思享工具箱

redis哨兵

摘要：
从属服务器）集群提供1）主生存检测2）集群中的M-S服务监控3）自动故障切换，这可以减少系统管理员手动切换从属服务器。Sentinel的一些设计思想与Zookeeper非常相似，但用户开发的用于监控Redis的zk客户端也可以满足相应的设计要求。1.为环境部署准备了三个Redis服务，

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：

Java代码 复制代码收藏代码redis哨兵第3张
  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-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  
Java代码 复制代码收藏代码redis哨兵第3张
  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 6479  
  4. slaveof 127.0.0.1 6379  
  5. ##-----------其他配置和master保持一致-----------##  
Java代码 复制代码收藏代码redis哨兵第3张
  1. ##redis.conf
  2. ##redis-1,通过启动参数配置为slave，配置文件保持独立
  3. port 6579
  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,并将复制如下配置信息.

Java代码 复制代码收藏代码redis哨兵第3张
  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-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  
Java代码 复制代码收藏代码redis哨兵第3张
  1. ##redis-1
  2. port 26479
  3. ##--------其他配置同上-------##
  1. ##redis-1  
  2. port 26479  
  3. ##--------其他配置同上-------##  
Java代码 复制代码收藏代码redis哨兵第3张
  1. ##redis-2
  2. port 26579
  3. ##--------其他配置同上-------#
  1. ##redis-2  
  2. port 26579  
  3. ##--------其他配置同上-------#   

3) 启动与检测

Java代码 复制代码收藏代码redis哨兵第3张
  1. ##redis-0(默认为master)
  2. > ./redis-server --include ../redis.conf
  3. ##启动sentinel组件
  4. > ./redis-sentinel ../local-sentinel.conf
  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的状态:

Java代码 复制代码收藏代码redis哨兵第3张
  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
  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参数:

Java代码 复制代码收藏代码redis哨兵第3张
  1. > ./redis-server --include ../redis.conf --slaveof 127.0.0.1 6479
  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实例的侦听端口:

Java代码 复制代码收藏代码redis哨兵第3张
  1. +sentinel sentinel 127.0.0.1:26579 127.0.0.1 26579 ....
  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详解

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

标签：#sentinel#master#实例#指令#slave | 浏览：284 | 发布日期：

免责声明：文章转载自《redis哨兵》仅用于学习参考。如对内容有疑问，请及时联系本站处理。

上篇navicat for mysql 进行数据传输（转载）Ubuntu 下常用的软件工具下篇

宿迁高防，2C2G15M，22元/月；香港BGP，2C5G5M，25元/月 雨云优惠码：MjYwNzM=

相关文章

mysql主从切换

1、修改配置文件 read-only=1（主库） #read-only=1（备库） 2、查询从库状态 mysql> show processlist ; mysql> show slave status G 3、查询主库状态 mysql> show processlist; mysql> show master status G *...

Redis集群实现分布式锁-RedLock

一、redis集群分布式锁 Redis单节点实现分布式锁 ，如果通过sentinel保证高可用，如果master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况： 1. 客户端1在Redis的master节点上拿到了锁。 2. Master宕机了，存储锁的key还没有来得及同步到Slave上。 3. master故障，发生故障转移，slave节点升...

MySQL同步故障：" Slave_SQL_Running:No" 两种解决办法

进入slave服务器，运行： mysql> show slave statusG Relay_Log_File: localhost-relay-bin.000535 Relay_Log_Pos: 21795072 Relay_Master_Log_File: localhost-bin.000094 Slave_IO_Running:...

Kubernetes 将Pod调度到Master节点

  出于安全考虑，默认配置下Kubernetes不会将Pod调度到Master节点。如果希望将k8s-master也当作Node使用，可以执行如下命令： kubectl taint node k8s-master node-role.kubernetes.io/master- 其中k8s-master是主机节点hostname如果要恢复Master Onl...

ESP8266恢复出厂设置

使用python3对ESP8266恢复出厂设置 1.安装Python库包 pip install esptool 2.恢复出厂设置 首先要确认一下ESP8266所连接的串口号，要以串口号作为指令的参数，如我的设备是在COM3， 我运行的指令就是：esptool.exe --port COM3 erase_flash...

ARM 汇编的mov操作立即数的疑问

1. 因为对arm汇编有些指令还不能理解，特别是一些相似功能指令间的区别。偶然在网上搜到“faq ARM assembly”，其中描述的几个问题还是值得好好研究一下。 2. 慢慢的发现自己也不再害怕英文的文档了，耐心看至少也能懂个大概。大批经典的文章和书籍都是en文的，所以经常看英文文档是一个非常好的习惯。看看GNU的一些reference manual，...

最新文章

随机推荐

思享工具箱导航