[转帖]Redis 备份与恢复（RDB/AOF）说明

1 RDB 方式

1.1 RDB 备份恢复说明

Redis 的备份恢复有两种方法：RDB和AOF。

其中RDB 文件是一个经过压缩的二进制文件,有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE。

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。
BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求。

Redis并没有专门载入RDB文件的命令，RDB文件的载入工作是在服务器启动时自动执行的。只要Redis服务器在启动时检测到RDB文件存在，它就会自动载入RDB文件。在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止。

可以通过如下命令获取redis 的安装目录：

127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/"
127.0.0.1:6379>

我们这里默认在根目录下。该参数是个静态参数，无法动态修改。只能通过修改配置文件并重启Redis 实例生效。

Redis 7 参数修改说明
https://www.cndba.cn/dave/article/108066

如果需要恢复数据，只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。

如果恢复了RDB 文件，在Redis 的日志中也会有记录。

1.2 自动间隔性保存

SAVE命令由服务器进程执行保存工作，BGSAVE命令则由子进程执行保存工作，所以SAVE命令会阻塞服务器，而BGSAVE命令则不会。

因为BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。

用户可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。

Save的默认配置如下：

127.0.0.1:6379> config get save
1) "save"
2) "3600 1 300 100 60 10000"
127.0.0.1:6379>

这里参数说明如下：

save 3600 1          3600秒内，如果至少发生了1次写入，则存一次
save 300 100        500秒内，如果至少发生了100次写入，则存一次）
save 60 10000      60秒后，如果至少发生了10000次写入，则存一次）

Redis的服务器默认每隔100毫秒就会执行一次函数serverCron，该函数用于对正在运行的服务器进行维护，它的其中一项工作就是检查save选项所设置的保存条件是否已经满足，如果满足的话，就执行BGSAVE命令。

因为我们dir 默认在根目录下，所以我们查看自动生成的rdb文件：

[dave@www.cndba.cn /]# ll /*.rdb
-rw-r--r-- 1 root root 149 Jun 12 18:44 /dump.rdb
[dave@www.cndba.cn /]#
36003

当然，我们也可以手工修改这个默认配置：

127.0.0.1:6379> config set save '3600 10 300 20 60 20000'
OK
127.0.0.1:6379> config get save
1) "save"
2) "3600 10 300 20 60 20000"
127.0.0.1:6379>

2 AOF 方式

除了RDB持久化功能之外，Redis还提供了AOF（Append Only File）持久化功能。与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态。

redis> SET msg "hello" 
OK
redis> SADD fruits "apple" "banana" "cherry" 
(integer) 3
redis> RPUSH numbers 128 256 512 
(integer) 3

RDB持久化保存数据库状态的方法是将msg、fruits、numbers三个键的键值对保存到RDB文件中，而AOF持久化保存数据库状态的方法则是将服务器执行的SET、SADD、RPUSH三个命令保存到AOF文件中。
被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的，因为Redis的命令请求协议是纯文本格式，所以我们可以直接打开一个AOF文件，观察里面的内容。

服务器在启动时，可以通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态，这个过程在日志中也会有记录。

2.1 AOF持久化的实现

AOF持久化功能的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤。

2.1.1 命令追加

当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾。

2.1.2 AOF文件的写入与同步

Redis的服务器进程是一个事件循环（loop），这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像serverCron函数这样需要定时运行的函数。

因为服务器在处理文件事件时可能会执行写命令，使得一些内容被追加到aof_buf缓冲区里面，所以在服务器每次结束一个事件循环之前，它都会调用flushAppendOnlyFile函数，考虑是否需要将aof_buf缓冲区中的内容写入和保存到AOF文件里面。

2.1.3 文件的写入和同步

为了提高文件的写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。

这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。
为此，系统提供了fsync和fdatasync两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性。

2.1.4 AOF持久化的效率和安全性

服务器配置appendfsync选项的值直接决定AOF持久化功能的效率和安全性。

当appendfsync的值为always时，服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件，并且同步AOF文件，所以always的效率是appendfsync选项三个值当中最慢的一个，但从安全性来说，always也是最安全的，因为即使出现故障停机，AOF 持久化也只会丢失一个事件循环中所产生的命令数据。
当appendfsync的值为everysec时，服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件，并且每隔一秒就要在子线程中对AOF文件进行一次同步。从效率上来讲，everysec模式足够快，并且就算出现故障停机，数据库也只丢失一秒钟的命令数据。
当appendfsync的值为no时，服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件，至于何时对AOF文件进行同步，则由操作系统控制。因为处于no模式下的flushAppendOnlyFile调用无须执行同步操作，所以该模式下的AOF文件写入速度总是最快的，不过因为这种模式会在系统缓存中积累一段时间的写入数据，所以该模式的单次同步时长通常是三种模式中时间最长的。从平摊操作的角度来看，no模式和everysec模式的效率类似，当出现故障停机时，使用no模式的服务器将丢失上次同步AOF文件之后的所有写命令数据。

2.2 AOF文件的载入与数据还原

同RDB的恢复一样，在Redis 启动时会自动应用AOF 文件。因为AOF文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读入并重新执行一遍AOF文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。

Redis读取AOF文件并还原数据库状态的详细步骤如下：

创建一个不带网络连接的伪客户端（fake client）：因为Redis的命令只能在客户端上下文中执行，而载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行AOF文件保存的写命令，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样。
从AOF文件中分析并读取出一条写命令。
使用伪客户端执行被读出的写命令。
一直执行步骤2和步骤3，直到AOF文件中的所有写命令都被处理完毕为止。

当完成以上步骤之后，AOF文件所保存的数据库状态就会被完整地还原出来。

2.3 AOF重写

因为AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的AOF文件很可能对Redis服务器、甚至整个宿主计算机造成影响，并且AOF文件的体积越大，使用AOF文件来进行数据还原所需的时间就越多。

为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写（rewrite）功能。通过该功能，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。

2.3.1 AOF文件重写的实现

虽然Redis将生成新AOF文件替换旧AOF文件的功能命名为“AOF文件重写”，但实际上，AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。

2.3.2 AOF后台重写

AOF重写程序aof_rewrite函数可以很好地完成创建一个新AOF文件的任务，但是，因为这个函数会进行大量的写入操作，所以调用这个函数的线程将被长时间阻塞，因为Redis服务器使用单个线程来处理命令请求，所以如果由服务器直接调用aof_rewrite函数的话，那么在重写AOF文件期间，服务期将无法处理客户端发来的命令请求。

很明显，作为一种辅佐性的维护手段，Redis不希望AOF重写造成服务器无法处理请求，所以Redis决定将AOF重写程序放到子进程里执行，这样做可以同时达到两个目的：

子进程进行AOF重写期间，服务器进程（父进程）可以继续处理命令请求。
子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

不过，使用子进程也有一个问题需要解决，因为子进程在进行AOF重写期间，服务器进程还需要继续处理命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后的AOF文件所保存的数据库状态不一致。

为了解决这种数据不一致问题，Redis服务器设置了一个AOF重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当Redis服务器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区，

这也就是说，在子进程执行AOF重写期间，服务器进程需要执行以下三个工作：

执行客户端发来的命令。
将执行后的写命令追加到AOF缓冲区。
将执行后的写命令追加到AOF重写缓冲区。

这样一来可以保证：

AOF缓冲区的内容会定期被写入和同步到AOF文件，对现有AOF文件的处理工作会如常进行。
从创建子进程开始，服务器执行的所有写命令都会被记录到AOF重写缓冲区里面。

当子进程完成AOF重写工作之后，它会向父进程发送一个信号，父进程在接到该信号之后，会调用一个信号处理函数，并执行以下工作：

将AOF重写缓冲区中的所有内容写入到新AOF文件中，这时新AOF文件所保存的数据库状态将和服务器当前的数据库状态一致。
对新的AOF文件进行改名，原子地（atomic）覆盖现有的AOF文件，完成新旧两个AOF文件的替换。

这个信号处理函数执行完毕之后，父进程就可以继续像往常一样接受命令请求了。
在整个AOF后台重写过程中，只有信号处理函数执行时会对服务器进程（父进程）造成阻塞，在其他时候，AOF后台重写都不会阻塞父进程，这将AOF重写对服务器性能造成的影响降到了最低。

3 操作示例

3.1 RDB备份恢复操作示例

3.1.1 修改默认的dir 目录

[dave@www.cndba.cn ~]# redis-cli
127.0.0.1:6379> auth redis
OK
127.0.0.1:6379> config get dir
1) "dir"
2) "/"
127.0.0.1:6379>

该参数是静态参数，要从配置文件修改并重启Redis实例：

[dave@www.cndba.cn ~]# cat /etc/redis.conf |grep dir|grep -v "^#"
dir "/data/redis"
appenddirname "appendonlydir"
[dave@www.cndba.cn ~]#
[dave@www.cndba.cn ~]# systemctl restart redis.service

[dave@www.cndba.cn ~]# redis-cli
127.0.0.1:6379> auth redis
OK
127.0.0.1:6379> config get dir
1) "dir"
2) "/data/redis"
127.0.0.1:6379>

3.1.2 创建KV对象

127.0.0.1:6379> get key1
(nil)
127.0.0.1:6379> set website "https://www.cndba.cn"
OK
127.0.0.1:6379> set author "tianlesoftware"
OK
127.0.0.1:6379> set name dave
OK
127.0.0.1:6379> get website
"https://www.cndba.cn"
127.0.0.1:6379> get authro
(nil)
127.0.0.1:6379> get name
"dave"
127.0.0.1:6379>

3.1.3 手工执行save

默认策略也会自动执行save，我们这里手工执行一下：

127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379>    

查看文件：
[dave@www.cndba.cn redis]# pwd
/data/redis
[dave@www.cndba.cn redis]# ll
total 4
-rw-r--r-- 1 root root 157 Jun 16 19:44 dump.rdb
[dave@www.cndba.cn redis]#

3.1.4 重启Redis

[dave@www.cndba.cn ~]# systemctl restart redis.service

可以看到之前创建的kv都在Redis中：
127.0.0.1:6379> keys *
1) "name"
2) "website"
3) "author"
127.0.0.1:6379> get name
"dave"
127.0.0.1:6379> get website
"https://www.cndba.cn"
127.0.0.1:6379> get author
"tianlesoftware"
127.0.0.1:6379>

如果我们此时删除备份文件，在重启，就没有这些值了。

[dave@www.cndba.cn redis]# pwd
/data/redis
[dave@www.cndba.cn redis]# ls
dump.rdb
[dave@www.cndba.cn redis]# rm -rf dump.rdb
[dave@www.cndba.cn redis]# systemctl restart redis.service
[dave@www.cndba.cn redis]# ll
total 4
-rw-r--r-- 1 root root 157 Jun 16 19:50 dump.rdb
[dave@www.cndba.cn redis]#

但在测试时发现，在重启时会自动生成rdb文件，所以我们这里采用非正常的方法，直接kill 进程：

[dave@www.cndba.cn redis]# pwd
/data/redis
[dave@www.cndba.cn redis]# rm -rf dump.rdb
[dave@www.cndba.cn redis]# ps -ef|grep redis
root     21115 18932  0 19:48 pts/1    00:00:00 redis-cli
root     21512     1  0 19:50 ?        00:00:00 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root     21720 19243  0 19:51 pts/2    00:00:00 grep --color=auto redis
[dave@www.cndba.cn redis]# kill -9 21512 21115
[dave@www.cndba.cn redis]# ll
total 0
[dave@www.cndba.cn redis]# systemctl restart redis.service
[dave@www.cndba.cn redis]# ps -ef|grep redis
root     21811     1  0 19:51 ?        00:00:00 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root     21830 19243  0 19:51 pts/2    00:00:00 grep --color=auto redis
[dave@www.cndba.cn redis]# ll
total 0
[dave@www.cndba.cn redis]#

[dave@www.cndba.cn ~]# redis-cli
127.0.0.1:6379> auth redis
OK
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379>

之前保存的kv就没有了。

这里通过测试也发现在正常关闭Redis 的情况下，会自动执行bgsave，生成RDB文件。

3.2 AOF 备份恢复操作示例

3.2.1 配置AOF

配置AOF 主要涉及如下几个参数：

AOF开关 appenonly
默认为NO，表示不启用AOF，改成YES 则启用AOF。
AOF持久化文件名配置appendfilename
该参数保存的AOF的文件名。
AOF同步频率 appendfsync

该参数有3个值：

always 每一次写入都同步
everysec 每秒同步一次，推荐这一种方式，即使丢失也只是丢失1秒的数据
no 从不同步，这里no并不是永远不同步，只是将数据交到操作系统手中。更快，更不安全的方法。通常，Linux 将使用此配置每 30 秒刷新一次数据，但这取决于内核的精确调整。

重写规则配置
auto-aof-rewrite-min-size：设置触发重写条件的文件基准值
auto-aof-rewrite-percentage：设置文件超过最小基准值的xx百分比那就重写，比如auto-aof-rewrite-min-size设置为100MB，auto-aof-rewrite-percentage设置为100，则当AOF 达到200MB的时候，就出发rewrite操作。

我们这里相关参数修改如下：

[dave@www.cndba.cn redis]# cat /etc/redis.conf |grep -E "append|auto-aof"|grep -v "^#"
appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
[dave@www.cndba.cn redis]#

重启Redis 让参数生效：

[dave@www.cndba.cn redis]# systemctl restart redis.service

127.0.0.1:6379> config get append*
1) "appenddirname"
2) "appendonlydir"
3) "appendfilename"
4) "appendonly.aof"
5) "appendfsync"
6) "everysec"
7) "appendonly"
8) "yes"
127.0.0.1:6379>

3.2.2 创建kv 对象

127.0.0.1:6379> set website "https://www.cndba.cn"
OK
127.0.0.1:6379> set author "tianlesoftware"
OK
127.0.0.1:6379>
127.0.0.1:6379>
127.0.0.1:6379> set name dave
OK
127.0.0.1:6379> keys *
1) "author"
2) "website"
3) "name"
127.0.0.1:6379>

查看生成的OAF 文件：

[dave@www.cndba.cn redis]# ll
total 8
drwxr-xr-x 2 root root  103 Jun 16 20:15 appendonlydir
-rw-r--r-- 1 root root   88 Jun 16 20:15 dump.rdb
-rw-r--r-- 1 root root 2548 Jun 16 20:15 redis.log
[dave@www.cndba.cn redis]# cd appendonlydir/
[dave@www.cndba.cn appendonlydir]# ll
total 12
-rw-r--r-- 1 root root  88 Jun 16 20:15 appendonly.aof.1.base.rdb
-rw-r--r-- 1 root root 155 Jun 16 20:17 appendonly.aof.1.incr.aof
-rw-r--r-- 1 root root  88 Jun 16 20:15 appendonly.aof.manifest
[dave@www.cndba.cn appendonlydir]# pwd
/data/redis/appendonlydir
[dave@www.cndba.cn appendonlydir]#

AOF 文件内容可以直接查看：

[dave@www.cndba.cn appendonlydir]# cat appendonly.aof.1.incr.aof
*2
$6
SELECT
$1
0
*3
$3
set
$7
website
$20
https://www.cndba.cn
*3
$3
set
$6
author
$14
tianlesoftware
*3
$3
set
$4
name
$4
dave
[dave@www.cndba.cn appendonlydir]#

3.2.3 重启Redis

[dave@www.cndba.cn ~]# systemctl restart redis.service

[dave@www.cndba.cn ~]# redis-cli
127.0.0.1:6379> auth redis
OK
127.0.0.1:6379> keys *
1) "name"
2) "website"
3) "author"
127.0.0.1:6379>

3.2.4 查看日志

日志里会记录Redis 的操作构成，这里摘录如下：

[dave@www.cndba.cn redis]# tail -30 redis.log
25716:M 16 Jun 2022 20:15:35.491 # Server initialized
25716:M 16 Jun 2022 20:15:35.497 * Creating AOF base file appendonly.aof.1.base.rdb on server start
25716:M 16 Jun 2022 20:15:35.502 * Creating AOF incr file appendonly.aof.1.incr.aof on server start
25716:M 16 Jun 2022 20:15:35.502 * Ready to accept connections

#接收到关闭Redis 的请求：
25716:signal-handler (1655382174) Received SIGTERM scheduling shutdown...
25716:M 16 Jun 2022 20:22:54.525 # User requested shutdown...
#同步AOF和RDB:
25716:M 16 Jun 2022 20:22:54.525 * Calling fsync() on the AOF file.
25716:M 16 Jun 2022 20:22:54.525 * Saving the final RDB snapshot before exiting.
25716:M 16 Jun 2022 20:22:54.529 * DB saved on disk
25716:M 16 Jun 2022 20:22:54.529 * Removing the pid file.
25716:M 16 Jun 2022 20:22:54.529 # Redis is now ready to exit, bye bye...
27023:C 16 Jun 2022 20:22:54.543 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
27023:C 16 Jun 2022 20:22:54.543 # Redis version=7.0.1, bits=64, commit=00000000, modified=0, pid=27023, just started
27023:C 16 Jun 2022 20:22:54.543 # Configuration loaded
27023:M 16 Jun 2022 20:22:54.544 * Increased maximum number of open files to 10032 (it was originally set to 1024).
27023:M 16 Jun 2022 20:22:54.544 * monotonic clock: POSIX clock_gettime
27023:M 16 Jun 2022 20:22:54.545 * Running mode=standalone, port=6379.
27023:M 16 Jun 2022 20:22:54.545 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
27023:M 16 Jun 2022 20:22:54.545 # Server initialized
#初始化的时候先加载AOF，然后加载RDB
27023:M 16 Jun 2022 20:22:54.546 * Reading RDB base file on AOF loading...
27023:M 16 Jun 2022 20:22:54.546 * Loading RDB produced by version 7.0.1
27023:M 16 Jun 2022 20:22:54.546 * RDB age 439 seconds
27023:M 16 Jun 2022 20:22:54.546 * RDB memory usage when created 0.84 Mb
27023:M 16 Jun 2022 20:22:54.546 * RDB is base AOF
27023:M 16 Jun 2022 20:22:54.546 * Done loading RDB, keys loaded: 0, keys expired: 0.
27023:M 16 Jun 2022 20:22:54.546 * DB loaded from base file appendonly.aof.1.base.rdb: 0.000 seconds
27023:M 16 Jun 2022 20:22:54.546 * DB loaded from incr file appendonly.aof.1.incr.aof: 0.000 seconds
27023:M 16 Jun 2022 20:22:54.546 * DB loaded from append only file: 0.000 seconds
27023:M 16 Jun 2022 20:22:54.546 * Opening AOF incr file appendonly.aof.1.incr.aof on server start
27023:M 16 Jun 2022 20:22:54.546 * Ready to accept connections
[dave@www.cndba.cn redis]#

因为AOF文件的更新频率通常比RDB文件的更新频率高，所以在启动Redis时：

如果服务器开启了AOF持久化功能，服务器会优先使用AOF文件来还原数据库状态。
只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。

4 总结

Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
若只打算用Redis 做缓存，可以关闭持久化。
若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。