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

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

20.5.2 重新启动组

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

Group Replication 旨在确保数据库服务持续可用，即使组成该组的某些服务器由于计划维护或意外问题而无法参与其中。只要剩余成员占据组的大多数，他们就可以选举新的主服务器并继续作为一个组运行。然而，如果复制组的每个成员都离开组，并且每个成员都通过STOP GROUP_REPLICATION语句或系统关闭停止了 Group Replication，那么该组现在只存在于理论上，作为成员上的一个配置。在这种情况下，要重新创建该组，必须像第一次启动一样通过引导启动。

首次引导组与第二次或后续引导组之间的区别在于，后者情况下，关闭的组的成员可能具有不同的事务集，取决于它们停止或失败的顺序。如果成员具有其他组成员上不存在的事务，则无法加入组。对于 Group Replication，这包括已提交和应用的事务，这些事务在gtid_executed GTID 集中，以及已经认证但尚未应用的事务，这些事务在group_replication_applier通道中。事务何时提交取决于为组设置的事务一致性级别（参见第 20.5.3 节，“事务一致性保证”）。然而，Group Replication 组成员永远不会删除已经认证的事务，这是成员承诺提交事务的声明。

因此，必须从最新的成员开始重新启动复制组，即执行最多事务并获得认证的成员。然后，事务较少的成员可以通过分布式恢复加入并赶上他们缺少的事务。不能假设组的最后已知主成员是组中最新的成员，因为比主成员关闭时间更晚的成员可能有更多的事务。因此，必须重新启动每个成员以检查事务，比较所有事务集，并确定最新的成员。然后可以使用该成员来引导组。

在每个成员关闭后，按照以下步骤安全地重新启动复制组。

1. 依次对每个组成员执行以下步骤，顺序不限：

1. 连接客户端到组成员。如果 Group Replication 尚未停止，请执行 STOP GROUP_REPLICATION 语句并等待 Group Replication 停止。
   
2. 编辑 MySQL 服务器配置文件（通常在 Linux 和 Unix 系统上命名为 my.cnf，在 Windows 系统上命名为 my.ini），并设置系统变量 group_replication_start_on_boot=OFF。此设置防止 MySQL 服务器启动时启动 Group Replication，这是默认设置。
   如果无法在系统上更改该设置，则可以允许服务器尝试启动 Group Replication，这将失败，因为组已完全关闭且尚未引导。如果采用这种方法，请勿在此阶段在任何服务器上设置 group_replication_bootstrap_group=ON。
   
3. 启动 MySQL 服务器实例，并验证 Group Replication 尚未启动（或启动失败）。此阶段不要启动 Group Replication。
   
4. 从组成员收集以下信息：

• gtid_executed GTID 集的内容。您可以通过执行以下语句获取：

mysql> SELECT @@GLOBAL.GTID_EXECUTED

• group_replication_applier 通道上的已认证事务集。您可以通过执行以下语句获取：

mysql> SELECT received_transaction_set FROM \
        performance_schema.replication_connection_status WHERE \
        channel_name="group_replication_applier";

1. 当您从所有组成员收集了事务集后，比较它们以找出哪个成员具有最大的事务集，包括已执行的事务（gtid_executed）和已认证的事务（在 group_replication_applier 通道上）。您可以通过查看 GTID 手动执行此操作，或者使用存储函数比较 GTID 集，如 Section 19.1.3.8, “Stored Function Examples to Manipulate GTIDs” 中所述。
   
2. 使用具有最大事务集的成员引导组，通过连接客户端到组成员并执行以下语句：

mysql> SET GLOBAL group_replication_bootstrap_group=ON;
mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;

1. 非常重要的是不要将设置 group_replication_bootstrap_group=ON 存储在配置文件中，否则当服务器再次重启时���将设置一个具有相同名称的第二个组。
2. 要验证该组现在存在并包含此创始成员，请在引导它的成员上执行此语句：

mysql> SELECT * FROM performance_schema.replication_group_members;

1. 通过在每个成员上执行 START GROUP_REPLICATION 语句，以任意顺序将其他每个成员重新添加到组中：

mysql> START GROUP_REPLICATION;

1. 要验证每个成员是否已加入组，请在任何成员上执行此语句：

mysql> SELECT * FROM performance_schema.replication_group_members;

1. 当成员重新加入组后，如果您编辑了他们的配置文件以设置group_replication_start_on_boot=OFF，您可以再次编辑它们以设置ON（或者移除该系统变量，因为ON是默认值）。
   

20.5.3 事务一致性保证

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

20.5.3.1 理解事务一致性保证

20.5.3.2 配置事务一致性保证

分布式系统（如 Group  Replication）的一个重要影响是作为一个群体提供的一致性保证。换句话说，是分布在群体成员之间的事务全局同步的一致性。本节描述了  Group Replication 如何处理依赖于群体中发生的事件的一致性保证，以及如何最佳配置您的群体的一致性保证。

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

20.5.3.1 理解事务一致性保证

就分布式一致性保证而言，无论是在正常操作还是故障修复操作中，Group Replication  一直是一个最终一致性系统。这意味着一旦传入流量减慢或停止，所有组成员都具有相同的数据内容。与系统一致性相关的事件可以分为控制操作，无论是手动操作还是由故障自动触发；和数据流操作。

对于 Group Replication，可以根据一致性评估的控制操作包括：

• 成员加入或离开，这在 Group Replication 的 Section 20.5.4, “分布式恢复” 和写保护中有所涵盖。
  
• 网络故障，这由围栏模式涵盖。
  
• 在单主组中，主故障切换，也可以是由 group_replication_set_as_primary() 触发的操作。
  

一致性保证和主故障切换

在单主组中，在次级节点被提升为主节点的主故障切换事件中，新的主节点可以立即对应用流量开放，无论复制积压数据有多大，或者可以限制访问直到积压数据被应用。

第一种方法是，在主故障后，组尽可能快地确保稳定的组成员资格，通过选举新的主节点，然后立即允许数据访问，同时仍在应用旧主节点的任何可能的积压数据。确保了写一致性，但在新的主节点应用积压数据时，读取可能暂时检索到陈旧数据。例如，如果客户端  C1 在旧主节点故障前刚写入 A=2 WHERE A=1，当客户端 C1 重新连接到新的主节点时，它可能读取到 A=1，直到新的主节点应用其积压数据并赶上旧主节点离开组的状态。

第二种选择是，在主故障后，系统确保稳定的组成员资格，并像第一种选择一样选举新的主节点，但在这种情况下，组等待新的主节点应用所有积压数据，然后才允许数据访问。这确保了在先前描述的情况下，当客户端 C1 重新连接到新的主节点时，它读取 A=2。然而，这样做的代价是，故障切换所需的时间与积压数据的大小成正比，在正确配置的组上应该很小。

在 MySQL 8.0.14 之前，没有办法配置故障切换策略，默认情况下可用性最大化，如第一种方法所述。在运行 MySQL 8.0.14 及更高版本的成员组中，您可以使用group_replication_consistency变量配置主故障切换期间成员提供的事务一致性保证级别。请参阅一致性对主选举的影响。

数据流操作

数据流与组一致性保证相关，因为读取和写入操作在组中执行，特别是当这些操作分布在所有成员之间时。数据流操作适用于组复制的两种模式：单主和多主，但为了更清晰地解释，本文仅限于单主模式。将传入的读取或写入事务分割到单主组成员的常规方式是将写入路由到主节点，并将读取均匀分布到从节点。由于组应该表现为单个实体，因此可以合理地期望主节点上的写入立即在从节点上可用。虽然组复制是使用实现  Paxos 算法的组通信系统（GCS）协议编写的，但组复制的某些部分是异步的，这意味着数据会异步应用到从节点。这意味着客户端 C2  可以在主节点上写入B=2 WHERE B=1，立即连接到从节点并读取B=1。这是因为从节点仍在应用积压数据，并且尚未应用主节点应用的事务。

事务同步点

您可以根据希望在组中同步事务的时间点配置组的一致性保证。为了帮助您理解概念，本节将简化跨组同步事务的时间点为读取操作时或写入操作时。如果在读取时同步数据，则当前客户端会等待直到给定时间点，即所有先前的更新事务都已应用，然后才能开始执行。使用这种方法，只有此会话受到影响，所有其他并发数据操作不受影响。

如果在写入时同步数据，则写入会话会等待直到所有从节点写入其数据。组复制使用写入的总顺序，因此这意味着等待这个和所有在从节点队列中的先前写入被应用。因此，当使用此同步点时，写入会话等待所有从节点队列被应用。

任何替代方案都确保在描述的客户端 C2 的情况下，即使立即连接到辅助服务器，也始终读取B=2。每种替代方案都有其优点和缺点，这些直接与你的系统工作负载相关。以下示例描述了不同类型的工作负载，并建议哪种同步点是适当的。

想象以下情况：

• 你希望负载均衡你的读取操作，而不需要在从哪个服务器读取时部署额外的限制，以避免读取过时数据，组写入比组读取要少得多。
  
• 如果你有一个主要是只读数据的组，你希望读写事务在提交后到处都被应用，这样后续的读取都是在包含最新写入的最新数据上进行的。这确保你不必为每个只读事务支付同步成本，而只需为读写事务支付。
  

在这些情况下，你应该选择在写入时进行同步。

想象以下情况：

• 你希望负载均衡你的读取操作，而不需要在从哪个服务器读取时部署额外的限制，以避免读取过时数据，组写入比组读取要常见得多。
  
• 你希望你的工作负载中的特定事务始终从组中读取最新数据，例如每当敏感数据更新时（例如文件的凭据或类似数据），你希望强制读取检索到最新值。
  

在这些情况下，你应该选择在读取时进行同步。

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

20.5.3.2 配置事务一致性保证

尽管 事务同步点 部分解释了概念上有两个可以选择的同步点：读取或写入时，但这些术语是一种简化，Group Replication 中使用的术语是：事务执行前 和 事务执行后。一致性级别对由组处理的只读（RO）和读写（RW）事务可能产生不同的影响，正如本节所示。

• 如何选择一致性级别
  
• 一致性级别的影响
  
• 一致性对主选举的影响
  
• 一致性规则下允许的查询
  

以下列表显示了在 Group Replication 中可以使用 group_replication_consistency 变量配置的可能一致性级别，按照事务一致性保证递增的顺序排列：

• EVENTUAL
  无论是 RO 还是 RW 事务在执行时都不会等待前置事务被应用。这是在添加 group_replication_consistency 变量之前 Group Replication 的行为。一个 RW  事务不会等待其他成员应用事务。这意味着一个事务在其他成员之前可能在一个成员上被外部化。这也意味着在主故障转移的情况下，新的主节点可以在之前的主节点的所有事务都被应用之前接受新的  RO 和 RW 事务。RO 事务可能导致过时的值，RW 事务可能由于冲突而导致回滚。
  
• BEFORE_ON_PRIMARY_FAILOVER
  具有新选举的主要成员并正在应用旧主要成员的积压的新  RO 或 RW  事务被保留（未应用），直到任何积压被应用。这确保了主要故障转移发生时，无论是故意还是不经意，客户端始终看到主要成员上的最新值。这保证了一致性，但意味着客户端必须能够处理正在应用积压时的延迟。通常，此延迟应该很小，但这取决于积压的大小。
  
• BEFORE
  RW 事务等待所有先前事务完成后再应用。RO 事务等待所有先前事务完成后再执行。这确保了此事务通过仅影响事务的延迟来读取最新值。通过仅在 RO 事务上使用同步，可以减少每个 RW 事务上的同步开销。此一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。
  
• AFTER
  RW  事务等待直到其更改已应用于所有其他成员。此值对 RO  事务没有影响。此模式确保当本地成员上提交事务时，任何后续事务都会读取已写入的值或任何组成员上更近的值。在主要用于 RO  操作的组中使用此模式，以确保一旦提交，已应用的 RW  事务就会被应用到所有地方。您的应用程序可以使用此模式来确保后续读取获取包括最新写入的最新数据。通过仅在 RW 事务上使用同步，可以减少每个 RO  事务上的同步开销。此一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。
  
• BEFORE_AND_AFTER
  RW 事务等待 1) 所有先前事务完成后再应用和 2) 直到其更改已应用于其他成员。RO 事务等待所有先前事务完成后再执行。此一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。
  

BEFORE 和 BEFORE_AND_AFTER 一致性级别都可以用于 RO 和 RW 事务。AFTER 一致性级别对 RO 事务没有影响，因为它们不生成更改。

如何选择一致性级别

不同的一致性级别为 DBA 和开发人员提供了灵活性，他们可以使用这些级别来设置基础设施；开发人员可以根据其应用程序的要求选择最适合的一致性级别。以下场景展示了如何根据您使用组的方式选择一致性保证级别：

• 场景 1 您希望负载均衡读取而不必担心过时读取，您的组写入操作明显少于组读取操作。在这种情况下，您应选择AFTER。
  
• 场景 2 你有一个应用了大量写入的数据集，并且希望偶尔进行读取而不必担心读取过时数据。在这种情况下，你应该选择BEFORE。
  
• 场景 3 你希望工作负载中的特定事务始终从组中读取最新数据，因此每当敏感数据更新（例如文件的凭据或类似数据）时，你希望强制读取始终读取最新值。在这种情况下，你应该选择BEFORE。
  
• 场景 4 你有一个主要包含只读（RO）数据的组，你希望你的读写（RW）事务一旦提交就在所有地方应用，以便后续读取是在包括最新写入的最新数据上进行的，而且你不需要在每个 RO 事务上进行同步，而只需在 RW 事务上进行。在这种情况下，你应该选择AFTER。
  
• 场景 5  你有一个主要包含只读数据的组，你希望你的读写（RW）事务始终从组中读取最新数据，并且一旦提交就在所有地方应用，以便后续读取是在包括最新写入的最新数据上进行的，而且你不需要在每个只读（RO）事务上进行同步，而只需在  RW 事务上进行。在这种情况下，你应该选择BEFORE_AND_AFTER。
  

你有自由选择强制执行一致性级别的范围。这很重要，因为如果在全局范围设置一致性级别，可能会对组性能产生负面影响。因此，你可以通过在不同范围使用group_replication_consistency系统变量来配置组的一致性级别。

要在当前会话上强制执行一致性级别，请使用会话范围：

> SET @@SESSION.group_replication_consistency= 'BEFORE';

要在所有会话上强制执行一致性级别，请使用全局范围：

> SET @@GLOBAL.group_replication_consistency= 'BEFORE';

在特定会话上设置一致性级别的可能性使你能够利用以下场景：

• 场景 6 给定系统处理几个不需要强一致性级别的指令，但一种指令确实需要强一致性：管理对文档的访问权限。在这种情况下，系统更改访问权限并希望确保所有客户端看到正确的权限。你只需要在这些指令上SET @@SESSION.group_replication_consistency= ‘AFTER’，并将其他指令保留在全局范围设置为EVENTUAL。
  
• 场景 7 在与场景 6 中描述的相同系统上，每天都需要执行一些分析处理的指令，并且因此需要始终读取最新数据。为了实现这一点，你只需要在该特定指令上SET @@SESSION.group_replication_consistency= ‘BEFORE’。
  

总结一下，你不需要以特定的一致性级别运行所有事务，特别是如果只有一些事务实际上需要它。

请注意，在组复制中，所有读写事务都是完全有序的，因此，即使您将一致性级别设置为AFTER，对于当前会话，此事务也会等待直到其更改在所有成员上应用，这意味着等待此事务和所有可能在次要队列中的前置事务。实际上，一致性级别AFTER会等待一切，直到包括此事务在内。

一致性级别的影响

另一种分类一致性级别的方式是根据对组的影响来进行，即，一致性级别对其他成员的影响。

除了在事务流中排序外，一致性级别BEFORE仅影响本地成员。也就是说，它不需要与其他成员协调，也不会对其事务产生影响。换句话说，BEFORE仅影响使用它的事务。

一致性级别AFTER和BEFORE_AND_AFTER对在其他成员上执行的并发事务确实会产生副作用。如果具有EVENTUAL一致性级别的事务在执行具有AFTER或BEFORE_AND_AFTER的事务时开始，其他成员的事务将等待，直到AFTER事务在该成员上提交，即使其他成员的事务具有EVENTUAL一致性级别。换句话说，AFTER和BEFORE_AND_AFTER影响所有ONLINE组成员。

为了进一步说明这一点，想象一个有 3 个成员 M1、M2 和 M3 的组。在成员 M1 上，一个客户端发出：

> SET @@SESSION.group_replication_consistency= AFTER;
> BEGIN;
> INSERT INTO t1 VALUES (1);
> COMMIT;

然后，在应用上述事务时，成员 M2 上的一个客户端发出：

> SET SESSION group_replication_consistency= EVENTUAL;

在这种情况下，即使第二个事务的一致性级别是EVENTUAL，因为它在第一个事务已经在 M2 上处于提交阶段时开始执行，第二个事务必须等待第一个事务完成提交，然后才能执行。

你只能在ONLINE成员上使用一致性级别BEFORE、AFTER和BEFORE_AND_AFTER，尝试在其他状态的成员上使用它们会导致会话错误。

一致性级别不是EVENTUAL的事务会等待直到达到由wait_timeout值配置的超时，其默认值为 8 小时。如果超时，将抛出ER_GR_HOLD_WAIT_TIMEOUT错误。

一致性对初选的影响

本节描述了一个群组的一致性级别如何影响已选出新主节点的单主群组。这样的群组会自动检测故障并调整活跃成员的视图，换句话说，成员配置。此外，如果一个群组以单主模式部署，每当群组成员发生变化时，都会执行检查以检测群组中是否仍有主成员。如果没有，则从次要成员列表中选择一个新的主成员。通常，这被称为次要晋升。

鉴于系统能够自动检测故障并自动重新配置自身，用户可能也期望一旦晋升发生，新的主节点在数据方面与旧主节点完全相同。换句话说，用户可能期望在他能够从新主节点读取和写入时，新主节点上没有待应用的复制事务。实际上，用户可能期望一旦他的应用故障切换到新主节点，甚至暂时也不会有机会读取旧数据或写入旧数据记录。

当在群组上激活并正确调整流量控制时，在晋升后立即从新选出的主节点暂时读取陈旧数据的机会很小，因为不应该有积压，或者如果有积压，那么应该很小。此外，您可能会有一个代理或中间件层，在晋升后管理应用程序对主节点的访问并在该级别强制执行一致性标准。如果您的群组成员使用的是  MySQL 8.0.14 或更高版本，您可以使用 group_replication_consistency 变量指定新主节点在晋升后的行为，该变量控制新选出的主节点是否阻止读取和写入，直到积压完全应用或者如果它的行为类似于运行 MySQL 8.0.13 或更早版本的成员。如果在有待应用的积压的新选出的主节点上设置了 group_replication_consistency 选项为 BEFORE_ON_PRIMARY_FAILOVER，并且在新主节点仍在应用积压时发出事务，则传入事务将被阻止，直到积压完全应用。因此，以下异常情况被防止：

• 对于只读和读写事务，不会出现陈旧的读取。这可以防止陈旧的读取通过新主节点外部化到应用程序中。
  
• 由于与仍在等待应用的积压中的复制读写事务发生写-写冲突，因此读写事务不会出现虚假回滚。
  
• 在读写事务中没有读取偏差，例如：

> BEGIN;
> SELECT x FROM t1; -- x=1 because x=2 is in the backlog;
> INSERT x INTO t2;
> COMMIT;

• 这个查询不应该引起冲突，但会写入过时的数值。

总结一下，当 group_replication_consistency 设置为 BEFORE_ON_PRIMARY_FAILOVER 时，您选择优先考虑一致性而不是可用性，因为每当选举新的主要成员时，读写操作都会被保留。这是在配置组时必须考虑的权衡。还应记住，如果流量控制正常工作，backlog 应该是最小的。请注意，更高的一致性级别 BEFORE、AFTER 和 BEFORE_AND_AFTER 也包括 BEFORE_ON_PRIMARY_FAILOVER 提供的一致性保证。

为了确保组提供相同的一致性级别，无论哪个成员被提升为主要成员，组的所有成员都应该将 BEFORE_ON_PRIMARY_FAILOVER（或更高的一致性级别）持久化到其配置中。例如，在每个成员上执行：

> SET PERSIST group_replication_consistency='BEFORE_ON_PRIMARY_FAILOVER';

这确保了所有成员都以相同的方式行事，并且配置在成员重新启动后仍然保留。

事务不能永远保持挂起状态，如果持续时间超过 wait_timeout，则会返回一个 ER_GR_HOLD_WAIT_TIMEOUT 错误。

在一致性规则下允许的查询

在使用 BEFORE_ON_PRIMARY_FAILOVER 一致性级别时，虽然所有写操作都被保留，但并非所有读操作都被阻塞，以确保您仍然可以在升级后的服务器应用 backlog 时进行检查。这对于调试、监控、可观察性和故障排除非常有用。一些不修改数据的查询是允许的，例如以下内容：

• SHOW 语句 - 从 MySQL 8.0.27 开始，此处仅限于不依赖于数据，仅依赖于状态和配置的语句，如下所列
  
• SET 语句
  
• 不使用表或可加载函数的 DO 语句
  
• EMPTY 语句
  
• USE 语句
  
• 使用针对 performance_schema 和 sys 数据库的 SELECT 语句
  
• 使用针对 infoschema 数据库中的 PROCESSLIST 表的 SELECT 语句
  
• 不使用表或可加载函数的 SELECT 语句
  
• STOP GROUP_REPLICATION 语句
  
• SHUTDOWN 语句
  
• RESET PERSIST 语句
  

允许在 MySQL 8.0.27 中使用的SHOW语句包括SHOW VARIABLES, SHOW  PROCESSLIST, SHOW STATUS, SHOW ENGINE INNODB LOGS, SHOW ENGINE INNODB  STATUS, SHOW ENGINE INNODB MUTEX, SHOW MASTER STATUS, SHOW REPLICA  STATUS, SHOW CHARACTER SET, SHOW COLLATION, SHOW BINARY LOGS, SHOW OPEN  TABLES, SHOW REPLICAS, SHOW BINLOG EVENTS, SHOW WARNINGS, SHOW ERRORS,  SHOW ENGINES, SHOW PRIVILEGES, SHOW PROCEDURE STATUS, SHOW FUNCTION  STATUS, SHOW PLUGINS, SHOW EVENTS, SHOW PROFILE, SHOW PROFILES, 和 SHOW RELAYLOG EVENTS。

20.5.4 分布式恢复

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

20.5.4.1 用于分布式恢复的连接

20.5.4.2 用于分布式恢复的克隆

20.5.4.3 配置分布式恢复

20.5.4.4 分布式恢复的容错性

20.5.4.5 分布式恢复的工作原理

每当成员加入或重新加入复制组时，它必须赶上在其加入之前或离开期间组成员应用的事务。这个过程称为分布式恢复。

加入成员首先通过检查其group_replication_applier通道的中继日志，查看组中已接收但尚未应用的任何事务。如果加入成员以前曾在组中，它可能会发现在离开之前未应用的事务，这种情况下会将其作为第一步应用。新加入组的成员没有任何需要应用的事务。

在此之后，加入成员连接到在线现有成员以进行状态传输。加入成员传输了在其加入组之前或离开期间发生的所有事务，这些事务由现有成员（称为捐赠者）提供。接下来，加入成员应用了在此状态传输过程中组中发生的事务。当此过程完成时，加入成员已经赶上了组中的其余服务器，并开始正常参与组中的活动。

组复制在分布式恢复期间使用这些方法的组合进行状态传输：

• 使用克隆插件的功能进行远程克隆操作，该功能从 MySQL 8.0.17 起可用。要启用此状态传输方法，必须在组成员和加入成员上安装克隆插件。组复制自动配置所需的克隆插件设置，并管理远程克隆操作。
  
• 从捐赠者的二进制日志复制并在加入成员上应用事务。此方法使用一个名为group_replication_recovery的标准异步复制通道，在捐赠者和加入成员之间建立。
  

在加入成员上发出START GROUP_REPLICATION后，组复制会自动选择这些方法的最佳组合进行状态转移。为此，组复制会检查哪些现有成员适合作为捐赠者，加入成员需要从捐赠者那里获取多少事务，以及是否在任何组成员的二进制日志文件中不再存在任何必需的事务。如果加入成员与适当的捐赠者之间的事务差距很大，或者某些必需的事务不在任何捐赠者的二进制日志文件中，组复制将开始进行远程克隆操作的分布式恢复。如果事务差距不大，或者未安装克隆插件，则组复制直接进行从捐赠者的二进制日志进行状态转移。

• 在远程克隆操作期间，加入成员上的现有数据将被删除，并替换为捐赠者的数据副本。当远程克隆操作完成并加入成员重新启动时，将执行从捐赠者的二进制日志进行状态转移，以获取在远程克隆操作进行时组应用的事务。
  
• 在从捐赠者的二进制日志进行状态转移期间，加入成员复制并应用所需的事务从捐赠者的二进制日志中，按照接收到的事务逐个应用，直到二进制日志记录加入成员加入组的点（视图更改事件）。在此过程中，加入成员缓冲组应用的新事务。当从二进制日志的状态转移完成时，加入成员应用缓冲事务。
  

当加入成员与组的所有事务保持最新时，它被声明为在线，并可以作为正常成员参与组，并且分布式恢复完成。

提示

从二进制日志进行状态转移是组复制的分布式恢复的基本机制，如果您的复制组中的捐赠者和加入成员未设置为支持克隆，则这是唯一可用的选项。由于从二进制日志进行状态转移是基于经典的异步复制，如果加入组的服务器根本没有组的数据，或者具有来自非常旧的备份镜像的数据，可能需要很长时间。因此，在将服务器添加到组之前，建议您通过传输一个相当新的服务器快照来设置具有组数据的服务器。这样可以最大程度地减少分布式恢复所需的时间，并减少对捐赠者服务器的影响，因为它们需要保留和传输更少的二进制日志文件。

译文：dev.mysql.com/doc/refman/8.0/en/group-replication-distributed-recovery-connections.html

20.5.4.1 分布式恢复的连接

当一个加入成员在分布式恢复期间连接到在线现有成员进行状态传输时，加入成员在连接上充当客户端，而现有成员充当服务器。当通过这个连接从捐赠者的二进制日志进行状态传输（使用异步复制通道group_replication_recovery）时，加入成员充当副本，而现有成员充当源。当远程克隆操作在这个连接上进行时，加入成员充当接收者，而现有成员充当捐赠者。适用于这些角色的配置设置在  Group Replication 上下文之外也适用于 Group Replication，除非它们被 Group Replication  特定的配置设置或行为所覆盖。

现有成员为分布式恢复向加入成员提供的连接并不是 Group Replication 用于组内在线成员之间通信的连接。

• Group Replication 的组通信引擎（XCom，一种 Paxos 变体）用于远程 XCom 实例之间的 TCP 通信的连接由group_replication_local_address系统变量指定。这个连接用于在线成员之间的 TCP/IP 消息。与本地实例的通信通过使用共享内存的输入通道进行。
  
• 对于分布式恢复，直到 MySQL 8.0.20，组成员向加入成员提供他们的标准 SQL 客户端连接，由 MySQL Server 的hostname和port系统变量指定。如果report_port系统变量指定了替代端口号，则使用该端口号。
  
• 从 MySQL 8.0.21 开始，组成员可以向加入成员提供一组专用客户端连接作为分布式恢复端点的替代列表，允许您单独控制分布式恢复流量，而不是由成员的常规客户端用户连接。您可以使用group_replication_advertise_recovery_endpoints系统变量指定此列表，并在加入组时成员将其分布式恢复端点列表传输给组。默认情况下，成员继续像早期版本一样提供标准 SQL 客户端连接。
  

重要提示

如果加入成员无法使用由 MySQL Server 的hostname系统变量定义的主机名正确识别其他成员，则分布式恢复可能会失败。建议运行 MySQL 的操作系统具有经过正确配置的唯一主机名，可以使用 DNS 或本地设置。服务器用于 SQL 客户端连接的主机名可以在性能模式表replication_group_members的Member_host列中验证。如果多个组成员外部化由操作系统设置的默认主机名，那么加入成员可能无法将其解析为正确的成员地址并无法连接进行分布式恢复。在这种情况下，您可以使用 MySQL Server 的report_host系统变量为每个服务器配置一个唯一的主机名来外部化。

加入成员建立分布式恢复连接的步骤如下：

1. 当成员加入组时，它使用其group_replication_group_seeds系统变量中包含的种子成员列表中的一个连接，最初使用该列表中指定的group_replication_local_address连接。种子成员可能是组的子集。
   
2. 通过此连接，种子成员使用 Group Replication 的成员服务向加入成员提供了一个在线组中所有成员的列表，以视图的形式呈现。成员信息包括每个成员提供的用于分布式恢复的分布式恢复端点或标准 SQL 客户端连接的详细信息。
   
3. 加入成员从此列表中选择一个适合的组成员作为其分布式恢复的捐赠者，遵循第 20.5.4.4 节“分布式恢复的容错”中描述的行为。
   
4. 然后，加入成员尝试使用捐赠者广告的分布式恢复端点连接到捐赠者，依次尝试列表中指定的顺序。如果捐赠者没有提供端点，则加入成员尝试使用捐赠者的标准  SQL 客户端连接。连接的 SSL 要求如第 20.5.4.1.4 节“分布式恢复的 SSL 和身份验证”中描述的group_replication_recovery_ssl_*选项所指定。
   
5. 如果加入成员无法连接到所选的提供者，它将尝试与其他适当的提供者重试，遵循  第 20.5.4.4 节，“分布式恢复的容错性”  中描述的行为。请注意，如果加入成员在不建立连接的情况下耗尽了广告端点列表，则不会回退到提供者的标准 SQL 客户端连接，而是切换到另一个提供者。
   
6. 当加入成员与提供者建立分布式恢复连接时，它将使用该连接进行状态传输，如  第 20.5.4 节，“分布式恢复”  中所述。用于连接的主机和端口在加入成员的日志中显示。请注意，如果使用远程克隆操作，当加入成员在操作结束时重新启动时，它将与新的提供者建立连接，以从二进制日志进行状态传输。这可能是与用于远程克隆操作的原始提供者不同的成员的连接，或者可能是与原始提供者的不同连接。无论如何，分布式恢复过程都将像在原始提供者的情况下一样继续。
   

20.5.4.1.1 选择分布式恢复端点的地址

由 group_replication_advertise_recovery_endpoints 系统变量提供的 IP 地址作为分布式恢复端点不需要为 MySQL Server 配置（即，它们不需要由 admin_address 系统变量指定或在 bind_address 系统变量的列表中）。它们必须分配给服务器。使用的任何主机名必须解析为本地 IP 地址。可以使用 IPv4 和 IPv6 地址。

为了 MySQL Server 配置分布式恢复端点所提供的端口必须通过 port、report_port 或 admin_port 系统变量指定。服务器必须在这些端口上监听 TCP/IP 连接。如果指定了 admin_port，则分布式恢复的复制用户需要 SERVICE_CONNECTION_ADMIN 权限才能连接。选择 admin_port 可以将分布式恢复连接与常规 MySQL 客户端连接分开。

加入的成员依次尝试列表中指定的每个端点。如果group_replication_advertise_recovery_endpoints设置为DEFAULT而不是端点列表，则提供标准的  SQL 客户端连接。请注意，标准的 SQL  客户端连接不会自动包含在分布式恢复端点列表中，并且不会作为备用方案提供，如果捐赠者的端点列表在没有连接的情况下耗尽。如果您希望将标准的 SQL  客户端连接作为多个分布式恢复端点之一提供，您必须在由group_replication_advertise_recovery_endpoints指定的列表中显式包含它。您可以将其放在最后一位，以便作为连接的最后手段。

一个组成员的分布式恢复端点（或标准的 SQL 客户端连接，如果没有提供端点）不需要添加到由group_replication_ip_allowlist（从 MySQL 8.0.22 开始）或group_replication_ip_whitelist地址。加入的成员必须通过允许列表允许的初始连接到组，以便检索分布式恢复的地址或地址。

当设置系统变量并发出START GROUP_REPLICATION语句时，您列出的分布式恢复端点将得到验证。如果列表无法正确解析，或者如果主机上的任何端点无法访问，因为服务器没有在其上监听，Group Replication 将记录错误并且不会启动。

20.5.4.1.2 分布式恢复的压缩

从 MySQL 8.0.18 开始，您可以选择通过从捐赠者的二进制日志进行状态传输的方法为分布式恢复配置压缩。压缩可以使分布式恢复受益，特别是在网络带宽有限且捐赠者必须向加入成员传输许多事务时。group_replication_recovery_compression_algorithms和group_replication_recovery_zstd_compression_level系统变量配置允许的压缩算法，以及在从捐赠者的二进制日志进行状态传输时使用的zstd压缩级别。有关更多信息，请参见第 6.2.8 节，“连接压缩控制”。

请注意，这些压缩设置不适用于远程克隆操作。当远程克隆操作用于分布式恢复时，克隆插件的clone_enable_compression设置适用。

20.5.4.1.3 分布式恢复的复制用户

分布式恢复需要一个具有正确权限的复制用户，以便 Group Replication  可以建立直接成员间的复制通道。复制用户还必须具有正确权限，以在捐赠者上充当远程克隆操作的克隆用户。在每个组成员上进行分布式恢复时必须使用相同的复制用户。有关设置此复制用户的说明，请参见第  20.2.1.3 节，“分布式恢复的用户凭据”。有关保护复制用户凭据的说明，请参见第 20.6.3.1 节，“分布式恢复的安全用户凭据”。

20.5.4.1.4 分布式恢复的 SSL 和身份验证

分布式恢复的 SSL 配置与正常组通信的 SSL 配置是分开的，由服务器的 SSL 设置和group_replication_ssl_mode系统变量确定。对于分布式恢复连接，专用的 Group Replication 分布式恢复 SSL 系统变量可用于配置专门用于分布式恢复的证书和密码。

默认情况下，分布式恢复连接不使用 SSL。要激活它，请设置group_replication_recovery_use_ssl=ON，并按照 Section 20.6.3, “Securing Distributed Recovery Connections”中描述的方式配置 Group Replication 分布式恢复 SSL 系统变量。您需要设置一个用于 SSL 的复制用户。

当配置分布式恢复使用 SSL 时，Group Replication 会将此设置应用于远程克隆操作，以及从捐赠者的二进制日志进行状态传输。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)的设置。

如果您没有为分布式恢复使用 SSL（因此group_replication_recovery_use_ssl设置为OFF），并且 Group Replication 的复制用户帐户使用caching_sha2_password插件（这是 MySQL 8.0 中的默认设置）或sha256_password插件进行身份验证，则会使用 RSA 密钥对进行密码交换。在这种情况下，要么使用group_replication_recovery_public_key_path系统变量指定 RSA 公钥文件，要么使用group_replication_recovery_get_public_key系统变量从源请求公钥，如 Section 20.6.3.1.1, “Replication User With The Caching SHA-2 Authentication Plugin”中所述。

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

20.5.4.2 分布式恢复的克隆

MySQL Server 的克隆插件从 MySQL 8.0.17 开始提供。如果要在组中使用远程克隆操作进行分布式恢复，必须事先设置现有成员和加入成员以支持此功能。如果不想在组中使用此功能，请不要设置，此时组复制仅使用来自二进制日志的状态传输。

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

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

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