Redis(二十六)-持久化操作之AOF

举报
码农飞哥 发表于 2022/06/04 23:49:52 2022/06/04
【摘要】 您好,我是码农飞哥,感谢您阅读本文,欢迎一键三连哦。 💪🏻 1. Python基础专栏,基础知识一网打尽,9.9元买不了吃亏,买不了上当。 Python从入门到精通 ❤️ 2. Python爬虫...

您好,我是码农飞哥,感谢您阅读本文,欢迎一键三连哦
💪🏻 1. Python基础专栏,基础知识一网打尽,9.9元买不了吃亏,买不了上当。 Python从入门到精通
❤️ 2. Python爬虫专栏,系统性的学习爬虫的知识点。9.9元买不了吃亏,买不了上当 。python爬虫入门进阶
❤️ 3. Ceph实战,从原理到实战应有尽有。 Ceph实战
❤️ 4. Java高并发编程入门,打卡学习Java高并发。 Java高并发编程入门
😁 5. 社区逛一逛,周周有福利,周周有惊喜。码农飞哥社区,飞跃计划
全网同名【码农飞哥】欢迎关注,个人VX: wei158556

1. 简介

上一篇文章我们介绍了 Redis(二十五)-持久化操作之RDB ,这篇文章接着来介绍另一种持久化的方式AOF。
AOF(Append Only File) : AOF 是以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初就会读取该文件重新构建数据,换言之,redis重启的话会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2. AOF 持久化流程

  1. 客户端的请求写命令会被append追加到AOF缓冲区内
  2. AOF缓冲区根据AOF持久化策略(always,everysec,no) 将操作sync 同步到磁盘的AOF文件中。
  3. AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量。
  4. Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的
    在这里插入图片描述

3. 开启AOF

AOF默认不开启,可以在redis.conf中配置文件名称,默认为appendonly.aof。AOF文件的保存路径,同RDB的路径一致。与AOF相关的配置有两个:

# appendonly 用于指定是否开启AOF,默认为no,我们可以改成yes
appendonly yes
# appendfilename 用于指定aof文件名,默认名称为:appendonly.aof,路径是启动redis-server的路径
appendfilename "appendonly.aof"

 
  • 1
  • 2
  • 3
  • 4

在这里插入图片描述
将配置 appendonly改成yes之后 ,重启redis服务器。可以在启动路径下看到 appendonly.aof 文件。
在这里插入图片描述
PS: AOF 和RDB同时开启,系统默认取AOF的数据(数据不会丢失)
AOF文件的格式;
在这里插入图片描述
在这里插入图片描述
可以在AOF文件中看到set命令的key以及value。

4. AOF启动/修复/恢复

AOF的备份机制和性能虽然和RDB不同,但是备份和恢复的操作和RBD一样,都是拷贝备份文件, 需要恢复时在拷贝到Redis工作目录下,启动Redis系统即加载。

4.1. 正常恢复

  1. 修改默认的 appendonly no,改为yes。
  2. 备份原来的 appendonly.aof 文件为 appendonly.aof.bak,删除最新的 appendonly.aof
  3. 将appendonly.aof.bak 重命名回appendonly.aof。重启Redis服务器。
    在这里插入图片描述

4.2. 异常恢复

  1. 修改默认的appendonly no,改为yes
  2. 如遇到AOF文件损坏,通过/usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复
  3. 备份被写坏的AOF文件
  4. 恢复:重启redis,然后重新加载。

5. AOF同步频率设置

  1. appendfsync always
    始终同步,每次Redis的写入都会立刻记入日志;性能较差但数据完整性较好
  2. appendfsync everysec
    每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失
  3. appendfsync no
    redis 不主动进行同步,把同步时机交给操作系统。

6. Rewrite 压缩

  1. Rewrite压缩是什么?
    AOF 采用文件追加方式,文件会越来越大,为了避免出现这种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最下指令集,可以使用命令 bgrewriteaof
  2. 重写原理,如何实现重写
    AOF文件持续增长而过长时,会fork出一条新进程来将文件重写(也是先写临时文件最后在rename)。redis 4.0 版本后的重写,是指把rdb的快照,以二进制的形式附在新的aof头部,作为已有的历史数据,替换掉原来的流水账操作。

Redis 会记录上次重写的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
重写虽然可以节约大量磁盘空间,减少恢复时间,但是每次重写还是会有一定的负担,因此设定Redis要满足一定的条件才会进行重写。

auto-aof-rewrite-percentage: 设置重写的基准值,文件达到100% 时开始重写(文件是原来重写后文件的2倍时触发)
auto-aof-rewrite-min-size: 设置重写的基准值,最小文件 64MB,达到这个值开始重写。
例如:文件达到70MB开始重写,降到50MB,下次就是100MB的时候开始重写。

7. AOF的优缺点

7.1 优点

  1. 备份机制更稳健,丢失数据概率更低
  2. 可读的日志文件,通过操作AOF文件,可以处理误操作。

7.2 劣势

1、比起RDB占用更多的磁盘空间
2. 恢复备份速度更慢
3. 每次读写都同步的话,有一定的性能压力。

8. 总结

官方推荐两个都启用
如果对数据不敏感,可以单独用RDB
不建议单独用AOF,因为可能会出现BUG
如果只是存内存缓存,可以都不用

文章来源: feige.blog.csdn.net,作者:码农飞哥,版权归原作者所有,如需转载,请联系作者。

原文链接:feige.blog.csdn.net/article/details/125114372

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。