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

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