Redis如何容灾备份

发布于 2023-06-28  647 次阅读


目标: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.恢复方法

  1. 如果是redis进程挂掉,那么重启redis进程即可,直接基于AOF日志文件恢复数据
  2. 如果是redis进程所在机器挂掉,那么重启机器后,尝试重启redis进程,尝试直接基于AOF日志文件进行数据恢复
  3. 如果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重写期间不要执行正常追加操作。

届ける言葉を今は育ててる
最后更新于 2023-06-28