如何将已下线的Cassandra节点从故障检测器failuredetector中移除

这是Cassandra gossip模块的典型缓存残留问题：nodetool status的统计口径是持有有效token范围的活跃环节点，和故障检测器维护的“所有曾建立过gossip连接的端点”列表分属不同缓存域。如果decommission过程中目标节点没有向全集群完整广播自己的下线gossip消息（比如进程提前退出、网络临时隔离导致消息丢包），就会出现节点已从环上移除，但故障检测器仍持续探测、Phi值因为收不到心跳持续升高的情况。

可按以下低风险优先级顺序操作处理：

• 第一优先级：触发全节点的gossip缓存重置
  在集群所有剩余存活节点上逐台执行nodetool gossipreset，该命令仅清空本地gossip模块的历史连接缓存、重建和当前集群节点的gossip通道，不会触发数据重平衡、不影响线上读写流量。执行后等待10~15秒，再查看故障检测器状态，绝大多数场景下残留的端点就会从监控列表消失。
• 第二优先级：注入全集群的节点移除gossip消息
  如果重置gossip缓存后仍有残留，可在任意一台存活的种子节点上执行nodetool removestatus <残留节点的IP地址>，该命令会向整个gossip网络广播指定节点的无效状态，强制所有节点的故障检测器终止对该残留端点的监控。
• 极端场景兜底操作
  若以上操作都未解决，说明残留的端点记录被持久化到了各节点的系统表缓存中，可采用滚动重启的方式逐台清理：每台节点先执行nodetool flush system把系统表内存缓存落盘，再逐台滚动重启，单节点重启稳定加入集群后再操作下一台，节点启动加载最新集群元数据的过程中会自动过滤掉无对应合法token的残留端点。

操作注意：不要对这类已完成decommission的残留节点执行nodetool assassinate，该命令会强行触发集群范围的token重排，带来不必要的负载波动，对缓存类残留完全没有必要使用。

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