思考一个问题：
当我们用 dble 执行一个 ddl hang 住时，我们该如何下手，如何找到这条 ddl hang 住的原因？是我们自己的操作导致还是踩中了 dble 的 bug ？下面我们从一个简单的场景着手来分析这个问题：
场景：对 shanging_4_t1 这张表执行 alter，结果 hang 住了
分析第一步：查看 dble 日志看是否有报错？
结果找到这个告警，报错信息跟我们观察到的现象是一致的。
分析第二步：查看这个日志的上下文，找出这个阶段 dble 都做了什么，问题可能出现在哪个阶段？
如果日志信息比较多，我们可以简单删选一下。
命令：less dble.log|grep DDL
从上面的信息我们大概可以看出，这个语句要发往 4 个分片，且这条 ddl 在 dble 执行中包括 2 个步骤。
步骤一：测试连接可用性
步骤二：真正下发 ddl
日志中可以很明显的看出，步骤一验证连接都成功完成了，但其中一个节点执行语句的状态一直处于 start。
根据提示出问题的 connection 为 23，可以定位到问题所在的 dataNode：dn2。
同时可以找到在对应节点上的 mysql 的线程号：29。
分析步骤三：连接日志中提示的出问题的 mysql 节点上，执行 show @@processlist
可以看出该节点上的 ddl 在等待一把锁。分析到这一步，我们大概已经知道该 ddl 执行 hang 住的原因了，是因为其中一个节点上该语句的在等待锁的释放，无法成功返回结果。
总结
当在 dble 上遇到 ddl 执行失败的时候，我们的排查步骤大致为：
1. 观察 dble 日志，查找是否有相关的报错或告警。2. 查找报错或告警的上下文，简单的理解 dble 的处理机制，找到该问题出现的环节。3. 根据日志提示进一步到对应节点上查找原因。
