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.