Shared storage database management method, system and device

Abstract

The embodiment of the invention provides a shared storage database management method, system and device. The shared storage database management method comprises the steps that lease locks in a shared storage database are traversed through function nodes corresponding to the shared storage database; under the condition that the target lease lock in the available state is traversed, occupying the target lease lock by using the function node; selecting a target node from a node cluster associated with the shared storage database, and migrating a to-be-executed data operation task of an abnormal node corresponding to the target lease lock to the target node; under the condition that task migration is completed, the target lease lock is distributed to the target node, and the target node is used for executing the to-be-executed data operation task based on the target lease lock. And smooth execution of the data operation task is ensured. The lease locks in the shared storage database are traversed by using the function nodes, the availability of the lease locks can be detected, the exception handling process can be triggered once the lease locks in the ownable state are detected, and the exception recovery time is shortened.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to methods, systems and apparatus for managing shared storage databases. Background Technology

[0002] Cloud-native databases are based on a write-multiple-read, shared-storage architecture. This type of database has only one write node, making high availability and synchronization link management relatively simple. Currently, cloud vendors are starting to implement multi-master architectures on top of shared-storage databases to evolve into the next generation of cloud-native databases. This means that multiple master nodes with read and write permissions can be mounted on the same stored data. In a multi-master architecture, although multiple master nodes have write permissions, conflict handling is required for data written to different master nodes. When providing services using shared-storage databases, reasonable exception handling strategies also need to be developed to ensure the normal operation of the shared-storage database.

[0003] In existing technologies, nodes are typically assigned specific databases they can read from and write to, allowing different nodes to access different databases and thus avoiding read / write conflicts. However, this leads to a situation where, in the event of a node malfunction, the database on the malfunctioning node cannot perform normal data read / write operations, causing the data read / write task to terminate. Therefore, there is an urgent need for a more effective shared storage database management method to address these issues. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a shared storage database management method. One or more embodiments of this specification also relate to a shared storage database management system, a shared storage database management device, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a shared storage database management method is provided, comprising:

[0006] The lease locks in the shared storage database are traversed using the functional nodes corresponding to the shared storage database;

[0007] If a target lease lock in a holdable state is found during traversal, the target lease lock is acquired using the functional node.

[0008] Select a target node in the node cluster associated with the shared storage database, and migrate the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node;

[0009] Once the task migration is complete, the target lease lock is assigned to the target node, and the target node is used to execute the data operation task to be executed based on the target lease lock.

[0010] According to a second aspect of the embodiments of this specification, a shared storage database management system is provided, including a functional node, a target node, and a shared storage node, wherein the shared storage node includes at least one lease lock.

[0011] The functional node is used to traverse the at least one lease lock contained in the shared storage node, and when a target lease lock in a holdable state is encountered, the target lease lock is occupied, the pending data operation tasks of the abnormal node corresponding to the target lease lock are migrated to the target node, and when the task migration is completed, the target lease lock is allocated to the target node.

[0012] The target node is used to execute the data operation task to be executed based on the target lease lock.

[0013] According to a third aspect of the embodiments of this specification, a shared storage database management apparatus is provided, comprising:

[0014] The traversal module is configured to traverse the lease locks in the shared storage database using the functional nodes corresponding to the shared storage database.

[0015] The occupancy module is configured to occupy the target lease lock using the functional node when a target lease lock in a holdable state is encountered during traversal.

[0016] The migration module is configured to select a target node in the node cluster associated with the shared storage database and migrate the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node;

[0017] The execution module is configured to, upon completion of task migration, allocate the target lease lock to the target node and utilize the target node to execute the data operation task to be executed based on the target lease lock.

[0018] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising:

[0019] Memory and processor;

[0020] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the above-described shared storage database management method are implemented.

[0021] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the shared storage database management method described above.

[0022] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the shared storage database management method described above.

[0023] In one embodiment of this specification, by traversing the lease locks in the shared storage database using the functional nodes corresponding to the shared storage database, a target lease lock can be acquired by the functional node when it is found to be in a holdable state. The successful acquisition of the target lease lock by the functional node indicates that the master node corresponding to the target lease lock is an abnormal node, which has failed to renew the target lease lock, resulting in the functional node successfully preempting it. At this point, a target node is selected in the node cluster associated with the shared storage database, and the pending data operation tasks of the abnormal node corresponding to the target lease lock are migrated to the target node. Once the task migration is complete, the abnormal node can be taken offline, the target lease lock is allocated to the target node, and the target node acquires the target lease lock and executes the pending data operation tasks based on the target lease lock. This ensures the smooth execution of data operation tasks and avoids termination of data operation tasks due to the abnormal state of the abnormal node. By traversing the lease locks in the shared storage database using functional nodes, the availability of lease locks can be detected. Once a lease lock in a holdable state is detected, the exception handling process can be triggered, which can reduce the complexity of the decision-making chain, improve the accuracy and timeliness of exception handling, and shorten the exception recovery time. Attached Figure Description

[0024] Figure 1 This is a schematic diagram illustrating the processing steps of a shared storage database management method provided in one embodiment of this specification;

[0025] Figure 2 This is a flowchart illustrating a shared storage database management method according to one embodiment of this specification;

[0026] Figure 3 This is a schematic diagram illustrating node exception handling in a shared storage database management method according to one embodiment of this specification;

[0027] Figure 4 This is a synchronization diagram illustrating a shared storage database management method provided in one embodiment of this specification;

[0028] Figure 5 This is a schematic diagram illustrating node replacement in a shared storage database management method according to one embodiment of this specification;

[0029] Figure 6 This is a schematic diagram illustrating the targeted replacement of nodes in a shared storage database management method provided in one embodiment of this specification;

[0030] Figure 7 This is a schematic diagram of the structure of a shared storage database management system provided in one embodiment of this specification;

[0031] Figure 8 This is a schematic diagram of the structure of a shared storage database management device provided in one embodiment of this specification;

[0032] Figure 9 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0033] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0034] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0035] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0036] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0037] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0038] Lease Lock: A mechanism used in distributed systems to achieve exclusive access to resources. Compared to traditional locking mechanisms, lease locks offer more flexible time control and better scalability.

[0039] I / O Fencing: A concept of I / O protection used to manage read and write permissions between compute nodes and storage nodes. Prohibiting a node from writing at the storage layer is called I / O Fencing.

[0040] Master node: A compute node used to provide read and write services.

[0041] Read-only node: A compute node used to provide read-only services.

[0042] Backup node: Also known as a disaster recovery node, it can generally be reused from a read-only node. After the primary node fails, it is used to replace the primary node and restore read and write services.

[0043] RTO (Recovery Time Objective): The recovery time objective mainly refers to the maximum tolerable period of system downtime, which is the shortest time period required from the occurrence of a disaster to the restoration of system service functionality.

[0044] `try_lock` refers to a non-blocking attempt to acquire a lock. If the lock is currently available, the acquisition is successful and the thread returns immediately; if the lock is already held, the attempt fails and the thread returns immediately without blocking the current thread.

[0045] `force_lock`: This command waits until the lock is available, regardless of its availability. This means that if the lock is currently held by another client, the client requesting `force_lock` will wait for the lock to be released. Once the lock becomes available, the requesting client will acquire it.

[0046] Figure 1 This is a schematic diagram illustrating the processing procedure of a data processing method provided in one embodiment of this specification; as shown below. Figure 1As shown, the shared storage database contains multiple lease locks. Nodes need to lease a lease lock to gain read and write permissions to the shared storage database. The functional nodes corresponding to the shared storage database iterate through the lease locks in the database. If a target lease lock is found to be holdable, the functional node can acquire it. A functional node successfully acquiring the target lease lock indicates that the master node corresponding to the target lease lock has not renewed it; therefore, the master node is an abnormal node, which is why the target lease lock was successfully preempted by the functional node. At this point, a target node is selected in the node cluster associated with the shared storage database, and the pending data operation tasks of the abnormal node corresponding to the target lease lock are migrated to the target node. Once the task migration is complete, the abnormal node can be taken offline, the target lease lock is assigned to the target node, and the target node leases the target lease lock and executes the pending data operation tasks based on the target lease lock. This ensures the smooth execution of data operation tasks and avoids termination of data operation tasks due to the abnormal state of the abnormal node. By traversing the lease locks in the shared storage database using functional nodes, the availability of lease locks can be detected. Once a lease lock in a holdable state is detected, the exception handling process can be triggered, which can reduce the complexity of the decision-making chain, improve the accuracy and timeliness of exception handling, and shorten the exception recovery time.

[0047] It's important to note that a lease lock is a mechanism used in distributed systems to coordinate resource access. It combines traditional locking mechanisms with the concept of a lease to manage access permissions to shared resources. The lease lock mechanism works as follows (taking a client requesting a lease lock from a lock service as an example): The client requests a lease from the lock service. If the resource is available and no other client holds a lease for that resource, the lock service grants the requester a lease and sets an expiration time. The client holding the lease can safely access the resource during the lease's validity period. The client can request renewal from the lock service before the lease expires to extend its exclusive access time. After completing its operations on the resource, the client should proactively release the lease so that other clients can request the resource. If the client fails to renew or release the lease before its expiration, the lock service will automatically reclaim the lease and may reassign it to other waiting clients.

[0048] In practical applications, in shared storage scenarios, shared storage provides multiple lease locks, each belonging to a different slot. Each slot's lease lock has an independent lock holder, and external requests can independently execute `try_lock` and `force_lock` on one or more slots. This requires adding an index parameter `slot id` to `try_lock` and `force_lock`. Changing the lock holder or write permissions of a slot does not affect the state of other slots. This provides fine-grained permission management for multi-master databases. Furthermore, an additional metadata file can simplify the maintenance of the information synchronization link. Since read-only nodes need to maintain the information synchronization link with the master node, for local read-only nodes, this synchronization link is a one-to-one relationship; for global read-only nodes, it is a many-to-one relationship. To facilitate read-only nodes quickly obtaining the addresses of one or more master nodes, a new metadata file is added for each lease lock. The metadata file is identical to a regular file and is maintained by the lock holder. When a master node successfully acquires or purchases a lock, its address (e.g., IP address, port) is updated in the metadata file.

[0049] This specification provides a shared storage database management method, and also relates to a shared storage database management system, a shared storage database management device, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0050] See Figure 2 , Figure 2 A flowchart of a shared storage database management method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0051] Step 202: Use the functional nodes corresponding to the shared storage database to traverse the lease locks in the shared storage database.

[0052] Specifically, a shared storage database is a database system in a multi-server environment where all server nodes share the same physical storage space. This architecture is designed to improve system scalability and availability while reducing maintenance costs. In a shared storage database architecture, each server node can directly access data stored on the shared storage device without needing to replicate or synchronize data copies. A function node is one of the server nodes, or it can be a node created for the shared storage server that coordinates and supervises the server nodes in the shared storage database. Function nodes can detect abnormal nodes corresponding to the shared storage database and then handle these abnormalities. A lease lock is a mechanism used in distributed systems to achieve exclusive access to resources. A server node corresponding to the shared storage database can obtain read and write permissions for the data corresponding to the lease lock by leasing a lease lock.

[0053] Based on this, at least one lease lock in the shared storage database is identified. The function node corresponding to the shared storage database is used to traverse the lease locks in the shared storage database. The function node attempts to rent the lease lock rented by the server node. If the server node does not renew the lease lock it has rented for a long time, the function node can successfully rent the lease lock that the server node has rented and has not renewed for a long time.

[0054] Furthermore, considering that the functional node itself does not have the ability to traverse the lease locks in the shared storage database, the functional node can create a background thread to complete the traversal of the lease locks in the shared storage database. The specific implementation is as follows:

[0055] A background thread is created using the functional node corresponding to the shared storage database; the background thread is then used to traverse the lease locks in the shared storage database based on the lease lock traversal order.

[0056] Specifically, the background thread iterates through the lease locks in the shared storage database by attempting to renew each lease lock. The order in which the lease locks are traversed can be the order in which they are listed in the shared storage database. The purpose of using the function node to traverse the lease locks in the shared storage database is to find lease locks that have not been renewed for a long time and lease them.

[0057] Based on this, a background thread is created using the functional node corresponding to the shared storage database. This background thread iterates through the lease locks in the shared storage database one by one, following the lease lock traversal order. During this process, each lease lock is attempted to be leased by the functional node. A successful lease lease by the functional node indicates that the lease lock has not been renewed for a long time and is in an expired state. The functional node then polls the lease locks in the shared storage database until a particular lease lock is successfully acquired. At this point, it indicates that the server node corresponding to that lease lock has failed.

[0058] For example, in a shared storage scenario, shared storage provides multiple lease locks, each belonging to a different storage location. Each lease lock in a storage location has an independent lock holder, and external requests can independently execute `try_lock` and `force_lock` on one or more lease locks. A server node in the shared storage database only gains read and write permissions to data if it successfully leases a lock. Lease locks have an expiration date, and the server node group must renew the lease when it expires. Functional nodes can probe the server nodes of the shared storage database by iterating through the lease locks to check for server node failures. Functional nodes create background threads to iterate through the lease locks in the shared storage database, polling for locks and attempting to lease them; a successful lease indicates that a faulty server node has been detected.

[0059] In summary, creating a background thread using a functional node and then using that background thread to traverse the lease locks in the shared storage database can improve the efficiency of traversing lease locks.

[0060] Step 204: If a target lease lock in a holdable state is found during traversal, the target lease lock is acquired using the functional node.

[0061] Specifically, after traversing the lease locks in the shared storage database using the corresponding functional nodes, a target lease lock in a holdable state can be acquired by the functional node. A target lease lock in a holdable state refers to a lease lock that has not been leased by a server node for an extended period, and the server node has been unavailable for a duration exceeding a certain threshold. The duration threshold can be the lease duration set for the lease lock. Acquiring the target lease lock using a functional node involves writing the functional node's node information into the target lease lock's metadata; successful writing indicates that the functional node has successfully leased the target lease lock.

[0062] Based on this, when the functional node corresponding to the shared storage database traverses the lease locks in the shared storage database and finds a target lease lock in a holdable state, the functional node can occupy the target lease lock and write the node information of the functional node into the metadata of the target lease lock. Successful writing indicates that the functional node has leased the target lease lock.

[0063] Furthermore, in the shared storage database, all lease locks exist on leased nodes. Lease locks that have not been renewed by nodes and whose non-renewal duration exceeds the lease duration can be considered to be in a holdable state. The determination of a target lease lock in a holdable state includes:

[0064] Identify n lease locks in the shared storage database; identify the i-th lease lock among the lease locks, where i starts from 1 and is a positive integer; if the i-th lease lock is in an unserviceable state, determine the duration of the unserviceability of the i-th lease lock; determine whether the duration of the unserviceability of the i-th lease lock is greater than a duration threshold; if not, increment i by 1 and execute the step of identifying the i-th lease lock among the lease locks; if yes, determine that the i-th lease lock is in a holdable state and use the i-th lease lock as the target lease lock.

[0065] Specifically, the leasing node for the i-th lease lock is node i. When the i-th lease lock expires, node i can renew the lease lock within the lease duration. If node i is in an unserviceable state for an extended period, and the duration of this unserviceable state exceeds a duration threshold, it indicates that the i-th lease lock is in an overdue state. Therefore, the duration of the unserviceable state of the i-th lease lock exceeds the duration threshold. The i-th lease lock being in an overdue state means that it is in a holdable state.

[0066] Based on this, n lease locks are identified in the shared storage database. Among these, the first lease lock is determined. If the first lease lock is not renewed, it is in an unserviceable state. The duration of the unserviceability of the i-th lease lock is determined, and it is judged whether the duration exceeds a duration threshold. If not, it means the first lease lock was not renewed, but the duration of non-renewal is relatively short. In this case, the second lease lock is identified from the n lease locks, and a candidate is determined. If yes, it means the first lease lock was not renewed, and the duration of non-renewal is relatively long, indicating it has expired. In this case, the first lease lock is determined to be in a holdable state, and it is designated as the target lease lock.

[0067] Using the previous example, if the shared storage database contains lease lock 1, lease lock 2 and lease lock 3, lease lock 1 is determined first according to the label order. It is then determined whether lease lock 1 is in an unserviceable state. If lease lock 1 is not leased, it can be determined that lease lock 1 is in an unserviceable state. If the duration of the unserviceable state of lease lock 1 is greater than the duration threshold, it means that lease lock 1 is in an expired state, and then lease lock 1 is taken as the target lease lock.

[0068] In summary, polling the lease locks in the shared storage database in a convenient manner until a target lease lock with an unservice duration greater than a duration threshold is obtained improves the accuracy of target lease lock determination.

[0069] Step 206: Select the target node in the node cluster associated with the shared storage database, and migrate the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node.

[0070] Specifically, after encountering a target lease lock in a holdable state, and using a functional node to acquire the target lease lock, a target node can be selected from the node cluster associated with the shared storage database. The pending data operation tasks of the abnormal node corresponding to the target lease lock can then be migrated to the target node. Here, the node cluster refers to the cluster where the server nodes of the shared storage database reside. The target node can be a master node holding other lease locks in the node cluster, or it can be a functional node. An abnormal node refers to a server node that has leased the target lease lock and whose unserviceability duration exceeds a certain threshold. Pending data operation tasks refer to data operation tasks that the abnormal node has not yet executed; these tasks can be data read / write tasks.

[0071] Based on this, when a target lease lock in a holdable state is encountered during the traversal, it indicates that the target lease lock has not been renewed for a long time, the renewal status of the target lease lock is abnormal, and the target lease lock is in an overdue and unrenewed state. At this time, a functional node can be used to occupy the target lease lock, and a target node that can take over the abnormal node from the node cluster associated with the shared storage database can be selected to continue processing the pending data operation tasks, or a target node that can assist the abnormal node in processing the pending data operation tasks can be selected. The pending data operation tasks of the abnormal node corresponding to the target lease lock can then be migrated to the target node.

[0072] Furthermore, functional nodes can be coordination nodes. After identifying an abnormal node, node coordination is performed to determine a primary node to take over from the abnormal node and continue executing the pending data operation tasks. The specific implementation is as follows:

[0073] When the functional node is a coordinating node, it means that the functional node acts as a relay node. The first master node associated with the abnormal node is selected in the node cluster associated with the shared storage database, and the first master node is used as the target node.

[0074] Specifically, the coordinating node is used to probe the availability of server nodes in the shared storage database and perform anomaly detection on the server nodes in the shared storage database. If an abnormal node is detected, the coordinating node can act as a relay node to temporarily take over the write point of the abnormal node and migrate the write point of the abnormal node to other master nodes in the shared storage database.

[0075] Based on this, the first master node associated with the abnormal node is selected from the node cluster related to the shared storage database. The first master node can be any master node corresponding to the shared storage database, and both the first master node and the abnormal master node are master nodes of the shared storage database. The first master node is used as the target node, and it takes over the data operation tasks to be performed from the abnormal node.

[0076] Using the previous example, the shared storage database corresponds to multiple master nodes. If the lease lock is determined to be an abnormal node by using the function node to traverse the lease lock, then master node 2 is selected as the first master node. After the write point of master node 1 is migrated to master node 2 by the function node, master node 2 can take over from master node 1 and continue to execute the pending data operation tasks of master node 1.

[0077] In summary, when the functional node is the coordinating node, the coordinating node can select the first primary node as the backup node for the abnormal node, take over from the abnormal primary node to continue executing the data operation tasks to be executed, thereby ensuring that the data operation tasks to be executed can be executed smoothly, and also realizing abnormal recovery.

[0078] Furthermore, a functional node can also be a backup node, used to take over from an abnormal node and continue executing the pending data operation tasks of the abnormal node. The specific implementation is as follows:

[0079] When the functional node is a backup node, selecting the target node in the node cluster associated with the shared storage database includes: using the functional node as the target node; after migrating the pending data operation task of the abnormal node corresponding to the target lease lock to the target node, it further includes: when the task migration is completed, using the target node to execute the pending data operation task based on the target lease lock.

[0080] Specifically, a backup node refers to a standby node, which is also a disaster recovery node for abnormal nodes.

[0081] Based on this, when a functional node is a backup node, it means that the functional node plays a disaster recovery role, and thus the functional node can be used as the target node. After migrating the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node, once the task migration is complete, it means that the target node can now take over from the abnormal node, and the pending data operation tasks can be executed using the target node based on the target lease lock.

[0082] In addition, functional nodes can also be globally read-only nodes, capable of identifying abnormal nodes by polling lease locks in the shared storage database, and acting as disaster recovery nodes to take over the pending data operation tasks from the abnormal nodes. After the abnormal node is identified, both the globally read-only node and the backup node can synchronize the pending data operation tasks of the abnormal node through the synchronization link.

[0083] Using the previous example, if the function node is used to traverse the lease lock and determine that the master node 1 is an abnormal node, the function node can be used as the target node to continue executing the data operation tasks to be performed by the abnormal node.

[0084] In summary, when the functional node is a backup node, the backup node can serve as a disaster recovery node for the abnormal node, taking over the execution of pending data operation tasks that the abnormal node has not yet completed. This enables node disaster recovery for the shared storage database, ensuring the efficiency and security of data reading and writing.

[0085] Furthermore, after the functional node is used as the target cutoff point and the target node executes the data operation task based on the target lease lock, there is a lack of functional nodes for traversing the lease locks in the shared storage database. A backup functional node can be constructed to take over the node probing task from the functional node. The specific implementation is as follows:

[0086] For the shared storage database, a backup functional node is constructed, and the backup functional node is used as the functional node. The step of traversing the lease locks in the shared storage database using the functional node corresponding to the shared storage database is then executed.

[0087] Specifically, the backup functional node is used to take over from the functional node to continue probing the nodes corresponding to the shared storage database and to traverse the lease locks in the shared storage database in order to detect whether there is an abnormal master node.

[0088] Based on this, a backup functional node is constructed for the shared storage database, and the backup functional node is used as a functional node. The backup functional node can be used to continue to traverse the lease locks in the shared storage database to detect whether there is an abnormal master node in the shared storage database.

[0089] Using the previous example, when replacing the abnormal node with a functional node as the target node, the operations and maintenance personnel or the management platform can add a backup functional node for the shared storage database. The backup functional node can take over from the functional node and continue to probe the corresponding master node of the shared storage database by traversing the lease locks.

[0090] In summary, by constructing backup functional nodes for shared storage databases and using these backup functional nodes as functional nodes, the backup functional nodes can take over from the functional nodes and continue to probe the corresponding master nodes of the shared storage database by traversing lease locks, thus enabling timely detection of nodes in abnormal states corresponding to the shared storage databases.

[0091] Step 208: After the task migration is completed, the target lease lock is assigned to the target node, and the target node is used to execute the data operation task to be executed based on the target lease lock.

[0092] Specifically, after selecting the target node in the node cluster associated with the shared storage database and migrating the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node, the target lease lock can be allocated to the target node after the task migration is completed, and the target node can be used to execute the pending data operation tasks based on the target lease lock until the pending data operation tasks are completed.

[0093] Based on this, in the node cluster associated with the shared storage database, a target node is selected. After migrating the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node, the migration is complete, indicating that the pending data operation tasks of the abnormal node can be taken over by the target node, and the abnormal node can be taken offline. The target lease lock is assigned to the target node, giving the target node read and write permissions to the data corresponding to the abnormal node. At this point, the target node can be used to execute the pending data operation tasks based on the target lease lock until the pending data operation tasks are completed.

[0094] Furthermore, considering that the master node in the shared storage database can choose to lease a lock or choose not to continue leasing the lock after the lease duration expires, and that the functional node is a partially read-only node, the functional node needs to maintain the synchronization link. The specific implementation is as follows:

[0095] When the functional node is a local read-only node, determine the local maintenance node corresponding to the local read-only node; use the local read-only node to read the local lease lock metadata of the local maintenance node; and when the local lease lock metadata meets the local data change conditions, update the local information synchronization link of the local maintenance node.

[0096] Specifically, a functional node is a locally read-only node, meaning that the functional node only performs node fault detection and maintenance on local maintenance nodes. A local maintenance node is the object being maintained by a locally read-only node. Local lease lock metadata refers to the data written to the metadata corresponding to the lease lock when the local maintenance node leases the lease lock. Local data change conditions refer to whether the local lease lock metadata has changed. If the local lease lock metadata read for the first time is different from the local lease lock metadata read for the second time, it means that the local lease lock metadata meets the local data change conditions, and it also means that the lease lock leased by the local maintenance node has been leased by another node.

[0097] Based on this, when a functional node is a locally read-only node, a corresponding locally maintenance node is determined. The locally read-only node only performs node maintenance on the locally maintenance node. The locally lease lock metadata of the locally maintenance node is read using the locally read-only node. If the locally lease lock metadata meets the local data change conditions, it indicates that the locally lease lock metadata read in the first reading is different from the locally lease lock metadata read in the second reading, meaning the lease lock leased by the locally maintenance node has been leased by another node, and the local information synchronization link of the locally maintenance node is updated.

[0098] Using the previous example, a local read-only node is set up for master node 1. The local read-only node periodically reads the metadata of lease lock 1 leased by master node 1. If the metadata read twice is different, it is determined that lease lock 1 is leased by another master node, and then the information synchronization link of master node 1 is modified.

[0099] In summary, when the functional node is a locally read-only node and the local lease lock metadata meets the local data change conditions, the local information synchronization link of the local maintenance node is updated, and the synchronization link of the local maintenance node is maintained to ensure data consistency.

[0100] Furthermore, considering that the master node in the shared storage database can choose to lease a lock or choose not to continue leasing the lock after the lease duration expires, and assuming the functional node is a globally read-only node, the functional node needs to maintain the synchronization link. The specific implementation is as follows:

[0101] When the functional node is a global read-only node, determine at least one global maintenance node corresponding to the global read-only node; traverse and read the global lease lock metadata of the at least one global read-only node according to the node traversal order until the target global lease lock metadata that meets the global data change conditions is obtained, and update the target global information synchronization link of the target global maintenance node corresponding to the target global lease lock metadata.

[0102] Specifically, a functional node is a globally read-only node, meaning it can probe the global master node of the shared storage database. The global master node is at least one globally maintained node corresponding to the shared storage database. This global maintained node is the object maintained by the functional node. The node traversal order can be the order in which the nodes among the at least one globally maintained node are arranged. Global lease lock metadata refers to the data written to the metadata corresponding to the lease lock when at least one globally read-only node leases the lease lock. Global data change conditions refer to whether the global lease lock metadata has changed. If the global lease lock metadata read for the first time is different from the global lease lock metadata read for the second time, it means that the global lease lock metadata meets the global data change conditions, and it also means that the lease lock leased by the globally maintained node has been leased by another node.

[0103] Based on this, when a functional node is a globally read-only node, at least one globally maintenance node is identified corresponding to the globally read-only node. The globally read-only node performs node maintenance for at least one globally maintenance node. The global lease lock metadata of at least one globally read-only node is traversed and read according to the node traversal order. It is determined whether the read global lease metadata meets the global data change conditions. If it does not meet the conditions, it means that the global lease metadata read in the first instance is the same as the global lease metadata read in the second instance, and the global lease lock metadata of the next globally read-only node can be read. If the conditions are met, it means that the global lease metadata read in the first instance is different from the global lease metadata read in the second instance. At this time, the target global information synchronization link of the target globally maintenance node corresponding to the target global lease lock metadata is updated.

[0104] Continuing with the previous example, in a shared storage database with two master nodes, a global read-only node is set up for master node 1 and master node 2. This global read-only node periodically and sequentially reads the metadata of lease lock 1 and lease lock 2 leased by master node 1 and master node 2. If the metadata of lease lock 1 reads differently in two separate reads, it is determined that lease lock 1 is leased by another master node, and the information synchronization link of master node 1 is modified. If the metadata of lease lock 1 reads is the same in two separate reads, the metadata of lease lock 2 is read. If the metadata of lease lock 2 reads differently in two separate reads, it is determined that lease lock 2 is leased by another master node, and the information synchronization link of master node 2 is modified.

[0105] In summary, when the functional node is a globally read-only node, by traversing the global lease lock metadata of at least one globally read-only node, the synchronization link of at least one globally maintenance node is maintained to ensure data consistency.

[0106] Furthermore, the functional node can be the primary local read-only node corresponding to the second primary node of the shared storage database, used for exception handling of the second primary node to achieve high availability of the second primary node, as specifically implemented below:

[0107] When the functional node is the primary local read-only node corresponding to the second primary node of the shared storage database, a polling time is determined, and the primary local read-only node polls the primary lease lock corresponding to the second primary node based on the polling time; if the primary lease lock is determined to be in an overdue state based on the polling result, the primary local read-only node occupies the primary lease lock, and the primary operation task corresponding to the second primary node is synchronized to the primary local read-only node based on the primary synchronization link between the second primary node and the primary local read-only node.

[0108] Specifically, the primary partial read-only node is a partial read-only node set up specifically for the secondary primary node, performing anomaly detection only on the secondary primary node. The secondary primary node can be any primary node corresponding to the shared storage database. The polling time refers to the time interval for querying the lease locks leased by the secondary primary node. The polling result refers to the leasing result of the lease locks leased by the secondary primary node using the primary partial read-only node. If the primary partial read-only node successfully leases the lease locks leased by the secondary primary node, it indicates that the lease locks leased by the secondary primary node are in an expired state, meaning the lease locks have not been renewed by the secondary primary node for an extended period, and the secondary primary node is in a faulty state.

[0109] Based on this, when the functional node is the primary local read-only node corresponding to the second primary node of the shared storage database, the primary local read-only node only performs anomaly detection on the second primary node. A polling time is determined, and the primary local read-only node polls the primary lease lock corresponding to the second primary node based on the polling time, attempting to lease the primary lease lock. If the polling result determines that the primary lease lock is in an expired state, it indicates that the primary lease lock has not been renewed by the second primary node for a long time, and the primary local read-only node successfully leases the primary lease lock. The primary local read-only node then occupies the primary lease lock. A primary synchronization link is constructed between the second primary node and the primary local read-only node, and the primary operation tasks corresponding to the second primary node are synchronized to the primary local read-only node based on this link. The primary local read-only node then replaces the second primary node and continues data operations.

[0110] Using the previous example, if the functional node is a local read-only node set up for the master node 1, the functional node only probes the master node 1. If an anomaly is detected in the master node 1, a synchronization link is established between the functional node and the master node 1, and the functional node takes over from the master node 1 to continue reading and writing data.

[0111] In summary, a functional node can be a primary local read-only node corresponding to the second primary node of a shared storage database. It is used to handle exceptions for the second primary node and can specifically achieve high availability for the second primary node.

[0112] In one embodiment of this specification, by traversing the lease locks in the shared storage database using the functional nodes corresponding to the shared storage database, a target lease lock can be acquired by the functional node when it is found to be in a holdable state. The successful acquisition of the target lease lock by the functional node indicates that the master node corresponding to the target lease lock is an abnormal node, which has failed to renew the target lease lock, resulting in the functional node successfully preempting it. At this point, a target node is selected in the node cluster associated with the shared storage database, and the pending data operation tasks of the abnormal node corresponding to the target lease lock are migrated to the target node. Once the task migration is complete, the abnormal node can be taken offline, the target lease lock is allocated to the target node, and the target node acquires the target lease lock and executes the pending data operation tasks based on the target lease lock. This ensures the smooth execution of data operation tasks and avoids termination of data operation tasks due to the abnormal state of the abnormal node. By traversing the lease locks in the shared storage database using functional nodes, the availability of lease locks can be detected. Once a lease lock in a holdable state is detected, the exception handling process can be triggered, which can reduce the complexity of the decision-making chain, improve the accuracy and timeliness of exception handling, and shorten the exception recovery time.

[0113] The following is in conjunction with the appendix Figure 3 Taking the shared storage database management method provided in this specification as an example of its application where multiple master nodes act as backup nodes for each other, the shared storage database management method will be further explained. Figure 3 This diagram illustrates a node exception handling method for a shared storage database management method according to an embodiment of this specification. The first application scenario is as follows: Figure 3As shown, the shared storage database provides multiple lease locks, from Lease Lock 1 to Lease Lock Max. Each lease lock has an independent lock holder (there are cases where a lease lock has no holder. Lease locks can be created in advance; if 128 lease locks are created by default, and the master node only has 2, then the lease lock may have no holder). Master node 1 holds Lease Lock 1, and master node 2 holds Lease Lock 2. When master node 1 leases Lease Lock 1, the address information of master node 1 is updated as metadata 1 in the metadata file corresponding to Lease Lock 1. The lock holder has write permissions for storage. Lease locks have a certain lease time. When a lease lock expires, master node 1 can renew Lease Lock 1 using the try_lock method (renewal must be done before the current lease expires. The renewal period must be shorter than the lease duration; otherwise, the node corresponding to the lease lock may be mistakenly considered faulty due to untimely renewal). Similarly, master node 2 can also renew Lease Lock 2 using the try_lock method. The main task of the coordinating node is to detect the availability of master node 1-Max using try_lock, temporarily take over the write point as a relay node, and migrate the write point to other master nodes.

[0114] When a master node becomes unavailable, any other master node can take over the load of that write point. The coordinating node is a stateless process with low cost, requiring only minimal CPU and memory resources. It does not provide external services; it acts solely as a relay for write point migration. Furthermore, during the migration decision-making process, the coordinating node can also probe the load status of different master nodes to implement custom load balancing strategies.

[0115] In practical applications, each master node corresponds to a lease lock. Each master node creates a background thread to perform a `try_lock` operation to renew the lease for its specified duration. Normally, all lease locks are held by their respective master nodes. The coordinating node also has a background thread that periodically polls each lease lock and performs a `try_lock` operation on each. Since all master nodes renew their leases successfully, the coordinating node's `try_lock` operation will fail. When master node 1 fails, such as due to a host crash, and the unavailability lasts longer than the predefined lease duration (1-5 seconds), lease lock 1 will expire. At this point, when the coordinating node polls for lease lock 1, it will successfully acquire the lock, indicating that master node 1 has been detected as faulty. At this time, a write point migration can be initiated. During the migration process, the coordinating node will continue to renew leases. Once the migration task is completed, the coordinating node stops renewing leases, returns to the probing state, and continues probing for other lease locks besides lease lock 1.

[0116] In addition, for lease lock 1, the coordinating node can periodically read metadata 1. When it detects an update to metadata 1 (indicating that the primary node 1 has recovered from a failure), it automatically initiates a write point migration operation, rolling back the previous migration behavior and restoring the cluster to its initial state. If metadata 1 remains unupdated for an extended period, the write point instance is considered offline. When restarting the write point, a notification message can be sent to instruct the coordinating node to restart probing lease lock 1. It should be noted that since no backup node is configured, the total resources of the cluster decrease if a primary node fails. Therefore, a write point migration operation is required in the first application scenario. If redundant resources such as backup nodes or globally read-only nodes are configured, a write point migration operation is not needed.

[0117] The second application scenario is that locally read-only nodes and globally read-only nodes can maintain the information synchronization link with respect to the master node. For example... Figure 4 As shown, the shared storage database provides multiple lease locks, from Lease Lock 1 to Lease Lock Max. Local read-only nodes connect to master node 1, and global read-only nodes connect to both master node 1 and master node 2. Local read-only nodes can create a background thread to periodically read information from metadata 1, automatically modifying the information synchronization link when the address in metadata 1 changes. For global read-only nodes, a background thread can be created to periodically and cyclically read metadata information from master node 1 and master node 2, automatically modifying the information synchronization link for that part when the address of a certain metadata changes.

[0118] The third application scenario involves using a dedicated backup node or a globally read-only node to achieve "one-to-many backup." This means using a single backup node as a disaster recovery backup for multiple primary nodes. The backup node uses the same CPU and memory resources as the primary node and is idle most of the time. When a primary node fails, the backup node's resources can directly take over the load of the original primary node. For example... Figure 5 As shown, the shared storage database provides multiple lease locks, from Lease Lock 1 to Lease Lock Max. Master Node 1 holds Lease Lock 1, and Master Node 2 holds Lease Lock 2. Master Node 1 can renew Lease Lock 1 using the `try_lock` method, and similarly, Master Node 2 can renew Lease Lock 2 using the same method. Backup nodes or globally read-only nodes periodically poll each lease lock and execute a `try_lock` operation on each. Backup nodes or globally read-only nodes have their own synchronization links with Master Node 1 and Master Node 2.

[0119] The functions of the standby node and the coordination node are similar. Taking the standby node as an example, the standby node creates a background thread to periodically poll each lease lock from 1 to Max and perform a try_lock operation on each lease lock. Since all master nodes renew their leases normally, the try_lock of the standby node will fail. When master node 1 fails and the duration of being unavailable exceeds the predefined lease duration, lease lock 1 will be in an expired state. When the standby node polls lease lock 1, it will succeed in locking, indicating that master node 1 is detected to be faulty. After successfully try_locking lease lock 1, the standby node is upgraded to the new master node 1 to provide services externally. After such a round of high-availability switchover, the number of master nodes in the entire cluster remains unchanged, and one standby node is missing. Then, an operator or the management platform can add a new standby node. At the same time, the "N standby M" function is also supported, where N < M, N is the number of master nodes, and M is the number of standby nodes or global read-only nodes. It can tolerate up to N master nodes failing simultaneously, but it depends on more resource reservation. In addition, the standby node also serves as a global read-only node. While performing try_lock on each lease lock, the standby node reads all lease lock metadata information to maintain the information synchronization link. Most of the time, it only serves non-critical read-only tasks externally. When a high-availability switchover is triggered, these non-critical read-only tasks are downgraded, and the resources are left for the load of the original master node. In this scenario, resources can be fully utilized, and when a failure occurs, the service quality of critical tasks is prioritized.

[0120] In the fourth application scenario, high availability of a single master node is achieved with the help of local read-only nodes. Local read-only nodes can be added separately for a certain master node. This requirement is generally for tasks in a multi-tenant scenario. For example, a certain tenant serves important customers or critical tasks and does not want to share resources with other nodes. Therefore, a master node is created for such requests, and the read-only service also does not share the global read-only but uses independent resources, that is, local read-only nodes are used. As Figure 6As shown, the shared storage database provides multiple lease locks, from Lease Lock 1 to Lease Lock Max. Master Node 1 holds Lease Lock 1, and Master Node 2 holds Lease Lock 2. Master Node 1 can renew Lease Lock 1 using the `try_lock` method, and similarly, Master Node 2 can renew Lease Lock 2 using the same method. A partial read-only node is added to Master Node 1, establishing a synchronization link between the partial read-only node and Master Node 1. The partial read-only node periodically probes Lease Lock 1 using the `try_lock` method, i.e., it periodically polls Lease Lock 1 and executes the `try_lock` operation. When Master Node 1 fails and the unservice duration exceeds the predefined lease duration, Lease Lock 1 will be in an expired state. The partial read-only node will successfully acquire the lock, indicating that it has detected the failure of Master Node 1, and the partial read-only node will be promoted to the new Master Node 1, providing services. After such a high-availability switchover, the number of master nodes in the entire cluster remains unchanged, but one partial read-only node is removed. A new partial read-only node can then be added back to Master Node 1 by operations personnel or the management platform.

[0121] In this embodiment, the detection, triggering, and execution of high availability logic are directly integrated within the database system, resulting in a simple decision-making chain, fewer dependencies, and higher accuracy and efficiency. This can provide a higher RTO for the data. Using multiple lease locks to implement independent permission management is suitable for multi-master architecture databases that support multi-point write functionality. For multi-master shared storage databases, high availability schemes for different node types are described based on the lease lock interface and metadata files, including coordinating nodes, standby nodes, locally read-only nodes, and globally read-only nodes.

[0122] Corresponding to the above method embodiments, this specification also provides embodiments of a shared storage database management system. Figure 7 A schematic diagram of the structure of a shared storage database management system according to one embodiment of this specification is shown. Figure 7 As shown, the shared storage database management system 700 includes a functional node 710, a target node 720, and a shared storage node 730. The functional node 710 is used to traverse at least one lease lock contained in the shared storage node 730. If a target lease lock in a holdable state is encountered, the functional node 710 acquires the target lease lock and migrates the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node 720. After the task migration is completed, the functional node 710 assigns the target lease lock to the target node 720. The target node 720 is used to execute the pending data operation tasks based on the target lease lock.

[0123] In practical applications, a shared storage database includes functional nodes and shared storage nodes. Each shared storage node contains multiple lease locks, each corresponding to a different SLOT (Site Rank). Each SLOT corresponds to a write node for the database, where the write node can be the master node of the shared storage database. The shared storage database management system includes functional nodes, target nodes, and shared storage nodes. Each shared storage node contains at least one lease lock. Functional nodes iterate through the at least one lease lock contained in the shared storage node. If a target lease lock in a holdable state is found, the functional node acquires the target lease lock and migrates the pending data operation tasks from the abnormal node corresponding to the target lease lock to the target node. Once the task migration is complete, the target lease lock is allocated to the target node. The target node executes the pending data operation tasks based on the target lease lock. In the shared storage database management system, functional nodes iterate through the lease locks in the shared storage database, and if a target lease lock in a holdable state is found, the functional node acquires the target lease lock. If a functional node successfully acquires the target lease lock, it indicates that the master node corresponding to the target lease lock is an abnormal node. This master node failed to renew the target lease lock, causing the functional node to successfully preempt it. In this case, the target node is selected in the node cluster associated with the shared storage database, and the pending data operation tasks of the abnormal node corresponding to the target lease lock are migrated to the target node.

[0124] Once the task migration is complete, the abnormal node can be taken offline, and the target lease lock can be allocated to the target node, which will then hold the target lease lock. The target node executes the pending data operation tasks based on the target lease lock. This ensures the smooth execution of data operation tasks and avoids termination of data operation tasks due to the abnormal state of the abnormal node. Functional nodes can traverse the lease locks in the shared storage database and detect lease lock availability. Once a holdable lease lock is detected, the exception handling process is triggered, which reduces the complexity of the decision-making chain, improves the accuracy and timeliness of exception handling, and shortens the exception recovery time.

[0125] The above is an illustrative scheme of a shared storage database management system according to this embodiment. It should be noted that the technical solution of this shared storage database management system and the technical solution of the shared storage database management method described above belong to the same concept. Details not described in detail in the technical solution of the shared storage database management system can be found in the description of the technical solution of the shared storage database management method described above.

[0126] Corresponding to the above method embodiments, this specification also provides embodiments of a shared storage database management device. Figure 8 A schematic diagram of a shared storage database management device according to one embodiment of this specification is shown. Figure 8 As shown, the device includes:

[0127] Traversal module 802 is configured to traverse the lease locks in the shared storage database using the functional nodes corresponding to the shared storage database;

[0128] The occupancy module 804 is configured to occupy the target lease lock using the functional node when the target lease lock in a holdable state is encountered during traversal.

[0129] Migration module 806 is configured to select a target node in the node cluster associated with the shared storage database and migrate the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node;

[0130] The execution module 808 is configured to, upon completion of task migration, allocate the target lease lock to the target node and utilize the target node to execute the data operation task to be executed based on the target lease lock.

[0131] In an optional embodiment, the traversal module 802 is further configured to:

[0132] In the case that the functional node is a locally read-only node, determine the local maintenance node corresponding to the locally read-only node;

[0133] The local lease lock metadata of the local maintenance node is read using the local read-only node. If the local lease lock metadata meets the local data change conditions, the local information synchronization link of the local maintenance node is updated.

[0134] In an optional embodiment, the traversal module 802 is further configured to:

[0135] In the case that the functional node is a globally read-only node, at least one globally maintenance node corresponding to the globally read-only node is determined;

[0136] The global lease lock metadata of at least one global read-only node is traversed and read according to the node traversal order until the target global lease lock metadata that meets the global data change conditions is obtained, and the target global information synchronization link of the target global maintenance node corresponding to the target global lease lock metadata is updated.

[0137] In an optional embodiment, the traversal module 802 is further configured to:

[0138] Create a background thread using the functional node corresponding to the shared storage database;

[0139] The background thread is used to traverse the lease locks in the shared storage database based on the lease lock traversal order.

[0140] In an optional embodiment, the occupancy module 804 is further configured to:

[0141] Identify n lease locks in the shared storage database;

[0142] The i-th lease lock is determined in the lease locks, where i starts from 1 and is a positive integer;

[0143] If the i-th lease lock is in an unserviceable state, determine the duration of the unserviceability of the i-th lease lock;

[0144] Determine whether the unserviceable duration of the i-th lease lock is greater than the duration threshold;

[0145] If not, increment i by 1 and perform the step of determining the i-th lease lock in the lease lock;

[0146] If so, determine that the i-th lease lock is in a holdable state, and set the i-th lease lock as the target lease lock.

[0147] In an optional embodiment, the migration module 806 is further configured to:

[0148] In the node cluster associated with the shared storage database, select the first master node associated with the abnormal node, and use the first master node as the target node.

[0149] In an optional embodiment, the migration module 806 is further configured to:

[0150] The functional node is used as the target node;

[0151] After migrating the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node, the process further includes:

[0152] Once the task migration is complete, the target node is used to execute the pending data operation task based on the target lease lock.

[0153] In an optional embodiment, the traversal module 802 is further configured to:

[0154] For the shared storage database, a backup functional node is constructed, and the backup functional node is used as the functional node. The step of traversing the lease locks in the shared storage database using the functional node corresponding to the shared storage database is then executed.

[0155] In an optional embodiment, the traversal module 802 is further configured to:

[0156] When the functional node is the primary local read-only node corresponding to the second primary node of the shared storage database, the polling time is determined, and the primary local read-only node is used to poll the primary lease lock corresponding to the second primary node based on the polling time;

[0157] If the primary lease lock is determined to be in an overdue state based on the polling results, the primary local read-only node is used to occupy the primary lease lock, and the primary operation task corresponding to the second primary node is synchronized to the primary local read-only node based on the primary synchronization link between the second primary node and the primary local read-only node.

[0158] In one embodiment of this specification, by traversing the lease locks in the shared storage database using the functional nodes corresponding to the shared storage database, a target lease lock can be acquired by the functional node when it is found to be in a holdable state. The successful acquisition of the target lease lock by the functional node indicates that the master node corresponding to the target lease lock is an abnormal node, which has failed to renew the target lease lock, resulting in the functional node successfully preempting it. At this point, a target node is selected in the node cluster associated with the shared storage database, and the pending data operation tasks of the abnormal node corresponding to the target lease lock are migrated to the target node. Once the task migration is complete, the abnormal node can be taken offline, the target lease lock is allocated to the target node, and the target node acquires the target lease lock and executes the pending data operation tasks based on the target lease lock. This ensures the smooth execution of data operation tasks and avoids termination of data operation tasks due to the abnormal state of the abnormal node. By traversing the lease locks in the shared storage database using functional nodes, the availability of lease locks can be detected. Once a lease lock in a holdable state is detected, the exception handling process can be triggered, which can reduce the complexity of the decision-making chain, improve the accuracy and timeliness of exception handling, and shorten the exception recovery time.

[0159] The above is an illustrative scheme of a shared storage database management device according to this embodiment. It should be noted that the technical solution of this shared storage database management device and the technical solution of the aforementioned shared storage database management method belong to the same concept. Details not described in detail in the technical solution of the shared storage database management device can be found in the description of the technical solution of the aforementioned shared storage database management method.

[0160] Figure 9 A structural block diagram of a computing device 900 according to one embodiment of this specification is shown. The components of the computing device 900 include, but are not limited to, a memory 910 and a processor 920. The processor 920 is connected to the memory 910 via a bus 930, and a database 950 is used to store data.

[0161] The computing device 900 also includes an access device 940, which enables the computing device 900 to communicate via one or more networks 960. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 940 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0162] In one embodiment of this specification, the above-described components of the computing device 900 and Figure 9 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 9 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0163] The computing device 900 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 900 can also be a mobile or stationary server.

[0164] The processor 920 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the shared storage database management method described above.

[0165] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the shared storage database management method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the shared storage database management method described above.

[0166] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the shared storage database management method described above.

[0167] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the shared storage database management method described above. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the shared storage database management method described above.

[0168] An embodiment of this specification also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the shared storage database management method described above.

[0169] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the shared storage database management method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the shared storage database management method described above.

[0170] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0171] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0172] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

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

[0174] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A shared storage database management method, comprising: The lease locks in the shared storage database are traversed using the functional nodes corresponding to the shared storage database; If a target lease lock in a holdable state is found during traversal, the target lease lock is acquired using the functional node. Select a target node in the node cluster associated with the shared storage database, and migrate the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node; Once the task migration is complete, the target lease lock is assigned to the target node, and the target node is used to execute the data operation task to be executed based on the target lease lock.

2. The shared storage database management method according to claim 1, further comprising: In the case that the functional node is a locally read-only node, determine the local maintenance node corresponding to the locally read-only node; The local lease lock metadata of the local maintenance node is read using the local read-only node. If the local lease lock metadata meets the local data change conditions, the local information synchronization link of the local maintenance node is updated.

3. The shared storage database management method according to claim 1, further comprising: In the case that the functional node is a globally read-only node, at least one globally maintenance node corresponding to the globally read-only node is determined; The global lease lock metadata of at least one global read-only node is traversed and read according to the node traversal order until the target global lease lock metadata that meets the global data change conditions is obtained, and the target global information synchronization link of the target global maintenance node corresponding to the target global lease lock metadata is updated.

4. The shared storage database management method according to claim 1, wherein the step of traversing the lease locks in the shared storage database using the functional nodes corresponding to the shared storage database includes: Create a background thread using the functional node corresponding to the shared storage database; The background thread is used to traverse the lease locks in the shared storage database based on the lease lock traversal order.

5. The shared storage database management method according to claim 1, wherein determining the target lease lock in the holdable state includes: Identify n lease locks in the shared storage database; The i-th lease lock is determined in the lease locks, where i starts from 1 and is a positive integer; If the i-th lease lock is in an unserviceable state, determine the duration of the unserviceability of the i-th lease lock; Determine whether the unserviceable duration of the i-th lease lock is greater than the duration threshold; If not, increment i by 1 and perform the step of determining the i-th lease lock in the lease lock; If so, determine that the i-th lease lock is in a holdable state, and set the i-th lease lock as the target lease lock.

6. The shared storage database management method according to claim 1, wherein when the functional node is a coordinating node, the step of selecting a target node in the node cluster associated with the shared storage database includes: In the node cluster associated with the shared storage database, select the first master node associated with the abnormal node, and use the first master node as the target node.

7. The shared storage database management method according to claim 1, wherein when the functional node is a backup node, the step of selecting a target node in the node cluster associated with the shared storage database includes: The functional node is used as the target node; After migrating the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node, the process further includes: Once the task migration is complete, the target node is used to execute the pending data operation task based on the target lease lock.

8. The shared storage database management method according to claim 7, further comprising, after the task migration is completed and the target node executes the data operation task to be executed based on the target lease lock, the method further comprising: For the shared storage database, a backup functional node is constructed, and the backup functional node is used as the functional node. The step of traversing the lease locks in the shared storage database using the functional node corresponding to the shared storage database is then executed.

9. The shared storage database management method according to claim 1, further comprising: When the functional node is the primary local read-only node corresponding to the second primary node of the shared storage database, the polling time is determined, and the primary local read-only node is used to poll the primary lease lock corresponding to the second primary node based on the polling time; If the primary lease lock is determined to be in an overdue state based on the polling results, the primary local read-only node is used to occupy the primary lease lock, and the primary operation task corresponding to the second primary node is synchronized to the primary local read-only node based on the primary synchronization link between the second primary node and the primary local read-only node.

10. A shared storage database management system, comprising a functional node, a target node, and a shared storage node, wherein the shared storage node includes at least one lease lock; The functional node is used to traverse the at least one lease lock contained in the shared storage node, and when a target lease lock in a holdable state is encountered, the target lease lock is occupied, the pending data operation tasks of the abnormal node corresponding to the target lease lock are migrated to the target node, and when the task migration is completed, the target lease lock is allocated to the target node. The target node is used to execute the data operation task to be executed based on the target lease lock.

11. A shared storage database management device, comprising: The traversal module is configured to traverse the lease locks in the shared storage database using the functional nodes corresponding to the shared storage database. The occupancy module is configured to occupy the target lease lock using the functional node when a target lease lock in a holdable state is encountered during traversal. The migration module is configured to select a target node in the node cluster associated with the shared storage database and migrate the pending data operation tasks of the abnormal node corresponding to the target lease lock to the target node; The execution module is configured to, upon completion of task migration, allocate the target lease lock to the target node and utilize the target node to execute the data operation task to be executed based on the target lease lock.

12. A computing device, comprising: Memory and processor; The memory is used to store computer programs or instructions, and the processor is used to execute the computer programs or instructions, which, when executed by the processor, implement the steps of the shared storage database management method according to any one of claims 1-9.

13. A computer-readable storage medium storing a computer program or instructions that, when executed by a processor, implement the steps of the shared storage database management method according to any one of claims 1-9.

14. A computer program product comprising a computer program or instructions which, when executed by a processor, implement the steps of the shared storage database management method of any one of claims 1-9.

Images