目录
一、RDB快照持久化 原理
二、RDB快照持久化配置(redis.conf):
三、触发RDB备份:
1、自动备份,需配置备份规则:
2、手动执行命令备份(save | bgsave):
3、flushall命令:
四、RDB的备份恢复:
五、RDB优缺点:
以下配置以Redis-x64-3.2.100.zip为例,介绍下 RDB快照持久化
一、RDB快照持久化 原理
1、单线程: Redis 是单线程程序,这个线程要同时负责多个客户端套接字的并发读写操作和内存数据结构的逻辑读写
。在服务线上请求的同时,Redis 还需要进行内存快照,内存快照要求 Redis 必须进行文件 IO 操作,这意味着单线程同时在服务线上的请求还要进行文件 IO 操作,文件 IO 操作会严重拖垮服务器请求的性能。还有个重要的问题是为了不阻塞线上的业务,就需要边持久化边响应客户端请求。持久化的同时,内存数据结构还在改变,如果一个大型的 hash 字典正在持久化过程中,过来一个删除请求如何处理?Redis 使用操作系统的多进程 COW(Copy On Write)
机制来实现快照持久化。
2、fork(多进程):Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程,快照持久化完全交给子进程来处理,父进程继续处理客户端请求。子进程刚刚产生时,它和父进程共享内存里面的代码段和数据段。
这是 Linux 操作系统的机制,为了节约内存资源,所以尽可能让它们共享起来。在进程分离的一瞬间,内存的增长几乎没有明显变化。
子进程做数据持久化,它不会修改现有的内存数据结构,它只是对数据结构进行遍历读取,然后序列化写到磁盘中。但是父进程不一样,它必须持续服务客户端请求,然后对内存数据结构进行不间断的修改。
这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成,当父进程对其中一个页面的数据进行修改时,会将被共享的页面复制一份分离出来,然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的,还是进程产生时那一瞬间的数据。
随着父进程修改操作的持续进行,越来越多的共享页面被分离出来,内存就会持续增长。但是也不会超过原有数据内存的 2 倍大小
。另外一个 Redis 实例里冷数据占的比例往往是比较高的,所以很少会出现所有的页面都会被分离
,被分离的往往只有其中一部分页面。子进程因为数据没有变化,它能看到的内存里的数据在进程产生的一瞬间就凝固了,再也不会改变,这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。
这里之需要需要通知父线程,是因为父线程要做个记录,保留最后一次持久化的时间。
二、RDB快照持久化配置(redis.conf):
1、指定备份文件的名称:在redis.conf中,可以修改rdb备份文件的名称,默认为dump.rdb。
2、指定备份文件存放的目录:
在redis.conf中,rdb文件的保存的目录是可以修改的,默认为Redis启动命令所在的目录
3、stop-writes-on-bgsave-error:当磁盘满时,是否关闭redis的写操作,stop-writes-on-bgsave-error用来指定当redis无法写入磁盘的话,是否直接关掉redis的写操作,
推荐yes。默认配置如下:
4、rdb备份是否开启压缩:对于存储到磁盘中的rdb快照文件,可以设置是否进行压缩,如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能,推荐yes。
5、rdbchecksum:是否检查rdb备份文件的完整性。存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取最大的性能提升,可以关闭此功能。推荐yes。
三、触发RDB备份:
有几下几种方法
1、自动备份,需配置备份规则:
可在redis.conf中配置自动备份的规则,save用来配置备份的规则,save格式如下:
save 秒钟 写操作次数
如设置20秒内有最少有3次key发生变化则进行备份:save 20 3。
默认规则为:默认是1分钟内修改了1万次,或5分钟内需修改了10次,或30分钟内修改了1次。
2、手动执行命令备份(save | bgsave):
有2个命令可以触发备份,
(1)save
:save时只管保存,其他不管,全部阻塞,手动保存,不建议使用。
(2)bgsave
:redis会在后台异步进行快照操作,快照同时还可以响应客户端情况。
可以通过 lastsave
命令获取最后一次成功生成快照的时间(获取到的是时间戳)。
动态停止RDB: redis-cli config set save ""
#save后给空值,表示禁用保存策略。
3、flushall命令:
执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义。
四、RDB的备份恢复步骤:
1、先通过CONFIG GET dir
查询rdb文件的目录,这其实就是查的redis.conf
文件当中通过dir
设置的目录
2、停止Redis
3、拷贝迁移的redis备份文件(dump.rdb)到CONFIG GET dir
查询出来的指定目录下。
cp dump.rdb dump.rdb
4、重新启动redis服务
五、RDB优缺点:
1、优点:
(1)适合大规模数据恢复
(2)对数据完整性和一致性要求不高更适合使用
(3)节省磁盘空间
(4)RDB是一个紧凑压缩的二进制文件,Redis加载RDB恢复数据远远快于AOF的方式
2、缺点:
(1)Fork的时候,内存中的数据会被克隆一份,大致2倍的膨胀,需要考虑
(2)虽然Redis在fork的时候使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
(3)RDB方式数据没办法做到实时持久化/秒级持久化,在备份周期在一定间隔时间做一次备份,所以如果Redis意外down的话,就会丢失最后一次快照后所有修改
(4)RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版RDB格式的问题
六、RBD简单演示:
(1)打开一个redis连接,设置key
(2)删除生成的rbd快照文件(我这里重命名了)
(3)重启redis,再次打开一个客户端,发现key不存在了
(4)还原之前的rbd文件,再次重启redis,并打开连接,key恢复了文章来源:https://www.toymoban.com/news/detail-809299.html
文章来源地址https://www.toymoban.com/news/detail-809299.html
到了这里,关于redis数据安全(二)数据持久化 RDB的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!