申请试用
HOT
登录
注册
 
4.万里开源MGR Bug修复之路-娄帅
0 点赞
0 收藏
0下载
3306π社区
/
发布于
/
27
人观看

万里开源的MGR Bug修复之路

内容介绍

  1. MGR架构介绍
  2. 如何进行Bug修复
  3. 我们对MGR做的工作

作者信息

娄帅 万里开源CTO 专注于分布式数据库研发领域

展开查看详情

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上没有对应的事务呢?

16.Bug 分析

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

22.MGR缺陷分类

23.回馈社区 4月1日 发布二进制包 扫码入群,领取软件试用版&演讲ppt

24.互动答疑环节 24

25.不忘DB初心,牢记万里使命 谢谢! 万里数据库官微

0 点赞
0 收藏
0下载