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

Для репликации на основе позиции файла процесс восстановления требует точной позиции потока SQL репликации (применителя), показывающей последнюю применённую транзакцию на реплике. На основании этой позиции поток ввода-вывода репликации (приёмник) извлекает из бинарного журнала источника все транзакции, которые должны быть применены к реплике от этого момента.

При использовании репликации на основе GTID (gtid_mode=ON), установите MASTER_AUTO_POSITION=1, что активирует автоматическое позиционирование по GTID для подключения к источнику, чтобы автоматически идентифицировать и извлечь пропущенные транзакции. Этот параметр устанавливается с помощью оператора CHANGE MASTER TO. Если у реплики есть несколько каналов репликации, необходимо установить этот параметр для каждого канала индивидуально. Подробнее о работе автоматического позиционирования по GTID см. раздел 16.1.3.3, «Автоматическое позиционирование по GTID». При использовании репликации на основе позиции файла MASTER_AUTO_POSITION=1 не используется, а вместо этого используется позиция бинарного журнала или журнала ретрансляции для управления началом репликации.

Установите sync_relay_log=1, что инструктирует поток ввода-вывода репликации синхронизировать журнал ретрансляции на диск после записи каждой полученной транзакции в него. Это означает, что запись реплики о текущей позиции, считанной из бинарного журнала источника (в репозитории метаданных источника), никогда не будет опережать запись о сохранённых в журнале ретрансляции транзакциях. Обратите внимание, что, хотя эта настройка наиболее безопасна, она также является самой медленной из-за большого количества операций записи на диск. С sync_relay_log > 1 или sync_relay_log=0 (где синхронизация выполняется операционной системой) в случае непредвиденной остановки реплики могут быть подтверждённые транзакции, которые ещё не были синхронизированы на диск. Такие транзакции могут привести к сбоям в процессе восстановления, если восстанавливающая реплика, исходя из информации, имеющейся в журнале ретрансляции, как последней синхронизированной на диск, попытается извлечь и применить транзакции снова вместо пропуска их. Настройка sync_relay_log=1 особенно важна для многопоточной реплики, где процесс восстановления терпит неудачу, если пробелы в последовательности транзакций не могут быть заполнены информацией в журнале ретрансляции. Для однопоточной реплики процесс восстановления использует журнал ретрансляции только в том случае, если соответствующая информация недоступна в репозитории метаданных применяющего модуля.

Установите innodb_flush_log_at_trx_commit=1, что синхронизирует журналы InnoDB на диск перед подтверждением каждой транзакции. Эта настройка, которая является значением по умолчанию, гарантирует, что таблицы InnoDB и журналы InnoDB сохраняются на диске, так что информация в журнале ретрансляции о транзакции больше не требуется. В сочетании с настройкой sync_relay_log=1 эта настройка дополнительно гарантирует, что содержимое таблиц InnoDB и журналов InnoDB всегда соответствует содержимому журнала ретрансляции, чтобы удаление файлов журнала ретрансляции не могло привести к незаполненным пробелам в истории транзакций реплики в случае непредвиденной остановки.

Установите relay_log_info_repository = TABLE, которое хранит позицию потока SQL репликации в таблице InnoDB mysql.slave_relay_log_info и обновляет её вместе с подтверждением транзакции, чтобы гарантировать точность записи. Эта настройка не является значением по умолчанию в MySQL 5.7. Если используется значение по умолчанию FILE, информация хранится в файле в каталоге данных, который обновляется после применения транзакции. Это создаёт риск потери синхронизации с источником в зависимости от стадии обработки транзакции, на которой произошла остановка реплики, или даже повреждения файла самого файла. С настройкой relay_log_info_repository = FILE восстановление не гарантируется.

Установите relay_log_recovery = ON, что включает автоматическое восстановление журнала ретрансляции сразу после запуска сервера. Эта глобальная переменная по умолчанию имеет значение OFF и является только для чтения во время выполнения, но вы можете установить её в ON с помощью опции --relay-log-recovery при запуске реплики после непредвиденной остановки реплики. Обратите внимание, что эта настройка игнорирует существующие файлы журнала ретрансляции, если они повреждены или несогласованы. Процесс восстановления журнала ретрансляции запускает новый файл журнала ретрансляции и извлекает транзакции из источника, начиная с позиции потока SQL репликации, записанной в репозитории метаданных применяющего модуля. Предыдущие файлы журнала ретрансляции удаляются со временем механизмом очистки реплики.