Database cluster management method and related product
By migrating cache locks based on affinity relationship in the database cluster, the network I/O overhead caused by frequent cross-node requests is solved, and the database operation efficiency and user experience are improved.
Patent Information
- Application Number
- CN202510428953.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-07
- Publication Date
- 2025-08-01
AI Technical Summary
In a decentralized database cluster with a shared cache architecture, frequent cross-node cache lock requests lead to excessive network I/O overhead, affecting the user experience.
By obtaining the affinity relationship between the data object and the node, the target lock node is determined, and the cache lock that needs to be modified from the main data object is migrated from the current lock node to the target lock node, reducing network communication across nodes.
Reduces network I/O overhead, improves database operation efficiency and user experience.
Smart Images

Figure CN120407577A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of databases, and in particular to a method for managing a database cluster, a computer-readable storage medium, a computer program product, and a computer device. Background Art
[0002] Currently, in a decentralized database cluster with a shared cache architecture (such as a Real Application Cluster, abbreviated as RAC), a Cache Fusion Lock (abbreviated as CFLock) is usually set to ensure cache consistency. As a lock resource, the cache lock is usually a globally unique resource in the database cluster. That is, when different nodes request the same data object, corresponding blocking relationships should be formed according to the exclusive mode of the lock to be acquired, so as to ensure cache consistency. A Distributed Lock Manager (abbreviated as DLM) is usually set in the database cluster to manage the cache lock. Specifically, the management rights of the cache locks of all data objects are allocated to multiple lock control nodes, and each lock control node is responsible for managing the cache locks of one or more data objects. When a node requests the cache lock of a certain data object, the requesting node needs to first confirm which node is the lock control node of the cache lock to be requested, and then request the lock resource from the lock control node through network communication. After receiving the request message, the lock control node will determine whether the cache lock can be granted to the requesting node, thus ensuring the global uniqueness of the cache lock and the rationality of locking.
[0003] In related technologies, a control lock index is usually generated based on the consistent hashing algorithm, and the management rights of the cache locks of each data object are allocated to each lock control node, so as to quickly retrieve the lock control node of the cache lock of the data object during use. However, when the requesting node frequently requests the cache lock of a certain data object, and the lock control node of the cache lock is not the requesting node, or is far away from the requesting node, frequent network communication is required, thus bringing a large network I / O overhead. In severe cases, it will cause a significant network I / O performance bottleneck and affect the user experience. Summary of the Invention
[0004] An object of the present invention is to provide a method for managing a database cluster, a computer-readable storage medium, a computer program product, and a computer device, so as to reduce the network I / O overhead generated when requesting the cache lock of a data object, improve the database operation efficiency, and further improve the user experience.
[0005] Specifically, according to one aspect of the present invention, the present invention provides a method for managing a database cluster, including:
[0006] Obtain the affinity relationship between data objects and nodes in the database cluster, where at least one of the nodes is the current lock-holding node that manages the cache locks of at least one of the data objects;
[0007] Determine the target lock-holding node corresponding to each data object according to the affinity relationship;
[0008] Determine the data object to be master-changed among all the data objects, where the target lock-holding node corresponding to the data object to be master-changed and the current lock-holding node are not the same node;
[0009] Migrate the cache lock of the data object to be master-changed from the current lock-holding node to the corresponding target lock-holding node.
[0010] Optionally, the step of migrating the cache lock of the data object to be master-changed from the current lock-holding node to the corresponding target lock-holding node includes:
[0011] The current lock-holding node adds a first reallocation request to the first waiting queue of the cache lock of the data object to be master-changed, and the first reallocation request is used to request reallocation of the lock-holding node to block the first waiting queue, and the first waiting queue is located at the current lock-holding node;
[0012] Send the first metadata of the cache lock of the data object to be master-changed to the corresponding target lock-holding node, so that after receiving the first metadata, the target lock-holding node adds a second reallocation request to the second waiting queue of the cache lock of the data object to be master-changed. The first metadata does not include the data of the first waiting queue, and the second reallocation request is used to request reallocation of the lock-holding node to block the second waiting queue, and the second waiting queue is located at the target lock-holding node;
[0013] In response to the coordination node of the database cluster updating the lock-holding index, the current lock-holding node sends the second metadata of the cache lock of the data object to be master-changed to the target lock-holding node, so that the target lock-holding node splices the received first waiting queue onto the second waiting queue. The coordination node is the node where the coordinator is located, and the lock-holding index describes the mapping relationship between the data object and the lock-holding node. The second metadata includes the data of the first waiting queue.
[0014] Optionally, the step of sending the first metadata of the cache lock of the data object to be master-changed to the target lock-holding node includes:
[0015] In response to the first reallocation request being at the head of the first waiting queue, put the first metadata into the sending window of the current lock-holding node corresponding to the target lock-holding node;
[0016] In response to the first metadata of the cache locks of all the main data objects to be changed managed by the current lock control node being within the sending window, send each of the sending windows to the corresponding target lock control node.
[0017] Optionally, before the step of sending the first metadata of the cache lock of the main data object to be changed to the target lock control node, the management method further includes:
[0018] Mark the cache lock of the main data object to be changed in the migration list to be migrated of the current lock control node;
[0019] After the step of sending the first metadata of the cache lock of the main data object to be changed to the target lock control node, the management method further includes:
[0020] Delete the cache lock of the main data object to be changed from the migration list to be migrated of the current lock control node.
[0021] Optionally, before the step of sending the first metadata of the cache lock of the main data object to be changed to the target lock control node, the management method further includes:
[0022] Mark the cache lock of the main data object to be changed in the deletion list to be deleted of the current lock control node;
[0023] After the step of the current lock control node sending the second metadata of the cache lock of the main data object to be changed to the target lock control node, the management method further includes:
[0024] Delete the cache lock of the main data object to be changed from the deletion list to be deleted of the current lock control node.
[0025] Optionally, the step of the coordination node updating the lock control index includes:
[0026] Determine whether each current lock control node has sent the first metadata of the cache locks of all the main data objects to be changed to the corresponding target lock control node;
[0027] If so, the coordination node updates the current lock control index according to the affinity relationship to obtain a new lock control index;
[0028] The coordination node sends a broadcast of an update message version, so that each node invalidates the current message version of each process in sequence by process, and then obtains the new message version corresponding to the new lock control index in sequence by process;
[0029] Upon confirmation that the total number of times of obtaining the new message version is equal to the total number of times of invalidating the current message version, it is confirmed that the update of the control lock index is completed.
[0030] Optionally, before the step of migrating the cache lock of the main data object to be modified from the current control lock node to the corresponding target control lock node, the management method further includes:
[0031] Blocking all database transactions of the main data objects to be modified that will generate new cache locks; and
[0032] After the step of migrating the cache lock of the main data object to be modified from the current control lock node to the corresponding target control lock node, the management method further includes:
[0033] Releasing the block on all database transactions of the main data objects to be modified that will generate new cache locks.
[0034] According to another aspect of the present invention, there is also provided a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the management method of any one of the above database clusters are implemented.
[0035] According to still another aspect of the present invention, there is also provided a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the management method of any one of the above database clusters are implemented.
[0036] According to yet another aspect of the present invention, there is also provided a computer device, including a memory, a processor, and a computer program stored on the memory, and the processor executes the computer program to implement the steps of the management method of any one of the above database clusters.
[0037] The management method of the database cluster of the present invention first determines the main data object to be modified by obtaining the affinity relationship between the data object and the node, and then realizes the transfer of the control lock node of the main data object to be modified by migrating the cache lock of the main data object to be modified from the current control lock node to the corresponding target control lock node. After the transfer is completed, the target control lock node does not need to generate cross-node network communication when frequently requesting the cache lock of the main data object to be modified, thereby reducing the network I / O overhead, improving the database operation efficiency, and further improving the user experience.
[0038] Based on the following detailed description of the specific embodiments of the present invention in conjunction with the accompanying drawings, those skilled in the art will be more clear about the above and other purposes, advantages and features of the present invention. Description of the Drawings
[0039] Some specific embodiments of the present invention will be described in detail hereinafter with reference to the accompanying drawings in an exemplary but not restrictive manner. The same reference numerals in the drawings denote the same or similar components or parts. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings:
[0040] Figure 1 is a schematic flowchart of a management method according to an embodiment of the present invention;
[0041] Figure 2 is a schematic flowchart of a management method according to an embodiment of the present invention for migrating the cache lock of the main data object to be modified from the current lock control node to the corresponding target lock control node;
[0042] Figure 3 is a schematic flowchart of a management method according to an embodiment of the present invention for sending the first metadata to the target lock control node;
[0043] Figure 4 is a schematic flowchart of a management method according to an embodiment of the present invention for updating the lock control index;
[0044] Figure 5 is a schematic flowchart of a management method according to another embodiment of the present invention;
[0045] Figure 6 is a schematic flowchart of a management method according to an embodiment of the present invention for generating a list of objects to be migrated and a list of objects to be deleted;
[0046] Figure 7 is a schematic flowchart of a management method according to an embodiment of the present invention for sending the first metadata;
[0047] Figure 8 is a schematic flowchart of a management method according to an embodiment of the present invention for receiving the first metadata;
[0048] Figure 9 is a schematic flowchart of a management method according to another embodiment of the present invention for sending the second metadata;
[0049] Figure 10 is a schematic flowchart of a management method according to an embodiment of the present invention for receiving the second metadata;
[0050] Figure 11 is a schematic diagram of a computer program product according to an embodiment of the present invention;
[0051] Figure 12 is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and
[0052] Figure 13Schematic diagram of a computer device according to an embodiment of the present invention. Detailed implementation
[0053] The purpose of the management method of the database cluster in this embodiment is to reduce the network I / O overhead generated when requesting the cache lock of a data object, improve the database operation efficiency, and thereby improve the user experience.
[0054] Figure 1 Schematic flowchart of a management method according to an embodiment of the present invention. Generally, the method may include:
[0055] S100, obtain the affinity relationship between data objects and nodes in the database cluster, where at least one node is the current lock-holding node that manages the cache lock of at least one data object;
[0056] S300, determine the target lock-holding node corresponding to each data object according to the affinity relationship;
[0057] S500, determine the data object to be master-changed among all data objects, and the target lock-holding node corresponding to the data object to be master-changed is not the same node as the current lock-holding node;
[0058] S700, migrate the cache lock of the data object to be master-changed from the current lock-holding node to the corresponding target lock-holding node.
[0059] The prior art usually generates a lock-holding index based on the consistent hashing algorithm and distributes the management rights of the cache locks of each data object to each lock-holding node. Although it ensures the consistency of each node's perception of the lock-holding node, it will cause a large network I / O overhead when a node requests the cache lock (CacheFusion Lock, abbreviated as CFLock) of a data object. To reduce this network I / O overhead, this embodiment proposes a lock-holding index based on the affinity relationship. Specifically, the coordination node of the cluster (i.e., the node where the coordinator is located) can obtain the statistical data of the access times of each node to each data object within a duration, and calculate the affinity relationship between each database object and the node according to the statistical data. The affinity relationship describes the mapping relationship between each node in the cluster and the data object it accesses most frequently. The coordination node can obtain the statistical data of the previous run when the database service starts, or can obtain the statistical data periodically during the service operation, which is not limited here. The data object can be a data table, etc. The data table can be stored as multiple data blocks, and the node can request the cache lock of each data block.
[0060] Exemplarily, the affinity relationship can be represented as an affinity map<k,v> function, where k represents the code value of the data object (also known as the key value), and v represents the code value of the node that accesses the data object with the key value the most times. After constructing the affinity map<k,v> function, the coordination node can broadcast it to all nodes in the cluster.
[0061] Through the affinity relationship, the node that accesses each data object the most times can be determined, which is called the target lock control node. Then, the data object to be master-changed can be determined. Exactly because the target lock control node corresponding to the data object to be master-changed and the current lock control node are not the same node, when the target lock control node frequently requests the cache lock of the data object to be master-changed, the target lock control node needs to frequently perform cross-node network communication with the current lock control node, thus generating a large network I / O overhead.
[0062] In this embodiment, after determining the data object to be master-changed and its corresponding target lock control node, the cache lock of the data object to be master-changed can be migrated from the current lock control node to the corresponding target lock control node, and the lock control node of the cache lock of the data object to be master-changed is updated to the target lock control node. In this way, when the target lock control node frequently requests the cache lock of the data object to be master-changed, it does not need to generate cross-node network communication, thus reducing the network I / O overhead, improving the database operation efficiency, and further improving the user experience.
[0063] In some embodiments of the management method of the present invention, as Figure 2 shown, the step of migrating the cache lock of the data object to be master-changed from the current lock control node to the corresponding target lock control node includes:
[0064] S711, the current lock control node adds a first reallocation request to the first waiting queue of the cache lock of the data object to be master-changed. The first reallocation request is used to request the reallocation of the lock control node to block the first waiting queue, and the first waiting queue is located at the current lock control node;
[0065] S714, send the first metadata of the cache lock of the data object to be master-changed to the corresponding target lock control node. The first metadata does not include the data of the first waiting queue;
[0066] S716, after receiving the first metadata, the target lock control node adds a second reallocation request to the second waiting queue of the cache lock of the data object to be master-changed. The second reallocation request is used to request the reallocation of the lock control node to block the second waiting queue, and the second waiting queue is located at the target lock control node;
[0067] S717. In response to the coordinator node of the database cluster updating the lock control index, the current lock control node sends the second metadata of the cache lock of the data object to be master-changed to the target lock control node. The coordinator node is the node where the coordinator is located. The lock control index describes the mapping relationship between the data object and the lock control node. The second metadata includes the data of the first waiting queue.
[0068] S719. The target lock control node splices the received first waiting queue onto the second waiting queue.
[0069] When there are many nodes and / or data objects in the cluster, migrating the cache lock of the data object to be master-changed from the current lock control node to the corresponding target lock control node may take a long time and may cause the cluster service to be interrupted. To prevent the cluster service from being interrupted, this embodiment proposes a solution to migrate the cache lock of the data object to be master-changed from the current lock control node to the corresponding target lock control node in two stages.
[0070] Specifically, in the first stage, the coordinator node can broadcast to the cluster, requiring each current lock control node in the cluster to load all the cache locks of the data objects to be master-changed managed by this node into the local lock table. At the same time, for each cache lock loaded, a first reassignment request is added to the first waiting queue of the cache lock, thereby blocking all requests after the first reassignment request. Exemplarily, the first reassignment request can be a Dynamic Resource Management (DRM) request, and this request can cause the dynamic resource management module to perform master change on the lock control node of the data object. The waiting queue follows the first-in, first-out principle. Requests after the first reassignment request will be queued after the first reassignment request, and before the first reassignment request is executed, requests after the first reassignment request will not be executed. By setting the first reassignment request to block all subsequent requests, it can prevent the current lock control node from processing the data object while sending the cache lock of the data object, thus avoiding confusion.
[0071] It should be understood that the coordinator node can broadcast each data object in the affinity map<k,v> function one by one, and each current lock control node responds to the broadcast of the data objects belonging to this node. In particular, if the target lock control node of the data object belonging to this node is the same as the current lock control node, this current lock control node does not respond to this broadcast.
[0072] After the coordination node broadcasts all data objects in the affinity map <k, v> function, that is, after each current lock control node has loaded the cache locks of all data objects managed by this node into the local lock table, each node can make the first-level allocation requests for each cache lock. Specifically, each current lock control node sends the first metadata of the cache lock of the data object to be changed to the corresponding target lock control node. In this embodiment, the first metadata only includes the lock structure of the cache lock and does not include the first waiting queue. The reason is that: at this time, the coordination node has not updated the lock control index, and all requests for the cache lock of the data object will still be sent to the current lock control node, and new requests can be added to the first waiting queue at the current lock control node. In this way, it can prevent the requests for the cache lock from being misprocessed and prevent the impact on the cluster service.
[0073] After receiving the first metadata, the target lock control node adds a second-level allocation request to the second waiting queue of the cache lock of the data object to be changed, and the second-level allocation request is used to block the second waiting queue. After the coordination node updates the lock control index, new requests for the cache lock will be sent to the target lock control node and added to the second waiting queue. Since the head of the second waiting queue is the second-level allocation request, the target lock control node will not immediately execute the new request for the cache lock, but wait for the data in the first waiting queue. Maintain the first-in, first-out principle of the waiting queue and give priority to processing requests that come first in time.
[0074] It should be understood that each current lock control node in the cluster can make the first-level allocation requests for each cache lock in parallel, or send the first metadata of the cache lock of the data object to be changed to the corresponding target lock control node in parallel. However, when the data volume is large, parallel execution will cause excessive pressure on the network communication of the cluster and affect the cluster service. In this regard, each current lock control node in the cluster can execute the first-level allocation requests for each cache lock serially. For example, start from the coordination node, and after the coordination node finishes execution, notify the next current lock control node to execute until all current lock control nodes in the cluster have finished execution.
[0075] In the second stage, after the coordination node updates the lock control index to a new lock control index based on the affinity relationship, the current lock control node sends the second metadata of the cache lock of the data object to be changed to the target lock control node, and the target lock control node splices the received first waiting queue onto the second waiting queue. The second metadata includes the first waiting queue. Before the lock control index is updated, all requests for this cache lock are sent to the first waiting queue. The first waiting queue will save all requests that have not been executed, and the request times of all requests in the first waiting queue are earlier than those in the second waiting queue. By splicing the first waiting queue onto the second waiting queue, it can prevent the situation of request loss.
[0076] After splicing the first waiting queue to the second waiting queue, the target control lock node can pop the second reassignment request from the waiting queue and then sequentially execute each request transaction in the waiting queue.
[0077] In some embodiments of the management method of the present invention, as Figure 3 shown, sending the first metadata of the cache lock of the main data object to be changed to the target control lock node includes:
[0078] S731, in response to the first reassignment request being at the head of the first waiting queue, putting the first metadata into the sending window of the current control lock node corresponding to the corresponding target control lock node;
[0079] S733, in response to the first metadata of the cache locks of all the main data objects to be changed managed by the current control lock node being in the sending window, sending each sending window to the corresponding target control lock node.
[0080] In this embodiment, the step of migrating the cache lock will not interrupt the service of the cluster. Specifically, each request before the first reassignment request for the cache lock will still be sequentially executed under the management of the current control lock node until all requests before the first reassignment request are executed. At this time, the first reassignment request is at the head of the first waiting queue.
[0081] The current control lock node can set multiple sending windows, and each sending window corresponds to another node. Exemplarily, if the cluster has a total of n nodes, then each node sets n - 1 sending windows. The current control lock node can determine the target control lock node of the cache lock of each data object according to the affinity map<k, v> function, and thus place its first metadata in the corresponding sending window. When the first metadata of the cache locks of all the main data objects to be changed managed by the current control lock node are in the sending window, each sending window is sent to the corresponding target control lock node.
[0082] It should be understood that each sending window can be set with a sending buffer area, and the sending buffer area has a certain maximum capacity threshold. When the data in the sending buffer area of a certain sending window reaches the maximum capacity threshold, the current control lock node can first send out this sending window to empty the sending buffer area to continue to accommodate the first metadata of other cache locks.
[0083] In some embodiments of the management method of the present invention, as Figure 2 shown, before the step of sending the first metadata of the cache lock of the main data object to be changed to the target control lock node, the management method further includes:
[0084] S712, marking the cache lock of the main data object to be changed to the pending migration list of the current control lock node;
[0085] After the step of sending the first metadata of the cache lock of the main data object to be modified to the target lock control node, the management method further includes:
[0086] S715, deleting the cache lock of the main data object to be modified from the pending migration list of the current lock control node.
[0087] In this embodiment, the pending migration list can be located on the current lock control node and is used to record the cache locks of all main data objects to be modified in the current lock control node. Specifically, when the coordination node broadcasts each data object in the affinity map<k,v> function one by one, the current lock control node will respond to the broadcast of the data objects managed by this node and mark the cache lock of the main data object to be modified in the pending migration list of the current lock control node. When the coordination node has broadcast all the data objects in the affinity map<k,v> function, the pending migration list of the current lock control node will record the cache locks of all main data objects to be modified in the current lock control node.
[0088] In this embodiment, after the current lock control node sends the first metadata of the cache lock of the main data object to be modified to the target lock control node, or after putting the first metadata of the cache lock of the main data object to be modified into the sending window corresponding to the corresponding target lock control node, the cache lock of the main data object to be modified can be deleted from the pending migration list. Specifically, the pending migration list of the current lock control node can be traversed. For each first metadata of a cache lock traversed, go back to the lock table to view the first waiting queue of this cache lock. If the head of the first waiting queue is a first reallocation request, put the first metadata into the sending window corresponding to the corresponding target lock control node and delete it from the pending migration list. Keep traversing and searching until the pending migration list of the current lock control node is empty.
[0089] By setting the pending migration list of the current lock control node, the cache locks of the main data objects to be modified in the current lock control node can be accurately recorded, preventing omission or loss.
[0090] In some embodiments of the management method of the present invention, such as Figure 2 shown, before the step of sending the first metadata of the cache lock of the main data object to be modified to the target lock control node, the management method further includes:
[0091] S713, marking the cache lock of the main data object to be modified in the pending deletion list of the current lock control node;
[0092] After the step of the current lock control node sending the second metadata of the cache lock of the main data object to be modified to the target lock control node, the management method further includes:
[0093] S718. Delete the cache lock of the master data object to be modified from the deletion list of the current lock control node.
[0094] In this embodiment, the deletion list may be on the current lock control node and is used to record the cache locks of all master data objects to be modified in the current lock control node. Specifically, when the coordination node broadcasts each data object in the affinity map <k, v> function one by one, the current lock control node will respond to the broadcast of the data objects managed by this node and mark the cache lock of the master data object to be modified in the deletion list of the current lock control node. After the coordination node broadcasts all the data objects in the affinity map <k, v> function, the deletion list of the current lock control node will record the cache locks of all master data objects to be modified in the current lock control node.
[0095] In this embodiment, after the current lock control node sends the second metadata of the cache lock of the master data object to be modified to the target lock control node, the cache lock of the master data object to be modified can be deleted from the deletion list. Specifically, the deletion list of the current lock control node can be traversed. For each cache lock traversed, the second metadata of the cache lock is placed in the sending window corresponding to the target lock control node and deleted from the deletion list. Keep traversing and searching until the deletion list of the current lock control node is empty. When the deletion list of the current lock control node is empty, it indicates that all the cache locks of the master data objects to be modified in the current lock control node have been deleted from the current lock control node and migrated to the corresponding target lock control node.
[0096] By setting the deletion list of the current lock control node, the cache locks of the master data objects to be deleted in the current lock control node can be accurately recorded, preventing omission or missing.
[0097] In some embodiments of the management method of the present invention, as Figure 4 shown, the steps for the coordination node to update the lock control index include:
[0098] S741. Determine whether each current lock control node has sent the first metadata of the cache locks of all master data objects to be modified to the corresponding target lock control node;
[0099] S743. If so, the coordination node updates the current lock control index according to the affinity relationship to obtain a new lock control index;
[0100] S745. The coordination node issues an update message version broadcast so that each node invalidates the current message version of each process in sequence according to the process, and then obtains the new message version corresponding to the new lock control index in sequence according to the process;
[0101] S747. In response to the total number of times of obtaining the new message version being equal to the total number of times of invalidating the current message version, confirm that the update of the lock control index is completed.
[0102] The new control lock index can be a hash index graph (HashMap) based on the affinity map <k, v> function, which can replace the current control lock index. The current control lock index can be a control lock index based on the consistent hashing algorithm. In this way, the network communication across nodes can be reduced, thereby reducing the network I / O overhead, improving the database operation efficiency, and further improving the user experience. The current control lock index can also be the hash index graph of the previous monitoring period (the affinity relationship may be different in different monitoring periods). In this way, the network communication across nodes in the current monitoring period can be effectively reduced, thereby reducing the network I / O overhead, improving the database operation efficiency, and further improving the user experience.
[0103] At the same time, there is usually only a unique message version number in the cluster, and this message version number is carried in any communication message. When the message version number carried in a certain message is inconsistent with the message version number of the node receiving the message, the node receiving the message will reject the reception and require the node sending the message to resend. The message version number can ensure that the understanding of messages by any two processes in the cluster is highly consistent.
[0104] When the pending migration lists of all nodes are empty, it can be confirmed that all current control lock nodes have sent the first metadata of the cache locks of all data objects to be master-changed to the corresponding target control lock nodes. Next, the current control lock index can be updated to the new control lock index. After the control lock index is updated, each request for the cache lock of each data object will be sent to the new control lock node.
[0105] In this embodiment, the message version is also updated when the control lock index is updated to ensure the consistency of the message understanding of each node. Specifically, the node can set a message reference count variable. The coordination node sends a broadcast request for the lock resource management process of each node to invalidate the current message version for all processes of this node. Whenever the current message version of a process is invalidated, this reference count variable will be decremented by 1. When the reference count of the current message version is 0, the lock resource management process will block and update the message version. Exemplarily, the version number of the new message version is the version number of the current message version plus 1. At the same time, the coordination node will also construct a HashMap according to the affinity map <k, v> function. After the control lock index is updated, the lock resource management process will release the lock. At this time, each process can request the new message version, and the reference count variable will be incremented by 1 each time it is requested until the value of the reference count variable reaches the initial value.
[0106] In some embodiments of the management method of the present invention, as Figure 5 shown, the management method includes:
[0107] S600, blocking all database transactions that will generate new cache locks for the master data objects to be modified; and
[0108] S700, the current lock controlling node migrating the cache locks of the master data objects to be modified from the current lock controlling node to the corresponding target lock controlling node;
[0109] S800, lifting the block on all database transactions that will generate new cache locks for the master data objects to be modified.
[0110] Blocking all database transactions that will generate new cache locks for the master data objects to be modified can block relevant database transactions and prevent new cache locks from being generated for the master data objects to be modified during the master data modification process, thus avoiding chaos. After the master data modification is completed, the requests of the blocked database transactions will be sent to the new lock controlling node.
[0111] In some embodiments of the management method of the present invention, as Figure 6 shown, the method by which the current lock controlling node generates the list to be migrated and the list to be deleted includes:
[0112] S911, starting;
[0113] S912, traversing the affinity map <k, v> function to determine whether there is a next master data object to be modified; if so, execute S913; if not, execute S919;
[0114] S913, obtaining the target lock controlling node of the master data object to be modified according to the affinity map <k, v> function;
[0115] S914, traversing the cache locks of the master data object to be modified to determine whether there is a next cache lock; if so, execute S915; if not, return to execute S912;
[0116] S915, loading the cache lock;
[0117] S916, adding the first reallocation request to the first waiting queue of the cache lock;
[0118] S917, marking the cache lock in the list to be migrated;
[0119] S918, marking the cache lock in the list to be deleted; return to execute S914;
[0120] S919, ending.
[0121] In some embodiments of the management method of the present invention, as Figure 7 shown, the method by which the current lock controlling node sends the first metadata includes:
[0122] S921, starting;
[0123] S922. Traverse the list of objects to be migrated and determine whether there is a cache lock for the next master data object to be modified. If so, execute S923; if not, execute S930.
[0124] S923. Hold the cache lock.
[0125] S924. Determine whether the head of the first waiting queue of the cache lock is the first reallocation request. If so, execute S925; if not, return to execute S922.
[0126] S925. Obtain the target control lock node of the cache lock.
[0127] S926. Put the first metadata of the cache lock into the sending window of the corresponding target control lock node.
[0128] S927. Delete the cache lock from the list of objects to be migrated.
[0129] S928. Determine whether the sending buffer of the sending window reaches the maximum capacity threshold. If so, execute S929; if not, return to execute S922.
[0130] S929. Send the sending window to the target control lock node; return to execute S922.
[0131] S930. Send the sending window to the target control lock node.
[0132] S931. End.
[0133] In some embodiments of the management method of the present invention, as Figure 8 shown, the method for the target control lock node to receive the first metadata includes:
[0134] S941. Start.
[0135] S942. Receive the first metadata of the cache lock in the sending window.
[0136] S943. Traverse the received cache lock and determine whether there is a next cache lock. If so, execute S944; if not, execute S946.
[0137] S944. Put the cache lock into the lock table of the target control lock node.
[0138] S945. Add the second reallocation request to the second waiting queue of the cache lock; return to execute S943.
[0139] S946. End.
[0140] In some embodiments of the management method of the present invention, as Figure 9 shown, the method for the current control lock node to send the second metadata includes:
[0141] S951, Start;
[0142] S952, Invalidate the current message versions of each process in sequence according to the process, and determine whether the message reference count variable is 0;
[0143] S953, If so, update the version number of the message version;
[0144] S954, Construct a HashMap according to the affinity map<k, v> function;
[0145] S955, Traverse the list to be deleted, and determine whether there is a cache lock for the next main data object to be modified; if so, execute S956; if not, execute S959;
[0146] S956, Hold the cache lock;
[0147] S957, Put the second metadata of the cache lock into the sending window of the corresponding target control lock node;
[0148] S958, Delete the cache lock from the list to be deleted;
[0149] S959, Determine whether the sending buffer of the sending window reaches the maximum capacity threshold; if so, execute S960; if not, return to execute S955;
[0150] S960, Send the sending window to the target control lock node;
[0151] S961, End.
[0152] In some embodiments of the management method of the present invention, as Figure 10 shown, the method for the target control lock node to receive the second metadata includes:
[0153] S971, Start;
[0154] S972, Receive the second metadata of the cache lock in the sending window;
[0155] S973, Traverse the received second metadata, and determine whether there is a next second metadata; if so, execute S974; if not, execute S976;
[0156] S974, Splice the first waiting queue in the second metadata to the corresponding second waiting queue;
[0157] S975, Dequeue the second reassignment request from the spliced waiting queue; return to execute S973;
[0158] S976, End.
[0159] The flowcharts provided in this embodiment are not intended to indicate that the operations of the method will be performed in any specific order, or that all operations of the method are included in every case. In addition, the method may include additional operations. Within the scope of the technical concept provided by the method of this embodiment, additional changes may be made to the above method.
[0160] It should be understood that in some embodiments, each part may be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system.
[0161] The embodiments of the present invention also provide a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 11 is a schematic diagram of a computer program product 10 according to an embodiment of the present invention, Figure 12 is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention, Figure 13 is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, and when the computer program 11 is executed by a processor 32, it implements the steps of any of the above management methods. The computer-readable storage medium 20 stores the above computer program 11, and when the computer program 11 is executed by a processor 32, it implements the steps of the management method of any of the above embodiments. The computer device 30 may include a memory 31, a processor 32, and a computer program 11 stored on the memory 31 and running on the processor 32.
[0162] The computer program 11 for performing the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or source code or object code written in any combination of one or more programming languages and procedural programming languages. The computer program 11 may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider via the Internet). In some embodiments, in order to perform aspects of the present invention, an electronic circuit, including for example a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit.
[0163] For the description of this embodiment, the computer program product 10 is a related product containing the computer program 11.
[0164] For the description of this embodiment, the computer-readable storage medium 20 is a tangible device capable of retaining and storing the computer program 11, which may be any device that can contain, store, communicate, propagate, or transport the computer program 11 for use by or in connection with an instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of the computer-readable storage medium 20 include the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded device, and any suitable combination of the above.
[0165] The computer device 30 can be, for example, a server, a desktop computer, a laptop computer, a tablet computer, or a smart phone. In some examples, the computer device 30 can be a cloud computing node. The computer device 30 can be described in the general context of computer system executable instructions, such as program modules, executed by a computer system. Generally, program modules can include routines, programs, object programs, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located on local or remote computing system storage media including storage devices.
[0166] The computer device 30 can include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of the instructions during operation. The processor 32 can be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. The memory 31 can include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.
[0167] The computer device 30 can also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows data to be input and output with external devices that can be connected to the computer device. The network adapter / interface can provide communication between the computer device and a network, which is generally shown as a communication network.
[0168] At this point, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications consistent with the principles of the present invention can still be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention should be understood and construed to cover all such other variations or modifications.
Claims
1. A management method for a database cluster, characterized in that Including: Obtaining the affinity relationship between data objects and nodes in the database cluster, where at least one of the nodes is the current lock-holding node that manages the cache locks of at least one of the data objects; Determining the target lock-holding node corresponding to each data object according to the affinity relationship; Determining the data objects to be master-changed among all the data objects, where the target lock-holding node corresponding to the data object to be master-changed and the current lock-holding node are not the same node; Migrating the cache lock of the data object to be master-changed from the current lock-holding node to the corresponding target lock-holding node.
2. The management method according to claim 1, wherein The step of migrating the cache lock of the data object to be master-changed from the current lock-holding node to the corresponding target lock-holding node includes: The current lock-holding node adds a first reassignment request to the first waiting queue of the cache lock of the data object to be master-changed, where the first reassignment request is used to request reassignment of the lock-holding node to block the first waiting queue, and the first waiting queue is located at the current lock-holding node; Sending the first metadata of the cache lock of the data object to be master-changed to the corresponding target lock-holding node, so that after receiving the first metadata, the target lock-holding node adds a second reassignment request to the second waiting queue of the cache lock of the data object to be master-changed. The first metadata does not include the data of the first waiting queue, and the second reassignment request is used to request reassignment of the lock-holding node to block the second waiting queue, and the second waiting queue is located at the target lock-holding node; In response to the coordination node of the database cluster updating the lock-holding index, the current lock-holding node sends the second metadata of the cache lock of the data object to be master-changed to the target lock-holding node, so that the target lock-holding node splices the received first waiting queue onto the second waiting queue. The coordination node is the node where the coordinator is located, and the lock-holding index describes the mapping relationship between the data object and the lock-holding node, and the second metadata includes the data of the first waiting queue.
3. The management method according to claim 2, wherein The step of sending the first metadata of the cache lock of the data object to be master-changed to the target lock-holding node includes: In response to the first reassignment request being at the head of the first waiting queue, putting the first metadata into the sending window of the current lock-holding node corresponding to the target lock-holding node; In response to the first metadata of the cache locks of all the data objects to be master-changed managed by the current lock-holding node being in the sending window, sending each sending window to the corresponding target lock-holding node.
4. The management method according to claim 2, wherein Before the step of sending the first metadata of the cache lock of the data object to be master-changed to the target lock-holding node, the management method further includes: Marking the cache lock of the data object to be master-changed to the list of locks to be migrated of the current lock-holding node; After the step of sending the first metadata of the cache lock of the data object to be master-changed to the target lock-holding node, the management method further includes: Delete the cache lock of the main data object to be modified from the list of locks to be migrated of the current lock control node.
5. The management method according to claim 2, wherein Before the step of sending the first metadata of the cache lock of the main data object to be modified to the target lock control node, the management method further includes: Mark the cache lock of the main data object to be modified in the list of locks to be deleted of the current lock control node; After the step that the current lock control node sends the second metadata of the cache lock of the main data object to be modified to the target lock control node, the management method further includes: Delete the cache lock of the main data object to be modified from the list of locks to be deleted of the current lock control node.
6. The management method according to claim 2, wherein The step in which the coordination node updates the lock control index includes: Determine whether each of the current lock control nodes has sent the first metadata of all the cache locks of the main data objects to be modified to the corresponding target lock control nodes; If so, the coordination node updates the current lock control index according to the affinity relationship to obtain a new lock control index; The coordination node sends a broadcast of an updated message version, so that each node invalidates the current message version of each process in sequence according to the process, and then obtains the new message version corresponding to the new lock control index in sequence according to the process; In response to the total number of times of obtaining the new message version being equal to the total number of times of invalidating the current message version, it is confirmed that the update of the lock control index is completed.
7. The management method according to claim 1, wherein Before the step of migrating the cache lock of the main data object to be modified from the current lock control node to the corresponding target lock control node, the management method further includes: Lock all database transactions of the main data objects to be modified that will generate new cache locks; and After the step of migrating the cache lock of the main data object to be modified from the current lock control node to the corresponding target lock control node, the management method further includes: Release the lock on all database transactions of the main data objects to be modified that will generate new cache locks.
8. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor, the steps of the management method of the database cluster according to any one of claims 1 to 7 are implemented.
9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, the steps of the management method of the database cluster according to any one of claims 1 to 7 are implemented.
10. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored on the memory, and the processor executes the computer program to implement the steps of the management method of the database cluster according to any one of claims 1 to 7.