1.AOF(Append Only File)
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2.文件名称
Aof保存的是appendonly.aof文件
3.配置
1).appendonly配置AOF持久化,默认关闭,启用是修改成yes
2).appendfilename文件名,默认appendonly.aof
3).Appendfsync可选值
-
-
Always:同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
-
Everysec:出厂默认推荐,异步操作,每秒记录 如果一秒内宕机,有数据丢失
-
No
-
4).No-appendfsync-on-rewrite:重写时是否可以运用Appendfsync,用默认no即可,保证数据安全性。
5).Auto-aof-rewrite-min-size:设置重写的基准值,默认当文件增长一倍或者大于64M后就会重写文件。
6).Auto-aof-rewrite-percentage:设置重写的基准值
4.AOF启动/备份/恢复/修复
1).启动
启动:设置Yes,修改默认的appendonly no,改为yes
启动aof配置,会在当前目录下自动生成appendonly.aof文件
执行的所有写操作,都会以日志的形式记录下来
appendonly.aof文件内容
2).备份
备份:将有数据的aof文件复制一份保存到对应目录(config get dir)
3).恢复
正常恢复:aof文件未损坏,重启redis然后重新加载
异常恢复:若网络异常或其他原因导致appendonly.aof文件损坏。使用Redis-check-aof --fix进行修复,打开appendonly.aof文件手动损坏。然后使用redis-check-aof --fix进行修复。
这里在aof文件中加入乱码。
执行redis-check-aof --fix 文件名
修复成功
再次启动redis,启动成功
5. Rewrite
1).概念:AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,
当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,
只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。
2).原理:AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
3).触发机制:Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
6.优势:
1).每修改同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
2).每秒同步:appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
3).不同步:appendfsync no 从不同步
7.劣势:
1).相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
2).Aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同
8.总结