上游默认下，DROP TABLE 不加 SYNC 有 480 秒能 UNDROP，DETACH 可逆，DROP PARTITION 只靠 FREEZE 备份，删超过 50 GB 会被拦下。Aiven 上的现有集群里宽限期和大小保险都是 0，误删后只剩备份。

行数对得上、数字却不对，先查时间轴：UTC 16 点到 24 点之间的时刻，在 UTC 和上海两种列声明下会落进相邻两天的分区。再查 JOIN 有没有在右表重复键上放大，去重计数是不是近似的 uniq，上游有没有改字段名让整列变成默认值。

数据少了不报错，常常很久之后才被发现。排查从上游和 Kafka 开始，再看 connector 的错误处理：默认配置下一条坏记录让 task 停住；配了 DLQ，同批同分区的好记录跟着进 DLQ；只开容错不配 DLQ，整批静默消失。

物化视图在插入时触发，看不到之后的合并，窗口外的重放、producer 重试和重发新版本都会让报表多算。按天和明细 FINAL 逐桶对账能找出偏了的天；重算一天要先过 part_log 的闸再换分区，否则会抹掉迟到写入。

明细表一直被 sink 写着，历史分区还会被补发。换引擎靠 ATTACH 把历史分区挂进新表，停 sink 排空后按 part_log 补齐，逐副本比行数过闸，再用 EXCHANGE 原子切换。lab 上 sink 只停了零点几秒，回滚后一行不丢。

Kafka 写进 ClickHouse 只能做到至少一次，三种重复都会落库。方案不开 sink 的 exactlyOnce，以 ReplacingMergeTree 按键折叠为主，入口调大去重窗口或改用异步插入，报表靠对账重算兜底，只在 lab 上验过。

按 _part、_part_offset 删掉重复的那份，带子查询的 DELETE 在复制表上先被拒；放开之后子查询跟着全表 part 数重复执行。加上 IN PARTITION 它反而最省，但同一秒写进来的两份按 create_time 分不开。

用 argMin 重建出事窗口再 REPLACE 的清理方案，在三副本 lab 里先报语法错；修好之后，列序错位、迟到写入、落后副本、只看一个节点的核对，以及换分区落到临时表还没复制到的副本，都能让数据坏掉或丢掉，行数校验照样通过。

Kafka 到 ClickHouse 的链路上，重复行能从 producer 重试、sink 超时重投、task 重启重放和人工补发四处进来。lab 实测 sink 的 exactlyOnce 挡得住重放，挡不住超时重投，打开后崩溃重启默认停在状态冲突上。

ClickHouse 没有 UPSERT，清掉已写进去的重复行，要从快照把一整天重建好、验过，再用 REPLACE PARTITION 整个换进去。R0 到 R8 的几道闸挡住副本落后、快照之后的写入和换分区落到没复制完的副本，回滚是反向再换一次。