High availability data management

Abstract

The present disclosure provides a method and apparatus for managing high availability data, a program product, a device, and a storage medium. The method is used in a first database of a data system, the data system further comprising an arbitration node and a second database, the first database serving as a main database, and the second database serving as a backup database. The method comprises: writing target data indicated by a data write request in a first database, and writing the target data to a second database; in response to a failure in writing the target data to the second database, performing transaction rollback on the data write request and sending a backup database demote request to the arbitration node and the second database; and in response to determination information returned by the arbitration node and / or the second database for the backup database demote request, switching a data system from a backup database normal state to a backup database abnormal state. The main database is used to determine that writing is successful in response to successful writing of data in the main database and the backup database when in the backup database normal state, and determine that writing is successful in response to successful writing of data in the main database when in the backup database abnormal state.

Description

High availability data management TECHNICAL FIELD

[0001] One or more embodiments of the present disclosure relate to the technical field of database, and in particular, to high availability data management. BACKGROUND

[0002] In today's high-speed development of the Internet and informatization, the production of data is growing explosively, so the requirements for databases and their management are getting higher and higher. The current distributed database often faces temporary failures by setting up a master and a backup, that is, when the master fails, the backup can be switched to the master to continue to provide services, thereby avoiding the service stop when the database fails, which affects the service quality and efficiency.

[0003] Generally, the master of the distributed database provides write services to the outside, and the backup is used to backup data. In related technologies, the distributed database will be down when the backup is abnormal because the data cannot be written, resulting in the inability to provide services to the outside. SUMMARY

[0004] Therefore, one or more embodiments of the present disclosure provide a high availability data management method and device, program product, equipment and storage medium.

[0005] To achieve the above object, the technical solutions of one or more embodiments of the present disclosure are provided as follows.

[0006] According to a first aspect of one or more embodiments of the present disclosure, a high availability data management method is provided, applied to a first database in a data system, the data system further comprising an arbitration node and a second database, the first database serving as a master, and the second database serving as a backup, the method comprising: in response to receiving a data write request sent by a client, writing target data indicated by the data write request in the first database, and writing the target data to the second database; in response to a write operation of writing the target data to the second database failing to execute, performing transaction rollback on the data write request, and sending a backup degradation request to the arbitration node and the second database respectively; in response to receiving determination information returned by the arbitration node and / or the second database for the backup degradation request, switching the data system from a backup normal state to a backup abnormal state; wherein the master is configured to, when the data system is in the backup normal state, return a write success message to the client in response to the target data being written successfully in the master and the backup respectively, and when the data system is in the backup abnormal state, return a write success message to the client in response to the target data being written successfully in the master.

[0007] In one embodiment of the present disclosure, the writing the target data indicated by the data write request into the first database and writing the target data into the second database comprises: writing the target data indicated by the data write request into a leader replica of the first database and generating a data write log; and sending the data write log to other replicas of the first database and the second database respectively, so that the other replicas of the first database and the second database replay the data write log respectively to write the target data.

[0008] In one embodiment of the present disclosure, the method further comprises: in response to receiving write acknowledgement messages returned by no less than a first preset number of replicas of the other replicas of the first database within a preset time length, determining that the writing operation of the target data into the first database is successfully executed; and in response to not receiving write acknowledgement messages returned by no less than the first preset number of replicas of the other replicas of the first database within a preset time length, determining that the writing operation of the target data into the first database fails.

[0009] In one embodiment of the present disclosure, the writing the target data into the second database comprises: writing the target data into multiple replicas of the second database respectively; in response to receiving write acknowledgement messages returned by no less than a second preset number of replicas of the multiple replicas of the second database within a first preset time length, determining that the writing operation of the target data into the second database is successfully executed; and in response to not receiving write acknowledgement messages returned by no less than the second preset number of replicas of the multiple replicas of the second database within the first preset time length, determining that the writing operation of the target data into the second database fails.

[0010] In one embodiment of the present disclosure, the method further comprises: in response to the first database being in a normal state and a renewal condition being met between a current time and a master lease, sending a first master election request to the arbitration node and the second database respectively; and in response to receiving acknowledgement information returned by the arbitration node and / or the second database for the first master election request, extending the master lease by a second preset time length.

[0011] In one embodiment of the present disclosure, the method further comprises: in response to the first database being in an abnormal state and the current time and the master library lease satisfying the lease renewal condition, not sending a first master library election request to the arbitration node and the second database, so that the second database sends a second master library election request to the arbitration node and the first database respectively in response to the current time and the master library lease satisfying the lease renewal condition and not receiving the first master library election request sent by the first database, and switches the second database as a master library in response to receiving the confirmation information returned by the arbitration node and / or the first database for the second master library election request.

[0012] In one embodiment of the present disclosure, the method further comprises: in response to the first database being in an abnormal state and receiving a data write request sent by a client, returning a write failure message to the client.

[0013] In one embodiment of the present disclosure, the method further comprises: in response to a write operation for writing the target data in the first database failing, determining that the first database is in an abnormal state.

[0014] In one embodiment of the present disclosure, the method further comprises: the system partition periodically sending a master library lease to a user partition in response to the first database being in a normal state, and determining that the first database is in an abnormal state in response to not receiving the master library lease periodically sent by the user partition; and the user partition periodically sending a master library lease to the system partition in response to the first database being in a normal state, and determining that the first database is in an abnormal state in response to not receiving the master library lease periodically sent by the system partition.

[0015] According to a second aspect of one or more embodiments of the present disclosure, a high-availability data management method is provided, applied to a second database of a data system, the data system further comprising an arbitration node and a first database, the first database serving as a master database, and the second database serving as a standby database, the method comprising: in response to a write operation of the first database to the second database for target data being successfully executed, returning a write confirmation message to the first database, so that the first database: in response to the target database being successfully written in the first database and the second database respectively, returns a write success message to a client; in response to a write operation of the target data to the second database being failed, performing transaction rollback on the data write request, and sending a standby database degradation request to the arbitration node and the second database respectively; in response to receiving determination information returned by the arbitration node and / or the second database for the standby database degradation request, switching the data system from a standby database normal state to a standby database abnormal state; wherein the target data is indicated by a data write request sent by the client to the first database to be written in the first database and the second database respectively; the master database is configured to return a write success message to the client in response to the target data being successfully written in the master database and the standby database respectively when the data system is in the standby database normal state, and return a write success message to the client in response to the target data being successfully written in the master database when the data system is in the standby database abnormal state.

[0016] In an embodiment of the present disclosure, the method further comprises: in response to a reappointment condition being met between a current time and a master database lease, and no first master database election request sent by the first database being received, sending a second master database election request to the arbitration node and the first database respectively, and in response to receiving confirmation information returned by the arbitration node and / or the first database for the second master database election request, switching the second database to a master database.

[0017] According to a third aspect of one or more embodiments of the present disclosure, a high-availability data management apparatus is provided, comprising: a first database applied in a data system, the data system further comprising an arbitration node and a second database, the first database serving as a master database, and the second database serving as a standby database, the apparatus comprising: a write module configured to write target data indicated by a data write request received from a client in the first database, and write the target data in the second database; a sending module configured to, in response to a write operation of writing the target data in the second database failing, perform transaction rollback on the data write request, and send a standby database degradation request to the arbitration node and the second database respectively; and a degradation module configured to, in response to receiving determination information returned by the arbitration node and / or the second database in response to the standby database degradation request, switch the data system from a standby database normal state to a standby database abnormal state; wherein the master database is configured to, when the data system is in the standby database normal state, return a write success message to the client in response to the target data being written in the master database and the standby database respectively, and when the data system is in the standby database abnormal state, return a write success message to the client in response to the target data being written in the master database.

[0018] In an embodiment of the present disclosure, the write module is configured to write the target data indicated by the data write request in a leader replica of the first database, and generate a data write log; and send the data write log to other replicas of the first database and the second database respectively, so that the other replicas of the first database and the second database replay the data write log respectively to write the target data.

[0019] In an embodiment of the present disclosure, the apparatus further comprises a first determination module configured to: in response to receiving write confirmation messages returned by no less than a first preset number of replicas of the other replicas of the first database within a preset time length, determine that a write operation of writing the target data in the first database is successful; and in response to not receiving write confirmation messages returned by no less than the first preset number of replicas of the other replicas of the first database within a preset time length, determine that the write operation of writing the target data in the first database fails.

[0020] In one embodiment of the present disclosure, when the writing module writes the target data to the second database, the writing module is configured to: write the target data to multiple copies of the second database respectively; in response to receiving write acknowledgement messages returned by no less than a second preset number of copies of the multiple copies of the second database within a first preset time length, determine that the writing operation of writing the target data to the second database is successful; and in response to not receiving write acknowledgement messages returned by no less than the second preset number of copies of the multiple copies of the second database within the first preset time length, determine that the writing operation of writing the target data to the second database fails.

[0021] In one embodiment of the present disclosure, the apparatus further comprises a renewal module configured to: in response to the first database being in a normal state and a renewal condition being met between a current time and a master database lease, send a first master database election request to the arbitration node and the second database respectively; and in response to receiving acknowledgement information returned by the arbitration node and / or the second database in response to the first master database election request, extend the master database lease by a second preset time length.

[0022] In one embodiment of the present disclosure, the apparatus further comprises a master-slave switching module configured to: in response to the first database being in an abnormal state and a renewal condition being met between a current time and a master database lease, not send a first master database election request to the arbitration node and the second database, so that the second database, in response to a renewal condition being met between a current time and the master database lease and not receiving the first master database election request sent by the first database, sends a second master database election request to the arbitration node and the first database respectively, and in response to receiving acknowledgement information returned by the arbitration node and / or the first database in response to the second master database election request, switches the second database to a master database.

[0023] In one embodiment of the present disclosure, the apparatus further comprises an exception processing module configured to: in response to the first database being in an abnormal state and receiving a data writing request sent by a client, return a write failure message to the client.

[0024] In one embodiment of the present disclosure, the apparatus further comprises an exception identification module configured to: in response to a writing operation of writing the target data in the first database failing, determine that the first database is in an abnormal state.

[0025] In one embodiment of the present disclosure, the device further comprises an exception notification module configured to: periodically send a master lease to a user partition in response to the first database being in a normal state, and determine that the first database is in an exception state in response to not receiving the master lease periodically sent by the user partition; and the user partition periodically sends a master lease to the system partition in response to the first database being in a normal state, and determines that the first database is in an exception state in response to not receiving the master lease periodically sent by the system partition.

[0026] According to a fourth aspect of one or more embodiments of the present disclosure, a high-availability data management device is provided, which is applied to a second database in a data system, the data system further comprising an arbitration node and a first database, the first database serving as a master, and the second database serving as a backup, the device comprising: a return module configured to return a write confirmation message to the first database in response to a write operation of writing target data to the second database by the first database being successfully executed, so that the first database: returns a write success message to a client in response to the target database being successfully written in the first database and the second database, respectively; performs transaction rollback on the data write request and sends a backup degradation request to the arbitration node and the second database, respectively, in response to the write operation of writing the target data to the second database failing to be executed; and switches the data system from a backup normal state to a backup exception state in response to receiving determination information returned by the arbitration node and / or the second database for the backup degradation request; wherein the target data is indicated by a data write request sent by the client to the first database to be written in the first database and the second database, respectively; and the master is configured to return a write success message to the client in response to the target data being successfully written in the master and the backup, respectively, when the data system is in the backup normal state, and return a write success message to the client in response to the target data being successfully written in the master when the data system is in the backup exception state.

[0027] In one embodiment of the present disclosure, the device further comprises a master-backup switching module configured to: send a second master election request to the arbitration node and the first database, respectively, in response to a renewal condition being met between a current time and a master lease, and not receiving a first master election request sent by the first database, and switch the second database to a master in response to receiving confirmation information returned by the arbitration node and / or the first database for the second master election request.

[0028] According to a fifth aspect of one or more embodiments of the present disclosure, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first or second aspect.

[0029] According to a sixth aspect of one or more embodiments of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor executes the executable instructions to implement the method as described in the first or second aspect.

[0030] According to a seventh aspect of one or more embodiments of the present disclosure, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first or second aspect.

[0031] The technical solutions provided by the embodiments of this disclosure can include the following beneficial effects: The high-availability data management method provided by the embodiments of this disclosure is applied to the first database in a data system including a first database currently serving as the primary database, a second database currently serving as the backup database, and an arbitration node. First, in response to receiving a data write request sent by a client, the target data indicated by the data write request is written into the first database, and the target data is also written into the second database. Then, in response to the failure of the write operation to write the target data into the second database, the data write request is rolled back, and a backup database degradation request is sent to the arbitration node and the second database respectively. Finally, in response to receiving confirmation information returned by the arbitration node and / or the second database in response to the backup database degradation request, the data system is switched from a backup database normal state to a backup database abnormal state.

[0032] In other words, this method is applied to the primary database of a data system. When the primary database receives a data write request from a client, it writes the target data indicated by the data write request into the primary database and also writes the target data into the backup database. If the target data is successfully written into both the primary and backup databases, a write success message is returned to the client, indicating that the data write request has been successfully processed. If the target data is not successfully written into the backup database, a backup database degradation request can be initiated within the data system. After receiving confirmation from any member within the data system, the backup database is downgraded. This allows the primary database to return a write success message to the client only if the target data is successfully written into the primary database when processing subsequent data write requests. This method targets data systems with only two data replicas: a primary database and a standby database. It offers high efficiency during data writing and ensures data security when the standby database is functioning correctly. A write success message is only returned after data has been successfully written to both the primary and standby databases. Even when the standby database malfunctions, it guarantees normal data writing; data writing will not fail to return a write success message or cause system crashes due to the standby database's inability to write. Furthermore, if the standby database malfunction is not yet detected (i.e., when the standby database cannot be written to but the data system is still in a normal standby database state, such as in the scenario where this method is applied), this method can roll back transactions for data that was successfully written to the primary database. This prevents data from being ignored due to discrepancies between the actual data writing situation and the state's data writing requirements, thus avoiding data loss during standby database recovery or even when switching to the primary database. Attached Figure Description

[0033] Figure 1 is a structural diagram of a data system provided in an exemplary embodiment.

[0034] Figure 2 is a structural diagram of a first database provided in an exemplary embodiment.

[0035] Figure 3 is a structural diagram of a second database provided in an exemplary embodiment.

[0036] Figure 4 is a flowchart of a highly available data management method applied to a first database, provided by an exemplary embodiment.

[0037] Figure 5 is a structural diagram of a data system provided in an exemplary embodiment.

[0038] Figure 6 is a scenario diagram of normal data writing provided by an exemplary embodiment.

[0039] Figure 7 is a scenario diagram of a backup database exception provided by an exemplary embodiment.

[0040] Figure 8 is a scenario diagram of a master library exception provided by an exemplary embodiment.

[0041] Figure 9 is a flowchart of a highly available data management method applied to a second database, provided by an exemplary embodiment.

[0042] Figure 10 is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0043] Figure 11 is a block diagram of a high-availability data management device applied to a first database, provided in an exemplary embodiment.

[0044] Figure 12 is a block diagram of a high-availability data management device applied to a second database, provided in an exemplary embodiment. Detailed Implementation

[0045] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this disclosure as detailed in the appended claims.

[0046] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this disclosure in other embodiments. In some other embodiments, the methods may include more or fewer steps than those described in this disclosure. Furthermore, a single step described in this disclosure may be broken down into multiple steps in other embodiments; and multiple steps described in this disclosure may be combined into a single step in other embodiments.

[0047] In today's era of rapid development in the internet and information technology, data generation is exploding, thus placing increasingly higher demands on databases and their management. Current distributed databases often address temporary failures by setting up primary and standby databases. This means that if the primary database fails, the standby database can take over as the primary and continue providing services, thereby avoiding service interruptions and ensuring service quality and efficiency.

[0048] Generally, a distributed database consists of a primary database providing write services and a standby database for data backup. In related technologies, a distributed database may crash due to the inability to write data when the standby database fails, thus preventing it from providing services. For example, a distributed database can operate in maximum performance mode, ensuring efficient data writing but compromising data security. This means that after data is written to the primary database, a response message is returned to the client, and the written data is asynchronously synchronized to the standby database. The primary database's data writing efficiency (i.e., the efficiency of returning a response message to the client) is not affected by the latency of data synchronization to the standby database. However, since the primary database cannot guarantee that the data will be successfully synchronized to the standby database when it returns a response message to the client, data in the standby database may be missing compared to the primary database, leading to data loss during primary-standby database failover. As another example, a distributed database can operate in maximum protection mode, ensuring data security but reducing data writing efficiency. This means that data is only returned to the client after successful writing to the primary database and successful synchronization to the standby database. Especially when the standby database fails, the primary database may never return a response message to the client, thus preventing it from providing services due to the inability to write data.

[0049] Based on this, at least one embodiment of this disclosure provides a highly available data management method. This method can automatically and dynamically adjust the state of the data system so that when the standby database is in a normal state, the data system returns a response message to the client when the data is successfully written to both the primary and standby databases. When the standby database is in an abnormal state, the system returns a response message to the client as soon as the data is successfully written to the primary database. This method can balance the data security and processing efficiency of the data system in handling data write requests. That is, when the standby database is abnormal, it ensures that the data is successfully written to both the primary and standby databases. When the standby database is abnormal, it avoids failing to return a response message because the standby database cannot be successfully written.

[0050] This method is applied to the distributed data system shown in Figure 1. The data system includes a first database A, a second database B, and an arbitration node C. Databases A, B, and C each run a distributed consensus protocol, such as Paxos. They form a distributed consensus protocol member group, with each database acting as a member. The roles of primary database, backup database, and arbitrator are defined by the three members of this member group. Arbitrator C always assumes the role of arbitrator, while the primary database role can only be held by one member at a time. For example, in Figure 1, database A acts as the primary database, database B as the backup database, and together with arbitrator C, they form a Paxos member group {[A, primary database], [B, backup database], [C, arbitrator]}.

[0051] The first database can be in the form of a database cluster, containing multiple partitions, each containing multiple replicas, namely a leader replica and regular replicas. For example, the first database A shown in Figure 2 has only one partition, and this partition includes three replicas: R1, R2, and R3. The leader replica is replica R1. Therefore, the membership information of the internal partition of the first database can be [A, primary database, (R1, R2, R3)]. Similarly, the second database can be in the form of a database cluster, containing multiple partitions, each containing multiple replicas, namely a leader replica and regular replicas. For example, the second database B shown in Figure 3 has only one partition, and this partition includes three replicas: R1, R2, and R3. The leader replica is replica R4. Therefore, the membership information of the internal partition of the first database can be [B, standby database, (R4, R5, R6)]. This disclosure does not intend to restrict the election method of the leader replica for each partition in each database.

[0052] This method can be implemented by a first database serving as the primary database and a second database serving as the backup database within the data system. The following sections will describe the method in detail from both the first and second database perspectives.

[0053] Please refer to Figure 4, which exemplarily illustrates the flow of a high-availability data management method applied to a first database, including steps S401 to S403.

[0054] In step S401, in response to receiving a data write request sent by the client, the target data indicated by the data write request is written into the first database, and the target data is written into the second database.

[0055] The data system has a normal standby database state and a standby database abnormal state. The primary database, when the data system is in a normal standby database state, returns a write success message to the client in response to the successful writing of the target data to both the primary and standby databases. Conversely, when the data system is in a standby database abnormal state, it returns a write success message to the client in response to the successful writing of the target data to the primary database. In other words, the primary database needs to write data to both the primary and standby databases when the standby database is in a normal state, and only needs to write data to the primary database when the standby database is in an abnormal state. It should be understood that the state of the database system and the actual state of the standby database are not necessarily the same in real time. This method is precisely designed to correct the state of the database system when they differ, and to compensate for and protect against potential data loss caused by these discrepancies.

[0056] The data write request instructs the data system to write target data. This data write request is received and processed by the first database, which acts as the primary database. Since the current state of the database system is that the backup database is in a normal state, the first database, acting as the primary database, writes the target data to both the first and second databases.

[0057] It should be understood that if the data system has system partitions and user partitions, the data write request needs to be assigned to the corresponding partition to perform the write operation in this step. Preferably, if the write operation is performed by the user partition, the result of the write operation can be synchronized to the system partition, especially when the write operation to write target data to the second database fails.

[0058] For example, in this step, target data can be written into the first database and then into the second database in the following manner.

[0059] First, the target data indicated by the data write request is written into the leader replica of the first database, and a data write log is generated.

[0060] Next, the data write logs are sent to other replicas of the first database and the second database, respectively, so that the other replicas of the first database and the second database replay the data write logs to write the target data. For example, the leader replica of the first database sends the data write logs to the other replicas of the first database and the second database, respectively.

[0061] It should be understood that after receiving the data write log sent by the leader replica, the other replicas of the first database will write the target data into their replicas by replaying the data write log, and return a write confirmation message to the leader replica after successful writing. Based on this, the leader replica can determine that the write operation of writing the target data into the first database was successfully executed if it receives a write confirmation message from at least a first preset number of other replicas of the first database within a preset time period; and determine that the write operation of writing the target data into the first database failed if it does not receive a write confirmation message from at least a first preset number of other replicas of the first database within a preset time period.

[0062] In other words, the first database is considered to have successfully written the target data only when all the leader replicas and at least a first preset number of ordinary replicas within the first database have successfully written the target data. That is, the first database has m replicas, and the target data is considered to have been successfully written to the first database only when the target data is successfully written to Q(m) replicas (Q(m) is the first preset number + 1). For example, as shown in Figure 2, the first database A has m replicas and Q(m) is 2, so its internal member group information can be [A, master database, (R1, R2, R3), 3, 2].

[0063] In this example, after the leader replica of the first database completes the writing of the target data and generates a data write log, it simultaneously synchronizes the data write log to other replicas of the first database and the second database. Compared with the related technology in which the leader replica synchronizes the target data to other replicas of the first database through the data write log and then synchronizes it to the second database, this example can improve the efficiency of synchronizing the target data to the second database and reduce the latency of data synchronization between the primary and standby databases.

[0064] For example, in this step, the target data can be written to the second database in the following manner.

[0065] First, the target data is written to multiple copies of the second database.

[0066] For example, following the method described in the example above, the target data is written to multiple replicas of the second database respectively. That is, the leader replica of the first database sends the data write log to each replica of the second database, so that each replica of the second database replays the data write log to write the target data within its replica. In other words, the specific process of writing the target data in the first database and writing the target log to the second database in this step is shown in Figure 5, namely: First, the target data indicated by the data write request is written to the leader replica of the first database, and a data write log is generated; Second, the data write log is sent to the other replicas of the first database and each replica of the second database respectively, so that the other replicas of the first database and each replica of the second database replay the data write log to write the target data.

[0067] For example, after the first database writes the target data to the leader replica and other replicas (e.g., a first preset number of replicas), it simultaneously writes the target data to each replica of the second database, for example, by writing the target data to each replica by sending logs.

[0068] It should be understood that after successfully writing the target data, the replica of the second database will return a write confirmation message to the first database (e.g., the leader replica of the first database).

[0069] Next, in response to receiving a write confirmation message from at least a second preset number of replicas of the second database within a first preset time period, it is determined that the write operation to write the target data to the second database was successfully executed; in response to not receiving a write confirmation message from at least a second preset number of replicas of the second database within a first preset time period, it is determined that the write operation to write the target data to the second database failed.

[0070] In other words, the target data is considered successfully written to the second database only when all replicas of the second database, not less than the second preset number, have successfully written the target data. That is, the second database has n replicas, and the target data is considered successfully written to the second database only when Q(n) replicas have successfully written the target data. For example, as shown in Figure 3, the second database B has 3 replicas and Q(n) is 2. Then its internal member group information can be [B, backup database, (R4, R5, R6), 3, 2].

[0071] In this example, the target data is only confirmed to have been successfully written to the second database when the first database successfully writes the target data to multiple copies of the second database. This increases the security and reliability of the target data, resulting in more data backups and preventing data from becoming unrecoverable due to backup loss.

[0072] As can be seen from the above content in this step, in Figure 1, the Paxos member group {[A, primary database, (list of primary database replicas), m, Q(m)], [B, standby database, (list of standby database replicas), n, Q(n)], [C, arbitrator]} is composed of the first database A, the second database B, and the arbitrator node C; for example, the data system shown in Figure 5 forms the Paxos member group {[A, primary database, (R1, R2, R3), 3, 2], [B, standby database, (R4, R5, R6), 3, 2], [C, arbitrator]}.

[0073] In step S402, in response to the failure of the write operation to write the target data to the second database, the data write request is rolled back, and a backup database degradation request is sent to the arbitration node and the second database respectively.

[0074] Transaction rollback of the data write request refers to restoring the completed response actions of the data write request, such as deleting the target data written to the first database. It can also return a write failure message to the client. Transaction rollback ensures data consistency between the primary and standby databases, preventing discrepancies between the actual data write status and the required write state, thus avoiding the neglect of unsuccessfully written data in the standby database and preventing data loss during standby recovery or even when switching to the primary database.

[0075] For example, taking the data system shown in Figure 5 as an example, the standby database downgrade request can be to change the Paxos member group {[A, primary database, (R1,R2,R3), 3, 2], [B, standby database, (R4,R5,R6), 3, 2], [C, arbitrator]} to {[A, primary database, (R1,R2,R3), 3, 2], [B, standby database, (R4,R5,R6), 3, 0], [C, arbitrator]}.

[0076] Upon receiving a backup database degradation request, the arbitration node and the second database (the leader replica) will return a confirmation message to the first database regarding the backup database degradation request. It should be understood that if the second database fails to successfully write the target data, it may not receive the backup database degradation request and will not return any confirmation message regarding the backup database degradation request.

[0077] Preferably, if the system partition of the data system performs the write operation in step S401, and the write operation to write the target data to the second database fails, the system partition can initiate a backup database degradation in the distributed consensus protocol member group, that is, send a backup database degradation request to the arbitration node and the second database respectively; if the user partition of the data system performs the write operation in step S401, and the write operation to write the target data to the second database fails, the result can be synchronized to the system partition, so that the system partition can initiate a backup database degradation in the distributed consensus protocol member group, that is, send a backup database degradation request to the arbitration node and the second database respectively.

[0078] It should be understood that the first database may return a write success message to the client in response to the successful execution of both the write operation to the first database and the write operation to the second database, indicating that the data write request has been successfully processed.

[0079] In step S403, in response to receiving confirmation information returned by the arbitration node and / or the second database in response to the backup database downgrade request, the data system is switched from the backup database normal state to the backup database abnormal state.

[0080] Since the primary database is used to return a write success message to the client in response to the successful writing of the target data to both the primary and the secondary databases when the data system is in a normal state (secondary database), and to return a write success message to the client in response to the successful writing of the target data to the primary database when the data system is in an abnormal state (secondary database), then when the first database receives a new data write request, or a data write request for transaction rollback in step S402, it can return a write success message to the client only in response to the successful execution of the write operation of writing the target data to the first database.

[0081] It should be understood that since the moment the data system switches from a normal standby state to an abnormal standby state is recorded, data that was not backed up to the standby ...

[0082] After the backup database recovers to normal, the first database can send a backup database upgrade request to the arbitration node and the second database respectively, and in response to receiving a confirmation message for the backup database upgrade request from the arbitration node and / or the second database, switch the status of the data system from the backup database abnormal state to the backup database normal state.

[0083] For example, taking the data system shown in Figure 5 as an example, the standby database upgrade request can be to change the Paxos member group {[A, primary database, (R1,R2,R3), 3, 2], [B, standby database, (R4,R5,R6), 3, 0], [C, arbitrator]} to {[A, primary database, (R1,R2,R3), 3, 2], [B, standby database, (R4,R5,R6), 3, 2], [C, arbitrator]}.

[0084] Next, we will explain the effectiveness of the high-availability data management method provided in this embodiment in detail, using a specific scenario and the data system shown in Figure 5. In the data system shown in Figure 5, the Paxos member groups under normal standby database status are {[A, primary database, (R1, R2, R3), 3, 2], [B, standby database, (R4, R5, R6), 3, 2], [C, arbitrator]}.

[0085] Please refer to the scenarios shown in Figure 6 and Figure 7. If a single data write can guarantee that at least two of replicas R1, R2, and R3, and at least two of replicas R4, R5, and R6, then both the primary and backup databases are functioning normally.

[0086] Referring to the scenario shown in Figure 7, if two replicas of the standby database fail, a single data write operation cannot meet the requirement of writing to at least two replicas of the standby database, and the data system cannot write data. In this situation, the primary database and the arbitrator node, as the majority party in the membership group change, remain alive. The leader replica of the primary database system partition detects that the standby database cannot write data to two replicas within the set time. It can change the data system's Paxos membership group {[A, Primary, (R1, R2, R3), 3, 2], [B, Standby, (R4, R5, R6), 3, 2], [C, Arbitrator]} to {[A, Primary, (R1, R2, R3), 3, 2], [B, Standby, (R4, R5, R6), 3, 2], [C, Arbitrator]}. At this point, data writing is successful as long as any two replicas of the primary database are successfully written, and the system restores its normal data writing capability. After the standby replicas R5 and R6 are repaired, the leader replica of the primary database system partition can use the primary database and the arbitrator node as the majority to change the Paxos member group of the data system from {[A, primary database, (R1, R2, R3), 3, 2], [B, standby database, (R4, R5, R6), 3, 2], [C, arbitrator]} to {[A, primary database, (R1, R2, R3), 3, 2], [B, standby database, (R4, R5, R6), 3, 2], [C, arbitrator]}. After this, data writing requires successful writing to both primary and standby replicas simultaneously for the process to be considered successful, and the system's data protection capabilities are restored to normal.

[0087] The high-availability data management method provided in this embodiment is applied to the first database in a data system including a first database currently acting as the primary database, a second database currently acting as the backup database, and an arbitration node. First, in response to receiving a data write request from a client, the method writes the target data indicated by the data write request into the first database and then writes the target data into the second database. Next, in response to the failure of the write operation to the second database, the method rolls back the data write request and sends a backup database degradation request to both the arbitration node and the second database. Finally, in response to receiving confirmation information from the arbitration node and / or the second database regarding the backup database degradation request, the method switches the data system from a backup database normal state to a backup database abnormal state.

[0088] In other words, this method is applied to the primary database of a data system. When the primary database receives a data write request from a client, it writes the target data indicated by the data write request into the primary database and also writes the target data into the backup database. If the target data is successfully written into both the primary and backup databases, a write success message is returned to the client, indicating that the data write request has been successfully processed. If the target data is not successfully written into the backup database, a backup database degradation request can be initiated within the data system. After receiving confirmation from any member within the data system, the backup database is downgraded. This allows the primary database to return a write success message to the client only if the target data is successfully written into the primary database when processing subsequent data write requests. This method targets data systems with only two data replicas: a primary database and a standby database. It offers high efficiency during data writing and ensures data security when the standby database is functioning correctly. A write success message is only returned after data has been successfully written to both the primary and standby databases. Even when the standby database malfunctions, it guarantees normal data writing; data writing will not fail to return a write success message or cause system crashes due to the standby database's inability to write. Furthermore, if the standby database malfunction is not yet detected (i.e., when the standby database cannot be written to but the data system is still in a normal standby database state, such as in the scenario where this method is applied), this method can roll back transactions for data that was successfully written to the primary database. This prevents data from being ignored due to discrepancies between the actual data writing situation and the state's data writing requirements, thus avoiding data loss during standby database recovery or even when switching to the primary database.

[0089] In this disclosure, the primary database in the distributed consensus protocol member group formed by the data system has a unique role and a primary database lease. Once the primary database lease expires, the primary database's role becomes invalid. Therefore, a reasonable renewal mechanism and a corresponding primary / standby database switching mechanism can be set to identify whether the database acting as the primary database is functioning normally, thereby ensuring that any anomalies in the primary database can be detected in a timely manner, thus guaranteeing that the primary database can provide services to the outside world. Preferably, once a database becomes the primary database, it can continue to serve as the primary database through the renewal mechanism if no anomalies occur. If an anomaly occurs, it can be dethroned as the primary database through the primary / standby database switching mechanism, and the original standby database will take over as the primary database.

[0090] In some embodiments of this disclosure, the renewal mechanism proceeds as follows: First, in response to the first database being in a normal state and the current time meeting the renewal conditions with the master database lease, a first master database election request is sent to the arbitration node and the second database respectively; Next, in response to receiving confirmation information returned by the arbitration node and / or the second database in response to the first master database election request, the master database lease is extended for a second preset duration.

[0091] The primary / standby database switching mechanism is as follows: In response to the first database being in an abnormal state and the current lease with the primary database meeting the renewal conditions, the first primary database election request is not sent to the arbitration node and the second database. Instead, the second database, in response to the current lease with the primary database meeting the renewal conditions and not receiving the first primary database election request from the first database, sends a second primary database election request to both the arbitration node and the first database. Upon receiving confirmation information from the arbitration node and / or the first database regarding the second primary database election request, the second database is switched to become the primary database.

[0092] Preferably, the primary / standby database switching mechanism may further include: responding to the first database being in an abnormal state and receiving a data write request from the client, returning a write failure message to the client. That is, when the first database is abnormal, the primary database is promptly deactivated, and the client's data write request is no longer processed.

[0093] It should be understood that the renewal mechanism and primary / standby database switching mechanism described above in this embodiment can be executed by the system partition of the first database, and the user partition can be notified to automatically renew its contract after renewal (i.e., continue to assume the role of primary database within the partition); or, the renewal mechanism and primary / standby database switching mechanism described above in this embodiment can be executed separately by each partition of the first database (i.e., the system partition and the user partition) within the partition.

[0094] For example, taking the data system shown in Figure 5 as an example, the second master database election request can be to change the Paxos member group {[A, master database, (R1,R2,R3), 3, 2], [B, standby database, (R4,R5,R6), 3, 2], [C, arbitrator]} to {[A, standby database, (R1,R2,R3), 3, 2], [B, master database, (R4,R5,R6), 3, 2], [C, arbitrator]}.

[0095] Among them, the current time and the master warehouse lease meeting the renewal conditions can be a specific time interval between the current time and the expiration time of the master warehouse lease, that is, the master warehouse lease is about to expire.

[0096] If the first database is not determined to be in an abnormal state, then it can be determined to be in a normal state. For example, whether the first database is in an abnormal state can be determined according to any of the following optional examples: Optional Example 1

[0097] In response to the failure of a write operation to write the target data into the first database, it is determined that the first database is in an abnormal state.

[0098] In this example, if a partition (e.g., a system partition or a user partition) fails to execute a write operation to write target data into the first database, then that partition determines that the first database is in an abnormal state. Optional Example 2

[0099] The system partition periodically sends a master database lease to the user partition when the first database is in a normal state, and determines that the first database is in an abnormal state when it does not receive the master database lease periodically sent by the user partition; the user partition periodically sends a master database lease to the system partition when the first database is in a normal state, and determines that the first database is in an abnormal state when it does not receive the master database lease periodically sent by the system partition.

[0100] In this example, the system partition and the user partition periodically send master database leases to each other to notify each other that they are functioning normally. Only after both the system partition and the user partition are functioning normally and confirming the other's normal status through these notifications can they confirm that the primary database is in a normal state. This periodic mutual notification allows the system partition and the user partition to be promptly informed of any anomalies in the other. For example, if the system partition fails to elect a leader replica and is in an abnormal state, it cannot send a master database lease to the user partition. Therefore, the user partition can promptly learn of the system partition's abnormality and confirm that the first database is in an abnormal state. Alternatively, if the system partition determines that the first database is in an abnormal state due to a write operation failing to write target data (as shown in Example 1), it will not send a master database lease to the user partition. Thus, the user partition can promptly learn of the system partition's abnormality and confirm that the first database is in an abnormal state. (This is repeated three times in the original text.)

[0101] Based on this, if the renewal mechanism and the primary / standby database switching mechanism described above in this embodiment are executed by the system partition of the first database, then this example can promptly determine that the first database is in an abnormal state when the system partition itself or the user partition is abnormal, thereby allowing the primary database to be removed and the primary / standby database switching mechanism to complete the primary / standby database switching; if the renewal mechanism and the primary / standby database switching mechanism described above in this embodiment are executed by each partition (i.e., the system partition and the user partition) of the first database respectively within the partition, then this example can enable the system partition or the user partition to promptly know the abnormality of the other and determine that the first database is in an abnormal state, thereby allowing the primary database to be removed and each partition to complete the primary / standby database switching by executing the primary / standby database switching mechanism.

[0102] Next, we will explain the effect of the primary / standby database switching mechanism provided in this embodiment in detail, using a specific scenario and the data system shown in Figure 5. In the data system shown in Figure 5, the Paxos member groups under the normal standby database state are {[A, Primary database, (R1, R2, R3), 3, 2], [B, Standby database, (R4, R5, R6), 3, 2], [C, Arbitration]}.

[0103] Please refer to the scenario shown in Figure 6. If a single data write can guarantee that at least two of replicas R1, R2, and R3, and at least two of replicas R4, R5, and R6, then both the primary and backup databases are functioning normally.

[0104] Referring to the scenario shown in Figure 8, if a partition of primary database A has more than two abnormal replicas, a single data write cannot satisfy the requirement of two replicas, and the data system cannot write data. If the abnormality occurs in the system partition of the primary database, the leader replicas of other partitions in primary database A will vacate their primary status and become standby databases because they have not received the periodic primary database leases from the leader replicas of the system partitions. If the abnormality occurs in the user partitions of the primary database, the leader replicas of the system partitions will vacate their primary status and become standby databases because they have not received the periodic primary database leases from the leader replicas of the user partitions. Ultimately, an abnormality in one partition will cause all partitions to become standby databases. As the majority party in the membership group change, standby database B and arbitrator node C can change the Paxos membership group of the data system from {[A, primary database, (R1, R2, R3), 3, 2], [B, standby database, (R4, R5, R6), 3, 2], [C, arbitrator]} to {[A, standby database, (R1, R2, R3), 3, 2], [B, primary database, (R4, R5, R6), 3, 2], [C, arbitrator]}, thus completing the primary / standby database switchover. Subsequently, the Leader replica of the new primary database B's system partition discovers that standby database A cannot be set... Writing data to two replicas within a set time interval can further change the Paxos member group of the data system from {[A, primary database, (R1, R2, R3), 3, 2], [B, standby database, (R4, R5, R6), 3, 2], [C, arbitrator]} to {[A, standby database, (R1, R2, R3), 3, 0], [B, primary database, (R4, R5, R6), 3, 2], [C, arbitrator]}. In this case, data writing is successful as long as any two replicas of primary database B are successfully written, and the system restores its normal data writing capability. After the standby replicas R1 and R2 of database A are repaired, the leader replica of the system partition of the primary database B can use the primary database and the arbitrator node as the majority to change the Paxos member group of the data system from {[A, standby, (R1, R2, R3), 3, 0], [B, primary database, (R4, R5, R6), 3, 2], [C, arbitrator]} to {[A, standby, (R1, R2, R3), 3, 2], [B, primary database, (R4, R5, R6), 3, 2], [C, arbitrator]}. After this, data writing requires successful writing to both replicas of the primary database and both replicas of the standby database simultaneously for the write to be considered successful, and the system's data protection capability is restored to normal.

[0105] In the above scenario, the anomaly of primary database A may be caused by network isolation between primary database A, primary database B, and arbitration node C. If primary database A receives a data write request from a client after network isolation but before it has been deactivated, the network isolation prevents it from successfully writing data to both primary database A and standby database B simultaneously, causing the data write request to time out or fail. If primary database A has been deactivated after network isolation but receives a data write request from a client, it will reject the request. Subsequently, primary database A is switched to standby database, and standby database B is switched to primary database. At this point, the data in databases A and B is completely consistent, and no data loss occurs during the switchover, achieving data integrity.

[0106] In this embodiment, each time the primary database's lease is about to expire, if it is in a normal state, it sends a first primary database election request to both the arbitration node and the backup database, claiming that it should continue to serve as the primary database. Upon receiving the first primary database election request, the arbitration node and the backup database will return confirmation information to the primary database to renew its lease. However, if the primary database is in an abnormal state, such as a write operation to a partition failing or a partition failing to elect a leader replica, it will relinquish its primary database status and stop processing data write requests from clients. Furthermore, it will not send a first primary database election request to the arbitration node and the backup database when its lease is about to expire, so that the arbitration node and the backup database are aware of the primary database's abnormality. The backup database will then initiate a primary database election within the distributed consensus protocol member group according to the primary / backup switchover mechanism, sending a second primary database election request to both the arbitration node and the original primary database. Upon receiving confirmation information from the arbitration node and / or the original primary database regarding the second primary database election request, it will assume the primary database status. It should be understood that the standby database initiates the election of the primary database within the distributed consensus protocol member group, and the operation of assuming the primary database can be executed by the standby database's system partition and broadcast to other partitions after assuming the primary database. Furthermore, after the original standby database becomes the new primary database, the process shown in Figure 4 can be used to confirm whether the original primary database, which has been downgraded to a standby database, is in a normal state. Based on the confirmation result, the status of the database system can be determined as either a normal standby database state or an abnormal standby database state. That is, after the primary database fails and a primary-standby database switchover occurs, the new primary database can downgrade the abnormal original primary database to avoid the database system being unable to provide normal services. Taking the data system shown in Figure 5 as an example, the Paxos member group {[A, standby database, (R1,R2,R3), 3, 2], [B, primary database, (R4,R5,R6), 3, 2], [C, arbitrator]} can be further changed to {[A, standby database, (R1,R2,R3), 3, 0], [B, primary database, (R4,R5,R6), 3, 2], [C, arbitrator]}.

[0107] As can be seen from the above embodiments, in the event of an anomaly in either the primary or backup database of the data system disclosed herein, the system can automatically perform degradation processing, ensuring data integrity and continued read / write services. Specifically, in the event of a primary database failure, the system can automatically upgrade the backup database to the primary database, ensuring data integrity and continued read / write services. If the primary database, backup database, and arbitration node are deployed in three data centers, this disclosure can guarantee that the system can continue to provide read / write services without data integrity even if any single data center fails. In other words, this disclosure applies arbitration nodes based on a distributed consensus protocol to the primary-backup database disaster recovery scenario of a distributed database, enabling automatic overall primary-backup failover of the backup database in the event of a primary database failure, ensuring data integrity across all partitions, guaranteeing zero data loss and uninterrupted service in the event of a single primary or backup database failure.

[0108] Please refer to Figure 9, which exemplarily illustrates the flow of a high-availability data management method applied to a second database, including step S901.

[0109] In step S901, in response to the successful execution of the write operation of the target data from the first database to the second database, a write confirmation message is returned to the first database, so that the first database: in response to the successful writing of the target data to both the first and second databases, returns a write success message to the client; in response to the failure of the write operation of the target data to the second database, performs a transaction rollback on the data write request and sends a backup database degradation request to both the arbitration node and the second database; in response to receiving confirmation information returned by the arbitration node and / or the second database in response to the backup database degradation request, switches the data system from a backup database normal state to a backup database abnormal state; wherein, the target data is indicated by the data write request sent by the client to the first database to be written to both the first and second databases; the primary database is used to return a write success message to the client in response to the successful writing of the target data to both the primary and backup databases when the data system is in a backup database normal state, and to return a write success message to the client in response to the successful writing of the target data to the primary database when the data system is in a backup database abnormal state.

[0110] In some embodiments of this disclosure, the method further includes: in response to the current time meeting the renewal conditions of the lease with the primary database and not receiving a first primary database election request from the first database, sending a second primary database election request to the arbitration node and the first database respectively, and switching the second database to the primary database in response to receiving confirmation information returned by the arbitration node and / or the first database in response to the second primary database election request.

[0111] The details of the high-availability data management method applied to the second database side have been described in detail in the various embodiments of the high-availability data management method applied to the first database side, and will not be repeated here.

[0112] Figure 10 is a schematic structural diagram of a device provided in an exemplary embodiment. Referring to Figure 10, at the hardware level, the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010, and may also include other hardware required for tasks. One or more embodiments of this disclosure can be implemented in software, for example, the processor 1002 reads the corresponding computer program from the non-volatile memory 1010 into the memory 1008 and then runs it. Of course, in addition to software implementation, one or more embodiments of this disclosure do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0113] Please refer to Figure 11. The high-availability data management device can be applied to the device shown in Figure 10 to realize the technical solution of this disclosure. The device can serve as the primary database in a data system, which also includes an arbitration node and a second database, with the second database serving as a backup database. The high-availability data management device can include: a write module 1101, configured to, in response to receiving a data write request from a client, write the target data indicated by the data write request into the first database and write the target data into the second database; a send module 1102, configured to, in response to a failure in writing the target data to the second database, roll back the data write request and send a backup database downgrade request to the arbitration node and the second database respectively; and a downgrade module 1103, configured to, in response to receiving confirmation information returned by the arbitration node and / or the second database regarding the backup database downgrade request, switch the data system from a backup database normal state to a backup database abnormal state; wherein, the primary database, when the data system is in a backup database normal state, returns a write success message to the client in response to the successful writing of the target data to both the primary and backup databases, and when the data system is in a backup database abnormal state, returns a write success message to the client in response to the successful writing of the target data to the primary database.

[0114] In one embodiment of this disclosure, the writing module is configured to: write the target data indicated by the data write request into the leader replica of the first database and generate a data write log; and send the data write log to other replicas of the first database and the second database respectively, so that the other replicas of the first database and the second database respectively replay the data write log to write the target data.

[0115] In one embodiment of this disclosure, the apparatus further includes a first determining module, configured to: determine that a write operation to write the target data in the first database was successfully executed in response to receiving a write confirmation message returned by at least a first preset number of other copies of the first database within a preset time period; and determine that a write operation to write the target data in the first database failed in response to not receiving a write confirmation message returned by at least a first preset number of other copies of the first database within a preset time period.

[0116] In one embodiment of this disclosure, when the writing module is used to write the target data to the second database, it is configured to: write the target data to multiple replicas of the second database respectively; in response to receiving a write confirmation message returned by a replica of the second database of not less than a second preset number within a first preset time period, determine that the write operation of writing the target data to the second database has been successfully executed; in response to not receiving a write confirmation message returned by a replica of the second database of not less than a second preset number within the first preset time period, determine that the write operation of writing the target data to the second database has failed.

[0117] In one embodiment of this disclosure, the apparatus further includes a renewal module, configured to: in response to the first database being in a normal state and the current time satisfying the renewal conditions for the master database lease, send a first master database election request to the arbitration node and the second database respectively; and in response to receiving confirmation information returned by the arbitration node and / or the second database in response to the first master database election request, extend the master database lease for a second preset duration.

[0118] In one embodiment of this disclosure, the apparatus further includes a primary / backup switching module, configured to: in response to the first database being in an abnormal state and the current lease with the primary database meeting the renewal conditions, not send a first primary database election request to the arbitration node and the second database, so that the second database, in response to the current lease with the primary database meeting the renewal conditions and not receiving the first primary database election request sent by the first database, respectively sends a second primary database election request to the arbitration node and the first database, and in response to receiving confirmation information returned by the arbitration node and / or the first database for the second primary database election request, switch the second database to the primary database.

[0119] In one embodiment of this disclosure, the apparatus further includes an exception handling module, configured to: in response to the first database being in an abnormal state and receiving a data write request sent by the client, return a message indicating that writing is not possible to the client.

[0120] In one embodiment of this disclosure, the apparatus further includes an anomaly identification module, configured to: determine that the first database is in an abnormal state in response to a failure of a write operation to write the target data into the first database.

[0121] In one embodiment of this disclosure, the apparatus further includes an anomaly notification module, configured to: periodically send a master database lease to a user partition in response to the first database being in a normal state, and determine that the first database is in an abnormal state in response to not receiving the master database lease periodically sent by the user partition; the user partition periodically sends a master database lease to the system partition in response to the first database being in a normal state, and determines that the first database is in an abnormal state in response to not receiving the master database lease periodically sent by the system partition.

[0122] Please refer to Figure 12. The high-availability data management device can be applied to the device shown in Figure 10 to implement the technical solution of this disclosure. The device can serve as a backup database in a data system, which also includes an arbitration node and a first database, with the first database serving as the primary database. The high-availability data management device may include: a return module 1201, used to return a write confirmation message to the first database in response to a successful write operation from the first database to the second database, so that the first database: returns a write success message to the client in response to successful writes to both the first and second databases; and rolls back the data write request in response to a failed write operation to the second database, and returns a message to both the arbitration node and the second database respectively. The database sends a backup database degradation request; in response to receiving confirmation information returned by the arbitration node and / or the second database regarding the backup database degradation request, the data system is switched from a backup database normal state to a backup database abnormal state; wherein, the target data is written to both the first database and the second database respectively by a data write request sent by the client to the first database; the primary database is used to return a write success message to the client when the data system is in a backup database normal state, in response to the target data being successfully written to both the primary database and the backup database, and to return a write success message to the client when the data system is in a backup database abnormal state, in response to the target data being successfully written to the primary database.

[0123] In one embodiment of this disclosure, the apparatus further includes a primary / standby switching module, configured to: in response to the current time satisfying the renewal conditions of the lease with the primary database and not receiving a first primary database election request from the first database, send a second primary database election request to the arbitration node and the first database respectively, and in response to receiving confirmation information returned by the arbitration node and / or the first database in response to the second primary database election request, switch the second database to the primary database.

[0124] One or more embodiments of this disclosure also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method provided in any of the above embodiments.

[0125] One or more embodiments of this disclosure also provide a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the method provided in any of the above embodiments.

[0126] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0127] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0128] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0129] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0130] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0131] The foregoing has described specific embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0132] The terminology used in one or more embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this disclosure. The singular forms “a,” “the,” and “the” used in one or more embodiments of this disclosure and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0133] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0134] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this disclosure, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this disclosure, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0135] The above description is merely a preferred embodiment of one or more embodiments of this disclosure and is not intended to limit the scope of one or more embodiments of this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this disclosure should be included within the scope of protection of one or more embodiments of this disclosure.

Claims

1. A high-availability data management method, applied to a first database in a data system, the data system further including an arbitration node and a second database, the first database serving as the primary database and the second database serving as the backup database, the method comprising: In response to receiving a data write request from a client, the target data indicated by the data write request is written into the first database, and the target data is also written into the second database; In response to the failure of the write operation to write the target data to the second database, the data write request is rolled back, and a backup database degradation request is sent to the arbitration node and the second database respectively. In response to receiving confirmation information returned by the arbitration node and / or the second database for the backup database degradation request, the data system is switched from the backup database normal state to the backup database abnormal state; The primary database is configured to return a write success message to the client in response to the successful writing of the target data to both the primary and the secondary databases when the data system is in a normal state (as the secondary database is in a normal state), and to return a write success message to the client in response to the successful writing of the target data to the primary database when the data system is in an abnormal state (as the secondary database is in an abnormal state).

2. The high-availability data management method according to claim 1, wherein writing the target data indicated by the data write request into the first database and writing the target data into the second database comprises: Write the target data indicated by the data write request into the leader replica of the first database, and generate a data write log; The data is written to a log and sent to other copies of the first database and the second database respectively, so that the other copies of the first database and the second database respectively replay the data write log to write the target data.

3. The high-availability data management method according to claim 2, further comprising: In response to receiving a write confirmation message from no less than a first preset number of other replicas of the first database within a preset time period, it is determined that the write operation of writing the target data into the first database was successfully executed; If no write confirmation message is received from any of the other replicas of the first database within a preset time period, it is determined that the write operation to write the target data into the first database has failed.

4. The high-availability data management method according to claim 1 or 2, wherein writing the target data to the second database comprises: The target data is written to multiple replicas of the second database respectively; In response to receiving a write confirmation message from a replica of the second database within a first preset time period of not less than a second preset number of replicas, it is determined that the write operation to write the target data to the second database was successfully executed. If no write confirmation message is received from at least a second preset number of replicas of the second database within a first preset time period, it is determined that the write operation to write the target data to the second database has failed.

5. The high-availability data management method according to claim 1, further comprising: In response to the first database being in a normal state and the current lease with the master database meeting the renewal conditions, a first master database election request is sent to the arbitration node and the second database respectively; In response to receiving confirmation information from the arbitration node and / or the second database regarding the first master database election request, the master database lease is extended for a second preset duration.

6. The high-availability data management method according to claim 1, further comprising: In response to the first database being in an abnormal state and the current lease with the primary database meeting the renewal conditions, the first primary database election request is not sent to the arbitration node and the second database. Instead, the second database, in response to the current lease with the primary database meeting the renewal conditions and not receiving the first primary database election request from the first database, sends a second primary database election request to both the arbitration node and the first database. Upon receiving confirmation information from the arbitration node and / or the first database regarding the second primary database election request, the second database is switched to become the primary database.

7. The high-availability data management method according to claim 1, further comprising: In response to the first database being in an abnormal state and receiving a data write request from the client, a write failure message is returned to the client.

8. The high-availability data management method according to claim 1, further comprising: In response to the failure of a write operation to write the target data into the first database, it is determined that the first database is in an abnormal state.

9. The high-availability data management method according to claim 5 or 8, further comprising: The system partition periodically sends a master database lease to the user partition when the first database is in a normal state, and determines that the first database is in an abnormal state when it does not receive the master database lease periodically sent by the user partition. The user partition periodically sends a master database lease to the system partition in response to the first database being in a normal state, and determines that the first database is in an abnormal state in response to not receiving the master database lease periodically sent by the system partition.

10. A high-availability data management method applied to a second database in a data system, the data system further comprising an arbitration node and a first database, the first database serving as the primary database and the second database serving as the backup database, the method comprising: In response to the successful execution of the write operation from the first database to the second database, a write confirmation message is returned to the first database, so that the first database: A write success message is returned to the client in response to the successful writing of the target data to the first database and the second database, respectively. In response to the failure of the write operation to write the target data to the second database, the data write request is rolled back, and a backup database degradation request is sent to the arbitration node and the second database respectively. In response to receiving confirmation information returned by the arbitration node and / or the second database for the backup database degradation request, the data system is switched from the backup database normal state to the backup database abnormal state; The target data is written to both the first database and the second database by a data write request sent by the client to the first database. The primary database is configured to return a write success message to the client when the data system is in a normal backup state, in response to the successful writing of the target data to both the primary database and the backup database, and to return a write success message to the client when the data system is in an abnormal backup state, in response to the successful writing of the target data to the primary database.

11. The high-availability data management method according to claim 10, further comprising: In response to the current situation where the lease with the primary database meets the renewal conditions and no first primary database election request is received from the first database, a second primary database election request is sent to the arbitration node and the first database respectively, and in response to receiving confirmation information returned by the arbitration node and / or the first database for the second primary database election request, the second database is switched to the primary database.

12. A high-availability data management device, comprising: A first database is used in a data system, the data system further including an arbitration node and a second database, the first database serving as the primary database and the second database serving as the backup database, the apparatus comprising: The writing module is configured to respond to a data write request sent by a client by writing the target data indicated by the data write request into the first database and writing the target data into the second database. The sending module is used to roll back the data write request in response to the failure of the write operation to write the target data to the second database, and send a backup database degradation request to the arbitration node and the second database respectively. The degradation module is used to switch the data system from a normal state to an abnormal state in response to receiving confirmation information returned by the arbitration node and / or the second database for the degradation request of the standby database; The primary database is configured to return a write success message to the client in response to the successful writing of the target data to both the primary and the secondary databases when the data system is in a normal state (as the secondary database is in a normal state), and to return a write success message to the client in response to the successful writing of the target data to the primary database when the data system is in an abnormal state (as the secondary database is in an abnormal state).

13. A high-availability data management device applied to a second database in a data system, the data system further comprising an arbitration node and a first database, the first database serving as the primary database and the second database serving as the backup database, the device comprising: The return module is used to respond to the successful execution of the write operation from the first database to the second database, by returning a write confirmation message to the first database, so that the first database: A write success message is returned to the client in response to the successful writing of the target data to the first database and the second database, respectively. In response to the failure of the write operation to write the target data to the second database, the data write request is rolled back, and a backup database degradation request is sent to the arbitration node and the second database respectively. In response to receiving confirmation information returned by the arbitration node and / or the second database for the backup database degradation request, the data system is switched from the backup database normal state to the backup database abnormal state; The target data is written to both the first database and the second database by a data write request sent by the client to the first database. The primary database is configured to return a write success message to the client when the data system is in a normal backup state, in response to the successful writing of the target data to both the primary database and the backup database, and to return a write success message to the client when the data system is in an abnormal backup state, in response to the successful writing of the target data to the primary database.

14. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 11.

15. An electronic device comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1 to 11 by executing the executable instructions.

16. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 11.

Images