组复制官方翻译九、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

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

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,且正在处理即将要来的事务
有些成员可能落后,但是最后都会追上

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

  • View Change: a Member Joins

当一个新的成员需要加入时,这个view就change了,每一个server都在queue一个view change

同时,S4 选择需要在online列表中选择一个server作为donar
每一个online server 都讲view change事 写入到了 binlog

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

  • State Transfer: Catching Up

一旦这个server选择了s2作为donar,那么就会创建一个异步复制通道(之前说过的phase1)来同步数据,直到之前的view change 事件(VC4)

换句话说就是:新成员从donar(s2)中复制数据,直到view change 事件结束(vc4)

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

当server正从donar中同步数据的同时,它也会cache住从group传来的事务(temporary Applier Buffer)。
一旦从donar同步结束,就会切换,选择来应用之前cache的事务

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

  • Finish: Caught Up

在 catch up (phase 2) 阶段中,一旦cached事务队列数量变成0,他就会变成online,正式成为其中一员

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

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%的吞吐

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

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

默认情况下,压缩是开启的
默认是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机制就开启

上一篇:如何从 0 到 1 开发 PyFlink API 作业


下一篇:组复制官方翻译八、Frequently Asked Questions