JPH10228404A - Journal management system and its method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a journal management system capable of dividedly arrang ing journal files by guaranteeing the contex of dotted updating history informa tion. SOLUTION: A data file in a shared data area 20 stores each AIJ (After image journal) management data 22 in a page 21 to be its updating unit. The data 22 manages a serial number to be increased in each updating of the page 21 and the increment of the serial number is executed when a transaction manager included in each application process 10 updates the page 21. The transaction manager stores the serial number in the updating history information at the time of generating the updating history information to be stored in a journal file 14, so that the time-sequential order of dotted updating history information can be guaranteed in each page of the data file.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a journal management system and a journal management method suitable for application to, for example, a ticket issuing system.

[0002]

2. Description of the Related Art In recent years, various online systems such as a bank online system and a ticket issuing system have been operated. In order to secure high reliability, these online systems are operated while collecting update information of a database file into a journal file.

Normally, in an online system, a set of work is regarded as a transaction, and when this transaction is completed (commit), the data update that has occurred within the transaction is confirmed and the update information is waited for being reflected in the journal file. I do. this is,
This is to prevent data integrity in the system from being impaired. Therefore, during this time, all pages including the updated data are locked, and, for example, another transaction using the data included in the page is made to wait.

[0004] Under such circumstances, recently, the lock of the page containing the update data is released without waiting for the completion of the transaction, and another transaction is permitted to use the page, thereby improving the performance of the entire system. A mechanism to achieve this has been considered. The mechanism will be described with reference to FIG.

When the application process 90 requests the transaction manager 91 to commit the transaction ((1) in FIG. 7), the transaction manager 91 first updates the update history information (AIJ: After) relating to the data updated in the transaction.
Image Journal 95 is created and stored in the AIJ queue 94 ((2) in FIG. 7). Then, the transaction manager 91 releases the transaction lock of the update page 93 including the update data at this point ((3) in FIG. 7). Therefore, other transactions can access the updated page 93 thereafter.

Next, the transaction manager 91
Instructs the journal writer 96 to actually update the AIJ 95 to the journal file 97 ((4) in FIG. 7). On the other hand, the journal writer 96 that has received this instruction executes the actual update ((5) in FIG. 7), and after the completion, sends the database file 9 to the data writer 98.
9 is instructed to reflect the update ((6) in FIG. 7). After receiving the instruction, the data writer 98 executes the actual update ((7) in FIG. 7), and outputs a clean point output indicating that the update to the database file 99 has been completely reflected to the journal writer 96. Request ((8) in FIG. 7).

When the actual update ((5) in FIG. 7) is completed, the journal file 97 notifies the transaction manager 91 of the completion ((9) in FIG. 7). Upon receipt of this notification, a response to the completion of the commit is returned to the application process ((10) in FIG. 7). In this way, it is possible to release the lock of the updated page without having to wait for commit completion.

[0008]

As described above, in online transaction processing, a mechanism for improving the performance of the entire system by releasing the lock of the updated page without waiting for the completion of the commit has been considered.

Recently, for the purpose of distributing the system load, in an online system, as shown in FIG. 8, a plurality of computers (nodes) 102 are operated in a cluster connection to distribute requests from the terminals 101. Distributed systems have been used for processing. In such a distributed system, when the above-described journal management is applied, the journal file 97 is stored in the shared disk 1
If it is allocated and shared and handled, the access to the journal file 97 becomes a bottleneck.
Here, consider that the journal file 97 is divided and arranged in each node. However, releasing the lock of the updated page without waiting for the completion of the commit is realized only when the time-series order of the AIJ 95 is guaranteed. Therefore, there is a problem that it is difficult to divide and arrange the journal file 97 in a plurality of nodes.

[0010] The present invention has been made in view of such circumstances, and guarantees the context of update history information scattered on a plurality of computers, thereby enabling journal file splitting and arrangement. It aims to provide a system and a journal management method.

[0011]

According to the journal management system of the present invention, when an application process requests a commit of a transaction, update history information of data updated in the transaction is generated, and the chronological order of the data is guaranteed. Release the lock of the page containing the update data at the point in time, and notify the application process of the completion of the commit after the update data included in the update history information is determined to be reflected in the data file, thereby performing a commit. A transaction management function for realizing lock release of an updated page before completion is applied to a distributed system in which a plurality of computers share a data file and a journal file holding the update history information is arranged for each of the plurality of computers. For a journal management system And an order management means for managing the time-series order of the update history information for each page of the data file, and the order of the update history information scattered in a plurality of journal files is determined by the page of the data file. It is guaranteed every time.

[0012] In the journal management system according to the present invention, the order management means manages the chronological order of the update history information relating to the updated data for each page of the data file. As a management method, for example, a serial number that is incremented for each update is stored in a page of the data file, and when the update history information is generated, the serial number is included in the update history information. Or a table indicating the correspondence between the serial number and the update history information is provided in a nonvolatile storage area and managed. It is also effective to hold this serial number in an area secured in a storage area shared by a plurality of computers.

Generally, in transaction management of an online system, a distributed lock manager is provided to control acquisition and release of a transaction lock. Therefore, it is also effective to make the distributed lock manager manage the serial numbers in synchronization with the lock acquisition and release requests.

As described above, by guaranteeing the chronological order of the update history information, the update history information can be scattered in a plurality of journal files, and the access to the journal file becomes a bottleneck. Also, it is possible to release the updated page before the completion of the commit even in the distributed system.

A journal writer for outputting update history information to a journal file outputs a header indicating the start of writing the update history information and a trailer indicating the end of writing for each write operation. Means for scheduling the history information to be output between the same header and trailer. As a result, the consistency of the update history information belonging to the transaction can be maintained.

When a page of the data file is damaged due to a system failure, update history information relating to the page, which is not reflected in the data file, is collected from all the journal files. A page restoring means for restoring the update history information according to a time-series order managed by a management means, wherein the page restoration means, when a miss occurs in the update history information, after the missing update history information; It is preferable to discard the update history information and suspend the reflection on the data file. As a result, there is no loss of consistency in the system.

In the journal management system according to the present invention, when an application process requests a commit of a transaction, update history information of data updated by the transaction is generated, and when the chronological order is guaranteed. By releasing the lock of the page including the update data and notifying the application process of the completion of the commit after the update data included in the update history information is determined to be reflected in the data file, the update before the completion of the commit is completed. Journal management for applying a transaction management function for realizing page lock release to a distributed system in which a plurality of computers share a data file and a journal file holding the update history information is arranged for each of the plurality of computers. In the system, before A journal file for storing update history information is allocated to each page of the data file in advance, and update history management means for managing all the update history information for the same page so as to be stored in the same journal file is provided. It is characterized by becoming.

In the journal management system according to the present invention, it is set in advance in which journal file the update history information is stored for each page, and the computer that has updated the data, if necessary, updates the journal as needed. The update history information is transmitted to another computer in which the file is located.

That is, no matter which computer is updated, the update history information on the same page is stored in the same journal file on the same computer. This is guaranteed for each page of the file.

[0020]

Embodiments of the present invention will be described below with reference to the drawings. (First Embodiment) FIG. 1 shows a network configuration and functional blocks of a computer system according to a first embodiment of the present invention.

As shown in FIG. 1, in the computer system according to the first embodiment, a plurality of computers (nodes) 10 are connected in a cluster by an inter-cluster network 30. Sharing data.

In each node 10, an application process 10 is operating and processes various transactions. In this node 10, the journal writer 12 and the data writer 13 operate in accordance with instructions from a transaction manager (not shown) included in the application process 10.

The journal writer 12 is for writing the update history information (AIJ) generated by the transaction manager to the journal file 14. On the other hand, the data writer 13 writes the data update executed by the transaction on the shared data area 20. This is to reflect the data file. In the computer system according to the first embodiment, the data file in the shared data area 20 holds the respective AIJ management data 22 in the page 21 which is the update unit. The AIJ management data 22 is for managing a serial number that is incremented each time the page 21 is updated. The serial number is incremented by a transaction manager included in each application process 10. When generating the AIJ, the transaction manager stores this serial number in the AIJ. Therefore, the chronological order of the AIJs written to the journal file 14 by the journal writer 12 is guaranteed by this serial number. In other words, as a result of updating the same page 21 by different nodes 10, AIJs related to the same page 21 are scattered in a plurality of journal files 14, but the context is guaranteed by this serial number. For example, it does not hinder online rollback processing.
Then, the lock of the updated page before the completion of the commit can be released without setting the access to the journal file as a bottleneck.

(Second Embodiment) Next, a second embodiment of the present invention will be described. Although the network configuration and functional blocks of the computer system according to the second embodiment are the same as those of the first embodiment, in the computer system of the second embodiment,
By storing each serial number in the AIJ, the AI
Rather than guaranteeing the chronological order of J, an AIJ management file 23 is provided in the shared data area 20 and this AI
The J management file 23 guarantees the chronological order of AIJ. FIG. 2 is a conceptual diagram for explaining the AIJ management file 23.

As shown in FIG. 2, when a certain page 21 is updated by a plurality of nodes, a plurality of AIJ1s are updated.
5 are generated and stored scattered in a plurality of journal files 14. Each application process 11
Transaction manager requests the journal writer 12 in its own node to store the AIJ 15, but stores the serial number obtained from the AIJ management data 22 held in the page 21 and the storage location of the journal file 14 in the shared data area 20. Is written in the AIJ management file 23.
Therefore, by referring to the AIJ management file 23, the context of the AIJ in each page and the storage position thereof can be obtained, and the online rollback processing and the like are not hindered as described above. In this case, there is a concern that the access to the AIJ management file 23 may become a bottleneck.
No problem occurs because the amount of information is very small as compared with the AIJ stored in No.4.

(Third Embodiment) Next, a third embodiment of the present invention will be described. Although the network configuration and functional blocks of the computer system according to the third embodiment are the same as those of the first embodiment, in the computer system of the third embodiment,
Instead of holding the AIJ management data 22 in each page 21 of the data file, an AIJ management area 24 is secured on the shared data area 20 as shown in FIG.
The serial number of each page 21 is managed in the AIJ management area 24. In the third embodiment, each time the page 21 is updated, the transaction manager increments the corresponding serial number in the AIJ management area 24. The shared data area 20 exists on the disk device. Further, the third embodiment is characterized in that serial numbers are managed by the AIJ management area 24 secured on the shared data area 22, and the serial number is used to guarantee the context. The method may be any of the methods described in the first and second embodiments (a serial number is stored in each AIJ, or a serial number is associated with a storage position).

(Fourth Embodiment) Next, a fourth embodiment of the present invention will be described. The network configuration and functional blocks of the computer system according to the fourth embodiment are the same as those of the first embodiment. Generally, in transaction management of an online system, a distributed lock manager is provided to control acquisition and release of a transaction lock. Therefore, in the computer system according to the fourth embodiment, an embodiment will be described in which the distributed lock manager manages serial numbers in synchronization with lock acquisition and release requests.

FIG. 4 is a conceptual diagram for explaining the operation principle of the fourth embodiment. When the file manager 16 included in the application process 11 requests the distributed lock manager 40 to acquire a lock ((1) in FIG. 4), the distributed lock manager 40 locks the requested page 21 and responds to the page 21. A
The file is read from the IJ management file 41 and returned to the file manager 16. Thereby, the application process 11 acquires the serial number of each page 21. On the other hand, when the file manager 16 requests the distributed lock manager 40 to release the lock ((2) in FIG. 4), the distributed lock manager 40 releases the lock on the requested page 21 and stores the lock in the AIJ management file 41. The serial number corresponding to the page 21 is incremented. Therefore, in the fourth embodiment, each time the page 21 is updated, the distributed lock manager 40
The corresponding serial number in the IJ management file 41 is incremented. The fourth embodiment is characterized in that serial numbers are managed by the distributed lock manager 40. A specific method for guaranteeing the context using the serial numbers is described in the first and second embodiments. Any of the methods described in the embodiments (a serial number is stored in each AIJ, or a serial number is associated with a storage position) may be used.

(Fifth Embodiment) Next, a fifth embodiment of the present invention will be described. Although the network configuration and functional blocks of the computer system according to the fifth embodiment are the same as those of the first embodiment, in the computer system according to the fifth embodiment,
The journal file 14 in which the AIJ relating to each page 21 is to be stored is assigned in advance. Then, each node dynamically calculates which journal file 14 is assigned by, for example, a hash method from an ID for uniquely identifying a data file and a page number.

For example, as shown in FIG. 5, an application process 11
Performs the update of page X, page Y, page Z,
It is assumed that the AIJ 15 is generated with the update. In this case, the transaction process of the application process 11 calculates, for each AIJ 15, from the ID file for uniquely identifying the data file and the page number by using the hash method to store in the journal file 14 of which node 10. Node 10 calculated
Is not its own node (Page X, Page Y)
Transmits the AIJ to another node 10. Therefore, in the fifth embodiment, all the AIJs for the same page 21 are stored in the same journal file 14, so that the AIJ does not have a serial number or the like.
The context of the AIJ on each page is guaranteed.

(Sixth Embodiment) Next, a sixth embodiment of the present invention will be described. In the sixth embodiment, description will be given focusing on the schedule function of the journal writer 12. As shown in FIG. 6, when the journal writer 12 according to the sixth embodiment writes an AIJ generated along with the execution of the transaction 17 into the journal file 14, the header indicating the start of writing and the trailer indicating the end of writing. Is output for each write operation. And
The journal writer 12 schedules the AIJ generated with the execution of the same transaction 17 to be output between the same header and trailer.
As a result, it is possible to maintain the consistency of the AIJ belonging to the transaction 17 (such as completion of all writing or failure of all writing).

As described above, by guaranteeing the chronological order of the AIJ, the lock of the updated page before the completion of the commit can be released while the journal file 14 is divided and arranged. The journal writer 12
Outputs a clean point to the journal file 14 when the data writer 13 notifies the data writer 13 of the completion of the actual update. And, when a page of any file is damaged due to a failure, the recovery work is
AIJs after this clean point are collected from all journal files 14, and the collected AIJs are used and performed in the order of management. At this time, for example, if a drop in the number such as a missing number (loss of the AIJ) occurs, the subsequent recovery processing is abandoned, and a response is made by invalidating the transaction. This prevents the integrity of the entire system from being impaired.

The journal management method described in the above embodiment can be distributed by storing it in a storage medium such as a floppy disk, an optical disk, or a semiconductor memory as a program that can be executed by a computer.

[0034]

As described above in detail, according to the present invention, it is possible to guarantee the chronological order of the update history information, so that the journal file is stored in each of a plurality of computers constituting the distributed system. It becomes possible to divide and arrange, and in the distributed system, it is possible to realize the release of the updated page before the completion of the commit without making the access to the journal file a bottleneck.

[Brief description of the drawings]

FIG. 1 is a diagram showing a network configuration and functional blocks of a computer system according to a first embodiment of the present invention.

FIG. 2 is a conceptual diagram illustrating an AIJ management file according to a second embodiment.

FIG. 3 is a diagram showing an AIJ management area secured on a shared data area according to a third embodiment;

FIG. 4 is a conceptual diagram for explaining the operation principle of the fourth embodiment.

FIG. 5 is a conceptual diagram for explaining the operation principle of the fifth embodiment.

FIG. 6 is an exemplary view for explaining a schedule function of a journal writer according to a sixth embodiment;

FIG. 7 is a conceptual diagram for explaining a conventional mechanism for releasing a lock of a page including update data without waiting for completion of a transaction.

FIG. 8 is a diagram showing a distributed system in which a plurality of computers are connected in a cluster.

[Explanation of symbols]

10 ... node, 11 ... application process, 12
... Journal writer, 13 ... Data writer, 20 ... Shared data area, 21 ... Page, 21 ... AIJ management data,
30 ... Inter-cluster network

Claims (11)

[Claims] When an application process requests a commit of a transaction, update history information of data updated by the transaction is generated, and when the time-series order is guaranteed, a page containing the updated data is locked. Transaction that releases lock of the updated page before the completion of the commit by notifying the application process of the completion of the commit after the update data included in the update history information is determined to be reflected in the data file. In a journal management system for applying a management function to a distributed system in which a plurality of computers share a data file and a journal file storing the update history information is arranged for each of the plurality of computers, Chronological order Journal management system characterized in that to guarantee comprising the order management means for managing each page of the file, the context of the update history information scattered in a plurality of journal file for each page of the data file. 2. The journal management system according to claim 1, wherein the order management means stores identification information indicating a chronological order in the same page in the update history information. 3. The non-volatile storage area according to claim 1, wherein the order management unit secures a table that associates identification information indicating a chronological order in the same page with storage position information indicating a storage position of the update history information. 2. The journal management system according to claim 1, wherein the journal management system manages the journal. 4. An area for holding a serial number that is incremented for each update is secured in each page of the data file, and the order management unit obtains the identification information from the serial number. Or the journal management system according to 3. 5. An area for holding a serial number that is incremented for each update for each page of the data file is secured in a storage area shared by the plurality of computers, and the order management unit performs the identification based on the serial number. 4. The journal management system according to claim 2, wherein information is obtained. 6. A sequence number incremented for each update is managed for each page of the data file by a distributed lock manager that controls acquisition and release of a transaction lock, and the sequence management unit receives the sequence number received from the distributed lock manager. 4. The journal management system according to claim 2, wherein the identification information is obtained from a journal. 7. A journal writer for outputting the update history information to the journal file, wherein the journal writer outputs a header indicating start of writing of the update history information and a trailer indicating end of writing for each write operation. And means for scheduling the update history information generated by the same transaction to be output between the same header and trailer. Or the journal management system according to 6. 8. When a page of the data file is damaged due to a system failure, update history information relating to the page and not reflected in the data file is collected from all the journal files,
A page restoration unit for restoring in accordance with a time-series order managed by the order management unit, wherein the page restoration unit is configured to: The update history information subsequent to the information is discarded and the reflection on the data file is suspended.
Journal management system described. 9. When an application process requests a commit of a transaction, update history information of data updated by the transaction is generated, and when the chronological order is guaranteed, a page containing the updated data is locked. Transaction that releases lock of the updated page before the completion of the commit by notifying the application process of the completion of the commit after the update data included in the update history information is determined to be reflected in the data file. In a journal management system for applying a management function to a distributed system in which a plurality of computers share a data file and a journal file holding the update history information is arranged for each of the plurality of computers, the update history information is The journal file to be stored Journal management, wherein update journal management means is assigned in advance for each page of the data file, and manages so that all of the update history information relating to the same page is stored in the same journal file. system. 10. When an application process requests a commit of a transaction, update history information of data updated by the transaction is generated, and when the chronological order is guaranteed, a page containing the updated data is locked. Transaction that releases lock of the updated page before the completion of the commit by notifying the application process of the completion of the commit after the update data included in the update history information is determined to be reflected in the data file. In a journal management method for applying a management function to a distributed system in which a plurality of computers share a data file, and a journal file holding the update history information is arranged for each of the plurality of computers, The data in chronological order And managed for each page of Airu, journal management method characterized by guaranteeing the context of the update history information scattered in a plurality of journal file for each of the data files. 11. When an application process requests a commit of a transaction, update history information of data updated by the transaction is generated, and when the chronological order is guaranteed, a page containing the updated data is locked. Transaction that releases lock of the updated page before the completion of the commit by notifying the application process of the completion of the commit after the update data included in the update history information is determined to be reflected in the data file. A program for performing journal management for applying a management function to a distributed system in which a plurality of computers share a data file and a journal file holding the update history information is arranged for each of the plurality of computers, Chronological order of update history information A computer-readable storage storing a program for controlling a computer so as to manage each page of the data file, and to guarantee the context of update history information scattered in a plurality of journal files for each data file. Medium.