GTID (Global Transaction Identifier)

A GTID is a unique, globally consistent identifier assigned to every transaction committed on a MySQL/MariaDB server, composed of the originating server's UUID and a monotonically increasing sequence number. It replaces file-offset-based binlog coordinates as the mechanism for tracking replication position, enabling deterministic, position-independent failover across topologies.

Practical example

An RDS MySQL Multi-AZ failover promotes a standby to primary; because GTID-based replication is enabled, all read replicas automatically reconnect and request only the exact transactions missing from their gtid_executed set, with no manual CHANGE MASTER coordinate calculation required.

Traditional MySQL replication tracked position using (binlog_file, binlog_position) tuples, which are meaningless outside the specific server that generated them. A replica promoted to master after a failover had no reliable way to tell other replicas where to resume, because the new master’s binlog files start their own independent offset sequence. GTIDs solve this by tagging every transaction with a tuple of the form source_uuid:transaction_id (e.g., 3E11FA47-71CA-11E1-9E33-C80AA9429562:23) at commit time, written into the binlog itself. Because the identifier travels with the transaction through relay logs and across any number of hops, a replica can compare its own GTID set (the union of all executed transaction identifiers, tracked in gtid_executed) against a candidate source and compute the exact delta of missing transactions, regardless of file rotation or topology changes.

The practical consequence is CHANGE MASTER TO MASTER_AUTO_POSITION=1: replicas no longer need an operator or orchestration tool to supply exact binlog coordinates after a failover. Tools like Orchestrator, MHA, and group replication rely on this property to perform automated leader election and repointing without manual coordinate surgery. GTID sets also make it possible to safely skip a transaction that fails on one replica (via gtid_next injection of an empty transaction) without desynchronizing the replica’s notion of position, something that was fragile and error-prone under legacy positional replication.

Idempotency risk: a transaction executed twice under two different GTIDs on divergent branches after a bad failover produces errant transactions — GTIDs present on a replica but never on the new source — which will halt replication with a duplicate-GTID conflict and require manual reconciliation (often via gtid_purged manipulation or pt-table-checksum).
Auto-increment and non-deterministic statements: under statement-based replication, functions like UUID() or NOW() can produce divergent results per replica; GTID tracking does not itself solve this — it assumes row-based or otherwise deterministic replication is in use.
Set arithmetic cost: on servers with very long uptime and no binlog purging discipline, gtid_executed can grow into a large sparse set requiring periodic compaction via RESET MASTER combined with careful gtid_purged seeding.
Cross-cluster merges: because the UUID component is tied to server_uuid, cloning a server’s data directory without regenerating auto.cnf produces UUID collisions that corrupt GTID uniqueness guarantees across the fleet.

GTIDs are the enabling primitive underneath MySQL Group Replication, InnoDB Cluster, and most managed offerings’ (Aurora MySQL, Cloud SQL, RDS) automated failover paths, precisely because they turn replication position into an algebraic set operation instead of a filesystem coordinate lookup. Operationally, the failure mode that matters most is errant transaction accumulation after split-brain writes to a demoted primary — detecting this requires comparing GTID sets across all nodes before re-attaching a former primary as a replica, since blind reattachment can either silently drop data or hang replication entirely on a duplicate-transaction error.