浅析开源数据库MySQL架构

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

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

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

普通的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中的时间戳信息进行对照，来找到准确的复制起始点，从而避免造成数据的丢失。

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

图六

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

图七

图八

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

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

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

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

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

优势：可靠性非常高，所有节点可以同时读写每一份数据，至少在不同主机上面存在一份拷贝，且冗余数据拷贝实时同步。

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

从架构上来说，它有点类似Replication，只是它是通过第三方的软件实现数据同步的过程，可靠性比Replication更高，但是也牺牲了性能。
优势：软件功能强大，数据在底层块设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致性的苛刻要求。

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

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

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