Database cluster management method and related product

Abstract

The invention provides a database cluster management method and related products. The management method comprises the steps of obtaining a to-be-changed main data object of a database cluster; each current lock control node is controlled to send the data of the first cache lock of each main data object needing to be changed to the corresponding affinity lock control node; and updating the lock control index in response to the coordination node of the database cluster, and controlling each current lock control node to send the data of the second cache lock of each main data object needing to be changed to the corresponding affinity lock control node. According to the method, the cache lock can be migrated and the lock control node can be changed under the condition of not interrupting the cluster service, the cross-node network I / O overhead is reduced, the database operation efficiency is improved, and the user experience is further improved.

Description

Technical Field

[0001] The present invention relates to the technical field of databases, and particularly to a management method for 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 need to request the same data object, corresponding blocking relationships should be formed according to the exclusive mode of the lock to be obtained, 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 lock control index is usually generated based on a 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 serious 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 management method for a database cluster, a computer-readable storage medium, a computer program product, and a computer device, so as to reduce network I / O overhead without interrupting the cluster service, 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 management method for a database cluster, including:

[0006] Obtain the data objects to be master-changed in the database cluster, where the current lock-holding node of the data objects to be master-changed and the affinity lock-holding node having an affinity relationship with it are not the same node, and the lock-holding node is configured to manage the cache locks of at least one data object;

[0007] Control each of the current lock-holding nodes to send the data of the first cache lock of each of the data objects to be master-changed to the corresponding affinity lock-holding node, where the first cache lock is an existing cache lock;

[0008] In response to the coordinator node in the database cluster updating the lock control index, control each of the current lock-holding nodes to send the data of the second cache lock of each of the data objects to be master-changed to the corresponding affinity lock-holding node. The coordinator node is the node where the coordinator is located, and the lock control index describes the mapping relationship between the data objects and the lock-holding nodes in the database cluster. The second cache lock is a newly generated cache lock for the data object to be master-changed before the lock control index update is completed.

[0009] Optionally, the step of the current lock-holding node sending the data of the first cache lock of the data object to be master-changed to the corresponding affinity lock-holding node includes:

[0010] Add a first reallocation request to the first waiting queue of the first cache lock, and mark the first cache lock to the first migration list. 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 of the first cache lock;

[0011] In response to all the first cache locks being added with the first reallocation request, set the database cluster to the reallocation state. Each of the current lock-holding nodes is configured to add a second reallocation request to the waiting queue of each newly generated second cache lock when the database cluster is in the reallocation state. The second reallocation request is used to request reallocation of the lock-holding node to block the waiting queue corresponding to the second cache lock;

[0012] Send the data of each of the first cache locks in the first migration list to the corresponding affinity lock-holding node.

[0013] Optionally, the sending the data of the first cache lock in the first migration list to the corresponding affinity lock-holding node includes:

[0014] In response to the first reallocation request being at the head of the first waiting queue, put the first data of the first cache lock into the sending window of the current lock-holding node corresponding to the corresponding affinity lock-holding node;

[0015] In response to all the first data of the first cache locks managed by the current lock control node being within the sending window, the sending window is sent to the corresponding affinity lock control node, so that the affinity lock control node adds a third reallocation request to the second waiting queue of the first data of the received first cache locks. The first data does not include the data in the first waiting queue. The third reallocation request is used to request reallocation of the lock control node to block the second waiting queue, and the second waiting queue is located at the affinity lock control node;

[0016] In response to the coordination node updating the lock control index, the current lock control node sends the second data of the first cache lock to the corresponding affinity lock control node. The second data includes the data in the first waiting queue, so that the affinity lock control node splices the received first waiting queue onto the second waiting queue.

[0017] Optionally, after the step of the current lock control node sending the second data of the first cache lock to the corresponding affinity lock control node, the management method further includes:

[0018] The current lock control node deletes all the data of the first cache lock; and

[0019] Optionally, after the step of the affinity lock control node splicing the received first waiting queue onto the second waiting queue, the management method further includes:

[0020] The third reallocation request is popped from the spliced waiting queue.

[0021] Optionally, the step of the current lock control node sending the data of the second cache lock of the data object to be master-changed to the corresponding affinity lock control node includes:

[0022] Put the data of each second cache lock into the sending window of the current lock control node corresponding to the corresponding affinity lock control node;

[0023] In response to all the data of the second cache locks being within the sending window, cancel the reallocation state of the database cluster;

[0024] Send the sending window to the corresponding affinity lock control node.

[0025] Optionally, the step of the coordination node updating the lock control index includes:

[0026] The coordination node updates the current lock control index according to the corresponding relationship between all the data objects to be master-changed and the corresponding affinity lock control nodes to obtain a new lock control index;

[0027] The coordination node sends a broadcast of the updated message version, so that each of the nodes 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 control lock index in sequence according to the process;

[0028] 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 control lock index is completed.

[0029] Optionally, the obtaining of the data objects to be master-changed in the database cluster includes:

[0030] Obtain the affinity relationship between the data objects and the nodes in the database cluster;

[0031] According to the affinity relationship, determine the affinity control lock node corresponding to each data object, and determine the data objects in which the current control lock node and the affinity control lock node are inconsistent as the data objects to be master-changed.

[0032] 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 the database cluster described above are implemented.

[0033] 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 the database cluster described above are implemented.

[0034] According to still 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 the database cluster described above.

[0035] The management method of the database cluster of the present invention can migrate the cache lock and change the control lock node without interrupting the cluster service by sending the existing first cache lock and the newly generated second cache lock of the current control lock node to the affinity control lock node in two times. When the affinity control lock node frequently requests the cache lock of the data object to be master-changed, it does not need to generate cross-node network communication, thereby reducing the cross-node network I / O overhead, improving the database operation efficiency, and further improving the user experience.

[0036] According to 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 objects, advantages and features of the present invention. Description of the Drawings

[0037] Some specific embodiments of the present invention will be described in detail hereinafter with reference to the accompanying drawings in an illustrative 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:

[0038] Figure 1 is a schematic flowchart of a management method according to an embodiment of the present invention;

[0039] Figure 2 is a schematic flowchart of determining a master data object to be modified in a management method according to an embodiment of the present invention;

[0040] Figure 3 is a schematic flowchart of sending a first cache lock in a management method according to an embodiment of the present invention;

[0041] Figure 4 is a schematic flowchart of sending the first data and the second data of the first cache lock in a management method according to an embodiment of the present invention;

[0042] Figure 5 is a schematic flowchart of updating a control lock index in a management method according to an embodiment of the present invention;

[0043] Figure 6 is a schematic flowchart of sending a second cache lock in a management method according to an embodiment of the present invention;

[0044] Figure 7 is a schematic flowchart of obtaining an affinity relationship list in a management method according to an embodiment of the present invention;

[0045] Figure 8 is a schematic flowchart of a management method according to an embodiment of the present invention;

[0046] Figure 9 is a schematic flowchart of the first migration stage of a management method according to an embodiment of the present invention;

[0047] Figure 10 is a schematic flowchart of the second migration stage of a management method according to an embodiment of the present invention;

[0048] Figure 11 is a schematic flowchart of the third migration stage of a management method according to an embodiment of the present invention;

[0049] Figure 12 is a schematic diagram of a computer program product according to an embodiment of the present invention;

[0050] Figure 13 is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and

[0051] Figure 14 It is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed implementation manners

[0052] The purpose of the management method of the database cluster in this embodiment is to reduce the network I / O overhead without interrupting the cluster service, improve the database operation efficiency, and further improve the user experience.

[0053] Figure 1 It is a schematic flowchart of a management method according to an embodiment of the present invention. Generally, the method may include:

[0054] S100, obtain the data object to be changed to the master in the database cluster. The current lock control node of the data object to be changed to the master and the affinity lock control node having an affinity relationship with it are not the same node. The lock control node is configured to manage the cache locks of at least one data object;

[0055] S300, control each current lock control node to send the data of the first cache lock of each data object to be changed to the master to the corresponding affinity lock control node. The first cache lock is an existing cache lock;

[0056] S500, in response to the coordination node of the database cluster updating the lock control index, control each current lock control node to send the data of the second cache lock of each data object to be changed to the master to the corresponding affinity lock control node. The coordination node is the node where the coordinator is located. The lock control index describes the mapping relationship between the data objects and the lock control nodes in the database cluster. The second cache lock is a newly generated cache lock for the data object to be changed to the master before the completion of the update of the lock control index.

[0057] The prior art usually generates a control lock index based on the consistent hashing algorithm and distributes the management rights of the cache locks of each data object to each control lock node. Although it ensures the consistency of each node's perception of the control lock 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 control lock index based on the affinity relationship. Specifically, the cluster can elect a coordinator node (i.e., the node where the coordinator is located) through a preset method, and the coordinator node will play an overall tuning and control role during the process of changing the control lock node. The resource management process of the coordinator node can obtain the statistical data of the access times of each node to each data object within a duration, calculate the affinity relationship between each database object and the node according to the statistical data, and the affinity relationship describes the mapping relationship between each node in the cluster and the data object it accesses most frequently. The coordinator node can obtain the statistical data of the previous run when the database service starts, or can obtain this statistical data periodically during the service operation, which is not limited here. The data object can be a data table, etc., and the data table can be stored as multiple data blocks, and the node can request the cache lock of each data block.

[0058] Through the affinity relationship, the node with the most access times to each data object can be determined. After the access frequency reaches the preset condition, this node can be used as the affinity control lock node, and then the data object to be changed can be determined. It is precisely because the affinity control lock node corresponding to the data object to be changed is not the same as the current control lock node that when the affinity control lock node frequently requests the cache lock of the data object to be changed, the affinity control lock node needs to frequently perform cross-node network communication with the current control lock node, thus generating a large network I / O overhead.

[0059] In this embodiment, after determining the data object to be changed and its corresponding affinity control lock node, the existing cache lock of the data object to be changed (i.e., already existing in the cache or already existing in the lock table of the cache lock) can be migrated from the current control lock node to the corresponding affinity control lock node, and the control lock node of the cache lock of the data object to be changed can be updated to the affinity control lock node. In this way, the affinity control lock node does not need to generate cross-node network communication when frequently requesting the cache lock of the data object to be changed, thereby reducing the network I / O overhead, improving the database operation efficiency, and further improving the user experience.

[0060] It takes a certain amount of processing time for the current lock control node to send the data of the first cache lock of each master data object to be modified to the corresponding affinity lock control node, and it also takes a certain amount of processing time for the coordination node to complete the update of the lock control index. During this period, the cluster may generate new request services for the master data objects to be modified, resulting in the generation of new cache locks (referred to as the second cache locks) for the master data objects to be modified. After the coordination node completes the update of the lock control index, it sends the data of the second cache lock to the corresponding affinity lock control node, enabling the affinity lock control node to execute various requests for the second cache lock and avoiding the loss of requests. This solution can migrate the cache locks of the master data objects to be modified and change the lock control nodes without interrupting the cluster service, achieving the purpose of reducing network I / O overhead and improving the database operation efficiency, and achieving the effect of improving the user experience.

[0061] In some embodiments of the management method of the present invention, as Figure 2 shown, obtaining the master data objects to be modified in the database cluster includes:

[0062] S111, obtaining the affinity relationship between data objects and nodes in the database cluster;

[0063] S113, according to the affinity relationship, determining the affinity lock control node corresponding to each data object, and determining the data objects whose current lock control node and affinity lock control node are inconsistent among all data objects as the master data objects to be modified.

[0064] Exemplarily, the resource management process of the coordination node will traverse the affinity statistics between data objects and nodes to obtain the affinity map <k, v> function, where k represents the code value of the data object (also referred to as the key value), and v represents the code value of the node that accesses the data object with the code value of key the most times. The node that accesses the data object with the code value of key the most times and meets the preset conditions can be used as the affinity lock control node of the data object. According to the affinity map <k, v> function, it is convenient to determine the master data objects to be modified whose current lock control node and affinity lock control node are inconsistent from all data objects to construct a list of master data objects to be modified.

[0065] It should be understood that during the process of the resource management process of the coordination node constructing the list of master data objects to be modified, the resource management processes of non-coordination nodes need to enter the blocked state to prevent the generation of new cache locks for the master data objects to be modified until the coordination node completes the construction of the list of master data objects to be modified.

[0066] If the coordination node fails to find the master data objects to be modified, the resource management processes of all nodes in the cluster will enter the next loop monitoring period and wait for the next opportunity to reassign the lock control node.

[0067] In some embodiments of the management method of the present invention, asFigure 3 As shown in Figure 3 , the steps for the current lock control node to send the first cache lock data of the main data object to be modified to the corresponding affinity lock control node include:

[0068] S311, add the first reassignment request to the first waiting queue of the first cache lock, and mark the first cache lock to the first waiting list for migration. The first reassignment request is used to request the reassignment of the lock control node to block the first waiting queue, and the first waiting queue is located at the current lock control node of the first cache lock;

[0069] S313, in response to all the first cache locks being added with the first reassignment request, set the database cluster to the reassignment state. Each current lock control node is configured to add a second reassignment request to the waiting queue of each newly generated second cache lock when the database cluster is in the reassignment state. The second reassignment request is used to request the reassignment of the lock control node to block the waiting queue corresponding to the second cache lock;

[0070] S315, send the data of each first cache lock in the first waiting list for migration to the corresponding affinity lock control node.

[0071] In this embodiment, the coordination node can broadcast to the cluster, requiring each current lock control node in the cluster to traverse the lock table of its cache locks, and the lock table contains all the cache locks it manages. For each first cache lock traversed, add a first reassignment request to the first waiting queue of the first cache lock, and mark the first cache lock to the first waiting list for migration. The first reassignment request is used to block 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 change the master of the lock control node of this data object. The waiting queue follows the first-in, first-out principle. Requests after the first reassignment request will queue 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.

[0072] It should be understood that the coordination 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 object belonging to the node it manages. In particular, when the affinity lock control node of the data object belonging to the node it manages is the same as the current lock control node, the current lock control node does not respond to this broadcast.

[0073] In this embodiment, the reallocation status of the cluster can be described by setting global variables. For example, the CFProcessResourceTransfer parameter can be set. When the boolean value of this parameter is true, it indicates that the cluster is in the reallocation status. When the boolean value of this parameter is false, it indicates that the cluster is not in the reallocation status. Specifically, for the newly generated second cache lock, when the current lock-holding node determines that the cluster is in the reallocation status, when putting this second cache lock into the lock table (for example, performing Cachefusion Lock insert), it will first add a second reallocation request to the waiting queue of this second cache lock, and then place the actual current request after the second reallocation request. That is to say, the subsequent requests of the second cache lock are blocked by the second reallocation request, preventing the current lock-holding node from processing data objects while sending cache locks of data objects, thus avoiding confusion.

[0074] When the current lock-holding node traverses the lock table to add a first reallocation request to the first cache lock in the lock table, the lock table can be locked until the cluster enters the reallocation status, and then the lock table is unlocked to prevent the content of the lock table from being updated during the traversal.

[0075] In some embodiments of the management method of the present invention, as Figure 4 shown, sending the data of the first cache lock in the first waiting migration list to the corresponding affinity lock-holding node includes:

[0076] S331, in response to the first reallocation request being at the head of the first waiting queue, putting the first data of the first cache lock into the sending window of the current lock-holding node corresponding to the corresponding affinity lock-holding node;

[0077] S332, in response to all the first data of the first cache locks managed by the current lock-holding node being in the sending window, sending the sending window to the corresponding affinity lock-holding node, where the first data does not include the data in the first waiting queue; [[ID=I5]]

[0078] S333, the affinity lock-holding node adds a third reallocation request to the second waiting queue of the first data of the received first cache lock. The third reallocation request is used to request the reallocation of the lock-holding node to block the second waiting queue, and the second waiting queue is located at the affinity lock-holding node;

[0079] S334, in response to the coordination node updating the lock-holding index, the current lock-holding node sends the second data of the first cache lock to the corresponding affinity lock-holding node, and the second data includes the data in the first waiting queue;

[0080] S336, the affinity lock-holding node splices the received first waiting queue onto the second waiting queue.

[0081] In this embodiment, the step of migrating the first cache lock does not interrupt the services of the cluster. Specifically, the requests for the first cache lock before the first reassignment request will still be sequentially executed under the management of the current lock control node until all the requests before the first reassignment request are executed. At this time, the first reassignment request is at the head of the first waiting queue.

[0082] The current lock control 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 lock control node can determine the affinity lock control nodes of the first cache locks of each data object according to the affinitymap<k,v> function, and thus place its first data in the corresponding sending window. When all the first data of the first cache locks of the data objects to be master-changed managed by the current lock control node are in the sending windows, each sending window is sent to the corresponding affinity lock control node.

[0083] It should be understood that each sending window can be set with a sending buffer, and the sending buffer has a certain maximum capacity threshold. When the data in the sending buffer of a certain sending window reaches the maximum capacity threshold, the current lock control node can first send out this sending window to empty the sending buffer to continue to accommodate the first data of other cache locks.

[0084] The current lock control node can traverse the first list to be migrated and put the first data of each first cache lock into the sending window one by one until the first list to be migrated is empty to prevent omission.

[0085] In this embodiment, the first data only includes the lock structure of the first 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 data object first 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 first cache lock from being wrongly disposed and prevent the impact on the cluster services.

[0086] After receiving the first data, the affinity lock control node adds the third reassignment request to the second waiting queue of the first cache lock of the data object to be master-changed, and the third reassignment request is used to block the second waiting queue. After the coordination node updates the lock control index, the new requests for the first cache lock will be sent to the affinity lock control node and added to the second waiting queue. Since the third reassignment request is at the head of the second waiting queue, the affinity lock control node will not immediately execute the new requests for the first cache lock but wait for the data in the first waiting queue. The first-in, first-out principle of the waiting queue is maintained, and the requests earlier in time are preferentially processed.

[0087] It should be understood that each current lock control node in the cluster can perform the first reallocation requests of each first cache lock in parallel, or send the first data of the first cache lock of the data object to be master-changed to the corresponding affinity 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 serially execute the first reallocation requests of each first cache lock. For example, starting from the coordination node, after the coordination node finishes execution, it notifies the next current lock control node to execute until all current lock control nodes in the cluster have finished execution.

[0088] 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 data of the first cache lock of the data object to be master-changed to the affinity lock control node, and the affinity lock control node splices the received first waiting queue to the second waiting queue. The second data includes the first waiting queue. Before the lock control index update is completed, all requests for this first 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 to the second waiting queue, the situation of request loss can be prevented.

[0089] After splicing the first waiting queue to the second waiting queue, the affinity lock control node can pop the third reallocation request from the waiting queue and then sequentially execute each request transaction in the waiting queue.

[0090] By splitting the data of the first cache lock into the first data and the second data and sending them to the affinity lock control node in two times, on the one hand, the requests of the cluster for the first cache lock during the master change can be effectively handled without interrupting the cluster service, and on the other hand, the communication pressure of the cluster can be dispersed.

[0091] In some embodiments of the management method of the present invention, as Figure 4 shown, after the step in which the current lock control node sends the second data of the first cache lock to the corresponding affinity lock control node, the management method further includes:

[0092] S335, the current lock control node deletes all data of the first cache lock; and

[0093] After the step in which the affinity lock control node splices the received first waiting queue to the second waiting queue, the management method further includes:

[0094] S337, pop the third reallocation request from the spliced waiting queue.

[0095] In this embodiment, the current lock control node can delete the data of the first cache lock from the lock table of the current lock control node, and the lock table of the current lock control node will retain the data of the second cache lock.

[0096] By popping the third reassignment request from the spliced waiting queue, the blockage of the requests after the third reassignment request can be lifted, enabling the affinity lock control nodes to execute these requests in sequence.

[0097] In some embodiments of the management method of the present invention, as Figure 5 shown, the steps for the coordination node to update the lock control index include:

[0098] S411, the coordination node updates the current lock control index according to the correspondence between all the data objects to be changed to the master and the corresponding affinity lock control nodes, to obtain a new lock control index;

[0099] S413, 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;

[0100] S415, 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.

[0101] The new lock control index can be a hash index map (HashMap) based on the affinity map<k,v> function, and this hash index map can replace the one based on the current lock control index. The current lock control index can be a lock control index based on the consistent hashing algorithm. In this way, cross-node network communication can be reduced, thereby reducing network I / O overhead, improving the database operation efficiency, and further improving the user experience. The current lock control index can also be the hash index map of the previous monitoring period (the affinity relationship may be different in different monitoring periods). In this way, cross-node network communication in the current monitoring period can be effectively reduced, thereby reducing network I / O overhead, improving the database operation efficiency, and further improving the user experience.

[0102] At the same time, there is usually only a unique message version number in the cluster, and this message version number will be carried in any communication message. When the message version number carried by 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 any two processes in the cluster have a highly consistent understanding of the message.

[0103] In this embodiment, when the control lock index is updated, the message version is also updated to ensure the consistency of message understanding among nodes. Specifically, a node can set a message reference count variable. The coordination node broadcasts a 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, the reference count variable is decremented by 1. When the reference count of the current message version reaches 0, the lock resource management process blocks and updates 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 also constructs a HashMap according to the affinity map<k,v> function. After the control lock index is updated, the lock resource management process releases the lock. At this time, each process can request the new message version, and the reference count variable is incremented by 1 each time a request is made until the value of the reference count variable reaches the initial value.

[0104] In some embodiments of the management method of the present invention, as Figure 6 shown, the steps for the current control lock node to send the data of the second cache lock of the data object to be master-changed to the corresponding affinity control lock node include:

[0105] S511, putting the data of each second cache lock into the sending window of the current control lock node corresponding to the corresponding affinity control lock node;

[0106] S513, in response to all the data of the second cache locks being in the sending window, canceling the reallocation state of the database cluster;

[0107] S515, sending the sending window to the corresponding affinity control lock node.

[0108] In this embodiment, the current control lock node can traverse the lock table and put all the data of the second cache locks in the lock table into the sending window one by one to send to the affinity control lock node to prevent omission.

[0109] After the coordination node updates the control lock index, the request for the data object to be master-changed is sent to the affinity control lock node. When the lock table of the data object to be master-changed of the current control lock node is empty, the reallocation state of the database cluster can be canceled, and the boolean value of the CFProcessResourceTransfer parameter can be set to false to prevent the affinity control lock node from adding a second reallocation request to the newly generated cache lock.

[0110] After the affinity control lock node receives the data of the second cache lock, replays the data and pops the second reallocation request, and then can execute the requests blocked after the second reallocation request.

[0111] In some embodiments of the management method of the present invention, as Figure 7 shown, the steps for obtaining the affinity relationship between data objects and nodes in the database cluster include:

[0112] S611, The affinity statistics counting table is blocked. The affinity statistics counting table counts the number of times each node accesses each data object;

[0113] S612, Traverse the affinity statistics counting table to determine whether there is a next data object;

[0114] S613, Determine whether the affinity condition is satisfied between the data object and the node with the most access times; if so, execute S614; if not, execute S615;

[0115] S614, Mark the affinity relationship between the data object and its affinity lock node in the affinity relationship list, and return to execute S612;

[0116] S615, Unlock the affinity statistics counting table.

[0117] In some embodiments of the management method of the present invention, as Figure 8 shown, the management method includes:

[0118] S621, Determine whether the affinity relationship list is non-empty; if so, execute S622; if not, execute S635;

[0119] S622, Traverse the affinity relationship list to determine whether there is a next affinity relationship; if so, execute S623; if not, execute S635;

[0120] S623, Broadcast and notify the affinity relationship of this migration;

[0121] S624, The current lock node blocks the lock table of the cache lock;

[0122] S625, Traverse the lock table to determine whether there is a next cache lock; if so, execute S626; if not, execute S630;

[0123] S626, Determine whether the cache lock is the first cache lock of the data object whose master needs to be changed for the affinity relationship of this migration; if so, execute S627; if not, return to execute S625;

[0124] S627, Add the first reallocation request to the first waiting queue of the first cache lock;

[0125] S628, Mark the first cache lock in the first list to be migrated;

[0126] S629, Mark the first cache lock in the first list to be deleted; return to execute S625;

[0127] S630, Set the CFProcessResourceTransfer parameter to true;

[0128] S631, Unlock the lock table;

[0129] S632, Execute the steps of the first migration phase;

[0130] S633, Execute the steps of the second migration phase;

[0131] S634, Execute the steps of the third migration phase; Return to execute S622;

[0132] S635, End.

[0133] In some embodiments of the management method of the present invention, as Figure 9 shown, the steps of the first migration phase include:

[0134] S641, Traverse the first list of items to be migrated, and determine whether there is a next first cache lock; if so, execute S642; if not, execute S645;

[0135] S642, Determine whether the head of the first waiting queue of the first cache lock is a first reallocation request; if so, execute S643; if not, return to execute S641;

[0136] S643, Delete the first cache lock from the first list of items to be migrated;

[0137] S644, Put the first data of the first cache lock into the sending window; Return to execute S641;

[0138] S645, Send the sending window to the affinity lock control node;

[0139] S646, The affinity lock control node replays the first data of the received first cache lock;

[0140] S647, The affinity lock control node adds the third reallocation request to the second waiting queue of the first cache lock.

[0141] In some embodiments of the management method of the present invention, as Figure 10 shown, the steps of the second migration phase include:

[0142] S651, Lock the lock control index;

[0143] S652, Lock the message version number;

[0144] S653, Update the lock control index;

[0145] S654, Broadcast a request for all node processes to invalidate the current message version;

[0146] S655, Unlock the lock control index and the message version number;

[0147] S656. Construct the cache processing bitmap of the first cache lock and determine whether it is cleared. If so, execute S657.

[0148] S657. Traverse the first list of items to be deleted and determine whether there is a next first cache lock. If so, execute S658. If not, execute S660.

[0149] S658. Put the second data of the first cache lock into the sending window.

[0150] S659. Delete the first cache lock from the first list of items to be deleted. Return to execute S657.

[0151] S660. The current lock control node sends the sending window to the affinity lock control node.

[0152] S661. The affinity lock control node splices the first waiting queue onto the second waiting queue.

[0153] S662. Pop the third reassignment request from the spliced waiting queue.

[0154] Among them, when the cache processing bitmap of the first cache lock is not cleared, it can wait for it to be cleared and receive the clearing signal. When the cache processing bitmap of the first cache lock is cleared, it indicates that all currently processing requests of the first cache lock have been completed, that is, all requests have been sent to the first waiting queue. In this way, requests can be prevented from being missed when sending the second data.

[0155] In some embodiments of the management method of the present invention, as Figure 11 shown, the steps of the third migration stage include:

[0156] S671. The current lock control node locks the lock table of the cache lock.

[0157] S672. Traverse the lock table and determine whether there is a next cache lock. If so, execute S673. If not, execute S676.

[0158] S673. Determine whether the cache lock is the second cache lock of the data object whose master needs to be changed for the affinity relationship of this migration. If so, execute S674. If not, return to execute S672.

[0159] S674. Put the second cache lock into the sending window.

[0160] S675. Delete the second cache lock from the lock table. Return to execute S672.

[0161] S676. Set the CFProcessResourceTransfer parameter to false.

[0162] S677. The current lock control node unlocks the lock on the lock table.

[0163] S678. Send the sending window to the affinity lock node;

[0164] S679. The affinity lock node receives the second cache lock;

[0165] S680. Determine whether the second cache lock already exists in the affinity lock node; if so, execute S681; if not, execute S682;

[0166] S681. Splice the waiting queue of the received second cache lock to the waiting queue of the local second cache lock;

[0167] S682. Add the second cache lock to the lock table of the affinity lock node.

[0168] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be executed 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 idea provided by the method in this embodiment, additional changes can be made to the above method.

[0169] It should be understood that in some embodiments, each part can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system.

[0170] The embodiment of the present invention also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 12 is a schematic diagram of a computer program product 10 according to an embodiment of the present invention, Figure 13 is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention, Figure 14 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 in the memory 31 and running on the processor 32.

[0171] 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., via the Internet using an Internet service provider). 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.

[0172] For the description of this embodiment, the computer program product 10 is a related product that includes the computer program 11.

[0173] 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.

[0174] 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.

[0175] 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.

[0176] 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.

[0177] Up to this point, those skilled in the art should recognize that although multiple exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications that conform to the principles of the present invention can still be directly determined or derived from the content disclosed in 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 determined to cover all these other variations or modifications.

Claims

1. A management method for a database cluster, characterized in that, Including: Obtain the data objects to be master-changed in the database cluster, where the current lock-holding node of the data objects to be master-changed and the affinity lock-holding node having an affinity relationship with it are not the same node, and the lock-holding node is configured to manage the cache locks of at least one data object; Control each of the current lock-holding nodes to send the data of the first cache lock of each of the data objects to be master-changed to the corresponding affinity lock-holding node, where the first cache lock is an existing cache lock; In response to the coordination node of the database cluster updating the lock control index, control each of the current lock-holding nodes to send the data of the second cache lock of each of the data objects to be master-changed to the corresponding affinity lock-holding node, where the coordination node is the node where the coordinator is located, the lock control index describes the mapping relationship between the data objects and the lock-holding nodes in the database cluster, and the second cache lock is a newly generated cache lock for the data objects to be master-changed before the lock control index is updated.

2. The management method according to claim 1, wherein The step of the current lock-holding node sending the data of the first cache lock of the data object to be master-changed to the corresponding affinity lock-holding node includes: Adding a first reassignment request to the first waiting queue of the first cache lock and marking the first cache lock to the first migration list, where the first reassignment request is used to request the 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 of the first cache lock; In response to all the first cache locks being added with the first reassignment request, setting the database cluster to the reassignment state, and each of the current lock-holding nodes is configured to add a second reassignment request to the waiting queue of each newly generated second cache lock when the database cluster is in the reassignment state, where the second reassignment request is used to request the reassignment of the lock-holding node to block the waiting queue corresponding to the second cache lock; Sending the data of each of the first cache locks in the first migration list to the corresponding affinity lock-holding node.

3. The management method according to claim 2, characterized in that, The sending the data of the first cache lock in the first migration list to the corresponding affinity lock-holding node includes: In response to the first reassignment request being at the head of the first waiting queue, putting the first data of the first cache lock into the sending window corresponding to the corresponding affinity lock-holding node of the current lock-holding node; In response to the first data of all the first cache locks managed by the current lock-holding node being in the sending window, sending the sending window to the corresponding affinity lock-holding node, so that the affinity lock-holding node adds a third reassignment request to the second waiting queue of the first data of the received first cache lock, where the first data does not include the data of the first waiting queue, and the third reassignment request is used to request the reassignment of the lock-holding node to block the second waiting queue, and the second waiting queue is located at the affinity lock-holding node; In response to the coordination node updating the control lock index, the current control lock node sends the second data of the first cache lock to the corresponding affinity control lock node, where the second data includes the data of the first waiting queue, so that the affinity control lock node splices the received first waiting queue onto the second waiting queue.

4. The management method according to claim 3, wherein after the step that the current control lock node sends the second data of the first cache lock to the corresponding affinity control lock node, the management method further includes: the current control lock node deletes all the data of the first cache lock; and after the step that the affinity control lock node splices the received first waiting queue onto the second waiting queue, the management method further includes: popping the third reallocation request from the spliced waiting queue.

5. The management method according to claim 2, characterized in that The step that the current control lock node sends the data of the second cache lock of the data object to be remastered to the corresponding affinity control lock node includes: putting the data of each second cache lock into a sending window of the current control lock node corresponding to the corresponding affinity control lock node; in response to that all the data of the second cache lock are in the sending window, canceling the reallocation state of the database cluster; sending the sending window to the corresponding affinity control lock node.

6. The management method according to claim 1, characterized in that, The step that the coordination node updates the control lock index includes: the coordination node updates the current control lock index according to the corresponding relationship between all the data objects to be remastered and the corresponding affinity control lock nodes to obtain a new control lock index; 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 a new message version corresponding to the new control lock index in sequence according to the process; in response to 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.

7. The management method according to claim 1, characterized in that The obtaining of the data objects to be remastered in the database cluster includes: obtaining the affinity relationship between the data objects and the nodes in the database cluster; according to the affinity relationship, determining the affinity control lock node corresponding to each data object, and determining the data objects in which the current control lock node and the affinity control lock node are inconsistent as the data objects to be remastered.

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.

Images