STOP SLAVE [thread_types]
thread_types:
[thread_type [, thread_type] ... ]
thread_type: IO_THREAD | SQL_THREAD
Stops the replication threads. STOP
SLAVE
requires the
SUPER
privilege. Recommended best
practice is to execute STOP SLAVE
on the
replica before stopping the replica server (see
Section 5.1.15, “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 replica prior to
shutting down the replica server if you are replicating any
tables that use a nontransactional storage engine (see the
Note later in this section).
Like START SLAVE
, this statement
may be used with the IO_THREAD
and
SQL_THREAD
options to name the thread or
threads to be stopped.
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
#16062608).
In MySQL 5.6.13 and later, you can control how long
STOP SLAVE
waits before timing out by setting
the rpl_stop_slave_timeout
system variable. This can be used to avoid deadlocks between
STOP SLAVE
and other SQL statements using
different client connections to the replica. When the timeout
value is reached, the issuing client returns an error message
and stops waiting, but the STOP SLAVE
instruction remains in effect. Once the replication threads are
no longer busy, the STOP SLAVE
statement is
executed and the replica 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 KILL
CONNECTION
statement for the replication 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
called SLAVE STOP
. That syntax is no longer
accepted as of MySQL 5.6.1.