redis持久化:RDB和AOF

Redis是一种内存键值存储,其完全在内存中运行,性能非常高效。但一旦发生系统故障或断电,内存中的数据会全部丢失。为了避免这个问题,redis本身提供了持久化的能力,使内存中的数据刷新至磁盘中,便于备份和恢复。

Redis持久化方式

Redis持久化的两种方式

  • RDB 数据库快照
  • AOF 日志追加文件

RDB

RDB是指定时间间隔,定期生成一个时间点快照。快照内包含当前实例的所有数据。

在默认情况下, Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。在配置文件中,调整以下参数使redis在“n秒内有m个操作变动”的情况下保存快照,也能通过执行命令BGSAVESAVE手动保存。

save 60 1000

RDB运作方式

当 Redis 需要保存 dump.rdb文件时, 服务器执行以下操作:

  1. Redis 调用 fork() ,同时拥有父进程和子进程。
  2. 子进程将数据集写入到一个临时 RDB 文件中。
  3. 当子进程完成对新 RDB 文件的写入时,Redis 用新 RDB 文件替换原来的 RDB 文件,并删除旧的 RDB 文件。

RDB优点

  • RDB 是一个非常紧凑的文件,它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份。 比如说,你可以每小时备份一次 RDB 文件,并且在每个月的每一天,也备份一个 RDB 文件。 这样的话,即使遇上问题,也可以随时将数据集还原到不同的版本。
  • RDB 非常适用于灾难恢复。它只有一个文件,并且内容都非常紧凑,可以(在加密后)将它传送到别的数据中心。
  • RDB 可以最大化 Redis 的性能:父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。
  • RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB缺点

  • RDS备份数据不是实时的,发生故障时总会丢失少许(取决于定期保存的周期)数据
  • RDS是通过fock子进程来持久化操作的。当数据量庞大时,fock子进程可能会耗时,造成短时间的延迟。

AOF

AOF是指记录服务器所有的写操作,将命令追加到AOF日志文件末尾。在服务器重启后,Redis通过重新执行日志文件中的命令来恢复数据,比RDB快照恢复的数据要更加完整。

通过修改以下配置开启AOF功能:

appendonly yes

AOF运作方式

AOF 重写和 RDB 创建快照一样,都巧妙地利用了写时复制机制。

以下是 AOF 重写的执行步骤:

  1. Redis 执行 fork() ,现在同时拥有父进程和子进程。
  2. 子进程开始将新 AOF 文件的内容写入到临时文件。
  3. 对于所有新执行的写入命令,父进程一边将它们累积到一个内存缓存中,一边将这些改动追加到现有 AOF 文件的末尾: 这样即使在重写的中途发生停机,现有的 AOF 文件也还是安全的。
  4. 当子进程完成重写工作时,它给父进程发送一个信号,父进程在接收到信号之后,将内存缓存中的所有数据追加到新 AOF 文件的末尾。
  5. Redis 原子地用新文件替换旧文件,之后所有命令都会直接追加到新 AOF 文件的末尾。

AOF优点

  • AOF更加实时,且是有序的对日志进行写入。AOF文件可以直接打开读取,恢复方便。
  • AOF只使用追加的方式写入文件,因此不需要进行文件seek。
  • 当AOF文件过大时,会自动在后台进行重写。重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的,因为 Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕,Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。

AOF缺点

  • 对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积。
  • 根据所使用的 fsync 策略,AOF 的速度可能会慢于 RDB 。 在一般情况下, 每秒 fsync 的性能依然非常高, 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快, 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间。

AOF的耐久性

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。

有三个选项:

  • 每次有新命令追加到 AOF 文件时就执行一次 fsync :非常慢,也非常安全。
  • 每秒 fsync 一次:足够快(和使用 RDB 持久化差不多),并且在故障时只会丢失 1 秒钟的数据。
  • 从不 fsync :将数据交给操作系统来处理。更快,也更不安全的选择。

默认的措施为每秒 fsync 一次, 这种 fsync 策略可以兼顾速度和安全性。

使用场景

一般来说, 如果想达到存储型数据库的数据安全性, 你应该同时使用两种持久化功能。

如果你非常关心你的数据, 但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化, 但我们并不推荐这种方式: 因为定时生成 RDB 快照非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

从RDS切换到AOF

redis支持不停机的情况下,从RDS切换到AOF。

  1. 备份最新的RDB快照文件。
  2. 执行命令CONFIG SET APPENDONLY YES,这个命令会阻塞当前,直到AOF文件创建完成,创建完成后,将数据写入AOF
  3. 检查数据
  4. 在配置文件中开启appendonly yes,防止重启后配置丢失。

Redis的备份

Redis 对于数据备份是非常友好的, 因为你可以在服务器运行的时候对 RDB 文件进行复制。RDB 文件一旦被创建, 就不会进行任何修改。 当服务器要创建一个新的 RDB 文件时, 它先将文件的内容保存在一个临时文件里面, 当临时文件写入完毕时, 程序才使用原子地用临时文件替换原来的 RDB 文件。

所以备份可以通过复制RDB文件来实现,

  • 创建一个定期任务(cron job), 每小时将一个 RDB 文件备份到一个文件夹。
  • 确保快照的备份都带有相应的日期和时间信息, 每次执行定期任务脚本时, 使用 find 命令来删除过期的快照: 比如说, 你可以保留最近 48 小时内的每小时快照, 还可以保留最近一两个月的每日快照。
  • 至少每天一次, 将 RDB 备份到你的数据中心之外, 或者至少是备份到其他物理主机上。

猜你喜欢

转载自blog.csdn.net/u010230971/article/details/80335543