redis持久化, RBD(Redis Database)和AOF(Append Only File)
发布日期:2021-06-29 15:52:15
浏览次数:3
分类:技术文章
本文共 2714 字,大约阅读时间需要 9 分钟。
_._ _.-``__ ''-._ _.-`` `. `_. ''-._ .-`` .-```. ```\/ _.,_ ''-._ ( ' , .-` | `, ) |`-._`-...-` __...-.``-._|'` _.-'| | `-._ `._ / _.-' | `-._ `-._ `-./ _.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-' `-._ `-.__.-' _.-' `-._ _.-' `-.__.-'
redis持久化
redis有两种持久化方式,rdb和aof,
- 启动服务会默认优先加载aof备份文件进行恢复,
- 如果加载失败会出错,不会再加载rdb文件;
- 如果没有aof文件则直接加载rdb文件
RDB(redis database)
实现方式
- 在指定的时间间隔将内存中的数据集快照(Snapshot)写入磁盘(dump.rdb)
- 恢复时是将快照读入内存
- redis会单独创建一个子进程(Fork)进行持久化操作,主进程不进行任何IO操作
优点:
- 如果需要大规模数据恢复,并且对数据完整性不是非常敏感,则RDB方式比AOF方式更加适合
缺点:
- RDB最后一次执行持久化操作之后的数据可能会丢失
- Fork进程时会将内存中的数据克隆一份,造成2倍的内存压力
fork进程
复制一个与当前进程一样的进程,新进程的所有数据与原进程相同。
配置
-
相关配置在文件中的
snapshotting
块 -
持久化触发规则
save <seconds> <changes>
# save# after 900 sec (15 min) if at least 1 key changed 15分钟1次save 900 1# after 300 sec (5 min) if at least 10 keys changed 5分钟10次save 300 10# after 60 sec if at least 10000 keys changed 1分钟1万次save 60 10000# 禁用持久化 空字符串或者不写save参数save ""
- 持久化文件名
# The filename where to dump the DBdbfilename dump.rdb# The working directorydir ./
- 其他
# 备份失败时停止写入操作stop-writes-on-bgsave-error yes# 压缩备份文件rdbcompression yes# 使用校验和rdbchecksum yes
手动备份
使用save
、bgsave
命令即可
127.0.0.1:6379> saveOK127.0.0.1:6379> BGSAVEBackground saving started
区别:
-
save: 全部阻塞
-
bgsave: 后台异步进行快照操作
注:使用其他一些命令也会触发备份,例如 flushAll
等
数据恢复
将备份文件(dump.rdb)移动到redis安装目录并重启服务即可
AOF(Append Only File)
实现方式
- 以日志形式记录每个写操作
- 文件为appendonly.aof
- 这个文件只允许追加,不允许修改
- redis启动服务后,会将日志文件里面的操作执行一遍完成恢复工作
- 在rdb和aof文件共存的状态下,redis会优先加载aof文件
- 如果aof文件损坏,会导致加载失败
- 可以使用
redis-check-aof
程序来检查aof文件- redis-check-aof --fix <filename>修复aof文件
- 优缺点:
- 优点:
- 数据完整性高
- 缺点:
- 速度慢
- 优点:
配置
- 位置:
APPEND ONLY MODE
# aof开启,默认关闭appendonly no# aof文件名(default: "appendonly.aof")appendfilename "appendonly.aof"# 重写aof文件触发比例auto-aof-rewrite-percentage 100# 重写aof文件触发最小文件大小auto-aof-rewrite-min-size 64mb
- 同步策略 appendSync
- 三种, always, everysec, no
- always: 同步持久化,性能较差,数据完整性好
- everysec: 每秒执行一次,异步
- no: 不同步
- 三种, always, everysec, no
#Appendsync 同步策略(默认:everysec)# 三种, always, everysec no# appendfsync alwaysappendfsync everysec# appendfsync no
数据恢复
- 开启aof
- 放置aof文件
- 重启服务
rewirte
- aof采用文件追加方式,会导致文件越来越大,为了防止文件过大带来的负面影响,引入了重写机制
- 文件达到一定大小就会对文件进行压缩,对内部文件进行精简
- 默认配置是当aof文件大小是上次rewrite后大小的100%,且文件大于64M时触发
总结
- 因为rdb只用做后备用途,建议只在Slave主机上持久化RDB文件,而且只要15min备份一次就足够了
- 开启aof,在最坏的情况下也只会丢失不到2秒的数据,代价是带来了持续的io
- AOF的重写产生的数据写到新文件造成的阻塞是不可避免的,只要硬盘允许,应该尽量减少rewrite的频率。
- 默认64M太小,可以设置到5以上。
- 如果不启用aof,使用Master-Slave Replication实现高可用性也可以。
- 如果Master和Slave同时宕机,会丢失十几分钟的数据,启动脚本需要比较Master和Slave上的RDB文件,载入比较新的那个文件。
转载地址:https://console.blog.csdn.net/article/details/115189706 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!
发表评论
最新留言
第一次来,支持一个
[***.219.124.196]2024年04月08日 08时11分25秒
关于作者
喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!
推荐文章
Django实战----页面静态化
2019-04-29
Django实战---商城购物车的增删改、显示和合并购物车
2019-04-29
Django项目实战----订单页面的显示和生成订单、提交订单的逻辑
2019-04-29
Django项目实战----生成订单时高并发问题使用乐观锁
2019-04-29
Django项目实战----添加支付宝支付
2019-04-29
DRF框架---前言(简单使用)
2019-04-29
字符串外面是b“ “的转换 -亲测有效
2019-04-29
单通道和多通道卷积
2019-04-29
npy文件和pkl文件的保存和读取
2019-04-29
middle-判断二分图-深度优先和广度优先
2019-04-29
买卖股票的最佳时机
2019-04-29
AUC粗浅理解笔记记录
2019-04-29
torch 模型运行时间与forward没对应的可能原因
2019-04-29
JavaScript 的addEventListener() 事件监听详解!
2019-04-29
上传图片到阿里云OSS和获取上传图片的url的详解 !
2019-04-29
Kafka为什么这么快?
2019-04-29
Java 生产者和消费者面试题
2019-04-29
生产者消费者问题
2019-04-29
本机电脑连接虚拟机redis失败解决方法
2019-04-29
DM365 应用层gpio控制
2019-04-29