/tags/clickhouse-keeper/ Recent content in ClickHouse Keeper on Hugo -- gohugo.io en Sun, 11 Oct 2026 09:30:00 +0800 /posts/clickhouse-keeper-outage-too-many-parts/ Sun, 11 Oct 2026 09:30:00 +0800 /posts/clickhouse-keeper-outage-too-many-parts/ 背景 复制表的写入要经过两样东西：Keeper 负责领块号、去重和复制日志，merge 负责把每次写入产生的小 part 合掉（写入路径那篇）。这篇看这两样出问题时，写入是什么表现、有什么前兆、平时盯什么。 现有集群上见过的前兆在 Keeper 上。写出重复行的那三个小时里，Keeper 的在途请求从常态的 5 到 15 涨到几千，副本只读只闪了两下，用瞬时采样根本看不到（超时重投那篇）。这套集群托管在 Aiven 上，每个节点同机跑一个 ZooKeeper，只在集群内可达，运维碰不到这一层。 还有第三种会让写入被拒的情形，和 Keeper、part 都无关：Aiven 在 profile 里锁了每个节点的并发查询数，A、B、C 三档部署分别是 100、375、200（档位见架构那篇），INSERT 也算在里面，超出时直接报 Code: 202 TOO_MANY_SIMULTANEOUS_QUERIES，查询里改设置也绕不过去。 下面的现象来自 clickhouse-lab 的实验 11、12（25.3.14.14，三副本加一个单节点 Keeper），Keeper 的故障是把容器停掉或冻住造出来的。现有集群每个节点跑的是 ZooKeeper，lab 是 ClickHouse Keeper；冻住之后约 10 秒才转只读，这 10 秒来自 ClickHouse 这一侧 ZooKeeper 客户端的 operation_timeout_ms（默认 10000，现有集群改没改看不到），两种服务端之间的差别 lab 没测。 Keeper 停掉和卡住，表现不一样 实验 12 分别把 Keeper 容器停掉（docker stop，进程没了、连接当场断开）和冻住（docker pause，进程卡住、连接还在）： 观测项 停掉 冻住 副本转只读 立刻，第一次轮询就已经是只读 约 10 秒后，要等发出去的 Keeper 请求超时 期间的 SELECT 照常返回，读不碰 Keeper 同左 期间的 INSERT 重试到上限后报 Code: 242 TABLE_IS_READ_ONLY，默认参数下卡了约 143 秒 客户端 30 秒超时断开；Keeper 一回来，服务端那条 INSERT 照常提交 Keeper 回来之后 2 到 12 秒内自己退出只读，被拒的那几条不会补写 同左；晚到提交的那条已经在表里 INSERT 卡约 143 秒是默认的重试参数决定的：insert_keeper_max_retries = 20，每次失败后的等待从 100 ms 翻倍、封顶 10 秒，加起来 142.