CN112433992A - 一种数据同步日志优化方法 - Google Patents
一种数据同步日志优化方法 Download PDFInfo
- Publication number
- CN112433992A CN112433992A CN202011275703.7A CN202011275703A CN112433992A CN 112433992 A CN112433992 A CN 112433992A CN 202011275703 A CN202011275703 A CN 202011275703A CN 112433992 A CN112433992 A CN 112433992A
- Authority
- CN
- China
- Prior art keywords
- log
- database
- destination
- log file
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
- G06F16/162—Delete operations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/275—Synchronous replication
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
本发明公开了一种数据同步日志优化方法,利用数据库日志中存储的数据库操作的可恢复性,持续对日志文件进行优化压缩,将日志文件传到目的端数据库完成数据库之间的异地同步。该方案使用极小的系统资源与带宽,兼顾多种异常网络场景处理,并且规避了重复冗余数据提交带来的恢复数据过大的问题。该发明具有可实用性,同时提升了数据同步的可用性,数据库的防灾以及可维护性。
Description
技术领域
本发明属于数据通信系统尤其是数据库领域,具体涉及一种数据同步日志优化方法。
背景技术
数据库异地同步在分布式系统框架中有着巨大的应用价值。在分布式系统中,每个分布式服务节点都需要根据中央调度来独立处理业务逻辑,因此作为数据存储功能的数据库,需要能适应数据异地多活,数据灾备等多种业务场景,这使得数据库的数据异地同步功能的重要性显得尤为重要。其次,由于无法预测业务时机以及日益增长的数据规模,又对数据同步的实时性与轻量性提出了更高的要求。
现有的数据库同步技术可分为两类,一种是采用数据库内部机制来实现,一种是采用第三方软件实现,比较成熟的数据库同步技术包含以下几种。
1)数据库快照加定时任务的方式,快照从根本上是一张数据库表,这张表将数据库中需要同步的数据的查询结果存在一张快照表中,然后根据数据库创建的定时任务定时地从源端数据库将数据“复制”到目的端数据库,但是这种是非实时的数据同步。
2)数据库内置日志备库方式,其基本原理是将日志文件从源端服务器传输到目地端服务器,然后在目的端数据库上应用这些日志文件,从而使源端数据库与目的端数据库保持一致,这种方式对网络传输带宽的要求较高,不支持一对多和多对一以及双向同步的场景,且目的端数据库是以只读方式打开,也不支持异构环境,需要相同的操作系统版本和数据库版本。
3)流复制方式,流复制方式利用高级队列技术,通过日志挖掘技术将源端数据库日志文件生成变更的逻辑记录,然后将这些变更应用到目地端数据库,从而实现数据库之间的数据同步,这种方式对源端数据库压力较大,对网络带宽要求也较高,还不能保证数据的零丢失。
4)第三方软件方式,目前的第三方软件(如GoldenGate)与流复制类似,但是性能较之流复制更为卓越,抗压性强。
以上的数据库同步方案中可以看出大多数都采用了监听和挖掘数据库日志文件的方式,但是这种方式的缺点在于:
没有有效的清除已传输和已应用的日志文件,和对于长期未传输和未应用的日志文件没有进行优化重构导致长期占用磁盘空间得不到释放,当空间占用过多时可能会导致数据库无法分配内存或锁死,对业务功能造成致命打击。
发明内容
针对现有技术以上缺陷或改进需求中的至少一种,特别是为了解决已有数据库异地同步技术导致的日志文件占用硬盘空间庞大的问题,最大程度优化日志文件体积并避免冗余的记录改动,本发明提出一种可对日志文件进行优化重构并及时删除的数据库同步方案,该方案在兼顾已有数据库同步技术的实时性,多场景应用与轻量级带宽的优势上,引入了对日志文件进行优化重构的日志优化进程,该进程受管理进程的管理并接收通知,当管理进程发现满足日志优化重构或删除的先置条件时,通知日志优化进程对日志文件进行优化,无需用户干预,保证了数据库同步功能的可持久性运行。
为实现上述目的,按照本发明的一个方面,提供了一种数据同步日志优化方法,其特征在于,源端数据库具备自动记录日志的能力,数据同步日志优化方法包括如下步骤:
步骤一:源端数据库监听数据库中的所有DDL和DML操作,并将监听到的DDL和DML操作写入到日志文件并存储到硬盘空间;
步骤二:启动源端服务器管理进程,包括日志优化进程和日志传输进程;日志优化进程不定时对日志文件进行优化重构或删除;同时日志传输进程将生成的日志文件传输到目的端服务器;
步骤三:启动目的端服务器管理进程,包括日志接收进程、日志优化进程和日志解析进程;目的端服务器的日志接收进程接收到日志文件后将日志文件交付给日志解析进程,同时日志优化进程不定时对日志文件进行优化重构或删除;
步骤四:目的端服务器日志解析进程解析日志文件并将记录到的DDL和DML操作写入到目的端数据库中。
优选地,所述源端数据库与目的端数据库可以为同一型数据库,也可以并不需要为同一型数据库,但都必须支持SQL,以便进行数据的更新。
优选地,所述源端数据库与目的端数据库的数量可以有单个或多个,以实现一对一或一对多或多对一或多对多,以及实现双向复制。
优选地,在步骤一里的源端数据库支持归档模式,在该模式下可将用户的DDL与DML操作写入到归档日志文件中。
优选地,在步骤一里的源端服务器管理进程负责日志传输进程和日志优化进程的启动与系统资源调度,同时负责所有定时以及监控日志文件的任务。
优选地,步骤二中的一个源端日志传输进程只对应着一个目的端,即开启多少日志传输进程根据要同步的目的端数据库数量而定。
优选地,步骤二中的目的端服务器不在线时,日志传输进程将日志文件暂时存储在源端服务器硬盘上,日志优化进程根据未传输的日志文件里的记录冗余改动来将日志文件重构为新的日志文件,源端服务器管理进程在满足以下任何条件的时机通知日志优化进程对硬盘上的未传输的日志文件进行优化重构:
a)定时器到达一小时;
b)未传输的日志文件占用空间达到阈值(由参数MAX_REDO_SIZE控制);
c)未传输的日志文件数量达到阈值(由参数MAX_REDO_FILE_NUM控制)。
优选地,步骤二中的源端服务器管理进程在满足以下任何条件的时机通知日志优化进程对硬盘上的日志文件进行删除:
a)确认日志传输进程将日志文件传输到所有的目的端服务器后;
b)未传输但已完成重构的日志文件占用空间达到阈值(由参数MAX_REDO_SIZE控制);
c)未传输但已完成重构的日志文件数量达到阈值(由参数MAX_REDO_FILE_NUM控制)。
优选地,步骤三中的目的端服务器管理进程负责日志接收进程和日志解析进程的启动与系统资源调度。
优选地,步骤三中的一个目的端日志解析进程只对应着一个源端,即开启多少日志解析进程跟要要同步的源端数据库数量而定。
优选地,步骤四中的目的端数据库未启动时,日志接收进程将日志文件暂时存储在所在服务器硬盘上,日志优化进程根据未应用的日志文件里的记录冗余改动来将日志文件重构为新的日志文件,目的端服务器管理进程在满足以下任何条件的时机通知日志优化进程对硬盘上的未应用的日志文件进行优化重构:
a)定时器到达一小时;
b)未应用的日志文件占用空间达到阈值(由参数MAX_REDO_SIZE控制);
c)未应用的日志文件数量达到阈值(由参数MAX_REDO_FILE_NUM控制)。
优选地,步骤四中的目的端服务器管理进程在满足以下任何条件的时机通知日志优化进程对硬盘上的日志文件进行删除:
a)确认日志解析进程将日志文件应用到目的端数据库后;
b)未应用但已完成重构的日志文件占用空间达到阈值(由参数MAX_REDO_SIZE控制);
c)未应用但已完成重构的日志文件数量达到阈值(由参数MAX_REDO_FILE_NUM控制)。
优选地,步骤四中目的端服务器日志解析进程将日志文件解析后进行结果合并时,如果发现主键冲突,则提交冲突信息并告警,冲突条件包含但不限于:
a)相同主键的记录插入(insert)只能由相同源端进行操作;
b)相同主键的记录修改(update)只能由相同源端进行操作。
优选地,步骤四中目的端服务器日志解析进程在DDL和DML操作写入到目的端数据库时若发生异常,主动回滚事务,提交错误信息并告警。
上述优选技术特征只要彼此之间未构成冲突就可以相互组合。
总体而言,通过本发明所构思的以上技术方案与现有技术相比,具有以下有益效果:
1、本发明的数据同步日志优化方法,利用数据库日志中存储的数据库操作的可恢复性,持续对日志文件进行优化压缩,将日志文件传到目的端数据库完成数据库之间的异地同步。该方案使用极小的系统资源与带宽,兼顾多种异常网络场景处理,并且规避了重复冗余数据提交带来的恢复数据过大的问题。该发明具有可实用性,同时提升了数据同步的可用性,数据库的防灾以及可维护性。
2、本发明提出一种可对日志文件进行优化重构并及时删除的数据库同步方案,该方案具有兼顾已有数据库同步技术的实时性,多场景应用与轻量级带宽的优势。
3、在上述优势的基础上,引入了对日志文件进行优化重构的日志优化进程,该进程受管理进程的管理并接收通知,当管理进程发现满足日志优化重构或删除的先置条件时,通知日志优化进程对日志文件进行优化,无需用户干预,根据先置条件对日志文件进行优化重构,保证了数据库同步功能的可持久性运行。
附图说明
图1是本发明实施例的数据同步日志优化方法的构架示意图;
图2是本发明实施例的数据同步日志优化方法中源端服务器的管理进程的示意图;
图3是本发明实施例的数据同步日志优化方法中源端日志文件优化重构的示意图;
图4是本发明实施例的数据同步日志优化方法中冲突处理的示意图;
图5是本发明实施例的数据同步日志优化方法中目的端日志文件优化重构的示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面结合具体实施方式对本发明进一步详细说明。
根据在数据同步中担任的角色不同,分为源端服务器与目的端服务器两种场景,如图1所示。
1.在源端服务器场景中,首先打开数据库归档日志模式,数据库开始自动将对数据库的所有DML和DDL操作记录到日志文件中。
启动源端服务器的管理进程,管理进程将其它线程依次启动,并为日志传输进程分配端口和系统资源,开启定时器任务以及日志文件监听任务(图2)。
源端服务器管理进程定时器任务主要包括每一小时通知日志优化进程进行日志文件优化重构。
源端服务器管理进程监听任务主要包括监听日志文件的状态,大小和数量,其中包括各日志文件是否完成重构;未传输的日志文件占用空间是否达到阈值(由参数MAX_REDO_SIZE控制);未传输的日志文件数量是否达到阈值(由参数MAX_REDO_FILE_NUM控制);未传输但已完成重构的日志文件占用空间是否达到阈值(由参数MAX_REDO_SIZE控制);未传输但已完成重构的日志文件数量是否达到阈值(由参数MAX_REDO_FILE_NUM控制);
所有日志传输进程和日志解析进程启动后主动向管理进程上报日志加载点(RedoLoadPoint),管理进程根据各日志传输进程上报的RedoLoadPoint询查出已完成传输的日志文件,然后通知日志优化进程进行日志文件删除。
假设数据库中完成了一次会话提交,会话中包含:表A的数据插入A1-A5,表B的数据更新B1-B3(由B1’-B3’更新到B1”-B3”),表C的数据删除C1-C2。数据库将这次会话提交的内容写入到归档日志文件中。源端管理进程监听到日志文件的改动,即刻通知日志传输进程将该日志传输到目的端并等待日志传输进程的传输结果应答。
假设有5个日志传输进程R1-R5(RTT,RedoLogTransmitThread)对应5个目的端,并且日志传输进程R1-R3探测到目的端服务器在线,即刻开始进行日志文件传输并在完成传输后更新RedoLoadPoint,日志传输进程R4、R5因为目的端服务器不在线而保持探测状态,不更新RedoLoadPoint。
此时数据库持续进行会话提交,会话内容包含:表A的数据删除A1-A2,表B的数据更新B1-B3(由B1”-B3”更新到B1”’-B3”’)。数据库将这次会话提交的内容写入到归档日志文件中。源端管理进程监听到日志文件的改动,即刻通知日志传输进程将该日志传输到目的端并等待日志传输进程的传输结果应答。
日志传输进程R1-R3探测到目的端服务器在线,即刻开始进行日志文件传输并在完成传输后更新RedoLoadPoint,日志传输进程R4、R5因为目的端服务器不在线而保持探测状态,依旧不更新RedoLoadPoint。
某时某刻,源端管理进程满足日志文件优化先置条件(定时器到达一小时;未传输的日志文件占用空间达到阈值;未传输的日志文件数量达到阈值),因日志传输进程R4、R5对应的目的端服务器持续不在线,通知日志优化进程对这两次会话的日志文件进行优化重构,优化后的内容包含:表A的数据插入A3-A5,表B的数据更新(由B1’-B3’更新到B1”’-B3”’),表C的数据删除C1-C2(图3)。
某时某刻,日志传输进程R4探测到对应的目的端服务器上线,即刻根据RedoLoadPoint开始向目的端传输日志文件,传输完成后更新RedoLoadPoint并指向日志文件末尾。
某时某刻,源端管理进程满足日志文件删除先置条件(确认日志传输进程将日志文件传输到所有的目的端服务器后;未传输但已完成重构的日志文件占用空间达到阈值;未传输但已完成重构的日志文件数量达到阈值),通知日志优化进程启动对日志文件的删除作业。
2.在目的端服务器场景中,首先启动目的端服务器的管理进程,管理进程将其它线程依次启动,并为日志接收进程分配端口和系统资源,开启定时器任务以及日志文件监听任务(图2)。
目的端管理进程定时器任务主要包括每一小时通知日志优化进程进行日志文件优化重构。
目的端管理进程监听任务主要包括监听日志文件的状态,大小和数量,其中包括各日志文件是否完成重构;未应用的日志文件占用空间是否达到阈值(由参数MAX_REDO_SIZE控制);未应用的日志文件数量是否达到阈值(由参数MAX_REDO_FILE_NUM控制);未应用但已完成重构的日志文件占用空间是否达到阈值(由参数MAX_REDO_SIZE控制);未应用但已完成重构的日志文件数量是否达到阈值(由参数MAX_REDO_FILE_NUM控制);
所有日志传输进程和日志解析进程启动后主动向管理进程上报日志加载点(RedoLoadPoint),管理进程根据各日志传输进程上报的RedoLoadPoint询查出已完成应用的日志文件,然后通知日志优化进程进行日志文件删除。
假设目的端日志接收线程接收到两份新的日志文件,源端1的日志文件1包含表A的数据插入A3-A5,表B的数据更新(由B1-B3更新到B1’-B3’),表C的数据删除C1-C2。源端2的日志文件2包含表A的数据插入A3’(与日志文件1中的A3同主键但内容不同),表B的数据更新(由B1-B3更新到B1”-B3”),表C的数据删除C1。
日志接收线程立刻通知管理线程,管理线程分配给对应的日志解析线程进行解析。日志解析线程对相应的日志文件进行解析后,将解析结果进行合并,发现主键冲突(表A和表B相同主键的记录来源于不同源端),提交冲突信息并告警。
用户手动解决冲突信息,并提交解决冲突后的结果,即表A的数据插入A3-A5,A6(原A3’但主键不同),表B的数据更新(B1到B1’,B2到B2”,B3到B3’),表C的数据删除C1-C2。日志解析线程接收用户提交的解决冲突后的结果(图4)。
如果日志解析线程探测到数据库已启动,则将DDL和DML操作写入到目的端数据库,并将RedoLoadPoint指向日志文件末尾。
如果日志解析线程探测到数据库未启动,则将用户提交的解决冲突后的结果生成新的日志文件,并删除原始日志文件。
目的端日志接收进程持续接收日志文件,日志接收进程此时接收到源端的日志文件3包含表A的数据更新A3更新到A3’,表B的数据删除B1’。
某时某刻,目的端管理进程满足日志文件优化先置条件(定时器到达一小时;未应用的日志文件占用空间达到阈值;未应用的日志文件数量达到阈值),因数据库持续不在线,管理进程通知日志优化进程对日志文件进行优化,优化后的内容包含:表A的数据插入A3’,A4,A5,表B的数据更新B2到B2”,B3到B3’,表B的数据删除B1,表C的数据删除C1-C2(图5)。
某时某刻,目的端管理进程探测到数据库上线,即刻根据RedoLoadPoint开始向目的端数据库应用重构后的日志文件,应用完成后更新RedoLoadPoint并指向日志文件末尾。
某时某刻,目的端管理进程满足日志文件删除先置条件(确认日志解析进程将日志文件应用到目的端数据库后;未应用但已完成重构的日志文件占用空间达到阈值;未应用但已完成重构的日志文件数量达到阈值),通知日志优化进程启动对日志文件的删除作业。
综上所述,与现有技术相比,本发明的方案具有如下显著优势:
1、本发明的数据同步日志优化方法,利用数据库日志中存储的数据库操作的可恢复性,持续对日志文件进行优化压缩,将日志文件传到目的端数据库完成数据库之间的异地同步。该方案使用极小的系统资源与带宽,兼顾多种异常网络场景处理,并且规避了重复冗余数据提交带来的恢复数据过大的问题。该发明具有可实用性,同时提升了数据同步的可用性,数据库的防灾以及可维护性。
2、本发明提出一种可对日志文件进行优化重构并及时删除的数据库同步方案,该方案具有兼顾已有数据库同步技术的实时性,多场景应用与轻量级带宽的优势。
3、在上述优势的基础上,引入了对日志文件进行优化重构的日志优化进程,该进程受管理进程的管理并接收通知,当管理进程发现满足日志优化重构或删除的先置条件时,通知日志优化进程对日志文件进行优化,无需用户干预,根据先置条件对日志文件进行优化重构,保证了数据库同步功能的可持久性运行。
可以理解的是,以上所描述的系统的实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,既可以位于一个地方,或者也可以分布到不同网络单元上。可以根据实际需要选择其中的部分或全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
另外,本领域内的技术人员应当理解的是,在本发明实施例的申请文件中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本发明实施例的说明书中,说明了大量具体细节。然而应当理解的是,本发明实施例的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。类似地,应当理解,为了精简本发明实施例公开并帮助理解各个发明方面中的一个或多个,在上面对本发明实施例的示例性实施例的描述中,本发明实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。
然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明实施例的单独实施例。
最后应说明的是:以上实施例仅用以说明本发明实施例的技术方案,而非对其限制;尽管参照前述实施例对本发明实施例进行了详细的说明,本领域的技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明实施例各实施例技术方案的精神和范围。
Claims (14)
1.一种数据同步日志优化方法,其特征在于,包括如下步骤:
步骤一:源端数据库监听数据库中的所有DDL和DML操作,并将监听到的DDL和DML操作写入到日志文件并存储到硬盘空间;
步骤二:启动源端服务器管理进程,包括日志优化进程和日志传输进程;日志优化进程不定时对日志文件进行优化重构或删除;同时日志传输进程将生成的日志文件传输到目的端服务器;
步骤三:启动目的端服务器管理进程,包括日志接收进程、日志优化进程和日志解析进程;目的端服务器的日志接收进程接收到日志文件后将日志文件交付给日志解析进程,同时日志优化进程不定时对日志文件进行优化重构或删除;
步骤四:目的端服务器日志解析进程解析日志文件并将记录到的DDL和DML操作写入到目的端数据库中。
2.如权利要求1所述的数据同步日志优化方法,其特征在于:
所述源端数据库与目的端数据库为同一型数据库或不同型数据库,但都支持SQL,以便进行数据的更新。
3.如权利要求1所述的数据同步日志优化方法,其特征在于:
所述源端数据库与目的端数据库的数量应满足实现一对一或一对多或多对一或多对多,以及实现双向复制。
4.如权利要求1所述的数据同步日志优化方法,其特征在于:
在步骤一里的源端数据库支持归档模式,在该模式下可将用户的DDL与DML操作写入到归档日志文件中。
5.如权利要求1所述的数据同步日志优化方法,其特征在于:
在步骤一里的源端服务器管理进程负责日志传输进程和日志优化进程的启动与系统资源调度,同时负责所有定时以及监控日志文件的任务。
6.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤二中的一个源端日志传输进程只对应着一个目的端,即开启多少日志传输进程根据要同步的目的端数据库数量而定。
7.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤二中的目的端服务器不在线时,日志传输进程将日志文件暂时存储在源端服务器硬盘上,日志优化进程根据未传输的日志文件里的记录冗余改动来将日志文件重构为新的日志文件,源端服务器管理进程在满足以下任何条件的时机通知日志优化进程对硬盘上的未传输的日志文件进行优化重构:
a)定时器到达一小时;
b)未传输的日志文件占用空间达到阈值;
c)未传输的日志文件数量达到阈值。
8.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤二中的源端服务器管理进程在满足以下任何条件的时机通知日志优化进程对硬盘上的日志文件进行删除:
a)确认日志传输进程将日志文件传输到所有的目的端服务器后;
b)未传输但已完成重构的日志文件占用空间达到阈值;
c)未传输但已完成重构的日志文件数量达到阈值。
9.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤三中的目的端服务器管理进程负责日志接收进程和日志解析进程的启动与系统资源调度。
10.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤三中的一个目的端日志解析进程只对应着一个源端,即开启多少日志解析进程跟要要同步的源端数据库数量而定。
11.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤四中的目的端数据库未启动时,日志接收进程将日志文件暂时存储在所在服务器硬盘上,日志优化进程根据未应用的日志文件里的记录冗余改动来将日志文件重构为新的日志文件,目的端服务器管理进程在满足以下任何条件的时机通知日志优化进程对硬盘上的未应用的日志文件进行优化重构:
a)定时器到达一小时;
b)未应用的日志文件占用空间达到阈值;
c)未应用的日志文件数量达到阈值。
12.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤四中的目的端服务器管理进程在满足以下任何条件的时机通知日志优化进程对硬盘上的日志文件进行删除:
a)确认日志解析进程将日志文件应用到目的端数据库后;
b)未应用但已完成重构的日志文件占用空间达到阈值;
c)未应用但已完成重构的日志文件数量达到阈值。
13.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤四中目的端服务器日志解析进程将日志文件解析后进行结果合并时,如果发现主键冲突,则提交冲突信息并告警,冲突条件包含:
a)相同主键的记录插入只能由相同源端进行操作;
b)相同主键的记录修改只能由相同源端进行操作。
14.如权利要求1所述的数据同步日志优化方法,其特征在于:
步骤四中目的端服务器日志解析进程在DDL和DML操作写入到目的端数据库时若发生异常,主动回滚事务,提交错误信息并告警。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011275703.7A CN112433992B (zh) | 2020-11-16 | 2020-11-16 | 一种数据同步日志优化方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011275703.7A CN112433992B (zh) | 2020-11-16 | 2020-11-16 | 一种数据同步日志优化方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112433992A true CN112433992A (zh) | 2021-03-02 |
CN112433992B CN112433992B (zh) | 2023-06-02 |
Family
ID=74701199
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011275703.7A Active CN112433992B (zh) | 2020-11-16 | 2020-11-16 | 一种数据同步日志优化方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112433992B (zh) |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150234906A1 (en) * | 2014-02-18 | 2015-08-20 | International Business Machines Corporation | Synchronizing data-sets |
CN107357848A (zh) * | 2017-06-27 | 2017-11-17 | 中国电子科技集团公司第二十八研究所 | 基于驱动封装的数据库同步方法 |
US20180260287A1 (en) * | 2017-03-07 | 2018-09-13 | Sap Se | Caching DML Statement Context During Asynchronous Database System Replication |
CN109241185A (zh) * | 2018-08-27 | 2019-01-18 | 武汉达梦数据库有限公司 | 一种数据同步的方法以及数据同步装置 |
CN109656934A (zh) * | 2018-11-19 | 2019-04-19 | 武汉达梦数据库有限公司 | 基于日志解析的源端Oracle数据库DDL同步方法及设备 |
CN111221909A (zh) * | 2019-12-31 | 2020-06-02 | 武汉达梦数据库有限公司 | 一种基于日志解析的数据库修改列同步方法和装置 |
CN111241094A (zh) * | 2019-12-31 | 2020-06-05 | 武汉达梦数据库有限公司 | 一种基于日志解析的数据库删除列同步方法和装置 |
-
2020
- 2020-11-16 CN CN202011275703.7A patent/CN112433992B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150234906A1 (en) * | 2014-02-18 | 2015-08-20 | International Business Machines Corporation | Synchronizing data-sets |
US20180260287A1 (en) * | 2017-03-07 | 2018-09-13 | Sap Se | Caching DML Statement Context During Asynchronous Database System Replication |
CN107357848A (zh) * | 2017-06-27 | 2017-11-17 | 中国电子科技集团公司第二十八研究所 | 基于驱动封装的数据库同步方法 |
CN109241185A (zh) * | 2018-08-27 | 2019-01-18 | 武汉达梦数据库有限公司 | 一种数据同步的方法以及数据同步装置 |
CN109656934A (zh) * | 2018-11-19 | 2019-04-19 | 武汉达梦数据库有限公司 | 基于日志解析的源端Oracle数据库DDL同步方法及设备 |
CN111221909A (zh) * | 2019-12-31 | 2020-06-02 | 武汉达梦数据库有限公司 | 一种基于日志解析的数据库修改列同步方法和装置 |
CN111241094A (zh) * | 2019-12-31 | 2020-06-05 | 武汉达梦数据库有限公司 | 一种基于日志解析的数据库删除列同步方法和装置 |
Non-Patent Citations (1)
Title |
---|
王锐;刘杰;: "Oracle远程数据库同步方法研究", 煤炭技术 * |
Also Published As
Publication number | Publication date |
---|---|
CN112433992B (zh) | 2023-06-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10929428B1 (en) | Adaptive database replication for database copies | |
US9934237B1 (en) | Metadata optimization for network replication using representative of metadata batch | |
US10095708B2 (en) | Data mobility, accessibility, and consistency in a data storage system | |
US9613046B1 (en) | Parallel optimized remote synchronization of active block storage | |
US9798486B1 (en) | Method and system for file system based replication of a deduplicated storage system | |
US9110964B1 (en) | Metadata optimization for network replication using differential encoding | |
US9773042B1 (en) | Method and system for accelerating data movement using change information concerning difference between current and previous data movements | |
CN114127695A (zh) | 到文件系统同步复制关系端点的重新同步 | |
US11074224B2 (en) | Partitioned data replication | |
US20220114064A1 (en) | Online restore for database engines | |
US7415467B2 (en) | Database replication system | |
US20220043777A1 (en) | Inofile management and access control list file handle parity | |
US20140279912A1 (en) | Client object replication between a first backup server and a second backup server | |
US11816348B2 (en) | Persistent hole reservation | |
US20210365187A1 (en) | Freeing and utilizing unused inodes | |
US10628298B1 (en) | Resumable garbage collection | |
US11907261B2 (en) | Timestamp consistency for synchronous replication | |
US20100217857A1 (en) | Consolidating session information for a cluster of sessions in a coupled session environment | |
US10909143B1 (en) | Shared pages for database copies | |
US20230081436A1 (en) | Dependency aware parallel splitting of operations | |
US10331362B1 (en) | Adaptive replication for segmentation anchoring type | |
US9361302B1 (en) | Uniform logic replication for DDFS | |
US11226878B1 (en) | Accelerator-based database recovery | |
US11150964B1 (en) | Sequential processing of changes in a distributed system | |
CN111352766A (zh) | 一种数据库的双活实现方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |