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
支持使用 USER
、PASSWORD
、DEFAULT_AUTH
和 PLUGIN_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_FILE
和SOURCE_LOG_POS
这些选项使复制应用线程处理事务,直到转继日志中的某个位置,该位置由源服务器上的二进制日志中对应位置的文件名和文件位置标识。应用线程在指定位置或之后找到最接近的事务边界,完成应用事务,并在该处停止。对于压缩的事务有效负载,请指定压缩的
Transaction_payload_event
的结束位置。即使在
CHANGE REPLICATION SOURCE TO
语句上设置了GTID_ONLY
选项,以阻止复制通道将文件名和文件位置持久化到复制元数据存储库中,也可以使用这些选项。文件名和文件位置在内存中跟踪。-
RELAY_LOG_FILE
和RELAY_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_order
为OFF
,则不会保留事务的提交顺序,因此出现间隙的可能性要大得多。如果未使用 GTID 并且您需要将故障的多线程副本更改为单线程模式,则可以按以下所示的顺序发出以下一系列语句
START REPLICA UNTIL SQL_AFTER_MTS_GAPS; SET @@GLOBAL.replica_parallel_workers = 0; START REPLICA SQL_THREAD;