A method and apparatus for fast data replication

Abstract

The purpose of the present application is to provide a method and device for rapid data replication. The present application receives a plurality of write requests sent by a client on each target storage node, generates a Raft log based on the write requests; for each write request, data stripping is performed on metadata and data itself in the Raft log to obtain an improved Raft log and actual data; each piece of actual data is randomly copied to the corresponding target storage node, and sequential application is performed according to the improved Raft log. Thus, the protocol level is improved, the actual data only needs to be written once, the storage space occupation is reduced, the timing of the replication algorithm is improved, and the performance is further improved.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a method and apparatus for rapid data copying. Background Technology

[0002] The Raft protocol is frequently used in distributed storage systems. Raft logs record operations on a state machine, which corresponds to the distributed storage system being synchronized. Raft nodes maintain a consistent state by ensuring the same log application order. Raft logs typically include metadata such as the target address and target length, as well as the actual data itself. However, writing data to these logs presents several problems: First, the logs consume significant space, which can only be reclaimed after nodes apply the logs and take a Raft snapshot. Second, the actual data to be written is first written to the logs and then decoded from them before being written to the target storage, resulting in poor performance and increased storage wear. Third, the sequential execution of log entries (metadata and the actual data to be written) further impacts performance.

[0003] To address the aforementioned issues, Chinese patent application (CN117492661A) discloses a data writing method, medium, apparatus, and computing device. In response to a data write request received by a leader node, the leader node writes the data write request to its Raft file. In response to a majority response received by the leader node, the state in the leader node's state machine is updated based on the majority response, and a second starting position of the target write address in the virtual disk file is determined. The first disk block mapping relationship is exchanged with the second disk block mapping relationship. However, this solution has significant limitations. It relies heavily on the file system, requiring some form of remapping at the file system level, and fails to propose improvements at the replication protocol level. It may not solve the Raft log capacity consumption problem and cannot solve the problem of sequential writing of the entire Raft log. Summary of the Invention

[0004] One objective of this application is to provide a method and apparatus for fast data replication, which solves the problems of storage space occupation and accelerated storage wear caused by the need for additional replication in the prior art, as well as the failure to improve the replication protocol level.

[0005] According to one aspect of this application, a method for rapid data copying is provided, the method comprising:

[0006] On each target storage node, multiple write requests sent by the client are received, and Raft logs are generated based on the write requests;

[0007] For each write request, the metadata in the Raft log is separated from the data itself to obtain the improved Raft log and the actual data;

[0008] Each piece of actual data is copied out of order to the corresponding target storage node and applied sequentially according to the improved Raft log. Each piece of actual data can be addressed by a corresponding unique identifier.

[0009] Optionally, each target storage node is a storage node within the same Raft protocol.

[0010] Optionally, multiple write requests sent by the client are received on each target storage node, and Raft logs are generated based on the multiple write requests, including:

[0011] On each target storage node, multiple write requests carrying unique identifiers are received from the client. Raft logs are generated based on these multiple write requests, and the unique identifiers are written into the Raft logs.

[0012] Optionally, each piece of actual data is copied out of order to the corresponding target storage node, including:

[0013] Determine the actual data generated by each target storage node in the order of the write requests it receives;

[0014] Each piece of actual data is written to the corresponding target storage node in an append-only manner, thus completing the out-of-order replication.

[0015] Optionally, each piece of actual data is written to the corresponding target storage node in an append-only manner, including:

[0016] Each piece of actual data is written to each target storage node in the order in which the actual data is obtained, and after each piece of data is written, the metadata of that actual data in the storage node is written. The metadata of the actual data stored in the storage node includes the length of the previous piece of actual data and a unique identifier.

[0017] Optionally, sequential application based on the improved Raft logs includes:

[0018] The metadata on the target storage node is located based on the unique identifier recorded in the Raft log. If found, a commit record containing valid data is sequentially written to the storage node. This record contains the unique identifier of the data or directly contains the starting address and length of the corresponding data.

[0019] According to another aspect of this application, a device for rapid data copying is also provided, the device comprising:

[0020] One or more processors; and

[0021] A memory storing computer-readable instructions, which, when executed, cause the processor to perform operations as described above.

[0022] According to another aspect of this application, a computer-readable medium is also provided, having stored thereon computer-readable instructions that can be executed by a processor to implement the method as described above.

[0023] Compared to existing technologies, this application receives multiple write requests from clients on each target storage node and generates Raft logs based on these requests. For each write request, the metadata in the Raft log is separated from the data itself, resulting in an improved Raft log and the actual data. Each copy of the actual data is then copied out of order to the corresponding target storage node and applied sequentially according to the improved Raft log. This improves the protocol level, requiring the actual data to be written only once, reducing storage space usage and improving the timing of the replication algorithm, thus further enhancing performance. Attached Figure Description

[0024] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0025] Figure 1 A schematic flowchart of a method for rapid data copying according to one aspect of this application is shown.

[0026] Figure 2 This illustration shows a schematic diagram of the data replication process based on the Raft protocol in a distributed storage system according to an embodiment of this application;

[0027] Figure 3 This diagram illustrates a data appending method in one embodiment of the present application.

[0028] Figure 4 This diagram illustrates the generation of commit records in one embodiment of this application.

[0029] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0030] The present application will now be described in further detail with reference to the accompanying drawings.

[0031] In a typical configuration of this application, the terminal, the device of the service network, and the trusted party all include one or more processors (e.g., a central processing unit (CPU)), input / output interfaces, network interfaces, and memory.

[0032] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0033] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined in this article, computer-readable media do not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0034] Figure 1 This diagram illustrates a flowchart of a rapid data copying method according to one aspect of this application, the method comprising: steps S11 to S13, wherein,

[0035] Step S11: Receive multiple write requests sent by the client on each target storage node, and generate Raft logs based on the write requests; wherein each target storage node is a storage node within the same Raft protocol. Here, the Raft log is a series of ordered logs, and each Raft protocol has a Raft replication group, which includes multiple nodes. Data is replicated to each node using the same Raft protocol, and the final data write order exhibited by each node is consistent. The client sends multiple write requests, such as... Figure 2 As shown, requests 1, 2, 3 and 4 are sent. When the storage node receives these requests, it generates the corresponding Raft logs, which record the four data corresponding to the four requests in an orderly manner.

[0036] Step S12: For each write request, the metadata in the Raft log is separated from the data itself to obtain an improved Raft log and the actual data. Here, each write request generates one set of data, and multiple data sets are recorded in the log in an orderly manner. The metadata information contained in the Raft log is separated from the multiple data sets themselves. For example, for requests 1, 2, 3, and 4, the generated log includes data 1, data 2, data 3, data 4, and metadata information. These four sets of data are separated from the metadata information to obtain the actual data 1, 2, 3, and 4, and a new Raft log containing only the metadata. This ensures that subsequent write operations only write the actual data, and the real data is written only once, reducing storage space usage.

[0037] Step S13 involves copying each piece of actual data out of order to the corresponding target storage node, and then applying it sequentially according to the improved Raft log. Each piece of actual data can be addressed by a unique identifier. The order in which different write requests are received by the target storage node will differ, resulting in different data writing orders. The order in which each piece of data is generated on different target storage nodes will also differ, leading to different copying orders. Each piece of actual data can be addressed by its corresponding unique identifier, which is generated by the client for each request. The data is not written in the order recorded in the log, such as data 1, data 2, data 3, and data 4, but rather in a random order. For example, data is copied on target storage node A in the order of data 1, data 3, data 2, and data 4, while on target storage node B it is in the order of data 2, data 1, data 3, and data 4 – a randomized write method. However, during application, it is executed sequentially according to the Raft metadata, that is, according to the time sequence in the metadata, ensuring that the data ultimately displayed on each target storage node is consistent. For example, on target storage node A, the data to be written is searched according to the logs of data 1, data 2, data 3, and data 4, which is represented as write 1, write 2, write 3, and write 4. On target storage node B, data 2, data 1, data 3, and data 4 are read according to the time order of Raft metadata, which is also represented as write 1, write 2, write 3, and write 4. Thus, the logs on target storage node A and target storage node B remain consistent, meaning the log write order is still the same. This achieves out-of-order data replication and sequential application of metadata, reducing the need for repeated data copying, storage space consumption, and performance degradation caused by decoding metadata.

[0038] The method described in this application is applied to a distributed storage system that conforms to the Raft protocol. The distributed storage system refers to a storage system that uses cluster applications, network technology, and distributed storage file systems to bring together a large number of storage devices of various types (storage devices are also called storage nodes) in the network to work together through application software or application interfaces to jointly provide data storage and business access functions to the outside world.

[0039] In one embodiment of this application, in step S11, multiple write requests carrying unique identifiers sent by the client are received on each target storage node. A Raft log is generated based on these multiple write requests, and the unique identifier is written into the Raft log. Here, the client generates a unique identifier for each write request, and this identifier is written into the Raft log as part of the Raft log. The generated Raft log records the data itself generated according to the write requests.

[0040] In one embodiment of this application, in step S13, the actual data generated by each target storage node in the order of the write requests it receives is determined; each piece of actual data is written to the corresponding target storage node in an append-only manner, completing the out-of-order copying. Here, we continue to refer to... Figure 2 Taking four requests as an example, if storage node 1 receives the requests in the order of request 1, request 3, request 2, and request 4, then the generated data will be in the order of data 1, data 3, data 2, and data 4. However, the data in storage node 2 will be in the order of data 2, data 1, data 3, and data 4. Therefore, the data will not be copied on storage nodes 1 and 2 according to the execution order recorded in the logs (e.g., if the log order is data 1, data 2, data 3, and data 4). Instead, it will be written to storage node 1 in the order of data 1, data 3, data 2, and data 4. The data copying order on different storage nodes may be different; the data is copied out of order. Subsequently, the Raft log metadata can be used to directly copy the corresponding logs in order, i.e., copying them in the order of log 1, log 2, log 3, and log 4. This achieves the function of out-of-order data copying and sequential application of metadata.

[0041] Following the above embodiment, when appending data, each piece of actual data is written sequentially on each target storage node in the order in which the actual data is obtained. After each piece of data is written, its metadata on the storage node is written. The metadata of the actual data stored on the storage node includes the length and unique identifier of the previous piece of actual data. Here, the original Raft log is stripped into two parts: metadata describing the operation to be performed and the data itself. The metadata includes the type of operation, the starting address of the data, the length, etc. The improved Raft log only contains metadata to tell the storage engine which data is valid; the actual data itself is directly written to the target storage using an append-only method. Figure 3As shown, for example, if the order of requests arriving at the storage node is request 1, request 2, and request 3, and the corresponding data is data 1, data 2, and data 3, the storage node writes the data sequentially. Each time data is written, its metadata information (represented by the gray box) is written sequentially to describe the data being written, such as its length and unique identifier. This metadata is very small. After writing data 1, a log entry about data 1 is appended, then data 2 is written, and so on. The storage node's metadata controls the state of the written data, such as which data is visible and how effectively the storage node can manage space. Therefore, even if data is written out of order, as long as the metadata controls the data state, the order of the read data can be maintained, and data is written according to the time sequence recorded in the Raft log.

[0042] In one embodiment of this application, when the stripped actual data is directly written to disk, the order of each storage node may be different because the data is not in the Raft log. Therefore, it is necessary to control the consistency of data presentation on each node. This consistency is controlled by an improved Raft log (containing only metadata). For example, the data appending order on storage node 1 is data 1, data 2, data 3, and the data written sequentially on node B is data 1, data 2, data 3. The data on the nodes includes a state: whether it is visible or not. Initially, all data are in the invisible state. The two nodes follow the Raft protocol and execute log entries sequentially: [write data 1, write data 2, write data 3]. Assuming the execution completion times correspond to t1, t2, and t3 respectively, then after t1, data 1 becomes visible, and the application can read data 1; after t2, data 2 becomes visible, and the application can read data 2; after t3, data 3 becomes visible, and the application can read data 3. Regardless of whether the initial data writing order is out of order, as long as the corresponding metadata is read according to the metadata's temporal order, the final presentation to the user is still the metadata's temporal writing order. In other words, the order in which data is written to a node is not important, as long as the state of the data is controlled to ensure that the order in which the data is visible is consistent with the order of the execution log entries.

[0043] In one embodiment of this application, in step S13, metadata on the target storage node is searched based on the unique identifier recorded in the Raft log. If found, a commit record containing valid data is sequentially written to the storage node. This record contains the unique identifier of the data or directly contains the starting address and length of the corresponding data. Here, when appending data to the storage node, the Raft application log correspondingly appends a commit record to the storage node, marking which data is currently effective, such as... Figure 4The commits marked in the diagram indicate which data has taken effect. When Raft logs are applied on a node, the unique identifier is used to locate the metadata on the disk (i.e., ...). Figure 4 The part indicated by the gray box in the middle) finds the data record through the metadata on the disk, and generates a commit record on the disk (the part indicated by the lighter gray box). The record contains the address and length of the effective data or a unique identifier; the process of applying the log only needs to read the metadata and then add a fixed-length (very small) record sequentially.

[0044] Continue to refer to Figure 2 In a distributed system, four write requests sent by a client, received at the same access point, are dispatched to several storage nodes under the same Raft protocol. The corresponding data may arrive at storage nodes 1, 2, and 4 in different orders. Data is then appended to the corresponding storage nodes. On storage node 1, the appended data order is data 1, data 3, data 2, and data 4; on storage node 2, the order is data 2, data 1, data 3, and data 4; and on storage node 4, the order is data 1, data 2, data 3, and data 4. That is, the actual data corresponding to logs 1, 2, 3, and 4 is written to the storage nodes beforehand, rather than being included in the Raft logs. When the logs are replicated, this actual data needs to be copied repeatedly, consuming storage space. Following the log's chronological order, data 1, data 2, data 3, and data 4 are located on the storage nodes using unique identifiers and the relevant data is retrieved. When applying the logs, the data is copied sequentially: logs 1, 2, 3, and 4 are written. Ultimately, four copies of the data are stored on different nodes. Although the copying order may differ, the overall log order remains the same, achieving complete data replication within the original Raft protocol. This ensures that the data presented to the user across these storage nodes remains consistent. The log for data 4 is not yet displayed on storage node 3 because log replication takes time, and this node may experience power outages. However, the leader node will automatically copy the log for data 4 to the node with the missing log. On these three storage nodes, each time data is written, a corresponding log is written (indicated by a gray box), and the effective data is marked (indicated by a lighter gray box). As you can see, data 1 and data 2 are marked as effective in different locations, generating commit records. Separating the Raft logs from the actual data allows them to be copied according to different timing requirements, improving performance without compromising data security without violating Raft semantics. Figure 2As can be seen, the data writing order on the three storage nodes is different, but the execution of the Raft log remains consistent. The Raft protocol only needs to ensure that the state machine's state changes (i.e., data operations) are sequential. Storage clients can pre-copy a certain amount of data to the relevant nodes, freeing this relatively time-consuming logic from Raft's timing control. For example, assuming a request writes 1MB of data, using existing solutions, the Raft log would need to exceed 1MB (requiring some metadata). Subsequently, when executing the log, the log needs to be unpacked and another 1MB written to the state machine, occupying at least 2MB of space. However, using the method of this application, the Raft log, after stripping, only contains metadata. 1MB is directly and sequentially written to the storage nodes, along with a small amount of log data from other storage nodes, resulting in a total slightly larger than 1MB.

[0045] Furthermore, embodiments of this application also provide a computer-readable medium storing computer-readable instructions that can be executed by a processor to implement the aforementioned method for fast data copying.

[0046] In one embodiment of this application, a device for rapid data copying is also provided, the device comprising:

[0047] One or more processors; and

[0048] A memory storing computer-readable instructions, which, when executed, cause the processor to perform operations as described above.

[0049] For example, computer-readable instructions, when executed, cause the one or more processors to:

[0050] On each target storage node, multiple write requests sent by the client are received, and Raft logs are generated based on the write requests;

[0051] For each write request, the metadata in the Raft log is separated from the data itself to obtain the improved Raft log and the actual data;

[0052] Each piece of actual data is copied out of order to the corresponding target storage node and then applied sequentially based on the improved Raft log.

[0053] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

[0054] It should be noted that this application can be implemented in software and / or a combination of software and hardware, for example, using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In one embodiment, the software program of this application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. Furthermore, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0055] Furthermore, a portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. The program instructions invoking the methods of this application may be stored in a fixed or removable recording medium, and / or transmitted via data streams in broadcast or other signal carrying media, and / or stored in the working memory of a computer device operating according to the program instructions. Here, one embodiment of this application includes an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein, when the computer program instructions are executed by the processor, the apparatus is triggered to operate the methods and / or technical solutions based on the foregoing embodiments of this application.

[0056] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that it can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. Terms such as "first," "second," etc., are used to denote names and do not indicate any particular order.

Claims

1. A method for rapid data copying, characterized in that, The method includes: On each target storage node, multiple write requests sent by the client are received, and Raft logs are generated based on the write requests; For each write request, the metadata in the Raft log is separated from the data itself to obtain the improved Raft log and the actual data; Each piece of actual data is copied out of order to the corresponding target storage node and then applied sequentially based on the improved Raft log; This involves receiving multiple write requests from clients on each target storage node, and generating Raft logs based on these write requests, including: On each target storage node, the client receives multiple write requests carrying unique identifiers sent by the client, generates Raft logs based on the multiple write requests, and the client generates a unique identifier for each write request and writes the unique identifier into the Raft log. The step of copying each piece of actual data out of order to the corresponding target storage node includes: determining the actual data generated by each target storage node in the order of the write requests it receives; and writing each piece of actual data to the corresponding target storage node in an append-only manner to complete the out-of-order copying. This involves writing each piece of actual data to the corresponding target storage node in an append-only manner, including: Each piece of actual data is written to each target storage node in the order in which the actual data is obtained, and after each piece of data is written, the metadata of that actual data in the storage node is written. The metadata of the actual data stored in the storage node includes the length of the previous piece of actual data and a unique identifier.

2. The method according to claim 1, characterized in that, Each target storage node is a storage node within the same Raft protocol.

3. The method according to claim 1, characterized in that, Sequential application based on improved Raft logs, including: The metadata on the target storage node is located based on the unique identifier recorded in the Raft log; If found, a commit record containing valid data is sequentially written to the storage node. This record contains a unique identifier for the data or directly contains the starting address and length of the corresponding data.

4. A device for rapid data copying, characterized in that, The device includes: One or more processors; and a memory storing computer-readable instructions that, when executed, cause the processor to perform the operations of the method as described in any one of claims 1 to 3.

5. A computer-readable medium having stored thereon computer-readable instructions that can be executed by a processor to implement the method as described in any one of claims 1 to 3.

Images