Redis（三）哨兵集群（sentinel）原理解释与实战配置部署

Redis哨兵集群（sentinel）原理解释与实战配置部署

Redis-哨兵简介:

(redis-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的监控目标会随之调换
端口：26379
配置文件：sentinel.conf
使用协议：tcp

Sentinel系统时刻监控着主和从，当主挂掉后选择其中一个从来升任成主，可以启动多个Sentinel来避免监控挂掉，但多个Sentinel它们要投票

哨兵工作原理：

• 01 在一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令来获得redis主从的节点信息
• 02 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
• 03 每2秒，会订阅获取一下主节点的哨兵信息，来了解哨兵们的信息，有新的哨兵加入，将会记录新哨兵信息，并与他建立连接
• 04 每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
• 05 如果一个 实例 距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
• 06 当主观下线的节点是 Master 时，则询问其他哨兵，超过一定个数则判断主节点挂掉，进行客观下线。
• 07 当需要对一个 Master 进行客观下线，就需要在 Sentinel 们中选举一个领导者来执行这个操作，对 Master 进行下线，选举才用Raft算法
• 08 若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
• 09 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
• 10 当对一个 Master 进行客观下线后，会从其它从中选择出一个执行slaveof no one命令，使其升级为主节点。
• 11 向其它从节点发送命令，指定新主，并对新主进行数据复制
• 12 当原坏掉的主恢复后，将会作为新主的从节点
• 13 如果原坏掉的主删除不恢复，Sentinel依然会定期检测，会造成一定资源浪费

主观下线和客观下线：

主观下线：

Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断，这个判断只是认为，但并不做任何动作

客观下线：

Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover

应用场景：

适合使用单点的redis，并有高可用需求的。因为始终是单台的redis，性能是有限度的，有更高需求可以选择集群。

在代码中，用jedis之类工具读取 Sentinel 的信息，获取当前没问题的主节点，进行写入操作即可。
当主挂掉，Sentinel会自动切换，只要对最新的主节点进行读写即可。

如果将主从做高可用，需要监控Sentinel的信息输出，将所有从节点做一个资源池，读将从资源池里找从节点进行。

Redis-哨兵部署：

• 假设三台redis服务器做哨兵，也可以部署部署三个哨兵同时监测redis集群主从状态。（暂时有问题）
• 当前文章基于redis主从复制集群之上部署，如为不是主从复制请移步：点击跳转

**系统：**CentOS-7.5
地址：

10.0.0.10   redis-01（master）
10.0.0.20   redis-02（slave）
10.0.0.30   redis-03（slave）
基于Redis主从复制环境的三台服务器操作

配置哨兵：（redis-01）

[root@db01 ~]# mkdir /data/26380 && vim /data/26380/sentinel.conf

#监听端口
port 26380
#数据存放目录
dir "/data/26380"
#定义Redis主库的地址与端口，名称为mymaster，（名称可以自定义），1代表是只要有1台sentinel认为主库宕机，那就切换
sentinel monitor mymaster 10.0.0.10 6379 1
#定义5000毫秒联系不上mymaster主库，就认为主库宕机了
sentinel down-after-milliseconds mymaster 5000
#告诉哨兵自定义的mymaster的认证密码
sentinel auth-pass mymaster redhat

其他配置：

# 守护进程模式
daemonize yes

# 指明日志文件名
logfile "/usr/local/redis/26379/sentinel.log"

创建命令软链接：（redis-01）

[root@db01 ~]# ln -s /usr/local/redis-5.0.2/src/redis-sentinel /usr/sbin/

启动哨兵：（redis-01）

[root@db01 ~]# redis-sentinel /data/26380/sentinel.conf &

测试哨兵可用性：

#'停掉主库，测试能否自定切换
[root@db01 ~]# redis-cli -h 10.0.0.10 -p 6379 -a redhat shutdown

重启源主库edis后：

#自动切换源主库为从库

加入systemd管理：

配置文件：

• 要指定pid文件

port 26379
daemonize yes
logfile "/usr/local/redis/26379/sentinel.log"
pidfile /usr/local/redis/26379/sentinel.pid
dir "/usr/local/redis-4.0.10/26379"
sentinel monitor mymaster 10.0.0.10 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel auth-pass mymaster 123456

加入systemd：

[root@db01 ~]# vim /lib/systemd/system/redis-26379.service
[Unit]
Description=Redis
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/usr/local/redis/26379/sentinel.pid
ExecStart=/usr/sbin/redis-sentinel /usr/local/redis/26379/sentinel.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

使用systemd管理哨兵：

[root@db01 ~]# systemctl restart redis-26379.service

哨兵常用参数与命令：

常用命令：

sentinel的基本状态信息
INFO

列出所有被监视的主服务器，以及这些主服务器的当前状态
SENTINEL masters

列出指定主redis的从节点状态情况
SENTINEL slaves <master-name>

列出指定主redis的监控哨兵信息，不包含他自己
SENTINEL sentinels <master-name>

返回给定名字的主服务器的 IP 地址和端口号
SENTINEL get-master-addr-by-name <master-name>

重置所有名字和给定模式 pattern 相匹配的主服务器。重置操作清除主服务器目前的所有状态，包括正在执行中的故障转移，并移除目前已经发现和关联的，主服务器的所有从服务器和 Sentinel 。
SENTINEL <master-name>

当主服务器失效时 在不询问其他 Sentinel 意见的情况下，强制开始一次自动故障迁移，但是它会给其他sentinel发送一个最新的配置，其他sentinel会根据这个配置进行更新
SENTINEL failover <master-name>

检查当前在线的哨兵节点。如果一共有5个节点，设置4票，但检查后只有3节点在线，那一直无法进行监控切换
sentinel ckquorum <master-name>

将配置强制刷新到本地文件
sentinel flushconfig

取消当前哨兵对某主节点的监控
sentinel remove <master name>

配置文件参数：

#<master-name>是主节点的名称，也就是可以同时监控多组主从
#主节点的地址和端口
#quorum是票数，需要几个哨兵节点认为有问题才进行操作
sentinel monitor <master-name> <ip> <port> <quorum>

#哨兵每隔一段时间就检测主节点是否存活，当超过<times>指定的时间，则认为主节点死掉
#虽然看似是对主控制，其实对从节点，其他哨兵节点也是这个参数控制
#默认30000，单位毫秒
sentinel down-after-milliseconds <master-name> <times>

#当主节点挂掉，新的主节点接替时，从节点会向新的主节点发起复制操作。这个参数控制同时发起复制操作的从节点个数。
#如果有一个新主，3个从，而<nums>设置为1。从节点会轮询复制
sentinel parallel-syncs <master-name> <nums>

#选出合适从节点，切换从为主，让其他从复制新主，让上线的坏主复制新主
#以上4部每个阶段故障时间超过<times>则认为失败
sentinel failover-timeout <master-name> <times>

#如果主节点有密码，需要配置密码，防止无法获取主节点信息
sentinel auth-pass <master-name> <password>

#当有重要事件，例如客观下线，主观下线时，将执行指定的脚本，并将一些相关参数传进去，可以发送邮件来通知
sentinel notification-script <master-name> <script-path>

#当故障转移结束后触发的脚本，并将一些相关参数传进去
sentinel client-reconfig-script <master-name> <script-path>

#脚本必须可以执行，开头必须有 #!/bin/bash 脚本头
#脚本最大执行时间不能超过一分钟，超过将杀死脚本
#如果shell脚本以exit 1结束，那么脚本稍后重试执行。如果以exit 2或者更高的值结束，那么脚本不会重试。正常返回值是exit 0
#脚本将传入如下参数
#<master-name> 主节点名称
#<role> 当前哨兵的角色是leader还是observer
#<state> 状态，是关闭还是启动
#<from-ip> 原主节点的ip
#<from-port> 原主节点的端口
#<to-ip> 新主节点的ip
#<to-port> 新主节点的端口

哨兵日志：