ZooKeeper 顺序节点计数器溢出导致 ClickHouse 复制表无法写入
复制表的每次 INSERT 和 merge 都在 ZooKeeper 的 log/ 下用掉一个 int32 序号。lab 上把计数器推到上限之后，INSERT 全报 Node exists，merge 失败，读照常；照原表建新表、把分区挂过去就能恢复写入。
最新文章
查看全部 →ClickHouse 交易明细系统的整体架构
交易明细从 Kafka 经托管 sink 写进三副本 ClickHouse，单日一千多万到三亿多行。现状是按结算日分区、至少一次写入、单分片三副本靠 Keeper；按键折叠、报表增量聚合加对账重算、整分区替换修数据在 lab 上验过，还没在现有集群上执行。
ClickHouse 误删表和分区之后的恢复
上游默认下，DROP TABLE 不加 SYNC 有 480 秒能 UNDROP，DETACH 可逆，DROP PARTITION 只靠 FREEZE 备份，删超过 50 GB 会被拦下。Aiven 上的现有集群里宽限期和大小保险都是 0，误删后只剩备份。
ClickHouse 的 Keeper 故障和 part 过多
写入变慢或被拒时，先看 Keeper 和 part 数。lab 上 Keeper 停掉时副本立刻只读，INSERT 卡约 143 秒才报错；卡住时客户端 30 秒超时，服务端在 Keeper 回来后照样提交。part 过多则先拖慢、后拒绝，中间那段是预警窗口。
ClickHouse 数字对不上的排查顺序
行数对得上、数字却不对，先查时间轴：UTC 16 点到 24 点之间的时刻，在 UTC 和上海两种列声明下会落进相邻两天的分区。再查 JOIN 有没有在右表重复键上放大，去重计数是不是近似的 uniq，上游有没有改字段名让整列变成默认值。
