STOP SLAVE [thread_types]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 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, 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
can this statement be used for a backup that allows for other (application) database operations in parallel (i.e. no locking as per http://bugs.mysql.com/bug.php?id=2264); 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 http://dev.mysql.com/doc/mysql/en/MySQL_Cluster_Backup_Concepts.html
Add your own comment.