克隆插件支持复制。除了克隆数据之外,克隆操作还从捐赠者那里提取复制坐标并将其传输给接收者,这使得可以使用克隆插件来配置组复制成员和副本。使用克隆插件进行配置比复制大量事务要快得多,效率也高得多。
组复制成员也可以配置为使用克隆插件作为分布式恢复的选项,在这种情况下,加入成员会自动选择最有效的方式从现有组成员检索组数据。有关详细信息,请参阅第 18.5.4.2 节,“为分布式恢复克隆”。
在克隆操作期间,二进制日志位置(文件名、偏移量)和
gtid_executed
GTID 集被提取并从捐赠者 MySQL 服务器实例传输到接收者。此数据允许在复制流中的一致位置启动复制。保存在文件中的二进制日志和中继日志不会从捐赠者复制到接收者。要启动复制,接收方赶上捐赠者所需的二进制日志不得在数据被克隆和复制开始之间被清除。如果所需的二进制日志不可用,则会报告复制握手错误。因此,应该将克隆的实例添加到复制组而不要过多延迟,以避免清除所需的二进制日志或新成员明显落后,
在克隆的 MySQL 服务器实例上发出此查询以检查传输给接收者的二进制日志位置:
mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
在克隆的 MySQL 服务器实例上发出此查询以检查
gtid_executed
传输给接收者的 GTID 集:mysql> SELECT @@GLOBAL.GTID_EXECUTED;
默认情况下,在 MySQL 8.0 中,复制元数据存储库保存在克隆操作期间从捐赠者复制到接收者的表中。复制元数据存储库包含与复制相关的配置设置,可用于在克隆操作后正确恢复复制。
在 MySQL 8.0.17 和 8.0.18 中,只
mysql.slave_master_info
复制表(连接元数据存储库)。从 MySQL 8.0.19 开始,表
mysql.slave_relay_log_info
(applier 元数据存储库)和mysql.slave_worker_info
(applier worker 元数据存储库)也被复制。
有关每个表中包含的内容的列表,请参阅
第 17.2.4.2 节,“复制元数据存储库”。请注意,如果设置
master_info_repository=FILE
和
relay_log_info_repository=FILE
在服务器上使用(这不是 MySQL 8.0 中的默认设置并且已弃用),则不会克隆复制元数据存储库;它们仅在TABLE
设置时被克隆。
要克隆以进行复制,请执行以下步骤:
对于组复制的新组成员,首先按照 第 18.2.1.6 节,“将实例添加到组”中的说明,为组复制配置 MySQL 服务器实例。还要设置 第 18.5.4.2 节“分布式恢复的克隆”中描述的克隆先决条件。当您
START GROUP_REPLICATION
在加入成员上发布时,克隆操作由 Group Replication 自动管理,因此您无需手动执行操作,也无需对加入成员执行任何进一步的设置步骤。对于源/副本 MySQL 复制拓扑中的副本,首先将数据从捐赠者 MySQL 服务器实例手动克隆到接收者。donor 必须是复制拓扑中的源或副本。有关克隆说明,请参阅第 5.6.7.3 节,“克隆远程数据”。
克隆操作成功完成后,如果要在接收方 MySQL 服务器实例上使用与捐赠者相同的复制通道,请验证它们中的哪些可以在源/副本 MySQL 复制拓扑中自动恢复复制,哪些需要手动设置。
对于基于 GTID 的复制,如果接收者配置有 、 或
gtid_mode=ON
的捐赠者并已从捐赠者克隆,捐赠者 的 GTID 集将应用于接收者。如果收件人是从拓扑中已有的副本克隆的,则使用 GTID 自动定位的收件人上的复制通道可以在克隆操作启动后自动恢复复制。如果您只想使用这些相同的通道,则无需执行任何手动设置。gtid_mode=ON
ON_PERMISSIVE
OFF_PERMISSIVE
gtid_executed
对于基于二进制日志文件位置的复制,如果接收方是 MySQL 8.0.17 或 8.0.18,则来自捐赠者的二进制日志位置不会应用于接收方,仅记录在性能模式
clone_status
表中。因此,必须手动设置使用基于二进制日志文件位置的复制的收件人上的复制通道,以便在克隆操作后恢复复制。确保这些通道未配置为在服务器启动时自动启动复制,因为它们还没有二进制日志位置并尝试从头开始复制。对于基于二进制日志文件位置的复制,如果接收方是 MySQL 8.0.19 或更高版本,则来自捐赠者的二进制日志位置将应用于接收方。在重新启动复制之前,使用基于二进制日志文件位置的复制的接收者上的复制通道自动尝试使用克隆的中继日志信息执行中继日志恢复过程。对于单线程副本(
replica_parallel_workers
或slave_parallel_workers
设置为 0),中继日志恢复应该在没有任何其他问题的情况下成功,使通道无需进一步设置即可恢复复制。对于多线程副本(replica_parallel_workers
或slave_parallel_workers
大于0),中继日志恢复很可能会失败,因为它通常不能自动完成。在这种情况下,会发出一条错误消息,您必须手动设置通道。
如果您需要手动设置克隆的复制通道,或者想在接收者上使用不同的复制通道,以下说明提供了将接收者 MySQL 服务器实例添加到复制拓扑的摘要和缩写示例。另请参阅适用于您的复制设置的详细说明。
要将收件人 MySQL 服务器实例添加到使用基于 GTID 的事务作为复制数据源的 MySQL 复制拓扑,请按照 第 17.1.3.4 节,“使用 GTID 设置复制”中的说明根据需要配置实例。如以下简短示例所示,为实例添加复制通道。语句(从 MySQL 8.0.23
CHANGE REPLICATION SOURCE TO
开始)或CHANGE MASTER TO
语句(MySQL 8.0.23 之前)必须定义源的主机地址和端口号,并且SOURCE_AUTO_POSITION
|MASTER_AUTO_POSITION
选项应该被启用,如图所示:mysql> CHANGE MASTER TO MASTER_HOST = 'source_host_name', MASTER_PORT = source_port_num, ... MASTER_AUTO_POSITION = 1, FOR CHANNEL 'setup_channel'; mysql> START SLAVE USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel'; Or from MySQL 8.0.22 and 8.0.23: mysql> CHANGE SOURCE TO SOURCE_HOST = 'source_host_name', SOURCE_PORT = source_port_num, ... SOURCE_AUTO_POSITION = 1, FOR CHANNEL 'setup_channel'; mysql> START REPLICA USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';
要将收件人 MySQL 服务器实例添加到使用基于二进制日志文件位置的复制的 MySQL 复制拓扑,请按照 第 17.1.2 节,“设置基于二进制日志文件位置的复制”中的说明根据需要配置实例。为实例添加复制通道,如以下缩写示例所示,使用在克隆操作期间传输给接收者的二进制日志位置:
mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; mysql> CHANGE MASTER TO MASTER_HOST = 'source_host_name', MASTER_PORT = source_port_num, ... MASTER_LOG_FILE = 'source_log_name', MASTER_LOG_POS = source_log_pos, FOR CHANNEL 'setup_channel'; mysql> START SLAVE USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel'; Or from MySQL 8.0.22 and 8.0.23: mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; mysql> CHANGE SOURCE TO SOURCE_HOST = 'source_host_name', SOURCE_PORT = source_port_num, ... SOURCE_LOG_FILE = 'source_log_name', SOURCE_LOG_POS = source_log_pos, FOR CHANNEL 'setup_channel'; mysql> START REPLICA USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';