Перенесення плагінів з локального зберігання (SQLite/Flatfile) на MySQL/MariaDB

Технічний посібник із міграції плагінів сервера Minecraft із повільних локальних конфігів та SQLite баз даних на багатопотокові рішення MySQL/MariaDB.

20.05.2026 Українська

Переведення плагінів з локального зберігання (SQLite/Flatfile) на MySQL/MariaDB

Коли ви тільки запускаєте сервер Minecraft, стандартні налаштування більшості плагінів здаються ідеальними. Вони працюють «із коробки», зберігаючи дані в локальні файли конфігурації (.yml, .json) або локальні бази даних (.db через рушій SQLite). Проте по мірі зростання проєкту — коли онлайн перекрочує позначку в 20–30 гравців — сервер починає страждати від періодичних мікрофризів (тіків, що тривають занадто довго), а в консолі хостингу з'являються попередження про затримки читання файлів.

У цій статті ми розберемо, чому локальні формати зберігання неминуче починають лагати при зростанні онлайну, як розгорнути централізовану базу даних на хостингу та правильно перевести на неї ключові плагіни: LuckPerms, EssentialsX та CoreProtect.

Чому Flatfile (.yml) та SQLite (.db) лагають при зростанні онлайну?

Проблема криється в архітектурі того, як операційна система та сервер Minecraft взаємодіють із диском хостингу:

  • Проблема Flatfile (.yml / .json): Щоразу, коли гравцеві потрібно видати привілей, зберегти його баланс або змінити стан гаманця, плагін змушений перезаписувати текстовий файл повністю. Якщо 20 гравців одночасно здійснюють транзакції, сервер починає раз за разом перечитувати та перезаписувати важкі файли конфігурації. Оскільки це часто відбувається синхронно з основним потоком гри (Main Thread), сервер буквально завмирає, очікуючи завершення операції введення-виведення (I/O).
  • Проблема SQLite (.db): SQLite — це чудова база даних, але вона являє собою один єдиний файл на диску. Головний мінус SQLite — блокування на рівні всього файлу (File Locking) при записі. Якщо плагін CoreProtect намагається записати в базу лог вибуху кріпера, жоден інший плагін (або цей же плагін в іншому потоці) не зможе нічого записати в цей файл, поки перша операція не завершиться. Виникає черга із запитів, яка виливається в відчутні лаги (мікрофризи) для гравців.

Рішення — MySQL / MariaDB: Це повноцінні мережеві системи керування базами даних (СУБД). Вони працюють у багатопотоковому режимі, підтримують блокування на рівні окремих рядків (а не всього файлу), вміють ефективно кешувати запити в оперативній пам'яті та обробляють дані асинхронно, повністю розвантажуючи основний процесор ігрового сервера.

Крок 1: Створення бази даних у панелі хостингу

Перед налаштуванням плагінів необхідно отримати реквізити доступу до MySQL. На сучасному ігровому хостингу це робиться в пару кліків:

  1. Перейдіть у панель керування сервером та відкрийте розділ «Бази даних» (Databases).
  2. Натисніть кнопку «Створити базу даних» (Create Database).
  3. Після створення панель відобразить реквізити. Нам знадобляться п'ять параметрів:
    • Host (IP-адреса або домен підключення, наприклад: 127.0.0.1 або sql.mygamehost.net)
    • Port (За замовчуванням для MySQL це 3306)
    • Database Name (Ім'я бази даних)
    • User (Ім'я користувача)
    • Password (Пароль)

Крок 2: Переведення плагінів на MySQL

Розглянемо перенесення трьох головних плагінів, які створюють максимальне навантаження на дискову підсистему.

1. LuckPerms (Права та привілеї)

LuckPerms ідеально оптимізований під роботу з мережею. Переведення на MySQL не тільки прибере лаги, а й дозволить вам зв'язати кілька серверів (наприклад, Сурвівал і Хаб) у єдину мережу прав.

  1. Відкрийте файл plugins/LuckPerms/config.yml.
  2. Знайдіть рядок storage-method: змініть значення з h2 або sqlite на mysql.
  3. Прокрутіть конфіг нижче до блоку data: і впишіть отримані від хостингу дані:
storage-method: mysql

data:
  address: localhost:3306 # Вкажіть ваш Host та Port через двокрапку
  database: lperms_db
  username: admin_user
  password: 'super_secure_password'
  table-prefix: 'lp_'
  1. Збережіть файл і введіть у консолі команду /lp sync. Плагін автоматично створить потрібні таблиці у вашій СУБД.

2. EssentialsX (Економіка, будинки, варпи, дані гравців)

За замовчуванням EssentialsX створює під кожного нового гравця окремий файл .yml у папці userdata. Коли на сервері реєструються тисячі гравців, папка перетворюється на кошмар для файлової системи Linux.

  1. Для роботи EssentialsX з базою даних вам знадобиться додатковий аддон — EssentialsXStorage (скачайте його з офіційного сайту розробників та покладіть у папку plugins/).
  2. Відкрийте основний plugins/Essentials/config.yml і знайдіть секцію зберігання (зазвичай у самому низу файлу).
  3. Перемкніть тип сховища на MySQL та заповніть параметри підключення:
essentials:
  storage:
    type: mysql
    mysql:
      host: localhost
      port: 3306
      database: essentials_db
      username: admin_user
      password: 'super_secure_password'

3. CoreProtect (Логування блоків)

CoreProtect — найважчий плагін на сервері, оскільки він записує мільйони дій. Переведення його на MySQL є критично важливим для стабільного TPS.

  1. Відкрийте файл plugins/CoreProtect/config.yml.
  2. Знайдіть параметр use-mysql: false і змініть його на use-mysql: true.
  3. Заповніть рядки підключення трохи нижче:
use-mysql: true
mysql-host: localhost
mysql-port: 3306
mysql-database: coreprotect_db
mysql-username: admin_user
mysql-password: "super_secure_password"
table-prefix: "co_"
  1. Перезапустіть сервер. При першому запуску CoreProtect почне індексацію структури бази даних, що може зайняти 1–2 хвилини.

Вирішення можливих проблем (Troubleshooting)

Проблема 1: Сервер видає помилку «Communications link failure» при запуску плагіна

Причина: Ігровий сервер не може достукатися до сервера бази даних. Або ви помилилися у заповненні хоста/пароля, або база даних на хостингу ще не запустилася.

Рішення: Уважно перевірте, чи немає зайвих пробілів або лапок у полях host та password. Якщо база розташована на зовнішньому сервері, переконайтеся, що хостинг дозволяє віддалені підключення (Remote Connections) до цієї бази даних.

Проблема 2: Зникли всі донати, варпи та регіони після увімкнення MySQL

Причина: Це логічно — плагіни підключилися до нової, абсолютно чистої бази даних, а всі ваші старі дані залишилися лежати в локальних файлах .db та .yml.

Рішення для LuckPerms: Плагін має вбудовану систему міграції. Перед тим як перемикати конфіг на MySQL, введіть команду: /lp export local_data. Потім перемкніть плагін на роботу з MySQL, запустіть сервер і введіть: /lp import local_data. Дані автоматично перенесуться з файлу в СУБД.

Рішення для інших плагінів:

Перенесення даних із SQLite (файлів .db) в MySQL вимагає використання сторонніх скриптів або конвертерів. Якщо на сервере вже грає багато людей, рекомендується проводити перемикання на MySQL у момент проведення планового вайпу (скидання світу), щоб почати ведення чистої та швидкої історії сервера.

Схожі статті

Оптимізація важких серверів з модами (Forge / NeoForge / Fabric)

Технічний посібник з оптимізації важких серверів Minecraft з модифікаціями. Огляд найкращих оптимізаторів, діагностика лагів через Spark та боротьба з навантаженням від автозаводів.

Читати далі

Передгенерація карти за допомогою Chunky: як назавжди позбутися лагів при польотах

Технічний посібник із передгенерації світів Minecraft за допомогою плагіна Chunky. Дізнайтеся, як запобігти падінню TPS через швидкі польоти гравців на елітрах.

Читати далі

Сучасні ядра Minecraft: Гайд з переходу, оптимізації та захисту сервера

Технічний посібник з міграції серверів Minecraft на продуктивні ядра (Paper, Purpur, Folia), тонкого налаштування конфігів для усунення лагів та організації ешелонованого захисту.

Читати далі