设为首页 收藏本站
查看: 1348|回复: 0

[经验分享] redis的哨兵(sentinel)配置和python程序应用示例

[复制链接]

尚未签到

发表于 2018-11-3 10:50:57 | 显示全部楼层 |阅读模式
  一、Sentinel概述:
  当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。Sentinel是Redis的高可用性(HA)解决方案,由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进行下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求。Redis提供的sentinel(哨兵)机制,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决
  l 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  l 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  l 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
  l 配置信息:哨兵提供了认证和服务发现,客户端连接到哨兵去获取当前redis 主服务器地址,如果发生故障转移,哨兵将会汇报新的服务器地址。每次进行主从切换时,sentinel配置文件自动更新
  二、Sentinel支持集群
  很显然,只使用单个sentinel进程来监控redis集群是不可靠的,当sentinel进程宕掉后(sentinel本身也有单点问题,single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群,这样有几个好处:
  1. 即使有一些sentinel进程宕掉了,依然可以进行redis集群的主备切换;
  2. 如果只有一个sentinel进程,如果这个进程运行出错,或者是网络堵塞,那么将无法实现redis集群的主备切换(单点问题);
  3. 如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。
  三、Sentinel版本选择
  Sentinel当前最新的稳定版本称为Sentinel 2(与之前的Sentinel 1区分开来)。随着redis2.8的安装包一起发行。安装完Redis2.8后,可以在redis2.8/src/里面找到Redis-sentinel的启动程序。如果你使用的是redis2.6(sentinel版本为sentinel 1),你最好应该使用redis2.8版本的sentinel 2,因为sentinel 1有很多的Bug,已经被官方弃用,所以强烈建议使用redis2.8以及sentinel 2。
  四、Redis Sentinel的配置
  redis主ip:192.168.221.160
  redis从ip:192.168.221.161
  Sentinel在redis主从的基础上继续配置,主从配置的方式这里不再赘述。详情请参考楼主另一篇文章:redis安装及主从配置
  我这里配置了两个哨兵,分别部署在两台机器上,采用了典型的配置项,配置文件如下:
[root@DB ~]# grep -Ev '^#|^$' /etc/sentinel_26379.conf  
port 26379
  
daemonize yes #程序后台执行
  
logfile "/var/log/sentinel.log"
  
dir "/tmp"
  
sentinel monitor mymaster 192.168.221.160 6379 2 #第一次设置哨兵时此ip一定要设置为redis集群中的主ip
  
sentinel down-after-milliseconds mymaster 5000
  
sentinel failover-timeout mymaster 6000
  
sentinel config-epoch mymaster 7
  
sentinel parallel-syncs mymaster 1
  下面简单解释下这些配置项:
  sentinel monitor mymaster 192.168.221.160 6379 2 表示sentinel监控的master名字是mymaster,地址为192.168.221.160:6379。行尾最后的一个2代表什么意思呢?我们知道,网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,当sentinel集群式,解决这个问题的方法就变得很简单,只需要多个sentinel互相沟通来确认某个master是否真的死了,这个2代表,当集群中有2个sentinel认为master死了时,才能真正认为该master已经不可用了。(sentinel集群中各个sentinel也有互相通信,通过gossip协议)
  sentinel down-after-milliseconds mymaster 5000  Sentinel会向master发送心跳PING来确认master是否存活,如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息,那么这个sentinel会主观地(单方面地)认为这个master已经不可用了(subjectively down, 也简称为SDOWN)。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的,单位是毫秒
  sentinel parallel-syncs mymaster 1 在执行故障转移时,最多可以有多少个从服务器同时从新的主服务器进行同步,数字越小,完成故障转移需要的时间越长
  五、运行Sentinel,状态检查
  先启动redis主从程序,在启动sentinel:
redis-server /etc/sentinel_26379.conf --sentinel  Master机器查看进程:
root      84286  57342  0 Oct18 pts/2    00:00:00 redis-cli -h 192.168.221.160 -p 26379  
root      84302      1  0 Oct18 ?        00:03:41 redis-server *:26379
  
redis     84328      1  0 Oct18 ?        00:03:01 /usr/sbin/redis-server 192.168.221.160:6379
  
root      84391  83553  0 Oct18 pts/3    00:00:00 redis-cli -h 192.168.221.160
  
root      86746  86651  0 09:35 pts/6    00:00:00 grep redis
  Slave机器查看进程:
redis     53505      1  0 Oct18 ?        00:02:17 /usr/sbin/redis-server 192.168.221.161:6379  
root      53510  52922  0 Oct18 pts/0    00:00:00 redis-cli -h 192.168.221.161
  
root      53542      1  0 Oct18 ?        00:02:53 redis-server *:26379
  
root      54767  54723  0 09:34 pts/1    00:00:00 grep redis
  查看master状态:
[root@MidApp ~]# redis-cli -h 192.168.221.160  
192.168.221.160:6379> info replication
  
# Replication
  
role:master
  
connected_slaves:1
  
slave0:ip=192.168.221.161,port=6379,state=online,offset=9243499,lag=0
  
master_repl_offset:9243644
  
repl_backlog_active:1
  
repl_backlog_size:1048576
  
repl_backlog_first_byte_offset:8195069
  
repl_backlog_histlen:1048576
  查看slave状态:
[root@DB ~]# redis-cli -h 192.168.221.161 -p 6379  
192.168.221.161:6379> info replication
  
# Replication
  
role:slave
  
master_host:192.168.221.160
  
master_port:6379
  
master_link_status:up
  
master_last_io_seconds_ago:0
  
master_sync_in_progress:0
  
slave_repl_offset:9200304
  
slave_priority:100
  
slave_read_only:1
  
connected_slaves:0
  
master_repl_offset:0
  
repl_backlog_active:0
  
repl_backlog_size:1048576
  
repl_backlog_first_byte_offset:0
  
repl_backlog_histlen:0
  查看sentinel状态:
[root@DB ~]# redis-cli -h 192.168.221.160 -p 26379  
192.168.221.160:26379> info sentinel
  
# Sentinel
  
sentinel_masters:1
  
sentinel_tilt:0
  
sentinel_running_scripts:0
  
sentinel_scripts_queue_length:0
  
master0:name=mymaster,status=ok,address=192.168.221.160:6379,slaves=1,sentinels=2
  六、Redis-Sentinel主从切换测试
  首先手动关闭主redis(192.168.221.160),查看sentinel日志,可以看到192.168.221.161已经变成了主redis,自动完成了切换:
[84302] 18 Oct 15:22:31.539 * +failover-state-wait-promotion slave 192.168.221.161:6379 192.168.221.161 6379 @ mymaster 192.168.221.160 6379  
[84302] 18 Oct 15:22:32.434 # +promoted-slave slave 192.168.221.161:6379 192.168.221.161 6379 @ mymaster 192.168.221.160 6379
  
[84302] 18 Oct 15:22:32.434 # +failover-state-reconf-slaves master mymaster 192.168.221.160 6379
  
[84302] 18 Oct 15:22:32.498 # +failover-end master mymaster 192.168.221.160 6379
  
[84302] 18 Oct 15:22:32.499 # +switch-master mymaster 192.168.221.160 6379 192.168.221.161 6379
  
[84302] 18 Oct 15:22:32.500 * +slave slave 192.168.221.160:6379 192.168.221.160 6379 @ mymaster 192.168.221.161 6379
  
[84302] 18 Oct 15:22:37.552 # +sdown slave 192.168.221.160:6379 192.168.221.160 6379 @ mymaster 192.168.221.161 6379
  把刚才关闭的redis再次启动之后检查redis主从状态:
[root@DB ~]# redis-cli -h 192.168.221.160 -p 6379  
192.168.221.160:6379> info replication
  
# Replication
  
role:slave
  
master_host:192.168.221.161
  
master_port:6379
  
master_link_status:up
  
master_last_io_seconds_ago:0
  
master_sync_in_progress:0
  
slave_repl_offset:9200304
  
slave_priority:100
  
slave_read_only:1
  
connected_slaves:0
  
master_repl_offset:0
  
repl_backlog_active:0
  
repl_backlog_size:1048576
  
repl_backlog_first_byte_offset:0
  
repl_backlog_histlen:0
[root@MidApp ~]# redis-cli -h 192.168.221.161  
192.168.221.161:6379> info replication
  
# Replication
  
role:master
  
connected_slaves:1
  
slave0:ip=192.168.221.160,port=6379,state=online,offset=9243499,lag=0
  
master_repl_offset:9243644
  
repl_backlog_active:1
  
repl_backlog_size:1048576
  
repl_backlog_first_byte_offset:8195069
  
repl_backlog_histlen:1048576
  检查sentinel配置文件:
[root@DB ~]# grep -Ev '^#|^$' /etc/sentinel_26379.conf  
port 26379
  
daemonize yes
  
logfile "/var/log/sentinel.log"
  
dir "/tmp"
  
sentinel monitor mymaster 192.168.221.161 6379 1
  
sentinel down-after-milliseconds mymaster 5000
  
sentinel failover-timeout mymaster 6000
  
sentinel config-epoch mymaster 7
  
sentinel known-slave mymaster 192.168.221.160 6379
  
sentinel known-sentinel mymaster 192.168.221.161 26379 74f54a23bf06b57ce1618ee48f42a09a11522bb9
  可以看到配置文件监控的master机器也变成了192.168.221.161:6379。
  七、python程序访问sentinel集群
  由于很好奇连入的程序是如何访问sentinel集群的,自己用python验证了一下。
  Python下需要安装redis相关的lib库,我这里使用的是redis-2.10.5版本
[root@DB ~]# python  
Python 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
  
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
  
Type "help", "copyright", "credits" or "license" for more information.
  
>>> from redis.sentinel import Sentinel #加载redis模块
  
>>> sentinel = Sentinel([('192.168.221.160', 26379),
  
...                      ('192.168.221.161', 26379)],
  
...                     socket_timeout=0.1) #连接哨兵服务器
  
>>> sentinel.discover_master('mymaster') #获取主redis服务器地址
  
('192.168.221.161', 6379)
  
>>> sentinel.discover_slaves('mymaster')#获取从redis服务区地址
  
[('192.168.221.160', 6379)]
  
>>> master = sentinel.master_for('mymaster', socket_timeout=0.1)
  
>>> master.set('foo','bar') #获取主redis服务器并进行写入
  
True
  
>>> slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
  
>>> slave.get('foo')#获取从redis服务器进行获取
  
'bar'
  
>>>
  初步认为程序通过sentinel提供的端口进行访问,获取主redis进行写入操作,读的话如果不指定方式会采取轮询的方式进行读操作
参考文档:
Redis Sentinel机制与用法(一)



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-630163-1-1.html 上篇帖子: Corvus,Redis-porxy安装部署指南 下篇帖子: redis的 rdb 和 aof 持久化的区别
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表