SLAVEOF NO ONE 是断连+角色重置的原子操作：终止复制连接、清空主节点状态、将 role 改为 master，运行时生效但重启回退，不清理数据、不通知其他节点。
能恢复，但必须分清“文件丢失”发生在哪一端、是否还有可用副本、有没有开启AOF。 直接在从节点执行 SLAVEOF NO ONE 不是万能钥匙，它只改角色，不补数据；真正起作用的是从节点上已同步的那部分数据快照或日志。
SLAVEOF NO ONE 之后，从节点变主节点但数据没丢，为什么？
因为 SLAVEOF NO ONE 是个轻量级运行时操作：它只清除复制元数据（如 master_host、repl_offset），把 role 改成 master，不碰内存里的键值对，也不删磁盘上的 dump.rdb 或 appendonly.aof。所以只要从节点之前同步完整、没被手动 FLUSHALL 过，数据就还在。
- 执行后立刻可写，新写入会落盘（取决于你是否开启了 RDB/AOF）
-
INFO replication中role:master出现、master_host字段消失，就是切换成功的信号 - 重启后会回退为从节点——如果配置文件里还留着
replicaof行，这点常被忽略
从 Slave 拿 RDB 文件恢复主节点，要注意三件事
这不是简单复制粘贴。RDB 文件本身只是快照，能否用、怎么用，取决于主从同步是否真正完成、时间点是否一致、以及主节点当前状态。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先确认从节点数据最新：用
INFO replication查master_repl_offset（主偏移）和slave_repl_offset（从偏移），两者相等才说明完全同步 - 从节点上执行
SAVE或BGSAVE生成新 RDB，比直接拷dump.rdb更稳妥——避免文件正在被写入导致损坏 - 把 RDB 放到原主节点的
dir配置路径下，且确保dbfilename名字匹配，否则 Redis 启动时压根不加载
为什么 AOF 比 RDB 更适合做故障后恢复？
RDB 是某一时刻的全量快照，AOF 是增量命令流。当主节点宕机前最后几秒的写入没来得及触发 RDB 保存，这部分数据就丢了；而只要 AOF 的 appendfsync 不是 no，这些命令大概率已刷盘。
- 若从节点启用了 AOF，它的
appendonly.aof文件可直接复制到主节点，替换后重启即可重放全部写操作 - 但要注意：AOF 文件可能包含非法命令（比如网络中断时截断），需先用
redis-check-aof --fix修复 - 如果主节点原来没开 AOF，光靠从节点的 AOF 恢复后，新主节点默认也不会自动开启 AOF——得手动改配置再
CONFIG REWRITE或重启
最易被忽略的一点：所有恢复动作的前提，是那个“从节点”自己没出问题。它可能同步滞后、磁盘满、AOF 被截断、甚至被误执行过 SLAVEOF 切换过多次。动手前务必用 INFO 和 redis-cli --stat 看实时指标，别只盯着文件是否存在。
