阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

Redis高可用之Redis Sentinel

226次阅读
没有评论

共计 7158 个字符,预计需要花费 18 分钟才能阅读完成。

1. Redis 主从配置

1.1. 设置主从复制

Master <= Salve

10.24.6.5:6379 <= 10.24.6.7:6379

 Redis 高可用之 Redis Sentinel

 

1.2.   取消主从复制

 Redis 高可用之 Redis Sentinel

 

1.3.  删除所有数据

flushdb: 删除这个 db 下的。
flushall: 删除所有

 

2. Sentinel 高可用配置

Sentinel 服务器地址:

10.24.6.7

启动

Redis-sentinel sentinel.conf

或者

Redis-server sentinel.conf –sentinel

 

Redis 服务器:

Master <= Salve

10.24.6.5:6379 <= 10.24.6.7:6379

10.24.6.4:6379

10.24.6.6:6379

2.1. Sentinel 客户端:

2.1.1.  Redis-DeskopMaster

 Redis 高可用之 Redis Sentinel

2.1.2.  Redis-cli

 Redis 高可用之 Redis Sentinel

2.2. 查看 Sentinel(info)

 Redis 高可用之 Redis Sentinel

2.3. 添加 redis sentinel

有两种方式,一种是通过配置文件,如何配置参考附录的 sentinel.conf。这种方式主要是面向预配置的 redis 群集。

另外一种方式使用 redis-cli 做热配置:

127.0.0.1:26381> sentinel monitor mymaster 172.18.18.207 6501 1 OK 

命令的格式如下:

SENTINEL MONITOR <name> <ip> <port> <quorum> 

注:quorum 表示发起 failover 需要的 sentinel 数量,看 sentinel 群集的数量决定。

 Redis 高可用之 Redis Sentinel

2.4. 删除 redis sentinel

从 sentinel 中删除群集,命令:172.18.18.207:26381> sentinel remove mymaster OK

Redis 高可用之 Redis Sentinel

2.5.  Sentinel 高可用管理

2.5.1.  查看所有 master

 Redis 高可用之 Redis Sentinel

2.5.2.  查看 master 的 slave

 Redis 高可用之 Redis Sentinel

2.6. Sentinel 高可用客户端选择服务

from redis.sentinel import Sentinel
sentinel = Sentinel([(
‘10.24.6.7’, 26379)], socket_timeout=0.1)
master = sentinel.master_for(
‘10.24.6.5master’, socket_timeout=0.1)
print master
master.set(
‘foo’, ‘bar’)
print master.get(‘foo’)

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

下面关于 Redis 的文章您也可能喜欢,不妨参考下:

Ubuntu 14.04 下 Redis 安装及简单测试 http://www.linuxidc.com/Linux/2014-05/101544.htm

Redis 主从复制基本配置 http://www.linuxidc.com/Linux/2015-03/115610.htm

Redis 集群明细文档 http://www.linuxidc.com/Linux/2013-09/90118.htm

Ubuntu 12.10 下安装 Redis(图文详解)+ Jedis 连接 Redis http://www.linuxidc.com/Linux/2013-06/85816.htm

Redis 系列 - 安装部署维护篇 http://www.linuxidc.com/Linux/2012-12/75627.htm

CentOS 6.3 安装 Redis http://www.linuxidc.com/Linux/2012-12/75314.htm

Redis 安装部署学习笔记 http://www.linuxidc.com/Linux/2014-07/104306.htm

Redis 配置文件 redis.conf 详解 http://www.linuxidc.com/Linux/2013-11/92524.htm

Redis 的详细介绍:请点这里
Redis 的下载地址:请点这里

本文永久更新链接地址:http://www.linuxidc.com/Linux/2016-04/130154.htm

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-22发表,共计7158字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中