Database data backup method and device, equipment and storage medium

Abstract

The invention provides a database data backup method and device, equipment and a storage medium. The method can be applied to the cloud computing field. The method comprises the following steps: in response to a received data backup request, dynamically selecting a target node of each fragment cluster according to a performance index of a backup node in each fragment cluster in a server cluster; under the condition that it is determined that the target node in each fragment cluster completes basic data backup for the main node, creating a data consistency point which is used for marking the moment when data of each node in the server cluster reaches a consistent state; synchronously distributing the data consistency point to each fragment cluster, so that each fragment cluster records a transaction log from the backup end moment of the target node to the data consistency point; and carrying out persistent storage on the basic data and the transaction log.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing, and more specifically, to a method, apparatus, device, and storage medium for backing up database data. Background Art

[0002] In a distributed database system, a service cluster consists of multiple shard clusters, and each shard cluster contains a primary node and a standby node internally. To ensure data security, backup operations are usually performed by the primary node. When a failure occurs, the system can quickly restore data based on the backup of the primary node, thereby ensuring the stable operation of the system and maintaining data integrity.

[0003] In the process of implementing the inventive concept, it is found that there are at least the following problems in the related art. During the data backup process, due to the inconsistent backup speeds of each shard cluster, there may be differences in the data between shard clusters. And relying solely on the primary node for backup will not only reduce the overall backup efficiency but also affect the accuracy and reliability of the backup data. Summary of the Invention

[0004] In view of this, the present invention provides a method, apparatus, device, medium, and program product for backing up database data.

[0005] One aspect of the present invention provides a method for backing up database data, including: in response to a received data backup request, dynamically selecting a target node for each of the above shard clusters according to the performance metrics of the standby nodes in each shard cluster of the server cluster; creating a data consistency point when it is determined that the target nodes in each of the above shard clusters have completed the basic data backup of the primary node, where the data consistency point is used to mark the moment when the data of each node in the server cluster reaches a consistent state; synchronously distributing the data consistency point to each of the above shard clusters so that each of the above shard clusters records the transaction logs between the backup end time of the target node and the data consistency point; and persistently storing the basic data and the transaction logs.

[0006] According to an embodiment of the present invention, the performance metrics include sub-metric data in multiple dimensions; the dynamically selecting a target node for each of the above shard clusters according to the performance metrics of the standby nodes in each shard cluster of the server cluster includes: for each of the above shard clusters, based on the sub-metric data of each of the above standby nodes, respectively generating a sorting result corresponding to each dimension through a multi-dimensional sorting algorithm, where the sub-metric data includes read / write speed, processor utilization rate, and data playback speed of the standby node; performing weighted fusion on the sorting results of each standby node in each dimension according to a preset weight to generate a comprehensive performance score; and selecting a target node from the multiple above standby nodes of the shard cluster according to the comprehensive performance score.

[0007] According to an embodiment of the present invention, the above method further includes: determining the node status of each of the above standby nodes based on the performance metrics of the standby nodes in each of the above shard clusters; for each of the above shard clusters, when it is determined that the node status of each of the above standby nodes is in an unavailable state, determining the primary node in the above shard cluster as the above target node.

[0008] According to an embodiment of the present invention, the above creation of the data consistency point includes: randomly selecting a coordinating node from multiple nodes whose node status is in a running state according to the node status of each node in the above server cluster, and the above coordinating node is a primary node or a standby node; sending a creation request for the above data consistency point to the above coordinating node, so that after receiving the above creation request, the above coordinating node generates a globally unique identifier including a time stamp according to the current system time.

[0009] According to an embodiment of the present invention, the above method further includes: when it is determined that the above coordinating node has received the above creation request, sending a blocking signal to the primary nodes in each of the above shard clusters, and the above blocking signal is used to block the submission of subsequent transactions; when each of the above shard clusters receives the above blocking signal, stopping receiving the submission requests of the above subsequent transactions; and completing the pending transactions that have started execution in the above shard clusters; when it is determined that the pending transactions of multiple above shard clusters have all been executed, generating the above data consistency point through the above coordinating node.

[0010] According to an embodiment of the present invention, the above method further includes: storing the log information generated by the primary nodes in each of the above shard clusters during transaction processing in a log archiving server, and the above log information includes the detailed information of the transaction operations performed by the primary nodes at each moment.

[0011] According to an embodiment of the present invention, the above method further includes: in response to a received data recovery request, verifying the recovery time in the above data recovery request to obtain a verification result; when it is determined that the above verification result indicates that the recovery time is less than or equal to the above backup end time, recovering the above basic data; when it is determined that the above verification result indicates that the recovery time is greater than the above backup end time, for each of the above shard clusters, searching in the archived logs of the above primary node for the data consistency point that is closest to the above recovery time and common to multiple above shard clusters; when it is determined that the found data consistency point is consistent with the above recovery time, recovering the above basic data; and replaying the above transaction logs to obtain recovery data; when it is determined that the found data consistency point is inconsistent with the above recovery time, recovering the above basic data; and retrieving the log information between the above recovery time and the found data consistency point from the above log archiving server; replaying the above transaction logs and the retrieved log information to obtain recovery data.

[0012] Another aspect of the present invention provides a database data backup device, comprising: a node selection module, configured to dynamically select a target node for each of the above-mentioned shard clusters according to the performance metrics of the standby nodes in each shard cluster of the server cluster in response to a received data backup request; a data point creation module, configured to create a data consistency point when it is determined that the target nodes in each of the above-mentioned shard clusters have completed the basic data backup of the master node, where the data consistency point is used to mark the moment when the data of each node in the server cluster reaches a consistent state; a data point distribution module, configured to synchronously distribute the above-mentioned data consistency point to each of the above-mentioned shard clusters, so that each of the above-mentioned shard clusters records the transaction logs between the backup end time of the target node and the data consistency point; a data storage module, configured to persistently store the above-mentioned basic data and the above-mentioned transaction logs.

[0013] Another aspect of the present invention provides an electronic device, comprising: one or more processors; a memory, configured to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the method as described above.

[0014] Another aspect of the present invention provides a computer-readable storage medium, storing computer-executable instructions, which are used to implement the method as described above when executed.

[0015] Another aspect of the present invention provides a computer program product, which includes computer-executable instructions, and the instructions are used to implement the method as described above when executed.

[0016] According to the embodiments of the present invention, by dynamically selecting the standby node with the optimal performance in each shard cluster for backup, the target node is accurately located, thereby significantly improving the backup efficiency and minimizing the impact on the business. After the basic data backup is completed, a data consistency point is created to mark the state where the data of each node in the shard cluster is consistent, ensuring the integrity and consistency of the backup data. Subsequently, the data consistency point is synchronously distributed to each shard cluster, and the transaction logs between the backup end time and the data consistency point are recorded, providing an accurate and reliable guarantee for data recovery. Finally, the basic data and the transaction logs are persistently stored, optimizing the backup performance while ensuring data security and realizing the efficient utilization of cluster resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Through the following description of the embodiments of the present invention with reference to the accompanying drawings, the above and other objects, features and advantages of the present invention will become clearer.

[0018] Figure 1An exemplary system architecture to which the database data backup method and apparatus of the present invention can be applied is shown.

[0019] Figure 2 A flowchart of the database data backup method according to an embodiment of the present invention is shown.

[0020] Figure 3 A schematic diagram of basic data backup in the database data backup method according to an embodiment of the present invention is shown.

[0021] Figure 4 A schematic diagram of log information storage in the database data backup method according to an embodiment of the present invention is shown.

[0022] Figure 5 A flowchart of data recovery according to an embodiment of the present invention is shown.

[0023] Figure 6 A block diagram of the database data backup apparatus according to an embodiment of the present invention is shown.

[0024] Figure 7 A block diagram of an electronic device suitable for implementing the database data backup method according to an embodiment of the present invention is shown. Detailed implementation manners

[0025] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. In the following detailed description, for the sake of explanation, many specific details are set forth in order to provide a thorough understanding of the embodiments of the present invention. However, it is obvious that one or more embodiments can be implemented without these specific details. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessarily obscuring the concepts of the present invention.

[0026] The terms used herein are merely for describing specific embodiments and are not intended to limit the present invention. The terms "including", "comprising" and the like used herein indicate the presence of the described features, steps, operations and / or components, but do not exclude the presence or addition of one or more other features, steps, operations or components.

[0027] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0028] In the case of using expressions such as "at least one of A, B, and C", generally, it should be interpreted according to the meaning that those skilled in the art usually understand this expression (for example, "a system having at least one of A, B, and C" should include, but not be limited to, a system having only A, only B, only C, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.).

[0029] In the embodiments of the present invention, in aspects such as the collection, update, analysis, processing, use, transmission, provision, disclosure, storage, etc. of the involved data (for example, including but not limited to user personal information), they all comply with the provisions of relevant laws and regulations, are used for legal purposes, and do not violate public order and good customs. In particular, necessary measures are taken for user personal information to prevent illegal access to user personal information data and to safeguard user personal information security and network security.

[0030] In the embodiments of the present invention, before obtaining or collecting user personal information, the authorization or consent of the user is obtained.

[0031] Embodiments of the present invention provide a method, apparatus, device, and storage medium for database data backup. It can be applied to the field of cloud computing. The method includes: in response to a received data backup request, dynamically selecting a target node for each shard cluster according to the performance metrics of the standby nodes in each shard cluster within the server cluster; creating a data consistency point when it is determined that the target nodes in each shard cluster have completed the basic data backup of the master node, where the data consistency point is used to mark the moment when the data of each node in the server cluster reaches a consistent state; synchronously distributing the data consistency point to each shard cluster so that each shard cluster records the transaction logs between the backup end moment of the target node and the data consistency point; and persistently storing the basic data and the transaction logs.

[0032] Figure 1 An exemplary system architecture to which the database data backup method and apparatus of the present invention can be applied is shown. It should be noted that Figure 1 What is shown is only an example of the system architecture to which the embodiments of the present invention can be applied to help those skilled in the art understand the technical content of the present invention, but it does not mean that the embodiments of the present invention cannot be used in other devices, systems, environments, or scenarios.

[0033] Such as Figure 1As shown, the system architecture 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is used to provide a medium for communication links between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired and / or wireless communication links, etc.

[0034] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications may be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, and / or social platform software, etc. (only for example).

[0035] The first terminal device 101, the second terminal device 102, and the third terminal device 103 may be various electronic devices with a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop portable computers, and desktop computers, etc.

[0036] The server 105 may be a server that provides various services, such as a background management server that supports the websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (only for example). The background management server may analyze and process data such as received user requests, etc., and feedback the processing results (such as web pages, information, or data, etc. obtained or generated according to user requests) to the terminal device.

[0037] It should be noted that the database data backup method provided by the embodiments of the present invention can generally be executed by the server 105. Correspondingly, the database data backup device provided by the embodiments of the present invention can generally be set in the server 105. The database data backup method provided by the embodiments of the present invention can also be executed by a server or a server cluster different from the server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or the server 105. Correspondingly, the database data backup device provided by the embodiments of the present invention can also be set in a server or a server cluster different from the server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or the server 105. Or, the database data backup method provided by the embodiments of the present invention can also be executed by the first terminal device 101, the second terminal device 102, or the third terminal device 103, or can also be executed by other terminal devices different from the first terminal device 101, the second terminal device 102, or the third terminal device 103. Correspondingly, the database data backup device provided by the embodiments of the present invention can also be set in the first terminal device 101, the second terminal device 102, or the third terminal device 103, or set in other terminal devices different from the first terminal device 101, the second terminal device 102, or the third terminal device 103.

[0038] It should be understood that Figure 1 the numbers of the terminal devices, networks, and servers in

[0039] Figure 2 shows a flowchart of the database data backup method according to an embodiment of the present invention.

[0040] As Figure 2 shown, the method includes operations S210 to S240.

[0041] In operation S210, in response to the received data backup request, target nodes of each shard cluster are dynamically selected according to the performance metrics of the standby nodes in each shard cluster of the server cluster.

[0042] In operation S220, when it is determined that the target nodes in each shard cluster have completed the basic data backup of the master node, a data consistency point is created, and the data consistency point is used to mark the moment when the data of each node in the server cluster reaches a consistent state.

[0043] In operation S230, the data consistency point is synchronously distributed to each shard cluster so that each shard cluster records the transaction logs between the backup end moment of the target node and the data consistency point.

[0044] In operation S240, the basic data and transaction logs are persistently stored.

[0045] According to an embodiment of the present invention, in a distributed database, a service cluster usually consists of multiple shard clusters. To ensure data reliability, each shard cluster contains multiple replicas, divided into a primary node and a standby node. The primary node is responsible for performing write operations, while the standby node serves as a replica of the primary node. When the primary node fails, the standby node will take over its responsibilities and continue to provide services. In addition, to further ensure data security, physical backups of the data in the entire database are required, and usually the primary node is selected for backup. However, to relieve the pressure on the primary node, the standby node can be considered for backup to improve resource utilization.

[0046] When the standby node is the backup target, since the data synchronization speed of the standby nodes in each shard cluster varies, the backup process needs to ensure the consistency of the data in each shard cluster. During the backup process using the standby node, first, a data backup request sent by the user is received. Then, the performance metrics of all standby nodes in each shard cluster in the server cluster are obtained. These metrics may include read / write speed, processor utilization, data playback speed, etc. Based on these performance metrics, a target node is selected for each shard cluster, that is, the node with the best performance among multiple standby nodes. For example, the target node may be a node with a faster read / write speed or a lower processor occupancy rate to ensure the efficiency and stability of the backup process.

[0047] Based on the target nodes selected for each shard cluster, parallel basic backups of each shard cluster are triggered to back up the basic data generated by the primary node during transaction processing. Specifically, the backup command is sent to the backup module in each target node. After receiving the backup request, the backup module will start the backup process to back up the data and log information of the database. After the backup task is completed, the user will be notified that the backup is finished. Through the parallel backup mechanism, each shard cluster can independently complete the backup task, reducing the waiting time during the backup process and significantly improving the backup speed.

[0048] After confirming that the target nodes in each shard cluster have completed the backup of the primary node's basic data, a data consistency point is created. The data consistency point is used to mark the moment when the data of each node in the server cluster reaches a consistent state, usually represented by a globally unique identifier with a timestamp. Creating a data consistency point can ensure that the data of each node within each shard cluster is fully synchronized at a specific point in time, providing a reliable benchmark for subsequent data recovery or consistency verification.

[0049] When each shard cluster has completed all transactions to be committed, the data consistency point is created and synchronously distributed to each shard cluster. Since all transactions have been processed, this ensures that the transaction states of all nodes are consistent. Subsequently, the data consistency point is recorded in the archival logs of all nodes in each shard cluster. After the basic data backup is completed, the basic data and the transaction logs between the backup end time and the data consistency point recorded in each shard cluster are persistently stored in the storage unit, and thus the backup process is completed.

[0050] As Figure 3 shown, the architecture for implementing data backup includes three key modules: a standby selection module 310, a backup execution module 320, and a consistency point module 330. These modules work together to ensure the reliability and consistency of data in a distributed environment.

[0051] The task of the standby selection module 310 is to select appropriate nodes from shard cluster 1 and shard cluster 2 for backup operations. In a distributed database system, data is divided into multiple shard clusters, and each shard cluster consists of a primary node 311 and multiple standby nodes 312. The standby selection module 310 will select the most suitable nodes from these nodes to perform backup operations according to the current system state and backup requirements.

[0052] The backup execution module 320 is responsible for the actual backup operations. It works in coordination with the nodes selected by the standby selection module 310 to perform backup processing on the data on the selected nodes. As Figure 3 can be seen, the backup execution module 320 is connected to shard cluster 1 and shard cluster 2, and each shard cluster includes a primary node and standby nodes. The backup execution module 320 will perform backup operations on these primary nodes and standby nodes to ensure the integrity and consistency of the data are maintained. At the same time, the backup module 321 is responsible for securely transmitting the backup data to the storage location to prevent data loss.

[0053] The role of the consistency point module 330 is to ensure that the data in shard cluster 1 and shard cluster 2 reaches a consistent state during the backup process. In a distributed system, data is distributed across multiple nodes, and maintaining data consistency is a challenge. The consistency point module 330 solves this problem by creating data consistency points, which mark specific moments when the database state is consistent. During the backup process, the consistency point module 330 ensures that the data of all shard clusters is fully synchronized at a specific point in time, providing a reliable benchmark for data recovery.

[0054] Through the close cooperation of three key modules, namely the standby machine selection module 310, the backup execution module 320, and the consistency point module 330, the distributed database system ensures data security and consistency. This architecture not only improves the reliability of data backup but also greatly enhances the system's ability to recover from failures, making data management more robust and efficient.

[0055] According to an embodiment of the present invention, by dynamically selecting the standby nodes with the best performance in each shard cluster for backup, the target nodes are accurately located, thereby significantly improving the backup efficiency and minimizing the impact on the business. After the basic data backup is completed, a data consistency point is created to mark the state where the data of each node in the shard cluster is consistent, ensuring the integrity and consistency of the backup data. Subsequently, the data consistency point is synchronously distributed to each shard cluster, and the transaction logs from the end of the backup to the data consistency point are recorded, providing an accurate and reliable guarantee for data recovery. Finally, the basic data and transaction logs are persistently stored, optimizing the backup performance while ensuring data security and achieving efficient utilization of cluster resources.

[0056] According to an embodiment of the present invention, the performance metrics include sub-metric data in multiple dimensions; based on the performance metrics of the standby nodes in each shard cluster within the server cluster, the target nodes of each shard cluster are dynamically selected, including: for each shard cluster, based on the sub-metric data of each standby node, through a multi-dimensional sorting algorithm, sorting results corresponding to each dimension are respectively generated, and the sub-metric data includes read / write speed, processor utilization rate, and data playback speed of the standby node; according to the preset weights, the sorting results of each standby node in each dimension are weighted and fused to generate a comprehensive performance score; according to the comprehensive performance score, the target node is selected from multiple standby nodes in the shard cluster.

[0057] According to an embodiment of the present invention, for each shard cluster, first, the sub-metric data of each standby node is obtained, including read / write speed, processor utilization rate, and data playback speed of the standby node. These metrics are key factors for evaluating the performance of standby nodes. For example, assume there are three standby nodes in a shard cluster, namely standby node A, standby node B, and standby node C. The data obtained through monitoring tools is as follows: the read / write speed of standby node A is 100MB / s, the processor utilization rate is 30%, and the data playback speed is 50MB / s; the read / write speed of standby node B is 80MB / s, the processor utilization rate is 40%, and the data playback speed is 60MB / s; the read / write speed of standby node C is 90MB / s, the processor utilization rate is 25%, and the data playback speed is 45MB / s.

[0058] Based on these sub - metric data, through a multi - dimensional sorting algorithm, sorting results corresponding to each dimension are generated respectively. Specifically, first, the read - write speed is sorted. The higher the read - write speed, the higher the ranking. In the above example, the sorting result is: standby node A (100MB / s) > standby node C (90MB / s) > standby node B (80MB / s). Then, the processor utilization rate is sorted. The lower the processor utilization rate, the more idle the node is and the higher the ranking. Therefore, the sorting result is: standby node C (25%) > standby node A (30%) > standby node B (40%). Finally, the data playback speed is sorted. The higher the data playback speed, the higher the ranking. The sorting result is: standby node B (60MB / s) > standby node A (50MB / s) > standby node C (45MB / s).

[0059] According to the preset weights, the sorting results of each standby node in each dimension are weighted and fused to generate a comprehensive performance score. Assume that the preset weights are: the weight of read - write speed is 0.4, the weight of processor utilization rate is 0.3, and the weight of data playback speed is 0.3. Taking standby node A as an example, its comprehensive performance score is: (1×0.4)+(2×0.3)+(2×0.3)=1.6. Similarly, calculate the comprehensive performance scores of standby node B and standby node C, which are: (3×0.4)+(3×0.3)+(1×0.3)=2.4, and (2×0.4)+(1×0.3)+(3×0.3)=2.0 respectively.

[0060] Finally, according to the comprehensive performance score, a target node is selected from multiple standby nodes in the shard cluster. In the above example, the comprehensive performance score of standby node A is the lowest (1.6), so it is selected as the target node. In this way, it can be ensured that the selected target node performs optimally in multiple key performance indicators, thus providing the best performance support for subsequent backup and recovery operations.

[0061] According to an embodiment of the present invention, the database data backup method further includes: determining the node status of each standby node based on the performance indicators of the standby nodes in each shard cluster; for each shard cluster, in the case where it is determined that the node statuses of all standby nodes are in an unavailable state, determining the primary node in the shard cluster as the target node.

[0062] According to an embodiment of the present invention, before selecting a target node, it is first necessary to determine the node status of each standby node based on the performance metrics of the standby nodes in each shard cluster. Specifically, through a monitoring tool or a health check mechanism, real-time detection is performed on performance metrics such as the read / write speed, processor utilization rate, and data playback speed of each standby node. If the performance metrics of a certain standby node cannot be obtained or its response times out, it can be determined that the standby node is in an unavailable state. For example, assume that there are three standby nodes in a shard cluster, namely standby node A, standby node B, and standby node C. During the detection process, it is found that the read / write speed of standby node A is 100MB / s, the processor utilization rate is 30%, and the data playback speed is 50MB / s; the read / write speed of standby node B is 80MB / s, the processor utilization rate is 40%, and the data playback speed is 60MB / s; while standby node C cannot respond to the detection request, so it is determined that standby node C is in an unavailable state.

[0063] For each shard cluster, after determining the node status of all standby nodes, if it is found that all standby nodes are in an unavailable state, that is, they cannot be accessed or their performance metrics cannot be obtained, then the primary node in the shard cluster is determined as the target node. The primary node usually has higher performance and stability, and can be a reliable choice for backup operations when all standby nodes are unavailable. For example, in the above shard cluster, if standby node A and standby node B are also inaccessible due to network failures or other reasons, then the system will automatically determine the primary node as the target node to ensure that the backup operation can proceed smoothly. In this way, when the standby nodes are unavailable, it is possible to quickly switch to the primary node, avoiding the interruption of the backup operation due to node unavailability, thereby improving the availability and reliability of the entire distributed database.

[0064] According to an embodiment of the present invention, creating a data consistency point includes: randomly selecting a coordinator node from multiple nodes whose node status is in a running state according to the node status of each node in the server cluster, where the coordinator node is a primary node or a standby node; sending a creation request for the data consistency point to the coordinator node, so that after receiving the creation request, the coordinator node generates a globally unique identifier including a timestamp according to the current system time.

[0065] According to an embodiment of the present invention, in a distributed database environment, the creation of a data consistency point is a crucial step in ensuring data synchronization and backup. First, it is necessary to randomly select a coordinating node from multiple nodes in the running state according to the node status of each node in the server cluster. The coordinating node can be the primary node or the standby node. For example, in a distributed database system containing multiple shard clusters, each shard cluster has several primary nodes and standby nodes. Suppose there are a primary node M1, standby nodes S1, S2, and S3 in the current cluster, where S3 is unavailable due to a fault, and M1, S1, and S2 are all in the running state. At this time, the system will randomly select a node from M1, S1, and S2 as the coordinating node. Suppose the randomly selected result is the standby node S1.

[0066] After determining the coordinating node, a creation request for the data consistency point is sent to this coordinating node. After receiving the creation request, the coordinating node will generate a globally unique identifier (BarrierID) containing a timestamp based on the current system time. This globally unique identifier is used to identify the consistency point of the current transaction and contains the current time information to ensure its uniqueness and traceability. For example, suppose the current system time is 14:30:00 on May 15, 2025. After receiving the creation request, the coordinating node S1 may generate a Barrier ID such as Barrier-20250515143000-12345678, where 20250515143000 represents the generation time, and 12345678 is a randomly generated unique serial number.

[0067] The creation of the data consistency point not only ensures the synchronization state of the data on each node within the shard cluster at a specific time point but also provides a clear benchmark for subsequent data recovery and consistency verification through the globally unique identifier. This mechanism can effectively guarantee the integrity and consistency of data in a complex distributed environment. At the same time, by randomly selecting the coordinating node, it avoids over-reliance on a single node and improves the reliability and availability of the system.

[0068] According to an embodiment of the present invention, the database data backup method further includes: in the case where it is determined that the coordinating node has received the creation request, sending a blocking signal to the primary nodes in each shard cluster, where the blocking signal is used to block the submission of subsequent transactions; in the case where each shard cluster has received the blocking signal, stopping receiving the submission requests of subsequent transactions; and completing the to-be-submitted transactions that have started execution in the shard cluster; in the case where it is determined that the to-be-submitted transactions of multiple shard clusters have all been executed, generating a data consistency point through the coordinating node.

[0069] According to an embodiment of the present invention, after determining that the coordination node receives a data consistency point creation request, a blocking signal is sent to the primary nodes in each shard cluster. The role of this blocking signal is to temporarily stop the submission of subsequent transactions to ensure that the transaction status within the shard cluster remains stable during the creation of the data consistency point. For example, assume that after the coordination node S1 receives the creation request, it sends a blocking signal to the primary node M1 of shard cluster 1, the primary node M2 of shard cluster 2, and the primary node M3 of shard cluster 3. After receiving the blocking signal, these primary nodes will immediately stop receiving new transaction submission requests.

[0070] After each shard cluster receives the blocking signal, the primary node will stop receiving subsequent transaction submission requests, but will continue to complete the pending transactions that have already started execution. This process is to ensure that all ongoing transactions can be successfully completed during the blocked state, avoiding data inconsistency caused by the mid-stop of transactions. For example, in shard cluster 1, the primary node M1 may be processing 3 pending transactions. After receiving the blocking signal, M1 will stop receiving new transaction submission requests, but will continue to complete these 3 transactions that have already started. Similarly, the primary nodes of shard cluster 2 and shard cluster 3 will also complete the pending transactions that have already started in their respective shard clusters.

[0071] After confirming that the pending transactions in multiple shard clusters have all been executed and completed, the coordination node will generate a data consistency point. At this time, since all pending transactions have been completed, the transaction status within the shard cluster has reached consistency. The coordination node generates a globally unique identifier containing a timestamp based on the current system time as the identifier of the data consistency point. This globally unique identifier not only identifies the data consistency point but also records the creation time, providing a reliable benchmark for subsequent data recovery and consistency verification.

[0072] Through this series of steps, the creation process of the data consistency point can ensure that in a distributed database system, the transaction status of all nodes is completely consistent at a specific point in time. This mechanism effectively avoids data inconsistency problems caused by the uncertainty of transaction submission and improves the reliability and data integrity of the distributed database system.

[0073] According to an embodiment of the present invention, the database data backup method further includes: storing the log information generated by the primary nodes in each shard cluster during transaction processing to a log archiving server, where the log information includes the detailed information of the transaction operations performed by the primary nodes at each moment.

[0074] According to an embodiment of the present invention, in a distributed database system, the backup module of the standby node receives a data backup request from a user. When the user requests a Point-In-Time-Recovery (PITR), the backup module triggers the log archiving operation of the distributed database. The core of this operation is to continuously archive the log information generated by the master node during transaction processing to the log archiving server to support subsequent point-in-time recovery requirements.

[0075] Specifically, the log archiving operation involves the master nodes in each shard cluster. These master nodes generate a large amount of log information during transaction processing, which records the detailed content of the transaction operations performed by the master nodes at various times. For example, the log information may include the start time, end time, involved data tables, operation types (such as insert, update, or delete), and the execution results of the transactions. These log information are the basis for point-in-time recovery backup because they can help the system restore to the state at a specific time point when needed.

[0076] To ensure the integrity and availability of the log information, the master nodes continuously send this log information to the log archiving server. The log archiving server is a server dedicated to storing and managing log information, and it has high availability and high-capacity storage capabilities. After the log information is stored on the log archiving server, it can be used for subsequent backup operations, data recovery, and consistency verification tasks. For example, when a user needs to restore the data state to a specific time point, the system can reconstruct the data state at that time point through the log information on the log archiving server, thus realizing the function of point-in-time recovery backup.

[0077] In this way, the distributed database system can effectively support point-in-time recovery backup, ensuring that when data loss or incorrect operations occur, users can quickly restore the data state to any specified time point. This mechanism not only improves the reliability of the system but also enhances the flexibility and security of data management.

[0078] As Figure 4 shown, in the data backup architecture, in addition to the standby machine selection module, the backup execution module, and the consistency point module, a log archiving server 410 is also introduced to support the operation of point-in-time recovery (PITR). The log archiving server 410 stores the log information archived from the master node, and this information is crucial for restoring the data to a specific time point.

[0079] After the backup execution module completes the data backup, it will transfer the backup data to the log archiving server 410. These backup data include all data states before the data consistency point created by the consistency point module. When the user requests a point-in-time recovery, these backup data and the log information in the log archiving server 410 will be used to restore the data to the time point specified by the user.

[0080] To implement point-in-time recovery, first determine the recovery time requested by the user, and then find the data consistency point closest to that time point. Once found, obtain the log records before that time point from the log archiving server 410 and replay them based on the backup data until the recovery time requested by the user is reached. This process ensures that the data can be accurately restored to the specified time point, meeting the user's requirements for data recovery accuracy.

[0081] Through this data backup architecture, the distributed database system can not only perform regular data backups but also support precise point-in-time recovery operations. This greatly enhances the system's data recovery ability, enabling users to quickly restore to any historical state in the event of data loss or corruption, thus ensuring business continuity and data integrity.

[0082] Figure 5 Shows a flowchart of data recovery according to an embodiment of the present invention.

[0083] As Figure 5 shown, the process includes operations S501 to S508.

[0084] In operation S501, in response to the received data recovery request, verify the recovery time in the data recovery request to obtain a verification result.

[0085] In operation S502, determine whether the recovery time is greater than the backup end time.

[0086] In operation S503, restore the basic data.

[0087] In operation S504, find the data consistency point closest to the recovery time and common to multiple shard clusters from the archived logs of the master nodes in each shard cluster.

[0088] In operation S505, determine whether the found data consistency point is consistent with the recovery time.

[0089] In operation S506, restore the basic data and replay the transaction logs.

[0090] In operation S507, retrieve the log information between the recovery time and the found data consistency point from the log archiving server.

[0091] In operation S508, the basic data is restored, and the transaction log and the retrieved log information are replayed.

[0092] According to an embodiment of the present invention, when a data recovery request is received, the recovery time in the request is first verified. If the recovery time is less than or equal to the backup end time, then the basic data is directly restored. For example, assume that the backup end time is 14:00:00 on May 15, 2025, and the user requests to restore the data state at 13:00:00 on May 15, 2025. In this case, the recovery time is earlier than the backup end time, so the basic data can be directly read from the backup storage unit and restored to the corresponding nodes of each shard cluster. This recovery method is suitable for the situation where the user needs to restore to a state before the backup time point, and the operation is simple and efficient.

[0093] After restoring the basic data, the data consistency of each shard cluster is verified to ensure that the data states of all nodes are consistent. Since the recovery time is within the valid range of the backup data and no additional log replay operation is required, the recovery process is completed quickly. This method is particularly suitable for the situation where the user needs to quickly restore to a state before the backup time point and has low requirements for the accuracy of the recovery time.

[0094] According to an embodiment of the present invention, if the recovery time is greater than the backup end time, then point-in-time recovery (PITR) needs to be performed. First, for each shard cluster, find the data consistency point closest to the recovery time and common to multiple shard clusters from the archived logs of the master node. For example, assume that the user requests to restore the data state at 15:00:00 on May 15, 2025, and the backup end time is 14:00:00 on May 15, 2025. At this time, the data consistency point closest to 15:00:00 needs to be found from the archived logs.

[0095] During the search process, it may be the case that the data consistency points of different shard clusters are inconsistent. For example, the closest data consistency point of shard cluster 1 is Barrier-20250515143000, while the closest data consistency point of shard cluster 2 is Barrier-20250515144500. This inconsistency may be due to different transaction processing speeds of different shard clusters. At this time, the previous data consistency point needs to be continued to be searched until a unified data consistency point existing in all shard clusters is found. Assume that the finally found unified data consistency point is Barrier-20250515141500, then this point will be used as the recovery target of the shard cluster.

[0096] When it is determined that the data consistency point found is consistent with the recovery time, first restore the basic data, and then replay the transaction log until the recovery time is reached. If the found data consistency point is inconsistent with the recovery time, then it is necessary to retrieve the log information between the recovery time and the found data consistency point from the log archive server. For example, assume that the recovery time is 15:00:00, and the unified data consistency point is Barrier-20250515141500, then it is necessary to retrieve the log information between 14:15:00 and 15:00:00. Replay the transaction log and the retrieved log information until the recovery time is reached, thereby completing the recovery operation.

[0097] In this way, each shard cluster first restores the backup data, and then replays the archived logs until the unified data consistency point is reached. Since all shard clusters are replayed to the same data consistency point, the consistency of the data after recovery can be guaranteed. This mechanism not only improves the flexibility of the recovery process, but also enhances the reliability and accuracy of data recovery.

[0098] Figure 6 The block diagram of the database data backup device according to an embodiment of the present invention is shown.

[0099] As Figure 6 shown, the database data backup device 600 includes a node selection module 610, a data point creation module 620, a data point distribution module 630, and a data storage module 640.

[0100] The node selection module 610 is configured to dynamically select the target nodes of each shard cluster according to the performance metrics of the standby nodes in each shard cluster in the server cluster in response to the received data backup request.

[0101] The data point creation module 620 is configured to create a data consistency point when it is determined that the target nodes in each shard cluster have completed the backup of the basic data of the master node. The data consistency point is used to mark the moment when the data of each node in the server cluster reaches a consistent state.

[0102] The data point distribution module 630 is configured to synchronously distribute the data consistency point to each shard cluster so that each shard cluster records the transaction log between the end time of the backup from the target node and the data consistency point.

[0103] The data storage module 640 is configured to persistently store the basic data and the transaction log.

[0104] According to an embodiment of the present invention, the node selection module 610 includes a sorting generation sub-module, a scoring generation sub-module, and a node selection sub-module.

[0105] A sorting generation sub-module, which is used for each shard cluster to respectively generate sorting results corresponding to each dimension based on the sub-index data of each standby node through a multi-dimensional sorting algorithm, where the sub-index data includes read / write speed, processor utilization rate, and data playback speed of the standby node.

[0106] A scoring generation sub-module, which is used to perform weighted fusion on the sorting results of each standby node in each dimension according to preset weights to generate a comprehensive performance score.

[0107] A node selection sub-module, which is used to select a target node from multiple standby nodes of the shard cluster according to the comprehensive performance score.

[0108] According to an embodiment of the present invention, the database data backup device 600 further includes a status determination module and a target determination module.

[0109] A status determination module, which is used to determine the node status of each standby node based on the performance metrics of the standby nodes in each shard cluster.

[0110] A target determination module, which is used for each shard cluster, in the case where it is determined that the node status of each standby node is in an unavailable state, to determine the primary node in the shard cluster as the target node.

[0111] According to an embodiment of the present invention, the data point creation module 620 includes a coordination selection sub-module and a request sending sub-module.

[0112] A coordination selection sub-module, which is used to randomly select a coordination node from multiple nodes with a running node status according to the node status of each node in the server cluster, and the coordination node is a primary node or a standby node.

[0113] A request sending sub-module, which is used to send a creation request for a data consistency point to the coordination node, so that after receiving the creation request, the coordination node generates a globally unique identifier including a timestamp according to the current system time.

[0114] According to an embodiment of the present invention, the database data backup device 600 further includes a signal sending module, a transaction processing module, and a data point generation module.

[0115] A signal sending module, which is used to send a blocking signal to the primary nodes in each shard cluster in the case where it is determined that the coordination node has received the creation request, and the blocking signal is used to block the submission of subsequent transactions.

[0116] A transaction processing module, which is used to stop receiving subsequent transaction submission requests in the case where each shard cluster receives the blocking signal; and complete the pending transaction that has started to be executed in the shard cluster.

[0117] A data point generation module, configured to generate a data consistency point through a coordination node when it is determined that the to-be-committed transactions of multiple shard clusters are all completed.

[0118] According to an embodiment of the present invention, the database data backup device 600 further includes a log archiving module.

[0119] The log archiving module is configured to store the log information generated by the primary node in each shard cluster during transaction processing to a log archiving server, where the log information includes the detailed information of the transaction operations performed by the primary node at each moment.

[0120] According to an embodiment of the present invention, the database data backup device 600 includes a time verification module, a data recovery module, a data point search module, a transaction replay module, and an information replay module.

[0121] The time verification module is configured to verify the recovery time in the data recovery request in response to the received data recovery request to obtain a verification result.

[0122] The data recovery module is configured to recover the basic data when it is determined that the verification result indicates that the recovery time is less than or equal to the backup end time.

[0123] The data point search module is configured to, when it is determined that the verification result indicates that the recovery time is greater than the backup end time, for each shard cluster, search for the data consistency point closest to the recovery time and shared by multiple shard clusters from the archived logs of the primary node.

[0124] The transaction replay module is configured to recover the basic data when it is determined that the found data consistency point is consistent with the recovery time; and replay the transaction logs to obtain the recovered data.

[0125] The information replay module is configured to recover the basic data when it is determined that the found data consistency point is inconsistent with the recovery time; and retrieve the log information between the recovery time and the found data consistency point from the log archiving server; replay the transaction logs and the retrieved log information to obtain the recovered data.

[0126] Any number of modules, sub-modules, units, and sub-units according to embodiments of the present invention, or at least part of the functions of any number of them, may be implemented in one module. Any one or more of the modules, sub-modules, units, and sub-units according to embodiments of the present invention may be split into multiple modules for implementation. Any one or more of the modules, sub-modules, units, and sub-units according to embodiments of the present invention may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on substrate, a system on package, an application specific integrated circuit (ASIC), or may be implemented by any other reasonable way of integrating or packaging circuits, or in any one of the three implementation manners of software, hardware, and firmware, or in an appropriate combination of any several of them. Alternatively, one or more of the modules, sub-modules, units, and sub-units according to embodiments of the present invention may be at least partially implemented as a computer program module, and when the computer program module runs, it may execute corresponding functions.

[0127] For example, any number of the node selection module 610, the data point creation module 620, the data point distribution module 630, and the data storage module 640 may be combined and implemented in one module / unit / sub-unit, or any one of the modules / units / sub-units may be split into multiple modules / units / sub-units. Alternatively, at least part of the functions of one or more of these modules / units / sub-units may be combined with at least part of the functions of other modules / units / sub-units and implemented in one module / unit / sub-unit. According to embodiments of the present invention, at least one of the node selection module 610, the data point creation module 620, the data point distribution module 630, and the data storage module 640 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on substrate, a system on package, an application specific integrated circuit (ASIC), or may be implemented by any other reasonable way of integrating or packaging circuits, or in any one of the three implementation manners of software, hardware, and firmware, or in an appropriate combination of any several of them. Alternatively, at least one of the node selection module 610, the data point creation module 620, the data point distribution module 630, and the data storage module 640 may be at least partially implemented as a computer program module, and when the computer program module runs, it may execute corresponding functions.

[0128] It should be noted that the part of the database data backup device in the embodiments of the present invention corresponds to the part of the database data backup method in the embodiments of the present invention. For the description of the part of the database data backup device, please refer to the part of the database data backup method for details, and it will not be elaborated here.

[0129] Figure 7 A block diagram of an electronic device suitable for implementing a database data backup method according to an embodiment of the present invention is shown. Figure 7 The shown electronic device is merely an example and should not impose any limitation on the functions and usage scope of the embodiments of the present invention.

[0130] As Figure 7 shown, the electronic device 700 according to an embodiment of the present invention includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage section 708 into a random access memory (RAM) 703. The processor 701 can include, for example, a general microprocessor (e.g., CPU), an instruction set processor, and / or a related chipset, and / or a dedicated microprocessor (e.g., an application specific integrated circuit (ASIC)), and so on. The processor 701 can also include on-board memory for caching purposes. The processor 701 can include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present invention.

[0131] In the RAM 703, various programs and data required for the operation of the electronic device 700 are stored. The processor 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. The processor 701 performs various operations of the method flow according to an embodiment of the present invention by executing the programs in the ROM 702 and / or the RAM 703. It should be noted that the program can also be stored in one or more memories other than the ROM 702 and the RAM 703. The processor 701 can also perform various operations of the method flow according to an embodiment of the present invention by executing the programs stored in one or more memories.

[0132] According to an embodiment of the present invention, the electronic device 700 may further include an input / output (I / O) interface 705, and the input / output (I / O) interface 705 is also connected to the bus 704. The electronic device 700 may further include one or more of the following components connected to the input / output (I / O) interface 705: an input portion 706 including a keyboard, a mouse, etc.; an output portion 707 including, for example, a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage portion 708 including a hard disk, etc.; and a communication portion 709 including a network interface card such as a LAN card, a modem, etc. The communication portion 709 performs communication processing via a network such as the Internet. The drive 710 is also connected to the input / output (I / O) interface 705 as needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed so that a computer program read from it can be installed into the storage portion 708 as needed.

[0133] According to an embodiment of the present invention, the method flow according to the embodiment of the present invention can be implemented as a computer software program. For example, an embodiment of the present invention includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program contains program codes for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication portion 709, and / or installed from the removable medium 711. When the computer program is executed by the processor 701, the above functions defined in the system of the embodiment of the present invention are executed. According to an embodiment of the present invention, the above-described system, device, apparatus, module, unit, etc. can be implemented by computer program modules.

[0134] The present invention also provides a computer-readable storage medium, which may be included in the device / device / system described in the above embodiment; or may exist separately without being assembled into the device / device / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present invention is implemented.

[0135] According to an embodiment of the present invention, the computer-readable storage medium may be a non-volatile computer-readable storage medium. For example, it may include but is not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In the present invention, the computer-readable storage medium may be any tangible medium that contains or stores a program, and this program can be used by or in combination with an instruction execution system, apparatus, or device.

[0136] For example, according to an embodiment of the present invention, the computer-readable storage medium may include one or more memories other than the above-described ROM 702 and / or RAM 703 and / or ROM 702 and RAM 703.

[0137] An embodiment of the present invention also includes a computer program product, which includes a computer program that contains program code for executing the method provided by the embodiment of the present invention. When the computer program product runs on an electronic device, this program code is used to enable the electronic device to implement the database data backup method provided by the embodiment of the present invention.

[0138] When this computer program is executed by the processor 701, the above functions defined in the system / apparatus of the embodiment of the present invention are executed. According to an embodiment of the present invention, the above-described systems, apparatuses, modules, units, etc. can be implemented by computer program modules.

[0139] In one embodiment, this computer program may rely on tangible storage media such as optical storage devices and magnetic storage devices. In another embodiment, this computer program may also be transmitted and distributed in the form of a signal on a network medium, and be downloaded and installed through the communication part 709, and / or be installed from the removable medium 711. The program code contained in this computer program can be transmitted by any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0140] According to an embodiment of the present invention, program code for executing the computer programs provided by the embodiments of the present invention can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The programming languages include, but are not limited to, programming languages such as Java, C++, Python, the "C" language, or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., by connecting through the Internet using an Internet service provider).

[0141] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and combinations of blocks in the block diagram or flowchart, can be implemented using a dedicated hardware-based system for performing the specified functions or operations, or can be implemented using a combination of dedicated hardware and computer instructions. Those skilled in the art can understand that the features described in the various embodiments of the present invention can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in the present invention. In particular, without departing from the spirit and teachings of the present invention, the features described in the various embodiments of the present invention can be combined and / or combined in various ways. All such combinations and / or combinations fall within the scope of the present invention.

[0142] The above describes the embodiments of the present invention. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present invention. Although the embodiments are described separately above, this does not mean that the measures in each embodiment cannot be used advantageously in combination. Without departing from the scope of the present invention, those skilled in the art can make various substitutions and modifications, and all such substitutions and modifications should fall within the scope of the present invention.

Claims

1. A method for backing up database data, characterized in that, Including: In response to receiving a data backup request, dynamically select the target nodes of each of the shard clusters according to the performance metrics of the standby nodes in each shard cluster of the server cluster; When it is determined that the target nodes in each of the shard clusters have completed the basic data backup of the primary node, create a data consistency point, which is used to mark the moment when the data of each node in the server cluster reaches a consistent state; Synchronously distribute the data consistency point to each of the shard clusters, so that each of the shard clusters records the transaction logs between the backup end time of the target node and the data consistency point; Persistently store the basic data and the transaction logs.

2. The method according to claim 1, wherein The performance metrics include sub-metric data in multiple dimensions; the dynamically selecting the target nodes of each of the shard clusters according to the performance metrics of the standby nodes in each shard cluster of the server cluster includes: For each of the shard clusters, based on the sub-metric data of each of the standby nodes, use a multi-dimensional sorting algorithm to respectively generate sorting results corresponding to each dimension, and the sub-metric data includes read / write speed, processor utilization rate, and data playback speed of the standby node; According to the preset weights, perform weighted fusion on the sorting results of each of the standby nodes in each dimension to generate a comprehensive performance score; Select the target node from multiple standby nodes of the shard cluster according to the comprehensive performance score.

3. The method according to claim 2, wherein It also includes: Based on the performance metrics of the standby nodes in each of the shard clusters, determine the node status of each of the standby nodes; For each of the shard clusters, when it is determined that the node status of each of the standby nodes is in an unavailable state, determine the primary node in the shard cluster as the target node.

4. The method according to claim 1, characterized in that The creating the data consistency point includes: According to the node status of each node in the server cluster, randomly select a coordination node from multiple nodes whose node status is in a running state, and the coordination node is a primary node or a standby node; Send a creation request for the data consistency point to the coordination node, so that after receiving the creation request, the coordination node generates a globally unique identifier including a timestamp according to the current system time.

5. The method according to claim 4, wherein It also includes: When it is determined that the coordination node has received the creation request, send a blocking signal to the primary nodes in each of the shard clusters, and the blocking signal is used to block the submission of subsequent transactions; When each of the shard clusters receives the blocking signal, stop receiving the submission requests of the subsequent transactions; And complete the pending transactions that have started to be executed in the shard cluster; When it is determined that the pending transactions of multiple shard clusters have all been executed, generate the data consistency point through the coordination node.

6. The method according to claim 1, characterized in that It also includes: Store the log information generated by the primary nodes in each of the shard clusters during transaction processing to a log archiving server, and the log information includes the detailed information of the transaction operations performed by the primary nodes at each moment.

7. The method according to claim 6, characterized in that, It also includes: In response to the received data recovery request, verify the recovery time in the data recovery request to obtain a verification result; When it is determined that the verification result indicates that the recovery time is less than or equal to the backup end time, recover the basic data; When it is determined that the verification result indicates that the recovery time is greater than the backup end time, for each of the shard clusters, find the data consistency point that is closest to the recovery time and common to multiple shard clusters from the archived logs of the master node; When it is determined that the found data consistency point is consistent with the recovery time, recover the basic data; and replay the transaction logs to obtain the recovery data; When it is determined that the found data consistency point is inconsistent with the recovery time, recover the basic data; And retrieve the log information between the recovery time and the found data consistency point from the log archiving server; replay the transaction logs and the retrieved log information to obtain the recovery data.

8. A database data backup device, characterized in that, Comprising: A node selection module, configured to dynamically select a target node for each of the shard clusters according to the performance metrics of the standby nodes in each shard cluster in the server cluster in response to a received data backup request; A data point creation module, configured to create a data consistency point when it is determined that the target nodes in each of the shard clusters have completed the backup of the basic data of the master node, where the data consistency point is used to mark the moment when the data of each node in the server cluster reaches a consistent state; A data point distribution module, configured to synchronously distribute the data consistency point to each of the shard clusters, so that each shard cluster records the transaction logs between the backup end time of the target node and the data consistency point; A data storage module, configured to persistently store the basic data and the transaction logs.

9. An electronic device, characterized in that, Comprising: One or more processors; A memory, configured to store one or more programs, wherein, when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Stored thereon are executable instructions, which when executed by a processor cause the processor to implement the method according to any one of claims 1 to 7.

Images