CN107958010B - 用于在线数据迁移的方法及系统 - Google Patents

Abstract

本发明公开的是关于一种用于在线数据迁移的方法及系统，属于数据迁移技术领域。一种用于在线数据迁移的方法，包括：监听应用的待迁移数据中的待迁移增量数据的二进制日志；根据所述二进制日志生成增量数据迁移消息；根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。本发明基于消息机制实现在线数据迁移。

Description

用于在线数据迁移的方法及系统

技术领域

本发明涉及数据迁移技术领域，尤其涉及一种用于在线数据迁移的方法及系统。

背景技术

数据库是以一定方式储存在一起、能为多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。在数据库使用过程中，当数据库的存储结构无法满足业务需求时，需要将数据库中的数据迁移到能够满足业务需求的新数据库中，这就涉及对大量数据进行迁移的问题。

传统数据迁移一般是离线的，但是为了不影响业务使用，出现了在线数据迁移技术，即在数据迁移过程中，仍允许业务线程访问数据库开展业务。

随着互联网行业的快速发展，人们的网上购物行为越来越普遍，用户的订单数据急剧暴增，几乎所有的在线运行的订单系统都面临着数据存储、检索、高并发的难题。一般在线订单系统的数据存储架构都在不断的进行升级改造，以电商平台虚拟商品相关的业务线为例，基本每个业务系统都在进行订单数据存储架构的升级改造，从单库单表的主从存储结构开始向多主多从、分库分表、分布式存储的方向升级。在进行订单数据存储架构水平、垂直切分的过程中基本上都面临着数据迁移的难题，数据迁移的高效、正确性直接关系到系统改造升级的成败。

相关技术中实现数据迁移有单机执行或者多机器数据并发执行。

单台机器的资源有限，导致单台机器执行数据迁移时间长、效率低，尤其是在单台机器执行大量数据迁移的时候。而目前一般线上的应用都是多机器、分布式的，单台机器迁移数据未能将线上的服务器资源加以合理利用。

但是多台机器并行执行数据迁移实现相对复杂。多台机器执行数据迁移，一般会考虑将迁移数据按照某个维度进行拆分，常规的方法会将迁移数据按ID(身份标识)进行取模，把待迁移的数据分成多个片，不同的机器迁移不同的分片数据，功能设计、实现上相对比较复杂。

另一方面，线上的应用的数据实时都在变化，一般把需要迁移的数据切分成历史数据(指已完成归档的数据、数据本身不变化)和增量数据(新产生的数据，包括新插入的及对老数据的修改)两部分分别来进行迁移。

历史数据迁移相对简单，其本身不会发生变化，迁移一次即可完成。增量数据迁移由于数据本身是变化的，很难保证增量迁移的正确性，实际操作中可能会涉及到应用停机、生产库停止写服务，导致迁移期间影响用户的正常使用。以上两部分数据迁移的正确性对系统升级改造的成败影响大、而且增量数据迁移的实现上难度大、风险高。

同时，上述迁移方案都和业务本身直接耦合，其通用性相对比较差，很难做到数据迁移功能的组件化、迁移功能重复利用率低，不同的业务系统执行相同的数据迁移功能都将涉及到大量的开发工作。

因此，需要一种新的用于在线数据迁移的方法及系统。

在所述背景技术部分公开的上述信息仅用于加强对本公开的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供一种用于在线数据迁移的方法及系统，用于至少部分地解决上述技术问题或者其他技术问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种用于在线数据迁移的方法，包括：

监听应用的待迁移数据中的待迁移增量数据的二进制日志；

根据所述二进制日志生成增量数据迁移消息；

根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。

在本公开的一种示例性实施例中，根据所述二进制日志生成增量数据迁移消息，包括：

解析所述二进制日志，获取所述待迁移增量数据的变更信息，所述变更信息包括发生更改的应用名、库名以及表名；

根据映射关系组装所述增量数据迁移消息，所述映射关系包括待迁移的应用名、库名以及表名。

在本公开的一种示例性实施例中，还包括：开启存储所述待迁移增量数据的数据库从库的二进制日志写入功能。

在本公开的一种示例性实施例中，所述二进制日志采用row模式。

在本公开的一种示例性实施例中，所述应用的待迁移数据还包括待迁移历史数据，所述方法还包括：

定时扫描所述待迁移历史数据生成历史数据迁移消息；

将所述历史数据迁移消息发送至所述应用的历史数据消息队列。

在本公开的一种示例性实施例中，还包括：当所述历史数据迁移消息发送至所述历史数据消息队列失败时，插入数据迁移任务，定时扫描所述数据迁移任务直至数据迁移成功。

在本公开的一种示例性实施例中，所述历史数据消息队列和所述增量数据消息队列共用同一消息队列。

在本公开的一种示例性实施例中，还包括：订阅所述消息队列，获取所述增量数据迁移消息和所述历史数据迁移消息，完成数据迁移。

在本公开的一种示例性实施例中，还包括：按照预设时间段比对预设信息校验所述待迁移数据和已完成迁移的数据之间的完整性。

根据本公开的一个方面，提供一种用于在线数据迁移的系统，包括：

监听模块，用于监听应用的待迁移数据中的待迁移增量数据的二进制日志；

消息生产模块，用于根据所述二进制日志生成增量数据迁移消息；

消息分发模块，用于根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。

在本公开的一种示例性实施例中，所述消息生产模块包括：

解析单元，用于解析所述二进制日志，获取所述待迁移增量数据的变更信息，所述变更信息包括发生更改的应用名、库名以及表名；

组装单元，用于根据映射关系组装所述增量数据迁移消息，所述映射关系包括待迁移的应用名、库名以及表名。

在本公开的一种示例性实施例中，所述应用的待迁移数据还包括待迁移历史数据，所述系统还包括：

扫描模块，用于定时扫描所述待迁移历史数据生成历史数据迁移消息；

消息发送模块，用于将所述历史数据迁移消息发送至所述应用的历史数据消息队列。

在本公开的一种示例性实施例中，还包括：迁移模块，用于订阅所述增量数据消息队列和所述历史数据消息队列，获取所述增量数据迁移消息和所述历史数据迁移消息，完成数据迁移。

根据本公开的一个方面，提供一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

监听应用的待迁移数据中的待迁移增量数据的二进制日志；

根据所述二进制日志生成增量数据迁移消息；

根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。

根据本公开的用于在线数据迁移的方法及系统，基于消息机制驱动数据迁移功能。

另一方面，本公开的用于在线数据迁移的方法及系统，通过Java的多线程技术执行迁移功能，能够实现多台机器、并发执行数据迁移，最大化的利用线上所有服务器资源来执行数据迁移任务。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1示意性示出根据本公开示例实施方式的一种用于在线数据迁移的方法的流程图；

图2示意性示出根据本公开示例实施方式的另一种用于在线数据迁移的方法的流程图；

图3示意性示出根据本公开示例实施方式的又一种用于在线数据迁移的方法的流程图；

图4示意性示出根据本公开示例实施方式的再一种用于在线数据迁移的方法的流程图；

图5示意性示出根据本公开示例实施方式的一种用于在线数据迁移的系统的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、系统、步骤等。在其它情况下，不详细示出或描述公知结构、方法、系统、实现、材料或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器系统和/或微控制器系统中实现这些功能实体。

以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的系统和方法的例子。

一般而言，互联网应用在为用户提供业务或服务的过程中，都需要数据库的支持。例如，电子商务交易平台中，需要在数据库中保存卖家用户上传的商品对象的描述、库存信息、买家的订单信息等等。

在数据库的使用过程中，经常面临数据迁移的情况，例如当数据库的存储结构无法满足业务需求，需要将数据库中的数据迁移到能够满足业务需求的新数据库，或者当数据库因扩容，需要将数据库中的数据迁移到容量更大的新数据库，等等。为便于描述，将之前存储数据的数据库称为原数据库。本实施例提供的方法适用于各种需要进行数据库迁移的情况。

数据迁移是指将数据从一台机器迁移到另一台机器，或者将数据从一个数据库迁移到另一个数据库，并且这些数据(包括结构定义)在转移后能正常运行。

图1示意性示出根据本公开示例实施方式的一种用于在线数据迁移的方法的流程图。

如图1所示，该用于在线数据迁移的方法包括以下步骤。

在步骤S102中，监听应用的待迁移数据中的待迁移增量数据的二进制日志。

这里的待迁移增量数据是指数据库中新产生的数据，包括新插入的数据和/或对数据库中已有数据的更改。

其中所述二进制日志(binary log，简称为binlog)，记录了对数据库(例如，MySQL)的更改操作，例如：创建数据库或表(create)、插入操作(insert)、更新操作(update)、删除操作(insert)等，每个更改操作都以一条记录的形式写入二进制日志文件中，每条记录中都包含了当前记录更新的时间戳、该记录在当前二进制日志文件中的位置(即：偏移量)以及与数据库更改操作相关的其他信息。MySQL数据库通常有一个或者多个二进制日志文件，不同的二进制日志文件通过文件扩展名采用不同的数字编号形式加以区分，例如：mysql-bin.00001。

在示例性实施例中，该方法还包括：开启存储所述待迁移增量数据的数据库从库的二进制日志写入功能。

其中对于一个高可用的在线应用的数据库一般都是主从结构，包括对外提供读写服务的主(master)数据库和数据库主库的一个或者多个从(slave)数据库。数据库主库可以包括一个或多个服务器，每个服务器一般可以具有一个区域管理单元，其中每个区域管理单元可以生成至少一个与增量数据相关的日志文件，该日志文件包括：要更改数据的内容、要更改数据写入数据库主库的时间信息(或被更改的时间信息)；当数据被更改时(例如，要迁移数据因被进行写操作而被更改时)，该区域管理单元可以将更改后的数据及更改的时间等写入日志文件中，该区域管理单元可以用于处理用户对数据库主库中数据的读写请求。

还是以MySQL数据库为例，本发明实施例将把应用的MySQL数据库从库开启binlog写入功能。这样，当数据库从库上执行数据更新动作时，会相应的将数据库从库的更改操作记录在所述二进制日志binlog中。可以通过在MySQL时指定--log-bin[＝base_name]参数启用数据库从库的binlog。本发明实施例通过配置数据库从库的binlog写入功能，可以实现在迁移增量数据时不影响数据库主库的读写性能。

在示例性实施例中，所述二进制日志采用row模式。

MySQL binlog日志有三种模式：statement、mixed以及row，其中statement只有sql，没有数据，所以无法获取原始的变更日志。row模式的binlog日志会把所有的执行的语句以每行记录的修改来进行记录，比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录。row模式下，binlog中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以row模式下的日志内容会非常清楚的记录下每一行数据修改的细节。且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。

为了能获取数据库的变更信息，本发明实施例可以采取row模式的方式来配置数据库从库的binlog。

在步骤S104中，根据所述二进制日志生成增量数据迁移消息。

在示例性实施例中，所述根据所述二进制日志生成增量数据迁移消息，包括：解析所述二进制日志，获取所述待迁移增量数据的变更信息，所述变更信息包括发生更改的应用名、库名以及表名；根据映射关系组装所述增量数据迁移消息，所述映射关系包括待迁移的应用名、库名以及表名。

关系型数据库中，数据的一条记录往往由多个字段的信息组成，因此在将待迁移数据从原数据库迁移到新数据库的过程中，可以从各个字段中选取出需要关注的内容，可以包括待迁移数据对应的应用名(例如应用A、应用B等)、数据库的库名、数据库中数据表的表名等。

数据库一般包含多个数据表。具体的，当需要进行数据迁移时，本发明实施例可以不按照数据的存储时间，从最早数据开始进行数据迁移，而是先确定目标业务以及开展目标业务所需的待迁移数据，以便于从业务需求角度进行数据迁移，提高数据迁移的灵活度。例如，假设应用A需要迁移的数据是订单表数据，则可以事先存储应用A的应用名(应用A)、应用A的数据库的库名、应用A的数据库中对应的订单表表名的映射关系，当解析到增量数据时，根据该映射关系判断其是否是订单表，如果是订单表数据，则生成对应的应用A的增量数据迁移消息；如果不是订单表，则可以不生成应用A的增量数据迁移消息。再例如，假设应用B需要迁移的数据是用户表数据，则可以事先存储应用B的应用名(应用B)、应用B的数据库的库名、应用B的数据库中对应的用户表表名的映射关系，当解析到增量数据时，根据该映射关系判断其是否是用户表，如果是用户表数据，则生成对应的应用B的增量数据迁移消息；如果不是订单表，则可以不生成应用B的增量数据迁移消息。

在示例性实施例中，解析所述二进制日志可以采用canal技术，但本公开不以此为限。

在示例性实施例中，所述根据映射关系组装所述增量数据迁移消息还包括：消息体报文设计。

消息订阅者需要根据消息体从应用对应的数据库(不同的应用可以设置为对应不同的数据库)中找到对应的数据迁移记录，根据此需求以订单表t_order为例，设计了如下通用消息体示例：{"tableName"："t_order","primaryKey"：1000000001}。下面的历史数据迁移消息也可以采用相同的消息体报文设计。

在一实施例中，该消息体报文可以统一采用Json(JavaScript Object Notation)格式。Json是一种轻量级的数据交换格式。

在步骤S106中，根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。

在示例性实施例中，可以采用消息中间件的消息队列来存储所述增量数据迁移消息。其中所述消息中间件是采用异步方式在消息生产者和消息订阅者间传送消息的系统。例如，可以采用Active Mq、Apache Kafka等，本公开可以采用任意能够实现本发明目的的消息中间件。

在示例性实施例中，同一消息中间件中可以包括多个消息队列，可以将不同应用的增量数据迁移消息分别发送至不同的消息队列。所述消息分发策略可以根据解析所述二进制日志获取到的数据库库名来区分对应的所述增量数据迁移消息应该发送到哪个增量数据消息队列。

在示例性实施例中，所述应用的待迁移数据还包括待迁移历史数据，所述方法还包括：定时扫描所述待迁移历史数据生成历史数据迁移消息；将所述历史数据迁移消息发送至所述应用的历史数据消息队列。

这里的待迁移历史数据是指已完成归档的数据，数据本身不再发生变化。在一实施例中，可以将应用数据库中的所有待迁移数据均视为待迁移历史数据，将待迁移历史数据迁移完成后，再根据待迁移增量数据更改已迁移到新数据库中的历史数据。在另一实施例中，可以根据数据的生成时间划分为历史数据和增量数据。例如，可以设置2015年12月31日之前的订单数据为待迁移历史数据，设置2016年1月1日之后的订单数据为待迁移增量数据。

在示例性实施例中，Java的应用在进行数据迁移的时候可以采用线程(thread)技术，设定一依赖Java线程实现的定时任务(worker)定时扫描所述待迁移历史数据生成历史数据迁移消息。

在示例性实施例中，还包括：当所述历史数据迁移消息发送至所述历史数据消息队列失败时，插入数据迁移任务，定时扫描所述数据迁移任务直至数据迁移成功。

在示例性实施例中，所述历史数据消息队列和所述增量数据消息队列共用同一消息队列。在其他实施例中，所述历史数据消息队列和所述增量数据消息队列也可以不共用同一消息队列。

在示例性实施例中，还包括：订阅所述消息队列，获取所述增量数据迁移消息和所述历史数据迁移消息，完成数据迁移。这样可以使历史数据消息订阅者也能完成增量数据迁移，实现了数据迁移消息订阅者的共用。

在一实施例中，当所述历史数据消息队列和所述增量数据消息队列不共用同一消息队列时，可以仅订阅所述历史数据消息队列获取所述历史数据迁移消息，完成历史数据迁移，或者仅订阅所述增量数据消息队列获取所述增量迁移消息，完成增量数据迁移。

以待迁移迁移的订单表t_order为例，下面为该订单表的字段结构：

字段名称	字段标识符	备注
			主键primaryKey	ID	订单表的主键，全局唯一
用户名	user_pin	订单所属用户唯一标示
			订单状态	status	订单状态
……	……	……

假设应用A通过订阅获取数据迁移消息(包括所述增量数据迁移消息和/或所述历史数据迁移消息)，根据消息体中的表名tableName字段对应的值：“t_order”，可以路由到待迁移数据存在应用A数据库的订单表t_order中；然后再根据消息体中的主键primaryKey字段对应的值：1000000001；可以最终查询到具体的迁移记录并完成数据迁移。

在示例性实施例中，还包括：按照预设时间段比对预设信息校验所述待迁移数据和已完成迁移的数据之间的完整性。

在一实施例中，可以通过比较迁移之前的原数据库和迁移之后的新数据库中的数据来校验在迁移过程中数据是否有缺失以及数据是否不完整。这种一一比对的数据迁移校验涉及到原待迁移数据和已迁移完成的数据对比，性能上开销比较大。

在本发明实施例中，可以采用Java多线程技术，针对不同的业务数据校验其主要业务的字段，以订单业务为例进行说明，可以按照所述预设时间段(例如，天)校验迁移前后的订单总条数、订单总金额、订单状态等关键字段的比对，对迁移完成的数据校验其正确性。

在示例性实施例中，还包括：当上述按照预设时间段比对预设信息校验所述待迁移数据和已完成迁移的数据之间的完整性时，出现数据校验异常的情况，可以根据校验异常出现的日期，缩小数据重复迁移范围，根据历史数据迁移条件配置(按日期、表主键ID进行迁移)可以重复将检验未通过的数据进行再次迁移，直至数据校验通过。

本发明实施方式提供的用于在线数据迁移的方法，一方面，基于数据库binlog日志实现了增量数据迁移，且增量数据迁移功能能够复用于不同的应用，数据迁移多机器并发执行效率高、开发工作量小、风险可控。另一方面，基于消息机制驱动数据迁移，从而无需对待迁移的数据进行拆分，所有待迁移的数据都是同等的，把数据拆分的功能从业务系统解耦出来，简化了数据迁移多台机器并行执行的方案，提出了一种高效的、平滑过渡的订单存储架构改造过程中面临的数据迁移解决方法。

图2示意性示出根据本公开示例实施方式的另一种用于在线数据迁移的方法的流程图。

如图2所示，该用于在线数据迁移的方法包括以下步骤。

在步骤S202中，监听应用的待迁移数据中的待迁移增量数据的二进制日志。

在步骤S204中，解析所述二进制日志，获取所述待迁移增量数据的变更信息，所述变更信息包括发生更改的应用名、库名以及表名。

在本发明实施例中，可以通过数据库binlog解析中间件，对数据库的binlog日志进行监听，提取数据库的变更信息进行解析获取增量数据，根据解析结果(例如应用名、库名、表名、主键等)组装增量数据变更信息并分发至消息中间件的相应消息队列。

增量数据迁移的消息生产者，需要实现配置化，因为不同的应用所迁移的数据表物理表各异，针对这个需求，数据库binlog解析中间件需要维护应用名、库名、待迁移数据的表名的映射关系，当解析到增量数据之后，根据映射关系组装增量数据迁移消息，调用消息生产者接口(API)将增量数据迁移消息发送至消息中间件(消息平台)。

在步骤S206中，根据映射关系组装所述增量数据迁移消息，所述映射关系包括待迁移的应用名、库名以及表名。

在步骤S208中，根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。

在步骤S210中，消息订阅者订阅所述增量数据消息队列，执行增量数据迁移。

这样各业务系统只需要订阅数据迁移的增量数据消息队列即可完成增量数据迁移。

本发明实施例中其他内容参考上述发明实施例的内容，在此不再赘述。

本发明实施方式提供的用于在线数据迁移的方法，通过监听应用数据库的待迁移增量表binlog信息，提取binlog变化信息，解析binlog信息，然后根据解析结果组装增量数据迁移消息，再将该增量数据迁移消息分发至消息平台相应应用的消息队列，应用通过订阅该消息队列获取到该增量数据迁移消息即可完成增量数据的迁移。

图3示意性示出根据本公开示例实施方式的又一种用于在线数据迁移的方法的流程图。

如图3所示，该用于在线数据迁移的方法包括以下步骤。

在步骤S302中，所述应用的待迁移数据还包括待迁移历史数据，定时扫描所述待迁移历史数据生成历史数据迁移消息。

本发明实施例可以实现历史数据迁移条件配置化，即不同的应用可以根据业务系统的特点灵活配置历史数据迁移条件，例如可以按日期、表主键ID等进行迁移。可以通过设置定时任务负责逐条读取应用数据库中某一个原数据表的待迁移历史数据。

在步骤S304中，将所述历史数据迁移消息发送至所述应用的历史数据消息队列。

在本发明实施例中，可以设置历史数据迁移扫描Worker(依赖于Java线程实现的定时任务)扫描待迁移历史数据，根据数据迁移消息体报文设计，组装历史数据迁移消息体，通过消息生产者调用消息中间件客户端API(消息中间件客户端与服务端通信的接口)，由消息生产者将历史数据迁移消息发送至消息平台。

在步骤S306中，判断该历史数据迁移消息是否发送成功。当消息发送成功时，进入步骤S308；当消息发送失败时，跳转到步骤S310。

在步骤S308中，消息订阅者订阅所述历史数据消息队列，执行历史数据迁移。跳转到步骤S314判断迁移是否成功。

在步骤S310中，插入数据迁移任务。

在本发明实施例中，当该历史数据迁移消息发送消息平台失败时，则可插入数据迁移任务，由迁移异常补漏Worker扫描该数据迁移任务直至数据迁移成功，该机制保证了数据迁移的完整性，同时也解决了消息发送过程中的异常情况。类似的，上述增量数据迁移消息发送至消息平台失败时，也可以采取相同的措施，即消息发送失败时可不采用消息机制实现数据迁移，而是采用直接在相应的应用的数据库中的任务表中写入一数据迁移任务，定时扫描该任务表执行该数据迁移任务。

存储待迁移数据的原应用数据库一般包含多个数据表，每个数据迁移任务对应原应用数据库中一个原数据表进行数据迁移的迁移任务。可以通过表配置文件来配置多个数据迁移任务对应的任务信息。

例如可以使用xml格式表配置文件来配置多个数据迁移任务对应的任务信息。对应每个数据迁移任务，表配置文件都包括源配置和目标配置。在每个数据迁移任务中，源配置给出了原应用数据库中需要迁移的原数据表的信息，目标配置给出了要把需要迁移的原数据表迁往的新数据库中的目标数据表的信息。具体地，源配置可包括原应用数据库中需迁移的数据表的原表名、切分字段、分库字段以及原表列和原表主键等信息。目标配置具体可包括将写入新数据库中的目标数据表的目标表名、目标表列以及目标表主键等信息。通过在表配置文件中填写原表名、目标表名等信息，即可实现一个数据迁移任务的配置。

确定在特定时间段内待迁移历史数据以及所述待迁移历史数据对应的应用；将所述待迁移历史数据迁移到目标存储区(一般情况下，可以是在原来的数据库基础上新增的数据库，也即将待迁移历史数据迁移到新增的其他数据库中。这里需要说明的是，新增的其他数据库可能是多个，并且一个数据库中可能存在多个表，此时，在将待迁移历史数据迁移到这些数据库时，需要首先确定好应该将当前的待迁移历史数据迁移到哪个数据库中的哪张表。具体实现时，可以根据待迁移历史数据的ID、新增数据库的数目、每个数据库中包含的表的数目这些信息来确定)。

在步骤S312中，定时扫描所述数据迁移任务，执行历史数据迁移。进入步骤S314判断迁移是否成功。

在步骤S314中，判断数据迁移是否成功；当数据迁移成功时，进入步骤S316；当数据迁移失败时，跳回到步骤S310插入数据迁移任务。

在本发明实施例中，历史数据迁移扫描worker主要定时扫描待迁移历史数据并生成迁移消息，若消息发送失败或迁移失败都将插入数据迁移任务，然后通过迁移异常补漏worker扫描该数据迁移任务直到数据迁移完成。

在步骤S316中，历史数据迁移完成。

本发明实施方式提供的用于在线数据迁移的方法，通过设置定时任务扫描待迁移历史数据生成迁移消息并发送至消息平台，消息消费者订阅消息队列即可实现基于消息机制的数据迁移；同时，还能够实现在消息发送至消息平台失败或者数据迁移失败时的补救措施，通过插入数据迁移任务并定时扫描该插入的数据迁移来保证数据迁移的完整性。

图4示意性示出根据本公开示例实施方式的再一种用于在线数据迁移的方法的流程图。

如图4所示，以两个应用(应用A和应用B)对本发明实施例提供的用于在线数据迁移的方法进行举例说明。需要说明的是，虽然图4所示的实施例中仅例举了两个应用，但实际该方法可以应用于任意多个应用，本公开对此不作限定。

首先将应用A待迁移数据划分为应用A待迁移历史数据和应用A待迁移增量数据，应用B待迁移数据划分为应用B待迁移增量数据和应用B待迁移历史数据。然后，定时任务扫描应用A待迁移历史数据生成应用A历史数据迁移消息，同时定时任务扫描应用B待迁移历史数据生成应用B历史数据迁移消息，并将该应用A历史数据迁移消息和该应用B历史数据迁移消息分发至消息中间件的应用A数据迁移消息队列和应用B数据迁移消息队列(这里假设增量数据消息队列和历史数据消息队列共用一个消息队列)。此时，应用A待迁移增量数据和应用B待迁移增量数据通过数据库二进制日志解析中间件(该解析中间件对增量数据的binlog进行监听、解析、组装消息及分发操作，具体参见上述实施例)分别生成应用A增量数据迁移消息和应用B增量数据迁移消息。该数据库二进制日志解析中间件分别将该应用A增量数据迁移消息和该应用B增量数据迁移消息分发至消息中间件的该应用A数据迁移消息队列和该应用B数据迁移消息队列。接着，应用A消息订阅者可以通过订阅该应用A数据迁移消息队列完成应用A的数据迁移，应用B消息订阅者可以通过订阅该应用B数据迁移消息队列完成应用B的数据迁移。

本发明实施方式提供的用于在线数据迁移的方法，基于消息驱动数据迁移，根据以上系统架构设计，将应用A、应用B待迁移的数据分为历史数据、增量数据两部分，一方面，历史数据单独开发生产迁移消息的worker，该worker生产并向消息平台应用A对应的消息队列发送历史数据迁移消息，数据迁移多机器并发执行效率高、开发工作量小、风险可控；另一方面，增量数据一直处于变化的状态，通过数据库binlog解析中间件对binlog日志进行监听，提取信息、解析、组装增量数据变更消息以及通过消息分发策略将不同应用的变更消息发至消息队列，应用A、应用B分别订阅数据迁移消息队列，最终由消息订阅者完成数据迁移任务。通过对数据库二进制日志的监听、提取、解析等进行模块化，不同的业务系统不用单独建立binlog解析应用，从而简化了增量数据迁移的流程。此外，通过解析数据库的binlog保证了数据变化的完整性，对于增量数据的每一次变化都能够提取到，从而保证了增量数据迁移的正确性，降低了迁移风险。

图5示意性示出根据本公开示例实施方式的一种用于在线数据迁移的系统的框图。

如图5所示，该用于在线数据迁移的系统100包括：监听模块12、消息生产模块14以及消息分发模块16。

其中监听模块12用于监听应用的待迁移数据中的待迁移增量数据的二进制日志。

消息生产模块14用于根据所述二进制日志生成增量数据迁移消息。

消息分发模块16用于根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。

在示例性实施例中，消息生产模块14包括：解析单元142，用于解析所述二进制日志，获取所述待迁移增量数据的变更信息，所述变更信息包括发生更改的应用名、库名以及表名；组装单元144，用于根据映射关系组装所述增量数据迁移消息，所述映射关系包括待迁移的应用名、库名以及表名。

在示例性实施例中，所述应用的待迁移数据还包括待迁移历史数据，所述系统100还包括：扫描模块18，用于定时扫描所述待迁移历史数据生成历史数据迁移消息；消息发送模块110，用于将所述历史数据迁移消息发送至所述应用的历史数据消息队列。

在示例性实施例中，所述系统100还包括：迁移模块112，用于订阅所述增量数据消息队列和所述历史数据消息队列，获取所述增量数据迁移消息和所述历史数据迁移消息，完成数据迁移。

关于上述实施例中的系统，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

进一步的，本公开实施方式还提供一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器。

所述处理器可被配置为：监听应用的待迁移数据中的待迁移增量数据的二进制日志；根据所述二进制日志生成增量数据迁移消息；根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。

例如，电子设备可以是智能手机，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

在示例性实施例，电子设备可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

一种非临时性计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行一种用于在线数据迁移的方法，所述方法包括：监听应用的待迁移数据中的待迁移增量数据的二进制日志；根据所述二进制日志生成增量数据迁移消息；根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列。

图1、2、3和4示出根据本公开示例实施方式的用于在线数据迁移的方法的流程图。该方法可例如利用如图5所示的用于在线数据迁移的系统实现，但本公开不限于此。需要注意的是，图1、2、3和4仅是根据本公开示例实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，图1、2、3和4所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块/进程/线程中同步或异步执行的。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

以上具体地示出和描述了本公开的示例性实施方式。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (13)

1.一种用于在线数据迁移的方法，其特征在于，包括：

监听应用的待迁移数据中的待迁移增量数据的二进制日志；

根据所述二进制日志生成增量数据迁移消息；

根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列；

根据所述二进制日志生成增量数据迁移消息，包括：

解析所述二进制日志，获取所述待迁移增量数据的变更信息，所述变更信息包括发生更改的应用名、库名以及表名；

根据映射关系组装所述增量数据迁移消息，所述映射关系包括所述待迁移数据对应的应用名、库名以及表名，当所述发生更改的应用名、库名以及表名分别与所述映射关系中的应用名、库名以及表名相同时，则生成所述应用的增量数据迁移消息。

2.根据权利要求1所述的方法，其特征在于，还包括：

开启存储所述待迁移增量数据的数据库从库的二进制日志写入功能。

3.根据权利要求2所述的方法，其特征在于，所述二进制日志采用row模式。

4.根据权利要求1所述的方法，其特征在于，所述应用的待迁移数据还包括待迁移历史数据，所述方法还包括：

定时扫描所述待迁移历史数据生成历史数据迁移消息；

将所述历史数据迁移消息发送至所述应用的历史数据消息队列。

5.根据权利要求4所述的方法，其特征在于，还包括：

当所述历史数据迁移消息发送至所述历史数据消息队列失败时，插入数据迁移任务，定时扫描所述数据迁移任务直至数据迁移成功。

6.根据权利要求4所述的方法，其特征在于，所述历史数据消息队列和所述增量数据消息队列共用同一消息队列。

7.根据权利要求6所述的方法，其特征在于，还包括：

订阅所述消息队列，获取所述增量数据迁移消息和所述历史数据迁移消息，完成数据迁移。

8.根据权利要求7所述的方法，其特征在于，还包括：

按照预设时间段比对预设信息校验所述待迁移数据和已完成迁移的数据之间的完整性。

9.一种用于在线数据迁移的系统，其特征在于，包括：

监听模块，用于监听应用的待迁移数据中的待迁移增量数据的二进制日志；

消息生产模块，用于根据所述二进制日志生成增量数据迁移消息；

消息分发模块，用于根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列；

所述消息生产模块包括：

解析单元，用于解析所述二进制日志，获取所述待迁移增量数据的变更信息，所述变更信息包括发生更改的应用名、库名以及表名；

组装单元，用于根据映射关系组装所述增量数据迁移消息，所述映射关系包括所述待迁移数据对应的应用名、库名以及表名，当所述发生更改的应用名、库名以及表名分别与所述映射关系中的应用名、库名以及表名相同时，则生成所述应用的增量数据迁移消息。

10.根据权利要求9所述的系统，其特征在于，所述应用的待迁移数据还包括待迁移历史数据，所述系统还包括：

扫描模块，用于定时扫描所述待迁移历史数据生成历史数据迁移消息；

消息发送模块，用于将所述历史数据迁移消息发送至所述应用的历史数据消息队列。

11.根据权利要求10所述的系统，其特征在于，还包括：

迁移模块，用于订阅所述增量数据消息队列和所述历史数据消息队列，获取所述增量数据迁移消息和所述历史数据迁移消息，完成数据迁移。

12.一种电子设备，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

监听应用的待迁移数据中的待迁移增量数据的二进制日志；

根据所述二进制日志生成增量数据迁移消息；

根据消息分发策略将所述增量数据迁移消息发送至所述应用的增量数据消息队列；

根据所述二进制日志生成增量数据迁移消息，包括：

解析所述二进制日志，获取所述待迁移增量数据的变更信息，所述变更信息包括发生更改的应用名、库名以及表名；

根据映射关系组装所述增量数据迁移消息，所述映射关系包括所述待迁移数据对应的应用名、库名以及表名，当所述发生更改的应用名、库名以及表名分别与所述映射关系中的应用名、库名以及表名相同时，则生成所述应用的增量数据迁移消息。

13.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-8中任一项所述的方法。

Images