MySQL Cluster体系结构概述.docx

上传人:b****7 文档编号:10173293 上传时间:2023-02-09 格式:DOCX 页数:12 大小:170.04KB
下载 相关 举报
MySQL Cluster体系结构概述.docx_第1页
第1页 / 共12页
MySQL Cluster体系结构概述.docx_第2页
第2页 / 共12页
MySQL Cluster体系结构概述.docx_第3页
第3页 / 共12页
MySQL Cluster体系结构概述.docx_第4页
第4页 / 共12页
MySQL Cluster体系结构概述.docx_第5页
第5页 / 共12页
点击查看更多>>
下载资源
资源描述

MySQL Cluster体系结构概述.docx

《MySQL Cluster体系结构概述.docx》由会员分享,可在线阅读,更多相关《MySQL Cluster体系结构概述.docx(12页珍藏版)》请在冰豆网上搜索。

MySQL Cluster体系结构概述.docx

MySQLCluster体系结构概述

MySQLCluster体系结构概述

MySQLCluster的高可用特性

 

目录

1前言1

2引入MySQL1

3高可用性系统架构2

4系统配置示例2

5同步复制3

6故障检测3

通信中断4

心跳故障4

网络分区4

确定故障顺序5

7节点恢复5

单节点恢复5

多节点恢复5

8系统恢复6

局部检查点6

全局检查点6

系统恢复6

复制和分区透明6

9故障案例6

10MySQL服务器节点故障7

存储节点故障7

管理服务器节点崩溃7

连接失败7

磁盘故障7

11结论7

关于MySQL8

 

1前言

这篇文献是介绍MySQLCluster的高可用性和可靠性,MySQL是一个内存集群的分布式数据库管理系统。

该系统建立在一个无共享体系结构上,包括了故障转移,节点恢复,数据同步和无单点故障等高级特性。

此文献描述了一个不同的应用场景,系统架构和使用方法,用于提供高可用性能。

2引入MySQL

MySQLCluster通过使用无单节点故障的分布式节点结构来得以达到高达99.999%的可用率。

该系统包括了多个分布于各设备和区域的节点,保证了持续可用,以防节点和网络故障。

MySQLCluster使用一种由一系列存储节点组成的存储引擎,这些存储节点可以存储那些使用标准的SQL访问MySQL服务器的获得的数据。

MySQLCluster包括三种节点(如图1):

图1:

节点系统

1.存储节点(SN)式系统的主要节点。

所有数据可以被存储在存储节点上。

数据在存储节点之间进行复制传递,以防止在在一个或者多个节点出现故障的情况下数据依然可用。

存储节点能够处理所有数据。

2.管理服务器节点(MSN)处理系统的配置和用于改变该系统的安装。

通常只有一个管理服务器节点被使用,但也有可能运行几个。

管理服务器节点仅用于在启动和系统重新配置,这意味着存储节点是可操作的,而不管理节点。

3.MySQL服务器节点是用于服务器访问集群的存储节点。

MySQL服务器为开发者提供一个标准的SQL接口和MySQL服务器依次处理请求发送到存储节点省去了在应用程序中低层次的编程。

一个MySQL集群中的MySQL服务器是与所有存储节点相联系的,并且,一个MySQL集群会有多个MySQL服务器。

在MySQLl服务器上执行的所有操作被一组共同的节点处理。

这就意味着,一旦一个操作在MySQL服务器上被执行了,执行结果在所有与MySQL集群相联系的MySQL服务器上都可见。

3高可用性系统架构

MySQL集群的节点结构经过精心设计,以实现高可用性:

MySQL服务器连接到所有集群存储节点。

如果某个存储节点出现故障,那么MySQL服务器可以很容易地使用任何其他存储节点来执行交易。

存储节点的数据被复制到多个存储节点。

如果一个存储节点出现故障,则总是有另一个存储节点中存储的信息相同。

管理服务器节点可以被停止并重新启动,而不会影响正在进行的执行存储节点。

管理服务器节点只用来配置信息发送到数据库和MySQL服务器节点,并且当存储节点启动并运行,管理服务器可以停止或禁止。

存储和MySQL服务器节点开始运行时需要管理服务器节点,因为他们首先连接到管理服务器,以获得MySQL集群的配置。

在设计系统以这种方式使系统可靠和高度可用的,因为没有单点故障。

在整体中任何节点都可以在不影响系统被杀死。

例如,应用程序可以继续执行,即使存储节点已关闭。

下面即将描述几种其他用于增加数据库的可靠性和可用性的技术和算法,包括:

数据可以在所有存储节点之间的同步复制。

这导致在遇到节点故障的情况下能够快速进行节点切换;

节点在多个主机上执行,使得MySQL集群甚至在出现硬件故障时仍然可操作;

节点使用的是无共享架构设计。

每个存储节点都有自己的磁盘和内存存储(在同一台计算机上运行多个存储节点时,还有共享磁盘和内存的选项。

);

没有单点故障。

任何节点都可以被停止而没有任何数据丢失,且无需使用数据库停止应用程序。

应用程序使用MySQL服务器连接到MySQLCluster,该服务器为应用程序提供:

数据独立。

这意味着应用程序可以被写入数据,而不需要知道其物理存储知识。

数据存储在一个存储引擎中,该存储引擎能处理所有的底层细节,如数据复制和自动故障切换。

网络和分布的透明性。

这意味着该应用程序既不依赖于网络的操作细节也不依赖于数据在存储节点上的分布。

复制和分区的透明性。

这意味着应用程序可以以相同的方式被写入,无论数据是否被复制,都和数据是如何分配相独立。

一个标准的SQL接口。

这使得开发人员和数据库应用无需任何底层编程而实现高可用性。

这些功能有可能使MySQL集群在发生故障时动态地重新配置,无需在应用程序中

定制编码。

4系统配置示例

MySQL簇也是高度可配置的,因此可以分别配置MySQL集群以满足您的特定需求。

可以改变计算机运行的数量,存储节点的数量,应用程序数量,存储节点如何分配到计算机等等。

一个配置示例(如图2),我们假设有四个存储节点SN1…SN4,运行在四台电脑上C1,……,C4。

我们想在其他俩台电脑,C5和C6,上运行俩个MySQL服务器,如M1和M2。

一个服务器管理节点MGN1运行在计算机C5上。

图2:

配置示例

所有的数据库表被水平分割成若干分区,其存储在所述存储节点中。

为了引入冗余数据,让我们使用两个系统副本(该系统可以通过配置获得1—4个系统副本)。

这意味着,在两个副本存在所有数据。

在上面的配置示例,存储节点SN1和SN2将存储在同一分区,SN3和SN4也是存储在统一分区。

集合{SN1,SN2}和{SN3,SN4}被称为节点组。

节点组是负责存储在系统中的一部分数据。

如果在一个节点组的所有节点出现故障,其文件系统会被清除,那么她们所在的分区(数据)也会丢失。

在我们的例子中每个节点组中配置有两个节点,以便在有一个节点发生故障的情况下另外一个作为备份节点。

5同步复制

在数据库中的所有数据都复制在同一个节点组的所有存储节点中的几个存储节点。

当数据库管理员启动MySQL集群时,副本的数量已经被决定了。

它可以从1个(无复制)被设置为4个。

数据是交换过程中同步复制的,即每次交换的结果在交换过程中传送到所有合适的存储节点。

当该操作将被提交时,发送一个请求到正在参与交换的所有存储节点。

当所有节点回应他们已经准备好,交换就被执行同时应用程序被告知数据交换成功。

数据的同步复制意味着,如果一个节点发生故障,则故障转移时间应该小于另一个节点接受时间,否则所有的数据已经被复制了。

为了确保数据库始终保持一致,如果一个存储节点的数据交换过程中出现故障,该交换被终止,同时通知应用程序,以便它在适当的时候可以重新启动操作。

6故障检测

有两种方法检测到故障节点:

通信中断和心跳故障。

这两种情况下,都会有信号发送到所有存储节点,并且网络分割协议用以确定是否有足够的节点剩余使MySQL集群能够继续运行。

请注意,如果某些节点被报告为故障,它实际上可能因为集群中的俩个部分已失去所有联系。

在这种情况下,我们不能让这俩个部分同时存在,因为这可能会导致数据库不一致。

MySQL集群确保应用程序可连续使用网络分区协议,可以自动选择集群中的一个组成部分继续运行。

在集群的其他部分的所有节点会自动重新启动并作为新的节点连接到集群。

通信中断

MySQL集群节点通过不同的通信协议连接。

目前,TCP,,OSE和内存共享都可以被MySQL集群实现和使用.通常情况下,所有存储节点之间是相互联接的并且每一个应用节点和所有存储节点想连接。

(除了共享存储器中的节点连接,这些连接可以用于连接驻留在不同的计算机上的节点。

)如果一个存储节点发现俩个节点之间的连接丢失,则所有其他存储节点都会被通知到,并且会共同将此节点认定为故障节点。

故障节点会自动重新启动并作为一种新的节点连接到MySOL集群,而该应用程序不受影响。

通信中断是检测一个节点出现故障的最快方法。

心跳故障

有些故障节点不能够被通信中断方法检测到,例如磁盘问题,内存问题,以及处理器疲惫。

这些故障导致一个节点不能正常工作,但不破坏节点连接到MySOL集群的其余部分。

心跳协议是用来检测这种故障。

存储节点被组织成一个逻辑循环(图3)。

每个存储节点发送心跳信号给循环中的下一个存储节点。

如果一个存储节点无法发送连续三次无法发送心跳信号,那么下一个存储节点将存储节点定性为发生故障。

故障节点被报告给所有存储节点,共同判定为故障节点。

图3:

心跳协议

网络分区

每当有节点出现故障,其余节点通过网络分区协议检查这些故障节点是否在节点组中只有一个或者可用节点超过了一半。

这确保数据传输能够不经过这些节点,或者只让这些节点承担部分传输工作。

为了说明如果没有网络分割协议的实施会发生什么,再考虑有四个存储节点的配置示例。

假设{SN1,SN3}和{SN2,SN4}之间所有的连接都丢失了。

由于两个节点组存储各自所有数据,每一组可以访问整个数据库。

如果两组被允许同时存在,然后每组可以更新不同的信息,从而导致我们有两个不一致的数据库。

网络分割协议解决了在多个节点组存在时确定唯一的一组为主导节点组的难题。

在特定的情况下,如果俩个存储节点组正好各占是节点中一半,这时,网络分割协议作为仲裁员投出了额外的一票。

任何管理服务器或应用程序节点可以被配置为仲裁者。

如果几个节点都配置为仲裁员,然后他们轮流作为权威仲裁人。

存储节点自动跟踪当前权威仲裁员,如果权威仲裁员被杀死,一个新的权威仲裁员将由存储节点自动分配。

对于示例配置,MGM1,M1和M2都可以被配置为仲裁员并且作为权威仲裁员要么会支持节点组{SN1,SN3}要么会制裁节点组{SN2,SN4},前提是至少有一组仍连接到权威仲裁员。

MySQL集群是自动管理的,所以不需要额外的编码或管理。

确定故障顺序

在特殊的情况下,当多个节点出现故障,两阶段提交故障判定协议被用来确定在该节点出现故障先后顺序,以确保他们可以安全地重新启动。

该协议分为两个步骤执行。

首先,所有的节点发送的所有他们认为已经出现故障的节点的列表到主存储节点。

(在很多的MySQL集群的协议有一个专门的主节点,万一主服务器失败,这个主存储节点立即任命。

)然后,主存储节点确定并告知所有节点出现故障的节点的先后顺序。

7节点恢复

如果有一些存储节点出现故障,他们自动启动节点恢复协议,该协议提供从完好的节点中获得重新启动的代码和数据。

单节点恢复

单节点恢复是如果一个存储节点发生故障,则该节点会从一个备份节点获得(即属于同一节点组作为故障节点的节点)应该给保存的分区数据并重新启动。

备份节点依次发送各个分区数据给正在重新启动的节点。

重启节点启动完成后就会立即准备为数据传送服务。

如果依次操作时读取一个分区中的数据,则它会被自动引导作为该分区的主要节点,即主要负责该分区。

由于这个节点是重启的,不是主要节点所以不需要考虑这些请求。

如果这个操作是要更新复制在该节点里的数据,那么这才是标准的步骤,即,即,首先更新主分区数据,然后备份分区。

如果该操作是要更新尚未转移到起始节点的分区,那么只能在主节点处得到更新,因为该分区将被转移到重新启动的节点。

由于只需要待更新一个待更新的信息,这实际上可能使数据库工作更快相比于当节点恢复,启动和再次运行。

多节点恢复

如果多个节点需要被恢复,可通过故障判定协议所确定的顺序来确他们应该被恢复的顺序。

主节点指示一个节点的同时恢复一个节点,单个节点恢复是一样的方式。

8系统恢复

系统恢复在系统出现故障以后恢复整个系统的过程。

在正常操作时,将日志记录在存储所有数据库操作(插入,删除,更新等)的磁盘中。

该日志为每个存储节点在文件系统上进行存储,并且仅用于在发生系统故障,也就是说,如果所有的存储节点同时出现故障的时候。

由于该日志包含所有的数据库操作,在系统恢复过程中,它是用来恢复历史最新的数据库数据。

局部检查点

由于日志随着操作次数的增长而增长,局部检查点协议来删除陈旧的日志。

本地检查点算法创建一个包含所有节点瞬间状态的数据复制操作并存储在磁盘上。

加载该快照后应用日志获取数据库保持最新状态。

加载此最新数据使数据库保持最新状态。

全局检查点

由于MySQL集群是一个主内存数据库,事务都将首先提交到主内存中。

只要所有节点组中还存在完好节点,复制就会使得数据变得安全。

为了从系统故障(当所有节点出现故障)恢复,MySQL集群日志刷新到磁盘中的全局检查点,有时也被称为组提交。

全局检查点被刷新后,所有的操作也提交到磁盘。

要控制操作的提交状态,MySQL集群分配一个全局性的检查点标识每个提交的操作。

全局检查点标识了各全局检查点所属的操作,可用于区别已经提交到磁盘的各操作。

例如,如果全球检查点15结束,那么与GCI所有小于于或等于15的操作结果已被保存到磁盘。

系统恢复

系统恢复分两步处理。

首先将局部检查点所获得的瞬时数据从磁盘加载到每个存储节点。

然后从磁盘读取日志并在每个存储节点上执行,以使数据库保持最新。

系统恢复将恢复所有操作,全局检查点标识小于或等于最近完成的全局性的检查点。

这将确保所有操作使用过的直到最近期的全球检查点被安全回收。

复制和分区透明

当应用程序要执行一个新的操作时,MySQL集群使用一个存储节点来执行。

如果存储节点发生故障,操作将自动发送到另一个存储节点。

一个循环算法自动选择一个用于操作的存储节点。

9故障案例

让我们来考虑各种故障,以及MySQL集群是如何处理它们的。

10MySQL服务器节点故障

如果MySQL服务器崩溃,它可以重新启动,并重新连接到MySQL集群。

在重新启动MySQL服务器后可以连接到任何存储节点。

在这个服务器关闭的时,MySQL集群的其他MySQL服务器可提供相同的数据库服务。

存储节点故障

如果一个存储节点崩溃,那么所有其他存储节点要么通过丢失节点之间的通信要么通过遗失心跳这两种方式来了解这个信息。

因为数据通常是复制的,总是存在可用的另一个存储节点提供服务的操作请求。

管理服务器节点崩溃

由于存储器和MySQL服务器节点是不依赖于管理服务器进行它们的执行操作的,所以管理服务器可能会发生故障,并重新启动任意次数,而不会影响正在运行的MySQL集群。

连接失败

如果存储节点之间的连接被破坏,节点获取有关故障的存储节点的信息。

连接丢失作为与节点故障相同的机制来进行处理。

首先,两阶段节点故障的协议被用来确定哪些节点是无法访问的,然后MySQL集群的改变可能出现的节点连接。

这些连接有一个故障转移系统来处理通信故障。

使用这个系统,TCP/IP连接有故障时延时约100毫秒,可伸缩相干接口连接有大约100微秒的故障切换时间。

连接故障转移系统有效地隐藏PCI卡的问题,电缆问题,以及通过其它连接发送消息来转换故障。

磁盘故障

所有存储节点存储其自己的数据。

如果一个节点检测到它的文件系统已被破坏,它就停止执行。

文件系统已被清除后,该节点使用节点恢复协议重新启动。

11结论

MySQL集群是采用了独特的无共享架构和标准的SQL接口,构建高可用性数据库。

我们已经介绍MySQL集群的高可用性功能了后也介绍了一些技术落。

MySQL集群容纳的多个存储节点故障和重新配置本身就快速掩盖了故障。

自愈能力,以及从应用程序数据分布和分区的透明度,形成了一个简单的编程模型,使数据库开发人员能够在应用中容易包含高可用性能无需进行复杂的低层次的编码。

关于MySQL

MySQLAB公司开发和销售一系列高性能,经济实惠的的数据库服务器和工具。

该公司的旗舰产品是MySQL,拥有超过500万活跃装置是世界上最流行的开源数据库。

许多世界上最大的组织,包括雅虎,Sabre控股公司,CoxCommunications公司,美联社和美国航空航天局,都使用MySQL来支持Web站点,业务关键型企业应用程序和打包软件实现,显著节约成本。

MySQLAB公司是第二代开源公司,该公司有着支持开源价值和方法论的盈利以及可持续发展的商业双重许可。

有关MySQL的更多信息,请访问。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 职业教育 > 职高对口

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1