Redis持久化

面试和工作,持久化都是重点!

Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失。所有Redis提供了持久化功能!

RDB(Redis DataBase)

在主从复制中,rdb就是备用的,在从机上面。

image-20201020154837032

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

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

我们默认的就是RDB,一般情况下不需要修改这个配置。RDB保存的文件是 dump.rdb 都是在我们的配置文件中快照中进行配置的!

image-20201020160709035

image-20201020161708496

触发机制:

1、save的规则满足的的情况下,会自动触发rdb规则

2、执行flushall命令,也会触发rdb规则

备份就会自动生成一个dump.rdb文件

image-20201020162900825

如何恢复rdb文件:

1、只需要将rdb文件放在我们的redis启动目录下就可以,redis启动的时候会自动检查dump.rdb文件,并恢复数据。

2、查看需要存放的位置

127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/usr/local/bin" # 如果在这个目录下存在dump.rdb文件,启动的时候就会恢复其中的数据

优点:

1、适合大规模的数据恢复!dump.rdb

2、对数据完整性要求不高,

缺点:

1、需要一定的时间间隔进行操作,如果redis意外宕机了,这个最后一次修改数据就没有了

2、fork进程的时候,会占用一定的内存空间。

AOF(Append Only File)

将我们所有的命令都记录下来,history,恢复的时候就把这个文件全部再执行一遍。

image-20201021085657336

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

AOF保存的是appendonly.aof文件

image-20201022101158528

默认是不开启的,需要手动进行配置!将appendonly 设置为yes。

然后保存配置文件,重启redis服务即可生效。

如果aof文件有错误,这个redis是启动不了的,我们需要修复这个aof配置文件,redsi提供了一个这样的工具redis-check-aof --fix

image-20201022103203775

执行命令:redis-check-aof --fix appendonly.aof

image-20201022103319564

如果文件正常,重启就可以直接恢复了。

**AOF的重写规则:**默认的就是文件的无限追加,文件会越来越大。

image-20201022112949648

如果文件大于64mb,就会fork一个新的进程来将我们的文件进行重写!

优点和缺点:

appendonly no # 默认不开启aof模式的,默认是使用rdb方式持久化的,在大部分情况下,rdb完全够用了

appendfilename "appendonly.aof" # 持久化的文件的名字

# appendfsync always # 每次修改都会同步(sync),消耗性能
appendfsync everysec # 每秒执行一次 sync,可能会丢失这一秒的数据
# appendfsync no # 每次修改都不会同步(sync),这个时候操作系统自己同步数据,速度最快。

优点:

1、每一次修改都同步,文件的完整性会更好。

2、每秒同步一次,可能会丢失一秒的数据。

3、从不同步,效率最高。

缺点:

1、相对于数据文件来说。aof远远大于rdb,修复的速度远远比rdb慢。

2、aof运行效率要比rdb慢,所以redis默认的配置就是rdb持久化。

Q.E.D.