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

  • — Brian Morrison II (PlanetScale, 2023-11-15) gives the canonical best-practices-altitude rationale for GTIDs over binlog file+offset replication: "By default, replicas will read the [binary log] file on a source database and track the processed records based on the position within that file. … This system is relatively fragile as issues can occur if the source crashes and the logs need to be restored. With GTIDs enabled, each transaction is assigned an ID so replicas can concretely determine if a transaction has been processed or not." Canonical wiki framing: the file+offset scheme is not crash-safe across log restore because the offset is a local-file coordinate that the post-restore binlog does not preserve; GTIDs are server-independent logical identifiers that survive crash + restore. Discloses the wire format: single GTID 14a54b2f-2ad0-43b6-b803-72b5d7151d3b:1 or GTID range 14a54b2f-2ad0-43b6-b803-72b5d7151d3b:1-10; each replica stores its executed set in the gtid_executed table. Replication-mode independence: GTIDs work under async, under semi-sync, under mixed-mode topology, and across the unplanned-failover playbook step 4 where replicas are re-pointed at the new primary via CHANGE MASTER TO ... MASTER_AUTO_POSITION=1.

  • sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-7-propagating-requests — canonical wiki disclosure that MySQL's GTID + timestamp binlog metadata is natively sufficient to satisfy the consensus-framework request- versioning requirement for propagation-race resolution — but with a formal caveat. Sugu Sougoumarane: "The MySQL binlogs contain metadata about all transactions. They carry two pieces of relevant information: (1) A Global Transaction ID (GTID), which includes the identity of the leader that created the transaction. (2) A timestamp. This metadata is faithfully propagated to all replicas. This information is sufficient to resolve most ambiguities if conflicting transactions are found due to failures. However, the faithful propagation of the transaction metadata breaks the versioning rule that the decision of a new elector must be recorded under a new timestamp." The MySQL replication substrate satisfies the version-per-request rule at the leader of origin but violates rule (3) (elector- propagation-assigns-new-version) because replicas keep the original leader's GTID + timestamp. The residual- correctness gap is closed operationally via concepts/anti-flapping rules in the external elector (Orchestrator / VTOrc). Canonical production instance of the patterns/external-metadata-for-conflict-resolution pattern. GTID's dual role across the wiki: data-motion primitive (zero-downtime migrations, schema reverts, CDC building block) and consensus-framework versioning primitive (propagation-race resolution at MySQL scale).

  • 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.

  • — 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).

  • — canonicalises GTID as the building block of Vitess's keyspace-wide VGTID. A VGTID is a set of per-shard {keyspace, shard, gtid} entries where each gtid: field is a literal MySQL GTID set (MySQL56/<source_uuid>:<transaction_range>), exactly as used in the 2026-02-16 post's VReplication copy-phase snapshot + COM_BINLOG_DUMP_GTID mechanics — but now wrapped with shard-identity metadata so a CDC consumer can persist a single keyspace-wide checkpoint without maintaining per-shard cursor state. Canonical wiki datum that sharding layers compose MySQL GTIDs into higher-level progress tokens rather than inventing new identity schemes.

  • sources/2026-04-21-planetscale-postgres-high-availability-with-cdc — canonical wiki framing of MySQL GTIDs as the substrate that makes every replica a valid CDC resume point, the structural decoupler of HA from CDC on MySQL. Sam Lambert (PlanetScale CEO, 2025-09-12): "MySQL's binary log is an action log. Every transaction carries a GTID. Replicas with log_replica_updates=ON re-emit transactions they apply into their own binlogs, preserving GTID continuity." The CDC consumer persists its own GTID cursor; "On reconnect it tells any suitable server, 'resume from this GTID.' If the binlog containing that GTID still exists, streaming continues with no slot object and no eligibility gate." Contrasts with Postgres logical replication slots where subscriber-progress metadata lives in a primary-local catalog, not on the consumer side. See patterns/action-log-vs-state-log-replication.

Last updated · 542 distilled / 1,571 read