哨兵不会主动扫描网络发现从节点，只信任sentinel monitor定义的主库及主节点info replication上报的从节点列表；新增从节点后sentinel slaves仍为空，说明未被纳入监控，需检查slave-announce-ip、sentinel monitor同步、防火墙、ntp及端口连通性。
SENTINEL masters 返回空或不包含新从节点
哨兵不会主动扫描网络发现从节点，它只信任 SENTINEL monitor 指令定义的主库及其后续通过 Redis 自身 INFO replication 上报的从节点列表。如果新增从节点后 SENTINEL slaves mymaster 仍返回空或数量不变，说明哨兵压根没把它纳入监控视野。
常见现象包括：SENTINEL masters 中 "num-slaves" 一直为 0 或旧值；新从节点在 redis-cli -p 26379 info sentinel 的 sentinel_masters 统计里不增长；日志中无 +sdown 或 +new-epoch 等与该从节点相关的事件。
- 确认从节点已真正连上主节点：在从节点执行
INFO replication，检查role:slave且master_link_status:up - 检查主节点是否允许从节点上报自身地址：若配置了
slave-announce-ip，必须填对——不能是127.0.0.1或容器内网段（如172.18.0.3），而应是哨兵能直连的真实 IP - 哨兵本身不读取从节点的配置文件，所以
slaveof配置正确 ≠ 哨兵能看见它；关键看主节点是否把该从节点“告诉”了哨兵
sentinel monitor 配置没生效或被覆盖
sentinel monitor 不是静态加载一次就完事的指令。它通过哨兵间 hello 消息广播协商，若某台哨兵启动早、网络延迟高或刚重启，可能还卡在旧视图里，导致部分哨兵认为“有这个主库”，另一些则完全无视。
典型诱因：sentinel.conf 文件里写了 sentinel monitor mymaster 10.0.1.10 6379 2，但某台哨兵实际运行时执行过 SENTINEL monitor mymaster 127.0.0.1 6379 2（比如测试时手抖），之后再改配置文件也不起作用。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须逐台连接哨兵，执行
SENTINEL monitor mymaster <ip><port><quorum></quorum></port></ip>强制刷新，而不是只改配置文件 - 执行后立刻用
SENTINEL masters和SENTINEL sentinels mymaster对比所有哨兵输出，确保一致 - 若使用 Docker 或 Kubernetes，
sentinel announce-ip必须显式设成宿主机可路由的 IP，否则 hello 消息发出去别人收不到
防火墙/NTP/CONFIG 重命名导致哨兵握手失败
哨兵之间靠 26379 端口通信，哨兵连主从靠 6379 端口。如果其中任意一环不通，SENTINEL slaves 就永远拿不到最新列表——不是逻辑问题，是根本连不上。
最隐蔽的坑是 NTP 偏移：两台哨兵时间差超 5 秒，hello 消息会被直接丢弃；主节点若重命名了 CONFIG 命令（如 rename-command CONFIG ""），哨兵在故障转移时无法重写配置，整个 failover 卡死，但日志里只显示 +failover-end，看不出原因。
- 检查所有哨兵之间
telnet <other-sentinel-ip> 26379</other-sentinel-ip>是否通；哨兵到主从的telnet <redis-ip> 6379</redis-ip>是否通 - 用
ntpstat或chronyc tracking确认各节点时间偏移 - 主节点若禁用了
CONFIG，要么放开（rename-command CONFIG CONFIG），要么在哨兵配置中加sentinel config-epoch mymaster 0（不推荐）
从节点未出现在 INFO replication 的 slaves 列表中
这是上游根源。哨兵的 slaves 列表完全来自主节点的 INFO replication 输出。如果这里都看不到新从节点，哨兵再怎么刷新配置也白搭。
常见于：从节点配置了 slave-announce-ip 但填错；主节点开启了 protected-mode yes 且没配 bind；从节点虽执行了 SLAVEOF，但主节点拒绝连接（如 requirepass 不匹配、maxclients 耗尽）。
- 在主节点执行
INFO replication，确认slave0~slaveN区块是否包含新从节点的 IP+端口 - 检查从节点日志是否有
Connecting to MASTER后跟MASTER REPLICA sync started，没有说明没连上 - 若主节点启用了密码，从节点的
slaveof配置无效，必须用CONFIG SET masterauth <pass></pass>或在配置文件中设masterauth
INFO replication 输出。
