redis学习系列(四)--在项目中部署redis企业级数据备份方案以及各种踩坑的数据恢复容灾演练

素颜马尾好姑娘i 2022-05-29 05:36 69阅读 0赞

到这里为止，其实还是停留在简单学习知识的程度，学会了redis的持久化的原理和操作，但是在企业中，持久化到底是怎么去用得呢？  
企业级的数据备份和各种灾难下的数据恢复，是怎么做得呢？  
1、企业级的持久化的配置策略  
①.在企业中，RDB的生成策略直接使用默认的即可

②.aof默认是关闭的 （appendonly no） 将no改为yes即可，其他的按默认配置即可。

save 900 1
    save 300 10
    save 60 10000   #rdb检查点
    dbfilename dump.rdb #rdb文件名
    dir /var/redis/6379  #rdb及aof文件存储目录
    appendonly yes #开启aof持久化策略
    
    # appendfsync always
    appendfsync everysec #aof持久化策略--每五秒钟只要有一个key发生变化就执行fsync()方法write数据到aof文件中
    # appendfsync no

2、企业级的数据备份方案  
RDB非常适合做冷备，每次生成之后，就不会再有修改了  
数据备份方案

（1）写crontab定时调度脚本去做数据备份

每小时一次备份
    
    crontab -e #在linux控制台输出这个命令
    0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh #输入定时（每小时的第0秒）要执行的文件
    vim /usr/local/redis/copy/redis_rdb_copy_hourly.sh #在/usr/local/redis/copy/redis_rdb_copy_hourly.sh新建文件，编辑文件，写入shell脚本
    #!/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 #将当前的redis rdb文件复制到刚生成的文件夹中做备份
    del_date=`date -d -48hour +%Y%m%d%k` #根据48小时前的时间定义一个变量
    rm -rf /usr/local/redis/snapshotting/$del_date #删除48小时前的文件及文件夹

每天copy一次备份
    crontab -e
    0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh #每天的0时0点0分执行定时任务
    vim /usr/local/redis/copy/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

每天一次将所有数据上传一次到远程的云服务器上去

3、数据恢复方案  
（1）如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据  
（2）如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复  
AOF没有破损，也是可以直接基于AOF恢复的，如果AOF文件破损，那么用redis-check-aof fix  
（3）如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复  
当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，人为。

找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据

容灾演练  
停止redis，关闭aof，拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置，打开aof，这个redis就会将内存中的数据对应的日志，写入aof文件中  
此时aof和rdb两份数据文件的数据就同步了

redis config set 热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，手动修改配置文件，打开aof的命令，再次重启redis即可

（4）如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据  
（5）如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复  
举个例子，12点上线了代码，发现代码有bug，导致代码生成的所有的缓存数据，写入redis，全部错了  
找到一份11点的rdb的冷备，然后按照上面的步骤，去恢复到11点的数据，不就可以了吗