MySQL :: MySQL 8.4 参考手册 :: 15.4.2.4 START REPLICA 语句

版本 8.4

9.0
8.0

8.0 日语

MySQL 8.4 参考手册 / ... / START REPLICA 语句

15.4.2.4 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
          |   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 启动复制线程，可以一起启动或分别启动。

START REPLICA 需要 REPLICATION_SLAVE_ADMIN 权限（或已弃用的 SUPER 权限）。START REPLICA 会导致正在进行的事务隐式提交。请参见第 15.3.3 节，“导致隐式提交的语句”。

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

START REPLICA 不带线程类型选项会启动所有复制线程，START REPLICA 带有这两个线程类型选项也会启动所有复制线程。
IO_THREAD 启动复制接收线程，该线程从源服务器读取事件并将它们存储在中继日志中。
SQL_THREAD 启动复制应用线程，该线程从中继日志读取事件并执行它们。多线程从服务器（replica_parallel_workers > 0）使用协调器线程和多个应用线程来应用事务，而 SQL_THREAD 会启动所有这些线程。

重要

START REPLICA 在所有复制线程启动后向用户发送确认消息。但是，复制接收线程可能尚未成功连接到源，或者应用线程在启动后立即应用事件时可能会停止。START REPLICA 在线程启动后不会继续监控它们，因此不会在它们随后停止或无法连接时发出警告。您必须检查副本的错误日志，查看复制线程生成的错误消息，或使用 SHOW REPLICA STATUS 检查它们是否正常运行。成功执行 START REPLICA 语句会导致 SHOW REPLICA STATUS 显示 Replica_SQL_Running=Yes，但它可能显示或可能不显示 Replica_IO_Running=Yes，因为 Replica_IO_Running=Yes 仅在接收线程正在运行且已连接时显示。有关更多信息，请参见第 19.1.7.1 节，“检查复制状态”。

可选的 FOR CHANNEL channel 子句允许您命名该语句适用的复制通道。提供 FOR CHANNEL channel 子句会将 START REPLICA 语句应用于特定的复制通道。如果未命名任何子句且不存在额外的通道，则该语句适用于默认通道。如果 START REPLICA 语句在使用多个通道时没有定义通道，则此语句将为所有通道启动指定的线程。有关更多信息，请参见第 19.2.2 节，“复制通道”。

组复制的复制通道 (group_replication_applier 和 group_replication_recovery) 由服务器实例自动管理。START REPLICA 根本不能与 group_replication_recovery 通道一起使用，并且仅应在组复制未运行时与 group_replication_applier 通道一起使用。group_replication_applier 通道仅具有一个应用线程，没有接收线程，因此如果需要，可以使用 SQL_THREAD 选项（不使用 IO_THREAD 选项）启动它。

START REPLICA 支持可插拔的用户密码身份验证（参见第 8.2.17 节，“可插拔身份验证”），并使用 USER、PASSWORD、DEFAULT_AUTH 和 PLUGIN_DIR 选项，如以下列表所述。使用这些选项时，必须启动接收线程 (IO_THREAD 选项) 或所有复制线程；您不能单独启动复制应用线程 (SQL_THREAD 选项)。

USER: 帐户的用户名。如果使用 PASSWORD，则必须设置此选项。该选项不能设置为空字符串或空字符串。
PASSWORD: 命名用户帐户的密码。
DEFAULT_AUTH: 身份验证插件的名称。默认值为 MySQL 本机身份验证。
PLUGIN_DIR: 身份验证插件的位置。

重要

使用 START REPLICA 设置的密码在写入 MySQL Server 的日志、性能架构表和 SHOW PROCESSLIST 语句时会被屏蔽。但是，它会以纯文本形式通过与副本服务器实例的连接发送。要保护传输中的密码，请使用 SSL/TLS 加密、SSH 隧道或其他保护连接免受未经授权查看的方法，用于副本服务器实例与您用于发出 START REPLICA 的客户端之间的连接。

UNTIL 子句使副本启动复制，然后处理事务，直到您在 UNTIL 子句中指定的点，然后再次停止。可以使用 UNTIL 子句使副本继续执行，直到您想要跳过不需要的事务的点之前，然后跳过该事务，如第 19.1.7.3 节，“跳过事务” 中所述。要标识事务，您可以使用 mysqlbinlog 和源的二进制日志或副本的中继日志，或使用 SHOW BINLOG EVENTS 语句。

您还可以使用 UNTIL 子句通过一次或分段处理事务来调试复制。如果您使用 UNTIL 子句执行此操作，请使用 --skip-replica-start 启动副本，以防止 SQL 线程在副本服务器启动时运行。在完成此过程后，删除该选项或系统变量设置，以防在服务器意外重启时忘记它。

SHOW REPLICA STATUS 语句包含显示 UNTIL 条件当前值的输出字段。UNTIL 条件持续到受影响的线程仍在运行，并在它们停止时被删除。

UNTIL 子句在复制应用线程 (SQL_THREAD 选项) 上运行。您可以使用 SQL_THREAD 选项，也可以让副本默认启动两个线程。如果您单独使用 IO_THREAD 选项，则会忽略 UNTIL 子句，因为不会启动应用线程。

您在 UNTIL 子句中指定的点可以是以下任何一个（并且只能是其中一个）选项

SOURCE_LOG_FILE 和 SOURCE_LOG_POS

这些选项使复制应用线程处理事务，直到中继日志中的某个位置，该位置由源服务器上二进制日志中对应点的文件名和文件位置标识。应用线程在指定位置或之后找到最近的事务边界，完成应用事务，然后停止在那里。对于压缩的事务有效负载，请指定压缩的 Transaction_payload_event 的结束位置。

即使在 GTID_ONLY 选项在 CHANGE REPLICATION SOURCE TO 语句上设置以阻止复制通道在复制元数据存储库中持久化文件名和文件位置时，也可以使用这些选项。文件名和文件位置在内存中跟踪。

RELAY_LOG_FILE 和 RELAY_LOG_POS

这些选项使复制应用线程处理事务，直到副本中继日志中的某个位置，该位置由中继日志文件名和该文件中的某个位置标识。应用线程在指定位置或之后找到最近的事务边界，完成应用事务，然后停止在那里。对于压缩的事务有效负载，请指定压缩的 Transaction_payload_event 的结束位置。

SQL_BEFORE_GTIDS

此选项使复制应用线程开始处理事务，并在遇到指定的 GTID 集中的任何事务时停止。来自 GTID 集的遇到的事务不会被应用，GTID 集中的任何其他事务也不会被应用。该选项接受包含一个或多个全局事务标识符的 GTID 集作为参数（参见 GTID 集）。GTID 集中的事务不一定按其 GTID 的顺序出现在复制流中，因此应用线程停止之前的交易不一定是最早的。

SQL_AFTER_GTIDS

此选项使复制应用线程开始处理事务，并在处理完指定 GTID 集中的所有事务后停止。该选项接受包含一个或多个全局事务标识符的 GTID 集作为参数（参见 GTID 集）。

使用 SQL_AFTER_GTIDS，复制线程在处理完 GTID 集中的所有事务后停止。事务按接收顺序处理，因此这些事务中可能包括不在 GTID 集中的事务，但这些事务是在 GTID 集中的所有事务提交之前接收（并处理）的。例如，执行 START REPLICA UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 会导致副本从源获取（并处理）所有事务，直到所有具有序号 11 到 56 的事务都被处理，然后在达到该点后停止，不再处理任何其他事务。

在较旧版本的 MySQL 中，此选项不能与 replica_parallel_workers > 1 一起使用。在 MySQL 8.4 中，这不再是一个问题，SQL_AFTER_GTIDS 可以使用，不会导致副本回退到单线程模式。

SQL_AFTER_MTS_GAPS

对于仅多线程副本（使用 replica_parallel_workers > 0），此选项使副本处理事务，直到从中继日志执行的事务序列中不再有间隙。在使用多线程副本时，在以下情况下可能会出现间隙

协调线程已停止。
应用线程中出现错误。
mysqld 意外关闭。

当复制通道存在间隙时，副本的数据库处于可能从未在源上存在过的状态。副本在内部跟踪间隙，并禁止执行会删除间隙信息的 CHANGE REPLICATION SOURCE TO 语句。

默认情况下，所有副本都是多线程的。当副本上 replica_preserve_commit_order=ON（默认值）时，除了此变量说明中列出的特定情况外，不应出现间隙。如果 replica_preserve_commit_order 为 OFF，则不会保留事务的提交顺序，因此出现间隙的可能性要大得多。

如果未使用 GTID，并且您需要将失败的多线程副本更改为单线程模式，则可以按所示顺序发出以下一系列语句

START REPLICA UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.replica_parallel_workers = 0;
START REPLICA SQL_THREAD;

PREV HOME UP NEXT