哨兵节点间通信失败的典型现象是INFO Sentinel中sentinels字段为空或数量少于部署总数，日志反复出现+sdown/-sdown sentinel，且SENTINEL sentinels mymaster仅返回本机哨兵；根本原因是myid重复、monitor地址不一致、bind/protected-mode配置不当或26379端口未通。
哨兵节点间通信失败的典型现象
登录任意一个哨兵节点执行 redis-cli -p 26379 INFO Sentinel，返回的 sentinels 字段为空或数量明显少于部署总数；日志里反复出现 +sdown sentinel 或 -sdown sentinel，说明它在不断“上线/下线”其他哨兵；SENTINEL sentinels mymaster 只返回本机哨兵，看不到对端。
检查并清理重复的 sentinel myid
所有哨兵配置文件中若存在相同的 sentinel myid 值（比如都写死了 sentinel myid abc123...），会导致它们互相拒绝握手。这不是配置错误，而是身份冲突。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 逐台登录哨兵节点，打开
/etc/redis/sentinel.conf，删除整行sentinel myid xxx - 重启该哨兵进程：
systemctl restart redis-sentinel（或对应服务名） - 重启后哨兵会自动生成唯一 ID 并写回配置文件，无需手动补写
- 注意：不要只改一个节点就停手，必须所有哨兵都执行该操作
确认所有哨兵监控的是同一个主节点地址
哨兵之间通过监听同一组 sentinel monitor 配置来发现彼此。如果从节点机器上误配了指向自己本地 Redis 实例的 sentinel monitor（例如 sentinel monitor mymaster 127.0.0.1 6380 2），它就无法加入主节点对应的哨兵集群。
- 每台哨兵的
sentinel.conf中，sentinel monitor的 IP 和端口必须一致，且指向主节点（如sentinel monitor mymaster 192.168.1.108 6379 2） - 这个地址必须能被所有哨兵节点直接访问（不能是 localhost、127.0.0.1 或仅绑定内网但未开放路由）
- 检查
bind和protected-mode：哨兵进程自身也要能被其他哨兵连上，所以它的bind应包含所在网卡 IP，且protected-mode no（或配了requirepass）
验证哨兵间网络与端口连通性
哨兵默认使用 TCP 端口（如 26379）与其他哨兵通信，不是靠 Redis 主从端口。很多人只通了 6379，却忘了放开哨兵端口。
- 用
telnet 192.168.1.109 26379从一台哨兵连另一台，确认端口可达 - 检查防火墙：
iptables -L -n | grep 26379或ufw status，确保 INPUT 规则放行该端口 - 确认没有容器网络隔离（如 Docker 默认 bridge 模式下，不同容器的 26379 不互通，需用 host 网络或自定义 overlay）
- 哨兵之间不依赖 DNS，全部用 IP + 端口硬编码，避免主机名解析失败
missing+quorum 就会卡死整个 failover 流程——这点常被忽略，直到主库真宕机才暴露。 
