频道栏目
首页 > 网络 > 云计算 > 正文

Redis哨兵模式及配置详解

2017-12-19 10:46:18         来源:刘大磊的博客  
收藏   我要投稿

前言

在上一篇redis的主从复制中已经实现了redis的主从架构,但是如果redis的主从架构中出现宕机怎么办?如果从redis宕机相对简单一些,那么如果住redis的宕机就会比较麻烦,需要我们手动进行处理,这样很可能会造成数据的丢失,这时候我们就需要用到Redis提供的哨兵(sentinel)功能,哨兵会在master发送故障的时候,能自动将slave切换成master,下面就对哨兵做一个介绍。

Sentinel(哨兵)

介绍

Redis SentinelSentinel(哨兵)是用于监控redis集群中Master状态的工具,其已经被集成在redis2.4+的版本中

作用

1):Master状态检测

2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave

3):Master-Slave切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换

哨兵模式的原理

Redis提供了sentinel(哨兵)机制,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决

每个sentinel会向其它sentinal、master、slave定时发送消息,以确认对方是否“活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的“主观认为宕机” Subjective Down,简称SDOWN)。

若”哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master”彻底死亡”(即:客观上的真正down机,Objective Down,简称ODOWN),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。

这里写图片描述

哨兵模式的配置

在redis的主从配置中,我们已经设置好了6380作为master6381,6382作为salve,现在我们在redis-jiqun目录下建一个sentinel.conf,或者我们从redis的解压目录将sentinel.conf文件复制到redis-jiqun目录中:

sentinel.conf的内容如下

port 26379  
dir /tmp  
sentinel monitor mymaster 192.168.251.129 6380 1  
sentinel down-after-milliseconds mymaster 30000  
sentinel parallel-syncs mymaster 1  
sentinel failover-timeout mymaster 180000  
logfile "/var/log/sentinel_log.log"  
注释:
1. port :当前Sentinel服务运行的端口
2. dir : Sentinel服务运行时使用的临时文件夹
3 sentinel monitor mymaster 192.168.251.129 6380 1:Sentinel去监视一个名为master的主redis实例,这个主实例的IP地址为本机地址192.168.1.103,端口号为6379,而将这个主实例判断为失效至少需要1个 Sentinel进程的同意,只要同意Sentinel的数量不达标,自动failover就不会执行
4. sentinel down-after-milliseconds mymaster 300000:指定了Sentinel认为Redis实例已经失效所需的毫秒数。当实例超过该时间没有返回PING,或者直接返回错误,那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移:只有在足够数量的Sentinel都将一个实例标记为主观下线之后,实例才会被标记为客观下线,这时自动故障迁移才会执行
5. sentinel parallel-syncs mymaster 1:指定了在执行故障转移时,最多可以有多少个从Redis实例在同步新的主实例,在从Redis实例较多的情况下这个数字越小,同步的时间越长,完成故障转移所需的时间就越长
6. sentinel failover-timeout mymaster 180000:如果在该时间(ms)内未能完成failover操作,则认为该failover失败

启动哨兵

方式一:redis-sentinel /path/to/sentinel.conf & (推荐,这种方式启动和redis实例没有任何关系,后面加&可以在后台启动,关闭ssh窗口依然会在后台执行)

在redis01的bin目录下执行:

./redis-sentinel /usr/local/redis-jiqun/sentinel.conf &

方式二:redis-server /path/to/sentinel.conf –sentinel,前台启动,ctril+c进行关闭

./redis-sentinel /usr/local/redis-jiqun/sentinel.conf --sentinel

测试哨兵

我们后台启动哨兵以后,可以在/var/log/sentinel_log.log中查看日志

这里写图片描述

现在我们停止6380master节点

#现在我们停止6380master节点
ps –ef |grep redis
kill -9 端口号
#查看log日志
cat /var/log/sentinel_log.log

这里写图片描述

下面就是模拟主节点宕机,哨兵进行工作的整个过程。

3349:X 07 Dec 13:52:17.982 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
3349:X 07 Dec 13:52:17.996 # Sentinel ID is 23e1e3e4fc3f181d30475fac45f3d10a481017f3
3349:X 07 Dec 13:52:17.996 # +monitor master mymaster 192.168.251.129 6380 quorum 1
3349:X 07 Dec 13:52:17.997 * +slave slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 13:52:18.009 * +slave slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 14:02:45.191 # +sdown master mymaster 192.168.251.129 6380   #说明master服务已经宕机
3349:X 07 Dec 14:02:45.191 # +odown master mymaster 192.168.251.129 6380 #quorum 1/1
3349:X 07 Dec 14:02:45.191 # +new-epoch 1
3349:X 07 Dec 14:02:45.192 # +try-failover master mymaster 192.168.251.129 6380  #开始恢复
3349:X 07 Dec 14:02:45.240 # +vote-for-leader 23e1e3e4fc3f181d30475fac45f3d10a481017f3 1  #投票选举哨兵leader,现在就一个哨兵所以leader就自己
3349:X 07 Dec 14:02:45.240 # +elected-leader master mymaster 192.168.251.129 6380  #选中leader
3349:X 07 Dec 14:02:45.241 # +failover-state-select-slave master mymaster 192.168.251.129 6380   #选中其中的一个slave当做master
3349:X 07 Dec 14:02:45.341 # +selected-slave slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380  #这里选中的是6382slave
3349:X 07 Dec 14:02:45.342 * +failover-state-send-slaveof-noone slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380  #发送slaveof no one命令
3349:X 07 Dec 14:02:45.419 * +failover-state-wait-promotion slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380   #等待升级master
3349:X 07 Dec 14:02:45.500 # +promoted-slave slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380  #升级6382为master
3349:X 07 Dec 14:02:45.500 # +failover-state-reconf-slaves master mymaster 192.168.251.129 6380 
3349:X 07 Dec 14:02:45.596 * +slave-reconf-sent slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 14:02:46.244 * +slave-reconf-inprog slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 14:02:46.244 * +slave-reconf-done slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 14:02:46.334 # +failover-end master mymaster 192.168.251.129 6380 #故障恢复完成
3349:X 07 Dec 14:02:46.334 # +switch-master mymaster 192.168.251.129 6380 192.168.251.129 6382   #主数据库从6380转变为6382
3349:X 07 Dec 14:02:46.334 * +slave slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6382  #添加6381为6382的从库
3349:X 07 Dec 14:02:46.334 * +slave slave 192.168.251.129:6380 192.168.251.129 6380 @ mymaster 192.168.251.129 6382  #添加6380为6382的从库
3349:X 07 Dec 14:03:16.374 # +sdown slave 192.168.251.129:6380 192.168.251.129 6380 @ mymaster 192.168.251.129 6382  #这里检测6379还是宕机状态
3349:X 07 Dec 14:14:23.989 # -sdown slave 192.168.251.129:6380 192.168.251.129 6380 @ mymaster 192.168.251.129 6382  #一直在检测6380的状态
3349:X 07 Dec 14:14:33.895 * +convert-to-slave slave 192.168.251.129:6380 192.168.251.129 6380 @ mymaster 192.168.251.129 6382  #我们启动6380,他变成了6380的slave
上一篇:机器学习实战——AdaBoost
下一篇:rundeck调度工具部署安装教程
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站