如何限制Apache Cassandra 3.11修复时的验证压缩并发数

一、直接限制验证压缩并发数的配置调整 #

Cassandra的验证压缩（Validation Compaction）并发数由核心参数控制，可通过两种方式调整：

• 修改cassandra.yaml配置文件中的concurrent_validations参数，将其设置为更低的值（比如2或3），该参数直接控制同时运行的验证压缩任务数量。修改后需逐节点滚动重启集群，避免影响可用性。
• 无需重启的动态调整：执行命令 nodetool setconcurrentvalidations <num>，比如 nodetool setconcurrentvalidations 2，可即时生效限制并发数。

二、修复过程的额外优化（配合现有参数） #

在已使用-pr（仅修复本节点数据）、-seq（串行修复）的基础上，补充以下调整：

• 按keyspace分批次修复：不要一次性触发所有表的修复，每次仅修复单个keyspace下的表，进一步降低单节点负载。
• 调整修复线程数：执行 nodetool setrepairthreadcount <num> 降低修复线程数（默认值为1，若之前调高过可改回1）。
• 错峰执行修复：将修复任务安排在业务低峰时段（如凌晨），减少对核心业务的影响。

三、Reaper过渡期间的临时缓解方案 #

在部署Reaper工具前，可通过以下临时方案缓解负载：

• 手动串行修复：编写简单shell脚本，循环遍历所有表，逐个执行 nodetool repair -pr -full -seq <keyspace> <table>，等待当前表修复完成后再启动下一个。
• 改用增量修复：去掉-full参数执行增量修复（Cassandra 2.1+支持），首次增量修复仍为全量，后续仅修复上次修复后变更的数据，触发的验证压缩任务会大幅减少。
• 监控并控制压缩队列：用 nodetool compactionstats 实时查看验证压缩队列长度，若队列过长，执行 nodetool stoprepair 暂停当前修复，待队列清空后再继续。

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