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

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

二、Redis两种持久方案

Reids持久化准备工作，先配置Linux系统参数保证Redis缓存能写入到dbfinename文件和appendfilename文件中,解决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/