Loading

redis哨兵机制

版权声明:本文为转载文章,博客原文地址:http://blog.csdn.net/a67474506?viewmode=contents

一、Redis的哨兵(sentinel) 系统用于管理多个 redis 服务器,该系统执行以下三个任务:

1、监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

2、提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

3、自动故障迁移(Automatic failover):当一个Master不能正常工作时,哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

二、哨兵

  哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown)。若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel 。但实际上它只是一个运行在特殊模式下的 Redis 服务器,你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。哨兵(sentinel) 的一些设计思路和zookeeper非常类似

单个哨兵(sentinel)

 

启动 6379  6380  6381 

配置主从架构

 

进入redis安装目录

修改哨兵配置文件

 
  1. vi sentinel.conf  


设置 sentinel monitor 为Master 地址

 

 

最后面的数字 1 表示最低通过票数

新建一个xshell连接来启动哨兵,可以查看sentinel的控制台信息

 
  1. redis-sentinel ./sentinel.conf  

 

 

将6380强制杀掉

 

等待一会  哨兵的控制台 打印出来 +sdown信息

 

 

说明已经监控到slave宕机了

 

重新启动 6380

哨兵控制台打印

 

可以看出slave重新加入到了主从复制中

-sdown: 说明是恢复服务

 

现在将Master 强制杀掉

 

哨兵控制台打印

 

我们进入 6381 查看状态

 

6381 已经是 master了 并且拥有一个 6380的slave

 

重新启动6379

 

6379已经恢复,并且将6379设置为6380的slave

 

这时我们查看sentinel.conf 发现  我们刚刚配置的端口已经变成6381

 

而6381也有2个slave

 

查看etc下面的redis.6379.conf 和 redis.6380.conf 发现哨兵(sentinel) 已经对该文件做了修改

 

6379之前是没有配置,所以就添加到了最后一行

sentinel后台运行和redis的配置文件一样修改daemonize参数

 

多个哨兵(sentinel)

 

配置了一个哨兵,如果该哨兵宕机了,那么整个主从架构就回复到了原始的情况,所以我们可以配置多个哨兵,每个哨兵监控Redis信息,并且哨兵之间也会互相监控

修改sentinel.conf中的最低通过票数

 

在拷贝二份sentinel.conf

 

[plain] view plain copy
 
  1. cp ./sentinel.conf sentinel.26479.conf  
  2. cp ./sentinel.conf sentinel.26579.conf  


修改sentinel.26579.conf和sentinel.26479.conf中的port

 

 

在新开二个xshell会话,查看26479 和 26579的控制台信息

在每个会话分别启动一个sentinel

 

此时控制台信息

26379:

 

增加了2个sentinel

26479:

 

26579:

 

强制杀掉6379

 

Sentinel发现宕机情况

 

3个都是一样的

 

重新启动6379,sentinel 打印的信息室一样的

 

好吧多个sentinel和一个sentinel的效果是一样,那么我们杀掉master试试

 

和单个哨兵是差不多的

整个故障转移过程是需要啊一个leader来调整的,所以多个sentinel会选举一个leader

在Leader触发failover之前,首先wait数秒(随即0~5),以便让其他sentinel实例准备和调整, 如果一切正常,那么leader就需要开始将一个salve提升为master,此slave必须为状态良好(不能处于SDOWN/ODOWN状态)且权重值最低(redis.conf中)的,当master身份被确认后,开始failover

 

另外2个sentinel的控制台信息

26479:

 

26579:

 

大概结果就是这样  ╮(╯▽╰)╭

 

那么我们强行杀掉一个sentinel试试

 

杀掉之后另外2个sentinel 都打印出了这个结果

 

仅此而已  其他的暂时没有发现什么东东

 

详细学习文章:

Redis Sentinel:集群Failover解决方案

http://shift-alt-ctrl.iteye.com/blog/1884370

Redis基于Sentinel哨兵高可用方案

http://www.178linux.com/672
Redis中sentinel集群的搭建和Jedis测试图文教程

http://blog.csdn.net/wtyvhreal/article/details/46517483

posted @ 2017-07-23 16:14  xwlmdd  阅读(291)  评论(0编辑  收藏  举报