redis的持久化:RDB的配置

RDB 详解

RDB持久化方式是指在指定时间间隔内将内存中的数据集快照写入磁盘,也就是Snapshot快照,它恢复时是将快照文件直接读到内存中,Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,等到持久化过程结束,再用这个临时文件替换上次持久化好的文件,整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效,RDB的缺点是最后一次的数据可能会丢失

从配置文件了解RDB

打开 redis.conf 文件,找到 SNAPSHOTTING 对应内容
1 RDB核心规则配置(重点)

save 900 1
save 300 10
save 60 10000

那么只要满足以下三个条件中的任意一个,BGSAVE命令就会被执行
服务器在900秒之内,对数据库进行了至少1次修改
服务器在300秒之内,对数据库进行了至少10次修改                                              

服务器在60秒之内,对数据库进行了至少10000次修改。

2 指定本地数据库文件名,一般采用默认的 dump.rdb

3 指定本地数据库存放目录,一般也用默认配置

 

4 默认开启数据压缩


################################ 快照  #################################  
#  
# Save the DB on disk:保存数据库到磁盘  
#  
#   save <秒> <更新>  
#  
#   如果指定的秒数和数据库写操作次数都满足了就将数据库保存。  
#  
#   下面是保存操作的实例:  
#   900秒(15分钟)内至少1个key值改变(则进行数据库保存--持久化)  
#   300秒(5分钟)内至少10个key值改变(则进行数据库保存--持久化)  
#   60秒(1分钟)内至少10000个key值改变(则进行数据库保存--持久化)  
#  
#   注释:注释掉“save”这一行配置项就可以让保存数据库功能失效。  
#  
#   你也可以通过增加一个只有一个空字符串的配置项(如下面的实例)来去掉前面的“save”配置。  
#  
#   save ""  
  
save 900 1  
save 300 10  
save 60 10000  
  
#在默认情况下,如果RDB快照持久化操作被激活(至少一个条件被激活)并且持久化操作失败,Redis则会停止接受更新操作。  
#这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题,可能会造成灾难。  
#  
#如果后台存储(持久化)操作进程再次工作,Redis会自动允许更新操作。  
#  
#然而,如果你已经恰当的配置了对Redis服务器的监视和备份,你也许想关掉这项功能。  
#如此一来即使后台保存操作出错,redis也仍然可以继续像平常一样工作。  
stop-writes-on-bgsave-error yes  
  
#是否在导出.rdb数据库文件的时候采用LZF压缩字符串和对象?  
#默认情况下总是设置成‘yes’, 他看起来是一把双刃剑。  
#如果你想在存储的子进程中节省一些CPU就设置成'no',  
#但是这样如果你的kye/value是可压缩的,你的到处数据接就会很大。  
rdbcompression yes  
  
#从版本RDB版本5开始,一个CRC64的校验就被放在了文件末尾。  
#这会让格式更加耐攻击,但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降,  
#所以,为了达到性能的最大化,你可以关掉这个配置项。  
#  
#没有校验的RDB文件会有一个0校验位,来告诉加载代码跳过校验检查。  
rdbchecksum yes  
  
# 导出数据库的文件名称  
dbfilename dump.rdb  
  
# 工作目录  
#  
# 导出的数据库会被写入这个目录,文件名就是上面'dbfilename'配置项指定的文件名。  
#   
# 只增的文件也会在这个目录创建(这句话没看明白)  
#   
# 注意你一定要在这个配置一个工作目录,而不是文件名称。  
dir ./  

手动执行RDB备份

save:

127.0.0.1:6379> set user n1
OK
127.0.0.1:6379> save
OK
127.0.0.1:6379>

bgsave:

[root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-cli
127.0.0.1:6379> save
OK
127.0.0.1:6379> set addr bj
OK
127.0.0.1:6379> BGSAVE
Background saving started

 

 

注意: bgsave命令是针对save阻塞问题做的优化。 Redis内部所有涉及到RDB操作都采用bgsave的方式, save命令可以放弃使用

触发RDB快照

1 在指定的时间间隔内,执行指定次数的写操作
2 执行save(阻塞, 只管保存快照,其他的等待) 或者是bgsave (异步)命令
3 执行flushall 命令,清空数据库所有数据,意义不大。
4 执行shutdown 命令,保证服务器正常关闭且不丢失任何数据,意义...也不大。

通过RDB文件恢复数据

将dump.rdb 文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。在实际开发中,一般会考虑到物理机硬盘损坏情况,选择备份dump.rdb 。可以从下面的操作演示中可以体会到。

RDB 的优缺点

优点:
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高,RDB是很好的选择。

缺点:
1 数据的完整性和一致性不高,因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存,因为Redis 在备份时会独立创建一个子进程,将数据写入到一个临时文件(此时内存中的数据是原来的两倍哦),最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

操作演示

[root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-server redis.conf
[root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-cli
127.0.0.1:6379> save
OK
127.0.0.1:6379> set addr bj
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> set n1 12
OK
127.0.0.1:6379> set n1 13
OK
127.0.0.1:6379> set n1 15
OK
127.0.0.1:6379> set n2 12
OK
127.0.0.1:6379> set n3 123
OK
127.0.0.1:6379> set 11 ser
OK
127.0.0.1:6379> set 124 werew
OK
127.0.0.1:6379> set we re
OK
127.0.0.1:6379> set 131 eq
OK
127.0.0.1:6379> set 12  sf
OK
127.0.0.1:6379> set rr rr
OK
127.0.0.1:6379> set aa  aa
OK
127.0.0.1:6379> set pp pp
OK
127.0.0.1:6379> set asd pp
OK
127.0.0.1:6379> set ss pp
OK
127.0.0.1:6379>
 
posted @ 2020-03-21 14:29  天宇轩-王  阅读(4878)  评论(0编辑  收藏  举报