Cassandra Hinted Handoff完成时长预测及持续运行异常问询

答案是可以大致估算，但没法做到绝对精准——毕竟这个过程受一堆配置和集群实时状态的影响。下面我给你拆解怎么操作，还有为什么它会一直跑个不停：

一、先凑齐关键数据 #

要估算的话，首先得拿到两个核心信息：

• 待同步的Hint总数据量：
  • 你可以用nodetool tablestats查看每个表的Pending Hints数值，部分Cassandra版本支持nodetool hintstats，能直接看到总hint大小、待处理数量这些更细的统计。
  • 最直观的方式是去节点的hint存储目录（默认是data/hints），用du -sh data/hints命令直接看总占用空间，这就是你要同步的总数据量。
• 当前的同步速率：
  • 多跑几次nodetool statushandoff或者nodetool hintstats，记录不同时间点的剩余hint数量/大小，算个平均速率。比如第一次看剩100GB，10分钟后剩90GB，那大概就是1GB/分钟的速度。
  • 也可以翻Cassandra的系统日志（默认在logs/system.log），里面会有类似Processed X hints in Y milliseconds的日志，用这个能算出瞬时的处理速率。

二、结合配置算理论上限 #

Cassandra的几个配置会直接限制hint同步的速度，都在cassandra.yaml里：

• hinted_handoff_throttle_in_kb：单个节点同步hint的带宽上限，默认是1024KB/s（也就是1MB/s）。注意这是单节点的速率，如果有好几个节点要往恢复的节点同步hint，总速率会被这个值卡着。
• max_hints_delivery_threads：处理hint投递的线程数，默认是2。线程越多理论上速度越快，但也要看集群的IO和网络扛不扛得住。
• 先确认hinted_handoff_enabled是true（默认就是），还有hinted_handoff_disabled_datacenters没把当前数据中心排除在外。

理论上的最大速率可以这么算：(hinted_handoff_throttle_in_kb * 1024) * max_hints_delivery_threads，但实际速率肯定比这个低——毕竟还要考虑网络延迟、目标节点的IO负载（比如它正在做compaction或者处理其他读写请求）。

三、为啥它一直在运行？ #

如果发现hint同步没完没了，大概率是这几个原因：

• 新Hint一直在生成：要是集群里还有其他节点在往这个刚恢复的节点写数据，但之前这个节点不可达，那新的hint会不断被加进来，同步自然永远做不完。你可以用nodetool statushandoff看Pending数量是不是一直在涨，或者看日志里的hint生成记录。
• 目标节点负载太高：刚恢复的节点如果IO或者CPU占满了，hint写入速度会慢到离谱，甚至暂停。用nodetool tpstats看看HintedHandoff线程池的待处理任务，或者用iostat、top查节点的资源使用情况就知道了。
• Hint文件损坏：极少数情况，hint文件坏了，Cassandra处理不了，就会卡在这里。去日志里搜搜有没有Corrupted hint file这类错误信息。
• 大量过期Hint在清理：Cassandra会自动删掉超过max_hint_window_in_ms（默认3小时）的hint，如果有一堆过期hint在清理，也会让进程看起来一直在跑。看看日志里的hint清理记录就能确认。

四、估算的小提醒 #

• 估算结果只能当参考，集群的负载、网络状况随时可能变——比如突然来个大读写请求，同步速率立马就降下来了。
• 如果是跨数据中心的hint同步，还要考虑跨DC的带宽和延迟，速度会比同DC慢很多。
• 你可以临时调大hinted_handoff_throttle_in_kb来加快同步，但别调太猛，避免影响正常业务读写，把目标节点压垮了。

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