共计 2661 个字符,预计需要花费 7 分钟才能阅读完成。
导读 | 数据库是所有应用系统的核心,故保证数据库稳定、高效、安全地运行是所有企业日常工作的重中之重。数据库系统一旦出现问题无法提供服务,有可能导致整个系统都无法继续工作。所以,一个成功的数据库架构在高可用设计方面也是需要充分考虑的。下面就为大家介绍一下如何构建一个高可用的 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 的动力。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)