必须显式配置 sentinel announce-ip 和 announce-port，确保所有哨兵使用客户端可直连的IP，并验证客户端能通过哨兵获取并连接新主节点。

哨兵配置里没填对 sentinel announce-ip

哨兵自己广播的 IP 是它认为“客户端该连谁”的关键，不是看 bind 或本地网卡地址。默认情况下，哨兵会用本机 hostname 反解出一个 IP（经常是 127.0.0.1 或内网不可达地址），导致客户端拿到错误地址，连不上新主节点。

必须显式设置：
sentinel announce-ip 192.168.10.25
sentinel announce-port 26379

• 这个 IP 必须是客户端网络能直连的（比如宿主机 IP、K8s Service IP、云服务器公网/内网可路由地址）
• 不能只在某台哨兵上配，所有哨兵节点都要一致且真实可达
• 改完要 sentinel failover 强制触发一次切换，验证客户端是否真能连上新主

客户端没启用哨兵自动发现机制

很多 Redis 客户端（如 Jedis、redis-py、StackExchange.Redis）默认不主动轮询哨兵，而是靠你手动传入“哨兵列表”+“服务名”，再由客户端内部连接哨兵查 SENTINEL get-master-addr-by-name。如果漏了服务名或哨兵地址写错，就永远卡在旧主。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 确认代码里初始化客户端时传的是哨兵地址列表，不是主节点地址
• 服务名（master-name）必须和哨兵配置中 sentinel monitor <name> ... 的 <name> 完全一致（大小写敏感）
• Java 用 JedisSentinelPool 时，别漏掉 new JedisSentinelPool("mymaster", sentinelSet) 里的 "mymaster"
• Python redis-py 要用 Sentinel(...).master_for("mymaster")，不是直接连 Redis(...)

防火墙或网络策略拦了哨兵间通信

哨兵靠 TCP 端口（默认 26379）互相交换状态，也靠它和 Redis 实例通信。如果哨兵 A 能连主库但连不上哨兵 B，它就无法达成多数派共识，is-master-down-by-addr 返回失败，failover 就卡住不动。

• 用 telnet 192.168.10.26 26379 从每台哨兵机器手动测通其他哨兵
• 检查云厂商安全组、K8s NetworkPolicy、宿主机 iptables 是否放行 26379 的双向 TCP
• 哨兵日志里搜 Connection refused 或 timeout，定位具体哪对节点不通
• 避免混用 IPv4/IPv6：所有哨兵配置统一用 IPv4 地址，关掉 ::1 相关监听

主从复制断开后哨兵没及时判定主下线

哨兵判断主库宕机不是靠心跳超时一次就切，而是依赖 quorum（投票数）+ down-after-milliseconds + failover-timeout 多重条件。常见误判是参数设得太保守，比如 down-after-milliseconds 5000 却把网络抖动当故障，或 quorum 设成 3 却只部署了 2 个哨兵。

• 生产环境建议：down-after-milliseconds 30000（30 秒），避免误切；quorum ≤ 哨兵总数的半数向上取整（3 哨兵设 2，5 哨兵设 3）
• 用 SENTINEL masters 查当前主节点状态，关注 flags 字段是否含 s_down 或 o_down
• 用 SENTINEL sentinels <master-name> 看其他哨兵是否都在线并同步了状态

哨兵本身不转发请求，也不代理流量，它只负责通知“谁是新主”。客户端能否切过去，本质取决于它能不能从哨兵那里拿到正确 IP，并且那个 IP 真的能被自己的网络访问到——这点最容易被当成“配置完了就没事了”，结果切完主节点，客户端还在连已下线的老地址。