Redis持久化

RDB持久化方式

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.

RDB的优点

RDB是一个非常紧凑的单一文件,方便备份与传输;
RDB在持久化的时候只需要fork出一个子进程,接下来的持久化工作由子进程完成,因此能最大限度得优化redis性能;
与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些;

RDB的缺点

由于其工作方式是定时fork一个子进程完成持久化,因此在其两次工作的间隔中间的数据会因掉电等原因意外停止工作而丢失
RDB操作全量数据,当数据量较大时,则开销也会较大

使用RDB

配置文件(RDB部分)

#save 间隔秒 操作数
#使用 save "" 禁用RDB
#900秒内有一次操作触发RDB
save 900 1
#300秒内有10次操作触发RDB
save 300 10
#60秒内10000次操作触发RDB
save 60 10000

#RDB异常时是否暂停接受写操作,默认是
stop-writes-on-bgsave-error yes

#RDB是否开启压缩,默认是
rdbcompression yes

#RDB是否开启CRC64校验位
rdbchecksum yes

#RDB快照文件名称
dbfilename dump.rdb

#没启用持久化的Redis实例是否删除其RDB文件,默认否
rdb-del-sync-files no

#RDB文件目录,默认使用命令的当前目录
dir ./

命令

#检查RDB文件,显示内容,如果发生错误会提示哪里错误
redis-check-rdb dump.rdb

#CLI中手动操作执行RDB
BGSAVE

AOF持久化方式

AOF全称是append only file,在redis中则是只追加写入命令

AOF的优点

AOF的持久化间隔何以非常短(每秒fsync最多丢失一秒数据,而每次写的时候fsync最多丢失一次操作数据,但磁盘IO开销大),最大限度的减少数据丢失;
AOF文件是一个只进行追加的日志文件,所以不需要写入seek;
Redis可以在AOF文件体积变得过大时,自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合;
AOF具有一定的可读性这意味着可以用它来恢复一些危险操作,如: 移除AOF文件末尾的FLUSHALL命令,并重启 Redis,就可以将数据集恢复到 FLUSHALL 执行之前的状态;
较新(4.0以后)版本中AOF在重写后可以和RDB混合,即将当前以前的数据重写为RBD,之后的增量数据依然是AOF

AOF的缺点

AOF文件的体积通常大于RDB
比RDB更高的服务器负荷
恢复速度较RDB可能更慢

使用AOF

配置文件(AOF部分)

#是否启用AOF,默认no
appendonly yes

#AOF文件名称
appendfilename "appendonly.aof"

#AOF写入刷新的三个级别,默认everysec
#everysec 每秒刷新,最多丢失1秒数据
#always 每次操作刷新
#no 每当页缓存满了才自动刷写到磁盘,最多丢失一个页缓存的数据
#页缓存一般操作系统默认4k,可调整(4的倍数)
appendfsync everysec

#如果子进程(RDB)正在操作,是否暂停AOF刷写到磁盘,默认否
#开启时可能会争抢磁盘IO,但数据丢失可能会更少
no-appendfsync-on-rewrite no

#再次自动重写AOF文件触发的大小和首次重写时大小的百分比(如当前配置为,和下面的64mb,相比较增长了100%则触发重写)
#指定为0时禁用自动AOF
auto-aof-rewrite-percentage 100

#首次自动重写AOF文件的大小
auto-aof-rewrite-min-size 64mb

#加载AOF数据时是否截断检查,默认是
aof-load-truncated yes

#AOF重写时是否启用混合(老数据会以RDB方式存储),默认启用
aof-use-rdb-preamble yes

命令

#检查AOF文件,显示内容,如果发生错误会提示哪里错误
redis-check-aof appendonly.aof

#CLI中手动操作执行重写AOF文件
BGREWRITEAOF

持久化方式的选择

Redis默认使用RDB方式进行持久化
如果数据丢失容忍度较高低考虑使用AOF,如果同时需要快速恢复则可以同时使用RDB和AOF,代价是性能开销更大
如果更考虑性能,数据丢失容忍度较高(如作为缓存使用),则考虑使用RDB,恢复更快,开销更低