目录
Redis的集群方案大致有三种:
1)redis cluster集群方案;
2)master/slave主从方案;
3)哨兵模式来进行主从替换以及故障恢复。
Sentinel哨兵模式介绍
哨兵模式基于主从复制模式,只是引入了哨兵来监控与自动处理故障。主从切换技术的方法是:当服务器宕机后,需要手动一台从机切换为主机,这需要人工干预,不仅费时费力而且还会造成一段时间内服务不可用。为了解决主从复制的缺点,就有了哨兵机制, 其结构如下:
Sentinel状态持久化
snetinel的状态会被持久化地写入sentinel的配置文件中。每次当收到一个新的配置时,或者新创建一个配置时,配置会被持久化到硬盘中,并带上配置的版本戳。这意味着,可以安全的停止和重启sentinel进程。
Sentinel作用
- Master状态检测
- 如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave。
- Master-Slave切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换。
Sentinel工作方式(每个Sentinel实例都执行的定时任务)
- 每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个PING命令。
- 如果一个实例(instance)距离最后一次有效回复PING命令的时间超过 own-after-milliseconds 选项所指定的值,则这个实例会被Sentinel标记为主观下线。
- 如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
- 当有足够数量的Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态,则Master会被标记为客观下线。
- 在一般情况下,每个Sentinel 会以每10秒一次的频率向它已知的所有Master,Slave发送 INFO 命令。
- 当Master被Sentinel标记为客观下线时,Sentinel 向下线的 Master 的所有Slave发送 INFO命令的频率会从10秒一次改为每秒一次。
- 若没有足够数量的Sentinel同意Master已经下线,Master的客观下线状态就会被移除。 若 Master重新向Sentinel 的PING命令返回有效回复,Master的主观下线状态就会被移\
三个定时监控任务
任务1:
每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图,
哨兵配置时只要配置对主节点的监控即可(sentinel monitor mymaster 127.0.0.1,26380,2),
通过向主节点发送info,即可获取从节点信息,
并当有新的从节点加入时可以马上感知到;
任务2:
每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息,
同时每个哨兵节点也会订阅该频道,来了解其它哨兵节点的信息及对主节点的判断,
其实就是通过消息publish和subscribe来完成的;
任务3:
每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测,
这个也是哨兵用来判断节点是否正常的重要依据;
Sentinel搭建过程
**我已经提前搭建好 Redis 主从复制,具体过程可以参考 **这篇博客
所有主机创建sentinel目录
mkdir -p /data/redis/26380 -p
所有主机创建sentinel配置文件
mkdir -p /data/redis/26380 -p
cat>/data/redis/26380/sentinel.conf<<eof
port 26380
dir "/data/redis/26380"
logfile /data/redis/26380/sentinel.log
protected-mode no
daemonize yes
sentinel monitor redis-master 10.0.0.31 6379 2
sentinel down-after-milliseconds redis-master 5000
sentinel auth-pass redis-master 123
eof
配置文件参数说明如下:
sentinel monitor redis-master 10.0.0.31 16370 2
指定 Redis 集群的初始主节点,并命名为 "redis-master"。注意,参数 "2" 表示 Sentinel 需要最少的投票数。这个设置在多 Sentinel 场景下非常有用。由于本案例使用了 3 个 Sentinel,因此设置为 2。在生产环境中,建议配置多 Sentinel 模式,最少设置为 3 个(建议设置为奇数) Sentinel 物理节点。设置为 2 表示当 3 个 Sentinel 中至少有 2 个节点认为主库宕机时,才会真正判定主库宕机。
sentinel down-after-milliseconds redis-master 5000
监控 Sentinel 集群时,如果超过 5000 毫秒(即 5 秒)仍然没有响应,则 Sentinel 会判定主库宕机。
sentinel auth-pass redis-master 123
由于 Sentinel 需要访问 Redis 集群,因此需要设置访问整个集群的密码。这里指定的密码为 "123",这意味着所有节点都使用相同的密码。
启动sentinel
redis-sentinel /data/redis/26380/sentinel.conf
netstat -lntup|grep 263
tail -f /data/redis/26380/sentinel.log
模拟主库宕机
[服务未授权][root@redis1 ~]# redis-cli -a 123 -p 6379 shutdown
[服务未授权][root@redis1 ~]# redis-cli -a 123 -p 6379 info replication
Could not connect to Redis at 127.0.0.1:6379: Connection refused
**此时我们观察Sentinel日志, 发现Sentinel 在检测到主节点故障后,执行了主从切换(failover)操作,将新的主节点切换为 10.0.0.32,并更新了从节点信息。 **
我们查看一下32节点的主从信息,可以发现节点变成master,并且只有一个从节点
现在我们恢复宕机的主库
[服务未授权][root@redis1 ~]# systemctl start redis
[服务未授权][root@redis1 ~]# netstat -lntup | grep 6379
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 9262/redis-server 1
tcp 0 0 10.0.0.31:6379 0.0.0.0:* LISTEN 9262/redis-server 1
再次观察Sentinel日志
日志中的 +sdown
和 -sdown
表示 Sentinel 对从节点状态的检测结果:
+sdown
表示 Sentinel 检测到从节点处于下线状态(subjectively down,主观下线)。-sdown
表示 Sentinel 检测到从节点恢复正常(从主观下线状态中恢复)。
查看主库主从信息
修复之后,之前宕机的主库会自动加入集群并成为slaves节点
[服务未授权][root@redis2 ~]# redis-cli -a 123 info replication
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# Replication
role:master
connected_slaves:2
slave0:ip=10.0.0.33,port=6379,state=online,offset=114633,lag=0
slave1:ip=10.0.0.31,port=6379,state=online,offset=114633,lag=0
master_failover_state:no-failover
master_replid:c584802c8c7397d0ce211128e18aa1d42365b8ed
master_replid2:34fbfdbde59d06ddfdda87a00f855e1d10cf5e19
master_repl_offset:114633
second_repl_offset:20373
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:114633
Sentinel常用命令
PING
用"PING"指令监测Redis或者sentinel实例是否正常工作,如果返回"PONG"说明是可以正常相应的!
[服务未授权][root@redis1 ~]# redis-cli -a 123 -p 26380 -h 10.0.0.32
10.0.0.32:26380>
10.0.0.32:26380> PING
PONG
10.0.0.32:26380>
SENTINEL master
列出所有被监视的主服务器,以及这些主服务器的当前状态;
[服务未授权][root@redis1 ~]# redis-cli -a 123 -p 26380 -h 10.0.0.32
10.0.0.32:26380> sentinel masters
1) 1) "name"
2) "redis-master"
3) "ip"
4) "10.0.0.32"
5) "port"
6) "6379"
7) "runid"
8) "9dc87ecfd058660282060d8365d409afc2c8b810"
9) "flags"
......
SENTINEL slaves
列出给定主服务器的所有从服务器,以及这些从服务器的当前状态;
10.0.0.32:26380> sentinel slaves redis-master
1) 1) "name"
2) "10.0.0.31:6379"
3) "ip"
4) "10.0.0.31"
5) "port"
6) "6379"
7) "runid"
8) "b528cf77ce0e02630563ef039b5f3e5130cc156f"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "457"
19) "last-ping-reply"
20) "457"
21) "down-after-milliseconds"
22) "5000"
23) "info-refresh"
24) "6464"
25) "role-reported"
.....
SENTINEL get-master-addr-by-name
返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作, 或者针对这个主服务器的故障转移操作已经完成, 那么这个命令返回新的主服务器的 IP 地址和端口号;
10.0.0.32:26380> SENTINEL get-master-addr-by-name redis-master
1) "10.0.0.32"
2) "6379"
10.0.0.32:26380>
SENTINEL reset
SENTINEL reset
命令用于重置 Sentinel 对主服务器的监控状态,具体操作如下:
- 清除主服务器的状态:删除 Sentinel 对指定模式匹配的主服务器的所有监控和状态信息。
- 取消故障转移:中止任何正在进行中的故障转移操作(如果有的话)。
- 移除从服务器:移除所有与主服务器关联的从服务器。
- 移除 Sentinel:将与主服务器相关联的 Sentinel 实例的信息也会被删除。
SENTINEL failover
当主服务器失效时,使用"SENTINEL failover
10.0.0.32:26380> SENTINEL get-master-addr-by-name redis-master
1) "10.0.0.32"
2) "6379"
10.0.0.32:26380> SENTINEL failover redis-master
OK
10.0.0.32:26380> SENTINEL get-master-addr-by-name redis-master
1) "10.0.0.31"
2) "6379"
10.0.0.32:26380>
标签:10.0,部署,Redis,redis,sentinel,master,Sentinel,节点
From: https://www.cnblogs.com/Unstoppable9527/p/18349032