RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 		 Visa 
4274 3200 2453 6495 

Глава 17. Поиск неисправностей для MySQL Enterprise Backup

Чтобы расследовать проблемы относительно резервной копии и восстановления с продуктом MySQL Enterprise Backup, рассмотрите следующие аспекты:

  • Прежде, чем расследовать любую проблему, ознакомьтесь с известными пределами и ограничениями на продукт в приложении B.

  • Если mysqlbackup сталкивается с проблемами во время требований операционной системы, он возвращает соответствующие коды ошибок OS. Вы, возможно, должны были бы консультироваться с документацией своей операционной системы для значения тех кодов ошибок и как обращаться с ними.

  • Вывод mysqlbackup посылает на stderr вместо stdout. По умолчанию тот же самый вывод направлен в файл журнала в backup_dir для использования в обнаружении ошибок. Посмотрите раздел 20.11 для получения дополнительной информации о том, как формировать эту особенность регистрации.

  • Возрастающие резервные копии, когда выполнены, используя опцию --start-lsn, требуют определения последовательности периодов времени. Необходимо сделать запись заключительного значения LSN в конце каждой резервной копии и определить значение в следующем инкрементном резервном копировании. Необходимо также удостовериться, что полное резервное копирование, которое вы восстанавливаете, подготовлено правильно, чтобы оно содержало все изменения от последовательности возрастающих резервных копий.

  • При работе mysqlbackup он вписывает информацию о прогрессе в таблицу mysql.backup_progress. Когда команда заканчивает операцию резервного копирования, она делает запись информации о статусе в таблицу mysql.backup_history. Можно запросить эти таблицы, чтобы контролировать продолжающиеся задания резервного копирования, видеть, сколько времени использовалось для различных стадий и проверить, произошли ли какие-либо ошибки.

17.1. Коды выхода MySQL Enterprise Backup

MySQL Enterprise Backup возвращает один из следующих кодов выхода при завершении. Значение каждого кода объяснено в таблице 17.1 со связанным выходным сообщением.

Таблица 17.1. Коды выхода и сообщения MySQL Enterprise Backup

Код выходаВыходное сообщение
0Все в порядке
1Неизвестная ошибка
2Внутренняя ошибка
3Один из необходимых файлов поврежден
4Один из необходимых файлов не найден
5Повреждена страница или заголовок
6Несоответствие в конфигурации и значении
7Неправильный аргумент
8Один или больше аргументов неизвестны
9Ошибка операции IO
10Ошибка выделения памяти
11Связь с сервером прервалась
12Продолжающаяся операция прервана пользователем
13У пользователя нет необходимых полномочий
14Нет свободного места на устройстве
15Версия образа не поддерживается этой версией meb
16Значение вне диапазона
17Ошибка Innodb
18Тайм-аут ожидания ресурса
19Сервер возвратил ошибку, выполняя sql

Команда mysqlbackup print-message берет код выхода, поставляемый опцией --error-code, и врзвращает соответствующее выходное сообщение в stdout. Пользователи могут, например, использовать скрипт, чтобы поймать код выхода, возвращенный mysqlbackup, а затем передать его print-message, чтобы получить выходное сообщение. См. описание для print-message .

17.2. Решение проблем с повреждениями

Иногда операционная система или аппаратные средства могут испортить страницу файла данных в местоположении, которое не вызывает ошибку базы данных, но препятствует mysqlbackup:

170225 10:46:18 PCR1INFO: Re-reading page at offset 0 in D:/temp/5.7_source/test/emp2.ibd
170225 10:46:18 PCR1INFO: Re-reading page at offset 0 in D:/temp/5.7_source/test/emp2.ibd
...
170225 10:46:26 PCR1 ERROR: Page at offset 0 in D:/temp/5.7_source/test/emp2.ibd seems corrupt!

У этих проблем могут быть различные причины. Вот некоторые предложения:

  • Проблема может произойти, если сервер MySQL слишком занят. Прежде, чем попробовать другие решения, вы могли бы выполнить резервную копию снова, используя некоторые параметры настройки не по умолчанию для следующих опций mysqlbackup:

    • --page-reread-time=MS. Попробуйте установить значение к, например, 0.05 для быстрого перечитывания во время несовпадений контрольной суммы.

    • --page-reread-count=retry_limit . Попробуйте установить значение к, например, 1000, чтобы позволить больше перечитываний во время несовпадений контрольной суммы прежде, чем MySQL Enterprise Backup сдастся и бросит ошибку.

  • Скремблировавшие данные в памяти могут вызвать проблему даже при том, что данные диска на самом деле не испорчены. Перезагрузите сервер базы данных и устройство хранения данных, чтобы видеть, сохраняется ли проблема.

  • Если проблема сохраняется после того, как сервер базы данных и устройство хранения данных были перезапущены, у вас действительно может быть повреждение на вашем диске. Вы могли бы рассмотреть данные о восстановлении из более ранней резервной копии и накатить недавние изменения, чтобы возвратить базу данных к ее текущему состоянию.

  • Если вы хотите заставить MySQL Enterprise Backup закончить резервную копию так или иначе прежде, чем исследуете первопричину проблемы, можно переписать значения контрольной суммы на диске, управляя утилитой innochecksum:

    innochecksum --no-checksum --write=crc32

    Опция --no-checksum отключит функцию проверки, а --write=crc32 заставляет innochecksum переписать значения контрольной суммы на диске.

ВАЖНО: не рассматривайте проблемы как незначительное раздражение. Узнайте, что не так с системой, в чем причина проблемы, однако, такой поиск неисправностей выходит за рамки этого руководства.

17.3. Использование журналов MySQL Enterprise Backup

Помимо вывода сообщения MySQL Enterprise Backup в stderr и в файл журнала, прогресс и история каждой резервной копии также зарегистрированы в таблицах mysql.backup_progress и mysql.backup_history на поддержанных серверах (чтобы пропустить обновление этих двух таблиц, используйте опцию --no-history-logging).

Таблица backup_progress

Каждая строка таблицы backup_progress делает запись изменения состояния или сообщения от задания резервного копирования. Таблица backup_progress имеет следующие колонки:

mysql> DESCRIBE mysql.backup_progress;
+---------------+---------------+------+-----+----------------------+--------------------------------------------------+
| Field         | Type          | Null | Key | Default              | Extra                                            |
+---------------+---------------+------+-----+----------------------+--------------------------------------------------+
| id            | int           | NO   | PRI | NULL                 | auto_increment                                   |
| backup_id     | bigint        | NO   | MUL | NULL                 |                                                  |
| tool_name     | varchar(4096) | NO   |     | NULL                 |                                                  |
| error_code    | int           | NO   |     | NULL                 |                                                  |
| error_message | varchar(4096) | NO   |     | NULL                 |                                                  |
| current_time  | timestamp(3)  | NO   |     | CURRENT_TIMESTAMP(3) | DEFAULT_GENERATED on update CURRENT_TIMESTAMP(3) |
| current_state | varchar(200)  | NO   |     | NULL                 |                                                  |
+---------------+---------------+------+-----+----------------------+--------------------------------------------------+
7 rows in set (0.00 sec)

MySQL Enterprise Backup 8.0.19 и позже: Таблица backup_progress в формате InnoDB.

MySQL Enterprise Backup 8.0.18 и ранее: Таблица backup_progress в формате CSV. Можно запросить таблицу через клиент mysql или разобрать файл .CSV приложением или скриптом.

Вот некоторые способы использовать информацию в таблице backup_progress:

  • Используйте backup_id, чтобы запросить всю информацию для различных стадий единственной операции резервного копирования и найти соответствующую строку в таблице backup_history для той же самой резервной копии (строка записана в backup_history только после окончания резервной копии).

  • Проверьте столбец tool_name для полной командной строки mysqlbackup, включая все используемые опции.

  • Используйте значения error_code и error_message, чтобы отследить любые ошибки, которые произошли, и видеть, должна ли операция резервного копирования быть закончена из-за каких-либо серьезных ошибок.

  • Используйте значения current_time и current_state, чтобы отследить прогресс операции. Они также позволяют вам узнать, сколько времени каждая стадия резервной копии занимает, что помогает вам планировать ваши будущие резервные копии.

Таблица backup_history

Каждая строка в таблице backup_history делает запись деталей одной законченной резервной копии, созданной командой mysqlbackup. Колонки таблицы backup_history:

mysql> mysql> DESCRIBE mysql.backup_history;
+---------------------------+---------------+------+-----+---------------------+-------+
| Field                     | Type          | Null | Key | Default             | Extra |
+---------------------------+---------------+------+-----+---------------------+-------+
| backup_id                 | bigint(20)    | NO   | PRI | NULL                |       |
| tool_name                 | varchar(4096) | NO   |     | NULL                |       |
| start_time                | timestamp     | NO   |     | 0000-00-00 00:00:00 |       |
| end_time                  | timestamp     | NO   |     | 0000-00-00 00:00:00 |       |
| binlog_pos                | bigint(20)    | NO   |     | NULL                |       |
| binlog_file               | varchar(255)  | NO   |     | NULL                |       |
| compression_level         | int(11)       | NO   |     | NULL                |       |
| engines                   | varchar(100)  | NO   |     | NULL                |       |
| innodb_data_file_path     | varchar(2048) | NO   |     | NULL                |       |
| start_lsn                 | bigint(20)    | NO   |     | NULL                |       |
| end_lsn                   | bigint(20)    | NO   |     | NULL                |       |
| backup_type               | varchar(50)   | NO   |     | NULL                |       |
| backup_format             | varchar(50)   | NO   |     | NULL                |       |
| mysql_data_dir            | varchar(2048) | NO   |     | NULL                |       |
| innodb_data_home_dir      | varchar(2048) | NO   |     | NULL                |       |
| innodb_log_group_home_dir | varchar(2048) | NO   |     | NULL                |       |
| innodb_log_files_in_group | varchar(100)  | NO   |     | NULL                |       |
| innodb_log_file_size      | varchar(100)  | NO   |     | NULL                |       |
| backup_destination        | varchar(4096) | NO   |     | NULL                |       |
| lock_time                 | double(7,3)   | NO   |     | NULL                |       |
| exit_state                | varchar(10)   | NO   |     | NULL                |       |
| last_error                | varchar(4096) | NO   |     | NULL                |       |
| last_error_code           | int(11)       | NO   |     | NULL                |       |
| start_time_utc            | bigint(20)    | NO   |     | NULL                |       |
| end_time_utc              | bigint(20)    | NO   |     | NULL                |       |
| consistency_time_utc      | bigint(20)    | NO   |     | NULL                |       |
| meb_version               | varchar(20)   | NO   |     | 0.0.0               |       |
| server_uuid               | varchar(36)   | NO   |     | NULL                |       |
+---------------------------+---------------+------+-----+---------------------+-------+
28 rows in set (0.01 sec)

Поскольку успешная резервная копия всегда регистрируется как таковая в таблице backup_history, неудача в фазе apply-log команды backup-and-apply-log не отражена в таблице backup_history. Всегда важно проверить вывод mysqlbackup, чтобы видеть, закончена ли операция полностью без ошибки.

Вот информация о некоторых колонках backup_history и некоторые способы использовать эту информацию:

  • tool_name делает запись полной команды mysqlbackup, включая все опции.

  • Можно использовать end_lsn вашей последней резервной копии как стартовый LSN для следующего инкрементного резервного копирования, определяя его с --start-lsn . Альтернатива определению начального значения LSN для инкрементного резервного копирования должна использовать опцию --incremental-base).

  • binlog_pos хранит положение двоичной регистрации, где события регистрации были охвачены резервной копией. Поскольку таблица backup_history раньше была в формате CSV, который не может зарегистрировать значения NULL непосредственно, если двоичная регистрация не позволена, значение -1 введен в колонку, то же самое относится к другим колонкам для значения NULL.

  • backup_type одно из FULL, PARTIAL, DIFFERENTIAL, INCREMENTAL или TTS.

  • backup_format одно из IMAGE (однофайловое копирование) или DIRECTORY (для директивных резервных копий).

  • Используйте значения, которые показывают параметры настройки резервной копии, например, mysql_data_dir, innodb_data_home_dir и backup_destination, чтобы подтвердить, что резервные копии используют правильный источник и каталог назначения.

  • exit_state это SUCCESS или FAILURE. Если exit_state = SUCCESS и last_error = 'NO_ERROR', операция резервного копирования была успешна, когда это будет иметь не так, посмотрите last_error и last_error_code для последней ошибки операции. Чтобы восстановить полный список ошибок для той операции резервного копирования, см. таблицу backup_progress.

17.4. Использование декларации MySQL Enterprise Backup

Каждый резервный каталог включает некоторые файлы в подкаталоге meta, которые детализируют, как резервная копия была создана, и какие файлы это содержит. Файлы, содержащие эту информацию, известны коллективно как декларация.

mysqlbackup производит эти файлы для использования инструментами управления базой данных, он не использует или изменяет файлы декларации после их создания. Инструменты управления могут использовать декларацию во время диагноза и процедур поиска неисправностей, например, если оригинальный экземпляр MySQL был потерян полностью, и процесс восстановления включает более, чем копирование файлов назад к рабочему серверу MySQL.

Файлы в декларации включают:

  • backup_create.xml: информация об операции резервного копирования.

  • backup_content.xml: информация о файлах в резервной копии. Эта информация полна и последовательна только, когда операция резервного копирования имеет успех. Инструмент управления мог бы использовать эту информацию, чтобы подтвердить, какие таблицы часть резервной копии. Инструмент управления мог бы сравнить контрольную сумму, зарегистрированную в декларации для однофайлового резервного копирования против контрольной суммы для файла после того, как однофайловое резервное копирование распаковано. Файл также содержит детали всех плагинов, определенных на поддержанном сервере, причем пользователи должны удостовериться, что те же самые плагины определяются таким же образом на целевом сервере для восстановления.

  • image_files.xml: информация о файлах в однофайловом резервном копировании. Только для резервных копий, взятых с опциями backup-to-image и backup-dir-to-image. Инструмент управления мог бы использовать пути, зарегистрированные в этом файле, чтобы запланировать или автоматизировать распаковку однофайлового резервного копирования, используя команды image-to-backup-dir или extract, либо отобразить пути извлеченных файлов опциями --src-entry и --dst-entry.

Поиск

  

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru