Cassandra 4.0修复任务无错误日志却失败的排查求助
操作背景
在Cassandra 4.0环境中执行增量范围修复命令：
nodetool repair -tr -inc -st -1013347141143265728 -et -1000918482763387932 keyspace table_name
现象记录
- 命令执行后，控制台输出停滞在以下日志：
[2024-06-19 10:37:07,190] /10.0.40.8: Adding to parent_repair_history memtable
[2024-06-19 10:37:07,190] /10.0.40.8: Enqueuing WRITES.WRITE response to /10.0.40.8
[2024-06-19 10:37:07,190] /10.0.40.8: Sending WRITES.WRITE message to /10.0.40.14, size=26 bytes
- 一天后通过
repair_admin查看状态，任务显示为FAILED，控制台重复打印：
[After waiting for poll interval of 300 seconds] queried for parent session status and 2024-06-20 10:35:00,143 couldn't find repair status for cmd: 5
[After waiting for poll interval of 300 seconds] queried for parent session status and 2024-06-20 10:40:00,145 couldn't find repair status for cmd: 5
[After waiting for poll interval of 300 seconds] queried for parent session status and 2024-06-20 10:45:00,146 couldn't find repair status for cmd: 5
- 日志排查结果：
- 通过修复会话UUID（
85e6e5f0-2de4-11ef-b649-2b6780b7b939）检索system.log和debug.log，未发现ERROR级日志 - INFO日志显示反压缩已成功完成：
INFO [AntiCompactionExecutor:24] 2024-06-19 10:35:07,367 CompactionManager.java:739 - [repair #85e6e5f0-2de4-11ef-b649-2b6780b7b939] Completed anticompaction successfully
- 仅有的WARN日志：
WARN [OptionalTasks:1] 2024-06-20 10:42:53,804 LocalSessions.java:273 - Auto failing timed out repair session LocalSession{sessionID=85e6e5f0-2de4-11ef-b649-2b6780b7b939, state=PREPARED, coordinator=/10.0.40.14, tableIds=[5320ff80-8d59-11ec-a59e-7309d471ee5e], repairedAt=1718764499422, ranges=[(-1013347141143265728,-1000918482763387932]], participants=[/10.0.40.1, /10.0.40.14, /10.0.40.10], startedAt=1718764499, lastUpdate=1718764507}
疑问
当前的排查方式是否存在遗漏？该如何进一步调试修复失败的问题？
排查建议
1. 检查节点间通信状态
从WARN日志可知，修复会话因超时而被标记失败，且状态停留在PREPARED，说明协调节点（/10.0.40.14）与参与节点（/10.0.40.1、/10.0.40.10、/10.0.40.8）的通信可能出现阻塞或中断：
- 确认所有节点的防火墙/安全组规则，放行Cassandra内部通信端口（默认7000、7001）和JMX端口（默认7199）
- 执行
nodetool status检查集群状态，确保所有节点处于UN状态 - 用
nc -zv <节点IP> 7000测试节点间TCP连接是否正常
2. 调整修复超时配置
Cassandra 4.0的cassandra.yaml中，以下参数直接影响修复会话的执行：
repair_session_timeout_in_ms：修复会话整体超时时间，默认值可能无法覆盖大数据量/大范围的修复场景cross_node_timeout：跨节点请求超时时间，若节点间网络延迟高，需适当调大
3. 查询修复会话的元数据
通过系统表获取修复会话的详细执行记录，定位停滞环节：
SELECT * FROM system_distributed.parent_repair_history WHERE id = 85e6e5f0-2de4-11ef-b649-2b6780b7b939; SELECT * FROM system_distributed.repair_history WHERE parent_id = 85e6e5f0-2de4-11ef-b649-2b6780b7b939;
这些表会记录修复阶段、参与节点、进度等关键信息，可帮助判断是哪个环节出现异常
4. 检查协调节点资源状态
协调节点（/10.0.40.14）可能因资源耗尽导致会话挂起：
- 查看协调节点的CPU、内存、磁盘IO使用率，确认是否存在资源瓶颈
- 重新梳理协调节点
debug.log中与repair、LocalSessions相关的日志，重点关注会话超时前后的细节，可能存在未被grep匹配到的关键信息
5. 小范围修复验证
先执行极小范围的增量修复，验证基础修复流程是否正常：
nodetool repair -tr -inc -st <更小起始token> -et <更小结束token> keyspace table_name
如果小范围修复成功，说明原修复范围数据量过大，导致超时或资源不足，可拆分范围分批执行
内容的提问来源于stack exchange，提问作者cheeeeen
