CN106339279B - 一种业务恢复方法及装置 - Google Patents

Abstract

本发明实施例提供了一种业务恢复方法及装置，应用于Hbase***中，所述方法包括：当感知第一区域服务器发生故障后，查找已存储的索引表，并在所述索引表中获得与所述第一区域服务器对应的第一区域，以及第一日志数据；存储所述第一区域对应的第一日志数据；将所述第一区域分配给正常运行的第二区域服务器，以使第二区域服务器加载所述第一区域时，根据与所述第一区域对应的第一日志数据，进行业务恢复。应用本发明实施例，在区域服务器故障后，可以直接从索引表中，查找故障的区域服务器对应的区域，以及该区域对应的日志数据，无需再进行日志分割，从而提高了区域服务器故障后业务恢复的效率。

Description

一种业务恢复方法及装置

技术领域

本发明涉及通信技术领域，特别是涉及一种业务恢复方法及装置。

背景技术

HBase(HadoopDatabase，Hadoop数据库)是一种面向列、可伸缩、实时读写的分布式存储数据库，能够实现复杂任务的并行和分布式处理，具有很高的处理性能和可靠性。

HBase是建立在分布式文件***120(Hadoop Distributed File System，HDFS)基础之上的，其常见结构如图1所示，包括：主机(Master)101、区域服务器(RegionServer)102、协调服务器(Zookeeper)103以及客户端104。

其中，客户端104为用户访问HBase的接口。

Master101与每个RegionServer102连接，负责管理各个RegionServer102。

RegionServer102是HBase中最核心的模块，每个RegionServer102根据其被分配的区域(Region)，通过客户端104接收用户对数据库的读写请求，响应所述读写请求，向分布式文件***120中读写数据。

Zookeeper103：协调集群中各网元之间的数据共享和访问，存储所有RegionServer的位置并实时监控其状态。另外，Zookeeper103还存储有HBase运行所需的其他信息。

具体的，每个RegionServer102管理多个HRegion对象。每个HRegion对应数据库表Table中的一个Region。在HBase中，一个Region只分配给一个RegionServer。

RegionServer202的工作原理如图2所示，图2中示出了一个RegionServer202被分配了3个HRegion203的情况。

RegionServer202通过客户端201接收用户的读写请求，根据读写请求中的数据，确定属于哪个Region，将该读写请求提交给对应的HRegion203对象，HRegion203对象将读写请求中的数据写入对应的内存204中，进而向分布式文件***中读写数据，完成读写请求对应的操作。在这个过程中，HRegion203对象会生成针对该读写请求的日志数据，存储至HLog中。一个RegionServer202对应一个HLog，其中存储了RegionServer202的所有Region的日志。HLog中的日志数据是按照日志数据生成的时间，顺序存储的，各个Region的日志数据混杂在一起。

在分布式***环境中，无法避免***出错或者宕机，一旦RegionServer出现故障意外退出，内存中的数据就会丢失，造成业务中断。

为了恢复中断的业务，Master会将故障RegionServer的Region分配给新的RegionServer。新的RegionServer需要获得故障RegionServer中各个Region对应的日志数据，才能针对不同Region分别恢复业务。

由于HLog中各个Region的日志数据混杂在一起，因此，需要先对HLog中的日志数据进行日志分割，将每个Region对应的日志数据分割出来。

目前进行日志分割，有两种方式：

第一种，Master通过Zookeeper感知到某RegionServer故障，读取故障RegionServer对应的HLog中的全部日志数据，对其进行日志分割，获得每个Region的日志数据分别存储，再由新的RegionServer去存储的日志数据中获得分配给自身的Region的日志数据。

第二种，Master通过Zookeeper感知到某RegionServer故障，针对故障RegionServer对应HLog中的全部日志数据，生成多个日志分割任务，将日志分割任务分配给不同的RegionServer，由不同的RegionServer并行完成日志分割任务。

上述两种方式虽然都能完成日志分割，但由于通常日志数据的数据量都非常庞大，因此第一种方式完全由Master处理，需要较长的时间，会造成I/O和内存的超载，处理效率较低；而第二种方式由RegionServer处理则需要占用不同的RegionServer的大量计算资源，造成了资源的耗费，处理效率也较低。

可见，现有技术由于需要进行日志分割，且目前日志分割的处理效率比较低，所以导致业务恢复的效率也不高。

发明内容

本发明实施例的目的在于提供一种业务恢复方法及装置，以实现提高区域服务器故障后业务恢复的效率。具体技术方案如下：

一方面，本发明实施例公开了一种业务恢复方法，应用于Hbase***中，包括：

当感知第一区域服务器发生故障后，查找已存储的索引表，并在所述索引表中获得与所述第一区域服务器对应的第一区域，以及第一日志数据；所述索引表用于记录区域服务器、区域以及日志数据三者的对应关系；

存储所述第一区域对应的第一日志数据；

将所述第一区域分配给正常运行的第二区域服务器，以使第二区域服务器加载所述第一区域时，根据存储的所述第一区域对应的第一日志数据，进行业务恢复。

优选的，所述索引表还包括状态信息，所述状态信息用于表示区域服务器的运行状态；

所述将所述第一区域分配给正常运行的第二区域服务器，包括：

根据所述索引表中的状态信息，选取出正常运行的区域服务器；

将该选取出的区域服务器作为第二区域服务器，并将所述第一区域分配给所述第二区域服务器。

优选的，所述方法还包括：在所述第一区域服务器发生故障之前，将针对第一区域执行的每次读写操作时生成的第一日志数据，记录至所述索引表中。

优选的，在将所述第一区域分配给正常运行的第二区域服务器后，所述方法还包括：

在所述索引表中，记录第二日志数据，使得所述索引表记录所述第二区域服务器与所述第一区域，以及所述第二日志数据的对应关系；所述第二日志数据包括第一日志数据，以及所述第二区域服务器针对所述第一区域执行的读写操作时生成的日志数据。

优选的，该方法还包括：

当感知所述第一区域服务器故障恢复后，查找已存储的索引表，并在所述索引表中获得分配给所述第二区域服务器的第一区域，以及第二日志数据；

存储所述第一区域对应的第二日志数据；

将所述第一区域分配回所述第一区域服务器，以使所述第一区域服务器加载所述第一区域时，根据与所述第一区域对应的第二日志数据，进行业务回切。

优选的，所述第一区域服务器对应的第一区域为多个；

所述存储所述第一区域对应的第一日志数据的步骤，为：存储每个第一区域对应的第一日志数据；

将所述第一区域分配给正常运行的第二区域服务器的步骤，为：分别将各个第一区域分配给一个或多个正常运行的第二区域服务器，以使每个第二区域服务器加载被分配的第一区域时，根据存储的所述第一区域对应的第一日志数据，进行业务恢复。

另一方面，本发明实施例公开了一种业务恢复装置，应用于Hbase***中，包括：

第一查表单元，用于当感知第一区域服务器发生故障后，查找已存储的索引表，并在所述索引表中获得与所述第一区域服务器对应的第一区域，以及第一日志数据；所述索引表用于记录区域服务器、区域以及日志数据三者的对应关系；

第一存储单元，用于存储所述第一区域对应的第一日志数据；

第一分配单元，用于将所述第一区域分配给正常运行的第二区域服务器，以使第二区域服务器加载所述第一区域时，根据存储的所述第一区域对应的第一日志数据，进行业务恢复。

优选的，所述装置还包括：状态信息单元，用于设置表示区域服务器的运行状态；

所述第一分配单元，包括：

选取子单元，用于根据所述索引表中的状态信息，选取出正常运行的区域服务器；

分配子单元，用于将该选取出的区域服务器作为第二区域服务器，并将所述第一区域分配给所述第二区域服务器。

优选的，所述装置还包括：

第一日志记录单元，用于在所述第一区域服务器发生故障之前，将针对第一区域执行的每次读写操作时生成的第一日志数据，记录至所述索引表中。

优选的，所述装置还包括：

第二日志记录单元，用于在所述索引表中，记录第二日志数据，使得所述索引表记录所述第二区域服务器与所述第一区域，以及所述第二日志数据的对应关系；所述第二日志数据包括第一日志数据，以及所述第二区域服务器针对所述第一区域执行的读写操作时生成的日志数据。

优选的，所述装置还包括：

第二查表单元，用于当感知所述第一区域服务器故障恢复后，查找已存储的索引表，并在所述索引表中获得分配给所述第二区域服务器的第一区域，以及第二日志数据；

第二存储单元，用于存储所述第一区域对应的第二日志数据；

第二分配单元，用于将所述第一区域分配回所述第一区域服务器，以使所述第一区域服务器加载所述第一区域时，根据与所述第一区域对应的第二日志数据，进行业务回切。

由上述的技术方案可见，本发明实施例提供的业务恢复方法及装置，由于在索引表中，包含了区域服务器、区域以及日志数据三者的对应关系；也就是说，在索引表中，已经将每个区域对应的日志数据分别做了记录，因此，在区域服务器故障后，可以直接从索引表中，查找故障的区域服务器对应的区域，以及该区域对应的日志数据，无需再进行日志分割，从而提高了区域服务器故障后业务恢复的效率。当然，实施本发明的任一产品或方法必不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术Hbase***结构示意图；

图2为现有技术RegionServer的工作原理示意图；

图3为本发明实施例的业务恢复方法的一种流程示意图；

图4为应用本发明实施例的业务恢复方法RegionServer的工作原理示意图；

图5为本发明实施例的业务恢复方法的另一种流程示意图；

图6为本发明实施例的业务恢复装置的一种结构示意图；

图7为本发明实施例的业务恢复装置的另一种结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供了一种业务恢复方法及装置，以提高区域服务器故障后业务恢复的效率。

需要说明的是，本发明实施例在Hbase***中预设一张索引表，正常运行的区域服务器(RegionServer)会将其分配的区域(Region)对应的日志数据统一写入所述索引表中。本发明实施例的RegionServer故障后的业务恢复方法及装置，优选的，由Hbase***中的Master基于所述索引表进行处理，从而实现了业务恢复。

参考图3，图3为本发明实施例提供的业务恢复方法的一种流程示意图，应用于Hbase***中，所述方法包括：

S301：当感知第一RegionServer发生故障后，查找已存储的索引表，并在所述索引表中获得与所述第一RegionServer对应的第一Region，以及第一日志数据；所述索引表用于记录RegionServer、Region以及日志数据三者的对应关系；

具体的，所述第一RegionServer发生故障，可以理解为Hbase***中的一个RegionServer发生故障，或者多个RegionServer同时发生故障。所述第一RegionServer对应的第一Region可以为一个或多个Region。当Hbase***中的一个或者多个RegionServer同时发生故障后，Master会通过zookeeper感知到发生故障的一个或多个RegionServer，并在已经存储的索引表中查找并获取所述发生故障的一个或多个RegionServer对应的一个或者多个Region。在所述索引表中，每个RegionServer对应一个或多个Region，每个RegionServer还对应第一Region对应的日志数据。

S302：存储所述第一Region对应的第一日志数据；

S303：将所述第一Region分配给正常运行的第二RegionServer，以使第二RegionServer加载所述第一Region时，根据存储的所述第一Region对应的第一日志数据，进行业务恢复。

具体的，当Hbase***中的一个或者多个RegionServer发生故障时，将所述一个或多个RegionServer在索引表中对应的Region分配给Hbase***中正常运行的RegionServer。需要说明的是，如果发生故障的RegionServer在索引表中对应的Region的数量比较少，可以将这些Region都分配给一个正常运行的RegionServer，如果故障RegionServer被分配的Region的数量比较多，可以将这些Region分配给正常运行多个RegionServer，以防止各个RegionServer负载分担不均。

实际应用中，索引表中还可以包含用于表示每个RegionServer运行状态的状态信息。例如，当RegionServer正常运行时，Master将该RegionServer的状态信息设置为激活状态，具体的，在索引表中可以用“Active”表示正常运行的RegionServer的状态信息为激活状态；或者，当RegionServer发生故障时，Master将该RegionServer的状态信息设置为锁定状态，具体的，在索引表中可以用“Block”表示该RegionServer的状态信息为锁定状态，也就是将正常运行的每个RegionServer的状态信息设置为“Active”，将发生故障的每个RegionServer的状态信息设置为“Block”。这样，Master就可以根据RegionServer的状态信息，感知到发生故障的RegionServer。

这种情况下，所述步骤S303可以包括：查找所述索引表，获得当前为激活状态的RegionServer，并从当前为激活状态的RegionServer中，确定一个或者多个RegionServer作为第二RegionServer，将所述第一Region分配给正常运行的第二RegionServer，也就是从正常运行的RegionServer中确定一个或者多个RegionServer(即，让第二RegionServer来接管该第一Region)，将发生故障的RegionServer的第一Region分配给所述确定的一个或者多个RegionServer。这里，可以根据正常运行的RegionServer的负载情况来确定选择一个或者多个RegionServer；例如，所述第二RegionServer在索引表中对应的Region数量比较少，则将第一Region分配给该第二RegionServer。

另外，所述步骤S302中，获取发生故障的RegionServer对应的一个或多个Region在索引表中对应的日志数据后，可以将所述日志数据存储到与第一Region关联的指定位置，其中，所述第一Region至少为一个Region或者多个Region。

这样，所述步骤S303中，第二RegionServer加载所述被分配的第一Region时，从第一Region关联的指定位置，分别获得被分配的第一Region对应的第一日志数据，进行业务恢复。

再有，本发明实施例中，在将所述第一Region分配给正常运行的第二RegionServer后，还可以将第一Region对应的第一日志数据添加到索引表中，并且该第一日志数据与第二RegionServer以及第一Region是对应的。

在本发明实施例的一种实现方式中，在所述第一RegionServer发生故障之前，将针对第一Region执行的每次读写操作时生成的第一日志数据，记录至所述索引表中。可以理解的是，在Hbase***中没有RegionServer发生故障时，也就是所有RegionServer都处于正常运行状态时，RegionServer针对Region执行的每次读写操作时生成对应的日志数据，写入到索引表中。

参考图4，图4为应用本发明实施例提供的业务恢复方法RegionServer的工作原理示意图。图4中示出了将6个Region(Region1、Region2、Region3、Region4、Region5以及Region6)分配给3个RegionServer(RegionServer1、RegionServer2以及RegionServer3)的情况，每个RegionServer分配2个Region。

在本实施例中，Hbase***还存有索引表，具体的，该索引表可以被存储在能够与Master、RegionServer以及Region关联的任意指定位置，并且该索引表是按照RegionServer、Region以及日志数据三者的对应关系建立的表。

例如，具体的，在RegionServer1发生故障之前，将针对该RegionServer1的Region1和Region2执行的每次读写操作时生成第一日志数据，添加至索引表中，并且，所述第一日志数据与该RegionServer1以及Region1和Region2是对应的。

针对图4所述的情况，在RegionServer1发生故障前，所述索引表如表一所示，其中，表中的Log为日志数据，Log1和Log2为第一日志数据，该第一日志数据具体为与RegionServer1对应的日志数据。

表一

如表二所示：当Master感知RegionServer1发生故障后，将所述RegionServer1的状态信息设置为“Block”，并将RegionServer1在索引表中的Region1和Region2分别分配给正常运行的RegionServer2和RegionServer3，同时，将Region1和Region2对应的第一日志数据，分别对应添加到RegionServer2和RegionServer3中，其中，表中的log为日志数据，具体的，Log1和Log2为第一日志数据，该第一日志数据具体为与RegionServer1对应的日志数据。需要说明的是，在此实施例中，第一RegionServer为RegionServer1、第二RegionServer包括RegionServer2和RegionServer3、第一Region包括Region1和Region2。

表二

如表二所示，当RegionServer1发生故障，RegionServer1的状态变为Block，则Master将RegionServer1对应的log1、log2(即第一日志数据)分别写入与RegionServer1对应的Region1、Region2中，并将写入了第一日志数据的Region1、Region2分别分配给RegionServer2、RegionServer3(此处考虑负载均衡，因此将Region1、Region2分别分配给了RegionServer2RegionServer3，也就是说RegionServer2、RegionServer3为本实施例中的第二RegionServer)这样，RegionServer2和RegionServer3在被分配了Region1和Region2后，通过读写Region1、Region2中的数据来继续执行RegionServer1中的业务，从而实现了对RegionServer1中的业务恢复，进一步的，RegionServer2、RegionServer3会将针对Region1和Region2执行的读写操作时生成的日志数据，添加至索引表中(如表二所示，第二RegionServer针对Region1、Region2读写生成的日志数据分别为log1`、log2`)，并且，Region1与RegionServer2以及Log1+log1`是对应的，Region2与RegionServer3以及Log2+log2`是对应的。此时，所述索引表将会记录第二RegionServer与第一Region，以及第二日志数据的对应关系，这里，所述第二日志数据包括第一日志数据，以及第二RegionServer针对所述第一Region执行的读写操作时生成的日志数据(即第二日志数据为log1+log1`以及log2+log2`)。

应用上述实施例，当Hbase***中的RegionServer发生故障后，可以直接从已存储的索引表中获取发生故障的RegionServer对应的Region，并将所述Region分配给Hbase***中正常运行的RegionServer。可见，在本发明实施例中，当RegionServer发生故障时，无需进行日志分割，直接在索引表中获得发生故障的RegionServer对应的Region，并将所获得的Region分配给正常运行的RegionServer，完成业务恢复，提高了RegionServer故障后业务恢复的效率。

参考图5，图5为本发明实施例提供的业务恢复方法的另一种流程示意图，应用于Hbase***中，与图4所示实施例相比，本实施例增加了业务回切的步骤，所述方法中：

步骤S501～步骤S503与图3所示的步骤S301～步骤S303类似，因此，这里不再赘述。

从步骤S504开始为业务回切的步骤，具体如下：

S504：当感知所述第一RegionServer故障恢复后，查找已存储的索引表，并在所述索引表中获得分配给所述第二RegionServer的第一Region，以及第二日志数据；

具体的，当第一RegionServer故障恢复后，Master会通过zookeeper感知，得知第一RegionServer故障已恢复，查找已存储的索引表，同时获得分配给所述第二RegionServer的第一Region对应的第二日志数据。这里，所述第一日志数据和所述第二日志数据是不同的，第二日志数据包括第一日志数据，以及第二RegionServer针对所述第一Region执行的读写操作时生成的日志数据。

S505：存储所述第一Region对应的第二日志数据；

将获得的第一Region对应的第二日志数据存储到与第一Region关联的指定位置。具体的，所述指定位置可以为“recovered.edits”或者其它具有存储功能的文件夹。

S506：将所述第一Region分配回所述第一RegionServer，以使所述第一RegionServer加载所述第一Region时，根据与所述第一Region对应的第二日志数据，进行业务回切；

具体的，当第一RegionServer故障恢复后，所述第一RegionServer在加载该RegionServer对应的第一Region时，从存储的第一Region对应的第二日志数据中，获得分配给第二Region的第一Region对应的第二日志数据，进行业务回切。可以理解为，当第一RegionServer故障恢复后，所述第一RegionServer在加载该RegionServer的第一Region时，从与第一Region关联的指定位置中获得所述第一Region对应的第二日志数据，进行业务回切。

在实际应用中，当所述第一Region对应的第二日志数据分配回所述第一RegionServer后，所述方法还包括：将索引表中第一RegionServer的运行状态的状态信息设置为激活状态，这里，激活状态表示该第一RegionServer已正常运行。另外，当Hbase***中再有RegionServer发生故障时，可以同样采用本发明所述的方法进行业务恢复。

应用上述各个实施例，可以在RegionServer发生故障后，查找已存储的索引表，直接获得该RegionServer对应的Region，以及该Region对应的日志数据，恢复该RegionServer，并将第二日志数据迁回到索引表中该RegionServer的日志记录中，使得业务回切至原RegionServer。可见本发明实施例省略了日志分割的过程，不但提高了RegionServer故障后业务恢复的效率，而且提高了RegionServer故障恢复后业务回切的效率。

参考图6，图6为本发明实施例提供的业务恢复装置的一种结构示意图，应用于Hbase***中，该装置包括：

第一查表单元601，用于当感知第一RegionServer发生故障后，查找已存储的索引表，并在所述索引表中获得与所述第一RegionServer对应的第一Region，以及第一日志数据；所述索引表用于记录RegionServer、Region以及日志数据三者的对应关系；

第一存储单元602，用于存储所述第一Region对应的第一日志数据；

第一分配单元603，用于将所述第一Region分配给正常运行的第二RegionServer，以使第二RegionServer加载所述第一Region时，根据存储的所述第一Region对应的第一日志数据，进行业务恢复。

在本发明实施例的一种实现方式中，该装置还包括：状态信息单元，用于设置表示RegionServer的运行状态；例如，将正常运行的RegionServer的状态信息设置为激活状态，将发生故障的RegionServer的状态信息设置为锁定状态。

在本发明实施例的一种实现方式中，所述第一分配单元603，包括：

第一查表子单元，用于根据所述索引表中的状态信息，选取出正常运行的RegionServer；

具体的，查找所述索引表，获得当前为激活状态的RegionServer；

第一分配子单元，用于将该选取出的RegionServer作为第二RegionServer，并将所述第一Region分配给所述第二RegionServer。

在本发明实施例的一种实现方式中，所述装置还包括：第一日志记录单元，用于在所述第一RegionServer发生故障之前，将针对第一Region执行的每次读写操作时生成的第一日志数据，记录至所述索引表中。

在本发明实施例的一种实现方式中，所述装置还包括：第二日志记录单元，用于在所述索引表中，记录第二日志数据，使得所述索引表记录所述第二RegionServer与所述第一Region，以及所述第二日志数据的对应关系；所述第二日志数据包括第一日志数据，以及所述第二RegionServer针对所述第一Region执行的读写操作时生成的日志数据。

应用上述各个实施例，当RegionServer发生故障时，无需进行日志分割，直接在索引表中获得发生故障的RegionServer对应的Region，分配给正常运行的RegionServer，完成业务恢复，提高了RegionServer故障后业务恢复的效率。

参考图7，图7为本发明实施例提供的业务恢复装置的另一种结构示意图，应用于Hbase***中，该装置包括：

第一查表单元701，用于当感知第一RegionServer发生故障后，查找已存储的索引表，并在所述索引表中获得与所述第一RegionServer对应的第一Region，以及第一日志数据；所述索引表用于记录RegionServer、Region以及日志数据三者的对应关系；

第一存储单元702，用于存储所述第一Region对应的第一日志数据；

第一分配单元703，用于将所述第一Region分配给正常运行的第二RegionServer，以使第二RegionServer加载所述第一Region时，根据存储的所述第一Region对应的第一日志数据，进行业务恢复。

需要说明的是，本实施例中的第一查表单元701、第一存储单元702和第一分配单元703分别可以与图6所示实施例中的第一查表单元601、第一存储单元602和第一分配单元603类似，因此，这里不再赘述。

第二查表单元704，用于当感知所述第一RegionServer故障恢复后，查找已存储的索引表，并在所述索引表中获得分配给所述第二RegionServer的第一Region，以及第二日志数据；

第二存储单元705，用于存储所述第一Region对应的第二日志数据；

第二分配单元706，用于将所述第一Region分配回所述第一RegionServer，以使所述第一RegionServer加载所述第一Region时，根据与所述第一Region对应的第二日志数据，进行业务回切。

在本发明实施例的一种实现方式中，所述索引表还包含状态信息，所以该装置还包括：状态设置单元，用于将正常运行的RegionServer的状态信息设置为激活状态，将发生故障的RegionServer的状态信息设置为锁定状态；

在本发明实施例的一种实现方式中，所述第一分配单元703，包括：

选取子单元，用于根据所述索引表中的状态信息，选取出正常运行的RegionServer；

分配子单元，用于将该选取出的RegionServer作为第二RegionServer，并将所述第一Region分配给所述第二RegionServer。

在本发明实施例的一种实现方式中，该装置还包括：第一日志记录单元，用于在所述第一RegionServer发生故障之前，将针对第一Region执行的每次读写操作时生成的第一日志数据，记录至所述索引表中。

在本发明实施例的一种实现方式中，该装置还包括：第二日志记录单元，用于在所述索引表中，记录第二日志数据，使得所述索引表记录所述第二RegionServer与所述第一Region，以及所述第二日志数据的对应关系；所述第二日志数据包括第一日志数据，以及所述第二RegionServer针对所述第一Region执行的读写操作时生成的日志数据。

应用上述各个实施例，可以在RegionServer发生故障后，查找已存储的索引表，直接获得该RegionServer的对应的Region，以及该Region对应的日志数据，并恢复该RegionServer，并将第二日志数据分配回恢复的RegionServer的中，使得业务回切至原RegionServer。可见，本发明实施例省略了日志分割的过程，不但提高了RegionServer故障后业务恢复的效率，而且提高了RegionServer故障恢复后业务回切的效率。

对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (7)

1.一种业务恢复方法，其特征在于，应用于Hbase***中，包括：

当感知第一区域服务器发生故障后，查找已存储的索引表，并在所述索引表中获得与所述第一区域服务器对应的第一区域，以及第一日志数据；所述索引表用于记录区域服务器、区域以及日志数据三者的对应关系；

存储所述第一区域对应的第一日志数据；

将所述第一区域分配给正常运行的第二区域服务器，以使第二区域服务器加载所述第一区域时，根据存储的所述第一区域对应的第一日志数据，进行业务恢复；

在将所述第一区域分配给正常运行的第二区域服务器后，所述方法还包括：

在所述索引表中，记录第二日志数据，使得所述索引表记录所述第二区域服务器与所述第一区域，以及所述第二日志数据的对应关系；所述第二日志数据包括第一日志数据，以及所述第二区域服务器针对所述第一区域执行的读写操作时生成的日志数据；

该方法还包括：

当感知所述第一区域服务器故障恢复后，查找已存储的索引表，并在所述索引表中获得分配给所述第二区域服务器的第一区域，以及第二日志数据；

存储所述第一区域对应的第二日志数据；

将所述第一区域分配回所述第一区域服务器，以使所述第一区域服务器加载所述第一区域时，根据与所述第一区域对应的第二日志数据，进行业务回切。

2.根据权利要求1所述的方法，其特征在于，所述索引表还包括状态信息，所述状态信息用于表示区域服务器的运行状态；

所述将所述第一区域分配给正常运行的第二区域服务器，包括：

根据所述索引表中的状态信息，选取出正常运行的区域服务器；

将该选取出的区域服务器作为第二区域服务器，并将所述第一区域分配给所述第二区域服务器。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：在所述第一区域服务器发生故障之前，将针对第一区域执行的每次读写操作时生成的第一日志数据，记录至所述索引表中。

4.根据权利要求1所述的方法，其特征在于，所述第一区域服务器对应的第一区域为多个；

所述存储所述第一区域对应的第一日志数据的步骤，为：存储每个第一区域对应的第一日志数据；

将所述第一区域分配给正常运行的第二区域服务器的步骤，为：分别将各个第一区域分配给一个或多个正常运行的第二区域服务器，以使每个第二区域服务器加载被分配的第一区域时，根据存储的所述第一区域对应的第一日志数据，进行业务恢复。

5.一种业务恢复装置，其特征在于，应用于Hbase***中，包括：

第一查表单元，用于当感知第一区域服务器发生故障后，查找已存储的索引表，并在所述索引表中获得与所述第一区域服务器对应的第一区域，以及第一日志数据；所述索引表用于记录区域服务器、区域以及日志数据三者的对应关系；

第一存储单元，用于存储所述第一区域对应的第一日志数据；

第一分配单元，用于将所述第一区域分配给正常运行的第二区域服务器，以使第二区域服务器加载所述第一区域时，根据存储的所述第一区域对应的第一日志数据，进行业务恢复；

所述装置还包括：

第二日志记录单元，用于在所述索引表中，记录第二日志数据，使得所述索引表记录所述第二区域服务器与所述第一区域，以及所述第二日志数据的对应关系；所述第二日志数据包括第一日志数据，以及所述第二区域服务器针对所述第一区域执行的读写操作时生成的日志数据；

所述装置还包括：

第二查表单元，用于当感知所述第一区域服务器故障恢复后，查找已存储的索引表，并在所述索引表中获得分配给所述第二区域服务器的第一区域，以及第二日志数据；

第二存储单元，用于存储所述第一区域对应的第二日志数据；

第二分配单元，用于将所述第一区域分配回所述第一区域服务器，以使所述第一区域服务器加载所述第一区域时，根据与所述第一区域对应的第二日志数据，进行业务回切。

6.根据权利要求5所述的装置，其特征在于，所述装置还包括：状态信息单元，用于设置表示区域服务器的运行状态；

所述第一分配单元，包括：

选取子单元，用于根据所述索引表中的状态信息，选取出正常运行的区域服务器；

分配子单元，用于将该选取出的区域服务器作为第二区域服务器，并将所述第一区域分配给所述第二区域服务器。

7.根据权利要求5所述的装置，其特征在于，所述装置还包括：

第一日志记录单元，用于在所述第一区域服务器发生故障之前，将针对第一区域执行的每次读写操作时生成的第一日志数据，记录至所述索引表中。

Images