Replication with Global Transaction Identifiers •Suggested methods for provisioning new replication servers when using GTIDs (see Section 17.1.3.5, “Using GTIDs for Failover and Scaleout” ). •Restrictions and limitations that you should be aware of when using GTID-based replication (see Section 17.1.3.7, “Restrictions on Replication with GTIDs” ). •Stored functions that you can use to work with GTIDs (see Section 17.1.3.8, “Stored Function Examples to Manipulate GTIDs” ). 3451 The  source_id  identifies the originating server. Normally, the source’s  server_uuid  is used for this purpose. The  transaction_id  is a sequence number determined by the order in which the transaction was committed on the source. For example, the first transaction to be committed has  1  as its transaction_id , and the tenth transaction to be committed on the same originating server is assigned GTID =  source_id : transaction_id A GTID is represented as a pair of coordinates, separated by a colon character ( : ), as shown here: If a transaction with a given GTID has started to execute on a server, but has not yet committed or rolled back, any attempt to start a concurrent transaction on the server with the same GTID blocks. The server neither begins to execute the concurrent transaction nor returns control to the client. Once the first attempt at the transaction commits or rolls back, concurrent sessions that were blocking on the same GTID may proceed. If the first attempt rolled back, one concurrent session proceeds to attempt the transaction, and any other concurrent sessions that were blocking on the same GTID remain blocked. If the first attempt committed, all the concurrent sessions stop being blocked, and auto-skip all the statements of the transaction. The auto-skip function for GTIDs means that a transaction committed on the source can be applied no more than once on the replica, which helps to guarantee consistency. Once a transaction with a given GTID has been committed on a given server, any attempt to execute a subsequent transaction with the same GTID is ignored by that server. No error is raised, and no statement in the transaction is executed. Replicated transactions retain the same GTID that was assigned to the transaction on the server of origin. The GTID is present before the replicated transaction begins to execute, and is persisted even if the replicated transaction is not written to the binary log on the replica, or is filtered out on the replica. The MySQL system table  mysql.gtid_executed  is used to preserve the assigned GTIDs of all the transactions applied on a MySQL server, except those that are stored in a currently active binary log file. GTID assignment distinguishes between client transactions, which are committed on the source, and replicated transactions, which are reproduced on a replica. When a client transaction is committed on the source, it is assigned a new GTID, provided that the transaction was written to the binary log. Client transactions are guaranteed to have monotonically increasing GTIDs without gaps between the generated numbers. If a client transaction is not written to the binary log (for example, because the transaction was filtered out, or the transaction was read-only), it is not assigned a GTID on the server of origin. A global transaction identifier (GTID) is a unique identifier created and associated with each transaction committed on the server of origin (the source). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication topology. For information about MySQL Server options and variables relating to GTID-based replication, see Section 17.1.6.5, “Global Transaction ID System Variables” . See also Section 12.19, “Functions Used with Global Transaction Identifiers (GTIDs)” , which describes SQL functions supported by MySQL 8.0 for use with GTIDs. 17.1.3.1 GTID Format and Storage