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

文章首发:Redis的持久化、数据备份方案和数据恢复

redis的持久化

RDB持久化

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

触发:

  1. 客户端在执行shutdown命令时,如果没有开启AOF持久化,那么就会触发RDB的持久化。
  2. 在redis的配置文件中有以下默认配置。在一下的条件成立时,就会触发RDB的持久化,而且是使用save命令完成的。但是save命令会阻塞主进程。一般使用bgsave命令,会fork出一个子进程进行持久化操作。

    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 可以提供多种缓冲区同步硬盘的策略,在性能和安全性方面做出权衡。

触发:

Redis的持久化、数据备份方案和数据恢复_第1张图片

  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的存放的数据量来决定。

    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

#!/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 [email protected]:/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

#!/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点的数据。

你可能感兴趣的:(redisnosql)