reids持久化之AOF

AOF

1 前言

RDB 的缺陷是最后一次持久化后的数据可能丢失。而AOF就是用来解决这个问题的.

2 简介

append only file ,以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis重启后就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作.

3 AOF的重写

• 简介

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof.

• 重写机制

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似.

• 触发条件

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发.

4 配置

#AOF持久化，是否记录更新操作日志，默认redis是异步（快照）把数据写入本地磁盘
appendonly no

#指定更新日志文件名
appendfilename "appendonly.aof"

# 每次有数据发生变化时都会写入appendonly.aof
# appendfsync always
# 默认方式，每秒同步一次到appendonly.aof
appendfsync everysec
# 不同步，数据不会持久化
# appendfsync no

# 当AOF日志文件即将增长到指定百分比时，redis通过调用BGREWRITEAOF是否自动重写AOF日志文件。
no-appendfsync-on-rewrite no

# aof自动重写%比。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb

#aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象。）出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
aof-load-truncated yes

5 演示

将 appendonly no 设置为 appendonly yes.

6 修复

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CjGaZmk5-1590223614333)(E:\redis笔记\AOF损坏.png)]

启动服务器

发现服务器无法启动,看到rdb和aof同时存在,说明优先读取的是AOF文件,因为AOF文件损坏导致启动失败.

修复方法:

[root@dason bin]# redis-check-aof --fix appendonly.aof 
'x              6e: Expected prefix '*', got: '
AOF analyzed: size=196, ok_up_to=110, diff=86
This will shrink the AOF from 196 bytes, with 86 bytes, to 110 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@dason bin]# redis-server /myredis/redis_aof.conf 
14046:C 23 Feb 2020 22:01:25.646 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
14046:C 23 Feb 2020 22:01:25.646 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=14046, just started
14046:C 23 Feb 2020 22:01:25.646 # Configuration loaded
[root@dason bin]# redis-cli -p 6379
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"

7 优劣势

优势: 每秒同步：appendfsync everysec 异步操作，每秒记录 .

劣势:

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb…

如果一秒内宕机，也会有数据丢失.

rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的.