将宕机的master下线 找一个salve作为master 通知所有的slave连接新的master 启动新的Master与slave 全量复制N+部分复制N 谁来确认master宕机了 找一个？怎么找法 修改配置后，原始的主恢复了怎么办？

哨兵简介 哨兵(sentinel)是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master

哨兵的作用 - 监控 不断的检查master和slave是否正常运行 master存活检测，master和slave运行情况检测 - 通知（提醒） 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知 - 自动故障转移 断开master和slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端的服务器地址

注意： 哨兵也是一台redis服务器，只是不提供数据服务 通常哨兵配置数量为单数

配置哨兵

• 配置一拖二的主从结构
• 配置三个哨兵（配置相同，端口不同） 哨兵配置文件sentinel.conf 启动哨兵 redis-sentinel sentinel-端口号.conf

环境： 为了快速完操实验操作，这里采用了单机多实例的方式

[root@CombCloud-2020110836 conf]# pwd
/opt/redis-5.0.9/conf
[root@CombCloud-2020110836 conf]# cat redis-6379.conf 
port 6379
daemonize no
dir "/data/redis/data"
dbfilename "dump-6379.rdb"
rdbcompression yes
rdbchecksum yes
save 10 2
appendonly yes
appendfsync always
appendfilename "appendonly-6379.aof"
bind 127.0.0.1
[root@CombCloud-2020110836 conf]# cat redis-6380.conf    
port 6380
daemonize no
dir "/data/redis/data"
replicaof 127.0.0.1 6379
[root@CombCloud-2020110836 conf]# cat redis-6381.conf  
port 6381
daemonize no
dir "/data/redis/data"
replicaof 127.0.0.1 6379
[root@CombCloud-2020110836 conf]# cat sentindel-26379.conf 
port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /data/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
[root@CombCloud-2020110836 conf]# cat sentindel-26380.conf   
port 26380
daemonize no
pidfile "/var/run/redis-sentinel.pid"
logfile ""
dir "/data/redis/data"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
[root@CombCloud-2020110836 conf]# cat sentindel-26381.conf  
port 26381
daemonize no
pidfile "/var/run/redis-sentinel.pid"
logfile ""
dir "/data/redis/data"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
先启动Mast

哨兵搭建
[root@CombCloud-2020110836 redis-5.0.9]# pwd
/opt/redis-5.0.9
[root@CombCloud-2020110836 redis-5.0.9]# cat sentinel.conf | egrep -v '^$|^#' 
port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
[root@CombCloud-2020110836 redis-5.0.9]# 

#mymaster名字可以随便起，连接的Master名字可以自定义， 连接服务器，2是代表如果有两台服务器认定master已死，则宣传master死记，通知设置哨兵数量的一半加1，所以哨兵数量必须为奇数 sentinel monitor mymaster 127.0.0.1 6379 2

#三十秒连接不上Master,则判断定master已死 sentinel down-after-milliseconds mymaster 30000

#新的master上任一次有多少个开始同步 sentinel parallel-syncs mymaster 1

#三分钟同步没完成算超时 sentinel failover-timeout mymaster 180000

#先启动master再启动slave，再启动哨兵

1、启动master

2、启动slave1

3、启动slave2

4、启动第一个哨兵 可以看到6380及6381在连接master主6379端口 7310:X 08 Jun 2020 04:56:51.361 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379 7310:X 08 Jun 2020 04:56:51.363 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

哨兵1客户端配置文件发生变化

5、启动第二个哨兵

可以看到26379即第一个哨兵在监控6379master

6、启动第三个哨兵 可以看到26379及26380在监控6379端口

7、此时再次查看三个哨兵配置文件发生变化 26379配置文件可以发现从库有6380和6381，及哨兵监控26380和26381

8、查看监听端口

9、关闭master

10、随便找一台哨兵日志输出 从日志最后三行可以看到 6380实例的redis已被选为Master，移除故障实例6379

11、查看6379,6380,6381配置文件 可看到redis6380配置文件已删除slaveof，而6381配置文件指定的主为6380

12、重新启动6379的master 查看哨兵已把这台主机从新加入监控

13、查看配置6379配置文件，该实例从新加入了集群成为了slave

集群搭建及主从故障切换过程演示完成

哨兵工作原理 三个阶段概述

• 监控阶段
• 通知阶段
• 故障转移阶段

阶段一：监控阶段 用于同步各个节点的状态信息

• 获取各个sentinel的状态（是否在线）
• 获取master的状态 -master 属生 - runid - role: master - 各个slave的详信息 - 获取所有slave的状态（根据master中的slave信息） - slave属性 - runid - role: slave - master_host、master_port - offset

原理解释： 1、哨兵先通过info获取master的各种状态(runid,role)信息，保存所有的哨兵状态(sentinestate,master,slaves,sentinels) 2、sentinel通过cmd连接master进行命令交换，通过命令连接获取工作状态 3、master保存所有redis实例的信息(sentineredislnstance,master,slave,sentinels) 4、哨兵通过info获取slave的各种状态(runid,role,master_host,,master_port,offset)信息 5、哨兵通过cmd连接slave进行命令交换 6、sentinel集群通过发布订阅进行信息共享，通过ping查看对方有没有存活

阶段二：通知阶段 原理解释： 任意一台sentinel通过cmd命令连接获取master和slave的状态，对master和slave发布消息hello，拿到对服务器响应的信息后，会再在几个sentinel频道里面进行信息传播

阶段三：故障转移阶段

1、任意一台sentinel去对master主机发送hello，经过在配置的指定时间发送多次master不回复，sentinel认为master已死亡，给标记状态为flags:SRL_S_DOWN，此为第一个哨兵发现死亡，为主观下线 2、sentinel在sentinel频道发送is-master-down-by-addr告知master已死亡 3、其他sentinel去对Master发送hello消息，经确认发现在master确实已死亡，此时master状态为flags:SRL_O_DOWN，此为客观下线，哨兵日志可看到输出，即配置文件里配置的只要认为有2人或以上认同master已下线，此为三台哨兵。所以哨兵数需要为奇数

各sentinel通过发送挂的ip，挂的端口，竟选次数，自已的runid，进行参加竟选投票，先发出来要投票的sentinel，被后面的setninel收到，则投他一票，票数多的通过竟选成为选择新master的权利者

被选出来的哨兵拥有选择slave为Master的权利，而此哨兵会通过如下来选择一个master王者 1、选择slave还在线的 2、会选择响应速度比较快的 3、选择与master连接时间长的 4、优先原则，1）优先级高的，2）偏移量近的，3）runid比较小的 哨兵选择好相应的slave做master后，会向新上任的master发送slaveof no，通知不要再连宕机Master，接着再通知其他slave发送slaveo，即连接的f新的master ip端口