Redis哨兵故障转移演练方法

Redis哨兵故障转移演练远非执行一条SENTINEL FAILOVER命令那么简单——它极易因哨兵未达成共识、主节点状态异常或quorum配置失当而“静默失败”；即使命令返回OK，也需层层验证哨兵的failover_in_progress标志、新主的独立master身份及旧主的正确从属关系；更关键的是，手动触发完全绕过了真实宕机中的健康探测、网络恢复、客户端重定向等核心环节，若不调大down-after-milliseconds和failover-timeout、不等待reconf-slaves阶段完成，演练结果将严重失真，让你误以为高可用坚不可摧，实则在真实故障中不堪一击。

SENTINEL FAILOVER 命令为什么没反应

执行 SENTINEL FAILOVER 后无任何输出或报错，但主从状态没变——大概率是哨兵集群没达成共识，或者目标主节点状态不满足强制切换前提。

• 必须确保至少 3 个哨兵实例在线且互相通信正常，否则 SENTINEL FAILOVER 会静默失败（不报错，但日志里有 no enough sentinels）
• 目标 必须在 SENTINEL MASTER 列表中存在，且当前角色为 master；如果该名字拼错、或主节点已下线被自动摘除，命令直接无效
• 哨兵配置中 quorum 值设得太高（比如设成 5，但实际只有 3 个哨兵），会导致无法发起投票，命令卡住或超时返回 (nil)
• 检查哨兵日志：tail -f /var/log/redis/sentinel.log，搜索 failover 和 is-master-down-by-addr，能快速定位卡在哪一步

手动触发后从库没升主？看这三处状态

即使命令返回 OK，也不代表切换完成。Redis 哨兵的故障转移是异步协商过程，需逐层验证状态是否真正收敛。

• 先查哨兵视角：SENTINEL MASTER ，确认 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 5000 中的过短阈值：设成 30000 以上，避免演练期间哨兵因短暂抖动把刚升主的节点又标为 sdown
• 禁用 sentinel failover-timeout 的默认值（180000ms）：如果设太小（比如 30000），可能在新主还没完成全量同步时就中断 failover 流程，导致回滚
• 临时修改后记得用 CONFIG REWRITE 持久化，否则重启哨兵服务配置丢失

哨兵故障转移不是原子操作，整个链条里任何一个环节（选举、复制、客户端感知）出问题，都会让演练结果失真。最常被忽略的是：没等 SENTINEL MASTER 输出里的 failover-state-reconf-slaves 变成 failover-state-reconf-in-progress 就去验证，其实这时候从库都还没开始认新主。

好了，本文到此结束，带大家了解了《Redis哨兵故障转移演练方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！