MySQL: не запускается после перезагрузки — причины и решение

MAATRIX

Перезагрузили сервер, а сайт лёг с ошибкой базы: MySQL не запускается после перезагрузки. Ситуация пугает, но в подавляющем большинстве случаев причина конкретна и указана прямо в логе — нехватка места, испорченные права, повреждённая таблица или занятый порт. Не паникуйте и не удаляйте данные: сначала прочитайте лог, а дальше действуйте по причине. Разберём шаг за шагом.

Первое действие: прочитайте error.log

Не гадайте, почему сервис не встаёт, — он сам пишет причину в лог ошибок. Сначала посмотрите статус и последние строки журнала:

systemctl status mysql
journalctl -u mysql --no-pager | tail -n 30
tail -n 40 /var/log/mysql/error.log

В логе почти всегда есть внятная строка о причине: Can't create/write to file, Table ... is marked as crashed, InnoDB: Cannot allocate memory, bind on TCP/IP port: Address already in use и подобные. Эта строка — ваш диагноз. Не пытайтесь чинить вслепую и тем более не сносите каталог данных: почти любая из типовых причин решается без потери данных, если сначала понять, что именно пишет MySQL. Ниже разберём самые частые сообщения и что с ними делать.

Причина 1: закончилось место на диске

Очень частый случай: диск заполнился, и при старте MySQL не может писать в свои файлы. В логе будет что-то про невозможность записи или No space left on device. Проверьте свободное место:

df -h

Если раздел с базой (обычно /var/lib/mysql на корневом разделе) заполнен на 100%, MySQL не запустится. Освободите место: удалите старые логи, ненужные бэкапы, очистите кэши пакетов. Частый пожиратель места — сами логи MySQL (бинлоги) и системные журналы. После освобождения хотя бы нескольких гигабайт снова запустите сервис:

systemctl start mysql

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

Причина 2: неверные права на каталог данных

Если в логе Can't create/write to file или упоминание прав доступа, а место есть — проблема в правах на каталог данных MySQL. Такое случается после ручного копирования файлов, восстановления из бэкапа или сбоя, когда владельцем каталога стал не тот пользователь. Каталог данных должен принадлежать пользователю mysql:

chown -R mysql:mysql /var/lib/mysql
chmod 750 /var/lib/mysql

После восстановления прав запустите сервис. Ещё одна вариация — SELinux или AppArmor блокирует доступ после изменений; тогда в логе будут соответствующие отказы, и нужно поправить политику или контексты. Но самый частый случай — именно чужой владелец каталога после операций с файлами. Всегда возвращайте владельца mysql:mysql каталогу данных, если трогали его вручную, и права на старт восстановятся.

Причина 3: повреждённая таблица InnoDB

Если в логе Table ... is marked as crashed или ошибки InnoDB о несогласованности, а сервис падает при старте — повреждена таблица или журнал InnoDB, часто из-за жёсткого выключения питания. Здесь помогает запуск в режиме восстановления. Аккуратно добавьте в конфиг под секцию [mysqld] параметр восстановления и стартуйте:

[mysqld]
innodb_force_recovery = 1

После этого MySQL обычно поднимается в режиме только для чтения — сразу сделайте дамп данных через mysqldump, пока есть доступ. Значение поднимают от 1 до 6 только по нарастающей и только при необходимости: чем выше, тем более разрушительно. Сняв дамп, уберите параметр, при необходимости пересоздайте базу и восстановите из дампа. Это стандартная и проверенная процедура: не удаляйте файлы наугад, а спасайте данные через режим восстановления и последующий дамп.

Причина 4: порт занят или второй экземпляр

Ошибка Address already in use на порту 3306 означает, что порт уже занят — обычно вторым, зависшим процессом MySQL, оставшимся от предыдущего запуска. Посмотрите, кто держит порт:

ss -tlnp | grep 3306

Если это старый процесс mysqld, корректно остановите сервис и убедитесь, что процесс завершился, затем запустите заново. Иногда причина в том, что systemd считает сервис запущенным, а процесс завис в промежуточном состоянии; тогда помогает полная остановка и повторный старт. Реже конфликт создаёт другой софт на 3306 — тогда либо остановите его, либо смените порт MySQL в конфиге. Главное — чтобы порт был свободен к моменту старта сервиса.

Как понять, что данные целы

Самый частый страх при этой проблеме — потерять базу. Хорошая новость: большинство причин (место, права, порт) вообще не затрагивают данные, а повреждение InnoDB решается через дамп в режиме восстановления. Как только MySQL поднялся, проверьте, что базы на месте и читаются:

mysql -e "SHOW DATABASES;"
mysqlcheck --all-databases

mysqlcheck проверит таблицы и укажет на проблемы. Если всё OK — данные целы, можно выдохнуть. Именно поэтому регулярные бэкапы через mysqldump или иной инструмент критичны: даже в худшем сценарии с повреждением вы восстанавливаетесь из копии за минуты. Настроенный автоматический дамп базы — лучшая страховка от любой из описанных ситуаций.

Профилактика: чтобы MySQL стартовал стабильно

Большинство проблем со стартом предотвращаются простыми мерами. Следите за свободным местом на диске и настройте оповещение при заполнении — переполненный диск не только валит старт, но и повреждает таблицы при записи. Настройте ротацию бинлогов и логов, чтобы они не съедали раздел. Корректно выключайте сервер (не выдёргивайте питание виртуалки), давая MySQL завершиться штатно, — это резко снижает риск повреждения InnoDB.

И главное — регулярные автоматические бэкапы, которые лежат отдельно от сервера. Тогда любая из описанных аварий превращается из катастрофы в рядовую процедуру восстановления. Держите под рукой привычку начинать диагностику с error.log: MySQL честно пишет причину, и большинство «страшных» отказов старта решаются за несколько минут, если не паниковать и не удалять данные наугад.

Отдельно стоит следить за памятью. Если в логе InnoDB: Cannot allocate memory — база не смогла выделить буферный пул при старте, потому что на сервере не хватило RAM. Такое случается, когда innodb_buffer_pool_size выставлен слишком большим для доступной памяти или когда память отъели другие процессы. Тогда либо уменьшите буфер под реальный объём RAM, либо освободите память, либо добавьте её серверу. Проверять доступную память полезно и до перезагрузки, особенно если незадолго до этого меняли конфигурацию MySQL: изменение, которое казалось безобидным на работающей базе, может помешать ей стартовать заново на сервере со скромной памятью.

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