企业生产环境中的数据备份和各种灾难下的数据恢复,到底是怎么做得呢?
1、企业级的持久化的配置策略
在企业中,RDB的生成策略,用默认的也差不多
save 60 10000:一分钟内有一万个key变成,就触发一次RDB快照。如果你希望尽可能确保RDB最多丢1分钟的数据,那么尽量就是每隔1分钟都生成一个快照,低峰期,数据量很少,也没必要
60s 10000--->生成RDB,1000--->RDB,这个根据你自己的应用和业务的数据量,你自己去决定
AOF一定要打开,fsync everysec:每秒从操作系统缓存刷新一次到硬盘
auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%,上次的两倍
auto-aof-rewrite-min-size 64mb: 根据你的数据量来定,如果系统中数据量比较少,那么可以设置成16mb,32mb。如果数据量比较大,那么可以设置成128MB
2、企业级的数据备份方案
RDB非常适合做冷备,每次生成之后,就不会再有修改了
数据冷备份方案:
(1)写crontab定时调度脚本去做数据冷备份
(2)每小时都copy一份rdb的备份,到一个目录中去,仅仅保留最近48小时的备份,这个还是需要根据各自的系统情况来定,也可以每2-3个小时copy一份RDB数据。
(3)每天都保留一份当日的rdb的备份,到一个目录中去,仅仅保留最近1个月的备份(根据需要来定)
(4)每次copy备份的时候,都把太旧的备份给删了
(5)每天晚上将当前服务器上所有的数据备份,发送一份到远程的云服务上去(可以保证当服务器硬盘损坏时,还可以有备份数据恢复)
使用Linux系统中的 crontab 机制进行数据的定时备份:
crontab机制简介:Linux中的定时器机制,可以通过设置,在固定的时间或者间隔一定的时间来执行特定的命令或者shell脚本
创建备份数据的脚本目录:/usr/local/redis/crontab ,每小时copy一次备份,删除48小时前的数据
crontab -e 编辑定时器crontab的命令
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
redis_rdb_copy_hourly.sh
脚本内容:
#!/bin/sh
cur_date=`date +%Y%m%d%k` // ``符号是Tab建上面的符号
rm -rf /usr/local/redis/snapshotting/$cur_date //防止文件冲突,先删除当前重复的文件
mkdir /usr/local/redis/snapshotting/$cur_date //创建当前文件
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date //将当前rdb文件复制到备份目录中del_date=`date -d -48hour +%Y%m%d%k` //得到48小时之前的时间戳
rm -rf /usr/local/redis/snapshotting/$del_date //删除48小时之前的数据chomd 777 redis_rdb_copy_hourly.sh 给当前脚本一个777权限
每天copy一次备份
crontab -e
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh
redis_rdb_copy_daily.sh
#!/bin/sh
cur_date=`date +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_datedel_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date
每天一次将所有数据上传一次到远程的云服务器上去
3、数据恢复方案
(1)如果是redis进程挂掉,那么重启redis进程即可,如果AOF持久化机制开启,那么redis默认直接基于AOF日志文件恢复数据
(2)如果是redis进程所在机器挂掉,那么重启机器后,尝试重启redis进程,尝试直接基于AOF日志文件进行数据恢复AOF没有破损,也是可以直接基于AOF恢复的
AOF append-only,顺序写入,如果AOF文件破损,那么用redis-check-aof fix
(3)如果redis当前最新的AOF和RDB文件出现了丢失/损坏,比如出于人为的原因,失误将/var/redis/6379/dump.rdb文件给删除了。那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复
找到RDB最新的一份备份,小时级的备份可以了,小时级的肯定是最新的,copy到redis里面去,就可以恢复到某一个小时的数据。
appendonly.aof + dump.rdb,优先用appendonly.aof去恢复数据,但是我们发现redis自动生成的appendonly.aof是没有数据的
然后我们自己的dump.rdb是有数据的,但是明显没用我们的数据。
并且在redis启动的时候,自动重新基于内存的数据,生成了一份最新的rdb快照,直接用空的数据,覆盖掉了我们拷贝过去的那份dump.rdb,导致无论是appendonly.apf、还是dump.rdb快照,都没有数据了。
你停止redis之后,其实应该先将redis.conf中的appendonly yes 改为 no ,然后再删除appendonly.aof,最后将我们的dump.rdb拷贝过去,然后再重启redis,数据就可以恢复了。
很简单,就是虽然你删除了appendonly.aof,但是因为打开了aof持久化,redis就一定会优先基于aof去恢复,即使文件不在,那就创建一个新的空的aof文件。
本来很开心,但是脑子一热,再关掉redis,手动修改配置文件,打开aof,再重启redis,数据又没了,空的aof文件,所有数据又没了!!!
在数据安全丢失的情况下,基于rdb冷备,如何完美的恢复数据,同时还保持aof和rdb的双开:
停止redis,关闭aof,删除aof文件,拷贝rdb备份,重启redis,确认数据恢复,直接在命令行热修改redis配置,打开aof,
命令:config set appendonly yes 这时redis就会将内存中的数据对应的日志,写入aof文件中,此时aof和rdb两份数据文件的数据就同步了。可能配置文件中的实际的参数没有被持久化的修改,再次停止redis,手动修改配置文件,打开aof的命令,再次重启redis即可。