Redis如何容灾备份

目标：Redis的容灾备份

容灾备份

1.开启RDB持久化

# redis.conf
save 900 1
save 300 10
save 60 10000

2.开启AOF配置

# redis.conf
# 开启aof
appendonly yes
appendfilename "appendony.aof"

# rewrite
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# appendfsync always
appendfsync everysec
# appendfsync no

3.RDB日志备份，编写脚本定时备份

vim一个redis-rdb-copy-per-hour.sh

#!bin/bash
cur_date=$(date "+%Y%m%d%H%M%S")
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir -p /usr/local/redis/snapshotting/$cur_date
cp /usr/local/redis/data/dump.rdb /usr/local/redis/snapshotting/$cur_date

del_date=$(date -d -48hour "+%Y%m%d%H%M")
rm -rf /usr/local/redis/snapshotting/$del_date

使用crontab定时器执行备份脚本

# 打开crontab
crontab -e

然后写入（以下为每10秒执行一次，生产环境可以调整一下每小时执行一次）：

# 打开crontab
# 测试环境
*/1 * * * * sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 10; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 20; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 30; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 40; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh
*/1 * * * * sleep 50; sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh

# 正式环境
* 1 * * * sh /usr/local/redis/bin/redis-rdb-copy-per-hour.sh

4.恢复方法

如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据
如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复
如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复，步骤如下：
1. 停止redis(命令是redis-cli shutdown),
2. 在配置文件中关闭aof: appendonly no
3. 拷贝rdb日志备份到/usr/local/redis/data（如果使用的是docker默认则在/data）目录下
4. 启动redis
5. 尝试get一个key，确认数据恢复
6. 命令热修改redis配置,使用redis-cli连接redis，使用命令redis config set appendonly yes打开aof方式,这样aof和rdb数据就一致了
7. 手动修改redis.conf配置文件中appendonly为yes，因为热修改暂时不会写到配置文件中，所以需要手动修改，然后启动redis，再次确认数据恢复

优化方案

独立部署，硬盘优化

独立部署其实为了解决子进程开销和优化，不要将Redis和其他存储服务器或者消息队列部署在一起，因为RDB和AOF的文件生成除了内存和硬盘开销之外，都属于CPU密集型操作。

也可以根据写入量决定是否使用性能更高的SSD磁盘。

缓存禁用持久化

如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何的持久化方式。

主从模式，从持久化

因为RDB文件只是作为后备用途，建议只是在Slave（从库）上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这一条规则。

如果不Enalbe AOF，仅靠Master-Slave Replication（主从复制）实现高可用高性能也可以。能省掉一大笔的IO也减少了Rewrite（重写）时带来的系统波动。代价是如果Master/Slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个（新浪微博选用的架构模式）。

优化fork处理

如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单的load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF Rewrite 的最后将Rewrite过程中产生的数据写到新的文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF Rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设置到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

还可以修改配置 no-appendfsync-on-rewrite no = yes ，让AOF重写期间不要执行正常追加操作。