Information processing device, information processing method, and information processing program

Abstract

If a failure occurs in one of the redundantly configured databases, any data differences that may arise are recovered. [Solution] The information processing device of the present invention determines the type of recovery processing based on the timing at which a DB server failure is detected during processing related to data registration in a first DB server and a second DB server, sets recovery information including the type of recovery processing and transaction identification information, checks the status of the first DB server and transactions existing in the DB server using the transaction identification information, and, based on the transaction status check results, causes the corresponding DB server to perform the recovery processing of the type related to the recovery processing of the recovery information.

Description

[Technical Field]

[0001] The present invention relates to an information processing device, an information processing method, and an information processing program. [Background technology]

[0002] When communicating between a client and a server, technology for creating redundant databases (DBs) is becoming widespread. For example, in systems that require reliability, such as voice communications, creating redundant databases for call information, etc., allows for server failover even if one server fails, enabling continuous system operation and maintaining reliability.

[0003] A conventional redundant configuration is described in Patent Document 1. The redundant configuration described in Patent Document 1 has multiple databases distributed in a distributed manner, so that even if one database fails, the other databases retain the records. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2016-40675 Summary of the Invention [Problem to be solved by the invention]

[0005] However, in the redundant configuration described above, if a malfunction occurs in one of the servers during the switchover process in the event of a failure, the databases cannot be synchronized and updated correctly, resulting in data differences between the databases, which may affect applications that use the databases.

[0006] Therefore, there is a need for an information processing device, an information processing method, and an information processing program that can recover data differences depending on the timing of detection of a failure when a failure occurs in one of the redundantly configured databases. [Means for solving the problem]

[0007] In order to solve such problems, the first present invention is an information processing device that stores the same data in a first DB (database) server and a second DB server that have a redundant configuration, and is characterized by comprising: (1) a recovery processing type determination means that determines the type of recovery processing based on the timing at which a failure of either DB server is detected during processing related to data registration in the first DB server and the second DB server; (2) a recovery information setting means that sets recovery information including the type of recovery processing and transaction identification information that identifies the transaction; (3) a status confirmation means that uses the transaction identification information of the recovery information to confirm the status of the first DB server and transactions existing in the DB server; and (4) a recovery processing means that causes the corresponding DB server to perform recovery processing of the type related to the recovery processing of the recovery information based on the transaction status confirmation result.

[0008] The second present invention is an information processing method for storing the same data in a first DB server and a second DB server having a redundant configuration, characterized in that (1) a recovery processing type determination means determines the type of recovery processing based on the timing of detecting a failure in either DB server during processing related to data registration in the first DB server and the second DB server, (2) a recovery information setting means sets recovery information including the type of recovery processing and transaction identification information that identifies the transaction, (3) a status confirmation means uses the transaction identification information of the recovery information to confirm the status of the first DB server and the transactions existing in the DB server, and (4) a recovery processing unit causes the corresponding DB server to perform recovery processing of the type related to the recovery processing of the recovery information based on the transaction status confirmation result.

[0009] The third invention is an information processing program for storing the same data in a first DB server and a second DB server having a redundant configuration, characterized in that the computer functions as: (1) a recovery processing type determination means for determining the type of recovery processing based on the timing at which a failure of either DB server is detected during processing related to data registration in the first DB server and the second DB server; (2) a recovery information setting means for setting recovery information including the type of recovery processing and transaction identification information that identifies the transaction; (3) a status confirmation means for confirming the status of transactions existing in the first DB server and the DB server using the transaction identification information of the recovery information; and (4) a recovery processing means for causing the corresponding DB server to perform recovery processing of the type related to the recovery processing of the recovery information based on the transaction status confirmation result. [Effects of the Invention]

[0010] According to the present invention, when a failure occurs in one of the databases in a redundant configuration, it is possible to recover the data difference depending on the timing at which the failure is detected. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is an overall configuration diagram showing the overall configuration of a redundant system according to an embodiment; [Figure 2] FIG. 10 is a sequence diagram showing data registration in a conventional master DB. [Figure 3] FIG. 10 is a sequence diagram showing a conventional process when a failure occurs during data registration. [Figure 4] FIG. 2 is an explanatory diagram illustrating a directory of a recovery file according to the embodiment. [Figure 5] 10A and 10B are explanatory diagrams illustrating the output timing of a recovery file and the processing content to be executed according to an embodiment. [Figure 6] FIG. 10 is a sequence diagram showing a processing operation for recovery by ROLLBACK in the embodiment. [Figure 7] FIG. 10 is a sequence diagram showing a processing operation for recovery by COMMIT in the embodiment. [Figure 8] FIG. 10 is a sequence diagram showing the operation of a recovery process according to a modified embodiment (part 1). [Figure 9] FIG. 10 is a sequence diagram (part 2) showing the operation of the recovery process according to the modified embodiment. [Figure 10] FIG. 10 is a sequence diagram (part 3) showing the operation of the recovery process according to the modified embodiment. [Figure 11] FIG. 10 is a sequence diagram showing the operation of a recovery process according to a modified embodiment (part 4). DETAILED DESCRIPTION OF THE INVENTION

[0012] (A) Embodiment Hereinafter, an information processing device, an information processing method, and an information processing program according to embodiments of the present invention will be described in detail with reference to the drawings.

[0013] In this embodiment, an example is shown in which the information processing device of the present invention is applied to a client-side device that is equipped with a DB client and a DB registration recovery processing unit in processing related to a database (DB). Note that the information processing device of the present invention is not limited to the client-side device described below.

[0014] (A-1) Configuration of the embodiment FIG. 1 is a diagram showing the overall configuration of a redundant system according to an embodiment.

[0015] In FIG. 1, a redundant system 9 according to the embodiment includes a client device 10 as an information processing device, and two database servers (hereinafter referred to as DB servers) 2 (2A and 2B).

[0016] The client device 10 has a DB client 1 that connects to and operates the DB server 2, and a DB registration recovery processing unit 11. In this example, the DB client 1 and the DB registration recovery processing unit 11 are physically installed in the same device (client device 10). However, they may be distributed as long as the processes described below can be linked.

[0017] The DB servers 2 (2A and 2B) are each connected to the DB client 1, and receive operations from the DB client 1 and store data.

[0018] The DB servers 2 (2A and 2B) include a master DB 21 (21A and 21B), a slave DB 22 (22A and 22B), and control units 23 (23A and 23B). The DB servers 2A and 2B are distributed.

[0019] For example, an application using the DB of DB server 2 can be a voice communication service that performs call processing, etc., and the server stores data such as subscriber information and call information in master DB 21 and slave DB 22, and provides reliable services using this data. Note that the application is not limited, and a wide range of services other than voice communication services can be applied.

[0020] DB servers 2A and 2B each have an independent redundant configuration. For example, DB server 2A has a master DB21A and a slave DB22A, and is configured as a master-slave redundant server. Similarly, DB server 2B has a master DB21B and a slave DB22B, and is configured as a master-slave redundant server.

[0021] In this embodiment, the recovery process between distributed master DBs 21 will be mainly described. Therefore, a detailed description of the master-slave configuration method, to which various methods can be applied, will be omitted. Also, it is assumed that the master DB 21 and slave DB 22 of each DB server 2 are correctly synchronized with each other and there are no differences in data.

[0022] The DB client 1 is connected to each DB server 2 (2A and 2B) and performs operations such as data registration and data retrieval on the DB (for example, master DB 21A and 21B) of each DB server 2. In other words, the DB client 1 has a role of operating the DB of the DB server 2.

[0023] When registering data in the DB servers 2, if any of the DB servers 2 fails and a data difference occurs between the master DB 21A and the master DB 21B, the DB client 1 performs recovery processing to restore the registered data difference.

[0024] The DB client 1 includes a recovery process type determination unit 11a, a recovery information setting unit 11b, and a storage unit 12 in addition to an operation unit for operating an existing DB.

[0025] The recovery processing type determination unit 11a determines the type of recovery processing based on the timing at which a failure in one of the DB servers 2 is detected during processing related to data registration in the DB servers 2A and 2B.

[0026] The recovery information setting unit 11b sets recovery information including the type of recovery process determined by the recovery process type determination unit 11a and transaction identification information for identifying the transaction. The recovery information setting unit 11b stores the recovery information in a directory of recovery files (update recovery files) provided in the storage unit 12.

[0027] The DB registration recovery processing unit 11 performs differential recovery when a data difference occurs in the DB when data is registered in each of the DB servers 2A and 2B. The DB registration recovery processing unit 11 is installed in a device as one function of a client-side device, for example.

[0028] The DB registration recovery processing unit 11 includes a state confirmation unit 11C and a recovery processing unit 11d.

[0029] The status confirmation unit 11c uses the transaction identification information in the recovery information to confirm the status of the transactions existing in the DB servers 2A and 2B.

[0030] The recovery processing unit 11d causes the corresponding DB server to perform the recovery process of the type related to the recovery process of the recovery information based on the transaction state confirmation result.

[0031] Each of the DB client 1 and the DB server 2 can be a computer equipped with a CPU, memory, an external storage device such as a hard disk, etc. For example, in each of the DB client 1 device and the DB server 2 device, processing programs (e.g., redundancy programs, recovery programs, etc.) are stored in an external storage device, and the CPU of the DB client 1 executes the processing program for DB client 1, and the CPU of the DB server 2 executes the processing program for DB server 2, thereby realizing processing of the redundant configuration and recovery processing.

[0032] (A-2) Operation of the embodiment Next, the processing operations in the redundant system 9 according to the embodiment will be described in detail with reference to the drawings.

[0033] (A-2-1) Technical concept of recovery processing The DB client 1 guarantees the identity of the data registered in the two DB servers 2. Therefore, the DB client 1 writes data to the master DBs 21A and 21B of the two DB servers 2, respectively.

[0034] Fig. 2 is a sequence diagram showing data registration in a conventional master DB, and Fig. 3 is a sequence diagram showing processing when a failure occurs during conventional data registration.

[0035] As shown in FIG. 2, the DB client 1 instructs each of the master DBs 21A and 21B to register data (step S1), and the master DBs 21A and 21B perform transaction processing.

[0036] As a general specification, consistency is guaranteed in the master DBs 21A and 21B by transactions, and when the transaction is completed successfully, the DB client 1 COMMITs to the master DBs 21A and 21B, and the master DBs 21A and 21B complete the data registration successfully. In this way, the DB client 1 is responsible for registering data in the master DBs 21A and 21B.

[0037] However, a failure may occur in one of the DB servers 2 (DB server 2B in the case of FIG. 3) during a transaction (step S2 in FIG. 3).

[0038] Here, the DB client 1 COMMITs the master DB 21A for which the transaction has been completed (step S3), and the master DB 21A completes the data registration (step S4). On the other hand, in the past, when a failure occurred in the master DB 21B, the DB client 1 was unable to COMMIT (step S5), as shown in the example of FIG. 3. That is, the failed master DB 21B stops the data registration process due to the malfunction. Thereafter, recovery work is performed (step S6), and after recovery from the failure, the master DB 21B rolls back to the state before the change (step S7), but because COMMIT has not been performed, the data related to this data registration process has not been registered (step S8), and a data difference may occur between the master DB 21A and the master DB 21B.

[0039] In the past, when a data difference occurred between two master DBs 21A and 21B, a maintenance person or the like had to operate DB client 1, manually compare the data difference between master DB 21A and master DB 21B, and register the data that should be registered to reflect the difference.

[0040] Therefore, in this embodiment, a system is adopted in which the two master DBs 21 retain exactly the same data as the prerequisite configuration, and a DB registration recovery function is provided on the client side. Then, when a failure such as a breakdown occurs and one of the two master DBs 21 fails to commit, causing a difference in the data between the master DBs 21, the DB registration recovery function is used to recover the difference. This makes it possible to update the master DB 21 even when a problem occurs.

[0041] For example, when a data difference occurs, it is not possible to recover the data difference using only the DB client 1 and the two master DBs 21A and 21B, so a DB registration recovery processing unit 11 is provided that recovers the data difference between the two master DBs 21 using a DB update history file (hereinafter also referred to as a "recovery file").

[0042] (A-2-2) About DB registration recovery processing unit 11 Next, the operation functions of the DB registration recovery processing unit 11 and the recovery file will be explained.

[0043] As a prerequisite, the DB registration recovery processing unit 11 creates a directory for recovery files on the DB client 1 as an initial setting.

[0044] FIG. 4 is an explanatory diagram illustrating a directory of a recovery file according to the embodiment.

[0045] As shown in the example of FIG. 4, the DB registration recovery processing unit 11 creates " / var / opt / postgres / log" on the DB client 1 as an output directory for storing a recovery file (DB update history file).

[0046] Furthermore, the DB registration recovery processing unit 11 causes the DB client 1 to create " / var / opt / postgres / log / work" as a directory during recovery and " / var / opt / postgres / log / recovered" as a directory where recovery has been completed. Note that the directories in FIG. 4 are merely examples and are not limiting.

[0047] For example, a recovery file (DB update history file) stores a transaction ID, timestamp, etc. Here, a "transaction ID" is identification information that identifies a transaction when data is registered in a DB. A "timestamp" is a value that indicates the time stamp when a transaction with a certain transaction ID was performed.

[0048] The DB registration recovery processing unit 11 outputs the registered content to a recovery file (recovery file directory) after registering the data (after issuing a data registration instruction) every time a data registration instruction is issued to the master DB 21 (master DBs 21A and 21B).

[0049] Here, for example, the DB registration recovery processing unit 11 outputs a recovery file in csv format, and creates the file name of the recovery file as "timestamp (14 digits)_transaction ID (16 digits)".

[0050] For example, if the timestamp is "20230605114100" and the transaction ID is "00007fffd8000b60", the DB client 1 creates a file name such as "20230605114100_00007fffd8000b60.csv".

[0051] By using a file name that includes a timestamp and a transaction ID in this way, the necessary recovery file can be searched for using the transaction ID as a key during differential recovery.

[0052] The recovery information recorded in the recovery file is output in two lines per transaction per file, one for DB server 2A and one for DB server 2B.

[0053] The format of the recovery information consists of four parameters separated by commas: "the server to connect to," "either COMMIT or ROLLBACK" indicating the type of processing to be performed by the recovery information, and "transaction ID" and "transaction number," which are identification information that uniquely identifies the transaction.

[0054] Furthermore, the recovery information is created in the format configuration described above, and is output line by line to the DB server 2A and DB server 2B.

[0055] For example, suppose the server name to connect to is "psql-test2", the process to be performed is "COMMIT", the transaction ID is "0x00007fffd8000b60", and the transaction number is "161280774". In this example, the format setting example would be "psql-test2,COMMIT,0x00007fffd8000b60,161280774".

[0056] Here, the process to be performed during recovery is determined depending on the timing at which the DB client 1 receives an NG from the DB server 2 where the failure occurred.

[0057] FIG. 5 is an explanatory diagram illustrating the output timing of the recovery file and the processing contents to be executed according to the embodiment.

[0058] As shown in FIG. 5, the DB client 1 outputs the recovery file when it receives an NG signal from the DB server 2, indicating that the transaction cannot be completed correctly, and the DB client 1 detects NG.

[0059] For example, if an NG signal is received from the failed DB server 2 while "data is being registered (i.e., a transaction is being executed)" with the DB server 2, the DB client 1 selects ROLLBACK. Also, for example, if an NG signal is received from the failed DB server 2 while "COMMIT is being executed (commit is being executed)" with the DB server 2, the DB client 1 selects COMMIT.

[0060] The conditions for connecting to a database during recovery are determined by the database server corresponding to the host name listed in the recovery file and the "connection port," "connection database name," "user," and "password" listed in the configuration.

[0061] (A-2-3) Recovery process [Recovery process with ROLLBACK] FIG. 6 is a sequence diagram showing the processing operation for recovery by ROLLBACK in the embodiment.

[0062] 6, the DB client 1 instructs the master DBs 21A and 21B of the two DB servers 2A and 2B to register data (step S101). A data registration transaction starts in each of the master DBs 21A and 21B.

[0063] At this time, a failure such as a breakdown occurs in the master DB 21B during the transaction (step S102), and the DB server 2B having the master DB 21B returns an NG signal indicating that a failure has occurred to the DB client 1 (step S103).

[0064] After the data registration in S101, the DB client 1 outputs recovery information including the registered contents to a recovery file (S104).

[0065] At this time, recovery information is created for DB server 2A and DB server 2B. For example, as shown in Fig. 6, "psql-test2,ROLLBACK,0x00007fffd8000b60,161280774" is set for DB server 2A, and "psql-test2,ROLLBACK,0x00007fffd8000b60,192231657" is set for DB server 2B.

[0066] In this example, the DB client 1 receives and detects an NG signal from the DB server 2B during "data registration." Therefore, as shown in Figure 5, the DB client 1 sets recovery information with the recovery process type set to "ROLLBACK" and outputs this recovery information to the recovery file.

[0067] In order to check the status of the master DBs 21A and 21B, the DB registration recovery processing unit 11 checks with each of the master DBs 21A and 21B whether or not the transaction ID in the recovery file exists (steps S105 and S108).

[0068] In this example, since no failure has occurred in the master DB 21A, it is possible to confirm that the transaction ID exists. Therefore, in response to a request from the DB registration recovery processing unit 11 to confirm the existence of the transaction ID (step S105), the master DB 21A replies to the DB registration recovery processing unit 11 that the transaction ID exists (step S106).

[0069] Meanwhile, recovery work is performed on the master DB 21B where the failure occurred. Because the failure occurred during data registration, the transaction with the transaction ID exists in the master DB 21B. Therefore, after recovery from the failure (step S107), in response to a confirmation from the DB registration recovery processing unit 11 about the existence of the transaction ID (step S108), the master DB 21B replies to the DB registration recovery processing unit 11 that the transaction ID exists (step S109).

[0070] The DB registration recovery processing unit 11 periodically or intermittently checks the contents of the directory during recovery execution using cron. Here, the DB registration recovery processing unit 11 checks whether the recovery file has remained in the directory for a certain period of time or more.

[0071] If a recovery file remains (step S110), the recovery file is moved to the recovery execution directory. Then, referring to the processing type set in the recovery information (in this example, "ROLLBACK"), the DB registration recovery processing unit 11 instructs each of the master DBs 21A and 21B to perform a ROLLBACK (steps S111 and S112).

[0072] After that, when recovery for all transactions in the file is completed, the recovery file is moved to the recovery execution directory, which allows the recovery file in the recovery execution directory to be deleted.

[0073] In this way, if an NG is detected "during data registration", by performing a ROLLBACK on each of the two master DBs 21A and 21B, the state before the failure occurs is restored, and the difference can be restored.

[0074] [Recovery processing with COMMIT] FIG. 7 is a sequence diagram showing the processing operation for recovery by COMMIT in the embodiment.

[0075] 7, the DB client 1 instructs the master DBs 21A and 21B of the two DB servers 2A and 2B to register data (step S201). Each of the master DBs 21A and 21B starts a transaction for registering data.

[0076] The transaction is completed in the master DB 21A, the DB client 1 issues a COMMIT to the master DB 21A (step S203), and the master DB 21A of the DB server 2A completes the data registration (step S204).

[0077] On the other hand, the transaction is completed in the master DB 21B, and the DB client 1 issues a COMMIT to the DB server 2B (step S202). However, during the execution of the COMMIT, a failure occurs in the master DB 21A (step S205), causing the COMMIT to fail (step S206). In other words, it is assumed that a failure occurs during the execution of the COMMIT transaction.

[0078] At this time, the DB server 2B having the master DB 21B returns an NG signal indicating that a failure has occurred to the DB client 1 (step S207).

[0079] After the data registration in S201, the DB client 1 outputs recovery information including the registered contents to a recovery file (S208).

[0080] At this time, as shown in the example of FIG. 7, recovery information for each of the DB servers 2A and 2B is set.

[0081] In this example, the DB client 1 receives and detects an NG signal from the DB server 2B during "COMMIT." Therefore, as shown in Figure 5, the DB client 1 sets recovery information with the process type at the time of recovery set to "COMMIT," and outputs this recovery information to the recovery file.

[0082] The DB registration recovery processing unit 11 checks the master DBs 21A and 21B to see if the transaction ID in the recovery file exists in each of the master DBs 21A and 21B in order to check the status of the master DBs 21A and 21B (steps S209, S212).

[0083] Since the master DB 21A has not experienced any failure and has completed data registration, the transaction ID does not exist. Therefore, in response to a request from the DB registration recovery processing unit 11 to confirm the existence of the transaction ID (step S209), the master DB 21A replies to the DB registration recovery processing unit 11 that the transaction ID does not exist (step S210).

[0084] On the other hand, in the master DB 21B, a transaction with the transaction ID exists because COMMIT failed due to a failure, etc. Therefore, after recovery from the failure (step S211), in response to a confirmation from the DB registration recovery processing unit 11 as to whether the transaction ID exists (step S212), the master DB 21B replies to the DB registration recovery processing unit 11 that the transaction ID exists (step S213).

[0085] The DB registration recovery processing unit 11 periodically or intermittently checks the contents of the directory during recovery execution using cron. Here, the DB registration recovery processing unit 11 checks whether the recovery file has remained in the directory for a certain period of time or more.

[0086] If a recovery file remains (step S214), the recovery file is moved to the recovery execution directory. Then, referring to the processing type set in the recovery information ("COMMIT" in this example), the DB registration recovery processing unit 11 issues a COMMIT to the master DB 21B (step S215).

[0087] The master DB 21B executes COMMIT to complete the data registration (step S216).

[0088] After that, when recovery for all transactions in the file is completed, the recovery file is moved to the recovery execution directory, which allows the recovery file in the recovery execution directory to be deleted.

[0089] In this way, if an NG is detected "during COMMIT", the data registration has been completed in the master DB 21A where no failure has occurred, so the difference can be recovered by executing COMMIT on the master DB 21B where the failure has occurred.

[0090] (A-3) Effects of the embodiment As described above, according to this embodiment, by providing a DB registration recovery function on the client side, even if one DB stops due to a failure while data is being updated in each of the two DBs, the differences between the two DBs can be reflected. This makes it possible to reduce the impact on applications that use the DBs even when a failure occurs.

[0091] (B) Other embodiments Although various modified embodiments have been mentioned in the above-described embodiment, the present invention can also be applied to the following modified embodiments.

[0092] (B-1) In the above embodiment, the case of two DB servers 2 is exemplified, but it is also possible to restore differences between the master DBs 21 held by three or more DB servers 2.

[0093] 8 to 11 are sequence diagrams showing the operation of the recovery process according to the modified embodiment.

[0094] 8 to 11 illustrate recovery processing when a failure occurs in one of the master DBs 21A to 21C of each of the three DB servers 2A to 2C, resulting in a difference. The same effect can be obtained when there are four or more DB servers.

[0095] The basic operation is the same as in the above-described embodiment, but there are three master DBs 21A to 21C, and the case where a failure occurs in the master DB 21 is different. Therefore, in Figures 8 to 11, the description will focus on characteristic processing, and the processing already described in Figures 6 and 7 will be omitted.

[0096] [Recovery process in Figure 8] The example in FIG. 8 shows a case in which a failure such as a breakdown occurs in the master DB 21B of the DB server 2B among the three DB servers 2A to 2C during "data registration."

[0097] In this example as well, the data registration transaction cannot be completed, and the DB server 2B returns an NG signal to the DB client 1 (step S303).

[0098] Since the DB client 1 detected an error during "data registration," it selects "ROLLBACK" as the processing type and outputs recovery information to a recovery file (step S304). The DB registration recovery processing unit 11 checks whether a transaction ID exists to check the status of the three DB servers 2A to 2C (steps S305, S308, S310).

[0099] The master DB 21A of the DB server 2A and the master DB 21C of the DB server 2C are currently executing a data registration transaction and the transaction ID exists, so they return a message indicating that the transaction ID exists (steps S306, S311).

[0100] After the DB server 2B in which the failure occurred recovers from the failure (step S307), the DB server 2B returns a message indicating that the transaction ID exists (step S309).

[0101] Thereafter, the DB registration recovery processing unit 11 instructs each of the master DBs 21A to 21C to perform a ROLLBACK (step S313). When recovery for all transactions in the file is complete, the recovery file is moved to the recovery-completed directory.

[0102] In this case as well, the master DBs 21A to 21C are rolled back to return to the state before the data was registered, so that the data differences between the three master DBs 21A to 21C disappear.

[0103] [Recovery process in Figure 9] The example in Figure 9 shows a case where, of the three DB servers 2A to 2C, a failure such as a breakdown occurred in the master DB 21B of DB server 2B and the master DB 21C of DB server 2C while "registering data." Even if there are multiple master DBs 21 that have experienced failures, the differences can be recovered by the same process.

[0104] In this example as well, the data registration transaction cannot be completed, and the DB server 2B and the DB server 2C each return an NG signal to the DB client 1 (steps S403, S405).

[0105] Since the DB client 1 detected an error during "data registration," it selects "ROLLBACK" as the processing type and outputs recovery information to a recovery file (step S406). The DB registration recovery processing unit 11 checks whether a transaction ID exists to check the status of the three DB servers 2A to 2C (steps S407, S410, S413).

[0106] The master DB 21A of the DB server 2A is currently executing a data registration transaction and the transaction ID exists, so it returns a message indicating that the transaction ID exists (step S408).

[0107] After recovering from the failure (steps S409 and S412), the DB servers 2B and 2C in which the failure occurred return a message indicating that the transaction ID exists (steps S411 and S414).

[0108] Thereafter, the DB registration recovery processing unit 11 instructs each of the master DBs 21A to 21C to perform a ROLLBACK (step S416). When recovery for all transactions in the file is complete, the recovery file is moved to the recovery-completed directory.

[0109] In this case as well, the master DBs 21A to 21C are rolled back to return to the state before the data was registered, so that the data differences between the three master DBs 21A to 21C disappear.

[0110] In this way, even if a failure occurs in multiple master DBs 21, the data differences between the three master DBs 21 can be restored.

[0111] [Recovery process in Figure 10] The example in FIG. 10 shows a case in which a failure such as a breakdown occurs in the master DB 21B of the DB server 2B among the three DB servers 2A to 2C during "COMMIT."

[0112] In this example, the COMMIT sent by the DB client 1 to the DB server 2B fails (step S505), the master DB 21B cannot complete the COMMIT transaction, and the DB server 2B returns an NG signal to the DB client 1 (step S506).

[0113] Since the DB client 1 detected NG during "COMMIT", it selects "COMMIT" as the processing type and outputs the recovery information to the recovery file (step S507). The DB registration recovery processing unit 11 checks whether a transaction ID exists or not to check the status of the three DB servers 2A to 2C (steps S509, S512, S515).

[0114] Since the transaction has been completed, the master DBs 21A and 21C do not have the transaction ID and therefore return a message to that effect to the DB registration recovery processing unit 11 (steps S510 and S516).

[0115] On the other hand, the master DB 21B where the failure occurred has not completed the transaction and therefore the transaction ID exists, so after the failure is recovered (step S511), it returns a message to that effect to the DB registration recovery processing unit 11 (step S513).

[0116] The DB registration recovery processing unit 11 issues a COMMIT to the master DB 21B (step S518). The master DB 21B executes a COMMIT to complete the data registration (step S519). Thereafter, the DB registration recovery processing unit 11 outputs the processed recovery file to the recovery execution directory for deletion.

[0117] In this way, even with three master DBs 21A to 21C, the same effects as those of the above-described embodiment can be obtained.

[0118] [Recovery process in Figure 11] This example is a case in which, of the three DB servers 2A to 2C, a failure such as a breakdown occurs in the master DB 21B of the DB server 2B and the master DB 21C of the DB server 2C during "COMMIT".

[0119] In this example, the COMMIT sent by DB client 1 to DB servers 2B and 2C fails (steps S604, S606), the master DBs 21B and 21C are unable to complete the COMMIT transaction, and DB servers 2B and 2C return an NG signal to DB client 1 (steps S607, S608).

[0120] Since the DB client 1 detected NG during "COMMIT", it selects "COMMIT" as the processing type and outputs recovery information to the recovery file (step S609). The DB registration recovery processing unit 11 checks whether a transaction ID exists or not to check the status of the three DB servers 2A to 2C (steps S611, S614, S617).

[0121] Since the master DB 21A has committed, the transaction ID does not exist, and so it returns a message to that effect to the DB registration recovery processing unit 11 (step S612).

[0122] On the other hand, the master DB 21B and master DB 21C where the failure occurred have not completed the transaction, and therefore the transaction ID exists. After the failure is recovered (steps S613 and S616), the master DB 21B and master DB 21C return a message to that effect to the DB registration recovery processing unit 11 (steps S615 and S618).

[0123] The DB registration recovery processing unit 11 issues a COMMIT to the master DBs 21B and 21C (step S620). The master DB 21B executes a COMMIT to complete the data registration (steps S621 and S622). Thereafter, the DB registration recovery processing unit 11 outputs the processed recovery file to the recovery execution directory for deletion.

[0124] In this way, even if a plurality of master DBs 21 fail during a COMMIT, by performing a COMMIT after recovery from the failure, data differences between the master DBs and other master DBs that are not broken down will disappear.

[0125] (B-2) The recovery process sequence is illustrated in Figures 6, 7, and 8 to 11, but is not limited to the processes and procedures shown in the figures. The order of the processes may be changed as long as the same effect is obtained. [Explanation of symbols]

[0126] 9...redundant systems, 10... client device, 1... DB client, 11... DB registration recovery processing unit, 1a... recovery processing type determination unit, 1b... recovery information setting unit, 1c... status confirmation unit, 1d... recovery processing unit, 12... storage unit, 2 (2A, 2B, 2C)...DB server, 21 (21A, 21B, 21C)...master DB, 22 (22A, 22B, 22C)...slave DB, 23...control unit.

Claims

1. In an information processing device that has a redundant configuration and stores the same data in a first DB (database) server and a second DB server, a recovery process type determination means for determining a type of recovery process based on the timing of detecting a failure in one of the first and second DB servers during a process related to data registration in the first and second DB servers; a recovery information setting unit that sets recovery information including a type related to the recovery process and transaction identification information that identifies the transaction; a status checking means for checking the status of transactions existing in the first DB server and the DB server by using the transaction identification information of the recovery information; a recovery processing means for causing a corresponding DB server to execute a recovery process of a type related to the recovery process of the recovery information based on a transaction status check result; An information processing device comprising:

2. 2. The information processing device according to claim 1, wherein the recovery process type determination means detects a failure based on failure information from a DB server in which a failure has occurred, and determines the type of the recovery process by referring to a preset recovery process type correspondence table.

3. The recovery process type determination unit When a DB server failure is detected during a data entry transaction, a rollback is determined as the type of recovery process; When a DB server failure is detected during the commit of a transaction, the commit of the transaction is determined as the type of recovery process.

3. The information processing apparatus according to claim 2, wherein:

4. The recovery information storage unit for storing recovery information includes at least a recovery in progress storage unit and a recovery completed storage unit, the recovery information setting unit stores the set recovery information in the recovery execution storage unit; After the recovery process, the recovery processing unit stores the recovery information that has been executed in the recovery execution storage unit.

2. The information processing apparatus according to claim 1, wherein:

5. In an information processing method in which the same data is stored in a first DB server and a second DB server having a redundant configuration, a recovery processing type determination means determining a type of recovery processing based on timing at which a failure of either of the first and second DB servers is detected during processing related to data registration in the first and second DB servers; a recovery information setting means for setting recovery information including a type of the recovery process and transaction identification information for identifying the transaction; a status confirmation means for confirming the status of transactions existing in the first database server and the first database server by using the transaction identification information of the recovery information; The recovery processing unit causes the corresponding DB server to perform the recovery process of the type related to the recovery process of the recovery information based on the transaction state confirmation result.

1. An information processing method comprising:

6. In an information processing program for storing the same data in a first DB server and a second DB server having a redundant configuration, Computer, a recovery process type determination means for determining a type of recovery process based on the timing of detecting a failure in one of the first and second DB servers during a process related to data registration in the first and second DB servers; a recovery information setting unit that sets recovery information including a type related to the recovery process and transaction identification information that identifies the transaction; a status checking means for checking the status of transactions existing in the first DB server and the DB server by using the transaction identification information of the recovery information; a recovery processing means for causing a corresponding DB server to execute a recovery process of a type related to the recovery process of the recovery information based on a transaction status check result; An information processing program characterized by causing the program to function as follows.

Images