一直很好奇，在企业中，持久化到底是怎么去用得呢？
企业级的数据备份和各种灾难下的数据恢复，是怎么做得呢？

文章目录

• 1、企业级的持久化的配置策略[ul]1.1 rdb持久化策略
• 1.2 AOF持久化策略
• 1.3 AOF rewrite操作

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

3、数据恢复方案

[/ul]

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

在企业中，一般都是RDB和AOF都会打开。

1.1 rdb持久化策略

RDB的生成策略，用默认的也差不多。

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

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

1.2 AOF持久化策略

AOF一定要打开

fsync everysec

1.3 AOF rewrite操作

aof rewite配置呢？

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

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

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

数据备份方案

（1）写

crontab

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

mkdir /usr/local/redis
cd /usr/local/redis
mkdir copy
cd copy/
vi redis_rdb_copy_hourly.sh

每小时copy一次备份，删除48小时前的数据,
脚本如下：

#!/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%H`
rm -rf /usr/local/redis/snapshotting/$del_date

设置所有人可以读写及执行

chmod 777 redis_rdb_copy_hourly.sh

建立一个保存备份文件的地方：

/usr/local/redis/snapshotting/

cd ..
mkdir snapshotting

然后使用定时任务，linux自带的：

crontab -e

写入文件，每小时执行一次

redis_rdb_copy_hourly.sh

文件

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

ps:如果遇到时间不准确的时候，我们需要自己设置一下当前的时间

date -s "20200502 11:00:00"    设置系统时间 记得加引号

同样，每天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

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

3、数据恢复方案

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

（2）如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复
AOF没有破损，也是可以直接基于AOF恢复的,AOF append-only，顺序写入，如果AOF文件破损，那么用

redis-check-aof fix

（3）如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复,
找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据。
appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的
然后我们自己的dump.rdb是有数据的，但是明显没用我们的数据
redis启动的时候，自动重新基于内存的数据，生成了一份最新的rdb快照，直接用空的数据，覆盖掉了我们有数据的，拷贝过去的那份dump.rdb

你停止redis之后，其实应该先删除appendonly.aof，然后将我们的dump.rdb拷贝过去，然后再重启redis

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

所以，停止redis之后，必须暂时在配置中关闭aof！！！，然后拷贝一份rdb过来，再重启redis，可以恢复过来

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

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

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

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

热修改配置参数：

redis config set

热修改可能配置文件中的实际的参数没有被持久化的修改，可以再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis即可。

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

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

以上均是来自龙果学院中华石衫老师的课程，很厉害，这是自己根据老师的笔记加上自己的实践整理的学习笔记，仅此而已。
此文章仅代表自己（本菜鸟）学习积累记录，或者学习笔记，如有侵权，请联系作者删除。人无完人，文章也一样，文笔稚嫩，在下不才，勿喷，如果有错误之处，还望指出，感激不尽~

技术之路不在一时，山高水长，纵使缓慢，驰而不息。

公众号：秦怀杂货店