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

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

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