Redis持久化之RDB、AOF详解

概述

Redis 提供了2种不同的持久化方式，分别为RDB和AOF

RDB能够定时地对数据进行快照存储，因为是定时的，所以服务宕机时存在丢失数据的风险
AOF能够记录每一次的写操作，当服务重启的时候会重新执行这些命令来恢复数据，恢复完整度高，但是比较耗时
Redis服务启动时，根据配置的持久化方式来决定加载RDB或者AOF恢复数据。如果2种持久化都开启，则优先加载AOF

RDB

RDB 相关配置

# save <seconds> <changes>
# 在900秒内保存1次、300秒内保存10次、60秒内保存10000次，这些条件符合其中一个就会触发RDB快照保存
save 900 1
save 300 10
save 60 10000

# RDB快照存储失败时，是否停止接收新的写入操作
stop-writes-on-bgsave-error yes

# 是否开启RDS快照文件的压缩存储（不开启会导致dump.rdb文件过大）
rdbcompression yes

# 对RDB格式进行校验，但是在加载或保存RDB文件时有10%的性能损耗
rdbchecksum yes

# RDB快照文件名
dbfilename dump.rdb

# 存放RDB、AOF文件的目录
dir /usr/local/redis-5.0.8/data

RDB 详解

如果Redis服务是正常退出，会自动保存最新数据到rdb，然后再退出服务
如果Redis服务是异常中断，例如kill命令直接终止，则不会触发RDB快照保存
在保存RDB文件时，父进程会fork出一个子进程来处理，然后父进程不需要再做其他IO操作。
在恢复大的数据集时，RDB会比AOF更快

AOF

AOF 相关配置

# 是否开启AOF持久化
appendonly no
# AOF持久化文件名
appendfilename "appendonly.aof"

# 持久化策略。
# always：每次写入数据分别触发持久化，并完成磁盘同步
# everysec：每秒持久化一次，并完成磁盘同步（推荐）
# no：将数据交给操作系统处理，更快，也更不安全
appendfsync everysec

# 当AOF文件正在rewrite时，是否停止appendfsync操作
# no：不停止，也就是追加操作照常进行
# yes：停止，不进行追加操作，而只是将其放在缓冲区
no-appendfsync-on-rewrite no

# AOF文件增大一定的比例后（percentage），自动触发重写机制bgrewriteaof
# 只有当文件超过一定的大小（min-size），bgrewriteaof才会执行，避免文件很小的时候一直反复的rewrite
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF 文件重写机制

AOF的机制是不断地将写命令追加到文件末尾，随着日积月累文件会变得越来越大，这时就需要一个重写机制来处理。
例如：你对1个数值进行INCR递增100次，AOF记录了100次INCR命令，实际上只需要1条SET命令就能保存最新的值了。
为了处理这种情况，AOF重写机制（bgrewriteaof）会创建1个新的AOF文件，包含了重建当前数据所需要的最少命令，创建完毕后直接替换掉原文件。
在这里插入图片描述

AOF 文件损坏处理

服务器宕机时可能导致AOF文件损坏，此时在Redis重启时不会加载这个AOF文件。这种情况下，可以通过以下方式处理：

复制一份当前的AOF文件，作为备份
使用Redis自带的修复程序进行处理：redis-check-aof -fix
（可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处
重启Redis服务，等待AOF文件加载以及数据恢复

RDB切换到AOF

假设Redis当前使用的是RDB，并且有了一定的数据量，这时候想启用AOF时，应该怎么操作呢？

方法一

直接修改redis.conf文件，把appendonly改成yes，然后重启redis。

注意：这时原数据将被全部清空
注意：这时原数据将被全部清空
注意：这时原数据将被全部清空

方法二

通过redis-cli连接redis，执行命令进行设置，这时将直接启用aof，并将当前的数据写入到appendonly.aof文件。

CONFIG SET appendonly yes

注意：redis.conf记得同步设置appendonly yes，否则下次重启aof不会启用