redis–16–持久化–AOF
1、 AOF(Append Only File)是什么
- 将每个写指令以日志的形式记录下来(增量保存)，只许追加文件但不可以改写文件
- 读指令不记录
- redis启动后会读取该日志文件来重新构建数据，简单来说，redis 重启后会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2、AOF持久化流程
- 客户端的请求写命令会被append追加到AOF缓冲区内；
- AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
- 默认情况每30秒执行一次同步操作
- AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
- Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；
3、优缺点
3.1、缺陷(与RDB比较)
- 占用更多的磁盘空间。
- 恢复备份速度要慢。
- 每次读写都同步的话，有一定的性能压力。
- 存在个别Bug，造成不能恢复。
3.2、优点
- 备份机制更稳健，丢失数据概率更低。
- 可读的日志文本，通过操作AOF文件，可以处理误操作。
4、配置
# AOF默认不开启，这里可以设置开启
appendonly yes
# aof文件名称
# aof文件存放位置默认与rdb在一个路径下
appendfilename "appendonly.aof"
# -----AOF同步频率设置-----
# 始终同步，每次Redis的写入都会立刻记入日志；
# 性能较差但数据完整性比较好
appendfsync always
# 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync everysec
# redis不主动进行同步，把同步时机交给操作系统
# 同步频率低,速度快
appendfsync no
# 正在导出rdb快照的过程中,要不要停止同步aof，一般停止，减少I/O
#yes :
# 1. 不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。
# 2. 降低数据安全性，提高性能
#no :
# 1. 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。
# 2. 数据安全，但是性能降低
no-appendfsync-on-rewrite yes
# -----重写设置-----
# aof文件大小比起上次重写时的大小,增长率100%时,触发重写
auto-aof-rewrite-percentage 100
# aof文件,至少超过64M时,触发重写
auto-aof-rewrite-min-size 64mb
5、触发AOF的场景
5.1、启动redis时候
- 启动redis时候会加载aop文件的命令来将硬盘的数据加载到内存中
- 速度比rdb慢
5.2、AOF同步频率
# 始终同步，每次Redis的写入都会立刻记入日志；
# 性能较差但数据完整性比较好
appendfsync always
# 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync everysec
# redis不主动进行同步，把同步时机交给操作系统
# 同步频率低,速度快
appendfsync no
6、AOF和RDB同时开启，redis听谁的
AOF和RDB同时开启，系统默认取AOF的数据,因为这样数据不会存在丢失。
7、AOF启动步骤
7.1、配置修改
# AOF默认不开启，这里可以设置开启
appendonly yes
# aof文件名称
# aof文件存放位置默认与rdb在一个路径下
appendfilename "appendonly6379.aof"
# 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync everysec
# 正在导出rdb快照的过程中,要不要停止同步aof，一般停止，减少I/O
no-appendfsync-on-rewrite yes
# -----重写设置-----
# aof文件大小比起上次重写时的大小,增长率100%时,触发重写
auto-aof-rewrite-percentage 100
# aof文件,至少超过8M时,触发重写
auto-aof-rewrite-min-size 8mb
7.2、关闭redis
127.0.0.1:6379> shutdown
not connected>
7.3、重启redis
/usr/local/bin/redis-server /redis/redis.conf
7.4、结果
为什么这个时候redis为空？
因为AOF和RDB同时开启，系统默认取AOF的数据,因为AOF没有数据，所以这个时候redis为空
8、AOF内容
8.1、客户端写数据
127.0.0.1:6379> set a 1
OK
127.0.0.1:6379>
8.1、AOF内容
9、备份和恢复演示
备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
9.1、备份演示
9.1.1、拷贝aof文件
cp appendonly6379.aof appendonly6379.aof.back
9.2、恢复演示
9.1.1、删除aof文件
rm -rf appendonly6379.aof
9.2.2、关闭redis
127.0.0.1:6379> shutdown
not connected>
9.2.3、修改aof备份文件
mv appendonly6379.aof.back appendonly6379.aof
9.2.4、重启redis然后重新加载
/usr/local/bin/redis-server /redis/redis.conf
9.2.5、客户端登陆查看
10、修复AOF演示
10.1、关闭redis
127.0.0.1:6379> shutdown
not connected>
10.2、配置修改
# 日志文件路径
logfile "/redis/data/redis.log"
方便报错查看日志
10.3、编辑aof文件
vim appendonly6379.aof
10.4、重启redis
/usr/local/bin/redis-server /redis/redis.conf
10.5、查看日志
启动是不成功的，我们可以通过日志看到错误信息
Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>
aof文件有错，可以通过redis-check-aof --fix aof文件名称 来修复
10.6、修复
/usr/local/bin/redis-check-aof --fix /redis/data/appendonly6379.aof
10.7、重启redis,发现成功 ，并且客户端可以访问redis了
/usr/local/bin/redis-server /redis/redis.conf
11、 重写压缩
11.1、重写压缩是什么
AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集。
可以使用命令bgrewriteaof
举例
打个比方，如有100条命令，都是set num=1,incr num …99次，那么aop日志就要向日志文件中写入100条命令，而重写的意思就是，把这100命令用set num=100来替换。
11.2、重写原理
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写
- 先写临时文件最后覆盖原aof文件
- redis4.0 版本后的重写，是指上就是把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
11.2.1、重写流程
（1）、bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
（2）、主进程fork出子进程执行重写操作，保证主进程不会阻塞。
（3）、子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区,保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
（4.1)、子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
（4.2)、主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
（5）、使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。
11.3、触发机制，何时重写
11.3.1、配置触发
# 正在导出rdb快照的过程中,要不要停止同步aof，一般停止，减少I/O
#yes :
# 1. 不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。
# 2. 降低数据安全性，提高性能
#no :
# 1. 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。
# 2. 数据安全，但是性能降低
no-appendfsync-on-rewrite yes
# -----重写默认配置-----
# aof文件大小比起上次重写时的大小,增长率100%时(当前aof文件是上次重写文件的2倍),触发重写
auto-aof-rewrite-percentage 100
# aof文件,至少超过64M时,触发重写
auto-aof-rewrite-min-size 64mb
系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,
如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
举例
文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB
- 当前文件是原先文件的2倍
- 当前文件>60M
11.3.2、手动触发
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
127.0.0.1:6379>
11.3.3、测试–配置触发
/usr/local/bin/redis-benchmark -n 15000
11.3.3、测试–手动触发触发
01、添加数据
/usr/local/bin/redis-benchmark -n 15000
02、查看aof文件大小
03、手动触发
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
127.0.0.1:6379>
12、总结
13、RDB,AOF用哪个好
- 官方推荐两个都启用。
- 如果对数据不敏感，可以选单独用RDB。
- 不建议单独用 AOF，因为可能会出现Bug。
- 如果只是做纯内存缓存，可以都不用。
13.1、官方推荐
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
- Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
13.1.1、只做缓存：
如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
13.1.2、同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
13.1.3、RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
13.1.4、性能建议
-
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
-
如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。但是这是有代价的
- 带来了持续的IO，
- AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
-
只要硬盘许可，应该尽量减少AOF rewrite的频率
- AOF重写的基础大小默认值64M太小了，可以设到5G以上
- 默认超过原大小100%大小时重写可以改到适当的数值。
1026
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
