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