Syntax:
START SLAVE [thread_types] [until_option] [connection_options]

thread_types:
    [thread_type [, thread_type] ... ]

thread_type: 
    IO_THREAD | SQL_THREAD

until_option:
    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
          |   MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
          |   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
          |   SQL_AFTER_MTS_GAPS  }

connection_options: 
    [USER='user_name'] [PASSWORD='user_pass'] [DEFAULT_AUTH='plugin_name'] [PLUGIN_DIR='plugin_dir']


gtid_set:
    uuid_set [, uuid_set] ...
    | ''

uuid_set:
    uuid:interval[:interval]...

uuid:
    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

h:
    [0-9,A-F]

interval:
    n[-n]

    (n >= 1) 

START SLAVE with no thread_type options starts both of the slave
threads. The I/O thread reads events from the master server and stores
them in the relay log. The SQL thread reads events from the relay log
and executes them. 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 log, 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.

In MySQL 5.6.7 and later, START SLAVE causes an implicit commit of an
ongoing transaction. See
http://dev.mysql.com/doc/refman/5.6/en/implicit-commit.html.

Beginning with MySQL 5.6.11, gtid_next must be set to AUTOMATIC before
issuing this statement (Bug #16062608).

MySQL 5.6.4 and later supports pluggable user-password authentication
with START SLAVE with the USER, PASSWORD, DEFAULT_AUTH and PLUGIN_DIR
options, as described in the following list:

o USER: User name. Cannot be set to an empty or null string, or left
  unset if PASSWORD is used.

o PASSWORD: Password.

o DEFAULT_AUTH: Name of plugin; default is MySQL native authentication.

o PLUGIN_DIR: Location of plugin.

Starting with MySQL 5.6.4, you cannot use the SQL_THREAD option when
specifying USER, PASSWORD, or both. (Bug #13083642).

See
http://dev.mysql.com/doc/refman/5.6/en/pluggable-authentication.html,
for more information.

If an insecure connection is used with any these options, the server
issues the warning Sending passwords in plain text without SSL/TLS is
extremely insecure.

Starting with MySQL 5.6.6, START SLAVE ... UNTIL supports two
additional options for use with global transaction identifiers (GTIDs)
(see http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html).
Each of these takes a set of one or more global transaction identifiers
gtid_set as an argument (see
http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-concepts.html#
replication-gtids-concepts-gtid-sets, for more information).

When no thread_type is specified, START SLAVE UNTIL SQL_BEFORE_GTIDS
causes both the slave SQL thread to process and the slave I/O thread to
fetch transactions until both of them have reached the first
transaction whose GTID is listed in the gtid_set. START SLAVE UNTIL
SQL_AFTER_GTIDS causes the slave threads to process all transactions
until the last transaction in the gtid_set has been processed by both
threads. In other words, START SLAVE UNTIL SQL_BEFORE_GTIDS causes the
slave SQL to process and I/O threads to fetch all transactions
occurring before the first GTID in the gtid_set is reached, and START
SLAVE UNTIL SQL_AFTER_GTIDS causes the slave threads to handle all
transactions, including those whose GTIDs are found in gtid_set, until
each has encountered a transaction whose GTID is not part of the set.
SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS each support the SQL_THREAD and
IO_THREAD options.

For example, START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS =
3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 causes the slave SQL thread
to process all transactions originating from the master whose
server_uuid is 3E11FA47-71CA-11E1-9E33-C80AA9429562 until it encounters
the transaction having sequence number 11; it then stops without
processing this transaction. In other words, all transactions up to and
including the transaction with sequence number 10 are processed.
Executing START SLAVE IO_THREAD UNTIL SQL_AFTER_GTIDS =
3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56, on the other hand, would
cause the slave I/O thread to obtain all transactions just mentioned
from the master, including all of the transactions having the sequence
numbers 11 through 56, and then to stop without processing any
additional transactions; that is, the transaction having sequence
number 56 would be the last transaction fetched by the slave I/O
thread.

With neither the SQL_THREAD option nor the IO_THREAD option, the
previous statement would cause the slave SQL thread to execute all
transactions originating from this master, including all transactions
with sequence numbers 11 through 56, and then to stop without
processing any additional transactions. The same command would also
cause the slave I/O thread to start. When the SQL thread reaches the
condition, it is stopped. In other words, START SLAVE UNTIL
SQL_BEFORE_GTIDS has the same effect as START SLAVE SQL_THREAD,
IO_THREAD UNTIL SQL_BEFORE_GTIDS; the slave SQL thread and slave I/O
thread are each started, and the SQL thread continues executing
transactions until the stop condition for that thread is met.
(Similarly, START SLAVE UNTIL SQL_AFTER_GTIDS is effectively the same
as START SLAVE SQL_THREAD, IO_THREAD UNTIL SQL_AFTER_GTIDS.)

Prior to MySQL 5.6.14, SQL_AFTER_GTIDS did not stop the slave once the
indicated transaction waa completed, but waited until another GTID
event was received (Bug #14767986).

*Note*: The SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS keywords are present
in the MySQL 5.6.5 server; however, neither of them functioned
correctly as options with START SLAVE [SQL_THREAD | IO_THREAD] UNTIL in
that version, and are therefore supported beginning only with MySQL
5.6.6. (Bug#13810456)

START SLAVE UNTIL SQL_AFTER_MTS_GAPS is available in MySQL 5.6.6 or
later. This statement causes a multi-threaded slave's SQL threads to
run until no more gaps are found in the relay log, and then to stop.
This statement can take an SQL_THREAD option, but the effects of the
statement remain unchanged. It has no effect on the slave I/O thread
(and cannot be used with the IO_THREAD option). START SLAVE UNTIL
SQL_AFTER_MTS_GAPS should be used before switching the slave from
multi-threaded mode to single-threaded mode (that is, when resetting
slave_parallel_workers back to 0 from a positive, nonzero value) after
slave has failed with errors in multi-threaded mode.

To change a failed multi-threaded slave to single-threaded mode, you
can issue the following series of statements, in the order shown:

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;


START SLAVE SQL_THREAD;

If you were running the failed multi-threaded slave with
relay_log_recovery enabled, then you must issue START SLAVE UNTIL
SQL_AFTER_MTS_GAPS prior to executing CHANGE MASTER TO. Otherwise the
latter statement fails.

*Note*: It is possible to view the entire text of a running START SLAVE
... statement, including any USER or PASSWORD values used, in the
output of SHOW PROCESSLIST. This is also true for the text of a running
CHANGE MASTER TO statement, including any values it employs for
MASTER_USER or MASTER_PASSWORD.

URL: http://dev.mysql.com/doc/refman/5.6/en/start-slave.html

