Documentation Home
MySQL 5.6 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 31.5Mb
PDF (A4) - 31.6Mb
PDF (RPM) - 30.6Mb
HTML Download (TGZ) - 7.6Mb
HTML Download (Zip) - 7.7Mb
HTML Download (RPM) - 6.6Mb
Man Pages (TGZ) - 187.6Kb
Man Pages (Zip) - 302.1Kb
Info (Gzip) - 2.9Mb
Info (Zip) - 2.9Mb
Excerpts from this Manual STOP SLAVE Syntax

STOP SLAVE [thread_types]

    [thread_type [, thread_type] ... ]

thread_type: IO_THREAD | SQL_THREAD

Stops the slave threads. STOP 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).

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.

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 #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 slave SQL statements using different client connections to the slave. (Bug #16856735)


In MySQL 5.6, STOP SLAVE waits until the current replication event group affecting one or more nontransactional tables has finished executing (if there is any such replication group), or until the user issues a KILL QUERY or KILL CONNECTION statement. (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.

User Comments
  Posted by Ralf Hauser on November 25, 2004
can this statement be used for a backup that allows for other (application) database operations in parallel (i.e. no locking as per; if so, will the user apart from a slight service degradation that e.g. only 1 instead of 2 slaves are available not notice that the backup is happening (in contrast to "mysqlhotcopy ")?

or would one rather need a temporary DISCONNECT or PAUSE SLAVE command for such a backup?

see also
Sign Up Login You must be logged in to post a comment.