巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,继续对外服务。
作用
- 主从监控:监控主从redis库运行是否正常
- 消息通知:哨兵可以将故障转移的结果发送给客户端
- 故障转移:如果master异常,则会进行主从切换,将其中一个slave作为新master
- 配置中心:客户端通过连接哨兵来获得当前redis服务的主节点地址
示例
-
在sentinel.conf文件中,使用如下命令设置要监控的master服务器,quorum表示确认客观下线的最少的哨兵数量
sentinel monitor <master-name> <ip> <redis-port> <quorum>
使用如下命令连接master服务的密码
sentinel auth-pass <master-name> <password>
其他配置
bash
sentinel down-after-milliseconds <master-name> <milliseconds>
指定多少毫秒之后,主节点没有应答哨兵,此时哨兵主观上认为主节点下线
sentinel parallel-syncs <master-name> <nums>:
表示允许并行同步的slave个数,当Master挂了后,哨兵会选出新的Master,此时,剩余的slave会向新的master发起同步数据
sentinel failover-timeout <master-name> <milliseconds>:
故障转移的超时时间,进行故障转移时,如果超过设置的毫秒,表示故障转移失败
sentinel notification-script <master-name> <script-path> :
配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script <master-name> <script-path>:
客户端重新配置主节点参数脚本
- 启动哨兵
查看sentinel.log,哨兵启动成功
- 将主机shutdown模拟主机故障
此时从机get数据时会失去连接,再次get数据重新发起连接,哨兵会从从机中选取新的master
查看主机的sentinel.log,选取了ip为192.168.229.102的从机作为新的master
- 重新启动原来的主机,可以看到原主机从master变为slave,新的master并不会改变
- sdown:主观下线,单个sentinel自己主观上检测到的关于master的状态在发送PING心跳后一定时间内(默认30s)没有收到合法回复
- odown:客观下线,多个sentinel达成一致意见认为一个master客观上已经宕机
- 当主节点被判断客观下线后,各个哨兵节点会进行协商,先选举出一个领导者哨兵,并由该哨兵进行故障迁移
- 哨兵选取新的master时,优先选取原master的直接slave,如果直接slave不可用,才会去寻找slave的slave
领导者哨兵选取算法------Raft算法
基本思路是先到先得:即在一轮选举中,哨兵A向B发送成为领导者的申请,如果B没有同意过其他哨兵,则会同意A成为领导者
新master选取机制
- 选出新的master,在健康的slave中,通过优先级(redis.conf中slave-priority或replica-priority,数字越小优先级越高)、复制偏移量、id三层比较选取新的master
-
重新认定master,领导者哨兵会对选举出的新master执行slaveof no one;对其他slave发送命令使剩余slave称为新master的slave
-
原master成为新master的slave,领导者哨兵会让原master降级为slave并恢复正常工作