> 文档中心 > “Redis哨兵“一撸到底 ,贼爽~

“Redis哨兵“一撸到底 ,贼爽~



? Redis系列?:

?Redis安装教程(保姆级详细图文)
?布隆过滤器安装步骤
?小记一手 “Redis持久化机制”
?手把手带你实操 RDB & AOF)
?带你 “亲自体验“ Redis主从复制


?温馨提示?:本文前置操作Redis主从复制


  • 停止所有Redis服务

    Ctrl+C逐一退出Redis前台服务

  • 新增26379.conf配置文件

    cd ~/test/vi 26379.conf
  • 将一下配置贴入26379.conf配置文件中

    指令提示:按i键开启vi的输入模式

    port 26379: 就是设置一个哨兵进程的端口为26379

    mymaster :由于一套哨兵可以监控多套Redis主从复制集群,所以是给每套Master起个名字

    127.0.0.1+6379+2:地址+端口号+投票权重值

    因为我们设置了Redis节点通信密码,所以得配置 sentinel auth-pass

    port 26379sentinel monitor mymaster 127.0.0.1 6379 2sentinel auth-pass mymaster 密码

    指令提示:按Esc键输入:wq退出编辑并保存,这是会在test/目录中生成一个26379.conf文件

    “Redis哨兵“一撸到底 ,贼爽~

    由于我们要启3个哨兵,所以我们需要再新增两个配置文件分别是26380.conf26381.conf,我们刚才已经配置好了一个26379.conf,这边直接复制出两份修改一下各配置文件中对应的端口号即可

    cp 26379.conf 26380.conf cp 26379.conf 26381.conf 

    “Redis哨兵“一撸到底 ,贼爽~

    修改26380.conf中对应的端口号

    vi 26380.conf 
    port 26380sentinel monitor mymaster 127.0.0.1 6379 2sentinel auth-pass mymaster 密码

    “Redis哨兵“一撸到底 ,贼爽~

    修改好按Esc键输入:wq退出编辑并保存

    修改26381.conf中对应的端口号

    vi 26381.conf 
    port 26381sentinel monitor mymaster 127.0.0.1 6379 2sentinel auth-pass mymaster 密码

    “Redis哨兵“一撸到底 ,贼爽~

    修改好按Esc键输入:wq退出编辑并保存

  • 启动Redis主从复制集群

    我们还是像上面那样在不同的窗口中开启不同的服务

    启动6379服务,此服务依然作为主节点

    redis-server ~/test/6379.conf

    在这里插入图片描述

    分别在Redis_6380Redis_6381窗口中分别启动63806381服务并追加为6379的从节点

    redis-server ~/test/6380.conf --replicaof 127.0.0.1 6379

    在这里插入图片描述

    redis-server ~/test/6381.conf --replicaof 127.0.0.1 6379

    查看6379节点日志,发现63806381节点服务成功追加为6379节点的从节点,那么6379即是这套主从复制集群主节点

    在这里插入图片描述

    • 启动哨兵

      知识点摘要:哨兵可以独立成一个进程运行,也可直接将redis-server作为哨兵使用,但从作为哨兵那刻起,此进程运行的服务不再是对外提供key-value存储的服务了

      启动第一个哨兵

      redis-server ~/test/26379.conf --sentinel

      在这里插入图片描述

      关键字释义

      Port: 26379便是我们刚才配置文件里面配置的

      quorum:投票权重值(只要同意 Sentinel 的数量不达标,自动故障迁移就不会执行)

      #哨兵IDSentinel ID is e2b3c7ec7f319cb6196ad6669e99e6f583f75ec7#Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为 127.0.0.1 , 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意+monitor master mymaster 127.0.0.1 6379 quorum 2#发现从节点有两个+slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

      启动第二个哨兵

      redis-server ~/test/26380.conf --sentinel

      在这里插入图片描述

      我们发现当启动第二个哨兵的时候好像多了点东西

      +sentinel sentinel e2b3c7ec7f319cb6196ad6669e99e6f583f75ec7 127.0.0.1 26379 @ mymaster 127.0.0.1 6379

      如果多台监控节点(Sentinel)只有一个节点监控到主节点服务异常,会出现统计不准确,势力范围不够从而产生网络分区,出现脑裂现象,

      在这里插入图片描述

      那么这个其实就是为了两两互相通信组成势力范围,如下图:

      在这里插入图片描述

      • 假设有3台监控节点同时监控主节点,则需要有2个节点都监控到主节点异常才会进行投票
      • 假设有N台监控节点同时监控主节点,则需要有N/2+1个节点都监控到主节点异常才会进行投票

      关于这块内容以后会针对性的开一章细讲,这边咱们先提个知识点,知道有这个东西先往下进行

      启动第三个哨兵

      redis-server ~/test/26381.conf --sentinel

      在这里插入图片描述

  • 自动故障转移测试

    当前主节点为6379,我们将它强制退出模拟服务挂机

    在这里插入图片描述

    我们去看63806379节点的日志就是找不到主节点了

    在这里插入图片描述
    在这里插入图片描述

  • 主观下线和客观下线

    主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。

    客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。 (一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。)

  • 客户端可以通过订阅来获得的频道和信息的格式

    可以参照这个表格去看哨兵日志

    @

    频道/事件名字 释义
    +sentinel 一个监视给定主服务器的新 Sentinel 已经被识别并添加。
    +sdown 给定的实例现在处于主观下线状态。
    -sdown 给定的实例已经不再处于主观下线状态。
    +odown 给定的实例现在处于客观下线状态。
    -odown 给定的实例已经不再处于客观下线状态。
    +new-epoch 当前的纪元(epoch)已经被更新。
    +vote-for-leader 投票选举一个leader
    +config-update-from 配置变更
    +switch-master 配置变更,主服务器的 IP 和地址已经改变。
    +failover-state-reconf-slaves 故障转移状态切换到了 reconf-slaves 状态。
    +slave-reconf-sent 领头(leader)的 Sentinel 向实例发送了 SLAVEOF 命令,为实例设置新的主服务器。
    +slave-reconf-inprog 实例正在将自己设置为指定主服务器的从服务器,但相应的同步过程仍未完成。
    +slave-reconf-done 从服务器已经成功完成对新主服务器的同步。
    +try-failover 一个新的故障迁移操作正在执行中,等待被大多数 Sentinel 选中
    +elected-leader 赢得指定纪元的选举,可以进行故障迁移操作了。
    +failover-state-select-slave 故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
    selected-slave Sentinel 顺利找到适合进行升级的从服务器。
    failover-state-send-slaveof-noone Sentinel 正在将指定的从服务器升级为主服务器,等待升级功能完成。
    failover-end 故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。

    分别观察3个哨兵服务的日志,我们来看看他们到底干了哪些事情

    sentinel_26379

    在这里插入图片描述

    #6379实例现在处于主观下线状态。+sdown master mymaster 127.0.0.1 6379#new一个新的纪元+new-epoch 1#投票选举sentinel_26381为leader节点(6ae83ddea90380e653bc5795a93633213579f2c4是sentinel_26381的Sentinel ID)+vote-for-leader 6ae83ddea90380e653bc5795a93633213579f2c4 1#6379实例现在处于客观下线状态。投票权重值是3/2(我们设置的投票权重值是2 这里达到了3,所以6379实例处于客观下线已经实锤可信)+odown master mymaster 127.0.0.1 6379 #quorum 3/2#配置变更,主服务器的 IP 和地址已经由127.0.0.1 6379变为127.0.0.1 6380。+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380#6381作为从服务器已经被 Sentinel 识别并关联到6380主节点。+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380#6379作为从服务器已经被 Sentinel 识别并关联到6380主节点。+slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380#6379节点现在处于主观下线状态。+sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

    sentinel_26380

    在这里插入图片描述

    #6379实例现在处于主观下线状态。+sdown master mymaster 127.0.0.1 6379#new一个新的纪元+new-epoch 1#投票选举sentinel_26381为leader节点(6ae83ddea90380e653bc5795a93633213579f2c4是sentinel_26381的Sentinel ID)+vote-for-leader 6ae83ddea90380e653bc5795a93633213579f2c4 1##配置变更,主服务器的 IP 和地址已经由127.0.0.1 6379变为127.0.0.1 6380。+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380#6381作为从服务器已经被 Sentinel 识别并关联到6380主节点。+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380#6379作为从服务器已经被 Sentinel 识别并关联到6380主节点。+slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380#6379节点现在处于主观下线状态。+sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

    sentinel_26381

    在这里插入图片描述

    #主观下线+sdown master mymaster 127.0.0.1 6379#客观下线+odown master mymaster 127.0.0.1 6379 #quorum 2/2#新开一个纪元+new-epoch 1#故障迁移操作正在执行中,等待被大多数 Sentinel 选中。+try-failover master mymaster 127.0.0.1 6379#统计选票+vote-for-leader 6ae83ddea90380e653bc5795a93633213579f2c4 1 9752d773b66a8012ac0f4bf3b38651c4cd058c1f voted for 6ae83ddea90380e653bc5795a93633213579f2c4 1 e2b3c7ec7f319cb6196ad6669e99e6f583f75ec7 voted for 6ae83ddea90380e653bc5795a93633213579f2c4 1#当前节点赢得指定纪元的选举,可以进行6379节点的故障迁移操作了。+elected-leader master mymaster 127.0.0.1 6379#6379节点故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器+failover-state-select-slave master mymaster 127.0.0.1 6379#Sentinel 顺利找到适合进行升级的从服务器6380。+selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379#Sentinel 正在将6380节点由从服务器升级为主服务器,等待升级功能完成。+failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379#故障切换状态等待6380节点晋升+failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379#6380节点已成功晋升+promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379#6379节点故障转移状态切换到了 reconf-slaves 状态+failover-state-reconf-slaves master mymaster 127.0.0.1 6379#6381此时是leader Sentinel节点向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令,为实例设置新的主服务器。+slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379#6379实例已经不再处于客观下线状态。-odown master mymaster 127.0.0.1 6379#6381实例正在将自己设置为指定主服务器的从服务器,但相应的同步过程仍未完成。+slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379#6381节点从服务器已经成功完成对新主服务器的同步。+slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379#6379节点故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。+failover-end master mymaster 127.0.0.1 6379#配置变更,主服务器的 IP 和地址已经由127.0.0.1 6379变为127.0.0.1 6380。+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380#6381作为从服务器已经被 Sentinel 识别并关联到6380主节点。+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380#6379作为从服务器已经被 Sentinel 识别并关联到6380主节点。+slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380#6379节点现在处于主观下线状态。+sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

    我们现在去6380主节点的Redis客户端操作一些set指令

    127.0.0.1:6380> FLUSHALLOK127.0.0.1:6380> keys *(empty array)127.0.0.1:6380> set k1 aaaOK

    6381从节点的Redis客户端看能不能正常同步到6380主节点的数据

    127.0.0.1:6381> keys *1) "k1"127.0.0.1:6381> get k1"aaa"

    经测试可以看到自动故障转移是成功的

    随着自动故障转移成功,哨兵是会将配置文件中主节点配置给修改成当前主节点

    vi ~/test/26379.conf

    到了最后,我们刚开始配的是6379为主节点 现在自动故障转移成功后,哨兵将配置文件修改为了6380为主节点了

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-R5u4p8sI-1647370544683)(/Users/rhys/Library/Application Support/typora-user-images/image-20220316024205530.png)]

    到这里,哨兵的操作基本过了一遍了,如有建议可提,会及时采纳~

杭州女装网