是什么
- 吹哨人巡查监控后台master主机是否故障 如果故障了根据投票数自动将某个从库转换为主库 继续对外服务
- 无人值守运维
能干嘛
- 主从监控
- 监控主从redis库是否运行正常
- 消息通知
- 哨兵可以将故障转移的结果发送给客户端
- 故障转移
- 如果master异常 则会进行主从转换 将其中一个slave作为新的master
- 配置中心
- 客户端通过连接哨兵来获得当前redis服务的主节点地址
案例
- 前提 三个哨兵 一个master 两个slave
- 步骤
-
/myredis目录下新建或者拷贝sentinel.conf文件名字绝对不能错
-
先看看/opt目录下默认的sentinel.conf文件
-
参数说明
- bind 服务监听地址 用于客户端 连接 默认本机地址
- daemonize 是否以后台daemon方式运行
- port端口
- logfile 日志文件路径
- pidfile pid文件路径
- dir 工作目录
- sentinel monitor
- 设置要监控的master服务器 quorum表示最少要有几个哨兵认可客观先下线 同意故障迁移的法定票数
- sentinel monitor
- master设施了密码 连接master 服务的密码
- sentinel down-after-milliseconds
- 指定多少毫米之后主节点没有应答哨兵 此时哨兵主观认为主节点下线
- sentinel parallel-syncs :
- 表示允许并行同步的slave个数 当master挂了后 哨兵会选出新的master 此时剩余的slave会向新的master发起同步数据
-
sentnel文件配置
-
运行原理
- 当一个主从配置 中的master失效之后 sentinel 可以选举出一个新的master用于自动接替原master的工作 主从配置中的其他redis服务器自动指向新的master同步数据 一般sentinel采取奇数台 防止某一台sentinel无法连接到master导致误切换
- 运行流程
- 三个哨兵监控 一主二从 正常运行
- sdown 主库 主观下线
- 单个sentinel自己主观上检测到关于master的状态 从sentinel的就角度来看 如果ping心跳包 后 在一定时间内没有收到合法的回复 就到达了sdown的条件
- sentinenl配置文件中的down-after-millseconds设置了判断主观下线的时间长度
- sentinel down-after-millseconds 表示master被当前sentinel实例认定为失效的间隔时间 这个配置其实就是主观下线的一个依据
- master超过sentinel down-after-millseconds这个时间没有给sentinel返回有效信息 这认定该master主观下线 也就是超过sentinel down-after-millseconds这个时间redis-server就会认为进入到sdown状态
- odown 主库客观下线
- odown需要一定数量的sentinel 多个哨兵达成一致意见才能让认为一个master客观上已经宕机
- 进行投票
- quorum这个参数是进行客观下线的一个依据,法定人数/法定票数
- 进行投票
- odown需要一定数量的sentinel 多个哨兵达成一致意见才能让认为一个master客观上已经宕机
意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候,某个sentinel节点可能因为自身网络原因导致无法连接master,而此时master并没有出现故障,所以这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,这就保证了公平性和高可用。
- 选举出哨兵的领导者
- 当主节点被判断客观下线以后 各个哨兵节点就会协商选举一个领导者哨兵节点 并由该节点进行故障迁移
- 选举哨兵的算法 raft算法
- 由领导者开始推动故障切换流程并选出一个新的master
- 选出性的master
- 某个slave被选中成为新的slave
- 选出规则 剩余slave节点健康的前提下 redis.conf文件中 优先级slave-priority 或 replica-priotity最高的从节点
- 复制偏移量的位置offset最大的节点
- 主从复制的时候有延迟未必就是完全备份
- 最小run id的节点 字典顺序 ascII
- 某个slave被选中成为新的slave
- 选出的从节点成为主节点
- 通过salveof no one 选出的从节点成为主节点 并通过salveof 命令让其他节点成为从节点
- sentinel leader 将选举出的master 执行salveof no one 操作 将其提升为master
- sentinel leader 向其他slave发送命令 让剩余的 节点slave 成为新master节点的salve
- 如果旧master上线
- 也会成为新master节点的salve节点
- sentinel leader 会让原来master 降级为slave恢复正常工作
- 选出性的master
建议
- 哨兵节点数量 应为多个 哨兵本身应该集群 保证高可用
- 哨兵数量应该 为奇数
- 各个哨兵的配置应该一致
- 哨兵+主从复制并不能保证数据的零丢失