Вопрос или проблема
Это первый раз, когда я столкнулся с этой проблемой, поэтому ищу помощь в ее решении.
Я управляю сервером Centos 9 Stream, который запускает MariaDB для моего проекта на Laravel 11. Несколько часов назад база данных отключилась, и я не смог перезапустить mariadb. После проверки лога в /var/log/maraidb/mariadb.log там упоминалось о “Поврежденном идентификаторе страницы” и что мне следует установить innodb_force_recovery=1.
Я пошел на это и установил следующее в /etc/my.cnf, а затем выполнил systemctl daemon-reload.
innodb_force_recovery=1
Я смог запустить mariadb. Я оставил это значение на 1 на несколько минут, затем попытался закомментировать его и перезапустить mariadb, и, похоже, все в порядке?
Что мне делать дальше? Боюсь, что это произойдет снова?
Установка innodb_force_recovery действительно решает проблему?
Вот вывод лога перед тем, как это произошло:
2024-11-03 8:43:58 0 [Note] Starting MariaDB 10.11.6-MariaDB source revision fecd78b83785d5ae96f2c6ff340375be803cd299 as process 10029
2024-11-03 8:43:58 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2024-11-03 8:43:58 0 [Note] InnoDB: Number of transaction pools: 1
2024-11-03 8:43:58 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2024-11-03 8:43:58 0 [Note] InnoDB: Using Linux native AIO
2024-11-03 8:43:58 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2024-11-03 8:43:58 0 [Note] InnoDB: Completed initialization of buffer pool
2024-11-03 8:43:58 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
2024-11-03 8:43:58 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=3177494355512
2024-11-03 8:43:58 0 [Note] InnoDB: Multi-batch recovery needed at LSN 3177535143735
2024-11-03 8:43:58 0 [ERROR] InnoDB: Corrupted page identifier at 3177544786030; set innodb_force_recovery=1 to ignore the record.
2024-11-03 8:43:58 0 [Note] InnoDB: End of log at LSN=3177544786030
2024-11-03 8:43:58 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2024-11-03 8:43:58 0 [Note] InnoDB: Starting shutdown...
2024-11-03 8:43:59 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2024-11-03 8:43:59 0 [Note] Plugin 'FEEDBACK' is disabled.
2024-11-03 8:43:59 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2024-11-03 8:43:59 0 [ERROR] Aborting
Ответ или решение
Решение проблемы поврежденного идентификатора страниц в MariaDB
Когда база данных MariaDB неожиданно выходит из строя с ошибкой "Corrupted page identifier", это может вызывать значительные опасения у администраторов. Описание вашей проблемы указывает на потенциальные повреждения в структуре данных InnoDB, что требует внимательного подхода к восстановлению.
Анализ проблемы
Согласно журнальным записям, ошибка возникла во время процесса восстановления инициализации плагина InnoDB, когда произошла попытка достичь контрольной точки (LSN) 3177544786030. Строка с ошибкой Corrupted page identifier сигнализирует о том, что обнаружена ошибка в идентификации страниц, что может быть вызвано аппаратными сбоями, некорректным завершением работы сервера или повреждением файлов таблиц.
Применение параметра innodb_force_recovery
Настройка innodb_force_recovery=1 позволяет базе данных запускаться даже в случае выявления серьезных ошибок, таких как повреждение страниц. Этот параметр следует использовать только как временную меру для доступа к данным и резервного копирования, так как он не исправляет повреждения, а просто игнорирует их. В вашем случае возможность запустить MariaDB с параметром innodb_force_recovery=1 указывает на наличие повреждений.
Рекомендации по дальнейшим действиям
-
Резервное копирование данных:
После того, как вы смогли запустить MariaDB с использованиемinnodb_force_recovery, рекомендуется сразу же создать полную резервную копию базы данных. Используйте такие инструменты, какmysqldump, для создания дампа.mysqldump -u username -p --all-databases > backup.sql -
Постепенное увеличение значения innodb_force_recovery:
Если после временного использования значения1вы столкнетесь с такими же проблемами в будущем, попробуйте увеличить значение параметраinnodb_force_recoveryдо 2 или 3, чтобы получить больше возможностей для восстановления данных. -
Проверка и восстановление таблиц:
После резервного копирования попробуйте выполнить командуREPAIR TABLE. Это может помочь устранить некоторые повреждения.REPAIR TABLE your_table_name; -
Идентификация коренной причины:
Ваша основная задача — выяснить, какие факторы стали причиной повреждения. Просмотрите журналы на наличие предупреждений о аппаратных сбоях, нехватке места на диске или проблемах с файловой системой. -
Переустановка и восстановление:
Если проблема не исчезает, возможно, вам придется создать новую инстанцию MariaDB и восстановить данные из последнего резервного копирования. Это позволит устранить любые структурные повреждения, вызванные неустойчивыми работами сервера. -
Регулярное тестирование резервных копий:
Убедитесь, что ваши резервные копии регулярно проверяются на целостность и работоспособность. Это поможет избежать потери данных в случае неожиданных сбоев. -
Мониторинг состояния системы:
Настройте систему мониторинга для отслеживания производительности и состояния вашего MariaDB сервера, чтобы заранее обнаруживать и минимизировать риски, связанные с возможными сбоями.
Заключение
Использование innodb_force_recovery предоставляет краткосрочные возможности для восстановления доступа к базе данных в условиях повреждения, но не является решением. Ключевым шагом вперед является создание резервных копий и анализ коренной причины проблем. Позаботьтесь о регулярном мониторинге и поддержании целостности вашей базы данных, чтобы предотвратить повторение подобных инцидентов.