CN106407356B - 一种数据备份方法及装置 - Google Patents

Abstract

本发明的实施方式提供了一种数据备份方法及装置。该方法包括：在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从所述从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；从所述主数据库中获取所述最终复制位置所在的目标二进制日志文件以及所述目标二进制日志文件之后的二进制日志文件。本发明的数据备份方法，在基于GTID模式的数据库中进行备份时，在减少备份数据量、减少备份数据占用的存储空间以及减少备份时间的同时，有效支持PIT恢复。此外，本发明的实施方式提供了一种数据备份装置。

Description

一种数据备份方法及装置

技术领域

本发明的实施方式涉及数据备份技术领域，更具体地，本发明的实施方式涉及一种数据备份方法及装置。

背景技术

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

MySQL是一个关系型数据库管理系统(Relational Database ManagementSystem，RDBMS)。MySQL是目前最流行的关系型数据库系统，在WEB应用方面MySQL是最好的RDBMS应用软件之一。

随着云计算在中国的普及，大多数云服务都是以开源数据库MySQL搭建的，而且用户在云服务器上搭建数据库大多数也是采用MySQL数据库。为了提高数据的稳定性，MySQL数据库中大多会对主数据库设置从数据库，其中，主数据库用于对用户提供服务，从数据库是主数据库的备份，通过复制功能，与主数据库的数据保持同步，从数据库用以在主数据库宕机以后，立即对用户提供服务，以实现服务的高可用。

现有MySQL数据库中基于二进制日志文件在主数据库和从数据库之间的复制，实现主数据库和从数据库之间的数据同步，具体来说，以一主一从的情况为例，如图1所示，主数据库102数据更改时，将更改操作记录在二进制日志Binary_log中，从数据库104与主数据库102进行数据同步时，请求获取Binary_log，主数据库102将Binary_log返回给从数据库104，从数据库104接收到主数据库102返回的Binary_log后，将Binary_log中的日志记录数据存储为重做日志Relay_log，并从Relay_log中解析出在主数据库102上执行的更改操作，并执行这些更改操作，也就是说，在主数据库102和从数据库104上执行同样的数据库操作，从而实现主数据库102与从数据库104的数据一致性。在数据同步时，Binary log与Relay log中的数据几乎一样，但是，二者之间对于同一更改操作记录的文件名称和偏移量并不相同，例如，一个更改操作在Binary log中的位置可能是mysql-bin.000001:568，其中，冒号前的mysql-bin.000001部分为文件名称，冒号后的568部分为文件的偏移量，而它在Relay log中的位置可能是relay-log.000002:124。

由于备份是一个耗时较长，代价较大的操作，为了避免备份对服务的影响，在关系型数据库服务(Relational Database Service，RDS)系统中，在备份时都是在从数据库上进行全量备份，也即全部复制从数据库中的数据进行备份。全量备份的优点是数据完整，恢复起来较快，缺点是数据量大，占用的存储空间大。RDS系统除了提供全量备份的功能以外，还提供增量备份的功能。增量备份有两种实现方式：(1)通过使用开源的备份工具，备份增量部分的物理数据；(2)拷贝主数据库上的Binary log，只备份增量部分的逻辑数据。

现在业界通用的增量备份方案是使用开源的备份工具(xtrabackup)，通过备份增量的物理数据来实现增量备份，这种增量备份可以在从数据库中进行增量备份，减少对业务的影响，但是，这种方案没有考虑到基于时间点(Point-in-Time，PIT)恢复的需求。而在RDS系统实现中，通过拷贝主数据库上的Binary log实现增量备份的方式，有一个显著的优点，能够有效支持PIT恢复，但是这种方式在从数据库上进行全量备份之后，从主数据库中上复制Binary log进行备份时，需要知道从Binary log的哪个位置开始复制，也就是说，在从数据库上进行全量备份之后，需要知道当前这个全量备份，与主数据库的Binary log的对应关系。换句话说，这种方式依赖于，备份工具在从数据库上进行全量备份时，能够确定出这个全量备份对应于主数据库的Binary log的位置，以便增量备份在主数据库上复制Binary log时，能够确定复制的起点。

从MySQL 5.6开始，业界逐渐开始使用基于全局事务标识(Global TransactionIdentifier，GTID)模式的故障恢复，希望摆脱对Binary log位置的依赖。如图2所示，在GTID模式下，就是对于每个事务，都有一个唯一的事务标识，例如：图2中示出的在数据头Header之后存储事务202、事务204、事务206以及事务208的事务数据时，同时存储每个事务的事务标识和事务数据，而此种模式下事务标识也会随着增量的逻辑数据，一起写到Binary log中。

在从数据库与主数据库进行数据同步时，主数据库中有一个GTID集合，从数据库中也有一个GTID集合，通过比对主数据库的GTID集合和从数据库的GTID集合，能够知道从数据库比主数据库缺少哪一部分事务数据。在基于GTID模式的从数据库上进行全量备份时，备份工具会给出当前全量备份包含的GTID集合，但是，并不会给出当前全量备份对应于主数据库中Binary log的位置。

在现有的基于GTID模式的数据库中，由于备份工具未给出全量备份与主数据库中Binary log的对应关系，也无法快速地通过给出的GTID集合，在主数据库的Binary log中找到该GTID集合对应的位置。因此，现有技术中基于GTID模式的数据库中，在每次备份时均需要复制从数据库中的全部数据进行备份，备份的数据量大，占用的存储空间大，而且不支持PIT恢复。

因此，目前亟需一种数据备份方法，以在基于GTID模式的数据库中进行备份时，在减少备份数据量、减少备份数据占用的存储空间以及减少备份时间的同时，有效支持PIT恢复。

发明内容

出于现有技术在基于GTID模式的数据库中，在每次备份时均需要复制从数据库中的全部数据进行备份，备份的数据量大，占用的存储空间大，而且不支持PIT恢复的问题。

为此，非常需要一种改进的数据备份方法，以在基于GTID模式的数据库中进行备份时，在减少备份数据量、减少备份数据占用的存储空间以及减少备份时间的同时，有效支持PIT恢复。

在本上下文中，本发明的实施方式期望提供一种数据备份方法及装置。

在本发明实施方式的第一方面中，提供了一种数据备份方法，包括：

在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从所述从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；

从所述主数据库中获取所述最终复制位置所在的目标二进制日志文件以及所述目标二进制日志文件之后的二进制日志文件。

在本发明实施方式的第二方面中，提供了一种数据备份装置，包括：

复制位置获取模块，用于在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从所述从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；

增量日志获取模块，用于从所述主数据库中获取所述最终复制位置所在的目标二进制日志文件以及所述目标二进制日志文件之后的二进制日志文件。

在本发明实施方式的第三方面中，提供了一种数据备份装置，例如，可以包括存储器和处理器，其中，处理器可以用于读取存储器中的程序，执行下列过程：

在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从所述从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；

从所述主数据库中获取所述最终复制位置所在的目标二进制日志文件以及所述目标二进制日志文件之后的二进制日志文件。

在本发明实施方式的第四方面中，提供了一种程序产品，其包括程序代码，当所述程序产品运行时，所述程序代码用于执行以下过程：

在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从所述从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；

从所述主数据库中获取所述最终复制位置所在的目标二进制日志文件以及所述目标二进制日志文件之后的二进制日志文件。

根据本发明实施方式的数据备份方法及装置，通过在基于GTID模式的数据库中对从数据库中的数据备份时，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置，从而能够从主数据库中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件进行备份，避免了每次备份时均需要复制从数据库中的全部数据进行备份的问题，从而减少了备份数据量、备份数据占用的存储空间以及备份时间，而且通过复制二进制日志进行备份的方法，能够有效支持PIT恢复。

附图说明

通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，其中：

图1示意性地示出了现有技术中主数据库与从数据库数据同步的原理示意图；

图2示意性地示出了现有技术中GTID模式数据库的数据结构示意图；

图3示意性地示出了根据本发明实施方式的应用场景示意图；

图4示意性地示出了根据本发明一实施例的一种数据备份方法的流程示意图；

图5示意性地示出了根据本发明一实施例的数据备份方法进行数据恢复的流程示意图；

图6示意性地示出了根据本发明另一实施例的一种数据备份装置的结构示意图；

图7示意性地示出了根据本发明又一实施例的数据备份装置的结构示意图；

图8示意性地示出了根据本发明再一实施例的用于数据备份方法的程序产品示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本发明的实施方式，提出了一种数据备份方法及装置。

在本文中，需要理解的是，所涉及的术语中：

1.全量备份：每一次备份，都是一个完整的备份，该备份包含了数据库中的所有数据。

2.增量备份：第一次备份是一个全量备份，之后只需要备份增量的那一部分数据，例如，在星期一进行了全量备份，在星期二备份的时候，只需要备份星期一到星期二这一天之间的增量数据。

3.PIT恢复：将数据恢复到过去的某一时刻，例如，现在已经是星期四，若发现星期二的12：00点到现在这段时间的数据出现了异常，则将数据恢复到星期二的12:00点。

此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

发明概述

本发明人发现，由于现有技术在基于GTID模式的从数据库上进行全量备份时，备份工具会给出当前全量备份包含的GTID集合，但备份工具未给出全量备份与主数据库中Binary log的对应关系，也无法快速地通过给出的GTID集合，在主数据库的Binary log中找到该GTID集合对应的位置。因此，在基于GTID模式的从数据库上进行备份时，每次均需要复制从数据库中的全部数据进行备份，备份的数据量大，占用的存储空间大，备份时间长，而且不支持PIT恢复。

为此，本发明提供了一种数据备份方法及装置，数据备份方法可以包括：在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；从主数据库中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件。

在介绍了本发明的基本原理之后，下面具体介绍本发明的各种非限制性实施方式。

应用场景总览

首先参考图3，如图3所示，为本发明实施例提供的数据备份方法的应用场景示意图，包括：主数据库302，从数据库304以及备份设备306，其中，主数据库302和从数据库304均是基于GTID模式的数据库，主数据库302用于对外提供服务，从数据库304是主数据库302的备份，通过复制主数据库302中的二进制日志文件与主数据库302进行数据同步，备份数据库304用于在主数据库302宕机时，对外提供服务，备份设备306用于对主数据库中的数据进行备份。

在备份时，为了不影响主数据库302对外提供服务，备份设备306先复制从数据库304中的数据进行备份，备份设备306在完成对从数据库304中的数据复制时，从从数据库304的复制进度信息中获取复制的从数据库304中的数据在主数据库302的二进制日志文件中的最终复制位置，备份设备306在获取最终复制位置之后，从主数据库302中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件完成数据备份。

其中，由于从数据库304通过复制主数据库302中的二进制日志文件与主数据库302进行数据同步，因此，该最终复制位置是指备份设备306从从数据库304中复制的全部数据在主数据库的二进制日志文件中对应的位置。备份设备306包括但不限于硬盘、光盘、U盘等存储设备。

示例性方法

下面结合图3的应用场景，参考图4～图5来描述根据本发明示例性实施方式的数据备份方法。需要注意的是，上述应用场景仅是为了便于理解本发明的精神和原理而示出，本发明的实施方式在此方面不受任何限制。相反，本发明的实施方式可以应用于适用的任何场景。

图4为本发明提供的一种数据备份方法的一实施例的流程示意图，主要包括数据备份的流程，执行主体可以为应用场景总览中的备份设备306或者与主数据库302、从数据库304以及备份设备306相连接的控制装置。如图4所示，本发明实施例提供的一种数据备份方法，包括如下步骤：

步骤401，在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置。

本步骤中，从数据库的复制进度信息，是指从数据库与主数据库之间数据同步的进度信息，也即从数据库复制主数据库的二进制日志的进度。在基于GTID模式的数据库中对从数据库中的数据备份时，在对从数据库中的数据复制完成之后，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置。

最终复制位置是指备份时从从数据库中复制的全部数据在主数据库的二进制日志文件中对应的位置。该最终复制位置，包括：二进制日志文件标识以及在二进制日志文件中的偏移位置。其中，二进制日志文件标识用于确定最终复制位置所在的二进制日志文件。

由于每个二进制日志文件中包括多条数据库的更改操作记录，最终复制位置可能并不是二进制日志文件的第一条更改操作记录，因此，还需要根据在二进制日志文件中的偏移位置确定最终复制位置所对应的更改操作记录。作为较为具体的实施例，例如：最终复制位置包括的二进制文件标识为012，在二进制日志文件中的偏移位置为10，则可以确定最终复制位置对应的是主数据库中标识为012的二进制日志文件的第10条更改操作记录。

具体实施时，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置，可以通过修改开源备份工具的方式，使得备份工具在备份时提供该最终复制位置。当然，还可以采用其它的方式获取，此处并不用于具体限定，例如：解析主数据库的二进制日志，通过字符串匹配的方式确定从数据库中的GTID集合在二进制日志中对应的最终复制位置。

步骤402，从主数据库中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件。

本步骤中，在获取最终复制位置之后，确定最终复制位置所在的目标二进制日志文件，并从主数据库中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件，完成数据备份。其中，最终复制位置所在的目标二进制日志文件是指最终复制位置包括的二进制日志文件标识所标识出的二进制日志文件。

本发明实施例，通过在基于GTID模式的数据库中对从数据库中的数据备份时，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置，从而能够从主数据库中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件进行备份，避免了每次备份时均需要复制从数据库中的全部数据进行备份的问题，从而减少了备份数据量、备份数据占用的存储空间以及备份时间，而且通过复制二进制日志进行备份的方法，能够有效支持PIT恢复。

优选地，为了保证获取到的最终复制位置的准确性，本发明实施例在基于GTID模式的数据库中从数据库中的数据备份时，从从数据库的复制进度信息中获取最终复制位置，包括：在基于GTID模式的数据库中完成对从数据库中数据的备份时，对从数据库中的数据进行加锁，从从数据库的复制进度信息中获取最终复制位置。

具体的，由于从数据库不断地与主数据库进行数据同步，从数据库中的数据是不断变化的，因此，为了防止在完成对从数据库中的数据备份到从从数据库的复制进度信息中获取最终复制位置之间的时间内，从数据库从主数据库复制数据进行数据同步，从而导致获取到的最终复制位置不准确，在完成对从数据库中数据的备份时，对从数据库的数据进行加锁，禁止从数据库复制主数据库中的数据进行数据同步，保证从数据库中数据与备份时复制的数据完全一致，进而从从数据库的复制进度信息中获取最终复制位置。当然，在获取最终复制位置之后，对从数据库进行解锁，以使从数据库与主数据库保持数据同步。

图5为本发明提供的一种数据备份方法进行数据恢复的流程示意图，在本发明提供的一种数据备份方法进行数据恢复的实施例中，主要包括在完成数据备份之后进行数据恢复的流程，执行主体可以为应用场景总览中的备份设备306或者与主数据库302、从数据库304以及备份设备306相连接的控制装置。如图5所示，本发明实施例提供的一种数据备份方法进行数据恢复时，包括如下步骤：

步骤501，在进行数据恢复时，向待恢复数据库发送备份时从从数据库中复制的数据以及备份时从主数据库中获取的二进制日志文件。

本步骤中，在完成数据备份之后，进行数据恢复时，也即接收到数据恢复请求时，响应于数据恢复请求向待恢复数据库发送备份时从从数据库中复制的数据以及备份时从主数据库中获取的二进制日志文件。

步骤502，控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作。

本步骤中，控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，以恢复备份的数据。较为优选地，在利用接收到的二进制日志文件对接收到的数据进行更改操作时，可以将二进制日志文件存储为重做日志，然后从重做日志中解析出更改操作，然后对接收到的数据进行更改操作。

优选地，若期望将数据恢复到某一时刻，则在进行数据恢复时，还需要获取预先配置的待恢复数据库数据恢复到的目标时刻，其中，目标时刻需要根据实际恢复需求预先配置，例如：目标时刻为9月1日12:00。

具体实施时，在获取预先配置的待恢复数据库数据恢复到的目标时刻之后，若期望将待恢复数据库恢复至与主数据库在目标时刻的数据相同，有以下两种实施方式，具体来说：

实施方式一、在获取预先配置的待恢复数据库数据恢复到的目标时刻之后，在向待恢复数据库发送备份时从从数据库中复制的数据以及备份时从主数据库中获取的二进制日志文件时，根据所述二进制日志文件中的时间标签，向所述待恢复数据库发送时间标签标识时刻在所述目标时刻之前的所有二进制日志文件，并控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作。

具体地，每个二进制日志文件中的时间标签中记录了该二进制日志文件中第一条更改操作记录的时刻以及最后一条更改操作记录的时刻，而且二进制日志文件中每条更改操作记录均有对应的更改时刻，因此，在获取预先配置的待恢复数据库数据恢复到的目标时刻之后，可以根据获取到的目标时刻以及二进制日志文件中的时间标签，从备份时从主数据库中获取的二进制日志文件中筛选出时间标签标识时刻在所述目标时刻之前的所有二进制日志文件，并将这部分二进制日志文件发送至待恢复数据库，避免了将所有二进制日志文件发送至待恢复数据库，减小了数据发送量，提高数据恢复速度。

值得说明的是，若目标时刻在某一二进制日志文件的时间标签所标识的起始时刻(第一条更改操作记录的时刻)或终止时刻(最后一条更改操作记录的时刻)之间，则根据该二进制日志文件中每条更改操作记录对应的更改时刻以及目标时刻，将该二进制日志文件拆分为两个子二进制日志文件，其中一个子二进制日志文件中包含更改操作记录对应的更改时刻在目标时刻之前的更改操作记录，另一个子二进制日志文件中包含更改操作记录对应的更改时刻在目标时刻之后的更改操作记录。

实施方式二、在获取预先配置的待恢复数据库数据恢复到的目标时刻，向待恢复数据库发送备份时从从数据库中复制的数据以及备份时从主数据库中获取的二进制日志文件之后，在控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作时，控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，将待恢复数据库中的数据恢复到目标时刻至与主数据库在目标时刻的数据相同。

具体的，控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，将待恢复数据库中的数据恢复到目标时刻至与主数据库在目标时刻的数据相同，包括：根据二进制日志文件中的时间标签，控制待恢复数据库利用时间标签标识时刻在目标时刻之前的所有二进制日志文件对接收到的数据进行更改操作；或者控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，在将待恢复数据库中的数据恢复到目标时刻之后的任一时刻之后，控制将待恢复数据库中的数据回滚至与主数据库在目标时刻的数据相同。

具体实施时，由于每个二进制日志文件中的时间标签中记录了该二进制日志文件中第一条更改操作记录的时刻以及最后一条更改操作记录的时刻，而且二进制日志文件中每条更改操作记录均有对应的更改时刻，因此，在控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作时，可以根据二进制日志文件中的时间标签以及二进制日志文件中每条更改操作记录对应的更改时刻，控制待恢复数据库利用时间标签标识时刻在目标时刻之前的所有更改操作记录对接收到的数据进行更改操作。

当然，具体实施时，在将待恢复数据库中的数据恢复到目标时刻时，也可以先将待恢复数据库中的数据恢复到目标时刻之后的任一时刻，然后控制将待恢复数据库中的数据回滚到目标时刻，也即控制将待恢复数据库中的数据回滚至与主数据库在目标时刻的数据相同。

示例性设备

在介绍了本发明示例性实施方式的方法之后，接下来，参考图6描述本发明示例性实施方式的数据备份装置。

图6为本发明实施例提供的一种数据备份装置的结构示意图之一，如图6所示，可以包括如下模块：

复制位置获取模块601，用于在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；

日志获取模块602，用于从主数据库中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件。

优选地，复制位置获取模块601，包括：

锁定单元6011，用于在基于GTID模式的数据库中完成对从数据库中数据的备份时，对从数据库中的数据进行加锁；

获取单元6012，用于从从数据库的复制进度信息中获取最终复制位置。

在本实施例的一些实施方式中，可选的，该数据备份装置还包括：

备份数据发送模块603，用于在进行数据恢复时，向待恢复数据库发送备份时从从数据库中复制的数据以及备份时从主数据库中获取的二进制日志文件；

数据恢复模块604，用于控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作。

在本实施例的一些实施方式中，可选的，该数据备份装置还包括：

恢复时刻获取模块605，用于获取预先配置的待恢复数据库数据恢复到的目标时刻。

在恢复时刻获取模块605获取预先配置的待恢复数据库数据恢复到的目标时刻之后，在将待恢复数据库的数据恢复至与主数据库在目标时刻的数据相同时，可以由备份数据发送模块603执行，也可以由数据恢复模块604执行，具体来说：

在本实施例的一些实施方式中，备份数据发送模块603向待恢复数据库发送从主数据库中获取的二进制日志文件，具体用于：根据二进制日志文件中的时间标签，向待恢复数据库发送时间标签标识时刻在目标时刻之前的所有二进制日志文件。

在本实施例的一些实施方式中，数据恢复模块604，具体用于：控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，将待恢复数据库中的数据恢复至与主数据库在目标时刻的数据相同。

数据恢复模块604控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，将待恢复数据库中的数据恢复至与主数据库在目标时刻的数据相同，具体用于：根据二进制日志文件中的时间标签，控制待恢复数据库利用时间标签标识时刻在目标时刻之前的所有二进制日志文件对接收到的数据进行更改操作；或者控制待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，在将待恢复数据库中的数据恢复到目标时刻之后的任一时刻之后，控制将待恢复数据库中的数据回滚至与主数据库在目标时刻的数据相同。

示例性设备

在介绍了本发明示例性实施方式的方法和装置之后，接下来，介绍根据本发明的又一示例性实施方式的数据备份装置。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，根据本发明的数据备份装置可以至少包括至少一个处理单元、以及至少一个存储单元。其中，所述存储单元存储有程序代码，当所述程序代码被所述处理单元执行时，使得所述处理单元执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的数据备份方法中的步骤。例如，所述处理单元可以执行如图4中所示的步骤401，在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置，步骤402，从主数据库中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件。

下面参照图7来描述根据本发明的这种实施方式的数据备份装置70。图7显示的数据备份装置70仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，数据备份装置70以通用计算设备的形式表现。数据备份装置70的组件可以包括但不限于：上述至少一个处理单元701、上述至少一个存储单元702、连接不同系统组件(包括处理单元701和存储单元702)的总线703。

总线703表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储单元702可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)7021和/或高速缓存存储器7022，还可以进一步包括只读存储器(ROM)7023。

存储单元702还可以包括具有一组(至少一个)程序模块7024的程序/实用工具7025，这样的程序模块7024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

数据备份装置70也可以与一个或多个外部设备704(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与数据备份装置70交互的设备通信，和/或与使得该数据备份装置70能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口705进行。并且，数据备份装置70还可以通过网络适配器706与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图7所示，网络适配器706通过总线703与数据备份装置70的其它模块通信。应当理解，尽管图中未示出，可以结合数据备份装置70使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

示例性程序产品

在一些可能的实施方式中，本发明提供的用于数据备份方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的数据备份方法中的步骤，例如，所述计算机设备可以执行如图4中所示的步骤401，在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置，步骤402，从主数据库中获取最终复制位置所在的目标二进制日志文件以及目标二进制日志文件之后的二进制日志文件。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

如图8所示，描述了根据本发明的实施方式的用于数据备份的程序产品80，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了数据备份装置的若干模块或子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (7)

1.一种数据备份方法，包括：

在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从所述从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；

从所述主数据库中获取所述最终复制位置所在的目标二进制日志文件以及所述目标二进制日志文件之后的二进制日志文件；

其中，所述方法进一步包括：

在进行数据恢复时，向待恢复数据库发送备份时从所述从数据库中复制的数据以及备份时从主数据库中获取的二进制日志文件；

控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作；

所述方法进一步包括：

获取预先配置的所述待恢复数据库数据恢复到的目标时刻；

则所述向待恢复数据库发送从主数据库中获取的二进制日志文件，包括：

根据所述二进制日志文件中的时间标签，向所述待恢复数据库发送时间标签标识时刻在所述目标时刻之前的所有二进制日志文件；

所述控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，包括：

控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，将待恢复数据库中的数据恢复至与所述主数据库在所述目标时刻的数据相同。

2.根据权利要求1所述的方法，其中，在基于GTID模式的数据库中对从数据库中的数据备份时，从所述从数据库的复制进度信息中获取所述最终复制位置，包括：

在基于GTID模式的数据库中完成对所述从数据库中数据的备份时，对所述从数据库中的数据进行加锁，从所述从数据库的复制进度信息中获取所述最终复制位置。

3.根据权利要求1所述的方法，其中，所述最终复制位置，包括：二进制日志文件标识以及在二进制日志文件中的偏移位置。

4.根据权利要求1所述的方法，其中，所述控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，将待恢复数据库中的数据恢复至与所述主数据库在所述目标时刻的数据相同，包括：

根据所述二进制日志文件中的时间标签，控制所述待恢复数据库利用时间标签标识时刻在所述目标时刻之前的所有二进制日志文件对接收到的数据进行更改操作；或者

控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，在将待恢复数据库中的数据恢复到所述目标时刻之后的任一时刻之后，控制将所述待恢复数据库中的数据回滚至与所述主数据库在所述目标时刻的数据相同。

5.一种数据备份装置，包括：

复制位置获取模块，用于在基于全局事务标识GTID模式的数据库中对从数据库中的数据备份时，从所述从数据库的复制进度信息中获取复制的从数据库中的数据在主数据库的二进制日志文件中的最终复制位置；

日志获取模块，用于从所述主数据库中获取所述最终复制位置所在的目标二进制日志文件以及所述目标二进制日志文件之后的二进制日志文件；

其中，所述装置进一步包括：

备份数据发送模块，用于在进行数据恢复时，向待恢复数据库发送备份时从所述从数据库中复制的数据以及备份时从主数据库中获取的二进制日志文件；

数据恢复模块，用于控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作；

恢复时刻获取模块，用于获取预先配置的所述待恢复数据库数据恢复到的目标时刻；

所述备份数据发送模块向所述待恢复数据库发送从主数据库中获取的二进制日志文件，具体用于：

根据所述二进制日志文件中的时间标签，向所述待恢复数据库发送时间标签标识时刻在所述目标时刻之前的所有二进制日志文件；

所述数据恢复模块，具体用于：

控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，将待恢复数据库中的数据恢复至与所述主数据库在所述目标时刻的数据相同。

6.根据权利要求5所述的装置，其中，所述复制位置获取模块，包括：

锁定单元，用于在基于GTID模式的数据库中完成对所述从数据库中数据的备份时，对所述从数据库中的数据进行加锁；

获取单元，用于从所述从数据库的复制进度信息中获取所述最终复制位置。

7.根据权利要求5所述的装置，其中，所述数据恢复模块控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，将待恢复数据库中的数据恢复至与所述主数据库在所述目标时刻的数据相同，具体用于：

根据所述二进制日志文件中的时间标签，控制所述待恢复数据库利用时间标签标识时刻在所述目标时刻之前的所有二进制日志文件对接收到的数据进行更改操作；或者

控制所述待恢复数据库利用接收到的二进制日志文件对接收到的数据进行更改操作，在将待恢复数据库中的数据恢复到所述目标时刻之后的任一时刻之后，控制将所述待恢复数据库中的数据回滚至与所述主数据库在所述目标时刻的数据相同。

Images