Backup management method, system, device, storage medium and program product of distributed computing cluster

Abstract

The application relates to a backup management method, system and device of a distributed computing cluster, a storage medium and a program product. The method comprises the following steps: a background management server selects a backup master node, and respectively sends backup sub-jobs to the backup master node and a sub-cluster master node; the backup master node acquires cluster lock information and sends the cluster lock information to a cluster management server; the sub-cluster master node performs backup configuration, and sends configuration information to the cluster management server; the cluster management server performs backup decision according to the cluster lock information and the configuration information, and notifies a backup node of a decision result; if a cluster state meets preset conditions, the backup master node sends a backup command to the sub-cluster master node; and the sub-cluster master node connects a storage server and performs a database backup operation according to parameters carried in the backup command and parameters carried in the backup sub-job. Through the above method, the business access node, the metadata node and the data node work cooperatively, and a DPC cluster backup task can be completed.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a backup management method, system, computer device, computer-readable storage medium, and computer program product for a distributed computing cluster. Background Technology

[0002] The arrival of the big data era is an inevitable trend in social development, and its impact has deeply permeated all aspects of daily life. For data with specific structures and organized according to established rules and methods, database systems have become a widely adopted solution due to their advantages in storage management, efficient querying, and convenient access. To prevent the risk of losing critical data due to hardware or software failures, regular data backups are crucial. With the help of complete backup sets and corresponding archived logs, it is possible to restore, copy, or migrate important data in the database, thereby effectively ensuring data security and business continuity.

[0003] Currently, with the development of computer technology, single data servers cannot meet the needs of a large number of users. Clusters can better distribute the pressure on single data servers and improve user access performance, thereby enhancing the user experience. Due to the diversity of clusters, while certain types of clusters can improve overall access performance, the fault tolerance of the entire cluster is put to the test. It is based on these complex considerations and by combining the advantages of various cluster types that composite clusters have emerged. DPC clusters (Distributed Processing Clusters) are one such type of composite multi-replica cluster.

[0004] Traditional cluster backup methods cannot meet the backup and recovery requirements of DPC clusters. Summary of the Invention

[0005] Therefore, it is necessary to provide a backup management method, system, computer equipment, computer-readable storage medium, and computer program product for distributed computing clusters to address the above-mentioned technical problems. This method can coordinate with business access nodes, metadata nodes, and data nodes to complete the backup task of the DPC cluster.

[0006] Firstly, this application provides a backup management method for a distributed computing cluster. The distributed computing cluster includes several service access nodes, a metadata cluster, and several data clusters. Both the metadata cluster and the data clusters adopt multi-replica sub-clusters, and each multi-replica sub-cluster has a sub-cluster master node. The method includes:

[0007] Based on the topology information of the distributed computing cluster, the backend management server selects the backup master node from several business access nodes and distributes the backup sub-jobs to the backup master node and the sub-cluster master node respectively.

[0008] The backup master node obtains cluster lock information based on the backup subjob and sends the cluster lock information to the cluster management server;

[0009] The sub-cluster master node performs backup configuration based on the backup sub-job and sends the configuration information to the cluster management server;

[0010] The cluster management server makes backup decisions based on cluster lock information and configuration information, and notifies the decision results to the backup master node and the sub-cluster master node.

[0011] If the backup master node determines that the cluster status meets the preset conditions based on the decision results, it sends a backup command to the sub-cluster master node.

[0012] The sub-cluster master node connects to the storage server and performs database backup operations based on the parameters carried in the backup command and the parameters carried in the backup sub-job.

[0013] In one embodiment, after the sub-cluster master node performs a database backup operation, the method further includes:

[0014] The backup master node summarizes the backup operation results of each sub-cluster master node, accesses the storage server to read back the backup data, verifies the backup operation results against the read-back backup data, and after the verification is successful, compiles the backup metadata and stores the backup metadata in the Catalog server.

[0015] In one embodiment, the backup metadata includes at least one of the following: topology information of the distributed computing cluster, type of each backup set, source information of each backup set, storage address of each backup set, archived log address, and backup data volume.

[0016] In one embodiment, after the backup master node stores the backup metadata in the Catalog server, the method further includes:

[0017] The backup master node notifies the child cluster master node of backup completion information;

[0018] The sub-cluster master node responds to the backup completion message by deleting the corresponding cached data.

[0019] In one embodiment, the method further includes:

[0020] Based on the topology information of the distributed computing cluster, the backend management server filters out business access nodes and distributes backup and recovery jobs to the metadata nodes in the metadata cluster and the data nodes in the data cluster, respectively.

[0021] Metadata nodes and data nodes access the Catalog server to obtain backup metadata based on the backup and recovery job. They determine the backup set storage address and archive log address of the corresponding node based on the backup metadata, download the archive log from the storage server based on the archive log address, and perform database recovery operations based on the backup set corresponding to the backup set storage address in the storage server and the downloaded archive log.

[0022] In one embodiment, the method further includes:

[0023] When the backup and recovery job is a cross-cluster recovery job, the metadata node modifies the registration information of each data node after the backup and recovery is completed.

[0024] Secondly, this application also provides a backup management system for a distributed computing cluster. The system includes a backend management server, a distributed computing cluster, a cluster management server, and a storage server. The distributed computing cluster includes several business access nodes, a metadata cluster, and several data clusters. Both the metadata cluster and the data clusters adopt multi-replica sub-clusters, and each multi-replica sub-cluster has a sub-cluster master node.

[0025] The background management server is used to select the backup master node from several business access nodes based on the topology information of the distributed computing cluster, and to distribute the backup sub-jobs to the backup master node and the sub-cluster master node respectively.

[0026] The backup master node is used to obtain cluster lock information based on the backup sub-job and send the cluster lock information to the cluster management server.

[0027] The sub-cluster master node is used to perform backup configuration based on the backup sub-job and send the configuration information to the cluster management server;

[0028] The cluster management server is used to make backup decisions based on cluster lock information and configuration information, and to notify the backup master node and the sub-cluster master node of the decision results.

[0029] The backup master node is also used to send backup commands to the sub-cluster master node when the cluster status is determined to meet preset conditions based on the decision results.

[0030] The sub-cluster master node is also used to connect to the storage server and perform database backup operations based on the parameters carried in the backup command and the parameters carried in the backup sub-job.

[0031] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the first aspect above.

[0032] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect above.

[0033] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect above.

[0034] The aforementioned backup management method, system, computer equipment, computer-readable storage media, and computer program products for distributed computing clusters involve the following steps: The backend management server selects a backup master node from several service access nodes based on the topology information of the distributed computing cluster, and distributes backup sub-jobs to the backup master node and sub-cluster master nodes respectively. The backup master node acquires cluster lock information based on the backup sub-jobs and sends the cluster lock information to the cluster management server. The sub-cluster master nodes perform backup configuration based on the backup sub-jobs and send the configuration information to the cluster management server. The cluster management server makes a backup decision based on the cluster lock information and configuration information, and notifies the backup master node and sub-cluster master nodes of the decision result. If the backup master node determines that the cluster status meets preset conditions based on the decision result, it sends a backup command to the sub-cluster master nodes. The sub-cluster master nodes connect to the storage server and execute database backup operations based on the parameters carried in the backup command and the parameters carried in the backup sub-jobs. Through this method, the DPC cluster backup task can be completed by the collaborative work of service access nodes, metadata nodes, and data nodes. Because each multi-replica sub-cluster has its own master node, the failure of a single node in a multi-replica sub-cluster will not affect the business of the entire distributed computing cluster, thus improving the stability of database backups. The cluster management server makes backup decisions based on cluster lock information and configuration information, enabling it to complete the backup preparation work for the distributed computing cluster, avoiding data conflicts and consistency issues, ensuring the successful execution of backup tasks, and improving the reliability of data protection. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is an application environment diagram of a backup management method for a distributed computing cluster in one embodiment;

[0037] Figure 2 This is a flowchart illustrating a backup management method for a distributed computing cluster in one embodiment;

[0038] Figure 3 This is a schematic diagram of the backup process for a DPC cluster in one embodiment;

[0039] Figure 4 This is a schematic diagram of the recovery process for a DPC cluster in one embodiment;

[0040] Figure 5 This is a structural block diagram of a backup management system for a distributed computing cluster in one embodiment.

[0041] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0043] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0044] The backup management method for distributed computing clusters provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, the UI (User Interface) 101 communicates with backupd (backup management server) 102 via the network. Backupd 102 communicates with the Distributed Computing Cluster (DPC) 103 via the network. The Distributed Computing Cluster 103 communicates with the Cluster Management Server 104, Storage Server 105, and Catalog Server 106 via the network. The Distributed Computing Cluster 103 includes SP nodes (SQL Processors, business access nodes), MP clusters (Metadata Processors, metadata clusters), and several BP clusters (Backend Processors, data clusters). Further, an SP node is an access node that backs up or restores the entire cluster data. This node only provides data service access functions and does not store business data itself; therefore, it does not need to back up any data. An MP cluster includes multiple MP nodes, using a multi-replica sub-cluster, used to store the metadata information of the DPC cluster. All nodes joining the cluster must register with the MP nodes. A BP cluster includes multiple BP nodes, using a multi-replica sub-cluster, and distributedly stores all business data of the DPC cluster through multiple BP clusters.

[0045] In one exemplary embodiment, such as Figure 2 As shown, a backup management method for distributed computing clusters is provided, which can be applied to applications such as... Figure 1 In the environment shown, the distributed computing cluster includes several service access nodes, a metadata cluster, and several data clusters. Both the metadata cluster and the data clusters employ multi-replica sub-clusters, and each multi-replica sub-cluster has a sub-cluster master node. The method includes:

[0046] Step 202: The backend management server selects the backup master node from several business access nodes based on the topology information of the distributed computing cluster, and distributes the backup sub-jobs to the backup master node and the sub-cluster master node respectively.

[0047] The DPC cluster refers to the DM distributed computing cluster. This cluster consists of multiple nodes working collaboratively to complete the tasks of the entire DPC cluster. To improve the overall fault tolerance of the DPC cluster, it includes MP multi-replica architecture and BP multi-replica architecture. Each MP cluster and BP cluster in the DPC is composed of multi-replica sub-clusters. This ensures that the failure of a single MP node or a single BP node does not affect the services of the entire DPC cluster, giving the DPC cluster characteristics such as high availability, high scalability, high performance, high throughput, and transparency. (Refer to...) Figure 1 A DPC cluster consists of several SP nodes ( Figure 1The diagram shows only one SP node, one MP multi-replica sub-cluster, and several BP multi-replica sub-clusters. The MP cluster, BP1 cluster, and BP2 cluster are three multi-replica sub-clusters in the entire combined cluster, and together with one SP node, they constitute the entire DPC cluster.

[0048] During backup, the backend management server dynamically selects one of the SP nodes as the backup access point for the entire DPC cluster based on a preset algorithm. Optionally, the backend management server selects the backup master node from multiple SP nodes based on preset load balancing rules and the topology information of the DPC cluster. Optionally, each SP node and each MP node in the MP cluster are built on the same physical machine, and the selected backup master SP node can dynamically change as the master nodes of the sub-clusters in the MP cluster change.

[0049] It should be noted that the DPC cluster only backs up the data of the master nodes in all multi-replica sub-clusters at a time. The master nodes of the sub-clusters in the MP cluster and the master nodes of the sub-clusters in the BP cluster can be dynamically switched. The switching of the master nodes of each multi-replica sub-cluster does not affect the external business functions of the entire DPC.

[0050] In one optional implementation, the data content in the multi-replica sub-cluster is cloned. However, because the DB_MAGIC (database magic number) of the multiple replicas is not equal, the backup data of each node in the multi-replica sub-cluster is not universal across the primary and backup sub-clusters. Since the primary node of the multi-replica sub-cluster can be migrated during operation—for example, if a new primary node is re-elected—the entire DPC cluster will be unable to perform incremental backups because the new primary node lacks a base backup. Therefore, the backend management server detects which nodes make up the backup set of the entire combined cluster and whether it supports incremental or differential backups. If incremental backups are supported, it switches to incremental backup mode and notifies each sub-cluster primary node to perform incremental backups during subsequent backup processes.

[0051] Step 204: The backup master node obtains the cluster lock information based on the backup subjob and sends the cluster lock information to the cluster management server.

[0052] Since data backup is inherently a mutually exclusive operation, the database uses internal mutex locks. To prevent concurrent backups from failing within the database and causing subsequent processing issues (due to the large number of cluster nodes, subsequent operations become cumbersome, such as garbage data reclamation), a cluster backup lock needs to be acquired before issuing a backup command to the cluster. If the lock has already been preempted by another job, acquiring the backup lock will fail, and the backup task will need to retry until the backup lock is acquired before the cluster backup task can be executed. Understandably, when multiple consecutive backup jobs exist in a DPC cluster, a competition for the cluster resource mutex lock will occur. If the acquisition of the cluster resource lock fails, the backup job will fail and need to be retried.

[0053] The cluster management server is responsible for detecting the real-time node status information of each node in the DPC cluster, collecting the topology information of the entire cluster, and the metadata information corresponding to each backup set.

[0054] Step 206: The sub-cluster master node performs backup configuration based on the backup sub-job and sends the configuration information to the cluster management server.

[0055] In this embodiment, the sub-cluster master node refers to the sub-cluster master node in the MP cluster or any BP cluster, meaning that the master node in each multi-replica sub-cluster executes step 206. In a specific implementation, the sub-cluster master node completes the preparation work before the data backup operation through backup configuration. In an optional implementation, the backup configuration of the sub-cluster master node includes configuration and installation of the SBT (System Backup to Tape) library.

[0056] Step 208: The cluster management server makes a backup decision based on the cluster lock information and configuration information, and notifies the backup master node and the sub-cluster master node of the decision result.

[0057] The cluster management server collects cluster information and performs status checks. Based on the collected information, it makes backup decisions and notifies each node of the results. Backup decisions include, but are not limited to, at least one of the following: checking if the entire cluster is in a normal state, checking if each node has completed its preparation work, and checking if any node is holding a cluster lock.

[0058] Step 210: If the backup master node determines that the cluster status meets the preset conditions based on the decision results, it sends a backup command to the sub-cluster master node.

[0059] The decision results include a first result and a second result. The first result indicates that the cluster state meets preset conditions, while the second result indicates that the cluster state does not meet preset conditions. Upon receiving the first result, the backup master node sends a backup command to the sub-cluster master node. Meeting the preset conditions means that the entire cluster is in a normal state, all nodes have completed their preparation work, and no other nodes are holding cluster locks.

[0060] Step 212: The sub-cluster master node connects to the storage server and performs the database backup operation based on the parameters carried in the backup command and the parameters carried in the backup sub-job.

[0061] The storage servers are primarily used to store multiple backup sets of the entire cluster's database and archived logs. Each sub-cluster master node connects to the storage server individually to perform database backups based on the parameters carried in the backup command and the job parameter information distributed by the background management server. It can be understood that a DPC cluster generates multiple backup sets during backup; that is, each multi-replica sub-cluster generates one backup set, which are categorized into MP backup sets and BP backup sets according to the role of the multi-replica sub-cluster in the overall cluster.

[0062] In the aforementioned backup management method for distributed computing clusters, the backend management server selects a backup master node from several service access nodes based on the topology information of the distributed computing cluster, and distributes backup sub-jobs to the backup master node and sub-cluster master nodes respectively. The backup master node obtains cluster lock information based on the backup sub-jobs and sends the cluster lock information to the cluster management server. The sub-cluster master nodes perform backup configuration based on the backup sub-jobs and send the configuration information to the cluster management server. The cluster management server makes a backup decision based on the cluster lock information and configuration information, and notifies the backup master node and sub-cluster master nodes of the decision result. If the backup master node determines that the cluster status meets the preset conditions based on the decision result, it sends a backup command to the sub-cluster master nodes. The sub-cluster master nodes connect to the storage server and execute the database backup operation based on the parameters carried in the backup command and the parameters carried in the backup sub-jobs. Through the above method, the DPC cluster backup task can be completed by the collaborative work of service access nodes, metadata nodes, and data nodes. Since each multi-replica sub-cluster has a sub-cluster master node, the failure of a single node in the multi-replica sub-cluster will not affect the business of the entire distributed computing cluster, thus improving the stability of database backup. The cluster management server makes backup decisions based on cluster lock information and configuration information, which can complete the backup preparation work of the distributed computing cluster, avoid data conflicts and consistency issues, ensure that the backup task can be successfully executed, and improve the reliability of data protection.

[0063] In one exemplary embodiment, such as Figure 3As shown, after the master node of the sub-cluster performs the database backup operation, the method further includes: the backup master node summarizing the backup operation results of each master node of the sub-cluster, accessing the storage server to read back the backup data, verifying the backup operation results and the read-back backup data, and after the verification is passed, compiling backup metadata and storing the backup metadata in the Catalog server.

[0064] Since the master node (i.e. the sub-cluster master node) in each multi-replica sub-cluster can be switched, after the backup is completed, the backup master node (SP node) reads back to the storage server to verify the backup set and summarize the data of multiple backup sets.

[0065] In this embodiment, the Catalog server is used to store and query backup jobs for the entire system, including system metadata information such as cluster backup set records, log backup records, and cluster topology. Each time the cluster performs a backup, it generates a cluster backup record, which is used to find available backup sets during recovery, to find existing base backups during incremental backups, or to find required archived logs during archived log downloads.

[0066] In one exemplary embodiment, the backup metadata includes at least one of the following: topology information of the distributed computing cluster, type of each backup set, source information of each backup set, storage address of each backup set, archived log address, and backup data volume.

[0067] Among them, backup metadata refers to the metadata information of the backup set, which records at least one of the following: the topology information of the entire DPC cluster, the backup set type to which the backup set belongs (including MP backup set and BP backup set), the source information of the backup set (i.e., which multi-replica sub-cluster the backup set belongs to, and which specific node in the multi-replica sub-cluster it belongs to), the storage address of each backup set, the archive log address, and the amount of backup data.

[0068] Preferably, as an information set, the backup metadata includes various information such as the topology of the distributed computing cluster, the type of each backup set, the source information of each backup set, the storage address of each backup set, the archived log address, and the amount of backup data. In specific implementations, in addition to this information, the backup metadata may also include other backup information.

[0069] In an exemplary embodiment, after the backup master node stores the backup metadata in the Catalog server, the method further includes: the backup master node notifying the sub-cluster master node of backup completion information; and the sub-cluster master node deleting the corresponding cached data in response to the backup completion information.

[0070] In this process, the backup master node notifies all other nodes in the cluster that the backup is complete, and the sub-cluster master node can delete some cached data to complete the backup cleanup.

[0071] In an exemplary embodiment, the method further includes: the background management server filters out business access nodes based on the topology information of the distributed computing cluster, and distributes backup and recovery jobs to the metadata nodes in the metadata cluster and the data nodes in the data cluster respectively; the metadata nodes and data nodes access the Catalog server to obtain backup metadata based on the backup and recovery jobs, determine the backup set storage address and archive log address of the corresponding node based on the backup metadata, download the archive log from the storage server based on the archive log address, and perform database recovery operations based on the backup set corresponding to the backup set storage address in the storage server and the downloaded archive log.

[0072] The backend management server analyzes the topology of the DPC cluster, filters out SP nodes, and distributes the cluster backup and recovery tasks to all metadata nodes (MP nodes) and data nodes (BP nodes). In an optional implementation, when the backup and recovery job is a cross-cluster recovery job, the nodes are mapped one-to-one according to their roles, and a specific node is notified to undertake the data recovery work of the target node in the source cluster.

[0073] After receiving the backup and recovery job, the MP and BP nodes each access and retrieve the backup metadata defined in the Catalog. Each node individually parses the entire backup metadata and obtains the address of the dataset on the storage server. The cluster uses the data parsed from the metadata to search for and download the necessary archived logs from the entire storage server. The database recovery job is then performed using the server's backup set and the downloaded archived logs.

[0074] In this embodiment, backup sets generated by each of the multi-replica sub-clusters are used to restore or recover data from the multi-replica sub-clusters, thereby achieving the restoration or recovery of the entire DPC cluster. Each node has its own separate archived logs; even if the archived logs of the multi-replica sub-clusters are used across nodes, it is ineffective.

[0075] In one optional implementation, DPC cluster recovery is offline, requiring the database service monitoring process to be shut down. Recovery of any multiple replica sub-clusters or a single node within the DPC cluster is independent and does not affect each other. After node recovery is complete, the database is started separately, and the database automatically detects and synchronizes cluster data according to the cluster configuration.

[0076] To ensure the consistency and synchronization of data across the entire cluster after the combined cluster is restored, the method provided in this example can manage and maintain backup sets and archived logs at a specific point in time within the cluster, including the management, querying, and intelligent downloading of all backup sets and related archived logs in the cluster.

[0077] In an exemplary embodiment, the method further includes: when the backup and recovery job is a heterogeneous cluster recovery job, the metadata node modifies the registration information of each stored data node after the backup and recovery is completed.

[0078] It's understandable that a cross-cluster recovery job refers to a situation where the recovery cluster and the source backup cluster are two different clusters. During configuration, there will be many differences, such as instance names, port numbers, machine IP addresses, etc. After the MP data from the source cluster is restored to the new cluster, these configuration information, belonging to the source cluster, need to be updated and synchronized according to the information of the new cluster. In the specific implementation, for cross-cluster recovery, the MP is started in single-machine mode, and the registration information of all nodes in the MP is modified before starting it in cluster mode. This step is skipped if the backup recovery job belongs to the source cluster recovery job.

[0079] In one exemplary embodiment, refer to Figure 3 The backup process for a DPC cluster includes the following steps:

[0080] 1. The UI page intelligently binds the cluster according to the actual configured DPC environment. In this way, the page will treat the database of multiple nodes in the cluster as the entire cluster. Users can click on any node to select the DPC cluster backup.

[0081] 2. The backup task will be sent from the front end to the backend management server (backupd). At this time, backupd will analyze the topology of the entire cluster based on the backend cluster data bound to the cluster, and then dynamically select one of the SP nodes in the cluster as the node that issues the backup command (i.e. the master node of the entire cluster) based on the analyzed topology, and at the same time send the cluster backup task to all nodes in the cluster.

[0082] 3. Upon receiving a backup task, all nodes in the cluster will check if a backup task is already in progress on their own node (whether a cluster lock is being used). If the lock is held, it indicates that a backup or recovery job is being executed in the cluster. If the lock is not preempted, the node will acquire and preempt the cluster lock, and perform some preparatory work before backup, such as configuring the service to which the backup data is uploaded and generating configuration information. At the same time, the node will notify the cluster management server of its information, and the cluster management server will perform real-time data aggregation of the cluster.

[0083] 4. After collecting real-time information from all nodes in the entire cluster, the cluster management server summarizes the information and decides whether the entire DPC cluster has the conditions for cluster backup (such as whether the status of the entire cluster is normal, whether any node is holding a cluster lock, etc.), and notifies each node in the cluster of the decision.

[0084] 5. When the master node acquires the cluster lock, it issues a database backup command to each node in the cluster.

[0085] 6. Each node will connect to the storage server separately to perform database backup based on the parameters carried in the command issued by the master node and the job parameter information distributed by backupd.

[0086] 7. The backup server will return the backup results individually to each node in the cluster.

[0087] 8. The master node summarizes the backup data results of each node, accesses the storage server again to read back and verify the backup data of each node, and compiles statistics, such as how much storage space the entire cluster backup occupies.

[0088] 9. The master node will store the statistical results of the entire cluster as metadata in the Catalog, including the composition structure of the entire cluster data, the amount of data, and the instance information corresponding to each dataset.

[0089] 10. The master node then notifies all other nodes in the cluster that the backup is complete and that they can delete some cached data to finish the backup process.

[0090] 11. The master node notifies backupd that the backup is complete.

[0091] 12. backupd will return the information to the front-end page for display.

[0092] In one exemplary embodiment, refer to Figure 4 The recovery process for a DPC cluster includes the following steps:

[0093] 1. Select any node in the cluster on the UI page to restore the cluster.

[0094] 2. backupd analyzes the cluster topology based on the data from the cluster binding process, filters out all SP nodes, and distributes the cluster recovery task to all MP and BP nodes. For cross-cluster recovery, it maps nodes one-to-one according to their roles and notifies a specific node to handle the data recovery for its corresponding target node in the source cluster.

[0095] 3. After receiving the cluster recovery task, these MP nodes and BP nodes each access and obtain the metadata information defined in the Catalog (i.e., Figure 3 (Data stored in the backup).

[0096] 4. Each node parses the entire metadata information individually and obtains the address of the dataset in the storage server.

[0097] 5. The cluster uses the data parsed from the metadata to search for and download the required archived logs from the entire storage server.

[0098] 6. Perform database recovery operations using the backup set of the storage server and the downloaded archived logs. If it is a cross-cluster recovery, you need to start MP in single-machine mode and modify the registration information of all nodes in MP before starting it in cluster mode (skip this step for source cluster recovery).

[0099] 7. Notify backupd of the recovery results.

[0100] 8. backupd will notify the front-end page of the recovery results.

[0101] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0102] Based on the same inventive concept, this application also provides a backup management system for a distributed computing cluster used to implement the backup management method for the distributed computing cluster described above. The solution provided by this system is similar to the implementation scheme described in the above method; therefore, the specific limitations of one or more embodiments of the backup management system for a distributed computing cluster provided below can be found in the limitations of the backup management method for the distributed computing cluster described above, and will not be repeated here.

[0103] In one exemplary embodiment, such as Figure 5As shown, a backup management system for a distributed computing cluster is provided. The system includes a backend management server 501, a distributed computing cluster 502, a cluster management server 503, and a storage server 504. The distributed computing cluster 502 includes several business access nodes 5021, a metadata cluster 5022, and several data clusters 5023. Both the metadata cluster 5022 and the data clusters 5023 adopt multi-replica sub-clusters, and each multi-replica sub-cluster has a sub-cluster master node.

[0104] The background management server 501 is used to select a backup master node from several business access nodes 5021 based on the topology information of the distributed computing cluster 502, and to distribute backup sub-jobs to the backup master node and the sub-cluster master node respectively.

[0105] The backup master node is used to obtain cluster lock information based on the backup sub-job and send the cluster lock information to the cluster management server 503.

[0106] The sub-cluster master node is used to perform backup configuration based on the backup sub-job and send the configuration information to the cluster management server 503;

[0107] Cluster management server 503 is used to make backup decisions based on cluster lock information and configuration information, and to notify the backup master node and sub-cluster master node of the decision results.

[0108] The backup master node is also used to send backup commands to the sub-cluster master node when the cluster status is determined to meet preset conditions based on the decision results.

[0109] The sub-cluster master node is also used to connect to storage server 504 and perform database backup operations based on the parameters carried in the backup command and the parameters carried in the backup sub-job.

[0110] In an exemplary embodiment, the system further includes a Catalog server, a backup master node, and is also used to summarize the backup operation results of each sub-cluster master node, access the storage server 504 to read back backup data, verify the backup operation results against the read-back backup data, and after the verification is successful, compile backup metadata and store the backup metadata in the Catalog server.

[0111] In one exemplary embodiment, the backup metadata includes at least one of the following: topology information of the distributed computing cluster 502, type of each backup set, source information of each backup set, storage address of each backup set, archived log address, and backup data volume.

[0112] In one exemplary embodiment, the backup master node is also used to notify the sub-cluster master node of backup completion information;

[0113] The sub-cluster master node is also used to delete the corresponding cached data in response to backup completion information.

[0114] In an exemplary embodiment, the background management server 501 is further configured to filter out the business access node 5021 based on the topology information of the distributed computing cluster 502, and distribute the backup and recovery jobs to the metadata nodes in the metadata cluster 5022 and the data nodes in the data cluster 5023 respectively.

[0115] Metadata nodes and data nodes access the Catalog server to obtain backup metadata based on the backup and recovery job. They determine the backup set storage address and archive log address of the corresponding node based on the backup metadata, download the archive log from storage server 504 based on the archive log address, and perform database recovery operations based on the backup set corresponding to the backup set storage address in storage server 504 and the downloaded archive log.

[0116] In an exemplary embodiment, when the backup and recovery job is a cross-cluster recovery job, the metadata node modifies the registration information of each data node after the backup and recovery is completed.

[0117] The modules in the backup management system of the aforementioned distributed computing cluster can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or they can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0118] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a backup management method for a distributed computing cluster.

[0119] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0120] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0121] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0122] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0123] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0124] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0125] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0126] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A backup management method for a distributed computing cluster, characterized in that, The distributed computing cluster includes several service access nodes, a metadata cluster, and several data clusters. Both the metadata cluster and the data clusters employ multi-replica sub-clusters, and each multi-replica sub-cluster has a sub-cluster master node. The method includes: The backend management server selects a backup master node from the plurality of service access nodes based on the topology information of the distributed computing cluster, and distributes backup sub-jobs to the backup master node and the sub-cluster master node respectively; wherein, the backend management server detects which nodes make up the backup set of the distributed computing cluster and determines whether incremental backup or differential backup is supported; if incremental backup is supported, it switches to incremental backup mode. The backup master node obtains cluster lock information based on the backup sub-job and sends the cluster lock information to the cluster management server; The sub-cluster master node performs backup configuration based on the backup sub-job and sends the configuration information to the cluster management server; The cluster management server makes backup decisions based on the cluster lock information and the configuration information, and notifies the backup master node and the sub-cluster master node of the decision results; When the backup master node determines that the cluster status meets the preset conditions based on the decision result, it sends a backup command to the sub-cluster master node. The sub-cluster master node connects to the storage server and performs database backup operations based on the parameters carried in the backup command and the parameters carried in the backup sub-job; wherein, in incremental backup mode, the sub-cluster master node performs incremental backup operations based on the notification from the background management server.

2. The method according to claim 1, characterized in that, After the sub-cluster master node performs the database backup operation, the method further includes: The backup master node summarizes the backup operation results of each sub-cluster master node, accesses the storage server to read back the backup data, verifies the backup operation results against the read-back backup data, and after the verification is successful, compiles the backup metadata and stores the backup metadata in the Catalog server.

3. The method according to claim 2, characterized in that, The backup metadata includes at least one of the following: the topology of the distributed computing cluster, the type of each backup set, the source information of each backup set, the storage address of each backup set, the archived log address, and the amount of backup data.

4. The method according to claim 2, characterized in that, After the backup master node stores the backup metadata in the Catalog server, the method further includes: The backup master node notifies the sub-cluster master node of backup completion information; The sub-cluster master node responds to the backup completion information by deleting the corresponding cached data.

5. The method according to any one of claims 2 to 4, characterized in that, The method further includes: The backend management server filters out the business access nodes based on the topology information of the distributed computing cluster, and distributes the backup and recovery jobs to the metadata nodes in the metadata cluster and the data nodes in the data cluster, respectively. The metadata node and the data node respectively access the Catalog server to obtain the backup metadata based on the backup and recovery job, determine the backup set storage address and archive log address of the corresponding node according to the backup metadata, download the archive log from the storage server according to the archive log address, and perform database recovery operation according to the backup set corresponding to the backup set storage address in the storage server and the downloaded archive log.

6. The method according to claim 5, characterized in that, The method further includes: When the backup and recovery job is a cross-cluster recovery job, the metadata node modifies the registration information of each data node after the backup and recovery is completed.

7. A backup management system for a distributed computing cluster, characterized in that, The system includes a backend management server, a distributed computing cluster, a cluster management server, and a storage server. The distributed computing cluster includes several business access nodes, a metadata cluster, and several data clusters. Both the metadata cluster and the data clusters adopt multi-replica sub-clusters, and each multi-replica sub-cluster has a sub-cluster master node. The background management server is used to select a backup master node from the plurality of service access nodes according to the topology information of the distributed computing cluster, and to distribute backup sub-jobs to the backup master node and the sub-cluster master node respectively; wherein, the background management server detects which nodes make up the backup set of the distributed computing cluster and determines whether incremental backup or differential backup is supported; if incremental backup is supported, it switches to incremental backup mode. The backup master node is used to obtain cluster lock information based on the backup sub-job and send the cluster lock information to the cluster management server; The sub-cluster master node is used to perform backup configuration based on the backup sub-job and send the configuration information to the cluster management server; The cluster management server is used to make backup decisions based on the cluster lock information and the configuration information, and to notify the backup master node and the sub-cluster master node of the decision results; The backup master node is also used to send a backup command to the sub-cluster master node when the cluster status is determined to meet preset conditions based on the decision result. The sub-cluster master node is also used to connect to the storage server and perform database backup operations according to the parameters carried in the backup command and the parameters carried in the backup sub-job; wherein, in incremental backup mode, the sub-cluster master node performs incremental backup operations according to the notification from the background management server.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images