Cassandra集群全量修复后Reaper仍失败及修复任务积压原因问询

问题1：执行完全量修复后Reaper仍运行失败的原因 #

• 全量修复仅解决了当时的集群数据不一致问题，未触达底层的版本兼容、资源瓶颈、配置不合理等根因，所以运行数日后问题复现：
  • 你使用的Cassandra 3.11.0版本存在大量已知的修复逻辑bug，包括修复会话异常终止、线程泄漏、校验阶段超时等问题，本身就会导致定期触发的Reaper修复随机失败。你日志中出现的Terminate session is called报错，就是该版本下修复会话超时后被服务端主动终止的典型表现。
  • 全量修复执行过程中会生成大量新的SSTable，你执行nodetool compactionstats也能看到有4个待压缩任务，压缩任务会占用大量磁盘IO和CPU资源，Reaper后续触发修复时，校验、数据同步步骤无法分配到足够资源，就会出现连接超时、任务执行失败的问题。
  • Reaper 2.2.3默认的修复配置和18节点的集群规模不匹配：如果修复段配置过大、并行修复段数量超过集群承载上限、会话超时阈值设置过短，都会导致修复任务还没跑完就被强制终止。
  • 日志中出现的9042端口连接超时报错，说明集群节点之间存在网络波动、防火墙限流的问题，跨节点的修复请求无法正常交互也会直接导致任务失败。

问题2：修复任务积压的根本原因 #

• 修复线程池资源耗尽：从nodetool tpstats的结果可以看到Repair#18线程池的活跃任务已经占满，后续提交的修复任务只能进入pending队列。Reaper默认的并行修复任务数如果配置过高，很容易打满集群的修复线程池。
• 任务执行速度跟不上调度速度：大表修复、IO资源被压缩占用都会拉长单任务的执行时长，如果Reaper配置的修复调度间隔太短，上一轮修复还没执行完成，下一轮任务就已经提交，会导致队列的任务越积越多。
• 失败任务残留占用资源：Cassandra 3.11.0版本下异常终止的修复会话不会自动释放线程资源，Reaper如果没有开启失败会话自动清理的配置，残留的会话会一直占着线程池，新的任务无法执行，只能排队积压。

临时解决&优化建议 #

• 先执行nodetool repair -cancel all终止所有当前运行的修复任务，等待待处理的压缩任务全部跑完后，再重新触发Reaper修复，可快速解决当前的任务积压问题。
• 将Cassandra版本升级至3.11.11及以上的稳定版，修复已知的修复逻辑bug；调整Reaper配置：把修复超时时间延长到30分钟以上，调小单修复段的大小，并行修复段数量设置为集群节点数的1/3，避免同时提交过多任务。
• 排查集群节点之间的网络连通性，确保7000（内部通信）、9042（CQL）端口没有被防火墙拦截、没有跨可用区的高延迟问题。

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