分布式 | ddl 失败在 dble 中排查过程

作者:冒飞
爱可生 dble 项目测试组成员,负责 dble 相关测试工作,拥有多年数据库中间件测试经验,擅长故障排查及性能调优。
本文来源:原创投稿
*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

思考一个问题:

当我们用 dble 执行一个 ddl hang 住时,我们该如何下手,如何找到这条 ddl hang 住的原因?是我们自己的操作导致还是踩中了 dble 的 bug ?

下面我们从一个简单的场景着手来分析这个问题:

场景:对 shanging_4_t1 这张表执行 alter,结果 hang 住了

1.png

分析第一步:查看 dble 日志看是否有报错?

2.png

结果找到这个告警,报错信息跟我们观察到的现象是一致的。

分析第二步:查看这个日志的上下文,找出这个阶段 dble 都做了什么,问题可能出现在哪个阶段?

如果日志信息比较多,我们可以简单删选一下。

命令:less dble.log|grep DDL

3.png

从上面的信息我们大概可以看出,这个语句要发往 4 个分片,且这条 ddl 在 dble 执行中包括 2 个步骤。

  • 步骤一:测试连接可用性
  • 步骤二:真正下发 ddl

日志中可以很明显的看出,步骤一验证连接都成功完成了,但其中一个节点执行语句的状态一直处于 start。

4.png

根据提示出问题的 connection 为 23,可以定位到问题所在的 dataNode:dn2。

5.png

同时可以找到在对应节点上的 mysql 的线程号:29。

6.png

分析步骤三:连接日志中提示的出问题的 mysql 节点上,执行 show @@processlist

7.png

可以看出该节点上的 ddl 在等待一把锁。分析到这一步,我们大概已经知道该 ddl 执行 hang 住的原因了,是因为其中一个节点上该语句的在等待锁的释放,无法成功返回结果。

总结

当在 dble 上遇到 ddl 执行失败的时候,我们的排查步骤大致为:

  1. 观察 dble 日志,查找是否有相关的报错或告警。
  2. 查找报错或告警的上下文,简单的理解 dble 的处理机制,找到该问题出现的环节。
  3. 根据日志提示进一步到对应节点上查找原因。

你可能感兴趣的:(mycat,中间件,开放源代码,数据库)