Cassandra 3.0三节点集群单节点不同步问题及告警日志求助

问题根因分析 #

从告警日志和节点状态信息能明确看出核心问题：

• 异常节点/10.x.x.149的gossip generation值1695958421对应2023年的时间，而集群其他节点的时间是2020年（local time = 1585157692），系统时间严重不一致直接导致gossip协议无法正常工作。
• Cassandra用generation（节点启动时基于系统时间生成的标识）判断节点状态新鲜度，当收到的generation远大于本地时间时，会判定为无效并拒绝同步。
• 另外/10.x.x.150的generation为0、heartbeat为0，说明该节点状态异常，大概率也是时间同步问题或服务故障导致。

分步解决方案 #

1. 全集群同步系统时间

时间不一致是所有问题的源头，必须优先解决：

• 在所有节点上检查NTP服务状态：

  # systemd系统用timedatectl检查同步状态
  timedatectl status
  # 或用ntpq查看NTP服务器连接情况
  ntpq -p
  

• 如果NTP未运行或同步失败，手动强制同步时间：

  # 针对chronyd服务
  chronyc makestep
  # 针对ntpd服务
  ntpd -qg
  

• 确保所有节点时间误差控制在几秒内，之后设置NTP服务开机自启，避免再次出现时间漂移。

2. 修复异常节点/10.x.x.149

该节点的generation值异常，需要重置gossip状态：

1. 先停止该节点的Cassandra服务，避免数据不一致：

   # 执行drain停止写入，确保数据flush到磁盘
   nodetool drain
   # 停止服务（根据系统管理方式调整，sysvinit用service cassandra stop）
   systemctl stop cassandra
   

2. 删除该节点的gossip数据目录（默认路径，根据实际部署调整）：

   rm -rf /var/lib/cassandra/data/system/gossip/*
   

3. 重启Cassandra服务：

   systemctl start cassandra
   

   重启后节点会基于同步后的系统时间重新生成正确的generation值。

3. 修复节点/10.x.x.150

该节点状态异常，按以下步骤处理：

• 先检查该节点的Cassandra服务是否运行：

  systemctl status cassandra
  

• 如果服务未运行，先启动服务；如果服务运行但状态依旧异常，重复步骤2的操作（drain→停止→清理gossip目录→重启）。
• 同样要确保该节点的系统时间和集群其他节点同步。

修复验证 #

1. 等待节点重启完成后，在任意节点执行nodetool status，确认所有节点状态为UN（Up/Normal）：

   nodetool status
   

2. 查看Cassandra日志，确认不再出现received an invalid gossip generation的告警信息。
3. 用nodetool gossipinfo检查各节点的generation值，确保所有节点的generation数值和当前系统时间匹配，无异常大值。

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