如何解决Cassandra中Bytes unrepaired未修复字节数持续增长问题

你的操作主要存在以下几个核心问题，导致Bytes unrepaired数值没有预期下降：

1. 滥用全量修复（--full参数） #

每天执行nodetool repair --full是完全错误的操作逻辑：

• --full会强制重新扫描并修复集群中所有数据，而非仅修复上次修复后新增的未同步数据。
• 修复过程中，集群的写入操作会持续产生新的未修复数据，全量修复的耗时通常远长于新数据生成的速度，导致未修复字节数始终无法清零，甚至因为修复开销引发的写入延迟，让未修复数据积累更多。

2. 每个节点单独执行局部修复（-pr）的错误方式 #

-pr（Partial Repair）仅修复当前节点负责的Token范围数据，但每个节点都单独执行-pr修复会导致：

• 修复工作在集群内重复执行，浪费资源。
• 无法保证跨节点的副本数据同步完成，因为局部修复仅处理当前节点的范围，其他节点的副本未被同步标记为已修复，最终导致Percent repaired始终显示为0.0。

3. 修复任务可能未完整执行 #

检查每个节点的Cassandra修复日志（默认路径/var/log/cassandra/repair.log），确认修复任务是否存在中途失败、超时或被中断的情况：

• 如果修复未完整完成，已修复的数据范围不会被标记，Bytes unrepaired自然不会减少。

4. 频繁写入/TTL操作的影响 #

如果这些表存在大量写入、更新或TTL过期数据：

• 新写入的数据会被自动标记为未修复，若修复速度赶不上新数据生成速度，未修复字节数会维持甚至增加。
• TTL过期的数据在被清理（compaction）前，也会被计入未修复字节数统计。

5. Cassandra 4.0.5的已知修复模块bug #

Cassandra 4.0.x早期版本存在修复状态跟踪异常、全量修复后未更新修复标记等已知问题，这些bug会导致修复结果无法被正确统计。

修正操作建议 #

• 停止每日全量修复：先执行一次完整的全量修复（仅执行一次），之后每日执行增量修复，且仅在集群中的一个节点执行：

  # 首次全量修复（仅执行一次）
  nodetool repair --full <keyspace>
  # 后续每日增量修复（仅在一个节点执行）
  nodetool repair -pr <keyspace>
  

• 检查修复日志，确保每次修复任务都完整执行，无报错或中断。
• 对写入量极大的表，可分表执行修复，或调整修复频率，避免影响业务写入。
• 考虑升级到Cassandra 4.0系列的最新稳定版本（如4.0.11及以上），修复已知的修复模块缺陷。

内容的提问来源于stack exchange，提问作者Коля Курик