Wetts's blog

Stay Hungry, Stay Foolish.

0%

Redis-主从切换-sentinel（哨兵机制）

发表于 分类于

转自：http://www.cnblogs.com/zhoujinyi/p/5569462.html

一

概述

Redis-Sentinel 是 Redis 官方推荐的高可用性（HA）解决方案，当用 Redis 做 Master-slave 的高可用方案时，假如 master 宕机了，Redis 本身（包括它的很多客户端）都没有实现自动进行主备切换，而 Redis-sentinel 本身也是一个独立运行的进程，它能监控多个 master-slave 集群，发现 master 宕机后能进行自动切换。

它的主要功能有以下几点

  • 不时地监控 redis 是否按照预期良好地运行；
  • 如果发现某个 redis 节点运行出现状况，能够通知另外一个进程（例如它的客户端）；
  • 能够进行自动切换。当一个 master 节点不可用时，能够选举出 master 的多个 slave（如果有超过一个 slave 的话）中的一个来作为新的 master，其它的 slave 节点会将它所追随的 master 的地址改为被提升为 master 的 slave 的新地址。

Sentinel 支持集群

很显然，只使用单个 sentinel 进程来监控 redis 集群是不可靠的，当 sentinel 进程宕掉后（sentinel 本身也有单点问题，single-point-of-failure）整个集群系统将无法按照预期的方式运行。所以有必要将 sentinel 集群，这样有几个好处：

  • 即使有一些 sentinel 进程宕掉了，依然可以进行 redis 集群的主备切换；
  • 如果只有一个 sentinel 进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现 redis 集群的主备切换（单点问题）;
  • 如果有多个 sentinel，redis 的客户端可以随意地连接任意一个 sentinel 来获得关于 redis 集群中的信息。

运行 Sentinel

运行 sentinel 有两种方式：

  1. ```
    redis-sentinel /path/to/sentinel.conf
    1
    2
    2. ```
       redis-server /path/to/sentinel.conf --sentinel

以上两种方式，都必须指定一个 sentinel 的配置文件 sentinel.conf，如果不指定，将无法启动 sentinel。sentinel 默认监听 26379 端口，所以运行前必须确定该端口没有被别的进程占用。

Sentinel 的配置

Redis 源码包中包含了一个 sentinel.conf 文件作为 sentinel 的配置文件，配置文件自带了关于各个配置项的解释。典型的配置项如下所示：

1
2
3
4
5
6
7
8
9
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

上面的配置项配置了两个名字分别为 mymaster 和 resque 的 master，配置文件只需要配置 master 的信息就好啦，不用配置 slave 的信息，因为 slave 能够被自动检测到（master 节点会有关于 slave 的消息）。需要注意的是，配置文件在 sentinel 运行期间是会被动态修改的，例如当发生主备切换时候，配置文件中的 master 会被修改为另外一个 slave。这样，之后 sentinel 如果重启时，就可以根据这个配置来恢复其之前所监控的 redis 集群的状态。

接下来我们将一行一行地解释上面的配置项：

1
sentinel monitor mymaster 127.0.0.1 6379 2

这一行代表 sentinel 监控的 master 的名字叫做 mymaster，地址为 127.0.0.1:6379，行尾最后的一个 2 代表什么意思呢？我们知道，网络是不可靠的，有时候一个 sentinel 会因为网络堵塞而误以为一个 master redis 已经死掉了，当 sentinel 集群式，解决这个问题的方法就变得很简单，只需要多个 sentinel 互相沟通来确认某个 master 是否真的死了，这个 2 代表，当集群中有 2 个 sentinel 认为 master 死了时，才能真正认为该 master 已经不可用了。（sentinel 集群中各个 sentinel 也有互相通信，通过 gossip 协议）。

除了第一行配置，我们发现剩下的配置都有一个统一的格式:

1
sentinel <option_name> <master_name> <option_value>

接下来我们根据上面格式中的 option_name 一个一个来解释这些配置项：

  • down-after-milliseconds
    • sentinel 会向 master 发送心跳 PING 来确认 master 是否存活，如果 master 在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个 sentinel 会主观地（单方面地）认为这个 master 已经不可用了（subjectively down, 也简称为 SDOWN）。而这个 down-after-milliseconds 就是用来指定这个“一定时间范围”的，单位是毫秒。
    • 不过需要注意的是，这个时候 sentinel 并不会马上进行 failover 主备切换，这个 sentinel 还需要参考 sentinel 集群中其他 sentinel 的意见，如果超过某个数量的 sentinel 也主观地认为该 master 死了，那么这个 master 就会被客观地（注意哦，这次不是主观，是客观，与刚才的 subjectively down 相对，这次是 objectively down，简称为 ODOWN）认为已经死了。需要一起做出决定的 sentinel 数量在上一条配置中进行配置。
  • parallel-syncs
    • 在发生 failover 主备切换时，这个选项指定了最多可以有多少个 slave 同时对新的 master 进行同步，这个数字越小，完成 failover 所需的时间就越长，但是如果这个数字越大，就意味着越多的 slave 因为 replication 而不可用。可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态。
  • 其他配置项在 sentinel.conf 中都有很详细的解释。

所有的配置都可以在运行时用命令 SENTINEL SET command 动态修改。

转自：https://blog.csdn.net/yswKnight/article/details/78158540

二

什么是哨兵机制?

Redis 的哨兵（sentinel）系统用于管理多个 Redis 服务器，该系统执行以下三个任务:

  1. 监控（Monitoring）：哨兵（sentinel）会不断地检查你的 Master 和 Slave 是否运作正常。
  2. 提醒（Notification）：当被监控的某个 Redis 出现问题时，哨兵（sentinel）可以通过 API 向管理员或者其他应用程序发送通知。
  3. 自动故障迁移（Automatic failover）：当一个 Master 不能正常工作时，哨兵（sentinel）会开始一次自动故障迁移操作，它会将失效 Master 的其中一个 Slave 升级为新的 Master，并让失效 Master 的其他 Slave 改为复制新的 Master；当客户端试图连接失效的 Master 时，集群也会向客户端返回新 Master 的地址，使得集群可以使用 Master 代替失效 Master。

哨兵（sentinel）是一个分布式系统，你可以在一个架构中运行多个哨兵（sentinel）进程，这些进程使用流言协议（gossip protocols）来接收关于 Master 是否下线的信息，并使用投票协议（agreement protocols）来决定是否执行自动故障迁移，以及选择哪个 Slave 作为新的 Master。

哨兵（sentinel）会向其它哨兵（sentinel）、master、slave 定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的”主观认为宕机” Subjective Down，简称 sdown）.

若“哨兵群”中的多数 sentinel，都报告某一 master 没响应，系统才认为该 master “彻底死亡”（即:客观上的真正down 机，Objective Down，简称 odown），通过一定的 vote 算法，从剩下的 slave 节点中，选一台提升为 master，然后自动修改相关配置。

虽然哨兵（sentinel）释出为一个单独的可执行文件 redis-sentinel，但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵（sentinel）。

哨兵（sentinel）的一些设计思路和 zookeeper 非常类似
1

哨兵模式的配置修改

实现步骤:

  1. 拷贝到 etc 目录
    • cp sentinel.conf /usr/local/redis/etc
  2. 修改 sentinel.conf 配置文件
    • sentinel monitor mymast 192.168.110.133 6379 1 #主节点 名称 IP 端口号 选举次数
    • #配置主服务器的密码(如没设置密码，可以省略)
    • sentinel auth-pass mymaster 123456
  3. 修改心跳检测 5000 毫秒
    • sentinel down-after-milliseconds mymaster 5000
  4. 做多多少合格节点
    • sentinel parallel-syncs mymaster 2
  5. 启动哨兵模式
    • ./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
  6. 停止哨兵模式

注意：

  1. 当启动哨兵模式之后，如果你的 master 服务器宕机之后，哨兵自动会在从 redis 服务器里面投票选举一个 master 主服务器出来；这个主服务器也可以进行读写操作！
  2. 如果之前宕机的主服务器已经修好，可以正式运行了。那么这个服务器只能进行读的操作，会自动跟随由哨兵选举出来的新服务器！
  3. 大家可以进入 ./redis-cli，输入 info，查看你的状态信息；

2

哨兵（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 的客观下线状态就会被移除。
  8. 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。