Redis09章——哨兵（sentinel）

一、是什么 吹哨人巡查监控后台master主机是否故障，如果故障了根据$\textcolor{red}{投票数}$自动将某一个从库转换为新主库，继续对外服务作用：俗称无人值守运维官网理论：High availability with Redis Sentinel | Docs 二、能干嘛 主从监控：监控主从redis库运行是否正常消息通知：哨兵可以将故障转移的结果发送给客户端故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新master配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址 三、怎么玩（案例演示实战步骤） （1）Redis Sentinel架构，前提说明 3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人1主2从：用于数据读取和存放 （2）案例步骤 3.3.1/myredis目录下新建或者拷贝sentinel.conf文件，名字绝对不能错

3.3.2先看看/opt/redis-7.0.0目录下默认的sentinel.conf文件的内容 3.3.3重要参数项说明 bind：服务监听地址，用于客户端连接，默认本机地址daemonize：是否以后台daemon方式运行protected-model：安全保护模式port：端口logfile：日志文件路径pidfile：pid文件路径dir：工作目录重点：其它 3.3.4本次案例哨兵sentinel文件通用配置 由于机器硬件的关系，我们的3个哨兵都同时配置到192.168.200.130同一台机器sentinel26379.conf bind 0.0.0.0 daemonize yes protected-mode no port 26379 logfile "sentinel26379.log" pidfile /var/run/redis-sentinel26379.pid dir ./ sentinel monitor mymaster 192.168.200.130 6379 2 #这个2代表只要两个哨兵同意 sentinel auth-pass mymaster 111111 sentinel26380.conf bind 0.0.0.0 daemonize yes protected-mode no port 26380 logfile "sentinel26380.log" pidfile /var/run/redis-sentinel26380.pid dir ./ sentinel monitor mymaster 192.168.200.130 6379 2 sentinel auth-pass mymaster 111111 sentinel26381.conf bind 0.0.0.0 daemonize yes protected-mode no port 26381 logfile "sentinel26381.log" pidfile /var/run/redis-sentinel26381.pid dir ./ sentinel monitor mymaster 192.168.200.130 6379 2 sentinel auth-pass mymaster 111111 注意：上述的logfile和dir都要根据自己的实际情况决定，因为我们的配置文件现在就在/opt/redis-7.0.0/myredis里，所以我这么填写master主机配置文件的说明： 3.3.5先启动一主二从3个redis实例，测试正常的主从复制 注意：现在也要给主机设置masterauth了（具体的ip根据自己实际情况确定）请看一眼redis6379.conf、redis6380.conf、redis6381.conf我们自己填写的主从复制相关内容3台不同的虚拟机实例，启动三台真实机器实例并连接 3.3.6再启动三个哨兵，完成监控 redis-server sentinel26379.conf --sentinelredis-server sentinel26380.conf --sentinelredis-server sentinel26381.conf --sentinel 3.3.7启动三个哨兵监控后再测试一次主从复制

3.3.8原有的master挂了 （1）我们自己手动关闭6379服务器，模拟master挂了 （2）问题思考 两台从机数据是否OK（要等一会儿，因为内部会重新选举）是否会从剩下的两台机器上选出新的master？可以看到此时第一台从机被选举成了新的master，第二台从机成为了它的slave（可以看第一台机器的日志文件）之前宕机的master重启回来，谁将会是新老大？会不会双master冲突。答：老大还是主机宕机后，新选出来的那个master。主机就算重启，它也不会变回master了，它只会成为新的master的slave （3）揭晓答案 数据OK 两个小问题                                                                                                                        了解Broken Pipe 投票新选 sentinel26379.log，从该日志中可以看到这个哨兵的idsentinel26380.log，从该日志中可以看到这个哨兵的idsentinel26381.log，从该日志中可以看到这个哨兵的id 谁是master，仅限本次案例 6380被选为新master，上位成功以前的6379被降级变成了slave6381还是slave，只不过换了个新老大6380（6379变6380） 3.3.9对比配置文件 老master，vim redis6379.conf新master，vim redis6380.conf结论：（1）文件的内容，在运行期间会被sentinel动态进行更改（2）Mater-Slave切换后，master的conf，slave的conf，sentinel的conf内容都会发生改变，及master的conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换 （3）其它备注 生产上都是不同机房不同服务器，很少出现3个哨兵全部挂掉的情况可以同时金童监控master，一行一个 四、哨兵运行流程和选举原理 （1）介绍

当一个主从配置中master失效后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据，一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换

（2）运行流程，故障切换 4.2.1三个哨兵监控一主二从，正常运行中...... 4.2.2SDown主观下线（Subjectively Down） SDOWN（主观不可用）是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度说明： 4.2.3ODown客观下线(Objectively Down) ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机说明： 4.2.4选举出领导者哨兵（哨兵中选出兵王） 当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者也即被选举出的兵王进行failover（故障转移）三哨兵日志文件2次解读分析（举例，这个不是从我自己的三个哨兵的log文件里截取的） sentinel26379.logsentinel26380.logsentinel26381.log 哨兵领导者，兵王如何选出来的？Raft算法 4.2.5由兵王开始推动故障切换流程并选出新的master （1）3步骤 一、新主登基 某个Salve被选中成为新的Master选出新master的规则，剩余slave节点健康的前提下 redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先级越高）复制偏移位置offset最大的从节点（也就是在master还没有宕机时，复制到数据比其他Slave要多）最小Run ID的从节点，字典顺序，ASCII码 二、群臣俯首

三、旧主拜服 （2）小总结

上述的failover操作均由sentinel自己独自完成，完全不需要人工干预

五、哨兵使用建议 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用哨兵节点的数量应该是奇数各个哨兵节点的配置应一致如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射哨兵集群+主从复制，并不能保证数据零丢失（引出集群）