基于binlog的元数据管理方法和用于提供元数据的方法及装置

摘要

本申请公开了一种基于binlog的元数据管理方法和装置，以及一种用于提供元数据的方法和装置。其中，所述基于binlog的元数据管理方法包括：从MySQL主数据库获取元数据，作为基准元数据；以上述获取基准元数据的时间点为起点，从所述MySQL主数据库获取二进制日志binlog数据；在上述获取binlog数据的过程中，针对所述binlog数据中的每个日志事件执行下述操作：判断所述日志事件记录的是否为DDL操作；若是，存储与所述DDL操作相关的信息。采用本申请提供的方法，实现了对MySQL主数据库在各个时间点的元数据的自主管理，从而可以提供从自主管理的起始时间到当前时间之间的任意一个时间点的元数据信息，增强了binlog解析功能的容错性和可运维性。

说明书

技术领域

本申请涉及MySQL数据库技术，具体涉及一种基于binlog的元数据管理方 法和装置。本申请同时提供一种用于提供元数据的方法和装置。

背景技术

MySQL是一个开放源码的关系型数据库管理系统，通常采用主从同步的架 构方式，即：一台主服务器负责处理写入操作和少量的读操作，一台或者多台 从服务器(或称备用服务器)负责处理读操作，从而实现负载均衡，缩短对用 户访问请求的响应时间。针对上述主从同步的架构方式，MySQL数据库通常 采用二进制日志文件Binlog来实现主、从数据库之间的数据复制功能。

随着数据库技术以及数据库业务的发展，上述主从复制功能已无法满足多 变的用户需求，例如，有的数据库业务只需要同步部分库或者表中的数据；有 的业务则需要把MySQL中的数据，同步到其他关系数据库，甚至nosql数据库 中去。基于这些需求，有些公司开发了基于binlog的数据同步产品，在MySQL 系统的外部实现数据解析和同步功能，具体说：将从MySQL主库拉取的binlog 数据解析成和数据库无关的结构数据，然后将所述结构数据按照目标数据库的 需求导入到所述目标数据库中，从而实现所需的数据同步功能。

在上述数据同步的过程中，为了完整地将binlog中的数据解析成和数据库 无关的结构数据，通常需要获知MySQL数据库的完整元数据(meta数据，即： 记录数据库和表结构的数据)，然而由于binlog自身无法提供这部分数据，因此 现有技术通常采用以下三种方式获取：

1)直接向MySQL主数据库查询所需的元数据；

2)搭建独立的MySQL数据库，每从binlog数据里获取一个DDL，都在该 MySQL数据库中执行，需要元数据时从该MySQL数据库中获取；

3)搭建meta中心，定期从MySQL主数据库抓取元数据并保存，如果在 数据同步过程中因为故障要重新执行部分同步操作、需要获取过去的某个指定 时间点的元数据时，则从已抓取的元数据中选择一个版本，并从该版本对应的 时间点重新拉取并解析binlog数据。

上述三种方式，在具体的应用过程中分别存在以下缺陷：

采用方式一，由于解析binlog数据需要与binlog数据的时间戳对应的元数 据信息，而MySQL主数据库的元数据是实时变化的，因此通过直接连接主库查 询的方式获得当前时间点的元数据信息，可能出现与解析binlog所需元数据不 一致的情况；

采用方式二，只能提供与当前解析的binlog数据的时间戳对应的元数据， 无法提供之前的其他时间点的元数据。

采用方式三，每隔一段时间就要从MySQL主数据库查询一次元数据，增加 了主数据库的负担；而且在需要获取过去的某个指定时间点的元数据时，只能 从定期抓取的元数据中，选取其抓取时间点早于所述指定时间点的元数据版本， 并从该版本对应的时间点开始拉取binlog数据，通常会拉取重复的数据，影响 整个数据同步过程的效率。

发明内容

本申请提供一种基于binlog的元数据管理方法和装置，以解决现有技术无 法根据指定时间点提供元数据的问题。本申请另外提供一种用于提供元数据的 方法和装置。

本申请提供一种基于binlog的元数据管理方法，包括：

从MySQL主数据库获取元数据，作为基准元数据；

以上述获取基准元数据的时间点为起点，从所述MySQL主数据库获取二进 制日志binlog数据；在上述获取binlog数据的过程中，针对所述binlog数据中 的每个日志事件执行下述操作：

判断所述日志事件记录的是否为DDL操作；

若是，存储与所述DDL操作相关的信息。

可选的，与所述DDL操作相关的信息包括：所述DDL操作对应的DDL语 句，以及所述DDL操作在所述binlog数据中对应的时间戳信息。

可选的，所述方法包括：

压缩所述基准元数据，并将压缩后的基准元数据以文件的形式存储在本地 文件系统中。

可选的，在执行所述压缩所述基准元数据的步骤前，执行下述操作：

将已获取的基准元数据导入本地MySQL数据库中；

相应的，如果所述判断所述日志事件记录的是否为DDL操作的结果为“是”， 则在存储与所述DDL操作相关的信息之前，执行下述操作：

在本地MySQL数据库中执行所述DDL操作。

可选的，所述存储与DDL操作相关的信息是指，将与DDL操作相关的DDL 语句和时间戳信息存储在本地MySQL数据库中的一个用于存储元数据相关信 息的特定数据表中；

相应的，所述方法还包括：

将所述获取基准元数据的时间点和存储基准元数据所使用的文件名称，存 储在本地MySQL数据库中的所述特定数据表中。

可选的，所述方法包括：

按照预先设定的时间间隔，定期执行下述操作：

从本地MySQL数据库获取对应于MySQL主数据库的元数据；

压缩所述元数据，并将压缩后的元数据以文件的形式存储在本地文件系统 中，作为与本次执行获取操作的时间点对应的基准元数据；

将获取上述基准元数据的时间点和存储所述基准元数据的文件名称，存储 在本地MySQL数据库中的所述特定数据表中。

可选的，所述方法包括：

按照预先设定的时间间隔，从本地文件系统中删除存储时间超过预先设定 期限的基准元数据文件，并从本地MySQL数据库中删除与被删除的文件对应的 DDL操作的相关信息。

相应的，本申请还提供一种基于binlog的元数据管理装置，包括：

基准元数据获取单元，用于从MySQL主数据库获取元数据，作为基准元数 据；

DDL操作信息获取单元，用于以上述获取基准元数据的时间点为起点，获 取并存储MySQL主数据库执行的DDL操作信息；

所述DDL操作信息获取单元包括：

Binlog数据获取子单元，用于以上述获取基准元数据的时间点为起点，从所 述MySQL主数据库获取二进制日志binlog数据；

DDL信息处理子单元，用于针对binlog数据中的每个日志事件，判断该日 志事件记录的是否为DDL操作；若是，存储与所述DDL操作相关的信息。

可选的，所述DDL操作信息获取单元存储的DDL信息包括：所述DDL操 作对应的DDL语句，以及所述DDL操作在所述binlog数据中对应的时间戳信 息。

可选的，所述装置包括：

数据压缩单元，用于压缩所述基准元数据，并将压缩后的基准元数据以文 件的形式存储在本地文件系统中。

可选的，所述装置包括：

基准元数据导入单元，用于在压缩所述基准元数据之前，将已获取的基准 元数据导入本地MySQL数据库中；

相应的，所述DDL信息处理子单元具体用于，针对binlog数据中的每个日 志事件，判断该日志事件记录的是否为DDL操作；若是，在本地MySQL数据 库中执行存储所述DDL操作并存储相关信息；

所述DDL信息处理子单元包括：

DDL判断子单元，用于针对binlog数据中的每个日志事件，判断该日志事 件记录的是否为DDL操作；

DDL执行子单元，用于当所述判断子单元的输出为“是”时，在本地MySQL 数据库中执行所述DDL操作，并触发DDL存储子单元工作；

DDL存储子单元，用于存储所述DDL操作的相关信息。

可选的，所述DDL存储子单元，具体用于，将与DDL操作相关的DDL语 句和时间戳信息存储在本地MySQL数据库中的一个用于存储元数据相关信息 的特定数据表中；

相应的，所述装置还包括：

基准元数据信息存储单元，用于将所述获取基准元数据的时间点和存储基 准元数据所使用的文件名称，存储在本地MySQL数据库中的所述特定数据表 中。

可选的，所述装置还包括：

基准元数据定期生成单元，用于按照预先设定的时间间隔生成基准元数据；

所述基准元数据定期生成单元包括：

定时控制子单元，用于根据预先设定的时间间隔定时触发下述本地元数据 获取子单元、基准元数据压缩子单元和基准元数据信息存储子单元工作；

本地元数据获取子单元，用于从本地MySQL数据库获取对应于MySQL主 数据库的元数据；

基准元数据压缩子单元，用于压缩所述元数据，并将压缩后的元数据以文 件的形式存储在本地文件系统中，作为与本次执行获取操作的时间点对应的基 准元数据；

基准元数据信息存储子单元，用于将获取上述基准元数据的时间点和存储 所述基准元数据的文件名称，存储在本地MySQL数据库中的所述特定数据表 中。

可选的，所述装置还包括：

基准元数据清理单元，用于按照预先设定的时间间隔，从本地文件系统中 删除存储时间超过预先设定期限的基准元数据文件，并从所述本地MySQL数据 库中删除与被删除的文件对应的DDL操作的相关信息。

此外，本申请还提供一种用于提供元数据的方法，包括：

接收获取与指定时间点对应的MySQL主数据库元数据的请求；

根据预先存储的所述MySQL主数据库的基准元数据和DDL操作信息，生 成本地MySQL数据库，该数据库与所述MySQL主数据库在所述指定时间点上 的元数据一致；

获取本地MySQL数据库中对应于MySQL主数据库的元数据，并返回给所 述请求的发起方。

可选的，所述MySQL主数据库的基准元数据和DDL操作信息，是通过以 下步骤生成的：

从所述MySQL主数据库获取元数据并存储，作为与执行所述获取操作的时 间点相对应的基准元数据；

以上述获取基准元数据的时间点为起点，从所述MySQL主数据库获取二进 制binlog数据，并存储所述binlog数据中与DDL操作相关的信息；所述与DDL 操作相关的信息包括：所述DDL操作对应的DDL语句及其在binlog数据中的 时间戳。

可选的，所述生成所述MySQL主数据库元数据的基准数据和DDL操作信 息的步骤，还包括：

将从所述MySQL主数据库获取的基准元数据导入本地MySQL数据库中； 并且，每次存储所述binlog数据中与DDL操作相关的信息之前，在本地MySQL 数据库中执行所述DDL操作；

按照预先设定的时间间隔，定期获取本地MySQL数据库的元数据并存储， 作为与执行所述获取操作的时间点对应的基准元数据。

可选的，所述根据预先存储的所述MySQL主数据库的基准元数据和DDL 操作信息，生成本地MySQL数据库，包括：

从预先存储的所述MySQL主数据库的基准元数据中，选取其时间点早于并 且临近所述指定时间点的基准元数据；

从预先存储的DDL操作信息中，选择其时间戳晚于所选基准元数据对应的 时间点、并且早于所述指定时间点的DDL操作信息；

将选取的基准元数据导入本地MySQL数据库中；

在执行了上述导入操作的本地MySQL数据库中依次执行所选的DDL操作。

可选的，在执行所述将选取的基准数据导入本地MySQL数据库的步骤之 前，执行下述操作：

判断本地MySQL数据库是否已有与MySQL主数据库对应的元数据；

若是，通过执行删除操作清除本地MySQL数据库中的所述元数据。

可选的，在执行了导入操作的本地MySQL数据库中依次执行所选的DDL 操作之前，执行下述操作：

从所选的DDL操作信息中，剔除从整体上对本地MySQL数据库的元数据 不产生影响的DDL操作信息；

相应的，所述在本地MySQL数据库中依次执行所选的DDL操作是指，在 本地MySQL数据库中依次执行完成上述剔除操作后的DDL语句。

相应的，本申请还提供一种用于提供元数据的装置，包括：

请求接收单元，用于接收获取与指定时间点对应的MySQL主数据库元数据 的请求；

数据库生成单元，用于根据预先存储的所述MySQL主数据库的基准元数据 和DDL操作信息，生成本地MySQL数据库，该数据库与所述MySQL主数据 库在所述指定时间点上的元数据一致；

数据返回单元，用于获取本地MySQL数据库中对应于MySQL主数据库的 元数据，并返回给所述请求的发起方。

可选的，所述装置还包括基准元数据生成单元，用于预先生成并存储所述 MySQL主数据库的基准元数据和DDL操作信息；

所述基准元数据生成单元包括：

基准元数据获取子单元，用于从所述MySQL主数据库获取元数据并存储， 作为与执行所述获取操作的时间点相对应的基准元数据；

DDL操作信息获取子单元，用于以上述获取基准元数据的时间点为起点， 从所述MySQL主数据库获取二进制binlog数据，并存储所述binlog数据中与 DDL操作相关的信息。

可选的，所述基准元数据生成单元还包括：

基准元数据导入子单元，用于将从所述MySQL主数据库获取的基准元数据 导入本地MySQL数据库中；

相应的，所述DDL操作信息获取子单元具体用于，以上述获取基准元数据 的时间点为起点，从所述MySQL主数据库获取二进制binlog数据，并在本地 MySQL数据库中执行所述binlog数据中的DDL操作，并存储相关信息。

所述基准元数据生成单元还包括：

基准元数据定期生成子单元，用于按照预先设定的时间间隔，定期获取本 地MySQL数据库的元数据并存储，作为与执行所述获取操作的时间点对应的基 准元数据。

可选的，所述数据库生成单元包括：

基准元数据选择子单元，用于从预先存储的所述MySQL主数据库的基准元 数据中，选取其时间点早于并且临近所述指定时间点的基准元数据；

DDL操作信息选择子单元，用于从预先存储的DDL操作信息中，选择其时 间戳晚于所选基准元数据对应的时间点、并且早于所述指定时间点的DDL操作 信息；

基准元数据导入子单元，用于将所述基准元数据选择子单元选取的基准元 数据导入本地MySQL数据库中；

DDL操作执行子单元，用于在执行了上述导入操作的本地MySQL数据库 中，依次执行所述DDL操作信息选择子单元所选的DDL操作。

可选的，所述数据库生成单元还包括：

元数据清除子单元，用于在将选取的基准数据导入本地MySQL数据库之 前，判断本地MySQL数据库是否已有与MySQL主数据库对应的元数据，若是， 通过执行删除操作清除本地MySQL数据库中的所述元数据。

可选的，所述数据库生成单元还包括：

DDL操作剔除子单元，用于在本地MySQL数据库中依次执行所选的DDL 操作之前，从所选的DDL操作信息中，剔除从整体上对本地MySQL数据库的 元数据不产生影响的DDL操作信息；

相应的，所述DDL操作执行子单元具体用于，在本地MySQL数据库中依 次执行完成上述剔除操作后的DDL语句。

与现有技术相比，本申请具有以下优点:

本申请提供的一种基于binlog的元数据管理方法，通过从MySQL主数据库 获取基准元数据，并将在拉取binlog过程中提取的DDL操作信息进行集中管理， 提供了对MySQL主数据库在各个时间点的元数据进行自主管理的一种方法，从 而为生成从自主管理的起始时间点到当前时间点之间的任意时间点的元数据提 供了可靠的依据。

本申请提供的一种用于提供元数据的方法，接收获取与指定时间点对应的 MySQL主数据库元数据的请求后，根据预先存储的所述MySQL主数据库的基 准元数据和DDL操作信息，生成与所述MySQL主数据库在所述指定时间点上 的元数据一致的本地MySQL数据库，并将该数据库的元数据返回给所述请求的 发起方。采用本方法，在不增加MySQL主数据库额外负担的情况下，不仅能够 提供当前解析binlog所需的准确元数据信息，而且可以提供从自主管理的起始 时间到当前时间之间的任意一个时间点的元数据信息，从而增强了binlog解析 功能的容错性和可运维性，为MySQL数据库业务的批量运维、数据过滤、异构 数据库同步、细粒度的并行同步等功能的实现提供了便利。

附图说明

图1是本申请的一种基于binlog的元数据管理方法的实施例的流程图；

图2是本申请实施例提供的获取DDL操作信息的处理过程的流程图；

图3是本申请的一种基于binlog的元数据管理装置的实施例的示意图；

图4是本申请的一种用于提供元数据的方法实施例的流程图；

图5是本申请实施例提供的生成本地MySQL数据库的处理流程图；

图6是本申请的一种用于提供元数据的装置实施例的示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请 能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背 本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请中，分别提供了一种基于binlog的元数据管理方法和装置、一种 用于提供元数据的方法和装置，在下面的实施例中逐一进行详细说明。

请参考图1，其为本申请的一种基于binlog的元数据管理方法的实施例的流 程图。所述方法包括如下步骤：

步骤101：从MySQL主数据库获取元数据，作为基准元数据。

所谓数据库的元数据，是指数据的数据，通常用于存储数据库及表的结构 信息，包括：数据库名、表名、列名、数据类型、长度、主键、外键、索引、 索引组合方式、编码方式等信息。数据库及表的结构并不是自创建后就一成不 变的，可能会因为执行DDL(DataDefinitionLanguage—数据定义语言)操作， 使得数据库的元数据发生变化，本实施例技术方案通过从MySQL主数据库获取 全量元数据作为基准元数据(获取该数据的时间点称为起始时间点)，并在从 MySQL主数据库拉取binlog的过程中，存储MySQL主数据库曾经执行的各个 DDL操作，即：记录了元数据所发生的增量变化，从而为生成起始时间点与当 前时间点之间的任意时间点的元数据提供了可靠的依据，实现了对MySQL主数 据库的元数据的自主管理。

从MySQL主数据库获取基准元数据，可以先与MySQL主数据库建立数据 连接，然后在该数据连接的基础上，向MySQL主数据库发送与获取元数据有关 的命令，例如：“showcreatedatabasedb_name”以及“showcreatetabletb_name” 等，然后接收从MySQL主数据库返回的信息。

例如，“showcreatetablet”命令，MySQL主数据库返回如下所示的信息：

上述信息实际上就是一个创建Tablet的DDL语句，包含了与数据表t相关 的元数据，例如列名、数据类型、长度以及主键等信息。当然上面列举的仅仅 是一个示意性的例子，在具体的实施中，MySQL主数据库针对上述show命令 返回的信息可能更为复杂。与“showcreatetabletb_name”类似，“showcreate databasedb_name”命令的返回信息中会包含createdatabaseDDL语句。

由于通过上述“showcreatetable”和“showcreatedatabase”返回的DDL 语句反映了数据库和表的结构信息，通过执行这些DDL语句就可以得到相应结 构的数据库和表，因此这些通过show命令返回的DDL语句就组成了本实施例 所述的元数据。

元数据可能随时间变化，因此本步骤从MySQL主数据库获取的元数据是与 所述起始时间点对应的，而且由于该元数据是全量数据，可以作为生成其他时 间点元数据的基准，因此称为与起始时间点对应的基准元数据。

如果要获取元数据的数据库和表的名称都是已知的，可以采用上述方式依 次获取即可。但是如果不知道MySQL主数据库中具体包含哪些数据库和表，或 者为了实现程序代码的复用，可以通过向MySQL主库发送下列命令的方式来获 取MySQL主数据库的元数据。

1)发送“showdatabase”命令，获取MySQL主库上的所有数据库的名称；

2)针对每个数据库，执行“showcreatedatabsedb_name”命令，获取名称 为db_name的数据库相关的元数据；

3)针对每个数据库，执行“showtablesfromdb_name”命令，获取名称为 db_name的数据库中的所有表的名称；

4)针对每个数据表，执行“showcreatetabletb_name”，获取名称为tb_name 的数据表的元数据。

通过上述方式获取MySQL主库在所述起始时间点的基准元数据后，可以存 储在内存中，也可以存储在本地文件系统或者其他存储介质中。如果所述基准 元数据的数据量比较大，例如达到了上百兆甚至超过了一个G，那么为了节省 对存储空间的占用，通常可以压缩所述基准元数据，并将压缩后的基准元数据 以文件的形式存储在本地文件系统或者其他存储介质中。在本实施例的一个具 体例子中，采用的是theDEFLATEcompression无损压缩算法执行的上述压缩操 作。

需要说明的是，在本实施例的一个具体例子中，通过“showcreatetable”和 “showcreatedatabase”命令获取与数据库和表相关的常规元数据，然而在实际 应用中，可能还需要进一步获取其他一些元数据，例如与索引、枚举、约束、 列字符集、编码方式等相关的元数据，在这种情况下可以采用类似的方法从 MySQL主数据库的系统表中获取所需的元数据。

步骤102：将已获取的基准元数据导入本地MySQL数据库中。

之所以要将已获取的基准元数据导入本地MySQL数据库中，是为了生成一 个与MySQL主数据库在起始时间点的元数据状态一致的本地MySQL数据库， 并通过在后续步骤103中执行从binlog中获取的DDL语句，使得本地MySQL 数据库与MySQL主数据库的元数据状态基本保持一致，从而在步骤104中能够 定期地根据本地MySQL生成不同时间点的基准元数据，而不会对MySQL主库 造成不必要的负担。

在本步骤中，如果本地尚未启动MySQL数据库服务，则可以执行下述操作：

1)用“mysql_install_db”命令初始化数据目录；

2)用“mysqld_safe”命令启动本地MySQL数据库服务。

通过在本地MySQL数据库中执行步骤101中获取的基准元数据包含的各个 DDL语句，就可以将已获取的MySQL主数据库的基准元数据导入本地MySQL 数据库中。具体说，可以先执行基准元数据中的“createdatabasedb_name”语 句在本地创建名称为db_name的数据库，通过“usedb_name”将创建的名称为 db_name的数据库作为当前数据库，然后执行该数据库包含的各个表所对应的 “createtabletb_name”DDL语句，从而完成该数据库中表结构的创建。采用上 述方式，执行所述基准元数据中的所有DDL语句，就可以完成本步骤的导入操 作。

在具体实现时，可以通过链接libmysqlclient.so库，并调用CAPI访问本地 MySQL数据库，也可以使用通用SQL接口访问本地MySQL数据库。

步骤103：以上述获取基准元数据的时间点为起点，从所述MySQL主数据 库拉取二进制日志binlog数据，在本地MySQL数据中执行binlog数据中的DDL 操作并存储相关信息。

为了获取MySQL主数据库在所述起始时间点之后的各个时间点的元数据 变化情况，需要持续地从MySQL主数据库拉取binlog数据，并在该过程中，在 本地MySQL数据库中执行binlog数据中每个DDL语句并存储相关信息。请参 见附图2，为了便于描述，将该处理过程分为两个步骤进行说明。

步骤103-1：以所述起始时间点为起点，从MySQL主数据库拉取binlog数 据。

为了便于理解，在此先对binlog作简要说明。binlog是MySQL以二进制形 式存储的日志，其中记录了对MySQL数据库所作的更改操作，MySQL主数据 库通常有一个或者多个二进制日志文件，不同的二进制日志文件通过文件扩展 名采用不同的数字编号形式加以区分，例如：mysql-bin.00001，mysql-bin.00002 等。

每个binlog文件头部都是4个字节的标记，随后就是一系列的 LOG_EVENT，即：本申请所述的日志事件，正常情况下binlog按照逐 LOG_EVENT的形式增长。LOG_EVENT的事件类型有很多种，其中用于记录 数据库更改操作的LOG_EVENT的事件类型为查询事件(queryevent)。 LOG_EVENT头部的第0-3字节记录执行数据库更改操作的主机时间，即为本申 请所述的时间戳信息，例如：时间戳1390467118对应的就是ThuJan2316:51:58 CST2014这个时间点；LOG_EVENT头部的第13-16字节，记录了该 LOG_EVENT的偏移量，即：在二进制日志文件中的位置；LOG_EVENT的事 件体部分记录了具体的事件内容，例如：具体的DDL语句或者DML(Data ManipulationLanguage)语句等。

为了从MySQL主数据库拉取binlog数据，需要按照MySQL提供的原生命 令COM_BINLOG_DUMP的接口要求，提供要获取的binlog数据的位点信息， 即：希望获取的数据所在的binlog文件的文件名及其在该文件中的偏移量。而 在本步骤中，需要拉取从所述起始时间点开始的binlog数据，因此需要将所述 起始时间点转换为COM_BINLOG_DUMP接口需要的位点信息，下面对该转换 过程作进一步说明。

首先，获取二进制日志文件列表。例如，可以向MySQL主数据库发送“show masterlogs”命令，然后接收MySQL主数据库返回的其本地二进制日志文件列 表，例如，在本实施例的一个具体例子中，MySQL主数据库返回的列表中包含 7个二进制日志文件文件，mysql-bin.000001、mysql-bin.000002、...... mysql-bin.000007。

然后，在已获取的二进制日志文件列表所包含的二进制日志文件中，获取 与所述起始时间点对应的二进制日志文件及偏移量信息。通过前面对binlog文 件格式的介绍可以知道，binlog文件就像一个流文件，按照时间顺序记录了对 MySQL数据库所做的更改。基于binlog文件格式的这种特点，可以采用二分查 找法，查找其包含的第一个日志事件的时间戳不晚于所述起始时间点的最后一 个文件，并从该文件的第一个日志事件开始执行遍历操作，找到其时间戳不早 于所述起始时间点的第一个日志事件，读取该日志事件头部的第13-16字节就获 取了该日志事件在当前二进制日志文件中的偏移量，从而找到了与所述起始时 间对应的二进制日志文件以及偏移量信息。

获取上述信息后，就可以向MySQL主数据库发送MySQL的原生命令 COM_BINLOG_DUMP，并根据该命令的格式要求，携带希望获取日志数据的 位点信息，即：上述已获取的二进制日志文件的名称以及偏移量信息。随后就 可以接收到MySQL主数据库返回的binlog数据，即：位于上述位点信息之后的 新的增量日志数据。

步骤103-2：针对获取的binlog数据中的每一个日志事件，判断其记录的是 否为DDL操作，若是，在本地MySQL数据库中执行该DDL操作并存储相关信 息。

每次接收的binlog数据中可能包含多个日志事件(LOG_EVENT)，根据 binlog数据文件的格式，逐一提取其中的每个日志事件，如果该日志事件的事件 类型不是Queryevent(事件类型信息记录在LOG_EVENT头部的第4个字节中)， 则继续提取下一个LOG_EVENT进行处理。

如果该日志事件为Queryevent，则进一步判断其事件体中记录的数据库更 改操作是否为DDL操作，对于采用row方式进行记录更新的binlog文件，Query event包含的通常是DDL操作；而对于采用statement方式进行记录更新的binlog 文件，Queryevent可能包含DML操作或DDL操作。因此，可以对Queryevent 事件体中记录的数据库更改操作语句进行语法解析，如果包含的是DDL语句(例 如常用的Create、Drop等语句)则执行下述两项操作，否则采用上述方式继续 处理下一个LOG_EVENT，直至将本次获取的binlog数据中的LOG_EVENT处 理完毕。

1)在本地MySQL数据库中执行所述DDL操作。

在本地MySQL数据库中执行从binlog数据中获取的DDL操作，即：使本 地MySQL数据库也发生与MySQL主数据库相同的数据库或表结构的变更。

在具体实现时，可以通过链接libmysqlclient.so库，并调用CAPI访问本地 MySQL数据库，也可以使用通用SQL接口访问本地MySQL数据库，例如使用 通用SQL接口执行CreatetableDDL语句等。

2)存储所述DDL操作的相关信息。

在步骤101中已经获取了MySQL主数据库在起始时间点的基准元数据(即： 起始时间点的全量元数据)，在本步骤中，再将从起始时间点拉取的binlog数据 中的DDL操作信息存储下来，也就获取了在基准元数据基础上的MySQL主数 据库的结构变更的增量信息。获取并存储了上述两类数据，就能够灵活地提供 MySQL主数据库在起始时间点之后的任意一个时间点的元数据，从而为需要该 信息的其他数据库应用或者业务提供服务。

在本步骤中，存储从binlog数据中获取的DDL操作的相关信息，所述DDL 操作的相关信息包括：与DDL操作相关的DDL语句、该DDL操作在binlog数 据中的时间戳信息。在具体实现中，可以将上述信息存储在内存中，也可以存 储在本地文件系统或者数据库中。在本实施例的一个具体例子中，在本地MySQL 数据库中单独创建了一个用于存储元数据相关信息的表，并将上述DDL操作的 相关信息存储在该表中。

上面描述了从MySQL主数据库拉取binlog数据并存储其中的DDL操作信 息的处理过程。需要说明的是，上述拉取过程和对DDL操作的处理过程并不是 一次性完成的，为了持续获取MySQL主数据库的元数据变化情况，需要反复执 行上述操作，即：每次接收到MySQL数据库返回的增量binlog数据并处理后， 都需要设置新的位点信息，并且再次发送COM_BINLOG_DUMP命令，获取下 一次的增量binlog数据并进行同样的处理。

步骤104：按照预先设定的时间间隔，定期生成基准元数据。

从理论上说，存储了MySQL主数据库在起始时间点的基准元数据，以及之 后MySQL主数据库执行的DDL操作信息后，对外提供元数据服务的应用或者 模块就可以依据上述数据，通过在本地数据库加载基准元数据并执行起始时间 点和指定时间点之间的DDL操作，生成所述起始时间点之后的任意一个指定时 间点的元数据。

在起始时间点和指定时间点之间的DDL操作数量比较多的情况下，上述生 成元数据的过程因为要逐一执行DDL操作，会比较耗时，影响对外提供元数据 据的应用或者模块的整体性能。考虑到上述情况，本实施例的技术方案采用了 一种优选实施方式进行元数据的管理，即：按照预先设定的时间间隔，定期生 成不同时间点的基准元数据(也称为元数据的基备份)。采用这种元数据管理方 式，便于对外提供元数据的模块或应用选择与指定时间点最近的基准元数据， 从而有助于提高其整体性能。

要生成不同时间点的基准元数据，并且不增加MySQL主数据库的负担，本 实施例的技术方案维护了一个本地MySQL数据库(参见步骤102和步骤103中 的说明)。并按照预先设定的时间间隔，定期执行下述操作：

首先，从本地MySQL数据库获取对应于MySQL主数据库的元数据。可以 采用在步骤101中描述的类似方式，即：通过“showcreatetable”、“showcreate database”等命令，获取本地MySQL数据库的元数据。需要说明的是，如果在 前面的步骤103中，在本地MySQL数据库中单独创建了一个用于存储元数据相 关信息的表，那么在本步骤中不获取该表的元数据。

然后，采用步骤101所述的无损压缩算法对上述获取的元数据进行压缩， 并将压缩后的元数据以文件的形式存储在本地文件系统中，作为与本次执行获 取操作的时间点对应的基准元数据；

最后，存储获取上述基准元数据的时间点和存储所述基准元数据的文件名 称。如果在步骤103中，在本地MySQL数据库中已经创建了一个用于存储元数 据相关信息的表(DDL操作信息存储在该表中)，为了便于查询，在本步骤中可 以将定期生成的基准元数据的文件名和对应的时间点也存储在该表中。步骤101 中在起始时间点获取的MySQL主数据库的基准元数据文件及所述起始时间点 也可以一并存放在该表中。对外提供元数据的应用或者模块，通过对该表的查 询，就可以获取与特定时间点对应的基准元数据以及在特定时间范围内的DDL 操作信息。

需要说明的是，本实施例从MySQL主数据库拉取binlog数据并在本地 MySQL数据库中执行其中的DDL操作，即：在MySQL主数据库上执行的DDL 操作，也会在本地MySQL数据库上执行，然而两者之间可能存在一定的时延， 也就是说当前时间点从MySQL本地数据库中获取的基准元数据，可能与 MySQL主数据库在当前时间点的元数据不完全一致。但是，因为在本地存储的 DDL操作信息的时间戳记录了该操作在MySQL主数据库中的执行时间点，因 此根据本步骤生成的基准元数据以及DDL操作信息，可以获取起始时间点与当 前时间点之间的某个历史时间点(例如：当前解析的binlog数据中的时间戳对 应的时间点)对应的MySQL主数据库的准确元数据。从这个角度上考虑，可以 认为本步骤中定期生成的基准元数据，同样起到了在获取MySQL主数据库元数 据过程中的基准作用，因此可以用该数据作为MySQL主数据库的基准元数据。

在实际实施中，由于定期生成的基准元数据会占据越来越多的存储空间， 因此可以根据获取元数据的实际需求，以及本地存储空间的限制，采用一定的 策略定期进行基准元数据的清理。例如，可以每隔一段时间进行一次检查，从 本地文件系统中删除存储时间超过预先设定期限的基准元数据文件(例如：删 除存储时间超过7天的基准元数据文件)；删除基准元数据文件的同时，也应该 从本地MySQL数据库中的用于存储元数据相关信息的表中，删除与该文件相关 的信息，以及与该文件对应的DDL操作信息，即：时间戳位于该基准元数据的 时间点和与其临近的基准元数据时间点之间的所有DDL操作的相关信息。

上述步骤给出的是本申请技术方案的一种优选实施方式，对于实现本申请 的技术方案来说，上述步骤并非都是必需的。例如，在从MySQL主数据库获取 了基准元数据后，只要记录了后续从binlog中获取的DDL操作信息，就可以依 据这些信息提供MySQL主数据库在起始时间点之后的各时间点的元数据，实现 了本申请对元数据进行自主管理的目的，也就是说，可以不执行步骤102、以及 步骤103中关于在本地执行DDL操作的部分、以及步骤104，同样可以实现本 申请的技术方案。

综上所述，本申请提供的一种基于binlog的元数据管理方法，通过从MySQL 主数据库获取基准元数据，并将在拉取binlog过程中提取的DDL操作信息进行 集中管理，提供了对MySQL主数据库在各个时间点的元数据进行自主管理的一 种方法，从而为生成从起始时间点到当前时间点之间的任意时间点的元数据提 供了可靠的依据。

在上述的实施例中，提供了一种基于binlog的元数据管理方法，与之相对 应的，本申请还提供一种基于binlog的元数据管理装置。请参看图3，其为本申 请的一种基于binlog的元数据管理装置的实施例示意图。由于装置实施例基本 相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说 明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种基于binlog的元数据管理装置，包括：基准元数据获取单 元301，用于从MySQL主数据库获取元数据，作为基准元数据；基准元数据导 入单元302，用于在压缩所述基准元数据之前，将已获取的基准元数据导入本地 MySQL数据库中；DDL操作信息获取单元303，用于以上述获取基准元数据的 时间点为起点，从所述MySQL主数据库拉取二进制日志binlog数据，在本地 MySQL数据中执行binlog数据中的DDL操作并存储相关信息；基准元数据定 期生成单元304，用于按照预先设定的时间间隔生成基准元数据。

可选的，所述DDL操作信息获取单元包括：

Binlog数据获取子单元，用于以上述获取基准元数据的时间点为起点，从所 述MySQL主数据库获取二进制日志binlog数据；

DDL信息处理子单元，用于针对binlog数据中的每个日志事件，判断该日 志事件记录的是否为DDL操作；若是，在本地MySQL数据库中执行存储所述 DDL操作并存储相关信息。

可选的，所述DDL操作信息获取单元存储的DDL信息包括：所述DDL操 作对应的DDL语句，以及所述DDL操作在所述binlog数据中对应的时间戳信 息。

可选的，所述装置包括：

数据压缩单元，用于压缩所述基准元数据，并将压缩后的基准元数据以文 件的形式存储在本地文件系统中。

可选的，所述DDL信息处理子单元包括：

DDL判断子单元，用于针对binlog数据中的每个日志事件，判断该日志事 件记录的是否为DDL操作；

DDL执行子单元，用于当所述判断子单元的输出为“是”时，在本地MySQL 数据库中执行所述DDL操作，并触发DDL存储子单元工作；

DDL存储子单元，用于存储所述DDL操作的相关信息。

可选的，所述DDL存储子单元，具体用于，将与DDL操作相关的DDL语 句和时间戳信息存储在本地MySQL数据库中的一个用于存储元数据相关信息 的特定数据表中；

相应的，所述装置还包括：

基准元数据存储单元，用于将所述获取基准元数据的时间点和存储基准元 数据所使用的文件名称，存储在本地MySQL数据库中的所述特定数据表中。

可选的，所述基准元数据定期生成单元包括：

定时控制子单元，用于根据预先设定的时间间隔定时触发下列子单元工作；

本地元数据获取子单元，用于从本地MySQL数据库获取对应于MySQL主 数据库的元数据；

基准元数据压缩子单元，用于压缩所述元数据，并将压缩后的元数据以文 件的形式存储在本地文件系统中，作为与本次执行获取操作的时间点对应的基 准元数据；

基准元数据信息存储子单元，用于将获取上述基准元数据的时间点和存储 所述基准元数据的文件名称，存储在本地MySQL数据库中的所述特定数据表 中。

可选的，所述装置还包括：

基准元数据清理单元，用于按照预先设定的时间间隔，从本地文件系统中 删除存储时间超过预先设定期限的基准元数据文件，并从所述本地MySQL数据 库中删除与被删除的文件对应的DDL操作的相关信息。

与上述的一种基于binlog的元数据管理方法相对应的，本申请还提供一种 用于提供元数据的方法。请参考图4，其为本申请提供的一种用于提供元数据的 方法实施例的流程图，本实施例与第一实施例步骤相同的部分不再赘述，下面 重点描述不同之处。本申请提供的一种用于提供元数据的方法包括：

步骤401：生成并存储MySQL主数据库的基准元数据和DDL操作信息。

本步骤通过以下方式生成MySQL主数据库的基准元数据和DDL操作信息： 从所述MySQL主数据库获取元数据并存储，作为与执行所述获取操作的起始时 间点相对应的基准元数据；以上述起始时间点为起点，从所述MySQL主数据库 获取二进制binlog数据，并存储所述binlog数据中与DDL操作相关的信息；所 述与DDL操作相关的信息包括：所述DDL操作对应的DDL语句及其在binlog 数据中的时间戳。

通过上述方式生成了MySQL主数据库在起始时间点的基准元数据并存储 了随后的DDL操作信息，在本步骤中还可以在上述基础上采用如下方式生成在 多个时间点的基准元数据：将从所述MySQL主数据库获取的基准元数据导入本 地MySQL数据库中；并且，每次存储所述binlog数据中与DDL操作相关的信 息之前，在本地MySQL数据库中执行所述DDL操作；按照预先设定的时间间 隔，定期获取本地MySQL数据库的元数据并存储，作为与执行所述获取操作的 时间点对应的基准元数据。关于上述处理过程的详细描述，请参见第一实施例 中的相关说明。

定期生成的基准元数据，可以作为MySQL主数据库的基准元数据，与已存 储的DDL操作信息相配合，得到MySQL主数据库在起始时间点之后的任一时 间点的元数据。具体说明请参见下面的步骤402—404。

步骤402：接收获取与指定时间点对应的MySQL主数据库元数据的请求。

在MySQL数据库业务中，经常会有这样的需求，即：将MySQL主数据库 中的数据同步到其他关系型数据库，或者是nosql数据库中。在同步过程中，由 于某些原因，对拉取的binlog数据进行解析所使用的元数据信息已经发生错误 了，即：已经与被解析数据不相匹配了，然而同步过程并没有终止，而是在这 种不一致的状态下继续进行。当同步过程抛出错误信息或者通过人为干预发现 这一问题时，需要回退到同步过程最初发生错误的时间点重新拉取binlog数据， 在这种情况下，该同步任务就会向负责提供元数据的模块或应用发送获取 MySQL主数据库元数据的请求，该请求中携带了重新拉取binlog的位点信息， 即：binlog数据中的时间戳(即本步骤所述的指定时间点)。负责提供元数据的 模块或应用自然就会接收到该请求。

步骤403：根据预先存储的所述MySQL主数据库的基准元数据和DDL操 作信息，生成本地MySQL数据库，该数据库与所述MySQL主数据库在所述指 定时间点上的元数据一致。

生成与MySQL主数据库在指定时间点上的元数据一致的本地MySQL数据 库的过程，包括步骤403-1至步骤403-4，下面结合附图5对各个步骤作进一步 的说明。

步骤403-1：从预先存储的所述MySQL主数据库的基准元数据中，选取其 时间点早于并且临近所述指定时间点的基准元数据。

如果预先存储的MySQL主数据库的基准元数据只有一个，即：在起始时间 点从MySQL主数据库获取的基准元数据，那么在本步骤中直接选择该基准元数 据；如果预先存储了多个与不同时间点对应的MySQL主数据库的基准元数据， 则从中选择其时间点早于并且临近所述指定时间点的基准元数据，例如：有四 个基准元数据，其时间点分别为1日零时、11日零时、21日零时、31日零时， 而指定的时间戳对应15日的某个时间点，与该时间点临近的基准元数据为11 日零时和21日零时的，其中时间点早于指定时间点的是11日零时的基准元数 据，因此在本步骤选择11日零时的基准元数据。

步骤403-2：从预先存储的DDL操作信息中，选择其时间戳晚于所选基准 元数据对应的时间点、并且早于所述指定时间点的DDL操作信息。

在步骤403-1中根据指定时间点选择了一个基准元数据，即：选取了一个全 量的元数据，在本步骤中选择其时间戳晚于所选基准元数据对应的时间点、并 且早于指定时间点的DDL操作信息，即：在上述全量元数据的基础上进一步选 取了所述指定时间点之前的增量DDL操作，由这两部分数据就可以确定与所述 指定时间点对应的MySQL主数据库的元数据。

步骤403-3：将选取的基准元数据导入本地MySQL数据库中。

将步骤403-2中选取的基准元数据导入本地MySQL数据库之前，需要先判 断所述基准元数据是否经过压缩处理，若是，则执行解压缩处理，恢复原始的 基准元数据，然后再执行本步骤所述的导入操作。具体的导入处理过程与第一 实施例中的步骤102中的描述类似，请参见该部分的相关说明，此处不再赘述。

需要说明的是，在执行上述导入操作之前，需要先判断本地MySQL数据库 中是否已有与MySQL主数据库对应的元数据，如果有，该元数据与当前所需的 与指定时间点对应的元数据通常是不一致的，因此需要先清除本地MySQL数据 库中的元数据，具体说，针对本地MySQL数据库中与MySQL主数据库对应的 每个表和数据库，通过执行“Droptabletb_name”命令和“Dropdatabasedb_name” 命令删除对应的元数据。

步骤403-4：在执行了上述导入操作的本地MySQL数据库中依次执行所选 的DDL操作。

在本地MySQL数据库中导入了步骤403-1所选的基准元数据后，依次执行 在步骤403-2中选取的DDL操作，那么本地MySQL数据库的元数据就与所述 指定时间点上的MySQL主数据库的元数据保持一致。关于在本地MySQL数据 库中执行DDL操作的说明请参见第一实施例步骤103-2中的相关部分。

在本地MySQL数据库中依次执行所选的DDL操作之前，可以先对待执行 的DDL操作进行筛选，从中剔除从整体上对本地MySQL数据库的元数据不产 生影响的DDL操作信息。例如，在待执行的DDL操作中有这样的情况，存在 一个较早时间点的DDL操作为“createtableX”，一个较晚时间点的DDL操作 为“droptableX”，那么在这两个时间点之间(包括这两个时间点)的DDL语 句都可以剔除(标记为不执行)，因为这些DDL语句的执行最终不会对本地 MySQL数据库的元数据产生影响。然后再在本地MySQL数据库执行筛选出的、 未剔除的那些DDL操作，从而可以减少执行DDL操作的时间，提高处理效率。

通过上述步骤403-1至403-4，就生成了与MySQL主数据库在所述指定时 间点上元数据一致的本地MySQL数据库，在步骤404中就可以获取本地MySQL 数据库中的元数据并返回给所述请求的发起方。

在具体实施过程中可能存在这样一种情况，步骤401从MySQL主数据库拉 取的binlog数据可以同时提供给其他进行数据同步的模块，该模块在进行当前 binlog数据解析的过程中，如果需要获取与当前binlog数据的时间戳对应的元数 据信息，也可能会向负责提供元数据的模块或应用发送获取元数据的请求，该 请求中携带当前处理的binlog数据的时间戳信息(即：指定的时间点)。

在这种情况下，负责提供元数据的模块或应用如果在步骤101中根据拉取 的binlog数据已经维护了本地MySQL数据库，并且请求中指定的时间戳大于已 经存储的DDL操作信息中最近一个DDL操作的时间戳，则说明当前本地 MySQL数据库的元数据就是解析当前binlog数据所需的元数据(与指定时间点 对应的元数据)，因此可以不执行本步骤403的操作，而是直接执行步骤404的 操作，从本地MySQL数据库中获取元数据并返回给所述请求的发起方。

步骤404：获取本地MySQL数据库中对应于MySQL主数据库的元数据， 并返回给所述请求的发起方。

通过CAPI或者通用SQL接口访问本地MySQL数据库，针对本地MySQL 数据库中对应于MySQL主数据库的每个数据库和表，执行“showcreatetable tb_name”或“showcreatedatabasedb_name”等命令，可以获取本地MySQL数 据库的元数据。

通过上述方式获取的元数据与MySQL主数据库在指定时间点的元数据是 一致的，本步骤可以直接将该数据返回给所述请求的发起方，也可以对该数据 重新进行组织，按照与所述请求方预先约定好的数据格式返回给所述请求方。 所述请求方接收该元数据后，就可以根据该元数据对所述指定时间点的binlog 数据进行解析，从而实现数据同步等功能。

至此，就完成了根据指定的时间点提供元数据的功能。需要说明的是，步 骤401并不是每次都要执行的，而是预先生成好的，当有需求需要获取指定时 间点的元数据时，直接执行步骤402—404即可获取所需元数据，并对外提供服 务。另外在具体的实施过程中，步骤401所述的基准元数据和DDL操作信息也 可以由专门负责进行MySQL元数据管理的应用或者模块提供，在这种情况下， 负责提供元数据的模块或应用就不用执行步骤401，而是直接执行步骤402-步骤 404，根据需求提供指定时间点的元数据。

综上所述，采用本申请提供的一种用于提供元数据的方法，在不增加MySQL 主数据库额外负担的情况下，不仅能够提供当前解析binlog所需的准确元数据 信息，而且可以提供从起始时间到当前时间之间的任意一个时间点的元数据， 从而增强了binlog解析功能的容错性和可运维性，为MySQL数据库业务的批量 运维、数据过滤、异构数据库同步、细粒度的并行同步等功能的实现提供了便 利。

在上述的实施例中，提供了一种用于提供元数据的方法，与之相对应的， 本申请还提供一种用于提供元数据的装置。请参看图6，其为本申请的一种用于 提供元数据的装置的实施例示意图。由于装置实施例基本相似于方法实施例， 所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的 装置实施例仅仅是示意性的。

本实施例的一种用于提供元数据的装置，包括：基准元数据生成单元601， 用于预先生成并存储所述MySQL主数据库的基准元数据和DDL操作信息；请 求接收单元602，用于接收获取与指定时间点对应的MySQL主数据库元数据的 请求；数据库生成单元603，用于根据预先存储的所述MySQL主数据库的基准 元数据和DDL操作信息，生成本地MySQL数据库，该数据库与所述MySQL 主数据库在所述指定时间点上的元数据一致；数据返回单元604，用于获取本地 MySQL数据库中对应于MySQL主数据库的元数据，并返回给所述请求的发起 方。

可选的，所述基准元数据生成单元包括：

基准元数据获取子单元，用于从所述MySQL主数据库获取元数据并存储， 作为与执行所述获取操作的时间点相对应的基准元数据；

DDL操作信息获取子单元，用于以上述获取基准元数据的时间点为起点， 从所述MySQL主数据库获取二进制binlog数据，并存储所述binlog数据中与 DDL操作相关的信息。

可选的，所述基准元数据生成单元还包括：

基准元数据导入子单元，用于将从所述MySQL主数据库获取的基准元数据 导入本地MySQL数据库中；

相应的，所述DDL操作信息获取子单元具体用于，以上述获取基准元数据 的时间点为起点，从所述MySQL主数据库获取二进制binlog数据，并在本地 MySQL数据库中执行所述binlog数据中的DDL操作，并存储相关信息。

所述基准元数据生成单元还包括：

基准元数据定期生成子单元，用于按照预先设定的时间间隔，定期获取本 地MySQL数据库的元数据并存储，作为与执行所述获取操作的时间点对应的基 准元数据。

可选的，所述数据库生成单元包括：

基准元数据选择子单元，用于从预先存储的所述MySQL主数据库的基准元 数据中，选取其时间点早于并且临近所述指定时间点的基准元数据；

DDL操作信息选择子单元，用于从预先存储的DDL操作信息中，选择其时 间戳晚于所选基准元数据对应的时间点、并且早于所述指定时间点的DDL操作 信息；

基准元数据导入子单元，用于将所述基准元数据选择子单元选取的基准元 数据导入本地MySQL数据库中；

DDL操作执行子单元，用于在执行了上述导入操作的本地MySQL数据库 中，依次执行所述DDL操作信息选择子单元所选的DDL操作。

可选的，所述数据库生成单元还包括：

元数据清除子单元，用于在将选取的基准数据导入本地MySQL数据库之 前，判断本地MySQL数据库是否已有与MySQL主数据库对应的元数据，若是， 通过执行删除操作清除本地MySQL数据库中的所述元数据。

可选的，所述数据库生成单元还包括：

DDL操作剔除子单元，用于在本地MySQL数据库中依次执行所选的DDL 操作之前，从所选的DDL操作信息中，剔除从整体上对本地MySQL数据库的 元数据不产生影响的DDL操作信息；

相应的，所述DDL操作执行子单元具体用于，在本地MySQL数据库中依 次执行完成上述剔除操作后的DDL语句。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本 领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改， 因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出 接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。 内存是计算机可读介质的示例。

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

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机 程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件 和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计 算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。