Чтобы расследовать проблемы относительно резервной копии и восстановления с продуктом MySQL Enterprise Backup, рассмотрите следующие аспекты:
Прежде, чем расследовать любую проблему, ознакомьтесь с известными пределами и ограничениями на продукт в приложении B.
Если mysqlbackup сталкивается с проблемами во время требований операционной системы, он возвращает соответствующие коды ошибок OS. Вы, возможно, должны были бы консультироваться с документацией своей операционной системы для значения тех кодов ошибок и как обращаться с ними.
Вывод mysqlbackup посылает на
stderr
вместо stdout
. По умолчанию тот же самый
вывод направлен в файл журнала в backup_dir
для использования в обнаружении ошибок. Посмотрите
раздел 20.11
для получения дополнительной информации о том, как формировать
эту особенность регистрации.
Возрастающие резервные копии, когда выполнены, используя опцию
--start-lsn
,
требуют определения последовательности периодов времени. Необходимо сделать
запись заключительного значения LSN в конце каждой резервной копии и
определить значение в следующем инкрементном резервном копировании.
Необходимо также удостовериться, что полное резервное копирование, которое вы
восстанавливаете, подготовлено правильно, чтобы оно содержало все изменения
от последовательности возрастающих резервных копий.
При работе mysqlbackup он вписывает
информацию о прогрессе в таблицу mysql.backup_progress
.
Когда команда заканчивает операцию резервного копирования, она делает запись
информации о статусе в таблицу mysql.backup_history
.
Можно запросить эти таблицы, чтобы контролировать продолжающиеся задания
резервного копирования, видеть, сколько времени использовалось для различных
стадий и проверить, произошли ли какие-либо ошибки.
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
.
Иногда операционная система или аппаратные средства могут испортить страницу файла данных в местоположении, которое не вызывает ошибку базы данных, но препятствует 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 переписать значения контрольной
суммы на диске.
ВАЖНО: не рассматривайте проблемы как незначительное раздражение. Узнайте, что не так с системой, в чем причина проблемы, однако, такой поиск неисправностей выходит за рамки этого руководства.
Помимо вывода сообщения 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
.
Каждый резервный каталог включает некоторые файлы в подкаталоге
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
.