Redis Sentinel 哨兵模式

1

Redis Sentinel 哨兵模式

1.网络架构

网络结构如下,通过Sentinel监控Master和Slave服务器:

clipboard.png

2.配置启动

配置文件如下:

vi /etc/redis-sentinel.conf
port 26379     
dir "/tmp"
logfile "/var/log/redis/sentinel_20086.log"

# 进程守护
daemonize yes

# 格式:sentinel <option_name> <master_name> <option_value>
# 最后的一个2代表在sentinel集群中,多少个节点认为master死了,才能真正认为该master不可用
sentinel monitor T1 127.0.0.1 6379 2  

# sentinel会向master发送心跳确认存活
# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息
# 那么这个sentinel会主观地认为这个master已经不可用了
# (subjectively down, 也简称为SDOWN)。
# down-after-milliseconds 用来指定这个“一定时间范围”,单位是毫秒,默认30秒。
sentinel down-after-milliseconds T1 15000

# failover过期时间。
# 当failover开始后,在此时间内仍然没有触发任何failover操作,当前sentinel将会认为此次failoer失败。
# 默认180秒,即3分钟。
sentinel failover-timeout T1 120000

# 在发生failover时,这个选项指定了最多可以有多少个slave同时对新的master进行同步。
# 这个数字越小,完成failover所需的时间就越长;
# 这个数字越大,就意味着越多的slave因为replication而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。
sentinel parallel-syncs T1 1

# sentinel 连接密码验证
# sentinel auth-pass <master_name> xxxxx

# 发生切换之后执行的一个自定义脚本
# sentinel notification-script <master-name> <script-path>
# sentinel client-reconfig-script <master-name> <script-path>

Sentinel 也需要集群化,以确保:

  1. 某个/些 Sentinel节点挂了,仍然可以实现Redis主从切换;
  2. Redis客户端可以通过任意一个Sentinel读取/写入信息。

启动Sentinel:

redis-sentinel /path/to/sentinel.conf

启动后,通过Sentinel的自动识别,配置文件中会自动加上已识别的Redis集群节点和Sentinel集群节点。

3.实现流程

  1. Sentinel集群通过配置文件发现master,启动时会监控master;
  2. 向master发送info命令,获取其所有slave节点;
  3. Sentinel集群向Redis主从服务器发送hello信息(心跳),包括Sentinel本身的ip、端口、id等内容,以此来向其他Sentinel宣告自己的存在;
  4. Sentinel集群通过订阅接收其他Sentinel发送的hello信息,以此来发现监视同一个主服务器的其他Sentinel;集群之间会互相创建命令连接用于通信,因为已经有主从服务器作为发送和接收hello信息的中介,Sentinel之间不会创建订阅连接;
  5. Sentinel集群使用ping命令来检测实例的状态,如果在指定的时间内(down-after-milliseconds)没有回复或则返回错误的回复,那么该实例被判为下线;
  6. 当failover主备切换被触发后,并不会马上进行,还需要Sentinel中的大多数sentinel授权后才可以进行failover,即进行failover的Sentinel会去获得指定quorum个的Sentinel的授权,成功后进入ODOWN状态。如在5个Sentinel中配置了2个quorum,等到2个Sentinel认为master死了就执行failover。
  7. Sentinel向选为master的slave发送 SLAVEOF NO ONE 命令,选择slave的条件是Sentinel首先会根据slaves的优先级来进行排序,优先级越小排名越靠前。如果优先级相同,则查看复制的下标,哪个从master接收的复制数据多,哪个就靠前。如果优先级和下标都相同,就选择进程ID较小的。
  8. Sentinel被授权后,它将会获得宕掉的master的一份最新配置版本号(config-epoch),当failover执行结束以后,这个版本号将会被用于最新的配置,通过广播形式通知其它sentinel,其它的sentinel则更新对应master的配置。
注意:
因为redis采用的是异步复制,没有办法避免数据的丢失。
可以在redis.conf通过以下配置来使得数据不会丢失:
// master最少得有多少个健康的slave存活才能执行写命令 
min-slaves-to-write 1
// 延迟小于min-slaves-max-lag秒的slave才认为是健康的slave
min-slaves-max-lag 10
当所有Slave都不符合条件时,master将停止写入。

4.故障转移

发生故障转移时,需要进行领导者选举。

  • sentinel首先会根据slaves的优先级来进行排序,优先级越小排名越靠前;
  • 如果优先级相同,则查看复制的下标,哪个从master接收的复制数据多,哪个就靠前;
  • 如果优先级和下标都相同,就选择RunID较小的那个;

如果一个redis的slave优先级配置为0,那么它将永远不会被选为master。

故障转移过程

领导者Sentinel需要将一个salve提升为master,此slave必须为状态良好,不能处于SDOWN/ODOWN状态。

  1. “+failover-triggered”: Leader开始进行failover,此后紧跟着“+failover-state-wait-start”,wait数秒。
  2. “+failover-state-select-slave”: Leader开始查找合适的slave
  3. “+selected-slave”: 已经找到合适的slave
  4. “+failover-state-sen-slaveof-noone”: Leader向slave发送“slaveof no one”指令,此时slave已经完成角色转换,此slave即为master
  5. “+failover-state-wait-promotition”: 等待其他sentinel确认slave
  6. “+promoted-slave”:确认成功
  7. “+failover-state-reconf-slaves”: 开始对slaves进行reconfig操作
  8. “+slave-reconf-sent”:向指定的slave发送“slaveof”指令,告知此slave跟随新的master
  9. “+slave-reconf-inprog”: 此slave正在执行slaveof + SYNC过程,如过slave收到“+slave-reconf-sent”之后将会执行slaveof操作。
  10. “+slave-reconf-done”: 此slave同步完成,此后leader可以继续下一个slave的reconfig操作。循环 step 7
  11. “+failover-end”: 故障转移结束
  12. “+switch-master”:故障转移成功后,各个sentinel实例开始监控新的master。

5.增加和删除节点

Sentinel会通过PUB/SUB自动识别新增节点。

删除流程:

  1. 停止所要删除的sentinel
  2. 发送一个SENTINEL RESET 命令给所有其它的sentinel实例,如果你想要重置指定master上面的sentinel,只需要把号改为特定的名字,注意,需要一个接一个发,每次发送的间隔不低于30秒(down-after-milliseconds);
  3. 检查一下所有的sentinels是否都有一致的当前sentinel数;

参考资料:
https://www.cnblogs.com/zhouj...
http://www.cnblogs.com/zhouji...
https://segmentfault.com/u/be...


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

载入中...