Redis的持久化方案(冷备):RDB和AOF
-
RDB:Redis Dump Binary,把当前进程数据生成快照保存到硬盘的过程,触发RDB分为自动和手动两种方式。
- 手动触发:手动触发的命令:
save
和bgsave
,两个命令都可以触发生成快照生成RDB文件,但是有区别:save
:阻塞Redis的服务器进程直至RDB文件创建完成bgsave
:会由Redis主进程fork出来一个子进程,子进程会把数据集先写入临时文件,写入成功之后,再替换之前的RDB文件,用二进制压缩存储,保证RDB文件始终存储的时完整的持久化内容,主进程继续工作处理命令请求。
- 自动触发:在配置文件中设置
save <seconds> <changes>
规则,可以自动间隔性执行bgsave
命令:save <seconds> <changes>表示在seconds秒内,至少有changes次变化,就会自动触发gbsave命令 save 900 1 当时间到900秒时,如果至少有1个key发生变化,就会自动触发bgsave命令创建快照 save 300 10 当时间到300秒时,如果至少有10个key发生变化,就会自动触发bgsave命令创建快照 save 60 10000 当时间到60秒时,如果至少有10000个key发生变化,就会自动触发bgsave命令创建快照
- 手动触发:手动触发的命令:
-
AOF:Append Of File,AOF持久化会把被执行的写命令写到AOF的文件的末尾,记录数据的变化,默认是没有开启AOF持久化的,开启后每执行一条更改Redis的数据的命令,都会把该命令追加到AOF文件中,这样可能会降低Redis的性能,使用较快的硬盘也可以提高AOF的性能。AOF记录Redis的写命令步骤为:命令追加,文件写入和文件同步。
- 命令追加:
服务器每执行一个写命令,都会把该命令以协议的格式先追加到aof_buf缓存区的末尾,而不是直接写入文件,避免每次有命令都直接写入硬盘,减少硬盘的IO次数。 - 文件写入和文件同步
对于何时把aof_buf缓冲区的内容合适写入保存到AOF文件中,Redis提供了多种策略: appendfsync:always、everysec、noappendfsync always
:每个写命令发生的时候,同步写入aof_buf,并同步从aof_buf同步到磁盘上的AOF文件中。appendfsync everysec
(系统默认):将aof_buf缓存区的内容写入AOF文件,每秒同步一次,由专门线程负责。appendfsync no
:将aof_buf缓存区的内容写入AOF文件,什么时候同步由系统决定。
- AOF重写:目的是为了压缩AOF文件的体积,因为随着时间的推移AOF文件的体积会越来越大,AOF文件重写并不需要对现有的 AOF文件进行任何读取、分享和写入操作,而是通过读取当前服务器的数据库状态来实现的,AOF重写分为手动和自动:
- 手动重写 :手动执行
bgrewriteaof
命令,执行原理和bgsave
类似,由主进程fork出来一个子进程来工作。 - 自动重写:根据配置条件自动触发
bgrewriteaof
命令
- 手动重写 :手动执行
- 命令追加:
# 表示当AOF文件的体积大于80MB,且AOF文件的体积比上一次重写后的体积大了一倍(100%)时,会执行`bgrewriteaof`命令
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 80mb
在重写期间,服务器主进程会继续处理命令请求,如果有写命令(包括增加删除修改操作)追加到aof_buf
的同时,也会追加到aof_rewrite_buf
重写缓冲区,
当子进程完成重写之后,会给父进程一个信号,父进程会把重写缓冲区的内容写进新的AOF临时文件中,然后再对新的AOF文件改名完成替换,从而保证新的AOF文件与当前数据库数据的一致性。
RDB和AOF对比
- RDB:
- 优点:恢复数据速度快,文件体积小
- 缺点:因为是周期性备份,所以有可能丢失部分数据
- AOF:
- 优点:不易丢失数据,秒级丢失(如果策略设成everysec),数据更加完整
- 缺点:体积比RDB文件大,数据速度恢复较慢
Redis数据恢复 先AOF后RDB
Redis4.0支持RDB和AOF混合之旧话,可以通过aof-use-rdb-preamble
开启
如果Redis进程挂了,Redis会直接从AOF文件恢复,如果AOF文件损坏,可以通过命令redis-check-aof fix
命令修复,如果没有AOF文件,则加载RDB文件。