Redis Sentinel(哨兵)部署

发布时间:2018-11-15  栏目:NoSQL  评论:0 Comments

 

Redis-sentinel是Redis实例的督查管理、通知及实例失效备援服务,是Redis集群的管理工具。在一般的分布式中心节点数据库被,Redis-sentinel的意向是主导节点的行事,监控各个其他节点的办事状况又进行故障恢复,来加强集群的高可用性。

正文永久地址:https://www.cnblogs.com/erbiao/p/9156215.html

一、Redis Sentinel规划

IP 端口号 角色
192.168.1.51 7000 Redis Master
192.168.1.52 7000 Redis Master
192.168.1.53 7000 Redis Master
192.168.1.51 27000 Sentinel
192.168.1.52 27000 Sentinel
192.168.1.53 27000 Sentinel

一个一致兆多起之Redis系统中,可以运用多单哨兵进行监控任务为保证系统足够稳健。此时,不仅哨兵会又监控主数据库和从数据库,哨兵之间也会见互相监督。在此间,建议大家哨兵至少配备3独,并且采取奇数个哨兵。

 

二、RedisSentinel部署

Redis官方文档
https://redis.io/topics/sentinel\#redis-sentinel-documentation

1、安装Redis

于3大服务器上各自安装Redis。需要专注的是,如果一旦吃Redis设置密码,需要以3只Redis的配置文件被设置同样的密码。

requirepass"Redis-Password"

 

2、设置主从复制

以2单SlaveRedis的部署文件中声明所起属于的主数据库。

 slaveof192.168.1.51 7000

这里要留意一点,如果主数据库设置了密码,需要持有Redis的安排文件中安masterauth”Redis-Password”,包括主数据库。Sentinel可以切换主从数据库,主数据库可能会见成由数据库,因此呢欲安装主数据库密码。

 

3、配置Sentinel.config

  • 创办布局文件
    创造一个sentinel目录,新建sentinel.conf文件(Redis提供了该文件的沙盘)。配置文件内容如下:

##sentinel实例之间的通讯端口

daemonize yes

port 27000

#redis-master

sentinel monitor redis-master 192.168.1.51 7000 2

sentinel down-after-milliseconds redis-master 5000

sentinel failover-timeout redis-master 900000

sentinel parallel-syncs redis-master 2

sentinel auth-pass redis-master 123456

logfile "/data/bd/redis/sentinel/sentinel.log"
  • 布局起说明:

1)daemonize yes

– 以后台过程模式运行

2)port 27000

– 哨兵的端口号,该端口号默认为26379。

3)logfile”/data/bd/redis/sentinel/sentinel.log”

– log文件所在地

4)sentinel monitor redis-master 192.168.1.517000 2


redis-master是主数据的号,考虑到故障恢复后主数据库的地方及端口号会发生变化,哨兵提供了指令可以透过别名获取主数据库的地址与端口号。

– 192.168.1.51
7000也第一布置时主数据库的地址及端口号,当主数据库发生变化时,哨兵会自动更新这个布局,不待我们失去关注。

–2,该参数用来表示执行故障恢复操作前至少用几单哨兵节点同意,一般安装也N/2+1(N为哨兵总数)。

5)sentinel down-after-milliseconds redis-master 1000


如果master在聊秒内无反应哨兵会开开展master-slave间的切换,使用“选举”机制

6)sentinel failover-timeout redis-master 5000


如果在小秒内并未拿宕掉的那尊master恢复,那哨兵认为这是均等次等审的宕机,而解该宕掉的master作为节点选取时可用之node然后等待一定的设定值的毫秒数后又来探测该节点是否恢复,如果恢复就拿它们看做一如既往雅slave加入哨兵监测节点群并在生一样破切换时也外分配一个“选取号”。

Redis Sentinel(Sentinel)用于为Redis提供高可用性,这便代表使用sentinel能创一个故障时莫待人工立即介入修复的条件。此外,sentinel还能兑现其他的功效,如监控,提醒,为客户端提供配置(
monitoring, notifications and acts as a configuration provider for
clients.)

4、Sentinel运行

  • 启动Redis和Sentinel
    配备完Redis和Sentinel之后,按梯次启动各个角色。启动顺序如下:
    Master->Slave->Sentinel,要保管按这顺序依次启动。
    Sentinel的起步命令和Redis类似,终端输入:

redis-sentinel /data/bd/redis/sentinel/sentinel.conf

启动成功后方可由此redis客户端工具查看时Sentinel的音讯,终端输入:

redis-cli -p 27000-h 192.168.1.51 INFO Sentinel

# Sentinel

sentinel_masters:1

sentinel_tilt:0

sentinel_running_scripts:0

sentinel_scripts_queue_length:0

master0:name=redis-master,status=ok,address=192.168.1.51:7000,slaves=2,sentinels=3
  • 查看sentinel日志
    日志路径在配置文件中安,终端输入:

tail -f/data/bd/redis/sentinel/sentinel.log

3273:X 08 Apr 10:44:14.733 # Sentinel runid is 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1

3273:X 08 Apr 10:44:14.733 # +monitor master redis-master 192.168.1.51 7000 quorum 2

3273:X 08 Apr 10:44:14.735 * +slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:44:14.744 * +slave slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:48:12.733 * +sentinel sentinel 192.168.1.52:27000 192.168.1.52:27000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:48:20.533 * +sentinel sentinel 192.168.1.53:27000 192.168.1.53:27000 @ redis-master 192.168.1.51 7000

+slave和+sentinel分别代表成功发现了从数据库暨外Sentinel。

  • 查看sentinel.conf
    再次打开sentinel.conf文件,发现sentinel自动生成了部分信,记录了监督过程中的状态变化。

##sentinel实例之间的通讯端口

daemonize yes

port 27000

#redis-master

sentinel monitor redis-master 192.168.1.51 7000 2

sentinel down-after-milliseconds redis-master 5000

sentinel failover-timeout redis-master 900000

sentinel parallel-syncs redis-master 2

sentinel auth-pass redis-master 123456

logfile "/data/bd/redis/sentinel/sentinel.log"

# Generated by CONFIG REWRITE

dir "/soft/sentinel"

sentinel config-epoch redis-master 0

sentinel leader-epoch redis-master 0

sentinel known-slave redis-master 192.168.1.52 7000

sentinel known-slave redis-master 192.168.1.53 7000

sentinel known-sentinel redis-master 192.168.1.52 27000 ef356da8dadb6a16268d25611942ecf001d5cb2e

sentinel known-sentinel redis-master 192.168.1.53 27000 188fa69f695fd17639ce1ee38592e894d8a14331

sentinel current-epoch 0                         

 

三、Sentinel验证

准事先的步骤我们曾经布置好了3玉Redisnode和Sentinel集群,Redis主数据库也192.168.1.51:7000。

Redis sentinel功能

  ·监控(Monitoring):sentinel会无间歇地检查Redis
master和Redis slave是否正规运作

  ·提醒(Notification):当其中一个受监控之Redis实例出现问题,sentinel能通过API或任何程序通知管理员

  ·自动故障转移(Automatic
failover)
:当Redis
master故障不能够正常办事时,sentinel会故障切换进程,将一个slave提升为master,另外的Redis
slave将更新配备利用初的master,此后发出新连时,会连接到新的Redis master

  ·配置提供者(Configuration
provider)
:Redis充当客户端服务意识的贵来:客户端连接到sentinel,以要时保险的Redis
master地址,若有故障转移,sentinels将告诉新地点

 

1、模拟主数据库故障

此地直接关闭主数据库,终端输入:

redis-cli -p 7000 shutdown

由此一段时间后,我们可见到sentinel.log文件中益了以下内容:

3273:X 08 Apr 10:58:08.330 # +sdown master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.385 # +odown master redis-master 192.168.1.73 7000 #quorum 2/2

3273:X 08 Apr 10:58:08.385 # +new-epoch 1

3273:X 08 Apr 10:58:08.385 # +try-failover master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.388 # +vote-for-leader 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.392 # 192.168.1.52:27000 voted for 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.393 # 192.168.1.53:27000 voted for 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.489 # +elected-leader master redis-master 192.168.1.51 7001

3273:X 08 Apr 10:58:08.489 # +failover-state-select-slave master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.580 # +selected-slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.580 * +failover-state-send-slaveof-noone slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.633 * +failover-state-wait-promotion slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.561 # +promoted-slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.561 # +failover-state-reconf-slaves master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.612 * +slave-reconf-sent slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.517 # -odown master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.576 * +slave-reconf-inprog slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.576 * +slave-reconf-done slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.643 # +failover-end master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.643 # +switch-master redis-master 192.168.1.51 7000 192.168.1.52 7000

3273:X 08 Apr 10:58:10.643 * +slave slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.52 7000

3273:X 08 Apr 10:58:10.643 * +slave slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

3273:X 08 Apr 10:58:15.654 # +sdown slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

+sdown 表示哨兵主观认为数据库下线
+odown 代表哨兵客观认为数据库下线
+try-failover 代表哨兵开始进行故障恢复
+failover-end
代表哨兵完成故障修复,其中包括了牵头哨兵的推选、备选从数据库的选等等较为复杂的过程
+switch-master表示主数据库从51服务器迁移至52服务器
+slave列出了初的主数据库的2单由数据库,而哨兵并没有彻底清除51服务器的实力信息,这是以歇的实例有或会见以将来复,哨兵会被那重新加入进来

Sentinel的分布式特性

  Redis
sentinel是一个分布式系统,可以以一个搭中运行多单sentinel进程,优势如下:

    ·  当多独sentinels确定master不再可用,就展开故障检测,这降低了误报的可能

    ·  当以不同服务器上运行多单sentinel进程,然后以sentinel做集群,即使其中一个故障,也足以展开热切换,降低对客户端的影响,从而升级了系健壮性

    ·  Redis客户端可连续任意sentinel来行使Redis集群

 

2、恢复故障数据库

重新启航192.168.1.51上的Redis数据库,查看sentinel.log文件,日志中多了以下的情:

3273:X 08 Apr 11:19:44.847 # -sdown slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

-sdown 哨兵将下线的Redis实例重新加入,并且作为新的主数据库的自数据库有

关于sentinel版本

  Sentinel当前版为名sentinel
2,它是下更精和另行简约的前瞻算法(在本文档中进行了说明)重写了初期的Sentinel实现。自Redis
2.8本,Redis sentinel发布了安居乐业版本。Redis Sentinel版本1与Redis
2.6一起发布,但已弃用,不建议以

  Sentinel 程序是redis编译安装完成后src目录下之“redis-sentinel”文件

 

启动sentinel

  使用redis-sentinel启动:

    redis-sentinel sentinel.conf

  使用redis-server以sentinel模式启动:

    redis-server sentinel.conf –sentinel

 

布局Redis sentinel前如果打听

  ·  Sentinel运行默认侦听端口26379

  ·  运行sentinel必须指定安排文件,因为系统采取此文件来保存时状态,一整再开sentinel时再加载。指定的布置文件来题目要无点名安排文件,sentinel会拒绝启动;

  ·  至少三只sentinel实例才会升迁系统健壮性,因为电动故障转移时,必须发盈余大多数sentinels存活,且sentinels间能互相通信

  ·  三独sentinel实例应在相对独立的虚拟机,甚至物理机,甚至不同区域

  ·  由于Redis使用异步复制,sentinel+Redis不能够管故障中保留已承认的写入,但但配置sentinel允许丢失有限的写入。另外还有部分安全性比较逊色之安排方式

  ·  使用的客户端要支持sentinel,大多数看好的都支持sentinel,但不是全方位

  ·  没有完全健康的HA设置,所以要是时常以测试环境中测试

  ·  sentinel于docker、端口映射或网络地址转换的条件遭到配置要怪小心:
在重复照射端口的情状下,真实端口可能和转发的端口不同,会毁Sentinel自动发现其余的sentinel进程与master的slave列表。

 

配置sentinel

  Redis安装完成会生成Redis根目录下的sentinel.conf配置文件,最小布置如下:

    bind 0.0.0.0 #侦听地址

    port 26379 #默认侦听端口

    dir /tmp #sentinel工作目录

    sentinel monitor mymaster 127.0.0.1 6379 2

    sentinel down-after-milliseconds mymaster 60000

    sentinel failover-timeout mymaster 180000

    sentinel parallel-syncs mymaster 1

 

    sentinel monitor resque 192.168.1.3 6380 4

    sentinel down-after-milliseconds resque 10000

    sentinel failover-timeout resque 180000

    sentinel parallel-syncs resque 5

 

  仅得指定masters去监控,每个不同的master都该来异之名称
,由于slave是自行发现的,所以无必要指定,且sentinel会自动更新所有slave的状态,信息相当及布置文件,以便在重起动时保留信息。每次进行故障转移,slave被升级也master时,每当发生新sentinel被发觉时,配置都见面于重写。

  上面两组示例配置主要督查两组redis实例,每个实例由一个master和茫然数量的起节点组成,一组实例集合调用“mymaster”,另一样组调用“resque”

 

  Sentinel monitor语法:

    sentinel monitor <master-group-name> <ip>
<port> <quorum>

 

    ·  master-group-name:Redis master实例名称

    ·  ip,port:master IP、master PORT

    ·  quorum:将master判断也失效至少需要N个Sentinel同意,仅用于检测master连接失败。如redis集群中生5独sentinel实例,若此的票数是2,master挂掉,表示有2只sentinel认为master挂掉才会于当是真的挂掉,此时会见触发自动故障转移。其中sentinel集众多被相继sentinel也能经过gossip协议相互通信。这意味在故障中,若大多数sentinel进程之中无法互相通信,自动故障转移将不会见叫点(aka
no failover in the minority partition)

  

  那上述例子第一组Redis实例监控的master叫“mymaster”,连接地址也127.0.0.1:6379,当sentinel集众多中生出2个实例认为mymaster挂掉时,自动进行故障转移。

 

  上述极端小布置中其他选项几乎总是下面形式:

    sentinel <option_name> <master_name>
<option_value>

 

  用于配置以下参数:

  ·  down-after-milliseconds

  若服务器在加的毫秒数以内, 没有回去Sentinel发送的PING命令的回复,或者返回一个不当,
那么Sentinel将这服务器标记为主观下线(subjectively
down,简称SDOWN)。

  不过只是发一个Sentinel将服务器标记为主观下线并不一定会滋生服务器的自动故障迁移:只有以足数量之Sentinel都用一个服务器标记为主观下线后,
服务器才会为记为合理下线(objectively
down,简称ODOWN),这时自动故障迁移才会执行。

  将服务器标记为合理下线所待的Sentinel数量由对master的布置决定

 

  ·  parallel-sync

  选项指定了在实践故障转移时,最多可出稍许只slave同时对新的master进行异步复制(并发数量),这个数字更是聊,完成故障转移所欲的时空哪怕愈长(数字更是聊,同时能够进行复制的slave越少)。

  若slave为装置也允许下过期数据集或无更新的数据集(参见redis.conf中对slave-serve-stale-data选项的印证),那么架构上或许无盼拥有的slave与新master同一时间进行异步复制,因为尽管slave与master间的复制过程绝大部分手续不见面阻塞slave,但slave在载入master发来之RDB文件时,仍然会导致slave在同样不怎么截时日外无克处理命令,如果整slave一起针对新master进行异步复制,那么会造成所有slave在紧缺日外任何请勿可用之场面。

  当然可设置该值为1来担保每次仅出一个slave与新
master进行异步复制,且未克处理命令。

 

  ·  failover-timeout

  故障转移的晚点时间
failover-timeout(默认三分钟)可以就此当偏下这些点:   

    ·  同一个sentinel对同一个master两坏failover之间的间隔时间。
 

    ·  当一个slave从一个错误的master那里异步复制数据开始算时,直到slave被改吧为对的master那里复制数据经常。
 

    ·  当思要取消一个正值展开的failover所需要的年月。    

    ·  当进行failover时,配置有slaves指为新的master所需的最为酷时。不过,即使过了之超时,slaves依然会被正确配置也对master,但是就算非遵循parallel-syncs所安排的条条框框来了

 

  当于Redis实例中开启了requirepass
foobared 授权密码 这样具有连接Redis实例的客户端都使供密码  

  设置哨兵sentinel 连接中心的密码
注意要为主从安同样的征密码
 

    sentinel auth-pass <master-name> <password>

    sentinel auth-pass mymaster MySUPER–secret-0123passw0rd

 

本文档剩余的情节将对Sentinel系统的别样选择进行介绍,
示例配置文件sentinel.conf也对有关的选项进行了整机的诠释。

 

Redis sentinel部署实例

  到目前为止,已经了解了sentinel基本信息,接下将经过一样名目繁多示例来讲学架构中得多少sentinel进程,如何放sentinel进程。首先是有些征:

    ·  Masters表示为:M1、M2、M3…Mn

    ·  Slaves表示为:R1、R2、R3…Rn(R stands for replica)

    ·  Sentinels表示为:S1、S2、S3…Sn

    ·  Clientis表示为:C1、C2、C3…Cn

    · 
当一个实例因Sentinel动作要改角色时,我们把它坐落方括号内,所以[M1]意味着是因为Sentinel干预而成master的实例

 

  要留意的是,最少三只sentinel实例才能够升迁系统健壮性,因为机关故障转移时,必须有剩余大多数sentinels存活,且sentinels间会相互通信

 

  图片 1

 

 

  例一:2个单身系统,2单sentinel,2节点redis集群(1主1起)的状态(不建议之方案)

  图片 2

  ·  此种架构中,若master
M1故障,2单sentinel完全可以尽管故障打成一致,然后授权机关进行故障切换,此时还正常的R1将受提升为master
[M1]

  · 
但,若M1所于的网故障宕机,S1也会停下工作,另一样系统面临运作的sentinel将无法授权故障转移,因此所有Redis集群将无法使用

 

  要专注,多数sentinel存活是不可或缺之,主要回应各异之故障转移现象,然后以新型的布信息发至到其它具有的sentinels。且,在没其余投票协商的景象下,进行机动故障转移是老惊险的:

  图片 3

  上图备受,两系统网络连接出现问题,会起两只意等同的master(假设S2未经投票协商活动进行故障切换),外部客户端会无终止的为少数度写副同时数,自此M1与[M1]获取的数额或许会见发出出入,当网络恢复正常时,Redis实例将无法看清哪份数据是科学的。此也脑裂。因此,至少在三只单身的系面临配置三独sentinel,以此缓解脑裂的问题

 

  例二:3只单身系统,3独sentinel,3节点redis集群(1主2从)的情(能管redis sentinel集群安全的极度基础方案)

  基于3独独立系统,每个系统都运作一个redis进程和sentinel进程

  图片 4

  若master
M1故障,S2和S3会就故障及一致,发起投票,提升一个slave为新master,且活动切换故障,因此客户端能继续呼吁Redis集群

 

  Sentinel和redis进程同也是异步复制,当M1所当系网络出现问题,断开与R2,R3的接连。假设为主写从读架构,那么当M1上确认了之写入请求将无法复制到slave(或者吃提升为master的slave),如下图:

  图片 5

  这,旧的master
M1被网隔离,因此slave R2被升级也master
M2,然而与旧masterM1连接的客户端(如C1)将会见连续写副旧数据。当连接恢复正常后,且旧master
M1将履新配备,成为新master的slave,且丢弃所有数据集,从新master更新数据,如此就丢掉了连续断开期间客户端写副到M1的数码

  使用Redis复制功能选项能化解这个题材,该意义允许以master检测及不再会以写副操作复制到指定数量之slave时止写副操作。

    min-slaves-to-write 1

    min-slaves-max-lag 10

 

    最少及1只slave正常通信且延迟小于10s才能够接受客户端写副操作(复制是异步的,因此不克写副实际上意味着slave已断开连接,或者不发送超过指定max-lag秒数的异步确认)。

    使用这个布局,上例中Redis
旧master M1用于10s后不可用。

    

    但,此布局是如出一辙把双刃剑,当半只slave关掉或者挂掉,master将停接纳写副请求,整个架构将移得特读。

 

  例三:sentinel与客户端运行在一个网

  有时只出少数独服务器可用来运行Redis实例,一兆一于。例二中的配置在这现象被无可用,因此我们用sentinel放在客户端系统上:

  图片 6

  此架构中,sentinel与客户端一样,若大多数客户端都得以看master,那就不曾毛病。C1、C2、C3每当此间代表通用客户端,如rails应用程序或者一个应用程序服务器。

  若M1和S1所于服务器系统挂掉,将起来故障切换,但不同的纱区域将会晤招致差之行,如客户端与Redis服务器中的网络断开,则sentinel将无法升迁slave为新的master,此时Redismaster和Redis
slave都将未可用。

 

  注意:若C3以及M1是运行于平等系统
(hardly possible with the network described above, but more likely
possible with different layouts, or because of failures at the software
layer),有一个看似于例二受到所描述的题材,区别在不见面时有发生脑裂,由于只发平等预告一于,且布局了min-slaves-to-write和min-slaves-max-lag,此时,master必须要能以受write/read请求,否则master与slave断开连接达到自然时间后,master将变的不得写,只可读。

  So this is a valid setup but the setup in the Example 2 has
advantages such as the HA system of Redis running in the same boxes as
Redis itself which may be simpler to manage, and the ability to put a
bound on the amount of time amasterinto the minority partition can
receive writes.

 

  例四:sentinel运行于每个系统,redis集群(一预示一从),两只以层客户端

  若客户端服务器不足3个,那本所讲述的布局于条例三惨遭就非以适用了,此处我们如果杂配置,如下:

  图片 7

  与例三环境类,但此间在四独网都运作了sentinel,若master
M1系统挂掉,其他三单sentinel将执故障切换。理论及可以移除C2、S4,且设置quorum为2,然而此时应用层就见面并未强可用了

 

Sentinel,docker,NAT以及可能的问题

  Docker使用端口映射技术:docker容器中运行的顺序行使的端口可能会见暨爆出的端口不同,这对于当平服务器遭受还要采取同一端口运行多单容器很有因此。

  NAT技术中呢恐怕有端口映射,甚至是IP。

 

  重新照射IP或端口会发出两单问题:

  · 
 sentinel的自发性发现不再工作,因为sentinel通过hello包通告被其它sentinel自己之侦听信息(端口+IP)。Sentinel是力不从心辨认IP或端口是否为重新照射的,因此错误的通知信息用于sentinel间连接会失败。

  ·  Redis
master命令“INFO”输出slave的接连信息,该连信息用于master用于检测远程连接,端口或地点是slave自身广播过来的,然而这端口可能是拂,无法用于master与slave间通信,就比如面一点那么。

 

  在docker环境下,sentinel使用master“INFO”输出信息自动检测slave,检测到的slave将不可达,且sentinel无法为master进行故障切换,因为于sentinel和master的角度看,没有一个slave是健康的。Sentinel也束手无策监督就组运行于docker中之master实例,惟有配置docker为1:1的端口映射

  对于第一个问题,若场景需求要于网络投环境下运作Redis实例或者sentinel实例,你可利用以下简单个sentinel配置来强制sentinel公布一个IP和端口:

    sentinel announce-ip <ip>

    sentinel announce-port <port>

 

  请留意,Docker能够当主机联网模式下运行(请查看–net=host选项为博更多信息)。这该不见面招其他问题,因为以斯设置中莫见面重照射端口。

 

主观下线和合理下线

  Redis中的sentinel有半点个有关下线(down)的定义:

  ·  主观下线(Subjectively Down, 简称
SDOWN)指的是单个Sentinel实例对服务器做出的下线判断。

  ·  客观下线(Objectively Down, 简称
ODOWN)指的凡大抵只Sentinel实例在对同一个服务器做出SDOWN判断,
并且通过SENTINEL is-master-down-by-addr 命令互相交流之后,
得发的服务器下线判断。(一个Sentinel可以通过为其它一个Sentinel发送“SENTINEL
is-master-down-by-addr”命令来询问对方是否认为给定的服务器就下线)

 

  若一个服务器无当“master-down-after-milliseconds”选项指定时间外,对向他发送“PING”的sentinel返回一个有效恢复(valid
reply),那么sentinel会将此服务器标记为主观下线(SDOWN)

  服务器对PING命令的有效恢复可以是三栽被之同等种植:

    ·  返回+PONG

    ·  返回-LOADING错误

    ·  返回-MASTERDOWN错误

  除本条三栽外的复原或者指定时间外无恢复,sentinel都见面标记该服务器恢复无效(non-vaild)

 

  注意,一个服务器必须以“master-down-after-milliseconds”周期时(毫秒)返回无效回复才见面被sentinel标记为主观下线,如一旦“master-down-after-milliseconds”为30000ms(30s),只要服务器在各个29秒之内返回至少一坏有效恢复,此服务器即见面于认为处于正常状态。

  从主观下线状态切换到成立下线状态并没行使严格的合法人数算法(strong
quorum algorithm),而是使了流言协议:如果Sentinel在加以的工夫限制外,
从旁Sentinel那里接收至了足足数量的master下线报告,
那么Sentinel就见面用master的状态从主观下线改变为合理下线。
如果下外Sentinel不再报告master已下线, 那么客观下线状态就会见于移除

  成立下线条件只是适用于**master:对于任何其它品类的Redis实例,Sentinel在拿它们判断也下线前无需要展开商谈,所以slave或者其它Sentinel永远不会见落得合理下线条件**

 

故障转移流程

  分为两部分,第一部分选出sentinel
leader,第二有些开展故障转移:

  1、sentinel集众多被的一个sentinel发现master疑似下线,标记该master的状态也主观下线(SDOWN)【sentinel节点会各国1s为master发送PING信息,若一个服务器并未于“master-down-after-milliseconds”选项指定时间内,对通往外发送“PING”的sentinel返回一个卓有成效恢复(valid
reply),那么sentinel会将这服务器标记为主观下线(SDOWN)】

  2、选出sentinel
leader。该sentinel查看自己发生无投于其它sentinel节点票,若曾投过,那么当个别加倍故障转移超时时间外未会见化leader,则易身份呢follower;没有投了票则申请成为leader(Candidate)。【Sentinel集群正常运作时,每个节点epoch(版本号,具体是什么翻看本章上下文)相同,当得故障转移时会于sentinel集众多被选出leader,由leader发起并施行故障转移操作。Sentinel采用Raft协议落实了Sentinel间选举Leader的算法(不过呢非全等同,具体参看http://weizijun.cn/2015/04/30/Raft协议实战的Redis%20Sentinel的选举Leader源码解析/),Sentinel集群故障转移完成后,所有Sentinel又会卷土重来平等。Leader仅仅是故障转移操作才见面出现的角色】

  3、Candidate(申请成为leader的sentinel节点)此时创新故障转移状态吧“start”,使目前epoch自增1(进入新的推周期),给自己投同批和向任何sentinel节点请求投票等

  4、Candidate不断统计自己的票数,当及一半且过其部署的quorum的票数,那么其就变成Leader(若以一个选举时间内,Candidate没有赢得过一半还过它部署的quorum的票数,此次选举失败,那么以设定的故障迁移过时间的星星倍增后,
重新尝试当选)

  5、sentinel leader迭代所有的sentinel
follower节点,检测是否要以该master标记为客体下线(ODOWN)状态,是虽然继续,否则取消公推投票

  6、选出合适的slave,sentinel leader使用以下流程来挑选合适的slave:

    a、 ·在故障master属下的slave当中,
那些被记为主观下线、已断线、或者最后一赖恢复PING命令的光阴大于五秒钟的slave都见面为裁

      ·在故障master属下的slave当中,
那些和失效master连接断开的时长超过 down-after
选项指定的时长十倍的slave都见面叫淘汰

    b、选择“slave-priority”(slave优先级)最高的slave,存在则选择该slave成为新master,存在一样优先级则连续朝下

    c、复制偏移量(replication
offset,即复制数据极其完全)最酷之异常slave作为新master,存在同样复制偏移量则连续朝下

    d、选择“run_id”(“INFO SERVER”查看)最小的slave

  7、sentinel leader向受选中的slave发送命令“SLAVEOF NO
ONE”,提升选中的slave为master

  8、通过发布和订阅功能,将创新后底部署传播给所有其他Sentinel,
其他Sentinel对它们自己之布置进行翻新

  9、向曾下线master的slave发送“SLAVEOF”命令,让其由新master复制数据

  10、当有着slave都早就开复制新master时,sentinel leader
终止这次故障迁移操作,所有Sentinel又会回升平等身份

 

  每当一个 Redis
实例被重新配置(reconfigured) ——
无论是被装成master、slave、又或叫安装成另外master的slave
——Sentinel都见面朝着被重新配置的实例发送一个 CONFIG REWRITE 命令,
从而确保这些配置会持久化在硬盘里。

 

  S**lave优先级**

  Redis实例有配备参数“slave-priority”,此参数在“INFO”中也克查询,sentinel使用这个布局从slave来抉择故障切换后底初master:
       

    ·  “slave-priority”设置为0的slave,不能够提升为master

    · 
优先级小之salve会优先考虑提升也master。如master有2单slave(S1,S2),优先级S1啊10,S2为100,若master故障且S1,S2都可用,则S1拿凡新master首选

 

  S**lave选举**

  当一个sentinel
leader实例准备展开故障转移,由于master处于ODOWN状态,且sentinel
leader从曾经清楚之大部分sentinel实例收到故障转移授权,此时一个宜的slave就要被选举出来。slave选举考量以下几件:

    ·  与master断开时间

    ·  slave优先级

    ·  复制偏移量

    ·  运行ID

 

  一个Slave若被发现及master断开连接的时空过master配置的过期时间(down-after-milliseconds选项)的十加倍,加上从正履行故障转移的sentinel
leader角度看master不可用的工夫,将让认为是无得当的都会于超了。

  即slave若无可用时过以下时,会被当是免入成为master的节点:

    (down-after-milliseconds * 10) +
milliseconds_since_master_is_in_SDOWN_state

 

  通过了以上测试的slave会继续拓展以下筛选:

    1、然后照slave配置文件被“slave-priority”的轻重缓急进行排序,数字略且未为0的slave将被增选为新master

    2、若“slave-priority”相同,则检查slave的复制偏移量,偏移量大(从旧master接收到还多之多寡)的会晤给增选也新master

    3、若多单slave有同一之优先级和复制偏移量,则则选择“run_id”(INFO
SERVER可以翻相)小的slave成为新master

 

  在**Redis集群中,若有适量的机械当slave,强烈建议将那先级数配置小一些,使其事先级赛一些**。此外,复制偏移量相同之景况并无少见,且独具的redis实例都足以运作于默认“run_id”上,想想多么可怕…

 

 

每个sentinel都要定期执行之职责

  · 
每个Sentinel以各级秒钟一赖的效率为其所掌握的master、slave以及另外Sentinel实例发送一个PING命令。

  ·  如果一个实例(instance)距离最后一涂鸦有效恢复PING命令的年华超过
down-after-milliseconds 选项所指定的值,
那么这个实例会给Sentinel标记为主观下线。
一个实惠恢复可以是:+PONG、-LOADING或-MASTERDOWN

  ·  如果一个master被记为主观下线,
那么在监控之master的保有Sentinel要因为各秒一破的效率肯定master的确进入了主观下线状态

  ·  如果一个master被记为主观下线,
并且有足够数量之Sentinel(至少要达成布局文件指定的数额)在指定的年月限制外允许这等同判定,
那么这master被标记为客体下线

  ·  以一般景象下, 每个Sentinel会以各级 10
秒一坏的频率为它曾解的享有master和slave发送 INFO 命令。
当一个master被Sentinel标记为合理下线时,Sentinel向下线master的具备slave发送INFO命令的频率会由10秒一糟反呢各秒一糟

  · 
当没有足够数量的Sentinel同意master已经下线master的合理下线状态就会给移除。
当master重新向Sentinel的PING命令返回有效恢复时,
master的主办下线状态就会见被移除

 

“-BUSY”状态处理

  当Lua脚本运行时刻越配置的Lua脚本时限时,Redis实例将回到“-BUSY”错误,在触及故障切换前,Redis尝试发送一个“SCRIPT
KILL”命令尝试杀死脚本执行过程,若脚论只有念(the script was
read-only),命令将履行成功。若该实例在尝后遵处于错误状态,实例将开展故障切换

 

速教程

  接下,将日趋介绍所有关于sentinel
API,配置和语义。同时,本节也拿会介绍如何布置3个sentinel实例并跟之并行。

  此处设3独实例运行在端口5000,5001,5002,且有redis集群一兆一起,分别运行在端口6379,6380,然后这些端口全部侦听在一个机器的127.0.0.1环抱地址

 

  3个sentinel配置类似:

    port 5000

    sentinel monitor mymaster 127.0.0.1 6379 2

  sentinel down-after-milliseconds mymaster 5000

  sentinel failover-timeout mymaster 60000

  sentinel parallel-syncs mymaster 1

 

  其他两单sentinel配置修改端口为5001,5002即可

 

  以上:

  · 
Master实例组定义也mymaster。依据不同之master实例组名称,sentinel能而且监控不同的Redis主从集群

  ·  quorum设置为2,sentinel monitor配置指令的尾声一个参数值

  · 
down-after-milliseconds值为5000ms,即5s,因此如果在就段日子从没收到master的ping回复,master就会被肯定为连失败

 

  启动sentinel会收到Redis集群登录信息:

    +monitormastermymaster 127.0.0.1 6379 quorum 2

  

    此吧sentinel事件信息,也可是使“发布/订阅”接收这看似事件。在故障检测和故障转移期间,sentinel会生成并记录不同的风波

 

  查询sentinel中master的状态

    redis-cli -p 5000Sentinelmaster mymaster

     1) “name”

     2) “mymaster”

     3) “ip”

     4) “127.0.0.1”

     5) “port”

     6) “6379”

     7) “runid”

     8) “8f315c998236a332cb327e6c33e5efead00f14c9”

     9) “flags”

    10) “master”

    11) “link-pending-commands”

    12) “0”

    13) “link-refcount”

    14) “1”

    15) “last-ping-sent”

    16) “0”

    17) “last-ok-ping-reply”

    18) “368”

    19) “last-ping-reply”

    20) “368”

    21) “down-after-milliseconds”

    22) “30000”

    23) “info-refresh”

    24) “2704”

    25) “role-reported”

    26) “master”

    27) “role-reported-time”

    28) “1318596”

    29) “config-epoch”

    30) “2”

    31) “num-slaves”

    32) “1”

    33) “num-other-sentinels”

    34) “2”

    35) “quorum”

    36) “2”

    37) “failover-timeout”

    38) “180000”

    39) “parallel-syncs”

    40) “1”

 

    一些关键信息:

    · 
num-other-sentinels为2,表示sentinel检测到其他两单sentinel。在日记中呢会看+sentinel生成的波

    · 
flags只出master,若master挂掉,那可以在当下张s_down或o_down标记

    ·  num-slaves为1,表示sentinel检测到有一个slave连接到master

 

    sentinel查看slave信息

      sentinel slaves mymaster

 

    查看sentinel信息

      sentinel sentinels mymaster

 

    获取当前master的地址

      SENTINEL get-master-addr-by-name mymaster

  故障转移测试

  这,sentinel测试环境已部署好,可以临时关张master并检讨部署是否有转移,可以吃master暂停300s:

    redis-cli -p 6379 DEBUG sleep 300

 

  此命令将master休眠300s,模拟了master故障无法连接的景况。此时查sentinel日志,能顾有关操作:

    ·  每个sentinel检测到master +sdown事件

    ·  事件后来晋级至+odown,意味着多单sentinel确认master不可达

    ·  sentinel投票支持将开行第一不行故障转移尝试的sentinel

    ·  开始故障转移

    ·  …

 

  这复询问master地址信息,会沾不同之复原:

    127.0.0.1:5000>Sentinelget-master-addr-by-name mymaster

    1) “127.0.0.1”

    2) “6380

 

Sentinel和Redis认证

  当master增加安全性为布置为需要客户端密码进行连续时,slave也要明白该密码,以便master与slave用于异步复制协议的中心连接。

  使用以下指令配置密码:

    · 
requirepass在master中配置,配置后可包不处理未验证客户端的呼吁

    · 
masterauth在slave配置,以便slave与master进行身份验证,正常的复制数据

 

  当以sentinel模式时,架构中连无单独来一个master,那么根据sentinel机制,故障转移后,slave会改变角色变成新master,旧master恢复正常后会见成为新master的slave,因此上述配置要以所有Redis集群中实例配置,不论是master还是slave。

 

  然而,在少数景下,我们兴许要谋个slave节点不需说明就只是被客户端读取数据,可以由此设置此slave优先级也0,来避免欠slave升级吗master,且只配备“masterauth”,此时即令不过实现未经身份验证的客户端读取数据

 

  为了使sentinel能正常连接到布置了“requirepass”的Redis实例,sentinel必须配备“sentinel
auth-pass”指令,格式如下:

    sentinel auth-pass <master-group-name> <pass>

 

sentinel客户端实施

  Sentinel需要鲜明的客户端支持,除非系统部署也推行将装有请求透明重定向到新的主实例(虚拟IP或其它类似系统)的台本。Sentinel客户端指南遭到介绍了客户端库实现之主题

 

Sentinel API

  Sentinel提供一个API来检查其状态,检查为监控master和slave的周转状态,订阅以获得一定通知,并于运转时重改sentinel配置

  默认sentinel侦听在TCP端口26379(6379凡是Redis
master和Redis
slave端口),sentinel使用redis协议通信,因此可下redis-cli与sentinel进行互动

  可以一直从sentinel的监督信息遭到翻Redis实例状态,也克查询到其它sentinel的消息等,同时,使用PUB/SUB可
从sentinel接收推送通知,如故障转移要入错误状态的实例,都可以进行推送。

 

Sentinel命令

  以下是命令列表,但未包修改sentinel配置的授命(稍后介绍)

    PING #返回PONG

    SENTINEL masters #亮所有为监控之master集齐状态

    SENTINELmaster<master name> #显示指定的master的状态信息

    SENTINEL slaves <master name>
#展示指定的master的slave状态信息

    SENTINEL sentinels <master name>
#亮指定master的sentinel状态信息

    SENTINEL get-master-addr-by-name <master name>
#展示指定名称master的IP和PORT,若master在进行故障切换或被终止,则回给升级也master的slave的IP和PORT

    SENTINEL reset <pattern> #重置所有包含关键字之master。
“pattern”参数是一个大局风格的模式。重置进程会破master所有先前保存的状态(包括正在进行故障切换),且删除已意识并与master关联的每个slave及其状态

    SENTINEL failover <master name>
#手动强制故障切换,当master失效时,在非了解外Sentinel意见的事态下,
强制开始同潮活动故障迁移(不过发起故障转移的Sentinel会向任何Sentinel发送一个初的部署,其他Sentinel会根据这个布局进行相应的翻新)

    SENTINEL ckquorum <master name>
#检查时sentinel的配备能否达成故障切换master所需的数量,执行这命令也会检测外多数sentinel是否正常(检测是否在线,以及是否能授权故障切换)。斯命令应在sentinel中用于检测sentinel部署是否正规

    SENTINEL flushconfig
#强制sentinel将运行时布置写副磁盘,包括目前sentinel状态。一般,sentinel每次在其状态改变时都见面重写配置(在sentinel状态信息让持久化到磁盘后重新开)。然而,有时见面冒出布局文件少的情况,如操作失误,磁盘故障,软件包升级或者部署管理器而招致配置文件少。此时,强制sentinel重写配置文件就好必要了,也殊便宜(老的布局文件少不会见潜移默化该令的实践)

 

运转时修改配置文件

  从Redis
2.8.4本开始,sentinel提供一个API来添加、删除或重改master的布置。注意:若发生差不多只sentinel,你当手动把所有的改动同步到其他Redis
sentinel实例中,意思是改单个sentinel配置,不见面自行将改变同步到网络被的sentinels。

  以下是sentinel用于创新sentinel实例配置的下令列表:

    SENTINEL MONITOR <name> <ip> <port>
<quorum>
#夫命令通知sentinel开始监控一个新的master,且指定其名目,ip,port,quorum,与sentinel.conf配置文件里“sentinel
monitor”指令语法类似,不同之是你免克以主机名代替IP,只能利用IPv4或IPv6地址

    SENTINEL REMOVE <name>
#移除指定master:这个master将由sentinel监控列表移除,将起sentinel的里边状态信息遭到全解除,sentinel,masters也无力回天列有拖欠master

    SENTINEL SET <name> <option> <value>
#以及“CONFIG
SET”命令相似,用于转移一定master的布局参数。指定多“option/value”对凡可以的(单对吧是足以的);sentinel.conf里有着可配备参数都得以用SET命令进行布置。

 

  以下是SENTINEL
SET命令的一个示范,用于修改所down-after-milliseconds调用的主设备的布置objects-cache:

    SENTINEL SET objects-cache-master down-after-milliseconds 1000

 

  如前所述,sentinel
SET可用来所装有配置文件中唯独部署的部署参数,此外,他会于无另行添加master(先SENTINEL
REMOVE再SENTINEL MONITOR)的状下,修改quorum:

    SENTINEL SET objects-cache-master quorum 5

 

  请留心,由于SENTINEL
MASTER以简要解析格式(作为字段/值对数组)提供所有配置参数,因此并未一样的GET命令

 

添加/删除sentinel

  基于sentinel自动发现体制,添加一个初sentinel是非常简单的。你得独自是开行新的sentinel,配置危机监控时所有移动的master,10s内sentinel将获任何sentinel列表及于监控master的保有slave信息

 

  而要补充加多只**sentinel**

  提议一个一个丰富,等待其他sentinels已经会及新sentinel通信,再补充加下一个。新增sentinel有或破产,一个一个添加sentinel能有效担保大多数sentinel都是常规的(若一次性增长的sentinel数量过现有sentinel数量,并且增长出现问题,可能会见招致现有sentinel出现问题)。一般的各国30s添加一个sentinel是于常见的。

  添加了晚,可用命令“SENTINELmastermastername”检查有sentinel是否早已全取得到有master的信

 

  删除**sentinel比较复杂**

  即受删去的sentinel很丰富日子无法访问,sentinels不会见全盘排除已经上加过的sentinels信息,因为一旦尽量减少其他sentinel的布局版本的换代,删除sentinel也发或引起故障转移

  因此为了移除一个sentinel,在尚未网络隔离的景象下答应按照以下步骤:

    1、停止要抹的sentinel进程

    2、执行命令“SENTINEL
RESET
*”,向所起另外sentinel实例发送命令重置状态信息(*代表重置所有master,也可指定master名称)。信息会一个一个的更新,大概要30s

    3、执行命令“SENTINELmastermastername”检查每个sentinel显示的sentinel数量是否一致

 

  删除旧的master或无法无法访问的slave

  Sentinel不见面了打消指定master的slave,即使slave长时间无法访问。在故障转移后,一旦旧master再次可用,会自行变成新master(旧slave)的slave,此时,新master和新slave会组成新的复制架构。

  若想从sentinel监控的master/slave列表里永远删除一个slave(可能是旧master),在住slave进程后,你要向装有sentinel发送命令“SENTINEL
RESET mastername”,重置mastername所有状态信息

 

Pub/Sub消息

  客户端好拿sentinel看做一个独自供了订阅功能的Redis服务器,不能够应用PUBLISH命令向这个服务器发送信息,但但应用“SUBSCRIBE”命令或“PSUBSCRIBE”命令,通过订阅给定的频段来博取相应的事件提醒。

一个频道能接纳和斯频道称一致之轩然大波,如称吧+sdown的频道就只是吸纳有实例进入主观下线(SDOWN)状态的波

 

  通过实践“PSUBSCRIBE
*
”命令能收有事件信息。

 

  以下是会动用此API接收的频段和信息格式的列表。第一单英文单词是频道/事件之称谓,其余是数量格式。

  注意,当格式中带有“instance
details”时,表示频道所返信息遭到寓了以下用于识别目标实例的始末:、

    <instance-type> <name> <ip> <port> @
<master-name> <master-ip> <master-port>

 

  “@”字符串后的情指定master(即@到终极部分,此有是可选的),仅于“@”字符之前的情节指定的实例不是master时使用。

    · +reset-master <instance details> #master就被重置

    · +slave <instance details>
#一个新slave已让sentinel识别并涉及

    · +failover-state-reconf-slaves <instance details>
#故障转移状态切换至了reconf-slaves状态

    · +failover-detected <instance details>
#另外一个sentinel开始了扳平不善故障转移操作,或一个slave转换成为了master

    · +slave-reconf-sent <instance details>
#领衔(leader)的sentinel向实例发送了命“SLAVEOF”,为实例更设置新的Redis
master

    · +slave-reconf-inprog <instance details>
#实例正在将团结安装为master的slave,但对应的协同过程仍无就

    · +slave-reconf-done <instance details>
#slave已成功完成对新master的一起

    · -dup-sentinel <instance details>
#本着深受定master进行监控之一个或者多单sentinel已经因又出现而让移除(当sentinel实例更开时会起这个种状态)

    · +sentinel <instance details>
#master有新sentinel被辨认并累加

    · +sdown <instance details>
#点名实例现处于主观下线Subjectively Down状态

    · -sdown <instance details>
#指定实例现不再处于主观下线状态

    · +odown <instance details>
#指定实例现居于合理下线(Objectively Down)状态

    · -odown <instance details>
#点名实例现不再处于合理下线状态

    · +new-epoch <instance details>
#Slot的版本号或者信息之版本号已受更新。节点如何判断接受的集群消息是比新的。Redis中行使本号机制来判断消息的初老,版本号越强意味着消息越来越新。在Redis中这种版本号为叫作configEpoch,每个节点都发出一个configEpoch,它是一个64号之平头。其实configEpoch更应当受称为是Slot的版本号,或者有Slot与节点映射关系的版本号。怎么掌握也?我们打信冲突之角度看之题材,因为configEpoch就是为了解决消息冲突之嘛。如上文所说汇众多被每个节点都见面维护一客集群状态快照。快照中每个Slot都起一个和之对应之节点,每个节点都来一个configEpoch,所以直观上configEpoch就如是Slot的版本号。当有一个节点负责的Slot有浮动之时光,节点会更新自己的configEpoch,并乘胜集群心跳传播该信息,集群消息是同等层层Slot、节点和configEpoch组成的三元组。当新的集群消息传开及任何节点的时候,节点会对比节点本身和集群消息中对应Slot的configEpoch来决定是否更新本地集群状态快照,从这层含义及看configEpoch也再符合为称作Slot的版本号或者信息之版本号。

    · +try-failover <instance details>
#凑巧于进展新的故障转移,正处在等候多数选状态

    · +elected-leader <instance details>
#博指定版本的选出,可以拓展故障迁移

    · +failover-state-select-slave <instance details>
#故障转移操作现处于“select-slave”状态,sentinel正以查找一个会叫提升为master的slave

    · no-good-slave <instance details>
#sentinel未找到适当的slave去提升。Sentinel会在一段时间后重试,但是当这种状况下,可能会见转移状态机并终止故障切换

    · selected-slave <instance details>
#sentinel找到适当的slave去提升

    · failover-state-send-slaveof-noone <instance details>
#sentinel正以言语指定的slave提升为master,等待功能升级好

    · failover-end-for-timeout <instance details>
#故障转移因超时而中止,不过最终具备slave都见面开复制新master(slaves
will eventually be configured to replicate with the newmasteranyway)

    · failover-end <instance details>
#故障转移操作顺利完成,所有slave开始打新master复制数据

    · switch-master <master name> <oldip>
<oldport> <newip> <newport>
#master连接配置变更,外部客户端都关注的音

    · +tilt #进入tilt模式

    · -tilt #退出tilt模式

 

自动发现Sentinel和slave

  哨兵及其他哨兵保持联系,以便互相检查对方的可用性,并拓展信息置换。无须为运行的每个Sentinel分别设置任何Sentinel的地址,
因为Sentinel可以经过颁布暨订阅功能来机关发现在监控相同master的旁Sentinel,
这无异效应是由此为频道 sentinel:hello 发送信息来促成的。

  同这类似, 你吧不必手动列出master属下的有着slave,
因为Sentinel可以透过询问master来获得有slave的信。

    ·  每个Sentinel会以每半秒一不好的频率,
通过颁布暨订阅功能,向受它们监控之具有master和slave的 sentinel:hello
频道发送一漫漫信息,信息遭含了Sentinel的 IP 地址、端口号及周转 ID
(runid)。

    ·  每个Sentinel都订阅了吃它们监控之有着master和slave的
sentinel:hello 频道, 查找之前不出现了之Sentinel(looking for unknown
sentinels)。当一个Sentinel发现一个新的Sentinel时,
它会将新的Sentinel添加暨一个列表中, 这个列表保存了Sentinel已清楚之,
监控同一个master的具有其他Sentinel。

    ·  Sentinel
发送的信息被尚连完整的master当前配备(configuration)。
如果一个Sentinel包含的master配置于任何一个Sentinel发送的配置要旧,
那么这Sentinel会立即升级至新布局高达。

    · 
在用一个初Sentinel添加到监督master的列表上面之前,Sentinel会先反省列表中是否都包含了和而长的Sentinel拥有同样运行
ID 或者千篇一律地点(包括 IP 地址与端口号)的Sentinel,
如果是的话,Sentinel会先转移除列表中既部分那些有相同运行 ID
或者千篇一律地点之Sentinel,然后又添加新Sentinel。

 

Sentinel在非故障转移的景况下对实例进行重新配置

  即使没活动故障迁移操作以展开,sentinel总会尝试用眼前安排利用至让监督的实例上,特别是:

    · 
依据当前配备,若一个slave被提升为master,那他会见成为旧master原有slave的复制对象,连接了左master的slave会被重新配置,以便能打对的master获取数据

    ·  旧master挂掉重新上线后,会于安排也新master的slave

  不过, 在上述这些规范满足今后,sentinel在针对实例进行重新配置之前还是会等待一段子足够长的时光,
确保可以收到到另外sentinel发来之布更新,
从而避免自己为保存了晚点的部署而针对实例进行了不必要的重新配置

 

算法和内部结构

  Quorum

  如前所述,每个被sentinel监控的master都配置了quorum,指定要针对master的不可达性或故障达一致的sentinel数量,以便触发故障转移。另外,网络问题导致架构间产生网络分区,此时故障转移绝不见面当单发生略部分的Sentinels存在的大网分区中实行,只见面在多数sentinels存在的网络分区中履行

 

  简单的游说即使是:

    · 
quorum:为了将master标记为ODOWN,需要发现并确认错误的sentinel数量

    ·  故障转移在ODOWN状态让触发

    · 
一旦故障转移给硌,尝试进行故障转移的sentinel会请求大多数sentinel的授权(在quorum为多数的事态下)

 

  如,架构中起5只sentinel
实例,quorum为2,那么至少2个sentinel确认master不可达后,故障转移才见面吃触发,然后能够实施故障转移的仅发内一个sentinel。

  若quorum为5,则拥有sentinel都必须就master故障达成一致,且行故障转移的sentinel
leader要落有sentinel的授权才能够展开故障转移。

 

  这表示quorum可出零星种方法调动sentinel:

    · 
若quorum设置为小于部署之大部sentinel的数据,此时sentinel对master故障更加灵敏,且要少数的sentinel无法和master通信就见面硌故障转移

    · 
若quorum设置也大于部署的大部sentinel的数额,此时只有大多数sentinel都认可master故障时,sentinel
leader才会开故障转移

 

  配置版本号(epoch)

  为了开故障转移,Sentinels
leader需要由大多数sentinel得到授权,原因:

  当一个Sentinel
leader被授权,它会否故障转移后的新master获得一个唯一性的epoch,用来号故障转移完成后sentinels的新部署版本号,另外,只有承认了master故障的绝大多数sentinel才能够博得此版本号。这意味着,每次故障转移的布都见面更新一个无比的本子号,这非常要紧,后面会说为什么这样重要。

  此外Sentinels有编制:若一个sentinel为故障转移一个初master而投票给任何sentinel,它以等一段时间再次尝试故障转移这个master,在sentinel.conf中但是配备是延迟时间failover-timeout。这意味Sentinels在平之时光外不会见尝试故障转移相同的master,第一不良呼吁授权成功后会尝试,失败则其它一个sentinel将会当一段时间后尝,类推。

 

  Redis Sentinel保证了活性(liveness)特点:如果大多数Sentinels
能够互通信,master故障,最后得会发出一个sentinel会受授权开始故障转移。

  Redis
Sentinel同也保了安全(safety)特点:一软故障转移中,每个Sentinel故障转移和一个master将采取不同的epoch版本号,失败后由另外的sentinel会重新转唯一的epoch版本号,然后发起故障转移;而首先潮变的epoch版本号因为没故障转移成功而抛开,生成的布局也未是最后配置为会见吃废弃

 

故障转移成功后,最终配置的传入

  一旦sentinel leader
故障转移成功,他拿开始播放新的部署,以便其他sentinels更新新master的音信。

  为了确认故障转移是否中标,sentinel需要能够发送命令“SLAVEOF
NO
ONE”给拥有参与选举的slave,稍后,切换为新master的音可知以“INFO”输出中形。

  这,即使slave正在更新配备,故障转移也给判定为打响,且持有Sentinels需要开始报告新的配备。

  Sentinel
leader传播新安排的缘由是每个sentinel每次进行已授权的故障转移时,都见面生出不同之绝无仅有的配置版本号,最终有sentinel会共享一个安排版本号。

   每个sentinel使用redis
订阅/发布意义为具有的master/slave连续地播报其监督之master的版,同时兼有的sentinel也会见待来自其它sentinel广播的音。

   配置在__sentinel__:hello发布/订阅频道中让广播。

  每份配置都有不同之本子号,而那个的版本号总是大了多少的版号,版本号越怪,越接近尾声之配备版本,越来广播的意思。

   如,初始配置时,所有sentinels都抱有版本号为1之配置,即mymaster的配置为192.168.1.50:6379,一段时间后发出故障转移,生成配置版本号2,若转移成功,他拿播放新的安排,即192.168.1.51:9000,其他sentinel实例收到此布局的广播会更新的自己的布置,因为这安排有再度强的版本号。

  也就是说,sentinel有第二单活性特点:一个可知相互通信的sentinel集群,在故障转移时,都见面尝试更新版本更胜之布局。

  一般如果网络故障产生网络分区,每个分区的sentinel都见面尝试收敛到再也强版本的布,没有网络分区时,所有sentinel都见面更新配备

 

 

  网络分区下的一致性

  Redis sentinel配置保证最终一致性,产生网络分区时,每个分区都见面尝试收敛到再也胜似版本的可用配置。

  使用sentinel时,有三栽角色:

    ·  Redis实例

    ·  Sentinel实例

    ·  Client

 

  也定义整个架构体系的行事,我们只要考虑到上述三栽角色,以下网络被发生3单节点,每节点运行一个Redis实例和sentinel实例:

  图片 8

  于斯系统的启状态被,Redis3是master,Redis2和Redis3是slave。此时网络故障造成旧master与另外节点隔离,sentinel
1和 2开始同轱辘故障转移,提升redis1为新master。

 

  这,Sentinel的机制确保了sentinel
1和 2持有master的新式部署,然而sentinel
3在隔离分区中依然具有旧的配备,我们掌握sentinel
3会当网络恢复时收获新的布,但要是发生客户端在网络故障时看原本master,会起啊?

  这客户端还是会在Redis3(旧master)中写入,当网络恢复,Redis3用化Redis1的slave,并免除在网络故障期间写副的兼具数据。

 

  依据数据需求,或者配备要求,你恐怕想要么无思量数据丢失的状来:

    ·  若你下Redis作为缓存服务器,Client
B仍然可于旧master写副数据是生有利的,即使数据最终会掉

    · 
若您以Redis作为存储服务器,这便非常不友善了,此时为了堵住这个问题亟需针对系统进行部署

 

  由于Redis是异步复制的,这种状态下无法完全避免数据丢失,但唯独运以下配置范围Redis3和Redis1之间数据的一致性问题:

    min-slaves-to-write 1

    min-slaves-max-lag 10(秒)

 

  当master配置以上选择,若她不可知向至少一个slave写副数据,将会停下接受写入请求。由于是异步复制,不可知写意味着slave已断开连接,或不发送异步确认过max-lag秒数

 

  因此高达例被,redis3将以10s后不可用,网络恢复后,sentinel
3将会见结及新架构中,客户端B能更赢得实惠配置并继续要。

 

  总之,Redis+Sentinel形成的架构体系具备最终一致性(a
whole are a an eventually consistent system where the merge function is
last failover
wins),且旧master的数量会被扔,然后从新mastar重新获取数据,因此总起一个节点会少部分就勾勒副的数码。
This is due to Redis asynchronous replication and the discarding nature
of the “virtual” merge function of the
system。但马上sentinel本身没有限制,若您采取大一致性的方式协调故障转移,问题同会油然而生。

 

  只来少数栽方法避免丢失已确认之写入:

    ·  使用并复制(以及下一个相当的一致性算法来运转复制行为)

    ·  使用所有最终一致性的体系,能集合相同对象的不比版本

 

Redis现在不可知采取方面的其它系统,是当前的开拓进取对象。可是有一个摄实现解决方案2以Redis存储之上,如SoundCloud
Roshi,或者Netflix
Dynomite。

 

Sentinel持久化状态

  Sentinel状态信息持久化到sentinel.conf中,如每次收到一个新部署文件要创造一个初布局文件(sentinel
leader完成),配置都见面跟布置版本号(epoch)一起持久化到磁盘。很醒目,即使就sentinel进程再开也能确保配置不掉

 

TILT模式

  Redis sentinel严重依赖系统时:为了确认实例是否可用,他会见记录最后一破恢复PING的辰,并与目前时比较推断距离最后一赖恢复过去了多久。

 

  然而,若系统时有畸形改变,或者系统十分繁忙,或进程由于某些原因阻塞,sentinel可能会见出现一些问题

 

  TITL模式是一模一样栽特殊的“保护”模式,sentinel能于发有预料之外问题常常,进入是模式,降低对网的依赖性。Sentinel定时器中断正常情况下各个秒10差调用,所以能猜测在定时器中断的片软调用内还是多要遗失会发生100毫秒的时刻。

 

  Sentinel所召开的就是记录之前的间歇调用时间,并跟目前调用时间比:

    ·  如果少不良调用时间里面的区别啊负值, 或者坏可怜(超过 2
秒钟), 那么 Sentinel 进入 TILT 模式。

    ·  如果 Sentinel 已经跻身 TILT 模式, 那么 Sentinel 延迟退出
TILT 模式的时。

 

  当处于TITL模式,sentinel或连监控所有状态,但:

    ·  停止处理要

    ·  当起实例向这个Sentinel发送“SENTINEL
is-master-down-by-addr”命令时,Sentinel返回负值:
因为此Sentinel所进行的下线判断已经不复纯粹。

  如果 TILT
可以正常维持30秒钟, 那么Sentinel退出TILT模式。

留下评论

网站地图xml地图