Redis:两种持久化方式RDB和Aof对比(3)

一、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文件恢复
 

本博客地址: wukong1688

本文原文地址:https://www.cnblogs.com/wukong1688/p/12321946.html

转载请著名出处!谢谢~~

 
 
 
 
 
 

相关推荐