CN113535665B - Method and device for synchronizing log files between main database and standby database - Google Patents
Method and device for synchronizing log files between main database and standby database Download PDFInfo
- Publication number
- CN113535665B CN113535665B CN202110810512.4A CN202110810512A CN113535665B CN 113535665 B CN113535665 B CN 113535665B CN 202110810512 A CN202110810512 A CN 202110810512A CN 113535665 B CN113535665 B CN 113535665B
- Authority
- CN
- China
- Prior art keywords
- database
- log file
- standby
- full
- log
- 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.)
- Active
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/17—Details of further file system functions
- G06F16/178—Techniques for file synchronisation in 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/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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Abstract
The invention provides a method and a device for synchronizing log files between a main database and a standby database, wherein the method comprises the following steps: the method comprises the steps that a main database generates a log file of data modification under the condition that the data modification is detected; the master database carries out transaction processing on data modification; under the condition that the transaction processing is successful, the master database synchronizes the log file to the standby database; and the standby database carries out replay according to the log file. The method and the device solve the technical problem that logs which cause the fault of the main database are easily synchronized to the standby database in the prior art, so that the standby database also has corresponding faults.
Description
Technical Field
The invention relates to the technical field of databases, in particular to a method and a device for synchronizing log files between a master database and a database.
Background
In consideration of disaster tolerance, load balancing, centralized data distribution and the like, in the prior art, a main database and a standby database are often adopted, and data synchronization is performed between the main database and the standby database, so that the function of dual-computer hot standby is realized.
It should be noted that, when a log file is synchronized between a conventional primary database and a standby database, the log file is often sent to the standby database for data replay after the log file is generated, so as to implement data synchronization.
Disclosure of Invention
The invention provides a method and a device for synchronizing log files between a main database and a standby database, which aim to solve the technical problem that logs causing the failure of the main database are easily synchronized to the standby database in the prior art, so that the standby database also has corresponding failure.
According to a first aspect of the present invention, there is provided a method for synchronizing log files between a primary database and a secondary database, the method comprising: the method comprises the steps that a main database generates a log file of data modification under the condition that the data modification is detected; the master database carries out transaction processing on the data modification; under the condition that the transaction processing is successful, the main database synchronizes the log file to the standby database; and the backup database carries out replay according to the log file.
Further, the step of replaying the database according to the log file comprises the following steps: generating replay progress information in the replay process of the database; the backup database synchronizes the replay progress information to the primary database through a heartbeat mechanism.
Further, the log file is an incremental log file, wherein after the backup database synchronizes the replay progress information to the primary database through a heartbeat mechanism, the method further comprises: under the condition that the backup database fails to replay, the backup database sends full synchronous request information to the main database; the master database generates a full log file according to the full synchronization request information and sends the full log file to the standby database; and the database replays according to the full log file.
Further, the log files include a binlog log file and a redolog log file, wherein after generating the log file for data modification, the method further comprises: and writing the binlog log file into a memory and writing the redolog file into a disk.
Further, after the backup database is replayed according to the log file, the method comprises the following steps: the standby database determines that the main database fails at the first time according to the heartbeat signal sent by the main database; and receiving and processing the data processing request by the database at a second time, wherein the second time is later than the first time.
According to a second aspect of the present invention, there is provided an apparatus for synchronizing log files between a master database and a database, the apparatus comprising: a first generation unit configured to generate a log file of data modification in a case where the data modification is detected; the transaction processing unit is used for carrying out transaction processing on the data modification; the synchronization unit is used for synchronizing the log file to the standby database under the condition that the transaction processing is successful; and a first replay unit for replaying according to the log file.
Further, the playback unit includes: the generating module is used for generating replay progress information in the replay process; and the synchronization module is used for synchronizing the replay progress information to the master database through a heartbeat mechanism.
Further, the log file is an incremental log file, and the apparatus further includes: a transmitting unit, configured to transmit full-scale synchronization request information to the master database in case of a failure in playback of the backup database; the second generation unit is used for generating a full log file according to the full synchronization request information and sending the full log file to the standby database; and a second playback unit for performing playback based on the full-size log file.
Further, the log files include a binlog log file and a redolog file, wherein the apparatus further comprises: and the writing unit is used for writing the binlog log file into the memory and writing the redolog file into the disk.
Further, the apparatus further comprises: the determining unit is used for determining that the main database fails at the first time according to the heartbeat signals sent by the main database; and the processing unit is used for receiving and processing the data processing request at a second time, wherein the second time is later than the first time.
The invention provides a method and a device for synchronizing log files between a main database and a standby database, wherein the method comprises the following steps: the method comprises the steps that a main database generates a log file of data modification under the condition that the data modification is detected; the master database carries out transaction processing on the data modification; under the condition that the transaction processing is successful, the master database synchronizes the log file to the standby database; and the backup database carries out replay according to the log file. The method and the device solve the technical problem that logs which cause the fault of the main database are easily synchronized to the standby database in the prior art, so that the standby database also has corresponding faults.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without creative efforts.
FIG. 1 is a flowchart illustrating a method for synchronizing log files between a primary database and a secondary database according to a first embodiment of the present invention;
fig. 2 is a flowchart of an alternative method for synchronizing log files between a primary database and a secondary database according to a first embodiment of the present invention;
fig. 3 is a flowchart of a method for synchronizing log files between an alternative primary database and a secondary database according to a first embodiment of the present invention; and
fig. 4 is a schematic diagram of an apparatus for synchronizing log files between a primary database and a secondary database according to a second embodiment of the present invention.
Detailed Description
In order to make the above and other features and advantages of the present invention more apparent, the present invention is further described below with reference to the accompanying drawings. It is understood that the specific embodiments described herein are for purposes of illustration only and are not intended to be limiting, as those of ordinary skill in the art will recognize.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that the specific details need not be employed to practice the present invention. In other instances, well-known steps or operations are not described in detail to avoid obscuring the invention.
Example one
The invention provides a method for synchronizing log files between a primary database and a secondary database, which comprises the following steps of:
in step S11, the master database generates a log file of data modification in the case where data modification is detected.
Specifically, in this solution, the primary database may be a mater database, the standby database may be a slave database, both the primary database and the standby database may be multidimensional databases, and in daily work, the primary database may be responsible for processing a network request and performing corresponding transaction processing, for example, processing a data processing request (for example, insert or delete) for changing data sent by a client, and the standby database may be responsible for processing a data processing request (for example, select) for viewing data by the client. When a client finds a request for modifying data of a main database, the main database generates a log file according to the data modification, wherein the log file may be a logical log file binlog for recording original logic of data modification statements or a physical log file redolog for recording specific modification matters.
At step S13, the master database transacts the data modification.
Specifically, after the master database generates a log file of data modifications, the master database may perform the data modifications on the transaction (i.e., data commit) of the transaction.
In step S15, the master database synchronizes the log file to the backup database in case of successful transaction processing.
Specifically, in the above scheme, if the transaction processing is successful, it means that the process of the transaction is processed normally, and the main database does not have a fault or a downtime in the process of processing the transaction, that is, the main database does not have a fault or a downtime due to the above events.
And step S17, the backup database replays according to the log file.
Specifically, in the present solution, after the transaction is successful, that is, after the data commit, the master database synchronizes the log file to the standby database, and the standby database performs data playback replay according to the log file to complete data synchronization of the master database and the standby database. And if the transaction is successful, the main database fails or is down for the transaction, and the log file is safe, so that after the data is replayed by the standby database according to the log file, the failure or the down does not occur.
It should be noted that the log file may be an incremental log file, for example, the master database continuously synchronizes a new binlog log to the standby database after the commit through the mechanism, detects that there is a new binlog from the standby database, and then replays the new binlog to achieve the consistency between the master database and the standby database. It should be noted that, after receiving the binlog generated by the primary database, the backup database sequentially writes the binlog into the local disk of the backup database, and then reads the binlog from the local disk in transaction units and replays the binlog, thereby completing the data consistency of the primary database and the backup database.
Optionally, as shown in fig. 2, in step S17, the step of replaying the database according to the log file may include:
in step S171, the database generates the playback progress information during playback.
And step S172, the backup database synchronizes the playback progress information to the master database through a heartbeat mechanism.
Specifically, in the present scheme, during the data playback process of the standby database, the standby database may synchronize the playback progress information to the main database through a heartbeat mechanism, for example, the standby database plays back binlog, and synchronizes the playback progress information to the main database with the heartbeat, so that the main database can constantly obtain the specific playback status and progress of the standby database.
Optionally, the log file is an incremental log file, such as an incremental binlog, wherein, after the backup database synchronizes the replay progress information to the primary database through the heartbeat mechanism in step S172, the method of the present embodiment may further include:
in step S173, when the backup database fails to be played back, the backup database transmits the entire synchronization request information to the master database.
In step S174, the master database generates a full amount of log files according to the full amount of synchronization request information, and transmits the full amount of log files to the standby database.
And step S175, the standby database replays according to the full log file.
Specifically, in this embodiment, if the backup database fails to replay the incremental binlog, the backup database may send full-amount synchronization request information to the master database, the master database generates a full-amount binlog, and the backup database may skip the previous incremental binlog after receiving the full-amount binlog and directly replay a new full-amount binlog. It should be noted here that the incremental binlog contains changes, and the full binlog refers to a snapshot of the latest data. The full binlog is generated when the synchronization of the standby database fails and a request is sent to the main database. The full binlog is generated from the data files, which are continually modified as requested by the user.
Specifically, the log files may include a binlog log file and a redolog log file, where after the step S11 generates the data modified log file, the method further includes:
step S12, writing the binlog log file into the memory and writing the redolog file into the disk.
Specifically, the present solution may collect binlog, then cache the collected binlog in a memory, then write a redolog file in a disk, and then merge data and metadata in step S13, thereby completing the operation of the final data commit.
Optionally, as shown in fig. 3, after the database is replayed according to the log file in step S17, the method of the present scheme may further include:
and step S19, the standby database determines that the main database fails at the first time according to the heartbeat signal sent by the main database.
Step S21, the database receives and processes the data processing request at a second time, wherein the second time is later than the first time.
Specifically, in the solution, a heartbeat mechanism is provided between the main database and the standby database, after the standby database is replayed according to the incremental log, the standby database can determine that the main database fails at the first time according to a heartbeat signal sent by the main database, and if the standby database fails, for example, the main database is down due to an abnormality, the solution stops the main database from processing the data processing request after the first time (i.e., the second time), but upgrades the standby database to a new main database, and allows the main database to process the new data processing request.
In summary, the above method of the present application provides a high availability scheme for a database based on binlog log synchronization, in which a binlog is written into a file and sent to a standby library at a time after completion of commit operations, so that a transaction that is down or erroneous in writing the redolog and the final data commit is not sent to the standby library. Because of such transactions, there is a great risk of them being replayed in the standby library, resulting in a downtime in the standby library or a data error. Therefore, the scheme can greatly improve the stability of the standby database, reduce unnecessary data synchronization and also enhance the rationality of the synchronization of the main data and the standby data.
Example two
As shown in fig. 4, the present application further provides an apparatus for synchronizing log files between a master database and a database, where the apparatus may be configured to perform the method in the first embodiment, and the apparatus includes: a first generating unit 40 for generating a log file of data modification in a case where the data modification is detected; a transaction processing unit 42, configured to perform transaction processing on the data modification; a synchronization unit 44, configured to synchronize the log file to the backup database if the transaction is successful; a first replay unit 46 for replaying according to the log file.
Specifically, according to the scheme provided by the device, compared with the prior art, the master database does not immediately send the standby database for data playback after generating the log file, but synchronizes the log file to the standby database for playback when the transaction processing is successful, and does not synchronize the log file to the standby database when the transaction processing is failed. And if the transaction is successful, the main database fails or crashes for the transaction, and the log file is safe, so that after the data is replayed according to the log file by the standby database, the failure or downtime does not occur.
Optionally, the first playback unit includes: the generating module is used for generating the replay progress information in the replay process; and the synchronization module is used for synchronizing the replay progress information to the master database through a heartbeat mechanism.
Optionally, the log file is an incremental log file, and the apparatus further includes: a transmitting unit, configured to transmit full-scale synchronization request information to the primary database in the case that playback of the secondary database fails; the second generation unit is used for generating a full log file according to the full synchronization request information and sending the full log file to the standby database; and a second playback unit for performing playback based on the full-size log file.
Optionally, the log files include a binlog log file and a redolog log file, wherein the apparatus further includes: and the writing unit is used for writing the binlog log file into the memory and writing the redolog file into the disk.
Optionally, the apparatus further comprises: the determining unit is used for determining that the main database fails at the first time according to the heartbeat signal sent by the main database; and the processing unit is used for receiving and processing the data processing request at a second time, wherein the second time is later than the first time.
According to the high-availability scheme of the database based on binlog log synchronization, the binlog is written into a file and is sent to the standby database at a time after all commit operations are completed, and therefore down or wrong transactions cannot be generated in the process of writing the redolog and the final data commit and are sent to the standby database. Because of such transactions, there is a great risk of being replayed in the standby library, causing the standby library to be down or causing data errors. Therefore, the scheme can greatly improve the stability of the standby database, reduce unnecessary data synchronization and enhance the rationality of the synchronization of the main and standby data.
It will be understood that the specific features, operations and details described herein above with respect to the method of the present invention may be similarly applied to the apparatus and system of the present invention, or vice versa. In addition, each step of the method of the present invention described above may be performed by a respective component or unit of the device or system of the present invention.
It should be understood that the various modules/units of the apparatus of the present invention may be implemented in whole or in part by software, hardware, firmware, or a combination thereof. The modules/units may be embedded in the processor of the computer device in the form of hardware or firmware or independent from the processor, or may be stored in the memory of the computer device in the form of software for being called by the processor to execute the operations of the modules/units. Each of the modules/units may be implemented as a separate component or module, or two or more modules/units may be implemented as a single component or module.
In one embodiment, a computer device is provided that includes a memory and a processor, the memory having stored thereon computer instructions executable by the processor, the computer instructions, when executed by the processor, instruct the processor to perform the steps of the method of embodiment one of the present invention. The computer device may broadly be a server, a terminal, or any other electronic device having the necessary computing and/or processing capabilities. In one embodiment, the computer device may include a processor, memory, a network interface, a communication interface, etc., connected by a system bus. The processor of the computer device may be used to provide the necessary computing, processing and/or control capabilities. The memory of the computer device may include non-volatile storage media and internal memory. An operating system, a computer program, and the like may be stored in or on the non-volatile storage medium. The internal memory may provide an environment for the operating system and the computer programs in the non-volatile storage medium to run. The network interface and the communication interface of the computer device may be used to connect and communicate with an external device via a network. Which when executed by a processor performs the steps of the method for charging a battery of the invention.
The invention may be implemented as a computer-readable storage medium, having stored thereon a computer program, which, when executed by a processor, causes the steps of the method of embodiment one of the invention to be performed. In one embodiment, the computer program is distributed across a plurality of computer devices or processors coupled by a network such that the computer program is stored, accessed, and executed by one or more computer devices or processors in a distributed fashion. A single method step/operation, or two or more method steps/operations, may be performed by a single computer device or processor or by two or more computer devices or processors. One or more method steps/operations may be performed by one or more computer devices or processors, and one or more other method steps/operations may be performed by one or more other computer devices or processors. One or more computer devices or processors may perform a single method step/operation, or two or more method steps/operations.
Those of ordinary skill in the art will appreciate that the method steps of the present invention may be directed to associated hardware such as a computer device or a processor, by a computer program, which may be stored in a non-transitory computer readable storage medium, that when executed, cause the steps of the present invention to be performed. Any reference herein to memory, storage, databases, or other media may include non-volatile and/or volatile memory, as appropriate. Examples of non-volatile memory include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, magnetic tape, floppy disk, magneto-optical data storage device, hard disk, solid state disk, and the like. Examples of volatile memory include Random Access Memory (RAM), external cache memory, and the like.
The respective technical features described above may be arbitrarily combined. Although not all possible combinations of features are described, any combination of features should be considered to be covered by the present specification as long as there is no contradiction between such combinations.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and these modifications or substitutions do not depart from the spirit of the corresponding technical solutions of the embodiments of the present invention.
Claims (6)
1. A method for synchronizing log files between a primary database and a secondary database, the method comprising:
under the condition that the main database detects data modification, generating a log file of the data modification;
the master database transacts the data modification;
under the condition that the transaction processing is successful, the master database synchronizes the log file to the standby database;
the standby database carries out replay according to the log file;
the step that the database replays according to the log file comprises the following steps:
the backup database generates replay progress information in the replay process;
the backup database synchronizes the replay progress information to the main database through a heartbeat mechanism;
the log file is an incremental log file, wherein after the backup database synchronizes the replay progress information to the master database through a heartbeat mechanism, the method further comprises:
under the condition that the standby database fails to be replayed, the standby database sends full synchronous request information to the main database;
the master database generates a full log file according to the full synchronization request information and sends the full log file to the standby database;
and the standby database carries out replay according to the full log file.
2. The method of claim 1, wherein the log files comprise a binlog log file and a redolog log file, and wherein after generating the log file of data modifications, the method further comprises:
and writing the binlog log file into a memory and writing the redolog file into a disk.
3. The method of claim 1, wherein after the backup database replays from the log file, the method comprises:
the standby database determines that the main database fails at the first time according to the heartbeat signal sent by the main database;
and receiving and processing a data processing request by the database at a second time, wherein the second time is later than the first time.
4. An apparatus for synchronizing log files between a primary database and a database, the apparatus comprising:
a first generation unit, configured to generate a log file of data modification in a case where the data modification is detected;
the transaction processing unit is used for carrying out transaction processing on the data modification;
the synchronization unit is used for synchronizing the log file to a standby database under the condition that the transaction processing is successful;
a first playback unit configured to perform playback based on the log file;
the playback unit includes:
the generating module is used for generating replay progress information in the replay process;
the synchronization module is used for synchronizing the replay progress information to the master database through a heartbeat mechanism;
the log file is an incremental log file, and the device further comprises:
a sending unit, configured to send full-scale synchronization request information to the primary database when the backup database fails to be replayed;
the second generation unit is used for generating a full log file according to the full synchronization request information and sending the full log file to the standby database;
and the second playback unit is used for performing playback according to the full log file.
5. The apparatus of claim 4, wherein the log files comprise a binlog log file and a redolog log file, wherein the apparatus further comprises:
and the writing unit is used for writing the binlog log file into a memory and writing the redolog file into a disk.
6. The apparatus of claim 4, further comprising:
the determining unit is used for determining that the main database fails at the first time according to the heartbeat signal sent by the main database;
and the processing unit is used for receiving and processing the data processing request at a second time, wherein the second time is later than the first time.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110810512.4A CN113535665B (en) | 2021-07-16 | 2021-07-16 | Method and device for synchronizing log files between main database and standby database |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110810512.4A CN113535665B (en) | 2021-07-16 | 2021-07-16 | Method and device for synchronizing log files between main database and standby database |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113535665A CN113535665A (en) | 2021-10-22 |
| CN113535665B true CN113535665B (en) | 2022-07-22 |
Family
ID=78128553
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110810512.4A Active CN113535665B (en) | 2021-07-16 | 2021-07-16 | Method and device for synchronizing log files between main database and standby database |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113535665B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113987078B (en) * | 2021-12-24 | 2022-04-19 | 中兴通讯股份有限公司 | Data synchronization method, device and computer readable storage medium |
| CN114490188A (en) * | 2022-02-09 | 2022-05-13 | 北京奥星贝斯科技有限公司 | Method and device for synchronizing main database and standby database |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103077222A (en) * | 2012-12-31 | 2013-05-01 | 中国科学院计算技术研究所 | Method and system for ensuring consistence of distributed metadata in cluster file system |
| CN107203560A (en) * | 2016-03-18 | 2017-09-26 | 中国移动通信集团宁夏有限公司 | Database, multiple database operation transaction consistency ensuring method and system |
| CN108376142A (en) * | 2018-01-10 | 2018-08-07 | 北京思特奇信息技术股份有限公司 | A kind of distributed memory database method of data synchronization and system |
| CN109241185A (en) * | 2018-08-27 | 2019-01-18 | 武汉达梦数据库有限公司 | A kind of method and data synchronization unit that data are synchronous |
| CN112231150A (en) * | 2020-10-27 | 2021-01-15 | 北京人大金仓信息技术股份有限公司 | Method and device for recovering fault database in database cluster |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101719165B (en) * | 2010-01-12 | 2014-12-17 | 浪潮电子信息产业股份有限公司 | Method for realizing high-efficiency rapid backup of database |
| US10915413B2 (en) * | 2017-01-19 | 2021-02-09 | Sap Se | Database redo log optimization by skipping MVCC redo log records |
| CN110825546A (en) * | 2019-09-12 | 2020-02-21 | 烽火通信科技股份有限公司 | Recovery method, system and equipment terminal for high-availability database cluster |
-
2021
- 2021-07-16 CN CN202110810512.4A patent/CN113535665B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103077222A (en) * | 2012-12-31 | 2013-05-01 | 中国科学院计算技术研究所 | Method and system for ensuring consistence of distributed metadata in cluster file system |
| CN107203560A (en) * | 2016-03-18 | 2017-09-26 | 中国移动通信集团宁夏有限公司 | Database, multiple database operation transaction consistency ensuring method and system |
| CN108376142A (en) * | 2018-01-10 | 2018-08-07 | 北京思特奇信息技术股份有限公司 | A kind of distributed memory database method of data synchronization and system |
| CN109241185A (en) * | 2018-08-27 | 2019-01-18 | 武汉达梦数据库有限公司 | A kind of method and data synchronization unit that data are synchronous |
| CN112231150A (en) * | 2020-10-27 | 2021-01-15 | 北京人大金仓信息技术股份有限公司 | Method and device for recovering fault database in database cluster |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113535665A (en) | 2021-10-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9575849B2 (en) | Synchronized backup and recovery of database systems | |
| US11397647B2 (en) | Hot backup system, hot backup method, and computer device | |
| CN107291787B (en) | Main and standby database switching method and device | |
| US10503616B2 (en) | Periodic data replication | |
| US8301600B1 (en) | Failover recovery in a distributed data store | |
| US9563517B1 (en) | Cloud snapshots | |
| US7793060B2 (en) | System method and circuit for differential mirroring of data | |
| CN102891849B (en) | Service data synchronization method, data recovery method, data recovery device and network device | |
| US8806274B1 (en) | Snapshot assisted synchronous replication | |
| CN113535665B (en) | Method and device for synchronizing log files between main database and standby database | |
| CN108628717A (en) | A kind of Database Systems and monitoring method | |
| WO2018098972A1 (en) | Log recovery method, storage device and storage node | |
| US8930751B2 (en) | Initializing replication in a virtual machine | |
| WO2021226905A1 (en) | Data storage method and system, and storage medium | |
| US11436110B2 (en) | Distributed database remote backup | |
| CN102710752A (en) | Disaster recovery storage system | |
| CN106815094B (en) | Method and equipment for realizing transaction submission in master-slave synchronization mode | |
| WO2019109256A1 (en) | Log management method, server and database system | |
| CN112181723A (en) | Financial disaster recovery method and device, storage medium and electronic equipment | |
| CN105938446B (en) | The data supported based on RDMA and hardware transactional memory replicate fault-tolerance approach | |
| US20150317226A1 (en) | Detecting data loss during site switchover | |
| WO2017122060A1 (en) | Parallel recovery for shared-disk databases | |
| CN115934742A (en) | Fault processing method, device, equipment and storage medium | |
| WO2019109257A1 (en) | Log management method, server and database system | |
| WO2022033269A1 (en) | Data processing method, device and system |
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 |