JPH034339A - System for updating data base in distributed processing system - Google Patents

Abstract

PURPOSE:To facilitate a journal management and to reduce the manual aid to manage a journal by centralizedly acquiring the journal related to the data base of a node at each place in the specific node at one point in a distributed processing system. CONSTITUTION:Only to specific one node (in this case, a node 11) among nodes, a journal storage part 114 and a DB backup storage part 119 are centralizedly provided. The journal generated in each node is acquired by a computer system #I (node 11) and stored into the storage part 114. By the DB backup storage part 119, not only a data base 115 of the computer system #I (node 11) but also the DB backup information of data bases 125 and 136 of computer systems #I and #III (nodes 12 and 13) are stored. The DB backup data are generally acquired by an operator before a transaction processing start (ordinarily, before the start of an on-line transaction processing on the day or after a data processing completion at a previous day).

Description

[Detailed Description of the Invention] [Industrial Application Field] The present invention relates to a method for updating a distributed database in a distributed processing system interconnected by communication lines, and in particular, to efficiently allocate and manage data to each node. This paper relates to database update methods in distributed processing systems.

[Prior Art] Conventionally, in a distributed processing system, as a method for synchronously updating (simultaneously updating) a distributed database in multiple computer systems (nodes), for example, "Nikkei Computer, May 23, 1988 issue" has been proposed. As described in (pages 101 to 116, especially pages 114 to 115), there is a known method in which each data processing system (each node) acquires a journal of file images before and after update. ing. In addition, as described in Japanese Patent Application Laid-open No. 156258/1983 (page 2), in transaction processing of a distributed database system, transaction logs (journals) are acquired at each site (node),
Furthermore, a method is known in which the number of messages is reduced by sending interim messages and reply messages for multiple transactions all at once to a required site.

[Problems to be Solved by the Invention] In all of the above-mentioned conventional techniques, a journal is acquired at each node, and as a result, journal management becomes complicated as described below.

That is, in a distributed processing system that includes a database of a workstation or small computer system and a large computer system, journal management cannot be performed centrally in the large computer system.

When a failure occurs, the database recovery method is complicated because the management light (computer system to which the database is attached) of the failed database is distributed among the computer system units and journals.

In order to enable each workstation or small computer system to acquire journals, the software configuration for those workstations or small computer systems becomes complicated, resulting in a problem of reduced processing performance and medium usage efficiency.

Therefore, an object of the present invention is to eliminate the above-mentioned problems in the prior art, enable centralized management of journals, unify management of the entire system, improve processing performance, and speed up recovery processing in the event of a failure. The object of the present invention is to provide a database update method in a distributed processing system that can improve the usage efficiency of media.

[Means for Solving the Problems] In order to achieve the above object, the database update method in the distributed processing system of the present invention includes a plurality of nodes each having a database, communication means between the nodes, and an update method from any one node. The system is equipped with a means for synchronizing and updating a database in a plurality of nodes in response to an update request, and is characterized by having means for acquiring journals of a server-side node and a client-side node at one specific node. In other words, each node (client side node and server side node) that manages a database sends update information of each database to one specific node through one communication line, and the journal of the update information is stored at that specific node. It is characterized by being configured so that it can be acquired in a concentrated manner.

Here, the client-side node refers to a node where a transaction is input by a user, and the server-side node refers to a node that provides a database in response to a request.Of course, the client may also serve as a database provider. Further, a specific node may also serve as a client or a server.

When a failure occurs in the database of a certain node, recovery instructions for this failure are centrally executed by the specified node.

Furthermore, in addition to the journal acquisition means provided centrally in the specific node, means for acquiring journals of only transactions in the secure state can be added to individual nodes (server-side nodes and client-side nodes). Therefore, after transmitting the commit state of the transaction to other nodes, the information acquired as a journal is made unnecessary (old history information that is no longer needed is deleted so that new history information can be stored).

[Effect] The effect based on the above configuration will be explained.

According to the present invention, since update journals of databases in a plurality of nodes (server side and client side) are acquired at one specific node, journal management is facilitated and processing performance is improved. This will be explained below regarding the case where the client side node becomes the specific node and the case where the server side node becomes the specific node.

To acquire journals all at once on a client side node, DB update information is sent to the client side as response information to a DB update request to the server side, and the sent information is acquired in the journal (Figure 2). example).

To acquire journals all at once on a server-side node, when a commit guarantee is sent on the client side, DB update information on the client side is simultaneously sent to the server side, and the sent information is acquired in the journal. (Example shown in Figure 3).

As a result, the DB update journal is acquired in one place.

Next, in order to issue recovery instructions in the event of a database failure in one place, the node that acquired the journal issues a recovery instruction from the DB backup, and one of the journals acquired after the DB backup.

It operates to recover by sending the journal information of the failed DB to the management node of the failed DB. Thereby, recovery instructions can be given in one place (the embodiment shown in FIG. 7).

A history information storage section is provided to acquire only the transactions processed on the client side and server side, and after acquiring the DB update image and the journal indicating that the commit has been decided at the time of commit, the commit process is performed and the commit state is transferred to other After sending the information to the node, it becomes unnecessary by making it possible to write the information of another transaction over the information obtained as a journal (because once the information is sent, the information in this storage is no longer needed) .

This allows the in-process to have a journal only for medium (secure) transactions.

[Example] An embodiment of the present invention will be described below with reference to the drawings.

FIG. 1 is a system configuration diagram of an embodiment of the present invention.
In this embodiment, the distributed processing system includes three nodes 11,
12. and 13, i.e. computer system #I, #
II, and #■, and a communication line 117 between each node.
, 118, 127 are provided. Node 11, 12.1
3 each has a database (DB) 115.1
25.135 is connected and the terminal system 116
, 126 and 136 are connected, thereby forming a data processing system in which each node processes transactions input from each terminal system.

As a feature of this embodiment, the journal storage unit 114 and the DB backup storage unit 119 are centrally stored only in a specific one of these nodes (in this case, node 11).
will be established. The journal generated at each node is acquired by the computer system #■ (node 11) and stored in the storage unit 114.
is stored in

The DB backup storage unit 119 is the computer system 31
It is designed to store not only the database 115 of (node 11) but also DB backup information of the databases 125 and 136 of computer system #II, am (node 12-13). Note that the DB backup data is generally acquired by the operator before the start of transaction processing (usually before the start of the current day's online transaction processing or after the end of the previous day's data processing).

The nodes 12 and 13 are provided with transaction history storage units 124 and 134 for acquiring transaction history information only for transactions in progress (transactions in the middle of updating, that is, transactions in a secure state). . In addition,
The journal storage unit 114 in the node 1 can also serve the same function as the transaction history storage units 124 and 134.

Each node 11, 12, 13 has an operating system 111, 121, 131, and a DB/DC program 112 that controls transactions.
, 122, 132 and each terminal 116, 126, 136, an application program (AP) 1 that references and updates the database of its own node and other nodes, and sends a response message to the terminal.
13°123.133 exists.

FIG. 2 is a flowchart showing an example of the processing of the DB/DC programs 112 and 122 when the databases 115 and 125 are updated by transactions input from the terminal system 116 of the #■ computer system 11 in FIG. be. The transaction is started (21) by input from the terminal 116. After the AP 113 requests to update the database of node 1, this AP
When there is a database update request for node 2 from 113,
D M L (Data Manipul
ationL anguage) is sent (22)
As a DML process, node 2 performs update processing of the DB of node 2 on the memory, and also sends update information of the DB of node 2 to node 1 (23).
At the end of the AP processing, acquire the DB update journals of node 2 and node 1, the journal indicating that the commit has been decided, and update the DB 115 (24), and send the commit to node 2 (25). Node 1 updates the DB 125 of Node 1 and sends the release of the secure state to node 1 (26). After receiving the release of the secure state, node 1 obtains a journal indicating completion of the commit (27).
The transaction processing is ended by returning a response to the input terminal (28). Node 2 is in a secure state (29) during processes 23 and 26, and if the system goes down during that time, it performs system recovery according to instructions from node 1.

FIG. 3 shows a processing example of the DB/DC programs 122 and 112 when the databases 125 and 115 in FIG. 1 are updated by transactions input from the terminal system 126 of the #■ computer system 12. This is a flowchart.

A transaction is initiated (30) by input from terminal system 126, D of node 2 by AP 123.
The B update DML process 31 is performed in memory. When there is a node IDB update request from the AP 123,
Sends the DML of the request to node 1 (32). Upon receiving the request, node 1 performs processing in memory (
33), returns a response, and when the AP processing is completed, node 2 sends a commit guarantee (34), and at the same time node 2
(34), Node 1 obtains a journal indicating that it has decided to commit the DB update journals of Node 1 and Node 2 (35), and returns a response. After updating (36),
37), node 1 obtains a journal indicating that it has received a commit decision, and then sends the commit state to DB 11.
5 (38) and returns a response to node 2. Node 2 returns a response to terminal system 126, etc., and ends the transaction (39). There is a secure state between processes 35 and 36, and if node 2 goes down during this period, node 2 will recover according to the journal state of node 1.

FIG. 4 is a flow chart showing a processing example of the DB/DC programs 122 and 132 when the databases 125 and 135 are updated by transactions input from the terminal system 126 of the #■ computer system 12 in FIG. . A transaction is initiated by input from terminal system 126 (41). AP123
After requesting the DB update of node 2 from
When a DB update request occurs, it sends a DML to node 3 (42). In response to the request from node 2, node 3 updates the DB as a process in memory and sends the DB update information to node 2. (43). Upon completion of the AP processing, the DB update information of nodes 2 and 3 is acquired in the transaction history storage unit 124 of node 2, and the DB
125, and also communicates the DB update information of nodes 2 and 3 to node 1 in order to centrally manage the journal on node 1, and waits for the completion of journal acquisition from node 1 (44), node 3 A commit transmission is performed (45), and the DB of node 3 is updated (46).

Upon completion of the reception from node 3, node 2 makes the transaction history information unnecessary (47), allowing the transaction history to be reused in another transaction. (In other words, old transaction information that is no longer needed is deleted by overwriting new transaction information.) A commit completion notification is sent to the node 1 to indicate the end of all processing (48), a response is returned to the terminal system 126, and the transaction processing is ended (49).

Processes 43 to 46 are in a secure state, and if the node goes down during that time, the system is recovered according to the state acquired in the transaction history of node 2.

FIG. 5 is an example of database update information transmitted via a communication line according to the present invention. Message length 51 indicates the entire length. The transaction status 52 indicates the status of the transaction that updated the DB, and indicates the node name 521 of the node where the transaction occurred (the management optical node of the terminal system that input the message), which uniquely identifies the transaction at that node. A transaction identifier 522 numbered for each transaction, and a commit state 52 indicating which stage of processing the transaction is in.
3. Consists of 524 DBs accessed by this transaction. The physical address 53 of the database is a node name, and in the case of a magnetic disk device, a volume name. The update position and update length 54 indicate the cylinder number, track number, and update length of the magnetic disk device. The before-update image 55 is the information before the database is updated, and the after-update image 56 is the information after the database is updated.

FIG. 6 is an example of transaction history information according to the present invention. Overall data length 61 and transaction status 62
correspond to 51 and 52 in FIG.

The database physical address 63 corresponds to 53 in FIG. The update position and update length 64 correspond to 54 in FIG. The pre-update image 65 corresponds to 55 in FIG. The updated image 66 is information equivalent to 66 in FIG.

FIG. 7 shows an embodiment in which the recovery instructions in the event of a database failure according to the present invention are executed in one place in FIG.
3 shows an example of database recovery. DB recovery is performed by file transfer using communication lines 117 and 118, and recovery instructions (
71) file transfer. After reading the journal 114 after the DB backup (72) and checking whether it is a journal for the failed DB (73) and whether the transaction has been committed (74), it is transferred to the updated image by file transfer. Recovery instructions (
75), and the entire process ends when the process up to the last acquired journal is completed (76).

[Effects of the Invention] As described above in detail, according to the present invention, in a distributed processing system, journal management is facilitated by centrally acquiring journals related to databases of nodes at one location at one specific node. By looking at this centrally acquired journal, it is economical and can reduce the manpower to manage the journal.

It is possible to understand the operation of the entire system, which has the effect of improving performance.

In addition, by executing recovery instructions in the event of a database failure in one place, it is possible to save labor in other computer systems, and also to perform quick recovery processing, which has the effect of improving reliability.

Further, by providing a means for acquiring a journal of only transactions in a secure state, the amount of storage medium for storing them can be reduced, resulting in economical effects.

[Brief explanation of drawings]

FIG. 1 is a system configuration diagram of an embodiment of the present invention, FIG.
FIG. 3 and FIG. 4 show a DB according to an embodiment of the present invention.
FIG. 5 is a flowchart showing the processing procedure of /DC, FIG. 5 is a diagram showing an example of database update information according to an embodiment of the present invention, and FIG.
FIG. 7 is a diagram showing an example of transaction history information according to an embodiment of the present invention, and FIG. 7 is a flow chart showing a database recovery procedure according to an embodiment of the present invention. 11.12.13 Old... Node (computer system),
21-28. 30-39. 41-49...-D B update procedure, 24, 25...... #■ Journal acquisition at node, 44...... Transaction history storage unit Information acquisition, 71-76... Database recovery procedure, 111, 121, 131... Operating system, 112, 122, 132...
...DB/DC (database/data communication) program, 113, 123, 133...
・Application program, 114...Journal storage unit, 115, 125, 135...
Database, 116.126, 136...Terminal system, 117°118.127...Communication line, 119...Database backup storage unit, 124,134... - Transaction history storage section. 2nd F: jA Kotojuu Ichisaki System/(Note “I) Kuflyan l> Hand calculation system 2〈No F'2)〈Sir I Guichibin 1〉 Figure 13 S5 System Figure 4 Figure 5 Figure 6 (1)

Claims (1)

[Scope of Claims] 1. A computer system comprising a plurality of nodes each having a database, means for communication between the nodes, and means for synchronizing and updating the database in the plurality of nodes in response to an update request from any one node. 1. A database update method in a distributed processing system, characterized in that the system includes means for acquiring journals of a server-side node and a client-side node at one specific node. 2. When a failure occurs in the database of a certain node,
2. The database update method in a distributed processing system according to claim 1, wherein the specific node executes the failure recovery instruction. 3. The database update method in a distributed processing system according to claim 1, further comprising means for acquiring a journal of only transactions in a secure state on the server side or the client side.