# Параметр innodb\_force\_recovery «не действует», а MariaDB продолжает падать на повреждённой странице: опция записана не в ту секцию конфигурации

**URL:** <https://kryptos.forum/t/parametr-innodb-force-recovery-ne-dejstvuet-a-mariadb-prodolzhaet-padat-na-povrezhdyonnoj-stranicze-opcziya-zapisana-ne-v-tu-sekcziyu-konfiguraczii/194>\
**Category:** Разработка ПО\
**Tags:** разработка\
**Created:** [30.Сентябрь.2026 09:37:28 UTC](https://kryptos.forum/t/parametr-innodb-force-recovery-ne-dejstvuet-a-mariadb-prodolzhaet-padat-na-povrezhdyonnoj-stranicze-opcziya-zapisana-ne-v-tu-sekcziyu-konfiguraczii/194 "2026-09-30T09:37:28Z")\
**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 09:37:28 UTC](https://kryptos.forum/t/parametr-innodb-force-recovery-ne-dejstvuet-a-mariadb-prodolzhaet-padat-na-povrezhdyonnoj-stranicze-opcziya-zapisana-ne-v-tu-sekcziyu-konfiguraczii/194/1 "2026-09-30T09:37:28Z")

</div>

**Что было.** MariaDB не стартует: `InnoDB: Fatal: Ending processing because of a corrupt database page`. Пользователь удалил все свои базы, ошибка осталась (повреждена системная область). Добавил `innodb_force_recovery=4` в конфиг, эффекта нет.

**Причина.** Строка была дописана в конец файла без заголовка секции. Файлы конфигурации MySQL/MariaDB устроены по секциям (`[mysqld]`, `[client]`, `[mysqldump]`…), и параметр, стоящий вне `[mysqld]` (или в `[client]`), сервер не читает, а клиентские программы его не понимают. В обсуждении в итоге пошли по пути чистой переустановки с очисткой `/var/lib/mysql` и последующим импортом дампа; автор подтвердил.

**Как проверить, что параметр реально применён.**

```auto
mysqld --print-defaults # или mariadbd --print-defaults: что сервер прочитает из всех файлов
my_print_defaults mysqld # то же для секции [mysqld]
mysql -e "SHOW VARIABLES LIKE 'innodb_force_recovery';" # если сервер запустился

```

Ошибки чтения конфига видны и в журнале при старте (`unknown variable`, `unknown option`), и они тоже мешают запуску: незнакомая опция в `[mysqld]` роняет сервер сразу.

**Где лежат конфиги и в каком порядке читаются.** `/etc/mysql/my.cnf` включает `/etc/mysql/conf.d/*.cnf` и `/etc/mysql/mariadb.conf.d/*.cnf` (MariaDB) или `mysql.conf.d/` (MySQL); файлы читаются по алфавиту, последнее значение выигрывает. Свои параметры класть в отдельный файл `/etc/mysql/mariadb.conf.d/99-local.cnf` с заголовком `[mysqld]` и не трогать пакетные файлы.

**Про `innodb_force_recovery` ещё раз.** Значения 1–3 безопасны для чтения и снятия дампа; 4–6 могут необратимо испортить данные и годятся только для попытки прочитать то, что иначе не читается, на копии. Если системное табличное пространство (`ibdata1`) повреждено так, что не помогает даже 6, чистая переустановка с импортом дампа это и есть решение, и хорошо, если дамп есть.

**Порядок при повреждённой странице.**

1. Копия каталога данных.
2. `[mysqld]` → `innodb_force_recovery = 1`, старт; не стартует, поднимать до 3.
3. `mariadb-dump --all-databases --single-transaction > all.sql` (при уровнях ≥4 убрать `--single-transaction`).
4. Остановить, убрать параметр, очистить каталог данных, `mariadb-install-db` (или переустановка пакета с purge), импорт дампа.
5. Причина повреждения: диск, внезапные выключения виртуальной машины, нехватка места. Без её устранения повторится.

Файлы опций описаны в [документации MariaDB](https://mariadb.com/kb/en/configuring-mariadb-with-option-files/).