用 docker 学习 redis 主从复制3.2 redis-sentinel「哨兵模式」核心配置-命令-原理

核心配置

更多配置在 redisdoc.com/topic/sentinel

1. sentinel 可监控多个主节点，通过命名来区分，例如master1 master2 ..

    sentinel monitor master1 172.10.0.5 2
    sentinel monitor master2 ..

2. 哨兵判断主节点下线的标准

    #Sentinel 会 ping 每个节点，如果超过30秒依然没有回复的话，做下线的判断
    sentinel down-after-milliseconds mymaster 30000

3. 什么是主观下线和客观下线
   其中一台 sentinel 认为主节点下线了，称为「主观的」，当 n 台都认为它下线了，称为「客观的」。n 就是第一点配置最后边的数字 2。当客观下线时，就开启故障转移。

4. 故障转移之后限制向新节点发起复制的个数
   sentinel 领导者做故障转移工作，它会发送给每个从节点向新的主节点发起复制的命令，此参数决定这个步骤是 并发还是串行。
   
   如果主节点的从节点过多，设置合适的值，可减少主节点的压力。

    #`1`代表每次只能复制一个
    sentinel parallel-syncs mymaster 1

5. 配置连接受监控的主节点的密码

    sentinel auth-pass <master-name> <password>

sentinel 命令

首先连接任一台 sentinel (不需要进入容器)，22531 是 sentinel1 的外映射端口 22531=>26379

[root@VM-0-8-centos ~]# redis-cli -p 22531
127.0.0.1:22531>

1. 命令行方式添加、删除监控主节点
   在之前配置 sentinel 时是从 /etc/redis-sentinel.conf中修改的，然而还可以通过命令行方式配置

    127.0.0.1:22531> sentinel monitor test 127.0.0.1 6666 2
    OK
    127.0.0.1:22531> sentinel remove test
    OK

2. 显示监控的所有 masters 以及它们的状态

    SENTINEL masters

    127.0.0.1:22531> SENTINEL masters
    1)  1) "name"
        2) "mymaster" #自定义名称
        3) "ip"
        4) "172.10.0.5"
        5) "port"
        6) "6379"
        ..

3. 显示指定 master 的信息和状态

    SENTINEL master <master name>

    127.0.0.1:22531> SENTINEL master mymaster
     1) "name"
     2) "mymaster"
    3) ...

4. 显示指定 master 的所有从节点

    SENTINEL slaves <master name>

    127.0.0.1:22531> SENTINEL slaves mymaster
    1)  1) "name"
        2) "172.10.0.2:6379"
        3) "ip"
        4) "172.10.0.2"
        5) "port"
        6) "6379"
        ...
    2)  1) "name"
        2) "172.10.0.4:6379"
        3) "ip"
        4) "172.10.0.4"
        ...

5. 返回指定 master 的 ip 和端口。，如果正在进行 failover 或者failover 已经完成，将会显示被提升为 master 的 slave 的 ip 和端口。

    SENTINEL get-master-addr-by-name <master name>

    127.0.0.1:22531> SENTINEL get-master-addr-by-name mymaster
    1) "172.10.0.5"
    2) "6379"

6. 强制 sentinel 执行 failover，并且不需要得到其他 sentinel 的同意。但是 failover 后会将最新的配置发送给其他 sentinel。

    SENTINEL failover <master name>

   提示：当前的 cli 是sentinel1 节点，那么就由 sentinel1 节点执行故障转移。

    127.0.0.1:22531> sentinel failover mymaster
    OK

   sentinel1 日志

    //收到命令
    # Executing user requested FAILOVER of 'mymaster'
    //递增集群状态版本号，这个版本号将被接下来选举出的新的master采用。
    # +new-epoch 4
    //开始对名为"mymaster"的Redis集群进行故障转移
    # +try-failover master mymaster 172.10.0.5 6379
    //投票给自己做领导者
    # +vote-for-leader b0d33c8c68f57a0e3e628bf5cded4419a492177c 4
    //选择领导者完毕（就是自己）
    # +selected-leader master mymaster 172.10.0.5 6379
    ...

   sentinel2 和 sentinel3 日志

    # +new-epoch 4
    # +config-update-from sentinel b0d33c8c68f57a0e3e628bf5cded4419a492177c 172.10.0.11 26379 @ mymaster 172.10.0.5 6379
    # +switch-master mymaster 172.10.0.5 6379 172.10.0.2 6379
    * +slave slave 172.10.0.4:6379 172.10.0.4 6379 @ mymaster 172.10.0.2 6379
    * +slave slave 172.10.0.5:6379 172.10.0.5 6379 @ mymaster 172.10.0.2 6379
    * +convert-to-slave slave 172.10.0.5:6379 172.10.0.5 6379 @ mymaster 172.10.0.2 6379

   可见 sentinel 集群并没有投票，sentinel1 直接完成了故障转移的工作（即使当前主节点是正常状态），然后将最新的配置发送给其他sentinel。

总结 sentinel 的原理

Sentinel 的实现原理，主要分为以下三个步骤。

1. 检测问题，主要讲的是三个定时任务，这三个内部的执行任务可以保证出现问题马上让 Sentinel 知道。

2. 发现问题，主要讲的是主观下线和客观下线。当有一台 Sentinel 机器发现问题时，它就会主观对它主观下线，但是当多个 Sentinel 都发现有问题的时候，才会出现客观下线。

3. 找到解决问题的人，主要讲的是领导者选举，如何在 Sentinel 内部多台节点做领导者选举，选出一个领导者。

4. 解决问题，主要讲的是故障转移，即如何进行故障转移。

Sentinel 内部的三个定时任务。

每10秒每个 Sentinel 对 Master 和 Slave 执行一次 Info Replication。
每2秒每个 Sentinel 通过 Master 节点的 channel 交换信息（pub/sub）。
每1秒每个 Sentinel 对其他 Sentinel 和 Redis 执行 ping。

第一个定时任务，指的是 Redis Sentinel 可以对 Redis 节点做失败判断和故障转移，在 Redis 内部有三个定时任务作为基础，来 Info Replication 发现 Slave 节点，这个命令可以确定主从关系。

第二个定时任务，类似于发布订阅，Sentinel 会对主从关系进行判定，通过_sentinel_:hello 频道交互。了解主从关系可以帮助更好的自动化操作 Redis。然后 Sentinel 会告知系统消息给其它 Sentinel 节点，最终达到共识，同时 Sentinel 节点能够互相感知到对方。

第三个定时任务，指的是对每个节点和其它 Sentinel 进行心跳检测，它是失败判定的依据。

sentinel 如何选择「合适的 Slave」 节点

Redis 内部其实是有一个优先级配置的，在配置文件中 slave-priority，这个参数是 Salve 节点的优先级配置，如果存在则返回，如果不存在则继续。

当上面这个优先级不满足的时候，Redis 还会选择复制偏移量最大的 Slave节点，如果存在则返回，如果不存在则继续。之所以选择偏移量最大，这是因为偏移量越小，和 Master 的数据越不接近，现在 Master挂掉了，说明这个偏移量小的机器数据也可能存在问题，这就是为什么要选偏移量最大的 Slave 的原因。

如果发现偏移量都一样，这个时候 Redis 会默认选择 runid 最小的节点。

本作品采用《CC 协议》，转载必须注明作者和本文链接