SystemdDoctor
служба не работает mysql данные диск

MySQL: InnoDB не запускается после аварийного завершения

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

Что это значит

Есть режим принудительного восстановления (innodb_force_recovery), который позволяет поднять сервер для выгрузки данных. Это средство для спасения данных, а не для продолжения работы: после выгрузки базу нужно создать заново.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Повреждение после аварийного выключения

    InnoDB рассчитывает на корректную запись журнала. Отключение питания или зависание оставляют его в несогласованном состоянии.

  2. Диск был заполнен во время записи

    Нехватка места прерывает запись журнала и табличных файлов. После освобождения места данные могут остаться несогласованными.

  3. Проблемы носителя

    Ошибки чтения с диска выглядят как повреждение данных. Отличить помогают записи ядра.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Подробные сообщения InnoDB о причине отказа.

sudo tail -80 /var/log/mysql/error.log

Свободное место: частая причина повреждений.

df -h /var/lib/mysql

Ошибки диска, объясняющие повреждение.

journalctl -k -b --no-pager | grep -i "I/O error"

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Повреждение после аварийного выключения
Почему происходит
InnoDB рассчитывает на корректную запись журнала. Отключение питания или зависание оставляют его в несогласованном состоянии.
Как проверить
Посмотрите журнал ошибок. 
sudo tail -60 /var/log/mysql/error.log | grep -iE "innodb|corrupt|crash"
Как исправить
Восстановите из резервной копии. Если её нет, поднимите сервер в режиме восстановления (начиная с уровня 1), выгрузите данные и создайте базу заново. 
sudo systemctl stop mysql
# в my.cnf: innodb_force_recovery = 1
sudo systemctl start mysql && mysqldump --all-databases > /root/dump.sql
2. Диск был заполнен во время записи
Почему происходит
Нехватка места прерывает запись журнала и табличных файлов. После освобождения места данные могут остаться несогласованными.
Как проверить
Посмотрите свободное место и записи о нехватке. 
df -h /var/lib/mysql
sudo grep -i "no space" /var/log/mysql/error.log | tail
Как исправить
Освободите место, затем разбирайтесь с целостностью. Пока места нет, любые попытки запуска только усугубят состояние.
3. Проблемы носителя
Почему происходит
Ошибки чтения с диска выглядят как повреждение данных. Отличить помогают записи ядра.
Как проверить
Посмотрите записи ядра и состояние диска. 
journalctl -k -b --no-pager | grep -iE "I/O error|medium error" | head
sudo smartctl -H /dev/sda 2>/dev/null | head
Как исправить
Снимите копию данных на другой носитель и замените диск. Восстановление на умирающем диске бессмысленно.

Пример вывода

InnoDB обнаружил повреждение страницы. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

mysqld[5100]: [ERROR] [MY-012153] [InnoDB] Database page corruption on disk or a failed file read of page
mysqld[5100]: [ERROR] [MY-012154] [InnoDB] You may have to recover from a backup.
mysqld[5100]: [ERROR] [MY-013183] [InnoDB] Assertion failure: buf0buf.cc
systemd[1]: mysql.service: Main process exited, code=dumped, signal=ABRT

Связанные ошибки

Где встречается чаще всего

Источники

  • Документация MySQL: принудительное восстановление InnoDB документация программы
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Наблюдалось после отключения питания тестовой машины во время записи.     собственная проверка, systemd 255
    сверено 15 сентября 2026