7.3 Восстановление исходной базы данных
Для устранения проблемы повреждения в исходной базе данных репликации можно восстановить резервную копию, позаботившись о том, чтобы не распространять ненужные операции SQL на серверы репликации:
Остановите исходную базу данных, а затем, например, используйте команду
copy-back-and-apply-log, чтобы восстановить резервную копию и подготовить данные.Отредактируйте файл исходной
my.cnfи прокомментируйтеlog-bin, чтобы реплики не получали дважды бинарный журнал, необходимый для восстановления источника.-
Репликацию на репликах необходимо временно остановить, пока вы перенаправляете бинарный журнал в источник. В репликах выполните:
mysql> STOP SLAVE;
-
Запустите исходный 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 SLAVE;
© 2025 Oracle
Licensed under the GPLv2 License.