1。概述当我们考虑MySQL数据库的高可用架构时，主要考虑以下几个方面：1.1如果数据库宕机或意外中断，可以尽快恢复数据库的可用性，尽可能减少宕机时间，以及保证业务不会因为数据库故障而中断。1.2用于备份、只读副本等的非主节点数据应与主节点数据实时或最终一致。1.3业务数据库切换时，切换前后数据库内容应保持一致，不会因数据丢失或不一致而影响业务。关于高可用的分类，这里不做详细讨论。这里只讨论常见高可用方案的优缺点和高可用方案的选择。2.高可用方案2.1.Master-slave或master-master半同步复制是利用双节点数据库构建单向或双向半同步复制。在5.7之后的版本中，由于引入了无损复制、逻辑多线程复制等一系列新特性，MySQL原生的半同步复制更加可靠。常见的架构如下：通常与proxy、keepalived等第三方软件配合使用，可以用来监控数据库的健康状况，执行一系列的管理命令。如果主库出现故障，切换到备库后该数据库仍然可以使用。优点：架构比较简单，采用原生的半同步复制作为数据同步的基础；双节点，主机宕机后无选主问题，直接切换即可；双节点，资源需求少，易于部署；缺点：完全依赖于半同步复制，如果半同步复制退化为异步复制，则无法保证数据的一致性；需要额外考虑haproxy和keepalived的高可用机制。2.2.半同步复制优化半同步复制机制是可靠的。如果半同步复制一直有效，那么数据就可以认为是一致的。但由于网络波动、半同步复制超时切换到异步复制等客观原因，此时无法保证数据的一致性。因此，尽可能保证半同步复制可以提高数据的一致性。该方案同样采用双节点架构，但在原有半同步复制的基础上进行了功能优化，使得半同步复制机制更加可靠。可参考的优化方案如下：2.2.1．双通道复制半同步复制。发生超时后，复制将断开连接。再次建立复制时，同时建立两个通道，其中一个半同步复制通道从当前位置开始复制，保证slave知道当前master的进度。另一个异步复制通道开始追赶从站的滞后数据。当异步复制通道赶上半同步复制开始时，恢复半同步复制。2.2.2.binlog文件服务器建立两个半同步复制通道。连接文件服务器的半同步通道在正常情况下是不开启的。当主从半同步复制出现网络问题，性能下降时，启动与文件服务器的半同步复制通道。当主从半同步复制恢复时，关闭与文件服务器的半同步复制通道。优点：双节点，所需资源少，部署简单；架构简单，没有选主问题，直接切换即可；与原生复制相比，优化后的半同步复制可以更好的保证数据的一致性。缺点：需要修改内核源码或使用mysql通讯协议。需要对源码有一定的了解，能够进行一定程度的二次开发。仍然依赖于半同步复制，并没有从根本上解决数据一致性问题。2.3.高可用架构优化将双节点数据库扩展为多节点数据库，或多节点数据库集群。您可以根据需要选择一主两从集群、一主多从集群、多主多从集群。由于半同步复制有一个特点，当收到一个slave成功的响应就认为半同步复制成功，所以多slave半同步复制的可靠性要优于单slave半同步复制。同步复制。并且多节点同时宕机的概率也小于单节点宕机的概率，所以在一定程度上可以认为多节点架构比双节点架构更适合高可用。但是由于数据库数量众多，需要数据库管理软件来保证数据库的可维护性。你可以选择MMM、MHA或者各种版本的proxy等等。常见的解决方法如下：2.3.1．MHA+多节点集群MHAManager会定时检测集群中的master节点。当master出现故障时，它可以自动将拥有最新数据的slave提升为新的master，然后重启所有其他slave。指向新的master，整个故障转移过程对应用程序是完全透明的。MHANode运行在每台MySQL服务器上，主要功能是在切换时处理二进制日志，保证切换时尽可能少的丢失数据。MHA还可以扩展到以下多节点集群：优点：可以自动检测和转移故障；具有良好的扩展性，可以根据需要扩展MySQL节点的数量和结构；与两节点MySQL复制相比，三节点/多节点MySQL不可用的概率较低缺点：至少需要三个节点，比两个节点需要更多的资源；逻辑更复杂，故障发生后更难排查和定位问题；数据一致性仍然依赖于原生的半同步复制保证，仍然存在数据不一致的风险；网络分区可能会出现脑裂现象；2.3.2.zookeeper+proxyZookeeper采用分布式算法保证集群数据的一致性，使用zookeeper可以有效保证proxy的高可用。可以更好的避免网络分区的现象。优点：更好的保证了整个系统的高可用，包括proxy和MySQL；更好的扩展性，可以扩展成大规模的集群；缺点：数据一致性仍然依赖于原来的mysql半同步复制；zk的引入，整个系统的逻辑变得更加复杂；2.4.共享存储共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL原生的复??制功能，而是通过磁盘数据同步的方式。以保证数据的一致性。2.4.1.SAN共享存储SAN的概念是允许在存储设备和处理器（服务器）之间建立直接的高速网络（相对于LAN）连接，通过它可以实现数据的集中存储。常见的架构如下：使用共享存储时，MySQL服务器可以挂载文件系统并正常运行。如果主库宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。优点：两个节点就够了，部署简单，切换逻辑简单；数据强一致性得到很好的保证；不会因为MySQL逻辑错误导致数据不一致；缺点：需要考虑共享存储的高可用；昂贵的;2.4.2.DRBD磁盘复制DRBD是一种基于软件、基于网络的块复制存储解决方案，主要用于服务器之间的磁盘、分区、逻辑卷等的数据镜像。当用户向本地磁盘写入数据的同时，会将数据发送到网络中另一台主机的磁盘中，从而实现本地主机（主节点）和远程主机（备节点）的数据同步实时。常用的架构如下：当本地主机出现问题时，远程主机仍然保留一份相同数据的副本，可以继续使用，保证数据安全。DRBD是Linux内核模块实现的一种快速级同步复制技术，可以达到和SAN一样的共享存储效果。优点：两个节点就够了，部署简单，切换逻辑简单；与SAN存储网络相比，价格低；保证数据的强一致性；缺点：对io性能影响很大；从库不提供读操作；2.5.分布式分布式协议可以很好的解决数据一致性问题。比较常见的方案如下：2.5.1.MySQL集群MySQL集群是官方的集群部署方案，利用NDB存储引擎实时备份冗余数据，实现数据库的高可用和数据一致性。优点：全部使用官方组件，不依赖第三方软件；可以实现数据的强一致性；缺点：国内使用较少；配置比较复杂，需要用到NDB存储引擎，区别于MySQL正则引擎；至少三个节点；2.5.2.Galera基于Galera的MySQL高可用集群。它是一个用于多主数据同步的MySQL集群解决方案。简单易用，无单点故障，可用性高。常见架构如下：优点：多主写，无延迟复制，可以保证数据强一致性；有成熟的社区，互联网公司正在大规模使用；自动故障转移，自动添加和删除节点；缺点：需要在原生MySQL节点上打wsrep补丁，只支持至少三个节点的innodb存储引擎；2.5.3.POAXSPaxos算法解决的是分布式系统如何就某个值（分辨率）达成共识的问题。该算法被认为是同类算法中最有效的。Paxos和MySQL的结合可以实现分布式MySQL数据的强一致性。常见架构如下：优点：多主写，无延迟复制，可以保证数据强一致性；成熟的理论基础；自动故障转移，自动添加和删除节点；缺点：只支持至少三个节点的innodb存储引擎；3.总结随着人们对数据一致性要求的不断提高，尝试了越来越多的方法来解决分布式数据一致性问题，比如MySQL自身优化、MySQL集群架构优化、Paxos、Raft、2PC等算法的引入和很快。使用分布式算法解决MySQL数据库数据一致性问题越来越被人们所接受。PhxSQL、MariaDBGaleraCluster、PerconaXtraDBCluster等一系列成熟产品越来越多地被大规模使用。随着MySQLGroupReplication官方的GA，使用分布式协议解决数据一致性问题成为了主流方向。期待越来越多优秀的解决方案被提出来，更好的解决MySQL的高可用问题。
