Redis持久化--Redis宕机或者出现意外删库致使数据丢失--解决方案

转发来源:https://www.cnblogs.com/xlecho/p/11834011.html

echo编辑整理，欢迎转载，转载请声明文章来源。欢迎添加echo微信(微信号：t2421499075)交流学习。 百战不败，依不自称常胜，百败不颓，依能奋力前行。——这才是真正的堪称强大！！！

---

Redis持久化的方案实际上是不少人接触的比较少的，由于相对应的数据故障不会不少，一次初始化的设置就能保证后续故障的所有顺利解决。本文讲述一下该机制的主要设置方法和持久化方案的对比，同时也会讲述一些持久化的原理。若是对于Redis持久化比较熟悉的但愿可以给到你帮助，若是不熟悉的，你大可参考本文对你的Redis进行设置。

什么是Redis的持久化？

可能不少人不多接触这个词，总觉的咱们Redis的全部数据都是所有可以永久存储的。然而你可能不知道的是，Redis的数据都是在内存当中的，若是没有持久化策略，你关闭Redis或者以后，你的数据有可能所有都丢失了。咱们每再一次登陆Redis访问上一次数据的时候，咱们都看到了原来的数据，就是得益于Redis的持久化。Redis的持久化简单说就是，将Redis存在内存中的值存储到能够永久存储的地方（磁盘等）

Redis的持久化方案

• RDB Redis DataBase
• AOF Append Only File

RDB [Redis DataBase]

RDB 是 Redis 默认的持久化方案。当知足必定条件的时候，会把当前内存中的数据写入磁盘，生成一个快照文件 dump.rdb。Redis 重启会经过加载 dump.rdb 文件恢复数据。dump.rdb是咱们redis文件当中的一个，位置以下图：

RDB是怎么实现持久化的

RDB是按照规则来触发持久化存储的，在咱们的redis.conf中咱们能够看到以下的几个配置：

save 900 1 # 900 秒内至少有一个 key 被修改（包括添加） save 300 10 # 300 秒内至少有 10 个 key 被修改 save 60 10000 # 60 秒内至少有 10000 个 key 被修改

这几个配置是不冲突的，只要知足任意一个都会触发。

• RDB方式的优势
• • RDB 是一个紧凑的单一文件,很方便传送到另外一个远端数据中心，很是适用于灾难恢复。
• • 与AOF相比,在恢复大的数据集的时候，RDB 方式会更快一些。
• RDB方式的缺点
• • RDB 方式数据没办法作到实时持久化/秒级持久化。由于 bgsave 每次运行都要
    执行 fork 操做建立子进程，频繁执行成本太高。
• • 在必定间隔时间作一次备份，因此若是 redis 意外 down 掉的话，就会丢失最后
    一次快照以后的全部修改（数据有丢失）。若是数据相对来讲比较重要，但愿将损失降到最小，则可使用 AOF 方式进行持久化。

RDB持久化的演示

若是咱们都按照正常程序走的话，咱们是很难看到没有持久化，或者出现持久化问题的故障现场的。因此咱们要学会持久化操做，或者只管看到持久化就须要手动触发持久化问题。这里主要演示两种状况，一种是数据正常备份，一种是数据丢失，咱们恢复备份数据。

注意

这两个操做都算是危险操做，咱们须要在操做以前进行一下设置一下Redis快照，Redis
提供了两条命令：

• save: 在生成快照的时候会阻塞当前 Redis 服务器， Redis 不能处理其余命令。若是
  内存中的数据比较多，会形成Redis长时间的阻塞。生产环境不建议使用这个命令。为了解决这个问题，Redis 提供了第二种方式。
• bgsave:执行 bgsave 时，Redis 会在后台异步进行快照操做，快照同时还能够响应客户端请
  求。具体操做是 Redis 进程执行fork操做建立子进程（copy-on-write），RDB持久化过程由子进程负责，完成后自动结束。它不会记录fork以后后续的命令。阻塞只发生在fork阶段，通常时间很短。用 lastsave 命令能够查看最近一次成功生成快照的时间。

使用shutdown 持久化

咱们先在Redis库中设置以下几个值

set k1 1 set k2 2 set k3 3 set k4 4 set k5 5 # 操做完成上面的步骤以后咱们中止服务器，触发RDB的自动保存save shutdown # 而后再次启动Redis服务 redis-server redis.conf # 启动完成，查看咱们那些刚刚保存的数据是否被持久化了 keys *

执行完上面的步骤以后，咱们能够看到咱们的数据都在，就说明咱们的触发备份是成功的。

使用flushall模拟数据丢失

该操做有必定的风险性，若是是演示练习按照操做来基本不会出现问题，可是生产上慎重操做。咱们作该操做以前，必定要注意先备份RDB对应的持久化问题dump.rdb

# 先备份dump.rdb cp dump.rdb dump.rdb.bak  # 备份完成以后咱们肯定备份成功在进行下一步操做---清空库 flushall  # 清空以后咱们中止服务器 shutdown  # 再次启动服务器，查看以前存储的kye keys * 

再次启动查看的时候，咱们发现咱们的数据丢失了

恢复丢失的数据

# 停服务器 shutdown  # 删除咱们现有dump.rdb rm -rf ./dump.rdb  # 删除成功以后，将咱们的备份的dump.rdb.bak从新命名成为dump.rdb mv dump.rdb.bak dump.rdb  # 肯定以后咱们再次启动redis服务 redis-server redis.conf  # 检查咱们以前丢失的数据是否存在 keys * 

完成以后咱们查看的数据就出现啦！

AOF [Append Only File]

AOF：Redis 默认不开启。AOF采用日志的形式来记录每一个写操做，并追加到文件中。开启后，执行更改 Redis 数据的命令时，就会把命令写入到AOF文件中。Redis重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工做。

该方式默认关闭，须要使用咱们须要修改以下配置

# 开关 Redis 默认只开启 RDB 持久化，开启 AOF 须要修改成 yes appendonly no # 文件名 路径也是经过 dir 参数配置 config get dir appendfilename "appendonly.aof"

数据都是实时持久化到磁盘吗？

因为操做系统的缓存机制，AOF数据并无真正地写入硬盘，而是进入了系统的硬盘缓存。何时把缓冲区的内容写入到 AOF 文件？

AOF的保存规则有三种

AOF 持久化策略（硬盘缓存到磁盘），默认 everysec

• no 表示不执行 fsync，由操做系统保证数据同步到磁盘，速度最快，可是不太安全；
• always 表示每次写入都执行 fsync，以保证数据同步到磁盘，效率很低；
• everysec 表示每秒执行一次 fsync，可能会致使丢失这 1s 数据。一般选择 everysec ，
  兼顾安全性和效率。

文件愈来愈大，怎么办？

因为 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行，AOF 的文件会愈来愈大，文件越大，占用服务器内存越大以及 AOF恢复要求时间越长。
可使用命令 bgrewriteaof来重写。AOF文件重写并非对原文件进行从新整理，而是直接读取服务器现有的键值对，而后用一条命令去代替以前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。

AOF指定大小开始重写

• auto-aof-rewrite-percentage:默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增加到必定大小的时候，Redis可以调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上第二天志重写获得AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

• auto-aof-rewrite-min-size:默认64M。设置容许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的状况还要重写。

• AOF方式的优势
• • AOF 持久化的方法提供了多种的同步频率，即便使用默认的同步频率每秒同步一次，Redis最多也就丢失 1 秒的数据而已。
• AOF方式的缺点
• • 对于具备相同数据的的Redis，AOF文件一般会比RDF文件体积更大（RDB存的是数据快照）。
• • 虽然 AOF 提供了多种同步的频率，默认状况下，每秒同步一次的频率也具备较高的性能。在高并发的状况下，RDB 比 AOF 具好更好的性能保证。

两种方案比较

那么对于AOF和RDB两种持久化方式，咱们应该如何选择呢？若是能够忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定时生成RDB 快照（snapshot）很是便于进行数据库备份， 而且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。不然就使用AOF重写。可是通常状况下建议不要单独使用某一种持久化机制，而是应该两种一块儿用，在这种状况下,当 redis 重启的时候会优先载入 AOF文件来恢复原始的数据，由于在一般状况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。---作一个有底线的博客主