必须同步更新所有哨兵的sentinel monitor配置并执行SENTINEL RESET，否则哨兵持续连旧IP导致主观下线、故障转移失败；还需配置announce-ip确保客户端获取新主地址。
哨兵模式下改主节点 bind IP 会直接导致故障转移失败
直接改 bind 后重启主节点，哨兵会持续判定它“主观下线”，因为所有哨兵仍按旧配置连接原 IP（比如 192.168.10.181），而新 bind 地址（如 192.168.20.50）未同步到哨兵监控逻辑中。客户端也拿不到新地址，整个集群卡在“主不可达”状态。
必须同步更新 sentinel.conf 中的 sentinel monitor 行
哨兵不读取 Redis 实例的 bind 配置，它只信任自己配置文件里的 sentinel monitor 指令。改主节点 IP 后，这行必须立刻同步，否则哨兵永远连错地址：
-
sentinel monitor mymaster 192.168.10.181 6379 2→ 改为 →sentinel monitor mymaster 192.168.20.50 6379 2 - 如果主节点设了密码，
sentinel auth-pass mymaster的密码字段不用动，但 IP 必须对上 - 所有哨兵节点（不止一台）都要改，改完逐个 reload：
redis-cli -p 26379 SENTINEL RELOAD或重启进程
改完必须执行 SENTINEL RESET 并验证拓扑
仅改配置不生效——哨兵内部缓存了旧主节点元数据，得强制刷新：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 连任意一台哨兵执行：
redis-cli -p 26379 SENTINEL RESET mymaster - 等几秒后查结果：
redis-cli -p 26379 SENTINEL MASTER mymaster，确认输出中的ip字段已是新地址 - 再手动触发一次切换测试：
redis-cli -p 26379 SENTINEL FAILOVER mymaster，观察是否能成功选出新主并让从节点同步过去
客户端连接层容易忽略 announce-ip 配置
即使哨兵自己连上了新主，客户端仍可能连不上——因为哨兵返回的主节点地址是它自己广播的，不是 Redis 实例的 bind。关键看这个：
- 每个哨兵的
sentinel.conf必须显式设置：sentinel announce-ip 192.168.20.50和sentinel announce-port 26379 - 这个
announce-ip必须是客户端网络能直连的地址（不能是127.0.0.1或 Docker 内网 IP） - 改完同样要
SENTINEL RELOAD，否则客户端通过SENTINEL GET-MASTER-ADDR-BY-NAME拿到的还是旧 IP
最常被跳过的一步：改完所有配置后，没用 SENTINEL RESET 清哨兵本地缓存，也没验证 SENTINEL MASTER 输出是否真的更新。这时候看起来“配置都改了”，实际哨兵还在用旧地址发心跳、返回旧 IP 给客户端。
