После аварийного выключения MySQL не стартует с «Cannot resize redo log file» и «Error number 28»: закончилось место, и база это первая жертва

Разработка ПО
1

Что было. Сервер с веб-приложением и MySQL выключили принудительно. После загрузки база не стартует; в журнале ошибок [ERROR] [InnoDB] Cannot resize redo log file … Write to file failed at offset 0, 0 bytes written, Error number 28 means 'No space left on device', и дальше отказ инициализации InnoDB. При этом администратор сначала не связал сообщение с диском.

Почему. Код 28 это ENOSPC, нет места на устройстве. При старте InnoDB создаёт или расширяет журналы повтора; для этого нужны сотни мегабайт свободного места на разделе с каталогом данных. Место кончилось ещё до выключения (в обсуждении раздел был заполнен), и аварийное выключение лишь сделало проблему видимой. Автор освободил место (удаление ненужных пакетов и данных, перенос части каталогов), после чего база поднялась; для части работ понадобился chroot с загрузочного носителя. Подтверждено.

Правильный порядок.

  1. df -h и df -i для раздела с /var/lib/mysql (и для /tmp, который MySQL использует для временных таблиц). Если занято 100 %, дальше ничего не запускать до освобождения хотя бы нескольких гигабайт.
  2. Что освобождать безопасно: journalctl --vacuum-size=200M, apt clean, старые ядра (apt autoremove), архивы в /var/log, ротация логов приложения, кэш пакетов и сборок. Что не трогать: файлы ib_logfile*, ibdata1, binlog.* руками; бинарные журналы чистить только командой PURGE BINARY LOGS из работающего сервера или через binlog_expire_logs_seconds.
  3. Запустить MySQL, проверить journalctl -u mysql -b, затем mysqlcheck --all-databases.
  4. Если сервер поднялся, но данные повреждены (отдельные таблицы не открываются): режимы принудительного восстановления и дамп (отдельный разбор).

Почему база страдает первой. Она пишет постоянно (журналы повтора, бинарные журналы, временные таблицы) и честно останавливается при отказе записи; веб-сервер и системные службы часто продолжают работать «как-то». Поэтому «сайт открывается, а база упала» типичная картина переполненного диска.

Профилактика.

  • Каталог данных на отдельном разделе или томе с запасом; мониторинг с порогом 85 % и оповещением.
  • binlog_expire_logs_seconds (по умолчанию 30 дней) под реальный объём; на небольших серверах без репликации бинарные журналы можно отключить (skip-log-bin) или хранить 3–7 дней.
  • Регулярные дампы с хранением на другом диске: они же спасают, если восстановление не удалось.
  • Не выключать сервер принудительно при «зависании»: сначала systemctl stop mysql через консоль, дождаться, потом перезагрузка.

Поведение при заполненном диске описано в документации MySQL.