Режимы восстановления InnoDB
Режим восстановления InnoDB используется для восстановления из чрезвычайных ситуаций. Перед внесением изменений необходимо убедиться, что у вас есть резервная копия базы данных на случай, если потребуется ее восстановление. Серверная системная переменная innodb_force_recovery устанавливает режим восстановления. Режим 0 соответствует нормальному режиму работы, а чем выше режим, тем строже ограничения. Более высокие режимы включают все ограничения более низких режимов.
Режим восстановления никогда не следует устанавливать на значение, отличное от нуля, кроме чрезвычайных ситуаций.
Обратите внимание, что режим восстановления не исправляет повреждения. Поврежденные файлы остаются поврежденными независимо от режима восстановления. Единственная цель режима восстановления — предоставить доступ к данным для чтения, если это вообще возможно.
В целом, лучше начать с режима восстановления 1 и увеличивать его по одному значению, если это необходимо. При режиме восстановления < 4 теряются только поврежденные страницы. При режиме 4 могут быть повреждены вторичные индексы. При режиме 5 результаты могут быть несогласованными и вторичные индексы могут быть повреждены (даже если они не были повреждены при режиме 4). Значение 6 оставляет страницы в устаревшем состоянии, что может привести к дополнительным повреждениям.
До MariaDB 10.2.7, режим 0 был единственным режимом, допускающим изменения данных. С MariaDB 10.2.7, транзакции записи разрешены при режиме 3 или меньше.
Для восстановления таблиц можно выполнить SELECT для выгрузки данных и DROP TABLE (когда разрешены транзакции записи) для удаления поврежденных таблиц.
Доступны следующие режимы:
Режимы восстановления
Поведение режима восстановления отличается в зависимости от версии (сервер/хранилище/innobase/include/srv0srv.h)
MariaDB 10.4 и ранее:
| Режим | Описание |
|---|---|
| 0 | По умолчанию, когда InnoDB работает в нормальном режиме. До MariaDB 10.2.7, это был единственный режим, допускающий изменения данных. С MariaDB 10.2.7, транзакции записи разрешены при innodb_force_recovery<=3. |
| 1 | (SRV_FORCE_IGNORE_CORRUPT) позволяет серверу продолжать работу, даже если обнаружены поврежденные страницы. Это достигается путем игнорирования определенных ошибок в восстановлении на основе журнала редо, таких как отсутствие файлов данных или поврежденные страницы данных. Любой журнал редо для затронутых файлов или страниц будет пропущен. Вы можете облегчить выгрузку таблиц, выполнив оператор SELECT * FROM table_name, чтобы пропустить поврежденные индексы и страницы. |
| 2 | (SRV_FORCE_NO_BACKGROUND) останавливает работу главного потока, предотвращая сбой, который происходит во время очистки. Очистка не будет выполнена, поэтому журналы отката будут продолжать расти. |
| 3 | (SRV_FORCE_NO_TRX_UNDO) не отменяет транзакции после восстановления от сбоя. Не влияет на отмену текущих активных транзакций. Начиная с MariaDB 10.2.7, также предотвращает выполнение некоторых фоновых задач, генерирующих откат. Эти задачи могут столкнуться с ожиданием блокировки из-за восстановленных неполных транзакций, отмена которых предотвращается. |
| 4 | (SRV_FORCE_NO_IBUF_MERGE) не рассчитывает статистику таблиц и предотвращает слияния буфера вставки. |
| 5 | (SRV_FORCE_NO_UNDO_LOG_SCAN) обрабатывает незавершенные транзакции как завершенные и не анализирует журналы отката при запуске. |
| 6 | (SRV_FORCE_NO_LOG_REDO) не выполняет прокрутку вперед журнала редо в рамках восстановления. Запросы, требующие индексов, вероятно, завершатся ошибкой при активном режиме. Однако, если выгрузка таблицы все равно приведет к сбою, можно попробовать использовать SELECT * FROM tab ORDER BY primary_key DESC для выгрузки всех данных после поврежденной части. |
С MariaDB 10.5 по MariaDB 10.6.4:
| Режим | Описание |
|---|---|
| 0 | По умолчанию, когда InnoDB работает в нормальном режиме. Транзакции записи разрешены при innodb_force_recovery<=4. |
| 1 | (SRV_FORCE_IGNORE_CORRUPT) позволяет серверу продолжать работу, даже если обнаружены поврежденные страницы. Это достигается путем игнорирования определенных ошибок в восстановлении на основе журнала редо, таких как отсутствие файлов данных или поврежденные страницы данных. Любой журнал редо для затронутых файлов или страниц будет пропущен. Вы можете облегчить выгрузку таблиц, выполнив оператор SELECT * FROM table_name, чтобы пропустить поврежденные индексы и страницы. |
| 2 | (SRV_FORCE_NO_BACKGROUND) останавливает работу главного потока, предотвращая сбой, который происходит во время очистки. Очистка не будет выполнена, поэтому журналы отката будут продолжать расти. |
| 3 | (SRV_FORCE_NO_TRX_UNDO) не отменяет транзакции после восстановления от сбоя. Не влияет на отмену текущих активных транзакций. Также предотвращает выполнение некоторых фоновых задач, генерирующих откат. Эти задачи могут столкнуться с ожиданием блокировки из-за восстановленных неполных транзакций, отмена которых предотвращается. |
| 4 | (SRV_FORCE_NO_IBUF_MERGE) То же, что и 3. |
| 5 | (SRV_FORCE_NO_UNDO_LOG_SCAN) обрабатывает незавершенные транзакции как завершенные и не анализирует журналы отката при запуске. |
| 6 | (SRV_FORCE_NO_LOG_REDO) не выполняет прокрутку вперед журнала редо в рамках восстановления. Запросы, требующие индексов, вероятно, завершатся ошибкой при активном режиме. Однако, если выгрузка таблицы все равно приведет к сбою, можно попробовать использовать SELECT * FROM tab ORDER BY primary_key DESC для выгрузки всех данных после поврежденной части. |
| Режим | Описание |
|---|---|
| 0 | По умолчанию, когда InnoDB работает в нормальном режиме. Транзакции записи разрешены при innodb_force_recovery<=4. |
| 1 | (SRV_FORCE_IGNORE_CORRUPT) позволяет серверу продолжать работу, даже если обнаружены поврежденные страницы. Это достигается путем игнорирования определенных ошибок в восстановлении на основе журнала редо, таких как отсутствие файлов данных или поврежденные страницы данных. Любой журнал редо для затронутых файлов или страниц будет пропущен. Вы можете облегчить выгрузку таблиц, выполнив оператор SELECT * FROM table_name, чтобы пропустить поврежденные индексы и страницы. |
| 2 | (SRV_FORCE_NO_BACKGROUND) останавливает работу главного потока, предотвращая сбой, который происходит во время очистки. Очистка не будет выполнена, поэтому журналы отката будут продолжать расти. |
| 3 | (SRV_FORCE_NO_TRX_UNDO) не отменяет транзакции DML после восстановления от сбоя. Не влияет на отмену текущих активных транзакций DML. Также предотвращает выполнение некоторых фоновых задач, генерирующих откат. Эти задачи могут столкнуться с ожиданием блокировки из-за восстановленных неполных транзакций, отмена которых предотвращается. |
| 4 | (SRV_FORCE_NO_DDL_UNDO) не отменяет транзакции после восстановления от сбоя. Не влияет на отмену текущих активных транзакций. Также предотвращает выполнение некоторых фоновых задач, генерирующих откат. Эти задачи могут столкнуться с ожиданием блокировки из-за восстановленных неполных транзакций, отмена которых предотвращается. |
| 5 | (SRV_FORCE_NO_UNDO_LOG_SCAN) обрабатывает незавершенные транзакции как завершенные и не анализирует журналы отката при запуске. Любой журнал DDL для таблиц InnoDB будет по существу проигнорирован InnoDB, но сервер запустится. |
| 6 | (SRV_FORCE_NO_LOG_REDO) не выполняет прокрутку вперед журнала редо в рамках восстановления. Запросы, требующие индексов, вероятно, завершатся ошибкой при активном режиме. Однако, если выгрузка таблицы все равно приведет к сбою, можно попробовать использовать SELECT * FROM tab ORDER BY primary_key DESC для выгрузки всех данных после поврежденной части. |
Также обратите внимание, что XtraDB (<= MariaDB 10.2.6) по умолчанию завершит работу сервера при обнаружении поврежденных данных в пространстве имен одной таблицы. Это поведение можно изменить — см. системную переменную innodb_corrupt_table_action.
Решение проблем
Попробуйте установить innodb_force_recovery в 1 и запустить mariadb. Если это не сработает, попробуйте значение "2". Если значение 2 работает, есть шанс, что единственное повреждение, которое у вас было, находится в журналах отката InnoDB. Если это запустит mariadb, вы сможете выгрузить базу данных с помощью mariadb-dump. Вы можете проверить любые другие проблемы с таблицами, выполнив mariadb-check --all-databases.
Если вам удалось успешно выгрузить базы данных или у вас были ранее хорошие резервные копии, удалите базы данных с командной строки mariadb, например, "DROP DATABASE yourdatabase". Остановите mariadb. Перейдите в /var/lib/mysql (или в место расположения каталога данных mysql) и выполните "rm -i ib*". Запустите mariadb, создайте базы данных, которые вы удалили ("CREATE DATABASE yourdatabase"), а затем импортируйте последние выгрузки: "mysql < mydatabasedump.sql"
© 2023 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.
https://mariadb.com/kb/en/innodb-recovery-modes/
