Redis: Sentinel 2

2015-03-23  本文已影响763人  谁又失忆

当前最新的稳定版叫做Sentinel 2，即“哨兵二代目”，必须使用Redis 2.8。2.6版本中的为Sentinel 1（哨兵一代目），有很多bug，已经被废弃。

功能

Redis Sentinel提供一下功能：

启动

启动哨兵服务器有一下两条命令：
redis-sentinel /path/to/sentinel.conf或redis-server /path/to/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
  1. The time needed to re-start a failover after a previous failover was already tried against the same master by a given Sentinel, is two times the failover timeout.
  2. The time needed for a slave replicating to a wrong master according to a Sentinel current configuration, to be forced to replicate with the right master, is exactly the failover timeout (counting since the moment a Sentinel detected the misconfiguration).
  3. The time needed to cancel a failover that is already in progress but did not produced any configuration change (SLAVEOF NO ONE yet not acknowledged by the promoted slave).
  4. The maximum time a failover in progress waits for all the slaves to be reconfigured as slaves of the new master. However even after this time the slaves will be reconfigured by the Sentinels anyway, but not with the exact parallel-syncs progression as specified.

Quorum

quorum字面翻译是“法定人数”，不是很喜欢，这里就还是用e文。执行故障转移需要一下几个步骤：

  1. master的状态为ODOWN
  2. 一个哨兵获取到授权执行故障转移操作
    quorum代表的数量主要体现在第1个步骤中，当有``个哨兵判断master为SDOWN时，master就被判断为ODOWN状态。如图：
`ODOWN`判断

假设上图中sentinel_1打算执行故障转移操作，就必须获取所有sentinel的授权，在判断master_1为ODOWN时，sentinel_1和sentinel_2的结论是一致的，所以只需向余下的哨兵们获取授权即可，即sentinel_3

当一个哨兵对给定master执行故障转移操作时，其他哨兵并没有放弃对该master执行故障转移的权利（好爱抢功劳），它们只是暂时放弃，当时间超过配置的failover-timeout时，其他哨兵们就会尝试对给定的master进行故障转移操作，直至成功。

哨兵们的配置

在哨兵们和master们正常运行的时候，每个哨兵都维护着相同的配置，各个节点会相互交换自己的配置版本号，一旦运行中有较新的版本出现，就会使用使用新的配置代替老的配置。在故障转移的过程，一旦一个哨兵获取到执行故障转移的授权，会立马生成新的版本号，一旦故障转移成功，会通过master们和slaver们发布新的配置文件，其他哨兵就会不得不使用最新的配置文件。正如上面说的，如果超过failover-timeout还没有成功的话，又有一个哨兵会去执行故障转移操作，会生成与前者不同的配置版本（功劳不能被抢嘛）。

配置传播

执行故障转移的过程中，对将要上任的slaver送slaver of no one（备胎转正），其他slaver发送slaver of（新爸爸），只要执行哨兵收到了ACK，就算这个过程还在进行，故障转移也算做成功，该哨兵会发布新的配置。
哨兵们传播配置文件主要依赖redis的消息订阅功能，官方叫gossip，就是八卦了，哨兵们都是老死不想往来的，都是通过“小道消息”获取彼此间的信息，从上文看，还特别爱赶潮流。哨兵会和所有的master（正宫）和slaver（备胎）宣布自己的配置版本信息（好像自己有一手资料似得），同时也会打听其他哨兵手上的情报，以防自己落伍了。

配置通过__sentinel__:hello通道广播

配置传播

八卦知天下

哨兵最开始不知道其他哨兵的存在，在他去嫖master的时候，顺便在master那里安插一个盯梢的，负责打听各路消息，保证自己掌握一手资料，和其他哨兵的情报。同时哨兵又爱吹牛，稍微一点新变化就爱吹嘘，所以情报也被其他哨兵打听走。master作为店里的头牌，加上日理万机的本事，所以生意基本上它一个人做，除非客人一定要找实习生（slaver）。傲娇的master通常会和哨兵们讲起自己的身价，比如有多人觊觎自己的位置.etc。作为嫖客的哨兵，一旦知道master服务不行了，就会发起选秀，就会去找替补slaver，当然哨兵们都是争相做主办方的，这样第一个睡嘛~嫖客无情～

哨兵每隔2秒发布它的个人信息，包括ip，port，runid
哨兵通过__sentinel__:hello获取到其他哨兵的情报，将它们加入到自己的盯梢薄里
哨兵发布的消息包含所有的master配置信息，一旦哨兵发现自己的情报落后与其他哨兵，就马上会更新到最新情报
当哨兵发现其他哨兵的存在，回去查找自己的情报薄，看看这个哨兵有没有存在

情报保存

哨兵视情报为生命，所以不管甚么时候，一旦获取到新的情报，就立马刻在自家的碑文上（写到硬盘），做传世之用。

备胎转正的条件

master的候选者参照几下几点：

  1. 和master失去链接的时间
  2. 级别
  3. 从master学习到的功力（原文：replication offset processed）
  4. Run ID

如果和master失恋的时间超过: (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state,则无法当选为候选人.
新master的考察项：
1. 优先级越高越优先（redis.conf中的slave-priority数值越小，不能小于0，等于0，则宣布一辈子做备胎）
2. 相同优先级就考察从master学到的本事，越多越好
3. 当优先级相同，本事一样，那就看名字了，哨兵认为Run Id越小越好

指令

哨兵的通信协议和的redis-server实例相同，可以通过redis-cli -h -p来访问，支持一下命令：

运行时的配置指令

哨兵的添加与删除

依赖八卦体系，添加哨兵很简单，只要监控master就可以被大家发现。删除哨兵则需要一下步骤：

  1. 杀死该哨兵进程
  2. 发送SENTINEL RESET *给其他哨兵
  3. 检查所有哨兵，发送指令SENTINEL master给所有哨兵来查看活跃的哨兵数量

参考文献

  1. 官方文档
上一篇 下一篇

猜你喜欢

热点阅读