Fault handling method, database node, and storage medium

Abstract

The present invention discloses a fault handling method, a database node and a storage medium. The method includes: in the case of a remote node failure, waking up a corresponding waiting event according to a waiting object registered in a management system, and triggering a waiting event for global fault recovery; sending a fault handling request to an active node in a cluster; in the case where the fault handling process executed by the active node ends, waking up the waiting event for global fault recovery. By using this method, in the case of a remote node failure, by sending a fault handling request to an active node in the cluster and triggering a waiting event for global fault recovery, all threads can be stopped from working so as to handle the faulty node, and at the same time, there is no impact on the remaining working threads.

Description

Technical Field

[0001] The embodiments of the present invention relate to the technical field of databases, and in particular, to a fault handling method, a database node, and a storage medium. Background Art

[0002] A shared storage database cluster is a highly available cluster architecture, and multiple database instances are included in the cluster environment. A database instance may include a set of operating system processes (or a multi-threaded process) and memory. The instances complete the access control of data pages through the Global Buffer Server (GBS) and the Local Buffer Server (LBS).

[0003] In the shared storage database cluster environment, the global latch information is managed by sharding according to the data page number, and each node maintains a part of the global latch information. When the requesting node requests the access control permission of a data page, if the global latch corresponding to the data page is on other nodes (such as EP02), the requesting node needs to send a request authorization message to EP02. After receiving the authorization response message from EP02, the requesting node can continue to execute; after the requesting node obtains the authorization of the data page, it still needs to read the latest data of the data page. If the latest data record of the data page is in node EP03, the requesting node needs to send a data page read request to EP03. The requesting node can continue to execute only after receiving the data page read response message from EP03.

[0004] However, when scenarios such as a machine power failure or a database instance exception occur, the requesting node will not be able to receive the response message from the remote node (such as EP02, EP03), so that the requesting node cannot continue to execute the access control of the data page. The existing fault handling methods have low reliability and cannot effectively handle the faulty node. Summary of the Invention

[0005] The embodiments of the present invention provide a fault handling method, a database node, and a storage medium to effectively handle the faulty node without affecting the remaining working threads and improve the reliability of the database cluster.

[0006] In a first aspect, the embodiments of the present invention provide a fault handling method, including:

[0007] In the case of a remote node failure, wake up the corresponding waiting event according to the waiting object registered in the management system, and trigger the waiting event for global fault recovery;

[0008] Send a fault handling request to the active nodes in the cluster;

[0009] In the case where the active nodes complete the fault handling process, wake up the waiting event for global fault recovery.

[0010] In a second aspect, an embodiment of the present invention provides a fault handling method, including:

[0011] Respond to a fault handling request and execute a fault handling process;

[0012] When the execution of the fault handling process ends, wake up the waiting event for global fault recovery.

[0013] In a third aspect, an embodiment of the present invention further provides a database node, including:

[0014] One or more processors;

[0015] A storage device for storing one or more programs;

[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the fault handling method provided by the embodiment of the present invention.

[0017] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the fault handling method provided by the embodiment of the present invention.

[0018] An embodiment of the present invention provides a fault handling method, a database node, and a storage medium. In the case of a remote node failure, the corresponding waiting event is woken up according to the waiting object registered in the management system, and the waiting event for global fault recovery is triggered; a fault handling request is sent to the active nodes in the cluster; when the execution of the fault handling process by the active nodes ends, the waiting event for global fault recovery is woken up. By using the above technical solution, in the case of a remote node failure, by sending a fault handling request to the active nodes in the cluster and triggering the waiting event for global fault recovery, all threads can be stopped to process the faulty node, and at the same time, it will not affect the remaining working threads. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a schematic flowchart of a fault handling method provided by Embodiment 1 of the present invention;

[0020] Figure 2 It is a schematic flowchart of a fault handling method provided by Embodiment 2 of the present invention;

[0021] Figure 3 It is a schematic structural diagram of message interaction between nodes in a fault handling method provided by Embodiment 2 of the present invention;

[0022] Figure 4 It is a schematic flowchart of a fault handling method provided by Embodiment 3 of the present invention;

[0023] Figure 5 Schematic structural diagram of a first fault handling device provided in Embodiment IV of the present invention;

[0024] Figure 6 Schematic structural diagram of a second fault handling device provided in Embodiment V of the present invention;

[0025] Figure 7 Schematic structural diagram of a database node provided in Embodiment VI of the present invention. Detailed implementation manners

[0026] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the present invention, rather than limiting the present invention. Additionally, it should be noted that for the sake of description, only parts related to the present invention rather than all structures are shown in the drawings.

[0027] Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations (or steps) as sequential processes, many of the operations can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the operations can be rearranged. The process can be terminated when its operations are completed, but it can also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc. In addition, without conflict, the embodiments in the present invention and the features in the embodiments can be combined with each other.

[0028] The term "including" and its variants used in the present invention are open-ended, that is, "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment".

[0029] It should be noted that the concepts such as "first" and "second" mentioned in the present invention are only used to distinguish the corresponding contents, and are not used to limit the order or the interdependent relationship.

[0030] It should be noted that the modifications of "one" and "multiple" mentioned in the present invention are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly stated in the context, it should be understood as "one or more".

[0031] Embodiment I

[0032] Figure 1It is a schematic flowchart of a fault handling method provided by Embodiment 1 of the present invention. This method is applicable to the situation where a faulty node appears in a shared storage database cluster. This method can be executed by a first fault handling method device, where the device can be implemented by software and / or hardware and is generally integrated on a database node.

[0033] It should be noted that the global latch service contains all the authorized latch information, including the node information that grants the latch, the data page address, the data page LSN, the latch type, the latest data page distribution, and other information. The local latch service contains all the data page information that this node has obtained the authorization permission from the global latch service, including the data page address, the data page LSN information, the latch type, etc.

[0034] Generally, exemplarily, when node EP01 accesses or modifies data page P1, it first needs to obtain the LBS permission of data page P1, and then obtain the latest data of P1. The specific process can be roughly described as follows: First, node EP01 needs to request the access control permission of data page P1. If the global latch corresponding to P1 is on other nodes, that is, remote node 1, node EP01 needs to send a request authorization message to remote node 1 and wait for the authorization response message from remote node 1; After receiving the request authorization message from EP01, remote node 1 adjusts the global latch information of P1, grants node EP01 the access control permission of data page P1, and sends an authorization response message to EP01; After receiving the authorization response message from remote node 1, EP01 continues to execute;

[0035] Then, after node EP01 obtains the authorization of data page P1, it needs to read the latest data of data page P1. The latest data of data page P1 may be stored on the disk or recorded in other active nodes, that is, remote node 2. If the latest data of data page P1 is recorded in remote node 2, EP01 needs to send a data page read request to remote node 2 and wait for the response message from remote node 2; After receiving the data page P1 read request from EP01, remote node 2 sends the content of data page P1 to EP01 through the network, and node EP01 continues to execute after receiving the data page read response message from remote node 2.

[0036] However, when scenarios such as power failure of the machine or abnormal database instance occur, the above access or modification process may be interrupted. EP01 will not be able to receive the response message from the remote node and cannot continue to execute the access or modification of data page P1.

[0037] Based on this, the embodiment of the present invention provides a fault handling method. When the requesting node requests to access or modify a data page, if a node failure occurs, the active node will perform a fault handling process to effectively handle the faulty node without affecting the remaining working threads.

[0038] Specifically, a fault handling method provided in Embodiment 1 of the present invention is applied to a requesting node, and specifically includes the following steps:

[0039] S110. In the case of a remote node failure, wake up the corresponding waiting event according to the waiting object registered in the management system, and trigger the waiting event for global fault recovery.

[0040] Among them, the remote node mainly refers to the node connected to the local server through a high-speed network. The remote node is also peer to the node on the local server and has the functions of providing data access and modification. In this embodiment, the remote node can be a global latch node or a node containing the latest data of the data page to be accessed.

[0041] Generally, the database allocates a continuous piece of memory for data page caching to improve data access performance. The same data page may be distributed in the caches of different nodes. The shared storage database cluster uses global latches to provide the concurrent access control function for data pages. For a certain data page, the node where the global latch storing the data page is located is called the global latch node or the global latch master node.

[0042] The management system can be understood as the system for managing data in the shared storage database. The management system may be the LBS management system for recording and managing local latch service information, or may be the io_sys management system for recording and managing information about data reading.

[0043] The waiting object can be understood as the object registered by the requesting node when applying for the LBS permission of the data page from the remote node or reading the latest data of the data page. After registering the waiting object, the requesting node registers the waiting object in the management system to wake up the waiting event; the waiting event can refer to the event that the thread pauses and is in the waiting state. For example, after the requesting node sends a message applying for the LBS permission of the data page to the remote node, the thread pauses and is in the state of waiting for the response of the remote node; the waiting event for global fault recovery is that the thread pauses and is in the state of waiting for global fault recovery.

[0044] Waking up mainly means terminating the waiting event and making the thread continue to run; triggering mainly means starting the waiting event.

[0045] This embodiment does not limit the identification of remote node failures. For example, the management system can perform occupancy counting on the waiting object. If the count is not reduced after exceeding the time threshold, it means that the corresponding remote node has failed; it can also be identified by the requesting node recording the time interval of sending the request message. If the requesting node does not receive the response from the corresponding remote node within a certain time interval, it means that the corresponding remote node has failed, etc.

[0046] In the case of a remote node failure, the requesting node can wake up the corresponding waiting event according to the waiting object registered in the management system, and trigger the waiting event for global failure recovery to wait for global failure recovery.

[0047] S120. Send a failure handling request to the active nodes in the cluster.

[0048] The active nodes can be nodes in the cluster, and the number of active nodes is not limited.

[0049] In the case of a remote node failure, the requesting node can send a failure handling request to the active nodes in the cluster, stop all working threads, and let the active nodes complete the handling of the failed node.

[0050] As an implementable way, the above steps S110 and S120 can be described as: in the case of a remote node failure, the requesting node initiates a failure handling process, and all the remaining working threads stop working. Then the requesting node can find the registered slot waiting object from the LBS management system, wake up the slot->event waiting event, reduce the lbs->n_fixed count, and finally start the waiting event for global failure recovery to wait for global failure recovery.

[0051] As another implementable way, the above steps S110 and S120 can also be described as: in the case of a remote node failure, the requesting node initiates a failure handling process, and all the remaining working threads stop working. Then the requesting node finds the registered slot waiting object from the io_sys management system, wakes up the slot->event waiting event, reduces the buf->n_fixed count and the lbs->n_fixed count, and finally starts the waiting event for global failure recovery to wait for global failure recovery.

[0052] It should be noted that the numbering order of the above S110 and S120 does not represent the execution order. That is, in the embodiment, the failure handling request can be sent to the active nodes in the cluster first, and then in the case of a remote node failure, the corresponding waiting event can be woken up according to the waiting object registered in the management system, and the waiting event for global failure recovery can be triggered.

[0053] S130. Wake up the waiting event for global failure recovery when the failure handling process executed by the active nodes ends.

[0054] When the failure handling process executed by the active nodes ends, the requesting node can wake up the waiting event for global failure recovery, and all the working threads continue to run. Then the requesting node continues to execute the access or modification of the data page.

[0055] A fault handling method provided in the first embodiment of the present invention can stop all threads from working in the case of a remote node fault by sending a fault handling request to an active node in the cluster and triggering a waiting event for global fault recovery, so as to process the faulty node without affecting the remaining working threads.

[0056] Embodiment 2

[0057] Figure 2 It is a schematic flowchart of a fault handling method provided in the second embodiment of the present invention. This second embodiment is optimized on the basis of the above embodiments. In this embodiment, the situation before waking up the corresponding waiting event according to the waiting object registered in the management system in the case of a remote node fault is specified.

[0058] In this embodiment, before waking up the corresponding waiting event according to the waiting object registered in the management system in the case of a remote node fault, it further includes: sending an LBS permission request message for the data page to be accessed to the first remote node, and registering a waiting object in the LBS management system; if the authorization response message from the first remote node is received, cancel the registration information of the waiting object in the LBS management system, and wake up the waiting event corresponding to the waiting object; if the authorization response message from the first remote node is not received, the first remote node fails. On this basis, the preparation work for the requesting node to obtain the LBS permission for the data page to be accessed is realized, and the situation of the first remote node failure is identified.

[0059] In this embodiment, before waking up the corresponding waiting event according to the waiting object registered in the management system in the case of a remote node fault, it further includes: if the latest data record of the data page to be accessed is in the second remote node, send a data page read request to the second remote node, and register a waiting object in the data reading management system; if the read response message from the second remote node is received, cancel the registration information of the waiting object in the data reading management system, and wake up the waiting event corresponding to the waiting object; if the read response message from the second remote node is not received, the second remote node fails. On this basis, the preparation work for the requesting node to read the data page is realized, and the situation of the second remote node failure is identified.

[0060] For the content not detailed in this embodiment, please refer to Embodiment 1.

[0061] As Figure 2 shown, a fault handling method provided in the second embodiment of the present invention includes the following steps:

[0062] S201. Send an LBS permission request message for the data page to be accessed to the first remote node, and register a waiting object in the LBS management system.

[0063] Among them, the remote node includes the first remote node, and the first remote node may refer to the global latch node of the data page to be accessed, which is used to store the global latch of the data page. The request message can be regarded as a message requesting the LBS permission of the data page to be accessed, and the request message may include the address information of the waiting object.

[0064] Specifically, when the requesting node applies for the LBS permission of the data page from the first remote node, it first registers a waiting object, then sends an LBS permission request message for the data page to be accessed to the first remote node. The request message includes the address information of the waiting object. At the same time, the requesting node registers the waiting object in the LBS management system. Finally, the requesting node starts waiting for an event to wait for the authorization response message from the first remote node.

[0065] S202. Determine whether an authorization response message from the first remote node is received. If so, execute S203; if not, execute S204.

[0066] The authorization response message can be regarded as a message in which the first remote node grants the requesting node the requested permission, and the authorization response message may include the address information of the waiting object.

[0067] It can be understood that after the requesting node sends an LBS permission request message for the data page to be accessed to the first remote node, the requesting node may receive an authorization response message from the first remote node, or may not receive an authorization response message from the first remote node. It is necessary to further perform subsequent operations by determining whether the requesting node receives an authorization response message from the first remote node. If the requesting node receives an authorization response message from the first remote node, it means that the first remote node in the cluster is working properly. At this time, the requesting node cancels the registration information of the waiting object in the LBS management system, wakes up the waiting event corresponding to the waiting object, and continues to perform the subsequent operation of obtaining the latest data of the data page. If the requesting node does not receive an authorization response message from the first remote node, it means that the first remote node has failed.

[0068] This embodiment does not limit the method for determining whether the requesting node receives an authorization response message from the first remote node. For example, the determination method may be: a waiting time is set in advance. If the requesting node receives an authorization response message from the first remote node within the waiting time, the subsequent operations are continued; if the requesting node has not received an authorization response message from the first remote node after the waiting time has elapsed, it is determined that the first remote node has failed. The waiting time can be set by relevant personnel, and this embodiment does not limit this.

[0069] S203. Cancel the registration information of the waiting object in the LBS management system and wake up the waiting event corresponding to the waiting object.

[0070] S204. The first remote node fails.

[0071] When the first remote node fails, it is necessary to further execute step S209 to handle the failure of the first remote node.

[0072] S205. If the latest data record of the data page to be accessed is in the second remote node, send a data page read request to the second remote node and register a waiting object in the data reading management system.

[0073] Among them, the remote node may include the second remote node, and the second remote node may be the node containing the latest data of the data page to be accessed; the data page read request can be regarded as a message requesting to read the latest data in the data page to be accessed, and the data page read request may include the address information of the waiting object.

[0074] Specifically, if the latest data record of the data page to be accessed is in the second remote node, when the requesting node requests the second remote node to read the latest data in the data page to be accessed, it first registers a waiting object, then sends a data page read request to the second remote node. The data page read request contains the address information of the waiting object. At the same time, the requesting node registers the waiting object in the data reading management system. Finally, the requesting node starts a waiting event to wait for the read response message from the second remote node.

[0075] S206. Determine whether the read response message from the second remote node is received. If so, execute S207; if not, execute S208.

[0076] Among them, the read response message can be regarded as a message in which the second remote node grants the requesting node the permission to read the latest data in the data page, and the read response message may include the latest data of the data page and the address information of the waiting object.

[0077] It is understandable that after the requesting node sends a data page read request to the second remote node, the requesting node may or may not receive a read response message from the second remote node. It is necessary to further determine whether the requesting node has received the read response message from the second remote node to perform subsequent operations. If the requesting node receives the read response message from the second remote node, it indicates that the second remote node in the cluster is working properly. At this time, the requesting node can cancel the registration information of the waiting object in the data reading management system and wake up the waiting event corresponding to the waiting object. At the same time, the requesting node can obtain the latest data of the data page to be accessed and continue to execute the thread. For example, it can modify the data of the data page or access the data of the next data page, etc.; if the requesting node does not receive the read response message from the second remote node, it indicates that the second remote node has failed.

[0078] This embodiment does not limit the method for determining whether the requesting node has received the read response message from the second remote node. For example, the determination method can be: a waiting time is set in advance. If the requesting node receives the read response message from the second remote node within the waiting time, subsequent operations are continued; if the requesting node has not received the read response message from the second remote node after exceeding the waiting time, it is determined that the second remote node has failed. The waiting time can be set by relevant personnel, and this embodiment does not limit this.

[0079] S207. Cancel the registration information of the waiting object in the data reading management system and wake up the waiting event corresponding to the waiting object.

[0080] S208. The second remote node has failed.

[0081] When the second remote node fails, it is necessary to further execute step S209 to handle the failure of the second remote node.

[0082] S209. In the case of a remote node failure, wake up the corresponding waiting event according to the waiting object registered in the management system and trigger the waiting event for global failure recovery.

[0083] S210. Send a failure handling request to the active nodes in the cluster.

[0084] Among them, the remote nodes may include a first remote node and a second remote node.

[0085] Specifically, in the case of a remote node failure, the requesting node can wake up the corresponding waiting event according to the waiting object registered in the management system and trigger the waiting event for global failure recovery, and the requesting node sends a failure handling request to the active nodes in the cluster.

[0086] As an implementable way, the above steps S209 and S210 can be described as follows: in the case of a failure of the first remote node, the requesting node initiates a fault handling process, and all the remaining working threads stop working. Then the requesting node can find the registered waiting objects in the LBS management system, wake up the corresponding waiting events, and finally start the global fault recovery waiting event to wait for the global fault recovery.

[0087] As another implementable way, the above steps S209 and S210 can also be described as follows: in the case of a failure of the second remote node, the requesting node initiates a fault handling process, and all the remaining working threads stop working. Then the requesting node finds the registered waiting objects in the io_sys management system, wakes up the corresponding waiting events, and finally starts the global fault recovery waiting event to wait for the global fault recovery.

[0088] It should be noted that, similarly, this embodiment does not limit the execution order of steps S209 and S210, as long as the content in the steps is ensured to be completed. For example, S209 and step S210 can be executed in sequence, or steps S209 and S210 can be executed simultaneously. This embodiment does not make any limitation in this regard.

[0089] S211. When the fault handling process executed by the active node ends, wake up the waiting event for global fault recovery.

[0090] A fault handling method provided in the second embodiment of the present invention can identify any type of faulty node by judging whether the authorization response message of the first remote node and / or the read response message of the second remote node is received, and can trigger the waiting event for global fault recovery for any type of faulty node, so as to effectively handle the faulty node.

[0091] As an optional embodiment, the fault handling method further includes: when each waiting object is registered in the management system, an occupancy count is increased.

[0092] Among them, the type of the occupancy count is not limited. For example, it can be an LBS occupancy count, or it can be a buf occupancy count. The occupancy count is used to record the number of events that are waiting.

[0093] It can be understood that when the requesting node sends an LBS permission request message for the data page to be accessed to the first remote node and / or sends a data page read request to the second remote node, a waiting object can be registered and the waiting object can be registered in the management system. At this time, when each waiting object is registered in the management system, an occupancy count is increased.

[0094] The purpose of adding this step is that if the occupancy count is not subtracted after exceeding a certain time threshold, it indicates that the corresponding remote node has failed. This step can be combined with step S202 and step S206 to judge the faulty node, so as to improve the accuracy of identifying the faulty node, and further ensure the effective processing of the faulty node.

[0095] Figure 3 It is a schematic diagram of the message interaction between nodes in a fault handling method provided in the second embodiment of the present invention, as Figure 3 shown, including a request node 1, a first remote node 2, and a second remote node 3.

[0096] Specifically, when the request node 1 applies for the LBS permission of the data page to be accessed to the first remote node 2, it needs to send an LBS permission request message about the data page to be accessed to the first remote node 2. The request message contains the waiting object address information. At this time, the request node 1 waits for the authorization response message from the first remote node 2. After receiving the request message from the request node 1, the first remote node 2 grants the LBS permission of the data page to be accessed to the request node 1 and sends an authorization response message to the request node 1. After receiving the authorization response message from the first remote node 2, the request node 1 continues to execute the operation of obtaining the latest data of the data page to be accessed;

[0097] When the latest data of the data page to be accessed is recorded in the second remote node 3, the request node 1 needs to send a data page read request to the second remote node 3, and then wait for the read response message from the second remote node 3. After receiving the data page read request from the request node 1, the second remote node 3 sends a read response message to the request node 1. After receiving the read response message from the second remote node 3, the request node 1 obtains the latest data of the data page to be accessed and continues to execute the subsequent thread.

[0098] Embodiment Three

[0099] Figure 4 It is a schematic diagram of a fault handling method provided in the third embodiment of the present invention. This method is applicable to the situation of handling faulty nodes. This method can be executed by a second fault handling method device, where the device can be implemented by software and / or hardware and is generally integrated on a database node.

[0100] As Figure 4 shown, a fault handling method provided in the third embodiment of the present invention is applied to an active node and specifically includes the following steps:

[0101] S310. Respond to the fault handling request and execute the fault handling process.

[0102] After the active node receives a fault handling request from the requesting node, it responds to the fault handling request and starts to execute the fault handling process. In this embodiment, the means for executing the fault handling process is not limited. For example, it can restore the data of the faulty node; it can also transfer the information of the faulty node to other nodes so that other nodes can perform the work of the faulty node.

[0103] S320. When the execution of the fault handling process ends, wake up the waiting event for global fault recovery.

[0104] When the active node finishes executing the fault handling process, it can end the waiting event for global fault recovery and enable all threads to continue working.

[0105] A fault handling method provided in Embodiment 3 of the present invention can effectively handle a faulty node by executing a fault handling process, and then end the waiting event for global fault recovery, enabling all threads to continue working.

[0106] In one embodiment, the execution of the fault handling process includes at least one of the following:

[0107] Restore the data of the faulty node according to the redo log of the faulty node;

[0108] Update the latch information of the nodes in the cluster;

[0109] Adjust the effective attributes of the nodes in the cluster.

[0110] Among them, the redo log is used to record data-related operations in the node, such as access, reading, modification, etc.

[0111] Specifically, the means for executing the fault handling process can include restoring the data of the faulty node according to the redo log of the faulty node, can also include updating the latch information of the nodes in the cluster, and can also include removing the faulty node to enable the normal nodes to continue working, that is, adjusting the effective attributes of the nodes in the cluster, etc.

[0112] Embodiment 4

[0113] Figure 5 The following is a schematic structural diagram of a first fault handling device provided in Embodiment 4 of the present invention. This device is applicable to the situation where there are faulty nodes in a shared storage database cluster. Among them, this device can be implemented by software and / or hardware and is generally integrated on the database node.

[0114] As Figure 5 shown, this device includes:

[0115] A trigger module 510, configured to, when a remote node fails, wake up a corresponding waiting event according to the waiting object registered in the management system, and trigger the waiting event for global fault recovery;

[0116] A sending module 520, configured to send a fault handling request to active nodes in the cluster;

[0117] A first wake-up module 530, configured to wake up the waiting event of global fault recovery when the execution of the fault handling process by the active node ends.

[0118] In the case of a remote node failure, the first fault handling device of this embodiment can stop all threads from working by sending a fault handling request to active nodes in the cluster and triggering the waiting event of global fault recovery, so as to handle the faulty node, and at the same time, it will not affect the remaining working threads.

[0119] On the above basis, the remote node includes a first remote node, and the first remote node is the global latch node of the data page to be accessed;

[0120] The management system includes a local latch service LBS management system.

[0121] On the above basis, before the trigger module 510, it further includes:

[0122] A request message sending unit, configured to send an LBS permission request message about the data page to be accessed to the first remote node and register a waiting object in the LBS management system;

[0123] A first wake-up unit, configured to cancel the registration information of the waiting object in the LBS management system and wake up the waiting event corresponding to the waiting object if the authorization response message from the first remote node is received;

[0124] A first fault unit, configured to determine that the first remote node is faulty if the authorization response message from the first remote node is not received.

[0125] On the above basis, the remote node includes a second remote node, and the second remote node is the node containing the latest data of the data page to be accessed;

[0126] The management system includes a data reading management system.

[0127] On the above basis, before the trigger module 510, it further includes:

[0128] A read request sending unit, configured to send a data page read request to the second remote node and register a waiting object in the data reading management system if the latest data of the data page to be accessed is recorded in the second remote node;

[0129] A second wake-up unit, configured to cancel the registration information of the waiting object in the data reading management system and wake up the waiting event corresponding to the waiting object if a read response message from the second remote node is received;

[0130] A second fault unit, configured to determine that the second remote node is faulty if a read response message from the second remote node is not received.

[0131] Based on the above, the apparatus further includes: a counting module, and the counting module is specifically configured to:

[0132] Increment an occupancy count each time a waiting object is registered in the management system.

[0133] The above first fault handling display apparatus can execute the fault handling method provided in Embodiment 1 or Embodiment 2 of the present disclosure, and has corresponding functional modules and beneficial effects for executing the method.

[0134] Embodiment 5

[0135] Figure 6 FIG. is a schematic structural diagram of a second fault handling apparatus provided in Embodiment 5 of the present invention. The apparatus is applicable to a situation where a faulty node appears in a shared storage database cluster, and the apparatus can be implemented by software and / or hardware and is generally integrated on a database node.

[0136] As Figure 6 shown, the apparatus includes:

[0137] An execution module 610, configured to execute a fault handling process in response to a fault handling request;

[0138] A second wake-up module 620, configured to wake up a waiting event for global fault recovery when the execution of the fault handling process ends.

[0139] The second fault handling apparatus of this embodiment can effectively handle a faulty node by executing a fault handling process, thereby ending the waiting event for global fault recovery and enabling all threads to continue working.

[0140] Based on the above, the execution module 610 includes at least one of the following:

[0141] Recover the data of the faulty node according to the redo log of the faulty node;

[0142] Update the latch information of the nodes in the cluster;

[0143] Adjust the valid attributes of the nodes in the cluster.

[0144] The above second fault handling display device can execute the fault handling method provided in Embodiment 3 of the present disclosure, and has the corresponding functional modules and beneficial effects for executing the method.

[0145] Embodiment 6

[0146] Figure 7 FIG. is a schematic structural diagram of a database node provided by Embodiment 6 of the present invention. As Figure 7 shown, the database node provided by Embodiment 6 of the present invention includes: one or more processors 71 and a storage device 72; the processors 71 in the database node can be one or more, Figure 7 taking one processor 71 as an example; the storage device 72 is used to store one or more programs; the one or more programs are executed by the one or more processors 71, so that the one or more processors 71 implement the fault handling method described in any one of the embodiments of the present invention.

[0147] It should be noted that the database node can be a request node or an active node. For a request node, after its processor executes the program, the following fault handling method can be implemented: in the case of a remote node failure, wake up the corresponding waiting event according to the waiting object registered in the management system, and trigger the waiting event for global fault recovery; send a fault handling request to the active nodes in the cluster; in the case where the active node finishes executing the fault handling process, wake up the waiting event for global fault recovery.

[0148] For an active node, after its processor executes the program, the following fault handling method can be implemented: respond to the fault handling request and execute the fault handling process; in the case where the fault handling process is finished, wake up the waiting event for global fault recovery.

[0149] The database node may further include: an input device 73 and an output device 74.

[0150] The processors 71, storage device 72, input device 73, and output device 74 in the database node can be connected by a bus or other means, Figure 7 taking connection by bus as an example.

[0151] The storage device 72 in the database node, as a computer-readable storage medium, can be used to store one or more programs, and the programs can be software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the fault handling methods provided in Embodiment 1 or 2 of the present invention (for example, attached Figure 5The modules in the first fault handling device shown include: a trigger module 510, a sending module 520, and a first wake-up module 530). The processor 71 executes various functional applications and data processing of the database node by running software programs, instructions, and modules stored in the storage device 72, that is, implements the fault handling method in the above method embodiments.

[0152] The storage device 72 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created according to the use of the database node, etc. In addition, the storage device 72 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state storage devices. In some instances, the storage device 72 may further include a memory remotely set relative to the processor 71, and these remote memories may be connected to the device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0153] The input device 73 can be used to receive input digital or character information, and generate key signal inputs related to user settings and function controls of the database node. The output device 74 may include display devices such as a display screen.

[0154] Embodiment Seven

[0155] Embodiment Seven of the present invention provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, it is used to execute a fault handling method, and the method includes:

[0156] In the case of a remote node failure, wake up the corresponding waiting event according to the waiting object registered in the management system, and trigger the waiting event for global fault recovery;

[0157] Send a fault handling request to the active nodes in the cluster;

[0158] In the case where the active node finishes executing the fault handling process, wake up the waiting event for global fault recovery.

[0159] Alternatively, when the program is executed by the processor, it is used to execute a fault handling method, and the method includes:

[0160] Respond to the fault handling request and execute the fault handling process;

[0161] In the case where the execution of the fault handling process ends, wake up the waiting event for global fault recovery.

[0162] Optionally, when the program is executed by the processor, it can also be used to execute the fault handling method provided in any embodiment of the present invention.

[0163] The computer storage medium of the embodiment of the present invention may adopt any combination of one or more computer-readable media. The computer-readable media may be computer-readable signal media or computer-readable storage media. The computer-readable storage media may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination of the above. The computer-readable storage media may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0164] The computer-readable signal media may include data signals propagated in a baseband or as part of a carrier wave, which carry computer-readable program codes. Such propagated data signals may take various forms, including but not limited to: electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal media may also be any computer-readable media other than the computer-readable storage media, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0165] The program codes contained on the computer-readable media may be transmitted by any appropriate media, including but not limited to: wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination of the above.

[0166] Computer program code for performing the operations of the present invention may be written in one or more programming languages or combinations thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and also including conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0167] Note that the above is only a preferred embodiment of the present invention and the technical principles applied. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, re-adjustments, and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments. Without departing from the concept of the present invention, more other equivalent embodiments may be included, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A fault handling method, characterized in that, Including: In the case of a remote node failure, wake up the corresponding waiting event according to the waiting object registered in the management system, and trigger the waiting event for global fault recovery; Send a fault handling request to the active nodes in the cluster; In the case where the active node finishes executing the fault handling process, wake up the waiting event for global fault recovery; Wherein, the waiting object is an object registered by the requesting node when applying for the local latch service (LBS) permission of the data page from the remote node or reading the latest data of the data page; The method further includes: performing occupancy counting on the waiting object through the management system. If the count is not reduced after exceeding the time threshold, it indicates that the corresponding remote node has failed; or, recording the time interval of sending the request message by the requesting node. If the requesting node does not receive a response from the corresponding remote node within the set time interval, it indicates that the corresponding remote node has failed; Wherein, the active node executing the fault handling process includes: restoring the data of the fault node according to the redo log of the fault node; updating the latch information of the nodes in the cluster; adjusting the effective attributes of the nodes in the cluster; transferring the information of the fault node to other nodes so that the other nodes can perform the work of the fault node.

2. The method according to claim 1, wherein The remote node includes a first remote node, and the first remote node is the global latch node of the data page to be accessed; The management system includes a local latch service (LBS) management system.

3. The method according to claim 2, wherein Before waking up the corresponding waiting event according to the waiting object registered in the management system in the case of a remote node failure, it further includes: Sending an LBS permission request message for the data page to be accessed to the first remote node, and registering a waiting object in the LBS management system; If the authorization response message from the first remote node is received, cancel the registration information of the waiting object in the LBS management system, and wake up the waiting event corresponding to the waiting object; If the authorization response message from the first remote node is not received, the first remote node has failed.

4. The method according to claim 1, wherein The remote node includes a second remote node, and the second remote node is the node containing the latest data of the data page to be accessed; The management system includes a data reading management system.

5. The method according to claim 4, characterized in that Before waking up the corresponding waiting event according to the waiting object registered in the management system in the case of a remote node failure, it further includes: If the latest data record of the data page to be accessed is in the second remote node, send a data page read request to the second remote node, and register a waiting object in the data reading management system; If the read response message from the second remote node is received, cancel the registration information of the waiting object in the data reading management system, and wake up the waiting event corresponding to the waiting object; If the read response message from the second remote node is not received, the second remote node has failed.

6. The method according to claim 3 or 5, characterized in that, It further includes: When each waiting object is registered in the management system, increase an occupancy count.

7. A database node, characterized in that, Including: One or more processors; A storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the fault handling method according to any one of claims 1-6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, the fault handling method according to any one of claims 1-6 is implemented.

Images