STOP SLAVE [thread_types] thread_types: [thread_type [, thread_type] ... ] thread_type: IO_THREAD | SQL_THREAD
Stops the slave threads.
SLAVE requires the
SUPER privilege. Recommended best
practice is to execute
STOP SLAVE on the
slave before stopping the slave server (see
Section 5.1.12, “The Server Shutdown Process”, for more information).
When using the row-based logging format:
You should execute
STOP SLAVE or
STOP SLAVE SQL_THREAD on the slave prior to
shutting down the slave server if you are replicating any tables
that use a nontransactional storage engine (see the
Note later in this section).
START SLAVE, this statement
may be used with the
SQL_THREAD options to name the thread or
threads to be stopped.
In MySQL 5.6.7 and later,
STOP SLAVE causes
an implicit commit of an ongoing transaction. See
Section 13.3.3, “Statements That Cause an Implicit Commit”.
Beginning with MySQL 5.6.11,
gtid_next must be set to
AUTOMATIC before issuing this statement (Bug
In MySQL 5.6.13 and later, you can control how long
STOP SLAVE waits before timing out by setting
system variable. This can be used to avoid deadlocks between
STOP SLAVE and other slave SQL statements
using different client connections to the slave. When the
timeout value is reached, the issuing client returns an error
message and stops waiting, but the
instruction remains in effect. Once the slave threads are no
longer busy, the
STOP SLAVE statement is
executed and the slave stops. (Bug #16856735)
If the current replication event group has modified one or more
nontransactional tables, STOP SLAVE waits for up to 60 seconds
for the event group to complete, unless you issue a
KILL QUERY or
statement for the slave SQL thread. If the event group remains
incomplete after the timeout, an error message is logged. (Bug
#319, Bug #38205)
In old versions of MySQL (before 4.0.5), this statement was
SLAVE STOP. That syntax is no longer
accepted as of MySQL 5.6.1.