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

用 argMin 重写整个分区再去 REPLACE 的写法，在三副本 lab 里不仅报语法错，修好后列序错位、迟到写入和落后副本还能让数据坏掉而且行数校验照过。只能靠快照和 part_log 补救。

同一条 Kafka 到 ClickHouse 的链路上，重复行先后从生产端重试、sink 超时重投、task 重启重放和人工补发四处进来。官方 sink 的 exactlyOnce 按 offset 区间判断，挡得住重放，超时重投只挡一半，生产端和补发挡不住。

ClickHouse 没有 UPSERT，清掉重复行要把整个日分区重写一遍再原子换进去。runbook 本体只有五条 SQL，跑之前要验的更多：两张表会不会指到同一个 Keeper 路径、分区 ID 怎么加引号、三个副本同步没有、分区是不是静止的。

ReplicatedMergeTree 默认记住最近 1000 个插入块，重投的那批内容和 token 都没变，本该被认出来。这张表三个副本每秒建 124 个块，1000 个块折合 8 秒，而重投的间隔是 32 到 124 秒。

同一个业务键在 ClickHouse 里出现两行完全一样的数据，写入时间相差 30 秒到两分钟。前一天吞吐掉到常态零头的十几个小时一行重复都没有，出重复的是第二天吞吐看着正常、Keeper 在途请求涨到几千的那三个小时。

同事准备用 mutation 修复 ClickHouse 表里写坏了 18 天的一列，我在评审方案的同时用只读连接把表的现状摸了一遍，意见主要提在回滚上。