Redis持久化

一、RDB

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

在主从复制中,rdb常用在从机上的备用

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

RDB默认保存的文件是 dump.rdb

RDB的触发机制:

  1. save规则满足
  2. 执行flushall也会触发RDB机制
  3. 关闭Redis服务器,也会触发RDB

如何将rdb文件中的数据恢复到Redis数据库中:只需将rdb文件放到Redis启动目录下即可,redis启动时会自动检查dump.rdb文件,恢复其中的数据

查看rdb文件存放的位置:config get dir

优点:适合大规模的数据恢复

缺点:

  1. 需要一定的时间间隔进行操作,如果服务器宕机,最后一次持久化的数据可能会丢失
  2. fork进程的时候,会占用一定的内存空间

二、AOF

AOF(Append Only File)。通俗易懂的将:aof就是将我们所有的命令都记录下来,好比history,恢复的时候就把这个文件在全部执行一遍

注意:AOF默认是不开启的 ,我们只需在配置文件中修改appendonly no 这一项。我们只需将no改成yes就开启了,重启Redis即可生效

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

AOF默认保存的是appendonly.aof文件
如果这个aof文件有错误,这时Redis是无法启动的,我们需要修复这个aof文件,Redis提供了一个aof文件修复工具:redis-check-aof

修复命令:redis-check-aof --fix [aof文件名]

优点:每一次修改都同步,文件的完整性会更好
缺点:

  1. 相对于数据文件来说,aof远远大于rdb,修复的速度也比rdb慢
  2. aof运行效率也要比rdb慢,因此Redis默认使用的是RDB持久化

总结

  1. RDB持久化方式能够在指定时间间隔对数据进行快照存储
  2. AOF持久化方式记录每次对服务器的更新操作,当服务器重启时,重写执行这些命令来恢复数据
  3. 如果Redis只用于做缓存,可以不使用任何持久化
  4. 同时开启两种持久化方式时。在这种情况下,当Redis重启时会优先载入AOF文件来恢复数据,因为在通常情况下AOF文件保存的数据集要比RDB更完整。RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,但建议不要只用AOF,因为RDB更适合用于数据库备份,快速重启,AOF在不断变化的情况下不好备份。并且RDB不会有AOF潜在的BUG。
  5. 性能建议:

    • 因为RDB文件只用作后备用途,建议只在从机上持久化RDB文件,并且只要15分钟备份一次足矣,只保留save 900 1 这条规则。
    • 如果开启AOF,好处是保存的数据完整性高,启动脚本较简单,只load自己的aof文件即可,代价是带来了持续的IO。如果不开启AOF,仅靠主从复制实现高可用性也可以,能省掉大量的IO,也减少了rewrite时带来的系统波动,代价是如果主从机同时宕机,会丢失十几分钟的数据,启动脚本也要比较两个主/从机中的RDB文件,载入最新的那个。
最后修改:2021 年 07 月 05 日 08 : 07 PM
如果觉得我的文章对你有用,请随意赞赏