大家好,我是悟空呀。
Redis 的 RDB 持久化方案,相信大家都有所了解,但是对于企业来说,如果只是持久化了一个 RDB 文件,不足以应付生产级别的事故。
通常的方案就是对 RDB 进行多个备份,今天带大家来真枪实弹操作下 RDB 的冷备,以及通过 RDB 进行数据恢复。学会了这招,今晚可以好好睡觉了吗?
企业级冷备方案
Redis RDB 持久化是非常适合做企业级的冷备方案的,这里的冷备可以理解为将已生成的文件拷贝到其他机器或者云服务器上。
RDB 适合做冷备的原因如下:
-
RDB 文件生成后,改变的频率低,除非频繁触发检查点导致重新生成。
-
RDB 是 Redis 内存快照,比 AOF 日志恢复速度快。
-
RDB 的生成策略可以自行配置,而且可以配置多项,可以根据系统的使用场景和实际情况进行设置。
备份方案
1、用 Linux 自带的 crontab 命令执行定时任务,调用数据备份脚本。
2、每小时备份一份一次当前最新的 RDB 快照文件到指定目录,只保留最近 48 小时的备份。
3、每天备份一份当前最新的 RDB 快照文件到指定目录,只保留最近一个月的 备份。
4、每天晚上将备份文件都发送远程的云服务器上。
流程图如下所示:
每小时备份
首先需要编写一个脚本,专门用来做数据备份,创建脚本的命令如下:
mkdir /usr/local/redis
mkdir /usr/local/redis/copy
vi /usr/local/redis/copy/redis_rdb_copy_hourly.sh
mkdir /usr/local/redis/snapshotting
chmod 777 /usr/local/redis
然后编写这个脚本文件:
#!/bin/sh
cur_date=`date +%Y%m%d%H`
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`
rm -rf /usr/local/redis/snapshotting/$del_date
脚本解释:
-
cur_data 代表当前时间,精确到小时,比如 2021080616。
-
删除当前小时的快照文件。
-
创建当前小时的备份文件,文件为空的。
-
拷贝当前的快照文件到上一步创建的空的备份文件中。
-
del_date 代表 48 小时以前的时间,精确到小时,比如 2021080416。
-
删除 48 小时以前的备份文件。
设置定时任务,每个小时的 0 分跑一次脚本:
crontab -e
0 * * * * sh /usr/local.redis/copy/redis_rdb_copy_hourly.sh
因为要等到下一个小时的 0 点,所以就手动运行脚本来测试:
cd /usr/local/redis/copy
./redis_rdb_copy_hourly.sh
会在 snapshotting 文件夹创建一个目录:2021080809,表示这是 2021-08-08 09 时的备份文件夹(注意这个时间是 UTC 时间)。这个目录里面还会有一个 dump.rdb 文件。如下图所示:
每天备份
和每小时备份类似,先创建一个每天备份一次的脚本:
vi /usr/local/redis/copy/redis_rdb_copy_daily.sh
chomd 777 *
编写脚本:
#!/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_date
del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date
创建每天备份一次的定时任务:
crontab -e
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh
手动执行备份脚本:
cd /usr/local/redis/copy
./redis_rdb_copy_daily.sh
会在 snapshotting 文件夹创建一个目录:20210808,表示这是今天 2021-08-08 的备份文件夹(注意这个时间是 UTC 时间)。这个目录里面还会有一个 dump.rdb 文件。如下图所示:
另外这些备份建议都上传到云服务器上,多个地方备份增加一份安全感。(云服务同步的后续再介绍。)
今晚就可以睡个安稳觉了~
从备份文件中恢复
假设一种场景:几个小时前上线的程序把 Redis 的数据都污染了,数据错了,该怎么办?
可以选择某个更早的时间点的备份文件进行恢复。
恢复的流程
-
停止 Redis,暂时关闭 AOF 的持久化配置。
-
删除 AOF 日志文件和 RDB 快照文件。
-
拷贝 RDB 快照文件到 Redis 的 RDB 文件加载目录。
-
重启 Redis,确认数据恢复成功。
-
热修改 Redis 的 AOF 持久化配置,Redis 会将内存中的数据写入到 AOF 文件中。
-
再次停止 Redis,手动修改配置文件,打开 AOF 持久化,防止热修改不生效。
-
再次重启 Redis。
– END –
本文分享自微信公众号 – 悟空聊架构(PassJava666)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
{{m.name}}
原创文章,作者:kepupublish,如若转载,请注明出处:https://blog.ytso.com/91582.html