Redis学习笔记(四) Redis哨兵(sentinel)

版权声明:本文为博主原创文章,博客地址:http://blog.csdn.net/a67474506?viewmode=contents https://blog.csdn.net/a67474506/article/details/50435498

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

·        监控(Monitoring): 哨兵(sentinel) 会不断地检查你的MasterSlave是否运作正常。

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

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

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.

每个哨兵(sentinel) 会向其它哨兵(sentinel)masterslave定时发送消息,以确认对方是否,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的主观认为宕机” 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安装目录


修改哨兵配置文件

vi sentinel.conf

设置 sentinel monitor 为Master 地址

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

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

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

cp ./sentinel.conf sentinel.26479.conf
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
Redissentinel集群的搭建和Jedis测试图文教程

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

展开阅读全文

没有更多推荐了,返回首页