【Redis哨兵】一撸到底，贼爽~_status=odown-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_44977377/article/details/123516724

🐯Redis系列🐯：

🐯Redis安装教程（保姆级详细图文）
🐯布隆过滤器安装步骤
🐯小记一手 “Redis持久化机制”
🐯手把手带你实操 RDB & AOF
🐯带你 “亲自体验“ Redis主从复制
🐯“Redis哨兵“一撸到底，贼爽~
🐯“Redis代理“之Twemproxy

🐯温馨提示🐯：本文前置操作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 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster 密码
```
指令提示：按Esc键输入:wq退出编辑并保存，这是会在test/目录中生成一个26379.conf文件

由于我们要启3个哨兵，所以我们需要再新增两个配置文件分别是26380.conf和26381.conf，我们刚才已经配置好了一个26379.conf，这边直接复制出两份修改一下各配置文件中对应的端口号即可
```
cp 26379.conf 26380.conf 
cp 26379.conf 26381.conf 
```
修改26380.conf中对应的端口号
```
vi 26380.conf 
```
```
port 26380
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster 密码
```
修改好按Esc键输入:wq退出编辑并保存

修改26381.conf中对应的端口号
```
vi 26381.conf 
```
```
port 26381
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster 密码
```
修改好按Esc键输入:wq退出编辑并保存
启动Redis主从复制集群

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

启动6379服务，此服务依然作为主节点
```
redis-server ~/test/6379.conf
```
分别在Redis_6380和Redis_6381窗口中分别启动6380和6381服务并追加为6379的从节点
```
redis-server ~/test/6380.conf --replicaof 127.0.0.1 6379
```
```
redis-server ~/test/6381.conf --replicaof 127.0.0.1 6379
```
查看6379节点日志，发现6380和6381节点服务成功追加为6379节点的从节点，那么6379即是这套主从复制集群的主节点
- 启动哨兵
  
  知识点摘要：哨兵可以独立成一个进程运行，也可直接将redis-server作为哨兵使用，但从作为哨兵那刻起，此进程运行的服务不再是对外提供key-value存储的服务了
  
  启动第一个哨兵
```
redis-server ~/test/26379.conf --sentinel
```
  关键字释义：
  
  Port: 26379便是我们刚才配置文件里面配置的
  
  quorum:投票权重值（只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）
```
#哨兵ID
Sentinel 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,我们将它强制退出模拟服务挂机

我们去看6380和6379节点的日志就是找不到主节点了
主观下线和客观下线

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

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

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

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

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

频道/事件名字释义
+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 故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。

频道/事件名字	释义
+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> FLUSHALL
OK
127.0.0.1:6380> keys *
(empty array)
127.0.0.1:6380> set k1 aaa
OK

到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)]