浅析开源数据库MySQL架构

数据库是全部应用系统的核心，故保证数据库稳定、高效、安全地运行是全部企业平常工做的重中之重。数据库系统一旦出现问题没法提供服务，有可能致使整个系统都没法继续工做。因此，一个成功的数据库架构在高可用设计方面也是须要充分考虑的。下面就为你们介绍一下如何构建一个高可用的MySQL数据库系统。

作过DBA或者是运维的同窗都应该知道，任何设备或服务，存在单点就会带来巨大风险，由于这台物理机一旦宕机或服务模块crash，若在短期内没法找到替换的设备，势必会影响整个应用系统。于是如何保证不出现单点就是咱们的重要工做，使用MySQL高可用方案能够很好地解决这个问题，通常有如下几种：

1、利用MySQL自身的Replication来实现高可用

MySQL自带的Replication就是咱们常说的主从复制（AB复制），经过对主服务器作一个从机，在主服务器宕机的状况下快速地将业务切换到从机上，保证应用的正常使用。利用AB复制作高可用方案也分为几种不一样的架构：

1、常规的MASTER---SLAVE解决方案

普通的MASTER---SLAVE是目前国内外大多数中小型公司最经常使用的一种架构方案，主要的好处就是简单、使用设备较少（成本较低）、维护方便。这种架构能解决单点的问题，并且还能在很大程度上解决系统的性能问题。在一个MASTER后面能够带上一个或者多个的SLAVE（主从级联复制），不过这种架构要求一个MASTER必须可以知足系统全部的写请求，否则就须要作水平拆分分担读的压力。

图一

 

图二

图一到图二展现的是：解决单点问题和利用读写分离达到提升性能的过程。

2、DUAL MASTER与级联复制结合

双主多从是在上面的方案中衍生而来的一种更加合理的方案。这个方案的好处是：当两个主服务器中任何一个挂掉时，整个架构都不用作大的调整。

 

图三

 

图四

 

图五

这个过程如上图所示。但图五这种状况比较特殊，即MASTER-B宕机的话怎么办呢？首先能够肯定的是咱们的全部Write请求都不会受到任何影响，并且全部的Read请求也都可以正常访问；但全部Slave的复制都会中断，Slave上面的数据会开始出现滞后的现象。这时候咱们须要作的就是将全部的Slave进行CHANGE MASTER TO操做，改成从Master A进行复制。因为全部Slave的复制都不可能超前最初的数据源，因此能够根据Slave上面的Relay Log中的时间戳信息与Master A中的时间戳信息进行对照，来找到准确的复制起始点，从而避免形成数据的丢失。

2、利用MYSQL CLUSTER实现总体的高可用

就目前而言，利用MYSQL CLUSTER实现总体的高可用（即NDB CLUSTER）的方案在国内的公司并无很普及。NDB CLUSTER节点实际上就是一个多节点的MySQL服务器，可是并不包含数据，因此任何机器只要安装了就可使用。当集群中某一个sql节点crash以后，由于节点不存具体的数据，因此数据不会丢失。如图六：

 

图六

3、经过MySQL的衍生产品实现高可用

在目前MySQL实现高可用的衍生产品中，知名度的和普及度比较高的是GALERA CLUSTER和PERCONA XTRDB CLUSTER（PXC）。相关的内容本文暂不展开讲述，感兴趣的同窗能够查阅相关资料进一步了解。这两种集群的实现方式都是相似的，如图7、图八：

 

图七

 

图八

4、各类高可用方案的利弊比较

在前面各类高可用设计方案的介绍中读者们可能已经发现，不论是哪种方案，都存在本身独特的优点，但也都或多或少存在一些限制。这一节将针对上面的几种主要方案作一个利弊分析，以供你们选择过程当中参考。

1、MySQL Replication

优点：部署简单，实施方便，维护也不复杂，是MySQL天生就支持的功能。且主备机之间切换方便，经过第三方软件或者自行编写的脚本便可自动完成主备切换。

劣势：若是Master主机硬件故障且没法恢复，则可能形成部分未传送到Slave端的数据丢失。

2、MySQL Cluster （NDB）

优点：可用性很是高，性能很是好。每一份数据至少在不一样主机上面存在一份拷贝，且冗余数据拷贝实时同步。

劣势：维护较为复杂，产品较新，存在部分bug，目前还不必定适用于比较核心的线上系统。

3、GALERA CLUSTER和PERCONA XTRDB CLUSTER（PXC）

优点：可靠性很是高，全部节点能够同时读写每一份数据，至少在不一样主机上面存在一份拷贝，且冗余数据拷贝实时同步。

劣势：随着集群的规模扩大，性能会愈来愈差。

4、 不得不提的DRBD磁盘网络镜像方案

从架构上来讲，它有点相似Replication，只是它是经过第三方的软件实现数据同步的过程，可靠性比Replication更高，可是也牺牲了性能。

优点：软件功能强大，数据在底层块设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不一样级别的同步。IO操做保持顺序，可知足数据库对数据一致性的苛刻要求。

劣势：非分布式文件系统环境没法支持镜像数据同时可见，即性能和可靠性二者相互矛盾，没法适用于对两者要求都比较苛刻的环境。维护成本高于MySQL Replication。

说完了各类经常使用架构的优缺点后，剩下的就是如何选择合适的架构在现实的生产环境中使用的问题。在这方面每一个人都有本身的想法和经验，具体哪一个方案是最优的就见仁见智了。在平常的工做中架构的完善并非一蹴而就，而是一个不断演变优化完善的过程。

个推在数据库方面也经历了从单点到主从再到主从+高可用的过程，同时也经历了从单一的MySQL+redis到MySQL+redis+es，最后到如今MySQL+redis+es+codis等等的演变。每一次的演变都是为了解决生产环境下的实际问题和痛点。单从MySQL来讲任何一个架构都没法解决全部的问题（痛点），都须要根据实际的状况选择一个合适架构。MySQL集群实现的方案很是灵活多变，对于MySQL工做者来讲如何选择一个合适的架构也是一种挑战，同时也是咱们不断钻研和学习MySQL的动力。