mysql 组复制（MGR）系列文章（三）之组复制相关的服务及组复制插件体系结构介绍

一、组内成员资格服务

组内成员资格服务(Group Membership)：

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

如果服务器加入该组，它会通过从现有服务器获取缺失的状态来自动更新自己。如果一台服务器离开了该组，例如它被关闭进行维护，其余的服务器会注意到它已经离开并自动重新配置该组。

组复制具有组成员资格服务，该服务定义哪些服务器联机并参与组。联机服务器列表称为视图。组中的每个服务器都有一个一致的视图，可以查看哪些服务器是在给定时刻积极参与组的成员。

组成员不仅必须就事务提交达成一致，还必须就当前视图达成一致。如果现有成员同意新服务器应成为组的一部分，则将重新配置组以将该服务器集成到其中，从而触发视图更改。如果服务器离开组，无论是自愿还是非自愿，组都会动态重新排列其配置，并触发视图更改。

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

二、故障检测服务

故障检测服务(Failure Detection):

组复制的故障检测机制是一种分布式服务，能够识别组中的服务器未与其他服务器通信，因此怀疑其已停止服务。如果该组织的共识是怀疑可能是真的，该组织将做出协调一致的决定，驱逐该成员。开除没有沟通的成员是必要的，因为该组需要大多数成员就事务提交或视图更改达成一致。如果某个成员没有参与这些决策，则该组必须将其删除，以增加该组包含大多数正常工作成员的机会，从而可以继续处理事务。

在复制组中，每个成员之间都有一个点对点的通信通道，从而创建了一个完全连接的图。这些连接由组通信引擎（XCom，Paxos变体）管理，并使用TCP/IP套接字。一个通道用于向成员发送消息，另一个通道则用于接收来自该成员的消息。如果一个成员在5秒内没有收到来自另一个成员的消息，则怀疑该成员失败，并在其自己的性能模式表replication_group_members中将该成员的状态列为UNREACHABLE。

如果怀疑持续超过10秒，则怀疑成员会试图将其认为可疑成员已失败的观点传播给该组的其他成员。在这种情况下，在协调决策中，可疑成员会被标记为从组中驱逐，并在group_replication_member_expel_timeout系统变量设置的等待期到期后被驱逐，驱逐机制会检测并执行驱逐。

如果网络不稳定，成员经常以不同的组合失去和重新建立联系，理论上一个团体最终有可能将其所有成员标记为驱逐，之后该团体将不复存在，必须重新建立。为了应对这种可能性，从MySQL 8.0.20开始，组复制的组通信系统（GCS）跟踪已标记为驱逐的组成员，并在决定整个组内是否有多数节点可用时将其视为可疑成员组中的一员。这确保了组中至少有一个成员，并且组可以继续存在。当被开除的成员实际上已被开除出该团体时，GCS会删除该成员开除的记录，以便该成员在有能力的情况下可以重新加入该团体。

三、容错性服务

容错性服务(Fault-tolerance):

MySQL组复制构建在Paxos分布式算法的实现之上，以提供服务器之间的分布式协调。因此，它需要大多数服务器处于活动状态才能达到法定人数，从而做出决定。这直接影响了系统在不损害自身及其整体功能的情况下可以容忍的故障数量。一个组内正常节点的数量必须达到n/2 + 1(n为组内节点总数)该复制组才能正常工作。
在实践中，这意味着要容忍一次故障，该组中必须有三台服务器。因此，如果一台服务器发生故障，仍有两台服务器形成多数（三分之二），并允许系统继续自动做出决策并取得进展。然而，如果第二台服务器非自愿地发生故障，那么该组（还剩一台服务器）就会阻止，因为没有多数人可以做出决定。

四、可观察性

可观察性（Observability）：

Group Replication插件内置了很多自动化功能。尽管如此，你有时可能需要了解幕后发生的事情。这就是Group Replication和Performance Schema的检测变得重要的地方。可以通过Performance Schema里面的表查询系统的整个状态（包括视图、冲突统计和服务状态）。复制协议的分布式特性以及服务器实例在事务和元数据上达成一致并同步的事实，使检查组的状态变得更加简单。例如，您可以连接到组中的单个服务器，并通过在组复制相关的Performance Schema里面的表上发出select语句来获取本地和全局信息。有关更多信息，请参阅 监控组复制。

五、组复制插件体系结构

MySQL Group Replication是一个MySQL插件，它基于现有的MySQL复制基础架构构建，利用了二进制日志、基于行的日志和全局事务标识符等功能。下图展示了MySQL组复制的整体架构框图

MySQL组复制插件包括一组用于捕获、应用和生命周期的API，这些API控制着插件与MySQL服务器的交互方式。有一些接口可以使信息从服务器流向插件，反之亦然。这些接口将MySQL服务器核心与组复制插件隔离开来，并且大多是放置在事务执行管道中的钩子。在一个方向上，从服务器到插件，会有关于服务器启动、服务器恢复、服务器准备接受连接以及服务器即将提交事务等事件的通知。在另一个方向上，插件指示服务器执行诸如提交或中止正在进行的事务，或在中继日志中排队事务等操作。

组复制插件架构的下一层是一组组件，当通知路由到它们时，这些组件会做出反应。捕获组件负责跟踪与正在执行的事务相关的上下文。应用程序组件负责在数据库上执行远程事务。恢复组件管理分布式恢复，并负责通过选择供体、管理追赶过程和对供体失败做出反应，使加入组的服务器保持最新状态。

继续往下看，复制协议模块包含复制协议的特定逻辑。它处理冲突检测，并接收事务并将其传播到组。

组复制插件体系结构的最后两层是组通信系统（GCS）API和基于Paxos的组通信引擎（XCom）的实现。GCS API是一个高级API，它抽象了构建复制状态机所需的属性。因此，它将消息传递层的实现与插件的其余上层解耦。组通信引擎处理与复制组成员的通信。