Redis持久化机制和线上环境容灾备份与恢复

两种持久化机制

Redis支持RDB和AOF两种持久化机制,持久化功能有效的避免因进程退出造成的数据丢失问题。redis的安装在上篇博文中已经写过了,这篇文章主要用到的linux目录分别如下:
a./etc/redis 该目录下存放过的是redis的配置文件
b./var/redis/6379/ 该目录下存放的是redis的持久化文件
c.在/usr/local目录下创建redis文件夹,在redis文件夹下创建copy文件,在redis下创建snapshotting文件夹

·RDB持久化机制

1.原理
每隔一段时间生成redis内存中的数据的一份完整的快照,例如,现在是12点,redis内存中有1000条数据,这时候redis生成一份RDB日志快照,快照中有1000条数据,我们设置每隔5分钟生成一次快照,到12:05时刻,redis中那个有1500条数据,redis生成一个完整的快照,这个日志文件中有1500条数据。

2.配置
触发持久化的机制有手动触发和自动触发。

• 手动触发

执行bgsave命令即可,执行了bgsave命令后的具体流程如下:

• 自动触发

编辑配置文件: vim /etc/redis/6379.conf文件,手动配置检查点,一条save配置代表一个检查点,redis默认的机制是RDB所以不涉及开启或不开启,我们只需要配置生成快照的时间方式即可,redis中默认有三条,我们可以自己根据实际业务需求设置时间,例如,我想每隔5s,只要有一条数据更新就生成快照

·AOF持久化机制

1.原理
有数据写入redis,redis自身就会将数据写入aof日志文件,redis并不是直接写入aof文件,而是先写到os cache,然后到一定时间再从os cache会触发操作系统的fsync操作写到磁盘

AOF会无限制的增加吗?
不会,redis中的数据是有一定限量的,不可能说redis内存中的数据无限增长,进而导致AOF无限增长,内存大小是一定的,到一定时候,redis就会用缓存淘汰算法,LRU,自动将一部分数据从内存中给清除,AOF是存放每条写命令的,所以会不断的膨胀,当大到一定的时候,AOF做rewrite操作,将AOF变得小一些,然后将旧的删掉
例如,当redis进行了清理,清除了一部分数据,AOF量到一定程度时,会rewrite,根据redis中新的数据进行rewrite,从而将aof变小,然后将旧的删掉
2.配置
同样有两种触发机制,手动触发和自动触发。

• 手动触发
  执行bgrewriteaof命令即可
  
• 自动触发
  由于redis默认的是RDB的持久化方式,AOF的方式默认是关闭的,所以,我们需要手动开启,我们打开/etc/redis/6379.conf配置文件
  a.打开AOF机制

appendonly yes

b.配置rewrite
在/etc/redis/6379.conf文件中有两个配置,auto-aof-rewrite-percentage和auto-aof-rewrite-min-size
第一条命令的意思是,当aof日志文件中的大小大于上一次的一倍了,那就执行rewrite
第二条意思是,就算满足了第一条的条件,但是还是需要和auto-aof-rewrite-min-size配置的值进行比较,当aof的大小大于64m时才会进行rewrite操作

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

c.AOF的三种写入方式,使用默认的everysec即可,即,每秒写入一次

# appendfsync always
appendfsync everysec
# appendfsync no

Redis备份与容灾

脚本备份,例如每小时一个rdb日志文件,我们在/usr/local/redis/目录下创建一个脚本redis_rdb_copy_daily.sh,我们将生成的rdb日志文件以日期命名,在/usr/local/snapshotting目录下存放的是日志文件,下列日志中的cur_date是当前小时的文件夹,我们将其删掉,重新创建一个当前小时命名的文件夹,将redis生成的rdb日志文件拷贝到该目录下,然后将48小时之前的日志删掉

#!//bin/sh
cur_date=`date +%Y%m%d%k`
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir -p /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

通过crotab定时器执行备份脚本:
使用命令crotab -e打开定时器文件,在其中加上执行时间的任务:

0 * * * * sh /usr/local/redis/copy/redis-rdb-copy-hourly.sh

这样有了定时器就会每小时执行一份备份,当我们redis意外停止,数据丢失时,可以通过最新的备份恢复数据

数据恢复方案

a.如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据
b.如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复
c.如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复
①停止redis(命令是redis-cli shutdown),
②在配置文件中关闭aof: appendonly no
③拷贝rdb日志备份到/var/redis/6379目录下
④启动redis(命令是,先到目录/etc/init.d/目录下, ./redis_6379)
⑤尝试get一个key,确认数据恢复
⑥命令热修改redis配置,使用redis-cli连接redis,使用命令redis config set appendonly yes打开aof方式,这样aof和rdb数据就一致了
⑦手动修改6379.conf配置文件中appendonly为yes,因为热修改暂时不会写到配置文件中,所以需要手动修改,然后启动redis,再次确认数据恢复
d.如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据
c.如果是发现有重大的数据错误,就找最新的并且无错的进行恢复