redis 系列24 哨兵Sentinel (中)
四. 检测下线状态
对于Redis的Sentinel中关于下线有两个不同的概念:(1)主观下线(Subjectively Down, 简称 Sdown) 指的是单个 Sentinel 实例对服务器做出的下线判断,此时不会进行故障转移。(2) 客观下线(Objectively Down, 简称 Odown)指的是多个 Sentinel 实例在对同一个服务器做出 Sdown 判断,此时目标sentinel会对主服务器进行故障转移。本篇具体详细介绍。
4.1 检测主观下线状态
默认情况下,Sentinel会以每秒一次的频率向所有与它创建命令连接的实例(包括主、从、其他sentinel在内)发送ping命令,并通过实例返回的ping命令回复来判断实例是否在线。例如:有二个sentinel服务,共同监视一主二从的redis服务。(1) sentinel服务将向sentine2、主服务master、从服务slave1和slave2发送ping命令。(2) sentine2服务将向sentine1、主服务master、从服务slave1和slave2发送ping命令。实例对于ping命令的回复可以分为两种情况:
(1) 有效回复: 实例返回 +pong 、 -loading、 -masterdown三种回复的其中一种。
(2)无效回复: 实例返回上面三种回复之处的其它回复,或者在指定时限内没有返回任何回复。在Sentinel.conf配置文件中的down-after-milliseconds选项指定了Sentinel判断实例进入主观下线所需的时间长度。
4.1.1主观下线时长选项的作用范围
用户设置down-after-milliseconds选项的值,不仅会被sentinel用来判断主服务器的主观下线状态,还会被用于判断主服务器下的所有从服务器,以及同样监视主服务器的其他sentinel的主观下线状态。
-- 例如用户向sentinel设置以了下配置: sentinel monitor master 127.0.0.1 6379 2 sentinel down-after-milliseconds master 50000
这里的master是主服务器的名称, 端口默认6379 ,2代表sentinel集群中有2个sentinel认为master 状态下线时,才能真正认为该master已经不可用了(也就是客观下线,下面会讲)。这50000毫秒不仅会成为sentinel判断master进入主观下线的标准,还会判断所有从库、其它sentinel进入主观下线的标准。
4.1.2 多个sentinel设置的主观下线时长可能不同
对于多个sentinel共同监视同一个主服务器时,这些sentinle在配置文件sentinle.conf中所设置的down-after-milliseconds值也可能不同,因此当一个sentinel将主服务器判断为主观下线时,其它sentinel可能仍然会认为主服务器处于在线状态。只有全部的sentine都判断进入了主观下线状态时,才会认为主master进入了主观下线状态。
4.2 检查客观下线状态
当sentinel将一个主服务器判断为主观下线之后,为了确认这个主服务器是否真要下线,会向同样监视这一主服务器的其它sentinel进行询问,其它sentinel回复已下线之后,sentinel就会将主服务器从主观判定为客观下线,并对主服务器执行故障转移操作。客观下线条件只适用于主服务器。
客观判断是:sentinel向其它sentinel发送sentinel is-master-down-by-addr命令进行互相交流之后,得出主服务器下线判断。 只要一个 Sentinel 发现某个主服务器进入了客观下线状态, 这个 Sentinel 就可能会被其他 Sentinel 推选出, 并对失效的主服务器执行自动故障迁移操作。
4.2.1 is-master-down-by-addr命令用来判断是否客观下线
命令格式:sentinel is-master-down-by-addr ip port current runid
分别代表主观下线的主服务器ip址址,端口号, sentinel当前的配置纪元用于选举领头羊sentinel, runid可以是*或者sentinel的运行ID。
--例如一个sentinel向其它sentinel发送以下命令: sentinel is-master-down-by-addr 127.0.0.1 6379 0 *
最后一个参数:*代表命令仅仅用于检测主服务器客观下线状态。而sentinel的运行ID则用于选举领头羊。当接收的sentinel收到其它sentinel回复的命令时,会取出命令中包含的参数,来检查主服务器是否已下线,然后向源sentinel返回一条信息。该信息包括三个参数:
(1) down_state: 检查主服务器的结果,1代表已下线,2代表未下线。
(2) leader_runid: 如果是* 用于检测主服务器下线状态。如果是runid则是局部领头sentinel的运行ID,用于选举领头sentinel。
(3) leader_epoch: 目标sentinel的局部领头sentinel的配置纪元。
例如返回: 1 * 1 。说明其它sentinel也同意主服务器下线。接收sentinel将统计其他sentinel同意主服务器下线的数量,当这一数量达到配置指定的数量时,就会客观下线,进行故障转移。
例如: sentinel monitor master 127.0.0.1 6379 2 配置是指包括当前sentinel在内,只要总共有两个sentinel 服务认为主服务器已经进入下线状态,那么当前sentinel就将主服务器判断为客观下线。
五. 选举领头sentinel
当一个主服务器被判断为客观下线时,监视这个下线主服务器的各个sentinel会进行协商,选择出一个领头sentinel,并由领头sentinel对下线主服务器执行故障转移操作,关于Redis选举领头sentinel规则和方法就不在述说,请看"redis设计与实现"书籍。
六.故障转移
选举产生领头sentinel之后,领头sentinel将对已下线的主服务器执行故障转移,操作包括三个步骤:
(1) 在已下线的主服务器属下的所有从服务器中,挑选出一个从服务器,并将其转换为主服务器。挑选是经过了严格的一项一项的过滤(如过滤从库下线的,5秒内没有回复领头sentinel的info命令的,与以下线的主服务器连接断开超过down-after-milliseconds *10 毫秒的。这些通通都删除),之后选出最优的从服务器。向这个从服务器发送slaveof no one命令,将这个从服务器转换为主服务器。
(2) 让已下线主服务器属下的所有从服务器改为复制新的主服务器。领头sentinel向已下线的主服务和所有从服务器(除了新的主服务)发送slaveof 命令,让它们复制新的主服务器。
(3) 将已下线的主服务器设置为从服务器。当已下线的主服务器重新上线时,sentinel就会向它发送slaveof命令,让它成为从服务。
七 sentinel上下二篇原理总结:
对于sentinel的高可用,用了二篇来介绍了sentinel服务、主服务、从服务、其它sentinel服务的原理关系。知识点比较多,下面再总结下:
(1) sentinel只是一个运行在特殊模式下的redis服务器,它使用了和普通模式不同的命令表,以及区别与普通模式下使用的命令不同。
(2) sentinel会读入指定的配置文件(sentinel.conf),为每个要监视的主服务器创建相应的实例结构,并创建连向主服务器的命令连接和订阅连接,其中命令连接用于向主服务器发送命令请求,订阅连接则用于接收指定频道的消息。
(3) sentinel通过向主服务器发送info命令来获得主服务器属下所有从服务器的地址信息,并为这些从服务器创建相应的实例结构,以及连向这些从服务器的命令连接和订阅连接。
(4) 一般情况下,sentinel以每10秒一次的频率向被监视的主服务器和从服务器发送info命令,当主服务器处于下线状态,或者sentinel正在对主服务器进行故障转移操作时,sentinel向从服务器发送info命令的频率会改为1秒一次。
(5)对于监视同一个主服务器和从服务器的多个sentinel来说,它们会以每2秒一次的频率,通过向被监视的_sentinel_:hello频道发送消息来向其他sentinel宣告自己的存在。
(6)每个sentinel也会从_sentinel_:hello中频道中接收其他sentinel发来的信息,并根据这些信息为其他sentinel创建相应的实例结构,以及命令连接。
(7) sentinel只会与主服务器和从服务器创建命令连接和订阅连接,sentinel与sentinel之间则只创建命令连接。
(8) sentinel以每秒一次的频率向实例(包括主,从,其它sentinel)发送ping命令,并根据实例对ping命令的回复来判断实例是否在线,当一个实例在指定的时长中连续向sentinel发送无效回复时,sentinel会将这个实例判断为主观下线。
(9)当sentinel将一个主服务器判断为主观下线时,它会向同样的监视这个主服务器的其他sentinel进行询问,看它们是否同意这个主服务器已经进入主观下线状态。
(10)当sentinel收集到足够多的主观下线投票之后,它会将主服务器判断为客观下线,并发起一次针对主服务器的故障转移操作。