redis持久化策略AOF和RDB优缺点对比

原文地址

redis提供了不同范围的持久化选选项

• RDB
• AOF
• 如果数据存在时间少，可以两者都不用
• 在同一个实例中合并AOF和RDB是可能的。注意，在这种情况下，当Redis重新启动AOF文件将被用来重建原始数据集，因为它被保证是最完整的。

需要理解的最重要的事情是RDB和AOF持久性之间的不同权衡。让我们从RDB开始:

RDB 的好处：

• RDB是一个非常紧凑的单文件时间点表示你的Redis数据。RDB文件是完美的备份。例如，您可能希望在最近的24小时内每小时归档一次RDB文件，并在30天内每天保存一次RDB快照。这允许您在发生灾难时轻松恢复数据集的不同版本。
• RDB非常适合灾难恢复，它是一个简单的压缩文件，可以传输到很远的数据中心，或者传输到Amazon S3(可能是加密的)。
• RDB最大限度地提高了Redis的性能，因为Redis父进程需要做的唯一的工作就是派生一个子进程来完成剩下的工作。父实例永远不会执行磁盘I/O或类似的操作。
• 与AOF相比，RDB允许以更快的速度重启大数据集。

RDB 的坏处：

• 如果你需要最小化Redis停止工作时的数据丢失的机会(例如停电后)，RDB是不好的。您可以在生成RDB的地方配置不同的保存点(例如，在至少5分钟之后，对数据集进行100次写操作，但是您可以有多个保存点)。然而，你通常会每五分钟或更久创建一个RDB快照，所以如果Redis停止工作而没有正确的关机，你应该做好丢失最新分钟数据的准备。
• RDB通常需要fork()，以便使用子进程在磁盘上持久存储。如果数据集很大，Fork()会很耗时，如果数据集很大，CPU性能不太好，Redis可能会停止为客户端服务几毫秒甚至一秒。AOF也需要fork()，但是您可以调优重写日志的频率，而不需要牺牲持久性

AOF 的好处：

• 使用AOF Redis更持久:你可以有不同的fsync策略:完全不fsync，每秒fsync，每次查询fsync。使用fsync的默认策略，每秒写操作的性能仍然很好(fsync是在后台执行的，主线程会在没有fsync的情况下努力执行写操作)，但是你只能损失1秒的写操作。
• AOF日志是一个仅追加的日志，因此如果出现断电，则不存在查找或损坏问题。即使由于某些原因(磁盘已满或其他原因)，日志以写了一半的命令结束，redis-check-aof工具也能够轻松地修复它
• 当AOF变得太大时，Redis能够在后台自动重写AOF。重写是完全安全,复述,继续追加到旧文件,产生一个全新的最小集合操作需要创建当前数据集,而一旦准备复述,开关的两个和第二个文件附加到新的一个开始。
• AOF以易于理解和解析的格式依次包含所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使你刷新了所有的错误使用冲洗大厅命令，如果没有重写日志，在此期间，你仍然可以保存你的数据集，只要停止服务器，删除最新的命令，并重新启动Redis再次。

AOF 的坏处：

• 对于相同的数据集，AOF文件通常比等效的RDB文件大。
• 根据fsync的具体策略，AOF可能比RDB慢。一般情况下，fsync设置为每秒的性能仍然很高，禁用fsync后，即使在高负载下，它的速度也应该和RDB一样快。尽管如此，RDB仍然能够提供更多关于最大延迟的保证，即使是在一个巨大的写负载的情况下。
• 过去，我们在特定命令中遇到过罕见的错误(例如，有一个涉及到BRPOPLPUSH等阻塞命令的错误)，导致生成的AOF在重新加载时不能复制完全相同的数据集。这些错误很少见，我们在测试套件中进行了测试，自动创建随机复杂数据集并重新加载它们，以检查一切是否正常。然而，对于RDB持久性来说，这些类型的错误几乎是不可能的。为了更清楚地说明这一点:Redis AOF通过增量地更新现有状态来工作，就像MySQL或MongoDB那样，而RDB快照则一次又一次地从头创建一切，这在概念上更健壮。然而- 1)需要注意的是,每次AOF是重写的复述,从头重新创建从实际数据中包含的数据集,使错误更强而总是附加阻力AOF文件(或一个重写阅读旧AOF代替阅读数据在内存中)。2)在现实世界中，我们从来没有收到过一个来自用户的关于AOF腐败的报告。

好，那我们怎么选择呢？

一般的指示是，如果你想获得与PostgreSQL相当的数据安全性，你应该同时使用这两种持久性方法。

如果您非常关心您的数据，但是在发生灾难时仍然可以忍受几分钟的数据丢失，那么您可以只使用RDB。

有许多用户单独使用AOF，但我们不鼓励这样做，因为不时地使用RDB快照对于进行数据库备份、加快重启速度以及在AOF引擎出现错误时都是一个好主意。

注意:由于所有这些原因，未来我们可能会将AOF和RDB统一为一个单一的持久性模型(长期计划)。

下面几节将说明关于这两个持久性模型的更多细节。

快照

save 60 1000

快照怎么工作的呢？

• redis forks。现在我们有了一个子进程和一个父进程。
• 子程序开始将数据集写入临时RDB文件。
• 当子程序写完新的RDB文件后，它将替换旧的RDB文件。

只追加文件

快照不是很持久。如果你的电脑运行Redis停止，你停电，或你意外kill -9你的实例，最新的数据写入Redis将丢失。虽然这对一些应用来说可能不是什么大问题，但也有完全持久性的情况，在这些情况下，Redis不是一个可行的选择。
只添加文件是Redis的另一种完全持久的策略。它在版本1.1中可用。
您可以在配置文件中打开AOF:

appendonly yes

从现在开始，每当Redis收到一个命令，改变数据集(例如，SET)，它将把它附加到AOF。当你重启Redis时，它会重新播放AOF来重建状态。

日志重写

可以猜到，随着执行写操作，AOF变得越来越大。例如，如果您将一个计数器递增100次，您将在数据集中得到一个包含最终值的键，但是在您的AOF中有100个条目。重建当前状态不需要其中99个条目。
因此，Redis支持一个有趣的功能:它能够在后台重建AOF，而不中断对客户的服务。每当你发出一个BGREWRITEAOF Redis将写最短的命令序列需要在内存中重建当前的数据集。如果你使用的AOF与Redis 2.2，你将需要运行BGREWRITEAOF的时间。Redis 2.4能够自动触发日志重写(更多信息请参见2.4示例配置文件)。

只追加的文件有多持久?

你可以配置多少次Redis将fsync数据在磁盘上。有三种选择:

• appendfsync always: 每次一个新命令被附加到AOF时，都使用fsync。非常非常慢，非常安全。
• appendfsync everysecond: fsync every second。足够快(在2.4中可能和快照一样快)，如果发生灾难，你可能会损失1秒的数据。
• appendfsync no: fsync，只是把你的数据放在操作系统手中。更快更不安全的方法。对于这种配置，Linux通常每30秒刷新一次数据，但这取决于内核的精确调优。

建议的(和默认的)策略是每秒进行fsync。它既快又安全。always策略实际上很慢，但是它支持组提交，所以如果有多个并行写操作，Redis会尝试执行一个fsync操作。

如果我的AOF被截断了该怎么办?

可能是服务器在写入AOF文件时崩溃了，或者存储AOF文件的卷在写入时已经满了。当这种情况发生时，AOF仍然包含一致的数据，表示给定时间点版本的数据集(在默认的AOF fsync策略下，该数据集可能会旧到一秒)，但是AOF中的最后一条命令可能会被截断。最新的主要版本的Redis将能够加载AOF无论如何，只是丢弃了最后的非良好格式的命令在文件。在这种情况下，服务器将发出如下日志:

* Reading RDB preamble from AOF file...
* Reading the remaining AOF tail...
# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 439 !!!
# AOF loaded anyway because aof-load-truncated is enabled

你可以改变默认配置，强制Redis停止在这种情况下，如果你想，但默认的配置是继续不管事实，最后的命令在文件中不是良好的格式，以确保可用后重新启动。
旧版本的Redis可能无法恢复，并可能需要以下步骤:

• 把你的AOF文件备份一份。
• 修复原始文件使用Redis -check-aof工具:
  $ redis-check-aof --fix
• 可以选择使用diff -u检查两个文件之间的差异。
• 用固定的文件重新启动服务器。

如果我的AOF损坏了怎么办?

如果AOF文件不仅被截断了，而且中间还被无效的字节序列破坏了，那么事情就更复杂了。Redis将在启动时抱怨，并将中止:

* Reading the remaining AOF tail...
# Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>

最好的办法是运行redis-check-aof实用程序,最初没有——fix 选项,然后理解问题,跳在给定的文件中抵消,看看是否可以手动修复文件:AOF使用相同的格式协议和非常简单的复述,手动修复。否则可以让工具修复文件,但在这种情况下所有的AOF部分无效的部分文件的末尾可能被丢弃,导致大量数据丢失如果腐败发生在最初的文件的一部分。

它是如何运作的

日志重写使用了快照中已经使用的“写时复制”技巧。它是这样工作的:

• Redis分叉，所以现在我们有一个子进程和一个父进程。
• 子程序开始在一个临时文件中写入新的AOF。
• 父程序将所有新更改累加到内存缓冲区中(但同时它将新更改写入旧的仅添加文件中，因此如果重写失败，我们是安全的)。
• 当子程序完成重写文件时，父程序将得到一个信号，并将内存中的缓冲区追加到子程序生成的文件的末尾。
• 利润!现在Redis自动将旧文件重命名为新文件，并开始向新文件添加新数据。

我如何可以切换到AOF，如果我目前使用转储。rdb快照?

在Redis 2.0和2.2中有一个不同的过程来做这个，你可以猜到它在Redis 2.2中更简单，不需要重启。

AOF和RDB持久性之间的交互

Redis >= 2.4确保在RDB快照操作已经在进行时避免触发AOF重写，或者在AOF重写在进行时允许BGSAVE。这可以防止两个Redis后台进程在同一时间做重磁盘I/O。
当快照进行时，用户使用BGREWRITEAOF显式地请求一个日志重写操作，服务器会回复一个OK状态码，告诉用户操作已经安排好了，当快照完成时，重写将开始。
在AOF和RDB持久性都被启用和Redis重启的情况下，AOF文件将被用来重建原始数据集，因为它被保证是最完整的。

备份Redis数据

在开始本节之前，请务必阅读以下句子:确保备份数据库。磁盘损坏，云中的实例消失，等等:没有备份意味着数据消失到/dev/null.的巨大风险

复述,非常数据备份以来友好你可以复制RDB文件在数据库运行时:RDB从不修改一旦产生,就产生了它使用一个临时名称和重命名为最终目的地自动使用重命名(2)只有当新快照就完成了。

这意味着在服务器运行时复制RDB文件是完全安全的。以下是我们的建议:

• 在服务器上创建cron作业，每小时在一个目录中创建RDB文件的快照，在另一个目录中创建每日快照。
• 每次运行cron脚本时，请确保调用find命令，以确保删除太旧的快照:例如，可以为最近48小时拍摄每小时的快照，为一两个月拍摄每日快照。请确保使用数据和时间信息为快照命名。
• 每天至少有一次，确保将RDB快照转移到数据中心之外，或者至少转移到运行Redis实例的物理机器之外。

如果你运行一个仅启用AOF持久性的Redis实例，你仍然可以复制AOF来创建备份。该文件可能缺少最后的部分，但Redis仍将能够加载它(参见前面的部分截断的AOF文件)。进入翻译页面。

灾难复原

Redis环境下的isaster恢复基本上和备份是一样的，再加上在许多不同的外部数据中心传输这些备份的能力。通过这种方式，即使在某些灾难性事件影响Redis运行和生成快照的主要数据中心的情况下，数据也是安全的。
由于许多Redis用户还处于起步阶段，因此没有足够的资金，我们将介绍一些成本不高的最有趣的灾难恢复技术。

• Amazon S3和其他类似的服务是实现灾难恢复系统的好方法。只需以加密的形式将每日或每小时的RDB快照传输到S3。您可以使用gpg -c(在对称加密模式下)加密数据。确保把你的密码保存在许多不同的安全的地方(例如，给你组织中最重要的人一份副本)。建议使用多种存储服务来提高数据安全性。
• 使用SCP (SSH的一部分)将快照传输到远端服务器。这是一个相当简单和安全的路径:在离您很远的地方获得一个小VPS，在那里安装ssh，并生成一个不带密码的ssh客户机密钥，然后将其添加到您的小VPS的authorized_keys文件中。您已经准备好以自动方式传输备份。在两个不同的供应商获得至少两个VPS以获得最佳结果。

如果不以正确的方式实现，这个系统很容易失败，理解这一点很重要。至少确保在传输完成后，您能够验证文件大小(应该与您复制的文件大小匹配)，如果您使用VPS，还可能验证SHA1摘要。
如果新备份的传输由于某种原因无法工作，您还需要某种独立的警报系统。