Redis学习（四）—— Sentiel哨兵模式

最新推荐文章于 2024-05-01 20:33:39 发布

weixin_33681778

最新推荐文章于 2024-05-01 20:33:39 发布

阅读量169

点赞数

文章标签：数据库 python

原文链接：https://my.oschina.net/u/1175305/blog/1807659

版权

2019独角兽企业重金招聘Python工程师标准>>>

一、什么是哨兵模式

redis的哨兵模式为redis提供了高可用。哨兵模式是对主从复制的一个支持，在主从模式下，如果主服务器宕机了的时候，哨兵可以自动的将salve端提升为master。当master重新连接之后，master会以salve节点加入。

哨兵模式的功能：

监控--监控master和slave的运行状态
通知--当其中一个节点出现问题，可以自动的通知系统管理员
自动的故障转移--如果master运行出现问题，哨兵会自动开启故障转移进程，将一个slave提升为master，其他的salve节点会从新使用新的master
配置提供

二、如何配置哨兵模式

据说解压版会内置sentinel.conf配置文件，我是使用的ubuntu的apt-get命令安装的，没有看到该配置文件，所以我自己手动创建了sentinel.conf配置文件，由于哨兵要大于3个，所以建立三份配置文件。

#Sentinel节点的端口
port 26379  
dir /var/redis/data/
logfile "26379.log"

#当前Sentinel节点监控 127.0.0.1:6379 这个主节点
#2代表判断主节点失败至少需要2个Sentinel节点节点同意
#mymaster是主节点的别名
sentinel monitor mymaster 127.0.0.1 6379 2

#每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 30000

#当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1

#故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000

同理配置26380和26381端口配置文件。

启动上一章节的主从复制。

启动哨兵。

启动哨兵有两种方式

redis-sentinel /path/to/sentinel.conf

redis-server /path/to/sentinel.conf --sentinel

由于我的安装版的，也没找到redis-sentinel命令在哪里，所以我使用了第二种启动方式。

sudo redis-server /etc/redis/sentinel-26379.conf --sentinel

分别启动三个哨兵。

启动好了之后开启一个redis-cli连接哨兵

redis-cli -p 26379

执行命令查看master状态

127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "c323ef9f9036ad491885bbc22d45dd3085bc766b"
    9) "flags"
   10) "master"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "790"
   19) "last-ping-reply"
   20) "790"
   21) "down-after-milliseconds"
   22) "30000"
   23) "info-refresh"
   24) "8796"
   25) "role-reported"
   26) "master"
   27) "role-reported-time"
   28) "78979"
   29) "config-epoch"
   30) "0"
   31) "num-slaves"
   32) "1"
   33) "num-other-sentinels"
   34) "2"
   35) "quorum"
   36) "2"
   37) "failover-timeout"
   38) "180000"
   39) "parallel-syncs"
   40) "1"

看到master状态正常，下面我们模拟master挂掉的情况，新开一个redis-cli执行命令

redis-cli -p 6379 DEBUG sleep 60 #让master睡眠60秒

由于我们刚才配置的是超过30秒，哨兵会认为master宕机了，在30秒后我们重新查看master状态

127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6380"
    7) "runid"
    8) "bbad4ebb9f103cd252ef5611ca100b564fab8718"
    9) "flags"
   10) "master"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "634"
   19) "last-ping-reply"
   20) "634"
   21) "down-after-milliseconds"
   22) "30000"
   23) "info-refresh"
   24) "5287"
   25) "role-reported"
   26) "master"
   27) "role-reported-time"
   28) "136152"
   29) "config-epoch"
   30) "1"
   31) "num-slaves"
   32) "1"
   33) "num-other-sentinels"
   34) "2"
   35) "quorum"
   36) "2"
   37) "failover-timeout"
   38) "180000"
   39) "parallel-syncs"
   40) "1"

可以看到slave自动被提升为了master，在60秒后，原来的master重新上线，我们再查看salve的状态

127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "127.0.0.1:6379"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "c323ef9f9036ad491885bbc22d45dd3085bc766b"
    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) "193"
   19) "last-ping-reply"
   20) "193"
   21) "down-after-milliseconds"
   22) "30000"
   23) "info-refresh"
   24) "7841"
   25) "role-reported"
   26) "slave"
   27) "role-reported-time"
   28) "802263"
   29) "master-link-down-time"
   30) "0"
   31) "master-link-status"
   32) "ok"
   33) "master-host"
   34) "127.0.0.1"
   35) "master-port"
   36) "6380"
   37) "slave-priority"
   38) "100"
   39) "slave-repl-offset"
   40) "620621"

原来的6379master变成了salve节点。至此哨兵模式配置完成。

三、通过发布订阅监控节点运行的状态

在刚才的基础上，我们新开一个redis-cli窗口

127.0.0.1:26379> SUBSCRIBE +sdown
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "+sdown"
3) (integer) 1

订阅了+sdown这个频道

这时候我们再让6380进入sleep，观察频道接受的消息

127.0.0.1:26379> SUBSCRIBE +sdown
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "+sdown"
3) (integer) 1
1) "message"
2) "+sdown"
3) "master mymaster 127.0.0.1 6380"
1) "message"
2) "+sdown"
3) "slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379"

会自动的发布节点down掉的状态和salve提升为master的信息

查看master状态可以看到6379的确成为了master

127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "c323ef9f9036ad491885bbc22d45dd3085bc766b"
    9) "flags"
   10) "master"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "923"
   19) "last-ping-reply"
   20) "923"
   21) "down-after-milliseconds"
   22) "30000"
   23) "info-refresh"
   24) "9237"
   25) "role-reported"
   26) "master"
   27) "role-reported-time"
   28) "330385"
   29) "config-epoch"
   30) "2"
   31) "num-slaves"
   32) "1"
   33) "num-other-sentinels"
   34) "2"
   35) "quorum"
   36) "2"
   37) "failover-timeout"
   38) "180000"
   39) "parallel-syncs"
   40) "1"

四、哨兵的自动配置

当master宕机的时候，从slave中选择一个出来当做master，同时会通知其他的slave，从新的master来同步数据，下面来验证一下。

再开启一个redis-server 6381 作为一个新的slave，现在就变成了1个master2个slave。同样我们让master进行睡眠，这次选择了6381作为master

观察6380的输出

7713:S 06 May 09:28:29.928 * Connecting to MASTER 127.0.0.1:6381
7713:S 06 May 09:28:29.928 * MASTER <-> SLAVE sync started
7713:S 06 May 09:28:29.928 * Non blocking connect for SYNC fired the event.
7713:S 06 May 09:28:29.928 * Master replied to PING, replication can continue...
7713:S 06 May 09:28:29.928 * Trying a partial resynchronization (request 9083f950d1060650dc83a8f2d82c76fb9dba6755:963245).
7713:S 06 May 09:28:29.929 * Full resync from master: a72b065da9fcfd76111653bef3b2c7613044fe24:996050
7713:S 06 May 09:28:29.929 * Discarding previously cached master state.
7713:S 06 May 09:28:30.019 * MASTER <-> SLAVE sync: receiving 2636 bytes from master
7713:S 06 May 09:28:30.019 * MASTER <-> SLAVE sync: Flushing old data
7713:S 06 May 09:28:30.019 * MASTER <-> SLAVE sync: Loading DB in memory
7713:S 06 May 09:28:30.020 * MASTER <-> SLAVE sync: Finished with success

可以看到会自动的从6381同步数据。

转载于:https://my.oschina.net/u/1175305/blog/1807659