MySQL8 中文参考（八十一）（5）

MySQL8 中文参考（八十一）（4）https://developer.aliyun.com/article/1566076

20.5.4.2.1 克隆的先决条件

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

• 捐赠者（现有组成员）和接收者（加入成员）必须安装并激活克隆插件。有关如何执行此操作的说明，请参阅第 7.6.7.1 节，“安装克隆插件”。
  
• 捐赠者和接收者必须运行在相同的操作系统上，并且必须具有相同的 MySQL Server 版本系列。因此，对于运行不同次要 MySQL Server 版本的组，如 MySQL 8.0 和 8.4，克隆不适用。
  在 MySQL 8.0.37 之前，克隆要求捐赠者和接收者是相同的点版本，如果捐赠者或接收者是 MySQL 8.0.36 或更早版本，则仍然适用此限制。
  
• 捐赠者和接收者必须安装并激活组复制插件，捐赠者上激活的任何其他插件（如密钥环插件）也必须在接收者上激活。
  
• 如果分布式恢复配置为使用 SSL（group_replication_recovery_use_ssl=ON），组复制会将此设置应用于远程克隆操作。组复制会自动配置克隆 SSL 选项的设置（clone_ssl_ca、clone_ssl_cert和clone_ssl_key），以匹配您对应的组复制分布式恢复选项的设置（group_replication_recovery_ssl_ca、group_replication_recovery_ssl_cert和group_replication_recovery_ssl_key）。
  
• 在加入复制组的过程中，您无需在clone_valid_donor_list系统变量中设置有效捐赠者列表。组复制会在从现有组成员中选择捐赠者后自动为您配置此设置。请注意，远程克隆操作使用服务器的 SQL 协议主机名和端口。
  
• 克隆插件有许多系统变量来管理远程克隆操作的网络负载和性能影响。组复制不会配置这些设置，因此您可以查看并设置它们，或者允许它们使用默认设置。请注意，当远程克隆操作用于分布式恢复时，克隆插件的clone_enable_compression设置适用于操作，而不是组复制的压缩设置。
  
• 为了在接收端调用远程克隆操作，组复制使用内部的mysql.session用户，该用户已经具有CLONE_ADMIN权限，因此您无需设置此权限。
  
• 作为远程克隆操作的捐赠者上的克隆用户，Group  Replication 使用您为分布式恢复设置的复制用户（在 Section 20.2.1.3, “User Credentials For  Distributed Recovery”中介绍）。因此，您必须在支持克隆的所有组成员上为此复制用户授予BACKUP_ADMIN权限。在为  Group Replication  配置加入成员时，还必须为复制用户授予权限，因为它们在加入组后可以充当捐赠者。在每个组成员上为复制用户授予此权限，您可以在禁用二进制日志记录的每个组成员上单独发出此语句，或者在启用二进制日志记录的一个组成员上发出：

GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';

• 如果您使用START GROUP_REPLICATION在服务器上指定复制用户凭据，而该服务器先前使用CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO提供用户凭据，请确保在进行任何远程克隆操作之前从复制元数据存储库中删除用户凭据。还要确保group_replication_start_on_boot=OFF在加入成员上设置。有关说明，请参见 Section 20.6.3, “Securing Distributed Recovery Connections”。如果不取消用户凭据，则在远程克隆操作期间，这些凭据将传输到加入成员。然后，group_replication_recovery通道可能会意外地使用存储的凭据在原始成员或从原始成员克隆的成员上启动。服务器启动时（包括远程克隆操作后）自动启动 Group Replication 将使用存储的用户凭据，如果操作员未在START GROUP_REPLICATION命令中指定分布式恢复凭据，则也会使用这些凭据。
  

20.5.4.2.2 克隆门槛

当组成员已经设置支持克隆时，group_replication_clone_threshold 系统变量指定了一个阈值，以事务数量表示，用于在分布式恢复中使用远程克隆操作。如果捐赠者的事务和加入成员的事务之间的差距大于这个数字，当技术上可能时，将使用远程克隆操作进行状态传输到加入成员。Group Replication 根据现有组成员的 gtid_executed 集合计算是否已超过阈值。在存在较大事务差距的情况下使用远程克隆操作，可以让您向组中添加新成员，而无需事先手动将组的数据传输到服务器，并且还可以使非常过时的成员更有效地追赶。

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

警告

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

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

20.5.4.2.3 克隆操作

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

注意

当状态转移完成时，集群复制会重新启动加入成员以完成该过程。如果在加入成员上设置了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 SLAVE FOR CHANNEL group_replication_recovery;
Or from MySQL 8.0.22:
RESET REPLICA FOR CHANNEL group_replication_recovery;

远程克隆操作会将存储在表中的设置从捐赠者克隆到接收者，以及数据。组复制管理与组复制通道相关的设置。在配置文件中持久化的组复制成员设置，如组复制本地地址，不会被克隆，也不会在加入成员时更改。组复制还保留与  SSL 使用相关的通道设置，因此这些设置对于每个成员都是独一无二的。

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

如果使用PRIVILEGE_CHECKS_USER帐户来帮助保护复制应用程序（请参阅 Section 19.3.3.2, “Group Replication 通道的权限检查”），从 MySQL 8.0.19 开始，将从捐赠者克隆PRIVILEGE_CHECKS_USER帐户和相关设置到加入的成员。如果设置加入的成员在启动时启动 Group Replication，则自动在适当的复制通道上使用该帐户进行权限检查。（在 MySQL 8.0.18 中，由于一些限制，建议不要在 Group Replication 通道中使用PRIVILEGE_CHECKS_USER帐户。）

20.5.4.2.4 其他目的的克隆

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

在支持克隆的所有版本中，您可以手动启动涉及 Group Replication  已停止的组成员的克隆操作。请注意，由于克隆要求捐赠者和接收者上的活动插件必须匹配，因此即使您不打算使服务器实例加入组，Group  Replication 插件也必须在另一个服务器实例上安装并激活。您可以通过发出以下语句来安装插件：

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

在 MySQL 8.0.20 之前的版本中，如果克隆操作涉及正在运行 Group Replication  的组成员，则无法手动启动克隆操作。从 MySQL 8.0.20  开始，您可以这样做，前提是克隆操作不会删除并替换接收方的数据。因此，启动克隆操作的语句必须包含DATA DIRECTORY子句，如果 Group Replication 正在运行。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-tuning-recovery.html

20.5.4.3 配置分布式恢复

Group Replication 的分布式恢复过程的几个方面可以配置以适应您的系统。

连接尝试次数

对于从二进制日志进行状态传输，Group Replication  限制了加入成员在尝试连接到供体池中的供体时所做的尝试次数。如果达到连接重试限制而没有成功连接，则分布式恢复过程将以错误终止。请注意，此限制指定了加入成员尝试连接到供体的总次数。例如，如果有  2 个组成员是适当的供体，并且连接重试限制设置为 4，加入成员在达到限制之前对每个供体进行 2 次连接尝试。

默认连接重试限制为 10。您可以使用group_replication_recovery_retry_count系统变量来配置此设置。以下命令将最大连接尝试次数设置为 5：

mysql> SET GLOBAL group_replication_recovery_retry_count= 5;

对于远程克隆操作，不适用此限制。Group Replication 仅尝试与每个适当的供体进行一次连接，然后开始尝试从二进制日志进行状态传输。

连接尝试的休眠间隔

对于从二进制日志进行状态传输，group_replication_recovery_reconnect_interval系统变量定义了分布式恢复过程在尝试连接到供体之间应该休眠多长时间。请注意，分布式恢复在每次供体连接尝试后不会休眠。由于加入成员正在连接到不同的服务器而不是重复连接到同一个服务器，它可以假设影响服务器  A 的问题不会影响服务器  B。因此，分布式恢复仅在经过所有可能的供体后暂停。一旦加入组的服务器对组中的每个适当的供体都尝试连接了一次，分布式恢复过程将休眠，时间由group_replication_recovery_reconnect_interval系统变量配置。例如，如果有 2 个组成员是适当的供体，并且连接重试限制设置为 4，加入成员对每个供体进行一次连接尝试，然后休眠连接重试间隔，然后对每个供体进行一次进一步的连接尝试，直到达到限制。

默认连接重试间隔为 60 秒，您可以动态更改此值。以下命令将分布式恢复捐赠者连接重试间隔设置为 120 秒：

mysql> SET GLOBAL group_replication_recovery_reconnect_interval= 120;

对于远程克隆操作，此间隔不适用。在开始尝试从二进制日志进行状态转移之前，Group Replication 仅对每个适当的捐赠者进行一次连接尝试。

在线标记加入成员

当分布式恢复成功完成从捐赠者到加入成员的状态转移后，加入成员可以在组中标记为在线并准备参与。默认情况下，在加入成员接收并应用了其缺失的所有事务后才会执行此操作。可选地，您可以允许在加入成员接收并认证（即完成冲突检测）其缺失的所有事务后，但在应用它们之前将其标记为在线。如果您想这样做，请使用group_replication_recovery_complete_at系统变量来指定替代设置TRANSACTIONS_CERTIFIED。

dev.mysql.com/doc/refman/8.0/en/group-replication-distributed-recovery-fault.html

20.5.4.4 分布式恢复的容错性

Group Replication 的分布式恢复过程具有多项内置措施，以确保在过程中出现任何问题时的容错性。

从当前视图中的适当在线组成员列表中随机选择分布式恢复的捐赠者。选择随机捐赠者意味着当多个成员进入组时，同一服务器不会被多次选择的机会很大。从  MySQL 8.0.17 开始，对于从二进制日志进行状态转移，加入者只选择运行低于或等于自身的 MySQL Server  补丁版本的捐赠者。对于早期版本，所有在线成员都可以成为捐赠者。对于远程克隆操作，加入者只选择与自身运行相同补丁版本的捐赠者。请注意，当加入成员在操作结束时重新启动时，它会与新的捐赠者建立连接，以从二进制日志进行状态转移，这可能是与用于远程克隆操作的原始捐赠者不同的成员。

在以下情况下，Group Replication 检测到分布式恢复中的错误，自动切换到新的捐赠者，并重试状态转移：

• 连接错误 - 存在身份验证问题或与候选捐赠者建立连接的其他问题。
  
• 复制错误 - 用于从二进制日志进行状态转移的复制线程之一（接收器或应用程序线程）失败。由于此状态转移方法使用现有的 MySQL 复制框架，因此可能会出现一些瞬态错误导致接收器或应用程序线程出错。
  
• 远程克隆操作错误 - 远程克隆操作失败或在完成之前停止。
  
• 捐赠者离开组 - 捐赠者离开组，或者在状态转移正在进行时，在捐赠者上停止 Group Replication。
  

Performance Schema 表replication_applier_status_by_worker显示导致最后一次重试失败的错误。在这些情况下，错误后的新连接将尝试与新的候选捐赠者建立连接。在错误事件中选择不同的捐赠者意味着新的候选捐赠者可能不会有相同的错误。如果安装了克隆插件，Group  Replication 首先尝试与每个适当的在线支持克隆的捐赠者进行远程克隆操作。如果所有这些尝试失败，Group Replication  将尝试依次从所有适当的捐赠者进行二进制日志状态转移，如果可能的话。

警告

对于远程克隆操作，接收方（加入成员）上的用户创建的表空间和数据在远程克隆操作开始传输数据之前被删除。如果远程克隆操作开始但未完成，加入成员可能会留下部分原始数据文件集，或者没有用户数据。如果在数据完全克隆之前停止克隆操作，捐赠者传输的数据将从接收方中删除。Group  Replication 会自动重试克隆操作，以修复这种情况。

在以下情况下，分布式恢复过程无法完成，加入成员将离开组：

• 清除的事务 - 加入成员需要的事务不在任何在线组成员的二进制日志文件中，并且数据无法通过远程克隆操作获取（因为未安装克隆插件，或者尝试了所有可能的捐赠者但失败）。因此，加入成员无法赶上组的进度。
  
• 额外的事务 - 加入成员已经包含一些组中不存在的事务。如果进行了远程克隆操作，这些事务将被删除和丢失，因为加入成员上的数据目录被擦除。如果进行了从捐赠者的二进制日志进行状态传输，这些事务可能会与组的事务发生冲突。有关处理此情况的建议，请参阅额外事务。
  
• 连接重试限制已达到 - 加入成员已经尝试了连接重试限制允许的所有连接尝试。您可以使用group_replication_recovery_retry_count系统变量进行配置（参见第 20.5.4.3 节，“配置分布式恢复”）。
  
• 没有更多的捐赠者 - 加入成员已经尝试了每个在线支持克隆的捐赠者进行远程克隆操作（如果安装了克隆插件），然后尝试了每个适当的在线捐赠者进行二进制日志的状态传输，如果可能的话。
  
• 加入成员离开组 - 加入成员离开组或在状态传输进行中时，加入成员上的 Group Replication 停止。
  

如果加入成员意外离开组，因此在上述任何情况下（除最后一种情况外），它将执行group_replication_exit_state_action系统变量指定的操作。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-view-changes.html

20.5.4.5 分布式恢复的工作原理

当 Group Replication  的分布式恢复过程从二进制日志中执行状态传输时，为了使加入的成员与捐赠者在特定时间点上同步，加入的成员和捐赠者使用 GTIDs（参见  Section 19.1.3, “Replication with Global Transaction  Identifiers”）。然而，GTIDs  只提供了加入成员缺失的事务信息。它们并不能帮助标记加入群组的服务器必须追赶到的特定时间点，也不能传递认证信息。这是二进制日志视图标记的工作，它们标记了二进制日志流中的视图更改，并且包含额外的元数据信息，为加入成员提供缺失的与认证相关的数据。

本主题解释了视图更改的作用以及视图更改标识符，以及执行从二进制日志中进行状态传输的步骤。

视图和视图更改

一个视图对应于在当前配置中积极参与的一组成员，换句话说就是在特定时间点。他们在群组中正常运行并在线。

视图更改发生在群组配置发生修改时，比如成员加入或离开。任何群组成员变更都会导致独立的视图更改，同时在同一逻辑时间点向所有成员通信。

视图标识符唯一标识一个视图。每当视图更改发生时，它就会生成。

在群组通信层，视图更改及其相关的视图标识符标记了成员加入之前和之后交换的数据之间的边界。这个概念通过二进制日志事件实现：“视图更改日志事件”（VCLE）。视图标识符被记录下来，以划分在群组成员身份发生更改之前和之后传输的事务。

视图标识符本身由两部分构成：一个随机生成的部分和一个单调递增的整数。随机生成的部分在创建组时生成，并在组中至少有一个成员时保持不变。整数在每次视图更改发生时递增。使用这两个不同的部分使视图标识符能够识别由成员加入或离开引起的增量组更改，并且能够识别所有成员离开组导致的完全组关闭的情况，因此不会留下任何关于组处于何种视图的信息。在组从一开始创建时随机生成标识符的部分确保二进制日志中的数据标记保持唯一，并且在完全组关闭后不会重复使用相同的标识符，因为这将导致未来的分布式恢复出现问题。

开始：稳定组

所有服务器都在线并处理来自组的传入交易。一些服务器可能在复制交易方面稍有落后，但最终它们会收敛。该组充当一个分布式和复制的数据库。

图 20.8 稳定组

视图更改：成员加入

每当新成员加入组，因此执行视图更改时，每个在线服务器都会将视图更改日志事件排队等待执行。这是因为在视图更改之前，服务器上可以排队应用的多个交易，因此这些属于旧视图。在它们之后排队视图更改事件可以保证正确标记此事件发生的时间。

与此同时，加入的成员从在线服务器列表中选择一个适当的捐赠者，如成员服务通过视图抽象所述。一个成员在视图 4 上加入，而在线成员将视图更改事件写入二进制日志。

图 20.9 成员加入

状态转移：追赶

如果组成员和加入成员都使用克隆插件进行设置（参见第 20.5.4.2 节，“用于分布式恢复的克隆”），并且加入成员与组之间的事务差异超过了远程克隆操作的阈值（group_replication_clone_threshold），则  Group Replication  将开始使用远程克隆操作进行分布式恢复。如果所需事务不再存在于任何组成员的二进制日志文件中，则还会执行远程克隆操作。在远程克隆操作期间，加入成员上的现有数据将被删除，并替换为捐赠者的数据副本。当远程克隆操作完成并加入成员重新启动后，将从捐赠者的二进制日志进行状态转移，以获取在远程克隆操作进行时组应用的事务。如果没有大的事务间隙，或者未安装克隆插件，则  Group Replication 直接进行从捐赠者的二进制日志进行状态转移。

对于从捐赠者的二进制日志进行状态转移，加入成员与捐赠者之间建立连接并开始状态转移。这种与捐赠者的交互会一直持续，直到加入组的服务器的应用程序线程处理与加入组时触发的视图更改日志事件相对应的视图更改日志事件。换句话说，加入组的服务器会从捐赠者进行复制，直到到达与其当前所在的视图标记相匹配的视图标记为止。

图 20.10 状态转移：追赶上

由于视图标识符在同一逻辑时间传输到组中的所有成员，因此加入组的服务器知道应在哪个视图标识符处停止复制。这避免了复杂的 GTID 集计算，因为视图标识符清楚地标记了哪些数据属于每个组视图。

当加入组的服务器从捐赠者进行复制时，同时也会缓存来自组的传入事务。最终，它停止从捐赠者进行复制，并切换到应用那些已经缓存的事务。

图 20.11 排队事务

完成：追赶上

当加入组的服务器识别到具有预期视图标识符的视图更改日志事件时，与提供者的连接将被终止，并开始应用缓存的事务。虽然它在二进制日志中充当标记，分隔视图更改，但视图更改日志事件还扮演另一个角色。它传达了所有服务器在加入组时感知到的认证信息，换句话说是最后一次视图更改。没有它，加入组的服务器将没有必要的信息来认证（检测冲突）后续事务。

追赶的持续时间不确定，因为它取决于工作负载和事务进入组的速率。这个过程完全在线进行，加入组的服务器在追赶时不会阻塞任何其他服务器。因此，当服务器进入这个阶段时落后的事务数量可能会因工作负载而变化，从而增加或减少。

当加入组的服务器达到零排队事务并且其存储的数据与其他成员相同时，其公共状态变为在线。

图 20.12 实例在线

20.5.5 支持 IPv6 和混合 IPv6 和 IPv4 组

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-ipv6.html

从 MySQL 8.0.14 开始，Group Replication 组成员可以使用 IPv6 地址作为组内通信的替代方案，而不是  IPv4 地址。要使用 IPv6 地址，服务器主机上的操作系统和 MySQL Server 实例都必须配置为支持 IPv6。有关为服务器实例设置  IPv6 支持的说明，请参见 Section 7.1.13, “IPv6 Support”。

IPv6 地址，或解析为其的主机名，可以被指定为成员在 group_replication_local_address 选项中提供给其他成员连接的网络地址。当与端口号一起指定时，IPv6 地址必须用方括号指定，例如：

group_replication_local_address= "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061"

在 group_replication_local_address 中指定的网络地址或主机名被 Group  Replication 用作复制组内组成员的唯一标识符。如果为服务器实例指定的 Group Replication 本地地址的主机名解析为  IPv4 和 IPv6 地址，那么始终使用 IPv4 地址进行 Group Replication 连接。指定为 Group  Replication 本地地址的地址或主机名与 MySQL 服务器 SQL 协议主机和端口不同，并且不在服务器实例的 bind_address 系统变量中指定。为了 Group Replication 的 IP 地址权限目的（参见 Section 20.6.4, “Group Replication IP Address Permissions”），您在 group_replication_local_address 中为每个组成员指定的地址必须添加到复制组中其他服务器的 group_replication_ip_allowlist（从 MySQL 8.0.22 开始）或 group_replication_ip_whitelist 系统变量的列表中。

复制组可以包含将 IPv6 地址作为其 Group Replication 本地地址的成员组合，以及呈现 IPv4 地址的成员。当服务器加入这样的混合组时，必须使用种子成员在 group_replication_group_seeds 选项中广告的协议进行初始联系，无论是 IPv4 还是 IPv6。如果组的任何种子成员在 group_replication_group_seeds 选项中列出了具有 IPv6 地址的情况，而加入成员具有 IPv4 Group Replication  本地地址，或者反之，则还必须为加入成员为所需协议设置和允许替代地址（或解析为该协议地址的主机名）。如果加入成员没有适当协议的允许地址，则其连接尝试将被拒绝。替代地址或主机名只需要添加到复制组中其他服务器的  group_replication_ip_allowlist（从 MySQL 8.0.22 开始）或 group_replication_ip_whitelist 系统变量中，而不需要添加到加入成员的 group_replication_local_address 值（该值只能包含单个地址）。

例如，服务器 A 是一个组的种子成员，并具有以下 Group Replication 的配置设置，以便在 group_replication_group_seeds 选项中广告 IPv6 地址：

group_replication_bootstrap_group=on
group_replication_local_address= "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061"
group_replication_group_seeds= "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061"

服务器 B 是组的加入成员，并具有以下 Group Replication 的配置设置，以便具有 IPv4 Group Replication 本地地址：

group_replication_bootstrap_group=off
group_replication_local_address= "203.0.113.21:33061"
group_replication_group_seeds= "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061"

服务器 B 还具有替代 IPv6 地址 2001:db8:8b0:40:3d9c:cc43:e006:19e8。为了成功加入组，服务器 B 的 IPv4 Group Replication 本地地址和其替代 IPv6 地址都必须列在服务器 A 的允许列表中，如下例所示：

group_replication_ip_allowlist=
"203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,
2001:db8:8b0:40:3d9c:cc43:e006:19e8"

作为 Group Replication IP 地址权限的最佳实践，服务器 B（以及所有其他组成员）应具有与服务器 A 相同的允许列表，除非安全要求另有规定。

如果复制组的任何成员或所有成员使用不支持在组复制中使用 IPv6 地址的较旧 MySQL Server 版本，则成员无法使用 IPv6  地址（或解析为 IPv6 地址的主机名）作为其组复制本地地址参与组。这适用于至少一个现有成员使用 IPv6  地址且不支持此功能的新成员尝试加入的情况，以及新成员尝试使用 IPv6  地址加入但组中至少有一个成员不支持此功能的情况。在每种情况下，新成员都无法加入。要使加入成员提供 IPv4 地址进行组通信，您可以将 group_replication_local_address 的值更改为 IPv4 地址，或配置您的 DNS 将加入成员的现有主机名解析为 IPv4 地址。在将每个组成员升级到支持 IPv6 用于组复制的 MySQL Server 版本后，您可以将每个成员的 group_replication_local_address 值更改为 IPv6 地址，或配置您的 DNS 提供 IPv6 地址。更改 group_replication_local_address 的值仅在停止并重新启动组复制时生效。

IPv6 地址还可以用作分布式恢复端点，从 MySQL 8.0.21 开始，可以使用 group_replication_advertise_recovery_endpoints 系统变量指定。在此列表中使用的地址适用相同的规则。请参阅 Section 20.5.4.1, “Connections for Distributed Recovery”。

20.5.6 使用 MySQL Enterprise Backup 与组复制

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-enterprise-backup.html

MySQL Enterprise Backup 是 MySQL Server 的商业许可备份实用程序，可与MySQL Enterprise Edition一起使用。本节解释了如何使用 MySQL Enterprise Backup 备份并随后恢复组复制成员。相同的技术可以用于快速向组中添加新成员。

使用 MySQL Enterprise Backup 备份组复制成员

备份组复制成员类似于备份独立的 MySQL 实例。以下说明假定您已经熟悉如何使用 MySQL Enterprise Backup  执行备份；如果不是这种情况，请查看 MySQL Enterprise Backup 8.0 用户指南，特别是备份数据库服务器。还请注意授予  MySQL 特权给备份管理员和使用 MySQL Enterprise Backup 与组复制中描述的要求。

考虑以下具有三个成员s1、s2和s3的组，运行在具有相同名称的主机上：

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | ONLINE       |
+-------------+-------------+--------------+

使用 MySQL Enterprise Backup，在其主机上发出以下命令，例如，创建s2的备份：

s2> mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/backups/my.mbi_`date +%d%m_%H%M` \
          --backup-dir=/backups/backup_`date +%d%m_%H%M` --user=root -p \
--host=127.0.0.1 backup-to-image

注意

• *对于 MySQL Enterprise Backup 8.0.18 及更早版本，*如果系统变量sql_require_primary_key设置为ON，MySQL Enterprise Backup 无法在服务器上记录备份进度。这是因为服务器上的backup_progress表是一个 CSV 表，不支持主键。在这种情况下，mysqlbackup在备份操作期间会发出以下警告：

181011 11:17:06 MAIN WARNING: MySQL query 'CREATE TABLE IF NOT EXISTS
mysql.backup_progress( `backup_id` BIGINT NOT NULL, `tool_name` VARCHAR(4096)
NOT NULL, `error_code` INT NOT NULL, `error_message` VARCHAR(4096) NOT NULL,
`current_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP               ON
UPDATE CURRENT_TIMESTAMP,`current_state` VARCHAR(200) NOT NULL ) ENGINE=CSV
DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_bin': 3750, Unable to create a table
without PK, when system variable 'sql_require_primary_key' is set. Add a PK
to the table or unset this variable to avoid this message. Note that tables
without PK can cause performance problems in row-based replication, so please
consult your DBA before changing this setting.
181011 11:17:06 MAIN WARNING: This backup operation's progress info cannot be
logged.

• 这并不会阻止mysqlbackup完成备份。
• 对于 MySQL Enterprise Backup 8.0.20 及更早版本，当备份次要成员时，由于 MySQL Enterprise Backup 无法将备份状态和元数据写入只读服务器实例，可能会在备份操作期间发出类似以下警告：

181113 21:31:08 MAIN WARNING: This backup operation cannot write to backup
progress. The MySQL server is running with the --super-read-only option.

• 您可以通过在备份命令中使用--no-history-logging选项来避免警告。对于 MySQL Enterprise Backup 8.0.21 及更高版本，这不是问题—请参阅使用 MySQL Enterprise Backup 与组复制获取详细信息。

MySQL8 中文参考（八十一）（6）https://developer.aliyun.com/article/1566078