这类问题我又碰上了一次。一主两从加三台哨兵的 Redis 6.2 集群，某次主节点网络抖动触发了切换，哨兵日志显示新主已经提升，可应用侧写入一直报 READONLY You can’t write against a read only replica，重启应用才恢复。
第一反应是「哨兵只会通知，切换后没人去改入口的虚拟地址，流量还打在原机器」，验证下来不成立。
原因不止一个，得分开看。应用直连写死了主库地址，没走哨兵，主从角色换了它不知道；连接池里的旧连接一直没断，客户端复用到降级成从库的老主上；旧主被降级后仍然监听同一个端口，只是拒绝写，从外部看像是连上了。
先确认三台节点的真实角色
redis-cli -h 10.0.2.11 -p 6379 info replication | grep -E 'role|master_host'接着看哨兵认定的是哪台主
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster随后改入口解析或让客户端走哨兵，再重建连接池
redis-cli -h 10.0.2.11 -p 6379 config set replica-read-only yes剩下的就是验证新主可写
redis-cli -h 10.0.2.12 -p 6379 set probe ok怎么算真的好了，看的是同一批现象。写入端不再出现 READONLY 报错，set 探针在新主上返回 OK，哨兵与应用的 master 地址一致，故障切换演练后业务无需重启。
容易忽略的是，只靠哨兵不够，入口要做成能被切换的地址；连接池必须支持节点变化通知，否则每次切换都是一次事故。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。