20241006-ClickHouse分布式DDL无法执行完成,永远卡在49%!

在这里插入图片描述

问题现象:

clickhouse 数据库,执行分布式DDL(建库、建表、删库、删表等)时,永远卡在49%,超过180秒以后,自动转为后台。

cjcdb01 :) create database cjc ON CLUSTER ck_cjc_cluster;
CREATE DATABASE cjc ON CLUSTER ck_cjc_cluster
Query id: x0cxxx92-xxdc-430b-b7f1-06bxxxx3dxx0
┌─host────────┬──port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐
│ 192.0.10.11 │  9100 │      0 │       │                   5 │                0 │
│ 192.0.10.12 │  9100 │      0 │       │                   4 │                0 │
│ 192.0.10.13 │  9100 │      0 │       │                   3 │                0 │
└─────────────┴───────┴────────┴───────┴─────────────────────┴──────────────────┘
→ Progress: 3.00 rows, 165.00 B (0.05 rows/s., 2.59 B/s.)  49%
↖ Progress: 3.00 rows, 165.00 B (0.02 rows/s., 1.27 B/s.)  49%
↘ Progress: 3.00 rows, 165.00 B (0.02 rows/s., 0.91 B/s.)  49%
3 rows in set. Elapsed: 180.665 sec. 
Received exception from server (version 23.3.8):
Code: 159. DB::Exception: Received from cjcdb01:9000. DB::Exception: Watching task /clickhouse/9000/task_queue/ddl/query-0000000000 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 3 unfinished hosts (0 of them are currently active), they are going to execute the query in background. (TIMEOUT_EXCEEDED)

架构说明:

ck部署在3台服务器上,每台服务器上配置两个ck实例,端口分别为9100和9200,架构是3分片2副本架构。

问题原因:

通过前台显示,9100实例分布式DDL语句执行成功了,登陆9200实例,发现执行失败。
由于一台服务器上安装两个实例,两个实例的端口和路径配置都不同。
其中有一个配置分布式DDL的参数,两个实例的配置分别为:

9100端口:

<distributed_ddl>
    <path>/clickhouse/9100/task_queue/ddl</path>
</distributed_ddl>

9200端口:

<distributed_ddl>
    <path>/clickhouse/9200/task_queue/ddl</path>
</distributed_ddl>

实际上这种配置方式是有问题的,因为这块配置的实际是zookeeper的路径,不是clickhouse的路径,当有分布式DDL执行时是在zookeeper的<distributed_ddl>路径下生成数据,
而不是clickhouse的<distributed_ddl>路径下。

解决方案:

所以这块需要修改为相同的路径,修改后的参数:

9100端口:

<distributed_ddl>
    <path>/clickhouse/task_queue/ddl</path>
</distributed_ddl>

9200端口:

<distributed_ddl>
    <path>/clickhouse/task_queue/ddl</path>
</distributed_ddl>

修改后,不需要重启,再次执行分布式DDL,可以瞬间执行完成。
###chenjuchao 20241001###
欢迎关注我的公众号《IT小Chen

### ClickHouse 分布式表中的数据跳变解决方案 在ClickHouse中,分布式表的数据跳变通常指的是由于网络延迟或其他因素导致某些节点上的数据未能及时同步更新,从而造成查询结果不一致的情况。为了有效应对这一挑战,可以从以下几个方面着手: #### 优化分片策略配置 合理设计分片键能够显著减少因数据分布不合理而引发的问题。应根据实际应用场景选取合适的字段作为分片依据,确保各分片间负载均衡的同时也便于后续维护管理[^1]。 #### 使用ReplicatedMergeTree引擎家族 相较于普通的`Distributed`引擎,采用支持副本功能的`Replicated*`系列存储引擎可以在一定程度上缓解此类现象的发生频率。这类引擎允许为每一个物理分片设置多个逻辑副本,并借助ZooKeeper协调器来保障不同实例间的最终一致性[^2]。 ```sql CREATE TABLE replicated_table ON CLUSTER cluster_name ( ... ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/replicated_table', '{replica}') ORDER BY (...) PARTITION BY toYYYYMM(date_column); ``` #### 调整系统参数提升稳定性 适当调整一些影响事务处理性能的关键参数也有助于改善整体表现。例如增大`max_network_bytes_per_second`限制值可加快跨节点通信速度;延长`distributed_ddl_task_timeout`超时时间则能给予更多重试机会给那些暂时不可达的服务端点[^3]。 #### 实施应用层补偿措施 当上述方法仍无法彻底根治该类异常状况时,则需考虑从业务流程角度出发寻找替代方案。比如引入消息队列机制实现异步通知变更事件,或是定期执行全量校验修复潜在差异等手段均不失为可行之策。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值