A method, apparatus, device and medium for resource takeover of a shared cluster

Abstract

This application relates to the field of database technology, and particularly to a resource takeover method, apparatus, device, and medium for a shared cluster. The method is applied to a first database node in a shared cluster. When a failure of a second database node is detected, the number of pending read / write requests for the second database node is obtained from the shared storage area of ​​the second database node in shared storage. If the number of pending read / write requests is zero, the data block resources of the second database node are taken over. This takeover method is entirely hardware-independent, using software to control the takeover of data block resources, thus avoiding access conflicts between the taking-over database node and the taken-over database node on the same data area on the disk.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a method, apparatus, device and medium for resource takeover of a shared cluster. Background Technology

[0002] In a shared clustered database environment, nodes in the cluster concurrently read and write data on a shared disk, and only one node can read and write the same data area on the disk at any given time. When a shared cluster experiences a split-brain due to a network failure, to ensure the consistency of cluster services, the system typically uses specific algorithms to identify and isolate the faulty nodes caused by the split-brain, while healthy nodes take over the data block resources of the faulty nodes. However, during the takeover process, if the original faulty node had issued read / write requests for a specific data area on the disk before being isolated, and these requests have not yet completed the disk read / write operations, and the healthy node taking over the data block also needs to perform read / write operations on that data area, then two read / write requests may simultaneously read and write the same data area. This situation will destroy data consistency and is irreversible once it occurs. Therefore, how to avoid read / write conflicts between the taking-over database node and the taken-over database node on the same data resource during resource takeover in a shared cluster is an urgent problem to be solved. Summary of the Invention

[0003] In view of this, embodiments of this application provide a resource takeover method, apparatus, device, and medium for a shared cluster, in order to solve the problem of avoiding read / write conflicts between the taking-over database node and the taken-over database node on the same data resource when performing resource takeover in a shared cluster.

[0004] In a first aspect, embodiments of this application provide a resource takeover method for a shared cluster, wherein the resource takeover method is applied to a first database node in the shared cluster, comprising:

[0005] When a failure is detected in the second database node, the number of read / write requests in transit for the second database node is obtained from the shared storage area of ​​the second database node in the shared storage.

[0006] If the number of read / write requests in transit is zero, then the data block resources of the second database node are taken over.

[0007] Secondly, embodiments of this application provide a resource takeover device for a shared cluster, the resource takeover device being applied to a first database node in the shared cluster, comprising:

[0008] The first acquisition module is used to acquire the number of in-transit read / write requests of the second database node from the shared storage area of ​​the second database node in the shared storage when a failure of the second database node is detected.

[0009] The first takeover module is used to take over the data block resources of the second database node if the number of in-transit read / write requests is zero.

[0010] Thirdly, embodiments of this application provide a computer device, the computer device including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the resource takeover method for a shared cluster as described in the first aspect.

[0011] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the resource takeover method for a shared cluster as described in the first aspect.

[0012] The beneficial effects of this application embodiment compared with the prior art are as follows: The resource takeover method of this application is applied to the first database node in the shared cluster. When a failure of the second database node is detected, the number of in-transit read and write requests of the second database node is obtained from the shared storage area of ​​the second database node in the shared storage. If the number of in-transit read and write requests is zero, the data block resources of the second database node are taken over.

[0013] Specifically, when taking over the data block resources of the second database node, the takeover operation is performed only when the number of pending read / write requests on the second database node is zero. This avoids the data inconsistency caused by multiple nodes accessing the same data resource simultaneously during the takeover process, where the second database node has already issued read / write requests for specific data areas on the disk, but these requests have not yet completed the disk read / write operations, and the taking-over database node also needs to perform read / write operations on the data area. Furthermore, the takeover method of this application does not rely on hardware at all, but uses software to control the takeover of data block resources, thus avoiding access conflicts between the taking-over database node and the taken-over database node on the same data area on the disk. Attached Figure Description

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

[0015] Figure 1 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 1 of this application;

[0016] Figure 2 This is a schematic diagram of the overall process of a resource takeover method for a shared cluster provided in Embodiment 1 of this application;

[0017] Figure 3 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 2 of this application;

[0018] Figure 4 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 3 of this application;

[0019] Figure 5 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 4 of this application;

[0020] Figure 6 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 5 of this application;

[0021] Figure 7 This is a schematic diagram of the structure of a resource takeover device for a shared cluster provided in Embodiment Six of this application;

[0022] Figure 8 This is a schematic diagram of the structure of a computer device provided in Embodiment 7 of this application. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0025] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0026] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0027] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0028] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0029] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0030] To illustrate the technical solution of this application, specific embodiments are described below.

[0031] See Figure 1 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 1 of this application. Figure 1 As shown, this resource takeover method is applied to the first database node in a shared cluster and may include the following steps:

[0032] Step S101: When a failure is detected in the second database node, the number of read / write requests in transit for the second database node is obtained from the shared storage area of ​​the second database node in the shared storage.

[0033] Step S102: If the number of read / write requests in transit is zero, then take over the data block resources of the second database node.

[0034] In this embodiment, a shared cluster can refer to a database cluster system that allows multiple database nodes to access and operate the same storage medium. Split-brain phenomenon can refer to the inconsistency in state and data divergence between database nodes caused by network failure. In a shared cluster database environment, when a split-brain phenomenon occurs among database nodes, to ensure the consistency of cluster services, the system typically uses a specific algorithm to identify and isolate the faulty database node caused by the split-brain. Simultaneously, a healthy database node takes over the data block resources of the faulty database node. Here, the second database node can refer to the faulty database node caused by the split-brain, and the first database node can refer to the healthy database node that takes over the data block resources of the second database node.

[0035] Shared storage can refer to physical storage devices (such as disks), a shared storage area can refer to storage space on shared storage, which allows multiple database nodes in a shared cluster to access and operate on the data in that storage space, an in-transit read / write request can refer to a request that has been sent to a specific data area on the disk but has not yet completed the disk read / write operation, and a data block resource can refer to a data block managed by a second database node.

[0036] Specifically, when a failure is detected in the second database node, the first database node prepares to take over the data block resources of the second database node. It obtains the number of in-transit read / write requests of the second database node from the shared storage area of ​​the second database node in the shared storage. If the number of in-transit read / write requests is zero, it means that there are no unfinished disk read / write requests in the second database node, and then the first database node takes over the data block resources of the second database node.

[0037] Optionally, after obtaining the in-transit read / write requests of the second database node, if the number of in-transit read / write requests is not zero, then wait.

[0038] For example, such as Figure 2 The diagram shown is a schematic representation of the overall process of a resource takeover method for a shared cluster provided in Embodiment 1 of this application.

[0039] If a user needs to create a database table, and the user executes the database statement to create the table on the client, sending a disk read / write request to the second database node, the overall process for the second database node to handle this disk read / write request can be as follows:

[0040] 1) After receiving a disk read / write request to create a table, the second database node first increments the number of in-transit read / write requests recorded in memory by 1. When the network connection with the shared storage is normal, the number of in-transit read / write requests recorded in memory is written to the shared storage through a timed thread; 2) The disk read / write request to create the table is processed, and the created table file is written to the disk; 3) The number of in-transit read / write requests recorded in memory is decremented by 1. When the network connection with the shared storage is normal, the number of in-transit read / write requests recorded in memory is written to the shared storage through a timed thread.

[0041] During the process of the second database node handling disk read / write requests, if a failure of the second database node is detected after step 1), and the first database node needs to take over the data block resources of the second database node, the overall process of resource takeover by the first database node can be as follows:

[0042] 1) Obtain the number of in-transit read / write requests for the second database node from the shared storage area of ​​the second database node in the shared storage; 2) If the number of in-transit read / write requests is zero, then take over the data block resources of the second database node.

[0043] Optionally, if the number of read / write requests in transit is not zero, the system waits. If the waiting time exceeds a preset time, the system forcibly takes over the data block resources of the second database node. If the waiting time does not exceed the preset time, the system continues to acquire the number of read / write requests in transit from the second database node. When the number of read / write requests in transit is zero, the system takes over the data block resources of the second database node.

[0044] In this embodiment, when taking over the data block resources of the second database node, the takeover operation is performed only when the number of read / write requests in transit for the second database node is zero. This avoids the data inconsistency caused by multiple nodes accessing the same data resource simultaneously during the takeover process, where the second database node has already issued read / write requests for a specific data area on the disk, but these requests have not yet completed the disk read / write operations, and the taking-over database node also needs to perform read / write operations on the data area. Furthermore, the takeover method of this application does not rely on hardware at all, but uses software to control the takeover of data block resources, thus avoiding access conflicts between the taking-over database node and the taken-over database node on the same data area on the disk.

[0045] See Figure 3 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 2 of this application. Figure 3 As shown, after waiting if the number of pending read / write requests is not zero, the following steps may also be included:

[0046] Step S301: Obtain the waiting time and check whether the waiting time exceeds the preset time.

[0047] Step S302: If the waiting time exceeds the preset time, the data block resources of the second database node are forcibly taken over.

[0048] In this embodiment of the application, the waiting time can refer to the time during which the first database node waits after detecting that the number of read / write requests in transit from the second database node is not zero. The preset time can refer to the timeout period for the first database node to wait in advance. Forced takeover can refer to forcibly setting the second database node to offline, isolating the second database node, and performing recovery operations on the data block resources of the second database node.

[0049] Specifically, if the number of read / write requests in transit for the second database node is not zero, then wait, obtain the waiting time of the first database node, check if the waiting time exceeds the preset time, and if the waiting time exceeds the preset time, then forcibly take over the data block resources of the second database node, forcibly set the second database node to offline, isolate the second database node, and perform recovery operations on the data block resources of the second database node.

[0050] In this embodiment, if the first database node waits for a period exceeding a preset time after detecting that the number of read / write requests in transit from the second database node is not zero, then the first database node forcibly takes over the data block resources of the second database node. By setting the waiting time and the forced takeover mechanism, the overall performance of the cluster system is prevented from degrading due to excessive waiting, thus ensuring the continuity of cluster services.

[0051] See Figure 4 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 3 of this application. Figure 4 As shown, after detecting whether the waiting time exceeds the preset time in step S301 above, the following steps may also be included:

[0052] Step S401: If the waiting time is detected to be within the preset time, the number of read / write requests in transit of the second database node is continuously obtained.

[0053] Step S402: When the number of read / write requests in transit is zero, take over the data block resources of the second database node.

[0054] Specifically, if the waiting time is detected to be within the preset time, the number of in-transit read and write requests of the second database node is continuously obtained. When the number of in-transit read and write requests decreases to zero, the first database node takes over the data block resources of the second database node.

[0055] While the first database node is waiting, if the failure of the second database node is not a network failure with the shared storage, the second database node can also decrement the number of in-transit read / write requests recorded in its shared storage area according to the processing progress after processing the incomplete in-transit read / write requests. When the first database node obtains that the number of in-transit read / write requests has decreased to zero, it takes over the data block resources of the second database node.

[0056] If the failure of the second database node is a network failure with the shared storage, then after processing the incomplete in-transit read and write requests, the second database node will be unable to decrement the number of in-transit read and write requests recorded in its shared storage area. In other words, the number of in-transit read and write requests continuously obtained by the first database node will not be zero. Therefore, when the waiting time exceeds the preset time, the first database node will forcibly take over the data block resources of the second database node.

[0057] In this embodiment, if the first database node detects that the number of read / write requests in transit from the second database node is not zero and the waiting time does not exceed a preset time, then it continues to acquire the number of read / write requests in transit from the second database node. When the number of read / write requests in transit decreases to zero, it takes over the data block resources of the second database node. This avoids access conflicts between the first and second database nodes to the same data area on the disk during the takeover process.

[0058] See Figure 5 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 4 of this application. Figure 5 As shown, the resource takeover method may further include the following steps:

[0059] Step S501: Upon receiving a disk read / write request from an upper-layer service, increment the number of in-transit read / write requests recorded in memory according to the disk read / write request.

[0060] Step S502: When the network connection with the shared storage is normal, write the number of in-transit read / write requests recorded in memory into the shared storage.

[0061] Step S503: Process the disk read / write request.

[0062] In this embodiment of the application, the shared storage network can refer to a storage local area network used to connect each node in the cluster with the shared disk storage device, allowing data transmission between each node and the shared disk storage device. The upper-layer service can refer to the user interface layer responsible for receiving user input.

[0063] Specifically, for any database node in the shared cluster, when it receives a disk read / write request sent by the upper-layer service, it first increments the number of in-transit read / write requests recorded in memory, for example, by one. When the network connection with the shared storage is normal, it writes the number of in-transit read / write requests recorded in memory into the shared storage area of ​​the database node in the shared storage. Then, it processes the disk read / write request.

[0064] In this embodiment, upon receiving a disk read / write request, the number of pending read / write requests recorded in memory is incremented. While the network connection to the shared storage is normal, the number of pending read / write requests recorded in memory is written to the shared storage area of ​​the database node. Then, the disk read / write request is processed. This avoids access conflicts between the taking-over database node and the taken-over database node on the same data area on the disk when the database node takes over the data block resources of the database node before completing the disk read / write operation, which would otherwise occur.

[0065] See Figure 6 This is a flowchart illustrating a resource takeover method for a shared cluster provided in Embodiment 5 of this application. Figure 6 As shown, after processing the disk read / write request in step S503 above, the following steps may also be included:

[0066] Step S601: Decrement the number of in-transit read / write requests recorded in memory.

[0067] Step S602: When the network connection with the shared storage is normal, write the number of in-transit read / write requests recorded in memory into the shared storage.

[0068] Specifically, for any database node in the shared cluster, after processing the received disk read / write requests, the number of in-transit read / write requests recorded in memory is decremented, for example, by one. When the network connection with the shared storage is normal, the number of in-transit read / write requests recorded in memory is written to the shared storage area of ​​that database node in the shared storage.

[0069] Optionally, a timed thread can be used to write the number of in-transit read / write requests recorded in memory to the shared storage area of ​​the database node in the shared storage when the network connection with the shared storage is normal.

[0070] In this embodiment, after processing the received disk read / write requests, the number of in-transit read / write requests recorded in memory is decremented. When the network connection to the shared storage is normal, the number of in-transit read / write requests recorded in memory is written to the shared storage area of ​​the database node. This avoids situations where inaccurate data entry of in-transit read / write requests leads to excessively long takeover wait times when taking over the data block resources of the database node, thus affecting the overall performance of the cluster system. It also avoids access conflicts between the taking-over database node and the taken-over database node on the same data area on the disk.

[0071] Corresponding to the resource takeover method of the shared cluster in the above embodiment, Figure 7 A structural block diagram of a resource takeover device for a shared cluster provided in Embodiment Six of this application is shown. The resource takeover device is applied to the first database node in the shared cluster. For ease of explanation, only the parts relevant to the embodiments of this application are shown.

[0072] See Figure 7 The resource takeover device includes:

[0073] The first acquisition module 71 is used to acquire the number of in-transit read / write requests of the second database node from the shared storage area of ​​the second database node in the shared storage when a failure of the second database node is detected.

[0074] The first takeover module 72 is used to take over the data block resources of the second database node if the number of in-transit read / write requests is zero.

[0075] Optionally, the resource takeover device also includes:

[0076] The waiting module is used to wait if the number of read / write requests in transit is not zero.

[0077] Optionally, the resource takeover device also includes:

[0078] The detection module is used to acquire the waiting time and detect whether the waiting time exceeds a preset time.

[0079] The second takeover module is used to forcibly take over the data block resources of the second database node if the waiting time is detected to exceed the preset time.

[0080] Optionally, the resource takeover device also includes:

[0081] The second acquisition module is used to continuously acquire the number of read / write requests in transit for the second database node if it is detected that the waiting time has not exceeded the preset time.

[0082] The third takeover module is used to take over the data block resources of the second database node when the number of read / write requests in transit is zero.

[0083] Optionally, the resource takeover device also includes:

[0084] The increment module is used to increment the number of in-transit read / write requests recorded in memory according to the disk read / write request when a disk read / write request is received from an upper-layer service.

[0085] The first write module is used to write the number of in-transit read / write requests recorded in the memory into the shared storage when the network connection with the shared storage is normal.

[0086] The processing module is used to process the disk read / write requests.

[0087] Optionally, the resource takeover device also includes:

[0088] The decrement module is used to decrement the number of in-transit read / write requests recorded in the memory.

[0089] The second write module is used to write the number of in-transit read / write requests recorded in the memory into the shared storage when the network connection with the shared storage is normal.

[0090] Optionally, the second write module mentioned above includes:

[0091] The timing unit is used to write the number of in-transit read / write requests recorded in the memory into the shared storage via a timing thread.

[0092] It should be noted that the information interaction and execution process between the above modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0093] Figure 8 This is a schematic diagram of the structure of a computer device provided in Embodiment Seven of this application. Figure 8 As shown, the computer device of this embodiment includes: at least one processor ( Figure 8 The diagram shows only one of the following: a memory and a computer program stored in the memory and executable on at least one processor. When the processor executes the computer program, it implements the steps in the page transfer method embodiments of any of the above-described shared cluster databases, or implements the steps in the resource takeover method embodiments of any of the above-described shared clusters.

[0094] This computer device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 8The examples of computer devices are merely examples and do not constitute a limitation on computer devices. Computer devices may include more or fewer components than shown in the illustration, or combinations of certain components, or different components, such as network interfaces, displays, and input devices.

[0095] The processor referred to can be a CPU, but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0096] Memory includes readable storage media, internal memory, etc., wherein internal memory can be the RAM of a computer device, providing an environment for the operation of the operating system and computer-readable instructions stored in the readable storage media. The readable storage media can be the hard drive of a computer device, or in other embodiments, it can be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, memory can include both internal storage units and external storage devices of the computer device. Memory is used to store the operating system, applications, bootloader, data, and other programs, such as program code for computer programs. Memory can also be used to temporarily store data that has been output or will be output.

[0097] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code, a recording medium, a computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0098] The implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program product. When the computer program product is run on a computer device, it enables the computer device to execute the steps in the above method embodiments.

[0099] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0100] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0101] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0102] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for resource takeover in a shared cluster, characterized in that, The resource takeover method is applied to the first database node in the shared cluster, including: When a failure is detected in the second database node, the number of read / write requests in transit for the second database node is obtained from the shared storage area of ​​the second database node in the shared storage. The read / write requests in transit refer to requests that have been sent to a specific data area of ​​the disk but have not yet completed disk read / write operations. If the number of read / write requests in transit is zero, then the data block resources of the second database node are taken over. The resource takeover method for the shared cluster also includes: Upon receiving a disk read / write request from an upper-layer service, the number of in-transit read / write requests recorded in memory is incremented according to the disk read / write request. When the network connection to the shared storage is normal, the number of in-transit requests recorded in the memory is written into the shared storage; Process the disk read / write requests; After obtaining the number of in-transit read / write requests for the second database node, the method further includes: If the number of read / write requests in transit is not zero, then wait until the waiting time exceeds the preset time or the number of read / write requests in transit becomes zero.

2. The resource takeover method for a shared cluster according to claim 1, characterized in that, After the waiting period, the following is also included: Obtain the waiting time and detect whether the waiting time exceeds the preset time; If the waiting time is detected to exceed the preset time, the data block resources of the second database node will be forcibly taken over.

3. The resource takeover method for a shared cluster according to claim 2, characterized in that, After detecting whether the waiting time exceeds a preset time, the method further includes: If the waiting time is detected to be within the preset time, the number of read / write requests in transit for the second database node is continuously acquired. When the number of read / write requests in transit is zero, the data block resources of the second database node are taken over.

4. The resource takeover method for a shared cluster according to claim 1, characterized in that, After processing the disk read / write request, the process also includes: Decrement the number of in-transit read / write requests recorded in the memory; When the network connection to the shared storage is normal, the number of in-transit requests recorded in the memory is written into the shared storage.

5. The resource takeover method for a shared cluster according to claim 4, characterized in that, The step of writing the number of in-transit requests recorded in the memory into the shared storage includes: The number of in-transit requests recorded in the memory is written to the shared storage via a timed thread.

6. A resource takeover device for a shared cluster, characterized in that, The resource takeover device is applied to the first database node in the shared cluster, and includes: The first acquisition module is used to acquire the number of in-transit read / write requests of the second database node from the shared storage area of ​​the second database node in the shared storage when a failure of the second database node is detected. The in-transit read / write request refers to a request that has been sent to a specific data area of ​​the disk but has not yet completed the disk read / write operation. The first takeover module is used to take over the data block resources of the second database node if the number of in-transit read / write requests is zero. The resource takeover device further includes: The increment module is used to increment the number of in-transit read / write requests recorded in memory according to the disk read / write request when a disk read / write request is received from an upper-layer service. The first write module is used to write the number of in-transit read / write requests recorded in the memory into the shared storage when the network connection with the shared storage is normal. The processing module is used to process the disk read / write requests; The resource takeover device further includes: The waiting module is used to wait if the number of read / write requests in transit is not zero, until the waiting time exceeds a preset time or the number of read / write requests in transit becomes zero.

7. A computer device, characterized in that, The computer device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the resource takeover method for the shared cluster as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the resource takeover method for the shared cluster as described in any one of claims 1 to 5.

Images