相匹配的主服务器。
pattern 参数是一个 Glob 风格的模式。重置操作清除主服务器目前的所有状态，包括正在执行中的故障转移，并移除目前已经发现和关联的，主服务器的所有从服务器和 Sentinel 。
SENTINEL failover
：当主服务器失效时，在不询问其他 Sentinel 意见的情况下，强制开始一次自动故障迁移（不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
发布与订阅信息
客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器：你不可以使用 PUBLISH 命令向这个服务器发送信息，但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令，通过订阅给定的频道来获取相应的事件提醒。
一个频道能够接收和这个频道的名字相同的事件。比如说，名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。
通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。
以下列出的是客户端可以通过订阅来获得的频道和信息的格式：第一个英文单词是频道/事件的名字，其余的是数据的格式。
注意，当格式中包含 instance details 字样时，表示频道所返回的信息中包含了以下用于识别目标实例的内容：
@
@ 字符之后的内容用于指定主服务器，这些内容是可选的，它们仅在 @ 字符之前的内容指定的实例不是主服务器时使用。
+reset-master
：主服务器已被重置。
+slave
：一个新的从服务器已经被 Sentinel 识别并关联。
+failover-state-reconf-slaves
：故障转移状态切换到了
reconf-slaves 状态。
+failover-detected
：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
+slave-reconf-sent
：领头（leader）的 Sentinel 向实例发送了
SLAVEOF 命令，为实例设置新的主服务器。
+slave-reconf-inprog
：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
+slave-reconf-done
：从服务器已经成功完成对新主服务器的同步。
-dup-sentinel
：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
+sentinel
：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
+sdown
：给定的实例现在处于主观下线状态。
-sdown
：给定的实例已经不再处于主观下线状态。
+odown
：给定的实例现在处于客观下线状态。
-odown
：给定的实例已经不再处于客观下线状态。
+new-epoch
：当前的纪元（epoch）已经被更新。
+try-failover
：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
+elected-leader
：赢得指定纪元的选举，可以进行故障迁移操作了。
+failover-state-select-slave
：故障转移操作现在处于
select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
no-good-slave
：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
selected-slave
：Sentinel 顺利找到适合进行升级的从服务器。
failover-state-send-slaveof-noone
：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
failover-end-for-timeout
：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
failover-end
：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
+switch-master
：配置变更，主服务器的 IP 和地址已经改变。
这是绝大多数外部用户都关心的信息。
+tilt ：进入 tilt 模式。
-tilt ：退出 tilt 模式。
故障转移
一次故障转移操作由以下步骤组成：
发现主服务器已经进入客观下线状态。对我们的当前纪元进行自增（详情请参考 Raft leader election ），并尝试在这个纪元中当选。如果当选失败，那么在设定的故障迁移超时时间的两倍之后，重新尝试当选。如果当选成功，那么执行以下步骤。选出一个从服务器，并将它升级为主服务器。向被选中的从服务器发送
SLAVEOF NO ONE 命令，让它转变为主服务器。通过发布与订阅功能，将更新后的配置传播给所有其他 Sentinel ，其他 Sentinel 对它们自己的配置进行更新。向已下线主服务器的从服务器发送
SLAVEOF 命令，让它们去复制新的主服务器。当所有从服务器都已经开始复制新的主服务器时，领头 Sentinel 终止这次故障迁移操作。
每当一个 Redis 实例被重新配置（reconfigured） ——无论是被设置成主服务器、从服务器、又或者被设置成其他主服务器的从服务器 ——Sentinel 都会向被重新配置的实例发送一个 CONFIG REWRITE 命令，从而确保这些配置会持久化在硬盘里。
Sentinel 使用以下规则来选择新的主服务器：
在失效主服务器属下的从服务器当中，那些被标记为主观下线、已断线、或者最后一次回复
PING 命令的时间大于五秒钟的从服务器都会被淘汰。在失效主服务器属下的从服务器当中，那些与失效主服务器连接断开的时长超过
down-after 选项指定的时长十倍的从服务器都会被淘汰。在经历了以上两轮淘汰之后剩下来的从服务器中，我们选出复制偏移量（replication offset）最大的那个从服务器作为新的主服务器；如果复制偏移量不可用，或者从服务器的复制偏移量相同，那么带有最小运行 ID 的那个从服务器成为新的主服务器。
Sentinel 自动故障迁移的一致性特质
Sentinel 自动故障迁移使用 Raft 算法来选举领头（leader） Sentinel ，从而确保在一个给定的纪元（epoch）里，只有一个领头产生。
这表示在同一个纪元中，不会有两个 Sentinel 同时被选中为领头，并且各个 Sentinel 在同一个纪元中只会对一个领头进行投票。
更高的配置纪元总是优于较低的纪元，因此每个 Sentinel 都会主动使用更新的纪元来代替自己的配置。
简单来说，我们可以将 Sentinel 配置看作是一个带有版本号的状态。一个状态会以最后写入者胜出（last-write-wins）的方式（也即是，最新的配置总是胜出）传播至所有其他 Sentinel 。
举个例子，当出现网络分割（network partitions）时，一个 Sent