redis数据持久化-AOF

之前写了基于RDB 实现redis 持久化，RDB会丢失最后一次备份之后的数据，如果要追求数据的完整性，就要考虑AOF(Append Only File)

AOF

• AOF特点

• 以日志的形式来记录所有写操作
• 日志文件是以追加的方式的来记录
• redis 的AOF 恢复方式把所有追加的文件从开始到结束全部执行一遍

• 优势

• AOF以秒为单位进行备份，如果发生问题只丢失最后一秒的数据
• 以log的日志形式进行追加，如果磁盘满了，会执行redis-check-aof 工具
• 当日志文件数据量太大的时候redis会在后台重写AOF文件，重写的过程也是fork新的进程进行操作
• AOF日志包含所有的写操作，会便于redis的解析恢复

• 劣势

• 相同的数据，AOF比RDB大
• 在同步情况下AOF的操作会比RDB慢

• 配置文件

# AOF默认是关闭的
appendonly yes
# aof的文件名
appendfilename "appendonly.aof"
# no: 写入aof文件，不等待磁盘同步
# everysec: 每秒备份，推荐使用
# always: 每次操作都会备份，数据最完整的，但性能差
appendfsync everysec
# 重写的时候是否要同步，yes是不同步，会导致数据不一致
# no同步阻塞，相当于重写过程中数据无法写入
no-appendfsync-on-rewrite no
# 重写机制：避免文件越来越大，自动优化文件大小，会fork一个新的进程去完成重写日志的操作
# 当AOF文件的大小比上次多了100%相当于两倍
# 文件大小达到了64mb
# 两个条件同时满足则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• 命令执行

127.0.0.1:6379> 
127.0.0.1:6379> set guan 123
OK
127.0.0.1:6379> get guan
"123"
127.0.0.1:6379> 

• appendonly.aof
  

• 查看文件
  
  文件中记录了redis 命令，数据恢复时逐条回复。

• 持久化文件操作

appendonly.aof ： 文件一旦进行修改，redis 启动会失败，可以修复该文件

• 文件修改
  
• 启动

[root@localhost bin]# redis-server  redis.conf 
39001:C 21 May 2020 21:31:02.083 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
39001:C 21 May 2020 21:31:02.083 # Redis version=6.0.1, bits=64, commit=00000000, modified=0, pid=39001, just started
39001:C 21 May 2020 21:31:02.083 # Configuration loaded
[root@localhost bin]# ps -ef|grep redis
root      39017  38726  0 21:31 pts/0    00:00:00 grep --color=auto redis
[root@localhost bin]# 

redis启动失败

• 修复

[root@localhost bin]# redis-check-aof --fix appendonly.aof 
'x              37: Expected prefix '*', got: '
AOF analyzed: size=73, ok_up_to=55, diff=18
This will shrink the AOF from 73 bytes, with 18 bytes, to 55 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@localhost bin]# 

文件修复后，redis 启动成功。文件修复时会自动删除，错误之后命令

RDB&AOF比较

• 如果能接受一段时间的缓存丢失，就可以选择RDB
• 如果对实时性要求比较高，就可以使用AOF
• 如果将RDB和AOF一起使用，相当于RDB做冷备，AOF做热备

总结

redis 提供了两种持久化方式，各有优缺点，根据实际需求，选择使用哪种，或者两种同时使用。如果后开启AOF 配置，注意启动时，数据可能会丢失，提前做好配置