A global transaction identifier (GTID) is a unique identifier created and associated with each transaction when it is committed on the server of origin (master). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication setup. There is a 1-to-1 mapping between all transactions and all GTIDs.
A GTID is represented as a pair of coordinates, separated by a
colon character (
:), as shown here:
source_id identifies the
originating server. Normally, the server's
server_uuid is used for this
purpose. (It is theoretically possible for it to be determined
in a different manner if the source of the transaction is not a
MySQL Server instance, but this is currently not supported.) The
transaction_id is a sequence number
determined by the order in which the transaction was committed
on this server; for example, the first transaction to be
1 as its
transaction_id, and the tenth
transaction to be committed on the same originating server is
10. (It is not possible for a transaction to
0 as a sequence number in a GTID.) Thus,
the twenty-third transaction to be committed originally on the
server having the UUID
3E11FA47-71CA-11E1-9E33-C80AA9429562 has this
This format is used to represent GTIDs in the output of
statements such as
STATUS as well as in the binary log. They can also be
seen when viewing the log file with
or in the output from
As written in the output of statements such as
SHOW MASTER STATUS,
SLAVE STATUS, a sequence of GTIDs originating from the
same server may be collapsed into a single expression, as shown
The example just shown represents the first through fifth
transactions originating on the MySQL Server whose
In MySQL 5.6.6 and later, this format is also used to supply the
argument required by the
uuid_set] ... | ''
GTID sets are used in the MySQL Server in several ways. For
example, the values stored by the
gtid_purged system variables
are represented as GTID sets. In addition, the functions
GTID_SUBTRACT() require GTID sets
GTIDs are always preserved between master and slave. This means that you can always determine the source for any transaction applied on any slave by examining its binary log. In addition, once a transaction with a given GTID is committed on a given server, any subsequent transaction having the same GTID is ignored by that server. Thus, a transaction committed on the master can be applied no more than once on the slave, which helps to guarantee consistency.
When GTIDs are in use, the slave has no need for any nonlocal
data, such as the name of a file on the master and a position
within that file. All necessary information for synchronizing
with the master is obtained directly from the replication data
stream. From the perspective of the database administrator or
developer, GTIDs entirely take the place of the file-offset
pairs previously required to determine points for starting,
stopping, or resuming the flow of data between master and slave.
This means that, when you are using GTIDs for replication, you
do not need (or want) to include
MASTER_LOG_POS options in the
CHANGE MASTER TO statement used
to direct a slave to replicate from a given master; in place of
these options, it necessary only to enable the
MASTER_AUTO_POSITION option introduced in
MySQL 5.6.5. For the exact steps needed to configure and start
masters and slaves using GTID-based replication, see
Section 22.214.171.124, “Setting Up Replication Using GTIDs”.
The generation and lifecycle of a GTID consists of the following steps:
A transaction is executed and committed on the master.
This transaction is assigned a GTID using the master's UUID and the smallest nonzero transaction sequence number not yet used on this server; the GTID is written to the master's binary log (immediately preceding the transaction itself in the log).
After the binary log data is transmitted to the slave and
stored in the slave's relay log (using established
mechanisms for this process—see
Section 16.2, “Replication Implementation”, for details),
the slave reads the GTID and sets the value of its
gtid_next system variable
as this GTID. This tells the slave that the next transaction
must be logged using this GTID.
It is important to note that the slave sets
gtid_next in a session context.
The slave checks to make sure that this GTID has not already been used to log a transaction in its own binary log. If and only if this GTID has not been used, the slave then writes the GTID and applies the transaction (and writes the transaction to its binary log). By reading and checking the transaction's GTID first, before processing the transaction itself, the slave guarantees not only that no previous transaction having this GTID has been applied on the slave, but also that no other session has already read this GTID but has not yet committed the associated transaction. In other words, multiple clients are not permitted to apply the same transaction concurrently.
gtid_next is not
empty, the slave does not attempt to generate a GTID for
this transaction but instead writes the GTID stored in this
variable—that is, the GTID obtained from the
master—immediately preceding the transaction in its