一种数据迁移方法及装置与流程

本申请涉及存储技术领域，尤其涉及一种数据迁移方法及装置。

背景技术：

随着互联网用户的激增以及业务的多样性发展，越来越多的数据(例如，用户数据、业务配置数据等)需要使用存储系统进行存储，以便用来分析和指导业务。集群存储系统因为其容量较大以及易于扩展的特点，在数据存储中应用广泛。

请参考图1a，为集群存储系统中的一种架构。在图1中，集群存储系统中部署管理节点a以及3个存储节点，分别标记为node1、node2和node3。集群存储系统中设置多个分布式逻辑存储单元(netlogicunitnumber，nlun)，例如，在该集群存储系统中可以设置nlun1和nlun2，每个nlun用于存储特定的数据，例如，nlun1用于存储视频数据，nlun2用于存储文本数据，管理节点a用于管理和维护每个nlun的成员盘以及每个成员盘中的数据，这样，当集群存储系统接收待存储的数据后，由管理节点a根据待存储的数据的类型判断将待存储的数据存储在nlun1还是nlun2中。针对每一个nlun，可以在每个存储节点中选择若干个磁盘作为该nlun的成员盘，从而与该nlun对应的数据全部存储在该nlun的成员盘中。例如，从每个存储节点中选择2个磁盘作为nlun1的成员盘，在node1节点中的成员盘标记为盘1和盘2，在node2节点中的成员盘标记为盘3和盘4，在node3节点中的成员盘标记为盘5和盘6，从而得到nlun1的成员盘的集合为{1,2,3,4,5,6}。

当集群存储系统扩容后，如图1b所示，在集群存储系统中新增一个存储节点，标记为node4，管理节点a会将其中一个或多个nlun的某一个成员盘替换为node4中的一个磁盘，例如，管理节点a将nlun1在node3中的磁盘6替换为node4中的磁盘7，从而，nlun1的成员盘的集合变为{1,2,3,4,5,7}。然后，管理节点a指示node4将源磁盘中的数据迁移到目标磁盘中，例如，将磁盘6中的数据迁移到磁盘7中。

由于数据迁移过程对用户是透明的，用户并不知道当前nlun1正处于数据迁移过程，因此，在nlun1进行数据迁移时，有可能会接收用户下发的数据删除指令。在这种情况下，若要删除的数据还没有从磁盘6迁移到磁盘7，则node4在接收到该删除指令后，确定磁盘7并未发现要删除的数据，确定该数据删除指令执行完成。在node4确定该数据删除指令执行完成后，磁盘6和磁盘7之间完成了数据迁移，从而要删除的数据又存储在磁盘7中，从而造成数据残留。

在现有技术中，为了解决数据残留问题，当node4接收到该数据删除指令后，会在node4的删除日志中记录该数据删除指令，当完成数据迁移后，node4回放该数据删除指令，从而将残留的数据删除。

可见，在上述方案中，要删除的数据首先从源磁盘迁移到目标磁盘，在迁移到目标磁盘后，再将该数据删除。该过程中需要浪费一次读数据的输入输出接口资源，一次写数据的输入输出接口资源和一次删除数据的输入输出接口资源，资源浪费较大。

技术实现要素：

本申请实施例提供一种数据迁移方法及装置，用于减少在数据迁移过程中对数据进行删除时所消耗的资源。

第一方面，本申请实施例提供一种数据迁移方法，该方法包括：在第二节点向第一节点迁移数据的过程中，该第一节点首先从该第二节点读取待迁移的数据、该待迁移的数据的版本号以及从至少一个第三节点中读取与该待迁移的数据属于同一个第一业务的数据的版本号，该第一业务的数据分布存储在该第二节点和至少一个该第三节点中；然后，在该第一节点确定从该第二节点读取的待迁移的数据的版本号与从任意一个该第三节点读取的数据的版本号不同时，该第一节点丢弃从该第二节点读取的待迁移的数据。

在上述技术方案中，在数据迁移时，通过比较待迁移的数据的版本号与其他节点中与待迁移的数据属于同一业务的数据的版本号，从而过滤掉要删除数据，可以减少无效迁移和后续删除io资源的浪费。

进一步地，由于可以减少无效迁移和后续删除io资源的浪费，从而可以降低数据迁移过程对业务的影响，可以提高迁移性能和可靠性。

在一种可能的设计中，该第一节点在从该第二节点读取待迁移的数据、该待迁移的数据的版本号以及从至少一个第三节点中读取与该待迁移的数据属于同一个第一业务的数据的版本号之前，接收指示该第一节点及该至少一个第三节点删除与该第一业务对应的数据的删除指令，则该第一节点确定从该第二节点读取的待迁移的数据的版本号为正整数，以及确定从任意一个该第三节点读取的数据的版本号不存在。

在上述技术方案中，在数据迁移时，可能会接收操作指令，当第一节点在从第二节点中读取第一业务的数据的版本号之前接收该删除指令，则该至少一个第三节点也接收该删除指令，从而至少一个第三节点分别将存储的第一业务的数据删除，这样，当执行删除操作后，至少一个第三节点的各个磁盘中便不存在该第一业务的数据，从而从任意一个该第三节点读取的第一业务的数据的版本号则为不存在。由于第二节点中的数据需要迁移，因此，第二节点不会将接收的删除指令下发给迁移数据的磁盘，因此，第一节点从第二节点中读取的第一业务的数据的版本号为未进行操作之前的版本号，二者不相同。

在一种可能的设计中，该第一节点在从该第二节点读取待迁移的数据、该待迁移的数据的版本号以及从至少一个第三节点中读取与该待迁移的数据属于同一个第一业务的数据的版本号之前，接收指示该第一节点及该至少一个第三节点改写与第一业务对应的数据的改写指令，则该第一节点确定从任意一个该第三节点读取的数据的版本号大于从该第二节点读取的待迁移的数据的版本号。

在上述技术方案中，在数据迁移时，可能会接收操作指令，当第一节点在从第二节点中读取第一业务的数据的版本号之前接收该改写指令，则该至少一个第三节点也接收该改写指令，从而至少一个第三节点分别改写存储的第一业务的数据，这样，当执行改写操作后，至少一个第三节点的各个磁盘中的第一业务的数据的版本号增大，而由于第二节点中的数据需要迁移，因此，第二节点不会将接收的删除指令下发给迁移数据的磁盘，因此，第一节点从第二节点中读取的第一业务的数据的版本号为未进行操作之前的版本号，第一节点从第二节点读取的第一业务的数据的版本号小于从任意一个第三节点读取的第一业务的数据的版本号。

在一种可能的设计中，该第一节点在从该第二节点读取到待迁移的数据、该待迁移的数据的版本号以及从至少一个第三节点中读取到与该待迁移的数据属于同一个第一业务的数据的版本号时，接收到指示该第一节点及该至少一个第三节点删除或改写与第一业务对应的数据的操作指令，则该第一节点缓存该操作指令所携带的操作版本号，若该第一节点在确定从该第二节点读取的待迁移的数据的版本号与从任意一个该第三节点读取的数据的版本号相同，且确定从该第二节点读取的待迁移的数据的版本号小于缓存的操作版本号，则该第一节点丢弃从该第二节点读取的待迁移的数据。

在上述技术方案中，在数据迁移时，可能会接收操作指令，当第一节点在从至少一个第三节点中读取第一业务的数据的版本号的接收该改写指令的同一时刻，该第一节点接收该操作指令，则该至少一个第三节点也接收该改写指令，但由于至少一个第三节点还未执行该操作指令，因此，第一节点从至少一个第三节点的各个磁盘中读取的是操作之前的第一业务的数据的版本号，而由于第二节点中的数据需要迁移，因此，第二节点不会将接收的删除指令下发给迁移数据的磁盘，因此，第一节点从第二节点中读取的第一业务的数据的版本号为未进行操作之前的版本号，从而第一节点从第二节点读取的第一业务的数据的版本号等于从任意一个第三节点读取的第一业务的数据的版本号。在这种情况下，第一节点可以将读取的第一业务的数据的版本号与操作指令的操作版本号进行比较，若读取的第一业务的数据的版本号小于操作指令的操作版本号，则第一节点从第二节点中读取的第一业务的数据为旧数据，从而丢弃该数据，可以解决并发导致的数据残留的问题。

在一种可能的设计中，该第一节点首先从该至少一个第三节点中确定处于可信状态的节点，该可信状态为存储该第一业务的数据的磁盘未发生故障、且存储该第一业务的数据的磁盘上的数据是完整的，然后从处于可信状态的节点读取与该待迁移的数据属于同一个第一业务的数据的版本号。

在上述技术方案中，由于第一节点从处于可信状态的节点中读取与待迁移的数据属于同一个业务的数据的版本号，因此，可以保证读取的该版本号的准确性。

在一种可能的设计中，该第一节点首先从该至少一个第三节点中确定处于可信状态的节点，该可信状态为存储该第一业务的数据的磁盘未发生故障、且存储该第一业务的数据的磁盘上的数据是完整的，然后从该处于可信状态的节点中确定负载最小的节点，从而从该负载最小的节点读取与该待迁移的数据属于同一个第一业务的数据的版本号。

在上述技术方案中，由于第一节点从处于可信状态且负载最小的节点中读取与待迁移的数据属于同一个业务的数据的版本号，因此，可以保证读取的该版本号的准确性以及减少读取该版本号的时延。

第二方面，本申请实施例提供一种数据迁移装置，该装置包括处理器，用于实现上述第一方面描述的方法。所述装置还可以包括存储器，用于存储程序指令和数据。所述存储器与所述处理器耦合，所述处理器可以调用并执行所述存储器中存储的程序指令，用于实现上述第一方面描述的方法。所述装置还可以包括通信接口，所述通信接口用于该装置与其它设备进行通信。示例性地，该其它设备包括上述第一方面中提及的第二节点或至少一个第三节点。

在一种可能的设计中，该装置包括通信接口和处理器，具体地，在第二节点通过所述通信接口向所述装置迁移数据的过程中，所述处理器通过通信接口从所述第二节点读取待迁移的数据、所述待迁移的数据的版本号以及从至少一个第三节点中读取与所述待迁移的数据属于同一个第一业务的数据的版本号，所述第一业务的数据分布存储在所述第二节点和至少一个所述第三节点中；所述处理器确定从所述第二节点读取的待迁移的数据的版本号与从任意一个所述第三节点读取的数据的版本号不同时，所述处理器丢弃从所述第二节点读取的待迁移的数据。

在一种可能的设计中，所述处理器还用于从至少一个第三节点中读取与所述待迁移的数据属于同一个第一业务的数据的版本号之前，通过所述通信接口接收删除指令，所述删除指令指示所述第一节点及所述至少一个第三节点删除与所述第一业务对应的数据；所述第一节点为所述装置或者为所述装置所在的节点；所述处理器确定从所述第二节点读取的待迁移的数据的版本号与从任意一个所述第三节点读取的数据的版本号不同时，可以通过：确定从所述第二节点读取的待迁移的数据的版本号为正整数，且确定从任意一个所述第三节点读取的数据的版本号不存在来确定。

在一种可能的设计中，所述处理器还用于从至少一个第三节点中读取与所述待迁移的数据属于同一个第一业务的数据的版本号之前，通过所述通信接口接收改写指令，所述改写指令指示所述第一节点及所述至少一个第三节点改写与第一业务对应的数据；所述第一节点为所述装置或者为所述装置所在的节点；所述处理器确定从所述第二节点读取的待迁移的数据的版本号与从任意一个所述第三节点读取的数据的版本号不同时，可以通过确定从任意一个所述第三节点读取的数据的版本号大于从所述第二节点读取的待迁移的数据的版本号来确定。

在一种可能的设计中，所述处理器还可以从至少一个第三节点中读取到与所述待迁移的数据属于同一个第一业务的数据的版本号时，通过所述通信接口接收到操作指令，所述操作指令指示所述第一节点及所述至少一个第三节点删除或改写与第一业务对应的数据；所述第一节点为所述装置或者为所述装置所在的节点；然后，缓存所述操作指令所携带的操作版本号；然后，在确定从所述第二节点读取的待迁移的数据的版本号与从任意一个所述第三节点读取的数据的版本号相同时，可以进而确定从所述第二节点读取的待迁移的数据的版本号是否小于缓存的操作版本号，若是则丢弃从所述第二节点读取的待迁移的数据。

在一种可能的设计中，所述处理器从至少一个第三节点中读取与所述待迁移的数据属于同一个第一业务的数据的版本号时，具体可以通过从所述至少一个第三节点中确定处于可信状态的节点，所述可信状态为存储所述第一业务的数据的磁盘未发生故障、且存储所述第一业务的数据的磁盘上的数据是完整的；再从所述处于可信状态的节点读取与所述待迁移的数据属于同一个第一业务的数据的版本号。

在一种可能的设计中，所述处理器从至少一个第三节点中读取与所述待迁移的数据属于同一个第一业务的数据的版本号时，还具体可以通过从所述至少一个第三节点中确定处于可信状态的节点，所述可信状态为存储所述第一业务的数据的磁盘未发生故障、且存储所述第一业务的数据的磁盘上的数据是完整的；再从所述处于可信状态的节点中确定负载最小的节点；从所述负载最小的节点读取与所述待迁移的数据属于同一个第一业务的数据的版本号。

第三方面，本申请实施例提供一种数据迁移装置，该装置可以是第一节点，也可以是第一节点中的装置，该装置可以包括获取单元和处理单元，这些模块可以执行上述第一方面任一种设计示例中相应的功能，且这些模块可以通过软件模块实现，也可以通过相应的硬件实体实现，比如当通过相应的硬件实体实现时，获取单元的功能与上述第二方面中通信接口的功能类似，处理单元与上述第二方面中处理器的功能类似。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被计算机执行时，使所述计算机执行第一方面中任意一项所述的方法。

第五方面，本申请实施例提供一种计算机程序产品，所述计算机程序产品存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被计算机执行时，使所述计算机执行第一方面中任意一项所述的方法。

第六方面，本申请提供了一种芯片系统，该芯片系统包括处理器，还可以包括存储器，用于实现第一方面所述的方法。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

上述第二方面至第六方面及其实现方式的有益效果可以参考对第一方面的方法及其实现方式的有益效果的描述。

附图说明

图1a为本申请实施例中集群存储系统的一种可能的架构图；

图1b为本申请实施例中集群存储系统进行数据迁移的示意图；

图2a为本申请实施例中集群存储系统的另一种可能的架构图；

图2b为本申请实施例中集群存储系统的另一种可能的架构图；

图3为在现有技术中的数据迁移过程的流程图；

图4为本申请实施例提供的数据迁移方法的一种示例的流程图；

图5为本申请实施例提供的数据迁移方法的另一种示例的流程图；

图6为本申请实施例提供的数据迁移方法的另一种示例的流程图；

图7为本申请实施例提供的数据迁移装置的一种结构示意图；

图8为本申请实施例提供的数据迁移装置的另一种结构示意图。

具体实施方式

为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合说明书附图以及具体的实施方式对本申请实施例中的技术方案进行详细的说明。

本文中的术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，如无特殊说明，一般表示前后关联对象是一种“或”的关系。

另外，需要理解的是，本申请实施例涉及的“多个”，是指两个或大于两个。“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

本申请实施例提供一种数据迁移方法，该方法应用于集群存储系统中。该集群存储系统可以为文件存储系统、块存储系统或者对象存储系统，或者上述存储系统的组合，在本申请实施例中不作限制。

请参考图1a、图2a和图2b，为集群存储系统的三种可能的架构图。如图1a所示的集群存储系统已在前文中进行了描述，在此不再赘述。与图1a所示的集群存储系统不同的是，在图2a所示的集群存储系统中仅包含用于存储数据的多个存储节点，该多个存储节点构成的一种耦合的节点集合，协同起来对外提供服务。如图2a所示，该集群存储系统中包括存储节点1～存储节点3，其中每一个存储节点对数据的处理方式相同，当该集群存储系统获取待存储的数据后，将该待存储的数据分别存储在每一个存储节点中，例如，每一个存储节点均存储该待存储的数据的全部内容，相当于将待存储的数据复制成3份，每一个存储节点存储其中一份数据。

与图1a和图2a所示的架构不同的是，在图2b所示的架构中包括多个管理节点，例如管理节点a和管理节点b，这样，当该集群存储系统中的某一个管理节点发生故障时，该集群存储系统仍然可以通过其他的管理节点为与该集群存储系统交互的客户端提供服务。

需要说明的是，集群存储系统不限于如图1a、图2a和图2b所示的架构，本申请实施例描述的集群存储系统是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着存储技术和存储系统架构的演变，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

另外，如图1a、图2a和图2b所述的集群存储系统，可以采用如下两种方式来存储数据。以图1a所示的集群存储系统为例进行说明。第一种方式，当集群存储系统的管理节点a获取待存储的数据后，管理节点a可以将该待存储的数据复制多份，例如，复制为3份，然后将复制后的数据分别存储在不同的存储节点中，例如，可以将复制的3份数据分别存储在node1～node3中。这样，该集群存储系统中的某一个存储节点发生故障导致存储的数据丢失，该数据可以从其他存储节点中获取。第二种方式，当集群存储系统的管理节点a获取待存储的数据后，管理节点a将该待存储的数据分割成多份，然后对分割后的每一份数据进行编码，从而得到的多份数据分片，然后将多份数据分片分别存储在不同的存储节点中。这样，该集群存储系统中的某一个存储节点发生故障导致存储的数据丢失，管理节点a可以根据其他存储节点上存储的数据分片，重构出该待存储的数据。当然，集群存储系统也可以采用其他方式存储数据，在此不作限制。

如图1a、图2a和图2b所述的集群存储系统支持对存储系统的扩容，具体扩容的方式与如1b所示，在此不再赘述。当集群存储系统扩容后，则需要将原始存储节点中的一部分数据迁移到新增的存储节点中。当处于数据迁移的过程中的集群存储系统接收到删除某一数据的指令后，由于存储该数据的源磁盘不会接收该删除指令，因此，会导致该数据残留在目标磁盘中(具体请参照背景技术中的问题介绍)。

请参考图3，在现有技术中，集群存储系统为解决数据残留的问题，采用的处理方式如下，以图1b所示的数据迁移过程为例：

步骤301、node4(为新增节点)在从磁盘6中读取待迁移的数据并将读取到的数据写在磁盘7。

步骤302、node4在从磁盘6中读取待迁移的数据并将读取到的数据写在磁盘7的过程中，node44接收到管理节点a下发的用于删除数据a的删除指令或者截断(truncate)操作指令。此时，node4确定数据a并未存储在磁盘7中，则node4在删除日志中记录该删除指令或者截断(truncate)操作指令；

步骤303、node4继续从磁盘6中读取待迁移的数据并存储在磁盘7，直至将磁盘6中所有的数据迁移到磁盘7中，完成数据迁移；

步骤304、node4回放在删除日志中记录的删除指令或者截断(truncate)操作，从而将存储在磁盘7中的数据a删除。

在上述处理方式中，node4为了避免数据a在磁盘7中的残留，在将数据a从磁盘6迁移到磁盘7的过程中浪费了一次读数据的输入输出接口资源和一次写数据的输入输出接口资源。node4在将数据a从磁盘7删除时，浪费了一次删除数据的输入输出接口资源。可见，资源浪费较大。

鉴于此，本申请实施例提供一种数据迁移方法，用于减少在数据迁移过程中对数据进行删除时所消耗的资源。下面结合附图介绍本申请实施例提供的技术方案。

请参考图4，为本申请实施例提供的数据迁移方法的流程图，该流程的描述如下：

步骤401、第一节点确定第二节点向该第一节点迁移数据。

在本申请实施例中，第一节点为数据要迁移到的目标磁盘所在的存储节点，该第一节点可以为存储系统中的新增节点，第二节点为数据迁移出的源磁盘所在的存储节点。为方便描述，在下面的介绍过程中，以将本申请提供的数据迁移方法应用在图1a所示的集群存储系统。

当集群存储系统需要扩容，管理节点a确定将原始存储节点的一个磁盘中的数据迁移到新增存储节点的磁盘中，例如，如图1b所示，增加node4，管理节点确定将node3的磁盘6中的数据迁移到node4的磁盘7中。或者，管理节点a因为预定的策略，例如，为了保证数据存储的均衡，确定将剩余存储空间小于阈值的磁盘的一部分数据迁移到剩余存储空间较大的磁盘中。在这些情况下，管理节点a向数据迁移的目标磁盘所在的存储节点发送指令，该指令中可以携带源磁盘的标识以及源磁盘所在的存储节点的标识，这样，当目标磁盘所在的存储节点接收该指令后，则确定该数据迁移过程。当然，也可以是由其他原因触发数据迁移，在本申请中不作限制。

在下面的介绍中，以图1b所述的数据迁移过程为例。在图1b所示的数据迁移过程中，集群存储系统中由于新增node4，管理节点a确定将磁盘6中的数据迁移到磁盘7中，在这种情况下，以下过程以第一节点为磁盘7所在的node4，第二节点为磁盘6所在的node3为例。管理节点a向node4发送指令，node4在接收该指令后，确定node3的磁盘6中的数据需要迁移到磁盘7中。

步骤402、node4从node3中读取待迁移的数据。

当node4确定node3的磁盘6中的数据需要迁移到磁盘7后，node4则从磁盘6中读取待迁移的数据。node4从node3中读取待迁移的数据的方式包括但不限于如下两种：

第一种读取方式：

管理节点a预先设置集群存储系统中的各个存储节点之间进行数据迁移时的传输单元的大小。例如，管理节点a设置该传输单元的大小为10mb，则node4从磁盘6的起始存储位置开始，依次读取10mb大小的数据，当该10mb大小的数据完成数据迁移，node4再从磁盘6中读取下一份10mb大小的数据。

第二中读取方式：

管理节点a预先设置集群存储系统中的各个存储节点之间进行数据迁移时用于读取数据的时间单元的大小。例如，管理节点a设置该时间单元的大小为2s，则node4从磁盘6的起始存储位置开始，每次用2s的时间从磁盘6中读取数据，例如，node4在2s时间内从磁盘6中读取了20mb的数据，则当该20mb的数据完成数据迁移，node4再用2s从磁盘6中读取下一份数据。需要说明的是，若node4的性能不发生变化，则node4每次在该时间单元中读取的数据的大小相同，例如，node4第一次在2s内从磁盘6中读取了20mb数据，则node4每一次读取的数据的大小都为20mb。若node4的性能发生变化，例如，当node4中存储的数据量越大，则性能越低。在这种情况下，node4第一次在2s内从磁盘6中读取了20mb数据，则node4在第n次读取的数据的大小可能小于20mb。

由于集群存储系统中的各个存储节点的性能可能不相同，从而造成不同的存储节点在进行数据迁移时每次读取的待迁移的数据的大小不同，例如，node4在从其他存储节点读取待迁移的数据时，每次能够读取20mb的数据，而node2的性能低于node4，则node2在从其他存储节点读取待迁移的数据时，每次可能读取10mb的数据，可以增加数据迁移过程的灵活性。

步骤403、node4从node3中读取待迁移的数据的版本号。

作为一种示例，node4采用步骤402中的第一种读取方式，从磁盘6中读取10mb的数据，该10mb的数据为第一业务的数据，且该10mb的数据的版本号携带在该数据中，则node4直接从该数据中读取相应的版本号即可，即node4获取第一业务的数据的版本号，例如为2。

作为另一种示例，该数据中可能不携带数据的版本号，则当node4从node3的磁盘6中读取该10mb的数据后，可以先确定该10mb的数据所属的业务，例如，该10mb的数据属于第一业务，然后node4再从node3的磁盘6中获取该第一业务的数据的版本号，例如为2。

需要说明的是，在本申请实施例中，不对步骤402和步骤403的执行顺序进行限制，可以先执行步骤402在执行步骤403，也可以步骤402和步骤403同时执行，也就是说，node4在从node3中读取待迁移的数据时，同步获取该待迁移的数据的版本号。

另外，若node4采用步骤402中的第一种读取方式，从磁盘6中读取10mb的数据，该10mb的数据可能不属于同一个业务，例如，该10mb的数据中的前5mb的数据属于第一业务，后5mb的数据属于第二业务。在这种情况下，node4从node3中读取待迁移的数据的版本号则为2个，分别为磁盘6中存储的第一业务的数据的版本号和第二业务的数据的版本号。当然，若该10mb的数据中分别包含3个或3个以上的业务的数据时，则node4从node3中读取的待迁移的数据的版本号的个数也为3个或3个以上。在本申请实施例中，node4每次从node3中读取的数据的版本号的个数可以为1个或者多个，在此不作限制。

步骤404、node4从至少一个第三节点中读取与待迁移的数据属于同一个业务的数据的版本号。

下面，对第三节点进行说明。在本申请实施例中，第三节点可以是集群存储系统中，除数据迁移出的源磁盘所在的节点与数据要迁移到的目标磁盘所在的节点外的其他节点。以图1b所示的应用场景为例，该集群存储系统中包括node1～node4，而node3和node4分别为磁盘6和磁盘7所在的节点，因此，第三节点则为node1和/或node2。在这种情况下，第三节点的个数可以为1个或2个。当然，若集群存储系统中还包括其他节点，例如node5、node6，则第三节点的个数也可以为2个以上。或者，若集群存储系统中只包括3个节点，例如，node2～node4，则第三节点则为node2，第三节点的个数为1个。

由于在集群存储系统中，每一个业务的数据都是以分布式存储的方式存储在nlun中的。以业务a的数据为例，当将业务a的数据存储在集群存储系统时，集群存储系统的管理节点a根据业务a的类型确定将业务a的数据存储在nlun1中，由于nlun1的成员盘的集合为磁盘{1,2,3,4,5,6}，因此，管理节点a会将业务a的数据拆分成6个数据块，然后分别存储在nlun1的每一个成员盘中。每一个数据块可以携带业务a的标识，这样，当管理节点a需要获取业务a的数据时，则分别从每个成员盘中读取携带有业务a的标识的数据块即可。

当第三节点的个数为2个或者2个以上时，node4从至少一个第三节点中读取与待迁移的数据属于同一个业务的数据的版本号的方法，包括但不限于如下三种情况。以第三节点包括node1和node2为例。

第一种情况：

node4从每一个第三节点中读取与待迁移的数据属于同一个业务的数据的版本号。例如，node4采用步骤402中的第一种读取方式，从磁盘6中读取10mb的数据，然后，node4确定该10mb的数据中携带第一业务的标识，例如，业务a的标识，则node4分别从node1中读取业务a的数据的版本号，以及从node2中读取业务a的数据的版本号。

第二种情况：

node4从至少一个第三节点中处于可信状态的节点读取与待迁移的数据属于同一个业务的数据的版本号。在本申请实施例中，可信状态为用于存储业务的数据的磁盘未发生故障且用于存储业务的数据的磁盘上的数据是完整的。

具体来讲，可信状态可以由集群存储系统中的管理节点a确定。例如，管理节点a可以定时轮询发送一个自定义的信息，例如心跳包或心跳帧，给集群存储系统中的各个节点，若管理节点a能够从某个节点中接收与该自定义的信息对应的反馈信息，则认为该节点未发生故障。或者，集群存储系统中的每个节点可以按照一定的时间间隔发送该自定义的信息，当管理节点a接收该自定义的信息后，则确定该节点未发生故障。该自定义的信息的具体内容可以是管理节点a与各个节点约定的内容，也可以是只包含包头的一个空包，在此不作限制。各个节点可以向管理节点a上报该节点中每个磁盘的状态。每个磁盘的状态可以包括正常状态以及故障状态，若磁盘可以提供读操作以及写操作的服务，则该磁盘为正常状态；若磁盘无法提供读操作的服务或者无法提供写操作的服务，则该磁盘为故障状态。管理节点a可以根据每个节点上报的磁盘的状态确定各个磁盘是否发生故障。当然，若某个节点发生故障，则管理节点a确定该节点中的每个磁盘发生故障。另外，当管理节点a控制两个磁盘之间进行数据迁移时，例如，管理节点a控制node4将node3的磁盘6中的数据迁移到磁盘7中，则管理节点a确定进行数据迁移的两个磁盘上的数据不是完整的，以及确定未发生数据迁移的磁盘上的数据是完整的。

管理节点a在获取上述信息后，则根据上述信息，确定每个节点是否处于可信状态。在本申请实施例中，管理节点a确定每个节点是否处于可信状态的方式可以包括但不限于如下两种：

第一种确定方式，若某个节点上的每一个磁盘均未发生故障且每个磁盘上的数据都是完整的，则管理节点a可以标记该节点为可信状态，否则，管理节点a标记该节点为非可信状态。

第二种确定方式，管理节点a根据上述信息，确定针对每一个业务，每个节点的可信状态。例如，针对业务a，用于存储该业务a的数据的磁盘为磁盘1～磁盘5，磁盘1和磁盘2为node1上的磁盘，磁盘3和磁盘4为node2上的磁盘，磁盘5为node3上的磁盘。若管理节点a确定磁盘1发生故障，磁盘2～磁盘5未发生故障且数据完整，则针对业务a处于可信状态的节点为node2和node3。node1中由于存在发生故障的磁盘1，因此，node1为非可信状态。在这种情况下，即使node3中的磁盘6发生数据迁移，但由于磁盘6并未存储业务a的数据，因此，针对业务a而言，node3仍然处于可信状态。

管理节点a可以采用上述两种确定方式中的其中一种，确定并记录每个节点的状态，该状态为处于可信状态或处于非可信状态。管理节点a可以将每个节点的状态发送给各个节点，或者，各个节点也可以从管理节点a中查询该状态。当然，由于磁盘的状态可能是实时发生变化的，因此，管理节点a确定的每个节点的状态也需要实时进行更新，具体更新的方法在本申请实施例中不作限制。

在这种情况下，node4从至少一个第三节点中处于可信状态的节点读取与待迁移的数据属于同一个业务的数据的版本号的过程如下：node4采用步骤402中的第一种读取方式，从磁盘6中读取10mb的数据，确定该数据中携带业务a的标识。然后，node4通过管理节点a确定node1和node2均处于可信状态，则node4分别从node1中读取业务a的数据的版本号，以及从node2中读取业务a的数据的版本号。

由于node4从处于可信状态的节点中读取与待迁移的数据属于同一个业务的数据的版本号，因此，可以保证读取的该版本号的准确性。

第三种情况：

node4从所述至少一个第三节点中处于可信状态且负载最小的节点读取与待迁移的数据属于同一个业务的数据的版本号。

在这种情况下，可信状态的定义与确定方式与步骤404的第二种情况中相应的内容相同，在此不再赘述。

管理节点a还可以统计并记录每个节点的负载，例如，该负载可以是每个节点中存储的数据的大小。管理节点a可以将每个节点的负载发送给各个节点，或者，各个节点也可以从管理节点a中查询每个节点的负载。当然，由于负载是实时发生变化的，因此，管理节点a也需要实时更新记录的每个节点的负载，具体更新的方法在本申请实施例中不作限制。

在这种情况下，node4从至少一个第三节点中处于可信状态且负载最小的节点读取与待迁移的数据属于同一个业务的数据的版本号的过程如下：node4采用步骤402中的第一种读取方式，从磁盘6中读取10mb的数据，确定该数据中携带业务a的标识。然后，node4通过管理节点a确定node1和node2均处于可信状态，且node1的负载最小，则node4从node1中读取业务a的数据的版本号。

由于node4从处于可信状态且负载最小的节点中读取与待迁移的数据属于同一个业务的数据的版本号，因此，可以保证读取的该版本号的准确性以及减少读取该版本号的时延。

为方便说明，在下面的描述中，以node4则从node3中读取待迁移的数据的版本号以及从至少一个第三节点中处于可信状态且负载最小的节点的node1中读取与待迁移的数据属于同一个业务的数据的版本号为例。

需要说明的是，在本申请实施例中，node4每次从node3中读取的数据的版本号的个数与node4每次从node1中读取的数据的版本号的个数相同。也就是说，若步骤403中，node4从node3中读取待迁移的数据的版本号则为1个，则相应地，node4从node1中读取与该待迁移的数据属于同一个业务的数据的版本号也为1个；若node4从node3中读取待迁移的数据的版本号则为多个，则相应地，node4从node1中读取与该待迁移的数据属于同一个业务的数据的版本号也为多个。

另外，为了减少数据迁移的时延，步骤403和步骤404也可以同时执行。在本申请实施例中不对步骤403和步骤404的执行顺序进行限制。

步骤405、node4接收用户下发的对第一业务的数据进行操作的指令。

由于数据迁移过程对用户是透明的，用户并不知道集群存储系统是否正处于数据迁移过程，因此，在node3的磁盘6向node4的磁盘7迁移数据时，有可能会接收用户下发的对第一业务的数据进行操作的指令。该指令可以是删除指令，该删除指令指示node1～node4删除与第一业务对应的数据，该指令也可以是改写指令，该改写指令指示node1～node4改写与第一业务对应的数据，当然，也可以是其他指令，在本申请实施例中，以该指令为删除指令为例进行说明。

需要说明的是，该指令不影响node4执行步骤403～步骤404，也就是说，在node3的磁盘6开始向node4的磁盘7迁移数据时，步骤402～步骤404已经开始执行。但是，由于步骤405中的指令是用于对集群存储系统中存储的第一业务的数据进行的操作，若该第一业务存储在集群存储系统中的nlun1中，则管理节点a会将该指令下发给nlun1的每个成员盘所在的节点。由于在该指令下发之前，nlun1的成员盘的磁盘集合已由集合{0,1,2,3,4,5,6}更新为{0,1,2,3,4,5,7}，因此，node3在收到该指令后，不会将该指令下发给磁盘6，而该nlun1的其他成员盘在收到该指令后，则会对该第一业务的数据进行相应地操作，例如，删除第一业务的数据，或者改写第一业务的数据。也就是说，当node4接收到该指令，也就表示nlun1的其他成员盘所在的节点也收到该指令。那么，当其他节点对第一业务的数据进行操作后，数据的版本号会发生改变，因此，步骤405会影响步骤404的执行结果。下面，对步骤405对步骤404的执行结果的影响进行说明。

在本申请实施例中，请参考图4，以node4在执行步骤403以及步骤404之前执行步骤405，即node4在从node1中读取第一业务的数据的版本号之前接收该指令，且该指令为指示删除第一业务的数据的删除指令为例进行说明。

当node4接收该删除指令，则node1～node3也接收该删除指令。从而node1～node3分别将磁盘1～磁盘5中存储的第一业务的数据删除。当执行删除操作后，各个磁盘中便不存在该第一业务的数据，从而磁盘1～磁盘5中第一业务的数据的版本号则为不存在。若步骤404获取的是第一业务的数据的版本号，则步骤404的执行结果为不存在。

步骤406、node4确定从node3读取的待迁移的数据的版本号与从node1中读取的数据的版本号的大小关系。

以node4从node3的磁盘6中读取的待迁移的数据为第一业务的数据为例。由于磁盘6中的数据需要迁移到磁盘7中，因此，node3不会将接收的删除指令下发给磁盘6，因此，磁盘6中第一业务的数据的版本号为未进行操作之前的版本号，例如，未进行操作之前第一业务的数据的版本号为2。而node4从node1中读取的第一业务的数据的版本号不存在，则node4确定从node3读取的待迁移的数据的版本号与从node1中读取的数据的版本号不同。

步骤407、node4确定从node3读取的待迁移的数据的版本号与从node1中读取的数据的版本号不同时，丢弃从node3中读取的待迁移的数据。

请继续参考图4，node4确定从node3读取的待迁移的数据的版本号与从node1中读取的数据的版本号不同，则认为node4从node3的磁盘6中读取的第一业务的数据为旧数据，从而丢弃读取的第一业务的数据。

需要说明的是，node4从磁盘6中读取的待迁移的数据，可能包含有不同的业务的数据，例如，该10mb的数据中的前5mb的数据属于第一业务，后5mb的数据属于第二业务。若node4确定从node3读取的第一业务的数据的版本号与从node1中读取的第一业务的数据的版本号不同，但从node3读取的第二业务的数据的版本号与从node1中读取的第二业务的数据的版本号相同，则node4仅丢弃读取的待迁移的数据中的第一业务的数据，例如，该10mb的数据中的前5mb的数据，而将该10mb的数据中的后5mb的数据写入磁盘7中。

然后，node4采用前述方法，继续从磁盘6中读取待迁移的数据，直至完成数据迁移。

在上述技术方案中，在数据迁移时，通过比较待迁移的数据的版本号与其他节点中与待迁移的数据属于同一业务的数据的版本号，从而过滤掉要删除数据，可以减少无效迁移和后续删除io资源的浪费。进一步地，由于可以减少无效迁移和后续删除io资源的浪费，从而可以降低数据迁移过程对业务的影响，可以提高迁移性能和可靠性。

由于不同的操作指令，对集群存储系统中存储的数据的版本号的影响不同，例如，当集群存储系统接收删除操作指令时，数据删除后，该数据的版本号则不存在；当集群存储系统接收改写操作指令时，数据改写后，该数据的版本号会增大。在前述实施例中以该操作指令为删除操作指令为例进行了说明，下面，以该操作指令为改写操作为例，介绍集群存储系统的数据迁移过程。

请参考图5，为本申请实施例提供的数据迁移方法的流程图，该流程的描述如下：

步骤501、第一节点确定第二节点向该第一节点迁移数据。

步骤502、node4从node3中读取待迁移的数据。

步骤503、node4从node3中读取待迁移的数据的版本号。

步骤504、node4从至少一个第三节点中读取与待迁移的数据属于同一个业务的数据的版本号。

步骤501～步骤504与步骤401～步骤404相同，在此不再赘述。

步骤505、node4接收用户下发的对第一业务的数据进行操作的指令。

以node4在执行步骤403以及步骤404之前执行步骤405，即node4在从node1中读取第一业务的数据的版本号之前接收该指令，且该指令为指示改写第一业务的数据的改写指令为例进行说明：

当node4接收该改写指令，则node1～node3也接收该改写指令。从而node1～node3分别根据改写指令，将磁盘1～磁盘5中存储的第一业务的数据进行改写。需要说明的是，第一业务的数据的版本号与集群存储系统对该数据的操作相关。具体来讲，当集群存储系统执行写入操作，将第一业务的数据写入磁盘时，第一业务的数据在所写入的每个磁盘的版本号均为1。以第一业务的数据所写入的磁盘的磁盘集合为磁盘{0,1,2,3,4,5,6}为例，则磁盘{0,1,2,3,4,5,6}中的每个磁盘中第一业务的数据的版本号为1。然后，若集群存储系统接收改写操作，对第一业务的数据进行改写，则磁盘集合{0,1,2,3,4,5,6}中的每个磁盘中第一业务的数据的版本号增加1，变为2，以此类推，每当集群存储系统对第一业务的数据进行一次操作后，各个磁盘中第一业务的数据的版本号则增加1。

在这种情况下，当执行改写操作后，磁盘1～磁盘5中第一业务的数据的版本号则增加1，假设执行改写操作之前，第一业务的数据的版本号为2，则执行步骤505之后再执行步骤504，则步骤504获取的第一业务的数据的版本号即为3。

步骤506、node4确定从node3读取的待迁移的数据的版本号与从node1中读取的数据的版本号的大小关系。

以步骤504的执行结果为第一业务的数据的版本号为3，且node4从node3的磁盘6中读取的待迁移的数据为第一业务的数据为例。由于磁盘6中的数据需要迁移到磁盘7中，因此，node3不会将接收的改写指令下发给磁盘6，因此，磁盘6中第一业务的数据的版本号为未进行操作之前的版本号，例如，未进行操作之前第一业务的数据的版本号为2。而node4从node1中读取的第一业务的数据的版本号为3，则node4确定从node3读取的待迁移的数据的版本号小于从node1中读取的数据的版本号。

步骤507、node4确定从node3读取的待迁移的数据的版本号与从node1中读取的数据的版本号不同时，丢弃从node3中读取的待迁移的数据。

请继续参考图5，node4确定从node3读取的待迁移的数据的版本号小于从node1中读取的数据的版本号，则认为node4从node3的磁盘6中读取的第一业务的数据为旧数据，从而丢弃读取的第一业务的数据。

需要说明的是，node4从磁盘6中读取的待迁移的数据，可能包含有不同的业务的数据，例如，该10mb的数据中的前5mb的数据属于第一业务，后5mb的数据属于第二业务。若node4确定从node3读取的第一业务的数据的版本号与从node1中读取的第一业务的数据的版本号不同，但从node3读取的第二业务的数据的版本号与从node1中读取的第二业务的数据的版本号相同，则node4仅丢弃读取的待迁移的数据中的第一业务的数据，例如，该10mb的数据中的前5mb的数据，而将该10mb的数据中的后5mb的数据写入磁盘7中。

然后，node4采用前述方法，继续从磁盘6中读取待迁移的数据，直至完成数据迁移。

在前述实施例中，以删除操作指令和改写操作指令为例，介绍了不同的操作指令对集群存储系统中存储的数据的版本号的影响。然而，操作指令下发的时机不同，也会影响node4从至少一个第三节点中读取与待迁移的数据属于同一个业务的数据的版本号的结果。下面，以操作指令和node4从至少一个第三节点中读取与待迁移的数据属于同一个业务的数据的版本号并发为例，介绍集群存储系统的数据迁移过程。

请参考图6，为本申请实施例提供的数据迁移方法的流程图，该流程的描述如下：

步骤601、第一节点确定第二节点向该第一节点迁移数据。

步骤602、node4从node3中读取待迁移的数据。

步骤603、node4从node3中读取待迁移的数据的版本号。

步骤604、node4从至少一个第三节点中读取与待迁移的数据属于同一个业务的数据的版本号。

步骤601～步骤604与步骤401～步骤404相同，在此不再赘述。

步骤605、node4接收用户下发的对第一业务的数据进行操作的指令。

以node4在从node1中读取第一业务的数据的版本号的同一时刻接收该指令，且该指令可以为指示删除第一业务的数据的删除指令或者该指令为指示改写第一业务的数据的改写指令为例进行说明。

当node4接收该指令，则node1～node3也接收该指令。由于步骤604和步骤605同时执行，node1还未对第一业务的数据进行任何操作，node4已经从node1中读取了第一业务的数据，在这种情况下，node4从node1中读取的第一业务的数据的版本仍然为进行操作之前的版本号，例如，进行操作之前第一业务的数据的版本号为2，则步骤604获取的第一业务的数据的版本号即为2。

步骤606、node4确定从node3读取的待迁移的数据的版本号与从node1中读取的数据的版本号的大小关系。

以步骤604的执行结果为第一业务的数据的版本号为2，且node4从node3的磁盘6中读取的待迁移的数据为第一业务的数据为例。由于磁盘6中的数据需要迁移到磁盘7中，因此，node3不会将接收的指令下发给磁盘6，因此，磁盘6中第一业务的数据的版本号为未进行操作之前的版本号，例如，未进行操作之前第一业务的数据的版本号为2。而node4从node1中读取的第一业务的数据的版本号为2，则node4确定从node3读取的待迁移的数据的版本号与从node1中读取的数据的版本号相同。

需要说明的是，node4从磁盘6中读取的待迁移的数据，可能包含有不同的业务的数据，例如，该10mb的数据中的前5mb的数据属于第一业务，后5mb的数据属于第二业务。在这种情况下，node4需要对不同的业务的数据的版本号分别进行判断，具体判断方式与步骤404相同，在此不再赘述。

步骤607、node4缓存接收的操作指令。

在本申请实施例中，缓存该操作指令即缓存该操作指令所携带的操作版本号和/或该操作指令所指示的与第一业务对应的数据的起始偏移量以及数据长度。缓存时间可以是20s、30s等，当然也可以是其他时长，在此不作限制。这样，当缓存该操作的时长达到该缓存时间后，则可以自动删除该操作指令，从而释放缓存空间。

需要说明的是，步骤607可以在步骤606之前执行，也可以在步骤606之后执行，在此不作限制。在图6中，以步骤607在步骤606之前执行为例。

步骤608、node4确定从node3读取的待迁移的数据的版本号小于所缓存的该操作指令所携带的操作版本号时，丢弃从node3中读取的待迁移的数据。

当node4确定从node3读取第一业务的数据的版本号与从node1中读取的数据的版本号相同，则node4比较从node3读取的第一业务的数据的版本号与所缓存的操作指令的操作版本号。以步骤604获取的第一业务的数据的版本号为2，所缓存的操作指令的操作版本号为3为例，node4确定待迁移的数据的版本号低于操作指令的操作版本号，从而确定待迁移的数据为旧数据，从而丢弃该待迁移的数据。

需要说明的是，node4从磁盘6中读取的待迁移的数据，可能包含有不同的业务的数据，例如，该10mb的数据中的前5mb的数据属于第一业务，后5mb的数据属于第二业务。在这种情况下，node可以首先根据从node3中读取的待迁移的数据的起始位置和终止位置，以及缓存的操作指令中指示的数据的起始偏移量和数据长度，确定从node3中读取的待迁移的数据是否为该操作指令要进行操作的数据，即，node4确定从node3中读取的待迁移的数据的起始位置和终止位置是否位于该操作指令所指示起始偏移量和该起始偏移量与数据长度之和对应的偏移量之间，若是，则该从node3中读取的待迁移的数据是该操作指令要进行操作的数据。例如，node4确定操作指令要进行操作的数据仅为该10mb的数据中的前5mb的数据，从而将该10mb的数据中的后5mb的数据(即第二业务的数据)写入磁盘7中。然后，node4则判断该操作指令的操作版本号与从node3读取的第一业务的数据的版本号的大小关系。根据步骤405中描述的操作指令的版本号与对应的数据的数据版本号之间的关系可知，由于磁盘6未接收该操作指令，因此，从node3读取的第一业务的数据的版本号小于该操作指令的操作版本号，从而node4丢弃该待迁移的数据。

然后，node4采用前述方法，继续从磁盘6中读取待迁移的数据，直至完成数据迁移。

在上述技术方案中，通过在数据迁移的目标磁盘所在的节点缓存操作指令，例如，缓存30s，从而，即使由于读取待迁移的数据的版本号和操作指令并发，数据迁移的目标磁盘所在的节点会读到已经删除的数据的版本号或者改写之前的数据的版本号，数据迁移的目标磁盘所在的节点也可以根据缓存的操作指令，丢弃已经删除或者已经改写的数据，可以解决并发导致的数据残留的问题，可以减少无效迁移和后续删除io资源的浪费、降低数据迁移过程对业务的影响，以及提高迁移性能和可靠性。

另外，需要说明的是，上述从可信状态也可以应用在元数据恢复场景、节点/磁盘故障转移场景或者对读取的业务数据的有效性进行判断的场景中。例如，在元数据恢复场景中，当某个磁盘中的数据发生故障后，可以从其他磁盘中确定出处于可信状态的磁盘，然后根据处于可信状态的磁盘中的数据进行元数据恢复，从而可以保证恢复的元数据的可靠性。在节点/磁盘故障转移场景，当某个节点/磁盘发生故障后，可以从其他节点/磁盘中确定出处于可信状态的节点/磁盘，然后故障转移到处于可信状态的节点/磁盘中，从而可以保证业务的连续性。在其他各个场景中，对可信状态的应用方法相似，在此不再一一举例。

上述本申请提供的实施例中，分别从第一节点、第二节点及至少一个第三节点之间交互的角度对本申请实施例提供的方法进行了介绍。为了实现上述本申请实施例提供的方法中的各功能，第一节点可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。

图7示出了一种数据迁移装置700的结构示意图。其中，数据迁移装置700可以是第一节点，能够实现本申请实施例提供的方法中第一节点的功能；数据迁移装置700也可以是能够支持第一节点实现本申请实施例提供的方法中第一节点的功能的装置。数据迁移装置700可以是硬件结构、软件模块、或硬件结构加软件模块。数据迁移装置700可以由芯片系统实现。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

数据迁移装置700可以包括获取单元701和处理单元702。

获取单元701可以用于执行图4所示的实施例中的步骤402以及步骤405，和/或用于执行图5所示的实施例中的步骤502以及步骤505，和/或用于执行图6所示的实施例中的步骤602以及步骤605，和/或用于支持本文所描述的技术的其它过程。获取单元701用于数据迁移装置700和其它模块进行通信，其可以是电路、器件、接口、总线、软件模块、收发器或者其它任意可以实现通信的装置。

处理单元702可以用于执行图4所示的实施例中的步骤401、步骤403、步骤404以及步骤406-步骤407，和/或用于执行图5所示的实施例中的步骤501、步骤503、步骤504以及步骤506-步骤507，和/或用于执行图6所示的实施例中的步骤601、步骤603、步骤604以及步骤606-步骤608，和/或用于支持本文所描述的技术的其它过程。

其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

如图8所示为本申请实施例提供的数据迁移装置800，其中，数据迁移装置800可以是图4、图5或图6所示的实施例中的第一节点，能够实现本申请图4、图5或图6所示的实施例中的第一节点的功能；数据迁移装置800也可以是能够支持第一节点实现本申请图4、图5或图6所示的实施例提供的方法中第一节点的功能的装置。其中，该数据迁移装置800可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

数据迁移装置800包括至少一个处理器820，用于实现或用于支持数据迁移装置800实现本申请图4、图5或图6所示的实施例中的第一节点的功能。示例性地，处理器820可以从第二节点中读取第一业务的数据的版本号或者从至少一个第三节点中读取属于第一业务的数据的版本号，具体参见方法示例中的详细描述，此处不做赘述。

数据迁移装置800还可以包括至少一个存储器830，用于存储程序指令和/或数据。存储器830和处理器820耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器820可能和存储器830协同操作。处理器820可能执行存储器830中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。当处理器820执行存储器830中的程序指令时，可以实现图4-图6所示的方法。

数据迁移装置800还可以包括通信接口810，用于通过传输介质和其它设备进行通信，从而用于数据迁移装置800中的装置可以和其它设备进行通信。示例性地，该其它设备可以是客户端。处理器820可以利用通信接口810收发数据。

本申请实施例中不限定上述通信接口810、处理器820以及存储器830之间的具体连接介质。本申请实施例在图8中以存储器830、处理器820以及通信接口810之间通过总线840连接，总线在图8中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

在本申请实施例中，处理器820可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

在本申请实施例中，存储器830可以是非易失性存储器，比如硬盘(harddiskdrive，hdd)或固态硬盘(solid-statedrive，ssd)等，还可以是易失性存储器(volatilememory)，例如随机存取存储器(random-accessmemory，ram)。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

本申请实施例中还提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行图4-图6所示的实施例中第一节点执行的方法。

本申请实施例中还提供一种计算机程序产品，包括指令，当其在计算机上运行时，使得计算机执行图4-图6所示的实施例中第一节点执行的方法。

本申请实施例提供了一种芯片系统，该芯片系统包括处理器，还可以包括存储器，用于实现前述方法中第一节点的功能。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

本申请实施例提供的方法中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digitalsubscriberline，简称dsl)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机可以存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digitalvideodisc，简称dvd))、或者半导体介质(例如，ssd)等。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。