Replication with Global Transaction Identifiers •A stored procedure is invoked that commits multiple transactions. One GTID is generated for each transaction that the procedure commits. •A multi-table  DROP TABLE  statement drops tables of different types. Multiple GTIDs can be generated if any of the tables use storage engines that do not support atomic DDL, or if any of the tables are temporary tables. •A  CREATE TABLE ... SELECT  statement is issued when row-based replication is in use ( binlog_format=ROW ). One GTID is generated for the  CREATE TABLE  action and one GTID is generated for the row-insert actions. The  gtid_next  System Variable By default, for new transactions committed in user sessions, the server automatically generates and assigns a new GTID. When the transaction is applied on a replica, the GTID from the server of origin is preserved. You can change this behavior by setting the session value of the  gtid_next  system variable: •When  gtid_next  is set to  AUTOMATIC , which is the default, and a transaction is committed and written to the binary log, the server automatically generates and assigns a new GTID. If a transaction is rolled back or not written to the binary log for another reason, the server does not generate and assign a GTID. •If you set  gtid_next  to a valid GTID (consisting of a UUID and a transaction sequence number, separated by a colon), the server assigns that GTID to your transaction. This GTID is assigned and added to  gtid_executed  even when the transaction is not written to the binary log, or when the transaction is empty. •GTIDs of replicated transactions that were committed with binary logging disabled on the replica. •GTIDs of transactions that were written to a binary log file that has now been purged. •GTIDs that were added explicitly to the set by the statement  SET @@GLOBAL.gtid_purged . 3458 The  gtid_purged  System Variable The set of GTIDs in the  gtid_purged  system variable ( @@GLOBAL.gtid_purged ) contains the GTIDs of all the transactions that have been committed on the server, but do not exist in any binary log file on the server.  gtid_purged  is a subset of  gtid_executed . The following categories of GTIDs are in gtid_purged : It is possible for a client to simulate a replicated transaction by setting  @@SESSION.gtid_next  to a specific GTID before executing the transaction. This technique is used by  mysqlbinlog  to generate a dump of the binary log that the client can replay to preserve GTIDs. A simulated replicated transaction committed through a client is completely equivalent to a replicated transaction committed through a replication applier thread, and they cannot be distinguished after the fact. When replication applier threads apply replicated transactions, they use this technique, setting @@SESSION.gtid_next  explicitly to the GTID of the replicated transaction as assigned on the server of origin. This means the GTID from the server of origin is retained, rather than a new GTID being generated and assigned by the replica. It also means the GTID is added to  gtid_executed  on the replica even when binary logging or replica update logging is disabled on the replica, or when the transaction is a no-op or is filtered out on the replica. Note that after you set  gtid_next  to a specific GTID, and the transaction has been committed or rolled back, an explicit  SET @@SESSION.gtid_next  statement must be issued before any other statement. You can use this to set the GTID value back to  AUTOMATIC  if you do not want to assign any more GTIDs explicitly.