Syntax:
START {REPLICA | 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
          |   SOURCE_LOG_FILE = 'log_name', SOURCE_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 REPLICA | SLAVE starts one or both of the replication threads.
From MySQL 8.0.22, use START REPLICA in place of START SLAVE, which is
deprecated from that release. In releases before MySQL 8.0.22, use
START SLAVE.

START REPLICA | SLAVE with no thread_type options starts both of the
replication threads. The replication I/O thread reads events from the
source server and stores them in the relay log. The replication SQL
thread reads events from the relay log and executes them. START REPLICA
| SLAVE requires the REPLICATION_SLAVE_ADMIN privilege (or the
deprecated SUPER privilege).

If START REPLICA | SLAVE succeeds in starting the replication threads,
it returns without any error. However, even in that case, it might be
that the replication threads start and then later stop (for example,
because they do not manage to connect to the source or read its binary
log, or some other problem). START REPLICA | SLAVE does not warn you
about this. You must check the replica's error log for error messages
generated by the replication threads, or check that they are running
satisfactorily with SHOW REPLICA | SLAVE STATUS.

START REPLICA | 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 REPLICA | 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 REPLICA | 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 an SQL
thread. Specifying the IO_THREAD or SQL_THREAD options when you start
this channel has no benefit.

START REPLICA | SLAVE supports pluggable user-password authentication
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.

For more information, see
https://dev.mysql.com/doc/refman/8.0/en/pluggable-authentication.html.

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 REPLICA | 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 REPLICA | SLAVE UNTIL
SQL_BEFORE_GTIDS causes the replication SQL thread to process
transactions until it has reached the first transaction whose GTID is
listed in the gtid_set. START REPLICA | SLAVE UNTIL SQL_AFTER_GTIDS
causes the replication threads to process all transactions until the
last transaction in the gtid_set has been processed by both threads. In
other words, START REPLICA | SLAVE UNTIL SQL_BEFORE_GTIDS causes the
replication SQL thread to process all transactions occurring before the
first GTID in the gtid_set is reached, and START REPLICA | SLAVE UNTIL
SQL_AFTER_GTIDS causes the replication 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 REPLICA | SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS =
3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 causes the replication SQL
thread to process all transactions originating from the source 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 REPLICA | SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS =
3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56, on the other hand, would
cause the replication SQL thread to obtain all transactions just
mentioned from the source, 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 replication SQL
thread.

When using a multithreaded replica 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 REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS statement to
cause a multithreaded replica'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 replication I/O thread (and cannot
be used with the IO_THREAD option).

Issuing START REPLICA | SLAVE on a multithreaded replica 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 REPLICA |
SLAVE UNTIL SQL_AFTER_MTS_GAPS, then issue RESET REPLICA | 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 replica to single-threaded mode, you
can issue the following series of statements, in the order shown:

START {REPLICA | SLAVE} UNTIL SQL_AFTER_MTS_GAPS;


START {REPLICA | SLAVE} SQL_THREAD;

*Note*:

It is possible to view the entire text of a running START REPLICA |
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 REPLICATION SOURCE TO | CHANGE MASTER TO statement, including
any values it employs for SOURCE_USER | MASTER_USER or SOURCE_PASSWORD
| MASTER_PASSWORD.

URL: https://dev.mysql.com/doc/refman/8.0/en/start-replica.html

