Database processing method, apparatus, device, storage medium, and program product

Abstract

Embodiments of the present application provide a database processing method, device, equipment, storage medium and program product, which are applied to a database cluster based on Kubernetes. The method comprises: dividing the database cluster to obtain a storage node cluster and a computing node cluster; the storage node cluster and the computing node cluster have corresponding sub-controllers respectively; using the sub-controller corresponding to the computing node cluster to collect first state information of the storage node cluster, and adjusting configuration information of the computing node cluster according to the first state information; using the sub-controller corresponding to the storage node cluster to collect second state information of the storage node cluster, and adjusting configuration information of the storage node cluster according to the second state information.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a database processing method, apparatus, device, storage medium, and program product. Background Technology

[0002] Currently, for databases with tightly coupled compute and storage, it is difficult to achieve flexible scaling of compute and storage nodes under a compute-storage separation architecture because they are not suitable for the characteristics of compute-storage separation architecture, resulting in low resource utilization. Summary of the Invention

[0003] This application provides a database processing method, apparatus, device, storage medium, and program product.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a database processing method applied to a Kubernetes-based database cluster, the method comprising:

[0006] The database cluster is divided into a storage node cluster and a compute node cluster; each of the storage node cluster and the compute node cluster has a corresponding sub-controller.

[0007] The sub-controller corresponding to the computing node cluster collects the first status information of the storage node cluster and adjusts the configuration information of the computing node cluster according to the first status information.

[0008] The sub-controller corresponding to the storage node cluster collects the second status information of the storage node cluster and adjusts the configuration information of the storage node cluster according to the second status information.

[0009] This application provides a database processing device applied to a Kubernetes-based database cluster, the device comprising:

[0010] A partitioning module is used to partition the database cluster into a storage node cluster and a compute node cluster; the storage node cluster and the compute node cluster each have corresponding sub-controllers;

[0011] The first adjustment module is used to collect the first status information of the storage node cluster using the sub-controller corresponding to the computing node cluster, and adjust the configuration information of the computing node cluster according to the first status information.

[0012] The second adjustment module is used to collect the second status information of the storage node cluster using the sub-controller corresponding to the storage node cluster, and adjust the configuration information of the storage node cluster according to the second status information.

[0013] This application provides a computer storage medium storing a computer program; when the computer program is executed, it can implement the database processing method provided by one or more of the aforementioned technical solutions.

[0014] This application provides a computer program product, including a computer program that, when executed by a processor, implements the database processing method provided by one or more of the aforementioned technical solutions.

[0015] The database processing method provided in this application divides the database cluster into a storage node cluster and a computing node cluster, and manages them independently using their respective sub-controllers. This enables resource decoupling and elastic scaling between the computing and storage layers. In practical applications, computing and storage resources can be scaled up or down according to business needs, improving resource utilization. It is applicable to diverse business scenarios and effectively solves the problems of traditional tightly coupled architectures being unable to achieve independent scaling up or down and having low resource utilization. Attached Figure Description

[0016] Figure 1 A schematic flowchart illustrating a database processing method provided in an embodiment of this application;

[0017] Figure 2 A schematic diagram of a Kubernetes-based database cluster structure is provided for an embodiment of this application;

[0018] Figure 3 A schematic diagram of another Kubernetes-based database cluster structure provided for an embodiment of this application;

[0019] Figure 4 This application provides a schematic diagram of a transaction processing flow between a host and a slave device, as illustrated in an embodiment of the present application.

[0020] Figure 5 A schematic flowchart illustrating a backup process provided in an embodiment of this application;

[0021] Figure 6 This is a schematic diagram of the structure of a database processing device provided in an embodiment of this application;

[0022] Figure 7 This is a schematic diagram of the structure of a database processing device provided in an embodiment of this application. Detailed Implementation

[0023] The technical solutions in this application will now be clearly and completely described with reference to the accompanying drawings.

[0024] The present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the embodiments provided herein are merely illustrative of the present application and are not intended to limit the present application. Furthermore, the embodiments provided below are some embodiments for implementing the present application, and not all embodiments for implementing the present application. Unless otherwise specified, the technical solutions described in the present application can be implemented in any combination.

[0025] It should be noted that, in this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or system that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or system. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other related elements (e.g., steps in the method or units in the system, such as a portion of a processor, a portion of a program, or software, etc.) in the method or system that includes that element.

[0026] For example, the database processing method provided in this application includes a series of steps, but the database processing method provided in this application is not limited to the steps described. Similarly, the database processing apparatus provided in this application includes a series of modules, but the database processing apparatus provided in this application is not limited to the modules explicitly described, and may also include modules that need to be set up for obtaining relevant information or processing based on information.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0028] The following are various embodiments.

[0029] Figure 1 This is a flowchart illustrating a database processing method provided in an embodiment of this application, as shown below. Figure 1 As shown, the process may include:

[0030] Step 100: Divide the database cluster into storage node clusters and compute node clusters.

[0031] In this embodiment of the application, the Kubernetes-based database cluster can be divided into two independent clusters: a storage engine cluster (SE cluster) and a compute engine cluster (CE cluster), also known as the storage layer and the compute layer. The storage engine cluster and the compute engine cluster each have corresponding sub-controllers, and correspondingly, different sub-controllers can be used to manage the storage engine cluster and the compute engine cluster respectively.

[0032] For example, a storage node cluster is typically responsible for persistent storage of data, replica management, disaster recovery backup, etc.; the cluster may include multiple storage nodes, which focus on data storage and access and do not handle computing tasks; the cluster has good scalability and can be horizontally scaled on demand to cope with the growth of data volume, making it suitable for massive data scenarios.

[0033] For example, a compute node cluster typically handles data processing and analysis tasks, such as querying and transaction processing. A compute node cluster may include a master compute node (host) and several slave compute nodes (one or more slave machines); the master compute node accesses the storage node cluster via a high-speed network; and it supports rapid elastic scaling, dynamically adding or removing compute nodes based on business load.

[0034] Step 101: Use the sub-controller corresponding to the compute node cluster to collect the first state information of the storage node cluster, and adjust the configuration information of the compute node cluster according to the first state information.

[0035] In this embodiment of the application, the compute node cluster (CE Cluster) has a corresponding sub-controller, which can be represented as CE Controller.

[0036] For example, resource control of a compute node cluster can be implemented through the CE Controller. Its function is similar to the resource control method of the original compute-storage tightly coupled database cluster. It does not rely on compute nodes to provide data services, and different compute nodes have a primary and backup relationship with each other. When a compute node fails, other compute nodes can automatically take over its tasks without the need for additional primary and backup switching components, thus ensuring the continuity of computing services.

[0037] In some embodiments, after collecting the first state information of the storage node cluster using the sub-controller corresponding to the computing node cluster, namely the CE Controller, the first state information can be compared with the preset state information, and the configuration information of the computing node cluster can be adjusted according to the comparison result.

[0038] For example, the CE Controller can actively interact with the storage node cluster to collect the current status information of the storage node cluster, i.e., the first status information. Here, the first status information may include status information related to computing tasks, such as node health and node load. The collected status information is compared with the preset status information to obtain the comparison result. Then, the configuration information of the computing node cluster is adjusted according to the comparison result.

[0039] Here, configuration information may include, but is not limited to, node scaling and routing policies. For example, if the comparison results indicate that the storage node cluster is overloaded, the CE Controller can be used to adjust the resource quota of the compute node cluster or trigger the compute node cluster to scale up to match the processing capacity of the storage layer. If the comparison results indicate that a node in the storage node cluster has failed, the CE Controller can be used to adjust the routing policy of compute tasks, rerouting compute tasks that originally needed to access the failed storage node to other healthy storage nodes, thus ensuring the continuity of data access.

[0040] Step 102: Use the sub-controller corresponding to the storage node cluster to collect the second status information of the storage node cluster, and adjust the configuration information of the storage node cluster according to the second status information.

[0041] In this embodiment of the application, the storage node cluster (SE Cluster) also has a corresponding sub-controller, which can be represented as SE Controller.

[0042] For example, resource control of a storage node cluster can be implemented through the SE Controller. The storage node cluster can include various resources such as Config Map, Secret, and service. Among them, Config Map is used for the configuration information of the storage cluster, such as data replication policy and storage path configuration; Secret is used for sensitive information of the storage cluster, such as access keys and authentication credentials; Service is used for the service routing configuration of the storage cluster to ensure that the compute nodes can correctly access the storage service.

[0043] In some embodiments, after collecting the second state information of the storage node cluster using the sub-controller corresponding to the storage node cluster, namely the SE Controller, the second state information can be compared with the preset state information, and the configuration information of the storage node cluster can be adjusted according to the comparison result.

[0044] For example, the SE Controller can collect the status information of the storage node cluster in real time, namely the second status information. Here, the second status information may include status information related to the operation of the storage node itself, such as node operating status, storage space occupancy rate, available capacity, etc., and compare the collected SE Cluster status with the preset status information to obtain the comparison result. Then, the configuration information of the storage node cluster is adjusted according to the comparison result.

[0045] Here, adjusting configuration information refers to performing configuration operations related to storage nodes; for example, it can perform node start / stop, status wait, or node upgrade. Among them, node start / stop means automatically starting a new node or shutting down a faulty node when the node status is abnormal or the cluster resources are insufficient; status wait means keeping the node in a waiting state in scenarios such as cluster initialization and upgrades until the running conditions are met; node upgrade means automatically triggering the node upgrade operation when the cluster needs to update the version, ensuring the version consistency of the cluster.

[0046] To facilitate understanding of the above process, the following will be combined with... Figure 2 Provided as an example, Figure 2 A schematic diagram of a Kubernetes-based database cluster structure is provided for an embodiment of this application, as shown below. Figure 2 As shown, the master and slave nodes correspond to the aforementioned computing node cluster, and the storage layer corresponds to the aforementioned storage node cluster. The master manages slave node status and generates transaction status logs through the master-slave transaction synchronization module. Slave node status management refers to real-time monitoring of the slave node's synchronization progress and health status to ensure the stability of the master-slave link. Transaction status log generation records key states such as transaction commits and rollbacks, providing complete evidence for slave node synchronization and ensuring that no transaction changes are missed. The master manages undo and redo logs through the master-slave shared data management module. Undo logs are used to recover data during transaction rollbacks, while redo logs are synchronized to the storage layer to ensure data persistence. Furthermore, during master failure recovery, redo operations ensure that committed transaction data is not lost. Additionally, this module can retrieve data pages from the storage layer to complete data interaction. The slave device constructs a view of the host's active transactions through the master-slave transaction synchronization module to accurately identify the commit status of transactions on the host, avoiding the synchronization of uncommitted dirty data. The slave's cache update module interacts with the host's master-slave shared data management module via log requests to obtain logs, perform log parsing and application, and simultaneously acquire data pages to complete data cache updates, ensuring data consistency between the slave and host. The storage layer provides multi-version data pages, data persistence, and load balancing capabilities to ensure reliable data storage and efficient data retrieval.

[0047] As can be seen from the embodiments of this application, by dividing and managing the storage node cluster and the computing node cluster separately, the storage and computing functions of the original Kubernetes-based database cluster can be decoupled, so that it meets the characteristics of a database under a computing and storage separation architecture. In this way, computing resources and storage resources can be expanded independently according to actual business needs, thereby solving the problem of resource waste caused by binding storage and computing in the traditional architecture.

[0048] In this embodiment, the primary computing node can first cache the generated redo logs in memory, and then cache them on the local disk. For example, when the primary computing node receives a transaction operation request, it executes the corresponding transaction operation and generates the corresponding redo logs based on the execution result. It should be noted that when the primary computing node generates redo logs, it can first cache the redo logs in memory, and then cache them on the local disk.

[0049] For example, redo logs are the core logs that ensure data persistence and fault recovery. When the master computing node receives a transaction operation request, it will execute the transaction operation corresponding to the transaction operation request and generate the corresponding redo log based on the execution result; that is, the host will generate the corresponding redo log for each transaction operation it completes.

[0050] It should be noted that when the primary compute node generates redo logs, the redo logs can be cached in memory first, and then cached on the local disk. In this way, the secondary compute nodes can directly obtain these logs from memory in real time and apply them to ensure data consistency between themselves and the primary compute node.

[0051] Understandably, if the slave device directly reads the local disk every time it retrieves logs, the high latency of disk input / output (IO) will directly increase the overall latency of master-slave synchronization, and may even cause slave data to lag. In this embodiment, by caching the redo logs generated by the master device each time in memory, when the master device receives a log retrieval request from the slave device, the master device can directly retrieve the redo logs from memory and return them to the slave device. This can significantly reduce the latency of the slave device retrieving logs and improve the efficiency of master-slave synchronization. At the same time, the master device's local disk retains the complete storage of the redo logs, and the memory cache is equivalent to temporary storage, which not only ensures the reliability of the logs, but also meets the low-latency synchronization requirements.

[0052] In this embodiment of the application, a storage engine is deployed on the storage nodes in the storage node cluster, and a computing engine is deployed on the computing nodes in the computing node cluster. The above method may further include: after the storage engine receives the redo logs issued by the computing engine, performing one or more of the following processes: log buffer management, log storage, log parsing, log application, log synchronization, data page reading, and metadata information synchronization.

[0053] For example, the main function of the storage engine is to store the redo logs issued by the computing engine and provide highly available, highly fault-tolerant, and highly reliable data access services. The storage engine can be divided into a log buffer management module, a log storage module, a log parsing module, a log application module, a log synchronization module, a data page reading module, and a metadata information synchronization module according to its functions. In turn, the data access services are realized through the collaboration of these functional modules.

[0054] In this embodiment, the concept of log as database is adopted. Correspondingly, after the computing engine sends the redo log to the storage engine and completes the persistence, the data can be considered to have been persisted. There is no need to wait for the data file to be written to disk, which improves the efficiency of data writing and ensures the reliability of data.

[0055] For example, the log buffer management module is used to manage the log buffer. The log buffer is a temporary area stored in memory used to cache redo logs issued by the computing engine. After the redo log is written to disk, a copy of the redo log is placed in the log buffer for parsing. When reading redo logs, the log parsing thread only needs to read from the hot log buffer in memory. The hot log buffer is contained within the log buffer and is essentially a dedicated area within the log buffer for storing copies of logs that have been persisted to disk and need to be parsed; that is, there is no need to directly access the log files on disk. Because memory read speed is much faster than disk read speed, reading logs directly from memory can significantly reduce disk I / O overhead and improve overall processing efficiency.

[0056] In this embodiment, a dual-buffer alternating reuse mechanism can be introduced for the log buffer to achieve parallel processing of log collection and parsing. The corresponding implementation idea is as follows: the log buffer is divided into two independent buffers (e.g., first buffer and second buffer) for separate management. One buffer is used for log collection, and the other for log parsing. The two buffers are used alternately to achieve parallel processing of log collection and parsing. For example, when the first buffer collects and parses the logs, the second buffer continues to collect logs. After the logs in the first buffer are parsed, the second buffer is used to parse the previously collected logs, and the first buffer collects logs again, repeating the above steps. In this way, log collection and parsing can be performed in parallel, improving data processing efficiency.

[0057] For example, the implementation process of writing logs to the hot log buffer can be as follows: When the log is received for the first time, the buf pointer points to the first buf, and the log is copied to the memory location pointed to by buf_free_block, which is the free starting position of the first buf. At the same time, three states are updated: record the offset of the log being written in the log file, modify last_log_file_offset to the offset of the log file being written, record the number of log bytes written n_bytes, update last_n_bytes to n_bytes, and move the memory location pointed to by buf_free_block backward by n_bytes to obtain the next writable memory location, that is, buf_free_block = buf_free_block + n_bytes. After the log writing is completed, the log parsing thread is woken up to parse the log. The parsing thread switches the hot log buffer to the second buffer and can continue to receive logs. The new logs received are written to the second buffer, and the parsing thread reads the logs in the first buffer for parsing. When the logs in the first buffer are parsed, the buffer switch is triggered again. The first buffer resumes log receiving, and the second buffer resumes log parsing.

[0058] For example, the log parsing module is used to retrieve logs from the log buffer (such as the hot log buffer), parse the logs, and after parsing, the parsing result can be put into the corresponding hash bucket in the hash table using a hash algorithm.

[0059] It should be noted that the parsing results of all logs on the same data page can be placed in the same hash bucket to prepare for subsequent log applications. When applying logs later (such as querying, statistics, alarms, etc.), the corresponding hash bucket can be directly located to quickly obtain all logs on the same data page without traversing the entire storage space, thus improving processing efficiency.

[0060] For example, the log linked list constructed by the storage layer is a hash table structure, which allows for quick location of logs using hash keys. In an optional embodiment, the tablespace ID (space_id) and page number (page_no) can be used as hash keys to place logs belonging to the same data page into the same hash bucket. For example, all redo logs with space_id=1 and page_no=10 can be placed into the same hash bucket.

[0061] For example, logs in the same hash bucket can be sorted in ascending order of Log Sequence Number (LSN). Here, LSN is a globally incrementing number of redo logs, representing the order in which the logs were generated. Sorting by LSN ensures that the order in which the logs are applied is completely consistent with the original order in which the data was modified, avoiding problems such as data rollback and overwrite errors.

[0062] It should be noted that after the hash table is built, there is no need to store information about LSNs. You only need to apply the logs to the corresponding data pages page by page. This is because LSNs are only used for sorting within the log linked list. When applying logs later, you only need to process them in the order of the linked list, without needing to query LSN information separately.

[0063] For example, the log application module can perform log application operations based on the parsing results of the log parsing module; correspondingly, the log application module can traverse each hash bucket in the hash table (each hash bucket corresponds to a log linked list of a data page); and apply the data modifications in the logs to the corresponding data pages in the order of the log linked lists corresponding to the hash buckets. Understandably, by introducing a combination of hash bucketing and linked list sorting, efficient classification and ordered application of logs can be achieved, improving the overall efficiency of data writing while ensuring data correctness.

[0064] For example, as described above, the log parsing module is a preparatory module for the log application module. The log parsing module improves log application efficiency through a well-designed log linked list. Specifically, it stores logs in hash buckets by data page and sorts them using LSN (Local Subsequent Number) to provide structured and ordered log data for the log application module. This avoids problems such as full scans and out-of-order processing during log application, thereby improving efficiency. The execution logic of the log application module is as follows: it directly reads the parsing results output by the log parsing module, traverses the hash buckets by page, and then applies the logs to the corresponding data pages sequentially according to the linked list order, completing the persistent data update.

[0065] It's important to note that the log application process is similar to the process of applying logs to the page during MySQL crash recovery. The log application module includes two different operating modes: MySQL crash recovery mode and normal operation mode. In MySQL crash recovery mode, the entire system is offline, and all work is done by the MySQL main thread, applying logs by calling the `recv_apply_hashed_log_recs()` function. In normal operation mode, the system is running normally, and log application can be handled in the background by a dedicated log application thread, while other modules function normally. Both modes share the same log application logic: a log processing method that uses page hash bucketing and LSN sorting, achieving code reuse and logical consistency. By differentiating between operating modes, both data recovery capabilities after system failures are ensured without affecting the system's online service capabilities.

[0066] In this embodiment of the application, the data reading module is used to respond to the read request of the computing engine and read the data page; correspondingly, it receives the read request sent by the computing engine, parses the key parameters (such as LSN) in the read request, locates the corresponding data page position according to the LSN specified in the read request, and returns the located data page content to the computing engine to meet its query and calculation needs.

[0067] For example, when a compute node cluster (compute layer) requests a data page from a storage node cluster (storage layer), it carries an identification information (0 or 1) to distinguish the source of the request (master compute node or slave compute node) and to determine how the storage layer constructs and returns the data page.

[0068] In one optional embodiment, if the identifier is 0, it indicates that the storage layer has received a data page retrieval request from a slave compute node. In this case, the user thread of the storage layer directly retrieves the corresponding data page from the memory buffer pool or disk, copies the data page to a temporary page, and then returns the temporary page directly to the slave compute node. The slave compute node itself stores logs of the data page that have not yet been applied and will use these logs to generate a new data page. If the identifier is 1, it indicates that the storage layer has received a data page retrieval request from a master compute node. In this case, the user thread of the storage layer first constructs a temporary page for the data page, then applies logs from all non-empty hash tables with sequence numbers between [first_pos, hash_pos] to the temporary page in sequence, and then returns the processed temporary page to the compute layer. first_pos represents the starting log sequence number (the earliest unapplied log), and hash_pos represents the current latest log sequence number (the latest persisted log).

[0069] Understandably, adopting a strategy of directly copying data pages for requests initiated by slave devices avoids the overhead of log application, improves the efficiency of slave data reading, and utilizes the slave's own stored logs to ensure data consistency, reducing the processing pressure on the storage layer. Requests initiated by the master device, on the other hand, use logs within a specified range to ensure that the master device obtains the latest data page after complete updates, guaranteeing the accuracy and consistency of master device data and providing a reliable data foundation for business processing in the computing layer.

[0070] In some embodiments, the database cluster includes a global controller, the compute node cluster includes multiple compute nodes, each compute node has a corresponding Pod, and the storage node cluster includes multiple storage nodes. The method may further include: obtaining third state information of the storage node cluster in real time through the global controller, determining whether all storage nodes in the storage node cluster are in a ready state based on the third state information; if it is determined that all storage nodes are in a ready state, then starting each Pod in the compute node cluster.

[0071] Here, the global controller can be the Operator component, and the third state information refers to the state information of all storage nodes in the storage node cluster. The Operator component can obtain the full state information of the storage node cluster in real time through the Application Programming Interface (API), that is, the third state information, which can include the node health, resource utilization and other state information of all storage nodes.

[0072] For example, after obtaining the third state information of the storage node cluster in real time through the Operator component, it can determine whether all storage nodes in the storage node cluster are in a ready state based on the third state information; for example, it can determine whether all storage nodes are normally available and whether data replicas have been synchronized. If all storage nodes are in a ready state, the Operator component will start each Pod in the compute node cluster; otherwise, if there are storage nodes in the storage node cluster that are not in a ready state, the Operator component will block the start of Pods in the compute node cluster to prevent the compute nodes from starting when the storage service is unavailable, thus preventing the task from failing.

[0073] As can be seen, in this embodiment, the compute node cluster and storage node cluster are managed by the CE Controller and SE Controller respectively, and the state linkage between the compute layer and the storage layer is realized by the Operator component. This not only retains the ease of use of traditional databases, but also has the flexibility and scalability of the storage-compute separation architecture.

[0074] In some embodiments, the storage node cluster and the compute node cluster have corresponding dedicated resources. The above method may further include: dividing the dedicated resources corresponding to the storage node cluster and the compute node cluster by tagging.

[0075] Here, dedicated resources are also called subordinate resources. In this embodiment of the application, subordinate resources corresponding to storage node clusters and compute node clusters can be divided by labeling. For example, the subordinate resources corresponding to compute node clusters can be labeled with cluster-type=ce, and the subordinate resources corresponding to storage node clusters can be labeled with cluster-type=se.

[0076] Understandably, by using tagging, it can be ensured that compute node clusters only obtain the compute resources corresponding to themselves, and storage node clusters will only load the storage resources corresponding to themselves, thus avoiding cross-contamination between compute and storage resources and ensuring the stable operation of the cluster.

[0077] For example, to facilitate understanding, the following is combined with Figure 3 Further illustrative examples of the database cluster architecture are provided; such as... Figure 3As shown, MaxScale is a database middleware, which acts as a proxy controller. It consists of a cluster of middleware 1 (MaxScale1), middleware 2 (MaxScale2), and middleware 3 (MaxScale3). This cluster is responsible for read / write separation and load balancing, and serves as the unified entry point for external access to the database cluster. The NCNDB cluster, or New Computing and Storage Separation Database Cluster, corresponds to the above database cluster and can be divided into CE clusters and SE clusters, corresponding to the compute node cluster and storage node cluster mentioned above. The CE cluster is managed by the CE sub-controller and contains one master compute node (CEInstance1(M)) and two slave compute nodes (CE Instance2(S) and CE Instance3(S)). The compute nodes act as primary and backup nodes for each other, providing data services without relying on the compute nodes. The SE cluster is managed by an SE sub-controller, comprising three storage nodes: SE Instance1, SE Instance2, and SE Instance3. The SE sub-controller is responsible for dynamic control of storage resources, allowing for node start-up, shutdown, and upgrades. The Backup Controller connects to storage volumes for data backup, while the Restore Controller interfaces with Object Storage Service (OBS) for data recovery. The Prometheus cluster handles monitoring and alerting, and the OpenSearch cluster manages logs.

[0078] In some embodiments, the compute node cluster includes a master compute node and slave compute nodes. The method further includes: when the master compute node performs a write transaction operation, writing the corresponding generated redo log to both the storage node cluster and the local temporary cache; when the master compute node receives a log retrieval request sent by the slave compute node, retrieving the redo log from the temporary cache and returning it to the slave compute node, so that the slave compute node applies the redo log to the corresponding data page.

[0079] For example, see Figure 4When the host performs a write transaction, the corresponding generated redo log (corresponding to the redo log in the diagram) is simultaneously written to both the storage node cluster (SE Cluster) and the local temporary cache (corresponding to the redo cache in the diagram). Here, writing to the storage node cluster is for persistent storage to ensure that the log is not lost, while writing to the local temporary cache is to reduce the latency of the slave machine retrieving the log.

[0080] For example, redo logs written to a local temporary cache remain in the cache for a period of time, waiting to be retrieved by the slave node. The slave node periodically and proactively calls the `log_write_up_to` interface to the master node through its log retrieval thread, sending a log retrieval request to request the latest redo logs. When the master compute node receives a log retrieval request from the slave compute node, it retrieves the latest redo logs from the temporary cache and returns them to the slave compute node. This allows the slave compute node to apply the redo logs to the corresponding data pages, completing data synchronization and ensuring that the slave data is consistent with the master data.

[0081] For example, see Figure 4 After receiving the redo log, the slave device first applies the redo log to the data pages in the memory buffer pool (corresponding to the buffer pool in the diagram) to restore the transaction execution state of the master device. If the data page is not in the buffer pool, the slave device will obtain the corresponding data page (corresponding to the page in the diagram) from the SE Cluster, apply the redo log to the data page, and finally put the updated data page into the buffer pool to ensure that the data version is consistent with the master device.

[0082] It's important to note that, to reduce read latency for slave devices, the master can simultaneously generate and send redo logs to all slave devices. This allows slaves to obtain the redo logs in advance and pre-apply them to data pages, reducing read latency. Simultaneously, the master needs to modify its undo management approach. This involves the master performing a purge operation on the undo logs, periodically clearing undo logs for completed transactions to free up storage space. Slave devices do not perform undo log purges; they retain all undo logs to monitor the master's transaction execution status and ensure transaction isolation.

[0083] For example, Figure 4 This application provides a schematic diagram of a transaction processing flow between a master and a slave device, as illustrated in the embodiments of this application. Figure 4As shown, during the transaction initiation phase, the host allocates a transaction with transaction ID x and writes this transaction ID to the redo log for replaying operations during fault recovery. During transaction execution, when modification operations such as INSERT / UPDATE / DELETE are performed on data pages, the logs corresponding to these modification operations are first written to the redo log, and the data pages in the memory buffer pool are updated simultaneously. When the transaction completes and enters the commit phase, the redo log is written to the commit log. The slave only handles query operations. When a query transaction starts, the slave replicates the list of active transaction IDs of the master node (i.e., the set of transaction IDs currently running but not committed on the host), constructs a read view, and reads the corresponding version of the data page from the memory buffer pool (corresponding to the buffer pool in the diagram) based on the constructed read view. If the data page is not in the buffer pool, the old version of the data page is loaded from the storage node cluster (SE Cluster). After reading, the transaction is committed. The entire process does not modify the data; it only returns the query results.

[0084] Considering the data storage structure under a compute-storage separation architecture, where metadata and data ontology are stored in compute node clusters and storage node clusters respectively, backup and recovery scenarios require special consideration. A full backup is achieved by integrating the data and performing a full backup, while simultaneously capturing the redo log information and corresponding LSNs at that point in time. Subsequent incremental backups can be completed by updating the redo logs and corresponding LSNs in real time. Real-time copying of database files does not guarantee data consistency; subsequent recovery steps ensure data consistency by relying on the redo logs maintained by InnoDB. The redo logs contain records of every change made to InnoDB data. When InnoDB starts, it checks the data files and transaction logs, performing two steps: applying committed transaction log entries to the data files and undoing any transactions that modified the data but were not committed. The LSNs recorded at startup ensure the time consumed by subsequent data file copying; therefore, if files are being modified, they will reflect the database's state at different points in time. Each InnoDB page (typically 16kb in size) contains an LSN, and each page's LSN shows its most recent modification time.

[0085] The compute-storage separation architecture ensures that storage node clusters and compute node clusters are managed separately based on SE and CE characteristics. It also leverages the diverse storage capabilities supported by Kubernetes, keeping the recovery process independent of both the storage and compute node clusters. This enables hot backups of data during database operation and allows for data preparation at any point in time using redo logs and LSNs, independent of the database cluster. The prepared data can then be used for database recovery at any point. The following provides an illustrative example of the data backup and recovery process.

[0086] In some embodiments, the above method further includes: when the main computing node detects the start of the backup thread, simultaneously starting a background detection process; continuously monitoring and copying all data change records within the backup period through the background detection process; the backup period refers to the time period from the start to the end of the backup thread.

[0087] For example, the backup thread can be started by a periodic scheduled task; here, the periodic scheduled task acts as a backup scheduler and can automatically trigger backup operations at preset time intervals (such as hourly, daily, etc.); when the scheduled task is triggered, the corresponding backup thread will be started to perform the corresponding backup operation.

[0088] For example, when the primary compute node detects the start of the backup thread, it simultaneously starts a background detection process. This background detection process continuously monitors and copies all data change records throughout the entire backup cycle, from the start to the end of the backup thread. These data change records originate from the redo logs that are written cyclically. Since the redo logs are reused cyclically, the background detection process must run continuously to ensure that incremental change data within the backup cycle is not lost due to log overwriting.

[0089] In some embodiments, the above method may further include: obtaining a static data snapshot when the backup thread starts by means of a locking mechanism; integrating the static data snapshot and all data change records to obtain a backup file; and performing data recovery based on the backup file.

[0090] For example, when the primary compute node detects the start of the backup thread, it can first obtain a static data snapshot at the time the backup thread starts through a locking mechanism; that is, first complete the full copy of the data files; during this process, a lock can be acquired using a lock command similar to FLUSH TABLES WITH READ LOCK in MySQL to obtain a static data snapshot; here, the purpose of locking is to put the database into a read-only state to prevent data from being modified during the backup, and at the same time flush all tables to disk to ensure that the data pages and logs of all committed transactions are persisted to disk to prevent data loss; the lock is held throughout the entire data copying process until the backup is completed.

[0091] In this embodiment of the application, after obtaining the static data snapshot when the backup thread starts and all data change records during the entire backup cycle, the two can be integrated to obtain a complete backup file, which can then be used for data recovery.

[0092] For example, after the backup is completed, the data preparation phase begins. The master compute node uses the replicated transaction log (redo log) to perform crash recovery operations on the backup file, rolling the InnoDB table data forward to the time when the backup was completed (which is consistent with the time when the lock command was executed). This ensures that all InnoDB table data is in a synchronized state, rather than being rolled back to the old state at the beginning of the backup, providing a reliable foundation for subsequent recovery.

[0093] The roll-forward operation advances the data from the state at the start of the backup to the state at the completion of the backup. By replaying committed transactions in the transaction log, the data reaches an eventual consistent state, ensuring that the restored data completely matches the business state at the time of backup completion.

[0094] For example, the data recovery process primarily replicates the data obtained during the data preparation phase. Correspondingly, the recovery process reads parameters from the configuration file (my.cnf), such as the data directory, InnoDB data directory, and log storage directory, and checks their existence. Then, it sequentially copies the InnoDB tables, indexes, and log files, preserving the original file attributes during the copying process. The backup framework reverts file ownership back to the original user beforehand to ensure the database can start normally. Leveraging the compute-storage separation feature, the backup Pod distributes the prepared data and log files to the storage node cluster (SE Cluster) as the foundation for the data storage layer; it distributes metadata files to each node in the compute node cluster (CE Cluster) to ensure the compute layer can correctly access the data. At this point, the entire data recovery process is complete, and the data on each node in both the SE Cluster and CE Cluster has been restored to normal. After the file distribution is complete, the Operator starts each Pod according to the startup order of the SE Cluster and CE Cluster, completing the recovery of the entire database cluster.

[0095] For example, Figure 5 A schematic flowchart of a backup process provided in an embodiment of this application is shown below. Figure 5As shown, after the backup scheduled task is triggered, the fork process starts, creating an independent backup process to avoid consuming resources of the main business process and ensure that online business is not affected. The backup process starts three copy threads in parallel: the ibd copy thread, responsible for copying the InnoDB table data files (.ibd) and buffer pool files; the frm copy thread, responsible for copying the table structure definition files (.frm) and recording the table's metadata information; and the redo copy thread, responsible for copying the redo log from the latest checkpoint position for subsequent data roll-forward recovery. After the ibd and frm files are copied, the backup process executes the FLUSHTABLES WITH READ LOCK (FTWRL) command to put the database into a read-only state. In the read-only state, other files are backed up to prevent data from being modified and causing inconsistencies. After receiving the notification, the redo copy thread stops working and exits, completing the redo log backup. The backup process then executes the UNLOCK TABLES command to release the read-only locks and restore the database's read and write capabilities. The backup process waits for all backup child processes to finish before exiting, and the entire backup process ends.

[0096] As can be seen, during the backup process, using multi-threaded parallel copying of different file types can shorten backup time and improve backup efficiency. Introducing the FTWRL command ensures that data is not modified when backing up static files, avoiding data inconsistencies. Copying redo logs from the latest checkpoint, combined with subsequent roll-forward recovery, can restore the backup data to the precise point in time when the backup was completed, further ensuring data consistency. Throughout the entire backup process, the database only briefly enters a read-only state in the final stage, remaining read-write available for the majority of the time, thus minimizing the impact on online business while achieving backup.

[0097] Figure 6 This is a schematic diagram of the structure of a database processing device provided in an embodiment of this application, as shown below. Figure 6 As shown, the database processing device 60 may include: a partitioning module 600, a first adjustment module 601, and a second adjustment module 602, wherein:

[0098] The partitioning module 600 is used to partition the database cluster to obtain a storage node cluster and a compute node cluster; the storage node cluster and the compute node cluster each have a corresponding sub-controller;

[0099] The first adjustment module 601 is used to collect the first status information of the storage node cluster using the sub-controller corresponding to the computing node cluster, and adjust the configuration information of the computing node cluster according to the first status information.

[0100] The second adjustment module 602 is used to collect the second status information of the storage node cluster using the sub-controller corresponding to the storage node cluster, and adjust the configuration information of the storage node cluster according to the second status information.

[0101] In some embodiments, the database cluster includes a global controller, the compute node cluster includes multiple compute nodes, each compute node has a corresponding Pod, the storage node cluster includes multiple storage nodes, and the apparatus further includes a determining module, the determining module being configured to:

[0102] The global controller obtains the third state information of the storage node cluster in real time, and determines whether all storage nodes in the storage node cluster are in a ready state based on the third state information.

[0103] If it is determined that all storage nodes are in a ready state, then start each Pod in the compute node cluster.

[0104] In some embodiments, the computing node cluster includes a master computing node and slave computing nodes, and the apparatus further includes a first processing module, the first processing module being configured to:

[0105] When the main computing node performs a write transaction operation, the corresponding generated redo log is simultaneously written to the storage node cluster and the local temporary cache.

[0106] When the master computing node receives a log retrieval request from the slave computing node, it retrieves redo logs from the temporary cache and returns them to the slave computing node, so that the slave computing node applies the redo logs to the corresponding data page.

[0107] In some embodiments, the storage node cluster includes storage nodes, each storage node having a storage engine deployed thereon, and the master compute node having a compute engine deployed thereon. The apparatus further includes a second processing module, the second processing module being configured to:

[0108] After receiving the redo logs from the computing engine, the storage engine performs one or more of the following processes: log buffer management, log storage, log parsing, log application, log synchronization, data page reading, and metadata information synchronization.

[0109] In some embodiments, the computing node cluster includes a master computing node, and the apparatus further includes a backup module, the backup module being configured to:

[0110] When the main computing node detects the start of the backup thread, a background detection process is started simultaneously.

[0111] The background detection process continuously monitors and copies all data change records within the backup cycle; the backup cycle refers to the time period from the start to the end of the backup thread.

[0112] In some embodiments, the backup module is further configured to:

[0113] A static data snapshot is obtained when the backup thread starts by using a locking mechanism;

[0114] The static data snapshot and all data change records are integrated to obtain a backup file;

[0115] Data recovery is performed based on the backup file.

[0116] In practical applications, the aforementioned partitioning module 600, first adjustment module 601, second adjustment module 602, determination module, first processing module, second processing module, and backup module can all be implemented by a processor located in the database processing device. This processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), controller, microcontroller, and microprocessor.

[0117] Furthermore, in this embodiment, the functional modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0118] If the integrated unit is implemented as a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0119] Specifically, the computer program instructions corresponding to a database processing method in this embodiment can be stored on storage media such as optical discs, hard disks, and USB flash drives. When the computer program instructions corresponding to a database processing method in the storage media are read or executed by a database processing device, any one of the database processing methods in the aforementioned embodiments is implemented.

[0120] Based on the same technical concept as the foregoing embodiments, see Figure 7 This illustration shows a database processing device 700 provided in an embodiment of this application, which may include: a memory 701 and a processor 702; wherein,

[0121] Memory 701 is used to store computer programs and data;

[0122] The processor 702 is configured to execute a computer program stored in the memory to implement any of the database processing methods described in the foregoing embodiments.

[0123] In practical applications, the memory 701 mentioned above can be volatile memory, such as RAM; or non-volatile memory, such as ROM, flash memory, hard disk drive (HDD) or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the processor 702.

[0124] The processor 702 described above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor. It is understood that for different database processing devices, the electronic device used to implement the above processor function can also be other types, and this application embodiment does not specifically limit the specific types.

[0125] In some embodiments, this application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the database processing methods described in the foregoing embodiments.

[0126] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0127] The descriptions of the various embodiments above tend to emphasize the differences between them. Similarities or commonalities can be referred to interchangeably, and for the sake of brevity, they will not be repeated here. The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict. The features disclosed in the various product embodiments provided in this application can be arbitrarily combined to obtain new product embodiments without conflict. The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined to obtain new method or device embodiments without conflict.

[0128] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage) containing computer-usable program code.

[0129] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1A device that provides the functions specified in one or more boxes.

[0130] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0131] The above are merely preferred embodiments of this application and are not intended to limit the scope of protection of this application.

Claims

1. A database processing method, characterized in that, The method, applied to Kubernetes-based database clusters, includes: The database cluster is divided into a storage node cluster and a compute node cluster; each of the storage node cluster and the compute node cluster has a corresponding sub-controller. The sub-controller corresponding to the computing node cluster collects the first status information of the storage node cluster and adjusts the configuration information of the computing node cluster according to the first status information. The sub-controller corresponding to the storage node cluster collects the second status information of the storage node cluster and adjusts the configuration information of the storage node cluster according to the second status information.

2. The method according to claim 1, characterized in that, The database cluster includes a global controller, the compute node cluster includes multiple compute nodes, each compute node has a corresponding Pod, the storage node cluster includes multiple storage nodes, and the method further includes: The global controller obtains the third state information of the storage node cluster in real time, and determines whether all storage nodes in the storage node cluster are in a ready state based on the third state information. If it is determined that all storage nodes are in a ready state, then start each Pod in the compute node cluster.

3. The method according to claim 1, characterized in that, The computing node cluster includes master computing nodes and slave computing nodes, and the method further includes: When the main computing node performs a write transaction operation, the corresponding generated redo log is simultaneously written to the storage node cluster and the local temporary cache. When the master computing node receives a log retrieval request from the slave computing node, it retrieves redo logs from the temporary cache and returns them to the slave computing node, so that the slave computing node applies the redo logs to the corresponding data page.

4. The method according to claim 3, characterized in that, The storage node cluster includes storage nodes, each storage node is equipped with a storage engine, and the master compute node is equipped with a compute engine. The method further includes: After receiving the redo logs from the computing engine, the storage engine performs one or more of the following processes: log buffer management, log storage, log parsing, log application, log synchronization, data page reading, and metadata information synchronization.

5. The method according to claim 1, characterized in that, The computing node cluster includes a master computing node, and the method further includes: When the main computing node detects the start of the backup thread, a background detection process is started simultaneously. The background detection process continuously monitors and copies all data change records within the backup cycle; the backup cycle refers to the time period from the start to the end of the backup thread.

6. The method according to claim 5, characterized in that, The method further includes: A static data snapshot is obtained when the backup thread starts by using a locking mechanism; The static data snapshot and all data change records are integrated to obtain a backup file; Data recovery is performed based on the backup file.

7. The method according to claim 1, characterized in that, The storage node cluster and the compute node cluster have corresponding dedicated resources, and the method further includes: The dedicated resources corresponding to the storage node cluster and the computing node cluster are divided by tagging.

8. A database processing apparatus, characterized in that, The device, applicable to Kubernetes-based database clusters, includes: A partitioning module is used to partition the database cluster into a storage node cluster and a compute node cluster; the storage node cluster and the compute node cluster each have a corresponding sub-controller; The first adjustment module is used to collect the first status information of the storage node cluster using the sub-controller corresponding to the computing node cluster, and adjust the configuration information of the computing node cluster according to the first status information. The second adjustment module is used to collect the second status information of the storage node cluster using the sub-controller corresponding to the storage node cluster, and adjust the configuration information of the storage node cluster according to the second status information.

9. A database processing device, characterized in that, The database processing device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method according to any one of claims 1 to 7.

10. A computer storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the method described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images