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

Для запуска реплики с репликацией на основе GTID необходимо включить опцию SOURCE_AUTO_POSITION в операторе CHANGE REPLICATION SOURCE TO. Альтернативные опции SOURCE_LOG_FILE и SOURCE_LOG_POS указывают имя файла журнала и начальную позицию в файле, но с GTID реплике не требуется эта внешняя информация. Полные инструкции по настройке и запуску источников и реплик с использованием репликации на основе GTID см. в разделе 19.1.3.4 «Настройка репликации с использованием GTID».

Опция SOURCE_AUTO_POSITION по умолчанию отключена. Если на реплике включена многоисточниковая репликация, необходимо установить эту опцию для каждого соответствующего канала репликации. Отключение опции SOURCE_AUTO_POSITION снова переводит реплику на файловую репликацию; это означает, что при GTID_ONLY=ON некоторые позиции могут быть помечены как недействительные, в этом случае необходимо также указать SOURCE_LOG_FILE и SOURCE_LOG_POS при отключении SOURCE_AUTO_POSITION.

Когда у реплики включены GTID (GTID_MODE=ON, ON_PERMISSIVE, или OFF_PERMISSIVE) и включена опция SOURCE_AUTO_POSITION, автопозиционирование активируется для подключения к источнику. Источник должен иметь GTID_MODE=ON, чтобы подключение прошло успешно. Во время начального обмена реплика отправляет набор GTID, содержащий транзакции, которые она уже получила, подтвердила или и то, и другое. Этот набор GTID равен объединению набора GTID в системной переменной gtid_executed (@@GLOBAL.gtid_executed) и набора GTID, записанных в таблице Performance Schema replication_connection_status в качестве полученных транзакций (результат оператора SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status).

Источник отвечает, отправляя все транзакции, записанные в его двоичном журнале, GTID которых не входит в набор GTID, отправленный репликой. Для этого источник сначала определяет соответствующий файл двоичного журнала для начала работы, проверяя Previous_gtids_log_event в заголовке каждого из своих файлов двоичного журнала, начиная с последнего. Когда источник находит первый Previous_gtids_log_event, не содержащий транзакций, которых не хватает реплике, он начинает с этого файла двоичного журнала. Этот метод эффективен и занимает значительное время только в том случае, если реплика значительно отстает от источника по количеству файлов двоичного журнала. Затем источник считывает транзакции в этом файле двоичного журнала и последующих файлах до текущего, отправляет транзакции с GTID, которых не хватает реплике, и пропускает транзакции, которые были в наборе GTID, отправленном репликой. Время, прошедшее до получения репликой первой недостающей транзакции, зависит от ее смещения в файле двоичного журнала. Этот обмен гарантирует, что источник отправляет только транзакции с GTID, которые реплика еще не получила или не подтвердила. Если реплика получает транзакции от нескольких источников, как в случае топологии ромба, функция автопропуска гарантирует, что транзакции не применяются дважды.

Если какие-либо из транзакций, которые должен отправить источник, были удалены из двоичного журнала источника или добавлены в набор GTID в системной переменной gtid_purged другим способом, источник отправляет ошибку реплике, и репликация не начинается. GTID отсутствующих удаленных транзакций идентифицируются и перечисляются в журнале ошибок источника в сообщении об ошибке. Реплика не может автоматически восстановиться от этой ошибки, так как части истории транзакций, которые необходимы для догоняния источника, были удалены. Попытка повторного подключения без включенной опции SOURCE_AUTO_POSITION приводит только к потере удаленных транзакций на реплике. Правильный способ восстановления из этой ситуации — для реплики реплицировать недостающие транзакции, указанные в сообщении, из другого источника или заменить реплику новой, созданной из более поздней резервной копии. Рассмотрите возможность пересмотра периода истечения срока действия двоичного журнала (binlog_expire_logs_seconds) на источнике, чтобы предотвратить повторное возникновение ситуации.

Если в процессе обмена транзакциями обнаружится, что реплика получила или подтвердила транзакции с UUID источника в GTID, но сам источник не имеет записи о них, источник отправляет ошибку реплике, и репликация не начинается. Эта ситуация может возникнуть, если источник, у которого не установлено sync_binlog=1, испытывает отключение питания или сбой операционной системы и теряет подтвержденные транзакции, которые еще не были синхронизированы с файлом двоичного журнала, но были получены репликой. Источник и реплика могут разойтись, если какие-либо клиенты подтверждают транзакции на источнике после его перезапуска, что может привести к ситуации, когда источник и реплика используют один и тот же GTID для разных транзакций. Правильный подход к восстановлению из этой ситуации — вручную проверить, разошлись ли источник и реплика. Если один и тот же GTID теперь используется для разных транзакций, необходимо выполнить ручную обработку конфликтов для отдельных транзакций по мере необходимости или удалить либо источник, либо реплику из топологии репликации. Если проблема заключается только в отсутствии транзакций на источнике, можно сделать источник репликой, позволить ему догнать другие серверы в топологии репликации, а затем сделать его источником снова, если это необходимо.

Для многоисточниковой реплики в топологии ромба (где реплика реплицирует данные от двух или более источников, которые, в свою очередь, реплицируют данные от общего источника), при использовании репликации на основе GTID убедитесь, что все фильтры репликации или другие настройки каналов одинаковы во всех каналах многоисточниковой реплики. При репликации на основе GTID фильтры применяются только к данным транзакций, и GTID не отфильтровываются. Это происходит для того, чтобы набор GTID реплики оставался согласованным с набором GTID источника, что означает, что автопозиционирование GTID может использоваться без повторного получения отфильтрованных транзакций каждый раз. В случае, когда реплика уровня ниже является многоисточниковой и получает одну и ту же транзакцию от нескольких источников в топологии ромба, реплика уровня ниже имеет несколько версий транзакции, а результат зависит от того, какой канал применит транзакцию первым. Второй канал, который пытается это сделать, пропускает транзакцию с помощью автопропуска GTID, потому что GTID транзакции был добавлен в набор gtid_executed первым каналом. При одинаковых фильтрах в каналах проблем нет, так как все версии транзакции содержат одни и те же данные, поэтому результаты одинаковы. Однако при разных фильтрах в каналах база данных может стать несогласованной, и репликация может зависнуть.