故障分析 | ClickHouse 集群分布式 DDL 被阻塞案例一则

作者：任坤

现居珠海，先后担任专职 Oracle 和 MySQL DBA，现在主要负责 MySQL、mongoDB 和 Redis 维护工作。

本文来源：原创投稿

* 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

1、背景

线上有套10节点 clickhouse 集群，5分片 * 2副本，版本19.7.3。

开发执行一个创建分布式表的操作，9个节点都成功返回，有个节点报错，返回信息如下：

Code: 159. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: Wa
tching task /clickhouse/task_queue/ddl/query‐0003271440 is executing longer
than distributed_ddl_task_timeout (=180) seconds. There are 1 unfinished ho
sts (0 of them are currently active), they are going to execute the query i
n background.

2、诊断

登录该节点查看 show processlist ，正在执行1个分布式 ddl ，该 ddl 已经运行100多个小时，应该是卡住了。

clickhouse 的分布式 ddl 是串行执行的，每次将任务存储到 zookeeper的/clickhouse/task_queue/ddl目录，按照 FIFO 排列。

对于每个节点，只有当前的ddl执行完毕，后面的才能被调用。

select * from zookeeper where path='/clickhouse/task_queue/ddl' order by ctime desc\G

刚刚发起的创建分布式表 ddl 排在第一位，上述截图中的 optimize table 排在第23，说明被其阻塞的 ddl 有22条之多，开发也确认最近两天的 ddl 任务在该节点上都没有成功。

尝试将其kill，等待几个小时仍然没有效果。

加 sync 关键字，直接卡住。

尝试重启ck实例也卡住，最后只能Kill -9。

重启实例后该任务依然存在，而且执行了10多分钟没有要结束的意思，kill操作仍然无效。

既然这个 ddl 无法绕过，执行的时候又长时间不结束，只能曲线救国，重命名该表让其临时消失一会。

rename table log_catch_data_local to log_catch_data_local1;

optimize table 当即返回，并且其后22个 ddl 也很快执行完毕，最后再将其重命名回原表。

此时再次执行 optimize table ，只需5s便成功返回，该问题解决。

3、总结

clickhouse 的分布式 ddl 在每个节点是 FIFO 串行执行的，任意1个 ddl 卡住了都会阻塞后续任务。

本例中的卡住的 ddl 是 optimize table ，可以通过重命名表跳过；如果是增删列，可以在 rename 后手工对该表执行本地 ddl 。

如果上述方法都不行，可以在出问题的节点将本地表直接 drop ，等待所有阻塞 ddl 执行完毕后，重新创建1个空表，会自动从另一个副本中同步数据。

最后，19.x版本已经很旧了，我们在使用过程中遭遇了各种问题，要尽快升级到20.x系列

本文关键字：#分布式ddl# #zookeeper#