8.3 Восстановление исходной базы данных
Для исправления проблемы с повреждением исходной базы данных репликации вы можете восстановить резервную копию, позаботившись о том, чтобы не распространять ненужные операции SQL на серверы реплик:
Отключите исходную базу данных, а затем, например, используйте команду
copy-back-and-apply-logдля восстановления её резервной копии и подготовки данных.Отредактируйте файл
my.cnfисходного сервера и закомментируйтеlog-bin, чтобы реплики не получали дважды бинарный журнал, необходимый для восстановления источника.-
Репликацию на репликах необходимо временно остановить, пока вы перенаправляете бинарный журнал в исходную базу данных. На репликах выполните:
mysql> STOP REPLICA;
-
Запустите исходный mysqld на восстановленной резервной копии:
$ mysqld … InnoDB: Doing recovery: scanned up to log sequence number 0 64300044 InnoDB: Last MySQL binlog file position 0
5585832, file name ./omnibook-bin.000002…InnoDB выведет файл бинарного журнала (
./omnibook-bin.000002в данном случае) и позицию (5585832в данном случае), до которой он смог восстановиться. -
Перенаправьте оставшиеся файлы бинарного журнала на восстановленный сервер. Количество оставшихся файлов бинарного журнала зависит от продолжительности периода между последней резервной копией и моментом, до которого вы хотите обновить базу данных. Чем длиннее этот период, тем больше может быть оставшихся файлов бинарного журнала. Все файлы бинарного журнала, содержащие все непрерывные позиции бинарного журнала в этот период, необходимы для успешного восстановления.
Вам также необходимо указать начальную позицию в бинарном журнале, с которой следует начать перенаправление событий. Извлеките эту информацию из файла
meta/backup_variables.txtв резервной копии, которую вы только что восстановили на шаге 1 (доступ кbackup_variables.txt, например, перейдя в временную директорию резервной копии, указанную параметром--backup-dirво время восстановления, и найдите файл в папкеmeta): найдите записьbinlog_position=вvaluemeta/backup_variables.txtи передайтеvalueкоманде mysqlbinlog в качестве параметра.ПримечаниеХотя последняя позиция бинарного журнала, восстанавливающаяся, также отображается InnoDB после восстановления (см. шаг 4 выше), это не надёжная информация для определения начальной позиции, которую следует использовать команде mysqlbinlog, так как могут быть события DDL и изменения, не связанные с InnoDB, произошедшие после момента времени, отражённого отображаемой позицией.
Например, если есть ещё два файла бинарного журнала,
omnibook-bin.000003иomnibook-bin.000004, которые следуют заomnibook-bin.000002, и восстановление на шаге 4 завершилось на позиции5585834согласно файлуbackup_variables.txt, перенаправьте бинарный журнал с помощью одного соединения на сервер с помощью этой команды:$ mysqlbinlog --start-position=5585834 /mysqldatadir/omnibook-bin.000002 \ /mysqldatadir/omnibook-bin.000003 /mysqldatadir/omnibook-bin.000004 | mysql
Для получения более подробной информации об использовании mysqlbinlog см. соответствующую документацию.
Исходная база данных теперь восстановлена. Отключите источник и отредактируйте файл
my.cnf, чтобы разкомментироватьlog-bin.Запустите источник ещё раз.
-
Возобновите репликацию на репликах:
mysql> START REPLICA;
© 2025 Oracle
Licensed under the GPLv2 License.