商品详情页系统 -- day04 部署redis时的数据备份方案与数据恢复

最新推荐文章于 2024-01-11 16:11:04 发布

DJTUDaker

最新推荐文章于 2024-01-11 16:11:04 发布

阅读量367

点赞数

分类专栏：缓存技术（redis/MongoDB）高并发解决方案

本文链接：https://blog.csdn.net/wingzhezhe/article/details/81586538

版权

缓存技术（redis/MongoDB）同时被 2 个专栏收录

11 篇文章 0 订阅

订阅专栏

高并发解决方案

7 篇文章 1 订阅

订阅专栏

一、企业中redis的数据备份方案

1、企业中的持久化的配置策略

（1）、企业中，RDB的生成策略基本上使用默认的三个即可，但如果希望尽可能的保证数据的准确性，即最多只允许丢失1分钟的数据内容，那么就尽可能每隔1分钟生成一次RDB快照，即默认配置中的：save 60 10000。但由于大部分数据在低峰期数据量都非常少，因此一般情况下，没有必要每隔一分钟生成一次快照，即使用其他的默认配置save 900 1 和 save 300 10 即可满足要求。

（2）、AOF一定要打开，并且AOF的生成策略使用默认的 everysec 即可，还有AOF的其他配置，如下：

auto-aof-rewrite-percentage 100: 就是当前AOF文件大小膨胀到超过上次100%，上次的两倍时进行rewrite操作

auto-aof-rewrite-min-size 64mb: AOF文件的最小rewriter大小，根据自己的数据量来定，16mb，32mb等等都可以

2、企业级的数据备份方案

备份方案可以分为：

（1）、小时级备份，把每个小时的数据进行备份保存到一个rdb文件中，仅仅保留48小时的数据。

（2）、每天备份，把每天的数据都进行备份到一个rdb文件中，并且把所有的rdb目录中，改目录只保留近一个月的数据。

（3）、企业中最常用方式：每天晚上将当前服务器上的所有数据进行备份，发送到一个远程的云服务上去，保证每天数据都有备份。

3、演示小时级的操作

（1）、进入 /usr/local 中创建redis数据备份操作文件夹

（2）、创建执行脚本的文件夹，并编写脚本文件

在 /usr/local/redis 中创建copy文件夹，在文件夹中创建进行小时级数据备份的脚本文件redis_rdb_copy_hourly.sh，并赋予执行权限。

#!/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
# 将当前时间的rdb文件备份到当前时间文件夹中
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date

# 获取要删除的备份文件夹的名称(默认删除48小时之前的文件夹)
del_date=`date -d -48hour +%Y%m%d%k`
# 删除48小时之前的文件夹
rm -rf /usr/local/redis/snapshotting/$del_date

（3）、创建snapshotting文件目录，用于存放rdb备份文件

（4）、编写执行redis_rdb_copy_hourly.sh的crontab调度命令

# 0 ：表示第0分
# 之后的*分别代表 ： 任意小时  任意天  任意月   任意周
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

4、演示每天备份的操作

（1）、创建redis_rdb_copy_daily.sh脚本文件并赋予执行权限

#!/bin/sh

cur_date=`date +%Y%m%d`
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 -1month +%Y%m%d`
rm -rf /usr/local/redis/snapshotting/$del_date

（2）、编写crontab定时调度命令

# 表示在任意月份，任意天的第0小时第0分钟执行后面的操作
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

二、数据故障恢复演练

1、redis进程意外终止时，数据恢复

重启redis即可，redis会直接基于AOF日志文件进行数据的恢复

2、redis所在服务器挂掉的情况

重启服务器，重启redis，redis会直接基于AOF日志文件进行数据的恢复，如果AOF有损坏，可以使用redis-check-aof fix命令进行修复之后进行数据恢复。

3、redis的当前最新的AOF和RDB文件出现丢失和损坏的情况

针对当前这种情况，我们通过模拟直接删除 /var/redis/6379中的dump.rdb文件的方式来进行redis数据恢复的容灾演练，具体操作如下：

（1）、手动进行小时级数据备份

（2）、删除/var/redis/6379文件夹下的所有持久化文件

删除持久化文件，重启redis，发现数据已经消失，即成功模拟AOF和RDB文件全部丢失和损坏的情况

（3）、将最新的小时级持久化备份文件拷贝到 /var/redis/6379 目录中

拷入备份文件后，启动客户端发现数据仍然没有恢复，问题发生的原因是什么？

4、步骤3数据未恢复的原因探索

（1）、思考一

问题发现：查看dump.rdb发现其中有数据，但是启动redis客户端时却获取不到数据。

结论：redis中开启AOF持久化机制之后，重启的时候默认优先使用appendonly.aof中的日志进行数据恢复，即使appendonly.aof文件不存在，也会重新创建一个appendonly.aof文件，而dump.rdb文件即使存在，也不会使用dump.rdb文件，因此造成虽然dump.rdb文件中有数据，但是使用客户端连接却查询不到数据的问题。

解决方案：停止redis，暂时在配置文件中关闭AOF机制，拷贝rdb备份文件到/var/redis/6379中，重启redis进行数据恢复实验

（2）、思考二

问题发现：关闭AOF持久化机制后发现数据已经恢复，此时在停止redis，配置文件中打开AOF配置，再启动redis进程，发现数据再一次没有恢复成功

问题结论：同样的问题，redis中开启了AOF机制之后，每次重启都会优先使用appendonly.aof持久化文件，而当前的appendonly.aof持久化文件中并没有数据（因为我们没有进行数据的操作，AOF中的缓存机制不会将操作的日志信息写入appendonly.aof文件中，因此没有数据），此时通过appendonly.aof恢复的redis中仍然是没有数据的。

解决方案：关闭redis，配置文件中关闭AOF机制，拷贝rdb备份文件，重启redis，确认rdb数据已经恢复，通过命令行的热修改命令打开AOF缓存机制，此时，redis会将内存中的数据对应的操作日志写入到appendonly.aof文件中，此时aof和rdb中的数据已经同步，但通过热修改命令开启的AOF机制，实际在配置文件仍然是关闭状态，但此时因为appendonly.aof文件已经是恢复过后的内容，此时，我们可以进行redis配置文件中的修改AOF配置的方式进行修改并重启redis，过程如下：