【redis】持久化---AOF

AOF开启

在conf文件中，打开即可

 

AOF含义

AOF 保存的是appendonly.aof文件

AOF持久化工作流程

 

AOF缓冲区三种写回策略

进入缓存区

always-->同步写回，每个写命令执行完毕就 立刻将日志写回磁盘

everysec-->间隔1s写回，每个写命令执行完，先放入缓存区，间隔1s后写回磁盘

no--> 不立刻写回，而是将日志放到缓存区，由操作系统决定什么时候写回磁盘

 

AOF案例实操，配置、启动、修复、恢复 

 AOF的配置文件（6 VS  7）

开启AOF

 Appendonly.aof文件存储路径：

 

7以前-->和RDB一个存储路径

7以后-->多了一个前置的 appendonlydir 文件夹不再和RDB存放在一起，因为以前是一个aof文件，现在是三个aof文件

appendonly.aof文件存储形式： 

Multi Part AOF的设计     三个类型详解：base、incr、manifest分别是什么？

小结：redis7以后的config中对应的配置项

 

  

AOF的恢复

正常恢复

 

 异常恢复    写回策略为everysec时，是1s间隔写回磁盘，其中有一部分还在缓存区，这时候incr文件里会有乱码，导致redis都启动失败

异常恢复命令： redis-check-aof --fix

 

AOF优势

INCR文件的知识点：

incr文件可以查看所有的写操作，包括flushall、flushdb，会自动记录在文件中，可以通过Linux文本编辑来删除误操作的命令 ，再重启即可恢复误操作之前的缓存数据

AOF劣势

 小结：

 

 

AOF重写机制

Q：重写机制是什么？

A：启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

 官网默认配置：

 触发机制：

自动触发-->顾名思义，自动触发；默认是当AOF文件大小是上一次重写后大小的一倍，且 文件大于64M时

手动触发-->类似RDB的BGSAVE，在redis命令行中发送bgrewriteaof，进行后台重写

为什么要进行AOF重写？

同一个key保留最新一次的写操作，再以前的写操作都被覆盖了，无意义，所以需要进行重写丢弃

触发重写后：

appendonly.aof 的三个文件名变了，base基本文件是瘦身后的incr数据日志，即保留所有key的最新一次写操作，被覆盖的写操作被丢弃，incr被清空，开始重新记录写操作

bgrewriteaof命令执行后：

立即重写，

 AOF重写的的结论：

重写的原理： 不是整理，是直接读取最新的缓存数据，然后用一条命令记录这些多条命令，再生成一个新的文件去替换原来的AOF文件

 

 

 

AOF优化配置项详解

开启，然后默认即可

 

总结