Redis数据备份，容灾恢复手段

傷城~ 2023-10-06 21:12 40阅读 0赞

### Redis持久化两种方式 ###

![图片][005b986b403409c6578bd85f67e29dd6.png]

### RDB持久化 ###

#### RDB是什么 ####

RDB持久化的机制是在`一段时间内`达到`某修改次数`，就把内存数据快照Snapshot`持久化`到硬盘上，比如：配置1分钟内修改100次，达到这个条件时，就会进行持久化操作。RDB文件格式是`dump.rdb`

#### 如何配置 ####

![图片][a54859466c7e84b1552aeef8f35962aa.png]

即：在redis.conf文件里配置，截图上的save <seconds> <changes>

如：save 1 100（一分钟内修改100次）

如何停止：在redis.conf文件里配置`save ""`，或者通过命令`config set save ""`

#### 触发RDB几种方式 ####

*  自动触发

> ❝
> 
> 就是上面说的redis.conf里的save配置
> 
> ❞

*  手动触发

> ❝
> 
> 执行`save`命令：save时只管保存，其它不管，全部阻塞
> 
> ❞

> ❝
> 
> 执行`bgsave`命令：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间
> 
> ❞

> ❝
> 
> 执行`flushall`命令，也会产生dump.rdb文件，但里面是空的，无意义
> 
> ❞

#### 持久化原理-fork ####

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感。

那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等），数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

#### 将持久化文件重新加载到内存中 ####

Redis是`基于内存`的，所以要将`硬盘`上的数据重新`加载到内存`中提供服务。

*  将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。
 *  获取 redis 的安装目录可以使用 config get dir 命令

#### RDB优势与劣势 ####

优势

*  适合大规模的数据恢复
 *  对数据完整性和一致性要求不高

劣势

*  在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。
 *  Fork的时候，内存中的数据被`克隆`了一份，`大致2倍`的膨胀性能需要考虑

#### RDB总结 ####

![图片][dce23bdd6c8300ee6433639cb083a197.png]

### AOF持久化 ###

#### AOF是什么 ####

Aof保存的是`appendonly.aof`文件，是将Redis所有的`写命令`（增删改）记录到这个日志文件中，`读命令`不记录。

只允许在文件末尾追加内容，不允许改写文件。

Redis启动的时候就会读取该文件，简而言之，就是将文件中的命令`重新执行`一遍，完成数据恢复到内存的工作。

#### 如何配置 ####

![图片][fb6b00683cfd2e2f13309cf514ab098a.png]

即：在redis.conf文件里配置，截图上的改成`appendonly yes`。

持久化策略

通过Appendfsync配置

*  Appendfsync Always

> ❝
> 
> `每次发生`数据`变更`会被立即`记录`到磁盘，`性能较差`但`数据完整性比较好`
> 
> ❞

*  Appendfsync Everysec

> ❝
> 
> 出厂默认推荐，异步操作，`每秒`记录，如果`一秒`内`宕机`，有数据`丢失`
> 
> ❞

#### AOF启动/恢复/修复 ####

同样我们需要将AOF文件`加载`到`内存`中之后才能`使用`，如果`AOF`文件被`破坏`了，我们该如何`修复`呢？

*  正常恢复到内存中

> ❝
> 
> 将有数据的aof文件复制一份保存到对应目录，目录路径可以通过`config get dir`命令获取，重新启动Redis就可以了
> 
> ❞

*  异常恢复文件到内存中

> ❝
> 
> 备份异常AOF文件，使用命令对文件进行修复：`redis-check-aof --fix 文件名`，然后重新启动Redis就可以了
> 
> ❞

#### Rewrite重写AOF文件 ####

什么是Rewrite

> ❝
> 
> AOF采用`文件追加`方式，文件会`越来越大`为避免出现此种情况，新增了重写机制。
> 
> ❞

> ❝
> 
> 当AOF`文件的大小`超过所设定的`阈值`时，Redis就会`启动`AOF文件的内容`压缩`，只保留可以恢复数据的`最小指令集`.可以使用命令`bgrewriteaof`进行重写文件
> 
> ❞

Rewrite原理

> ❝
> 
> AOF文件持续增长而过大时，会fork出一条`新进程`来将文件重写(也是先写临时文件最后再rename)。
> 
> ❞

> ❝
> 
> 遍历`新进程`的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件。
> 
> ❞

> ❝
> 
> 而是将整个内存中的数据库内容用命令的方式重写了一个`新的aof`文件，这点和快照有点类似
> 
> ❞

触发重写机制

> ❝
> 
> Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍，且文件大于64M时触发
> 
> ❞

#### AOF优势/劣势 ####

优势

*  每次修改同步：appendfsync always同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
 *  每秒同步：appendfsync everysec异步操作，每秒记录，如果一秒内宕机，仅一秒内的数据丢失

劣势

*  相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
 *  Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

#### AOF总结 ####

![图片][64cceea3cc4edeaee4985f4bc025cd94.png]

**文末福利  
可以加小新老师vx免费获取【Java高清路线图】和【全套学习视频和配套资料】**

![43f860877e7d4bd5b7aee44339ebcbd2.png][]

[005b986b403409c6578bd85f67e29dd6.png]: https://img-blog.csdnimg.cn/img_convert/005b986b403409c6578bd85f67e29dd6.png
[a54859466c7e84b1552aeef8f35962aa.png]: https://img-blog.csdnimg.cn/img_convert/a54859466c7e84b1552aeef8f35962aa.png
[dce23bdd6c8300ee6433639cb083a197.png]: https://img-blog.csdnimg.cn/img_convert/dce23bdd6c8300ee6433639cb083a197.png
[fb6b00683cfd2e2f13309cf514ab098a.png]: https://img-blog.csdnimg.cn/img_convert/fb6b00683cfd2e2f13309cf514ab098a.png
[64cceea3cc4edeaee4985f4bc025cd94.png]: https://img-blog.csdnimg.cn/img_convert/64cceea3cc4edeaee4985f4bc025cd94.png
[43f860877e7d4bd5b7aee44339ebcbd2.png]: https://img-blog.csdnimg.cn/43f860877e7d4bd5b7aee44339ebcbd2.png