Redis哨兵模式监控多个哨兵节点_通过SENTINEL SENTINELS命令查看集群状态-Redis-PHP中文网

sentinel sentinels 命令须在 redis-sentinel 进程上执行，连错节点、端口或配置错误会导致报错或显示 disconnected；需检查启动方式、端口、announce-ip、网络连通性及 flags 等字段。

redis哨兵模式监控多个哨兵节点_通过sentinel sentinels命令查看集群状态

SENTINEL SENTINELS 命令返回空或报错：连接的是主节点而非哨兵节点

这个命令只能在哨兵节点（sentinel）上执行，不能在 Redis 主从节点上运行。如果连到 redis-server 实例（哪怕它配置了 sentinel 模式但没用 redis-sentinel 启动），会直接报错 NOAUTH Authentication required 或 ERR unknown command `SENTINEL`。

确认方式很简单：

检查启动命令：必须是 redis-sentinel /path/to/sentinel.conf，不是 redis-server /path/to/sentinel.conf
检查进程名：ps aux | grep redis，看到的是 redis-sentinel 进程才对
检查端口：哨兵默认监听 26379，主从节点默认是 6379 —— 连错端口是常见原因

SENTINEL SENTINELS 返回结果中 ip 字段是 127.0.0.1 或内网地址，外部无法访问

这是哨兵自动发现其他哨兵时，读取对方配置里的 bind 或 sentinel announce-ip 导致的。默认情况下，哨兵会用自己的 bind 地址（如 127.0.0.1）上报自己，其他哨兵就跟着广播这个地址。

解决方法只有显式配置对外可访问的 IP：

在每个哨兵的配置文件中添加 sentinel announce-ip 192.168.1.10（换成实际外网/集群内可达 IP）
同时确保 bind 不仅绑 127.0.0.1，比如写成 bind 0.0.0.0 或具体网卡 IP（注意防火墙放行 26379 端口）
改完后必须 redis-cli -p 26379 SENTINEL reset * 或重启哨兵，否则旧信息仍缓存在其他哨兵内存里

为什么 SENTINEL SENTINELS 显示的哨兵状态一直是 `disconnected`？

这表示当前哨兵无法与列表中的某个哨兵建立 TCP 连接，常见于网络不通、端口未开放、对方进程已挂，或对方哨兵配置了错误的 sentinel monitor 名称导致握手失败。

Redis Skill - 高性能缓存管理

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

下载

排查顺序建议：

用 telnet 192.168.1.11 26379 或 nc -zv 192.168.1.11 26379 确认基础连通性
检查目标哨兵日志：tail -f /var/log/redis/sentinel.log，看是否有 Connection refused 或 invalid instance type
确认所有哨兵的 sentinel monitor mymaster 192.168.1.5 6379 2 中的主节点别名（mymaster）完全一致，大小写和拼写都不能差
如果用了 Docker 或 Kubernetes，注意容器间 DNS 解析是否正常，避免用 localhost 或 127.0.0.1 互相引用

监控多个哨兵时，SENTINEL SENTINELS 的输出字段含义和关键判断依据

每行代表一个被发现的哨兵节点，字段顺序固定但不带 key 名，需按位置理解。典型输出如下：

1) 1) "name"
   2) "192.168.1.10:26379"
   3) "ip"
   4) "192.168.1.10"
   5) "port"
   6) "26379"
   7) "runid"
   8) "a1b2c3d4..."
   9) "flags"
   10) "sentinel"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "1234"
   19) "last-ping-reply"
   20) "1234"
   21) "down-after-milliseconds"
   22) "5000"
   23) "last-hello-message"
   24) "1234"
   25) "voted-leader"
   26) "?"
   27) "voted-leader-epoch"
   28) "0"

重点关注这几项：

flags 必须含 sentinel，若出现 odown 或 sdown 表示该哨兵已被判定下线
last-ok-ping-reply 和 last-ping-reply 差值过大（比如超过 down-after-milliseconds）说明心跳异常
voted-leader 非 ? 且 voted-leader-epoch 有数值，说明参与过故障转移投票 —— 可用于判断哨兵集群是否曾触发 failover

真正可靠的哨兵健康判断，不能只看 SENTINEL SENTINELS，还得交叉验证 SENTINEL MASTER mymaster 和各哨兵的 INFO replication 输出。尤其要注意 num-other-sentinels 是否等于你部署的总数，少一个就说明发现机制漏掉了谁。