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

Каждому изменению базы данных (DDL или DML), которое записывается в двоичный журнал, присваивается GTID. Это включает изменения, которые автоматически подтверждаются, и изменения, которые подтверждаются с помощью операторов BEGIN и COMMIT или START TRANSACTION. GTID также присваивается при создании, изменении или удалении базы данных, а также при создании, изменении или удалении объекта базы данных, не являющегося таблицей, такого как процедура, функция, триггер, событие, представление, пользователь, роль или грант.

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

Когда таблица автоматически удаляется сгенерированным оператором в двоичном журнале, оператору присваивается GTID. Временные таблицы удаляются автоматически, когда реплика начинает применять события от источника, который только что был запущен, а также при использовании репликации на основе операторов (binlog_format=STATEMENT) и когда сеанс пользователя, у которого открыты временные таблицы, отключается. Таблицы, использующие хранилище MEMORY, удаляются автоматически при первом обращении к ним после запуска сервера, поскольку строки могли быть потеряны во время завершения работы.

Если транзакция не записывается в двоичный журнал на исходном сервере, сервер не присваивает ей GTID. Это включает транзакции, которые были отменены, и транзакции, которые были выполнены при отключённой записи двоичного журнала на исходном сервере, глобально (с --skip-log-bin, указанным в конфигурации сервера) или для сеанса (SET @@SESSION.sql_log_bin = 0). Это также включает транзакции без действий, когда используется репликация на основе строк (binlog_format=ROW).

Транзакциям XA присваиваются отдельные GTID для фазы XA PREPARE транзакции и фазы XA COMMIT или XA ROLLBACK транзакции. XA-транзакции сохраняются подготовленными, чтобы пользователи могли их подтвердить или отменить в случае сбоя (что в топологии репликации может включать переход к другому серверу). Поэтому две части транзакции дублируются отдельно, поэтому они должны иметь свои собственные GTID, даже если бы транзакция без XA, которая была отменена, не имела бы GTID.

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

По умолчанию для новых транзакций, подтверждённых в пользовательских сеансах, сервер автоматически генерирует и присваивает новый GTID. При применении транзакции на реплике сохраняется GTID с исходного сервера. Вы можете изменить это поведение, установив значение сеанса переменной системы gtid_next:

Обратите внимание, что после установки gtid_next на определённый GTID и транзакция была подтверждена или отменена, перед любым другим оператором должен быть выпущен явный оператор SET @@SESSION.gtid_next. Вы можете использовать это, чтобы вернуть значение GTID к AUTOMATIC, если вы не хотите присваивать больше GTID явно.

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

Клиент может смоделировать дублированную транзакцию, установив @@SESSION.gtid_next на определённый GTID перед выполнением транзакции. Эта техника используется mysqlbinlog для генерации дампа двоичного журнала, который клиент может воспроизвести для сохранения GTID. Дублированная транзакция, смоделированная с помощью клиента, подтвержденная таким способом, полностью эквивалентна транзакции, подтвержденной с помощью потока реплики, и их невозможно отличить задним числом.

Множество GTID в переменной системы gtid_purged (@@GLOBAL.gtid_purged) содержит GTID всех транзакций, которые были выполнены на сервере, но не существуют в любом файле бинарного журнала на сервере. gtid_purged является подмножеством gtid_executed. Следующие категории GTID находятся в gtid_purged:

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

Наборы GTID в переменных системы gtid_executed и gtid_purged инициализируются при запуске сервера. Каждый файл бинарного журнала начинается с события Previous_gtids_log_event, которое содержит множество GTID во всех предыдущих файлах бинарного журнала (составленное из GTID в предыдущем файле Previous_gtids_log_event и GTID каждого Gtid_log_event в предыдущем файле). Содержимое Previous_gtids_log_event в старейшем и самом последнем файлах бинарного журнала используется для вычисления множеств gtid_executed и gtid_purged при запуске сервера:

Если бинарные журналы от MySQL 5.7.7 или более ранних версий участвуют в этих вычислениях, возможно, что для gtid_executed и gtid_purged будут вычислены неправильные множества GTID, и они останутся неправильными даже если сервер будет перезапущен позже. Подробности см. в описании переменной системы binlog_gtid_simple_recovery, которая управляет тем, как бинарные журналы итерируются для вычисления множеств GTID. Если одна из описанных ситуаций применима к серверу, задайте binlog_gtid_simple_recovery=FALSE в файле конфигурации сервера перед его запуском. Это задание заставляет сервер итерировать все файлы бинарного журнала (а не только самые новые и старые), чтобы найти, где появляются события GTID. Этот процесс может занять много времени, если у сервера большое количество файлов бинарного журнала без событий GTID.

Если вам нужно сбросить историю выполнения GTID на сервере, используйте оператор RESET MASTER. Например, вам может потребоваться сделать это после проведения тестовых запросов для проверки настройки репликации на новых серверах с поддержкой GTID или при подключении нового сервера к группе репликации, но он содержит некоторые нежелательные локальные транзакции, которые не принимаются группой репликации.

Перед выполнением RESET MASTER, убедитесь, что у вас есть резервные копии файлов бинарного журнала и файла индекса бинарного журнала сервера (если таковой имеется), и получите и сохраните набор GTID, хранящийся в глобальном значении переменной системы gtid_executed (например, выполнив оператор SELECT @@GLOBAL.gtid_executed и сохранив результаты). Если вы удаляете нежелательные транзакции из этого множества GTID, используйте mysqlbinlog для проверки содержимого транзакций, чтобы убедиться, что они не имеют значения, не содержат данных, которые необходимо сохранить или реплицировать, и не привели к изменениям данных на сервере.

При выполнении RESET MASTER выполняются следующие операции сброса:

Обратите внимание, что RESET MASTER является методом для сброса истории выполнения GTID, даже если сервер является репликой, где запись бинарного журнала отключена. RESET SLAVE не влияет на историю выполнения GTID.