组复制官方翻译九、Group Replication Technical Details

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机制就开启