Redis-哨兵监控(sentinel)

是什么

Docs

吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务

作用:无人值守运维

能干嘛

1.主从监控

监控主从redis的库是否运行正常

2.消息通知

哨兵可以将故障转移的结果发送给客户端

3.故障转移

如果Master异常，则会进行主从切换将其中一个Slave作为新Master

4.配置中心

客户端通过连接哨兵来获得当前Redis服务的主节点地址

案例演示(实战步骤)

1.Redis sentinel架构,前提说明

2.案例步骤

1./myredis目录下新建或者拷贝sentinel.conf文件，名字绝不能错

把/opt/redis-版本号下的最原始的sentinel.conf文件拷贝进/myredis下

2.conf配置文件的重点参数说明

1.bind

服务监听地址，用于客户端连接，默认本机地址

2.daemonize

是否以后台daemon方式运行

3.protected-mode

安全保护模式

4.port

端口

5.logfile

日志文件路径

6.pidfile

pid文件路径

7.dir

工作目录

8.sentinel monitor <master-name> <ip> <redis-port> <quorum>

设置要监控的master服务器

quorum:表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。

为什么用quorum:

我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

9.sentiel auth-pass <master-name> <password>

master设置了密码，连接master服务的密码

10.其他        

3.本次案例哨兵sentinel.conf的通用配置

由于机器硬件关系，我们的3个哨兵都同时配置进192.168.111.169同一台机器

在/myredis下配置:

sentinel26379:

4.先启动一主二从3个redis实例,测试正常的主从复制

1.架构说明

2.配置redis一主二从的conf文件

6379:(也要配置6379的masterauth,因为当6379从主机下位后成为从机,要连接新主机)

3.3台不同的虚拟机实例，启动三部真实机器实例并连接

5.启动三个哨兵,完成监控

6.启动三个哨兵后再测试一次主从复制

7.原有的master挂了

1.我们自己手动关闭6379服务器,模拟master挂了

2.问题思考

两台从机上的数据是否ok-->ok的,但是因为要内部选举,所以会error一段时间

是否会从剩下的两台从机上选出新的master-->会

之前down的主机重新启动回来,谁将是新老大,会不会双master冲突-->不会,通过日志,我们发现6379会彻底变成slave

查看sentinel26379.log文件

3.答案揭晓

数据是ok的,但是两个小问题,一种是连接断开,一种是broken pipe

8.对比配置文件

6379的配置文件;

结论:

sentinel会修改redis数据库的conf文件

3.其他备注

哨兵只是监控,没有业务压力

生产都是不同机房不同服务器，很少出现3个哨兵全挂掉的情况

哨兵可以同时监控多个master,一行一个

哨兵运行流程和选举原理

当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换

运行流程,故障切换

三个哨兵监控一主二从,正常运行中

主观下线SDown

SDOWN(主观不可用)是单个sentinel自己主观止检测到的关于master的状态，从sentinel的角度来看如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度

 ODown客观下线

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉

quorum

选举出领导者哨兵(哨兵中选出兵王)leader

投票完以后,三个哨兵选出一个leader.由leader来执行接下来的更换master等操作

当主节点被判断客观下线以后，各个哨兵节点会进行协商先选举出一个领导者哨兵节点(兵王)并由该领导者节点也即被选举出的兵王进行failover(故障迁移)

看日志可以看到选取leader的过程

兵王如何选举出来的?Raft算法

判断主观下线的哨兵节点向其他哨兵节点发送master宕机，如果超过半数的哨兵节点判断master节点进入客观下线的状态，那么率先判断进入主观下线的哨兵将成为领头sentinel

由兵王开始推动故障切换流程并选举出一个新的master(新master选举的算法)

三步骤

新王登基

某个slave被选中成为新master

选出新master的规则(在slave节点健康的前提下):

群臣俯首

首先被选为新master的执行slaveof no one命令让自己从原来的从节点变为主节点,然后再通过slaveof 命令让其他节点成为从节点

旧主拜服

总结

上述的failover操作均由sentinel自己独自完成，完全无需人工干预

哨兵使用建议

并不能保证数据零丢失,引出集群