redis缓存架构详解（四）-redis数据备份方案及数据恢复容灾演练3. 数据备份方案及数据恢复容灾演练

65 阅读 0 评论 43 点赞

我是靠谱客的博主忧心曲奇，最近开发中收集的这篇文章主要介绍redis缓存架构详解（四）-redis数据备份方案及数据恢复容灾演练3. 数据备份方案及数据恢复容灾演练，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

3. 数据备份方案及数据恢复容灾演练

以上对redis的持久化的原理和操作进行了讲解，但是在企业中，持久化到底是怎么去用得呢？
企业级的数据备份和各种灾难下的数据恢复，是怎么做得呢？本节将对redis企业级数据备份方案，以及各种踩坑的数据恢复进行容灾演示。

3.1. 持久化的配置策略

在企业中，RDB的生成策略，用默认的也可以：

save 60 10000 ：1分钟内有10000个key值发生变化，就生成RDB，这个根据应用和业务的数据量来决定。

如果你希望RDB丢失数据少，如RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照。在低峰期，数据量很少，时间上可以设置久一点。
AOF一定要打开，fsync，everysec

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

3.2. 数据备份方案

RDB非常适合做冷备，每次生成之后，就不会再有修改了。
数据备份方案

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

使用crontab定时调度脚本做数据备份。

crontab 格式：

*　　*　　*　　*　　*　　command
分　 时　 日　 月　 周　
命令
第1列表示分钟1～59 每分钟用*或者 */1表示
第2列表示小时1～23（0表示0点）
第3列表示日期1～31
第4列表示月份1～12
第5列标识号星期0～6（0表示星期天）
第6列要运行的命令

Crontab 选项:

crontab –e : 修改 crontab 文件. 如果文件不存在会自动创建。
crontab –l : 显示 crontab 文件。
crontab -r : 删除 crontab 文件。
crontab -ir : 删除 crontab 文件前提醒用户。

示例1：每小时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定时调度任务中

crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

示例2：每天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定时调度任务中

crontab -e
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

每天一次将所有数据上传一次到远程的云服务器上去

3.3. 数据恢复方案

3.3.1.常见的几种数据恢复方案

1、如果是redis进程挂掉

如果是redis进程挂掉，那么重启redis进程，只要开启了AOF持久化机制，redis会直接基于AOF日志文件恢复数据。

我们已经在上文AOF数据恢复部分，对AOF日志文件恢复数据，使用fsync everysec 策略进行了演示，演示结果最多丢失一秒的数。

2、如果是redis进程所在机器挂掉

如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，如果AOF没有破损，也是可以直接基于AOF日志文件进行数据恢复。

AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix 进行文件修复。

3、如果redis当前最新的AOF和RDB文件出现了丢失/损坏

如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复。

当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，大部分是人为因素。

3.3.2. 容灾演练：AOF+RDB两种方式进行数据恢复

原理：appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据，
模拟实验：将redis备份文件 /var/redis/6379 下的文件给删除，然后使用备份文件进行恢复。
找到RDB最新的一份备份，copy到redis里面去，查看数据恢复情况。

情况1：重启redis后，redis自动生成空的appendonly.aof文件，而我们copy过来的dump.rdb是有数据，此时，redis数据没有恢复。

分析：因为redis恢复数据，首先是基于aof文件进行恢复，redis启动的时候，自动重新基于内存的数据，生成一份最新的appendonly.aof，如果appendonly.aof不存在，就会生成空的appendonly.aof文件，然后redis基于空的appendonly.aof文件进行数据恢复，不会用到我们之前的冷备份文件dump.rdb,所以，数据恢复失败。

情况2：在停止redis之后，先删除appendonly.aof，然后将我们的dump.rdb拷贝过去，然后再重启redis，数据恢复失败。

分析：虽然删除了appendonly.aof，但是因为打开了aof持久化，redis就一定会优先基于aof去恢复，即使文件不在，那就创建一个新的空的aof文件

情况3：停止redis，暂时在配置中关闭aof，然后拷贝一份rdb过来，再重启redis，数据能不能恢复过来，可以恢复过来。

情况4：:再关掉redis，手动修改配置文件，打开aof，再重启redis，数据又没了，redis又生成空的aof文件，所有数据又没了。

3.3.3. 完美的恢复数据方法

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

正确操作步骤：

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

此时aof和rdb两份数据文件的数据就同步了

redis 热修改配置参数命令：

root@cache01 6379]# redis-cli
127.0.0.1:6379>config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379>config set appendonly yes
OK
127.0.0.1:6379>

注意：

redis 的 config set 热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，当内存中的数据同步到aof文件后，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis。

3.3.4. 当前服务器上的所有RDB全部损坏的数据恢复方案

如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据。

3.3.5. 重大数据错误，导致数据污染解决方案

 如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复。
举个例子，12点上线了代码，发现代码有bug，导致代码生成的所有错误的缓存数据都写入了redis，那怎么办呢？我们可以找到一份11点的rdb的冷备，然后按照上面的步骤，去恢复到11点的数据，就可以了。