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

Question

目的:

我正在尝试每 X 次制作一次 dump.rdb 和每 Y 次 appendonly.aof 的备份副本，这样如果文件由于任何原因(或者甚至只是 AOF 的 appendonly.aof 文件)损坏，我可以从中恢复我的数据dump.rdb.backup 快照，然后是自从我拥有最新的 appendonly.aof.backup 副本以来发生的任何其他更改。

情况:

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

问题:

1) 由于子进程在后台将 dump.rdb 写入临时文件 - 当子进程创建新图像时发生的关键更改会发生什么？我知道无论后台写入如何，AOF 文件都会继续追加，但新的 dump.rdb 文件是否也包含关键更改？

2) 如果 dump.rdb 不包含关键更改，是否有某种方法可以找出子进程被 fork 的确切位置？这样我就可以跟踪 AOF 文件将拥有最新信息的时间点。

谢谢!

Answer 1

通常，人们要么使用RDB，要么使用AOF作为持久化策略。拥有他们两个是相当昂贵的。每 5 分钟运行一次转储，每秒复制一次 aof 文件听起来非常频繁。除非 Redis 实例仅存储少量数据，否则您可能会杀死盒子的 I/O 子系统。

现在，关于您的问题:

1)RDB机制的语义

转储机制利用现代操作系统内核在克隆/派生过程中实现的写时复制机制。当fork完成后，系统只是通过复制页表来创建后台进程。页面本身在两个进程之间共享。如果 Redis 进程在页面上进行了写操作，操作系统将透明地复制该页面(因此 Redis 实例有自己的版本，后台进程有以前的版本)。因此，后台进程可以保证内存结构保持不变(因此是一致的)。

结果是在 fork 之后开始的任何写操作都不会被转储。转储是在 fork 时拍摄的一致快照。

2) 跟踪 fork 点

可以通过运行INFO持久化命令，计算rdb_last_save_time - rdb_last_bgsave_time_sec来估计fork时间戳，但不是很准确(仅次于第二)。

为了更加准确(毫秒)，您可以解析 Redis 日志文件以提取以下行:

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

您至少需要“通知”日志级别才能看到这些行。

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