<p>The error appears when you run CHANGE MASTER on a multi-threaded replication slave that stopped with unresolved relay log gaps.</p>
<p>MySQL Error 1802: ER_MTS_CHANGE_MASTER_CANT_RUN_WITH_GAPS occurs when CHANGE MASTER is issued on a slave that halted in multi-threaded mode with relay-log gaps. Clear the gaps by START SLAVE UNTIL or RESET SLAVE, then rerun CHANGE MASTER to resolve the problem.</p>
CHANGE MASTER cannot be executed when the slave was
Error 1802 fires when the CHANGE MASTER command is executed on a replication slave that previously stopped with an error or was killed while running in Multi-Threaded Slave (MTS) mode. MySQL detects unresolved relay log gaps and blocks the command.
The server refuses to change master coordinates because doing so while gaps exist could corrupt replication state. Fixing the gap first is mandatory before re-configuring the replication source.
The primary trigger is executing CHANGE MASTER while the slave’s worker threads have not fully processed all relay log events, leaving holes in the executed_gtid_set or log file sequence.
Other causes include abrupt shutdowns, manual KILL of worker threads, disk failures delaying relay log writes, or STOP SLAVE commands issued during heavy parallel replication.
First identify whether gaps exist with SHOW SLAVE STATUS. If Relay_Log_Gap or Retrieved_Gtid_Set is incomplete, either allow the slave to finish processing or start it until a safe point.
Commonly, administrators run START SLAVE UNTIL SQL_BEFORE_GTIDS = 'gtid_set' to catch up, or START SLAVE; WAIT_FOR_EXECUTED_GTID_SET(); then stop the slave cleanly before issuing CHANGE MASTER.
After a crash, replaying relay logs usually eliminates gaps. If relay logs are corrupted, RESET SLAVE removes all local logs and lets the slave fetch a fresh stream from the master.
When migrating to a new source, stop the slave with a controlled STOP SLAVE; flush GTIDs, confirm no gaps, and then apply CHANGE MASTER TO MASTER_HOST='new'.
Always stop the slave cleanly before maintenance. Monitor Relay_Log_Gap and Seconds_Behind_Master metrics. Run CHANGE MASTER only on slaves in a synced or fully stopped state.
Configure skip_slave_start=0 and relay_log_recovery=1 to reduce relay log inconsistencies after unexpected restarts.
Errors 1593 (ER_SLAVE_RELAY_LOG_READ_FAILURE) and 1201 (ER_SLAVE_THREAD_KILLED_BY_MASTER) also stem from relay log or thread issues. They can often be resolved with RESET SLAVE or relay log purge steps similar to error 1802.
Worker threads stopped before finishing queued events, leaving gaps.
Terminating threads mid-transaction interrupts relay log continuity.
Unexpected shutdown prevents orderly relay log flush and causes holes.
Corrupted relay logs break the execution sequence and create gaps.
Indicates the slave could not read the relay log file, often due to corruption or missing file.
Signals that the master requested the slave SQL thread to stop, commonly after failover actions.
Occurs when the slave attempts to execute an event beyond the available relay log coordinate.
No. Forcing the command risks data divergence. Always remove gaps first.
RESET SLAVE deletes local relay logs. Take backups and verify GTID consistency before running it.
Rarely. It mainly affects multi-threaded slaves where parallel workers can leave holes.
Galaxy’s query history and version control make it easy to script orderly STOP SLAVE and CHANGE MASTER sequences, reducing operator mistakes.
.avif)
.avif){kind=logo}
