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

Для запуска реплики с помощью репликации на основе GTID не нужно включать параметры MASTER_LOG_FILE или MASTER_LOG_POS в операторе CHANGE MASTER TO, используемом для указания реплике, откуда копировать данные из источника. Эти параметры определяют имя файла журнала и начальную позицию в файле, но реплике с GTID не нужны эти внешние данные. Вместо этого, необходимо включить параметр MASTER_AUTO_POSITION. Полные инструкции по настройке и запуску источников и реплик с помощью репликации на основе GTID см. в разделе 16.1.3.4 «Настройка репликации с использованием GTID».

Параметр MASTER_AUTO_POSITION по умолчанию отключен. Если на реплике включена многоисточниковая репликация, необходимо установить этот параметр для каждого соответствующего канала репликации. Отключение параметра MASTER_AUTO_POSITION возвращает реплику к позиционной репликации.

Когда у реплики включены GTID (GTID_MODE=ON, ON_PERMISSIVE, или OFF_PERMISSIVE) и включен параметр MASTER_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 отсутствующих удалённых транзакций определяются и перечисляются в журнале ошибок источника в сообщении об ошибке. Реплика не может автоматически восстановиться от этой ошибки, потому что части истории транзакций, необходимые для догоняния источника, были удалены. Попытка повторного подключения без включенного параметра MASTER_AUTO_POSITION приводит только к потере удаленных транзакций на реплике. Правильный подход для восстановления в этой ситуации — это заново копировать недостающие транзакции, перечисленные в сообщении, из другого источника, либо заменить реплику новой репликой, созданной на основе более свежей резервной копии. Рассмотрите возможность пересмотра периода истечения срока действия двоичного журнала на источнике, чтобы избежать подобной ситуации в будущем.

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