Linux Cassandra修复工具：Repair 的原理、策略与调度实践
一、Repair 原理详解：反熵与 Merkle Tree
1.1 为什么需要 Repair？
Cassandra 最终一致性模型：
- 写操作：Coordinator 并行写RF副本，根据一致性级别ACK
- 故障场景：节点宕机 → Hinted Handoff临时存储（默认3小时）
反熵机制（Anti-Entropy）：
- Repair：主动比较副本间数据差异，同步缺失/旧版本
- Read Repair：读时被动修复（概率默认10%）
生产依赖：主动Repair是保证强一致性的必须操作。
1.2 Merkle Tree（默克尔树）原理
Repair核心数据结构：Merkle Tree（哈希树）
- 每个节点为范围（Token range）构建Merkle Tree
- 根哈希相同 → 数据一致；不同 → 递归比较子树 → 定位差异范围
优势：
构建过程：
- 每个副本节点独立构建树（内存开销，5.0 Trie优化降低）
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]
关键选项：
- -pr：Primary Range，仅修本节点主范围（并行安全，必加）
- -seq：Sequential，顺序修范围（与-pr结合，分批）
- -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 注意
三、Repair 调度实践
3.1 调度频率与窗口
- 中大型：每周增量repair + 每月full（或仅增量）
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后：
- Compaction跳过已标记 → 避免立即合并风暴
监控：nodetool compactionstats
四、Repair 监控与诊断
4.1 Metrics
- 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 或读写对比测试
五、生产最佳实践与常见坑
常见问题：
- Repair卡住 → Merkle树构建慢（大Partition） → 分区优化
- 内存高 → 树构建 → 调repair_session_space_in_mb
