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

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']


channel_option:
    FOR CHANNEL channel

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 REPLICATION_SLAVE_ADMIN or
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.

START SLAVE causes an implicit commit of an ongoing transaction. See
https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html.

gtid_next must be set to AUTOMATIC before issuing this statement.

The optional FOR CHANNEL channel clause enables you to name which
replication channel the statement applies to. Providing a FOR CHANNEL
channel clause applies the START SLAVE statement to a specific
replication channel. If no clause is named and no extra channels exist,
the statement applies to the default channel. If a START SLAVE
statement does not have a channel defined when using multiple channels,
this statement starts the specified threads for all channels. This
statement is disallowed for the group_replication_recovery channel. See
https://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for
more information.

You can add IO_THREAD and SQL_THREAD options to the statement to name
which of the threads to start. Note that the Group Replication applier
channel (group_replication_applier) has no I/O thread, only a SQL
thread. Specifying the IO_THREAD or SQL_THREAD options when you start
this channel has no benefit.

MySQL 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.

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.

See
https://dev.mysql.com/doc/refman/8.0/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.

START SLAVE ... UNTIL supports two additional options for use with
global transaction identifiers (GTIDs) (see
https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.html). Each
of these takes a set of one or more global transaction identifiers
gtid_set as an argument (see
https://dev.mysql.com/doc/refman/8.0/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.

When using a multithreaded slave with slave_preserve_commit_order=0
set, there is a chance of gaps in the sequence of transactions that
have been executed from the relay log in the following cases:

o killing the coordinator thread

o after an error occurs in the applier threads

o mysqld shuts down unexpectedly

Use the START SLAVE UNTIL SQL_AFTER_MTS_GAPS statement to cause a
multithreaded slave's worker threads to only 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).

Issuing START SLAVE on a multithreaded slave with gaps in the sequence
of transactions executed from the relay log generates a warning. In
such a situation, the solution is to use START SLAVE UNTIL
SQL_AFTER_MTS_GAPS, then issue RESET SLAVE to remove any remaining
relay logs. See
https://dev.mysql.com/doc/refman/8.0/en/replication-features-transactio
n-inconsistencies.html for more information.

To change a failed multithreaded 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;

*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: https://dev.mysql.com/doc/refman/8.0/en/start-slave.html

