redis数据备份

redis是一个内存数据库，如果没有配置持久化，redis重启以后数据就会全部丢失。因此需要开启redis的持久化功能，将数据保存在磁盘上。

redis备份有两种方式，但是两种都可以同时存在进行备份，一种是全量rdb，一种是增量aof。

当redis集群重启的时候，先判断aof文件是否存在，如果存在则加载aof，如果不存在，则加载rdb。

一、RDB

1.1 介绍

• 在指定的时间间隔内将内存中的数据集快照写入磁盘
• 默认的文件名为dump.rdb
• 产生快照的情况
  • save
    • 会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止
  • bgsave
    • fork创建子进程，RDB持久化过程由子进程负责，会在后台异步进行快照操作，快照同时还可以响应客户端请求
  • 自动化
    • 配置文件来完成，配置触发 Redis的 RDB 持久化条件
    • 比如 "save m n"。表示m秒内数据集存在n次修改时，自动触发bgsave
  • 主从架构
    • 从服务器同步数据的时候，会发送sync执行同步操作，master主服务器就会执行bgsave

1.2 rdb的配置

# 时间策略，表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份
save 900 1
# 表示300s内有10条写入，就产生快照
save 300 10  
save 60 10000
#禁用RDB-只需要在save的最后一行写上save ""
# redis servercron 类似于linux的crontab，用来定期执行程序的命令，类似默认每隔100毫秒执行一次

# rdb文件名称-默认dump.rdb
dbfilename dump.rdb

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩--将rdb文件压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

# rdb文件保存路径
dir /usr/local/redis-0.6

1.3 时间策略save

实际生产环境每个时段的读写请求肯定不是均衡的，为此redis提供一种根据key单位时间操作次数来触发一次备份到磁盘，我们可以自由定制什么情况下触发备份，此功能起到平衡性能与数据安全的作用

1.4 触发RDB备份

• 手动触发：手动触发有两种，一种是save，一种是bgsave。通过redis-cli执行即可
  • save:会阻塞当前线程，直至持久化完成以前，服务都是不可用的，线上应该禁止该方式。
  • bgsave:该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候
• 自动触发，以下几种情形会自动触发redis的rdb备份
  • 根据我们的 save m n 配置规则自动触发。这里触发的条件比较苛刻，redis服务器周期性操作函数serverCron默认每隔100毫秒执行一次，主要是检查save选项所设置的条件（只要有一条满足则算）是否已经满足，如果满足就执行bgsave命令。
  • 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave
  • 执行 debug reload 时
  • 执行 shutdown时，如果没有开启aof，也会触发

二、AOF

2.1 AOF配置

# 是否开启aof
appendonly yes

# 文件名称--默认appendonly.aof
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置--当AOF文件的体积大于64MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）的时候
#自动重写的百分比配置
auto-aof-rewrite-percentage 100
#aof文件临界值达到多大重写
auto-aof-rewrite-min-size 64mb

# 加载aof时如果有错如何处理
aof-load-truncated yes # yes表示如果aof尾部文件出问题，写log记录并继续执行。no表示提示写入等待修复后写入

# 文件重写策略
aof-rewrite-incremental-fsync yes

2.2 数据备份

appendfsync 同步模式有三种模式，一般情况下都采用 everysec 配置，在数据和安全里面做平衡性选择，最多损失1s的数据。

• always：把每个写命令都立即同步到aof，很慢，但是很安全

  每个时间事件循环都将AOF_BUF缓冲区的所有内容写入到AOF文件，并且同步AOF文件，这是最安全的方式，但磁盘操作和阻塞延迟，是IO开支较大。

• everysec：每秒同步一次，是折中方案

  每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。如果遇到物理服务器故障，有可能导致最近一秒内aof记录丢失(可能为部分丢失)。

• no：redis不处理交给OS（系统）来处理，非常快，但是也最不安全

  redis并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因OS配置有关。处于no模式下的flushAppendOnlyFile调用无须执行同步操作

AOF的整个流程大体来看可以分为两步，一步是命令的实时写入（如果是 appendfsync everysec 配置，会有1s损耗），第二步是对aof文件的重写。因为实时写入磁盘会带来非常高的磁盘IO，影响整体性能，所以将写入命令放入到内存buffer里，最后在同步到磁盘，这是利用内存高效的特点。

流程如下：命令写入 -> 追加到aof_buf -> 通过时间事件调用flushAppendOnlyFile函数同步到aof磁盘

aof重写过程

aof重写会将旧的aof命令重写入放到新的aof文件文件当中，当重写完成以后原子性的替换旧的aof文件。

在aof重写的过程当中，如果有新的写入命令请求进来，为了能够让aof和命令写入不冲突，aof命令会加载到新旧两个aof的缓冲区当中。这样就能保证新的和旧的命令都不会丢失

三、RDB和AOF对比

3.1 优缺点对比

• RDB的优缺点
  • 优点：
    • RDB最大限度地提高了Redis的性能，父进程不需要参与磁盘I/O
    • 与AOF相比，RDB允许使用大数据集更快地重启
  • 缺点：
    • 如果您需要在Redis停止工作时（例如断电后）将数据丢失的可能性降至最低，则RDB并不好，即如果设置save 60 1000的时候，当60秒以内没有1000条数据写入，这时候redis宕机会丢失这60秒内的数据。
    • RDB经常需要fork（）才能使用子进程持久存储在磁盘上。如果数据集很大，Fork（）可能会非常耗时
• AOF的优缺点
  • 优点：
    • 数据更加安全
    • 当Redis AOF文件太大时，Redis能够在后台自动重写AOF ## INCRE 1 执行10万 = INCREBY10万执行一次
    • AOF以易于理解和解析的格式一个接一个地包含所有操作的日志 # flushdb类似于rm -rf /*
  • 缺点：
    • AOF文件通常比同一数据集的等效RDB文件大
    • 根据确切的fsync策略，AOF可能比RDB慢

四、选择持久化方式

单机的持久化方式：

一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

可以选择以下几种方式：

• RDB持久化与AOF持久化同步使用
• 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据，可以关闭持久化，如果丢失数据可以通过其它途径补回；
• 自己制定策略定期检查Redis的情况，然后可以手动触发备份、重写数据；
• 采用集群和主从同步

在redis4.0以后开始的reweite支持混合模式。即aof和rdb一起使用，默认开启。直接将rdb的持久化方式来操作二进制内容，覆盖到aof文件里，有新的写入的话还是继续使用append命令追加。

集群和主从：

集群和主从是自带备份功能的。通过主从同步的方式进行备份

五、数据恢复

这是针对单机数据故障恢复