Sentinel模式下的主从切换

根据redis官网的哨兵模式文档：http://redis.io/topics/sentinel

可以知道sentinel有监控 通知 自动故障转移 以及配置信息的提供的功能

在上一篇文档中,描述了Redis的主从配置。现在我们就接着上面的继续朝着高可用进发吧。

为了方便，我的主从配置的实例配置都是在同一台机器上。同样所启用的sentinel实例也是在同一机器上。

首先启动redis

根据信息可以看到主从配置信息：

6379 master 6380 slave 6381 slave 

主从配置的实例已经启动完成

下面sentinel实例启动

根据官方文档中的建议，我们使用三个sentinel实例来进行操作

Port sentinel实例启动后占用的端口

Demonize 是否是后台启动

Logfile 日志保存位置

第五行则是 实例要监控的主服务器信息 包括为服务器起得名字mymaster ip port 以及quorum（就是至少要多少个哨兵认为这个主库挂了，才算真的挂了，即客观下线 ODown，具体详细可以查看官网文档）

down-after-milliseconds mymaster 5000这个就是当哨兵在发出ping命令后的5S内没有收到回复则认为该库主观下线

failover-timeout：则是当在选出leader哨兵多久后进行故障转移。

Config-epocf 则表示当前的配置版本号

我把三个文档的配置文件放在了跟redis配置文件系统的地方

三个配置文件的信息除了端口外完全相同

接下来启动redis的三个哨兵实例

我们在查看5000端口上的哨兵实例的日志文件中可以看到如下内容

第一行是哨兵启动运行id

然后就是发现主服务器 发现主库的从服务器 发现监测这个主库的其他哨兵实例。最后发现其他的两个哨兵实例则是在他们启动后被发现并被加入监控。具体哨兵之间的相互监控官网文档中说了很多的优势。这里就不细说了

 

当再一次打开这个实例的配置文件则会发现配置文件中新增了一些东西

可以看出sentinel把当前的redis的主从信息保存进行了配置文件中。

最终能够看到的关于redis的进程则显示如下

接下来我们停止主库

接下来我们查看哨兵的日志文件

当我们再查看5000端口上的sentinel配置文件信息，可以发现6380端口的redis实例已经变成了主库,而6379则变成了从库

同样根据6379端口的redis实例 可以看到 slaveof 已经配置到了6380上

当我们再次把6379端口的redis实例启动时

则会发现sentinel日志中的信息增加了6379取消了主观下线的信息

至此基于sentinel的主从配置全部完成