关于脑裂我们先来看看红帽的文档是如何解释的
# What does "split-brain" mean?
"Split brain" is a condition whereby two or more computers or groups of computers lose contact with one another but still act as if the cluster were intact. This is like having two governments trying to rule the same country. If multiple computers are allowed to write to the same file system without knowledge of what the other nodes are doing, it will quickly lead to data corruption and other serious problems.
Split-brain is prevented by enforcing quorum rules (which say that no group of nodes may operate unless they are in contact with a majority of all nodes) and fencing (which makes sure nodes outside of the quorum are prevented from interfering with the cluster).
在“双机热备”高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。由于相互失去了联系,都以为是对方出了故障,2个节点上的HA软件像“裂脑人”一样,“本能”地争抢“共享资源”、争起“应用服务”,就会发生严重后果:或者共享资源被瓜分、2边“服务”都起不来了;或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据库轮询着的联机日志出错)。
运行于备用主机上的Heartbeat可以通过以太网连接检测主服务器的运行状态,一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下,主、备服务器间的心跳连接是一个独立的物理连接,这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态,而其只要能通过其中一个连接收到主服务器处于活动状态的信息,就会认为主服务器处于正常状态。从实践经验的角度来说,建议为Heartbeat配置多条独立的物理连接,以避免Heartbeat通信线路本身存在单点故障。
1、串行电缆:被认为是比以太网连接安全性稍好些的连接方式,因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序,从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度,因此主、备服务器的距离必须非常短。
2、以太网连接:使用此方式可以消除串行线缆的在长度方面限制,并且可以通过此连接在主备服务器间同步文件系统,从而减少了从正常通信连接带宽的占用。
基于冗余的角度考虑,应该在主、备服务器使用两个物理连接传输heartbeat的控制信息;这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况,这种争用资源的场景即是所谓的“脑裂”(split-brain)或“partitioned cluster”。在两个节点共享同一个物理设备资源的情况下,脑裂会产生相当可怕的后果。
为了避免出现脑裂,可采用下面的预防措施:
添加冗余的心跳线,例如双线条线。尽量减少“裂脑”发生机会。
启用磁盘锁。正在服务一方锁住共享磁盘,“裂脑”发生时,让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题,如果占用共享盘的一方不主动“解锁”,另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃,就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即,正在服务的一方只在发现心跳线全部断开(察觉不到对端)时才启用磁盘锁。平时就不上锁了。
设置仲裁机制。例如设置参考IP(如网关IP),当心跳线完全断开时,2个节点都各自ping一下 参考IP,不通则表明断点就出在本端,不仅“心跳”、还兼对外“服务”的本端网络链路断了,即使启动(或继续)应用服务也没有用了,那就主动放弃竞争,让能够ping通参考IP的一端去起服务。更保险一些,ping不通参考IP的一方干脆就自我重启,以彻底释放有可能还占用着的那些共享资源。
参考至:http://surpassdream.blog.51cto.com/1347340/284974
http://www1.chinaunix.com/space.php?uid=25715911&do=blog&id=261403
本文原创,转载请注明出处、作者
如有错误,欢迎指正
邮箱:czmcj@163.com
分享到:
相关推荐
redis哨兵模式之脑裂现象.docx
基于Oracle RAC 双活方案实施,如何规避脑裂风险- 最佳实践.docx
容灾脑裂及解决方案.pptx
本文详细介绍了Redis高可用集群的搭建和优化策略。首先对比了哨兵模式和高可用集群模式,强调了集群模式在性能和高可用性方面...最后,对集群中可能出现的问题如网络抖动和脑裂等进行了分析,并提供了相应的解决方案。
ElasticSearch集群脑裂优化设置,配合博文ES集群优化。
heartbeat、drbd配置较为复杂,需要自己写脚本才能实现MySQL自动切换,对于不会脚本语言的人来说,这无疑是一种脑裂问题;对于mmm,生产环境中很少有人用,且mmm 管理端需要单独运行一台服务器上,要是想实现高可用...
mysql+lvs+keepalive+mha高可用,vip漂移,可以看我博客有新教程,不用keepalive。因为keepalive存在脑裂
es高可用 防止集群脑裂问题 防止单点故障问题 Master节点故障 Data节点故障 节点可迁移 集群的横向动态扩容
通过keepalived,实现多台GlusterFS高可用的存储配置方案。2个节点的GlusterFS无法避免脑裂问题,多台GlusterFS如何提供统一的挂载服务,通过该技术方案,完美的实现了VIP方式的高可用的GlusterFS存储方案。
infinispan-presentation-splitbrain Infinispan 脑裂演示
No.1【脑裂风险】存储跨中心双活方案设计阶段该如何尽量避免脑裂? No.2【性能影响】存储跨中心双活方案设计阶段如何尽量降低对整体性能的影响? No.3【数据一致性风险】跨中心的双活存储数据一致性如何保障? No....
分析并解决keepalived脑裂导致20min中断事故
MySQL DBA for Galera Cluster集群架构搭建与管理,生产环境一定要为3台节点,可以阻止脑裂问题,更多的节点不会对写入有很大的提升,相反节点越多写入性能越差!
Sivyer's BlogIntroduction私人博客,用于记录个人知识及总结,是使用...分布式事务 心跳机制 顺序消费 消息去重 消息重试 主从复制 高可用设计Zookeeper 脑裂问题 羊群效应 分布式锁KafkaEsNettyMysqlSpring书籍阅读
Keepalived+HAProxy配置高可用负载均衡,解决keepalived无法安装问题,公司项目总结,经过压力测试。
通过存储仲裁的合理配置规避双活脑裂风险.docx
什么是MOBIKE高可用性(莫哈)?MoHA通过自动进行主节点故障转移和快速的主节点切换,为跨区域MySQL集群提供了高可用性(HA)。 高可用性主站故障检测和主站故障转移自动化可在几秒钟内实现主站切换。 预防脑裂通过...
MySQL Group Replication(MGR)是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案,以插件形式提供,实现了分布式下数据的最终一致性,总结MGR特点如下: 高一致性:基于分布式paxos协议实现组...
│ 第十三课MySQL5.7高可用架构之Mycat.pdf │ 第十三课MySQL8.0高可用架构之Mycat.pdf │ 第十九课MySQL备份和恢复.pdf │ 第十二课MySQL5.7复制.pdf │ 第十二课MySQL8.0复制.pdf │ 第十五课MySQL8.0高可用架构之...
Elasticsearch的特性 分布式、全文检索、近实时搜索和分析、高可用、模式自由、restful 讲述Elasticsearch的架构和Elasticsearch 的核心 概念 二、索引数据 单词 文档矩阵,倒排索引,倒排索引实例,单词词典 三、...