Replication with Global Transaction Identifiers Restoring GTID mode replicas.   When restoring a replica in a GTID based replication setup that has encountered an error, injecting an empty transaction may not solve the problem because an event does not have a GTID. Use  mysqlbinlog  to find the next transaction, which is probably the first transaction in the next log file after the event. Copy everything up to the  COMMIT  for that transaction, being sure to include the  SET @@SESSION.gtid_next . Even if you are not using row-based replication, you can still run binary log row events in the command line client. Stop the replica and run the transaction you copied. The  mysqlbinlog  output sets the delimiter to  /*! */; , so set it back: mysql>  DELIMITER ; Restart replication from the correct position automatically: From MySQL 8.0.23, you can set up replication channels to assign a GTID to replicated transactions that do not already have one. This feature enables replication from a source server that does not have GTIDs enabled and does not use GTID-based replication, to a replica that has GTIDs enabled. If it is possible to enable GTIDs on the replication source server, as described in Section 17.1.4, “Changing GTID Mode on Online Servers” , use that approach instead. This feature is designed for replication source servers where you cannot enable GTIDs. Note that as is standard for MySQL replication, this feature does not support replication from MySQL source servers earlier than the previous release series, so MySQL 5.7 is the earliest supported source for a MySQL 8.0 replica. You can enable GTID assignment on a replication channel using the ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS  option of the  CHANGE REPLICATION SOURCE TO statement.  LOCAL  assigns a GTID including the replica’s own UUID (the  server_uuid  setting).  uuid assigns a GTID including the specified UUID, such as the  server_uuid  setting for the replication source server. Using a nonlocal UUID lets you differentiate between transactions that originated on the replica and transactions that originated on the source, and for a multi-source replica, between transactions that originated on different sources. If any of the transactions sent by the source do have a GTID already, that GTID is retained. A replica set up with  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS  on any channel cannot be promoted to replace the replication source server in the event that a failover is required, and a backup taken from the replica cannot be used to restore the replication source server. The same restriction applies to replacing or restoring other replicas that use  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS on any channel. The replica must have  gtid_mode=ON  set, and this cannot be changed afterwards, unless you remove the  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS=ON  setting. If the replica server is started without GTIDs enabled and with  ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS  set for any replication 3467 Important 17.1.3.6 Replication From a Source Without GTIDs to a Replica With GTIDs mysql>  SET GTID_NEXT=automatic; mysql>  RESET SLAVE; mysql>  START SLAVE; Or from MySQL 8.0.22: mysql>  SET GTID_NEXT=automatic; mysql>  RESET REPLICA; mysql>  START REPLICA;