CN115328880B - 分布式文件在线恢复方法、系统、计算机设备及存储介质 - Google Patents

Abstract

本申请涉及一种分布式文件在线恢复方法、系统、计算机设备及存储介质，属于数据恢复技术领域，包括以下步骤：获取恢复任务，选择确定恢复的源节点和目的节点；控制节点向源节点发起进入异步恢复阶段并将源节点的分区状态设置为COMPLETE；源节点获取恢复任务，开始从源节点到目的节点的恢复；判断异步恢复阶段是否结束；若否，则保持原节点到目的节点的恢复，若是，则执行以下步骤；源节点向控制节点发起进入同步恢复阶段请求；源节点获取恢复任务，开始从源节点到目的节点的恢复；判断两个副本数据是否一致；恢复任务完成。本申请具有缩短数据恢复过程中的等待时长，提高连续性写入的时效性的效果。

Description

分布式文件在线恢复方法、系统、计算机设备及存储介质

技术领域

本申请涉及数据恢复技术领域，尤其是涉及一种分布式文件在线恢复方法、系统、计算机设备及存储介质。

背景技术

随着互联网技术的发展，大数据时代的到来，对数据存储的要求也越来越高，为保证数据安全避免数据损失或者丢失，分布式数据存储得到广泛应用。分布式文件系统（DFS）就是在集群中所有节点上抽象出一层，向下屏蔽各个机器的具体物理路径，向上提供集群内逻辑上的一套文件系统，读写数据，用户不需要关注具体在哪个物理节点上，有DFS抽象层统一处理。

分布式数据存储通常采用多副本实时写入的方式进行数据存储，在这一方式中会由于各种如网络故障、机器宕机等因素造成部分副本写入失败，当控制节点发现有数据节点上的分区和自己所维护的信息不一致时，就需要恢复机制来恢复该不一致的分区。在多副本的情况下，可以拷贝一直的副本的数据到不一致的副本所在的数据节点上的覆盖原本不一致的副本数据来恢复，即恢复原理就是不一致的副本拷贝数据到不一致的副本上。

现有的恢复机制中，在整个恢复过程中，无法向写入新的数据，而恢复过程可能会持续很久，导致等待延时长，无法满足用户对连续写入的需求。

发明内容

为了缩短数据恢复过程中的等待时长，提高连续性写入的时效性，本申请提供一种分布式文件在线恢复方法、系统、计算机设备及存储介质。

第一方面，本申请提供一种分布式文件在线恢复方法，采用如下的技术方案：

一种分布式文件在线恢复方法，包括以下步骤：

获取恢复任务，选择确定恢复的源节点和目的节点；

控制节点向源节点发起进入异步恢复阶段并将源节点的分区状态设置为COMPLETE；

源节点获取恢复任务，开始从源节点到目的节点的恢复；

判断异步恢复阶段是否结束；若否，则保持原节点到目的节点的恢复，若是，则执行以下步骤；

源节点向控制节点发起进入同步恢复阶段请求，控制节点将源节点分区状态设置为RECOBERING；

源节点获取恢复任务，开始从源节点到目的节点的恢复；

判断两个副本数据是否一致；若否，则保持源节点到目的节点的恢复，若是，则执行以下步骤；

恢复任务完成，控制节点更新副本状态信息，将分区状态设置为COMPLETE。

通过采用上述技术方案，通过将整个恢复过程分成异步恢复阶段和同步恢复阶段，通过设置异步恢复阶段中，分区处于COMPLETE状态，仍可以写入，以实现在恢复的同时也可以满足数据写入的要求，缩短分区状态为RECOVERING的时间，即减少阻塞写入的时间，从而降低等待延时时长，提高连续性写入的时效性；通过同步恢复阶段中，分区处于RECOVERING状态，此时该分区不能写入，以保证恢复结束后源节点和目的节点上的两个副本数据保持一致。

进一步地，在所述控制节点向源节点发起进入异步恢复阶段并将源节点的分区状态设置为COMPLETE前，所述控制节点将源节点的分区状态先从COMPLETE转成RECOVING，再将分区状态从RECOVING转换成COMPLETE。

通过采用上述技术方案，将分区状态从COMPLETE转成RECOVING，又快速地转回COMPLETE，使得分区短暂的处于RECOVING状态，是为了复用之前恢复的这部分代码，而几乎不会对分区在异步恢复阶段的写入造成影响。

进一步地，所述源节点获取恢复任务，开始从源节点到目的节点的恢复具体包括以下步骤：

源节点向控制节点获取CID Snapshot；

源节点通过CID Snapshot获知源节点本身该分区最大的CID，同时源节点获知目的节点当前最大CID；

源节点读取这两个CID差异部分的数据，并发送到目的节点。

通过采用上述技术方案，DFS支撑事务和MVCC，每次事务都有一个CID，CID是递增的，MVCC指保留了数据的多个版本，不同的版本对应不同的事务，也相当于一次写入，CID可以看作版本号，通过获取CID Snapshot，即可知道两个副本之间的数据差异，根据CID去拷贝两个副本之间实际差异的数据，而不是从源节点的分区向目的节点的分区拷贝所有数据的数据，从而避免对两个副本相同数据进行拷贝而造成恢复时间久。

进一步地，所述源节点获取恢复任务，开始从源节点到目的节点的恢复还包括以下步骤：

源节点更新其所维护的目的节点CID信息，以及目的节点当前数据量信息。

通过采用上述技术方案，由于存在两个副本之间的数据差异量较大的情况，差异数据不能一次性拷贝完成，因此可以分成多次发送，当每次数据发送完成后，源节点通过更新维护目的节点的CID信息从而重新获取两个副本之间的数据差异，以便于后续发送的数据拷贝定位。

进一步地，所述源节点在开始新一轮发送数据到目的节点前，所述源节点重新向控制节点获取CID Snapshot。

通过采用上述技术方案，在异步恢复阶段中，源节点的分区仍然可以写入新的数据，当新的数据写入完成之后会对应生成新的CID，源节点在新的拷贝开始前，重新获取CIDSnapshot以此来保证新写入的数据也可能在下一次数据拷贝中被拷贝到目的节点。

进一步地，所述判断异步恢复阶段是否结束，具体包括：判断两个副本数据差异是否小于阈值，所述阈值设置于源节点上。

通过采用上述技术方案，由于异步恢复阶段中，源节点的分区仍可以写入新的数据，因此在判断异步恢复阶段是否结束，无需要求两个副本之间数据一致，只需要保证数据差异小于一定值即可，通过合理设置阈值，以使得整个恢复过程中的时长更加合理。

进一步地，所述判断异步恢复阶段是否结束，具体包括：判断往返次数是否超过复制上限，所述复制上限设置于源节点上，一次往返为一次完整的数据拷贝。

通过采用上述技术方案，通过设置复制上限以限制异步恢复阶段的数据拷贝次数，从而对异步恢复阶段的时长进行限制，以降低双副本系统在异步恢复阶段出现容错率低的情况。

第二方面，本申请提供一种应用上述第一方面所述的分布式文件在线恢复系统，包括控制节点和数据节点，

所述控制节点用于管理元数据，分配分区位置，提供对事务的支持；

所述数据节点用于存储数据，其包括源节点和目的节点，

所述源节点用于提供拷贝数据，所述控制节点根据恢复任务确定所述源节点和所述目的节点，所述控制节点控制所述源节点向所述目的节点的恢复。

第三方面，本申请提供一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行上述第一方面所述的在线恢复方法的步骤。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述第一方面所述的在线恢复方法。

综上所述，本申请包括以下至少一种有益技术效果：

1.通过将恢复过程分为异步恢复阶段和同步恢复阶段，在异步恢复阶段中源节点分区仍可以写入新的数据，不会阻塞写入，以此来减少恢复的分区处于RECOVERING状态的时间；

2.源节点通过获取CID Snapshot来获知源节点本身和目的节点的最大CID，从而实现在恢复过程之后中，根据CID只拷贝两个副本之间的差异数据，而非拷贝所有的数据，以此来降低恢复过程的时长；

3.通过设置两个副本数据差异的阈值和拷贝往返次数的复制上限，以此来保证异步恢复阶段能够及时结束，保证双副本系统在恢复过程中的容错率。

附图说明

图1是本申请实施例中在线恢复系统的结构示意框图；

图2是本申请实施例中在线恢复方法的整体步骤流程图；

图3是本申请实施例中在线恢复方法的部分步骤流程图，主要显示了异步恢复阶段数据拷贝的步骤；

图4是本申请实施例中在线恢复方法的部分步骤流程图，主要显示了判断异步恢复阶段是否结束的步骤；

图5是本申请实施例中在线恢复方法的部分步骤流程图，主要显示了同步恢复阶段数据拷贝的步骤；

图6是本申请实施例中在线恢复方法的数据恢复过程的示意图。

附图标记说明：1、控制节点；2、数据节点。

具体实施方式

以下结合附图图1-图6对本申请作进一步详细说明。

本申请实施例公开一种分布式文件在线恢复系统，参照图1，其包括至少一个控制节点1和多个数据节点2，控制节点1的主要职责是管理元数据，分配分区位置，提供对事务的支持；数据节点2的主要职责是存储数据。如图1中为一个单控制节点1、三个数据节点2的集群，数据节点2分别为datanode1、datanode2和datanode3；控制节点1和数据节点2是一个进程，处于物理机、虚拟器或者容器上。该集群副本数为2，同一个分区的数据会被分布到不同的数据节点2上，同属于一个分区的不同副本之间存储的数据是相同，如datanode1的chunk1上的数据与datanode2的chunk1上的数据是相同。控制节点1会存储各个数据节点2上分区信息（元数据），在数据节点2启动等阶段，数据节点2也会向控制节点1汇报自己的信息，正常运行过程中，控制节点1和数据节点2各自推进自己维护的分区信息（包括版本号）。

如果某个数据节点2下线，DFS运行后续的写入操作只往剩余的数据节点2上写入数据，假设datanode1下线，则datanode2和datanode3仍可以正常写入数据。若正常运行时，如果一个写操作包含chunk1、chunk2、chunk3三个分区，那么这个写操作会同时往chunk1在datanode1和datanode2的两个副本上写入，往chunk2在datanode1和datanode3的两个副本上写入，往chunk3在datanode2和datanode3的两个副本上写入。那么在datanode1下线后，这个写操作往chunk1在datanode2的副本上写入，往chunk2在datanode3的副本上写入，往chunk3在datanode2和datanode3的两个副本上写入。

当某一数据节点2下线又重新上线后，控制节点1会将数据节点2根据恢复需求分为源节点和目的节点，源节点为恢复拷贝数据的源头所在的节点（可能是任意一个一致的副本所在的数据节点2），目的节点为需要恢复数据的源头所在的数据节点2，即数据不一致的副本所在的数据节点2。例如上述举例中，当datanode1又重新上线后，会向控制节点1汇报自己的分区信息，如果在datanode1下线之后有新的写入，datanode1上并没有推进自己所维护的chunk1和chunk2的版本号信息，控制节点1在收到datanode1的汇报之后会发现datanode1上的chunk1和chunk2的版本号落后于自己所维护的datanode2上的chunk1和datanode3上的chunk2的版本号，控制节点1需要将源节点的数据拷贝到目的节点，进行数据恢复。在恢复chunk1上的数据时，源节点为datanode2，在恢复chunk2上的数据时，源节点为datanode3，目的节点均为datanode1。

本申请实施例还公开一种应用于上述分布式文件系统的分布式文件在线恢复方法。如图2所示，分布式文件在线恢复方法包括以下步骤：

S1、获取恢复任务，选择确定恢复的源节点和目的节点。

具体地，数据节点2会主动或被动地向控制节点1汇报分区信息，其中主动汇报为数据节点2向控制节点1主动汇报自己的分区信息；正常情况下，数据节点2会每间隔一段时长（多为2S）向控制节点1发送心跳包。被动汇报为当控制节点1超过一定时长（与2S对应，多为6S）未接收到数据节点2的心跳包，则认为该数据节点2已经下线删除，控制节点1上维护的该数据节点2的分区信息，使得该数据节点2不会参与后续事务，当该数据节点2再次上线，控制节点1会再收到该数据节点2的心跳包，此时控制节点1认为该数据节点2重新上线，会让该数据节点2汇报自己所有的分区信息。控制节点1收到数据节点2的汇报后，不管由于数据损坏还是版本号不一致，都需要对该数据节点2进行数据恢复，并放入到待恢复的队列中；队列是汇报的函数和恢复线程之间的通信方式，一个往队列中添加任务，一个从队列中取出任务，将恢复任务放到队列中主要是将恢复任务教给单独的线程来执行，不阻塞数据节点2汇报所有分区的这个流程。

恢复线程会从恢复队列中取出恢复任务，控制节点1根据已经收到的汇报，选择确定恢复的源节点和目的节点，向源节点发起恢复任务。

S2、控制节点1向源节点发起进入异步恢复阶段并将源节点的分区状态设置为COMPLETE。

具体地，每个分区在控制节点1上有三种状态COMPLETE、CONSTRUCTING和RECOVERING，其中COMPLETE表示该分区没有写入也没有在恢复中；CONSTRUCTING表示该分区正在写入中；RECOVERING表示该分区正在恢复中。分区只能由COMPLETE状态转为CONSTRUCTING或RECOVERING状态，再由CONSTRUCTING或RECOVERING状态转为COMPLETE状态，CONSTRUCTING和RECOVERING状态之间不能直接转换，即写入中的分区不能进行恢复，恢复中的分区不能进行写入，本申请实施例中所讨论的状态以及写入恢复都是针对分区的，而不是针对一个分区的某个副本。

在异步恢复阶段中，控制节点1将源节点的分区状态设置为COMPLETE，以使得在异步恢复阶段中，源节点的分区仍可写入数据。本申请中，控制节点1将源节点的分区状态先从COMPLETE转成RECOVING，又快速从RECOVING转换成COMPLETE，将分区状态短暂的置为RECOVEING是为了复用之前恢复的这部分代码。当分区状态再次转为COMPLETE状态后，恢复线程才进入异步恢复阶段，在异步恢复阶段中，源节点的分区为可写入新数据，以保证在恢复过程中，源节点的分区仍能进行数据写入，以解决恢复过程可能会持续很久而无法写入数据的问题。

S3、源节点获取恢复任务，开始从源节点到目的节点的恢复。

具体地，DFS支持事务和MVCC，事务保证看数据节点2上分区与数据记录的信息和数据是一致的；MVCC操作可以知道不一致的副本到底确实了哪些事务。本申请实施例中事务采用append操作，每次事务都有一个CID，CID是递增的，数据不一致的副本相比于一致的副本会缺少一些事务，也就是数据不一致的副本的最大CID是小于一致副本的最大CID。在源节点开始恢复前，源节点回到从目的节点获取到目的节点当前最大CID。

参照图3，具体包括以下步骤：

S31、源节点向控制节点1获取CID Snapshot；

S32、源节点通过CID Snapshot获知源节点本身该分区最大的CID，同时源节点获知目的节点当前最大CID；

S33、源节点读取这两个CID差异部分的数据，并发送到目的节点；

S34、源节点更新其所维护的目的节点CID信息，以及目的节点当前数据量信息；

具体地，源节点获取CID Snapshot后，通过CID Snapshot获取到自己的最大CID，同时也知道目的节点当前最大CID，当差异数据过大时，数据会拆分成多次进行发送，每次发送的最大数据量为128MB，每次源节点发送数据到目的节点，目的节点向源节点返回拷贝成功，则代表一次往返；因此源节点除了恢复开始时会从目的节点获取目的节点最大CID外，每次往返结束之后，源节点都会将自己维护目的节点最大CID修改为拷贝后CID。比如，恢复开始时，目的节点的最大CID为99，在恢复时，源节点第一次往返拷贝了CID为100-110的数据，当第一次拷贝结束后，源节点会将其维护的目的节点的最大CID修改为110。

在异步恢复阶段的恢复过程中，源节点还是可以写入的，因此每次往返中，源节点在开始新一轮数据拷贝前均会重新从控制节点1上重新获取CID Snapshot，以此来获取本节点上副本的一个最大CID，从而判断两个副本之间的差异，如果这个时候两个副本一致，则会控制节点1汇报恢复完成。但是在异步恢复阶段，一次往返过程中可能有新的数据写入，但是这个写入的数据不会在该次往返过程中被拷贝，且如果新的数据在下一次往返开始前还没有完成写入，则新的数据不会产生新的CID，即在下一次往返中该数据不会被拷贝，源节点可能还会由于没有新的CID产生，而判断两个副本一致；如果新的数据在下一次往返开始前完成写入了，在新一轮拷贝开始前，新写入的数据会产生新的CID，因此两个副本之间的数据仍然不一致，此时源节点会发起新的拷贝任务。

S4、判断异步恢复阶段是否结束；若否，则保持源节点到目的节点的恢复，若是，则执行以下步骤。

参照图4，具体地，判断异步恢复阶段是否结束具体包括以下两种判断方式：一是判断两个副本数据差异是否小于阈值；二是判断往返次数是否超过复制上限。在异步恢复阶段中，源节点的分区可以写入新的数据，源节点的副本数据和目的节点的副本数据可能存在上述“假一致”的情况，因此无需对要求两个副本数据一致再执行后续的步骤，仅设置阈值为某一数值即可，当然，阈值可以设置为0。在异步恢复阶段中，虽然不阻塞写入，但只能往好的副本上写入新的数据，在恢复中的分区仍然不能同步写入新的数据，如果集群是一个双副本设置，在异步恢复阶段中，只有一个副本能够写入，此时系统没有多副本容错的能力，造成系统工作在非最优状态下，因此在异步恢复阶段中拷贝的往返次数不宜过多；实际上，往返次数的多少与异步恢复阶段中是否有新的数据写入有关，因此在设置复制上限时需要结合实际业务进行设定。

在恢复过程中，可以比较两个副本之间的数据差异是否小于阈值，也可以比较拷贝的往返次数是否超过复制上限，两个比较判断可以选取其中一个也可以选取两个同时进行，当选取一种判断方式时，只要判断结果为否，则表示异步恢复阶段仍未结束，若判断结果为是，则表示异步恢复阶段结束，执行后续恢复步骤。如果选取两个判断方式同时进行，则当两个比较判断结果均为否时，表示异步恢复阶段仍未结束，源节点保持到目的节点的恢复，即当两个副本之间的数据差异大于或等于阈值且拷贝的往返次数没有超过复制上限时，保持异步恢复阶段的源节点到目的节点的恢复。当任一比较判断结果为是时，则进行后续的恢复步骤，即两个副本之间的数据差异小于阈值或者往返次数超过复制上限则时，结束异步恢复阶段，进行下一恢复状态。本申请实施例中，优选两个判断方法同时进行，以使得整个恢复过程耗时更短。源节点上设置有数据差异的阈值和往返次数的复制上限，且数据差异的阈值和往返次数的复制上限均可以根据实际使用场景进行配置。

S5、源节点向控制节点1发起进入同步恢复阶段请求，控制节点1将源节点的分区状态设置为RECOVERING。

具体地，由于异步恢复阶段，源节点的分区可以写入新数据，因此可能存在新写入的数据由于没有完成写入而导致源节点误以为两个副本一致，或者控制节点1接收到恢复成功的信息之后回修改元数据，而此时这个分区有新的写入在进行，这个元数据是瞬态的，不是一个确定的状态，因此当异步恢复阶段完成之后，由源节点想控制节点1发起请求，控制节点1将源节点的分区状态转换成RECOVERING，当源节点的分区状态从COMPLETE转换为RECOVERING后，源节点该分区不能再有新的写入；此时在线恢复进入同步恢复阶段。

S6、源节点获取恢复任务，开始从源节点到目的节点的恢复。

参照图5，具体地，源节点向目的节点的恢复过程即为数据拷贝过程，具体包括以下步骤：

S61、源节点向控制节点1获取CID Snapshot；

S62、源节点通过CID Snapshot获知源节点本身该分区最大的CID，同时源节点获知目的节点当前最大CID；

S63、源节点读取这两个CID差异部分的数据，并发送到目的节点；

S64、源节点更新其所维护的目的节点CID信息，以及目的节点当前数据量信息；

具体地，当分区状态处于RECOVERING时，该分区不能再写入新的数据，在异步恢复阶段中，拷贝的往返次数不宜过多，在实际的拷贝时，拷贝的数据量会随着拷贝次数的增加而下降，即在第一次拷贝时，会由于两个副本之间的差异数据量大，而使得拷贝的数据量也会很大，拷贝耗时较长，在异步恢复阶段中分区仍能写入新的数据，因此在拷贝过程中，写入的数据量可能也会比较大，在持续写入的场景中，用户单次写入的数据量不会很大，因此随着拷贝次数的增加，拷贝的数据量会逐渐减小，单次拷贝的时间也会相应减少，在拷贝过程中，写入的新的数据量也会越少，因此异步恢复阶段最后一次的数据拷贝之后，两个副本之间的最终数据差异可能会收敛到用户单次写入的数据量。

同步恢复阶段的数据拷贝原理与异步恢复阶段的数据拷贝原理相同，当源节点在开始新一轮同步拷贝前根据CID Snapshot获取目的节点当前最大的CID，由于同步恢复阶段，源节点的分区不能写入新的数据，因此源节点的最大CID保持不变。同步恢复阶段的拷贝时间与两个副本间最终数据差异有关，假设数据差异阈值为1000行，那么同步恢复阶段的时间可以控制在1秒内，有效降低延时等待的时间。

S7、判断两个副本数据是否一致。

具体地，在同步恢复阶段中，源节点的分区不能再写入新的数据，此阶段中，源节点比较其与目的节点的最大CID是否一致，如果不一致，则保持同步恢复阶段中的源节点到目的节点的恢复；若源节点与当源节点的最大CID与目的节点的最大CID相等时，则代表源节点和目的节点的数据实质相同，即此时两个副本数据一致，执行后续步骤。

S8、恢复任务完成，控制节点1更新副本状态信息，将分区状态设置为COMPLETE。

具体地，当源节点判断两个副本最大CID一致时，源节点向控制节点1发送恢复任务完成报告，控制节点1收到源节点汇报的完成报告，更新副本状态信息，将分区从RECOVERING转换为COMPLETE状态，允许写入。

参照图6，本申请实施例中以datanode1故障为例，在datanode1故障下线阶段中，chunk1有新数据写入，chunk2无新数据写入；当datanode1因为机器恢复进程重启或网络恢复等情况重新上线，datanode1主动或被动地向控制节点1汇报分区信息，即图中箭头1。控制节点1收到datanode1的汇报后，不管是由于data corruption还是version不一致，都需要进行恢复，放入到待恢复队列。恢复线程从待恢复队列中取出恢复任务，根据目前已经收到的汇报，选择确定恢复的源节点和目的节点，本申请实施例中，源节点为datanode2，目的节点为datanode1，控制节点1向源节点发起恢复任务，即图中箭头2。源节点收到任务后，开始从源节点到目的节点的恢复，即图中箭头3和图中箭头4，箭头3和箭头4是源节点向目的节点拷贝数据时的一次往返（往：拷贝数据，返：告知数据拷贝成功/失败），一个恢复任务可能会有很多次往返，因此当有多次往返时，箭头3和箭头4也为多个。当源节点判断出两个副本之间数据差异小于阈值或者往返次数超过复制上限时，源节点向控制节点1发起转为同步恢复阶段地请求，即图中箭头5。控制节点1收到转同步恢复阶段地请求后，将分区转为RECOVEING状态。源节点收到控制节点1发送的转同步恢复阶段成功地回复后，即图中箭头6，开始从源节点向目的节点的恢复，即图中箭头7和箭头8，当有多次往返时，箭头7和箭头8也为多个。当源节点根据CID判断出两个副本之间的数据一致时，恢复任务完成，源节点向控制节点1发送完成状态，即图中箭头9。控制节点1收到源节点汇报的完成报告，更新副本状态信息，将分区设置为COMPLETE状态，分区允许写入。

本申请实施例还公开了一种计算机系统，该计算机系统包括存储器和处理器，存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行本实施例提供的任一流数据处理方法。

本申请实施例还公开了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本申请实施例提供的分布式文件在线恢复方法。

所述计算机可读存储介质例如包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上均为本申请的较佳实施例，并非依此限制本申请的保护范围，故：凡依本申请的结构、形状、原理所做的等效变化，均应涵盖于本申请的保护范围之内。

Claims (8)

1.一种分布式文件在线恢复方法，其特征在于：包括以下步骤：

获取恢复任务，选择确定恢复的源节点和目的节点；

控制节点(1)向源节点发起进入异步恢复阶段并将源节点的分区状态设置为COMPLETE；

源节点获取恢复任务，开始从源节点到目的节点的恢复；

判断异步恢复阶段是否结束；若否，则保持原节点到目的节点的恢复，若是，则执行以下步骤；

源节点向控制节点(1)发起进入同步恢复阶段请求，控制节点(1)将源节点分区状态设置为RECOBERING；

源节点获取恢复任务，开始从源节点到目的节点的恢复；其中，

源节点向控制节点(1)获取CID Snapshot；

源节点通过CID Snapshot获知源节点本身该分区最大的CID，同时源节点获知目的节点当前最大CID；

源节点读取这两个CID差异部分的数据，并发送到目的节点；

源节点更新其所维护的目的节点CID信息，以及目的节点当前数据量信息；

判断两个副本数据是否一致；若否，则保持源节点到目的节点的恢复，若是，则执行以下步骤；

恢复任务完成，控制节点(1)更新副本状态信息，将分区状态设置为COMPLETE。

2.根据权利要求1所述的分布式文件在线恢复方法，其特征在于：在所述控制节点(1)向源节点发起进入异步恢复阶段并将源节点的分区状态设置为COMPLETE前，所述控制节点(1)将源节点的分区状态先从COMPLETE转成RECOVING，再将分区状态从RECOVING转换成COMPLETE。

3.根据权利要求1所述的分布式文件在线恢复方法，其特征在于：所述源节点在开始新一轮发送数据到目的节点前，所述源节点重新向控制节点(1)获取CID Snapshot。

4.根据权利要求1所述的分布式文件在线恢复方法，其特征在于：所述判断异步恢复阶段是否结束，具体包括：判断两个副本数据差异是否小于阈值，所述阈值设置于源节点上。

5.根据权利要求1或4所述的分布式文件在线恢复方法，其特征在于：所述判断异步恢复阶段是否结束，具体包括：判断往返次数是否超过复制上限，所述复制上限设置于源节点上，一次往返为一次完整的数据拷贝。

6.一种应用权利要求1至5任一所述的分布式文件在线恢复系统，其特征在于：包括控制节点(1)和数据节点(2)，

所述控制节点(1)用于管理元数据，分配分区位置，提供对事务的支持；

所述数据节点(2)用于存储数据，其包括源节点和目的节点，

所述源节点用于提供拷贝数据，所述控制节点(1)根据恢复任务确定所述源节点和所述目的节点，所述控制节点(1)控制所述源节点向所述目的节点的恢复。

7.一种计算机设备，其特征在于：包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行如权利要求1至5任一所述的在线恢复方法的步骤。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1至5任一项所述的在线恢复方法。

Images