Redis持久化+灾难恢复方案
# Redis持久化和灾难恢复
# 前言
Redis是如何将数据持久化到硬盘?
在生产环境中,Redis如何进行灾难恢复?
如果你想了解更多Persistence和Disaster recovery方面的知识，亦可参考官方文档：https://redis.io/docs/manual/persistence/ (opens new window)
# 一、Redis Persistence
Redis是一种key-value型的非关系型内存数据库，Redis持久化是指将数据持久化存储，例如存储到SSD中，Redis提供了如下的持久化方案:
# 1、RDB 快照
默认情况下，Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中，可以配置redis"当N秒内有M次数据的变动"触发一次保存，或者也可以手动的调用save 或 bgsave 命令手动生成dump快照，手动执行save命令是同步的，会阻塞线程
# save
下面的命令“当redis在60 秒内有至少有 1000 个键被改动“，dump一次快照：
//60 秒内有至少有 1000 个键被改动
//关闭RDB只需要将所有的save保存策略注释掉即可
save 60 1000
2
3
# bgsave
bgsave使用到redis一种copy-on-write技术，过程如下
1、当redis开始dump时，会fork出一个子线程。
2、由子线程写入一个临时的RDB文件。
3、写入完成后，替换掉旧文件。
save和bgsave的区别
区别 save bgsave IO类型 同步 异步 是否阻塞redis其它命令 是 否(在生成子进程执行调用fork函 数时会有短暂阻塞) 复杂度 O(n) O(n) 优点 不会消耗额外内存 不阻塞客户端命令 缺点 阻塞客户端命令 需要fork子进程，消耗内存 RDB方式使用的是bgsave命令
# 2、AOF (Append Only File)
将修改的指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间fsync到磁盘)
# 基本配置
通过下面的配置开启:
appendonly yes
多久fsync一次到磁盘，有三个选项：
appendfsync always #每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
appendfsync everysec #默认。每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。
appendfsync no #从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择
2
3
# AOF重写
自动重写配置:
#aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
auto-aof-rewrite-min-size 64mb
#aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-percentage 100
#不触发重写
auto-aof-rewrite-percentage 0
2
3
4
5
6
除了自动重写外，AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof，它也使用到redis一种copy-on-write技术，过程如下：
- 当redis开始rewrite时，会fork出一个子线程。
- 由子线程写入一个临时的RDB文件。
- 写入完成后，替换掉旧文件
Tips:当你不小心使用了flushall指令，只要rewrite没有执行，你依然恢复你的数据，关闭redis，删除AOF中的flushall指令，重启服务即可
# 3、Redis 4.0 混合持久化
重启 Redis 时， 选择AOF 文件恢复数据相对于RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。
通过下面的配置开启(必须先开启aof)：
aof-use-rdb-preamble yes
混合持久化过程如下：
- 主线程会fork出一个子进程
- 子进程会把内存中的数据以RDB的方式写入新的aof中
- 把重写缓冲区中的增量命令以AOF方式写入到新文件
- 将含有RDB个数和AOF格数的AOF数据覆盖旧的AOF文件
文件格式：
# 4、AOF和RDB，我们应该选哪一个？
| 命令 | RDB | AOF |
|---|---|---|
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 容易丢失数据 | 根据策略决定 |
当RDB和AOF两种持久化方式都开启时，Redis重启会选择AOF文件恢复数据，因为相对而言，AOF文件的数据更全
# 二、Disaster recovery
在Redis的环境中，灾难恢复和备份是基本上一样的，只是在此基础上将持久化文件备份到外部的数据中心。这样，即使在一些灾难性事件，数据也是安全的。
# 灾难预防方案
- 将每天或者每小时的RDB文件加密后（gpg -c等）传输到云存储服务器上，例如：Amazon s3,Ali cloud等
- 通过SCP(SSH的一部分)命令将文件传输到其它服务器上
# 预防备份策略
- 创建一个crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
- 每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份
- 保证备份文件命名包含日期和时间，保证每次copy备份的时候，都把太旧的备份给删了
- 每天一次将Redis机器上的备份复制一份到其他机器上，以防机器损坏
# 思维导图
