redis学习-27- Redis数据备份和还原及RDB/AOF持久化策略配置

28.数据备份和还原

• Redis SAVE 命令用于创建当前数据库的备份文件，文件名默认为dump.rdb。备份数据库数据可以增强对数据的保护，提升数据的安全性。当数据不小心丢失或者被删除时，我们就可以通过相应的操作进行数据恢复。本节介绍 Redis 的数据备份和数据还原操作。

• 备份数据：SAVE 命令基本语法如下：

redis 127.0.0.1:6379> SAVE

• 执行备份命令：

redis 127.0.0.1:6379> SAVE
OK

注意：命令执行后，将在 Redis 安装目录中自动创建dump.rdb文件（win）。如下图所示：

而在linux中命令执行后，一般会在redis安装目录配置文件所在目录下生成。可以通过CONFIG GET dir命令来查看dump.rdb生成的具体位置。

• **恢复数据:**恢复数据，只需将备份文件 dump.rdb 移动到 Redis 安装目录下，然后重启 Redis 服务器，即可进行数据还原。

• 下面使用CONFIG命令获取 Redis 安装目录，如下所示：

#win下的安装目录
127.0.0.1:6379> config get dir
1) "dir"
2) "E:\\software\\Redis"
#可以得知 Redis 的安装目录为 E:\\software\\Redis

#linux下的安装目录，config无法对受保护的配置参数进行修改如：dir,只能通过修改配置文件进行修改
remote:0>config get dir
 1)  "dir"
 2)  "/usr/local/redis/conf"

• **后台备份数据：**Redis 还提供了一个BGSAVE命令，同样也可以创建 Redis 备份文件，它与SAVE命令的不同之处在于，该命令在后台运行。示例演示：

remote:0>bgsave
"Background saving started"

29.RDB持久化原理和配置策略

• Redis 是一款基于内存的非关系型数据库，它会将数据全部存储在内存中。但是如果 Redis 服务器出现某些意外情况，比如宕机或者断电等，那么内存中的数据就会全部丢失。因此必须有一种机制能够保证 Redis 储存的数据不会因故障而丢失，这就是 Redis 的数据持久化机制。

• 数据的持久化存储是 Redis 的重要特性之一，它能够将内存中的数据保存到本地磁盘中，实现对数据的持久存储。这样即使在服务器发生故障之后，也能通过本地磁盘对数据进行恢复。

• Redis 提供了两种持久化机制：第一种是 RDB，又称快照（snapshot）模式：RDB将当前数据快照到.rdb格式文件，第二种是 AOF 日志，也就追加模式：AOF将写操作追加到缓冲区，再将缓冲区的操作同步到磁盘。

29.1 RDB快照模式原理

• RDB 即快照模式，它是 Redis 默认的数据持久化方式，它在指定的时间间隔内会将内存数据集的快照压缩保存在 dump.rdb 这个二进制文件中，，也就是行话讲的Snapshot快照。所谓“快照”就是将内存数据以二进制文件的形式保存起来，恢复时将快照文件直接读到内存中，一般不需要修改这个默认配置。

• Redis 是单线程的，也就说一个线程要同时负责多个客户端套接字的并发读写，以及内存数据结构的逻辑读写。Redis 服务器不仅需要服务线上请求，同时还要备份内存快照。在备份过程中 Redis 必须进行文件 IO 读写，而 IO 操作会严重降低服务器的性能。那么如何实现既不影响客户端的请求，又实现快照备份操作呢，这时就用到了多进程。
  

• Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化操作。RDB 实际上是 Redis 内部的一个定时器事件，它每隔一段固定时间就去检查当前数据发生改变的次数和改变的时间频率，看它们是否满足配置文件中规定的持久化触发条件。当满足条件时，Redis 就会通过操作系统调用 fork() 来创建与当前进程一样的一个子进程来进行持久化，该子进程与父进程享有相同的地址空间，即：变量、环境变量、程序计数器等数值都和原进程一致，但是一个全新的进程，并作为原进程的子进程。。

• Redis 通过子进程遍历整个内存空间来获取存储的数据，将数据写入一个临时文件中，持久化过程结束后，再用这个临时文件替换上次持久化好的文件。注意，此时的主进程不进行任何IO操作，仍然可以对外提供服务，父子进程之间通过操作系统的 COW 机制实现了数据段分离，从而保证了父子进程之间互不影响，这就确保了极高的性能。若是须要进行大规模数据的恢复，且对于数据恢复的完整性不是很是敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

29.2 RDB持久化触发策略

• RDB 持久化提供了两种触发策略：一种是手动触发，另一种是自动触发。

29.2.1 手动触发策略

• 先确定redis是否启动

方式一：检测后台进程是否存在 ps aux | grep redis
方式二：检测6379端口是否在监听 netstat -lntp | grep 6379

• 手动触发是通过SAVE命令或者BGSAVE命令将内存数据保存到磁盘文件中。如下所示：

remote:0>save
"OK"

remote:0>bgsave
"Background saving started"

remote:0>lastsave
"1671181899"

#如何中止:动态全部中止RDB保存规则的方法
remote:0>config set save ""

#flushall命令也会触发生成dump.rdb文件，但里面是空的，无意义
#redis服务关闭时也会触发生成dump.rdb文件
备份就自动生成一个 dump.rdb

上述命令BGSAVE从后台执行数据保存操作，其可用性要优于执行 SAVE 命令。

SAVE 命令会阻塞 Redis 服务器进程，直到 dump.rdb 文件创建完毕为止，在这个过程中，服务器不能处理任何的命令请求。

BGSAVE命令是非阻塞式的，所谓非阻塞式，指的是在该命令执行的过程中，并不影响 Redis 服务器处理客户端的其他请求。这是因为 Redis 服务器会 fork() 一个子进程来进行持久化操作（比如创建新的 dump.rdb 文件），而父进程则继续处理客户端请求。当子进程处理完后会向父进程发送一个信号，通知它已经处理完毕。此时，父进程会用新的 dump.rdb 文件覆盖掉原来的旧文件。

• 因为SAVE命令无需创建子进程，所以执行速度要略快于BGSAVE命令，但是SAVE命令是阻塞式的，因此其可用性欠佳，如果在数据量较少的情况下，基本上体会不到两个命令的差别，不过仍然建议使用 BGSAVE命令。

注意：LASTSAVE 命令用于查看 BGSAVE 命令是否执行成功。

29.2.2 自动触发策略

• 自动触发策略，是指 Redis 在指定的时间内，数据发生了多少次变化时，会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中，有时候在生产环境我们会将这个文件进行备份。如下所示：
  

• 上图所示， save m n 的含义是在时间 m 秒内，如果 Redis 数据至少发生了 n 次变化，那么就自动执行BGSAVE命令。配置策略说明如下：

  • save 900 1 表示在15分钟内，至少更新了 1 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
  • save 300 10 表示在 5 分钟内，至少更新了 10 条数据，Redis 自动触 BGSAVE 命令，将数据保存到硬盘。
  • save 60 10000 表示 60 秒内，至少更新了 10000 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。

• 只要上述三个条件任意满足一个，服务器就会自动执行BGSAVE命令。当然可以根据实际情况自己调整触发策略。若是想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也能够save “ “

注意：每次创建 RDB 文件之后，Redis 服务器为实现自动持久化而设置的时间计数和次数计数就会被清零，并重新开始计数，因此多个策略的效果不会叠加。

• 恢复过程:只需要将rdb文件放在我们redis数据目录(即：dir目录)就可以，redis启动的时候会自动检查该目录的dump.rdb并恢复其中的数据！若文件异常，用check-dump修复再重启即可

#通过以下命令设置数据目录
config set dir dump.rdb文件位置
#获取数据rdb文件位置
config get dir 

• 生产环境下通常需要将rdb文件进行备份。

29.2.3 RDB持久化优劣势

• 劣势：在 RDB 持久化的过程中，子进程会把 Redis 的所有数据都保存到新建的 dump.rdb 文件中，会占用一定的内存空间，这是一个既消耗资源又浪费时间的操作。因此 Redis 服务器不能过于频繁地创建 rdb 文件，否则会严重影响服务器的性能。
• 劣势：RDB 持久化的最大不足之处在于，最后一次持久化的数据可能会出现丢失的情况。可以这样理解，在 持久化进行过程中，服务器突然宕机了，这时由于没达到自动触发策略导致的存储的数据可能并不完整，比如子进程已经生成了 rdb 文件，但是主进程还没来得及用它覆盖掉原来的旧 rdb 文件，这样就把最后一次持久化的数据丢失了。
• 优势：RDB 数据持久化适合于大规模的数据恢复，并且还原速度快，如果对数据的完整性不是特别敏感（可能存在最后一次丢失的情况），那么 RDB 持久化方式非常合适。
  

30.AOF持久化配置策略

• AOF 被称为追加模式，或日志模式，是 Redis 提供的另一种持久化策略，它能够以日志的形式存储 Redis 服务器已经执行过的的命令，并且只记录对内存有过修改的命令,只许追加文件但不能够改写文件，这种数据记录方法，被叫做“增量复制”，其默认存储文件为appendonly.aof。redis启动之初会读取该文件全部在执行一遍重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复

30.1 开启AOF持久化

• AOF 机制默认处于未开启状态，可以通过修改 Redis 配置文件开启 AOF，如下所示：

• Windows系统执行如下操作：

#修改配置文件，把no改为 yes.将有数据的aof文件复制一份保存到对应目录(config get dir)
#恢复：重启redis而后从新加载
appendonly yes

#确定存储文件名是否正确
appendfilename "appendonly.aof"
#重启服务器
redis-server --service-stop
redis-server --service-start

• Linux系统执行如下操作：

[root@localhost RedisBloom-2.2.9]# cd /usr/local/redis/conf
#修改配置文件：
[root@localhost conf]# vim redis.conf
#把 no 改为 yes
appendonly yes 
#确定存储文件名是否正确
appendfilename "appendonly.aof"

#然后在启动redis服务端，注意redis配置文件的路径
[root@VM-0-3-centos conf]# redis-server redis.conf
#或者使用如下命令启动，要在安装的时候将启动文件加到/etc/init.d/
#sudo /etc/init.d/redis-server restart

应在 Linux 系统上操作 Redis，否则一些 AOF 的性能无法体现，设置完毕，重启Redis服务后会在dir目录生成.aof文件。

aof文件可以通过vim进行查看。

如果aof文件出错了，redis会自动尝试修复，当提示无法修复的时候再用check工具。该工具位于bin目录下

• 测试：将appendonly.aof文件故意修改错误，重启redis服务后redis-cli连接会发现redis无法连接，这时候需要修复这个文件，重启redis服务后连接成功。
  

#修复appendonly.aof文件命令
redis-check-aof -- fix appendonly.aof
#修复后在appendonly.aof之前被修改的内容被还原

30.2 AOF持久化机制

• 每当有一个修改数据库的命令被执行时，服务器就将命令写入到 appendonly.aof 文件中，该文件存储了服务器执行过的所有修改命令，因此，只要服务器重新执行一次 .aof 文件，就可以实现还原数据的目的，这个过程被形象地称之为“命令重演”。
  

• **写入机制:**Redis 在收到客户端修改命令后（读操作不记录），先进行相应的校验，如果没问题，就立即将该命令存追加到 .aof 文件中，也就是先存到磁盘中（只追加文件不可以改写文件），然后服务器再执行命令。这样就算遇到了突发的宕机情况情况，也只需将存储到 .aof 文件中的命令，在redis启动时进行一次“命令重演”就可以恢复到宕机前的状态。

  在上述执行过程中，有一个很重要的环节就是命令的写入，这是一个 IO 操作。Redis 为了提升写入效率，它不会将内容直接写入到磁盘中，而是将其放到一个内存缓冲区（buffer）中，等到缓冲区被填满时才真正将缓存区中的内容写入到磁盘里。

• **重写机制：**Redis 在长期运行的过程中，aof 文件会越变越长。如果机器宕机重启，“重演”整个 aof 文件会非常耗时，导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下“瘦身”运动。

  为了让 aof 文件的大小控制在合理的范围内，Redis 提供了 AOF 重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留能够恢复数据的最小指令集，手动执行BGREWRITEAOF命令，开始重写 aof 文件，如下所示：

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

• 通过上述操作后，服务器会生成一个新的 aof 文件，该文件具有以下特点：

  • 新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致；
  • 新的 aof 文件会使用尽可能少的命令来记录数据库数据，因此新的 aof 文件的体积会小很多；
  • AOF 重写期间，服务器不会被阻塞，它可以正常处理客户端发送的命令。

• 对原有 aof 文件和新生成的 aof 文件做了对比，如下所示：

原有aof文件	重写后aof文件
select 0	SELECT 0
sadd myset Jack	SADD myset Jack Helen JJ Lisa
sadd myset Helen	SET message ‘hello aof’
sadd myset JJ	RPUSH num 4 6 8
sadd myset Lisa
INCR number
INCR number
DEL number
SET message ‘hello redis’
SET message ‘hello aof’
RPUSH num 2 4 6
RPUSH num 8
LPOP num

• 重写原理：AOF文件持续增加而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操做，并无读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点相似

新生成的 aof 文件中，它的命令格式做了很大程度的简化。

• **自动触发AOF重写:**Redis 为自动触发 AOF 重写功能，提供了相应的配置策略,默认无限追加。如下所示：修改 Redis 配置文件，让服务器自动执行 BGREWRITEAOF 命令。

#默认配置项
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #表示触发AOF重写的最小文件体积,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

• 该配置项表示：触发重写所需要的 aof 文件体积百分比，只有当 aof 文件的增量大于 100% 时才会fork一个新的进程进行重写，也就是大一倍。比如，第一次重写时文件大小为 64M，那么第二次触发重写的体积为 128M，第三次重写为 256M，以此类推。如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能。

30.3 AOF策略配置

• 上述介绍写入机制的过程中，如果遇到宕机前，缓冲内的数据未能写入到磁盘中，那么数据仍然会有丢失的风险。服务器宕机时，丢失命令的数量，取决于命令被写入磁盘的时间，越早地把命令写入到磁盘中，发生意外时丢失的数据就会越少，否则越多。

• Redis 为数据的安全性考虑，同样为 AOF 持久化提供了策略配置，打开 Redis 配置文件，如下图所示：
  

• 上述配置策略说明如下：

  • Always 同步持久化：服务器每写入一个命令，就调用一次 fsync 函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据，但是其执行速度较慢,但数据完整性比较好；
  • Everysec（默认）异步操做：服务器每一秒调用一次 fsync 函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据，通常都使用它作为 AOF 配置策略；
  • No：服务器不主动调用 fsync 函数，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的，所以这种策略，不确定性较大，不安全，但是效率是最高的。

注意：Linux 系统的 fsync() 函数可以将指定文件的内容从内存缓存刷到硬盘中。

• 由于是 fsync 是磁盘 IO 操作，所以执行很慢！如果 Redis 执行一条指令就要 fsync 一次（Always），那么 Redis 高性能将严重受到影响。

  在生产环境的服务器中，Redis 通常是每隔 1s 左右执行一次 fsync 操作（ Everysec），这样既保持了高性能，也让数据尽可能的少丢失。最后一种策略（No），让操作系统来决定何时将数据同步到磁盘，这种策略存在许多不确定性，所以不建议使用。

• 从三种策略的运行速度来看，Always 的速度最慢，而 Everysec 和 No 都很快。

• AOF和RDB对比：

RDB持久化	AOF持久化
全量备份，一次保存整个数据库。	增量备份，一次只保存一个修改数据库的命令。
每次执行持久化操作的间隔时间较长。	保存的间隔默认为一秒钟（Everysec）
数据保存为二进制格式，其还原速度快。	使用文本格式还原数据，所以数据还原速度一般。
执行 SAVE 命令时会阻塞服务器，但手动或者自动触发的 BGSAVE 不会阻塞服务器	AOF持久化无论何时都不会阻塞服务器。

相对于数据文件来说，aof远远大于rdb,修复的速度也比rdb慢！
aof运行效率也要比rdb慢，每秒同步策略效率较好，不同效率和rdb相同。所以我们redis默认的配置就是rdb持久化！

• 如果进行数据恢复时，既有 dump.rdb文件，又有 appendonly.aof 文件，应该先通过 appendonly.aof 恢复数据，这能最大程度地保证数据的安全性。
• 若这两种方式同时开启，从性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
  

30.4 RDB/AOF持久化方式比较

• RDB和AOF可以共存，但是恢复的时候找的是AOF，如果AOF文件异常，可以通过check-aof进行AOF修复。
• 两种持久化方式的对比：
  • 1）RDB不能实时持久化数据，如果redis服务器断电可能存在丢失数据的风险。而AOF方式持久化做到实时持久化数据。
  • 2）加载RDB恢复数据远快于AOF方式。因为RDB是二进制数据，而AOF是日志的形式。
  • 3）如果用高版本redis进行RDB持久化的文件用到低版本redis启动恢复会出现不兼容的问题。
• 如果你的数据很大，又希望快速的恢复和备份，换句话说你如果对数据完整性要求低的话，只简单的使用rdb即可
• RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储。
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redisi还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
• 只做缓存，如果只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
• 同时开启两种持久化方式:
  • 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
  • RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，建议不要只使用AOF，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的Bug,留着作为一个万一的手段。
• 性能建议
  • 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save900 1这条规则。
  • 如果Enable AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只Ioad自己的AOF文件就可以了，代价是带来了持续的lO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值
  • 如果不Enable AOF,仅靠Master-Slave Repllcation实现高可用性也可以，能省掉一大笔IO,也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时宕掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构。

下一篇：redis学习-28- Redis Cluster主从模式