Redis-持久化之RDB（Redis DataBase）

是什么

RDB（Redis DataBase）

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

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

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

Fork

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

备份文件信息

  1. Rdb默认保存的是dump.rdb文件
  2. 保存路径：
    • 默认在redis的安装目录下
    • config get dir 获取rdb文件保存目录
  3. 获取备份文件：
    • 先通过config get dir 查询rdb文件目录
    • 将*.rdb的文件拷贝到别的地方

配置

配置位置：SNAPSHOTTING

SNAPSHOTTING

  1. save

    • save 秒钟 写操作次数

    • 示例：

      • 是1分钟内改了1万次 或5分钟内改了10次 或15分钟内改了1次

      • 1
        2
        3
        save 60 10000 
        save 300 10 
        save 900 1

  2. stop-writes-on-bgsave-error

    • 备份出现错误时停止写入redis
    • 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制

  3. rdbcompression

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

  4. rdbchecksum

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

  5. dbfilename

    • 快照存储名称（备份文件名称）
    • 默认为dump.rdb

  6. dir

    • 目录（默认是执行redis启动命令时所在的目录），也是rdb文件保存目录
    • config get dir 获取目录

如何触发RDB快照（备份）

触发RDB快照的方式

  1. 触发配置文件中默认的快照配置，自动保存

    • 1
      2
      3
      save 900 1
      save 300 10
      save 60 10000

  1. 手动保存快照：命令save或者是bgsave

    • Save：save时只管保存，其他不管，全部阻塞。
    • BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
    • 可以通过lastsave命令获取最后一次成功执行快照的时间。

  2. 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。

  3. 执行shutdown命令（正常关闭redis），也会产生dump.rdb文件，里面有数据。

备份（保存）策略（save）

  1. 方式一：save 秒钟 写操作次数
    • 是1分钟内改了1万次 save 60 10000
    • 或5分钟内改了10次 save 300 10
    • 或15分钟内改了1次 save 900 1
  2. 方式二：禁用自动备份（立即备份）
    • 如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以。

停止备份

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

如何恢复

正常恢复

  1. 将备份文件（dump.rdb）移动到redis安装目录并启动服务即可
    • 冷拷贝后重新使用，可以cp dump.rdb dump_new.rdb
  2. config get dir获取目录

异常恢复

  1. 将被写坏的文件（dump.rdb）移动到redis安装目录
  2. 备份被写坏的文件（dump.rdb）
  3. 修复：redis-check-dump –fix进行恢复
  4. 恢复：重启redis然后重新加载

RDB优缺点

优势

  1. 适合大规模的数据恢复
  2. 对数据完整性和一致性要求不高

劣势

  1. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改；
  2. Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

同时开启两种持久化方式

在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据。

因为在通常情况下AOF文件保存的数据集要不RDB文件保存的数据集要完整。

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。

那要不要只使用AOF呢？

作者建议不要，

因为RDB更适合用于备份数据库（AOF在不断变化不好备份），

快速重启，而且不会有AOF可能潜在的BUG，留一个作为万一的手段。

总结

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。

  • RDB是一个非常紧凑的文件；
  • RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能；
  • 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。
  • 数据丢失风险大
  • RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致redis在一些毫秒级不能响应客户端请求。

最后更新： 2020年07月18日 23:36

原始链接： http://ligangit.com/2020/07/15/Redis-持久化之RDB/

赏
× 请我吃糖~
打赏二维码