当前位置:Gxlcms > 数据库问题 > redis配置文件基本解析以及RDB持久化与AOF持久化

redis配置文件基本解析以及RDB持久化与AOF持久化

时间:2021-07-01 10:21:17 帮助过:19人阅读

技术图片

Maxmemory-samples :设置样本数量,LRU算法和最小TTL算法都并非是精确的算法,而是估算值,所以你可以设置样本的大小,redis默认会检查这么多个key并选择其中LRU的那个

redis RDB持久化

什么是redis持久化?用两个关键词来概括,就是RDB和AOF

RDB:Redis DataBase

AOF:Append Only File

那么RDB具体有什么用?

答:在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里

  redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。

  如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork:Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。

RDB保存的是dump.rdb文件

技术图片

 

 

 技术图片

 

 

 技术图片

 

 

 我们为了方便解释,先把这个dump.rdb删掉,然后开两个窗口

技术图片

 

 

 技术图片

 

 

 然后我们备份一份dump.rdb文件并命名为dump_back.rdb文件:

技术图片

 

 

 之后我们在redis中进行清库操作,然后关闭连接:

技术图片

 那么此时,我们的dump.rdb文件应该记录的是什么?

技术图片

我们重新进入redis查看:

技术图片

 可以看到 ,我们之前新增的12个key已经没有了,这是因为我们在执行flushall指令的时候它会立即生成一个新的dump.rdb文件并把原来的覆盖掉,

不过这时候我们之前备份的dump_back.rdb文件就可以派上用场了:

我们先把这次的dump.rdb文件删掉,然后把之前的备份文件复制一份并命名为dump.rdb:

技术图片

 

 

 然后我们再进入redis查看,就可以看到之前 新增的12个key了:

技术图片

 

 

 RDB是整个内存压缩过的Snapshot,RDB的数据结构,可以配置复合的快照触发条件。

如果想禁用RDB持久化的策略,只要不设置任何save指令,或者给save传入一个空字符串参数就可以了。

如果我们传入的参数很重要,要求它立即备份,也可以再redis中键入save来完成手动备份

技术图片

 

 

 技术图片

 

 

 stop-writes-on-bgsave-error yes

这一行说的是当后台保存数据时错误,那么禁止继续写入数据,当然如果配置成no,表示你不在乎数据不一致或者有其他的收端发现和控制。

技术图片

 

 

 rdbcompression :对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能

技术图片

 

 

 rdbchecksum:在存储快照后,还可以让rdis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能。

技术图片

 

 

 总结一下:

如何触发RDB快照:

1、配置文件中默认的快照配置-冷拷贝后重新使用 可以cp dump.rdb dump_back.rdb

2、执行save命令或bgsave:

save:save时只管保存,其他不管,一律阻塞

bgsave:redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。

3、执行flushall命令,也会产生dump.rdb文件,单里面是空的,无意义

如何恢复:

将备份文件(dump.rbd)移动到redis的启动目录(你在哪个目录下启动的redis,哪个目录就是你的启动目录)下并启动服务即可

config get dir 获取目录

rdb的优势:

1、适合大规模的数据恢复

2、对数据的完整性和一致性要求不高

rdb的劣势:

1、在一定时间间隔做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改

2、Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑

如何停止:

动态所有停止RDB保存规则的方法:redis-cli config set save “”

redis AOF持久化:

AOF是什么:以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

我们为了方便解释,先复制一个redis.conf 并命名为redis_aof.conf,然后把所有的rdb文件全部删掉:

技术图片

 

 

 然后把redis_aof.conf里的appendonly 那一项改为yes(默认是no)

技术图片

 

 然后我们在左边的窗口启动redis_aof.conf:

技术图片

 

 然后我们会发现我们的目录里多出来一个appendonly.aof文件:

技术图片

 

我们在redis中新增四个key:

技术图片

 

 然后我们可以在appendonly.aof文件中可以看到它原模原样记录了我们的写动作(甚至我们在哪个库都记录下来了):

技术图片

 

 然后我们执行flushall指令:

技术图片

 

我们会发现appendonly.aof文件中也把flushall这个指令记录下来了:

 技术图片

 

可以看到现在我们的库里面是空的:

 技术图片

 

 然后我们把appendonly.aof文件里面的那行flushall删掉(实际生产中不允许直接修改appendonly.aof文件):

技术图片

 

 然后我们重新启动redis:

技术图片

 

 可以看到,我们的数据又恢复了。

第二个问题,如果dump.rdb和appendonly.aof文件共存,那么启动的是谁?

我们执行一个shutdown命令,它会自动生成一个dump.rdb文件:

技术图片

 

 技术图片

 

 然后我们给appendonly.aof文件搞破坏:

我们键入一大堆无用字符,并保存:

技术图片

 

 那么现在这个文件相当于被损坏掉了。

那么我们再启动redis的时候,如果能够正常启动,说明它找的是dump.rdb文件,如果不能正常启动,那说明它找的是aof文件:

技术图片

 

 如上图,我们可以看到进程并没有被正常启动,说明它是先识别aof文件的,那么我们把aof文件删掉,只保留rdb文件,他就应该能正常启动了,我们来试一下:

技术图片

 

 技术图片

 

 果然可以正常启动,这也再次证明redis启动的时候识别的是aof文件。

那如果不删除aof,怎么修复呢?

我们要用到src目录下的redis-check-aof文件:

技术图片

 

 我们把它复制一份到我的启动目录下,然后执行如下操作:

技术图片

 

 然后我们就可以正常启动redis了:

技术图片

 

 ------------------------------------------------------------------未完待续---------------------------------------------------------

 

redis配置文件基本解析以及RDB持久化与AOF持久化

标签:日志文件   说明   memory   推荐   span   erro   file   策略   时间   

人气教程排行