SENTINEL FAILOVER 无反应大概率因哨兵未达成共识或主节点状态不满足切换前提：需至少3个哨兵在线且通信正常，目标master必须存在于SENTINEL MASTER列表且角色为master，quorum值不可高于实际哨兵数；命令返回OK不代表切换完成，须依次验证哨兵failover_in_progress标志、新主role:master且无master_host、旧主已变为slave并指向新主；手动触发不模拟真实故障路径，无法检测发现延迟、重连失败及客户端重定向问题；演练前须调大down-after-milliseconds和failover-timeout避免误判，并等待failover-state-reconf-slaves阶段完成再验证。
SENTINEL FAILOVER 命令为什么没反应
执行 SENTINEL FAILOVER <master-name> 后无任何输出或报错，但主从状态没变——大概率是哨兵集群没达成共识，或者目标主节点状态不满足强制切换前提。
- 必须确保至少 3 个哨兵实例在线且互相通信正常，否则
SENTINEL FAILOVER会静默失败（不报错，但日志里有no enough sentinels） - 目标
<master-name>必须在SENTINEL MASTER列表中存在，且当前角色为master；如果该名字拼错、或主节点已下线被自动摘除，命令直接无效 - 哨兵配置中
quorum值设得太高（比如设成 5，但实际只有 3 个哨兵），会导致无法发起投票，命令卡住或超时返回(nil) - 检查哨兵日志：
tail -f /var/log/redis/sentinel.log，搜索failover和is-master-down-by-addr，能快速定位卡在哪一步
手动触发后从库没升主？看这三处状态
即使命令返回 OK，也不代表切换完成。Redis 哨兵的故障转移是异步协商过程，需逐层验证状态是否真正收敛。
- 先查哨兵视角：
SENTINEL MASTER <master-name>，确认flags字段是否含failover_in_progress，且num-slaves、num-other-sentinels数值合理 - 再查新主库：
INFO replication返回中role:master且connected_slaves:>0，同时master_host字段为空（不是从别的节点同步） - 最后查旧主库：它应该已变成
slave，且master_host指向新主 IP+端口；若仍是master或master_host为空，说明复制关系未重建成功
SENTINEL FAILOVER 和真实宕机的区别
手动触发不会模拟网络分区或进程崩溃，所以绕过了很多真实故障路径，容易误判高可用能力。
- 真实主库宕机时，哨兵会先通过
is-master-down-by-addr多轮确认，而SENTINEL FAILOVER直接跳过健康检查，强行发起选举——这意味着它测不出哨兵发现延迟、主观下线误判等问题 - 旧主恢复后，会自动以从库身份加入新主，但真实场景中可能因
replica-announce-ip配置错误或防火墙导致重连失败，这点手动演练完全覆盖不到 -
SENTINEL FAILOVER不触发客户端重定向逻辑（如 Jedis 的SentinelPool自动更新地址），你得自己模拟客户端断连重试，否则以为“切成功了”，其实应用还在往旧主发请求
演练前必须关掉的两个配置项
否则你会遇到“切了又切回来”或“新主立刻被降级”的诡异现象。
- 关闭
sentinel down-after-milliseconds <master-name> 5000中的过短阈值：设成 30000 以上，避免演练期间哨兵因短暂抖动把刚升主的节点又标为sdown - 禁用
sentinel failover-timeout <master-name>的默认值（180000ms）：如果设太小（比如 30000），可能在新主还没完成全量同步时就中断 failover 流程，导致回滚 - 临时修改后记得用
CONFIG REWRITE持久化，否则重启哨兵服务配置丢失
SENTINEL MASTER 输出里的 failover-state-reconf-slaves 变成 failover-state-reconf-in-progress 就去验证，其实这时候从库都还没开始认新主。 
