Redis持久化RDB和AOF

RDB

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

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

Rdb 保存的是dump.rdb文件

如何触发RDB快照

如何恢复

优势劣势

实验:

1,先将快照哪里修改为120,表示在两分钟之内如果进行10次写操作,会将写的内容保存到dump.rdb

 修改

 

 

2.启动redis,

 

3.进行写操作

 

4,对dump.rdb进行备份,以防数据丢失(如删库,断电等)

 

5,对数据库进行破坏(删库,断电)

 

6,恢复数据(首先找到备份的rdb文件,然后删除本地的dump.rdb,在删除数据库以后断电了,redis迅速将数据写入rdb,但是已经删除了,所以写入的为空,读出来也为空)

 

7.恢复成功

总结

 AOF

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

Aof保存的是appendonly.aof文件

配置位置:

启动/修复/恢复

异常修复appendaof.conf:

实验:

为了不让配置文件过于复杂,重新建一个redis.conf,名为redis_aof.conf

1,登陆

2.进行写操作,然后删库,断电

 

 3,此时查看appendonly.aof文件,发现数据已经持久化到appendonly.aof里面

 

4,删除appendonly.aof里面的命令flushall,重启成功

 

Rewrite

优势和劣势 

 aof总结

总结

 

生命不止,折腾不息
原文地址:https://www.cnblogs.com/steakliu/p/11401183.html