#### 13.4.2.8 START REPLICA 声明

[](<>)

```
START REPLICA [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)
```

`开始复制`启动一个或两个复制线程。从 MySQL 8.0.22 开始，使用[`开始复制`](start-replica.html)代替[`启动奴隶`](start-slave.html)，该版本已弃用。在 MySQL 8.0.22 之前的版本中，使用[`启动奴隶`](start-slave.html).

`开始复制`没有*`线程类型`*options 启动两个复制线程。复制 I/O（接收者）线程从源服务器读取事件并将它们存储在中继日志中。复制 SQL（应用程序）线程从中继日志中读取事件并执行它们。`开始复制`需要[`REPLICATION_SLAVE_ADMIN`](privileges-provided.html#priv_replication-slave-admin)特权（或已弃用的[`极好的`](privileges-provided.html#priv_super)特权）。

如果`开始复制`成功启动复制线程，它返回没有任何错误。然而，即使在这种情况下，也可能是复制线程启动然后停止（例如，因为它们无法连接到源或读取其二进制日志，或其他一些问题）。`开始复制`不会就此向您发出警告。您必须检查副本的错误日志以获取复制线程生成的错误消息，或者检查它们是否令人满意地运行[`显示副本状态`](show-replica-status.html).

`开始复制`导致正在进行的事务的隐式提交。看[第 13.3.3 节，“导致隐式提交的语句”](implicit-commit.html).

[`gtid_next`](replication-options-gtids.html#sysvar_gtid_next)必须设置为`自动的`在发表此声明之前。

可选的`对于频道 *`渠道`*`子句使您能够命名该语句适用于哪个复制通道。提供一个`对于频道 *`渠道`*`条款适用于`开始复制`声明到特定的复制通道。如果没有指定子句并且不存在额外的通道，则该语句适用于默认通道。如果一个`开始复制`当使用多个通道时，该语句没有定义通道，该语句为所有通道启动指定线程。这种说法是不允许的`group_replication_recovery`渠道。看[第 17.2.2 节，“复制通道”](replication-channels.html)了解更多信息。

你可以加`IO_THREAD`和`SQL_THREAD`语句的选项来命名要启动的线程。请注意，组复制应用程序通道 (`group_replication_applier`) 没有 I/O (receiver) 线程，只有一个 SQL (applier) 线程。指定`IO_THREAD`要么`SQL_THREAD`启动此频道时的选项没有任何好处。

`开始复制`支持可插入的用户密码身份验证`用户`,`密码`,`DEFAULT_AUTH`和`插件目录`选项，如下表所述：

-   `用户`： 用户名。不能设置为空字符串或 null 字符串，或者在以下情况下保持未设置`密码`用来。

-   `密码`： 密码。

-   `DEFAULT_AUTH`: 插件名称；默认是 MySQL 本机身份验证。

-   `插件目录`: 插件的位置。

    您不能使用`SQL_THREAD`指定任何选项时的选项`用户`,`密码`,`DEFAULT_AUTH`， 要么`插件目录`, 除非`IO_THREAD`还提供了选项。

    有关详细信息，请参阅[第 6.2.17 节，“可插拔身份验证”](pluggable-authentication.html).

    如果将不安全的连接与任何这些选项一起使用，则服务器会发出警告在没有 SSL/TLS 的情况下以纯文本发送密码是极其不安全的。

`开始复制...直到`支持与全局事务标识符 (GTID) 一起使用的两个附加选项（请参阅[第 17.1.3 节，“使用全局事务标识符进行复制”](replication-gtids.html)）。这些中的每一个都需要一组一个或多个全局事务标识符*`gtid_set`*作为论据（见[GTID 集](replication-gtids-concepts.html#replication-gtids-concepts-gtid-sets)， 了解更多信息）。

没有时*`线程类型`*被指定，`开始复制直到 SQL_BEFORE_GTIDS`导致复制 SQL 线程处理事务，直到它到达*第一的*GTID 列在*`gtid_set`*.`开始复制直到 SQL_AFTER_GTIDS`导致复制线程处理所有事务，直到*`最后的`*中的交易*`gtid_set`*已被两个线程处理。换一种说法，`开始复制直到 SQL_BEFORE_GTIDS`导致复制 SQL 线程处理在第一个 GTID 之前发生的所有事务*`gtid_set`*达到，并且`开始复制直到 SQL_AFTER_GTIDS`导致复制线程处理所有事务，包括那些 GTID 位于*`gtid_set`*，直到每个人都遇到一个 GTID 不属于该集合的事务。`SQL_BEFORE_GTIDS`和`SQL_AFTER_GTIDS`每个人都支持`SQL_THREAD`和`IO_THREAD`选项，虽然使用`IO_THREAD`与他们目前没有任何效果。

例如，`开始复制 SQL_THREAD 直到 SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56`导致复制 SQL 线程处理源自其源的所有事务[`server_uuid`](replication-options.html#sysvar_server_uuid)是`3E11FA47-71CA-11E1-9E33-C80AA9429562`直到遇到序列号为 11 的事务；然后它停止而不处理此事务。换句话说，处理直到并包括序列号为 10 的事务的所有事务。执行`开始复制 SQL_THREAD 直到 SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56`另一方面，会导致复制 SQL 线程从源获取刚才提到的所有事务，包括所有序列号为 11 到 56 的事务，然后停止而不处理任何其他事务；也就是说，序列号为 56 的事务将是复制 SQL 线程获取的最后一个事务。

使用多线程副本时（[`replica_parallel_workers`](replication-options-replica.html#sysvar_replica_parallel_workers)要么[`slave_parallel_workers`](replication-options-replica.html#sysvar_slave_parallel_workers) >0)，在以下情况下，从中继日志中执行的事务序列可能会出现间隙：

-   协调器线程已停止

-   应用程序线程中发生错误

-   [**mysqld**](mysqld.html)意外关闭

    从 MySQL 8.0.27 开始，默认情况下所有副本都是多线程的。什么时候[`replica_preserve_commit_order=ON`](replication-options-replica.html#sysvar_replica_preserve_commit_order)要么[`slave_preserve_commit_order=ON`](replication-options-replica.html#sysvar_slave_preserve_commit_order)为副本设置，这也是 MySQL 8.0.27 的默认设置，除了描述中列出的特定情况外，不应出现间隙[`replica_preserve_commit_order`](replication-options-replica.html#sysvar_replica_preserve_commit_order)和[`slave_preserve_commit_order`](replication-options-replica.html#sysvar_slave_preserve_commit_order).如果[`replica_preserve_commit_order=OFF`](replication-options-replica.html#sysvar_replica_preserve_commit_order)要么[`slave_preserve_commit_order=OFF`](replication-options-replica.html#sysvar_slave_preserve_commit_order)为副本设置，这是 MySQL 8.0.27 之前的默认设置，事务的提交顺序没有保留，因此出现间隙的机会要大得多。

    使用`开始复制直到 SQL_AFTER_MTS_GAPS`语句使多线程副本的工作线程仅运行，直到在中继日志中找不到更多间隙，然后停止。这个语句可以取`SQL_THREAD`选项，但语句的效果保持不变。它对复制 I/O（接收者）线程没有影响（并且不能与`IO_THREAD`选项）。

    MySQL 8.0.26 之前，发行`开始复制`在从中继日志执行的事务序列中存在间隙的多线程副本上会生成警告。在这种情况下，解决方案是使用`开始复制直到 SQL_AFTER_MTS_GAPS`, 然后发出[`重置副本`](reset-replica.html)删除任何剩余的中继日志。从 MySQL 8.0.26 开始，在使用基于 GTID 的复制和 GTID 自动定位时，将完全跳过检查事务序列中的间隙的过程，因为可以使用 GTID 自动定位来解决事务中的间隙。在那种情况下，`开始复制直到 SQL_AFTER_MTS_GAPS`只是在发现第一个要执行的事件时停止应用程序线程，并且不尝试检查事务序列中的间隙。看[第 17.5.1.34 节，“复制和事务不一致”](replication-features-transaction-inconsistencies.html)了解更多信息。

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


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

Or from MySQL 8.0.26:
START REPLICA UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.replica_parallel_workers = 0;
START REPLICA SQL_THREAD;
```

`开始复制`在复制 I/O（接收器）线程和复制 SQL（应用程序）线程都启动后，向用户发送确认。但是，复制接收器线程可能尚未连接。为此，一个成功的`开始复制`原因[`显示副本状态`](show-replica-status.html)以显示`Replica_SQL_Running=是`，但这并不能保证`Replica_IO_Running=是`（因为`Replica_IO_Running=是`仅当接收线程正在运行时*并连接*）。有关详细信息，请参阅[第 13.7.7.35 节，“显示副本状态声明”](show-replica-status.html)， 和[第 17.1.7.1 节，“检查复制状态”](replication-administration-status.html).

一个`直到`子句 (*`直到选项`*，在前面的语法中）可以添加以指定副本应该启动并运行，直到复制 SQL 线程到达源的二进制日志或副本的中继日志中的给定点。使用以下一对选项之一来指定位置：

-   `MASTER_LOG_POS`和`MASTER_LOG_FILE`对于二进制日志（到 MySQL 8.0.22）。

-   `SOURCE_LOG_POS`和`SOURCE_LOG_FILE`对于二进制日志（来自 MySQL 8.0.23）。

-   `RELAY_LOG_POS`和`RELAY_LOG_FILE`用于中继日志。

    对于压缩的交易有效载荷，位置必须基于压缩的`Transaction_payload_event`.当 SQL 线程到达指定点时，它会停止。如果`SQL_THREAD`在语句中指定选项时，它只启动 SQL 线程。否则，它会启动两个复制线程。如果 SQL 线程正在运行，则`直到`子句被忽略并发出警告。您不能使用`直到`子句与`IO_THREAD`选项。

    也可以用`开始复制直到`使用其中一个选项指定相对于给定 GTID 或一组 GTID 的停止点`SQL_BEFORE_GTIDS`要么`SQL_AFTER_GTIDS`，如本节前面所述。使用这些选项之一时，您可以指定`SQL_THREAD`,`IO_THREAD`，这两个，或者都不是。如果您仅指定`SQL_THREAD`，那么只有复制SQL线程（applier）受该语句影响；要是`IO_THREAD`被使用，那么只有复制 I/O（接收者）线程受到影响。如果两者`SQL_THREAD`和`IO_THREAD`被使用，或者如果它们都没有被使用，那么 SQL（应用程序）和 I/O（接收器）线程都会受到该语句的影响。

    为`直到`子句，您必须指定以下任何一项：

-   *两个都*日志文件名和该文件中的位置

-   *任何一个*的`SQL_BEFORE_GTIDS`要么`SQL_AFTER_GTIDS`

-   `SQL_AFTER_MTS_GAPS`

    不要混合源和中继日志选项。不要将日志文件选项与 GTID 选项混用。

    这`直到`子句仍然可以与文件名和文件位置选项一起使用，当`GTID_ONLY`选项设置在[`将复制源更改为`](change-replication-source-to.html)用于停止复制通道在复制元数据存储库中保留文件名和文件位置的语句。文件名和文件位置在内存中进行跟踪。

    这`直到`多线程副本不支持子句，除非同时使用`SQL_AFTER_MTS_GAPS`.如果`直到`用于多线程副本，没有`SQL_AFTER_MTS_GAPS`，副本以单线程（顺序）模式运行以进行复制，直到由`直到`条款达成。

    任何`直到`条件由随后的重置[`停止复制`](stop-replica.html)声明，一个`开始复制`不包含的声明`直到`子句，或重新启动服务器。

    指定日志文件和位置时，可以使用`IO_THREAD`选项`开始复制...直到`即使只有 SQL 线程受此语句影响。这`IO_THREAD`在这种情况下，选项会被忽略。使用 GTID 选项之一时，上述限制不适用 (`SQL_BEFORE_GTIDS`和`SQL_AFTER_GTIDS`);GTID 选项同时支持`SQL_THREAD`和`IO_THREAD`，如本节前面所述。

    这`直到`子句可用于调试复制，或使复制继续进行，直到您希望避免副本复制事件的点之前。例如，如果一个不明智的[`删除表`](drop-table.html)语句已在源上执行，您可以使用`直到`告诉副本执行到该点，但不能更远。要查找事件是什么，请使用[**mysqlbinlog**](mysqlbinlog.html)使用源的二进制日志或副本的中继日志，或者使用[`显示 BINLOG 事件`](show-binlog-events.html)陈述。

    如果您正在使用`直到`要让副本进程分段复制查询，建议您使用[`--skip-slave-启动`](replication-options-replica.html#option_mysqld_skip-slave-start)选项，或者从 MySQL 8.0.24 开始，[`skip_slave_start`](replication-options-replica.html#sysvar_skip_slave_start)系统变量，用于防止 SQL 线程在副本服务器启动时运行。程序完成后删除选项或系统变量设置，以便在服务器意外重启时不会忘记。

    这[`显示副本状态`](show-replica-status.html)语句包括显示当前值的输出字段`直到`健康）状况。
