旧主恢复后未自动降级为从节点，因哨兵未将其纳入新拓扑管理：根本原因是哨兵启动时未加载最新配置，或sentinel.conf中残留错误的sentinel monitor指令、不匹配的sentinel myid及announce-ip配置，导致无法正确下发SLAVEOF命令。
旧主恢复后仍被当主节点用，导致写入失败
哨兵完成故障转移后，原主节点修复上线，但未自动降级为从节点，继续以独立主身份响应客户端写请求，结果报 READONLY You can't write against a read only replica 或直接拒绝连接。这不是客户端问题，而是哨兵未能将该节点重新纳入拓扑管理——根本原因是它启动时没加载最新哨兵配置，或配置中残留了旧的 sentinel myid 和错误的 sentinel monitor 指令。
sentinel.conf 被自动重写但角色没变？检查这三处
Redis 哨兵在运行中会通过 CONFIG REWRITE 自动更新配置文件，但它只写入运行时动态生成的监控状态（如从节点列表、当前主节点IP），**不修改以下三项**：哨兵自身的 sentinel myid、sentinel announce-ip/port、以及最危险的——sentinel monitor 行是否指向正确的主节点名和地址。若你手动改过 sentinel monitor mymaster 192.168.1.10 6379 2，而新主已是 192.168.1.20，哨兵重启后仍会固执地去“监控”那个已下线的旧地址，导致整个集群失联。
- 用
redis-cli -p 26379 SENTINEL MASTER mymaster查当前哨兵视角下的主节点 IP，对比实际新主地址是否一致 - 打开该哨兵的
sentinel.conf，确认末尾sentinel monitor行中的 IP 是否已被重写为新主；若仍是旧 IP，说明该哨兵从未收到过+switch-master事件，或事件被丢弃 - 执行
redis-cli -p 26379 CONFIG GET "sentinel-myid"，输出值应与配置文件末尾的sentinel myid完全一致；若不一致，说明配置文件被人工覆盖过，且哨兵未重启生效
旧主 Redis 实例启动后不自动同步，怎么办
旧主 Redis 进程重启后，默认不会主动执行 SLAVEOF，它仍以主身份启动，除非哨兵明确下发指令。哨兵只会在检测到该实例健康且 sentinel monitor 配置正确时，才向其发送 SLAVEOF new_master_ip new_master_port。常见卡点：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 旧主 Redis 的
redis.conf中若存在slaveof指令（哪怕注释掉），会导致启动失败或行为异常；必须清空或删掉整行 - 哨兵配置中
sentinel down-after-milliseconds mymaster 5000设置过短，而旧主刚启动网络未稳，就被判为odown，跳过同步流程 - 旧主 Redis 的
protected-mode yes且绑定127.0.0.1，哨兵无法从外部发起SLAVEOF命令；需改为bind 0.0.0.0或指定内网 IP，并配好requirepass（若启用了密码）
依赖自动重写不可靠，必须做两件事
别指望 CONFIG REWRITE 能兜底所有场景。哨兵的自动重写只保证“当前视图”写入磁盘，不校验逻辑一致性。线上出问题的案例里，80% 是因为运维在故障后手动编辑了 sentinel.conf，却忘了删掉旧 sentinel myid，或改错了 sentinel monitor 的端口，导致哨兵进程持续处于“半失联”状态。
- 每次哨兵重启前，用
redis-cli -p 26379 SENTINEL RESET *清空本地缓存的拓扑状态（注意：这不会清sentinel myid） - 部署脚本中必须包含校验逻辑：读取
sentinel.conf末尾的sentinel myid，用openssl rand -hex 20生成新值并替换，再启动；严禁复制粘贴配置文件
最易被忽略的是：哨兵之间通过 __sentinel__:hello 频道通信，若某台哨兵的 sentinel announce-ip 写成了 127.0.0.1，其他哨兵就永远收不到它的状态更新——此时它自己日志里可能一切正常，但整个集群共识已失效。
