MySQL 8.0版本说明
MySQL 8.0源代码文档10bet官方网站
团队需要在需要复制的变更发生时达成共识。这适用于常规事务，但对于组成员更改和一些保持组一致性的内部消息传递也是必需的。共识要求大多数小组成员同意一个给定的决定。当失去大多数组成员时，由于无法确保多数或法定人数，该组将无法前进并阻塞。
当出现多个非自愿故障时，Quorum可能会丢失，导致大多数服务器突然从组中移除。例如，在一个由5台服务器组成的组中，如果其中3台同时保持沉默，则多数服务器将受到影响，因此无法达到法定人数。实际上，其余两个服务器无法判断其他3个服务器是否已经崩溃，或者网络分区是否单独隔离了这2个服务器，因此无法自动重新配置组。
另一方面，如果服务器主动退出组，它们会指示组重新配置自己。实际上，这意味着要离开的服务器会告诉其他服务器它要离开了。这意味着其他成员可以正确地重新配置组，保持成员的一致性，并重新计算大多数。例如，在上述5台服务器的场景中，其中3台同时离开，如果3台离开的服务器一个接一个地警告该组它们要离开，那么成员资格能够从5调整为2，同时在发生这种情况时确保quorum。
请注意
法定人数的减少本身就是不良计划的副作用。根据预期故障的数量计划组的大小(不管它们是连续的、一次性发生的还是零星发生的)。
下面几节将解释如果系统分区的方式使组中的服务器无法自动实现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上停止Group Replication(或完全停止s1和s2)，弄清楚s3、s4和s5上发生了什么，然后重新启动Group Replication(或服务器)。
组复制允许您通过强制执行特定配置来重置组成员列表。例如，在上面的例子中，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，获取如下信息。
SELECT @@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上。
mysql> 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声明。