节点异常宕机后自动切换失败需按“检测—决策—执行—验证”四环节逐层排查：查探针日志与探测参数确认是否检测到故障；核对zk会话、仲裁状态及vip权限验证决策逻辑；检查新主角色、元数据同步点和客户端连接确认执行生效；最后回溯rpo/rto评估数据丢失与恢复时效。
节点异常宕机后自动切换失败，不是“没切”，而是“该切没切”或“切了但不生效”。排查要围绕“检测—决策—执行—验证”四个环节逐层下沉，重点看日志、状态、配置、网络四类证据。
一、确认故障是否被正确检测到
自动切换的前提是系统感知到了宕机。很多故障卡在第一步——健康检查压根没发现异常。
- 查监控探针日志：比如ZKFC的
zkfc.log里是否有Failed to connect to NameNode HTTP endpoint；openGauss的gs_om -t status输出中主节点状态是否已变为Unknown或Down；MHA的masterha_manager日志里是否有Dead server detected记录。 - 核对探测参数：心跳超时时间（如
ha.healthcheck.timeout）、重试次数（如ipc.client.connect.max.retries）、网络连通性（用telnet 主节点IP 端口测试HTTP或数据库端口是否真不通）。 - 注意假死陷阱：进程还在、端口可连，但JVM卡顿或SQL线程阻塞，此时依赖HTTP回调或简单端口检测的机制大概率失效。需补充进程内指标（如GC时间、事务响应延迟）作为辅助判断依据。
二、检查切换决策逻辑是否触发
检测到异常≠立刻切换。仲裁、投票、超时等待等逻辑可能拦住流程。
- 查ZooKeeper会话状态：用
echo stat | nc localhost 2181看ZKFC是否还持有有效会话；若会话未过期（session timeout设得过大），ZKFC不会主动发起fencing和切换。 - 查仲裁节点是否在线：KingbaseES或MGR集群中，若仲裁节点失联或投票未达多数（如3节点集群有2个不可达），切换会被拒绝。
- 查VIP漂移权限：Keepalived或自研脚本执行
ifconfig绑定VIP时，是否因SELinux限制、网卡名写错（如写成eth0但实际是ens160）、或缺少sudo权限而静默失败。
三、验证切换执行动作是否完成
即使日志显示“开始切换”，也不代表服务真正接管成功。
- 查新主节点角色状态：Hadoop用
hdfs haadmin -getServiceState nn2；openGauss用gs_ctl query -D $PGDATA；MySQL MHA用masterha_check_status，确认目标节点确实进入Active或Primary角色。 - 查元数据/日志同步点：Hadoop看JournalNode上edit log是否连续；MySQL比对
SHOW MASTER STATUS和从库SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos；KingbaseES检查WAL接收延迟（pg_stat_replication视图里的replay_lag）。 - 查客户端连接行为：是否仍连老IP？DNS缓存是否未刷新？应用连接池是否缓存了旧连接？可用
ss -tulnp | grep :3306确认监听端口是否已在新节点启动并绑定。
四、回溯RPO与RTO是否符合预期
切换成功只是起点，业务是否真的无损，要看数据丢了多少、服务停了多久。
- RPO（数据丢失量）：对比宕机前最后一条成功事务的binlog位点/WAL LSN，与新主节点当前应用到的位置。异步复制下，差值越大，丢的数据越多；半同步下，若配置了
AFTER_SYNC且未超时，理论上RPO=0。 - RTO（恢复时间）：从监控告警发出到客户端可正常读写的时间。注意排除应用层重试耗时（如未配
maxRetries，第一次请求就直接报错，而非等待切换完成）。 - 典型反模式：切换后业务报“唯一键冲突”或“主键不存在”，说明旧主节点未彻底隔离（fencing失败），或应用在双主窗口期内发出了重复请求。
