CN113468135B - 数据迁移方法、系统、设备及产品 - Google Patents

Abstract

本申请实施例提供数据迁移方法、系统、设备及产品。该方法包括：将第一节点上的待迁移对象在第一时刻时的数据信息及第一时刻后的与待迁移对象有关的增量数据传输至第二节点，以便第二节点迁入待迁移对象。在待迁移对象迁移进度参数满足预置条件时，启动双运行工作模式；未提交的针对待迁移对象的第一节点事务将执行中产生的增量数据传输至第二节点；若存在针对待迁移对象的第二节点事务，将第二节点事务路由至第二节点。本申请提供的技术方案，启动双运行工作模式，第一节点可以继续执行未提交的针对待迁移对象的第一节点事务，将针对待迁移对象进行访问的第二节点事务路由到第二节点中对应的目标对象执行，实现对待迁移对象在线无中断迁移。

Description

数据迁移方法、系统、设备及产品

技术领域

本申请涉及计算机技术领域，尤其涉及数据迁移方法、系统、设备及产品。

背景技术

随着分布式数据库技术的发展，分布式数据库规模也越来越大，可能会出现负载倾斜等问题，数据库节点迁移需求随之产生。

在现有分布式数据库的迁移作业中，为了不影响对事务的正常执行，通常会采取在线迁移的方式。然而，在线迁移过程中，可能会出现停机或者迁移导致事务中断的问题。虽然有一些迁移方案能够实现在不中断事务的情况下进行在线迁移，但是迁移过程对分布式数据库系统性能要求较高，而且会造成较大的数据开销。

发明内容

为解决或改善现有技术中存在的问题，本申请各实施例提供了数据迁移方法、系统、设备及产品。

第一方面，在本申请的一个实施例中，提供了一种数据迁移方法。该方法包括：

将第一节点上的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至第二节点，以便所述第二节点迁入所述待迁移对象；

获取反映所述待迁移对象迁移进度的参数；

在所述参数满足预置条件时，启动双运行工作模式；

在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述第二节点；

在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述第二节点，以由所述第二节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务。

第二方面，在本申请的一个实施例中，提供了另一种数据迁移方法。该方法包括：

存储第一节点传输的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据；

基于所述数据信息及所述增量数据，执行迁入操作，以生成与所述待迁移对象数据同步的迁入对象；

接收到针对所述迁入对象的第二节点事务时，启动冲突检测；

在通过所述冲突检测后，执行所述第二节点事务。

第三方面，在本申请的一个实施例中，提供了一种数据迁移系统。所述系统包括：

源节点和至少一个目的节点；

所述源节点，用于将待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至所述目的节点，以便所述目的节点迁入所述待迁移对象；获取反映所述待迁移对象迁移进度的参数；在所述参数满足预置条件时，启动双运行工作模式；在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述目的节点；在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述目的节点，以由所述目的节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务；

所述目的节点，用于存储源节点传输的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据；基于所述数据信息及所述增量数据，执行迁入操作，以生成与所述待迁移对象数据同步的迁入对象；接收到针对所述迁入对象的第二节点事务时，启动冲突检测；在通过所述冲突检测后，执行所述第二节点事务。

第四方面，在本申请的一个实施例中，提供了一种电子设备，包括存储器及处理器；其中，

所述存储器，用于存储程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于实现第一方面所述的一种数据迁移方法或第二方面所述的另一种数据迁移方法。

第五方面，在本申请的一个实施例中，提供了一种计算机程序产品，包括计算机程序/指令，当所述计算机程序/指令被处理器执行时，致使所述处理器能够实现第一方面所述的一种数据迁移方法或第二方面所述的另一种数据迁移方法。

本申请实施例提供的技术方案，将第一节点上的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至第二节点，以便所述第二节点迁入所述待迁移对象；获取反映所述待迁移对象迁移进度的参数；在所述参数满足预置条件时，启动双运行工作模式；在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述第二节点；在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述第二节点，以由所述第二节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务。采用上述技术方案，在参数满足预置条件的时候，启动双运行工作模式，也就是第一节点可以继续执行未提交的针对待迁移对象的第一节点事务，而且将执行中产生的增量数据传输到第二节点。同时，对路由关系进行修改，以便将针对待迁移对象进行访问的第二节点事务路由到第二节点中对应的目标对象执行，从而实现对待迁移对象的在线无中断迁移。

附图说明

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

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

图2为本申请实施例提供的分布式数据库中源节点与目的节点的连接关系的结构示意图；

图3为本申请实施例提供的数据信息生成方法的流程示意图；

图4为本申请实施例提供的修改信息传输方法的流程示意图；

图5为本申请实施例提供的修改数据传输的框架示意图；

图6为本申请实施例提供的修改事务执行方法的流程示意图；

图7为本申请实施例提供的分区路由表修改的示意图；

图8为本身实施例提供的另一种数据迁移方法的流程示意图；

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

图10为本申请实施例提供的一种电子设备的结构示意图；

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

图12为本申请实施例提供的另一种电子设备的结构示意图。

具体实施方式

在现有技术当中，分布式数据库技术的发展，分布式数据库系统变得越来越庞大复杂，对于其中任何一个节点的改动都会关系到整体系统的稳定性。然而，随着实际应用需求增多的同时所要解决的问题也在增多。比如需要解决负载均衡问题等，则需要对数据库节点进行迁移。为了减小数据迁移过程中对分布式数据库系统正常工作的不利影响，通常采用在线迁移的方式。

现有的在线迁移方案有很多种，比如，Squall、MgCrab、ProRea等方案。利用这些方案在进行在线迁移过程中均存在各种各样的问题。比如，Squall依赖于每数据分区的锁来保证迁移数据的一致性，会造成比较大的同步开销；MgCrab局限于Deterministic数据库，需要事先知道事务的读写访问集合才能进行迁移；ProRea存在同步开销较大的问题。因此，本申请技术方案提出一种能够实现低开销无中断在线迁移技术方案。

需要说明的是，分布式数据库总体架构，有两个思路和方向，一个是基于共享存储的架构，另一个是基于数据分片的架构。本方案是基于数据分片的分布式数据库。数据分片架构的特点是底层数据通过一定的规则，如hash或range让数据分别分布到不同的数据库节点上，计算时底层多个节点共同参与计算，同时节点可以扩展。这里所说的数据库节点可以是硬件节点也可以是虚拟节点。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。此外，下文描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请技术方案中，假设需要将分布式数据库中的数据从源节点迁移到目的节点。利用Remus技术进行在线迁移，下面将通过具体实施例进行说明。

如图1为本申请实施例提供的数据迁移方法的流程示意图。在实际应用场景中，该方法的执行主体可以是分布式数据库中数据库节点，也可以称之为源节点。该方法具体包括如下步骤：

101：将第一节点上的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至第二节点，以便所述第二节点迁入所述待迁移对象。

102：获取反映所述待迁移对象迁移进度的参数。

103：在所述参数满足预置条件时，启动双运行工作模式。

104：在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述第二节点。

105：在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述第二节点，以由所述第二节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务。

如图2为本申请实施例提供的分布式数据库中源节点与目的节点的连接关系的结构示意图。从图2中可以看到，在源节点中包含有多个待迁移对象shard1，以及在目的节点中包含有多个目标对象shard2。在不中断任何事务的情况下，将源节点中的待迁移对象shard1迁移到目的节点中目标对象shard2。

在实际应用中，采用在线迁移的方式（也就是将一个待迁移对象shard1从源节点迁移到目的节点），在迁移过程中时刻存在新的数据信息、增量数据的产生。可以将源节点中的待迁移对象shard1的迁移过程整体思路如下：先采用异步模式将待迁移对象在第一时刻时的数据信息以及第一时刻之后该待迁移对象的增量数据传输至迁入节点（即第二节点），并在传输过程中监听模式切换触发事件，在监听到该触发事件（Sync为true）时将异步模式切换为同步模式，并启动双运行工作模式。在该双运行工作模式下，第一节点上已执行的事务（即未提交的针对所述待迁移对象的至少一个第一节点事务）可继续执行直至提交；并能持续的采用同步模式将执行中产生的增量数据传输至第二节点，以使第二节点能在本地生成一个与待迁移对象数据同步的迁入对象。在执行至少一个第一节点事务期间（即至少一个第一节点事务均完成提交之前），若出现针对待迁移对象的第二节点事务，则可将该第二节点事务路由至第二节点，由第二节点执行该第二节点事务。对待迁移对象shard1迁移的过程中，在保证不中断第一节点事务的在线迁移的同时，还要确保迁移过程中的分布式一致性与隔离性等。

假设，针对第一节点（源节点）上的待迁移对象（shard1）在第一时刻开始执行迁移操作。则，需要将第一时刻及以前所产生的所有数据信息都迁移到第二节点（目的节点）中，在实际迁移过程中，如果数据信息比较多，可以采用分批次多轮次迭代迁移的方式。在执行迁移操作之前，需要在第二节点创建一个空的shard，进而利用多版本并发控制在第一时刻为源节点待迁移对象shard1创建快照，进而实现将快照拷贝到第二节点。为了便于理解，在下述实施例中，将被路由到第一节点（也就是源节点）访问待迁移对象shard1的事务称为第一节点事务，将被路由到第二节点（也就是目的节点）访问目标对象（由待迁移对象迁移得到的）shard2的事务称为第二节点事务。需要说明的是，这里所说的第一节点事务可以理解为在源节点执行的源事务集合，这里所说的第二节点事务可以理解为在目的节点执行的目的事务集合，并不局限于一个事务。

需要说明的是，双运行工作模式可以理解为第一节点与第二节点同时执行对待迁移对象的访问事务的工作模式。不需要中断访问源节点中待迁移对象的第一节点事务的执行过程，对于需要访问待迁移对象的新的第二节点事务可以路由到第二节点并继续执行事务。从而能够实现无事务中断地将待迁移对象由第一节点转移到第二节点。

这里所说的数据信息包括：快照和数据项版本（tuple版本）。具体来说，如图3为本申请实施例提供的数据信息生成方法的流程示意图。从图3中可以看到数据信息的生成方式包括如下步骤：301：生成所述待迁移对象在所述第一时刻时的快照。302：获取所述待迁移对象中存储的在所述第一时刻之前提交的至少一个数据项版本。303：将所述快照及所述至少一个数据项版本作为所述待迁移对象在所述第一时刻时的数据信息。

例如，在第一时刻生成待迁移对象shard1的快照，该第一时刻对应的时间戳为snap_ts。基于该时间戳snap_ts读取在第一时刻之前已经提交的每个数据项版本，也就是要读取对snap_ts可见的各个数据项版本。这里所说的数据项版本为tuple版本，在待迁移对象shard1中存储有多个版本的tuple，每一个tuple版本表示一次对待迁移对象执行事务访问的操作，此外还可以为每个tuple分配一个主键值。

在本申请一个或者多个实施例中，将所述数据信息传输至第二节点，包括：向所述第二节点发送携带有所述数据信息的存储请求，以便所述第二节点基于所述存储请求执行相应的存储事务，以将所述数据信息存储在已创建的目标对象中。接收到所述第二节点反馈完成执行的响应后，向所述第二节点发送针对所述存储事务的提交通知，以便所述第二节点提交所述存储事务，并使得所述快照以一个最小的时间戳进行提交。

在生成数据信息之后，第一节点可以向第二节点发送存储请求，在该存储请求中携带有数据信息（包括快照和数据项版本等）。在进行存储之前，需要在第二节点中创建一个空的目标对象shard2。第二节点接收到存储请求之后，将数据信息存储到目标对象shard2当中。第一节点（源节点）中的待迁移对象shard1则继续执行当前正在进行中的第一节点事务直至结束。需要说明的是，此时第二节点的目标对象中存储的数据信息与待迁移对象中第一时刻以前的数据信息是完全相同的。同时在对数据信息的复制传输的过程中，第一节点中待迁移对象因为执行至少一个第一节点事务导致不断产生新的增量数据。由于在对数据信息进行复制的时候采用异步模式，也就是将快照以及数据项版本复制到目标对象直接进行存储，不需要等待对快照中的预设日志的回放，因此，常规情况下复制数据信息的速度明显快于产生修改信息的速度，采用异步模式不会对第一节点中正常事务执行造成性能影响。即便待迁移对象中存储的数据信息较多或者新生成的修改信息速度较快的情况下，在对待迁移对象中的数据信息进行多轮复制后可以使得待迁移对象中存在数量有限的待复制的数据信息和/或修改信息，比如经过多轮迭代复制后未执行重做日志的数量有限。

在第二节点执行完对当前数据信息的存储工作之后，第二节点向第一节点反馈已经执行完成存储事务。进而第二节点可以进行存储事务的提交。需要说明的是，该存储事务所要存储的数据信息都是在第一时刻（时间戳为snap_ts）前第一节点中执行至少一个第一节点事务所生成的，为了使得第二节点中目标对象参与后续第二节点事务访问请求的时候，能够有权限看到这些数据信息，需要在进行存储时提交的时候，为这些快照标记为最小的提交时间戳。这里所说的最小的时间戳可以是预先设定的小于第二节点中任何事务的开始时间。

在实际应用中，对于第一时刻之前的数据信息采用异步模式复制传输方式。具体来说，在进行存储之前，需要在第二节点中创建一个空的目标对象shard2，该目标对象shard2是只读状态。要查询这个快照shard，就是查源节点中待迁移对象shard1在某一时刻时的数据状态。而shard快照是空文件，也就是里面没有数据。如果要查询快照中的某一tuple版本，就会被重定向到源节点的shard，所以返回的数据（即tuple）就是源节点shard中的数据。

如前文所述可知，在对待迁移对象进行迁移处理过程中，由于第一节点继续执行第一节点事务或者接收新的事务访问，会持续不断的出现产生的新的修改信息，这部分与待迁移对象相关的修改信息也需要传输到第二节点中。如图4为本申请实施例提供的修改信息传输方法的流程示意图。具体来说，将所述第一时刻后针对所述待迁移对象的修改信息传输至所述第二节点，包括如下步骤：

401：获取所述待迁移对象的日志文件中时间戳晚于所述第一时刻的日志。

402：将获取到的、属于同一事务的多个日志存储在一个缓存队列中。

403：在所述缓存队列中存在反映事务提交的日志，且该反映事务提交的日志的提交时间戳晚于所述第一时间时，将所述缓存队列中的多个日志传输至所述第二节点；其中，所述修改信息即所述缓存队列中的多个日志。

需要说明的是，这里所说的修改信息中包含有多个日志（比如，预设日志WAL日志），可以利用预设日志（Write-ahead Logging，WAL）来跟踪并记录在待迁移对象生成快照、复制快照以及完成复制过程中的新的修改相关信息，以便将修改信息同步到第二节点中的目标对象中。例如，在分布式数据库系统中，每个数据库节点用一个事务状态日志CLOG来记录事务状态（比如，运行、准备（prepared）、提交、中止（Abort）等）以及提交时间戳。并且数据库在先写入提交记录到预写日志中，再修改CLOG的事务状态（CLOG状态在数据库故障后可以通过WAL恢复）。

在实际应用中，第一节点中存储的日志比较繁杂，不仅包含有第一节点中待迁移对象历史相关日志（也就是第一时刻之前的日志），还包含有新产生的日志（也就是第一时刻及其之后的日志）。容易理解的是，在第一时刻之前的日志可以跟随数据信息传输到第二节点当中。对于第一时刻之后的日志，则需要进行区分传输。具体来说，第一节点启动传输进程不断读取解析WAL日志，可以根据日志文件关联的时间戳进行判断，若待迁移对象的日志文件的关联的时间戳者晚于第一时刻，则确定该日志文件为第一节点新产生的日志。这里所说的新产生的日志是修改过程中所产生的WAL日志。进而，将获取到的属于同一个第一节点事务的多个日志存储到内存中的一个缓存队列当中。若在缓存队列中存在用于反映事务提交的日志，则获取该日志对应的提交时间戳，并判断该提交时间戳与第一时间的大小关系。若提交时间戳不早于第一时间对应的时间戳snap_ts，则将缓存队列中的新的日志发送给第二节点。

将携带有新的WAL日志的修改信息发送给第二节点之后，第二节点会启动重做进程对新的日志进行回放。这里需要说明的是，回放过程中，第二节点启动影子事务（shadow）重新执行与第一节点相同的修改，在执行过程中，要确保影子事务采用与第一节点执行事务时相同的开始时间戳进行快照读，以及相同的提交时间戳进行事务提交。

为了便于理解，下面具体举例说明。如图5为本申请实施例提供的修改数据传输的框架示意图。从图5中可以看到，第一节点将WAL日志中在第一时刻snap_ts之后提交第一节点事务对应的修改信息异步传播到第二节点。在第一节点会启动一个sender进程（传输进程），不断读取解析WAL日志，在解析后若发现日志中存在与第一节点事务的第一个修改相关的日志时，会在内存中为第一节点事务构建一个内存缓存队列，用来缓存第一节点事务的修改信息。当解析到第一节点事务的提交(commit)日志记录时，判断该提交日志记录对应的提交时间戳是否晚于第一时刻snap_ts，如果是，则将第一节点事务缓存在内存中缓存队列的修改信息发送到第二节点。

在第二节点接收到修改信息之后，第二节点会启动一个重做（apply）进程，该进程则回放sender进程发过来的修改信息。具体的，第二节点中为每个同步过来的事务在本地启动一个影子（shadow）事务来重新执行第一节点上第一节点事务修改操作的修改信息。在shadow事务执行过程中，采用第一节点执行第一节点事务一样的开始时间戳进行快照读，并采用和第一节点执行第一节点事务一样的提交时间戳进行提交。

在实际应用中，重做（apply）进程回放修改信息的时候，需要基于tuple主键值进行回放。具体来说，每个shard分区表均有一个tuple主键值（Primary Key）。第一节点利用Sender进程解析过程中，当将WAL日志中与待迁移对象shard1相关的操作（比如，update、delete、insert、lock rows等）日志记录解析出来时，同时会记录该操作修改的tuple主键值，以及对tuple的更新内容。从而，对于每个修改记录，apply进程首先根据tuple主键值在第二节点找到该tuple版本链（即主键索引扫描），然后再找到可见的更新的版本。对于插入记录，则检查数据库约束条件（比如主键不能重复）后，如果满足条件后，则直接执行插入。

在本申请一个或多个实施例中，获取反映所述待迁移对象迁移进度的参数，包括：获取所述第二节点反馈的未执行重做（apply）的日志数量；或者，获取向所述第二节点传输数据的迭代次数。

如前文所述可知，在对数据信息的复制传输的过程中，第一节点中待迁移对象因为执行至少一个第一节点事务导致不断产生新的增量数据以及对应的修改信息。即便待迁移对象中存储的数据信息较少或者新生成的修改信息速度比第二节点回放速度慢的情况下，在对待迁移对象中的数据信息进行多轮复制后可以使得待迁移对象中存在数量有限的待复制的数据信息和/或修改信息。此时，可以对第一节点与第二节点之间的待迁移对象shard1传播模式进行切换。本申请方案中，异步模式能够实现快速复制，换言之能够实现快速将第一节点中的数据信息、修改信息复制到第二节点当中，而不需要等待第二节点的回放进度，适用于大量数据信息或修改信息同步操作，但是无法确保多个第二节点的回放进度一致。同步模式能够保证多个第二节点中的日志回放一致性效果，但是由于需要第二节点事务完成回放、提交之后，才算执行完毕，若直接采用同步模式会对第一节点负载性能产生不利影响，增加第一节点处理事务所需等待时间。因此，本申请方案是分阶段采用不同的复制方式，当需要同步的数据比较多的时候，采用异步复制的方式，当需要同步数据比较少的时候，采用同步复制的方式。同步多少的判断过程，可以是由协调节点对源节点中最新日志序号（Log Sequence Number，LSN）和目的节点中已回放日志序号LSN进行比较之后确定的，两个LSN之间的差值越大，表示未回放的数量较多，反之表示未回放数量较少。

传播模式切换后，分布式数据库系统则调整为双运行模式。具体如下：

在进行异步模式中，第二节点接收到数据信息、修改信息之后，根据其中的WAL日志进行重做（apply）并回放。在第二节点不断进行日志重做并回放的同时，第二节点还不断接收新的修改信息等待回放。若在第二节点中没有执行重做的日志数量小于第一阈值的时候，则可以将第一节点向第二节点进行迁移的传播模式切换为同步模式。第一节点基于MOCC（Multi-version OptimisticConcurrency Control）协议进行提交，即等待修改在第二节点进行了写写冲突检测、约束条件检测，并回放完成。如果没有写写冲突，则第一节点事务在它的修改回放完成后可以进行提交。否则第一节点事务将被回滚。

若已经执行的由第一节点向第二节点传输数据信息和/或修改信息的迭代次数大于第二阈值的时候，则可以将第一节点向第二节点进行迁移的工作模式切换为同步模式。第一节点基于MOCC（Multi-version OptimisticConcurrency Control）协议进行提交，即等待修改在第二节点进行了写写冲突检测，并回放完成。如果没有写写冲突，则第一节点事务在它的修改回放完成后可以进行提交。否则第一节点事务将被回滚。基于MOCC协议进行提交的过程将在下述实施例中进行解释说明。

为了便于理解对待迁移对象shard1迁移工作中传播模式切换过程，下面通过具体实施例进行举例说明。

当第二节点上未回放的修改信息数量低于第一阈值时，或者，经过预定第二阈值数目的迭代后，对待迁移对象的迁移工作将进入双运行工作（DUAL）执行模式，完成迁移路由切换。需要说明的是，将每个被路由到第一节点访问待迁移对象的事务称为第一节点事务，将被路由到第二节点访问待迁移对象的事务称为第二节点事务。这里所说的DUAL执行模式为单向Dual Execution模型，在切换路由路径后，新到来的访问待迁移对象的第二节点事务被路由到第二节点执行，同时允许在第一节点的已执行第一节点事务继续运行到结束，从而避免服务中断。

这里需要说明的是，在前文表述中，进行迁移路由切换的条件有两个。第一种是当第二节点上未回放的修改信息（WAL日志）数量小于第一阈值的时候，则表示在常规情况下回放速度比较快，当剩余未回放数量较少的时候，可以进行路由切换。当然也可能出现特殊情况，就是经过多轮次迭代之后，第二节点中剩余的未回放的修改信息数量仍然很多，则此时可以将迭代次数作为限定条件，换言之，当迭代次数达到第二阈值后，虽然未回放修改信息数量仍然大于第一阈值，此时仍然可以进行路由切换。

为了支持DUAL模式执行，需要将异步模式切换成同步模式，换言之，访问第一节点中待迁移对象的第一节点事务需要等待它的修改信息在第二节点被回放完成才能进行事务提交并结束。传播模式的切换可以通过在第一节点中设置一个sync的标记。具体的，在第一节点共享内存区域设置一个sync变量。当执行传播模式切换时，将第一节点的sync变量设置为true。第一节点事务在提交时，检查sync变量，来判断是否需要进行同步等待。如果sync变量被设置为true，则第一节点事务采用后面提到的MOCC协议进行提交，换言之，需要等待第一节点事务的修改信息在第二节点被回放完成；否则，第一节点事务直接写完提交日志到WAL并持久化，在完成对WAL的修改后即可结束。在实际应用中，协调节点对第一节点（也就是源节点）中和待迁移对象修改相关的最新日志序号LSN和目的节点中已回放日志序号LSN进行比较之后，发现差距不是很大时，可以触发将sync设置为true。

在设置完sync变量后，传播模式切换阶段还需要等待所有已有的正在运行的第一节点事务结束，以及它们的修改信息在第二节点全部回放完成。需要说明的是，在设置sync的时候，有些第一节点事务已经进入提交阶段，没有看到sync被设置。因此传播模式切换需要等待这些事务全部结束，以及它们的修改在第二节点被回放完成。具体的，可以在它们结束的时候，获取当前WAL中迁移对象对应最新的写入刷新位置，然后等待第二节点回放达到或超过这个位置。当传播模式切换完成后，才可以执行DUAL执行模式。如图5所示，在同步模式下，采用的是和异步模式一样的复制方法。

在DUAL执行模式中，可以将第二节点事务路由到第二节点访问待迁移对象。为了改变第二节点事务对待迁移对象的访问路径，需要对待迁移对象对应的对象与节点关系进行修改。这里所说的对象与节点的对应关系也可称为路由关系，对应的，用于存储的对象与节点的对应关系的表称为分区路由表（shard map table）。

在实际应用中，每个数据库节点都维护一个自己的分区路由表。将第一节点中的分区路由表称为第一分区路由表，将第二节点中维护的分区路由表称为第二分区路由表。

在DUAL执行模式中进行路由修改的具体过程如下：

发起因所述待迁移对象迁移引起对象与节点关系变化的修改事务，以便节点集群中的参与节点按照所述修改事务的指示修改本地存储的对象与节点的对应关系。

在实际应用中，每个数据库节点都维护一个对象（待迁移对象或者目标对象以及其他对象）与节点（第一节点或第二节点以及其他节点）的对应关系，也就是分区路由表，换言之，进行目的节点访问的时候，可以通过分区路由表找到对应的目的节点进而实现访问。

在分布式数据库当中有很多数据库节点参与到事务执行当中，因此，在进行分区路由表的修改的时候，需要节点集群中多个参与节点共同执行修改事务完成对分区路由表的修改。如图6为本申请实施例提供的修改事务执行方法的流程示意图。从图6中可以看到，包括如下步骤：

601：向所述节点集群中的参与节点发送有关所述修改事务的询问请求。

602：接收节点集群中参与节点返回的执行所述修改事务后的响应信息。

603：在接收到所述参与节点反馈的所述响应信息，并基于所述响应信息确定所述参与节点完成所述修改事务的执行时，向所述参与节点发送提交通知。

604：接收所述参与节点反馈的针对所述修改事务的提交响应。

当有对分区路由表的修改需求的时候，由协调节点向当前节点集群中每个参与节点发送修改事务的询问请求，询问是否可以执行提交操作，并开始等待各参与者节点的响应。在参与节点接到Prepare请求之前，每一个参与者节点会各自执行与修改事务有关的数据更新。如果参与节点执行成功，暂时不提交事务，而是向修改事务的协调节点返回完成（Done）消息。当事务协调节点接到了所有参与者的返回完成消息，整个分布式事务将会进入提交阶段。需要说明的是，采用分布式事务来修改分区路由表（shard map table），采用二阶段提交的同时，需要对提交时间戳进行分配，从而使得修改事务执行后依然能够保证所有分布式事务的原子性、一致性、隔离性和持久性。具体实现步骤将在下述实施例中进行举例说明，这里就不再重复赘述。

若分区路由表（shard map table）通常处于被频繁访问的状态，为了缓解访问压力，以及加速分区路由表的访问效果，可以由各个进程建立一个私有的对象与节点关系的缓存，为了确保各个进程私有的对象与节点关系的缓存正常使用，会将修改事务的修改结果及时同步到各个私有的对象与节点关系的缓存。在实际应用中，为了能够确保及时同步效果，执行修改事务所产生的修改都会被同步到该对象与节点关系的缓存当中。在本实施例中，会将所有待迁移对象的可见分区路由表tuple都刷新到缓存中。

若分区路由表没有建立私有缓存（比如对某个分区路由表的访问不频繁），每个进程在进行事务路由的时候，根据路由事务的开始时间戳读对其可见的分区路由表（shardmap table）tuple，进而基于该可见的分区路由表进行事务路由。

需要说明的是，这里所说的在进程中建立私有的缓存可以作为一种可选方案，在实际应用中用户可以根据实际需求进行选择（比如，如果不存在分区路由表的访问压力，可以不建立私有缓存），上述实施例并不构成对本申请技术方案的限制。

所述接收所述参与节点反馈的针对所述修改事务的提交响应，包括：向所述节点集群中的参与节点发送有关所述修改事务的询问请求，以便所述参与节点设定为准备刷新修改后对象与节点关系的准备状态，在所述节点集群的共享内存中刷新标识符的情况下所述参与节点刷新所述修改后对象与节点关系。

如图7为本申请实施例提供的分区路由表修改的示意图。从图7中可以看到，shardmap1中有shardid1和shardid2，其中，shardid1对应的节点nodeid为1，shardid2对应的节点nodeid为10。在通过修改事务进行修改的时候，修改为shardid1对应的节点nodeid为2，shardid2对应的节点nodeid未修改，仍然为10。需要说明的是，分区路由表shard maptable被存储在各个节点当中，可以采用分布式事务实现对待迁移对象的shardmap1进行修改，在修改完成后进行提交。

为了便于理解DUAL执行模式，下面具体举例说明。

在每个节点维护有一个自己的分区路由表shard map table。当需要对分区路由表shard map table进行修改的时候，可以采用一个分布式事务（也就是修改事务Tm）来修改所有参与节点的shard map table，从而使得新到来的第二节点事务被路由到第二节点访问待迁移对象。具体的，shard map table在每个节点用一个数据库表来存储，从而支持事务访问修改，并保证MVCC（多版本并发控制）下的快照隔离。每个进程进行事务路由时，通过快照读取对该事务开始时间戳可见的shard map table路由表中可见的tuple版本。

通过采用分布式事务来修改shard map table，保证第一节点事务的开始时间戳均早于第二节点事务的开始时间戳，自然也小于第二节点事务的提交时间戳。从而使得第二节点事务的修改对第一节点事务不可见。这样，在 DUAL执行模式下Remus只需要将第一节点的修改同步到第二节点，换言之实现单向的DUAL执行模型。

这是因为，对于任意第一节点事务Ts的开始时间戳必定早于或等于修改事务Tm的提交时间戳（因为第一节点事务被路由到了第一节点，看到的是路由路径切换之前的shardmap table版本）。对于任意第二节点事务Td的开始时间戳必定晚于修改事务Tm的提交时间戳。因此，第一节点事务Ts的开始时间戳必定早于第二节点事务Td的开始时间戳，以及提交时间戳。

由于分布式数据库每个节点都有分区路由表shard map table可以实现路由事务，分布式数据库的基于一致性快照隔离机制来保证在所有节点路由的第一节点事务Ts和第二节点事务Td都满足这个特性。每个进程频繁的访问shard map table表进行事务路由，会造成比较大的开销。

在实际应用中，每个进程可以建立一个私有的分区路由表缓存shard maptablecache，这是因为每个进程频繁访问分区路由表shard map table造成比较大的开销，采用建立私有的对象与节点关系的缓存shard map table cache能够有效降低开销。为了保证修改事务Tm执行的修改及时同步到对象与节点关系的缓存（shard map table cache）中，在执行修改事务Tm之前，会通知所有参与节点进入准备状态（shard map table sync）。每次对事务进行路由前，数据库进程都会根据事务的开始时间戳快照，去读取分区路由表shard map table来刷新缓存。在修改事务Tm执行结束后，通知所有节点退出shard maptable sync状态。当shard map table sync状态结束，如果某个进程的cache还没有刷新到最新版本，则该进程在修改事务Tm结束后以及当前正在路由执行的事务结束后，主动刷新缓存到最新版本。这样是安全的，因为该进程后面路由的事务的开始时间戳肯定都大于Tm的提交时间戳。进一步地，为了减少shard map table刷新的开销，可以在每个节点的共享内存区域记录需要刷新的shard map table的迁移shard ids，以及第二节点node id。同时共享内存可以维护一个shard map table的版本号，当一个进程的缓存刷新到最新修改事务Tm产生的版本号之后，就不用再去读取shard map table，从而避免不必要的刷新。

本申请实施例提供的技术方案中，提出一种双运行工作模式。该双运行工作模式需在反映对象迁移进展程度的参数满足预置条件时才能启动。在双运行工作模式下，第一节点可继续执行未提交的针对所述待迁移对象的第一节点事务，且将执行中产生的增量数据传输至所述第二节点，这样第二节点可继续基于接收到的增量数据进行回放操作得到与待迁移对象同步的目标对象；与此同时第二节点可以接收到被路由到该节点的新的第二节点事务。从而实现对待迁移对象的在线无中断迁移。

基于相同的思路，本申请实施例还提供另一种数据迁移方法。如图8为本身实施例提供的另一种数据迁移方法的流程示意图。从图8中可以看到具体包括如下步骤：

801：存储第一节点传输的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据。

802：基于所述数据信息及所述增量数据，执行迁入操作，以生成与所述待迁移对象数据同步的迁入对象。

803：接收到针对所述迁入对象的第二节点事务时，启动冲突检测。

804：在通过所述冲突检测后，执行所述第二节点事务。

对第一节点中待迁移对象采用在线迁移方式。将待迁移对象迁移到第二节点，并存储到第二节点中预先建立的迁入对象中。具体来说，在第一节点中存储有待迁移对象shard1的历史数据信息，响应于对待迁移对象的迁入操作，第二节点接收并存储包含有待迁移对象shard1快照的数据信息。假设，待迁移对象的快照是在第一时刻生成的，而此时第一节点中还有正在执行中的事务，并随之不断产生新的增量数据。进一步地，将增量数据以及快照都存储到迁入对象中。

在实际应用中，第二节点采用异步模式接收到数据信息之后，会对数据信息进行回放。在回放过程中第二节点接收到被路由过来的对迁入对象进行访问的第二节点事务。在此之前，需要利用修改事务对对象与节点关系进行修改，以及在此过程中第一节点所产生的增量数据的传输模型由异步模式切换为同步模式，具体可参考图1至图7对应各实施例，这里就不再重复赘述。在第二节点执行影子事务过程中，需要基于MOCC协议进行写写冲突验证。影子事务采用和它的第一节点事务一样的开始时间戳和提交时间戳，像普通事务一样执行，即进行快照读，约束条件检查，写写冲突检测。具体来说，通过同步模式将第一节点中针对待迁移对象执行第一节点事务修改的修改信息，同步到第二节点的迁入对象中。接下来，第二节点启动与第一节点上执行的第一节点事务对应的影子事务，该影子事务的开始时间及提交时间需与第一节点上执行的对应的所述第一节点事务相同。在第一节点进行第一节点事务提交前，启动写写冲突检测，具体包括：若所述第一节点提交所述第一节点事务前，查找到所述影子事务执行的第一节点事务的可见版本对应的更新版本，则回滚所述影子事务以及第一节点事务。若所述第一节点提交所述第一节点事务前，未查找到所述影子事务执行的第一节点事务的可见版本对应的更新的版本，则通过所述冲突检测。

MVCC并发控制协议则包含准备阶段和提交阶段，MOCC并发控制协议包含验证阶段和提交阶段，因此可见MOCC协议比现有MVCC协议多了验证工作。为了便于理解，下面对基于MOCC协议进行写写冲突检查进行举例说明。这里所说的验证工作，是指需要进行写写冲突验证。具体来说，第二节点对接收到的修改信息进行回放之时，根据待回放事务的开始时间进行快照读，如果该可见版本在版本链中存在更新的版本，比如，存在被第二节点的事务更新，或者被标记为删除（dead），或者存在第一节点和第二节点同时针对同一个tuple版本的两个修改操作，则说明存在写写冲突，需要中止并回滚影子事务以及对应的第一节点中执行的第一节点事务。

如果检查后发现没有写写冲突、没有违反约束条件并被回放成功，则检查通过。当所有修改都通过写写冲突检测，并被回放完成后，第二节点的重做apply进程将该影子事务（shadow）执行二阶段提交（Two-Phase Commit，2PC）的prepare操作，然后回复一个validation-ok的消息给第一节点。否则，apply进程中止并回滚影子事务，并回复validation-failure给第一节点。

在验证通过之后，第一节点可以进行第一节点事务（源事务）的提交。若第一节点事务是单节点（非分布式事务）事务，将提交日志记录到WAL日志中。该提交日志记录会被sender进程传播到第二节点。第二节点的apply进程会将相应prepared的shadow事务用相同的提交时间戳进行提交。此外，为了提高回放效率，也可以启动单独的进程来接收第一节点的提交记录（commit）或回滚记录，提交prepared的shadow事务。这样也可以避免一个未提交的shadow事务阻塞后面的shadow事务的检查与提交。若第一事务是一个分布式事务，则该第一节点事务的准备阶段在第一节点上通过。如果该第一节点事务在其它所有参与节点上都准备（prepare）成功，则它最终会被协调节点分布式提交；同样它在第一节点会写入提交日志记录到WAL中，被sender进程异步传播到第二节点，提交第二节点上的影子（shadow）事务。如果最终第一节点事务因为在其它参与节点没有prepare成功而被协调节点回滚，则它会写入回滚日志记录到WAL中，最终第二节点的影子事务也会被回滚。

当影子事务执行的过程中和第二节点事务出现死锁，则数据库死锁检测器在发现这种情况下，选择杀掉造成死锁的第二节点事务，以避免对apply进程的回放造成中断。

在迁移过程中，可能会出现第一节点故障或者第二节点故障的问题，下面对故障恢复方案进行举例说明。具体的，如果故障发生在分区路由表切换前，即分布式修改事务Tm执行成功前，则第一节点上拥有完整的最新的数据。可以采取终止整个迁移工作，并将第二节点上的部分迁移的数据清理，进而在后面继续重试迁移计划。

如果故障发生在分区路由表切换后，则这个时候可能进入DUAL执行模式，第二节点上拥有完整的最新的数据。由于在DUAL执行过程中，采用2PC的方法来提交影子事务以及采用两阶段验证提交第一节点事务，需要采用传统分布式数据库中的2PC清理机制来恢复第二节点上的影子事务状态。例如在故障恢复时，如果发现第一节点事务提交了，但是它对应的影子事务仍然处于准备（prepared）状态，则需要用第一节点事务的提交时间戳将对应的影子事务提交。在这里不列举所有的情况，简单来说出现故障时，需要检查所有prepared的影子事务对应的第一节点事务的状态，来决定是提交还是回滚该影子事务，从而保证一致性的状态。

需要说明的是，在进行多个待迁移对象迁移的时候，所采用的Remus也可以支持多个待迁移对象一起迁移，其迁移过程与单个待迁移对象的迁移过程相同，具体可参考上述实施例，这里就不再重复赘述。

基于同样的思路，本申请实施例还提供一种数据迁移装置。如图9为本申请实施例提供的一种数据迁移装置的结构示意图。该数据迁移装置包括：

传输模块91，用于将第一节点上的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至第二节点，以便所述第二节点迁入所述待迁移对象。

获取模块92，用于获取反映所述待迁移对象迁移进度的参数。

启动模块93，用于在所述参数满足预置条件时，启动双运行工作模式。

执行模块94，用于在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述第二节点。

路由模块95，用于在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述第二节点，以由所述第二节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务。

可选地，还包括生成模块96，用于生成所述待迁移对象在所述第一时刻时的快照；获取所述待迁移对象中存储的在所述第一时刻之前提交的至少一个数据项版本；将所述快照及所述至少一个数据项版本作为所述待迁移对象在所述第一时刻时的数据信息。

可选地，传输模块91，用于向所述第二节点发送携带有所述数据信息的存储请求，以便所述第二节点基于所述存储请求执行相应的存储事务，以将所述数据信息存储在已创建的目标对象中；接收到所述第二节点反馈完成执行的响应后，向所述第二节点发送针对所述存储事务的提交通知，以便所述第二节点提交所述存储事务，并使得所述快照以一个最小的时间戳进行提交。

可选地，传输模块91，还用于获取所述待迁移对象的日志文件中时间戳晚于所述第一时刻的日志。将获取到的、属于同一事务的多个日志存储在一个缓存队列中。在所述缓存队列中存在反映事务提交的日志，且该反映事务提交的日志的提交时间戳晚于所述第一时间时，将所述缓存队列中的多个日志传输至所述第二节点。其中，所述修改信息即所述缓存队列中的多个日志。

可选地，获取模块92，用于获取所述第二节点反馈的未执行重做（apply）的日志数量；或者获取向所述第二节点传输数据的迭代次数。

可选地，还包括发起模块97，用于发起因所述待迁移对象迁移引起对象与节点关系变化的修改事务，以便节点集群中的参与节点按照所述修改事务的指示修改本地存储的对象与节点的对应关系。

可选地，发起模块97还用于向所述节点集群中的参与节点发送有关所述修改事务的询问请求；

接收节点集群中参与节点返回的执行所述修改事务后的响应信息；

在接收到所述参与节点反馈的所述响应信息，并基于所述响应信息确定所述参与节点完成所述修改事务的执行时，向所述参与节点发送提交通知；

接收所述参与节点反馈的针对所述修改事务的提交响应。

可选地，发起模块97还用于向所述节点集群中的参与节点发送有关所述修改事务的询问请求，以便所述参与节点设定为准备所述对象与节点准备状态；其中，所述同步状态是在所述节点集群的共享内存中记录有刷新标识符确定是否需要同步所述对象与节点关系。

本申请一个实施例还提供一种电子设备。如图10为本申请实施例提供的一种电子设备的结构示意图。该电子设备包括存储器1001、处理器1002及通信组件1003；其中，

所述存储器1001，用于存储程序；

所述处理器1002，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于：

将第一节点上的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至第二节点，以便所述第二节点迁入所述待迁移对象；

获取反映所述待迁移对象迁移进度的参数；

在所述参数满足预置条件时，启动双运行工作模式；

在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述第二节点；

在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述第二节点，以由所述第二节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务。

上述存储器1001可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

进一步地，本实施例中的所述处理器1002可以具体是：可编程交换处理芯片，该可编程交换处理芯片中配置有数据复制引擎，能对接收到的数据进行复制。

上述处理器1002在执行存储器中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。进一步，如图10所示，电子设备还包括：电源组件1004等其它组件。

基于同样的思路，本申请实施例还提供另一种数据迁移装置。如图11为本申请实施例提供的另一种数据迁移装置的结构示意图。该数据迁移装置包括：

存储模块1101，用于存储第一节点传输的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据。

执行模块1102用于基于所述数据信息及所述增量数据，执行迁入操作，以生成与所述待迁移对象数据同步的迁入对象。

接收模块 1103，用于接收到针对所述迁入对象的第二节点事务时，启动冲突检测。

执行模块1102还用于在通过所述冲突检测后，执行所述第二节点事务。

执行模块1102还用于第二节点需启动与第一节点上执行的第一节点事务对应的影子事务，该影子事务的开始时间及提交时间需与第一节点上执行的对应的所述第一节点事务相同。

执行模块1102还用于若所述第一节点提交所述第一节点事务前，查找到所述影子事务执行的第一节点事务的可见版本对应的更新版本，则回滚所述影子事务以及第一节点事务；

若所述第一节点提交所述第一节点事务前，未查找到所述影子事务执行的第一节点事务的可见版本对应的更新版本，则通过所述冲突检测。

本申请一个实施例还提供另一种电子设备。如图12为本申请实施例提供的另一种电子设备的结构示意图。该电子设备包括存储器1201、处理器1202及通信组件1203；其中，

所述存储器1201，用于存储程序；

所述处理器1202，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于：

存储第一节点传输的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据；

基于所述数据信息及所述增量数据，执行迁入操作，以生成与所述待迁移对象数据同步的迁入对象；

接收到针对所述迁入对象的第二节点事务时，启动冲突检测；

在通过所述冲突检测后，执行所述第二节点事务。

上述存储器1201可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

进一步地，本实施例中的所述处理器1202可以具体是：可编程交换处理芯片，该可编程交换处理芯片中配置有数据复制引擎，能对接收到的数据进行复制。

上述处理器1202在执行存储器中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。进一步，如图12所示，电子设备还包括：电源组件1204等其它组件。

基于上述实施例，将第一节点上的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至第二节点，以便所述第二节点迁入所述待迁移对象；获取反映所述待迁移对象迁移进度的参数；在所述参数满足预置条件时，启动双运行工作模式；在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述第二节点；在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述第二节点，以由所述第二节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务。采用上述技术方案，在参数满足预置条件的时候，启动双运行工作模式，也就是第一节点可以继续执行未提交的针对待迁移对象的第一节点事务，而且将执行中产生的增量数据传输到第二节点。同时，对路由关系进行修改，以便将针对待迁移对象进行访问的第二节点事务路由到第二节点中对应的目标对象执行，从而实现对待迁移对象的在线无中断迁移。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (12)

1.一种数据迁移方法，包括：

将第一节点上的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至第二节点，以便所述第二节点迁入所述待迁移对象，并且所述第二节点需启动与第一节点上执行的第一节点事务对应的影子事务，所述影子事务的开始时间及提交时间需与所述第一节点事务相同；

获取反映所述待迁移对象迁移进度的参数；

在所述参数满足预置条件时，启动双运行工作模式；

在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述第二节点；

在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述第二节点，以由所述第二节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务。

2.根据权利要求1所述的方法，所述数据信息的生成方式包括：

生成所述待迁移对象在所述第一时刻时的快照；

获取所述待迁移对象中存储的在所述第一时刻之前提交的至少一个数据项版本；

将所述快照及所述至少一个数据项版本作为所述待迁移对象在所述第一时刻时的数据信息。

3.根据权利要求2所述的方法，将所述数据信息传输至第二节点，包括：

向所述第二节点发送携带有所述数据信息的存储请求，以便所述第二节点基于所述存储请求执行相应的存储事务，以将所述数据信息存储在已创建的目标对象中；

接收到所述第二节点反馈完成执行的响应后，向所述第二节点发送针对所述存储事务的提交通知，以便所述第二节点提交所述存储事务，并使得所述快照以一个最小的时间戳进行提交。

4.根据权利要求1至3中任一项所述的方法，将所述第一时刻后针对所述待迁移对象的修改信息传输至所述第二节点，包括：

获取所述待迁移对象的日志文件中时间戳晚于所述第一时刻的日志；

将获取到的、属于同一事务的多个日志存储在一个缓存队列中；

在所述缓存队列中存在反映事务提交的日志，且该反映事务提交的日志的提交时间戳晚于所述第一时刻时，将所述缓存队列中的多个日志传输至所述第二节点；

其中，所述修改信息即所述缓存队列中的多个日志。

5.根据权利要求1所述的方法，所述获取反映所述待迁移对象迁移进度的参数，包括：

获取所述第二节点反馈的未执行重做的日志数量；或者，

获取向所述第二节点传输数据的迭代次数。

6.根据权利要求1所述的方法，还包括：

发起因所述待迁移对象迁移引起对象与节点关系变化的修改事务，以便节点集群中的参与节点按照所述修改事务的指示修改本地存储的对象与节点的对应关系。

7.根据权利要求6所述的方法，所述发起因所述待迁移对象迁移引起对象与节点关系变化的修改事务，包括：

向所述节点集群中的参与节点发送有关所述修改事务的询问请求；

接收节点集群中参与节点返回的执行所述修改事务后的响应信息；

在接收到所述参与节点反馈的所述响应信息，并基于所述响应信息确定所述参与节点完成所述修改事务的执行时，向所述参与节点发送提交通知；

接收所述参与节点反馈的针对所述修改事务的提交响应。

8.根据权利要求7所述的方法，所述向所述节点集群中的参与节点发送有关所述修改事务的询问请求，包括：

向所述节点集群中的参与节点发送有关所述修改事务的询问请求，以便所述参与节点设定为准备刷新修改后对象与节点关系的准备状态，在所述节点集群的共享内存中刷新标识符的情况下所述参与节点刷新所述修改后对象与节点关系。

9.一种数据迁移方法，所述方法包括：

存储第一节点传输的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据；

基于所述数据信息及所述增量数据，执行迁入操作，以生成与所述待迁移对象数据同步的迁入对象；

第二节点需启动与第一节点上执行的第一节点事务对应的影子事务，该影子事务的开始时间及提交时间需与第一节点上执行的对应的所述第一节点事务相同；

接收到针对所述迁入对象的第二节点事务时，启动冲突检测；

在通过所述冲突检测后，执行所述第二节点事务。

10.根据权利要求9所述的方法，还包括：

若所述第一节点提交所述第一节点事务前，查找到所述影子事务执行的第一节点事务的可见版本对应的更新版本，则回滚所述影子事务以及第一节点事务；

若所述第一节点提交所述第一节点事务前，未查找到所述影子事务执行的第一节点事务的可见版本对应的更新版本，则通过所述冲突检测。

11.一种数据迁移系统，包括：源节点和至少一个目的节点；

所述源节点，用于将待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据，传输至所述目的节点，以便所述目的节点迁入所述待迁移对象，并且第二节点需启动与第一节点上执行的第一节点事务对应的影子事务，所述影子事务的开始时间及提交时间需与所述第一节点事务相同；获取反映所述待迁移对象迁移进度的参数；在所述参数满足预置条件时，启动双运行工作模式；在所述双运行工作模式下存在未提交的针对所述待迁移对象的第一节点事务时，将执行中产生的增量数据传输至所述目的节点；在所述双运行工作模式下存在针对所述待迁移对象的第二节点事务时，将所述第二节点事务路由至所述目的节点，以由所述目的节点在完成所述待迁移对象的迁入并通过冲突检测后再执行所述第二节点事务；

所述目的节点，用于存储源节点传输的待迁移对象在第一时刻时的数据信息及所述第一时刻之后产生的与所述待迁移对象有关的增量数据；基于所述数据信息及所述增量数据，执行迁入操作，以生成与所述待迁移对象数据同步的迁入对象；接收到针对所述迁入对象的第二节点事务时，启动冲突检测；在通过所述冲突检测后，执行所述第二节点事务。

12.一种电子设备，包括存储器及处理器；其中，

所述存储器，用于存储程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以用于实现上述权利要求1至8中任一项所述的方法；或上述权利要求9至10中任一项所述的方法。

Images