04.简单了解一下Redis企业级数据备份方案

一、企业级的持久化的配置策略

---

（1）每隔1分钟去检查如果超过10000个可以变更，则生成一个快照。RDB最多丢1分钟的数据。

save 60 10000

（2）AOF一定要打开，fsync，everysec

#就是当前AOF大小膨胀到超过上次100%，上次的两倍
auto-aof-rewrite-percentage 100
#最小触发size
auto-aof-rewrite-min-size 64mb

 

 

二、企业级的数据备份方案

---

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

数据备份方案

（1）写一个linux服务器的crontab命令定时调度脚本去做数据备份

（2）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份

（3）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份

（4）每次copy备份的时候，都把太旧的备份给删了

（5）每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去

 

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

crontab -e

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`
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

 

• 每天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_date

del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date

 

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

 

 

三、数据恢复方案

---

（1）如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据

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

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

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

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

（5）如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复

举个例子，12点上线了代码，发现代码有bug，导致代码生成的所有的缓存数据，写入redis，全部错了

找到一份11点的rdb的冷备，然后按照上面的步骤，去恢复到11点的数据，不就可以了吗

 

 

四、容灾演练

---

• 场景：

我们希望redis数据恢复到某一个时间点，所以选择那个时间点的RDB文件进行恢复，我们拷贝RDB到服务器中。把原来的aof文件删掉。

注意：我们此时使用的是混合持久化机制。会优先用AOF文件去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的，而我们拷贝的dump.rdb是有数据的。

 

• 错误操作

edis启动，会自动生成一个空的AOF文件，并使用这个空的AOF恢复数据，又自动重新基于内存的数据生成了一份最新的空的rdb快照，覆盖掉了我们有数据的拷贝过去的那份dump.rdb

 

• 原因分析

虽然你删除了appendonly.aof，但是因为打开了aof持久化，redis启动就一定会优先基于aof去恢复，即使文件不在，那就创建一个新的空的aof文件，导致redis恢复后又是空的，又生成了一个空的RDB文件，结果数据恢复失败了。

 

• 调整操作：

停止redis，应该先暂时在配置中关闭aof，然后拷贝一份rdb过来，再重启redis，数据就会使用RDB进行数据恢复，可以恢复过来，这一步是对的

如果此时脑子一热，再关掉redis，手动修改配置文件，打开aof，再重启redis，数据又没了，空的aof文件，所有数据又没了。

 

• 最终正确操作

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

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

#使用命令打开AOF
redis-cli config set appendonly yes

（2）redis config set热修改配置参数，可是配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis，完美！

 

 

---

hi~我是Mirror，一个为了自由安逸的未来而不断前进的的程序员。

如果你觉得文章对你有一点点帮助，一个小小赞，便是对我的认可，如果有不足之处，也欢迎各位指正。