4

目的：

我正在尝试每 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 不包含关键更改，有没有办法找出子进程被分叉的确切点？这样我就可以跟踪 AOF 文件将拥有最新信息的时间点。

谢谢！

4

1 回答 1

2

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

现在，关于您的问题：

1）RDB机制的语义

转储机制利用现代操作系统内核在克隆/分叉过程中实现的写时复制机制。分叉完成后，系统只是通过复制页表来创建后台进程。页面本身在两个进程之间共享。如果 Redis 进程对某个页面进行了写操作，操作系统会透明地复制该页面（这样 Redis 实例就有自己的版本，而后台进程是之前的版本）。因此，后台进程保证了内存结构保持不变（因此是一致的）。

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

2) 跟踪分叉点

可以通过运行 INFO 持久化命令并计算 rdb_last_save_time - rdb_last_bgsave_time_sec 来估计分叉时间戳，但它不是很准确（仅第二个）。

为了更准确（毫秒），您可以解析 Redis 日志文件以提取以下行：

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

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

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

于 2013-04-11T09:05:03.623 回答