A data recovery processing method and related technologies for a distributed storage system
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-04-07
- Publication Date
- 2026-08-14
AI Technical Summary
由于恢复请求属于后台业务,系统在处理恢复请求时会进行相应的流控处理,导致恢复请求的延时相对较长,从而造成前端写请求时延增大,给客户端业务带来影响
[0035]本申请所提供的一种分布式存储系统的数据恢复处理方法,包括:当写请求的对象存在于待恢复对象集合中,第一数据设备将写请求的内容和对应的数据内容进行合并处理,得到写恢复事务;将所述写恢复事务发送到对应的第二数据设备,以便所述第二数据设备基于所述写恢复事务进行数据恢复,当数据恢复完成时返回完成消息;当接收到完成消息时,将所述对象从待恢复对象集合中删除。
Smart Images

Figure CN116401099B_ABST
Abstract
Description
Technical Field
[0001] This application relates to distributed data storage technology, and in particular to a data recovery processing method, data recovery processing device, server, and computer-readable storage medium for a distributed storage system. Background Technology
[0002] With the continuous development of information technology, end users are becoming increasingly sensitive to and demanding in terms of I / O (Input / Output) latency. Even when a cluster experiences partial failures or scaling down, system latency must remain relatively stable. However, in current distributed storage systems, when failures or scaling down occur, some objects in Placement Groups (PGs) become degraded and require recovery. When front-end applications need to modify these objects, they must first be restored, and only after the restoration is complete can front-end write requests be processed.
[0003] In related technologies, when processing write requests, if an object needs to be restored or is being restored, the current write request for that object needs to be enqueued and processed until the entire object is completed before continuing to process the write request. Since restoration requests are background processes, the system performs flow control during their processing, resulting in a relatively long delay. This increases the latency of frontend write requests, impacting client-side business operations. Furthermore, if an object is currently undergoing modification write operations while being restored, the restoration locking will fail, causing the entire PG to enter a waiting state until the write process for that object is completed and the write lock is released before the PG enters the restoration state. Therefore, it is evident that this can easily lead to a relatively long delay in restoration requests, increasing the latency of frontend write requests and impacting client-side business operations.
[0004] Therefore, how to enable parallel execution of front-end business request processing and recovery is a key issue of concern for those skilled in the art. Improving the recovery speed of objects in PostgreSQL while reducing front-end business I / O latency is crucial. Summary of the Invention
[0005] The purpose of this application is to provide a data recovery processing method, data recovery processing device, server, and computer-readable storage medium for a distributed storage system, enabling front-end business request processing and recovery to be executed in parallel, thereby reducing front-end business I / O latency and improving the recovery speed of objects in PG.
[0006] To address the aforementioned technical problems, this application provides a data recovery processing method for a distributed storage system, comprising:
[0007] When the object of the write request exists in the set of objects to be recovered, the first data device merges the content of the write request with the corresponding data content to obtain a write recovery transaction;
[0008] The write recovery transaction is sent to the corresponding second data device so that the second data device can perform data recovery based on the write recovery transaction and return a completion message when the data recovery is complete.
[0009] When a completion message is received, the object is removed from the set of objects to be restored.
[0010] Optionally, when the data recovery of the second data device is completed, the method further includes:
[0011] The second data device removes the object from the local set of objects to be recovered.
[0012] Optionally, the first data device merges the content of the write request and the corresponding data content to obtain a write recovery transaction, including:
[0013] The first data device reads the data content of the object;
[0014] The modified content of the write request is merged with the data content to obtain the full recovery data;
[0015] The write recovery transaction is constructed based on the full recovery data.
[0016] Optionally, the second data device performs data recovery based on the write recovery transaction, including:
[0017] The second data device performs full data recovery based on the write recovery transaction.
[0018] Optional, also includes:
[0019] The first data device constructs a recovery request based on the data of the object to be recovered;
[0020] The recovery request is sent to the corresponding second data device so that the second data device can perform data recovery based on the object version number of the recovery request and the local object version number.
[0021] Optionally, the second data device performs data recovery based on the object version number of the recovery request and the local object version number, including:
[0022] The second data device determines whether the local object version number is less than the object version number of the recovery request;
[0023] If so, data recovery is performed based on the recovery request, and a recovery success message is sent.
[0024] If not, a recovery success message will be sent.
[0025] Optionally, when the first data device receives a recovery success message, it further includes:
[0026] Remove the object to be recovered from the set of objects to be recovered.
[0027] This application also provides a data recovery processing apparatus for a distributed storage system, comprising:
[0028] The request merging module is used to merge the content of the write request and the corresponding data content when the object of the write request exists in the set of objects to be recovered, so as to obtain a write recovery transaction;
[0029] The transaction sending module is used to send the write recovery transaction to the corresponding second data device so that the second data device can perform data recovery based on the write recovery transaction and return a completion message when the data recovery is completed.
[0030] The object deletion module is used to delete the object from the set of objects to be recovered when a completion message is received.
[0031] This application also provides a server, including:
[0032] Memory, used to store computer programs;
[0033] A processor is configured to implement the steps of the data recovery processing method described above when executing the computer program.
[0034] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the data recovery processing method described above.
[0035] This application provides a data recovery processing method for a distributed storage system, comprising: when the object of the write request exists in a set of objects to be recovered, a first data device merges the content of the write request and the corresponding data content to obtain a write recovery transaction; the write recovery transaction is sent to a corresponding second data device so that the second data device performs data recovery based on the write recovery transaction; when the data recovery is completed, a completion message is returned; when the completion message is received, the object is deleted from the set of objects to be recovered.
[0036] By merging the content of the write request and the corresponding data into a write recovery transaction and then sending it to the second data device, the second data device can process the write request and recovery request simultaneously in one execution process, avoiding delays in the write request and realizing simultaneous processing of write and recovery requests, thereby improving the execution efficiency of the distributed storage system.
[0037] This application also provides a data recovery processing device, server, and computer-readable storage medium for a distributed storage system, which have the above-mentioned beneficial effects, and will not be elaborated here. Attached Figure Description
[0038] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0039] Figure 1 A flowchart illustrating a data recovery processing method for a distributed storage system provided in this application embodiment;
[0040] Figure 2 A flowchart illustrating another data recovery processing method for a distributed storage system provided in this application embodiment;
[0041] Figure 3 A flowchart illustrating a data recovery processing method for a distributed storage system provided in this application embodiment;
[0042] Figure 4 This is a schematic diagram of the structure of a data recovery processing device for a distributed storage system provided in an embodiment of this application;
[0043] Figure 5 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation
[0044] The core of this application is to provide a data recovery processing method, data recovery processing device, server, and computer-readable storage medium for a distributed storage system, enabling front-end business request processing and recovery to be executed in parallel, thereby reducing front-end business I / O latency and improving the recovery speed of objects in PG.
[0045] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0046] In related technologies, when processing write requests, if an object needs to be restored or is being restored, the current write request for that object needs to be enqueued and processed until the entire object is completed before continuing to process the write request. Since restoration requests are background processes, the system performs flow control during their processing, resulting in a relatively long delay. This increases the latency of frontend write requests, impacting client-side business operations. Furthermore, if an object is currently undergoing modification write operations while being restored, the restoration locking will fail, causing the entire PG to enter a waiting state until the write process for that object is completed and the write lock is released before the PG enters the restoration state. Therefore, it is evident that this can easily lead to a relatively long delay in restoration requests, increasing the latency of frontend write requests and impacting client-side business operations.
[0047] Therefore, this application provides a data recovery processing method for a distributed storage system. By merging the content of a write request and the corresponding data into a write recovery transaction, and then sending it to a second data device, the second data device can simultaneously process the write request and the recovery request in one execution process, avoiding delays in the write request, realizing simultaneous processing of the write request and the recovery request, and improving the execution efficiency of the distributed storage system.
[0048] The following embodiment illustrates a data recovery processing method for a distributed storage system provided in this application.
[0049] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a data recovery processing method for a distributed storage system provided in an embodiment of this application.
[0050] In this embodiment, the method may include:
[0051] S101, when the object of the write request exists in the set of objects to be recovered, the first data device merges the content of the write request and the corresponding data content to obtain a write recovery transaction;
[0052] This step aims to merge the content of the write request and the corresponding data content into a write recovery transaction when the object of the write request exists in the set of objects to be recovered.
[0053] In this context, when a write request is made for an object that exists in the set of objects to be recovered, it indicates that the object needs to be recovered but has not yet been recovered. Generally, a write operation can only be performed on the object after it has been recovered, resulting in a delay in the write request. Therefore, in this application's technical solution, write requests and recovery requests are merged before being sent to the corresponding device for processing.
[0054] In this embodiment, the first data device can be the primary OSD (Object Storage Device) in the platform. Other backup OSDs perform data recovery through the primary OSD. Alternatively, it can be a backup OSD. Other backup OSDs or the primary OSD can perform data recovery through the backup OSD. Furthermore, the first data device can be a storage node in a distributed storage platform. Accordingly, the first data device can be a primary storage node or a backup storage node. The specific choice depends on actual needs. Therefore, the first data device in this embodiment is not unique and is not limited in this embodiment.
[0055] In this context, the content of the write request in the first data device is the content that is modified in the write request. Correspondingly, the corresponding data content is the content of that object in the first data device.
[0056] Furthermore, this step may include:
[0057] Step 1: The first data device reads the data content of the object;
[0058] Step 2: Merge the modified content of the write request with the data content to obtain the full recovery data;
[0059] Step 3: Construct a write recovery transaction based on the full recovery data.
[0060] As can be seen, this optional solution mainly describes how to construct a write recovery transaction. In this optional solution, the first data device reads the data content of the object; merges the modified content of the write request with the data content to obtain the full recovery data; and constructs a write recovery transaction based on the full recovery data.
[0061] The process involves merging the modified content of the write request with the data content. This can be achieved by directly modifying the data content based on the modified content, resulting in the latest modified data. Then, a write recovery transaction is generated based on this latest modified data to restore the data. This allows the second data device to directly restore to the latest data without processing the write request again.
[0062] Accordingly, the step of the second data device performing data recovery based on write recovery transactions in this embodiment may include:
[0063] The second data device performs full data recovery based on write recovery transactions.
[0064] As can be seen, this optional solution mainly relies on the write recovery transaction to perform full data recovery, so that the second data device can obtain the latest data.
[0065] S102, the write recovery transaction is sent to the corresponding second data device so that the second data device can perform data recovery based on the write recovery transaction, and a completion message is returned when the data recovery is completed;
[0066] Based on S101, this step aims to send the write recovery transaction to the corresponding second data device so that the second data device can perform data recovery based on the write recovery transaction and return a completion message when the data recovery is complete.
[0067] Conversely, in existing technologies, when processing write requests, if it is found that an object needs to be restored or is being restored, the current write request for that object needs to be enqueued and processed until the entire object is completed before continuing to process the write request. Since restoration requests are background business processes, the system performs corresponding flow control processing when processing restoration requests, resulting in a relatively long delay for restoration requests. This increases the latency of frontend write requests and impacts client-side business operations.
[0068] Optionally, in this embodiment, when the data recovery of the second data device is completed, the method further includes:
[0069] The second data device removes the object from the local collection of objects to be recovered.
[0070] As can be seen, this optional solution mainly describes the option to delete the corresponding object. In this optional solution, the second data device deletes the object from the local set of objects to be recovered. The set of objects to be recovered mainly records the objects to be recovered. Normally, the corresponding objects can be locked using this set of objects to prevent other operations from accessing them, but this would cause a delay in request processing. Therefore, this technical solution merges the write request and the recovery request to avoid delaying the write request.
[0071] S103, when a completion message is received, the object is removed from the set of objects to be restored.
[0072] Building upon S102, this step aims to remove the object from the set of objects to be recovered when a completion message is received. In other words, the first data device removes the object from the record when it receives a message from the second data device indicating that the transaction has been completed.
[0073] Furthermore, this embodiment may also include:
[0074] Step 1: The first data device constructs a recovery request based on the data of the object to be recovered;
[0075] Step 2: Send the recovery request to the corresponding second data device so that the second data device can perform data recovery based on the object version number in the recovery request and the local object version number.
[0076] As can be seen, this optional solution mainly describes how to process recovery requests, thereby avoiding latency during the recovery request processing and improving processing efficiency. In this optional solution, the first data device constructs a recovery request based on the data of the object to be recovered; the recovery request is sent to the corresponding second data device, so that the second data device can perform data recovery based on the object version number in the recovery request and the local object version number.
[0077] Conversely, in the prior art, when restoring an object, if the object is undergoing a write operation, the recovery lock will fail, causing the entire PG to enter a waiting state until the write process of the object is completed and the write lock is released before the PG enters the recovery state.
[0078] As can be seen, in this alternative solution, the object operation is determined by the second data device itself, rather than by the first data device waiting before processing.
[0079] Furthermore, the second data device in the previous alternative scheme, performing data recovery based on the object version number of the recovery request and the local object version number, may include:
[0080] Step 1: The second data device determines whether the local object version number is less than the object version number in the recovery request;
[0081] Step 2: If yes, perform data recovery based on the recovery request and send a recovery success message;
[0082] Step 3: If not, send a recovery success message.
[0083] As can be seen, this optional solution mainly describes how the second data device performs the recovery. In this optional solution, the second data device determines whether the local object version number is less than the object version number in the recovery request; if so, it performs data recovery based on the recovery request and sends a recovery success message; otherwise, it sends a recovery success message.
[0084] Furthermore, when the first data device receives the recovery success message, it also includes:
[0085] Remove the object to be recovered from the collection of objects to be recovered.
[0086] In summary, this embodiment combines the content of the write request and the corresponding data into a write recovery transaction, and then sends it to the second data device. This allows the second data device to process both the write request and the recovery request simultaneously in one execution process, avoiding delays in the write request and achieving simultaneous processing of the write and recovery requests, thereby improving the execution efficiency of the distributed storage system.
[0087] The following specific embodiment further illustrates the data recovery processing method of a distributed storage system provided in this application.
[0088] In this embodiment, by optimizing the read / write and recovery processes, the locking process in the read / write and recovery processes is removed. The object write and recovery write operations are integrated by using the missing table (the set of objects to be recovered) and the version number, thereby achieving the goal of parallel reading / write operations and recovery.
[0089] This optimization reduces the queuing waiting operations for read and write business requests, reduces latency fluctuations in front-end business, and also avoids queuing waiting operations for recovery PG, increasing the continuity of recovery processing and improving recovery speed.
[0090] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating another data recovery processing method for a distributed storage system provided in an embodiment of this application.
[0091] First, the specific implementation steps for processing write requests are as follows:
[0092] Step 1: After writing the request to dequeue, determine whether the object needs to be restored using the missing table;
[0093] Step 2: If the object needs to be restored, read the object directly from the main OSD, merge the modified content into the read content, and then proceed to step 4.
[0094] Step 3: If the object does not need to be restored, proceed directly to step 4;
[0095] Step 4: Construct write transaction requests and distribute them to each standby OSD, while the primary OSD also processes the write transactions.
[0096] Step 5: The backup OSD in the missing state receives the write request and completes the write transaction on the lower disk;
[0097] Step 6: After the disk is closed, delete the object from the local missing table and return a write success message to the master OSD.
[0098] Step 7: After the primary OSD receives a successful write response from the backup OSD which is in a missing state, it deletes the object from the primary OSD's missing table.
[0099] Step 8: After all backup OSDs return a successful write response, return a successful write response to the client.
[0100] Please refer to Figure 3 , Figure 3A flowchart illustrating a data recovery processing method for a distributed storage system provided in this application embodiment.
[0101] Secondly, the specific implementation steps for handling recovery requests are as follows:
[0102] Step 1: The recovery thread recovers objects in the missing table according to the hash order;
[0103] Step 2: Read the data of the object on the primary OSD, construct a recovery request, and send it to the backup OSD which is in a missing state;
[0104] Step 3: After receiving the recovery request sent by the master OSD, the standby OSD first reads the version number of the local object.
[0105] Step 4: If the local version number is less than the object version number carried in the recovery request or the local object does not exist, proceed to step 5; otherwise, proceed to step 7.
[0106] Step 5: Complete the recovery of the lower bounds of the transaction;
[0107] Step 6: After the disk is closed, delete the object from the local missing table;
[0108] Step 7: Send a successful recovery response to the master OSD;
[0109] Step 8: After receiving the successful recovery response, the master OSD removes the object from the master OSD's missing list.
[0110] As can be seen, this embodiment combines the content of the write request and the corresponding data into a write recovery transaction, and then sends it to the second data device. This allows the second data device to process the write request and the recovery request simultaneously in one execution process, avoiding delays in the write request and achieving simultaneous processing of the write request and the recovery request, thereby improving the execution efficiency of the distributed storage system.
[0111] The data recovery processing apparatus for a distributed storage system provided in the embodiments of this application is described below. The data recovery processing apparatus for a distributed storage system described below can be referred to in correspondence with the data recovery processing method for a distributed storage system described above.
[0112] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of a data recovery processing device for a distributed storage system provided in an embodiment of this application.
[0113] In this embodiment, the device may include:
[0114] The request merging module 100 is used to merge the content of the write request and the corresponding data content when the object of the write request exists in the set of objects to be recovered, so as to obtain a write recovery transaction;
[0115] The transaction sending module 200 is used to send the write recovery transaction to the corresponding second data device so that the second data device can perform data recovery based on the write recovery transaction and return a completion message when the data recovery is complete.
[0116] The object deletion module 300 is used to delete objects from the collection of objects to be recovered when a completion message is received.
[0117] Optionally, the device may also include:
[0118] The second module for deleting records to be recovered is used to delete objects from the local collection of objects to be recovered.
[0119] Optionally, the request merging module 100 is specifically used to read the data content of the object; merge the modified content of the write request with the data content to obtain the full recovery data; and construct a write recovery transaction based on the full recovery data.
[0120] Optionally, the data recovery process based on write recovery transactions by the second data device may include:
[0121] The second data device performs full data recovery based on write recovery transactions.
[0122] Optionally, the device may also include:
[0123] The recovery request processing module is used to construct a recovery request based on the data of the object to be recovered; and send the recovery request to the corresponding second data device so that the second data device can perform data recovery based on the object version number of the recovery request and the local object version number.
[0124] Optionally, the second data device performs a data recovery process based on the object version number of the recovery request and the local object version number, including:
[0125] The second data device determines whether the local object version number is less than the object version number in the recovery request; if so, it performs data recovery based on the recovery request and sends a recovery success message; otherwise, it sends a recovery success message.
[0126] Optionally, the device may also include:
[0127] The first module for deleting records to be recovered is used to delete objects to be recovered from the collection of objects to be recovered.
[0128] In this embodiment, the content of the write request and the corresponding data are merged into a write recovery transaction and then sent to the second data device. This allows the second data device to process the write request and recovery request simultaneously in one execution process, avoiding delays in the write request and achieving simultaneous processing of the write request and recovery request, thereby improving the execution efficiency of the distributed storage system.
[0129] This application also provides a server, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the structure of a server provided in an embodiment of this application. The server may include:
[0130] Memory, used to store computer programs;
[0131] A processor, used to execute computer programs, can implement the steps of a data recovery processing method for any of the distributed storage systems described above.
[0132] like Figure 5 The diagram shows the structural composition of a server, which may include a processor 10, a memory 11, a communication interface 12, and a communication bus 13. The processor 10, memory 11, and communication interface 12 all communicate with each other through the communication bus 13.
[0133] In this embodiment, the processor 10 may be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic devices.
[0134] The processor 10 can call the program stored in the memory 11. Specifically, the processor 10 can execute the operations in the embodiment of the abnormal IP identification method.
[0135] The memory 11 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment, the memory 11 stores at least a program for implementing the following functions:
[0136] When the object of the write request exists in the set of objects to be recovered, the first data device merges the content of the write request with the corresponding data content to obtain a write recovery transaction;
[0137] The write recovery transaction is sent to the corresponding second data device so that the second data device can perform data recovery based on the write recovery transaction and return a completion message when the data recovery is complete.
[0138] When a completion message is received, the object is removed from the collection of objects to be restored.
[0139] In one possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.
[0140] In addition, memory 11 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.
[0141] Communication interface 12 can be an interface for the communication module, used to connect with other devices or systems.
[0142] Of course, it should be noted that, Figure 5 The structure shown does not constitute a limitation on the server in the embodiments of this application. In practical applications, the server may include more than [other components]. Figure 5 More or fewer components as shown, or combinations of certain components.
[0143] In this embodiment, the content of the write request and the corresponding data are merged into a write recovery transaction and then sent to the second data device. This allows the second data device to process the write request and recovery request simultaneously in one execution process, avoiding delays in the write request and achieving simultaneous processing of the write request and recovery request, thereby improving the execution efficiency of the distributed storage system.
[0144] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps of any of the data recovery processing methods described above for a distributed storage system.
[0145] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0146] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.
[0147] In this embodiment, the content of the write request and the corresponding data are merged into a write recovery transaction and then sent to the second data device. This allows the second data device to process the write request and recovery request simultaneously in one execution process, avoiding delays in the write request and achieving simultaneous processing of the write request and recovery request, thereby improving the execution efficiency of the distributed storage system.
[0148] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.
[0149] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0150] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0151] The foregoing has provided a detailed description of a data recovery processing method, data recovery processing apparatus, server, and computer-readable storage medium for a distributed storage system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A data recovery processing method for a distributed storage system, characterized in that, include: When the object of the write request exists in the set of objects to be recovered, the first data device merges the content of the write request with the corresponding data content to obtain a write recovery transaction; The write recovery transaction is sent to the corresponding second data device so that the second data device can perform data recovery based on the write recovery transaction and return a completion message when the data recovery is complete. When a completion message is received, the object is removed from the set of objects to be restored.
2. The data recovery processing method according to claim 1, characterized in that, When the data recovery of the second data device is complete, it also includes: The second data device removes the object from the local set of objects to be recovered.
3. The data recovery processing method according to claim 1, characterized in that, The first data device merges the write request content and the corresponding data content to obtain a write recovery transaction, including: The first data device reads the data content of the object; The modified content of the write request is merged with the data content to obtain the full recovery data; The write recovery transaction is constructed based on the full recovery data.
4. The data recovery processing method according to claim 3, characterized in that, The second data device performs data recovery based on the write recovery transaction, including: The second data device performs full data recovery based on the write recovery transaction.
5. The data recovery processing method according to claim 1, characterized in that, Also includes: The first data device constructs a recovery request based on the data of the object to be recovered; The recovery request is sent to the corresponding second data device so that the second data device can perform data recovery based on the object version number of the recovery request and the local object version number.
6. The data recovery processing method according to claim 5, characterized in that, The second data device performs data recovery based on the object version number of the recovery request and the local object version number, including: The second data device determines whether the local object version number is less than the object version number of the recovery request; If so, data recovery is performed based on the recovery request, and a recovery success message is sent. If not, a recovery success message will be sent.
7. The data recovery processing method according to claim 6, characterized in that, When the first data device receives the recovery success message, it also includes: Remove the object to be recovered from the set of objects to be recovered.
8. A data recovery processing device for a distributed storage system, characterized in that, include: The request merging module is used to merge the content of the write request and the corresponding data content when the object of the write request exists in the set of objects to be recovered, so as to obtain a write recovery transaction; The transaction sending module is used to send the write recovery transaction to the corresponding second data device so that the second data device can perform data recovery based on the write recovery transaction and return a completion message when the data recovery is completed. The object deletion module is used to delete the object from the set of objects to be recovered when a completion message is received.
9. A server, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the data recovery processing method as described in any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the data recovery processing method as described in any one of claims 1 to 7.
Citation Information
Patent Citations
Data recovery method and device
CN107544869A
Data writing and data restoration method and device, electronic device and storage medium
CN108572793A