MySQL:
START SLAVE
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 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 SLAVE requires the
REPLICATION_SLAVE_ADMIN privilege (or the deprecated SUPER privilege).
If START 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 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 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.
START 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 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 replication 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 replication 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 replication 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 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 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 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 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 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 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 replica to single-threaded mode, you
can issue the following series of statements, in the order shown:
START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.slave_parallel_workers = 0;
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
Example