redis入门(9)：redis数据备份与恢复（rdb/aof）

试验环境：

• centos7.6x64位，CentOS-7-x86_64-Minimal-1810.iso

  百度网盘下载地址：https://pan.baidu.com/s/1ckjQS_DGuI-7GGvmvhLNKQ 提取码: 6gfc
  linux的安装参照：centos7.6最小化安装

• redis-5.0.5.tar.gz

  官网下载地址：http://download.redis.io/releases/redis-5.0.5.tar.gz
  百度网盘下载地址：https://pan.baidu.com/s/1ipnB043h5Tvk7cYGKxSr8g 提取码: bdkh

实验环境注意：

文章后来经过修正后的实验环境是：centos8.2+redis6.0.6

参考：

• Redis 数据备份与恢复
• Redis 性能测试
• Redis系列七：redis持久化
• Redis数据备份与恢复

说明：
redis支持RDB和AOF两种持久化机制，持久化可以避免因进程退出而造成数据丢失。
redis配置文件默认开启rdb，禁用aof。

一、RDB持久化

RDB持久化的本质是将redis中内存的数据做一个快照保存到硬盘进行备份。它有以下特点：

• redis配置文件默认开启的持久化机制
• 当达到一定条件时redis会自动进行rdb持久化，触发rdb自动持久化的配置参考下面，他们是“或”的关系，即：只要有一个条件满足就会自动执行持久化

  save 900 1 #900秒内有至少1个键被更改则进行快照；
  save 300 10 #300秒内有至少10个键被更改则进行快照；
  save 60 10000 #60秒内有至少10000个键被更改则进行快照。

• 每次rdb的持久化都是一个全新的快照，不会修改已有的备份文件。
• rdb持久话的时候会先在磁盘的临时目录生成快照，生成完成后才会拷贝到配置的指定位置（同名文件会替换）。
• rdb持久化时可以对数据进行压缩
• 也可以手动进行持久化（save/bgsave）

  save命令： 阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它。
  bgsave命令： redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化。

• 执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave。（如果开启了aof，我们仍然可以执行shutdown save强制持久化到rdb文件）
• 缺点：无法做到实时持久化，每次都要创建子进程，频繁操作成本过高

bgsave运行流程：

1.1 实验观察redis默认的rdb配置

首先，使用命令/usr/local/redis/bin/redis-server以默认配置开启redis：

然后，使用另外一个客户端进行连接，查看默认配置如下：

可以看到，rdb默认被开启，并且触发条件设置为3600 1 300 100 60 10000，持久化时开启压缩。

1.2 实验save、bgsave命令以及shutdown命令

在上面开启的redis基础上，我们先执行shutdown命令，观察是否自动持久化rdb数据，首先看一下备份目录：

可以看到，此时并没有dump.rdb文件
我们执行shutdown命令：

可以看到，在客户端执行shutdown后，服务端的日志上已经输出了rdb持久化的信息了。
此时，我们看一下备份目录：

由此可以看到：shutdown命令执行后，redis是自动进行rdb持久化的。

1.3 rdb持久化文件的恢复

恢复很简单，先把redis服务关掉，然后将rdb文件拷贝到redis配置文件指定的位置，最后启动redis即可。

二、AOF持久化

由于rdb持久化并不会实时的进行备份（需要达到一定条件或手动触发），所以仅使用rdb进行持久化数据是存在数据丢失的风险的。幸好，redis提供了AOF持久化方式来解决这一问题。
redis默认没有开启aof持久化，需要我们手动开启。
配置参数，参照：

appendonly  yes                    #开启AOF持久化功能；
dir	./							   	   #aof文件存储的目录,这个配置与rdb共用		
appendfilename appendonly.aof          #AOF持久化保存文件名；
appendfsync always                     #每次执行写入都会执行同步，最安全也最慢；
#appendfsync everysec                  #每秒执行一次同步操作；
#appendfsync no                    #不主动进行同步操作，而是完全交由操作系统来做，每30秒一次，最快也最不安全；
auto-aof-rewrite-percentage  100      #当AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据；
auto-aof-rewrite-min-size    64mb      #允许重写的最小AOF文件大小配置写入AOF文件后，要求系统刷新硬盘缓存的机制。

AOF持久化的工作示意图如下：

AOF持久化流程： 命令写入(append),文件同步(sync),文件重写(rewrite),重启加载(load)

流程说明：

• 1，所有的写入命令(set hset)会append追加到aof_buf缓冲区中
• 2，AOF缓冲区向硬盘做sync同步
• 3，随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩
• 4，当redis服务重启，可load加载AOF文件进行恢复

从aof文件中恢复？

redis支持同时开启rdb和aof两个持久化机制，它们在备份的过程中互不影响，但是在恢复时是以AOF方式为主的，因为AOF方式相比RDB方式保存了更全的数据。
恢复的时候和rdb一样，把aof文件拷贝到配置文件指定的目录即可，然后启动redis，它就会读取aof中的命令，等将这些命令执行完了，也就恢复完成了。因为是通过执行命令恢复的，所以时间可能要长点。。。

2.1 实验 aof持久化

准备配置文件如下：
redis.conf

#修改端口为6500
port 6500 
#运行模式改为后台运行
daemonize yes 
#后台运行模式时用来记录进程ID的文件
pidfile /var/run/redis_6500.pid 
#redis日志文件
logfile "/usr/local/redis/bin/log.txt" 
#数据文件
dbfilename dump-6500.rdb
#连接密码
requirepass 123456
#持久化数据保存目录
dir "/usr/local/redis/bin/" 

#开启aof持久化
appendonly  yes
#aof持久化文件名称
appendfilename appendonly.aof 
#每次执行写入都会执行同步,最安全也最慢
appendfsync always 

启动redis：

客户端连接：

此时观察备份目录：

现在只能看到一个空的aof文件（可以打开看看，确实是空的）。
在客户端执行几个命令，如下：

此时我们看一下aof文件：

可以看到，我们执行的命令都在这里面有记录。（另外，因为我们开启了aof，所以如果我们执行shutdown命令，那么不会默认执行bgsave的，你可以试一下。）

如果我们指定了过期时间怎么样呢，恢复时已经过期的数据还会重现嘛？
答：肯定不能重现。
如下图所示：

三、其他的持久化方式

redis本身仅提供了rdb和aof两种方式的持久化，它们都各有优缺点。不过当我们选择主从方式运行redis的时候，我们又多了一种持久化方式：
我们将数据持久化任务加在从redis上，主redis上不再使用rdb或aof，这样能减轻主redis的压力。如果我们担心从redis服务器挂掉的话，可以再增加一个从redis去持久化数据。。。