CN118355374A - 用于同步数据复制的方法和系统 - Google Patents

Abstract

本发明提供了一种用于第一集群至第二集群的同步数据复制的方法。第一集群和第二集群相互双活配合工作。方法包括：从第一集群的第一区域服务器中的客户端服务器接收写命令；第一区域服务器在第二集群的第二区域服务器中复制接收到的写命令；其中，复制步骤包括：第二区域服务器将与写命令相关联的记录提交到第二区域服务器的第二预写日志(WAL)中，在将记录提交到第二WAL之后，第二区域服务器将记录提交到第二区域服务器的第二存储器中。此外，方法包括：所述第一区域服务器将与写命令相关联的记录提交到第一区域服务器的第一预写日志(WAL)，在将记录提交到第一WAL之后，第一区域服务器将记录提交到第一区域服务器的第一存储器。

Description

用于同步数据复制的方法和系统

本申请要求于2021年12月27日提交印度专利局、发明名称为“用于同步数据复制的方法和系统(METHOD AND SYSTEM FOR SYNCHRONOUSDATAREPLICATION)”的第202131061002号印度专利申请的优先权，该在先申请以全文引用的方式并入本文。

技术领域

本文描述的公开内容大体上涉及在分布式数据库管理系统中管理数据的机制，尤其涉及在Apache HBase^TM等分布式数据库中采用的数据恢复和同步方法。

背景技术

Hadoop数据库(HBase)是一种分布式数据库，具有高可靠性、高性能、基于键值存储等特点。因此，越来越多的企业和用户使用HBase创建数据表。HBase数据模型中存储了具有不同数据类型、不同列大小和字段大小的半结构化数据。数据文件使用分布式文件系统(如HDFS)存储在后端。HBase数据模型由若干个逻辑组件组成：行键、列族、表名、时间戳等。行键用于唯一识别HBase表中的行。HBase中的列族是静态的，而列本身是动态的。

HBase表：称为区域(Region)的各个分区中存储的行的逻辑集合。

·HBase行：表中数据的实例。

·RowKey：HBase表中的每个条目都由RowKey识别和索引。

·列：对于每个RowKey，可以存储无限数量的属性。

·列族：行中的数据作为列族分组在一起，所有列一起存储在称为HFile的低级存储文件中。

图1示出了Hbase架构及其组件的概述。HBase中最简单、最基本的水平扩展性单位是区域。存储在一起的连续、排序的行集合称为区域(表数据的子集)。HBase架构可能有许多HBase主节点，其中一个可能在任何时间点都处于活动状态。对于HBase主节点/主服务器(HMaster)而言，会有若干个从节点，即区域服务器。每个区域服务器(从节点)服务于一组区域，区域只能由单个区域服务器服务。每当客户端发出写请求时，HMaster都会接收到该请求，并将该请求转发给对应的区域服务器。主服务的高可用性是通过Apache Zookeeper^TM(图1中未示出)协调器框架来管理的。

HMaster/主服务器：

-管理Hbase表的创建、删除；

-将表区域(分区)分配给集群中的区域服务器；

-通过将区域平均分配给区域服务器来平衡集群；

-检测区域服务器的故障，并通过(进一步说明的)称为服务器崩溃过程(servercrash procedure，SCP)的过程来恢复崩溃的区域服务器中的区域。

区域服务器：

-托管表的区域(分区)，并处理从客户端传入的读请求、写请求；

-将记录写入区域服务器级别的预写日志(write ahead log，WAL)文件，以实现持久性和内存(in-memory)的快速可用性；

-管理区域存储文件，用于压缩和删除旧记录等操作；

-根据HMaster的任务分配，从WAL文件中恢复表分区(区域)数据。

区域服务器进程运行在HMaster管理的集群中的每个节点/数据节点上，例如图1中的DataNode 1、DataNode N。区域服务器大致由以下组件组成：

内存存储(in memory store)：它是写缓存，用于存储尚未写入磁盘的新数据。区域中的每个列族都有内存存储/MemStore。

预写日志(write ahead log，WAL)：WAL是用于存储未持久化到永久存储的新数据的文件。如HBase等数据库使用WAL来确保强一致性，WAL将HBase中数据的所有更改记录到基于文件的存储器。在正常操作下，不需要WAL，因为数据更改从MemStore移动到StoreFiles。但是，如果在刷新MemStore之前，区域服务器崩溃或不可用，则WAL确保数据的更改可以被重放。如果写入WAL失败，则整个修改数据的操作都会失败。

Hfile：HFile是实际的存储文件，用于将行作为排序后的键值存储在磁盘上。

除了主服务器和区域服务器之外，Hbase使用ZooKeeper作为分布式协调服务，用于区域分配，并通过将它们加载到其它正在运行的区域服务器来恢复任何的区域服务器崩溃。ZooKeeper是一种集中式监控服务器，用于维护配置信息并提供分布式同步。HMaster和区域服务器注册了ZooKeeper服务，客户端需要访问ZooKeeper仲裁才能连接到区域服务器和HMaster。

图1还描述了区域服务器中的数据写入过程：

1.客户端向区域服务器发送插入数据请求；

2.区域服务器首先将记录提交到预写日志(write ahead log，WAL)文件；

3.将数据记录插入到内存存储中的区域；

4.在记录达到存储文件之前，数据记录仅在临时内存和WAL文件中。因此，这些数据库也称为基于LSM树(日志结构化合并树)的数据库。一旦内存中积累了许多记录，这些记录就会以结构化和压缩的存储文件(HFile)的形式刷新到文件系统中；

5.将刷新后的文件添加到区域存储文件中。HFile通过压缩过程合并为大型HFile。

图2概述了区域服务器故障恢复机制，以及处理区域服务器故障所涉及的主服务器(HMaster)和区域服务器的组件。如图2a所示，当主服务器(Hmaster)检测到集群的任何一个区域服务器发生故障时，会在主服务器中触发服务器崩溃过程(server crashprocedure，SCP)，该过程涉及以下主要步骤：

o识别属于集群的故障区域服务器的所有预写日志(write ahead log，WAL)文件。可以理解，区域服务器可以托管若干个WAL文件，每个WAL文件可以包括若干个区域的记录。

o将WAL文件任务(拆分Wal)中的记录恢复到其它区域服务器。图2b描述了由分配的区域服务器实现的WALSplitter的任务。WALSplitter从恢复的WAL文件中检索记录，并按区域拆分记录。例如，参见图2b中针对区域1、区域2和区域N隔离的记录。此外，对于每个区域的每个拆分记录，也会创建对应的编辑文件。

o分配的区域服务器从WAL文件中收集每个区域的记录，并过滤已刷新的记录或属于已删除区域的记录以及与写入(put)数据无关的编辑详细信息。

o将恢复的区域记录(编辑)写入编辑文件，所述编辑文件进一步称为“恢复的编辑”文件。

虽然分配的区域服务器使用如上所述的WALSplitter(如图2a所示)，主服务器(HMaster)重新分配崩溃的区域服务器中的每个区域，每个区域被分配给集群的一个区域服务器。图2c进一步描绘了在分配的区域服务器中的打开区域处理程序过程的实现方式，所述分配的区域服务器在被分配了区域时从主服务器接收任务。

o在分配请求时，相应的分配的区域服务器读取区域的已恢复的编辑文件(参见图2b)。

o应用于内存并刷新到分配区域的存储文件，以确保记录是持久的。

o初始化所有的存储文件，以便为查询做好准备。

o向主服务器确认区域打开状态。

o使区域可供用户操作。

数据复制：

为了实现灾难恢复的数据恢复或提高可用性，使用多集群部署，其中，使用称为复制的机制将数据记录从一个集群传输到另一集群，该机制的工作原理如下：

o使用后台复制服务将WAL文件中的记录以异步模式复制到对等集群[最终一致性]

o至少一次将客户端编辑传递到对等集群

o每个新的WAL都会被添加到复制队列中，并在ZK(ZooKeeper)中同步状态

o源区域服务器将批量编辑复制到宿(sink)区域服务器。

多个集群在不同的操作模式下工作：

-双活模式：

-为了实现负载均衡的目的，不同的客户端应用都可以独立访问这两个集群。

-当第一集群不可访问时，应用可以使用其它集群作为回退，这使得集群具有高可用性。

-主备模式：

-只有活动集群可供客户端应用访问，而备集群从活动集群同步数据。在活动集群崩溃的情况下，

备集群可供客户端访问。

与数据从活动集群传输到备集群相关的技术问题之一是异步模式，异步模式使连接到备集群的客户端应用无法看到最新的数据，因此客户端会看到不一致的结果。此外，当活动集群在发生灾难或电源故障场景下宕机时，未传输到备集群的数据将丢失(高恢复点目标(recovery point object，RPO))。此外，要恢复所有数据并实现数据一致性，可能需要很长时间才能恢复集群并重放挂起的数据或将原始数据与备集群中的可用记录进行比较(高恢复时间目标(recovery time object，RTO))。但是，在数据一致性受损的情况下，可以使集群立即可供客户端应用使用。主备模式中使用的异步复制方法的缺点可以概括为：

-当两个集群都健康时的最终一致性。

-从备集群读取会产生过期数据

-当活动集群崩溃时，未复制的数据会丢失。

-RPO＝约数秒到分钟；

-RTO＝约数分钟到数小时

在目前已知的基于Apache的HBased技术中，公开了同步复制方法。题为“使用远程WAL的同步复制方案(Synchronous Replication Solution using Remote WAL)”的文档(称为现有技术1，该文档可从以下链接访问：https://issues.apache.org/jira/browse/HBASE-19064)描述了两个群集(即活动集群(A)和备集群(S))的设置，并通过异步复制连接这两个集群。所有的读/写都在A执行，S只接收复制数据。除了正常的WAL日志记录之外，A还会向S的HDFS集群写入WAL(远程WAL)的副本。当异步复制进行时，S也会删除S上已经复制的远程WAL。如果A崩溃，并且希望S成为下一个活动集群，则在提供服务之前，远程WAL将在S上重放。与现有技术1公开的方法相关联的缺点如下：

o从节点，即S，不接受读请求或写请求，只接收复制数据。

o使用远程日志，这种设计只降低了RPO。但实际的数据记录传输仍然使用异步复制。

o在主节点故障期间从远程日志文件中恢复挂起的数据仍然需要很长的时间(RTO＝约数分钟)，因为所有表都有数据记录。过滤每个区域/表分区所需的记录需要分钟级别的时间(RTO＝约数分钟)

o集群切换需要几分钟的时间，直到区域恢复/刷新存储。

o不支持自从节点读取。即使启用，数据也是过期的(因为数据副本仍然是通过异步复制)

US20170161350A1，“分布式存储环境中的同步复制(Synchronous replicationin a distributed storage environment)”，称为现有技术2，公开了：为了实现同步复制，考虑了最终一致性方法和强一致性方法。接收到的数据可以写入到主数据存储的日志中，以便最终提交。然后，可以用记录(例如唯一标识符)注释数据，这有助于在辅助数据存储中重放数据。在接收到辅助数据存储已经将数据写入日志的确认后，主数据存储可以提交数据并将成功确认传输回客户端。在强一致性方法中，主数据存储可以等待向客户端发送成功确认，直到它接收到辅助数据存储不仅已写入数据而且已提交数据的确认。与现有技术2公开的方法相关联的缺点如下：

o方案基于主数据存储到辅助数据存储。辅助数据存储中不支持写入。

o在发生崩溃的情况下，没有恢复集群的方案；

o如果主集群与辅助集群之间存在通信故障，则在辅助集群中提交之后，记录对辅助集群可见，但在主集群中不可读取。

US8301593，“混合模式同步和异步复制系统(Mixed mode synchronous andasynchronous replication system)”，称为现有技术3，描述了：复制系统包括异步复制模式和同步复制模式，它复制与多个事务相关联的数据。每个事务有一个或多个事务步骤或操作。当复制系统以异步复制模式运行时，基于逐个对象将第一组事务步骤或操作分配给多个应用方。当复制系统以同步复制模式运行时，基于逐个事务将第二组事务步骤或操作分配给多个应用方。复制系统还包括一个或多个始发节点，并且对要在始发节点上执行的第一组和第二组事务步骤或操作的请求可以在相同的时间段内发起。与现有技术3公开的方法相关联的缺点如下：

o事务由客户端发起和提交，而不是由分布式数据库自动管理。对于集群宕机的故障场景，客户端需要注意的是等待，直到完成到辅助/备数据库的同步。

o事务是全局的，不在需要单独的事务分区设计的分区级别。

o针对通信故障期间出现的崩溃和乱序记录的恢复方案不在本设计范围内。

WO2017124938A1，“用于数据同步的方法、设备和系统(A method,device,andsystem for data synchronization)”，称为现有技术3，描述了：用于数据同步的方法包括：当数据同步源端确定源数据库的数据修改时，数据同步源端针对当前的数据修改实例产生实时通知，并将实时通知发送给数据同步目标端；当数据同步目标端接收到实时通知时，数据同步目标端从实时通知中解析与数据修改相关的信息，并基于解析结果更新目标端数据库缓存。当目标端接收到实时通知时，目标端可以基于实时通知中携带的信息直接更新本地数据库缓存，或者启动对本地数据库的监控，以便在本地数据同步完成后立即更新缓存数据，从而实现减少缓存同步和更新延迟的效果。与现有技术4公开的方法相关联的缺点如下：

o两个集群之间没有行锁协调。如果表的同一行在两个集群中都被修改，则不能保证原子性。

综上所述，分布式数据库存储系统的现有复制机制还有一定的改进空间，尤其是在如HBase等分布式数据库的分区级别下，复制过程中的事务管理方面。业界现有的解决方案主要集中在集群之间的异步数据传输，这只能支持最终一致性，无法满足客户需要强一致性的需求。使用主备架构的传统系统需要很长的时间才能供用户使用，因为需要对尚未同步的动态记录进行漫长的恢复过程。

发明内容

本发明内容旨在介绍与同步复制方法相关的概念，所述同步复制方法在双活集群模式部署中使用，其中，两个集群可以支持同时读取和写入。此外，还讨论了针对这种双活集群模式部署，故障之后的恢复机制和自动恢复，以及设置回同步复制。

本发明的主要目的是提供在分布式数据库系统(例如HBase)的双活模式部署中将数据从一个集群同步到另一集群的方法，以及在灾难期间从任何故障集群恢复数据的方法。本发明的主要目的可以概括为：

-支持多活动集群，但数据结果一致。

-使两个集群都可以被用户访问，以实现负载均衡。

-通过批量加载准备好的数据文件而不是使用逐条记录来优化恢复崩溃集群所需的时间。

-在一个集群不健康或崩溃时，提供即时故障恢复到健康集群的功能。

-跟踪通信故障记录并确保事务在两个集群中具有相同的状态。

-实现RPO＝0。

-实现RTO约为0(如果一个集群宕机，客户端可以切换到其它集群)。

在第一种实现方式中，本发明提供了一种用于第一集群至第二集群的同步数据复制的方法。所述第一集群和所述第二集群相互双活配合工作。所述方法包括：从所述第一集群的第一区域服务器中的客户端服务器接收写命令；所述第一区域服务器在所述第二集群的第二区域服务器中复制接收到的写命令；其中，复制步骤包括：所述第二区域服务器将与所述写命令相关联的记录提交到所述第二区域服务器的第二预写日志(write ahead log，WAL)中，在将所述记录提交到所述第二WAL之后，所述第二区域服务器将所述记录提交到所述第二区域服务器的第二存储器中。此外，所述方法包括：所述第一区域服务器将与所述写命令相关联的所述记录提交到所述第一区域服务器的第一预写日志(write ahead log，WAL)，在将所述记录提交到所述第一WAL之后，所述第一区域服务器将所述记录提交到所述第一区域服务器的第一存储器。

在一种实现方式中，所述第一区域服务器在第二阶段提交，即首先在远程集群中完成提交，然后才在本地集群中提交。

在另一种实现方式中，与在所述第一区域服务器中接收到的所述写命令对应的所述记录被同时提交到所述第一区域服务器的所述第一存储器和所述第二区域服务器的所述第二存储器；如果与所述写命令对应的所述记录在所述第一区域服务器和所述第二区域服务器中的任一个区域服务器中提交失败，则在所述第一集群和所述第二集群中的任一个集群中接收到的后续读操作或搜索查询不考虑所述记录。

在又一种实现方式中，公开了一种用于同步数据复制的系统。所述系统包括第一集群和第二集群。所述第一集群包括第一区域服务器，所述第一区域服务器包括第一存储器、第一预写日志(write ahead log，WAL)和第一文件存储器；所述第二集群包括第二区域服务器，所述第二区域服务器包括第二存储器、第二WAL和第二文件存储器。所述第一集群和所述第二集群相互双活配合工作。此外，所述第一区域服务器用于从客户端服务器接收写命令，在所述第二区域服务器中复制接收到的写命令，其中，复制步骤包括：所述第二区域服务器将与所述写命令相关联的记录提交到第二WAL中，在将所述记录提交到所述第二WAL之后，所述第二区域服务器将所述记录提交到所述第二存储器。此外，所述第一区域服务器用于将与所述写命令相关联的所述记录提交到所述第一WAL，在将所述记录提交到所述第一WAL之后，将所述记录提交到所述第一区域服务器的第一存储器。并且，所述第二区域服务器用于在所述第二区域服务器中复制所述接收到的写命令。

附图说明

该详细描述是参考附图进行描述的。在附图中，附图标记最左边的数字表示该附图标记首次出现的附图。所有附图使用相同的附图标记来指代相似特征和组件。

图1示出了现有技术方案中的Hbase架构及其组件的概述。

图2示出了在现有技术方案中HBase中采用的服务器崩溃过程。

图3示出了本发明的指导提供的双活集群架构及其组件的概述。

图4示出了本发明的实施例提供的用于第一集群至第二集群的同步数据复制的方法，第一集群和第二集群相互双活配合工作。

图5示出了本发明的实施例提供的事务日志记录和管理乱序记录的方法。

图6示出了本发明的实施例提供的在第一区域服务器中提交记录的方法。

图7是本发明的实施例提供的使用集群之间的协调锁的事务管理机制的示意图。

图8是本发明的实施例提供的使用集群之间的协调锁的事务管理机制的示意图。

图9是本发明的实施例提供的区域恢复机制的示意图。

图10是本发明的实施例提供的健康监控机制和单集群写入模式的示意图。

图11是本发明的实施例提供的自动恢复并设置回同步复制机制的示意图。

图12是本发明的实施例提供的离线批量加载数据场景的示意图。

图13至图15示出了本发明的实施例提供的用于同步数据复制的系统，所述系统包括相互双活配合的第一集群和第二集群。

图16示出了本申请中讨论的HBase集群的数据节点的示意表示。

应当理解，附图是为了说明本发明的概念，不应理解为对本发明的限制。

具体实施方式

下文结合本发明的实施例中的附图，对本发明的实施例中的技术方案进行清楚的描述。显然，所描述的实施例仅仅是本发明的一部分实施例而不是全部实施例。

本发明可以通过多种方式实现为过程、装置、系统、物质组成、计算机可读介质(例如计算机可读存储介质)或计算机网络，其中，程序指令通过光学或电子通信链路发送。在本说明书中，这些实现方式或者本发明可以采取的任何其它形式可以称为技术。通常，所公开过程的步骤的顺序可以在本发明的范围内进行更改。

下文提供本发明的一个或多个实施例的详细描述以及示出本发明的原理的附图。虽然本发明是结合这些实施例进行描述的，但本发明不限于任何实施例。本发明的范围仅由权利要求书限制，并且本发明包括许多替代方案、修改和等同方案。以下描述中阐述了许多具体细节，以便透彻地理解本发明。提供这些细节是为了举例的目的，并且本发明可以在没有部分或者所有这些具体细节的情况下根据权利要求书进行实践。为清楚起见，没有详细描述与本发明有关的技术领域中已知的技术资料，以免对本发明产生不必要的混淆。

以下详细描述中阐述了许多具体细节，以便透彻地理解本发明。但是，本领域的技术人员应理解，在没有这些特定细节的情况下，依然可以实践本发明。在其它情况下，没有详细描述公知的方法、过程、组件、模块、单元和/或电路，以免混淆本发明。

尽管本发明的实施例在这方面不受限制，但使用“处理”、“计算(computing/calculating)”、“确定”、“建立”、“分析”、“检查”等术语进行的讨论，可以指计算机、计算平台、计算系统或其它电子计算设备的一个或多个操作和/或过程，该一个或多个操作和/或过程将数据(该数据表示为计算机寄存器和/或存储器内的物理(例如，电子)量)操纵和/或转换成其它数据，该其它数据类似地表示为计算机寄存器和/或存储器或可以存储指令以执行操作和/或过程的其它信息非瞬时性存储介质内的物理量。

尽管本发明的实施例在这方面不受限制，但本文使用的术语“多个”可以包括“多个”或“两个或两个以上”等。术语“多个”可以在整个说明书中用于描述两个或两个以上组件、设备、元件、单元、参数等。除非明确说明，否则本文中描述的方法实施例不限于特定的顺序。此外，所描述的方法实施例或其元素中的一些可以在同一时间点同时发生或执行。

本发明涉及的方案能够支持两个活动集群，并通过使用数据记录的同步复制提供强一致性，以实现高读取和写入可用性。根据本发明，同步复制是通过分区级协调锁实现的。

图3示出了本发明的指导提供的双活集群架构及其组件的概述。集群通常指一组计算机系统(也称为节点/服务器)，这些系统被连接或相互连接以紧密地在一起运行，从而在许多方面它们构成了单台计算机。HBase等分布式数据库系统可以支持多活集群。一些应用需要保证读取速度，以避免在出现网络或磁盘问题时读取性能出现间歇性峰值，针对这些应用，多集群架构是一种常见的方案。它还有助于负载平衡，并作为用于灾难恢复的备份集群。当使用双活模式部署时，当第一集群不可访问时，应用可以使用其它集群作为回退，这使得集群具有高可用性。图3示出了集群1和集群2，两者相互双活配合，即两个集群可以支持同时读取和写入。集群1和集群2可以是分布式数据库系统的一部分。在一个这样的实现方式中，分布式数据库系统是HBase。在另一种实现方式中，本申请的技术方案可以用于分布式数据库系统，该分布式数据库系统能够对表进行分区，并采用WAL文件对目标集群中的表数据进行同步和恢复。在下文中，集群1也称为“第一集群”、“第一活动集群”或“源集群”，集群2也称为“第二集群”、“第二活动集群”、“宿集群”或“目的集群”。

如参考图1所解释的，典型的HBase集群可以包括一个或多个区域服务器，每个区域服务器服务于一组区域，并且区域可以仅由一个区域服务器服务。图3中的集群1相对于一个区域服务器(也称为第一区域服务器)示出，在所示示例中，该区域服务器托管由HBase集群管理的表的区域。第一区域服务器处理来自客户端托管的应用的读请求和写请求。第一区域服务器包括对应的内存存储和WAL，也可以分别称为第一存储器和第一WAL。此外，第一区域服务器还包括事务状态日志，以下参考第一集群的第一区域服务器称为“第一事务状态日志”。此外，第一区域服务器还包括健康传感器。数据I/O操作(例如写命令)从集群1的第一区域服务器到集群2的对应区域服务器(称为“第二区域服务器”)的复制由第一区域服务器的复制管理器管理。复制管理器还管理第一区域服务器的健康传感器。

类似于集群1(即第一集群)，集群2(即第二集群)如图3所示，其与第一集群以双活操作方式工作。类似于集群1，图3中的集群2相对于一个区域服务器(也称为第二区域服务器)示出，在所示示例中，该区域服务器托管也由集群1的第一区域服务器托管的表的区域。第二区域服务器可以支持与第一区域服务器同时读取和写入。第二区域服务器拥有对应的内存存储、WAL、事务状态日志和对应的健康传感器。为便于引用，与第二区域服务器对应，将第二区域服务器的组件分别称为第二WAL、第二存储器、第二事务状态日志和第二健康传感器。此外，第二区域服务器还包括行复制写(sink)和自动恢复处理程序，这在前面的描述中进行更详细的解释。

需要说明的是，集群2使用与集群1相同的机制进行写入。为简单起见，仅描述一个操作。类似地，集群1使用与集群2相同的机制进行读取，在集群2中接收到的相应区域的读命令从托管对应区域的第二区域服务器的持久存储文件中读取。

根据本发明的实施例，两个集群，即集群1和集群2可以并行写入数据，并且可以从任何集群中执行读取，结果彼此高度一致。当一个集群宕机时，另一集群支持读取和写入。

根据本发明的实施例，两个集群之间的写入冲突通过使用协调分区级锁定机制来管理。

根据本发明的实施例，在查询结果中不考虑在任何集群中失败的写入。

根据本发明的实施例，集群的健康状况被监控，并且可以自动切换到本地写入或同步写入模式。此外，在不健康的集群上可能会禁用读取和写入。

根据本发明的实施例，基于最后同步点恢复崩溃的集群。

本发明提供了一种用于第一集群至第二集群的同步数据复制的方法。所述第一集群和所述第二集群相互双活配合工作。图4示出了本实施例提供的同步数据复制方法。第一集群包括集群1，第二集群包括集群2，如图3所示。

在步骤402中，第一集群(即集群1)的第一区域服务器从客户端服务器接收写命令。客户端服务器可以托管应用，类似于图3中的描述。参考图3，写命令从第一区域服务器复制到第二区域服务器，其中，第二区域服务器中的行复制写处理复制机制。具体地，在步骤402中，第一区域服务器在第二集群的第二区域服务器中复制接收到的写命令。在此处，复制步骤包括：第二区域服务器在第二区域服务器的第二预写日志(write ahead log，WAL)中提交与写命令相关联的记录，在将记录提交到第二WAL之后，第二区域服务器将记录提交到第二区域服务器的第二存储器中。涉及将写命令提交到第二WAL和第二存储器的复制步骤由行复制写处理。

在第二区域服务器中提交写命令后，在步骤404中，第一区域服务器将与写命令相关联的记录提交到第一区域服务器的第一WAL，在将记录提交到第一WAL之后，将记录提交到第一区域服务器的第一存储器。根据本发明的指导，写操作首先在远程集群(即第二集群)中执行，然后在本地集群(即第一集群)中执行。即，在第一阶段在远程集群中提交之后，本地集群中的提交是在第二阶段完成的。

根据本发明的特定实施例，在第一区域服务器和第二区域服务器上维护与接收到的写命令相关联的数据记录的事务状态。第一区域服务器的事务日志(也称为第一事务日志)用于维护正在第一WAL和第一存储器中提交的数据记录的事务状态，第二区域服务器的事务日志(也称为第二事务日志)用于维护正在第二WAL和第二存储器中提交的数据记录的事务状态。作为示例，图5a示出了WAL序列识别号(ID)，所述WAL序列识别号与顺序数据记录对应，所述顺序数据记录写入区域服务器中的本地WAL，所述区域服务器接收由该区域服务器托管的区域的写命令。示例中的WAL可以包括图4和图3中提及的第一区域服务器的第一WAL，本文的WAL还可以包括图4和图3中提及的第二区域服务器的第二WAL。WAL中的每个条目(即由对应的序列ID(在图5a的示例中为1、2、3、4、5)识别的条目)在同一区域服务器的本地事务日志中具有一个或多个对应的条目。即，第一区域服务器的第一WAL中的条目将在第一区域服务器的第一事务日志中具有一个或多个对应的条目，第二区域服务器的第二WAL中的条目将在第二区域服务器的第二事务日志中具有一个或多个对应的条目。事务日志中的条目在下文中称为事务状态，因为这些条目指示了正在提交给WAL的数据记录的状态/进度。为了便于参考，可以将第一事务日志的条目称为第一事务状态，将第二事务日志的条目称为第二事务状态。事务状态为以下三种类型之一：进行中、成功、失败/超时，其中，进行中状态指示记录尚未提交到WAL，成功状态指示记录成功提交到WAL，超时/失败状态指示记录未能提交到WAL。WAL中的每个记录条目在事务日志中可能有至少两个事务状态，最后更新的条目被认为是记录的最新事务状态。参考图5a的示例，序列ID为1的记录最初在事务日志中具有进行中状态，一旦成功提交到WAL，该状态随后在事务日志中更新为成功。序列ID为1的记录的最后更新的条目(即成功)将被视为该记录的最新事务状态。对于WAL中的序列ID为3的另一条记录，有三种事务状态：进行中、成功、超时/失败。在这种情况下，尽管在该区域服务器的WAL中成功提交记录(序列ID为3)，但在第二集群的第二区域服务器的本地WAL中提交将会失败。因此，事务日志中的事务状态被再次更新为失败/超时，从而反映在本地提交时提交失败。事务日志中的最后一个条目始终被视为最新事务状态。所有本地超时记录都会报告到远程集群，以便也纠正远程存储器中的状态。为此，根据本发明的实施例，只有在本地集群提交成功时，在远程集群的本地存储器中提交记录才会成功，从而在远程集群与本地集群之间的同步复制模式期间保持强一致性。

图6示出了图4所示的方法的另一实施例。具体地，图6公开的方法包括：在第二区域服务器中复制接收到的写命令期间，在第二区域服务器中提交记录，参考图4示出和解释。将记录提交到第二区域服务器的第二存储器的步骤包括：在图6的步骤602处，第二区域服务器在第二区域服务器中维护的第二事务日志中更新记录的第二事务状态。此处使用的术语“第二”表示事务日志属于第二区域服务器，事务状态属于该第二事务日志的条目。如上文关于图5a所解释的，第二事务状态指示第二区域服务器中的记录的以下当前状态中的至少一个状态：

-进行中状态；

-成功状态

-超时/失败状态；

进行中状态指示记录尚未提交到第二WAL，成功状态指示记录成功提交到第二WAL，超时/失败状态指示记录未能提交到第二WAL。每个记录在第二事务日志中具有至少两个第二事务状态。记录的最后更新的条目是第二事务日志中指示记录的最新事务状态的最后条目。

此外，在步骤604处，第二区域服务器向第一区域服务器发送记录的最新事务状态。

在步骤606处，第一区域服务器从第二区域服务器接收记录的最新第二事务状态。

在步骤608处，当从第二区域服务器接收到的记录的最新第二事务状态为成功时，第一区域服务器可以在第一区域服务器的第一存储器中提交记录。

在一个实施例中，仅当从第二区域接收到的记录的最新第二事务状态为成功时，第一区域服务器才可以在第一存储器中提交记录。在另一实施例中，第一区域服务器可能已经在第一存储器中提交了记录，并且随后，可以接收从第二区域接收到的记录的为失败/超时的最新第二事务状态。这是图5a的示例中示出的场景。因此，第一事务日志中的事务状态被再次更新为失败/超时，从而反映在本地提交时记录的提交失败。

根据图4所示的方法的另一实施例，包括在第一区域服务器中提交记录的方法包括：第一区域服务器更新在第一区域服务器中维护的第一事务日志中的记录的第一事务状态。此处使用的术语“第一”表示事务日志属于第一区域服务器，事务状态属于该第一事务日志的条目。如上文关于图5a所解释的，第一事务状态指示第一区域服务器中的记录的当前状态中的至少一个状态。

在本实施例中，第一区域服务器和第二区域服务器分别维护本地事务日志、第一事务日志和第二事务日志。所有本地超时都会报告给远程集群，以便也纠正远程集群中的事务状态，从而也纠正远程内存中的事务状态。

在另一示例中，考虑以下场景：第二区域服务器已经将记录提交到第二存储器，从而将第二事务状态更新为“成功”。但是，第一区域服务器的第一事务日志中的记录的最新第一事务状态为“超时/失败”。第一区域服务器向第二区域服务器发送记录的最新第一事务状态。第二区域服务器接收到记录的最新第一事务状态后，第二区域服务器检测记录的第一事务状态是超时/失败状态。在检测到时，与第一区域服务器相同，第二区域服务器再次更新第二区域服务器中的记录的第二事务状态，以在第二区域服务器中反映超时/失败状态。因此，第二存储器中的记录也必须被更新，以反映与事务日志的事务状态对应的超时/失败状态。在本示例中采取的场景中，第二区域服务器最初已经将记录提交到第二存储器。但是，随着记录的第二事务状态再次更新，第二存储器可能不得不使其第二存储器中的记录失效或超时。

根据其它实施例，公开了一种在第二区域服务器的文件存储中重写文件的方法。作为示例，以上面讨论的相同场景为例，即第二区域服务器最初已经将记录提交到第二存储器，然后将记录的第二事务状态再次更新为失败/超时状态，在这种场景下，可能记录已经从第二存储器刷新到第二区域服务器的文件存储(HFile)(称为第二文件存储)。根据本发明的一种实现方式，如果记录已经从第二存储器刷新到第二文件区域的第二文件存储，并且记录的超时/失败状态被检测为第二文件区域中的最新第一事务状态，则第二区域服务器重写第二文件存储中的文件，以便从第二区域服务器中删除记录的所有事务。在本文中，记录的事务涉及与写命令对应的所有事务，所述写命令在第一区域服务器中接收并在第二区域服务器中被复制。因此，根据本发明的实施例，与在第一区域服务器中接收到的写命令对应的记录被同时提交到第一区域服务器的第一存储器和第二区域服务器的第二存储器；如果与写命令对应的记录在第一区域服务器和第二区域服务器中的任一个区域服务器中提交失败，则在第一集群和第二集群中的任一个集群中接收到的后续读操作或搜索查询不考虑所述记录。为此，参考图5b的说明。第一区域服务器包括内存存储“Mem Store”，(也称为第一存储器)和文件存储(Hfile)(还称为第一文件存储)。在第一存储器中，根据对应的事务日志中的条目更新所有记录的事务状态。当从内存中查询记录时，或将记录从内存刷新到HFile时，只考虑成功的事务，即内存中具有成功事务状态的记录。在图5a、图5b的示例中，颜色编码可以用于指代不同类型的事务状态。在图5b中，绿色可以与成功状态对应，黄色可以与进行中状态对应，红色可以称为失败/超时状态。以颜色编码为例，事务ID为3的记录的最新事务状态为失败/超时。如图5b的示例所示，扫描器用于扫描第一区域服务器的Mem Store的记录，并且仅从Mem Store读取或刷新成功的事务，即事务ID为1和4的绿色编码记录。根据本发明的一种实现方式，扫描器(查询扫描器)是第一区域服务器的组件。但是，在另一实施例中，扫描器可以位于第一区域服务器(例如HMaster)之外。将事务ID为3的失败/超时记录的事务状态报告给远程集群，以便也纠正远程存储器中的状态。考虑到事务ID为3的对应记录已经从远程区域服务器的Mem Store刷新到第二文件存储，根据本发明的实施例，远程区域服务器重写其文件存储中的文件以移除事务ID为3的记录的事务。通过本发明的一种实现方式，由远程区域服务器实现修复机制。如图5b所示，在远程区域中实现了HFile修复定时任务(Repair Chore)，HFile修复定时任务将重写具有无效事务的文件，在本示例中，无效事务是事务ID 3。如图5所示，最初远程区域中的HFile具有序列顺序为1、3和4的成功事务，这些事务最初在远程区域中的内存事务中是成功的。在接收到无效事务ID 3的报告后，HFile修复定时任务在后台修复文件，从文件中移除事务ID 3的事务，接着会在远程区域中看到具有序列顺序为1和4的成功事务的HFile，其中3被移除。为此，将与在第一区域服务器中接收到的写命令对应的记录同时提交到第一区域服务器的第一存储器和第二区域服务器的第二存储器。如果与写命令对应的记录在第一区域服务器和第二区域服务器中的任一个区域服务器中提交失败，则在第一集群和第二集群中的任一个集群中接收到的后续读操作或搜索查询不考虑所述记录。

鉴于本发明的又一实施例，将记录同时提交到第一区域服务器的第一存储器和第二区域服务器的第二存储器的方法包括：第一集群和第二集群的协调行锁管理。根据本发明的另一实施例，在第一集群和第二集群中传入事务/写命令存在冲突时，第一个到达的事务被赋予优先级，而另一个到达的事务排下一个。

根据本发明的具体实施例，将记录同时提交到第一区域服务器的第一存储器和第二区域服务器的第二存储器的方法包括：第一区域服务器锁定第一行，第一行属于第一区域服务器托管的区域，并且第一行与在第一区域服务器中接收的写命令对应。第一区域服务器将接收到的写命令复制到第二区域服务器。作为示例，参考图7(稍后描述)。当在集群1的第一区域服务器中获取与行＝100对应的写命令时，在集群1的区域服务器中锁定行100，并将事务发送到集群2的第二区域服务器的行复制写处理程序7A进行复制。此外，所述方法包括：第二区域服务器锁定第二行，所述第二行属于第二区域服务器托管的区域，第二行与在第二区域服务器中复制的写命令对应。在本文中，在术语“行”之前使用的术语“第二”意味着该行属于由集群2的第二区域服务器托管的区域。应当理解，第一行与第二行相同。参考图7的示例，在为集群1的第一区域服务器中的TX1(写命令)锁定行100时，为集群2的第二区域服务器中的TX1(复制)锁定行100。此外，当对第二行的锁定成功时，所述方法还包括：第二区域服务器将记录提交到第二WAL中和第一区域服务器将记录提交到第一WAL中并行执行。

根据本发明的一种实现方式，通过在本地(第一集群)上锁定行、在远程集群(第二集群)中写入以及随后在本地集群中写入来执行写操作。此外，提交到WAL和内存是第二阶段，首先在远程集群中，然后在本地集群中。当发生冲突时，确保第一个到达的事务被赋予优先级，另一个到达的事务排下一个。这可以使用时间戳来完成。如果事务时间戳也发生冲突，则可以选择哈希算法来决定冲突解决(最小对端ID)。根据本发明的另一种实现方式，一旦远程锁也成功，两个集群中的写入(WAL，Memstore写入)可以并行完成。对于失败/超时记录，如果在远程锁定期间发生超时，将通过检查远程过程调用(remote procedure call，RPC)将提交与另一事务状态进行同步。根据本实现方式，锁协调对于区域是局部的，因此事务管理是分布式的。这样做的优点是，不存在如全局事务管理和锁争用等瓶颈。

根据本发明的一个实施例，在两个集群之间使用协调锁的事务管理可以处于单行级别。根据本发明的另一实施例，在两个集群之间使用协调锁的事务管理可以处于批处理级别，该批处理级别可以是原子或非原子的。

在单行锁管理的一个这样的实现方式中，所述方法包括：确定另一事务是否更早到达第二集群中，即在第一集群中接收到的写命令之前到达。在这种情况下，单行锁会在集群2中重试。作为示例，客户端服务器可以为相应的事务1和事务2生成时间戳ts1、ts2，其中，事务1与在集群1中接收的写命令对应，而事务2与在集群2中接收的另一写命令对应。在冲突时，区域服务器可以选择t＝min{ts1,ts2}的Tx。在其它示例中，可以选择哈希协议或可插拔冲突解决协议。在单行锁场景的一个具体实施例中，图4所示的实现方式的方法还可以包括：从第二集群的第二区域服务器中的另一客户端服务器接收另一写命令，所述另一写命令也与记录相关联，所述记录与在第一服务器区域中接收的写命令相关联。在此实现方式中，事务2可以从另一客户端服务器到达第二集群的第二区域服务器，并且可以具有时间戳ts2。此外，第二区域服务器确定哪些事务(即，第一写命令或第二写命令)到达了第二区域服务器。例如，第二区域服务器确定来自另一客户端服务器的写命令是否晚于来自第一区域服务器中的客户端服务器的写命令到达第二区域服务器。根据本发明的实现方式，确定通过以下机制中的至少一种执行：

-第二区域服务器检查与写命令相关联的事务时间戳和与另一写命令相关联的事务时间戳；

-第二区域服务器对从第一客户端服务器接收的写命令和从第二客户端服务器接收的另一写命令应用哈希协议；

-第二区域服务器对从第一客户端服务器接收的写命令和从第二客户端服务器接收的另一写命令应用可插拔冲突解决协议。

任何一种机制都可以用于确定哪个事务更早到达第二区域服务器，从而可以相应地在第二区域服务器中获取锁。

根据另一实施例，如果确定来自另一客户端服务器的另一写命令(事务2)晚于来自第一区域服务器中的客户端服务器的写命令(事务2)到达第二区域服务器，则第二区域服务器执行将与写命令(事务1)相关联的记录提交到第二WAL中的步骤，在将记录提交到第二WAL之后，执行第二区域服务器将记录(事务1)提交到第二区域服务器的第二存储器的步骤。

根据另一实施例，如果确定来自另一客户端服务器的另一写命令(事务2)在来自第一区域服务器中的客户端服务器的写命令(事务1)之前到达第二区域服务器，则在第二区域服务器中提交与写命令(事务1)相关联的记录之前，第二区域服务器执行将与另一写命令(事务2)相关联的记录提交到第二WAL中的步骤，在将记录提交到第二WAL之后，执行第二区域服务器将与另一写命令(事务2)相关联的记录提交到第二区域服务器的第二存储器的步骤。

对于单行锁管理，现在参考图7和图3所示的流程图来说明协调行锁管理的应用场景。图7所示的集群1和集群2分别包括图3所示的集群1和集群2。此外，图7所示的行复制写RPC处理程序7A包括图3的行复制写。此外，图7所示的事务状态RPC处理程序7B也被理解为集群2的第二区域服务器的组件，图3中未示出。行复制写RPC处理程序7A和事务状态RPC处理程序7B的作用应在前面的描述中被理解。在图7的示例中，当事务(来自客户端服务器的写命令)到达集群1时，事务流在集群1中开始。在示例中，区域服务器为到达集群1的事务生成时间戳。该示例说明了具有行＝100且值为10的事务到达集群1的第一区域服务器，针对其写入时间戳＝t1/ts1。在下一步骤中，为具有时间戳＝t1/ts1的此事务生成事务ID/事务号＝TX1。第一区域服务器锁定行＝100，然后在第二集群中尝试对行＝100的锁定。复制写RPC处理程序7A从集群1接收信息，该信息包括事务号TX 1、来自集群1的锁定行＝100和事务号TX1具有时间戳ts1。集群2的第二区域服务器的复制写RPC处理程序7A尝试对行100的锁定。集群2的第二区域服务器可能具有进行中的另一事务，该另一事务具有事务号TX2以及生成的时间戳t2/ts2。第二区域服务器对行100执行尝试锁定。如果行100还没有被锁定，则在这一步骤获得锁定。但是，如果行100已经针对TX 2锁定，则第二区域服务优先选择具有较早时间戳的事务。因此，根据本发明的实施例，验证具有时间戳ts1的TX1是否<具有时间戳ts2的TX2。如果确认TX1比TX2早，则重试对行100的锁定并随后获得锁定。但是，如果具有时间戳ts2的TX2<具有时间戳ts1的TX1，则首先针对事务TX2锁定和处理行100。行已经锁定的异常处理程序向集群1的第一区域服务器报告针对事务TX2锁定了行100。因此，在远程集群中提交事务TX2之后，第二区域也将释放对行100的锁定，并重试对行100的锁定。因此，行级别的锁定在两个集群中是协调的，在有冲突的情况下，确保第一个到达的事务(使用写入时间戳)被赋予优先级，而另一事务排下一个。一旦远程锁定也成功，两个集群中的写入(WAL、Mem Store写入)可以并行完成。

如上文描述的上述实施例所述，通过在本地锁定行来执行写操作，首先在远程集群中写入，然后在本地/源集群中写入。提交在第二阶段完成，首先在远程集群中，然后在本地/源集群中。参考图7，一旦在远程集群中获得了对行100的锁定，则在远程集群中执行写操作。如果在第二区域服务器中写入的结果为成功，则在集群2中释放对行100的锁，此时在集群1的区域服务器中发起写操作。需要指出，在远程集群中写入之后的状态是“等待源确认”，这意味着远程集群等待源集群对TX1的成功事务状态确认。根据本发明所描述的实施例，提交到WAL和存储器是在使用从源(origin/source)集群接收的最新事务状态更新事务日志之后进行的。事务状态RPC处理程序7B从集群1接收记录的事务状态，并在第二区域服务器的事务日志中更新事务状态。或者，如果在第二区域服务器中写入成功的结果为失败，则释放对行100的锁定，并将失败的事务状态报告给源集群，即集群1。集群1的第一区域服务器释放对行100的锁定，在远程失败时，结束事务TX1的处理。在经过一段相当长的时间之后会再次尝试远程获取锁定的过程。

当远程写入成功并报告给集群1的第一区域服务器时，在集群1的第一区域服务器中发起对TX1的写操作。在写入之后，在第二阶段在集群1的区域服务器中完成提交，即首先在集群2完成提交。如果在集群1的第一区域服务器中执行的写操作的结果为成功，则检查在远程中TX1的事务状态是否为成功。随后，除非事务TX1超时，否则会在集群1中执行向WAL和内存存储的提交。当在集群1的区域服务器中提交时，将其报告给集群2的事务状态RPC处理程序7B，该事务状态RPC处理程序7B随后更新集群2的区域服务器中的事务日志。如果事务TX1在集群1的区域服务器中超时，则过程将结束。集群2的事务状态RPC处理程序7B将相应地在集群2的区域服务器的事务日志中更新事务TX1的事务状态。

如果在集群1的第一区域服务器中执行的写操作的结果是失败，则在集群1的区域服务器的事务日志中更新事务状态，并且还将失败状态报告给集群2的事务状态RPC处理程序7B。集群2的事务状态RPC处理程序7B将相应地在集群2的区域服务器的事务日志中更新事务TX1的事务状态。基于TX1在远程集群中的最新事务状态，将在远程集群中提交TX1或使TX1失败。

根据本发明的实施例，单行锁定管理可以扩展到批量行锁定管理。批量行锁定管理可以分为原子型和非原子型两种。与在源集群1中接收到的写命令对应的记录可以具有从客户端服务器接收到的原子批量行请求和非原子批量行请求的行批量的事务。

根据本发明的一种实现方式，图7所示的单行锁定场景可以扩展到原子批量锁定场景。所述方法可以包括：响应于客户端服务器的原子批量行请求，第一区域服务器锁定第一行且第二区域服务器锁定第二行。从客户端接收的原子批量行请求应该完成所有行插入，否则失败。因此，将尝试对客户端请求中给出的所有行进行锁定。如果由于正在进行的远程集群写入锁定而导致任何锁定行锁定不可用，将释放旧锁定并重试。一旦在两个集群中都获得了所有行锁定，则继续进行数据写入。图8a中示出了本实现方式的示例性说明，其示出了在集群1中锁定的与事务TX1(在第一区域服务器中接收到的写命令)对应的所有行都被尝试在集群2中锁定。如果有任何行锁定不可用，例如针对集群2中的锁定没有获得忙碌行Ri、Rj(例如，分别被事务TXa、TXb占据)，则集群1的第一区域服务器将不得不释放最初针对集群1中的事务TX1获得的所有锁定。集群1的第一区域服务器将等待TXa、TXb最终完成，并且在集群1中重试针对与事务TX1对应的所有行获取锁定，然后在集群2中再次尝试。

根据本发明的一种实现方式，图7所示的单行锁定场景可以扩展到非原子批量锁定场景。响应于客户端服务器的非原子批量行请求，所述方法包括：第一区域服务器锁定第一行批量，第一行的第一批量属于第一区域服务器托管的区域，并且第一行批量与在第一区域服务器中接收的写命令对应。参考图8b中所示的关于非原子批量行锁定管理的示例性流程图。作为第一步骤，集群1的第一区域服务器锁定第一行批量。此外，在获取第一行批量的锁定时，从图7可以理解，集群1的第一区域服务器在第二区域服务器中复制接收到的写命令。第二区域服务器尝试锁定第二行批量，所述第二行批量属于第二区域服务器托管的区域，并且第二行批量与在第二区域服务器中复制的写命令对应。应当理解，本文使用的术语“第一”和“第二”是指由第一区域服务器处理的行批量和由第二区域服务器处理的行批量，但是，第一行批量分别与在集群1中的第一区域服务器和集群2中的第二区域服务器中尝试锁定的第二行批量相同。在非原子批量行管理中，第二区域服务器尝试针对第二行批量获取锁定。但是，有些行可能已经针对集群2中的其它事务被锁定。在这种情况下，第二区域服务器获取第二行批量的至少第一子集的锁定(SubBatch 1＝OK)，而未能获取第二行批量的第二子集的锁定(SubBatch2＝NOK)。在此处，第二行批量的第一子集包括可用于锁定的行，第二行批量的第二子集包括不可用于锁定的行。在获取第二行批量的第一子集的锁定并且未能获取第二行批量的第二子集的锁定时，集群2的第二区域服务器对此向集群1的第一区域服务器报告。第一区域服务器释放第一行批量的第一子集的锁定，第一行批量的第一子集与第二区域服务器中的第二行批量的第一子集对应。参考图8b中所示的示例，其中，流程表明，在集群1中，SubBatch 2上的锁定被释放，SubBatch 1的突变继续，如参考图7所述。因此，所述方法包括：并行执行第二区域服务器将记录提交到第二WAL中以及第一区域服务器将记录提交到第一WAL中，其中，第二区域服务器的提交步骤是对第二行批量的第一子集执行的，第一区域服务器的提交步骤是对第一行批量的第一子集执行的。同样，第一区域服务器获取第一行批量的第二子集的锁定，第一行批量的第二子集的锁定先前在远程集群中获取失败。此外，在获取集群1中的第一行批量的第二子集的锁定时，第二区域服务器再次尝试获取第二行批量的第二子集的锁定。如图8b所示，在锁定第一集群中的SubBatch 2以及可能的下一行批量时，在集群2中尝试下一个可能的小批量锁。该过程继续，以便执行并行提交步骤，所述并行提交步骤是并行执行第二区域服务器针对第二行批量的第二子集将记录提交到第二WAL中以及第一区域服务器针对第一行批量的第二子集将记录提交到第一WAL中。

根据本发明的其它实施例，公开了根据本发明实现的服务器崩溃过程。在灾难期间，如果其中一个区域服务器(例如集群1的第一区域服务器)发生故障，则主服务器根据本发明的指导实现服务器崩溃过程。在描述本发明的实施例时，图2a的描述并入本文以供参考。根据本发明的一种实现方式，有故障区域服务器的文件被恢复并刷新到集群中的另一区域服务器。为了从有故障区域服务器(例如，第一集群中的第一区域服务器)中恢复文件，所述方法包括：在主服务器中调用服务器崩溃恢复过程，所述主服务器管理第一集群中的区域的分配，并相应地管理由第一区域服务器托管的区域的分配。在主服务器中调用服务器崩溃恢复过程时，所述方法还包括：主服务器识别一个或多个WAL，所述一个或多个WAL属于第一区域服务器；主服务器将来自一个或多个WAL中的每个WAL的记录的恢复分配给第一集群的其它区域服务器。图2a的描述描述WAL拆分器和分配区域的步骤，通过引用并入本文。分配的区域服务器从第一区域服务器的一个或多个WAL中的一个WAL中收集记录。分配的区域服务器拆分来自该WAL的记录，以根据WAL中记录可用的对应区域来隔离记录。此外，分配的区域为每组隔离的记录创建编辑文件(即，为按区域拆分的每组或记录创建编辑文件)。此外，分配的区域服务器为分配的区域服务器所创建的每个编辑文件创建事务日志文件。在图2b所示的现有技术恢复机制中，WAL拆分器创建事务日志文件无法应用。为编辑文件创建的事务日志文件用于在分配的区域服务器的对应的事务日志中加载该编辑文件的记录的事务状态。因此，分配的区域服务器在内存中加载分配给该区域服务器的区域的编辑文件，在内存中还加载编辑文件的每个记录的事务状态。这由该分配区域的打开区域处理程序在处理过程中进行处理。分配的区域服务器将编辑文件本地写入分配的其它区域服务器的对应存储器中，所述编辑文件与一个区域(被分配给该区域服务器)对应。此外，分配的区域服务器将编辑文件的事务日志文件加载到分配的其它区域服务器的对应的事务日志中。来自编辑文件的每个记录的最新事务状态从与该编辑文件对应的事务日志文件中推导。最终，分配的区域服务器将内存中的编辑文件刷新到分配的区域服务器的文件存储(HFile)。在本发明的具体实现方式中，刷新包括从分配的区域服务器的内存中加载的编辑文件中检查每个记录的事务状态。具有失败/超时状态的记录不会刷新到文件存储，具有进行中状态的记录重新加载到内存中，而具有成功状态的记录刷新到分配的区域服务器的文件存储。

作为示例，现在参考图9，其描述了上述实现方式的说明。

-标记为1、2和3的流程描述了每个区域的事务日志拆分以及处理恢复时的区域编辑[1、2、3]

-标记为4的流程描述了主服务器将区域分配给集群的另一区域文件，其中，分配的区域的打开区域处理程序为分配的区域加载恢复的编辑。

-标记为5的流程描述了在区域打开期间加载恢复的编辑，并应用恢复的事务日志中的事务状态以恢复崩溃之前的原始状态

-标记为6的流程描述了使用Tx感知扫描器(与参考图5b所示和解释的类似扫描器对应)从存储器刷新到存储文件。在此处，失败的事务被忽略。

-标记为7的流程描述了将所有未提交的事务(进行中)加载回存储器。这些事务将在下一个循环中刷新到HFile。

-标记为8的流程描述了区域的最新刷新的Tx ID可以存储在主节点中，以便在下次恢复时清除复杂的Tx日志并识别起始偏移量。

主服务器将所有WAL拆分任务分组，并分配给创建此WAL文件的原始区域服务器(如果可用)。这可以通过DFS中WAL文件所在的文件夹和文件名来识别。这样可以保证WAL拆分期间的本地读取，节省网络带宽。

根据本发明的下一实施例，公开了一种监控第一集群和第二集群的健康状况的方法。具体地，根据所公开的实施例，监控第一集群和第二集群的健康状况，以便在检测到第一集群和第二集群中的任何一个出现不健康状态时，回退到单集群写入模式。在此处，第一集群和第二集群包括上文从图3至图9公开的实施例。根据一种实现方式，集群的健康状况在集群中本地监控，并报告给相应的本地zookeeper和远程zookeeper。根据另一种实现方式，集群的健康状况由本地zookeeper和远程zookeeper监控。例如，不同的集群状态如图10所示。集群1和集群2中的每一个分别包括一组第一区域服务器(RS、RS、RS)和一组第二区域服务器(也表示为RS、RS、RS)。集群1和集群2中的每一个由相应的zookeeper(ZK)管理，ZK也可以分别称为第一zookeeper和第二zookeeper。图10示出了zookeeper(ZK)管理集群2。根据本发明的实施例，集群1的健康状况由其本地zookeeper(参考10a)以及远程zookeeper(参考10b)监控。类似地，集群2的健康状况由其本地zookeeper(参考10b)以及远程zookeeper 9(参考10a)监控。为此，第一zookeeper监控第一集群的健康状况，也可以与第二zookeeper共享第一集群的健康状况的信息。同样，第二zookeeper监控第二集群的健康状况，也可以与第一zookeeper共享第二集群的健康状况的信息。第一ZK和第二ZK在各自监控的第一集群和第二集群的健康方面相互协调。此外，存在不同的集群状态，例如：

(1)本地写入：本地状态意味着，相应的集群/集群的区域服务器只允许在本地写入。

(2)活动：活动状态意味着，相应集群/集群的区域服务器也可以向远程集群写入和同步数据

(3)不健康：不健康的活动状态意味着，在恢复之前，相应的集群/集群的区域服务器无法支持读操作或写操作。

(4)恢复：恢复状态意味着，相应的集群/集群的区域服务器可以保持写入直到状态改变为活动。

参考图10，两个集群，即集群1和集群2在对等Zookeeper中相互协调状态(参考10a、10b)。集群1的第一zookeeper获取集群1的区域服务器(RS)和主服务器(Master)的状态，并相应地设置健康模式状态(我的状态)，该状态识别集群1的健康状态。10a是第一zookeeper更新的信息，所述信息包括第一集群的健康状态以及第二zookeeper通知的对等集群(集群2)的健康状态。在图10的示例中，10a信息包括对等体状态(C2)：不健康，这意味着集群2被远程集群通知为不健康。在本地集群1中，主服务器处于Up状态，区域服务器1(RS1)处于Up状态，区域服务器2(RS2)处于Down状态，区域服务器(RS3)处于Down状态。因为对等体状态为不健康，所以第一zookeeper将健康状态模式(我的模式)设置为本地。在集群2中，第二zookeeper更新的信息(10b)包括第二集群的健康状态以及第一zookeeper通知的对等集群(集群1)的健康状态。在图10的示例中，10b信息包括对等体状态(C1)：活动，这意味着集群1被远程集群通知为活动。在本地集群2中，主服务器处于Up状态，区域服务器1(RS1)处于Up状态，区域服务器2(RS2)处于Up状态，区域服务器(RS3)处于Down状态。由于第二集群2可能正在恢复，所以第一个zookeeper将健康状态模式(我的模式)设置为不健康。

在上面的示例中，在写入期间，如果与远程区域服务器的通信失败，则在集群中验证本地状态。根据集群的健康状态，相应集群中的写操作/读操作可以根据以下场景之一执行：

如果不健康：拒绝读/写

如果本地模式：忽略并继续进行本地写入

如果同步模式(在本地集群与远程集群之间复制)：检查ZK中的对等体状态

--如果对等体不健康：回退到本地模式[更新ZK中的状态]

--如果对等体是活动的并且RS宕机：基于超时重试和拒绝

--如果对等体正在恢复：等待状态更改为活动。

鉴于上述实施例，当根据第一ZK确定第一区域服务器具有不健康状态时，第一区域服务器拒绝来自客户端服务器的写命令。

鉴于上述实施例，当根据第一ZK确定第一区域服务器具有本地健康状态时，第一区域服务器在第一WAL和第一存储器中提交写命令，并停止向第二集群的第二区域服务器的复制。

鉴于上述实施例，当根据第二ZK确定第二区域服务器具有恢复中的健康状态时，第一区域服务器停止向第二集群的第二区域服务器的复制。

鉴于上述实施例，当根据第一ZK确定第一区域服务器具有活动的健康状态且根据第二ZK确定第二区域服务器具有活动的健康状态时，第一区域服务器执行写命令的提交以及向第二集群的第二区域服务器的复制。

根据本发明的下一实施例，公开了一种用于在故障转移之后自动恢复集群的方法。具体地，根据本发明的实施例，所述方法包括将恢复中的集群设置回与活动集群的同步复制。现在参考图11，示出了根据本发明将恢复中的集群设置回与活动集群同步模式的示例。在图11的示例中，假设集群1在故障转移之后正在恢复，而集群2是当前活动集群。应当理解，集群1和集群2是指到目前为止参考图3至图7描述的第一集群和第二集群。在图11中，恢复中的集群1的主服务器协调并识别所有需要同步的表和区域。主服务器分配区域服务器来启动恢复过程，区域服务器的区域恢复处理程序触发活动集群中同步复制表的所有区域部分的MemStore刷新。基于最后同步的Tx号，从活动集群下载所有HFile并批量加载到集群1中。随后，在源集群中启用行同步，即开始事务管理并同步从现在开始的所有记录。同步开始之前写入的所有存储器记录都会被传输。一旦所有区域都同步完成，集群1的集群状态将启用为活动。

在当前实施例中，在恢复之后，当集群1启动时，无论在集群1宕机时向活动集群2写入了什么数据，该数据都必须在集群1上恢复。集群1的主服务器(HMaster)协调并识别需要同步的表和区域。具体地，HMaster可以与集群2协调，例如与集群2的ZK协调，以便识别在集群1宕机时接收到写命令的表和区域。如图11所示，集群1的HMaster从集群1中分配区域服务器，以便从集群2中恢复待同步的数据。在该示例中，假设HMaster分配第一集群的第一区域服务器，以便从集群2(为活动集群)的第二区域服务器中恢复数据。第一区域服务器包括区域恢复处理程序，用于执行如下操作：根据前面的描述，从第二区域服务器恢复数据并启用与第二区域服务器同步。在流程1中，被分配恢复操作的第一区域服务器启动恢复过程，所述恢复过程由第一区域服务器的区域恢复处理程序实现。在流程2中，区域恢复处理程序恢复第一区域服务器的事务日志(参考图11中的恢复的事务日志)，这表明在第一区域服务器的内存中提交的最后成功的事务是事务TX4。因此，用TX4识别的记录最后被刷新到第一区域服务器的文件存储(HFile)中。在流程3中，区域服务器处理程序已经识别出最后成功的事务是TX4，从活动集群(即集群2)下载最后刷新TX4后的HFile。为了从集群2下载或检索HFile，从第一区域服务器向集群2的第二区域服务器的对应内存发送刷新指令。在第二区域服务器的内存中接收到的刷新指令使内存中的记录被刷新到第二区域服务器的对应文件存储(HFile)中。第二集群的HFile在从内存刷新到第二区域服务器的文件存储之后被更新，并被复制到集群1中的第一区域服务器的文件存储。然后将如此拉取并复制到集群1中的第一区域服务器的文件存储的HFile批量加载到第一区域服务器的内存。流程4、5和6描述了在第一区域服务器的内存中批量加载HFile之后，在集群1中的第一区域服务器与集群2中的第二区域服务器之间恢复事务同步。参考图4和图5，已经详细解释了活动集群1与活动集群2之间的同步复制依赖于第一区域服务器和第二区域服务器的相应事务管理器。即，在批量加载第一区域服务器和第二区域服务器两者之后，恢复更新它们相应的事务日志，在第一区域服务器和第二区域服务器两者中提交，下载/刷新它们相应的内存数据，从而启用集群1与集群2之间的区域的同步复制，并启用集群1状态为活动。

在上述实施例中，HFile的批量加载可能意味着参考图12解释的卸载数据加载场景。基本上，活动集群1与集群2之间的同步复制可以通过向两个集群写入数据来执行，这由双集群写入器实现(流程1)，例如，在调用数据导入作业时执行。在图12所示的示例中，调用Import TSV Map Reduce Job以由双集群写入器执行双集群写入。另一种将数据写入集群的方式是离线模式，该离线模式在图12中表示为Load Incremental Files。在离线模式下，有些文件可能会被批量加载到集群中，然后这些文件可能会被直接加载到集群的区域服务器的内存。在双集群写模式下，复制是逐条记录进行的，涉及写入到WAL、写入到内存和刷新到HFile。在批量加载方式中，HFile是离线创建的，并且HFile是直接加载到集群的文件存储中的。然后，Hfile中的记录的对应区域将启动将文件从HFile加载到集群1的区域文件服务器的内存。此外，第一集群的区域服务器将向集群2的对应区域服务器发送文件的复制请求。例如，参考图12中的示例，集群2的区域服务器的行复制写从集群1接收批量加载HFile的复制。行复制写还将文件批量加载到集群2的文件存储中，然后将这些文件加载到集群2的区域服务器的内存。在离线模式下，虽然没有WAL写入，但复制WAL(即集群1的WAL)会标记一些文件已经批量加载到内存中，而不是逐个记录写入的事件。批量数据加载提交通过类似于单个写入记录(单行锁定事务管理)的行复制写同步到对等集群(集群2)，如果文件没有被双集群写入器复制，则行复制还可以注意从源集群复制文件并加载到区域。

鉴于上述实施例，参考图3、图4和图12，公开了如下方法：将第一集群的第一区域服务器设置回与第二集群的第二区域服务器同步复制，其中，第一区域服务器和第一集群具有恢复中的健康状态，第二区域服务器和第二集群具有活动的健康状态。所述方法包括：第一集群中的主服务器识别要从第二区域服务器同步到第一区域服务器的区域。主服务器向第一区域服务器分配恢复过程，用于将识别的记录从第二区域服务器同步到第一区域服务器。第一区域服务器恢复第一区域服务器的第一事务日志以识别最后成功的事务，并将文件从第二区域服务器的第二文件存储下载到第一区域服务器的第一文件存储，这些文件属于最后成功的事务之后的事务。此后，在第一文件存储中的下载文件被加载到第一区域服务器的第一存储器之后，第一区域服务器恢复同步。在恢复之前，第一区域服务器将第一存储器中的记录传输到第二区域服务器的第二存储器。在同步之后，第一区域服务器将从第一区域服务器中的客户端服务器接收到的写命令复制到第二区域服务器。

根据一种实现方式，将文件从第二文件存储下载到第一文件存储的步骤包括：第一区域服务器触发将记录从第二存储器刷新到第二区域服务器中的第二文件存储，所述记录属于第一集群中的主服务器所识别的区域。第二区域服务器接收到触发指令后，将记录刷新到第二文件存储。在所述刷新后，在第二区域服务器中刷新时，第一区域服务器将文件从第二文件存储复制到第一文件存储。

根据一种实现方式，第一区域服务器复制包括：第一区域服务器将文件从第一文件存储批量加载到第一存储器。

根据本发明的另一实施例，公开了一种用于同步数据复制的系统。所述系统包括第一集群和第二集群。在本发明的当前公开的实现方式中，第一集群和第二集群包括参考图3描述的第一集群(集群1)和第二集群(集群2)。因此，所公开的系统执行参考图4至图12所公开的本发明。下文参考集群1和集群2来解释该系统，集群1和集群2中包括上文详细解释的所有要素和特征。

作为示例，图13示出了本发明的实施例提供的系统1300。系统1300包括第一集群(集群1)和第二集群(集群2)。第一集群包括第一区域服务器1300A。应当理解，尽管系统描绘了包括在第一集群中的单个区域服务器1300A，但第一集群可以包括多个第一区域服务器，如图1所示。第一区域服务器1300A包括第一存储器1302A(也称为“Mem Store”)、第一预写日志(write ahead log，WAL)1304和第一文件存储1306A(也称为HFile/持久存储文件)。同样，第二集群1300B包括第二存储器1302B、第二WAL 1304B和第二文件存储1306B。所述第一集群和所述第二集群相互双活配合工作。根据本发明的实施例，第一区域服务器1300A用于将写命令复制到第二区域服务器1300B。

根据一种实现方式，第一区域服务器1300A用于从客户端服务器接收写命令。客户端服务器未在图13中示出，但可以理解为托管类似于图3所示的应用，该应用向集群1和集群2发送读命令和写命令。此外，第一区域服务器1300A在第二区域服务器1300B中复制写命令。此外，第二区域服务器1300B用于在第二区域服务器中复制接收到的写命令。复制步骤包括：第二区域服务器1300B将与写命令相关联的记录提交到第二WAL 1304B中，在将记录提交到第二WAL 1304B之后，第二区域服务器1300B将记录提交到第二存储器1302B。此外，第一区域服务器1300A将与写命令相关联的记录提交到第一WAL 1304A，在将记录提交到第一WAL 1304A之后，将记录提交到第一区域服务器1300A的第一存储器1302A。第一区域服务器1300A可以在第二阶段提交记录，即首先在远程集群中完成提交，然后才在本地集群中完成提交。在另一种实现方式中，第一区域服务器将与在第一区域服务器1300A中接收的写命令对应的记录同时提交到第一区域服务器的第一存储器1304A和第二区域服务器1300B的第二存储器1304B，如参考图7所详细解释的。

作为示例，图14示出了本发明的另一实施例提供的系统1300。系统1300包括图13所示的系统1300的组件。此外，第一区域服务器1300A包括第一事务日志1308A，第二区域服务器1300B包括第二事务日志1308B。第一事务日志1308A和第二事务日志1308B分别包括上文参考图3进行解释的第一事务日志和第二事务日志。第二区域服务器用于更新第二事务日志1308B中的记录的第二事务状态。第二事务状态指示第二区域服务器中的记录的以下当前状态中的至少一个状态：进行中状态、成功状态和超时/失败状态；其中，进行中状态指示记录尚未提交到第二WAL 1304B，成功状态指示记录成功提交到第二WAL 1304B，并且超时/失败状态指示记录未能提交到第二WAL 1304B；每个记录在第二事务日志1304B中具有至少两个第二事务状态，最后更新的条目被认为是记录的最新第二事务状态。此外，第二区域服务器1300B用于向第一区域服务器1300A发送第二事务日志中的记录的最新第二事务状态。第一区域服务器1300A用于从第二区域服务器1300B接收记录的最新第二事务状态。第一区域服务器1300A用于：当接收到的最新第二事务状态是成功状态时，将记录提交到第一存储器1302A中。

在另一示例中，参考图14，第一区域服务器1300A用于在第一事务日志中更新记录的第一事务状态，第一事务状态指示第一区域服务器中的记录的以下当前状态中的至少一个状态：进行中状态、成功状态和超时/失败状态；其中，进行中状态指示记录尚未提交到第一WAL 1304A，成功状态指示记录成功提交到第一WAL 1304A，并且超时/失败状态指示记录未能提交到第一WAL 1304A。每个记录在第一事务日志1308A中具有至少两个事务状态，最后更新的条目被认为是记录的最新第一事务状态。

在另一示例中，第一区域服务器1300A用于向第二区域服务器1300B发送记录的最新第一事务状态。第二区域服务器1300B用于接收记录的最新第一事务状态，并检测到记录的第一事务状态是超时/失败状态。在检测到时，第二区域服务器1300B用于在第二事务日志中再次更新记录的对应的第二事务状态，以在第二区域服务器中指示超时/失败状态；第二区域服务器1300B用于更新第二存储器1302B中的记录，以反映记录的超时/失败状态。

在另一示例中，如果记录已从第二存储器1302B刷新到第二区域服务器1300B的第二文件存储1306B，并且记录的超时/失败状态被作为第二区域服务器1300B中的最新第一事务状态接收，则第二区域服务器用于重写第二文件存储1306B中的文件，以移除与写命令对应的记录的事务。

在另一示例中，将与在第一区域服务器1300A中接收到的写命令对应的记录同时提交到第一区域服务器1300A的第一存储器1302A和第二区域服务器1300B的第二存储器1302B。如果与写命令对应的记录在第一区域服务器1300A和第二区域服务器1300B中的任一个区域服务器中提交失败，则在第一集群和第二集群中的任一个集群中接收到的后续读操作或搜索查询不考虑所述记录。

在又一示例中，为了将记录同时提交到第一区域服务器1300A的第一存储器1302A和第二区域服务器1300B的第二存储器1302B，第一区域服务器1300A用于锁定第一行，所述第一行属于第一区域服务器1300A托管的区域，并且第一行与在第一区域服务器1300A中接收的写命令对应。上文对图7和图8a、图8b的描述提供了对本文公开的实施例的参考。第一区域服务器1300A用于将接收到的写命令复制到第二区域服务器1300B中。第二区域服务器1300B用于锁定第二行，所述第二行属于第二区域服务器1300B托管的区域，第二行与在第二区域服务器1300B中复制的写命令对应。当对第二行的锁定成功时，第二区域服务器1300B用于将记录提交到第二WAL 1304B中，第一区域服务器1300B用于将记录提交到第一WAL 1304A中，第二区域服务器1300B的提交与第一区域服务器1300A的提交并行执行。

在其中一种实现方式中，第一区域服务器1300A锁定第一行和第二区域服务器1300B锁定第二行是响应于客户端服务器的原子批量行请求。

在另一种实现方式中，响应于客户端服务器的非原子批量行请求，第一区域服务器1300A用于锁定第一行批量，第一行的第一批量属于第一区域服务器1300A托管的区域，并且第一行批量与在第一区域服务器1300A中接收的写命令对应。在此，结合图8的描述以供参考。此外，第一区域服务器1300A用于将接收到的写命令复制到第二区域服务器1300B中。第二区域服务器1300B用于尝试锁定第二行批量，第二行批量属于第二区域服务器1300B托管的区域，并且第二行批量与在第二区域服务器1300B中复制的写命令对应。此外，第二区域服务器用于获取第二行批量的至少第一子集的锁定，而未能获取第二行批量的第二子集的锁定。基于此，第一区域服务器1300A用于释放第一行批量的第一子集的锁定，第一行批量的第一子集与第二区域服务器中的第二行批量的第一子集对应。因此，第二区域服务器1300B用于将记录提交到第二WAL 1304B中，第二区域服务器1300B的提交步骤是对第二行批量的第一子集执行的，第一区域服务器用于将记录提交到第一WAL中，第一区域服务器的提交步骤是对第一行批量的第一子集执行的，其中，第二区域服务器的提交与第一区域服务器的提交并行执行。随后，第一区域服务器1300A用于再次锁定第一行批量的第二子集，第一行批量的第二子集与第二区域服务器中的第二行批量的第二子集对应。此外，第二区域服务器1300B用于再次尝试锁定第二行批量的第二子集，以便执行并行提交，所述并行提交是第二区域服务器1300B针对第二行批量的第二子集将记录提交到第二WAL 1304B中以及第一区域服务器1300A针对第一行批量的第二子集将记录提交到第一WAL 1304A中并行执行。

在另一实施例中，第二区域服务器1300B用于从另一客户端服务器接收另一写命令，所述另一写命令也与记录相关联，所述记录与在第一服务器区域1300A中接收的写命令相关联。第二区域服务器1300B用于确定来自另一客户端服务器的另一写命令是否晚于来自第一区域服务器中的客户端服务器的写命令到达第二区域服务器。在此，参考图7的描述，其描述了基于第二区域服务器中的第一个到达的事务重试锁定的本发明的实施例。从客户端服务器接收到的写命令可以理解为图7中的TX1，从另一客户端服务器接收到的另一写命令可以理解为TX2。在本实施例中，第二区域服务器1300B的确定通过以下机制中的至少一种机制来执行：

第二区域服务器1300B用于检查与写命令相关联的事务时间戳和与另一写命令相关联的事务时间戳；

第二区域服务器1300B用于对写命令和另一写命令应用哈希协议；

第二区域服务器用于对写命令和另一写命令应用可插拔冲突解决协议。

此外，第二区域服务器1300B用于执行将与写命令相关联的记录提交到第二WAL1304B中的步骤，在将记录提交到第二WAL 1304B之后，在确定来自另一客户端服务器的另一写命令晚于来自第一区域服务器1300A中的客户端服务器的写命令到达第二区域服务器1300B时，执行将记录提交到第二区域服务器1300B的第二存储器1302B的步骤。

或者，在确定来自另一客户端服务器的另一写命令在来自第一区域服务器中的客户端服务器的写命令之前到达第二区域服务器时，在执行将与写命令相关联的记录提交到第二WAL 1304B中的步骤之前，第二区域服务器1300B用于将与另一写命令相关联的记录提交到第二WAL 1304B中，在将记录提交到第二WAL 1304B之后，将记录提交到第二存储器1302B。

作为另一示例，图15示出了本发明的又一实施例。图15示出了系统1300，系统1300包括图13和图14所示的系统。图15的系统1300包括第一集群(集群1)和第二集群(集群2)。第一集群包括第一区域服务器1300-1A和至少一个其它区域服务器1300-2A。此外，第一集群包括主服务器1310A，所述主服务器1310A用于管理第一集群中区域的分配，并相应地管理由第一集群的第一区域服务器1300-1A和其它区域服务器1300-2A托管的区域的分配。类似地，第二集群包括第二区域服务器1300-1B和至少一个其它区域服务器1300-2B。此外，第二集群包括主服务器1310B，所述主服务器1310B用于管理第二集群中区域的分配，并相应地管理由第二集群的第二区域服务器1300-2B和其它区域服务器1300-2B托管的区域的分配。

如前所述，主服务器(在此实例中为主服务器1310A)用于调用服务器崩溃恢复过程，以从第一集群中的第一区域服务器1300-1A恢复文件，其中，第一集群包括其它区域服务器1300-2A，所述其它区域服务器1300-2A被分配从第一区域服务器1300-1A恢复文件，其它区域服务器1300-2A中的每个区域服务器包括对应的存储器、对应的WAL、对应的事务日志和对应的文件存储。在主服务器1310-A中调用服务器崩溃恢复过程时，主服务器1310-A用于：识别一个或多个WAL，所述一个或多个WAL属于正在恢复的第一区域服务器1300-1A；将来自一个或多个WAL的记录的恢复分配给第一集群的其它区域服务器1300-2A。应当理解，图15示出了一个其它区域服务器1300-2A，而可能存在未示出的其它区域服务器。例如，主服务器1310A将来自一个或多个WAL的记录的恢复分配给其它区域服务器1300-2A(也称为分配的其它区域服务器1300-2A)。第一集群中的分配的其它区域服务器1300-2A用于从第一区域服务器1300-1A的一个或多个WAL中的一个WAL中收集记录。此外，分配的其它区域服务器1300-2A用于根据WAL中记录可用的对应区域来拆分来自WAL的记录，以隔离记录；为与一个区域对应的每组隔离记录创建编辑文件，并为所创建的每个编辑文件创建事务日志文件。此外，分配的其它区域服务器1300-2A用于将编辑文件本地写入分配的其它区域服务器1300-2A的对应存储器中。在此处，编辑文件与主服务器1310A分配给分配的其它区域服务器1300-2A的一个区域对应。此外，分配的其它区域服务器1300-2A用于将编辑文件的对应的事务日志文件加载到分配的其它区域服务器1300-2A的对应的事务日志中，其中，从加载的事务日志文件恢复来自编辑文件的每个记录的最新事务状态。如上文参考图9详细解释的，分配的区域服务器1300-2A检查来自编辑文件的每个记录的事务状态，基于来自编辑文件的每个记录的事务状态将编辑文件刷新到分配的其它区域服务器1300-2A的对应文件存储，其中，事务状态指示失败/超时状态的记录不被刷新，事务状态指示进行中状态的记录被重新加载，并且事务状态指示成功状态的记录被刷新到对应的文件存储。

作为另一示例，图13至图15中公开的系统还可以包括与第一集群对应的第一zookeeper(ZK)和与第二集群对应的第二zookeeper(ZK)。在此处，参考图10，讨论了与第一ZK和第二ZK相关的实施例。至少包括第一区域服务器1300A的第一集群的健康状况由第一ZK监控，包括第二区域服务器1300B的第二集群的健康状况由第二ZK监控，此外，第一ZK也维护第二集群的健康状况的信息，第二ZK也维护第一集群的健康状况的信息。在一种实现方式中，第一区域服务器1300A用于：当根据第一ZK确定第一区域服务器具有不健康状态时，拒绝来自客户端服务器的写命令。在另一种实现方式中，第一区域服务器1300A用于：当根据第一ZK确定第一区域服务器1300A具有本地健康状态时，在第一WAL 1304A和第一存储器1302A中提交写命令，并且用于停止复制。第一区域服务器1300A用于：当根据第二ZK确定第二区域服务器1300B具有恢复中的健康状态时，停止复制。第一区域服务器1300A用于：当根据第一ZK确定第一区域服务器1300A具有活动的健康状态且根据第二ZK确定第二区域服务器1300B具有活动的健康状态时，执行复制和提交。在当前讨论的实施例中，第一ZK和第二ZK在各自监控的第一集群和第二集群的健康方面相互协调。

在本发明的另一种实现方式中，与第一集群对应的主服务器1310A(参考图15)用于：当第一区域服务器1300A和第一集群具有恢复中的健康状态并且第二区域服务器1300B和第二集群具有活动的健康状态时，将第一集群的第一区域服务器1300A设置回与第二集群的第二区域服务器1300B同步复制。图11的描述通过引用并入本文。此外，第一区域服务器1300A和第二区域服务器1300B包括图13和图14所示的相应区域服务器的组件。主服务器1310A用于在第一集群中识别要从第二区域服务器1300B同步到第一区域服务器1300A的区域。此外，主服务器1310A用于向第一区域服务器1300A分配恢复过程，用于将识别的记录从第二区域服务器1300B同步到第一区域服务器1300A。此外，第一区域服务器1300A用于恢复第一区域服务器1300A的第一事务日志1308A以识别最后成功的事务。相应地，第一区域服务器1300A用于将文件从第二区域服务器1300B的第二文件存储1306B下载到第一区域服务器1300A的第一文件存储1306A，所述文件属于最后成功的事务之后的事务。此外，第一区域服务器1300A用于：在第一文件存储1306A中的下载文件被加载到第一区域服务器1300A的第一存储器1302A之后恢复同步，其中，在恢复之前，第一区域服务器1300A用于将第一存储器1302A中的记录传输至第二区域服务器1300B的第二存储器1302B。此外，第一区域服务器1300A用于启用将从第一区域服务器1300A中的客户端服务器接收的写命令复制到第二区域服务器1300B。

在一种实现方式中，为了将文件从第二文件存储1306B下载到第一文件存储1306A，第一区域服务器1300A用于触发将记录从第二存储器1302B刷新到第二文件存储1306B，所述记录属于第一集群中的主服务器1310A所识别的区域。因此，第二区域服务器1300B用于将记录刷新到第二文件存储1306B，并且第一区域服务器1300A用于在刷新第二区域服务器1300B中的记录时将文件从第二文件存储1306B复制到第一文件存储1306A。在另一种实现方式中，第一区域服务器1300A用于将复制的文件从第一文件存储1306A批量加载到第一存储器1302A。

图16示出了HBase集群的数据节点1600的示意图。数据节点1600可以表示第一集群的第一区域服务器、第二集群的第二区域服务器或主服务器，相应地可以是本发明的实施例提供的HBase集群的计算和/或存储节点。本领域技术人员将认识到，术语数据节点1600是为了讨论清楚的目的而包括的，但绝不意欲将本发明的应用限制到特定节点。本发明中描述的至少一些特征/方法在区域服务器中实现。例如，本发明中的特征/方法是使用硬件、固件和/或安装在硬件上运行的软件来实现的。如图16所示，数据节点1600包括收发器(Tx/Rx)1610，收发器是发送器、接收器或其组合。处理器1620耦合到Tx/Rx 1610以处理从客户端节点接收的写命令或从另一数据节点复制的写命令。处理器1610可以包括一个或多个多核处理器和/或存储器模块1630，所述存储器模块1630用作数据存储、缓冲器等。处理器1610被实现为通用处理器，或者是一个或多个专用集成电路(application specificintegrated circuit，ASIC)和/或数字信号处理器(digital signal processor，DSP)的一部分。存储器模块1630包括用于临时存储内容的缓存，例如随机存取存储器(randomaccess memory，RAM)。此外，存储器模块1630包括用于相对较长时间地存储内容的长期存储器，例如只读存储器(read only memory，ROM)。例如，缓存存储器和长期存储器包括动态随机存取存储器(dynamic random access memory，DRAM)、固态硬盘(solid-state drive，SSD)、硬盘或其组合。

应当理解，通过将可执行指令编程和/或加载到数据节点1600上，处理器1610、缓存和长期存储器中的至少一个被改变，将节点1610部分地转换为特定的机器或装置，例如，执行从第一集群到第二集群的同步数据复制，所述第一集群和第二集群相互双活配合工作，如本发明的实施例所指导的。可以通过将可执行软件加载至计算机来实现的功能可以通过公知设计规则转换成硬件实现，这在电力工程和软件工程领域是基础的。决定使用软件还是硬件来实施一个概念通常取决于对设计稳定性及待生产的单元数量的考虑，而不是从软件领域转换至硬件领域中所涉及的任何问题。通常，经常变动的设计更适于在软件中实现，因为重新编写硬件实现比重新编写软件设计成本更高。通常，大量生产的稳定设计更适于在硬件中实现，例如在ASIC中实现，因为对于大型生产运行，硬件实现比软件实现更便宜。通常，设计以软件形式开发和测试，然后通过公知设计规则将其转换为ASIC中的等效硬件实现，该硬件实现硬连接软件的指令。特定机器或装置与由新ASIC控制的机器的方式相同，同样，已经编程和/或加载有可执行指令的计算机被视为特定机器或装置。

相对于两个集群之间的现有技术复制方法，如在本发明中参考图3所解释的本发明提供了至少以下有益技术效果。

·高可用性，对任何集群的查询结果具有强一致性

·针对单集群宕机情况的即时恢复(RTO约0)

·单集群宕机不会丢失数据(RPO＝0)

·事务管理独立于客户端应用

·客户端可以读取或写入任何集群

·没有中央事务管理器。在区域级分布。

·每个表可配置的一致性级别。在异步复制与同步复制之间进行选择

·自动恢复从崩溃中恢复的集群，避免管理员复杂的手动恢复过程；

·通过差异存储文件数据传输而不是逐个记录进行，实现快速集群恢复；

·提高了可用性，即使在网络故障、磁盘慢和短期JVM暂停的情况下，也能获得一致的读取结果。

总体而言，本发明的实施例公开了用于两个集群之间的事务管理的方法、系统和装置。事务管理包括通过协调行锁定机制在两个集群之间进行单行、包括原子批量和非原子批量的批量事务管理。实施例还公开了用于扫描和刷新到HFile的内存事务状态。后台文件修复(修复定时任务)机制用于纠正乱序记录。本实施例公开了用于批量数据加载场景的事务管理，以及使用批量存储文件而不是逐个记录来在故障转移后快速恢复的自动恢复过程。

本领域技术人员可以清楚地理解，为了描述的方便和简洁，上述系统、装置和单元的具体工作过程可以参考上述方法实施例中对应的过程，本文不再赘述。

虽然本发明提供了若干个实施例，但应该理解，在不脱离本发明的范围的情况下，所公开的系统和方法可以通过其它多种具体形式体现。本发明示例应当被视为说明性而非限制性的，且意图并不限于本文所给出的详细内容。例如，各种元件或组件可以组合或集成在另一系统中，或者一些特征可以省略或不实施。

另外，在不脱离本发明范围的情况下，各种实施例中描述和说明为离散或单独的技术、系统、子系统和方法可以与其它系统、模块、技术或方法组合或集成。示出或描述为彼此耦合、或直接耦合、或彼此通信的其它项目可通过某种接口、设备或中间组件以电方式、机械方式或其它方式间接耦合或通信。变化、替换和变更的其它示例可由本领域技术人员确定，并可在不偏离本文公开的范围的情况下进行。

因此，保护范围不受上文所述的限制，而是由所附权利要求书定义，所述范围包含所附权利要求书的主题的所有等效物。每项和每条权利要求作为进一步公开的内容并入说明书中，且权利要求是本发明的实施例。本发明中的参考的论述并不是承认其为现有技术，尤其是具有在本申请案的在先申请优先权日期之后的公开日期的任何参考。

最后，选择本说明书中使用的语言主要是出于可读性和指导性，而不是记述或限制发明主题。因此，本发明的范围不由该详细描述限制，而是由本申请基于此提出的任何权利要求限制。因此，本发明的实施例的公开内容旨在为说明性的，而不是为了限制本发明的范围，本发明的范围在权利要求中提出。

Claims (34)

1.一种用于第一集群至第二集群的同步数据复制的方法，其特征在于，所述第一集群和所述第二集群相互双活配合工作，所述方法包括：

从所述第一集群的第一区域服务器中的客户端服务器接收写命令；

所述第一区域服务器在所述第二集群的第二区域服务器中复制接收到的写命令；其中，所述复制的步骤包括：所述第二区域服务器将与所述写命令相关联的记录提交到所述第二区域服务器的第二预写日志(WAL)中，在将所述记录提交到所述第二WAL之后，所述第二区域服务器将所述记录提交到所述第二区域服务器的第二存储器；以及

所述第一区域服务器将与所述写命令相关联的所述记录提交到所述第一区域服务器的第一预写日志(WAL)，在将所述记录提交到所述第一WAL之后，所述第一区域服务器将所述记录提交到所述第一区域服务器的第一存储器。

2.根据权利要求1所述的方法，其特征在于，所述第二区域服务器将所述记录提交到所述第二区域服务器的第二存储器包括：

所述第二区域服务器在第二事务日志中更新所述记录的第二事务状态，所述第二事务日志被维护在所述第二区域服务器中，所述第二事务状态指示所述第二区域服务器中的所述记录的以下当前状态中的至少一个：进行中状态、成功状态和超时/失败状态；其中，所述进行中状态指示所述记录尚未被提交到所述第二WAL，所述成功状态指示所述记录被成功提交到所述第二WAL，所述超时/失败状态指示所述记录未能被提交到所述第二WAL；每个记录在所述第二事务日志中具有至少两个第二事务状态，最后更新的条目被视为所述记录的最新第二事务状态；

所述第二区域服务器向所述第一区域服务器发送所述第二事务日志中的所述记录的所述最新第二事务状态；

所述第一区域服务器从所述第二区域服务器接收所述记录的所述最新第二事务状态；

当接收到的所述最新第二事务状态是所述成功状态时，所述第一区域服务器将所述记录提交到所述第一存储器中。

3.根据权利要求2所述的方法，其特征在于，所述第一区域服务器将所述记录提交到所述第一区域服务器的第一存储器包括：

所述第一区域服务器在第一事务日志中更新所述记录的第一事务状态，所述第一事务日志被维护在所述第一区域服务器中，所述第一事务状态指示所述第一区域服务器处的所述记录的以下当前状态中的至少一个：进行中状态、成功状态和超时/失败状态；其中，所述进行中状态指示所述记录尚未被提交到所述第一WAL，所述成功状态指示所述记录被成功提交到所述第一WAL，所述超时/失败状态指示所述记录未能被提交到所述第一WAL；每个记录在所述第一事务日志中具有至少两个事务状态，最后更新的条目被视为所述记录的最新第一事务状态。

4.根据权利要求3所述的方法，其特征在于，还包括：

所述第一区域服务器向所述第二区域服务器发送所述记录的所述最新第一事务状态；

在所述第二区域服务器处接收所述记录的所述最新第一事务状态，并且所述第二区域服务器检测到所述记录的所述第一事务状态是超时/失败状态；

响应于所述检测，所述第二区域服务器在所述第二事务日志中再次更新所述记录对应的第二事务状态，以在所述第二区域服务器中指示所述超时/失败状态；以及

所述第二区域服务器在所述第二存储器中更新所述记录，以反映所述记录的所述超时/失败状态。

5.根据权利要求4所述的方法，其特征在于，如果所述记录已从所述第二存储器刷新到所述第二区域服务器的第二文件存储器，但在所述第二区域服务器处接收到作为所述最新第一事务状态的所述记录的所述超时/失败状态，则所述方法包括：

所述第二区域服务器重写所述第二文件存储器中的文件，以移除与所述写命令对应的所述记录的事务。

6.根据权利要求1至5中任一项所述的方法，其特征在于，与所述第一区域服务器处接收到的所述写命令对应的所述记录被同时提交到所述第一区域服务器的所述第一存储器和所述第二区域服务器的所述第二存储器；如果与所述写命令对应的所述记录未能被提交到所述第一区域服务器和所述第二区域服务器中的任一个中，则所述第一集群和所述第二集群中的任一个中接收到的后续读操作或搜索查询均不考虑所述记录。

7.根据权利要求6所述的方法，其特征在于，将所述记录同时提交到所述第一区域服务器的所述第一存储器和所述第二区域服务器的所述第二存储器包括：

所述第一区域服务器锁定第一行，所述第一行属于由所述第一区域服务器托管的区域，所述第一行与所述第一区域服务器处接收的所述写命令对应；

所述第一区域服务器在所述第二区域服务器中复制接收到的写命令；

所述第二区域服务器锁定第二行，所述第二行属于由所述第二区域服务器托管的区域，所述第二行与在所述第二区域服务器处复制的所述写命令对应；以及

在所述第二行被成功锁定时，并行执行由所述第二区域服务器将所述记录提交到所述第二WAL中和由所述第一区域服务器将所述记录提交到所述第一WAL中。

8.根据权利要求7所述的方法，其特征在于，所述第一区域服务器锁定所述第一行以及所述第二区域服务器锁定所述第二行是响应于所述客户端服务器的原子批量行请求。

9.根据权利要求6所述的方法，其特征在于，响应于所述客户端服务器的非原子批量行请求，所述方法包括：

所述第一区域服务器锁定第一行批量，所述第一行批量属于由所述第一区域服务器托管的区域，所述第一行批量与所述第一区域服务器处接收的所述写命令对应；

所述第一区域服务器在所述第二区域服务器中复制接收到的写命令；

所述第二区域服务器尝试由所述第二区域服务器锁定第二行批量，所述第二行批量属于由所述第二区域服务器托管的区域，所述第二行批量与在所述第二区域服务器处复制的所述写命令对应；

所述第二区域服务器获取对所述第二行批量的至少第一子集的锁定，而未能获取对所述第二行批量的第二子集的锁定；

所述第一区域服务器释放对所述第一行批量的第一子集的锁定，所述第一行批量的第一子集与所述第二区域服务器中的所述第二行批量的第一子集对应；

并行执行由所述第二区域服务器将所述记录提交到所述第二WAL中和由所述第一区域服务器将所述记录提交到所述第一WAL中，其中，所述第二区域服务器的提交步骤是对所述第二行批量的第一子集执行的，所述第一区域服务器的提交步骤是对所述第一行批量的第一子集执行的；

所述第一区域服务器再次锁定所述第一行批量的第二子集，所述第一行批量的第二子集与所述第二区域服务器中的所述第二行批量的第二子集对应；以及

所述第二区域服务器再次尝试由所述第二区域服务器锁定所述第二行批量的第二子集，使得并行执行以下步骤：所述第二区域服务器针对所述第二行批量的第二子集将所述记录提交到所述第二WAL中，以及所述第一区域服务器针对所述第一行批量的第二子集将所述记录提交到所述第一WAL中。

10.根据权利要求1所述的方法，其特征在于，还包括：

从所述第二集群的所述第二区域服务器中的另一客户端服务器接收另一写命令，所述另一写命令也与关联所述第一区域服务器中接收的所述写命令的所述记录相关联；

所述第二区域服务器确定来自所述另一客户端服务器的所述另一写命令是否比来自所述第一区域服务器处的客户端服务器的所述写命令晚到达所述第二区域服务器；其中，

通过以下机制中的至少一个执行所述确定：

所述第二区域服务器检查与所述写命令相关联的事务时间戳和与所述另一写命令相关联的事务时间戳；

所述第二区域服务器对从所述客户端服务器接收的所述写命令和从所述另一客户端服务器接收的所述另一写命令应用哈希协议；以及

所述第二区域服务器对从所述客户端服务器接收的所述写命令和从所述另一客户端服务器接收的所述另一写命令应用可插拔冲突解决协议。

11.根据权利要求10所述的方法，其特征在于，还包括：

在确定来自所述另一客户端服务器的所述另一写命令比来自所述第一区域服务器处的所述客户端服务器的所述写命令晚到达所述第二区域服务器时，所述第二区域服务器执行将与所述写命令相关联的所述记录提交到所述第二预写日志(WAL)中的步骤，并且在将所述记录提交到所述第二WAL之后，所述第二区域服务器执行将所述记录提交到所述第二区域服务器的所述第二存储器的步骤。

12.根据权利要求10所述的方法，其特征在于，还包括：

在确定来自所述另一客户端服务器的所述另一写命令比来自所述第一区域服务器处的所述客户端服务器的所述写命令早到达所述第二区域服务器时，在所述第二区域服务器执行将与所述写命令相关联的所述记录提交到所述第二WAL中的步骤之前，所述第二区域服务器将与所述另一写命令相关联的所述记录提交到所述第二WAL中，在将所述记录提交到所述第二WAL之后，所述第二区域服务器将所述记录提交到所述第二存储器。

13.根据权利要求1所述的方法，其特征在于，所述方法还包括：从所述第一集群中的所述第一区域服务器恢复文件，其中，恢复所述文件包括：

在主服务器中调用服务器崩溃恢复过程，所述主服务器管理所述第一集群中的区域的分配，并相应地管理由所述第一区域服务器托管的区域的分配；

在所述主服务器中调用所述服务器崩溃恢复过程时，所述方法还包括：

所述主服务器识别属于正在恢复的所述第一区域服务器的一个或多个WAL；

所述主服务器将来自所述一个或多个WAL的记录的恢复分配到所述第一集群的其它区域服务器；

分配的其它区域服务器收集来自所述一个或多个WAL中的WAL的记录；

所述分配的其它区域服务器根据所述WAL中记录可用的对应区域，拆分来自所述WAL的所述记录，以隔离所述记录；

所述分配的其它区域服务器为与一个区域对应的每组隔离记录创建编辑文件，并为每个所创建的编辑文件创建事务日志文件；

所述分配的其它区域服务器将所述编辑文件本地写入所述分配的其它区域服务器的对应存储器，所述编辑文件与分配给所述分配的其它区域服务器的一个区域对应，并将所述编辑文件的对应的事务日志文件加载到所述分配的其它区域服务器的事务日志，其中，从加载的事务日志文件中恢复所述编辑文件中的每个记录的最新事务状态；

所述分配的其它区域服务器将所述编辑文件刷新到所述分配的其它区域服务器的文件存储器中，其中，所述刷新包括：

检查所述编辑文件中的所述每个记录的所述事务状态；

不刷新事务状态指示失败/超时状态的记录；

重新加载事务状态指示进行中状态的记录；以及

将具有指示成功的事务的记录刷新到所述分配的其它区域服务器的所述文件存储器。

14.根据权利要求1所述的方法，其特征在于，至少包括所述第一区域服务器的所述第一集群的健康状况由与所述第一集群对应的第一zookeeper(ZK)监控，至少包括所述第二区域服务器的所述第二集群的健康状况由与所述第二集群对应的第二zookeeper(ZK)监控，所述第一ZK还维护所述第二集群的所述健康状况的信息，所述第二ZK还维护所述第一集群的所述健康状况的信息，所述方法还包括：

当根据所述第一ZK确定所述第一区域服务器具有不健康状态时，所述第一区域服务器拒绝来自所述客户端服务器的所述写命令；

当根据所述第一ZK确定所述第一区域服务器具有本地健康状态时，所述第一区域服务器将所述写命令提交到所述第一WAL和所述第一存储器中，所述第一区域服务器停止所述复制；

当根据所述第二ZK确定所述第二区域服务器具有恢复中的健康状态时，所述第一区域服务器停止所述复制；

当根据所述第一ZK确定所述第一区域服务器具有活动的健康状态且根据所述第二ZK确定所述第二区域服务器具有活动的健康状态时，所述第一区域服务器执行所述复制并且所述第一区域服务器执行所述提交，并且

其中，所述第一ZK和所述第二ZK关于各自监控的所述第一集群和所述第二集群的健康状况而相互配合。

15.根据权利要求14所述的方法，其特征在于，还包括：设置回所述第一集群的所述第一区域服务器与所述第二集群的所述第二区域服务器的同步复制，其中，所述第一区域服务器和所述第一集群具有恢复中的健康状态，所述第二区域服务器和所述第二集群具有活动的健康状态，所述方法包括：

所述第一集群中的主服务器识别要从所述第二区域服务器同步到所述第一区域服务器的区域；

所述主服务器向所述第一区域服务器分配恢复过程，所述恢复过程用于将识别的记录从所述第二区域服务器同步到所述第一区域服务器；

所述第一区域服务器恢复所述第一区域服务器的所述第一事务日志，以识别最后成功的事务；

所述第一区域服务器将文件从所述第二区域服务器的所述第二文件存储器下载到所述第一区域服务器的所述第一文件存储器，所述文件属于所述最后成功的事务之后的事务；

在所述第一文件存储器中的下载的文件被加载到所述第一区域服务器的所述第一存储器之后，所述第一区域服务器恢复同步，其中，在恢复之前，所述第一区域服务器将所述第一存储器中的记录传输到所述第二区域服务器的第二存储器；以及

所述第一区域服务器启动将从所述第一区域服务器处的所述客户端服务器接收到的写命令复制到所述第二区域服务器。

16.根据权利要求15所述的方法，其特征在于，将文件从所述第二文件存储器下载到所述第一文件存储器的步骤包括：

所述第一区域服务器触发将记录从所述第二存储器刷新到所述第二区域服务器中的所述第二文件存储器，所述记录属于所述第一集群中的所述主服务器所识别的区域；

所述第二区域服务器将所述记录刷新到所述第二文件存储器；以及

在所述第二区域服务器中刷新后，所述第一区域服务器将所述文件从所述第二文件存储器复制到所述第一文件存储器。

17.根据权利要求16所述的方法，其特征在于，所述第一区域服务器进行的复制包括：所述第一区域服务器将所述文件从所述第一文件存储器批量加载到所述第一存储器。

18.一种用于同步数据复制的系统，其特征在于，所述系统包括：

包括第一区域服务器的第一集群，所述第一区域服务器包括第一存储器、第一预写日志(WAL)和第一文件存储器；以及

包括第二区域服务器的第二集群，所述第二区域服务器包括第二存储器、第二WAL和第二文件存储器，所述第一集群和所述第二集群相互双活配合工作，其中：

所述第一区域服务器用于：

从客户端服务器接收写命令；

在所述第二区域服务器中复制接收到的写命令，其中，所述复制的步骤包括：所述第二区域服务器将与所述写命令相关联的记录提交到第二WAL中，在将所述记录提交到所述第二WAL之后，所述第二区域服务器将所述记录提交到所述第二存储器；以及

将与所述写命令相关联的所述记录提交到所述第一WAL，在将所述记录提交到所述第一WAL之后，将所述记录提交到所述第一区域服务器的第一存储器；并且

所述第二区域服务器用于在所述第二区域服务器中复制所述接收到的写命令。

19.根据权利要求18所述的系统，其特征在于，

所述第一区域服务器包括第一事务日志；

所述第二区域服务器包括第二事务日志；

所述第二区域服务器用于在所述第二事务日志中更新所述记录的第二事务状态，所述第二事务状态指示所述第二区域服务器中的所述记录的以下当前状态中的至少一个：进行中状态、成功状态和超时/失败状态；其中，所述进行中状态指示所述记录尚未被提交到所述第二WAL，所述成功状态指示所述记录被成功提交到所述第二WAL，所述超时/失败状态指示所述记录未能被提交到所述第二WAL；每个记录在所述第二事务日志中具有至少两个第二事务状态，最后更新的条目被视为所述记录的最新第二事务状态；

所述第二区域服务器用于向所述第一区域服务器发送所述第二事务日志中的所述记录的所述最新第二事务状态；以及

所述第一区域服务器用于从所述第二区域服务器接收所述记录的所述最新第二事务状态；并且，

其中，所述第一区域服务器用于：当接收到的所述最新第二事务状态是所述成功状态时，将所述记录提交到所述第一存储器中。

20.根据权利要求19所述的系统，其特征在于，

所述第一区域服务器用于在所述第一事务日志中更新所述记录的第一事务状态，所述第一事务状态指示所述第一区域服务器处的所述记录的以下当前状态中的至少一个：进行中状态、成功状态和超时/失败状态；其中，所述进行中状态指示所述记录尚未被提交到所述第一WAL，所述成功状态指示所述记录被成功提交到所述第一WAL，超时/失败状态指示所述记录未能被提交到所述第一WAL；每个记录在所述第一事务日志中具有至少两个事务状态，最后更新的条目被视为所述记录的最新第一事务状态。

21.根据权利要求20所述的系统，其特征在于，

所述第一区域服务器用于向所述第二区域服务器发送所述记录的所述最新第一事务状态；

所述第二区域服务器用于接收所述记录的所述最新第一事务状态，并检测到所述记录的所述第一事务状态是超时/失败状态；

响应于所述检测，所述第二区域服务器用于在所述第二事务日志中再次更新所述记录的对应的第二事务状态，以在所述第二区域服务器中指示所述超时/失败状态；以及

所述第二区域服务器用于更新所述第二存储器中的所述记录，以反映所述记录的所述超时/失败状态。

22.根据权利要求21所述的系统，其特征在于，如果所述记录已从所述第二存储器刷新到所述第二区域服务器的所述第二文件存储器，但在所述第二区域服务器处接收到作为所述最新第一事务状态的所述记录的所述超时/失败状态，则所述第二区域服务器用于：

重写所述第二文件存储器中的文件，以移除与所述写命令对应的所述记录的事务。

23.根据权利要求18至22中任一项所述的系统，其特征在于，与在所述第一区域服务器处接收到的所述写命令对应的所述记录被同时提交到所述第一区域服务器的所述第一存储器和所述第二区域服务器的所述第二存储器；如果与所述写命令对应的所述记录未能被提交到所述第一区域服务器和所述第二区域服务器中的任一个中，则所述第一集群和所述第二集群中的任一个中接收到的后续读操作或搜索查询均不考虑所述记录。

24.根据权利要求23所述的系统，其特征在于，为了将所述记录同时提交到所述第一区域服务器的所述第一存储器和所述第二区域服务器的所述第二存储器，

所述第一区域服务器用于锁定第一行，所述第一行属于由所述第一区域服务器托管的区域，所述第一行与所述第一区域服务器处接收的所述写命令对应，所述第一区域服务器用于在所述第二区域服务器中复制接收到的写命令；

所述第二区域服务器用于锁定第二行，所述第二行属于由所述第二区域服务器托管的区域，所述第二行与在所述第二区域服务器处复制的所述写命令对应；以及

在所述第二行被成功锁定时，所述第二区域服务器用于将所述记录提交到所述第二WAL中，所述第一区域服务器用于将所述记录提交到所述第一WAL中，所述第二区域服务器的提交与所述第一区域服务器的提交并行执行。

25.根据权利要求24所述的系统，其特征在于，所述第一区域服务器锁定所述第一行以及所述第二区域服务器锁定所述第二行是响应于所述客户端服务器的原子批量行请求。

26.根据权利要求23所述的系统，其特征在于，响应于所述客户端服务器的非原子批量行请求，

所述第一区域服务器用于锁定第一行批量，所述第一行批量属于由所述第一区域服务器托管的区域，所述第一行批量与所述第一区域服务器处接收的所述写命令对应，所述第一区域服务器用于在所述第二区域服务器中复制接收到的写命令；

所述第二区域服务器用于尝试锁定第二行批量，所述第二行批量属于由所述第二区域服务器托管的区域，所述第二行批量与在所述第二区域服务器处复制的所述写命令对应；

所述第二区域服务器用于获取对所述第二行批量的至少第一子集的锁定，而未能获取对所述第二行批量的第二子集的锁定；

所述第一区域服务器用于释放对所述第一行批量的第一子集的锁定，所述第一行批量的第一子集与所述第二区域服务器中的所述第二行批量的第一子集对应；

所述第二区域服务器用于将所述记录提交到所述第二WAL中，所述第二区域服务器的提交步骤是对所述第二行批量的第一子集执行的，所述第一区域服务器用于将所述记录提交到所述第一WAL中，所述第一区域服务器的提交步骤是对所述第一行批量的第一子集执行的，其中，所述第二区域服务器的所述提交与所述第一区域服务器的所述提交并行执行；

所述第一区域服务器用于再次锁定所述第一行批量的第二子集，所述第一行批量的第二子集与所述第二区域服务器中的所述第二行批量的第二子集对应；以及

所述第二区域服务器用于再次尝试锁定所述第二行批量的第二子集，使得并行执行由所述第二区域服务器针对所述第二行批量的第二子集将所述记录提交到所述第二WAL中以及由所述第一区域服务器针对所述第一行批量的第二子集将所述记录提交到所述第一WAL中。

27.根据权利要求18所述的系统，其特征在于，

所述第二区域服务器用于从另一客户端服务器接收另一写命令，所述另一写命令也与关联所述第一区域服务器中接收的所述写命令的所述记录相关联；以及

所述第二区域服务器用于确定来自所述另一客户端服务器的所述另一写命令是否比来自所述第一区域服务器处的所述客户端服务器的所述写命令晚到达所述第二区域服务器；

其中，通过以下机制中的至少一个执行所述确定：

所述第二区域服务器用于检查与所述写命令相关联的事务时间戳和与所述另一写命令相关联的事务时间戳；

所述第二区域服务器用于对接收到的所述写命令和所述另一写命令应用哈希协议；

所述第二区域服务器用于对所述写命令和所述另一写命令应用可插拔冲突解决协议。

28.根据权利要求27所述的系统，其特征在于，

在确定来自所述另一客户端服务器的所述另一写命令比来自所述第一区域服务器处的所述客户端服务器的所述写命令晚到达所述第二区域服务器时，所述第二区域服务器用于执行将与所述写命令相关联的所述记录提交到所述第二WAL中的步骤，在将所述记录提交到所述第二WAL之后，执行将所述记录提交到所述第二区域服务器的所述第二存储器的步骤。

29.根据权利要求27所述的系统，其特征在于，

在确定来自所述另一客户端服务器的所述另一写命令比来自所述第一区域服务器处的所述客户端服务器的所述写命令早到达所述第二区域服务器时，在执行将与所述写命令相关联的所述记录提交到所述第二WAL中的步骤之前，所述第二区域服务器用于将与所述另一写命令相关联的所述记录提交到所述第二WAL中，在将所述记录提交到所述第二WAL之后，将所述记录提交到所述第二存储器。

30.根据权利要求18所述的系统，其特征在于，所述系统还包括主服务器，所述主服务器用于管理所述第一集群中的区域的分配，并相应地管理由所述第一区域服务器托管的区域的分配；其中，

所述主服务器用于调用服务器崩溃恢复过程，以从所述第一集群中的所述第一区域服务器恢复文件，其中，所述第一集群包括其它区域服务器，所述其它区域服务器被分配从所述第一区域服务器恢复所述文件，所述其它区域服务器中的每个区域服务器包括对应的存储器、对应的WAL、对应的事务日志和对应的文件存储器；

在所述主服务器中调用所述服务器崩溃恢复过程时，所述主服务器用于：识别一个或多个WAL，所述一个或多个WAL属于正在恢复的所述第一区域服务器；将来自所述一个或多个WAL的记录的恢复分配给所述第一集群的所述其它区域服务器；

来自所述第一集群的分配的其它区域服务器用于：

从所述一个或多个WAL中的WAL中收集记录；

根据所述WAL中记录可用的对应区域来拆分来自所述WAL的所述记录，以隔离所述记录；

为与一个区域对应的每组隔离记录创建编辑文件，并为每个所创建的编辑文件创建事务日志文件；

将所述编辑文件本地写入所述分配的其它区域服务器的对应存储器，所述编辑文件与分配给所述分配的其它区域服务器的一个区域对应，并将所述编辑文件的对应事务日志文件加载到所述分配的其它区域服务器的对应事务日志中，其中，从加载的事务日志文件中恢复所述编辑文件中的每个记录的最新事务状态；

检查所述编辑文件中的每个记录的所述事务状态；以及

基于所述编辑文件中的每个记录的所述事务状态，将所述编辑文件刷新到所述分配的其它区域服务器的对应文件存储器，并且

其中，不刷新事务状态指示失败/超时状态的记录，重新加载事务状态指示进行中状态的记录；并且将事务状态指示成功状态的记录刷新到所述对应的文件存储器。

31.根据权利要求18所述的系统，其特征在于，所述系统还包括与所述第一集群对应的第一zookeeper(ZK)和与所述第二集群对应的第二zookeeper(ZK)，其中，至少包括所述第一区域服务器的所述第一集群的健康状况由第一ZK监控，至少包括所述第二区域服务器的所述第二集群的健康状况由所述第二ZK监控，所述第一ZK还维护所述第二集群的所述健康状况的信息，所述第二ZK还维护所述第一集群的所述健康状况的信息，其中，

所述第一区域服务器用于：当根据所述第一ZK确定所述第一区域服务器具有不健康状态时，拒绝来自所述客户端服务器的所述写命令；

所述第一区域服务器用于：当根据所述第一ZK确定所述第一区域服务器具有本地健康状态时，将所述写命令提交到所述第一WAL和所述第一存储器中；并且停止所述复制；

所述第一区域服务器用于：当根据所述第二ZK确定所述第二区域服务器具有恢复中的健康状态时，所述第一区域服务器停止所述复制；以及

所述第一区域服务器用于：当根据所述第一ZK确定所述第一区域服务器具有活动的健康状态且根据所述第二ZK确定所述第二区域服务器具有活动的健康状态时，执行所述复制和所述提交，并且

其中，所述第一ZK和所述第二ZK关于各自监控的所述第一集群和所述第二集群的健康状况而相互配合。

32.根据权利要求31所述的系统，其特征在于，所述系统还包括与所述第一集群对应的主服务器，其中，当所述第一区域服务器和所述第一集群具有恢复中的健康状态，所述第二区域服务器和所述第二集群具有活动的健康状态时，所述主服务器用于设置回所述第一集群的所述第一区域服务器与所述第二集群的所述第二区域服务器的同步复制，其中：

所述主服务器用于：

在所述第一集群中识别要从所述第二区域服务器同步到所述第一区域服务器的区域；

向所述第一区域服务器分配恢复过程，所述恢复过程用于将识别的记录从所述第二区域服务器同步到所述第一区域服务器；

所述第一区域服务器用于：

恢复所述第一区域服务器的所述第一事务日志以识别最后成功的事务；

将文件从所述第二区域服务器的所述第二文件存储器下载到所述第一区域服务器的所述第一文件存储器，所述文件属于所述最后成功的事务之后的事务；

在所述第一文件存储器中的下载的文件被加载到所述第一区域服务器的所述第一存储器之后，恢复同步，其中，在恢复之前，将所述第一存储器中的记录传输到所述第二区域服务器的第二存储器中；以及

启动将从所述第一区域服务器处的所述客户端服务器接收到的写命令复制到所述第二区域服务器。

33.根据权利要求32所述的系统，其特征在于，为了将文件从所述第二文件存储器下载到所述第一文件存储器，

所述第一区域服务器用于触发将记录从所述第二存储器刷新到所述第二文件存储器，所述记录属于所述第一集群中的所述主服务器所识别的区域；

所述第二区域服务器用于将所述记录刷新到所述第二文件存储器；以及

所述第一区域服务器用于：在所述第二区域服务器中进行刷新后，将所述文件从所述第二文件存储器复制到所述第一文件存储器。

34.根据权利要求32所述的系统，其特征在于，所述第一区域服务器用于将复制的文件从所述第一文件存储器批量加载到所述第一存储器。