Redis哨兵原理，我忍你很久了( 二 ) _Redis

这个值越小完成故障转移的时间就越长，这个值越大就意味着越多的从节点因为同步数据而不可用。
⑥sentinel failover-timeout mymaster 180000：在进行同步的过程中，多长时间完成算有效，系统默认值是 3 分钟。
开始配置
使用命令 cat sentinel.conf | grep -v '#' | grep -v '^$' >
./data/sentinel-26379.conf 把 sentinel.conf 过滤后的信息移到 /usr/local/redis/conf 下。

文章插图

然后打开 sentinel-26379.conf 修改信息存放目录：

文章插图

再快速的复制两个哨兵配置文件，端口为 26380 和 26381：
sed 's/26379/26381/g' sentinel-26379.conf > sentinel-26381.conf

文章插图

测试主从复制处于正常工作状态，启动三台 redis 服务器，端口分别为 6379、6380、6381：

文章插图

查看主节点信息，是有俩台从节点在连接着，端口分别为 6380、6381 。
这里有一个小小的点就是 lag 怎么一个是 1 一个是 0 呢？lag 是延迟时间，我这里是本地测试所以会出现 0 的情况，使用云服务器是很少出现的。
lag 的值为 0 和 1 都属于正常。

文章插图

测试主节点添加一个 hash 值，hset kaka name kaka：

文章插图

分别从 slave1 和 slave2 获取 kaka 的值，检测主从复制是否正常运行。
经过测试我们的主从结构是正常运行的，如下图：

文章插图

文章插图

启动一个哨兵 redis-sentinel 26379-sentinel.conf：

文章插图

连接 26379 哨兵，主要是最后一行，监控的主节点名为 mymaster，状态正常，从节点有俩个，哨兵数量为 1 个。

文章插图

再来查看一下 26379 的哨兵配置信息，这个时候已经改动了：

文章插图

在启动一个 26380 的哨兵，redis-sentinel 26380-sentinel.conf，这里注意一下最后一行多了一条信息，这个 id 就是我们 26379 配置文件新增的 id 。

文章插图

然后我们来到哨兵 26379 的客户端，同样也是新增的 26380 哨兵的 id：

文章插图

这个时候我们再查看一下 26379 哨兵的配置文件，第一次查看配置文件是没有配置 26380 哨兵的，第二次查看时配置了 26380 哨兵后添加的信息。

文章插图

最后我们需要把哨兵客户端 3 启动起来，端口号为 26381 。启动起来之后，我们的配置信息和服务端的信息也会改动，添加哨兵 26380 有的信息，哨兵 26381 也会有。
直到这里我们对哨兵的配置就结束了，接下来我们把主节点 Master 给宕掉。

文章插图

等待 30 秒后我们来到 26379 哨兵的客户端，这里新增了一些信息，那么这些信息都做了什么呢？让我们细细道来。

文章插图

这里边的信息我们先需要知道几个：
①+sdown：这个信息后是指三个哨兵里边有一个认为主节点宕机了。
②+odown：这个信息是指其他俩个哨兵去连接了一下主节点，发现确实是主节点宕机了，然后发起了一轮投票。这里使用的是 redis 4.0，版本之间这块信息有点差异。
③+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380：直到这里是哨兵发起投票的结果，推选端口为 6380 的 redis 为主节点。
④+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380：这里就把端口为 6381 与 6379 和新的主节点 6380 做了一个连接。