STOP SLAVE [thread_types] [channel_option] thread_types: [thread_type [, thread_type] ... ] thread_type: IO_THREAD | SQL_THREAD channel_option: FOR CHANNEL channel
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.17, “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.
STOP SLAVE causes an implicit commit of an
ongoing transaction. See Section 13.3.3, “Statements That Cause an Implicit Commit”.
gtid_next must be set to
AUTOMATIC before issuing this statement.
You can control how long
STOP SLAVE waits
before timing out by setting the
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.
CHANGE MASTER TO statements are allowed
while the slave is running, depending on the states of the slave
SQL and I/O threads. However, using
SLAVE prior to executing
TO in such cases is still supported. See
Section 18.104.22.168, “CHANGE MASTER TO Syntax”, and
Section 17.3.8, “Switching Masters During Failover”, for more
clause enables you
to name which replication channel the statement applies to.
clause applies the
STOP SLAVE statement to a specific
replication channel. If no channel is named and no extra
channels exist, the statement applies to the default channel. If
STOP SLAVE statement does not name a
channel when using multiple channels, this statement stops the
specified threads for all channels. This statement cannot be
used with the
channel. See Section 17.2.3, “Replication Channels” for more
When using statement-based replication:
changing the master while it has open temporary tables is
potentially unsafe. This is one of the reasons why
statement-based replication of temporary tables is not
recommended. You can find out whether there are any temporary
tables on the slave by checking the value of
using statement-based replication, this value should be 0 before
CHANGE MASTER TO. If there are any
temporary tables open on the slave, issuing a
MASTER TO statement after issuing a
SLAVE causes an
When using a multithreaded slave
slave_parallel_workers is a
nonzero value), any gaps in the sequence of transactions
executed from the relay log are closed as part of stopping the
worker threads. If the slave is stopped unexpectedly (for
example due to an error in a worker thread, or another thread
KILL) while a
STOP SLAVE statement is
executing, the sequence of executed transactions from the relay
log may become inconsistent. See
Section 22.214.171.124, “Replication and Transaction Inconsistencies”
for more information.
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.