Redis---8---哨兵（sentinel）

Redis---8---哨兵（sentinel）

是什么

吹哨人巡查监控后台master主机是否故障，如果故障了根据*** 投票数 *** 自动将某一个从库转换为新主库，继续对外服务。

作用： 俗称，无人值守运维

​

1，监控redis运行状态，包括master和slave
2，当master down机，能自动将slave切换成新master

能干嘛

• 主从监控 监控主从redis库运行是否正常
• 消息通知 哨兵可以将故障转移的结果发送给客户端
• 故障转移 如果Master异常，则会进行主从切换，将其中一个Slave作为新Master
• 配置中心 客户端通过连接哨兵来获得当前Redis服务的主节点地址

怎么玩（案例演示实战步骤）

• Redis Sentinel 架构，前提说明

  • 三个哨兵 自动监控和维护集群，不存放数据，只是吹哨人

  • 1主2从 用于数据读取和存放

    • 6379

    

不服就干

1. /myredis目录下新建或者拷贝sentinel.conf文件，名字绝不能错

2. 先看看/opt目录下默认的sentinel.conf文件的内容

3. 重点参数项说明

   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服务的密码。
   

   

   

   

4. 本次案例哨兵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
   

   

5. 先启动一主二从3个redis实例，测试正常的主从复制

   

   6379这台机器要设置masterauth 是因为后续可能变成从机，需要设置访问新主机的密码，不然可能后续报错master_line_status:down

6. 以下是哨兵内容部分=====

7. 再启动三个哨兵，完成监控

   redis-sentinel /path/to/sentinel.conf	或
   redis-server /path/to/sentinel.conf --sentinel
   

   

8. 启动3个哨兵监控后在测试一次主从复制

   

   

   

   

   

9. 原有的master挂了

   • 手动关闭6379服务器，模拟master挂了

   • 问题思考

     1. ​ 两台从机数据是否ok？

     2. ​ 是否会从剩下的2台机器上选出新的master

     3. ​ 之前down机的master机器重启回来，谁将会是新老大？会不会双master冲突？

        

        ​

        在本次案例中，6380被选为新master，上位成功

        以前的6379从master降级变成了slave

        6381还是slave，只不过换了个新老大6380

10. 对比配置文件

    

    

    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等容器里面，尤其要注意端口的正确应声。

哨兵集群+主从复制，并不能保证数据零丢失。