AOF 与 RDB 混合持久化的恢复路径怎样验证

Redis 同时启用 AOF 和 RDB 后，恢复验证不能只盯着 dump.rdb 是否存在。重启时，Redis 会优先使用 AOF 重建数据；在 Redis 7 及以后，AOF 又由 manifest、一个 base 文件和若干 incremental 文件组成。可靠的演练应该把“启动成功”和“数据符合预期”分开检查。

一、先分清混合持久化的恢复输入

RDB 是某个时刻的紧凑快照，适合快速加载和备份；AOF 记录改变数据集的写命令，重启时通过重放恢复状态。开启 aof-use-rdb-preamble yes 后，AOF 重写产生的基础部分可以使用 RDB 格式，后面再接 AOF 命令尾部，这就是常说的“混合持久化”。

因此，恢复演练至少要保留同一组文件及其目录结构。Redis 7 以后不要只复制一个旧式 appendonly.aof 文件就结束，还要检查 AOF manifest 是否能找到对应的 base 和 incremental 文件。一个实用判断是：基础键来自快照，最后一次覆盖、删除或追加操作必须由增量部分体现。

二、用隔离目录构造一次恢复演练

演练应使用与源实例相同的大版本 Redis，并把备份复制到临时数据目录，避免直接覆盖生产文件。下面的配置只表达验证思路，目录、端口和密码应按测试环境调整：

# 让测试实例把持久化文件写入独立目录
dir /srv/redis-restore-check
dbfilename dump.rdb

# 开启 AOF，并用 RDB 前缀缩短基础数据的加载路径
appendonly yes
aof-use-rdb-preamble yes

# 每秒同步一次，演练时要把可能丢失的时间窗口记录下来
appendfsync everysec

# 末尾只有不完整命令时允许按默认策略继续加载
aof-load-truncated yes

# 使用独立端口，避免误连到生产实例
port 6390

启动前先核对目录中的 manifest、base 和 incremental 文件是否成套，再启动测试实例。不要把“端口能监听”当成恢复完成；Redis 能启动，只说明解析路径没有立即失败。

三、用数据不变量验证 RDB 基础与 AOF 增量

验证键要覆盖不同类型和不同操作结果。可以在源实例写入一组带版本标记的数据，再在恢复实例中用同样的命令检查。下面的命令是恢复演练脚本片段，注释说明了每个检查点：

# 固定版本标记：确认恢复的是本次演练的数据集
redis-cli -p 6390 SET restore:version hybrid-v1

# 读取基础键：确认快照中的字符串仍然存在
redis-cli -p 6390 GET restore:version

# 检查增量覆盖：恢复前应把旧值改成 new，不能只看到快照旧值
redis-cli -p 6390 GET restore:overwritten

# 检查增量删除：被删除的键必须返回空，而不是从 RDB 复活
redis-cli -p 6390 EXISTS restore:deleted

# 检查集合结果：追加操作应反映在长度和尾部成员中
redis-cli -p 6390 LLEN restore:events
redis-cli -p 6390 LRANGE restore:events -2 -1

# 检查过期边界：只记录 TTL 是否仍在合理区间，不要求精确相等
redis-cli -p 6390 TTL restore:session

检查表可以这样记录：固定值用于确认基础加载，覆盖值用于确认 AOF 尾部，删除键用于确认命令重放，列表用于确认追加顺序，TTL 用于确认恢复时刻和过期语义。若只查几个普通 GET，很容易漏掉“服务可用但增量没有生效”的问题。

四、截断和损坏要分开处理

如果 Redis 日志提示 AOF 末尾 short read，通常代表最后一条命令没有完整写入。较新的 Redis 可以在 aof-load-truncated yes 时丢弃最后一条不完整命令并继续启动，但这意味着恢复结果可能少最后一个写入，必须结合业务可接受的数据窗口判断。

如果损坏出现在文件中间，启动会因 bad file format 失败。此时先保留原文件副本，再不带修复参数运行 redis-check-aof 观察偏移位置；确认影响后，才考虑对副本使用 --fix。修复可能丢弃损坏点之后的 AOF 内容，不能把它当作无损恢复。

# 先只读分析副本，避免直接修改原始持久化文件
cp appendonlydir/appendonly.aof.manifest /tmp/restore.manifest.copy
redis-check-aof appendonlydir/appendonly.aof.1.incr.aof

# 只有确认损坏范围并接受数据损失后，才在副本上尝试修复
cp appendonlydir/appendonly.aof.1.incr.aof /tmp/incr.aof.fix-copy
redis-check-aof --fix /tmp/incr.aof.fix-copy

相关问题

同时有 dump.rdb 和 AOF 时一定加载 RDB 吗？

不一定。开启 AOF 时，Redis 通常优先用 AOF 重建，因为它代表更完整的状态；dump.rdb 仍然适合独立备份和快速灾备。

只检查 Redis 能否启动够不够吗？

不够。至少要核对覆盖、删除、集合长度和 TTL，这些结果才能证明 AOF 增量和时间边界都被正确处理。

每秒同步是否代表绝对不丢数据？

不是。appendfsync everysec 是性能与持久性的折中，故障时仍可能损失最近一小段尚未同步的数据，具体窗口要通过演练和监控确认。