ClickHouse 日志显示未压缩文件的哈希值不匹配

Posted 2023-03-25

【中文标题】ClickHouse 日志显示未压缩文件的哈希值不匹配

【英文标题】：ClickHouse log shows hash of uncompressed files doesn't match

【发布时间】：2021-01-08 04:01:56

【问题描述】：

ClickHouse 日志经常打印如下错误信息：

2021.01.07 00:55:24.112567 [ 6418 ]  <Error> vms.analysis_data (7056dab3-3677-455b-a07a-4d16904479b4): 
Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: 
hash of uncompressed files doesn't match (version 20.11.4.13 (official build)). 
Data after merge is not byte-identical to data on another replicas. There could be several reasons: 
1. Using newer version of compression library after server update. 
2. Using another compression method. 
3. Non-deterministic compression algorithm (highly unlikely). 
4. Non-deterministic merge algorithm due to logical error in code. 
5. Data corruption in memory due to bug in code. 
6. Data corruption in memory due to hardware issue. 
7. Manual modification of source data after server startup. 
8. Manual modification of checksums stored in ZooKeeper. 
9. Part format related settings like 'enable_mixed_granularity_parts' are different on different replicas. 
We will download merged part from replica to force byte-identical result.

我们对生产环境中的所有数据节点使用相同的版本（20.11.4.13）和相同的压缩方法（LZ4），我们也不会修改数据文件或存储在 Zookeeper 中的值。

所以我的问题是：

错误是如何引起的？此外，CickHouse 服务器在哪些情况下会抛出这些异常？ 在合并部分时，副本之间是否有校验和检查机制？ 我还发现，在我们的一个数据节点中，分离的文件夹中有很多名为“ignored_20201208_23116_23116_0”的文件夹，这些文件是不是引用的问题导致的数据损坏？

谢谢。

【参考方案1】：

您需要尽快将所有节点升级到 20.11.6.6。

这些错误的原因是与 AIO 相关的严重错误。

---

ignored_ -- 不相关。您可以删除它们。

gtranslate: 非活动部分不会立即删除，因为在写入新部分时，不会调用 fsync，即在一段时间内，新部分仅在服务器的 RAM（OS 缓存）中。因此，当服务器自发重启时，新的（合并的）部分可能会丢失或损坏。在这种情况下，ClickHouse 在启动过程中会检查部件的完整性，如果检测到问题，它将不活动的块返回到活动列表中，然后再次合并它们。在这种情况下，损坏的部分被重命名（添加了前缀 broken_）并移动到分离的文件夹中。如果完整性检查在合并的部分中没有检测到问题，则将原来的非活动块重命名（添加前缀忽略_）并移动到分离的文件夹。

【讨论】：

使用ReplicatedMergeTree，当其中一个replica准备合并新插入的part时，如何保持part的一致性？通知其他副本由 Zookeeper 单独执行相同的合并操作？非常感谢。

多个副本可以同时成为leader。使用merge_tree 设置replicated_can_become_leader 可以防止副本成为领导者。领导者负责安排后台合并。