Documentation Home
MySQL 5.7 参考手册

13.4.2.5 START SLAVE 语句

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一起或单独启动复制线程。该语句需要 SUPER特权。START SLAVE导致正在进行的事务的隐式提交（请参阅第 13.3.3 节，“导致隐式提交的语句”）。

对于线程类型选项，您可以指定 IO_THREAD、SQL_THREAD、这两个选项，或两者都不指定。只有启动的线程才会受该语句影响。

  • START SLAVE没有线程类型选项会启动所有复制线程， START SLAVE两个线程类型选项也是如此。

  • IO_THREAD启动复制接收器线程，它从源服务器读取事件并将它们存储在中继日志中。

  • SQL_THREAD启动复制应用程序线程，该线程从中继日志中读取事件并执行它们。多线程副本（ slave_parallel_workers> 0）使用协调器线程和多个应用程序线程应用事务，并SQL_THREAD启动所有这些。

重要的

START SLAVE在所有复制线程启动后向用户发送确认。但是，复制接收器线程可能尚未成功连接到源，或者应用程序线程可能在启动后立即应用事件时停止。START SLAVE不会在线程启动后继续监视线程，因此如果它们随后停止或无法连接，它不会警告您。您必须检查副本的错误日志以了解复制线程生成的错误消息，或者检查它们是否以令人满意的方式运行 SHOW SLAVE STATUS。一个成功的START SLAVE语句会导致 SHOW SLAVE STATUS显示 Slave_SQL_Running=Yes，但它可能显示也可能不显示Slave_IO_Running=Yes，因为Slave_IO_Running=Yes仅在接收线程同时运行和连接时显示。有关详细信息，请参阅 第 16.1.7.1 节，“检查复制状态”。

可选子句使您能够命名该语句适用于哪个复制通道。提供一个子句将 语句应用于特定的复制通道。如果没有命名子句并且不存在额外的通道，则该语句适用于默认通道。如果 语句在使用多个通道时没有定义通道，则该语句为所有通道启动指定的线程。有关详细信息，请参阅 第 16.2.2 节，“复制通道”。 FOR CHANNEL channelFOR CHANNEL channelSTART SLAVESTART SLAVE

组复制（group_replication_applier和 group_replication_recovery）的复制通道由服务器实例自动管理。您可以与之交互的唯一组复制通道是 group_replication_applier通道。这个通道只有一个applier线程，没有receiver线程，所以SQL_THREAD 不用IO_THREADoption就可以用option启动。 START SLAVE根本不能与 group_replication_recovery频道一起使用。

START SLAVE supports pluggable user-password authentication (see Section 6.2.13, “Pluggable Authentication”) with the USER, PASSWORD, DEFAULT_AUTH and PLUGIN_DIR options, as described in the following list. When you use these options, you must start the receiver thread (IO_THREAD option) or all the replication threads - you cannot start the replication applier thread (SQL_THREAD option) alone.

USER

The user name for the account. You must set this if PASSWORD is used. The option cannot be set to an empty or null string.

PASSWORD

The password for the named user account.

DEFAULT_AUTH

The name of the authentication plugin. The default is MySQL native authentication.

PLUGIN_DIR

The location of the authentication plugin.

Important

The password that you set using START SLAVE is masked when it is written to MySQL Server’s logs, Performance Schema tables, and SHOW PROCESSLIST statements. However, it is sent in plain text over the connection to the replica server instance. To protect the password in transit, use SSL/TLS encryption, an SSH tunnel, or another method of protecting the connection from unauthorized viewing, for the connection between the replica server instance and the client that you use to issue START SLAVE.

The UNTIL clause makes the replica start replication, then process transactions up to the point that you specify in the UNTIL clause, then stop again. The UNTIL clause can be used to make a replica proceed until just before the point where you want to skip a transaction that is unwanted, and then skip the transaction as described in Section 16.1.7.3, “Skipping Transactions”. To identify a transaction, you can use mysqlbinlog with the source's binary log or the replica's relay log, or use a SHOW BINLOG EVENTS statement.

You can also use the UNTIL clause for debugging replication by processing transactions one at a time or in sections. If you are using the UNTIL clause to do this, start the replica with the --skip-slave-start option to prevent the SQL thread from running when the replica server starts. Remove the option after the procedure is complete, so that it is not forgotten in the event of an unexpected server restart.

The SHOW SLAVE STATUS statement includes output fields that display the current values of the UNTIL condition. The UNTIL condition lasts for as long as the affected threads are still running, and is removed when they stop.

The UNTIL clause operates on the replication applier thread (SQL_THREAD option). You can use the SQL_THREAD option or let the replica default to starting both threads. If you use the IO_THREAD option alone, the UNTIL clause is ignored because the applier thread is not started.

The point that you specify in the UNTIL clause can be any one (and only one) of the following options:

SOURCE_LOG_FILE and SOURCE_LOG_POS

These options make the replication applier process transactions up to a position in its relay log, identified by the file name and file position of the corresponding point in the binary log on the source server. The applier thread finds the nearest transaction boundary at or after the specified position, finishes applying the transaction, and stops there.

RELAY_LOG_FILE and RELAY_LOG_POS

These options make the replication applier process transactions up to a position in the replica’s relay log, identified by the relay log file name and a position in that file. The applier thread finds the nearest transaction boundary at or after the specified position, finishes applying the transaction, and stops there.

SQL_BEFORE_GTIDS

This option makes the replication applier start processing transactions and stop when it encounters any transaction that is in the specified GTID set. The encountered transaction from the GTID set is not applied, and nor are any of the other transactions in the GTID set. The option takes a GTID set containing one or more global transaction identifiers as an argument (see GTID Sets). Transactions in a GTID set do not necessarily appear in the replication stream in the order of their GTIDs, so the transaction before which the applier stops is not necessarily the earliest.

SQL_AFTER_GTIDS

This option makes the replication applier start processing transactions and stop when it has processed all of the transactions in a specified GTID set. The option takes a GTID set containing one or more global transaction identifiers as an argument (see GTID Sets).

With SQL_AFTER_GTIDS, the replication threads stop when they have processed the transactions in the GTID set and encounter the first transaction whose GTID is not part of the GTID set. For example, executing START REPLICA UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 causes the replica 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.

SQL_AFTER_MTS_GAPS

For a multithreaded replica only (with slave_parallel_workers > 0), this option makes the replica process transactions up to the point where there are no more gaps in the sequence of transactions executed from the relay log. When using a multithreaded replica, there is a chance of gaps occurring in the following situations:

  • The coordinator thread is stopped.

  • An error occurs in the applier threads.

  • mysqld shuts down unexpectedly.

When a replication channel has gaps, the replica’s database is in a state that might never have existed on the source. The replica tracks the gaps internally and disallows CHANGE MASTER TO statements that would remove the gap information if they executed.

Issuing START SLAVE on a multithreaded replica with gaps in the sequence of transactions executed from the relay log generates a warning. To correct this situation, the solution is to use START SLAVE UNTIL SQL_AFTER_MTS_GAPS. See Section 16.4.1.32, “Replication and Transaction Inconsistencies” for more information.

如果您需要将失败的多线程副本更改为单线程模式，您可以按照显示的顺序发出以下一系列语句： 

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.slave_parallel_workers = 0;
START SLAVE SQL_THREAD;