CN102402562A - Database remote disaster tolerant method and system - Google Patents
Database remote disaster tolerant method and system Download PDFInfo
- Publication number
- CN102402562A CN102402562A CN2010102890762A CN201010289076A CN102402562A CN 102402562 A CN102402562 A CN 102402562A CN 2010102890762 A CN2010102890762 A CN 2010102890762A CN 201010289076 A CN201010289076 A CN 201010289076A CN 102402562 A CN102402562 A CN 102402562A
- Authority
- CN
- China
- Prior art keywords
- database
- change
- data
- script
- synchronized
- 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.)
- Pending
Links
Images
Abstract
The invention discloses a database remote disaster tolerant method and a system. A first database changes the data of a local database to generate a change file; an executable script can be generated according to the change file and then is synchronized to a second database after being added with an asynchronization identifier; the second database executes the executable script to change the local data; and during the process of synchronizing the data change to the first database, if the data change is recognized to come from the first database according to the asynchronization identifier carried in the executable script, the data change caused by executing the executable script is not synchronized to the first database. According to the invention, the sources of data change are distinguished, thus the load of a master server is reduced while bidirectional remote backup disaster tolerance is realized.
Description
Technical field
The present invention relates to synchronous disaster tolerance technology field, database strange land, more specifically, relate to a kind of database strange disaster recovery method and system.
Background technology
Field of telecommunications just develops towards the fusion direction of multi-service, many networks at present, but the construction mode that the business platform that most of operator built in evolution still adopts independently, separates.Each business platform, no matter its amount of capacity and function what, all needs deployment separately to database that should business platform.For significant data; Then need carry out disaster-tolerant backup to data; General way is to use the complete memory device of a cover that the storage data of master server are backed up, and the hardware resource that these are used to back up can't produce any profit when normal operation; Cause a large amount of uses of hardware resource or idle, caused higher operation cost.
Present stage each big operator; Especially multinational operator is faced with and lowers CAPEX (CapitalExpenditure; Capital outlay) and the important task of OPEX (Operating Expense, i.e. operation cost), CAPEX generally is meant the input of fund to capital assets; Concerning telecom operators, the project of disposable expenditures such as the relevant network equipment, computing machine, instrument all belongs to CAPEX.The deployment and the dilatation of therefore new office point all can be followed the principle that reduces TCO (Total Cost of Ownership, overall cost), with the input of minimum, produce maximum value.
In disclosed patent documentation; Not enough below Chinese patent CN200910236502.3 exists: as only to relate to and unidirectionally carry out data sync to another database from source database; Not to the data of coming synchronously from source database and since the professional data that are created in target database distinguish.Then there is the defective that determining step is too many, efficient is not high in another Chinese patent CN200510086911, thereby is not suitable for big data quantity and carries out synchronously.
Summary of the invention
The technical matters that the present invention solves provides a kind of database strange disaster recovery method and system, in the fulfillment database long-distance disaster, lowers the load of master server.
For solving the problems of the technologies described above, the invention provides a kind of database strange disaster recovery method, said method comprises:
First database generates change file to the data change that derives from local data base, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to second database;
Said second database is carried out the said script of carrying out local data is changed; To said first database synchronization time; Carry out said asynchronous sign that script has and identify data change and derive from said first database according to said, then saidly carry out the data change that script causes and no longer be synchronized to said first database carrying out.
Further, said first database and said second database are each other to client database;
Whether said first database or second database root have asynchronous sign according to the script of carrying out carried out, and identify data change and derive from client database or local data base.
Further, when said first database or second database identify data change and derive from client database, can carry out the data change that script causes and do not generate change file, no longer be synchronized to client database to carrying out.
Further, when said first database or second database identify data change and derive from local data base, be that record cell generates said change file in Buffer Pool with the wall scroll statement;
From said Buffer Pool, read when the change file generation is said carries out script, the change file that read is renamed, and the change file after renaming in deletion regularly or the said Buffer Pool of transfer backup.
Further, said data change comprises: increase, minimizing or content alteration.
The present invention also provides a kind of database long-distance disaster system, comprises first data subsystem and second data subsystem,
Said first data subsystem is used for, and the data change that derives from local data base is generated change file, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to said second data subsystem;
Said second data subsystem is used for; Carrying out the said script of carrying out changes local data; When said first data subsystem is synchronous; Carry out said asynchronous sign that script has and identify data change and derive from said first data subsystem according to said, then saidly carry out the data change that script causes and no longer be synchronized to said first data subsystem carrying out.
In addition, said data subsystem further comprises: database, Buffer Pool and synchronized process module,
Said database is used for, and the data change that derives from local data base is generated change file;
Said Buffer Pool is used for, and cushions the said change file that said database generates;
Said synchronized process module is used for, and reads the said change file of said Buffer Pool, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to client database.
In addition; Said database is further used for; Whether the script carried out according to carrying out has asynchronous sign, identifies data change and derives from client database or local data base, when identifying data change and derive from client database; Can carry out the data change that script causes and do not generate change file carrying out, no longer to be synchronized to client database.
In addition, said synchronized process module also is used for, and when from said Buffer Pool, reading change file, the change file that read is renamed;
Said Buffer Pool also is used for, the change file after deletion regularly or transfer backup rename.
In addition, said synchronized process module is further used for, and the filename suffix of the change file that read is made amendment;
Whether said Buffer Pool is further used for, distinguish change file according to the extension name of filename and rename.
Compared with prior art, the present invention has following beneficial effect at least:
The present invention in synchronizing process, for the data of coming synchronously from source database and since the professional data change that produces in target database distinguish, to synchronization failure according to obstructed reason fast processing, thereby realize two-way remote backup disaster tolerance;
Synchronous through introducing the strange land bi-directional data, disaster tolerance system makes the database that only can be used in user data backup originally also can participate in operation each other, has reduced master server pressure, has also guaranteed data security simultaneously;
In addition,, make disaster tolerance equipment also can produce income, reduced the operation costs such as CAPEX and OPEX of operator because disaster tolerance system also can be participated in operation.
Description of drawings
Fig. 1 is the Organization Chart of the database long-distance disaster system of the embodiment of the invention;
Fig. 2 is the treatment scheme synoptic diagram of the database long-distance disaster of the embodiment of the invention.
Embodiment
In view of the number of drawbacks of prior art, the present invention proposes a kind of database strange disaster recovery method, adopts following technical scheme:
First database generates change file to the data change that derives from local data base, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to second database;
Said second database is carried out the said script of carrying out local data is changed; To said first database synchronization time; Carry out said asynchronous sign that script has and identify data change and derive from said first database according to said, then saidly carry out the data change that script causes and no longer be synchronized to said first database carrying out.
Further, said first database and said second database are each other to client database;
Whether said first database or second database root have asynchronous sign according to the script of carrying out carried out, and identify data change and derive from client database or local data base.
Further, when said first database or second database identify data change and derive from client database, can carry out the data change that script causes and do not generate change file, no longer be synchronized to client database to carrying out.
Further, when said first database or second database identify data change and derive from local data base, be that record cell generates said change file in Buffer Pool with the wall scroll statement;
From said Buffer Pool, read when the change file generation is said carries out script, the change file that read is renamed, and the change file after renaming in deletion regularly or the said Buffer Pool of transfer backup.
Further, said data change comprises: increase, minimizing or content alteration.
For the ease of setting forth the present invention, below will combine accompanying drawing and specific embodiment that the enforcement of technical scheme of the present invention is described in further detail.
Fig. 1 is the Organization Chart of the database long-distance disaster system of the embodiment of the invention, comprises source data subsystem and target data subsystem, wherein:
Said source data subsystem is used for, and the data change that derives from local data base is generated change file, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to the target data subsystem;
Said target data subsystem is used for; Execution can be carried out script local data is changed; When the source data subsystem is synchronous; Identify data change and derive from said source data subsystem according to carrying out said asynchronous sign that script has, then can carry out the data change that script causes and no longer be synchronized to the source data subsystem carrying out.
Wherein, the environment B at the environment A at source data subsystem place and target data subsystem place is disaster tolerance each other, and the backup of data is two-way backups, both indistinctions also with regard to the composition of itself.
As shown in Figure 1, the data subsystem of present embodiment mainly is made up of following module:
Database is mainly used in the storage and the processing of source data and disaster tolerance data;
Buffer Pool is mainly used in the storage change file, and the record synchronizing information is regularly deleted scratch file;
The synchronized process module, the content synchronization that is mainly used in database arrives client database.
Further, said database is used for, and the data change that derives from local data base is generated change file;
Said Buffer Pool is used for, and cushions the said change file that said database generates;
Said synchronized process module is used for, and reads the said change file of said Buffer Pool, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to client database.
In addition; Said database is further used for; Whether the script carried out according to carrying out has asynchronous sign, identifies data change and derives from client database or local data base, when identifying data change and derive from client database; Can carry out the data change that script causes and do not generate change file carrying out, no longer to be synchronized to client database.
In addition, said synchronized process module also is used for, and when from said Buffer Pool, reading change file, the change file that read is renamed;
Said Buffer Pool also is used for, the change file after deletion regularly or transfer backup rename.
In addition, said synchronized process module is further used for, and the filename suffix of the change file that read is made amendment;
Whether said Buffer Pool is further used for, distinguish change file according to the extension name of filename and rename.
In conjunction with the composition module of the database long-distance disaster system in the foregoing description, the source database of the embodiment of the invention mainly may further comprise the steps to the synchronizing process of target database:
Step 1: the data of source database storage change, like increase, minimizing or content alteration;
Whether step 2: source database judges whether to be the needs data in synchronization, be the data change that derives from local data base promptly, if, then according to this data change, be that record cell generates change file with the wall scroll statement, be stored in local buffer pool;
Wherein, when initial, the data of source database storage change, and then directly generate change file according to data change.Afterwards, whether source database can have asynchronous sign according to data change judges whether that needs are synchronous, if be not with asynchronous sign, then explanation is the data change that derives from local data base, needs then to generate change file synchronously; If have asynchronous sign, then explanation is the data change that derives from target database, does not then generate change file.
Step 3: local synchronized process module reads the change file in the Buffer Pool, according to the record cell in the change file, and the splicing statement, the script carried out that generation can be carried out in target database, and add asynchronous sign, be synchronized to target database;
Step 4: the change file that the synchronized process module records read, and this change file renamed, prevent to repeat to read;
Step 5: target database is caught the data change have asynchronous sign, does not generate change file at Buffer Pool for these changes, then only carries out can carry out script the data of storage are changed, and the regeneration change file does not turn back to source database;
Step 6: the file that Buffer Pool will rename deletion regularly or transfer backup.
Fig. 2 shows the entire flow figure of the database strange disaster recovery method of the embodiment of the invention, and is as shown in Figure 2, and this flow process specifically comprises the steps:
Step 1, business operation cause the data recording change in the environment A database of source;
Step 2, this data recording place table belongs to the synchronous table of needs, and increment takes place and changes (like increase, minimizing or content alteration) in this table, need in time be synchronized to the opposite end environment;
Step 3 judges whether this increment changes is that the data change that has asynchronous sign causes (can whether be with asynchronous sign to judge according to the script that causes this change), if then do not generate change file at Buffer Pool;
Step 4 is to be caused by the data change that does not have asynchronous sign if this increment changes, and then generates change file at Buffer Pool;
Step 5, the synchronized process module reads change file, begins to carry out synchronously;
The synchronized process module is located to read since the last time when reading change file synchronously;
Step 6, the synchronized process module will read and the file of synchronous mistake renames;
Step 7, Buffer Pool are deleted the file that has renamed, the file that also promptly had been synchronized regularly by specified configuration;
Particularly; Whether can distinguish change file according to the extension name of filename renames; For example: because the change file that increment change to generate, be to be the filename suffix with .r in newly-built, it is the filename suffix that the process that then the is synchronized module that had read changes into .o.
Need to prove that above-mentioned steps 6 is all carried out with step 7 after step 5, but this step 7 does not have certain sequencing relation with step 6.
Step 8, synchronized process module are according to the change of file content, and splicing can be carried out script, and after adding asynchronous sign, are synchronized to client database is carried out, and the client database correspondence table is being carried out alter operation;
Step 9a, if the major key collision error takes place in the target database implementation, then source database is abandoned this conflict record, this EO according to the error reason in the errored response of receiving by the synchronization module among the environment A of source;
Step 9b has an error logging table in the source database, if in the target database implementation mistake except that the major key conflict takes place, then the source database perform statement that such is wrong records in this table;
Step 9c carries out in target database if can carry out script smoothly, causes that then the related data record changes, and it is owing to the operation with asynchronous sign causes that target database captures this record change, does not then generate change file at local buffer pool.
In sum, database strange disaster recovery method provided by the invention and system have following characteristics:
1) environment A is arranged, environment B two sets of data environment are participated in operation;
2) business datum gets into environment A respectively, the database among the B;
3) need the Buffer Pool of data in synchronization in environment separately to generate change file;
4) the synchronized process module in the environment reads the change file in the local buffer pool separately, be with asynchronous sign after, divide to be clipped in the environment of opposite end database and to carry out, to guarantee two environmental data unanimities;
5) environment A, B backups each other, and when arbitrary environment was destroyed, another set of environment can guarantee the integrality of total data, and accepted whole business rapidly.
More than be merely preferred case study on implementation of the present invention; Be not limited to the present invention; The present invention also can have other various embodiments; Under the situation that does not deviate from spirit of the present invention and essence thereof, those of ordinary skill in the art can make various corresponding changes and distortion according to the present invention, but these corresponding changes and distortion all should belong to the protection domain of the appended claim of the present invention.
One of ordinary skill in the art will appreciate that all or part of step in the said method can instruct related hardware to accomplish through program, said program can be stored in the computer-readable recording medium, like ROM (read-only memory), disk or CD etc.Alternatively, all or part of step of the foregoing description also can use one or more integrated circuit to realize.Correspondingly, each the module/unit in the foregoing description can adopt the form of hardware to realize, also can adopt the form of software function module to realize.The present invention is not restricted to the combination of the hardware and software of any particular form.
Claims (10)
1. a database strange disaster recovery method is characterized in that, said method comprises:
First database generates change file to the data change that derives from local data base, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to second database;
Said second database is carried out the said script of carrying out local data is changed; To said first database synchronization time; Carry out said asynchronous sign that script has and identify data change and derive from said first database according to said, then saidly carry out the data change that script causes and no longer be synchronized to said first database carrying out.
2. the method for claim 1 is characterized in that,
Said first database and said second database are each other to client database;
Whether said first database or second database root have asynchronous sign according to the script of carrying out carried out, and identify data change and derive from client database or local data base.
3. method as claimed in claim 2 is characterized in that,
When said first database or second database identify data change and derive from client database, can carry out the data change that script causes and do not generate change file, no longer be synchronized to client database to carrying out.
4. like claim 2 or 3 described methods, it is characterized in that,
When said first database or second database identify data change and derive from local data base, be that record cell generates said change file in Buffer Pool with the wall scroll statement;
From said Buffer Pool, read when the change file generation is said carries out script, the change file that read is renamed, and the change file after renaming in deletion regularly or the said Buffer Pool of transfer backup.
5. like claim 1,2 or 3 described methods, it is characterized in that,
Said data change comprises: increase, minimizing or content alteration.
6. a database long-distance disaster system is characterized in that, comprises first data subsystem and second data subsystem,
Said first data subsystem is used for, and the data change that derives from local data base is generated change file, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to said second data subsystem;
Said second data subsystem is used for; Carrying out the said script of carrying out changes local data; When said first data subsystem is synchronous; Carry out said asynchronous sign that script has and identify data change and derive from said first data subsystem according to said, then saidly carry out the data change that script causes and no longer be synchronized to said first data subsystem carrying out.
7. system as claimed in claim 6 is characterized in that, said data subsystem further comprises: database, Buffer Pool and synchronized process module,
Said database is used for, and the data change that derives from local data base is generated change file;
Said Buffer Pool is used for, and cushions the said change file that said database generates;
Said synchronized process module is used for, and reads the said change file of said Buffer Pool, generates according to said change file and can carry out script, add asynchronous sign after, be synchronized to client database.
8. system as claimed in claim 7 is characterized in that,
Said database is further used for; Whether the script carried out according to carrying out has asynchronous sign; Identifying data change derives from client database or local data base; When identifying data change and derive to client database, can carry out the data change that script causes and do not generate change file carrying out, no longer be synchronized to client database.
9. like claim 7 or 8 described systems, it is characterized in that,
Said synchronized process module also is used for, and when from said Buffer Pool, reading change file, the change file that read is renamed;
Said Buffer Pool also is used for, the change file after deletion regularly or transfer backup rename.
10. system as claimed in claim 9 is characterized in that,
Said synchronized process module is further used for, and the filename suffix of the change file that read is made amendment;
Whether said Buffer Pool is further used for, distinguish change file according to the extension name of filename and rename.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2010102890762A CN102402562A (en) | 2010-09-14 | 2010-09-14 | Database remote disaster tolerant method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2010102890762A CN102402562A (en) | 2010-09-14 | 2010-09-14 | Database remote disaster tolerant method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN102402562A true CN102402562A (en) | 2012-04-04 |
Family
ID=45884773
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2010102890762A Pending CN102402562A (en) | 2010-09-14 | 2010-09-14 | Database remote disaster tolerant method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102402562A (en) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103200267A (en) * | 2013-04-11 | 2013-07-10 | 天脉聚源(北京)传媒科技有限公司 | File management method and file management system |
| CN103516667A (en) * | 2012-06-20 | 2014-01-15 | 中国银联股份有限公司 | System, method and apparatus used for safety information data disaster recovery backup |
| WO2014067254A1 (en) * | 2012-11-01 | 2014-05-08 | 华为技术有限公司 | Method, device and database system for detecting database data consistency |
| CN104426968A (en) * | 2013-08-30 | 2015-03-18 | 腾讯科技（深圳）有限公司 | Data management method and device |
| WO2015192661A1 (en) * | 2014-06-19 | 2015-12-23 | 中兴通讯股份有限公司 | Method, device, and system for data synchronization in distributed storage system |
| CN107066355A (en) * | 2017-05-15 | 2017-08-18 | 郑州云海信息技术有限公司 | The backup server system and its building method of a kind of High Availabitity |
| WO2017198144A1 (en) * | 2016-05-20 | 2017-11-23 | 中兴通讯股份有限公司 | Disaster tolerance method for iptv system, and iptv disaster tolerance system |
| CN107590024A (en) * | 2017-08-10 | 2018-01-16 | 郑州云海信息技术有限公司 | A kind of date storage method and data-storage system |
| CN108038163A (en) * | 2017-12-06 | 2018-05-15 | 交控科技股份有限公司 | Standby control center database synchronous system |
| CN109005246A (en) * | 2018-09-12 | 2018-12-14 | 北京中电普华信息技术有限公司 | A kind of synchronous method of data, apparatus and system |
| CN109063135A (en) * | 2018-08-03 | 2018-12-21 | 中国人民银行清算总中心 | A kind of database copy method and system based on more distributed structure/architecture living |
| CN109710688A (en) * | 2018-11-26 | 2019-05-03 | 福建天泉教育科技有限公司 | A kind of real-time Inspection method of data and message-oriented middleware |
| CN111723116A (en) * | 2020-06-30 | 2020-09-29 | 上海豫源电力科技有限公司 | Data backfill method, device and system |
| CN111770120A (en) * | 2019-04-01 | 2020-10-13 | 江苏华章物流科技股份有限公司 | Real-time remote backup method of VS editor and storage medium |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101187888A (en) * | 2007-12-11 | 2008-05-28 | 浪潮电子信息产业股份有限公司 | Method for coping database data in heterogeneous environment |
-
2010
- 2010-09-14 CN CN2010102890762A patent/CN102402562A/en active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101187888A (en) * | 2007-12-11 | 2008-05-28 | 浪潮电子信息产业股份有限公司 | Method for coping database data in heterogeneous environment |
Cited By (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103516667B (en) * | 2012-06-20 | 2017-03-01 | 中国银联股份有限公司 | For the system of the disaster-tolerant backup of security information data, method and apparatus |
| CN103516667A (en) * | 2012-06-20 | 2014-01-15 | 中国银联股份有限公司 | System, method and apparatus used for safety information data disaster recovery backup |
| WO2014067254A1 (en) * | 2012-11-01 | 2014-05-08 | 华为技术有限公司 | Method, device and database system for detecting database data consistency |
| CN103200267A (en) * | 2013-04-11 | 2013-07-10 | 天脉聚源(北京)传媒科技有限公司 | File management method and file management system |
| CN104426968A (en) * | 2013-08-30 | 2015-03-18 | 腾讯科技（深圳）有限公司 | Data management method and device |
| CN104426968B (en) * | 2013-08-30 | 2019-05-24 | 腾讯科技（深圳）有限公司 | Data managing method and device |
| CN105187464B (en) * | 2014-06-19 | 2019-11-05 | 南京中兴软件有限责任公司 | Method of data synchronization, apparatus and system in a kind of distributed memory system |
| CN105187464A (en) * | 2014-06-19 | 2015-12-23 | 中兴通讯股份有限公司 | Data synchronization method, device and system in distributed storage system |
| WO2015192661A1 (en) * | 2014-06-19 | 2015-12-23 | 中兴通讯股份有限公司 | Method, device, and system for data synchronization in distributed storage system |
| WO2017198144A1 (en) * | 2016-05-20 | 2017-11-23 | 中兴通讯股份有限公司 | Disaster tolerance method for iptv system, and iptv disaster tolerance system |
| CN107066355A (en) * | 2017-05-15 | 2017-08-18 | 郑州云海信息技术有限公司 | The backup server system and its building method of a kind of High Availabitity |
| CN107590024A (en) * | 2017-08-10 | 2018-01-16 | 郑州云海信息技术有限公司 | A kind of date storage method and data-storage system |
| CN107590024B (en) * | 2017-08-10 | 2020-08-07 | 郑州云海信息技术有限公司 | Data storage method and data storage system |
| CN108038163B (en) * | 2017-12-06 | 2020-07-31 | 交控科技股份有限公司 | Master and backup control center database synchronization system |
| CN108038163A (en) * | 2017-12-06 | 2018-05-15 | 交控科技股份有限公司 | Standby control center database synchronous system |
| CN109063135A (en) * | 2018-08-03 | 2018-12-21 | 中国人民银行清算总中心 | A kind of database copy method and system based on more distributed structure/architecture living |
| CN109005246A (en) * | 2018-09-12 | 2018-12-14 | 北京中电普华信息技术有限公司 | A kind of synchronous method of data, apparatus and system |
| CN109005246B (en) * | 2018-09-12 | 2021-10-01 | 北京国电通网络技术有限公司 | Data synchronization method, device and system |
| CN109710688A (en) * | 2018-11-26 | 2019-05-03 | 福建天泉教育科技有限公司 | A kind of real-time Inspection method of data and message-oriented middleware |
| CN111770120A (en) * | 2019-04-01 | 2020-10-13 | 江苏华章物流科技股份有限公司 | Real-time remote backup method of VS editor and storage medium |
| CN111723116A (en) * | 2020-06-30 | 2020-09-29 | 上海豫源电力科技有限公司 | Data backfill method, device and system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102402562A (en) | Database remote disaster tolerant method and system | |
| CN109656934B (en) | Source Oracle database DDL synchronization method and device based on log analysis | |
| US8250033B1 (en) | Replication of a data set using differential snapshots | |
| US7873599B2 (en) | Backup control apparatus and method eliminating duplication of information resources | |
| EP1618504B1 (en) | System and method for a consistency check of a database backup | |
| US7634679B2 (en) | Remote location failover server application | |
| US9588858B2 (en) | Periodic data replication | |
| CN101888405B (en) | Cloud computing file system and data processing method | |
| US7801867B2 (en) | Optimizing backup and recovery utilizing change tracking | |
| US20080162599A1 (en) | Optimizing backup and recovery utilizing change tracking | |
| CN102750317B (en) | Method and device for data persistence processing and data base system | |
| US9229970B2 (en) | Methods to minimize communication in a cluster database system | |
| US7487385B2 (en) | Apparatus and method for recovering destroyed data volumes | |
| CN103842969A (en) | Information processing system | |
| CN106933703A (en) | A kind of method of database data backup, device and electronic equipment | |
| CN102331957A (en) | File backup method and device | |
| CN107229540A (en) | A kind of database restoring method and system based on time point | |
| CN106528071A (en) | Selection method and device for target code | |
| CN112800007B (en) | Directory entry expansion method and system suitable for FAT32 file system | |
| US8595271B1 (en) | Systems and methods for performing file system checks | |
| CN107402841A (en) | Large-scale distributed file system data recovery method and equipment | |
| US10228879B1 (en) | System and method for backup and restore of offline disks in mainframe computers | |
| EP4315093A1 (en) | Database schema branching workflow, with support for data, keyspaces and vschemas | |
| CN103235747B (en) | The restoration methods of metadata and system | |
| CN116821232A (en) | Data synchronization method and related device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20120404 |