Redis全方位详解–磁盘持久化和容灾备份

序言

  在上一篇博客中,博客介绍了redis的数据类型使用场景和redis分布式锁的正确姿势。我们知道一旦Redis重启,存在redis里面的数据就会全部丢失。所以这篇博客中向大家介绍Redis的磁盘持久化。

 

REDIS持久化

  以每隔一段时间对redis进行快照的方式实现持久化

RDB持久化

  优点:1、对redis性能影响小。

     2、数据集比较大的时候,恢复速度比AOF快。

       3、RDB是一个非常紧凑的单一文件,很方便传到第三方数据中心(亚马逊S3),以便日后的灾难恢复。

  缺点:1、因为RDB的快照持久化方式,所以一旦出现宕机,你可能丢失几分钟的数据。

     2、RDB需要fork一个子进程来保存数据集到磁盘上,所以当数据集比较大的时候,就会造成redis在毫秒级内对客户端没反应。

  配置文件:在redis.conf文件中,有这样一段话。

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

说明在三种策略下,RDB会执行快照来将数据保存在磁盘上。例如 save 60 10000 意思是,”60秒内至少有1000个键被改动”,这自动保存一次数据集。

notice:当redis刚启动,这时你使用redis-cli向redis中存入一条数据,会发现并没有生成dump.rdb。这是因为这时候还没有满组以上三种策略,所以不会执行bgsave命令,这时要么你等900秒,要么你进入redis-cli,主动执行bgsave命令。

这样就会生成dump.rdb。

  工作方式:当需要数据持久化的时候,会执行一下操作

    1、Redis调用forks.同时拥有父进程和子进程。(这个过程是阻塞的)

    2、子进程将数据集写入一个临时的rdb文件中。

    3、Redis用新的rdb文件替换旧的rdb文件,并删除旧的rdb文件。

 

AOF持久化

  以向AOF文件中追加redis写操作方式实现持久化

  优点:1、AOF有三种策略:无fsync(完全依赖系统,性能很接近RDB)、每秒fsync、写时fsync(数据完全同步,但性能比较差)。默认使用每秒fsync,这种策略,即使redis宕机,最多也只会丢失一秒中的数据,兼顾性能和数据实时性。

       2、当向AOF文件写入命令时,由于某些问题(磁盘已满或写时宕机等)造成未写入完整的命令,可以使用redis-check-aof命令修复这些问题。

     3、当AOF文件过大时,会自动重写AOF文件。(例如我们只能了一百次incr count,就会在AOF文件中追加100次这个命令,那么重写后,就只会有一条类似set count 100的命令)。

     4、AOF 文件有序地保存了对redis执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存,非常的容易读懂。因此当我们执行一些误操作(FLUSHALL)的时候,也可以通过修改AOF文件来修复数据。

  缺点:1、相同的数据集情况下,体积会比rdb大。

     2、除非使用无fsync,不然AOF的性能都慢于RDB。

  配置文件:同样去看redis.conf文件中的配置注释。主要配置如下

appendonly yes                      是否开启AOF持久化
appendfilename "appendonly.aof"     AOF文件名
# appendfsync always          每次写入时都追加的AOF文件中
appendfsync everysec          每秒同步一次AOF文件
# appendfsync no            不同步AOF文件,完全依赖操作系统

 下面还有一些其他参数配置,详细的可以去官网下载一份对应版本的redis.conf文件。

  工作原理:AOF重写和RDB创建快照一样,都巧妙的利用了redis写时复制机制:

    1、redis执行fork(),同时拥有父进程和子进程。

    2、子进程将新AOF命令写入到临时文件中。

    3、所有新执行的写入命令,redis一边将其放入内存缓存中,一边写入现有的AOF文件中,这样即使AOF重写中redis发生宕机,现有AOF文件也是安全的。

    4、当子进程完成AOF重写时,会给父进程发送一个信号,父进程在接收到信号后,会将内存缓存中的所有命令追加到新的AOF文件中。

    5、Redis用新的AOF替换原有的AOF。

 

如何选择使用哪种持久化

  1、如果你对数据的安全性要求非常高,那么建议两种都适用。

  2、如果你可以承受数分钟的数据损失,那么就可以使用rdb

  3、使用AOF

notice:redis官网有这样一段话:因为以上提到的种种原因, 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。或许很快,我们就不用纠结使用哪种持久化了。

 

从RDB切换到AOF

  1、为现有的rdb文件创建一个备份,并将备份放到一个安全的地方

  2、redis-cli: config set appendonly yes 执行这个命令时,redis会阻塞,知道AOF文件创建完成,然后新的写入命令会被追加到新的AOF文件中。

  3、redis-cli: config set save “” 关闭RDB持久化是可选的,因为你完全可以同时开启RDB和AOF这两种持久化功能。

  4、记得把前面的修改同步到redis.conf配置文件中,否则redis重启后,config set设置的配置就失效了。

 

备份redis数据及容灾

  牢记:确保你的数据由完整的备份。 磁盘故障,节点失效, 诸如此类的问题都可能让你的数据消失不见, 不进行备份是非常危险的。

  因为RDB的工作原理,所以redis对于数据备份是非常友好的。无论何时,复制RDB文件是绝对安全的。

    1、创建一个定期任务(cron job), 每小时将一个 RDB 文件备份到一个文件夹, 并且每天将一个 RDB 文件备份到另一个文件夹。

    2、确保快照的备份都带有相应的日期和时间信息, 每次执行定期任务脚本时, 使用 find 命令来删除过期的快照: 比如说, 你可以保留最近 48 小时内的每小时快照, 还可以保留最近一两个月的每日快照。

    3、至少每天一次, 将 RDB 备份到你的数据中心之外, 或者至少是备份到你运行 Redis 服务器的物理机器之外。

  数据备份了之后,为了做到容灾,你可以将备份后的数据放到第三方数据中心。