目录
sentinel down-after-milliseconds
sentinel client-reconfig-script
一 简介
Redis Sentinel是一个分布式架构, 其中包含若干个Sentinel节点和Redis数据节点, 每个Sentinel节点会对数据节点和其余Sentinel节点进行监控, 当它发现节点不可达时, 会对节点做下线标识。 如果被标识的是主节点, 它还会和其他Sentinel节点进行“协商”, 当大多数Sentinel节点都认为主节点不可达时, 它们会选举出一个Sentinel节点来完成自动故障转移的工作, 同时会将这个变化实时通知给Redis应用方。 整个过程完全是自动的, 不需要人工来介入, 这套方案很有效地解决了Redis的高可用问题。
Redis Sentinel与Redis主从复制模式只是多了若干Sentinel节点, 所以Redis Sentinel并没有针对Redis节点做了特殊处理。
二 部署
假设已经搭建了如图所示的主从结构:
搭建过程可以参考:https://blog.csdn.net/qq_16399991/article/details/99881319;
1. 配置Sentinel节点
#redis-sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
dir /usr/local/redis/redis_sentinel_26379/data
#sentinel-1节点需要监控127.0.0.1: 6379这个主节点;
#2代表判断主节点失败至少需要2个Sentinel节点同意;
#mymaster是主节点的别名
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
2 启动Sentinel节点
Sentinel节点的启动方法有两种:
- 使用redis-sentinel命令
redis-sentinel redis-sentinel-26379.conf
- 使用redis-server命令加--sentinel参数
redis-server redis-sentinel-26379.conf --sentinel
用相同方式分别启动26480、26481端口的sentinel
redis-sentinel redis-sentinel-26480.conf
redis-sentinel redis-sentinel-26481.conf
3确认是否启动成功
Sentinel节点本质上是一个特殊的Redis节点, 所以也可以通过info命令来查询它的相关信息, 从下面info的Sentinel片段来看, Sentinel节点找到了主节点127.0.0.1: 6379, 发现了它的两个从节点, 同时发现Redis Sentinel一共有3个Sentinel节点。 这里只需要了解Sentinel节点能够彼此感知到对方, 同时能够感知到Redis数据节点就可以了:
至此Redis Sentinel已经搭建完成;
有2点需要强调一下:
- 生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。
- Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任何区别, 只不过是添加了一些Sentinel节点对它们进行监控。
三 配置项说明
-
sentinel monitor
sentinel monitor <master-name> <ip> <port> <quorum>
Sentinel节点要监控的是一个名字叫做<master-name>, ip地址和端口为<ip><port>的主节点。 <quorum>代表要判定主节点最终不可达所需要的票数。
配置中没有看到有关从节点和其余Sentinel节点的配置, 那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息。
同时<quorum>还与Sentinel节点的领导者选举有关, 至少要有max( quorum, num( sentinels) /2+1) 个Sentinel节点参与选举, 才能选出领导者Sentinel, 从而完成故障转移。 例如有5个Sentinel节点, quorum=4, 那么至少要有max( quorum, num( sentinels) /2+1) =4个在线Sentinel节点才可以进行领导者选举。
-
sentinel down-after-milliseconds
sentinel down-after-milliseconds <master-name> <times>
Sentinel节点通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达, 如果超过了down-after-milliseconds配置的时间且没有有效的回复, 则判定节点不可达, <times>( 单位为毫秒) 就是超时时间。 这个配置是对节点失败判定的重要依据。
-
sentinel parallel-syncs
sentinel parallel-syncs <master-name> <nums>
当Sentinel节点集合对主节点故障判定达成一致时, Sentinel领导者节点会做故障转移操作, 选出新的主节点, 原来的从节点会向新的主节点发起复制操作, parallel-syncs就是用来限制在一次故障转移之后, 每次向新的主节点发起复制操作的从节点个数。 如果这个参数配置的比较大, 那么多个从节点会向新的主节点同时发起复制操作, 尽管复制操作通常不会阻塞主节点,但是同时向主节点发起复制, 必然会对主节点所在的机器造成一定的网络和磁盘IO开销。
-
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监控的主节点配置了密码, sentinel auth-pass配置通过添加主节点的密码, 防止Sentinel节点对主节点无法监控。sentinel auth-pass <master-name> <password>
-
sentinel notification-script
sentinel notification-script的作用是在故障转移期间, 当一些警告级别的Sentinel事件发生( 指重要事件, 例如-sdown: 客观下线、 -odown: 主观下线) 时, 会触发对应路径的脚本, 并向脚本发送相应的事件参数。sentinel notification-script <master-name> <script-path>
该脚本会接收每个Sentinel节点传过来的事件参数, 可以利用这些参数作为邮件或者短信报警依据;P
-
sentinel client-reconfig-script
entinel client-reconfig-script的作用是在故障转移结束后, 会触发对应路径的脚本, 并向脚本发送故障转移结果的相关参数。sentinel client-reconfig-script <master-name> <script-path>