Request processing method of a database node and related products

Abstract

This invention provides a request processing method and related products for database nodes. The method includes: acquiring a data page to be evicted and releasing the local cache lock corresponding to the data page; in response to the completion of the local cache lock release, removing the data page to be evicted from the mapping table used to record the index information of cached data pages; determining a control node for managing the local cache lock of the data page to be evicted; generating a request to delete the local cache lock, forwarding the request to a local message queue, and checking whether the data page to be evicted has not yet been loaded into the storage area based on the local message queue; obtaining an authorized deletion list from the control node according to the request, and deleting the local cache lock based on the authorized deletion list. The solution of this invention enhances the stability and reliability of the database system in high-concurrency scenarios by forwarding the request to delete the local cache consistency lock to the local message queue for asynchronous processing by a background thread.

Description

Technical Field

[0001] This invention relates to database technology, and in particular to a request processing method for database nodes and related products. Background Technology

[0002] In a shared-storage, multi-write database cluster, nodes concurrently read and write to the same data directory. The cluster uses a global cache consistency lock to coordinate access to the buffer by each node, while each node also maintains its own local cache consistency lock. If all buffer pool slots are occupied and the target page is not hit, the buffer manager must select the victim page for eviction to free up space for loading a new page. During the eviction process, the local cache consistency lock corresponding to the page must also be deleted. During this period, the buffer manager must synchronously wait for the management node to delete the authorized lock, and the SQL service process will be blocked, unable to respond to other requests, thus reducing cluster throughput and response performance. Summary of the Invention

[0003] One objective of this invention is to improve the throughput and response performance of shared storage multi-write database clusters in high-concurrency scenarios.

[0004] A further objective of this invention is to decouple the deletion of local cache consistency locks from the updating of global cache consistency locks while ensuring cluster cache consistency.

[0005] Specifically, the present invention provides a data processing method for a database cluster, comprising: Obtain the data page to be phased out, and release the local cache lock corresponding to the data page to be phased out; In response to the completion of the release of the local cache lock, the data page to be evicted is removed from the mapping table used to record the index information of cached data pages; In response to the fact that the data page to be phased out is not loaded into the storage area used for caching data pages, a control node for managing the local cache lock of the data page to be phased out is determined; A request to delete the local cache lock is generated, the request is forwarded to the local message queue, and the data page to be evicted is detected based on the local message queue to see if it has not yet been loaded into the storage area. If so, the request is sent to the control node, the authorized deletion list is obtained from the control node according to the request, and the local cache lock is deleted based on the authorized deletion list.

[0006] Optionally, the page for retrieving data to be phased out includes: Receive access requests for the target data page; In response to the absence of a free slot and the absence of the target data page in the storage area used for caching data pages, a data page is selected from the storage area used for caching data pages as the data page to be replaced according to a preset replacement strategy. The preset replacement strategy includes any one of the least frequently used strategy, the least recently used strategy, and the first-in-first-out strategy.

[0007] Optionally, releasing the local cache lock corresponding to the data page to be evicted includes: Obtain the lock identifier of the local cache lock corresponding to the data page to be phased out; The corresponding lock record is obtained from the local lock management structure based on the lock identifier; Delete the lock record from the local lock management structure.

[0008] Optionally, after removing the data page to be evicted from the mapping table used to record index information of cached data pages, the method further includes: In response to an access request for a target data page, obtain the page identifier of the target data page; A new index record is created in the mapping table used to record index information of cached data pages. The new index record points to the storage location of the target data page in the storage area used for caching data pages.

[0009] Optionally, determining the control node for managing the local cache lock of the data page to be evicted includes: Based on the total number of nodes in the database cluster and the page identifier of the data page to be phased out, the target node identifier is determined, and the node corresponding to the target node identifier is determined as the control node.

[0010] Optionally, the target node identifier is determined based on the total number of nodes in the database cluster and the page identifier of the data page to be evicted, including: Perform a hash operation on the page identifier of the data page to be phased out to obtain a hash value; The hash value is moduloed by the total number of nodes in the database cluster to obtain the modulo result. The node identifier corresponding to the modulo operation result is determined as the target node identifier.

[0011] Optionally, after determining the control node for managing the local cache lock of the data page to be evicted, the method further includes: Determine whether the request node and the control node are the same node, wherein the request node is the node that performs the operation of obtaining the data page to be phased out; If so, execute a request to generate and delete the local cache lock at the request node; If not, the request is sent to the communication process of the control node based on the communication process of the requesting node.

[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 data processing method for any of the above-described database 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 data processing method for any of the above-described database clusters.

[0014] According to another aspect of the present invention, a computer device is also provided, which 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 any database cluster data processing method.

[0015] The data processing method for database clusters in this invention decouples the deletion of local cache consistency locks from the update of global cache consistency locks. The SQL service process can return immediately after releasing the local lock and forwarding the request to the local message queue, without synchronously waiting for the management node to complete the global lock deletion operation. This eliminates the blocking waiting time of the SQL service process during page eviction, thereby improving the throughput and response performance of the shared storage multi-write database cluster in high-concurrency scenarios. After the request is forwarded to the local message queue, it checks whether the affected page has been reloaded. If the affected page is reloaded by another process during asynchronous processing, the eviction process is terminated, avoiding data inconsistency caused by the deletion of the local cache consistency lock while the global cache consistency lock has not been updated. By forwarding the request to delete the local cache consistency lock to the local message queue for asynchronous processing by a background thread, orderly queuing and smooth processing of eviction requests are achieved, avoiding the processing pressure caused by a large number of eviction operations simultaneously flooding the control node, thus enhancing the stability and reliability of the database system in high-concurrency scenarios.

[0016] 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

[0017] The following sections will describe some specific embodiments of the invention in a detailed manner 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 1This is a schematic flowchart of a data processing method for a database cluster according to an embodiment of the present invention; Figure 2 This is a schematic flowchart illustrating the process of obtaining a data page to be phased out in a database cluster data processing method according to an embodiment of the present invention; Figure 3 This is a schematic flowchart illustrating the release of a local cache lock in a database cluster data processing method according to an embodiment of the present invention; Figure 4 This is a schematic flowchart illustrating the creation of a new index record in a database cluster data processing method according to an embodiment of the present invention; Figure 5 This is a schematic flowchart illustrating the determination of a target node identifier in a database cluster data processing method according to an embodiment of the present invention; Figure 6 This is a schematic flowchart illustrating routing assurance in a database cluster data processing method 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

[0018] Multi-write database clusters are a high-availability database architecture developed from single-node databases. Multi-write database clusters allow multiple database nodes to concurrently read and write to the same data directory, and organize the database instances of each node through a cluster coordination mechanism to provide a unified database service to the outside world, thereby achieving horizontal scaling of system processing capacity and high availability of services.

[0019] To address this, multi-write database clusters employ cache fusion technology to ensure secure access to shared resources. Cache fusion effectively merges the buffer caches of all instances in the cluster into a logically unified, shared, large cache pool, ensuring that the entire cluster logically presents only a single buffer to the outside world. Cache fusion is implemented through a global cache consistency lock. Specifically, when a SQL service process requests to read or write the buffer, it first checks whether the local node holds a peer-to-peer or higher-level global cache consistency lock (i.e., checks the local cache consistency lock). If it does, it can directly operate on the buffer; otherwise, it needs to request a global cache consistency lock from the resource management node through the local node's communication process.

[0020] In a multi-write database cluster, when a database instance accesses a data page, it needs to acquire a buffer pool slot to place the requested page. When all buffer pool slots are occupied and none contain the requested page, the buffer manager must select a page from the buffer pool to evict it, freeing up space for the requested page. The selected evicted page is called the victim page. To ensure cache consistency, these page resources are protected by a global cache consistency lock, and each node also maintains its own local cache consistency lock. Therefore, when evicting a victim page, the corresponding local cache consistency lock must also be deleted.

[0021] However, existing technologies employ a synchronous approach for deleting local cache consistency locks when evicting victim pages. Specifically, after the buffer manager identifies a victim page, it must request authorization from the management node to delete the corresponding cache consistency lock. Subsequent page loading operations can only proceed after the local cache consistency lock corresponding to the victim page has been completely deleted. In other words, after the buffer manager identifies a victim page, it needs to wait in the buffer for the management node to authorize lock deletion. During this synchronous wait, the current SQL service process is blocked and cannot respond to other requests. Since lock deletion involves cross-node communication, the local node needs to interact with the resource management node to confirm lock release, further prolonging the synchronous wait time. In multi-node, high-concurrency access scenarios, frequent page eviction operations will lead to a large number of synchronous lock deletion waits, resulting in long wait times and severely impacting the overall throughput and response performance of the database cluster.

[0022] Figure 1 This is a schematic flowchart of a data processing method for a database cluster according to an embodiment of the present invention. Figure 1 As shown, the data processing method for this database cluster generally includes: Step S101: Obtain the data page to be phased out and release the local cache lock corresponding to the data page to be phased out; In step S102, in response to the completion of the release of the local cache lock, the data page to be evicted is removed from the mapping table used to record the index information of the cached data page; Step S103: In response to the fact that the data page to be phased out is not loaded into the storage area used for caching data pages, determine the control node for managing the local cache lock of the data page to be phased out; Step S104: Generate a request to delete the local cache lock, forward the request to the local message queue, and check whether the data page to be evicted has not yet been loaded into the storage area based on the local message queue; Step S105: If yes, send the request to the control node, obtain the authorized deletion list from the control node according to the request, and delete the local cache lock based on the authorized deletion list.

[0023] In this embodiment, after receiving an access request for the target data page, the requesting node first checks whether there are any free slots in the storage area. If there are no free slots and the storage area does not contain the target data page, the page eviction process is initiated. The requesting node selects a data page to be evicted from the storage area. After determining the data page to be evicted, the requesting node obtains the lock identifier of the local cache consistency lock (hereinafter referred to as the local cache lock) corresponding to the page, searches for the corresponding lock record in the local lock management structure based on the lock identifier, and deletes it, thus completing the synchronous release of the local cache lock.

[0024] It should be noted that the storage area refers to the memory storage space used for caching data pages. One specific implementation of this storage area is a buffer pool, which is a storage structure in a database system used to cache disk data pages in memory. A buffer pool contains multiple buffer pool slots, each capable of storing one data page. It should be understood that the storage area in this article is not limited to a buffer pool; it can also be other storage structures used for caching data pages, such as a shared cache or a page cache. Any storage structure used to temporarily store data pages for fast access can be considered as the storage area described in this embodiment. When the SQL service process accesses a data page, it first checks whether the target page has been cached in the storage area. If a cache match is found, it is read directly from the storage area; if not, the target page is loaded from disk into a free slot in the storage area.

[0025] It should be noted that the local cache lock is a copy of the global cache consistency lock (referred to as the global cache lock) on the current node (in this embodiment, the current node is the requesting node). It is used to record the lock authorization status of the data pages to be evicted on the current node, allowing the current node to determine whether it can directly access the page without querying the management node each time. Since this step only involves memory operations on the requesting node and does not involve cross-node communication or disk I / O, it executes quickly and has minimal impact on the SQL service process.

[0026] In this embodiment, after the local cache lock is released, the requesting node obtains the page identifier of the data page to be evicted, searches for the corresponding index record in the mapping table based on the page identifier, and deletes it. The mapping table records the correspondence between the page identifiers of all data pages currently loaded into the storage area and their storage locations. After the data page to be evicted is removed from the mapping table, the mapping table no longer contains the index information of the data page to be evicted. Subsequently, any access request for the data page to be evicted will not find a corresponding record in the mapping table, triggering a page reload process instead of directly using potentially outdated data content in the storage area.

[0027] It should be noted that the data content of the page to be phased out still remains in its corresponding storage location within the storage area; it has not been deleted or overwritten. However, this storage location no longer has a corresponding record in the mapping table, thus logically it is in a reusable state. When a new page is loaded into the storage area, this storage location will be reused, and the original data content will be overwritten.

[0028] It should be noted that a mapping table refers to a data structure used to record the index information of cached data pages. One specific implementation of it is a buffer table, but it can also be implemented using a hash table or a B+ tree.

[0029] In this embodiment, before executing the eviction process, the requesting node needs to confirm that the data page to be evicted has not yet been reloaded to the storage area. If it has been reloaded, it indicates that the data page to be evicted has been restored to a valid state, and continuing the eviction will lead to data errors, so the eviction should be terminated. After confirming that the data page to be evicted has not yet been loaded, the requesting node obtains the page identifier of the data page to be evicted; based on the total number of nodes in the database cluster and the page identifier of the data page to be evicted, it determines the target node identifier and identifies the node corresponding to the target node identifier as the control node. It should be noted that each data page is managed by one control node in the multi-write database cluster, and this control node is responsible for maintaining the global cache lock information of the data page.

[0030] In this embodiment, the requesting node generates a request to delete the local cache lock and forwards the request to the local message queue, which is managed asynchronously by a background thread. After retrieving the request from the local message queue, the background thread monitors whether the data page to be evicted has not yet been loaded into the storage area. If the data page to be evicted has been reloaded into the storage area by another process, the current evicting process is terminated; otherwise, subsequent steps are executed.

[0031] In this embodiment, the requesting node sends a request to the control node, which generates an authorized deletion list and returns it to the requesting node. The requesting node checks the authorized deletion list to determine if it is on the list. If it is, it deletes the local cache lock corresponding to the data page to be evicted; otherwise, it skips the deletion operation. After completion, it notifies the control node to update the global cache lock.

[0032] Based on the above steps, by decoupling the deletion of the local cache consistency lock from the update of the global cache consistency lock, the SQL service process can return immediately after releasing the local lock and forwarding the request to the local message queue, without synchronously waiting for the management node to complete the deletion of the global lock. This eliminates the blocking waiting time of the SQL service process during page eviction, thereby improving the throughput and response performance of the shared storage multi-write database cluster in high-concurrency scenarios. After the request is forwarded to the local message queue, the system checks whether the affected page has been reloaded. If the affected page is reloaded by another process during asynchronous processing, the eviction process is terminated, avoiding data inconsistency caused by the deletion of the local cache consistency lock but the failure to update the global cache consistency lock. By forwarding the request to delete the local cache consistency lock to the local message queue and processing it asynchronously by a background thread, the orderly queuing and smooth processing of eviction requests are achieved, avoiding the processing pressure caused by a large number of eviction operations flooding the control node simultaneously, thus enhancing the stability and reliability of the database system in high-concurrency scenarios.

[0033] Figure 2 This is a schematic flowchart illustrating the process of obtaining data pages to be phased out in a database cluster data processing method according to an embodiment of the present invention. Figure 2 As shown, the page for retrieving data to be phased out includes: Step S201: Receive an access request for the target data page; In step S202, in response to the absence of free slots and the absence of a target data page in the storage area used for caching data pages, a data page is selected from the storage area used for caching data pages as a data page to be replaced according to a preset replacement strategy. The preset replacement strategy includes any one of the least frequently used strategy, the least recently used strategy, and the first-in-first-out strategy.

[0034] In this embodiment, the requesting node receives the target data page access request submitted by the SQL execution engine through its database service process. The data structure of this access request includes at least the following fields: a page identifier (Page ID, used to uniquely identify a data page in the database), an access type (Read / Write, used to determine the lock level required for the access request), a transaction identifier (Transaction ID, used for transaction isolation control), and a timestamp (Timestamp, used for request ordering and timeout control). The page identifier is used to determine the target data page corresponding to the current access request, in order to locate or evict the corresponding cached page in the storage area.

[0035] The requesting node performs a lookup operation in the storage area based on the extracted page identifier. It calculates the corresponding hash value using a hash function based on the page identifier and locates the corresponding index record in the mapping table. If a match is found, the storage location of the page is returned directly; otherwise, the status of free slots in the storage area is further checked. The requesting node checks the free slot list in the storage area's management structure. If the free slot list is not empty, it means there are available slots. The target data page is read directly from the disk and loaded into a free slot, and an index record for the page is added to the mapping table, ending the process. If the free slot list is empty, it means the storage area is full. The node continues to check if the target data page is already in the storage area; if so, its storage location is returned directly; otherwise, the page eviction process is triggered.

[0036] In this embodiment, after the page replacement process is triggered, the requesting node selects a data page from the occupied slots of the storage area as the data page to be replaced according to a preset replacement strategy. The storage area maintains metadata information for each data page, including access frequency, last access time, and load time. The requesting node iterates through the metadata information of each occupied slot in the storage area according to the selected strategy and selects a page that meets the strategy conditions.

[0037] For example, the substitution strategy may take any of the following forms: The Least Frequently Used (LFU) strategy involves requesting nodes to iterate through the access counts of each data page in the storage region and select the page with the lowest access count as the data page to be evicted. If multiple pages have the same access count, the most recent access time is compared, and the page with the earliest most recent access time is selected as the data page to be evicted. To adapt to changes in access patterns, LFU can be used in conjunction with a decay mechanism, which periodically decays the access counts of all pages proportionally, reducing the access weight of older pages over time.

[0038] The Least Recently Used (LRU) strategy requires each node to maintain a linked list sorted by access time. Each time a page is accessed, it is moved to the head of the list, leaving the least recently accessed page at the tail. The page at the tail of the list is then selected as the page to be evicted.

[0039] The First In First Out (FIFO) strategy requires requesting nodes to maintain a queue sorted by loading time. Each time a page is loaded, it is added to the end of the queue, and the page at the head of the queue is selected as the data page to be evicted.

[0040] Based on the above steps, if the storage area is full and the target data page is not found, a replacement strategy is used to select and discard a data page to free up storage space for loading the target data page. This avoids page loading failures or service interruptions due to insufficient storage area capacity, ensuring the continuous availability of the database service. Selecting data pages to be discarded through a preset replacement strategy allows high-value data pages to be retained in the storage area, thereby improving the hit rate of the storage area.

[0041] Figure 3 This is a schematic flowchart illustrating the release of a local cache lock in a database cluster data processing method according to an embodiment of the present invention. Figure 3 As shown, releasing the local cache lock corresponding to the data page to be evicted includes: Step S301: Obtain the lock identifier of the local cache lock corresponding to the data page to be phased out; Step S302: Obtain the corresponding lock record from the local lock management structure based on the lock identifier; Step S303: Delete the lock record from the local lock management structure.

[0042] In this embodiment, after identifying the data page to be evicted, the requesting node obtains the lock identifier of the local cache lock corresponding to that page. The lock identifier is used to uniquely identify a lock record in the local lock management structure. One specific implementation is to directly use the page identifier of the data page to be evicted as the lock identifier. The requesting node extracts the page identifier from the metadata information of the data page to be evicted and uses it as the lock identifier to perform subsequent lock record location operations.

[0043] In this embodiment, the requesting node uses the lock identifier as the lookup key to perform a lookup operation in the local lock management structure. For example, a hash operation is performed on the page identifier to obtain a hash value. Based on this hash value, the corresponding hash slot in the local lock hash table is located. Each lock record node is traversed in this hash slot, and the page identifier in the lock record is compared with the target page identifier. If a match is found, the complete information of the lock record is obtained, including the lock mode and holding status. If the lookup fails, meaning that there is no lock record corresponding to the page in the local lock management structure, it indicates that the requesting node does not currently hold a local cache lock for that page. In this case, the release operation can be skipped or exception handling can be triggered.

[0044] In this embodiment, after successfully acquiring the lock record, the requesting node deletes the lock record from the local lock management structure. For example, the target lock record node is removed from the hash slot, releasing the memory space occupied by the lock record, and the metadata information of the local lock management structure (such as the total number of lock records) is updated. After deletion, the local lock management structure no longer contains lock records for the data page to be evicted, indicating that the requesting node's local cache lock on that page has been released. Subsequent lock status queries for that page will return a result indicating no lock is held. If the page is accessed again later, the requesting node needs to re-apply for lock authorization from the control node.

[0045] Based on the above steps, the requesting node uses the page identifier as the lock identifier and directly locates the corresponding lock record in the local lock management structure through a hash lookup, with a lookup time complexity of O(1). The entire release process only involves searching and deleting data structures in the requesting node's memory, without involving any cross-node network communication or disk I / O. Therefore, the local lock release has a microsecond-level response speed and has minimal impact on the SQL service process. In addition, the lock identifier directly reuses the page identifier, without the need for additional generation or conversion, further reducing the processing overhead on the lock release path.

[0046] Figure 4 This is a schematic flowchart illustrating the creation of a new index record in a database cluster data processing method according to an embodiment of the present invention. Figure 4 As shown, after removing the data page to be evicted from the mapping table used to record the index information of cached data pages, the process also includes: Step S401: In response to the access request for the target data page, obtain the page identifier of the target data page; Step S402: Create a new index record in the mapping table used to record the index information of cached data pages. The new index record points to the storage location of the target data page in the storage area used to cache data pages.

[0047] In this embodiment, after releasing the local cache lock and removing the mapping table of the data page to be evicted, the requesting node begins loading the target data page. The requesting node extracts the page identifier of the target data page from the received access request. This page identifier uniquely identifies the target data page in the database and is also the basis for finding the page's index record in the mapping table. If the access request does not directly carry the page identifier, the requesting node can obtain it through other methods, such as querying the database directory or parsing tablespace and page address information in the SQL statement.

[0048] The requesting node reads the target data page from the disk and loads it into the storage location of the data page to be evicted in the storage area. Then, it creates a new index record for the target data page in the mapping table, which points to the storage location of the target data page in the storage area.

[0049] It should be noted that the requesting node inserts a new index record into the mapping table using the page identifier of the target data page as the key and the storage location information of that page in the storage area as the value. After insertion, the target data page in the storage area is now accessible. Subsequent access requests for that target data page can be directly matched in the mapping table without needing to read from the disk again, thus improving data access efficiency.

[0050] Based on the above steps, by obtaining the page identifier of the target data page, the page to be loaded can be accurately located, avoiding loading errors. After the target data page is loaded, a new index record is created based on the mapping table, so that the newly loaded page can be immediately hit by subsequent access requests without repeatedly triggering disk I / O. This ensures efficient use of storage space while improving the query performance of the shared storage multi-write database cluster.

[0051] Figure 5 This is a schematic flowchart illustrating the process of determining the target node identifier in a database cluster data processing method according to an embodiment of the present invention. Figure 5 As shown, based on the total number of nodes in the database cluster and the page identifier of the data page to be evicted, the target node identifier is determined as follows: Step S501: Perform a hash operation on the page identifier of the data page to be evicted to obtain a hash value; Step S502: Perform a modulo operation on the hash value using the total number of nodes in the database cluster to obtain the modulo operation result; Step S503: Determine the node identifier corresponding to the modulo operation result as the target node identifier.

[0052] In this embodiment, the requesting node uses the page identifier of the data page to be evicted as an input parameter and calls a preset hash function to perform a hash operation to obtain the corresponding hash value. The hash function maps the variable-length integer value of the page identifier to a fixed-length hash value. This hash value is used in subsequent steps for modulo operations to determine the mapping relationship between the page and the node. The hash function can be implemented using various standard algorithms, such as MurmurHash3 or CRC32, and the specific choice can be determined according to the cluster size and performance requirements.

[0053] In this embodiment, the requesting node obtains the current total number of nodes in the shared storage cluster. Using this total number of nodes as a modulus, a modulo operation is performed on the resulting hash value. This involves calculating the remainder when the hash value is divided by the total number of nodes, yielding the modulo result. The modulo operation maps the hash value from a large integer space to a finite node number space, with values ​​ranging from 0 to (N-1), where N is the total number of nodes, and each integer value within this range corresponds to a cluster node. The modulo operation involves only integer division, making it fast. It should be noted that the total number of cluster nodes remains constant during the modulo operation to ensure consistency of the control node calculated for the same page identifier at different times.

[0054] In this embodiment, the requesting node uses the modulo operation result as the target node identifier. If the nodes in the cluster are numbered consecutively starting from 0, the modulo operation result is the node number; if the node numbers are not consecutive or use non-numeric identifiers, the requesting node performs an index mapping in the node identifier list based on the modulo operation result, and determines the node identifier corresponding to the modulo operation result as the target node identifier. Since each data page in the cluster has a unique mapping relationship with a control node, and this mapping relationship is uniquely determined by the modulo operation result obtained after hash calculation and modulo operation of the page identifier, the node identified by the modulo operation result is the control node of the data page to be evicted.

[0055] Figure 6 This is a schematic flowchart illustrating routing assurance in a database cluster data processing method according to an embodiment of the present invention. Figure 6 As shown, after determining the control node used to manage the local cache lock of the data pages to be evicted, it also includes: Step S601: Determine whether the request node and the control node are the same node. The request node is the node that performs the operation of obtaining the data page to be phased out. Step S602: If yes, execute a request to generate and delete the local cache lock on the requesting node; Step S603: If not, the communication process of the requesting node will send the request to the communication process of the control node.

[0056] In this embodiment, after determining the control node of the data page to be eliminated, the requesting node compares its own node identifier with the control node's node identifier to determine whether the requesting node and the control node are the same node. This determination operation is a simple numerical or string comparison and does not involve cross-node communication.

[0057] In this embodiment, if the determination result indicates that the request node and the control node are the same node (i.e., the request node itself is the control node of the page), then the request node does not need to perform cross-node communication and can directly execute the processing logic of generating a request to delete the local cache lock on its own node. The request node submits the request to the local authorization processing queue, and the local process generates an authorized deletion list and provides it directly to the request node. This local processing method avoids network communication overhead and is faster.

[0058] In this embodiment, if the determination result indicates that the requesting node and the control node are not the same node, i.e., the control node is a remote node, the requesting node needs to send the request to the control node for processing via cross-node communication. The requesting node encapsulates the request into a message format and sends it to the control node through its own communication process. The control node receives the message through its communication process and, based on the request, generates and returns the authorized deletion list.

[0059] Based on the above steps, the identity relationship between the request node and the control node is accurately identified by comparing their node identifiers, and then differentiated processing paths are executed according to the identification results. In the same-node scenario, the request node processes the request locally, avoiding cross-node network communication overhead and shortening response time; in the cross-node scenario, the request is sent to the remote control node through a communication process, realizing request transmission in a distributed environment. This ensures unified management of authorization decisions by the control node and guarantees the consistency of global cache lock information. At the same time, node identity determination and request routing logic are decoupled, facilitating dynamic expansion of the cluster size, and adapting to new nodes without modifying the core routing logic.

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

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

[0062] 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 7As 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 cluster data processing methods. Figure 8 As 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 data processing method for the database 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.

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

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

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

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

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

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

[0069] 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. A data processing method for a database cluster, characterized in that, include: Obtain the data page to be phased out, and release the local cache lock corresponding to the data page to be phased out; In response to the completion of the release of the local cache lock, the data page to be evicted is removed from the mapping table used to record the index information of cached data pages; In response to the fact that the data page to be phased out is not loaded into the storage area used for caching data pages, a control node for managing the local cache lock of the data page to be phased out is determined; A request to delete the local cache lock is generated, the request is forwarded to the local message queue, and the data page to be evicted is detected based on the local message queue to see if it has not yet been loaded into the storage area. If so, the request is sent to the control node, the authorized deletion list is obtained from the control node according to the request, and the local cache lock is deleted based on the authorized deletion list.

2. The data processing method for a database cluster according to claim 1, characterized in that, The page for retrieving data to be phased out includes: Receive access requests for the target data page; In response to the absence of a free slot and the absence of the target data page in the storage area used for caching data pages, a data page is selected from the storage area used for caching data pages as the data page to be replaced according to a preset replacement strategy. The preset replacement strategy includes any one of the least frequently used strategy, the least recently used strategy, and the first-in-first-out strategy.

3. The data processing method for a database cluster according to claim 1, characterized in that, Releasing the local cache lock corresponding to the data page to be evicted includes: Obtain the lock identifier of the local cache lock corresponding to the data page to be phased out; The corresponding lock record is obtained from the local lock management structure based on the lock identifier; Delete the lock record from the local lock management structure.

4. The data processing method for a database cluster according to claim 1, characterized in that, After removing the data page to be evicted from the mapping table used to record the index information of cached data pages, the process also includes: In response to an access request for a target data page, obtain the page identifier of the target data page; A new index record is created in the mapping table used to record index information of cached data pages. The new index record points to the storage location of the target data page in the storage area used for caching data pages.

5. The data processing method for a database cluster according to claim 1, characterized in that, The control node used to manage the local cache lock of the data pages to be evicted includes: Based on the total number of nodes in the database cluster and the page identifier of the data page to be phased out, the target node identifier is determined, and the node corresponding to the target node identifier is determined as the control node.

6. The data processing method for a database cluster according to claim 5, characterized in that, The target node identifier is determined based on the total number of nodes in the database cluster and the page identifier of the data page to be phased out, including: Perform a hash operation on the page identifier of the data page to be phased out to obtain a hash value; The hash value is moduloed by the total number of nodes in the database cluster to obtain the modulo result. The node identifier corresponding to the modulo operation result is determined as the target node identifier.

7. The data processing method for a database cluster according to claim 1, characterized in that, After determining the control node for managing the local cache lock of the data page to be evicted, the method further includes: Determine whether the request node and the control node are the same node, wherein the request node is the node that performs the operation of obtaining the data page to be phased out; If so, execute a request to generate and delete the local cache lock at the request node; If not, the request is sent to the communication process of the control node based on the communication process of the requesting node.

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 data processing method for the database cluster according to 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 data processing method for the database 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 data processing method for a database cluster as described in any one of claims 1 to 7.

Images