AOF 持久化配置

AOF 持久化配置，默认是关闭的，默认打开的是 RDB 持久化配置。AOF 持久化在 redis.conf 文件中配置，目前配置文件存放在 /etc/redis/6379.conf。

打开配置文件，修改 appendonly 属性为 yes ，打开 AOF 持久化配置：

  1. appendonly yes

AOF 有三种 fsync 策略：

  1. # 每次写入一条数据就执行一次 fsync
  2. # appendfsync always
  3. # 每隔一秒执行一次 fsync
  4. appendfsync everysec
  5. # 不主动执行fsync
  6. # appendfsync no
  • always：每次写入一条数据，立即将这个数据对应的写日志 fsync 到磁盘上去，性能非常差，吞吐量很低；
  • everysec：每秒将 os cache 中的数据 fsync 到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的；
  • no：Redis 只负责将数据写入 os cache 就不管了，后面 os cache 根据自己的策略将数据刷入磁盘，不可控制；

基于 AOF 持久化机制的数据恢复实验

**

  1. 设置 appendonly 属性为 yes，打开 AOF 持久化，重启 Redis；
  2. 往 Redis 中写入几条数据，等待一秒；
  3. kill -9 强制杀死 Redis 进程，删除 /var/run/redis_6379.pid 文件，再重新启动 Redis；
  4. 通过 redis-cli 客户端查看刚刚插入的数据，发现最新的几条数据还在，查看 /var/redis/6379 文件夹，发现已经存在appendonly.aof 文件；

AOF rewrite 操作

Redis 中的内存中的数据是有一定限量的，内存到一定大小后，Redis 就会使用缓存淘汰算法（LRU）自动将一部分过期数据从内存中清除。AOF 是存放没有写命令的，所以文件会不断膨胀，当大到一定的时候，AOF 会做 rewrite 操作。

在 redis.conf 文件中，可以配置 rewrite 策略。

  1. # 如果 AOF 日志文件增长的比例，超过了之前的100%，就可能会去触发一次 rewrite
  2. auto-aof-rewrite-percentage 100
  3. # 但是此时还要去跟min-size比较，大于64M才会去触发一次 rewrite
  4. auto-aof-rewrite-min-size 64mb

AOF rewrite 操作步骤：

  1. Redis fork 一个子进程；
  2. 子进程基于当前内存中的数据，构建日志，开始往一个新的临时的 AOF 文件中写入日志；
  3. Redis 主进程，接收到 client 新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的 AOF 文件；
  4. 子进程写完新的日志文件之后，Redis 主进程将内存中的新日志再次追加到新的 AOF 文件中；
  5. 用新的日志文件替换掉旧的日志文件；

AOF 破损文件的修复

**
如果 Redis 在 append 数据到 AOF 文件时，机器宕机了，可能会导致 AOF 文件破损，用 redis-check-aof —fix 命令来修复破损的 AOF 文件。

  1. redis-check-aof --fix /usr/local/appendonly.aof

AOF 和 RDB 同时工作

  • 如果 RDB 在执行 snapshotting 操作，那么 Redis 不会执行 AOF rewrite; 如果 Redis 再执行 AOF rewrite，那么就不会执行 RDB snapshotting
  • 如果 RDB 在执行 snapshotting，此时用户执行 BGREWRITEAOF 命令，那么等 RDB 快照生成之后，才会去执行 AOF rewrite
  • 同时有 RDB snapshot 文件和 AOF 日志文件，那么 Redis 重启的时候，会优先使用 AOF 进行数据恢复，因为其中的日志更完整

作者：殷建卫 链接：https://www.yuque.com/yinjianwei/vyrvkf/hm1goc 来源：殷建卫 - 架构笔记 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。