MySQL高可用架构的演进( 二 ) _高可用架构

3、跨机房部署：过半数的节点的机制，适合跨机房的集群容错部署，同个机房内的节点网络间通讯的延迟较小。
4、高扩展性：节点的增加与移除会自动更新组成员信息，新节点加入后，自动从其他节点同步增量数据，直到与其他节点数据一致，过程简单，无需过多的人工干预。
5、多种模式：支持单主与多主模式
缺点：
1、集群要求比较稳定的网络环境，不适用于WAN场景。
2、多主情况下容易有冲突发生，造成业务交易成功率低。
3、资源消耗较多

文章插图

其他的高可用方案

基于异步复制的主从方案
最常见的高可用方案之一是采用异步复制的方式，增加一个或者多个从节点，以实现主节点异常时可以快速切换，这种情况下经常会有binary log落后的情况，一般情况下也无法很好的实现自动切换，所以很多时候作为灾备使用，并且业务上能够接受一些数据丢失的情况。
使用SAN共享存储
传统的数据库产品会使用SAN共享存储在存储数据，多个数据库实例并发访问共享存储存取数据，应用通过虚拟IP访问数据库，当某个数据库挂掉以后会由其他正常的实例接管虚拟IP继续对外提供服务。这种方案有明显的问题，一在于共享存储的成本高，二在于共享存储本身又称为了单点。
使用DRBD网络RAID方案
DRBD是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案,实际使用并不多，主要原因在于DRBD本身速度会成为瓶颈，并且通过基于块的存储复制，只能作为灾备，无法同时对外提供服务，存在比较大的资源浪费。
使用NFS等网络文件系统
这种方案类似使用SAN共享存储，但是性能会更差，网络文件系统难以实现高吞吐，瓶颈非常明显。
使用分布式文件系统
使用分布式文件系统存放数据是另外一种考虑的方向，不同的数据库实例可以使用分布式文件系统的数据，一致性和高可用交由底层分布式文件系统处理，但是这种模式下也很难实现故障的切换，并且引入分布式文件系统更加复杂。
使用主主架构
主主架构其实本质上也是异步复制，相对于主从，主主架构的好处在于当其中一个节点故障时可以直接切换，免去了从节点切换为主节点的流程。但是，一般建议不要使用，因为可能存在主键冲突、从节点上误操作同步到了主节点等情况，使用主从架构更加稳健。这种架构适用于对数据没有强一致性要求，允许丢失少量数据的情况，当做灾备或者提供更大的读能力的场景。
MariaDB Galera Cluster
MariaDB是Mysql的一个分支，在业内也是被广泛使用的，Galera Cluster是MariaDB提供的高可用的集群方案，其在MySQL InnoDB存储引擎基础上打了wrep(虚拟全同步复制)patch，提供了强一致性、高可用的能力，Percona/MariaDB各自的发行版都支持了这个功能，目前支持XtraDB/InnoDB存储引擎。Galera Cluster有以下优缺点：优点：
1、同步复制(注意，这里的同步仍然是指事务发送到各个节点的过程，事务在各个节点的应用的过程仍然是异步的，各个节点独立的)2、真正的 multi-master，所有节点可以同时读写数据库3、自动的节点成员控制，失效节点自动被清除4、新节点加入数据自动复制、支持并行复制5、事务不丢失，不存在主从不一致的情况下缺点：
1、一般只支持三个节点，网络越慢，主节点越多，则越容易有性能的瓶颈，集群扩展性受限。2、事务的提交需要等待集群所有节点的确认回复，无法支持跨机房部署的场景，因为跨机房的网络抖动延迟较大。3、多主情况下容易有冲突发生，造成业务交易成功率低。4、非MySQL官方，虽然社区也很优秀，但对于一些企业来说，会要求官方版本。

文章插图

MySQL NDB Cluster
MySQL NDB Cluster是MySQL官方提供的集群同步方案，是一个真正全同步的方案，整体架构如下：

文章插图

集群分为三种角色：
Management Node
实现对集群其他节点的管理，维护元数据信息，例如数据节点内存大小、数据节点数据存放位置，SQL节点位置信息等。
SQL Node
数据节点不直接提供应用程序访问，SQL节点对接应用程序，转发请求到数据节点，Cluster中可以有多个SQL节点，每个SQL节点查询到的数据都是一致的，一般来说，SQL节点越多，分配到每个SQL节点的负载就越小，系统的整体性能就越好。