Redis(开发与运维):43---Sentinel之（哨兵的安装与部署、哨兵配置参数、部署技巧、哨兵API）

一、哨兵的安装与部署

• 上一篇文章介绍了Redis Sentinel的基本架构，下面将介绍如何安装和部署Redis Sentinel
• 下面以3个Sentinel节点、1个主节点、2个从节点组成一个Redis Sentinel进行说明，拓扑结构如下图所示

①部署主节点

• 主节点的地址为127.0.0.1:6379。配置文件为/opt/redis/conf/redis-6379.conf，下面列出了部分选项值：

port        6379
daemonize   yes
logfile     6379.log
dbfilename  dump-6379.rdb
dir         /opt/redis/data/

• 启动主节点：

sudo redis-server /opt/redis/conf/redis-6379.conf

 

• 检测主节点是否启动成功：

redis-cli -h 127.0.0.1 -p 6379 ping

• 此时的拓扑图如下所示：

②启动从节点1（127.0.0.1:6380）

• 从节点1的地址为127.0.0.1:6380。配置文件为/opt/redis/conf/redis-6380.conf，下面列出了部分选项值：

port        6380
daemonize   yes
logfile     6380.log
dbfilename  dump-6380.rdb
dir         /opt/redis/data/
slaveof     127.0.0.1 6379

• 启动从节点1：

sudo redis-server /opt/redis/conf/redis-6380.conf

• 检测从节点1是否启动成功：

redis-cli -h 127.0.0.1 -p 6380 ping

 

③启动从节点2（127.0.0.1:6381）

• 从节点2的地址为127.0.0.1:6381。配置文件为/opt/redis/conf/redis-6381.conf，下面列出了部分选项值：

port        6381
daemonize   yes
logfile     6381.log
dbfilename  dump-6381.rdb
dir         /opt/redis/data/
slaveof     127.0.0.1 6379

• 启动从节点2：

sudo redis-server /opt/redis/conf/redis-6381.conf

 

• 检测从节点2是否启动成功：

redis-cli -h 127.0.0.1 -p 6381 ping

 

④确认主从关系

• 主节点：查看复制的相关信息，有两个从节点127.0.0.1:6380和127.0.0.1:6381

redis-cli -h 127.0.0.1 -p 6379 info replication

• 从节点1：查看复制的相关信息，其复制的主节点为127.0.0.1:6379

redis-cli -h 127.0.0.1 -p 6380 info replication

 

• 从节点2：查看复制的相关信息，其复制的主节点为127.0.0.1:6379

redis-cli -h 127.0.0.1 -p 6381 info replication

 

• 此时的拓扑图如下所示：

⑤启动Sentinel节点1（127.0.0.1:26379）

• sentinel节点1的地址为127.0.0.1:26379。配置文件为/opt/redis/conf/redis-sentinel-26379.conf，下面列出了部分选项值：
  • sentinel节点的默认配置端口为26379
  • sentinel monitor：代表该sentinel节点监控的是127.0.0.1:6379这个主节点，mymaster代表主节点的别名，2代表主节点失败至少需要2个sentinel节点同意
  • 其余选项在下面介绍

port 26379
daemonize yes
logfile 26379.log
dir /opt/redis/data/

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

• 启动Sentinel节点1：启动sentinel节点的方式有两种，两种方法的本质是一样的

# 方法一：通过redis-sentinel命令
sudo redis-sentinel /opt/redis/conf/redis-sentinel-26379.conf

# 方法二：通过redis-server加--sentinel参数
sudo redis-server /opt/redis/conf/redis-sentinel-26379.conf --sentinel

启动Sentinel节点2（127.0.0.1:26380）

• sentinel节点2的地址为127.0.0.1:26380。配置文件为/opt/redis/conf/redis-sentinel-26380.conf，下面列出了部分选项值：

port 26380
daemonize yes
logfile 26380.log
dir /opt/redis/data/

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

• 启动Sentinel节点2：

sudo redis-sentinel /opt/redis/conf/redis-sentinel-26380.conf

启动Sentinel节点3（127.0.0.1:26381）

• sentinel节点3的地址为127.0.0.1:26381
• 配置文件为/opt/redis/conf/redis-sentinel-26381.conf，下面列出了部分选项值：

port 26381
daemonize yes
logfile 26381.log
dir /opt/redis/data/

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

• 启动Sentinel节点3： 

sudo redis-sentinel /opt/redis/conf/redis-sentinel-26381.conf

⑥确认

• Sentinel节点本质上是一个特殊的Redis节点，所以也可以通过info命令来查询它的相关信息

redis-cli -h 127.0.0.1 -p 26379 info sentinel

• 结果如下所示：
  • Sentinel节点找到了主节点127.0.0.1：6379，发现了它的两个从节点（slaves），同时发现Redis Sentinel一共有3个Sentinel节点（sentinels ）
  • 这里只需要了解Sentinel节点能够彼此感知到对方，同时能够感知到Redis数据节点就可以了

• 当三个Sentinel节点都启动后，整个拓扑结构如下图所示：

• 至此Redis Sentinel已经搭建起来了，整体上还是比较容易的，但是有2点需要强调一下：
  • 生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上
  • Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任何区别，只不过是添加了一些Sentinel节点对它们进行监控

二、哨兵配置参数

默认配置文件

• Redis安装目录下有一个sentinel.conf，是默认的Sentinel节点配置文件，配置的参数如下所示：

port 26379
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
#sentinel auth-pass <master-name> <password>
#sentinel notification-script <master-name> <script-path>
#sentinel client-reconfig-script <master-name> <script-path>

• port和dir分别代表Sentinel节点的端口和工作目录，下面对其他参数进行介绍

sentinel monitor

• 格式如下：

sentinel monitor <master-name> <ip> <port> <quorum>

• 参数如下：
  • 本配置说明此Sentinel节点要监控的是一个名字叫做<master-name>，ip地址和端口为<ip> <port>的主节点
  • <quorum>代表要判定主节点最终不可达所需要的票数。但实际上Sentinel节点会对所有节点进行监控，但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置，那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息，有关这 部分是如何实现的，将在后面“sentinel实现原理”文章中介绍
    • <quorum>参数用于故障发现和判定：例如将quorum配置为2，代表至少有2个Sentinel节点认为主节点不可达，那么这个不可达的判定才是客观的。 对于<quorum>设置的越小，那么达到下线的条件越宽松，反之越严格。一 般建议将其设置为Sentinel节点的一半加1
    • 同时<quorum>还与Sentinel节点的领导者选举有关：至少要有 max(quorum，num(sentinels)/2+1)个Sentinel节点参与选举，才能选出领导者Sentinel，从而完成故障转移。例如有5个Sentinel节点，quorum=4，那么 至少要有max(quorum，num(sentinels)/2+1)=4个在线Sentinel节点才可以 进行领导者选举
• 例如某个Sentinel初始节点配置如下：

port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

• 当所有节点启动后，配置文件中的内容发生了变化，体现在三个方面：
  • Sentinel节点自动发现了从节点、其余Sentinel节点
  • 去掉了默认配置，例如parallel-syncs、failover-timeout参数
  • 添加了配置纪元相关参数
• 启动后变化为：

port 26379
daemonize yes
logfile "26379.log"
dir "/opt/soft/redis/data"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0

#发现两个slave节点
sentinel known-slave mymaster 127.0.0.1 6380
sentinel known-slave mymaster 127.0.0.1 6381

#发现两个sentinel节点
sentinel known-sentinel mymaster 127.0.0.1 26380 282a70ff56c36ed56e8f7ee6ada74124140d6f53
sentinel known-sentinel mymaster 127.0.0.1 26381 f714470d30a61a8e39ae031192f1feae7eb5b2be
sentinel current-epoch 0

sentinel down-after-milliseconds

• 格式如下：

sentinel down-after-milliseconds <master-name> <times>

• 每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达，<times>（单位为毫秒）就是超时时间
• 这个配置是对节点失败判定的重要依据
• 优化说明：down-after-milliseconds越大，代表Sentinel节点对于节点不可达的条件越宽松，反之越严格。条件宽松有可能带来的问题是节点确实不可 达了，那么应用方需要等待故障转移的时间越长，也就意味着应用方故障时 间可能越长。条件严格虽然可以及时发现故障完成故障转移，但是也存在一 定的误判率
• 运维提示：down-after-milliseconds虽然以<master-name>为参数，但实际上对Sentinel节点、主节点、从节点的失败判定同时有效

sentinel parallel-syncs

• 格式如下：

sentinel parallel-syncs <master-name> <nums>

• 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作
• parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大，那么多个从节点会向新的主节点同时发起复制操作，尽管复制操作通常不会阻塞主节点， 但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和磁盘IO开销
• 下图展示了一个案例，parallelsyncs=3会同时发起复制，parallel-syncs=1时从节点会轮询发起复制

sentinel failover-timeout

• 格式如下：

sentinel failover-timeout <master-name> <times>

• failover-timeout通常被解释成故障转移超时时间，但实际上它作用于故障转移的各个阶段：
  • a）选出合适从节点
  • b）晋升选出的从节点为主节点
  • c）命令其余从节点复制新的主节点
  • d）等待原主节点恢复后命令它去复制新的主节点
• failover-timeout的作用具体体现在四个方面：
  • 1）如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主 节点做故障转移的起始时间是failover-timeout的2倍
  • 2）在b）阶段时，如果Sentinel节点向a）阶段选出来的从节点执行slaveof no one一直失败（例如该从节点此时出现故障），当此过程超过 failover-timeout时，则故障转移失败
  • 3）在b）阶段如果执行成功，Sentinel节点还会执行info命令来确认a） 阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failovertimeout时，则故障转移失败
  • 4）如果c）阶段执行时间超过了failover-timeout（不包含复制时间）， 则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从 节点去同步最新的主节点

sentinel auth-pass

• 格式如下：

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

• 如果Sentinel监控的主节点配置了密码，sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点对主节点无法监控。

sentinel notification-script

• 配置如下：

sentinel notification-script <master-name> <script-path>

• 该配置的作用是在故障转移期间，当一些警告级别的Sentinel事件发生（指重要事件，例如-sdown：客观下线、-odown：主观下 线）时，会触发对应路径的脚本，并向脚本发送相应的事件参数
• 例如在/opt/redis/scripts/下配置了notification.sh，该脚本会接收每个Sentinel节点传过来的事件参数，可以利用这些参数作为邮件或者短信报警依据：

#notification.sh
#!/bin/sh
#获取所有参数
msg=$*
#报警脚本或者接口，将msg作为参数
exit 0

• 如果需要该功能，就可以在Sentinel节点添加如下配置：

sentinel notification-script mymaster /opt/redis/scripts/notification.sh

• 例如下面就是某个Sentinel节点对主节点做了主观下线（有关主观下线的概念在后面文章介绍）后脚本收到的参数：

+sdown master mymaster 127.0.0.1 6379

sentinel client-reconfig-script

• 配置如下：

sentinel client-reconfig-script <master-name> <script-path>

• 该选项的作用是在故障转移结束后，会触发对应路径的脚本，并向脚本发送故障转移结果的相关参数
• 例如在/opt/redis/scripts/下配置了client-reconfig.sh，该脚本会接收每个Sentinel节点传过来的故障转移结果参数，并触发类似短信和邮件报警：

# client-reconfig.sh
#!/bin/sh
#获取所有参数
msg=$*
#报警脚本或者接口，将msg作为参数
exit 0

• 如果需要该功能，就可以在Sentinel节点添加如下配置：

sentinel client-reconfig-script mymaster /opt/redis/scripts/client-reconfig.sh

• 当故障转移结束，每个Sentinel节点会将故障转移的结果发送给对应的脚本，具体参数如下：
  • <master-name>：主节点名
  • <role>：Sentinel节点的角色，分别是leader和observer，leader代表当前
  • Sentinel节点是领导者，是它进行的故障转移；observer是其余Sentinel节点
  • <from-ip>：原主节点的ip地址
  • <from-port>：原主节点的端口
  • <to-ip>：新主节点的ip地址
  • <to-port>：新主节点的端口

<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>

•  例如以下内容分别是三个Sentinel节点发送给脚本的，其中一个是leader，另外两个是observer：

mymaster leader start 127.0.0.1 6379 127.0.0.1 6380
mymaster observer start 127.0.0.1 6379 127.0.0.1 6380
mymaster observer start 127.0.0.1 6379 127.0.0.1 6380

• 有关sentinel notification-script和sentinel client-reconfig-script有几点需要注意：
  • <script-path>必须有可执行权限
  • Redis规定脚本的最大执行时间不能超过60秒，超过后脚本将被杀掉
  • 如果shell脚本以exit 1结束，那么脚本稍后重试执行。如果以exit 2或者 更高的值结束，那么脚本不会重试。正常返回值是exit 0
  • 如果需要运维的Redis Sentinel比较多，建议不要使用这种脚本的形式 来进行通知，这样会增加部署的成本。
  • <script-path>开头必须包含shell脚本头（例如#！/bin/sh），否则事件发生时Redis将无法执行脚本产生如下错误：

-script-error /opt/sentinel/notification.sh 0 2

三、配置参数的调整

• 和普通的Redis数据节点一样，Sentinel节点也支持动态地设置参数，而且和普通的Redis数据节点一样并不是支持所有的参数
• 格式如下：

sentinel set <param> <value>

• 下图是sentinel set命令支持的参数：

• 有几点需要注意一下：
  • 1）sentinel set命令只对当前Sentinel节点有效
  • 2）sentinel set命令如果执行成功会立即刷新配置文件，这点和Redis普通数据节点设置配置需要执行config rewrite刷新到配置文件不同
  • 3）建议所有Sentinel节点的配置尽可能一致，这样在故障发现和转移时比较容易达成一致
  • 4）上图中为sentinel set支持的参数，具体可以参考源码中的sentinel.c的 sentinelSetCommand函数
  • 5）Sentinel对外不支持config命令

四、监控多个节点

• Redis Sentinel可以同时监控多个主节点，具体拓扑图类似于下图所示

• 配置方法也比较简单，只需要指定多个masterName来区分不同的主节点即可。例如下面的配置监控monitor master-business-1和 monitor master-business-2两个主节点：

# 监控1
sentinel monitor master-business-1 10.10.xx.1 6379 2
sentinel down-after-milliseconds master-business-1 60000
sentinel failover-timeout master-business-1 180000
sentinel parallel-syncs master-business-1 1

# 监控2
sentinel monitor master-business-2 10.16.xx.2 6380 2
sentinel down-after-milliseconds master-business-2 10000
sentinel failover-timeout master-business-2 180000
sentinel parallel-syncs master-business-2 1

五、部署技巧

①Sentinel节点不应该部署在一台物理“机器”上

• 这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较 流行的容器，它们虽然有不同的IP地址，但实际上它们都是同一台物理机， 同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响
• 为了实现Sentinel节点集合真正的高可用，请勿将Sentinel节点部署在 同一台物理机器上

②部署至少3个且奇数个的Sentinel节点

• 3个以上是通过增加Sentinel节点的个数提高对于故障判定的准确性
• 因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点
• 有关Sentinel节点如何判断节点失败，如何选举出一个Sentinel节点进行故障转移将在后面“实现原理”文章介绍

③只有一套Sentinel，还是每个主节点配置一套Sentinel？

• Sentinel节点集合可以只监控一个主节点，也可以监控多个主节点，也就意味着部署拓扑可能有下面两种情况

• 下面分别分析两种方案的优缺点：
  • 方案一：一套Sentinel，很明显这种方案在一定程度上降低了维护成本，因为只需要维护固定个数的Sentinel节点，集中对多个Redis数据节点进行管理就可以了。但是这同时也是它的缺点，如果这套Sentinel节点集合出现异常，可能会对多个Redis数据节点造成影响。还有如果监控的Redis数据节点较多，会造成Sentinel节点产生过多的网络连接，也会有一定的影响
  • 方案二：多套Sentinel，显然这种方案的优点和缺点和上面是相反的， 每个Redis主节点都有自己的Sentinel节点集合，会造成资源浪费。但是优点 也很明显，每套Redis Sentinel都是彼此隔离的
• 运维提示：如果Sentinel节点集合监控的是同一个业务的多个主节点集合，那么使用方案一、否则一般建议采用方案二

五、哨兵API

• Sentinel节点是一个特殊的Redis节点，它有自己专属的API
• 为了方便演示，下面都以图进行说明：

sentinel masters

• 展示所有被监控的主节点状态以及相关的统计信息
• 例如：

sentinel master <master name>

• 展示指定<master name>的主节点状态以及相关的统计信息
• 例如：

sentinel slaves <master name>

• 展示指定<master name>的从节点状态以及相关的统计信息
• 例如：

sentinel sentinels <master name>

• 展示指定<master name>的Sentinel节点集合（不包含当前Sentinel节点）
• 例如：

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

• 返回指定<master name>主节点的IP地址和端口
• 例如：

sentinel reset <pattern>

• 当前Sentinel节点对符合<pattern>（通配符风格）主节点的配置进行重置，包含清除主节点的相关状态（例如故障转移），重新发现从节点和Sentinel节点
• 例如sentinel-1节点对mymaster-1节点重置状态如下：

sentinel failover <master name>

• 对指定<master name>主节点进行强制故障转移（没有和其他Sentinel节点“协商”），当故障转移完成后，其他Sentinel节点按照故障转移的结果更新自身配置
• 这个命令在Redis Sentinel的日常运维中非常有用，将在后面“开发与运维中的问题”一文中进行介绍：https://blog.csdn.net/qq_41453285/article/details/106419183
• 例如，对mymaster-2进行故障转移：

• 执行命令前，mymaster-2是127.0.0.1:6382

• 执行命令后：mymaster-2由原来的一个从节点127.0.0.1:6383代替

sentinel ckquorum <master name>

• 检测当前可达的Sentinel节点总数是否达到<quorum>的个数
• 见上面的sentinel monitor配置参数
• 例如quorum=3，而当前可达的Sentinel节点个数为2个，那么将无法进行故障转移，Redis Sentinel的高可用特性也将失去
• 例如：

sentinel flushconfig

• 将Sentinel节点的配置强制刷到磁盘上，这个命令Sentinel节点自身用得比较多，对于开发和运维人员只有当外部原因（例如磁盘损坏）造成配置文件损坏或者丢失时，这个命令是很有用的
• 例如：

sentinel remove <master name>

• 取消当前Sentinel节点对于指定<master name>主节点的监控
• 例如sentinel-1当前对mymaster-1进行了监控：

• 例如下面，sentinel-1节点取消对mymaster-1节点的监控，但是要注意这个命令仅仅对当前Sentinel节点有效

• 再执行info sentinel命令，发现sentinel-1已经失去对mymaster-1的监控：

sentinel monitor <master name> <ip> <port> <quorum>

• 这个命令和配置文件中的含义是完全一样的，只不过是通过命令的形式来完成Sentinel节点对主节点的监控
• 例如命令sentinel-1节点重新监控mymaster-1节点：

• 命令执行后，发现sentinel-1节点重新对mymaster-1节点进行监控：

sentinel set <master name>

• 动态修改Sentinel节点配置选项，这个命令已经在上面介绍了，这里就不赘述了

sentinel is-master-down-by-addr

• Sentinel节点之间用来交换对主节点是否下线的判断，根据参数的不同，还可以作为Sentinel领导者选举的通信方式
• 在后面“实现原理”一文中会详细介绍