目标: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数据副本进行数据恢复,步骤如下:
- 停止redis(命令是redis-cli shutdown),
- 在配置文件中关闭aof: appendonly no
- 拷贝rdb日志备份到/usr/local/redis/data(如果使用的是docker默认则在/data)目录下
- 启动redis
- 尝试get一个key,确认数据恢复
- 命令热修改redis配置,使用redis-cli连接redis,使用命令redis config set appendonly yes打开aof方式,这样aof和rdb数据就一致了
- 手动修改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重写期间不要执行正常追加操作。
Comments NOTHING