ClickHouse 集群分布式 DDL 被阻塞案例
Tags： ClickHouse故障处理
1、背景
线上有套10节点 clickhouse 集群，5分片 * 2副本，版本19.7.3。
开发执行一个创建分布式表的操作，9个节点都成功返回，有个节点报错，返回信息如下：
1 2 3 4 5 | 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执行完毕，后面的才能被调用。
1 | 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 无法绕过，执行的时候又长时间不结束，只能曲线救国，重命名该表让其临时消失一会。
1 | 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系列
