以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只允许追加文件不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
相关的配置项:
appendonly:
appendfilename:
appendfsync:
always : 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好
everysec : 出厂默认推荐,异步操作,美妙记录。如果一秒内宕机,有数据丢失
no
no-appendfsync-on-rewrite: 重写时是否可以运用appendfsync,用默认no即可,保证数据安全性
auto-aof-rewrite-min-size: 设置重写的基准值
auto-aof-rewrite-percentage: 设置重写的基准值
AOF启动/修复/恢复
正常恢复
启动:设置为yes,修改默认的appendonly no,改为yes
异常恢复
启动:设置为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时触发。
优势
每秒同步 : appendfsync always 同步持久化 , 每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好
每修改同步 : appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
不同步 :appendfsync no 从不同步
总结
- AOF文件是一个只能进行追加的日志文件
- Redis可以在AOF文件体积变得过大时,自动的在后台对AOF进行重写
- AOF文件有序地保存了对数据库执行的所有写操作,这些写操作以Redis协议的格式保存,因此AOF文件的内容非常容易被别人读懂,对文件进行分析也很轻松
- 对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积
- 根据所使用的fsync策略,AOF的速度可能会慢于RDB
官方建议
RDB持久化方式能够在指定的时间间隔对数据进行快照存储,AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,
AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。