CN115408200A - 多存储引擎的数据备份方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明提供一种多存储引擎的数据备份方法、装置、电子设备及存储介质，包括：创建目标数据库的基准备份集；在任一存储引擎中启动数据增量捕捉获取增量数据；由增量数据与相关的元数据信息，构成增量文件；将增量文件与基准备份集关联，生成时间点备份集。本发明提供的数据备份方法及装置，仅需要在多个存储引擎中选择记录一个增量修改，并保存为独立于每个存储引擎的增量文件，同时添加事务ID等元数据信息，使得该增量文件中能够包含需要的数据和信息，以便能够对数据库系统中的多种存储引擎进行增量备份及恢复，有效地解决了目前多存储引擎备份存在的实现复杂度高、增量数据冗余的问题，实现了每个存储引擎均能完整支持增量备份和时间点恢复。

Description

多存储引擎的数据备份方法、装置、电子设备及存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种多存储引擎的数据备份方法、装置、电子设备及存储介质。

背景技术

对于数据库系统来说，数据的可靠性是至关重要的，尤其是关键业务的数据，是一个企业的宝贵财富，甚至是赖以生存发展的根本。数据如果丢失可能对企业造成不可挽回的经济损失，尤其对于一些关乎民生的行业，如金融、电信等，数据丢失还会导致严重的社会问题。因此，数据的备份和恢复作为保障数据可靠性和安全性的最后屏障显得尤为重要。

数据除了由于系统故障，如硬件故障，或软件上的缺陷的造成丢失数据或数据错误外，也有可能由于人为的误操作，例如非法入侵或内部人员的恶意篡改等原因造成数据的丢失和错误。这时就需要能够将数据库恢复到最近的正确的时间点的数据；这种能将数据库的数据恢复到给定时间点的方法就是基于时间基准点的数据恢复技术。

目前，基于时间点的恢复技术通常都是由数据库的存储引擎来处理，通过保存存储引擎的修改日志，通过日志回放的方式或者日志回滚的方式来实现基于时间基准点的数据恢复。

但由于不同的存储引擎使用的修改日志格式是不相同的，故导致日志的回放或回滚方式也存在较大的差异，因此会造成数据迁移难度大、数据冗余较多，数据备份及恢复的整体复杂性和总体运维成本高等缺陷。

发明内容

针对现有技术存在的问题，本发明实施例提供一种多存储引擎的数据备份方法、装置、电子设备及存储介质。

本发明提供一种多存储引擎的数据备份方法，包括：创建目标数据库的基准备份集；在任一存储引擎中启动数据增量捕捉，以获取增量数据；由所述增量数据与所述增量数据文件相关的元数据信息，构成增量文件；将所述增量文件与所述基准备份集关联，生成时间点备份集。

根据本发明提供的一种多存储引擎的数据备份方法，所述创建数据库的基准备份集，包括：在各个存储引擎中创建快照文件集，并将由所有快照文件集构成的快照文件簇作为所述基准备份集。

根据本发明提供的一种多存储引擎的数据备份方法，所述元数据信息包括：事务身份标识号和时间戳。

根据本发明提供的一种多存储引擎的数据备份方法，所述增量文件的格式为所述目标数据库中所有存储引擎的通用存储格式。

根据本发明提供的一种多存储引擎的数据备份方法，在所述目标数据库中所有存储引擎均为Key Value类型的情况下，确定所述增量文件的格式为：确定所述增量文件由增量变化数据和元数据构成；所述增量变化数据包括增量修改的操作类型、增量修改的类型和增量修改的数据；所述元数据包括所述元数据信息。

根据本发明提供的一种多存储引擎的数据备份方法，还包括：接收数据恢复指令，对所述目标数据库中的备份数据进行恢复；读取所述数据恢复指令相关的设定时间，以确定与所述设定时间距离最近的基准备份集；根据所述基准备份集确定与之关联的增量文件；根据所述增量文件中的增量记录和所述设定时间确定待恢复的增量数据，以创建每个存储引擎的时间点恢复集；根据每个存储引擎的所述时间点恢复集，将所述目标数据库中的每个存储引擎的数据恢复到所述设定时间时的数据。

根据本发明提供的一种多存储引擎的数据备份方法，所述创建每个存储引擎的时间点恢复集，包括：获取所述基准备份集对应的快照文件簇中每个存储引擎的快照文件集；将每个所述快照文件集与所述增量数据关联，生成每个存储引擎的时间点恢复集。

本发明还提供一种多存储引擎的数据备份装置，包括：基准备份集生成单元，用于创建目标数据库的基准备份集；增量数据采集单元单元，用于在任一存储引擎中启动数据增量捕捉，以获取增量数据；备份集生成单元，用于将所述增量文件与所述基准备份集关联，生成时间点备份集。

本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述多存储引擎的数据备份方法的步骤。

本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述多存储引擎的数据备份方法的步骤。

本发明提供的多存储引擎的数据备份方法、装置、电子设备及存储介质，仅需要在多个存储引擎中选择记录一个增量修改，并保存为独立于每个存储引擎的增量文件，同时添加事务ID等元数据信息，使得该增量文件中能够包含需要的数据和信息，以便能够对数据库系统中的多种存储引擎进行增量备份及恢复，有效地解决了目前多存储引擎备份存在的实现复杂度高、增量数据冗余的问题，实现了每个存储引擎均能完整支持增量备份和时间点恢复。

附图说明

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

图1是本发明提供的多存储引擎的数据备份方法的流程示意图之一；

图2是本发明提供的多存储引擎的数据备份方法的流程示意图之二；

图3是本发明提供的增量文件的格式示意图；

图4是本发明提供的HBase WAL日志的格式示意图；

图5是本发明提供的多存储引擎的数据恢复方法的流程示意图；

图6是本发明提供的多存储引擎的数据备份与基于时间点恢复的整体示意图；

图7是本发明提供的多存储引擎的数据备份装置的结构示意图；

图8是本发明提供的电子设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在本发明实施例的描述中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。术语“上”、“下”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

数据库系统的主要应用场景可以分为两种：一种是联机事务处理型(On-LineTransaction Processing，OLTP)，另一种是联机分析处理型(Online AnalyticalProcessing，OLAP)。通常这两种使用场景使用不同的数据库来处理，其主要原因是针对这两种使用方式需要使用不同的存储格式，也就需要使用不同的存储引擎来处理。

对于OLTP场景，通常是数据录入和更新，使用基于行的存储格式和存储引擎可以提高数据插入语句和更新语句的速度，但是基于行的存储格式对于复杂的查询分析语句的处理比较低效。

对于OLAP场景，通常是对数据中某些列做统计和分析，使用基于行的存储格式会读取大量不需要的列的数据，并且存储引擎不能预先对每列的数据做预先的处理，从而导致处理性能非常低，而使用基于列的存储格式，就可以非常高效的按照每列的数据进行操作，从而可以显著的提升查询分析语句的处理性能。

使用不同的数据库处理这两类应用场景就需要在这两种数据库之间进行数据迁移。除了增加整个系统的复杂性、运维成本等因素外，数据迁移还导致了数据的冗余。且由于迁移数据是有延迟的，也就无法保证分析类场景数据的实时性。随着数据量的不断增大，以及分析类场景对实时性要求的提高，使用不同的数据库处理这两种业务场景的方式就无法满足业务的要求，因此分布式融合型数据库系统(Hybrid Transaction AnalyticalProcessing，HTAP)就成为目前数据库未来的发展方向。HTAP就是使用一个数据库系统来同时处理OLTP型和OLAP型这两种业务场景；从而达到无需进行数据迁移，消除数据冗余，实现实时分析业务，降低整体复杂性和总体运维成本的目的。

目前，实现HTAP主要有两种方式，第一种实现方式是使用折中的存储格式来同时处理OLTP型和OLAP型业务场景。这种折中的存储格式通常是介于行式存储和列式存储之间，能够在行式存储和列式存储种取得一种平衡，能同时支持OLTP型和OLAP型的业务场景。但是由于采用了折中的存储方案，因此这样的数据库存储引擎在两种场景上性能都不能达到最优，并不能达到分别使用两种不同数据库所能提供的性能。

另一种实现方式是使用不同的存储格式和存储引擎来分别处理OLTP型和OLAP型的业务。由于HTAP中的每份数据都存在多个副本(通常是三个)，因此就可以在这些副本中选择一部分(比如两个副本)使用行式存储来处理OLTP型业务，另一部分(一个副本)采用列式存储来处理OLAP型业务。这种实现方式可以分别为OLTP型和OLAP型业务提供最好的性能。

目前使用多个存储引擎分别处理OLTP型和OLAP型业务的HTAP普遍采用的备份和恢复方式，都是基于每个存储引擎自身的机制来实现的。由于使用了多种存储引擎以及对应的多种存储格式，增加了系统备份的实现和维护的复杂性，主要表现在：

每种存储引擎都有自己独有的备份方式以及备份的保存格式，加之有些存储引擎可能不支持增量捕捉，也可能使用不同的增量数据的保存格式，或者不能支持增量备份数据的事务一致性的处理，这些问题极大的增加了多存储引擎增量备份和基于时间点恢复在实现上的复杂性，同时由于每个存储引擎和数据格式都使用独立的修改记录文件，对存储空间的使用上也会有成倍的增长。而且如果选用的多个存储引擎中有一个不支持增量捕捉或者时间点恢复，就会导致整个数据库不能支持增量捕捉和时间点恢复。

为有效解决这一问题，本发明提供的多存储引擎的数据备份方法、装置、电子设备及存储介质，尤其能够支持多存储引擎的HTAP的增量备份和基于时间点恢复。

下面结合图1-图8描述本发明实施例所提供的多存储引擎的数据备份方法和装置。

图1是本发明提供的多存储引擎的数据备份方法的流程示意图之一，如图1所示，包括但不限于以下步骤：

步骤101：创建目标数据库的基准备份集。

在目标数据库所在的数据库系统中的各个存储引擎中分别创建相应的快照文件集，以组成快照文件簇。其中，每个快照文件集构成一个包含所有存储引擎的快照文件簇的一部分。

将每个存储引擎创建快照的时间作为目标数据库基于时间点备份以及恢复的一个基准时间点。关联的快照文件簇则为目标数据库基于时间点备份以及恢复的基准备份集。

其中，基准备份集也可以理解为，是某个时间点所有存储引擎的全量备份，对应每个存储引擎在这个时间的全部快照文件。

步骤102：在任一存储引擎中启动数据增量捕捉，以获取增量数据。

在完成目标数据库的基准备份集的创建后，在其中一个存储引擎中启动数据增量捕捉，并将获取的增量数据。

步骤103：由所述增量数据与所述增量数据文件相关的元数据信息，构成增量文件。

具体地，在步骤103的基础上，以一种与存储引擎无关的格式存储至某一增量文件中，并在该增量文件中添加数据增量捕捉相关的事务ID、时间戳以及与之关联的基准备份集信息等元数据信息。

步骤104：将所述增量文件与所述基准备份集关联，生成时间点备份集。

将步骤103中获取的与存储引擎无关的增量文件和与之关联的基准备份集，共同构成一个时间基准点备份集。

进一步地，可以迭代执行上述步骤102至步骤104，以将每个存储引擎的时间基准点备份集，共同组成一个时间基准点备份簇，以通过各存储引擎实现对各个时间基准点所产生的增量数据的备份。

在需要执行基于时间基准点的数据恢复工作时，还可以根据全部存储引擎相关的时间基准点备份簇，可将数据库的全部存储引擎数据恢复到选定时间点。

因此，时间点备份集可以理解为，包含一个基准备份集和之后的增量数据的集合，可以用以将数据库的数据恢复到任一给定的时间点。

本发明提供的多存储引擎的数据备份方法，仅需要在多个存储引擎中选择记录一个增量修改，并保存为独立于每个存储引擎的增量文件，同时添加事务ID等元数据信息，使得该增量文件中能够包含需要的数据和信息，以便能够对数据库系统中的多种存储引擎进行增量备份及恢复，有效地解决了目前多存储引擎备份存在的实现复杂度高、增量数据冗余的问题，实现了每个存储引擎均能完整支持增量备份和时间点恢复。

本发明提供的多存储引擎的数据备份方法，仅需要在多个存储引擎中选择记录一个增量修改，并保存为独立于每个存储引擎的增量文件，同时添加事务ID等元数据信息，使得该增量文件中能够包含需要的数据和信息，以便能够对数据库系统中的多种存储引擎进行增量备份及恢复，有效地解决了目前多存储引擎备份存在的实现复杂度高、增量数据冗余的问题，实现了每个存储引擎均能完整支持增量备份和时间点恢复。

基于上述实施例的内容，作为一种可选实施例，步骤101所述的创建数据库的基准备份集，包括：在各个存储引擎中创建快照文件集，并将由所有快照文件集构成的快照文件簇作为所述基准备份集。

其中，所述元数据信息可以包括：事务身份标识号(Identity document，ID)、时间戳、关联基准备份集信息。

图2是本发明提供的多存储引擎的数据备份方法的流程示意图之二，如图2所示，作为另一实施例，整个备份流程包括但不限于以下步骤：

步骤1，创建目标数据库的基准备份集，为所有存储引擎生成快照文件簇：

假设目标数据库仅存在两个存储引擎(存储引擎1和存储引擎2)，分别为每个存储引擎创建快照文件，并由所有快照文件构成一个快照文件簇作为基准备份集。

步骤2，创建存储引擎无关增量文件，记录数据库中主存储引擎的增量数据，并存储为存储引擎无关的增量文件格式：

利用存储引擎启动数据增量捕捉，获取当前时刻的增量数据，并由增量数据创建一个与存储引擎无关的增量文件。

步骤3，添加增量数据相关的元数据信息：

将上述增量数据相关的事务ID、时间戳和基准备份集信息均对应的添加到这一增量文件中。

其中，所述事务ID是指目标数据库的事务ID，用于标识目标数据库系统中运行的每个事务的全局唯一编号，可以使用特定于目标数据库的SQL查询，从目标数据库中获取该事务ID。

所述时间戳(timestamp)是创建备份时的系统时间(可以理解为创建快照的时间)，通常用一个整数表示从某个特定时间(如Unix Timestamp以1970年1月1日零点为起点)开始的秒数或微秒数(根据需求可以选择精度)，全量备份(基准备份集)和增量备份(时间点备份集)都需要用到和保存相应的时间戳。本发明提供的多存储引擎的数据备份方法，在实现基于时间点恢复时，也是需要使用时间戳来指定时间。

所述关联基准备份集信息，主要包括基准备份集的快照文件信息和基准备份集的时间戳信息，能够为步骤104中，将增量文件与基准备份集关联提供关联依据。

步骤4，创建时间点备份集：

将基准备份集和步骤3中获取的增量文件关联，形成时间点备份集。

最后，重复迭代执行上述步骤1至步骤4，则可以生成下一阶段的基准点备份集(在每一次迭代中，可以在不同的存储引擎中启动数据增量捕捉)。

其中，在每次迭代时，增量文件只在一个存储引擎上捕捉，但是由于是采用与存储引擎无关的格式保存的，因此可以应用于所有的存储引擎。所有的存储引擎都可以使用各自的基准备份集和与存储引擎无关的增量文件来构成一个时间点备份集。这些所有存储引擎的时间点备份集共同构成时间基准点备份簇。

需要说明的是，快照文件是用来做全量备份的，也就是基准备份。对于分布式数据库来说，每个存储引擎都包含多个存储节点，每个节点至少包含一个存储文件，因此每个存储引擎的全部快照文件构成快照文件集，全部存储引擎的快照文件就构成快照文件簇。一个基准备份集就包含一个存储引擎的快照文件集。

增量文件产生于增量备份，只在某个存储引擎上生成，所有增量文件构成增量备份集。但是由于是采用与存储引擎无关的格式保持的，故可以用于所有存储引擎恢复数据。

时间点备份集是一个存储引擎的基准备份集加上增量备份集构成的；所有存储引擎的时间点备份集则构成时间基准点备份簇。

本发明提供的多存储引擎的数据备份方法，在完成基准备份集的创建后，在其中一个存储引擎中启动数据增量捕捉，并将增量数据存储至与存储引擎无关的增量文件中，同时在该增量文件中添加事务ID、时间戳以及关联基准备份集信息等元数据信息。

然后，将增量文件与关联的基准备份集构成一个时间基准点备份集。

迭代执行上述方法，获取到各个存储引擎的时间基准点备份集，然后由所有时间基准点备份集构成与全部存储引擎无关的时间基准点备份簇。

本发明提供的多存储引擎的数据备份方法，使用与存储引擎无关的增量文件，来记录、保存多个存储引擎的增量数据，从而达到降低多存储引擎分布式数据库系统中实现增量备份的复杂性，消除多存储引擎增量备份数据的冗余。

基于上述实施例的内容，作为一种可选实施例，所述增量文件的格式为所述目标数据库中所有存储引擎的通用存储格式。

在实际运用中，与存储引擎无关的增量文件的格式可以是不是固定的，即并不需要采用一种对任何存储引擎都通用的存储格式来保存增量文件。

不同存储引擎之间的差异可能非常大，比如基于B-Tree的存储引擎和基于KeyValue的存储引擎之间就会存在很大的差别。虽然理论上可以设计出一种完全通用的格式，但是可能会带来比较大的转换工作和性能损耗。因此，只需针对目标数据库所在的数据库系统(以下统称：目标数据库系统)中所需要支持的多个存储引擎，设计出一种通用的增量格式即可。例如，在目标数据库系统的存储引擎均为Key Value类型的，则仅需要设计一种通用的Key Value类型的增量记录格式的增量文件，而并不需要考虑是否适用于B-Tree类型或者其它存储引擎类型。

作为一种可选实施例，在目标数据库中所有存储引擎均为Key Value类型的情况下，确定所述增量文件的格式为：确定所述增量文件由增量变化数据和元数据构成；所述增量变化数据包括增量修改的操作类型、增量修改的类型和增量修改的数据；所述元数据包括所述元数据信息。

图3是本发明提供的增量文件的格式示意图，如图3所示，本发明针对Key Value类型的存储引擎设计一种通用的格式：

每个增量文件主要包含两个部分：增量变化数据(Mutation)和元数据(Meta)。

Mutation中主要记录了增量修改的操作类型(如：PUT/DELETE)，增量修改的对象(RowKey)和增量修改的数据(RowValue)。

Meta中主要保存修改对应的事务ID(Transaction ID)和时间戳(Timestamp)等信息。

作为一种可选实施例，下面以HBase这个最常见的Key Value存储引擎为例，说明如何将存储引擎自身的修改日志转换成通用的增量文件格式。

在此之前，先简要介绍一下HBase的修改日志格式(WAL)：

WAL日志也叫写前日志或预写日志，在HBase做任何修改操作之前都需要首先写WAL日志，记录相应的操作类型和操作的数据。WAL日志的主要作用是用于故障恢复，当HBase的节点或者Region发生故障时，可以利用WAL日志恢复未提交完成的修改操作。由于WAL文件中记录了每次的修改操作，因此WAL日志也可以用来做HBase的增量备份。

HBase是一个Key Value存储引擎，数据都是使用Key Value格式存储。图4是本发明提供的HBase WAL日志的格式示意图，如图4所示，HBase的WAL日志文件也采用的是KeyValue格式：

HBase的WAL日志文件中每个修改记录的Key是HLogKey，Value是KeyValue，HLogKey中记录了这个修改对应的Region、表名(TableName)，修改序列(Sequence Number)和写入时间等信息；KeyValue则记录了修改的数据，包含修改类型(KeyType)，修改的行(Row)、列簇(Column Family)、时间戳和值等信息。

WAL日志中有些信息可以直接对应到通用格式，比如timestamp，value(对应RowValue)；有些信息需要做一些转换，比如KeyType转换为Operation，TableName会转换为TableID，使用TableID可以减少存储空间的占用，Row，Column Family和Qualifier等转换为RowID；Region和Sequence Number则不再需要；同时添加Transaction ID等信息即可完成从WAL日志到通用格式的转换。

在本发明提供的多存储引擎的数据备份方法中，通用的与存储引擎无关的增量文件的格式可以根据目标数据库系统中实际使用的多个存储引擎类型进行适应性的选择，可同时保证增量文件的通用性并有效地提高了数据备份的性能。

图5是本发明提供的多存储引擎的数据恢复方法的流程示意图，如图5所示，本发明提供的多存储引擎的数据备份方法，还包括：接收数据恢复指令，对所述目标数据库中的备份数据进行恢复；读取所述数据恢复指令相关的设定时间，以确定与所述设定时间距离最近的基准备份集；根据所述基准备份集确定与之关联的增量文件；根据所述增量文件中的增量记录和所述设定时间确定待恢复的增量数据，以创建每个存储引擎的时间点恢复集；根据每个存储引擎的所述时间点恢复集，将所述目标数据库中的每个存储引擎的数据恢复到所述设定时间时的数据。

作为一种可选实施例，在采用上述实施例中所述的数据备份完成了对目标数据库中增量数据的备份工作之后，若接收数据恢复指令，则对目标数据库中的备份数据进行恢复。

其中，数据恢复指令可以是由用户发出的，也可以是目标数据库系统在检测到当前数据存在错误，需要将目标数据库中所存储的数据恢复至最近的一次正确的状态后，由服务器自动生成的。

在接收到这一数据恢复指令之后，开始执行对目标数据库中的备份数据进行恢复的流程，包括但不限于以下步骤：

步骤1，选择基准备份集，一般来说是根据数据恢复指中包含的设定时间，以选择与该设定时间之前距离最近的基准备份集。

步骤2，根据所选择的基准备份集，查找与之关联的增量文件。

步骤3，在确定了增量文件的基础上，选择与存储引擎无关的增量数据，包括：

根据增量文件中记录的增量数据和选定的时间确定恢复所需的增量记录集。

步骤4，创建每个存储引擎的时间点恢复集。

步骤5，基于时间点恢复每个存储引擎中的数据，包括：

根据每个存储引擎的时间点恢复集，将数据库的每个存储引擎的数据恢复到选定时间点。

基于上述实施例的内容，作为一种可选地实施例，所述创建每个存储引擎的时间点恢复集，包括：获取所述基准备份集对应的快照文件簇中每个存储引擎的快照文件集；将每个所述快照文件集与所述增量数据关联，生成每个存储引擎的时间点恢复集。

具体地，将基准备份集中的快照文件簇中的每个存储引擎的快照文件集，与存储引擎无关的增量记录集相关联，形成每个存储引擎的时间点恢复集。

图6是本发明提供的多存储引擎的数据备份与基于时间点恢复的整体示意图，如图6所示，作为一种可选实施例，本发明提供的多存储引擎的数据备份方法，在完成基准备份集的创建后，在其中一个存储引擎中启动数据增量捕捉，并将所述增量数据存储至一种与存储引擎无关的增量文件中，并在增量文件中添加事务ID、时间戳以及关联基准备份集数据等元数据信息。

增量文件与关联的基准备份集构成一个时间基准点备份集，所有存储引擎的时间基准点备份集构成时间基准点备份簇。

根据全部存储引擎无关的时间基准点备份簇，可将数据库的全部存储引擎数据恢复到选定时间点。

将存储引擎无关的增量文件与基准备份集关联，形成时间基准点备份集。

然后，根据时间基准点备份集，将数据库的数据恢复到选定的时间点，具体步骤包括：

使用各个存储引擎的基准备份集，将数据库的数据恢复到基准时间点；根据基准时间点选择关联的时间点备份集；再根据选定的时间点选择增量备份文件集；在各个存储引擎中回放所述存储引擎无关的增量文件中的增量数据；其中，增量数据为增量文件中从基准时间点至选定时间点的时间范围以内产生的增量数据。

需要说明的是，图6中的全量备份也就是在步骤101中所获取的基准备份集中的每个基准备份，每个基准备份的创建时间和后面的增量数据的最大备份时间(也就是下一个基准数据备份前的最后一个增量数据的备份时间)构成一个时间区间，这个区间就是这个时间基准点备份集能够恢复数据的时间点区间。执行时间点恢复时会根据用户提供的时间点计算该时间所在的区间来选择用于恢复数据的时间点备份集。

本发明提供的多存储引擎的数据备份方法，仅需要在多个存储引擎中选择记录一个增量修改，并保存为独立于每个存储引擎的增量文件，同时添加事务ID等元数据信息，使得该增量文件中能够包含需要的数据和信息，以便能够对数据库系统中的多种存储引擎进行增量备份及恢复，有效地解决了目前多存储引擎备份存在的实现复杂度高、增量数据冗余的问题，实现了每个存储引擎均能完整支持增量备份和时间点恢复。

图7是本发明提供的多存储引擎的数据备份装置的结构示意图，如图7所示，主要包括基准备份集生成单元71、增量数据采集单元单元72和备份集生成单元73，其中：

基准备份集生成单元71主要用于创建目标数据库的基准备份集；增量数据采集单元单元72主要用于在任一存储引擎中启动数据增量捕捉，以获取增量数据；备份集生成单元73主要用于将所述增量文件与所述基准备份集关联，生成时间点备份集。

需要说明的是，本发明实施例提供的多存储引擎的数据备份装置，在具体执行时，可以基于上述任一实施例所述的多存储引擎的数据备份方法来实现，对此本实施例不作赘述。

本发明提供的多存储引擎的数据备份装置，仅需要在多个存储引擎中选择记录一个增量修改，并保存为独立于每个存储引擎的增量文件，同时添加事务ID等元数据信息，使得该增量文件中能够包含需要的数据和信息，以便能够对数据库系统中的多种存储引擎进行增量备份及恢复，有效地解决了目前多存储引擎备份存在的实现复杂度高、增量数据冗余的问题，实现了每个存储引擎均能完整支持增量备份和时间点恢复。

图8是本发明提供的电子设备的结构示意图，如图8所示，该电子设备可以包括：处理器(processor)810、通信接口(Communications Interface)820、存储器(memory)830和通信总线840，其中，处理器810，通信接口820，存储器830通过通信总线840完成相互间的通信。处理器810可以调用存储器830中的逻辑指令，以执行多存储引擎的数据备份方法，该方法包括：创建目标数据库的基准备份集；在任一存储引擎中启动数据增量捕捉获取增量数据；由增量数据与相关的元数据信息，构成增量文件；将增量文件与基准备份集关联，生成时间点备份集。

此外，上述的存储器830中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法所提供的多存储引擎的数据备份方法，该方法包括：创建目标数据库的基准备份集；在任一存储引擎中启动数据增量捕捉获取增量数据；由增量数据与相关的元数据信息，构成增量文件；将增量文件与基准备份集关联，生成时间点备份集。

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各实施例提供的多存储引擎的数据备份方法，该方法包括：创建目标数据库的基准备份集；在任一存储引擎中启动数据增量捕捉获取增量数据；由增量数据与相关的元数据信息，构成增量文件；将增量文件与基准备份集关联，生成时间点备份集。

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

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

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

Claims (10)

1.一种多存储引擎的数据备份方法，其特征在于，包括：

创建目标数据库的基准备份集；

在任一存储引擎中启动数据增量捕捉，以获取增量数据；

由所述增量数据与所述增量数据文件相关的元数据信息，构成增量文件；

将所述增量文件与所述基准备份集关联，生成时间点备份集。

2.根据权利要求1所述的多存储引擎的数据备份方法，其特征在于，所述创建数据库的基准备份集，包括：

在各个存储引擎中创建快照文件集，并将由所有快照文件集构成的快照文件簇作为所述基准备份集。

3.根据权利要求1所述的多存储引擎的数据备份方法，其特征在于，所述元数据信息包括：事务身份标识号、时间戳、关联基准备份集信息。

4.根据权利要求3所述的多存储引擎的数据备份方法，其特征在于，所述增量文件的格式为所述目标数据库中所有存储引擎的通用存储格式。

5.根据权利要求4所述的多存储引擎的数据备份方法，其特征在于，在所述目标数据库中所有存储引擎均为Key Value类型的情况下，确定所述增量文件的格式为：

确定所述增量文件由增量变化数据和元数据构成；

所述增量变化数据包括增量修改的操作类型、增量修改的类型和增量修改的数据；所述元数据包括所述元数据信息。

6.根据权利要求1所述的多存储引擎的数据备份方法，其特征在于，还包括：接收数据恢复指令，对所述目标数据库中的备份数据进行恢复；

读取所述数据恢复指令相关的设定时间，以确定与所述设定时间距离最近的基准备份集；

根据所述基准备份集确定与之关联的增量文件；

根据所述增量文件中的增量记录和所述设定时间确定待恢复的增量数据，以创建每个存储引擎的时间点恢复集；

根据每个存储引擎的所述时间点恢复集，将所述目标数据库中的每个存储引擎的数据恢复到所述设定时间时的数据。

7.根据权利要求6所述的多存储引擎的数据备份方法，其特征在于，所述创建每个存储引擎的时间点恢复集，包括：

获取所述基准备份集对应的快照文件簇中每个存储引擎的快照文件集；

将每个所述快照文件集与所述增量数据关联，生成每个存储引擎的时间点恢复集。

8.一种多存储引擎的数据备份装置，其特征在于，包括：

基准备份集生成单元，用于创建目标数据库的基准备份集；

增量数据采集单元单元，用于在任一存储引擎中启动数据增量捕捉，以获取增量数据；

备份集生成单元，用于将所述增量文件与所述基准备份集关联，生成时间点备份集。

9.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述多存储引擎的数据备份方法步骤。

10.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述多存储引擎的数据备份方法步骤。

Images