在之前的文章中，我们介绍了Redis的哨兵机制，也介绍了为什么哨兵集群最少需要三个哨兵节点，下面来动手搭建一个最简哨兵集群，也就是三个节点的哨兵集群。

一.哨兵集群的配置文件解读

        哨兵配置文件在你安装的redis的文件夹根目录下就可以找到，名称为:sentinel.conf。一般而言，我们需要配置的参数不多，配置的最多的参数为以下几项：

bind 192.168.31.12

port 5000

dir /var/sentinal/5000

sentinel monitor mymaster 192.168.31.12 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

# sentinel auth-pass <master-name> <password>

哨兵常用配置解读

        一个哨兵节点是可以监控多个Redis集群的，在上面的展示中，这个哨兵节点监控了一个别名为mymaster的master-slaves的集群。如果你在这个哨兵的配置文件中同时配置了多份上面的配置的话，一个哨兵就可以同时监控多个master-slaves的集群。

二.部署经典的三节点哨兵集群

        关于哨兵节点为什么至少为三个，在上篇文章中已经详细的介绍了，关于quorum和majority这里也不再赘述了。

        首先，我们需要一个redis主从架构的集群，我这里使用的是一主二从这样的架构。

（1）创建哨兵配置文件的存放路径和哨兵的工作目录

mkdir -p /etc/sentinal

mkdir -p /var/sentinal/5000

（2）将redis安装目录下的sentinel.conf拷贝出来，改名5000.conf放入/etc/sentinal文件夹中，并将此操作和(1)中的操作在三台服务器中都进行，记得要更改bind 这个参数对应的服务器的ip。

（3）第二步进行完毕之后，我们就可以将哨兵运行起来了。

        首先在master节点所在的服务器命令行中输入redis-sentinel /ect/sentinal/5000.conf,哨兵正常运行的话，你可以看到如下图所示的输出：

哨兵启动成功

        我们分别在三台服务器上启动哨兵，你就可以在哨兵的日志中看到哨兵感知到master节点，slave节点，以及其他哨兵节点的启动。

哨兵感知到master,slave,以及其他哨兵

        哨兵之间是怎么感知到的呢？其实就是通过redis本身的pub/sub来实现的，即redis的消息发布和订阅channel消息系统和机制。我们可以通过下面几个指令来查看哨兵的状态：

sentinel master mymaster：查看当前master节点的状态和信息

sentinel slaves mymaster：查看当前master下的slave的状态和信息

sentinel sentinels mymaster:查看正在监控mymaster的哨兵的状态和信息

sentinel get-master-addr-by-name mymaster:得到mymaster的ip和端口号

三.容灾演练

（1）我们首先杀死master节点redis的进程，并删除/var/run/redis_6379.pid，接下来查看哨兵的日志：

首先使用ps -ef  | grep redis 查看redis的进程

然后使用 kill -9 port_num来杀死redis的进程

再将 /var/run/redis_6379.pid删除

kill master后的日志

其余哨兵的日志输出内容大致与它相同。

（2）配置文件更新了吗？我们一探究竟！

        我们首先查看哨兵配置文件中关于master节点的配置：

master节点的信息被更新

当哨兵运行起来之后，它的配置文件也会自动变化，比如：

sentinel leader-epoch mymaster 0

当我们初次将哨兵运行起来时这个参数为0，也就是版本号为0，当执行完一次故障转移之后，版本号发生了变化。

配置信息的版本号

哨兵配置文件最下方，在你将哨兵启动后也会发生变化：

哨兵配置文件的变化

我们也可以在命令行中查看哨兵的配置信息：

redis-cli 中查看master信息

那么还有的问题就是，经过主备切换之后，我们之前的数据有没有丢失呢？

获取之前的数据

我们也可以通过info指令来查看之前是slave，然后被提升为master节点的redis节点的信息：

现任master节点的信息

我们将刚刚杀死的redis进程重启，看看会发生什么变化：

降级之后的master节点信息

然后查看哨兵的日志信息：

原master节点作为slave连上

（3）原本的master节点在重启服务器之后能变回master吗？

        答案是否定的，现在的配置文件已经发生变化，重启后的master节点仍然是故障转移之后的master,故障转移是重启不可逆的。

（4）哨兵作为守护进程运行

        现在哨兵的运行是我们直接可以看到的，日志也是直接输出到控制台，要是服务器宕机了的话，我们连日志都没得看，下面我们会介绍两个参数，让哨兵作为守护进程运行，将日志输出到日志文件中：

daemonize yes

logfile /var/log/sentinel/5000/sentinel.log

别忘记使用：mkdir -p /var/log/sentinel/5000 将日志文件的路径创建好

这样哨兵就会以守护进程去运行，日志信息将输出到文件中。