CentOS 单机版配置Redis3.0 RDB与AOF持久化配置

编写日期：2017-07-19

编写作者：mtsbv110

邮    箱：2532874889@qq.com

 

主机规划：192.168.9.155

Redis版本：redis-3.2.8.tar.gz

安装目录：/usr/local/redis

 

一、RDB持久化配置（默认开启）：

RDB持久化机制，对redis中的数据执行周期性的持久化

 

RDB持久化机制的优点

（1）RDB会生成多个数据文件（每次生成一个新的快照，都会覆盖之前的老快照），每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，以预定好的备份策略来定期备份redis中的数据

（2）RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。（适用于RDB文件比较小的情况）

（3）基于RDB数据文件来重启和恢复redis进程，更加快速

 

RDB持久化机制的缺点

（1）如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据

（2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒

 

RDB快照生成策略

redis.conf文件，也就是/usr/local/redis/conf/6379.conf，去配置持久化

save 900 1

save 300 10

save 60 10000

 

例如：save 60 10000

每隔60s，如果有超过10000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting，快照。

save可以设置多个，就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生了变更，如果有，就生成一个新的dump.rdb文件

 

也可以手动调用Save或BGSAVE命令的，同步或异步执行rdb快照生成

/usr/local/bin/redis-cli -h 127.0.0.1 -p 6379 -a pwd bgsave|save

 

[root@bogon 6379]# redis-cli save

-rw-r--r--. 1 root root 94 7月  24 16:08 dump.rdb

 

二、AOF持久化配置（基于命令日志/merge/回放方式）

在生产环境里面，一般来说AOF都是要打开的。

AOF 是存放每一条写指令的，所以会不断的膨胀，但内存的大小是一定的，所以当大到一定的时候，AOF会进行Rewrite的操作。（基于当时Redis内存中的数据，会重新压缩构造一个更小的AOF文件，然后将就的aof大文件给删除）。

 

 

AOF持久化机制的优点:

（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据

（2）AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高（但没有RDB 写QPS高），而且文件不容易破损，即使文件尾部破损，也很容易修复

（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

 

AOF持久化机制的缺点

 

（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

 

Appendonly数据恢复

开启 AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入os cache的，然后每隔一定时间再fsync一下

(即使AOF和RDB都开启了，redis重启的时候，也是优先通过AOF进行数据恢复的，因为aof数据比较完整)。

appendonly yes

AOF的fsync配置三种策略

appendfsync always            每次写入一条数据就执行一次fsync;

appendfsync everysec                     每隔一秒执行一次fsync;

appendfsync no               不主动执行fsync

 

redis将数据写入AOF缓冲区，单独开一个现场做fsync操作。

appendfsync everysec每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的

 

AOF rewrite

redis中的数据其实有限的，很多数据可能会自动过期、可能会被用户删除、可能会被redis用缓存清除的算法清理掉。

redis中的数据会不断淘汰掉旧的，就一部分常用的数据会被自动保留在redis内存中。所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，到很大很大，所以AOF会自动在后台每隔一定时间做rewrite操作，AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了; redis内存只剩下10万; 基于内存中当前的10万数据构建一套最新的日志，到AOF中; 覆盖之前的老日志; 确保AOF日志文件不会过大，保持跟redis内存数据量一致。

 

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

 

（1）redis fork一个子进程

（2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志

（3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件

（4）子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中

（5）用新的日志文件替换掉旧的日志文件

 

三、先使用RDB，后开启AOF，aof和rdb两份数据文件同步问题

（1）先手动执行当前内存生成RDB文件，备份RDB文件，以防数据同步失败。

[root@bogon 6379]# redis-cli save

将rdb文件拷贝到安全的地方
（2）直接在命令行热修改redis配置，打开aof，这个redis就会将内存中的数据对应的日志，写入aof文件中

[root@bogon 6379]# redis-cli config set appendonly yes  

 

127.0.0.1:6379> BGREWRITEAOF

Background append only file rewriting started

 

(3)停止redis，手动修改配置文件，打开aof的命令，再次重启redis

 

[root@bogon conf]# redis-cli shutdown

[root@bogon 6379]# vi /usr/local/redis/conf/6379.conf

 

 

[root@bogon conf]# /etc/init.d/redis start

Starting Redis server...

 

注：如果强杀 kill -9,记得删除/var/run/redis_6379.pid文件

 

四、RDB 冷备数据备份方案

（1）写crontab定时调度脚本去做数据备份

[root@bogon redis]# pwd

/usr/local/redis

 

[root@bogon redis]# date

2017年 07月 25日 星期二 12:59:55 CST

创建快照生成目录

[root@bogon 6379]# mkdir -p /usr/local/redis/snapshotting

（2）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份

（3）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份

（4）每次copy备份的时候，都把太旧的备份给删了

创建shell 脚本存放目录

[root@bogon shell]# mkdir -p /usr/local/redis/shell

编写每小时（保留最近48小时的备份）备份脚本

 [root@bogon 6379]# vim redis_rdb_copy_hourly.sh

#!/bin/sh

cur_date=`date +%Y%m%d%k`

rm -rf /usr/local/redis/snapshotting/$cur_date

mkdir /usr/local/redis/snapshotting/$cur_date

cp /usr/local/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

 

del_date=`date -d -48hour +%Y%m%d%k`

rm -rf /usr/local/redis/snapshotting/$del_date

[root@bogon shell]# chmod u+x redis_rdb_copy_hourly.sh

每小时copy一次备份，删除48小时前的数据

[root@bogon redis]# crontab –e

0 * * * * sh /usr/local/redis/shell/redis_rdb_copy_hourly.sh

 

检查是否生效

[root@bogon redis]# date +%Y%m%d%k

2017072513

[root@bogon redis]# date -d -48hour +%Y%m%d%k

2017072313

在snapshotting手动创建一个日期2017072313

[root@bogon snapshotting]# mkdir 2017072313

进入2017072313目录/usr/local/redis/snapshotting/2017072313

[root@bogon 2017072313]# touch dump.rdb

[root@bogon 2017072313]# pwd

手动执行redis_rdb_copy_hourly.sh，24小时之前的文件被删除，当前时间的备份。

 

编写每天（保留最近1个月的备份）备份脚本

#!/bin/sh

cur_date=`date +%Y%m%d`

rm -rf /usr/local/redis/snapshotting/$cur_date

mkdir /usr/local/redis/snapshotting/$cur_date

cp /usr/local/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

 

del_date=`date -d -1month +%Y%m%d`

rm -rf /usr/local/redis/snapshotting/$del_date

[root@bogon redis]# crontab –e

0 0 * * * sh /usr/local/redis/shell/redis_rdb_copy_daily.sh

 

[root@bogon shell]# chmod u+x redis_rdb_copy_daily.sh

 

检查是否生效

[root@bogon shell]# date -d -1month +%Y%m%d

20170625

[root@bogon shell]# cd /usr/local/redis/snapshotting/

[root@bogon snapshotting]# ls

2017072513

[root@bogon snapshotting]# mkdir 20170625

[root@bogon snapshotting]# ls

20170625  2017072513

[root@bogon snapshotting]# cd 20170625/

[root@bogon 20170625]# ls

[root@bogon 20170625]# touch dump.rdb