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
一起或单独启动复制线程。从 MySQL 8.0.22 开始,使用
START REPLICA
代替
START SLAVE
,该版本已弃用。在 MySQL 8.0.22 之前的版本中,使用
START SLAVE
.
START REPLICA
需要
REPLICATION_SLAVE_ADMIN
特权(或已弃用的SUPER
特权)。START REPLICA
导致正在进行的事务的隐式提交。请参阅
第 13.3.3 节,“导致隐式提交的语句”。
对于线程类型选项,您可以指定
IO_THREAD
、SQL_THREAD
、这两个选项,或两者都不指定。只有启动的线程才会受该语句影响。
START REPLICA
没有线程类型选项会启动所有复制线程,START REPLICA
两个线程类型选项也是如此。IO_THREAD
启动复制接收器线程,它从源服务器读取事件并将它们存储在中继日志中。SQL_THREAD
启动复制应用程序线程,该线程从中继日志中读取事件并执行它们。多线程副本(具有replica_parallel_workers
orslave_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
仅在接收线程同时运行和连接时显示。有关详细信息,请参阅
第 17.1.7.1 节,“检查复制状态”。
可选子句使您能够命名该语句适用于哪个复制通道。提供一个子句将
语句应用于特定的复制通道。如果没有命名子句并且不存在额外的通道,则该语句适用于默认通道。如果
语句在使用多个通道时没有定义通道,则该语句为所有通道启动指定的线程。有关更多信息,请参阅
第 17.2.2 节,“复制通道”。
FOR CHANNEL
channel
FOR CHANNEL
channel
START REPLICA
START REPLICA
组复制(group_replication_applier
和
group_replication_recovery
)的复制通道由服务器实例自动管理。START
REPLICA
根本不能与
group_replication_recovery
通道一起使用,并且只能
group_replication_applier
在组复制未运行时与通道一起使用。channel 只有applier thread ,
group_replication_applier
没有receiver thread,所以需要的时候可以通过SQL_THREAD
不带option 的option 来启动IO_THREAD
。
START REPLICA
支持可插入的用户密码认证(参见
第 6.2.17 节,“可插入的认证”),带有
、
USER
和选项
,如下表所述。当您使用这些选项时,您必须启动接收线程(选项)或所有复制线程 - 您不能单独启动复制应用程序线程(选项)。
PASSWORD
DEFAULT_AUTH
PLUGIN_DIR
IO_THREAD
SQL_THREAD
-
USER
帐户的用户名。如果
PASSWORD
使用,则必须设置此项。该选项不能设置为空字符串或空字符串。-
PASSWORD
指定用户帐户的密码。
-
DEFAULT_AUTH
身份验证插件的名称。默认是 MySQL 本机身份验证。
-
PLUGIN_DIR
身份验证插件的位置。
您设置的密码START
REPLICA
在写入 MySQL 服务器的日志、性能模式表和
SHOW PROCESSLIST
语句时会被屏蔽。但是,它是通过与副本服务器实例的连接以纯文本形式发送的。要保护传输中的密码,请使用 SSL/TLS 加密、SSH 隧道或其他保护连接免遭未经授权查看的方法,用于副本服务器实例和您用于发布的客户端之间的连接START
REPLICA
。
该UNTIL
子句使副本开始复制,然后处理事务直到您在UNTIL
子句中指定的点,然后再次停止。该UNTIL
子句可用于使副本继续进行,直到您要跳过不需要的事务的点之前,然后按照
第 17.1.7.3 节“跳过事务”中所述跳过该事务。要识别事务,您可以将
mysqlbinlog与源的二进制日志或副本的中继日志一起使用,或者使用SHOW
BINLOG EVENTS
语句。
您还可以使用该UNTIL
子句通过一次处理一个事务或分段处理事务来调试复制。如果您使用该UNTIL
子句来执行此操作,请
--skip-slave-start
使用系统变量选项或从 MySQL 8.0.24
启动副本skip_slave_start
,以防止 SQL 线程在副本服务器启动时运行。该过程完成后删除选项或系统变量设置,以便在服务器意外重启时不会忘记。
该SHOW REPLICA STATUS
语句包括显示
UNTIL
条件当前值的输出字段。UNTIL
只要受影响的线程仍在运行,
该条件就会持续,并在它们停止时被删除。
该UNTIL
子句在复制应用程序线程(SQL_THREAD
选项)上运行。您可以使用该SQL_THREAD
选项或让副本默认启动两个线程。如果
IO_THREAD
单独使用该选项,则该
UNTIL
子句将被忽略,因为应用程序线程未启动。
您在子句中指定的点UNTIL
可以是以下选项中的任何一个(且只能是一个):
-
SOURCE_LOG_FILE
和SOURCE_LOG_POS
(从 MySQL 8.0.23),或MASTER_LOG_FILE
和MASTER_LOG_POS
(到 MySQL 8.0.22) 这些选项使复制应用程序处理事务直到其中继日志中的某个位置,该位置由源服务器上二进制日志中相应点的文件名和文件位置标识。applier thread 在指定位置或之后找到最近的事务边界,完成应用事务,并在那里停止。对于压缩的交易负载,指定压缩的结束位置
Transaction_payload_event
。GTID_ONLY
当在语句上设置选项CHANGE REPLICATION SOURCE TO
以停止复制通道在复制元数据存储库中保留文件名和文件位置 时,仍然可以使用这些选项 。文件名和文件位置在内存中被跟踪。-
RELAY_LOG_FILE
和RELAY_LOG_POS
这些选项使复制应用程序处理事务直到副本的中继日志中的某个位置,由中继日志文件名和该文件中的位置标识。applier thread 在指定位置或之后找到最近的事务边界,完成应用事务,并在那里停止。对于压缩的交易负载,指定压缩的结束位置
Transaction_payload_event
。GTID_ONLY
当在语句上设置选项CHANGE REPLICATION SOURCE TO
以停止复制通道在复制元数据存储库中保留文件名和文件位置 时,仍然可以使用这些选项 。文件名和文件位置在内存中被跟踪。-
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 的所有事务,然后停止而不处理任何其他事务。-
SQL_AFTER_MTS_GAPS
仅对于多线程副本(with
replica_parallel_workers
orslave_parallel_workers
> 0),此选项使副本处理事务直到从中继日志执行的事务序列中没有更多间隙的点。使用多线程副本时,有可能在以下情况下出现间隙:协调器线程已停止。
应用程序线程中发生错误。
mysqld意外关闭。
当复制通道有间隙时,副本的数据库处于源上可能永远不存在的状态。副本在内部跟踪间隙,并禁止
CHANGE REPLICATION SOURCE TO
在执行时删除间隙信息的语句。在 MySQL 8.0.26 之前,
START REPLICA
在从中继日志执行的事务序列中存在间隙的多线程副本上发布会生成警告。要纠正这种情况,解决方案是使用START REPLICA UNTIL SQL_AFTER_MTS_GAPS
. 有关更多信息,请参阅 第 17.5.1.34 节,“复制和事务不一致” 。SOURCE_AUTO_POSITION=1
从 MySQL 8.0.26 开始,当基于 GTID 的复制和 GTID 自动定位 ( ) 用于通道时, 完全跳过检查事务序列中的间隙的过程,因为事务中的间隙可以使用 GTID 自动定位解决定位。在这种情况下, 应用程序START REPLICA UNTIL SQL_AFTER_MTS_GAPS
线程会在发现要执行的第一个事务时停止,并且不会尝试检查事务序列中的间隙。您也可以继续CHANGE REPLICATION SOURCE TO
像往常一样使用语句,通道可以进行中继日志恢复。从 MySQL 8.0.27 开始,所有副本默认都是多线程的。当 为副本设置
replica_preserve_commit_order=ON
or 时,这也是 MySQL 8.0.27 的默认设置,除了 和slave_preserve_commit_order=ON
的描述中列出的特定情况外,不应出现间隙 。MySQL 8.0.27之前默认的replica如果 设置了 or ,事务的commit order是不保留的,出现gaps的几率会大很多。replica_preserve_commit_order
slave_preserve_commit_order
replica_preserve_commit_order=OFF
slave_preserve_commit_order=OFF
如果 GTID 未在使用中并且您需要将失败的多线程副本更改为单线程模式,您可以按照显示的顺序发出以下一系列语句:
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;