После обновления Ubuntu до 24.04 MariaDB не стартует с «Unknown/unsupported storage engine: InnoDB»: журнал повтора от старой версии и как переносить базы правильно

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

Что было. Обновление выпуска с 22.04 на 24.04 подняло MariaDB с 10.6 до 10.11. Служба не стартует; в журнале [ERROR] Unknown/unsupported storage engine: InnoDB, а чуть выше причина: InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.6.7. Каталог данных лежал на отдельном разделе и был подключён символической ссылкой вместо /var/lib/mysql.

Почему. Старая версия завершилась некорректно (или её остановили до того, как она дописала журнал повтора), а новая версия отказывается применять чужой журнал: обновление формата возможно только с чистого состояния. Без InnoDB сервер стартовать не может, отсюда «неизвестный движок».

Что сделал автор. После долгих попыток переустановил MariaDB с чистым каталогом данных и загрузил базы из SQL-дампов. Попытки вернуть старый каталог как есть снова ломали запуск. Подтверждено. Ключевой совет участников: между версиями переносить данные дампом, а не копированием файлов.

Как надо было (и как выйти из ситуации без дампа).

  1. До обновления выпуска: mariadb-dump --all-databases --single-transaction --routines --events > all.sql, затем чистая остановка systemctl stop mariadb и проверка, что в журнале Shutdown complete. Только потом do-release-upgrade.
  2. Если уже сломано и дампа нет: поставить рядом (в контейнере или на другой машине) ту же старую версию 10.6, подсунуть ей копию каталога данных, дать ей корректно стартовать и восстановиться, снять дамп, остановить чисто. Затем импортировать в новую версию. Это надёжнее любых «принудительных» флагов.
  3. innodb_force_recovery (уровни 1–6 в [mysqld]) нужен только чтобы поднять сервер в режиме «только чтение» и снять дамп; выше 3 возможна потеря данных, и после дампа каталог нужно пересоздать. Не оставлять параметр в конфиге.
  4. После импорта на новой версии обязательно mariadb-upgrade (проверка системных таблиц) и удаление символических ссылок вместо каталога данных: лучше указать datadir= в конфиге явно, чтобы AppArmor и пакетные скрипты знали, где данные.

Отдельно про AppArmor. При каталоге данных вне /var/lib/mysql профиль usr.sbin.mariadbd блокирует доступ, и симптом похож («не может открыть файлы»); нужен алиас или дополнение профиля в /etc/apparmor.d/local/. Проверять journalctl -k | grep apparmor.

Проверка перед любыми действиями. journalctl -u mariadb -b целиком, не только последняя строка: причина всегда выше «unsupported storage engine».

Обновление описано в документации MariaDB.