Database system, distributed cluster, fault processing method and related products

Abstract

The invention provides a database system, a distributed cluster, a fault processing method and related products. The database system comprises a recovery process and a database process deployed in each node; wherein the recovery process is used for carrying out fault processing and virtual internet protocol address redistribution when a node has a fault; and the database process is used for performing database recovery when one node has a fault. Through the embodiment of the invention, the operations of fault processing, virtual internet protocol address redistribution and database recovery can be performed in parallel, so that the fault processing time is shortened, and the influence on front-end services during faults is reduced. The problem that the service cutoff time is long due to the fact that the fault switching time is long in an existing distributed cluster is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of fault handling, and in particular to a database system, a distributed cluster, a fault handling method, a computer program product, an electronic device and a non-volatile computer-readable storage medium. Background Art

[0002] In a distributed cluster, there are often many services running. In the actual environment, some unexpected situations often occur, such as network fluctuations, service crashes, etc., causing service unavailability.

[0003] In actual applications, CTDB (Cluster Trivial Database) can monitor the running status of distributed cluster services. In the event of service failure, it can detect and start the service within a 5-second detection cycle. At the same time, it will also monitor the status of the cluster's network card. When the network is abnormal, it will also handle it accordingly to reduce the impact of network problems on cluster performance and business. However, in the existing CTDB, there are still problems such as slow fault handling that need to be solved. Summary of the invention

[0004] In view of the above problems, a database system, a distributed cluster, a fault handling method, a computer program product, an electronic device and a non-volatile computer-readable storage medium are proposed to overcome the above problems or at least partially solve the above problems, including:

[0005] A database system is applied in a distributed cluster, the distributed cluster includes multiple nodes, and the database system includes a recovery process and a database process deployed in each node; wherein:

[0006] The recovery process is used to perform fault handling and virtual Internet Protocol address reallocation when a node fails;

[0007] The database process is used to recover the database when a node fails.

[0008] Optionally, the database process is further used to receive a target request for a database and respond to the target request.

[0009] Optionally, the database process is further used to create a local socket domain in the node to which it belongs, so as to monitor requests initiated by other services for the database.

[0010] Optionally, the database process is used to respond to the target request for the database and send result information corresponding to the target request to the service that initiates the target request.

[0011] Optionally, the database system further includes a main process deployed in each node;

[0012] The main process is used for the node to establish a connection with other nodes and receive the first heartbeat information sent by the other nodes; and determine the status of the other nodes according to the first heartbeat information;

[0013] The recovery process is used to determine whether the other nodes have faults according to the status of the other nodes determined in the main process.

[0014] Optionally, the database process is also used for the node to establish a connection with the database process of other nodes, and receive second heartbeat information sent by the database process of other nodes; and determine the status of the other nodes according to the second heartbeat information.

[0015] Optionally, the database process is used to lock the cluster of the distributed cluster; if the cluster locking of the distributed cluster is successful, the database is restored and other nodes are notified to perform database restoration.

[0016] Optionally, the database process is further used to perform database recovery upon receiving a database recovery request sent by the other node if cluster locking of the distributed cluster fails.

[0017] Optionally, the database process is further used to create a monitoring event daemon process, and detect through the monitoring event daemon process whether a node to which the database process belongs fails.

[0018] Optionally, the database process is further used to exit the monitoring event daemon process after determining whether the node to which it belongs fails.

[0019] Optionally, the database process is further configured to mark the node as failed when it is detected that the node fails.

[0020] Optionally, the database process is also used to modify the status of other nodes.

[0021] Optionally, the distributed cluster further includes an object storage daemon;

[0022] The recovery process is used to mark the failed node as failed in the object storage daemon process.

[0023] Optionally, the database system further includes:

[0024] The event daemon process is used to receive and execute instructions sent by the main process.

[0025] Optionally, the main process is also used to create the event daemon process, the recovery process and the database process.

[0026] An embodiment of the present invention further provides a distributed cluster, which includes the database system as described above and multiple nodes.

[0027] The embodiment of the present invention further provides a fault handling method, which is applied to the recovery process of the database system as described above, and the method includes:

[0028] The recovery process performs fault handling and virtual Internet Protocol address reallocation when a node fails; wherein the database process of the database system performs database recovery when a node fails.

[0029] The embodiment of the present invention further provides a fault handling method, which is applied to the database process of the database system as described above, and the method includes:

[0030] The database process is used to recover the database when a node fails; wherein the recovery process of the database system performs fault processing and reallocation of virtual Internet Protocol addresses when a node fails.

[0031] An embodiment of the present invention further provides a computer program product, including computer instructions, which implement the fault handling method as described above when executed by a processor.

[0032] An embodiment of the present invention further provides an electronic device, comprising a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program implements the fault handling method as described above when executed by the processor.

[0033] An embodiment of the present invention further provides a non-volatile computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the fault handling method described above is implemented.

[0034] In an embodiment of the present invention, the database system includes a recovery process and a database process deployed in each node; wherein: the recovery process is used to perform fault handling and virtual Internet Protocol address reallocation when a node fails; the database process is used to perform database recovery when a node fails. Through the embodiment of the present invention, the operations of fault handling, virtual Internet Protocol address reallocation and database recovery can be performed in parallel, thereby reducing the fault handling time and reducing the impact of the fault on the front-end business. The problem of long fault switching time and long service interruption time caused by the existing distributed cluster is solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solution of the present invention, the accompanying drawings required for use in the description of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0036] Figure 1 It is a structural diagram of a cluster trivial database in the prior art;

[0037] Figure 2a is a schematic diagram of the structure of a database system according to an embodiment of the present invention;

[0038] Figure 2b It is a partial structural diagram of a database system according to an embodiment of the present invention;

[0039] Figure 2c is a schematic diagram of the structure of another database system according to an embodiment of the present invention;

[0040] Figure 3 is a flowchart of a method for troubleshooting according to an embodiment of the present invention;

[0041] Figure 4 is a flowchart of another fault handling method according to an embodiment of the present invention;

[0042] Figure 5 is a schematic diagram of the structure of a computer program product according to an embodiment of the present invention;

[0043] Figure 6 is a schematic structural diagram of an electronic device according to an embodiment of the present invention;

[0044] Figure 7 It is a structural schematic diagram of a non-volatile computer-readable storage medium according to an embodiment of the present invention. DETAILED DESCRIPTION

[0045] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0046] like Figure 1 As shown, in the existing mechanism of CTDB, three processes are created during the startup of CTDB, namely, the main process 120, the event daemon process 110 and the recovery process 130.

[0047] The main process 120 is mainly responsible for establishing a TCP (Transmission Control Protocol) connection between the node to which it belongs (node[i]) and other nodes (node[j]) to monitor requests from other nodes; in addition, the main process 120 can also create a local domain to monitor requests from local client processes (including SMBD (Server Message Block Daemon), cluster simple database daemon, recovery process 130, and execute CTDB commands), heartbeat detection between nodes, etc.

[0048] The event daemon process 110 mainly executes corresponding events according to the messages sent by the main process 120; for example, periodically executing network card status monitoring events, monitoring service status, etc., and passing the results to the main process 120.

[0049] The recovery process 130 is mainly responsible for monitoring the operation status of the cluster, database recovery and the allocation of virtual Internet Protocol addresses. The recovery process 130 mainly obtains information about other nodes by sending information for obtaining the status of other nodes to the main process 120 of the node to which it belongs. At the same time, the recovery process 130 can also receive and process messages sent by other nodes received by the main process 120.

[0050] The recovery process 130 of the main node of CTDB first obtains the status information of other nodes. When a node failure is detected, it needs to send a recovery request to other nodes through the main process 120. The recovery process 130 needs to perform a failover first, and needs to restore the database by notifying other nodes and receive a message that the database recovery is complete.

[0051] Then, the virtual Internet Protocol address reallocation process is carried out, and each node releases the virtual Internet Protocol address that has been obtained and obtains the newly allocated virtual Internet Protocol address.

[0052] When the master node detects a node failure in the cluster, it will first perform a failover process, set the OSD and other services of the failed node to down, and then perform database recovery. Database recovery is usually a time-consuming process. After the database recovery is completed, it is necessary to reallocate the virtual Internet Protocol address and switch the business IP (Internet Protocol) address to a new node to reduce the time of business interruption caused by the failure. Therefore, the failover time of CTDB directly affects the recovery time of the business.

[0053] In order to reduce the time consumption of business recovery, an embodiment of the present invention provides a new database system, which can be applied to a distributed cluster; in practical applications, the distributed cluster may include multiple nodes, and the database system includes a recovery process and a database process deployed in each node. Specifically, a node is deployed with a recovery process and a database process.

[0054] In the embodiment of the present invention, the CTDB service is split out of the database process, which is used to process database-related processes separately. The database recovery process in the original CTDB cluster, which is serially executed by the recovery process, including fault handling, database recovery, and virtual Internet Protocol address reallocation, is handed over to the database process for execution, and the other processes are handled by the recovery process. By using parallel processing, the fault handling time can be reduced, thereby reducing the impact of the fault on the front-end business. This solves the problem of long fault switching time and long service interruption time in existing distributed clusters. For details, please refer to Figure 2a , Figure 2a A schematic diagram of the structure of a database system according to an embodiment of the present invention is shown.

[0055] like Figure 2a As shown, the database system may include a recovery process 210 and a database process 220 deployed in each node 30; wherein:

[0056] A recovery process 210, for performing fault handling and virtual Internet Protocol address reallocation when a node 30 fails;

[0057] The database process 220 is used to recover the database when a node 30 fails.

[0058] In practical applications, each node 30 in the distributed cluster may be deployed with a recovery process 210 and a database process 220. The recovery process 210 may be used to perform global fault handling and global virtual Internet Protocol address reallocation for a node 30 in the distributed cluster when a node 30 fails.

[0059] Exemplarily, fault handling may refer to the process in which the recovery process 210 marks the faulty node 30 as down in the object storage daemon; after marking the faulty node 30 as down in the object storage daemon, subsequent calls to the node 30 may be avoided.

[0060] Virtual Internet Protocol address reallocation may refer to a process of reallocating a virtual Internet Protocol address; specifically, it may refer to a process of allocating a virtual Internet Protocol address allocated to a failed node 30 to other nodes 30 .

[0061] In actual applications, in order to reduce the fault processing time, a database process 220 may be additionally set in the database system to perform the database recovery step; specifically, the database process may be deployed in each node 30 of the distributed cluster.

[0062] When a node 30 is detected to have a fault, the database processes 220 in each node 30 can work together to complete the database recovery operation; specifically, when the database process 220 detects that a node 30 has a fault, it can first use the redis lock to lock the cluster. If the lock is successful, the database process 220 will recover the database by itself and notify the database processes 220 of other nodes 30 to recover the database.

[0063] In an embodiment of the present invention, the database system includes a recovery process and a database process deployed in each node; wherein: the recovery process is used to perform fault processing and virtual Internet Protocol address reallocation when a node fails; the database process is used to perform database recovery when a node fails. Through the embodiment of the present invention, the operations of fault processing, virtual Internet Protocol address reallocation and database recovery can be performed in parallel, thereby reducing the fault processing time and reducing the impact of the fault on the front-end business. The problem of long fault switching time and long service interruption time in the existing distributed cluster is solved.

[0064] In one embodiment of the present invention, Figure 2b As shown, the database process 220 is also used to receive target requests for the database and respond to the target requests.

[0065] In some feasible embodiments, the database in the distributed cluster is only used for internal use and cannot be provided to the third-party service 40; in this regard, in an embodiment of the present invention, the database process 220 can also be assigned to handle the target request of the third-party service 40 to the database.

[0066] Specifically, the database can be set in a distributed cluster, and the database process 220 can be used to receive target requests for the database from the third-party service 40; the target request can refer to a request for obtaining data in the database, or it can be other requests for processing data in the database, etc., and the embodiments of the present invention are not limited to this.

[0067] After receiving the target request, the database process 220 may respond to the target request based on the data in the database and perform corresponding operations.

[0068] In an embodiment of the present invention, the database process 220 may also be used to create a local socket domain in the node 30 to which it belongs, so as to monitor requests for the database initiated by other services.

[0069] In some feasible embodiments, the database process 220 may also create a local socket domain in the node 30 to which it belongs, so as to monitor relevant requests initiated by the third-party service 40 for the database, and perform corresponding operations in response to the request.

[0070] The creation of a local socket domain refers to creating a communication endpoint using a local socket (Unix domain socket or Unix socket) in the node 30 where the database process 220 is deployed. A local socket is a mechanism for inter-process communication (IPC) on the same machine, which uses a file system path name to identify a communication endpoint instead of a network address and port number.

[0071] In one embodiment of the present invention, the database process 220 may be used to respond to a target request for the database and send result information corresponding to the target request to the service that initiated the target request.

[0072] In actual applications, after receiving a target request for a database, the database process 220 can perform corresponding operations in response to the target request; specifically, the database process 220 can generate corresponding result information based on the data in the database in response to the target request; then, the result information corresponding to the target request is sent to the third-party service 40 that initiated the target request; the result information may include data in the database corresponding to the target request, which is not limited in this embodiment of the present invention.

[0073] In one embodiment of the present invention, Figure 2c As shown, the database system also includes a main process 230 deployed in each node 30;

[0074] The main process 230 is used for the node to establish a connection with other nodes and receive the first heartbeat information sent by other nodes; determine the status of other nodes according to the first heartbeat information;

[0075] The recovery process 210 is used to determine whether other nodes 30 have faults according to the status of other nodes 30 determined in the main process 230.

[0076] In actual applications, the database system may also include a main process 230 deployed in each node 30, and the main processes 230 may establish connections with each other so as to establish connections between different nodes 30; the main process 230 may be used to receive the first heartbeat information of other nodes 30 (i.e., nodes 30 other than the node 30 to which it belongs in the distributed cluster), and determine the status of other nodes 30 based on the first heartbeat information; that is, determine whether other nodes 30 have faults.

[0077] Exemplarily, if the first heartbeat information sent by other nodes 30 is not received within a preset time period, it can be determined that the other node 30 has a fault; at this time, the main process 230 can set the state of the other node 30 to a faulty state.

[0078] In actual applications, the recovery process 210 can obtain the status of other nodes 30 from the main process 230 of the node 30 to which it belongs, and use it to determine whether there are faults in other nodes 30; if the recovery process 210 determines that there are faults in other nodes 30, fault processing and virtual Internet Protocol address reallocation can be performed.

[0079] In one embodiment of the present invention, the database process 220 can also be used for the node 30 to establish a connection with the database process 220 of other nodes 30, and receive the second heartbeat information sent by the database process 220 of other nodes 30; determine the status of other nodes 30 based on the second heartbeat information.

[0080] In some feasible embodiments, connections can also be established between the various database processes 220 to perform the detection process and recovery process of the database recovery. Specifically, the database process 220 in one node 30 can establish a connection with the database process 220 in other nodes 30; any one of the database processes 220 can receive the second heartbeat information sent by the database process 220 of other nodes 30, and determine whether the other nodes 30 are faulty based on the second heartbeat information. Exemplarily, if the second heartbeat information sent by the database process 220 of other nodes 30 is not received within a preset time, it can be determined that the other node 30 is faulty; at this time, the database process 220 can set the state of the other node 30 to a faulty state, and perform corresponding database recovery operations.

[0081] In one embodiment of the present invention, when performing database recovery, the database process 220 is used to lock the cluster of the distributed cluster; if the cluster lock of the distributed cluster is successful, the database is recovered and other nodes 30 are notified to perform database recovery.

[0082] In some feasible embodiments, when the database process 220 in a node 30 detects that other nodes 30 have faults, it can first lock the cluster of the distributed cluster; specifically, it can first use a redis lock to lock the cluster.

[0083] If the database process 220 successfully locks the cluster of the distributed cluster, the database can be restored, and the database processes 220 of other nodes 30 are notified to perform database recovery.

[0084] In one embodiment of the present invention, the database process 220 is also used to perform database recovery upon receiving a database recovery request sent by other nodes 30 if cluster locking of the distributed cluster fails.

[0085] In some feasible embodiments, if locking fails, you can wait for the database process 220 of other nodes 30 to successfully lock, send a database recovery message to all connectable nodes 30 and process it, and then perform a database recovery operation; specifically, after the database process 220 fails to lock, when receiving a database recovery request sent by the database process 220 of other nodes 30, it can first perform a database recovery; then, after the current database recovery is completed, perform a cluster lock operation on the distributed cluster to perform another database recovery. Of course, if the other database recovery has been completed in the previous time, it can be omitted.

[0086] In an embodiment of the present invention, the database process 220 may also be used to create a monitoring event daemon process 250 , and detect through the monitoring event daemon process 250 whether a node 30 to which the database process 220 belongs fails.

[0087] In some possible embodiments, such as Figure 2b As shown, the database process 220 can also be used to create a monitoring event daemon 250, and detect whether the node 30 to which it belongs fails through the created monitoring event daemon 250. Specifically, the database process 220 can create a monitoring event daemon 250 when it needs to detect whether the node 30 to which it belongs fails, and send information to the monitoring event daemon 250; the monitoring event daemon 250 can detect whether the node 30 to which it belongs fails based on the received information; the information can be information collected by the database process 220 and used to detect whether the node 30 to which it belongs fails, such as: the time to send the second heartbeat information to other nodes 30, etc., and the embodiment of the present invention does not limit this.

[0088] In one embodiment of the present invention, the database process 220 is further configured to exit the monitoring event daemon process 250 after determining whether the node 30 to which it belongs fails.

[0089] In some feasible embodiments, after determining whether the node 30 to which the database process 220 belongs fails, the database process 220 may exit the created monitoring event daemon process 250 to reduce resource usage.

[0090] In one embodiment of the present invention, the database process 220 is further configured to mark the node 30 as failed when it is detected that the node 30 to which it belongs fails.

[0091] In some feasible embodiments, when the database process 220 detects that the node 30 to which it belongs fails, it can mark the node 30 to which it belongs as failed, so that other nodes 30 can determine that the node 30 has a fault based on the mark, and also avoid that operations such as requests for the node 30 are responded to but cannot be processed.

[0092] In one embodiment of the present invention, the database process 220 is also used to modify the status of other nodes 30.

[0093] In some feasible embodiments, the database process 220 can also modify the status of other nodes 30; specifically, when the database process 220 of a node 30 detects that the status of other nodes 30 has changed, for example, from a normal state to a faulty state, it can modify the status of the other nodes 30 stored locally.

[0094] In one embodiment of the present invention, the distributed cluster further includes an object storage daemon;

[0095] The recovery process 210 is used to mark the failed node 30 as failed in the object storage daemon.

[0096] In some feasible embodiments, the distributed cluster also includes an object storage daemon, i.e., OSD (Object Storage Daemon); the recovery process 210 can be used to mark the failed node 30 as a fault in the object storage daemon so that the distributed cluster can determine that the node 30 is faulty.

[0097] In one embodiment of the present invention, Figure 2c As shown, the database system also includes:

[0098] The event daemon process 240 is used to receive and execute instructions sent by the main process 230.

[0099] In some feasible embodiments, the database system may also include an event daemon 240 deployed in each node 30; the event daemon 240 may be responsible for specific execution and send the execution results to the main process 230; illustratively, the event daemon 240 may execute, for example, periodically executing network card status monitoring events, monitoring service status, etc., and pass the results to the main process 230.

[0100] In one embodiment of the present invention, the main process 230 is also used to create an event daemon process 240 , a recovery process 210 , and a database process 220 .

[0101] In some feasible embodiments, the event daemon process 240 , the recovery process 210 , and the database process 220 may be created by the main process 230 .

[0102] by Figure 2c For example:

[0103] The optimized CTDB service has four processes, namely the main process 230, the event daemon process 240, the recovery process 210 and the database process 220. Among them, the event daemon process 240, the recovery process 210 and the database process 220 are all sub-processes created by the main process 230.

[0104] The main process 230 sends the specific event to be executed to the event daemon process 240 , which is responsible for the specific execution and sends the execution result to the main process 230 .

[0105] Any two nodes 30 in the cluster establish a TCP connection through the main process 230, and send heartbeat messages to other nodes 30 in the cluster except itself every second.

[0106] The recovery process 210 continuously obtains the status and flag messages of other nodes 30 from the main process 230. When the main process 230 does not receive the heartbeat message of a node 30 for n seconds, it is considered that the node 30 is faulty and corresponding processing is performed.

[0107] Specifically, the recovery process 210 can obtain the information of the unconnectable node 30 from the main process 230 and start to handle the fault. The recovery process 210 is only responsible for handling the fault, such as marking the osd of the faulty node 30 as down.

[0108] The newly added database process 220 is mainly responsible for database recovery and receiving database-related requests sent by other services, such as requests to access the database. The database process 220 of each node 30 in the cluster establishes a TCP connection with other nodes 30 except itself, and sends heartbeat information to the database processes 220 of other nodes 30 except itself every second. When the database process 220 detects that it has not received the heartbeat message of a node 30 for n seconds, it first checks whether it is a fault of itself.

[0109] If the fault is not caused by the node 30 itself, it is considered to be caused by the peer fault and the fault recovery is started. At this time, the database process 220 will first use the redis lock to lock the cluster. If the lock is successful, the database process 220 of the node 30 will notify other nodes 30 through the TCP connection to start database recovery. If the lock fails, the database process 220 of other nodes 30 will wait for the database process 220 of other nodes 30 to lock successfully, and then send a database recovery message to all connected nodes 30 before performing the database recovery operation.

[0110] The database process 220 can also create a local sockett domain to monitor database-related operation requests initiated by other services.

[0111] Figure 2b For example:

[0112] After the CTDB service is started, a database process 220 is created. The database process 220 creates a local socket domain for listening to other services. The database process 220 provides an external interface; third-party services can register with the database process 220. When a third-party service needs to obtain database-related content, it only needs to send a message to the database process 220, and the database process 220 sends the result to the third-party service.

[0113] The database process 220 establishes a TCP connection with the database processes 220 of other nodes 30 in the cluster except the current node 30, and sends a heartbeat message to the database processes 220 of other nodes 30 except the current node 30 every second. If the heartbeat message of the database process 220 of a certain node 30 is not received for n consecutive seconds, it is determined whether the current node 30 or the opposite node 30 is faulty.

[0114] The database process 220 needs to start the monitoring event daemon 250 and send a message to the monitoring event daemon 250 to check whether the failure is caused by the node 30. After the monitoring event daemon 250 returns the inspection result to the database process 220, the monitoring event daemon 250 exits to release system resources.

[0115] After the database process 220 obtains the inspection result, if the fault is in the local node 30, it marks itself as an unconnectable node 30. If the fault is not in the local node 30, it locks the cluster. If the lock is successful, it sends a database recovery message to other nodes 30 in the cluster to recover the database. If the lock fails, it waits for the database recovery message sent by the node 30 that has successfully locked.

[0116] Based on the database system provided in the above embodiment, an embodiment of the present invention further provides a distributed cluster, which may include the database system and multiple nodes mentioned in the above embodiment.

[0117] The database system may include a recovery process and a database process. The recovery process may be used to perform global fault handling and global virtual Internet Protocol address reallocation for a node when a node in a distributed cluster fails. The database process may collaborate to complete database recovery operations; specifically, when a database process detects a node failure, it may first use a redis lock to lock the cluster. If the lock is successful, the database process will perform database recovery on its own and notify the database processes of other nodes to perform database recovery.

[0118] Based on the database system provided in the above embodiment, the embodiment of the present invention also provides a fault handling method, such as Figure 3 Specifically, the fault handling method can be applied to the recovery process of the database system.

[0119] like Figure 3 As shown, the fault handling method may include the following steps:

[0120] Step 301: When a node fails, the recovery process performs fault processing and reallocation of virtual Internet Protocol addresses; wherein, when a node fails, the database process of the database system performs database recovery.

[0121] In actual applications, when the recovery process detects a node failure, it can perform global fault processing for the node and global virtual Internet Protocol address reallocation.

[0122] In addition, when a node failure is detected, the database processes in each node can work together to complete the database recovery operation; specifically, when the database process detects a node failure, it can first use the redis lock to lock the cluster. If the lock is successful, the database process will recover the database by itself and notify the database processes of other nodes to recover the database.

[0123] In some feasible embodiments, the database process can also be used to receive a target request from a third-party service for a database; the target request can be a request for obtaining data in the database, or other requests for processing data in the database, etc., which are not limited in the embodiments of the present invention. After receiving the target request, the database process can respond to the target request based on the data in the database and perform corresponding operations.

[0124] In the embodiment of the present invention, when a node fails, the recovery process performs fault processing and reallocation of a virtual Internet Protocol address; wherein, when a node fails, the database process of the database system performs database recovery. Through the embodiment of the present invention, the operations of fault processing, virtual Internet Protocol address reallocation and database recovery can be performed in parallel, thereby reducing the fault processing time and reducing the impact of the fault on the front-end business. The problem of long fault switching time and long service interruption time in the existing distributed cluster is solved.

[0125] Based on the database system provided in the above embodiment, the embodiment of the present invention also provides a fault handling method, such as Figure 4 Specifically, the fault handling method can be applied to a database process in a database system.

[0126] like Figure 4 As shown, the fault handling method may include the following steps:

[0127] Step 401: When a node of the database process fails, the database process performs database recovery; wherein, when a node of the database system fails, the recovery process performs fault processing and reallocation of a virtual Internet Protocol address.

[0128] In actual applications, when a node failure is detected, the database processes in each node can work together to complete the database recovery operation; specifically, when the database process detects a node failure, it can first use the redis lock to lock the cluster. If the lock is successful, the database process will recover the database by itself and notify the database processes of other nodes to recover the database.

[0129] In addition, when the recovery process detects a node failure, it can perform global fault processing for the node and global virtual Internet Protocol address reallocation.

[0130] In some feasible embodiments, the database process can also be used to receive a target request from a third-party service for a database; the target request can be a request for obtaining data in the database, or other requests for processing data in the database, etc., which are not limited in the embodiments of the present invention. After receiving the target request, the database process can respond to the target request based on the data in the database and perform corresponding operations.

[0131] In the embodiment of the present invention, when a node fails, the database process performs database recovery; wherein, when a node fails, the recovery process of the database system performs fault processing and virtual Internet Protocol address reallocation. Through the embodiment of the present invention, the operations of fault processing, virtual Internet Protocol address reallocation and database recovery can be performed in parallel, thereby reducing the fault processing time and reducing the impact of the fault on the front-end business. The problem of long fault switching time and long service interruption time in the existing distributed cluster is solved.

[0132] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0133] The embodiment of the present invention also provides a computer program product, such as Figure 5 As shown, the computer program product 5 includes computer instructions 501, and when the computer instructions 501 are executed by a processor, the above fault handling method is implemented.

[0134] The embodiment of the present invention further provides an electronic device, such as Figure 6 As shown, the electronic device 6 includes a processor 601, a memory 602, and a computer program stored in the memory 602 and capable of running on the processor. When the computer program is executed by the processor, the above fault handling method is implemented.

[0135] The embodiment of the present invention also provides a non-volatile computer-readable storage medium, such as Figure 7 As shown, the non-volatile computer-readable storage medium 7 stores a computer program 701, and when the computer program 701 is executed by the processor, the above fault handling method is implemented.

[0136] As for the product embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0137] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0138] Those skilled in the art will appreciate that the embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the embodiments of the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0139] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0140] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0141] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0142] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0143] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0144] The above provides a detailed introduction to a database system, a distributed cluster, a fault handling method, a computer program product, an electronic device and a non-volatile computer-readable storage medium. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for a person skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A database system, characterized in that: The database system is applied in a distributed cluster, the distributed cluster includes multiple nodes, and the database system includes a recovery process and a database process deployed in each node; wherein: The recovery process is used to perform fault handling and virtual Internet Protocol address reallocation when a node fails; The database process is used to recover the database when a node fails.

2. The database system according to claim 1, characterized in that: The database process is also used to receive a target request for the database and respond to the target request.

3. The database system according to claim 2, characterized in that: The database process is also used to create a local socket domain in the node to which it belongs, so as to monitor requests initiated by other services for the database.

4. The database system according to claim 2, characterized in that: The database process is used to respond to the target request for the database and send result information corresponding to the target request to the service that initiated the target request.

5. The database system according to claim 1, characterized in that: The database system also includes a main process deployed in each node; The main process is used for the node to establish a connection with other nodes and receive the first heartbeat information sent by the other nodes; and determine the status of the other nodes according to the first heartbeat information; The recovery process is used to determine whether the other nodes have faults according to the status of the other nodes determined in the main process.

6. The database system according to claim 1, characterized in that: The database process is also used for the node to which it belongs to establish a connection with the database process of other nodes, and receive the second heartbeat information sent by the database process of the other nodes; and determine the status of the other nodes according to the second heartbeat information.

7. The database system according to claim 1, characterized in that: The database process is used to lock the cluster of the distributed cluster; if the cluster locking of the distributed cluster is successful, the database is restored and other nodes are notified to perform database restoration.

8. The database system according to claim 7, characterized in that: The database process is further used to perform database recovery upon receiving a database recovery request sent by the other node if cluster locking of the distributed cluster fails.

9. The database system according to claim 1, characterized in that: The database process is also used to create a monitoring event daemon process, and detect through the monitoring event daemon process whether a node to which the database process belongs fails.

10. The database system according to claim 9, characterized in that: The database process is also used to exit the monitoring event daemon process after determining whether the node to which it belongs fails.

11. The database system according to claim 9, characterized in that: The database process is also used to mark the node as failed when it is detected that the node fails.

12. The database system according to claim 9, characterized in that: The database process is also used to modify the status of other nodes.

13. The database system according to claim 5, characterized in that: The distributed cluster also includes an object storage daemon; The recovery process is used to mark the failed node as failed in the object storage daemon process.

14. The database system according to claim 5, characterized in that: The database system also includes: The event daemon process is used to receive and execute instructions sent by the main process.

15. The database system according to claim 14, characterized in that: The main process is also used to create the event daemon process, the recovery process and the database process.

16. A distributed cluster, characterized in that: The distributed cluster includes the database system according to any one of claims 1 to 15 and multiple nodes.

17. A fault handling method, characterized in that: Applied to the recovery process of the database system according to any one of claims 1 to 15, the method comprises: The recovery process performs fault handling and virtual Internet Protocol address reallocation when a node fails; wherein the database process of the database system performs database recovery when a node fails.

18. A fault handling method, characterized in that: Applied in a database process of a database system according to any one of claims 1 to 15, the method comprises: The database process is used to recover the database when a node fails; wherein the recovery process of the database system performs fault processing and reallocation of virtual Internet Protocol addresses when a node fails.

19. A computer program product, characterized in that It comprises computer instructions, which, when executed by a processor, implement the fault handling method as claimed in any one of claims 17 to 18.

20. An electronic device, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program implements the fault handling method according to any one of claims 17 to 18 when executed by the processor.

21. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the fault handling method according to any one of claims 17 to 18 is implemented.

Images