Redis(二)：Redis的数据备份/读写分离

最新推荐文章于 2024-07-09 09:11:28 发布

CodingALife

最新推荐文章于 2024-07-09 09:11:28 发布

阅读量452

点赞数

分类专栏： Redis 文章标签： java

本文链接：https://blog.csdn.net/mingyuli/article/details/120634728

版权

Redis 专栏收录该内容

7 篇文章 3 订阅

订阅专栏

5.2.1、数据备份目录：/usr/local/redis/copy

6、数据恢复方案

7、redis如何通过读写分离承载读请求qps超过10万+？

7.1、redis高并发跟整个系统的高并发之间的关系

7.2、redis不能支撑高并发的瓶颈在哪里？

7.3、如果redis要支撑超过10万+的并发，那应该怎么做？

7.4、接下来要讲解的一个topic

写在前面：

redis的技术，包括4块

redis各种数据结构和命令的使用，包括java api的使用
redis一些特殊的解决方案的使用，pub/sub消息系统，分布式锁，输入的自动完成等等
redis日常的管理相关的命令
redis企业级的集群部署和架构

集群架构的底层原理，哨兵的底层原理，redis的大规模的架构师如何去支撑海量数据、高并发、高可用的。

1、安装单机版redis

wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz

tar -xzvf tcl8.6.1-src.tar.gz

cd /usr/local/tcl8.6.1/unix/

./configure

make && make install

使用redis-3.2.8.tar.gz（截止2017年4月的最新稳定版）

tar -zxvf redis-3.2.8.tar.gz

cd redis-3.2.8

make && make test && make install

2、redis的生产环境启动方案

要把redis作为一个系统的daemon进程去运行的，每次系统启动，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的配置文件(我的在/home/hadoop))，/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 设置持久化文件的存储位置

（7）启动redis，执行cd /etc/init.d, chmod 777 redis_6379，./redis_6379 start

（8）确认redis进程是否启动，ps -ef | grep redis

（9）让redis跟随系统启动自动启动

在redis_6379脚本中，最上面，加入两行注释

# chkconfig: 2345 90 10

# description: Redis is a persistent key-value database

chkconfig redis_6379 on

3、redis cli的使用

redis-cli SHUTDOWN，连接本机的6379端口停止redis进程

redis-cli -h 127.0.0.1 -p 6379 SHUTDOWN，制定要连接的ip和端口号

redis-cli PING，ping redis的端口，看是否正常

redis-cli，进入交互式命令行

SET k1 v1

GET k1

4、企业级的持久化的配置策略

企业级的数据备份和各种灾难下的数据恢复，是怎么做得呢？

在企业中，RDB的生成策略，用默认的也差不多。
save 60 10000：如果你希望尽可能确保说，RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照，低峰期，数据量很少，也没必要。
是10000条生成RDB还是1000条生成RDB，这个根据你自己的应用和业务的数据量，你自己去决定。
AOF一定要打开，fsync选择everysec。
auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%，上次的两倍。
auto-aof-rewrite-min-size 64mb: 根据你的数据量来定，16mb，32mb。

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

RDB非常适合做冷备，每次生成之后，就不会再有修改了

5.1、数据备份方案

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

5.2、数据备份实操

5.2.1、数据备份目录：/usr/local/redis/copy

cd /etc/local
mkdir redis
cd redis
mkdir copy
cd copy
vim redis_rdb_copy_hourly.sh

1.1、每小时copy一次备份，删除48小时前的数据的脚本文件：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

增加权限：chmod 777 redis/copy/redis_rdb_copy_hourly.sh

1.2、定时任务目录：/usr/local/redis/snapshotting

 crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

1.3、执行定时任务

cd /usr/local/redis/copy

./redis_rdb_copy_hourly.sh

2.1、每天copy一次备份，删除1个月前的数据的脚本文件：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

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

crontab -e

0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

效果：在目录/usr/local/redis/snapshotting下有近48小时和近1个月的数据，用于出现大面积数据错误时的数据恢复。对于数据丢失等故障的恢复时使用最新的dump即可。

6、数据恢复方案

如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据。不演示了，在AOF数据恢复那一块，演示了。如果使用fsync everysec，最多就丢一秒的数据。
如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复。若AOF没有破损，也是可以直接基于AOF恢复的，因为AOF是 append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix即可。
如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复。当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，是人为的造成的。比如：大数据系统hadoop，有人不小心就把hadoop中存储的大量的数据文件对应的目录，rm -rf一下，我朋友的一个小公司，运维不太靠谱，权限也弄的不太好。

举例：/var/redis/6379下的dump和aof文件给删除了。

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

appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的。然后我们自己的dump.rdb是有数据的，但是明显没用我们的数据。

redis启动的时候，自动重新基于内存的数据，生成了一份最新的rdb快照，直接用空的数据，覆盖掉了我们有数据的，拷贝过去的那份dump.rdb。

你停止redis之后，其实应该先删除appendonly.aof，然后将我们的dump.rdb拷贝过去，然后再重启redis。很简单，就是虽然你删除了appendonly.aof，但是因为打开了aof持久化，redis就一定会优先基于aof去恢复，即使文件不在，那就创建一个新的空的aof文件。

方法：停止redis，暂时在配置中关闭aof，然后拷贝一份rdb过来，再重启redis，数据能不能恢复过来，可以恢复过来。脑子一热，再关掉redis，手动修改配置文件，打开aof，再重启redis，数据又没了，空的aof文件，所有数据又没了。

在数据安全丢失的情况下，基于rdb冷备，如何完美的恢复数据，同时还保持aof和rdb的双开？

正确做法：首先停止redis，然后打开配置文件关闭aof，然后拷贝rdb备份到redis中，然后重启redis，确认数据恢复，最后直接在命令行热修改redis配置，打开aof，这个redis就会将内存中的数据对应的日志，写入aof文件中。并且此时aof和rdb两份数据文件的数据就同步了。

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

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