redis sentinel(哨兵)模式

原文： http://redis.io/topics/sentinel

一、Sentinel作用

1)：Master状态检测

2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave

3)：Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

 二、Sentinel工作方式

1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令

2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线

5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令

6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。

 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

 2.1主观下线和客观下线

主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。

客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.

三、配置举例

port 26379
daemonize yes

logfile /root/soft/redis-2.8.24/runtime/logs/sentinel.log
pidfile /root/soft/redis-2.8.24/runtime/sentinel.pid

#master1
sentinel monitor m1 127.0.0.1 6379 2
sentinel down-after-milliseconds m1 5000
sentinel parallel-syncs m1 1
sentinel failover-timeout m1 10000

#master2
sentinel monitor m2 127.0.0.1 6381 2
sentinel down-after-milliseconds m2 5000
sentinel parallel-syncs m2 1
sentinel failover-timeout m2 10000

四、sentinel命令

redis-cli -p 26379 info

redis-cli -p 26379 sentinel masters

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 monitor m3 127.0.0.1 6384 2
sentinel set m3 down-after-milliseconds 5000
sentinel set m3 failover-timeout 10000
sentinel set m3 parallel-syncs 1

5.1增加或删除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 来查询。

5.2删除旧master或者不可达slave

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

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

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

1、停掉旧的redis进程

2、修改redis进程对应的配置文件，删掉slaveof 行（默认master）

3、给每个sentinel进程发送 sentinel reset master名字 （过一会就好了）

4、需要的话，再启动redis进程