MySQL 5.7版本说明
当需要复制的变更发生时，团队需要达成共识。这是常规事务的情况，但组成员关系更改和保持组一致性的一些内部消息传递也需要这样做。共识要求大多数团队成员同意一个给定的决定。当大多数组成员丢失时，该组成员将无法前进并阻塞，因为它无法确保多数或法定人数。
当出现多个非自愿故障时，可能会丢失Quorum，导致大多数服务器突然从组中删除。例如，在一个5台服务器的组中，如果其中3台同时变为静默状态，多数就会受到影响，因此无法达到法定人数。实际上，其余两个服务器无法判断其他3个服务器是否已经崩溃，或者网络分区是否将这2个服务器单独隔离，因此无法自动重新配置组。
另一方面，如果服务器自愿退出组，它们会指示组重新配置自己。在实践中，这意味着正在离开的服务器会告诉其他服务器它正在离开。这意味着其他成员可以正确地重新配置组，保持成员的一致性，并重新计算多数。例如，在上面的5个服务器的场景中，其中3个服务器同时离开，如果3个离开的服务器一个接一个地警告团队它们要离开，那么成员关系就能够从5调整到2，同时，在此过程中确保quorum。
请注意
缺乏法定人数本身就是糟糕计划的一个副作用。为预期的故障数量规划分组大小(不管它们是连续的、一次性发生的还是零星发生的)。
下面几节将解释如果系统分区的方式使组中的服务器不自动实现仲裁，那么该如何做。
提示
在多数损失之后，一个主组被排除在组之外，然后进行重新配置，可以包含不包含在新组中的额外事务。如果发生这种情况，将被排除的成员添加回组的尝试将导致消息错误此成员的已执行事务比组中存在的事务多。
的replication_group_members性能模式表从该服务器的角度显示当前视图中每个服务器的状态。在大多数情况下，系统不会进行分区，因此该表显示的信息在组中所有服务器之间是一致的。换句话说，该表上每个服务器的状态都是由当前视图中的所有人一致同意的。但是，如果存在网络分区，且仲裁丢失，则该表将显示状态遥不可及的对于那些它不能联系的服务器。此信息由Group Replication内建的本地故障检测器导出。
为了理解这种类型的网络分区，下面的部分将描述一个场景，在这个场景中，最初有5台服务器正确地一起工作，而当只有2台服务器在线时，该组将发生更改。该场景如图所示。
因此，让我们假设有一个组中有这5个服务器:
具有成员标识符的服务器s1
199年b2df7-4aaf-11e6-bb16-28b2bd168d07具有成员标识符的服务器s2
199年bb88e-4aaf-11e6-babe-28b2bd168d07带有成员标识符的服务器s3
1999年b9fb-4aaf-11e6-bb54-28b2bd168d07带有成员标识符的服务器s4
19 ab72fc-4aaf-11e6-bb51-28b2bd168d07带有成员标识符的服务器s5
19 b33846-4aaf-11e6-ba81-28b2bd168d07
最初，组运行良好，服务器之间的通信也很愉快。您可以通过登录到s1并查看它来验证这一点replication_group_members性能模式表。例如:
SELECT MEMBER_ID,MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;+--------------------------------------+--------------+-------------+ | MEMBER_ID | MEMBER_STATE | -MEMBER_ROLE | +--------------------------------------+--------------+-------------+ | 1999年b9fb-4aaf-11e6-bb54-28b2bd168d07 |在线二级| | | 199年b2df7-4aaf-11e6-bb16-28b2bd168d07主要在线| | | | 199年bb88e-4aaf-11e6-babe-28b2bd168d07 |在线二级| | | 19 ab72fc-4aaf-11e6-bb51-28b2bd168d07 |在线二级| | | 19 b33846-4aaf-11e6-ba81-28b2bd168d07在线二级| | |+--------------------------------------+--------------+-------------+然而，片刻之后发生了灾难性的故障，服务器s3、s4和s5意外停止。几秒钟后，再看看replication_group_memberss1上的表显示它仍然在线，但其他几个成员没有。事实上，如下所示，它们被标记为遥不可及的．此外，系统不能重新配置自己来改变成员，因为大多数已经丢失了。
SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;+--------------------------------------+--------------+ | MEMBER_ID | MEMBER_STATE | +--------------------------------------+--------------+ | 199 b2df7-4aaf-11e6-bb16-28b2bd168d07 1999 b9fb-4aaf-11e6-bb54-28b2bd168d07 |的| | |在线| | 199年bb88e-4aaf-11e6-babe-28b2bd168d07在线| | | 19 ab72fc-4aaf-11e6-bb51-28b2bd168d07 |的| | 19 b33846-4aaf-11e6-ba81-28b2bd168d07 |遥不可及的 | +--------------------------------------+--------------+该表显示，s1现在位于一个没有外部干预就无法前进的组中，因为大多数服务器都无法访问。在这种特殊情况下，需要重置组成员列表以允许系统继续运行，这将在本节中解释。或者，也可以选择在s1和s2上停止组复制(或完全停止s1和s2)，弄清楚s3、s4和s5发生了什么，然后重新启动组复制(或服务器)。
组复制允许通过强制执行特定配置来重置组成员列表。例如，在上面的例子中，其中s1和s2是唯一在线的服务器，您可以选择强制只包含s1和s2的成员配置。这需要检查关于s1和s2的一些信息，然后使用group_replication_force_members变量。
假设您回到了这样一种情况，其中s1和s2是组中仅剩下的服务器。服务器s3、s4和s5已意外离开组。要使服务器s1和s2继续，需要强制只包含s1和s2的成员关系配置。
警告
这个过程使用group_replication_force_members这是最后的补救办法。它必须要非常小心地使用，并且仅用于覆盖quorum的损失。如果使用不当，它可能会造成人工脑裂的情况，或者完全阻塞整个系统。
回想一下，系统被阻塞，当前配置如下(由本地故障检测器在s1上感知到):
SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;+--------------------------------------+--------------+ | MEMBER_ID | MEMBER_STATE | +--------------------------------------+--------------+ | 199 b2df7-4aaf-11e6-bb16-28b2bd168d07 1999 b9fb-4aaf-11e6-bb54-28b2bd168d07 |的| | |在线| | 199年bb88e-4aaf-11e6-babe-28b2bd168d07在线| | | 19 ab72fc-4aaf-11e6-bb51-28b2bd168d07 |的| | 19 b33846-4aaf-11e6-ba81-28b2bd168d07 |遥不可及的 | +--------------------------------------+--------------+首先要做的是检查s1和s2的本地地址(组通信标识符)是什么。登录到s1和s2，并像下面这样获取信息。
mysql >选择@@group_replication_local_address;一旦你知道s1的组通信地址(127.0.0.1:10000)和s2 (127.0.0.1:10001)，您可以在两台服务器中的一台上使用它来注入新的成员配置，从而覆盖已丢失quorum的现有配置。要在s1上这样做:
mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";这将通过强制使用不同的配置来解除组的阻塞。检查replication_group_members在s1和s2上验证此更改后的组成员关系。第一次在s1。
SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;+--------------------------------------+--------------+ | MEMBER_ID | MEMBER_STATE | +--------------------------------------+--------------+ | 网上在线b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | | | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | | +--------------------------------------+--------------+然后在s2上。
SELECT * FROM performance_schema.replication_group_members;+--------------------------------------+--------------+ | MEMBER_ID | MEMBER_STATE | +--------------------------------------+--------------+ | 网上在线b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | | | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | | +--------------------------------------+--------------+在强制执行新的成员资格配置时，请确保将强制退出组的所有服务器都已停止。在上面描述的场景中，如果s3、s4和s5不是真的不可访问，而是在线的，那么它们可能已经形成了自己的功能分区(它们是5个分区中的3个，因此它们拥有大多数)。在这种情况下，强制列出包含s1和s2的组成员名单可能会造成人工裂脑的情况。因此，在强制执行新的成员关系配置之前，必须确保要排除的服务器确实已关闭，如果没有关闭，则在继续之前关闭它们。
当你用过group_replication_force_members系统变量，以成功强制新的组成员身份和解除阻塞的组，确保您清除了系统变量。group_replication_force_members必须为空才能发出开始GROUP_REPLICATION声明。