Cassandra 3.0.9集群nodetool repair过慢原因及提速方案咨询

首先可以明确：日志里的“Redistributing index summaries”确实会拖慢修复速度。这个操作是Cassandra在重新计算并分发SSTable的索引摘要（Index Summary），目的是优化后续读性能，但它会占用大量磁盘IO和CPU资源——尤其是你刚导入大量数据后，集群内会生成大量新SSTable，这个重分发过程会和repair线程争抢系统资源，直接导致修复进度放缓。

接下来分享几个能有效提升修复速度的实操方案，按优先级排序：

1. 优先使用增量修复（Incremental Repair） #

Cassandra 3.0已支持增量修复，它仅修复上次全量修复后发生变化的数据，效率远高于默认全量修复。执行命令：

nodetool repair -inc

注意：如果集群从未执行过全量修复，第一次需要先跑一次全量修复（nodetool repair），后续再用增量修复就能看到明显的速度提升。

2. 调整repair并行线程数 #

默认的4个repair线程对于18节点集群来说确实偏少，你可以通过两种方式调整：

• 临时调整：执行repair时添加-par参数指定并行数，例如：

  nodetool repair -par 8
  

  （建议根据节点CPU核心数调整，一般设为核心数的1/2到2/3，避免资源过载）
• 永久调整：修改cassandra.yaml中的concurrent_repair_threads参数，重启节点后生效。

3. 拆分修复范围，避免一次性全量修复 #

不要直接对整个集群所有keyspace/table执行repair，拆分任务能大幅降低单节点压力：

• 按keyspace/table拆分：

  nodetool repair -keyspace your_keyspace -table your_table
  

• 按token范围拆分：用-start-token和-end-token指定修复的token区间，把大任务拆成多个小任务分批执行。

4. 临时暂停索引摘要自动调整 #

既然“Redistributing index summaries”会抢占资源，你可以临时禁用这个自动调整，等修复完成后再恢复：

nodetool setindexsummaryresizeinterval 0

修复完成后，再设回默认值（例如60分钟）：

nodetool setindexsummaryresizeinterval 60

5. 错开节点修复时间，避免集群资源竞争 #

不要同时在18个节点上启动repair，分批次执行——比如先修3-4个节点，完成后再启动下一批。这样能避免集群整体IO/CPU被打满，反而能提升整体修复效率。

6. 先等待compaction完成再启动repair #

导入大量数据后，集群通常会有大量minor/major compaction在后台运行，compaction和repair都会争抢磁盘IO资源。你可以用nodetool compactionstats查看进度，等大部分compaction完成后再启动repair，能减少资源冲突。

最后提个小建议：Cassandra 3.0.9是较老的版本，社区已经修复了不少和repair相关的bug（比如增量修复的稳定性问题），如果业务允许，建议升级到3.0.x系列的最新补丁版本，能从根源上减少修复慢的问题。

内容的提问来源于stack exchange，提问作者T. Meyerink