WO2018098972A1

WO2018098972A1 - Log recovery method, storage device and storage node

Info

Publication number: WO2018098972A1
Application number: PCT/CN2017/081334
Authority: WO
Inventors: 李开广; 王英
Original assignee: 华为技术有限公司
Priority date: 2016-11-30
Filing date: 2017-04-21
Publication date: 2018-06-07
Also published as: CN106776130A; CN106776130B

Abstract

Disclosed is a log recovery technology, which may be applied to a distributed storage system. The log recovery method comprises: after a target storage node recovers to normal from a failure, sending a request to obtain a recovery log to a normal storage node in a distributed storage system; the target storage node receiving a first recovery log record which is returned by another storage node, a first recovery log indicating a service log which requires recovery; according to an indication of the first recovery log, the target storage node sending to the normal storage node a request to obtain a service log; the target storage node generating a target service log according to a received service log; and saving the target service log.

Description

Log recovery method, storage device and storage node

Technical field

The invention relates to the invention of storage technology, and relates to the field of logging in the field of storage technology.

Background technique

In the storage field, more and more distributed storage adopts an object-based architecture. The architecture is divided into upper and lower layers, where the upper layer is the file system, the block, the service layer such as S3/Swift, and the lower layer is the distributed key value. , KV) storage layer.

The distributed KV storage layer is responsible for the allocation, storage, and release of system storage space, providing reliability for the upper service layer across storage nodes, and self-healing functions that support storage media failures such as disks. Distributed KV can implement self-healing through the associated log, and the associated log of the repair class is also called the recovery log.

In addition to providing basic services such as file system, block, and S3/Swift, the service layer also needs to provide value-added features such as quotas and remote replication. These value-added features also need to store quota consumption records, remote replication incremental change records, and so on. As a result, these value-added features place additional demands on distributed storage. Distributed storage can also provide storage and reading methods for these additional records through companion logs. Service characteristics additional class associated logs are also called business logs.

In the prior art, a verification method of a distributed storage system is: splitting service data into data fragments, and computing redundant fragments by data fragmentation; some storage nodes storing service data fragments, and another part of storage The node stores redundant slices. For example, the number of data storage nodes is N, each data storage node stores one data fragment; the number of redundant storage nodes is M, and each redundant storage node stores one verification fragment.

For service data, if there is a faulty storage node in the distributed storage system, if the number of faulty storage nodes does not exceed M, only the remaining storage nodes are normally written with data (data fragmentation or parity fragmentation). It does not cause data loss, so the write operation will be performed normally. The service log is stored along with the shards, and the service logs saved by each storage node are the same. After the faulty storage node returns to normal, the unwritten fragments can be recovered through the fragmentation of other storage nodes. However, in the prior art, the service log is not recovered together with the shards. Therefore, although there are shards in the restored storage node, there is no service log.

In this case, due to the original normal storage node, a failure may occur after receiving the slice. This means that the service log of each storage node is not reliable, so if you want to read the service log from the distributed storage system, the host must obtain the service log from the M+1 storage nodes, and obtain the service log. A consolidated business log can be obtained after a combined induction. The process of obtaining and sorting the M+1 service logs adds to the computing resource consumption and time waiting of the host.

Summary of the invention

A log is provided to solve the problem that the service log recovery speed is slow in the prior art.

In a first aspect, the present invention provides an embodiment of a log recovery method, which is applied to a target storage node, where the target storage node is faulty, the target storage node is located in a distributed storage system, and the distributed storage system includes The target storage node and the normal storage node, the method includes: after the target storage node recovers from the fault state to the normal state, sending a request for acquiring a recovery log to the normal storage node in the distributed storage system; The target storage node receives the recovery log returned by the other storage node, the recovery log includes a first recovery log record, and the first recovery log indicates a service log that needs to be restored; according to the indication of the first recovery log, The target storage node sends a request for obtaining a service log to the normal storage node; the target storage node generates a target service log according to the received service log; and saves the target service log. Apply this solution, the host can Get the business log at any time, and only need to get the business log from a storage node. The process is simple and the delay is low.

The first possible implementation manner of the first aspect, after the host detects that the target storage node is faulty, the host sends a first recovery log to the normal storage node, where the normal storage node receives the first sent by the host Restore the log and store it. This solution provides the basis for subsequent use of the first recovery log to recover business logs.

The second possible implementation manner of the first aspect, wherein the target storage node generates the target service log according to the received service log, specifically: the target storage node merges and removes the received service log according to the received service log. The project is repeated to generate the target business log. This scheme describes the process of generating the target service log. The service logs sent by other storage nodes may not be complete, so they should be merged; there may be duplicate content after the merge, so duplicates should be removed.

A third possible implementation manner of the first aspect, the recovery log record further includes a second recovery log record, wherein the second recovery log record records fragmentation location information, the method further includes: the target storage node Sending a fragmentation acquisition request to another storage node in the distributed storage system, where the fragment acquisition request carries the fragmentation location information; the target storage node receives a fragment sent by another storage node; and the target storage node uses Receive the fragment, obtain the fragment of the storage node and save it. This scenario describes how the failed storage node fragmentation is recovered.

A fourth possible implementation manner of the first aspect, the method further includes: the host sending a service log obtaining request to the target storage node; the target storage node sending the target service log to the host; The target service log performs an operation. The scheme describes that the host can perform the operation of the service log only by obtaining the target service log, instead of obtaining the service log from multiple storage nodes and then merging and deduplicating to perform the operation of the service log. This solution is simpler and more efficient than the prior art.

In a fifth possible implementation manner of the first aspect, the target storage node and the normal storage node belong to the same partition.

In a second aspect, the present invention further provides an embodiment of a service log storage device, where the service log storage device is in communication with a normal storage device, the service log storage device includes: a sending module, configured to be used in the service log storage device After the fault is restored to normal, the request for obtaining the recovery log is sent to the normal storage device; the receiving module is configured to receive the recovery log returned by the other storage node, where the recovery log includes a first recovery log record, and the first recovery The log indicates a service log that needs to be restored; the processing module is configured to send, by the sending module, a request for obtaining a service log to the normal storage device according to the indication of the first recovery log; the processing module is further configured to: A target service log is generated according to the received service log, and a storage module is configured to save the target service log. The solution details and technical effects of the second aspect (and various implementations of the second aspect) and the first aspect (and various implementations of the first aspect) are similar and therefore are not described herein.

A third aspect of the present invention provides an embodiment of a service log storage node, where the service log storage node is located in a distributed storage system, where the distributed storage system includes the service log storage node and a normal storage node, and the service The log storage node includes a processor and a storage medium, and the processor is configured to: after the service log storage node recovers from the fault, send a request for acquiring the recovery log to the normal storage node; and receive the returned by the other storage node. The recovery log includes a first recovery log record, where the first recovery log indicates a service log that needs to be restored; and according to the indication of the first recovery log, sends a service log to the normal storage node. The request generates a target service log according to the received service log, and saves the target service log to the storage medium. The solution details and technical effects of the third aspect (and various implementations of the third aspect) and the first aspect (and various implementations of the first aspect) are similar and therefore are not described herein.

DRAWINGS

Figure 1 is a schematic diagram of a storage node failure;

2 is a schematic diagram of data recovery in a fault storage node;

3 is a schematic diagram of a storage node failure according to an embodiment of the present invention;

4 is a schematic diagram of data recovery in a fault storage node according to an embodiment of the present invention;

5 is a flow chart of an embodiment of a log recovery method of the present invention;

6 is a structural diagram of an embodiment of a service log storage device of the present invention;

7 is a topological diagram of an embodiment of a service log storage node of the present invention.

detailed description

The solution of the present application can be applied to a distributed storage system. Data stored in a distributed storage system can store files (or parts of files), objects, or key values (KV, key value). In the following embodiments, only the object storage will be described as an example unless otherwise specified.

The associated log may be log information generated by the distributed storage system in the process of storing data along with the preservation of the data. The associated log can be used for data recovery, and can also be used to record value-added features such as quotas. The service log and recovery log are all associated logs. The associated log can have characteristics: companionship, with the operation of the object, does not exist alone; reliability, with the operation of the object, each storage node saves the same companion log in a mirrored manner, and its reliability can be related to the object. The reliability level is the same; consistency, with the operation of the object, the consistency between the storage nodes is the same as the object; the logistic, the operation of the associated log pair always adds a number of records to the associated log object. The various logs mentioned in the embodiments of the present invention may be log records in a log file.

Referring to FIG. 1, a distributed storage system includes: a storage node 1, a storage node 2, and a storage node 3. Data (such as files or values) is split into data fragments. The redundancy slice 3 is parity data formed by the data slice 1 and the data slice 2, and the three slices are prepared to be stored in different storage nodes. If the storage node 2 fails when the data is written, the data slice 2 that needs to be written to the storage node 2 cannot be successfully written, the data slice 1 is successfully written to the storage node 1, and the redundant slice 3 is successfully written. Enter storage node 3.

Similarly, the service log and the second recovery log are successfully written in the storage node 1 and the storage node 3, and the service log and the second recovery log cannot be successfully written in the storage node 2. Data fragmentation and redundant fragmentation are collectively referred to as fragmentation. The second recovery log in FIG. 1 is used to recover data fragmentation or redundant fragmentation. For N+M redundancy ratio, as long as no less than N fragments are obtained, the remaining fragments can be recovered. The recovery log records the storage node IDs that need to be restored, the fragments that need to be restored, and the version number that needs to be restored.

Referring to Figure 2, after storage node 2 resumes normal operation. The data slice 2 can be calculated by the data slice 1 stored in the storage node 1 and the redundant slice 3 stored in the storage node 3, and the calculated data slice 2 is written into the storage node 2 so that the storage node The data slice 2 in 2 is recovered. However, the associated log in storage node 2 that should be stored is not recovered. If the host (the host and all the storage nodes communicate) need to obtain the service log, you must read the service logs from the storage node 1 and the storage node 3 separately, and then merge and collate to obtain a reliable service log.

Referring to FIG. 3, similar to FIG. 1, the storage node 2 has failed. The difference from FIG. 2 is that there are two recovery logs in the embodiment of the present invention. In addition to the second recovery log, there is a first recovery log, which is used to restore the service log.

In the case of storage node 2 failure, the process of writing data can be performed in a two-stage (2PC) transaction process. Proceed as follows.

(1) The host splits the file or object to be written into data fragments, and selects a certain number of data fragments according to the number of storage nodes to calculate redundant fragments. The selected data fragments and redundant fragments are sent to the respective storage nodes. Each storage node sends one or more shards.

(2) The storage node is temporarily stored in the memory after receiving the fragment. Then the storage node sends it to its own hard disk, and each hard disk sends a slice.

(3) The host sends a prepare request to each storage node.

(4) The storage node that received the prepare request will write the transaction log locally and then send a response message. Since the storage node 2 sends a failure, only the storage node 1 and the storage node 2 have issued a response message.

(5) After the host receives the response message from the storage node 1 and the storage node 3. Judgment: When all the storage nodes that received the prepare are responded to by the host. The host sends a request to the storage node that sends the response message; otherwise, the host issues an abort request to the storage node that sends the response message.

(6) The storage node that receives the commit request stores the shards in the memory persistently, that is, in a non-volatile storage medium (such as a disk or a solid-state hard disk). Each hard disk stores one slice.

Referring to Figure 4, after storage node 2 recovers from a failure. In addition to recovering the service log using the first recovery log, the second recovery log can also be used to recover the data fragment 2.

The recovery process is as follows.

(1) After the storage node 2 returns to normal, the message that it returns to normal is advertised to the storage node 1 and the storage node 3.

(2) After receiving the notification message, the storage node 1 and the storage node 3 send the locally stored recovery log to the storage node 2.

(3) The storage node 2 obtains the data fragment 1 and the verification fragment 3 according to the first recovery log, and relies on the data fragment 1 and the verification fragment 3 to recover the data fragment 2. The data slice 2 is sent to the storage node 2. The storage node 2 holds the data slice 2 into a non-volatile storage medium.

In fact, any storage node can calculate the data slice 2 as long as the data slice 1 and the check slice 3 are obtained. Therefore, the recovery process of the data slice 2 can also be performed by the storage node 3 or the storage node 1, and Let me repeat.

(4) The storage node 2 according to the second recovery log, the storage node 1 and the storage node 3 each send a local service log to the storage node 2. After the storage node 2 performs the operations of merging and removing duplicates, it generates its own service log and saves the generated service log.

Again, this operation can be performed by other storage nodes. The generated service log is sent to the storage node 2 for storage.

Referring to FIG. 5, it is a flowchart of an embodiment of a log recovery method of the present invention. The process of Figures 3 and 4 is described in more detail.

11. Before the host writes the service log, check the storage node in the distributed system to know the status of the storage node (the status includes: normal, fault). Write the service log and the first recovery log to the normal storage node. The service log describes the attributes of the object, and the first recovery log is used to restore the service log. For the failed storage node, the service log and the first recovery log are not written. A storage node failure means that the storage node cannot write data, including the failure of the storage node itself, and the failure of the host to the storage node. For convenience of description, the failed storage connection is referred to as a target storage node.

The storage node range involved in this step is the storage node where the partition is located. The storage space of each partition is saved by multiple Provided by the storage node. Each storage node also provides storage for multiple partitions simultaneously.

For example, if there are 10 storage nodes in the distributed storage system, and the partitions to be written in the data are distributed in the four storage nodes, the storage nodes in this step check whether the four storage nodes are faulty. Storage nodes can be left unchecked. The normal storage node and the target storage node mentioned in this embodiment and other embodiments are for a specific partition unless otherwise specified. Refers to the storage nodes distributed by this partition. In other words, the set of the normal storage node and the target storage node is composed of storage nodes where the storage space of the partition is located. Each storage space can be described by a range of addresses.

The first recovery log carries the information of the service log that needs to be restored, and the information of the service log can be located to the log that needs to be restored. The information form of the business log can be various. For example, (1) the information of the service log may be an identifier (I D) of the service log, and the identifier may be located to a specific service log; (2) the information of the service log may be a description of the service log type and the generation of the service log. period.

Optionally, the fragment and the second recovery log are also written to the normal storage node. Specifically, it is stored in each storage space according to the amount of storage space. Different slices are stored in different storage spaces. Each slice is one of the N data slices of the object, or one of the M check slices; the second recovery log stored in different storage spaces is the same. . It should be noted that if the number of faulty storage nodes is too large, and the number of normal storage nodes (or the number of fragments provided by the normal storage node) is difficult to form a verification relationship, step 11 is not performed, and the entire process is terminated.

The second recovery log records the storage node ID and the object ID; it may also be other information, such as the storage node ID and the address of the fragment on the hard disk; there may be other forms as long as the fragmentation of the failed storage node is resumed. You can find the fragments in the normal storage node.

In distributed storage, a partition consists of a set of storage space from hard disks of different storage nodes, each of which provides a storage space. The service log and the first recovery log are stored in the normal storage node. The service log and the first recovery log are mirrored in the storage space of the normal storage node. After storing the object in the partition, the partition provides data protection capabilities for the object, such as erasure code (EC) and mirror (mirror). Taking the protection algorithm of the erasure code as an example, a specific method is: storing a group of slices into a partition, the space forming the partition comes from a plurality of hard disks, and each hard disk provides a storage space for storing a slice. The hard disk comes from multiple storage nodes. The component slice includes a verification slice and a data slice, the data slice is split by the object, the check slice is generated by the data slice, and the data slice and the check slice form a check relationship. Taking the redundancy ratio of N+M as an example, after obtaining the fragmentation of at least N storage nodes in the partition, the fragmentation in the remaining storage nodes can be recovered by using the erasure code algorithm, and this step can be performed. If the number of normal storage nodes is less than N, the verification relationship is not met. This step is not performed.

Optionally, the step may further include: writing, according to the quantity of the storage space provided by the normal storage node, the fragment into the normal storage node, where each storage space may store one fragment.

12. After the target storage node returns to normal, send a request for obtaining a recovery log to the normal storage node.

In order to facilitate the distinction, in the present embodiment and other various embodiments, the normal storage node refers to a storage node that is originally in a normal state, or a storage that is in a normal state during a failure of the template storage node, unless otherwise specified. Node, so the storage node in the normal state does not include the target storage node. The request to recover the log may carry a period of time during which the recovery log needs to be obtained (that is, a period of time during which the target storage node fails).

It should be noted that, among the storage nodes distributed by the partition including the target storage node, information of the partition, such as which storage nodes the partition is distributed, is recorded. So for a particular partition, the target storage node can Know which storage nodes are located in this partition's other space.

This step can send a recovery log request to a normal storage node (such as the primary storage node in the partition). A recovery log request can also be sent to all normal storage nodes.

13. The normal storage node obtains a recovery log by calling a log interface program after receiving the request for obtaining a recovery log. A recovery log during a target storage node failure is sent to the target storage node.

If only one normal storage node receives the request to obtain a recovery log, the normal storage node feeds back the recovery log. One solution is to obtain a local recovery log as feedback to the recovery log of the target storage node. This scheme can be applied to the complete situation of the local recovery log. Another solution is to obtain the recovery log from the local, and obtain the recovery log from other normal storage nodes. After the merge and deduplication, the feedback log is fed back to the recovery log of the target storage node. This scheme can be applied to the local recovery log. Case.

For a normal storage node that has obtained the local recovery log, if there are multiple recovery logs in the same normal storage node (for example, there are multiple storage spaces, each storage space stores one recovery log), you can send only one recovery log. You can send multiple recovery logs.

If the plurality of normal storage nodes receive the request for obtaining the recovery log, the local recovery logs are respectively fed back to the target storage node, and after the target storage node merges and removes the duplicate items, the operation of step 14 is performed.

For this step, the normal storage node obtains the recovery log of the local storage, specifically, the log of the space storage belonging to the partition in the storage node. If there are multiple storage spaces belonging to the partition, each storage space stores one. If you want to recover the log, you can get one of the recovery logs at will.

It should be noted that, as described above, the partition is composed of a plurality of storage spaces. Multiple storage spaces that make up the same partition come from multiple storage nodes. Each storage node can provide one storage space; it can also provide multiple storage spaces. Each storage space stores one fragment; and stores logs (recovery logs, service logs, etc.), and logs of different storage spaces are mirrored.

In the case where the same storage node provides multiple storage spaces, different storage spaces can come from different hard disks to improve system reliability. For example, when a storage node provides three storage spaces, the three storage spaces are respectively from the three hard disks of the storage node. Because the logs are accompanied by shard storage, each storage space can store a single log. Therefore the number of logs and the number of shards are the same.

14. After receiving the recovery log, the target storage node sends a recovery request to the normal storage node according to the indication of the recovery log. The sending range of the recovery request can be all normal storage nodes.

For the recovery of the service log, the target storage node sends a service log recovery request to the normal storage node according to the information described in the first recovery log.

For the recovery of the fragment, the target storage node sends a service log recovery request to the normal storage node according to the information described in the second recovery log.

15. The normal storage node, after receiving the recovery request, sends the data of the information recorded in the recovery request to the target storage node.

For the first recovery log, if the information carried in the first recovery log is an identifier of the service log, the service log corresponding to the identifier is directly sent to the target storage node. If the information carried in the first recovery log describes the service log type and the time period during which the service log is generated. Then, the service log that satisfies the information of the service log (the specified service log type in the specified time period) is sent to the target storage node.

If there are multiple service logs that meet the conditions in the same storage node (for example, there are multiple storage spaces, each The storage space stores a service log), which can be sent to the target storage node, or only one of them can be sent.

For the second recovery log, the fragment of the storage node is found according to the fragmentation information carried in the second recovery log, and then sent to the target storage node. For example, the slice of the storage node can be found according to the storage node ID and the object ID. For each normal storage node that sends a slice, the range of transmission is all fragments that satisfy the condition at the partition. That is, if there are multiple shards of the same normal storage node, these shards are sent to the target storage node.

16. The target storage node receives the service logs sent by other storage nodes, and generates a target service log. Then save the generated business log.

When the information of the first recovery log is an identifier of the service log, the received service logs are combined to generate a target service log. This restores the business log that would otherwise need to be stored to the target storage node. In some cases, the deduplication operation can be performed after the merge to generate a service log that needs to be stored to the target storage node.

The information carried in the first recovery log describes the service log type and the time period during which the service log is generated. Then, the received service logs are merged, and then the target service logs are generated after the duplicates are removed. This restores the business log that would otherwise need to be stored to the target storage node.

In addition, the target storage node can also recover the fragments. The method is: performing a check calculation on the received fragments, and generating a fragment that needs to be stored to the target storage node. In this embodiment, the target storage node obtains the fragmentation and performs the data recovery operation. It can be understood that, in other embodiments, the storage may be obtained by other storage nodes and the data recovery operation may be performed. The fragment is sent to the target storage node.

17. The host reads the service log acquisition request from the target storage node, and performs the next operation according to the obtained service log. For example, if the service log describes the consumption of the storage space quota of the partition, it is determined whether to continue writing data to the partition according to the consumption of the storage space quota.

Based on the service log recovery solution provided by the embodiment, when the host needs to read the service log, the host only needs to read the service log to one storage node, and does not need to read multiple service logs, so the delay is shorter, and the process is also It's simpler, and it also saves network bandwidth between the host and the distributed storage system.

Referring to FIG. 6 , it is a structural diagram of an embodiment of a service log storage device, which can perform the above-mentioned log recovery method. Since it has been described in detail in the embodiment of the log recovery method, only a brief introduction will be given below. The service log storage device 2 is in communication with the normal storage device, and the service log storage device 2 includes:

The sending module 21 is configured to send a request for acquiring a recovery log to the normal storage device after the service log storage device recovers from a fault;

The receiving module 22 is configured to receive the recovery log returned by another storage node, where the recovery log includes a first recovery log record, the first recovery log indicates a service log that needs to be restored, and the processing module 23 is configured to An instruction to obtain a service log is sent to the normal storage device by the sending module 21; the processing module 23 is further configured to generate a target service log according to the received service log; 24, for saving the target service log, for example, saving to a storage medium.

The receiving module 22 is further configured to: after the service log storage device fails, receive the first recovery log sent by the host and store the first recovery log.

The processing module 23 generates the target service log according to the received service log, which includes: the processing module 23 generates the target service log according to combining the received service logs and removing duplicate items.

The recovery log record further includes a second recovery log record, wherein the second recovery log record records fragmentation location information; the sending module 21 is further configured to send a fragment acquisition request to the storage device, where The fragmentation acquisition request carries the fragmentation location information; the receiving module 22 is further configured to receive a fragment sent by another storage device; the processing module 23 is further configured to obtain, by using the received fragmentation, Fragments of this storage node are saved.

Further, the host communicates with the service log storage device. The host is configured to send a service log obtaining request to the service log storage device. After the receiving module 22 receives the service log obtaining request, the sending module 21 is further configured to send the target service log to the host; the host is further configured to perform operations according to the target service log. .

The service log storage device 2 and the normal storage device belong to the same partition.

The service log storage device may be hardware, such as a storage node, and the present invention may be referred to as a service log storage node. Physically it may be a storage controller, or a storage server, or a combination of a storage controller and a storage medium.

FIG. 7 is a topological diagram of an embodiment of a service log storage node of the present invention.

The service log storage node 3 is located in a distributed storage system, and the distributed storage system includes the service log storage node 3 and a normal storage node (not shown), and the service log storage node 3 includes a processor 31, a memory 32, and a storage medium 33. The memory 32 has a program, and the processor 31 is configured to execute, by running a program in the memory, to send a request for acquiring a recovery log to the normal storage node after the service log storage node recovers from the fault. Receiving the recovery log returned by the other storage node, the recovery log includes a first recovery log record, the first recovery log indicating a service log that needs to be restored; according to the indication of the first recovery log, to the The normal storage node sends a request for obtaining a service log; and generates a target service log according to the received service log; and saves the target service log to the storage medium 33.

In other embodiments, such as when the processor is a Field Programmable Gate Array (FPGA), the processor itself has the ability to memorize programs and therefore does not require memory.

The present invention also provides an embodiment of a storage medium such as an optical disk/U disk, in which a computer program is stored in the optical disk/U disk, and after the program is installed in a computer, a storage server or a storage controller, steps 11-16 can be executed by running the program. The method mentioned.

Claims

A log recovery method is applied to a target storage node, where the target storage node is located in a distributed storage system, the distributed storage system includes the target storage node and a normal storage node, and the method includes:

After the target storage node recovers from the fault, sending a request for acquiring a recovery log to the normal storage node in the distributed storage system;

The target storage node receives the recovery log returned by another storage node, where the recovery log includes a first recovery log record, and the first recovery log indicates a service log that needs to be restored;

And the target storage node sends a request for acquiring a service log to the normal storage node according to the indication of the first recovery log;

Generating, by the target storage node, a target service log according to the received service log;

The target service log is saved.
The method of claim 1 before the method further comprising:

After the target storage node fails, the normal storage node receives the first recovery log sent by the host and stores it.
The method according to claim 1, wherein the target storage node generates the target service log according to the received service log, which specifically includes:

The target storage node generates the target service log according to combining the received service logs and removing duplicate items.
The method of claim 1, wherein the recovery log record further comprises a second recovery log record, wherein the second recovery log record records fragmentation location information, the method further comprising:

Sending, by the target storage node, a fragmentation acquisition request to other storage nodes in the distributed storage system, where the fragment acquisition request carries the fragmentation location information;

The target storage node receives the fragments sent by other storage nodes;

The target storage node obtains the fragment of the storage node and saves it by using the received fragment.
The method of claim 1 further comprising:

The host sends a service log obtaining request to the target storage node;

Sending, by the target storage node, the target service log to the host;

The host performs an operation according to the target service log.
The method of claim 1 wherein:

The target storage node and the normal storage node belong to the same partition.
A service log storage device, wherein the service log storage device communicates with a normal storage device, wherein the service log storage device comprises:

a sending module, configured to send, to the normal storage device, a request for acquiring a recovery log after the service log storage device recovers from a fault;

a receiving module, configured to receive the recovery log returned by another storage node, where the recovery log includes a first recovery log record, where the first recovery log indicates a service log that needs to be restored;

a processing module, configured to send, by using the sending module, a request for acquiring a service log to the normal storage device according to the indication of the first recovery log;

The processing module is further configured to generate a target service log according to the received service log;

a storage module, configured to save the target service log.
The service log storage device of claim 7, the receiving module is further configured to:

After the service log storage device fails, the first recovery log sent by the host is received and stored.
The service log storage device according to claim 7, wherein the processing module generates the target service log according to the received service log, which specifically includes:

The processing module generates the target service log according to combining the received service logs and removing duplicate items.
The service log storage device of claim 7, wherein the recovery log record further comprises a second recovery log record, wherein the second recovery log record records fragmentation location information, wherein:

The sending module is further configured to send a fragment acquisition request to the storage device, where the fragment acquisition request carries the fragmentation location information;

The receiving module is further configured to receive a fragment sent by another storage device;

The processing module is further configured to use the received fragment to obtain a fragment of the storage node and save the fragment.
A service log storage device according to claim 7, wherein:

The receiving module is further configured to receive a service log obtaining request sent by the host;

The sending module is further configured to send the target service log to the host, so that the host performs an operation according to the target service log.
A service log storage device according to claim 7, wherein:

The service log storage device and the normal storage device belong to the same partition.
A service log storage node, where the service log storage node is located in a distributed storage system, the distributed storage system includes the service log storage node and a normal storage node, wherein the service log storage node includes processing And a storage medium for executing:

After the service log storage node recovers from the fault, sending a request for obtaining a recovery log to the normal storage node;

Receiving, by the other storage node, the recovery log, where the recovery log includes a first recovery log record, where the first recovery log indicates a service log that needs to be restored;

And sending, according to the indication of the first recovery log, a request for acquiring a service log to the normal storage node;

Generate a target service log based on the received service logs.

Saving the target business log to the storage medium.