The replication SQL or IO thread for a given replication channel is already stopped when START SLAVE/REPLICA is issued.
ER_SLAVE_CHANNEL_WAS_NOT_RUNNING means the replication thread for the specified channel is already stopped, so MySQL ignores START SLAVE. Verify channel name, then run START SLAVE CHANNEL 'name' or restart replication after clearing errors.
ER_SLAVE_CHANNEL_WAS_NOT_RUNNING
MySQL raises ER_SLAVE_CHANNEL_WAS_NOT_RUNNING (error 3084, SQLSTATE HY000) when you execute START SLAVE or START REPLICA for a replication channel whose IO and SQL threads are already stopped. The server treats the request as redundant and reports this warning or error instead of restarting the threads.
The condition was introduced in MySQL 5.7.6 along with multi-source replication channels. Understanding why the channel is inactive helps administrators keep replication healthy and avoid data lag.
The most common trigger is running START SLAVE without checking the channel status. If SHOW SLAVE STATUS shows both threads as No, issuing START SLAVE may return this message because MySQL sees the channel as purposely stopped.
Other causes include scripted failovers that call START SLAVE multiple times, typo-free but wrong channel names, and high-availability tools that retry replication commands after timeouts.
First confirm the exact channel name with SHOW SLAVE STATUS FOR CHANNEL 'name'. If threads are stopped intentionally, simply ignore the message. If they should be running, issue START SLAVE CHANNEL 'name' or START REPLICA CHANNEL 'name' to launch them.
When the channel was stopped due to errors, run SHOW SLAVE STATUS to locate the Last_SQL_Error or Last_IO_Error, correct the underlying problem, then restart replication.
During server restarts, automation may invoke START SLAVE twice, producing this warning. Wrap START commands in a status check to avoid noise.
In multi-source setups, administrators sometimes forget to include CHANNEL 'analytics'. MySQL interprets this as the default channel and returns ER_SLAVE_CHANNEL_WAS_NOT_RUNNING because that default is inactive. Always specify the correct channel.
Check replication thread status before issuing START SLAVE or START REPLICA. Automate using a single idempotent script that only starts channels whose threads are not running.
Monitor SHOW SLAVE STATUS and alert when a channel is stopped longer than tolerated. Tools like Galaxy can integrate these checks directly into query collections, making replication health visible to the whole team.
ER_SLAVE_CHANNEL_ALREADY_RUNNING appears when START SLAVE is executed on a channel that is already active. ER_SLAVE_FATAL_ERROR occurs when replication stops due to unrecoverable issues. Both require status checks and targeted fixes.
An admin previously issued STOP SLAVE CHANNEL 'name', leaving the threads inactive. A later START SLAVE call returns error 3084.
Failover or init scripts may issue START SLAVE multiple times in quick succession, triggering the message on the second call.
Using the default channel when multi-source replication is configured leads MySQL to reference a channel that is intentionally idle.
Raised when START SLAVE is executed on a channel with running threads.
Indicates a critical replication failure that stops the slave thread.
Occurs when the replica cannot read the master's binary log, often due to purged files.
No. ER_SLAVE_CHANNEL_WAS_NOT_RUNNING simply reports that the channel is already stopped. It does not impact other channels or threads.
If the channel should remain inactive, you can ignore it. Otherwise, investigate why the threads are stopped and restart them.
Galaxy lets engineers store replication health queries in shared Collections, ensuring every team member can verify channel status before running START SLAVE.
The condition was introduced in MySQL 5.7.6 and persists in all later 5.7 and 8.0 releases.
.avif)
.avif){kind=logo}
