目的:
我正在尝试每 X 次制作 dump.rdb 和每 Y 次 appendonly.aof 的备份副本，因此如果文件因任何原因(甚至只是 AOF 的 appendonly.aof 文件)损坏，我可以从转储中恢复我的数据。 rdb.backup 快照，然后是其他任何更改，因为我拥有 appendonly.aof.backup 的最新副本。
情况:
我每 5 分钟备份一次 dump.rdb，每 1 秒备份一次 appendonly.aof。
问题:
1) 由于 dump.rdb 在后台被子进程写入临时文件 - 子进程创建新图像时发生的关键更改会发生什么？我知道无论后台写入如何，AOF 文件都会继续追加，但是新的 dump.rdb 文件是否也包含关键更改？
2)如果 dump.rdb 不包含关键更改，有没有办法找出子进程被 fork 的确切点？这样我就可以跟踪 AOF 文件将拥有最新信息的时间点。
谢谢!
最佳答案
通常，人们使用 RDB 或 AOF 作为持久化策略。拥有这两个是相当昂贵的。每 5 分钟运行一次转储，每秒复制一次 aof 文件听起来非常频繁。除非 Redis 实例仅存储少量数据，否则您可能会杀死机器的 I/O 子系统。
现在，关于您的问题:
1) RDB 机制的语义
转储机制利用了现代操作系统内核在克隆/ fork 过程中实现的写时复制机制。当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% 准确)。