Redis7--基础篇7(哨兵sentinel)

发布于:2023-12-07 ⋅ 阅读:(61) ⋅ 点赞:(0)

1. 关于哨兵的介绍

1、监控redis运行状态,包括master和slave(主从监控)
2、哨兵可以将故障转移的结果发送给客户端(消息通知)
3、当master down机,能自动将slave切换成新master(故障转移)
4、客户端通过连接哨兵来获得当前Redis服务的主节点地址(配置中心)
在这里插入图片描述
吹哨人巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,继续对外服务,俗称无人值守。

2. 案例演示

2.1 Redis Sentinel 架构说明

三个哨兵,自动监控和维护集群,不存放数据,只是吹哨人。
一主二从,用于读取和存放数据。
在这里插入图片描述
在这里插入图片描述

2.2 配置文件

  • 将配置文件sentinel.conf 拷贝到与redis7.conf同一个目录,方便管理配置文件
  • bind 服务监听地址,用于客户端连接,默认本机网卡地址。
  • daemonize 是否以后台daemon方式运行
  • prot 端口
  • logfile 日志文件路径
  • pidfile pid文件路径
  • dir 工作路径
  • sentinel monitor <master-name> <ip> <redis-prot> <quorum>
    设置要监控的master服务器 quorum表示确认客观下线的最少的哨兵数量
    我们知道,网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了,quorum这个参数是进行客观下线的一个依据,意思是至少有quorum个sentinel认为这个master有故障,才会对这个master进行下线以及故障转移。因为有的时候,某个sentinel节点可能因为自身网络原因,导致无法连接master,而此时master并没有出现故障,所以,这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,这就保证了公平性和高可用
  • sentinel auth-pass <master-name> <password> 连接master服务的密码
  • sentinel down-after-milliseconds <master-name> <milliseconds> 指定多少毫秒之后,主节点没有应答哨兵,此时哨兵主观上认为主节点下线
  • sentinel parallel-syncs <master-name> <nums> 表示允许并行同步的slave个数,当Master挂了后,哨兵会选出新的Master,此时,剩余的slave会向新的master发起同步数据
  • sentinel failover-timeout <master-name> <milliseconds> 故障转移的超时时间,进行故障转移时,如果超过设置的毫秒,表示故障转移失败
  • sentinel notification-script <master-name> <script-path> 配置当某一事件发生时所需要执行的脚本
  • sentinel client-reconfig-script <master-name> <script-path> 客户端重新配置主节点参数脚本

我们将三个哨兵配置到同一个机器中,6379端口的主机。

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

在这里插入图片描述

2.3 启动哨兵模式

redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel

2.4 模拟6379主机down掉,查看结果

投票新选主机
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

6381被选为新master

在这里插入图片描述

6379从master变为slave

在这里插入图片描述
各个主机运行的Redis的配置文件会被 sentinel 动态的修改。

3. 哨兵的运行流程和选举原理

  • SDown主观下线(Subjectively Down)
    SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于master的状态,从sentinel的角度来看,如果发送了PING心跳后,在一定时间内没有收到合法的回复,就达到了SDOWN的条件。
    sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度。
    所谓主观下线(Subjectively Down, 简称 SDOWN)指的是单个Sentinel实例对服务器做出的下线判断,即单个sentinel认为某个服务下线(有可能是接收不到订阅,之间的网络不通等等原因)。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息, 那么这个Sentinel会主观的(单方面的)认为这个master不可以用了。
    在这里插入图片描述
    sentinel down-after-milliseconds <masterName> <timeout>
    表示master被当前sentinel实例认定为失效的间隔时间,这个配置其实就是进行主观下线的一个依据
    master在多长时间内一直没有给Sentine返回有效信息,则认定该master主观下线。也就是说如果多久没联系上redis-servevr,认为这个redis-server进入到失效(SDOWN)状态。

  • ODown客观下线(Objectively Down)
    ODOWN需要一定数量的sentinel,多多个哨兵达成一致意见才能认为一个master客观上已经岩掉
    四个参数含义:
    masterName是对某个master+slave组合的一个区分标识(一套sentinel可以监听多组master+slave这样的组合)
    在这里插入图片描述
    quorum这个参数是进行客观下线的一个依据,法定人数/法定票数
    意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候,某个sentinel节点可能因为自身网络原因导致无法连接master,而此时master并没有出现故障,所以这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,这就保证了公平性和高可用。

    1. 选出领导者哨兵
      当主节点被判断 客观下线 以后各个哨兵节点会进行协商先选举出一个领导者哨兵节点(兵王))并由该领导者节点,也即被选举出的兵王进行failover(故障迁移)。
      哨兵领导者,兵王如何选出来的?Raft算法。
      在这里插入图片描述
      监视该主节点的所有哨兵都有可能被选为领导者,选举使用的算法是Raft算法;Raft算法的基本思路是先到先得:
      即在一轮选举中,哨兵A向B发送成为领导者的申请,如果B没有同意过其他哨兵,则会同意A成为领导者。
    1. 由领导者哨兵推动故障切换流程并选出一个新master
      选出新master的规则,剩余slave节点健康前提下
      redis.conf文件中,优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)。
      在这里插入图片描述
      复制偏移位置offset最大的从节点。
      最小Run ID的从节点,字典顺序,ASCII码。
      在这里插入图片描述
    1. 执行slaveof no one命令让选出来的从节点成为新的主节点,并通过slaveof命令让其他节点成为其从节点
    1. Sentinel leader会对选举出的新master执行slaveof no one操作,将其提升为master节点
    1. Sentinel leader向其它slave发送命令,让剩余的slave成为新的master节点的slave
    1. 将之前已下线的老master设置为新选出的新master的从节点,当老master重新上线后,它会成为新master的从节点
    1. Sentinel leader会让原来的master降级为slave并恢复正常工作

上述的failover操作(故障转移操作)均由sentinel自己独自完成,完全无需人工干预

4. 哨兵使用建议

  • 哨兵节点的数量应为多个,哨兵本身应该集群,保证高可用
  • 哨兵节点的数量应该是奇数
  • 各个哨兵节点的配置应一致
  • 如果哨兵节点部署在Docker等容器里面,尤其要注意端口的正确映射
  • 哨兵集群+主从复制,并不能保证数据零丢失承上启下引出集群
本文含有隐藏内容,请 开通VIP 后查看

网站公告

今日签到

点亮在社区的每一天
去签到