JP2002366407A - Data base replication system and data base automatic recovery method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a data base replication system capable of instantaneously detecting the occurrence of the mismatching of a master data base and a replica data base, and re-transferring only the mismatching data, and quickly executing the re-synchronizing processing of the master data base and the replica data base even when the abnormal end of transaction or system-down is generated. SOLUTION: In this data base replication system, a data base management system is provided with a transaction abandoning means for abandoning a transaction, and a replication control system is provided with a transaction sequence monitoring means for detecting the abnormal end of transaction, and a replication client system is provided with an update history re-transmitting means for reading the mismatching data of a master data base and a replica data base from the master data base, and for setting a correct value in the replica data base.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a database replication system and a database automatic recovery method.

[0002]

2. Description of the Related Art Conventionally, a database replication control that creates a replica of a master database held by one information processing apparatus as a replica database in another information processing apparatus and maintains consistency between the master database and the replica database. Systems are known. As such a conventional database replication control system, for example, JP-A-2000-203
No. 66, JP-A-2000-20374, JP-A-2
000-47918, JP-A-2001-34527
And Japanese Patent Application Laid-Open No. 9-54718.

In a conventional database replication control system, a transaction may be abnormally terminated during execution of a database update, or may be abnormally terminated due to a system crash during the execution of a database update. At the time of such abnormal termination, the replication control system
It was not always possible to guarantee the consistency between the master database and the replica database. Therefore, when inconsistency between the master database and the replica database occurs due to abnormal termination as described above, all data is transferred from the master database to the replica database in a batch by presenting online business processing, and then brought into a consistent state. It was necessary to resume online operations.

[0004] Therefore, in order for replication to operate normally, the contents of the master database and the replica database must be the same. For this purpose, the replication and database update operations are temporarily stopped, and the master database is transferred from the replica database to the replica database. It is necessary to carry out batch transfer of all data.

Therefore, even when a transaction ends abnormally or when the system goes down, the inconsistency between the master database and the replica database can be instantaneously generated without stopping the database reference / update operation or stopping the replication. There has been a demand for a database replication system and a database automatic recovery method capable of detecting and retransferring only inconsistent data and performing high-speed resynchronization processing between a master database and a replica database.

[0006]

SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to provide a method for instantaneously stopping database referencing / updating work and stopping replication even when a transaction ends abnormally or when a system goes down. Provide a database replication system and a database automatic recovery method capable of detecting occurrence of inconsistency between a master database and a replica database, retransferring only inconsistent data, and performing resynchronization processing between the master database and the replica database at high speed. Is to do.

[0007]

According to a first aspect of the present invention, there is provided a database replication system comprising a replication server system having a master database and a replication client system having a replica database. The server system has a database management system and a replication control system,
The database management system has transaction abandonment means for abandoning a transaction, the replication control system has a transaction sequence monitoring means for detecting abnormal termination of a transaction, and the replication client system has the master database and the replica database. Read inconsistent data from the master database,
A database replication system comprising update history resending means for setting a correct value in a replica database.

With this configuration, when a transaction is abnormally terminated due to forced termination or the like, the transaction sequence monitoring means detects abnormal termination of the transaction, the transaction discarding means discards the transaction, and the update history resending means transmits the master database to the master database. Inconsistent data between the master database and the replica database is read from the master database, and a correct value is set in the replica database, so that if the transaction ends abnormally, the master database and the replica database can be matched. Therefore, according to the database replication system of the present invention, even when a transaction ends abnormally or the system goes down, database replication can be performed without stopping database reference / update operations or stopping replication. It is possible.

The invention described in claim 2 of the present application is
2. The data replication system according to claim 1, wherein the replication control system includes a system down processing unit that detects data inconsistency when a system down occurs. With this configuration, even when a system failure occurs, inconsistency is automatically detected, and it is possible to match the master database and the replica database.

The invention described in claim 3 of the present application is
A method for automatically recovering a database using a database replication system including a replication system having a master database, a database management system, a replication control system, and a replication client system having a replica database, the transaction sequence monitoring of the replication control system Means for detecting abnormal termination of the transaction, steps for discarding the transaction by the transaction discarding means of the database management system, and means for updating the update history of the replication client system for inconsistency between the master database and the replica database. Reads data from the master database and A database automatic recovery method characterized by comprising the step of setting the correct value Rica database.

With this configuration, when a transaction is abnormally terminated due to forced termination or the like, the transaction sequence monitoring means detects the abnormal termination of the transaction, the transaction discarding means discards the transaction, and the update history resending means transmits the master database to the master database. Reads inconsistent data between the master database and the replica database from the master database, and sets the correct value in the replica database. This provides an automatic database recovery method that can match the master database and the replica database if a transaction ends abnormally. . Therefore, according to the automatic database recovery method of the present invention, even when a transaction ends abnormally or the system goes down, it is possible to execute database replication without stopping database reference / update operations or stopping replication. Is possible.

Further, the invention described in claim 4 of the present application is
4. The automatic database recovery method according to claim 3, wherein the system down processing means of the replication control system has a step of detecting data inconsistency when a system down occurs. With such a configuration, the automatic database recovery method of the present invention is a method that can automatically detect inconsistency even when a system failure occurs and make the master database and the replica database consistent.

[0013] The invention described in claim 5 of the present application provides:
A method for automatically recovering a database using a database replication system including a replication system having a master database, a database management system, a replication control system, and a replication client system having a replica database, the transaction sequence monitoring of the replication control system Means for detecting abnormal termination of the transaction, steps for discarding the transaction by the transaction discarding means of the database management system, and means for updating the update history of the replication client system for inconsistency between the master database and the replica database. Reads data from the master database and Is a program for executing the automatic database recovery method in a computer characterized in that it comprises the step of setting the correct value Rica database.

With this configuration, when a transaction is abnormally terminated due to forced termination or the like, the transaction sequence monitoring means detects the abnormal termination of the transaction, the transaction discarding means discards the transaction, and the update history resending means transmits the master database to the master database. Inconsistent data between the master database and the replica database is read from the master database and the correct value is set in the replica database. Therefore, if the transaction ends abnormally, a database automatic recovery method that can match the master database and the replica database is executed. can do.

Further, the invention described in claim 6 of the present application is
6. A program for causing a computer to execute the database automatic recovery method according to claim 5, further comprising a step of detecting a data inconsistency when a system failure occurs in the replication control system when the system failure occurs. I do. With such a configuration, it is possible to execute a database automatic recovery method that can automatically detect inconsistency even when a system failure occurs and make the master database and the replica database consistent.

[0016]

DESCRIPTION OF THE PREFERRED EMBODIMENTS First, a database replication system according to the present invention will be described. The database replication system of the present invention includes a replication server system having a master database and a replication client system having a replica database, and the replication server system has a database management system and a replication control system. Further, the database management system has a transaction discarding unit for discarding the transaction, and the replication control system has a transaction sequence monitoring unit for detecting abnormal termination of the transaction.

Further, the replication client system has a replication control system, and the replication control system has update history resending means, and the update history resending means masters inconsistent data between the master database and the replica database. It has means for reading from the database and setting correct values in the replica database.

An embodiment of the database replication system of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing the configuration of the database replication system of the present invention. As shown in FIG. 1, the database replication system of the present invention includes a replication server system 101 and a replication client system 401.

Replication server system 101
Has a database management system 201 (hereinafter, also referred to as "DBMS" in the present specification), a replication control system 301, a master database 207, an update journal 208, and an update history extraction file 306. In addition, the replication client system 4
01 has a replication control system 402 and a replica database 405.

The DBMS 201 includes a database reference processing unit 202, a database update processing unit 203, a transaction determination unit 204, an update journal processing unit 205, and a transaction discarding unit 206, and the replication control system 301 It has means 302, transaction sequence monitoring means 303, update history transmitting means 304, and system down processing means 305.

The replication control system 403 of the replication client system 401 includes an update history reception / reflection unit 403 and an update history retransmission unit 405.

In the database replication system 101 of the present invention, the transaction discarding means 206 has a function of discarding a transaction, and the transaction sequence monitoring means 303
Has a function of detecting abnormal termination of a transaction. Further, the update history resending means 404 is configured to transmit the master database 207 and the replica database 4
05 is read from the master database 207 and a function of setting a correct value to the replica database 405 is provided.

Further, in the database replication system 101 of the present invention, the replication control system 301 has a system down processing means 305, and the system down processing means 305 does not transfer data when a system down occurs. It has the function of detecting matching.

The flow of operation in the update history extracting means 302 will be described with reference to the drawings. FIG. 2 is a diagram showing a flow of the operation in the update history extracting means 302. As shown in FIG. 2, the update history extracting unit 302
It has a function of determining the value of UTPUT. OUTP
If UT = DATA is specified (step 50
1) In step 502, database update history information is generated from the contents of the database update performed immediately before.

If OUTPUT = COMMIT1 is specified (step 503), COMMIT1 information is generated in step 504, and OUTPUT = C
If OMMIT2 is specified (step 505),
In step 506, COMMIT2 information is generated,
If OUTPUT = ROLLBACK is specified (step 507), ROLLB is set in step 508.
Generate ACK information. OUTPUT = CHECK
If K is designated (step 509), step 5
At 10, CHECK information is generated. Each information generated in the above steps 502, 504, 506, 508 and 510 is written in the update history extraction file in step 511.

Next, an operation flow in the transaction sequence monitoring means 303 will be described with reference to the drawings. FIG. 3 is a diagram showing a flow of operation in the transaction sequence monitoring means 303. As shown in FIG. 3, the transaction sequence monitoring means 303
Has the function of determining the value of the argument OUTPUT and setting the value of the global variable SEQ.

If OUTPUT = DATA is specified (step 601), the program proceeds to step 602 where SEQ
= 0 and the flow branches to step 611. OUTPUT = C
If OMMIT1 is specified (step 603),
At step 604, SEQ = 1 is set and step 611 is set.
Branch to If OUTPUT = COMMIT2 is specified (step 605), SEQ = 2 in step 606, and the flow branches to step 611.

If OUTPUT = ROLLBACK is specified (step 607), step 608 is executed.
In step 609, the value set in the past as a global variable SEQ is determined. If SEQ = 1, SEQ = −1 is set in step 609, and if SEQ = 1 is not set, step 61 is performed.
At 0, SEQ = 3, and the process branches to step 611. In step 611, the value of the global variable SEQ is determined, and if the value is not equal to −1, the process ends. On the other hand, if SEQ = −1, OUTPUT = CHECK is set in step 612, the update history extracting unit 302 is called, SEQ = 0 is set in step 613, and the process ends.

Next, the operation flow of the update history reception / reflection means 403 will be described with reference to the drawings. FIG.
FIG. 8 is a diagram showing a flow of operation in the update history reception / reflection unit 403. As shown in FIG. 4, the update history reception / reflection unit 403 has a function of determining the type of the update history and setting a variable STAT.

As shown in FIG. 4, in step 701, the update history reception / reflection means 403 sets the variable STAT in advance.
Is set to 0. Next, in step 702, one update history is read, and then the type of the update history is determined. If it is COMMIT1 information (step 703)
Sets STAT = 1 in step 704 and branches to step 712. If the information is COMMIT2 information (step 705), STAT =
It is set to 2 and it branches to step 712. Also, ROLLBA
If it is CK information (step 708), step 7
At 08, STAT = 3 is set and the flow branches to step 712.

If it is CHECK information (step 709), the previous STAT
Is determined, and if STAT = 1 is not set, step 712 is executed.
And STAT = 1 (step 711)
Sets STAT = -1 and branches to step 712.

Next, the value of STAT is determined, and STAT is determined.
= 2 (Step 712), Step 713
At 701, the transaction is reflected in the replica DB, and the process branches to step 701. If STAT = 3 (step 714), the transaction is discarded in step 715, and the flow branches to step 701. Also,
If STAT = −1 (step 716), the update history retransmitting unit 404 is called, and in step 717, the transaction is reflected in the replica DB, and
Branch to 01. On the other hand, if the STAT has any other value, it is determined that the transaction is in the middle of a transaction, and the flow branches to step 702.

Next, the operation of executing a database update instruction will be described. FIG. 5 is a diagram showing a flow of the operation of executing the database update instruction. As shown in FIG. 5, when executing a database update instruction (step 801), the database update processing means 203 is called. The database update processing unit 203 updates the master database (step 802), determines the existence of the replica database, and ends the process if the replica database does not exist. On the other hand, if a replica database exists (step 804), the argument OU
TPUT = DATA is set (step 804), the update history extraction unit 302 and the transaction sequence monitoring unit 303 are called, and the process ends.

Next, the operation of executing the COMMIT instruction will be described. FIG. 6 is a diagram showing a flow of the operation of the COMMIT instruction execution. As shown in FIG. 6, when the COMMIT instruction is executed (step 901), the transaction determination means 204 and the update journal processing means 205 of the DBMS 201 are called.

In the transaction determination means 204, in step 902, the COMMI
T processing is performed, and in step 903, the replica D
The presence of B is determined, and if the replica DB does not exist, the process ends. On the other hand, if a replica database exists (step 904), the argument OUTPUT = CO
MMIT1 is set (step 904), the update history extraction unit 302 and the transaction sequence monitoring unit 303 are called, and the process ends.

In the update journal processing means 205, in step 905, the COM
MIT processing is performed, and the existence of a replica DB is determined in step 906. If there is no replica DB, the processing ends. On the other hand, if a replica database exists (step 904), the argument OUTPUT =
COMMIT2 is set, the update history extraction unit 302 and the transaction sequence monitoring unit 303 are called, and the process ends.

Next, the operation of executing the ROLLBACK instruction will be described. FIG. 7 is a diagram showing a flow of the operation of executing the ROLLBACK instruction. As shown in FIG.
When the LBACK instruction is executed (step 1001), the transaction discarding means 206 is called.

In the transaction discarding means 206, ROLLBACK processing is performed in step 1002, and the existence of a replica database is determined in step 1003. If there is no replica database, the processing ends. On the other hand, if a replica database exists (step 1004), the argument OUT
PUT = ROLLBACK is set, and the update history extracting unit 302 and the transaction sequence monitoring unit 30
3 is called, and the process ends.

Next, the operation at the time of system down processing will be described. FIG. 8 is a diagram showing a flow of operation when the system goes down. As shown in FIG. 8, the system down processing means 305 determines in step 1101 whether a system down has occurred before the system is activated, and terminates the processing if no system down has occurred. On the other hand, if a system down has occurred, the argument OUTPUT = CHECK is set in step 1102, the update history extracting means 302 is called, and the process ends.

Next, an example of a transaction will be described. FIG. 9 shows an example 1201 of a certain transaction.
FIG. 6 is a diagram illustrating a process performed by the database management system 201. Reference numeral 1202 shown in FIG. 9 denotes an SQL that refers to the master database, and is processed by the database reference processing unit 202. In this case, the contents of the database are not updated, and the replication control system 301 is not called.

Reference numeral 1203 shown in FIG. 9 denotes an SQL for updating the master database, which is processed by executing a database update instruction (step 801). The database update processing means 203 is called from the execution of the database update instruction (step 801). After the master database is updated in step 802, if a replica database exists, the update history extraction means 302 is called with OUTPUT = DATA. Database update history information is generated, and in step 511, the update history is written to the update history extraction file as indicated by 1301 in FIG. After that, OUTPUT
= DATA, transaction sequence management means 30
3 is called, SEQ = 0 is set in step 602, and the execution of the database update processing instruction ends.

An instruction 1204 shown in FIG. 9 clearly indicates the end of the transaction, and is processed by executing the COMMIT instruction (step 901). COMMIT
The transaction determination means 204 is called from the instruction execution (step 901), and after executing the COMMIT processing of the master database in step 902, if a replica database exists, OUTPUT = CO
The update history extraction means 302 is called in MMIT1, and COMMIT1 information is generated in step 504,
In step 511, the update history is written to the update history extraction file as indicated by 1302 in FIG.

Further, the transaction sequence monitoring means 303 is called with OUTPUT = COMMIT1, and SEQ = 1 is set in step 604.
Next, the update journal processing means 205 is called. After the update journal write processing of the master database is executed in step 905, if a replica database exists, the update history extraction means 302 is called with OUTPUT = COMMIT2, and in step 506, COMMIT2 Information is generated, and in step 511, the update history is written to the update history extraction file as indicated by 1303 in FIG.

Further, the transaction sequence monitoring means 303 is called with OUTPUT = COMMIT2, SEQ = 2 is set in step 605, and the update history reception / reflection means 4 of the replication control system 402 of the replication client system 401 is set.
03 reads and processes the update history extraction file received periodically.

First, in step 702, the update history 1
The update history is read, and since the update history is DATA information, the process returns to step 702 while retaining the information. Next, in step 702, the next update history 1302 is read, and since this update history is COMMIT1 information,
In step 704, STAT = 1 is set, and the process returns to step 702.

Next, in step 702, the next update history 1303 is read, and this update history is stored in COMMIT2.
STAT = 2 in step 706 because it is information.
Is set, the process branches to step 713 in step 712, and the transaction is reflected in the replica database in step 713 based on the read update history. After the reflection is completed and the contents of the master database and the replica database become the same, Return to step 701.

Next, the operation at the time of abnormal termination of a transaction will be described. When a transaction is abnormally terminated due to forced termination or the like, in a conventional system, normal replication control processing may not be completed. The operation of the database replication system according to the present invention when a transaction ends abnormally due to forced termination or the like will be described with reference to FIG.

If an abnormal end occurs after step 902 in FIG. 6 and before the update history extracting means 302 is called, the master database normally completes until the update journal writing (step 905) ends, but the replication control is terminated. There is a possibility that the processing of the update history extraction means 302, which means the completion of the transaction in the system, cannot be completed and abnormally terminated, resulting in inconsistency between the master database and the replica database.

In the database replication system of the present invention, if a transaction ends abnormally immediately after the update journal writing process (step 905), the processing of the master database is in a state where all transactions are completed, and the update history is shown in FIG. Show 1
Only 401 and 1402 are output, and COMMIT2 indicating the completion of the transaction is not output. Thereafter, the database management system 201 detects the abnormal termination of the transaction, calls the transaction discarding means 206, and discards the transaction.

First, in step 1002, a ROLLBACK process of the database is performed. In this case, since the master database has already completed the transaction, the ROLLBACK processing has no effect on the master database. Next, in step 1004, the update history extraction means 302 is called with OUTPUT = ROLLBACK, and in step 508, the RO
The LLBACK information is generated, and in step 511, the update history is written to the update history extraction file as indicated by 1403 in FIG.

Further, in the transaction sequence monitoring means 303, OUTPUT = ROLLBACK,
In addition, since SEQ = 1, in step 609 S
If EQ = −1 is set, abnormal termination is detected, and step 61
In step 2, the ROLLBACK information output immediately before is discarded, OUTPUT = CHECK is set, the CHECK information is output by the update history extraction means 302, and SEQ = 0 is set and cleared. The update history states at that time are 1501, 1502 and 1503 shown in FIG.

Next, the replication control system 4 of the replication client system 401
02, the update history reception / reflection means 403 shown in FIG.
The update history extraction files 501, 1502, and 1503 are read and the processing is performed. When the CHECK information of 1503 shown in FIG.
TAT = −1 is set, and data having a possibility of inconsistency is read again from the master database using the update history retransmitting means 404.
Set the correct value for.

Next, another embodiment of the database replication system of the present invention will be described. In the present embodiment, when a system failure occurs, inconsistency is automatically detected. When the system is started, first, the system down processing means 305 is called. If this system startup is the first system startup after the system down, in step 1102, OUTPUT = CHECK.
Is set in the update history extracting means 302.
Output information.

Replication client system 4
In step 01, the CHECK information is received, the update history retransmitting means 404 is called, and data having a possibility of inconsistency is read from the master database again, and a correct value is set in the replica database in step 717, as in the case of abnormal termination of the transaction. I do. By having such steps, even when a system failure occurs, data inconsistency is automatically detected, and high-speed recovery is enabled.

Next, the automatic database recovery method of the present invention will be described. The automatic recovery method of the present invention
A method for automatically recovering a database using a database replication system including a replication system having a master database, a database management system, a replication control system, and a replication client system having a replica database, the transaction sequence monitoring of the replication control system Means for detecting abnormal termination of the transaction, steps for discarding the transaction by the transaction discarding means of the database management system, and means for updating the update history of the replication client system for inconsistency between the master database and the replica database. Reads data from the master database and It characterized by having a step of setting the correct value Rica database.

The automatic database recovery method of the present invention can be implemented using the above-described database replication system of the present invention. In the automatic database recovery method of the present invention, the transaction sequence monitoring means 303 of the replication control system 310 detects abnormal termination of the transaction, the transaction discarding means of the database management system 201 discards the transaction, the replication client system The update history retransmitting means 404 included in 401 has a step of reading an inconsistent database between the master database 207 and the replica database 405 from the master database 207 and setting a correct value in the replica database 405. For the above steps,
This is as described in the above description of the operation of the database replication system of the present invention.

In the automatic database recovery method of the present invention, the replication control system 301
Has a step of detecting data inconsistency when a system down occurs. This step is also as described in the above description of the operation of the database replication system of the present invention.

Next, a program for causing a computer to execute the database automatic recovery method of the present invention will be described. The program for causing a computer to execute the automatic database recovery method of the present invention is a program for controlling the operation of the computer and for executing the automatic database recovery method of the present invention described above. Is a program for executing the database automatic recovery method of the present invention described above.

[0059]

As described in detail above, the database replication system of the present invention does not stop the database reference / update work or stop the replication even at the end of the transaction or when the system goes down. It is a system that can implement replication. Further, according to the automatic database recovery method of the present invention, database replication can be performed without stopping database reference / update operations or stopping replication even at the end of a transaction or when the system goes down. Can be.

[Brief description of the drawings]

FIG. 1 is a diagram showing a configuration of a database replication system of the present invention.

FIG. 2 is a diagram showing a flow of an operation in an update history extraction unit.

FIG. 3 is a diagram showing a flow of an operation in a transaction sequence monitoring means.

FIG. 4 is a diagram showing a flow of operation in an update history reception / reflection unit 3.

FIG. 5 is a diagram showing a flow of an operation of executing a database update instruction.

FIG. 6 is a diagram showing a flow of an operation of executing a COMMIT instruction.

FIG. 7 is a diagram showing a flow of an operation of executing a ROLLBACK instruction.

FIG. 8 is a diagram showing a flow of operation at the time of system down.

FIG. 9 is a diagram illustrating an example of a transaction.

FIG. 10 is a diagram illustrating an example of an update history.

[Explanation of symbols]

 101 Replication server system 201 Database management system 202 Database reference processing means 203 Database update processing means 204 Transaction determination means 205 Update journal processing means 206 Transaction discarding means 207 Master database 208 Update journal 301 Replication control system 302 Update history extraction means 303 Transaction sequence monitoring Means 304 Update history transmission means 305 System down processing means 306 Update history extraction file 401 Replication client system 402 Replication control system 403 Update history reception reflection means 404 Update history retransmission means

Claims (6)

[Claims] 1. A database replication system comprising a replication server system having a master database and a replication client system having a replica database, wherein the replication server system has a database management system and a replication control system; The system includes a transaction discarding unit for discarding the transaction, the replication control system includes a transaction sequence monitoring unit for detecting abnormal termination of the transaction, and the replication client system is configured to determine whether or not the master database and the replica database have an error. Read the consistent data from the master database and the replica database To set the correct value, and having the update history retransmission means, a database replication system. 2. The replication control system according to claim 1,
2. The data replication system according to claim 1, further comprising system down processing means for detecting data inconsistency when a system down occurs. 3. A method for automatically recovering a database using a database replication system including a replication system having a master database, a database management system, a replication control system, and a replication client system having a replica database, wherein the replication control system Detecting the abnormal termination of the transaction by the transaction sequence monitoring means included in the database management system; and discarding the transaction by the transaction discarding means of the database management system. The update history resending means of the replication client system includes the master database and the replica. Is data inconsistent with the database the master database? Automatically restoring a replica database and setting a correct value in a replica database. 4. The database automatic recovery method according to claim 3, further comprising a step of detecting a data inconsistency when a system down occurs in a system down processing unit of the replication control system. 5. A method for automatically recovering a database using a database replication system including a replication system having a master database, a database management system, a replication control system, and a replication client system having a replica database, the replication control system comprising: Detecting the abnormal termination of the transaction by the transaction sequence monitoring means included in the database management system; and discarding the transaction by the transaction discarding means of the database management system. The update history resending means of the replication client system includes the master database and the replica. Is data inconsistent with the database the master database? A program for causing a computer to execute a database automatic recovery method, comprising the steps of: reading from a database and setting a correct value in a replica database. 6. A program for causing a computer to execute the database automatic recovery method according to claim 5, wherein the system down processing means of the replication control system has a step of detecting data inconsistency when a system down occurs. .