前言

了解了redis的持久化的原理和操作，但是在企业中，持久化到底是怎么去用得呢？

数据备份和数据恢复

我们需要了解企业级的数据备份和各种灾难下的数据恢复

持久化配置策略

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

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

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

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

数据备份

方案

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

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

crontab未安装： https://www.cnblogs.com/xiaommvik/p/6038907.html

具体操作

进入目录/usr/local/redis

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

redis_rdb_copy_hourly.sh

/usr/local/redis/copy

#!/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

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

每天copy一次备份

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

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

数据恢复方案

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

不演示了，在AOF数据恢复那一块，演示了，fsync everysec，最多就丢一秒的数

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

AOF没有破损，也是可以直接基于AOF恢复的AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix

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

当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，人为大数据系统，hadoop，有人不小心就把hadoop中存储的大量的数据文件对应的目录，rm -rf一下，我朋友的一个小公司，运维不太靠谱，权限也弄的不太好，aof和rdb备份目录/var/redis/6379下的文件给删除了

解决： 找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据

容灾演练

dump.rdb恢复

appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的，然后我们自己备份的dump.rdb是有数据的，但是明显重启后没用我们的数据。

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

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

发现还是没有恢复。

虽然删除了appendonly.aof，但是因为打开了aof持久化 appendonly yes，redis就一定会优先基于aof去恢复，即使文件不在，会创建一个新的空的aof文件，也不会使用我们备份的rdb文件。
停止redis，暂时在配置中关闭aof，然后拷贝一份rdb过来，再重启redis，可以恢复过来
如果关掉redis，手动修改配置文件，重新打开aof (appendonly yes)，再重启redis，数据又没了，空的aof文件，所有数据又没了