Stopping only the I/O thread enables the events in the relay log to be executed by the SQL thread up to the point where the relay log ends. This can be useful when you want to pause execution to catch up with events already received from the source, when you want to perform administration on the replica but also ensure that it has processed all updates to a specific point. This method can also be used to pause event receipt on the replica while you conduct administration on the source. Stopping the I/O thread but permitting the SQL thread to run helps ensure that there is not a massive backlog of events to be executed when replication is started again. 

## 17.1.7.3 Skipping Transactions 

If replication stops due to an issue with an event in a replicated transaction, you can resume replication by skipping the failed transaction on the replica. Before skipping a transaction, ensure that the replication I/O thread is stopped as well as the SQL thread. 

First you need to identify the replicated event that caused the error. Details of the error and the last successfully applied transaction are recorded in the Performance Schema table replication_applier_status_by_worker . You can use mysqlbinlog  to retrieve and display the events that were logged around the time of the error. For instructions to do this, see Section 7.5, “Point- in-Time (Incremental) Recovery” . Alternatively, you can issue SHOW RELAYLOG EVENTS  on the replica or SHOW BINLOG EVENTS  on the source. 

Before skipping the transaction and restarting the replica, check these points: 

•Is the transaction that stopped replication from an unknown or untrusted source? If so, investigate the cause in case there are any security considerations that indicate the replica should not be restarted. 

•Does the transaction that stopped replication need to be applied on the replica? If so, either make the appropriate corrections and reapply the transaction, or manually reconcile the data on the replica. 

•Did the transaction that stopped replication need to be applied on the source? If not, undo the transaction manually on the server where it originally took place. 

To skip the transaction, choose one of the following methods as appropriate: 

•When GTIDs are in use ( gtid_mode  is ON ), see Skipping Transactions With GTIDs . 

•When GTIDs are not in use or are being phased in ( gtid_mode  is OFF , OFF_PERMISSIVE , or ON_PERMISSIVE ), see Skipping Transactions Without GTIDs. 

•If you have enabled GTID assignment on a replication channel using the ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS  option of the CHANGE REPLICATION SOURCE TO  statement, see Skipping Transactions Without GTIDs. Using ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS  on a replication channel is not the same as introducing GTID-based replication for the channel, and you cannot use the transaction skipping method for GTID-based replication with those channels. 

To restart replication after skipping the transaction, issue START REPLICA | SLAVE , with the FOR CHANNEL  clause if the replica is a multi-source replica. 

## Skipping Transactions With GTIDs 

When GTIDs are in use ( gtid_mode  is ON ), the GTID for a committed transaction is persisted on the replica even if the content of the transaction is filtered out. This feature prevents a replica from retrieving previously filtered transactions when it reconnects to the source using GTID auto-positioning. It can also be used to skip a transaction on the replica, by committing an empty transaction in place of the failing transaction. 

