现在的企业中mysql数据库，它的高可用的方案有哪些？其实方案有很多种，本文给大家做一个横向的对比。
本文将一次性的给大家分享两大类的高可用方案。
第一类是支持自动故障转移的高可用架构，其中包含了6种不同的架构方案。另外一类是针对的数据可靠性，提供了3种有效性方案。一共加起来有九种。
每一种方案我都会用最简单的图例给大家介绍它的特点以及优缺点，以及它的一些特性。
首先是故障自动转移方案。
一、Multi Master Replication Manager(MMM)
对于Multi Master Replication Manager(MMM)，我的评价是廉颇老矣，技术有点久远了，它是支持单主的。
MMM是最早期的mysql针对于主从数据库之间的故障转移和数据同步的方案。它是在建立在原有的mysql的主从复制的基础上，额外的增加了一个监控的服务器去监测MySQL主服务器的运行的状态。如果主服务器挂了，就让备用的服务器顶上。
注意，这里指的单主不是说只有一个主服务器，而是在同一时间只有一台主服务器对外提供服务。在我们实际使用的时候，主服务器之间采用的是VIP，也就是虚拟IP的方案来实现的自动故障转移。所以作为客户端来说，不需要去做任何的调整，就可以无感知的来形成数据库切换了，这是它的一些特点。
但是缺点也非常明显，因为是早期的设计，所以在数据的一致性方面缺少了很多的考量，容易丢失事务。在后期的mysql 5.5版本中出现了半同步复制以后，这个问题得到了一定程度上的解决。但是仍然是采用的是异步的数据不一致方案来进行的。故障转移概率的情况下会出现丢失的情况。而且最关键的是因为太过久远了，所以MMM现在已经基本上没有什么热度了，而且不支持主流的mysql 的GTID复制，这是最要命的情况。
二、MHA-霓虹国佳作-单主
现在针对于老版本的mysql数据库，比如你现在还在使用mysql 5.5版本或者5.6、5.7版本的话，这个时候MHA这种架构就是针对老版本数据库的一个比较好的选型了。
MHA架构的主要设计需要我们安装MHA的客户端，也就是节点，然后额外的部署一台服务器叫做manager监控器。作为管理者会对具体的主节点来进行状态监控。如果主节点挂掉了，那其他的从属节点，会选择一个同步率最高，也就是数据最完整的从节点代替成为新的主节点。
在这个处理过程中，主从之间的数据同步仍然是依赖mysql自带的基于binlog的主从复制方案。只不过它在这个基础上提供了自动的故障转移。而这个MHA就是master high of ability，也就是主高可用的意思。
这里的M就是master的意思，那也决定了它有一些具体的限制和场景。
我们在实践的过程中，主服务器挂了，mysql在5.5版本以后提供的半同步复制，它可以保证至少有一个从属服务器的数据和主服务器是一致的，这叫做半同步复制。所以MAA它会优先的使用半同步复制的一致的节点作为新的主服务器来对外提供服务。
但是MHA有一个比较大的缺点就在于它只关注主节点。你看到这个master high ability，也就是只关注主。作为从属节点，它只关注基本的状态。如果说某一个存储，比如说它服务不稳定，网络通信不稳定，这样的话它仍然会给我们来进行一个主从之间的切换。那切换到了一个不稳定的新的主服务器上，我们的系统的应用仍然是会出现问题的。所以这就是MHA它的问题，只关注到主了，对从的关心不够。
三、MySQL Group Replication(MGR)-5.7 单(荐)/多主
第三种方案是我现在在日常工作中建议和架构选型中使用到的最多的一种。就是在mysql 5.7.17版本以后的全同步复制方案，叫做MGR mysql组复制。在mysql 5.7.17版本以后，它提供了一个内置的插件，就是组复制插件。它的一个主要的设计就是在进行数据同步的时候，所有节点之间都是全同步的。也就是说在没有把数据给向其他基于log复制完成之前，客户端是无法收到响应的。所以MGR在任何一个时间对于当前可用的节点访问的时候，数据都是一致的。
MGR官方推荐的是使用单节点的单主模式。当然官方也说了支持多主模式，但是官方建议使用单主模式。你可以感觉它的这个措辞里边的委婉说明了什么问题。
MGR有两个优势。第一个就像前面提到的全同步，我们不用担心节点之间的状态一致性问题。另外一个就是它是不需要额外的部署监控节点，因为MGR底层采用的是paxo s选举算法。它会在当前的主服务器中，通过选举得到一个新的leader节点。所以MGR可以把所有的服务器都用在数据存储和处理上，并不需要额外的浪费设备资源去部署监控节点，这是它的优势所在。
但是MGR也有一些问题，它的使用有一些约束。
首先MGR是必须在GTID模式下，并且binlog的模式必须是row，因为这样才会记录数据变更前和变更后的状态。除了row以外，还有一种格式叫做statement。使用statement命令模式时，其实是在binlog里边保存的是具体的sql语句，而row保存的是数据。Statement在MGR中是不支持的。并且数据库的存储引擎必须是innoDB。
MGR的优势就在于强一致，以及无需部署额外的节点。在实际的构建过程中，MGR也推荐的是使用单主模式（一主多从），同时它也可以进行自动的故障转移。
四、MySQL Cluster-多主
mysql cluster有一个自带的集群模式。Mysql cluster是默认支持多种模式的。多种模式中有一个关键性的设计，就是它所有的节点都可以是主节点。它和前文提到的MHA、MGR，最大的区别就是它是第一个良好支持的官方自带多主的方案。
它的一个主要的含义，就是节点之间都是主没问题。但是对外暴露的时候，底层它的数据存储格式是一个叫做NDB node的分布式的存储节点。它里边的数据是进行有效性的同步。
所以我们访问到任何一个主，实际上在底层进行数据写入的时候，是基于NDB的存储引擎来完成的。因此这个存储区域里边本质上是存储了多份儿，但是我们在使用的时候，它就是一个逻辑上的整体。底层的数据存储是分布式的，而这个分布式的数据存储mysql自己实现的NDB存储引擎。
对于MySQL Cluster这个模式，它的好处就是首先多主模式，这是弥补以前的问题，同时数据是强一致的。
但是它最大的问题是我们国内开发时候都使用的是innoDB引擎，现在换成了NDB引擎。虽然两者非常相似，但是仍然有一些特性上的差异。所以我们之前在学习innoDB引擎的那些经验，无法嫁接在NDB上面。这些可能会造成一些额外的性能问题，或者一些莫名其妙的问题。所以基于此，国内使用是相对比较少的。
五、Galera Cluster-第三方优秀的多主高可用方案
Galera它是由三方所提供的一款插件扩展出来的，它的底层设计和mysql官方不太一样。它是数据仍然是存储在我们本地，不像NDB一样存储在一起。Galera是每一个存储自己的数据，但是通过他们所构建的WSREP的协议，完成数据之间的强同步的传输。也就是说我们既可以保证数据每台服务器存一份儿，同时又可以通过网络保证节点之间是强一致的。
所以日常开发时候，我们接入到任何一个主节点上面都是可以完成写操作的。同时从其他节点读取的时候，得到的也是最新的数据，没有中间的数据差异的状态，这是它的优势所在。
六、Percona XtraDB Cluster(PXC)-多主
PXC我给它的评价叫做既生瑜何生亮，它是一种早期的多主实现模式。PXC的全称是Percona XtraDB Cluster。它的出现和上文的Galera是非常类似的。只不过就像是不同厂商所开发的不同的解决方案。
就像tomcat提供了外部容器，我们jboss也提供了外部容器。虽然他们都做同样的事情，但是不同的厂商有不同的设计特点。
PXC的出现的比Galera要早，在早期的时候用的是比较多的，它是早期为数不多的支持多主的方案。但是后续Galera不管从性能上还有各方面的设计上来说，都有一部分要优于PXC，尤其是性能上面要好一些。
所以目前大家更倾向于Galera这个多主的方式。
以上就是6种MySQL高可用的支持故障转移的方案，每一个都有自己的使用场景和方案。
下面再看另外一个问题，就是高可用架构下的数据可靠性该如何保障？
这里我也给大家提供了三种方案，这三种方案了解一下。
一、RAID10-原始方案
RAID10-原始方案是最原始的在银行金融级别使用的比较多的方案。就是利用多块磁盘阵列，把一份数据来进行多次存储。这样就可以保障在数据哪怕有一个节点出现了丢失的话，也会有其他的备份会顶上。
其中RAID10代表的是将一大块数据拆分成两份儿，一份存在左边，一份存在右边，这叫做RAID 0。它把数据一分为二，那RAID1是针对刚才左右的这个数据进行一次复制，等于我们把这个数据做了一个备份。在读取的时候也可以从这个备份中往外进行读取。所以RAID1加RAID0叫RAID10。RAID10是使用到的最多的一种高可用的方案。
但是现在RAID 10有1个问题，它是单点的，它一般来说都会构建在一个地方。比如说发生了天灾，一块陨石把你的机房全毁了，那全都完蛋了。怎么办呢？
二、SAN共享存储-贵
这个时候我们还有另外一种方案，就是SAN共享存储。我们可以看一下共享存储网络的价格，64T的158000，这还是一个入门级别的产品，它干什么用的呢？就是通过一系列硬件的基础设施，构建出来一套可以支持远程数据备份，而且支持高可用和高速传输的这么一套存储解决方案，我们把它称为SAN存储网络。
这个存储网络它的性能是没有问题的。专务专用，除了贵没缺点。所以咱们在日常开发的时候，如果你有钱想保证数据安全，SAN是最好的选择了。它可以做到既要又要，但是唯独的就是你的钱包会瘪一点。
三、DRBD磁盘复制-系统自带
如果你没有那么多的预算，又需要保障数据之间的远程同步和备份怎么办呢？这个时候可以采用DRBD的磁盘复制，这是linux系统自带的方案。主和从之间，一个可以写，一个可以读。主和从之间，在disk在数据层面上基于操作系统来进行远程复制，这个是操作系统自带的特性。而disk这里边不是说只是一块硬盘，这个disk可以是刚才的RAID10。然后通过操作系统层面上的功能，实现了远程基于网络的数据的同步和复制。这样保证了数据至少有一个全量的备份。基于DRBD也是采用CP的方式，是强一致性的。
但是也有两个关键点要注意，第一个要保证网络是稳定的，最好是拉一条光纤。第二，这是我们这两台设备之间，尤其存储的地方的写入速度要足够高。否则基于强一致的这个disk，由于网络和写入的延迟就会相对比较高，这也对硬件提出了更高的要求。
希望这篇MySQL高可用架构方案介绍文章对大家有帮助。
推荐阅读：
苏公网安备32021302001419号