文档首页
MySQL 9.0 参考手册
相关文档 下载此手册

MySQL 9.0 参考手册  /  ...  /  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_THREADSQL_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_appliergroup_replication_recovery)由服务器实例自动管理。 START REPLICA 根本不能与 group_replication_recovery 通道一起使用,并且仅在组复制未运行时才应与 group_replication_applier 通道一起使用。 group_replication_applier 通道仅具有应用线程,没有接收线程,因此如果需要,可以使用 SQL_THREAD 选项(不带 IO_THREAD 选项)启动它。

START REPLICA 支持使用 USERPASSWORDDEFAULT_AUTHPLUGIN_DIR 选项的可插拔用户密码身份验证(请参见 第 8.2.17 节,“可插拔身份验证”),如下面的列表所述。当您使用这些选项时,您必须启动接收线程(IO_THREAD 选项)或所有复制线程;您不能单独启动复制应用线程(SQL_THREAD 选项)。

USER

帐户的用户名。如果使用 PASSWORD,则必须设置此项。该选项不能设置为空字符串或 null 字符串。

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_FILESOURCE_LOG_POS

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

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

RELAY_LOG_FILERELAY_LOG_POS

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

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

SQL_BEFORE_GTIDS

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

SQL_AFTER_GTIDS

此选项使复制应用线程开始处理事务,并在处理完指定 GTID 集中的所有事务后停止。该选项接受一个 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 9.0 中,这不再是一个问题,并且可以使用 SQL_AFTER_GTIDS,而不会导致副本回退到单线程模式。

SQL_AFTER_MTS_GAPS

对于仅限于多线程副本(replica_parallel_workers > 0),此选项使副本处理事务,直到转继日志中不再存在事务执行序列的间隙为止。使用多线程副本时,在以下情况下可能会出现间隙

  • 协调线程已停止。

  • 应用线程中发生错误。

  • mysqld 意外关闭。

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

默认情况下,所有副本都是多线程的。当副本上设置了 replica_preserve_commit_order=ON(默认值)时,除了该变量描述中列出的特定情况外,不应该出现间隙。如果 replica_preserve_commit_orderOFF,则不会保留事务的提交顺序,因此出现间隙的可能性要大得多。

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

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