SENTINEL PUBSUB通道不通导致哨兵无法协商状态，因__sentinel__:hello等频道断连，需检查26379端口互通、NTP时间同步、sentinel auth-pass配置一致，并强制执行SENTINEL monitor刷新视图，确保所有哨兵SENTINEL masters输出完全一致。
SENTINEL 发布订阅通道不通，哨兵间无法协商状态
哨兵节点靠 PUBSUB 频道（如 __sentinel__:hello）广播和接收彼此的监控信息。这个通道一旦断掉，SENTINEL masters 输出就会不一致，新哨兵加入后长期卡在“未识别主库”状态，根本走不到选举环节。
常见错误现象包括：SENTINEL sentinels <name> 返回空列表、某台哨兵执行 SENTINEL ckquorum <name> 报 missing+quorum 但其他节点显示正常、redis-cli -p 26379 PUBSUB CHANNELS 在不同哨兵上看到的频道数不一致。
- 检查所有哨兵是否能双向访问彼此的
26379端口（用telnet <ip> 26379或nc -zv <ip> 26379） - 确认防火墙没拦截
26379的入站+出站流量（尤其是云厂商安全组、iptables、nftables） - 验证
sentinel monitor配置是否已在所有哨兵上生效：逐台连上去跑SENTINEL masters，比对num-sentinels和flags字段是否统一 - 别忽略 NTP 偏移——时间差 > 5s 会导致 hello 消息被直接丢弃，用
ntpq -p或chronyc tracking查看
客户端重订阅失败，导致收不到故障转移通知
哨兵通过 __sentinel__:hello 和 +switch-master 这类频道发事件，但这些消息只推给当前活跃的订阅连接。连接断开后不会补发，也不会持久化。
典型表现是：主从已切换成功，SENTINEL get-master-addr-by-name mymaster 返回新地址，但业务应用仍往旧主地址发请求，报 Connection refused 或认证失败。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端必须监听底层连接异常（如
redis-py的ConnectionError、TimeoutError），而不是等超时自动重试 - 重连成功后，必须显式调用
SUBSCRIBE __sentinel__:hello和SUBSCRIBE +switch-master，不能依赖上次的订阅上下文 - 不要在初始化阶段只做一次订阅——要封装成带重试的循环逻辑，例如每 3 秒尝试重订阅，直到收到第一条
hello消息 - 如果用了连接池（如
JedisSentinelPool），确认它内部是否真正实现了哨兵事件监听，有些老版本只是拿哨兵查地址，不订阅事件
sentinel auth-pass 配置缺失或不匹配，导致 failover 后新主拒绝连接
主节点启用了 requirepass，但哨兵没配 sentinel auth-pass，或者密码写错/大小写不符，会导致故障转移后新主节点拒绝所有客户端认证请求，看起来像“切换成功但业务连不上”。
错误日志里通常看不到明确提示，只会在客户端侧出现 NOAUTH Authentication required 或 ERR invalid password；而哨兵日志里可能只有模糊的 Failed to AUTH to master。
- 检查所有哨兵配置中是否都存在
sentinel auth-pass <master-name> <password>，且值与主节点requirepass完全一致（含空格、特殊字符） - 用
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster拿到新主地址后，手动连上去测试认证：redis-cli -h <new-ip> -p 6379 -a <password> ping - 如果主节点开启了
rename-command CONFIG ""，哨兵在切换过程中调用CONFIG SET会失败，导致从节点无法正确配置为新主的从库——此时需在哨兵配置中加sentinel config-epoch <name> <epoch>手动干预，或临时放开CONFIG
哨兵配置未动态刷新，旧 monitor 视图残留引发脑裂
修改 sentinel.conf 后只重启进程，不执行 SENTINEL monitor 命令，会导致部分哨兵仍按旧配置监控一个已下线的 IP:PORT，而其他哨兵在监控新地址。结果就是两组哨兵各自形成子集群，互相看不见，SENTINEL ckquorum 检查永远失败。
这种问题在滚动升级、灾备切换或网络分区恢复后特别常见，表现为：SENTINEL sentinels <name> 输出里，一部分哨兵列出的 peer 列表为空，另一部分却有完整列表。
- 强制刷新必须在每台哨兵上执行：
SENTINEL monitor <name> <ip> <port> <quorum>，不是改完配置文件就完事 - 刷新后立刻验证：
SENTINEL ckquorum <name>必须返回OK，且SENTINEL masters中num-sentinels应等于实际在线哨兵数 - 注意
quorum值设置：设为2却只有 1 台哨兵在线，或设为偶数（如4）而总哨兵数为5，都会在分区时导致投票分裂 - 如果某哨兵长期失联后重启，它本地缓存的 monitor 配置可能比 hello 广播还“新”，这时必须先
SENTINEL reset *清空状态再重新monitor
hello 消息——不是看配置文件一模一样，而是看 SENTINEL masters 的输出是否完全一致。只要有一台哨兵的 flags 是 disconnected 或 odown 而别人是 ok，整个协商机制就已失效。 
