WO2023151443A1

WO2023151443A1 - Synchronizing main database and standby database

Info

Publication number: WO2023151443A1
Application number: PCT/CN2023/071515
Authority: WO
Inventors: 杨传辉
Original assignee: 北京奥星贝斯科技有限公司
Priority date: 2022-02-09
Filing date: 2023-01-10
Publication date: 2023-08-17
Also published as: CN114490188A

Abstract

Provided in the present disclosure are a method and apparatus for synchronizing a main database and a standby database. The method can be applied to a main database, and the method comprises: receiving a first transaction request, wherein the first transaction request is used for requesting the modification of data in a main database; in response to the first transaction request, executing a modification operation on the data in the main database; performing data synchronization with a first standby database according to the modification operation; if data synchronization fails, sending a notification message to an arbitrator, wherein the notification message is used for notifying the arbitrator of the deletion of the first standby database from a first database set, and databases in the first database set are all standby databases which are synchronized with the data in the main database; and sending, to an initiator of a first transaction, a response for the first transaction request.

Description

Synchronize primary and standby databases

technical field

The present disclosure relates to the technical field of databases, and in particular to a method and device for synchronizing active and standby databases.

Background technique

Disasters may render the database unavailable, making it impossible to continue to provide services. Related technologies can realize disaster recovery based on the active-standby synchronization mechanism. For example, when the primary database is unavailable due to a disaster, the active/standby switchover can be performed, and the standby database can continue to provide services. However, there are many problems in the active-standby synchronous disaster recovery mechanism. For example, when the standby database is unavailable, the primary database cannot continue to serve. Or, data may be lost during active/standby switchover.

Contents of the invention

In view of this, the present disclosure provides a method and device for synchronizing primary and secondary databases to solve the above problems.

In a first aspect, a method for synchronizing primary and standby databases is provided, the method is applied to the primary database, and the method includes: receiving a first transaction request, the first transaction request is used to request data in the primary database Modify; in response to the first transaction request, perform a modification operation on the data in the primary database; perform data synchronization with the first standby database according to the modification operation; if the data synchronization fails, send a notification to the arbitrator message, the notification message is used to notify the arbitrator to delete the first standby database from the first database set, and the databases in the first database set are all standby databases synchronized with the primary database data; A reply to the first transaction request is sent to the initiator of the first transaction.

Optionally, the performing data synchronization with the first standby database according to the modification operation includes: generating a redo log according to the modification operation; and sending the redo log to the first standby database.

In the second aspect, a method for synchronizing primary and standby databases is provided, the method is applied to the arbitrator, and the method includes: receiving a notification message sent by the primary database, the notification message is used to notify the arbitrator to update the The first standby database is deleted from the first database set, and the databases in the first database set are all standby databases synchronized with the data of the primary database; according to the notification message, the first standby database is deleted from the Deleted in the first database collection.

Optionally, the method further includes: selecting a database from the first set of databases for switching to the primary database.

Optionally, the first data set is recorded in a list.

Optionally, the arbitrator is implemented based on an election protocol.

In a third aspect, there is provided a device for synchronizing primary and backup databases, the device is deployed with a primary database, and the device includes: a first receiving unit, configured to receive a first transaction request, and the first transaction request is used to request modify the data in the primary database; the executing unit is configured to perform a modifying operation on the data in the primary database in response to the first transaction request; the synchronizing unit is configured to communicate with the first backup according to the modifying operation The database performs data synchronization; the first sending unit is configured to send a notification message to the arbitrator if the data synchronization fails, and the notification message is used to notify the arbitrator to remove the first standby database from the first database set For deletion, the databases in the first database set are all standby databases synchronized with the primary database data; the response unit is configured to send a response to the first transaction request to the initiator of the first transaction.

Optionally, the synchronizing unit includes: a generating unit, configured to generate redo logs according to the modification operation; a second sending unit, configured to send redo logs to the first standby database.

In a fourth aspect, there is provided a device for synchronizing primary and standby databases, the device is deployed with an arbitrator, and the device includes: a second receiving unit, configured to receive a notification message sent by the primary database, and the notification message is used to notify The arbitrator deletes the first standby database from the first database set, and the databases in the first database set are all standby databases synchronized with the data of the primary database; the deletion unit is configured to message, deleting the first standby database from the first database set.

Optionally, the device further includes: a selection unit, configured to select a database from the first set of databases for switching to the primary database.

Optionally, the first data set is recorded in a list.

Optionally, the arbitrator is implemented based on an election protocol.

In a sixth aspect, a computer-readable storage medium is provided, on which executable code is stored, and when the executable code is executed, the method as described in the first aspect or the second aspect can be implemented.

In a seventh aspect, a computer program product is provided, including executable codes, and when the executable codes are executed, the method as described in the first aspect or the second aspect can be implemented.

When the first operation fails to synchronize to the first standby database (that is, the first standby database is unavailable), the primary database may notify the arbitrator to delete the first standby database from the first database set and continue to serve. When the primary database is unavailable, the standby database in the first database set may be selected to perform active-standby switchover without causing data loss. Therefore, based on the method provided by the present disclosure, when any one of the primary database or the first standby database is unavailable, the system can still continue to serve, and the problem of data loss will not occur.

Description of drawings

FIG. 1 is a schematic flowchart of a method for synchronizing primary and secondary databases provided by an embodiment of the present disclosure.

FIG. 2 is a schematic flowchart of another method for synchronizing primary and secondary databases provided by an embodiment of the present disclosure.

FIG. 3 is a schematic flowchart of another method for synchronizing primary and secondary databases provided by an embodiment of the present disclosure.

FIG. 4 is a schematic structural diagram of an apparatus for synchronizing active and standby databases provided by an embodiment of the present disclosure.

FIG. 5 is a schematic structural diagram of another device for synchronizing active and standby databases according to an embodiment of the present disclosure.

FIG. 6 is a schematic structural diagram of another device for synchronizing primary and secondary databases provided by an embodiment of the present disclosure.

Detailed ways

The following will clearly and completely describe the technical solutions in the embodiments of the present disclosure with reference to the accompanying drawings of the embodiments of the present disclosure. Apparently, the described embodiments are only some of the embodiments of the present disclosure, not all of them.

database (database, DB)

Databases can be used to organize, store and manage data in terms of data structures. The database can perform operations such as adding, deleting, modifying, or searching data in the database according to the modification transaction request. Common databases include Oracle, MySQL, DB2, MongoDB, and Redias. A database is an essential part of a system such as a production system.

Databases are inevitably subject to disasters and failures. Disasters may include: force majeure (such as natural disasters or terrorist attacks, etc.), heavy data load (such as high concurrent data or massive data, etc.), or network failures. The related technology proposes a disaster recovery mechanism for the database, so as to realize that the database can continue to serve or restore the service after encountering a disaster, thereby improving the usability and stability of the database.

As a disaster recovery mechanism, a system (such as a production system) may include multiple databases. Every database in the system can synchronize the same replica, i.e. store the same data. Multiple databases can be set in different locations (such as different machines, computer rooms or cities). When a database encounters a disaster, other databases can continue to serve.

Active-standby synchronization disaster recovery mechanism

Under the active-standby synchronous disaster recovery mechanism, the system can include a primary database and one or more standby databases. The primary database can read and write data, and the standby database can be used to back up the data in the primary database. The primary database can also be called the main database or the production database, and the standby database can also be called the standby database or the slave database.

Disasters can render the primary and/or standby databases unavailable. The unavailability of the primary database may include primary database failure. The situation that the standby database is unavailable may include a failure of the standby database or a network failure between the primary and standby databases.

When the primary database is unavailable due to a disaster, the system can switch to the standby database to continue serving to avoid the impact of the disaster. Every time an operation is performed on the primary database, the operation needs to be synchronized to the standby database to achieve the consistency of data in the primary database and the standby database, so that when switching, it can ensure that the standby database of the primary database is switched to the original primary database. The data is the same. The master-standby synchronization scheme can include Oracle's data protection scheme DataGuard, MySQL master-standby synchronization, and election-based master-standby synchronization.

The redo log (undo log) is a key structure in the database. Redo logs are used to record changes to the database. A redo log can consist of one or more log files. For the master-standby synchronization scheme, the master database and the standby database can be associated with corresponding redo logs. In the event of a disaster, data recovery can be performed based on redo logs. The primary database can synchronize redo logs to the standby database to achieve data backup.

As an implementation manner, the disaster recovery method based on master-standby synchronization may include steps S101 to S105. Step S101, the master database receives a transaction request. In step S102, the master database executes the modification operation corresponding to the transaction request. Step S103, the primary database synchronizes the modification operation to the standby database. As an implementation, the primary database can write modification operations to redo log files and synchronize the redo log files to the standby database. Step S104, the master database sends a response to the transaction request to the initiator of the modification transaction. The different modes are described in detail below.

The synchronization between the primary database and the standby database can be achieved through the following modes: maximum protection mode (maximum protection), maximum performance mode (maximum performance) or maximum availability mode (maximum availability).

In the highest protection mode, only when the modification operation is successfully synchronized to the standby database, the primary database can respond to the initiator of the modification transaction. Therefore, the highest protection mode can realize the complete consistency of the data of the primary database and the data of the standby database. As an implementation manner, if the primary database receives a synchronization success message fed back by the standby database, the primary database may respond to the modification transaction initiator to report that the modification transaction is executed successfully. Alternatively, if the primary database does not receive a synchronization success message from the standby database within a certain period of time, the primary database may not respond to the initiator of the modification transaction.

In the highest performance mode, after the primary database successfully completes the operation corresponding to the transaction request, it can respond to the initiator of the transaction request without considering the synchronization of the modified transaction to the standby database. As an implementation method, the master database can report to the modification transaction initiator that the modification transaction is successfully executed after successfully writing the local redo log. A background thread can asynchronously copy redo logs to the standby database.

In the highest availability mode, if the standby database is available, the synchronization mode is the highest protection mode. If the standby database is unavailable, such as if the standby database fails or the network between the primary and standby database fails, synchronous mode degrades to the highest performance mode.

In some embodiments, the highest protection mode may be called strong synchronous mode, and the highest performance mode or highest availability mode may be called asynchronous replication mode.

Active-standby Synchronous Disaster Recovery Mechanism Based on Election Protocol

Election protocols can be implemented based on majority voting. Election protocols can be used to solve the problem of how to reach agreement on a certain value (or resolution). To implement the election protocol, at least 3 nodes need to be deployed to support the majority (more than half) and the minority. The election protocol may include, for example, Paxos or Raft (that is, a simplified version of Paxos).

In the master-slave synchronization scheme based on the election protocol, the system needs to deploy at least 3 nodes (also called replicas), and each node is used to store data, that is, the system includes at least 3 databases. In actual deployment, the system can deploy 3, 5 or more nodes. Taking the system with 3 nodes deployed as an example, each master-standby synchronization or master-standby switchover must be executed successfully on at least 2 nodes before it can be considered successful. Taking the system deployed with 5 nodes as an example, each master-standby synchronization or master-standby switchover must be executed successfully on at least 3 nodes before it can be considered successful.

For master-slave synchronization, when the operation is synchronized to the majority (more than half) nodes, the modification transaction initiator can be fed back to the modification transaction execution success. For active-standby switching, when a minority (either the primary database or the standby database) fails, a new node can be selected through an election protocol to continue providing services.

Lossless automatic disaster recovery

The disaster recovery mechanism can be evaluated by at least one of recovery point objective (RPO) and recovery time objective (recovery time objective). RPO can refer to the length of time at which data can be lost at most. RTO can refer to the maximum time required from a disaster to return to normal. Understandably, the shorter the RPO, the less data may be lost. The shorter the RTO, the longer the database can be up and running.

After a failure occurs, if the system can automatically recover within a short period of time without losing data, the system can achieve lossless automatic disaster recovery. For example, if the RPO of a system=0 and the RTO is relatively short (for example, the RTO is less than one minute), it can be considered that the system can achieve lossless disaster recovery.

The following is an analysis of the support of the above-mentioned master-slave synchronization scheme for lossless automatic disaster recovery one by one.

In the highest protection mode, the data in the standby database is strongly consistent with the data in the primary database. When the primary database fails, no data will be lost when switching between the primary and secondary databases. When the standby database fails, the primary and standby synchronization cannot be performed, and the service needs to be suspended.

In the highest performance mode, when the standby database fails, the primary database can continue to serve, so high availability can be achieved. When the primary database fails, data consistency between the primary database and the primary database cannot be guaranteed because the data in the primary database may not have been synchronized to the standby database, and there is a possibility of data loss when switching to the standby database.

The highest available mode is a combination of the highest protection mode and the highest performance mode. Therefore, it is still impossible to determine that the data in the standby database is consistent with the data in the primary database. When the primary database fails, it is difficult to achieve lossless primary-standby switchover.

It can be seen that in the highest protection mode, highest performance mode or highest availability mode, service suspension or data loss may occur after the failure of the primary database or the standby database. Therefore, it is difficult for the above three modes to realize automatic lossless disaster recovery.

The active-standby mechanism based on the election protocol can continue to serve when the minority is unavailable (such as node failure or communication failure between nodes). Take the system including 3 nodes for storing data as an example, and the minority is 1 node. That is, when any one of the 3 nodes (primary database or standby database) is unavailable, the majority can continue to serve. It can be seen from this that the active and standby mechanism based on the election protocol can realize automatic lossless disaster recovery. Taking the deployment mode of three nodes in the same computer room as an example, this mode can support non-destructive disaster recovery after a database failure on one machine in the computer room. Or, taking the deployment mode of three computer rooms in the same city as an example, this mode can support non-destructive disaster recovery after the database failure of one computer room. Or, take the deployment mode of three locations and five centers as an example, which can support non-destructive disaster recovery after a database failure in a city.

It can be seen from the above that the highest protection mode, the highest performance mode or the highest availability mode can only serve normally when the primary database is unavailable, or can only serve normally when the standby database is unavailable. Services can still be provided as normal. Therefore, it is difficult for the above three modes to realize automatic lossless disaster recovery. Although the master-standby synchronization based on the election protocol can realize the lossless disaster recovery of any node (primary database or standby database), but there are many nodes to store data, and the storage cost is high. It can be seen from this that it is difficult for related technologies to achieve lossless automatic disaster recovery, or the cost of realizing lossless automatic disaster recovery is relatively high.

In view of the above problems, the present disclosure proposes a method for synchronizing primary and secondary databases. Fig. 1 is a schematic flowchart of a method for synchronizing primary and secondary databases proposed by an embodiment of the present disclosure. The method shown in FIG. 1 can be implemented by the primary database, the first standby database, the arbitrator and the initiator. The method shown in FIG. 1 may include step S110 to step S160.

Step S110, the primary database receives a first transaction request.

A first transaction request may be used to request modifications to data in the primary database. The initiator may send at least one transaction request to the main database, and the first transaction request may be any item in the at least one transaction request. The initiator of the first transaction request may be a client.

Step S120, in response to the first transaction request, modifying the data in the master database.

The modify operation corresponds to the first transaction request. The modification operation may include at least one of adding, deleting, and changing data in the master database.

Step S130, perform data synchronization on the first standby database according to the modification operation.

As an implementation manner, the modification operation may be sent to the first standby database for synchronization by the first standby database.

Data synchronization between the primary database and the first standby database can be implemented based on redo logs. As an implementation manner, step S130 may include step S131 and step S132.

Step S131, generating a redo log according to the modification operation. For example, a master library can write modification operations to a local log file to generate redo logs.

Step S132, sending redo logs to the first standby database.

The first standby database may generate redo logs of the first standby database according to the received redo logs. For example, the first standby database can replicate the redo logs of the primary database to the first standby database.

The primary database can synchronize data with multiple standby databases. The first standby database can be any one of multiple databases.

The primary database may or may not succeed in synchronizing data to the first standby database. In the case of successful synchronization, the first standby database may feed back a message, for example, a message of "successful synchronization". In the case of a synchronization failure, the first standby database may feed back a message, for example, a message of "synchronization failure". Or, in some cases, the first standby database cannot perform feedback or the feedback information cannot be delivered to the primary database. Therefore, if the first standby database does not feed back the synchronization result within a certain period of time, the primary database may also determine that the synchronization of the first data to the first standby database has failed.

Step S140, if the data synchronization fails, the master database sends a notification message to the arbitrator.

The notification message is used to notify the arbitrator to delete the first standby database from the first data set.

Step S150, according to the notification message, the arbitrator deletes the first standby database from the first database set.

An arbitrator may maintain a first set of databases. All the databases in the first database set can be standby databases that are synchronized with the data of the primary database. It can be understood that the data of the standby database in the first database set is strongly consistent with the data of the primary database.

The arbitrator can refer to the first database set to select the standby database for the master-standby switchover, so as to avoid data loss caused by data inconsistency in the master-standby database during the master-standby switchover. As an implementation method, when the arbitrator detects that the primary database is unavailable (for example, the primary database fails), the arbitrator can automatically select a standby database in the first database set to switch over, instead of selecting a standby database that is not in the first database set standby database.

No matter whether the data synchronization in step S130 is successful or not, the master database can execute step S160.

Step S160, sending a response to the first transaction request to the initiator of the first transaction.

It can be understood that the primary database can respond to the initiator of the first transaction request to successfully modify the transaction. After the initiator receives the response, it can continue to send other transaction requests. The response of the primary database to the initiator may be independent of whether the data of the first standby database is successfully synchronized with the primary database. Therefore, even if data synchronization to the first standby database fails (that is, the primary database sends a notification message to the arbitrator), as long as the execution of the modified transaction is successfully executed, the initiator of the first transaction can be answered.

As an implementation method, after the primary database fails to synchronize data with the first standby database, subsequent modification operations generated by other transaction requests only need to be successfully executed on the primary database and/or successfully written to the log of the primary database to respond to the initiator. It is not necessary to synchronize data to the first standby database. It should be noted that the master data can send a notification message to the arbitrator to remove the first standby database from the first database set before synchronizing data to the first standby database, so that the first database set maintained by the arbitrator The data in the standby database is always up-to-date.

It can be seen from this that when the modification operation fails to be synchronized to the first standby database, that is, the first standby database is unavailable (for example, the first standby database fails or the network between the primary database and the first standby database fails), the primary database The service may not be stopped and the arbitrator is notified to delete the first standby database from the first database set. When the primary database is unavailable, the arbitrator can select a standby database consistent with the data of the primary database to switch to the primary database through the first database set, without causing data loss. Therefore, based on the method provided in the present disclosure, when any one of the primary database or the first standby database is unavailable, the system can still continue to serve, and the problem of data loss will not occur. It can be seen that the RPO of the master-slave synchronization solution provided by the present disclosure is equal to 0, and the RTO is less than one minute, that is, automatic lossless disaster recovery can be realized. That is to say, the present disclosure can not only realize the high availability of the database, but also realize that the data will not be lost during the master-standby switchover.

In addition, the present disclosure requires at least two nodes for data storage (a primary database and a standby database) to achieve lossless disaster recovery. Compared with the scheme that requires at least 3 nodes for storage (one primary database and two standby databases) (such as the primary-standby synchronization scheme based on the election protocol), it reduces the data copies that need to be stored, thereby reducing the cost of data storage. cost.

The present disclosure does not limit the manner in which the first database sets records. As an implementation manner, the first database set may be recorded in the form of a list, that is, the standby database whose data is consistent with the primary database is recorded in a synchronization list.

As an implementation, if all modification operations of the primary database are successfully synchronized to the first standby database, the primary database can send the first message to add the first standby database. The arbitrator can add the first standby database to the first standby database according to the first message in a database collection. For example, after the arbitrator deletes the first standby database from the first database set, if the first standby database is restored to an available state, and the data synchronization between the primary database and the first standby database is successful, the primary database can notify the arbitrator to remove the first The standby database is added to the first database set. Alternatively, after the first standby database is initially registered with the primary database, and the primary database and the first standby database successfully perform data synchronization, the primary database may notify the arbitrator to add the first standby database to the first database set.

The primary database may have multiple standby databases associated with it, and the first standby database may be any one of the multiple standby databases. In this case, the first set of standby databases may include one or more standby databases. The primary database may send notification messages for different standby databases to the arbitrator, so as to notify the arbitrator which standby database or databases to delete from the first database set.

The arbitrator may be a third party that is relatively independent from the primary database and the standby database. Therefore, the arbitrator may be called a third-party arbitrator or a third-party arbitrator.

When deploying the arbitrator, the arbitrator can be deployed separately from the database (including the primary database, the first standby database or other standby databases). For example, the arbitrator and the database can be deployed on different machines, different computer rooms or different cities. When the database suffers from a disaster, the arbitrator deployed separately from the database can avoid the disaster, so that the arbitrator can still serve normally even if the database suffers a disaster.

The arbitrator can be implemented through an election protocol to achieve high availability of the arbitrator. As an implementation, the arbitrator can use Paxos or Raft election protocol. The arbitrator may include at least 3 nodes (eg 3 or 5 nodes). When a few nodes of the arbitrator are unavailable (such as node failure or network failure), new nodes can be selected through the election protocol to continue to provide services, so that the arbitrator has high availability. It is understandable that in addition to the election protocol, the arbitrator can also be implemented in other ways that can achieve high availability.

Multiple systems can share a single arbiter, reducing the cost of arbitrator deployment. That is to say, the arbitrator can be used to maintain multiple database collections that correspond one-to-one to multiple master databases. Each database set includes a standby database that is synchronized with the corresponding primary database data. For example, a company can deploy a set of globally available arbitrator services, and all the database nodes can share this set of arbitrator services.

FIG. 2 and FIG. 3 are schematic diagrams of an active-standby synchronous disaster recovery method provided by an embodiment of the present disclosure.

Fig. 2 shows the master-standby synchronization method when both the master database and the first standby database are available. The method shown in FIG. 2 can be executed by the client, the primary database and the first standby database. The arbitrator may include 3 nodes (the nodes are represented by circles in Figure 3), and is implemented based on the election protocol.

The method shown in FIG. 2 may include step S210 to step S240.

Step S210, the client sends a transaction modification request to the master database.

Step S221, the master database writes a log in a local log file. The local log files can be the redo log files of the primary database.

Step S222, synchronizing the modification operation to the first standby database. Step S221 and step S222 may be performed synchronously.

Step S230, in response to the master-standby synchronization operation, the first standby database writes the modification operation into the log file of the standby database.

In step S240, the first standby database replies "successful synchronization" to the primary database.

In step S250, the master database sends second information to the client, and the second information is used to reply that the client successfully executes the modification transaction.

Fig. 3 shows a fault handling method when the first standby database is unavailable. The method shown in FIG. 3 can be executed by the client, the primary database, the first standby database, and the arbitrator. The arbitrator may include 3 nodes (the nodes are represented by circles in Figure 3), and is implemented based on the election protocol.

The method shown in FIG. 3 may include step S310 to step S340.

Step S310, the client sends a transaction modification request to the master database.

Step S321, the master database writes a log in a local log file. The local log files are the redo log files of the primary database.

Step S322, synchronizing the modification operation to the first standby database. Step S321 and step S322 may be performed synchronously.

Step S330, when the primary database has not received the response from the first standby database to the synchronization of the primary and secondary databases after a certain period of time (that is, at least one failure in the first standby database and the network between the first standby database and the primary database) , the primary database sends the first message to the arbitrator to notify the arbitrator to remove the first standby database from the synchronization list.

In step S340, the master database sends second information to the client, and the second information is used to reply that the client successfully modifies the transaction.

Based on the methods shown in FIG. 2 and FIG. 3 , it can be realized that the data in the standby database in the synchronization list maintained here is consistent with the data in the primary database. Whether the primary database or the standby database is unavailable later, the arbitrator can select a database (such as a server) in the synchronization list to continue the synchronization service after detecting the failure.

For example, when the first standby database fails, the first standby database may be removed from the synchronization list after the primary database fails to synchronize with the first standby database. Subsequent primary database can feed back the second information to the client after successfully writing the local log file.

Alternatively, when a network failure occurs between the primary database and the first standby database, the first standby database may be removed from the synchronization list after the primary database fails to synchronize to the first standby database. Subsequent primary database can feed back the second information to the client after successfully writing the local log file. Next, if the first standby database fails, there is no need to deal with it. If the primary database fails later, since the first standby database is not in the synchronization list, the arbitrator may not select the first standby database to switch to the primary database, thereby avoiding data loss.

Or, in the case of failure of the primary database, the arbitrator detects the failure of the primary database, and after a period of time, the standby database in the synchronization list can be synchronized (if the synchronization list includes the first standby database, the first standby database can be selected) Switch to the primary database to continue the service.

The method embodiments provided by the present disclosure are described above through FIGS. 1 to 3 , and the device embodiments provided by the present disclosure are described below with reference to FIGS. 4 to 6 .

FIG. 4 is a schematic structural diagram of an apparatus 400 for synchronizing active and standby databases according to an embodiment of the present disclosure. Apparatus 400 may be a computing device with computing functions, such as a server. The device 400 is deployed with a master database. The apparatus 400 may include a first receiving unit 410 , an execution unit 420 , a synchronization unit 430 , a first sending unit 440 and a response unit 450 .

The first receiving unit 410 may be used to receive a first transaction request, and the first transaction request is used to request to modify data in the master database; the execution unit 420 may be used to respond to the first transaction request, to modify the The data in the primary database performs a modification operation; the synchronization unit 430 can be used to perform data synchronization with the first standby database according to the modification operation; the first sending unit 440 can be used to send a notification to the arbitrator if the data synchronization fails message, the notification message is used to notify the arbitrator to delete the first standby database from the first database set, and the databases in the first database set are all standby databases synchronized with the primary database data; The response unit 450 may be configured to send a response to the first transaction request to the initiator of the first transaction.

Optionally, the synchronizing unit 430 may include: a generating unit and a second sending unit. The generation unit can be used to generate redo logs according to the modification operation. The second sending unit may be used to send redo logs to the first standby database.

FIG. 5 is a schematic structural diagram of an apparatus 500 for synchronizing active and standby databases provided by an embodiment of the present disclosure. Apparatus 500 may be a computing device with computing functions, such as a server. Apparatus 500 deploys an arbitrator. The apparatus 500 may include a second receiving unit 510 and a deleting unit 520 .

The second receiving unit 510 may be configured to receive a notification message sent by the primary database, the notification message is used to notify the arbitrator to delete the first standby database from the first database set, and the first database set in the first database set The databases are all standby databases synchronized with the data of the primary database.

The deleting unit 520 may be configured to delete the first standby database from the first database set according to the notification message.

Optionally, the apparatus 500 may further include: a selection unit. The selection unit may be used to select a database from the first set of databases for switching to the primary database.

Optionally, the first data set is recorded in a list.

Optionally, the arbitrator is implemented based on an election protocol.

Fig. 6 is a schematic structural diagram of an apparatus for synchronizing primary and secondary databases according to yet another embodiment of the present disclosure. The apparatus 600 may be, for example, a computing device with a computing function. For example, the device 600 may be a mobile terminal or a server. The apparatus 600 may include a memory 610 and a processor 620 . Memory 610 may be used to store executable code. The processor 620 can be used to execute the executable code stored in the memory 610, so as to realize the steps in the various methods described above. In some embodiments, the apparatus 600 may further include a network interface 630 through which data exchange between the processor 620 and external devices may be implemented.

In the above embodiments, all or part may be implemented by software, hardware, firmware or other arbitrary combinations. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, all or part of the processes or functions according to the embodiments of the present disclosure will be generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server or data center Transmission to another website site, computer, server or data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrated with one or more available media. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a digital video disc (digital video disc, DVD)), or a semiconductor medium (such as a solid state disk (solid state disk, SSD)), etc. .

Those skilled in the art can appreciate that the units and algorithm steps of the examples described in conjunction with the embodiments of the present disclosure can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementation should not be considered beyond the scope of the present disclosure.

In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.

The above is only a specific implementation of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Anyone skilled in the art can easily think of changes or substitutions within the technical scope of the present disclosure. should fall within the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be determined by the protection scope of the claims.

The above descriptions are only preferred embodiments of the present disclosure, and are not intended to limit the present disclosure. Any modifications, equivalent replacements, etc. made within the spirit and principles of the present disclosure shall be included in the protection scope of the present disclosure within.

Claims

A method for synchronizing active and standby databases, the method being applied to the active database, the method comprising:

receiving a first transaction request, where the first transaction request is used to request to modify data in the master database;

In response to the first transaction request, perform a modification operation on data in the primary database;

Perform data synchronization with the first standby database according to the modification operation;

If the data synchronization fails, send a notification message to the arbitrator, where the notification message is used to notify the arbitrator to delete the first standby database from the first database set, and the databases in the first database set are all A standby database that is synchronized with the primary database data;

A reply to the first transaction request is sent to the initiator of the first transaction.
The method according to claim 1, said performing data synchronization with the first standby database according to said modification operation comprises:

Generate a redo log according to the modification operation;

Send redo logs to the first standby database.
A method for synchronizing active and standby databases, the method is applied to an arbitrator, and the method includes:

receiving a notification message sent by the primary database, the notification message is used to notify the arbitrator to delete the first standby database from the first database set, and the databases in the first database set are all synchronized with the primary database data standby database;

According to the notification message, the first standby database is deleted from the first database set.
The method of claim 3, further comprising:

Selecting a database for switching to the primary database from the first database set.
The method of claim 3, said first set of data being recorded by a list.
The method according to claim 3, the arbitration party is implemented based on an election protocol.
A device for synchronizing primary and backup databases, the device is deployed with a primary database, and the device includes:

The first receiving unit is configured to receive a first transaction request, and the first transaction request is used to request modification of data in the master database;

an execution unit, configured to perform a modification operation on data in the master database in response to the first transaction request;

a synchronization unit, configured to perform data synchronization with the first standby database according to the modification operation;

The first sending unit is configured to send a notification message to the arbitrator if the data synchronization fails, the notification message is used to notify the arbitrator to delete the first standby database from the first database set, and the second standby database is deleted from the first database set. The databases in a database set are standby databases synchronized with the primary database data;

A response unit, configured to send a response to the first transaction request to the initiator of the first transaction.
The device according to claim 7, the synchronization unit comprising:

a generating unit, configured to generate a redo log according to the modification operation; and

The second sending unit is configured to send redo logs to the first standby database.
A device for synchronizing active and standby databases, the device is deployed with an arbitrator, and the device includes:

The second receiving unit is configured to receive a notification message sent by the primary database, the notification message is used to notify the arbitrator to delete the first standby database from the first database set, and the databases in the first database set are all A standby database synchronized with the primary database data;

A deleting unit, configured to delete the first standby database from the first database set according to the notification message.
The apparatus of claim 9, further comprising:

The selecting unit selects a database from the first set of databases for switching to the primary database.
The apparatus of claim 9, said first set of data being recorded by a list.
The apparatus according to claim 9, the arbitrator is implemented based on an election protocol.
A device for synchronizing active and standby databases, comprising a memory and a processor, wherein executable code is stored in the memory, and the processor is configured to execute the executable code, so as to realize any one of claims 1-6 the method described.