Redis 持久化取舍：RDB、AOF 与故障恢复演练
Redis 持久化不是一个“打开即可高枕无忧”的选项。RDB、AOF、复制和外部备份解决的问题不同：持久化降低进程重启后的数据损失，复制提升可用性，备份用于应对误删除、逻辑错误和整组节点损坏。
RDB：紧凑快照
RDB 在指定条件生成时间点快照，文件紧凑、恢复快，适合备份和灾难恢复。代价是两次快照之间的数据可能丢失，Fork 和写时复制在大实例、高写入下会带来内存与延迟压力。
使用 RDB 时要监控最近一次保存是否成功、耗时、Fork 时间和磁盘空间。仅配置 save 规则但从不检查失败，相当于没有备份。
AOF：记录写操作
AOF 通过追加写命令缩小数据丢失窗口。常见策略：
appendfsync always：持久性最强，写入成本最高。appendfsync everysec：常用折中，故障时通常最多损失约一秒数据。appendfsync no：交给操作系统刷盘，性能与丢失窗口更不可控。
AOF 会重写以压缩历史命令。重写期间同样需要关注额外内存、磁盘 I/O 和临时文件空间。现代 Redis 的多部分 AOF 由清单管理，备份时应按官方方式复制完整集合，不能只拿其中一个文件。
两者如何选择
- 纯缓存、数据库可快速回源：可以不持久化，但要验证雪崩恢复能力。
- 可接受分钟级丢失、重视快速恢复：RDB 可能足够。
- 希望缩小丢失窗口：AOF
everysec更常见。 - 数据价值较高：组合使用 RDB 与 AOF，并保留外部备份。
开启持久化不等于 Redis 适合成为核心交易数据库。业务仍要评估事务语义、审计、查询和恢复目标。
复制不是备份
主节点执行误删除，命令会立即复制到从节点；逻辑污染也会同步传播。备份必须与在线集群隔离，保存多个时间点，并定期验证可读性。
一次完整恢复演练
- 在隔离环境启动与生产兼容的 Redis 版本。
- 复制备份文件并校验 Hash、权限和清单完整性。
- 启动实例，检查日志中加载类型、耗时和错误。
- 对关键 Key 做数量、抽样内容、TTL 和业务一致性校验。
- 记录 RPO（丢失多少数据）与 RTO（恢复花多久）。
- 演练完成后销毁隔离数据，更新恢复手册。
生产检查项
- 数据目录是否真正挂载到持久卷。
- 容器重建是否仍能读取同一数据目录。
- 磁盘满时是否有告警和写入保护。
- AOF/RDB 最近成功时间是否纳入监控。
- 是否存在跨机器、跨时间点备份。
- 是否真正做过恢复，而不仅是“看见文件存在”。
评论
0 条讨论