1 sdown和odown转换机制
两种失败状态
1.1 概念
sdown主观宕机
一个哨兵自己觉得一个master宕机
odown客观宕机
quorum数量的哨兵都觉得一个master宕机
1.2 达成条件
sdown
一个哨兵ping一个master,超过is-master-down-after-milliseconds
odown
一个哨兵在指定时间内,收到了quorum指定数量的其他哨兵也认为那个master是sdown了,那么就认为是odown
2 自动发现机制
通过Redis的pub/sub实现哨兵互相之间的发现,每个哨兵都会往__sentinel__:hello这个channel发一个消息,此时所有其他哨兵都可消费到该消息,于是感知到其他哨兵的存在.
每隔2s,哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hellochannel里发一个消息,内容为自己的host、ip和runid还有对该master的监控配置
每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel,然后去感知到同样在监听这个master+slaves的其他哨兵的存在
每个哨兵还会跟其他哨兵交换对master的监控配置,互相进行监控配置的同步
3 slave配置的自动纠正
哨兵会负责自动纠正slave的一些配置,比如
slave要成为潜在的master候选人,哨兵会确保slave复制现有master的数据
slave连接到了一个错误的master上,比如故障转移之后,那么哨兵会确保它们连接至正确的master
4 slave = master选举算法
若一个master被认为odown了,而且majority数量的哨兵都允许了主备切换,那么某个哨兵就会执行主备切换操作,此时首先要选举一个slave,会考虑slave的一些信息
跟master断开连接的时长
slave优先级
复制offset
run id
若一个slave跟master断开连接的时间已经超过down-after-milliseconds的10倍,外加master的宕机时长,那么slave就会被认为不适合选举为master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
接下来会对slave进行排序
按照slave优先级进行排序,slave priority越低,优先级就越高
如果slave priority相同,那么看replica offset,哪个slave复制了越多的数据,offset越靠后,优先级就越高
如果上面两个条件都相同,那么选择一个run id比较小的那个slave
5 quorum和majority
每次一个哨兵要做主备切换,首先需要quorum数量的哨兵认为odown,然后选举出一个哨兵来做切换
该哨兵还得得到majority个哨兵的授权,才能正式执行切换
若quorum majority
比如5个哨兵,majority就是3,quorum设置为2,那么就3个哨兵授权就可以执行切换
若quorum = majority
那么必须quorum数量的哨兵都授权,比如5个哨兵,quorum是5,那么必须5个哨兵都同意授权,才能执行切换
6 configuration epoch
哨兵会监控一套Redis master+slave,并有相应的监控配置
执行切换的哨兵,会从要切换到的新master(salve = master)那里得到一个configuration epoch,这就是一个version号,每次切换的version号都必须是唯一的
如果第一个选举出的哨兵切换失败,那么其他哨兵,会等待failover-timeout时间,然后接替继续执行切换,此时会重新获取一个新的configuration epoch,作为新的version号
7 configuraiton传播
哨兵完成切换之后,会在自己本地更新生成最新的master配置,然后同步给其他哨兵
这里是通过pub/sub机制传递的
到了这里,之前提到的version号就很重要了,因为各种消息都是通过一个channel去发布和监听的,所以一个哨兵完成一次新的切换之后,新的master配置是跟着新的version号的
其他的哨兵也都是根据版本号的大小来更新自己的master配置的