- 12.6.2 SQL Statements for Controlling Slave Servers
- 12.6.2.1 CHANGE MASTER TO Syntax
- 12.6.2.2 LOAD DATA FROM MASTER Syntax
- 12.6.2.3 LOAD TABLE tbl_name FROM MASTER Syntax
- 12.6.2.4 MASTER_POS_WAIT() Syntax
- 12.6.2.5 RESET SLAVE Syntax
- 12.6.2.6 SET GLOBAL SQL_SLAVE_SKIP_COUNTER Syntax
- 12.6.2.7 START SLAVE Syntax
- 12.6.2.8 STOP SLAVE Syntax
STOP SLAVE [thread_type[,thread_type] ... ]thread_type: IO_THREAD | SQL_THREAD
Stops the slave threads. STOP
SLAVE requires the
SUPER privilege.
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.
Note
The transactional behavior of STOP
SLAVE changed in MySQL 5.1.35. Previously, it took
effect immediately; beginning with MySQL 5.1.35, it waits
until the current replication event group (if any) has
finished executing, 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. This usage is still
accepted in MySQL 5.1 for backward compatibility,
but is deprecated.
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.