网络分区

每当需要复制的更改发生时，小组就需要达成共识。常规处理就是这种情况，但组成员身份更改和一些使组保持一致的内部消息传递也是必需的。共识要求大多数小组成员同意给定的决定。当大多数组成员丢失时，该组将无法继续前进并阻止，因为它无法确保多数或法定人数。

当出现多个非自愿故障时，仲裁可能会丢失，从而导致大多数服务器突然从组中删除。例如，在一组5台服务器中，如果其中3台立即变为静音，则大多数服务器将受到损害，因此无法达到法定人数。实际上，其余两个服务器无法判断其他3台服务器是否崩溃，或者网络分区是否单独隔离了这2台服务器，因此无法自动重新配置该组。

另一方面，如果服务器自愿退出该组，则它们会指示该组重新配置自身。实际上，这意味着要离开的服务器会告诉其他人它要离开。这意味着其他成员可以正确地重新配置组，维护成员身份的一致性，并重新计算大多数成员。例如，在上述5个服务器同时离开3个服务器的情况下，如果3个离开服务器向组警告他们即将离开的组，则成员资格可以将自己从5个调整为2个时间，确保达到法定人数。

注意

仲裁丢失本身就是不良计划的副作用。根据预期的故障数量计划组的大小（无论它们是连续的，一次全部发生还是偶发的）。

以下各节说明了如果系统分区的方式使得组中的服务器无法自动实现仲裁，该怎么办。

在失去多数票并重新配置后已从组中排除的主数据库可能包含新组中未包含的额外事务。如果发生这种情况，尝试从组中添加回被排除的成员将导致错误消息：此成员具有比组中存在的事务更多的已执行事务。

检测分区

在replication_group_members性能模式表显示每个服务器在从该服务器的角度来看，当前视图状态。在大多数情况下，系统没有运行到分区，因此该表显示的信息在组中的所有服务器之间都是一致的。换句话说，此表中每个服务器的状态在当前视图中被所有人同意。但是，如果存在网络分区，并且仲裁丢失，那么该表将显示UNREACHABLE其无法联系的那些服务器的状态。该信息由组复制中内置的本地故障检测器导出。

丢失仲裁

为了了解这种类型的网络分区，以下部分描述了一个场景，其中最初有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意外停止。此后几秒钟，再次replication_group_members参见s1 上的表表明该表仍处于联机状态，但其他几个成员不在。实际上，如下所示，它们标记为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变量。

强制加入新成员

假设您又回到了s1和s2是组中剩下的唯一服务器的情况。服务器s3，s4和s5意外离开了该组。要使服务器s1和s2继续运行，您想强制仅包含s1和s2的成员资格配置。

警告

该程序使用group_replication_force_members并且应被视为最后的补救措施。必须格外小心地使用它，并且仅用于使仲裁无效。如果使用不当，它可能会创建人为裂脑方案或完全阻塞整个系统。

回想一下，系统已被阻塞，当前配置如下（如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";

通过强制执行其他配置，可以解除对组的阻止。replication_group_members更改后，请同时检查s1和s2以验证组成员身份。首先在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       	|
+--------------------------------------	+--------------	+

强制执行新的成员资格配置时，请确保确实要停止将要从组中强制退出的所有服务器。在上述情况下，如果s3，s4和s5并非真正不可访问而是在线的，则它们可能已经形成了自己的功能分区（5分之3，因此占多数）。在这种情况下，将组成员列表强制为s1和s2可能会导致人为分裂的情况。因此，在强制执行新的成员资格配置之前，确保要排除的服务器确实已关闭是很重要的；如果没有关闭，请在继续操作之前将其关闭。

使用group_replication_force_members系统变量成功强制新的组成员身份并取消阻止该组后，请确保清除系统变量。group_replication_force_members必须为空才能发出START GROUP_REPLICATION声明。