RDB与AOF的选择

36套java高级架构师视频+38套大数据视频  需要视频的加我vx：du13797566440

AOF定义：以日志的形式记录每个操作，将Redis执行过的所有指令全部记录下来（读操作不记录），只许追加文件但不可以修改文件，Redis启动时会读取

AOF配置文件重构数据 换句话说，就是Redis重启就会根据日志内容从头到尾执行一次来完成数据的恢复工作。

Tip:

　　一.RDB与AOF同时开启  默认先加载AOF的配置文件

　　二.相同数据集，AOF文件要远大于RDB文件，恢复速度慢于RDB

　　三.AOF运行效率慢于RDB,但是同步策略效率好，不同步效率和RDB相同

1.RDB持久化(以快照的方式) 策略（默认）：

　　save 900 1       （15分钟检查一次如果有一个key变更重新生成rdb文件）
　　save 300 10     （5分钟检查一次如果有10个key变更重新生成rdb文件）
　　save 60 10000  （1分钟检查一次如果有一个1万变更重新生成rdb文件）
2.RDB默认配置文件名称：

　　dbfilename dump.rdb(只有一个，新的覆盖之前的)

3.表示是否开启AOF持久化：

　　appendonly yes(默认no,关闭) 

4.AOF持久化配置文件的名称：

　　appendfilename "appendonly.aof"

5.AOF持久化策略(默认每秒)：

　　appendfsync always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)

　　appendfsync everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)

　　appendfsync no  （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）

6.AOF配置文件损坏修复方法：

　　进入redis安装路径 执行 redis-check-aof --fix AOF配置文件名称

7.AOF的Rewrite(重写) ：

　　定义：AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制

        　　当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

　　原理：当AOF增长过大时，会fork出一条新的进程将文件重写(也是先写临时文件最后rename)，遍历新进程的内存数据，每条记录有一条set语句。

　　　　   重写AOF文件并没有操作旧的AOF文件，而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件（有点类似快照）

触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

　　　　　auto-aof-rewrite-percentage 100  （一倍）
　　　　   auto-aof-rewrite-min-size 64mb
8.RDB与AOF的选择：

　　做备份：当数据量大，且对恢复速度有要求，并且数据的一致性要求不高的话，可以只使用RDB

　　只做缓存：不用开启任何的持久化方式

　　两者都开启的建议：RDB数据不实时，同时使用两者时服务器只会找AOF文件，可不可以只使用AOF?建议不要，因为RDB更适合备份数据库(AOF在不断变化，不好备份)，快速重启，而且不会又AOF可能潜在的BUG,留作万一的手段。

　　　　　　　　　　

 数据备份和恢复

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


在企业中，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


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


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


数据备份方案


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


/usr/local/redis


每小时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 命令定时执行脚本

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日志文件恢复数据


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


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


AOF没有破损，也是可以直接基于AOF恢复的


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


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


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


大数据系统，hadoop，有人不小心就把hadoop中存储的大量的数据文件对应的目录，rm -rf一下，我朋友的一个小公司，运维不太靠谱，权限也弄的不太好


/var/redis/6379下的文件给删除了


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


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