METHOD AND SYSTEM FOR MANAGING REPLICATION OF DATA

Abstract

Data replication management which enables rapid retrieval while increasing the performance of the entire system, and maintaining data synchronization regarding successively updated data is performed. There are steps which comprises a step that when a slave node which has received an instruction for retrieval does not receive a return massage from a master node within a predetermined time period (Ts1) from the transmission of a request message to the master node, the slave node requests the master node to provide a transaction log up to the latest version with respect to the update of a master database; a step that the master node which has received the request transmits the transaction log to the slave node; and a step that the slave node updates a replica database with reference to the transaction log transferred from the master node.

Description

TECHNICAL FIELD

The present invention relates to a method and system for managing the replication of data, and more specifically relates to a method and system for managing the replication of data between a database of a computer (node) connected to a network and a database of another node to which a search is requested.

BACKGROUND ART

In recent years, a technology for realizing a replication system by applying a transaction log has been proposed. With a transaction log, it is possible to realize high-speed operation while maintaining the permanence of database changes by recording a history of changes implemented to a database in an area different from a recording area of the database. A history of all updates is stored in a transaction log, thus it is possible to reconstruct all updates of the database as long as the transaction log is stored.

Proposed as a synchronization method of data with a transaction log is a method for completing a synchronization process of data between a master node and slave nodes when a transfer source node (master node) starts keeping a transaction log in a recording area, transfers the same transaction log to all the other nodes existing in a replication system, the transfer destination nodes (slave nodes) notify the master node of completion after completing the receipt of the transaction log, the master node receives the notifications of completion from all the slave nodes, and a recording process in its own recording area ends (see Patent Document 1, for example). In this method, it is possible to quickly execute a search process since it is unnecessary to inquire again of the master node about the latest information when the slave node makes a search.

DOCUMENTS OF PRIOR ARTS

Patent Document

Patent Document 1: Japanese Patent Application Laid-Open No. 2006-293910

SUMMARY OF THE INVENTION

Problems to be Solved by the Invention

However, the above data synchronization method has a problem that whenever a database (a “database” may hereinafter be referred to as “DB”) of a master node is changed, deleted and updated (“change, delete, and update” may hereinafter be referred to as “update”), a synchronization process with all replica DBs (“databases of transfer destination nodes” in Patent Document 1) is performed so that if a synchronization process of any replica DB takes time because of a failure in any one of any node and a communication path thereof, it takes time to complete the synchronization process and the performance of an entire system decreases.

A main object of the present invention is to provide a method and system for managing the replication of data, which improve the above problem and encourage an improvement in the performance of the entire system while maintaining synchronization of data sequentially updated and enabling a speedy search through the data.

Means for Solving the Problems

According to a first aspect of the present invention, it is characterized in that a slave node that has received a search instruction requests from a master node a transaction log up to the latest version related to updates of a master DB in a case of not receiving a reply message from the master node within a specified time (T_s1) since the time of the transmission of a request message to the master node, the master node that has received the request transmits the transaction log to the slave node, and the slave node updates a replica DB with reference to the transaction log transferred from the master node.

In the present invention, it is preferable that the slave node that has received the search instruction should update the replica database with reference to an already received transaction log in a case of receiving a reply message from the master node within the specified time (T_s1). In this manner, it is possible to improve the performance of the entire system particularly when the frequency of searches is not high since the application of the transaction log is delayed and the replica DB is updated after the transaction log is applied only when a search instruction is received.

In the present invention, it is preferable that the master node, which has received an update instruction, should complete an update in accordance with the update instruction after receiving notifications of completion of transfer from all the slave nodes that have received a new request message within a specified time (T_r1) since the time of the receipt of the request message and completing an update of the master DB. In this manner, the master node can execute a synchronization process with nodes from which a node that takes time for communication is eliminated among the slave nodes and complete an update process speedily even if trouble occurs in any one of any slave node and a communication path thereof.

According to a second aspect of the present invention, it is characterized in that a slave node that has received a search instruction requests a transaction log up to the latest version related to updates of the master DB from a parent node thereof in a case of not receiving a reply message from the parent node within a specified time (T_s3) since the time of the transmission of a request message to the parent node, that the parent node requests the transaction log from a further parent node thereof is repeated until reaching a node having the transaction log in a case where the parent node does not have the transaction log, that the node having the transaction log that has received the request transmits the transaction log to child nodes thereof and the child nodes that have received the transmission transmit the transaction log further to child nodes of thereof at a lower order is repeated until the slave node receives the transaction log, and the slave node updates a replica DB with reference to the transferred transaction log.

In the present invention, it is preferable that the slave node that has received the search instruction should update the replica DB with reference to an already received transaction log in a case of receiving a reply message from the parent node within the specified time (T_s3). In this manner, it is possible to improve the performance of the entire system particularly when the frequency of searches is not high since the application of the transaction log is delayed and the replica DB is updated after the transaction log is applied only when a search instruction is received.

In the present invention, it is preferable that each node should transmit a notification of completion of transfer to a parent node thereof after transmitting to child nodes thereof the transaction log up to the latest version related to updates of the master DB and receiving notifications of completion of transfer from all the child nodes that have received a new request message within a specified time (T_r3) since the time of the receipt of the request message.

In this manner, each of the nodes can execute a synchronization process with nodes from which a node that takes time for communication is eliminated and complete an update process speedily even if trouble occurs in any one of any node and a communication path thereof.

Effects of the Invention

According to a method and system for the replication of data of the present invention, if a slave node that has received a search instruction does not receive a reply message within a specified time since the time of the transmission of a request message to any one of a parent node thereof and a master node, a replica DB is updated with reference to any one of a node having a transaction log up to the latest version and the transaction log transferred from the master node. Therefore, even if trouble occurs in any one of any node and a communication path thereof, it is possible to perform a synchronization process speedily, and a user can make a search by use of a replica DB in synchronization with a master DB. In other words, it is possible to encourage an improvement in the performance of an entire system and provide a speedy search.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an explanatory view illustrating data replication management according to an embodiment of the present invention (first and second embodiments).

FIG. 2 is an explanatory view illustrating heartbeat communication between a slave node and a master node (first and second embodiments).

FIG. 3 is an explanatory view illustrating data replication management of a tree structure according to an embodiment of the present invention (third and fourth embodiments).

FIG. 4 is an explanatory view illustrating heartbeat communication between a slave node and a parent node thereof (third and fourth embodiments).

MODE FOR CARRYING OUT THE INVENTION

A detailed description will hereinafter be given of embodiments for carrying out the present invention with reference to the attached drawings. However, the present invention is not interpreted while limiting to this, but various updates, modifications, and improvements can be added based on the knowledge of those skilled in the art without departing from the scope of the present invention. Furthermore, the same reference numerals are attached to the same members as those in a first embodiment in the following embodiments, and the overlapping descriptions will be omitted.

First Embodiment

FIG. 1 illustrates an outline of data replication management according to a first embodiment of the present invention, and includes a master node 100, and a plurality of (n number) slave nodes connected to the master node 100 via a network 120. Here, all of the plurality of slave nodes has the same configuration, and the same numeral 200 is attached.

The master node 100 has a master DB 102 managed by the master node 100, a transaction log recording area 104 for recording and storing a transaction log, a DB backend 106 for providing a write instruction to the master DB 102 and the transaction log recording area 104, and a communication module 108 for communicating with the slave nodes.

Each of the slave nodes 200 has a replica DB 202 managed by the slave node 200 in a manner of having the content identical with that of the master DB 102 and used as a search target, a transaction log recording area 204 for recording and storing a transaction log, a DB backend 206 for providing a write instruction to the replica DB 202 and the transaction log recording area 204, a communication module 208 for communicating with the master node 100, a transaction log write module 210 for writing a transaction log received from the master node 100 to the transaction log recording area 204, and a restoration module 212 for performing a restoration process of a transaction log and writing to the replica DB202.

Next, a description will be given of the operation of a data replication management system in the embodiment with reference to FIG. 1.

A data update request of a user enters the DB backend 106 of the master node 100 as an update instruction. The DB backend 106, which has received the update instruction, starts writing to the transaction log recording area 104, and at the same time provides the communication module 108 with a transfer instruction of a transaction log related to new updates.

When ending writing to the transaction log recording area 104, the DB backend 106 starts updating the master DB 102.

As a general rule, the communication module 108, which has received the transfer instruction, transmits the transaction log to the communication modules 208 of all the connected slave nodes 200. After receiving the transaction log, the communication modules 208 transmit the transaction log to the transaction log write modules 210, and the transaction log write modules 210 write the transaction log to the transaction log recording areas 204.

Next, the transaction logs are called by the restoration modules 212 from the transaction log recording areas 204 to be applied to the replica DBs 202, and data replication between the master DB 102 and the replica DB 202 used as a search target is complete.

After waiting to complete replication, the communication modules 208 transmit the completion of transfer to the communication module 108, and the communication module 108 transmit the completion of transfer to the DB backend 106.

When the communication module 108 receives notifications of the completion of the transfer of the transaction log from the communication modules 208 of all the slave nodes 200 and an update of the master DB 102 ends, the update operations in accordance with the data update request (update instruction) of a user is complete.

FIG. 2 is an explanatory view illustrating normal heartbeat communication between the slave node 200 and the master node 100.

The slave nodes 200 transmit a request message to the master node 100 respectively at intervals of a specified time T_i1. Here, the specified time T_i1 is set to be the time from when the slave node 200 transmits a request message to the master node 100 until a time T₀₁, elapses since the receipt of a reply message.

The master node 100, which has received a request message, transmits a reply message to each of the slave nodes 200 that performed transmission. If a reply message does not arrive from the master node 100 within a specified time T_s1 of when the slave node 200 transmits the request message, some trouble may be occurring in any one of the master node 100 and a communication path thereof.

Incidentally, it is also possible to set the specified time T_i1 to be the time from the transmission of a request message until the time T₀₁ elapses. Also in this case, if a reply message does not arrive from the master node 100 within the specified time T_s1 since the time of the transmission of a request message, some trouble may be occurring in the system.

If not receiving a reply message from the master node 100 within the specified time T_s1 since the time of the transmission of the request message, the slave node 200 assumes that some trouble may be occurring in the system and stops transmitting a request message to the master node 100.

Moreover, if not receiving a next new request message from the slave node 200 that transmitted performed transmission within a specified time T_r1, since the time of the transmission of the reply message, the master node 100, which has received the request message, assumes that some abnormality has occurred in any one of the slave node 200 and a communication path thereof.

Here, the specified time T_r1, is set to be a sufficiently longer time than the time T_s1, for example, a time calculated by a formula T_r1=T₀₁+233 T_s1, in order that the slave node 200 can detect an abnormality simultaneously with the master node 100 or earlier than that.

If the slave node 200 does not receive a reply message even after a lapse of T_s1 since the master node 100 transmits the reply message, the slave node 200 detects an abnormality. If not detecting an abnormality, the slave node 200 transmits a next request message before T₀₁+T_s1 elapses since the transmission of the request message. If the master node 100 does not receive a next request message even after a lapse of T_s1 since the slave node 200 transmits the next request message, the slave node 200 does not receive a reply message even after a lapse of T_s1 since the transmission of the next request message, and consequently detects an abnormality.

Therefore, if the master node 200 does not receive a new request message for a lapse of T_r1(=T₀₁+2×T_s1) and detects an abnormality, the slave node 200 either does not receive a reply message to a newest request message within T_s1 of the transmission of the request message or does not receive a reply message to a next request message within T_s1 of the transmission of the request message. Therefore, the slave node 200 has already detected an abnormality.

If receiving a data update request from a user, the master node 100 starts writing to the transaction log recording area 104, and at the same time transfers a transaction log related to new updates to the communication module 208 of the slave node 200 that transmitted a new request message within the specified time T_r1 since the time of the transmission of the reply message. The slave node 200 that has received the transaction log then updates the replica DB 202 and transmits the completion of transfer to the master node 100 as described above.

The slave node 200 that did not transmit a new request message within the specified time T_r1 is assumed that some abnormality is occurring and the transaction log is not transferred to the communication module 208 thereof.

If receiving notifications of the completion of transfer from all the slave nodes 200 to which the transaction log has been transferred, the master node 100 assumes that the synchronization process of the transaction log is complete even if a notification of the completion of transfer does not arrive from the salve node 200 that does not transmit a new request message. If the synchronization process of the transaction log is complete and an update of its own master DB 102 ends, the data update request from a user is complete.

A data search request of a user enters the DB backend 206 of any slave node 200 as a search instruction, and if the slave node 200 receives a reply message within the specified time T_s1 since the time of the transmission of the request message to the master node 100, the search requested by a user is made by use of the replica DB 202.

However, if the slave node 200 does not receive a reply message within the specified time T_s1, the communication module 208 requests a transaction log that is not yet obtained and up to the latest version (this may be collectively referred to as a “transaction log up to the latest version” or simply as a “transaction log” in the description) from the communication module 108 of the master node 100. It is possible to reduce the amount of information transmitted and lighten the load of communications by not including a transaction log already obtained by the slave node 200 in a transaction log for which the request is made.

The communication module 108 that has received the request transmits the transaction log up to the latest version to the communication module 208 of the slave node 200 that transmitted the request.

The communication module 208 transmits the received transaction log to the transaction log write module 210, and the transaction log write module 210 writes to the transaction log recording area 204. Next, the transaction log is called by the restoration module 212 from the transaction log recording area 204 to be applied to the replica DB 202, and data replication between the master DB 102 and the replica DB 202 used as a search target is complete.

The search requested by a user is made by use of the replica DB 202.

The slave node 200 that has stopped transmitting a request message since it did not receive a reply message within the specified time T_s1 since the time the transmission of the request message transmits a request restart message to the master node 100 after a lapse of a specified time since the stop of the transmission of the request message, and afterward requests the transaction log up to the latest version from the master node 100. If receiving a restart permission message within the specified time T_s1, since the time the transmission of the restart message, the slave node 200 transmits a request message to the master node 100, and afterward transmits a request message to the master node 100 at intervals of the specified time T₀₁ after the receipt of a reply message similarly to before the trouble occurred. If not receiving a reply message to the request restart message within a specified time (T_s1) or receiving a restart reject message, the slave node 200 transmits a request restart message again after a lapse of a specified time.

The master node 100, which has received a request restart message, transmits a restart permission message when assuming that an abnormality occurred in the slave node 200, and adds the slave node 200 to nodes targeted for the synchronization process upon the transfer of a transaction log. If a request for a transaction log up to the latest version is received afterward, the transaction log is transmitted.

The slave node 200 eliminated from the targets of the synchronization process updates the replica DB by acquiring a transaction log up to the latest version upon making a search. Accordingly, it is possible to make a search by use of the replica DE in synchronization with the master DB.

However, the master node 100 transmits a restart reject message when not detecting an abnormality of the slave node 200.

In the first embodiment, as a general rule, whenever receiving an update request from a user, the master node 100 transfers a transaction log related to updates of the master DE 102 to all the slave nodes 200, and completes the update request after confirming that the replica DBs 202 are updated at the slave nodes 200. Hence, there are advantages that the slave node 200 that has received a search instruction can make a search speedily by use of the replica DB 202 that are already kept in the latest state, and the search speed does not decrease even if the frequency of searches is high.

Moreover, if any one of a request and a response to a reply message between the master node 100 and any slave node 200 does not arrive within a specified time, the master node 100 assumes that trouble has occurred in any one of the node and a communication path thereof, eliminates the slave node 200 from the targets of the synchronization process upon update of the master DB 102, and requests a transaction log up to the latest version from the master node 100 whenever the slave node 200 receives a search instruction. Therefore, it is possible to execute the synchronization process at high speed while keeping the slave node 200 in a synchronized state even when trouble occurs.

In the embodiment, the time T_r1, until the master node 100 receives a new request message after the transmission of a reply message is set to be sufficiently longer than T_s1 as described above. Accordingly, it is possible to prevent the slave node 200 from judging that the slave node 200 itself has received a transaction log up to the latest version without noticing trouble although the master node 100 detected the trouble and eliminated the slave node 200 from the targets of the synchronization process. In other words, it is possible to prevent a user from making a search by use of the replica DB 202 that is out of synchronization with the updated master DB 102.

After the trouble is restored, the slave node 200 that has detected the trouble can restart transmitting a request message and return to a state before the trouble occurred. With regard to temporary network trouble in between with the slave node 200, it is possible to process an update request speedily by eliminating the slave node 200 from the targets of synchronization when the trouble is occurring, and to process a search request to the slave node 200 speedily by adding the slave node 200 to the targets of synchronization after the restoration. Consequently, it is possible to improve the performance of the entire system.

In the embodiment, it is possible to transmit and receive a request and a reply message, and request and transfer a transaction log by use of the same communication path. Moreover, it is possible to use a communication path in which a message transmitted first arrives first without fail as a communication path. In this manner, it is possible to guarantee that the transfer of a transaction log on the communication path is securely made by confirming the transmission and receipt of a request message and a reply message.

Second Embodiment

FIG. 1 illustrates an outline of data replication management according to a second embodiment of the present invention, and a description will be given of the operation with reference to FIG. 1.

Similarly to the case of the first embodiment, the master node 100, which has received a data update request from a user as an update instruction, starts updating the master DB 102, and as a general rule, transmits a transaction log related to updates of the master DE 102 to the communication modules 208 of all the connected slave nodes 200.

When ending the receipt of the transaction log, the communication modules 208 transmit notifications of the completion of transfer to the communication module 108, and the communication module 108 to the DB backend 106.

When the communication module 108 receives the notifications of the completion of transfer of the transaction log from the communication modules 208 of all the slave nodes 200, and an update of the master DB 102 ends, the update operations in accordance with the data update request (update instruction) of a user is complete.

FIG. 2 illustrates heartbeat communication between the master node 100 and the slave node 200 under normal operating conditions as described in the first embodiment.

A data search request of a user enters the DB backend 206 of any slave node 200 as a search instruction. The DB backend 206 transmits the search instruction to the communication module 208. When the slave node 200 receives a reply message within a specified time T_s1 since the time the transmission of the request message to the master node 100, the communication module 208 transmits a transaction log up to the latest version that which is owned by the communication module 208 itself to the transaction log write module 210. The transaction log write module 210 writes the transaction log to the transaction log recording area 204.

Next, the transaction log is called by the restoration module 212 from the transaction log recording area 204 to be applied to the replica DB 202. Accordingly, data replication between the master DB 102 and the replica DB 202 used as a search target is complete. The data search request is accomplished by use of the replica DB 202.

The case where the slave node 200 that has received the search instruction does not receive a reply message within the specified time T_s1 since the time the transmission of the request message to the master node 100 is the same as in the first embodiment, and the aspects described in the first embodiment other than the above in the embodiment are the same as the first embodiment.

The effects specific to the embodiment are as follows.

In the second embodiment, it is sufficient if the master node 100, which has transmitted a transaction log reflecting an update instruction to the slave node 200, simply waits to receive a receipt notification of the transaction log from the communication module 208, and it is unnecessary to wait until the transaction log is applied to the replica DB 202. As a result, it is possible to process the synchronization process speedily upon the transfer of the transaction log.

Furthermore, the slave node 200 that has received the search instruction updates the data of the replica DB 202 with reference to an already received transaction log up to the latest version and makes a search by use of the replica DB 202.

In the embodiment, the application of a transaction log is delayed, and the replica DB is updated by applying a transaction log only when a search instruction is received. Therefore, there is an advantage that it is unnecessary to request again a transaction log up to the latest version from the master node 100.

Third Embodiment

FIG. 3 is an explanatory view illustrating data replication management of a tree structure used in a third embodiment of the present invention.

Included is a master node 100 as a root of the tree structure, and included is a plurality of slave nodes 200 as the nodes and leaves of the tree structure. The master node is set to be the highest laver, and a slave node positioned in a layer that is n layer lower than the master node 100 is shown as a slave node 200 (n).

The nodes are connected directly to nodes positioned one layer lower or upper respectively with a network (unillustrated in FIG. 3) as shown in FIG. 3. In the description, a “child node” of a node indicates a node one layer lower that is connected directly to the node, and a “parent node” of a node indicates a node one layer upper that is connected directly to the node. Moreover, a “leaf node” indicates a node having no child nodes.

A “descendant node” of a node indicates a node that can be reached by descending from the node to lower layers, through a child node of the node and a child node of the child node, along the tree structure. Among descendant nodes, a difference between nodes (leaf nodes) positioned in the lowest layer and a layer where the node is positioned may be referred to as the “height.”

The configurations of the master node 100 and the slave nodes 200 are the same as the master node 100 and the slave nodes 200 shown in FIG. 1, respectively.

Next, a description will be given of a method for managing the replication of data according to the third embodiment with reference to FIGS. 1 and 3.

A data update request of a user enters the DB backend 106 of the master node 100 as an update instruction. if receiving the update instruction, the DB backend 106 starts writing to the transaction log recording area 104, and at the same time provides the communication module 108 with a transfer instruction of a transaction log related to the new updates.

When ending writing to the transaction log recording area 104, the DB backend 106 starts updating the master DB 102.

The communication module 108, which has received the transfer instruction of the transaction log related to the new updates, transmits the transaction log to communication modules 208 (1) of all the child nodes 200 (1). The communication modules 208 (1) transmit the received transaction log to the transaction log write modules 210 (1) and instruct to update replica DBs 202 (1) while further transmitting the transaction log to communication modules 208 (2) of all child nodes 200 (2) at a lower order.

The above is repeated until the transaction log is transmitted to communication modules 208 (z) of leaf nodes 200 (z).

If receiving the transaction log, the communication modules 208 (z) perform transmission to transaction log write modules 210 (z), and the transaction log write modules 210 (z) write the transaction log to transaction log recording areas 204 (z).

Next, the transaction logs are called by restoration modules 212 (z) from the transaction log recording area 204 (z) to be applied to replica DBs 202 (z), and data replication between the master DB 102 and the replica DBs 202 (z) managed by the leaf nodes 200 (z) is complete.

After waiting to complete replication, the communication modules 208 (z) transmit the completion of transfer to communication modules 208 (z−1) of parent nodes 200 (z−1) that transferred the transaction log, and if the communication modules 208 (z−1) receive the completion of transfer from all the slave nodes 200 (z) to which the transmission was performed as well as an update of data of their own replica DBs 202 (z−1) being complete, the communication modules 208 (z−1) transmit the completion of transfer to communication modules 208 (z−2) of further parent nodes 200 (z−2) thereof.

If the above transmission of the completion of transfer is repeated, the communication module 108 of the master node 100 receives the completion of transfer from all the child nodes 200 (1) and an update of the master DB 102 ends, the update operations in accordance with the data update request (update instruction) of a user are complete.

FIG. 4 is an explanatory view illustrating normal heartbeat communication between a slave node 200 (n), and any one of the parent nodes 200 (n−1) and 100.

The slave node 200 (n) transmits a request message to the parent node thereof at intervals of a specified time T_i3. The parent node that has received the request message transmits a reply message to the slave node 200 (n). If a reply message does not arrive from the parent node within a specified time T_s3 of when the slave node 200 (n) transmitted the request message, some trouble may be occurring in any one of the parent node and a communication path thereof.

Here, with regard to the parent node, n being greater than 1 indicates a slave node 200 (n−1), and n=1 indicates the master node 100 (they may be collectively referred to as “any one of the parent nodes 200 (n−1) and 100” in the description). The specified time T_i3 is set to be the time from when the slave node 200 (n) transmits a request message to the parent node until a time T₀₃ elapses since the receipt of a reply message.

Incidentally, the specified time T_i3 can be set to be the time from when the slave node 200 (n) transmits a request message until the time T₀₃ elapses, too. Also in this case, if a reply message does not arrive from the parent node within the specified time T₀₃ since the time of the transmission of a request message, some trouble may be occurring in the system.

If receiving a reply message from the parent node thereof within the specified time T_s3 since the time of the transmission of the request message, the slave node 200 (n) assumes itself to own a transaction log up to the latest version.

In contrast, if not receiving a reply message from the parent node thereof within the specified time T_s3, the slave node 200 (n) stops transmitting a request message to the parent node. In other words, the slave node 200 (n) assumes that some trouble may be occurring in the system, and assumes itself to not own a transaction log up to the latest version.

Moreover, if a request message arrives from a child node 200 (n+1) of the slave node 200 (n) that has stopped transmitting a request message, the slave node 200 (n) does not transmit a reply message thereto. Hence, the child node 200 (n+1) does not receive a reply message even after a lapse of the specified time T_s3. Accordingly, the child node 200 (n+1) does not transmit an answer message to a child node 200 (n±2) of the child node. This process is repeated until reaching all the descendent nodes.

Incidentally, assuming the height of the slave node 200 (n) in the tree structure is q, a maximum time T_m3 required from when the slave node 200 (n) stops transmitting a reply message until all the descendent nodes detect trouble can be calculated as a function T_m3=f(T₀₃, T_s3, q) where T₀₃, T_s3 and q are variables, and becomes longer as q becomes greater.

Moreover, if a new request message does not arrive from the slave node 200 (n) that has received the request message within a specified time T_r3 since the time of the transmission of the reply message, any one of the parent nodes 200 (n−1) and 100 of the slave node 200 (n) assumes that some abnormality occurred in any one of the slave node 200 (n) and a communication path thereof. Here, T_r3 is set to be a definitely longer time than the time that the slave node 200 (n) and all the descendent nodes detect the abnormality. As an example, T_r3 is set to be a time calculated by a formula T_r3=T₀₃+2×T_s3+T_m3.

The slave node 200 (n) detects the abnormality by a lapse of the time T (=T₀₃+2×T_s3) since the transmission of the reply message and stops returning a reply message to a request message from a child node thereof. Assuming the height of the slave node 200 (n) in the tree structure is q, all the descendent nodes of the slave node 200 (n) detect the abnormality after a further lapse of the time T_m3 calculated by the specified function T_m3=f (T₀₃, T_s3, q) since that point in time. Consequently, assuming T_r3=T₀₃+2×T_s3+T_m3, the time T_r3 is caused to be a longer time than a time required for the slave node 200 (n) and all descendent nodes thereof to detect the abnormality.

Any one of the parent nodes 200 (n−1) and 100 that has assumed some trouble has occurred transfers the transaction log to communication modules 208 (n) of the slave nodes 200 (n) that transmitted a new request message within the specified time T_r3 since the time of the transmission of the reply message, but does not transfer the transaction log to the communication modules 208 (n) of the slave nodes 200 (n) that did not transmit a new request message within the specified time T_r3.

If receiving notifications of the completion of transfer from all the nodes 200 (n) to which the transaction log is transferred, the parent node assumes that the synchronization process of the transaction log is complete even if a notification of the completion of transfer does not arrive from the slave node 200 (n) that does not transmit a new request message. In a case where the parent node is the slave node 200 (n−1), if the synchronization process of the transaction log is complete and an update of the replica DB 202 (n−1) managed by itself ends, the parent node transmits a notification of the completion of transfer to any one of the further parent nodes 200 (n−2) and 100. In a case where the parent node is the master node 100, if the synchronization process of the transaction log is complete and an update of its own master DB 102 ends, the data update request of a user is complete.

A data search request of a user enters a DB backend 206 (k) of any slave node 200 (k) as a search instruction, and the slave node 200 (k) transmits a request message to any one of the parent nodes 200 (k−1) and 100. If the slave node 200 (k) receives a reply message from the parent node within the specified time T_s3 since the time of the transmission, the data search is made by use of a replica DB 202 (k).

However, if a reply message is not received from the parent node within the specified time T_s3, the DB backend 206 (k) of the slave node 200 (k) transmits the search instruction to a communication module 208 (k), and the communication module 208 (k) requests a transaction log up to the latest version related to updates of the master DB 102 from any one of communication modules 208 (k−1) and 108 of the parent node.

If the parent node is any one of a slave node 200 (k−1) that owns the transaction log and the master node 100, any one of the communication modules 208 (k−1) and 108 of the parent node transmits the transaction log to the communication module 208 (k) of the slave node 200 (k).

If the parent node is the slave node 200 (k−1) that does not own the transaction log, the communication module 208 (k−1) requests any one of communication modules 208 (k−2) and 108 (in a case of k=2) of a further parent node thereof to transfer the transaction log after a lapse of a specified time since the receipt of the request for the transaction log from the communication module 208 (k).

As described above, if the request for transfer of a transaction log up to the latest version is repeated and reaches any one of a slave node 200 (m) that owns the transaction log and the master node 100, any one of communication modules 208 (m) and 108 thereof transmits the transaction log to any one of communication modules 208 (m+1) and 208 (1) of any one of child nodes 200 (m+1) and 200 (1) that has transmitted the request for transfer. Any one of the communication modules 208 (m+1) and 208 (1) that has received the transaction log performs transmission to any one of communication modules 208 (m+2) and 208 (2) of any one of child nodes 200 (m+2) and 208 (2) of the child node that transmitted the request for transfer. Similar transfer is repeated, and the communication module 208 (k) of the slave node 200 (k) obtains the transaction log.

The communication module 208 (k) transfers the transaction log to a transaction log write module 210 (k), and the transaction log write module 210 (k) writes to a transaction log recording area 204 (k).

Next, the transaction log is called by a restoration module 212 (k) from the transaction log recording area 204 (k) to be applied to a replica DB 202 (k), and data replication between the master DB 102 and the replica DB 202 (k) used as a search target is complete.

The slave node 200 (n) that has stopped transmitting a request message since not receiving a reply message from any one of the parent nodes 200 (n−1) and 100 within the specified time T_s3 since the time of the transmission of the request message transmits a request restart message to the parent node after a lapse of the time T_m3 calculated by the formula T_m3=f(T₀₃, T_s3, q) since the stop of the transmission of the request message, and afterward requests a transaction log up to the latest version from the parent node. If not receiving a restart permission message to the request restart message within the specified time T_s3 since the time of the transmission of the request restart message or receiving a restart reject message, the slave node 200 (n) transmits a request restart message again after a lapse of a specified time.

If receiving a restart permission message within the specified time T_s3 since the time of the transmission of the restart message, the slave node 200 (n) transmits a request message to the parent node, and afterward transmits a request message to the parent node at intervals of a specified time T_s1 after the receipt of the reply message, similarly to before detecting the abnormality.

If the parent node that received the request restart message has already assumed that an abnormality occurred in the slave node 200 (n), and the node itself owns a transaction log up to the latest version, the parent node transmits a restart permission message and adds the node 200 (n) to nodes targeted for the transfer of a transaction log. Moreover, if receiving a request for a transaction log up to the latest version afterward, the parent node transmits a transaction log up to the latest version owned by itself. If the parent node has not yet assumed that an abnormality occurred in the slave node 200 (n) or the node itself does not own a transaction log up to the latest version, the parent node transmits a restart reject message.

As described above, after the trouble is restored, the slave node 200 (n) restarts transmitting a request message first. Accordingly, the slave node 200 (n) is caused to own a transaction log up to the latest version. As a result, the child node 200 (n+1) thereof restarts transmitting a request message. Hence, a request message restarts being transmitted in descending order of layers, from the slave node 200 (n) on down to all the descendent nodes, and all the descendent nodes eventually return to a state before the trouble occurred.

In this manner, if receiving a search instruction, the slave node 200 (n) eliminated from the targets of the synchronization process updates the replica DB by acquiring a transaction log up to the latest version upon making a search. Accordingly, it is possible to make a search by use of the replica DB in synchronization with the master DB.

In the third embodiment, in a structure including the master node 100 being a master node as the root of the tree structure and the plurality of slave nodes 200 being slave nodes as the nodes and leaves of the tree structure, a transaction log related to updates of the master DB is transferred as a general rule to all the slave nodes 200 on every update, and the replica DB 202 is updated at each of the slave nodes 200. Therefore, there are advantages that the slave node 200 that receives a search request from a user can make a search speedily by use of the replica DB 202 and a search speed does not decrease even if the frequency of searches is high.

Moreover, if there is no response to any one of a request message and a response message between any connected nodes within a specified time, it is assumed that some trouble has occurred, and the master node 100, which has received an update request, and the slave node 200 that has received a transaction log eliminate a child node 200 that has not received a request message from the targets of the synchronization process, and if not receiving a reply message, the slave node 200 that has received a search request requests a transaction log up to the latest version from a parent node thereof. Hence, it is possible to execute the synchronization process at high speed while keeping the slave node 200 in a synchronous state even when trouble occurs.

In the embodiment, the time T_r3 from when a parent node transmits a reply message until when the parent node receives a new request message from the child node is set, considering T₀₃, T_s3 and the height q of the child node in the tree structure. As a result, it is possible to prevent all slave nodes 200 that are a child node 200 and all descendent nodes thereof, from judging to have received a transaction log up to the latest version without noticing trouble although a parent node detects the trouble and eliminates the child node from the targets of the synchronization process. In other words, it is possible to prevent a search from being made by use of the replica DB 202 that is out of synchronization with the updated master DB 102.

After the trouble is restored, the slave node 200 that could not receive a reply message and detected the trouble can restart transmitting a request message and return to a state before the trouble occurred. With regard to temporary network trouble in between with the slave node 200, there is an advantage that the performance of the entire system can be improved since it is possible to process an update request speedily by eliminating the slave node 200 from the targets of synchronization for an update request if the trouble is occurring, and it is possible to process a search request to the slave node 200 speedily by adding the slave node 200 to the targets of synchronization after the trouble is restored.

In the embodiment, if requests for a transaction log up to the latest version arrive from other child nodes of the slave node 200 (n−1) within a specified time since the time of the receipt of the request for the transaction log from the communication module 208 (n), all the requests can be transmitted together to a further parent node thereof. In this manner, it is possible to lighten the load of the network traffic.

Furthermore, in the embodiment, it is possible to transmit and receive a request and a reply message, and request and transfer a transaction log by use of the same communication path. Moreover, it is possible to use a communication path in which a message transmitted first arrives first without fail as a communication path. In this manner, it is possible to guarantee that the transfer of a transaction log on the communication path is securely made by confirming the transmission and receipt of a request message and a reply message.

Fourth Embodiment

FIG. 3 illustrates an outline of data replication management according to the second embodiment of the present invention, and a description will be given of the operation with reference to FIGS. 1 and 3.

The communication module 108, which has received a transfer instruction of a transaction log related to new updates from the DB backend 106 of the master node 100, which received a data update request from a user, transfers the transaction log to communication modules 208 (1) of all child nodes 200 (1) thereof. The communication modules 208 (1) that have received the transaction log transfer the transaction log further to communication modules 208 (2) of all child nodes 200 (2) thereof at a lower order, respectively.

The above is repeated until communication modules 208 (z) of leaf nodes 200 (z) receive the transaction log.

If receiving the transaction log, the communication modules 208 (z) of the leaf nodes 200 (z) transmit the completion of transfer to communication modules 208 (z−1) of parent nodes thereof. If receiving the completion of transfer from all the leaf nodes 200 (z) to which the transfer was performed, the communication modules 208 (z−1) transmit the completion of transfer to communication modules 208 (z−2) of further parent nodes thereof.

If the above transmission of the completion of transfer is repeated, the communication module 108 of the master node 100 receives the completion of transfer from all the slave nodes 200 (1) and an update of the master DB 102 ends, the update operations in accordance with the data update request (update instruction) of a client is complete.

A search requested by a user enters a DB backend 206 (k) of any slave node 200 (k). If the slave node 200 (k) receives a reply message within a specified time T_s3 since the time of the transmission of a request message to any one of a node 200 (n−1) one layer upper and the master node 100, and itself does not detect an abnormality, the search is made by use of a replica DB 202 (k).

A data search request of a user enters the DB backend 206 (k) of any slave node 200 (k) as a search instruction. The DB backend 206 (k) transmits the search instruction to a communication module 208 (k). If receiving a reply message within the specified time T_s3 of when the slave node 200 (k) transmits a request message to any one of a parent node 200 (k−1) thereof and the master node 100, the communication module 208 (k) transmits a transaction log up to the latest version owned by itself to a transaction log write module 210 (k). The transaction log write module 210 writes the transaction log to a transaction log recording area 204 (k).

Next, the transaction log is called by a restoration module 212 (k) from the transaction log recording area 204 (k) to be applied to the replica DB 202 (k). Accordingly, data replication between the master DB 102 and the replica DB 202 (k) used as a search target is complete, and the data search request is accomplished by use of the replica DB 202 (k).

A case where the slave node 200 (k) that receives the search instruction does not receive a reply message within the specified time T_s3 is the same as in the third embodiment, and the aspects described in the third embodiment other than the above in the embodiment are the same as in the third embodiment.

Effects specific to the embodiment are as follows.

In the fourth embodiment, it is sufficient if the parent node 200 (k−1) that has transmitted a transaction log reflecting an update instruction to the slave node 200 (k) simply waits to receive a notification of the receipt of the transaction log from the communication module 208 (k). Accordingly, it is unnecessary to wait until the transaction log is applied to the slave DB 202 (k). Therefore, it is possible to process the synchronization process speedily at the time of transfer of a transaction log.

Furthermore, the slave node 200 (k) that has received a search instruction updates data of the replica DB 202 (k) with reference to an already received transaction log up to the latest version and makes a search by use of the replica DE 202 (k).

In the embodiment, there is an advantage that it is unnecessary to request a transaction log up to the latest version again from the parent node since a replica DB is updated by delaying the application of a transaction log and applying the transaction log only when a search instruction is received.

INDUSTRIAL APPLICABILITY

As described above, it is possible to use the present invention as a DB management system that can make a search while ensuring consistency of information sequentially updated between a plurality of sites.

EXPLANATION OF REFERENCE NUMERALS

• 100: Master node
• 102: Master DB
• 104, 204: Transaction log recording area
• 106, 206: DB backend 108, 208: Transaction log write module
• 120: Network
• 200: Slave node
• 202: Replica DB

Claims

1. A method for managing replication of data between a master database managed by a master node and a replica database that is managed by a slave node connected to the master node in a manner of having a content identical with that of the master database and that is used as a search target,

the method comprising:

a step of causing the slave node that has received a search instruction to request from the master node a transaction log up to a latest version related to updates of the master database in a case of not receiving a reply message from the master node within a specified time (Ts1) since the time of transmission of a request message to the master node;

a step of causing the master node that has received the request to transmit the transaction log to the slave node; and

a step of causing the slave node to update the replica database with reference to the transaction log transferred from the master node.

2. The method for managing replication of data according to claim 1, further comprising a step of causing the slave node to update the replica database with reference to an already received transaction log in a case of receiving a reply message from the master node within the specified time (Ts1) since the time of transmission of a request message to the master node.

3. The method for managing replication of data according to claim 1 or 2, comprising a step of causing the master node, which has received an update instruction, to complete an update in accordance with the update instruction after receiving notifications of completion of transfer from all the slave nodes that have received a new request message within a specified time (Tr1) since the time of receipt of the request message and completing an update of the master database.

4. A method for managing replication of data between a master database managed by a master node and replica databases that are managed by a plurality of slave nodes connected to a tree structure having the master node as a root in a manner of having a content identical with that of the master database and that are used as search targets,

the method comprising:

a step of causing the slave node that has received a search instruction to request from a parent node of the slave node a transaction log up to a latest version related to updates of the master database in a case of not receiving a reply message from the parent node within a specified time (Ts3) since the time of transmission of a request message to the parent node;

a step of repeating that the parent node requests further from a parent node of the parent node the transaction log until reaching a node having the transaction log in a case where the parent node does not have the transaction log;

a step of repeating that the node having the transaction log, which has received the request, transmits the transaction log to child nodes of the node and the child nodes transmit the transaction log further to child nodes thereof at a lower order until the slave node receives the transaction log; and

a step of causing the slave node to update the replica database with reference to the transferred transaction log.

5. The method for managing replication of data according to claim 4, further comprising a step of causing the slave node to update the replica database with reference to an already received transaction log in a case of receiving a reply message from the parent node of the slave node within the specified time (Ts3) since the time of transmission of a request message to the parent node.

6. The method for managing replication of data according to claim 4 or 5, comprising a step of causing the node to transmit a notification of completion of transfer to a parent node thereof after transmitting to the child nodes the transaction log up to a latest version related to updates of the master database and receiving notifications of completion of transfer from all the child nodes that have received a new request message within a specified time (T,r3) since the time of receipt of the request message.

7. The method for managing replication of data according to any one of claims 4 to 6, comprising a step of, in a case of receiving requests for the transaction log from other child nodes within a specified time since the time of receipt of a request for the transaction log from any child node of the node that does not have the transaction log up to a latest version related to updates of the master database, causing the node to collect these requests and request from a parent node of the node the transaction log.

8. A system for managing replication of data, configured by connecting a master database managed by a master node with a replica database that is managed by a slave node connected to the master node in a manner of having a content identical with that of the master database and that is used as a search target, wherein

the master node includes means for updating the master database in accordance with an update instruction, means for transmitting to the slave node a transaction log related to updates of the master database, and means for transmitting to the slave node a transaction log up to a latest version related to updates of the master database in accordance with a request of the slave node, and

the slave node includes means for requesting from the master node the transaction log up to a latest version related to updates of the master database in accordance with a search instruction, and means for updating the replica database with reference to the transaction log transferred from the master node, in a case of not receiving a reply message from the master node within a specified time (Ts1) since the time of transmission of a request message to the master node.

9. The system for managing replication of data according to claim 8, wherein the slave node further includes means for updating the replica database with reference to an already received transaction log in accordance with the search instruction in a case of receiving a reply message from the master node within the specified time (Ts1).

10. A system for managing replication of data, configured by connecting a master database managed by a master node with replica databases that are managed by a plurality of slave nodes connected to a tree structure having the master node as a root in a manner of having a content identical with that of the master database and that are used as search targets, wherein

the master node includes means for updating the master database in accordance with an update instruction, means for transmitting to a child node of the master node a transaction log related to updates of the master database, and means for transmitting to the child node a transaction log up to a latest version related to updates of the master database in accordance with a request of the child node, and

the slave node includes means for requesting from the parent node the transaction log up to a latest version related to updates of the master database, and means for updating the replica database with reference to the transferred transaction log, in a case of not receiving a reply message from the node that is higher by one level within a specified time (Ts3) since the time of transmission of a request message to a parent node of the slave node.

11. The system for managing replication of data according to claim 10, wherein the slave node further includes means for updating the replica database with reference to an already received transaction log in accordance with a search instruction in a case of receiving a reply message from the parent node of the slave node within the specified time (Ts3) since the time of transmission of a request message to the parent node.

12. The system for managing replication of data according to claim 10 or 11, wherein

the node includes:

means for requesting from a parent node of the node the transaction log up to a latest version related to updates of the master database in a case of not having the transaction log,

means for transmitting the transaction log to child nodes of the node that has made a request in a case of having the transaction log, and

means for transmitting a notification of completion of transfer to the parent node or the master node after transmitting the transaction log to the child nodes of the node and receiving notifications of completion of transfer from all the child nodes that have received a new request message within a specified time since the time of receipt of the request message.