Redis - 持久化

标签：

一、RDB 持久化

描述：会在指定的时间间隔内将内存中的数据集快照写入磁盘。

工作机制：

• Redis 调用 fork()。于是我们有了父子两个进程。
• 子进程开始将数据集写入一个临时 RDB 文件。
• 当子进程完成了新 RDB 文件，替换掉旧文件。

优点：

• RDB 文件适合用于备份，是一种表示某个即时点数据集的紧凑文件。例如，你可能想要每小时归档最近 24 小时的 RDB 文件，每天保存近 30 天的 RDB 快照。这允许你很容易的恢复不同版本的数据集以容灾。
• RDB 非常适合于灾难恢复。作为一个紧凑的单一文件，可以被传输到其他设备上。
• 性能最大化。因为 Redis 父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘 IO 这样的操作。
• RDB 在重启保存了大数据集的实例时比 AOF 要快。

缺点：

• 若想保证数据的高可用性能，即最大限度地避免数据丢失，RDB 将不是一个很好的选择。因为每隔一段时间会进行一次备份，若中途出现宕机，那最近的修改就会丢失。
• RDB 经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且 CPU 性能不够强大的话，Redis 会停止服务客户端几毫秒甚至一秒。AOF 也需要 fork()，但是你可以调整多久频率重写日志而不会有损持久性。

二、AOF 持久化（append-on file）

描述：快照并不是非常具有可持久性。如果电脑停机了，电源线断了，最近写入 Redis 的数据将会丢失。所以 AOF 是一个替代方案，是 Redis 的完全可持久性策略。

工作机制：在服务端记录每次收到的写操作，将会被追加到 AOF 中。在服务器启动时会根据这些操作重建原始数据集。

如何开启：

appendonly yes

三种同步方式的配置：

// 每次有数据修改发生时都会写入AOF文件
appendfsync always
// 每秒钟同步一次，该策略为AOF的缺省策略
appendfsync everysec
// 从不同步。高效但是数据不会被持久化
appendfsync no

优点：

• 更高的数据安全性，即数据持久性。有三种同步策略：每秒同步，每修改同步，不同步。默认为每秒同步策略，写性能也仍然很不错（同步是由后台线程完成的，主线程继续努力地执行写请求）。
• AOF 日志是一个追加文件，即使出现宕机现象，也不会破坏文件的已有内容。即使由于某种原因文件末尾是一个写到一半的命令（磁盘满或者其他原因），redis-check-aof 工具也可以很轻易的修复。
• AOF 文件变得很大时，Redis 会自动在后台进行重写。重写是绝对安全的，因为 Redis 继续往旧的文件中追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦第二个文件创建完毕，Redis 就会切换这两个文件，并开始往新文件追加。
• AOF 文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个 AOF 文件。例如，即使你不小心错误地使用 FLUSHALL 命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启 Redis 就可以。

缺点：

• 对同样的数据集，AOF 文件通常要大于等价的 RDB 文件。
• AOF 可能比 RDB 慢，这取决于准确的 fsync 策略。通常 fsync 设置为每秒一次的话性能仍然很高，如果关闭 fsync，即使在很高的负载下也和 RDB 一样的快。不过，即使在很大的写负载情况下，RDB 还是能提供能好的最大延迟保证。
• 在过去，我们经历了一些针对特殊命令(例如，像 BRPOPLPUSH 这样的阻塞命令)的罕见 bug，导致在数据加载时无法恢复到保存时的样子。这些 bug 很罕见，我们也在测试套件中进行了测试，自动随机创造复杂的数据集，然后加载它们以检查一切是否正常，但是，这类 bug 几乎不可能出现在 RDB 持久化中。为了说得更清楚一点：Redis AOF 是通过递增地更新一个已经存在的状态，像 MySQL 或者 MongoDB 一样，而 RDB 快照是一次又一次地从头开始创造一切，概念上更健壮。但是，1)要注意 Redis 每次重写 AOF 时都是以当前数据集中的真实数据从头开始，相对于一直追加的 AOF 文件(或者一次重写读取老的 AOF 文件而不是读内存中的数据)对 bug 的免疫力更强。2)我们还没有收到一份用户在真实世界中检测到崩溃的报告。

如何修复损坏的 AOF 文件，文件损坏后 Redis 就无法装载了，可以使用下面步骤解决这个问题

• 创建 AOF 的一个拷贝用于备份。
• 使用 Redis 自带的 redis-check-aof 工具来修复原文件：$ redis-check-aof --fix <filename>
• 使用 diff -u 来检查两个文件有什么不同。用修复好的文件来重启服务器。

三、如何选择持久化机制

1). RDB

2). AOF

3). 可以完全禁止持久化。

4). RDB + AOF

我们该选谁：

通常来说，你应该同时使用这两种持久化方法。

如果你很关注你的数据，但是仍然可以接受灾难时有几分钟的数据丢失，你可以只单独使用 RDB。

有很多用户单独使用 AOF，但是我们并不鼓励这样，因为时常进行 RDB 快照非常方便于数据库备份，启动速度也较之快，还避免了 AOF 引擎的 bug。

四、如何从 RDB 切换到 AOF

• 备份你最新的 dump.rdb 文件。
• 把备份文件放到一个安全的地方。
• 发送以下两个命令：
• redis-cli config set appendonly yes
• redis-cli config set save ""
• 确保你的数据库含有其包含的相同的键的数量。
• 确保写被正确的追加到 AOF 文件。

第一个 CONFIG 命令开启 AOF。Redis 会阻塞以生成初始转储文件，然后打开文件准备写，开始追加写操作。

第二个 CONFIG 命令用于关闭快照持久化。这一步是可选的，如果你想同时开启这两种持久化方法。

重要：记得编辑你的 redis.conf 文件来开启 AOF，否则当你重启服务器时，你的配置修改将会丢失，服务器又会使用旧的配置。

Redis - 持久化

标签：

原文地址：http://www.cnblogs.com/xmsx/p/5392799.html