Linux Cassandra修复工具：Repair 的原理、策略与调度实践

一、Repair 原理详解：反熵与 Merkle Tree

1.1 为什么需要 Repair？

Cassandra 最终一致性模型：

• 写操作：Coordinator 并行写RF副本，根据一致性级别ACK
• 故障场景：节点宕机 → Hinted Handoff临时存储（默认3小时）
• Hint超时或网络分区 → 副本间数据不一致

反熵机制（Anti-Entropy）：

• Repair：主动比较副本间数据差异，同步缺失/旧版本
• Read Repair：读时被动修复（概率默认10%）
• Hinted Handoff：临时修复

生产依赖：主动Repair是保证强一致性的必须操作。

1.2 Merkle Tree（默克尔树）原理

Repair核心数据结构：Merkle Tree（哈希树）

• 每个节点为范围（Token range）构建Merkle Tree
• 叶子节点：数据块哈希（默认每128行）
• 上层：子节点哈希组合
• 根哈希相同 → 数据一致；不同 → 递归比较子树 → 定位差异范围

优势：

• 差异检测高效（O(log n)）
• 传输最小差异数据

构建过程：

1. 每个副本节点独立构建树（内存开销，5.0 Trie优化降低）
2. 交换树，比较根哈希
3. 差异子树 → streaming同步

5.0优化：更深树层级，内存更省。

1.3 Repair 类型

• Full Repair：全范围重建Merkle树，同步所有差异（耗资源）
• Incremental Repair（4.0+推荐）：仅未repair部分，标记已repair SSTable（anticompaction避免风暴）
• Subrange Repair：指定Token范围
• Validation Repair：轻量，仅构建树不同步（诊断用）

二、Repair 策略与命令实战

2.1 nodetool repair 核心选项

基本命令：

nodetool repair [options] [keyspace] [table]

关键选项：

• -full：全量repair（慎用）
• -inc：增量repair（默认，推荐）
• -pr：Primary Range，仅修本节点主范围（并行安全，必加）
• -seq：Sequential，顺序修范围（与-pr结合，分批）
• -j：并行job数（默认1）
• -tr：Tracer概率
• -start-token / -end-token：子范围repair

生产推荐：

nodetool repair -pr -inc keyspace table   # 单表增量主范围
nodetool repair -pr -seq -inc             # 全集群顺序增量

2.2 策略对比

5.0变化：增量repair更高效，支持UCS anticompaction自动。

2.3 多DC Repair 注意

• 默认仅本DC
• 加-dc：指定DC
• 跨DC：网络带宽评估

三、Repair 调度实践

3.1 调度频率与窗口

• 小集群：每周full repair
• 中大型：每周增量repair + 每月full（或仅增量）
• 时间窗口：夜间低峰，结合Compaction限速

3.2 自动化调度脚本

Opscenter或自研脚本：

#!/bin/bash
# weekly_repair.sh

KEYSPACES="prod logs"

for ks in$KEYSPACES; do
    TABLES=$(cqlsh -e "DESC TABLES FROM $ks" | grep -v system)
for table in$TABLES; do
echo"Repairing $ks.$table"
        nodetool repair -pr -inc -seq $ks$table
done
done

crontab：

0 2 * * 0 /opt/scripts/weekly_repair.sh >> /var/log/cassandra_repair.log 2>&1

大集群：分批（nodetool -h host repair）

工具：Reaper for Cassandra（开源repair管理器，推荐）

• 自动分段、并行、安全暂停

3.3 Anticompaction 防控风暴

增量repair后：

• 标记已repair SSTable
• Compaction跳过已标记 → 避免立即合并风暴

监控：nodetool compactionstats

四、Repair 监控与诊断

4.1 Metrics

• cassandra_repair_*
• Pending/Completed/Successful

Grafana面板：Repair进度、失败率

4.2 日志

grep "Repair" /var/log/cassandra/system.log
# 关注：Merkle tree build time, differences found

4.3 验证一致性

工具：cassandra-consistency-checker 或读写对比测试

五、生产最佳实践与常见坑

1. 必加-pr：避免多节点重复修同一范围
2. 优先增量：full仅初始化或紧急
3. 分批调度：大集群>100节点，用Reaper
4. 结合备份：repair后snapshot
5. 多DC独立：每个DC单独调度

常见问题：

• Repair卡住 → Merkle树构建慢（大Partition） → 分区优化
• 网络风暴 → 未-seq → 加顺序
• 不一致未修复 → 漏表 → 脚本覆盖所有
• 内存高 → 树构建 → 调repair_session_space_in_mb