Redis学习笔记（12）- Redis的主从配置和哨兵的使用

1、前言

  在《Windows环境Redis的主从配置》这篇内容中，尝试了在Windows环境下搭建了一个简单的主从配置的Redis环境。在CentOS中搭建Redis的主从配置和Windows环境下基本一样，这一篇的内容主要是当master节点有密码时，从节点配置需要添加的参数和哨兵在主从中的使用。

2、番外篇

  Redis因为一些政治原因，被迫做出改动的消息很早之前就有耳闻，但是因为当时使用Redis的频率也不高，所以当时没有太过在意。原因是：很多开发者认为Redis的作者在主从模式（(master-slave）的命名和文档描述中使用了带有歧视色彩的词语（slave在英文中有奴隶的意思），所以这些开发者希望 Redis 作者能修改 Redis 中 master-slave 架构的描述。因为这件事，当时在社区引发了激烈的讨论，最后Redis作者，迫于压力开始进行了分步骤的修改，所以就出现了replicaof 替换 slaveof的事情（slaveof还保留使用）。
  在之前做过一些简单的主从复制的配置，一直在使用slaveof配置或slaveof命令，这次详细学习Redis的时候，发现在redis.conf文档中，查找不到slaveof关键词了，替代出现的是replicaof，两个命令功能一样。文档中描述已经换成了，如下所示：

3、主从模式的快速搭建

  在《Windows环境Redis的主从配置》这篇内容中，已经尝试了在Windows环境下搭建主从模式的Redis，在Centos环境下搭建过程基本一样，这里因为一些上面提到的“特殊”原因，开始使用replicaof进行配置了。

1. 准备工作
   
   在/usr/local/redis/master-slave目录（这个目录随意定义）下，准备了六个目录，每个目录其实都是一份编译并安装好后的Redis根目录，Redis的编译和安装过程请参考《CentOS7安装Redis，并设置开机启动》。根据名字我们可以知道：

• redis-master用来做Redis主从模式中的主节点，
• redis-slave1、redis-slave2用来做主从模式下从节点，
• redis-sentinel1、redis-sentinel2、redis-sentinel3三个目录就是用来做Redis哨兵的，Redis的哨兵其实就是一种特殊的Redis实例。

注：在实际的工作过程中，如果有哨兵的存在，因为Redis实例的掉线，主从模式中的主从关系会自动发生改变的。

2. 主从模式的配置
   修改Redis主从模式中主从节点的redis.conf文件，基本一样，如下所示：

#设置当前Redis的实例的IP
bind 192.168.0.182
#设置当前Redis实例的端口号，默认是：6379
port 7010
#开启Redis的安全模式
protected-mode yes
#设置运行后台运行
daemonize yes
#设置Redis实例的密码
requirepass "xxx"
#当节点作为从节点时，需要配置主节点的密码
masterauth "xxx"
#配置redis日志的名称
logfile "redis.log"
#配置pid文件
pidfile "/var/run/redis_7010.pid"
#仅从节点需要添加该配置，在切换主从关系时，该配置可能会自动改变，分别表示主节点的ip和port
replicaof 192.168.0.182 7010

如果主节点开启了安全模式，但是从节点没有配置masterauth 时，会出现如下报错：《MASTER aborted replication with an error: NOAUTH Authentication required.》

3. 依次启动redis实例
   首先启动主节点实例。命令如下（使用的相对路径，所以需要注意当前所在目录）：
   
   只启动了主节点后，可以查看主节点中从节点的相关信息，如下所示：
   
   然后分别启动两个子节点，命令如下：
   
   启动了从节点后，可以查看现在的主节点的主从模式中的关系：
   
4. 简单测试
   首先在主节点设置一个key=t1的值，然后分别链接从节点，通过get t1，也可以获取到主节点设置的值。如下所示：
   

4、Redis哨兵

  Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。下面是Redis官方文档对于哨兵功能的描述：

• 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
• 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

5、启用Redis哨兵

1. 首先修改sentinel.conf的配置
   修改Redis哨兵的sentinel.conf配置文件，三个哨兵节点都一样，如下所示：

#哨兵绑定的IP（在一台服务器上，所以三个哨兵的IP一样）
bind 192.168.0.182
#哨兵绑定的接口（这里分别使用了27010、27011、27012）
port 27011
#开启安全模式
protected-mode yes
#设置运行后台运行
daemonize yes
#设置pid文件
pidfile /var/run/redis-sentinel_7011.pid
#设置日志文件
logfile "sentinel.log"
#设置哨兵节点监控主节点的名称、ip和port，最后的数字与主节点的故障判定有关：至少需要n个哨兵节点同意，才能判定主节点故障并进行故障转移。
sentinel monitor mymaster 192.168.0.182 7010 2
#设置主节点的密码
sentinel auth-pass mymaster 123456

2. 启动哨兵
   首先通过命令启动一个哨兵，如下所示：

src/redis-sentinel sentinel.conf 

然后通过redis-cli访问连接哨兵，命令入下：

src/redis-cli -h 192.168.0.182 -p 27010 -a 123456

最后，查看哨兵的信息，命令如下：

info sentinel

具体过程如下图所示：

通过info sentinel命令，我们可以知道，当前主节点的名称为mymaster，ip为192.168.0.182，端口号为7010，有两个从节点，一个哨兵。
然后再启动另外两个哨兵，然后查看哨兵信息如下是：

通过上图，我们发现，哨兵已经变成了3个。

6、验证Redis哨兵的故障转移功能

  通过前面的操作，当前的环境：7010对应主节点，7011、7012对应从节点，27010、27011、27012对应三个哨兵节点。如下所示：


  下面开始演示故障转移个功能，首先，查看当前实例对应的pid，命令如下：

ps -ef | grep redis

  然后通过kill命令，关掉主节点对应的实例，命令如下：

kill -9 30073

最后，在哨兵节点中，查看哨兵信息，如下所示：

info sentinel

根据截图可以看到，主节点已经切换成7011这个实例，但是显示从节点还是2个（原主节点上线后，会自动作为一个从节点存在）。需要注意：如果kill掉原主节点后，直接通过info sentinel命令查看，有可能会发现主节点地址不变，这是因为切换主节点需要时间。

  然后，重新启动原来的主节点，等待一段时间后，通过下面命令查看redis.conf配置，会发现原主节点redis.conf配置文件中，增加了一条replicaof 192.168.0.182 7011。如果查看新的主节点中的redis.conf配置文件，会发现原来的replicaof 192.168.0.182 7010配置以及被删除了；另外一个从节点中原来的replicaof 192.168.0.182 7010配置变成了replicaof 192.168.0.182 7011。所以在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。

cat redis.log 

哨兵的配置文件也会发生变化，如下所示：

参考：
1、《太无奈！Redis 作者被迫修改 master-slave 架构的描述》
2、《深入学习Redis（4）：哨兵》