Redis持久化RDB与AOF

RDB（Redis DateBase）

什么是RDB
在主从复制中，rdb就是备用了！从机上面！

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建( fork ) 一个子进程来进行持久化。会先将数据写入到一个临时文件中.待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感.那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB.。一般情况下不需要修改这个配置!

实际生产需要备份dump.rdb文件

==rdb保存的文件时dump.rdb == 在配置文件中快照中进行配置的！

自己定义一个测试，60s内修改五次key，触发rdb操作

触发机制

1、save的规则满足情况下，自动触发rdb规则
2、执行flushall，也会触发rdb规则
3、退出redis（shutdown），也会产生rdb文件

恢复rdb文件

1、将rdb文件放入redis启动目录就可以，redis启动的时候就会自动检测dump.rdb恢复其中数据！
2、查看需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" #如果在这个目录存在dump.rdb 文件，启动就会自动恢复其中数据

优缺点

AOF(Append Only File)

将我们所有命令都记录下来，恢复的时候 就把这个文件全部执行一遍！

append

默认不开启，需要手动配置！
重启redis就会生效！
如果aof文件有错误，这个时候redis无法启动成功，我们需要修复aof文件
redis 给我们提供了一个工具 redis-check-aof

[root@jandmla bin]# redis-check-aof --fix appendonly.aof 
0x              4d: Expected \r\n, got: 6164
AOF analyzed: size=91, ok_up_to=52, ok_up_to_line=19, diff=39
This will shrink the AOF from 91 bytes, with 39 bytes, to 52 bytes
Continue? [y/N]: y
Successfully truncated AOF

如果文件正常，重启可以直接恢复！

appendonly no #默认不开启，默认使用rdb方式持久化，在大部分情况，rdb够用！
appendfilename "appendonly.aof"  #持久化的文件名字

# appendfsync always #每次修改都会sync（同步），消耗性能
appendfsync everysec #每秒执行一次sync，可能会丢失这1s数据！
# appendfsync no #不执行，自己同步数据，速度最快！

#rewrite 重写

重写规则说明

aof默认就是文件的无限追加，文件会越来越大！

如果文件大于m，太大了！fork一个新的进程来讲文件进行重写！

优缺点

总结