用reaper修复600GB表花了37个小时

Question

我开始使用Reaper工具修复我们的Cassandra，修复过程非常缓慢。 我在 600GB 的表上测试了该工具，使用 Reaper 工具花了 37 小时完全修复该表。

我在三个数据中心有一个副本

我的配置

segmentCountPerNode: 16
repairParallelism: PARALLEL
repairIntensity: 0.9
scheduleDaysBetween: 7
repairRunThreadCount: 15
hangingRepairTimeoutMins: 30
storageType: cassandra
enableCrossOrigin: true
incrementalRepair: false
blacklistTwcsTables: true
enableDynamicSeedList: true
repairManagerSchedulingIntervalSeconds: 1
activateQueryLogger: false
jmxConnectionTimeoutInSeconds: 5
useAddressTranslator: false
maxParallelRepairs: 10

和 4 个修复线程

我在日志中看到以下消息，但我没有看到任何待处理的压缩或繁忙的节点

INFO   [2024-07-19 04:01:50,862] [cassandra-staging:f3ba9f10-4449-11ef-bbc3-c35808c06f7a] i.c.s.RepairRunner - All nodes are busy or have too many pending compactions for the remaining candidate segments.
INFO   [2024-07-19 04:01:50,866] [cassandra-staging:f3ba9f10-4449-11ef-bbc3-c35808c06f7a] i.c.s.RepairRunner - All nodes are busy or have too many pending compactions for the remaining candidate segments.
INFO   [2024-07-19 04:01:50,873] [cassandra-staging:f3ba9f10-4449-11ef-bbc3-c35808c06f7a] i.c.s.RepairRunner - Repair amount done 216.0

Answer 1

从您在问题中发布的详细信息中没有太多需要分析的内容来说明问题的原因。

您可以检查的一件事是是否有根据 Reaper 运行的修复，然后将它们与节点上正在进行的修复线程进行比较。如果节点上已经运行了其他修复线程（例如使用

nodetool repair

手动触发但尚未完成的线程，或其他原因），Reaper 启动另一次修复将受到限制。

顺便说明一下，1 秒的调度间隔对后端来说可能过于激进，因为它会不断请求修复段列表，因此您可能需要考虑更长的 10 秒间隔。干杯！