展开查看详情
1 .万里数据库CTO 娄帅
2021 年 3 月 20 日
北京万里开源软件有限公司
2 .01 MGR架构介绍
02 Bug修复流程
03 现状和未来
3 . Group Replication Plugin Architecture
分层设计，保持接口和实现相对独立
server层与plugin的接口
• server层状态信息传递
• 用户事务信息传递
1. 本节点事务信息传递到MGR集群
2. 其他节点事务应用到本节点
4 . Group Replication Plugin Architecture
分层设计，保持接口和实现相对独立
• Capture: 跟踪本节点的事务相关
信息
• Applier: 执行其它节点的远程事务
• Recovery：负责故障恢复时，选
择donar节点，catch up binlog等
5 . Group Replication Plugin Architecture
分层设计，保持接口和实现相对独立
• MGR协议逻辑
• 消息的封装
• 接收XCOM返回的消息
• 发送本节点消息给XCOM
• 冲突检测等
6 . Group Replication Plugin Architecture
分层设计，保持接口和实现相对独立
• GCS Interface: 定义了GCS的具
体实现与处理逻辑之间的统一接口
• GCE: GCS的具体实现，
Xcom(eXtended
COMmunications)
7 .Group Replication Plugin Architecture
分层设计，保持接口和实现相对独立
8 .Life of a Transaction Commit in MGR
9 .Life of a Transaction Commit in MGR
10 .Life of a Transaction Commit in MGR
11 .Life of Transaction Commit under AFTER Consistency Level
12 .01 MGR架构介绍
02 Bug修复流程
03 现状和未来
13 .Bug现场
1.server1, server2, server3组成的三节点MGR集群
2.server1, server2处于ONLINE状态，server3手动关闭
3.server1上在不间断并发执行事务
4.当重启server3实例，start group_replication后，server1报错异常退出。
server1执行请求的客户端报错信息：
ERROR 3798 (HY000) at line 1: Error while waiting for transactions with
group_replication_consistency= 'AFTER' to commit.
server1节点的error log日志:
2020-09-29T06:40:09.508840Z 17 [ERROR] [MY-013309] [Repl] Plugin
group_replication reported: 'Transaction '1:247' does not exist on Group
13
Replication consistency manager while receiving remote transaction prepare.'
2020-09-29T06:40:09.508882Z 17 [ERROR] [MY-011452] [Repl] Plugin
group_replication reported: 'Fatal error during execution on the Applier process of
Group Replication. The server will now leave the group.'
14 .Bug现场
通过比较server1和server2的binlog，发现server2比server1多了246和247两条
日志。
245是drop table t3
246是view change日志。
247是server1错误日志中的报错事务, drop table t1.
15 . Bug 分析
通过server1的报错信息，定位到具体
的报错函数:
handler_remote_prepare
具体的报错逻辑：
1. 收到remote_prepare消息
2. 根据remote_prepare的gtid
1. 查找本地处于MGR提交状态
的事务列表，是否有对应的
gtid的事务
2. 或者已经提交的gtid
3. 如果都找不到，则报错
为什么server2上产生的247号
事务的remote prepare，在
server1上没有对应的事务呢？
17 .Bug 分析
1. drop table t3处于local prepared状态，事务号245
2. view change到来，发现有本地为提交的事务，故delay
3. drop table t1应用，分配了246事务号
4. 245 remote prepare消息到来，激活245号事务提交
5. 247 remote prepare消息到来，找不到对应的gtid，异常退出
主要原因是local prepared状态的事务导致了view change delay，
view change delay后续的事务占用本该属于view change的gtid，
导致了gtid在节点间不一致的情况。
18 . 修复方案
根本原因是因为delay view
change后续的事务占用了
view change的GTID。
故我们需要保证delay view
change之后的事务需要等待
view change执行完成之后，
才能真正应用。
完善测例，保证问题可回归。
MGR目前版本里，关
于并发时序问题的Bug
不仅这一个。
19 .01 MGR架构介绍
02 Bug修复流程
03 现状和未来
20 .All Verified Bugs
重现MGR Bug比一般Bug更复杂，导致用户无法准确描述和复现Bug。
Need Feedback, Can't repeat，一些Bug石沉大海。
21 .Bugs reported by 万里数据库
21
23 .回馈社区
4月1日
发布二进制包
扫码入群，领取软件试用版&演讲ppt
25 .不忘DB初心，牢记万里使命
谢谢！
万里数据库官微
热门城市
