CN115617571A - 一种数据备份方法、装置、系统、设备及存储介质 - Google Patents

Abstract

本说明书实施例公开了一种数据备份方法、装置、系统、设备及存储介质。所述方法包括：针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；构建可提交事务集合，并确定存储节点的裁剪位点；其中，所述可提交事务集合包括：在所述第一位点到所述裁剪位点之间，存在提交事件的两阶段提交事务；所述存储节点的裁剪位点为，所述可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；备份所述可提交事务集合，以及存储节点中所述第一位点到所述裁剪位点之间的操作日志。

Description

一种数据备份方法、装置、系统、设备及存储介质

技术领域

本说明书实施例涉及数据库技术领域，尤其涉及一种数据备份方法、装置、系统、设备及存储介质。

背景技术

针对数据分散存储到至少两个存储节点的数据库，具体进行备份时，需要针对多个存储节点进行备份。

相关技术中，可以针对数据库进行逻辑备份。逻辑备份具体可以是通过select*查询获取数据库中所有表的数据进行备份。但是逻辑备份需要占用较多的数据库资源，影响数据库本身业务的执行。

发明内容

为了解决上述问题，本说明书实施例提供了一种数据备份方法、装置、系统、设备及存储介质。技术方案如下所示。

一种数据备份方法，应用于数据库，所述数据库中包括至少两个存储节点；所述方法包括：

针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

构建可提交事务集合，并确定存储节点的裁剪位点；

其中，所述可提交事务集合包括：在所述第一位点到所述裁剪位点之间，存在提交事件的两阶段提交事务；

所述存储节点的裁剪位点包括，所述可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

备份所述可提交事务集合，以及存储节点中所述第一位点到所述裁剪位点之间的操作日志。

一种数据备份装置，应用于数据库，所述数据库中包括至少两个存储节点；所述装置包括：

物理备份单元，用于针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

构建单元，用于构建可提交事务集合，并确定存储节点的裁剪位点；

其中，所述可提交事务集合包括：在所述第一位点到所述裁剪位点之间，存在提交事件的两阶段提交事务；

所述存储节点的裁剪位点包括，所述可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

备份单元，用于备份所述可提交事务集合，以及存储节点中所述第一位点到所述裁剪位点之间的操作日志。

上述技术方案通过物理备份和备份操作日志，可以实现数据库中存储数据的备份，无需逻辑备份，可以减少数据库数据备份对数据库本身业务执行的影响。

附图说明

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

图1是本说明书实施例提供的一种数据备份方法的流程示意图；

图2是本说明书实施例提供的一种数据库的结构示意图；

图3是本说明书实施例提供的一种操作日志备份的原理示意图；

图4是本说明书实施例提供的另一种操作日志备份的原理示意图；

图5是本说明书实施例提供的另一种操作日志备份的原理示意图；

图6是本说明书实施例提供的另一种操作日志备份的原理示意图；

图7是本说明书实施例提供的另一种操作日志备份的原理示意图；

图8是本说明书实施例提供的另一种操作日志备份的原理示意图；

图9是本说明书实施例提供的另一种操作日志备份的原理示意图；

图10是本说明书实施例提供的另一种操作日志备份的原理示意图；

图11是本说明书实施例提供的另一种数据备份方法的流程示意图；

图12是本说明书实施例提供的一种数据恢复方法的流程示意图；

图13是本说明书实施例提供的另一种数据备份方法的流程示意图；

图14是本说明书实施例提供的一种数据备份装置的结构示意图；

图15是本说明书实施例提供的另一种数据备份装置的结构示意图；

图16是本说明书实施例提供的一种数据备份系统的架构示意图；

图17是用于配置本说明书实施例方法的一种设备的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于公开的范围。

针对数据分散存储到至少两个存储节点的数据库，具体进行备份时，需要针对多个存储节点进行备份。

相关技术中，可以针对数据库进行逻辑备份。逻辑备份具体可以是通过select*查询获取数据库中所有表的数据进行备份。但是逻辑备份需要占用较多的数据库资源，影响数据库本身业务的执行。

例如，由于逻辑备份需要扫描大量数据，会对数据库的性能造成一定的影响，通常需要放在业务低峰期执行。另外由于是逻辑备份且只能进行表级并行，对于数据库这种超大数据集的场景，整体吞吐能力较低，时间较长，备份效率较低。

为了解决上述问题，本说明书实施例提供了一种数据备份方法。该方法可以用于针对数据库中的存储数据进行备份。

在该方法中，可以针对数据库中的每个存储节点中全量存储数据进行物理备份。物理备份的具体解释可以参见相关技术。该数据库具体可以是分布式数据库，分布式数据库中的存储数据可以分散存储在至少两个存储节点中。

相比于逻辑备份，物理备份的备份效率较高，备份速度快，并且对数据库本身业务执行的影响较小。

针对数据库，数据分散存储在不同存储节点上，并且不同存储节点上的数据之间可以存在关联性。

例如，两个存储节点上可以针对同一笔交易分别存储有相应的记录，这两个记录之间存在关联。如果需要修改该笔交易的记录，就需要针对这两个存储节点修改相应的记录。

具体地，两个存储节点中的其中一个节点可以用于存储买方数据，另一个节点可以用于存储卖方数据。针对同一笔交易，需要分别在这两个存储节点存储卖方角度的记录和买方角度的记录。而这两个记录就具有关联性。

后续需要查询该笔交易的信息时，可以综合这两个记录进行查询，确保交易数据的完整性。

基于数据库中的数据关联性，需要数据库保持事务一致性，也就是事务对数据完整性约束的遵循。

例如，当一个事务需要修改两个存储节点上的关联记录，这两个存储节点上该事务的执行结果应当保持一致，都回滚成功，或者都提交成功。

具体地，针对卖方存储节点和买方存储节点，如果针对同一笔交易，买方存储节点成功提交，存储该笔交易的买方角度信息；而卖方数据成功回滚，不存在该笔交易的卖方角度信息。从而会导致该笔交易数据不完整。

为了便于数据库中的存储数据在根据备份恢复后，也能够保持事务一致性，在该方法中，具体备份时，可以进一步备份各个存储节点中所需要的操作日志，以便于在恢复数据库中的存储数据时，可以基于备份的操作日志保持事务一致性。

具体的解释可以参见后文解释。

由于本说明书实施例提供的该方法中，可以通过物理备份和备份操作日志，实现数据库中存储数据的备份，无需逻辑备份，可以减少数据库备份对数据库本身业务执行的影响。

并且，该方法备份的效率相比逻辑备份较高；针对操作日志的备份，也不会影响数据库的业务执行，进一步减少了数据库备份对数据库业务执行的影响。

如图1所示，为本说明书实施例提供的一种数据备份方法的流程示意图。

本方法流程并不限定执行主体，具体可以应用于数据库，用于针对数据库中的存储数据进行备份。

数据库中可以包括至少两个存储节点；数据库中的存储数据可以分散存储在至少两个存储节点中。

可选地，数据库中还可以包括计算节点。计算节点可以用于负责数据分布式路由、计算及动态调度，负责分布式事务2PC协调、全局二级索引维护等。具体可以用于针对存储节点发起事务，例如，两阶段提交事务。

为了便于理解，如图2所示，为本说明书实施例提供的一种数据库的结构示意图。图2中的数据库可以包括2个计算节点和3个存储节点。

当然，本说明书并不限定数据库中计算节点和存储节点的具体数量，图2仅仅用于示例性说明。

可选地，数据库具体可以是分布式数据库，例如，PolarDB-X数据库。

可选地，本方法流程可以由数据库中的计算节点执行。执行本方法流程的计算节点可以称为管控节点。

可选地，数据库中可以新增一个节点，执行本方法流程。数据库中的该新增节点可以具有数据库中存储节点的控制权限。

可选地，本方法流程也可以由数据库以外的设备执行，该设备可以用于针对数据库中的存储数据进行备份。其中，该设备具体可以是管理设备，管理设备可以具有数据库的控制权限。具体可以是具有数据库中存储节点的控制权限，以及数据库中计算节点的控制权限。

可选地，由于每个存储节点可以存储数据库中的部分存储数据，因此，不同存储节点可以具有不同的操作日志，操作日志具体可以包括数据更新日志，用于记录存储节点所存储的数据库数据更新情况。

当然，操作日志具体也可以包括数据库日志，例如，数据库逻辑日志或者数据库事务日志，用于记录存储节点所存储的数据库数据更新情况。

本方法流程可以包括以下步骤。

S101：针对每个存储节点中全量存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点。

S102：在确定未完成事务集合中的全部两阶段提交事务完成的情况下，发起针对全部存储节点的心跳事务。

可选地，未完成事务集合可以包括，在物理备份之后的第一时刻，数据库中未完成的全部两阶段提交事务。

S103：在全部存储节点提交心跳事务成功的情况下，针对每个存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；将心跳事务添加到当前可提交事务集合中。

S104：循环更新当前可提交事务集合和每个存储节点的当前裁剪位点，直到针对每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中。

其中，每个存储节点的当前裁剪位点为，当前可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点。

S105：循环结束后，备份当前可提交事务集合，以及每个存储节点中第一位点到当前裁剪位点之间的操作日志。

上述方法流程可以通过物理备份和备份操作日志，实现数据库中存储数据的备份，无需逻辑备份，可以减少数据库备份对数据库本身业务执行的影响。

并且，该方法备份的效率相比逻辑备份较高；针对操作日志的备份，也不会影响数据库的业务执行，进一步减少了数据库备份对数据库业务执行的影响。

此外，基于上述方法流程所备份的存储节点中全量存储数据、操作日志以及当前可提交事务集合，能够在后续恢复数据库中存储数据时，确保事务一致性。

下面针对本方法流程中备份的数据，如何在恢复后维持事务一致性的原因进行解释。

在一种可选的实施例中，针对数据库中所需执行的事务，通常可以划分为针对单个存储节点的事务，和针对至少两个存储节点的事务。

其中，针对单个存储节点的事务，通常是针对单个存储节点中的数据库进行更新的事务。

针对至少两个存储节点的事务，通常是针对至少两个存储节点之间存在关联的数据进行更新的事务。

因此，在考虑数据库中的事务一致性时，通常不考虑只针对单个存储节点的事务，无论该类事务是否执行成功，只更新单个存储节点中的数据，不影响其他存储节点，也就不影响事务一致性。例如，针对单个存储节点中的数据进行修改的事务。

而对于针对至少两个存储节点的事务，就需要确保所针对的全部存储节点，该事务的执行结果保持一致。要么都回滚，要么都提交。

在一种可选的实施例中，在数据库中，针对至少两个存储节点的事务，可以通过两阶段提交事务执行。

可选地，两阶段提交事务具体可以是遵循两阶段提交协议的分布式事务。两阶段提交事务具体可以包括：XA事务。

MySQL中实现了开放的X/Open CAE规范，XA事务具体可以是一种基于MySQL提供的XA接口的分布式事务执行方式。

例如，针对两个存储节点中的关联数据进行修改的事务，具体可以是遵循两阶段提交协议执行。

由于两阶段提交事务涉及至少两个存储节点，因此，本方法流程中重点针对两阶段提交事务执行相关步骤，以确保存储节点之间的事务一致性。

一、下面针对两阶段提交事务进行具体解释。

针对两阶段提交事务，存在准备提交阶段和提交阶段，也就是prepare阶段和commit阶段。

1)在prepare阶段中，数据库中的计算节点，可以向两阶段提交事务所针对的所有存储节点发送该事务的准备提交消息，也就是prepare消息。

存储节点在接收到该事务的准备提交消息后，可以在本地处理该事务，并将处理结果写入日志中。

例如，两阶段提交事务具体是修改两个存储节点中的一组关联数据。两个存储节点接收到该事务后，可以从存储数据中取出该关联数据，并根据该事务进行修改，将修改结果写入日志中。具体可以是redo日志。

此时两阶段提交事务处于准备提交状态，也就是prepare状态。存储节点可以相应地，将该事务的准备事件写入操作日志中，也就是prepare事件。具体可以是写入数据库逻辑日志中。

存储节点可以将prepare成功的消息返回到计算节点。

在prepare阶段，存储节点可以连续执行以下操作：在接收到该事务的准备提交消息后，可以在本地处理该事务，并将处理结果写入日志中；将该事务的准备事件写入操作日志中；将prepare成功的消息返回到计算节点。

因此，存储节点的操作日志中的事务准备事件，可以表征该事务处于准备提交状态，并且处理结果已经写入日志中，方便后续根据提交信息直接写入存储节点所存储的数据库数据中。

换言之，事务“准备提交(prepare)”成功，可以表征该事务准备事件已经写入操作日志中。

2)在commit阶段，计算节点在确定两阶段提交事务所针对的全部存储节点都prepare成功的情况下，也就是两阶段提交事务所针对的全部存储节点都处于prepare状态，可以向该事务所针对的全部存储节点，发起该事务的提交消息，也就是commit消息。

两阶段提交事务所针对的全部存储节点在接收到该事务的提交消息后，可以执行提交操作，将日志中事务的处理结果写入存储节点所存储的数据库数据中，完成提交。从数据库整体角度出发，也可以说明事务处理结果写入数据库中。

此时两阶段提交事务处于提交状态，也就是commit状态。存储节点可以相应地，在写入存储节点所存储的数据库数据成功的情况下，将该事务的提交事件写入操作日志中，也就是commit事件。具体可以是写入数据库逻辑日志中。

存储节点可以将commit成功的消息返回到计算节点。

在commit阶段，存储节点可以连续执行以下操作：在接收到该事务的提交消息后，可以执行提交操作，将日志中事务的处理结果写入存储节点所存储的数据库数据中；在写入成功的情况下，将该事务的提交事件写入操作日志中，将commit成功的消息返回到计算节点。

因此，存储节点的操作日志中的事务提交事件，可以表征该事务处于提交状态，并且处理结果已经写入存储节点所存储的数据库数据成功，也就是成功写入数据库。

换言之，事务“提交(commit)”成功，可以表征该事务的提交事件已经写入操作日志中。

3)此外，计算节点在确定两阶段提交事务所针对的任一存储节点prepare失败或者响应超时的情况下，可以发起该事务的回滚消息，也就是rollback消息。

两阶段提交事务所针对的全部存储节点在接收到该事务的回滚消息后，可以执行回滚操作，完成回滚。

此时两阶段提交事务处于回滚状态，也就是rollback状态。存储节点可以将该事务的回滚事件写入操作日志中，也就是rollback事件，标识该事务被回滚。具体可以是写入数据库逻辑日志中。

存储节点可以将回滚成功的消息返回到计算节点。

存储节点可以连续执行以下操作：在接收到该事务的回滚消息后，可以执行回滚操作，删除日志中事务的处理结果；在删除成功的情况下，将该事务的回滚事件写入操作日志中，将回滚成功的消息返回到计算节点。

因此，存储节点的操作日志中的事务回滚事件，可以表征该事务处于回滚状态，并且处理结果已经删除。

换言之，事务回滚成功，可以表征该事务回滚事件已经写入操作日志中。

需要说明的是，两阶段提交事务，在所针对的全部存储节点都提交成功，或者都回滚成功的情况下，可以看作执行完成。

如果两阶段提交事务所针对的任一存储节点没有提交成功或者回滚成功，则该事务还在执行过程中，处于未完成的状态。

针对两阶段提交事务，在操作日志中，可以对应于准备事件、提交事件和回滚事件。

在解释两阶段提交事务之后，进一步解释上述方法流程中的未完成事务集合和心跳事务。

二、未完成事务集合。

需要说明的是，在针对每个存储节点中全量存储数据进行物理备份后，所备份的数据库数据可能不一致。

例如，一个存储节点中已经提交事务，而另一个存储节点中还未提交该事务。一个存储节点中已经回滚事务，而另一个存储节点中该事务还未回滚。

如果在后续备份日志时，备份的日志中不包括事务的提交事件或者回滚事件，也就无法确定出该事务的处理结果。也就会出现不同节点的全量备份和备份日志里，存在割裂的已提交事务的情况。

例如，一个存储节点中在物理备份之前已经成功提交事务，该存储节点后续备份的第一位点之后的操作日志中并不会包含该事务的提交事件。

另一个存储节点中还未提交该事务，但是后续备份的第一位点之后的操作日志中可能也不包含该事务的提交事件。

在后续恢复时，根据备份的第一位点之后的操作日志，也就无法确定该事务是否能够提交。

因此，可以先针对某一时刻数据库中未完成的两阶段提交事务，等待这些事务全部完成。

具体可以确定未完成事务集合，其中包括在物理备份之后的第一时刻，数据库中未完成的全部两阶段提交事务。

具体地，数据库中未完成的全部两阶段提交事务，可以包括：数据库中已经发起但未完成的全部两阶段提交事务。

在物理备份之后，可以确定出未完成事务集合，并等待未完成事务集合中的全部两阶段提交事务完成。

基于上述分析，两阶段提交事务完成，可以包括：两阶段提交事务所针对的每个存储节点，成功回滚该两阶段提交事务；或者两阶段提交事务所针对的每个存储节点，成功提交该两阶段提交事务。

需要说明的是，由于已经确定未完成事务集合中的每个两阶段提交事务完成，因此，可以确定对于未完成事务集合中的每个两阶段提交事务，所针对的全部存储节点都成功回滚或者成功提交。

而基于上述两阶段提交事务的解释，事务成功回滚，可以说明该事务在存储节点的操作日志中已经记录了相应的回滚事件。事务成功提交，可以说明该事务在存储节点的操作日志中已经记录了相应的提交事件。

因此，在确定未完成事务集合中的每个两阶段提交事务完成的情况下，此时该事务针对的每个存储节点的操作日志中，已经记录了该事务完成的处理结果。具体可以是回滚事件或者提交事件。

通过物理备份存储节点中的全量存储数据，以及备份包含第一位点到未完成事务集合中每个两阶段提交事务完成的操作日志内容，从而可以基于物理备份的存储节点全量存储数据，在后续的恢复过程中，确保未完成事务集合中的每个两阶段提交事务，所针对的每个存储节点都能够根据所备份的操作日志内容，完成一致的处理结果，保证了未完成事务集合中每个两阶段提交事务的一致性。

在本方法流程中，后续备份操作日志时，可以备份每个存储节点中第一位点(物理备份开始时刻)到当前裁剪位点之间的操作日志。

而当前裁剪位点在每个存储节点中，都可以在心跳事务准备事件或者之后。具体解释可以参见后文。

并且，由于心跳事务是在确定未完成事务集合中的每个两阶段提交事务完成的情况下发起的，因此，每个存储节点中，心跳事务的准备事件都在未完成事务集合中的每个两阶段提交事务完成之后。

换言之，所备份的每个存储节点操作日志中，可以包含第一位点到未完成事务集合中每个两阶段提交事务完成的操作日志内容。

因此，针对未完成事务集合中的全部两阶段提交事务，可以通过备份的操作日志，确定所针对的每个存储节点中的处理结果是回滚或提交，从而确保在后续利用备份的操作日志恢复时，可以保证这些事务在不同存储节点之间的一致性。

因此，可以针对第一时刻，数据库中未完成的全部两阶段提交事务，能够确保后续恢复时的事务一致性。

需要说明的是，由于直接针对每个存储节点中全量存储数据进行物理备份，没有确保不同存储节点之间的事务一致性，后续备份日志时，也是从第一位点(物理备份开始时刻)开始的，因此，针对物理备份之前发起的事务，后续备份的日志可能会缺少这些事务的相关事件。

例如，备份的日志可能缺少物理备份之前发起的事务准备事件，也可能缺少物理备份之前发起的事务提交事件。

通过设置第一时刻的未完成事务集合，并且通过等待未完成事务集合中的全部两阶段提交事务完成，以及备份相应的日志，确保这些事务的一致性，从而可以避免备份日志缺少事务的相关事件而影响到事务一致性。

此外，由于未完成事务集合中包括第一时刻数据库中未完成的全部两阶段提交事务，因此，对于第一时刻以及之前数据库中已经完成的全部两阶段提交事务，基于备份的连续日志，同理，都可以确保处理结果的一致性，也就可以确保事务一致性。

之后，可以针对第一时刻之后发起的事务，确保事务一致性。

由于第一时刻之后发起的事务，相关的事件(例如，准备事件、提交事件或回滚事件)都会记录在操作日志中第一时刻对应位点之后，因此，可以通过备份的日志查找事务的相关事件，用于确保事务的一致性。具体可以参见后文解释。

为了便于理解，如图3所示，为本说明书实施例提供的一种操作日志备份的原理示意图。

其中展示了存储节点1-3的操作日志，还展示了物理备份对应的第一位点、第一时刻对应的位点和发起心跳事务对应的位点。并且展示了事务1-3的准备事件和提交事件在操作日志中的位置。

为了便于描述，将事务1的准备事件描述为P1，将事务1的提交事件描述为C1；将事务2的准备事件描述为P2，将事务2的提交事件描述为C2；将事务3的准备事件描述为P3，将事务3的提交事件描述为C3。

其中，事务1是针对存储节点1和存储节点2的事务；事务2是针对存储节点1和存储节点2的事务；事务3是针对存储节点2和存储节点3的事务。

在第一位点针对存储节点1-3的全量存储数据进行物理备份时，可以看到事务1在所针对的存储节点1中还处于准备提交状态，而在所针对的存储节点2中处于提交状态。此时存储节点1和存储节点2之间，事务1所更新的数据不一致。

并且，此时事务2在所针对的存储节点1中处于准备提交状态，而在所针对的存储节点2中还未准备成功。此时存储节点1和存储节点2之间，事务2所更新的数据不一致。

在物理备份之后的第一时刻，此时事务1已经完成，所针对的存储节点1和存储节点2的操作日志中，都已经记录提交事件，处于提交成功的状态。

后续利用备份日志进行恢复时，基于物理备份的存储节点全量存储数据，存储节点1备份的全量存储数据可以根据C1事件，将事务1成功提交，从而与存储节点2备份的全量存储数据中的事务1保持一致，实现事务1的一致性。

换言之，针对第一时刻之前完成的两阶段提交事务，可以基于备份的日志确保不同存储节点之间的事务一致性。

第一时刻下，数据库中未完成的两阶段提交事务包括，事务2和事务3。其中，事务2所针对的存储节点2完成提交，但是事务2所针对的存储节点1还未完成提交。因此，事务2还未完成。

同理，事务3所针对的存储节点2还未完成准备提交，并且事务3所针对的存储节点3还未完成提交，因此，事务3还未完成。

之后可以等待事务2和事务3完成，再针对存储节点1-3发起心跳事务。

也就是在事务2所针对的存储节点1和存储节点2都完成提交，并且事务3所针对的存储节点2和存储节点3都完成提交，进而可以开始针对存储节点1-3发起心跳事务。

后续备份日志时，备份的日志可以包括存储节点1-3中第一位点到发起心跳事务之间的日志。

后续利用备份日志进行恢复时，基于物理备份的存储节点全量存储数据，存储节点1备份的全量存储数据可以根据C2事件，将事务2成功提交；存储节点2备份的全量存储数据可以根据P2事件和C2事件，将事务2成功提交，从而使得存储节点1和存储节点2之间的事务2保持一致，实现事务2的一致性。

同理，事务3也可以保持一致性。

换言之，针对第一时刻未完成的两阶段提交事务，可以基于备份的日志确保不同存储节点之间的事务一致性。

三、心跳事务。

针对第一时刻之后发起的两阶段提交事务，可以通过心跳事务对全部存储节点进行标注，进而确保事务一致性。

首先，根据上述两阶段提交事务的解释，结合图示解释两阶段提交事务的相关事件之间的关系推论。

1)推论一：针对每个两阶段提交事务，在该事务所针对的每个存储节点中，该事务准备事件都记录在计算节点下发该事务提交信息的时刻之前，该事务提交事件都记录在计算节点下发该事务提交信息的时刻之后。

基于上述两阶段提交事务的解释，计算节点在确定两阶段提交事务所针对的全部存储节点都prepare成功的情况下，才会下发该事务的提交消息。

由于所针对的全部存储节点prepare成功的操作中，可以包括所针对的全部存储节点在操作日志中记录该事务准备事件。

因此，可以将计算节点下发提交信息的时刻看作是分界线，在该事务所针对的每个存储节点中，该事务准备事件都记录在计算节点下发该事务提交信息的时刻之前。

基于上述两阶段提交事务的解释，两阶段提交事务所针对的全部存储节点在接收到该事务的提交消息后，可以执行提交操作，将日志中事务的处理结果写入存储节点所存储的数据库数据中，完成提交。

完成提交的操作中，可以包括：接收到计算节点下发的提交信息，进行后续的提交，在写入存储节点所存储的数据库数据成功的情况下，在操作日志中记录该事务提交事件。

因此，可以将计算节点下发提交信息的时刻看作是分界线，在该事务所针对的每个存储节点操作日志中，该事务提交事件都记录在计算节点下发该事务提交信息的时刻之后。

为了便于理解，如图4所示，为本说明书实施例提供的另一种操作日志备份的原理示意图。

其中展示了存储节点1-3的操作日志，并且展示了事务1的准备事件和提交事件在操作日志中的位置。

为了便于描述，将事务1的准备事件描述为P1，将事务1的提交事件描述为C1。其中，事务1是针对存储节点1-3的事务。

可见，存储节点1-3分别在事务1准备提交成功后，在日志中记录准备事件，并将准备提交成功的消息发送到计算节点。

计算节点在确定存储节点1-3中的事务1都prepare成功的情况下，可以下发事务1的提交消息。

由于消息发送的时延，可能存在提交消息在不同时刻到达各个存储节点，之后存储节点1-3完成提交，在日志中记录事务1的提交事件C1。

因此，以计算节点下发事务1的提交消息的时刻为分界线，可以确定在事务1所针对的每个存储节点操作日志中，P1都在分界线之前，C1都在分界线之后。

基于推论一，可以确定针对同一两阶段提交事务，在该事务所针对的每个存储节点中，准备事件都位于提交事件之前。

以图3为例，存储节点1-3中，P1都在分界线之前，也就都在C1之前。

基于推论一，也可以确定针对每个两阶段提交事务，在该事务所针对的每个存储节点中，计算节点下发该事务提交信息的时刻都在该事务准备事件与该事务提交事件之间。

以图3为例，存储节点1-3中，下发事务1的提交消息的时刻都在P1和C1之间。

2)推论二：如果在一个存储节点的操作日志中，两阶段提交事务1的提交事件之后，存在两阶段提交事务2的准备事件，则可以确定事务1的提交消息下发时刻，早于事务2的提交消息下发时刻。

基于推论一，如果在一个存储节点的操作日志中，存在两阶段提交事务1的提交事件，则可以确定事务1的提交消息下发时刻，在该事务1提交事件对应时刻之前。

基于推论一，如果在一个存储节点的操作日志中，存在两阶段提交事务2的准备事件，则可以确定事务2的提交消息下发时刻，在该事务2准备事件之后。

进一步地，如果在一个存储节点的操作日志中，两阶段提交事务1的提交事件之后，存在两阶段提交事务2的准备事件，则可以按照从前到后的时序顺序排序，得到：事务1的提交消息下发时刻、该事务1提交事件、该事务2准备事件、事务2的消息下发时刻。

也就可以确定事务1的提交消息下发时刻，早于事务2的提交消息下发时刻。

为了便于理解，如图5所示，为本说明书实施例提供的另一种操作日志备份的原理示意图。

其中展示了存储节点的操作日志，并且展示了事务1-2的准备事件和提交事件在操作日志中的位置。

为了便于描述，将事务1的准备事件描述为P1，将事务1的提交事件描述为C1。将事务2的准备事件描述为P2，将事务2的提交事件描述为C2。

在该操作日志中，C1可以在P2之前。并且，P1一定在C1之前，C2一定在P2之后。

因此，下发事务1的提交消息的时刻，一定在P1和C1之间，也就是在C1之前。

而下发事务2的提交消息的时刻，一定在P2和C2之间，也就是在P2之后。

又因为C1在P2之前，因此，从前到后的时序顺序一定是P1、下发事务1的提交消息、C1、P2、下发事务2的提交消息、C2。

因此，事务1的提交消息下发时刻，早于事务2的消息下发时刻。

3)推论三：如果在一个存储节点的操作日志中，两阶段提交事务1的提交事件之后，存在两阶段提交事务2的准备事件，则可以确定在每个存储节点的操作日志中，事务2的提交事件之后，不存在事务1的准备事件。

基于推论二，可以确定，如果在一个存储节点的操作日志中，两阶段提交事务1的提交事件之后，存在两阶段提交事务2的准备事件，则可以确定事务1的提交消息下发时刻，早于事务2的消息下发时刻。

基于推论二，也可以确定，如果在一个存储节点的操作日志中，事务2的提交事件之后，存在事务1的准备事件，则可以确定事务2的提交消息下发时刻，早于事务1的消息下发时刻。

需要说明的是，在数据库中，可以存在多个计算节点，计算节点通常针对单个事务，可以下发一次该事务的提交消息。

因此，对于不同的事务，事务提交消息的下发先后时序是固定的，事务1的提交消息下发时刻早于事务2的消息下发时刻的情况，以及事务2的提交消息下发时刻早于事务1的消息下发时刻的情况，并不会同时存在。

换言之，在一个存储节点的操作日志中，事务1的提交事件之后存在事务2的准备事件的情况，与事务2的提交事件之后存在事务1的准备事件，并不会同时存在。

因此，如果在一个存储节点的操作日志中，两阶段提交事务1的提交事件之后，存在两阶段提交事务2的准备事件，则可以确定在每个存储节点的操作日志中，事务2的提交事件之后，不存在事务1的准备事件。

为了便于理解，下面以P1表示事务1的准备事件，以C1表示事务1的提交事件。以P2表示事务2的准备事件，以C2表示事务2的提交事件。

如果在任一存储节点的操作日志中，存在P1-C1-P2-C2的先后时序顺序，那么，可以表明事务1提交消息在事务2提交消息之前下发。

在其他存储节点的操作日志中，也就不存在P2-C2-P1-C1的先后时序顺序。

此外，尽管下发提交消息的事务先后顺序是固定的，但是各个存储节点完成事务提交的先后顺序无法控制。

例如，计算节点针对事务1和事务2先后下发提交消息，但是事务1需要提交的数据量较大，事务2需要提交的数据量较小，则可能出现事务2提交完成的时刻，早于事务1提交完成的时刻。

在操作日志中也就会出现事务2的提交事件在事务1的提交事件之前的情况。

因此，如果在任一存储节点的操作日志中，存在P1-C1-P2-C2的先后时序顺序，那么，其他存储节点的操作日志中可能存在以下几种情况：P1-P2-C1-C2、P1-P2-C2-C1、P2-P1-C1-C2、P2-P1-C2-C1。

为了便于理解，如图6所示，为本说明书实施例提供的另一种操作日志备份的原理示意图。

其中展示了存储节点1-5的操作日志，并且展示了事务1-2的准备事件和提交事件在操作日志中的位置。

为了便于描述，将事务1的准备事件描述为P1，将事务1的提交事件描述为C1。将事务2的准备事件描述为P2，将事务2的提交事件描述为C2。

4)推论四：如果在一个存储节点的操作日志中，两阶段提交事务1的提交事件之后，存在两阶段提交事务2的准备事件，则可以确定在事务1和事务2共同针对的每个存储节点操作日志中，事务1的准备事件都在事务2的提交事件之前。

基于推论二，如果在一个存储节点的操作日志中，两阶段提交事务1的提交事件之后，存在两阶段提交事务2的准备事件，则可以确定事务1的提交消息下发时刻，早于事务2的提交消息下发时刻。

由于在事务1所针对的每个存储节点操作日志中，事务1的准备事件都在事务1的提交消息下发时刻之前，并且事务1的提交消息下发时刻，早于事务2的提交消息下发时刻。

因此，可以得到事务1所针对的每个存储节点操作日志中的先后时序顺序为：事务1准备事件、事务1的提交消息下发时刻、事务2的提交消息下发时刻。

进一步地，基于推论一，可以确定在事务2所针对的每个存储节点操作日志中，事务2的提交事件都在事务2的提交消息下发时刻之后。

因此，上述先后时序顺序可以更新为：事务1准备事件、事务1的提交消息下发时刻、事务2的提交消息下发时刻、事务2的提交事件。

从而可以确定，在事务1和事务2所共同针对的每个存储节点操作日志中，事务1的准备事件，都在事务2的提交事件之前。

以图6为例，在事务1所针对的所有节点1-5中，P1都在下发事务1的提交消息时刻之前，也就都在下发事务2的提交消息时刻之前，也就都在C2之前。

5)基于上述推理得到的四个推论，可以进一步解释利用心跳事务确保事务一致性的原理。

可选地，心跳事务是针对全部存储节点发起的，因此，心跳事务也属于两阶段提交事务。

由于心跳事务也是两阶段提交事务，存在准备事件和提交事件，因此，针对在任一存储节点的操作日志中，在心跳事务准备事件之前存在提交事件的事务，可以利用上述推论四，确定在该事务所针对的全部存储节点操作日志中，该事务的准备事件都在心跳事务提交事件之前。

可选地，如果一个事务在任一存储节点的操作日志中，在心跳事务准备事件之前存在提交事件，也就可以确定，计算节点已经下发该事务的提交消息，进行后续的提交操作。

因此，该事务的处理结果可以确定是“提交”而不是“回滚”。

为了便于描述，将该事务，也就是在任一存储节点的操作日志中，在心跳事务准备事件之前存在提交事件的两阶段提交事务，称为特定事务。

利用上述推论四，可以确定在特定事务所针对的全部存储节点操作日志中，特定事务的准备事件都在心跳事务提交事件之前。

针对特定事务，为了确保特定事务的一致性，可选地，可以限定在特定事务所针对的每个存储节点备份的操作日志中至少包括特定事务的准备事件。

基于上述针对两阶段提交事务的解释，操作日志中的事务准备事件，可以表明事务已经处于准备提交的状态，相关的处理结果已经写入日志中，只需要接收到提交消息就能够写入数据库中，完成提交。

并且，针对特定事务，都已经确定处理结果是“提交”。

在特定事务所针对的每个存储节点备份的操作日志中，由于都包含特定事务的准备事件，无论是否包括特定事务的提交事件，在后续恢复数据库存储数据时，针对特定事务可以确定处理结果是“提交”，从而可以在备份的操作日志中不包括特定事务提交事件的情况下，基于特定事务的“准备事件”恢复特定事务的“准备提交状态”，进而可以由计算节点下发特定事务的提交消息，完成后续的提交步骤，确保不同存储节点之间特定事务的处理结果都是“提交成功”，确保事务的一致性。

如果在备份的操作日志中包括特定事务提交事件的情况下，特定事务可以根据操作日志进行恢复，也可以执行提交步骤，得到“提交成功”的处理结果。

基于上述解释，可以利用心跳事务的准备事件，收集特定事务到一个事务集合中，进行后续的操作。

可选地，可以将每个存储节点的操作日志中，在心跳事务准备事件之前存在提交事件的全部两阶段提交事务，添加到一个事务集合中。

其中，事务集合中的每个事务的准备事件，在该事务所针对的每个存储节点操作日志中，都在心跳事务提交事件之前。

可选地，由于第一时刻未完成的事务可以确保一致性，后续需要针对第一时刻之后发起的两阶段提交事务确保一致性，而第一时刻之后发起的事务的提交事件难以确定范围，因此，可以限定是在第一时刻之后。

可选地，可以将每个存储节点的操作日志中，在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到一个事务集合中。

具体可以是将每个存储节点的操作日志中，在第一时刻对应位点与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到一个事务集合中。

因此，事务集合中的每个事务，在至少一个存储节点的操作日志中，存在提交事件位于第一时刻与心跳事务准备事件之间。

由于事务集合中的每个事务，在至少一个存储节点的操作日志中，已经在心跳事务准备事件之前记录下了提交事件，因此，该事务的处理结果可以确定为“提交”。

为了便于描述，将上述事务集合称为可提交事务集合。

可选地，由于需要心跳事务的提交事件确定事务准备事件的范围，因此，需要确保每个存储节点的心跳事务都提交成功，也就可以确定心跳事务的处理结果为“提交”，从而可以将心跳事务也添加到可提交事务集合中。

在确定可提交事务集合之后，可以针对每个存储节点，确定所需要备份的操作日志。

具体可以是确定每个存储节点的日志裁剪位点，以便于后续将第一位点(物理备份开始时刻)到裁剪位点之间的操作日志进行备份。

为了确保可提交事务集合中的每个两阶段提交事务，在所针对的每个存储节点备份的操作日志中至少包括该事务的准备事件，可选地，可以针对每个存储节点，将可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点，确定为裁剪位点。

具体地，最晚记录的准备事件的结束位点，可以是该准备事件结束的位点，也就是该准备事件在操作日志中对应段落结束的位点。

从而可以在后续备份裁剪位点之前的操作日志时，将该准备事件也包含在备份的操作日志中。

可选地，由于可提交事务集合中每个特定事务准备事件都在心跳事务提交事件之前，因此，每个存储节点的裁剪位点不会在心跳事务提交事件之后，也就可以方便确定裁剪位点。

进一步地，需要在全部存储节点提交心跳事务成功的情况下，确保全部存储节点的操作日志中都已经记录心跳事务提交事件，从而可以方便确定出在心跳事务提交事件之前的裁剪位点。

在确定每个存储节点的裁剪位点的情况下，所备份的第一位点(物理备份开始时刻)到裁剪位点之间的操作日志，可以包括可提交事务集合中针对该节点的全部两阶段提交事务的准备事件。

相对应地，后续针对每个存储节点，利用备份的操作日志进行恢复时，针对处于准备提交状态的事务，如果该事务属于可提交事务集合，则可以由计算节点下发提交消息完成提交，从而确保可提交事务集合中事务的一致性。

因此，通过上述解释，可以利用可提交事务集合、裁剪位点和备份的操作日志，能够确保可提交事务集合中每个事务的一致性。

为了便于理解，如图7所示，为本说明书实施例提供的另一种操作日志备份的原理示意图。

其中展示了存储节点1-4的操作日志，并且展示了事务1-2的准备事件和提交事件，以及心跳事务的准备事件和提交事件在操作日志中的位置。

为了便于描述，将事务1的准备事件描述为P1，将事务1的提交事件描述为C1。将事务2的准备事件描述为P2，将事务2的提交事件描述为C2。将心跳事务的准备事件描述为PH，将心跳事务的提交事件描述为CH。

其中，事务1是针对存储节点1-2的事务。事务2是针对存储节点3-4的事务。心跳事务是针对存储节点1-4的事务。

在图7中，由于存储节点1中，C1在PH之前，所以可提交事务集合包括事务1。由于存储节点3中，C2在PH之前，所以可提交事务集合包括事务2。

可提交事务集合也包括心跳事务。

基于可提交事务集合，可以确定存储节点1-4的裁剪位点。

存储节点1-2中，在可提交事务集合(包括事务1-2和心跳事务)中针对存储节点1-2的事务(事务1和心跳事务)之间，最晚记录的准备事件是PH。

因此，可以将PH对应的结束位点确定为裁剪位点。

为了方便展示裁剪位点，在存储节点1-2的操作日志中，标注出了PH在操作日志中所占据的段落，裁剪位点就是PH占据段落结束的位点。

从而方便后续备份裁剪位点之前的操作日志，将PH也包含在备份的操作日志中。

存储节点3中，在可提交事务集合(包括事务1-2和心跳事务)中针对存储节点3的事务(事务2和心跳事务)之间，最晚记录的准备事件是PH。

因此，可以将PH对应的结束位点确定为裁剪位点。

存储节点4中，在可提交事务集合(包括事务1-2和心跳事务)中所针对存储节点4的事务(事务2和心跳事务)之间，最晚记录的准备事件是P2。

因此，可以将P2对应的结束位点确定为裁剪位点。

在后续针对存储节点1-4，利用备份的操作日志进行数据恢复时，可以通过操作确保可提交事务集合(包括事务1-2和心跳事务)的事务一致性。

针对心跳事务，存储节点1-4在利用备份到裁剪位点的操作日志进行数据恢复后，心跳事务都基于PH进行恢复，处于准备提交状态。

由于心跳事务属于可提交事务集合，可以确定处理结果为“提交”，因此，可以由计算节点向存储节点1-4下发针对心跳事务的提交消息，使得存储节点1-4之间，心跳事务的处理结果都是“提交成功”，确保心跳事务的一致性。

针对事务1，存储节点1-2在利用备份到裁剪位点的操作日志进行恢复后，存储节点1中事务1已经基于P1和C1，“提交成功”，存储节点2中事务1基于P1，还处于准备提交状态。

由于事务1属于可提交事务集合，可以确定处理结果为“提交”，因此，可以由计算节点向存储节点2下发针对事务1的提交消息，使得存储节点1和存储节点2之间，事务1的处理结果都是“提交成功”，确保事务1的一致性。

同理，也可以确保事务2的一致性。此处不再赘述。

6)通过上述操作，可以确保初始的可提交事务集合中的事务一致性。但是还存在其他第一时刻之后发起的两阶段提交事务，需要确保一致性。

下面根据其他第一时刻之后发起的两阶段提交事务分类，分别解释确保一致性的方式。

a)如果裁剪位点在PH(心跳事务准备事件)之后，那么在备份的操作日志中，可能存在事务的提交事件位于PH与裁剪位点之间，但是该事务不在可提交事务集合中。

为了便于理解，如图8所示，为本说明书实施例提供的另一种操作日志备份的原理示意图。

其中展示了存储节点1-4的操作日志，并且展示了事务2-3的准备事件和提交事件，以及心跳事务的准备事件和提交事件在操作日志中的位置。

为了便于描述，将事务2的准备事件描述为P2，将事务2的提交事件描述为C2。将事务3的准备事件描述为P3，将事务3的提交事件描述为C3。将心跳事务的准备事件描述为PH，将心跳事务的提交事件描述为CH。

其中，事务2是针对存储节点3-4的事务。事务3是针对存储节点2-4的事务。心跳事务是针对存储节点1-4的事务。

具体裁剪位点的确定可以参考图7的解释，此处不再赘述。

在确定裁剪位点之后，存储节点2中备份的裁剪位点之前的操作日志中，并不包括P3和C3；存储节点3中备份的裁剪位点之前的操作日志中，只包括P3，不包括C3；存储节点4中备份的裁剪位点之前的操作日志中，包括P3和C3。

由于事务3在所针对的存储节点1-4中PH之前，都不存在C3，因此，事务3没有被添加到可提交事务集合中。

但是随着裁剪位点的确定和操作日志的备份，存储节点2-4备份的操作日志之间，事务3的准备事件没有全部保留，后续恢复时存储节点2没有备份的P3，事务3无法基于P3恢复到“准备提交”状态，也就无法利用下发的提交消息恢复到存储节点4中事务3的“提交成功”结果。从而无法确保事务3的一致性。

为了确保可提交事务集合之外，并且在至少一个存储节点操作日志中PH与裁剪位点之间，存在提交事件的事务的一致性，可以将这类事务所针对的每个存储节点中的准备事件都包含在备份操作日志中。

为了便于描述，将可提交事务集合之外，并且在至少一个存储节点操作日志中PH与裁剪位点之间，存在提交事件的事务称为“补充事务”。

需要说明的是，由于初始的裁剪位点，是针对每个存储节点，将可提交事务集合中针对该节点的两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件对应的结束位点，确定为裁剪位点。

而初始的可提交事务集合中，心跳事务以外的每个事务都在至少一个存储节点操作日志中，存在提交事件位于心跳事务准备事件之前。

基于上述推论二，如果在一个存储节点的操作日志中，两阶段提交事务1的提交事件之后，存在两阶段提交事务2的准备事件，则可以确定事务1的提交消息下发时刻，早于事务2的提交消息下发时刻。

因此，可以确定初始的可提交事务集合中，心跳事务以外每个事务的提交消息下发时刻，都早于心跳事务的提交消息下发时刻。

进一步地，针对补充事务，可以确定补充事务在初始的可提交事务集合中裁剪位点对应事务的准备事件之前，存在提交事件。

并且，由于补充事务存在提交事件在至少一个存储节点操作日志的PH与裁剪位点之间，裁剪位点并不是PH结束位点，因此，裁剪位点对应事务并不是心跳事务。

从而可以确定，裁剪位点对应事务的提交消息下发时刻，早于心跳事务的提交消息下发时刻。

同样基于上述推论二，可以确定补充事务的提交消息下发时刻，早于初始可提交事务集合中裁剪位点对应事务的提交消息下发时刻。

因此，可以确定时序先后顺序为：补充事务的提交消息下发时刻、裁剪位点对应事务的提交消息下发时刻、心跳事务的提交消息下发时刻。

换言之，补充事务的提交消息下发时刻都早于心跳事务的提交消息下发时刻。

进一步地，基于上述推论一：针对每个两阶段提交事务，在该事务所针对的每个存储节点中，该事务准备事件都记录在计算节点下发该事务提交信息的时刻之前，该事务提交事件都记录在计算节点下发该事务提交信息的时刻之后。

可以确定在补充事务所针对的每个存储节点中，补充事务的准备事件都在补充事务的提交消息下发时刻之前。

也可以确定，在心跳事务所针对的每个存储节点(也就是数据库中全部存储节点中)心跳事务的提交事件都在心跳事务的提交消息下发时刻之后。

从而可以确定，在补充事务所针对的每个存储节点中，补充事务的准备事件，都在心跳事务的提交事件之前。

为了便于理解，如图9所示，为本说明书实施例提供的另一种操作日志备份的原理示意图。

图9中具体的解释可以参见图8的解释。

其中，根据存储节点4中，P3-C3-P2，可以确定事务3的提交消息的下发时刻，早于事务2的提交消息下发时刻。

又根据存储节点3中P2-C2-PH-CH，可以确定事务2的提交消息下发时刻，早于心跳事务的提交消息下发时刻。

因此，可以确定出，在存储节点2-4中，P3不会超出“事务3提交消息下发时刻”，进而不会超过“事务2提交消息下发时刻”，也不会超过“心跳事务的提交消息下发时刻”，也就都在CH之前。

换言之，在存储节点2-4中，P3都在CH之前。

在证明补充事务的准备事件都在CH之前的情况下，为了确保补充事务的一致性，可以也将补充事务添加到可提交事务集合中，使用相同的裁剪位点确定方式，使得补充事务所针对的每个存储节点都备份补充事务的准备事件。

当然，随着补充事务添加到可提交事务集合中，所确定的裁剪位点可能进一步向后移动，从而出现新的补充事务。

由于可提交事务集合中，即使添加了补充事务，补充事务本身的提交消息下发时刻，都早于心跳事务的提交消息下发时刻，因此，添加了补充事务后的可提交事务集合，仍然符合“可提交事务集合中，心跳事务以外每个事务的提交消息下发时刻，都早于心跳事务的提交消息下发时刻”。

进一步地，可以基于相同的推理过程，证明新的补充事务的准备事件，也都在心跳事务提交事件之前。

因此，可以循环更新可提交事务集合和每个存储节点的裁剪位点，直到没有新的补充事务出现。

在本实施例中，通过循环更新可提交事务集合和每个存储节点的裁剪位点，直到每个存储节点的PH与裁剪位点之间存在提交事件的事务都可以添加到可提交事务集合中，从而可以确保裁剪位点之前的操作日志中，包括当前的可提交事务集合中针对该节点的全部事务的准备事件。

进而可以确保，对于每个存储节点的PH与裁剪位点之间存在提交事件的事务，在所针对的全部存储节点备份的操作日志中，都包含该事务准备事件，从而至少能够确保该事务在后续恢复时可以恢复到“准备提交”状态。

并且由于该事务可以确定处理结果为“提交”，也就可以由计算节点下发该事务的提交消息，确保该事务所针对的全部存储节点之间，该事务的处理结果都是“提交成功”。

因此，可以确保每个存储节点的PH与裁剪位点之间存在提交事件的事务的一致性。

可选地，可以在全部存储节点提交心跳事务成功的情况下，针对每个存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；将心跳事务添加到当前可提交事务集合中。

针对每个存储节点，可以将当前可提交事务集合中针对该节点的两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件对应的结束位点，确定为当前裁剪位点。

循环更新当前可提交事务集合和各个存储节点的当前裁剪位点，直到针对每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中。

其中，每个存储节点的当前裁剪位点为，当前可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点。

本实施例可以通过循环更新，将每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务，都包含在循环更新结束后的当前可提交事务集合中。

由于当前裁剪位点也是根据当前可提交事务集合确定的，可以确保在每个存储节点中，当前裁剪位点之前的操作日志包括当前可提交事务集合中每个事务的准备事件。

进而可以使得循环更新结束后的当前可提交事务集合中，每个事务在恢复时，至少能够恢复到“准备提交状态”。

进一步，可以确定当前可提交事务集合中每个事务的处理结果都是“提交”，进而可以针对还未提交成功的事务，由计算节点下发相应的提交消息。

因此，可以确保循环更新结束后的当前可提交事务集合中每个事务的一致性。

为了便于理解，如图10所示，为本说明书实施例提供的另一种操作日志备份的原理示意图。

图10中具体的解释可以参见图9的解释。

经过循环更新，可以确定当前的可提交事务集合中包括事务2、事务3和心跳事务。

而当前的裁剪位点可以更新为当前的位点。

具体地，其中存储节点2的裁剪位点可以更新为P3的结束位点。

基于图10中的当前裁剪位点进行操作日志的备份，也就可以将事务2、事务3和心跳事务的准备事件都包含在备份的日志中。从而可以确保事务2、事务3和心跳事务的一致性。

b)以裁剪位点为界，上述解释了在至少一个存储节点的裁剪位点之前存在提交事件的事务如何确保一致性。

对于循环更新结束后的当前可提交事务集合以外的两阶段提交事务，如果在后续根据备份的操作日志恢复后，处于完成的状态。换言之，这些事务在裁剪位点之前都已经完成。那么这些事务的处理结果已经保持一致，存在一致性，无需通过额外的操作确保事务一致性。

对于循环更新结束后的当前可提交事务集合以外的两阶段提交事务，如果在后续根据备份的操作日志恢复后，还处于未完成的状态，那么计算节点可以直接下发相应的回滚消息，确保这些事务的一致性。

具体地，未完成的事务存在以下两种分类。

(1)在事务所针对的每个存储节点备份的操作日志中(也就是裁剪位点之前)，都不存在提交事件或回滚事件。

在这种情况下，在该事务所针对的每个存储节点备份的操作日志中(也就是裁剪位点之前)可能存在准备事件，也可能不存在准备事件。

由于无法确定该事务的处理结果，因此，可以直接通过回滚的方式，确保在恢复时，该事务的处理结果都是“回滚成功”，从而确保一致性。

(2)在事务所针对的至少一个存储节点备份的操作日志中(也就是裁剪位点之前)，存在回滚事件。

在这种情况下，该事务属于所针对的全部存储节点没有全部回滚成功，所以还处于未完成的状态。

由于已经确定该事务的处理结果为“回滚”，因此，可以通过回滚的方式，确保在恢复时，该事务的处理结果都是“回滚成功”，从而确保一致性。

综上所述，以裁剪位点为分类依据，可以针对在裁剪位点之前发起的事务，通过上述实施例确保一致性。

具体地，对于裁剪位点之前发起的事务，在裁剪位点之前可能已经完成(全部提交成功或者全部回滚成功)、或者在裁剪位点之前没有全部提交成功(未完成)，或者在裁剪位点之前没有全部回滚成功(未完成)、或者在裁剪位点之前没有处理结果(未完成)。

具体可以总结为以下4种情况。

(1)对于在至少一个存储节点的裁剪位点之前存在提交事件的事务，能够确保一致性。

具体可以是，对于在至少一个存储节点的第一时刻与裁剪位点之间存在提交事件的事务，能够确保一致性。

也就是对于在裁剪位点之前全部提交成功(属于已完成的事务)，或者提交时未全部提交成功的事务，能够通过下发提交消息，确保一致性。

(2)对于在裁剪位点之前完成(全部提交成功或者全部回滚成功)的事务，能够通过基于备份操作日志的恢复，确保一致性。

(3)对于在裁剪位点之前回滚时未全部回滚成功的事务，能够通过下发回滚消息，确保一致性。

(4)对于在裁剪位点之前未完成，并且无法确定处理结果是提交还是回滚的事物，能够通过下发回滚消息，确保一致性。

因此，针对第一时刻和裁剪位点之间发起的两阶段提交事务，可以通过上述实施例，确保事务一致性。

四、额外补充说明。

需要额外说明的是，在确定裁剪位点时，并没有直接以心跳事务的提交事件为裁剪位点。

这是因为如果以心跳事务的提交事件为裁剪位点，那么对于补充事务，无法确定出补充事务的准备事件是否在心跳事务提交事件之前。

此外，在备份操作日志时，直接备份连续的操作日志，也就是第一位点到当前裁剪位点之前的操作日志，这是因为在后续恢复时，数据库中的同一数据可能被不同的事务连续修改，如果只备份用于保持事务一致性所需要的日志部分，可能会导致数据库中的数据无法恢复到原本的修改结果。

下面针对各个步骤进行详细的解释。

一、S101：针对每个存储节点中全量存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点。

本方法流程并不限定物理备份的方式。可选地，可以直接拷贝每个存储节点的数据库存储数据文件。

在本实施例中，由于无需逻辑备份，无需通过SQL语句查询数据，也就可以减少对数据库资源的消耗，提高备份效率。

在一种可选的实施例中，可以针对不同存储节点中全量存储数据同时进行物理备份，从而可以方便确定物理备份的时刻。

当然，允许不同存储节点可以在不同时刻进行物理备份。

关于存储节点中的操作日志，可选地，具体可以包括数据库逻辑日志，也就是binlog。可选地，操作日志也可以包括事务日志。

二、S102：在确定未完成事务集合中的全部两阶段提交事务完成的情况下，发起针对全部存储节点的心跳事务。

可选地，未完成事务集合可以包括，在物理备份之后的第一时刻，数据库中未完成的全部两阶段提交事务。

在一种可选的实施例中，可以预先获取未完成事务集合。

可选地，数据库可以包括至少一个计算节点。具体获取未完成事务集合，可以从计算节点中获取。不同的计算节点之间可以共享未完成事务集合。

本方法流程并不限定第一时刻，只要第一时刻在物理备份之后即可，也就是第一位点对应时刻之后。

可选地，可以在所有的存储节点物理备份完成的情况下，确定第一时刻。具体的第一时刻可以是全部存储节点之间物理备份完成的最晚时刻。可选地，第一时刻也可以是最后一个存储节点物理备份完成的时刻之后预设时长的时刻。

当然，第一时刻也可以是物理备份还未全部完成的时刻。

在一种可选的实施例中，两阶段提交事务完成，可以包括：两阶段提交事务所针对的每个存储节点，成功回滚该两阶段提交事务；或者两阶段提交事务所针对的每个存储节点，成功提交该两阶段提交事务。

可选地，在等待未完成事务集合中的全部两阶段提交事务完成之后，可以发起针对全部存储节点的心跳事务。

本方法流程并不限定发起心跳事务的时机，只要是在未完成事务集合中的全部两阶段提交事务完成之后即可。

可选地，可以是在确定未完成事务集合中的全部两阶段提交事务完成的时刻，发起针对全部存储节点的心跳事务。

可选地，心跳事务可以是针对数据库中每个存储节点的两阶段提交事务。

由于心跳事务主要用于针对全部存储节点进行标注，因此，心跳事务具体修改的数据可以不是用户数据，从而减少对用户数据的影响。

可选地，心跳事务可以是针对每个存储节点中的系统表进行修改的事务。

可选地，心跳事务可以是由计算节点针对全部存储节点发起的。

可选地，在数据库中的计算节点执行本方法流程的情况下，可以直接由该计算节点发起心跳事务。

可选地，在数据库以外的设备执行本方法流程的情况下，可以由该设备控制计算节点发起心跳事务。具体可以是由管理设备控制计算节点，针对数据库中的全部存储节点发起心跳事务。

三、S103：在全部存储节点提交心跳事务成功的情况下，针对每个存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；将心跳事务添加到当前可提交事务集合中。

S103是为了确定初始的当前可提交事务集合，方便后续进行循环更新。

基于上述针对事务一致性的原理分析，在全部存储节点提交心跳事务成功的情况下，可以确保每个存储节点操作日志中已经记录心跳事务提交事件。

从而可以确保当前可提交事务集合中的事务准备事件都已经记录到每个存储节点的操作日志中，方便后续确定每个存储节点的当前裁剪位点。

需要强调的是，由于需要使用心跳事务的提交事件，帮助确定每个存储节点的当前裁剪位点，因此，心跳事务的处理结果是提交成功，需要全部存储节点提交心跳事务成功。

此外，通过将心跳事务添加到初始的当前可提交事务集合中，使得每次循环更新的存储节点的当前裁剪位点，都在心跳事务准备事件的结束位点或者之后。

即使是存储节点的初始当前裁剪位点，由于初始的当前可提交事务集合包括心跳事务，初始的当前裁剪位点也都在心跳事务准备事件的结束位点或者之后。

由于心跳事务是在确定未完成事务集合中的全部两阶段提交事务完成的情况下，针对全部存储节点发起的，因此，未完成事务集合中的全部两阶段提交事务在操作日志中，都在心跳事务准备事件之前完成。

而裁剪位点都在心跳事务准备事件结束位点及之后，因此，可以确保备份的当前裁剪位点之前的操作日志中，包括未完成事务集合中的全部两阶段提交事务完成的相关记录(提交事件或者回滚事件)。

进而可以确保在后续进行恢复时，对于未完成事务集合中的全部两阶段提交事务，都可以基于备份的操作日志，恢复到完成状态，确保了这些事务的一致性。

在一种可选的实施例中，由于通过S102，已经确定未完成事务集合中的全部两阶段提交事务完成，从而可以备份相关的操作日志用于确保事务一致性，因此，S103是针对第一时刻之后发起的两阶段提交事务确保事务一致性。

因此，需要针对每个存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中。

当然，可选地，也可以将第一位点与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中。

可选地，也可以将心跳事务准备事件之前存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中。

在一种可选的实施例中，也可以将每个存储节点的部分操作日志拷贝出来，用于确定当前可提交事务集合，也可以用于后续进行循环更新。

可选地，可以针对每个存储节点，确定不在心跳事务提交事件的结束位点之前的第二位点。

之后可以综合全部存储节点的预设操作日志，用于确定当前可提交事务集合。可选地，预设操作日志可以至少包括：第一时刻和第二位点之间的操作日志。

当然，可选地，预设操作日志也可以包括：第一位点和第二位点之间的操作日志。

由于第二位点不在心跳事务提交事件的结束位点之前，也就是在心跳事务提交事件的结束位点及之后，从而可以方便后续确定每个存储节点的当前裁剪位点。

可选地，针对每个存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中，可以包括：针对每个存储节点的预设操作日志，将在心跳事务准备事件之前存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；预设操作日志包括：第一时刻和第二位点之间的操作日志。

本方法流程并不限定每个存储节点的操作日志中，确定第二位点的方式，只要所确定的第二位点不在心跳事务提交事件的结束位点之前，确保后续确定的当前可提交事务集合中每个事务准备事件都在第二位点之前即可。

可选地，可以根据时刻确定第二位点。具体可以是在确定每个存储节点中的心跳事务提交成功的情况下，确定第二时刻。第二时刻可以是在每个存储节点中心跳事务提交成功之后。

之后可以将第二时刻对应的操作日志位点，确定为第二位点。

基于时刻确定第二位点，可以提高确定第二位点的效率，从而提高备份效率。

可选地，也可以直接将心跳事务提交事件的结束位点，确定为第二位点。

综上所述，可选地，针对每个存储节点，确定不在心跳事务提交事件的结束位点之前的第二位点，可以包括：针对每个存储节点，将心跳事务提交事件的结束位点，确定为第二位点；或者在全部存储节点提交心跳事务成功的情况下，针对每个存储节点的操作日志，将第二时刻对应的位点，确定为第二位点；第二时刻不早于全部存储节点之间最晚记录的心跳事务提交事件结束位点。

可选地，第二时刻可以是全部存储节点之间最晚提交的心跳事务对应的时刻，也可以晚于全部存储节点之间最晚提交的心跳事务对应的时刻。

四、S104：循环更新当前可提交事务集合和每个存储节点的当前裁剪位点，直到针对每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中。

可选地，每个存储节点的当前裁剪位点为，当前可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点。

在一种可选的实施例中，基于上述针对事务一致性的原理分析，需要针对当前可提交事务集合和每个存储节点的当前裁剪位点进行循环更新。

在循环更新的过程中，需要根据当前可提交事务集合，利用上述方法确定出每个存储节点的当前裁剪位点。

进一步地，需要根据每个存储节点的当前裁剪位点，确定是否存在新的补充事务，也就是当前可提交事务集合以外，并且在心跳事务准备事件与当前裁剪位点之间存在提交事件的事务。

如果存在新的补充事务，可以将新的补充事务添加到当前可提交事务集合中进行更新，进而执行下一轮的循环更新。

如果不存在新的补充事务，则可以说明，针对每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中。

基于上述针对事务一致性的原理分析，可以确定对于在至少一个存储节点的当前裁剪位点之前存在提交事件的事务，能够通过后续的操作，确保事务一致性。

当然，对于其他事务，也能够通过后续的操作，确保事务一致性。

需要说明的是，每个存储节点的当前裁剪位点都不会超出心跳事务提交事件，具体证明可以参见上述针对事务一致性的原理分析。

而第一时刻与心跳事务提交事件之间，存在提交事件的全部两阶段提交事务是有限的，因此，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务，也是有限的。

换言之，上述循环更新可以趋于收敛，循环更新能够在有限次数后结束。

可选地，循环更新当前可提交事务集合和每个存储节点的当前裁剪位点，可以包括：循环执行以下步骤，直到当前可提交事务集合没有新增事务：针对每个存储节点，将在心跳事务准备事件与当前裁剪位点之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；针对每个存储节点，将当前可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点，确定为当前裁剪位点。

其中，当前可提交事务集合没有新增事务，则可以说明，针对每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中。

针对每个存储节点的当前裁剪位点，本方法流程并不限定具体的确定方法。

可选地，可以从心跳事务准备事件开始向后遍历，也可以从心跳事务提交事件开始向前遍历，也可以确定出心跳事务准备事件与心跳事务提交事件之间的所有事务准备事件以及对应的先后顺序，用于确定当前裁剪位点。

可选地，每个存储节点的当前裁剪位点确定方法，可以包括：针对每个存储节点，从心跳事务提交事件开始，向前遍历操作日志中的全部准备事件；在当前遍历的准备事件对应两阶段提交事务，属于当前可提交事务集合的情况下，将该事务准备事件的结束位点，确定为该存储节点的当前裁剪位点。

五、S105：循环结束后，备份当前可提交事务集合，以及每个存储节点中第一位点到当前裁剪位点之间的操作日志。

基于上述关于事务一致性的分析，在物理备份每个存储节点中全量存储数据之外，还需要在循环结束后，备份当前可提交事务集合，以及每个存储节点中第一位点到当前裁剪位点之间的操作日志。

可选地，具体可以是从操作日志中，裁剪拷贝出第一位点到裁剪位点之间的操作日志。

此外，在一种可选的实施例中，基于上述关于事务一致性的分析，对于上述实施例中包含心跳事务的可提交事务集合，除了心跳事务以外，其他事务都在所针对的至少一个存储节点操作日志中，在当前裁剪位点之前存在提交事件。

而对于心跳事务，每个存储节点中心跳事务提交事件都在当前裁剪位点之后。

因此，针对心跳事务，也可以不添加到可提交事务集合中。

需要说明的是，一方面，由于需要确保未完成事务集合中全部两阶段提交事务完成的操作日志进行备份，因此，当前裁剪位点需要在心跳事务准备事件的结束位点或之后，这是因为心跳事务是在未完成事务集合中全部两阶段事务完成后发起的。换言之，未完成事务集合中全部两阶段事务完成之后，才会发起心跳事务，才会记录心跳事务准备事件。

另一方面，虽然心跳事务在数据库中处理结果是提交。但是因为心跳事务的提交事件无法进行备份，因此，也可以在恢复数据库存储数据时，针对心跳事务进行回滚，确保心跳事务的一致性。

可选地，如图11所示，为本说明书实施例提供的另一种数据备份方法的流程示意图。

本方法流程并不限定执行主体，具体可以应用于数据库，用于针对数据库中的存储数据进行备份。

数据库中可以包括至少两个存储节点；数据库中的存储数据可以分散存储在至少两个存储节点中。

本方法流程可以包括以下步骤。

S201：针对每个存储节点中全量存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点。

S202：在确定未完成事务集合中的全部两阶段提交事务完成的情况下，发起针对全部存储节点的心跳事务。

可选地，未完成事务集合可以包括，在物理备份之后的第一时刻，数据库中未完成的全部两阶段提交事务。

S203：在全部存储节点提交心跳事务成功的情况下，针对每个存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；将心跳事务准备事件的结束位点确定为每个存储节点的当前裁剪位点。

S204：循环更新当前可提交事务集合和每个存储节点的当前裁剪位点，直到针对每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中。

可选地，其中，每个存储节点的当前裁剪位点为，备选位点和心跳事务准备事件的结束位点之间最晚记录的位点；备选位点为，当前可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点。

S205：循环结束后，备份当前可提交事务集合，以及每个存储节点中第一位点到当前裁剪位点之间的操作日志。

需要说明的是，初始的当前裁剪位点可以确定为心跳事务准备事件的结束位点。

后续针对当前裁剪位点进行更新时，如果备选位点在心跳事务准备事件的结束位点之前，那么可能备选位点之前的操作日志，没有包括未完成事务集合中全部事务完成的日志，因此，需要在备选位点和心跳事务准备事件的结束位点之间，确定最晚记录的位点作为当前裁剪位点。

本方法流程的解释可以参见上述方法流程的解释。

基于上述数据备份方法的实施例，本说明书实施例还提供了一种在上述备份方法实施例的基础上，进行数据恢复的方法实施例。

如图12所示，为本说明书实施例提供的一种数据恢复方法的流程示意图。

本方法流程的执行主体并不限定，具体可以是数据库，也可以是数据库中的计算节点，也可以是数据库以外的管理设备。具体解释可以参见上文。

其中可以包括以下步骤。

S301：针对任一存储节点，获取物理备份的全量存储数据，以及备份的第一位点到当前裁剪位点之间的操作日志，并基于所获取的全量存储数据和所获取的操作日志恢复该存储节点。

可选地，由于操作日志中包括存储节点的操作，因此，存储节点针对物理备份的全量存储数据，可以逐个执行所备份的操作日志中的操作，实现数据恢复。

S302：获取备份的当前可提交事务集合。

S303：在该存储节点完成恢复的情况下，针对该存储节点中处于准备提交状态的每个两阶段提交事务，在该事务属于当前可提交事务集合的情况下，提交该事务，在该事务不属于当前可提交事务集合的情况下，回滚该事务。

可选地，上述步骤S301和S302之间的执行顺序并不限定，可以并行执行，也可以串行执行。

通过利用当前可提交事务集合，将每个存储节点中当前裁剪位点之前存在提交事件的事务都进行提交，确保这类事务的处理结果都能够恢复到提交成功，从而可以确保一致性。

换言之，可以针对在至少一个存储节点的当前裁剪位点之前存在提交事件的事务，通过提交事务确保一致性。

对于其他事务，也就是在全部存储节点中当前裁剪位点之前不存在提交事件的事务，在这类事务所针对的全部存储节点之间，备份的操作日志都不包含这类事务的提交事件。

因此，基于备份的操作日志，这类事务的处理结果无法确定或者就是回滚。

针对这类事务，可以通过回滚确保一致性。

综上所述，本方法流程可以基于上述数据备份方法的实施例，确保恢复的数据库存储数据的事务一致性。

需要说明的是，对于在全部存储节点中当前裁剪位点之前不存在提交事件的事务，即使备份的操作日志中，存在这类事务的准备事件，在恢复时也只需要将数据写入日志(例如，redo日志)，而不会影响数据库存储数据的恢复。

即使后续针对这类事务进行回滚，也不会影响数据库存储数据的恢复。

在一种可选的实施例中，也可以在该存储节点完成恢复的情况下，针对该存储节点中未完成的每个两阶段提交事务，在该事务属于当前可提交事务集合的情况下，提交该事务，在该事务不属于当前可提交事务集合的情况下，回滚该事务。

对于未完成的两阶段提交事务，可以包括：不确定处理结果的两阶段提交事务、没有全部提交的两阶段提交事务、没有全部回滚的两阶段提交事务。

由于当前可提交事务集合中的事务，在至少一个存储节点的当前裁剪位点之前存在提交事件，能够确定处理结果是提交，因此，“不确定处理结果的两阶段提交事务”不在当前可提交事务集合中，从而可以通过回滚事务确保一致性。

对于没有全部提交的两阶段提交事务，一定在至少一个存储节点的当前裁剪位点之前存在提交事件，用于确定处理结果是提交，因此，“没有全部提交的两阶段提交事务”在当前可提交事务集合中，从而可以通过提交事务确保一致性。

对于没有全部回滚的两阶段提交事务，由于事务的处理结果已经确定是回滚，从而可以通过回滚事务确保一致性。

当然，对于事务是否属于未完成状态，通常需要综合多个存储节点进行确定，因此，在一种可选的实施例中，可以针对数据库中的多个存储节点进行数据恢复，具体可以是针对数据库中的全部存储节点进行数据恢复，从而可以在恢复完成后，确定数据库中未完成的事务。

可选地，针对每个存储节点，获取物理备份的全量存储数据，以及备份的第一位点到当前裁剪位点之间的操作日志，并基于所获取的全量存储数据和所获取的操作日志恢复该存储节点。

获取备份的当前可提交事务集合。

在每个存储节点完成恢复的情况下，针对数据库中未完成的每个两阶段提交事务，在该事务属于当前可提交事务集合的情况下，提交该事务，在该事务不属于当前可提交事务集合的情况下，回滚该事务。

针对事务的提交和回滚，本方法流程并不限定具体的实现方式。

可选地，可以由计算节点下发事务提交消息实现事务的提交，也可以由计算节点下发事务回滚消息实现事务的回滚。

可选地，也可以不经过计算节点，直接实现事务的提交和回滚，具体可以是针对需要提交的事务，将日志中的数据处理结果写入数据库，具体可以是写入存储节点所存储的数据库数据中；针对需要回滚的事务，可以在日志中记录回滚事件。

在一种可选的实施例中，在两阶段提交事务包括XA事务的情况下，可以使用XARECOVER获取悬挂事务列表，也就是该存储节点中处于准备提交状态的每个两阶段提交事务。

还可以在提交两阶段提交事务时，使用XA COMMIT提交事务。在回滚两阶段提交事务时，使用XA ROLLBACK回滚事务。

上述方法流程描述了针对单个存储节点的存储数据恢复方法，针对多个存储节点，可以分别通过上述方法流程恢复各个存储节点存储的数据库数据，从而恢复完整的数据库。

基于上述备份的方法实施例，可以通过简单的操作实现对数据库的恢复，从而可以提高恢复效率，并且可以确保事务的一致性。

基于上述的数据备份方法实施例，以及对应的恢复方法实施例，由于针对存储节点中全量存储数据直接进行物理备份，并且备份的是操作日志，对于数据库中的数据并没有执行查询等操作，因此，降低了对运行在数据库上的业务的影响。

基于上述的备份方法实施例，可以通过确定预设操作日志进行综合，而不是全量的操作日志，有效控制了需要协同确定可提交事务集合的数据量，降低了协同的代价。

并且，各个存储节点可以并行地分别进行备份操作，有效提高了备份过程的并发度，提高了整体数据库备份数据的效率。

基于上述的恢复方法实施例，各个存储节点也可以并行地分别进行恢复操作，无需交互协同，有效提高了恢复过程的并发度，提高了整体数据库恢复数据的效率。

因此，上述方法实施例，在数据库上实现了一种可以进行一致恢复的、全量的、物理的备份过程和对应的恢复过程，对于数据库自身业务的影响较小。

备份和恢复的过程可以支持大部分基于MySQL XA接口实现的分布式事务，也就是XA事务。

并且，备份和恢复的过程是高效的、低代价的、低协同的。具体可以体现在可提交事务集合的确定代价较小。

此外，本说明书实施例还提供了另一种数据备份方法的方法实施例。

在该方法实施例中，可以确保部分事务在恢复后的一致性。

如图13所示，为本说明书实施例提供的另一种数据备份方法的流程示意图。

本方法流程并不限定执行主体，具体可以应用于数据库，用于针对数据库中的存储数据进行备份。数据库中可以包括至少两个存储节点。

可选地，数据库中的不同存储节点，可以分散存储数据库中的存储数据。

该方法流程可以包括以下步骤。

S401：针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点。

S402：构建可提交事务集合，并确定存储节点的裁剪位点。

其中，可选地，可提交事务集合可以包括：在第一位点到裁剪位点之间，存在提交事件的两阶段提交事务。

可选地，存储节点的裁剪位点可以包括，可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点。

S403：备份可提交事务集合，以及存储节点中第一位点到裁剪位点之间的操作日志。

其中，可选地，存储节点具体可以是数据库中的每个存储节点。

可选地，存储节点中的存储数据，具体可以包括存储节点中的全量存储数据。

可选地，可提交事务集合可以包括：在第一位点到裁剪位点之间，存在提交事件的全部或部分两阶段提交事务。

可选地，可提交事务集合可以包括：在全部或部分存储节点的第一位点到裁剪位点之间，存在提交事件的两阶段提交事务。

在本方法流程中，可以通过构建可提交事务集合，并且将可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点，确定为裁剪位点，进而可以确定在备份的日志中，至少包括可提交事务集合中事务的准备事件，方便后续恢复数据时，通过提交操作，确保可提交事务集合中事务的一致性。

具体可以是在备份的日志中，至少包括可提交事务集合中每个事务的准备事件。

具体确保可提交事务集合中事务一致性的原理可以参见上文解释。

在一种可选的实施例中，确定存储节点的裁剪位点，可以包括：在预设事务完成时刻对应的操作日志位点之后，确定存储节点的裁剪位点。

其中，可选地，预设事务完成时刻可以包括：未完成事务集合中两阶段提交事务完成的时刻。

可选地，未完成事务集合可以包括，在物理备份之后的第一时刻，数据库中未完成的两阶段提交事务。

在本实施例中，可以通过在预设事务完成时刻对应的操作日志位点之后，设置裁剪位点，从而可以确定在备份的日志中，至少包括未完成事务集合中事务完成所需的事件，方便后续根据备份的日志恢复数据时，可以确保未完成事务集合中的事务完成，确保未完成事务集合中事务的一致性。

具体可以是在备份的日志中，至少包括未完成事务集合中每个事务完成所需的事件。

具体确保未完成事务集合中事务一致性的原理可以参见上文解释。

其中，可选地，未完成事务集合可以包括，在物理备份之后的第一时刻，数据库中未完成的全部或部分两阶段提交事务。

可选地，预设事务完成时刻可以包括：未完成事务集合中全部或部分两阶段提交事务完成的时刻。

在一种可选的实施例中，构建可提交事务集合，并确定存储节点的裁剪位点，可以包括以下步骤。

在确定未完成事务集合中的两阶段提交事务完成的情况下，发起针对存储节点的心跳事务。

其中，未完成事务集合可以包括，在物理备份之后的第一时刻，数据库中未完成的两阶段提交事务。

在存储节点提交心跳事务成功的情况下，针对存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；将心跳事务添加到当前可提交事务集合中。

循环更新当前可提交事务集合和存储节点的当前裁剪位点，确认存储节点在第一时刻与当前裁剪位点之间存在提交事件的两阶段提交事务，包含在当前可提交事务集合中。

其中，存储节点的当前裁剪位点可以包括，当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点。

其中，可选地，发起针对存储节点的心跳事务，具体可以是发起针对全部或部分存储节点的心跳事务。

可选地，存储节点提交心跳事务成功的情况，可以包括全部或部分存储节点提交心跳事务成功的情况。

可选地，可以针对全部或部分存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中。

可选地，可以针对存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部或部分两阶段提交事务，添加到当前可提交事务集合中。

可选地，可以循环更新全部或部分存储节点的当前裁剪位点。

可选地，可以确认全部或部分存储节点在第一时刻与当前裁剪位点之间存在提交事件的两阶段提交事务，包含在当前可提交事务集合中。

可选地，可以确认存储节点在第一时刻与当前裁剪位点之间存在提交事件的全部或部分两阶段提交事务，包含在当前可提交事务集合中。

可选地，存储节点的当前裁剪位点可以包括，当前可提交事务集合中针对该存储节点的全部或部分两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点。

在本实施例中，通过心跳事务的设置，可以确定存储节点的裁剪位点在心跳事务准备事件的结束位点或之后，从而可以使得备份的日志中，至少包括未完成事务集合中事务完成所需的事件。并且，也可以确定存储节点的裁剪位点在心跳事务提交事件之前。

具体的原理可以参见上文解释。

可选地，备份可提交事务集合，以及存储节点中所述第一位点到裁剪位点之间的操作日志，可以包括：循环结束后，备份当前可提交事务集合，以及存储节点中第一位点到当前裁剪位点之间的操作日志。

可选地，循环更新当前可提交事务集合和存储节点的当前裁剪位点，可以包括：

循环执行以下步骤，直到当前可提交事务集合没有新增事务：

针对存储节点，将在心跳事务准备事件与当前裁剪位点之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；

针对存储节点，将当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点，确定为当前裁剪位点。

可选地，具体可以是针对一个或多个存储节点，执行上述步骤。

可选地，可以是针对全部或部分存储节点，将在心跳事务准备事件与当前裁剪位点之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中。

可选地，可以针对存储节点，将在心跳事务准备事件与当前裁剪位点之间存在提交事件的全部或部分两阶段提交事务，添加到当前可提交事务集合中。

可选地，可以针对全部或部分存储节点，将当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点，确定为当前裁剪位点。

可选地，可以针对存储节点，将当前可提交事务集合中针对该存储节点的全部或部分两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点，确定为当前裁剪位点。

可选地，存储节点的当前裁剪位点确定方法，可以包括：

针对存储节点，从心跳事务提交事件开始，向前遍历操作日志中的准备事件；

在当前遍历的准备事件对应两阶段提交事务，属于当前可提交事务集合的情况下，将该事务准备事件的结束位点，确定为该存储节点的当前裁剪位点。

可选地，可以针对全部或部分存储节点，从心跳事务提交事件开始，向前遍历操作日志中的准备事件。

可选地，可以针对存储节点，确定不在心跳事务提交事件的结束位点之前的第二位点；

可选地，针对存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中，可以包括：

针对存储节点的预设操作日志，将在心跳事务准备事件之前存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；预设操作日志可以包括：第一时刻和第二位点之间的操作日志。

确认存储节点在第一时刻与当前裁剪位点之间存在提交事件的两阶段提交事务，包含在当前可提交事务集合中，可以包括：

确认存储节点的预设操作日志中，在当前裁剪位点之前存在提交事件的两阶段提交事务，包含在当前可提交事务集合中。

可选地，针对存储节点，确定不在心跳事务提交事件的结束位点之前的第二位点，可以包括：

针对存储节点，将心跳事务提交事件的结束位点，确定为第二位点；或者

在存储节点提交心跳事务成功的情况下，针对存储节点的操作日志，将第二时刻对应的位点，确定为第二位点；所述第二时刻不早于存储节点之间最晚记录的心跳事务提交事件的结束位点。

可选地，两阶段提交事务完成，可以包括：两阶段提交事务所针对的存储节点，成功回滚该两阶段提交事务；或者两阶段提交事务所针对的存储节点，成功提交该两阶段提交事务。

可选地，操作日志可以包括：数据库逻辑日志；两阶段提交事务可以包括：XA事务。

本方法流程的具体解释，可以参见上述方法流程S101-S105的解释。

本说明书实施例也提供另一种数据备份方法的方法实施例。

本方法流程并不限定执行主体，具体可以应用于数据库，用于针对数据库中的存储数据进行备份。数据库中可以包括至少两个存储节点。

该方法流程可以包括以下步骤。

S501：针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点。

S502：在确定未完成事务集合中的两阶段提交事务完成的情况下，发起针对存储节点的心跳事务；未完成事务集合包括，在物理备份之后的第一时刻，数据库中未完成的两阶段提交事务。

S503：在存储节点提交心跳事务成功的情况下，针对存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；将心跳事务准备事件的结束位点确定为存储节点的当前裁剪位点。

S504：循环更新当前可提交事务集合和存储节点的当前裁剪位点，确认存储节点在第一时刻与当前裁剪位点之间存在提交事件的两阶段提交事务，包含在当前可提交事务集合中。

其中，存储节点的当前裁剪位点包括，备选位点和心跳事务准备事件的结束位点之间最晚记录的位点；备选位点为，当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

S505：循环结束后，备份当前可提交事务集合，以及存储节点中第一位点到当前裁剪位点之间的操作日志。

本方法流程的解释可以参见上文。

本说明书实施例还提供另一种数据恢复方法。具体可以是基于上述方法流程S401-S403的数据恢复方法。

本方法流程可以包括以下步骤。

S601：针对存储节点，获取物理备份的存储数据，以及备份的第一位点到裁剪位点之间的操作日志，并基于存储数据和所获取的操作日志恢复该存储节点。

S602：获取备份的可提交事务集合。

S603：在该存储节点完成恢复的情况下，针对该存储节点中处于准备提交状态的两阶段提交事务，在该事务属于可提交事务集合的情况下，提交该事务，在该事务不属于可提交事务集合的情况下，回滚该事务。

本方法流程可以通过针对可提交事务集合中的事务，进行提交操作，从而可以确保可提交事务集合中的事务一致性。

具体解释和原理可以参见上文。

可选地，可以针对一个或多个存储节点，获取物理备份的存储数据，以及备份的第一位点到裁剪位点之间的操作日志，并基于存储数据和所获取的操作日志恢复该存储节点。具体可以是针对数据库中的全部或部分存储节点。

对应于上述方法实施例，本说明书实施例还提供了对应的装置实施例。

如图14所示，为本说明书实施例提供的一种数据备份装置的结构示意图。

本装置实施例具体可以应用于数据库，用于针对数据库中的存储数据进行备份。

数据库中可以包括至少两个存储节点；数据库中的存储数据可以分散存储在至少两个存储节点中。

该装置可以包括以下单元。

数据备份单元701，用于针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点。

构建单元702，用于构建可提交事务集合，并确定存储节点的裁剪位点。

其中，可选地，可提交事务集合包括：在第一位点到裁剪位点之间，存在提交事件的两阶段提交事务。

可选地，存储节点的裁剪位点包括，可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点。

第一备份单元703，用于备份可提交事务集合，以及存储节点中第一位点到裁剪位点之间的操作日志。

可选地，构建单元702用于：

在预设事务完成时刻对应的操作日志位点之后，确定存储节点的裁剪位点；

预设事务完成时刻包括：未完成事务集合中两阶段提交事务完成的时刻；未完成事务集合包括，在物理备份之后的第一时刻，数据库中未完成的两阶段提交事务。

可选地，构建单元702用于：

在确定未完成事务集合中的两阶段提交事务完成的情况下，发起针对存储节点的心跳事务；未完成事务集合包括，在物理备份之后的第一时刻，数据库中未完成的两阶段提交事务；

在存储节点提交心跳事务成功的情况下，针对存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；将心跳事务添加到当前可提交事务集合中；

循环更新当前可提交事务集合和存储节点的当前裁剪位点，确认存储节点在第一时刻与当前裁剪位点之间存在提交事件的两阶段提交事务，包含在当前可提交事务集合中；

其中，存储节点的当前裁剪位点包括，当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点。

可选地，第一备份单元703用于：

循环结束后，备份当前可提交事务集合，以及存储节点中第一位点到当前裁剪位点之间的操作日志。

可选地，构建单元702用于：

循环执行以下步骤，直到当前可提交事务集合没有新增事务：

针对存储节点，将在心跳事务准备事件与当前裁剪位点之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；

针对存储节点，将当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点，确定为当前裁剪位点。

可选地，存储节点的当前裁剪位点确定方法，包括：

针对存储节点，从心跳事务提交事件开始，向前遍历操作日志中的准备事件；

在当前遍历的准备事件对应两阶段提交事务，属于当前可提交事务集合的情况下，将该事务准备事件的结束位点，确定为该存储节点的当前裁剪位点。

可选地，构建单元702还用于：针对存储节点，确定不在心跳事务提交事件的结束位点之前的第二位点；

可选地，构建单元702用于：

针对存储节点的预设操作日志，将在心跳事务准备事件之前存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；预设操作日志包括：第一时刻和第二位点之间的操作日志；

可选地，构建单元702用于：

确认存储节点的预设操作日志中，在当前裁剪位点之前存在提交事件的两阶段提交事务，包含在当前可提交事务集合中。

可选地，构建单元702用于：

针对存储节点，将心跳事务提交事件的结束位点，确定为第二位点；或者

在存储节点提交心跳事务成功的情况下，针对存储节点的操作日志，将第二时刻对应的位点，确定为第二位点；第二时刻不早于存储节点之间最晚记录的心跳事务提交事件的结束位点。

可选地，两阶段提交事务完成，包括：

两阶段提交事务所针对的存储节点，成功回滚该两阶段提交事务；或者

两阶段提交事务所针对的存储节点，成功提交该两阶段提交事务。

可选地，操作日志包括：数据库逻辑日志；两阶段提交事务包括：XA事务。

如图15所示，为本说明书实施例提供的另一种数据备份装置的结构示意图。

本装置实施例具体可以应用于数据库，用于针对数据库中的存储数据进行备份。

数据库中可以包括至少两个存储节点；数据库中的存储数据可以分散存储在至少两个存储节点中。

该装置可以包括以下单元。

物理备份单元801，用于针对每个存储节点中全量存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点。

心跳事务单元802，用于在确定未完成事务集合中的全部两阶段提交事务完成的情况下，发起针对全部存储节点的心跳事务；未完成事务集合包括，在物理备份之后的第一时刻，数据库中未完成的全部两阶段提交事务。

迭代更新单元803，用于在全部存储节点提交心跳事务成功的情况下，针对每个存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；将心跳事务添加到当前可提交事务集合中；迭代更新当前可提交事务集合和每个存储节点的当前裁剪位点，直到针对每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中；其中，每个存储节点的当前裁剪位点为，当前可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点。

备份单元804，用于迭代结束后，备份当前可提交事务集合，以及每个存储节点中第一位点到当前裁剪位点之间的操作日志。

可选地，迭代更新单元803具体用于：循环执行以下步骤，直到当前可提交事务集合没有新增事务：针对每个存储节点，将在心跳事务准备事件与当前裁剪位点之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；针对每个存储节点，将当前可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点，确定为当前裁剪位点。

可选地，每个存储节点的当前裁剪位点确定方法，包括：针对每个存储节点，从心跳事务提交事件开始，向前遍历操作日志中的全部准备事件；在当前遍历的准备事件对应两阶段提交事务，属于当前可提交事务集合的情况下，将该事务准备事件的结束位点，确定为该存储节点的当前裁剪位点。

可选地，迭代更新单元803还用于：针对每个存储节点，确定不在心跳事务提交事件的结束位点之前的第二位点。

可选地，迭代更新单元803具体用于：针对每个存储节点的预设操作日志，将在心跳事务准备事件之前存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；预设操作日志包括：第一时刻和第二位点之间的操作日志。

可选地，迭代更新单元803具体用于：迭代更新当前可提交事务集合和每个存储节点的当前裁剪位点，直到在每个存储节点的预设操作日志中，在当前裁剪位点之前存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中。

可选地，迭代更新单元803具体用于：针对每个存储节点，将心跳事务提交事件的结束位点，确定为第二位点；或者在全部存储节点提交心跳事务成功的情况下，针对每个存储节点的操作日志，将第二时刻对应的位点，确定为第二位点；第二时刻不早于全部存储节点之间最晚记录的心跳事务提交事件的结束位点。

可选地，两阶段提交事务完成，包括：两阶段提交事务所针对的每个存储节点，成功回滚该两阶段提交事务；或者两阶段提交事务所针对的每个存储节点，成功提交该两阶段提交事务。

可选地，操作日志可以包括：数据库逻辑日志；两阶段提交事务可以包括：XA事务。

本说明书实施例还提供另一种数据备份装置实施例。

本装置实施例具体可以应用于数据库，用于针对数据库中的存储数据进行备份。

数据库中可以包括至少两个存储节点；数据库中的存储数据可以分散存储在至少两个存储节点中。

该装置可以包括以下单元。

数据库备份单元，用于针对每个存储节点中全量存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点。

心跳单元，用于在确定未完成事务集合中的全部两阶段提交事务完成的情况下，发起针对全部存储节点的心跳事务；未完成事务集合包括，在物理备份之后的第一时刻，数据库中未完成的全部两阶段提交事务。

更新单元，用于在全部存储节点提交心跳事务成功的情况下，针对每个存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的全部两阶段提交事务，添加到当前可提交事务集合中；将心跳事务准备事件的结束位点确定为每个存储节点的当前裁剪位点；循环更新当前可提交事务集合和每个存储节点的当前裁剪位点，直到针对每个存储节点，在第一时刻与当前裁剪位点之间存在提交事件的全部两阶段提交事务都包含在当前可提交事务集合中。

可选地，其中，每个存储节点的当前裁剪位点为，备选位点和心跳事务准备事件的结束位点之间最晚记录的位点；备选位点为，当前可提交事务集合中针对该节点的全部两阶段提交事务之间，在该节点操作日志中最晚记录的准备事件的结束位点。

日志备份单元，用于循环结束后，备份当前可提交事务集合，以及每个存储节点中第一位点到当前裁剪位点之间的操作日志。

本说明书实施例还提供一种基于上述装置实施例的数据恢复装置，包括：

日志恢复单元，用于针对任一存储节点，获取物理备份的全量存储数据，以及备份的第一位点到当前裁剪位点之间的操作日志，并基于所获取的全量存储数据和所获取的操作日志恢复该存储节点。

事务恢复单元，用于获取备份的当前可提交事务集合；在该存储节点完成恢复的情况下，针对该存储节点中处于准备提交状态的每个两阶段提交事务，在该事务属于当前可提交事务集合的情况下，提交该事务，在该事务不属于当前可提交事务集合的情况下，回滚该事务。

上述装置实施例的具体解释可以参见上述方法实施例。

本说明书实施例还提供了一种系统实施例，具体可以是一种数据库系统。

数据库系统中可以包括管控节点和至少两个存储节点。

管控节点用于：针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

构建可提交事务集合，并确定存储节点的裁剪位点；

其中，可提交事务集合包括：在第一位点到裁剪位点之间，存在提交事件的两阶段提交事务；

存储节点的裁剪位点包括，可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

备份可提交事务集合，以及存储节点中第一位点到裁剪位点之间的操作日志。

其中，可选地，管控节点具体可以是数据库系统中的计算节点。数据库系统中可以包括计算节点和至少两个存储节点。

系统实施例的解释可以参见上述方法实施例。

数据库系统的架构图，作为一种示例，具体可以参见图2。

本说明书实施例还提供了一种系统实施例，具体可以是一种数据备份系统。

数据备份系统可以包括管理设备和数据库系统，数据库系统中可以包括至少两个存储节点。管理设备可以具有该数据库系统的控制权限。

管理设备用于：针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

构建可提交事务集合，并确定存储节点的裁剪位点；

其中，可提交事务集合包括：在第一位点到裁剪位点之间，存在提交事件的两阶段提交事务；

存储节点的裁剪位点包括，可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

备份可提交事务集合，以及存储节点中第一位点到裁剪位点之间的操作日志。

系统实施例的解释可以参见上述方法实施例。

为了便于理解，如图16所示，为本说明书实施例提供的一种数据备份系统的架构示意图。

其中包括管理设备和数据库系统。数据库系统中可以包括2个计算节点和3个存储节点。

管理设备可以具有数据库系统的控制权限，从而实现数据库系统中存储数据的备份。

当然，图16中数据库系统所包括的计算节点数量和存储节点数量都用于示例性说明，并不限定本说明书实施例的范围。

本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现上述任一方法实施例。

本说明书实施例还提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现上述任一方法实施例。

图17示出了本说明书实施例所提供的一种更为具体的计算机设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一方法实施例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护。

Claims (17)

1.一种数据备份方法，应用于数据库，所述数据库中包括至少两个存储节点；所述方法包括：

针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

构建可提交事务集合，并确定存储节点的裁剪位点；

其中，所述可提交事务集合包括：在所述第一位点到所述裁剪位点之间，存在提交事件的两阶段提交事务；

所述存储节点的裁剪位点包括，所述可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

备份所述可提交事务集合，以及存储节点中所述第一位点到所述裁剪位点之间的操作日志。

2.根据权利要求1所述方法，所述确定存储节点的裁剪位点，包括：

在预设事务完成时刻对应的操作日志位点之后，确定存储节点的裁剪位点；

所述预设事务完成时刻包括：未完成事务集合中两阶段提交事务完成的时刻；所述未完成事务集合包括，在物理备份之后的第一时刻，所述数据库中未完成的两阶段提交事务。

3.根据权利要求1所述方法，所述构建可提交事务集合，并确定存储节点的裁剪位点，包括：

在确定未完成事务集合中的两阶段提交事务完成的情况下，发起针对存储节点的心跳事务；所述未完成事务集合包括，在物理备份之后的第一时刻，所述数据库中未完成的两阶段提交事务；

在存储节点提交心跳事务成功的情况下，针对存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；将心跳事务添加到当前可提交事务集合中；

循环更新当前可提交事务集合和存储节点的当前裁剪位点，确认存储节点在第一时刻与当前裁剪位点之间存在提交事件的两阶段提交事务，包含在当前可提交事务集合中；

其中，所述存储节点的当前裁剪位点包括，当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点。

4.根据权利要求3所述方法，所述备份所述可提交事务集合，以及存储节点中所述第一位点到所述裁剪位点之间的操作日志，包括：

循环结束后，备份当前可提交事务集合，以及存储节点中所述第一位点到当前裁剪位点之间的操作日志。

5.根据权利要求3所述方法，所述循环更新当前可提交事务集合和存储节点的当前裁剪位点，包括：

循环执行以下步骤，直到当前可提交事务集合没有新增事务：

针对存储节点，将在心跳事务准备事件与当前裁剪位点之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；

针对存储节点，将当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点，确定为当前裁剪位点。

6.根据权利要求3所述方法，存储节点的当前裁剪位点确定方法，包括：

针对存储节点，从心跳事务提交事件开始，向前遍历操作日志中的准备事件；

在当前遍历的准备事件对应两阶段提交事务，属于当前可提交事务集合的情况下，将该事务准备事件的结束位点，确定为该存储节点的当前裁剪位点。

7.根据权利要求3所述方法，还包括：针对存储节点，确定不在心跳事务提交事件的结束位点之前的第二位点；

所述针对存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中，包括：

针对存储节点的预设操作日志，将在心跳事务准备事件之前存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；所述预设操作日志包括：第一时刻和第二位点之间的操作日志；

所述确认存储节点在第一时刻与当前裁剪位点之间存在提交事件的两阶段提交事务，包含在当前可提交事务集合中，包括：

确认存储节点的预设操作日志中，在当前裁剪位点之前存在提交事件的两阶段提交事务，包含在当前可提交事务集合中。

8.根据权利要求7所述方法，所述针对存储节点，确定不在心跳事务提交事件的结束位点之前的第二位点，包括：

针对存储节点，将心跳事务提交事件的结束位点，确定为第二位点；或者

在存储节点提交心跳事务成功的情况下，针对存储节点的操作日志，将第二时刻对应的位点，确定为第二位点；所述第二时刻不早于存储节点之间最晚记录的心跳事务提交事件的结束位点。

9.根据权利要求2所述方法，所述两阶段提交事务完成，包括：

所述两阶段提交事务所针对的存储节点，成功回滚该两阶段提交事务；或者

所述两阶段提交事务所针对的存储节点，成功提交该两阶段提交事务。

10.根据权利要求1所述方法，所述操作日志包括：数据库逻辑日志；所述两阶段提交事务包括：XA事务。

11.一种基于权利要求1至10任一项所述数据备份方法的数据恢复方法，包括：

针对存储节点，获取物理备份的存储数据，以及备份的第一位点到裁剪位点之间的操作日志，并基于所述存储数据和所获取的操作日志恢复该存储节点；

获取备份的可提交事务集合；

在该存储节点完成恢复的情况下，针对该存储节点中处于准备提交状态的两阶段提交事务，在该事务属于所述可提交事务集合的情况下，提交该事务，在该事务不属于所述可提交事务集合的情况下，回滚该事务。

12.一种数据备份方法，应用于数据库，所述数据库中包括至少两个存储节点；所述方法包括：

针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

在确定未完成事务集合中的两阶段提交事务完成的情况下，发起针对存储节点的心跳事务；所述未完成事务集合包括，在物理备份之后的第一时刻，所述数据库中未完成的两阶段提交事务；

在存储节点提交心跳事务成功的情况下，针对存储节点，将在第一时刻与心跳事务准备事件之间存在提交事件的两阶段提交事务，添加到当前可提交事务集合中；将心跳事务准备事件的结束位点确定为存储节点的当前裁剪位点；

循环更新当前可提交事务集合和存储节点的当前裁剪位点，确认存储节点在第一时刻与当前裁剪位点之间存在提交事件的两阶段提交事务，包含在当前可提交事务集合中；

其中，所述存储节点的当前裁剪位点包括，备选位点和心跳事务准备事件的结束位点之间最晚记录的位点；所述备选位点为，当前可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

循环结束后，备份当前可提交事务集合，以及存储节点中第一位点到当前裁剪位点之间的操作日志。

13.一种数据备份装置，应用于数据库，所述数据库中包括至少两个存储节点；所述装置包括：

物理备份单元，用于针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

构建单元，用于构建可提交事务集合，并确定存储节点的裁剪位点；

其中，所述可提交事务集合包括：在所述第一位点到所述裁剪位点之间，存在提交事件的两阶段提交事务；

所述存储节点的裁剪位点包括，所述可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

备份单元，用于备份所述可提交事务集合，以及存储节点中所述第一位点到所述裁剪位点之间的操作日志。

14.一种数据库系统，包括管控节点和至少两个存储节点；

管控节点用于：针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

构建可提交事务集合，并确定存储节点的裁剪位点；

其中，所述可提交事务集合包括：在所述第一位点到所述裁剪位点之间，存在提交事件的两阶段提交事务；

所述存储节点的裁剪位点包括，所述可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

备份所述可提交事务集合，以及存储节点中所述第一位点到所述裁剪位点之间的操作日志。

15.一种数据备份系统，包括管理设备和数据库系统；所述数据库系统包括至少两个存储节点；所述管理设备具有所述数据库系统的控制权限；

管理设备用于：针对存储节点中存储数据进行物理备份，并将该存储节点中物理备份的开始时刻所对应的操作日志位点确定为第一位点；

构建可提交事务集合，并确定存储节点的裁剪位点；

其中，所述可提交事务集合包括：在所述第一位点到所述裁剪位点之间，存在提交事件的两阶段提交事务；

所述存储节点的裁剪位点包括，所述可提交事务集合中针对该存储节点的两阶段提交事务之间，在该存储节点操作日志中最晚记录的准备事件结束位点；

备份所述可提交事务集合，以及存储节点中所述第一位点到所述裁剪位点之间的操作日志。

16.一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至12中任一项所述方法。

17.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1至12中任一项所述方法。

Images