CN101183377A - 一种基于消息中间件的高可用性数据库集群 - Google Patents

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上实现了一个具有高可用性、高性能和可扩展的数据库集群系统。与现有的技术相比，本发明具有以下技术效果：

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)释放锁。

以上述步骤构建全复制脚本完毕后，将脚本文件发送至待恢复节点执行就可以将其恢复到与其它正常节点一致的状态。

全复制恢复主要依赖于正常节点的数据库状态，只要恢复过程中没有新的写操作，待恢复节点完成数据传输后，其状态一定与正常节点一致。而恢复进程已经获得所有节点数据库所有表的读锁，应用程序只能对数据库进行读访问，而写操作被阻塞，因此恢复过程中没有写操作的条件完全可以保证。

本文规定，第一个接收到某个更新任务的节点成为本地节点，系统中通过消息总线转发获得该更新任务的节点称为远程节点。本地节点和远程节点是对某一个具体的更新任务而言的。对于本地节点而言，更新任务T_i节点是本地任务，而对于远程节点，它则是远程任务。

“读一写所有可用”协议中，读任务仅在接收节点执行即可；而写任务在本地节点和远程节点的执行流程是不同的。在本地节点，写任务执行步骤如下：接收请求、多播发送消息、多播接收消息、请求锁、执行任务，如图7所示。而在远程节点，过程仅有3步：接收请求、请求锁、执行任务，如图8所示。值得注意的是，本地执行写任务时，有两次请求(消息)的接收，但是发送者不同，第一次接收的请求来自应用程序或应用代理，经处理后交由消息总线转发给其它节点，第二次接收的消息来自消息总线，此时请求消息是经过全局排序后消息中间件转发的。

在上述流程中，接收请求、发送消息、接收消息属于系统的消息控制部分，而请求锁、发送执行属于系统的并发控制部分。另外，结合MySQL采用的是多版本数据库，为提高并发读，系统采用的“读一写所有可用”协议中，读操作不上锁，仅写操作上锁。

本发明的系统是一个分布式的环境，采用严格的两阶段封锁协议，但是还必须保证各个节点对事务授予锁和释放锁的顺序必须是完全一致的。系统采用索引和链表的形式实现锁表，各数据节点按照相同的规则为每一个进入系统的事务(或立即提交执行的单个SQL命令)分配唯一的事务编号，按相同顺序授予锁；收到事务在所有节点执行完毕的消息释放锁。锁表采用一个数据项名哈希值为索引的散列表在链表中查找数据项。

本发明的系统中，给数据项加锁的方式主要有两种：

共享锁：如果事务获得了数据项的共享锁，则事务可读当不能写数据项；

排它锁：如果事务获得了数据项的排它锁，则事务可读亦可写数据项；

每个事务都要根据将对数据项进行的操作类型申请适当的锁。该请求发送给并发控制模块，只有在并发控制模块授予所需锁之后，事务才能继续其操作。

本发明构建了一个全局的锁表来实现并发控制，锁表由两部分组成：锁表项和锁表节点链表。锁表项保存了项和指向锁表节点链表的头指针，其中项保存了申请锁的对象(表或者行)；锁表节点链表由一个个锁表节点链接而成，同一个锁表链表中的所有锁表节点都对同一个数据对象进行操作，锁表节点保存了申请锁的类型和指向下个锁表节点的指针。

进一步，本发明的并发控制算法如下：

假如系统中新接收一个更新事务T，则

(1)读取更新事务T将更新的对象表或行，并将对象哈希转换为锁表项中的项；

(2)查找锁表，如果某个锁表项中的项等于该项，以事务T构建锁表节点置于锁表项指向的锁表链表后面；否则，新建一个锁表项(L)，将该项添加进L中，并将事务T构建的新的锁表节点置于L指向的锁表链表后面；

(3)如果更新事务T的锁表节点处于对应锁表链表的第一个，那么直接授予锁；否则，读取前驱节点的事务申请的锁类型，根据相容矩阵表判断相容性，相容则授予锁，如果不相容则等待前驱节点的事务执行完毕释放锁再授予更新事务T请求锁。

Claims (6)

1.一种基于消息中间件的高可用性数据库集群，包括由M台数据库服务器(4)构成的数据库服务层，其特征在于：该系统在应用层和数据库服务层(4)之间设置有中间层，中间层包括N个应用代理(2)，M个数据库中间件(3)及消息总线，1≤N≤16，1≤M≤8；

应用代理(2)用于服务节点出现故障时的连接重定向，保持服务不中断，提高可靠性；

数据库中间件(3)用于对数据库请求消息的拦截、解析、处理和转发；

消息总线贯穿于数据库中间件(3)和数据库服务器(4)之间，它负责将数据中间件(3)发送的读写操作进行全局排序，保证数据一致性，并将排序结果发送给数据库服务器(4)。

2.根据权利要求1所述的高可用性数据库集群，其特征在于：应用代理(2)包括请求连接管理器(2A)、执行模块(2B)和重定向模块(2C)；

请求连接管理器(2A)用于监听及接收应用层的数据连接请求，保存所有数据节点的MySQL ODBC数据源，构建MySQL连接池；如果应用程序和请求连接管理器(2A)连接建立成功，将应用程序的请求发送给执行模块(2B)；否则将连接出错信息发送给重定向模块(2C)；

执行模块(2B)用于发送执行MySQL请求给数据库中间件(3)，检查返回结果，并将回送结果发送给应用程序，它还接收数据库中间件(3)提供的端口信息；

重定向模块(2C)用于在当前提供服务的数据节点连接出现故障时，变更执行模块(2B)使用的MySQL连接，并将变更结果通知执行模块(2B)。

3.根据权利要求1或2所述的高可用性数据库集群，其特征在于：数据库中间件(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)的结果，利用分布式锁表，控制更新事务在全局执行顺序的一致。

4.根据权利要求3所述的高可用性数据库集群，其特征在于：数据恢复模块(3G)按照下述步骤进行增量数据恢复：

①待恢复节点读取完成日志，分析得到最后执行完成的任务编号Tj；

②将分析得到的任务编号发送给选举出来的正常节点；

③正常节点分析它的完成日志，获得上开始恢复时执行完成的任务编号Ti；

④如果Ti-Tj值为0，则转步骤⑦执行；如果值大于0，则转步骤⑤执行；如果值小于0，则显示系统错误，待恢复节点不加入系统，跳出恢复过程等待管理员处理；

⑤正常节点打开它的更新日志，将任务Tj至Ti的SQL命令解析出来，存于增量恢复脚本中；

⑥正常节点将增量恢复脚本传输给待恢复节点，待恢复节点执行脚本完成数据同步；

⑦显示完成增量恢复。

5.根据权利要求3所述的高可用性数据库集群，其特征在于：数据恢复模块(3G)按照下述步骤进行全复制数据恢复：

①写入创建数据库命令；

②切换数据访问用户；

③写入删除正常节点数据库中存在表的命令；

④申请写锁，根据正常节点中数据表名和格式创建新表；

⑤严格按照正常节点中表的数据写插入命令；

⑥多个表，则重复执行第④步至第⑤步的操作；

⑦释放锁。

6.根据权利要求3所述的高可用性数据库集群，其特征在于：并发控制模块(3J)按照下述步骤进行处理：

①当系统中新接收一个更新事务时，读取更新事务将更新的对象表或行，并将对象哈希转换为锁表项中的项；

②查找锁表，如果某个锁表项等于上述项，以上述更新事务构建锁表节点置于该锁表项指向的锁表链表后面；否则，新建一个锁表项，将上述项添加进新建的锁表项中，并将上述更新事务构建的新锁表节点置于新建的锁表项指向的锁表链表后面；

③如果更新事务的锁表节点处于对应锁表链表的第一个，那么直接授予锁；否则，读取前驱节点的事务申请的锁类型，根据相容矩阵表判断相容性，相容则授予锁，如果不相容则等待前驱节点的事务执行完毕释放锁再授予更新事务请求锁。

Images