前言:Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会随之消失(断电及失),所以Redis提供了持久化功能,Redis默认是使用RDB方式持久化的,在大部分情况下,RDB完全够用了
1 RDB(Redis DataBase)
在主从复制中,RDB就是备用的,一般放在从机上面而不是主机,相对来说比较方便,AOF基本不使用
RDB的大概执行流程
暂时无法在文档外展示此内容
在指定的时间间隔内将内存中的数据集(集体)快照写入到磁盘内,恢复的时候是将快照文件直接读到内存中
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个近视文件中,等持久化过程都结束了,再用这个临时文件替换上次持久化好的文件,整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那么RDB的方式会比AOF更加的高效,RDB的缺点是最后一次持久化后的数据可能丢失(最后一次持久化有可能宕机),我们默认的就是使用RDB,不需要修改这个配置
RDB保存的文件是 dump.rdb 都是在我们conf配置文件中快照区域(SNAPSHOTTING)进行配置的
RDB在conf配置文件中的相关配置截图,快照部分(SNAPSHOTTING)
dbfilename dump.rdb #redisRDB持久化默认的保存的文件名叫dump.rdb #redis中RDB持久化默认策略 # save 900 1 #在900s内修改1次key 这些都是默认的规则(策略),大多数情况下不需要我们修改 # save 300 10 #在300s内修改10次key # save 60 10000 #在60s内修改10000次key save 60 5 #在60s内修改了5次key
自定义测试RDB持久化,只要我们在60s内修改了5次key,就会触发RDB操作,一旦触发RDB操作就会生成dump.rdb文件
save 60 5 #在60s内修改了5次key
首先我们把dump.rdb文件删除
然后在我们规定的60s内修改5此次key再次查看会发现dump.rdb文件自动生成
#修改下面5个键都是在我们自定义规则一分钟内操作完成的 所以会自动生成dump.rdb文件 127.0.0.1:6379> set k1 v1 #随便set几个key测试 OK 127.0.0.1:6379> set k2 v2 #随便set几个key测试 OK 127.0.0.1:6379> set k3 v3 #随便set几个key测试 OK 127.0.0.1:6379> set k4 v4 #随便set几个key测试 OK 127.0.0.1:6379> set k5 v5 #随便set几个key测试 OK 127.0.0.1:6379> shutdown #宕机redis not connected> ping #重新连接 PONG 127.0.0.1:6379> get k1 #key发现我们redis就算宕机了也会把数据进行持久化 "v1"
发现目录dump.rdb文件自动生成 触发我们的规则
RDB持久化触发机制(生成dump.rdb文件)
1 save的规则满足的情况下(符合我们在conf配置文件中自定义的规定时间内进行多少key的修改),会触发RDB规则
2 执行flushall命令,也会触发我们的RDB规则
3 退出我们的redis,redis宕机,使用shutdown命令,也会触发我们的RDB规则
备份就会自动生成一个dump.rdb文件
如何恢复RDB文件(dump.rdb)
在生产环境一般会将这个dump.rdb文件进行备份,防止数据丢失
1 只需要将RDB文件放在我们redis启动目录下就可以了，redis启动的时候就会自动检查dump.rdb文件恢复其中的数据(全自动的)
2 查看需要存放的位置
127.0.0.1:6379> config get dir #查看查看需要存放的位置 1) "dir" 2) "D:\\Tools\\Java\\Redis" #需要放在的目录,和它在同一级即可,如果存在这个文件(dump.rdb)那么启动时就会自动恢复其中的数据
