CN101183377B - 一种基于消息中间件的高可用性数据库集群*** - Google Patents
一种基于消息中间件的高可用性数据库集群*** Download PDFInfo
- Publication number
- CN101183377B CN101183377B CN2007101687213A CN200710168721A CN101183377B CN 101183377 B CN101183377 B CN 101183377B CN 2007101687213 A CN2007101687213 A CN 2007101687213A CN 200710168721 A CN200710168721 A CN 200710168721A CN 101183377 B CN101183377 B CN 101183377B
- Authority
- CN
- China
- Prior art keywords
- module
- database
- data
- message
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于消息中间件的高可用性数据库集群***,包括由多台数据库服务器构成的数据库服务层,在应用层和数据库服务层之间设置有中间层,中间层包括多个应用代理,多个数据库中间件及消息总线;应用代理用于服务节点出现故障时的连接重定向,保持服务不中断,提高可靠性;数据库中间件用于对数据库请求消息的拦截、解析、处理和转发;消息总线贯穿于数据库中间件和数据库服务器之间,它负责将数据中间件发送的读写操作进行全局排序,保证数据一致性,并将排序结果发送给数据库服务器。本发明为获得具有高可用性的高性能数据库提供了一条切实可行的途径,具有较高的可用性、良好的可扩展性、易于构建和管理的特点。
Description
技术领域
本发明涉及计算机数据库群集中间件技术领域,更具体地说,就是使用消息中间件技术来构建高可用性数据库集群。
背景技术
当前的一些热点应用如电子商务、火车票定购服务、电子银行等,通常在某个较短时间内,用户数量极大,查询的峰值达到每秒钟10万次以上,单个的服务器无论是从CPU的处理能力还是网络的物理带宽来说,都无法满足这么高的性能需求。同时,对于这些应用中,服务器的失效将对服务的提供者带来巨大的损失。在这一背景下,数据库集群技术的研究和发展成为学术界和工业界非常关注的问题。
当前,数据库集群产品主要分为共享存储结构和非共享结构。一般来讲,共享存储结构的数据库集群对存储设备要求较高,其数据库服务器存取数据的速度也快于非共享存储结构的数据库集群。然而,由于采用了专用存储设备,在提高***构造成本的同时,也降低了集群***的可扩展性。
采用非共享的集群结构,将数据存放在专门负责存储的子集群中,这类似于并行文件***,由于采用存储子集群结构,这类集群通常具有很高的可扩展性。但是,这类数据库集群大都是基于数据库引擎的,例如MySQLCluster就只能使用NDB(或称NDB Cluster)的存储引擎,而不能使用MyISAM、InnoDB等存储引擎,更不能与SQL Server或DB2等数据库服务器组成数据库集群;其次,***结构较为复杂,***开发和维护成本高。
同时在网络(特别是TCP连接级)容错方面,目前大部分数据库集群表现不佳。Oracle RAC虽然具有TCP连接容错能力,然而其技术是私有的。而本发明基于消息中间件的高可用性数据库集群就有效的解决了上述的所有问题。
发明内容
本发明的目的在于提供一种基于消息中间件的高可用性数据库集群***,该数据库集群***具有高可用性、高性能和可扩展性。
本发明提供的基于消息中间件的高可用性数据库集群***,包括由M台数据库服务器构成的数据库服务层,其特征在于:该***在应用层和数据库服务层之间设置有中间层,中间层包括N个应用代理,M个数据库中间件及消息总线,1≤N≤16,1≤M≤8;
应用代理用于服务节点出现故障时的连接重定向,保持服务不中断,提高可靠性;
数据库中间件用于对数据库请求消息的拦截、解析、处理和转发;
消息总线贯穿于数据库中间件和数据库服务器之间,它负责将数据库中间件发送的读写操作进行全局排序,保证数据一致性,并将排序结果发送给数据库服务器;
数据库中间件包括消息接收模块、MySQL消息解析模块、SQL语句解析模块、请求执行与结果处理模块、消息处理模块、故障检测模块、数据恢复模块、日志模块、组通信模块和并发控制模块;
消息接收模块用于监听端口信息,接收来自上层数据库请求,从已建立的MySQL连接池中选择空闲连接提供初始化、中断、SQL命令查询、删除、***、修改数据库服务,将接收到的消息处理后交由MySQL消息解析模块;
MySQL消息解析模块用于解析消息接收模块获得的MySQL消息,区分消息类型,解压分析得到SQL命令并发送给SQL语句解析模块进行后续处理;
SQL语句解析模块用于从MySQL消息解析模块获得MySQL消息中读、写命令,解析出命令的类型;如果是非写命令,直接转交请求执行与结果处理模块;如果是写命令,解析结果返回给消息处理模块;
请求执行与结果处理模块用于将本地节点的只读信息直接发送给数据库服务器执行,全局写命令发送给并发控制模块,比对分析执行结果并返回给应用代理;
消息处理模块负责***中的消息处理和转发,将处理后的信息通过组通信模块置于消息总线上,转发给其它数据节点;同时,接收经由组通信模块传递来的其它数据节点消息;包含写命令的组通信消息全局排序后,解析出MySQL消息传递给请求执行与结果处理模块执行;发送前和接收到结果后通过日志模块写更新日志和完成日志;获得故障消息时,调用故障检测模块分析处理;
故障检测模块利用消息处理模块获得的***组成员变更的信息,分析***故障,当由新节点加入或者故障节点恢复时调用数据恢复模块进行数据同步;
数据恢复模块利用日志模块提供的更新日志,分析新加入节点或待恢复节点与正常节点的数据差异,对数据进行同步处理,直至所有节点达到数据库一致;
日志模块用于定义数据恢复的更新日志、增量恢复脚本数据格式,为消息处理模块和数据恢复模块提供日志的访问接口;
组通信模块为消息处理模块和消息总线的接口;
并发控制模块根据请求执行与结果处理模块的结果,利用分布式锁表,控制更新事务在全局执行顺序的一致。
本发明的数据库集群***通过消息中间件在数据库服务器上构建一个数据库网关,分发数据库访问请求、比对执行结果,采用主动复制方案,组成了一个数据库集群。采用“读一写所有可用”的技术保证集群中各个节点的数据一致性,并提高了集群***整体的读性能。智能分析新加入节点或故障节点与正常节点的数据差异,选择全复制或者增量复制进行数据库恢复。本发明在当今最为流行的开源数据库MySQL上实现了一个具有高可用性、高性能和可扩展的数据库集群***。与现有的技术相比,本发明具有以下技术效果:
a.高可用性:即使一个或多个节点宕机,***可将用户的请求重定向到其它正常节点,保证服务可持续;新节点加入或者故障节点恢复,利用更新日志进行数据同步,保证***内所有节点数据一致。
b.高性能:采用“读一写所有可用”技术,用户的增、删、修改操作会在***中各个节点执行,本发明采用合适的并发控制技术保证写性能不明显降低;而读操作仅在本地节点执行,远程节点不执行,读操作并发度极大提高,性能上升。
c.可扩展性:***中任何一个节点都可提供数据库服务,增加一个节点,意味着可为更多的用户服务。***配置简单,数据同步技术可迅速的将新节点纳入***,可扩展性好。
d.透明性:当***出现故障时,利用消息中间件将故障节点迅速隔离,同时将它正在服务的用户请求重定向到其他可用节点,该过程对用户透明。
e.同等性:本发明的数据库集群***中,各个节点对等,无主从节点之分,***中仅两个节点时,相当于双机互备***;具体对某个SQL更新命令或事务,仅存在本地节点和远程节点之分,当都同时执行该命令或事务,而本地节点负责将结果返回给用户。
附图说明
图1为本发明高可用性数据库集群***的体系结构图;
图2为图1中应用代理的模块结构图;
图3为图1中应用代理的流程图;
图4为图1中数据库中间件的功能模块图;
图5为本发明高可用性数据库集群***的失效恢复示意图;
图6为本发明高可用性数据库集群***的恢复算法过程;
图7为本发明写操作在本地节点上的执行过程;
图8为本发明写操作在远程节点上的执行过程。
具体实施方式
本发明采用的技术思想如下:
a.建立应用代理,其作用在于连接重定向,是客户端的代理;
b.建立数据库中间件,采用“读一写所有可用”技术保证数据节点间的数据一致。同时满足数据节点的动态加入和离开,并维护节点的正常运行。
c.建立数据库服务层,使用MySQL服务器构建数据库服务层。
进一步,事务和单个发送后立即执行的SQL命令都以任务或请求统称之。对于只读请求,第一个接收的节点立即执行并返回结果;对于写请求任务,需要向所有其它节点转发执行,这就是“读一写所有”,或称“读一写多”协议。本发明在此协议基础上改进得到一种“读一写所有可用”的协议。这种方法中读操作与“读一写所有”模式一样处理:***任何可用节点的副本都可以读取,并在那个副本上获得读锁。写操作转发到所有副本上,同时需要获得所有副本的写锁。如果一个节点停机,更新任务则不在该节点上执行,而由***恢复模块在该节点重新加入***时恢复。
下面结合附图对本发明作进一步详细的说明。
如图1所示,本发明***通过在应用层和数据库服务层中间增加了中间层,实现数据库集群。
数据库服务层位于整个数据库集群底层,由若干个数据库服务器41、42、...4M构成。在本***中,各个节点使用的主要是MySQL服务器,不要求是相同版本的,也就是说,某些节点可以采用MySQL 5.0,而其他节点采用MySQL 5.1,另外对发行版本也没有严格要求,但是采用的MySQL服务器应支持InnoDB、MyISAM等存储引擎,数据访问端口为3306,建议使用二进制发行版mysql-max-5.0.*。
从图1中可以看到,中间层包括应用代理21、22、...2N,数据库中间件31、32、...、3M及消息总线,1≤N≤16,1≤M≤8。应用程序11、12、...1N都有一个相应的应用代理21、22、...2N,即有一个应用程序请求,就有个应用代理与之一一对应的关系。当应用程序与应用代理成功建立连接后,应用代理选取一个数据库中间件进行连接,多个应用代理可以对应一个数据库中间件。一个数据库服务器对应一个数据库中间件,MySQL服务进程、组通信进程和HAMC进程(数据库中间件的主进程)同时运行于服务器上,构成一个数据节点;而客户端的应用程序对应一个应用代理,同时运行于客户端上。
为表述方便,下文将应用程序11、12、...1N,应用代理21、22、...2N,数据库中间件31、32、...、3M和数据库服务器41、42、...4M分别统称为应用程序1,应用代理2,数据库中间件3和数据库服务器4。
数据库中间件3是数据库集群***的主体。作为一个中间件,数据库中间件充分体现了代理的思想。数据库中间件的主要作用是对数据库请求消息的拦截、解析、处理和转发,转发机制是本***技术的核心,它依赖于一个基于IP多播的消息中间件,在本***中,其作用犹如一个专门提供***成员通信的消息总线;而应用代理的作用在于服务节点出现故障时的连接重定向,保持服务不中断,提高可靠性。数据库中间件代理底层的数据库服务器向上层应用提供数据服务,本***中,如果要使用群集功能,应用程序访问***提供的访问端口,而不是MySQL服务的默认端口3306;如果使用3306端口访问数据库,则不会经过数据库中间件,实际上就是使用单机的数据库***,没有达到高可用性,各个节点间也不能实时数据同步。
消息总线贯穿于数据库中间件3和数据库服务器4之间,它负责将数据中间件3发送的读写操作进行全局排序,保证数据一致性,并将排序结果发送给数据库服务器4。
应用层:该层是上层数据库应用,可以是应用服务器,也可以是用户的数据操作。
如图2所示,从功能结构上,应用代理2划分为以下几个模块:请求连接管理器2A、执行模块2B和重定向模块2C,其中图中数据库中间件’的表示其它数据节点中的数据库中间件。图2中各个模块的主要功能有:
请求连接管理器2A:监听及接收应用层的数据连接请求,保存所有数据节点的MySQL ODBC数据源,构建MySQL连接池。如果应用程序1和请求连接管理器2A连接建立成功,交由执行模块2B处理应用程序的请求;如果应用程序1和请求连接管理器2A的连接中断,则由重定向模块2C进行处理。
执行模块2B用于发送执行MySQL请求给数据库中间件,检查返回结果和回送结果给应用程序1。执行模块通过***提供的访问端口来访问数据库中间件3。
重定向模块2C:当前提供服务的数据节点连接出现故障时,变更执行模块使用的MySQL连接,并将变更结果通知执行模块2B。
应用代理2的结构简单,流程图见图3。应用代理2开始运行后,就可以接受用户的请求,图中的接受数据库请求及选择合适连接由请求连接管理器2A实现,请求连接管理器2A根据节点的状态来决定由哪个数据节点来处理用户请求,同时建立应用代理2与数据库中间件3的连接。连接建立后,执行模块2B会向数据库中间件3发送执行。如果执行模块2B等待执行结果超时,重定向模块2C会根据当前数据节点们的状态重定向连接,即重新选择一个数据中间件来处理用户的请求。如果执行结果成功返回,执行模块会将执行结果返回给用户。
如图4所示,处于服务节点的数据库中间件3是数据库集群***的主体,模块结构比应用代理复杂。功能模块划分如下:消息接收模块3A、MySQL消息解析模块3B、SQL语句解析模块3C、请求执行与结果处理模块3D、消息处理模块3E、故障检测模块3F、数据恢复模块3G、日志模块3H、组通信模块3I和并发控制模块3J,其中图中数据库中间件’的表示其它数据节点中的数据库中间件。图3中的各个模块的主要功能:
(1)消息接收模块3A:监听***服务端口,接收来自上层数据库请求,从已建立的MySQL连接池中选择空闲连接提供初始化、中断、SQL命令查询、删除、***、修改等数据库服务,将接收到的消息处理后交由MySQL消息解析模块3B;
(2)MySQL消息解析模块3B:解析消息接收模块获得的MySQL消息,区分消息类型,解压分析得到SQL命令并发送给SQL语句解析模块3C进行后续处理;
(3)SQL语句解析模块3C:从MySQL消息解析模块3B获得MySQL消息中读、写命令,解析出命令的类型(select、create、update、insert、delete等)、操作对象(数据库名、表名等)。如果是非写命令,直接转交请求执行与结果处理模块3D;如果是写命令(create、update、insert、delete等),解析结果返回给消息处理模块3E;
(4)请求执行与结果处理模块3D:该模块是一个单独的线程。本地节点的只读信息直接发送给数据库服务器4执行,全局写命令(包括本地节点和远程节点的写命令)发送给并发控制模块3J,比对分析执行结果并返回给应用代理的执行模块2B;
(5)消息处理模块3E:负责***中的消息处理和转发,是核心模块。MySQL消息被解析完成后,如果是写命令,则本模块将消息socket、本地节点ID、事务标示、写命令类型(create、update、insert、delete)标示、数据操作对象(数据库名、表名)、请求锁类型等信息附于MySQL消息之前,组成新的消息,通过组通信模块3I置于消息总线上,转发给其它数据节点;同时,接收经由组通信模块3I传递来的其它数据节点消息。包含写命令的组通信消息全局排序后,解析出MySQL消息传递给请求执行与结果处理模块执行;发送前和接收到结果后通过日志模块写更新日志和完成日志。获得故障消息时,调用故障检测模块分析处理;
(6)故障检测模块3F:利用消息处理模块3E获得的***组成员变更的信息(最先来自组通信模块3I),分析***故障,当由新节点加入或者故障节点恢复时调用数据恢复模块3G进行数据同步,;
(7)数据恢复模块3G:利用***的更新日志和完成日志,分析新加入节点或待恢复节点与正常节点的数据差异,根据差异程度选择全复制或增量复制策略进行数据同步直至所有节点达到数据库一致;
(8)日志模块3H:定义数据恢复的更新日志(update.log)、完成日志(commit.log)、增量恢复脚本(patch.sql)数据格式,为消息处理模块3E和数据恢复模块3G提供日志的访问接口,该模块是数据恢复的基础;
(9)组通信模块3I:消息处理模块和消息总线的接口,***中是一个单独的线程,完成组通信消息的有序转发和接收,也是***中极为重要的组成模块;
(10)并发控制模块3J:根据请求执行与结果处理模块3D的结果,利用分布式锁表,控制更新事务在全局执行顺序的一致,从而保证事务并发执行可串行化,各个节点数据库一致。
图5(a)清晰的说明了正常情况下,即各个数据节点(包括中间层和数据库服务层)正常运行时的***结构;但是,当出现网络中断、***宕机等故障时,***结构有所不同,如图5(b)所示。
假如因某种故障导致应用代理2到数据库中间件3、数据库中间件3到数据库服务器4的连接出现问题,也就是数据库服务器4不能再提供数据库服务时,应用代理2重新选择***中数据节点并建立连接,重定向后再将未完成的数据库请求发送至新的数据节点以获得不间断的数据库服务。图5表示的仅是应用代理22不能访问数据库服务器42时的情况,将数据库服务器42换作其它节点,处理故障和重定向算法不变。
导致数据库服务器42不能正常访问的故障可能有:数据库服务器42上MySQL服务进程、组通信进程或HAMC进程(数据库中间件运行的主进程)异常,网络问题导致消息总线与数据库服务器42通信中断、应用代理22到数据库服务器42的连接中断等。这类故障同样存在于***中的其他数据节点,本部分故障情况下的体系结构仅是以数据库服务器42为例具体说明之。
如图6所示,这是本发明的恢复算法过程。其中,update.log为更新日志,记录客户端的更新请求;commit.log为完成日志,记录成功执行的更新操作;state.log为状态日志,记录节点的工作状态;patch.sql为增量恢复脚本。更新日志和完成日志的每一项都由一个任务编号标识,任务编号是全局分配的唯一任务标示符,依次递增。
本发明***有两种类型的恢复技术:增量恢复和全复制恢复。恢复功能重点在于检测服务节点的加入和离开以及网络故障,运行时记录数据修改,恢复时比较故障节点正常节点的差异,当差异程度较小时利用增量恢复技术进行数据同步,而差异较大时进行全复制恢复保证***中节点的数据一致性。下面详细地介绍这两种恢复技术的实现步骤。
当数据服务节点运行时间很久后,数据库文件大小达到几GB,某个节点偶然出现故障离开***,但是时间不长,与其它正常节点的差异不大,这时采用增量恢复较为适宜。恢复步骤如下:
(1)待恢复节点读取完成日志,分析得到最后执行完成的任务编号Tj。
(2)将分析得到的任务编号发送给选举出来的正常节点。
(3)正常节点分析它的完成日志,获得上开始恢复时执行完成的任务编号Ti。
(4)如果Ti-Tj值为0,则转(7)执行;如果值大于0,则转(5)执行;如果值小于0,则显示***错误,待恢复节点不加入***,跳出恢复过程等待管理员处理。
(5)正常节点打开它的更新日志,将任务Tj至Ti的SQL命令解析出来,存于增量恢复脚本中。
(6)正常节点将增量恢复脚本传输给待恢复节点,待恢复节点执行增量恢复脚本完成数据同步。
(7)显示完成增量恢复。
MySQL提供了良好的数据传输功能,可以利用MySQL的数据库拷贝将整个数据库传输到新加入的节点。传输整个数据库采用的方式不是直接传输数据库文件,而是构建一个全复制脚本,然后在待恢复节点执行达到数据传输的目的,正常节点上脚本构建过程如下:
(1)写入创建数据库命令;
(2)切换数据访问用户;
(3)写入删除正常节点数据库中存在表的命令;
(4)申请写锁,根据正常节点中数据表名和格式创建新表;
(5)严格按照正常节点中表的数据写***命令。
(6)多个表,则重复执行第(4)步至第(5)步的操作。
(7)释放锁。
以上述步骤构建全复制脚本完毕后,将脚本文件发送至待恢复节点执行就可以将其恢复到与其它正常节点一致的状态。
全复制恢复主要依赖于正常节点的数据库状态,只要恢复过程中没有新的写操作,待恢复节点完成数据传输后,其状态一定与正常节点一致。而恢复进程已经获得所有节点数据库所有表的读锁,应用程序只能对数据库进行读访问,而写操作被阻塞,因此恢复过程中没有写操作的条件完全可以保证。
本文规定,第一个接收到某个更新任务的节点成为本地节点,***中通过消息总线转发获得该更新任务的节点称为远程节点。本地节点和远程节点是对某一个具体的更新任务而言的。对于本地节点而言,更新任务Ti节点是本地任务,而对于远程节点,它则是远程任务。
“读一写所有可用”协议中,读任务仅在接收节点执行即可;而写任务在本地节点和远程节点的执行流程是不同的。在本地节点,写任务执行步骤如下:接收请求、多播发送消息、多播接收消息、请求锁、执行任务,如图7所示。而在远程节点,过程仅有3步:接收请求、请求锁、执行任务,如图8所示。值得注意的是,本地执行写任务时,有两次请求(消息)的接收,但是发送者不同,第一次接收的请求来自应用程序或应用代理,经处理后交由消息总线转发给其它节点,第二次接收的消息来自消息总线,此时请求消息是经过全局排序后消息中间件转发的。
在上述流程中,接收请求、发送消息、接收消息属于***的消息控制部分,而请求锁、发送执行属于***的并发控制部分。另外,结合MySQL采用的是多版本数据库,为提高并发读,***采用的“读一写所有可用”协议中,读操作不上锁,仅写操作上锁。
本发明的***是一个分布式的环境,采用严格的两阶段封锁协议,但是还必须保证各个节点对事务授予锁和释放锁的顺序必须是完全一致的。***采用索引和链表的形式实现锁表,各数据节点按照相同的规则为每一个进入***的事务(或立即提交执行的单个SQL命令)分配唯一的事务编号,按相同顺序授予锁;收到事务在所有节点执行完毕的消息释放锁。锁表采用一个数据项名哈希值为索引的散列表在链表中查找数据项。
本发明的***中,给数据项加锁的方式主要有两种:
共享锁:如果事务获得了数据项的共享锁,则事务可读当不能写数据项;
排它锁:如果事务获得了数据项的排它锁,则事务可读亦可写数据项;
每个事务都要根据将对数据项进行的操作类型申请适当的锁。该请求发送给并发控制模块,只有在并发控制模块授予所需锁之后,事务才能继续其操作。
本发明构建了一个全局的锁表来实现并发控制,锁表由两部分组成:锁表项和锁表节点链表。锁表项保存了项和指向锁表节点链表的头指针,其中项保存了申请锁的对象(表或者行);锁表节点链表由一个个锁表节点链接而成,同一个锁表链表中的所有锁表节点都对同一个数据对象进行操作,锁表节点保存了申请锁的类型和指向下个锁表节点的指针。
进一步,本发明的并发控制算法如下:
假如***中新接收一个更新事务T,则
(1)读取更新事务T将更新的对象表或行,并将对象哈希转换为锁表项中的项;
(2)查找锁表,如果某个锁表项中的项等于该项,以事务T构建锁表节点置于锁表项指向的锁表链表后面;否则,新建一个锁表项(L),将该项添加进L中,并将事务T构建的新的锁表节点置于L指向的锁表链表后面;
(3)如果更新事务T的锁表节点处于对应锁表链表的第一个,那么直接授予锁;否则,读取前驱节点的事务申请的锁类型,根据相容矩阵表判断相容性,相容则授予锁,如果不相容则等待前驱节点的事务执行完毕释放锁再授予更新事务T请求锁。
Claims (5)
1.一种基于消息中间件的高可用性数据库集群***,包括由M台数据库服务器(4)构成的数据库服务层,其特征在于:该***在应用层和数据库服务层(4)之间设置有中间层,中间层包括N个应用代理(2),M个数据库中间件(3)及消息总线,1≤N≤16,1≤M≤8;
应用代理(2)用于服务节点出现故障时的连接重定向,保持服务不中断,提高可靠性;
数据库中间件(3)用于对数据库请求消息的拦截、解析、处理和转发;
消息总线贯穿于数据库中间件(3)和数据库服务器(4)之间,它负责将数据库中间件(3)发送的读写操作进行全局排序,保证数据一致性,并将排序结果发送给数据库服务器(4);
数据库中间件(3)包括消息接收模块(3A)、MySQL消息解析模块(3B)、SQL语句解析模块(3C)、请求执行与结果处理模块(3D)、消息处理模块(3E)、故障检测模块(3F)、数据恢复模块(3G)、日志模块(3H)、组通信模块(3I)和并发控制模块(3J);
消息接收模块(3A)用于监听端口信息,接收来自上层数据库请求,从已建立的MySQL连接池中选择空闲连接提供初始化、中断、SQL命令查询、删除、***、修改数据库服务,将接收到的消息处理后交由MySQL消息解析模块(3B);
MySQL消息解析模块(3B)用于解析消息接收模块获得的MySQL消息,区分消息类型,解压分析得到SQL命令并发送给SQL语句解析模块(3C)进行后续处理;
SQL语句解析模块(3C)用于从MySQL消息解析模块(3B)获得MySQL消息中读、写命令,解析出命令的类型;如果是非写命令,直接转交请求执行与结果处理模块(3D);如果是写命令,解析结果返回给消息处理模块(3E);
请求执行与结果处理模块(3D)用于将本地节点的只读信息直接发送给数据库服务器(4)执行,全局写命令发送给并发控制模块(3J),比对分析执行结果并返回给应用代理(2);
消息处理模块(3E)负责***中的消息处理和转发,将处理后的信息通过组通信模块(3I)置于消息总线上,转发给其它数据节点;同时,接收经由组通信模块(3I)传递来的其它数据节点消息;包含写命令的组通信消息全局排序后,解析出MySQL消息传递给请求执行与结果处理模块(3D)执行;发送前和接收到结果后通过日志模块(3H)写更新日志和完成日志;获得故障消息时,调用故障检测模块(3F)分析处理;
故障检测模块(3F)利用消息处理模块(3E)获得的***组成员变更的信息,分析***故障,当由新节点加入或者故障节点恢复时调用数据恢复模块(3G)进行数据同步;
数据恢复模块(3G)利用日志模块(3H)提供的更新日志,分析新加入节点或待恢复节点与正常节点的数据差异,对数据进行同步处理,直至所有节点达到数据库一致;
日志模块(3H)用于定义数据恢复的更新日志、增量恢复脚本数据格式,为消息处理模块(3E)和数据恢复模块(3G)提供日志的访问接口;
组通信模块(3I)为消息处理模块和消息总线的接口;
并发控制模块(3J)根据请求执行与结果处理模块(3D)的结果,利用分布式锁表,控制更新事务在全局执行顺序的一致。
2.根据权利要求1所述的高可用性数据库集群***,其特征在于:应用代理(2)包括请求连接管理器(2A)、执行模块(2B)和重定向模块(2C);
请求连接管理器(2A)用于监听及接收应用层的数据连接请求,保存所有数据节点的MySQL ODBC数据源,构建MySQL连接池;如果应用程序和请求连接管理器(2A)连接建立成功,将应用程序的请求发送给执行模块(2B);否则将连接出错信息发送给重定向模块(2C);
执行模块(2B)用于发送执行MySQL请求给数据库中间件(3),检查返回结果,并将回送结果发送给应用程序,它还接收数据库中间件(3)提供的端口信息;
重定向模块(2C)用于在当前提供服务的数据节点连接出现故障时,变更执行模块(2B)使用的MySQL连接,并将变更结果通知执行模块(2B)。
3.根据权利要求1所述的高可用性数据库集群***,其特征在于:数据恢复模块(3G)按照下述步骤进行增量数据恢复:
①待恢复节点读取完成日志,分析得到最后执行完成的任务编号Tj;
②将分析得到的任务编号发送给选举出来的正常节点;
③正常节点分析它的完成日志,获得开始恢复时执行完成的任务编号Ti;
④如果Ti-Tj值为0,则转步骤⑦执行;如果值大于0,则转步骤⑤执行;如果值小于0,则显示***错误,待恢复节点不加入***,跳出恢复过程等待管理员处理;
⑤正常节点打开它的更新日志,将任务Tj至Ti的SQL命令解析出来,存于增量恢复脚本中;
⑥正常节点将增量恢复脚本传输给待恢复节点,待恢复节点执行脚本完成数据同步;
⑦显示完成增量恢复。
4.根据权利要求1所述的高可用性数据库集群***,其特征在于:数据恢复模块(3G)按照下述步骤进行全复制数据恢复:
①写入创建数据库命令;
②切换数据访问用户;
③写入删除正常节点数据库中存在表的命令;
④申请写锁,根据正常节点中数据表名和格式创建新表;
⑤严格按照正常节点中表的数据写***命令;
⑥多个表,则重复执行第④步至第⑤步的操作;
⑦释放锁。
5.根据权利要求1所述的高可用性数据库集群***,其特征在于:并发控制模块(3J)按照下述步骤进行处理:
①当***中新接收一个更新事务时,读取更新事务将要更新的对象表或行,并将对象哈希转换为锁表项中的项;
②查找锁表,如果某个锁表项等于上述项,以上述更新事务构建锁表节点置于该锁表项指向的锁表链表后面;否则,新建一个锁表项,将上述项添加进新建的锁表项中,并将上述更新事务构建的新锁表节点置于新建的锁表项指向的锁表链表后面;
③如果更新事务的锁表节点处于对应锁表链表的第一个,那么直接授予锁;否则,读取前驱节点的事务申请的锁类型,根据相容矩阵表判断相容性,相容则授予锁,如果不相容则等待前驱节点的事务执行完毕释放锁再授予更新事务请求锁。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101687213A CN101183377B (zh) | 2007-12-10 | 2007-12-10 | 一种基于消息中间件的高可用性数据库集群*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101687213A CN101183377B (zh) | 2007-12-10 | 2007-12-10 | 一种基于消息中间件的高可用性数据库集群*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101183377A CN101183377A (zh) | 2008-05-21 |
CN101183377B true CN101183377B (zh) | 2010-09-08 |
Family
ID=39448655
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101687213A Expired - Fee Related CN101183377B (zh) | 2007-12-10 | 2007-12-10 | 一种基于消息中间件的高可用性数据库集群*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101183377B (zh) |
Families Citing this family (77)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102299904B (zh) * | 2010-06-23 | 2014-03-19 | 阿里巴巴集团控股有限公司 | 一种实现业务数据备份的***及方法 |
CN102467508A (zh) * | 2010-11-04 | 2012-05-23 | 中兴通讯股份有限公司 | 提供数据库服务的方法及数据库*** |
CN102141946B (zh) * | 2011-03-25 | 2014-08-20 | 北京世纪互联宽带数据中心有限公司 | 一种图形数据库联机事务数据恢复的方法及*** |
CN102841895B (zh) * | 2011-06-22 | 2015-06-24 | 阿里巴巴集团控股有限公司 | 一种处理数据库状态转移的方法和*** |
CN102262680B (zh) * | 2011-08-18 | 2013-08-21 | 北京新媒传信科技有限公司 | 一种基于海量数据存取需求的分布式数据库代理*** |
GB2496377B (en) | 2011-11-02 | 2014-07-30 | Ibm | Message reconciliation during disaster recovery |
CN103092712B (zh) * | 2011-11-04 | 2016-03-30 | 阿里巴巴集团控股有限公司 | 一种任务中断恢复方法和设备 |
CN102402616B (zh) * | 2011-12-22 | 2015-01-14 | 北京新媒传信科技有限公司 | 一种数据库集群的实现方法和*** |
CN102609463B (zh) * | 2012-01-13 | 2014-08-20 | 广东电网公司电力科学研究院 | 一种基于准实时平台的数据集群管理*** |
CN103368754B (zh) * | 2012-03-26 | 2018-04-10 | 中兴通讯股份有限公司 | 一种检测业务故障的方法、装置和***及设备 |
CN103051681B (zh) * | 2012-12-06 | 2015-06-17 | 华中科技大学 | 一种面向分布式文件***的协作式日志*** |
CN103198159B (zh) * | 2013-04-27 | 2016-01-06 | 国家计算机网络与信息安全管理中心 | 一种基于事务重做的异构集群多副本一致性维护方法 |
CN103281363A (zh) * | 2013-05-17 | 2013-09-04 | 浪潮集团有限公司 | 一种路灯云*** |
CN103294807B (zh) * | 2013-05-31 | 2017-03-01 | 重庆大学 | 一种基于多层级关系的分布式数据管理方法 |
CN103294479A (zh) * | 2013-06-19 | 2013-09-11 | 成都市欧冠信息技术有限责任公司 | 分布式事务处理方法与*** |
CN103345502B (zh) * | 2013-07-01 | 2017-04-26 | 曙光信息产业(北京)有限公司 | 分布式数据库的事务处理方法和*** |
CN104579905B (zh) * | 2013-10-15 | 2018-11-06 | 阿里巴巴集团控股有限公司 | 消息传递方法和***及mom服务器、接收端 |
CN103607376B (zh) * | 2013-10-29 | 2017-01-11 | 北京奇虎科技有限公司 | 一种兼容协议的方法及装置 |
CN103744896A (zh) * | 2013-12-24 | 2014-04-23 | 乐视网信息技术(北京)股份有限公司 | 一种数据处理方法和装置 |
CN104751257A (zh) * | 2013-12-25 | 2015-07-01 | 携程计算机技术(上海)有限公司 | 酒店数据的管理*** |
CN105376289A (zh) * | 2014-09-01 | 2016-03-02 | 重庆好吃狗云计算科技有限公司 | 一种无损快速恢复数据和***运行的方法 |
CN105681156B (zh) * | 2014-11-19 | 2019-06-11 | 阿里巴巴集团控股有限公司 | 消息发布方法、装置及*** |
US9824134B2 (en) * | 2014-11-25 | 2017-11-21 | Sap Se | Database system with transaction control block index |
CN104539713B (zh) * | 2014-12-31 | 2018-10-09 | 北京奇虎科技有限公司 | 业务请求处理方法和装置 |
KR102103063B1 (ko) * | 2015-04-01 | 2020-05-29 | 아브 이니티오 테크놀로지 엘엘시 | 분산 컴퓨팅 시스템에서 데이터베이스 트랜잭션들을 프로세싱하는 방법 |
CN106503001B (zh) * | 2015-09-03 | 2019-11-12 | 菜鸟智能物流控股有限公司 | 分布式集群环境中的数据更新方法及装置 |
CN105389371A (zh) * | 2015-11-16 | 2016-03-09 | 天津南大通用数据技术股份有限公司 | 一种数据库集群建立连接高可用的方法和*** |
CN105447121A (zh) * | 2015-11-16 | 2016-03-30 | 天津南大通用数据技术股份有限公司 | 一种数据库集群重建连接高可用的方法 |
CN105786998B (zh) * | 2016-02-19 | 2019-02-26 | 创元网络技术股份有限公司 | 数据库中间件***及利用其处理数据的方法 |
CN107180034A (zh) * | 2016-03-09 | 2017-09-19 | 精硕科技(北京)股份有限公司 | MySQL数据库的集群*** |
CN105933408B (zh) * | 2016-04-20 | 2019-08-13 | ***股份有限公司 | 一种Redis通用中间件的实现方法及装置 |
CN105933407B (zh) * | 2016-04-20 | 2019-12-06 | ***股份有限公司 | 一种实现Redis集群高可用的方法及*** |
CN105975481B (zh) * | 2016-04-22 | 2019-11-01 | 浪潮(北京)电子信息产业有限公司 | 一种减小rac节点间gc请求的方法及装置 |
CN107665219B (zh) * | 2016-07-28 | 2021-01-29 | 华为技术有限公司 | 一种日志管理方法及装置 |
US11120036B2 (en) * | 2016-08-03 | 2021-09-14 | Oracle International Corporation | System and method for efficient repurposing of connections in a multi-tenant database environment |
CN106354747B (zh) * | 2016-08-15 | 2019-08-16 | 成都轻车快马网络科技有限公司 | 用于大数据的服务提供方法 |
CN106412011A (zh) * | 2016-08-30 | 2017-02-15 | 广州鼎甲计算机科技有限公司 | 一种多节点间无共享存储的高可用集群***和实现 |
CN106357452B (zh) * | 2016-09-29 | 2019-06-04 | 上海和付信息技术有限公司 | 一种单点异构数据存储的高可用框架***及其实现方法 |
CN106874341B (zh) * | 2016-12-23 | 2022-04-05 | 中科星图股份有限公司 | 一种数据库同步方法 |
CN107092529B (zh) * | 2017-02-10 | 2021-01-01 | 北京星选科技有限公司 | Olap服务方法、装置及*** |
CN107294828B (zh) * | 2017-06-15 | 2020-06-26 | 广州天源信息科技股份有限公司 | 跨区域分布式站点交互与数据同步方法 |
CN109426552A (zh) * | 2017-09-05 | 2019-03-05 | 阿里巴巴集团控股有限公司 | 事务处理方法、装置和***以及电子设备 |
CN107943870A (zh) * | 2017-11-10 | 2018-04-20 | 顺丰科技有限公司 | 用于提高分布式数据库中间件稳定性的方法及其设备 |
CN107943868B (zh) * | 2017-11-10 | 2021-12-24 | 顺丰科技有限公司 | 支持***信息友好查看的数据库中间件的方法及设备 |
CN108153838B (zh) * | 2017-12-15 | 2022-03-11 | 山东中维世纪科技股份有限公司 | 一种MySQL数据库中间件预处理方法 |
CN108255621A (zh) * | 2018-01-10 | 2018-07-06 | 深圳友门鹿网络科技有限公司 | 一种基于binlog的MySQL增量消息解析方法 |
CN108279988B (zh) * | 2018-01-25 | 2021-07-23 | 微梦创科网络科技(中国)有限公司 | 一种基于Lua脚本语言的消息处理方法及*** |
CN108984318B (zh) * | 2018-06-22 | 2022-06-07 | 广州唯品会信息科技有限公司 | 基于驱动模型的消息投递方法、装置及可读存储介质 |
CN110874371B (zh) * | 2018-08-31 | 2023-06-02 | 杭州海康威视数字技术股份有限公司 | 一种数据分析***、方法及装置 |
CN109522361A (zh) * | 2018-09-27 | 2019-03-26 | 中国经济信息社有限公司 | 一种利用消息总线进行数据库实时同步的方法及*** |
CN109271452B (zh) * | 2018-10-19 | 2021-04-13 | 武汉达梦数据库有限公司 | Db2数据库数据同步更新方法及设备 |
CN109669821B (zh) * | 2018-11-16 | 2022-04-05 | 深圳证券交易所 | 消息中间件的集群部分故障恢复方法、服务器及存储介质 |
CN109460437B (zh) * | 2018-11-19 | 2021-05-28 | 南京苏宁易付宝网络科技有限公司 | 一种分布式环境下事件处理方法及处理*** |
CN109933412B (zh) * | 2019-01-28 | 2021-02-23 | 武汉慧联无限科技有限公司 | 基于分布式消息中间件的分布式事务处理方法 |
CN109951261B (zh) * | 2019-03-20 | 2021-09-28 | 江苏满运软件科技有限公司 | 中间件消息传输补偿方法、装置、电子设备、存储介质 |
CN111813786B (zh) * | 2019-04-12 | 2024-06-11 | 阿里巴巴集团控股有限公司 | 缺陷检测/处理方法和装置 |
CN110162428A (zh) * | 2019-05-17 | 2019-08-23 | 中国铁道科学研究院集团有限公司 | 数据同步方法及装置、电子设备和计算机可读存储介质 |
CN110134737B (zh) * | 2019-05-20 | 2021-02-26 | 中国铁道科学研究院集团有限公司 | 数据变化监听方法及装置、电子设备和计算机可读存储介质 |
CN110134704B (zh) * | 2019-05-31 | 2021-11-02 | 厦门大学嘉庚学院 | 一种基于分布式缓存的大数据集群事务实现方法 |
CN110569142A (zh) * | 2019-08-29 | 2019-12-13 | 天津大学 | 一种oracle数据增量同步***及方法 |
CN110704207B (zh) * | 2019-09-11 | 2021-04-27 | 口碑(上海)信息技术有限公司 | 业务应用中间件的数据处理方法及装置、存储介质 |
CN112541006B (zh) * | 2019-09-23 | 2023-01-06 | 拉扎斯网络科技(上海)有限公司 | 数据库命令请求处理方法、装置、电子设备及存储介质 |
CN110602136B (zh) * | 2019-09-25 | 2021-09-14 | 华为技术有限公司 | 集群访问方法和相关产品 |
CN110807064B (zh) * | 2019-10-28 | 2022-08-26 | 北京优炫软件股份有限公司 | Rac分布式数据库集群***中的数据恢复装置 |
CN110909076B (zh) * | 2019-10-31 | 2023-05-23 | 北京浪潮数据技术有限公司 | 一种存储集群数据同步方法、装置、设备及存储介质 |
CN110909079B (zh) * | 2019-11-20 | 2020-09-01 | 南方电网数字电网研究院有限公司 | 数据交换同步方法、***、装置、服务器和存储介质 |
CN111061749B (zh) * | 2019-12-12 | 2024-02-23 | 山东大学 | 基于事务顺序分析的数据库事务并发重做方法和装置 |
CN111127088B (zh) * | 2019-12-17 | 2023-06-27 | 深圳前海环融联易信息科技服务有限公司 | 实现最终一致性的方法、装置、计算机设备及存储介质 |
CN111405015B (zh) * | 2020-03-09 | 2022-09-30 | 中国建设银行股份有限公司 | 一种数据处理方法、装置、设备及存储介质 |
CN111552637B (zh) * | 2020-04-20 | 2023-05-19 | 北京顺达同行科技有限公司 | 数据库状态的检测方法、装置、电子设备及其存储介质 |
CN111786956B (zh) * | 2020-06-05 | 2022-04-19 | 四川省东宇信息技术有限责任公司 | 基于消息中间件通信安全接入内网网络的***及方法 |
CN112487097A (zh) * | 2020-12-11 | 2021-03-12 | 杭州安恒信息技术股份有限公司 | 一种分布式领域数据同步的方法、***及设备 |
CN112486780A (zh) * | 2020-12-17 | 2021-03-12 | 中职物联(湖北)信息科技有限公司 | 一种基于消息中间件的数据库性能实时监控和诊断方法和*** |
CN113064869B (zh) * | 2021-03-23 | 2023-06-13 | 网易(杭州)网络有限公司 | 日志处理方法、装置、发送端、接收端设备及存储介质 |
CN113032421A (zh) * | 2021-04-29 | 2021-06-25 | 电子科技大学 | 基于MongoDB的分布式事务处理***及方法 |
CN113946628A (zh) * | 2021-10-27 | 2022-01-18 | 中国建设银行股份有限公司 | 一种基于***的数据同步方法及装置 |
CN114785749B (zh) * | 2022-04-14 | 2024-07-16 | 北京京东拓先科技有限公司 | 一种消息群发处理方法和装置 |
-
2007
- 2007-12-10 CN CN2007101687213A patent/CN101183377B/zh not_active Expired - Fee Related
Non-Patent Citations (1)
Title |
---|
金海、邹德清、韩宗芬.基于Web的网格***的实现.小型微型计算机***24 12.2003,24(12),2053-2056. * |
Also Published As
Publication number | Publication date |
---|---|
CN101183377A (zh) | 2008-05-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101183377B (zh) | 一种基于消息中间件的高可用性数据库集群*** | |
US9251163B2 (en) | File sharing system and file sharing method | |
US9286368B2 (en) | Linking framework for information technology management | |
US20110161281A1 (en) | Distributed Transaction Management in a Distributed Shared Disk Cluster Environment | |
US8504523B2 (en) | Database management system | |
Kemme et al. | Database replication: a tale of research across communities | |
EP2342655B1 (en) | Quorum based transactionally consistent membership management in distributed storage systems | |
US20060195487A1 (en) | Systems and Methods for Managing the Synchronization of Replicated Version-Managed Databases | |
CN102640151A (zh) | 信息***中转换后的数据的高吞吐量、可靠复制 | |
US20060123098A1 (en) | Multi-system auto-failure web-based system with dynamic session recovery | |
KR100450400B1 (ko) | 안전 기억 장치가 없는 환경을 위한 이중화 구조의 주 메모리 상주 데이터베이스 관리시스템 및 그 데이터 일치성 제어방법 | |
EP3722973B1 (en) | Data processing method and device for distributed database, storage medium, and electronic device | |
US20160142249A1 (en) | Method, medium, and system for configuring a new node in a distributed memory network | |
CN102033912A (zh) | 一种分布式数据库访问方法及*** | |
WO2018164772A1 (en) | Aggregate, index based, synchronization of node contents | |
KR20040074627A (ko) | 복제 명령 분배 시스템 및 방법 | |
CN105354328A (zh) | 一种解决NoSQL数据库并发访问冲突的***及方法 | |
KR100521742B1 (ko) | 엑스엠엘 문서의 구조 및 속성 정보의 손실 없이 엑스엠엘문서를 원격 서버로 복제하는 엑스엠엘 데이터베이스이중화 장치 및 그 방법 | |
JP2024026143A (ja) | 最終的に一貫性のあるデータベース複製への切り替え | |
JP5331050B2 (ja) | データ同期システム、データ同期方法、情報処理装置、情報処理方法、およびプログラム | |
Won et al. | Moving metadata from ad hoc files to database tables for robust, highly available, and scalable HDFS | |
EP2502415A2 (en) | Record operation mode setting | |
KR102598619B1 (ko) | 데이터베이스 관리 서비스 제공 시스템 | |
US11360866B2 (en) | Updating stateful system in server cluster | |
CN110069448A (zh) | 一种录像索引方法及录像索引*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C17 | Cessation of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20100908 Termination date: 20121210 |