18.5.4.2 分布式恢复克隆_MySQL 8.0 参考手册

MySQL 8.0 参考手册 / 第十八章组复制 / 18.5 组复制操作 / 18.5.4 分布式恢复 / 18.5.4.2 分布式恢复克隆

18.5.4.2 分布式恢复克隆

MySQL Server 的克隆插件从 MySQL 8.0.17 开始可用。如果要在群组内使用远程克隆操作进行分布式恢复，则必须事先设置现有成员和加入成员以支持此功能。如果你不想在一个组中使用这个功能，不要设置它，在这种情况下组复制只使用二进制日志的状态传输。

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

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

18.5.4.2.1 克隆的先决条件

有关设置和配置克隆插件的完整说明，请参阅第 5.6.7 节，“克隆插件”。第 5.6.7.3 节“克隆远程数据”中介绍了远程克隆操作的详细先决条件。对于Group Replication，需要注意以下关键点和区别：

捐赠者（现有群组成员）和接收者（加入成员）必须安装并激活克隆插件。有关执行此操作的说明，请参阅第 5.6.7.1 节，“安装克隆插件”。
捐赠者和接受者必须在同一操作系统上运行，并且必须具有相同的MySQL Server版本（必须为MySQL 8.0.17或更高版本以支持克隆插件）。因此，克隆不适用于成员运行不同 MySQL Server 版本的组。
捐赠者和接受者必须安装并激活 Group Replication 插件，捐赠者上激活的任何其他插件（例如密钥环插件）也必须在接受者上激活。
如果分布式恢复配置为使用 SSL ( group_replication_recovery_use_ssl=ON)，组复制将此设置应用于远程克隆操作。Group Replication 会自动配置克隆 SSL 选项（clone_ssl_ca、 clone_ssl_cert和 clone_ssl_key）的设置，以匹配相应 Group Replication 分布式恢复选项（group_replication_recovery_ssl_ca、 group_replication_recovery_ssl_cert和 group_replication_recovery_ssl_key）的设置。
您不需要 clone_valid_donor_list 为了加入复制组而在系统变量中设置有效捐赠者列表。Group Replication 在从现有组成员中选择一个捐赠者后，会自动为您配置此设置。请注意，远程克隆操作使用服务器的 SQL 协议主机名和端口。
克隆插件有许多系统变量来管理远程克隆操作的网络负载和性能影响。Group Replication 不配置这些设置，因此您可以查看它们并根据需要进行设置，或者允许它们默认。请注意，当远程克隆操作用于分布式恢复时，克隆插件的 clone_enable_compression 设置适用于该操作，而不是组复制压缩设置。
要在接收者上调用远程克隆操作，Group Replication 使用内部 mysql.session用户，该用户已经拥有CLONE_ADMIN权限，因此您无需进行设置。
作为远程克隆操作的供体上的克隆用户，组复制使用您为分布式恢复设置的复制用户（在第 18.2.1.3 节“分布式恢复的用户凭证”中介绍）。因此，你必须给 BACKUP_ADMIN此复制用户对支持克隆的所有组成员的特权。当您为组复制配置复制用户时，还要授予复制用户加入成员的权限，因为他们在加入组后可以充当捐助者。同一个复制用户用于每个组成员的分布式恢复。要将此权限授予现有成员的复制用户，您可以在禁用二进制日志记录的情况下对每个组成员单独发出此语句，或者在启用二进制日志记录的一个组成员上发出此语句：
```
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
```
如果您用于在以前使用| START GROUP_REPLICATION提供用户凭据的服务器上指定复制用户凭据 , 请确保在进行任何远程克隆操作之前从复制元数据存储库中删除用户凭据。还要确保在加入成员上设置。有关说明，请参阅第 18.6.3 节，“保护分布式恢复连接”。如果您不取消设置用户凭据，它们将在远程克隆操作期间传输给加入的成员。这 CHANGE REPLICATION SOURCE TOCHANGE MASTER TOgroup_replication_start_on_boot=OFFgroup_replication_recovery然后可能会在原始成员或从中克隆的成员上无意中使用存储的凭据启动通道。在服务器启动时自动启动组复制（包括在远程克隆操作之后）将使用存储的用户凭据，如果操作员未在命令中指定分布式恢复凭据，它们也会被使用 START GROUP_REPLICATION 。

18.5.4.2.2 克隆阈值

当组成员设置为支持克隆时， group_replication_clone_threshold 系统变量指定一个阈值，表示为事务数，用于在分布式恢复中使用远程克隆操作。如果捐赠者的交易与加入成员的交易之间的差距大于此数字，则在技术上可行时，将使用远程克隆操作将状态转移到加入成员。Group Replication根据 gtid_executed现有组成员的集合。在出现大事务间隙时使用远程克隆操作，您可以将新成员添加到组中，而无需事先手动将组数据传输到服务器，还可以使非常过时的成员更有效地赶上进度。

Group Replication 系统变量的默认设置 group_replication_clone_threshold 非常高（GTID 中事务允许的最大序列号），因此它有效地停用了任何可能从二进制日志进行状态传输的克隆。要使 Group Replication 能够在更合适的情况下为状态传输选择远程克隆操作，请设置系统变量以指定多个事务作为您希望克隆发生的事务间隙。

警告

不要 group_replication_clone_threshold 在活动组中使用低设置。如果在进行远程克隆操作的过程中，组内发生了超过阈值的事务数，则加入成员在重启后会再次触发远程克隆操作，并且可以无限继续下去。为避免这种情况，请确保将阈值设置为高于远程克隆操作期间您预计在组中发生的事务数。

当无法从捐助者的二进制日志传输状态时，组复制会尝试执行远程克隆操作，而不管您的阈值如何，例如，因为加入成员所需的事务在任何现有组成员的二进制日志中都不可用。gtid_purged组复制根据现有组成员的集合来识别这一点。当所需的事务在任何成员的二进制日志文件中不可用时，您不能使用 group_replication_clone_threshold 系统变量来停用克隆，因为在这种情况下，克隆是手动将数据传输到加入成员的唯一替代方法。

18.5.4.2.3 克隆操作

为克隆设置组成员和加入成员时，组复制会为您管理远程克隆操作。远程克隆操作可能需要一些时间才能完成，具体取决于数据的大小。有关监视过程的信息，请参阅第 5.6.7.10 节“监视克隆操作”。

笔记

状态转移完成后，Group Replication 会重启加入的成员以完成该过程。如果 group_replication_start_on_boot=OFF 在加入成员上设置，例如因为您在 START GROUP_REPLICATION 语句中指定了复制用户凭据，则必须START GROUP_REPLICATION在此重新启动后再次手动发出。如果 group_replication_start_on_boot=ON 启动 Group Replication 所需的其他设置是在配置文件中或使用SET PERSIST语句设置的，则您无需干预，该过程会自动继续以使加入的成员联机。

如果远程克隆过程耗时较长，在 MySQL 8.0.22 之前的版本中，可能会在这段时间内为组积累的认证信息集变得太大而无法传输给加入的成员。在这种情况下，加入的成员会记录一条错误消息并且不会加入该组。从 MySQL 8.0.22 开始，Group Replication 以不同的方式管理应用事务的垃圾收集过程，以避免这种情况。在早期版本中，如果您确实看到此错误，请在远程克隆操作完成后等待两分钟，以便进行一轮垃圾收集以减少组认证信息的大小。

RESET SLAVE FOR CHANNEL group_replication_recovery;
Or from MySQL 8.0.22:
RESET REPLICA FOR CHANNEL group_replication_recovery;

远程克隆操作克隆保存在表中的设置，从捐赠者到接受者，以及数据。Group Replication 管理专门与 Group Replication 通道相关的设置。保存在配置文件中的组复制成员设置（例如组复制本地地址）不会被克隆，也不会在加入成员上更改。Group Replication 还保留与 SSL 使用相关的通道设置，因此这些设置对于单个成员是唯一的。

如果捐赠者用于复制通道的复制用户凭证已使用|group_replication_recovery存储在复制元数据存储库中声明，它们在克隆后转移给加入成员并由其使用，并且它们必须在那里有效。使用存储的凭据，所有通过远程克隆操作接收状态传输的组成员因此自动接收用于分布式恢复的复制用户和密码。如果您在CHANGE REPLICATION SOURCE TOCHANGE MASTER TOSTART GROUP_REPLICATION声明，这些用于启动远程克隆操作，但它们不会在克隆后传递给加入成员使用。如果您不希望凭证传输给新加入者并记录在那里，请确保在远程克隆操作发生之前取消设置它们，如第 18.6.3 节“保护分布式恢复连接”中所述，并使用START GROUP_REPLICATION 它们来提供它们。

如果一个PRIVILEGE_CHECKS_USER帐户已用于帮助保护复制应用程序（请参阅第 17.3.3.2 节，“组复制通道的权限检查”），从 MySQL 8.0.19 开始，PRIVILEGE_CHECKS_USER捐赠者的帐户和相关设置将被克隆到加入成员。如果加入成员设置为在启动时启动组复制，它会自动使用该帐户在适当的复制通道上进行权限检查。（在MySQL 8.0.18中，由于诸多限制，建议您不要使用 PRIVILEGE_CHECKS_USER具有Group Replication通道的账号。）

18.5.4.2.4 为其他目的克隆

Group Replication 启动并管理用于分布式恢复的克隆操作。已设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，您可能希望通过从作为捐赠者的组成员克隆来创建一个新的服务器实例，但您不希望新的服务器实例立即加入该组，或者可能永远不会。

在支持克隆的所有版本中，您可以手动启动涉及停止组复制的组成员的克隆操作。请注意，因为克隆要求捐助者和接受者上的活动插件必须匹配，所以组复制插件必须在另一个服务器实例上安装并处于活动状态，即使您不打算让该服务器实例加入组。您可以通过发出以下语句来安装插件：

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

在 MySQL 8.0.20 之前的版本中，如果操作涉及正在运行组复制的组成员，则无法手动启动克隆操作。从 MySQL 8.0.20 开始，您可以执行此操作，前提是克隆操作不会删除和替换收件人上的数据。因此，启动克隆操作的语句必须包含 DATA DIRECTORYif Group Replication is running 子句。