Redis RDB 和 AOF

导读

RDB 和 AOF 对比：

持久化方式选择

如果对数据安全性要求极高，应该同时使用两种持久化方式。

如果可以承受若干时间内的数据丢失，可以只使用 RDB 持久化。

不建议只使用 AOF 持久化，因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度要比 AOF 恢复的速度要快。

RDB 和 AOF 的恢复优先级

如果 Redis 同时使用 RDB 和 AOF 持久化，Redis 会优先使用 AOF 进行恢复数据。

在启动 Redis 时，如果已经存在了 appendonly.aof 文件，则基于 appendonly.aof 文件恢复数据；如果不存在 appendonly.aof 文件，则创建一个空的 appendonly.aof 文件，并基于这个空的 appendonly.aof 文件启动。

redis开启rdb和aof后文件正确恢复

正是由于以上的特性，在使用 RDB 恢复数据并切换为使用 RDB + AOF 持久化时需要特别小心，以避免造成数据丢失。现在我需要同时开启aof和rdb两个持久化策略，假如我们直接关闭redis，并且打开aof的开关，此时我们重连redis,会发现上一次保存的数据不见了。

appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的然后我们自己的dump.rdb是有数据的，但是明显没用我们的数据。很简单，就是虽然你删除了appendonly.aof，但是因为打开了aof持久化，redis就一定会优先基于aof去恢复，即使文件不在，那就创建一个新的空的aof文件。

在数据安全丢失的情况下，基于rdb冷备，如何完美的恢复数据，同时还保持aof和rdb的双开？
正确的做法应该是：

• 停止 Redis，关闭 AOF 持久化，保留 RDB 持久化，防止启动时生成 appendonly.aof 文件；
• 拷贝 RDB 文件到数据目录，启动 Redis，启动后 Redis 会使用 RDB 文件恢复数据；
• 确认数据恢复，在命令行热修改配置开启 AOF 持久化 config set appendonly yes；
• 等待 Redis 将内存中的数据写入 appendonly.aof 文件，此时 RDB 和 AOF 数据已同步；
• 停止 Redis，修改配置文件开启 AOF 持久化和 RDB 持久化；
• 启动 Redis，数据恢复和持久化配置完成。

aof文件损坏

那假如aof文件损坏，如何使用rdb文件恢复呢？
我们先删除aof文件，关闭aof配置，再启动redis：发现数据已经恢复（此时是使用rdb来恢复的），并且appendonly.aof文件也没有。此时，我们在redis的客户端执行命令:

 config set appendonly yes

打开aof，此时在aof文件的位置就会生成appendonly.aof文件
注意：在执行启动aof命令的时候，需要在所有的主节点全部执行，此命令只会在执行命令的节点生效。
最后，重启redis，发现数据全部恢复正常，持久化方式也变成了rdb和aof同时执行。