在MySQL的高可用架构中，MHA、MGR等方法现在比较流行，mm+keepalive的方法目前来看是比较老旧的办法，今天对这种办法做一个简单的介绍，题目中写的"纸上谈兵"，是因为这个实验我没有做，也不打算做，旨在说明清除原理即可。
脑裂（split-brain）：指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，例如都去用同一个ip提供网页服务，结果会导致系统混乱，数据损坏。
脑裂（split-brain），指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。
3月16日在北京举行的腾讯云自研数据库CynosDB交流会圆满落下帷幕。现将技术团队分享的内容整理如下。
相对于其他的数据库厂商大会，MySQL的的确寒酸，连幕头都没有，上来就直接讲，不过也符合MySQL一贯的风格。这次翻译的是 2023年MySQL summit -- MySQL high availability and disaster recovery。开始本次的讲解人是 MySQL的产品经理，明显和我之前听的MongoDB的两期差距较大，一看是不善言辞的人。
组建MySQL集群的几种方案 LVS+Keepalived+MySQL（有脑裂问题？但似乎很多人推荐这个） DRBD+Heartbeat+MySQL（有一台机器空余？Heartbeat切换时间较长？有脑裂问题？） MySQL Proxy（不够成熟与稳定？使用了Lua？是不是用了他做分表则可以不用更改客户端逻辑？） MySQL Cluster （社区版不支持INNODB引擎？商用案例不足？） MySQL + MHA （如果配上异步复制，似乎是不错的选择，又和问题？） MySQL + MMM （似乎反映有很多问
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件。 Keepalived采用是模块化设计，不同模块实现不同的功能； keepalived主要有三个模块，分别是core、check和vrrp。 core：是keepalived的核心，负责主进程的启动和维护，全
本文重点讲解ZooKeeper脑裂问题的处理办法。ZooKeeper是用来协调（同步）分布式进程的服务，提供了一个简单高性能的协调内核，用户可以在此之上构建更多复杂的分布式协调功能。脑裂通常会出现在集群环境中，比如Elasticsearch、ZooKeeper集群，而这些集群环境有一个统一的特点，就是它们有一个大脑，比如Elasticsearch集群中有Master节点，ZooKeeper集群中有Leader节点。
前面大家介绍了主从、主主复制以及他们的中间件mysql-proxy的使用，这一篇给大家介绍的是keepalived的搭建与使用！ 一、keepalived简介 1.1、keepalived介绍 Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态，如果某个服务器节点出现异常， 或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完
所谓脑裂，就是指两个或多个节点都“认为”自身是正常节点而互相“指责”对方，导致不能选取正确的节点进行接管或修复，导致脑裂状态。这种现象出现在数据修复、集群管理等等高可用场景。
在etcd集群中，如果出现网络分区或节点失联等情况，可能会导致脑裂（split-brain）现象的发生。脑裂指的是一个集群中的不同部分独立地对外提供服务，而且这些部分互相不可见、不可达。这会导致etcd中存储的数据出现不一致的情况，进而影响到整个系统的稳定性和可用性。本文将介绍etcd集群脑裂的原因以及如何处理。
脑裂（split-brain） 指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。 对于无状态服务的HA，无所谓脑裂不脑裂；但对有状态服务(比如MySQL)的HA，必须要严格防止脑裂。（但有些生产环境下的系统按照无状态服务HA的那一套去配置有状态服务，结果可想而知...） 如何防止HA集群脑裂 一般采用2个方法 1）仲裁 当两个节点出现分歧时，由第3方的仲裁者决定听谁的。这个仲裁者，可能是一个锁服
Redis 脑裂问题是指，在 Redis 哨兵模式或集群模式中，由于网络原因，导致主节点（Master）与哨兵（Sentinel）和从节点（Slave）的通讯中断，此时哨兵就会误以为主节点已宕机，就会在从节点中选举出一个新的主节点，此时 Redis 的集群中就出现了两个主节点的问题，就是 Redis 脑裂问题。
针对目前公司的数据库架构要做统计规划和调整，所以针对不同的业务环境要选择合适的架构就比较重要，同时作为运维人员又要考虑到维护的便捷性（不能做过多架构维护），最终停留在mha+vip/主从+vip/mycat集群/域名+主从这几种架构或组合，这里就分布对不同架构部署做下记录并对比起优劣，针对不同场景做出合适的选择。
主从集群有1个主库、5个从库和3个哨兵实例，突然发现客户端发送的一些数据丢了，直接影响业务层数据可靠性。
目前大多数项目都在往分布式上发展，一旦系统采用分布式系统，便会引入更多复杂场景和解决方案。比如，当你在系统中使用了Elasticsearch、ZooKeeper集群时，你是否了解过集群的“脑裂”现象？又是否知道它们是如何解决脑裂问题的？
# gluster volume heal VOLNAME info split-brain
在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样，争抢“共享资源”、争起“应用服务”，就会发生严重后果——或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。
在集群中，节点间通过心跳来了解彼此的健康状态，以确保各节点协调工作。假设只有“心跳”出现问题，但各个节点还在正常运行，这时，每个节点都认为其它的节点宕机了，自己才是整个集群环境中的“唯一健在者”，自己应该获得整个集群的“控制权”。在集群环境中，存储设备都是共享的，这就意味着数据灾难。简单点说，就是如果由于私有网络硬件或软件的故障，导致集群节点间的私有网络在一定时间内无法进行正常的通信，这种现像称为脑裂。在发生脑裂情况后，集群的某些节点间的网络心跳丢失，但磁盘心跳依然正常，集群根据投票算法（Quorum Algorithm）将不正确的节点踢出集群。磁盘心跳的主要目的是当集群发生脑裂时可以帮助指定脑裂的解决方案。
所谓的脑裂，就是指在主从集群中，同时有两个主节点，它们都能接收写请求。而脑裂最直接的影响，就是客户端不知道应该往哪个主节点写入数据，结果就是不同的客户端会往不同的主节点上写入数据。而且，严重的话，脑裂会进一步导致数据丢失。
所谓的脑裂问题，就是在多机热备的高可用 HA 系统中，当两个节点心跳突然断开，就分裂为了两个独立的个体，由于互相失去联系，都认为对方出现了故障，因此都会去争抢对方的资源，争抢启动，由此就会发生严重的后果。 举个形象的例子，A 和 B 作为一个双机热备集群的两个节点，各自持有集群的一部分数据 — a 和 b，这时，两机器之间突然无法通信，A 认为 B 已经挂掉，B 认为 A 已经宕机，于是会出现：
要了解什么是脑裂，首先我们要明白es集群的组成。ES集群由一个主节点（多个备选节点组成）和多个数据节点组成的，主节点负责创建，删除索引，分配分片，追踪集群的节点状态等工作，即是调度节点，计算压力比较低，而数据节点负责数据存储与具体的操作，比如搜索，聚合等任务，计算压力比较大。
是指在主从集群中，同时有两个主节点，它们都能接收写请求。而脑裂最直接的影响，就是客户端不知道应该往哪个主节点写入数据，结果就是不同的客户端会往不同的主节点上写入数据。而且严重的话，脑裂会进一步导致数据丢失；
MGR（Mysql Group Replication）是5.7版本新加的特性，是一个MySQL插件。
本质是通过冗余实现高可用(多台、多机房、多通道), 但是冗余带来了更大的复杂性. 比如任务分配器(例nginx)连接检测、管理、维护、中断处理.
因为master -> slave的复制是异步的（客户端发送给redis，主节点数据同步到内存中后就返回成功了） 所以可能有部分数据还没复制到slave，master就宕机了，此时master内存中的数据也没了，这些部分数据就丢失了。
如果发生网络中断或者服务器宕机，那么集群会有可能被划分为两部分，各自有自己的master来管理，那么这就是脑裂。
1、在线调整参数： 对现有资源的配置文件进行修改，两个对等节点要保持一致，然后执行 drbdadm adjust <resource> 在两个节点上都要执行； 2、在线校验数据完整性；（这个对性能还是有很大影响的） 它通过验证源对每个底层的设备某一资源的块存储设备一次计算出加密摘要，传输到对等节点，对摘要对应的本地副本块进行验证，若不匹配，则进行标识并进行重新同步，在线验证过程中不会阻塞资源的复制，不会造成系统的中断； 操作方式： 配置文件中修改：
互为主备要引入两个VIP，如mysql双主，nginx双主，这样要引入两个VIP，也就是还需要引入。
第三步：在MySQL01数据库中创建一个ds_wp数据库，然后倒入 ds_wp.sql
关于集群中的"脑裂"问题，之前已经在这里详细介绍过，下面重点说下Zookeeper脑裂问题的处理办法。ooKeeper是用来协调（同步）分布式进程的服务，提供了一个简单高性能的协调内核，用户可以在此之上构建更多复杂的分布式协调功能。脑裂通常会出现在集群环境中，比如ElasticSearch、Zookeeper集群，而这些集群环境有一个统一的特点，就是它们有一个大脑，比如ElasticSearch集群中有Master节点，Zookeeper集群中有Leader节点。
GlusterFS是一种分布式文件系统，项目中使用它作为数据文件冷备存储后台。GlusterFS的技术特点是采用无元数据中心的架构，采用Xlator以调用栈的形式组织各功能模块，Xlator之间通过RPC进行通信，客户端与服务端共用某些Xlator，下图就是Gluster客户端与服务端的Xlator栈示意图。
该文讲述了在高可用系统中，当心跳线出现故障时，会导致整个系统分裂成两个独立的部分，并产生不良影响。为了解决这个问题，可以采用添加冗余心跳线、启用磁盘锁和设置仲裁机制等方法。
两个节点可以采用简单的一主一从模式，或者双主模式，并且放置于同一个VLAN中，在master节点发生故障后，利用keepalived/heartbeat的高可用机制实现快速切换到slave节点；
最近PXC 5.7出现脑裂，前端Navicate连接到MySQL时，提示WSREP has not yet prepared node for application use错误。脑裂可是个不容易忽视的问题啊，严重的导致数据错乱。你懂的，就好比酒驾，迷糊啊，都乱了。下文是本次故障的具体描述。
自 2008 年双 11 以来，在每年双 11 超大规模流量的冲击上，蚂蚁金服都会不断突破现有技术的极限。2010 年双 11 的支付峰值为 2 万笔/分钟，到 2017 年双 11 时这个数字变为了 25.6 万笔/秒。
Distributed Replicated Block Device(DRBD)是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。其核心功能通过Linux的内核实现，比文件系统更加靠近操作系统内核及IO栈。DRBD是由内核模块和相关脚本而构成，用以构建高可用性的集群。其实现方式是通过网络来镜像整个设备。你可以把它看作是一种网络RAID。它允许用户在远程机器上建立一个本地块设备的实时镜像。
如果因为网络的故障，导致一个集群被划分成了两片，每片都有多个node，以及一个master，那么集群中就出现了两个master了。
做多活比较难搞的是中间件的多活和有状态服务的数据同步。zk作为一般公司的服务发现的方案，其多机房集群的搞法也是一个问题。
随着云计算、大数据等技术的普及，运维岗位在IT领域中的地位越来越重要。一个优秀的运维工程师不仅要具备扎实的技术基础，还需要具备良好的问题解决能力、团队协作精神和学习能力。因此，面试是选拔优秀运维工程师的关键环节。
创建容错系统的最常见方法是创建组件冗余，换句话说，组件可以被移除，而系统应该继续按预期运行。这就造成了一系列的挑战，将这种系统的复杂性提高到一个完全不同的水平。具体而言，复制的数据库需要同时维护和管理若干个server成员，而不只是一个。此外，当多个server协同工作是，系统必须处理其他一些常见的分布式系统问题，诸如断网或脑裂等情况。
在这些可选项中，最常见的就是基于主从复制的方案，其次是基于Galera的方案，我们重点说说这两种方案。其余几种方案在生产上用的并不多，我们只简单说下。
UP之前都是在自己的阿里云服务器和腾讯云服务器上测试的ES,之前的关于ES以及Kibana的操作都是可以正常的执行的,但是这次在配置ES集群的时候问题却是一直有问题.虽然两者的ES都能够正常启动,但是双方节点都显示找不到对方节点,一直处于ping对方节点的状态.并且由于双方节点都处于这种状态,导致两台服务器的Kibana都无法正常连接到相应的ES,导致后续的操作都无法正常执行.
在工作中，经常会用到zookeeper,当然跟它的功能离不开，无论是搭建大数据中间件kafka，hbase等还是开发流程引擎做备份选举。而考虑到zookeeper的时候，不得不说一下搭建集群时为神马要做到用奇数个节点。原先接触的不多，只需要知道这个事情就好，今天好奇研究了一下。
自 2008 年双 11 以来，在每年双 11 超大规模流量的冲击上，蚂蚁金服都会不断突破现有技术的极限。
简介：汤波（甘盘），男，1989/02/21，硕士学历。高中开始编程，热爱技术，深信技术让世界更美好。对前沿技术一直保持饥饿感，热衷于创新和革新，让系统体制更为高效和人性化，也深知一个人强走的快，一个团体强才能走的远。在技术团队建设（团队招聘和组建、梯队梯度建设）、技术栈管理（包含技术选型、技术规范建设、软件体系规划）和项目研发管理（软件工程管理、开发效能和质量管理）方面有着较为丰富的实践经验, 维护个人博客tbwork.org。 关注领域：企业中后台，SaaS，PaaS，大型分布式架构，Serverless，Service mesh，新零售，互联网全栈，网络应用/协议开发，计算机算法应用，区块链，人工智能。
领取专属 10元无门槛券
手把手带您无忧上云
