This replication error appears when sql_slave_skip_counter is greater than 0 and you attempt to start more than one SQL thread without specifying a channel.
MySQL Error 3086 (ER_SLAVE_CHANNEL_SQL_SKIP_COUNTER) occurs when sql_slave_skip_counter is set and you try to start multiple replication SQL threads. Start only one thread or specify a channel with START SLAVE FOR CHANNEL to resolve the issue.
ER_SLAVE_CHANNEL_SQL_SKIP_COUNTER
The message When sql_slave_skip_counter > 0, it is not allowed to start more than one SQL thread shows that MySQL replication protects the sql_slave_skip_counter variable from concurrent consumption. The counter tells a single SQL thread how many events to skip after a failure. Allowing two threads to share it would corrupt replication state.
The error appears in MySQL 5.7.6 and later, as well as MariaDB versions that support multi-source replication channels. It is triggered only when you issue START SLAVE without restricting the operation to a single channel.
The primary cause is setting sql_slave_skip_counter to a value greater than 0 and then calling START SLAVE without limiting the restart to a single SQL thread or channel. MySQL detects that more than one SQL thread might consume the counter.
It can also occur on servers configured for multi-source replication where global relay log recovery tries to start all channels at once while sql_slave_skip_counter remains set.
Stop replication cleanly, decide which channel needs to consume the counter, and then start only that thread. After the event is skipped, reset the counter to 0 so additional channels can be started.
Scenario 1 - single channel replication: issue STOP SLAVE, set sql_slave_skip_counter, then START SLAVE SQL_THREAD. This starts exactly one SQL thread that will use the counter safely.
Scenario 2 - multi source replication: use START SLAVE FOR CHANNEL 'channel_name' so only the chosen channel consumes the counter, keeping other channels stopped until the skip finishes.
Always reset sql_slave_skip_counter to 0 immediately after the skip succeeds. Automate this with monitoring scripts or stored procedures.
When skipping events on a multi channel replica, specify the channel in every STOP SLAVE and START SLAVE command. Document the workflow so team members do not start all channels accidentally.
Error 1872 (ER_SLAVE_SQL_THREAD_SLIDE_LOG_EVENT) signals issues while skipping events. Error 1755 (ER_SLAVE_FATAL_ERROR) appears if the skipped event is critical. They differ because 3086 focuses on thread count conflicts, while 1872 and 1755 report event processing failures.
Executing START SLAVE without channel scope starts multiple SQL threads and triggers the error.
Failover tools that restart all replication threads overlook the counter value and provoke the conflict.
DBAs may forget to append FOR CHANNEL when working with specific channels, causing accidental parallel starts.
Raised when the SQL thread fails to reposition after skipping events. Fix by checking relay log integrity.
A generic replication fatal error that may follow if the skipped event breaks consistency.
Indicates an invalid MASTER_DELAY setting and is unrelated to skip counters but can appear during replication maintenance.
No. The variable is dynamic and can be set while the replica is running or stopped.
No. Each channel needs its own skip operation executed independently.
If replication stops again before finishing the skip, the counter is not decremented to zero. Clear it manually once done.
Galaxy retains your skip-and-start commands in a shared notebook, letting teammates audit and repeat the exact steps.
.avif)
.avif){kind=logo}
