Common Replication Administration Tasks When you use a  SET GLOBAL sql_slave_skip_counter  statement to skip events and the resulting position is in the middle of an event group, the replica continues to skip events until it reaches the end of the group. Execution then starts with the next event group. The  CHANGE MASTER TO  statement does not have this function, so you must be careful to identify the correct location to restart replication at the beginning of an event group. However, using  CHANGE MASTER TO  means you do not have to count the events that need to be skipped, as you do with a  SET GLOBAL sql_slave_skip_counter , and instead you can just specify the location to restart. When you have assessed the failing transaction for any other appropriate actions as described previously (such as security considerations), count the number of events that you need to skip. One event normally corresponds to one SQL statement in the binary log, but note that statements that use  AUTO_INCREMENT or  LAST_INSERT_ID()  count as two events in the binary log. When binary log transaction compression is in use, a compressed transaction payload ( Transaction_payload_event ) is counted as a single counter value, so all the events inside it are skipped as a unit. If you want to skip the complete transaction, you can count the events to the end of the transaction, or you can just skip the relevant event group. Remember that with  SET GLOBAL sql_slave_skip_counter , the replica continues to skip to the end of an event group. Make sure you do not skip too far forward and go into the next event group or transaction so that it is not also skipped. Issue the  SET  statement as follows, where  N  is the number of events from the source to skip: This statement cannot be issued if  gtid_mode=ON  is set, or if the replication I/O and SQL threads are running. The  SET GLOBAL sql_slave_skip_counter  statement has no immediate effect. When you issue the  START REPLICA | SLAVE  statement for the next time following this  SET  statement, the new value for the system variable  sql_slave_skip_counter  is applied, and the events are skipped. That  START REPLICA | SLAVE  statement also automatically sets the value of the system variable back to 0. If the replica is a multi-source replica, when you issue that  START REPLICA | SLAVE  statement, the  FOR CHANNEL  clause is required. Make sure that you name the correct channel, otherwise events are skipped on the wrong channel. When you have assessed the failing transaction for any other appropriate actions as described previously (such as security considerations), identify the coordinates (file and position) in the source’s binary log that represent a suitable position to restart replication. This can be the start of the event group following the event that caused the issue, or the start of the next transaction. The replication I/O thread begins reading from the source at these coordinates the next time the thread starts, skipping the failing event. Make sure that you have identified the position accurately, because this statement does not take event groups into account. Issue the  CHANGE MASTER TO  statement as follows, where  source_log_name  is the binary log file that contains the restart position, and  source_log_pos  is the number representing the restart position as stated in the binary log file: If the replica is a multi-source replica, you must use the  FOR CHANNEL  clause to name the appropriate channel on the  CHANGE MASTER TO  statement. This statement cannot be issued if  MASTER_AUTO_POSITION=1  is set, or if the replication I/ O and SQL threads are running. If you need to use this method of skipping a transaction when 3583 Skipping Transactions With  CHANGE MASTER TO Skipping Transactions With  SET GLOBAL sql_slave_skip_counter SET GLOBAL sql_slave_skip_counter =  N CHANGE MASTER TO MASTER_LOG_FILE=’ source_log_name ’, MASTER_LOG_POS= source_log_pos ;