组复制服务

组成员身份

在MySQL组复制中，一组服务器构成一个复制组。群组具有名称，该名称采用UUID的形式。该组是动态的，服务器可以随时离开（自愿或非自愿）并加入。每当服务器加入或离开时，该组都会进行自我调整。

如果服务器加入该组，它将通过从现有服务器获取丢失的状态来自动使自己处于最新状态。如果服务器离开了该组，例如已被拆除以进行维护，则其余服务器会注意到该服务器已离开并自动重新配置该组。

组复制具有组成员资格服务，该服务定义了哪些服务器处于联机状态并参与该组。联机服务器列表称为视图。组中的每台服务器都具有一致的视图，即在给定的时间哪些成员是积极参与组的服务器。

组成员不仅必须就事务提交达成共识，而且必须就当前观点达成一致。如果现有成员同意将新服务器纳入组，则将组重新配置为将该服务器集成到其中，从而触发视图更改。如果服务器自愿离开该组，则该组将动态重新排列其配置，并触发视图更改。

在成员自愿离开组的情况下，它首先启动动态组重新配置，在此期间，所有成员必须在不离开服务器的情况下就新视图达成一致。但是，如果成员非自愿离开该组，例如由于该成员意外停止或网络连接断开，则它将无法启动重新配置。在这种情况下，组复制的故障检测机制会在短时间内识别出该成员已离开，并提出了重新配置没有故障成员的组的建议。与自愿退出的成员一样，重新配置需要组中大多数服务器的同意。但是，如果小组无法达成协议，例如，由于它的分区方式使得大多数服务器都不在线，因此系统无法动态更改配置，并阻止以防止出现脑裂情况。这种情况需要管理员的干预。

成员可能会短暂脱机，然后在故障检测机制检测到其故障之前以及在重新配置组以删除该成员之前，尝试再次重新加入该组。在这种情况下，重新加入的成员会忘记其先前的状态，但是如果其他成员向其发送旨在用于其崩溃前状态的消息，则可能导致出现问题，包括可能的数据不一致。如果处于这种情况的成员参加XCom的共识协议，则有可能导致XCom通过在失败前后做出不同的决定来为同一共识回合提供不同的价值。

为了应对这种可能性，从MySQL 5.7.22和MySQL 8.0开始，服务器在加入组时会被赋予唯一的标识符。这样，组复制就可以了解以下情况：同一台服务器的新实例（具有相同的地址，但有一个新的标识符）正试图加入该组，而旧实例仍被列为成员。新的化身被阻止加入该组，直到可以通过重新配置将旧的化身移除为止。如果group_replication_member_expel_timeout系统变量已设置为允许成员有更多时间在被驱逐之前返回到该组，被怀疑的成员可以重新加入，只要它实际上并未失败即可。如果组复制在服务器上停止并重新启动，则该成员将成为新的化身，并且在怀疑超时之前不能重新加入。

故障检测

组复制包括故障检测机制，该机制能够找到并报告哪些服务器处于静默状态，并因此认为已死机。总体而言，故障检测器是一种分布式服务，可提供有关哪些服务器可能死机（怀疑）的信息。服务器静音时会触发怀疑。如果服务器A在给定时间段内未收到来自服务器B的消息，则会发生超时并引起怀疑。后来，如果小组同意这种怀疑可能是真的，那么该小组将确定给定的服务器确实发生了故障。这意味着组中的其余成员将做出共同决定以开除给定成员。

如果服务器与组中的其他服务器隔离，则它怀疑所有其他服务器均已失败。无法与该组达成协议（因为它无法达到法定人数），因此对其怀疑不会产生任何后果。通过这种方式将服务器与组隔离时，它将无法执行任何本地事务。

在网络不稳定且成员经常以不同组合失去和重新建立联系的情况下，从理论上讲，一个小组有可能最终将其所有成员标记为驱逐，此后该小组将不复存在并必须成立再次。为了解决这种可能性，从MySQL 8.0.20开始，组复制的组通信系统（GCS）跟踪标记为驱逐的组成员，并在确定是否存在多数成员时将其视为可疑成员组中的成员。。这样可确保组中至少保留一个成员，并且该组可以继续存在。当被驱逐成员实际上已从组中删除时，

有关您可以配置为指定工作组成员对故障情况的响应以及可疑失败的组成员采取的操作的组复制系统变量的信息，请参见“对故障检测和响应的响应”。网络分区”。

容错

MySQL组复制建立在Paxos分布式算法的实现之上，以提供服务器之间的分布式协调。因此，它需要大多数服务器处于活动状态才能达到法定人数，从而做出决定。这直接影响了系统可以容忍的故障数量，而不会损害自身及其整体功能。这样，容忍f故障所需的服务器数量（n）为n = 2 x f + 1。

实际上，这意味着要容忍一个故障，该组中必须包含三台服务器。这样一来，如果一台服务器发生故障，仍然会有两台服务器形成多数（三分之二），并使系统继续自动做出决定并继续前进。但是，如果第二台服务器不由自主地发生故障，则该组（仅剩一台服务器）将阻塞，因为没有多数可以决定。

下表是说明上述公式的小表。

可观察性

组复制插件中内置了许多自动化功能。但是，您有时可能需要了解幕后发生的事情。在这里，组复制和性能模式的检测变得很重要。可以通过Performance Schema表查询系统的整个状态（包括视图，冲突统计信息和服务状态）。复制协议的分布式性质以及服务器实例同意并因此在事务和元数据上同步的事实，使得检查组的状态变得更加简单。例如，您可以连接到组中的单个服务器，并通过在与组复制相关的性能架构表上发布select语句来获取本地和全局信息。有关更多信息，请参见“监视组复制”。