Redis 第五集持久化方案RDB与AOF(Redis)

二、Redis两种持久方案

Reids持久化准备工作,先配置Linux系统参数保证Redis缓存能写入到dbfinename文件和appendfilename文件中,解决Redis服务器重启后数据消失的问题。

Redis 第五集持久化方案RDB与AOF(Redis)_redis

有三种方式修改内核参数,但要有root权限:

(1)编辑/etc/sysctl.conf ,改vm.overcommit_memory=1,然后sysctl -p使配置文件生效

(2)sysctl vm.overcommit_memory=1

(3)echo 1 > /proc/sys/vm/overcommit_memory

1.RDB方式持久化

a.根据配置,快照将被写入dbfilename选项指定的文件里,并储存在dir选项指定的路径下。

b.创建快照和几种方式:

(b1).客户端向Redis服务器发送BGSAVE命令来创建一个快照,Redis会调用fork来创建一个子进程来负责 将快照写入磁盘达到持久化的目的。

(b2).客户端向Redis服务器发送SAVE命令来创建一个快照。

(b3).通过在配置文件中设置save选项,来触发BGSAVE命令创建快照。

(b4).客户端向Redis服务器发送shutdown命令时。

(b5).Redis服务器向另一台Redis服务器发送SYNC命令进行复制操作的时候。


c.在redis.conf中设置save选项来创建BGSAVE命令来创建快照,如下:

    save 900 1

  #表示距Redis服务器上次成功创建快照900秒后,

  #并且执行了写操作,那么Redis会开始一次新的BGSAVE操作,从而把创建的快照持久化到磁盘上。


d.演示Redis-RDB方式持久化及发生故障时进行数据恢复

(i).首先在配置文件中设置选项,笔者自定义了一个配置文件名为"redis.custom.conf"(当Redis服务

        器启动时加载此配置文件即可) 配置好选项后,

         记得重起Redis服务(可以先shutdow,再./src/redis-server redis.custom.conf)

(ii).然后模拟Redis服务器丢失数据,使用FLUSHALL命令把数据清除掉。然后再利

                 用保存了快照的文件dump.rdb来恢复Redis服务器中和缓存里的数据。

如下图:

vi /usr/local/redis/bin/redis.conf

默认如下(默认就是开启的):

218 save 5 1 注意修改秒数,我改成了5,默认900秒

219 save 300 10

220 save 60 10000

241 rdbcompression yes

253 dbfilename "dump.rdb"

263 dir "/usr/local/redis/bin"


[root@TEST01 bin]#  ./redis-cli -h 10.253.3.16 -p 6380

10.253.3.16:6380> set hello world2

OK

10.253.3.16:6380> get hello

"world2"

10.253.3.16:6380> keys *

1) "hello"

10.253.3.16:6380> save

OK

10.253.3.16:6380> set wxh1 wxh1

OK

10.253.3.16:6380> get wxh1

"wxh1"

10.253.3.16:6380>


5秒后,备份数据文件:

[root@TEST01 bin]# cp dump.rdb dump.rdb.bak


清空数据:

10.253.3.16:6380> flushall

OK

10.253.3.16:6380> keys *

(empty list or set)


按住ctrl+c关闭redis;覆盖数据文件:

[root@TEST01 bin]# cp dump.rdb.bak dump.rdb

cp:是否覆盖"dump.rdb"? y


重启数据库:./redis-server /usr/local/redis/bin/redis.conf

发现数据回来:

10.253.3.16:6380> keys *

1) "hello"

2) "wxh1"

说明:当Redis内存占用量达到几十个GB时且剩余内存空间不多或者运行在虚拟机上时,此时执行BGSAVE可能会导致系统长时间停顿。停顿的原因是由于BGSAVE创建子进程引起的。而SAVE命令不会导致停顿,但SAVE会阻塞,阻塞到快照生成为止。根据实践经验一个内存大小为60GB的虚拟机上,当Redis占用50G内存时,使用SAVE命令创建快照的速度远胜过使用BGSAVE命令。 所以通常情况下会写脚本来调用SAVE命令来生成快照持久化到磁盘中,由于它的阻塞原因,常常选择在深夜执行该脚本


2.AOF持久化

a.      什么是AOF持久化?

简单的来说,AOF持久化会将执行的写命令写到AOF文件的末尾,以此来记录数据发生的变化。因此,Redis只要从头到尾重新执行一次AOF文件中包含的所有写命令,就可以恢复AOF文件所记录的数据集。

b.     AOF持久化通过配置选项appendonly为yes来开启。(配置在redis.custom.conf文件中),重启Redis服务器时加载配置文件redis.custom.conf然后根据指定的xxxx.aof来恢复数据。

c.      appendfsync选项可以设置AOF文件使用的同步频率为哪一种。

d.     重写和压缩AOF文件

由于Redis会不断的把写命令写到AOF文件中,AOF文件的体积越变越大,用户可以向Redis服务器进行发送BGREWRITEAOF命令,这个命令可以移除AOF文件中冗余命令来重写AOF文件,使AOF文件的体积尽可能的变得小。

e.      AOF持久化通过两个选项auto-aof-rewrite-percentage和auto-aof-rewrite-min-size进行。

假设用户在redis.custom.conf中配置了选项

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

持久化的同时,如果满足以下条件:

i.      启用了AOF持久化,AOF的体积大于64MB时,

ii.     并且AOF文件的体积比上一次重写后的体积至少大了一倍时将触发Redis执行BGREWRITEAOF命令进行重写和压缩AOF文件。

f.      演示AOF持久化:

说明:这个演示与RDB类似,不同的是备份的文件由dbfilename dump.rdb变成 appendfilename appendonly.aof的备份(给appendonly.aof 文件备份appendonly.aof.bak,必须在FLUSHALL命令前,因为这个命令会被记录于appendonly.aof文件中,那么恢复数据时,执行这个命令数据不也为空了?所以要在这个命令之前备份。

具体思路:使用FLUSHALL命令清空所有数据,来模拟缓存数据的丢失,然后再这个备份文件覆盖appendonly.aof来演示缓存的持久化

tips: redis-check-aof --fix appendonly.aof 用于修复appendonly.aof文件异常。


699 appendonly no  --需要修改为yes

703 appendfilename "appendonly.aof"

729 appendfsync everysec

770 auto-aof-rewrite-percentage 100

771 auto-aof-rewrite-min-size 64mb


测试时,218 save 900 1,这样避免RDB影响。

输入数据:

10.253.3.16:6380> set wxh2 wxh2

OK

10.253.3.16:6380> set wxh3 wxh3

OK

10.253.3.16:6380> set wxh4 wxh4

OK

10.253.3.16:6380> keys *

1) "wxh4"

2) "wxh2"

3) "wxh3"


备份数据文件:

cp appendonly.aof appendonly.aof.bak


删除数据:

10.253.3.16:6380> flushall

OK

10.253.3.16:6380> keys *

(empty list or set)


关闭redis,覆盖数据文件:

[root@TEST01 bin]# cp appendonly.aof.bak appendonly.aof

cp:是否覆盖"appendonly.aof"? y


查看数据,已经回来:

10.253.3.16:6380> keys *

1) "wxh3"

2) "wxh4"

3) "wxh2"


1.Redis RDB持久化方案

优点:数据恢复更快。使用函数process_logs(conn,path,callback)来对日志进行聚合计算,通过将日志处理的进度记录到Redis里面,当系统发生故障后,根据进度记录来完成之前未完成的处理工作。

缺点:RDB方式数据完整性和一致性不高。从配置选项可以看出,它指定设置时间段来创建快照,然后把数据持久化到存储介质中的。那么在这一段时间内快照创建失败将会导致持久化失败。那么数据可能会丢失一大块。


2.Redis AOF持久化方案.

优点:AOF方式的数据完整性和一致性相对较高,当使用官方推荐的appendfsync everysec,即使用持久化失败也是丢失1秒时间的数据。

缺点:随着aof文件体积的变得越大,数据恢复变得越慢。因为Redis会从头到尾执行aof中所有写的命令。此外:两种持久化方案在Redis中可以同时使用,也可以单独使用某一种。


参考:http://www.pianshen.com/article/870590295/