Redis持久化

Redis Persistence

 

转载▼

Redis 为持久化（latteye注：可以简单的理解为存储）提供了不同的方案：

• RDB 持久化提供了以某个周期时间为节点，对数据快照的方案。
• AOF 持久化方案记录了所有服务器接收到的指令。并可以在服务器启动时将指令重新加载，从而重构原始的数据库。Redis 用和它协议相同的方式来记录这些指令，同时命令的记录是不断添加的（append-only）。当 log 过于庞大时 Redis 可以在后台对其进行重写。
• 如果你只希望数据库运行的时候保存数据，你可以关闭持久化选项。
• AOF 和 RDB 可以在一个实例中合起来用。注意，在这种情况下，当服务器重启时，是由 AOF 来重构数据库的。因为 AOF 对数据的保障性更加可靠。

最重要的是理解 RDB 和 AOF 之间的区别，从而能权衡两者。让我们先来看 RDB 吧：

RDB 的优势

• RDB 是一种以时间点为基准(point-in-time)且使用单文件(single-file)的数据重现方式。RDB 文件非常适合用来备份。比如你希望在最近的24小时，每小时对数据做一次快照，且最近30天，每天保留一份快照。RDB 让你非常方便的从灾难中恢复数据到任意一个时间点。
• RDB 非常适合灾难恢复。单文件存储的方式非常适合将文件传输到远程的数据中心，或者备份在 Amazon S3 上（最好加密哦）。
• RDB 可以让性能最大化。Redis 父进程只需要派生出一个子进程来管理即可，其父进程永远都不需要执行磁盘 I/O 相关的操作。
• 在你的数据库文件较大时，RDB 提供比 AOF 更快的重启速度。

RDB 的劣势

• 如果你希望在 Redis 异常退出时（比如断电了）最小化数据损失，Redis 并不是你最好的选择。你可以在部署了RDB的机器上配置不同的保存点（对于实例来说至少等待5分钟且写入数据次数超过100次，不过你可以设置多个保存点）。无论如何，你通常会每五分钟创建一个或多个快照，所有当 Redis 非正常关闭的时候你应该会丢失几分钟的数据。
• 由于需要经常操作磁盘，RDB 会经常 fork()出一个子进程。如果你的数据库文件很大的话，Fork()占用比较多的时间，并且可能会影响 Redis 暂停服务一段时间（millisecond 级别），如果你的数据库超级大并且你的CPU比较弱，有可能是会达到一秒。AOF 同样需要 fork()，但你可以调整重写的频率来协调性能和数据的保障性。

AOF 的优势

• 在 Redis 使用 AOF 更加持久化：你可以使用不同的 fsync 策略：完全不做 fsync，每秒 fsync，每一个请求 fsync。使用默认的每秒 fsync 模式时，性能依旧是非常好的。（主进程在后台没有 fsync 在执行的时候会尽量的做写操作），而且你只会丢失最多一秒的数据。
• AOF 日志是一个不断添加的日志（append only），所有它不可以搜索，同时即使在机器电源故障的情况下日志也不会损坏。即使有一条命令写到一半的时候失败了，redis-check-aof 工具也可以很方便的修复日志。
• 当日志过大的时候，Redis 可以在后台重写 AOF 日志。整个重写过程是安全的，当 Redis 创建新的准备新的 log 文件时，它依旧往旧的日志里面写入数据。同时，它会根据当前的数据库创建一个新的、最小的日志文件。当这些都完成时，Redis 将两个日志文件交换，并将些的log记录在新的文件上。
• AOF 用一种简单的格式逐一记录了所有的操作。你甚至可以方便的导出一个 AOF 文件。如果你在一台实例上误输入了 FLUSHALL 命令，在日志文件被重写之前，你可以简单的停止你的服务器，在日志文件中删除最后的 FLUSHALL 命令，然后重启 Redis，之前被删除的数据依旧在那里。

AOF 的劣势

• 对于等量的数据库来说 AOF 产生的文件比 RDB 要大。
• 根据 fsync 策略的不同，AOF 有可能比 RDB 要慢。通常使用每秒 fsync 一次的性能还是比较高的。如果你关闭 fsync， AOF 的性能即使在高负载下应该和 RDB 一样高。当然，在高磁盘负载时还是 RDB 相对能提供比较稳定的延时效果。
• 曾经有一些命令（for instance there was one involving blocking commands like BRPOPLPUSH）会导致一些罕见的 bug — AOF 在启动的时候会不重新加载原有数据。这样的 bug 很少见，我们在一套测试环境中进行了测试。我们自动创建了一些大量的随机数据，然后重新加载数据库，看看一切是否正常。不过 RDB 环境下面机会不会出现这种 bug。让我们明确的看一下：Redis AOF 通过一种不断增长式的方式来更新数据。而 RDB 在一个基础上不断的创造快照，这种方式更加强壮。但是 1) 需要注意的是，Redis 每一次重写 AOF 时，都是从一个数据文件中真实的数据重写而来。相对不断的添加数据到 AOF 文件（or one rewritten reading the old AOF instead of reading the data in memory），这种方式产生 bug 的几率更小。2）在实际应用中从来没有收到过 AOF 损坏的报告。

OK ，到底选择什么呢？

通常，如果你要和 PostgreSQL 所提供的数据保障性相比较，那么建议你同时使用两种持久化方式。

如果你非常在意你的数据，但是也还可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用 RDB。

很多用户仅使用了 AOF，但是我们建议，既然 RDB 可以时不时的给数据做个完整的快照，并且提供更快的重启，而且在某些情况下 bug 也要少，你最好还是使用 RDB。

注：综合以上原因，我们希望可以在未来（长远计划）统一 AOF 和 RDB 成一种持久化模式。

下面的章节将以实例来介绍两种持久化方式的更多细节。

快照

默认情况下，Redis 在磁盘上以二进制格式保存数据快照，名为 dump.rdb。你可以配置 Redis 每 N 秒且至少有 M 次 数据修改则保存一次数据，或者你可以手动通过 SAVE 或者 BGSAVE 命令来执行保存。

比如，这个配置会让 Redis 每 60 秒且至少有 1000 次 key 修改，则保存一次数据：

save 60 1000

这种策略被成为 快照(snapshotting)

它怎么工作？

当Redis需要将数据导出到磁盘时，发生了以下事情：

• Redis 派生出一个子进程。我们现在有一个子进程和一个父进程。
• 子进程开始将数据写入一个临时的 RDB 文件。
• 当子进程写完新的 RDB 文件后，用新的 RDB 文件替换旧的。

这种工作方式允许 Redis 使用到 copy-on-wirite 带来的优势。

Append-only 文件

快照的持久化非常可靠。如果你的 Redis 突然停止、你的电源突然坏了、或者你意外的 kill -9 了你的进程，最后写入 Redis 的那些数据都会丢失。对某些应用来说，这可能不是什么大问题，还有很多的方式来保障数据可靠性，在那些情况下 Redis 并不是很好的选择。

append-only 文件是另一个可以提供完全数据保障的方案。这种技术自 1.1 版本启用。

你可以在配置中打开 AOF 功能：

appendonly yes

配置以后，只要是 Redis 接收到的会修改数据库的命令就会被记录在 AOF 文件中。当你重启 Redis 之后，它会重复 AOF 中的指令从而来重现数据最新的状态。

日志重写

和你想的一样，AOF 文件会在操作过程中变得越来越大。比如，如果你做一百次加法计算，最后你只会在数据库里面得到最终的数值，但是在你的 AOF 里面会存在 100 次记录。其中 99 条记录对最终的结果是无用的。

所以 Redis 支持一个很有趣的功能：他可以在不影响服务的前提下在后台重构 AOF 文件。当你输入 BGREWRITEAOF 命令时，Redis 会在内存中按最简短的排序整理所有的指令。如果你在使用 Redis 2.2 你需要是不是的跑一下 BGREWRITEAOF 命令。而 Redis 2.4 已经支持自动进行重新工作(更多信息请查看 2.4 文档。)

Append Only 文件到底有多可靠?

你可以配置 Redis 如何将数据 fsync 到磁盘上。有以下几种选项。

• 每当有命令请求时，fsync。非常安全，非常非常慢。
• 每秒做一次fsync。足够快了（在 2.4 版本中几乎和快照模式一样快。）,而在遇到灾难时，你可能会丢失最近1秒的数据。
• 永远不做 fsync，仅仅只是把数据放在系统中，非常快，但是却不安全的方式

建议的（且默认的）模式是每秒同步一次。这是坚固速度和安全的方式。一有命令就记录的方式在以前是很慢的(尽管在2.0版本中有所提升) - 没什么办法让 fsync 更快了。

当 AOF 文件损坏时，应该怎么做？

AOF 在服务器崩溃的时候是有可能损坏的（这永远没办法解决），Redis 无法加载已经损坏的文件。如果你遇到了这种情况，你可以通过以下的步骤来修复问题：

• 给AOF文件做个备份。
• 用 Redis 随身带的 redis-check-aof 命令来修复原始文件：

• $ redis-check-aof --fix "filename"

• 用 diff -u 来比较两个文件之间的区别(非必须)
• 用修复过的文件来重启服务器。

它如何工作的？

日志重写用了和快照一样的 copy-on-write 技术。以下是他工作的方式：

Redis 派生出一个子进程，于是我们一个父进程和一个子进程了。

• 子进程开始在一个临时文件写入 AOF 信息。
• 父进程将所有的新指令积蓄在内存中(在同一时刻，它也将指令记录在了老 AOF 文件中，这样即使重写过程失败了，我们也是安全的。)
• 当子进程重写完文件之后，父进程会获取到一个信号，然后将内存中积累的数据由子进程写入到文件中去。
• 搞定！现在Redis 自动将文件名修改，以后就将数据添加到新文件中了。

如果我正在使用 RDB 快照，怎么才能切入到AOF呢？

在2.2和2.0版本中，这个操作略有不同。当然，我相信你可以猜到，2.2中的操作要简单一些，且不要求重启。

Redis >= 2.2

• 给你最新的 dump.rdb 文件做一个备份。
• 将这个备份文件保存到一个安全的地方。
• 输入下面两个命令：
• redis-cli config set appendonly yes
• redis-cli config set save ""
• 确认一下你的数据库 key 的数量没有变化。
• 确认一下新的记录已经记录到了正确的文件。

第一个 CONFIG 命令启用了 Append Only 文件。Redis 会按照顺序先先初始化一个文件，接着打开这个文件给 AOF 写入，然后会将所有的请求写入 AOF 文件。

第二个 CONFIG 命令 是用来关闭快照持久化模式。这不是必须的，如果你想要，你可以同时使用两种持久化模式。

重要：记得在你的 redis.conf 文件中开启 AOF，不然的话一旦你重启服务器，服务器会按照以前的配置工作了。

Redis 2.0

• 备份你最新的 dump.rdb 文件。
• 将备份文件放到安全的地方。
• 停止一切数据库写入操作。
• 执行 redis-cli bgrewriteaof 命令。这将创建一个 append only 文件.
• 当 Redis 完成创建 AOF dump 文件之后停止服务器。
• 编辑 redis.conf 文件以开启 AOF 持久化选项。
• 重启服务器。
• 确认你的数据没有少。
• 确认所有请求已经记录到了正确的 AOF 文件。

整合 RDB 和 AOF 两种持久化模式

Redis >= 2.4 确保了在 RDB 做快照的过程中不会触发一个 AOF 重写动作，反之亦然。这避免了两种持久化同时触发高I/O的工作。

当快照正在处理时，如果用户手动执行了 BGREWRITEAOF 命令，服务器会立刻返回一个 OK。这表示重写动作已经在排队，当快照完成之后就会执行 AOF 重写。

如果你同时启用了 AOF 和 RDB，在 Redis 重启的时候，系统会使用 AOF 文件来重构数据库。这是因为 AOF 相对更加可靠。

备份Redis数据

在开始本章之前，请先读读下面这句话：一定要备份你的数据库。磁盘损坏，实例莫名其妙的消失，这相当于：将你大量的数据都写入到 /dev/null。

Redis 是一款非常易于备份的数据库 -- 你可以在 Redis 运行的时候拷贝 RDB 文件。RDB 文件绝对不会在拷贝的时候被修改，在拷贝的过程中，他会使用一个临时的文件名。只有在快照完全结束时，才会用 rename(2) 将其改为最终的名字。(and while it gets produced it uses a temporary name and is renamed into its final destination atomically using rename(2) only when the new snapshot is complete.)

这表示在服务器运行的时候拷贝RDB文件是一件绝对安全的事情。以下是我们的建议：

• 用 crontab 每小时为数据库创建一次快照，另在别处保留每日快照。
• 每次 crontab 执行的时候，用 find 命令寻找老的快照并删除。保留最近48小时的每小时快照，保留1-2个月的每日快照。用日期以及时间信息来命名这些文件。
• 每天至少将这些文件转移一次到别的机房，至少转移出那台物理机器。

灾难恢复

在此文中灾难恢复可以理解为和备份一样的工作，外加将备份的文件转移至其他不同的机房。这样即使在 Redis 所在的机房遇到严重的灾难时，你依旧可以使用它的快照来恢复数据。

由于大多数 Redis 的用户都处于起步阶段，估计并没有太多的钱花在灾难恢复上，我们来看看比较有趣且便宜的方案吧：

Amazon S3 和其他类似的服务非常作为您的灾难恢复系统。你只要将你的每日备份简单的放在 S3 的加密区域。你可以使用 gpg -c 来加密你的数据。并且确保将密码保存在多个安全的地方（可以分发给你公司里比较重要的人）。我们建议同时使用多个外部存储服务来保障数据安全。

使用 scp (ssh 的一部分) 将数据传输到可信的服务器。下面是个简单而且安全的方式：在距离你很远的地方弄台VPS，装上 ssh，最好是一个仅用密钥登陆且无密码的配置。这样就可以很方便的自动传输备份文件了。最好在不同的商家那里多买点 VPS。

请注意！如果你没有按照正确的方式部署，这种方式还是很容易失败的。至少在完成传输以后请用 SHA1 sum 验证文件是否正确。