Redis数据持久化策略
持久化策略之RDB
RDB:在指定的时间间隔,执行数据集的时间点快照。
实现类似照片记录效果的方式,就是把某一时刻的数据和状态以文件的形式写到磁盘上,也就是读快照。这样一来即使故障宕机,快照文件也不会丢失,数据的可靠性也就能得到保证。这个快照文件就称为RDB文件(dump.rdb)。其中,RDB就是Redis DataBase的缩写。通俗点说就是在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot内存快照,它恢复时再将硬盘快照文件直接读回到内存里
RDB的持久化:6与7的配置是存在一定区别的
Redis 6.X中redis.conf中的配置快照部分,SNAPSHOTTING
Redis6.0.16 之前的配置情况,在Redis.conf配置文件中的SNAPSHOTTING下配置save参数,来触发Redis的RDB持久化条件。比如save m n :表示m秒内数据集存在n次修改时,自动触发bgsave
Redis 6.2以及7之后变化频率发生了变化
如何利用dump文件进行数据恢复?
自动备份:
将备份文件(dump.rdb)移动到redis安装目录并启动服务即可恢复数据。
备份成功后故意用flushdb清空redis,看看是否可以恢复数据?执行flushall/flushdb命令也会产生dump.rdb文件,但里面是空的,无意义。
物理恢复,一定服务和备份分机隔离
备注:不可以把备份文件dump.rdb和生产redis服务器放在同一台机器,必须分开各自存储,以防生产机物理损坏后备份文件也挂了。
手动备份:save与bgsave
redis提供了两个命令来生成RDB文件,分别是save和bgsave(默认)
save
save命令在主程序中执行会阻塞当前redis服务器,直到持久化工作完成执行save命令期间,Redis不能处理其他命令,线上禁止使用
bgsave(默认)
redis会在后台异步进行快照操作,不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程,由子进程复制持久化过程
fork是什么? 从linux角度看,fork()会产生一个和父进程完全相同的子进程,但子进程在此后多会exec系统调用,出于效率的考虑,尽量避免膨胀。
lastsave 可以通过lastsave命令获取最后一次成功执行快照的时间
时间戳转化
RDB的优点
优点总结
适合大规模的数据恢复、按照业务定时备份、对数据完整性和一致性要求不高、RDB文件在内存中的加载速度要比AOF快得多
RDB的缺点
缺点总结
在一定间隔时间做一次备份,所以如果redis意外down掉的化,就会丢失从当前至最近一次快照期间的数据,快照之间的数据会丢失
内存数据的全量同步,如果数据量太大会导致I/O严重影响服务器性能
RDB依赖于主进程的fork,在更大的数据集中,这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份,大致2倍的膨胀性,需要考虑。
数据丢失的案例
kill -9 模拟宕机
redis重启恢复数据,查看数据是否丢失
如何检测修复dump.rdb文件
哪些情况会触发RDB快照??
1.配置文件中默认的快照配置
2.手动save/bgsave命令
3.执行flushall/flushdb命令也会产生dump.rdb文件,但里面是空白的
4.执行shutdown且没有设置开启AOF持久化
5.主从复制时,主节点自动触发
如何禁用快照??
动态所有停止RDB保存规则的方法:
redis-cli config set save ""
配置文件快照禁用的方式
RDB优化配置项
相关命令
stop-writes-on-bgsave-error
默认yes。 如果配置成no,表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致,那么在快照写入失败时,也能确保redis继续接受新的写请求
rdbcompression
默认yes 。 对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能
rdbchecksum
rdb-del-sync-files