跟燕青学Redis-Redis主从复制

梦里梦外; 2023-06-16 05:00 42阅读 0赞

## 安装Redis3.0 ##

yum -y install cpp binutils glibc glibc-kernheaders glibc-common glibc-devel gcc make gcc-c++ libstdc+±devel tcl

mkdir -p /usr/local/src/redis  
cd /usr/local/src/redis  
wget http://download.redis.io/releases/redis-3.0.2.tar.gz 或者 rz 上传  
tar -xvf redis-3.0.2.tar.gz  
cd redis-3.0.2  
make  
make test \#这个就不要执行了，需要很长时间  
make install

cp redis.conf /etc/  
vi /etc/redis.conf  
\#修改如下，默认为no  
daemonize yes

\#启动  
redis-server /etc/redis.conf  
\#测试  
redis-cli

## 主从复制 ##

### 主从复制的好处 ###

主从复制的好处有2点：  
1、 避免redis单点故障  
2、 构建读写分离架构，满足读多写少的应用场景

### 主从架构 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70]

### 启动实例 ###

创建6379、6380、6381目录，分别将安装目录下的redis.conf拷贝到这三个目录下。  
![在这里插入图片描述][2019112419553030.png]  
分别进入这三个目录，分别修改配置文件，将端口分别设置为：6379（Master）、6380（Slave）、6381（Slave）。同时要设置pidfile文件为不同的路径。

分别启动三个redis实例：  
![在这里插入图片描述][20191124195545150.png]

### 设置主从 ###

在redis中设置主从有2种方式：

1、 在redis.conf中设置slaveof  
a) slaveof  
2、 使用redis-cli客户端连接到redis服务，执行slaveof命令  
a) slaveof

第二种方式在重启后将失去主从复制关系。

查看主从信息：INFO replication

主：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 1]  
role：角色  
connected\_slaves：从库数量  
slave0：从库信息

从：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 2]

### 测试 ###

在主库写入数据：  
![在这里插入图片描述][20191124195656516.png]  
在从库读取数据：  
![在这里插入图片描述][20191124195709765.png]

## 主从从架构 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 3]

### 启动实例 ###

![在这里插入图片描述][20191124195810627.png]  
设置主从：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 4]  
设置从从：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 5]

### 测试 ###

在主库设置数据：  
![在这里插入图片描述][20191124195909409.png]  
在6380获取数据：  
![在这里插入图片描述][20191124195924819.png]  
在6381获取数据：  
![在这里插入图片描述][20191124195936921.png]

## 从库只读 ##

默认情况下redis数据库充当slave角色时是只读的不能进行写操作。  
可以在配置文件中开启非只读：slave-read-only no  
![在这里插入图片描述][20191124200015835.png]

## 复制原理 ##

1、 当从库和主库建立MS关系后，会向主数据库发送SYNC命令；  
2、 主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来；  
3、 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis；  
4、 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令；  
5、 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致；

## 无磁盘复制 ##

通过前面的复制过程我们了解到，主库接收到SYNC的命令时会执行RDB过程，即使在配置文件中禁用RDB持久化也会生成，那么如果主库所在的服务器磁盘IO性能较差，那么这个复制过程就会出现瓶颈，庆幸的是，Redis在2.8.18版本开始实现了无磁盘复制功能（不过该功能还是处于试验阶段）。

原理：  
Redis在与从数据库进行复制初始化时将不会将快照存储到磁盘，而是直接通过网络发送给从数据库，避免了IO性能差问题。

开启无磁盘复制：repl-diskless-sync yes

## 复制架构中出现宕机情况，怎么办？ ##

如果在主从复制架构中出现宕机的情况，需要分情况看：  
1、 从Redis宕机  
a) 这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；  
b) 问题？ 如果从库在断开期间，主库的变化不大，从库再次启动后，主库依然会将所有的数据做RDB操作吗？还是增量更新？（从库有做持久化的前提下）  
i. 不会的，因为在Redis2.8版本后就实现了，主从断线后恢复的情况下实现增量复制。  
2、 主Redis宕机  
a) 这个相对而言就会复杂一些，需要以下2步才能完成  
i. 第一步，在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务；  
ii. 第二步，将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来；  
b) 这个手动完成恢复的过程其实是比较麻烦的并且容易出错，有没有好办法解决呢？当前有的，Redis提供的哨兵（sentinel）的功能。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191124195452702.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ==,size_16,color_FFFFFF,t_70
[2019112419553030.png]: https://img-blog.csdnimg.cn/2019112419553030.png
[20191124195545150.png]: https://img-blog.csdnimg.cn/20191124195545150.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191124195615399.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191124195633201.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ==,size_16,color_FFFFFF,t_70
[20191124195656516.png]: https://img-blog.csdnimg.cn/20191124195656516.png
[20191124195709765.png]: https://img-blog.csdnimg.cn/20191124195709765.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20191124195751424.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ==,size_16,color_FFFFFF,t_70
[20191124195810627.png]: https://img-blog.csdnimg.cn/20191124195810627.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20191124195827229.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/201911241958442.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA2MjMzOQ==,size_16,color_FFFFFF,t_70
[20191124195909409.png]: https://img-blog.csdnimg.cn/20191124195909409.png
[20191124195924819.png]: https://img-blog.csdnimg.cn/20191124195924819.png
[20191124195936921.png]: https://img-blog.csdnimg.cn/20191124195936921.png
[20191124200015835.png]: https://img-blog.csdnimg.cn/20191124200015835.png