https://dev.mysql.com/doc/refman/8.0/en/group-replication-technical-details.html
这一章主要描述MGR的更多细节
18.10.1 Group Replication Plugin Architecture
MGR是一个MySQL插件，它是构建在MySQL复制架构上的，因此就拥有了它的很多优秀的特性
比如： binog、row-based、GTID等
它也整合了现在MySQL的一些组件如：performance schema 、plugin、service的架构
下面一张图可以很好的展示MGR的整体结构和架构
- Figure 18.9 Group Replication Plugin Block Diagram
MGR包括了一系列的API如：capture, apply, and lifecycle，这些东西控制这个plugin如何与MySQL server进行协助
这些接口令信息从server到plugin进行流动这，反之亦然
这些接口将MySQL Server和Group进行了隔离
在某一方面，从server到pugin，有一些事件通知信息如：server的开启、server的恢复、server接收请求连接、提交事务等
在另一方面，plugin通知server完成相关动作，如：commit事务，或拒绝即将来临的事务，让事务排队等
下面一层，又是一些MGR组件
capture组件 负责 执行并与相关的事务持续保持联系
applier组件 负责 执行远程接收的事务
recovery组件 负责 管理分布式恢复，以及管理成员的加入、新成员的日志同步，处理相关donor失败等情况
继续往下，replication protocol模块，包含了具体的逻辑复制协议
他负责处理组复制的事务冲突、竞争
最后2层是：Group Communication System (GCS) API 和 communication engine (XCom)【基于Paxos的实现】
Group Communication System (GCS) API 高层的API，负责抽象复制状态机所需要的属性
communication engine（XCom）主要处理组成员之间的协作和交流
18.10.2 The Group
在MGR中，一堆servers组成了复制group
一个由UUID组成的名字的group
这个group是动态的，且servers可在任何时间*（不管是主动，还是被动）加入和离开
如果一个server加入了一个group，他会自动的从donar中catch没有的事务，这其实就是异步复制机制
如果一个server离开了group，剩下的server会意识到它的离开，并自动重新更新配置
18.10.3 Data Manipulation Statements
任何事务都可以*执行事务不用协调，但是在commit的时候，需要其他server一起协调来做决定这个事务的命运
这种协调有两种目的：
1）检测这个事务是应该commit，还是不应该commit
2）传递这个changes，以至于其他的servers可以很好的应用它
由于事务是通过原子广播的形式来传递，所以要么所有server都能接收到，要么全部都接收不到
如果他们接收到了原子广播信息： 那么他们都将以同样的顺序接收到
由于冲突检测需要比对事务写集，因此他们是在row-level层面上进行检测
冲突检测的解决方案是：谁第一个提交，谁获胜的方式（first committer wins rule）
假设：t1和t2同时提交，那么总有一个在前面，如果t1在前，t2在后，那么t1就会赢得提交权，t2就会被拒绝或rollback
18.10.4 Data Definition Statements
在MGR中，DDL是需要大家关注的
虽然8.0介绍说已经支持原子DDL，就是完全的DDL语句作为一个原子事务一样，要么提交，要么rollback
但是，DDL语句，原子的，非原子的，都会隐式提交当前session的任何活跃事务
也就是说：DDL无法跟其他事务组合使用
MGR是基于乐观复制的模式，也就是先执行，如有必要在rollback的模式
在multi-primary模式下，DDL和DML作用在同一个对象上，会造成数据不一致的情况，所以需要引起大家足够的关心
如果是single-primary，这种问题就不会发生，因为所有事务更新都在同一个server完成，那就是primary
18.10.5 Distributed Recovery
当一个成员加入group，需要追上现有成员的事务日志，这个过程叫做Distributed Recovery
这一节，主要描述Distributed Recovery
18.10.5.1 Distributed Recovery Basics
Distributed Recovery的基础是：异步复制
主要分2阶段：
phase1： 一个server要加入一个group，首先会选择一个成员作为donar，它主要提供新成员所需要的所有事务日志
除此之外，它还会cache住这个group的其他exchange事务
一旦从donar的复制结束，对于donar的异步复制通道就会关闭 ，然后这个server 开启第二个步骤，catch up
phase2：这个阶段，它会执行之前cache住的exchange，直到这个queue的队列为0，最后宣布这个成员为 online
在恢复过程中，如果在phase1的时候，遇到donar server的错误，那么就会换一个server作为donar开始同步数据
如果phase1 donar结束connection的阶段有问题，那么直接开启一个新的connection指向新的donar即可，这都是自动的
18.10.5.2 Recovering From a Point-in-time
GTID可以提供哪些日志需要恢复，server已经处理哪些事务，但是它没办法做到标记一个具体的point（组成员进行catch up），也没办法传送certification信息
这是binlog view marker做的事情，它可以在binlog stream中标记一个view，也可以打上额外的元数据信息标记（缺失的certification信息）
18.10.5.3 View Changes
这一节主要描述 view change identifier内部是如何在binary log 事件中协调工作的
- Begin: Stable Group
所有的成员都是online，且正在处理即将要来的事务
有些成员可能落后，但是最后都会追上
- View Change: a Member Joins
当一个新的成员需要加入时，这个view就change了，每一个server都在queue一个view change
同时，S4 选择需要在online列表中选择一个server作为donar
每一个online server 都讲view change事 写入到了 binlog
- State Transfer: Catching Up
一旦这个server选择了s2作为donar，那么就会创建一个异步复制通道（之前说过的phase1）来同步数据，直到之前的view change 事件（VC4）
换句话说就是：新成员从donar（s2）中复制数据，直到view change 事件结束（vc4）
当server正从donar中同步数据的同时，它也会cache住从group传来的事务(temporary Applier Buffer)。
一旦从donar同步结束，就会切换，选择来应用之前cache的事务
- Finish: Caught Up
在 catch up (phase 2) 阶段中，一旦cached事务队列数量变成0，他就会变成online，正式成为其中一员
18.10.5.4 Usage Advice and Limitations of Distributed Recovery
分布式恢复也有一些限制。
由于phase1阶段需要同步大量数据，所以推荐做法是，在加入group的server，应该要选择一个合适的Snapchat或备份（rencent），这样会减少catch-up的phase1的时间
18.10.6 Observability
由于MGR内部很多机制都是自动的，所以你需要了解其中的原理和场景。
这样看来，Performance Schema是非常重要的，因为他可以监控和查询相关的MGR场景和状态
18.10.7 Group Replication Performance
这一节主要描述怎么样配置才能让MGR达到最好的性能
18.10.7.1 Fine Tuning the Group Communication Thread
当MGR插件load的时候， group communication thread (GCT)就在循环跑起来了
如果想要强制让GCT来等待，可以使用 group_replication_poll_spin_loops
mysql> SET GLOBAL group_replication_poll_spin_loops= 10000;
18.10.7.2 Message Compression
当网络带宽是瓶颈的时候，消息压缩可能提升30-40%的吞吐
默认情况下，压缩是开启的
默认是LZ4，阈值是：1000000 bytes
如果设置阈值：
STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold= 2097152;
START GROUP_REPLICATION;
以上设置的是2MB，意味着，如果事务产生了2MB的消息，它就会压缩。
取消压缩，设置为group_replication_compression_threshold=0
18.10.7.3 Flow Control
大部分成员确认接收到事务，且同意所有事务的顺序后，MGR才能确保事务commit
如果所有的写事务没有超过这个group任何成员的压力承受极限的时候，一切都运行的很好
一旦有部分成员承受不了极限，那么他们就可能落后其他成员
当部分成员落后的时候，就很有可能产生一致性问题，尤其是部分读可能读到的是落后的数据
为了解决这种问题，有一种复制协议机制，他就是流控
流控的队列有两个：1）certification queue 2）binlog applier queue.
两大机制：1）monitor机制 2）Throttling机制
18.10.7.3.1 探针和统计
监控机制是建立在group中设置探针，并定期收集数据，阶段性上报信息，来一起分享这些探针数据
探针数据如下：
- certifier queue 大小
- replication applier queue 大小
- 总认证事务的大小
- 总远程执行事务的大小（一个member）
- 总本地事务的大小
18.10.7.3.2 MGR Throttling
一旦达到1）certification queue 2）binlog applier queue.的上限，那么Throttling机制就开启