Contents

1. 1. 18.10.1 Group Replication Plugin Architecture
2. 2. 18.10.2 The Group
3. 3. 18.10.3 Data Manipulation Statements
4. 4. 18.10.4 Data Definition Statements
5. 5. 18.10.5 Distributed Recovery
   1. 5.1. 18.10.5.1 Distributed Recovery Basics
   2. 5.2. 18.10.5.2 Recovering From a Point-in-time
   3. 5.3. 18.10.5.3 View Changes
   4. 5.4. 18.10.5.4 Usage Advice and Limitations of Distributed Recovery
6. 6. 18.10.6 Observability
7. 7. 18.10.7 Group Replication Performance
   1. 7.1. 18.10.7.1 Fine Tuning the Group Communication Thread
   2. 7.2. 18.10.7.2 Message Compression
   3. 7.3. 18.10.7.3 Flow Control
      1. 7.3.1. 18.10.7.3.1 探针和统计
      2. 7.3.2. 18.10.7.3.2 MGR Throttling

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