redis主从+sentinel

sentinel
Redis的sentinel系统用于管理多个Redis服务器，主要执行三个任务： 
1）监控：sentinel不断检查主从服务器是否运行正常； 
2）提醒：当某个redis服务器出现问题，可以通过API发送通知； 
3）自动故障迁移：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。 
Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress），这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。虽然 Redis Sentinel释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 –sentinel 选项来启动 Redis Sentinel 。

注意：

redis2.6开始，才开始有sentinel。redis2.6的是sentinel1，redis2.8开始出现sentinel2，由于sentinel2.6有不少bug，所以redis官方推荐使用sentinel2.8。

我在这里使用的是redis版本是3.2.8。

192.168.11.73 主

192.168.11.77 从

1、redis主从配置

192.168.2.77（从）服务器上的redis.conf文件中修改如下配置项：

slaveof 192.168.11.73 6379

requirepass "1234"

masterauth "1234"

#bind 127.0.0.1（取消绑定，或者bind 0.0.0.0）

#protected-mode yes

192.168.11.73（主）服务器上的redis.conf文件中修改如下配置项：

requirepass "1234"

masterauth "1234"

#bind 127.0.0.1（取消绑定，或者bind 0.0.0.0）

#protected-mode yes

2、sentinel实现故障切换

192.168.11.73服务器的sentinel.conf文件：

port 26379

daemonize yes（启动进程设置为后台进程）
sentinel monitor mymaster 192.168.11.73 6379 1（最后的这个数值应当小于等于集群中slave的个数）

sentinel auth-pass mymaster 1234
sentinel down-after-milliseconds mymaster 30000（master被当前sentinel实例认定为“失效”的间隔时间，也就是说当一个master出现问题的时候，30秒内如果master没有恢复的话，sentinel就会从当前的slave中选举出新的master，其他的slave会更改自己的redis.conf文件中的slaveof配置项）
sentinel failover-timeout mymaster 180000（failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。）
sentinel parallel-syncs mymaster 1（当新master产生时，同时进行“slaveof”到新master并进行同步复制的slave个数。在salve执行salveof与同步时，将会终止客户端请求。此值较大，意味着“集群”终止客户端请求的时间总和和较大。此值较小,意味着“集群”在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据。）

192.168.11.77服务器的sentinel.conf文件：

port 26379

daemonize yes（启动进程设置为后台进程）
sentinel monitor mymaster 192.168.11.73 6379 1

sentinel auth-pass mymaster 1234
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

#配置完redis主从和sentinel之后的效果：

当192.168.11.73和192.168.11.77的redis服务都正常启动的时候，192.168.11.73是主，192.168.11.77是从；

停止192.168.11.73的redis服务，此时192.168.11.77变为主；

然后再重启192.168.11.73的redis服务，此时192.168.11.73变为从，192.168.11.77还是为主；

注意点：
1)：首次启动时，必须先启动Master的redis和sentinel

2)：Sentinel 只在 server 端做主从切换，app端要自己开发(例如Jedis库的SentinelJedis，能够监控Sentinel的状态)

3)：如果不能远程访问redis的话，那么应该是centos防火墙没有开放6379和26379端口的原因，需要在主从服务器上的防火墙上开放6379和26379这两个端口
4)：若Master已经被判定为下线，Sentinel已经选择了新的Master，也已经将old Master改成Slave，但是还没有将其改成new Master。若此时重启old Master，则Redis集群将处于无Master状态，此时只能手动修改配置文件，然后重新启动集群

#sentinel故障切换，从变主原理：

sentinel会去掉从库的slaveof语句，使原从变新主；

原主恢复后，sentinel会在原主配置文件末尾添加slaveof语句，使原主变新从。

如果想恢复原来的主从的地位，也就是192.168.2.75为主，192.168.2.78为从，那么就需要手动切换。

#sentinel原理
    首先解释2个名词:SDOWN和ODOWN.
SDOWN:subjectively down,直接翻译的为"主观"失效,即当前sentinel实例认为某个redis服务为"不可用"状态.
ODOWN:objectively down,直接翻译为"客观"失效,即多个sentinel实例都认为master处于"SDOWN"状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为"不可用",将会开启failover.
    SDOWN适合于master和slave,但是ODOWN只会使用于master;当slave失效超过"down-after-milliseconds"后,那么所有sentinel实例都会将其标记为"SDOWN".

    1) SDOWN与ODOWN转换过程:
每个sentinel实例在启动后,都会和已知的slaves/master以及其他sentinels建立TCP连接,并周期性发送PING(默认为1秒)
在交互中,如果redis-server无法在"down-after-milliseconds"时间内响应或者响应错误信息,都会被认为此redis-server处于SDOWN状态.
如果2)中SDOWN的server为master,那么此时sentinel实例将会向其他sentinel间歇性(一秒)发送"is-master-down-by-addr <ip> <port>"指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN...其他sentinel实例做同样的交互操作.配置项"sentinel monitor <mastername> <masterip> <masterport> <quorum>",如果检测到master处于SDOWN状态的slave个数达到<quorum>,那么此时此sentinel实例将会认为master处于ODOWN.
每个sentinel实例将会间歇性(10秒)向master和slaves发送"INFO"指令,如果master失效且没有新master选出时,每1秒发送一次"INFO";"INFO"的主要目的就是获取并确认当前集群环境中slaves和master的存活情况.
经过上述过程后,所有的sentinel对master失效达成一致后,开始failover.
    2) Sentinel与slaves"自动发现"机制:
    在sentinel的配置文件中(local-sentinel.conf),都指定了port,此port就是sentinel实例侦听其他sentinel实例建立链接的端口.在集群稳定后,最终会每个sentinel实例之间都会建立一个tcp链接,此链接中发送"PING"以及类似于"is-master-down-by-addr"指令集,可用用来检测其他sentinel实例的有效性以及"ODOWN"和"failover"过程中信息的交互.
    在sentinel之间建立连接之前,sentinel将会尽力和配置文件中指定的master建立连接.sentinel与master的连接中的通信主要是基于pub/sub来发布和接收信息,发布的信息内容包括当前sentinel实例的侦听端口:

参考： http://diannaowa.blog.51cto.com/3219919/1557617
关闭master的redis服务测试故障转移,若redis配置了分片功能，则该方式会出现一定的BUG。

在默认情况下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服务器使用的是 6379 ）。
Sentinel 接受 Redis 协议格式的命令请求， 所以你可以使用 redis-cli 或者任何其他 Redis 客户端来与 Sentinel 进行通讯。
有两种方式可以和 Sentinel 进行通讯：
· 第一种方法是通过直接发送命令来查询被监视 Redis 服务器的当前状态， 以及 Sentinel 所知道的关于其他 Sentinel 的信息， 诸如此类。
· 另一种方法是使用发布与订阅功能， 通过接收 Sentinel 发送的通知： 当执行故障转移操作， 或者某个被监视的服务器被判断为主观下线或者客观下线时， Sentinel 就会发送相应的信息。
Sentinel 命令

以下列出的是 Sentinel 接受的命令：
· PING：返回 PONG 。
· SENTINEL masters：列出所有被监视的主服务器，以及这些主服务器的当前状态。
· SENTINEL slaves <master name>：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。
· SENTINEL get-master-addr-by-name <master name>： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。
· SENTINEL reset <pattern>： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。
· SENTINEL failover <master name>： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
发布与订阅信息

客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器： 你不可以使用 PUBLISH 命令向这个服务器发送信息， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。
一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。
通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。
以下列出的是客户端可以通过订阅来获得的频道和信息的格式： 第一个英文单词是频道/事件的名字， 其余的是数据的格式。
注意， 当格式中包含 instance details 字样时， 表示频道所返回的信息中包含了以下用于识别目标实例的内容：
<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

@ 字符之后的内容用于指定主服务器， 这些内容是可选的， 它们仅在 @ 字符之前的内容指定的实例不是主服务器时使用。
· +reset-master <instance details>：主服务器已被重置。
· +slave <instance details>：一个新的从服务器已经被 Sentinel 识别并关联。
· +failover-state-reconf-slaves <instance details>：故障转移状态切换到了 reconf-slaves 状态。
· +failover-detected <instance details>：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
· +slave-reconf-sent <instance details>：领头（leader）的 Sentinel 向实例发送了 SLAVEOF 命令，为实例设置新的主服务器。
· +slave-reconf-inprog <instance details>：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
· +slave-reconf-done <instance details>：从服务器已经成功完成对新主服务器的同步。
· -dup-sentinel <instance details>：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
· +sentinel <instance details>：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
· +sdown <instance details>：给定的实例现在处于主观下线状态。
· -sdown <instance details>：给定的实例已经不再处于主观下线状态。
· +odown <instance details>：给定的实例现在处于客观下线状态。
· -odown <instance details>：给定的实例已经不再处于客观下线状态。
· +new-epoch <instance details>：当前的纪元（epoch）已经被更新。
· +try-failover <instance details>：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
· +elected-leader <instance details>：赢得指定纪元的选举，可以进行故障迁移操作了。
· +failover-state-select-slave <instance details>：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
· no-good-slave <instance details>：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
· selected-slave <instance details>：Sentinel 顺利找到适合进行升级的从服务器。
· failover-state-send-slaveof-noone <instance details>：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
· failover-end-for-timeout <instance details>：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
· failover-end <instance details>：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
· +switch-master <master name> <oldip> <oldport> <newip> <newport>：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
· +tilt：进入 tilt 模式。
    -tilt：退出 tilt 模式。