AOF = Append Only File
- 打开aof功能
appendonly yes
- 指定aof文件
appendfilename "appendonly.aof"
- 修复aof备份文件
# linux命令
redis-check-aof --fix [aof文件的路径]
# redis-check-aof是redis文件夹下的一个程序
# 会将文件中不符合aof记录规范语法的内容删除
# 由于各种可能发生的情况会造成aof记录文件破损,这时就可以在启动redis之前执行下这个命令
- Appendfsync
# 配置文件中
appendfsync always
# 同步持久化,每次发生数据变更会立即记录到磁盘,性能较差,但数据完整性比较好
appendfsync everysec
# 出场默认推荐,异步操作,美妙记录,如果一秒内宕机,有数据丢失
appendfsync no
# no表示等操作系统进行数据缓存同步到磁盘
# 好像效果就是从不同步
- rewrite
- 是什么:AOF采用文件追加方式,文件会越来越大,为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令
bgrewriteaof
- 重写原理:AOF我文件持续增长而过大时,会fork出一条心进程来将文件重写(也是先写临时文件最后再rename),遍历新进程内存中数据,每条记录有一条的set语句.重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似
- 触发机制:Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍,且文件大于64M时触发
# 触发机制在redis.conf中配置,下面的是默认的
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
- No-appendfsync-no-rewrite:重写时是否可以运用appendfsync,用默认no即可,保证数据安全性
- 优势: 持久化保存的数据比较完整
- 劣势:
- 相同数据集的数据而言aof文件要远大于rdb文件,恢复速率慢于rdb
- AOF运行效率要慢于RDB,每秒同步策略效率较好,不同步效率和RDB相同
-
总结
- AOF文件是一个只进行追加的日志文件
- redis可以再aof文件体积变得过大时,自动地在后台对aof进行重写
- aof文件有序地保存了对数据库执行的所有写入操作,这些写入操作以redis协议的格式保存,因此aof文件的内容非常容易被人读懂,对文件进行分析也很轻松
- 对于相同的数据集来说,aof文件的体积通常要大于rdb文件的体积
- 根据所使用的fsync策略,aof的速度可能会慢于rdb
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作你到文件末尾,Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
- 只做缓存:如果你只希望你的数据再看服务器运行的时候存在,你可以不适用任何持久化方式
- 同时开启两种持久化方式
在这种情况下,当redis重启的时候会有限载入aof文件来恢复原始的数据,
因为在通常情况下aof文件保存的数据集要比rdb文件保存的数据集要完整.
RDB的数据不实时,同时使用两者时服务器重启也只会找aof文件.
那要不要只使用AOF呢?
建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),
快速重启,而且不会有AOF可能潜在bug,留着作为一个玩意的手段
