Redis企业级数据备份方案和灾难下的数据恢复

蓝颜～岁月

已于 2022-11-02 21:04:54 修改

阅读量134

点赞数

分类专栏： # Redis实战文章标签： redis 数据库缓存

于 2022-11-02 21:00:20 首次发布

本文链接：https://blog.csdn.net/weixin_40172337/article/details/127658455

版权

Redis实战专栏收录该内容

5 篇文章 0 订阅

订阅专栏

企业级持久化的配置策略

在企业中，RDB的生成策略，用默认的也差不多

save 900 1
save 300 10
save 60 10000

save 60 10000 如果你希望尽可能确保说，RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照，低峰期，数据量很少，也没必要

10000->生成RDB，1000->RDB，这个根据你自己的应用和业务的数据量，你自己去决定

AOF一定要打开，fsync，everysec

# appendfsync always #总是
appendfsync everysec #每秒持久化
# appendfsync no #不自动

#就是当前AOF大小膨胀到超过上次100%，上次的两倍
auto-aof-rewrite-percentage 100
#根据你的数据量来定，16mb，32mb
auto-aof-rewrite-min-size 64mb

企业级的数据备份方案

RDB非常适合做冷备，每次生成之后，就不会再有修改了

数据备份方案：

写crontab定时调度脚本去做数据备份
每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份
每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份
每次copy备份的时候，都把太旧的备份给删了
每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去，例如：阿里云

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

文件名：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 /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

crontab -e 添加定时器

#每小时执行如下脚本
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

每天copy一次备份

文件名：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_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

数据恢复方案

如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据
如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复：

AOF没有破损，也是可以直接基于AOF恢复的
AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof --fix
如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复:

appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的，然后我们自己的dump.rdb是有数据的，但是明显没用我们的数据，优先使用AOF 文件【也是因为我们开启AOF持久化】

redis启动的时候，自动重新基于内存的数据，生成了一份最新的rdb快照，直接用空的数据，覆盖掉了我们有数据的，拷贝过去的那份dump.rdb

在数据安全丢失的情况下，基于rdb冷备，如何完美的恢复数据，同时还保持aof和rdb的双开:

停止redis，关闭aof，拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置，打开aof 这个redis就会将内存中的数据对应的日志，写入aof文件中，此时aof和rdb两份数据文件的数据就同步了。

redis config set热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis
如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据
如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复

举个例子，12点上线了代码，发现代码有bug，导致代码生成的所有的缓存数据，写入redis，全部错了，找到一份11点的rdb的冷备，然后按照上面的步骤，去恢复到11点的数据，这样就可以了