Home未分类Redis Sentinel 机制与用法

Redis Sentinel 机制与用法

2016 年 1 月 1 日



Redis Sentinel 机制与用法


（一）




# 概述


Redis-Sentinel 是 Redis 官方推荐的高可用性( HA )解决方案，当用 Redis 做 Master-slave 的高可用方案时，假如 master 宕机了，Redis 本身(包括它的很多客户端)都没有实现自动进行主备切换，而 Redis-sentinel 本身也是一个独立运行的进程，它能监控多个 master-slave 集群，发现 master 宕机后能进行自懂切换。

它的主要功能有以下几点

  • 不时地监控 redis 是否按照预期良好地运行;

  • 如果发现某个 redis 节点运行出现状况，能够通知另外一个进程(例如它的客户端);

  • 能够进行自动切换。当一个 master 节点不可用时，能够选举出 master 的多个 slave (如果有超过一个 slave 的话)中的一个来作为新的 master ,其它的 slave 节点会将它所追随的 master 的地址改为被提升为 master 的 slave 的新地址。



# Sentinel 支持集群


很显然，只使用单个 sentinel 进程来监控 redis 集群是不可靠的，当 sentinel 进程宕掉后( sentinel 本身也有单点问题，single-point-of-failure )整个集群系统将无法按照预期的方式运行。所以有必要将 sentinel 集群，这样有几个好处：

  • 即使有一些 sentinel 进程宕掉了，依然可以进行 redis 集群的主备切换；

  • 如果只有一个 sentinel 进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现 redis 集群的主备切换（单点问题）;

  • 如果有多个 sentinel，redis 的客户端可以随意地连接任意一个 sentinel 来获得关于redis集群中的信息。



# Sentinel 版本


Sentinel 当前最新的稳定版本称为 Sentinel 2 (与之前的 Sentinel 1 区分开来）。随着 redis 2.8 的安装包一起发行。安装完 Redis 2.8 后，可以在 redis 2.8/src/ 里面找到 Redis-sentinel 的启动程序。



强烈建议

：


如果你使用的是 redis 2.6 ( sentinel 版本为  sentinel  1 
)，你最好应该使用 redis 2.8 版本的  sentinel  2
，因为sentinel 1有很多的 Bug ，已经被官方弃用，所以强烈建议使用 redis 2.8 以及 sentinel 2。



# 运行 Sentinel


运行 sentinel 有两种方式：

  • 第一种

redis-sentinel /path/to/sentinel.conf
  • 第二种 
redis-server /path/to/sentinel.conf --sentinel

以上两种方式，都必须指定一个 sentinel 的配置文件 sentinel.conf ，如果不指定，将无法启动 sentinel 。sentinel 默认监听 26379 端口，所以运行前必须确定该端口没有被别的进程占用。



# Sentinel 的配置


Redis 源码包中包含了一个 sentinel.conf 文件作为 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


上面的配置项配置了两个名字分别为 
mymaster 和 resque 的 master ，配置文件只需要配置 master 的信息就好啦，不用配置 slave 的信息，因为 slave 能够被自动检测到( master 节点会有关于 slave 的消息)。需要注意的是，配置文件在 sentinel 运行期间是会被动态修改的，例如当发生主备切换时候，配置文件中的 master 会被修改为另外一个 slave 。这样，之后 sentinel 如果重启时，就可以根据这个配置来恢复其之前所监控的 redis 集群的状态。



接下来我们将一行一行地解释上面的配置项：

sentinel monitor mymaster 127.0.0.1 6379 2


这一行代表 sentinel 监控的 master 的名字叫做  mymaster 
,地址为  127.0.0.1:6379 
，行尾最后的一个  2 
代表什么意思呢？我们知道，网络是不可靠的，有时候一个 sentinel 会因为网络堵塞而误以为一个 master redis 已经死掉了，当 sentinel 集群式，解决这个问题的方法就变得很简单，只需要多个 sentinel 互相沟通来确认某个 master 是否真的死了，这个  2 
代表，当集群中有 2 个 sentinel 认为 master 死了时，才能真正认为该 master 已经不可用了。（ sentinel 集群中各个 sentinel 也有互相通信，通过 gossip 协议）。

除了第一行配置，我们发现剩下的配置都有一个统一的格式:

sentinel


接下来我们根据上面格式中的  option_name 
一个一个来解释这些配置项：


  • down-after-milliseconds


sentinel 会向 master 发送心跳  PING 
来确认 master 是否存活，如果 master 在“ 一定时间范围
”内不回应  PONG
或者是回复了一个错误消息，那么这个 sentinel 会 主观地
(单方面地)认为这个 master 已经不可用了( subjectively down , 也简称为 SDOWN )。而这个 down-after-milliseconds 就是用来指定这个“ 一定时间范围
”的，单位是毫秒。


不过需要注意的是，这个时候 sentinel 并不会马上进行 failover 主备切换，这个 sentinel 还需要参考 sentinel 集群中其他 sentinel 的意见，如果超过某个数量的 sentinel 也 主观地
认为该 master 死了，那么这个 master 就会被 客观地
(注意哦，这次不是主观，是客观，与刚才的 subjectively down 相对，这次是 objectively down ，简称为 ODOWN )认为已经死了。需要一起做出决定的 sentinel 数量在上一条配置中进行配置。


  • parallel-syncs

在发生 failover 主备切换时，这个选项指定了最多可以有多少个 slave 同时对新的 master 进行同步，这个数字越小，完成 failover 所需的时间就越长，但是如果这个数字越大，就意味着越多的 slave 因为 replication 而不可用。可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态。
其他配置项在 sentinel.conf 中都有很详细的解释。

所有的配置都可以在运行时用命令 
SENTINEL SET command 
动态修改。



# Sentinel 的“仲裁会”



前面我们谈到，当一个 master 被 sentinel 集群监控时，需要为它指定一个参数，这个参数指定了当需要判决 master 为不可用，并且进行 failover 时，所需要的 sentinel 数量，本文中我们暂时称这个参数为 票数


不过，当 failover 主备切换真正被触发后， failover 并不会马上进行，还需要 sentinel 中的 大多数 
sentinel 授权后才可以进行 failover 。

当 ODOWN 时， failover 被触发。 failover 一旦被触发，尝试去进行 failover 的 sentinel 会去获得“大多数” sentinel 的授权（如果票数比大多数还要大的时候，则询问更多的 sentinel )

这个区别看起来很微妙，但是很容易理解和使用。例如，集群中有 5 个 sentinel ，票数被设置为 2 ，当 2 个 sentinel 认为一个 master 已经不可用了以后，将会触发 failover ，但是，进行 failover 的那个 sentinel 必须先获得至少 3 个 sentinel 的授权才可以实行 failover 。

如果票数被设置为 5 ，要达到 ODOWN 状态，必须所有 5 个 sentinel 都主观认为 master 为不可用，要进行 failover ，那么得获得所有 5 个 sentinel 的授权。



# 配置版本号



为什么要先获得 大多数 
sentinel 的认可时才能真正去执行 failover 呢？


当一个 sentinel 被授权后，它将会获得宕掉的 master 的一份最新配置版本号，当 failover 执行结束以后，这个版本号将会被用于最新的配置。因为 大多数 
sentinel 都已经知道该版本号已经被要执行 failover 的 sentinel 拿走了，所以其他的 sentinel 都不能再去使用这个版本号。这意味着，每次 failover 都会附带有一个独一无二的版本号。我们将会看到这样做的重要性。

而且， sentinel 集群都遵守一个规则：如果 sentinel A 推荐 sentinel B 去执行 failover ， A 会等待一段时间后，自行再次去对同一个 master 执行 failover ，这个等待的时间是通过 
failover-timeout 
配置项去配置的。从这个规则可以看出， sentinel 集群中的 sentinel  不会再同一时刻并发去 failover 同一个 master ，第一个进行 failover 的 sentinel 如果失败了，另外一个将会在一定时间内进行重新进行 failover ，以此类推。


redis sentinel 保证了活跃性：如果 大多数 
sentinel 能够互相通信，最终将会有一个被授权去进行 failover .

redis sentinel 也保证了安全性：每个试图去 failover 同一个 master 的 sentinel 都会得到一个独一无二的版本号。



# 配置传播


一旦一个 sentinel 成功地对一个 master 进行了 failover ，它将会把关于 master 的最新配置通过广播形式通知其它 sentinel ，其它的 sentinel 则更新对应 master 的配置。

一个 faiover 要想被成功实行， sentinel 必须能够向选为 master 的 slave 发送 
SLAVE OF NO ONE 
命令，然后能够通过 
INFO 
命令看到新 master 的配置信息。

当将一个 slave 选举为 master 并发送 
SLAVE OF NO ONE
` 后，即使其它的 slave 还没针对新 master 重新配置自己， failover 也被认为是成功了的，然后所有 sentinels 将会发布新的配置信息。

新配在集群中相互传播的方式，就是为什么我们需要当一个 sentinel 进行 failover 时必须被授权一个版本号的原因。

每个 sentinel 使用##发布/订阅##的方式持续地传播 master 的配置版本信息，配置传播的##发布/订阅##管道是：
__sentinel__:hello
。

因为每一个配置都有一个版本号，所以以版本号最大的那个为标准。

举个栗子：假设有一个名为 mymaster 的地址为 192.168.1.50:6379 。一开始，集群中所有的 sentinel 都知道这个地址，于是为 mymaster 的配置打上版本号 1 。一段时候后 mymaster 死了，有一个 sentinel 被授权用版本号 2 对其进行 failover 。如果 failover 成功了，假设地址改为了 192.168.1.50:9000 ，此时配置的版本号为 2 ，进行 failover 的 sentinel 会将新配置广播给其他的 sentinel ，由于其他 sentinel 维护的版本号为 1 ，发现新配置的版本号为 2 时，版本号变大了，说明配置更新了，于是就会采用最新的版本号为 2 的配置。

这意味着 sentinel 集群保证了第二种活跃性：一个能够互相通信的 sentinel 集群最终会采用版本号最高且相同的配置。



# SDOWN 和 ODOWN 的更多细节



sentinel 对于 不可用
有两种不同的看法，一个叫 主观不可用
( SDOWN ),另外一个叫 客观不可用
( ODOWN )。 SDOWN 是 sentinel 自己主观上检测到的关于 master 的状态， ODOWN 需要一定数量的 sentinel 达成一致意见才能认为一个 master 客观上已经宕掉，各个 sentinel 之间通过命令 
SENTINEL is_master_down_by_addr 
来获得其它 sentinel 对 master 的检测结果。


从 sentinel 的角度来看，如果发送了
PING 

心跳后，在一定时间内没有收到合法的回复，就达到了 SDOWN 的条件。这个时间在配置中通过 
is-master-down-after-milliseconds 
参数配置。


当 sentinel 发送 

PING 

后，以下回复之一都被认为是合法的：

PING replied with +PONG.

PING replied with -LOADING error.

PING replied with -MASTERDOWN error.

其它任何回复（或者根本没有回复）都是不合法的。

从 SDOWN 切换到 ODOWN 不需要任何一致性算法，只需要一个 gossip 协议：如果一个 sentinel 收到了足够多的 sentinel 发来消息告诉它某个 master 已经 down 掉了， SDOWN 状态就会变成 ODOWN 状态。如果之后 master 可用了，这个状态就会相应地被清理掉。

正如之前已经解释过了，真正进行 failover 需要一个授权的过程，但是所有的 failover 都开始于一个 ODOWN 状态。

ODOWN 状态只适用于 master ，对于不是 master 的 redis 节点 sentinel 之间不需要任何协商， slaves 和 sentinel 不会有 ODOWN 状态。



# Sentinel 之间和 Slaves 之间的自动发现机制



虽然 sentinel 集群中各个 sentinel 都互相连接彼此来检查对方的可用性以及互相发送消息。但是你不用在任何一个 sentinel 配置任何其它的 sentinel 的节点。因为 sentinel 利用了 master 的 发布/订阅
机制去自动发现其它也监控了统一 master 的 sentinel 节点。

通过向名为 
__sentinel__:hello 
的管道中发送消息来实现。

同样，你也不需要在 sentinel 中配置某个 master 的所有 slave 的地址， sentinel 会通过询问 master 来得到这些 slave 的地址的。


每个 sentinel 通过向每个 master 和 slave 的 发布/订阅
频道 
__sentinel__:hello 
每秒发送一次消息，来宣布它的存在。

每个 sentinel 也订阅了每个 master 和 slave 的频道 
__sentinel__:hello 
的内容，来发现未知的 sentinel ，当检测到了新的 sentinel ，则将其加入到自身维护的 master 监控列表中。

每个 sentinel 发送的消息中也包含了其当前维护的最新的 master 配置。如果某个 sentinel 发现

自己的配置版本低于接收到的配置版本，则会用新的配置更新自己的 master 配置。

在为一个 master 添加一个新的 sentinel 前， sentinel 总是检查是否已经有 sentinel 与新的 sentinel 的进程号或者是地址是一样的。如果是那样，这个 sentinel 将会被删除，而把新的 sentinel 添加上去。



# 网络隔离时的一致性


redis sentinel 集群的配置的一致性模型为最终一致性，集群中每个 sentinel 最终都会采用最高版本的配置。然而，在实际的应用环境中，有三个不同的角色会与 sentinel 打交道：

  • Redis 实例.

  • Sentinel 实例.

  • 客户端.

为了考察整个系统的行为我们必须同时考虑到这三个角色。

下面有个简单的例子，有三个主机，每个主机分别运行一个 redis 和一个 sentinel :

             +-------------+

             | Sentinel 1  | <--- Client A

             | Redis 1 (M) |

             +-------------+

                     |

                     |

 +-------------+     |                     +------------+

 | Sentinel 2  |-----+-- / partition / ----| Sentinel 3 | <--- Client B

 | Redis 2 (S) |                           | Redis 3 (M)|

 +-------------+                           +------------+

在这个系统中，初始状态下 redis 3 是 master ,  redis 1 和 redis 2 是 slave 。之后 redis 3 所在的主机网络不可用了， sentinel 1 和 sentinel 2 启动了 failover 并把 redis 1 选举为 master 。

Sentinel 集群的特性保证了 sentinel 1 和 sentinel 2 得到了关于 master 的最新配置。但是 sentinel 3 依然持着的是就的配置，因为它与外界隔离了。

当网络恢复以后，我们知道 sentinel 3 将会更新它的配置。但是，如果客户端所连接的 master 被网络隔离，会发生什么呢？

客户端将依然可以向 redis 3 写数据，但是当网络恢复后， redis 3 就会变成 redis 的一个 slave ，那么，在网络隔离期间，客户端向 redis 3 写的数据将会丢失。

也许你不会希望这个场景发生：

  • 如果你把 redis 当做缓存来使用，那么你也许能容忍这部分数据的丢失。

  • 但如果你把 redis 当做一个存储系统来使用，你也许就无法容忍这部分数据的丢失了。

因为 redis 采用的是异步复制，在这样的场景下，没有办法避免数据的丢失。然而，你可以通过以下配置来配置 redis 3 和 redis 1 ，使得数据不会丢失。

min-slaves-to-write 1

min-slaves-max-lag 10


通过上面的配置，当一个 redis 是 master 时，如果它不能向至少一个 slave 写数据( 上面的 min-slaves-to-write
指定了 slave 的数量)，它将会拒绝接受客户端的写请求。由于复制是异步的， master 无法向 slave 写数据意味着 slave 要么断开连接了，要么不在指定时间内向 master 发送同步数据的请求了(上面的 min-slaves-max-lag
指定了这个时间)。



# Sentinel 状态持久化


snetinel 的状态会被持久化地写入 sentinel 的配置文件中。每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。这意味着，可以安全的停止和重启 sentinel 进程。



Redis Sentinel 机制与用法（二）




# 概述


Redis-Sentinel 是 Redis 官方推荐的高可用性( HA )解决方案，当用 Redis 做 Master-slave 的高可用方案时，假如 master 宕机了， Redis 本身(包括它的很多客户端)都没有实现自动进行主备切换，而 Redis-sentinel 本身也是一个独立运行的进程，它能监控多个 master-slave 集群，发现 master 宕机后能进行自懂切换。

它的主要功能有以下几点

  • 不时地监控 redis 是否按照预期良好地运行;

  • 如果发现某个 redis 节点运行出现状况，能够通知另外一个进程(例如它的客户端);

  • 能够进行自动切换。当一个 master 节点不可用时，能够选举出 master 的多个 slave (如果有超过一个 slave 的话)中的一个来作为新的 master ,其它的 slave 节点会将它所追随的 master 的地址改为被提升为 master 的 slave 的新地址。



# 无 failover 时的配置纠正


即使当前没有 failover 正在进行， sentinel 依然会使用当前配置去设置监控的 master 。特别是：

  • 根据最新配置确认为 slaves 的节点却声称自己是 master (参考上文例子中被网络隔离后的的 redis 3 )，这时它们会被重新配置为当前 master 的 slave 。

  • 如果 slaves 连接了一个错误的 master ，将会被改正过来，连接到正确的 master 。



# Slave 选举与优先级


当一个 sentinel 准备好了要进行 failover ，并且收到了其他 sentinel 的授权，那么就需要选举出一个合适的 slave 来做为新的 master 。

slave 的选举主要会评估 slave 的以下几个方面：

  • 与 master 断开连接的次数

  • Slave 的优先级

  • 数据复制的下标(用来评估 slave 当前拥有多少 master 的数据)

  • 进程 ID

如果一个 slave 与 master 失去联系超过 10 次，并且每次都超过了配置的最大失联时间( 
down-after-milliseconds option 
)，并且，如果 sentinel 在进行 failover 时发现 slave 失联，那么这个 slave 就会被 sentinel 认为不适合用来做新 master 的。

更严格的定义是，如果一个 slave 持续断开连接的时间超过

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

就会被认为失去选举资格。

符合上述条件的 slave 才会被列入 master 候选人列表，并根据以下顺序来进行排序：

  1. sentinel 首先会根据 slaves 的优先级来进行排序，优先级越小排名越靠前（？）。

  2. 如果优先级相同，则查看复制的下标，哪个从 master 接收的复制数据多，哪个就靠前。

  3. 如果优先级和下标都相同，就选择进程 ID 较小的那个。

一个 redis 无论是 master 还是 slave ，都必须在配置中指定一个 slave 优先级。要注意到 master 也是有可能通过 failover 变成 slave 的。

如果一个 redis 的 slave 优先级配置为 0 ，那么它将永远不会被选为 master 。但是它依然会从 master 哪里复制数据。



# Sentinel 和 Redis 身份验证


当一个 master 配置为需要密码才能连接时，客户端和 slave 在连接时都需要提供密码。

master 通过 
requirepass 
设置自身的密码，不提供密码无法连接到这个 master 。

slave 通过 
masterauth 
来设置访问 master 时的密码。

但是当使用了 sentinel 时，由于一个 master 可能会变成一个 slave ，一个 slave 也可能会变成 master ，所以需要同时设置上述两个配置项。



# Sentinel API


Sentinel 默认运行在 26379 端口上， sentinel 支持 redis 协议，所以可以使用 redis-cli 客户端或者其他可用的客户端来与 sentinel 通信。

有两种方式能够与 sentinel 通信：

  • 一种是直接使用客户端向它发消息


  • 另外一种是使用 发布/订阅
    模式来订阅 sentinel 事件，比如说 failover ，或者某个 redis 实例运行出错，等等。



## Sentinel 命令


sentinel 支持的合法命令如下：

  • PING
     sentinel 回复 
    PONG
    .
  • SENTINEL masters
     显示被监控的所有 master 以及它们的状态.
  • SENTINEL master
     显示指定 master 的信息和状态；
  • SENTINEL slaves
     显示指定 master 的所有 slave 以及它们的状态；
  • SENTINEL get-master-addr-by-name
     返回指定 master 的 ip 和端口，如果正在进行 failover 或者 failover 已经完成，将会显示被提升为 master 的 slave 的 ip 和端口。

  • SENTINEL reset
     重置名字匹配该正则表达式的所有的 master 的状态信息，清楚其之前的状态信息，以及 slaves 信息。

  • SENTINEL failover

     强制 sentinel 执行 failover ，并且不需要得到其他 sentinel 的同意。但是 failover 后会将最新的配置发送给其他
    sentinel 。



## 动态修改 Sentinel 配置


从 redis 2.8.4 开始， sentinel 提供了一组 API 用来添加，删除，修改 master 的配置。

需要注意的是，如果你通过 API 修改了一个 sentinel 的配置， sentinel 不会把修改的配置告诉其他 sentinel 。你需要自己手动地对多个 sentinel 发送修改配置的命令。

以下是一些修改 sentinel 配置的命令：

  • SENTINEL MONITOR  
    这个命令告诉 sentinel 去监听一个新的 master 
  • SENTINEL REMOVE
     命令 sentinel 放弃对某个 master 的监听
  • SENTINEL SET
     这个命令很像 Redis 的 
    CONFIG SET 
    命令，用来改变指定 master 的配置。支持多个 。例如以下实例：
  • SENTINEL SET objects-cache-master down-after-milliseconds 1000

只要是配置文件中存在的配置项，都可以用 
SENTINEL SET 
命令来设置。这个还可以用来设置 master 的属性，比如说 quorum (票数)，而不需要先删除 master ，再重新添加 master 。例如：

SENTINEL SET objects-cache-master quorum 5



## 增加或删除 Sentinel


由于有 sentinel 自动发现机制，所以添加一个 sentinel 到你的集群中非常容易，你所需要做的只是监控到某个 Master 上，然后新添加的 sentinel 就能获得其他 sentinel 的信息以及 masterd 所有的 slave 。

如果你需要添加多个 sentinel ，建议你一个接着一个添加，这样可以预防网络隔离带来的问题。你可以每个 30 秒添加一个 sentinel 。最后你可以用 
SENTINEL MASTER mastername 
来检查一下是否所有的 sentinel 都已经监控到了 master 。

删除一个 sentinel 显得有点复杂：因为 sentinel 永远不会删除一个已经存在过的 sentinel ，即使它已经与组织失去联系很久了。

要想删除一个 sentinel ，应该遵循如下步骤：

  1. 停止所要删除的 sentinel

  2. 发送一个 
    SENTINEL RESET *  
    命令给所有其它的 sentinel 实例，如果你想要重置指定 master 上面的 sentinel ，只需要把 * 号改为特定的名字，注意，需要一个接一个发，每次发送的间隔不低于 30 秒。
  3. 检查一下所有的 sentinels 是否都有一致的当前 sentinel 数。使用 
    SENTINEL MASTER mastername
      来查询。



## 删除旧 master 或者不可达 slave


sentinel 永远会记录好一个 Master 的 slaves ，即使 slave 已经与组织失联好久了。这是很有用的，因为 sentinel 集群必须有能力把一个恢复可用的 slave 进行重新配置。

并且， failover 后，失效的 master 将会被标记为新 master 的一个 slave ，这样的话，当它变得可用时，就会从新 master 上复制数据。

然后，有时候你想要永久地删除掉一个 slave (有可能它曾经是个 master )，你只需要发送一个 
SENTINEL RESET master 
命令给所有的 sentinels ，它们将会更新列表里能够正确地复制 master 数据的 slave 。



## 发布/订阅


客户端可以向一个 sentinel 发送订阅某个频道的事件的命令，当有特定的事件发生时， sentinel 会通知所有订阅的客户端。需要注意的是客户端只能订阅，不能发布。


订阅频道的名字与事件的名字一致。例如，频道名为  sdown
将会发布所有与 SDOWN 相关的消息给订阅者。

如果想要订阅所有消息，只需简单地使用 
PSUBSCRIBE *


以下是所有你可以收到的消息的消息格式，如果你订阅了所有消息的话。第一个单词是频道的名字，其它是数据的格式。

注意：以下的 instance details 的格式是：

@

如果这个 redis 实例是一个 master ，那么@之后的消息就不会显示。

    +reset-master  -- 当master被重置时.

    +slave  -- 当检测到一个slave并添加进slave列表时.

    +failover-state-reconf-slaves  -- Failover状态变为reconf-slaves状态时

    +failover-detected  -- 当failover发生时

    +slave-reconf-sent  -- sentinel发送SLAVEOF命令把它重新配置时

    +slave-reconf-inprog  -- slave被重新配置为另外一个master的slave，但数据复制还未发生时。

    +slave-reconf-done  -- slave被重新配置为另外一个master的slave并且数据复制已经与master同步时。

    -dup-sentinel  -- 删除指定master上的冗余sentinel时 (当一个sentinel重新启动时，可能会发生这个事件).

    +sentinel  -- 当master增加了一个sentinel时。

    +sdown  -- 进入SDOWN状态时;

    -sdown  -- 离开SDOWN状态时。

    +odown  -- 进入ODOWN状态时。

    -odown  -- 离开ODOWN状态时。

    +new-epoch  -- 当前配置版本被更新时。

    +try-failover  -- 达到failover条件，正等待其他sentinel的选举。

    +elected-leader  -- 被选举为去执行failover的时候。

    +failover-state-select-slave  -- 开始要选择一个slave当选新master时。

    no-good-slave  -- 没有合适的slave来担当新master

    selected-slave  -- 找到了一个适合的slave来担当新master

    failover-state-send-slaveof-noone  -- 当把选择为新master的slave的身份进行切换的时候。

    failover-end-for-timeout  -- failover由于超时而失败时。

    failover-end  -- failover成功完成时。

    switch-master      -- 当master的地址发生变化时。通常这是客户端最感兴趣的消息了。

    +tilt -- 进入Tilt模式。

    -tilt -- 退出Tilt模式。



## TILT 模式


redis sentinel 非常依赖系统时间，例如它会使用系统时间来判断一个 PING 回复用了多久的时间。

然而，假如系统时间被修改了，或者是系统十分繁忙，或者是进程堵塞了， sentinel 可能会出现运行不正常的情况。

当系统的稳定性下降时， TILT 模式是 sentinel 可以进入的一种的保护模式。

当进入 TILT 模式时， sentinel 会继续监控工作，但是它不会有任何其他动作，它也不会去回应 
is-master-down-by-addr 
这样的命令了，因为它在 TILT 模式下，检测失效节点的能力已经变得让人不可信任了。

如果系统恢复正常，持续 30 秒钟， sentinel 就会退出 TITL 模式。



## -BUSY状态


注意：该功能还未实现。

当一个脚本的运行时间超过配置的运行时间时， sentinel 会返回一个 -BUSY 错误信号。如果这件事发生在触发一个 failover 之前， sentinel 将会发送一个 SCRIPT KILL 命令，如果 script 是只读的话，就能成功执行。

Related Posts

About The Author

maynard

懒散，不想无聊