SENTINEL FAILOVER 返回 OK 仅表示指令被接收，不意味切换完成；无反应主因是哨兵未达成共识或目标 master 不满足前提（如在线哨兵数＜quorum、master 不在监控列表、哨兵未初始化完毕）；需分三步验证：哨兵视角含 failover_in_progress、新主 role:master 且 master_host 为空、旧主已变 slave 并指向新主；手动触发跳过主观/客观下线、网络分区、客户端重定向等真实路径，故须调大超时参数、等待 reconf-slaves 阶段结束，并补断网测试。
SENTINEL FAILOVER 命令不会立即完成切换，返回 OK 仅表示哨兵已接收指令并开始流程；若主从状态没变，大概率是哨兵未达成共识或目标 master 不满足前提条件。
为什么 SENTINEL FAILOVER 没反应
命令执行后无输出、无报错、主从也没变，常见原因不是命令写错了，而是底层检查卡住了：
- 哨兵集群在线数不足 quorum：比如配置了
sentinel monitor mymaster 127.0.0.1 6379 2，但当前只有 1 个哨兵能通信，就无法发起选举 - 目标 master 不在哨兵的监控列表里：用
SENTINEL MASTER mymaster查不到该实例，或 flags 中不含master（比如它已被标记为s_down或已下线） - 哨兵自身未完成初始化：刚启动时可能还没从其他哨兵同步到完整拓扑，
SENTINEL SENTINELS mymaster返回空或数量异常 - 日志里卡在
is-master-down-by-addr阶段：说明哨兵在尝试确认 master 状态，但收不到足够响应——查tail -f /var/log/redis/sentinel.log最直接
执行后如何判断是否真切换成功
不能只看命令返回 OK，必须分三步验证实际状态：
- 查哨兵视角：
SENTINEL MASTER mymaster，确认flags字段含failover_in_progress，且num-slaves和num-other-sentinels数值合理（比如从 2 变成 1，说明旧主已脱网） - 查新主库：
INFO replication返回中role:master且master_host:为空（不是从别的节点同步），同时connected_slaves> 0 - 查旧主库：它应已变成
role:slave，且master_host指向新主的 IP+端口；若仍是role:master或master_host为空，说明复制关系重建失败
手动触发和真实故障的区别在哪
SENTINEL FAILOVER 跳过了真实故障路径里的关键环节，容易误判高可用能力：
- 不走主观下线（
s_down）和客观下线（o_down）流程，直接发起选举，因此测不出down-after-milliseconds设置是否合理、发现延迟是否超标 - 不模拟网络分区或主进程崩溃，旧主恢复后能否自动重连新主、是否因
replica-announce-ip配置错误或防火墙被拒，这些全覆盖不到 - 客户端连接池不会收到哨兵推送的新地址，也不会触发重定向逻辑，所以“短时不可用”这类问题在手动演练中根本暴露不出来
真正要练出效果，得提前做三件事
否则就是走形式，演完以为稳了，出事才发现漏了一堆链路：
- 调大两个超时参数：把
down-after-milliseconds和failover-timeout设得比默认值更宽松，避免演练中途被误判中断 - 等完再验：必须等到
SENTINEL MASTER mymaster显示failover-state-reconf-slaves阶段结束，才去查新主、旧主状态 - 补真实断网测试：手动
iptables -A OUTPUT -d <old-master-ip> -j DROP</old-master-ip>模拟网络隔离，再观察哨兵行为——这才是检验发现机制和脑裂防护的关键
