一种数据库迁移方法、装置、电子设备及存储介质
技术领域
本申请涉及数据库技术领域,尤其涉及一种数据库迁移方法、装置、电子设备及存储介质。
背景技术
数据迁移(又称分级存储管理,hierarchical storage management,HSM)是一种将离线存储与在线存储融合的技术,将正在提供线上服务的数据从一个地方迁移到另一个地方。
数据迁移的过程大致可以分为抽取、转换、装载三个步骤。数据抽取、转换是根据新旧***数据库的映射关系进行的,而数据差异分析是建立映射关系的前提,这其中还包括对代码数据的差异分析。转换步骤一般还要包含数据清洗的过程,数据清洗主要是针对源数据库中,对出现二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行相应的清洗操作;在清洗之前需要进行数据质量分析,以找出存在问题的数据,否则数据清洗将无从谈起。数据装载是通过装载工具或自行编写的SQL程序将抽取、转换后的结果数据加载到目标数据库中。
在实现本发明的过程中发明人发现,对于分库数据表存储的数据,由于迁移后数据库数据量、表的数据量、每个表中的数据量均会发生变化,因此,现有数据迁移技术无法保证迁移前后数据的一致性。
针对相关技术中存在的诸多技术问题,目前尚未提供有效的解决方案。
发明内容
为了解决上述技术问题或者至少部分地解决上述技术问题,本申请实施例提供了一种数据库迁移方法、装置、电子设备及存储介质。
第一方面,本申请实施例提供了一种数据库迁移方法,包括:
获取源数据库中的待迁移数据;
确定将所述待迁移数据迁移到目标数据库后,所述目标数据库中增加的第一迁入数据;其中,所述目标数据库至少包括一个;
根据所述待迁移数据以及第一迁入数据进行迁移前后的数据量一致性校验。
可选的,如前所述的方法,所述将所述待迁移数据迁移到目标数据库,包括:
确定所述源数据库中的第一数据表对应的第一自增标识;其中,所述第一数据表为所述待迁移数据中的数据表,同一所述源数据库中的第一数据表的第自增标识按序递增设置;
根据所述第一自增标识将所述第一数据表迁移到所述目标数据库。
可选的,如前所述的方法,所述根据所述第一自增标识将所述第一数据表迁移到所述目标数据库,包括:
根据所述第一数据表对应的第一自增标识,并按照预设次序对所述第一数据表进行读取;
依次将读取的所述第一数据表按照预设的迁移策略写入对应的目标数据库中。
可选的,如前所述的方法,根据所述待迁移数据以及第一迁入数据进行迁移前后的数据量一致性校验,包括:
根据所述待迁移数据生成第一Md5值;
根据所述第一迁入数据生成第二Md5值;
基于所述第一Md5值和第二Md5值进行所述迁移前后的数据量一致性校验。
可选的,如前所述的方法,还包括:
获取在对所述待迁移数据进行迁移的过程中写入所述源数据库中的增量数据;
确定将所述增量数据迁移到所述目标数据库后,所述目标数据库中增加的第二迁入数据;
根据所述增量数据以及第二迁入数据进行所述增量数据的迁移结果校验。
可选的,如前所述的方法,所述获取在对所述待迁移数据进行迁移的过程中写入所述源数据库中的增量数据,包括:
获取所述源数据库的数据库信息;
根据所述数据库信息注册得到所述源数据库的从库;
通过所述从库从所述源数据库中获取第二数据表对应的第二自增标识;其中,所述第二数据表包括所述增量数据及待迁移数据;
根据所述第二自增标识以及第一自增标识,筛选得到所述增量数据对应的第三数据表;其中,所述第一自增标识为所述待迁移数据中的数据表对应的自增标识,所述第三数据表为所述增量数据中的数据表;
根据所述第三数据表得到所述增量数据。
可选的,如前所述的方法,所述根据所述增量数据以及第二迁入数据进行所述增量数据的迁移结果校验,包括:
确定所述第三数据表中携带的全局唯一标识;
根据所述全局唯一标识从所述源数据库中调取所述第三数据表;
根据所述全局唯一标识从所述目标数据库中调取第四数据表;
根据所述第三数据表的数据以及所述第四数据表的数据进行所述增量数据的迁移结果校验。
可选的,如前所述的方法,根据所述第三数据表的数据以及所述第四数据表的数据进行所述增量数据的迁移结果校验,包括:
根据所述第三数据表的数据生成第三Md5值;
根据所述第四数据表的数据生成第四Md5值;
基于所述第三Md5值和第四Md5值进行所述迁移结果校验。
可选的,如前任一项所述的方法,所述方法还包括:
获取所述源数据库中的未转移数据;
在所述未转移数据的数据量在预设区间内时,停止对所述目标数据库进行数据写入;
在所述未转移数据的数据量不在预设区间内时,对所述未转移数据进行迁移。
可选的,如前任一项所述的方法,在通过所述迁移前后的数据量一致性校验之后,还包括:
在所述源数据库中抽取出预设条数的第一数据;其中,所述第一数据为所述源数据库中的任一数据;
在所述目标数据库中抽取出预设条数的第二数据;其中,所述第二数据为所述目标数据库中与所述第一数据对应的数据;
根据所述第一数据的数据生成第五Md5值;
根据所述第二数据的数据生成第六Md5值;
在所述第五Md5值和第六Md5值一致时,判定所述源数据库中的数据完全迁移至所述目标数据库。
第二方面,本申请实施例提供了数据库迁移装置,包括:
获取模块,用于获取源数据库中的待迁移数据;
确定模块,用于确定将所述待迁移数据迁移到目标数据库后,所述目标数据库中增加的第一迁入数据;
校验模块,用于根据所述待迁移数据以及第一迁入数据进行迁移前后的数据量一致性校验。
第三方面,本申请实施例提供了一种电子设备,包括:处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信;
所述存储器,用于存放计算机程序;
所述处理器,用于执行计算机程序时,实现上述方法步骤。
第四方面,本申请实施例提供了一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现上述方法步骤。
本申请通过提供一种数据库迁移方法、装置、电子设备及存储介质。其中所述数据库迁移方法,包括:获取源数据库中的待迁移数据;确定将所述待迁移数据迁移到目标数据库后,所述目标数据库中增加的第一迁入数据;其中,所述目标数据库至少包括一个;根据所述待迁移数据以及第一迁入数据进行迁移前后的数据量一致性校验。本申请实施例提供的上述技术方案与相关技术相比具有如下优点:相对于相关技术在对源数据库中的数据进行分库分表存储之后,会由于迁移后数据库数量、表的数量、每个表中的数据量的变化,导致迁移前后数据不一致;而本申请方法能够对迁移的数据进行一致性校验,进而保障迁移前后数据的一致性。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种数据库迁移方法的流程图;
图2为本申请另一实施例提供的一种数据库迁移方法的流程图;
图3为本申请另一实施例提供的一种数据库迁移方法的流程图;
图4为本申请另一实施例提供的一种数据库迁移方法的流程图;
图5为本申请另一实施例提供的一种数据库迁移方法的流程图;
图6为本申请另一实施例提供的一种数据库迁移方法的流程图;
图7为本申请另一实施例提供的一种数据库迁移方法的流程图;
图8为本申请另一实施例提供的一种数据库迁移方法的流程图;
图9为本申请一应用例中对待迁移数据进行迁移及校验的示意图;
图10为本申请一应用例中对增量数据进行迁移及校验的示意图;
图11为本申请实施例提供的一种数据库迁移装置的框图;
图12为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
如图1所示,本申请实施例提供了一种数据库迁移方法,包括如下所示步骤S1至S3:
S1.获取源数据库中的待迁移数据;
具体的,源数据库为存在需要将其中存储的数据迁出的数据库,待迁移数据为需要进行迁出的数据;一般的待迁移数据以数据表的形式存在;
可选的,可以通过数据复制中心(例如:Dbrep)从Subscriber获取源数据库信息,然后从数据库中读取数据;其中,Subscriber用于进行数据拽取的一个应用程序,Dbrep是基于kafka、zookeeper等搭建的准实时数据同步***。
Kafka:最初由Linkedin公司开发,是一个分布式、分区的、多副本的、多订阅者,基于zookeeper协调的分布式日志***(也可以当做MQ***),常见可以用于web/nginx日志、访问日志,消息服务等等。
S2.确定将待迁移数据迁移到目标数据库后,目标数据库中增加的第一迁入数据;其中,目标数据库至少包括一个;
具体的,目标数据库为用于将上述的待迁移数据迁入的数据库,且目标数据库可以为一个或多个,一般的,一个数据表中的数据存储在同一个目标数据库中,上述的第一迁入数据为将待迁移数据迁入目标数据库后得到的数据;
将待迁移数据迁移到目标数据库可以通过Sharding-Sphere进行写入;其中,Sharding-Sphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar这3款相互独立的产品组成;其中,Sharding-JDBC为轻量级Java框架,在Java的JDBC层提供的额外服务,使用客户端直连数据库,以jar包形式提供服务,无需额外部署和依赖,可理解为增强版的JDBC驱动,完全兼容JDBC和各种ORM框架;Sharding-Proxy为透明化的数据库代理端,提供封装了数据库二进制协议的服务端版本,用于完成对异构语言的支持;它可以使用任何兼容MySQL/PostgreSQL协议的访问客户端(如:MySQL Command Client,MySQL Workbench,Navicat等)操作数据,对DBA更加友好;Sharding-Sidecar用于代理所有对数据库的访问。他们均提供标准化的数据分片、读写分离、柔性事务和数据治理功能,可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。进一步的,可以通过所述Sharding-Sphere中的Sharding-JDBC执行本步骤中相应的方法。
S3.根据待迁移数据以及第一迁入数据进行迁移前后的数据量一致性校验。
具体的,由于待迁移数据在迁移过程中会出现同步失败,或重复迁移等情况,因此会导致迁移前后的数据量不一致的情况,因此需要对源数据库中的待迁移数据以及目标数据库中的第一迁入数据进行校验,判断两者的数据量是否一致。可选的,在判断数据量一致之后,还可以对两者的数据内容的一致性进行判断。
如图2所示,在一些实施例中,如前的方法,步骤S2将待迁移数据迁移到目标数据库,包括如下所示步骤S21至S22:
S21.确定源数据库中的第一数据表对应的第一自增标识;其中,第一数据表为待迁移数据中的数据表,同一源数据库中的第一数据表的第一自增标识按序递增设置;
具体的,第一自增标识为单表唯一自增主键(id),且该单表唯一自增主键(id)在同一源数据库中是唯一的,且每当新写入一个数据时,在已有标识基础上递增生成一个新的标识,举例的,当每一个用户的数据对应一个数据表时,在源数据库中的存储方式如下表所示:
Account_0000 |
用户1 |
Account_0001 |
用户2 |
|
|
Account_0049 |
用户50 |
|
|
其中Account_0000~Account_0049即为上述的单表唯一自增主键(id)的一种表现形式;举例的:当数据库已有的数据表中最大的第一自增标识为Account_0045时,再新存储进一个用户的数据时,则用于存储该用户数据的数据表所对应的第一自增标识为Account_0046,对应的用户的数据则标识为用户47。
S22.根据第一自增标识将第一数据表迁移到目标数据库。
具体的,如上表所示,按照Account_0000~Account_0049对各个用户(例如:用户1、用户2等等)的数据进行读取,并且将各个用户的数据迁移到目标数据库中。
如图3所示,在一些实施例中,如前的方法,上述步骤S22根据第一自增标识将第一数据表迁移到目标数据库,包括如下所示步骤S221至S222:
S221.根据第一数据表对应的第一自增标识,并按照预设次序对第一数据表进行读取。
具体的,上述的预设次序可以是由小到大,或由大到小等顺序进行,由于一般在数据存储时,第一自增标识都是由小至大进行递增生成的,因此读取时也按照标识由小到大的顺序进行读取,以防止对超过某一大小上限的标识漏读取的情况;且能够便于在后期增加数据的情况下能够快速判断出未进行读取或迁移的数据。
S222.依次将读取的第一数据表按照预设的迁移策略写入对应的目标数据库中。
具体的,上述的预设的迁移策略可以是:将某一源数据库中的某一数据表存储到某一目标数据库的某一数据表中的策略。
举例来说:
当定义每个源数据库中数据表的总个数为tableNumber=50;具体的各个数据表的第一自增标识为:account_0000~account_0049;
定义总数据库的个数为dbNumber=24,具体信息为db0~db23,并且可以通过spring的动态数据源的配置方式,对所有数据库中的源数据进行统一管理,以便于后期对所有数据库中的数据进行迁移管理。
resource为将用户id进行Hash值处理得到;
数据表迁移进的新的目标数据库的位置可以通过下式进行计算:(Long.valueOf(resource)%(dbNumber*tableNumber)/tableNumber);
Long.valueOf(resource),是resource对应的long值。
数据表迁移进的新的目标数据库后存储的表的位置可以通过下式进行计算:Long.valueOf(resource)%tableNumber。
目标库的数据量增加,表也增加,通过此算法可以知道新数据存储的位置。
在一些实施例中,如前的方法,根据待迁移数据以及第一迁入数据进行迁移前后的数据量一致性校验,包括如下所述步骤A1至A3:
A1.根据待迁移数据生成第一Md5值;
A2.根据第一迁入数据生成第二Md5值;
A3.基于所述第一Md5值和第二Md5值进行所述迁移前后的数据量一致性校验。一般的,可以在第一Md5值和第二Md5值一致时,判定待迁移数据的数据量与第一迁入数据的数据量一致。
具体的,源数据库端为:
具体的,目标数据库端为:
则源数据库端的第一MD5值为:(值1值2值3);
目标数据库端的第二MD5值为:(值a值b值c);
因此只需比较(值1值2值3)和(值a值b值c)即可判断待迁移数据的数据量与第一迁入数据的数据量是否一致。
如图9所示,根据前述实施例中的方案提供的一种应用例如下所述:
1.同步方案:
按照分表维度,通过id增序逐批次迁移数据。
2.校验方案:
Dbrep在做数据迁移的同时,记录下所有表迁移到的最大id值。待存量迁移完成后,统计源数据库中各分表中小于等于最大id的数据量。在数据库表无物理删除的情况下,该值应该等于目标库中总表记录数。有物理删除时,前者小于后者。
a1)Dbrep从Subscriber读取数据库信息(步骤i);
b1)按照分表的维度,通过id逐批次读取数据(步骤ii);并通过Sharding-JDBC写入到目标数据库(步骤iii和步骤iv);
c1)数据迁移的同时,记录下各表迁移到的最大id(步骤v);
d1)分别统计各个源数据库中最大id以内的第一数据表的数据量之和(步骤vi、步骤vii和步骤viii),与目标数据库总数据量做比较(步骤ix和步骤x)。
如图4所示,在一些实施例中,如前的方法,还包括如下所述步骤S4至S6:
S4.获取在对待迁移数据进行迁移的过程中写入源数据库中的增量数据;
具体的,在通过步骤S1至S3中的对待迁移数据进行迁移的过程中,由于上述的源数据库中并未被禁止写入数据,因此会存在上述的源数据库被写入新数据的情况,新数据即为本实施例中所述的增量数据;举例来说:当待迁移数据包括A1、A2~A40时,且执行步骤S1至S3的过程中,源数据库中又被写入了新的数据A41和A42时,则需要对新数据(A41和A42)再次进行迁移;因此,为了保障数据能够完全迁移,需要获取增量数据,并对其进行数据迁移。
S5.确定将增量数据迁移到目标数据库后,目标数据库中增加的第二迁入数据;
具体的,上述的第二迁入数据为对增量数据进行迁移后,目标数据库中增加的数据;将增量数据迁移到目标数据库可以采用下述方法进行:由于在前述步骤S4中已确认增量数据对应,因此可以通过kafka将增量数据的信息进行存储;然后由Dbrep-sink以及Sharding-JDBC将增量数据写入目标数据库中。
S6.根据增量数据以及第二迁入数据进行增量数据的迁移结果校验。
为了能够对迁移的数据均进行准确的校验,因此对增量数据与第二迁入数据也需要进行校验。
如图5所示,在一些实施例中,如前的方法,上述步骤S4获取在对待迁移数据进行迁移的过程中写入源数据库中的增量数据,包括如下所示步骤S41至S45:
S41.获取源数据库的数据库信息;
具体的,以前述实施例为例,可以先通过Subscriber读取源数据库中的数据库信息,然后再通过Dbrep从Subscriber读取数据库信息。
S42.根据数据库信息注册得到源数据库的从库。
具体的,可以通过Dbrep注册成上述源数据库的从库,以获得各个源数据库的数据信息;
S43.通过从库从源数据库中获取第二数据表对应的第二自增标识;其中,第二数据表包括增量数据及待迁移数据;
具体的,第二数据表为源数据库中的数据表,且此时的源数据库中包括的数据有:在前述实施例中已进行迁移的待迁移数据与增量数据;上述的第二自增标识同样为单表唯一自增主键;且一般的,在同一源数据库中,第二自增标识与第一自增标识同为其中数据表的标识,只是第二自增标识对应的数据包括增量数据及待迁移数据,而第一自增数据只包括待迁移数据;增量数据对应的第二数据表所携带的第二自增标识是在待迁移数据对应的第一数据表所携带的第一自增标识的基础上增加得到的;
S44.根据第二自增标识以及第一自增标识,筛选得到增量数据对应的第三数据表;其中,第一自增标识为待迁移数据中的数据表对应的自增标识,第三数据表为增量数据中的数据表;
具体的,由于一般在数据迁移时,是按照自增标识(第一自增标识及第二自增标识)由小到大的顺序进行的,因此,在对待迁移数据进行迁移之后,记录下其最大的第一自增标识即可判断:第一自增标识小于等于该最大的第一自增标识的数据表均已进行过迁移;由于第二自增标识是在第一自增标识的基础上自增得到的,因此根据第二自增标识与第一自增标识即可得到增量数据中第三数据表对应的自增标识,进而可以通过标识定位到所述第三数据表;在得到第三数据表之后,将第三数据表写入到Kafka中。
S45.根据第三数据表得到增量数据。
具体的,在确定第三数据表之后,第三数据表中的数据即为上述的增量数据。
如图6所示,在一些实施例中,如前的方法,上述步骤S6根据增量数据以及第二迁入数据进行增量数据的迁移结果校验,包括如下所示步骤S61至S64:
S61.确定第三数据表中携带的全局唯一标识;
具体的,上述全局唯一标识可以为通用唯一识别码uuid(Universally UniqueIdentifier);
S62.根据全局唯一标识从源数据库中调取第三数据表;
具体的,由于在前述实施例中已确认增量数据对应的第三数据表,因此可以确认各个增量数据对应的全局唯一标识;可选的,可以通过kafka将增量数据的信息进行存储,同时kafka中可以记录各个第三数据表对应的全局唯一标识;然后使Dbrep-Check获取kafka中uuid数据后,通过Subscriber读取源数据库中的第三数据表。
S63.根据全局唯一标识从目标数据库中调取第四数据表;
具体的,由于存储于目标数据库中的第四数据表同样存在全局唯一标识,因此也可以通过全局唯一标识调取得到目标数据库中的第四数据表;其中一种可选的技术方案为:在步骤S62的具体示例的基础上,Dbrep-Check获取kafka中uuid数据后,通过Sharding-JDBC读取目标数据库中的第四数据表。
S64.根据第三数据表的数据以及第四数据表的数据进行增量数据的迁移结果校验。
具体的,通过从目标数据库中获取的第四数据表以及源数据库中获取的数据表对两者的数据量进行校验。
在一些实施例中,如前的方法,步骤S64根据第三数据表的数据以及第四数据表的数据进行增量数据的迁移结果校验,包括如下所示步骤B1至B3:
B1.根据第三数据表的数据生成第三Md5值;
B2.根据第四数据表的数据生成第四Md5值;
B3.基于第三Md5值和第四Md5值进行迁移结果校验。
具体的,该步骤执行过程与前述实施例中的步骤A1至A3类似,在此不再进行赘述。
根据前述步骤S4至S6的对增量数据进行迁移及校验方法的一种应用例如下所述:
1、同步方案:
在启动存量数据迁移之前,先记录下每个源数据库实例当前的单表唯一自增主键id(第一自增标识)。存量数据同步完成之后,将Dbrep注册成各数据库实例的从库,从之前纪录的单表唯一自增主键(最大第一自增标识)位置开始读取数据,并通过Sharding-Sphere写入到新的数据库。
2、校验方案:
Dbrep将增量数据写入到Kafka的同时,记录下所有数据的uuid。校验程序通过这些uuid读取源和目标两端记录的全字段,拼接生成Md5值。
当Dbrep和Kafka同步到无积压时,对比两端Md5值。具体的,当目标数据库与源数据库中的数据量的差异量与dbrep同步积压和Kafka消费积压量(即:还在迁移中的数据量)基本吻合,则认为数据同步基本正常。
关闭源端数据库的写入,待Dbrep和Kafka完全同步完成后,再次对比两端数据;如果无差异,则认为同步完成;如个别数据有差异,可通过uuid手动补全。
在启动存量数据迁移之前,先记录下每个源数据库实例当前的GTID。存量数据同步完成之后,将Dbrep注册成各数据库实例的从库,从之前纪录的GTID位置开始读取数据,并通过Sharding-Sphere写入到新的数据库。
具体步骤如图10所示:
a2)Dbrep-Source从Subscriber读取数据库信息(对应图中步骤①);
b2)Dbrep-Source注册成源数据库从库,获取数据(对应图中步骤②);
c2)将数据库变更记录写入到Kafka,并将增量数据的uuid记录到Kafka(对应图中步骤③);
d2)Dbrep-Sink消费kafka数据(对应图中步骤④),通过Sharding-JDBC写入到目标数据库(对应图中步骤⑤⑥);
e2)校验程序Dbrep-Check消费kafka中uuid数据(对应图中步骤⑦),通过Subscriber读取源数据库端的数据(对应图中步骤⑧⑨)和通过Sharding-JDBC读取目标数据库端的数据(对应图中步骤⑩
),对比两端全字段Md5值。
如图7所示,在一些实施例中,如前任一项的方法,方法还包括如下所示步骤S71至S73:
S71.获取源数据库中的未转移数据;
具体的,未转移数据即为源数据库中未转移至目标数据库中的数据。
S72.在未转移数据的数据量在预设区间内时,停止对目标数据库进行数据写入;
具体的,预设区间用于表征未转移数据的积压量;可选的,预设区间可以为0,即源数据库中的数据完全转移至目标数据库之后,才停止对目标数据库进行数据写入。
S73.在未转移数据的数据量不在预设区间内时,对未转移数据进行迁移。
具体的,在未转移数据的数据量不在预设区间内时,则表征未转移数据的数据量超出了预设的积压量,则需要对未转移数据进行迁移;可选的,预设区间可以为0,即源数据库中只要存在未转移数据则需要持续对目标数据库进行数据写入。
在一些实施例中,如前任一项的方法,由于在进行数据迁移的过程中,还可能存在对源数据库端的数据进行改写等造成源数据库端数据与目标数据库端的数据不一致的情况,因此在通过迁移前后的数据量一致性校验之后还需要再次对两端的数据进行校对,以提升数据的一致性,如图8所示,可以包括如下所示步骤S81至S85:
S81.在源数据库中抽取出预设条数的第一数据;其中,第一数据为源数据库中的任一数据;
S82.在目标数据库中抽取出预设条数的第二数据;其中,第二数据为目标数据库中与第一数据对应的数据;
S83.根据第一数据的数据生成第五Md5值;
S84.根据第二数据的数据生成第六Md5值;
S85.在第五Md5值和第六Md5值一致时,判定源数据库中的数据完全迁移至目标数据库。
具体的,预设条数可以是任一预设的数量,举例的:可以是10000条、5000条、2000条等等。获取与第一数据对应的第二数据可以通过存储时的迁移信息或标识对应关系进行获取。步骤S83至S85对应的执行过程与前述实施例中的步骤A1至A3类似,在此不再进行赘述。
如图11所示,根据本申请的另一方面,本申请实施例提供了数据库迁移装置,该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。包括:
获取模块1,用于获取源数据库中的待迁移数据;
确定模块2,用于确定将待迁移数据迁移到目标数据库后,目标数据库中增加的第一迁入数据;
校验模块3,用于根据待迁移数据以及第一迁入数据进行迁移前后的数据量一致性校验。
具体的,本发明实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述,此处不再赘述。
本申请实施例还提供一种电子设备,如图12所示,电子设备可以包括:处理器1501、通信接口1502、存储器1503和通信总线1504,其中,处理器1501,通信接口1502,存储器1503通过通信总线1504完成相互间的通信。
存储器1503,用于存放计算机程序;
处理器1501,用于执行存储器1503上所存放的计算机程序时,实现以下上述方法实施例的步骤。
上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect,P C I)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
本申请还提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现以下上述方法实施例的步骤。
需要说明的是,对于上述装置、电子设备及计算机可读存储介质实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
进一步需要说明的是,在本文中,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本发明的具体实施方式,使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。