RedisRDB和AOF持久化

RDB(Redis DataBase)

rdb保存的文件是dupm.rdb(在配置文件中配置)

save 规定时间内,执行多少次操作,就会持久化到文件

在主从复制中,rbd就是备用的,在从机上,因为不占用主机的内存空间

触发机制

1.save的规则满足情况下,会自动触发rdb规则
2.执行flushall命令,也会触发rdb规则
3.退出redis,也会产生rdb文件
备份会自动生成一个dump.rdb 

恢复rdb文件:

只需要将rdb文件放在redis启动目录就可以,redis启动时会自动检查dump.rdb恢复其中的数据

查看存放的位置

 localhost:0>config  get dir
 1)  "dir"
 2)  "D:\redis"  #如果当前目录下存在dump.rdn文件,启动就会自动恢复其中的数据

优缺点

优点

1.适合大规模数据恢复,
2.如果对数据完整性要求不高

缺点

1.需要一定的时间间隔进行操作,如果期间redis意外宕机了,最后一次修改的数据就没了
2.fork进程的时候会占用一定的内存空间

AOF(Append only File)

将所有的命令都记录下来,恢复的时候,吧这个文件全部再执行一遍

以日志的形式记录每一个写的操作(读不做记录),将redis执行过的指令记录下来(读操作不记录),只需追加文件,不可改写文件,redis启动之初会读取改文件重新构建数据,redis启动的话,根据日志文件的内容将写指令从前到后执行一次,以完成数据恢复的工作

aof保存的 是appendonly.aof文件

重写说明

如果aof文件大于64mb,fork一个新的进程将文件进行重写.

aof默认文件无限追加,文件会越来越大

no-appendfsync-on-rewrite no  #是否进行重写

auto-aof-rewrite-percentage 100  #重写基准100
auto-aof-rewrite-min-size 64mb 	#重写最大值64MB

APPEND ONLY MODE

appendonly no #默认不开启,如果要开启aof,改为yes

appendfilename "appendonly.aof"  #生成文件的名字

# appendfsync always	#每次修改都会 sync,消耗性能
appendfsync everysec #每秒执行一次 sync,可能会丢失这一秒的数
# appendfsync no	#不执行sync ,这个时候操作系统自己执行同步,速度是最快的

appendonly no #默认不开启,需要手动配置,改为yes,重启redis就会生效

设置参数

 因为设置了 save 60 5 ,所以生成了aof文件

 查看aof文件,其实内部保存的就是之前操作的命令

 破坏文件后保存

破坏文件后,redis是启动不起来的 

 使用redis提供分修复工具redis-check-aof,修复aof文件

 输入修复命令 redis-check-aof --fix appendonly.aof

文件修复完成后,重启后即可恢复  

优缺点

优点:

1.每次修改都同步,文件完整性更好

2.每秒同步一次,可能会丢失1秒数据

3.如果appendonly no 则从不同步,就会丢失数据,单效率最高

缺点

1.对于数据文件来说,aof远远大于rdb,修复的速度也比rdb慢

2.aof运行效率比rdb慢,所以redis默认rdb持久化

1、RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储。

2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据,，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4、同时开启两种持久化方式 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。 RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库( AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一 次就够了，只保留 save 900 1 这条规则。 如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。 如果不Enable AOF，仅靠Master-Slave Repllcation实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时挂掉，会丢失 十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构。