Redis---8---哨兵（sentinel）
是什么
吹哨人巡查监控后台master主机是否故障，如果故障了根据*** 投票数 *** 自动将某一个从库转换为新主库，继续对外服务。
作用： 俗称，无人值守运维
1，监控redis运行状态，包括master和slave
2，当master down机，能自动将slave切换成新master
能干嘛
- 主从监控 监控主从redis库运行是否正常
- 消息通知 哨兵可以将故障转移的结果发送给客户端
- 故障转移 如果Master异常，则会进行主从切换，将其中一个Slave作为新Master
- 配置中心 客户端通过连接哨兵来获得当前Redis服务的主节点地址
怎么玩（案例演示实战步骤）
-
Redis Sentinel 架构，前提说明
-
三个哨兵 自动监控和维护集群，不存放数据，只是吹哨人
-
1主2从 用于数据读取和存放
- 6379
-
不服就干
-
/myredis目录下新建或者拷贝sentinel.conf文件，名字绝不能错
-
先看看/opt目录下默认的sentinel.conf文件的内容
-
重点参数项说明
bind 服务监听地址，用于客户端连接，默认本机地址 daemonize 是否以后台daemon方式运行 protected-mode 安全保护模式 port 端口 logfile 日志文件路径 pidfile pid文件路径 dir 工作目录 ================================ 哨兵 监控 法定投票数 sentinel monitor <master-name> <ip> <redis-port> <quotum> 设置要监控的master服务器 quorum表示最少有几个哨兵认可"客观下线" ，同意故障迁移的法定票数。 sentinel auth-pass <master-name> <password> master设置了密码，连接master服务的密码。 -
本次案例哨兵sentinel文件通用配置
哨兵默认的端口号是26379
26379： 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.137.132 6379 2 sentinel auth-pass mymaster 924721 26380: bind 0.0.0.0 daemonize yes protected-mode no port 26379 logfile "/myredis/sentinel26380.log" pidfile /var/run/redis-sentinel26380.pid dir /myredis sentinel monitor mymaster 192.168.137.132 6389 2 sentinel auth-pass mymaster 924721 26381: bind 0.0.0.0 daemonize yes protected-mode no port 26379 logfile "/myredis/sentinel26381.log" pidfile /var/run/redis-sentinel26381.pid dir /myredis sentinel monitor mymaster 192.168.137.136 6381 2 sentinel auth-pass mymaster 924721 -
先启动一主二从3个redis实例，测试正常的主从复制
6379这台机器要设置masterauth 是因为后续可能变成从机，需要设置访问新主机的密码，不然可能后续报错master_line_status:down
-
以下是哨兵内容部分=====
-
再启动三个哨兵，完成监控
redis-sentinel /path/to/sentinel.conf 或 redis-server /path/to/sentinel.conf --sentinel -
启动3个哨兵监控后在测试一次主从复制
-
原有的master挂了
-
手动关闭6379服务器，模拟master挂了
-
问题思考
-
两台从机数据是否ok？
-
是否会从剩下的2台机器上选出新的master
-
之前down机的master机器重启回来，谁将会是新老大？会不会双master冲突？
在本次案例中，6380被选为新master，上位成功
以前的6379从master降级变成了slave
6381还是slave，只不过换了个新老大6380
-
-
-
对比配置文件
master哨兵配置文件自动生成新增内容
master主配置文件会在最下面自动生成新增内容
结论： Master-Slave切换后，master_redis.conf、salve_redis.conf和sentinel.conf 的内容都会发生改变，即master_redis.conf会多一行slaveof的配置，sentinel.conf的监控目标会随之调换其他备注
- 生产都是不同机房不同服务器，很少出现3个哨兵全挂掉的情况
- 可以同时监控多个master，一行一个。
哨兵运行流程和选举原理
当一个主从配置中的master失效之后，sentinel可以选举出一个新的master，用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据，一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。
运行流程，故障切换
-
三个哨兵监控一主二从，正常运行中...
-
SDown主观下线（Subjectively Down）
-
ODown客观下线（Objectively Down）
ODown需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉
-
选举出领导者哨兵（哨兵中选出兵王）
当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者节点，也即被选举出的兵王进行failover（故障迁移） 日志文件： sdown master mymaster 192.168.137.132 6379 //主管下线 odown master mymaster 192.168.137.132 6379 quorum 2/2 //认为6379客观下线达到了两个票数 new-epoch 1 //开始新的一轮选举 +try-failover master mymaster 192.168.137.132 6379 //尝试故障迁移 Sentinel new configuration saved on disk +vote-for-leader 哨兵一号ID 1 //选举兵王 哨兵N号ID voted for 哨兵一号ID 1 //给哨兵一号选取兵王投取一票 哨兵M号ID voted for 哨兵一号ID 1 //给哨兵一号选取兵王投取一票 ======================= +switch-master mymaster ......6379(IP) .....6380(IP) //交换master +slave slave ......6379 @ mymaster ......6380 //给新master6380 重新指定两个slave +slave slave ......6381 @ mymaster ......6380哨兵领导者--兵王是如何选出来的？---->Raft算法
-
由兵王开始推动故障切换流程并选出一个新master
新主登基 某个slave选举为新的master priority 值越小，优先级越高，默认是100 规则：先比优先级高-----》再比复制偏移量大-----》RunID谁小（字典顺序，ASCII码）群臣俯首 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点。 Sentinel leader会对选举出的新master执行slave no one操作，将其提升为master节点。 Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave。 旧主拜服 老master回来也认怂 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点。 Sentinel leader 会让原来的master降级为slave并恢复正常工作。小总结，上述的failover操作均由sentinel自己独自完成，完全无需人工干预。
哨兵使用建议
哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用。
哨兵节点的数量应该是奇数。（保证高可用，可投票）
各个哨兵节点的配置（硬件）应一致。
如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确应声。
哨兵集群+主从复制，并不能保证数据零丢失。
eader 会让原来的master降级为slave并恢复正常工作。
小总结，上述的failover操作均由sentinel自己独自完成，完全无需人工干预。
[外链图片转存中...(img-5mwIEnTO-1719890634085)]
## 哨兵使用建议
哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用。
哨兵节点的数量应该是奇数。（保证高可用，可投票）
各个哨兵节点的配置（硬件）应一致。
如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确应声。
哨兵集群+主从复制，并不能保证数据零丢失。