MariaDB на сервере: частые ошибки и решения

MAATRIX

Ошибки MariaDB на сервере выглядят угрожающе, но за большинством стоит десяток типовых причин с коротким решением. Ниже — разбор частых проблем: access denied, «can't connect through socket», too many connections, отказ старта после сбоя, переполнение диска и кракозябры в кодировке. Для каждой сначала даётся решение, потом причина, чтобы вы починили быстро, а разобрались без спешки. Поскольку MariaDB — форк MySQL, многие ошибки и их лечение совпадают, но есть и свои нюансы.

Access denied for user

Классическая ERROR 1045 (28000): Access denied for user 'appuser'@'localhost' означает, что сервер работает, но не пускает. Первое, что нужно понять: в MariaDB пользователь 'appuser'@'localhost' и 'appuser'@'127.0.0.1' — это два разных пользователя с разными правами. Если приложение подключается по TCP к 127.0.0.1, а вы завели только запись для localhost (сокет), доступа не будет. Посмотрите фактический список:

sudo mariadb -e "SELECT user, host, plugin FROM mysql.user;"

Обратите внимание на колонку plugin. Если у root там стоит unix_socket, то войти по паролю по сети под ним нельзя в принципе — это защита, а не ошибка. Для приложений заводите отдельных пользователей с обычной парольной аутентификацией. Если же прав не хватает на конкретную базу, выдайте их явно через GRANT и выполните FLUSH PRIVILEGES. При забытом пароле root его сбрасывают через запуск с --skip-grant-tables, но только локально и с наглухо закрытым портом на время процедуры.

Can't connect through socket

Ошибка Can't connect to local server through socket '/run/mysqld/mysqld.sock' почти всегда значит, что сервер не запущен. Проверьте статус и, если служба лежит, ищите причину в журнале:

sudo systemctl status mariadb
sudo journalctl -u mariadb -n 50

Частые причины падения — закончилось место на диске, повреждён конфиг после ручной правки или не хватило памяти под буфер InnoDB. Строка InnoDB: Cannot allocate memory в журнале прямо указывает на нехватку RAM: уменьшите innodb_buffer_pool_size или добавьте памяти на VPS. Ошибки прав на каталог /var/lib/mysql тоже роняют старт — проверьте, что владелец каталога пользователь mysql.

Реже проблема в том, что приложение ищет сокет по одному пути, а сервер создаёт его по другому. Тогда подключайтесь по TCP через -h 127.0.0.1 или укажите верный путь к сокету в настройках клиента. Точный путь всегда виден в конфиге сервера в секции [mysqld] параметром socket.

Too many connections

ERROR 1040: Too many connections — сервер упёрся в лимит max_connections. Быстрая диагностика показывает, кто занимает соединения:

sudo mariadb -e "SHOW STATUS LIKE 'Threads_connected'; SHOW PROCESSLIST;"

Чаще всего лимит выбирают «спящие» соединения в состоянии Sleep — приложение открыло их и не закрыло из-за отсутствия пула или слишком большого wait_timeout. Простое повышение лимита лечит симптом и съедает память: каждое соединение резервирует буферы. Правильнее уменьшить wait_timeout, чтобы простаивающие коннекты закрывались быстрее, и настроить пул соединений на стороне приложения.

Если на сервере много сайтов и каждый плодит подключения, вывод честный: либо оптимизировать приложения, либо взять сервер с большим объёмом RAM. Задранный до тысячи max_connections на слабой машине приводит к тому, что база падает под собственным весом при первом же всплеске трафика — памяти на все заявленные соединения физически не хватает.

MariaDB не стартует после сбоя или перезагрузки

Частая ситуация на слабых VPS: после ребута или аварийного выключения MariaDB не поднимается. Смотрите журнал. Если там Out of memory и процесс убит OOM-killer — серверу не хватает RAM. На машине с 1 ГБ памяти база с настройками по умолчанию может не влезать. Уменьшите буфер InnoDB, отключите ненужные компоненты, добавьте небольшой swap как страховку от пиков или, что честнее при постоянной нехватке, перейдите на тариф с большей памятью.

Другой сценарий — повреждение таблиц InnoDB после жёсткого выключения. В журнале будут строки о восстановлении (crash recovery); обычно InnoDB чинит себя сам, дайте ему время. Если восстановление зацикливается и сервер падает, помогает временный запуск с innodb_force_recovery на минимальном уровне, чтобы поднять базу и немедленно снять дамп. Но это аварийный режим для спасения данных, а не рабочее состояние — после снятия дампа базу восстанавливают из него на чистом сервере.

Переполнение диска и разросшиеся логи

Отказ записи с No space left on device означает, что закончилось место. Сначала посмотрите, что заняло диск:

df -h
sudo du -sh /var/lib/mysql/*

Типичные пожиратели — бинарный лог репликации, файлы больших таблиц и старые дампы бэкапов рядом с базой. Бинлоги очищаются командой PURGE BINARY LOGS BEFORE '2026-08-01 00:00:00'; при условии, что они уже не нужны репликам. Чтобы логи не копились впредь, задайте binlog_expire_logs_seconds для автоматической очистки. После освобождения места база продолжит работу.

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

Ещё один тихий пожиратель места, о котором забывают, — раздувание таблиц (fragmentation) при интенсивном удалении и обновлении строк. Файл таблицы InnoDB не уменьшается автоматически после массового удаления данных: место освобождается внутри файла, но операционной системе не возвращается. Если вы удалили миллионы строк, а df всё равно показывает занятый диск, выполните OPTIMIZE TABLE имя; — команда пересобирает таблицу и отдаёт лишнее место системе. На больших таблицах это тяжёлая операция, запускайте её в период низкой нагрузки и убедитесь, что на диске есть временное место под пересборку.

Кракозябры и другие мелкие беды

Текст сохраняется, но русские буквы превращаются в «Ð¿Ñивеѻ или вопросительные знаки — это несовпадение кодировок между базой, таблицей, соединением и приложением. Проверьте настройки через SHOW VARIABLES LIKE 'character_set%'; и приведите всё к utf8mb4. Важнее всего кодировка соединения: приложение при подключении должно указывать utf8mb4, иначе данные искажаются независимо от настроек базы. Уже испорченные записи чинят только восстановлением из корректного дампа.

Если сервер стабильно упирается в память или диск, это честный сигнал, что железо мало для задачи. В MAATRIX можно быстро арендовать VPS в России, США или Великобритании с нужными ресурсами под MariaDB и перенести базу без спешки. Оплата — картой РФ, по СБП, криптой или токеном MAAT, иностранная карта не требуется.

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