直接更换主节点IP需同步执行SENTINEL RESET、确保新主就绪并验证ROLE，同时更新哨兵auth-pass配置，否则将导致连接失败、重配混乱或写入丢失。
直接换主节点 IP 不能只改 sentinel.conf 里的一行，必须同步触发哨兵重发现 + 客户端感知，否则会出现连接旧地址失败、从节点反复被重配、甚至写入丢失。
SENTINEL RESET 后必须等哨兵重新拉取 info
当你把主节点迁移到新 IP（比如从 192.168.100.10 搬到 192.168.100.50），仅修改所有哨兵的 sentinel monitor mymaster 192.168.100.50 6379 2 并重启是不够的。哨兵不会立刻信任这个新地址——它需要先连上该地址上的 Redis 实例，执行 INFO replication 确认它确实是主节点，且有合法的 role:master 和一致的 run_id。
- 执行
SENTINEL RESET mymaster（在任一哨兵上）后，哨兵会清空本地缓存的主节点状态，并在几秒内发起新一轮探测 - 此时新主节点必须已启动、绑定正确 IP、未启用
protected-mode、且能响应PING和INFO - 若新主节点尚未就绪，哨兵会持续报错
ERR Invalid argument, No such master with that name或卡在sdown状态 - 可用
SENTINEL MASTER mymaster查看当前ip、port、flags（是否为master）和num-slaves是否已更新
客户端不能只靠 __sentinel__:hello 频道解析 IP
订阅 __sentinel__:hello 是获取主节点变更最轻量的方式，但消息本身不带校验，且多个哨兵广播存在微小时间差。如果客户端直接用第 4–5 字段（IP+port）无条件切换连接，可能拿到一个“尚未完成复制就绪”的地址，导致 READONLY 错误或写入拒绝。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 收到新 IP 后，必须先用该地址连接 Redis，执行
ROLE命令确认返回["master", ...]，再尝试写操作 - 避免在收到第一条新消息时立即切断旧连接；建议保留旧连接 5–10 秒，同时并发探测新地址是否真正可写
- 若业务使用连接池（如 JedisPool、redis-py 的 ConnectionPool），需主动调用
close()或标记旧连接失效，否则池中残留连接仍会发请求到旧 IP - 注意：只有连接 Redis 数据节点（非哨兵节点）才能成功
SUBSCRIBE __sentinel__:hello；连哨兵节点会报错ERR only allowed from normal client connections
replicaof 手动指向新主前要停掉哨兵监控
如果你因迁移需要，临时让某个从节点直连新主（比如做数据补全），直接执行 replicaof 192.168.100.50 6379 是危险的——哨兵会在 1–3 秒内检测到拓扑不一致，自动把它切回原主或触发错误 failover。
- 临时操作前，先在对应哨兵上执行
SENTINEL REMOVE mymaster（移除对该主节点的监控），再操作从节点 - 操作完成后，用
SENTINEL MONITOR mymaster 192.168.100.50 6379 2重新加入，并执行SENTINEL RESET mymaster - 不要在生产环境长期依赖
replicaof手动维护主从关系；它绕过了哨兵的选举逻辑和复制偏移量校验，容易造成数据断层 - Redis 6.2+ 支持
REPLICAOF NO ONE PERSISTENT，可让节点脱离复制但保留配置，适合迁移过渡期，但依然需配合哨兵重配置
最关键的遗漏点：哨兵本身不存储主节点证书或 ACL 规则。如果新主启用了 requirepass 或 aclfile，你必须确保所有哨兵配置里都更新了 sentinel auth-pass mymaster <new_password>，否则它们连不上新主，整个故障转移流程会卡死在“主观下线”阶段。
