Redis集群~windows下搭建Sentinel环境及它对主从模式的实际意义

Redis集群~windows下搭建Sentinel环境及它对主从模式的实际意义

关于redis-sentinel出现的原因

Redis集群的主从模式有个最大的弊端,就是当主master挂了之前,它的slave从服务器无法提升为主,而在redis-sentinel出现之后,有效的解决了这个问题,它相当于是一个投票者或者哨兵,它时刻监视着redis集群的各个服务器,当主master挂了之后,它将进行投票进行新master的选举,一般地,我们会建立多个redis-sentinel服务器,它们都会进行主master的选举工作,当多个redis-sentinal都选择同一个主之后,这个主才有效!

关于之前的主从模式

对于内部的主从模式(master-slaves)主要实现了数据的读写分离,可以有效的提升服务器的吞吐量,但对于高可用上,表现不佳,因为当主挂了之后,从slave无法成为主,或者没有这种机制,相关主从环境搭建请像我的这篇文章

Redis学习笔记~conf自主集群模式》

关于sentinel环境的搭建

1 下载redis3.2版

2 建立几个副本文件夹

3 对redis-window.conf的信息进行修改,主要有以下3点

sentinel monitor mymaster 127.0.0.1 6379 2 //当前的主master,2个sentinel选举成功后,才有效
sentinel down-after-milliseconds mymaster 60000 //判断主master挂机的时间(毫秒)
sentinel failover-timeout mymaster 180000 //失败的超时时间
sentinel parallel-syncs mymaster 1  //选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长

4 以sentinel模块支持redis-server

对于windows版本的redis,没有像linux环境里redis-sentinel进程,而可以使用redis-server来启动sentinal,我们只要添加这个参数即可,代码如下

5 查看redis-sentinel下的主从服务器

  • SENTINEL masters :列出所有被监视的主服务器,以及这些主服务器的当前状态。
  • SENTINEL slaves :列出给定主服务器的所有从服务器,以及这些从服务器的当前状态。
  • SENTINEL get-master-addr-by-name : 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作, 或者针对这个主服务器的故障转移操作已经完成, 那么这个命令返回新的主服务器的 IP 地址和端口号。
  • SENTINEL reset : 重置所有名字和给定模式 pattern 相匹配的主服务器。
  • SENTINEL failover : 当主服务器失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移 (不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置,其他 Sentinel 会根据这个配置进行相应的更新)。

连接指定的redis-sentinel服务器

显示当前的主master服务器

Redis-sentinel的实际意义

对于我们使用方来说,有了redis-sentinel就等于有了当前的redis-master,即我们的数据就知道向哪台服务器写入了(其它slave都是从master同步的数据),这对于使用客户端的开发人员来说,直接链接redis-sentinel的返回值即可,当然前提是你不要求横向扩展,不要求分片存储,当然,这对一个大型数据存储来说,是可笑的,我们当然需要扩展,对大数据当然要进行自动分片,所有我们需要为redis-sentinal再加一层统一的代理服务器,如Twemproxy,有了TW代理,我们在连接redis时,直接连接TW的地址即可,这会自动分片,并且自动向redis-sentinel并连接真实的redis-master服务器!

对于我们的Sentinel来说,我们只能对它进行一些简单的操作,如订阅服务,同时,它为我们开放了很多事件,供我们在外面调用

Sentinel模式下的几个事件

  • +reset-master :主服务器已被重置。
  • +slave :一个新的从服务器已经被 Sentinel 识别并关联。
  • +failover-state-reconf-slaves :故障转移状态切换到了 reconf-slaves 状态。
  • +failover-detected :另一个 Sentinel 开始了一次故障转移操作,或者一个从服务器转换成了主服务器。
  • +slave-reconf-sent :领头(leader)的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令,为实例设置新的主服务器。
  • +slave-reconf-inprog :实例正在将自己设置为指定主服务器的从服务器,但相应的同步过程仍未完成。
  • +slave-reconf-done :从服务器已经成功完成对新主服务器的同步。
  • -dup-sentinel :对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候,就会出现这种情况。
  • +sentinel :一个监视给定主服务器的新 Sentinel 已经被识别并添加。
  • +sdown :给定的实例现在处于主观下线状态。
  • -sdown :给定的实例已经不再处于主观下线状态。
  • +odown :给定的实例现在处于客观下线状态。
  • -odown :给定的实例已经不再处于客观下线状态。
  • +new-epoch :当前的纪元(epoch)已经被更新。
  • +try-failover :一个新的故障迁移操作正在执行中,等待被大多数 Sentinel 选中(waiting to be elected by the majority)。
  • +elected-leader :赢得指定纪元的选举,可以进行故障迁移操作了。
  • +failover-state-select-slave :故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
  • no-good-slave :Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级,又或者直接放弃执行故障转移操作。
  • selected-slave :Sentinel 顺利找到适合进行升级的从服务器。
  • failover-state-send-slaveof-noone :Sentinel 正在将指定的从服务器升级为主服务器,等待升级功能完成。
  • failover-end-for-timeout :故障转移因为超时而中止,不过最终所有从服务器都会开始复制新的主服务器(slaves will eventually be configured to replicate with the new master anyway)。
  • failover-end :故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
  • +switch-master :配置变更,主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
  • +tilt :进入 tilt 模式。
  • -tilt :退出 tilt 模式。
阅读更多
个人分类: redis-sentinel
上一篇Redis集群redis主从自动切换Sentinel(哨兵模式)
下一篇Redis 哨兵模式实现主从故障互切换
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭