“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
: 就是设置一个哨兵进程的端口为26379mymaster
:由于一套哨兵
可以监控多套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
文件由于我们要启3个哨兵,所以我们需要再新增两个配置文件分别是
26380.conf
和26381.conf
,我们刚才已经配置好了一个26379.conf
,这边直接复制出两份修改一下各配置文件中对应的端口号即可cp 26379.conf 26380.conf cp 26379.conf 26381.conf
修改
26380.conf
中对应的端口号vi 26380.conf
port 26380sentinel monitor mymaster 127.0.0.1 6379 2sentinel auth-pass mymaster 密码
修改好按
Esc
键输入:wq
退出编辑并保存修改
26381.conf
中对应的端口号vi 26381.conf
port 26381sentinel monitor mymaster 127.0.0.1 6379 2sentinel 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 的数量不达标,自动故障迁移就不会执行)#哨兵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
,我们将它强制退出模拟服务挂机我们去看
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 命令来询问对方是否认为给定的服务器已下线。)
-
客户端可以通过订阅来获得的频道和信息的格式
可以参照这个表格去看哨兵日志
@
频道/事件名字 释义 +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为主节点了
到这里,哨兵的操作基本过了一遍了,如有建议可提,会及时采纳~