Skip to content

CONCEPT Cited by 2 sources

GTID position

Definition

A GTID (Global Transaction Identifier) in MySQL is a unique label for every committed transaction, of the form <source_server_uuid>:<transaction_id>. A GTID set (also called a GTID position) is the set of all GTIDs a server has executed — retrievable via SELECT @@global.GTID_EXECUTED — representing which transactions this server has applied, in a server-independent way.

Crucially, a GTID position is semantically portable across servers because it describes which logical transactions have been applied, not where in the binary log they live. A replica can be pointed at a primary via GTID ("stream me every transaction I haven't executed yet") without needing to know the primary's binlog file/offset. This makes GTIDs the load-bearing primitive for portable replication state — the position means the same thing whether recorded on the primary, on a replica, or in a migration workflow's sidecar storage.

Why this matters for data motion

A GTID position captured atomically with a consistent snapshot (see concepts/consistent-non-locking-snapshot) is the piece of metadata that lets a migration:

  1. Copy the snapshot's rows to a destination.
  2. Tail binlog events from the source starting at exactly that GTID position — neither losing any events that happened after the snapshot (those would be missing on the destination) nor double-applying events that are already in the snapshot (those would corrupt the destination).

Without GTIDs, migrations are pinned to binlog file+offset pairs which drift across primary failover, reset on binlog rotation, and have no meaning on a different server.

The MySQL-specific command COM_BINLOG_DUMP_GTID takes a GTID set as input and streams the binlog events the client is missing — the exact primitive Vitess uses in VReplication's continuous replication phase.

Seen in

  • sources/2026-04-21-planetscale-behind-the-scenes-how-schema-reverts-work — canonical wiki framing of the GTID as the cut-over freeze point marker in online schema changes. Guevara + Noach: "The Vitess migration flow marks the database position at that freeze point." The freeze-point GTID is then re-used by the post-cut-over inverse-replication stream as its well-defined origin — "The revert process tracks ongoing changes to the table and applies them to a shadow table" starting exactly from the freeze-point GTID. The GTID is the shared reference point that makes both the forward swap and the inverse replication stream coherent, without which the revert mechanism would have no well-defined "tables were equivalent" origin.

  • sources/2026-02-16-planetscale-zero-downtime-migrations-at-petabyte-scale — canonical wiki description of two uses of the GTID position in zero-downtime migrations: (1) captured at snapshot opening via @@global.GTID_EXECUTED so the follow-on binlog replication knows where to start; (2) advanced and persisted in the VReplication sidecar vreplication table on every event-batch commit so a stream can always restart from exactly-where-it-left-off. Matt Lord explicitly names COM_BINLOG_DUMP_GTID as the MySQL protocol command Vitess issues to stream events from a given GTID position forward. GTID positions are also the mechanism VDiff uses to make source and target-shard snapshots correspond to the same logical point in time — each target shard's stream runs until it reaches the source's captured GTID, then stops (equivalent to MySQL's START REPLICA UNTIL).

Last updated · 319 distilled / 1,201 read