Featured image of post Redis的持久化、数据备份方案和数据恢复
NoSQL

Redis的持久化、数据备份方案和数据恢复

redis的持久化

RDB持久化

redis会fork创建一个子进程来进行持久化。将数据写进一个临时文件，持久化结束之后会替换上一个持久化好的RDB文件。在这期间redis主进程不会参与持久化，以保证redis的高性能。

触发：

  1. 客户端在执行shutdown命令时，如果没有开启AOF持久化，那么就会触发RDB的持久化。

  2. 在redis的配置文件中有以下默认配置。在一下的条件成立时，就会触发RDB的持久化，而且是使用save命令完成的。但是save命令会阻塞主进程。一般使用bgsave命令，会fork出一个子进程进行持久化操作。

    1
2
3

    save 900 1     #after 900 sec (15 min) if at least 1 key changed
save 300 10    #after 300 sec (5 min) if at least 10 keys changed
save 60 10000  #after 60 sec if at least 10000 keys changed

  3. 执行flushall命令清空内存中的数据时，同时触发持久化，清空磁盘。

优点和缺点

优点：数据恢复比较快，适合大规模的数据恢复，适合当作冷备的方案。

缺点：如果是突然宕机，丢失的数据比较多。数据量大时，持久化生成快照RDB文件会影响redis的性能。

AOF持久化

开启了AOF之后，会将所有命令追加到AOF缓冲区中，根据对应的写入策略写入到磁盘的AOF的持久化文件中。可以说就是redis的一个日志文件，里面记录的是redis的写操作。但是由于记录的是一条条命令，AOF文件会膨胀的很快，达到一定量的时候，就会触发rewrite操作，重写AOF文件，来达到压缩的目的(fork子进程来完成)。

redis 使用单线程响应命令，如果每次写 AOF 文件命令都直接追加到硬盘，那么性能瓶颈完全取于当前硬盘负载。先写入缓冲区 aof_buf 中，还有另一好处，redis 可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出权衡。

触发：

  1. redis的配置文件中默认是没有开启AOF的，要开启在配置文件中打开即可appendonly no —>appendonly yes。也可以在redis已经运行时设置：CONFIG SET appendonly yes，不过这样当redis重启时，设置会失效。
  2. 配置的写入策略触发。
    1. appendfsync everysec(默认)：每秒同步一次命令到AOF持久化文件中，效率很高，可能会丢失1秒的数据。
    2. appendfsync no：从不同步，只需将数据交给操作系统即可。更快，更不安全的方法。通常，Linux将使用此配置每30秒刷新一次数据，但这取决于内核的精确调整。
    3. appendfsync always：每次触发数据变更的时候立即追加到AOF文件中，效率很低，但是很安全。

重写机制：

  1. 默认配置。比如说上一次AOF rewrite之后，是128mb。然后就会接着128mb继续写AOF的日志，如果发现增长的比例，超过了之前的100%，256mb，就可能会去触发一次rewrite。但是此时还要去跟min-size，64mb去比较，256mb > 64mb，才会去触发rewrite。

    因为AOF文件的重写会fork出一个子进程进行重写，为了减少重写次数需要调大下面的参数，但是都是要基于自身使用的redis的存放的数据量来决定。

    1
2

    auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

优点和缺点：

优点：以更好的保护数据不丢失，一般AOF会每隔1秒(默认的同步策略)，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复(使用redis提供的工具可以修复：redis-check-aof --fix)。

日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

缺点：对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。

AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。

类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

RDB和AOF到底该如何选择

  1. 不要仅仅使用RDB，因为那样会导致你丢失很多数据

  2. 也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug

  3. 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复

所以说成年人，全都要！

AOF和RDB同时工作：

  1. 如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting
  2. 如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite
  3. 同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整

redis持久化文件加载流程

  1. 首先是会去判断是否开启了AOF，如果存在存在AOF文件，则直接加载AOF文件
  2. 如果找不到AOF文件，则直接启动，不会加载RDB文件
  3. 如果没有开启AOF，会去加载RDB文件，通过RDB恢复数据

数据备份方案

  1. 写crontab定时调度脚本去做数据备份
  2. 每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份
  3. 每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份
  4. 每次copy备份的时候，都把太旧的备份给删了(是否删除旧的备份，看具体情况而定)
  5. 每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务器(用于存放备份即可，也可以存放在本地)上去。

每小时备份一次：redis_rdb_backup_hourly.sh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#!/bin/sh 

cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
# 备份存放本地
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date
# 备份发送到备份服务器，注意免密码登录
# scp -rq /var/redis/6379/dump.rdb root@192.168.129.100:/opt

# 删除最近48小时的rdb文件
del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date

每小时执行一次该脚本：0 0 * * * ? sh /usr/local/redis/shell/redis_rdb_backup_hourly.sh

每天备份一次：redis_rdb_backup_daily.sh

1
2
3
4
5
6
7
8
9

#!/bin/sh 

cur_date=`date +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=`date -d -1day +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date

每天执行一次备份脚本：0 0 0 * * ? sh /usr/local/redis/shell/redis_rdb_backup_daily.sh

数据恢复方案

（1）如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据

（2）如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复。AOF没有破损，也是可以直接基于AOF恢复的。AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix

（3）如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复。

当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，人为。那就把破损的文件给删除了。去备份服务器找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据

停止redis，关闭aof，拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置，打开aof，这个redis就会将内存中的数据对应的日志，写入aof文件中

此时aof和rdb两份数据文件的数据就同步了

redis config set热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis

（4）如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据

（5）如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复

举个例子，12点上线了代码，发现代码有bug，导致代码生成的所有的缓存数据，写入redis，全部错了

找到一份11点的rdb的冷备，然后按照上面的步骤，去恢复到11点的数据。