MySQL не стартует после перезагрузки

MAATRIX

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

Первый шаг: читаем лог ошибок MySQL

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

# почему сервис упал — краткая причина
systemctl status mysql -l
# полный лог ошибок MySQL — здесь настоящая причина
tail -50 /var/log/mysql/error.log
# для MariaDB путь может отличаться
journalctl -u mariadb --no-pager | tail -50

В логе почти всегда есть строка с конкретной ошибкой: не хватает места, не может открыть файл (права), повреждена таблица, порт занят, битый ibdata. Прочитайте лог снизу вверх до первой ошибки — она и есть корень. Дальнейшие действия зависят от того, что именно там написано, поэтому не пропускайте этот шаг: без лога вы будете чинить вслепую. Ниже разберём самые частые сообщения и что с ними делать.

Частая причина: закончилось место на диске

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

# место на диске
df -h
# и inode — их нехватка даёт тот же эффект
df -i

Если диск заполнен под 100% (или кончились inode), освободите место: удалите старые логи, ненужные бэкапы, почистите кэши. Частый виновник — сами бинарные логи MySQL (binlog), разросшиеся до десятков гигабайт, или огромный error.log. После освобождения хотя бы пары гигабайт пробуйте запустить базу снова. Это тот случай, когда причина не в самой MySQL, а в окружении, и лечится она за минуту — но без проверки места можно долго искать не там.

Права на файлы данных

Вторая частая причина — MySQL не может получить доступ к своим файлам данных из-за неверных прав или владельца. Такое случается после восстановления из бэкапа, ручного копирования файлов, изменений в системе. Каталог данных (/var/lib/mysql) и всё в нём должны принадлежать пользователю mysql. В логе — Permission denied или Can't create/open file:

# кто владелец каталога данных
ls -ld /var/lib/mysql
# вернуть правильного владельца
chown -R mysql:mysql /var/lib/mysql
chmod 750 /var/lib/mysql

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

Повреждение таблиц InnoDB

Если сервер выключился жёстко (потеря питания, зависание, kill без корректного завершения), InnoDB может обнаружить несогласованность при старте и отказаться подниматься. В логе — упоминания InnoDB, corrupt, crash recovery, иногда циклический перезапуск. InnoDB умеет восстанавливаться сам при обычном старте, прокатывая журнал, но при серьёзном повреждении нужен режим принудительного восстановления:

# добавить в конфиг [mysqld] и запустить
innodb_force_recovery = 1

Значение начинают с 1 и повышают до 6 только по необходимости — чем выше, тем агрессивнее и рискованнее восстановление. Как только база поднялась в этом режиме, немедленно сделайте дамп всех данных через mysqldump, затем уберите параметр, пересоздайте базу и импортируйте дамп обратно. Важно: режим innodb_force_recovery — для спасения данных, а не для постоянной работы; в нём база доступна только на чтение и в ограниченном виде. Именно поэтому свежий бэкап тут бесценен: при сильном повреждении восстановление из дампа надёжнее любого форсирования.

Занятый порт и остатки процесса

Иногда MySQL не стартует, потому что порт 3306 уже занят или предыдущий процесс не завершился корректно и держит сокет. В логе — Address already in use или ошибка про PID-файл. Проверьте, не висит ли старый процесс:

# кто держит порт 3306
ss -tlnp | grep 3306
# зависшие процессы mysqld
ps aux | grep mysqld
# при необходимости — снять зависший процесс и удалить устаревший PID-файл

Если обнаружен завис­ший mysqld, аккуратно завершите его и уберите устаревший PID- или сокет-файл, на который жалуется лог, затем стартуйте заново. Реже порт занимает другой экземпляр базы или посторонний сервис — тогда либо освободите порт, либо смените порт MySQL в конфиге. Эта причина встречается после сбойных перезапусков, когда система не успела корректно освободить ресурсы предыдущего запуска.

Профилактика: чтобы база поднималась сама

Чтобы перезагрузка не превращалась в аварию, подготовьтесь заранее. Настройте регулярные автоматические бэкапы базы на отдельное хранилище и проверяйте, что они разворачиваются, — это страховка от любого повреждения. Мониторьте свободное место и inode, чтобы диск не переполнялся незаметно и не ронял базу при следующем старте. Настройте ротацию бинарных логов, чтобы они не съедали диск.

• Держите свежие бэкапы базы отдельно от сервера и проверяйте восстановление.
• Следите за местом на диске и inode с оповещениями.
• Настройте ротацию binlog и логов, чтобы не переполнять диск.
• Убедитесь, что автозапуск базы включён (systemctl enable mysql).
• Завершайте сервер корректно, избегая жёстких выключений под нагрузкой.

Стабильная работа базы начинается с сервера, где хватает быстрого диска и памяти, а выключения происходят корректно. У MAATRIX VPS и выделенные серверы под базы данных доступны в локациях RU, US и UK — быстрый NVMe, запас по ресурсам, полный root-доступ и оплата из России картой или криптой. Когда диску есть куда расти, а бэкапы делаются автоматически, перезагрузка сервера перестаёт быть поводом для тревоги за базу.

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