Стратегия восстановления Основной Основной репликации

Существует два основных подхода для этой проблемы, о которой я знаю. Во-первых при выполнении InnoDB вместо Myisam затем можно сделать резервное копирование в транзакции (-единственная транзакция - lock-tables=FALSE), который объединился с - журналы сброса (не требуемый, но хороший) и - основные данные дадут Вам последовательное резервное копирование с информацией о положении репликации. Журналы сброса сбросят журналы, прежде чем дамп будет создан, что означает, что положение всегда будет 106, и - основные данные исправят имя файла журнала и положение в файле дампа. Конечно, необходимо выполнить это на ведущем устройстве для - основные данные для работы.

Второй путь, который Вы упомянули, состоит в том, чтобы использовать третий хост для создания резервных копий. В этом случае необходимо остановить репликацию, удостоверьтесь, что DB является read_only (хотя действительно, все копии должны быть только для чтения, так как это не производит записи от репликации), и затем создайте резервное копирование И запишите положение репликации. Вы не можете использовать - основные данные в этом случае. Вместо этого Вы могли бы сделать что-то вроде этого:

echo 'stop slave' | mysql {options)
mysqldump {your options} > DB.sql
echo 'show slave status\G' > DB.replication
echo 'start slave' | mysql {options)

Если бы когда-нибудь необходимо восстанавливать от этого резервного копирования, Вы выполнили бы восстановление и затем установили бы репликацию, куда эти два параметра master_log_file и master_log_pos прибывают из файла DB.replication:

master_log_file = value of Master_Log_File
master_log_pos = value of Exec_Master_Log_Pos

Примечание: Вы можете И ДОЛЖНЫ протестировать это от другой копии.

Дополнительное примечание: если у Вас есть пул копий (например, при разделении чтений от записей для веб-приложения), для копий возможно быть вне синхронизации с новым ведущим устройством; это может произойти, если обработка отказа происходит в течение периода тяжелой записи ввод-вывод так как поток копий асинхронно и нет никакой гарантии, что Ваше резервное устройство в той же позиции других копий когда Вы обработка отказа. Однако этого еще не произошло со мной...