Method and device for recovering data in distributed block storage system

Abstract

The invention relates to a method and a device for recovering data in a distributed block storage system. The distributed block storage system comprises a block storage access client, a storage service cluster and a metadata service cluster; the storage service cluster comprises a plurality of storage service nodes, and the method comprises the following steps: 1) monitoring the cluster state in real time, and executing the step 2) when monitoring that the cluster is abnormal; 2) judging whether to delay reconstruction or not, if so, delaying for a set time and then executing the step 3), andif not, directly executing the step 3); 3) establishing a to-be-recovered data object list; and 4) recovering data according to the to-be-recovered data object list, and executing the data recovery step in parallel by each storage service node. Compared with the prior art, the method has the advantages that the data recovery speed can be increased, the influence of data recovery on front-end application performance can be reduced, and the like.

Description

technical field [0001] The invention relates to the field of computer distributed block storage software systems, in particular to a data recovery method and device in a distributed block storage system. Background technique [0002] In a distributed block storage system, the copy mechanism and DHT hash are generally used to calculate the data storage location. When the cluster state changes, such as node offline / re-online, disk failure, capacity expansion, and the storage location of some data copies of some storage objects changes, the data recovery module generally uses the push method of the primary copy to restore other copies or the pull method to perform recovery from other available copies , when the copy of the data object is not restored, if the front-end application data access occurs, it is generally necessary to wait for the data object to be restored before performing the write operation, which has a huge impact on the performance of the front-end application d...

AI Technical Summary

Problems solved by technology

When the cluster state changes, such as node offline / re-online, disk failure, capacity expansion, and the storage location of some data copies of some storage objects changes, the data recovery module generally uses the push method of the primary copy to restore other copies or the pull method to perform recovery from other available copies , when the copy of the data object is not restored, if the front-end application data access occurs, it is generally necessary to wait for the data object to be restored before performing the write operation, which has a huge impact on the performance of the front-end application data access, and may cause the front-end application to hang ,service is not available

The front-end application may only write 4K, and the recovery granularity of data objects is generally at least 1M or above. The problem of write amplification is serious, resulting in the fact that the write performance may drop to one-tenth of the normal cluster when the cluster is abnormal.

At the same time, the storage node does not record incremental write data after it goes offline for a short time. The amount of data to be restored each time is huge, and many unwritten data need to be restored again.

[0003] In the existing public technology, in order to reduce the amount of recovered data, the incremental write data is recorded through the Journal Log when the cluster is abnormal or even the cluster is normal, and the write operation is performed after the Journal Log is persisted to the storage medium. The performance impact of accessing is also huge

In order to balance data recovery and access to front-end application data, generally by setting recovery QOS, limit the rate of data recovery to reduce the impact on front-end application data access, but this setting is generally static, and recovery can be improved in a dynamic way efficiency

[0004] Many of the above problems are completely unacceptable in performance-sensitive application scenarios such as databases, which limits the application scenarios of distributed block storage and can only be applied in edge business scenarios

Images