背景

今天clickhouse在执行相关的脚本时不定时的出现超时报错。

报错内容：

DB::Exception: Watching task /clickhouse/task_queue/ddl/query-xxx is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 1 unfinished hosts (0 of them are currently active), they are going to execute the query in background.

分析过程

1. 一开始以为是clickhouse中存在某些进程卡住，导致后面的脚本执行不了。所以查询进程，但并未发生卡死的进程。

## 查询进程情况
select * from system.processes;
## 关键字段：query_id、elapsed（执行时间）、query（查询内容）、client_houstname（客户端地址）
## 附带删除进程的脚本
KILL QUERY WHERE query_id='123-234-345-456-765-234-345' 

这里发生了一个小插曲。因kiil query操作太频繁，所以导致剩下的两个节点也被我整挂了，整个集群都不可用。但过了十分钟后又恢复了，初步猜测是zookeeper的心跳机制发挥作用。

2. 但观察了一段时间后，发现一个现象：仅在optimize table的时候，执行时间elapsed到180s后，进程才消失，所以定位到问题所在了，optimize table抛超时异常。其他的查询跟写数据并未发现异常。
3. 尝试在clickhouse开发文档中看看能不能找到答案。浏览了一会，被一句话吸引到了。 “当 OPTIMIZE 与 ReplicatedMergeTree 家族的表引擎一起使用时，ClickHouse将创建一个合并任务，并等待所有节点上的执行。” 灵光一闪：“会不会是有节点挂了。”因为在数据合并的过程，如果有节点挂了，合并不了。但这也并不影响数据的查询与写入
4. 检查了一下节点的健康情况，确实有个节点的clickhouse-server挂了。
5. 重启挂掉节点的clickhouse-server，结果启动时抛出异常。

service clickhouse-server start

DB::Exception: The local set of parts of table default.test doesn’t look like the set of parts in ZooKeeper: 65.88 million rows of 85.04 million total rows in filesystem are suspicious. There are 545 unexpected parts with 65883643 rows (191 of them is not just-written with 65883643 rows), 0 missing parts (with 0 blocks).

这里也可以解释上面的小插曲，zookeeper能重启clickhouse-server，但该挂掉的节点为什么没能自动启起来。

6. 上述报错的原因是clickhouse的节点挂掉之后，clickhouse发生过alter或truncate的操作，导致挂掉节点的数据跟正常的节点数据不一致。
7. 解决方法，删除问题节点的相关数据表的数据文件。

# 具体路径视clickhouse安装部署时的路径
rm -r /data/clickhouse/data/default/test

8. 处理完，重启成功。
9. 但观察任务执行情况，依旧报执行超时的错误。这个时候怀疑，会不会是数据量过多，在合并数据需要的时间超过了设置时间。
10. 开始尝试针对某个数据表进行删数据。

alter table default.test on cluster ${cluster_name} 
drop partition '2020-01-01'

11. 结果还是报执行超时错误=.= 正当我心灰意冷之时，尝试了多次之后，意外来了，竟然可以成功了。这个时候再看optimize table 的执行情况，也顺利执行了。初步猜测，可能是因为节点刚重启完，集群在做数据平衡，所以处理不了数据合并、删除数据等操作。
12. 至此，问题终于解决了。

参考链接：
clickhouse查看后台进程并杀掉
clickhouse开发文档——OPTIMIZEl
zookeeper数据不一致
clickhouse踩坑之路