KR20130043823A - Distributed storage system for maintaining data consistency based on log, and method for the same - Google Patents

Abstract

PURPOSE: A distribution storage system for maintaining data matching based on a log and a method thereof are provided to generate a log for an operation which is not performed and to perform the operation based on the log, thereby maintaining data matching. CONSTITUTION: A first node receives a request of a first operation; generates a log which shows failure of the first operation; and repeatedly attempts the first operation based on the log(270). When the first operation is performed, the first node deletes the log(280). The failure includes a case that an object, which is used in the first operation, is not existed in the first node. The first node performs the first operation after performing a second operation which includes generation of the object. [Reference numerals] (210) Receive a first command; (220,260) First operation can be performed?; (230) Generate a log indicating the failure of the first operation; (240,295) Output a success response for the first command; (250) Wait(perform a second operation); (270,290) Perform the first operation; (280) Delete the log; (AA) Start; (BB) End

Description

DISTRIBUTED STORAGE SYSTEM FOR MAINTAINING DATA CONSISTENCY BASED ON LOG, AND METHOD FOR THE SAME}

The following embodiments are directed to distributed storage systems and methods.

Disclosed are a distributed storage system that maintains data consistency based on logs and a method of maintaining data consistency of a distributed storage system based on logs.

Systems in which data is frequently bulk inserted can improve throughput by using cheap and large numbers of devices and distributing and storing the data among the devices.

As a large number of devices are used, the failures occurring in the devices themselves may increase, and the response time of the system may become difficult to ensure. To solve this problem, distributed storage systems can maintain and manage replicas. Here, the replicas refer to a plurality of devices that store the same data.

In a distributed storage system including a plurality of nodes, consistency between replicas storing the same data may be a problem. In other words, the replicas must each process operations in a different order from each other so that the data that each of the replicas has differs from each other.

One way to maintain consistency is to configure the operations provided to the replicas to satisfy commutativity and idempotent. Compatibility means that the results of performing the above operations will always be the same, even if certain operations are performed in a different order from each other. Idability means that the result when a specific operation is repeatedly performed is the same as the result when the above operation is performed once. For example, an operation that satisfies equality can be configured by restricting 1) performing an operation that is not equal, or 2) updating only a part of a row that is not the entire row of the table. An example of an unequal operation is self rereference. Equation "A = A + 1" is an example of self rereference.

Another way to maintain consistency is total ordering. Full ordering means how the replicas order the operations from one another, as the replicas perform the operations. To order the operations, the replicas can use global queues or locks, and can set up a master and a slave to each other. For example, the master of the replicas determines the order between the operations while performing the operations, and the slaves may perform the operations according to the determined order. However, when full ordering is used, if one node of the replica fails, the other nodes may also be affected from the failure.

In Korean Patent Publication No. 10-2008-0102622 (published November 26, 2008), a replication log is generated and transmitted to a distribution system through a transaction log of a master database, and a slave host to which replication logs are distributed is determined. Disclosed is a method of reflecting the replication log in a slave database by distributing the replication log to a corresponding slave host.

An embodiment of the present invention may provide a distributed storage system and a distributed storage method for generating a log of an operation that cannot be performed and maintaining the consistency of data by performing the operation later based on the log.

An embodiment of the present invention sets distributed end time of data copy, copies objects of data to target node, and distributes stored data to maintain consistency of data by re-copying the updated object to target node before the end time. It is possible to provide a system and a distributed storage method.

According to one aspect of the invention, in a distributed storage system, comprising a plurality of nodes, a first node of the plurality of nodes receives a request of a first operation, the first node to perform the first operation Generates a log indicating the failure of the first operation when a failure that cannot be performed occurs, the first node repeatedly attempts the first operation based on the log, and when the first operation is performed, the log. A distributed storage system is provided, which deletes it.

The failure may mean that an object used in the first operation does not exist in the first node.

The first node may perform the first operation after performing a second operation including creation of the object.

The timestamp of the first operation may represent a later time than the timestamp of the second operation.

The first operation may be an update operation on the object. The second operation may be an insert operation on the object.

The failure may be a network failure or a process failure of the first node.

According to one aspect of the invention, in a distributed storage system, comprising a plurality of nodes, a first node of the plurality of nodes receives a request of a first operation, the first node to perform the first operation When a failure that cannot be performed, a log indicating a failure of the first operation is generated and the log is transmitted to a second node of the plurality of nodes, and the second node stores the log and is based on the log. And periodically requesting the first node to attempt the first operation, and wherein the first node requests the second node to delete the log when the first operation is performed. .

According to another aspect of the present invention, in a distributed storage system, a plurality of nodes, a failed node is a failed node of the plurality of nodes, a source node is one of the replicas, the replicas are the One or more nodes providing the same data as the failed node of the plurality of nodes, a target node being a newly selected node as one of the replicas, replacing the failed node of the plurality of nodes, wherein the source node is the Recognizing the failure of the failure node, the source node sets an end time of copying data, copies objects of the data to the target node, updates the target node after being copied before the end time. A distributed storage system is provided that copies one object back to the target node.

The end time may be a time at which all of the plurality of nodes recognizes a copy to the target node and may also send an access request for the data to the target node.

The source node may copy the objects to the target node in ascending order of timestamps of each of the objects.

The source node may perform the copying on an object in which the time stamp among the objects indicates the end time or a previous time of the end time.

The coordination node of the plurality of nodes may receive an update request for the first object, the coordination node may transmit an update request for the first object to each of the source node and the target node, and The target node may generate a log indicating a failure of the update request when the first object does not exist, and update the first object based on the log after the first object is copied from the source node. Can be.

The source node performs an operation of inserting the second object into the target node when a second object does not exist in the target node, and the first node of the target node when the second object exists in the target node. The second object may be copied to the target node by performing an operation of updating an object.

According to another aspect of the present invention, a method of managing data in a distributed storage system using a plurality of nodes, the first node of the plurality of nodes receiving a request of the first operation, the first Generating a log indicating a failure of the first operation by the first node when a failure occurs in which one node cannot perform the first operation, and the first node repeats the first operation based on the log And deleting the first log when the first node performs the first operation.

The failure may mean that an object used in the first operation does not exist in the first node.

The retrying of the first operation may include: performing, by the first node, a second operation including generation of the first object, and performing the first operation after the second operation is performed. It may include.

According to another aspect of the present invention, a method of managing data in a distributed storage system using a plurality of nodes, the first node of the plurality of nodes receiving a request of the first operation, the first Generating a log indicating a failure of the first operation by the first node when a failure occurs in which one node cannot perform the first operation, and transmitting the log to the second node by the first node Storing the log by the second node; requesting the first node to attempt the first operation periodically based on the log; wherein the first operation may be performed If the first node performs the first operation, if the first operation is performed, the first node requests the second node to delete the log and the second operation. A method of managing data is provided, the method comprising the node deleting the log.

According to yet another aspect of the present invention, in a distributed storage system using a plurality of nodes to copy data between the nodes, the target node requesting a copy of the data from the source node-the source node is One of the replicas, wherein the target node is a newly selected node as one of the replicas of the plurality of nodes, replacing the failed one of the replicas, wherein the source node indicates the end time of the copy of the data. Setting, copying, by the source node, objects of the data to a target node, and copying, again, the updated first object before the end time after the source node is copied to the target node to the target node. Provided is a method of copying data in a distributed storage system.

The copying step may include the source node copying the objects to the target node in ascending order of timestamps of each of the objects.

The source node may perform the copying on an object in which the time stamp among the objects indicates the end time or a previous time of the end time.

The data copying method may further include: receiving, by the coordinating node of the plurality of nodes, an update request for the first object, the coordinating node, respectively, requesting the update of the first object from the source node and the target node. Transmitting, the target node generating a log indicating a failure of the update request if the first object does not exist, and the target node based on the log after the first object is copied from the source node The method may further include updating the first object.

A distributed storage system and distributed storage method are provided for generating a log of an operation that cannot be performed and maintaining the consistency of data by performing the operation later based on the log.

There is provided a distributed storage system and a distributed storage method for maintaining the consistency of data by setting an end time of copying data, copying objects of data to a target node, and copying an object updated before the end time to a target node. do.

The distributed storage system and distributed storage method transmit a new data access request to the target node to which the data is copied, and copy only objects having a timestamp indicating the time before the source node to the target node to the target node. Even if there are many objects that are inserted or updated as a result, data migration can be prevented from continuously extending.

1 illustrates a case where data mismatch occurs between nodes of a distributed storage system.
2 is a flowchart illustrating a method of managing data in a distributed storage system using a plurality of nodes according to an embodiment of the present invention.
3 is a flowchart illustrating a method for managing data in a distributed storage system by writing a log to a neighbor node according to an embodiment of the present invention.
4 illustrates a distributed storage system for copying data according to an embodiment of the present invention.
5 is a flowchart of a data copy method of a distributed storage system according to an embodiment of the present invention.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings. However, the present invention is not limited to or limited by the embodiments. Like reference symbols in the drawings denote like elements.

In the following, update is used in the same meaning as change, and update and change may be used interchangeably.

Each node in a distributed storage system manages data. A node may mean an execution unit for processing a specific task. For example, a node may mean a process or a server. The data may include one or more tables. Nodes can perform operations on the rows of a table. In the following embodiments, an object may mean a particular row of a particular table.

1 illustrates a case where data mismatch occurs between nodes of a distributed storage system.

The distributed storage system includes a first node 120 and a second node 130. The first node 120 and the second node 130 may be replicas replicating the same data.

Client 110 sends two commands 150 and 160 to a distributed storage system.

The insert command 150 requests an operation for inserting a into the object (or data) A. The time stamp of the insert command 150 is T1. Here, the time stamp of the insert command 150 may be viewed as a time stamp of an insert operation requested by the insert command 150. The update command 160 requests an operation to update the value of the object A to b. The time stamp of the update command 160 (or the update operation required by the update command 140) is T2. T1 and T2 represent the time when the client 110 actually requested each of the two instructions 150 and 160. T1 <T2.

The intention of the client 110 is to insert an object A having a value of 'a' into a distributed storage system and then update the value of the object A to 'b'. Two commands 150 and 160 are delivered to the first node 120 in the correct order. Accordingly, the first node 120 may normally process the two commands 150 and 160. On the other hand, in the second node 130, the update command 160 arrives first, and the insert command 150 arrives later. When the update command 160 arrives at the second node 130, there is no object A in the second node 130. Therefore, the update operation on the nonexistent object A fails. Thereafter, when the insert command 150 arrives at the second node 130, the insert command 150 is performed, so that the object A stored in the second node 130 has a value of 'a'.

As described above, depending on the order in which a plurality of commands are delivered to each node, a data mismatch problem may occur where multiple replicas have different values for a particular object.

In order to prevent such a data mismatch problem from occurring, the distributed storage system may use a method of sequentially executing the above instructions according to the time when the instructions are requested. Each command includes a timestamp indicating the time at which the command was requested, and each of the replicas may check the timestamp and perform the received commands in order. However, if the replica continues to wait for another command (e.g., insert command 150) to execute the command that arrived earlier (e.g., update command 160), the response time is guaranteed. Problems that may not be possible can occur.

An embodiment of the present invention, which will be described below, proposes a method of solving the data mismatch problem using a log indicating a failure of an operation.

2 is a flowchart illustrating a method of managing data in a distributed storage system using a plurality of nodes according to an embodiment of the present invention.

The distributed storage system may include a plurality of nodes. All or some of the nodes of the plurality of nodes may be replicas replicating the same data.

In the following, the failed node performing the steps 210 to 295 may be one of a plurality of nodes included in the distributed storage system, and may correspond to the second node 130 described above with reference to FIG. 1. have.

In step 210, the failed node receives the first command. The first command may be the update command 160 described above with reference to FIG. 1. The first command includes the first operation that the failed node should perform. The first command may mean requesting a first operation.

In step 220, the failed node determines whether the first operation can be performed. If it is possible to perform the first operation, the failed node performs the first operation (step 290). Next, the first node outputs a success response to the first command (step 295), and the procedure ends. Here, the output of the success response may mean that the failed node transmits a success response indicating that the execution of the first command was successful to the client that requested the first command.

In step 230, when a failure occurs in which the failure node cannot perform the first operation of the first command, the failure node generates a log indicating the failure of the first operation.

The failure may mean that the object used in the first operation (eg, object A in the operation of the update command 160) does not exist in the failure node. In this case, the generated log may be information indicating that the execution of the first operation failed because a specific object does not exist in the failed node. In this case, the disabled node may perform a first operation after performing a second operation (eg, operation of the insertion command 150) of the second command including generation of the object. For example, the first operation may be an update operation on a specific object, and the second operation may be an insert operation on the specific object. Here, the insert operation is considered to include the creation of an object that is the object of insertion as part of the operation, and the update operation does not include the creation of the object that is the object to be updated as part of the operation.

The first command and the second command may each include a time stamp. The time stamp of each instruction may be a time stamp of an operation included in the instruction. The timestamp of the first instruction (ie, the timestamp of the first operation) may represent a later time than the timestamp of the second instruction (ie, the timestamp of the second operation), and the faulty node may The order of instructions (or operations) can be known by comparing the times represented.

The log may be a log that the failed node leaves in local (ie, the failed node itself) for later performing the failed operation again. The log may be a log for the distributed storage system to provide eventual consistency, and may be referred to as an eventual query log (EQ log).

In step 240, the failed node may output a success response to the first command.

By means of steps 230 and 240, the failed node immediately outputs a success response with only a log generated without waiting for a failed operation to be performed. Thus, a failed node (or distributed storage system) can ensure immediate response time.

In steps 250 and 280, the failed node may repeatedly attempt the first operation based on the generated log.

In step 250, the failed node may wait for some time. During standby, the failed node may perform the second operation described above.

In step 260, the failed node determines whether the first operation can be performed. If the first operation still cannot be performed, step 250 is repeated. If the first operation can be performed, then at step 270, the failed node performs the first operation. Next, in step 280, the failed node deletes the log, after which the procedure ends. For example, when an object used in the first operation is generated by the failure node performing the second operation, the first operation may be performed.

The steps 210-295 described above can be performed individually by each of all nodes in the distributed storage system. By the method described above, each of the nodes can output an immediate response to each of the commands while maintaining the consistency of the data by performing the operations in the order of the commands. Thus, even if there is a faulty node in the distributed storage system, the client sending the command to the distributed storage system may not wait for a long time for a response to the command.

3 is a flowchart illustrating a method for managing data in a distributed storage system by writing a log to a neighbor node according to an embodiment of the present invention.

In this embodiment, the failure node described with reference to FIG. 2 stores a log indicating failure of the operation in a neighbor node in the distributed storage system, not the failure node itself, and is requested to retry the operation from the neighbor node. According to the configuration for performing the operation according to. The failing node 310 of the present embodiment may be the failing node described in FIG. 2.

Step 330 corresponds to steps 210-230 described above. The failure described in step 230 may be a network failure or process failure of the failed node 310. The failure may result in the loss of a particular instruction's operation.

In step 340, the failed node 310 transmits the generated log to the log node 320. The log node 320 is a neighbor node of the faulty node 310. Since the log is a log of a lost command (or operation), the log may be referred to as a lost query log (MQ log).

The failing node 310 may select one node of the plurality of nodes of the distributed storage system as the log node 320. The failure node 310 may preferentially select another node of the plurality of nodes as the log node 320 except for replicas that replicate the same data as itself. Through this selection, the faulty node 310 may maintain the sum of the number of nodes performing a specific operation and the number of nodes having a log of the failure of the specific operation.

There may be a plurality of log nodes 320. When the data of the failed node 310 is copied by n replicas, the log node 320 may be n − 1 nodes of a distributed storage system. By using the plurality of log nodes 320, it is possible to prevent the log from being lost even when another node in the replica additionally fails. When there are a plurality of log nodes 320, the steps 345, 350, and 380 to be described below may be performed by each of the plurality of log nodes 320.

In step 345, log node 320 stores the transmitted log.

In steps 350-355, log node 320 periodically requests failed node 310 to attempt a first operation based on the stored log.

In step 350, the log node 320 checks the stored log and requests the failed node 310 to attempt the first operation.

In step 355, the failure node 310 receiving the request determines whether or not the first operation can be performed. If the first operation can be performed, step 360 is performed. If the first operation cannot be performed, step 350 is repeated periodically.

In step 360, the failed node 310 recovering from the failure performs a first operation.

In step 370, the failed node 310 requests the log node 320 to delete the log.

In step 380, log node 320 deletes the log.

4 illustrates a distributed storage system for copying data according to an embodiment of the present invention.

In this embodiment, when a failure occurs in one node of the replicas 410 of the distributed storage system 400, a method of copying data to another node is disclosed.

A node may fail in one of the replicas 410 that copies and stores the same data. The failed node 420 is a failed node of the replicas 410, and the replicas 410 are one or more nodes that provide the same data as the failed node 420 of a plurality of nodes of the distributed storage system 400. . Due to the occurrence of the failure, it may be impossible to access the data of the failed node 420. In the event of a failure, one of the replicas 410 except for the failed node 420 should copy its data to another node that operates normally, and add the node to which the data has been copied as a new replica. When the copy is completed and the location information of the replicas 410 is updated, the distributed storage system 400 may keep the number of replicas 410 constant. Replica migration means copying as described above.

One node of the replicas 410 recognizes the failure of the failed node 420 and copies its data to one of the nodes of the distributed storage system 400 that is not included in the replicas 410. The source node 430 is a node that recognizes the failure of the failure node 420. The target node 450 is a node to which data of the source node 430 is copied. The target node 450 is a newly selected node as one of the replicas 410 in place of the failed node 420 of the plurality of nodes of the distributed storage system 400. The replica node 440 is the remaining node of the replicas 410 except for the failed node 420 and the source node 430.

Client 490 is a node requesting data access to distributed storage system 400. The coordination node 460 is a node that receives the request from the client 490 and replicates the data access request to each of the replicas 410 that replicate the data. The coordination node 460 may be any node that is requested to access data from the client 490 of the plurality of nodes of the distributed storage system 400. For example, one node of replicas 410 may also be a coordinating node 460.

  The data access request may be sent to the replica node 440 and the source node 430, and may be sent to the failed node 420 or the target node 450. For example, when the coordination node 460 does not recognize that a failure has occurred at the failure node 420, a data access request is sent to the failure node 420, and the coordination node 460 has a target node 450 at the failure node. When it is recognized that it replaces 420, a data access request may be sent to the target node 450.

When the replica migration is executed, the entire data of the source node 430 (eg, all the tables in the local database of the source node 430) is read and the read entire data is inserted into the target node 450. Even while source node 430 is executing a replica migration, distributed storage system 400 may receive data access requests from clients. In this case, it may be difficult to accurately copy additionally introduced data to the target node 450 unless the distributed storage service of the source node 430 is stopped.

In order to copy data without interrupting the distributed storage service, distributed storage system 400 maintains a timestamp for all data (eg, rows of objects or tables).

A specific method for replica migration is described in detail below with reference to FIG.

Technical contents according to an embodiment of the present invention described above with reference to FIGS. 1 to 3 may be applied to the present embodiment as it is. Therefore, more detailed description will be omitted below.

5 is a flowchart of a data copy method of a distributed storage system according to an embodiment of the present invention.

The distributed storage system 400 may further include a management node 500 that manages data copying.

At step 510, management node 500 recognizes a failure of failed node 420.

In step 512, the management node 500 selects one of the plurality of nodes of the distributed storage system 400 except the replicas 410 as the target node 450 to which the data is to be replicated. Can be. The management node 500 determines that 1) the failure has occurred at the failed node 420, and 2) that the target node 450 has been selected to replace the failed node 420. Or nodes other than a particular node).

In step 514, the coordination node 460 instructs the target node 450 to copy (ie, migrate) the data from the source node 430.

At step 516, target node 450 registers a copy of the data with source node 430.

In step 520, the source node 430 sets the end time of copying the data. The above end time indicates that all of the plurality of nodes in the distributed storage system 400 (or the remaining nodes except the failed node 420) recognize the copy of the data to the target node 450 and request a data access request. It may be a time that can also be sent to the target node 450 or a time after the above time.

In step 530, the source node 430 may sort the objects of data in ascending order of timestamps of each of the objects.

In step 540, the data of the source node 430 (ie, the objects that make up the data) are copied to the target node 450. The above copy may mean that the target node 450 inserts data read from the database of the source node 430 into its database.

In step 540, the source node 430 makes a copy of the objects of the data whose time stamps indicate the end time or the previous time of the end time. The source node 430 may copy the objects having a time stamp indicating a later time than the time indicated by the time stamp, based on the time stamp of the last copied object.

Step 540 may be performed again. When the copy of the data is completed, newly added data may be copied from the source node 430 to the target node 450 again after the point in time at which the copy of the data is registered in step 516.

If the object is updated after the end time, the data access request for the update is also sent to the target node 450. Therefore, since the update is performed in the target node 450 itself, the object does not need to be copied again from the source node 430.

Step 550 indicates that each of the objects of the source node 430 is copied to the target node 450. By repeatedly executing step 550, source node 430 may copy objects to target node 450 in ascending order of timestamps of each of the objects.

While step 540 is performed, steps 560-570 may be performed.

At step 560, the coordination node 460 receives an update request for the first object.

At step 565, the coordination node 465 sends an update request for the first object to each of the source node 430 and the target node 450. The source node 430 may update the value of the first object and change the value of the time stamp of the first object to the latest time.

Before the update request for the first object is generated within the target node 450 (ie, before the source node 430 copies the first object to the target node 450), the target node 450 ), The target node 450 may not update the first object that does not exist. Thus, the update request fails, and at step 570, the target node 450 may generate a log indicating the failure of the update request. Thereafter, by copying data 540, the first object is copied to the target node 450. After the first object has been copied, in step 590, the target node 450 may update the first object based on the log. After the first object is updated, at step 595, target node 450 deletes the log.

If the update request for the first object has been sent to the target node 450 after the source node 430 has copied the first object to the target node 450, and the time at which the first object was changed is before the end time, step At 580, the source node 430 may recopy the first object to the target node 450. In this case, the recopy may be performed through an update operation. That is, when the first object to be copied does not exist in the target 'node 450, the copying of the object may mean that the source node 430 performs an operation of inserting the second object into the target node 450. Can be. In addition, when the first object to be copied exists in the target node 450, the copying of the object may mean that the source node 430 performs an operation of updating the first object of the target node 450. . For example, if the first object to be copied already exists in the target node 450, an insert operation for copying the first object may be changed to an update operation.

Unlike conventional data migration, the objects of the source node 430 are not frozen during data copy. Therefore, the original data (that is, the data in the source node 430) can be continuously updated, and an object already copied to the target node 450 can also be copied again after the update by changing the timestamp to the latest value. have. In addition, 1) by sending a new data access request to the target node 450, and 2) the source node 430 copies only the objects having a timestamp indicating the time before the end time to the target node 450, In the case of many newly updated (or inserted) objects, the copying time can be prevented from being continuously extended.

In step 585, the target node 450 where the data copying is completed may notify the management node 500 of the completion of the data copying. The management node 500 may inform all nodes of the distributed storage system 400 that the target node 450 has become one of the replicas 410.

Technical contents according to an embodiment of the present invention described above with reference to FIGS. 1 to 4 may be applied to the present embodiment as it is. Therefore, more detailed description will be omitted below.

Method according to an embodiment of the present invention is implemented in the form of program instructions that can be executed by various computer means may be recorded on a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be those specially designed and constructed for the present invention or may be available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

As described above, the present invention has been described by way of limited embodiments and drawings, but the present invention is not limited to the above embodiments, and those skilled in the art to which the present invention pertains various modifications and variations from such descriptions. This is possible.

Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined by the equivalents of the claims, as well as the claims.

400: distributed storage system
410: replicas
420: failed node
430: source node
440: replica node
450: target node
460: Coordination Node
500: managed node

Claims (20)

In a distributed storage system,
Multiple nodes
/ RTI &gt;
A first node of the plurality of nodes receives a request for a first operation, and the first node generates a log indicating a failure of the first operation when a failure in which the first operation cannot be performed occurs. The first node repeatedly attempts the first operation based on the log, and deletes the log when the first operation is performed. The method of claim 1,
The obstacle includes a case in which the object used in the first operation does not exist in the first node, and the first node performs the first operation after performing a second operation including generation of the object. Distributed storage system. The method of claim 2,
And the timestamp of the first operation represents a later time than the timestamp of the second operation. In a distributed storage system,
Multiple nodes
/ RTI &gt;
A first node of the plurality of nodes receives a request for a first operation, and the first node generates a log indicating a failure of the first operation when a failure in which the first operation cannot be performed occurs. Transmits to a second node of the plurality of nodes,
The second node stores the log, periodically requests the first node to attempt the first operation based on the log, and the first node requests the second node when the first operation is performed. Requesting deletion of the log from the distributed storage system. In a distributed storage system,
Multiple nodes
/ RTI &gt;
The failed node is a failed node of the plurality of nodes, the source node is one of the replicas, the replicas are one or more nodes providing the same data as the failed node of the plurality of nodes, and the target node is the A node newly selected as one of the replicas, replacing the failed node of the plurality of nodes,
The source node recognizes the failure of the failure node, the source node sets an end time of the copy of data, copies the objects of data to the target node, and the end time after being copied to the target node. Copying a previously updated first object back to the target node. The method of claim 5,
And the end time is a time at which all of the plurality of nodes can recognize a copy to the target node and can also send an access request for the data to the target node. The method of claim 5,
The source node copies the objects to the target node in ascending order of timestamps of each of the objects. The method of claim 7, wherein
And the source node performs the copying on the object of which the timestamp indicates the end time or a previous time of the end time. The method of claim 5,
The coordination node of the plurality of nodes receives an update request for the first object, the coordination node transmits an update request for the first object to each of the source node and the target node, and the target node is And generating a log indicating failure of the update request when the first object does not exist, and updating the first object based on the log after the first object is copied from the source node. The method of claim 5,
The source node performs an operation of inserting the second object into the target node when a second object does not exist in the target node, and the first node of the target node when the second object exists in the target node. 2) copying the second object to the target node by performing an operation to update the object. In a method for managing data in a distributed storage system using a plurality of nodes,
Receiving, by a first node of the plurality of nodes, a request for a first operation;
Generating a log indicating a failure of the first operation by the first node when a failure in which the first operation cannot be performed occurs in the first node;
The first node repeatedly attempting the first operation based on the log; And
Deleting the first log when the first node performs the first operation
/ RTI &gt;
How to manage your data. The method of claim 11,
The failure includes a case in which the object used in the first operation does not exist in the first node,
Attempting to repeat the first operation,
Performing, by the first node, a second operation including creation of the first object; And
Performing the first operation after the second operation is performed
Including,
And the timestamp of the first operation represents a later time than the timestamp of the second operation. In a method for managing data in a distributed storage system using a plurality of nodes,
Receiving, by a first node of the plurality of nodes, a request for a first operation;
Generating a log indicating a failure of the first operation by the first node when a failure in which the first operation cannot be performed occurs in the first node;
The first node sending the log to the second node;
The second node storing the log;
The second node periodically requesting the first node to attempt the first operation based on the log;
If the first operation can be performed, performing the first operation by the first node;
When the first operation is performed, requesting the second node to delete the log from the first node; And
The second node deleting the log
Comprising a data management method. In a distributed storage system using a plurality of nodes to copy data between the nodes,
A target node requesting a copy of data from a source node, wherein the source node is one of the replicas, the target node replacing one of the failed failed ones of the replicas as one of the replicas of the plurality of nodes; Is a newly selected node-;
Setting, by the source node, an end time of copying of the data;
Copying the objects of data to a target node by the source node; And
Copying the first object updated before the end time back to the target node after the source node is copied to the target node.
Comprising a data copy method of a distributed storage system. 15. The method of claim 14,
And the end time is a time at which all of the plurality of nodes recognizes a copy to the target node and can also send an access request for the data to the target node. 15. The method of claim 14,
Wherein the copying comprises:
The source node copying the objects to the target node in ascending order of timestamps of each of the objects;
Comprising a data copy method of a distributed storage system. 17. The method of claim 16,
And the source node performs the copying on the object among the objects whose timestamp indicates the end time or a previous time of the end time. 15. The method of claim 14,
Receiving, by the coordinating node of the plurality of nodes, an update request for the first object;
Sending, by the coordinating node, an update request for the first object to each of the source node and the target node;
Generating, by the target node, a log indicating a failure of the update request when the first object does not exist; And
Updating, by the target node, the first object based on the log after the first object is copied from the source node
Further comprising, the data copy method of the distributed storage system. 15. The method of claim 14,
When the second object that is the target of the copy does not exist in the target node, the copying is performed by a source node to insert the second object into the target node, and the second object exists in the target node. If the copying is performed by the source node performing an operation of updating the second object of the target node. A computer-readable recording medium containing a program for performing the method of any one of claims 11 to 19.

Images