参考官方文档：

https://dev.mysql.com/doc/refman/5.7/en/group-replication.html

创建容错系统的最常见方法是使组件冗余，换句话说，组件可以被移除，系统应该继续按预期运行。 这产生了一系列挑战，将这些系统的复杂性提高到一个完全不同的水平。 具体而言，复制数据库必须处理这样一个事实，即它们需要维护和管理多个服务器而不是一个服务器。 此外，由于服务器正在协同创建该组，因此必须处理其他几个经典的分布式系统问题，例如网络分区或脑裂情景。

因此，最终的挑战是将数据库和数据复制的逻辑与以一致且简单的方式协调多个服务器的逻辑融合。 换句话说，让多个服务器就系统状态和每个变化的数据达成一致。 这可以概括为让服务器在每个数据库状态转换时达成一致，以便它们都作为单个数据库进行，或者它们最终会聚到相同的状态。 这意味着它们需要作为（分布式）状态服务器运行。

MySQL Group Replication通过服务器之间的强协调提供分布式状态机复制。 当服务器属于同一组时，服务器会自动进行协调。 该组可以在具有自动主要选举的单主模式下操作，其中一次只有一个服务器接受更新。 或者，对于更高级的用户，组可以在多主模式下部署，其中所有服务器都可以允许更新，即使它们是同时发布的。 这种能力的代价是应用程序必须解决此类部署所带来的限制。

有一个内置的组成员服务，可以在任何给定的时间点保持组的视图一致并可供所有服务器使用。 服务器可以离开并加入组，视图也会相应更新。 有时，服务器可能会意外离开组，在这种情况下，故障检测机制会检测到此情况并通知组视图已更改。 这都是自动的。

对于要提交的事务，该组的大多数必须就全局事务序列中给定事务的顺序达成一致。 决定提交或中止事务由每个服务器单独完成，但所有服务器都做出相同的决定。 如果存在网络分区，导致成员无法达成协议，则在解决此问题之前系统不会继续进行。 因此，还有一种内置的自动裂脑保护机制。

所有这些都由提供的组通信系统（GCS）协议提供支持。 它们提供故障检测机制，组成员服务以及安全且完全有序的消息传递。 所有这些属性都是创建系统的关键，该系统可确保在服务器组中一致地复制数据。 该技术的核心是Paxos算法实现的。 它充当组通信引擎。

17.1.1 复制技术

17.1.1.1 主-从 复制

传统的MySQL Replication提供了一种简单的Primary-Secondary复制方法。 有一个主要（主），有一个或多个辅助（slave）。 主用来执行事务，提交它们，然后它们稍后（因此异步）发送到辅助节点，以便重新执行（在基于语句的复制中）或应用（在基于行的复制中）。 它是一个无共享系统，默认情况下所有服务器都拥有完整的数据副本。

还有半同步复制，它为协议添加了一个同步步骤。 这意味着主服务器在提交时等待辅助服务器确认它已收到该事务。 只有这样，主服务器才会恢复提交操作。

在上面的两张图中，您可以看到经典异步MySQL复制协议（以及它的半同步变体）的图表。 对角箭头表示服务器之间交换的消息或服务器与客户端应用程序之间交换的消息。

17.1.1.2 组复制

组复制是一种可用于实现容错系统的技术。 复制组是一组通过消息传递相互交互的服务器。 通信层提供一组保证，例如原子消息和所有订单消息传递。 这些是非常强大的属性，可以转换为非常有用的抽象，可以用来构建更高级的数据库复制解决方案。

MySQL Group Replication构建于此类属性和抽象之上，并实现了多主机随处更新的复制协议。本质上，复制组由多个服务器组成，组中的每个服务器可以独立地执行事务。但是所有读写（RW）事务只有在得到组的批准后才会提交。只读（RO）事务在组内不需要协调，因此立即提交。换句话说，对于任何RW事务，组需要决定它是否提交，因此提交操作不是来自始发服务器的单方面决定。确切地说，当事务准备好在始发服务器提交时，服务器以原子方式广播写入值（更改的行）和对应的写入集（被更新的行的唯一标识符）。然后为该事务建立全局total order 。最终，这意味着所有服务器都以相同的顺序接收相同的事务集。因此，所有服务器都以相同的顺序应用相同的更改集，因此它们在组内保持一致。

但是，在不同服务器上并发执行的事务之间可能存在冲突。 这些冲突被检查两个不同和并发事务的写集检测，这个过程叫做 certification。 如果在不同服务器上执行的两个并发事务更新同一行，则存在冲突。 解决过程是，首先被订购的事务在所有服务器上提交，而第二个被订购的事务中止，因此在原始服务器上回滚并由组中的其他服务器删除。 这实际上是分布式的先提交胜出的规则。

最后，组复制是一种无共享复制方案，其中每个服务器都有自己的整个数据副本。

上图描绘了MySQL Group Replication协议，通过将其与MySQL Replication（甚至是MySQL半同步复制）进行比较，您可以看到一些差异。 请注意，为清楚起见，此图中缺少一些潜在的共识和与Paxos相关的消息。

17.1.2 组复制使用场景

通过组复制，您可以通过将系统状态复制到一组服务器来创建具有冗余的容错系统。即使某些服务器随后发生故障，只要它不是全部或大多数，系统仍然可用。根据失败的服务器数量，该组可能会降低性能或可伸缩性，但它仍然可用。服务器故障是孤立且独立的。它们由组成员服务跟踪，该服务依赖于分布式故障检测器，该检测器能够在任何服务器离开组时发出信号，无论是自愿还是由于意外停止。有一个分布式恢复过程，以确保当服务器加入组时，它们会自动更新。不需要服务器故障转移，并且任何位置的多主机更新可确保在单个服务器发生故障时不会更新不给被阻塞。总而言之，MySQL Group Replication保证数据库服务持续可用。

重要的是要了解尽管数据库服务可用，但在服务器崩溃的情况下，必须将连接到它的客户端重定向或故障转移到其他服务器。 这不是Group Replication尝试解决的问题。 连接器，负载平衡器，路由器或某种形式的中间件更适合处理此问题。 例如，请参阅 MySQL Router 8.0。

17.1.2.1 场景例子

以下示例是组复制的典型用例。

• 弹性复制 - 需要非常流畅的复制基础架构的环境，其中服务器的数量必须动态增长或缩小，并且副作用尽可能少。 例如，云数据库服务。
• 高可用 shards - 分片是实现写入横向扩展的常用方法。 使用MySQL组复制实现高可用性分片，其中每个分片映射到复制组。
• 主从复制的替代方案 - 在某些情况下，使用单个主服务器会使其成为单点争用。 在某些情况下，写入整个组可能会更具可扩展性。
• 自主系统 - 此外，您可以完全部署MySQL组复制，以实现复制协议中内置的自动化（本章和前面章节中已有介绍）。

17.1.3 组复制细节

17.1.3.1 故障检测

提供了一种故障检测机制，能够查找并报告哪些服务器是静默的，因此被假定已经死亡。 在较高级别，故障检测器是一种分布式服务，它提供有关哪些服务器可能已死（怀疑）的信息。 稍后如果小组同意怀疑可能是真的，那么小组就会确定给定的服务器确实失败了。 这意味着该组中的其余成员采取协调决策以排除给定成员。

服务器静默时会触发怀疑。 当服务器A在给定时间段内没有从服务器B接收消息时，会发生超时并引发怀疑。

如果服务器与组的其余部分隔离，则会怀疑所有其他服务器都已失败。 由于无法与该集团达成协议（因为它无法确定法定人数），其怀疑并没有后果。 当服务器以这种方式与组隔离时，它无法执行任何本地事务。

--此节点会被集团排除，并且无法执行本地事务

17.1.3.2 组成员关系

MySQL Group Replication依赖于组成员关系服务。 这是内置于插件中的。 它定义了哪些服务器在线并参与该组。 在线服务器列表通常称为view。 因此，组中的每个服务器都具有一致的视图，其是在某一时刻时刻主动参与该组的成员。

服务器不仅必须同意事务提交，还要同意当前视图。 因此，如果服务器同意新服务器成为组的一部分，则组将该服务器重新配置集成在其中，从而触发视图更改。 相反的情况也会发生，如果服务器自愿离开组，则组会动态重新排列其配置并触发视图更改。

请注意，当成员自愿离开时，它首先启动动态组重新配置。 这会触发一个过程，所有成员必须在没有离开服务器的情况下就新视图达成一致。 但是，如果一个成员不由自主地离开（例如它已意外停止或网络连接断开），则故障检测机制会实现这一事实，并建议重新配置该组。 如上所述，这需要集团中大多数服务器的同意。 如果该组无法达成同意（例如，它没有以多数服务器在线的方式进行分区），则系统无法动态更改配置因此组织脑裂的情况。 最终，这意味着管理员需要介入并解决此问题。

17.1.3.3 容错

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

--假如要容忍2台故障，则最少需要5台服务器的组

在实践中，这意味着为了容忍一个故障，该组必须具有三个服务器。 因此，如果一个服务器发生故障，仍然有两个服务器构成多数（三个中的两个），并允许系统继续自动做出决策并继续进行。 但是，如果第二个服务器意外地失败，那么该组（剩下一个服务器）会阻塞，因为没有多数人可以做出决定。