ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

redis学习笔记(14)AOF持久化

2022-05-01 16:33:12  阅读:163  来源: 互联网

标签:AOF 14 文件 redis Redis aof 重写


1、概述

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

2、持久化流程

  • 客户端的请求写命令会被 append 追加到 AOF 缓冲区内;
  • AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中;
  • AOF 文件大小超过重写策略或手动重写时,会对 AOF 文件 rewrite 重写,压缩 AOF 文件容量;
  • Redis 服务重启时,会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

3、开启AOF

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

4、AOF 和 RDB 同时开启,redis 听谁的?

AOF 和 RDB 同时开启,系统默认取 AOF 的数据(数据不会存在丢失)。

5、AOF 启动、修复、恢复

  • AOF 的备份机制和性能虽然和 RDB 不同,但是备份和恢复的操作同 RDB 一样,都是拷贝备份文件,需要恢复时再拷贝到 Redis 工作目录下,启动系统即加载。
  • 正常恢复
    • 修改默认的 appendonly no,改为 yes。
    • 将有数据的 aof 文件复制一份保存到对应目录 (查看目录:config get dir)。
    • 恢复:重启 redis 然后重新加载。
  • 异常恢复
    • 修改默认的 appendonly no,改为 yes。
    • 如遇到 AOF 文件损坏,通过 /usr/local/bin/ redis-check-aof–fix appendonly.aof 进行恢复。
    • 备份被写坏的 AOF 文件。
    • 恢复:重启 redis,然后重新加载。

6、AOF 同步频率设置

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

7、rewrite压缩

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

AOF 文件持续增长而过大时,会 fork 出一条新进程来将文件重写 (也是先写临时文件最后再 rename),redis4.0 版本后的重写,是指把 rdb 的快照,以二进制的形式附在新的 aof 头部,作为已有的历史数据,替换掉原来的流水账操作。

no-appendfsync-on-rewrite:

    • 如果 no-appendfsync-on-rewrite=yes ,不写入 aof 文件只写入缓存,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据。(降低数据安全性,提高性能)
    • 如果 no-appendfsync-on-rewrite=no,还是会把数据往磁盘里刷,但是遇到重写操作,可能会发生阻塞。(数据安全,但是性能降低)

8、触发机制,何时重写

  • Redis 会记录上次重写时的 AOF 大小,默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。
  • 重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定 Redis 要满足一定条件才会进行重写。
    • auto-aof-rewrite-percentage:设置重写的基准值,文件达到 100% 时开始重写(文件是原来重写后文件的 2 倍时触发)。
    • auto-aof-rewrite-min-size:设置重写的基准值,最小文件 64MB。达到这个值开始重写。
    • 系统载入时或者上次重写完毕时,Redis 会记录此时 AOF 大小,设为 base_size,
    • 如果 Redis 的 AOF 当前大小 >= base_size +base_size*100% (默认) 且当前大小 >=64mb (默认) 的情况下,Redis 会对 AOF 进行重写。

例如:文件达到 70MB 开始重写,降到 50MB,下次什么时候开始重写?100MB

9、重写流程

  1. bgrewriteaof 触发重写,判断是否当前有 bgsave 或 bgrewriteaof 在运行,如果有,则等待该命令结束后再继续执行;
  2. 主进程 fork 出子进程执行重写操作,保证主进程不会阻塞;
  3. 子进程遍历 redis 内存中数据到临时文件,客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区,保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失;
  4. 子进程写完新的 AOF 文件后,向主进程发信号,父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件;
  5. 使用新的 AOF 文件覆盖旧的 AOF 文件,完成 AOF 重写。

10、优劣

  • 优势
    • 备份机制更稳健,丢失数据概率更低。
    • 可读的日志文本,通过操作 AOF 稳健,可以处理误操作。
  • 劣势
    • 比起 RDB 占用更多的磁盘空间。
    • 恢复备份速度要慢。
    • 每次读写都同步的话,有一定的性能压力。
    • 存在个别 Bug,造成恢复不能。

 

参考:Redis | ZC 的学习录 (zhangc233.github.io)

 

标签:AOF,14,文件,redis,Redis,aof,重写
来源: https://www.cnblogs.com/mango1997/p/16213151.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有