文章首发：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 changedsave 300 10    #after 300 sec (5 min) if at least 10 keys changedsave 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的寄存的数据量来决定。

    auto-aof-rewrite-percentage 100auto-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_datemkdir /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

#!/bin/sh cur_date=`date +%Y%m%d`rm -rf /usr/local/redis/snapshotting/$cur_datemkdir /usr/local/redis/snapshotting/$cur_datecp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_datedel_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点的数据。