0

我正在运行一个大约 25GB 的 Redismaxmemory实例usage。它像Statefulset在 Kubernetes 中一样运行。因为 redis-pod 可以安排到任何盒子，并且可以在我通过 RDB 进行 AOF 备份时随时重新启动。

但是，昨天redis-pod重新启动，加载数据大约需要5分钟，这让我想到如果数据很大，RDB备份是否更适合？

  • 我知道，AOF 文件的大小可能会过大，并且会自动重写以进行优化。
  • 但即使在 100% 优化的状态下，如果数据库必须重新启动，IMO 将花费全部时间来调用所有将数据填充回 25GB 的命令，这将是耗时的。（大约 5 分钟，我监控）
  • 我想减少这个时间并考虑回到 RDB 快照，尽管数据会丢失，这是快速启动时间的权衡。将 BGSAVE 安排更短的时间，以避免或减少数据丢失。

我想知道，如果数据量很大并且您想避免较慢的启动时间，是否最好使用 RDB 备份？如果每 5 或 10 分钟运行一次 BGSAVE，如果数据量很大（超过 15GB）是否是好习惯？

（对于其他人来说，大数据量可能还不够大，但这是关于启动时间，我很担心，以及它带来的停机时间）

4

1 回答 1

0

我是OP。

不是答案，但想分享一些我在一些实验后收集到的数据

  • 我使用以下命令在 Redis DB 中填充了 16.5GB 的数据 DEBUG POPULATE 165000000 PHPREDIS_SESSION

  • 然后我在 - 的帮助下重写/优化 AOF 文件BGREWRITEAOF。整个操作耗时 209 秒：
    aof_last_rewrite_time_sec:209

  • 刚重写完，我重启了Redis实例，用了3分钟，全部数据恢复到16.5Gb的Redis内存

  • 在此之后，我关闭了 AOF 并启用了 RDB 备份，并调用了BGSAVE开始备份。它花了 202 秒完成：
    rdb_last_bgsave_time_sec:202

  • 在 RDB 备份之后，我再次重启了 Redis 实例，再次用了大约 3 分钟，与 AOF 差不多，整个数据集在 Redis 内存中恢复。

看起来 RDB 和 100% 优化的 AOF 文件将花费或多或少相同的时间来恢复数据。

如果没有优化或重写 AOF，它可能需要更多时间，因为 Redis 将运行更多命令来恢复数据。

我还测试了一个25GB数据的Redis实例的启动时间，开启AOF，恢复数据用了4m30s。

注意：
上面提供的数据仅通过单次迭代获得，而 vanilla Redis 未经任何调整。这些数字可能与其他一些情况或配置不匹配。只是想分享我的发现。

于 2021-09-30T11:19:53.083 回答