Redis-Sentinel

Redis的高可用方案的实现：主从切换以及虚拟IP或客户端

从Redis 2.8开始加入对Sentinel机制从而实现了服务器端的主从切换，但目前尚未发现实现虚拟IP或客户端切换方案

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案

当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，

而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

功能：

  • 监控redis是否按照预期良好地运行;
  • 如果发现某个redis节点运行出现状况，能够通知另外一个进程;
  • 能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址

只使用单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群

好处：

  • 解决单点问题；
  • 有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息

Sentinel当前最新的稳定版本称为Sentinel 2。随着redis2.8的安装包一起发行。安装完Redis2.8后，可以在redis2.8/src/里面找到Redis-sentinel的启动程序

运行sentinel有两种方式

redis-sentinel /path/to/sentinel.conf
#或者
redis-server /path/to/sentinel.conf --sentinel

　注意：

　　　　必须指定一个sentinel的配置文件sentinel.conf，如果不指定，将无法启动sentinel。sentinel默认监听26379端口，所以运行前必须确定该端口没有被别的进程占用　

 配置

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5
注：
  • sentinel monitor mymaster 127.0.0.1 6379 2

　　sentinel监控的master的名字叫做mymaster,地址为127.0.0.1:6379，行尾最后的一个2代表当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了

  • down-after-milliseconds

　　用来指定这个“一定时间范围”的，单位是毫秒。

　　sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

  • parallel-syncs

　　在发生failover主备切换时，指定最多可以有多少个slave同时对新的master进行同步

　　数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态

Sentinel的仲裁

　　当failover主备切换真正被触发后，failover并不会马上进行，还需要sentinel中的大多数sentinel授权后才可以进行failover。　

网络隔离时的一致性

　　redis sentinel集群的配置的一致性模型为最终一致性，集群中每个sentinel最终都会采用最高版本的配置

　　redis采用的是异步复制，在某些场景下，没有办法避免数据的丢失。可以通过以下配置来配置，使得数据不会丢失

min-slaves-to-write 1 当一个redis是master时，如果它不能向min-slaves-to-write的数量的slave写数据，将会拒绝接受客户端的写请求
min-slaves-max-lag 10 不在min-slaves-max-lag时间内向master发送同步数据的请求了

Sentinel状态持久化

　　snetinel的状态会被持久化地写入sentinel的配置文件中。每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳

无failover时的配置纠正

　　即使当前没有failover正在进行，sentinel依然会使用当前配置去设置监控的master
　　如果slaves连接了一个错误的master，将会被改正连接到正确的master

Slave选举与优先级

选举出一个合适的slave来做为新的master评估slave的：

  • 与master断开连接的次数
  • Slave的优先级
  • 数据复制的下标(用来评估slave当前拥有多少master的数据)
  • 进程ID(选择进程ID较小在前)

注：
　　如果一个redis的slave优先级配置为0，虽然会从master那复制数据，但它将永远不会被选为master。

Sentinel和Redis身份验证

当一个master配置为需要密码才能连接时，客户端和slave在连接时都需要提供密码。master通过requirepass设置自身的密码，不提供密码无法连接到这个master。slave通过masterauth来设置访问master时的密码。

当使用了sentinel时，由于一个master可能会变成一个slave，一个slave也可能会变成master，所以需要同时设置上述两个配置项

Sentinel API

Sentinel默认运行在26379端口上

  • 直接使用客户端向它发消息
  • 使用发布/订阅模式来订阅sentinel事件
PING sentinel回复PONG.
SENTINEL masters 显示被监控的所有master以及它们的状态.
SENTINEL master <master name> 显示指定master的信息和状态；
SENTINEL slaves <master name> 显示指定master的所有slave以及它们的状态；
SENTINEL get-master-addr-by-name <master name> 返回指定master的ip和端口，如果正在进行failover或者failover已经完成，将会显示被提升为master的slave的ip和端口。
SENTINEL reset <pattern> 重置名字匹配该正则表达式的所有的master的状态信息，清楚其之前的状态信息，以及slaves信息。
SENTINEL failover <master name> 强制sentinel执行failover，并且不需要得到其他sentinel的同意。但是failover后会将最新的配置发送给其他sentinel　

增加Sentinel

　　有sentinel自动发现机制

　　监控到某个Master上，然后新添加的sentinel就能获得其他sentinel的信息以及master所有的slaves

删除Sentinel

sentinel永远不会删除一个已经存在过的sentinel

  1. 停止所要删除的sentinel

  2. 发送一个SENTINEL RESET * 命令给所有其它的sentinel实例，如果你想要重置指定master上面的sentinel，只需要把*号改为特定的名字，注意，需要一个接一个发，每次发送的间隔不低于30秒。

  3. 检查一下所有的sentinels是否都有一致的当前sentinel数。使用SENTINEL MASTER mastername 来查询。

删除旧master或者不可达slave

　　sentinel永远会记录好一个Master的slaves，即使slave已经与组织失联好久了。这样sentinel集群必须有能力把一个恢复可用的slave进行重新配置。

　　failover后，失效的master将会被标记为新master的一个slave，当它变得可用时，就会从新master上复制数据。

　　如果你想要永久地删除掉一个slave(有可能它曾经是个master)，只需要发送一个SENTINEL RESET master命令给所有的sentinels，将会更新列表里能够正确地复制master数据的slave。

发布/订阅

　　客户端可以向一个sentinel发送订阅某个频道的事件的命令，当有特定的事件发生时，sentinel会通知所有订阅的客户端。

　　注意：客户端只能订阅，不能发布。

TILT 模式

redis sentinel非常依赖系统时间，如它会使用系统时间来判断一个PING回复用了多久的时间。

如果系统时间被修改了，或者是系统十分繁忙，或者是进程堵塞了，sentinel可能会出现运行不正常的情况

当系统的稳定性下降时，TILT模式是sentinel可以进入的一种的保护模式。当进入TILT模式时，sentinel会继续监控工作，但是它不会有任何其他动作，它也不会去回应is-master-down-by-addr这样的命令了，因为它在TILT模式下，检测失效节点的能力已经变得让人不可信任了。
如果系统恢复正常，持续30秒钟，sentinel就会退出TITL模式。

 

sentinel是今天看文章看到的，于是顺便查了下资料，先记录下，还有待研究

 

posted @ 2017-01-05 11:18  慕尘  阅读(669)  评论(0)  编辑  收藏  举报