CN103559188B - 元数据管理方法及管理系统 - Google Patents

Abstract

本发明提供了一种高可用性的元数据管理方法，包括步骤：在需要对元数据进行操作时，同时在至少两个元数据库上执行相同的元数据操作指令；其特征在于，当其中至少一个元数据库上的操作完成时，则判定元数据操作成功。本发明还提供了一种高可用性的元数据管理系统。本发明有效避免了数据同步问题和单一主服务器的效率瓶颈问题。

Description

元数据管理方法及管理系统

技术领域

本发明涉及一种元数据管理方法及管理系统。

背景技术

元数据是对数据资源的描述，英文名称是“Metadata”，通常被解释为data about data，即关于数据的数据。元数据是信息共享和交换的基础和前提，用于描述数据集的内容、质量、表示方式、空间参考、管理方式以及数据集的其他特征。

随着信息技术不断发展，以及人们对信息共享的迫切需求，元数据技术被应用于更多的领域，如：在图书馆与信息界，元数据被定为提供关于信息资源或数据的一种结构化的数据，是对信息资源的结构化的描述；在数据仓库领域中，元数据被定义为描述数据及其环境的数据；在软件构造领域，元数据被定义为在程序中不是被加工的对象，而是通过其值的改变来改变程序的行为的数据。

元数据往往是一个系统的基础数据，在系统运行过程中，需要实时访问元数据，以便对当前操作作出决策。元数据对整体服务有着十分关键的作用，其效率和容错性直接关系到整个系统的访问性能和可用性，因此元数据的高可用技术具有重要意义。

过去对元数据服务的可用性保证大都采用日志技术，而日志技术由于其自身的局限性，并不能很好地为元数据服务提供有力保障。逐步发展起集中式的元数据管理，即由一个单独的节点服务器管理全部的元数据，具有控制简单， 设计，实现难度小等优点。但是，其缺点也是致命的：元数据库是单一失效点。

针对这种情况，出现了一种双元服务器的高可用系统。现在一般的双元数据库系统，一般为主从服务器，即主服务器，从服务器之间用内部网络连接，组成活动/备用节点集群模型。这种模型可以使主元数据库在节点失效的情况下，使从服务器接替主服务器的工作，达到不中断服务，实现高可用的连续服务。

但是，这种服务模型在主节点失效时，需要通过基于日志和内存的同步方式，以及从服务器的非对称服务结构达到高可用。如果从服务器还未完成同步也失效，将导致数据丢失这种严重的错误。并且，主从模式只能有一个提供服务，主服务器的效率将是瓶颈。

发明内容

本发明针对上述问题，提出了一种高可用性的元数据管理方法及管理系统，其有效避免了数据同步问题和单一主服务器的效率瓶颈问题。

在一个方面，本发明提供了一种元数据管理方法，包括步骤：

在需要对元数据进行操作时，同时在至少两个元数据库上执行相同的元数据操作指令；

其特征在于，当其中至少一个元数据库上的操作完成时，则判定元数据操作成功。

在另一个方面，本发明提供了一种元数据管理系统，其特征在于，包括，

元数据操作单元，用于在需要对元数据进行操作时，同时在至少两个元数据库上执行相同的元数据操作指令；和

操作成功判断单元，用于当其中至少一个元数据库上的操作完成时，判定元数据操作成功。

本发明采用了元数据双写模式，有效避免了数据同步中发生错误的问题，并且两个元数据地位是相等的，解决了单一主服务器的效率瓶颈问题。

附图说明

下面将参照附图描述本发明的具体实施例，其中：

图1是本发明一个应用场景中的元数据管理系统的示意图；

图2是本发明的元数据库管理方法的操作流程图；

图3是本发明的元数据库管理系统的示意图；

图4是本发明的元数据库的5种状态的相互关系示意图；

图5是本发明的元数据库的状态转换流程图；

图6是本发明的元数据库租赁线程的流程图；并且

图7是本发明的元数据库续租线程的流程图。

具体实施方式

为了使本发明的技术方案及优点更加清楚明白，以下结合附图对本发明的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本发明的一部分实施例，而不是所有实施例的穷举。

如图1所示，在这个场景中，具有两个元数据库103和104，它们在整个网络中处于同等的地位。这两个元数据库103和104通过路由器102与业务服务器101连接。该业务服务器101中运行着数量不定的服务进程，该业务服务器101将使用本地文件系统创建一些共享内存空间做交换数据之用。

本领域技术人员很容易理解到，尽管图1中仅示出了一个业务服务器，但实际上并不限于一个业务服务器，可以是多个业务服务器连接至这两个元数据库103和104。同样地，尽管图1中示出了两个元数据库103和104，但实际上并不限于两个，也可以是更多个元数据库。在本说明书中，具体的数量仅是举例。

这两个元数据库103和104在系统运行中，将采用双写模式向业务服务器101提供服务。双写模式在这里意思是，当需要对元数据进行操作时，需要对 两个元数据库103和104同时操作。而且，只要有其中一个的操作完成，就认为元数据操作成功。如果有一个元数据库操作失败，需要将当前元数据操作指令保存到操作成功的元数据库中，待操作失败的元数据库恢复有效后，再执行需要恢复的元数据操作指令，然后该元数据库可继续提供服务。具体地，若其中某个元数据库(比如103)失效，另外一个元数据库(比如104)将继续提供服务，并保存失效元数据库103需要恢复的元数据操作指令，待失效元数据库103恢复有效后，再执行需要恢复的元数据操作指令，然后元数据库103可继续提供服务。

本发明提供了一种元数据库管理方法，如图2所示，其包括如下步骤：

在步骤S101，当需要对元数据进行操作时，在两个元数据库上同时执行修改元数据的操作。

然后，在步骤S102，判断两个元数据库是否均修改成功。如果均修改成功，则返回修改元数据成功(S1021)，流程结束。如果并未都修改成功，则继续在步骤S103，判断两个元数据库是否均修改失败。如果均修改失败，则返回修改元数据失败(S1031)，流程结束。如果也并未都修改失败，也就是说，一个元数据库修改成功，而另一个元数据库修改失败，则流程转到步骤S104。

在步骤S104，在业务服务器的本地文件系统中将操作失败的元数据库设置为不可用状态，以免继续向其发出修改指令。接着，在步骤S105中，在操作成功的元数据库中记录该操作失败的数据库上尚未执行的修改操作指令，以便后续再次执行。

接着，在步骤S106中，判断上述记录是否成功。如果未记录成功，则将需要记录的操作失败的元数据库的修改操作指令记录在本地文件系统中(S1061)，以便后续再次执行。在本地文件系统中的记录操作可采用独占锁的方式记录。在记录成功(不管是在成功元数据库中记录，还是在本地文件系统中记录)后，则返回修改元数据成功(步骤S107)，流程结束。

基于同一发明构思，本发明提供了一种元数据管理系统200，如图3所示， 其包括：元数据操作单元201，用于在需要对元数据进行操作时，同时在至少两个元数据库103和104上执行相同的元数据操作指令；和操作成功判断单元202，用于当其中至少一个元数据库(比如104)上的操作完成时，判定元数据操作成功。

元数据管理系统200还可包括：操作恢复单元203，用于在有元数据库(比如103)操作失败时，将元数据操作指令保存到操作成功的元数据库(比如104)中，待该操作失败的元数据库(比如103)恢复后再执行元数据操作指令。操作恢复单元203还可用于在保存失败时将操作指令保存到发出操作指令的业务服务器101的本地文件系统中。操作恢复单元203还可用于在操作失败的元数据库(比如103)的恢复中，由租赁该元数据库(比如103)成功的业务进程对该元数据库(比如103)进行恢复操作。元数据库的恢复和租赁将在后面详细描述。

为了确保操作成功，元数据库应具有如下5种状态，这5种状态的相互关系如图4所示：

1、不可用状态：元元数据库的网络不通，业务服务器不能连接到该元数据库。

2、需要恢复状态：元数据库可以连接，但是，需要执行完恢复命令。

3、正在恢复状态：元数据库正在执行恢复命令，正在恢复。

4、完成恢复状态：元数据库现有恢复命令已经执行完成。但是，需要再次确认在恢复完成时是否有新的命令需要恢复。如果有新的命令需要恢复，则进入需要恢复状态。如果无新的命令需要恢复，则进入可用状态。

5、可用状态：元数据库已经完成了恢复操作，可以提供服务。

当业务服务器需要操作元数据库时，首先，应该确定是否有一个元数据库处于可用状态。只要某一个元数据库是可用状态时，就能进行元数据的操作，否则，只能先试图恢复其中一个元数据库为可用状态。

元数据库的以上各个状态之间的相互转换流程如图5所示。

首先，在步骤S201，判断本元数据库是否连接成功。如果连接不成功，则返回本元数据库为不可用状态(S2011)，结束。如果连接成功，则在本地文件中查看本元数据库的状态(S202)，判断是否为可用状态(S203)。

如果处于可用状态，则返回本元数据库为可用状态(S2031)，结束。如果处于不可用状态，则连接另一元数据库。

在步骤204，判断另一元数据库是否连接成功。如果连接不成功，则将本元数据库设置为需要恢复状态(S2041)，结束。如果连接成功，则将本元数据库设置为正在恢复状态(S205)。

接着，在步骤S206，执行另一元数据库或本地文件系统上的对本元数据库的恢复命令。

然后，在步骤S207，判断恢复命令是否执行成功。如果执行不成功，返回到步骤S204。如果执行成功，则接着在步骤S208，将本元数据库设置为完成恢复状态。

然后，在步骤S209，确认本元数据库是否有需要恢复的命令。如果还有需要恢复的命令，返回到步骤S204。如果没有需要恢复的命令，则流程进行到步骤S210，将本元数据库设置为可用状态。

最后，在步骤S211，如果接收到其他进程的状态更改通知，则按照通知更改成相应的状态(通常更改成不可用状态)，结束。

在系统实际运行中，可能会出现各种运行错误，因此容错是必须解决的问题。本发明的解决方案提供了完善的容错机制。

常见的典型错误包括：其中一个元数据库不可用；在修改元数据时两个元数据库相继不可用；业务进程退出。容错处理的流程可参见图2所示的元数据库双写模式的操作流程。

下面将针对上述各种情况详细说明本发明的容错处理机制。

(1)其中一个元数据库不可用

当系统在运行时，如果其中某个元数据库不可用时，将会被业务服务器上 的各个业务进程实时检测到，此时该元数据库将被设置为不可用状态。如果当前没有修改元数据的操作，元数据库变为不可用，直接进入到元数据库状态转换流程即可。如果当前正在修改元数据，需要先将该元数据库修改元数据的操作保存到另一台可用的元数据库中，再进入元数据库状态转换流程。

(2)修改元数据时两个元数据库相继不可用

如上所述，当修改元数据时，如果某个元数据库不可用，需要将修改元数据的操作保存到另一台可用的元数据库中。但是，如果该可用的元数据库突然变得不可用，那么需要保存的元数据修改操作将会保存失败。此时，需要将修改元数据的操作保存到本地文件系统。

(3)业务进程退出

当业务进程在运行过程中，终止运行。此时，需要恢复的元数据操作已经记录到本地文件系统或元数据库中。如果还没有将需要恢复的元数据操作保存该业务进程就终止运行，将会发生丢失数据的严重错误。因此，用户不能随意将业务进程强制终止，除非用户很清楚将发生什么情况。不过，其他的业务进程将继续工作，不会受到影响。

如上所述，在本发明中，业务进程可能有多个，它们都能连接到这两个元数据库。如果某个元数据库需要恢复，它们都能探测到该信息，并且都会试图去恢复该元数据库。但是，如果多个进程都同时恢复一个元数据库，将会导致冲突。因此，需要有一种机制去保证它们的互斥性。为此，本发明采用了元数据库租赁机制。也就是，只有成功租赁到某个元数据库的业务进程，才有权对该元数据库进行恢复操作。

下面，详细描述元数据库的租赁机制。

元数据库的租赁机制，需要两个线程合作完成，分别是元数据库租赁线程和元数据库续租线程，这两个线程的流程图分别如图6和7示。

图6示出了元数据库的租赁机制。首先，在步骤S301，连接到元数据库查看该元数据库的租赁到期时间，判断是否已到期。若已到期，则设置该元数据 库的新的租赁到期时间，通常为当前时间之后的某一时间，并将租赁者设置为本进程标识。上述操作必须在一个原子操作内完成。

随后，在步骤S302，判断上述租赁操作是否成功。若不成功，则结束。若租赁成功，则进行到步骤S303，通知续租线程保持续租。

接着，在步骤S304，获取并执行全部恢复操作。这个恢复操作的过程可能会比较长。

在恢复过程结束(S305)后，通知续租线程续租结束(S306)。恢复操作全部执行成功或某个操作命令执行失败，均将导致整个恢复操作过程结束。

图7示出了元数据库的续租机制。首先，在步骤S401接收到续租开始命令后，在步骤402确认是否收到续租结束命令。如果接收到续租结束命令，则返回到步骤S401。如果未接收到续租结束命令，则在步骤S403检查是否已经到达续租启动时刻(续租启动时刻指的是应该启动续租操作的时刻，比如租赁时间已过去一定比例，比如4/5)，如果已经到达，则修改元数据库的续租信息，将租赁到期时间延长(S404)，如果未到达，则返回到步骤S402。

举例来说，初始时，某一元数据库还没有被租赁，那么其“租赁到期时间”和“租赁者”为空。比如，后续某一时刻，该元数据库被租赁，租赁时长为20秒，则设置“租赁到期时间”和“租赁者”，租赁到期时间为当前时刻加上20秒(T+20)。此后，如果有新的租赁请求则将被拒绝。在设定的续租启动时刻，比如离租赁到期时间还差20*1/5＝4秒，即T+16秒时，延长租赁时间，继续租赁20秒。在T+36秒时刻，租赁时间结束，清空“租赁到期时间”和“租赁者”。此后，该元数据库可响应于新的租赁请求。

很显然，上述仅是举例，续租启动时刻并不限制于到达租赁到期时间的4/5，租赁时间也不限于20秒，而是可以根据实际情况灵活设置。

如上所述，本发明提供了一种高可用性的元数据库管理方法及管理系统，解决了现在方案存在的几个问题。

(1)有效避免了数据同步问题。在主从式元数据库模式中，需要将主服 务器的数据同步到从服务器中，这种方式在同步过程中容易发生错误。而且，同步过程中，不能提供服务。本发明提供的解决方案避免了这个问题。

(2)有效避免了单一主服务器的效率瓶颈问题。在主从式元数据库模式中，始终只有一台服务器对外提供服务。而在本解决方案中，两个元数据库的地位是相等的，均可以对外提供服务，只要有其中一个元数据库执行成功就可返回。因此，不需要将全部的操作都放到一个主服务器上。

以上实施例仅用以说明本发明的技术方案，而非对其进行限制。因此，在不背离本发明的精神及其实质的情况下，本领域技术人员可作出各种改变、替换和变型。很显然，但这些改变、替换和变型都应涵盖于本发明权利要求的保护范围之内。

Claims (6)

1.一种元数据管理方法，包括步骤：

在需要对元数据进行操作时，同时在至少两个元数据库上执行相同的元数据操作指令；

其特征在于，当其中至少一个元数据库上的操作完成时，则判定元数据操作成功；如果有元数据库操作失败，则将所述元数据操作指令保存到操作成功的元数据库中，待该操作失败的元数据库恢复后再执行所述元数据操作指令；

将操作失败的元数据库设置为不可用状态；

如果所述保存失败，将所述元数据操作指令保存到发出元数据操作指令的业务服务器的本地文件系统中。

2.如权利要求1所述的元数据管理方法，其特征在于，在恢复所述操作失败的元数据库时，由租赁该元数据库成功的业务进程对该元数据库进行恢复操作。

3.如权利要求2所述的元数据管理方法，其特征在于，由租赁该元数据库成功的业务进程对该元数据库进行恢复操作具体为：

在判断所述操作失败的元数据库的租赁到期时间已到达后，设置新的租赁到期时间，并将租赁者设置为所述业务进程；

在租赁成功后，通知续租线程保持续租；

执行恢复操作；

在恢复操作完成后，通知续租线程结束续租。

4.如权利要求3所述的元数据管理方法，其特征在于，所述续租线程的操作具体为：

在接收到续租开始命令后，确认是否收到续租结束命令；

如果未接收到续租结束命令，检查是否已经到达续租启动时刻；

在已经到达续租启动时刻后，将租赁到期时间延长。

5.一种元数据管理系统，其特征在于，包括，

元数据操作单元，用于在需要对元数据进行操作时，同时在至少两个元数据库上执行相同的元数据操作指令；和

操作成功判断单元，用于当其中至少一个元数据库上的操作完成时，判定元数据操作成功；

操作恢复单元，用于在有元数据库操作失败时，将所述元数据操作指令保存到操作成功的元数据库中，待该操作失败的元数据库恢复后再执行所述元数据操作指令；

设置单元，用于将操作失败的元数据库设置为不可用状态；

操作恢复单元还用于在所述保存失败时将所述元数据操作指令保存到发出元数据操作指令的业务服务器的本地文件系统中。

6.如权利要求5所述的元数据管理系统，其特征在于，操作恢复单元还用于在恢复所述操作失败的元数据库时，由租赁该元数据库成功的业务进程对该元数据库进行恢复操作。