MySQL8 中文参考（八十二）（2）

MySQL8 中文参考（八十二）（1）https://developer.aliyun.com/article/1565901

20.7.3 单一共识领导者

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

默认情况下，Group Replication 的组通信引擎（XCom，一种 Paxos 变体）使用复制组的每个成员作为领导者。从  MySQL 8.0.27  开始，当组处于单主模式时，组通信引擎可以使用单个领导者来驱动共识。在单主模式下使用单一共识领导者可以提高性能和韧性，特别是当组的某些次要成员当前无法访问时。

要使用单一共识领导者，组必须按以下方式配置：

• 组必须处于单主模式。
  
• group_replication_paxos_single_leader 系统变量必须设置为 ON。默认设置为 OFF 时，该行为被禁用。您必须对复制组进行完全重启（引导）以使 Group Replication 生效对此设置的更改。
  
• Group Replication 通信协议版本必须设置为 8.0.27 或更高。使用 group_replication_get_communication_protocol() 函数查看组的通信协议版本。如果使用较低版本，则组无法使用此行为。如果所有组成员都支持，您可以使用 group_replication_set_communication_protocol() 函数将组的通信协议设置为更高版本。MySQL InnoDB Cluster 会自动管理通信协议版本。有关更多信息，请参见 Section  20.5.1.4, “Setting a Group’s Communication Protocol Version”。
  

当配置完成后，Group Replication 指示组通信引擎使用组的主节点作为单一领导者来驱动共识。当选举出新的主节点时，Group  Replication 会告知组通信引擎使用新的主节点。如果主节点当前不健康，组通信引擎会使用其他成员作为共识领导者。性能模式表 replication_group_communication_information 显示当前首选和实际共识领导者，首选领导者是 Group Replication 的选择，实际领导者是组通信引擎选择的领导者。

如果组处于多主模式，具有较低的通信协议版本，或者行为被group_replication_paxos_single_leader设置禁用，则所有成员都被用作领导者来推动共识。在这种情况下，性能模式表replication_group_communication_information显示所有成员都是首选和实际领导者。

在性能模式表replication_group_communication_information中的字段WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE显示组是否支持使用单个领导者，即使在查询的成员上当前设置为OFF的group_replication_paxos_single_leader。如果组是在启动时使用group_replication_paxos_single_leader设置为ON，并且其通信协议版本为 MySQL 8.0.27 或更高版本，则该字段设置为 1。此信息仅对处于ONLINE或RECOVERING状态的组成员返回。

20.7.4 消息压缩

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

对于在线群组成员之间发送的消息，Group Replication 默认启用消息压缩。特定消息是否被压缩取决于您使用group_replication_compression_threshold系统变量配置的阈值。超过指定字节数的有效载荷的消息将被压缩。

默认压缩阈值为 1000000 字节。您可以使用以下语句将压缩阈值增加到 2MB，例如：

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold = 2097152;
START GROUP_REPLICATION;

如果将group_replication_compression_threshold设置为零，则消息压缩将被禁用。

Group Replication 使用 LZ4 压缩算法来压缩组内发送的消息。请注意，LZ4 压缩算法支持的最大输入大小为 2113929216 字节。这个限制低于group_replication_compression_threshold系统变量的最大可能值，该值与 XCom 接受的最大消息大小相匹配。因此，LZ4 最大输入大小是消息压缩的实际限制，当启用消息压缩时，超过此大小的事务无法提交。使用 LZ4 压缩算法时，请不要为group_replication_compression_threshold设置大于 2113929216 字节的值。

Group Replication 不要求所有组成员的group_replication_compression_threshold的值相同。然而，建议在所有组成员上设置相同的值，以避免事务不必要的回滚、消息传递失败或消息恢复失败。

从 MySQL 8.0.18 开始，您还可以为通过从捐赠者的二进制日志进行状态传输的分布式恢复发送的消息配置压缩。这些消息的压缩，从已在组中的捐赠者发送到加入成员，是通过group_replication_recovery_compression_algorithms和group_replication_recovery_zstd_compression_level系统变量分别控制。有关更多信息，请参见 Section 6.2.8，“连接压缩控制”。

二进制日志事务压缩（自 MySQL 8.0.20 起可用），由binlog_transaction_compression系统变量激活，也可用于节省带宽。当事务负载在组成员之间传输时保持压缩。如果您将二进制日志事务压缩与  Group Replication  的消息压缩结合使用，消息压缩的作用机会较少，但仍可压缩标头以及未压缩的事件和事务负载。有关二进制日志事务压缩的更多信息，请参见 Section  7.4.4.5，“二进制日志事务压缩”。

组内发送的消息的压缩发生在组通信引擎级别，即在数据交给组通信线程之前，因此在mysql用户会话线程的上下文中进行。如果消息负载大小超过group_replication_compression_threshold设置的阈值，事务负载在发送到组之前会被压缩，并在接收时解压缩。接收消息时，成员会检查消息信封以验证是否已压缩。如果需要，则成员在将事务传递到上层之前对其进行解压缩。此过程如下图所示。

图 20.13 压缩支持

当网络带宽成为瓶颈时，消息压缩可以在组通信级别提供高达 30-40%的吞吐量改进。这在负载下的大型服务器组的情况下尤为重要。组内N个参与者之间的互连是 TCP 点对点的性质，使发送方将相同数量的数据发送N次。此外，二进制日志可能具有较高的压缩比。这使得压缩成为包含大型事务的 Group Replication 工作负载的一个引人注目的特性。

20.7.5 消息分段

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

当在 Group Replication 组成员之间发送异常大的消息时，可能导致一些组成员被报告为失败并从组中驱逐。这是因为 Group  Replication 的组通信引擎（XCom，一种 Paxos  变体）使用的单个线程在处理消息时占用时间过长，因此一些组成员可能会将接收者报告为失败。从 MySQL 8.0.16  开始，默认情况下，大消息会自动分割成单独发送并由接收方重新组装的片段。

系统变量group_replication_communication_max_message_size指定了 Group Replication 通信的最大消息大小，超过该大小的消息将被分段。默认的最大消息大小为 10485760 字节（10 MiB）。允许的最大值与replica_max_allowed_packet和slave_max_allowed_packet系统变量的最大值相同，即 1073741824 字节（1 GB）。group_replication_communication_max_message_size的设置必须小于replica_max_allowed_packet或slave_max_allowed_packet的设置，因为应用程序线程无法处理大于最大允许数据包大小的消息片段。要关闭分段，为group_replication_communication_max_message_size指定零值。

与大多数其他 Group Replication 系统变量一样，必须重新启动 Group Replication 插件才能使更改生效。例如：

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_communication_max_message_size= 5242880;
START GROUP_REPLICATION;

分段消息的消息传递在所有组成员接收并重新组装消息的所有片段后被视为完成。分段消息在其标头中包含信息，使得在消息传输过程中加入的成员能够恢复其加入之前发送的早期片段。如果加入的成员未能恢复片段，则会自行从组中退出。

为了使复制组使用分片，所有组成员必须在 MySQL 8.0.16 或更高版本，并且组使用的 Group Replication 通信协议版本必须允许分片。您可以使用group_replication_get_communication_protocol()函数检查组使用的通信协议，该函数返回组支持的最旧的  MySQL Server 版本。从 MySQL 5.7.14 版本开始允许消息压缩，从 MySQL 8.0.16  版本开始还允许消息分片。如果所有组成员都在 MySQL 8.0.16 或更高版本，并且没有要求允许早期版本的成员加入，您可以使用group_replication_set_communication_protocol()函数将通信协议版本设置为 MySQL 8.0.16 或更高版本，以允许分片。有关更多信息，请参见第 20.5.1.4 节，“设置组的通信协议版本”。

如果一个复制组由于某些成员不支持而无法使用分片，系统变量group_replication_transaction_size_limit可以用来限制组接受的事务的最大大小。在 MySQL 8.0 中，默认设置约为 143 MB。超过此大小的事务将被回滚。您还可以使用系统变量group_replication_member_expel_timeout来允许额外的时间（最长一小时），在怀疑已经失败的成员被从组中驱逐之前。

20.7.6 XCom 缓存管理

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

20.7.6.1 增加缓存大小

20.7.6.2 减少缓存大小

用于 Group Replication 的组通信引擎（XCom，一种 Paxos  变体）包括一个用于在共识协议的一部分中交换组成员之间的消息（及其元数据）的缓存。消息缓存除了其他功能外，还用于在成员在与其他组成员无法通信的一段时间后重新连接到组时恢复丢失的消息。

从 MySQL 8.0.16 开始，可以使用group_replication_message_cache_size系统变量为  XCom 的消息缓存设置缓存大小限制。如果达到缓存大小限制，XCom  会删除已经决定和传递的最旧条目。因为正在尝试重新连接的不可达成员会随机选择任何其他成员来恢复丢失的消息，所以所有组成员都应该设置相同的缓存大小限制。因此，每个成员的缓存中应该有相同的消息。

在 MySQL 8.0.16 之前，缓存大小为 1 GB，从 MySQL 8.0.16 开始，默认设置的缓存大小相同。请确保系统上有足够的内存可用于您选择的缓存大小限制，考虑到 MySQL Server 的其他缓存和对象池的大小。请注意，使用group_replication_message_cache_size设置的限制仅适用于缓存中存储的数据，缓存结构需要额外的 50 MB 内存。

在选择group_replication_message_cache_size设置时，应参考成员被驱逐之前的时间段内预期的消息量。这段时间的长度由group_replication_member_expel_timeout系统变量控制，该变量确定了等待期限（最长一小时），除了成员最初的 5 秒检测期外，允许成员返回到组中而不被驱逐。请注意，在 MySQL 8.0.21 之前，这段时间默认为成员变得不可用后的 5 秒，这只是在产生怀疑之前的检测期，因为group_replication_member_expel_timeout系统变量设置的额外驱逐超时默认为零。从 8.0.21 开始，驱逐超时默认为 5 秒，因此默认情况下，成员在至少离开 10 秒后才会被驱逐。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-performance-xcom-cache-increase.html

20.7.6.1 增加缓存大小

如果一个成员缺席的时间不够长，以至于还没有被从组中驱逐，它可以重新连接并从另一个成员的 XCom  消息缓存中检索丢失的事务，然后再次参与组。然而，如果在成员缺席期间发生的事务已经被从其他成员的 XCom  消息缓存中删除，因为它们达到了最大大小限制，那么该成员无法通过这种方式重新连接。

Group Replication  的组通信系统（GCS）通过警告消息向您发出警告，当一个消息被从消息缓存中删除时，这个消息可能会被当前不可达的成员用于恢复。这个警告消息被记录在所有活动组成员上（对于每个不可达成员只记录一次）。尽管组成员无法确定不可达成员看到的最后一条消息是什么，但警告消息表明缓存大小可能不足以支持您选择的成员被驱逐之前的等待时间。

在这种情况下，考虑根据group_replication_member_expel_timeout系统变量指定的时间段内预期的消息量，再加上 5 秒的检测期，来增加group_replication_message_cache_size限制，以便缓存包含所有成员成功返回所需的所有丢失消息。如果预计某个成员将在异常时间内变得不可达，还可以考虑暂时增加缓存大小限制。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-performance-xcom-cache-reduce.html

20.7.6.2 减小缓存大小

XCom 消息缓存大小的最小设置是 1 GB，直到 MySQL 8.0.20 版本。从 MySQL 8.0.21 开始，最小设置为 134217728 字节（128 MB），这使得可以在可用内存量受限的主机上部署。如果主机处于不稳定网络上，不建议将group_replication_message_cache_size设置得非常低，因为较小的消息缓存会使组成员在短暂失去连接后更难重新连接。

如果重新连接的成员无法从 XCom  消息缓存中检索到所需的所有消息，则该成员必须离开组并重新加入，以从另一个成员的二进制日志中使用分布式恢复检索缺失的事务。从 MySQL  8.0.21  开始，默认情况下，离开组的成员会进行三次自动重新加入尝试，因此重新加入组的过程可以在没有操作员干预的情况下进行。然而，使用分布式恢复重新加入是一个明显更长且更复杂的过程，比从  XCom  消息缓存中检索消息需要更长时间，因此成员需要更长时间才能变得可用，组的性能可能会受到影响。在稳定网络上，可以最小化成员短暂失去连接的频率和持续时间，因此这种情况发生的频率也应该最小化，因此组可能能够容忍较小的  XCom 消息缓存大小而不会对其性能产生显著影响。

如果您考虑减小缓存大小限制，可以使用以下语句查询 Performance Schema 表memory_summary_global_by_event_name：

SELECT * FROM performance_schema.memory_summary_global_by_event_name
  WHERE EVENT_NAME LIKE 'memory/group_rpl/GCS_XCom::xcom_cache';

这返回消息缓存的内存使用统计，包括当前缓存条目数和当前缓存大小。如果您减小缓存大小限制，XCom 会删除已经决定和传递的最旧条目，直到当前大小低于限制。在此移除过程进行时，XCom 可能暂时超过缓存大小限制。

20.7.7 响应故障检测和网络分区

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

20.7.7.1 驱逐超时

20.7.7.2 不可达多数超时

20.7.7.3 自动重新加入

20.7.7.4 退出操作

组复制的故障检测机制旨在识别不再与组通信并在看似可能已经失败时将其驱逐的组成员。拥有故障检测机制增加了组包含大多数正常工作成员的机会，因此客户端的请求能够被正确处理。

通常，所有组成员定期与所有其他组成员交换消息。如果某个组成员在 5  秒内没有收到来自特定成员的任何消息，当检测期结束时，会对该成员产生怀疑。当怀疑超时时，被怀疑的成员被认为已经失败，并被驱逐出组。被驱逐的成员从其他成员看到的成员列表中被移除，但它并不知道自己已经被驱逐出组，因此它认为自己在线，而其他成员无法到达。如果成员实际上没有失败（例如，因为仅因临时网络问题而断开连接），并且能够恢复与其他成员的通信，它将接收一个包含其被驱逐出组信息的视图。

组成员对这些情况的响应，包括故障成员本身，在整个过程中可以进行配置。默认情况下，如果怀疑某个成员已经失败，则会发生以下行为：

1. 在 MySQL 8.0.20  之前，当产生怀疑时，立即超时。一旦组识别到已过期的怀疑，被怀疑的成员就有可能在超时后的几秒内存活，因为定期进行过期怀疑检查。从 MySQL  8.0.21 开始，在怀疑超时并且被怀疑的成员有可能被驱逐之前，会添加 5 秒的等待时间。
   
2. 如果被驱逐的成员恢复通信并意识到自己已被驱逐，在 MySQL 8.0.20 之前，它不会尝试重新加入组。从 MySQL 8.0.21 开始，它将自动尝试三次重新加入组（每次尝试之间间隔 5 分钟），如果此自动重新加入过程不起作用，则停止尝试重新加入组。
   
3. 当被驱逐的成员不尝试重新加入组时，它会切换到超级只读模式并等待操作员注意。（例外情况是在 MySQL 8.0.12 至 8.0.15 的版本中，默认情况下成员会关闭自身。从 MySQL 8.0.16 开始，行为已更改以匹配 MySQL 5.7 中的行为。）
   

您可以使用本节中描述的组复制配置选项来永久或临时更改这些行为，以适应您系统的要求和您的优先级。如果您遇到由较慢的网络或机器引起的不必要的驱逐、具有高意外瞬时中断率的网络，或计划中的网络中断，考虑增加驱逐超时和自动重新加入尝试次数。从  MySQL 8.0.21  开始，已更改默认设置以减少在这些情况下需要操作员干预以恢复被驱逐成员的频率。请注意，虽然成员正在经历上述任何默认行为之一时，尽管它不接受写入，但如果成员仍在与客户端通信，则仍然可以进行读取，随着时间的推移，过时读取的可能性会增加。如果避免过时读取对您而言比避免操作员干预更重要，请考虑减少驱逐超时和自动重新加入尝试次数或将其设置为零。

未发生故障的成员可能会由于网络分区而失去与复制组的部分但不是全部的联系。例如，在一个由 5  台服务器（S1、S2、S3、S4、S5）组成的组中，如果（S1、S2）和（S3、S4、S5）之间存在断开连接，则存在网络分区。第一组（S1、S2）现在处于少数派，因为它无法与超过一半的组联系。由少数派组成员处理的任何事务都会被阻塞，因为组的大多数是不可达的，因此组无法达成法定人数。有关此场景的详细描述，请参见第  20.7.8  节，“处理网络分区和法定人数丧失”。在这种情况下，默认行为是使少数派和多数派的成员继续留在组中，继续接受事务（尽管在少数派成员上被阻塞），并等待操作员干预。此行为也是可配置的。

请注意，如果团队成员使用的是较旧的 MySQL 服务器版本，不支持相关设置，或者使用具有不同默认设置的版本，则他们会根据上述默认行为对自己和其他团队成员采取行动。例如，不支持group_replication_member_expel_timeout系统变量的成员会在检测到过期的怀疑时立即驱逐其他成员，并即使其他成员支持该系统变量并设置了更长的超时时间，他们也会接受这种驱逐。

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

20.7.7.1 驱逐超时

你可以使用group_replication_member_expel_timeout系统变量，该变量从 MySQL 8.0.13 开始提供，以允许在怀疑创建和怀疑成员被驱逐之间提供额外时间。当一个服务器没有从另一个服务器接收消息时，就会创建怀疑，如第 20.1.4.2 节“故障检测”中所解释的那样。

在 Group Replication 组成员创建对另一个成员（或自身）的怀疑之前，会有一个初始的 5 秒检测期。然后，在另一个成员对其（或自身对自身）的怀疑超时后，该组成员将被驱逐。在此之后可能会有一个短暂的时间段，然后驱逐机制会检测并执行驱逐。group_replication_member_expel_timeout指定了在创建怀疑和驱逐被怀疑成员之间等待的时间段，称为驱逐超时，期间组成员被列为UNREACHABLE，但不会从组的成员列表中移除。

• 如果怀疑成员在等待期结束时再次活动，成员将应用由剩余组成员在 XCom 消息缓存中缓冲的所有消息，并进入ONLINE状态，无需操作员干预。在这种情况下，组将认为该成员是同一实例。
  
• 如果怀疑成员在怀疑超时后才重新活动并能恢复通信，它会收到一个被驱逐的视图，此时意识到自己被驱逐。你可以使用group_replication_autorejoin_tries系统变量，该变量从 MySQL 8.0.16 开始提供，使成员在此时自动尝试重新加入组。从 MySQL 8.0.21 开始，默认情况下激活此功能，并且成员会进行三次自动重新加入尝试。如果自动重新加入过程失败或未尝试，则被驱逐成员将按照group_replication_exit_state_action指定的退出操作进行。
  

在驱逐成员之前的等待时间仅适用于先前在组中活动过的成员。从未在组中活动过的非成员不会获得此等待时间，并且在初始检测期结束后因加入时间过长而被移除。

如果group_replication_member_expel_timeout设置为 0，则没有等待期，而在 5 秒检测期结束后，疑似成员立即有可能被驱逐。这是 MySQL 8.0.20 及更早版本的默认设置。这也是不支持group_replication_member_expel_timeout系统变量的 MySQL 服务器版本的组成员的行为。从 MySQL 8.0.21 开始，默认值为 5，意味着在 5 秒检测期后的 5 秒内，疑似成员有可能被驱逐。并非所有组成员都必须具有相同的group_replication_member_expel_timeout设置，但建议这样做以避免意外驱逐。任何成员都可以对任何其他成员（包括自身）产生怀疑，因此有效的驱逐超时是具有最低设置的成员的超时。

在以下情况下考虑增加group_replication_member_expel_timeout的值，而不使用默认值：

• 网络速度较慢，默认的 5 或 10 秒在驱逐之前不足以确保组成员始终交换至少一条消息。
  
• 网络有时会出现短暂中断，您希望在这些时候避免不必要的驱逐和主要成员更改。
  
• 网络不在您的直接控制之下，您希望最大程度减少操作员干预的需求。
  
• 预计会发生临时网络中断，您不希望因此而有些或全部成员被驱逐。
  
• 个别机器正在经历减速，您不希望它被从组中驱逐。
  

您可以指定最长达 3600 秒（1 小时）的驱逐超时。重要的是要确保 XCom 的消息缓存足够大，以容纳在指定时间段内预期的消息量，再加上初始的 5 秒检测期，否则成员无法重新连接。您可以使用group_replication_message_cache_size系统变量来调整缓存大小限制。有关更多信息，请参见第 20.7.6 节，“XCom 缓存管理”。

如果一个群组中的任何成员目前受到怀疑，那么群组成员资格不能重新配置（通过添加或删除成员或选举新领导者）。如果需要实施群组成员变更，而其中一个或多个成员受到怀疑，并且你希望怀疑成员继续留在群组中，那么请采取任何必要行动使这些成员重新活跃，如果可能的话。如果你无法使这些成员重新活跃，并且希望将他们从群组中驱逐，你可以立即强制怀疑超时。方法是在任何活跃成员上更改group_replication_member_expel_timeout的值为低于自怀疑创建以来已经经过的时间的值。这样一来，怀疑成员将立即有可能被驱逐。

如果一个复制组成员意外停止并立即重新启动（例如，因为它是使用mysqld_safe启动的），如果设置了group_replication_start_on_boot=on，它会自动尝试重新加入群组。在这种情况下，重新启动和重新加入尝试可能发生在成员的先前实例被驱逐出群组之前，这样该成员就无法重新加入。从  MySQL 8.0.19 开始，Group Replication 自动使用群组通信系统（GCS）功能为成员重试重新加入尝试 10  次，每次重试之间间隔 5 秒。这应该涵盖大多数情况，并允许足够的时间让先前的实例被驱逐出群组，从而让成员重新加入。请注意，如果group_replication_member_expel_timeout系统变量设置为指定成员被驱逐之前等待的较长时间，自动重新加入尝试可能仍然不会成功。

对于在group_replication_member_expel_timeout系统变量不可用的情况下避免不必要驱逐的替代缓解策略，请参阅 Section 20.3.2, “Group Replication Limitations”。

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

20.7.7.2 不可达多数超时

默认情况下，由于网络分区而处于少数派的成员不会自动离开群组。您可以使用系统变量group_replication_unreachable_majority_timeout设置成员在与大多数群组成员失去联系后等待的秒数，然后退出群组。设置超时意味着您无需主动监视网络分区后处于少数派群组的服务器，并且可以避免由于不当干预而创建群组成员的两个版本导致的分裂脑情况。

当group_replication_unreachable_majority_timeout指定的超时时间到期时，已由该成员和少数派群组中的其他成员处理的所有待处理事务都将被回滚，并且该群组中的服务器将移至ERROR状态。您可以使用从 MySQL 8.0.16 开始提供的group_replication_autorejoin_tries系统变量，使成员在此时自动尝试重新加入群组。从 MySQL 8.0.21 开始，默认情况下激活此功能，并且成员将进行三次自动重新加入尝试。如果自动重新加入过程不成功或未尝试，则少数派成员将按照group_replication_exit_state_action指定的退出操作进行。

在决定是否设置不可达多数超时时，请考虑以下几点：

• 在对称群组中，例如具有两个或四个服务器的群组，如果两个分区包含相等数量的服务器，则两个群组都认为自己处于少数派并进入ERROR状态。在这种情况下，群组没有功能性分区。
  
• 尽管存在少数派群组，但由少数派群组处理的任何事务都会被接受，但由于少数服务器无法达到法定人数，这些事务被阻塞，直到在这些服务器上发出STOP GROUP_REPLICATION或达到不可达多数超时为止。
  
• 如果不设置不可达多数超时，则少数派群组中的服务器永远不会自动进入ERROR状态，您必须手动停止它们。
  
• 如果在检测到大多数丢失后在少数派群组的服务器上设置不可达多数超时，则不会产生任何影响。
  

如果您不使用group_replication_unreachable_majority_timeout系统变量，则在网络分区事件中进行操作发明的过程在第 20.7.8 节，“处理网络分区和失去法定人数”中描述。该过程涉及检查哪些服务器正在运行，并在必要时强制进行新的组成员资格。

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

20.7.7.3 自动重新加入

group_replication_autorejoin_tries系统变量从 MySQL 8.0.16  开始提供，使被驱逐或达到不可达多数超时的成员尝试自动重新加入组。在 MySQL 8.0.20 之前，系统变量的值默认为  0，因此默认情况下不会激活自动重新加入。从 MySQL 8.0.21 开始，系统变量的值默认为  3，这意味着成员会自动尝试重新加入组，每次尝试之间间隔 5 分钟，最多尝试 3 次。

当未激活自动重新加入时，成员一旦恢复通信即接受其驱逐，并继续执行由group_replication_exit_state_action系统变量指定的操作。之后，需要手动干预才能将成员带回组中。如果您可以容忍可能出现过时读取的可能性，并希望最小化手动干预的需求，特别是在瞬时网络问题经常导致成员被驱逐的情况下，使用自动重新加入功能是合适的。

使用自动重新加入时，当成员被驱逐或达到不可达多数超时时，它会尝试重新加入（使用当前插件选项值），然后继续进行进一步的自动重新加入尝试，直到达到指定的尝试次数为止。在一次不成功的自动重新加入尝试后，成员在下一次尝试之前等待  5 分钟。自动重新加入尝试和它们之间的时间称为自动重新加入过程。如果在成员重新加入或停止之前耗尽了指定的尝试次数，则成员将执行由group_replication_exit_state_action系统变量指定的操作。

在自动重新加入尝试期间和之间，成员保持在超级只读模式，并在其复制组视图上显示ERROR状态。在此期间，成员不接受写入。但是，随着时间的推移，成员上的读取仍然可以进行，但随着时间的推移，读取变得越来越可能过时。如果您确实希望在自动重新加入过程中干预以使成员脱机，可以随时使用STOP GROUP_REPLICATION语句或关闭服务器来手动停止成员。如果您无法容忍任何时间段内可能出现过时读取的可能性，请将group_replication_autorejoin_tries系统变量设置为 0。

你可以使用性能模式监视自动重新加入过程。在自动重新加入过程进行时，性能模式表events_stages_current显示事件“正在进行自动重新加入过程”，显示到目前为止在此过程实例中尝试的重试次数（在WORK_COMPLETED字段中）。events_stages_summary_global_by_event_name表显示服务器实例启动自动重新加入过程的次数（在COUNT_STAR字段中）。events_stages_history_long表显示每个自动重新加入过程完成的时间（在TIMER_END字段中）。当成员重新加入复制组时，在组完成兼容性检查并接受其为成员之前，其状态可能显示为OFFLINE或ERROR。当成员正在赶上组的事务时，其状态为RECOVERING。

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

20.7.7.4 退出操作

group_replication_exit_state_action系统变量，从 MySQL 8.0.12 和  MySQL 5.7.24 开始提供，指定了当成员由于错误或问题意外离开组时，Group Replication  应该执行的操作，以及在自动重新加入失败或不尝试重新加入时的操作。请注意，在被驱逐成员的情况下，成员在重新连接到组之前并不知道自己被驱逐，因此只有在成员成功重新连接或成员对自己产生怀疑并将自己驱逐时，才会执行指定的操作。

按影响顺序，退出操作如下：

1. 如果READ_ONLY是退出操作，实例将通过将系统变量super_read_only设置为ON，将 MySQL 切换到超级只读模式。当成员处于超级只读模式时，客户端无法进行任何更新操作，即使他们拥有CONNECTION_ADMIN权限（或已弃用的SUPER权限）。然而，客户端仍然可以读取数据，由于不再进行更新，随着时间的推移，存在过时读取的可能性会增加。因此，您需要主动监视服务器以防止故障。从 MySQL 8.0.15 开始，这是默认的退出操作。在执行此退出操作后，成员的状态将在组的视图中显示为ERROR。
   
2. 如果OFFLINE_MODE是退出操作，则通过将系统变量offline_mode设置为ON，实例将将 MySQL 切换到离线模式。当成员处于离线模式时，连接的客户端用户在下一次请求时将被断开连接，不再接受连接，但具有CONNECTION_ADMIN权限（或已弃用的SUPER权限）的客户端用户除外。Group Replication 还将系统变量super_read_only设置为ON，因此客户端无法进行任何更新，即使他们已经使用CONNECTION_ADMIN或SUPER权限连接。此退出操作阻止了更新和过时读取（除了具有上述权限的客户端用户进行读取），并使代理工具（如  MySQL Router）能够识别服务器不可用并重定向客户端连接。它还保持实例运行，以便管理员可以尝试解决问题而不关闭  MySQL。此退出操作从 MySQL 8.0.18 版本开始提供。在执行此退出操作后，成员的状态在组的视图中显示为ERROR（而不是OFFLINE，这意味着成员具有 Group Replication 功能，但当前不属于任何组）。
   
3. 如果ABORT_SERVER是退出操作，则实例将关闭  MySQL。指示成员关闭自身可以防止所有过时读取和客户端更新，但这意味着 MySQL Server  实例不可用，必须重新启动，即使问题可以在不进行此步骤的情况下解决。此退出操作是从 MySQL 8.0.12 版本（添加系统变量时）到 MySQL  8.0.15 版本（含）的默认操作。在执行此退出操作后，成员将从组的视图中的服务器列表中删除。
   

请注意，无论设置了哪种退出操作，都需要操作员干预，因为已耗尽自动重新加入尝试（或从未有过）并已被组驱逐的前成员不允许重新加入而无需重新启动  Group Replication。退出操作仅影响客户端是否仍然可以在无法重新加入组的服务器上读取数据，以及服务器是否保持运行。

重要提示

如果在成员成功加入组之前发生故障，则不会执行group_replication_exit_state_action指定的退出操作。这种情况发生在本地配置检查期间发生故障，或者加入成员的配置与组的配置不匹配时。在这些情况下，super_read_only系统变量保持其原始值，服务器不会关闭 MySQL。为了确保当 Group Replication 未启动时服务器无法接受更新，我们建议在服务器启动时在配置文件中设置super_read_only=ON，Group Replication 在成功启动后将其更改为OFF。当服务器配置为在服务器启动时启动 Group Replication（group_replication_start_on_boot=ON）时，此保护措施尤为重要，但在使用START GROUP_REPLICATION命令手动启动 Group Replication 时也很有用。

如果成员成功加入组后发生故障，则执行指定的退出操作。以下情况会发生：

1. 应用程序错误 - 复制应用程序中存在错误。此问题无法恢复。
   
2. 无法进行分布式恢复 - 存在问题，导致 Group Replication 的分布式恢复过程（使用远程克隆操作和从二进制日志进行状态传输）无法完成。Group  Replication 在适当的情况下会自动重试分布式恢复，但如果没有更多选项来完成该过程，则会停止。有关详细信息，请参见第 20.5.4.4  节，“分布式恢复的容错性”。
   
3. 组配置更改错误 - 在使用函数进行组范围配置更改时发生错误，如第 20.5.1 节，“配置在线组”中所述。
   
4. 主选举错误 - 在单主模式下为组选择新主成员时发生错误，如第 20.1.3.1 节，“单主模式”中所述。
   
5. 无法访问的多数超时 - 成员与大多数组成员失去联系，因此处于少数，并且由 group_replication_unreachable_majority_timeout 系统变量设置的超时已经过期。
   
6. 成员被组驱逐 - 对成员提出了怀疑，并且由 group_replication_member_expel_timeout 系统变量设置的任何超时已经过期，成员已恢复与组的通信并发现自己已被驱逐。
   
7. 超出自动重新加入尝试次数 - group_replication_autorejoin_tries 系统变量被设置为指定在失去多数或被驱逐后的自动重新加入尝试次数，成员完成了这些尝试次数但未成功。
   

以下表格总结了每种情况下的失败场景和操作：

表 20.3 组复制失败情况下的退出操作

20.7.8 处理网络分区和失去法定人数

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

当需要复制发生的更改时，组需要达成共识。这适用于常规事务，但也适用于组成员更改和保持组一致性的某些内部消息。共识要求组成员中的大多数同意给定决定。当组成员的大多数丢失时，组无法继续进行并阻塞，因为它无法获得法定人数或法定人数。

当有多个非自愿故障导致大多数服务器突然从组中移除时，可能会丢失法定人数。例如，在 5 台服务器组中，如果其中有 3  台同时变得沉默，那么大多数就会受到影响，因此无法实现法定人数。事实上，剩下的两台无法确定其他 3  台服务器是否已崩溃，还是网络分区已将这两台孤立，因此组无法自动重新配置。

另一方面，如果服务器自愿退出组，它们会指示组应重新配置自身。实际上，这意味着要离开的服务器告诉其他人它要离开。这意味着其他成员可以正确地重新配置组，维护成员的一致性并重新计算法定人数。例如，在上述  5 台服务器的情况下，如果有 3 台同时离开，如果这 3 台离开的服务器依次警告组它们要离开，那么成员资格就能够从 5 调整到  2，并同时在此过程中确保法定人数。

注意

失去法定人数本身就是规划不良的副作用。根据预期故障数量规划组大小（无论这些故障是连续发生、同时发生还是零星发生）。

对于单主模式的组，主服务器可能有一些尚未在网络分区发生时其他成员上出现的事务。如果考虑将主服务器排除在新组之外，请注意这些事务可能会丢失。具有额外事务的成员无法重新加入组，尝试会导致错误消息，内容为此成员的已执行事务多于组中存在的事务。设置group_replication_unreachable_majority_timeout系统变量以避免此情况。

以下各节解释了如果系统以使组内服务器无法自动实现法定人数的方式分区应该怎么办。

检测分区

replication_group_members  性能模式表呈现了从该服务器的视角看到的当前视图中每台服务器的状态。大多数情况下，系统不会遇到分区，因此该表显示跨组中所有服务器一致的信息。换句话说，该表上每台服务器的状态在当前视图中得到了所有人的认可。然而，如果存在网络分区，并且丢失了法定人数，那么对于那些无法联系的服务器，该表将显示状态为  UNREACHABLE。这些信息由 Group Replication 内置的本地故障检测器导出。

图 20.14 失去法定人数

要理解这种类型的网络分区，以下部分描述了最初有 5 台服务器正确协作的情景，以及一旦只有 2 台服务器在线后组发生的变化。该情景在图中描述。

因此，假设有一个包含这 5 台服务器的组：

• 服务器 s1 的成员标识符为 199b2df7-4aaf-11e6-bb16-28b2bd168d07
  
• 服务器 s2 的成员标识符为 199bb88e-4aaf-11e6-babe-28b2bd168d07
  
• 服务器 s3 的成员标识符为 1999b9fb-4aaf-11e6-bb54-28b2bd168d07
  
• 服务器 s4 的成员标识符为 19ab72fc-4aaf-11e6-bb51-28b2bd168d07
  
• 服务器 s5 的成员标识符为 19b33846-4aaf-11e6-ba81-28b2bd168d07
  

最初，组运行良好，服务器之间愉快地进行通信。您可以通过登录 s1 并查看其 replication_group_members 性能模式表来验证这一点。例如：

mysql> SELECT MEMBER_ID,MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+-------------+
| MEMBER_ID                            | MEMBER_STATE | MEMBER_ROLE |
+--------------------------------------+--------------+-------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | ONLINE       | SECONDARY   |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       | PRIMARY     |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       | SECONDARY   |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | ONLINE       | SECONDARY   |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | ONLINE       | SECONDARY   |
+--------------------------------------+--------------+-------------+

然而，片刻之后发生了灾难性故障，服务器 s3、s4 和 s5 意外停止运行。几秒钟后，再次查看 s1 上的 replication_group_members 表，显示它仍然在线，但其他几个成员不在线。事实上，如下所示，它们被标记为 UNREACHABLE。此外，系统无法重新配置自身以更改成员资格，因为大多数成员已经丢失。

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE  |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE  |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE  |
+--------------------------------------+--------------+

表格显示，s1  现在处于一个没有办法继续进行的组中，因为大多数服务器无法访问。在这种特殊情况下，需要重置组成员列表以允许系统继续进行，这在本节中有解释。或者，您也可以选择停止  s1 和 s2 上的组复制（或完全停止 s1 和 s2），弄清楚 s3、s4 和 s5 发生了什么，然后重新启动组复制（或服务器）。

解除分区阻塞

组复制使您能够通过强制特定配置来重置组成员列表。例如，在上述情况中，只有 s1 和 s2 在线，您可以选择强制执行仅包含 s1 和 s2 的成员配置。这需要检查有关 s1 和 s2 的一些信息，然后使用 group_replication_force_members 变量。

图 20.15 强制执行新的成员配置

假设您回到了只剩下 s1 和 s2 两台服务器的情况。服务器 s3、s4 和 s5 突然离开了组。为了让服务器 s1 和 s2 继续运行，您希望强制执行一个只包含 s1 和 s2 的成员配置。

警告

此过程使用 group_replication_force_members ，应被视为最后的补救措施。它必须极度小心使用，仅用于覆盖丧失法定人数的情况。如果被滥用，可能会导致人为的脑裂情况或完全阻塞整个系统。

在强制执行新的成员配置时，请确保任何要被强制退出组的服务器确实已经停止运行。在上述场景中，如果 s3、s4 和 s5  并非真正无法访问，而是在线的话，它们可能已经形成了自己的功能分区（它们是 5 台中的 3 台，因此拥有多数派）。在这种情况下，强制使用只包含  s1 和 s2  的组成员列表可能会导致人为的脑裂情况。因此，在强制执行新的成员配置之前，确保要排除的服务器确实已关闭，如果没有关闭，请在继续之前关闭它们。

警告

对于单主模式的组，主服务器可能有一些在网络分区时其他成员尚未存在的事务。如果您考虑将主服务器排除在新组之外，请注意这些事务可能会丢失。具有额外事务的成员无法重新加入组，尝试会导致错误消息为此成员的已执行事务多于组中存在的事务。设置group_replication_unreachable_majority_timeout系统变量以避免此情况。

请记住系统被阻塞，当前配置如下（由s1上的本地故障检测器感知）：

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE  |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE  |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE  |
+--------------------------------------+--------------+

首先要做的是检查s1和s2的本地地址（组通信标识符）。登录到s1和s2，并按以下方式获取该信息。

mysql> SELECT @@group_replication_local_address;

一旦知道s1（127.0.0.1:10000）和s2（127.0.0.1:10001）的组通信地址，您可以在两个服务器中的一个上使用它来注入新的成员配置，从而覆盖已失去法定人数的现有配置。在s1上执行以下操作：

mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";

通过强制不同配置来解除组的阻塞。在此更改后，检查s1和s2上的replication_group_members以验证组成员身份。首先在s1上。

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE       |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE       |
+--------------------------------------+--------------+

然后在s2上执行。

mysql> SELECT * FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE       |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE       |
+--------------------------------------+--------------+

在使用group_replication_force_members系统变量成功强制新的组成员身份并解除组阻塞后，请确保清除该系统变量。为了发出START GROUP_REPLICATION语句，group_replication_force_members必须为空。

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