Method for access control of a database shared cluster and related product

Abstract

The application provides a database shared cluster access control method and related products. The method comprises: in response to detecting a database shared cluster topology change event, performing a global lock acquisition operation on a current cluster topology view; after the global lock acquisition succeeds, sending a change preprocessing instruction to a target process in the database shared cluster that needs to initiate remote resource access; in response to all remote resource access requests initiated in the database shared cluster being completed, making the database shared cluster enter a request empty state, and in the request empty state, performing a member node update operation according to a change type indicated by the topology change event, and reconstructing a consistent hash ring based on an updated cluster topology view; and releasing the global lock and sending a change completion instruction. The scheme of the application enables all requests in the change process to be correctly routed and executed based on a consistent cluster topology view, while avoiding resource competition or data conflict.

Description

Technical Field

[0001] This invention relates to database technology, and in particular to an access control method and related products for a database shared cluster. Background Technology

[0002] In a shared database cluster, when any member node accesses global resources, if the cluster membership changes (such as a node joining or leaving), the remote request being processed will usually be interrupted or need to be retried, leading to increased request latency or errors. After the change is completed, because it cannot be confirmed whether the issued request has been executed on the old management node, it may cause problems such as resource contention, request conflicts, or data inconsistency, affecting the stability of the database system and the accuracy of the data. Summary of the Invention

[0003] One objective of this invention is to improve the performance of remote request processing in a database shared cluster during member changes, and to avoid delays and errors caused by request interruptions or retries.

[0004] A further objective of this invention is to prevent remote requests being interrupted or retried during member change processes, thereby ensuring the continuity of request execution.

[0005] Specifically, the present invention provides an access control method for a database shared cluster, comprising: In response to the detection of a database shared cluster topology change event, a global lock acquisition operation is performed on the current cluster topology view; the global lock is used to prevent concurrent changes to the cluster topology view; the topology change event is the addition, removal, or change of the running status of any member node in the database shared cluster. After successfully acquiring the global lock, a change preprocessing instruction is sent to the target process in the database shared cluster that needs to initiate remote resource access; the change preprocessing instruction is used to cause the target process to stop initiating new remote resource access requests. In response to the completion of all remote resource access requests initiated in the database shared cluster, the database shared cluster enters a request emptying state. In the request emptying state, member node update operations are performed according to the change type indicated by the topology change event, and a consistent hash ring is reconstructed based on the updated cluster topology view. The consistent hash ring is used to determine the resource management node in the database shared cluster. Release the global lock and send a change completion indication; the change completion indication is used to enable the target process to initiate a new remote resource access request based on the reconstructed consistent hash ring.

[0006] Optionally, performing a global lock acquisition operation on the current cluster topology view includes: Increment the private counter maintained by the current process. Detect whether the incremented private counter value is equal to 1, wherein the incremented private counter value being equal to 1 indicates that the current process did not hold any lock state on the current cluster topology view before this increment operation; If so, increment the shared counter that is globally maintained by the database shared cluster; If not, keep the count value of the shared counter unchanged.

[0007] Optionally, before performing the increment operation on the private counter maintained by the currently running process, the following steps are also included: Detect whether the count value of the private counter has reached a preset upper limit threshold; If so, the increment operation is not performed, an error message is returned, and the global lock acquisition operation on the current cluster topology view is terminated; If not, perform the increment operation.

[0008] Optionally, putting the database shared cluster into a request queuing state includes: Obtain the current count value of the shared counter maintained globally by the database shared cluster; the current count value of the shared counter is used to represent the total number of processes currently holding a lock state for the cluster topology view; Detect whether the current count value of the shared counter is equal to 0; If so, it is determined that all remote resource access requests have been completed, and the database shared cluster has entered a request emptying state.

[0009] Optionally, performing member node update operations based on the change type indicated by the topology change event includes: While maintaining the global lock and without changing the current cluster topology view, member nodes can be added or deleted, or the running status information of member nodes can be updated, based on the topology change event.

[0010] Optionally, reconstructing the consistent hash ring based on the updated cluster topology view includes: Retrieve the identity identifiers of all member nodes in the updated cluster topology view; Map the identity identifiers of each member node to the ring space of the consistent hash ring to generate the hash position of each member node in the ring space; Based on the hash position of each member node in the ring space, a mapping relationship between the member nodes and the ring space interval is constructed to form a reconstructed consistent hash ring.

[0011] Optionally, releasing the global lock includes: Perform a decrement operation on the private counter maintained by the currently running process; Detect whether the count value of the decremented private counter is equal to 0, wherein the count value of the decremented private counter being equal to 0 is used to indicate that the current process no longer holds any lock state for the current cluster topology view after this decrement operation; If so, perform a decrement operation on the shared counter that is globally maintained by the database shared cluster; If not, keep the count value of the shared counter unchanged.

[0012] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the access control method for any of the above-described database sharing clusters.

[0013] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the steps of the access control method for any of the above-described database shared clusters.

[0014] According to another aspect of the present invention, a computer device is also provided, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of any database sharing cluster access control method.

[0015] The access control method for a shared database cluster of this invention, by performing a global lock acquisition operation on the current cluster topology view, first prevents concurrent changes to the cluster topology view after a topology change event is triggered. This ensures that all remote resource access requests during the entire topology change process are calculated and routed to resource management nodes based on the same stable cluster topology view, avoiding problems such as inconsistent hash rings, disordered resource access, or requests being routed to incorrect nodes due to concurrent topology changes, thus guaranteeing the global consistency of resource access in the distributed database cluster during topology changes. After successfully acquiring the global lock, a change preprocessing instruction is sent to the target processes, causing all target processes to proactively stop initiating new remote resource access requests before the topology change. Simultaneously, all remote resource access requests already initiated in the cluster are completed, allowing the cluster to enter a request clearing state before executing member node updates and hash ring reconstruction, avoiding service interruptions caused by forced request interruptions or maintenance shutdowns. A global lock mechanism is adopted to uniformly coordinate the concurrent control of topology changes and resource access. The global lock is acquired only when a topology change event is triggered and is released immediately after the change is completed. The lock is held continuously throughout the entire change process (including request emptying, member node updates, and hash ring reconstruction). The release timing is clear and can be precisely controlled by the completion status of the change process. Since the acquisition and release of the global lock are strictly bound to the lifecycle of the change process, lock conflicts caused by multiple change events simultaneously contending for the global lock in a distributed environment are avoided, thereby improving the availability and stability of the database system.

[0016] Furthermore, the access control method for the database shared cluster of the present invention maintains a private counter for the current process, and updates the global shared counter only when the private counter increments from 0 to 1, thereby achieving reentrancy of lock acquisition. Multiple lock acquisitions by the same process only require updating the shared counter the first time, avoiding deadlock problems caused by nested acquisitions of the same lock. The update granularity of the shared counter is reduced from the request level to the process level, significantly reducing the frequency of cross-process access to shared storage, lowering cache consistency overhead, and improving system throughput in high-concurrency scenarios. By reading a single shared counter, it is possible to accurately determine whether a process holds a topology view lock without traversing all processes, providing a lightweight and reliable basis for emptying decisions.

[0017] Furthermore, in the access control method for the database shared cluster of the present invention, each remote request must hold a topology view lock before it is initiated. Therefore, when the shared counter reaches zero, it indicates that no process holds a lock, thus confirming that the database shared cluster has entered the request emptying state, executing member node update operations and reconstructing the consistent hash ring. The emptying determination is performed by reading the current count value of the shared counter maintained globally by the cluster, which can be completed with only one atomic read operation, with a time complexity of O(1), which is independent of the cluster size. This significantly reduces the time overhead and network round trips in clusters with a large number of nodes. When the shared counter reaches zero, a topology change is initiated to ensure that the change operation does not conflict with any ongoing remote requests for resource access, ensuring the security of the cluster topology change process. Using the shared counter as the single determination criterion for emptying completion simplifies the distributed emptying problem into a single-point counting query, significantly reducing the implementation complexity of the change decision logic.

[0018] Furthermore, the access control method for the database shared cluster of the present invention updates the global shared counter only when the private counter decreases from 1 to 0, achieving symmetric reentrancy of lock release. Multiple lock releases by the same process only require updating the shared counter on the last release, avoiding lock state anomalies caused by incomplete or excessive lock release. Only when all processes holding locks have completed the decrement operation and the shared counter reaches zero is it confirmed that no process holds the lock, providing a clear completion condition for releasing the global lock. This avoids premature or delayed execution of change operations due to inaccurate lock release timing, ensuring the overall correctness and timing controllability of the topology change process.

[0019] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0020] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a schematic flowchart of an access control method for a database shared cluster according to an embodiment of the present invention; Figure 2 This is a schematic flowchart illustrating the execution of a global lock acquisition operation in an access control method for a database shared cluster according to an embodiment of the present invention; Figure 3 This is a schematic flowchart of the exception handling operation in the access control method of a database shared cluster according to an embodiment of the present invention; Figure 4This is a schematic flowchart illustrating the process of entering the request emptying state in an access control method for a database shared cluster according to an embodiment of the present invention. Figure 5 This is a schematic flowchart of reconstructing a consistent hash ring in an access control method for a database shared cluster according to an embodiment of the present invention; Figure 6 This is a schematic flowchart illustrating the release of a global lock in an access control method for a database shared cluster according to an embodiment of the present invention; Figure 7 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 8 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; Figure 9 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0021] In a shared database cluster, when any member node accesses global resources, if the cluster membership changes (such as a node joining or leaving), the remote request being processed will usually be interrupted or need to be retried, leading to increased request latency or errors. After the change is completed, because it cannot be confirmed whether the issued request has been executed on the old management node, it may cause problems such as resource contention, request conflicts, or data inconsistency, affecting the stability of the database system and the accuracy of the data.

[0022] Database shared clusters typically use a consistent hash ring to manage global resources. Each member node determines the corresponding resource management node by calculating the position of the resource key value on the hash ring and then initiates a remote resource access request to that node. However, when cluster members change, the consistent hash ring needs to be rebuilt to reflect the latest cluster topology. Otherwise, some requests may be routed to offline nodes or newly joined nodes that have not yet completed initialization, causing request failures. If remote requests are still initiated based on the old ring during the hash ring reconstruction process, the inconsistency between the old and new ring views may lead to requests being routed to the wrong nodes, further exacerbating the risk of resource access conflicts and data inconsistency.

[0023] In existing technologies, one approach to address the aforementioned issues is to directly interrupt all ongoing remote requests when cluster members change, and then have the upper-layer application retry them after the change is complete. However, this approach may trigger a retry storm due to a large number of retries in request-intensive scenarios, leading to overall cluster performance degradation. Another approach is to suspend all remote resource access during the change and resume access after the change is complete. While this avoids routing errors and resource conflicts, it introduces a service interruption window during which the cluster cannot process any remote requests, making it difficult to meet the service continuity requirements of high-availability scenarios.

[0024] In summary, ensuring uninterrupted remote resource access during cluster topology changes while guaranteeing that all requests are correctly routed and executed based on a consistent cluster topology view, and avoiding resource contention or data conflicts caused by inconsistencies in the topology view between requests before and after the change, is a pressing technical problem in the field of shared database clusters.

[0025] Figure 1 This is a schematic flowchart of an access control method for a database shared cluster according to an embodiment of the present invention. Figure 1 As shown, the access control method for this database shared cluster can generally include: Step S101: In response to detecting a database shared cluster topology change event, a global lock acquisition operation is performed on the current cluster topology view; the global lock is used to prevent concurrent changes to the cluster topology view; the topology change event is the addition, removal, or change of the running status of any member node in the database shared cluster. Step S102: After successfully acquiring the global lock, a change preprocessing instruction is sent to the target process in the database shared cluster that needs to initiate remote resource access; the change preprocessing instruction is used to make the target process stop initiating new remote resource access requests. Step S103: In response to the completion of all remote resource access requests initiated in the database shared cluster, the database shared cluster enters the request emptying state. In the request emptying state, member node update operations are performed according to the change type indicated by the topology change event, and the consistent hash ring is reconstructed based on the updated cluster topology view. The consistent hash ring is used to determine the resource management node in the database shared cluster. Step S104: Release the global lock and send a change completion indication; the change completion indication is used to enable the target process to initiate a new remote resource access request based on the reconstructed consistent hash ring.

[0026] In this embodiment, when the member management component of the database shared cluster detects a topology change event, it initiates a change processing procedure. Topology change events include, but are not limited to: the active joining of member nodes (such as a new node joining when the cluster is expanded), the active removal of member nodes (such as a node leaving when the cluster is scaled down), and changes in the running status of member nodes (such as a node restarting or rejoining after network partition recovery). The above-mentioned change events are detected by the cluster membership service through heartbeat detection or explicit registration mechanisms, and corresponding change event notifications are generated.

[0027] In response to a detected topology change event, the database system acquires a global lock on the current cluster topology view. This global lock is a distributed lock whose scope covers the entire shared database cluster. It prevents concurrent modifications to the topology view during remote request processing, ensuring that at most one change process holds the lock and performs the topology change at any given time. The global lock acquisition operation can be performed in a blocking or non-blocking manner.

[0028] In this embodiment, after successfully acquiring the global lock, the member management component broadcasts a change preprocessing instruction to all target processes in the database shared cluster that may need to initiate remote resource access. The member management component determines the target processes based on process registration information or process type identifiers; the target processes include all worker processes participating in global resource access.

[0029] The change preprocessing instruction includes a notification that the change process has been initiated, and an instruction to stop initiating new remote requests. Upon receiving this instruction, the target process switches its state to change-ready mode. In this mode, all new remote resource access requests are temporarily stored in a local pending queue, or a status code indicating that a change is in progress is returned directly, without being sent to the network. For remote requests already initiated and in transit, the target process continues to allow them to execute normally until completion, without actively interrupting or canceling them.

[0030] In this embodiment, after sending the change preprocessing instruction, the member management component continuously monitors whether there are still any ongoing remote resource access requests in the cluster. Once it is confirmed that all initiated remote resource access requests have been completed, the cluster enters a request clearing state. In the request clearing state, the member management component performs corresponding member node update operations based on the type of topology change event: if a node is added, the new node's identification information and corresponding routing entry are added to the cluster topology view; if a node is removed, the node's identification information and associated routing entry are deleted from the topology view; if the running status changes, the node's status identifier is updated. After the member node update operation is completed, the member management component reconstructs the consistent hash ring based on the updated cluster topology view. The consistent hash ring is used to map each member node to the ring space and, upon receiving a remote resource access request, routes it to the corresponding resource management node in the ring space based on the resource identifier carried in the request.

[0031] In this embodiment, after the consistent hash ring is reconstructed, the member management component releases the global lock and sends a change completion indication to all target processes. The change completion indication includes a change process completion identifier, version information of the new consistent hash ring, and a node list. Upon receiving the change completion indication, the target process compares the ring version information stored locally with the version information in the change completion indication. If they match, the process switches its state from change preparation mode to normal operation mode and reconstructs the consistent hash ring structure locally based on the node list to initiate new remote resource access requests based on the reconstructed consistent hash ring. If they do not match, the process reloads the latest consistent hash ring information from shared storage before switching back to normal operation mode.

[0032] Based on the above steps, by performing a global lock acquisition operation on the current cluster topology view, concurrent changes to the cluster topology view are prevented after a topology change event is triggered. This ensures that all remote resource access requests during the entire topology change process are calculated and routed to resource management nodes based on the same stable cluster topology view. This avoids problems such as inconsistent hash rings, incorrect resource access, or requests being routed to the wrong nodes caused by concurrent topology changes, guaranteeing the global consistency of resource access in the distributed database cluster during topology changes. After successfully acquiring the global lock, a change preprocessing instruction is sent to the target processes, causing all target processes to proactively stop initiating new remote resource access requests before the topology change. Simultaneously, they wait for all remote resource access requests already initiated in the cluster to complete, allowing the cluster to enter a request clearing state before executing member node updates and hash ring reconstruction. This avoids service interruptions caused by forced request interruptions or maintenance shutdowns. A global lock mechanism is adopted to uniformly coordinate the concurrent control of topology changes and resource access. The global lock is acquired only when a topology change event is triggered and is released immediately after the change is completed. The lock is held continuously throughout the entire change process (including request emptying, member node updates, and hash ring reconstruction). The release timing is clear and can be precisely controlled by the completion status of the change process. Since the acquisition and release of the global lock are strictly bound to the lifecycle of the change process, lock conflicts caused by multiple change events simultaneously contending for the global lock in a distributed environment are avoided, thereby improving the availability and stability of the database system.

[0033] Figure 2 This is a schematic flowchart illustrating the execution of a global lock acquisition operation in an access control method for a database shared cluster according to an embodiment of the present invention. Figure 2 As shown, performing a global lock acquisition operation on the current cluster topology view includes: Step S201: Increment the private counter maintained by the current process. Step S202: Detect whether the incremented private counter value is equal to 1, wherein the incremented private counter value being equal to 1 indicates that the current process did not hold any lock on the current cluster topology view before this increment operation. Step S203: If yes, increment the shared counter maintained globally by the database shared cluster. Step S204: If not, keep the count value of the shared counter unchanged.

[0034] In this embodiment, before initiating a remote resource access request, the current process performs an atomic increment operation on a private counter maintained locally within the process. The private counter is stored in the process's local memory space, and its lifecycle is consistent with the process's, recording the nested number of times the current process holds a locked state in the cluster topology view. The atomic increment operation is an intra-process operation, not involving cross-process communication or distributed coordination, resulting in low execution latency.

[0035] Atomic increment operations are intra-process operations, involving no cross-process communication or distributed coordination, resulting in low execution latency. For example, atomic increments can be implemented using atomic instructions supported by the underlying hardware (such as the LOCK XADD instruction in x86 architecture or the LDADD instruction in ARM architecture), or relying on atomic variable operation interfaces provided at the programming language level (such as std::atomic::fetch_add in C++ or AtomicInteger.incrementAndGet in Java), ensuring atomicity and memory visibility in a multi-threaded environment. After an atomic increment operation is completed, the count value before the increment represents the lock nesting depth before the operation, and the count value after the increment represents the lock nesting depth after the operation.

[0036] In this embodiment, after the increment operation is completed, the current process checks whether the incremented private counter value is 1. The purpose of this check is to determine whether the current process already held a lock on the cluster topology view before this increment operation. If the incremented private counter value is 1, it indicates that the private counter value was 0 before the increment, meaning the current process did not hold any topology view locks before executing this lock acquisition, and this operation is the process's first lock acquisition. If the incremented private counter value is greater than 1, it indicates that the private counter already held a lock before the increment, and this operation is the process's nested lock acquisition. This check is an integer comparison operation, which is also a local operation and does not incur cross-process communication overhead.

[0037] In this embodiment, when the incremented private counter value is detected to be equal to 1, the current process executes the increment operation of the shared counter. The shared counter is maintained globally by the database shared cluster, and its storage location is a shared storage area accessible to all processes (such as shared memory or a distributed coordination service). Its value represents the total number of processes holding topology view locks in the current cluster. When the private counter increments from 0 to 1, it indicates that the current process has switched from a state without a lock to a state with a lock, and an increment operation needs to be performed on the shared counter to ensure that the value of the shared counter is consistent with the total number of processes actually holding locks in the system. The increment operation of the shared counter involves cross-process access to shared resources, and atomicity needs to be guaranteed by a synchronization mechanism. In specific implementation, the shared counter can be stored in shared memory and incremented through hardware-supported atomic instructions; in a distributed environment, it can also be implemented through a distributed counter based on a consensus protocol. The update frequency of the shared counter is significantly reduced compared to the private counter, that is, it is triggered only when a process first acquires a lock, rather than when every request is initiated.

[0038] In this embodiment, when the incremented private counter value is detected to be greater than 1, the current process maintains the shared counter value unchanged. In this case, the current process already holds the lock before this operation, and this operation is a nested lock acquisition within the process, that is, the same process initiates a remote request again while already holding the lock, reusing the existing topology view lock state. Since this process has previously included its own count in the shared counter (that is, the increment operation of the shared counter was triggered when the private counter incremented from 0 to 1 in the previous operation), this nested acquisition does not add a new process holding the lock, so the value of the shared counter does not need to be changed, and the original count value can be maintained.

[0039] It's important to note that the shared counter operates on a process-by-process, not request-by-request, granularity. Even if multiple requests are in transit for the same process simultaneously, they are only counted once at the shared counter level. This design effectively controls the update frequency of the shared counter, reducing the global synchronization performance overhead in multi-process concurrent scenarios.

[0040] Based on the above steps, by maintaining a private counter for the current process and updating the global shared counter only when the private counter increments from 0 to 1, reentrancy of lock acquisition is achieved. When the same process acquires the lock multiple times, the shared counter only needs to be updated the first time, avoiding deadlock problems caused by nested acquisition of the same lock. The update granularity of the shared counter is reduced from the request level to the process level, which significantly reduces the frequency of cross-process access to shared storage, reduces cache consistency overhead, and improves system throughput in high-concurrency scenarios. By reading a single shared counter, it is possible to accurately determine whether a process holds a topology view lock without traversing all processes, providing a lightweight and reliable basis for emptying decisions.

[0041] Figure 3 This is a schematic flowchart illustrating the exception handling operation in an access control method for a database shared cluster according to an embodiment of the present invention. Figure 3 As shown, before performing the increment operation on the private counter maintained by the currently running process, the following steps are also included: Step S301: Detect whether the count value of the private counter has reached the preset upper limit threshold; Step S302: If yes, do not perform the increment operation, return an error message, and terminate the global lock acquisition operation on the current cluster topology view; Step S303: If not, perform the increment operation.

[0042] In this embodiment, before the current process increments the private counter, it checks whether the current count value of the private counter has reached a preset upper limit threshold. The preset upper limit threshold is a predefined integer constant, and its value is determined based on the process's resource capacity and system design constraints. The upper limit threshold is set based on factors including, but not limited to, the following: the maximum number of file descriptors available to the process, system-level limits on the number of network connections, the size of the buffer in the process's memory space used to manage request context, and the operating system's maximum thread concurrency constraints. For example, the preset upper limit threshold can be 1024, 4096, or 65535, with the specific value depending on the resource specifications and cluster size of the target deployment environment. The purpose of setting the upper limit threshold is to ensure that the number of nested topology view locks held by the current process does not exceed the process's resource carrying capacity, preventing resource exhaustion or process crashes due to infinite nested locking.

[0043] The detection of the private counter's upper limit threshold is a process-local integer value comparison operation, not involving cross-process or cross-node communication. During the detection process, the current process compares the current value of the private counter with the preset upper limit threshold: if the current value is less than the upper limit threshold, it means that the process still has resource reserves to allow new lock acquisition operations; if the current value has reached the upper limit threshold, it means that the process's lock holdings are saturated and it can no longer accept new lock acquisition requests. Through this design, the process's resource usage is always within a controllable range, ensuring the resource security of the database system.

[0044] In this embodiment, if the current count value of the private counter has reached or exceeded the preset upper limit threshold, the current process performs the following operations: Refuse to perform the increment operation and keep the current value of the private counter unchanged; Return an error code to the caller. The error code includes an error type identifier, the current private counter value, the preset upper limit threshold, and the process identifier. The error type identifier indicates that resources are exhausted or the maximum number of locked items has been reached. The current global lock acquisition operation is terminated, and subsequent steps will not be executed.

[0045] Other business logic in the current process handles the error code accordingly, including waiting and retrying or reporting the exception to the management module. Through the above processing, the value of the private counter is constrained within a preset upper limit threshold, fundamentally avoiding process instability caused by resource exhaustion.

[0046] In this embodiment, if the current count value of the private counter has not reached the preset upper limit threshold, the current process executes an increment operation on the private counter. The increment operation is an atomic operation within the process, and the incremented count value is the original value plus 1. After the increment operation is completed, the current process checks whether the incremented count value is equal to 1 to determine whether the shared counter needs to be updated.

[0047] Based on the above steps, by checking whether the count value has reached the preset upper limit threshold before the private counter increments, the increment operation is only allowed when the count value has not reached the threshold. This avoids the risk of exhausting process resources (such as file descriptors, network connections, memory buffers, etc.) due to infinite nested locking, and fundamentally prevents process crashes or system instability.

[0048] Figure 4 This is a schematic flowchart illustrating the process of entering a request emptying state in an access control method for a database shared cluster according to an embodiment of the present invention. Figure 4 As shown, the process of putting a database shared cluster into a request exhaustion state includes: Step S401: Obtain the current count value of the shared counter maintained globally by the database shared cluster; the current count value of the shared counter is used to represent the total number of processes currently holding a lock state for the cluster topology view; Step S402: Check if the current count value of the shared counter is equal to 0; Step S403: If yes, determine that all remote resource access requests have been completed and determine that the database shared cluster has entered the request emptying state.

[0049] In this embodiment, after the aforementioned change preprocessing instruction is sent, the member management component enters the drain monitoring phase. The member management component reads the current count value of the shared counter from the global storage medium. The shared counter is maintained globally by the database shared cluster, and its storage location depends on the cluster deployment. In a cluster based on shared storage, the shared counter is stored in a shared memory area, which is accessed by each node through a unified memory mapping mechanism; in a cluster based on a distributed coordination service, the shared counter is maintained through a distributed key-value store (such as etcd or ZooKeeper), and its value is read by each node through a remote procedure call interface. Regardless of the storage method used, the read operation must ensure that the latest committed value is obtained.

[0050] The shared counter is defined as an unsigned integer, representing the total number of processes holding a topology view lock in the current database shared cluster. For example, whenever a process's private counter increments from 0 to 1 (i.e., the process first acquires the topology view lock), the shared counter is incremented by 1; whenever a process's private counter decrements from 1 to 0 (i.e., the process completely releases the topology view lock), the shared counter is decremented by 1. Therefore, the value of the shared counter corresponds to the number of processes holding locks in the system.

[0051] In this embodiment, if the zeroing detection determines that the current count value of the shared counter is equal to 0, the member management component confirms that all remote resource access requests have been completed, and accordingly determines that the database shared cluster has entered the request queuing state. After determining that it has entered the queuing state, the member management component can perform the following optional operations: Record the timestamp of drainage completion and the total drainage waiting time for performance monitoring and log analysis. Whether to perform additional confirmation depends on the system configuration: If a cooldown window is configured, the shared counter will be read again after an additional preset time (e.g., 1 to 3 seconds) to confirm that it is still 0, in order to eliminate the boundary situation where the request completion status has not been synchronized due to network latency. After the cooldown window ends, the member management component finally confirms that the drain status has been established.

[0052] It should be noted that the emptied state indicates that there are no ongoing remote resource access requests in the database shared cluster, and all requests sent before the aforementioned change preprocessing instruction were completed naturally. In this state, the member management component performs member node update operations without affecting any requests.

[0053] Based on the above steps, each remote request must hold a topology view lock before initiating. Therefore, the shared counter returning to zero indicates that no process holds a lock, thus confirming that the database shared cluster has entered the request emptying state, executing member node update operations and reconstructing the consistent hash ring. The emptying determination is performed by reading the current count value of the shared counter maintained globally by the cluster, which only requires one atomic read operation and has a time complexity of O(1), which is independent of the cluster size. This significantly reduces the time overhead and network round trips in clusters with a large number of nodes. When the shared counter returns to zero, the topology change is initiated to ensure that the change operation does not conflict with any ongoing remote requests for resource access, thus ensuring the security of the cluster topology change process. Using the shared counter as the single criterion for emptying completion simplifies the distributed emptying problem into a single-point counting query, significantly reducing the implementation complexity of the change decision logic.

[0054] In the implementation of step S103, performing the member node update operation according to the change type indicated by the topology change event includes: While maintaining a global lock and without changing the current cluster topology view, member nodes can be added or removed, or the running status information of member nodes can be updated, based on topology change events.

[0055] In this implementation, after the request for a cleared status is confirmed, the member management component, while maintaining the global lock, performs member node update operations based on the type of topology change event. The global lock is held continuously throughout the update process, ensuring that the modification process of the topology view is not interfered with by other concurrent change processes, and guaranteeing the atomicity and consistency of the update operation.

[0056] If a topology change event indicates that a member node has joined, the member management component performs the node addition operation. First, it verifies the new node's legitimacy, including confirming that its identification information does not duplicate existing nodes, its network address is reachable, and its node type is compatible with the cluster. After successful verification, it creates the node's data structure in the cluster topology view, including a unique node identifier, network address and port number, node role identifier, initial status flag, and joining timestamp.

[0057] If the topology change event indicates member node removal, the member management component performs a node deletion operation. Before execution, it verifies that the node to be deleted exists in the current topology view; if it does not exist, the deletion operation is terminated. Otherwise, all associated information of the node is removed from the topology view, including deleting its data structure from the node list, cleaning up route mapping entries, and reclaiming identifier resources. The atomicity of the deletion operation is guaranteed by the continuous holding of a global lock, and the consistency of the topology view is not compromised by concurrent operations throughout the deletion process.

[0058] If a topology change event indicates a change in the running status of a member node, the member management component performs a status update operation. Running status includes normal operation, suspicious status, recovery in progress, and stopped status. The component locates the target node's data record in the topology view, updates its status field to the new value, and appends a timestamp and reason identifier for the status change to the update record.

[0059] All the above-mentioned add, delete, and update operations are performed within the context of holding the global lock. The continuous holding of the global lock makes the entire update operation sequence appear as an indivisible atomic operation to the outside world. That is, no other process can observe the intermediate state of the topology view before the lock is released, and can only read the final view after the update is completed, thereby eliminating the risk of inconsistency in the topology view data caused by concurrent modifications.

[0060] Figure 5 This is a schematic flowchart illustrating the reconstruction of a consistent hash ring in an access control method for a database shared cluster according to an embodiment of the present invention. Figure 5 As shown, reconstructing the consistent hash ring based on the updated cluster topology view includes: Step S501: Obtain the identity identifiers of all member nodes in the updated cluster topology view; Step S502: Map the identity identifier of each member node to the ring space of the consistent hash ring, and generate the hash position of each member node in the ring space; Step S503: Based on the hash position of each member node in the ring space, construct the mapping relationship between the member nodes and the ring space interval to form the reconstructed consistent hash ring.

[0061] In this embodiment, after the member node update operation is completed, the member management component initiates the reconstruction process of the consistent hash ring. The member management component extracts the identity identifiers of all member nodes from the updated cluster topology view, that is, it traverses the node list of the topology view and reads the unique identifier information of each node one by one.

[0062] For example, the identity identifier can take one of the following forms: node ID (a globally unique value or string assigned by the cluster member service when the node joins), a combination of IP address and port number, or node UUID. The choice of identity identifier must satisfy three characteristics: global uniqueness, stability, and hashability. Global uniqueness means that the identity identifiers of any two nodes within the same cluster are different; stability means that the identity identifier does not change during the node's operation; and hashability means that the identity identifier can be used as an input parameter for hash calculation in a hash function.

[0063] The member management component assembles all the acquired identity identifiers into a set, which contains all nodes in the current topology view that are in the "ACTIVE" state. Whether nodes marked as "SUSPECTED", "RECOVERING", or "STOPPING" in the topology view are included in this set depends on the cluster configuration policy; under the default configuration, only nodes in the "ACTIVE" state participate in the hash ring calculation.

[0064] In this embodiment, after obtaining the set of identity identifiers, the member management component performs a hash calculation on each identity identifier, mapping it to the ring space of the consistent hash ring, and generating the hash position of the node in the ring space. The ring space of the consistent hash ring is defined as a numerical range consisting of consecutive values, ranging from 0 to 2. m -1, where m is the output bit width of the hash function. In specific implementations, the value of m depends on the hash function used. For example, the MD5 algorithm outputs a 128-bit hash value, SHA-1 outputs 160 bits, and SHA-256 outputs 256 bits. Taking MD5 as an example, the ring space of the hash ring is [0, 2]. 128 -1], totaling approximately 3.4 × 10 38 Integer positions.

[0065] For each member node's identity identifier, the member management component uses it as input to a hash function to calculate a fixed-length hash value H. The position of this hash value in the ring space is the node's hash position. For example, the hash value H can be considered an m-bit binary integer, and its position coordinates in the ring space are that integer value. Due to the uniform distribution characteristic of the hash function, the hash positions of each node exhibit a random yet uniform distribution in the ring space.

[0066] The member management component generates one or more hash positions for each member node. A single hash position corresponds to a physical node scheme, meaning each physical node has only one mapping point on the ring. For example, the member management component can employ a virtual node scheme, mapping each physical node to K virtual nodes (K being a preset multiple of virtual nodes, typically 100 to 200). Each virtual node has an independent identity and its hash position is calculated separately. The virtual node scheme further distributes the load of a single physical node across multiple positions on the ring, mitigating load skew caused by uneven hash position distribution when the number of nodes is small.

[0067] In this embodiment, after all member nodes are mapped to the ring space, the member management component constructs a mapping relationship from the ring space interval to the member nodes, forming a reconstructed consistent hash ring.

[0068] The member management component sorts all node anchors in the ring space in ascending order of their numerical values. After sorting, the ring space is divided into several consecutive intervals equal to the number of nodes. Each interval begins at a given node anchor and ends at the next node anchor in a clockwise direction (the interval does not include the ending anchor). For the last node anchor, its ending point is the starting position of the ring space, thus ensuring the ring is connected end-to-end. After interval division, each position on the ring is uniquely assigned to an interval.

[0069] For each partitioned interval, the member management component establishes a mapping relationship from that interval to its starting node. When routing and locating a resource identifier, the member management component calculates the hash value of the resource identifier to obtain its position in the ring space, and searches for the first node anchor point in a clockwise direction. The member node corresponding to this anchor point is the management node for that resource.

[0070] It should be noted that the member management component generates a routing table based on the mapping relationship between the above intervals and nodes. The data structure of the routing table is a series of ordered key-value pairs, where the key is the starting position of the interval and the value is the identifier of the corresponding member node. To improve the efficiency of route lookup, the member management component can use data structures such as skip lists, binary search, or B-trees to store the routing table, so that for any given hash position, the first node in the clockwise direction can be found in O(log N) time complexity.

[0071] Based on the above steps, the hash ring is reconstructed by extracting member node identifiers from the updated cluster topology view, ensuring that the set of member nodes in the consistent hash ring remains strictly consistent with the node records in the cluster topology view. Newly added, deleted, or state-changed nodes in the topology view are accurately reflected in the ring's distribution structure after hash ring reconstruction, preventing requests from being routed to incorrect nodes due to asynchrony between the topology view and the hash ring.

[0072] Figure 6 This is a schematic flowchart illustrating the release of a global lock in an access control method for a database shared cluster according to an embodiment of the present invention. Figure 6 As shown, releasing the global lock includes: Step S601: Perform a decrement operation on the private counter maintained by the current process; Step S602: Detect whether the count value of the decremented private counter is equal to 0. The count value of the decremented private counter being equal to 0 indicates that the current process no longer holds any lock on the current cluster topology view after this decrement operation. Step S603: If yes, perform a decrement operation on the shared counter maintained globally by the database shared cluster; Step S604: If not, keep the count value of the shared counter unchanged.

[0073] In this embodiment, after the current process completes a remote resource access request and releases the corresponding topology view lock, it performs an atomic decrement operation on a private counter maintained locally by the process. The private counter records the nested number of topology view locks held by the current process, i.e., the number of pending requests currently being executed by the process that hold locks. The decrement operation reduces the current value of the private counter by 1, indicating that the process has completed a remote request and released one layer of lock nesting. After the atomic decrement operation, if the value before the decrement was greater than 1, it will still be greater than 0 after the decrement, indicating that the process has other pending requests; if the value before the decrement was equal to 1, it will return to zero after the decrement, indicating that the completed request is the last pending request for the process.

[0074] In this embodiment, after the decrement operation is completed, the current process checks whether the value of the decremented private counter is 0. The purpose of this check is to determine whether the current process still holds a topology view lock after this decrement operation. If the decremented private counter value is 0, it indicates that the private counter value was 1 before the decrement, meaning the current process had only one pending request before executing this decrement. After this request was completed, the process no longer holds any topology view locks, and its state changes from holding a lock to not holding a lock. If the decremented private counter value is greater than 0, it indicates that the private counter value was greater than 1 before the decrement, meaning the process still holds other topology view locks after this request, and the process-level lock state has not changed. This check is an integer comparison operation, a local operation, and does not incur cross-process communication overhead.

[0075] In this embodiment, if the private counter is detected to be equal to 0 after decrementing, the current process executes a decrement operation on the shared counter. The shared counter is maintained globally by the database shared cluster, and its value represents the total number of processes holding topology view locks in the current cluster. If the private counter decreases from 1 to 0, it indicates that the process has switched from holding a lock to not holding a lock, and a decrement operation needs to be performed on the shared counter to ensure that the value of the shared counter is consistent with the total number of processes actually holding locks in the system. The decrement operation of the shared counter involves cross-process access to shared resources. Similar to the increment operation, it needs to rely on a synchronization mechanism to ensure atomicity. That is, in the shared memory scheme, it is implemented through hardware atomic instructions, and in the distributed coordination service scheme, it is guaranteed by a consensus protocol.

[0076] In this embodiment, when the private counter value is detected to be greater than 0 after decrement, the current process maintains the shared counter value unchanged. In this case, the current process held two or more layers of nested locks before this decrement, and still holds at least one layer of locks after this operation, so the process-level locking state has not changed. Since the process had previously included its own count in the shared counter (i.e., the increment operation of the shared counter was triggered when the private counter incremented from 0 to 1), releasing one layer of locks does not completely exit the locking state for the process, so the value of the shared counter does not need to change.

[0077] Based on the above steps, the global shared counter is updated only when the private counter decreases from 1 to 0, achieving symmetric reentrancy of lock release. Multiple lock releases by the same process only require updating the shared counter on the last release, avoiding lock state anomalies caused by incomplete or excessive lock release. Only when all processes holding locks have completed the decrement operation and the shared counter reaches zero is it confirmed that no process holds the lock, providing a clear completion condition for releasing the global lock. This avoids premature or delayed execution of change operations due to inaccurate lock release timing, ensuring the overall correctness and timing controllability of the topology change process.

[0078] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.

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

[0080] This embodiment also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 7 This is a schematic diagram of a computer program product 10 according to an embodiment of the present invention. Figure 8 This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention. Figure 9 This is a schematic diagram of a computer device 30 according to an embodiment of the present invention. Figure 7 As shown, the computer program product 10 includes a computer program 11, which, when executed by the processor 32, implements the steps of any of the above-described database shared cluster access control methods. Figure 8As shown, a computer-readable storage medium 20 stores the aforementioned computer program 11, which, when executed by the processor 32, implements the steps of the access control method for the database shared cluster of any of the above embodiments. Figure 9 As shown, 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.

[0081] The computer program 11 used to perform the operations of this invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, 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 execute entirely on the user's computer, partially on the user's computer, as a standalone 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 via any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer. In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing status information of the computer-readable program instructions.

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

[0083] For the purposes of this embodiment, computer-readable storage medium 20 is a tangible device capable of holding and storing a computer program 11. It can be any device capable of containing, storing, communicating, propagating, or transmitting the program 11 for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage medium 20 include: 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 optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, and any suitable combination thereof.

[0084] Computer device 30 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 30 can be a cloud computing node. Computer device 30 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. 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 reside on local or remote computing system storage media, including storage devices.

[0085] Computer device 30 may include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of said instructions during operation. The processor 32 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 31 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0086] Computer device 30 may also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows external devices that can be connected to the computer device to input and output data. The network adapter / interface provides communication between the computer device and a network, typically represented as a communication network.

[0087] Therefore, 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 conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. An access control method for a database shared cluster, characterized in that, include: In response to the detection of a database shared cluster topology change event, a global lock acquisition operation is performed on the current cluster topology view; The global lock is used to prevent concurrent changes to the cluster topology view; the topology change event is the addition, removal, or change of the running status of any member node in the database shared cluster. After successfully acquiring the global lock, a change preprocessing instruction is sent to the target process in the database shared cluster that needs to initiate remote resource access. The change preprocessing instruction is used to cause the target process to stop initiating new remote resource access requests; In response to the completion of all remote resource access requests initiated in the database shared cluster, the database shared cluster enters a request emptying state. In the request emptying state, member node update operations are performed according to the change type indicated by the topology change event, and the consistent hash ring is reconstructed based on the updated cluster topology view. The consistent hashing ring is used to determine the resource management node in the database shared cluster; Release the global lock and send a change completion indication; the change completion indication is used to enable the target process to initiate a new remote resource access request based on the reconstructed consistent hash ring.

2. The access control method for a database shared cluster according to claim 1, characterized in that, Performing a global lock acquisition operation on the current cluster topology view includes: Increment the private counter maintained by the current process. Detect whether the incremented private counter value is equal to 1, wherein the incremented private counter value being equal to 1 indicates that the current process did not hold any lock state on the current cluster topology view before this increment operation; If so, increment the shared counter that is globally maintained by the database shared cluster; If not, keep the count value of the shared counter unchanged.

3. The access control method for a database shared cluster according to claim 2, characterized in that, Before performing the increment operation on the private counter maintained by the currently running process, the following steps are also included: Detect whether the count value of the private counter has reached a preset upper limit threshold; If so, the increment operation is not performed, an error message is returned, and the global lock acquisition operation on the current cluster topology view is terminated; If not, perform the increment operation.

4. The access control method for a database shared cluster according to claim 1, characterized in that, Entering the request queuing state for the database shared cluster includes: Obtain the current count value of the shared counter maintained globally by the database shared cluster; the current count value of the shared counter is used to represent the total number of processes currently holding a lock state for the cluster topology view; Detect whether the current count value of the shared counter is equal to 0; If so, it is determined that all remote resource access requests have been completed, and the database shared cluster has entered a request emptying state.

5. The access control method for a database shared cluster according to claim 1, characterized in that, Performing member node update operations based on the change type indicated by the topology change event includes: While maintaining the global lock and without changing the current cluster topology view, member nodes can be added or deleted, or the running status information of member nodes can be updated, based on the topology change event.

6. The access control method for a database shared cluster according to claim 1, characterized in that, Reconstructing the consistent hash ring based on the updated cluster topology view includes: Retrieve the identity identifiers of all member nodes in the updated cluster topology view; Map the identity identifiers of each member node to the ring space of the consistent hash ring to generate the hash position of each member node in the ring space; Based on the hash position of each member node in the ring space, a mapping relationship between the member nodes and the ring space interval is constructed to form a reconstructed consistent hash ring.

7. The access control method for a database shared cluster according to claim 1, characterized in that, Releasing the global lock includes: Perform a decrement operation on the private counter maintained by the currently running process; Detect whether the count value of the decremented private counter is equal to 0, wherein the count value of the decremented private counter is equal to 0, which indicates that the current process no longer holds any lock state for the current cluster topology view after this decrement operation; If so, perform a decrement operation on the shared counter that is globally maintained by the database shared cluster; If not, keep the count value of the shared counter unchanged.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the access control method for the database shared cluster as described in any one of claims 1 to 7.

9. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the access control method for a database shared cluster as described in any one of claims 1 to 7.

10. A computer device, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the access control method for the database shared cluster according to any one of claims 1 to 7.

Images