Redis3.0 主从复制及哨兵配置

Redis3.0 主从复制及哨兵配置

1.安装Redis

#命令步骤

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.主从复制（读写分离）

主从复制的好处有2点：

1、 避免redis单点故障

2、 构建读写分离架构，满足读多写少的应用场景

2.1. 主从架构

 

2.1.1. 启动实例

创建6379、6380、6381目录，分别将安装目录下的redis.conf拷贝到这三个目录下。

分别进入这三个目录，分别修改配置文件，将端口分别设置为：6379（Master）、6380（Slave）、6381（Slave）。同时要设置pidfile文件为不同的路径。

分别启动三个redis实例：

2.1.2. 设置主从

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

1、 在redis.conf中设置slaveof

 a) slaveof <masterip> <masterport>

2、 使用redis-cli客户端连接到redis服务，执行slaveof命令

 a) slaveof <masterip> <masterport>

 

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

查看主从信息：INFO replication 

主：

role：角色

connected_slaves：从库数量

slave0：从库信息

从：

2.1.3. 测试

在主库写入数据：

在从库读取数据：

2.2. 主从从架构

2.2.1. 启动实例

设置主从：

设置从从：

2.2.2. 测试

在主库设置数据：

在6380获取数据：

在6381获取数据：

2.3. 从库只读

默认情况下redis数据库充当slave角色时是只读的不能进行写操作。

可以在配置文件中开启非只读：slave-read-only no

2.4. 复制的过程原理

1、 当从库和主库建立MS关系后，会向主数据库发送SYNC命令；

2、 主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来；

3、 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis；

4、 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令；

5、 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致；

2.5. 无磁盘复制

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

原理：

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

 

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

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

如果在主从复制架构中出现宕机的情况，需要分情况看：

1、 从Redis宕机

 a) 这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；

 b) 问题？ 如果从库在断开期间，主库的变化不大，从库再次启动后，主库依然会将所有的数据做RDB操作吗？还是增量更新？（从库有做持久化的前提下）

  i. 不会的，因为在Redis2.8版本后就实现了，主从断线后恢复的情况下实现增量复制。

2、 主Redis宕机

 a) 这个相对而言就会复杂一些，需要以下2步才能完成

  i. 第一步，在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务；

  ii. 第二步，将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来；

 b) 这个手动完成恢复的过程其实是比较麻烦的并且容易出错，有没有好办法解决呢？当前有的，Redis提高的哨兵（sentinel）的功能。

3. 哨兵（sentinel）

3.1. 什么是哨兵

 顾名思义，哨兵的作用就是对Redis的系统的运行情况的监控，它是一个独立进程。它的功能有2个：

 

 1、 监控主数据库和从数据库是否运行正常；

 2、 主数据出现故障后自动将从数据库转化为主数据库；

3.2. 原理

单个哨兵的架构：

多个哨兵的架构：

多个哨兵，不仅同时监控主从数据库，而且哨兵之间互为监控。

3.3. 环境

当前处于一主多从的环境中：

3.4. 配置哨兵

当前处于一主多从的环境中：

启动哨兵进程首先需要创建哨兵配置文件：

 

vim sentinel.conf

输入内容：

sentinel monitor hadoopMaster 127.0.0.1 6379 1

 

说明：

hadoopMaster：监控主数据的名称，自定义即可，可以使用大小写字母和“.-_”符号

127.0.0.1：监控的主数据库的IP

6379：监控的主数据库的端口

1：最低通过票数

 

启动哨兵进程：

redis-sentinel ./sentinel.conf

由上图可以看到：

1、 哨兵已经启动，它的id为9059917216012421e8e89a4aa02f15b75346d2b7

2、 为master数据库添加了一个监控

3、 发现了2个slave（由此可以看出，哨兵无需配置slave，只需要指定master，哨兵会自动发现slave）

3.5. 从数据库宕机

kill掉2826进程后，30秒后哨兵的控制台输出：

 

2989:X 05 Jun 20:09:33.509 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster 127.0.0.1 6379

 

说明已经监控到slave宕机了，那么，如果我们将3380端口的redis实例启动后，会自动加入到主从复制吗？

2989:X 05 Jun 20:13:22.716 * +reboot slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster 127.0.0.1 6379

2989:X 05 Jun 20:13:22.788 # -sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster 127.0.0.1 6379

 

可以看出，slave从新加入到了主从复制中。-sdown：说明是恢复服务。

3.6. 主库宕机

哨兵控制台打印出如下信息：

 

2989:X 05 Jun 20:16:50.300 # +sdown master hadoopMaster 127.0.0.1 6379  说明master服务已经宕机

2989:X 05 Jun 20:16:50.300 # +odown master hadoopMaster 127.0.0.1 6379 #quorum 1/1  

2989:X 05 Jun 20:16:50.300 # +new-epoch 1

2989:X 05 Jun 20:16:50.300 # +try-failover master hadoopMaster 127.0.0.1 6379  开始恢复故障

2989:X 05 Jun 20:16:50.304 # +vote-for-leader 9059917216012421e8e89a4aa02f15b75346d2b7 1  投票选举哨兵leader，现在就一个哨兵所以leader就自己

2989:X 05 Jun 20:16:50.304 # +elected-leader master hadoopMaster 127.0.0.1 6379  选中leader

2989:X 05 Jun 20:16:50.304 # +failover-state-select-slave master hadoopMaster 127.0.0.1 6379 选中其中的一个slave当做master

2989:X 05 Jun 20:16:50.357 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ hadoopMaster 127.0.0.1 6379  选中6381

2989:X 05 Jun 20:16:50.357 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ hadoopMaster  127.0.0.1 6379  发送slaveof no one命令

2989:X 05 Jun 20:16:50.420 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ hadoopMaster 127.0.0.1 6379   等待升级master

2989:X 05 Jun 20:16:50.515 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ hadoopMaster 127.0.0.1 6379  升级6381为master

2989:X 05 Jun 20:16:50.515 # +failover-state-reconf-slaves master hadoopMaster 127.0.0.1 6379

2989:X 05 Jun 20:16:50.566 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster 127.0.0.1 6379

2989:X 05 Jun 20:16:51.333 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster 127.0.0.1 6379

2989:X 05 Jun 20:16:52.382 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster 127.0.0.1 6379

2989:X 05 Jun 20:16:52.438 # +failover-end master hadoopMaster 127.0.0.1 6379 故障恢复完成

2989:X 05 Jun 20:16:52.438 # +switch-master hadoopMaster 127.0.0.1 6379 127.0.0.1 6381  主数据库从6379转变为6381

2989:X 05 Jun 20:16:52.438 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster 127.0.0.1 6381  添加6380为6381的从库

2989:X 05 Jun 20:16:52.438 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ hadoopMaster 127.0.0.1 6381  添加6379为6381的从库

2989:X 05 Jun 20:17:22.463 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ hadoopMaster 127.0.0.1 6381 发现6379已经宕机，等待6379的恢复

可以看出，目前，6381位master，拥有一个slave为6380.

 

接下来，我们恢复6379查看状态：

2989:X 05 Jun 20:35:32.172 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ hadoopMaster 127.0.0.1 6381  6379已经恢复服务

2989:X 05 Jun 20:35:42.137 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ hadoopMaster  127.0.0.1 6381  将6379设置为6381的slave

3.7. 配置多个哨兵

vim sentinel.conf

输入内容：

sentinel monitor hadoopMaster2 127.0.0.1 6381 2

sentinel monitor hadoopMaster2 127.0.0.1 6381 1

 

3451:X 05 Jun 21:05:56.083 # +sdown master hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:56.083 # +odown master hadoopMaster2 127.0.0.1 6381 #quorum 1/1

3451:X 05 Jun 21:05:56.083 # +new-epoch 1

3451:X 05 Jun 21:05:56.083 # +try-failover master hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:56.086 # +vote-for-leader 3f020a35c9878a12d2b44904f570dc0d4015c2ba 1

3451:X 05 Jun 21:05:56.086 # +elected-leader master hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:56.086 # +failover-state-select-slave master hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:56.087 # +sdown master hadoopMaster 127.0.0.1 6381

3451:X 05 Jun 21:05:56.189 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:56.189 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster2  127.0.0.1 6381

3451:X 05 Jun 21:05:56.252 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster2  127.0.0.1 6381

3451:X 05 Jun 21:05:57.145 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ hadoopMaster2  127.0.0.1 6381

3451:X 05 Jun 21:05:57.145 # +failover-state-reconf-slaves master hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:57.234 * +slave-reconf-sent slave 127.0.0.1:6379 127.0.0.1 6379 @ hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:58.149 * +slave-reconf-inprog slave 127.0.0.1:6379 127.0.0.1 6379 @ hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:58.149 * +slave-reconf-done slave 127.0.0.1:6379 127.0.0.1 6379 @ hadoopMaster2  127.0.0.1 6381

3451:X 05 Jun 21:05:58.203 # +failover-end master hadoopMaster2 127.0.0.1 6381

3451:X 05 Jun 21:05:58.203 # +switch-master hadoopMaster2 127.0.0.1 6381 127.0.0.1 6380

3451:X 05 Jun 21:05:58.203 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ hadoopMaster2 127.0.0.1 6380

3451:X 05 Jun 21:05:58.203 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ hadoopMaster2 127.0.0.1 6380

如有什么理解错的地方，还希望大神指点，感谢！！！