Cassandra节点频繁宕机及读数据超时技术问题问询

从你描述的情况（节点/XX.XX.XX.XX频繁被标记为DOWN，同时查询超时），结合提供的调试日志来看，核心问题是节点间Gossip通信异常，伴随连接握手失败，进而引发集群不稳定，最终导致查询超时。下面是具体的分析和解决步骤：

关键日志解读 #

先把你提供的核心日志贴出来，方便对应分析：

DEBUG [GossipTasks:1] 2019-11-29 00:21:05,940 Gossiper.java:353 - Convicting /XX.XX.XX.XX with status NORMAL - alive true
INFO [GossipTasks:1] 2019-11-29 00:21:05,941 Gossiper.java:1034 - InetAddress /XX.XX.XX.XX is now DOWN
DEBUG [GossipTasks:1] 2019-11-29 00:21:05,941 OutboundTcpConnection.java:205 - Enqueuing socket close for /XX.XX.XX.XX
DEBUG [MessagingService-Outgoing-/XX.XX.XX.XX-Gossip] 2019-11-29 00:21:08,942 OutboundTcpConnection.java:425 - Attempting to connect to /XX.XX.XX.XX
INFO [HANDSHAKE-/XX.XX.XX.XX] 2019-11-29 00:21:08,943 OutboundTcpConnection.java:561 - Handshaking version with /XX.XX.XX.XX
INFO [HANDSHAKE-/XX.XX.XX.XX] 2019-11-29 00:21:13,943 OutboundTcpConnection.java:570 - Cannot handshake version with /XX.XX.XX.XX

这里几个关键点：

• 节点被集群判定为DOWN，触发连接关闭
• 尝试重连时出现版本握手失败，这是一个重要信号
• 连接反复断开、重连，导致集群Gossip协议无法正常同步节点状态

可能的原因及修复步骤 #

1. 网络连通性问题（最常见） #

Cassandra节点之间依赖Gossip协议（默认端口7000）、数据传输端口（7001如果启用SSL）以及JMX端口通信，任何端口被拦截都会导致通信失败：

• 检查/XX.XX.XX.XX节点的防火墙/安全组规则，确保集群内所有节点能访问上述端口
• 用telnet XX.XX.XX.XX 7000或nc -zv XX.XX.XX.XX 7000测试端口连通性，确认没有丢包或延迟过高
• 如果是云环境，检查是否存在网络分区、子网隔离或者带宽限制

2. Cassandra版本不一致 #

日志里的Cannot handshake version直接提示版本不匹配问题：

• 确认集群内所有节点的Cassandra版本完全一致（包括小版本），版本差异会导致节点间无法正常握手通信
• 如果是刚加入的节点，检查其安装包版本是否和集群一致，不一致的话重新安装对应版本

3. 节点资源耗尽 #

节点内存、CPU或磁盘资源耗尽会导致其无法响应Gossip请求，被集群标记为DOWN：

• 内存检查：执行nodetool info查看堆内存使用，或者free -m看系统内存。如果堆内存不足，调整jvm.options里的-Xms和-Xmx参数（推荐为系统内存的50%，最大不超过32GB）
• CPU检查：用top查看CPU使用率，如果持续100%，排查是否有其他进程占用资源，或者调整Cassandra的并发参数（比如concurrent_reads、concurrent_writes）
• 磁盘检查：用df -h确认磁盘空间充足，iostat -x查看IO负载，磁盘IO瓶颈会导致请求超时，建议使用SSD存储

4. Gossip配置不合理 #

如果网络环境较差，默认的Gossip参数可能不适用：

• 打开cassandra.yaml，调整gossip_timeout（默认3000ms）为更大的值，比如5000ms，给节点更多响应时间
• 检查listen_address和rpc_address配置，确保节点绑定的是集群内可访问的IP，而不是127.0.0.1

5. 临时应急处理（如果节点持续影响集群） #

如果该节点反复宕机导致集群不稳定，可以先将其移出集群：

• 如果节点还能响应，在该节点执行nodetool decommission，让它安全退出集群
• 如果节点完全不可用，在其他正常节点执行nodetool removenode <节点ID>（节点ID可以通过nodetool status获取）
• 修复节点问题后，再重新加入集群

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