Redis持久化（RDB&AOF）

DreamTT
150 阅读7分钟

RDB（Redis Database）

RDB持久性以指定的时间间隔，执行数据集的时间点快照

实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写

Redis7以后的时间间隔设置

1689496286535.png

  1. 自动备份，设置时间间隔
  2. 手动备份，两个命令sava 和 bsave

save和bgsave区别

save在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用

basave：Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程

fork：在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。

RDB优点

  • RDB是Redis 数据的一个非常紧凑的单文件时间点表示。RDB 文件非常适合备份。例如，我们可能希望在最近的 24 小时内每小时归档一次 RDB 文件，并在30天内每天保存一个RDB 快照。这使我们可以在发生灾难时轻松恢复不同版本的数据集。
  • RDB 非常适合灾难恢复，”它是一个可以传输到远程数据中心或Amazon S3(可能已加)的压缩文件。
  • RDB 最大限度地提高了 Redis 的性能，因为 Redis 父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程。父进程永远不会执行磁盘I/O 或类似操作。与AOF相比，RDB 允许使用大数据集更快地重启
  • 在副本上，RDB 支持重启和故障转移后的部分重新同步

RDB缺点

  • 如果我们需要在 Redis 停止工作时(例如断电后)将数据丢失的可能性降到最低，那么RDB并不好。我们可以配置生成 RDB 的不同保存点(例如，在对数据集至少5分钟和100次写入之后，可以有多个保存点)。但是，我们通常会每五分钟或更长时间创建一次 RDB 快照，因此，如果 Redis 由于任何原因在没有正确关闭的情况下停止工作，我们应该准备好丢失最新分钟的数据。
  • RDB 需要经常 fork以便使用子进程在磁盘上持久化。如果数据集很大，fork可能会很耗时，并且如果数据集很大并且 CPU 性能不是很好，可能会导致 Redis 停止为客户端服务几毫秒甚至一秒钟。AOF 也需要 fork但频率较低，您可以调整要重写日志的频率，而不需要对持久性进行饪何权衡。

哪些情况会触发RDB快照(将内存内容写入磁盘)

  1. 配置文件中默认的快照配置
  2. 手动sava/bgsave命令
  3. 执行flushall/flushdb命令
  4. 执行shutdown且没有设置开启AOF持久化
  5. 主从复制时，主节点自动触发

AOF（Append Only File）

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

默认情况下，redis是没有开启AOF(append only file)的。开启AOF功能需要设置配置: appendonly yes

image.png image.png

AOF中三种写回策略（AOF缓存区的内容写入AOF文件）

  • Always：同步写回，每个写命令执行完立刻同步的将日志写回磁盘
  • eversec:每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区的内容写入磁盘(默认策略)
  • no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

image.png

Redis7 AOF新特性，将一个AOF文件拆分成了三个 base基本文件，incr增量文件，manifest清单文件 image.png

AOF优点

  • 使用AOF Redis 更加持久: 您可以有不同的fsync 策略: 根本不fsync、每秒fsync、每次查询时fsync。使用每秒fsync 的默认策略，写入性能仍然很棒。fsync 是使用后台线程执行的，当没有 fsync正在进行时，主线程将努力执行写入，因此您只能丢失一秒钟的写入。
  • AOF 日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电时出现损坏问题。即使由于某种原因(磁盘已满或其他原因) 日志以写一半的命令结尾，redis-check-aof 工具也能够轻松修复它
  • 当AOF 变得大大时，Redis 能够在后台自动重写AOF。重写是完全安全的，因为当 Redis 继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始附加到新的那一个。
  • AOF以易于理解和解析的格式依次包合所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使您不小心使用该FLUSHALL命令刷新了所有内容，只要在此期间没有执行日志重写，您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存您的数据集.

AOF缺点

  • AOF文件通常比相同数据集的等效 RDB 文件大
  • 根据确切的 fsync 策略，AOF 可能比 RDB 慢。一般来说，将fsync 设置为每秒性能仍然非常高，并且在禁用 fsync 的情况下，即使在高负载下它也应该与 RDB 一样快。即使在巨大的写入负载的情况下，RDB 仍然能够提供关于最大延迟的更多保证。

AOF自动重写机制

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大,文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩.只保留可以恢复数据的最小指令集 或者可以手动使用命令 bgrewriteaof 来重新

举个栗子：

set k1 v1
set k1 v2 
set k1 v3

如果不重写，这三条语句都在aof文件中，既会占用内存空间，启动时候也都要执行一遍。重写后的话aof文件就只会有 set k1 v3这条指令

image.png 当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文供保存的数据集要完整。

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢? 作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。

image.png

avatar
文章
阅读
粉丝