从库必须明确关闭rdb和aof：save ""、appendonly no；主库持久化策略决定故障恢复数据完整性；备份必须来自主库，从库rdb不可替代；replica-serve-stale-data yes易致读取过期数据。
从库开启 RDB 或 AOF 是否必要？
不是“建议开启”，而是“必须明确关闭”。Redis 从库（slave/replica）默认不执行持久化，这是设计使然：主从复制本身已提供数据冗余，从库的持久化不仅无益，反而会引发严重问题。
常见错误现象：SAVE 或 BGSAVE 在从库触发后，CPU 突增、复制延迟飙升，甚至出现 READONLY You can't write against a read only replica. 报错后仍因磁盘 I/O 阻塞同步线程；若同时开启 AOF，还会因 appendfsync everysec 的定时刷盘与复制缓冲区竞争写入资源。
- 从库配置中必须显式禁用 RDB：
save ""（清空所有save规则） - 从库配置中必须关闭 AOF：
appendonly no（即使主库开了，从库也必须关） - 若使用 Redis 6.2+，还需确认
replica-read-only yes未被意外覆盖为no，否则可能误写导致复制中断
主库持久化策略直接影响从库切换后的数据完整性
主从切换（如故障转移）后，新主库的数据边界完全取决于原主库最后一次成功落盘的内容。这里没有“中间态”可选——从库只同步命令流或 RDB 快照，它本身不生成新的持久化点。
使用场景举例：若主库仅配置 save 900 1（15 分钟内至少 1 次写入才触发 RDB），而实际业务每秒写入数百 key，那么一次宕机可能导致最多 15 分钟数据丢失；此时无论从库是否开启 RDB，都无法弥补这个窗口。
- 高可靠性场景应启用
AOF+appendfsync always，但需接受性能折损（吞吐下降 30%~50%，取决于磁盘） - 平衡方案推荐
appendfsync everysec+no-appendfsync-on-rewrite yes，避免 AOF 重写期间阻塞 fsync - 严禁在主库同时开启
AOF和RDB自动触发（即保留save规则），二者并发落盘易导致磁盘 I/O 饱和，反向拖慢复制
哨兵或 Cluster 模式下，从库角色切换为主库时的持久化行为
哨兵（Sentinel）执行故障转移后，被提升的从库会自动将自身配置写入 redis.conf（若配置了 sentinel monitor 对应的 sentinel config-epoch），但它不会自动开启持久化——它继承的是原从库的配置文件内容。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
这意味着：如果原从库配置里是 appendonly no 和 save ""，切换后的新主库依然不会落盘，直到你手动修改配置并 CONFIG REWRITE 或重启。
- 生产环境部署前，必须确保所有节点（包括从库）的配置文件中，
appendonly和save设置与角色无关——即主库该开的，从库配置模板里也要预设好，只是运行时靠CONFIG SET关闭 - 切勿依赖
CONFIG SET appendonly yes动态开启：AOF 开启瞬间会触发rewrite，若此时内存数据量大，可能耗时数分钟，期间新主库拒绝写入 - 真正安全的做法是：所有节点统一使用含
appendonly yes和合理appendfsync的配置文件，再通过运维脚本在从库启动后立即执行CONFIG SET appendonly no
备份恢复链路中，从库快照能否替代主库备份？
不能。从库生成的 RDB 文件本质是主库某时刻的副本，其时间戳、校验和、key 数量都与主库一致；但若从库在 SLAVEOF 过程中发生过短暂停滞或部分命令丢弃（如网络抖动导致 repl-backlog 溢出），它的 RDB 就已偏离主库真实状态。
更危险的是：有人误以为“从库没写请求，RDB 更干净”，于是定期 scp 从库的 dump.rdb 做冷备——这等于备份了一个可能已损坏的复制中间态。
- 备份必须来自主库，且应在低峰期手动触发
BGSAVE，记录返回的RDB文件名与INFO persistence中的rdb_last_save_time - 若主库无法停写，可用
redis-cli --rdb /tmp/backup.rdb -u redis://user:pass@master:6379直接拉取当前主库 RDB，不触发本地保存 - 任何基于从库的自动化备份脚本，都必须前置校验：
INFO replication中master_sync_in_progress:0且slave_repl_offset与主库master_repl_offset严格相等
最常被忽略的一点：Redis 的 replica-serve-stale-data 默认为 yes，意味着从库在网络断开后仍持续响应读请求——此时你看到的“最新数据”，可能停留在几小时之前。这个设置和持久化无关，却会让故障排查时误判数据丢失范围。
