type
status
date
slug
summary
tags
category
icon
password
AI 摘要
故事的开始是Clickhouse这小子在执行创表操作的时候报了个这个错误
task_queue/ddl/query-0001709703 is not finished on 1 of 3 hosts (0 of them are currently executing the task, 0 are inactive). They are going to execute the query in background. Was waiting for 180.346783536 seconds, which is longer than distributed_ddl_task_timeout
你看之前得给你说明一下嗷，如果你也遇到了这个错误也许下面介绍的参数是治标不治本的，可以优先考虑看看各个表中有没有有问题的partition，实在没办法了再考虑使用这个参数作为一个临时解决方案，我这儿纯粹是为了记录一下这个参数。
问题来源
先来介绍一下为啥会提到这个参数，咱都知道Clickhouse一般都拿来存日志、监控啥的。考虑到每个组织设置的数据保留时间（TTL）可能不一样，所以我呢给平台的组织做了分表的操作，每个表都能自己设置TTL时间。这个方案呢之前有人已经在做了，但是做了一半，所以线上会有一些已经创建过的表。当然这个表是分布式表引擎是
ReplicaMergeTree，执行DDL操作的时候会带上 on {cluster} 。监控数据是从kafka消费过来的，而当它准备往Clickhouse写入的时候就会去判断一下缓存中查一下有没有对应组织的表，如果没有则会执行创表操作。
这时候问题就来了，Kafka的消费端跑了几分钟就会出现不消费的情况，观察了几次日志发现每次想要执行CREATE TABLE操作的时候就会报错
...waiting for 180.346783536 seconds, which is longer than distributed_ddl_task_timeout ，并且Kafka就不消费了。问题排查
那很显然问题就是出在创表这个阶段，我和我的师兄根据这个提示错误查了好久好久，问过GPT也问过DEEPSEEK，有说是网络不通的、有说是IO速度不足的、有说是Zookeeper同步不过来的……各种问题我们都照着去查了一下发现一点问题都没有，因为处理这块问题已经耗时比较久了，于是想到了2两个零时解决方案：
- 在创表的时候如果卡住了，就写入到一个不带组织的全局表中，避免卡住主流程，属于一个降级方案
- 设置
distributed_ddl_output_mode参数为throw_only_active。
参数介绍
当然最后还是把这个问题彻底解决了，没有用到这两个方案，但是排查问题的过程中遇到了这个参数感觉未来可能还挺有用的所以给它记一下，没错
distributed_ddl_output_mode 就是我这次要介绍的参数。我最初碰到这个参数是在这里，它也遇到了和我差不多的错误。看了一下官方文档
给它翻译一下就是
distributed_ddl_output_mode
类型： DistributedDDLOutputMode
默认值：抛出
设置分布式 DDL 查询结果的格式。
可能的值
throw - 返回查询已完成的所有主机的结果集及查询执行状态。如果在某些主机上查询失败，则会重新抛出第一个异常。如果在某些主机上查询尚未完成，且超过了
distributed_ddl_task_timeout，则会抛出 TIMEOUT_EXCEEDED 异常。
none - 与 throw 类似，但分布式 DDL 查询不返回结果集。
null_status_on_timeout - 如果查询未在相应主机上完成，则在结果集的某些行中返回 NULL 作为执行状态，而不是抛出 TIMEOUT_EXCEEDED。
never_throw - 如果在某些主机上查询失败，不抛出 TIMEOUT_EXCEEDED，也不重新抛出异常。
none_only_active - 与 none 类似，但不等待复制数据库的非活动副本。注意：在这种模式下，不可能发现查询未在某些副本上执行，查询将在后台执行。
null_status_on_timeout_only_active - 与 null_status_on_timeout 类似，但不等待复制数据库的非活动副本
throw_only_active - 与 throw 类似，但不等待复制数据库的非活动副本。刚刚有提到我设置的参数是throw_only_active，那是因为我怀疑它总是卡在某一个Clickhouse实例上，那么我把这个实例的创表进度忽略只关心可以执行的实例。