START SLAVE [thread_type[,thread_type] ... ] START SLAVE [SQL_THREAD] UNTIL MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS =log_posSTART SLAVE [SQL_THREAD] UNTIL RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS =log_posthread_type: IO_THREAD | SQL_THREAD
START SLAVE with no
thread_type options starts both of
the slave threads. The I/O thread reads queries from the master
server and stores them in the relay log. The SQL thread reads
the relay log and executes the queries. START
SLAVE requires the SUPER privilege.
If START SLAVE succeeds in starting the slave
threads, it returns without any error. However, even in that
case, it might be that the slave threads start and then later
stop (for example, because they do not manage to connect to the
master or read its binary logs, or some other problem).
START SLAVE does not warn you about this. You
must check the slave's error log for error messages generated by
the slave threads, or check that they are running satisfactorily
with SHOW SLAVE STATUS.
START SLAVE sends an acknowledgement to the
user after both the IO thread and the SQL thread have started.
However, the IO thread may not yet have connected. For this
reason, a successful START SLAVE causes
SHOW SLAVE STATUS to show
Slave_SQL_Running=Yes, but this does not
guarantee that Slave_IO_Running=Yes (because
Slave_IO_Running=Yes only if the IO thread is
running and connected). For more
information, see Section 12.5.6.30, “SHOW SLAVE STATUS Syntax”, and
Section 15.1.4.1, “Checking Replication Status”.
You can add IO_THREAD and
SQL_THREAD options to the statement to name
which of the threads to start.
An UNTIL clause may be added to specify that
the slave should start and run until the SQL thread reaches a
given point in the master binary logs or in the slave relay
logs. When the SQL thread reaches that point, it stops. If the
SQL_THREAD option is specified in the
statement, it starts only the SQL thread. Otherwise, it starts
both slave threads. If the SQL thread is running, the
UNTIL clause is ignored and a warning is
issued.
For an UNTIL clause, you must specify both a
log filename and position. Do not mix master and relay log
options.
Any UNTIL condition is reset by a subsequent
STOP SLAVE statement, a START
SLAVE statement that includes no
UNTIL clause, or a server restart.
The UNTIL clause can be useful for debugging
replication, or to cause replication to proceed until just
before the point where you want to avoid having the slave
replicate a statement. For example, if an unwise DROP
TABLE statement was executed on the master, you can
use UNTIL to tell the slave to execute up to
that point but no farther. To find what the event is, use
mysqlbinlog with the master logs or slave
relay logs, or by using a SHOW BINLOG EVENTS
statement.
If you are using UNTIL to have the slave
process replicated queries in sections, it is recommended that
you start the slave with the --skip-slave-start
option to prevent the SQL thread from running when the slave
server starts. It is probably best to use this option in an
option file rather than on the command line, so that an
unexpected server restart does not cause it to be forgotten.
The SHOW SLAVE STATUS statement includes
output fields that display the current values of the
UNTIL condition.
In old versions of MySQL (before 4.0.5), this statement was
called SLAVE START. This usage is still
accepted in MySQL 6.0 for backward compatibility,
but is deprecated.


User Comments
Useful feature...
Sometimes it's desirable to keep a slave behind the master in the event a bad drop statement causes chaos.
For example to keep a slave behind the master at all times write a script to:
1) get the current master log file and position and save it in a file
2) use the master log file and position from the *previous* run to START SLAVE UNTIL MASTER_LOG_FILE='<log file>', MASTER_LOG_POS=<position>
3) run the script once per hour to keep the slave the behind at least an hour at all times... or every ten minutes to keep it ten minutes behind.
Be sure to add skip-slave-start to your my.cnf
Add your own comment.