redis持久化之aof

Redis的AOF持久化通过记录所有写操作日志,确保数据安全。在正常恢复时,若删除flushall命令,数据可在重启后恢复。异常情况下,可通过Redis-check-aof修复。AOF重写机制避免文件过大,当文件超过预设阈值时,创建最小指令集的新的AOF文件。AOF同步策略包括每次同步、每秒同步和不同步,各有优缺点。AOF文件通常比RDB大,恢复速度慢,但提供更好的数据完整性。
摘要由CSDN通过智能技术生成

redis持久化之aof

概念

以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

Aof保存的是appendonly.aof文件

配置文件位置

在这里插入图片描述

AOF启动/修复/恢复

正常恢复

1修改配置文件
在这里插入图片描述
2启动redis,写2次,然后flushall.查看aof文件,恢复发现并没有数据,在aof文件中删除掉flushall命令,再次启动redis,发现数据存在。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

异常恢复

1备份aof文件,修改aof文件,加入不符合redis语法的内容
2尝试启动redis,无法启动
3使用Redis-check-aof --fix进行修复
4重启redis,正常
在这里插入图片描述
在这里插入图片描述

Rewrite

概念:AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
原理:AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
触发机制:Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

优缺点

优点:
1每修改同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
2每秒同步:appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
3不同步:appendfsync no 从不同步
缺点:
1相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
2Aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

总结

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值