CN105574187A - Duplication transaction consistency guaranteeing method and system for heterogeneous databases - Google Patents
Duplication transaction consistency guaranteeing method and system for heterogeneous databases Download PDFInfo
- Publication number
- CN105574187A CN105574187A CN201510976842.5A CN201510976842A CN105574187A CN 105574187 A CN105574187 A CN 105574187A CN 201510976842 A CN201510976842 A CN 201510976842A CN 105574187 A CN105574187 A CN 105574187A
- Authority
- CN
- China
- Prior art keywords
- transaction
- affairs
- destination
- submit
- transaction table
- 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
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/18—File system types
- G06F16/182—Distributed file systems
- G06F16/184—Distributed file systems implemented as replicated file system
-
- 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/17—Details of further file system functions
- G06F16/1734—Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention provides a duplication transaction consistency guaranteeing method and system for heterogeneous databases based on a committing list. In the environment that logs are used for duplicating the heterogeneous databases, a committing transaction list is used for recoding target terminal databases, so that the transaction process is completed, and examination on restoring of a starting point is executed regularly. When system failures are duplicated, the committing transaction list is used for determining the starting position of a transaction log which needs to be retransmitted. According to the duplication transaction consistency guaranteeing method and system disclosed by the invention, heterogeneous database duplication based on the transaction list is adopted, so as to solve the technical problem that the data of a source database is inconsistent with that of a target database because the transaction execution of the source database is likely to be inconsistent with the transaction execution of the target database.
Description
Technical field
The present invention relates to a kind of transaction consistency support method of Heterogeneous Database Replication, espespecially a kind of Heterogeneous Database Replication transaction consistency support method and system submitting table based on affairs to.
Background technology
Along with the widespread use of Enterprise Informatization system, information system has become the key that enterprise maintains business running.The diversified type of service of enterprise causes data access demand increasingly complex, and the sharply soaring of data volume also causes database server can't bear the heavy load simultaneously.Enterprise, in the urgent need to improving the availability of infosystem, ensures the continuity of business, reduces the loss brought because of disaster or fault to greatest extent.For this reason, the data Replica of Distributed Heterogeneous Database is a kind of conventional technological means.
At present, extract the transaction journal of source database, obtain the data manipulation of source database, comprise insertion (INSERT), delete (DELETE), upgrade (UPDATE), then the destination of dubbing system is sent to by network, destination reverts to original SQL statement and performs on destination data storehouse, is a kind of conventional database replication technology.It has on the performance of source database and data pattern impact little, mode very flexibly can be adopted to configure various topological structure, support across advantages such as the operating system of isomery and database platform copy.
Ensureing the transaction consistency of destination data storehouse and source database, and under any hardware and software failure, possess the ability recovering data Replica, is the problem that this dubbing system needs to consider.Some data copy systems of current existence, the GoldenGate of such as Oracle, by the file management Copy Info of self, the transaction journal be drawn into is preserved in the file of source and destination, when hardware and software failure appears in system, according to the daily record executing location of preserving in file, the information such as position are extracted in daily record, again position in the transaction journal of source database, continue data Replica process.
But the file management that in said method, dubbing system uses, independent of the transaction management in destination data storehouse, cannot ensure the consistance copying affairs.Such as, first dubbing system destination submits affairs to, in the file of oneself, then register ID and LSN of these affairs, before file flushes to not volatile storage medium reliably, there occurs fault.After system reboot, because the affairs in destination data storehouse are submitted to, the fault recovery of this database and transaction management mechanism will ensure the persistence of affairs, namely affairs enter into force for the impact of data, but the internal file of dubbing system does not correctly register this information, when causing recovering data Replica, the daily record of these affairs is passed to destination data storehouse and is performed by dubbing system again, same affairs perform repeatedly, and the affairs causing source database and destination data storehouse are inconsistent.
As can be seen here, traditional dubbing system utilizes own files to manage Copy Info, cannot ensure the consistance that source database and destination data storehouse both sides' affairs perform, and needs the transaction consistency support method inventing new Heterogeneous Database Replication.
Summary of the invention
The invention provides a kind of transaction consistency support method and system of Heterogeneous Database Replication, its object is to, solve existing Heterogeneous Database Replication system when adopting data Replica based on transaction journal, source database and destination data storehouse both sides' affairs perform the inconsistency that may exist, and cause the technical matters that both data is inconsistent.
In order to solve the problem, the present invention by the following technical solutions:
Based on the Heterogeneous Database Replication transaction consistency support method submitting table to, comprise the steps:
The operation steps of destination data storehouse and source database transactional synchronization, is specially: create in destination data storehouse and submit transaction table to, create and do not submit transaction table in the internal memory of dubbing system destination; From source database, obtain the Operation Log of affairs, dubbing system destination performs corresponding data manipulation according to described Operation Log in destination data storehouse; Affairs first time operation information is inserted as a record and does not submit transaction table to, the last submit operation information of affairs is inserted as a record and submits transaction table to, never submit in transaction table simultaneously and delete the record submitting affairs to;
The quantitative check step of dubbing system destination, be specially: find affairs that not yet submit to, that occur the earliest not submitting in transaction table, submit in transaction table all transaction journals of deleting before these affairs to, submit to insertion one in transaction table to comprise the check point record of transaction information that not yet submit to, that occur the earliest simultaneously;
Fault recovery step, is specially: obtain transaction information that not yet submit to, that occur the earliest from the check point record submitted to transaction table, and dubbing system source is using these affairs as recovery starting point, and the Operation Log that affairs are relevant sends to destination; If the record of not corresponding affairs of this daily record in submission transaction table, then dubbing system destination performs corresponding data according to the Operation Log received and operates in destination data storehouse.
Further, the specific implementation process of described destination data storehouse and master data base transactional synchronization step is:
11) create submission transaction table in destination data storehouse, create in dubbing system destination internal memory and do not submit transaction table to;
12) extract the Operation Log in source database, Operation Log comprises affairs ID, transaction sequence LSN and content;
13) if the affairs ID of Operation Log occurs first time, what show to be drawn into is the Article 1 Operation Log of affairs, then insertion one in transaction table is not being submitted to comprise the transaction journal of affairs Article 1 Operation Log LSN information, the data manipulation that execution journal content is specified, returns step 12); Otherwise, perform step 14);
14) if the log content be drawn into is shown to be submit operation, then step 15 is performed); If the log content be drawn into is shown to be the data manipulation beyond submission, then perform step 16);
15) insert at submission transaction table the transaction journal that comprises affairs submit operation daily record LSN information, the all data manipulations submitting to transaction table and affairs to relate to are carried out affairs submission in the lump, never submits in transaction table the transaction journal of deleting and equaling to submit affairs ID to;
16) perform corresponding data operation, return step 12);
Further, the specific implementation process of the quantitative check step in described destination data storehouse is:
21) do not submitting in transaction table the record finding sequence number LSN minimum to, corresponding current affairs that not yet submit to, that occur the earliest, remember that the sequence number LSN of this record is LSN0;
22) all records deleted in transaction table and be less than or equal to LSN0 are being submitted to;
23) in submission transaction table, insert a check point record, check point record includes LSN0 information;
Further, the specific implementation process of described fault recovery step is:
31) dubbing system source sends the request of inquiry checkpoint to dubbing system destination;
32) dubbing system destination is at destination data library inquiry to check point record, and the LSN0 information feed back stored is to dubbing system source;
33) dubbing system source searches for the transaction journal that equals LSN0 as recovery starting point in the Operation Log file of source database, successively these affairs and subsequent transaction associated oplog is sent to dubbing system destination.
34) dubbing system destination is searched for according to the affairs ID of the Operation Log recovered in destination data storehouse in submission transaction table, equals the transaction journal of affairs ID, then inoperation if search, and terminates; Otherwise according to the Operation Log recovered, corresponding data operation is performed to destination data storehouse.
Based on the Heterogeneous Database Replication transaction consistency safeguards system submitting table to, comprising: source database, destination data storehouse, dubbing system, be created in destination data storehouse submission transaction table, be created in dubbing system destination internal memory do not submit transaction table to;
The Operation Log of affairs in source database is transmitted to destination by dubbing system source, and destination performs corresponding data manipulation in destination data storehouse; Destination does not submit the first time operation information of the affairs received to transaction table as a record insertion, the last submit operation information of affairs is inserted as a record and submits transaction table to, never submit in transaction table and delete the record submitting affairs to;
The timing of dubbing system destination finds affairs that not yet submit to, that occur the earliest not submitting in transaction table, submit in transaction table all transaction journals of deleting before these affairs to, submit to insertion one in transaction table to comprise the check point record of transaction information that not yet submit to, that occur the earliest simultaneously;
Dubbing system destination obtains transaction information that not yet submit to, that occur the earliest from the check point record submitted to transaction table, the Operation Log that these affairs in source database and subsequent transaction are correlated with, using these affairs as recovery starting point, is sent to destination by dubbing system source; If the record of not these affairs in submission transaction table, then dubbing system destination performs corresponding data operation according to the Operation Log received in destination data storehouse.
The present invention contrasts prior art following superiority:
The present invention utilizes a submission transaction table in destination data storehouse to preserve the affairs submitted to and the affairs the earliest not yet submitted to, the renewal of this table is submitted in the lump with corresponding affairs, take full advantage of the fault recovery function in destination data storehouse self, the information that the operation and affairs that copy affairs self perform is synthesized affairs, submits to together.So, the atomicity of affairs ensure that the consistance that the data manipulation of affairs self and the information of affairs successful execution store, and the information storage that affairs perform is the foundation of dubbing system fault recovery, thus ensure that transaction consistency and the data consistency of Heterogeneous Database Replication.Overcome checkpoint information and the issuable inconsistency of destination data storehouse Separate Storage of dubbing system in classic method.
Accompanying drawing explanation
Fig. 1 is reconstructed model schematic diagram of the present invention.
Fig. 2 be the present invention in data Replica process, for submitting transaction table to and not submitting the management process schematic diagram of transaction table to.
Fig. 3 is the schematic flow sheet of checkpoint of the present invention process.
Fig. 4 is the schematic flow sheet of failover procedure of the present invention.
Fig. 5 is according to an example of the present invention schematic diagram, wherein, Fig. 5 (a) submits transaction table the t1 moment to and does not submit transaction table schematic diagram to, Fig. 5 (b) for check point record insertion process schematic diagram, Fig. 5 (c) be failover procedure schematic diagram.
Embodiment
In order to make object of the present invention, technical scheme and advantage clearly understand, below in conjunction with drawings and Examples, the present invention is further elaborated.Should be appreciated that specific embodiment described herein only in order to explain the present invention, be not intended to limit the present invention.In addition, if below in described each embodiment of the present invention involved technical characteristic do not form conflict each other and just can mutually combine.
The present invention comprises three steps: the operation steps of destination data storehouse and master data base transactional synchronization, the quantitative check step in destination data storehouse and fault recovery step.The following detailed description of:
Fig. 2 is the operation steps process flow diagram of the object of the invention database and master data base transactional synchronization, is specially:
11) create one in destination data storehouse and submit transaction table to, field requires as follows.
In the internal memory of dubbing system, create one and do not submit transaction table to, field requires as follows.
12) at source database, dubbing system extracts the Operation Log in source database, and log packet is containing affairs ID, transaction sequence LSN and content.
13) if the affairs ID of Operation Log occurs first time, what show to be drawn into is the Article 1 Operation Log of affairs, then insertion one in transaction table is not being submitted to comprise the transaction journal of affairs Article 1 Operation Log LSN information, the data manipulation that execution journal content is specified, returns step 12); Otherwise, perform step 14).
14) if the log content be drawn into is shown to be submit operation, then step 15 is performed); If the log content be drawn into is shown to be data manipulation beyond submission such as INSERT, DELETE, UPDATE, then perform step 16).
15) insert at submission transaction table the transaction journal that comprises affairs submit operation daily record LSN information, the all data manipulations submitting to transaction table and affairs to relate to are carried out affairs submission in the lump, never submits in transaction table the transaction journal of deleting and equaling to submit affairs ID to.
16) generate statement corresponding to this daily record in destination data storehouse and perform corresponding data operation, returning step 12).
Fig. 3 is the quantitative check flow chart of steps of the object of the invention database, by timer, and clocked flip checkpoint process, the time is to execution following steps:
21) do not submitting in transaction table the record finding sequence number LSN minimum to, corresponding current affairs that not yet submit to, that occur the earliest, remember that the sequence number LSN of this record is LSN0.
22) all records deleted in transaction table and be less than or equal to LSN0 are being submitted to, i.e. perform statement: DELETEFROM " submission transaction table " WHERE " submission LSN " <=LSN0.
Transaction table is submitted in the cleaning of this step to, and for before affairs start for not submitting to of occurring the earliest, the submission affairs just submitted to, preserving without the need to continuing, therefore being cleaned out in submission transaction table.
Also it should be noted that, the not only transaction journal of deleting here, also deletes the check point record equaling LSN0.Check point record refers in step 23) detailed description.
23) in submission transaction table, insert a check point record, check point record includes LSN0 information.
In order to distinguish with transaction journal, can arrange separately " affairs ID " field value of check point record, for example be set to 0, because the ID of normal transaction is a positive integer, Transaction ID field be 0 record one special, represent the record of checkpoint, this record " submitting LSN field to " equals LSN0, when representative occurs in this checkpoint, all affairs occurred the earliest not submitting affairs to, the daily record LSN of its Article 1 operation.I.e. perform statement: INSERTINTO " submission transaction table " VALUES (0, LSN0).
Fig. 4 displaying duplication system stops because of the system failure, restarts the reference position that rear source determines according to the record of submission table in destination data storehouse to copy.Detailed process is:
When dubbing system is because communication failure, after dubbing system or source database or destination data storehouse system failure abnormal end, restart dubbing system.
31) source sends the request of inquiry checkpoint to destination.
32) destination inquires check point record in the submission table in destination data storehouse, and the LSN0 information feed back stored is to source; I.e. perform statement: SELECT " submission LSN " FROM " submission transaction table " WHERE " affairs ID "=0.
33) source searches for the transaction journal that equals LSN0 as recovery starting point in source database journal file, successively by subsequent operation Log Sender to destination.
The affairs being less than the daily record of this LSN0 corresponding are submitted to all in destination data storehouse, perform without the need to row again.
34) after destination receives transaction journal, according to search in the affairs ID in log recording to " submission transaction table ".I.e. perform statement:
SELECT*FROM " submission transaction table " the affairs ID that WHERE " affairs ID "=log recording is corresponding.
Affairs ID submission transaction table in exist, i.e. step 65) SELECT statement result collection be sky, then ignore this log recording, if it is empty, then destination generates statement corresponding to this daily record and is performing on destination data storehouse.
Above step 31), 32), 33), 34) move in circles execution, until dubbing system recovers normal
The following detailed description of an example:
Fig. 5 (a) submits transaction table the t1 moment to and does not submit transaction table schematic diagram to, destination data storehouse is when first time receives the daily record of affairs ID=3, do not submitting in transaction table the record inserting affairs ID=3, LSN=99 to, when submitting the affairs of affairs ID=2 to, do not submit in transaction table the record inserting affairs ID=3, LSN=98 to, do not submit in transaction table the transaction journal of deleting ID=2 to.
Fig. 5 (b) is check point record insertion process schematic diagram, do not submit in transaction table show ID=3, the affairs of initial LSN=99 are the affairs occurred the earliest not yet submitted to, namely the record then deleted in affairs submission table early than these affairs deletes the record of affairs ID=2, LSN=98, inserts the check point record of affairs ID=0, LSN=99 simultaneously.
Fig. 5 (c) is failover procedure schematic diagram.In submission transaction table, find check point record, know that recovering starting point is the affairs of ID=3, LSN=99.
Those skilled in the art will readily understand; the foregoing is only preferred embodiment of the present invention; not in order to limit the present invention, all any amendments done within the spirit and principles in the present invention, equivalent replacement and improvement etc., all should be included within protection scope of the present invention.
Claims (5)
1., based on the Heterogeneous Database Replication transaction consistency support method submitting table to, it is characterized in that, comprise the steps:
The operation steps of destination data storehouse and source database transactional synchronization, is specially: create in destination data storehouse and submit transaction table to, create and do not submit transaction table in the internal memory of dubbing system destination; From source database, obtain the Operation Log of affairs, dubbing system destination performs corresponding data manipulation according to described Operation Log in destination data storehouse; Affairs first time operation information is inserted as a record and does not submit transaction table to, the last submit operation information of affairs is inserted as a record and submits transaction table to, never submit in transaction table simultaneously and delete the record submitting affairs to;
The quantitative check step of dubbing system destination, be specially: find affairs that not yet submit to, that occur the earliest not submitting in transaction table, submit in transaction table all transaction journals of deleting before these affairs to, submit to insertion one in transaction table to comprise the check point record of transaction information that not yet submit to, that occur the earliest simultaneously;
Fault recovery step, is specially: obtain transaction information that not yet submit to, that occur the earliest from the check point record submitted to transaction table, and dubbing system source is using these affairs as recovery starting point, and the Operation Log that affairs are relevant sends to destination; If the record of not corresponding affairs of this daily record in submission transaction table, then dubbing system destination performs corresponding data according to the Operation Log received and operates in destination data storehouse.
2. the Heterogeneous Database Replication transaction consistency support method based on submitting table to according to claim 1, it is characterized in that, the specific implementation process of described destination data storehouse and master data base transactional synchronization step is:
11) create submission transaction table in destination data storehouse, create in dubbing system destination internal memory and do not submit transaction table to;
12) extract the Operation Log in source database, Operation Log comprises affairs ID, transaction sequence LSN and content;
13) if the affairs ID of Operation Log occurs first time, what show to be drawn into is the Article 1 Operation Log of affairs, then insertion one in transaction table is not being submitted to comprise the transaction journal of affairs Article 1 Operation Log LSN information, the data manipulation that execution journal content is specified, returns step 12); Otherwise, perform step 14);
14) if the log content be drawn into is shown to be submit operation, then step 15 is performed); If the log content be drawn into is shown to be the data manipulation beyond submission, then perform step 16);
15) insert at submission transaction table the transaction journal that comprises affairs submit operation daily record LSN information, the all data manipulations submitting to transaction table and affairs to relate to are carried out affairs submission in the lump, never submits in transaction table the transaction journal of deleting and equaling to submit affairs ID to;
16) perform corresponding data operation, return step 12).
3. the Heterogeneous Database Replication transaction consistency support method based on submitting table to according to claim 1 and 2, it is characterized in that, the specific implementation process of the quantitative check step in described destination data storehouse is:
21) do not submitting in transaction table the record finding sequence number LSN minimum to, corresponding current affairs that not yet submit to, that occur the earliest, remember that the sequence number LSN of this record is LSN0;
22) all records deleted in transaction table and be less than or equal to LSN0 are being submitted to;
23) in submission transaction table, insert a check point record, check point record includes LSN0 information.
4. the Heterogeneous Database Replication transaction consistency support method based on submitting table to according to claim 3, it is characterized in that, the specific implementation process of described fault recovery step is:
31) dubbing system source sends the request of inquiry checkpoint to dubbing system destination;
32) dubbing system destination is at destination data library inquiry to check point record, and the LSN0 information feed back stored is to dubbing system source;
33) dubbing system source searches for the transaction journal that equals LSN0 as recovery starting point in the Operation Log file of source database, successively these affairs and subsequent transaction associated oplog is sent to dubbing system destination.
34) dubbing system destination is searched for according to the affairs ID of the Operation Log recovered in destination data storehouse in submission transaction table, equals the transaction journal of affairs ID, then inoperation if search, and terminates; Otherwise according to the Operation Log recovered, corresponding data operation is performed to destination data storehouse.
5. the Heterogeneous Database Replication transaction consistency safeguards system based on submission table, it is characterized in that, comprising: source database, destination data storehouse, dubbing system, be created in destination data storehouse submission transaction table, be created in dubbing system destination internal memory do not submit transaction table to;
The Operation Log of affairs in source database is transmitted to destination by dubbing system source, and destination performs corresponding data manipulation in destination data storehouse; Destination does not submit the first time operation information of the affairs received to transaction table as a record insertion, the last submit operation information of affairs is inserted as a record and submits transaction table to, never submit in transaction table and delete the record submitting affairs to;
The timing of dubbing system destination finds affairs that not yet submit to, that occur the earliest not submitting in transaction table, submit in transaction table all transaction journals of deleting before these affairs to, submit to insertion one in transaction table to comprise the check point record of transaction information that not yet submit to, that occur the earliest simultaneously;
Dubbing system destination obtains transaction information that not yet submit to, that occur the earliest from the check point record submitted to transaction table, the Operation Log that these affairs in source database and subsequent transaction are correlated with, using these affairs as recovery starting point, is sent to destination by dubbing system source; If the record of not these affairs in submission transaction table, then dubbing system destination performs corresponding data operation according to the Operation Log received in destination data storehouse.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510976842.5A CN105574187B (en) | 2015-12-23 | 2015-12-23 | A kind of Heterogeneous Database Replication transaction consistency support method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510976842.5A CN105574187B (en) | 2015-12-23 | 2015-12-23 | A kind of Heterogeneous Database Replication transaction consistency support method and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105574187A true CN105574187A (en) | 2016-05-11 |
| CN105574187B CN105574187B (en) | 2019-02-19 |
Family
ID=55884318
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510976842.5A Active CN105574187B (en) | 2015-12-23 | 2015-12-23 | A kind of Heterogeneous Database Replication transaction consistency support method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105574187B (en) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106777270A (en) * | 2016-12-28 | 2017-05-31 | 中国民航信息网络股份有限公司 | A kind of Heterogeneous Database Replication parallel execution system and method based on submission point time line locking |
| CN107016075A (en) * | 2017-03-27 | 2017-08-04 | 聚好看科技股份有限公司 | Company-data synchronous method and device |
| CN107391306A (en) * | 2017-07-27 | 2017-11-24 | 国家电网公司 | A kind of isomeric data library backup file access pattern method |
| CN109189608A (en) * | 2018-08-13 | 2019-01-11 | 武汉达梦数据库有限公司 | A kind of method guaranteeing duplication transaction consistency and corresponding reproducing unit |
| CN109408480A (en) * | 2018-09-29 | 2019-03-01 | 武汉达梦数据库有限公司 | The method and system read based on ORACLE multinode RAC log based on SCN alignment |
| CN110300964A (en) * | 2017-05-24 | 2019-10-01 | 北京科蓝软件系统股份有限公司 | Database copy method and database replication system |
| CN110457284A (en) * | 2019-06-05 | 2019-11-15 | 黄疆 | More time point data restoration methods and system based on SQLServer database |
| CN110851528A (en) * | 2019-10-09 | 2020-02-28 | 网联清算有限公司 | Database synchronization method and device, storage medium and computer equipment |
| CN111241094A (en) * | 2019-12-31 | 2020-06-05 | 武汉达梦数据库有限公司 | Database deleted column synchronization method and device based on log analysis |
| CN111694800A (en) * | 2020-04-30 | 2020-09-22 | 武汉达梦数据库有限公司 | Method for improving data synchronization performance and data synchronization system |
| CN112307118A (en) * | 2020-09-30 | 2021-02-02 | 武汉达梦数据库有限公司 | Method for guaranteeing data consistency based on log analysis synchronization and synchronization system |
| CN112966047A (en) * | 2021-03-05 | 2021-06-15 | 浪潮云信息技术股份公司 | Method for realizing table copying function based on distributed database |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1784677A (en) * | 2004-03-31 | 2006-06-07 | 微软公司 | System and method for a consistency check of a database backup |
| US20080046480A1 (en) * | 2003-12-15 | 2008-02-21 | At&T Knowledge Ventures, L.P. | Architecture of database application with robust online recoverability |
| CN103198159A (en) * | 2013-04-27 | 2013-07-10 | 国家计算机网络与信息安全管理中心 | Transaction-redo-based multi-copy consistency maintaining method for heterogeneous clusters |
| CN104216955A (en) * | 2014-08-20 | 2014-12-17 | 百度在线网络技术（北京）有限公司 | Methods and devices for operating data and managing events and distributed system |
-
2015
- 2015-12-23 CN CN201510976842.5A patent/CN105574187B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080046480A1 (en) * | 2003-12-15 | 2008-02-21 | At&T Knowledge Ventures, L.P. | Architecture of database application with robust online recoverability |
| CN1784677A (en) * | 2004-03-31 | 2006-06-07 | 微软公司 | System and method for a consistency check of a database backup |
| CN103198159A (en) * | 2013-04-27 | 2013-07-10 | 国家计算机网络与信息安全管理中心 | Transaction-redo-based multi-copy consistency maintaining method for heterogeneous clusters |
| CN104216955A (en) * | 2014-08-20 | 2014-12-17 | 百度在线网络技术（北京）有限公司 | Methods and devices for operating data and managing events and distributed system |
Cited By (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106777270A (en) * | 2016-12-28 | 2017-05-31 | 中国民航信息网络股份有限公司 | A kind of Heterogeneous Database Replication parallel execution system and method based on submission point time line locking |
| CN107016075A (en) * | 2017-03-27 | 2017-08-04 | 聚好看科技股份有限公司 | Company-data synchronous method and device |
| CN110300964B (en) * | 2017-05-24 | 2022-11-08 | 北京科蓝软件系统股份有限公司 | Database replication method and database replication system |
| CN110300964A (en) * | 2017-05-24 | 2019-10-01 | 北京科蓝软件系统股份有限公司 | Database copy method and database replication system |
| CN107391306A (en) * | 2017-07-27 | 2017-11-24 | 国家电网公司 | A kind of isomeric data library backup file access pattern method |
| CN109189608A (en) * | 2018-08-13 | 2019-01-11 | 武汉达梦数据库有限公司 | A kind of method guaranteeing duplication transaction consistency and corresponding reproducing unit |
| CN109189608B (en) * | 2018-08-13 | 2019-07-26 | 武汉达梦数据库有限公司 | A kind of method guaranteeing duplication transaction consistency and corresponding reproducing unit |
| CN110262929A (en) * | 2018-08-13 | 2019-09-20 | 武汉达梦数据库有限公司 | A kind of method guaranteeing duplication transaction consistency and corresponding reproducing unit |
| CN110262929B (en) * | 2018-08-13 | 2020-01-07 | 武汉达梦数据库有限公司 | Method for ensuring consistency of copying affairs and corresponding copying device |
| CN109408480A (en) * | 2018-09-29 | 2019-03-01 | 武汉达梦数据库有限公司 | The method and system read based on ORACLE multinode RAC log based on SCN alignment |
| CN110457284A (en) * | 2019-06-05 | 2019-11-15 | 黄疆 | More time point data restoration methods and system based on SQLServer database |
| CN110457284B (en) * | 2019-06-05 | 2022-11-29 | 黄疆 | Multi-time point data recovery method and system based on SQLServer database |
| CN110851528A (en) * | 2019-10-09 | 2020-02-28 | 网联清算有限公司 | Database synchronization method and device, storage medium and computer equipment |
| CN110851528B (en) * | 2019-10-09 | 2022-09-02 | 网联清算有限公司 | Database synchronization method and device, storage medium and computer equipment |
| CN111241094B (en) * | 2019-12-31 | 2021-06-08 | 武汉达梦数据库有限公司 | Database deleted column synchronization method and device based on log analysis |
| CN111241094A (en) * | 2019-12-31 | 2020-06-05 | 武汉达梦数据库有限公司 | Database deleted column synchronization method and device based on log analysis |
| CN111694800A (en) * | 2020-04-30 | 2020-09-22 | 武汉达梦数据库有限公司 | Method for improving data synchronization performance and data synchronization system |
| CN111694800B (en) * | 2020-04-30 | 2023-03-24 | 武汉达梦数据库股份有限公司 | Method for improving data synchronization performance and data synchronization system |
| CN112307118A (en) * | 2020-09-30 | 2021-02-02 | 武汉达梦数据库有限公司 | Method for guaranteeing data consistency based on log analysis synchronization and synchronization system |
| CN112307118B (en) * | 2020-09-30 | 2024-03-22 | 武汉达梦数据库股份有限公司 | Method for guaranteeing data consistency based on log analysis synchronization and synchronization system |
| CN112966047A (en) * | 2021-03-05 | 2021-06-15 | 浪潮云信息技术股份公司 | Method for realizing table copying function based on distributed database |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105574187B (en) | 2019-02-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105574187A (en) | Duplication transaction consistency guaranteeing method and system for heterogeneous databases | |
| US7330859B2 (en) | Database backup system using data and user-defined routines replicators for maintaining a copy of database on a secondary server | |
| CN101334797B (en) | Distributed file systems and its data block consistency managing method | |
| KR101662212B1 (en) | Database Management System providing partial synchronization and method for partial synchronization thereof | |
| CN102891849B (en) | Service data synchronization method, data recovery method, data recovery device and network device | |
| US8898112B1 (en) | Write signature command | |
| US20150213100A1 (en) | Data synchronization method and system | |
| US9672244B2 (en) | Efficient undo-processing during data redistribution | |
| CN109992628B (en) | Data synchronization method, device, server and computer readable storage medium | |
| US20090210429A1 (en) | System and method for asynchronous update of indexes in a distributed database | |
| US20160142249A1 (en) | Method, medium, and system for configuring a new node in a distributed memory network | |
| CN109542682B (en) | Data backup method, device, equipment and storage medium | |
| CN111078667B (en) | Data migration method and related device | |
| JP2012069168A (en) | Geographically distributed cluster | |
| CN113239013B (en) | Distributed system and storage medium | |
| KR20080102622A (en) | Data replication method and systme for database management system | |
| CN103197988A (en) | Data backup and recovery method, device and database system | |
| CN107229540A (en) | A kind of database restoring method and system based on time point | |
| CN102708166B (en) | Data replication method, data recovery method and data recovery device | |
| US20230315713A1 (en) | Operation request processing method, apparatus, device, readable storage medium, and system | |
| CN110196788B (en) | Data reading method, device and system and storage medium | |
| CN112800060A (en) | Data processing method and device, computer readable storage medium and electronic equipment | |
| CN104991739A (en) | Method and system for refining primary execution semantics during metadata server failure substitution | |
| US8918364B1 (en) | Online mirror state transitioning in databases | |
| CN114490570A (en) | Production data synchronization method and device, data synchronization system and server |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP03 | Change of name, title or address |
Address after: 430073 16-19 / F, building C3, future science and technology building, 999 Gaoxin Avenue, Wuhan East Lake New Technology Development Zone, Wuhan City, Hubei Province Patentee after: Wuhan dream database Co.,Ltd. Address before: 430073 5th floor, building C6, optical valley software park, special 1, Guanshan 1st Road, Donghu Development Zone, Wuhan City, Hubei Province Patentee before: WUHAN DAMENG DATABASE Co.,Ltd. |
|
| CP03 | Change of name, title or address | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220905 Address after: 430073 16-19 / F, building C3, future science and technology building, 999 Gaoxin Avenue, Donghu New Technology Development Zone, Wuhan City, Hubei Province Patentee after: Wuhan dream database Co.,Ltd. Patentee after: HUAZHONG University OF SCIENCE AND TECHNOLOGY Address before: 430073 16-19 / F, building C3, future science and technology building, 999 Gaoxin Avenue, Wuhan East Lake New Technology Development Zone, Wuhan City, Hubei Province Patentee before: Wuhan dream database Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20230731 Address after: 16-19/F, Building C3, Future Science and Technology Building, No. 999 Gaoxin Avenue, Donghu New Technology Development Zone, Wuhan City, Hubei Province, 430206 Patentee after: Wuhan dream database Co.,Ltd. Address before: 430073 16-19 / F, building C3, future science and technology building, 999 Gaoxin Avenue, Donghu New Technology Development Zone, Wuhan City, Hubei Province Patentee before: Wuhan dream database Co.,Ltd. Patentee before: HUAZHONG University OF SCIENCE AND TECHNOLOGY |
|
| TR01 | Transfer of patent right |