接上一篇RDB,本篇看下Redis数据持久化的第二种方式AOF。
目录
一、AOF原理
1、写入机制:
2、缓冲机制:
3、重写机制 :
4、运行流程
二、AOF文件配置
1、开启AOF:
2、自动触发AOF重写
3、重写规则:
三、AOF的备份恢复:
1、正常恢复:
2、异常恢复:
四、重写流程:
五、AOF优缺点:
1、优点:
2、缺点:
一、AOF原理
AOF 日志存储的是 Redis 服务器的顺序指令序列,AOF 日志只记录对内存进行修改的指令记录。假设 AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列,那么就可以通过对一个空的 Redis 实例顺序执行所有的指令,也就是「重放」,来恢复 Redis 当前实例的内存数据结构的状态。
1、写入机制:
Redis 在收到客户端修改命令后,先进行相应的校验,如果没问题,就立即将该命令存追加到 .aof 文件中,也就是先存到磁盘中,然后服务器再执行命令。这样就算遇到了突发的宕机情况情况,也只需将存储到 .aof 文件中的命令,进行一次“命令重演”就可以恢复到宕机前的状态。
2、缓冲机制:
在上述执行过程中,有一个很重要的环节就是命令的写入,这是一个 IO 操作。Redis 为了提升写入效率,它不会将内容直接写入到磁盘中,而是将其放到一个内存缓存区(buffer)中,等到缓存区被填满时采用异步真正将缓存区中的内容写入到磁盘里,Linux 系统的 fsync() 函数可以将指定文件的内容从内核缓存刷到硬盘中。
但是如果机器突然宕机,AOF 日志内容可能还没有来得及完全刷到磁盘中,这个时候就会出现日志丢失。Redis 为数据的安全性考虑,同样为 AOF 持久化提供了策略配置appendfsync:有三个选项,见第二部分配置参数
3、重写/压缩机制 :
Redis 在长期运行的过程中,aof 文件会越变越长。如果机器宕机重启,“重演”整个 aof 文件会非常耗时,导致长时间 Redis 无法对外提供服务。为了让 aof 文件的大小控制在合理的范围内,Redis 提供了 AOF 重写机制
(1)自动触发AOF重写:Redis 为自动触发 AOF 重写功能,提供了相应的配置策略,默认配置
该配置项表示:触发重写所需要的 aof 文件体积百分比,只有当 aof 文件的增量大于 100% 时才进行重写,也就是大一倍。比如,第一次重写时文件大小为 64M,那么第二次触发重写的体积为 128M,第三次重写为 256M,以此类推。如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能。
(2)手动执行BGREWRITEAOF
命令,这个命令通过移除AOF文件中的冗余命令来重写AOF文件
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致;
新的 aof 文件会使用尽可能少的命令来记录数据库数据,因此新的 aof 文件的体积会小很多;
AOF 重写期间,服务器不会被阻塞,它可以正常处理客户端发送的命令。
即使 Bgrewriteaof 执行失败,也不会有任何数据丢失,因为旧的 AOF 文件在 Bgrewriteaof 成功之前不会被修改
4、运行流程
(1)客户端的请求写命令会被append追加到AOF缓冲区内
(2)AOF缓冲区会根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
(3)AOF文件大小超过重写策略或手动重写时,会对AOF文件进行重写(rewrite),压缩AOF文件容量
(4)redis服务器重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的。
二、AOF文件配置
1、开启AOF:
AOF默认不开启,可以在 redis.conf 文件中对AOF进行配置开启:
appendonly no # 是否开启AOF,yes:开启,no:不开启,默认为no
appendfilename "appendonly.aof" # aof文件名称,默认为appendonly.aof
dir ./ # aof文件所在目录,默认./,表示执行启动命令时所在的目录
2、自动触发AOF重写/压缩
见原理部分。
3、appendfsync同步频率:
默认为Everysec,有三个选项
(1)Always:服务器每写入一个命令,就调用一次 fsync函数,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据,但是其执行速度较慢;
(2)Everysec(默认):服务器每一秒调用一次 fsync 函数,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行的命令数据,通常都使用它作为 AOF 配置策略;
(3)No:服务器不主动调用 fsync 函数,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外停机时,丢失命令的数量是不确定的,所以这种策略,不确定性较大,不安全。
4、重写/压缩规则:
no-appendfsync-on-rewrite:重写时,不会执行appendfsync操作
no-appendfsync-on-rewrite no
该参数表示在正在进行AOF重写时不会将AOF缓冲区中的数据同步到旧的AOF文件磁盘,也就是说在进行AOF重写的时候,如果此时有写操作进来,此时写操作的命令会放在aof_buf缓存中(内存中),而不会将其追加到旧的AOF文件中,这么做是为了避免同时写旧的AOF文件和新的AOF文件对磁盘产生的压力。
(1)默认是ON,表示关闭,即在AOF重写时,会对AOF缓冲区中的数据做同步磁盘操作
,这在很大程度上保证了数据的安全性。但是遇到重写操作,可能会发生阻塞。(数据安全,但是性能降低)
(2)如果no-appendfsync-on-rewrite为yes,不写入aof文件,只写入缓存
,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据。(降低数据安全性,提高性能)。
但在数据量很大的场景,因为两者都会消耗磁盘IO,对磁盘的影响较大,可以将其设置为“yes”减轻磁盘压力,但在极端情况下可能丢失整个AOF重写期间的数据。
三、AOF的备份恢复:
AOF的备份机制和性能虽然和RDB不同,但是备份和恢复的操作同RDB一样,都是拷贝备份文件,需要恢复时再拷贝到Redis工作目录下,启动系统即加载。
1、正常恢复:
(1)修改默认的appendonly no,改为yes
(2)将有数据的aof文件复制一份保存到对应的目录(查看目录:config get dir)
(3)恢复:重启redis然后重新加载
2、异常恢复:
(1)修改默认的appendonly no,改为yes
(2)如遇到aof文件损坏,通过 redis-check-aof --fix appendonly.aof
进行恢复,appendonly.aof是文件名
四、重写流程:
1、手动执行 bgrewriteaof命令触发重写,判断是否当前有bgfsave或bgrewriteaof在运行,如果有,则等待该命令结束后再继续执行
2、主进程fork出子进程执行重写操作,保证主进程不会阻塞
3、子进程遍历redis内存中的数据到临时文件,客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整性以及新AOF文件生成期间的新的数据修改动作不会丢失
4、子进程写完新的AOF文件后,向主进程发送信号,父进程更新统计信息
5、主进程把aof_rewrite_buf中的数据写入到新的AOF文件
6、使用新的AOF文件覆盖旧的AOF文件,完成AOF重写
五、AOF优缺点:
1、优点:
(1)备份机制更稳健,丢失数据概率更低
(2)可读的日志文本,通过操作AOF文件,可以处理误操作
2、缺点:
(1)比RDB占用更多的磁盘空间
(2)恢复备份速度要慢
(3)每次读写都同步的话,有一定的性能压力
(4)存在个别bug,造成不能恢复