Replication Features and Issues 6. If the last transaction in the relay log is only half-received and the multithreaded replica’s coordinator thread has started to schedule the transaction to a worker, then  STOP REPLICA | SLAVE  waits up to 60 seconds for the transaction to be received. After this timeout, the coordinator gives up and aborts the transaction. If the transaction is mixed, it may be left half-completed. 7. STOP REPLICA | SLAVE  when using a single-threaded replica. If the ongoing transaction only updates transactional tables, it is rolled back and  STOP REPLICA | SLAVE  stops immediately. If the ongoing transaction is mixed,  STOP REPLICA | SLAVE  waits up to 60 seconds for the transaction to complete. After this timeout, it aborts the transaction, so it may be left half-completed. 1. The replica database is in a state that may never have existed on the source. 2. The field  Exec_master_log_pos  in  SHOW REPLICA | SLAVE STATUS  is only a “low-water mark” . In other words, transactions appearing before the position are guaranteed to have committed, but transactions after the position may have committed or not. 3. CHANGE REPLICATION SOURCE TO  and  CHANGE MASTER TO  statements for that channel fail with an error, unless the applier threads are running and the statement only sets receiver options. 4. If  mysqld  is started with  --relay-log-recovery , no recovery is done for that channel, and a warning is printed. 5. If  mysqldump  is used with  --dump-slave , it does not record the existence of gaps; thus it prints CHANGE REPLICATION SOURCE TO  |  CHANGE MASTER TO  with  RELAY_LOG_POS  set to the “low- water mark”  position in  Exec_master_log_pos . 3676 When GTID-based replication is in use, from MySQL 5.7.28 a multithreaded replica checks first whether  MASTER_AUTO_POSITION  is set to  ON , and if it is, omits the step of calculating the transactions that should be skipped or not skipped. In that situation, the old relay logs are not required for the recovery process. RESET REPLICA | SLAVE  removes the relay logs and resets the replication position. Thus issuing  RESET REPLICA | SLAVE  on a replica with gaps means the replica loses any information about the gaps, without correcting the gaps. The source binary log position information is persisted in binary format in the internal table mysql.slave_worker_info .  START REPLICA | SLAVE [SQL_THREAD]  always consults this information so that it applies only the correct transactions. This remains true even if slave_parallel_workers  has been changed to 0 before  START REPLICA | SLAVE , and even if  START REPLICA | SLAVE  is used with  UNTIL  clauses.  START REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS  only applies as many transactions as needed in order to fill in the gaps. If  START REPLICA | SLAVE  is used with  UNTIL  clauses that tell it to stop before it has consumed all the gaps, then it leaves remaining gaps. If a replication channel has source binary log position lag but no gaps, cases 2 to 5 above apply, but case 1 does not. After applying the dump on another server, and starting the replication threads, transactions appearing after the position are replicated again. Note that this is harmless if GTIDs are enabled (however, in that case it is not recommended to use  --dump-slave ). If a replication channel has gaps, it has the following consequences: The global variable  rpl_stop_slave_timeout  is unrelated to the process of stopping the replication threads. It only makes the client that issues  STOP REPLICA | SLAVE  return to the client, but the replication threads continue to try to stop. Warning