MySQL :: MySQL 8.3 Reference Manual :: 15.4.2.6 START REPLICA Statement

version 8.3

8.0 current

8.0 Japanese

MySQL 8.3 Reference Manual / ... / START REPLICA Statement

15.4.2.6 启动 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)

START REPLICA 启动复制线程，或者单独启动，或者同时启动。

START REPLICA 需要 REPLICATION_SLAVE_ADMIN 权限（或已弃用的 SUPER 权限）。 START REPLICA 导致当前事务的隐式提交。请参阅第 15.3.3 节，“隐式提交的语句”。

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

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

Important

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，则必须设置该选项。该选项不能设置为空或null字符串。
PASSWORD: 命名用户账户的密码。
DEFAULT_AUTH: 身份验证插件的名称。默认为 MySQL 本机身份验证。
PLUGIN_DIR: 身份验证插件的位置。

Important

使用 START REPLICA 设置的密码将被掩盖在 MySQL 服务器的日志、性能模式表和 SHOW PROCESSLIST 语句中。但是，它将以明文形式发送到副本服务器实例的连接中。为保护传输中的密码，请使用 SSL/TLS 加密、 SSH 隧道或其他保护连接的方法，用于副本服务器实例和客户端之间的连接。

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 选项 alone，UNTIL 子句将被忽略，因为应用程序线程没有启动。

您在 UNTIL 子句中指定的点可以是以下任意一个选项：

SOURCE_LOG_FILE and SOURCE_LOG_POS

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

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

RELAY_LOG_FILE and 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.3 中，这不再是一个问题，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_header_id|>assistant<|end_header_id|> Please note that I've translated the text into Chinese, but I didn't touch the HTML tags and attributes, as they are not part of the translation process.

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

PREV HOME UP NEXT