Data recovery method, device, storage medium and electronic device

Abstract

The present application relates to the field of data processing technology, and specifically provides a method, device, storage medium and electronic device for data recovery. The method is applied to a monitoring node and may include: obtaining a node recovery weight value of data anomaly information of a cluster failure, wherein the node recovery weight value represents the node resources of at least one sub-node required to recover the failure; according to a pre-acquired recovery configuration parameter, sending the node recovery weight value to each of the at least one sub-node, so that each sub-node can recover the data anomaly information based on the node recovery weight value; wherein the recovery configuration parameter is generated by each sub-node based on the data anomaly information. Some embodiments of the present application can achieve effective data recovery while ensuring the normal operation of data services.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a method, device, storage medium and electronic device for data recovery. Background Art

[0002] When a traditional distributed storage cluster has a node failure, if the failure needs to be recovered, the node needs to suspend business processing, which greatly affects the business processing efficiency.

[0003] At present, compared with traditional storage server clusters, new distributed storage clusters have a relatively high tolerance for failures in a small number of devices or even a small number of storage nodes, and can perform normal business processing while recovering from failures. However, restoring failures to normal status requires occupying the internal resources of the node, so how to balance data recovery and normal business processing has become a technical problem that needs to be solved urgently. Summary of the invention

[0004] The purpose of some embodiments of the present application is to provide a method, device, storage medium and electronic device for data recovery. The technical solutions of the embodiments of the present application can balance data recovery and normal business processing, and effective data recovery is achieved while ensuring normal data business processing.

[0005] In a first aspect, some embodiments of the present application provide a method for data recovery, applied to a monitoring node, comprising: obtaining a node recovery weight value of data anomaly information of a cluster failure, wherein the node recovery weight value represents the node resources of at least one sub-node required to recover the failure; sending the node recovery weight value to each sub-node of the at least one sub-node according to pre-acquired recovery configuration parameters, so that each sub-node can recover the data anomaly information based on the node recovery weight value; wherein the recovery configuration parameters are generated by each sub-node based on the data anomaly information.

[0006] After obtaining the node recovery weight value corresponding to the node resource required for fault recovery, some embodiments of the present application send the node recovery weight value to each child node according to the recovery configuration parameter, so as to use the corresponding node resource to recover the data anomaly information of the fault, and during the recovery process, the business on the child node can be processed normally. The embodiments of the present application can balance data recovery and normal business processing, and realize effective data recovery while ensuring the normal processing of data business.

[0007] In some embodiments, before obtaining the node recovery weight value of the data anomaly information of the cluster failure, the method also includes: collecting the data anomaly information when it is confirmed that the failure existing in the cluster is recoverable; calculating the data anomaly information according to a preset weight value rule to obtain a basic weight value; and adjusting the basic weight value based on the business processing level of the cluster to obtain the node recovery weight value.

[0008] Some embodiments of the present application calculate the basic weight value for data anomaly information through preset weight value rules, and then adjust the node recovery weight value based on the business processing level, so as to reasonably allocate node resources and complete data recovery while ensuring the normal processing of sub-node business.

[0009] In some embodiments, during the process of recovering the data anomaly information, the method further includes: receiving the data recovery progress fed back by the respective child nodes, and regularly updating the node recovery weight value based on the cluster parameters and the data recovery progress, and obtaining an updated weight value, wherein the updated weight value is used to regularly adjust the node resources of the at least one child node.

[0010] Some embodiments of the present application periodically update node recovery weight values ​​through data recovery progress and cluster parameters to ensure reasonable allocation of node resources.

[0011] In the second aspect, some embodiments of the present application provide a method for data recovery, which is applied to any child node, and the any child node is one of at least one child node in the fault recovery task; including: generating recovery configuration parameters based on the data anomaly information of the fault sent by the monitoring node; sending the recovery configuration parameters to the monitoring node; receiving the node recovery weight value sent by the monitoring node, and using the node resources corresponding to the node recovery weight value to recover the data anomaly information.

[0012] In some embodiments of the present application, any child node generates a recovery configuration parameter through data anomaly information, and then the monitoring node, after determining the node recovery weight value, can send the recovery configuration parameter to any corresponding child node to call the corresponding node resource for data recovery. The embodiments of the present application can balance data recovery and normal business processing, and realize effective data recovery while ensuring normal data business processing.

[0013] In some embodiments, generating recovery configuration parameters based on data anomaly information of a fault sent by a monitoring node includes: obtaining data correlation between the data anomaly information and any of the child nodes; and determining the recovery configuration parameters through the data anomaly information and the data correlation.

[0014] Some embodiments of the present application determine reply configuration parameters through data anomaly information and data correlation, so as to achieve rational utilization of node resources.

[0015] In some embodiments, during the data anomaly information recovery process, the method further includes: dynamically adjusting the node recovery weight value and the business processing weight value based on the node task queue, wherein the sum of the node recovery weight value and the business processing weight value is a fixed value.

[0016] Some embodiments of the present application dynamically adjust the node recovery weight value and the business processing weight value through the task queue, so as to achieve the reasonable allocation of node resources and ensure that the business processing and data recovery are carried out in a reasonable and orderly manner.

[0017] In some embodiments, after the data anomaly information is recovered using the node resources corresponding to the node recovery weight value, the method further includes: sending the data recovery progress of the data anomaly information to the monitoring node, so that the monitoring node periodically updates the node recovery weight value based on cluster parameters and the data recovery progress to obtain an updated weight value; receiving the updated weight value; and adjusting the node resources using the updated weight value to complete the recovery of the data anomaly information.

[0018] Some embodiments of the present application send data recovery progress to the monitoring node, so that the monitoring node can determine the update weight value, dynamically adjust the node resources, and complete data recovery. This can achieve reasonable allocation of node resources and ensure that business processing and data recovery are carried out in a reasonable and orderly manner.

[0019] In a third aspect, some embodiments of the present application provide a data recovery device, applied to a monitoring node, comprising: an acquisition module, used to obtain a node recovery weight value of data anomaly information of a cluster failure, wherein the node recovery weight value represents the node resources of at least one sub-node required to recover the failure; a sending module, used to send the node recovery weight value to each sub-node of the at least one sub-node according to a pre-acquired recovery configuration parameter, so that each sub-node can recover the data anomaly information based on the node recovery weight value; wherein the recovery configuration parameter is generated by each sub-node based on the data anomaly information.

[0020] In a fourth aspect, some embodiments of the present application provide a data recovery device, which is applied to any child node, and the any child node is one of at least one child node in a fault recovery task; it includes: a generation module, which is used to generate recovery configuration parameters based on the data anomaly information of the fault sent by the monitoring node; a sending module, which is used to send the recovery configuration parameters to the monitoring node; a recovery module, which is used to receive a node recovery weight value sent by the monitoring node, and use the node resources corresponding to the node recovery weight value to recover the data anomaly information.

[0021] In a fifth aspect, some embodiments of the present application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the method described in any embodiment of the first aspect.

[0022] In a sixth aspect, some embodiments of the present application provide an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement a method as described in any embodiment of the first aspect.

[0023] In a seventh aspect, some embodiments of the present application provide a computer program product, wherein the computer program product comprises a computer program, wherein the computer program, when executed by a processor, can implement the method described in any embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions of some embodiments of the present application, the drawings required for use in some embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0025] Figure 1 A system diagram of data recovery provided for some embodiments of the present application;

[0026] Figure 2 One of the flow charts of the data recovery method provided in some embodiments of the present application;

[0027] Figure 3 A second flow chart of a method for data recovery provided in some embodiments of the present application;

[0028] Figure 4 A third flowchart of a method for data recovery provided in some embodiments of the present application;

[0029] Figure 5One of the block diagrams of the data recovery device provided in some embodiments of the present application;

[0030] Figure 6 The second block diagram of the data recovery device provided in some embodiments of the present application;

[0031] Figure 7 A schematic diagram of an electronic device is provided for some embodiments of the present application. DETAILED DESCRIPTION

[0032] The technical solutions in some embodiments of the present application will be described below in conjunction with the drawings in some embodiments of the present application.

[0033] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0034] Because in the current distributed storage cluster, when a node failure or a device failure under a node occurs, the business can be processed normally while data recovery is performed. Based on this, some embodiments of the present application propose a method for data recovery, in which the monitoring node can perform a fault level assessment on the data anomaly information of the sending fault, and determine the node recovery weight value of the node resources required for fault recovery; the child node can determine the recovery configuration parameter through the data anomaly information, and the recovery configuration parameter can characterize the amount of data recovery tasks that the child node can carry. After that, the monitoring node can send a recovery weight value to each child node according to the recovery configuration parameter, and the child node can determine its own node resources for fault recovery according to the recovery weight value, and then perform the recovery task. In the process of data recovery, the node recovery weight value can be dynamically adjusted according to the processing progress of data recovery and the status of the task sequence of the child node, so as to complete the fault recovery. Some embodiments of the present application can reasonably allocate node resources and complete the recovery task of data anomaly information without affecting normal business processing, so as to ensure the stable and reliable operation of the cluster.

[0035] The following is combined with Figure 1 The overall composition structure of the data recovery system provided by some embodiments of the present application is exemplified.

[0036] like Figure 1As shown, some embodiments of the present application provide a data recovery system, which includes: a monitoring node 100 and a first sub-node 101, a second sub-node 102...the Nth sub-node. Among them, the monitoring node 100 can be composed of some nodes in the cluster, and it can monitor other nodes in the cluster (such as the first sub-node 101, the second sub-node 102...the Nth sub-node), collect the group status abstract map Map uploaded by each node, and determine whether each node has a fault, so as to maintain the normal operation of the cluster. The first sub-node 101, the second sub-node 102...the Nth sub-node is used to process the tasks issued. Each node corrects the Map composed of other nodes according to its own health or network conditions, allocates its own memory management, and performs operations such as data exchange, verification and calculation in the cluster based on the current status.

[0037] In some embodiments of the present application, when the monitoring node 100 detects a fault in the cluster, it can calculate the node recovery weight value required to recover the fault and distribute it to normal child nodes, so that the child nodes can provide corresponding resources based on the node recovery weight value to perform fault recovery tasks. At the same time, the remaining resources of the child nodes can normally handle other services. By monitoring the cluster status through the monitoring node 100, determining the node recovery weight and allocating it to each child node, the reasonable use of node resources can be achieved.

[0038] In some embodiments of the present application, the value of N can be set according to actual conditions, and the embodiments of the present application are not specifically limited here.

[0039] The following is combined with Figure 2 The implementation process of data recovery performed by the monitoring node 100 provided in some embodiments of the present application is exemplified.

[0040] Please see attached Figure 2 , Figure 2 A flow chart of a method for data recovery is provided for some embodiments of the present application. The method for data recovery may include:

[0041] S210, obtaining a node recovery weight value of data anomaly information of a cluster failure, wherein the node recovery weight value represents a node resource of at least one sub-node required to recover the failure.

[0042] For example, in some embodiments of the present application, the monitoring node 100 can evaluate the level of the fault to determine the node recovery weight value. The node recovery weight value can be adjusted in real time according to factors such as the cluster load status, time and task priority; the larger the node recovery weight value, the more node resources the corresponding recovery task operation will obtain.

[0043] In some embodiments of the present application, before executing S210, the data recovery method may include: when confirming that the fault existing in the cluster is recoverable, collecting the data anomaly information; calculating the data anomaly information according to a preset weight value rule to obtain a basic weight value; based on the business processing level of the cluster, adjusting the basic weight value to obtain the node recovery weight value.

[0044] For example, in some embodiments of the present application, when a fault is detected in the storage cluster and it is a recoverable fault, the monitoring node 100 first collects the data anomaly information, and evaluates the fault level to obtain a basic weight value. Among them, the preset weight value rule includes the possible faults in the cluster and the corresponding relationship with the weight value. For example, the fault of "the cluster will collapse if another disk is damaged" is obviously more serious than the fault of "the failure of two nodes can be tolerated". At this time, the basic weight value of the fault of "the cluster will collapse if another disk is damaged" can be 40%, and the basic weight value of the fault of "the failure of two nodes can be tolerated" can be 8%. The preset weight value rule can be determined and processed after multiple summaries based on the actual fault situation of the cluster, or it can be set by relevant personnel, and the embodiments of the present application are not specifically limited here.

[0045] After obtaining the basic weight value, the weight value of the recovery operation can be corrected again according to parameters such as whether the current moment is in the peak business period, the expected recovery time, etc., to obtain the node recovery weight value. Specifically, "whether the current moment is in the peak business period" can be determined according to a pre-set comparison table to obtain the business processing level. For example, the business processing level is divided as follows: the business volume from 8:00 to 9:00 in the morning is general, not particularly busy, and is regarded as the first business level; the business volume from 9:00 to 11:00 is large and very busy, and is regarded as the second business level, and so on. Among them, whether it is busy can be determined by the amount of business volume in the current period. For example, multiple thresholds are set, and the business volume is divided into multiple levels within different threshold ranges, such as less, general, more, and very much. Among them, generally corresponds to the first business level, and very much corresponds to the second business level. Or, it is determined based on the occupancy rate of cluster resources. For example, multiple thresholds are set, and cluster resources are divided into multiple levels within different threshold ranges. For example, if the occupancy rate exceeds 80%, it is very busy, and the business processing level is the second business level. Different service levels correspond to different weight values. The basic weight value can be modified according to the current cluster situation to obtain the node recovery weight value.

[0046] In addition to considering whether the business is in peak hours and whether it is busy, other factors such as expected recovery time can also be considered; by comprehensively analyzing multiple factors (for example, setting different weight values ​​according to the importance of each factor), the business processing level is determined, and then the basic weight value is effectively corrected to achieve reasonable use of resources. It should be understood that the embodiments of the present application are not limited to this.

[0047] S220, according to the pre-acquired recovery configuration parameters, sending the node recovery weight value to each child node in the at least one child node, so that each child node can recover the data anomaly information based on the node recovery weight value; wherein the recovery configuration parameters are generated by each child node based on the data anomaly information.

[0048] For example, in some embodiments of the present application, the monitoring node 100 can send data anomaly information to each child node, and each child node determines the amount of recovery tasks it can bear based on its own resources and determines the recovery configuration parameters. The monitoring node 100 can send the node recovery weight to each corresponding child node according to the recovery configuration parameters, so that each child node can receive the recovery task that matches its recovery configuration parameters, thereby achieving orderly and effective recovery of data.

[0049] In some embodiments of the present application, during the process of recovering the data anomaly information, the data recovery method may include: receiving the data recovery progress fed back by the respective child nodes, and regularly updating the node recovery weight value based on the cluster parameters and the data recovery progress, and obtaining an updated weight value, wherein the updated weight value is used to regularly adjust the node resources of the at least one child node.

[0050] For example, in some embodiments of the present application, the data recovery status (as a specific example of data recovery progress) will be reported to the monitoring node 100 by each child node in real time. The monitoring node 100 calculates and updates the weight value in real time based on the cluster parameters and data recovery status, and re-issues it to each child node regularly. For example, if the storage cluster has a large number of write demands at a certain point in time, it will decide whether to reduce the data recovery weight and increase the business weight depending on the current severity of the fault to ensure the effective processing of recovery tasks and business tasks. By updating the weight regularly, this regular cycle will continue until the fault is completely recovered, at which time the recovery weight will be reset to 0.

[0051] The following is combined with Figure 3 The implementation process of data recovery performed by any sub-node provided by some embodiments of the present application is exemplarily described, wherein any sub-node is a normal sub-node among the first sub-node 101, the second sub-node 102, ... the Nth sub-node.

[0052] Please see attached Figure 3 , Figure 3 A flow chart of a method for data recovery is provided for some embodiments of the present application. The method for data recovery may include:

[0053] S310, generating recovery configuration parameters based on the data anomaly information of the fault sent by the monitoring node.

[0054] For example, in some embodiments of the present application, after collecting data anomaly information, the monitoring node 100 uniformly sends the data anomaly information to normal sub-nodes in the cluster. Any of the normal sub-nodes will generate recovery configuration parameters according to its own business resource situation and data anomaly information.

[0055] In some embodiments of the present application, S310 may include: obtaining the data correlation between the data anomaly information and any of the child nodes; and determining the recovery configuration parameters through the data anomaly information and the data correlation.

[0056] For example, in some embodiments of the present application, any child node uses an algorithm (such as a DHT algorithm) to calculate the network topology between nodes, and obtains the distance between each failed node (i.e., the failed node) and itself under the current network topology. And consider the correlation between the current node (i.e., any child node) and the data anomaly information (as a specific example of data correlation) to determine the recovery configuration parameters. For example, the correlation may refer to: whether any child node carries a copy of the failed data block in the case of replica disaster recovery, whether there is a check block with the same stripe as the failed data block in the case of erasure code disaster recovery, etc. The recovery configuration parameters may include the amount of data that can be carried for the recovery task, and which part of the data in the data anomaly information can be recovered, etc.

[0057] For example, node k (as a specific example of any child node) processes the broadcasted exception list (as a specific example of data exception information): the damaged data block is A0bx980b1 (i.e., the storage code of the data block) before abstraction. It is known from HASHMAP that node k stores its copy (such as the xxx placement group stored in drive 1). The node where the data anomaly is located is n, and the topological distance from k is 2. f(2):xxx is put into the recovery queue of storage pool A; the next damaged data block has no copy in node k, so it is skipped; traverse in this way, divide the queues into different storage pools, summarize the queues and f(n) of each queue, and send them to the monitoring node 100 as the recovery configuration parameters. For example, the queues are: queA:[f(2):xxx, f(1):yyy,--.]; queB:[f(1):bbb, f(1):yxd,...], etc.

[0058] S320: Send the recovery configuration parameters to the monitoring node.

[0059] For example, in some embodiments of the present application, any child node sends recovery configuration parameters to the monitoring node 100 .

[0060] S330, receiving a node recovery weight value sent by a monitoring node, and using node resources corresponding to the node recovery weight value to recover the data anomaly information.

[0061] For example, in some embodiments of the present application, after any child node receives a node recovery weight value, based on the amount of data carried by the device (e.g., a drive) under the child node and the relevance of the recovered data, a data recovery task is assigned to the device based on the node recovery weight value, so that the drive uses corresponding resources to perform the data recovery task.

[0062] In some embodiments of the present application, during the process of recovering the data anomaly information, the data recovery method may include: dynamically adjusting the node recovery weight value and the business processing weight value based on the node task queue, wherein the sum of the node recovery weight value and the business processing weight value is a fixed value.

[0063] For example, in some embodiments of the present application, in order to ensure the normal operation of normal business, the sum of the node recovery weight value and the initial value of the business weight is a fixed value, and the size relationship determines what type of task will have a higher priority to enter the task queue. If the current recovery weight is high, the next task of the device to enter the task queue must be a recovery task. In other words, during the task processing process, the node recovery weight value and the business processing weight value can be compared. Whichever value is higher, the task will be prioritized in the front of the queue, and the task with the higher weight value will be processed first.

[0064] At the same time, the business tasks that intend to join the queue are broadcasted in the data placement group or the local business priority driver group to find the driver that can process the business under the child node, so as to avoid the business from entering the waiting queue of the device as much as possible. As the recovery or normal business tasks are queued, the corresponding weight will be reduced by a fixed task characteristic value; as the task queue expands, the current weight value will alternately decrease. For example, when a recovery task is queued, the business processing weight value decreases by a fixed task characteristic value; similarly, when a normal business is queued, the recovery weight value decreases by a fixed task characteristic value. The task characteristic value can be set according to the actual application scenario. For example, when the business processing weight value is higher than the node recovery weight value, the business is placed in the task queue when the business task is assigned, and the recovery task is placed in the waiting queue. After the business task is queued, the business processing weight value decreases by a task characteristic value. The same is true for the processing of node recovery weight values ​​and recovery tasks.

[0065] When any weight value (recovery weight value and business weight value) is less than the task characteristic value, the corresponding flag is set to 1, and the two flags are judged by '&' operation; if the true value is returned, the driver daemon will automatically interrupt the weight allocation of the recovery task and business task, reset the weight, flag and other parameters, and start the next round of queuing process (i.e., the re-division of the task queue). In addition, the allocation process can also be interrupted by the monitoring node 100 re-issuing the update weight and other operations.

[0066] In some embodiments of the present application, after executing S330, the data recovery method may include: sending the data recovery progress of the data anomaly information to the monitoring node, so that the monitoring node periodically updates the node recovery weight value based on the cluster parameters and the data recovery progress, and obtains the updated weight value; receiving the updated weight value; and using the updated weight value to adjust the node resources to complete the recovery of the data anomaly information.

[0067] For example, in some embodiments of the present application, any child node can report the data recovery status to the monitoring node 100 in real time, so that the monitoring node 100 can regularly update the node recovery weight based on the current cluster status, so that any child node can allocate resources more reasonably and complete the data recovery task. The above weight update process is cyclic until the fault is completely recovered, at which time the recovery weight will be reset to 0. This method can balance the processing resources of the cluster, complete fault recovery while ensuring normal business processing, and has high reliability.

[0068] The following is combined with Figure 4 The specific process of data recovery provided by some embodiments of the present application is exemplified.

[0069] Please see attached Figure 4 , Figure 4 A flow chart of a method for data recovery is provided for some embodiments of the present application.

[0070] It should be noted that, in order to facilitate the description of the implementation process of data recovery of the present application, the above process is described below by taking the interaction between the monitoring node 100 and the first sub-node 101 as an example.

[0071] S401, when the monitoring node 100 confirms that the failure in the cluster is recoverable, it collects data abnormality information.

[0072] S402, the monitoring node 100 calculates the data anomaly information according to a preset weight value rule to obtain a basic weight value.

[0073] S403 , the monitoring node 100 sends data anomaly information to the first child node 101 .

[0074] S404: The first subnode 101 determines data recovery relevance based on the data anomaly information.

[0075] S405: The first subnode 101 determines recovery configuration parameters based on the data anomaly information and data recovery relevance.

[0076] S406 , the first child node 101 sends the recovery configuration parameters to the monitoring node 100 .

[0077] S407, the monitoring node 100 adjusts the basic weight value based on the business processing level of the cluster to obtain a node recovery weight value.

[0078] S408 , the monitoring node 100 sends the node recovery weight value to the first child node 101 according to the recovery configuration parameters.

[0079] S409: The first subnode 101 allocates data recovery tasks to corresponding node resources for recovery based on the node recovery weight value.

[0080] S410, the first child node 101 dynamically adjusts the node recovery weight value and the business processing weight value based on the node task queue, and continues to execute the data recovery task.

[0081] S411 , the first child node 101 sends data recovery progress to the monitoring node 100 .

[0082] S412, the monitoring node 100 periodically updates the node recovery weight value based on the cluster parameters and data recovery progress, and obtains the updated weight value.

[0083] S413, the first child node 101 receives the updated weight value, and uses the updated weight value to adjust the node resources to complete the recovery of the data anomaly information.

[0084] It can be understood that the specific implementation process of S401~S413 can refer to the method embodiment provided above, and in order to avoid repetition, the detailed description is appropriately omitted here.

[0085] It can be seen from some of the embodiments of the present application described above that the present application implements self-management of fault recovery of a distributed storage cluster through the cluster's own conditions, and effectively improves the reliability of data recovery while ensuring the normal progress of data services.

[0086] Please refer to Figure 5 , Figure 5 The block diagram of the data recovery device provided by some embodiments of the present application is shown. It should be understood that the data recovery device corresponds to the above method embodiment and can execute each step involved in the above method embodiment. The specific functions of the data recovery device can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here.

[0087] Figure 5 The data recovery device includes at least one software function module that can be stored in a memory in the form of software or firmware or solidified in the data recovery device. The data recovery device is applied to a monitoring node, including: an acquisition module 510, used to obtain a node recovery weight value of data anomaly information of a cluster failure, wherein the node recovery weight value represents the node resources of at least one sub-node required to recover the failure; a sending module 520, used to send the node recovery weight value to each sub-node of the at least one sub-node according to a pre-acquired recovery configuration parameter, so that each sub-node can recover the data anomaly information based on the node recovery weight value; wherein the recovery configuration parameter is generated by each sub-node based on the data anomaly information.

[0088] Please refer to Figure 6 , Figure 6 The block diagram of the data recovery device provided by some embodiments of the present application is shown. It should be understood that the data recovery device corresponds to the above method embodiment and can execute each step involved in the above method embodiment. The specific functions of the data recovery device can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here.

[0089] Figure 6 The data recovery device includes at least one software function module that can be stored in a memory in the form of software or firmware or solidified in the data recovery device. The data recovery device is applied to any child node, and the any child node is one of at least one child node in the fault recovery task; including: a generation module 610, which is used to generate recovery configuration parameters based on the data anomaly information of the fault sent by the monitoring node; a sending module 620, which is used to send the recovery configuration parameters to the monitoring node; a recovery module 630, which is used to receive a node recovery weight value sent by the monitoring node, and use the node resources corresponding to the node recovery weight value to recover the data anomaly information.

[0090] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method, and will not be described in detail here.

[0091] Some embodiments of the present application further provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the operations of the method corresponding to any of the above methods provided in the above embodiments.

[0092] Some embodiments of the present application further provide a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the operations corresponding to any of the above methods provided in the above embodiments.

[0093] like Figure 7 As shown, some embodiments of the present application provide an electronic device 700, which includes: a memory 710, a processor 720, and a computer program stored in the memory 710 and executable on the processor 720, wherein the processor 720 can implement a method as described in any of the above embodiments when reading the program from the memory 710 through a bus 730 and executing the program.

[0094] Processor 720 can process digital signals and can include various computing structures, such as complex instruction set computer structure, reduced instruction set computer structure, or a structure that implements a combination of multiple instruction sets. In some examples, processor 720 can be a microprocessor.

[0095] The memory 710 may be used to store instructions executed by the processor 720 or data related to the execution of instructions. These instructions and / or data may include codes for implementing some or all functions of one or more modules described in the embodiments of the present application. The processor 720 of the disclosed embodiment may be used to execute instructions in the memory 710 to implement the method shown above. The memory 710 includes a dynamic random access memory, a static random access memory, a flash memory, an optical memory, or other memory known to those skilled in the art.

[0096] The above description is only an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.

[0097] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0098] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

Claims

1. A method for data recovery, characterized in that: Applied to monitoring nodes, including: Obtaining a node recovery weight value of data anomaly information of a cluster failure, wherein the node recovery weight value represents a node resource of at least one subnode required to recover the failure; According to the recovery configuration parameters acquired in advance, the node recovery weight value is sent to each child node in the at least one child node, so that each child node recovers the data anomaly information based on the node recovery weight value; wherein the recovery configuration parameters are determined by each child node based on the current network topology to determine the distance from the failed node and the correlation between each child node and the data anomaly information; The method also includes: receiving the data recovery progress fed back by the respective child nodes, and regularly updating the node recovery weight value based on the cluster parameters and the data recovery progress, and obtaining an updated weight value, wherein the updated weight value is used to regularly adjust the node resources of the at least one child node; wherein the updated weight value is determined by adjusting the node recovery weight value and the business processing weight value according to the task characteristic value through the change of the task queue, and the sum of the node recovery weight value and the business processing weight value is a constant; and when any one of the node recovery weight value and the business processing weight value is less than the task characteristic value, upon confirming that the flag and operation of the node recovery weight value and the business processing weight value is a true value, the node recovery weight value and the business processing weight value are reallocated.

2. The method according to claim 1, characterized in that Before obtaining the node recovery weight value of the data anomaly information of the cluster failure, the method further includes: When confirming that the fault existing in the cluster is recoverable, collecting the data abnormality information; Calculate the data anomaly information according to the preset weight value rule to obtain a basic weight value; The basic weight value is adjusted based on the service processing level of the cluster to obtain the node recovery weight value.

3. A method for data recovery, characterized in that: Applied to any sub-node, the any sub-node being one of at least one sub-node in a task of restoring a fault; the method comprising: Generate recovery configuration parameters based on the data anomaly information of the fault sent by the monitoring node; Sending the recovery configuration parameters to the monitoring node; Receiving a node recovery weight value sent by a monitoring node, and using a node resource corresponding to the node recovery weight value to recover the data anomaly information; The method also includes: receiving the updated weight value; wherein the updated weight value is determined by adjusting the node recovery weight value and the business processing weight value according to the task characteristic value through the change of the task queue, and the sum of the node recovery weight value and the business processing weight value is a constant; and when any weight value of the node recovery weight value and the business processing weight value is less than the task characteristic value, confirming that the flag of the node recovery weight value and the business processing weight value is a true value, reallocating the node recovery weight value and the business processing weight value.

4. The method according to claim 3, characterized in that The generating of the recovery configuration parameters based on the data anomaly information of the fault sent by the monitoring node includes: Obtaining the data correlation between the data anomaly information and any of the sub-nodes; The recovery configuration parameters are determined according to the data anomaly information and the data correlation.

5. The method according to claim 3 or 4, characterized in that In the data anomaly information recovery process, the method further includes: Based on the node task queue, the node recovery weight value and the business processing weight value are dynamically adjusted, wherein the sum of the node recovery weight value and the business processing weight value is a fixed value.

6. The method according to claim 3 or 4, characterized in that After the data anomaly information is recovered by using the node resources corresponding to the node recovery weight value, the method further includes: Sending the data recovery progress of the data anomaly information to the monitoring node, so that the monitoring node regularly updates the node recovery weight value based on the cluster parameters and the data recovery progress, and obtains the updated weight value; The node resources are adjusted using the updated weight value to complete the recovery of the data anomaly information.

7. A data recovery device, characterized in that: The device is used to execute the method according to claim 1, and is applied to a monitoring node, comprising: An acquisition module, used to acquire a node recovery weight value of data anomaly information of a cluster failure, wherein the node recovery weight value represents a node resource of at least one subnode required to recover the failure; A sending module is used to send the node recovery weight value to each child node in the at least one child node according to the pre-acquired recovery configuration parameters, so that each child node can recover the data anomaly information based on the node recovery weight value; wherein the recovery configuration parameters are generated by each child node based on the data anomaly information.

8. A data recovery device, characterized in that: The device is used to execute the method according to claim 3, and is applied to any sub-node, where the any sub-node is one of at least one sub-node in the task of restoring the fault; the device comprises: A generation module, used to generate recovery configuration parameters based on the data anomaly information of the fault sent by the monitoring node; A sending module, used for sending the recovery configuration parameters to the monitoring node; The recovery module is used to receive the node recovery weight value sent by the monitoring node, and use the node resources corresponding to the node recovery weight value to recover the data anomaly information.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program executes the method according to any one of claims 1 to 6 when executed by a processor.

10. An electronic device, characterized in that: The method comprises a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the computer program executes the method according to any one of claims 1 to 6 when being run by the processor.

11. A computer program product, characterized in that The computer program product comprises a computer program, wherein the computer program executes the method according to any one of claims 1 to 6 when executed by a processor.

Images