持久化操作-AOF
AOF是什么?
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只允许加文 件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,Redis重启的话就根据日志 文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF持久化流程
- 客户端的请求写命令会被append追加到AOF缓冲区内。
- AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作同步到磁盘的AOF文件中。
- AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量。
- Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的。
AOF默认不开启
可以在redis.conf中配置文件名称,默认为appendonly.aof。
AOF文件的保存路径,同RDB的路径一致。
如果AOF和RDB同时启动,Redis默认读取AOF的数据。
AOF启动/修复/恢复
- 正常恢复
- 启动:设置Yes:修改默认的appendonly no,改为yes。
- 恢复:重启Redis然后重新加载。
例:设置appendonly为yes,配置修改后,需要重启Redis服务。
服务器启动后,生成appendonly.aof文件,且大小为0。
设置数据。
bash
set k11 v11
set k12 v12
set k13 v13
set k14 v14
set k15 v15
- 异常恢复
- 启动:设置Yes:修改默认的appendonly no,改为yes。
- 修复:如遇到AOF文件损坏,通过/user/local/bin/redis-check-aof --fix appendonly.aof进行 恢复。
- 恢复:重启Redis然后重新加载。
例:服务启动和数据设置同上,模拟损坏appendonly.aof文件
bash
vim appendonly.aof.1.incr.aof
在文件最后追加Hello World文本,破坏appendonly.aof原有格式,使其不可用。
重启Redis服务,并连接。由于aof文件被破坏,导致服务器启动失败。
通过/user/local/bin/redis-check-aof --fix工具对appendonly.aof进行恢复。
bash
redis-check-aof --fix appendonlydir/appendonly.aof.1.incr.aof
修复成功。再次查看aof文件,破坏的地方已经修复。再次启动服务器成功。
AOF同步频率设置
-
appendfsync always
始终同步,每次Redis的写入都会立刻记入日志,性能较差但数据完整性比较好。
-
appendfsync everysec
每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
-
appendfsync no
redis不主动进行同步,把同步时机交给操作系统。
Rewrite
-
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大 小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令 集。
例:设置k1为0,然后incr 进行了4次,k1对应的值会是4,其实就相当于set k1 4
-
重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定 Redis要满足一定条件才会进行重写。
redis.conf默认配置
auto-aof-rewrite-min-size:表示重写时,文件大小必须必这个值要大。
auto-aof-rewrite-percentage:表示目前文件大小比上次重写后的文件大小大这么多才行。