Один из наших клиентов службы поддержки Percona недавно сообщил о сбое Percona XtraBackup с ошибкой повреждения страницы в таблице InnoDB. Заказчик подумал, что это проблема или ошибка в инструменте Percona XtraBackup. После исследования мы обнаружили, что страница InnoDB была действительно повреждена, и инструмент Percona XtraBackup обнаружил ошибку, как и ожидалось, и, следовательно, задание резервного копирования не удалось.
Я подумал, что это будет интересная тема и достойная запись в блоге. В этой статье я опишу инструмент innochecksum , когда и как его использовать, и каковы возможные исправления, если таблица InnoDB страдает от повреждения страницы.
Инструмент innochecksum — это автономный инструмент, который печатает контрольные суммы для файлов InnoDB. Этот инструмент читает файл табличного пространства InnoDB, вычисляет контрольную сумму для каждой страницы и сообщает о несоответствиях, если таковые имеются. Несоответствие контрольной суммы является признаком поврежденных страниц. Будучи автономным инструментом, innochecksum не может использоваться в файле табличного пространства, который используется сервером MySQL в настоящее время, поэтому вам необходимо отключить сервер перед запуском инструмента innochecksum. Если вы попытаетесь запустить инструмент innochecksum на работающем сервере MySQL, есть вероятность, что innochecksum вылетит или сообщит о неверной контрольной сумме для хорошей страницы, что приведет к ошибочным результатам. Существует вероятность того, что при запуске innochecksum для файла табличного пространства, открываемого mysqld, страницы являются грязными и еще не проверены контрольной суммой самим механизмом хранения InnoDB.
Дело в том, что не запускайте innochecksum на работающем сервере.
Повреждение InnoDB может быть вызвано многими факторами (например, потеря питания, неисправное оборудование, ошибки). Механизм хранения InnoDB проверяет вычисленную контрольную сумму при чтении страниц из табличного пространства на диске в сохраненную контрольную сумму на странице. В случае, если InnoDB обнаружит несоответствие контрольной суммы страницы, это приведет к выключению сервера MySQL.
Позвольте мне показать вам ошибку повреждения страницы, обнаруженную Percona XtraBackup во время выполнения резервного копирования, в ходе которого после резервного копирования произошел сбой.
[01]xtrabackup:Database page corruption detected atpage25413,retrying...
[01]xtrabackup:Database page corruption detected atpage25413,retrying...
[01]xtrabackup:Database page corruption detected atpage25413,retrying...Во-первых, нам нужно определить, действительно ли табличное пространство повреждено для этой конкретной таблицы. Я делаю это с помощью утилиты innochecksum, как показано ниже. Как я упоминал ранее, обязательно отключите MySQL перед использованием инструмента innochecksum.
$innochecksum-p25413/path/to/datadir/database_name/table_name.ibdЯ передал флаг -p (page) для innochecksum, чтобы проверить только те страницы, которые были повреждены Percona XtraBackup. Не передавая никакой опции инструменту innochecksum, он проверит все табличное пространство на наличие повреждений, что потребует дополнительного простоя сервера. Инструмент innochecksum также поддерживает параметр -d (отладка) для печати контрольной суммы для каждой страницы и параметр -v (подробный) для печати индикатора прогресса. Вы можете найти более подробную информацию в руководстве . Если инструмент сообщает о повреждении страницы, то таблица базы данных действительно повреждена, как показано ниже.
page25413invalid(fails log sequence number check)Чтобы решить эту проблему, первое, что вы должны попробовать — это mysqldump поврежденной таблицы. Если mysqldump завершился успешно, существует проблема во вторичных индексах для этого табличного пространства. Это связано с тем, что утилита mysqldump не касается индексов, поскольку индексы создаются после вставки всех строк.
Если mysqldump завершается успешно, проблема связана с индексами. Я бы предложил следующие варианты, чтобы исправить коррупцию.
— Выполните OPTIMIZE TABLE для той таблицы, которая перестраивает индексы. Таблица будет заблокирована во время операции до MySQL 5.6.17. Начиная с MySQL 5.6.17 OPTIMIZE TABLE является оперативной операцией.
— Перестройте таблицу с помощью инструмента pt-online-schema-change из Percona Toolkit . Это даст тот же результат, что и OPTIMIZE TABLE, неблокирующим способом, так как инструмент pt-online-schema = change является онлайн-инструментом изменения схемы.
— Отбросьте все вторичные индексы, а затем создайте их заново. Во время этой операции таблица будет заблокирована только для записи. Опять же, вы можете использовать инструмент pt-online-schema-change для этой цели, не жертвуя возможностью чтения / записи в таблицу во время операции удаления и создания индексов.
Наконец, я бы предложил повторно запустить инструмент innochecksum, чтобы снова проверить целостность таблиц, так как это обеспечит отсутствие повреждения страницы. В этом случае мы обнаружили, что таблица действительно была повреждена, и исправление повреждения таблицы с помощью таблицы резервного копирования / перезагрузки устранило проблему, и Percona XtraBackup работала нормально во время следующего запуска.
Возможно, что mysqldump дает сбой серверу MySQL для поврежденной таблицы. К счастью, Percona Server содержит innodb_corrupt_table_action, которую вы можете включить. Переменная конфигурации имеет динамический характер, это означает, что для ее включения не требуется перезапуск сервера MySQL. До версии Percona Server 5.6 innodb_corrupt_table_action было известно как innodb_pass_corrupt_table . Как только вы включите эту опцию, вы можете попробовать mysqldump снова. Если вы используете Oracle MySQL, я бы посоветовал попробовать это с innodb_force_recovery в случае, если mysqldump не сможет вывести содержимое таблицы.
В качестве примечания: если резервное копирование прошло успешно без каких-либо ошибок при выполнении резервного копирования с помощью Percona Xtrabackup, это означает, что в ваших таблицах InnoDB нет несоответствия или повреждения контрольной суммы страницы. Percona XtraBackup может проверять контрольные суммы страниц и в случае ошибок регистрирует ошибки и существует, как я уже упоминал выше.
Существует также модифицированная версия innochecksum, предоставленная Марком Каллаганом из Facebook, и ее можно найти в этом отчете об ошибках, который предоставляет дополнительную статистику для блоков отмены табличного пространства. Существует еще один инструмент, созданный Джереми Коулом от Google, известный как InnoDB Ruby Tool, для проверки внутренних компонентов InnoDB.
ОГРАНИЧЕНИЯ:
- Innochecksum — это автономный инструмент для проверки контрольных сумм InnoDB. Это означает, что вы должны остановить сервер MySQL. В противном случае выдает ошибку «Невозможно заблокировать файл», начиная с MySQL 5.7.
- Старые версии innochecksum поддерживают только файлы размером до 2 ГБ. Однако, поскольку MySQL 5.6 innochecksum поддерживает файлы размером более 2 ГБ.
- Переменная сервера Percona innodb_corrupt_table_action поддерживается для таблиц, существующих в их табличном пространстве (т.е. innodb_file_per_table) .
- Если вы используете сжатые таблицы ( ROW_FORMAT = COMPRESSED ), то вы должны использовать innochecksum из MySQL 5.7.2 или выше, поскольку более ранние версии innochecksum не поддерживают сжатые таблицы. Проверьте эту ошибку для деталей.
Новые функции для инструмента innochecksum из MySQL 5.7:
- Как я уже упоминал выше, поскольку MySQL 5.7 innochecksum поддерживает размеры файлов более 2 ГБ.
- Начиная с MySQL 5.7, вы можете регистрировать вывод с опцией –log.
- Опция -page-type-summary добавлена для резюме типа страницы
- MySQL 5.7 также включает в себя еще одну приятную опцию — page-type-dump, которая выводит детали каждой страницы в стандартный вывод (STDOUT) или стандартную ошибку (STDERR).
- Начиная с MySQL 5.7, innochecksum может выполняться для нескольких пользовательских файлов системных табличных пространств.
- Начиная с MySQL 5.7, innochecksum может выполняться для нескольких файлов системных табличных пространств.
Вы можете прочитать больше об этом в справочной странице MySQL 5.7 innochecksum .
Заключение: в этом посте мы выявили повреждение страницы InnoDB с помощью журналов, созданных Percona XtraBackup, и исправили их с помощью инструмента mysqldump. Но опять же, к сожалению, есть вероятность, что Percona XtraBackup не всегда будет одинаково терпеть неудачу при обнаружении коррупции. Поэтому в некоторых случаях нелегко определить, произошел ли сбой Percona XtraBackup из-за неверной контрольной суммы или ее собственной ошибки. Но в большинстве случаев повреждение страницы является причиной, если Percona XtraBackup не удается завершить.
Подводя итог, я бы сказал, что Percona XtraBackup — это хороший способ проверить, не повреждены ли страницы InnoDB, и вы также можете проверить то же самое с помощью утилиты mysqldump.