JP3094888B2 - Numbering mechanism, data consistency confirmation mechanism, transaction re-execution mechanism, and distributed transaction processing system - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a numbering mechanism, a data consistency checking mechanism, a transaction re-execution mechanism, and a distributed transaction processing system. In particular, the present invention relates to a distributed transaction processing system that can be constructed while maintaining high availability and high data consistency when performing distributed transaction processing.

[0002]

2. Description of the Related Art Conventionally, in a computer system for performing distributed transaction processing, when a failure between computers, for example, a crash of one or more computers or a communication path failure occurs, a process for a transaction in an in-doubt state at that time is described below. (A) or (b). The in-doubt state is a state in which prepare completion is notified in response to a prepare request of two-phase commit and a commit / rollback instruction is awaited. Can't decide what to back.

[0003] (A) In response to a transaction in an in-doubt state, a transaction waits for a commit / rollback instruction until the failure is recovered. In particular, when a computer including a transaction in an in-doubt state crashes, the state of waiting for a commit / rollback instruction is reproduced after the computer is rebooted. Such a mechanism is provided, for example, in Oracle7 which is a database management system of Oracle Corporation of the United States. For example, "Oracle7" issued by Oracle Japan, Inc.
Server Overview "part number 6693-70-129
2. According to ja3, 22-19 "Fault in Two-Phase Commit", it is described that Oracle7 has an automatic recovery function.

[0004] (b) The processing for a transaction in an in-doubt state is terminated by waiting for a commit / rollback instruction, and the processing is continued by a user's judgment (heuristic decision). If the user makes a heuristic decision without being able to check the system state, data consistency may be lost. Therefore, after failure recovery, the system
A heuristic reporting system that checks and reports the consistency of commit / rollback between distributed transaction components with D as a key. For example, as described above, “Oracle7 Server
According to "Summary" 22-20, Oracle7 automatically detects erroneous decisions. However, in this case, since the heuristic report notifies the problem transaction by the global transaction ID (GTID) given by the system, the user must determine the actual response from the global transaction GTID.

Conventionally, in the case of the treatment (b), a treatment is performed without using a heuristic report, and there is a distributed transaction processing system in which consistency is confirmed by serial number management in a business application. Below, about this conventional distributed transaction processing system,
This will be described with reference to the drawings. FIG. 32 is a block diagram showing a configuration of a conventional distributed transaction processing system, and FIG. 33 is a flowchart showing a processing flow of a transaction TA1 of site A on the distributed transaction processing system shown in FIG. FIG. 32 shows an example of a system in which databases are synchronously updated at two sites A and B using RPC. In FIG. 33, when the synchronization status is managed by the conventional user serial number, two
The processing contents of a transaction that synchronously updates the database at two sites A and B are shown. DB of FIG. 32
A is the order database (master) of site A,
DBB is a site B order database (replica). Order records RECA, RECB in each database
Has order information Data as a column using the order number Key as a key. The transaction TA1 in FIG.
An order record is created for the order information input from the terminal and inserted into each database.

FIG. 34 is a diagram showing how the data mismatch between site A and site B is detected by the distributed transaction system shown in FIG. Here, an example is shown in which, when the parent transaction commits but the child transaction rolls back, it is detected by the conventional method that the data consistency is broken by the serial number of the user. The structure of the order database (master) DBA of site A and the order database (replica) DBB of site B are as shown in FIG. Transaction TA1 of site A is composed of order information 'AA input from the terminal.
When A 'is received (step S1001), the order number' 101 'is numbered on the database (step S100).
2) Here, commit locally once (step S
1003). Next, the transaction of the site A is composed of order information 'AA input from the terminal using the order number as a key.
An order record RRCA containing A 'is created and written to the order database (master) DBA of site A (step S1004).

Subsequently, the transaction at site A is
For site B, order number (Key), order information (D
data) with RPC (Remot)
ePrecedure Call) (Step S1)
005). At this time, the transaction of site A transmits the order number and the order information to the transaction of site B. The parameter at this time is the order number (Key)
101 'and' AAA 'of the order information (Data). The site B transaction creates an order record RECB according to the parameters sent from the site A transaction, and creates an order database (replica).
Writing to the DBB (step S1006), and returning control to the site A transaction (step S100)
7).

The transaction at site A sends a prepare request to procedure p1 at site B to perform a commit process (step S1008). Site B procedure p
Upon receiving the prepare request, the log collecting mechanism LA collects a prepare log for the prepare request, performs the prepare, and then returns a ready notification (prepare completion notification) to the site A transaction (step S1009). When receiving the ready notification from the site B, the transaction of the site A executes a local commit and transmits a commit instruction to the site B (step S1008). Immediately after this, the transaction of site A determines that the system has crashed before site B receives the commit instruction, and transmits the result to the terminal (step S1010).

[0009] In the procedure of site B, after the cause of the failure is resolved,
The system restarts. In this example, the transaction that was in the prepared state at the time of the failure is rolled back by heuristic determination, and which transaction was rolled back is notified together with the contents of the rolled back record.
The user confirms the same record at site A by referring to the record key in the notified information. As a result, the user knows that data inconsistency has occurred because of the corresponding record.

[0010]

In the above-mentioned conventional distributed transaction processing system, when the transaction processing of (a) is adopted, data consistency can be completely maintained, but resources such as a database fail. There is a problem that the availability of the system is reduced because it is locked until recovery. Even in the case of Oracle7 as an example, when it takes a long time to recover from a failure, it is recommended that a heuristic decision be manually performed. For this, see "Oracl
e7 Server Administrator's Guide "part number 6644
-70-1292. In ja4, 15-15, "Resolving the problem of distributed transactions", the section "Replace in-doubt transactions manually" is mentioned.
In addition, this method is complicated to implement and operate, and some database management systems are not supported.

On the contrary, when (b) is adopted,
Although resources are released immediately and there is no problem in terms of availability, data consistency may be lost if the user cannot confirm the status of transactions of other computers. For this, see "Oracle7
The same section of the Server Administrator's Guide states that incorrect decisions can cause database inconsistencies. With traditional methods, even if heuristic reports show data inconsistencies,
Since there is no direct relationship with the business and the specific recovery procedure is left to the user, the burden on system design and application design is large.

Further, in the above-described method of managing by the serial number of the user, it is necessary to commit at the time of numbering irrespective of the business. If commit is not performed, numbering and rollback will be performed, and if another transaction later renumbers the same serial number as shown in FIG. 35, it cannot be used for detecting consistency. FIG. 35 shows an example in which the consistency cannot be detected if the user's serial number itself is rolled back by the conventional method.

Accordingly, the present invention provides a complicated operation for a failure during a two-phase commit, a reduction in system availability due to data being continuously locked during the failure, and a database management system itself. Can maintain data integrity throughout the system even if it does not support full data integrity by recreating the failure condition, and if the database management system does not support heuristic reporting, A numbering mechanism that allows you to easily check the data integrity status of the entire system,
An object of the present invention is to provide a data consistency check mechanism, a transaction re-execution mechanism, and a distributed transaction processing system.

[0014]

Even if data inconsistency occurs by making a heuristic decision, it is almost always possible to recover consistency by actually inputting an appropriate recovery transaction later. It is. Therefore, heuristic decisions should be made to avoid loss of availability, and if necessary, programs or recovery transactions that were part of the original distributed transaction can later be replaced by local, non-distributed transactions.
Re-execute as a transaction. In this case, since the processing is executed as a local transaction, the portion for performing the communication processing in the original program is NOP except for the reception processing. Since the received data contains information unique to each transaction, it is collected as a log during the execution of a normal distributed transaction. When re-executing as a local transaction, the receiving process is reproduced by reading from this log. Also, the part related to numbering is read from the log and reproduced.

As a specific recovery process from a system failure, first, a transaction that may have lost consistency, that is, a transaction for which a heuristic decision is made, is extracted from the log. In a distributed processing system with heuristic reports,
By utilizing this, a transaction in which data consistency is broken is specified, and a corresponding recovery transaction is input with a corresponding transaction ID. In a distributed processing system without a heuristic report, whether data consistency between the two systems is maintained by matching records in the DB based on serial numbers by a numbering mechanism that is guaranteed to not return due to rollback or system failure Judge. Hereinafter, means for solving the present invention will be described for each claim.

The numbering mechanism according to the present invention holds the sequence number in a memory and a file, counts up the sequence number in the memory by calling a numbering command from the business program, returns the sequence number to the business program, and executes the entire computer. Writes the latest sequence number to a file at least once every N times given by the default value or definition, is not returned by transaction rollback, and is not numbered and locked until the commit after numbering Mechanism,
After a system failure that causes loss of memory information, the sequence number remaining in the file plus the sequence number of N or more is restored, so that even if a failure occurs, a sequence number larger than the sequence number last returned to the business program And a numbering recovery mechanism for restarting numbering from the beginning.

In the distributed transaction processing, the data consistency checking mechanism according to the present invention includes a database for writing a record using a serial number as a key provided by a numbering mechanism according to claim 1 provided in a distributed node of a transaction serving as a coordinator. A log collection mechanism that writes the same serial number to the log at the latest at the same time as the prepare log provided in the distributed node to be denied, a consistency judgment definition that specifies the location of data to be matched at the time of data consistency check, and a judgment method, Data inconsistency due to heuristic decision at the time of failure, consistency for transactions that have an in-doubt prepared log but have not been committed / rolled back by the coordinator's instruction, whether there is a record corresponding to the serial number in the log Match according to the judgment definition information It is characterized in that it has a data inconsistency detection mechanism to further detected.

The transaction re-executing mechanism according to the present invention executes the program, which is one distributed node of the distributed transaction processing, while collecting the recovery processing log and the numbering processing according to claim 1 during normal execution, At the time of re-execution, the program or the corresponding recovery program is re-entered as a local transaction with the original transaction ID, NOP is performed for communication processing other than the program reception processing, and the reception processing and the method according to claim 1 are adopted. The number process is characterized in that it has a program interface mechanism for writing to a log during normal execution, reproducing by reading from the log based on the transaction ID, and processing the transaction as a local transaction.

The distributed transaction processing system according to the present invention comprises the following components a) to f):
The parent transaction that starts the child transaction becomes the coordinator on the two-phase commit,
A rollback is performed as a heuristic decision in b), a heuristic report is provided as a data consistency check mechanism in e), and the original child transaction itself is used as a rerun transaction by the transaction rerun mechanism in f). By submitting, the transaction in the prepared state is temporarily rolled back after the occurrence of a failure between the computers, and the child transaction is resubmitted as a local transaction later as needed to restore the consistency between the computers. It is characterized by the following. a) a log collection mechanism; b) a heuristic decision mechanism for committing / rolling back a transaction waiting for a commit / rollback decision from the partner transaction in the event of a failure by local heuristic decision; A recovery candidate transaction extraction mechanism for extracting a transaction without a log and a rollback log as a recovery candidate; d) when a transaction becomes a recovery candidate,
Injection instruction information indicating which transaction should be injected. E) Confirming, after recovery from the failure, whether data consistency between the transaction committed / rolled back by the heuristic decision and the partner transaction has not been lost. The data reconciliation mechanism according to claim 3, wherein:

A distributed transaction processing system according to the present invention comprises the components described in claims 4) to 4), wherein a child transaction becomes a coordinator on a two-phase commit, and a role is determined as a heuristic decision in b). A heuristic report is provided as a data consistency check mechanism of e), and the original parent transaction itself is input as a re-executed transaction by the transaction re-executing mechanism of f). After the occurrence of a failure, a transaction in the prepared state is temporarily rolled back, and the parent transaction is re-entered as a local transaction as needed to restore consistency between computers. .

The distributed transaction processing system according to the present invention comprises the components described in claims 4) to 4), wherein the parent transaction which activates the child transaction becomes a coordinator on two-phase commit, and b The commit is performed as a heuristic decision in (1), and a heuristic report is provided as a data consistency checking mechanism in (e), and a claim 3 is provided as a transaction re-executing mechanism in (f), and the original child transaction is supported. By submitting a recovery transaction, a prepared transaction is temporarily committed after a failure occurs between computers, and then the recovery transaction is re-submitted as a local transaction later if necessary, thereby ensuring consistency between computers. Characterized by restoring sex It is intended.

A distributed transaction processing system according to the present invention comprises the components described in claims 4) to 4), wherein a child transaction becomes a coordinator on two-phase commit, and a heuristic decision is made in b). It performs a commit, has a heuristic report as a data consistency check mechanism of e), has claim 3 as a transaction re-execution mechanism of f), and inputs a recovery transaction corresponding to the original parent transaction. In this way, it is possible to temporarily commit a prepared transaction after a failure has occurred between computers, and then re-enter a recovery transaction as a local transaction as needed to restore consistency between computers. It is a feature.

[0023] In the distributed transaction processing system according to the present invention, in the distributed transaction processing system according to the fourth aspect, the data consistency confirmation mechanism is set to e) in the fourth aspect.
The data consistency check mechanism of the present invention is changed to the data consistency check mechanism of claim 2.

[0024] The distributed transaction processing system according to the present invention is the distributed transaction processing system according to claim 5, wherein the data consistency confirmation mechanism is as set forth in claim 5;
3. The distributed transaction processing system according to claim 2, wherein the data consistency checking mechanism is changed to the data consistency checking mechanism according to claim 2.

In the distributed transaction processing system according to the present invention, in the distributed transaction processing system according to the sixth aspect, the data consistency confirmation mechanism is set to e) in the sixth aspect.
The data consistency check mechanism of the present invention is changed to the data consistency check mechanism of claim 2.

The distributed transaction processing system according to the present invention is the distributed transaction processing system according to claim 7;
3. The distributed transaction processing system according to claim 2, wherein the data consistency checking mechanism is changed to the data consistency checking mechanism according to claim 2.

[0027]

Embodiments of the present invention will be described below with reference to the drawings. Embodiment 1 FIG. In this embodiment, a serial number by a numbering mechanism that does not return even if rollback or system failure occurs,
This is an example used for notification of normal / abnormal termination of an application. Hereinafter, the present embodiment will be described with reference to the drawings. FIG. 1 is a flowchart showing a processing flow of a transaction using the numbering mechanism according to the first embodiment of the present invention. First, upon receiving the order information input from the terminal (step S1), the numbering mechanism performs numbering for each order (step S2), and sends the numbering result, that is, processing confirmation information to the terminal. It transmits (step S3). The terminal operator can output the processing confirmation information transmitted from the numbering mechanism to the screen of the terminal, record the work entered by the terminal operator thereafter, and refer to this serial number as a key. As a result, the terminal operator knows that the transaction processing is, for example, No. 20.

The numbering mechanism actually performs the business process (step S4), determines whether there is an error, and if it determines that there is no error and normal termination (step S5), the normal termination including the serial number is performed. A message is output (step S6), and commit is performed. On the other hand, when the numbering mechanism determines that there is an error and the processing ends abnormally (step S5), the numbering mechanism outputs an abnormal end message including the serial number (step S5).
8) Roll back (step S9). By referring to the output of the normal end / abnormal end message, the terminal operator can judge whether or not the 20th of the work entered by the terminal operator has ended without any error. Here, if the serial number is also rolled back, the same serial number is reused when the next job is input, and cannot be used for identifying the job.

Next, FIG. 2 is a flowchart showing a processing flow of the numbering mechanism according to the first embodiment of the present invention. Here, the contents of the process of numbering by the numbering mechanism and returning the result to the application are shown. Upon receiving the numbering request information transferred from the application (step S11), the numbering mechanism locks the current numbering area on the memory (step S12) and adds +1 to the current numbering on the memory. Then, the numbering is rewritten (step S13). The numbering mechanism locks the 19th area on the memory, for example, and rewrites the 19th number to 20th. Thereafter, the numbering mechanism determines whether the numbering is a multiple of N, and
If it is determined that the number is a multiple of (step S14), the numbering in the memory is stored in the non-volatile medium (step S1).
5) After the current numbering on the memory is unlocked (step S16), the numbering result is returned to the application (step S17).

On the other hand, when determining that the numbering is not a multiple of N (step S14), the numbering mechanism unlocks the current numbering in the memory without storing the numbering in the memory in the non-volatile medium (step S14). In step S16, the numbering result is returned to the application (step S17). It is assumed that the numbering mechanism writes data to the memory once every ten times, for example.
When the number becomes 0, the number 20 is written in the memory. This ensures that the counter has advanced to 20 on disk. The numbering mechanism, for example, when the numbering becomes 21, the numbering is advanced on the memory, unlocked, and returned to the application.

FIG. 3 is a flowchart showing a numbering recovery processing flow of the numbering mechanism according to the first embodiment of the present invention. Here, the contents of the current numbering recovery process by the numbering mechanism after the occurrence of a failure that causes loss of memory contents such as a system crash are shown. The numbering mechanism recovers the current numbering from the non-volatile medium (step S21) and adds + N to the current numbering. The numbering mechanism, for example, if a system crash or the like occurs when the numbering becomes 15, the numbering is stored in the memory, and all information in the memory is lost. There is nothing to rely on. For example, it is assumed that the non-volatile medium has a numbering 10 smaller than the numbering 15 now, and when the numbering 10 starts to be used, it is possible that the number has already reached 19. Sometimes. In order to avoid this, for example, if +10 is added to the current numbering, writing is performed once every ten times even if the process proceeds. For this reason,
Since the numbering is increased from the current +10 times to 20 times, and the numbering may be used from the 20th time, it is possible to guarantee that the numbering does not return. Therefore, by performing such processing, the serial number by this numbering mechanism can be skipped, but the duplication can be eliminated.

As described above, in the present embodiment, the sequence number is held in the memory and the file on the non-volatile medium, and the sequence number in the memory is counted up by calling a numbering instruction from the business program, thereby increasing the sequence number in the memory. The latest sequence number is written to a file at least once every N times given by the default value or definition in the whole computer. Since there is no program numbering mechanism that is not numbered, it is locked until there is a request and returns to the application, but this numbering can be used freely until the commit. Therefore, even if another transaction comes, it can be counted up and used.

In this embodiment, the sequence number + N remaining in the file after the occurrence of a system failure in which information in the memory is lost
By restoring the above sequence numbers, even if a failure occurs, the business program has a numbering recovery mechanism that restarts numbering from the sequence number larger than the last returned sequence number. For example, even if a crash occurs when the numbering 19 is returned, the numbering is returned from the numbering number 20 or more, so that the numbering can be obtained without duplication.

According to the present embodiment, when the user wants to obtain the identification information of each transaction, the numbering can be obtained without using any database or file and without duplication. Further, as is clear from the flowchart of FIG. 2, such a numbering is performed only during the numbering process for serializing the process. Can be done. Moreover, since I / O is performed once per N transactions, the availability of the system can be improved.

Embodiment 2 The present embodiment is a data consistency check mechanism in a distributed transaction processing system extending between two computers, and an order number is assigned to order information received from a terminal at one site, and this number is assigned. Using the order number as a key, the order data is written into the order database (master) at site A, and the RPC (Re
This is an example of application to a transaction that writes data to an order database (replica) at site B using a “mote Procedure Call” p1. This embodiment will be described below with reference to the drawings on how the data consistency is confirmed after the system B at the site B crashes.

FIG. 4 is a block diagram showing the configuration of the distributed transaction processing system according to the second embodiment of the present invention. Here, an example of a system in which databases are synchronously updated at two sites A and B using RPC is shown. In FIG. 4, 1 and 2 are computers, 3 and 4 are order databases, 5 and 6 are log collecting mechanisms, and 7 is a numbering mechanism. 8 is an application, 9 is a terminal, and 10 and 11 are order records. Order records 10, 1 in each order database 3, 4
1 designates order information (Da) using an order number (Key) as a key.
ta) as a column. The computer 1 on the site A has an order database (master) 3, a log collection mechanism 5,
A numbering mechanism 7, an application 8, and the like are provided.
The computer 2 on the site B does not have a numbering mechanism, and has an order database (replica) 4 and a log collection mechanism 6.
Etc. are provided. In the present embodiment, when updating by the application 8 of the computer 1 on the site A side, the site A
The order database 3 of the site B and the order database 4 of the site B are updated synchronously. When the update on the site A side is confirmed, the update on the site B side is confirmed, and when the update on the site A side is canceled, the update on the site B side is canceled. Set to.

FIG. 5 is a flowchart showing a transaction processing flow of the distributed transaction processing system shown in FIG. Here, the processing contents of a transaction for updating the databases 3 and 4 synchronously at the two sites A and B using RPC are shown. Upon receiving the order information input from the terminal 9 (step S31), the computer 1 on the site A performs the same numbering as in the first embodiment and collects the order number by the numbering (step S31).
32) The order information is inserted into the order database 3 on the site A side using the collected order number as a key (step S33). The computer 1 on the site A uses the order number (Key) and the order information (Data) inserted in the order database 3 of the site A as arguments to the computer 2 on the site B by RPC.
Is performed (step S34).

The computer 2 on the site B side inserts order information into the order database 4 on the site B side using the same order number as that on the site A side transferred from the computer 1 on the site A side as a key (step S35) and calls it. The control is returned to the original computer A on the site A side (step S36). in this way,
The computer 1 on the site A updates with the numbered order number and the order information, and transmits the updated order number and the order information to the computer 2 on the site B side. The computer 2 on the site B updates with the order number and the order information transmitted from the computer 1.

Computer 1 on site A, after the end of RPC,
The prepare request information is transmitted to the computer 2 on the site B side (step S37). When the prepare request information transmitted from the computer 1 is received, the computer 2 on the site B performs a prepare and sends the prepared request to the computer 1 on the site A side. The prepare completion information is transmitted (step S38). Calculator 1 on site A
When the prepare completion information transmitted from the computer 2 is received, a commit is performed, commit request information is transmitted to the computer 2 on the site B side (step S37), and a result of the commit is transmitted to the terminal 9 (step S3).
9). When receiving the commit request information transmitted from the computer 1, the computer 2 on the site B performs a commit (step S38).

Next, FIGS. 6 and 7 are sequence diagrams showing how the data consistency between the sites A and B of the distributed transaction processing system shown in FIG. 4 is confirmed. FIG. 6 shows a state in which data consistency of both sites A and B is confirmed when there is no inconsistency, and FIG. 7 shows a case where both sites A and B in the case where there is inconsistency. This shows how data consistency is confirmed. As shown in FIG. 6, the transactions of the sites A and B correspond to the order records 10 and 11 corresponding to the order information input from the terminal 9.
Is created, and the created order records 10 and 11 are inserted into the order databases 3 and 4.

The structure of each of the order databases 3 and 4 is shown in FIG.
As shown in FIG. First, the case where the coordinator side of site A is rolled back and no inconsistency occurs is shown in FIG.
Next, a case where the coordinator side of the site A is committed and an inconsistency occurs will be described with reference to FIG.

The computer 1 on the site A assigns the order number “101” to the input information “AAA” transmitted from the terminal 9 by using the numbering mechanism of the first embodiment. Using the numbered order number '101' as a key, an order record 10 containing the input information 'AAA' transmitted from the terminal 9 is created and written to the order database 3.

Next, the computer 1 on the site A side
RPC of procedure p9 is performed for the computer 2 on the side. At this time, the computer 2 of the site B has a parameter for performing the procedure p9 from the computer 1 of the site A, that is, “101” of the order number (Key) numbered by the site A and the order information ( Data) 'AAA' is transmitted.

When the computer 2 on the site B receives the order number and the parameters of the order information transmitted from the computer 1 on the site A, the computer 2 creates an order record 11 in accordance with the order number and the parameters of the order information, and creates an order database. 4
And the control is returned to the computer 1 on the site A side. The computer 1 on the site A transmits the prepare request information to the computer 2 on the site B to perform a commit process.

When the computer 2 on the site B receives the prepare request information transmitted from the computer 1 on the site A,
The log collection mechanism 6 of the site B collects the prepare log including the order number. As shown in FIG. 8, the contents of the prepare log include a TID indicating a transaction ID.
, P indicating a flag indicating a prepare log, an RPC procedure name, Key (order number; key of order database) of RPC parameters, and Data (order information).

The computer 2 on the site B side prepares the
It is assumed that after log collection, a system crash occurs before sending ready (prepared) information to the computer 1 of the site A. After collecting the prepare log, the computer 2 on the site B is in a state of waiting for a command for commit or rollback from the computer 1 on the site A, and may commit or roll back. I can't decide for myself. Calculator 2 on Site B is
Suppose a system crash occurs while waiting for a commit / rollback instruction.

Since the ready information is not transmitted from the computer 2 on the site B, the computer 1 on the site A is timed out and rolled back. That is, the record writing of the order record 10 to the order database 3 is as follows.
Canceled, the order database 3 returns to its original state.

On the other hand, at the site B, after the cause of the failure is resolved, the system is restarted. In this example, it is assumed that the transaction in the prepared state at the time of the failure is rolled back by heuristic determination.

Next, after the communication path with the site A is restored,
For the transaction for which heuristics have been determined, the consistency checker performs processing in accordance with the flowchart shown in FIG. 10 described below. Here, it shows how the consistency check is performed for the transaction for which the heuristic decision has been made. The consistency checking mechanism reads the judgment definition information of the corresponding transaction (step S41), and after reading the serial number information in the log indicated by the read judgment definition information (step S42),
A record having the key of the serial number information in the log of the partner database indicated in the judgment definition information is searched (step S4).
3).

As shown in FIGS. 8 and 9, the consistency checking mechanism first reads the key of the serial number information in the prepare log,
I go to the other party's database that matches this key. FIG. 8 shows the contents of the prepare log as a confirmation mechanism. Naturally, it is not possible to confirm unless information is entered at the key of the RPC parameter. FIG. 9 shows information on which should be matched. The RPC 1 shown in FIG. 9 is a process for matching key information in the prepare log with the order number in the order database of the partner site A. As a heuristic decision,
Indicate that your side will be rolled back.

If the consistency checker has searched for the record of the partner (step S44), it determines whether this heuristic decision is a commit, and if this heuristic decision is a commit (step S45). ), It is determined that there is no mismatch. When the consistency check mechanism determines that there is a record of the other party and that the heuristic decision is rollback (steps S44 and S45), it is determined that the record is inconsistent. If the consistency checker has not searched for the record of the partner (step S44), the consistency checker determines whether this heuristic decision is a commit, and determines that this heuristic decision is a commit (step S4).
6) It is determined that there is a mismatch. When the consistency check mechanism determines that there is no partner record and that the heuristic decision is rollback (step S44,
46), it is determined that there is no mismatch.

The consistency checking mechanism first checks the log and obtains the order number '101'. A corresponding record of the same key in the order database 3 of the site A is searched.
Since this has not been rolled back, it is detected that no inconsistency has occurred. Which field in the log should be compared with which database record at which site should be given to the consistency checker in advance as a judgment definition for each transaction as shown in FIG.

When the site B crashes, the site A is rolled back because the ready is not notified from the site B. Since the database 3 of the site A rolls back, it returns to the original state. In the next transaction, the numbering mechanism does not return just because the rollback is performed, so that the transaction is searched from '102'. '101' is a state in which it is not found. When Site B starts up, it doesn't know if heuristic decisions will make it consistent, but it's decided to roll back anyway,
Then go to the log and see that '101' is an in-doubt. The point is, I don't know which information to set. So site B queries site A to find out which one to set. Since the consistency check mechanism of the site B has not searched for “101”, it is found that the rollback has been performed.

In the same example, as shown in FIG. 7, it is assumed that the computer 2 on the site B side has just occurred a system crash immediately after sending a ready notification. The computer 1 on the site A receives the ready notification from the computer 2 and executes the commit to create a record 10 of '101'. After that, the computer 1 on the site A transmits the commit request information to the computer 2 on the site B, but the computer 2 on the site B
Has been crashed, so this commit request is ignored. On the other hand, in the computer 2 on the site B side, after the cause of the failure is resolved, the system is restarted. As in the case of FIG. 6, the transaction in the prepared state is rolled back by heuristic determination.

Next, a transaction heuristically determined after the communication path with the computer 1 on the site A side is restored will be described. The consistency checker checks the log and obtains the order number '101' as in FIG. The corresponding record of the same key in the order database 3 of the computer 1 on the site A side corresponding to this is searched for, but since it has been committed, it can be seen that inconsistency has occurred. By the above procedure, the consistency between the two sites can be confirmed in any case after the system crash.

As described above, in the present embodiment, in the distributed transaction processing, the order record using the serial number by the same numbering mechanism 7 as in the first embodiment provided at the site A of the distributed node of the transaction serving as the coordinator as a key 10 and an order database 3 for writing the same serial number in a log before the prepare log at the latest at the site B of the distributed node serving as a subordinate. The definition of the consistency judgment that specifies the location of the data to be judged and the judgment method, and the data inconsistency due to the heuristic decision at the time of failure, for the transaction that has an in-doubt prepared log but has not been committed / rolled back by the coordinator's instruction To check if there is a record corresponding to the serial number in the log By matching according to the consistency judgment definition information, it can be detected and the user
It is configured to have a data inconsistency detection mechanism that does not need to be aware of the transaction ID. For this reason,
In a data consistency check at the time of a system failure when performing transaction processing in a distributed system including two computers 1 and 2, it is possible to check the consistency without relying on a heuristic report or a global ID. Conventionally, in a system that performs a heuristic report after a heuristic decision is made, the ID is known, but since it is an ID assigned to each transaction unrelated to the business, it cannot be confirmed in a business manner. However, such a problem can be solved.

Embodiment 3 This embodiment is a transaction re-executing mechanism in a distributed transaction processing system extending between two computers, and creates order data for order information received from a terminal at a site A, and activates a site B by a distributed transaction activation. This is an example of application to a process of writing in an order database, obtaining payment information at site A as a result of a distributed transaction, and printing a slip. In this distributed transaction processing system, it is assumed that the order database exists only at the site B, and the commit is performed only at the site B. Hereinafter, the present embodiment will be described with reference to the drawings.

FIG. 11 is a block diagram showing a configuration of the distributed transaction processing system according to the third embodiment of the present invention at the time of normal execution. FIG. FIG. 3 is a block diagram illustrating a configuration at the time of execution. The portion indicated by the dotted line in FIG. 12 is a portion that is involved during normal execution and is not involved during re-execution. 11 and 12, the same reference numerals as those in FIG. 4 denote the same or corresponding parts, 21 and 22 are transactions, 23 is a re-execution mechanism, 24 and 25 are management terminals, and 26 is a printer. In the present embodiment, although the distributed transaction itself is the same, the transaction 21 of the site A and the transaction 22 of the site B
, A process of updating the order database 4 of the site B, obtaining the result, and printing out with the printer 26 is performed. To perform this processing, when site B crashes at a certain timing, that is, when the system crashes after updating the order database 4,
Processing is performed only at site A.

Next, FIG. 13 shows transaction 2 of site A in the distributed transaction processing system shown in FIG.
6 is a flowchart showing a processing flow in a normal execution of a transaction 22 of a site 1 and a site B. Here, the processing contents (at the time of normal execution) of a transaction for updating a remote database using a distributed transaction and outputting a form locally are shown. When the transaction 21 of the site A is started from the terminal 9, after receiving the order information transmitted from the terminal 9 and collecting the terminal reception log (step S51), the transaction number is assigned to the order number and the numbering log is collected. It is collected (step S52).

The transaction 21 of the site A is activated by using the numbered order number (Key) and the order information (Data) as arguments and transmits the transaction number to the transaction 22 of the site B (step S53). When receiving the order number and the order information transmitted from the transaction 21, the transaction 22 of the site B inserts and updates the received order information into the order database 4 using the received order number as a key (step S54). After updating the order database, the transaction 22 of the site B transmits the payment information to the transaction 21 of the site A as a result (step S55), and then commits locally (step S56).

When receiving the payment information transmitted from the transaction 22 (step S57), the transaction 21 of the site A transmits an end notification to the transaction 22 of the site B (step S58). When receiving the end notification transmitted from the transaction 21 (step S59), the transaction 22 of the site B determines whether the reception is normal, and if the reception is normal (step S60), the transaction ends and the reception is not normal (step S60). Step S
60), the transaction ID is displayed on the management terminal 25 (step S61). Transaction 2 of Site A
1 transmits a form including the order number and payment information to the printer 26 after transmitting the end notification to the site A (step S
62), and transmits the result to the terminal 9 (step S63).

FIG. 14 is a flowchart showing a local re-execution processing flow at the site A in the distributed transaction processing system shown in FIG. Here, the processing contents (at the time of re-execution) of a transaction for updating a remote database using a distributed transaction and outputting a form locally are shown. Here, a description will be given, with reference to FIG. 12, of how a form that has not been output due to a system crash at site A is output without affecting site B by re-executing a transaction at site A, with reference to FIG. . At the time of normal execution in FIG. 11, as described above, the transaction 21 of the site A is activated from the business terminal 9, activates the transaction 22 of the site B, and outputs the processing result to the printer. Suppose that a system crash has occurred at site A immediately after starting transaction 22 at site B.

As described above, if a system crash occurs at the site A immediately after the start of the transaction 22 at the site B, the reception of the termination notification at the site B is abnormally terminated. The generated transaction ID is displayed. At the time of re-execution,
As shown in FIG.
D instructs the re-executing mechanism 23 to start, whereby the processing is performed only at the site A in accordance with the flow of FIG. 14 described later. In this case, transaction 2
If steps 1 and 22 are re-executed as they are, the database 4 of the site B will be updated twice, and the numbering will be reset.

Therefore, as shown in FIG. 13, reception information and numbering information are recorded in a log at the time of normal execution, and as shown in FIG. 14, these are read from the log at the time of re-execution. If the processing is NOP, the required form is correctly output, and the site B and the terminal 9 are not affected. At the time of re-execution, the transaction 21 of the site A collects the order number written in the log from the terminal 9 when there is a restart request from the management terminal 25 without starting from the terminal 9 (steps S71 and S72). ), Since it is not necessary to request the site B using the numbering, a NOP is set (step S73), and the reception processing is logged (step S73).
74). Then, the transaction 21 of the site A is
The end notification is set to NOP (step S75), and the form including the order number and payment information is output (step S7).
6) The result transmission is set to NOP (step S77), and the process ends.

As described above, in this embodiment, the program which is one distributed node of the distributed transaction processing is
At the time of normal execution, the receiving process and the numbering process according to the first embodiment are executed while being collected in the recovery log.
The program or the corresponding recovery program is re-entered as a local transaction with the original transaction ID, and the communication process other than the program reception process is turned to NOP.
The numbering process is performed by writing to a log during normal execution, reproduced by reading from the log based on the transaction ID, and having a program interface mechanism for processing as a local transaction as a transaction. Therefore, at the time of re-execution, these are read from the log, and other transmission processing is NO.
By setting to P, necessary forms can be output correctly, so that site B and terminals can be prevented from being affected. Therefore, in a distributed system including a plurality of computers 1 and 2, a plurality of transactions 21 and
When the processes are performed in cooperation with each other, when it is desired to re-execute only the specific transaction 21 due to a failure or the like, the re-execution can be easily performed.

Embodiment 4 This embodiment is a distributed transaction processing system extending between two computers, and writes order information received from a terminal at a site A into an order database (master) at a site A, and
This is an example of application to a transaction that writes to the order database (replica) of site B by p1. Site B
This embodiment will be described below with reference to the drawings on how the data consistency is restored after the system crash.

FIG. 15 is a block diagram showing a configuration of a distributed transaction processing system according to the fourth embodiment of the present invention. In FIG. 14, the same reference numerals as those in FIGS. 4 and 11 denote the same or corresponding parts. Reference numeral 31 denotes the transaction 22 of the site B waiting for a commit / rollback decision from the transaction 21 of the partner site A at the time of failure.
A heuristic decision mechanism for committing / rolling back by a local heuristic decision for the time being, 32 is a recovery candidate transaction extracting mechanism for extracting a transaction having only a prepare log and no commit log or rollback log as a recovery candidate. . Data consistency checks 33 and 34 confirm whether or not the data consistency between the transaction 22 of the site B committed / rolled back by the heuristic decision and the transaction 21 of the partner site A is restored after recovery from the failure. It is a sex confirmation mechanism. The distributed transaction processing system according to the present embodiment includes a log collection mechanism 5, a heuristic determination mechanism 31, a recovery candidate transaction extraction mechanism 32, and which transaction should be input when a certain transaction becomes a recovery candidate. , Data consistency checking mechanisms 33 and 34, and a transaction re-executing mechanism 23 similar to the third embodiment.

The distributed transaction processing system according to the present embodiment comprises the above-mentioned components. In particular, the transaction 21 of the site A, which activates the transaction 22 of the site B, becomes a coordinator even after two-phase commit. , Heuristic decision mechanism 3
The rollback is performed as the heuristic determination in step 1, and a heuristic report is provided as the data consistency checker 33.
By inputting the transaction 22 itself at the site B, after a failure between the computers 1 and 2 occurs, the transaction in the prepared state is temporarily rolled back,
Later, the transaction 22 of the site B is re-entered as a local transaction as necessary, and
This is a system that restores consistency between the two. Embodiment 2
In the above, the case where the consistency check is performed has been described. However, the distributed transaction processing system according to the present embodiment is configured to perform the process of restoring the consistency after performing the consistency check.

Next, FIG. 16 is a flowchart showing a transaction processing flow on the distributed transaction processing system shown in FIG. Here, the processing contents of a transaction for updating the databases 3 and 4 synchronously at the two sites A and B using RPC are shown. When the transaction 21 on the site A receives the order information input from the terminal 9 (step S81),
The same numbering as in the first embodiment is performed, an order number is collected by the numbering (step S82), and the order information is inserted into the order database 3 of the site A using the collected order number as a key (step S83). .

The transaction 21 on the site A side receives the order number (Ke) inserted into the order database 3 of the site A.
y) and the order information (Data) as arguments, perform RPC to the transaction 22 of the site B (step S8)
4). Transaction 22 on site B is site A
The order information is inserted into the order database 4 on the site B side using the same order number as that on the site A side transferred from the transaction 21 on the side as a key (step S85), and the control is returned to the transaction 21 on the caller site A side (step S85). Step S86).

As described above, the transaction 21 on the site A updates with the numbered order number and the order information, and transmits the updated order number and the order information to the transaction 22 on the site B side. . The transaction 22 on the site B updates with the order number and the order information transmitted from the transaction 21. After the RPC ends, the transaction 21 on the site A transmits the prepare request information to the transaction 22 on the site B (step S87), and the transaction 22 on the site B
When the prepare request information transmitted from the transaction 21 is received, a prepare is performed, and the prepare completion information is transmitted to the transaction 21 on the site A side (step S88).

Upon receiving the prepare completion information transmitted from the transaction 22, the transaction 21 on the site A commits, transmits the commit request information to the transaction 22 on the site B (step S87), and transmits the information to the terminal 9. The result of the commit is transmitted (step S89). Upon receiving the commit request information transmitted from the transaction 21, the transaction 22 on the site B commits (step S
88).

Next, FIGS. 17 and 18 are sequence diagrams showing communication and database changes caused by the distributed transaction processing system shown in FIG. 17 and 18 show how the data consistency between the two sites is maintained. In FIG. 17, the parent site A
18 shows a state in which both sites roll back when rollback is performed. FIG. 18 shows a state in which both sites commit when parent site A commits. As shown in FIG. 17, transactions 21 and 22 of sites A and B create order records 10 and 11 for the order information input from the terminal 9 and store the created order records 10 and 11 in each order database 3. , 4 is inserted.

The structure of each of the order databases 3 and 4 is shown in FIG.
As shown in FIG. First, the case where the coordinator side of site A is rolled back and both sites A and B are rolled back and consistency is maintained will be described with reference to FIG. The case where B is committed and the consistency is maintained will be described with reference to FIG.

The computer 1 on the site A assigns the order number “101” to the input information “AAA” transmitted from the terminal 9 by using the numbering mechanism of the first embodiment. Using the numbered order number '101' as a key, an order record 10 containing the input information 'AAA' transmitted from the terminal 9 is created and written to the order database 3.

Next, the computer 1 on the site A side
RPC is performed on the procedure p18 for the computer 2 on the side. At this time, the computer 2 of the site B is provided with the computer 1 of the site A.
, Parameters for performing the procedure, that is, '101' of the order number (Key) numbered on the site A side and 'AAA' of the order information (Data) are transmitted.

When the computer 2 on the site B receives the order number and the order information parameters transmitted from the computer 1 on the site A side, the computer 2 creates an order record 11 in accordance with the order number and the parameters of the order information. 4
And the control is returned to the computer 1 on the site A side. The computer 1 on the site A transmits the prepare request information to the computer 2 on the site B to perform a commit process.

When the computer 2 on the site B receives the prepare request information transmitted from the computer 1 on the site A,
The log collecting mechanism 6 of the site B collects a prepare log including a global transaction ID (GTID) and RPC parameters as reception information. As shown in FIG. 19, the contents of the prepare log include a GTID indicating a global transaction ID, a prepare
P indicating a flag indicating a log, RPC procedure name, and RP
Key (order number; key of order database) of C parameter and Data (order information) are included.

The computer 2 on the site B side prepares the
It is assumed that after log collection, as shown in FIG. Calculator 2 on Site B
Is waiting for a commit or rollback instruction from the computer 1 on the site A after collecting the prepare log. Can not. It is assumed that the computer 2 on the site B side has crashed while waiting for a commit / rollback instruction.

Since the computer 1 on the site A does not transmit the ready information from the computer 2 on the site B, a timeout occurs and the transaction 21 is rolled back. That is, the order record 10 in the order database 3
Record writing is canceled, order database 3
Returns. On the other hand, Site B
The system restarts. In this example, it is assumed that the transaction in the prepared state at the time of occurrence of the failure is rolled back by the heuristic determination mechanism 31.

First, the recovery candidate transaction extraction mechanism 32 extracts a prepared log of a transaction that has only a prepared log and has not been committed or rolled back as a recovery candidate. At this time, since the prepare log of the procedure p18 of the global transaction GTID = i is applicable, it is extracted.

Next, after the communication path with the site A is restored,
The data consistency checking mechanism 33 of the site A and the data consistency checking mechanism 34 of the site B communicate with each other by the heuristic report, and the global transaction GTI
The status of the parent transaction 21 of D = i is confirmed. In this case, since the parent has also been rolled back as described above, re-input is not performed, and the sites A and B are both rolled back, so that data consistency is maintained.

In the same example, as shown in FIG. 18, it is assumed that the computer 2 on the site B side has occurred immediately after the system crash has sent the ready notification. The computer 1 on the site A receives the ready notification from the computer 2 and executes the commit to create a record 10 of '101'. Thereafter, the computer 1 on the site A side becomes the computer 2 on the site B side.
The commit request information is transmitted to the site B, but the computer 2 on the site B has crashed, so that the commit request is ignored.

On the other hand, in the computer 2 on the site B side, after the cause of the failure is resolved, the system is restarted. As in the case of FIG. 17, the transaction in the prepared state is rolled back by the heuristic determination mechanism 31 and the recovery candidate transaction extraction mechanism 32 executes the procedure p1.
Eight prepare logs are extracted.

Next, after the communication path with the site A is restored,
In the computer 2 on the site B side, the data consistency check mechanism 33 of the site A and the data consistency check mechanism 34 of the site B update the status of the parent transaction 21 of the global transaction GTID = i by using a heuristic report. I do. This time, as described above, since the parent transaction 21 has been committed, the procedure p18 is reentered as a local transaction by the transaction reexecuting mechanism 23. Procedure p18
Writes a record according to the parameters, so that a record with key '0101' and data 'AAA' is created. As a result, both sites have the same record and maintain consistency. As described above, in the present embodiment, the data in the prepared state is rolled back, the transaction is extracted from the log by the recovery candidate transaction extraction mechanism 32, and information for re-input is extracted. Consistency checking mechanisms 33, 34 using heuristic reports
To check the consistency, and if the consistency is consistent,
If you don't reboot and the consistency doesn't match,
Perform a restart. For this reason, the consistency can be maintained because the consistency is restored if the consistency is broken.

Next, FIG. 20 is a flowchart showing the processing flow of checking the consistency and re-inputting shown in FIGS. The recovery candidate transaction extraction mechanism 32 determines whether there is any untreated transaction among the re-entry candidate transactions, and if there is an untreated transaction (step S91), sets the transaction to be treated as T (step S9)
2) On the other hand, when there is no untreated one (step S9)
1) Exit the loop and end the process. The data consistency checking mechanisms 33 and 34 check whether or not the consistency of the transaction T is maintained by the global transaction GTID and the heuristic report (step S93), and when the consistency is broken (step S94). Then, the RPC name and the parameter of the transaction T are set (step S95).

If the consistency has not been lost (step S94), the data consistency checking mechanisms 33 and 34 determine that the transaction T has been processed and return to step S91 of the next transaction (step S96). The transaction 21 on the site A, after setting the RPC name and parameters,
The RPC of the transaction 22 of the site B is called (step S97), and the transaction 2 of the site B is executed.
2 receives the RPC request from the site A, performs the processing of each RPC (step S98), and executes the caller site A
Control is returned to the transaction 21 (step S9).
9). The transaction 21 of the site A calls the above-described RPC of the transaction 22 of the site B, and issues a commit request to the transaction 22 of the site B (step S100). When receiving the commit request from the site A, the transaction 22 of the site B performs a local commit process (step S10).
1).

As described above, in the present embodiment, site B
The transaction 21 of the parent site A that activates the transaction 22 becomes the coordinator on the two-phase commit, and rolls back as a heuristic decision by the heuristic decision mechanism 31. The data consistency check mechanisms 33 and 34 A heuristic report is provided, and the original child transaction itself is input as a re-execution transaction by the transaction re-execution mechanism 23. Is rolled back, and the child transaction is re-entered later as a local transaction as needed to restore the consistency between the computers 1 and 2. Therefore, the consistency between the two sites can be maintained in any case after the system crash.

In the present embodiment, among the cases where transaction processing is performed in a distributed system composed of a plurality of computers 1 and 2, especially when the following (1), (2) and (3) are met, the computer 1 , By providing a means for restoring data consistency after recovery from a failure while preventing the system from being locked by exclusive control when a failure occurs between two, increasing system availability and simplifying operation, The reliability of the system can be improved. (1) Child transaction 21 (activated side) becomes coordinator after two-phase commit. (2)
It is preferable to commit a transaction whose result is in-doubt as a heuristic decision. (3) A heuristic report is provided as the data consistency check mechanisms 33 and 34.

In the distributed transaction processing system according to the fourth embodiment, the data consistency checking mechanism used in the fourth embodiment may be replaced with the data consistency checking mechanism used in the second embodiment. Good. Other configurations are the same as those of the fourth embodiment. Also in this configuration, the same effect as in the fourth embodiment can be obtained in a system that does not include a heuristic report.

Embodiment 5 This embodiment is the same as the fourth embodiment in that the business content, the database configuration, and the heuristic determination are rollbacks. 22 is an example.

FIG. 21 is a block diagram showing a configuration of a distributed transaction processing system according to the fourth embodiment of the present invention. 21, the same reference numerals as those in FIG. 15 indicate the same or corresponding parts. In the fourth embodiment, the transaction re-execution mechanism 23 and the heuristic determination mechanism 31
And the recovery candidate transaction extraction mechanism 32 to the site B
In this embodiment, the transaction re-execution mechanism 23, the heuristic determination mechanism 31, and the recovery candidate transaction extraction mechanism 32 are provided in the computer 1 on the site A side. ing.

In the distributed transaction processing system according to the present embodiment, the transaction 22 of the site B, which is started by the transaction 21 of the site A, becomes a coordinator after two-phase commit, and the heuristic determination mechanism 31 A rollback is performed as a decision, and a heuristic report is provided as the data consistency check mechanism 33. By inputting the transaction 21 itself of the site A as a re-execution transaction by the transaction re-execution mechanism 23, After the failure between the two has occurred, the transaction in the prepared state is temporarily rolled back, and the transaction 21 of the site A is re-entered as a local transaction if necessary. A system for restoring the integrity between calculation machines 1 and 2.

Next, FIG. 22 is a flowchart showing a transaction processing flow on the distributed transaction processing system shown in FIG. Unlike FIG. 16 of the fourth embodiment, the coordinator is the activated RPC. Here, the processing contents of a transaction for updating the databases 3 and 4 synchronously at the two sites A and B using RPC are shown. When receiving the order information input from the terminal 9 (step S111), the transaction 21 on the site A performs the same numbering as in the first embodiment and collects the order number by the numbering (step S11).
2) The order information is inserted into the order database 3 on the site A using the collected order number as a key (step S).
113).

The transaction 21 on the site A side receives the order number (Ke) inserted in the order database 3 of the site A.
y) and the order information (Data) as arguments, perform RPC to the transaction 22 of the site B (step S11).
4). Transaction 22 on site B is site A
The order information is inserted into the order database 4 on the site B side using the same order number as that on the site A side transferred from the transaction 21 on the side as a key (step S115), and control is returned to the transaction 21 on the site A side that is the calling source (step S115). Step S116).

As described above, the transaction 21 on the site A updates the numbered order number and the order information, and transmits the updated order number and the order information to the transaction 22 on the site B side. . The transaction 22 on the site B updates with the order number and the order information transmitted from the transaction 21. After the RPC ends, the transaction 21 on the site A transmits transaction end information to the transaction 22 on the site B side (step S117).

When the transaction 22 on the site B side serving as the coordinator receives the transaction end information transmitted from the transaction 21 (step S)
118), sends the prepare request information to the transaction A on the site A side (step S119). When the prepare request information transmitted from the transaction 22 is received, the transaction 21 on the site A performs the prepare and performs the prepare on the site B side. The prepare completion information is transmitted to the transaction 22 (step S120).

When the transaction 22 on the site B receives the prepare completion information transmitted from the transaction 21, it commits and transmits the commit request information to the transaction 21 on the site A (step S).
119). Upon receiving the commit request information transmitted from the transaction 22, the transaction 21 on the site A commits (step S120), and transmits the result to the terminal 9 (step S121).

Next, FIG. 23 is a sequence diagram showing a state where the data consistency between the sites A and B of the distributed transaction processing system shown in FIG. 21 is maintained by being committed to both the sites A and B. . Up to the point where the transaction 21 of the site A performs the RPC on the procedure p23 of the site B, it is the same as the fourth embodiment. Thereafter, the transaction 22 of the site B returns control to the transaction 21 of the calling site A with the end of the RPC process, and thereafter, the transaction 2 of the site A
When the transaction completion information transmitted from the transaction A 1 is received, the prepare request information is
Send to 1.

The transaction A of the site A returns a ready notification to the transaction 22 of the site B. The transaction 22 of the site B immediately executes the local commit and immediately returns the site B to the transaction 21 of the site A before returning the commit instruction to the transaction 21 of the site A. Computer 2 of the system
Suppose you crash.

Since the transaction A on the site A does not receive a commit instruction from the transaction 22 on the site B, the heuristic determination mechanism 31 rolls back the transaction B after waiting for the commit instruction on the site B to time out. The transaction 21 at the site A is held as a recovery candidate by the recovery candidate transaction extraction mechanism 32.

On the other hand, at the site B, after the cause of the failure is resolved, the system is restarted. Thereafter, after the communication path between the site A and the site B is restored, the status of the transaction 21 of the site A is confirmed by the consistency confirmation mechanisms 33 and 34 of the sites A and B based on the heuristic report. In this case, as described above, since the transaction 22 at the site B has been committed but has been rolled back at the site A, an inconsistency has occurred.
Is executed. At this time, as shown in the flow of FIG. 24 described later, the transaction 21 of the site A is executed as a local transaction. According to the above procedure, in the present embodiment, consistency between the two sites A and B can be maintained even after the system crash.

FIG. 24 is a flow chart showing the transaction re-execution processing flow of site A in the distributed transaction processing system shown in FIG. When receiving the order information transmitted from the terminal 9 (step S131), the transaction 21 of the site A performs numbering based on the order information (step S132), and uses the numbered order information as a key for the site A. (Step S133).

The transaction 21 of the site A performs RPC to the transaction 22 of the site B using the numbered order number and the order information as arguments. At this time, the call from the site A to the site B is NOP, and the result of the RPC is input from the log. Thereafter, the transaction 21 of the site A transmits transaction end information to the transaction 21 of the site A (step S13).
5) After committing as a local transaction (step S136), the result transmission to terminal 9 is NO
Set to P (step S137).

As described above, in the present embodiment, among the cases where transaction processing is performed in a distributed system including a plurality of computers 1 and 2, the following (1), (2),
In the case of (3), by providing a means for recovering data consistency after recovery from a failure while preventing the system from being locked by exclusive control when a failure occurs between the computers 1 and 2, The reliability of the system can be increased while increasing the availability of the system and simplifying the operation. (1) The child transaction 22 of the site B started by the parent transaction 21 of the site A has two phases.
(2) It is preferable to roll back a transaction with an unknown result (in-doubt) as a heuristic decision. Have.

In the distributed transaction processing system according to the fifth embodiment, the data consistency checking mechanism used in the fifth embodiment may be changed to the data consistency checking mechanism used in the second embodiment. Good. Other configurations are the same as those of the fifth embodiment. Also in the case of this configuration, the same effect as in the fifth embodiment can be obtained in a system without a heuristic report.

Embodiment 6 FIG. In the present embodiment, the business content and the database configuration are the same as those in the above-described fourth embodiment, but the transaction in the prepared state at the time of the occurrence of the failure is committed for the time being by the heuristic decision, contrary to the fourth embodiment. It is an example. FIG. 25 is a block diagram showing a configuration of the distributed transaction processing system according to the sixth embodiment of the present invention. 25, the same reference numerals as those in FIGS. 15 and 21 indicate the same or corresponding parts. In the present embodiment, the input instruction information is added to the site B side in addition to the configuration of the fourth embodiment.

In the distributed transaction processing system according to the present embodiment, the transaction 21 of the site A, which particularly activates the transaction 22 of the site B, becomes a coordinator after two-phase commit, and the heuristic decision mechanism 31 And a data integrity check mechanism 3
3 and 34, a heuristic report is provided, and the same transaction re-executing mechanism 23 as that of the third embodiment is provided. By inputting a recovery transaction corresponding to the transaction 22 of the original site B, the computer 1, A system in which a transaction in a prepared state is temporarily committed after the occurrence of a failure between two computers, and a recovery transaction is later re-submitted as a local transaction as needed to restore consistency between the computers 1 and 2 It is. The transaction processing flow on the distributed transaction processing system of the present embodiment is the same as that of the fourth embodiment shown in FIG. In the present embodiment, a cancel transaction q27 shown in FIG. 27 is further provided. In addition to the configuration of the fourth embodiment, the input instruction information shown in FIG. 27 is used.

FIG. 26 is a flowchart showing a cancellation procedure flow of the distributed transaction processing system shown in FIG. Transaction B at site B is K
After deleting the record of the order database 4 using ey as a key (step S141), commit is performed (step S142). The input instruction information includes, as shown in FIG.
The original transaction name (RPC name), the input transaction name / RPC name (parameter), and the corresponding information of the parameter are written.

Next, FIG. 28 is a sequence diagram showing how the data consistency between site A and site B of the distributed transaction processing system shown in FIG. 25 is maintained. Here, a case where both sites A and B are rolled back will be described. Transaction 21 of site A RPCs procedure p18 of site B, and then prepares
Up to the point where the log is collected, the same as in the fourth embodiment. Immediately thereafter, as shown in FIG. 28, the transaction 22 of the site B sends a ready (ready) notification to the site A.
It is assumed that the computer 2 at the site B has a system crash before the transaction 2 is transmitted to the transaction 21. Site A
Transaction 21 is rolled back in the same manner as in the fourth embodiment.

On the other hand, at the site B, after the cause of the failure is resolved, the system is restarted. In this example, it is assumed that the transaction in the prepared state at the time of occurrence of the failure is committed by the heuristic determination mechanism 31, contrary to the fourth embodiment. First, as in the fourth embodiment, the recovery log of the procedure p1 is extracted by the recovery candidate transaction extraction mechanism 32.

Next, after the communication path with the site A is restored,
After obtaining the heuristic report, the transaction reexecutor 23 checks the status of the parent transaction of GTID = i. In this case, as described above, although the parent transaction 21 of the site A has been rolled back, it has been committed at the site B, which is inconsistent. As shown in FIG. 27, the JB input instruction information includes a cancel transaction q27 and a cancel transaction q27 for the RPC name of p18.
Is defined with the parameter of p18 of the RPC name. Thus, the transaction re-executing mechanism 23 inputs the cancel transaction q27. Cancel transaction q27 is RP
The process performed by p18 is canceled using the parameter of the C name p18. In this case, the record with the key “0101” is deleted. Now both sites A and B have key '01
Since there is no record of 01 ', data consistency is maintained.

If a system crash occurs after the commit of the transaction 22 of the site A serving as the coordinator, the consistency check shows that the consistency of the two sites A and B has not been lost. The input of q27 is not performed. According to the above procedure, in the present embodiment, consistency between both sites can be maintained even after a system crash.

As described above, in the present embodiment, the following (1), (2),
In the case of (3), by providing a means for recovering data consistency after recovery from a failure while preventing the system from being locked by exclusive control when a failure occurs between the computers 1 and 2, The reliability of the system can be increased while increasing the availability of the system and simplifying the operation. (1) The transaction 21 of the site A, which activates the transaction 22 of the site B, becomes the coordinator even after the two-phase commit. It is better to do,
(3) Heuristic reports are provided as the data consistency check mechanisms 33 and 34.

In the distributed transaction processing system according to the sixth embodiment, the data consistency checking mechanism used in the sixth embodiment may be replaced with the data consistency checking mechanism used in the second embodiment. Good. Other configurations are the same as in the sixth embodiment. In this example, the definition of the determination for checking the consistency and the definition of the transaction for recovery can be integrated as shown in FIG. Also in this configuration, the same effect as in the sixth embodiment can be obtained in a system that does not include a heuristic report.

Embodiment 7 FIG. In the present embodiment, the business content and the database configuration are the same as those of the above-described fifth embodiment. It is an example. The configuration of the distributed transaction processing system according to the present embodiment is the same as the configuration shown in FIG. 25 of the fifth embodiment.

In the distributed transaction processing system according to the present embodiment, in particular, the transaction 22 of the site B, which is activated by the transaction 21 of the site A, has two transactions.
The coordinator becomes a coordinator after the phase commit, and performs a commit as a heuristic decision by the heuristic decision mechanism 31. By providing a recovery transaction corresponding to the transaction 21 of the original site A by providing the same as that of the mode 3, after a failure between the computers 1 and 2 occurs, the transaction in the prepared state is temporarily committed,
Later, a recovery transaction can be
This is a system for re-inputting as a transaction and restoring consistency between the computers 1 and 2. The transaction processing flow on the distributed transaction processing system of the present embodiment is the same as that of the fifth embodiment shown in FIG. In the present embodiment, the recovery transaction UA used for the transaction 21 of the site A shown in FIG.
30 are provided. In addition to the configuration of the fourth embodiment, the input instruction information shown in FIG. 31 is used.

FIG. 30 is a flowchart showing a processing flow of the recovery transaction UA30 used for the transaction of the site A in the distributed transaction processing system of the present embodiment. Upon receiving the order information transmitted from the terminal 9 (step S151), the transaction 21 of the site A deletes the record of the order database 3 using the key of the order number as a key (step S152), and then performs a local commit (step S152). S1
53). As shown in FIG. 31, the input instruction information describes the correspondence between the original transaction name (RPC name), the input transaction name / RPC name (parameter), and the start information.

In the present embodiment, similar to the sixth embodiment,
When it is determined that the consistency is lost by the transaction 21 of the site A, the transaction re-executing mechanism 23
Inputs the recovery transaction UA30 corresponding to the transaction 21 with reference to the input instruction information of FIG. The recovery transaction UA30 operates as a local transaction to cancel the processing performed by the transaction 21 of the site A, as shown in FIG. Thereby, in the present embodiment, data consistency between both sites A and B can be maintained.

As described above, in the present embodiment, the following (1), (2),
In the case of (3), by providing means for restoring data consistency after restoration of a failure while preventing the system from being locked by exclusive control when a failure occurs between the computers 1 and 2 System reliability while improving availability and simplifying operation. (1) The site B transaction 22 activated by the site A transaction 22 becomes a coordinator after a two-phase commit. Is preferred,
(3) Heuristic reports are provided as the data consistency check mechanisms 33 and 34. In the distributed transaction processing system according to the seventh embodiment, the data consistency checking mechanism used in the seventh embodiment may be changed to the data consistency checking mechanism used in the second embodiment. Other configurations are the same as those in the seventh embodiment. Also in the case of this configuration, the same effect as in the seventh embodiment can be obtained in a system without a heuristic report.

[0121]

[Brief description of the drawings]

FIG. 1 is a flowchart showing a transaction processing flow of a numbering mechanism according to the first embodiment of the present invention.

FIG. 2 is a flowchart illustrating a processing flow of a numbering mechanism according to the first embodiment of the present invention.

FIG. 3 is a flowchart showing a numbering recovery process flow of the numbering mechanism according to the first embodiment of the present invention.

FIG. 4 is a block diagram illustrating a configuration of a distributed transaction processing system according to a second embodiment of the present invention.

5 is a flowchart showing a transaction processing flow of the distributed transaction processing system shown in FIG.

FIG. 6 is a sequence diagram showing a state where data consistency between sites A and B of the distributed transaction processing system shown in FIG. 4 is confirmed.

FIG. 7 is a sequence diagram showing how data consistency between site A and site B of the distributed transaction processing system shown in FIG. 4 is confirmed.

8 is a diagram showing the contents of a log collected by the distributed transaction processing system shown in FIG.

FIG. 9 is a diagram showing consistency judgment definition information used by the consistency confirmation mechanism of the distributed transaction processing system shown in FIG. 4 to identify the location of information to be matched;

FIG. 10 is a flowchart showing a processing flow of a consistency checking mechanism of the distributed transaction processing system shown in FIG. 4;

FIG. 11 is a block diagram illustrating a configuration of a distributed transaction processing system according to a third embodiment of the present invention during normal execution.

FIG. 12 is a block diagram showing a configuration at the time of re-execution of a distributed transaction processing system according to a third embodiment of the present invention.

13 is a flowchart showing a processing flow at the time of normal execution of a transaction at sites A and B in the distributed transaction processing system shown in FIG. 11;

14 is a flowchart showing a local re-execution processing flow at site A of the distributed transaction processing system shown in FIG.

FIG. 15 is a block diagram illustrating a configuration of a distributed transaction processing system according to a fourth embodiment of the present invention.

16 is a flowchart showing a transaction processing flow on the distributed transaction processing system shown in FIG.

FIG. 17 is a sequence diagram showing communication and database change caused by the distributed transaction processing system shown in FIG. 15;

FIG. 18 is a sequence diagram showing communication and database changes caused by the distributed transaction processing system shown in FIG. 15;

19 is a diagram showing contents of a prepare log collected by the distributed transaction processing system shown in FIG.

FIG. 20 is a flowchart showing a processing flow of confirmation of consistency and re-input shown in FIGS.

FIG. 21 is a block diagram illustrating a configuration of a distributed transaction processing system according to a fourth embodiment of the present invention.

FIG. 22 is a flowchart showing a transaction processing flow on the distributed transaction processing system shown in FIG. 21.

23 is a sequence diagram showing a state where data consistency of sites A and B of the distributed transaction processing system shown in FIG. 21 is committed and maintained at both sites.

24 is a flowchart showing a transaction re-execution processing flow of site A in the distributed transaction processing system shown in FIG. 21.

FIG. 25 is a block diagram illustrating a configuration of a distributed transaction processing system according to a sixth embodiment of the present invention.

26 is a flowchart showing a cancellation procedure flow of the distributed transaction processing system shown in FIG. 25.

FIG. 27 is a diagram showing input instruction information used in the distributed transaction processing system shown in FIG.

FIG. 28 is a sequence diagram showing a state where data consistency of both sites A and B of the distributed transaction processing system shown in FIG. 25 is maintained.

FIG. 29 is a diagram showing the contents of the input instruction information merged with the consistency determination definition.

FIG. 30 is a flowchart showing a processing flow of a recovery transaction used for a transaction at the site A in the distributed transaction processing system according to the seventh embodiment of the present invention.

FIG. 31 is a diagram showing contents of input instruction information used in the distributed transaction processing system according to the seventh embodiment of the present invention.

FIG. 32 is a block diagram showing a configuration of a conventional distributed transaction processing system.

FIG. 33 is a flowchart showing a transaction processing flow of site A on the distributed transaction processing system shown in FIG. 32;

FIG. 34 is a diagram illustrating a state where data inconsistency between site A and site B is detected by the distributed transaction processing system illustrated in FIG. 32;

FIG. 35 is a diagram illustrating a state in which consistency cannot be detected when a user's serial number itself is rolled back by a conventional method.

[Explanation of symbols]

1,2 calculator, 3,4 order database, 5,6
Log collection mechanism, 7 numbering mechanism, 8 applications,
9 terminal, 10, 11 order record, 21, 22 transaction, 23 transaction re-executing mechanism,
24, 25 management terminal, 26 printer, 31 heuristic determination mechanism, 32 recovery candidate transaction extraction mechanism, 33, 34 data consistency check mechanism.

──────────────────────────────────────────────────続 き Continued on the front page (58) Field surveyed (Int.Cl. ⁷ , DB name) G06F 12/00 G06F 15/16-15/177

Claims (11)

(57) [Claims] Claims 1. A sequence number is stored in a memory and a file.
The sequence number in the memory is counted up by calling a numbering instruction from the business program and returned to the business program, and the latest sequence number is stored in a nonvolatile medium at least once every N times given by the default value or the definition in the entire computer. The numbering program interface mechanism that writes to the above file, is not returned by transaction rollback, and is not locked until committing after numbering, and the file after a system failure that loses memory information A numbering recovery mechanism for restoring the remaining sequence numbers + N or more so that even if a failure occurs, the business program resumes numbering from a sequence number larger than the last sequence number returned last. Numbering mechanism characterized by the following. 2. In the distributed transaction processing, a database for writing a record using a serial number as a key by the numbering mechanism according to claim 1 provided in a distributed node of a transaction serving as a coordinator, and a database provided in a distributed node serving as a subordinate. A log collection mechanism that writes the serial number to the log at the same time as the prepare log at the latest, a consistency decision definition that specifies the location and decision method of data to be matched when checking data consistency, and data inconsistency due to heuristic determination at the time of failure To the in-doubt prepare
For transactions that have logs but have not been committed / rolled back under the direction of the coordinator,
A data inconsistency detection mechanism for detecting whether there is a record corresponding to a serial number in the log by matching the records in accordance with the consistency determination definition information. 3. A program, which is one distributed node of the distributed transaction processing, is executed during normal execution while receiving processing and numbering processing according to claim 1 are collected in a recovery log. At re-execution, the program or the program is executed. The corresponding recovery program is re-entered as a local transaction with the original transaction ID, the communication processing other than the reception processing of the program is turned to NOP, and the reception processing and the numbering processing according to claim 1 are executed in a log during normal execution. A transaction re-executing mechanism, characterized by having a program interface mechanism for writing the data to a local transaction based on the transaction ID and reproducing the read transaction from a log based on the transaction ID. A parent transaction which starts a child transaction becomes a coordinator on a two-phase commit, and rolls back as a heuristic decision in b). In this case, a heuristic report is provided as a data consistency checking mechanism in e), and the original child transaction itself is input as a re-executed transaction by the transaction re-executing mechanism in f). A distributed transaction processing system wherein a transaction in a prepared state is temporarily rolled back after occurrence, and a child transaction is re-entered as a local transaction later as needed to restore consistency between computers. a) a log collection mechanism; b) a heuristic decision mechanism for committing / rolling back a transaction waiting for a commit / rollback decision from the partner transaction in the event of a failure by local heuristic decision; A recovery candidate transaction extraction mechanism for extracting a transaction without a log and a rollback log as a recovery candidate; d) when a transaction becomes a recovery candidate,
Injection instruction information indicating which transaction should be injected. E) Confirming, after recovery from the failure, whether data consistency between the transaction committed / rolled back by the heuristic decision and the partner transaction has not been lost. The data reconciliation mechanism according to claim 3, wherein: 5. The method according to claim 4, wherein the child transaction becomes a coordinator on a two-phase commit, and rolls back as a heuristic decision in b). A heuristic report is provided as a data consistency check mechanism of f), and the original parent transaction itself is input as a re-execution transaction by the transaction re-execution mechanism f) to temporarily A distributed transaction processing system wherein a transaction in a prepared state is rolled back, and a parent transaction is later re-entered as a local transaction as needed to restore consistency between computers. 6. A parent transaction which activates a child transaction becomes a coordinator on a two-phase commit and comprises a commit as a heuristic decision in b). A heuristic report is provided as a data consistency checking mechanism of e), and a claim 3 is provided as a transaction re-execution mechanism of f), and a recovery transaction corresponding to the original child transaction is input. In this method, a transaction in a prepared state is temporarily committed after the occurrence of a failure between computers, and the recovery transaction is re-entered as a local transaction as needed to restore consistency between computers. Distributed transaction processing system. 7. The method according to claim 4, wherein the child transaction becomes a coordinator on a two-phase commit and performs a commit as a heuristic decision in b). A heuristic report is provided as a data consistency checking mechanism. Claim 3 is provided as a transaction re-executing mechanism of f), and by inputting a recovery transaction corresponding to the original parent transaction, a failure between computers can be prevented. A distributed transaction processing system wherein a transaction in a prepared state is temporarily committed after occurrence, and a recovery transaction is re-entered as a local transaction later as needed to restore consistency between computers. 8. The distributed transaction processing system according to claim 4, wherein the data consistency checker is obtained by changing the data consistency checker of claim 4) to the data consistency checker of claim 2. A distributed transaction processing system. 9. The distributed transaction processing system according to claim 5, wherein the data consistency checker is obtained by changing the data consistency checker of claim 5) to the data consistency checker of claim 2. A distributed transaction processing system. 10. The distributed transaction processing system according to claim 6, wherein the data consistency check mechanism is provided.
3. The distributed transaction processing system according to claim 1, wherein the data consistency check mechanism of e) is changed to the data consistency check mechanism of claim 2. 11. The distributed transaction processing system according to claim 7, wherein the data consistency check mechanism is provided.
3. The distributed transaction processing system according to claim 2, wherein the data consistency check mechanism of e) is changed to the data consistency check mechanism of claim 2.