Redis-哨兵
哨兵sentinel
吹哨人巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库换成新主库;
投票数写多少:?
作用:无人值守运维
监控redis运行状态,包括master和slave
当master down 机,能自动将slave切换成新master
能干什么
主从监控
监控主从redis库运行是否正常
消息通知
哨兵可以将故障转移的结果发送给客户端
故障转移
如果master异常,则会进行主从切换,将其中一个slave作为新的Master
配置中心
客户端通过连接哨兵来获得当前redis服务的主节点
实战
重点参数项说明
1 | sentinel monitor <master-name> <ip> <redis-port> <quorum> |
设置要监控的master服务器
quorum表示最少有几个哨兵 认可客观下线,同意故障迁移的法定票数
quorum这个参数是进行客观下线的一个依据,意思是至少有quorum个sentinel认为这个master有故障,才会对这个master进行下线以及故障转移.因为有的时候,某个sentinel节点可能因为自身网络的原因,无法连接master,而此时master并没有出现故障,所以这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,就保证了公平性和高可用.
1 | sentinel auth-pass <master-name> <password> |
master 设置了密码,连接master服务的密码
运行流程和选举原理
当一个主从配置中的master失效之后,sentinel可以选举出一个新的master用于自动接替原master的工作,主从配置中的其他redis服务器自动指向新的master同步数据.一般建议sentinel采用奇数台
运行流程,故障切换
三个哨兵监控一主二从,正常运行中……
SDown主观下线(Subjectively Down)
- SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于master的状态,从sentinel的角度来看,如果发送了ping心跳之后,在一定的时间里面没有收到合法的回复,就达到了SDOWN的条件.
- sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
ODOWN客观下线(Objectively down)
ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经宕了
选举出领导者哨兵(哨兵中选出兵王)leader
当主节点被判断客观下线以后,哥哥哨兵节点会协商,先选举出一个**==领导者哨兵节点==** 并由该领导者节点,也即被选举出的leader进行failover(故障迁移)
哨兵leader如何选举的 Raft算法
基本思路:先到先得 ,
在一轮选举中,哨兵A向B发送成为领导者的申请,如果B没有同意过其他哨兵,就会同意A成为领导者
由leader开始推动故障切换流程并选择一个新的master
某一个slave被选中成为一个新的master,规则如下:
由于存在网络抖动,不见得每个slave都会有效的得到master的信息,replication 谁复制的多就选谁
执行slaveof no one命令让选出来的从节点成为新的主节点,并通过slaveof命令让其他节点成为其从节点
Sentinel leader会对选举出的新master执行slaveof no one 操作,将其提升为master节点
sentinel leader向其他slave发送命令,让剩余的slave成为新的master节点的slave
哨兵使用建议
- 哨兵系欸但的数量应该为多个,哨兵本身应该集群,保证高可用
- 哨兵节点的数量应该是奇数
- 各个哨兵节点的配置应该是一致的.最好硬件一样
- 如果哨兵节点部署在Docker等容器里面,尤其是注意端口的正确映射
- 哨兵集群+主从复制,并不能保证数据的零丢失