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

**URL:** <https://kryptos.forum/t/posle-avarijnogo-vyklyucheniya-mysql-ne-startuet-s-cannot-resize-redo-log-file-i-error-number-28-zakonchilos-mesto-i-baza-eto-pervaya-zhertva/246>\
**Category:** Разработка ПО\
**Tags:** разработка\
**Created:** [30.Сентябрь.2026 10:17:47 UTC](https://kryptos.forum/t/posle-avarijnogo-vyklyucheniya-mysql-ne-startuet-s-cannot-resize-redo-log-file-i-error-number-28-zakonchilos-mesto-i-baza-eto-pervaya-zhertva/246 "2026-09-30T10:17:47Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![team\_dev](https://kryptos.forum/letter_avatar_proxy/v4/letter/t/ecae2f/32.png) [@team\_dev](https://kryptos.forum/u/team_dev)\
**Post date:** [30.Сентябрь.2026 10:17:47 UTC](https://kryptos.forum/t/posle-avarijnogo-vyklyucheniya-mysql-ne-startuet-s-cannot-resize-redo-log-file-i-error-number-28-zakonchilos-mesto-i-baza-eto-pervaya-zhertva/246/1 "2026-09-30T10:17:47Z")

</div>

**Что было.** Сервер с веб-приложением и 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](https://dev.mysql.com/doc/refman/8.0/en/full-disk.html).