Sharding cluster backup recovery method, system, device, computer equipment and medium

By establishing a mapping between master node identifiers and backup file paths through a backup server, backup files are automatically retrieved and stored, solving the problem of high complexity in backup and recovery of sharded clusters and simplifying user operations.

CN118152185BActive Publication Date: 2026-02-17ANHUI DINGJIA COMPUTER TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202410351521.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-03-26
Publication Date
2026-02-17
Estimated Expiration
2044-03-26

AI Technical Summary

Technical Problem

Existing sharded cluster backup and recovery methods are highly complex, requiring users to manually memorize and manipulate numerous backup file attributes, which is prone to errors.

Method used

By establishing a mapping between master node identifiers and backup file paths through a backup server, backup files can be automatically retrieved and stored, reducing the complexity of user operations.

Benefits of technology

This eliminates the need for users to remember the attributes of each backup file during sharded cluster backup and recovery, simplifying the operation process and reducing complexity.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118152185B_ABST
    Figure CN118152185B_ABST
Patent Text Reader

Abstract

The application relates to a sharding cluster backup recovery method, system and device, computer equipment and a storage medium. The method comprises the following steps: a backup server acquires backup files corresponding to each target slave node included in a source cluster to be backed up in response to a sharding cluster backup request; acquires a backup file path corresponding to each backup file and a first master node identifier corresponding to each target slave node, and constructs a first correspondence relationship; acquires second master node identifiers of each master node in a target cluster used for recovering the backup files of the source cluster in response to a sharding cluster recovery request for the source cluster, and constructs a second correspondence relationship; the first correspondence relationship and the second correspondence relationship are used for acquiring each backup file from a backup file path corresponding to each second master node identifier and storing the backup file in each master node corresponding to the second master node identifier. The method can reduce the complexity of sharding cluster backup recovery.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a sharding cluster backup recovery method, system, device, computer equipment, storage medium and computer program product. BACKGROUND

[0002] With the development of data processing technology, a technology of using a sharding cluster for data management has appeared. The sharding cluster is usually composed of multiple shards and a configuration service, and each shard and the configuration service contain a master-slave relationship. When backing up, data needs to be backed up from each slave node. Since the number of shards is multiple, multiple backup files will be generated. When recovering, the corresponding backup data files need to be recovered to the corresponding master node.

[0003] In the traditional technology, for the data backup and recovery of the sharding cluster, since the corresponding backup data files need to be recovered to the corresponding master node, the user usually needs to manually remember the attributes of each backup file and copy them one by one to the corresponding node.

[0004] However, if the number of shards in the sharding cluster is large, the number of backup files will also increase accordingly. The above backup recovery method requires the user to remember the attributes of each backup file, which greatly increases the user's operation complexity and is prone to errors. Therefore, the existing sharding cluster backup recovery method has high complexity. SUMMARY

[0005] Therefore, it is necessary to provide a sharding cluster backup recovery method, system, device, computer equipment, storage medium and computer program product capable of reducing the complexity of the sharding cluster backup recovery method.

[0006] In a first aspect, the present application provides a sharding cluster backup recovery method applied to a backup server, comprising:

[0007] In response to a sharding cluster backup request, obtaining backup files corresponding to each target slave node included in a source cluster to be backed up; each target slave node corresponds to a different master node in the source cluster;

[0008] Obtaining a backup file path corresponding to each backup file, and a first master node identifier corresponding to each target slave node, and constructing a first correspondence relationship between each first master node identifier and each backup file path;

[0009] In response to a sharded cluster recovery request for the source cluster, the second master node identifier of each master node in the target cluster used to recover the backup files of the source cluster is obtained, and a second correspondence between each first master node identifier and each second master node identifier is constructed; the first correspondence and the second correspondence are used to obtain each backup file from the backup file path corresponding to each second master node identifier according to the second master node identifier corresponding to each master node in the target cluster, and the first correspondence and the second correspondence, and store them in each master node corresponding to the second master node identifier.

[0010] In one embodiment, the source cluster includes multiple first shards and a first configuration server, each first shard and the first configuration server including a master node and multiple slave nodes; each master node in each first shard and the first configuration server is configured with a first agent; the step of obtaining backup files corresponding to each target slave node in the source cluster to be backed up in response to the shard cluster backup request includes: in response to the shard cluster backup request, obtaining the target slave node from the slave nodes corresponding to each of the first shards in the source cluster and the slave nodes included in the first configuration server; generating a cluster backup task based on the target slave node, and sending the cluster backup task to the first agent configured in each of the first shards and the first configuration server; the cluster backup task is used for each first agent to obtain the target slave node from the multiple slave nodes corresponding to each first agent, and obtain backup files from the target slave node respectively and send them to the backup server.

[0011] In one embodiment, each of the first agents is further configured to obtain the first master node identifier of the master node corresponding to each of the first agents, and to obtain the backup file path of the backup file corresponding to each of the first agents in the backup server; the step of obtaining the backup file path corresponding to each of the backup files and the first master node identifier corresponding to each of the target slave nodes includes: receiving the backup file path corresponding to each of the first agents and the first master node identifier corresponding to each of the first agents sent by each of the first agents.

[0012] In one embodiment, each of the first correspondences is stored in a database table; after constructing the first correspondence between each of the first master node identifiers and each of the backup file paths, the method further includes: writing each of the first correspondences into the database table and generating a database table identifier corresponding to the database table; in response to a sharded cluster recovery request for the source cluster, obtaining the second master node identifiers of each master node in the target cluster for restoring the backup files of the source cluster, and constructing a second correspondence between each of the first master node identifiers and each of the second master node identifiers, includes: in response to the sharded cluster recovery request, obtaining a database table identifier that matches the sharded cluster recovery request; obtaining a database table that matches the database table identifier, and obtaining each of the first master node identifiers from the matching database table; obtaining the second master node identifiers of each master node in the target cluster, and constructing a second correspondence between each of the first master node identifiers and each of the second master node identifiers.

[0013] In one embodiment, the target cluster includes multiple second shards and second configuration servers, each second shard and configuration server including one master node and multiple slave nodes; each master node in each second shard and second configuration server is configured with a second agent; after constructing the second correspondence between each first master node identifier and each second master node identifier, the method further includes: constructing a cluster recovery task based on each second correspondence; sending the cluster recovery task to the second agent configured in each second shard and second configuration server; the cluster recovery task is used for each second agent to obtain a first master node identifier corresponding to each second master node identifier; querying the database table based on each first master node identifier to obtain the backup file path corresponding to each second master node identifier; obtaining each backup file from the backup file path corresponding to each second master node identifier, and storing it in each master node corresponding to the second master node identifier.

[0014] Secondly, this application also provides a sharded cluster backup and recovery system, including: a backup server, and a first agent and a second agent communicatively connected to the backup server, wherein the first agent is set on different master nodes in the source cluster to be backed up, and the second agent is set on different master nodes in the target cluster used to restore backup files of the source cluster; wherein:

[0015] The backup server is configured to respond to a sharded cluster backup request by receiving backup files sent by each of the first agents, and receiving the backup file path corresponding to each of the backup files, as well as the first master node identifier corresponding to each of the first agents; and constructing a first correspondence between each of the first master node identifiers and each of the backup file paths.

[0016] The backup server is further configured to, in response to a sharded cluster recovery request for the source cluster, obtain the second master node identifier of each master node in the target cluster, and construct a second correspondence between each first master node identifier and each second master node identifier;

[0017] Each of the second agents is used to obtain each backup file from the backup file path corresponding to each of the second master nodes according to the second master node identifier corresponding to each master node in the target cluster, and the first correspondence and the second correspondence, and store it to each of the master nodes corresponding to the second master node identifier.

[0018] In one embodiment, the source cluster includes multiple first shards and a first configuration server, each first shard and the first configuration server including a master node and multiple slave nodes; each first agent is further configured to obtain a target slave node from the multiple slave nodes corresponding to each first agent, and obtain backup files from the target slave nodes respectively; send each of the backup files to the first agent corresponding to the first configuration server; the first agent corresponding to the first configuration server is configured to send each of the backup files to the backup server.

[0019] Thirdly, this application also provides a sharded cluster backup and recovery device, applied to a backup server, comprising:

[0020] The backup file acquisition module is used to respond to a sharded cluster backup request and acquire the backup files corresponding to each target slave node in the source cluster to be backed up; each target slave node corresponds to a different master node in the source cluster.

[0021] The first relationship construction module is used to obtain the backup file path corresponding to each of the backup files and the first master node identifier corresponding to each of the target slave nodes, and to construct a first correspondence between each first master node identifier and each of the backup file paths;

[0022] The second relationship construction module is used to respond to the sharded cluster recovery request for the source cluster, obtain the second master node identifier of each master node in the target cluster for restoring the backup files of the source cluster, and construct a second correspondence between each first master node identifier and each second master node identifier; the first correspondence and the second correspondence are used to obtain each backup file from the backup file path corresponding to each second master node identifier according to the second master node identifier corresponding to each master node in the target cluster, and the first correspondence and the second correspondence, and store it in each master node corresponding to the second master node identifier.

[0023] Fourthly, 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 as described in any embodiment of the first aspect.

[0024] 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 as described in any embodiment of the first aspect.

[0025] 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 as described in any embodiment of the first aspect.

[0026] The aforementioned sharded cluster backup and recovery method, system, apparatus, computer equipment, storage medium, and computer program product, in response to a sharded cluster backup request via a backup server, obtain backup files corresponding to each target slave node in the source cluster to be backed up; each target slave node corresponds to a different master node in the source cluster; obtain the backup file path corresponding to each backup file, and the first master node identifier corresponding to each target slave node, and construct a first correspondence between each first master node identifier and each backup file path; in response to a sharded cluster recovery request for the source cluster, obtain the second master node identifiers of each master node in the target cluster used to recover the backup files of the source cluster, and construct a second correspondence between each first master node identifier and each second master node identifier; the first and second correspondences are used to obtain each backup file from the backup file path corresponding to each second master node identifier according to the second master node identifier corresponding to each master node in the target cluster, and to store it in the master node corresponding to each second master node identifier. This application utilizes a backup server to obtain backup files corresponding to different master nodes for each target slave node during sharded cluster backup. Furthermore, it establishes a first correspondence between target slave nodes and their corresponding master node identifiers using the backup file paths and the first master node identifiers of the master nodes corresponding to those target slave nodes. During sharded cluster recovery, a second correspondence is established between the second master node identifiers of each master node in the target cluster and their corresponding first master node identifiers. Then, using both the first and second correspondences, backup files are retrieved from the backup file paths corresponding to the second master node identifiers and stored on the corresponding master nodes of the target clusters. This method enables the backup data of multiple nodes in the source cluster to be backed up to their respective master nodes in the target cluster, eliminating the need for users to remember the attributes of each backup file. Users only need to focus on the source and target clusters to perform the backup, thus reducing the complexity of sharded cluster backup and recovery. Attached Figure Description

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

[0028] Figure 1 This is a diagram illustrating the application environment of a sharded cluster backup and recovery method in one embodiment.

[0029] Figure 2 This is a flowchart illustrating a sharded cluster backup and recovery method in one embodiment;

[0030] Figure 3 This is a schematic diagram of the process for obtaining backup files in one embodiment;

[0031] Figure 4 This is a flowchart illustrating the process of constructing the second correspondence in one embodiment;

[0032] Figure 5 This is a schematic diagram of the structure of a sharded cluster backup and recovery system in one embodiment;

[0033] Figure 6 This is a diagram illustrating an application scenario of a MongoDB cluster backup and recovery method in one embodiment.

[0034] Figure 7 This is a schematic diagram of the backup workflow in one embodiment;

[0035] Figure 8 This is a schematic diagram of the backup service workflow in one embodiment;

[0036] Figure 9 This is a schematic diagram of the recovery workflow in one embodiment;

[0037] Figure 10 This is a structural block diagram of a sharded cluster backup and recovery device in one embodiment;

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

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

[0040] The sharded cluster backup and recovery method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, the backup server can communicate with servers in both the source and target clusters. Both the source and target clusters can contain multiple shards, designated as shard 1, shard 2, ..., shard n, and each shard contains multiple node servers, including one master node server and multiple slave node servers. Specifically, when the backup server receives a sharded cluster backup request for the source cluster, it responds to the request, obtaining the backup files corresponding to the target slave nodes of different master nodes in the source cluster, along with the backup file path and the first master node identifier for each backup file, thus establishing a first correspondence between the first master node identifier and the backup file path. Subsequently, if a sharded cluster recovery request is received, a second correspondence between the second master node identifiers of each master node in the target cluster and the first master node identifiers can be established. Finally, the backup file path corresponding to each second master node identifier can be obtained through the first and second correspondences. The corresponding backup file is then obtained through this backup file path and stored on the master node in the target cluster corresponding to each second master node identifier. The backup server and each node server can be implemented using independent servers.

[0041] In one embodiment, such as Figure 2 As shown, a sharded cluster backup and recovery method is provided, which can be applied to... Figure 1 Taking the backup server in the example, the following steps are included:

[0042] Step S201: In response to the sharded cluster backup request, obtain the backup files corresponding to each target slave node in the source cluster to be backed up; each target slave node corresponds to a different master node in the source cluster.

[0043] In this system, the backup server is used to provide sharded cluster backup services. The source cluster refers to the cluster that needs to be backed up. The sharded cluster backup request is a request to the backup server to perform a sharded cluster backup of the source cluster. This request can be triggered by a user and carries an identifier of the source cluster that needs to be backed up. The backup file is the file in the source cluster that needs to be backed up. This backup file can be provided by the target slave nodes in the source cluster that correspond to different master nodes.

[0044] For example, if the source cluster contains shard 1, shard 2, ..., shard n, since each shard contains a master node and multiple slave nodes, the corresponding backup files can be obtained from the target slave nodes of each shard as backup files for different shards, namely backup file 1, backup file 2, ..., backup file n.

[0045] Step S202: Obtain the backup file path corresponding to each backup file and the first master node identifier corresponding to each target slave node, and construct the first correspondence between each first master node identifier and each backup file path.

[0046] The backup file path is the file storage path used to store the different backup files mentioned above, while the first master node identifier is used to identify the master node corresponding to the slave node that provides the backup file. For example, if backup file 1 is provided by a slave node of shard 1 in the source cluster, its corresponding first master node identifier can be the master node identifier of shard 1. Similarly, if backup file 2 is provided by a slave node of shard 2 in the source cluster, its corresponding first master node identifier can be the master node identifier of shard 2. Then, a first correspondence can be established between each backup file path and its first master node identifier.

[0047] Step S203: In response to the sharded cluster recovery request for the source cluster, obtain the second master node identifier of each master node in the target cluster for the backup files used to restore the source cluster, and construct a second correspondence between each first master node identifier and each second master node identifier; the first correspondence and the second correspondence are used to obtain each backup file from the backup file path corresponding to each second master node identifier according to the second master node identifier corresponding to each master node in the target cluster, and the first correspondence and the second correspondence, and store it in each master node corresponding to the second master node identifier.

[0048] A sharded cluster recovery request is a request used to restore backup files from the source cluster. This request can also be triggered by a user and carries the identifier of the target cluster for restoring the backup files. The second master node identifier is the identifier of each master node in the target cluster. Similar to the source cluster, the target cluster can also contain multiple shards, and each shard contains one master node and multiple slave nodes. The second master node identifier identifies the different master nodes in the target cluster. After receiving a sharded cluster recovery request from the source cluster, the backup server can first determine the target cluster for restoring the backup files, and the second master node identifiers of each master node in the target cluster. Then, it can establish the correspondence between the different first master node identifiers and second master node identifiers.

[0049] For example, the first master node identifier may include the master node identifier of shard 1 and the master node identifier of shard 2 in the source cluster, and the second master node identifier may include the master node identifier of shard 1 and the master node identifier of shard 2 in the target cluster. The backup server may construct the correspondence between the master node identifier of shard 1 in the source cluster and the master node identifier of shard 1 in the target cluster, and the correspondence between the master node identifier of shard 2 in the source cluster and the master node identifier of shard 2 in the target cluster, as the second correspondence.

[0050] Once the first and second correspondences are established, the corresponding backup file paths can be queried based on the second master node identifier of each master node in the target cluster. For example, if the backup file path corresponding to the master node identifier of shard 1 in the target cluster is path 1, and backup file 1 is stored on this path, then backup file 1 can be stored on the master node of shard 1 in the target cluster. Similarly, if the backup file path corresponding to the master node identifier of shard 2 in the target cluster is path 2, and backup file 2 is stored on this path, then backup file 2 can be stored on the master node of shard 2 in the target cluster.

[0051] In the above-described sharded cluster backup and recovery method, the backup server responds to the sharded cluster backup request by obtaining the backup files corresponding to each target slave node in the source cluster to be backed up; each target slave node corresponds to a different master node in the source cluster; the backup file path corresponding to each backup file and the first master node identifier corresponding to each target slave node are obtained, and a first correspondence relationship is constructed between each first master node identifier and each backup file path; in response to the sharded cluster recovery request for the source cluster, the second master node identifier of each master node in the target cluster used to restore the backup files of the source cluster is obtained, and a second correspondence relationship is constructed between each first master node identifier and each second master node identifier; the first correspondence relationship and the second correspondence relationship are used to obtain each backup file from the backup file path corresponding to each second master node identifier according to the second master node identifier corresponding to each master node in the target cluster, and to store it in each master node corresponding to the second master node identifier. This application utilizes a backup server to obtain backup files corresponding to different master nodes for each target slave node during sharded cluster backup. Furthermore, it establishes a first correspondence between target slave nodes and their corresponding master node identifiers using the backup file paths and the first master node identifiers of the master nodes corresponding to those target slave nodes. During sharded cluster recovery, a second correspondence is established between the second master node identifiers of each master node in the target cluster and their corresponding first master node identifiers. Then, using both the first and second correspondences, backup files are retrieved from the backup file paths corresponding to the second master node identifiers and stored on the master nodes of the target clusters corresponding to those second master node identifiers. This method enables the backup data of multiple nodes in the source cluster to be backed up to the corresponding master nodes in the target cluster, eliminating the need for users to remember the attributes of each backup file. Users only need to focus on the source and target clusters to perform the backup, thus reducing the complexity of sharded cluster backup and recovery.

[0052] In one embodiment, the source cluster includes multiple first shards and first configuration servers, each first shard and first configuration server including one master node and multiple slave nodes; the master node included in each first shard and first configuration server is configured with a first agent; such as Figure 3 As shown, step S201 may further include:

[0053] Step S301: In response to the sharded cluster backup request, obtain the target slave node from the slave nodes corresponding to each first shard in the source cluster and the slave nodes contained in the first configuration server.

[0054] In this embodiment, the source cluster may consist of multiple shards, namely multiple first shards, and a configuration server, namely a first configuration server. Each first shard and the first configuration server may contain a master node server and multiple slave node servers. In addition, each master node server may also be configured with a proxy service, namely a first proxy, which can be used to perform backup tasks.

[0055] Specifically, when the backup server receives a sharded cluster backup request, it first needs to determine one of the slave nodes contained in each first shard and the first server in the source cluster as the target slave node.

[0056] For example, the source cluster includes shard 1, shard 2, and a configuration server. Each of shard 1, shard 2, and the configuration server contains one master node and two slave nodes. The backup server can be selected from the two slave nodes of shard 1, shard 2, and the configuration server to serve as the target slave node for each of the three shards.

[0057] Step S302: Generate a cluster backup task based on the target slave node, and send the cluster backup task to the first agent set by each first shard and the first configuration server; the cluster backup task is used by each first agent to obtain the target slave node from multiple slave nodes corresponding to each first agent, and obtain backup files from the target slave node respectively and send them to the backup server.

[0058] The cluster backup task is used to enable each first agent in the source cluster to perform file backups. After determining the target slave node, the backup server can generate a corresponding cluster backup task based on the target slave node and send it to the first agents set by each first shard and the first configuration server. Each first agent can then extract the backup files from the target slave node indicated in the cluster backup task and send them to the backup server. For example, for the first agent of shard 1, if the target slave node is slave node 1, then this first agent can obtain the backup files from slave node 1 of shard 1 and send them to the backup server. Similarly, for the first agent of shard 2, if the target slave node is slave node 1, then this first agent can obtain the backup files from slave node 1 of shard 2 and send them to the backup server.

[0059] In this embodiment, the backup server can also determine the target slave node corresponding to each first shard in the source cluster and the first configuration server, and generate a cluster backup task. Then, it can use the corresponding first agents to obtain backup files from the target slave node and send them. This method can reduce the workload of the backup server during the backup process and can realize synchronous backup of different shards, thereby improving the backup efficiency.

[0060] Furthermore, each first agent is also used to obtain the first master node identifier of the master node corresponding to each first agent, and to obtain the backup file path of the backup file corresponding to each first agent in the backup server; step S202 may further include: receiving the backup file path corresponding to each first agent and the first master node identifier corresponding to each first agent sent by each first agent.

[0061] In this embodiment, each first agent can not only send the corresponding backup files to the backup server for storage, but also obtain the corresponding backup path of the backup files during backup storage and send the backup path to the backup server, enabling the backup server to receive the backup file path of the backup files on the backup server. Simultaneously, the first master node identifier of each master node can also be sent to the backup server by the corresponding first agent. The first master node identifier can be sent during the backup of the source cluster or before the backup, for example, when configuring the first agent for each master node and after the first agent starts running. The backup server can then obtain the backup file path corresponding to each backup file and the first master node identifier corresponding to each target slave node by receiving the backup file paths and first master node identifiers sent by each first agent.

[0062] In this embodiment, the backup file path and the first master node identifier can also be actively sent to the backup server by the first agent, thereby further reducing the workload of the backup server.

[0063] In one embodiment, each first correspondence is stored in a database table; after step S202, the method may further include: writing each first correspondence into a database table and generating a database table identifier corresponding to the database table.

[0064] In this embodiment, the first correspondence can be stored in a database table, and the database table identifier is used to identify different database tables. After the backup server completes the construction of the first correspondence, it can write the first correspondence into the database table and manage the above-mentioned first correspondence through the database table. Then, the database table identifier corresponding to the database table can also be generated.

[0065] like Figure 4 As shown, step S203 may further include:

[0066] Step S401: In response to the sharded cluster recovery request, obtain the database table identifier that matches the sharded cluster recovery request;

[0067] Step S402: Obtain the database table that matches the database table identifier, and obtain the identifier of each first master node from the matching database table.

[0068] In this embodiment, after receiving a sharded cluster recovery request, the backup server can respond to the sharded cluster recovery request and determine the source cluster corresponding to the recovery request, thereby determining the corresponding database table identifier. Then, the database table identifier can be used to query the corresponding database table, thereby extracting the first master node identifier of each master node contained in the source cluster from the database table.

[0069] Step S403: Obtain the second master node identifier of each master node in the target cluster, and construct a second correspondence between each first master node identifier and each second master node identifier.

[0070] Afterwards, the backup server can also obtain the second master node identifiers of each master node in the target cluster. The second master node identifiers can be obtained and stored by the backup server in advance from the target cluster, or they can be obtained from the target cluster during the backup file recovery task. Then, a second correspondence between each first master node identifier and each second master node identifier can be constructed.

[0071] In this embodiment, the backup server can also store the first correspondence through a database table, and when performing backup and recovery, it can query the first master node identifiers contained in the first correspondence through the database table identifier to realize the construction of the second correspondence with the second master node identifier. This method can improve the efficiency of the second correspondence construction.

[0072] Furthermore, the target cluster includes multiple second shards and second configuration servers, each second shard and configuration server including one master node and multiple slave nodes; each second shard and second configuration server has a second agent configured in its master node; after step S403, the process may further include: constructing a cluster recovery task based on the corresponding relationships between the second shards and the second configuration servers; sending the cluster recovery task to the second agents configured in each second shard and the second configuration server; the cluster recovery task is used by each second agent to obtain the first master node identifier corresponding to each second master node identifier; querying a database table based on each first master node identifier to obtain the backup file path corresponding to each second master node identifier; obtaining each backup file from the backup file path corresponding to each second master node identifier and storing it in each master node corresponding to the second master node identifier.

[0073] Similar to the structure of the source cluster, the target cluster can also consist of multiple shards, i.e., second shards, and a configuration server, i.e., the second configuration server. Each second shard and the second configuration server can contain a master node server and multiple slave node servers. In addition, each master node server can also be configured with a proxy service, i.e., the second proxy, which can be used to perform recovery tasks.

[0074] Specifically, after the backup server completes the construction of the second mapping relationship, it can also use this relationship to construct corresponding cluster recovery tasks. These tasks are then sent to the second agents configured on each second shard and the second configuration server. These cluster recovery tasks enable each second agent in the target cluster to perform file recovery. Subsequently, each second agent can obtain its corresponding first master node identifier based on the second mapping relationship contained in the cluster recovery task and the second master node identifier of the master node it corresponds to. It then queries the database table using the first master node identifier to obtain the backup file path corresponding to each second master node identifier, and finally retrieves and stores the backup file from that path.

[0075] For example, for the second agent of target cluster shard 1, the second mapping record contains the correspondence between target cluster shard 1 and source cluster shard 1. This second agent can then use the identifier of source cluster shard 1 to query the database table, thereby obtaining backup file path 1. Therefore, the second agent can obtain backup file 1 from backup file path 1 and store backup file 1. Similarly, for the second agent of shard 2, the second mapping record contains the correspondence between target cluster shard 2 and source cluster shard 2. This second agent can then use the identifier of source cluster shard 2 to query the database table, thereby obtaining backup file path 2. Therefore, the second agent can obtain backup file 2 from backup file path 2 and store backup file 2.

[0076] In this embodiment, the backup server can also generate a cluster recovery task through a second correspondence. Each second agent obtains the first master node identifier of the corresponding source cluster master node based on the second correspondence, and queries a database table based on the first master node identifier to obtain the backup file path and retrieve the backup file. This method reduces the workload of the backup server during file recovery and enables synchronous recovery of different shards, improving recovery efficiency.

[0077] In one embodiment, such as Figure 5 As shown, a sharded cluster backup and recovery system is provided. This system may include: a backup server 501, and a first agent 502 and a second agent 503 communicatively connected to the backup server 501. The first agent 502 is configured on different master nodes in the source cluster to be backed up, and the second agent 503 is configured on different master nodes in the target cluster used to restore backup files from the source cluster.

[0078] Backup server 501 can respond to sharded cluster backup requests upon receipt, receiving backup files, their backup file paths, and the primary master node identifiers of their respective primary master nodes from the primary agents 502 located on different primary master nodes in the source cluster to be backed up. It can then construct a mapping between these primary master node identifiers and their backup file paths, establishing a primary mapping relationship.

[0079] Backup server 501 can also be used to determine the master node identifiers of each master node in the target cluster used to restore the backup files of the source cluster when it receives a sharded cluster recovery request for the source cluster. The second master node identifier is used to construct a correspondence between the second master node identifier and the first master node identifier as a second correspondence.

[0080] Each second agent 503 can obtain the backup file path that matches each second agent 503 based on the second master node identifier of each corresponding master node and the first and second correspondence relationships constructed by the backup server 501, thereby obtaining the corresponding backup file from the corresponding backup file path and storing it to the corresponding master node.

[0081] The aforementioned sharded cluster backup and recovery system includes: a backup server 501, and a first agent 502 and a second agent 503 communicatively connected to the backup server 501. The first agents 502 are configured on different master nodes in the source cluster to be backed up, and the second agents 503 are configured on different master nodes in the target cluster used to restore backup files from the source cluster. The backup server 501 responds to sharded cluster backup requests by receiving backup files sent by each of the first agents 502, receiving the backup file paths corresponding to each backup file, and the first master node identifiers corresponding to each of the first agents 502. The system identifies and establishes a first correspondence between each first master node identifier and each backup file path. Backup server 501 is further configured to respond to a sharded cluster recovery request for the source cluster, obtain the second master node identifiers of each master node in the target cluster, and establish a second correspondence between each first master node identifier and each second master node identifier. Each second agent 503 is configured to retrieve each backup file from the backup file path corresponding to each second master node identifier based on the second master node identifier corresponding to each master node in the target cluster, as well as the first and second correspondences, and store them on the corresponding master node. This embodiment, through a sharded cluster backup and recovery system, enables the backup data corresponding to multiple nodes in the source cluster to be backed up separately on the corresponding master nodes in the target cluster, without requiring the user to remember the attributes of each backup file. The user only needs to focus on the source and target clusters to achieve backup, thus reducing the complexity of sharded cluster backup and recovery.

[0082] In one embodiment, the source cluster includes multiple first shards and a first configuration server, each first shard and the first configuration server including a master node and multiple slave nodes; each first agent 502 is further configured to obtain a target slave node from the multiple slave nodes corresponding to each first agent 502, and obtain backup files from the target slave nodes respectively; send each backup file to the first agent corresponding to the first configuration server; the first agent corresponding to the first configuration server is configured to send each backup file to the backup server 501.

[0083] In this embodiment, the source cluster can consist of multiple shards, namely the first shard, and a configuration server, namely the first configuration server. Each first shard and the first configuration server can simultaneously contain one master node and multiple slave nodes. When each first agent 502 sends a backup file to the backup server 501, since the backup time of each backup file is uncertain, each first agent 502 needs to first determine the target slave node from among the multiple slave nodes corresponding to the first agent 502, obtain the backup file from the target slave node, and then send it to the first configuration server. The first configuration server then uniformly sends all configuration files to the backup server 501.

[0084] For example, the first agent 502 in the source cluster shard 1 obtains the backup file 1 from the target slave node of shard 1. After backing up the backup file 1, it needs to send the backup file 1 to the first configuration server. Similarly, the first agent 502 in the source cluster shard 2 obtains the backup file 2 from the target slave node of shard 2. After backing up the backup file 2, it needs to send the backup file 2 to the first agent corresponding to the first configuration server. Then, the first agent corresponding to the first configuration server integrates the backup file 1 and the backup file 2 and sends them to the backup server 501 for storage.

[0085] In this embodiment, after each first agent 502 obtains the backup file from the target slave node, it can first send the backup file to the first agent corresponding to the first configuration server, and then the first agent corresponding to the first configuration server sends it to the backup server 501 for storage. Compared with sending directly to the backup server 501, this method can realize the integration of backup files before sending, further improving the intelligence of sharded cluster backup.

[0086] In one embodiment, an automated backup and recovery method for a MongoDB sharded cluster is also provided. The MongoDB sharded cluster typically consists of multiple shards and a configuration service. Each shard and configuration service has a master-slave relationship. During backup, data is typically backed up from each slave node, which generates multiple backup files. During recovery, the corresponding backup data files need to be restored to the corresponding master node.

[0087] Therefore, during sharded cluster backup, each shard sends its own master node identifier and master-slave attributes. After the data backup of each shard is completed, the backup set records which master node's corresponding slave node the data belongs to, and marks the identifier of each master node in the source cluster onto the corresponding data. During recovery, the attribute information of the backup source cluster is first provided. Through selection calculation, the correspondence between the master node identifiers of the source cluster and the target cluster is obtained and sent to the corresponding shards in the target cluster. On the target cluster shards, the path of the data file is retrieved through the identifier of the master node in the source cluster, thus obtaining the file data corresponding to the master node of that shard, completing the recovery process.

[0088] This process can be applied to, for example... Figure 6 The application scenario shown depicts a source cluster with three shards and a configuration server, each containing three host nodes (one master and two slaves). The target cluster has a similar configuration, requiring the software system to install an agent on each host node and interconnect with the backup service.

[0089] During backup, backup data is retrieved from multiple slave nodes in the source cluster, and the retrieved backup files are uploaded to storage. Information is recorded in the backup set, which is uniquely indexed by its ID. During recovery, the backup set information is retrieved using this ID, and the files of each backup are found and restored to the target cluster.

[0090] Therefore, users only need to care about the source cluster and the target cluster, and which backup set of data to restore, without needing to worry about the internal configuration of each cluster or the correspondence between the shards of the source cluster and the target cluster.

[0091] Specifically, this can be achieved through the following process:

[0092] 1. Backup process

[0093] After each agent starts running, it sends its unique identifier and master / slave attributes to the backup service. When a backup is initiated, the backup service arbitrarily selects a slave node from each shard and sends a backup task. When an agent on a slave node receives the backup task, it retrieves the backup data from the slave node and sends it to the storage service. Simultaneously, it sends the path to the backup files on the storage service and the master node identifier corresponding to the slave node to the agent on the configuration service for aggregation. Once each agent's data backup is complete, the configuration service sends it to the backup service, which generates a backup set indexed by a unique ID for use during recovery. The workflow is as follows: Figure 7 As shown.

[0094] 2. Backup set design

[0095] Backup sets are generated by the backup service and indexed by a unique ID. The format design of the current backup set is shown in Table 1:

[0096] Table 1. Format of Backup Sets

[0097]

[0098] The backup set organization is designed as a database table that records the paths of all files generated during the backup process, as well as the master node identifier information of each shard in the source cluster. The backup file path can be queried by the master node identifier.

[0099] 3. The backup service's recovery process

[0100] Before initiating the recovery task, each host on the target cluster runs an agent service. After the agent starts running, it proactively sends its local node identifier and master-slave attributes to the backup service. When data needs to be recovered from the target cluster, the detailed contents of the backup set are retrieved using the backup set ID, as shown in Table 1. The source data to be recovered is obtained from the contents of Table 1, and then a one-to-one correspondence between the source cluster master node identifier and the target cluster master node identifier is established using the master node information of the target cluster, as shown in Table 2.

[0101] Table 2. Master Node Correspondence between Source Cluster and Target Cluster

[0102]

[0103] Subsequently, the backup service sends recovery tasks to the master node agent of the target cluster. Each recovery task contains the master node identifier of the source cluster and the master node identifier of the target cluster, indicating that data corresponding to a specific master node in the source cluster will be restored to the master node of the target cluster. The backup service's operation flow is as follows: Figure 8 As shown.

[0104] 4. Recovery process

[0105] After the target cluster's master node receives the recovery task, since the task contains the source cluster's master node identifier, it can look up Table 1 using the source cluster's master node identifier to obtain the specific path of the backup file, and then retrieve the corresponding data to restore to the target cluster's master node. The workflow is as follows: Figure 9 As shown.

[0106] The above embodiments overcome the need for users to manage multiple backup files generated after backup, organizing multiple backup files into a single backup set. This facilitates the generation, selection, and deletion of cluster backup sets and simplifies backup and recovery operations for MongoDB sharded clusters. Users only need to focus on backing up from a specific source cluster during backup and recovery, and only need to focus on restoring data from a specific backup set to a specific target cluster during recovery. This solution automatically handles the correspondence between source cluster data and target cluster nodes. Furthermore, it utilizes a general MongoDB interface to obtain cluster information, making it applicable to the backup and recovery of various MongoDB cluster versions.

[0107] 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 of other steps.

[0108] Based on the same inventive concept, this application also provides a sharded cluster backup and recovery apparatus for implementing the sharded cluster backup and recovery method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more sharded cluster backup and recovery apparatus embodiments provided below can be found in the limitations of the sharded cluster backup and recovery method described above, and will not be repeated here.

[0109] In one embodiment, such as Figure 10 As shown, a sharded cluster backup and recovery device is provided, applied to a backup server, including: a backup file acquisition module 1001, a first relationship construction module 1002, and a second relationship construction module 1003, wherein:

[0110] The backup file acquisition module 1001 is used to respond to the sharded cluster backup request and acquire the backup files corresponding to each target slave node in the source cluster to be backed up; each target slave node corresponds to a different master node in the source cluster.

[0111] The first relationship construction module 1002 is used to obtain the backup file path corresponding to each backup file and the first master node identifier corresponding to each target slave node, and to construct the first correspondence between each first master node identifier and each backup file path;

[0112] The second relationship construction module 1003 is used to respond to the sharded cluster recovery request for the source cluster, obtain the second master node identifier of each master node in the target cluster for the backup files used to restore the source cluster, and construct a second correspondence between each first master node identifier and each second master node identifier; the first correspondence and the second correspondence are used to obtain each backup file from the backup file path corresponding to each second master node identifier according to the second master node identifier corresponding to each master node in the target cluster, and the first correspondence and the second correspondence, and store it in each master node corresponding to the second master node identifier.

[0113] In one embodiment, the source cluster includes multiple first shards and a first configuration server, each first shard and the first configuration server including a master node and multiple slave nodes; each first shard and the first configuration server includes a master node with a first agent configured; the backup file acquisition module 1001 is further configured to, in response to a shard cluster backup request, acquire a target slave node from the slave nodes corresponding to each first shard in the source cluster and the slave nodes included in the first configuration server; generate a cluster backup task based on the target slave node, and send the cluster backup task to the first agent configured in each first shard and the first configuration server; the cluster backup task is used by each first agent to acquire the target slave node from the multiple slave nodes corresponding to each first agent, and acquire backup files from the target slave node respectively and send them to the backup server.

[0114] In one embodiment, each first agent is further configured to obtain the first master node identifier of the master node corresponding to each first agent, and to obtain the backup file path of the backup file corresponding to each first agent in the backup server; the first relationship construction module 1002 is further configured to receive the backup file path corresponding to each first agent and the first master node identifier corresponding to each first agent sent by each first agent.

[0115] In one embodiment, each first correspondence is stored in a database table; the first relationship construction module 1002 is further configured to write each first correspondence into the database table and generate a database table identifier corresponding to the database table; the second relationship construction module 1003 is further configured to, in response to a sharded cluster recovery request, obtain a database table identifier that matches the sharded cluster recovery request; obtain a database table that matches the database table identifier, and obtain each first master node identifier from the matching database table; obtain the second master node identifier of each master node in the target cluster, and construct a second correspondence between each first master node identifier and each second master node identifier.

[0116] In one embodiment, the target cluster includes multiple second shards and second configuration servers, each second shard and configuration server including one master node and multiple slave nodes; each master node in each second shard and second configuration server is configured with a second agent; the second relationship construction module 1003 is further configured to construct a cluster recovery task based on each second correspondence relationship; send the cluster recovery task to the second agent configured in each second shard and second configuration server; the cluster recovery task is configured for each second agent to obtain a first master node identifier corresponding to each second master node identifier based on the cluster recovery task; query a database table based on each first master node identifier to obtain the backup file path corresponding to each second master node identifier; obtain each backup file from the backup file path corresponding to each second master node identifier, and store it in each master node corresponding to the second master node identifier.

[0117] Each module in the aforementioned sharded cluster backup and recovery device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to 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 11 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, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores backup file data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a fragmented cluster backup and recovery method.

[0119] Those skilled in the art will understand that Figure 11 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 embodiment, a computer device is also 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 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 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. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile 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, 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 specification.

[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 sharded cluster backup and recovery method, characterized in that, Applied to a backup server, the method includes: In response to a sharded cluster backup request, the backup files corresponding to each target slave node in the source cluster to be backed up are obtained; each target slave node corresponds to a different master node in the source cluster. Obtain the backup file path corresponding to each of the backup files, and the first master node identifier corresponding to each of the target slave nodes, and construct a first correspondence between each first master node identifier and each of the backup file paths; the backup file path is the path of the backup file in the backup server, and the first master node identifier is used to identify the slave node providing the backup file and the corresponding master node; In response to a sharded cluster recovery request for the source cluster, the second master node identifier of each master node in the target cluster used to restore the backup files of the source cluster is obtained, and a second correspondence between each first master node identifier and each second master node identifier is constructed. The second master node identifier is used to identify different master nodes in the target cluster. The first correspondence and the second correspondence are used to obtain each backup file from the backup file path corresponding to each second master node identifier according to the second master node identifier corresponding to each master node in the target cluster, and the first correspondence and the second correspondence, and store them in each master node corresponding to the second master node identifier.

2. The method according to claim 1, characterized in that, The source cluster includes multiple first shards and first configuration servers. Each first shard and first configuration server includes one master node and multiple slave nodes. Each first shard and first configuration server has a first agent configured in its master node. The step of responding to a sharded cluster backup request by obtaining the backup files corresponding to each target slave node in the source cluster to be backed up includes: In response to the sharded cluster backup request, the target slave node is obtained from the slave nodes corresponding to each of the first shards in the source cluster and from the slave nodes included in the first configuration server; A cluster backup task is generated based on the target slave node, and the cluster backup task is sent to the first agent set by each first shard and the first configuration server; the cluster backup task is used by each first agent to obtain the target slave node from multiple slave nodes corresponding to each first agent, and obtain backup files from the target slave node respectively and send them to the backup server.

3. The method according to claim 2, characterized in that, Each of the first agents is further configured to obtain the first master node identifier of the master node corresponding to each of the first agents, and to obtain the backup file path of the backup file corresponding to each of the first agents in the backup server; The step of obtaining the backup file path corresponding to each of the backup files and the first master node identifier corresponding to each of the target slave nodes includes: Receive the backup file path corresponding to each of the first agents, and the first master node identifier corresponding to each of the first agents.

4. The method according to claim 1, characterized in that, Each of the first correspondences is stored in a database table; After establishing the first correspondence between each of the first master node identifiers and each of the backup file paths, the method further includes: Each of the first correspondences is written into a database table, and a database table identifier corresponding to the database table is generated; the database table identifier is used to identify different database tables. In response to a sharded cluster recovery request for the source cluster, the process of obtaining the second master node identifiers of each master node in the target cluster from the backup files used to restore the source cluster, and constructing a second correspondence between each first master node identifier and each second master node identifier, includes: In response to the sharded cluster recovery request, obtain the database table identifier that matches the sharded cluster recovery request; Obtain the database table that matches the database table identifier, and obtain the identifiers of each first master node from the matching database table; Obtain the second master node identifier of each master node in the target cluster, and construct a second correspondence between each first master node identifier and each second master node identifier.

5. The method according to claim 4, characterized in that, The target cluster includes multiple second shards and second configuration servers. Each second shard and configuration server includes one master node and multiple slave nodes. Each second shard and second configuration server has a second agent configured in the master node. After constructing the second correspondence between each of the first master node identifiers and each of the second master node identifiers, the method further includes: Based on the second correspondence, construct a cluster recovery task; The cluster recovery task is sent to the second agent set up by each second shard and the second configuration server; the cluster recovery task is used by each second agent to obtain the first master node identifier corresponding to each second master node identifier; query the database table based on each first master node identifier to obtain the backup file path corresponding to each second master node identifier; obtain each backup file from the backup file path corresponding to each second master node identifier, and store it in each master node corresponding to the second master node identifier.

6. A sharded cluster backup and recovery system, characterized in that, The system includes: a backup server, and a first agent and a second agent communicatively connected to the backup server, wherein the first agent is configured on different master nodes in the source cluster to be backed up, and the second agent is configured on different master nodes in the target cluster used to restore backup files from the source cluster; wherein: The backup server is configured to respond to a sharded cluster backup request by receiving backup files sent by each of the first agents, and receiving the backup file paths corresponding to each of the backup files, as well as the first master node identifiers corresponding to each of the first agents; constructing a first correspondence between each of the first master node identifiers and each of the backup file paths; the backup file path is the path of the backup file in the backup server, and the first master node identifier is used to identify the slave node providing the backup file and the corresponding master node; The backup server is further configured to, in response to a sharded cluster recovery request for the source cluster, obtain the second master node identifier of each master node in the target cluster, and construct a second correspondence between each first master node identifier and each second master node identifier; the second master node identifier is used to identify different master nodes in the target cluster. Each of the second agents is used to obtain each backup file from the backup file path corresponding to each of the second master nodes according to the second master node identifier corresponding to each master node in the target cluster, and the first correspondence and the second correspondence, and store it to each of the master nodes corresponding to the second master node identifier.

7. The system according to claim 6, characterized in that, The source cluster includes multiple first shards and first configuration servers, and each first shard and first configuration server includes one master node and multiple slave nodes; Each of the first agents is further configured to obtain a target slave node from a plurality of slave nodes corresponding to each of the first agents, and obtain backup files from the target slave nodes respectively; and send each of the backup files to the first agent corresponding to the first configuration server; The first agent corresponding to the first configuration server is used to send each of the backup files to the backup server.

8. A sharded cluster backup and recovery device, characterized in that, The apparatus, used in backup servers, includes: The backup file acquisition module is used to respond to a sharded cluster backup request and acquire the backup files corresponding to each target slave node in the source cluster to be backed up; each target slave node corresponds to a different master node in the source cluster. The first relationship construction module is used to obtain the backup file path corresponding to each of the backup files and the first master node identifier corresponding to each of the target slave nodes, and to construct a first correspondence between each first master node identifier and each of the backup file paths; the backup file path is the path of the backup file in the backup server, and the first master node identifier is used to identify the slave node providing the backup file and the corresponding master node; The second relationship construction module is used to respond to a sharded cluster recovery request for the source cluster, obtain the second master node identifier of each master node in the target cluster for restoring backup files of the source cluster, and construct a second correspondence between each first master node identifier and each second master node identifier; the second master node identifier is used to identify different master nodes of the target cluster, and the first correspondence and the second correspondence are used to obtain each backup file from the backup file path corresponding to each second master node identifier according to the second master node identifier corresponding to each master node in the target cluster, and the first correspondence and the second correspondence, and store it in each master node corresponding to the second master node identifier.

9. 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 5.

10. 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 5.

Citation Information

Patent Citations

  • Cloud backup system and data backup method thereof

    CN103873501A

  • Hadoop cluster file backup system and method

    CN111382137A