Replication with Global Transaction Identifiers it is the UUID of the replica server ( LOCAL ) or a user-specified UUID ( MANUAL ). The information is also recorded in the applier metadata repository. A  RESET SLAVE ALL  statement resets the ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS  setting, but a  RESET SLAVE  statement does not. Because GTID-based replication is dependent on transactions, some features otherwise available in MySQL are not supported when using it. This section provides information about restrictions on and limitations of replication with GTIDs. Updates involving nontransactional storage engines.   When using GTIDs, updates to tables using nontransactional storage engines such as  MyISAM  cannot be made in the same statement or transaction as updates to tables using transactional storage engines such as  InnoDB . This restriction is due to the fact that updates to tables that use a nontransactional storage engine mixed with updates to tables that use a transactional storage engine within the same transaction can result in multiple GTIDs being assigned to the same transaction. Such problems can also occur when the source and the replica use different storage engines for their respective versions of the same table, where one storage engine is transactional and the other is not. Also be aware that triggers that are defined to operate on nontransactional tables can be the cause of these problems. In any of the cases just mentioned, the one-to-one correspondence between transactions and GTIDs is broken, with the result that GTID-based replication cannot function correctly. CREATE TABLE ... SELECT statements.   Prior to MySQL 8.0.21,  CREATE TABLE ... SELECT statements are not allowed when using GTID-based replication. When  binlog_format  is set to STATEMENT , a  CREATE TABLE ... SELECT  statement is recorded in the binary log as one transaction with one GTID, but if  ROW  format is used, the statement is recorded as two transactions with two GTIDs. If a source used  STATEMENT  format and a replica used  ROW  format, the replica would be unable to handle the transaction correctly, therefore the  CREATE TABLE ... SELECT  statement is disallowed with GTIDs to prevent this scenario. This restriction is lifted in MySQL 8.0.21 on storage engines that support atomic DDL. In this case,  CREATE TABLE ... SELECT  is recorded in the binary log as one transaction. For more information, see Section 13.1.1, “Atomic Data Definition Statement Support” . Temporary tables.   When  binlog_format  is set to  STATEMENT ,  CREATE TEMPORARY TABLE  and DROP TEMPORARY TABLE  statements cannot be used inside transactions, procedures, functions, and triggers when GTIDs are in use on the server (that is, when the  enforce_gtid_consistency  system variable is set to  ON ). They can be used outside these contexts when GTIDs are in use, provided that autocommit=1  is set. From MySQL 8.0.13, when  binlog_format  is set to  ROW  or  MIXED ,  CREATE TEMPORARY TABLE  and  DROP TEMPORARY TABLE  statements are allowed inside a transaction, procedure, function, or trigger when GTIDs are in use. The statements are not written to the binary log and are therefore not replicated to replicas. The use of row-based replication means that the replicas remain in sync without the need to replicate temporary tables. If the removal of these statements from a transaction results in an empty transaction, the transaction is not written to the binary log. Preventing execution of unsupported statements.   To prevent execution of statements that would cause GTID-based replication to fail, all servers must be started with the  --enforce-gtid- consistency  option when enabling GTIDs. This causes statements of any of the types discussed previously in this section to fail with an error. Note that  --enforce-gtid-consistency  only takes effect if binary logging takes place for a statement. If binary logging is disabled on the server, or if statements are not written to the binary log because they 3469 17.1.3.7 Restrictions on Replication with GTIDs