The replica IO thread is running while you attempt an operation that needs it stopped.
MySQL error 1906 (ER_SLAVE_IO_THREAD_MUST_STOP) signals that a replication command cannot run because the replica IO thread is still active. Stop the thread with STOP SLAVE IO_THREAD, perform your CHANGE MASTER TO or RESET SLAVE step, then restart replication.
ER_SLAVE_IO_THREAD_MUST_STOP
MySQL raises error 1906 when you issue a replication command that modifies the replication configuration while the IO thread on the replica is still running. The server blocks the change to protect replication integrity.
The message appears mainly with CHANGE MASTER TO, RESET SLAVE, or START SLAVE when issued in an incorrect order. MySQL versions 5.7.4 through 5.7.5 exposed this error code; later versions still enforce the rule but return a generic replication error.
The error fires because MySQL disallows modification of replication settings while the IO thread is actively reading the binary log from the source. Stopping the IO thread ensures a clean state before changes are applied.
Typical triggers include attempting CHANGE MASTER TO to point a replica at a new source, resetting replication while threads run, or switching channels without pausing replication.
Stop the replica IO thread, run the desired replication command, then restart replication. This three-step pattern resolves the error safely in all supported MySQL versions.
Scenario: Migrating a replica to a new primary. Solution: STOP SLAVE IO_THREAD; CHANGE MASTER TO ...; START SLAVE;
Scenario: Cleaning relay logs with RESET SLAVE. Solution: STOP SLAVE; RESET SLAVE; START SLAVE;
Adopt a checklist that always stops replication threads before altering replication configuration. Automate this sequence in deployment scripts to prevent manual mistakes.
Monitor thread status with SHOW PROCESSLIST or performance_schema.replication_connection_status to confirm threads are stopped before proceeding.
Error 1192 - ER_SLAVE_LOCKING_FAILURE: occurs when the SQL thread cannot acquire a lock. Stop both threads, apply the lock fix, then restart.
Error 1593 - ER_SLAVE_RELAY_LOG_READ_FAILURE: indicates relay log read problems. Use FLUSH RELAY LOGS and ensure IO thread is stopped during maintenance.
The most frequent cause. Operators forget to pause the IO thread before redirecting the replica to a new source.
RESET SLAVE purges relay logs and internal metadata. MySQL blocks the command if either replication thread remains active.
Custom scripts may mistakenly call CHANGE MASTER TO directly, especially after upgrades. Insert explicit STOP statements to harden automation.
Raised when the SQL thread cannot obtain a necessary lock. Often fixed by stopping both replication threads before retrying.
Indicates problems reading relay logs, sometimes appearing after disk issues. Requires flushing relay logs and restarting replication.
Appears when a replica cannot connect to its source. Check network, credentials, and SSL parameters.
You only need to stop the IO thread for CHANGE MASTER TO but stopping both threads is safe and ensures consistency.
No. The SQL thread keeps applying events already downloaded. New events are simply paused until the IO thread is restarted.
Yes. Include STOP SLAVE IO_THREAD, CHANGE MASTER TO, and START SLAVE commands in your deployment scripts or Ansible playbooks.
Galaxy’s AI copilot flags replication commands missing STOP SLAVE IO_THREAD in your SQL, and Collections let teams embed safe templates everyone can reuse.
.avif)
.avif){kind=logo}
