Redis 高可用部署

发布时间:2020-06-27 15:13:30 作者:Flywithmeto
来源:网络 阅读:9664

Redis 高可用原理:

Redis使用sentinel机制来实现高可用,sentinel是另外一个集群,主要是用来监控所有的Redis服务器,所有redis主节点和redis从节点,监控方式使用的是ping指令,sentinel每隔1秒向master发送【ping】,如果在一段时间内没有收到【pong】或者收到无效回复,则认为master下线。
sentinel对下线有两种定义:
a.主观下线(sdown):sentinel实例本身对服务实例的判断
b.客观下线(odown):多个sentinel实例对同一个服务SDOWN的状态做出协商后的判断,只有master才可能在odown状态 。

简单的说,一个sentinel单独做出的判断只能是sdown,是没有任何官方效力的,只有多个sentinel大家商量好,得到一致,才能将某个master状态从sdown置为odown,只有确定master的状态转换为odown状态后,才能做后续failover的操作。
sentinel能够实现监控整个主从复制架构,你只要告诉sentinel谁是主服务器就行了,它会从主服务器上,也就是向主服务发送info指令,了解这个主下面有哪些从服务器,如果发现主服务器离线了,它会自动从这个主服务器下面的某个从服务器中选举一个当新的主节点,那么此前从节点连的主节点是原来的老主,原来的主节点不在了怎么办,sentinel告诉客户端新的主是谁 ,向客户端发送slaveof指定让从节点重新选择主节点。
如果sentinel连不主节点或者sentinel本身故障了怎么办,所以sentinel需要做一个集群。由集群中的每个节点来共同判断redis节点是否down了。
Sentinel作用是管理多个redis服务实现HA
监控: Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
通知:当被监控的某个Redis服务器出现问题时, Sentinel可以通过API向管理员或者其他应用程序发送通知。
自动故障转移:当一个主服务器不能正常工作时, Sentinel会开始一次自动故障迁移操作,它会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器。
使用的是流言协议,投票协议。

sentinel的启动

启动方式有两种:

#通过redis-server 的sentinel参数启动:
    redis-servier /etc/sentinel.conf  --sentinel
#通过redis-sentinel命令启动:
    redis-sentinel /etc/sentinel.conf 

Sentinel依赖于配置文件,它必须用配置文件不停保存自已的状态信息。

启动一个sentinel有以下几个步骤:

  1. 服务器自身初始化 。
    运行 redis-server 中专用于sentinel功能的代码
  2. 初始化sentinel状态,根据给定的配置文件,初始化监控的master服务器列表
  3. 创建连向master的连接。

sentinel专用配置文件解析

 #sentinel.conf为其专用配置文件,主要设置如下参数:
#默认Port
   port 26379 
#指定要监控的master,mymaster是定义的master名字,quorum为法定票数2,此处指的是sentinel的数,只有指定的sentinel同意时才认为sentinel做的决策是有效的,一般大于sentinel数量的半数。可以有多个master,一组sentinel集群可以监控N个主从复制架构 
   sentinel monitor mymaster 127.0.0.1 6379 2   
#指定要连接的redis master密码 
   sentinel auth-pass mymaster redis  
#至少多长时间 连不上才认为主的离线了。单位为ms,   即连接超时时长
   sentinel down-after-milliseconds mymaster 30000 
# 刚刚设定为新主时,允许同时有多少个从向主发起同步请求。 
   sentinel parallel-syncs 1 
#当master故障时,把新的从提升为master,多长时间提不上就认为故障转移失败。 
   sentinel failover-timeout mymaster 180000 #故障转移的超时时长              

sentinel专用命令:

sentinel masters  #获取所有监控的master
sentinel slaves <master name>  #列出该master的所有从节点 
sentinel  get-master-addr-by-name <master name>#根据master名字来获取地址 
sentinel  reset    #重置所有,从头再来 
sentinel failover <mater name>  #手动故障转移,并指明向哪组master发起手动 

Redis高可用配置示例

Redis版本:3.2.2
一主两从:
主:10.3.1.15 6379
从:10.3.1.15 6378
从:10.3.1.15 6376
一个Sentinel:10.3.1.17

#启动sentinel 
./bin/redis-sentinel /data/service/redis/sentinel.conf  
18844:X 23 Mar 18:34:58.053 * Increased maximum number of open files to 10032 (it was originally set to 1024). 
...
...
18844:X 23 Mar 18:34:58.054 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 

18844:X 23 Mar 18:34:58.056 # Sentinel ID is 524c94beed78f379e4a0b3b641992449b0cdcf7f 

18844:X 23 Mar 18:34:58.056 # +monitor master mymaster 10.3.1.15 6379 quorum 2 

18844:X 23 Mar 18:34:58.057 * +slave slave 10.3.1.15:6378 10.3.1.15 6378 @ mymaster 10.3.1.15 6379 

18844:X 23 Mar 18:34:58.059 * +slave slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 
#启动完成,从控制台上面可以看到sentinel已经找到master和slave。
#获取sentinel 所监控的redis master服务器信息 
10.3.1.17:26379> sentinel masters 
1)  1) "name" 
     2) "mymaster" 
     3) "ip" 
     4) "10.3.1.15" 
     5) "port" 
     6) "6379" 
     7) "runid" 
     8) "3520e56cadc7a3cd591da0094199d46a83771318" 
     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) "697" 
   19) "last-ping-reply" 
   20) "697" 
   21) "down-after-milliseconds" 
   22) "30000" 
62360:X 24 Mar 13:05:53.197 # +sdown master mymaster 10.3.1.15 6379  #主观认为master已失效 

62360:X 24 Mar 13:05:53.197 # +odown master mymaster 10.3.1.15 6379 #quorum 1/1  #客观认为master已失效 

62360:X 24 Mar 13:06:07.965 # +new-epoch 13  #准备进master新一纪元,第13次选举。 

62360:X 24 Mar 13:06:07.965 # +try-failover master mymaster 10.3.1.15 6379  #尝试转移master 

62360:X 24 Mar 13:06:07.967 # +vote-for-leader 9cf767f451de09136054ccc6afc6dcc5f939b5a0 13  #投票选举leader 

62360:X 24 Mar 13:06:07.967 # +elected-leader master mymaster 10.3.1.15 6379  #之前被选举出来的 master 

62360:X 24 Mar 13:06:07.967 # +failover-state-select-slave master mymaster 10.3.1.15 6379 #Leader开始select合适的master 

62360:X 24 Mar 13:06:08.034 # +selected-slave slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 #已找到了合适的从10.3.1.15:6376为主 

62360:X 24 Mar 13:06:08.034 * +failover-state-send-slaveof-noone slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 #Leader 向 slave 发送“slaveof no one”指令,此时 slave 已经完成角色转换,此 slave 即为 master 

62360:X 24 Mar 13:06:08.093 * +failover-state-wait-promotion slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 #等待其他 sentinel 确认 slave 

62360:X 24 Mar 13:06:09.116 # +promoted-slave slave 10.3.1.15:6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 #确认成功 

62360:X 24 Mar 13:06:09.116 # +failover-state-reconf-slaves master mymaster 10.3.1.15 6379 #开始对slaves进行reconfig 操作 

62360:X 24 Mar 13:06:09.176 * +slave-reconf-sent slave 10.3.1.15:6378 10.3.1.15 6378 @ mymaster 10.3.1.15 6379 #向指定的slave 发送“slaveof”指令,告知此 slave 跟随新的 master 

62360:X 24 Mar 13:06:10.132 * +slave-reconf-inprog slave 10.3.1.15:6378 10.3.1.15 6378 @ mymaster 10.3.1.15 6379 开始对slaves进行reconfig 操作 

然后进入sentinel中查看新的master:

10.3.1.17:26379> sentinel masters 
 #可以看到master已经发生了改变
1)  1) "name" 
     2) "mymaster" 
     3) "ip"  
     4) "10.3.1.15"   
     5) "port" 
     6) "6376" 
     7) "runid"  

回到某个slave节点查看:

10.3.1.15:6378> config get slaveof 
1) "slaveof" 
2) "10.3.1.15 6376" 
10.3.1.15:6378>  

现在把原来的master 6379启动起来,再看下它是主还是从:

10.3.1.15:6379> config get slaveof 
1) "slaveof" 
2) "10.3.1.15 6376" 
#原来的master,此时已是从节点了

现在进入新选举出来的master查看:

10.3.1.15:6376> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.3.1.15,port=6379,state=online,offset=707098,lag=1
slave1:ip=10.3.1.15,port=6379,state=online,offset=707013,lag=1
master_repl_offset:707098
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:707097
10.3.1.15:6376> 

以上就是Redis sentinel就是高可用功能,应用程序应该向sentinel发请求,去寻求新Master的地址,这时要用redis专用程序,根据sentinel反馈来联络新服务器。

推荐阅读:
  1. Azure Redis 系列之 Azure Redis部署
  2. CacheEasy-Redis私有云平台

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

redis 高可用

上一篇:DBCS和UCS编码相关

下一篇:勒索病毒、敲诈者病毒、wallet比特币病毒加密数据后的应急处理

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》