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 any of USER, PASSWORD, DEFAULT_AUTH, or PLUGIN_DIR, unless
the IO_THREAD option is also provided (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 the slave SQL thread to process transactions until it has
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 thread to process 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, although using IO_THREAD with them
currently has no effect.

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 SQL_THREAD UNTIL SQL_AFTER_GTIDS =
3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56, on the other hand, would
cause the slave SQL 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 SQL
thread.

Prior to MySQL 5.6.14, SQL_AFTER_GTIDS did not stop the slave once the
indicated transaction was 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

