redis持久化（RDB、AOF、混合持久化）

最新推荐文章于 2024-02-23 14:44:33 发布

半隐退状态

最新推荐文章于 2024-02-23 14:44:33 发布

阅读量1.6k

点赞数 3

文章标签： redis 数据库 database

原文链接：https://www.bilibili.com/read/cv13235983

版权

1. RDB快照（snapshot）

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb的二进制文件中。

你可以对 Redis 进行设置，让它在“N 秒内数据集至少有 M 个改动”这一条件被满足时，

自动保存一次数据集。

比如说，以下设置会让 Redis 在满足“60 秒内有至少有 1000 个键被改动”这一条件时，

自动保存一次数据集：

save 60 1000

优点：

RDB 是一个非常紧凑（compact）的文件，体积小，因此在传输速度上比较快，因此适合灾难恢复。

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快得多。

缺点：

RDB是一个快照过程，无法完整的保存所有数据，尤其在数据量比较大时候，一旦出现故障丢失的数据将更多。

RDB文件是特定的格式，阅读性差，由于格式固定，可能存在不兼容情况。

~~~

bgsave

~~~

bgsave执行原理：

针对save命令进行优化，Redis中所有涉及RDB操作都采用bgsava方式

优势

1.采用子线程创建RDB文件()，不会对redis服务器性能造成大的影响( 性能最大化)；

2.快照生成的RDB文件是一种压缩的二进制文件，可以方便的在网络中传输和保存。通过RDB文件可以方便的将redis数据恢复到某一历史时刻，可以提高数据安全性，避免宕机等意外对数据的影响。

3.适合大规模的数据恢复, RDB的启动恢复效率高。

4.如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

劣势

1.在redis文件在时间点A生成，之后产生了新数据，还未到达另一次生成RDB文件的条件，redis服务器崩溃了，那么在时间点A之后的数据会丢失掉，数据一致性不是完美的好，如果可以接受这部分丢失的数据，可以用生成RDB的方式；

2.快照持久化方法通过调用fork()方法创建子线程。当redis内存的数据量比较大时，创建子线程和生成RDB文件会占用大量的系统资源和处理时间，对 redis处理正常的客户端请求造成较大影响。

3.数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。

4.备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。所以 Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

Q: 通过RDB文件恢复数据?

答: 将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。作者：WeiyiGeek https://www.bilibili.com/read/cv13235983 出处：bilibili

RDB文件恢复数据流程

1、先备份一份 dump.rdb 为 dump_bak.rdb（模拟线上）

2、flushall 清空数据（模拟数据丢失,需要注意 flushall 也会触发rbd持久化）

3、将 dump_bak.rdb 替换为 dump.rdb

4、重启redis服务，恢复数据

2. AOF（append-only file）

快照功能并不是非常耐久（durable）：如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件

AOF文件生成机制

答: 生成过程包括三个步骤,即。

redis 打开AOF持久化功能之后，redis在执行完一个写命令后，把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾，此时缓冲区的记录还没有写到Appendonly.aof文件中。然后，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程，只有经过了文件的同步过程，写命令才真正的被保存到了AOF文件中。选项 Appendfsync 就是配置同步的频率的。

你可以通过修改配置文件来打开 AOF 功能：

appendonly yes

从现在开始，每当 Redis 执行一个改变数据集的命令时（比如 SET），这个命令就会被追加到 AOF 文件的末尾。

这样的话，当 Redis 重新启动时，程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

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

有三个选项：

appendfsync always。每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。

appendfsync everysec。每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。

appendfsync no。从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次，这种 fsync 策略可以兼顾速度和安全性。

优点：

数据更完整，秒级数据丢失(取决于设置fsync策略)。、

兼容性较高，由于是基于redis通讯协议而形成的命令追加方式，无论何种版本的redis都兼容。

aof文件是明文的，可阅读性较好。

缺点：

数据文件体积较大，即使有重写机制，但是在相同的数据集情况下，AOF文件通常比RDB文件大。

相对RDB方式，AOF速度慢于RDB，并且在数据量大时候，恢复速度AOF速度也是慢于RDB。

由于频繁地将命令同步到文件中，AOF持久化对性能的影响相对RDB较大。

AOF文件重写

1、redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，当AOF文件体积过大时，数据恢复的时间也是非常长的，因此，redis提供了重写或者说压缩AOF文件的功能。

比如，AOF重写功能就是干这个事情的。重写时，可以调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。

2、重写的原理:Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（太大了）。最后替换旧的aof文件

3、重写触发机制:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发，这里的“一倍”和“64M” 可以通过配置文件修改

aof 文件记录的是每一条redis命令，有时候我们会对某一个key进行多次set，中间会产生很多条命令，但是结果只有一个。

优势

1.该机制可以带来更高的数据安全性，即数据持久化; 常规三种同步策略即每秒同步()、每修改同步()和不同步；

2.由于该机制对日志文件的写入操作采用的是Append模式，即使过程中出现宕机也不会破坏日志文件中已经存在的内容,如果数据不完整在Redis下次启动之前, 通过redis-check-aof解决数据一致性问题;

3.如果日志文件体积过大可以启动rewrite机制，即redis以Append模式不断的将修改数据写到老的磁盘文件中，同时创建新文件记录期间有哪些修改命令执行，此项极大的保证数据的安全性;

4.AOF文件可读性强,其包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作（）

5.数据的完整性和一致性更高

劣势

1.AOF文件比RDB文件较大, 对于相同数量的数据集而言;

2.redis负载较高时，RDB文件比AOF文件具有更好的性能；

3.RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，因此从理论上来说，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些情况下，AOF的确也存在一些bug，比如使用阻塞命令时，这些bug的场景RDB是不存在的。

4.因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

5.根据同步策略的不同，AOF在运行效率上往往会慢于RDB,总的来说每秒同步策略的效率还是比较高的

set name 1

...

set name 12

set name 123

...

set name 1234

set name 12345

例如我们执行了上述命令，aof 文件会记录着每一条命令。在redis重启时，会逐条执行上述的命令。但是其实可以精简为set name 12345，其余的几条命令其实没有意义。AOF重写就是实现了这个功能。

AOF写和重写流程：

Q: 如何触发AOF快照?

答: 根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。

Q: 如何根据AOF文件恢复数据?

答: 正常情况下，将Appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致文件格式异常，从而导致数据还原失败，可以通过命令进行修复。

配置说明:

~~~

cat > redis.conf <<'EOF'

# 持久化数据存储

dir "/data"

# 是否开启AOF默认为否

appendonly yes

# AOF文件名字及路径，若RDB路径已设置这里可不设置

appendfilename "appendonly.aof"

# AOF的3种模式，no(使用系统缓存处理，快）、always(记录全部操作，慢但比较安全）、everysec(每秒同步，折中方案，默认使用）

appendfsync everysec

# 重写期间是否同步数据，默认为no

no-appendfsync-on-rewrite no

# 配置重写触发机制: 确保AOF日志文件不会过大，保持跟redis内存数据量一致。

# 配置说明:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发(根据实际环境进行配置)

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 256mb

# AOF重写策略是否启用，默认为yes

aof-rewrite-incremental-fsync yes

# 加载AOF时如果报错则会继续但写入log，如果为no则不会继续

aof-load-truncated yes

# Redis5.0有的功能AOF重写及恢复可以使用RDB文件及AOF文件，速度更快，默认yes

aof-use-rdb-preamble yes

EOF

~~~

Q: 如何通过AOF文件恢复数据流程?

1、执行flushall，模拟数据丢失

2、重启 redis 服务，恢复数据

3、修改 appendonly.aof，模拟文件异常

4、重启 Redis 服务失败，这同时也说明了RDB和AOF可以同时存在，且优先加载AOF文件。

5、使用 redis-check-aof 校验 appendonly.aof 文件。

# 针对Redis aof 持久化文件进行完整性检测并进行修复

/usr/local/redis/bin/redis-check-aof --fix appendonly.aof

# The AOF appears to start with an RDB preamble.

# Checking the RDB preamble to start:

# [offset 0] Checking RDB file appendonly.aof

# [offset 27] AUX FIELD redis-ver = '5.0.10'

# [offset 41] AUX FIELD redis-bits = '64'

# [offset 53] AUX FIELD ctime = '1631088747'

# [offset 68] AUX FIELD used-mem = '31554944'

# [offset 84] AUX FIELD aof-preamble = '1'

# [offset 86] Selecting DB ID 0

# [offset 13350761] Checksum OK

# [offset 13350761] \o/ RDB looks OK! \o/

# [info] 157070 keys read

# [info] 0 expires

# [info] 0 already expired

# RDB preamble is OK, proceeding with AOF tail...

# 0x 27b66b0: Expected prefix '*', got: 'R'

# AOF analyzed: size=116993914, ok_up_to=41641648, ok_up_to_line=1816854, diff=75352266

# AOF is not valid. Use the option to try fixing it.

6、重启Redis 服务后正常。

# 利用源实例生成的aof文件数据进行恢复到其它主机中。

redis-cli -h 17.20.0.2 -a password --pipe < applendonly.aof

注意:当你使用 flushall 清空数据的时候，重启redis服务发现数据没恢复，是因为 FLUSHALL 命令也被写入AOF文件中，会导致数据恢复失败，所只需要删除aof文件中的flushall就行了。

在数据库恢复时把 aof(Append only file) 从中对redis数据库操作的命令，增删改操作的命令，执行了一遍即可。

实际案例:

描述: 用于异步执行一个文件重写操作, 重写会创建一个当前 AOF 文件的体积优化版本，因为AOF为记录每次的操作会导致实际记录冗杂、使得文件过大，所以需要做重写操作。

重写方式分为以下两种:

# (1) AOF自动重写:按配置文件条件自动触发重写

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 256mb

# (2) AOF手动重写:使用 redis-cli 连接到 server 端执行 bgrewriteaof 进行手动重写。

# 注意:从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作。

127.0.0.1:6379> BGREWRITEAOF

# 即使 Bgrewriteaof 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 Bgrewriteaof 成功之前不会被修改。

Background append only file rewriting started

合并两个不同实例的数据

描述: 我们可以利用如下方式进行集群多个主节点持久化数据的合并。

(1) AOF 备份合并: 我们说过它实际上是一些列Redis的命令文本。

例如，假设有两台 Redis（6379, 6479），它们的AOF文件名分别为(6379.aof, 6479.aof)，现在要将6379的数据合并到 6479.aof

# 首先

cp 6379.aof 6379.aof.bak, cp 6479.aof 6479.aof.bak

# 合并

cat 6379.aof 6479.aof > new.aof

# 检查&修复

/usr/local/redis/bin/redis-check-aof --fix appendonly.aof

(2) RDB 备份合并: 注意以下方法可能由于服务端版本不同而有些许差异。

RDB格式如下：头5个字节是字符REDIS,之后4个字节代表版本号，阿里的版本分别是 00 00 00 06,之后2个字节 FE 00，FE是标识 00是数据库，还好我们只有一个库, 最后的结尾9个字节 , FF 加上8个字节的CRC64校验码（实在没空弄，后来偷了一个懒）

# 1.线上服务使用的阿里云的集群版本redis服务，数据量1千万，rdb文件4GB,8个rdb文件，每个500MB。

#文件1 大小566346503，截取尾部的9个字节

dd bs=1 if=src_1.rdb of=1.rdb count=566346494

#文件2 大小570214520，跳过头部的11个字节，再截取尾部的9个字节

dd bs=1 if=src_2.rdb of=2.rdb skip=11 count=570214500

...

#文件8 大小569253061，跳过头部的11个字节，再截取尾部的8个字节，保留FF。

dd bs=1 if=src_8.rdb of=8.rdb skip=11 count=569253042

# 2.合并文件(得到备份文件dump.rdb)

cat 1.rdb > dump.rdb

cat 2.rdb >> dump.rdb

...

cat 8.rdb >> dump.rdb

# 3.检查备份文件(应该会提示没有crc校验)

redis-check-rdb dump.rdb

# 4.修改配置文件,因为数据库备份文件里面不包含crc64的校验码，配置文件中关闭选项。

rdbchecksum no

Tips : 数据恢复到此结束，此方法只适合用于临时恢复和导出数据，数据完整性不敢保证。

参考地址: https://github.com/sripathikrishnan/redis-rdb-tools/wiki/Redis-RDB-Dump-File-Format

其它工具:

https://github.com/leonchen83/redis-rdb-cli/ | 一个可以解析, 过滤, 分割, 合并 rdb 离线内存分析的工具. 也可以在两个redis之前同步数据并允许用户自定义同步服务来把redis数据同步到其他地方.

3.混合持久化(redis4.0之后才支持)

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。

如果使用 AOF 日志重放，性能则相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动的时候需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将aof_rewrite_buf重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，如下图：