llp-blog

Appearance

Redis持久化-AOF ​

1.官方资料 ​

在线文档 : https://redis.io/topics/persistence

2.AOF 是什么? ​

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

3.AOF 持久化流程 ​

1、持久化流程示意图

image-20230124122242089

2、解读上图

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

4.AOF 开启 ​

1、在 redis.conf 中配置文件名称，默认为 appendonly.aof

image-20230124122333607

2、AOF 文件的保存路径，同 RDB 的路径一致。 3、AOF 和 RDB 同时开启，系统默认取 AOF 的数据 4、当开启 AOF 后, Redis 从 AOF 文件取数据.

image-20230124213158781

image-20230124213424254

5.AOF 实例演示 ​

1、需求：开启 AOF 机制, 使用 AOF 机制进行 Redis 内存数据的备份和恢复

  • 确保 Redis 开启了 AOF 机制

image-20230124213628907

image-20230124213734264

image-20230124213830622

​ 查看aof文件

image-20230124214057875

6.AOF 启动/修复/恢复 ​

1.基本说明

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

2.正常恢复

1、修改默认的 appendonly no，改为 yes 2、将有数据的 aof 文件定时备份, 需要恢复时, 复制一份保存到对应目录(查看目录：config get dir) 3、恢复：重启 redis 然后重新加载 4、和前面 RDB 备份/恢复机制类似

3.异常恢复

1、如遇到 AOF 文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复 2、建议先: 备份被写坏的 AOF 文件 3、恢复：重启 redis，然后重新加载

image-20230124214358207

image-20230124214435967

image-20230124214551305

image-20230124214708879

修复文件

shell
[root@localhost ~]# redis-check-aof --fix appendonly.aof 
0x              7c: Expected prefix '*', got: 'h'
AOF analyzed: size=140, ok_up_to=124, ok_up_to_line=32, diff=16
This will shrink the AOF from 140 bytes, with 16 bytes, to 124 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@localhost ~]#

image-20230124215005298

7.同步频率设置 ​

1、配置位置，redis.conf文件中

image-20230124215132256

2、解读上图

appendfsync always

（谨慎使用）：每条 Redis 操作命令都会写入磁盘，最多丢失一条数据

appendfsync everysec

（默认）：每秒钟写入一次磁盘，最多丢失一秒的数据

appendfsync no

redis 不主动进行同步，把同步时机交给操作系统

（不推荐）：由操作系统决定何时写入磁盘，Linux 默认 30s 写入一次数据至磁盘

参考：https://baijiahao.baidu.com/s?id=1740774723808931509&wfr=spider&for=pc

8.Rewrite 压缩 ​

  • rewrite 重写介绍
  1. AOF 文件越来越大，需要定期对 AOF 文件进行重写达到压缩
  2. 旧的 AOF 文件含有无效命令会被忽略，保留最新的数据命令 , 比如 set a a1 ; set a b1 ; set a c1; 保留最后一条指令就可以了
  3. 多条写命令可以合并为一个 , 比如 set a c1 b b1 c c1
  4. AOF 重写降低了文件占用空间
  5. 更小的 AOF 文件可以更快的被 redis 加载
  • 重写触发配置
  1. 手动触发 直接调用 bgrewriteaof 命令

image-20230124215800763

  1. 自动触发

    image-20230124215815701

auto-aof-rewrite-min-size: AOF 文件最小重写大小, 只有当 AOF 文件大小大于该值时候才能 重写, 默认配置 64MB auto-aof-rewrite-percentage: 当前 AOF 文件大小和最后一次重写后的大小之间的比率等于 或者大于指定的增长百分比，如 100 代表当前 AOF 文件是上次重写的两倍时候才重写 系统载入时或者上次重写完毕时，Redis 会记录此时 AOF 大小，设为base_size,

如果 Redis 的 AOF 当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis 会对 AOF 进行重写

这里是两个条件：

1.刚开启aof时，aof的文件大小为0即base_size=0，此时要出发重写当aof的文件大小>=64mb即可

2.正常执行的情况依次类推，第二次重写就是128mb

3.假设在执行的过程中aof的文件等于100mb，我们将redis停掉或者说服务器宕机了，再次启动

这时base_size为100mb，那么第二次重写就必须大于等于200mb

9.AOF 持久化小结 ​

1.优势

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

image-20230124220646181

2.劣势

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

10.RDB和AOF持久化选择哪一个 ​

1、官方文档地址: https://redis.io/topics/persistence

image-20230124220802468

2、官方推荐两个都启用 3、如果只做缓存：如果你只希望你的数据在服务器运行的时候存在, 你也可以不使用任何 持久化方式

当同时开启aof和rdb两个持久化方式时，默认读取数据是从aof中获取，但aof并不会影响到rdb的备份机制