Redis的集群(故障转移)

Redis集群自身实现了高可用,当集群内少量节点出现故障时通过自动故障转移保证集群可以正常对外提供服务。

故障发现

1. 主观下线

当cluster-node-timeout时间内某节点无法与另一个节点顺利完成ping消息通信时,则将该节点标记为主观下线状态。

2. 客观下线

当某个节点判断另一个节点主观下线后,该节点的下线报告会通过Gossip消息传播。当接收节点发现消息体中含有主观下线的节点,其会尝试对该节点进行客观下线,依据下线报告是否在有效期内(如果在cluster-node-timeout*2时间内无法收集到一半以上槽节点的下线报告,那么之前的下线报告会过期),且数量大于槽节点总数的一半。若是,则将该节点更新为客观下线,并向集群广播下线节点的fail消息。

故障恢复

故障节点变为客观下线后,如果下线节点是持有槽的主节点,则需要在它的从节点中选出一个替换它,从而保证集群的高可用,过程如下:

1. 资格检查

每个从节点都要检查最后与主节点断线时间,判断是否有资格替换故障的主节点。如果从节点与主节点断线时间超过cluster-node-timeout*cluster-slave-validity-factor,则当前从节点不具备故障转移资格。

2. 准备选举时间

从节点符合故障转移资格后,更新触发故障选举时间,只有到达该时间才能执行后续流程。采用延迟触发机制,主要是对多个从节点使用不同的延迟选举时间来支持优先级。复制偏移量越大说明从节点延迟越低,那么它应该具有更高的优先级。

3. 发起选举

当从节点到达故障选举时间后,会触发选举流程:

(1) 更新配置纪元

配置纪元是一个只增不减的整数,每个主节点自身维护一个配置纪元,标示当前主节点的版本,所有主节点的配置纪元都不相等,从节点会复制主节点的配置纪元。整个集群又维护一个全局的配置纪元,用于记录集群内所有主节点配置纪元的最大版本。每次集群发生重大事件,如新加入主节点或由从节点转换而来,从节点竞争选举,都会递增集群全局配置纪元并赋值给相关主节点,用于记录这一关键事件。

(2) 广播选举消息

在集群内广播选举消息,并记录已发送过消息的状态,保证该从节点在一个配置纪元内只能发起一次选举。

4. 选举投票

只有持有槽的主节点才会处理故障选举消息,每个持有槽的节点在一个配置纪元内都有唯一的一张选票,当接到第一个请求投票的从节点消息,回复消息作为投票,之后相同配置纪元内其它从节点的选举消息将忽略。投票过程其实是一个领导者选举的过程。

每个配置纪元代表了一次选举周期,如果在开始投票后的cluster-node-timeout*2时间内从节点没有获取足够数量的投票,则本次选举作废。从节点对配置纪元自增并发起下一轮投票,直到选举成功为止。

5. 替换主节点

当前从节点取消复制变为主节点,撤销故障主节点负责的槽,把这些槽委派给自己,并向集群广播告知所有节点当前从节点变为主节点。

故障转移时间

1. 主观下线识别时间=cluster-node-timeout。

2. 主观下线状态消息传播时间<=cluster-node-timeout/2(消息通信机制会优先选取下线状态节点通信)。

3. 从节点转移时间<=1000毫秒(偏移量最大的从节点最多延迟1秒发起选举,通常一次就会成功)。

所以,failover-time(毫秒) <= cluster-node-timeout + cluster-node-timeout/2 + 1000

故障转移过程

Redis的集群(伸缩)搭建好的集群模拟主节点故障场景。

集群状态信息

127.0.0.1:6879> cluster nodes

99ea0df1d9683affb1271a5092fc8b15b378adba 127.0.0.1:6885 master - 0 1533780841246 12 connected 0-1364 4096 5461-6826 10923-12287 15018-16383

558b0fb8d44933e694b46c15d05e595ce5ae4fab 127.0.0.1:6886 slave 99ea0df1d9683affb1271a5092fc8b15b378adba 0 1533780844286 12 connected

...

强制关闭6885端口对应的redis进程

$ ps -ef | grep 6885

redis 96825  1  0 Aug04 ?    00:05:03 redis-server 0.0.0.0:6885 [cluster]

$ kill -9 96825

日志分析如下:

. 从节点6886与主节点6885复制中断。

96829:S 08 Aug 19:15:45.870 # Connection with master lost.

96829:S 08 Aug 19:15:45.870 * Caching the disconnected master state.

96829:S 08 Aug 19:15:46.804 * Connecting to MASTER 127.0.0.1:6885

96829:S 08 Aug 19:15:46.805 * MASTER <-> SLAVE sync started

96829:S 08 Aug 19:15:46.805 # Error condition on socket for SYNC: Connection refused

. 6879和6880两个主节点都标记6885为主观下线,超过半数因此标记为客观下线状态。

6879端口日志

22574:M 08 Aug 19:16:02.677 * Marking node 99ea0df1d9683affb1271a5092fc8b15b378adba as failing (quorum reached).

6880端口日志

22578:M 08 Aug 19:16:02.680 * Marking node 99ea0df1d9683affb1271a5092fc8b15b378adba as failing (quorum reached).

. 从节点识别正在复制的主节点进入客观下线后准备选举时间。

6886端口日志

96829:S 08 Aug 19:16:02.682 * FAIL message received from 90cb860b7f4ff516304c577bc1e514dc95ecd09b about 99ea0df1d9683affb1271a5092fc8b15b378adba

96829:S 08 Aug 19:16:02.761 # Start of election delayed for 855 milliseconds (rank #0, offset 1654026).

. 延迟选举时间到达后,从节点更新配置纪元并发起故障选举。

6886端口日志

96829:S 08 Aug 19:16:03.677 # Starting a failover election for epoch 13.

. 6879和6880主节点为从节点6886投票。

6879端口日志

22574:M 08 Aug 19:16:03.679 # Failover auth granted to 558b0fb8d44933e694b46c15d05e595ce5ae4fab for epoch 13

6880端口日志

22578:M 08 Aug 19:16:03.680 # Failover auth granted to 558b0fb8d44933e694b46c15d05e595ce5ae4fab for epoch 13

. 从节点获取2个主节点投票后,超过半数,执行替换主节点操作从而完成故障转移。

6886端口日志

96829:S 08 Aug 19:16:03.688 # Failover election won: I'm the new master.

96829:S 08 Aug 19:16:03.688 # configEpoch set to 13 after successful failover

故障转移后,集群状态信息

127.0.0.1:6879> cluster nodes

99ea0df1d9683affb1271a5092fc8b15b378adba 127.0.0.1:6885 master,fail - 1533780945879 1533780943442 12 disconnected

558b0fb8d44933e694b46c15d05e595ce5ae4fab 127.0.0.1:6886 master - 0 1533803267149 13 connected 0-1364 4096 5461-6826 10923-12287 15018-16383

...

重启6885端口,其会以现有集群配置为准,变为新主节点6886的从节点。

6885端口日志

47931:M 09 Aug 01:35:34.512 # Configuration change detected. Reconfiguring myself as a replica of 558b0fb8d44933e694b46c15d05e595ce5ae4fab

集群内其它节点接收到6885发来的ping消息,清空客观下线状态。

22574:M 09 Aug 01:35:34.520 * Clear FAIL state for node 99ea0df1d9683affb1271a5092fc8b15b378adba: master without slots is reachable again.

此时集群状态信息

127.0.0.1:6879> cluster nodes

99ea0df1d9683affb1271a5092fc8b15b378adba 127.0.0.1:6885 slave 558b0fb8d44933e694b46c15d05e595ce5ae4fab 0 1533804408406 13 connected

558b0fb8d44933e694b46c15d05e595ce5ae4fab 127.0.0.1:6886 master - 0 1533804407394 13 connected 0-1364 4096 5461-6826 10923-12287 15018-16383

...

手动故障转移

Redis集群提供了手动故障转移功能,指定从节点发起转移,主从节点角色进行互换,过程如下:

1. 从节点通知主节点停止处理所有客户端请求。

2. 主节点发送对应从节点延迟复制的数据。

3. 从节点接收复制延迟的数据,直到主从复制偏移量一致。

4. 从节点立刻发起投票选举,选举成功后断开复制变为新的主节点,之后向集群广播。

5. 原主节点接收消息后更新自身配置变为从节点,解除所有客户端请求阻塞,重定向到新的主节点。

6. 原主节点变为从节点后,向新的主节点发起全量复制请求(Redis4.0版本这一过程会有改善)。

6885端口上发起手动转移

127.0.0.1:6885> cluster failover

OK

日志分析如下:

6885端口日志

47931:S 09 Aug 02:11:19.943 # Manual failover user request accepted.

47931:S 09 Aug 02:11:20.010 # Received replication offset for paused master manual failover: 2969

47931:S 09 Aug 02:11:20.011 # All master replication stream processed, manual failover can start.

47931:S 09 Aug 02:11:20.011 # Start of election delayed for 0 milliseconds (rank #0, offset 2969).

47931:S 09 Aug 02:11:20.111 # Starting a failover election for epoch 14.

47931:S 09 Aug 02:11:20.115 # Failover election won: I'm the new master.

47931:S 09 Aug 02:11:20.115 # configEpoch set to 14 after successful failover

47931:M 09 Aug 02:11:20.115 # Connection with master lost.

6886端口日志

96829:M 09 Aug 02:11:19.943 # Manual failover requested by slave 99ea0df1d9683affb1271a5092fc8b15b378adba.

96829:M 09 Aug 02:11:20.113 # Failover auth granted to 99ea0df1d9683affb1271a5092fc8b15b378adba for epoch 14

96829:M 09 Aug 02:11:20.116 # Connection with slave 127.0.0.1:6885 lost.

96829:M 09 Aug 02:11:20.318 # Configuration change detected. Reconfiguring myself as a replica of 99ea0df1d9683affb1271a5092fc8b15b378adba

96829:S 09 Aug 02:11:20.521 * Connecting to MASTER 127.0.0.1:6885

Redis集群还提供了强制故障转移的方法:

1. cluster failover force - 用于主节点宕机且无法自动完成故障转移的情况。

2. cluster failover takeover - 用于集群内一半以上主节点故障的场景,从节点无法收到半数以上主节点投票,无法完成选举过程(慎用)。

若感兴趣可关注订阅号”数据库最佳实践”(DBBestPractice).

原文地址:http://blog.51cto.com/coveringindex/2156902

时间: 2024-10-08 03:18:11

Redis的集群(故障转移)的相关文章

mongodb集群故障转移实践

简介 NOSQL有这些优势: 大数据量,可以通过廉价服务器存储大量的数据,轻松摆脱传统mysql单表存储量级限制. 高扩展性,Nosql去掉了关系数据库的关系型特性,很容易横向扩展,摆脱了以往老是纵向扩展的诟病. 高性能,Nosql通过简单的key-value方式获取数据,非常快速.还有NoSQL的Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多. 灵活的数据模型,NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式.而在关系数据库里

Redis Cluster集群总结性梳理

前面已经介绍了Redis Cluster集群及其部署过程,下面再补充下有关Redis Cluster应用原理部分内容,以便更加深刻透彻地理解Redis Cluster. 一.Redis Cluster集群最核心的三个目标 性能:这是Redis赖以生存的看家本领,增加集群功能后当然不能对性能产生太大影响,所以Redis采取了P2P而非Proxy方式.异步复制.客户端重定向等设计,而牺牲了部分的一致性.使用性. 水平扩展:集群的最重要能力当然是扩展,文档中称可以线性扩展到1000结点. 可用性:在C

170103、Redis官方集群方案 Redis Cluster

前面我们谈了Redis Sharding多服务器集群技术,Redis Sharding是客户端Sharding技术,对于服务端来说,各个Redis服务器彼此是相互独立的,这对于服务端根据需要灵活部署Redis非常轻便,Redis Sharding具有很好的灵活性.可伸缩性,是一种轻量级集群技术. 本篇,介绍另外一种多Redis服务器集群技术,即Redis Cluster.Redis Cluster是一种服务器Sharding技术,3.0版本开始正式提供. Redis Cluster中,Shard

Redis 学习(三)redis服务器集群、客户端分片

下面是来自知乎大神的一段说明,个人觉得非常清晰,就收藏了. 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,scale up不是一个好办法,我们需要scale out横向可伸缩扩展,这需要由多台主机协同提供服务,即分布式多个Re

02.Redis主从集群的Sentinel配置

阅读目录 开始 1.集群环境 2.配置并启动Redis主从集群 3.配置sentinel集群并启动 4.测试sentinel集群 回到顶部 1.集群环境 1.Linux服务器列表 使用4台CentOS Linux服务器搭建环境,其IP地址如下: 192.168.110.100192.168.110.101192.168.110.102192.168.110.103 2.Redis服务部署环境 192.168.110.100    启动多个Redis sentinel服务,构成Redis sent

centos6下redis cluster集群部署过程

一般来说,redis主从和mysql主从目的差不多,但redis主从配置很简单,主要在从节点配置文件指定主节点ip和端口,比如:slaveof 192.168.10.10 6379,然后启动主从,主从就搭建好了.redis主从中如果主节点发生故障,不会自动切换,需要借助redis的Sentinel(哨兵模式)或者keepalive来实现主的故障转移. 今天介绍下redis cluster集群模式:redis集群是一个无中心的分布式redis存储架构,可以在多个节点之间进行数据共享,解决了redi

Redis的集群(伸缩)

Redis集群提供了节点的扩容和收缩方案,在不影响集群对外服务的情况下,可以为集群添加节点进行扩容,也可以下线节点进行缩容.其中的原理可理解为槽和对应的数据在不同节点间移动. 扩容集群 在Redis的集群(搭建)中搭建了6个节点,其中3个主节点分别维护自己负责的槽和数据,为了后续测试,填充若干测试数据. $ for i in $(seq 1 70000); do redis-cli -p 6879 -c set key:migrate:test:${i} ${i}; done $ redis-t

Redis Cluster 集群使用(3)

简介 Redis3.0版本之前,可以通过Redis Sentinel(哨兵)来实现高可用(HA),从3.0版本之后,官方推出了Redis Cluster,它的主要用途是实现数据分片(Data Sharding),不过同样可以实现HA,是官方当前推荐的方案.在Redis Sentinel模式中,每个节点需要保存全量数据,冗余比较多,而在Redis Cluster模式中,每个分片只需要保存一部分的数据,对于内存数据库来说,还是要尽量的减少冗余.在数据量太大的情况下,故障恢复需要较长时间. Redis

10.Redis分布式集群

10.Redis分布式集群10.1 数据分布10.1.1 数据分布理论10.1.2 Redis数据分区10.1.3 集群功能限制10.2 搭建集群10.2.1 准备节点10.2.2 节点握手10.2.3 分配槽10.2.4 用redis-trib.rb搭建集群10.3 节点通信10.3.1 通信流程10.3.2 Gossip消息10.3.3 节点选择10.4 集群伸缩10.4.1 伸缩原理10.4.2 扩容集群10.4.3 收缩集群10.5 请求路由10.5.1 请求重定向10.5.2 Smar