Redis哨兵(非集群 Rrdis 的高可用性 )
1. 什么是哨兵
吹哨人巡查监控后台 master 主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,继续对外服务
Redis哨兵在不使用Redis集群时为Redis提供高可用性
2. 作用
无人值守运维
3. 哨兵作为分布式系统
Redis Sentinel是一个分布式系统:
Sentinel 本身设计为在有多个 Sentinel 进程协同的配置中运行。让多个 Sentinel 流程协作的优势如下:
- 当多个哨兵同意认为主节点不再可用时,将执行故障检测。这降低了误报的可能性。
- 即使不是所有的 Sentinel 进程都在工作,Sentinel 也能正常工作,使系统能够抵御故障。毕竟,拥有一个本身就是单点故障的故障转移系统没有任何意义。
哨兵、Redis 实例(主实例和副本实例)和客户端的总和 连接到Sentinel和Redis,也是一个更大的分布式系统,具有 特定属性。在本文档中,概念将逐步介绍 从基本信息开始,了解基本信息 Sentinel 的属性,到更复杂的信息(可选)在 以了解哨兵究竟是如何工作的。
4. 使用Redis哨兵
sentinel.conf文件中的重要配置
==
==
==
==
==
5. Running Sentinel
redis-sentinel sentinel23679.conf --sentinel
//启动配置文件为sentinel23679的哨兵
6. 手动模拟主机下线
在6379输入: shutdown
我们发现在第一时间,在6380端口get key时
Error: Server closed the connection
但又过了5s左右,数据就恢复了,get key 能拿到值
同时发现,6381成为了主机(6379挂掉前是从机),6380还是从机
我们来看以下哨兵配置文件 sentinel26370.conf:
我们同时发现,6379也称为6381的小弟,即使回来也是从机身份
了解一下Broken Pipe
注意事项
6379的配置文件发生变化
6381的配置文件发生变化
首先会执行slaveof no one
所以说6380配置文件也会发生改变
==
==
可以同时监控多个master,一个一行
7. 哨兵运行流程 和 选举原理
SDown主观下线
Sdown是单个sentinel自己主观上检测到的关于master的状态,从sentinel的角度来看,如果发送了PING心跳后,在一定时间内没有收到合法的回复,就达到了SDOWN的条件
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长短
ODown客观下线
ODown需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经宕掉
选举出领导者哨兵
咋选出来的?
由兵王开始推动故障切换流程并选出一个新的master
选举master的选举算法
- 先看权限
- 再看复制偏移量,谁大选谁
- 否则就看谁运行ID小选谁