AOF是以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取改文件重新构架数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
1.默认情况下
appendonly是no,开启需要设置为yes
2.appendfilename后缀为.aof
3.appendfsync:
always:同步持久化 每次发生数据变更会被立即记录到磁盘,性能较差单数据完整性比较好
everysec: 出厂默认推荐,异步操作,每秒记录 ,如果一秒内宕机,有数据丢失
No:
4.no-appendfsync-no-rewrite:重写时是否可以运用apppendfsync,用默认no即可,保证数据安全性。
auto-aof-rewrite-min-size:设置重写的基准值
auto-aof-rewrite-percentage:设置重写的基准值
4.AOF正常恢复:
修改默认的appendonly no,改为yes
将有数据的aof文件复制一份保存到对应的目录(config get dir)
恢复:重启redis然后重新加载
异常恢复:
修改默认的appendonly no,改为yes
备份被写坏的AOF文件
修复:Redis-check-aof --fix 进行修复
恢复:重启redis然后重新加载
rewrite:
AOF采用文件追加大小,文件会越来越大为避免出现将此种情况,新增了重写机制,当AOF文件的大小超过所设定的阀值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof
重写原理
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后在rename),遍历新进程的内存中数据,每条记录有一条的set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用用命令的方式重写了一个新的aof文件,这点和快照有点类似
触发机制:
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
总结
AOF文件时一个只进行追加的日志文件
Redis可以在aof文件体积变得过大时,自动地在后台对AOF进行重写
AOF文件有序地保存了对数据库执行的所有写入操作,这些写入操作以redis协议的格式保存,因此aof文件的内容非常容易被人读懂,对文件进行分析也很轻松
对于相同数据集来说,aof文件的体积通常大于rdb文件的体积
根据所使用的fsync策略,aof的速度可能会慢于rdb