CN114691704A - 一种基于MySQL binlog的元数据同步方法 - Google Patents

Abstract

本发明公开了一种基于MySQL binlog的元数据同步方法，包括如下步骤：S1、配置源端MySQL数据库，开启binlog；S2、采集全量表元数据，获取当前数据库中的库、表、字段等信息；S3、查询并记录当前日志文件，并将日志文件内偏移量作为增量基准；S4、根据增量基准，获取并解析binlog日志文件。本发明的元数据同步方法，先其中一个时间点作为基准点，记录binlog日志文件名和偏移量作为增量基准，从该增量基准作为起始点获取binlog日志文件数据并解析其中的事件，对于binlog日志文件中解析出来的DDL变更需要解析成中间格式的数据结构，并转换成二进制数据通过MQ发送到目的端，目的端对中间格式的数据结构反序列化，生成SQL语句并执行。

Description

一种基于MySQL binlog的元数据同步方法

技术领域

本发明涉及关系型数据库同步技术领域，具体地说是一种基于MySQL binlog的元数据同步方法。

背景技术

随着信息时代的飞速发展，大数据、人工智能的兴起，数据作为一种资源，越来越被一些企业、单位重视，数据产出的经济和社会价值也越来越明显。当今社会，企业数据越来越庞大、复杂，呈现数据量巨大、数据种类繁多包括结构化数据和非结构化数据、数据存放单一等特点，这势必给数据带来安全和不可靠的隐患，因此数据的同步和备份显得越来越重要。

在数据库同步需要同步数据库的全量和增量数据。全量可以认为是当前数据库中数据的一个快照，比如有多少库多少表等。增量是以采集全量的点为基准点之后的变更。增量数据包括DML(表数据的增删改)以及DML(增删库、增删表或表中增删列、重命名等表属性的修改)。为保证源端和目的端库的元数据一致，需要及时进行DDL数据的同步。

MySQL作为一种开源关系型数据库，由于其良好的功能和性能成为最流行的数据库，广泛应用于各种业务系统。MySQL生成的二进制日志binlog中包含了DDL及DML数据，可以解析日志还原出数据操作用于数据同步。

在现有技术中，公开号为CN 112306743 A，名称为《数据处理方法、装置、电子设备及计算机存储介质》的专利申请描述了mysql分库分表的分布式系统的备份恢复，但是该专利申请中未对DDL进一步描述处理。还有公开号为CN110879813A，名称为《一种基于二进制日志解析的MySQL数据库增量同步实现方法》的专利申请描述了基于binlog的DML增量采集，但是该申请未对DDL数据进行采集及进一步处理。

发明内容

本发明的目的是针对以上不足，提供一种基于MySQL binlog的元数据同步方法，

本发明所采用技术方案是：

一种基于MySQL binlog的元数据同步方法，包括如下步骤：

S1、配置源端MySQL数据库，开启binlog；

S2、采集全量表元数据，获取当前数据库中的库、表、字段等信息；

S3、查询并记录当前日志文件，并将日志文件内偏移量作为增量基准；

S4、根据增量基准，获取并解析binlog日志文件；

S5、将从binlog日志文件中解析出来的sql语句进行解析，并将解析后的sql语句填充到数据结构中；

S6、将所获取的增量日志传递到目的端，并在目的端执行同步数据；

S7、记录所获取的日志文件及最后的偏移量作为新的增量基准；

S8、间隔一定的时间后，重复步骤S4-S7。

作为进一步的优化，本发明步骤S1中，配置源端MySQL数据库配置过程中，在开启binlog后，还包括配置binlog日志文件名以及binlog日志文件路径，并配置server id。

作为进一步的优化，本发明步骤S2中，通过访问information_schema中的表，获取表SCHEMATA为库信息，tables为表信息，columns为列信息，views为视图信息；

采集全量表元数据时，在内存中记录该表结构数据。

作为进一步的优化，本发明步骤S3中，在采集全量表元数据之前需要记录下当前的binlog文件以及当前binlog文件的位置，若开启了gtid，并记录gtid号。

作为进一步的优化，本发明步骤S4中，与源端数据库建立数据库连接，向MASTER注册Slave，然后发送从某个增量点获取数据的请求(COM_BINLOG_DUMP)，接收二进制日志数据并逐个解析，直到数据解析完成。

作为进一步的优化，本发明步骤S4中，解析binlog过程中需要记录日志文件及位置position，以用于下次增量查询或异常恢复。

作为进一步的优化，本发明步骤S5中，在binlog中解析出来的sql语句中包括DDL变更和DWL变更，在解析DDL变更以后，需要将解析后的DDl变更对内存中记录的表元数据进行更新，在解析DWL数据时，需要依照此前记录的表元数据。

作为进一步的优化，本发明步骤S6中，源端采集解析的DDL变更数据序列化后传递到目的端，目的端根据RequestParam以及自身的数据类型，生成相应操作的SQL语句，并执行所生成的语句。

本发明具有以下优点：

1、本发明的元数据同步方法，先其中一个时间点作为基准点，记录binlog日志文件名和偏移量作为增量基准，从该增量基准作为起始点获取binlog日志文件数据并解析其中的事件，对于binlog日志文件中解析出来的DDL变更需要解析成中间格式的数据结构，并转换成二进制数据通过MQ发送到目的端，目的端对中间格式的数据结构反序列化，生成SQL语句并执行；

2、本发明通过同时同步DDl变更和DML变更使得源端和目的端的结构和数据保持一致性；

3、本发明通过将DDl变更变换为中间数据结构，既可以用作异构数据的元数据同步，还可以在目的端精准控制允许执行的操作。

附图说明

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

下面结合附图对本发明进一步说明：

图1为源端数据库的采集流程示意图；

图2为从源端获取binlog日志并解析的流程示意图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明，以使本领域的技术人员可以更好地理解本发明并能予以实施，但所举实施例不作为对本发明的限定，在不冲突的情况下，本发明实施例以及实施例中的技术特征可以相互结合。

需要理解的是，在本发明实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。在本发明实施例中的“多个”，是指两个或两个以上。

本发明实施例中的属于“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，单独存在B，同时存在A和B这三种情况。另外，本文中字符“/”一般表示前后关联对象是一种“或”关系。

本实施例提供一种基于MySQL binlog的元数据同步方法，主要过程为在源端数据库采集binlog日志文件，并进行解析后应用到目标端，具体的，包括如下步骤：

S1、配置源端MySQL数据库，开启binlog；

步骤S1中，配置源端MySQL数据库配置过程中，在开启binlog后，还包括配置binlog日志文件名以及binlog日志文件路径，并配置server id；具体的，需要如下方式重启MySQL配置文件：：

log_bin＝ON

log_bin_basename＝ binlog日志文件路径

log_bin_index＝ binlog日志文件名

server-id＝ 唯一标识一个客户端的整形数

并在配置完成后，重启MySQL服务；

S2、采集全量表元数据，获取当前数据库中的库、表、字段等信息；

通过访问information_schema中的表，获取表SCHEMATA为库信息，tables为表信息，columns为列信息，views为视图信息；可以通过执行sql简单查看，获取所有库(>SHOWDATABASES；),获取库的表(>SHOW TABLES；),获取表的字段(>SHOW CREATE TABLE table1；显示建表语句)；

在内存中记录此表结构数据，后续通过解析增量数据来更新；

S3、查询并记录当前日志文件，并将日志文件内偏移量作为增量基准；

Binlog是一组文件，其中包含了有关对MySQL服务器实例进行的数据修改的信息。日志由一组二进制日志文件和一个索引文件组成。索引文件记录了当前的日志文件。日志文件中包含了数据修改的事件。日志文件格式到目前有三个版本，需要根据mysql版本确定日志文件格式；

在采集全量表元数据之前需要记录下当前的binlog文件以及当前binlog文件的位置，若开启了gtid，并记录gtid号；通过SQL获取增量点的方式示例如下：

S4、根据增量点，获取并解析binlog日志文件；

通过建立数据库连接，并向MySQL发送命令再接收数据进行处理。向MASTER注册Slave(COM_REGISTER_SLAVE)，然后发送从某个增量点获取数据的请求(COM_BINLOG_DUMP)，接收二进制日志数据并逐个解析，直到数据解析完成。解析过程中需要记录日志文件及位置position，以用于下次增量查询或异常恢复。在发送获取增量数据前获取增量基准及当前表结构并记录备用。

Binlog-event表示了所有的事件及每个事件的格式，以此二进制格式解析；

其中的事件:WRITE_ROWS_EVENT,UPDATE_ROWS_EVENT,DELETE_ROWS_EVENT记录了数据的增删改操作的DML事件。QUERY_EVENT记录了DDL操作成功的sql语句。

S5、将从binlog日志文件中解析出来的sql语句进行解析，并将解析后的sql语句填充到数据结构中；

从binlog中解析出的sql语句如果是同一种数据库且配置完全一样，可以直接使用。否则需要进一步解析使用。SQL解析需要使用语法分析及词法分析工具，如flex/bison，可以参考mysql源码中的sql_yacc.yy及sql_lex.h和sql_lex.cc。解析SQL语句，并填充到数据结构中。

数据结构用proto3语法描述如下：

Proto3定义的数据结构可以生成C++/Java等语言的代码。数据结构提供了序列化和反序列化的功能

S6、将所获取的增量日志传递到目的端，并在目的端执行同步数据；

在解析DDL变更之后，需要将解析后的DDL操作对内存中记录的表元数据做更新。比如DDL为在某位置增加列，则需要在表示表列的数组中增加一列，并正确修改列的序号；如果DDL为重命名列，则需要修改表列中的命名；如果删除列，则需要修改该列后续列的列序列号。

解析DML数据时需要依照记录此处记录的表元数据。

当解析binlog日志到与增量日志采集前获取的日志位置一致时，此时内存中的表元数据应该与数据库中的表元数据一致。如果有误差可以依据策略(忽略误差或报错)，使用数据库中的元数据替换内存中的元数据，以使得后续binlog日志中的DML数据能正确解析。

S7、间隔一定的时间后，重复步骤S4-S6。

以上所述实施例仅是为充分说明本发明而所举的较佳的实施例，本发明的保护范围不限于此。本技术领域的技术人员在本发明基础上所作的等同替代或变换，均在本发明的保护范围之内。本发明的保护范围以权利要求书为准。

Claims (8)

1.一种基于MySQL binlog的元数据同步方法，其特征在于：S1、配置源端MySQL数据库，开启binlog；

S2、采集全量表元数据，获取当前数据库中的库、表、字段等信息；

S3、查询并记录当前日志文件，并将日志文件内偏移量作为增量基准；

S4、根据增量基准，获取并解析binlog日志文件；

S5、将从binlog日志文件中解析出来的sql语句进行解析，并将解析后的sql语句填充到数据结构中；

S6、将所获取的增量日志传递到目的端，并在目的端执行同步数据；

S7、记录所获取的日志文件及最后的偏移量作为新的增量基准；

S8、间隔一定的时间后，重复步骤S4-S7。

2.根据权利要求1所述的方法，其特征在于：步骤S1中，配置源端MySQL数据库配置过程中，在开启binlog后，还包括配置binlog日志文件名以及binlog日志文件路径，并配置server id。

3.根据权利要求2所述的方法，其特征在于：步骤S2中，通过访问information_schema中的表，获取表SCHEMATA为库信息，tables为表信息，columns为列信息，views为视图信息；

采集全量表元数据时，在内存中记录该表结构数据。

4.根据权利要求3所述的方法，其特征在于：步骤S3中，在采集全量表元数据之前需要记录下当前的binlog文件以及当前binlog文件的位置，若开启了gtid，并记录gtid号。

5.根据权利要求4所述的方法，其特征在于：步骤S4中，与源端数据库建立数据库连接，向MASTER注册Slave，然后发送从某个增量点获取数据的请求(COM_BINLOG_DUMP)，接收二进制日志数据并逐个解析，直到数据解析完成。

6.根据权利要求5所述的方法，其特征在于：步骤S4中，解析binlog过程中需要记录日志文件及位置position，以用于下次增量查询或异常恢复。

7.根据权利要求6所述的方法，其特征在于：步骤S5中，在binlog中解析出来的sql语句中包括DDL变更和DWL变更，在解析DDL变更以后，需要将解析后的DDl变更对内存中记录的表元数据进行更新，在解析DWL数据时，需要依照此前记录的表元数据。

8.根据权利要求1所述的方法，其特征在于：步骤S6中，源端采集解析的DDL变更数据序列化后传递到目的端，目的端根据RequestParam以及自身的数据类型，生成相应操作的SQL语句，并执行所生成的语句。

Images