你的位置:首页 > 软件开发 > 数据库 > MySQL性能调优与架构设计——第 17 章 高可用设计之思路及方案

MySQL性能调优与架构设计——第 17 章 高可用设计之思路及方案

发布时间:2016-06-23 20:00:13
第 17 章 高可用设计之思路及方案 前言:数据库系统是一个应用系统的核心部分,要想系统整体可用性得到保证,数据库系统就不能出现任何问题。对于一个企业级的系统来说,数据库系统的可用性尤为重要。数据库系统一旦出现问题无法提供服务,所有系统都可能无法继续工作,而不像软件中部分系统出现 ...

MySQL性能调优与架构设计——第 17 章 高可用设计之思路及方案

第 17 章 高可用设计之思路及方案

前言:

数据库系统是一个应用系统的核心部分,要想系统整体可用性得到保证,数据库系统就不能出现任何问题。对于一个企业级的系统来说,数据库系统的可用性尤为重要。数据库系统一旦出现问题无法提供服务,所有系统都可能无法继续工作,而不像软件中部分系统出现问题可能影响的仅仅只是某个功能无法继续服务。所以,一个成功的数据库架构在高可用设计方面也是需要充分考虑的。本章内容将针对如何构建一个高可用的 MySQL 数据库系统来介绍各种解决方案以及方案之间的比较。

17.1 利用 Replication 来实现高可用架构

做维护的读者朋友应该都清楚,任何设备(或服务),只要是单点,就存在着很大的安全隐患。因为一旦这台设备(或服务) crash 之后,在短时间内就很难有备用设备(或服务)来顶替其功能。所以稍微重要一些的服务器或者应用系统,都会存在至少一个备份以供出现异常的时候能够很快的顶替上来提供服务。 如上图所示,当我们的 Slave 集群中的一台 Slave C 出现故障 crash 之后,整个系统的变化仅仅只是从 Master 至 Slave C 的复制中断,客户端应用的 Read 请求也不能再访问 Slave C。当时其他所有的 MyServer.aspx' target='_blank'>SQL Server 在不需要任何调整的情况下就能正常工作。客户端的请求 Read 请求全部由 Slave A 和 Slave B 来承担。

17.1.2 Master 单点问题的解决

上面的架构可以很容易的解决 Slave 出现故障的情况,而且不需要进行任何调整就能继续提供服务。但是,当我们的 Master 出现问题后呢?当我们的 Master 出现问题之后所有客户端的 Write 请求就都无法处理了。 当 Master 出现故障 crash 之后,原客户端对 Master 的所有 Write 请求都会无法再继续进行下去了,所有原 Master 到 Slave 的复制也自然就断掉了。这时候,我们选择一台 Slave 将其切换成 Master。假设选择的是 Slave A,则我们将其他 Slave B 和 Slave C都通过 CHANGE MASTER TO 命令更换其 Master,从新的 Master 也就是原Slave A 开始继续进行复制。同时将应用端所有的写入请求转向到新的 Master。对于 Read 请求,我们可以去掉对新 Master 的 Read 请求,也可以继续保留。 我们通过两台 MySQL Server 搭建成 Dual Master 环境,正常情况下,所有客户端的Write 请求都写往 Master A,然后通过 Replication 将 Master A 复制到 Master B。一旦 Master A 出现问题之后,所有的 Write 请求都转向 Master B。而在正常情况下,当Master B 出现问题的时候,实际上不论是数据库还是客户端的请求,都不会受到实质性的影响。 如上图所示,首先考虑 Slave 出现异常的情况。在这个架构中,Slave 出现异常后的处理情况和普通的 Master - Slave 架构的处理方式完全一样,仅仅需要在应用访问 Slave集群的访问配置中去掉一个 Slave 节点即可解决,不论是通过应用程序自己判断,还是通过硬件解决方案如 F5 都可以很容易的实现。 如果出现故障的不是 Master B 而是 Master A 又会怎样呢?首先可以确定的是我们的所有 Write 请求都不会受到任何影响,而且所有的 Read 请求也都还是能够正常访问。 下面我们从两个方面分别来介绍 MySQL Cluster 的高可靠性。

17.2.1 SQL 节点的高可靠性保证

MySQL Cluster 中的 SQL 节点实际上就是一个多节点的 mysqld 服务,并不包含任何数据。所以,SQL 节点集群就像其他任何普通的应用服务器一样,可替代性很高,只要安装了支持 MySQL Cluster 的 MySQL Server 端即可。 如上图,当 SQL 1 crash 之后,实际上仅仅只是访问到数据的很多条途径中的某一条中断了,实际上仍然还有很多条途径可以获取到所需要的数据。而且,由于 SQL 的可替代性很高,所以更换也非常简单,即使更换整台主机,也可以在短时间内完成。

17.2.2 NDB 节点的高可靠性保证

MySQL Cluster 的数据冗余是有一个前提条件的,首先必须要保证有足够的节点,实际上是至少需要2个节点才能保证数据有冗余,因为,MySQL Cluster 在保存冗余数据的时候,是比需要确保同一份数据的冗余存储在不同的节点之上。在保证了冗余的前提下,MySQL Cluster 才会将数据进行分区。 RaiDB-1:

MySQL性能调优与架构设计——第 17 章 高可用设计之思路及方案RaiDB-0-1:

MySQL性能调优与架构设计——第 17 章 高可用设计之思路及方案

原标题:MySQL性能调优与架构设计——第 17 章 高可用设计之思路及方案

关键词:MYSQL

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。