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

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

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

При использовании репликации на основе GTID (gtid_mode=ON), установите GTID_ONLY=1, чтобы реплика использовала только GTIDs в процессе восстановления и перестала сохранять имена и позиции файлов двоичного и ретрансляционного журналов в репозиториях метаданных репликации. Этот параметр устанавливается с помощью инструкции CHANGE REPLICATION SOURCE TO. С GTID_ONLY=1, во время восстановления информация о позиции файла игнорируется, и используется автоматическое пропускание GTID для пропуска транзакций, которые уже были предоставлены, вместо определения правильной позиции файла. Эта стратегия более эффективна при условии, что вы очищаете журналы ретрансляции, используя значение по умолчанию для relay_log_purge, что означает, что необходимо проверить только один файл журнала ретрансляции.

Установите 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 всегда соответствует содержимому журнала ретрансляции, чтобы очистка файлов журнала ретрансляции не могла вызвать незаполненные пробелы в истории транзакций реплики в случае неожиданной остановки.

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

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