版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_32447321/article/details/87275219
因为要重启机器,之前用docker run时,仅想做缓存用,未考虑要持久化;docker restart redis导致原key-value丢失;仅遗留几个key
然后就查看了一下redis默认的持久化策略
alexcn.xyz:6371> keys *
1) "alex"
2) "alex2"
alexcn.xyz:6371> CONFIG GET save
1) "save"
2) "3600 1 300 100 60 10000"
于是乎:手动触发Redis进行RDB持久化的命令:
alexcn.xyz:6370> bgsave
Background saving started
alexcn.xyz:6371> save
OK
(选其一,区别下续)
接下来备份其生成的默认dump.rdb文件(redis数据库),并写入20个 keys
redis中确实存在了新添加20 keys;下图:
alexcn.xyz:6371> keys *
1) "alex_4"
2) "alex"
3) "alex_6"
4) "alex_7"
5) "alex_15"
6) "alex_14"
7) "alex_11"
8) "alex_19"
9) "alex_5"
10) "alex2"
11) "alex_8"
12) "alex_17"
13) "alex_3"
14) "alex_18"
15) "alex_2"
16) "alex_16"
17) "alex_10"
18) "alex_9"
19) "alex_12"
20) "alex_1"
21) "alex_0"
22) "alex_13"
此时默认的RDB并未进行持久化策略 图1,stop服务将会丢失key;
此时stop并把之前备份的 dump.rdb放在load目录,redis中将会是只有最初备份的2个keys
alexcn.xyz:6371> keys *
1) "alex"
2) "alex2"
总结如下:redis的RDB是根据持久化策略进行自动或手动配置的;redis重启后通过读取.rdb文件进行load数据。
ps:
手动触发Redis进行RDB持久化的命令有两种:
1、save
该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止。
显然该命令对于内存比较大的实例会造成长时间阻塞,这是致命的缺陷,为了解决此问题,Redis提供了第二种方式。
2、bgsave
执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短。
基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
ps:执行执行 flushall 命令,也会产生dump.rdb文件,但里面是空的,无意义