文章目录
①. AOF - 概述作用
-
①. 官网介绍
-
②. 以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
-
③. 默认情况下,redis是没有开启AOF(append only file)
开启AOF功能需要设置配置:appendonly yes - Aof保存的是appendonly.aof文件
②. AOF - 工作流程
-
①. Client作为命令的来源,会有多个源头以及源源不断的请求命令
-
②. 在这些命令到达Redis Server 以后并不是直接写入AOF文件,会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域,存在的目的是当这些命令达到一定量以后再写入磁盘,避免频繁的磁盘IO操作
-
③. AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件
-
④. 随着写入AOF内容的增加为避免文件膨胀,会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的
-
⑤. 当Redis Server 服务器重启的时候会从AOF文件载入数据。
③. 缓冲区 - 写回策略
-
①. 配置文件位置:
-
②. Always:同步写回,每个写命令执行完立刻同步地将日志写回磁盘
-
③. everysec: 每秒写回,每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,每隔1秒把缓冲区中的内容写入磁盘
-
④. no:操作系统控制的写回,每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
④. 配置文件说明(6 VS 7)
-
①. 如何开启aof
-
②. 使用默认写回策略,每秒钟
# appendfsync always
appendfsync everysec
# appendfsync no
- ③. aof文件-保存路径
- redis6 - AOF保存文件的位置和RDB保存文件的位置一样,都是通过redis.conf配置文件的dir配置
- redis7之后最新:dir + appenddirname
- ④. aof文件-保存名称,redis6只有一个
- ⑤. Redis7.0 Multi Part AOF的设计
- base:表示基础AOF,它一般由子进程通过重写产生,该文件最多只有一个
- incr:表示增量AOF,它一般会在AOFRW开始执行时被创建,该文件可能存在多个
- manifest清单文件,用来管理aof的
⑤. 正常、异常恢复
-
①. 启动:修改默认的appendonly no,改为yes
-
②. 写操作继续,生成aof文件到指定的目录
-
③. 恢复1:重启redis然后重新加载,结果OK
-
④. 恢复2:将生产的aof文件重命名,重启发现redis中无数据,将重命名的文件重新改为aof文件,重启发现redis有数据产生
- 写入数据进redis,然后flushdb+shutdown服务器
- 新生成了dump和aof
- 备份新生成的aof.bak,然后删除dump/aof再看恢复
- 重启redis然后重新加载试试？
- 停止服务器,拿出我们的备份修改后再重新启动服务器看看
- ⑤. 异常恢复
- 故意乱写正常的AOF文件,模拟网络闪断文件写error
vim /myredis/appendonlydir/appendonly.aof.1.incr.aof - 重启Redis之后就会进行AOF文件的载入,发现启动都不行
- 异常修复命令:redis-check-aof --fix 进行修复
- 重新OK
⑥. AOF - 优劣势
-
①. 优势:更好的保护数据不丢失 、性能高、可做紧急恢复
-
②. 劣势
- 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
- aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同
⑦. AOF - 重写机制
- ①. 启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集
- 由于AOF持久化是Redis不断将写命令记录到AOF文件中,随着Redis不断的进行,AOF的文件会越来越大,文件越大,占用服务器内存越大以及AOF恢复要求时间越长
- 为了解决这个问题,Redis新增了重写机制,当AOF文件的大小超过所设定的峰值时,Redis就会自动启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集
- 可以手动使用命令bgrewriteaof来重新
- ②. 触发机制 - 官网默认配置:同时满足,且的关系才会触发
- 根据上次重写后的aof大小,判断当前aof大小是不是增长了1倍
- 重写时满足的文件大小
-
③. 自动触发:满足配置文件中的选项后,Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
-
④. 手动触发:客户端向服务器发送bgrewriteaof命令
-
⑤. 启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集 - 如何理解这句话
-
⑥. 案例验证:
- 前期配置准备,开启aof
- 重写峰值修改为1k:auto-aof-rewrite-min-size 1k
- 删除之前的全部aof和rdb,清除干扰项
- ⑦. 自动触发案例01
- 完成上述正确配置,重启redis服务器,执行set k1 v1查看aof文件是否正常
- 查看三大配置文件
- k1不停1111111暴涨
- 重写触发
⑧. AOF优化配置项详解
⑨. RBD和AOF共存模式
-
①. rdb和aof可以共存,数据恢复顺序和加载流程
-
②. 如何选择？
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾
- ③. 同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
- RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
作者建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段
- ④. 推荐方式:RDB+AOF混合方式
- 设置aof-use-rdb-preamble的值为yes,yes表示开启,设置为no表示禁用
- RDB+AOF的混合方式,结论:RDB镜像做全量持久化,AOF做增量持久化
- 先使用RDB进行快照存储,然后使用AOF持久化记录所有的写操作,当重写策略满足或手动触发重写的时候,将最新的数据存储为新的RDB记录
- ⑤. 纯缓存模式:同时关闭RDB+AOF
- 禁用rdb:save “”(禁用rdb持久化模式下,我们仍然可以使用命令save、bgsave生成rdb文件)
- 禁用aof:appendonly no(禁用aof持久化模式下,我们仍然可以使用命令bgrewriteaof生成aof文件)