Redis学习(四)—— Sentiel哨兵模式

1、什么是哨兵模式redis

redis的哨兵模式为redis提供了高可用。哨兵模式是对主从复制的一个支持,在主从模式下,若是主服务器宕机了的时候,哨兵能够自动的将salve端提高为master。当master从新链接以后,master会以salve节点加入。ubuntu

    哨兵模式的功能:bash

  • 监控--监控master和slave的运行状态
  • 通知--当其中一个节点出现问题,能够自动的通知系统管理员
  • 自动的故障转移--若是master运行出现问题,哨兵会自动开启故障转移进程,将一个slave提高为master,其余的salve节点会重新使用新的master
  • 配置提供

2、如何配置哨兵模式服务器

听说解压版会内置sentinel.conf配置文件,我是使用的ubuntu的apt-get命令安装的,没有看到该配置文件,因此我本身手动建立了sentinel.conf配置文件,因为哨兵要大于3个,因此创建三份配置文件。ui

#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端口配置文件。code

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

启动哨兵。进程

启动哨兵有两种方式ip

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

因为个人安装版的,也没找到redis-sentinel命令在哪里,因此我使用了第二种启动方式。get

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节点。至此哨兵模式配置完成。

3、经过发布订阅监控节点运行的状态

在刚才的基础上,咱们新开一个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"

4、哨兵的自动配置

当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同步数据。

相关文章
相关标签/搜索