从节点启动后不会自动加入哨兵监控，必须由哨兵通过主库info replication主动发现；需确保sentinel monitor配置正确、主库可达且返回有效从节点信息，从节点自身无需任何哨兵配置。
从节点启动后不会自动加入哨兵监控，必须靠哨兵主动发现并纳入管理——关键不在从节点“做什么”，而在哨兵是否已正确配置主节点、且能连通该从节点。
sentinel monitor 配置必须存在且生效
哨兵只有在配置了 sentinel monitor 指令并成功连接到主库后，才会通过 INFO replication 获取从节点列表，进而建立连接并开始监控。如果这条配置缺失、拼写错误（比如 mymaster 和实际主节点别名不一致），或主库地址端口不可达，哨兵压根不会知道有从节点这回事。
- 检查任意一台运行中的哨兵：执行
redis-cli -p 26379 sentinel masters，确认返回中包含目标主节点，且num-slaves字段大于 0 - 若
num-slaves为 0，说明哨兵没从主库拉到从节点信息——先验证redis-cli -h 主库IP -p 主库端口 ping是否返回PONG，再查主库的INFO replication输出里是否有该从节点的slaveX行 - 注意：
sentinel monitor中的别名（如mymaster）大小写敏感，所有哨兵必须完全一致，否则集群视作不同主节点
从节点自身无需配置哨兵相关项
从节点的 redis.conf 文件里，**不要**写 sentinel 开头的任何配置；它只负责响应主库同步和哨兵的 PING/INFO 请求。常见错误是误加 sentinel auth-pass 或 sentinel monitor 到从节点配置中，这会导致 Redis 启动失败或行为异常。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 从节点只需确保：正确设置了
slaveof（或replicaof）指向主库、有正确的masterauth（如果主库启用了密码）、protected-mode no（若需跨网段通信） - 从节点不需要监听哨兵端口（如 26379），也不需要启动哨兵进程——它不是哨兵集群的成员，只是被监控对象
- 重启从节点后，只要主从复制链路正常，哨兵会在下一轮
INFO轮询（默认每 10 秒）中自动识别并纳入监控，无需人工干预
新从节点上线后哨兵识别延迟约 10–15 秒
哨兵不是实时感知新从节点的。它依赖主库 INFO replication 的输出更新本地拓扑，而这个命令默认每 10 秒执行一次；首次拉取后还需几秒完成握手与状态同步。所以从节点启动并完成与主库的全量同步后，仍需等待至少一轮完整周期才能出现在哨兵视野里。
- 验证方式：在哨兵上执行
redis-cli -p 26379 sentinel slaves mymaster，观察返回列表是否包含新从节点的 IP 和端口 - 如果 20 秒后仍未出现，重点排查：主库的
INFO replication是否真列出了该从节点；该从节点的slave_repl_offset是否持续增长（证明复制正常）；哨兵日志中是否有类似+sdown slave <ip>:<port></port></ip>或+slave的记录 - 切勿在刚启动就反复重启哨兵或修改配置——高频重载反而可能触发哨兵状态紊乱
最容易被忽略的是：哨兵对从节点的“发现”完全被动，它不扫描网络、不读取从节点配置、也不依赖 DNS 或服务注册。一切依据主库的 INFO 输出。所以问题往往不出在从节点，而出在主库是否如实上报、哨兵能否稳定读取、以及两者之间有没有防火墙或认证拦路。
