一、RDB快照
1、概念
默认的持久化方案。
在指定时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。
在指定目录下生成一个dump.rdb文件。
重启会通过加载dump.rdp文件恢复数据。
2、对应配置参数
save <seconds> <changes>
eg:
save 900 1
save 300 10
save 60 10000
若不想用RDB方案,则为save ""
# 时间策略save 900 1
save 300 10
save 60 10000
# 文件名称
dbfilename dump.rdb
# 文件保存路径
dir /home/work/app/redis/data/
# 如果持久化出错,主进程是否停止写入
stop-writes-on-bgsave-error yes
# 是否压缩
rdbcompression yes
# 导入时是否检查
rdbchecksum yes
3、手动触发rdb快照
save 会阻塞
bgsave 不会阻塞,重fork新子进程保存
4、优缺点
1)优点:适合大规模数据恢复,如果对数据完整性和一致性要求不高,RDB是很好的选择
2)缺点:完整性和一致性不高
二、Aof日志追加
1、概念
默认不开启。
出现是为了弥补RDB的不足。
2、对应配置参数
appendonly yes (默认为no)
appendfilename "appendonly.aof"
# appendfsync always appendfsync everysec # appendfsync no
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 配置重写触发机制
# 是否开启aofappendonly yes
# 文件名称appendfilename "appendonly.aof"
# 同步方式appendfsync everysec
# aof重写期间是否同步no-appendfsync-on-rewrite no
# 重写触发配置auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb
# 加载aof时如果有错如何处理aof-load-truncated yes
# 文件重写策略aof-rewrite-incremental-fsync yes
3、手动触发
bgrewriteaof 瘦身机制 ,重新整理aof命令日志
4、优缺点
优点:数据完整性和一致性更高
缺点:aof记录的内容对,文件会越来越大,数据恢复也会越来越慢
三、两者同时使用
两种可同时使用
当数据恢复时,优先加载aof文件恢复