Redis Sentinel 机制与用法（二）

Question

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 的新地址。
  <br/>

无 failover 时的配置纠正

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

• 根据最新配置确认为 slaves 的节点却声称自己是 master(参考上文例子中被网络隔离后的的 redis3)，这时它们会被重新配置为当前 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 name> 显示指定 master 的信息和状态；
• SENTINEL slaves <master name> 显示指定 master 的所有 slave 以及它们的状态；
• SENTINEL get-master-addr-by-name <master name> 返回指定 master 的 ip 和端口，如果正在进行 failover 或者 failover 已经完成，将会显示被提升为 master 的 slave 的 ip 和端口。
• SENTINEL reset <pattern> 重置名字匹配该正则表达式的所有的 master 的状态信息，清楚其之前的状态信息，以及 slaves 信息。
• SENTINEL failover <master name> 强制 sentinel 执行 failover，并且不需要得到其他 sentinel 的同意。但是 failover 后会将最新的配置发送给其他 sentinel。

动态修改 Sentinel 配置

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

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

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

• SENTINEL MONITOR <name> <ip> <port> <quorum> 这个命令告诉 sentinel 去监听一个新的 master
• SENTINEL REMOVE <name> 命令 sentinel 放弃对某个 master 的监听
• SENTINEL SET <name> <option> <value> 这个命令很像 Redis 的 CONFIG SET 命令，用来改变指定 master 的配置。支持多个<option><value>。例如以下实例：
• 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 的格式是：

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

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

    +reset-master <instance details> -- 当 master 被重置时.
    +slave <instance details> -- 当检测到一个 slave 并添加进 slave 列表时.
    +failover-state-reconf-slaves <instance details> -- Failover 状态变为 reconf-slaves 状态时
    +failover-detected <instance details> -- 当 failover 发生时
    +slave-reconf-sent <instance details> -- sentinel 发送 SLAVEOF 命令把它重新配置时
    +slave-reconf-inprog <instance details> -- slave 被重新配置为另外一个 master 的 slave，但数据复制还未发生时。
    +slave-reconf-done <instance details> -- slave 被重新配置为另外一个 master 的 slave 并且数据复制已经与 master 同步时。
    -dup-sentinel <instance details> -- 删除指定 master 上的冗余 sentinel 时 (当一个 sentinel 重新启动时，可能会发生这个事件).
    +sentinel <instance details> -- 当 master 增加了一个 sentinel 时。
    +sdown <instance details> -- 进入 SDOWN 状态时;
    -sdown <instance details> -- 离开 SDOWN 状态时。
    +odown <instance details> -- 进入 ODOWN 状态时。
    -odown <instance details> -- 离开 ODOWN 状态时。
    +new-epoch <instance details> -- 当前配置版本被更新时。
    +try-failover <instance details> -- 达到 failover 条件，正等待其他 sentinel 的选举。
    +elected-leader <instance details> -- 被选举为去执行 failover 的时候。
    +failover-state-select-slave <instance details> -- 开始要选择一个 slave 当选新 master 时。
    no-good-slave <instance details> -- 没有合适的 slave 来担当新 master
    selected-slave <instance details> -- 找到了一个适合的 slave 来担当新 master
    failover-state-send-slaveof-noone <instance details> -- 当把选择为新 master 的 slave 的身份进行切换的时候。
    failover-end-for-timeout <instance details> -- failover 由于超时而失败时。
    failover-end <instance details> -- failover 成功完成时。
    switch-master <master name> <oldip> <oldport> <newip> <newport> -- 当 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 是只读的话，就能成功执行。