返回 登录
5

浅析开源数据库MySQL架构

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

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

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

二、利用MYSQL CLUSTER实现整体的高可用

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

三、通过MySQL的衍生产品实现高可用

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

四、各种高可用方案的利弊比较

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

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的动力。

评论