Cassandra特定节点上无法修复特定表问题求助

针对你在5节点Cassandra 3.10数据中心遇到的user_tmp表修复卡顿/失败问题，结合你提供的表统计信息，我整理了几个实战中有效的排查和解决方向：

1. 优先清理无用快照，释放资源 #

从你给出的信息看，这个表的快照占用了216.87 MiB空间——快照会在repair过程中被用来做数据对比，过多或过旧的快照会额外消耗IO和内存资源，尤其是对于近200万条记录的表来说，这很可能是修复变慢的元凶：

• 先查看快照详情：执行 nodetool listsnapshots -t user_tmp，确认每个快照的创建时间和用途（比如是否是备份遗留的）。
• 清理不需要的快照：如果是旧的、无保留价值的快照，用 nodetool clearsnapshot -t <快照名称> user_tmp 精准删除；如果所有快照都没用，直接执行 nodetool clearsnapshot user_tmp 清理全部。

2. 合并SSTable，降低修复扫描成本 #

虽然你的user_tmp表只有4个SSTable，但合并操作可以减少repair时需要扫描的数据块数量，提升效率：

• 手动触发minor compaction：执行 nodetool compact -t user_tmp，这个操作会合并当前的SSTable（注意不要在业务高峰期执行，会占用IO）。
• 检查压缩策略：执行 DESCRIBE TABLE user_tmp; 查看表的压缩配置，Cassandra 3.10默认是LZ4，如果是Deflate这类高压缩比但高CPU开销的策略，可以考虑换成LZ4，减少repair时的CPU消耗。

3. 调整repair执行策略，避免资源过载 #

你当前的每日-pr、每周-full的策略没问题，但对于大表来说，full repair很容易一次性占满节点资源，建议拆分执行：

• 分token范围修复：把集群的token范围拆分成几个小部分，分批次执行full repair，比如：

  nodetool repair -full -st <起始token值> -et <结束token值> user_tmp
  

  你可以用 nodetool ring 获取集群的token范围，均匀拆分后逐个执行，避免一次性处理所有数据。
• 限制repair并行度：修改cassandra.yaml中的repair_threads参数（默认是1），如果节点CPU和IO充足，可以适当调高到2-4（不要超过节点核心数的一半），减少单节点repair的时间。

4. 排查节点内存与IO瓶颈 #

repair过程对内存和IO的要求很高，这两个资源不足会直接导致修复卡顿：

• 检查堆内存：执行 nodetool info 查看Heap Memory Usage，如果堆内存使用率接近上限（比如超过80%），会引发频繁GC拖慢修复。可以临时调整JVM堆内存（Cassandra 3.10建议堆内存不超过8G），或者开启GC日志排查是否有长时间停顿。
• 监控磁盘IO：用 iostat -x 1 观察repair期间的磁盘读写负载，如果%util接近100%，说明磁盘成为瓶颈，建议在业务低峰期执行repair，或者考虑升级存储介质（比如机械盘换SSD）。

5. 检查表数据完整性 #

如果以上操作都无效，可能是表的SSTable存在隐性损坏：

• 执行 nodetool scrub user_tmp，这个命令会检查SSTable的完整性，修复损坏的索引或数据块，同时清理无效数据。注意scrub会占用较多资源，务必在低峰期执行。
• 确认数据分布：用 nodetool tablestats user_tmp 对比各节点的Space used (live)，如果某个节点的数据量远大于其他节点，说明数据分布不均，会导致该节点repair时间过长，可以考虑调整表的复制策略或手动触发数据均衡。

内容的提问来源于stack exchange，提问作者iMajna