SENTINEL FAILOVER 返回 OK 但未切换，是因为哨兵在前置检查阶段失败：quorum 值过高、目标 master 不在监控列表、或哨兵未初始化完成；需查日志确认卡点，并通过 SENTINEL MASTER、INFO replication 等多维度验证状态是否真正收敛。
SENTINEL FAILOVER 命令返回 OK 却没切换，怎么回事
执行 SENTINEL FAILOVER mymaster 后只看到 OK，但主从角色纹丝不动，不是命令写错了，而是哨兵在前置检查阶段就失败了。常见卡点有三个：
-
quorum值过高：比如配置了sentinel monitor mymaster 127.0.0.1 6379 3，但当前只有 2 个哨兵在线，无法达成投票共识 - 目标
mymaster不在监控列表里：用SENTINEL MASTER mymaster查不到，或返回结果中flags字段不含master（可能已被标记为s_down或已从拓扑中移除） - 哨兵未初始化完成：刚启动时
SENTINEL SENTINELS mymaster返回空或数量异常，说明它还没同步到完整集群视图
最直接的办法是查日志：tail -f /var/log/redis/sentinel.log，搜 is-master-down-by-addr 或 failover，看卡在哪一步。
怎么确认切换真的完成了，不能只信 OK
OK 只代表哨兵收下指令，切换是异步协商过程，必须分三处验证状态是否真正收敛：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 查哨兵视角：
SENTINEL MASTER mymaster，确认flags含failover_in_progress，且num-slaves、num-other-sentinels数值合理（比如旧主掉线后，num-slaves应该减少） - 查新主库：
INFO replication中role:master且master_host:为空（不是从别的节点同步），同时connected_slaves > 0 - 查旧主库：它应已变成
role:slave，且master_host指向新主的 IP+端口；若仍是role:master或master_host为空，说明复制关系重建失败
想指定某台从库升主，该怎么操作
哨兵默认按 slave-priority 选主，不保证是你想要的那台。要强制指定：
- 提前把其他从库的
slave-priority改为0（在对应redis.conf里配，然后CONFIG REWRITE或重启生效） - 确保目标从库的
slave-priority是正整数（如默认的100），且网络延迟低、复制偏移量最新 - 执行
SENTINEL FAILOVER mymaster后，等切换完成再把其他从库的slave-priority调回原值，否则下次故障转移还会跳过它们
手动触发和真实故障的区别在哪
SENTINEL FAILOVER 跳过了真实故障路径里的关键环节，容易误判高可用能力：
- 不走主观下线（
s_down）和客观下线（o_down）流程，因此测不出down-after-milliseconds设置是否合理、发现延迟是否超标 - 不模拟网络分区或主进程崩溃，旧主恢复后能否自动重连新主、是否因
replica-announce-ip配置错误或防火墙被拒，这些都覆盖不到 - 客户端连接池不会收到哨兵推送的新地址，也不会触发重定向逻辑，所以“短时不可用”这类问题在手动演练中根本暴露不出来
真正验证高可用，得关掉主节点进程、拔网线、杀哨兵进程——手动触发只是快速校验链路通不通，不是压测。
