Redis7之哨兵(九)
9.1介绍
-
哨兵巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,继续对外服务,俗称无人值守运维
-
作用
- 监控redis运行状态,包括master和slave
- 当master down机,能自动将slave切换成新master
-
哨兵的四个功能
- 主从监控
- 监控主从redis库运行是否正常
- 消息通知
- 哨兵可以将故障转移的结果发送到客户端
- 故障转移
- 如果master异常,则会进行主从切换,将其中一个slave作为新master
- 配置中心
- 客户端通过连接哨兵来获得当前Redis服务的主节点地址
- 主从监控
9.2 基本操作
Redis Sentinel架构
- 3个哨兵
- 自动监控和维护集群,不存放数据,只是监控
- 1主2从
- 用于数据读取和存放
步骤
注意: 由于虚拟机运行内存问题,将哨兵放在一台机器上,真正部署项目时要分开
-
在 /myredis 目录新建或者拷贝 sentinel.conf
-
先看看redis解压目录下默认的sentinel.conf文件的内容
-
哨兵sentinel文件参数(先导)
- bind 服务监听地址,用于客户端连接
- daemonize 是否以后台daemon方式运行
- protected-mode 安全保护模式
- port 端口
- logfile 日志文件路径
- pidfile pid日志路径
- dir 工作目录
- sentiel monitor
- 设置要监控的master
- quorm 表示最少有几个哨兵认可客观下线,同意故障迁移的法定票数
- 网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了,quorum这个参数是进行客观下线的一个依据,意思是至少有quorum个sentinel认为这个master有故障,才会对这个master进行下线以及故障转移。因为有的时候,某个sentinel节点可能因为自身网络原因,导致无法连接master,而此时master并没有出现故障,所以,这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,这就保证了公平性和高可用。
- sentiel auth-pass 通过密码连接master
-
哨兵sentinel文件配置
-
sentinel26379.conf
-
sentinel26380.conf
- sentienl26381.conf
-
-
先启动一主二从
-
按照上章配置的一主二从基础上,需要对主机redis6379.conf进行更改
-
-
6379后续可能会变成从机,需要设置访问新主机的密码, 请设置masterauth项访问密码为123456
-
-
启动一主二从
-
6379.conf redis-server /myredis/redis6379.conf redis-cli -a 123456 6380.conf redis-server /myredis/redis6380.conf redis-cli -a 123456 -p 6380 6381.conf redis-server /myredis/redis6381.conf redis-cli -a 123456 -p 6381
-
-
-
启动哨兵
-
redis-sentinel sentinel26379.conf --sentinel redis-sentinel sentinel26380.conf --sentinel redis-sentinel sentinel26381.conf --sentinel
-
-
-
关闭6379服务器,模仿master挂了
- 两台从机的数据不会丢失
- 会从其他两台从机选出一个新的master
- 挂掉的master重连回来,直接变成新master的从机
注意:
- 本文中的 sentinel26379.conf、sentinel26380.conf、sentinel26381.conf会在运行中进行动态更改
- 在master-slave切换中,会自动多一行slaveof的配置
哨兵运行流程和选举原理
当一个主从配置中的master失效之后,sentinel可以选举出一个新的master,用于接替原master的工作,主从配置中其他redis服务器自动指向新的master同步数据。一般建议sentinel采用奇数台,防止某一台sentinel无法连接到master导致误切换、
-
SDOWN主观下线
-
SDOWN 是单个sentinel 自己主观上检测到的关于master的状态,从sentinel的角度来看,如果发送了PING心跳后,在一定时间内没有收到合法的回复,就达到了SDOWN的条件
-
sentinel配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度
-
-
ODOWN客观下线
- ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经宕机
- ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经宕机
-
选举出领导者哨兵
-
当主节点被判断客观下线以后,各个哨兵节点会进行协商,县选举出一个领导者哨兵节点并由该领导者节点进行failover(故障迁移)
-
Raft算法 选出领导者节点
-
-
由领导者节点开始推动故障切换并选出一个新master
- 新主登基
- 某个slave 备选成为新 master
- 群臣俯首
- 一朝天子一朝臣,重新认老大
- 旧主拜服
- 老master回来也得怂
- 新主登基
-
以上的failover都是sentinel自己独立完成,完全无需人工干预
使用建议
- 哨兵节点的数量应为多个,哨兵本身应该集群,保证高可用
- 哨兵节点的数量应该是奇数个
- 各个哨兵节点的配置应该一致
- 如果哨兵节点部署在Docker等容器里,要注意端口的正确映射
- 哨兵集群+主从复制,并不能保证数据零丢失