Documentation Home
MySQL 8.3 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.8Mb
PDF (A4) - 40.9Mb
Man Pages (TGZ) - 294.0Kb
Man Pages (Zip) - 409.0Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb
Excerpts from this Manual

MySQL 8.3 Reference Manual  /  ...  /  Cloning for Distributed Recovery

20.5.4.2 分布式恢复中的克隆

从 MySQL 8.0.17 开始,MySQL 服务器的克隆插件可用。如果您想在组中使用远程克隆操作来实现分布式恢复,必须预先设置现有成员和加入成员以支持该功能。如果您不想在组中使用该功能,不要设置它,在这种情况下,组复制将仅使用二进制日志的状态传输。

要使用克隆,至少需要一个现有组成员和加入成员预先设置以支持远程克隆操作。至少,您必须在捐赠者和加入成员上安装克隆插件,授予复制用户分布式恢复的 BACKUP_ADMIN 权限,并将 group_replication_clone_threshold 系统变量设置为适当的级别。为了确保捐赠者的最大可用性,建议将所有当前和未来的组成员设置为支持远程克隆操作。

请注意,远程克隆操作将从加入成员中删除用户创建的表空间和数据,然后从捐赠者传输数据。如果操作在进行中停止,加入成员可能会留下部分数据或无数据。这可以通过重试远程克隆操作来修复,组复制将自动执行。

20.5.4.2.1 克隆的先决条件

有关设置和配置克隆插件的完整说明,请参阅 第 7.6.7 节,“克隆插件” 。远程克隆操作的详细先决条件在 第 7.6.7.3 节,“远程数据克隆” 中涵盖。对于组复制,请注意以下关键点和差异:

  • 捐赠者(现有组成员)和接收者(加入成员)必须安装并激活克隆插件。有关执行此操作的说明,请参阅 第 7.6.7.1 节,“安装克隆插件”

  • 捐赠者和接收者必须运行相同的操作系统,并且必须具有相同的 MySQL 服务器版本(必须是 MySQL 8.0.17 或更高版本,以支持克隆插件)。因此,克隆不适用于组成员运行不同 MySQL 服务器版本的情况。

  • 捐赠者和接收者必须安装并激活组复制插件,并且捐赠者上的任何其他插件(例如密钥环插件)也必须在接收者上激活。

  • 如果分布式恢复配置为使用 SSL (group_replication_recovery_use_ssl=ON),组复制将应用该设置以进行远程克隆操作。组复制将自动配置克隆 SSL 选项 (clone_ssl_ca, clone_ssl_certclone_ssl_key)以匹配您的分布式恢复设置 (group_replication_recovery_ssl_ca, group_replication_recovery_ssl_certgroup_replication_recovery_ssl_key)。

  • 您不需要在 clone_valid_donor_list 系统变量中设置有效捐赠者列表,以便加入复制组。组复制将自动配置该设置,选择捐赠者后。请注意,远程克隆操作使用服务器的 SQL 协议主机名和端口。

  • 克隆插件具有许多系统变量,以管理远程克隆操作的网络负载和性能影响。组复制不配置这些设置,因此您可以查看它们并根据需要设置它们,或者允许它们默认。请注意,当远程克隆操作用于分布式恢复时,克隆插件的clone_enable_compression设置将应用于操作,而不是组复制压缩设置。

  • 要在接收方上invoke远程克隆操作,组复制使用内部的mysql.session用户,该用户已经具有CLONE_ADMIN特权,因此您不需要设置它。

  • 作为克隆用户在donor上的远程克隆操作,组复制使用了分布式恢复的复制用户(在第 20.2.1.3 节,“用户凭证For Distributed Recovery”中涵盖)。因此,您必须在所有支持克隆的组成员上授予BACKUP_ADMIN特权给该复制用户。此外,当您配置加入成员时,也需要授予该特权,因为它们可以在加入组后充当donor。同一个复制用户用于每个组成员的分布式恢复。要授予该特权给复制用户,可以在每个组成员上单独禁用二进制日志记录,然后在一个组成员上启用二进制日志记录。

    GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
  • 如果您使用START GROUP_REPLICATION指定复制用户凭证在服务器上,而之前使用CHANGE REPLICATION SOURCE TO指定用户凭证,请确保在远程克隆操作之前从复制元数据存储库中删除用户凭证。此外,请确保group_replication_start_on_boot=OFF在加入成员上设置。有关说明,请参阅第 20.6.3 节,“Securing Distributed Recovery Connections”。如果您不unset用户凭证,它们将在远程克隆操作期间传输到加入成员上。在这种情况下,group_replication_recovery通道可能会在原始成员或从其克隆的成员上意外启动。

20.5.4.2.2 克隆阈值

当组成员被设置为支持克隆时,group_replication_clone_threshold系统变量指定了一个阈值,以交易数量表示,用于分布式恢复中的远程克隆操作。如果donor和加入成员之间的交易差距大于该阈值,则使用远程克隆操作进行状态传输。组复制根据现有组成员的gtid_executed集合来计算阈值是否被超过。使用远程克隆操作可以在大交易差距的情况下添加新成员到组中,而不需要手动将组数据传输到服务器上,也可以让成员快速赶上。

默认情况下,group_replication_clone_threshold组复制系统变量的设置非常高(GTID 中的最大交易序号),因此它实际上禁用了克隆操作,除非状态传输来自二进制日志。要启用组复制选择远程克隆操作进行状态传输,请将系统变量设置为指定的交易数量,以便在交易差距超过该阈值时启用克隆。

Warning

不要在活动组中将group_replication_clone_threshold设置为低值。如果在远程克隆操作期间组中发生的交易数量超过阈值,加入成员将在重新启动后触发远程克隆操作,并可能无限期地继续这种情况。为了避免这种情况,请确保将阈值设置为高于组中预期发生的交易数量。

组复制尝试在阈值不相关的情况下执行远程克隆操作,例如当从捐赠者的二进制日志中无法进行状态传输时。组复制根据现有组成员的gtid_purged集合来确定这种情况。你不能使用group_replication_clone_threshold系统变量来停用克隆操作,因为在这种情况下,克隆是将数据传输到加入成员的唯一替代方法。

20.5.4.2.3 克隆操作

当组成员和加入成员设置为克隆时,组复制将为您管理远程克隆操作。远程克隆操作可能需要一些时间来完成,具体取决于数据的大小。请参阅第 7.6.7.10 节,“监控克隆操作”以获取监控过程的信息。

Note

当状态传输完成时,组复制将重新启动加入成员以完成过程。如果group_replication_start_on_boot=OFF在加入成员上设置,例如,因为您在START GROUP_REPLICATION语句中指定了复制用户凭据,那么您必须在重新启动后手动再次发出START GROUP_REPLICATION语句。如果group_replication_start_on_boot=ON且其他设置用于启动组复制的配置文件或使用SET PERSIST语句,那么您不需要干预,过程将自动继续以使加入成员在线。

如果远程克隆过程需要很长时间,在 MySQL 8.0.22 之前的版本中,组中的认证信息可能变得太大无法传输到加入成员。在这种情况下,加入成员将记录错误消息并且不加入组。从 MySQL 8.0.22 开始,组复制管理垃圾回收过程以避免这种情况。在早期版本中,如果您看到这种错误,在远程克隆操作完成后,等待两分钟以允许垃圾回收过程减少组的认证信息的大小。然后,在加入成员上发出以下语句,以便它停止尝试应用先前的认证信息:

RESET REPLICA FOR CHANNEL group_replication_recovery;

远程克隆操作克隆了捐赠者中的设置,包括持久化在表中的设置,以及数据。组复制管理与组复制通道相关的设置。组复制成员的设置,例如组复制本地地址,持久化在配置文件中,不会被克隆,也不会在加入成员上更改。组复制还保留了与 SSL 使用相关的通道设置,这些设置是每个成员独有的。

如果复制用户凭证用于donor的group_replication_recovery复制通道已经存储在复制元数据存储库中使用CHANGE REPLICATION SOURCE TO语句,它们将被传输到并由加入成员使用,必须在那里有效。如果您在START GROUP_REPLICATION语句中指定复制用户凭证,这些将用于启动远程克隆操作,但它们不会被传输到加入成员并使用。如果您不想将凭证传输到新加入者并记录在那里,请确保在远程克隆操作之前unset它们,如第 20.6.3 节,“保护分布式恢复连接”所述,并使用START GROUP_REPLICATION语句来提供它们。

如果已经使用PRIVILEGE_CHECKS_USER帐户来帮助保护复制应用程序(见第 19.3.3.2 节,“Group Replication Channels 的权限检查”),从 MySQL 8.0.19 开始,PRIVILEGE_CHECKS_USER帐户和相关设置将从donor克隆到加入成员。如果加入成员设置为在启动时启动Group Replication,它将自动使用该帐户对适当的复制通道进行权限检查。(在 MySQL 8.0.18 中,由于一些限制,不建议使用PRIVILEGE_CHECKS_USER帐户与Group Replication Channels。)

20.5.4.2.4 手动克隆

Group Replication 初始化和管理克隆操作以进行分布式恢复。组成员可以参与克隆操作,用户可以手动启动克隆操作。例如,您可能想通过克隆从组成员创建新的服务器实例,但不想让新服务器实例立即加入组,或者永远不加入。

在所有支持克隆的版本中,您可以手动启动克隆操作,涉及到组成员上停止了Group Replication。请注意,因为克隆需要donor和recipient上的活动插件匹配,因此Group Replication插件必须安装并激活在其他服务器实例上,即使您不想让服务器实例加入组。您可以通过发出以下语句来安装插件:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

在 MySQL 8.0.20 之前的版本中,您不能手动启动克隆操作,如果克隆操作涉及到组成员上正在运行Group Replication。从 MySQL 8.0.20 开始,您可以这样做,前提是克隆操作不删除和替换recipient上的数据。因此,用于启动克隆操作的语句必须包括DATA DIRECTORY子句,如果Group Replication正在运行。