前言
在企业级的redis持久化中,RDB的生成策略,用默认的就差不多
AOF也一定要打开,fsync,everysec
数据备份
- 写crontab定时调度脚本去数据库备份
- 每小时copy一份rdb的备份,到一个目录中去,仅仅保留近48小时的备份
- 每天保留一份rdb的备份,到一个目录中去,仅仅保留最近1个月的备份
- 每天copy备份的时候,都把太旧的备份删除掉
- 每天晚上将当前服务器上的备份,发送到一个远程的云服务器上
备份目录:/usr/local/redis
小时级备份
先创建定时任务
命令:crontab -e
输入:0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
退出编辑模式保存
redis目录下创建copy和snapshotting目录
copy存放脚本命令
snapshotting存放拷贝过来的持久化文件
在copy下创建脚本
cur_date=`date +%Y%m%d%k`
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
del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date
cur_date:以当前时间生成目录名
rm -rf /usr/local/redis/snapshotting/
c
u
r
d
a
t
e
:
移
除
旧
的
持
久
化
文
件
m
k
d
i
r
/
u
s
r
/
l
o
c
a
l
/
r
e
d
i
s
/
s
n
a
p
s
h
o
t
t
i
n
g
/
cur_date:移除旧的持久化文件 mkdir /usr/local/redis/snapshotting/
curdate:移除旧的持久化文件mkdir/usr/local/redis/snapshotting/cur_date:创建新的目录
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/
c
u
r
d
a
t
e
:
将
r
d
b
持
久
化
文
件
拷
贝
到
新
建
的
目
录
下
d
e
l
d
a
t
e
=
‘
d
a
t
e
−
d
−
48
h
o
u
r
+
r
m
−
r
f
/
u
s
r
/
l
o
c
a
l
/
r
e
d
i
s
/
s
n
a
p
s
h
o
t
t
i
n
g
/
cur_date:将rdb持久化文件拷贝到新建的目录下 del_date=`date -d -48hour +%Y%m%d%k`:获取48小时前的那个文件夹名 rm -rf /usr/local/redis/snapshotting/
curdate:将rdb持久化文件拷贝到新建的目录下deldate=‘date−d−48hour+rm−rf/usr/local/redis/snapshotting/del_date:删除40小时前目录
然后,手动执行一下脚本
可以看到rdb文件已经拷贝过来了
天级备份
天级定时任务创建:0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.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_date
del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date
数据恢复演示
- 如果redis进程挂了,直接重启redis进程,直接基于aof日志文件恢复数据
- 如果是redis进程所在的机器挂了,那么重启redis后,尝试重启redis进程,尝试基于aof日志文件进行数据恢复,aof没有破损,是可以基于aof进行恢复的
aof apped-only,顺序写入,如果aof文件破损,使用redis-check-aof --fix进行修复 - redis当前最新的aof和rdb文件出现了丢失/破损到无法恢复,那么可以尝试当前机器上当前的某个最新的rdb数据副本进行数据恢复
当前最新的aof和rdb文件出现丢失/破损到无法恢复,一般不是机器故障,一般是人为,比如一不小心rm -rf
找到rdb最新的一份备份,小时级的备份,copy到redis里面去,就可以恢复到某一小时的数据
appendonly.aof+dump.rdb,优先使用appendonly.aof去恢复数据,但是我们发现redis自动生成的appendonly.aof是没有数据的
我们的dumo.rdb是明显有数据的,没有用rdb的数据
redis重启时,自动基于内存的数据,生成一份最新的rdb快照,直接用空的数据,覆盖掉我们有数据,也就是刚拷贝过来的dump.rdb文件
停止掉redis后,应该删除掉appendonly.aof文件,然后将dump.rdb文件拷贝过去,重启redis
其实道理很简单,虽然你删除了appendonly.aof文件,但是由于打开了aof持久化,redis一定会优先基于aof去恢复,即使我们删除了aof文件,也会在启动的时候生成一个空的aof文件,暂时在配置中关闭aof持久化,然后拷贝rdb文件过来,这是重启,发现数据是恢复过来了,但是,此时去配置文件中打开aof持久化,重启后,发现数据又没了,还是以前的问题,新生成的aof文件为空,导致优先基于aof恢复的数据为空。
我们要做的是让aof和rdb里面的数据一致
- 首先在config配置文件中把appendonly 设置成no
- 然后,在redis-cli中手动配置成yes
config set appendonly yes
- 此时 cat appendonly.aof文件,发现是和rdb数据是同步的
- 数据保持一致后,再去config文件中将appendonly修改成yes