当前位置: 首页 > news >正文

尚硅谷redis7 63-69 redis哨兵监控之理论简介

63 redis哨兵监控之理论简介

什么是哨兵

master挂了如何办?从机原地待命。此时数据只能读取不能更新。因此需要:

吹哨人巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,

哨兵的作用


1、监控redis运行状态,包括master和slave
2、当master down机,能自动将slave切换成新master

如何使用哨兵

主从监控 监控主从redis库运行是否正常

        Sentinel 实时监控 Redis 的主从节点运行状态,检测节点是否宕机或失联。

消息通知 哨兵可以将故障转移的结果发送给客户端

        当发生主从切换后,Sentinel 会将新的主节点信息通知给客户端或相关服务,确保其连接到正确的主节点。

故障转移 如果Master异常,则会进行主从切换,将其中一个Slave作为新Master

        Sentinel 发现主节点(Master)宕机,并经多个 Sentinel 实例协商确认后,会自动将其中一个从节点(Slave)提升为新的主节点,并将其他从节点重新配置为复制新的主节点。

配置中心 客户端通过连接哨兵来获得当前Redis服务的主节点地址

        客户端可以通过连接 Sentinel 获取当前可用的主节点地址,而不需要手动修改配置,从而实现动态主节点发现。

64 redis哨兵监控之案例实操1

3个哨兵 自动监控和维护集群,不存放数据,只是吹哨人

1主2从 用于数据读取和存放

为什么要有 3 个 Sentinel 哨兵?

1.防止一个哨兵挂了,无法实现监控

2.基数好投票

Redis Sentinel 使用一种简单的共识机制来避免误判【有时候主机并不是真死了,可能是网络不好】。哨兵集群通过“投票”来决定主节点是否真的故障。这个过程称为:

故障主观判断(sdown) → 故障客观判断(odown)

  • 每个 Sentinel 实例独立判断主节点是否故障(sdown

  • 当大多数 Sentinel 都认为主节点不可用时,才会触发故障转移(odown)

Redis 集群中通常部署 3 个 Sentinel(哨兵),是为了实现高可用的主从切换机制。哨兵之间通过投票机制达成共识,判断主节点是否真的故障,并协调自动故障转移。3 个是最小可容忍 1 个故障的投票集,是安全性与资源使用的最佳平衡。

由于硬件问题,无法用6台机子去模拟过程,因此6379:master,6390、6381:slave。同时三个哨兵和6379共用一个主机。

先看看/opt目录下默认的sentinel.conf文件【哨兵配置文件】的内容

将此sentinel.conf文件拷贝到myredis文件夹下

重点参数项说明

bind:服务监听地址,用于客户端连接,默认本机地址

daemonize:是否以后台daemon方式运行

protected-mode:安全保护模式

port:端口

logfile:日志文件路径

pidfile:pid文件路径    用于指定 进程 ID 文件(PID 文件) 的保存路径。
dir:工作目录

设置要监控的Master服务器

sentinel monitor <master-name> <ip> <redis-port> <quorum>

参数说明
<master-name>主节点的名称(逻辑标识,可自定义)
<ip>要监控的主节点的 IP 地址
<redis-port>主节点的端口
<quorum>最少有多少个 Sentinel 认为主节点挂了,才会进行故障转移(投票数量)

sentinel auth-pass <master-name> <password> 配置主节点认证密码的重要命令,用于确保 Sentinel 在连接主节点时通过密码验证。

参数说明
<master-name>sentinel monitor 中配置的主节点名称保持一致
<password>主节点 Redis 的访问密码(即 requirepass 设置的密码)

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster myRedisPassword
这个配置告诉 Sentinel:
“连接并监控名为 mymaster 的主节点时,需要使用密码 myRedisPassword。”

61 redis哨兵监控之案例实操2 

我们知道,网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了,quorum这个参数是进行客观下线的一个依据,意思是至少有quorum个sentinel认为这个master有故障,才会对这个master进行下线以及故障转移。因为有的时候,某个sentinel节点可能因为自身网络原因,导致无法连接master,而此时master并没有出现故障,所以,这就需要多个sentinel都一致认为该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>:
    • 客户端重新配置主节点参数脚本

66 redis哨兵监控之案例实操3

如果你使用的是 redis-sentinel 可执行文件(或者你有一个指向 redis-server 的符号链接,名为 redis-sentinel),你可以通过以下命令来以 Sentinel 模式运行:

redis-sentinel /path/to/sentinel.conf

否则,你也可以直接使用 redis-server 可执行文件,并通过 Sentinel 模式启动,如下所示:

redis-server /path/to/sentinel.conf -- sentinel

哨兵默认监听 TCP 端口 26379,因此要让哨兵正常工作,你的服务器必须开放 26379 端口,以接收来自其他哨兵实例 IP 地址的连接。否则,哨兵之间将无法通信,也无法就该执行什么操作达成一致,故障转移也将无法进行。

本案例sentinel文件通用配置

由于机器硬件关系,我们的3个哨兵都同时配置进一台虚拟机中【例如:192.168.111.169】
sentinel26379.conf

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 26379Sentinel 的监听端口,默认就是这个
logfile日志文件路径(建议确保 /myredis 目录存在)
pidfilePID 文件路径(注意你原来写的是 redis-sentine126379. pid,有空格和拼写错)
dirSentinel 持久化信息的工作目录
sentinel monitor配置要监控的主节点(名称、IP、端口、投票数)
sentinel auth-passSentinel 连接主节点使用的认证密码

sentinel26380.conf


sentinel26381.conf
请看一眼sentinel26379.conf、sentinel26380.conf、sentinel26381.conf我们自己填写的内容
master主机配置文件说明

67 redis哨兵监控之案例实操4

哨兵内容部分

启动3个哨兵,完成监控

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

启动3个哨兵后再测试一次主从复制

原有的master挂了

        两台从机数据是否OK         ok
        是否会从剩下的2台机器上选出新的master         是,master变为6381
        之前down机的master机器重启回来,谁将会是新老大?会不会双master冲突?        重启回来会变为从机。

69 reids哨兵监控之案例实操6

broken pipe

6379突然断开后会报两种错误:

6379断开后,6380先是会报错,但过一会又能正常使用

这两种错误几乎是一样的原因

认识broken pipe

        pipe是管道的意思,管道里面是数据流,通常是从文件或网络套接字读取的数据。当该管道从另一端突然关闭时,会发生数据突然中断,即是broken.对于socket来说,可能是网络被拔出或另一端
的进程崩溃

解决问题

        其实当该异常产生的时候,对于服务端来说,并没有多少影响。因为可能是某个客户端突然中止了进程导致了该错误

总结 Broken Pipe
        这个异常是客户端读取超时关闭了连接,这时候服务器端再向客户端已经断开的连接写数据时就发生了broken pipe异常!

谁是master

6381被选为新master,上位成功,以前的6379从master降级变成了slave
6380还是slave,只不过换了个新老大6381(6379变6381),6380还是slave

注意!6379后续可能会变成从机,需要设置访问新主机的密码,请设置masterauth项访问密码为111111,不然后续可能报错master_link_status:down

对比配置文件

由于主机从机的位置互换,检查配置文件会发现里面有关主从机配置的参数也会发生改变:

文件的内容,在运行期间会被sentinel动态进行更改
Master-Slave切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换

相关文章:

  • 查看webpack版本的三种方式
  • LiveGBS国标视频平台收流模式:UDP、TCP被动与TCP主动传输模式之差异剖析
  • JavaScript 性能优化:从入门到实战
  • 精益数据分析(92/126):指标基准化——如何判断你的数据表现是否足够优秀
  • Cloudera Manager 学习笔记
  • 使用Miniconda管理Python环境
  • 从0到1掌握Kotlin高阶函数:开启Android开发新境界!
  • 【第2章 绘制】2.8 线段
  • 有关于常量的一节知识
  • 设计模式26——解释器模式
  • 腾控产品在油田间抽节能中的应用
  • 苍穹外卖 09 WebSocket来单提醒客户催单营业额统计
  • 第二章 1.5 数据采集安全风险防范之数据采集安全管理
  • Three.js 直线拐角自动圆角化(圆弧转弯)
  • electron开发百度桌面应用demo及如何打包应用
  • LabVIEW双光子荧光成像软件开发
  • 智能指针的使用及原理
  • 大模型-高通性能测试工具介绍-1
  • 基本面高股息策略
  • ros2--串口通信
  • 怎么做微信领券网站/优化设计三年级上册语文答案
  • wordpress主题超2m/seo引擎搜索网站
  • 建设学分银行网站策划书/外贸接单十大网站
  • 给别人做网站/深圳在线制作网站
  • 医疗营销网站建设/软文推广发稿
  • 郑州大型网站/企业网站模板 免费