首页> 中国专利> 一种异构数据库复制事务一致性保障方法及系统

一种异构数据库复制事务一致性保障方法及系统

摘要

本发明提供一种基于提交表的异构数据库复制事务一致性保障方法及系统,在使用日志进行异构数据库复制环境中,利用提交事务表记录目的端数据库完成事务的过程,并定期执行恢复起始点的检查,在复制系统故障时利用提交事务表决定需要重传的事务日志起始位置。本发明采用基于事务表的异构数据库复制,解决了源数据库和目的数据库双方事务执行可能存在的不一致性,导致双方数据不一致的技术问题。

著录项

  • 公开/公告号CN105574187A

    专利类型发明专利

  • 公开/公告日2016-05-11

    原文格式PDF

  • 申请/专利权人 武汉达梦数据库有限公司;

    申请/专利号CN201510976842.5

  • 发明设计人 付铨;孙峰;陈琦;周英飚;

    申请日2015-12-23

  • 分类号G06F17/30(20060101);

  • 代理机构42224 武汉东喻专利代理事务所(普通合伙);

  • 代理人方放

  • 地址 430073 湖北省武汉市东湖开发区关山一路特1号光谷软件园C6栋5层

  • 入库时间 2023-12-18 15:12:16

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2023-08-15

    专利权的转移 IPC(主分类):G06F16/17 专利号:ZL2015109768425 登记生效日:20230731 变更事项:专利权人 变更前权利人:武汉达梦数据库股份有限公司 变更后权利人:武汉达梦数据库股份有限公司 变更事项:地址 变更前权利人:430073 湖北省武汉市东湖新技术开发区高新大道999号未来科技大厦C3栋16-19层 变更后权利人:430206 湖北省武汉市东湖新技术开发区高新大道999号未来科技大厦C3栋16-19层 变更事项:专利权人 变更前权利人:华中科技大学 变更后权利人:

    专利申请权、专利权的转移

  • 2022-09-16

    专利权的转移 IPC(主分类):G06F16/17 专利号:ZL2015109768425 登记生效日:20220905 变更事项:专利权人 变更前权利人:武汉达梦数据库股份有限公司 变更后权利人:武汉达梦数据库股份有限公司 变更事项:地址 变更前权利人:430073 湖北省武汉市武汉东湖新技术开发区高新大道999号未来科技大厦C3栋16-19层 变更后权利人:430073 湖北省武汉市东湖新技术开发区高新大道999号未来科技大厦C3栋16-19层 变更事项:专利权人 变更前权利人: 变更后权利人:华中科技大学

    专利申请权、专利权的转移

  • 2019-02-19

    授权

    授权

  • 2016-06-08

    实质审查的生效 IPC(主分类):G06F17/30 申请日:20151223

    实质审查的生效

  • 2016-05-11

    公开

    公开

说明书

技术领域

本发明涉及一种异构数据库复制的事务一致性保障方法,尤指一种基 于事务提交表的异构数据库复制事务一致性保障方法及系统。

背景技术

随着企业信息化系统的广泛应用,信息化系统已经成为企业维持业务 运转的关键。企业多样化的业务类型导致数据访问需求日趋复杂化,同时 数据量的急剧攀升也导致数据库服务器不堪重负。企业迫切需要提高信息 系统的可用性,保证业务的连续性,最大限度地减少因灾难或故障所带来 的损失。为此,分布式异构数据库的数据复制是一种常用的技术手段。

目前,抽取源数据库的事务日志,获得源数据库的数据操作,包括插 入(INSERT)、删除(DELETE)、更新(UPDATE),然后通过网络发送给 复制系统的目的端,目的端恢复成原始的SQL语句在目的数据库上执行, 是一种常用的数据库复制技术。它具有对源数据库的性能和数据模式影响 小,可采用非常灵活的方式配置出各种拓扑结构,支持跨异构的操作系统 和数据库平台复制等优点。

保障目的数据库与源数据库的事务一致性,并在任何软硬件故障下具 备恢复数据复制的能力,是这种复制系统需要考虑的问题。目前存在的一 些数据复制系统,例如Oracle的GoldenGate,通过自身的文件管理复制信 息,在源端和目的端的文件中保存抽取到的事务日志,当系统出现软硬件 故障时,根据文件中保存的日志执行位置,日志抽取位置等信息,重新在 源数据库的事务日志中进行定位,继续数据复制过程。

然而,上述方法中复制系统使用的文件管理独立于目的数据库的事务 管理,无法保证复制事务的一致性。例如,复制系统目的端首先提交一个 事务,然后在自己的文件中登记此事务的ID和LSN,在文件可靠的刷新到 不易失存储介质之前,发生了故障。系统重启后,因为目的数据库的事务 已经提交,该数据库的故障恢复和事务管理机制将保证事务的持久性,即 事务对于数据的影响已经生效,但复制系统的内部文件并未正确登记这一 信息,导致恢复数据复制时,复制系统再次将此事务的日志传到目的数据 库执行,同一事务执行多次,造成了源数据库和目的数据库的事务不一致。

由此可见,传统的复制系统利用自身文件管理复制信息,无法保证源 数据库和目的数据库双方事务执行的一致性,需要发明新的异构数据库复 制的事务一致性保障方法。

发明内容

本发明提供了一种异构数据库复制的事务一致性保障方法及系统,其 目的在于,解决现有异构数据库复制系统采用基于事务日志的数据复制时, 源数据库和目的数据库双方事务执行可能存在的不一致性,导致双方数据 不一致的技术问题。

为了解决上述问题,本发明采用以下技术方案:

一种基于提交表的异构数据库复制事务一致性保障方法,包括如下步 骤:

目的数据库与源数据库事务同步的操作步骤,具体为:在目的数据库 创建提交事务表,在复制系统目的端的内存中创建未提交事务表;从源数 据库中获取事务的操作日志,复制系统目的端根据所述操作日志在目的数 据库中执行相应的数据操作;将事务第一次操作信息作为一条记录插入未 提交事务表,将事务的最后一次提交操作信息作为一条记录插入提交事务 表,同时从未提交事务表中删除已提交事务的记录;

复制系统目的端的定时检查步骤,具体为:在未提交事务表中找到尚 未提交的、最早发生的事务,在提交事务表中删除该事务之前的所有事务 记录,同时在提交事务表中插入一条包含尚未提交的、最早发生的事务信 息的检查点记录;

故障恢复步骤,具体为:从提交事务表中的检查点记录获取尚未提交 的、最早发生的事务信息,复制系统源端以该事务作为恢复起点,将事务 相关的操作日志发送给目的端;如果提交事务表中没有该日志对应事务的 记录,则复制系统目的端根据收到的操作日志在目的数据库中执行相应数 据操作。

进一步地,所述目的数据库与主数据库事务同步步骤的具体实现过程 为:

11)在目的数据库创建提交事务表,在复制系统目的端内存中创建未 提交事务表;

12)抽取源数据库中的操作日志,操作日志包含事务ID、事务序列号 LSN和内容;

13)若操作日志的事务ID是第一次出现,表明抽取到的是事务的第一 条操作日志,则在未提交事务表中插入一条包含事务第一条操作日志LSN 信息的事务记录,执行日志内容指定的数据操作,返回步骤12);否则, 执行步骤14);

14)若抽取到的日志内容表明是提交操作,则执行步骤15);若抽取 到的日志内容表明是提交以外的数据操作,则执行步骤16);

15)在提交事务表插入一条包含事务提交操作日志LSN信息的事务记 录,将提交事务表与事务涉及的所有数据操作一并进行事务提交,从未提 交事务表中删除等于提交事务ID的事务记录;

16)执行相应数据操作,返回步骤12);

进一步地,所述目的数据库的定时检查步骤的具体实现过程为:

21)在未提交事务表中找到序列号LSN最小的记录,对应当前尚未提 交的、最早发生的事务,记该记录的序列号LSN为LSN0;

22)在提交事务表中删除小于等于LSN0的所有记录;

23)在提交事务表中插入一条检查点记录,检查点记录包含有LSN0信 息;

进一步地,所述故障恢复步骤的具体实现过程为:

31)复制系统源端向复制系统目的端发送查询检查点的请求;

32)复制系统目的端在目的数据库查询到检查点记录,将其存储的LSN0 信息反馈给复制系统源端;

33)复制系统源端在源数据库的操作日志文件中搜索等于LSN0的事务 记录作为恢复起点,依次将此事务及后续事务相关操作日志发送给复制系 统目的端。

34)复制系统目的端在目的数据库根据恢复用的操作日志的事务ID在 提交事务表中搜索,若搜索到等于事务ID的事务记录,则不操作,结束; 否则对目的数据库按照恢复用的操作日志执行相应数据操作。

一种基于提交表的异构数据库复制事务一致性保障系统,包括:源数 据库、目的数据库、复制系统、创建于目的数据库的提交事务表、创建于 复制系统目的端内存的未提交事务表;

复制系统源端将源数据库中事务的操作日志转发给目的端,目的端在 目的数据库中执行相应的数据操作;目的端将收到的事务的第一次操作信 息作为一条记录插入未提交事务表,将事务的最后一次提交操作信息作为 一条记录插入提交事务表,从未提交事务表中删除已提交事务的记录;

复制系统目的端定时在未提交事务表中找到尚未提交的、最早发生的 事务,在提交事务表中删除该事务之前的所有事务记录,同时在提交事务 表中插入一条包含尚未提交的、最早发生的事务信息的检查点记录;

复制系统目的端从提交事务表中的检查点记录获取尚未提交的、最早 发生的事务信息,复制系统源端以该事务作为恢复起点,将源数据库中此 事务及后续事务相关的操作日志发送给目的端;如果提交事务表中没有该 事务的记录,则复制系统目的端根据收到的操作日志在目的数据库中执行 相应数据操作。

本发明对比现有技术有以下优越性:

本发明利用目的数据库中一张提交事务表保存已提交的事务和尚未提 交的最早的事务,对此表的更新与对应的事务一并提交,充分利用了目的 数据库自身的故障恢复功能,将复制事务自身的操作与事务执行的信息合 成为一个事务,一起进行提交。如此,事务的原子性保证了事务自身的数 据操作与事务成功执行的信息存储的一致性,而事务执行的信息存储是复 制系统故障恢复的依据,从而保证了异构数据库复制的事务一致性和数据 一致性。克服了传统方法中复制系统的检查点信息与目的数据库分离存储 可能产生的不一致性。

附图说明

图1是本发明的复制模型示意图。

图2是本发明在数据复制过程中,对于提交事务表和未提交事务表的 管理流程示意图。

图3是本发明检查点过程的流程示意图。

图4是本发明故障恢复过程的流程示意图。

图5是按照本发明的一个实例示意图,其中,图5(a)是t1时刻提交事 务表和未提交事务表示意图,图5(b)为检查点记录插入过程示意图,图5(c) 为故障恢复过程示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图 及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体 实施例仅仅用以解释本发明,并不用于限定本发明。此外,下面所描述的 本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可 以相互组合。

本发明包含三个步骤:目的数据库与主数据库事务同步的操作步骤、 目的数据库的定时检查步骤和故障恢复步骤。下面详细说明:

图2是本发明目的数据库与主数据库事务同步的操作步骤流程图,具 体为:

11)在目的数据库创建一张提交事务表,字段要求如下。

在复制系统的内存中,创建一张未提交事务表,字段要求如下。

12)在源数据库,复制系统抽取源数据库中的操作日志,日志包含事务 ID、事务序列号LSN和内容。

13)若操作日志的事务ID是第一次出现,表明抽取到的是事务的第一 条操作日志,则在未提交事务表中插入一条包含事务第一条操作日志LSN 信息的事务记录,执行日志内容指定的数据操作,返回步骤12);否则, 执行步骤14)。

14)若抽取到的日志内容表明是提交操作,则执行步骤15);若抽取 到的日志内容表明是提交以外的数据操作譬如INSERT、DELETE、UPDATE, 则执行步骤16)。

15)在提交事务表插入一条包含事务提交操作日志LSN信息的事务记 录,将提交事务表与事务涉及的所有数据操作一并进行事务提交,从未提 交事务表中删除等于提交事务ID的事务记录。

16)在目的数据库生成此日志对应的语句并执行相应数据操作,返回 步骤12)。

图3是本发明目的数据库的定时检查步骤流程图,通过定时器,定时 触发检查点过程,时间到执行以下步骤:

21)在未提交事务表中找到序列号LSN最小的记录,对应当前尚未提 交的、最早发生的事务,记该记录的序列号LSN为LSN0。

22)在提交事务表中删除小于等于LSN0的所有记录,即执行语句: DELETEFROM“提交事务表”WHERE“提交LSN”<=LSN0。

此步骤清理提交事务表,对于在最早发生的未提交事务启动之前,就 已经提交的已提交事务,在提交事务表中已经无需继续保存,因此将其清 理掉。

还需说明的是,这里删除的不光是事务记录,还删除了等于LSN0的检 查点记录。检查点记录请参见在步骤23)的详细说明。

23)在提交事务表中插入一条检查点记录,检查点记录包含有LSN0信 息。

为了与事务记录区分,可对检查点记录的“事务ID”字段值单独设置, 譬如设为0,因为正常事务的ID是一个正整数,事务ID字段为0的记录就 是一条特殊的,表示检查点的记录,此记录的“提交LSN字段”等于LSN0, 代表在此检查点发生时,所有未提交事务的最早发生的事务,其第一条操 作的日志LSN。即执行语句:INSERTINTO“提交事务表”VALUES(0,LSN0)。

图4显示复制系统因系统故障终止,重启后源端根据目的数据库中提 交表的记录决定复制的起始位置。具体过程为:

当复制系统因为通信故障,复制系统或源数据库或目的数据库系统故 障异常终止后,重启复制系统。

31)源端向目的端发送查询检查点的请求。

32)目的端在目的数据库的提交表中查询到检查点记录,将其存储的 LSN0信息反馈给源端;即执行语句:SELECT“提交LSN”FROM“提 交事务表”WHERE“事务ID”=0。

33)源端在源数据库日志文件中搜索等于LSN0的事务记录作为恢复 起点,依次将后续操作日志发送给目的端。

小于此LSN0的日志对应的事务在目的数据库均已提交,无需再行执行。

34)目的端接到事务日志后,根据日志记录中的事务ID到“提交事务 表”中搜索。即执行语句:

SELECT*FROM“提交事务表”WHERE“事务ID”=日志记录对应 的事务ID。

事务ID在提交事务表中存在,即步骤65)的SELECT语句结果集不为空, 则忽略此日志记录,若为空,则目的端生成此日志对应的语句并在在目的数 据库上执行。

以上步骤31)、32)、33)、34)循环往复执行,直到复制系统恢复正常

下面详细说明一个实例:

图5(a)是t1时刻提交事务表和未提交事务表示意图,目的数据库在第 一次收到事务ID=3的日志时,在未提交事务表中插入事务ID=3、LSN=99 的记录,在提交事务ID=2的事务时,在未提交事务表中插入事务ID=3、 LSN=98的记录,在未提交事务表中删除ID=2的事务记录。

图5(b)为检查点记录插入过程示意图,未提交事务表中表明ID=3、 起始LSN=99的事务为尚未提交的最早发生的事务,则在事务提交表中删 除早于该事务的记录即删除事务ID=2、LSN=98的记录,同时插入事务 ID=0、LSN=99的检查点记录。

图5(c)为故障恢复过程示意图。在提交事务表中找到检查点记录,获 知恢复起点为ID=3、LSN=99的事务。

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

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号