企业级的持久化的配置策略

在实际生产环境，RDB 和 AOF 一定都要打开，RDB 和 AOF 的配置需要根据业务的数据量决定

Redis RDB 持久化配置和数据恢复实验

RDB 持久化配置

• 自动方式

RDB 持久化在 redis.conf 文件中配置，目前配置文件存放在 /etc/redis/6379.conf，打开配置文件，添加 save 属性配置，定期生成 RDB 快照。

# 每隔15分钟，如果有超过1个key发生了变更，那么就生成一个新的dump.rdb文件
save 900 1
# 每隔5分钟，如果有超过300个key发生了变更，那么就生成一个新的dump.rdb文件
save 300 10
# 每隔1分钟，如果有超过10000个key发生了变更，那么就生成一个新的dump.rdb文件
save 60 10000

save 属性可以设置多个，就是设置多个 SNAPSHOTTING 检查点，每到一个检查点，就会去 check 一下，是否有指定的 key 数量发生了变更，如果有，就生成一个新的 dump.rdb 文件。

• 手动方式

也可以在 redis-cli 命令中输入 save 或者 bgsave 命令，手动同步或异步生成 RDB 快照。

RDB 持久化机制的工作流程

1. Redis 根据配置自己尝试去生成 RDB 快照文件；
2. fork 一个子进程出来；
3. 子进程尝试将数据 dump 到临时的 RDB 快照文件中；
4. 完成 RDB 快照文件的生成之后，就替换之前的旧的快照文件；

基于 RDB 持久化机制的数据恢复实验

通过 redis-cli SHUTDOWN 这种方式去停掉 Redis，其实是一种安全退出的模式，Redis 在退出的时候会将内存中的数据立即生成一份完整的 RDB 快照，存放在 /var/redis/6379/dump.rdb。

需要使用 kill -9 *** 强制杀死进程的方式来模拟 Redis 异常退出。执行步骤如下：

1. 先往 Redis 中插入几条数据；
2. kill -9 强制杀死 Redis 进程，删除 /var/run/redis_6379.pid 文件，再重新启动 Redis；
3. 通过 redis-cli 客户端查看刚刚插入的数据，发现最新的几条数据已经丢失；
4. 配置 save 检查点，save 5 1（每隔5秒，如果有超过1个key发生了变更，那么就生成一个新的dump.rdb文件）；
5. 往 Redis 中插入几条数据，暂停5秒以上；
6. kill -9 强制杀死 Redis 进程，删除 /var/run/redis_6379.pid 文件，再重新启动 Redis；
7. 通过 redis-cli 客户端查看刚刚插入的数据，发现最新的几条数据还在，查看 dump 文件，发现已经更新为成最新的了；

Redis AOF 持久化配置和相关实验

AOF 持久化配置

AOF 持久化配置，默认是关闭的，默认打开的是 RDB 持久化配置。AOF 持久化在 redis.conf 文件中配置，目前配置文件存放在 /etc/redis/6379.conf。

打开配置文件，修改 appendonly 属性为 yes ，打开 AOF 持久化配置：

appendonly yes

AOF 有三种 fsync 策略：

# 每次写入一条数据就执行一次 fsync
# appendfsync always
# 每隔一秒执行一次 fsync
appendfsync everysec
# 不主动执行fsync
# appendfsync no

• always：每次写入一条数据，立即将这个数据对应的写日志 fsync 到磁盘上去，性能非常差，吞吐量很低；
• everysec：每秒将 os cache 中的数据 fsync 到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的；
• no：Redis 只负责将数据写入 os cache 就不管了，后面 os cache 根据自己的策略将数据刷入磁盘，不可控制；

基于 AOF 持久化机制的数据恢复实验

1. 设置 appendonly 属性为 yes，打开 AOF 持久化，重启 Redis；
2. 往 Redis 中写入几条数据，等待一秒；
3. kill -9 强制杀死 Redis 进程，删除 /var/run/redis_6379.pid 文件，再重新启动 Redis；
4. 通过 redis-cli 客户端查看刚刚插入的数据，发现最新的几条数据还在，查看 /var/redis/6379 文件夹，发现已经存在appendonly.aof 文件；

AOF rewrite 操作

Redis 中的内存中的数据是有一定限量的，内存到一定大小后，Redis 就会使用缓存淘汰算法（LRU）自动将一部分过期数据从内存中清除。AOF 是存放没有写命令的，所以文件会不断膨胀，当大到一定的时候，AOF 会做 rewrite 操作。

在 redis.conf 文件中，可以配置 rewrite 策略。

# 如果 AOF 日志文件增长的比例，超过了之前的100%，就可能会去触发一次 rewrite
auto-aof-rewrite-percentage 100
# 但是此时还要去跟min-size比较，大于64M才会去触发一次 rewrite
auto-aof-rewrite-min-size 64mb

AOF rewrite 操作步骤：

1. Redis fork 一个子进程；
2. 子进程基于当前内存中的数据，构建日志，开始往一个新的临时的 AOF 文件中写入日志；
3. Redis 主进程，接收到 client 新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的 AOF 文件；
4. 子进程写完新的日志文件之后，Redis 主进程将内存中的新日志再次追加到新的 AOF 文件中；
5. 用新的日志文件替换掉旧的日志文件；

AOF 破损文件的修复

如果 Redis 在 append 数据到 AOF 文件时，机器宕机了，可能会导致 AOF 文件破损，用 redis-check-aof --fix 命令来修复破损的 AOF 文件。

redis-check-aof --fix /usr/local/appendonly.aof

AOF 和 RDB 同时工作

• 如果 RDB 在执行 snapshotting 操作，那么 Redis 不会执行 AOF rewrite; 如果 Redis 再执行 AOF rewrite，那么就不会执行 RDB snapshotting
• 如果 RDB 在执行 snapshotting，此时用户执行 BGREWRITEAOF 命令，那么等 RDB 快照生成之后，才会去执行 AOF rewrite
• 同时有 RDB snapshot 文件和 AOF 日志文件，那么 Redis 重启的时候，会优先使用 AOF 进行数据恢复，因为其中的日志更完整

企业级的数据备份方案

• 写 crontab 定时调度脚本做数据备份
• 每小时都 copy 一份 rdb 的备份，到一个目录中去，仅仅保留最近48小时的备份
• 每天都保留一份当日的 rdb 的备份，到一个目录中去，仅仅保留最近1个月的备份
• 每次 copy 备份的时候，都把太旧的备份给删了
• 每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去

按小时备份

redis_rdb_copy_hourly.sh

#!/bin/sh 
cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date
del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$del_date

每小时 copy 一次备份，删除48小时前的数据。

crontab -e

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

按天备份

redis_rdb_copy_daily.sh

#!/bin/sh 
cur_date=`date +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date
del_date=`date -d -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date

每天 copy 一次备份，删除一个月前的数据。

crontab -e

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

数据恢复方案

1. 如果是 Redis 进程挂掉，那么重启 Redis 进程即可，直接基于 AOF 日志文件恢复数据；
2. 如果是 Redis 进程所在机器挂掉，那么重启机器后，尝试重启 Redis 进程，尝试直接基于 AOF 日志文件进行数据恢复；
3. 如果 Redis 当前最新的 AOF 和 RDB 文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的 RDB 数据副本进行数据恢复；

恢复步骤参考如下：

• 停止 Redis
• 在 Redis 配置文件中关闭 AOF 持久化配置
• 拷贝云服务上最新的 RDB 备份数据到 /var/redis/6379 文件夹下
• 重启 Redis，确认数据恢复
• 直接在命令行热修改 Redis 配置，config set appendonly yes
• 确认在 /var/redis/6379 文件夹下生成 AOF 持久化文件 appendonly.aof
• 停止 Redis
• 在 Redis 配置文件中打开 AOF 持久化配置
• 重启 Redis，确认数据情况

4. 如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据
5. 如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复

举个例子，12点上线了代码，发现代码有 bug，导致代码生成的所有的缓存数据全部错了，找到一份11点的 rdb 的冷备，然后按照上面的步骤，去恢复到11点的数据，就可以了。

source: //www.yuque.com/yinjianwei/vyrvkf/hm1goc