Redis(8):最简哨兵集群的搭建

        在之前的文章中,我们介绍了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 将日志文件的路径创建好

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

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容