MAATRIX GAMES / Блог / MySQL для игровых плагинов: настройка

MySQL для игровых плагинов: настройка

MAATRIX GAMES

Рано или поздно на сервере появляется плагин, который вместо привычных YAML или SQLite-файликов просит подключение к MySQL — обычно это LuckPerms, CoreProtect, экономика на Vault или что-то из мира uMod/Oxide для Rust. Новичка это часто ставит в тупик: где брать эту базу, что туда писать и почему плагин ругается на "Access denied". Разберём по шагам — от установки MySQL до бэкапа, чтобы всё завелось с первого раза и не развалилось при первом же вайпе.

Зачем плагину вообще база данных, а не файл

Файловое хранилище (YAML, JSON, SQLite) прекрасно работает, пока данных немного и сервер один. Но у него есть слабые места, из-за которых разработчики крупных плагинов переходят на MySQL:

  • Параллельный доступ. Если у вас несколько игровых серверов (например, хаб + несколько миров через BungeeCord/Velocity), и все они должны видеть одни и те же права игроков или баланс экономики — общий файл на каждом сервере не даст согласованности. MySQL как централизованное хранилище решает это естественно.
  • Целостность при сбоях. SQLite и файлы уязвимы к повреждению при резком отключении питания или креше процесса на середине записи. У полноценной СУБД журналирование транзакций куда надёжнее.
  • Объём данных. CoreProtect, который логирует буквально каждое действие игрока (блоки, контейнеры, чат), на активном сервере быстро генерирует миллионы записей — SQLite на таких объёмах начинает тормозить на выборках.

Если у вас один небольшой сервер и плагин из коробки поддерживает SQLite/H2 — можно спокойно остаться на нём, MySQL не обязателен. Но если плагин явно рекомендует MySQL для продакшена (как LuckPerms) или вы планируете сеть из нескольких серверов — лучше сразу настроить как надо.

MySQL на том же VPS или на отдельном сервере

На том же сервере, где крутится игра. Проще всего: один VPS, один SSH, минимум настройки сети. Подходит для одиночного сервера с одним-двумя плагинами на БД. Минус — MySQL и игра делят RAM и диск: на слабой конфигурации (2-4 ГБ) СУБД может откусывать кусок памяти, который иначе достался бы TPS.

На отдельном сервере/VPS. Оправдано, если у вас сеть из нескольких игровых серверов с одной общей базой (например, LuckPerms для сети через Velocity), либо если БД сама по себе нагружена (активный CoreProtect на популярном сервере). Плюс — изоляция: тяжёлый SQL-запрос не подвесит тикрейт игры. Минус — сложнее в настройке: порт MySQL наружу, фаервол под конкретный IP, плюс небольшая сетевая задержка.

Для старта и для большинства случаев — держите MySQL на том же VPS, что и игра. Выносить на отдельную машину есть смысл, когда реально упираетесь в ресурсы или строите сеть серверов.

Нужен игровой сервер?

MAATRIX GAMES — 45+ игр, деплой за минуты, DDoS-защита, автобэкапы. Тарифы от 399 ₽/мес.

Создать сервер

Устанавливаем MySQL или MariaDB

MariaDB — форк MySQL, полностью совместимый по протоколу и синтаксису, почти все плагины работают с ней без разницы. На Ubuntu/Debian она чаще уже в стандартных репозиториях и ставится проще:

sudo apt update
sudo apt install mariadb-server -y
sudo systemctl enable --now mariadb

Если хостер требует именно MySQL (например, из-за совместимости с другим софтом на сервере):

sudo apt install mysql-server -y
sudo systemctl enable --now mysql

После установки обязательно прогоните скрипт базовой защиты — он уберёт анонимный доступ, тестовую базу и попросит задать пароль root:

sudo mysql_secure_installation

На вопросы отвечайте: задать пароль root — да, убрать анонимных пользователей — да, запретить удалённый вход под root — да, удалить тестовую базу — да, перечитать привилегии — да. Root от MySQL плагинам вообще не понадобится — под них мы создадим отдельного пользователя с ограниченными правами (следующий раздел).

Проверить, что сервис живой и слушает порт:

sudo systemctl status mariadb
sudo ss -tlnp | grep 3306

Если база стоит на том же VPS, что и игра, порт 3306 наружу лучше вообще не открывать — плагин обращается к базе через 127.0.0.1, и фаервол снаружи эту дырку даже не увидит. Общие принципы настройки портов и фаервола под игровой сервер разобраны в статье про порты и фаервол.

Создаём базу данных и отдельного пользователя для плагинов

Не подключайте плагины под root — если конфиг с паролем утечёт (а конфиги иногда попадают в паблик-репозитории или бэкапы без шифрования), под root это компрометация всей СУБД, а под ограниченным пользователем — только конкретной базы.

Заходим в консоль MySQL от root:

sudo mysql -u root -p

Создаём базу и пользователя, ограниченного одной этой базой и локальным доступом:

CREATE DATABASE luckperms CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'lp_user'@'localhost' IDENTIFIED BY 'ваш-надёжный-пароль';
GRANT ALL PRIVILEGES ON luckperms.* TO 'lp_user'@'localhost';
FLUSH PRIVILEGES;

Обратите внимание на utf8mb4 — если создать базу с дефолтной кодировкой (часто latin1 в старых установках), ники с юникодом или эмодзи в чате (для плагинов логирования чата) могут ломаться при записи.

Если плагину подключается с другого сервера (случай "MySQL отдельно"), меняем 'localhost' на конкретный IP игрового сервера, а не на '%' (любой хост) — это заметно сужает поверхность атаки:

CREATE USER 'lp_user'@'203.0.113.10' IDENTIFIED BY 'ваш-надёжный-пароль';
GRANT ALL PRIVILEGES ON luckperms.* TO 'lp_user'@'203.0.113.10';
FLUSH PRIVILEGES;

Для каждого крупного плагина, который хранит много данных, разумно завести отдельную базу и отдельного пользователя (luckperms, coreprotect, essentials_economy и т.д.), а не сваливать всё в одну общую базу под одним логином — так проще разбираться при проблемах и делать точечный бэкап.

Подключаем плагин к базе: где и что прописывать

Дальше — сторона плагина. У каждого свой конфиг, но набор полей почти всегда одинаковый: хост, порт, имя базы, логин, пароль.

LuckPerms (plugins/LuckPerms/config.yml):

storage-method: mysql

data:
  address: localhost:3306
  database: luckperms
  username: lp_user
  password: 'ваш-надёжный-пароль'
  table-prefix: 'luckperms_'

После смены storage-method LuckPerms при первом запуске создаст таблицы автоматически — руками ничего создавать не нужно.

CoreProtect (plugins/CoreProtect/config.yml):

mysql: true
mysql-database: coreprotect
mysql-username: cp_user
mysql-password: ваш-надёжный-пароль
mysql-hostname: localhost
mysql-port: 3306

EssentialsX по умолчанию хранит экономику и данные игроков в файлах, встроенной MySQL-конфигурации нет: под БД экономики обычно ставят Vault как прослойку и отдельный экономический плагин с поддержкой SQL. Если у вас связка Vault + экономика, смотрите конфиг именно экономического плагина — поле обычно называется storage-type: mysql или похоже.

Плагины Rust на uMod/Oxide (например, Economics или ServerRewards) тоже могут писать в MySQL через отдельный коннектор-плагин. Общий подход к экономике на Rust — в статье про экономику Rust-сервера.

После правки конфига плагин почти всегда нужно перезапустить целиком (не хот-релоадом), чтобы он переоткрыл соединение с новыми параметрами. Общие принципы работы с конфигами плагинов — в статье про конфигурационные файлы игрового сервера.

Проверяем соединение и разбираем типичные ошибки

Перед тем как гонять плагин, стоит проверить доступ руками:

mysql -u lp_user -p -h localhost luckperms -e "SHOW TABLES;"

Если команда отработала без ошибок — плагин с теми же данными тоже подключится. Частые проблемы:

  • Access denied for user 'lp_user'@'localhost' — неверный пароль в конфиге, либо пользователь создан для другого хоста ('%' вместо 'localhost' или наоборот). Проверьте через SELECT user, host FROM mysql.user; от root.
  • Unknown database 'luckperms' — опечатка в имени базы в конфиге плагина. Сверьте SHOW DATABASES;.
  • Can't connect to MySQL server on '...' (111) — сервис не запущен (systemctl status mariadb) либо порт закрыт фаерволом при подключении с другого сервера.
  • Плагин подключается, но с задержкой роняет TPS — проверьте, не соперничает ли MySQL с игрой за RAM (free -h); при нехватке — добавьте RAM или вынесите базу на отдельный сервер.
  • Кракозябры вместо ников/текста — почти всегда неправильная кодировка при создании базы (не utf8mb4). Пересоздать базу проще, чем чинить кодировку задним числом.

Если после всех проверок соединение всё равно не идёт, а сервер только недавно переехал к новому хостеру — стоит перепроверить, не потерялись ли настройки при переносе; это разобрано в статье про миграцию сервера к другому хостеру.

Бэкап и восстановление базы данных плагинов

Важный момент, который многие упускают: обычный бэкап файлов игрового сервера (мир, конфиги, jar) не включает данные из MySQL — это отдельное хранилище, физически лежащее в своей директории (/var/lib/mysql). Если вы бэкапите только папку сервера, а потом восстанавливаетесь из бэкапа — права игроков из LuckPerms или логи CoreProtect окажутся в базе, которая осталась в старом (или вообще нерабочем) состоянии.

Общие принципы автобэкапа по расписанию — в статье про автобэкапы игрового сервера, здесь — специфика именно дампа MySQL.

Снять дамп одной базы:

mysqldump -u lp_user -p luckperms > /backups/luckperms_$(date +%F).sql

Дамп сразу нескольких баз плагинов:

mysqldump -u root -p --databases luckperms coreprotect essentials_economy > /backups/plugins_$(date +%F).sql

Для регулярного бэкапа удобно завести отдельного пользователя, у которого есть только права на чтение и экспорт (SELECT, LOCK TABLES, SHOW VIEW), без права менять данные — тогда даже если скрипт бэкапа скомпрометирован, он не сможет ничего сломать в базе:

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'другой-пароль';
GRANT SELECT, LOCK TABLES, SHOW VIEW ON *.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;

Автоматизировать снятие дампа по расписанию проще всего через cron:

crontab -e
# каждый день в 4:30 ночи
30 4 * * * mysqldump -u backup_user -p'другой-пароль' --databases luckperms coreprotect | gzip > /backups/mysql_$(date +\%F).sql.gz

Храните пароль не прямо в crontab, а в отдельном файле с правами 600 (~/.my.cnf с секцией [mysqldump]) — так он не светится в списке процессов при выполнении команды.

Восстановление из дампа — обратная команда:

mysql -u root -p luckperms < /backups/luckperms_2026-08-29.sql

Проверяйте дампы на реальную восстанавливаемость хотя бы раз в пару месяцев — бэкап, который ни разу не разворачивали на тестовой базе, по факту не бэкап, а файл, в котором вы просто верите.

Нужен игровой сервер?

MAATRIX GAMES — 45+ игр, деплой за минуты, DDoS-защита, автобэкапы. Тарифы от 399 ₽/мес.

Создать сервер

Частые вопросы

Обязательно ли использовать MySQL, если плагин это предлагает как опцию?

Нет. Если сервер один и данных немного, встроенный SQLite/файлы из коробки — рабочее и более простое решение. MySQL имеет смысл при сети серверов или большом объёме данных (частые логи, много игроков).

Можно ли использовать одну базу MySQL для нескольких плагинов сразу?

Технически да, если у каждого плагина свой table-prefix в конфиге, чтобы таблицы не пересекались по именам. Но отдельные базы под каждый крупный плагин упрощают бэкап и диагностику.

MariaDB и MySQL — это одно и то же для плагина?

Для подавляющего большинства игровых плагинов — да, они используют стандартный MySQL-протокол и не заметят разницы. Экзотические SQL-функции, специфичные для одной из СУБД, встречаются в плагинах крайне редко.

Плагин пишет Communications link failure через какое-то время после старта — почему?

Часто это тайм-аут неактивного соединения со стороны MySQL (wait_timeout), а плагин не переоткрывает его сам. Проверьте, использует ли плагин connection pooling (HikariCP есть почти у всех современных плагинов вроде LuckPerms) — если да, проблема обычно в другом, стоит смотреть полный стектрейс в логах.

Нужно ли делать бэкап MySQL, если я и так делаю снапшот всего VPS у хостера?

Снапшот диска — это тоже валидный бэкап данных MySQL, но он снимается по расписанию хостера и часто реже, чем хотелось бы для активной базы с логами. Отдельный mysqldump по cron даёт вам контроль над частотой и возможность восстановить конкретную базу, не разворачивая весь сервер целиком.