CN110209735B - 数据库备份方法、数据库备份装置、计算设备和存储介质 - Google Patents

Abstract

本发明涉及数据库备份方法、数据库备份装置、计算设备和计算机可读存储介质。数据库备份方法包括：从备份起始时刻开始，将更新日志从源数据库同步到备份存储位置，其中所述源数据库中的数据被组织为表，并且所述更新日志记录所述备份起始时刻之后对所述源数据库执行的更新操作；将所述源数据库的各个表单独地备份到所述备份存储位置；并且在所述各个表的备份完成之后，终止所述更新日志到所述备份存储位置的同步，其中所述更新日志中对应于所述同步的终止时刻的位点作为备份一致性位点。在备份过程中，无需对数据库加全局读锁，从而降低或消除对于数据库的正常使用的影响。

Description

数据库备份方法、数据库备份装置、计算设备和存储介质

技术领域

本发明涉及数据库备份技术，具体来说涉及一种数据库备份方法、数据库备份装置、计算设备和存储介质。

背景技术

数据库是以数据为中心的应用的重要组件，可以存储和处理大量数据。备份对于保证数据的可靠性至关重要。当数据库宕机或数据错乱时，可以通过恢复备份的方式还原数据。以MySQL数据库为例，典型的备份方案包括：（1）逻辑备份，其中通过标准SQL语句获得数据库的备份；以及（2）物理备份，其中通过物理拷贝文件的方式，获得数据库的备份。

逻辑备份需要对正在提供服务的数据库加全局读锁。由于加锁期间数据库不能执行所有的数据操作，所以数据库的可用性受到很大影响。物理备份同样需要对数据库加全局读锁，但加锁时间比逻辑加锁备份短。由于物理拷贝涉及直接从文件系统读取数据，未经过数据库的逻辑校验，因此可能出现备份数据不可用的情况。

发明内容

有利的是，提供一种可以缓解、减轻或甚至消除上述问题中的一个或多个的机制。

根据本发明的一方面，提供了一种数据库备份方法，包括：从备份起始时刻开始，将更新日志从源数据库同步到备份存储位置，其中所述源数据库中的数据被组织为表，并且所述更新日志记录所述备份起始时刻之后对所述源数据库执行的更新操作；将所述源数据库的各个表单独地备份到所述备份存储位置；并且在所述各个表的备份完成之后，终止所述更新日志到所述备份存储位置的同步，其中所述更新日志中对应于所述同步的终止时刻的位点作为备份一致性位点。

在一些实施例中，所述各个表包括支持回滚操作的至少一个第一类型表和不支持回滚操作的至少一个第二类型表，并且所述更新操作包括用于更新表结构的第一类型操作和用于更新表内容的第二类型操作。

在一些实施例中，单独地备份所述源数据库的各个表包括：对所述各个表中的每一个表分别执行元数据检查以确定所述每一个表为所述第一类型表还是所述第二类型表；并且将所述每一个表从所述源数据库复制到所述备份存储位置。

在一些实施例中，单独地备份所述源数据库的各个表还包括：响应于所述元数据检查表明所述每一个表为第一类型表，实时地解析所述更新日志；并且响应于所述解析表明在针对该第一类型表的临界时间段期间发生了所述第一类型操作，直接返回执行元数据检查以重新备份该第一类型表。所述临界时间段是不允许对该第一类型表执行所述第一类型操作的时间段。所述临界时间段开始于对该第一类型表执行所述元数据检查的时间段内的一时刻，并且结束于将该第一类型表复制到所述备份存储位置的时间段内的一时刻。

在一些实施例中，单独地备份所述源数据库的各个表还包括：响应于所述元数据检查表明所述每一个表为第一类型表，在将所述每一个表从所述源数据库复制到所述备份存储位置之后解析所述更新日志；并且响应于所述解析表明在针对该第一类型表的临界时间段期间发生了所述第一类型操作，返回执行元数据检查以重新备份该第一类型表。所述临界时间段是不允许对该第一类型表执行所述第一类型操作的时间段。所述临界时间段开始于对该第一类型表执行所述元数据检查的时间段内的一时刻，并且结束于将该第一类型表复制到所述备份存储位置的时间段内的一时刻。

在一些实施例中，单独地备份所述源数据库的各个表还包括：响应于所述元数据检查表明所述每一个表为第二类型表，对该第二类型表加读锁，使得在将该第二类型表复制到所述备份存储位置的时间段期间发生的所述第一类型操作和所述第二类型操作等待，直到该第二类型表的复制完成。

在一些实施例中，所述方法还包括：将已备份至所述备份存储位置的各个表导入目标数据库；以及对所述目标数据库回放已同步至所述备份存储位置的更新日志，使得由所述更新操作产生的增量数据被合并到已导入所述目标数据库的所述各个表中的相应表。

在一些实施例中，所述方法还包括：将已备份至所述备份存储位置的各个表导入目标数据库；并且对所述目标数据库回放已同步至所述备份存储位置的更新日志，使得由所述更新操作产生的增量数据被合并到已导入所述目标数据库的所述各个表中的相应表。对所述目标数据库回放所述更新日志包括：使用保证数据幂等性的改写规则，对于每个第一类型表执行所述更新日志中记录的且在针对所述每个第一类型表的所述临界时间段期间发生的所述第二类型操作。

在一些实施例中，所述第二类型操作包括插入操作、修改操作、删除操作和替换操作。所述改写规则包括：将原始插入操作改写为替换操作；将原始修改操作改写为删除操作加插入操作；并且将原始删除操作保持为删除操作。

在一些实施例中，对所述目标数据库回放所述更新日志还包括：忽略所述更新日志中记录的且在所述备份起始时刻与针对所述每个第一类型表的所述临界时间段的开始时刻之间发生的所述第一类型操作和所述第二类型操作；并且直接执行所述更新日志中记录的且在针对所述每个第一类型表的所述临界时间段的结束时刻与所述同步的终止时刻之间发生的所述第一类型操作和所述第二类型操作，而不使用所述改写规则。

在一些实施例中，所述源数据库包括MySQL，所述第一类型表包括事务表，所述第二类型表包括非事务表，所述第一类型操作包括数据定义语言操作，并且所述第二类型操作包括数据操纵语言操作。

在一些实施例中，单独地备份所述源数据库的各个表包括：利用多线程并发地备份所述各个表。

根据本发明的另一方面，提供了一种数据库备份装置，包括：日志同步模块，被配置成从备份起始时刻开始，将更新日志从源数据库同步到备份存储位置，其中所述源数据库中的数据被组织为表，并且所述更新日志记录所述备份起始时刻之后对所述源数据库执行的更新操作；以及表备份模块，被配置成将所述源数据库的各个表单独地备份到所述备份存储位置。所述日志同步模块还被配置成在所述各个表的备份完成之后，终止所述更新日志到所述备份存储位置的同步，其中所述更新日志中对应于所述同步的终止时刻的位点作为备份一致性位点。

根据本发明的另一方面，提供了一种计算设备，包括存储器和处理器，所述存储器被配置成在其上存储计算机程序指令，所述计算机程序指令当在所述处理器上执行时促使所述处理器执行如上所述的方法中的任一个。

根据本发明的另一方面，提供了一种计算机可读存储介质，其上存储计算机程序指令，所述计算机程序指令当在处理器上执行时促使所述处理器执行如上所述的方法中的任一个。

在各实施例中，通过对数据库中的表单独地备份，数据库的整实例备份被分割成各个表的备份。与需要对数据库加全局读锁的逻辑备份和物理备份相比，这种“分治”的方式使得在备份过程中无需对数据库加全局读锁，从而降低或消除对于数据库的正常使用的影响。在进一步的实施例中，在恢复数据库时，可以通过回放更新日志得到增量数据，从而实现数据库的一致性快照。

附图说明

在下面结合附图对于示例性实施例的描述中，本发明的更多细节、特征和优点被公开，在附图中：

图1示出了根据本发明实施例的数据库备份方法的流程图；

图2示出了图1的方法中用于备份单个表的流程图；

图3示出了在备份MySQL数据库的实施例中备份事务表的示意性时序图；

图4示出了在备份MySQL数据库的实施例中备份非事务表的示意性时序图；

图5示出了在图1的方法中恢复数据库的步骤的流程图；

图6示出了在恢复MySQL数据库的实施例中回放更新日志的示意性时序图；

图7示出了其中可以应用根据本发明实施例的技术的应用场景；

图8示出了根据本发明实施例的数据库备份装置的示意性框图；并且

图9示出了代表可以实现本文描述的各种技术的一个或多个系统和/或设备的示例计算设备。

具体实施方式

下面结合附图详细描述本发明的实施例。

图1示出了根据本发明实施例的数据库备份方法100的流程图。

在步骤110处，从备份起始时刻开始，将更新日志从源数据库同步到备份存储位置。

备份存储位置可以位于源数据库的本地或者位于源数据库的远程处。

源数据库典型地为其中数据被组织为表的关系型数据库。在关系型数据库中，数据按层级进行组织，所述层级由高到低一般包括：数据库、表、记录、和字段。关系型数据库的示例包括但不限于MySQL。

更新日志中记录了所述备份起始时刻之后对所述源数据库执行的更新操作，并且因此可以体现备份起始时刻之后产生的增量数据。术语“增量数据”是相对于全量数据而言的，全量数据是指在备份起始时刻已经存在于源数据库中的数据。将理解的是，在数据库技术的语境中，更新操作不限于修改操作，而是可以包括例如创建、增加（插入）、删除等等对数据的结构或内容做出了更改的任何操作。在MySQL数据库的示例中，更新日志的功能可以由binlog提供。binlog是一个二进制格式的文件，其用于记录用户对MySQL数据库的更新操作。例如，更改数据表结构和更改表内容的SQL语句都会记录到binlog中，但是对库表等内容的查询不会被记录。

在一些实施例中，源数据库中的各个表包括支持回滚（rollback）操作的至少一个第一类型表和不支持回滚操作的至少一个第二类型表。回滚指的是当数据处理错误时，将数据恢复到上一次正确状态的行为。另外，所述更新操作包括用于更新表结构的第一类型操作和用于更新表内容的第二类型操作。

在MySQL数据库的示例中，所述第一类型表包括事务表，所述第二类型表包括非事务表，所述第一类型操作包括数据定义语言（DDL）操作，并且所述第二类型操作包括数据操纵语言（DML）操作。数据定义语言主要用于定义或改变表的结构，包括例如创建（Create）、更改（Alter）、丢弃（Drop）等。数据操纵语言用来对表的内容进行操作，包括例如选择（Select）、修改（Update）、插入（Insert）和删除（Delete）。

在步骤120处，将源数据库的各个表单独地备份到所述备份存储位置。

此处，所谓“单独地备份”是指在每个表（而非整个数据库）的基础上执行备份。这样，数据库的整实例备份被分割成各个表的备份。这种“分而治之”的方式使得在备份过程中无需对数据库加全局读锁，从而降低或消除对于数据库的正常使用的影响。

将理解的是，虽然步骤110和120被顺序地描述和示出，但是这只是说明性的。在实践中，更新日志的同步和各个表的备份可以并发地执行。

图2示出了步骤120中用于备份单个表的流程图。

参考图2，对该表执行元数据检查以确定该表为第一类型表还是第二类型表（步骤121和122）。在MySQL数据库的示例中，元数据检查可以被执行来获取关于表的结构的信息，以便用于确定该表是事务表还是非事务表。该获取的信息还可以用于例如执行数据校验或确保表具有主键或唯一索引，从而确保备份数据的可用性。

无论该表是第一类型表还是第二类型表，它都将在元数据检查之后从源数据库被复制到备份存储位置（步骤126）。然而，第一和第二类型表将被不同地处理。

对于每个第一类型表，存在这样的一个时间段（本文中称为“临界（critical）时间段”），在该时间段期间不允许对该第一类型表执行所述第一类型操作。临界时间段覆盖元数据检查操作与表复制操作之间的过渡点。具体地，临界时间段开始于对该第一类型表执行所述元数据检查的时间段内的一时刻，并且结束于将该第一类型表复制到所述备份存储位置的时间段内的一时刻。这样的临界时间段是数据库内在要求的，用于避免破坏数据的一致性。

图3示出了备份MySQL数据库中的事务表的示意性时序图。

虽然图3示出了仅一个事务表的备份过程，但是其他事务表的备份可以被并发地执行。下面参考图3更详细地描述第一类型表（在MySQL数据库的示例中为事务表）的备份过程。

在该示例中，更新日志（即，binlog）的同步从T0时刻持续至T9时刻，元数据检查从T1时刻持续至T3时刻，并且该事务表的复制从T3时刻持续至T8时刻。特别地，MySQL数据库规定，在T2时刻至T4时刻的时间段（“临界时间段”）期间，不允许对该事务表执行DDL操作，因为DDL操作本身是一种事务，能够破坏事务表的一致性。例如，在T3时刻至T4时刻期间正在复制事务表的表结构，如果在此时间段期间执行DDL操作，则将破坏该事务表的表结构。

在T2时刻之前或在T4时刻之后执行的DDL操作不会破坏事务的一致性，并且因此被允许。另外，DML操作只涉及对表内容的操纵，并且因此在从T0时刻至T9时刻的整个时间段内被允许。这些DDL操作和DML操作被记录到binlog中。

对于在T2时刻至T4时刻的临界时间段期间发生的DDL操作，可以采取一些措施来确保备份的一致性。

返回参考图2，在一些实施例中，如果所述元数据检查表明该表为第一类型表（步骤121和122），则实时地解析所述更新日志（步骤123）。如果所述解析表明在针对该第一类型表的临界时间段（例如，图3中从T2时刻至T4时刻）期间发生了所述第一类型操作，则处理流程直接返回执行元数据检查以重新备份该第一类型表，而不等待表的复制完成。

可替换地，在一些实施例中，如果所述元数据检查表明该表为第一类型表（步骤121和122），则在将该表从所述源数据库复制（步骤126）到所述备份存储位置之后再解析所述更新日志（步骤123），如图2中的带箭头的虚线和/>所指示的。也即，更新日志的解析不是实时进行的。然后，如果所述解析表明在针对该第一类型表的临界时间段（例如，图3中从T2时刻至T4时刻）期间发生了所述第一类型操作，则处理流程返回执行元数据检查以重新备份该第一类型表。如果所述解析表明在针对该第一类型表的临界时间段（例如，图3中从T2时刻至T4时刻）期间没有发生所述第一类型操作，则处理流程结束，如图2中的带箭头的虚线/>所指示的。

将理解的是，虽然图2示出了仅单个表的备份过程，但是其他表的备份可以利用多线程被并发地执行。这有助于减少数据库备份所需的时间，从而进一步降低备份过程对于数据库的使用的影响。

对于每个第二类型表，由于不需要考虑数据回滚，所以在更新日志的整个同步期间内，第一类型操作和第二类型操作都被允许。

图4示出了备份MySQL数据库中的非事务表的示意性时序图。

虽然图4示出了仅一个非事务表的备份过程，但是其他非事务表的备份可以被并发地执行。下面参考图4更详细地描述第二类型表（在MySQL数据库的示例中为非事务表）的备份过程。

在该示例中，更新日志（即，binlog）的同步从T0时刻持续至T7时刻（对应于图3中的T9时刻），元数据检查从T1时刻持续至T2时刻，并且该非事务表的复制从T2时刻持续至T6时刻。如图4所示，DDL操作和DML操作在T0时刻至T7时刻的整个时间段内都被允许，只不过在复制非事务表的时间段（T2时刻至T6时刻）期间，DDL操作和DML操作必须等待复制完成才能被执行。这同样是为了确保数据一致性。

为此目的，返回参考图2，如果所述元数据检查表明该表为第二类型表（步骤121和122），则对该第二类型表加读锁（步骤125），使得在将该第二类型表复制到所述备份存储位置的时间段（例如，图4中T2时刻至T6时刻）期间发生的所述第一类型操作和所述第二类型操作等待，直到该第二类型表的复制完成。与对整个数据库加全局读锁的方案不同，此处读锁是单独地加到各个第二类型表，因此减小了对于整个数据库的访问的影响。另外，每个第二类型表被加读锁的时间段相对较短，不会持续整个备份过程。

返回参考图1，在步骤130处，在源数据库中的各个表的备份完成之后，终止所述更新日志到所述备份存储位置的同步。

在上面结合图3和4描述的MySQL数据库的示例中，binlog的同步的终止时刻为图3中的T9时刻，或等价地图4中的T7时刻。在图3中，不同的事务表都具有相应的复制结束时刻T8，但是binlog的同步的终止时刻T9将晚于各相应的T8时刻中最晚的那个时刻。在一些实施例中，T9时刻甚至可以与最晚的那个T时刻重叠。在图4中，不同的非事务表都具有相应的复制结束时刻T6，但是binlog的同步的终止时刻T7一般地将晚于各相应的T6时刻中最晚的那个时刻。这为在T2时刻与T6时刻之间发生且等待表复制结束的DDL操作和DML操作提供了执行时间。

更新日志中对应于所述同步的终止时刻的位点（position）可以作为备份一致性位点。即，在同步的终止时刻，备份存储位置处的备份数据与源数据库中的数据是一致的。这样，通过执行步骤110至130，在备份起始时刻已经存在于源数据库中的全量数据和在备份过程中产生的增量数据被备份到备份存储位置，得到源数据库的一致性快照。

当源数据库被损坏时，这些备份数据可以从该备份存储位置被恢复到目标数据库。目标数据库可以被创建为具有与源数据库相同的名称以便完全替换源数据库，或者它可以被创建为具有新的名称以用作新的数据库。

图5示出了在方法100中恢复数据库的步骤140的流程图。

参考图5，在步骤141处，将已备份至所述备份存储位置的各个表导入目标数据库。在步骤142处，对所述目标数据库回放已同步至所述备份存储位置的更新日志。

回放更新日志涉及重新执行备份过程中记录的更新操作。通过执行这些更新操作，由所述更新操作产生的增量数据被合并到已导入所述目标数据库的所述各个表中的相应表，产生源数据库的一致性快照。

图6示出了在恢复MySQL数据库时回放（apply）更新日志binlog的示意性时序图。

由于回放binlog涉及重新执行备份过程中记录的DDL操作和DML操作，因此有可能备份过程中已经被更新的数据被再次更新，从而产生错误的结果。这对于事务表而言尤为如此，因为在备份过程中的临界时间段（T2时刻至T4时刻，参见图3）期间，DML操作是被允许的。因此，为了确保数据幂等性，对于每个事务表，需要对binlog中记录的且在针对该事务表的临界时间段期间发生的DML操作进行改写。改写规则如表1所示。

表1

原始操作	新的操作
		插入（Insert）	替换（Replace into）
修改（Update）	删除加插入（Delete&Insert）
		删除（Delete）	删除（Delete）

“Replace into”具有与 “Insert”类似的功能，不同点在于，如果表中的一个旧记录与一个用于主键或一个唯一索引的新记录具有相同的值，则“Replace into”在插入新记录之前先删除此旧记录，否则，它直接插入新记录。“Update”被改写为“Delete&Insert”，使得表中已有的旧记录在回放binlog的过程中不会被再次修改。“Delete”保持为“Delete”而不被改写。这样，目标数据库中的最终数据被确保为以binlog为准，确保了数据一致性。

在一些实施例中，在回放binlog的过程中，在备份起始时刻T0与临界时间段的开始时刻T2之间发生的DDL操作和DML操作可以被忽略。这是因为在这一时间间隔中，事务表还未被复制，并且发生在该时间间隔中的任何操作的结果都将反映在随后被复制的事务表中。

在一些实施例中，在回放binlog的过程中，在临界时间段的结束时刻T4与binlog的同步的终止时刻T9之间发生的DDL操作和DML操作被直接执行，而不使用所述改写规则。这是因为发生在这一时间间隔中的任何操作不会破坏事务表的一致性，使得改写规则不再必要。

图7一般地在700处示出了其中可以应用根据本发明实施例的技术的应用场景。

参考图7，源数据库710被备份至备份盘720。在一些场景中，源数据库710可以是云数据库（CDB），例如腾讯云云数据库。因此，根据本发明实施例的技术可以用作云数据库的一种备份手段。附加地或替换地，根据本发明实施例的技术可以用作云数据库备份服务的默认备份方式，供用户在控制台选择使用。用户可以将自己的数据库实例进行完整备份而不影响线上业务访问。在一些场景中，源数据库710还可以是位于客户端本地的数据库。因此，根据本发明实施例的技术可以用作本地数据库的一种备份手段。

备份盘720可以位于源数据库710的本地，例如位于与源数据库710不同的磁盘分区中。可替换地，备份盘720可以是位于源数据库710的远程处的一个或多个存储介质。可替换地，备份盘720还可以是分布式存储系统，其包括位于不同物理位置处的多个存储介质。

当需要时，备份盘720中的备份数据被导入目标数据库730以恢复源数据库。如前所述，目标数据库730可以被创建为具有与源数据库720相同的名称以便完全替换源数据库720，或者它可以被创建为具有新的名称以用作新的数据库。

图8示出了根据本发明实施例的数据库备份装置800的示意性框图。

参考图8，数据库备份装置800包括日志同步模块810、表备份模块820和数据库恢复模块830。

日志同步模块810被配置成从备份起始时刻开始，将更新日志从源数据库同步到备份存储位置。所述源数据库中的数据被组织为表，并且所述更新日志记录所述备份起始时刻之后对所述源数据库执行的更新操作。日志同步模块810的操作已经在上面关于结合图1至6例示说明的方法实施例进行了详细描述，并且为了简洁起见在此不再重复。

表备份模块820被配置成将所述源数据库的各个表单独地备份到所述备份存储位置。表备份模块820的操作已经在上面关于结合图1至6例示说明的方法实施例进行了详细描述，并且为了简洁起见在此不再重复。

日志同步模块810还被配置成在所述各个表的备份完成之后，终止所述更新日志到所述备份存储位置的同步。所述更新日志中对应于所述同步的终止时刻的位点作为备份一致性位点。

数据库恢复模块830被配置成：将已备份至所述备份存储位置的各个表导入目标数据库；以及对所述目标数据库回放已同步至所述备份存储位置的更新日志，使得由所述更新操作产生的增量数据被合并到已导入所述目标数据库的所述各个表中的相应表。数据库恢复模块830的操作已经在上面关于结合图1至6例示说明的方法实施例进行了详细描述，并且为了简洁起见在此不再重复。

将理解的是，日志同步模块810、表备份模块820和数据库恢复模块830可以由软件、固件、硬件或其组合来实现，如后面还将进一步描述的。

图9示出了一个示例系统900，其包括代表可以实现本文描述的各种技术的一个或多个系统和/或设备的示例计算设备910。

计算设备910可以是例如服务提供商的服务器、与客户端（例如，客户端设备）相关联的设备、片上系统、和/或任何其它合适的计算设备或计算系统。上面关于图8描述的数据库备份装置800可以采取计算设备910的形式。

如图示的示例计算设备910包括彼此通信耦合的处理系统911、一个或多个计算机可读介质912以及一个或多个I / O接口913。尽管未示出，但是计算设备910还可以包括系统总线或其他数据和命令传送系统，其将各种组件彼此耦合。系统总线可以包括不同总线结构的任何一个或组合，所述总线结构诸如存储器总线或存储器控制器、外围总线、通用串行总线、和/或利用各种总线架构中的任何一种的处理器或局部总线。还构思了各种其他示例，诸如控制和数据线。

处理系统911代表使用硬件执行一个或多个操作的功能。因此，处理系统911被图示为包括可被配置为处理器、功能块等的硬件元件914。这可以包括在硬件中实现作为专用集成电路或使用一个或多个半导体形成的其它逻辑器件。硬件元件914不受其形成的材料或其中采用的处理机构的限制。例如，处理器可以由（多个）半导体和/或晶体管（例如，电子集成电路（IC））组成。在这样的上下文中，处理器可执行指令可以是电子可执行指令。

计算机可读介质912被图示为包括存储器/存储装置915。存储器/存储装置915表示与一个或多个计算机可读介质相关联的存储器/存储容量。存储器/存储装置915可以包括易失性介质（诸如随机存取存储器（RAM））和/或非易失性介质（诸如只读存储器（ROM）、闪存、光盘、磁盘等）。存储器/存储装置915可以包括固定介质（例如，RAM、ROM、固定硬盘驱动器等）以及可移动介质（例如，闪存、可移动硬盘驱动器、光盘等）。计算机可读介质912可以以下面进一步描述的各种其他方式进行配置。

一个或多个输入/输出接口913代表允许用户向计算设备910键入命令和信息并且还允许使用各种输入/输出设备将信息呈现给用户和/或其他组件或设备的功能。输入设备的示例包括键盘、光标控制设备（例如，鼠标）、麦克风（例如，用于语音输入）、扫描仪、触摸功能（例如，被配置为检测物理触摸的容性或其他传感器）、相机（例如，可以采用可见或不可见的波长（诸如红外频率）将不涉及触摸的运动检测为手势）等等。输出设备的示例包括显示设备（例如，显示器或投影仪）、扬声器、打印机、网卡、触觉响应设备等。

计算设备910还包括数据库备份服务916。数据库备份服务916可以作为计算程序指令存储在存储器/存储装置915中。数据库备份服务916可以连同处理系统911、计算机可读介质912和I/O接口913一起实现关于图8描述的数据库备份装置800的各个模块的全部功能。

本文可以在软件硬件元件或程序模块的一般上下文中描述各种技术。一般地，这些模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、元素、组件、数据结构等。本文所使用的术语“模块”，“功能”和“组件”一般表示软件、固件、硬件或其组合。本文描述的技术的特征是与平台无关的，意味着这些技术可以在具有各种处理器的各种计算平台上实现。

所描述的模块和技术的实现可以存储在某种形式的计算机可读介质上或者跨某种形式的计算机可读介质传输。计算机可读介质可以包括可由计算设备910访问的各种介质。作为示例而非限制，计算机可读介质可以包括“计算机可读存储介质”和“计算机可读信号介质”。

与单纯的信号传输、载波或信号本身相反，“计算机可读存储介质”是指能够持久存储信息的介质和/或设备，和/或有形的存储装置。因此，计算机可读存储介质是指非信号承载介质。计算机可读存储介质包括诸如易失性和非易失性、可移动和不可移动介质和/或以适用于存储信息（诸如计算机可读指令、数据结构、程序模块、逻辑元件/电路或其他数据）的方法或技术实现的存储设备之类的硬件。计算机可读存储介质的示例可以包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字通用盘（DVD）或其他光学存储装置、硬盘、盒式磁带、磁带，磁盘存储装置或其他磁存储设备，或其他存储设备、有形介质或适于存储期望信息并可以由计算机访问的制品。

“计算机可读信号介质”是指被配置为诸如经由网络将指令发送到计算设备910的硬件的信号承载介质。信号介质典型地可以将计算机可读指令、数据结构、程序模块或其他数据体现在诸如载波、数据信号或其它传输机制的调制数据信号中。信号介质还包括任何信息传递介质。术语“调制数据信号”是指以这样的方式对信号中的信息进行编码来设置或改变其特征中的一个或多个的信号。作为示例而非限制，通信介质包括诸如有线网络或直接连线的有线介质以及诸如声、RF、红外和其它无线介质的无线介质。

如前所述，硬件元件914和计算机可读介质912代表以硬件形式实现的指令、模块、可编程器件逻辑和/或固定器件逻辑，其在一些实施例中可以用于实现本文描述的技术的至少一些方面。硬件元件可以包括集成电路或片上系统、专用集成电路（ASIC）、现场可编程门阵列（FPGA）、复杂可编程逻辑器件（CPLD）以及硅中的其它实现或其他硬件设备的组件。在这种上下文中，硬件元件可以作为执行由硬件元件所体现的指令、模块和/或逻辑所定义的程序任务的处理设备，以及用于存储用于执行的指令的硬件设备，例如，先前描述的计算机可读存储介质。

前述的组合也可以用于实现本文所述的各种技术和模块。因此，可以将软件、硬件或程序模块和其它程序模块实现为在某种形式的计算机可读存储介质上和/或由一个或多个硬件元件914体现的一个或多个指令和/或逻辑。计算设备910可以被配置为实现与软件和/或硬件模块相对应的特定指令和/或功能。因此，例如通过使用处理系统的计算机可读存储介质和/或硬件元件914，可以至少部分地以硬件来实现将模块实现为可由计算设备910作为软件执行的模块。指令和/或功能可以由一个或多个制品（例如，一个或多个计算设备910和/或处理系统911）可执行/可操作以实现本文所述的技术、模块和示例。

在各种实施方式中，计算设备910可以采用各种不同的配置。这些配置中的每一个包括可以具有一般不同的构造和能力的设备，并且因此可以根据不同设备类别中的一个或多个配置计算设备910。例如，计算设备910可以被实现为包括个人计算机、台式计算机、多屏幕计算机、膝上型计算机、上网本等的计算机类设备。计算设备910还可以被实现为包括诸如移动电话、便携式音乐播放器、便携式游戏设备、平板计算机、多屏幕计算机等移动设备的移动装置类设备。计算设备910还可以实现为电视类设备，包括电视、机顶盒、游戏机等。

本文描述的技术可以由计算设备910的这些各种配置来支持，并且不限于本文所描述的技术的具体示例。计算设备910可以与云数据库所位于的“云”920交互。云920包括和/或代表用于资源932的平台930。平台930抽象云920的硬件（例如，服务器）和软件资源的底层功能。资源932可以包括在远离计算设备910的服务器上执行计算机处理时可以使用的应用和/或数据。资源932还可以包括通过因特网和/或通过诸如蜂窝或Wi-Fi网络的订户网络提供的服务。

虽然各个操作在附图中被描绘为按照特定的顺序，但是这不应理解为要求这些操作必须以所示的特定顺序或者按顺行次序执行，也不应理解为要求必须执行所有示出的操作以获得期望的结果。在特定情况下，多任务和并行处理可能是有利的。此外，前面描述的实施例中不同系统部件的划分不应理解为所有实施例都要求这种划分，并且应当理解，所描述的程序部件和系统通常可以集成在单个软件产品中，或者打包到多个软件产品中。

通过研究附图、公开内容和所附的权利要求书，本领域技术人员在实践所要求保护的主题时，能够理解和实现对于所公开的实施例的变型。在权利要求书中，词语“包括”不排除其他元件或步骤，不定冠词“一”或“一个”不排除多个，并且“多个”意指两个或更多。在相互不同的从属权利要求中记载了某些措施的仅有事实并不表明这些措施的组合不能用来获利。

Claims (13)

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

从备份起始时刻开始，将更新日志从源数据库同步到备份存储位置，其中所述源数据库中的数据被组织为表，并且所述更新日志记录所述备份起始时刻之后对所述源数据库执行的更新操作；

将所述源数据库的各个表单独地备份到所述备份存储位置；并且

在所述各个表的备份完成之后，终止所述更新日志到所述备份存储位置的同步，其中所述更新日志中对应于所述同步的终止时刻的位点作为备份一致性位点；

其中所述各个表包括支持回滚操作的至少一个第一类型表和不支持回滚操作的至少一个第二类型表，并且其中所述更新操作包括用于更新表结构的第一类型操作和用于更新表内容的第二类型操作；

其中单独地备份所述源数据库的各个表包括：

对所述各个表中的每一个表分别执行元数据检查以确定所述每一个表为所述第一类型表还是所述第二类型表；并且

将所述每一个表从所述源数据库复制到所述备份存储位置；

其中单独地备份所述源数据库的各个表还包括：

响应于所述元数据检查表明所述每一个表为第一类型表，并且通过对所述更新日志的解析表明在针对该第一类型表的临界时间段期间发生了所述第一类型操作，直接返回执行元数据检查以重新备份该第一类型表，

其中所述临界时间段是不允许对该第一类型表执行所述第一类型操作的时间段，并且

其中所述临界时间段开始于对该第一类型表执行所述元数据检查的时间段内的一时刻，并且结束于将该第一类型表复制到所述备份存储位置的时间段内的一时刻。

2.如权利要求1所述的方法，其中单独地备份所述源数据库的各个表还包括：

响应于所述元数据检查表明所述每一个表为第一类型表，实时地解析所述更新日志。

3.如权利要求1所述的方法，其中单独地备份所述源数据库的各个表还包括：

响应于所述元数据检查表明所述每一个表为第一类型表，在将所述每一个表从所述源数据库复制到所述备份存储位置之后解析所述更新日志。

4.如权利要求1所述的方法，其中单独地备份所述源数据库的各个表还包括：

响应于所述元数据检查表明所述每一个表为第二类型表，对该第二类型表加读锁，使得在将该第二类型表复制到所述备份存储位置的时间段期间发生的所述第一类型操作和所述第二类型操作等待，直到该第二类型表的复制完成。

5.如权利要求1至4中任一项所述的方法，还包括：

将已备份至所述备份存储位置的各个表导入目标数据库；以及

对所述目标数据库回放已同步至所述备份存储位置的更新日志，使得由所述更新操作产生的增量数据被合并到已导入所述目标数据库的所述各个表中的相应表。

6.如权利要求2或3所述的方法，还包括：

将已备份至所述备份存储位置的各个表导入目标数据库；并且

对所述目标数据库回放已同步至所述备份存储位置的更新日志，使得由所述更新操作产生的增量数据被合并到已导入所述目标数据库的所述各个表中的相应表，

其中对所述目标数据库回放所述更新日志包括：

使用保证数据幂等性的改写规则，对于每个第一类型表执行所述更新日志中记录的且在针对所述每个第一类型表的所述临界时间段期间发生的所述第二类型操作。

7.如权利要求6所述的方法，其中所述第二类型操作包括插入操作、修改操作、删除操作和替换操作，并且其中所述改写规则包括：

将原始插入操作改写为替换操作；

将原始修改操作改写为删除操作加插入操作；并且

将原始删除操作保持为删除操作。

8.如权利要求6所述的方法，其中对所述目标数据库回放所述更新日志还包括：

忽略所述更新日志中记录的且在所述备份起始时刻与针对所述每个第一类型表的所述临界时间段的开始时刻之间发生的所述第一类型操作和所述第二类型操作；并且

直接执行所述更新日志中记录的且在针对所述每个第一类型表的所述临界时间段的结束时刻与所述同步的终止时刻之间发生的所述第一类型操作和所述第二类型操作，而不使用所述改写规则。

9.如权利要求1所述的方法，其中单独地备份所述源数据库的各个表包括：利用多线程并发地备份所述各个表。

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

日志同步模块，被配置成从备份起始时刻开始，将更新日志从源数据库同步到备份存储位置，其中所述源数据库中的数据被组织为表，并且所述更新日志记录所述备份起始时刻之后对所述源数据库执行的更新操作；以及

表备份模块，被配置成将所述源数据库的各个表单独地备份到所述备份存储位置，

其中所述日志同步模块还被配置成在所述各个表的备份完成之后，终止所述更新日志到所述备份存储位置的同步，其中所述更新日志中对应于所述同步的终止时刻的位点作为备份一致性位点；

其中所述各个表包括支持回滚操作的至少一个第一类型表和不支持回滚操作的至少一个第二类型表，并且其中所述更新操作包括用于更新表结构的第一类型操作和用于更新表内容的第二类型操作；

其中表备份模块还被配置成：

对所述各个表中的每一个表分别执行元数据检查以确定所述每一个表为所述第一类型表还是所述第二类型表；并且

将所述每一个表从所述源数据库复制到所述备份存储位置；

其中表备份模块还被配置成：

响应于所述元数据检查表明所述每一个表为第一类型表，并且通过对所述更新日志的解析表明在针对该第一类型表的临界时间段期间发生了所述第一类型操作，直接返回执行元数据检查以重新备份该第一类型表，

其中所述临界时间段是不允许对该第一类型表执行所述第一类型操作的时间段，并且

其中所述临界时间段开始于对该第一类型表执行所述元数据检查的时间段内的一时刻，并且结束于将该第一类型表复制到所述备份存储位置的时间段内的一时刻。

11.如权利要求10所述的数据库备份装置，还包括数据库恢复模块，其被配置成：

将已备份至所述备份存储位置的各个表导入目标数据库；以及

对所述目标数据库回放已同步至所述备份存储位置的更新日志，使得由所述更新操作产生的增量数据被合并到已导入所述目标数据库的所述各个表中的相应表。

12.一种计算设备，包括存储器和处理器，所述存储器被配置成在其上存储计算机程序指令，所述计算机程序指令当在所述处理器上执行时促使所述处理器执行权利要求1-9中任一项所述的方法。

13.一种计算机可读存储介质，其上存储计算机程序指令，所述计算机程序指令当在处理器上执行时促使所述处理器执行权利要求1-9中任一项所述的方法。