我正在使用组合模式 - RDB + AOF。
我正在寻找一种从 RDB 文件重新启动后加载的方法 - 主要用于快速重新启动。
最重要的是，我想继续编写 AOF。
一旦知道有灾难发生，我会从 AOF 手动加载。
这是我当前的配置：（我知道appendonly yes 说AOF 将在重启后加载，我正在寻找RDB 的等待加载并继续编写AOF。）
aof-use-rdb-preamble yes
aof-load-truncated yes
aof-rewrite-incremental-fsync yes
appendfilename "appendonly.aof"
appendfsync everysec
appendonly yes
谢谢
【问题讨论】：
标签： redis persistence
如果两者都启用，Redis 将始终加载 AOF，因为 AOF 为您提供更好的持久性。
通过使用aof-use-rdb-preamble yes，您已经获得了两全其美的效果。您的 AOF 会不时地自动重写，首先是 RDB 文件，然后是 AOF 尾部。见redis.conf L1157。
由于您希望获得可预测的平均恢复时间 (MTTR)，因此您希望调整自动重写 AOF 的参数，如 redis.conf LL113 中所述
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
您也可以使用 BGREWRITEAOF command 手动触发 AOF 重写
即使appendonly 配置为no，BGREWRITEAOF 也可以工作。但是，请注意，每次调用 BGREWRITEAOF 时，您都会在 appendonly.aof 文件中获得一个 rdb 文件。
然后，如果将appendonly 配置为yes，您还会得到一个 AOF 尾部（命令附加到 appendonly.aof 文件中）。
BGREWRITEAOF 和 BGSAVE 是昂贵的操作，并且会在运行时降低服务器的性能。所以我建议你只使用 AOF，它已经自动或每次运行 BGREWRITEAOF 时都可以为你提供日志压缩。
您可以将auto-aof-rewrite-percentage 设置为较低的值，例如 2% 或 5%。然后，您可以使用这两种策略测试 MTTR（重新启动所需的时间）。我相信您会发现差异太小，无法将这两种策略（RDB 和 AOF）分开组合。如果aof-use-rdb-preambleyesyes，AOF 已经为您提供了 RDB-inside
【讨论】：
BGREWRITEAOF 命令和appendonly no 会导致系统从RDB 加载并继续写入AOF？