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

这一章主要描述一些组复制的背景

构建一个容错系统最常用的方法就是让组件冗余，换句话说就是组件即便被移除掉，整个系统还是能够正常对外提供服务
这无疑在不同层面上提出了更多的挑战
需要注意的是，复制结构的数据库系统必须思考的一个事实就是：他们需要维护和管理一堆不同的sever
此外，他们还必须解决分布式系统所面临的问题：比如 脑裂、网络分区等等

因此，最大的挑战就是去融合这种逻辑数据库，保证数据复制的一致性
换句话说，为了让不同server都同意这个系统的状态，他们每一台server的数据修改都必须验证一致
这就意味着他们需要运作的想一个状态机一样（分布式）

MySQL Group Replication提供了一套分布式状态机制复制管理方法

对于要提交的事务，这个group采取大部分原则来投票，让事务全局有序
决定commit还是拒绝这个事务都是由server自行判断，但是所有servers都会做出一样的决定
如果网络产生了分区，脑裂产生导致成员之间无法达成一致投票决定，那么这个系统会停止运行直到这个问题被解决
所以，他有一个内置、自动的脑裂包含机制在运行

以上所有的功能都是由Group Communication System (GCS) 协议来保证
它有错误检测机制、组成员通信服务、安全可靠的顺序一致消息分发
所有这些特性是搭建一个 数据完全一致性的系统 的关键要素
在一些非常核心重要的技术点上 罗列了Paxos 算法的实现，它扮演着组复制通信引擎的角色，至关重要

18.1.1 Replication Technologies

在了解MGR内幕之前，这里先主要介绍下相关的背景概念、以及概述
这章主要告诉我们，MGR需要什么，以及传统的异步复制和MGR直接的一些区别

18.1.1.1 Primary-Secondary Replication

传统的复制提供了一个简单的主从复制架构（Primary-Secondary）
primary就是master，secondary就是slaves，可以有多个slaves
master执行事务、commit事务，然后异步的将这些事务发送到slaves，让他们re-executed一遍（statement模式）或者 重新applied （ROW模式）
它是share-nothing架构，即所有server都有一份完整的数据copy

还有一种传统复制叫：半同步复制
它意味着：在commit的之前，master等待，直到slaves给master一个确认接收到事务的ack，master才恢复commit的操作

在上面的两幅图中，你能看到异步传统复制协议的基本架构，箭头代表client消息的流动和转变

18.1.1.2 Group Replication

组复制是一个实现了容错系统的技术
组复制集群就是一堆机器，他们之间通过消息进行沟通
communication 层：提供了一系列的保障机制，atomic message（原子广播） ， total order message delivery（全局序列消息分发机制）

MGR在此基础上构建并实现了一个multi-master的复制协议，它可以在任何server上写数据
集群的本质就是多server，每个server可以独立的处理事务
但是所有的读写（RW）事务都必须经过集群的审核
所有的只读（RO）事务不受任何影响
换句话说，对于RW事务，group只需要决定它应该commit还是拒绝commit，因此事务操作并不是单方面（origi server）的决定
确切的说，当origin server准备进行事务commit的时候，这个server会自动广播这个写集
然后，一个全局排序的事务产生了
这意味着，所有的server都接收同样顺序的事务集
由于是有序的，所有server应用相同顺序，相同数据的写集，因此他们的数据也是一致的

然而，如果是并发写在不同server的场景会遇到冲突
因此，对应这种情况需要进行冲突检测，这个过程叫做认证 certification
如果两个并发事务在不同server同时执行，并且更新了相同的row，那么他们就是冲突的
那么它的解决方案就是，排在前面的事务会被标记commit，排在后面的会被拒绝（这个事务在origin server会回滚，其他server会被丢弃）

最后，MGR也是一种share-nothing架构，每个server都有一份完整的数据copy

18.1.2 Group Replication Use Cases

组复制提供了一个高容错性的系统，即使一些机器宕机，只要不是所有或者大多数机器不可用，那么整个系统还是可用状态
总结下来，MGR保证数据库持续可用

18.1.2.1 Examples of Use Case Scenarios

以下就是典型的MGR使用案例

• Elastic Replication 可伸缩的复制
• Highly Available Shards 高可用的分片
• Alternative to Master-Slave replication 可选择master-slave架构
• Autonomic Systems 完全自动化的系统

18.1.3 Group Replication Details

18.1.3.1 Failure Detection

它提供一个错误检测机制，可以找到或报告出哪些servers没有回应，哪些server挂了
在高一层次来将，错误检测机制就是一个分布式服务，用于提供哪些server挂掉或可能挂掉的情报信息
之后，如果组成员通过某种协议认证了这个嫌疑犯（可能挂掉的家伙）已经真的挂了，那么集群就会决定这个嫌疑犯真的的确挂了
这意味着，组的其他成员一致决定将这个嫌疑犯踢出集群

当Server A 在指定time-out时间内没有收到来自server B的回应，那么B就会被提升为嫌疑犯
如果一个Server被其他group成员隔离，那么它就会怀疑所有其他的成员都挂了
由于它不能达成投票的一致性认可（没有达到法定人数的确认），所以它认为的嫌疑犯就不能被确认为failed
如果一个Server在这种情况下被隔离，那么他是不能执行local事务的

18.1.3.2 Group Membership

MGR依赖组会员服务（Group Membership Service，简称GMS），它是内置的
它定义了哪些servers是online并加入了这个group,这些online servers经常被称为view
因此，这个组里面的任一online成员都有一个一致的view

如果servers同意让一个新server加入到这个group中来，那么这个group就好重新自动将其配置上，且重新触发形成一个新的view
如果一个server非自愿的离开了group，那么错误检测机制就开始识别，也会重新配置上一个新的view
上面提到的这些都需要一个协议，并且需要大多数人参与并认可的协议
如果这个group没有满足达到这个协议认可的要求，那么自动配置将不会起作用，并且该系统会被阻塞来防止脑裂的产生
最后，这意味着管理员需要手动介入来解决这个问题

18.1.3.3 Fault-tolerance

MGR 是在Paxos分布式算法构建实现的，以此它需要满足大多数活跃成员进行投票选举的策略。
有一个公式：n = 2 x f + 1 ， n代表group的成员数，f代表允许挂掉的成员数 ，在这个公式下，整个集群是安全的

如果n=3，那么允许挂掉的server是1，也能满足要求，但是如果再挂一个呢， 其实就问题非常大了