The replica SQL thread did not stop within replication_stop_timeout after receiving a STOP SLAVE signal.
ER_STOP_SLAVE_SQL_THREAD_TIMEOUT signals that the replica SQL thread could not finish its current work before the stop timeout expired. Raise replication_stop_timeout or wait for the thread to complete, then reissue STOP SLAVE to resolve the issue.
ER_STOP_SLAVE_SQL_THREAD_TIMEOUT
MySQL raises error 1875 when the STOP SLAVE or STOP REPLICA command waits longer than replication_stop_timeout for the replica SQL thread to finish its current event batch. The feature was added in 5.7.2 to prevent indefinite waits during replication shutdown.
The message means the SQL thread has acknowledged the stop signal but is still executing statements. Once the timeout expires, MySQL surfaces ER_STOP_SLAVE_SQL_THREAD_TIMEOUT and leaves the thread running.
Long running transactions or heavy DDL on the source can hold the SQL thread past the timeout. Each statement must complete before the thread stops, so large event groups increase wait time.
I/O or network stalls that slow statement apply rates also extend stop waits. Low replication_stop_timeout values make the error more likely on busy replicas.
First, identify whether the SQL thread is still progressing. Check Seconds_Behind_Source and Last_SQL_Error in SHOW REPLICA STATUS. If progress continues, simply wait and re-issue STOP SLAVE once it finishes.
If you must stop replication quickly, raise replication_stop_timeout and try again. For stubborn blocks, kill the blocking query, or skip events with SET GLOBAL sql_slave_skip_counter.
During planned maintenance, replicas running large ALTER TABLE statements often show this error. In that case, allow the statement to finish or change channel to applier stop timeout to a higher value before maintenance.
When a user accidentally runs a massive update on the primary, replicas can take hours to apply it. Temporarily increasing replication_stop_timeout lets STOP SLAVE wait long enough to finish.
Set replication_stop_timeout based on the longest transaction you expect. Values between 300 and 900 seconds work for most workloads.
Monitor long running queries and replica lag with Galaxy or other tools. Galaxy’s live query view helps you detect heavy statements before they block a STOP SLAVE operation.
ER_STOP_SLAVE_IO_THREAD_TIMEOUT (1964) appears when the I/O thread cannot stop within its timeout. ER_REPLICA_SQL_THREAD_STOPPED can follow if you manually kill the SQL thread. Fixes are similar - increase the timeout or wait for completion.
Multi-row updates, deletes, or batch inserts can keep the SQL thread busy for minutes, causing the stop timeout to expire.
ALTER TABLE and OPTIMIZE TABLE operations replicate as single events that must finish before the thread halts.
Slow storage or network latency reduces apply throughput, lengthening the time needed to finish current events.
A default of 30 seconds may be too small for production workloads, leading to frequent timeouts.
Timeout while waiting for the I/O thread to stop. Increase replication_stop_timeout_io to fix.
Indicates the SQL thread has been stopped manually or due to an error. Review Last_SQL_Error for details.
Duplicate key error in the SQL thread that can also block STOP SLAVE until skipped or fixed.
Set the value longer than your typical longest transaction. Many teams use 300-900 seconds in production.
No. MySQL leaves the SQL thread running. Data remains consistent; only the stop request fails.
Killing the thread aborts the current transaction and may require recovery with START REPLICA UNTIL SQL_BEFORE_GTIDS. Use it only when maintenance windows demand immediate stop.
Galaxy highlights long running replica queries and surfaces real-time lag, enabling you to adjust timeouts proactively before issuing STOP SLAVE.
.avif)
.avif){kind=logo}
