Redis哨兵模式不负责增加从库，仅监控、判断和通知；新增从库需先配置为从节点并建立复制，再由哨兵通过主节点INFO自动发现，最后经健康检查与客户端/Proxy配合实现读流量分发。

Redis 哨兵模式本身不负责增加从库，它只监控、判断和通知——真正完成从库添加与同步的是 Redis 实例自身和运维操作。动态增加从库的关键在于“先让新实例成为从节点，再让哨兵感知它”，整个过程无需重启服务，但必须严格遵循顺序。

启动新 Redis 实例并配置为从节点

新节点不能空跑，必须主动建立复制关系：

• 确保新 Redis 实例已正确启动：bind 绑定可访问 IP（不能仅限 127.0.0.1），protected-mode no，端口未被占用
• 不要改配置文件再重启；直接连上新实例执行命令：REPLICAOF <master-ip> <master-port>
• 执行后立刻检查：INFO replication 中 master_link_status:up、slave_repl_offset 持续增长，且 master_sync_in_progress:0（表示全量同步已完成）

让哨兵发现并纳入监控

哨兵不会自动扫描网络，它依赖主节点的 INFO 输出或主动探测：

Redis Skill - 高性能缓存管理

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

下载

• 哨兵默认每 10 秒向主节点发 INFO replication，从中提取当前从节点列表；因此新从库最多延迟 10 秒才会出现在 SENTINEL SLAVES <master-name> 结果中
• 若迟迟不出现，检查三项：防火墙是否放行新从库端口、新从库 bind 配置是否允许哨兵 ping 通、主节点 INFO 输出里是否真有该从库地址
• 无需对新从库执行 SENTINEL MONITOR（这个命令只用于添加主节点监控）；哨兵通过主节点间接发现从库即可

确认从库具备参与读和故障转移的资格

被哨兵看到 ≠ 可用。它还需满足健康与选举条件：

• 运行 SENTINEL slaves <master-name>，确认新节点 flags 包含 slave,online（而非 slave,sdown 或 slave,disconnected）
• 检查复制延迟：lag 字段应 ≤ 100（毫秒级），过大说明同步滞后，Proxy 或客户端读策略会自动剔除
• 若希望它在故障转移中被选为主节点，确保：slave-priority ≠ 0、与主断连时间未超 down-after-milliseconds × 10、已完成全量同步且偏移量接近主节点

客户端或 Proxy 层启用读流量分发

哨兵不管请求怎么发，读写分离靠外部实现：

• 使用 Lettuce 客户端时，初始化连接时设置 ReadFrom.REPLICA_PREFERRED，它会自动从哨兵获取从节点列表并轮询分发读请求
• 若用 Proxy（如 Codis、自研网关），需监听哨兵的 +slave/-slave 事件（通过 SENTINEL SUBSCRIBE），实时更新内部读节点池，避免轮询拉取
• 切记：Jedis 默认不支持自动读从，需手动管理连接池并定期调用 SENTINEL SLAVES 刷新地址