Apache Cassandra 2.2.8跨DC提示传递超时问题求助

先明确下你的问题场景：两个数据中心经历数小时网络中断恢复后，DC1向DC2的Hinted Handoff（提示移交）频繁超时失败，从日志里能看到反复出现Operation timed out - received only 0 responses；但DC2向DC1的Hinted Handoff基本都能成功，只有极少失败。

先贴出你提供的关键日志片段方便参考：

DC1到DC2的失败日志 #

INFO [HintedHandoff:2] 2018-05-17 15:27:30,286 HintedHandOffManager.java:367 - Started hinted handoff for host: 3623ef5c-08c9-4614-be7a-3971cd3157fb with IP: /10.166.242.xx 
INFO [HintedHandoff:1] 2018-05-17 15:27:51,603 HintedHandOffManager.java:486 - Failed replaying hints to /10.166.242.30; aborting (80 delivered), error : Operation timed out - received only 0 responses. 
INFO [HintedHandoff:1] 2018-05-17 15:27:51,635 HintedHandOffManager.java:367 - Started hinted handoff for host: d229bbd4-b883-4d46-b273-dbabd8b78772 with IP: /10.166.242.xx 
INFO [HintedHandoff:1] 2018-05-17 15:28:56,194 HintedHandOffManager.java:486 - Failed replaying hints to /10.166.242.29; aborting (111 delivered), error : Operation timed out - received only 0 responses. 
...（后续重复的超时日志）

DC2到DC1的成功日志 #

INFO [HintedHandoff:1] 2018-05-17 15:09:11,082 HintedHandOffManager.java:367 - Started hinted handoff for host: e37d2fc9-71e8-4dbb-8a96-8215f7b31749 with IP: /10.166.18.XX 
INFO [HintedHandoff:2] 2018-05-17 15:09:11,082 HintedHandOffManager.java:367 - Started hinted handoff for host: e0078d7f-6189-4485-b78b-9274b159de81 with IP: /10.166.18.XX 
INFO [HintedHandoff:2] 2018-05-17 15:09:11,847 HintedHandOffManager.java:399 - Finished hinted handoff of 4 rows to endpoint /10.166.18.XX 
INFO [HintedHandoff:2] 2018-05-17 15:09:12,378 HintedHandOffManager.java:399 - Finished hinted handoff of 31 rows to endpoint /10.166.18.XX 
...（后续成功完成的日志）

接下来我给你梳理排查思路和解决办法：

一、优先排查单向网络问题 #

因为反向传输正常，单向的网络限制或瓶颈是最可能的原因，可以从这几点入手：

• 带宽饱和检查：网络恢复后，DC1会批量传输中断期间积压的hint数据，很可能把DC1到DC2的出向带宽占满，导致请求超时。你可以在DC1节点用iftop或者sar -n DEV 1查看实时流量，确认带宽使用率是否接近100%。
• 防火墙/安全组规则验证：检查DC1到DC2的Cassandra内部通信端口（默认7000，SSL用7001）是否有单向的限流、丢包或者会话超时设置。比如有些防火墙会对大流量连接做超时拦截，或者单向QoS限制了Cassandra的传输速率。
• 链路丢包测试：在DC1节点上用mtr 10.166.242.xx（替换成DC2的节点IP）做持续的链路测试，看中间节点是否有高延迟或丢包情况；也可以用ping -f 10.166.242.xx做批量ping，统计丢包率。

二、检查DC2节点的资源瓶颈 #

虽然DC2到DC1的传输正常，但DC2在接收DC1的hint时可能资源不足，导致无法及时响应：

• CPU与内存状态：用top查看DC2节点的CPU使用率，是否有进程占用大量资源；用nodetool tpstats查看Cassandra内部线程池的排队情况，尤其是hint相关的线程。另外，检查JVM GC日志，如果GC频繁（比如Full GC次数多），会导致节点停顿，无法处理请求。
• 磁盘IO负载：用iostat -x 1查看DC2节点的磁盘指标，重点看%util（磁盘使用率）和await（IO等待时间）。如果磁盘IO繁忙（比如同时在做压缩、修复），写入hint数据会变慢，进而导致DC1端超时。

三、调整Cassandra相关配置参数 #

如果网络和资源都没问题，可能是Hinted Handoff的配置不匹配：

• 调整传输速率：修改DC1节点cassandra.yaml中的hinted_handoff_throttle_in_kb参数，降低传输速率（比如从默认的1024改成512），避免给DC2造成太大压力。修改后需要重启节点生效，或者用nodetool sethintthrottle动态调整。
• 延长请求超时时间：调大DC1节点的request_timeout_in_ms参数（比如从10000改成30000），给DC2足够的时间处理hint请求。这个参数可以动态调整，用nodetool settimeout hintedhandoff 30000。
• 验证hint相关开关：确认DC2节点的hinted_handoff_enabled参数是true，并且max_hint_window_in_ms设置合理（虽然网络恢复后这个窗口已过，但如果积压hint过多，可能影响传输）。

四、手动干预Hinted Handoff #

如果自动重试一直失败，可以尝试手动触发：

• 先在DC1节点执行nodetool flush hints，把内存中的hint刷到磁盘，避免丢失；
• 然后用nodetool reloadhints重新加载hint文件；
• 如果之前hint被禁用，执行nodetool enablehints重新启用。

如果积压的hint数量极大，且部分旧hint已经过期，可以谨慎删除DC1节点data/hints目录下的旧hint文件（注意备份！），减少传输压力。

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