主库崩了，从库不会自动变成主库——除非用了哨兵或redis cluster；纯主从下服务中断，需人工干预，slaveof no one无法真正救急，主库恢复后直接slaveof易触发全量同步，哨兵也需正确配置与客户端配合。
没配哨兵时，SLAVEOF 不能救急
很多人误以为只要执行 SLAVEOF no one 就能立刻接管服务，但现实很骨感：
- 执行
SLAVEOF no one后，原从库确实会停止复制、获得写权限，但它不自动继承主库的客户端连接、密码、ACL 规则、慢日志配置等运行时状态； - 如果主库刚崩，从库可能还没同步完最后一批命令（尤其是用 RDB + 命令传播模式时），
replication backlog缓冲区里没存全，这部分数据就丢了； - 客户端还在往旧主库地址发请求，DNS 或连接池没刷新，会持续报
Connection refused或超时，不是切换完命令就“自动可用”。
主库恢复后，别直接 SLAVEOF 回去
原主库修好重启，想让它变回从库？不能一上来就 SLAVEOF，否则大概率触发全量同步（SYNC），代价巨大：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 新主库（原从库）的
repl_backlog_size如果太小，或原主库宕机太久，复制积压缓冲区数据已被覆盖，新主库只能发起PSYNC?FULLRESYNC； - 全量同步会 fork 子进程生成 RDB，占用大量内存和 CPU，还可能阻塞新主库的读写；
- 正确做法是：先在新主库上执行
BGSAVE，把当前最新数据落盘；再把生成的dump.rdb拷到原主库目录，清空其 AOF（如有）、关闭持久化（避免加载冲突），再启动；最后才执行SLAVEOF——这样大概率能走部分同步（PSYNC）。
哨兵不是“开了就自动高可用”
哨兵能自动完成故障转移，但前提是配置没踩坑：
-
sentinel monitor的 quorum 值必须 ≤ 实际在线哨兵数，否则无法达成多数派投票； - 哨兵之间必须能互相通信（
sentinel down-after-milliseconds和sentinel failover-timeout要匹配网络延迟）； - 客户端必须使用支持哨兵的驱动（如 Jedis 的
RedisSentinelConfiguration、redis-py 的Sentinel类），且要监听+switch-master事件来刷新 master 地址； - 如果只部署单个哨兵，它自己挂了，整个自动恢复就失效了——生产环境至少 3 个哨兵，分散在不同机器。
