Course contentsShow
← Databases & SQL
Lesson 1025 of 1,9539. MySQL and MariaDB EcosystemsFree lesson

Global Transaction Identifiers (GTID)

Utilize GTIDs to simplify replication state management and server recovery.

In this lesson, you will learn how Global Transaction Identifiers (GTIDs) transform database replication from a brittle, position-based process into a robust, identity-based system.

Beyond File Offsets

Before GTIDs, MySQL and MariaDB tracked replication using a (filename, position) coordinate system within the binary log. If a master server failed, you had to manually determine exactly which file and offset the slave was at. This was notoriously error-prone; a slight miscalculation meant missing data or a broken replication stream.

A GTID is a unique identifier assigned to every transaction committed on the master. It follows the format source_id:transaction_id (e.g., 550e8400-e29b-41d4-a716-446655440000:15). Because this ID is permanent and travels with the transaction, the replica knows exactly which transactions it has already processed, regardless of which binary log file they originated in.

Simplifying Recovery and State Management

GTIDs essentially turn replication into a "state-based" model rather than a "log-position" model. This simplifies life for database administrators in two major ways:

  1. Effortless Failover: When promoting a new master, you no longer need to hunt for the master’s binary log position. The new replica simply reports which GTIDs it has executed, and the new master automatically sends only the missing transactions.
  2. Simplified Re-provisioning: If a replica falls out of sync or fails, you don't need complex scripts to find the correct CHANGE MASTER TO coordinates. You simply point the replica to the new master, and it "self-heals" by comparing its own set of executed GTIDs (gtid_executed) against the master.

Code Example: To verify the state of a server using GTIDs, you can check the gtid_executed variable, which shows the range of transactions applied:

-- Check which transactions have been applied
SELECT @@global.gtid_executed;

-- Configuring a replica with GTIDs
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

By enabling MASTER_AUTO_POSITION = 1, the replica handles the entire handshake process, ensuring it never applies the same transaction twice and never misses an update during recovery.

Key Takeaway: GTIDs remove the fragility of log-file positioning, enabling automated failover and self-healing replicas by assigning every transaction a globally unique and traceable identity.