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
![](https://img2020.cnblogs.com/i-beta/1829785/202003/1829785-20200321140832869-82094099.png)
3 指定本地数据库存放目录,一般也用默认配置
![](https://img2020.cnblogs.com/i-beta/1829785/202003/1829785-20200321140845606-723749311.png)
4 默认开启数据压缩
![](https://img2020.cnblogs.com/i-beta/1829785/202003/1829785-20200321140907177-889938024.png)
################################ 快照 ################################# # # 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>
![](https://img2020.cnblogs.com/i-beta/1829785/202003/1829785-20200321140645929-1485746393.png)