Redis Sentinel基本架构
- 多个sentinel发现并确认master有问题
- 选举出一个sentinel作为领导
- 选出一个salve作为master
- 通知其余slave成为新的master的slave
- 通知客户端主从变化
- 等待master复活成为新的master的slave
安装与配置
- 配置开启主从节点
- 配置开启sentinel监控master节点
Redis主节点
启动redis-server redis-7000.conf
redis配置:
主节点:
1 | port 7000 |
从节点:
1 | port 7001 |
1 | port 7002 |
sentinel配置:
1 | port ${port} |
安装演示
配置redis
单机演示实际为能相互ping通的多台机器
1:创建master节点配置
2:创建7000,7001节点配置
3:查看主从状态
到此为止主从的配置搭建完毕了
配置sentinel
通过官方提供的配置模板导入sentinel配置
配置信息:
查看Sentinel监控状态:
到此我们可以发现Sentinel已经检测到了matser节点的主从信息,由于我们只启动一个Sentinel所以Sentinel发现的数目为1
再去看看redis-sentinel-26379.conf的变化:
发现他已经把7000的两个slave节点的信息配置自动写入到了配置文件中
生成另外两个Sentinel配置
查看sentinel状态
发现26380的Sentinel并没有发现其他节点
查看原因:
1 | cat /var/log/redis/26379.log |
我们发现三个节点的pid都是一样的,所以需要配置pid
编辑26379,26380,26381.conf 去掉配置文件自动生成的myid,并加入
1 | pidfile "/var/run/redis/redis-sentinel-26379.pid" |
状态已正常
go客户端
1 | package main |
执行以下命令,并模拟7000端口宕机
1 | go run client.go |
执行结果:
日志分析
查看7001.log
从日志中发现选举7002为master,执行redis-cli -p 7002 info replication
验证下
看看sentinel日志的变化
故障转移
三个定时任务
- 每10秒每个sentinel对master和slave执行info
- 发现slave节点
- 确定主从关系
- 每2秒每个sentinel通过master节点的channel节点交换信息(pub/sub)
- 通过__sentinel__和:hello频道交互
- 交互对节点的看法和自身的信息
- 每1秒每个Sentinel对其它Sentinel和Redis执行ping
- 失败判定依据,心跳检测
主观下线和客观下线
- 主观下线:每个sentinel节点对Redis节点失败的偏见
- 客观下线:所有sentinel节点对Redis节点失败达成共识(quorum:建议节点数/2+1)
领导者选举
- 原因:只有一个sentinel节点完成故障转移
- 选举:通过sentinel is-master-down-by-addr命令都希望成为领导者
- 每个主观下线的Sentinel节点向其他Sentinel节点发送命令,要求它设置为领导者
- 收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令,那么该同意将被拒绝
- 如果该Sentinel节点发现通过的票数已经超过Sentinel集合半数且超过quorum,那么它将成为领导者
- 如果此过程中有多个Sentinel节点成为领导者,那么将等待一段时间重新选举
故障转移
- 从slave节点选出一个”合适的”节点作为新的master节点
- 对上面的slave节点执行
slaveof no one
命令让其成为master节点 - 向剩余的slave节点发送命令,让他们成为新master节点的slave节点,复制规则和parallel-syncs参数有关
- 更新原来的master节点并配置为slave,并保持对其”关注”,当其恢复后,命令他去复制新的master节点
选择”合适的”slave节点
- 选择slave-priority(slave节点优先级)最高的slave节点。如果存在则返回,不存在则继续
- 选择复制偏移量最大的slave节点(复制的最完整)如果存在则返回,不存在则继续
- 选择runid最小的slave节点