Node switching method, electronic device and computer readable storage medium

Abstract

Embodiments of the present invention relate to the field of Internet technology, and in particular to a node switching method, an electronic device, and a computer-readable storage medium. The above-mentioned node switching method includes: if the main management node of a distributed database is abnormal, determining whether several backup management nodes of the distributed database have consistent copies; wherein the distributed database includes management nodes and non-management nodes corresponding to the management nodes, and the management nodes include a main management node and several backup management nodes; if at least one backup management node has a consistent copy, a new main management node is determined among the backup management nodes with consistent copies; and the non-management nodes are switched according to the new main management node. The node switching method provided by the embodiment of the present invention aims to improve the logical rigor of the node switching process, making the switching method more reasonable and simple, ensuring that the distributed database does not lose data, and thus ensuring that various businesses can operate normally.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of Internet technology, and in particular to a node switching method, an electronic device, and a computer-readable storage medium. Background Art

[0002] With the rapid development of Internet technology, the scale of industry application systems has expanded rapidly, and the amount of data generated by industry applications has exploded, especially in the financial industry, technology industry and other industries that value data security. Centralized databases can no longer meet the needs of terabyte (TB) or even petabyte (PB) data. Various industries are increasingly in need of a method that can quickly process data and respond to user access in a timely manner, and also need this method to centrally analyze, manage and maintain data.

[0003] Therefore, distributed databases with characteristics such as transparency, data redundancy, easy scalability, and autonomy have become a commonly used method in the industry. Distributed databases often use a multi-site and multi-center networking architecture to ensure the stability and reliability of their services and the high availability of each component. In actual use, distributed databases need to face the challenges of natural disasters and man-made disasters. Therefore, in a disaster recovery environment, whether the business can be migrated normally, whether each component can be switched smoothly, and the operating status after switching are important factors in measuring the high availability of the database. Related technologies often use a dual-machine cluster system (Highly Available, referred to as: HA) to switch between the primary and standby management nodes.

[0004] However, the HA environment switching operation is complex and data inconsistency is prone to occur, resulting in low disaster recovery capabilities of distributed databases. Summary of the invention

[0005] The main purpose of the embodiments of the present application is to propose a node switching method, an electronic device and a computer-readable storage medium, aiming to improve the logical rigor of the node switching process, make the switching method more reasonable and simple, ensure that the distributed database does not lose data, and thus ensure that various services can operate normally.

[0006] To achieve the above-mentioned purpose, an embodiment of the present application also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above-mentioned node switching method.

[0007] To achieve the above objectives, an embodiment of the present application further provides a readable storage medium storing a computer program, which implements the above node switching method when executed by a processor.

[0008] The node switching method, electronic device and computer-readable storage medium proposed in the present application, if the main management node of the distributed database is abnormal, it is determined whether several backup management nodes of the distributed database have consistent copies; wherein, the distributed database includes management nodes and non-management nodes corresponding to the management nodes, and the management nodes include main management nodes and several backup management nodes. If the main management node is abnormal, it means that the main management node fails, and the distributed database cannot continue to be used, and enters the fault switching mode. If at least one backup management node has a consistent copy, a new main management node is determined in the backup management nodes with consistent copies. Because the new main management node has a consistent copy, the node is used as the new main management node, which can reduce the amount of data loss to 0, that is, metadata will not be lost after switching. According to the new main management node, the non-management node is switched, and the distributed database can be restored in time to make the distributed database run again. In the embodiment of the present invention, whether the backup management node has a consistent copy is considered during the switching process, which improves the logical rigor of the node switching process, makes the switching method more reasonable, and makes the switching operation simpler, so as to ensure that the distributed database does not lose data, thereby ensuring that various businesses can operate normally. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a flowchart of a node switching method according to a first embodiment of the present invention;

[0010] Figure 2 is a schematic diagram of a distributed database provided according to a first embodiment of the present invention;

[0011] Figure 3 is a schematic diagram of another distributed database provided according to the first embodiment of the present invention;

[0012] Figure 4 is a flowchart of determining whether a plurality of backup management nodes have consistent copies if a primary management node is abnormal according to the first embodiment of the present invention;

[0013] Figure 5 is a flowchart of a node switching method according to a second embodiment of the present invention;

[0014] Figure 6 is a flowchart of a node switching method according to a third embodiment of the present invention;

[0015] Figure 7 is a schematic diagram of a distributed database provided according to a third embodiment of the present invention;

[0016] Figure 8 is a flowchart of switching a non-management node according to a new primary management node in accordance with a third embodiment of the present invention;

[0017] Fig. 9 is a flowchart of a node switching method according to a fourth embodiment of the present invention;

[0018] Fig.10 is a flowchart of a fault-same-city switching mode provided according to a fourth embodiment of the present invention;

[0019] Fig.11 is a flow chart of a drill switching mode provided according to a fourth embodiment of the present invention;

[0020] Fig.12 is a flow chart of a fault-inter-city switching mode provided according to a fourth embodiment of the present invention;

[0021] Fig.13 is a schematic structural diagram of an electronic device according to a fifth embodiment of the present invention. DETAILED DESCRIPTION

[0022] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the present application, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can also be implemented. The division of the following embodiments is for the convenience of description, and the specific implementation of the present application should not be construed as any limitation, and the various embodiments can be combined and referenced with each other under the premise of no contradiction.

[0023] The first embodiment of the present invention relates to a node switching method, which is applied to an electronic device, wherein the electronic device can be a server. In this embodiment and the following embodiments, the electronic device is described by taking the server as an example. The implementation details of the node switching method of this embodiment are described in detail below. The following content is only for the convenience of understanding the implementation details provided, and is not necessary for implementing this solution.

[0024] The specific process of the node switching method of this embodiment can be as follows Figure 1 As shown, including:

[0025] Step 101, if the main management node of the distributed database is abnormal, determine whether several backup management nodes of the distributed database have consistent copies; if yes, execute step 102, otherwise, end directly;

[0026] Specifically, when an abnormality occurs in the main management node of the distributed database managed by the server, the server can determine whether several backup management nodes of the distributed database have consistent copies. Among them, the distributed database includes management nodes and non-management nodes corresponding to the management nodes. The management nodes include a main management node and several backup management nodes. Each management node can correspond to one or more non-management nodes. If the main management node can work normally, it means that the main management node is normal. If the main management node cannot work normally, it means that the main management node is abnormal. The reasons for the abnormality of the main management node include but are not limited to power failure of the main management node and disconnection of the main management node from the network.

[0027] In one example, the distributed database is Figure 2 The one-site three-center distributed database shown includes three computer rooms, namely computer room 1, computer room 2 and computer room 3. Each computer room is equipped with two management nodes. Each management node corresponds to a global transaction manager (Global Transaction Manager, abbreviated as: GTM) and two data nodes (Data Bank, abbreviated as: DB). Both GTM and DB are non-management nodes.

[0028] In one example, a distributed database is built with a distributed service framework, where the distributed service framework can be a zookeeper framework. The zookeeper framework is powerful and easy to build. You only need to deploy a zookeeper node on the server. The interface of the zookeeper node can clearly display the IP address and port information of the current main management node. A three-center distributed database built with a zookeeper framework can be as follows: Figure 3 As shown in the figure, each management node corresponds to a zookeeper node. Considering that the related technology uses HA for node switching, the HA environment is complex to build. Not only do the IPs in the same network segment need to be active and standby for each other, but the DNS service also needs to be configured. The active and standby relationship of data is unclear and it is easy to have inconsistency between the active and standby nodes. The switching is subject to many restrictions. However, the zookeeper framework makes the environment construction simpler, the requirements for the server are relatively low, and the switching is simple.

[0029] In the specific implementation, in order to solve the single point failure problem, the distributed database has several backup management nodes that store copies of the metadata of the main management node, and the copies that are completely consistent with the metadata of the main management node are called consistent copies. However, it takes a certain amount of time to synchronize the metadata of the main management node to each backup management node, so there is a situation in the distributed database where the backup management node does not have a consistent copy.

[0030] In one example, if the server determines that none of the backup management nodes has a consistent copy, the server may directly terminate the switching process.

[0031] In another example, if the server determines that several backup management nodes do not have consistent copies, the server can determine a new primary management node based on the primary election priorities of the several backup management nodes, where the primary election priority can be set by technical personnel in this field when setting up a distributed database, and the embodiments of the present invention do not specifically limit this.

[0032] In another example, if the main management node of the distributed database is abnormal, it can be determined whether the plurality of backup management nodes of the distributed database have consistent copies. Figure 4 The implementation of each sub-step shown is as follows:

[0033] Sub-step 1011, if the main management node of the distributed database is abnormal, obtain the water level information of the distributed database;

[0034] Specifically, after the server determines that the main management node of the distributed database is abnormal, it can obtain the water level information of the distributed database. The water level information can truly reflect the current synchronization status of the distributed database. Considering the water level information during the switching process can effectively avoid metadata loss after the switch.

[0035] In one example, after determining that the main management node is abnormal, the server may analyze the synchronization status of several backup management nodes of the distributed database, and obtain the water level information of the distributed database according to the analysis result.

[0036] Sub-step 1012, if the water level information is a high water level, replaying several backup management nodes of the distributed database;

[0037] Specifically, if the water level information of the distributed database obtained by the server is a high water level, several backup management nodes of the distributed database may be replayed.

[0038] In the specific implementation, the server can obtain the operation log of the main management node and replay several backup management nodes according to the content recorded in the log. The high water mark indicates that the current synchronization status of the distributed database is good. Replay can ensure that the backup management node performs the same operation as the main management node, improving consistency.

[0039] Sub-step 1013, determining whether the plurality of backup management nodes after playback have consistent copies;

[0040] Specifically, after the server completes replaying several backup management nodes of the distributed database, it can continue to determine whether the several backup management nodes after replay have consistent copies.

[0041] In a specific implementation, the high water mark indicates that the sum of metadata stored in several backup management nodes in the distributed database includes the metadata stored in the main management node. When switching is performed at the high water mark, the distributed database will not lose metadata.

[0042] In one example, if the water level information is lower than the high water level, the switching process is terminated. If the water level information of the distributed database is lower than the high water level, it means that the current synchronization state of the distributed database is poor, indicating that the metadata stored in the primary management node has metadata that is not stored in some backup management nodes in the distributed database. At this time, continuing to switch will cause metadata loss. Therefore, the switching process is terminated to prevent forced switching from causing the loss of distributed database metadata and causing business errors and unnecessary economic losses.

[0043] Step 102: If at least one standby management node has a consistent copy, a new primary management node is determined among the standby management nodes having the consistent copy;

[0044] Specifically, after the server determines that at least one backup management node has a consistent copy, it can determine a new primary management node among the backup management nodes with consistent copies. The new primary management node has a consistent copy, and using this node as the new primary management node can reduce the amount of data loss to 0. Correspondingly, the primary management node before determining the new primary management node can be called the original primary management node. That is to say, after the server determines that the original primary management node is abnormal, it can continue to determine whether several backup management nodes of the distributed database have consistent copies. If at least one backup management node has a consistent copy, the server can determine the new primary management node among the backup management nodes with consistent copies.

[0045] In one example, the distributed database is Figure 2 In the three-center distributed database shown, the main management node is management node 3. The server determines that the three backup management nodes, management node 4, management node 5 and management node 6, have consistent copies. The server can randomly select a backup management node from these three backup management nodes as the new main management node.

[0046] In another example, the server has a pre-stored master election priority, and the server can determine a new master management node from the backup management nodes with consistent replicas based on the master election priority. The pre-stored master election priority can be determined by a person skilled in the art according to actual needs, and the embodiments of the present invention do not specifically limit this.

[0047] For example: a distributed database is Figure 2In the three-center distributed database shown, the main management node is management node 3, and management node 4 is the backup management node in the same computer room as the main management node. The server determines that the three backup management nodes, management node 4, management node 5 and management node 6, have consistent copies, and the pre-stored master selection priority is greater than others in the same computer room. The server selects management node 4 as the new main management node.

[0048] In one example, after the server determines the new primary management node, it can call the new primary management node and pull metadata from each backup management node except the new primary management node to ensure zero data loss. The distributed database can be restored in time to ensure normal business operation and reduce enterprise losses.

[0049] Step 103: Switch the non-management node according to the new primary management node.

[0050] Specifically, after the server determines the new main management node, it can switch the non-management nodes according to the new main management node, wherein the non-management nodes include but are not limited to GTM and DB.

[0051] In one example, after the server determines the new main management node, it can automatically generate a non-management node switching instruction according to the new main management node, and switch the non-management node according to the non-management node switching instruction.

[0052] In another example, after the server determines the new main management node, it can instruct the operation and maintenance personnel to call the non-management node switching script, that is, instruct the operation and maintenance personnel to issue a non-management node switching instruction. After receiving the non-management node switching instruction issued by the operation and maintenance personnel, the non-management node is switched according to the non-management node switching instruction.

[0053] In the first embodiment of the present invention, if the main management node of the distributed database is abnormal, it is determined whether several backup management nodes of the distributed database have consistent copies; wherein, the distributed database includes management nodes and non-management nodes corresponding to the management nodes, and the management nodes include main management nodes and several backup management nodes. If the main management node is abnormal, it means that the main management node fails, and the distributed database cannot continue to be used, and enters the fault switching mode. If at least one backup management node has a consistent copy, a new main management node is determined among the backup management nodes with consistent copies. Because the new main management node has a consistent copy, the node is used as the new main management node, which can reduce the amount of data loss to 0, that is, metadata will not be lost after switching. According to the new main management node, the non-management node is switched, and the distributed database can be restored in time to make the distributed database run again. In the embodiment of the present invention, whether the backup management node has a consistent copy is considered during the switching process, which improves the logical rigor of the node switching process, makes the switching method more reasonable, and makes the switching operation simpler, so as to ensure that the distributed database does not lose data, thereby ensuring that various businesses can operate normally.

[0054] The second embodiment of the present invention relates to a node switching method. The implementation details of the node switching method of this embodiment are described in detail below. The following content is only for the convenience of understanding the implementation details, and is not necessary for implementing this solution. Figure 5 The node switching method according to the second embodiment of the present invention comprises:

[0055] Step 201, if the main management node of the distributed database is abnormal, determine whether several backup management nodes of the distributed database have consistent copies, if yes, execute step 205, otherwise, execute step 202;

[0056] Specifically, after determining that the main management node is abnormal, the server can continue to determine whether at least one backup management node has a consistent copy. If at least one backup management node has a consistent copy, execute step 205; if several backup management nodes do not have a consistent copy, execute step 202.

[0057] Step 202, determining the synchronization speed of a plurality of standby management nodes;

[0058] Specifically, after the server determines that none of the several standby management nodes has a consistent copy, the server can determine the synchronization speeds of the several standby management nodes.

[0059] In a specific implementation, the server can measure the synchronization speed of several backup management nodes according to the amount of metadata synchronized by the backup management nodes, that is, the backup management nodes with more synchronized metadata have a faster synchronization speed; and the backup management nodes with less synchronized metadata have a slower synchronization speed.

[0060] Step 203, determining a new primary management node according to the synchronization speeds of the plurality of backup management nodes;

[0061] Specifically, after the server determines the synchronization speeds of several backup management nodes, it can determine a new primary management node according to the synchronization speeds of the several backup management nodes. Determining a new primary management node according to the synchronization speeds of several backup management nodes can make the determined new primary management node more reasonable.

[0062] In an example, the server may select a backup management node with the fastest synchronization speed as the new primary management node based on the synchronization speeds of several backup management nodes.

[0063] In another example, the server may determine a new master management node according to the synchronization speeds of several backup management nodes and a preset master election priority.

[0064] Step 204: calling the new primary management node to pull metadata from each backup management node except the new primary management node;

[0065] Specifically, after the server determines the new primary management node, it can call the new primary management node and pull metadata from each backup management node except the new primary management node to ensure zero data loss. The distributed database can be restored in time to ensure normal business operation and reduce enterprise losses.

[0066] In the specific implementation, after determining the new primary management node, the server can determine whether there is metadata in the backup management nodes other than the new primary management node that the new primary management node does not have. If there is metadata in the backup management nodes other than the new primary management node that the new primary management node does not have, the server calls the new primary management node and pulls metadata from the backup management nodes other than the new primary management node to ensure that the new primary management node has complete metadata of the distributed database.

[0067] Step 205, determining a new primary management node among the backup management nodes having consistent copies;

[0068] Step 206: Switch the non-management node according to the new primary management node.

[0069] Among them, step 205 to step 206 have been explained in the first embodiment and will not be repeated here.

[0070] The second embodiment of the present invention, if the main management node of the distributed database is abnormal, after determining whether several backup management nodes of the distributed database have consistent copies, also includes: if several backup management nodes do not have consistent copies, determining the synchronization speed of several backup management nodes; determining a new main management node according to the synchronization speed of several backup management nodes, which can make the determined new main management node more reasonable, call the new main management node, and pull metadata from each backup management node except the new main management node to ensure that the data loss is zero, so that the distributed database can be restored in time, the normal operation of the business can be guaranteed, and the loss of the enterprise can be reduced.

[0071] The third embodiment of the present invention relates to a node switching method. The implementation details of the node switching method of this embodiment are specifically described below. The following content is only for the convenience of understanding the implementation details, and is not necessary for implementing this solution. Figure 6 is a schematic diagram of a node switching method according to a third embodiment of the present invention, comprising:

[0072] Step 301: if the main management node of the distributed database is abnormal, determine whether all backup management nodes in the same city as the main management node are abnormal. If yes, execute step 302; otherwise, execute step 304.

[0073] Specifically, a distributed database with multiple locations and multiple centers can be deployed in multiple computer rooms in multiple cities, and the backup management nodes include backup management nodes in the same city as the main management node and backup management nodes in different cities from the main management node. After determining that the main management node is abnormal, the server can continue to determine whether all backup management nodes in the same city as the main management node are abnormal.

[0074] In one example, the distributed database is Figure 7 The two-site four-center distributed database shown includes city A and city B. City A is equipped with computer room 1 and computer room 2, and city B is equipped with computer room 3 and computer room 4. Each computer room is equipped with two management nodes. Each management node corresponds to a GTM and two DBs. GTM and DB are non-management nodes. Assume that management node 8 in computer room 4 is the main management node, management node 5, management node 6 and management node 7 are backup management nodes in the same city as the main management node, and management node 1, management node 2, management node 3 and management node 4 are backup management nodes in different cities from the main management node.

[0075] Step 302, calling a preset cross-city switching script;

[0076] Specifically, after determining that all backup management nodes in the same city as the main management node are abnormal, the server can call a preset different-city switching script, wherein the different-city switching script is used to switch the main management node to a city different from the main management node.

[0077] In a specific implementation, the reasons that cause all backup management nodes in the same city as the primary management node to be abnormal may include, but are not limited to: power outage in the city of the primary management node and network disconnection in the city of the primary management node.

[0078] In one example, a preset inter-city switching script can be pre-stored in the server by a technician in this field. After the server determines that the backup management nodes in the same city as the main management node are abnormal, it can instruct the operation and maintenance personnel to call the preset inter-city switching script and enter the fault inter-city switching mode.

[0079] Step 303, according to the preset cross-city switching script, determine a new main management node from the backup management nodes in a different city from the main management node;

[0080] Specifically, after calling the preset cross-city switching script, the server can determine the new main management node from the backup management node in a different city from the main management node according to the preset cross-city switching script. Switching the main management node to a different city through the cross-city switching script can further improve the disaster recovery capability of the distributed database, ensure the normal operation of the business, and reduce the loss of the enterprise.

[0081] In one example, the cross-city switching script may include a specified city. For example, the distributed database is a distributed database with three centers in three locations, the main management node is management node 1 in city A, and the backup management nodes are management node 2 in city A, management node 3 and management node 4 in city B, and management node 5 and management node 6 in city C. Now all the management nodes in city A are unavailable, and the cross-city switching script specifies that the main management node is switched to city C. The server selects one from management node 5 and management node 6 in city C as the new main management node according to the cross-city switching script.

[0082] In another example, the cross-city switching script may include a specified computer room ID. Figure 7 In the two-site four-center distributed database shown, the main management node is management node 3 in computer room 2 in city A. Now all management nodes in city A are unavailable. The cross-city switching script specifies that the main management node will be switched to computer room 4 in city B. According to the cross-city switching script, the server selects one from management node 7 and management node 8 in computer room 4 in city B as the new main management node.

[0083] Step 304, determine whether the backup management node in the same city as the primary management node has a consistent copy; if yes, execute step 305, otherwise, end directly;

[0084] Among them, step 304 has been similarly described in the first embodiment and will not be repeated here.

[0085] Step 305, determining a new primary management node from the backup management nodes that have consistent copies and are in the same city as the primary management node;

[0086] Specifically, after the server determines that there is at least one backup management node in the same city as the primary management node with a consistent copy, it can determine a new primary management node from the backup management nodes in the same city as the primary management node that have a consistent copy. When a backup management node in the same city as the primary management node is available, the primary management node will be switched to the same city, which can effectively save switching time and ensure business continuity.

[0087] In one example, the distributed database is Figure 7 In the two-site four-center distributed database shown, the main management node is management node 3 in computer room 2 in city A. All backup management nodes in city A are available, and the server can select one from management node 1, management node 2 and management node 4 as the new main management node.

[0088] Step 306, switching the non-management node according to the new primary management node;

[0089] Specifically, after the server determines the new main management node, it can switch the non-management nodes according to the new main management node, wherein the non-management nodes include but are not limited to GTM and DB.

[0090] In one example, according to the new primary management node, switching the non-management node can be performed as follows: Figure 8 The implementation of each sub-step shown is as follows:

[0091] Sub-step 3061, disabling the connection instance of the distributed database;

[0092] Specifically, after the server determines the new main management node, it can disable the connection instance of the distributed database. Considering that after the main management node is abnormal, there is a possibility that the business in another city will continue to be processed, disabling the connection instance of the distributed database in time can prevent data confusion.

[0093] Sub-step 3062, obtaining the time of data consistency of the distributed database according to the metadata information of the new primary management node;

[0094] Specifically, after disabling the connection instance of the distributed database, the server can obtain the time of data consistency of the distributed database according to the metadata information of the new primary management node.

[0095] In one example, the server may determine that the moment when an abnormality occurs in the main management node is the moment when the data consistency of the distributed database is achieved.

[0096] In another example, the server may check the data of each non-management node, and obtain the time of data consistency of the distributed database according to the metadata information of the new master management node and the data of each non-management node.

[0097] Sub-step 3063, rolling back the non-management node corresponding to the new primary management node to the time when data consistency is achieved;

[0098] In the specific implementation, after the server obtains the moment of data consistency of the distributed database, it can roll back the non-management node corresponding to the new primary management node to the moment of data consistency, that is, the data of the non-management node corresponding to the new primary management node is made consistent with the data of the non-management node corresponding to the primary management node, thereby ensuring the consistency of the distributed database business data and preventing data confusion and errors.

[0099] Sub-step 3064, switching the non-management node corresponding to the primary management node to the non-management node corresponding to the new primary management node after the rollback;

[0100] Specifically, after rolling back the non-management node corresponding to the new primary management node to the time of data consistency, the server may switch the non-management node corresponding to the primary management node to the non-management node corresponding to the new primary management node after the rollback.

[0101] In a specific implementation, the server may set the GTM corresponding to the new primary management node as the new primary GTM, and set the data node corresponding to the new primary management node as the new primary data node.

[0102] Sub-step 3065, enabling the connection instance of the distributed database.

[0103] Specifically, after the server switches the non-management node corresponding to the primary management node to the non-management node corresponding to the new primary management node after the rollback, the server can re-enable the connection instance of the distributed database to make the database run again.

[0104] In the third embodiment of the present invention, the backup management node includes a backup management node in the same city as the main management node and a backup management node in a different city from the main management node; if at least one backup management node has a consistent copy, a new main management node is determined in the backup management node with a consistent copy, including: if at least one backup management node in the same city as the main management node has a consistent copy, a new main management node is determined in the backup management node with a consistent copy and in the same city as the main management node, which can effectively save switching time and ensure business continuity. If the main management node of the distributed database is abnormal, before judging whether several backup management nodes of the distributed database have consistent copies, it also includes: if the main management node and the backup management node in the same city as the main management node are both abnormal, calling a preset different city switching script; according to the preset different city switching script, a new main management node is determined in the backup management node in a different city from the main management node, even if the backup management nodes in the same city as the main management node are unavailable, the main management node can be switched to a different city through the different city switching script, further improving the disaster recovery capability of the distributed database, ensuring the normal operation of the business, and reducing the loss of the enterprise. According to the new main management node, the non-management node is switched, including: disabling the connection instance of the distributed database; obtaining the time of data consistency of the distributed database according to the metadata information of the new main management node; rolling back the non-management node corresponding to the new main management node to the time of data consistency; switching the non-management node corresponding to the main management node to the non-management node corresponding to the new main management node after the rollback; enabling the connection instance of the distributed database, which can ensure the consistency of the distributed database business data and prevent data confusion and errors.

[0105] The fourth embodiment of the present invention relates to a node switching method. The implementation details of the node switching method of this embodiment are specifically described below. The following content is only for the convenience of understanding the implementation details, and is not necessary for implementing this solution. Fig. 9 is a schematic diagram of a node switching method according to a fourth embodiment of the present invention, comprising:

[0106] Step 401, after receiving the node drill switching information, determine whether the main management node of the distributed database is normal, if yes, execute step 402, otherwise, directly end;

[0107] Specifically, the server can receive the node rehearsal switching information input by the operation and maintenance personnel in real time. After receiving the node rehearsal switching information, the server can determine whether the main management node of the distributed database is normal. If the main management node of the distributed database is normal, execute step 402. If the main management node of the distributed database is abnormal, the rehearsal switching cannot be performed and ends directly.

[0108] Step 402, calling a preset drill switching script;

[0109] Specifically, after the server completes synchronization of several backup management nodes, it can call a preset drill switching script, wherein the drill script is used to drill switching of the main management node.

[0110] In one example, a preset drill switching script may be pre-stored in a server by a person skilled in the art. After the server completes synchronization of several standby management nodes, the operation and maintenance personnel may be instructed to call the preset drill switching script.

[0111] Step 403, according to the drill switching script, deactivate the main management node and synchronize several backup management nodes of the distributed database;

[0112] Specifically, the server can deactivate the main management node according to the drill switching script and synchronize several backup management nodes of the distributed database. Timely deactivation of the main management node can prevent business confusion, because the main management node is normal, the master-slave relationship is normal, and normal synchronization can be performed to ensure data consistency.

[0113] Step 404, determining a new primary management node among the synchronized backup management nodes;

[0114] Specifically, the server can determine the new primary management node from the synchronized backup management nodes. Performing a drill switch can test the disaster recovery capability of the distributed database so that technical personnel can make timely adjustments and maintenance, further improving the disaster recovery capability of the distributed database.

[0115] In one example, the drill switching script may include a specified city. For example, the distributed database is a distributed database with three centers in three locations, the main management node is management node 1 in city A, and the backup management nodes are management node 2 in city A, management node 3 and management node 4 in city B, and management node 5 and management node 6 in city C. The drill switching script specifies that the main management node is switched to city C, and the server selects one of management node 5 and management node 6 in city C as the new main management node according to the drill switching script.

[0116] In another example, the drill switching script may include a specified computer room ID. Figure 7 In the two-site four-center distributed database shown, the main management node is management node 3 in computer room 2 in city A. The drill switching script specifies that the main management node will be switched to computer room 4 in city B. According to the drill switching script, the server selects one from management node 7 and management node 8 in computer room 4 in city B as the new main management node.

[0117] Step 405, disabling the connection instance of the distributed database;

[0118] Step 406, obtaining the time of data consistency of the distributed database according to the metadata information of the new primary management node;

[0119] Step 407, rolling back the non-management node corresponding to the new primary management node to the time of data consistency;

[0120] Step 408: Switch the non-management node corresponding to the primary management node to the non-management node corresponding to the new primary management node after the rollback;

[0121] Step 409: Enable the connection instance of the distributed database.

[0122] Among them, steps 405 to 409 have been similarly described in the third embodiment and will not be repeated here.

[0123] The fourth embodiment of the present invention, after receiving the rehearsal switching information of the node, determines whether the main management node of the distributed database is normal; if the main management node is normal, calls a preset rehearsal switching script; according to the preset rehearsal switching script, disables the main management node, and synchronizes several backup management nodes of the distributed database; determines a new main management node among the several synchronized backup management nodes, which can verify the disaster recovery capability of the distributed database, so that technical personnel can make adjustments and maintenance in time, and further improve the disaster recovery capability of the distributed database.

[0124] In one example, this embodiment provides four switching modes, including: automatic switching in the same city when a fault occurs, switching in the same city when a drill occurs, switching in a different city when a fault occurs, and switching in a different city when a drill occurs. Each switching mode uses a hierarchical switching method for management nodes and non-management nodes, which greatly reduces the coupling between components and avoids the overall switching failure caused by the failure of a component to switch.

[0125] The specific implementation method of failure switching in the same city can be as follows Fig.10 As shown, the details are as follows:

[0126] Step 501, determine whether the distributed database is at a high water level, if yes, execute step 502, otherwise, end the fault intra-city switching;

[0127] Specifically, after the server determines that it has entered the fault intra-city switch, it can determine whether the distributed database is at a high water level. A high water level means that the distributed database is currently in a good synchronization state and the switch will not lose data.

[0128] Step 502, waiting for each standby management node to complete playback;

[0129] Specifically, after determining that the distributed database is at a high water mark, the server can replay each backup management node and wait for the replay of each management node to complete;

[0130] Step 503, determine whether at least one standby management node participating in the master election has a consistent copy, if yes, execute step 506, otherwise, execute step 504;

[0131] Specifically, in the same-city failover mode, each backup management node in the same city as the primary management node participates in the primary election, and the backup management nodes in different cities from the primary management node do not participate in the primary election. The server can determine whether at least one backup management node participating in the primary election has a consistent copy;

[0132] Step 504: Select the standby management node with the fastest synchronization speed and the highest master selection priority as the new master management node;

[0133] Specifically, after the server determines that none of the backup management nodes participating in the master election have consistent copies, it can select the backup management node with the fastest synchronization speed and the highest master election priority as the new master management node, where each backup management node corresponds to a preset master election priority, and the master election priority can be set by technical personnel in this field according to actual needs when building a distributed database.

[0134] In a specific implementation, the server may determine the synchronization speed of each standby management node according to the amount of metadata that has been synchronized by each standby management node.

[0135] Step 505: calling the new primary management node to pull metadata from the backup management nodes except the new primary management node;

[0136] Specifically, the server can call the new primary management node and pull metadata from the backup management nodes except the new primary management node to ensure that the metadata of the new primary management node is maximized.

[0137] Step 506: Select a backup management node with a consistent copy and the highest master selection priority as the new master management node;

[0138] Specifically, after the server determines that at least one backup management node participating in the master election has a consistent copy, it can select the backup management node with a consistent copy and the highest master election priority as the new master management node, where each backup management node corresponds to a preset master election priority, and the master election priority can be set by technical personnel in this field according to actual needs when building a distributed database.

[0139] Step 507, starting a new master management node and reestablishing the master-slave relationship between the management nodes;

[0140] Specifically, after the server determines the new primary management node, it can activate the new primary management node and rebuild the primary-backup relationship between the management nodes.

[0141] Step 508: Control the automatic switching of GTM and DB according to the new primary management node.

[0142] Specifically, the server can control the automatic switching of GTM and DB according to the new primary management node.

[0143] Among them, step 501 to step 507 are the management node switching process, and step 508 is the non-management node switching process.

[0144] The specific implementation method of the drill switching (including the same-city drill switching and the different-city drill switching) can be as follows: Fig.11 As shown, the details are as follows:

[0145] Step 601, determine whether the distributed data master-slave relationship is normal, if so, execute step 602, otherwise, end the drill switching process;

[0146] Specifically, when the master-slave relationship of distributed data is normal, a drill switch can be performed. If the master-slave relationship of distributed data is abnormal, it means that the main management node has a fault, and the fault same-city switch mode or the fault different-city switch mode is entered.

[0147] Step 602, deactivate the main management node and wait for the synchronization of the backup management nodes to be completed;

[0148] Specifically, when the server determines that the master-slave relationship of the distributed database is normal, it can deactivate the master management node and wait for the synchronization of the backup management nodes to be completed. Since the master management node is normal, the server can synchronize the backup management nodes.

[0149] Step 603: According to the specified computer room ID, select the standby management node with the highest master election priority from the standby management nodes participating in the master election as the new master management node;

[0150] Specifically, after determining that synchronization of each backup management node is complete, the server can select a backup management node with the highest master election priority from the backup management nodes participating in the master election as the new master management node according to the specified computer room ID.

[0151] Step 604, starting a new master management node and reestablishing the master-slave relationship between the management nodes;

[0152] Specifically, after the server determines the new primary management node, it can activate the new primary management node and rebuild the primary-backup relationship between the management nodes.

[0153] Step 605, disabling the connection instance of the distributed database;

[0154] Specifically, after rebuilding the master-slave relationship between management nodes, the server can disable the connection instance of the distributed database, suspend the business in time, and prevent data confusion.

[0155] Step 606, switching the GTM and data nodes to the designated computer room;

[0156] Specifically, after disabling the connection instance of the distributed database, the server can switch the GTM and data nodes to the designated computer room, that is, switch to the GTM and data nodes corresponding to the new primary management node.

[0157] Step 607, re-enable the connection instance.

[0158] Specifically, after switching the GTM and data nodes to the designated computer room, the server can re-enable the connection instance and resume business.

[0159] Among them, step 601 to step 604 is a management node switching process, and step 605 to step 607 is a non-management node switching process.

[0160] The specific implementation method of cross-city fault switching can be as follows: Fig.12 As shown, specifically including:

[0161] Step 701, waiting for each standby management node to complete playback;

[0162] Among them, step 701 is similar to step 504 of the fault same-city switching mode and will not be repeated here.

[0163] Step 702: According to the specified computer room ID, select the standby management node with the highest master election priority from the standby management nodes participating in the master election as the new master management node;

[0164] Specifically, after the server determines that the playback of each backup management node is completed, it can select the backup management node with the highest master election priority among the backup management nodes participating in the master election as the new master management node according to the specified computer room ID. Among them, in the fault switching mode in different cities, the backup management node in the same city as the main management node is abnormal and will not participate in the election, while the backup management node in a different city from the main management node will participate in the election.

[0165] Step 703: calling the new primary management node to pull metadata from the backup management nodes except the new primary management node;

[0166] Specifically, the server can call the new primary management node and pull metadata from the backup management nodes except the new primary management node to ensure that the metadata of the new primary management node is maximized.

[0167] Step 704, starting a new master management node and reestablishing the master-slave relationship between the management nodes;

[0168] Specifically, after the server determines the new primary management node, it can activate the new primary management node and rebuild the primary-backup relationship between the management nodes.

[0169] Step 705, disabling the connection instance of the distributed database;

[0170] Specifically, after rebuilding the master-slave relationship between management nodes, the server can disable the connection instance of the distributed database, suspend the business in time, and prevent data confusion.

[0171] Step 706, obtaining metadata information of the cluster;

[0172] Specifically, after the server disables the connection instance of the distributed database, it can obtain metadata information of the cluster, that is, obtain metadata information of the new primary management node. Obtaining the metadata information can determine the moment of data consistency.

[0173] Step 707, rolling back the cluster to the data consistency moment;

[0174] Specifically, after obtaining the metadata information of the cluster, the server can roll back the cluster to the data consistency moment, that is, roll back the non-management nodes corresponding to the new primary management node to the data consistency moment to make the business data consistent.

[0175] Step 708, switching the remote GTM to the primary GTM, and the remote data node to the primary data node;

[0176] Specifically, after the server rolls back the cluster to the data consistency moment, the remote GTM can be switched to the primary GTM and the remote data node can be switched to the primary data node.

[0177] Step 709: re-enable the connection instance.

[0178] Specifically, after the server switches the remote GTM to the primary GTM and the remote data node to the primary data node, the connection instance can be re-enabled to resume business.

[0179] Among them, step 701 to step 704 is a management node switching process, and step 705 to step 709 is a non-management node switching process.

[0180] Compared with related technologies, the node switching method providing the above four switching modes has the following advantages:

[0181] (1) The environment is simple and convenient to set up. The traditional HA environment requires IPs in the same network segment to be active and standby, and requires the configuration of DNS servers, etc. The Zookeeper environment is simpler to set up and has lower requirements for servers. You only need to install the Zookeeper node on the corresponding server.

[0182] (2) The master election strategy has strict logic. During the master election process, the management node’s master election priority, data synchronization status, election attributes (such as local is greater than local is greater than other cities), and distributed database water level information are comprehensively considered to ensure that management node data is not lost to the greatest extent possible.

[0183] (3) The switching modes are diverse and customizable. Users can use this solution not only to implement emergency switching and repair of the environment in the event of a failure, but also to conduct a switch drill when all components are operating normally, so as to examine the business processing capabilities of the backup room and evaluate the operating status of each component in the backup room.

[0184] (4) Reasonable switching method. In various switching modes of this solution, the management node and non-management node are switched in layers, which greatly reduces the coupling between components and avoids the overall switching failure caused by the failure of a certain component to switch.

[0185] (5) The switching operation is simple and the switching script can be re-entered. Whether it is a disaster recovery switch or a drill switch, the entire operation process only requires calling the script and entering a command to complete the switch of the entire computer room. If the switch fails due to a faulty node during the switch process, the same switch command can be entered after the faulty node is repaired to initiate the switch again.

[0186] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0187] A fifth embodiment of the present invention relates to an electronic device, such as Fig.13 As shown, it includes: at least one processor 801; and a memory 802 that is communicatively connected to the at least one processor 801; wherein the memory 802 stores instructions that can be executed by the at least one processor 801, and the instructions are executed by the at least one processor 801 so that the at least one processor 801 can execute the node switching method in the above-mentioned embodiments.

[0188] Among them, the memory and the processor are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and memories together. The bus can also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor.

[0189] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory can be used to store data used by the processor when performing operations.

[0190] The sixth embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0191] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0192] Those skilled in the art will appreciate that the above-mentioned embodiments are specific examples for implementing the present invention, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A node switching method, characterized in that: include: If the main management node of the distributed database is abnormal, determine whether several backup management nodes of the distributed database have consistent copies; wherein the distributed database includes a management node and non-management nodes corresponding to the management node, and the management node includes a main management node and several backup management nodes; If at least one standby management node has the consistent copy, determining a new primary management node among the standby management nodes having the consistent copy; According to the new primary management node, switching the non-management node; If the main management node of the distributed database is abnormal, after determining whether the plurality of backup management nodes of the distributed database have consistent copies, the method further includes: If none of the plurality of standby management nodes has the consistent replica, determining synchronization speeds of the plurality of standby management nodes; Determining a new primary management node according to the synchronization speeds of the plurality of backup management nodes; If the main management node of the distributed database is abnormal, determining whether several backup management nodes of the distributed database have consistent copies includes: If the main management node of the distributed database is abnormal, obtaining the water level information of the distributed database; If the water level information is a high water level, replaying the several backup management nodes of the distributed database; wherein the high water level is used to indicate that the sum of the metadata stored by the several backup management nodes in the distributed database includes the metadata stored by the main management node; Determine whether several backup management nodes have consistent copies after playback.

2. The node switching method according to claim 1, characterized in that: After the new primary management node is determined, the method further includes: The new primary management node is called to pull metadata from each backup management node except the new primary management node.

3. The node switching method according to claim 1, characterized in that: The standby management nodes include standby management nodes in the same city as the main management node and standby management nodes in different cities from the main management node; If at least one standby management node has the consistent copy, determining a new primary management node among the standby management nodes having the consistent copy includes: If at least one backup management node in the same city as the primary management node has the consistent copy, a new primary management node is determined from the backup management nodes in the same city as the primary management node that have the consistent copy.

4. The node switching method according to claim 3, characterized in that: If the main management node of the distributed database is abnormal, before determining whether the plurality of backup management nodes of the distributed database have consistent copies, the method further includes: If both the main management node and the backup management node in the same city as the main management node are abnormal, calling a preset cross-city switching script; According to the preset cross-city switching script, a new main management node is determined among the backup management nodes in a different city from the main management node.

5. The node switching method according to claim 4, characterized in that: The switching of the non-management node according to the new primary management node includes: disabling a connection instance of the distributed database; Acquire the time of data consistency of the distributed database according to the metadata information of the new primary management node; Rolling back the non-management node corresponding to the new primary management node to the time of data consistency; Switching the non-management node corresponding to the primary management node to the non-management node corresponding to the new primary management node after the rollback; Enables a connection instance of the distributed database.

6. The node switching method according to claim 1, characterized in that: The method further comprises: After receiving the node's drill switching information, determine whether the main management node of the distributed database is normal; If the main management node is normal, call the preset drill switching script; According to the preset drill switching script, the main management node is deactivated, and several backup management nodes of the distributed database are synchronized; A new primary management node is determined among the synchronized backup management nodes.

7. The node switching method according to any one of claims 1 to 6, characterized in that: The distributed database is built with a distributed service framework, and the distributed service framework is zookeeper.

8. An electronic device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the node switching method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the node switching method according to any one of claims 1 to 7 is implemented.

Images