CN113656511B

CN113656511B - 一种基于源库不停机的异构数据库增量同步方法及系统

Info

Publication number: CN113656511B
Application number: CN202111218116.9A
Authority: CN
Inventors: 赵伟; 朱佳伟
Original assignee: Tianjin Nankai University General Data Technologies Co ltd
Current assignee: Tianjin Nankai University General Data Technologies Co ltd
Priority date: 2021-10-20
Filing date: 2021-10-20
Publication date: 2022-02-18
Anticipated expiration: 2041-10-20
Also published as: CN113656511A

Abstract

本发明提供了一种基于源库不停机的异构数据库增量同步方法及系统，具体步骤如下：开启数据捕获，监控源端数据库的最新变化，捕获增量数据，并将增量数据发送到临时储存区；进行全量同步任务，全量过程和增量过程中均设置递增序列号；增量数据捕获完成，进行数据投递，完成临时储存区的增量数据进入目标端数据库；对全量同步过程中产生的重复数据进行去重；继续进行数据捕获和数据投递，进行后续的增量同步。本发明所述的临时储存区保证全量内容先进入目标端数据库，增量内容后进入目标端数据库，防止增量内容先进入目标端数据库在空表上执行sql语句，之后全量内容进入目标端数据库，导致增量内容没生效的问题发生，保证数据有效性。

Description

一种基于源库不停机的异构数据库增量同步方法及系统

技术领域

本发明属于于异构数据库数据同步领域，尤其是涉及一种基于源库不停机的异构数据库增量同步方法及系统。

背景技术

很多应用为了确保数据的安全、准确、合规，都会选择给数据源备份一个或多个节点，提高应用和用户的体验。大部分情况我们都需要在已有的业务基础上做数据同步，全量同步就是保证数据源和不同节点初始环境相同。传统的全量同步为了保证同步的准确性，一般选择将源端数据库停机，待确保数据同步完成后，再开启源端数据库的业务数据流入。可是全量同步基本上都会面临数据多，时间长的问题，尽管我们会选择晚上和低峰时段进行全量同步，但是长时间的业务不可用也是很多应用不可接受的。

本文旨在解决全量同步时应用可以实现源库不停机，既要保证源库的可用，又要保证数据同步的一致性。我们在实现过程中主要面临两个问题。第一，由于全量同步过程中，源端业务不停，所以同时会有增量数据产生并进入目标库，在全量同步完成并将全量过程中增量同步到目标库后，会产生重复数据。第二，由于全量和增量导出后我们无法保证谁先进入目标端数据库，如果增量内容先进入目标端数据库，会在空表上执行sql语句，之后全量内容进入目标端数据库，导致增量内容没生效，会产生数据不一致。

发明内容

有鉴于此，本发明旨在提出一种基于源库不停机的异构数据库增量同步方法及系统，以解决数据同步源库不停机的情况下，增量数据进入数据库产生重复数据以及增量数据先进入目标端数据库而产生增量内容失效的问题。

为达到上述目的，本发明的技术方案是这样实现的：

一方面，本申请提出一种基于源库不停机的异构数据库增量同步方法，将源端数据库内容存到目标端数据库中，具体步骤如下：

S1、开启数据捕获，监控源端数据库的最新变化，捕获增量数据，并将增量数据发送到临时储存区；

S2、进行全量同步任务,全量过程和增量过程中均设置递增序列号，全量过程中的递增序列号记录源端数据库改变次数，同时，增量过程中的递增序列号记录增量数据捕获次数；

S3、全量同步完成，获得全量过程中源端数据库改变的次数，获得全量过程的递增序列号；

S4、全量过程中设置的递增序列号在每次源端数据库改变后增加一，增量过程中设置的递增序列号记录增量数据捕获次数，当捕获次数大于改变次数时，标志着捕获增量数据完成，捕获增量数据完成，进行数据投递，完成临时储存区的增量数据进入目标端数据库,确保临时储存区的消息消费完毕；

S5、对全量同步及增量数据进入目标端数据库后出现的重复数据进行去重；

S6、继续进行数据捕获和数据投递，进行后续的增量同步。

步骤S5中，只进行全量同步时不会出现数据重复，但是在全量同步不停机、全量和增量内容均要进入目标端数据库的情况下，全量数据进入目标端数据库一次，增量数据紧接着进入目标端数据库，两次数据进入目标端数据库会造成部分数据重复。

进一步的，步骤S4中，临时储存区的消息消费完毕的判断方法如下：

判断最后一条消息的偏移量maxoffset与消费完成返回的确认消息的偏移量commitoffset是否一致，若一致时，标志临时储存区消息消费完毕。

进一步的，步骤S5中，对全量同步过程中产生的重复数据进行去重的具体步骤如下：

S71、根据目标端数据库表中的数据ID分组，相同的ID分为一组；

S72、根据分组后组内总条数大于1的ID找出重复数据，并将每个ID的对应的重复数据重新存入一个临时表中；

S73、为临时表增加一个row_number列，所述row_number列中的序号依次递增，为重复数据增加一个序列号；

S74、删除目标端数据库中的重复数据，并通过序列号选出重复数据中的一条插入目标端数据库中。

另一方面，本申请还提出一种基于源库不停机的异构数据库增量同步系统，包括数据捕获组件、数据投递组件、队列中间件kafka、管理组件、去重组件；

所述数据捕获组件通过管理组件控制启动，所述数据捕获组件用于监控源端数据库的最新变化，捕获增量内容，并将增量内容发送到队列中间件kafka中；

所述管理组件用于启动全量同步任务、设置递增序列号，全量过程和增量过程中均设置递增序列号，全量过程中的递增序列号记录源端数据库改变次数，同时，增量过程中的递增序列号记录增量数据捕获次数；

全量同步任务完成后，所述管理组件会返回全量过程中源端数据库改变的次数；

全量过程中设置递增序列号在每次源端数据库改变后增加一，同时增量过程中设置的递增序列号记录增量数据捕获次数，当捕获次数大于改变次数时，标志数据捕获组件捕获增量数据完成，捕获增量数据完成后，所述管理组件会返回捕获完成的信号；

所述数据投递组件通过管理组件启动，将队列中间件kafka中存入的增量内容全部存储到目标端数据库中，确保队列中间件kafka的消息消费完毕；

设置去重组件对全量同步过程中产生的重复数据进行去重；

去重结束后，通过管理组件启动数据捕获组件和数据投递组件，进行后续的增量同步。

进一步的，队列中间件kafka的消息消费完毕判断方法：

判断最后一条消息的偏移量maxoffset与消费完成返回的确认消息的偏移量commitoffset是否一致，若一致时，队列中间件kafka的消息消费完毕。

进一步的，去重组件对全量同步过程中产生的重复数据进行去重的方法如下：

根据目标端数据库表中的数据ID分组，相同的ID分为一组；

根据分组后组内总条数大于1的ID找出重复数据，并将每个ID的对应的重复数据重新存入一个临时表中；

为临时表增加一个row_number列，所述row_number列中的序号依次递增，为重复数据增加一个序列号；

删除目标端数据库中的重复数据，并通过序列号选出重复数据中的一条插入目标端数据库中。

进一步的，所述数据捕获组件是以操作日志的形式记录源端数据库的变化。

相对于现有技术，本发明所述的一种基于源库不停机的异构数据库增量同步方法及系统具有以下有益效果：

(1)本发明所述的临时储存区保证全量内容先进入目标端数据库，增量内容后进入目标端数据库，防止增量内容先进入目标端数据库在空表上执行sql语句，之后全量内容进入目标端数据库，导致增量内容没生效的问题发生，保证数据有效性。

(2)本发明所述的全量同步完成并将全量过程中增量同步到目标库后，可能会产生重复数据，通过相同ID识别重复数据，借助临时表去重，减少垃圾数据。

附图说明

构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明实施例所述的一种基于源库不停机的异构数据库增量同步方法流程图；

图2为本发明实施例所述的一种基于源库不停机的异构数据库增量同步系统框图；

图3为本发明实施例所述的数据去重流程图。

具体实施方式

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”等的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以通过具体情况理解上述术语在本发明中的具体含义。

下面将参考附图并结合实施例来详细说明本发明。

如图1所示，本申请提出一种基于源库不停机的异构数据库增量同步方法，将源端数据库内容存到目标端数据库中，具体步骤如下：

S6、继续进行数据捕获和数据投递，进行后续的增量同步。

步骤S4中，临时储存区的消息消费完毕的判断方法如下：

步骤S5中，对全量同步过程中产生的重复数据进行去重的具体步骤如下：

S72、根据分组后组内总条数大于1的ID找出重复数据，并将每个ID对应的重复数据重新存入一个临时表中；

S74、删除目标端数据库中的重复数据，并在每组重复数据中通过序列号选出任意一条数据插回目标数据库中。

如图2所示，另一方面，本申请还提出一种基于源库不停机的异构数据库增量同步系统，包括数据捕获组件，数据投递组件，队列中间件kafka，管理组件、去重组件。

可以在管理组件中去启停任意组件，监控任意组件的执行结果，管理组件是所有组件的执行窗口，其他功能组件是每个具体任务的执行者。其中，数据捕获组件担任全量同步过程中捕获产生的增量内容；队列中间件kafka担任临时缓存捕获到的增量内容；数据投递组件担任同步内容的进入目标端数据库任务。通过这些组件协同完成了源库不停机的全量同步，主要流程包括如下几个步骤：

步骤1、启动管理组件；

步骤2、在管理组件中启动数据捕获组件，捕获增量内容；

步骤3、在管理组件中启动全量同步任务；

步骤4、等待管理组件返回全量同步结束的信号；

步骤5、等待管理组件返回增量捕获完成的信号；

步骤6、在管理组件中开启数据投递组件；

步骤7、启动去重组件，进行数据去重；

步骤8、开启数据捕获和投递组件，进行后续的增量同步。

步骤1、启动管理组件

管理组件是所有组件的窗口，监控其他组件，并且会给我们返回其他组件的执行结果，开启管理组件是所有操作的前提。在管理组件上，可以按照自己的启停要求去管理其他组件，并且可以获取我们需要的临界条件。

步骤2、在管理组件中启动数据捕获组件，捕获增量内容

在管理组件上启动数据捕获组件，数据捕获组件用于监控源端数据库的最新变化，记录增量内容，数据捕获组件是以操作日志的形式记录源端数据库的变化，开启数据捕获组件可以保证源端数据不停机，进行数据库增量同步。

数据捕获组件的下游组件是队列中间件kafka，把源端数据库的增量内容发到队列中间件kafka，是为了解决源库不停机全量同步过程出现的数据不一致问题。

例如，源端数据库table1表有一条数据a＝1，如果业务场景会修改这条数据，将a修改成2，那么数据捕获组件会捕获到这样一条日志，sql如下：

update table1 set a＝2where a＝1；

其中table1是表名，a是字段名称。如果没有引入队列中间件kafka，增量内容直接进入目标端数据库，全量内容没有进入目标端数据库，则目标端数据库是空表。增量内容进入目标端数据库会执行上面的sql，没有数据只能空执行。直到全量内容进入目标端数据库时，目标端数据会有一条未被修改过的a＝1的数据，而源端数据库已经被业务修改成了a＝2，至此，源端数据库和目标端数据就出现了数据不一致现象。所以，我们把增量内容暂时放在队列中间件kafka中，并且关闭数据投递组件，这样队列中间件kafka中存储消息是不会被消费的。当我们收到管理组件全量同步完成的信号，再放开数据投递组件，这样就可以保证增量内容是后于全量内容进入目标端数据库的。那么，就不会出现上述增量记录的sql日志在空表执行，造成数据不一致的现象。

步骤3、在管理组件中启动全量同步任务

在管理组件中启动全量同步任务。通常，在传统技术中，启动全量同步的时候，需要关闭数据捕获组件，即让数据库处于一个静态的状态，等待全量同步完成后开启增量同步。而本申请在开启全量任务之前已经开启了数据捕获组件，就是让源端数据库处于一个源库不停机的状态。

步骤4、等待管理组件返回全量同步结束的信号

管理组件会记录全量同步的执行结果，还会记录全量过程中的增量改变次数。用一个递增的递增序列号记录改变次数，每次改变递增序列号增加一。当全量内容同步完毕，管理组件会返回全量同步完成和全量过程源端数据库修改的次数，即上面提到的递增的递增序列号。

步骤5、等待管理组件返回增量捕获完成的信号

管理组件会记录下全量过程中源端数据库的变化次数，它是用一个递增的递增序列号表示的，每次改变递增序列号增加一。之所以引入这样一个序列号，是为了解决数据重复的问题，因为开启数据投递的时机会影响后面的去重。

比如，当数据捕获组件没有完全捕获完毕，即没有把全量过程中业务产生的增量内容全部捕获到，这时候开启数据投递组件。那么后续的去重工作只会将全量内容和捕获不完全的内容重复部分消除掉，当全量同步结束后，全量过程中遗留的增量内容进入目标端数据库，那么，这部分遗留的增量内容和全量内容很有可能会有重复的部分，但是去重工作已经结束了，所以会造成去重不彻底。

为了解决去重不彻底的问题，必须确保全量过程中的增量内容全部捕获完毕，全量过程中设置递增序列号在每次源端数据库改变后增加一，同时增量过程中设置递增序列号记录增量数据捕获次数，只有当增量过程中递增序列号大于全量过程中递增序列号时，才标志着数据捕获完毕，才能开启下游的数据投递组件，从而确保不会出现去重不彻底的问题。

在管理组件中开启数据投递组件，开启的临界条件就是增量的序列号大于全量的序列号。管理组件会根据是否达到临界条件给出反馈，不需要自己去比较。

步骤6、在管理组件中开启数据投递组件

在管理组件中开启数据投递组件，这一步骤主要是消费队列中间件kafka里的消息，完成增量内容进入目标端数据库。这一步要求确保消息消费完毕，不造成数据丢失。通过比对maxoffset与commitoffset值是否一致，判断是否全部消费完成。maxoffset代表最后条消息的偏移量，commitoffset表示消费完成返回的确认消息的偏移量。当两者一致时，标志消息消费完毕。

如图3所示，步骤7、启动去重组件，进行数据去重

在管理组件中开启去重组件，数据去重是为了解决源库不停机的全量过程中产生的重复数据，解决的具体思路，用下面一个实例说明。

假如全量同步过程完成，同步到目标端数据库表结构和数据如下，查询出t1表的全部数据，可以看出有两条重复数据。

gbase>select*from t1；

此时，需要找出t1表的重复数据，然后将重复数据存到一个临时表中，并且为临时表增加一个row_number列，就是一个递增序号，通过下面的sql语句完成上面的过程。

create table t1_tmp as select row_number()over(partition by id orderby id)as PK,t.*from t1 t where t.id in(select id from t1 group by id havingcount(1)>1)；

其中t1_tmp是临时表名，PK是递增序号的别名，t是t1表的别名，t.*表示t1表的所有字段。我们判重的条件是数据id重复，select id from t1 group by id having count(1)>1表示根据id分组，相同id的分为一组，找出分组后组内总条数大于1的分组id。找出重复数据后，存入临时表，查询出临时表的内容。

gbase>select*from t1_tmp；

可以看出，临时表保存着目标端t1表的两条重复数据，并且给每条数据加了一个序列号PK。

删除目标端t1表的重复数据，通过下面的sql语句实现。

delete t1 t where t.id in(select id from t1 group by id having count(1)>1)；

其中判重条件和上述临时表找出重复数据的条件一致。删除重复数据后，再查询一下t1的全部内容。

gbase>select*from t1；

可以看出，t1表的重复数据确实已经被删除，但是此时就相当于少了这条重复数据，必须把重复数据去重后插入回去，通过如下的sql实现。

insert into t1 select id,n1,n2 from t1_tmp where PK＝2；

选择将PK＝2的数据插入回去，理论上重复数据只会出现两条一样，不会出现三条甚至更多，因为产生重复只会是增量内容和全量内容的重复，即两者出现相同部分。所以，只需要选出一条插入回去即可，这里实例选择的是PK＝2，也可以选择PK＝1。去重流程完毕后，最后查看一下t1表的内容。

gbase>select*from t1；

以上实例就是去重的全部过程和思路。主要内容找出重复数据后将重复数据缓存在临时表，然后删除原表的重复数据，最后将去重后的重复数据新增回原表。

步骤8、开启数据捕获和投递组件，进行后续的增量同步

上述步骤完成后，其实已经实现了源库不停机的全量同步。这里，同时开启数据捕获和投递组件，是为了后续的增量同步。因为已经完成了全量同步，后续源端的业务是通过增量同步完成的数据同步。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种基于源库不停机的异构数据库增量同步方法，将源端数据库内容存到目标端数据库中，其特征在于：具体步骤如下：

S6、继续进行数据捕获和数据投递，进行后续的增量同步。

2.根据权利要求1所述的一种基于源库不停机的异构数据库增量同步方法，其特征在于：步骤S4中，临时储存区的消息消费完毕的判断方法如下：

3.根据权利要求1所述的一种基于源库不停机的异构数据库增量同步方法，其特征在于：步骤S5中，对全量同步过程中产生的重复数据进行去重的具体步骤如下：

4.一种基于源库不停机的异构数据库增量同步系统，其特征在于：包括数据捕获组件、数据投递组件、队列中间件kafka、管理组件、去重组件；

设置去重组件对全量同步过程中产生的重复数据进行去重；

5.根据权利要求4所述的一种基于源库不停机的异构数据库增量同步系统，其特征在于：队列中间件kafka的消息消费完毕判断方法：

6.根据权利要求4所述的一种基于源库不停机的异构数据库增量同步系统，其特征在于：去重组件对全量同步过程中产生的重复数据进行去重的方法如下：

根据目标端数据库表中的数据ID分组，相同的ID分为一组；

根据分组后组内总条数大于1的ID找出重复数据，并将每个ID对应的重复数据重新存入一个临时表中；

7.根据权利要求4所述的一种基于源库不停机的异构数据库增量同步系统，其特征在于：所述数据捕获组件是以操作日志的形式记录源端数据库的变化。