[Redis学习] Redis持久化对于故障恢复的意义

矫情吗；* 2022-01-26 16:37 212阅读 0赞

# 1. 生产环境中Redis启动前的配置 #

生产环境中，要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动。

## 1.1 Redis各文件目录设置 ##

1.redis的解压目录下，进入utils目录中，找到redis\_init\_script脚本  
2.将redis\_init\_script脚本拷贝到linux的/etc/init.d目录中，将redis\_init\_script重命名为redis\_6379,6379是我们希望这个redis实例监听的端口号  
3.修改redis\_6379脚本的第6行的REDISPORT，设置为相同的端口号(默认就是6379)  
4.创建两个目录： /etc/redis (存放redis的配置文件) ， /var/redis/6379 (存放redis的持久化文件)  
5.修改redis配置文件(默认根目录下，redis.conf),拷贝到/etc/redis目录中，修改名称为6379.conf  
6.修改redis.conf中的部分配置为生产环境

> daemonize   yes                             让redis以daemon进程进行  
> pidfile     /var/run/redis\_6379.pid         设置redis的pid文件位置  
> port        6379                            设置redis的监听端口号  
> dir         /var/redis/6379                 设置持久化文件的存储位置

## 1.2 启动redis，执行脚本 ##

> cd /etc/init.d/redis\_6379  
> ./redis\_6379 start

## 1.3 让redis跟随系统启动自动启动 ##

*  在redis\_6379脚本中，最上面，加入两行注释

> \#chkconfig:2345 90 10  
> \#description: Redis is a persistent key-value database

*  执行如下命令设置开机自启

> chkconfig redis\_6379 on

# 2. 生产环境中Redis持久化配置 #

在生产环境中，为了保证Redis中数据的安全性，都要同时开启RDB持久化和AOF持久化。RDB进行数据冷备，AOF做数据热备。

## 2.1 配置RDB持久化机制 ##

在redis.conf文件，也就是我们这里的/etc/redis\_6379/6379.conf去配置RDB持久化

> save 60 1000

每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting,快照也可以手动调用save或者bgsave命令，同步或异步执行rdb快照生成。

save可以设置多个，就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生了变更，如果有，就生成一个新的dump.rdb文件。如下配置：

> save 900 1  
> save 300 10  
> save 60 10000

## 2.2 基于RDB持久化机制的数据恢复实验 ##

**1.在redis中保存几条数据，立即停掉redis进程，然后重启redis，看看刚才插入的数据还在不在,为什么?**

> 通过redis-cli SHUTDOWN这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照。

**2.在redis中再保存几条新的数据，用kill -9 粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景**

这次就发现，redis进程异常被杀掉，数据没有进dump文件，几条最新的数据丢失了

**3.手动设置一个save检查点， save 5 1 **  
如果启动报pid已经存在，则先删除/var/run/redis\_6379.pid

> rm -rf redis\_6379.pid

写入几条数据，等待5秒钟   
停掉redis进程，再重新启动redis，看刚才插入的数据还在不在，这时我们发现数据可以顺利恢复。

## 2.3 配置AOF持久化机制 ##

在redis.conf文件，也就是我们这里的/etc/redis\_6379/6379.conf去配置AOF持久化

*  AOF持久化，默认是关闭的，默认打开RDB持久化

> \# 可以打开AOF持久化机制  
> appendonly yes

*  打开AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写如os cache的，然后每隔一定时间在fsync一下，可以配置AOF的fsync策略，有三种：always,everysec,no。我们通常都是用everysec,原因我们在上一篇博客中介绍了。

> \# appendfsync always  
> appendfsync everysec  
> \# appendfsync no

*  配置AOF持久化文件rewrite的配置

> auto-aof-rewrite-percentage 100  \# 就是当前AOF大小膨胀到超过上次100%，上次的两倍  
> auto-aof-rewrite-min-size 64mb   \# 根据你的数据量来定，16mb，32mb

*  而且机制AOF和RDB都开启了，redis重启的时候，也是优先通过AOF进行数据恢复的,因为AOF的比较完整。

# 3. 企业级的数据备份方案 #

RDB非常适合做冷备，每次生成之后，就不会再有修改了   
使用定时脚本执行备份方案，crontab -e，该命令详情及使用方法请看百度百科。   
**数据备份方案**

1.写crontab定时调度脚本去做数据备份  
2.每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份  
3.每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份  
4.每次copy备份的时候，都把太旧的备份给删了  
5.每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去  
/usr/local/redis

## 3.1 每小时copy一次备份，删除48小时前的数据 ##

**执行命令：crontab -e**

> 0 \* \* \* \* sh /usr/local/redis/copy/redis\_rdb\_copy\_hourly.sh

**redis\_rdb\_copy\_hourly.sh**

> \#!/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
> 
> del\_date=\`date -d -48hour +%Y%m%d%k\`  
> rm -rf /usr/local/redis/snapshotting/$del\_date

## 3.2 每天copy一次备份,删除一天前的备份 ##

**crontab -e**

> 0 0 \* \* \* sh /usr/local/redis/copy/redis\_rdb\_copy\_daily.sh

**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

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

# 4. 数据恢复方案 #

*  如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据，最多就丢一秒的数
 *  如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复AOF没有破损，也是可以直接基于AOF恢复的。AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix修复，但是要注意的是，修复会导致错误的那条语句被删除，进而导致数据丢失。
 *  如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复
 *  当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据

本文原文地址：[https://blog.csdn.net/why15732625998/article/details/80565044][https_blog.csdn.net_why15732625998_article_details_80565044]

[https_blog.csdn.net_why15732625998_article_details_80565044]: https://blog.csdn.net/why15732625998/article/details/80565044