redis数据恢复

公司线上一个项目数据存储采用MySQL，共分为10个库，分布在4台机器上，每个库数据量约为10G，各机器均采用RAID5加速磁盘访问；
当同时在线人数达高峰期（10w），DB磁盘IO压力巨大，导致访问巨慢，，在线人数就很难上不去了。

针对上面描述情况，使用redis后可有效解决这一瓶颈，因为Redis数据读写都是直接操作内。

解决方案：
将部分数据压缩导入到redis后，总数据量约30G（转换成redis数据类型数据量），一主一从模型，共两组。
一台机器内存32G，开10个实例，共20个实例，多实例方便做持久化。

同样适用于上面的redis持久化策略调整方案（思路和上面一致）

主从库配置：
主库：关闭save开展，aof默认不打开，允许从库访问。主库设置了密码访问requirepass My#redis
从库：需增加配置：开启AOF持久化，关闭save快照，设置密码；
从库10个实例的配置文件分别为：slave6001.conf ~ slave6010.conf
slave6001.conf配置内容如下（其他实例拷贝这个，修改端口等其他信息即可）

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

daemonize yes pidfile /var/run/slave6001.pid port 6001 timeout 300 loglevel debug logfile /usr/local/redis/var/debug6001.log syslog-enabled yes databases 16 rdbcompression yes dbfilename slave6001.rdb dir /data/redis-data/slave6001 slaveof 192.168.0.139 6001 masterauth My#redis slave-serve-stale-data yes requirepass My#redis appendonly yes appendfilename slave6001.aof appendfsync everysec no-appendfsync-on-rewrite no vm-enabled no vm-swap-file /tmp/redis.swap vm-max-memory 0 vm-page-size 32 vm-pages 134217728 vm-max-threads 4 hash-max-zipmap-entries 512 hash-max-zipmap-value 64 list-max-ziplist-entries 512 list-max-ziplist-value 64 set-max-intset-entries 512 activerehashing yes

主库每晚12点给每个实例手动做一次bgsave快照。主库备份脚本（redis_bgsave.sh）

1 2 3 4 5 6 7 8 9

#!/bin/bash #date=`date +%y%m%d_%H%M%S` REDISPASSWORD=My#redis for PORT in `seq 6001 6010` do /usr/local/redis/bin/redis-cli -h 127.0.0.1 -p $PORT -a $REDISPASSWORD bgsave sleep 10 done date >> /usr/local/redis/var/bgsave.log

从库每晚12点拷贝每个实例的AOF到其他目录并对其打包，压缩包要有异地备份，之后再压缩AOF（bgrewriteaof）。
从库备份AOF并bgrewriteaof脚本（redis_backup.sh ：对单个实例）

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

#!/bin/sh ## FD:File Dir ## RD:Runing Dir ## 第一个参数为redis实例名 if [ $# -ne 1 ]; then echo “Usage:$0  redis_name” exit fi CURDATE=`date +%Y%m%d` CURHOUR=`date +%Y%m%d_%H` CURTIME=`date +%Y%m%d_%H%M%S` REDISPASSWORD=My#redis REDISNAME=$1 PORT=`echo $REDISNAME | cut -c6-9` LOGFILE=/data/logs/redisbak/redis_allbak_${CURDATE}.log if [ "${REDISNAME}" = "" ]; then echo “redis name Error!” exit 1 else if [ ! -d "/data/redis-data/${REDISNAME}" ]; then echo “redis name Error!” exit 1 fi fi DDIR=/data/backup/redis/$CURHOUR mkdir -p ${DDIR} RDIR=/data/redis-data/$REDISNAME cd ${RDIR} tar -zcf $DDIR/${REDISNAME}_${CURTIME}.tar.gz $REDISNAME.aof if [ $? != 0 ]; then echo “tar error $REDISNAME.aof” >> $LOGFILE #exit 1 fi sleep 5 /usr/local/redis/bin/redis-cli -h 127.0.0.1 -p $PORT -a $REDISPASSWORD bgrewriteaof sleep 5 ###  delete old backup data dir  ### #/bin/rm -rf `date -d -7day +”%Y%m%d”` find /data/backup/redis/ -mtime +7 | xargs rm -rf echo “Backup $REDISNAME ok at $CURTIME !” >> $LOGFILE

从库对所有实例备份（/data/sh/redis_allbak.sh）

1 2 3 4 5 6 7

#!/bin/sh CURDATE=`date +%Y%m%d` LOGFILE=/data/logs/redisbak/redis_allbak_${CURDATE}.log for PORT in `seq 6001 6010` do /data/sh/redis_backup.sh slave${PORT} && echo “slave${PORT} ok `date +%Y%m%d_%H%M%S`” >> $LOGFILE 2>&1 || echo “slave${PORT} backup error” >> $LOGFILE 2>&1 done

操作注意事项
1）若主库挂了，不能直接开启主库程序。若直接开启主库程序将会冲掉从库的AOF文件，这样将导致只能恢复到前一天晚上12的备份。
2）程序在跑时，不能重启网络(程序是通过网络接口的端口进行读写的)。网络中断将导致中断期间数据丢失。
3）确定配置文件全部正确才启动（尤其不能有数据文件名相同），否则会冲掉原来的文件，可能造成无法恢复的损失。

灾难恢复
1）主库故障，快速恢复到最近状态描述：主库挂了（redis程序挂了/机器宕机了），从库正常，恢复到主库挂掉的时间点：去从库手动做一次快照，拷贝快照到主库相应目录，启动，OK。
在从库做一次快照，转移快照文件到其他目录，将快照文件目录拷贝到主库相应目录，启动主库，OK!
( /data/sh/redis_bgsave_cp.sh )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#!/bin/bash REDISPASSWORD=My#redis for PORT in `seq 6001 6010` do /usr/local/redis/bin/redis-cli -h 127.0.0.1 -p $PORT -a $REDISPASSWORD bgsave sleep 5 done sleep 15 for PORT in `seq 6001 6010` do SDIR=/data/redis-data/slave${PORT}/ DDIR=/data/redis_recovery/redis-data/ mkdir -p $DDIR/redis${PORT}/ cd $SDIR cp -rf slave${PORT}.rdb $DDIR/redis${PORT}/redis${PORT}.rdb #sleep 1 done

在主库将原来数据目录重命名。
从从库拷贝快照文件到主库。
启动主库。

2）恢复到当天12点状态注意备份数据（当前状态AOF+正常退出快照）！
停止redis。
解压AOF（/data/sh/redis_untar.sh）

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#!/bin/bash DAY=20111102 SDIR=/data/backup/redis/20161102_00/ cd $SDIR for PORT in `seq 6001 6010` do tar -zxf slave${PORT}_$DAY_*.tar.gz sleep 2 done 切割AOF（/data/sh/redis_sed.sh） #!/bin/bash DDIR=/data/redis_recovery/ TAG=”TAG111101_1200″ for PORT in `seq 6001 6010` do SDIR=/data/backup/redis/20161102_00/ SAOF=${SDIR}/slave${PORT}.aof line=`sed -n “/$TAG/=” $SAOF` num=$[$line + 3] mkdir -p ${DDIR}/slave${PORT}/ sed “${num},\$d” $SAOF > ${DDIR}/slave${PORT}/slave${PORT}.aof done

将原来数据目录重命名。
将切割出来的AOF目录重命名为配置文件的数据目录。（注释主从同步配置项）。
启动从库。
做快照，拷贝到主库，启动主库（同上面第1）步）。

3）恢复到两天或几天前12点状态从库每晚备份要备份AOF未bgrewriteaof之前的数据，可根据当天晚上12点备份，没有bfrewriteaof之前的AOF文件来进行恢复，方法同上面的第2）步。

 

 

公司线上redis主从环境下的持久化策略调整：
描述：
之前线上项目使用redis，部署了redis主从环境。redis的主从复制功能非常强大，一个master可以拥有多个slave，而一个slave又可以拥有多个slave，如此下去，形成了强大的多级服务器集群架构。由于主redis采用了AOF和save快照的持久化，长时间下去，aof文件不断增大，磁盘空间使用率逐渐暴增。
考虑到性能问题，需要对redis持久化做些调整，调整如下：
   1）主库不开启AOF持久化，并关闭save快照功能（即注释默认的三个save设置），只在每晚12点定时手动做一次bgsave快照，并将快照文件转移到异地。即主库上不产生appendonly.aof持久化文件，做的快照数据放在.rdb文件里（如dump.rdb，由于是压缩配置(rdbcompression yes表示快照文件要压缩)，所以快照文件要比aof文件小），然后将这个快照文件dump.rdb转移到其他的服务器上，防止主服务器宕机造成的损失！
   2）从库开启AOF持久化并1秒落地，同样不做快照save。并在每晚12点做一次bgrewriteaof压缩appendonly.aof持久化文件，压缩前先对aof文件进行备份。
--------------------------------------------------------------------------------------------------------------------------------------------
按照这种方法进行redis持久化调整，由于线上redis的主库之前采用了AOF和save快照的持久化，之后将这两种都关闭，从库采用AOF持久化。出现了下面的现象：
就是主库关闭AOF和save快照后，主redis上的appendonly.aof持久化文件在一段时间内还在刷，在增大，这是正常的，由于之前开启的缘故，刷过一段时间，主redis的appendonly.aof持久化文件就不刷了，只有从redis的appendonly.aof持久化文件在刷了
--------------------------------------------------------------------------------------------------------------------------------------------

主从redis部署的主要目的：数据持久化，灾难恢复，冗余。主库不落地，减少消耗。
1）主库不做AOF，不做快照，允许从库访问即可。
2）从库开启AOF，不做save
3）备份策略：
主库每晚12点整给每个实例手动做一次bgsave快照，并将快照文件备份到远程节点上。
从库每晚12点整对AOF文件打包备份(tar)，打包备份后做一次AOF文件压缩(bgrewriteaof)。每天的数据起始点是前一天晚上rewriteaof后的数据。

主库服务器脚本：
即主库快照之后，将快照文件转移到异地即从库机器192.168.1.121/135上面。

1 2 3 4 5 6 7 8 9

[root@192-168-1-132 redis]# cat redis_bgsave.sh #!/bin/bash CURHOUR=`date +%Y%m%d_%H` /usr/local/bin/redis-cli -h 127.0.0.1 -p 6379 bgsave sleep 10 rsync -av /data/redis/dump.rdb root@192.168.1.121:/data/backup/192.168.1.132-save/$CURHOUR/ rsync -av /data/redis/dump.rdb root@192.168.1.135:/data/backup/192.168.1.132-save/$CURHOUR/ sleep 10 date >> /data/logs/bgsave.log

从库服务器脚本：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

[root@cdn redis]# cat redis_backup.sh #!/bin/bash   CURDATE=`date +%Y%m%d` CURHOUR=`date +%Y%m%d_%H` CURTIME=`date +%Y%m%d_%H%M%S` LOGFILE=/data/logs/redisbak/redis_allbak_${CURDATE}.log REDISNAME=appendonly.7000 DDIR=/data/backup/redis/$CURHOUR mkdir -p ${DDIR} RDIR=/data/redis cd ${RDIR} tar -zcf $DDIR/${REDISNAME}_${CURTIME}.tar.gz appendonly.7000.aof if [ $? != 0 ]; then   echo "tar error $REDISNAME.aof" >> $LOGFILE fi sleep 5 /usr/local/bin/redis-cli -h 127.0.0.1 -p 6379 bgrewriteaof sleep 5   ###  delete old backup data dir  ### #/bin/rm -rf `date -d -30day + "%Y%m%d"` find /data/backup/redis/ -mtime +30 | xargs rm -rf echo "Backup $REDISNAME ok at $CURTIME !" >> $LOGFILE

[root@cdn redis]# crontab -e
59 23 * * * /bin/bash /data/redis/redis_backup.sh >/dev/null 2>&1

[root@cdn redis]# cd /data/backup/redis/20161207_13
[root@cdn 20161207_13]# ls
appendonly.7000_20161207_133131.tar.gz