如何备份Redis服务器的RDB和AOF文件以便恢复，以确保最小化数据丢失？

Question

目的：

我想每隔X时间备份dump.rdb和每隔Y时间备份appendonly.aof，这样如果文件因为任何原因被损坏（甚至只是AOF的appendonly.aof文件），我就可以从dump.rdb.backup快照中恢复我的数据，然后再将最近的appendonly.aof.backup副本的数据应用到它上面。

现状：

我每5分钟备份一次dump.rdb，并且每秒备份一次appendonly.aof。

问题：

1）由于dump.rdb正在后台通过子进程写入临时文件，当子进程创建新镜像时发生的键值更改会发生什么？我知道AOF文件将继续追加，而不受后台写入的影响，但新的dump.rdb文件是否包含键值更改？

2）如果dump.rdb不包含键值更改，是否有某种方法可以找出子进程被分叉的确切点？这样我就可以跟踪在该点之后AOF文件将具有最新的信息。

谢谢！

- lisa188

Answer 1

通常，人们使用RDB或AOF作为持久化策略之一。同时使用两种方式代价相当高昂。每5分钟运行一次dump操作并每秒复制一次aof文件听起来非常频繁。除非Redis实例只存储少量数据，否则很可能会破坏您的I/O子系统。

现在，关于你的问题：

1）RDB机制的语义

转储机制利用了现代操作系统内核在克隆/分叉进程时实现的写时复制机制。当分叉完成后，系统只需通过复制页面表创建后台进程。页面本身在两个进程之间共享。如果Redis进程对页面执行写操作，则操作系统将自动复制页面（因此Redis实例具有自己的版本，而后台进程具有以前的版本）。因此，后台进程保证内存结构保持不变（因此保持一致）。

结果是，在fork之后开始的任何写操作都不会被捕获到dump中。dump是在fork时间拍摄的一组一致快照。

2）跟踪fork点

您可以通过运行INFO persistence命令并计算rdb_last_save_time-rdb_last_bgsave_time_sec来估计fork时间戳，但这不是非常准确（仅为秒级）。

要更加精确（毫秒级），您可以解析Redis日志文件以提取以下行：

[3813] 11 Apr 10:59:23.132 * Background saving started by pid 3816

您需要至少具备“notice”日志级别才能看到这些行。

据我所知，目前没有办法将AOF中的特定条目与RDB的fork操作相关联（即不可能100％准确）。

- Didier Spezia