Redis监控 哨兵管理 如何使用Redis命令查看哨兵信息，redis快速查询哨兵状态

Redis监控实战：手把手教你用命令查看哨兵状态

最新动态：Redis 7.2增强哨兵自动故障转移能力

根据2025年7月的最新消息，Redis 7.2版本对哨兵系统进行了多项优化，特别是在网络分区恢复后的自动处理能力上有了显著提升，这使得在生产环境中使用Redis哨兵进行高可用管理变得更加可靠，今天我们就来聊聊如何通过Redis命令快速查看哨兵状态,掌握集群健康状况。

Redis哨兵是什么？

Redis哨兵(Sentinel)就是Redis的高可用性解决方案，它像个24小时值班的保安，时刻盯着你的Redis主从集群，一旦主节点挂了，哨兵能自动选出新的主节点，把从节点切换过去,让你的服务几乎感受不到中断。

基础哨兵信息查询

查看哨兵基本信息

连上任意哨兵节点,执行这个命令：

redis-cli -p 26379
127.0.0.1:26379> INFO SENTINEL

你会看到类似这样的输出：

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

这里重点看：

• sentinel_masters：监控的主节点数量
• master0部分显示了主节点名称、状态、地址、从节点数量和哨兵数量

查看哨兵监控的主节点

0.0.1:26379> SENTINEL MASTERS

这个命令会列出所有被监控的主节点信息,包括：

• 主节点名称
• IP和端口
• 法定人数(quorum)
• 故障转移配置

深入查询哨兵状态

查看特定主节点的详细信息

0.0.1:26379> SENTINEL MASTER mymaster

把"mymaster"换成你的主节点名称,你会看到更详细的信息：

1. "name"
2. "mymaster"
3. "ip"
4. "127.0.0.1"
5. "port"
6. "6379"
7. "runid"
8. "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
9. "flags"
10. "master" ...（更多信息）

特别关注"flags"字段，正常应该是"master"，如果有"fail?"或"s_down"就说明有问题了。

查看从节点信息

0.0.1:26379> SENTINEL SLAVES mymaster

这会列出所有从节点的详细信息,包括：

• 每个从节点的IP和端口
• 主从复制状态
• 延迟情况
• 优先级（用于故障转移）

查看其他哨兵节点

0.0.1:26379> SENTINEL SENTINELS mymaster

这个命令特别有用,它能告诉你：

• 集群中有多少个哨兵节点
• 每个哨兵的IP和端口
• 哨兵之间的通信状态

如果这里显示的哨兵数量比你实际部署的少，说明网络可能有问题,哨兵之间通信不畅。

实战技巧：快速检查哨兵健康状态

日常运维中,我常用这个组合命令快速检查：

redis-cli -p 26379 <<EOF
INFO SENTINEL
SENTINEL MASTER mymaster | grep -E "status|address|slaves|sentinels"
EOF

输出示例：

# Sentinel
sentinel_masters:1
...
status=ok
address=127.0.0.1:6379
slaves=2
sentinels=3

几秒钟就能确认：

1. 主节点状态正常(status=ok)
2. 主节点地址正确
3. 有2个从节点
4. 3个哨兵都在线

故障排查常用命令

查看当前主节点地址

0.0.1:26379> SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
1) "127.0.0.1"
2) "6379"

这个命令在脚本中特别有用,可以自动获取当前主节点地址。

检查故障转移状态

0.0.1:26379> SENTINEL CKQUORUM mymaster

如果输出"OK 3 usable Sentinels. Quorum and failover authorization can be reached"，说明法定人数足够,可以执行故障转移。

查看挂起的脚本

0.0.1:26379> SENTINEL PENDING-SCRIPTS

有时候故障转移卡住了，可能是因为有脚本在执行,这个命令能帮你发现。

哨兵监控的最佳实践

1. 至少部署3个哨兵节点：放在不同的物理机器上，防止单点故障

2. 定期检查哨兵日志：哨兵的重要操作都会记日志，

   • +sdown（主观下线）
   • +odown（客观下线）
   • +switch-master（主节点切换）

3. 设置监控告警：对关键指标设置告警：

   • 哨兵数量减少
   • 主节点状态异常
   • 从节点数量不足

4. 测试故障转移：定期模拟主节点宕机，确保哨兵能正常工作

常见问题解答

Q：为什么SENTINEL SENTINELS命令显示的哨兵数量不对？ A：可能是网络问题导致哨兵之间通信不畅,检查哨兵节点的网络连接和防火墙设置。

Q：主节点明明活着，哨兵却显示+sdown怎么办？ A：这通常是哨兵和主节点之间的网络问题，检查网络延迟和连接，可以调整sentinel down-after-milliseconds参数,适当增加超时时间。

Q：故障转移后原主节点恢复，它会自动变回主节点吗？ A：不会，除非你手动执行故障转移把它切回来，或者设置sentinel failover-timeout让它在一段时间后可以重新参与选举。

熟练使用这些哨兵查询命令，能让你在Redis集群出现问题时快速定位原因，不再像个无头苍蝇一样乱撞，把这些命令加入你的运维工具箱,下次遇到Redis高可用问题就能从容应对了！