Master-slave switching method and device for distributed database

Abstract

The embodiment of the present specification provides a master-slave switching method and device of a distributed database. The master database and the standby database are both distributed databases; the library roles corresponding to all master copies and all standby copies in the master database are all master libraries; the library roles corresponding to all master copies and all standby copies in the standby database are all standby libraries; the method comprises: triggering any one first party in the master database and the standby database to perform master-slave switching; obtaining the current node state of a first node of a copy running a log stream in the first party; setting the library role of the first node according to the current node state of the first node and the library switching capability of each node of each copy running the log stream. The embodiment of the present specification can avoid setting errors of the library role of the node and avoid errors of the database business.

Description

Technical Field

[0001] This specification relates to database technology in one or more embodiments, and more particularly to a method and apparatus for master-slave switching of distributed databases. Background Technology

[0002] The database records every insert, update, and delete operation in a log. Later, by parsing the log, a complete history of data changes can be obtained, thus enabling data synchronization.

[0003] Traditional databases are typically single-machine databases. However, with the further development of database technology, distributed databases such as OceanBase have emerged. In a distributed database, all logs corresponding to a transaction are written to multiple log streams within the distributed database, and these different log streams may be distributed across multiple machine nodes within the distributed database.

[0004] To ensure the availability and cross-domain disaster recovery capabilities of distributed databases, primary and standby databases are typically configured. Under normal circumstances, the primary database provides database services to users, while the standby database backs up the log streams from the primary database. When the primary database becomes unavailable, the standby database needs to be switched to become the primary database. However, during the switchover process between the primary and standby databases in a distributed database, switchover errors frequently occur, reducing the availability of the distributed database. Summary of the Invention

[0005] This specification describes one or more embodiments of a method and apparatus for master-slave failover in a distributed database, which can reduce failover errors and improve the availability of the distributed database.

[0006] According to the first aspect, a method for primary-standby failover of a distributed database is provided, wherein both the primary database and the standby database are distributed databases; the primary database stores at least one log stream, each log stream including one primary replica and at least one standby replica, and the database role corresponding to all primary replicas and all standby replicas in the primary database is primary database; the standby database backs up all log streams in the primary database, each backed-up log stream including one primary replica and at least one standby replica, and the database role corresponding to all primary replicas and all standby replicas in the standby database is standby database; the method includes:

[0007] Trigger a primary / standby switchover between either the primary or standby database;

[0008] For the first node of the replica of the log stream in the first party, obtain the current node state of the first node;

[0009] Based on the current node status of the first node and the library switching capabilities of each node running the log stream, set the library role of the first node.

[0010] Wherein, the current node state of the first node is: maintaining the master node state; correspondingly, the first node is the master node; wherein, the master node is the node that runs the primary replica of the log stream;

[0011] The triggering of a primary or standby database switchover includes: the primary node receiving a database role switch command from the user; the database role switch command carrying the target database role to be switched to;

[0012] The setting of the library role for the first node includes:

[0013] The master node sends a library role switch notification to all slave nodes running all backup replicas of the log stream; the library role switch notification carries the target library role.

[0014] The master node receives the library role switching confirmation message returned by the slave node;

[0015] The master node determines whether the number of slave nodes that send the library role switch confirmation message is not less than half of the total number of slave nodes. If so, the master node will change its own library role to the target library role.

[0016] The process further includes, after the master node receives the library role switching command from the user, and before the master node sends the library role switching notification to all slave nodes of all backup replicas running the log stream, the master node caches the target library role information in memory.

[0017] The step of activating its own library role as the target library role includes: activating the target library role based on the information of the target library role cached in memory.

[0018] The process of converting one's own library role into the target library role further includes:

[0019] The master node broadcasts a target library role confirmation message to trigger the slave nodes that receive the target library role confirmation message to activate their own library roles as the target library role.

[0020] When the first node fails, either the primary database or the standby database is triggered to perform a primary-standby switchover.

[0021] After the first node crashes, when the first node resumes operation, the process of obtaining the current node state of the first node is performed.

[0022] The current node status of the first node is: elected as the master node after recovery; correspondingly, the first node is the master node elected after recovery; wherein, the master node is the node that runs the primary replica of the log stream;

[0023] The setting of the library role for the first node includes:

[0024] The master node sends a role query message to all slave nodes of all backup replicas running the log stream;

[0025] The master node receives a role response message from the slave node; this role response message carries information about the slave node's current library role.

[0026] The master node determines whether the role response messages sent by the majority of all slave nodes carry the same library role information. If so, it uses the library role information carried in the role response messages sent by the majority of slave nodes to activate its own library role.

[0027] When the first node fails, either the primary database or the standby database is triggered to perform a primary-standby switchover.

[0028] After the first node crashes, when the first node resumes operation, the process of obtaining the current node state of the first node is performed.

[0029] The current node status of the first node is: after recovery, it becomes a slave node; correspondingly, the first node is a slave node; wherein, the slave node is a node that serves as a backup copy of the running log stream;

[0030] The setting of the library role for the first node includes:

[0031] The slave node sends a role query request to the master node;

[0032] The slave node receives the role response notification returned by the master node;

[0033] The slave node applies its own library role based on the master node's current library role information carried in the received role response notification; the master node's current library role information is set by the master node based on its own library switching capability and the library switching capability of at least half of all slave nodes.

[0034] According to the second aspect, a master-slave failover device for a distributed database is provided, the device comprising:

[0035] This switching trigger module is configured to receive triggers for primary / standby switching;

[0036] The node status determination module is configured to obtain the current node status of the first node after the switchover trigger module receives the primary / standby switchover trigger.

[0037] The library role setting module is configured to set the library role of the first node based on the current node status of the first node and the library switching capabilities of each node of each replica running the log stream.

[0038] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-6.

[0039] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in any embodiment of this specification.

[0040] In the embodiments of this specification, during the switching process between the primary and standby databases, for a node that needs to switch database roles, the node's database role is not set directly according to the switching command or the saved previous database role. Instead, the current node status is considered first, i.e., whether the node is currently a primary node running the primary replica or a slave node running the standby replica. Secondly, the database switching capability of each node running each replica of the log stream is also considered (the database switching capability is: whether it can complete the database role switch). Therefore, the database role that the first node should be set can be obtained comprehensively, avoiding incorrect database role settings, thereby avoiding database business errors caused by switching errors and improving the reliability of switching between the primary and standby databases. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a schematic diagram of the structure of a distributed database.

[0043] Figure 2 This is a schematic diagram of the system architecture used in one embodiment of this specification.

[0044] Figure 3 This is a flowchart of a distributed database master-slave failover method in one embodiment of this specification.

[0045] Figure 4 This is a diagram illustrating a situation where read-write consistency requirements cannot be met during the master-slave switchover process in a distributed database.

[0046] Figure 5 This is a flowchart illustrating a method for meeting read-write consistency requirements during master-slave failover in a distributed database, as described in one embodiment of this specification.

[0047] Figure 6 This is a schematic diagram illustrating an embodiment of this specification in which read-write consistency requirements are met during the master-slave switchover process of a distributed database.

[0048] Figure 7 This is a diagram illustrating a situation where persistence requirements cannot be met during the master-slave switchover process in a distributed database.

[0049] Figure 8 This is a flowchart illustrating a method for meeting persistence requirements during master-slave failover in a distributed database, as described in one embodiment of this specification.

[0050] Figure 9 This is a schematic diagram illustrating how a distributed database master-slave failover process meets persistence requirements, according to one embodiment of this specification.

[0051] Figure 10 This is a diagram illustrating a situation where the atomicity requirement cannot be met during the master-slave switchover process in a distributed database.

[0052] Figure 11 This is a flowchart illustrating a method for satisfying atomicity requirements during master-slave failover in a distributed database, as described in this specification.

[0053] Figure 12 This is a schematic diagram illustrating how an embodiment of this specification satisfies the atomicity requirement during the master-slave switchover process in a distributed database.

[0054] Figure 13 This is a schematic diagram of the structure of a master-slave switching device for a distributed database in one embodiment of this specification. Detailed Implementation

[0055] To achieve high availability in a distributed database, a primary database and a backup database exist. Within each database, multiple replicas exist for each log stream. For example, see... Figure 1Taking log streams P1 and P2 as examples, each log stream has multiple replicas. In the primary database, the replica of P1 in node 11 is the primary replica (not indicated by a forward slash), and the replicas of P1 in nodes 12 and 13 (indicated by a forward slash) are backup replicas. Similarly, the replica of P2 in node 12 is the primary replica (not indicated by a forward slash), and the replicas of P2 in nodes 11 and 13 (indicated by a forward slash) are backup replicas. Furthermore, the standby database also includes the two log streams P1 and P2, as well as multiple replicas of these two log streams. For example, in the standby database, the replica of P1 in node 21 is the primary replica (not indicated by a forward slash), the replica of P1 in node 22 (indicated by a forward slash) is a backup replica, the replica of P2 in node 22 is the primary replica (not indicated by a forward slash), and the replica of P2 in node 21 (indicated by a forward slash) is a backup replica.

[0056] Each replica corresponds to a database role, which indicates whether it's a replica in the primary or standby database. For example, in the primary database, all primary and standby replicas are assigned the primary database role, while in the standby database, all primary and standby replicas are assigned the standby database role. During a switchover between the primary and standby databases in a distributed database, all replicas in the original primary database (including primary and standby replicas) need to change their database role to standby, and all replicas in the original standby database (including primary and standby replicas) need to change their database role to primary. However, in actual switchover processes, nodes frequently experience crashes or other anomalies, leading to errors in the database role switching of a replica, resulting in switchover errors and ultimately, database service failures.

[0057] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0058] First, it should be noted that the terminology used in the embodiments of this invention is for the purpose of describing specific embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” used in the embodiments of this invention and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0059] To facilitate understanding of the methods provided in this manual, the system architecture involved and applicable to this manual is first described. For example... Figure 2 As shown, the system architecture mainly includes three network nodes: primary database, backup database, and switching control device.

[0060] Both the primary and standby databases are distributed databases. The primary database stores at least one log stream, with each log stream having one primary replica and at least one secondary replica, stored on different nodes corresponding to the primary database. The standby database stores all log streams from the primary database, with each log stream having one primary replica and at least one secondary replica, stored on different nodes corresponding to the standby database. In the primary database, all primary and secondary replicas are assigned the role of primary database; in the standby database, all primary and secondary replicas are assigned the role of secondary database. Different nodes corresponding to the primary database can be located in different regions; similarly, different nodes corresponding to the standby database can also be located in different regions.

[0061] It should be understood that Figure 2 The number of primary databases, backup databases, and switching control devices shown is merely illustrative. Any number can be selected and deployed as needed.

[0062] The switching control device interacts with both the primary and backup databases via a network. This network can include various connection types, such as wired or wireless communication links or fiber optic cables.

[0063] Figure 3 This is a flowchart of a distributed database master-slave failover method in one embodiment of this specification. It is understood that this method can also be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. See also... Figure 3 The method includes:

[0064] Step 301: Trigger a primary / standby switchover between either the primary or standby database.

[0065] Step 303: For the first node of the replica of the running log stream in the first party, obtain the current node status of the first node.

[0066] Step 305: Based on the current node status of the first node and the library switching capabilities of each node running the log stream replicas, set the library role of the first node.

[0067] According to the above Figure 3As can be seen from the process described, in the embodiments of this specification, during the switching process between the primary and standby databases, for a node that needs to switch database roles, the node's database role is not set directly according to the switching command or the saved previous database role. Instead, the current node status is considered first, i.e., whether the node is currently a primary node running the primary replica or a secondary node running the standby replica. Secondly, the database switching capability of each node running each replica of the log stream is also considered (the database switching capability is: whether it can complete the database role switch). Therefore, the database role that the first node should be set can be obtained comprehensively, avoiding incorrect database role settings, thereby avoiding database business errors caused by switching errors and improving the reliability of switching between the primary and standby databases.

[0068] The following section, in conjunction with the accompanying drawings, discusses... Figure 3 The process shown will be explained.

[0069] Figure 3 The method described is universal and can avoid incorrect database role settings in different business scenarios, ensuring the correctness of database switching. Specifically, the above... Figure 3 The method described guarantees read / write consistency, durability, and atomicity during the switchover process between the primary and standby databases. Below, we will illustrate each of these aspects with a business scenario example. Figure 3 The implementation process of the method shown.

[0070] Scenario 1: Ensure read / write consistency during the switchover between the primary and backup databases.

[0071] Read-write consistency refers to the following: Database master-slave changes and reads must satisfy read-after-write consistency, meaning users can always see the latest successfully changed master-slave database status; it must also satisfy monotonic read consistency, meaning that if a user reads the database role of any node in the database at a certain point in time (e.g., the master database), and if the user does not subsequently initiate a new database switch command, the database role of any node in that database that the user reads thereafter should remain unchanged (e.g., still the master).

[0072] However, during the master-slave switchover process in a distributed database, read-write consistency issues may arise due to node failures or other reasons. For example, referring to the accompanying diagrams, a database X includes nodes 1 (in the diagrams, all cylinders marked with the number 1 represent node 1), 2 (in the diagrams, all cylinders marked with the number 2 represent node 2), and 3 (in the diagrams, all cylinders marked with the number 3 represent node 3), each running a log stream. This database X was originally the primary database. If a user switches database X to the standby database, then the database role of all nodes running the log stream in database X should be changed to standby. See [link to diagram]. Figure 4 User A changes the database role of node 1 (the primary node) to that of a secondary node. User B then queries and finds that node 1's database role is indeed secondary, indicating that database X, where node 1 resides, is currently a secondary database. However, after node 1 makes its role secondary, it fails and goes down. Since node 1, as the primary node, hasn't instructed nodes 2 and 3 (as secondary nodes) to also make their database roles secondary, the roles of nodes 2 and 3 remain unchanged, still indicating they are primary. Because node 1 fails, node 3 is elected as the primary node. User B then queries node 3 again and finds that its database role is now primary, indicating that database X, where node 3 resides, is currently the primary database. However, User B didn't perform any operation to switch database X from secondary to primary after the initial query. The primary / secondary status of database X in the initial query ("secondary") differs from the primary status in the subsequent query ("primary"), leading to inconsistencies in data read / write operations.

[0073] The methods described in this specification can be applied to this business scenario. The main function is to run the master node of the primary replica to control the modification process of the database roles on each node, thereby ensuring read-write consistency.

[0074] When applied to business scenario one Figure 3 The current node state of the first node in the process is: maintaining the master node state; correspondingly, the first node is the master node; the step 301 of triggering a master-slave switch between either the primary database or the standby database includes: the master node receiving a database role switch command sent by the user; the database role switch command carries the target database role to be switched to;

[0075] Step 305 sets the library role for the first node, including:

[0076] Step 3051: The master node sends a library role switch notification to all slave nodes of all backup replicas running the log stream; the library role switch notification carries the target library role;

[0077] Step 3053: The master node receives the library role switch confirmation message returned by the slave node;

[0078] Step 3055: The master node determines whether the number of slave nodes that sent the library role switch confirmation message is not less than half of the total number of slave nodes. If so, the master node will change its own library role to the target library role.

[0079] Furthermore, after the first node receives the database role switching command from the user in step 3051, and before the master node sends the database role switching notification to all slave nodes of all backup replicas running the log stream in step 3053, the process further includes step 3052: the master node caches the target database role information in memory; correspondingly, in step 3055, the target database role is activated based on the cached target database role information. It is evident that through the processing in steps 3052 and 3055, it can be ensured that the master node activates the target database role "backup database" only when a majority of nodes among all nodes of all replicas running the log stream can successfully switch database roles, thereby guaranteeing data read / write consistency.

[0080] For example, to solve the problem described above Figure 4 For the described inconsistency issues, see [link to relevant documentation]. Figure 5 In one embodiment of this specification, the method for implementing master-slave failover of a distributed database corresponding to business scenario one may specifically include:

[0081] Step 501: The master node, i.e., node 1, receives the library role switching command sent by the user; the library role switching command carries the target library role to which it needs to switch.

[0082] See Figure 6 In database X, the original database roles of nodes 1, 2, and 3, which run a log stream, are primary databases. V2 represents the target database role "standby database", and V1 represents the original database role "primary database".

[0083] Step 503: Node 1 obtains its current node status as a master node.

[0084] Step 505: Before a majority vote is reached for the switch, Node 1 caches the current changes, that is, it caches V2 in memory, and V1 remains in effect. The target library role V2 is temporarily not effective.

[0085] Step 507: Node 1 sends a library role switching notification to Node 2 and Node 3; the library role switching notification carries the target library role information.

[0086] Step 509: Node 1 receives library role switching confirmation messages returned by each slave node.

[0087] Step 511: Node 1 determines whether the number of slave nodes that sent the database role switching confirmation message is not less than half of the total number of slave nodes. If so, proceed to step 513; otherwise, end the current process.

[0088] Here, if the number of slave nodes that send database role switching confirmation messages is not less than half of the total number of slave nodes, then most of the nodes, including node 1, can successfully switch database roles and cooperate to complete the database switch.

[0089] Step 513: Node 1 sets its own library role to V2 based on the target library role V2 cached in memory.

[0090] Step 515: Node 1 broadcasts a target library role confirmation message to trigger the slave nodes 2 and 3, which received the target library role confirmation message, to change their own library role to the target library role V2.

[0091] The above Figure 5 The process shown can solve the above combination. Figure 4 The inconsistency between read and write operations is illustrated. For example, see [link to relevant documentation]. Figure 5 , Figure 6 User A changes the database role of node 1 (the primary node) to that of a secondary node. At this point, node 1 does not automatically change its database role to secondary; its active database role remains V1 (as before the switchover). Node 1 caches the necessary database role V2 in memory. User B then queries and finds that node 1's database role is the primary database (V1), indicating that database X, where node 1 resides, is the primary database. Subsequently, node 1 fails and goes down. As the primary node, node 1 has not yet instructed nodes 2 and 3 (the secondary nodes) to also change their database roles to secondary. Therefore, the active database roles in nodes 2 and 3 remain unchanged, still the original primary database (V1). Then, as described above... Figure 5 The principle of the method is that the master node learns from all other nodes. Since node 3's own database role is V1 and it also learns that node 2's database role is V1, the majority of nodes have a database role of V1. Therefore, the effective database role in node 3 is the master database, i.e., V1. Because node 1 crashes, node 3 is elected as the master node. When user B queries node 3 again as the master node, they find that node 3's database role is the master database, thus determining that database X, where node 3 resides, is the master database. Therefore, user B's query result is consistent with the previous query result, both indicating the master database, thus satisfying the data read / write consistency requirement.

[0092] Scenario 2: Ensure persistence during the switchover between the primary and backup databases.

[0093] Durability means that once the database switchover is successful, the master / slave status of the database, i.e., the database role of each node, should not change regardless of how the master node is switched over or any node fails.

[0094] However, during the master-slave failover process in distributed databases, issues arise that cannot guarantee durability. For example, see... Figure 7 Node 3 failed and went down. At this time, a switchover occurred between the primary and standby databases. The user changed the database role of Node 1, which was the primary node, to that of the standby database. Afterwards, Node 1 and Node 2, which were in normal working order, could both successfully switch over and change their database roles to standby. For example, Node 1 could use the above... Figure 5 The process shown allows for the switching of the database role once it is determined that a majority of nodes (including node 1 itself) have the capability to switch databases. Node 3, due to a system crash, cannot complete the database role modification. After the switchover between node 1 and node 2 is complete, node 3 recovers and is elected as the primary node. However, node 3's database role remains the primary database from before the failure. The primary node's database role becomes incorrect, failing to meet the aforementioned persistence requirement.

[0095] The method described in the embodiments of this specification can be applied to business scenario two. In this case, Figure 3 The current state of the first node in the process is: it was elected as the master node after recovery; correspondingly, the first node is the master node elected after recovery (i.e., ...). Figure 9 In step 301, when the first node fails, either the primary database or the standby database is triggered to perform a primary / standby switchover.

[0096] After the first node crashes, when the first node resumes operation, the process of obtaining the current node state of the first node is performed.

[0097] Step 305 sets the library role for the first node, including:

[0098] After recovering from a crash and being elected as the master node, the elected master node sends a role query message to all slave nodes running all backup replicas of the log stream.

[0099] The master node receives a role response message from the slave node; this role response message carries information about the slave node's current library role.

[0100] The master node determines whether the role response messages sent by the majority of all slave nodes carry the same library role information. If so, it uses the library role information carried in the role response messages sent by the majority of slave nodes to activate its own library role.

[0101] For example, to solve the problem described above Figure 7For the described problem of not being able to satisfy atomicity, see [link to relevant documentation]. Figure 8 In one embodiment of this specification, the method for implementing master-slave failover of a distributed database corresponding to business scenario two may specifically include:

[0102] Step 801: Node 3, as a slave node, fails and goes down. Node 1, as the master node, receives a database role switching command from the user. The database role switching command carries the target database role to which the user needs to switch.

[0103] See Figure 9 In database X, the original database roles of nodes 1, 2, and 3, which run a log stream, are primary databases. V2 represents the target database role "standby database", and V1 represents the original database role "primary database".

[0104] Step 803: After determining that a majority of nodes (including node 1 itself) can switch database roles, node 1 can successfully switch, that is, set its own database role as a standby database, and at the same time node 2 will also make its own database role effective as a standby database.

[0105] The specific implementation process of step 803 can be found in the above. Figure 5 The process shown is as follows.

[0106] Step 805: Node 3 resumes operation and is elected as the master node.

[0107] Step 807: Node 3 sends a role query message to Node 1 and Node 2.

[0108] Step 809: Node 3 receives role response messages returned by nodes 1 and 2; the role response message carries information about the current library role of the slave node.

[0109] Since both nodes 1 and 2 have changed their library role to the master library, i.e., V2, the two role reply messages received by node 3 both carry V2.

[0110] Step 811: Node 3 determines whether the role response messages sent by a majority of the nodes from all the slave nodes carry the same library role information. If so, proceed to step 813; otherwise, end the current process.

[0111] Step 813: Node 3 uses the library role information carried in the role reply message sent by the majority of nodes to activate its own library role.

[0112] The above Figure 8 In the process shown, node 3, as the newly elected master node, learns the latest library role from the majority of nodes (which includes node 3 itself) during the appointment process. See also Figure 9Since there are a total of 3 nodes, and the library role information replied by nodes 1 and 2, which are the majority nodes, is the same, both being V2, in this step 813, the role with the largest role version number among the majority nodes, namely V2, is taken as the current role, that is, its own library role is made the main library.

[0113] Combination Figure 9 As shown above, Figure 8 The process shown satisfies the persistence requirements during database switching.

[0114] Scenario 3: Ensure atomicity during the switchover between the primary and backup databases.

[0115] Atomicity means that a database switch operation must either succeed or fail; there should be no intermediate state. In other words, the database roles corresponding to all nodes running the log stream replica in the database must either all be modified successfully or all be modified unsuccessfully. It is not allowed for only a portion of the nodes to have their database roles modified successfully.

[0116] However, during the master-slave failover process in distributed databases, atomicity issues may arise. For example, see... Figure 10 Node 3 failed and went down. At this time, a switchover between the primary and standby databases occurred. The user changed the database role of Node 1, which was the primary node, to that of the standby database. Afterwards, Node 1 and Node 2, which were in normal working order, could both successfully switch over and change their database roles to standby databases. For example, Node 1 could use the above... Figure 5 The process shown allows for the switching of database roles once the majority (including node 1 itself) has the capability to switch database roles. Node 3, due to a system crash, cannot complete the database role modification. After the switch between node 1 and node 2 is complete, node 3 resumes operation as a slave node. However, node 3's database role remains the primary database from before the failure, failing to become a backup database. This results in a database role error, failing to meet the aforementioned atomicity requirement.

[0117] The method described in the embodiments of this specification can be applied to business scenario three. In this case, Figure 3 The current state of the first node in the process is: after recovery, it becomes a slave node; correspondingly, the first node is the recovered slave node (i.e., Figure 12 In step 301, when the first node fails, either the primary database or the standby database is triggered to perform a primary / standby switchover.

[0118] After the first node crashes, when the first node resumes operation, the process of obtaining the current node state of the first node is performed.

[0119] Step 305 sets the library role for the first node, including:

[0120] After recovering from a crash and becoming a slave node, the slave node sends a role query request to the master node.

[0121] The slave node receives the role response notification returned by the master node;

[0122] The slave node applies its own library role based on the master node's current library role information carried in the received role response notification; the master node's current library role information is set by the master node based on its own library switching capability and the library switching capability of at least half of all slave nodes.

[0123] For example, to solve the problem described above Figure 10 For the described problem of not being able to satisfy atomicity, see [link to relevant documentation]. Figure 11 , Figure 12 In one embodiment of this specification, the method for implementing master-slave failover of a distributed database corresponding to business scenario three may specifically include:

[0124] Step 1101: Node 3, as a slave node, fails and goes down. Node 1, as the master node, receives a database role switching command from the user. The database role switching command carries the target database role to which the user needs to switch.

[0125] See Figure 12 In database X, nodes 1, 2, and 3, which run a log stream, were originally the primary database. V2 represents the target database role "standby database," and V1 represents the original database role "primary database."

[0126] Step 1103: After determining that a majority of nodes (including itself) can switch the database role, node 1 can successfully switch, that is, its database role will be set to standby database. At the same time, node 2 will also set its database role to standby database.

[0127] The specific implementation process of step 1103 can be found in the above. Figure 5 The process shown is as follows.

[0128] Step 1105: Node 3 resumes operation and becomes a slave node.

[0129] Step 1107: Node 3 sends a role query request to Node 1, which is the master node, in order to learn the current role from the master node.

[0130] Step 1109: Node 3 receives the role response notification returned by Node 1.

[0131] Step 1111: Node 3 activates its own library role based on the library role information of the master node carried in the received role reply notification; wherein, the library role information of the master node is set by the master node based on its own library switching capability and the library switching capability of at least half of all slave nodes.

[0132] Because in step 1103, node 1, based on the majority (including node 1 itself) of the switchable results, sets its library role to primary library (V2), and node 2 also changes its library role to primary library (V2), the role response notification received by node 3 from node 1 carries V2. Therefore, node 3 will also set its library role to V2 according to the latest library role of the primary node (node ​​1). Figure 8 In the process shown, node 3, as the newly elected master node, learns the latest library role from the majority of nodes (which includes node 3 itself) during the appointment process. See also Figure 9 Since there are a total of 3 nodes, and the library role information replied by nodes 1 and 2, which are the majority nodes, is the same, both being V2, in this step 813, the role with the largest role version number among the majority nodes, namely V2, is taken as the current role, that is, its own library role is made the main library.

[0133] In one embodiment of this specification, a primary / standby failover device for a distributed database is provided, wherein both the primary and standby databases are distributed databases. The primary database stores at least one log stream, each log stream including one primary replica and at least one standby replica. All primary replicas and all standby replicas in the primary database correspond to the primary database role. The standby database backs up all log streams from the primary database, each backed-up log stream including one primary replica and at least one standby replica. All primary replicas and all standby replicas in the standby database correspond to the standby database role. This device can be installed in each node of the database. See [link to documentation]. Figure 13 The device includes:

[0134] The switching trigger module 1301 is configured to receive triggers for primary / standby switching;

[0135] The node status determination module 1302 is configured to obtain the current node status of the first node after the switchover trigger module 1301 receives the trigger for primary / standby switchover;

[0136] The library role setting module 1303 is configured to set the library role of the first node based on the current node status of the first node and the library switching capability of each node running each replica of the log stream. In one embodiment of the device in this specification, the current node status of the first node is: maintaining the master node status; correspondingly, the first node is the master node; the master-slave switching device of the distributed database is set in the master node.

[0137] The switching trigger module 1301 is configured to execute: receiving a library role switching command from the user; the library role switching command carries the target library role to which the user needs to switch;

[0138] Library role settings module 1303 is configured to execute:

[0139] Send a library role switch notification to all slave nodes of all backup replicas running the log stream; the library role switch notification carries the target library role.

[0140] Receive the library role switch confirmation message returned from the node;

[0141] Determine whether the number of slave nodes that have sent the library role switch confirmation message is not less than half of the total number of slave nodes. If so, change the slave node's own library role to the target library role.

[0142] In one embodiment of the device described in this specification, the library role setting module 1303 is configured to: cache the target library role information in memory before sending a library role switching notification to all slave nodes of all backup replicas running the log stream; then, based on the target library role information cached in memory, activate its own library role as the target library role.

[0143] In one embodiment of the device described in this specification, the library role setting module 1303 is configured to perform the following: after making its own library role the target library role, broadcast a target library role confirmation message to trigger the slave node that receives the target library role confirmation message to make its own library role the target library role.

[0144] In one embodiment of the device described in this specification, when the first node fails, either the primary database or the standby database is triggered to perform a primary / standby switchover.

[0145] After the first node crashes, when the first node resumes operation, the node status determination module 1302 obtains the current node status of the first node;

[0146] The current node status of the first node is: elected as the master node after recovery; correspondingly, the first node is the master node elected after recovery; the master-slave switching device of the distributed database is set in the master node elected after recovery;

[0147] Library role settings module 1303 is configured to execute:

[0148] Send a role query message to all slave nodes of all backup replicas running this log stream;

[0149] Receive the role response message returned by the slave node; the role response message carries information about the slave node's current library role.

[0150] Determine whether the role response messages sent by the majority of all slave nodes carry the same library role information. If so, use the library role information carried in the role response messages sent by the majority of slave nodes to activate its own library role.

[0151] In one embodiment of the device described in this specification, when the first node fails, either the primary database or the standby database is triggered to perform a primary / standby switchover.

[0152] After the first node crashes, when the first node resumes operation, the node status determination module 1302 executes the above steps to obtain the current node status of the first node.

[0153] The current node status of the first node is: after recovery, it becomes a slave node; correspondingly, the first node is a slave node; wherein, the slave node is the node that serves as a backup copy of the running log stream; the master-slave switching device of the distributed database is set in the recovered slave node;

[0154] Library role settings module 1303 is configured to execute:

[0155] Send a role query request to the master node; receive a role response notification from the master node; and apply the master node's current library role information to itself based on the master node's current library role information carried in the received role response notification. The master node's current library role information is set by the master node based on its own library switching capability and the library switching capability of at least half of all slave nodes.

[0156] It should be noted that the above-mentioned devices are typically implemented on the server side. They can be set up on independent servers, or a combination of some or all of the devices can be set up on the same server. This server can be a single server or a server cluster consisting of multiple servers. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPs) services, such as high management difficulty and weak service scalability. The above-mentioned devices can also be implemented on computer terminals with strong computing capabilities.

[0157] This specification provides, in one embodiment, a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the methods of any embodiment in the specification.

[0158] This specification provides a computing device according to one embodiment, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to perform the method of any embodiment of the specification.

[0159] It is understood that the structures illustrated in the embodiments of this specification do not constitute a specific limitation on the apparatus of the embodiments of this specification. In other embodiments of the specification, the above-described apparatus may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0160] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0161] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for switching over a master and a backup of a distributed database, wherein, The master database and the standby database are both distributed databases; at least one log stream is stored in the master database, each log stream includes one master copy and at least one standby copy, and the roles of all master copies and all standby copies in the master database are master databases; all log streams in the master database are backed up in the standby database, each backed-up log stream includes one master copy and at least one standby copy, and the roles of all master copies and all standby copies in the standby database are standby databases; the method comprises the following steps: Triggering any first party in the master database and the standby database to perform master-standby switching; Obtaining the current node state of a first node running a master copy or a standby copy of a log stream in the first party; When the first node is a master node running a master copy of the log stream, setting the role of the first node according to the current node state of the first node, the database switching capability of each slave node running a standby copy of the log stream; When the first node is a slave node running a standby copy of the log stream, setting the role of the first node according to the current node state of the first node, the database switching capability of each slave node running a standby copy of the log stream, and the database switching capability of a master node running a master copy of the log stream; The database switching capability is whether the role of the database can be switched.

2. The method of claim 1, wherein, The current node state of the first node is to maintain the state of the master node; accordingly, the first node is the master node; the master node is a node running a master copy of the log stream. The triggering of the master-standby switching of any first party in the master database and the standby database comprises that the master node receives a database role switching command sent by a user; the database role switching command carries a target database role to which switching is required; The setting of the role of the first node comprises the following steps: The master node sends a database role switching notification to all slave nodes of all standby copies running the log stream; the database role switching notification carries the target database role; The master node receives a database role switching confirmation message returned by the slave node; The master node judges whether the number of slave nodes sending the database role switching confirmation message is not less than half of the number of all slave nodes; if yes, the master node validates the database role of the master node as the target database role.

3. The method of claim 2, wherein, After the master node receives the database role switching command sent by the user, and before the master node sends the database role switching notification to all slave nodes of all standby copies running the log stream, the master node further buffers information of the target database role in the memory; The validation of the database role of the master node as the target database role comprises that the target database role is validated according to the information of the target database role buffered in the memory.

4. The method of claim 2, wherein, After the database role of the master node is validated as the target database role, the master node further broadcasts a target database role confirmation message to trigger the slave node receiving the target database role confirmation message to validate the database role of the slave node as the target database role. When the first node is down, triggering any first party in the master database and the standby database to perform master-standby switching; 5. The method of claim 1, wherein, ​ obtaining a current node state of the first node when the first node resumes work after being down; the current node state of the first node is that the first node is elected as a master node after resuming work; and the first node is the master node after resuming work; wherein the master node is a node running a primary copy of a log stream; the setting of the library role of the first node comprises: the master node sends a role query message to all slave nodes running all backup copies of the log stream; the master node receives a role reply message returned by the slave node; the role reply message carries information of a current library role of the slave node; the master node judges whether the role reply messages from a majority of the slave nodes carry the same information of the library role; if so, the master node uses the information of the library role carried in the role reply messages from the majority of the slave nodes to take effect on the library role of the master node.

6. The method of claim 1, wherein, triggering a first node in either of a master database and a standby database to perform master-standby switchover when the first node is down; obtaining a current node state of the first node when the first node resumes work after being down; the current node state of the first node is that the first node becomes a slave node after resuming work; and the first node is the slave node; wherein the slave node is a node running a backup copy of a log stream; the setting of the library role of the first node comprises: the slave node sends a role query request to the master node; the slave node receives a role reply notification returned by the master node; the slave node takes effect on the library role of the slave node according to information of a current library role of the master node carried in the received role reply notification; wherein the information of the current library role of the master node is set by the master node according to a library switching capability of the master node and a library switching capability of at least half of all slave nodes.

7. The master-slave switching device of a distributed database, wherein, the master database and the standby database are both distributed databases; at least one log stream is saved in the master database, each log stream comprises a primary copy and at least one backup copy, and the corresponding library roles of all primary copies and all backup copies in the master database are master libraries; all log streams in the master database are backed up in the standby database, each backed-up log stream comprises a primary copy and at least one backup copy, and the corresponding library roles of all primary copies and all backup copies in the standby database are backup libraries; the device comprises: a switchover triggering module configured to receive a trigger of master-standby switchover; a node state determining module configured to obtain a current node state of a first node in which the node state determining module is located after the switchover triggering module receives the trigger of master-standby switchover; wherein the first node runs a primary copy or a backup copy of a log stream. The library role setting module is configured to, when the first node is a master node running a primary copy of a log stream, set the library role of the first node according to a current node state of the first node and library switching capabilities of each slave node running a backup copy of the log stream; and when the first node is a slave node running a backup copy of the log stream, set the library role of the first node according to a current node state of the first node, library switching capabilities of each other slave node running a backup copy of the log stream, and a library switching capability of a master node running a primary copy of the log stream. The library switching capability is whether the library role can be switched.

8. The apparatus of claim 7, wherein, The device is arranged in each node running each copy. 9.A computer readable storage medium having stored thereon a computer program, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-6. 10.A computing device comprising a memory and a processor, the memory having stored therein executable code, the processor, when executing the executable code, implementing the method of any one of claims 1-6.

Images