哨兵机制核心作用

核心操作流程

哨兵的配置

启动命令： redis-server sentinel.conf --sentinel

# 配置文件在sentinel运行期间是会被动态修改的# sentinel如果重启时，就可以根据这个配置来恢复其之前所监控的redis集群的状态# 绑定IPbind 0.0.0.0# 默认yes，没指定密码或者指定IP的情况下，外网无法访问protected-mode no# 哨兵的端口，客户端通过这个端口来发现redisport 26380# 哨兵自己的IP，手动设定也可自动发现，用于与其他哨兵通信sentinel announce-ip# 临时文件夹dir /tmp# sentinel监控的master的名字叫做mymaster,地址为 60.205.209.106 6380,两个及以上哨兵认定为死亡，才认为是真的死亡sentinel monitor mymaster 60.205.209.106 6380 2# 发送心跳PING来确认master是否存活# 如果master在“一定时间范围”内不回应ping 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了sentinel down-after-milliseconds mymaster 1000# 如果在该时间（ms）内未能完成failover操作，则认为该failover失败sentinel failover-timeout mymaster 3000# 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长sentinel parallel-syncs mymaster 1

sentinel 通过info replication 发现redis主从信息

主观下线

单个哨兵自身认为redis实例已经不能提供服务

检测机制：哨兵向redis发送ping请求，+PONG\-LOADING\MASTERDOWN这三种情况视为正常，其他回复均视为无效。

对应配置文件的配置项：sentinel down-after-milliseconds mymaster 1000

客观下线

一定数量值的哨兵认为master已经下线。

检测机制：当哨兵主管认为master下线后，则会通过SENTINEL is-master-down-by-addr命令，询问其他哨兵是否认为master已经下线，如果达成共识（达到quornum个数），就会认为master节点客观下线，开始故障转移流程。

对应配置文件的配置项：sentinel monitor mymaster 192.168.0.105 6380 2

slave选举方案

节点状态：非 S_DOWN,O_DOWN，DISCONNECTED

判断规则：(down-after-milliseconds * 10) +milliseconds_since_master_is_in_SDOWN_stateSENTINEL slaves mymaster

优先级: redis.conf中的一个配置项： slave-priority 值越小，优先级越高

数据同步情况：Replication offset processed

最小的run id:run id 比较方案：字典顺序， ASCII码

主从切换的过程

针对即将成为master的slave节点，将其撤出主从集群

自动执行：slaveof NO ONE

针对其他slave节点，使它们成为新master的从属

自动执行：slaveof new_master_host new_master_port

哨兵如何通信的

1.哨兵之间的自动发现 2.哨兵之间通过命令进行通信 3.哨兵之间通过订阅发布进行通信

哨兵领导选举机制

基于Raft算法实现的选举机制，流程简述如下：

1. 拉票阶段：每个哨兵节点希望自己成为领导者；

2. sentinel节点收到拉票命令后，如果没有收到或同意过其他sentinel节点的请求，就同意该sentinel

节点的请求（每个sentinel只持有一个同意票数）；

3. 如果sentinel节点发现自己的票数已经超过一半的数值，那么它将成为领导者，去执行故障转移；

4. 投票结束后，如果超过failover-timeout的时间内，没进行实际的故障转移操作，则重新拉票选举。

注：以了解raft协议为主。https://raft.github.io/、http://thesecretlivesofdata.com/raft/

转载地址：http://gujdi.baihongyu.com/

你可能感兴趣的文章