码迷，mamicode.com
首页 > 其他好文 > 详细

Redis Sentinel：集群Failover解决方案（转载）

时间：2015-03-11 14:26:13      阅读：181      评论：0      收藏：0      [点我收藏+]

标签：

本文转载自：http://shift-alt-ctrl.iteye.com/blog/1884370

文中的配置例子，还有failover过程中触发的订阅事件具有很好的参考价值。

   Redis sentinel(哨兵)模块已经被集成在redis2.4+的版本中,尽管目前不是release,不过可以尝试去使用和了解,事实上sentinel还是有点复杂的.
   sentinel主要功能就是为Redis M-S(master,slaves)集群提供了1)master存活检测 2)集群中M-S服务监控 3) 自动故障转移,M-S角色转换等能力,从一个方面说是提高了redis集群的可用性.

    一般情况下,最小M-S单元各有一个maste和slave组成,当master失效后,sentinel可以帮助我们自动将slave提升为master;有了sentinel组件,可以减少系统管理员的人工切换slave的操作过程.

    sentinel的一些设计思路和zookeeper非常类似,事实上,你可以不使用sentinel,而是自己开发一个监控redis的zk客户端也能够完成相应的设计要求.

 

一.环境部署

    准备3个redis服务,简单构建一个小的M-S环境；它们各自的redis.conf配置项中,除了port不同外,要求其他的配置完全一样(包括aof/snap,memory,rename以及授权密码等);原因是基于sentinel做故障转移,所有的server运行机制都必须一样,它们只不过在运行时"角色"不同,而且它们的角色可能在故障时会被转换;slave在某些时刻也会成为master,尽管在一般情况下,slave的数据持久方式经常采取snapshot,而master为aof,不过基于sentinel之后,slave和master均要采取aof(通过bgsave,手动触发snapshot备份).

 

   1)  redis.conf：

 

  1. ##redis.conf  
  2. ##redis-0,默认为master  
  3. port 6379  
  4. ##授权密码，请各个配置保持一致  
  5. requirepass 012_345^678-90  
  6. masterauth 012_345^678-90  
  7. ##暂且禁用指令重命名  
  8. ##rename-command  
  9. ##开启AOF，禁用snapshot  
  10. appendonly yes  
  11. save “”  
  12. ##slaveof no one  
  13. slave-read-only yes  

 

  1. ##redis.conf  
  2. ##redis-1,通过启动参数配置为slave，配置文件保持独立  
  3. port 6479  
  4. slaveof 127.0.0.1 6379  
  5. ##-----------其他配置和master保持一致-----------##  

 

  1. ##redis.conf  
  2. ##redis-1,通过启动参数配置为slave，配置文件保持独立  
  3. port 6579  
  4. slaveof 127.0.0.1 6379  
  5. ##-----------其他配置和master保持一致-----------##  

 

    2) sentinel.conf

    请首先在各个redis服务中sentinel.conf同目录下新建local-sentinel.conf,并将复制如下配置信息.

  1. ##redis-0  
  2. ##sentinel实例之间的通讯端口  
  3. port 26379  
  4. sentinel monitor def_master 127.0.0.1 6379 2  
  5. sentinel auth-pass def_master 012_345^678-90  
  6. sentinel down-after-milliseconds def_master 30000  
  7. sentinel can-failover def_master yes  
  8. sentinel parallel-syncs def_master 1  
  9. sentinel failover-timeout def_master 900000  
 
  1. ##redis-1  
  2. port 26479  
  3. ##--------其他配置同上-------##  
 
  1. ##redis-2  
  2. port 26579  
  3. ##--------其他配置同上-------#   

    3) 启动与检测

   

  1. ##redis-0(默认为master)  
  2. > ./redis-server --include ../redis.conf  
  3. ##启动sentinel组件  
  4. > ./redis-sentinel ../local-sentinel.conf  
    按照上述指令,依次启动redis-0,redis-1,redis-2;在启动redis-1和redis-2的时候,你会发现在redis-0的sentinel控制台会输出"+sentinel ..."字样,表示有新的sentinel实例加入到监控.不过此处需要提醒,首次构建sentinel环境时,必须首先启动master机器.

 

    此后你可以使用任意一个"redis-cli"窗口,输入"INFO"命令,可以查看当前server的状态:

   

  1. > ./redis-cli -h 127.0.0.1 -p 6379  
  2. ##如下为打印信息摘要:  
  3. #Replication  
  4. role:master  
  5. connected_salves:2  
  6. slave0:127.0.0.1,6479,online  
  7. slave1:127.0.0.1.6579,online  
    "INFO"指令将会打印完整的服务信息,包括集群,我们只需要关注"replication"部分,这部分信息将会告诉我们"当前server的角色"以及指向它的所有的slave信息.可以通过在任何一个slave上,使用"INFO"指令获得当前slave所指向的master信息.

 

    "INFO"指令不仅可以帮助我们获得集群的情况,当然sentinel组件也是使用"INFO"做同样的事情.

    当上述部署环境稳定后,我们直接关闭redis-0,在等待"down-after-milliseconds"秒之后(30秒),redis-0/redis-1/redis-2的sentinel窗口会立即打印"+sdown""+odown""+failover""+selected-slave""+promoted-slave""+slave-reconf"等等一系列指令,这些指令标明当master失效后,sentinel组件进行failover的过程.

    当环境再次稳定后,我们发现,redis-1被提升("promoted")为master,且redis-2也通过"slave-reconf"过程之后跟随了redis-1.

    如果此后想再次让redis-0加入集群,你需要首先通过"INFO"指令找到当前的masterip + port,并在启动指令中明确指明slaveof参数:

  1. > ./redis-server --include ../redis.conf --slaveof 127.0.0.1 6479  

    sentinel实例需要全程处于启动状态,如果只启动server而不启动相应的sentinel,仍然不能确保server能够正确的被监控和管理.

 

二. sentinel原理

    首先解释2个名词:SDOWN和ODOWN.

  • SDOWN:subjectively down,直接翻译的为"主观"失效,即当前sentinel实例认为某个redis服务为"不可用"状态.
  • ODOWN:objectively down,直接翻译为"客观"失效,即多个sentinel实例都认为master处于"SDOWN"状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为"不可用",将会开启failover.

    SDOWN适合于master和slave,但是ODOWN只会使用于master;当slave失效超过"down-after-milliseconds"后,那么所有sentinel实例都会将其标记为"SDOWN".

   

    1) SDOWN与ODOWN转换过程:

  • 每个sentinel实例在启动后,都会和已知的slaves/master以及其他sentinels建立TCP连接,并周期性发送PING(默认为1秒)
  • 在交互中,如果redis-server无法在"down-after-milliseconds"时间内响应或者响应错误信息,都会被认为此redis-server处于SDOWN状态.
  • 如果2)中SDOWN的server为master,那么此时sentinel实例将会向其他sentinel间歇性(一秒)发送"is-master-down-by-addr <ip> <port>"指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN...其他sentinel实例做同样的交互操作.配置项"sentinel monitor <mastername> <masterip> <masterport> <quorum>",如果检测到master处于SDOWN状态的slave个数达到<quorum>,那么此时此sentinel实例将会认为master处于ODOWN.
  • 每个sentinel实例将会间歇性(10秒)向master和slaves发送"INFO"指令,如果master失效且没有新master选出时,每1秒发送一次"INFO";"INFO"的主要目的就是获取并确认当前集群环境中slaves和master的存活情况.
  • 经过上述过程后,所有的sentinel对master失效达成一致后,开始failover.

    2) Sentinel与slaves"自动发现"机制:

    在sentinel的配置文件中(local-sentinel.conf),都指定了port,此port就是sentinel实例侦听其他sentinel实例建立链接的端口.在集群稳定后,最终会每个sentinel实例之间都会建立一个tcp链接,此链接中发送"PING"以及类似于"is-master-down-by-addr"指令集,可用用来检测其他sentinel实例的有效性以及"ODOWN"和"failover"过程中信息的交互.
    在sentinel之间建立连接之前,sentinel将会尽力和配置文件中指定的master建立连接.sentinel与master的连接中的通信主要是基于pub/sub来发布和接收信息,发布的信息内容包括当前sentinel实例的侦听端口:

  1. +sentinel sentinel 127.0.0.1:26579 127.0.0.1 26579 ....  

    发布的主题名称为"__sentinel__:hello";同时sentinel实例也是"订阅"此主题,以获得其他sentinel实例的信息.由此可见,环境首次构建时,在默认master存活的情况下,所有的sentinel实例可以通过pub/sub即可获得所有的sentinel信息,此后每个sentinel实例即可以根据+sentinel信息中的"ip+port"和其他sentinel逐个建立tcp连接即可.不过需要提醒的是,每个sentinel实例均会间歇性(5秒)向"__sentinel__:hello"主题中发布自己的ip+port,目的就是让后续加入集群的sentinel实例也能或得到自己的信息.
    根据上文,我们知道在master有效的情况下,即可通过"INFO"指令获得当前master中已有的slave列表;此后任何slave加入集群,master都会向"主题中"发布"+slave 127.0.0.1:6579 ..",那么所有的sentinel也将立即获得slave信息,并和slave建立链接并通过PING检测其存活性.

    补充一下,每个sentinel实例都会保存其他sentinel实例的列表以及现存的master/slaves列表,各自的列表中不会有重复的信息(不可能出现多个tcp连接),对于sentinel将使用ip+port做唯一性标记,对于master/slaver将使用runid做唯一性标记,其中redis-server的runid在每次启动时都不同.

 

   3) Leader选举:

    其实在sentinels故障转移中，仍然需要一个“Leader”来调度整个过程：master的选举以及slave的重配置和同步。当集群中有多个sentinel实例时，如何选举其中一个sentinel为leader呢？

    在配置文件中“can-failover”“quorum”参数，以及“is-master-down-by-addr”指令配合来完成整个过程。

    A) “can-failover”用来表明当前sentinel是否可以参与“failover”过程，如果为“YES”则表明它将有能力参与“Leader”的选举，否则它将作为“Observer”，observer参与leader选举投票但不能被选举；

    B) “quorum”不仅用来控制master ODOWN状态确认，同时还用来选举leader时最小“赞同票”数；

    C) “is-master-down-by-addr”，在上文中以及提到，它可以用来检测“ip + port”的master是否已经处于SDOWN状态，不过此指令不仅能够获得master是否处于SDOWN，同时它还额外的返回当前sentinel本地“投票选举”的Leader信息(runid);

    每个sentinel实例都持有其他的sentinels信息，在Leader选举过程中(当为leader的sentinel实例失效时，有可能master server并没失效，注意分开理解)，sentinel实例将从所有的sentinels集合中去除“can-failover = no”和状态为SDOWN的sentinels，在剩余的sentinels列表中按照runid按照“字典”顺序排序后，取出runid最小的sentinel实例，并将它“投票选举”为Leader，并在其他sentinel发送的“is-master-down-by-addr”指令时将推选的runid追加到响应中。每个sentinel实例都会检测“is-master-down-by-addr”的响应结果，如果“投票选举”的leader为自己，且状态正常的sentinels实例中，“赞同者”的自己的sentinel个数不小于(>=) 50% + 1,且不小与<quorum>，那么此sentinel就会认为选举成功且leader为自己。

    在sentinel.conf文件中，我们期望有足够多的sentinel实例配置“can-failover yes”，这样能够确保当leader失效时，能够选举某个sentinel为leader，以便进行failover。如果leader无法产生，比如较少的sentinels实例有效，那么failover过程将无法继续.

 

    4) failover过程:

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

    A）“+failover-triggered”: Leader开始进行failover，此后紧跟着“+failover-state-wait-start”，wait数秒。

    B）“+failover-state-select-slave”: Leader开始查找合适的slave

    C）“+selected-slave”: 已经找到合适的slave

    D） “+failover-state-sen-slaveof-noone”: Leader向slave发送“slaveof no one”指令，此时slave已经完成角色转换，此slave即为master

    E） “+failover-state-wait-promotition”: 等待其他sentinel确认slave

    F）“+promoted-slave”：确认成功

    G）“+failover-state-reconf-slaves”: 开始对slaves进行reconfig操作。

    H）“+slave-reconf-sent”:向指定的slave发送“slaveof”指令，告知此slave跟随新的master

    I）“+slave-reconf-inprog”: 此slave正在执行slaveof + SYNC过程，如过slave收到“+slave-reconf-sent”之后将会执行slaveof操作。

    J）“+slave-reconf-done”: 此slave同步完成，此后leader可以继续下一个slave的reconfig操作。循环G）

    K）“+failover-end”: 故障转移结束

    L）“+switch-master”：故障转移成功后，各个sentinel实例开始监控新的master。

三.Sentinel.conf详解

 

  1. ##sentinel实例之间的通讯端口  
  2. ##redis-0  
  3. port 26379  
  4. ##sentinel需要监控的master信息：<mastername> <masterIP> <masterPort> <quorum>  
  5. ##<quorum>应该小于集群中slave的个数,只有当至少<quorum>个sentinel实例提交"master失效"  
  6. ##才会认为master为O_DWON("客观"失效)  
  7. sentinel monitor def_master 127.0.0.1 6379 2  
  8.   
  9. sentinel auth-pass def_master 012_345^678-90  
  10.   
  11. ##master被当前sentinel实例认定为“失效”的间隔时间  
  12. ##如果当前sentinel与master直接的通讯中，在指定时间内没有响应或者响应错误代码，那么  
  13. ##当前sentinel就认为master失效(SDOWN，“主观”失效)  
  14. ##<mastername> <millseconds>  
  15. ##默认为30秒  
  16. sentinel down-after-milliseconds def_master 30000  
  17.   
  18. ##当前sentinel实例是否允许实施“failover”(故障转移)  
  19. ##no表示当前sentinel为“观察者”(只参与"投票".不参与实施failover)，  
  20. ##全局中至少有一个为yes  
  21. sentinel can-failover def_master yes  
  22.   
  23. ##当新master产生时，同时进行“slaveof”到新master并进行“SYNC”的slave个数。  
  24. ##默认为1,建议保持默认值  
  25. ##在salve执行salveof与同步时，将会终止客户端请求。  
  26. ##此值较大，意味着“集群”终止客户端请求的时间总和和较大。  
  27. ##此值较小,意味着“集群”在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据。  
  28. sentinel parallel-syncs def_master 1  
  29.   
  30. ##failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，  
  31. ##当前sentinel将会认为此次failoer失败。  
  32. sentinel failover-timeout def_master 900000  
  33.   
  34. ##当failover时，可以指定一个“通知”脚本用来告知系统管理员，当前集群的情况。  
  35. ##脚本被允许执行的最大时间为60秒，如果超时，脚本将会被终止(KILL)  
  36. ##脚本执行的结果：  
  37. ## 1    -> 稍后重试，最大重试次数为10;   
  38. ## 2    -> 执行结束，无需重试  
  39. ##sentinel notification-script mymaster /var/redis/notify.sh  
  40.   
  41. ##failover之后重配置客户端，执行脚本时会传递大量参数，请参考相关文档  
  42. # sentinel client-reconfig-script <master-name> <script-path>  
    更详细信息，请参考src/sentinel.c源码 .配置文件加载过程参见方法：sentinelHandlerConfiguration(..)

Redis Sentinel：集群Failover解决方案（转载）

标签：

原文地址：http://www.cnblogs.com/haifan1984/p/4329675.html
踩
(0)
赞
(0)
   
举报
评论 一句话评论（0）
登录后才能评论！
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
mamicode.com排行更多图片
更多
友情链接
兰亭集智   国之画   百度统计   站长统计   阿里云   chrome插件   新版天听网
关于我们 - 联系我们 - 留言反馈
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码！