replicaof no one 不会清空从库数据，仅断开复制并切换角色为master；若之后立即replicaof，Redis尝试PSYNC增量同步，但若replid不匹配或offset超出backlog范围，则触发FULLRESYNC并强制清空重载。
replicaof no one 不会清空从库数据，但可能掩盖问题
执行 replicaof no one 只是断开复制关系，不会触发 FLUSHALL 或清空数据库。从库内存和磁盘上的键值仍保留，但此时它变成一个独立的、可能含脏数据的 Redis 实例。如果之后立刻 replicaof <master_ip><master_port></master_port></master_ip>，Redis 会尝试基于当前状态做 PSYNC —— 若 master_replid 匹配且 offset 在 repl-backlog 范围内，就走增量同步；否则 fallback 全量同步。但关键在于：全量同步前，从库**必须主动清空自身数据**，这个动作由主库发来的 FULLRESYNC 触发，而非从库自动判断。
真正避免清空的唯一前提是“不触发全量同步”
从库是否被清空，取决于它能否成功进入增量同步（partial resync）。这需要同时满足三个条件：
- 主库的
repl-backlog-size足够大（建议 ≥ 当前内存占用的 2 倍），且未被写满覆盖 - 断连时间 ≤
repl-backlog-ttl（默认 3600 秒），否则 backlog 被释放 - 主库未重启过 —— 否则
run_id变更，PSYNC 请求直接被拒，强制全量同步
用 INFO replication 查看从库的 master_repl_offset 和主库对比，差值若小于 backlog 大小，说明还有机会追上；否则已注定要清空重载。
手动干预时，FLUSHALL 必须在 replicaof 之前执行
如果你确认从库已有误写（比如曾 CONFIG SET slave-read-only no），又想让它重新同步但**保留部分本地数据**（如配置类 key），就不能依赖自动全量同步——因为 FULLRESYNC 一定会清空整个 db。此时应：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先停写流量，确保无新请求打到该从库
- 用
redis-cli -h <slave> KEYS "pattern:to:keep:*"</slave>提前备份关键 key（或用DUMP+RESTORE） - 执行
FLUSHDB（只清当前 db）或FLUSHALL（清全部 db），再立即replicaof <master_ip><master_port></master_port></master_ip> - 同步完成后，把备份的 key 手动回填（注意 TTL 和类型）
注意：FLUSHALL 是原子操作，执行后无法 rollback；生产环境务必先验证 key 范围，避免误删。
从库配置里禁用 save 不等于“不怕清空”
有人以为从库关掉 RDB（save ""）就能规避清空风险，这是误解。RDB 关闭只影响本地持久化，不影响复制逻辑。当全量同步发生时，从库依然会接收主库发来的 RDB 流，并在内存中清空+加载——这个过程与本地是否有 RDB 文件无关。反而，关闭 save 会让从库重启后无法断点续传，每次都要全量同步，清空频率更高。
真正要防的是“不该发生的全量同步”，而不是“同步时怎么不清空”。所以重点始终是：压测时调大 repl-backlog-size 和 client-output-buffer-limit，监控 master_sync_in_progress 和 repl_backlog_histlen，在 backlog 即将写满前人工介入，比等它溢出后再抢救更可靠。
