Redis哨兵
吹哨人巡查监控后台master主机是否故障,如果故障了就会根据投票数自动将某一个从库转换为新主库继续对外服务
作用:1.监控redis运行状态,包括master和slave 2.当msater宕机能自动将slave切换为新的master
capacity:
主从监控:监控主从redis库运行是否正常
消息通知:哨兵可以将故障转移的结果发送给客户端
故障转移:如果master异常,则会进行主从切换,将其中一个Slave作为新的Master
配置中心:客户端通过连接哨兵来获取当前Redis服务的主节点地址
哨兵和Redis都是独立的机器,二者使用的配置文件也不同redis使用的是redis.conf,哨兵使用的是sentinel.conf
1.sentinel.conf配置文件
要想使用哨兵进行监控就需要在sentinel.conf配置文件中配置sentinel配置项
sentinel monitor <master-name> <ip> <redis-port> <qurom>
参数含义:
master-name 顾名思义就是要监控的主机名称
ip 就是要监控的主机端口
redis-port 就是要监控的机器的redis端口号
qurom 是投票数,是确认客观下线的最少的哨兵数量
我们知道,网络是会波动的,并不可靠,有时sentinel会因为网络堵塞而误以为master挂了,因此为了判断的合理性哨兵一般会使用集群,即在sentinel集群的环境下需要各个sentinel之间进行沟通来确认某个master是否是真的挂了,qurom这个参数就是进行客观下线的一个依据,意思就是至少有几个哨兵认为master挂了才会对这个master主机进行下线以及故障转移。因为有时候某个sentinel可能因为自身的网络原因,导致无法连接master,而此时master并没有出现故障,所以这就需要多个sentinel认为master有问题,才可进行下一步操作,这就保证了公平性和高可用
sentinel auth-pass <master-name> <password> master设置了密码,连接master服务的密码
sentinel down-after-millseconds <master-name> <millseconds> 指定多少毫秒之后,主节点没有应答哨兵,此时哨兵就认为主节点下线
sentinel parallel-syncs <master-name> <nums> 表示允许并行同步的slave的个数,当Master挂了之后,哨兵会选出新的Master,此时剩余的slave会像新的master发起同步数据
sentinel failover-timeout <master-name> <millseconds> 故障转移的超时时间,进行故障转移时,如果超过设置的毫秒,表示故障转移失败
sentinel notification-script <master-name> <script-path> 配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script <master-name> <script-path> 客户端重新配置主节点参数脚本
2.哨兵的运行流程和选举原理
当主从关系中的主机因为特殊原因下线之后哨兵进行投票选举,从slave中选出一个作为master,其他的slave与新选出的master形成新的主从关系,下线的主机在重新上线之后不会再次成为主机而是变为新master的slave。
主观下线:单个sentinel自己主观上检测到master的状态,从sentinel的角度来看,如果发送了PING心跳之后,在一定的时间内没有得到答复,就达到了SDOWN的条件。可以再配置文件中配置down-after-millseconds 设置判断主观下线的时间长度(默认是30s)
客观下线:ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经down掉。
当master确认ODOWN是哨兵中就会选举出一个哨兵Leader来进行故障迁移
哨兵Leader的选举算法:Raft算法,监视该主节点的哨兵都有可能被选举为哨兵Leader。Raft算法的基本思路是先到先得,即在每一轮选举中,哨兵A向发送成为Leader的申请,如果B没有同意过其他的哨兵,则会同意A成为Leader
故障转移流程:分三步,由sentinel独立完成无需人工干预,故可称为无人值守安装机制
1.某个slave被选为新Master
选出新master的规则(在剩余slave节点健康的情况下)
先比对剩余slave的priority谁高谁为新master
一样就比对replication offset 复制偏移量一样是谁高选谁为新master
如果还一样就看run ID 最小的为new master
2.被选出来的新master会被sentinel执行slaveof no one 来成为新的主节点,并通过发送slaveof 命令使得其他的slave节点成为其从节点
3.之前已经下线的老master被设置为新master的从节点,当老master上线之后就会成为新master的slave
3.哨兵的使用建议
1.哨兵节点的个数应该有多个,哨兵本身应该为集群,保证高可用
2.哨兵节点的数量应该为奇数
3.各个哨兵节点的配置应该一致
4.如果哨兵节点部署在Docker容器里面,尤其要注意端口的正确映射
5.哨兵集群+主从复制,并不能保证数据0丢失,最好使用集群