/tags/replicatedmergetree/ Recent content in ReplicatedMergeTree on Hugo -- gohugo.io en Wed, 16 Sep 2026 20:00:00 +0800 /posts/clickhouse-block-dedup-window/ Wed, 16 Sep 2026 20:00:00 +0800 /posts/clickhouse-block-dedup-window/ 一条 Kafka Connect sink 往 ReplicatedMergeTree 写数据，INSERT 卡过 30 秒超时之后框架把同一批原样重投，服务端两次都提交了，表里就多出 234 行逐字节相同的数据（这条链路怎么走到重投，写在ClickHouse 里的重复行来自 Kafka Connect 超时重投）。 ReplicatedMergeTree 自带块级去重（block-level deduplication），服务端记住最近若干个插入块的标识（有 token 用 token，没有就用块哈希），重复的块直接跳过。这张表本来就是 Replicated，这层默认是开着的；重投出去的记录、顺序、边界和第一次一模一样，插件给 INSERT 带的 insert_deduplication_token 也没变。认得出来的条件都在，它还是没拦住。原因在于这个窗口按块数算，而这张表建块太快。 窗口按块数算，默认 1000 个块 查一下生效值： SELECT name, value FROM system.merge_tree_settings WHERE name LIKE '%dedup%' replicated_deduplication_window 1000 replicated_deduplication_window_seconds 604800 窗口是 1000 个块，_seconds 是一周。这两个值没人改过，就是 25.9 之前的上游默认值。上游后来把两个都动了：25.9 起 replicated_deduplication_window 从 1000 提到 10000（PR #86820），25.10 起 replicated_deduplication_window_seconds 从一周改成一小时（PR #87414，标了 backward incompatible）。这套生产跑的是 25.3，查出来的 1000 和一周就是这个版本的原厂默认值。 提窗口那个 PR 底下，作者 CheSema 遇到的情况和这篇接近。「I faced several cases when retries run out of deduplication window.