JP2007183728A - Multiplex database system, synchronization method therefor, intermediation device and intermediation program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a synchronization method in a multiplex database system, not causing contradiction between respective databases even if processing a plurality of transactions in parallel. <P>SOLUTION: In this multiplex database system, an intermediation device 200 detects contradiction of a processing result between respective servers 100, or a non-response of the server 100, selects one response from respective responses and cuts off the server 100 returning the response except the selected response from the system when detecting the contradiction of the processing result. When detecting the non-response of the server 100, the intermediation device 200 cuts off the server 100 of the no-response from the system, performs synchronization processing with the server 100 during normal operation incorporated in the system and the server 100 cut off from the system, and incorporates the server 100 cut off from the system into the system again after the synchronization processing is completed. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a multiplexed database system in which a plurality of database management systems (DBMS) are operated in parallel, and more particularly to a synchronization technique between databases.

  As a conventional multiplexed database system, for example, one described in Patent Document 1 is known. In this system, as shown in FIG. 50, two computers 1010 and 1020 each having a database are connected by a communication line. The computers 1010 and 1020 are synchronized between databases by so-called two-phase commit control.

  The computer 1010 controls the application program 1011 for executing various business processes and the search and update of the database 1014 and synchronizes with the update process in the database 1024 of another computer 1020 via the transaction monitor 1013. The system 1012 includes a transaction monitor 1013 that synchronizes update processing of the databases 1014 and 1024 by so-called two-phase commit control. Similarly to the computer 1010, the computer 1020 is composed of an application program 1021, a database management system 1022, and a transaction monitor 1023.

  In this system, a processing procedure in which the same data is held in the database 1014 of the computer 1010 and the database 1024 of the computer 1020 and the same update is reflected in both the databases 1014 and 1024 even when there is an update will be described.

  The application program 1011 updates the databases 1014 and 1024 with the same query within a certain transaction. The database 1014 is updated by the database management system 1012, and the database 1024 is updated by the database management system 1022.

  Then, the application program 1011 issues a “COMMIT request” for confirming the update so far or a “ROLLBACK request” for canceling the update so far at the end of the transaction. The “COMMIT request” or “ROLLBACK request” is sent by the transaction monitor 1013 to the database management system 1022 via the database management system 1012 and the transaction monitor 1023.

  For example, when the transaction monitor 1013 transfers a “COMMIT request”, the database management systems 1012 and 1022 return whether or not COMMIT execution is possible to the transaction monitor 1013. At this time, the database management systems 1012 and 1022 do not actually execute COMMIT, but only answer whether or not execution is possible.

  When the transaction monitors 1013 and 1023 receive a “COMMIT OK” response from both the database management systems 1012 and 1022, they transmit “COMMIT execution” to the database management systems 1012 and 1022, respectively. The database management systems 10112 and 1022 that have received “COMMIT execution” actually execute COMMIT.

  On the other hand, for example, when the transaction monitor 1013 receives a “COMMIT not possible” response from one of the database management systems 1012 or 1022, even if the other response is “COMMIT OK”, the transaction monitor 1013 responds to the database management systems 1012 and 1022. Then, “Execute ROLLBACK” is transmitted to cancel the transaction. Receiving “Execute ROLLBACK”, the database management systems 1012 and 1022 actually execute ROLLBACK.

As described above, the update is prevented from being reflected only in one of the databases, and the same update is always performed on both databases, thereby maintaining synchronization between the databases.
JP-A-6-161862

  However, the above-described conventional technique is a method for synchronizing the database of one transaction in a plurality of databases, and cannot control the synchronization of the database between the plurality of transactions. In other words, when multiple transactions are executed in parallel and these transactions access the same row of the same table almost simultaneously, the database is out of sync or the response returned to the client is unique. Problems such as being undecided arise. This problem will be specifically exemplified below.

  Consider a table named test_table shown in FIG. At this time, consider a case where transactions T1 and T2 shown in FIG. 52 are executed almost simultaneously. Transaction T1 updates the row with id = 101, and transaction T2 updates the row with id = 101 and the row with id = 102. The value of id = 101 differs depending on which transaction UPDATE is executed first.

  The order in which the UPDATEs in the two transactions are executed can be considered in the following two ways.

(1) T2 UPDATE after T1 UPDATE
(2) T2 UPDATE after T2 UPDATE
In the case of (1), after two transactions are executed, the result of UPDATE of T2 remains and division = 2. On the other hand, in the case of (2), the result of UPDATE of T1 remains after execution of two transactions, and division = 1. That is, the data of the final table test_table differs between (1) and (2).

  That is, even if the initial state of a plurality of databases is the same and the same transaction is executed, if one DBMS executes in the order (1) and another DBMS executes in the order (2), There is a problem that the database is out of sync (the state that holds the same data).

  As another example, consider a case where transactions T3 and T4 shown in FIG. 53 are executed almost simultaneously. The value obtained in the SELECT of the transaction T4 differs depending on whether the SELECT of the transaction T4 is executed before or after the COMMIT of the transaction T3.

  There are two possible orders for executing SELECT of transaction T4 and COMMIT of transaction T3.

(3) T3 COMMIT after T4 SELECT
(4) T4 SELECT after T3 COMMIT
In the case of (3), after the SELECT of the transaction T4 is executed, an old value department = 3 that does not reflect the UPDATE of the transaction T3 is obtained. On the other hand, in the case of (4), the value department = 1 reflecting the UPDATE of the transaction T3 is obtained after the SELECT of the transaction T4 is executed.

  That is, even if the initial state of a plurality of databases is the same and the same transaction is executed, it is obtained when one DBMS is executed in the order of (3) and another DBMS is executed in the order of (4). The value will be different.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a synchronization method in a multiplexed database system in which inconsistency does not occur between databases even when a plurality of transactions are processed in parallel. It is to provide.

  The invention of the present application is a multiplex comprising a plurality of database servers and an intermediary device that relays a processing request from a client computer to each database server and returns one of the valid responses from each database server as a processing result to the client computer. The present invention relates to the synchronization processing of each database in the database system.

  By the way, when a plurality of transactions are processed in parallel in each database server, and processing requests in the transactions are processed in different orders in each database server, from the intermediary device side, (1) from a certain database server It is recognized that there is no response from another database server, or (2) the response from one database server and the response from another database server are inconsistent (different) There is a case.

  Therefore, in the present invention, the intermediary device (A) (i) upon detecting that there is no response to the processing request from the database server, disconnects the non-response database server from the system, or (ii) between each database server A database server that detects a contradiction in processing results, selects one response from each response, returns the selected response to the client computer, and returns a response other than the selected response. (B) The database server separated from the system is synchronized with the database server operating normally in the system, and (C) the database server separated from the system when the synchronization processing is completed. Is incorporated into the system again.

  As a result, when there is a response from a certain database server but no response from another database, the database server having no response is disconnected from the system. Or, if a response from one database server and a response from another database server are inconsistent, one response is selected from the responses, and the database server returns a response other than the selected response Is disconnected from the system. In other words, when a database server detects the possibility that the processing order of processing requests differs between database servers and the database servers become asynchronous (data that should be the same between the database servers is no longer the same) As a reference, the database server that may be asynchronous with the database server is disconnected from the system. Then, synchronization processing is performed between the database server that is operating normally and the database server that is separated from the system. When the synchronization processing is completed, the database server that is separated from the system is incorporated into the system again. Thereby, synchronization of each database server is achieved.

  In the synchronization process, the intermediary device is provided with a difference information storage unit that stores processing requests from client computers as difference information and a snapshot storage unit that stores database snapshots, and the database server is disconnected from the system. During this time, the processing request received from the client computer is stored as difference information. Further, the mediation device acquires a snapshot from the database server that is operating normally and stores it in the snapshot storage unit. Then, the intermediary device restores the database of the database server separated from the system using the snapshot. Thereafter, the mediation device sequentially transmits the difference information stored in the difference information storage unit to the database server. The database server can synchronize with a normally operating server by processing a processing request as difference information from the mediation device.

  Here, the incorporation of the database server into the system means that the mediating apparatus handles the database server so as to function as a database server constituting the multiplexed database system. In addition, the separation from the database server from the system means that the mediating apparatus handles the database server so that it does not function as the database server constituting the multiplexed database system. Therefore, the processing request from the client computer reaches the database server incorporated in the system via the mediation device, but the processing request from the client computer does not reach the database server separated from the system. It should be noted that it is irrelevant whether the database server is incorporated in or disconnected from the system, and whether the database server can or cannot communicate with the mediation device. That is, even when the database server and the mediation apparatus are in a communicable state, the database server may not be incorporated in the system.

  As described above, according to the present invention, even if a contradiction occurs between the database servers by processing a plurality of transactions in parallel, the database servers can be synchronized and thus the conflict can be resolved. In addition, since the control process for maintaining the synchronization of each database server is performed exclusively by the mediation device, the existing database can be used without modification as the database itself. Furthermore, each database server has processing that guarantees that all databases are updated in the same order in order to maintain synchronization, that is, update query order control and scheduling, server-to-server communication and order control for realizing them. Since it is not necessary to perform processing such as rollback in the case of failure, an increase in processing load associated with the processing can be prevented.

(First embodiment)
A multiplexed database system according to a first embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram illustrating the overall configuration of a multiplexed database system according to the present embodiment.

  As shown in FIG. 1, this multiplexed database system is a system in which a plurality of database servers (hereinafter referred to as “servers”) 100 and an intermediary device 200 are connected by a network 300, and one or more database servers are connected via the network 400. It is accessed from a client computer (hereinafter referred to as “client”) 500 and a database match checking device 600. In the present embodiment, as shown in FIG. 1, two servers 100a and 100b are provided and accessed from two clients 500a and 500b. In the following description, when each server 100 is distinguished from other servers 100, subscripts “a” and “b” are added. The same applies to the client 500. In the example of FIG. 1, the server 100 and the client 500 are connected to different networks 300 and 400, respectively, but may be connected to the same network.

  As shown in FIG. 1, the intermediary device 200 has an IP address 172.17.1.1 on the network 400 side, and discloses this as the IP address of the database server. When the client 500 or the database match checking device 600 wants to access the database, it sends a query to the IP address 172.17.1.1, and receives a response packet to the query from the intermediary device 200 with the IP address 172.17.1.1. This is the same as sending / receiving a packet to / from the database server having the IP address 172.17.1.1 for the client 500 or the like. A virtual database server having this IP address 172.17.1.1 is called a virtual server 800. The purpose of the virtual server 800 is to conceal that the server 100 is redundant. That is, whether both the server 100a and the server 100b are operating, whether the server 100b is down and only the server 100a is operating, whether a new server is added in addition to the server 100a and the server 100b, the client is not affected. There is no need to change the operation.

  The server 100 includes a database 101 that stores and manages data. Further, the server 100 restarts in response to an instruction from the outside such as the mediation apparatus 200. When the server 100 is restarted, the database 101 is started.

  The database 101 is an RDBMS (Relational Database Management System) that performs processing by solving SQL (Structured Query Language). There are various types of such databases 101, for example, PostSQL (http://www.postgres.org/) by The PostgreSQL Global Development Group, Oracle (registered trademark) by Oracle (http: // www. oracle.com/). In the present embodiment, PostgreSQL is used as the database 101.

  In addition, the database 101 has functions of creating a snapshot and restoring the database from the snapshot from another terminal via the network. This function is normally provided as a function related to maintenance of the database 101. For example, in PostgreSQL, tools pg_dump and psql are prepared, and by using these tools, it is possible to acquire a snapshot from another terminal and restore from the snapshot. Here, the snapshot means replicated data of the entire database or data necessary for restoring the database. In general, whether or not uncommitted data is included in a snapshot at the start of snapshot creation, whether or not a query can be processed during snapshot creation, and the like depend on the specifications of the database 101. In this embodiment, it is assumed that only the data committed at the start of snapshot creation is reflected in the snapshot, that is, the contents of the query committed after the start of snapshot creation is not reflected in the snapshot. To do.

  As shown in FIG. 2, the intermediary device 200 includes a server management table 201 that manages the server 100 in this system, a transaction management table 202 that manages transactions, and a transmission queue 203 that temporarily stores queries to be transmitted to the server 100 The query received from the client 500 is input to the transmission queue 203, the query is extracted from the transmission queue 203 and transmitted to the server 100, and the query transmission processor 205 transmits the query. A legitimacy determination unit 206 that determines the legitimacy of a response from each server 100 to the query, a response transmission processing unit 207 that transmits a response determined to be legitimate by the legitimacy determination unit 206 to the requesting client 500, A synchronization processing control unit 208 that controls the synchronization processing between the servers 100; And a snapshot storage unit 209 for temporarily storing a snapshot of the database 101 obtained from the server 100 during the synchronization process.

  The server management table 201 stores state information indicating whether the server is operating normally and whether the query can be processed (active) or whether the synchronization process is being performed (sync). When the server 100 is disconnected from the system, the entry for the server 100 is deleted from the server management table 201. FIG. 3 shows an example of the server management table. As shown in FIG. 3, the server management table 201 is composed of a server ID for identifying the server 100 and an operating state of the server. In the example of FIG. 3, the server 100 a and the server 100 b are registered, and the operation state is “active” indicating both normal operation. In this embodiment, the IP address assigned to the server 100 is used as the server ID.

  The transaction management table 202 stores the presence / absence of a transaction that is currently being executed or whose execution has been suspended. FIG. 4 shows an example of the transaction management table 202. As shown in FIG. 4, the transaction management table 202 includes a client ID for uniquely identifying a client and a transaction ID for uniquely identifying a transaction. These pairs are registered in the transaction management table 202 by the reception query processing unit 204 at the start of the transaction, and deleted from the transaction management table 202 by the response transmission processing unit 207 at the end of the transaction. The client ID is an IP address or a port number of the client 500, for example. The transaction ID is newly allocated by the reception query processing unit 204 every time a new transaction occurs.

  The transmission queue 203 has a function as a transmission buffer when transmitting a query received from the client 500 or the like to the server 100, and also has a function of storing and storing the query received from the client 500 during the synchronization process as difference information. Is.

  The data structure of the transmission queue 203 will be described with reference to FIG. The transmission queue 203 stores the contents of the query received from the client 500, the transaction ID to which the query belongs, and the transmission state to each server 100. The transaction ID is acquired from the transaction management table 202. The transmission state to each server 100 is stored for each server 100 belonging to the system.

  The transmission status of the transmission queue 203 to each server 100 can take four values: “untransmitted”, “transmission complete”, “hold”, and “hold release”. “Non-transmission” is a state in which the transmission is scheduled to be made to the server 100 without being suspended, but has not been transmitted yet. “Transmission complete” is a state in which transmission to the server 100 is completed. “Hold” is a state where the server 100 is held without being transferred to the server 100 during the process of incorporating the server 100 into the system. “Release hold” is a state where the “hold” state is released but not transmitted. Each entry in the transmission queue 203 is deleted from the transmission queue 203 when the transmission state for all the servers 100 is “transmission complete” and the transaction to which the query belongs is completed.

  When receiving a query from the client 500 via the network 400, the received query processing unit 204 analyzes the query and detects the start of a new transaction, and registers the transaction in the transaction management table 202 and server management. Referring to the table 201, the reception query is input to the transmission queue 203.

  The method by which the received query processing unit 204 detects the start of a new transaction differs depending on the type of DBMS. For example, in the case of the above PostgreSQL, the start of the transaction is when the client 500 or the like transmits an SQL “BEGIN”, and the end of the transaction is when the client 500 or the like transmits an SQL “COMMIT” or “ROLLBACK”. . In the case of Oracle, the transaction starts when the client 500 or the like transmits a valid SQL (there is no SQL for declaring the explicit start of the transaction), and the end of the transaction is “COMMIT” by the client 500 or the like. This is a time when SQL “ROLLBACK” is transmitted. In addition, when the server 100 operates in the AUTO COMMIT mode, each SQL sentence received from the client 500 or the like can be interpreted as belonging to one independent transaction, so that every time an SQL is received from the client 500 or the like, It can be treated that the transaction is started before the SQL execution and the transaction is ended after the SQL execution.

  When the reception query processing unit 204 puts a reception query into the transmission queue 203, the transmission state for each server 100 is set as follows. When the server operating state of the server management table 201 is “active”, the transmission state of the server 100 is set to “untransmitted”. When the server operating state of the server management table 201 is “sync” and the query transfer process for the server 100 has not yet started, the transmission state of the server 100 is set to “hold”. . In other words, in the present embodiment, the difference information is accumulated by storing the received query as “hold” in the transmission queue 203. When the server operating state of the server management table 201 is “sync” and the query transfer process for the server 100 has started, the transmission state of the server 100 is set to “hold release”. .

  The query transmission processing unit 205 monitors the transmission queue 203, extracts queries in the transmission queue 203 whose transmission status is “untransmitted” or “hold release” from the oldest one to the target server 100. The transmission state of the transmission queue 203 is updated to “transmission complete”.

  The validity determination unit 206 receives a response to the query transmitted to each server 100 by the query transmission processing unit 205 and determines the validity of the response. This validity determination is for determining the validity of query processing between one or more servers 100. Specifically, when there are three or more servers 100, there are a method of deciding by majority vote, and a method of judging a received response based on a predetermined rule. For example, when a response “update successful” is returned in response to a “reference” request from the client 500, such a response is not possible if it is normal (it should be a response related to reference such as successful reference). Judge that the response is not correct. Also, if there is a data length field in the packet related to the response, the value of this data length field is compared with the actually received packet length, and if they are different, it is determined that they are not correct. Further, one Master server is determined in advance from the plurality of servers 100, and it is determined that the response from this server 100 is always correct. There is also a method using a combination of the above methods. For example, as a result of performing a majority decision with three units, the contents of the responses are all disjoint, and if the majority response cannot be determined, it is determined that the master server response is correct. If only one server 100 is operating normally, it is determined that the response from that server 100 is normal. The number of servers 100 that are operating normally can be recognized by referring to the server management table 201. When the correctness determination unit 206 detects the server 100 that returned an invalid response as a result of the correctness determination, the correctness determination unit 206 deletes the entry for the server 100 from the server management table 201 and the transmission queue 203 and Send a restart instruction. As a result, the query is not transmitted to the server 100, so that the server 100 is disconnected from the system. In addition, the server 100 performs a restart process in response to the restart instruction.

  The response transmission processing unit 207 is a response that is determined to be valid by the validity determination unit 206, and when the operating state of the transmission source server 100 of the response is “active”, one of the responses is sent to the processing request source. Return to the client 500 or the like. In addition, the response transmission processing unit 207 detects whether the response received from the server 100 is related to the end of the transaction. If the response is related to the end of the transaction, the response transmission processing unit 207 displays an entry about the transaction. Delete from 202. Further, the response transmission processing unit 207 deletes, from the transmission queue 203, a query that belongs to the completed transaction and in which the transmission state of all the servers 100 is “transmission complete”. In addition, when the “hold release” query disappears from the transmission queue 203, the response transmission processing unit 207 sets the operation state of the server management table 201 to “active” for the server 100 that has been “hold release”. Update. Thereby, the server 100 is incorporated into the system. It should be noted that the timing of incorporation into the system may be during execution of a query in the normally operating server 100, or the transaction may be ongoing.

  The synchronization processing control unit 208 performs synchronization processing between the new server 100 and a server that is operating normally in the system when the server 100 outside the system (referred to here as “new server 100” for convenience) is incorporated into the system. To control. Here, the new server 100 includes both a server that is newly added to the system and a server that is once disconnected from the system and incorporated into the system again.

  When detecting the input of the database synchronization request (system integration request), the synchronization processing control unit 208 (1) sets the operation state of the new server 100 to “sync” and adds it to the server management table 201 (2 ) A column for the new server 100 is added to the transmission status column of the transmission queue 203. (3) One server for synchronization processing is selected from the servers 100 operating normally and the server 100 is selected. If the transmission status of the transmission queue 203 is “unsent”, it is updated to “pending”. (4) The server 100 for synchronization processing waits until the processing of the query being executed is completed, and the synchronization processing When the processing of the query being executed in the server 100 is completed, a snapshot of the server 100 is acquired and stored in the snapshot storage unit 209 To start the management, carry out the process of. In the present embodiment, it is assumed that the database synchronization request is a predetermined input device (not shown) after the operator confirms the completion of restart of the new server 100.

  Also, the synchronization processing control unit 208 handles the processes from (1) to (4) from the start of snapshot creation as one process and performs exclusive control in order to maintain data consistency. In other words, the synchronization processing control unit 208 performs the processing from (1) to (4) on the server management table 201 and the transmission queue 203 accessed in each processing while performing the processing from the start of snapshot creation to (4). Access from other functional blocks (for example, the received query processing unit 204) is interrupted.

  When the query remains in the transmission queue 203 in (2), the synchronization processing control unit 208 sets all the transmission states of the new server 100 for the query to “pending”. As described above, the entry in the transmission queue 203 is deleted when the transaction ends. Therefore, the query remaining in the transmission queue 203 is a query whose transaction has not ended, and is not reflected in the snapshot created in (4). In the process (2), the transmission state for this query is set to “pending”, and the query is held as difference information.

  Further, the synchronization processing control unit 208 (5) restores the database 101 of the new server 100 from the snapshot when the creation of the snapshot is completed, and (6) stores the data in the transmission queue 203 when the restoration of the database 101 is completed. The transmission state is changed from “hold” to “hold release” for all the queries in the new server 100 column. As a result, the query transmission processing unit 205 starts transmitting a query as difference information to the new server 100. When the processing of the query that has been “hold release” is completed, the response transmission processing unit 207 updates the operating state of the server management table 201 to “active” for the new server 100, so that the new server 100 Built into the system.

  The client 500 issues an update query (request to update the database) and a reference query (request to refer to the contents of the database) to the multiplexed database system.

  Similar to the client 500, the database match checking device 600 operates as a client of the multiplexed database system, and issues a query for checking whether or not the databases 101 of the servers 100 match each other. This query is of the reference system, and is, for example, “SELECT * FROM test_table” for a predetermined table test_table. The database coincidence inspection apparatus 600 issues the inspection query periodically or in response to an instruction from an operator or the like.

  Next, the operation of the multiplexed database system according to the present embodiment will be described with reference to the drawings. First, the operation when the servers 100a and 100b are operating normally will be described with reference to FIGS.

  In the initial state, the databases 101a and 101b are completely the same, and the server management table 201 is as shown in FIG. Further, it is assumed that the transaction management table 202 and the transmission queue 203 are empty. Assume that a table test_table exists in each of the servers 100a and 100b.

  When the client 500a transmits a packet including the transaction start SQL address to 172.17.1.1, the reception query processing unit 204 of the mediation apparatus 200 receives the packet (step S1). The reception query processing unit 204 detects that a transaction has started, and registers the IP address and transaction number of the client 500a in the transaction management table 202 (step S2). FIG. 8 shows the transaction management table 202 at this time. Then, the query related to this packet is placed in the transmission queue 203 with the transmission state set to “untransmitted” for the server 100 (in this case, the servers 100 a and 100 b) operating normally with reference to the server management table 201.

  The query transmission processing unit 205 extracts a query whose transmission state is “untransmitted” from the transmission queue 203 and transmits the packet to the corresponding server 100. Here, since the servers 100a and 100b are operating normally, the packets are transferred to the server 100a and the server 100b (steps S3 and S4, respectively). Since transmission to each server 100 is completed, the transmission state of the transmission queue 203 for each server 100 is updated to “transmission complete”. The correctness determination unit 206 receives a response packet notifying that the transaction has started normally from the server 100a (step S5), but at this point in time, all the response packets are not yet complete ( In this case, the response packet from the server 100b has not arrived), and the validity determination unit 206 does nothing and waits for the response packet from the server 100b. When a response packet notifying that the transaction has started normally is received from the server 100b (step S6), since all the response packets have been prepared, the validity determination unit 206 compares the response packets with each other. Thus, it is checked whether or not a failure has occurred in the server 100 (step S7). In this case, since both of the two response packets are packets indicating that the transaction has started normally, it is determined that there is no failure. Then, the response transmission processing unit 207 returns one of the valid response packets to the client 500a (Step S8).

  Next, the client 500a transmits to 172.17.1.1 a packet including SQL (UPDATE) for updating the table test_table (step S9). The reception query processing unit 204 refers to the server management table 201 and sets the transmission state of the normally operating server 100 to “untransmitted” and puts it in the transmission queue 203. The query transmission processing unit 205 extracts the query from the transmission queue 203, transfers the packet to each server 100 (steps S10 and S11, respectively), and updates the transmission state of the transmission queue 203 to “transmission completed”. The server 100a transmits a response packet notifying that UPDATE has been successfully completed to the mediation apparatus 200, and the validity determination unit 206 of the mediation apparatus 200 receives the response packet (step S12). At this time, not all response packets are prepared, and the validity determination unit 206 waits without doing anything. When a response packet notifying that UPDATE has been successfully received is received from the server 100b (step S13), since all the response packets are now prepared, the validity determination unit 206 compares the response packets with each other, thereby It is checked whether a failure has occurred in 100 (step S14). In this case, since both of the two response packets are packets indicating that UPDATE was successful, it is determined that there is no failure. Then, the response transmission processing unit 207 transfers one valid response packet to the client 500a (step S15).

  Next, the client 500a transmits to 172.17.1.1 a packet including SQL (COMMIT) that confirms the update to the table test_table (actually updates the database) (step S16). The reception query processing unit 204 refers to the server management table 201 and sets the transmission state of the normally operating server 100 to “untransmitted” and puts it in the transmission queue 203. The query transmission processing unit 205 retrieves the query from the transmission queue 203, transfers the packet to each server 100 (steps S17 and S18, respectively), and updates the transmission state of the transmission queue 203 to “transmission completed”. The server 100a transmits a packet notifying that the COMMIT has been successful to the mediation device 200, and the validity determination unit 206 of the mediation device 200 receives this response packet (step S19). At this time, not all response packets are prepared, and the validity determination unit 206 waits without doing anything. When the response packet notifying that the COMMIT has been successfully received is received from the server 100b (step S20), since all the response packets are now prepared, the validity determination unit 206 compares the response packets with each other to determine the server. It is checked whether a failure has occurred in 100 (step S21). In this case, since the two response packets are packets indicating that the COMMIT has succeeded, it is determined that there is no failure. The response transmission processing unit 207 transfers one of the valid response packets to the client 500a (Step S22). In addition, since the COMMIT has been completed normally, it can be seen that the transaction has ended. Therefore, the response transmission processing unit 207 deletes the registration of the transaction from the transaction management table 202 (step S23) and transmits to all the servers 100. Queries whose status is “transmission completed” (here, three queries “BEGIN”, “UPDATE”, and “COMMIT”) are deleted from the transmission queue 203 (step S23). At this time, the transaction management table 202 and the transmission queue 203 are again in the initial state (that is, empty).

  Next, an operation when the server 100b becomes a failure due to a failure or the like will be described with reference to FIGS. In the initial state, it is assumed that the databases 101a and 101b are completely the same, and the server management table 201 is as shown in FIG. Further, it is assumed that the transaction management table 202 and the transmission queue 203 are empty.

  When the client 500a transmits a packet including a transaction start SQL (BEGIN) addressed to 172.17.1.1, the reception query processing unit 204 of the mediation apparatus 200 receives the packet (step S30). The reception query processing unit 204 detects that a transaction has started, and registers the IP address and transaction number of the client 500a in the transaction management table 202 (step S31). FIG. 10 shows the transaction management table 202 at this time. Then, the query relating to this packet is placed in the transmission queue 203 with the transmission state “unsent” for the server 100 operating normally with reference to the server management table 201.

  The query transmission processing unit 205 extracts a query whose transmission state is “untransmitted” from the transmission queue 203 and transfers the packet to each corresponding server 100 (steps S32 and S33, respectively). Next, the transmission state of the transmission queue 203 is updated to “transmission completed”. The legitimacy determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the transaction has started normally from the server 100a (step S34), but at this point, all the response packets are still ready. (In this case, the response packet from the server 100b does not come), and nothing is done to wait for the response packet from the server 100b. Then, when a response packet notifying that the transaction has been started normally is received from the server 100b (step S35), since all the response packets are now prepared, the validity judgment unit 206 compares the response packets with each other. Thus, it is checked whether or not a failure has occurred in the server 100 (step S36). In this case, since both of the two response packets are packets indicating that the transaction has started normally, it is determined that there is no failure. Then, the response transmission processing unit 207 transfers one of the valid response packets to the client 500a (Step S37).

  Here, it is assumed that the server 100b is down due to a failure such as a failure after returning the response packet in step S35 (step S38).

  Next, the client 500a transmits a packet containing SQL (UPDATE) for updating the table test_table to 172.17.1.1 (step S39). The reception query processing unit 204 refers to the server management table 201 and sets the transmission state of the normally operating server 100 to “untransmitted” and puts it in the transmission queue 203. At this point, since the mediation apparatus 200 does not know that the server 100b is down, the information that the server 100b is operating normally remains stored in the server management table 201. Therefore, the reception query processing unit 204 stores the reception query in the transmission queue 203 by setting the transmission state to “untransmitted” not only in the field of the server 100 a but also in the field of the server 100 b. The query transmission processing unit 205 extracts a query whose transmission state is “untransmitted” from the transmission queue 203 and transfers the packet to each of the servers 100a and 100b (steps S40 and S41, respectively). Next, the query transmission processing unit 205 updates the transmission state of the transmission queue 203 to “transmission complete”. The server 100a transmits a response packet notifying that UPDATE has been successfully completed to the mediation device 200, and the validity determination unit 206 of the mediation device 200 receives the response packet (step S42). At this point in time, not all response packets are available, so the validity determination unit 206 waits without doing anything. However, since the server 100b is down, the response packet from the server 100b does not reach the correctness determination unit 206 indefinitely. As a result, the validity determination unit 206 times out and detects that the server 100b is down. Then, the validity judgment unit 206 deletes the entry of the server 100b from the server management table 201 (step S43). The server management table 201 at this time is shown in FIG. Also, the transmission status column for the server 100 b is deleted from the transmission queue 203. The transmission queue 203 at this time is shown in FIG. Next, the response transmission processing unit 207 transfers the response packet to the client 500a (step S44). Here, it should be noted that the client 500a does not recognize whether the server 100b has failed, and can receive services from the virtual server 800 as before.

  Next, the client 500a transmits, to 172.17.1.1, a packet including SQL (COMMIT) for confirming update to the table test_table (step S45). The reception query processing unit 204 refers to the server management table 201 and sets the transmission state of the normally operating server 100 to “untransmitted” and puts it in the transmission queue 203. Here, the query is stored in the transmission queue 203 with the transmission state “unsent” only for the server 100a. Then, the query transmission processing unit 205 extracts the query from the transmission queue 203, and transfers the packet only to the corresponding server, in this case, the server 100a (step S46). Next, the transmission state of the transmission queue 203 is updated to “transmission completed”. The server 100a transmits a response packet notifying that the COMMIT has succeeded normally, and the validity determination unit 206 of the mediation apparatus 200 receives this response packet (step S47). Here, since only one server 100 is operating normally, the validity determination unit 206 determines that the response packet is valid, and the response transmission processing unit 207 transfers the response packet to the client 500a (step S48). In addition, since the COMMIT has been completed normally, it can be seen that the transaction has ended. Therefore, the response transmission processing unit 207 deletes the registration of the transaction from the transaction management table 202 (step S49), and transmits to all the servers 100. Queries whose status is "transmission complete" (here, three queries "BEGIN", "UPDATE", and "COMMIT") are deleted from the transmission queue 203 (step S50). At this time, the transaction management table 202 and the transmission queue 203 are again in the initial state (that is, empty).

  Next, a case where the processing order in each server 100 is different for a plurality of transactions processed in parallel will be described with reference to the sequence charts of FIGS. 13 and 14.

  Here, it is assumed that the two servers 100a and 100b that are operating normally process a query from each client 500. In the initial state, the databases 101a and 101b are completely the same, and the server management table 201 is as shown in FIG. Further, it is assumed that the transaction management table 202 and the transmission queue 203 are empty. Assume that a table test_table exists in each of the servers 100a and 100b. Then, it is assumed that the client 500a issues the transaction T1 in FIG. 52 and the client Tb issues the transaction T2 in FIG. 52 to the table test_table in FIG. As described above, it should be noted that the data in the database 101 after the processing of these two transactions T1 and T2 has different contents depending on the processing order of each transaction.

  Here, in order to explain the database inconsistency in the query processing order and the rough flow of the solution, the update operation of the server management table 201, the input / output of queries to the transmission queue 203, the update of the transaction management table 202 Detailed operations of each part of the mediation apparatus 200, such as operations, are omitted.

  As shown in FIG. 13, the client 500a transmits a query (BEGIN) for starting a transaction T1 to the mediation apparatus 200 (step S101), while the client 500b sends a query (BEGIN) for starting a transaction T2 to the mediation apparatus 200. Transmit (step S102). The mediation apparatus 200 transfers each query to the servers 100a and 100b that are operating normally (steps S103 to S106). Then, the legitimacy of the responses (steps S107 to S110) from the respective servers 100a and 100b is checked (not shown), and one of the legitimate responses is transferred to the requesting client 500a or 500b (step S111). To S112).

  The clients 500a and 500b that have received a response to BEGIN from the mediation device 200 transmit the next query belonging to each transaction to the mediation device 200. In the present embodiment, the client 500a transmits an UPDATE query for transaction T1 to the mediation apparatus 200 (step S113), and the client 500b transmits an UPDATE query for transaction T2 to the mediation apparatus 200 (step S114). The mediation apparatus 200 that has received the query from the clients 500a and 500b transfers the query to the servers 100a and 100b that are operating normally (steps S115 to S118).

  In the server 100a, it is assumed that the UPDATE query of the transaction T1 is processed before the UPDATE query of the transaction T2. The server 100a that has processed the UPDATE query of the transaction T1 transmits the processing result to the mediation apparatus 200 (step S119). At this time, the update target row of test_table by the UPDATE query of transaction T1 is locked until transaction T1 is committed. In the UPDATE query of transaction T2, the locked row is an update target, so the processing of the query is suspended until the lock is released (step S120).

  On the other hand, in the server 100b, it is assumed that the UPDATE query for transaction T2 is processed before the UPDATE query for transaction T1. The server 100b that has processed the UPDATE query of the transaction T2 transmits the processing result to the mediation apparatus 200 (step S121). At this time, the update target row of test_table by the UPDATE query of transaction T2 is locked until transaction T2 is committed. In the UPDATE query of the transaction T1, since the locked row is an update target, the processing of the query is suspended until the lock is released (step S122).

  Here, it is assumed that the response to the UPDATE query of the transaction T1 from the server 100a (step S119) reaches the mediation apparatus 200 before the response to the UPDATE query of the transaction T2 from the server 100b (step S121).

  The intermediary device 200 has received a response for the UPDATE query of the transaction T1 from one server 100a (step S119), but has not received a response from the other server 100b, and waits for the response (step S123). As described above, this is because the intermediary device 200 compares the responses from the servers 100a and 100b with each other to determine the validity. Similarly, the intermediary device 200 receives a response to the UPDATE query of the transaction T2 from one server 100b (step S121), but has not received a response from the other server 100a, and waits for the response (step S124). ).

  As described above, since the UPDATE query processing of the transaction T1 is waiting for unlocking in the server 100b (step S122), the response waiting for the query (step S123) in the mediating apparatus 200 times out (step S125). As a result, the intermediary device 200 determines that the server 100b has failed, cancels waiting for a response in step S124, and disconnects the server 100b from the system (step S126). Specifically, the entry of the server 100b is deleted from the server management table 201, and the transmission status column of the server 100b is deleted from the transmission queue 203. Then, as shown in FIG. 14, the mediating apparatus 200 transmits a restart instruction to the server 100b separated from the system (step S127), and returns a response to the client 500a (step S128).

  When receiving the restart instruction from the mediation apparatus 200, the server 100b starts its own restart (step S129).

  The client 500a that has received the response for the UPDATE query of the transaction T1 transmits a query (COMMIT) for confirming the update to the mediation apparatus 200 (step S130). When receiving the query from the client 500a, the mediation device 200 refers to the server management table 201 and transfers the query to the normally operating server 100a (step S131).

  In the server 100a, the lock is released by processing the COMMIT query of the transaction T1, and the processing of the transaction T2 can be resumed (step S132). As a result, the server 100a returns a response to the COMMIT query of the transaction T1 to the mediation device 200 (step S133), and the mediation device 200 transfers the response to the client 500a (step S134). Next, the server 100a returns a response to the UPDATE query of the transaction T2 to the mediation device 200 (step S135), and the mediation device 200 transfers the response to the client 500b (step S136).

  The client 500b that has received the response for the UPDATE query of the transaction T2 transmits a query (COMMIT) for confirming the update to the mediation apparatus 200 (step S137). When receiving the query from the client 500b, the mediation device 200 refers to the server management table 201 and transfers the query to the normally operating server 100a (step S138). The server 100a processes the query and returns a response to the mediation device 200 (step S139), and the mediation device 200 transfers the response to the client 500b (step S140).

  Here, it is assumed that the restart of the server 100b disconnected from the system is completed (step S141). When the operator of the mediation device 200 confirms the completion of the restart of the server 100b, the operator instructs the mediation device 200 to input a database synchronization request (step S142). The intermediary device 200 performs a process of synchronizing the database 101a of the normally operating server 100a and the database 101b of the server 100b (step S143). Details of this synchronization processing will be described later. When the synchronization process is completed, the mediation apparatus 200 incorporates the server 100b into the system again (step S144). Details of the incorporation processing into the system will be described later together with details of the synchronization processing in step S143.

  With the above processing, the synchronization of the database 101 is maintained between the servers 100 even if the processing order of the servers 100 is different for a plurality of transactions processed in parallel.

  Next, another example of a plurality of transactions processed in parallel when the processing order in each server 100 is different will be described with reference to the sequence charts of FIGS. 15 and 16.

  Here, it is assumed that the two servers 100a and 100b that are operating normally process a query from each client 500. In the initial state, the databases 101a and 101b are completely the same, and the server management table 201 is as shown in FIG. Further, it is assumed that the transaction management table 202 and the transmission queue 203 are empty. Assume that a table test_table exists in each of the servers 100a and 100b. Then, it is assumed that the client 500a issues the transaction T3 in FIG. 53 and the client Tb issues the transaction T4 in FIG. 53 to the table test_table in FIG. As described above, the data in the database 101 after the processing of the two transactions T3 and T4 is not affected by the processing order of each transaction. However, as described above, it should be noted that the result of SELECT in the transaction T4 differs depending on the processing order of the transactions T3 and T4.

  Here, in order to explain the database inconsistency in the query processing order and the rough flow of the solution, the update operation of the server management table 201, the input / output of queries to the transmission queue 203, the update of the transaction management table 202 Detailed operations of each part of the mediation apparatus 200, such as operations, are omitted.

  As illustrated in FIG. 15, when the client 500a transmits a query (BEGIN) for starting a transaction T3 to the mediation device 200 (step S201), the mediation device 200 refers to the server management table 201 and the normally operating server 100a. And 100b (steps S202 and S203). When the intermediary device 200 receives a response from each of the servers 100a and 100b (steps S204 and S205), it transfers one of the valid responses to the client 500a (step S206).

  Next, the client 500a transmits an update query (UPDATE) of the transaction T3 to the mediation apparatus 200 (step S207). On the other hand, the client 500b transmits a query (BEGIN) for starting the transaction T4 to the mediation apparatus 200 (step S208).

  The intermediary device 200 transfers the UPDATE query of the transaction T3 to the servers 100a and 100b that are operating normally (steps S209 and S210), and transfers the BEGIN query of the transaction T4 to the servers 100a and 100b that are operating normally (step S211). , S212). When the intermediary device 200 receives a response to the UPDATE query of the transaction T3 from each of the servers 100a and 100b (steps S213 and S214), it transfers one of the valid responses to the client 500a (step S215). When a response to the BEGIN query of transaction T4 is received from each of the servers 100a and 100b (steps S216 and S217), one of the valid responses is transferred to the client 500b (step S218).

  Next, the client 500a transmits a query (COMMIT) for confirming the transaction T3 to the mediation apparatus 200 (step S219). On the other hand, the client 500b transmits a reference query (SELECT) of the transaction T4 to the mediation apparatus 200 (step S220).

  The intermediary device 200 transfers the COMMIT query of the transaction T3 to the servers 100a and 100b that are operating normally (steps S221 and S222), and transfers the SELECT query of the transaction T4 to the servers 100a and 100b that are operating normally (step S223). , S224).

  Here, in one server 100a, the COMMIT query of the transaction T3 is processed before the SELECT query of the transaction T4 (steps S225 and S226), and in the other server 100b, the SELECT query of the transaction T4 is processed from the COMMIT query of the transaction T3. Assume that the processing has been performed first (steps S227 and S228). As a result, it is assumed that the response of the SELECT query of transaction T4 is different from the response from the server 100a (step S226) and the response from the server 100b (step S227).

  Since the response to the SELECT query of the transaction T4 is inconsistent between the servers 100a and 100b, the intermediary device 200 selects one of the servers 100a or 100b and validates the response from the selected server 100a or 100b. (Step S229). Here, as a selection method of the server 100, for example, a master server is determined in advance, a method of selecting the master server, a method of selecting a server that first returned a response, and selecting a selected server sequentially by round robin. A method, a method of selecting at random, a method of selecting according to the processing capacity and processing load of each server, and the like can be mentioned. In this embodiment, the server 100a is selected as the master server, and the server 100a is selected as the server that returned a valid response. The mediation device 200 disconnects the server 100b that has returned an invalid response from the system (step S230). Specifically, the entry of the server 100b is deleted from the server management table 201, and the transmission status column of the server 100b is deleted from the transmission queue 203. Then, as shown in FIG. 16, a restart instruction is transmitted to the server 100b (step S231).

  When receiving the restart instruction from the mediation apparatus 200, the server 100b starts its own restart (step S232).

  The mediation apparatus 200 transfers the response to the COMMIT query of the transaction T3 and the response to the SELECT query of the transaction T4 received from the selected server 100a, respectively, to the requesting clients 500a and 500b (steps S233 and S234). Thereafter, queries from the clients 500a and 500b are processed by the normally operating server 100a. In the example of FIG. 16, when the client 500b transmits a COMMIT query of transaction T4 to the mediation apparatus 200 (step S235), the mediation apparatus 200 transfers the query to the normally operating server 100a (step S236). When receiving a response to the query from the server 100a (step S237), the mediation apparatus 200 returns this response to the requesting client 500b (step S238).

  Here, it is assumed that the restart of the server 100b disconnected from the system is completed (step S239). When the operator of the mediation device 200 confirms the completion of the restart of the server 100b, the operator instructs the mediation device 200 to input a database synchronization request (step S240). The intermediary device 200 performs a process of synchronizing the database 101a of the normally operating server 100a and the database 101b of the server 100b (step S241). Details of this synchronization processing will be described later. When the synchronization process is completed, the mediation apparatus 200 incorporates the server 100b into the system again (step S242). Details of the incorporation processing into the system will be described later together with details of the synchronization processing in step S241.

  With the above processing, even if the processing order in each server 100 is different for a plurality of transactions processed in parallel, only one correct response is returned to the client 500 as a processing result.

  In this example, even if the processing order of the queries belonging to the two transactions T3 and T4 is different, there is no query that updates the same row among the queries belonging to the transactions T3 and T4. There is no inconsistency between the databases 101 due to the difference. Therefore, considering only this example, it is considered that each process (steps S230 to S232, S239 to S242) for synchronizing the database 101 is unnecessary. However, in the present embodiment, the synchronization of the database 101 is performed so that it is possible to deal with the case where inconsistency is latent in the database 101 for some reason and the inconsistency is detected in response to the step S229. Each process for conversion was carried out. Further, in this example, the result mismatch due to the mismatch between the SELECT and UPDATE orders has been described. However, there may be a mismatch between results such as SELECT FOR UPDATE in the reference system and DELETE in the updater. In this embodiment, even in such a case, inconsistency of the database 101 can be resolved by performing the same processing as the sequence described with reference to FIGS. 15 and 16.

  Next, details of the synchronization processing in steps S143 and S241 will be described. In the synchronization process according to the present invention, the mediation apparatus 200 acquires a snapshot of the database 101 from the server 100 that is operating normally at the start of the synchronization process, and restores the database 101 of the new server 100 using this snapshot. . Further, the query from the client 500 received during this process is accumulated as difference information in the mediation apparatus 200. This difference information is accumulated using the transmission queue 203. When the new server 100 completes the restoration of the database 101 from the snapshot, the difference information is acquired from the mediation apparatus 200 and the difference information is processed.

  Note that the implementation of the synchronization process is not limited to the restart according to the restart instruction from the mediation apparatus 200. That is, it is also performed when the server 100 is disconnected from the system due to a failure and then re-installed in the system. It is also implemented when adding more servers that make up the system.

  Hereinafter, the synchronization operation when the server 100b is incorporated into the system will be described with reference to FIGS. The point to be noted at this time is to add the server 100b while continuing the service to the clients 500a and 500b, that is, to synchronize the databases 101a and 101b without bringing down the system.

  The database 101b is not synchronized with the database 101a, that is, is not identical. For example, the database 101b may hold data immediately before restart or data immediately before the occurrence of a failure, or may not have any data in the case of a completely new server. In the present invention, even in the former case, old data is deleted, and the database 101b is incorporated into the system assuming that no data is held. That is, it is not necessary to keep old data.

  Here, since only the server 100a is operating normally, it is assumed that the server management table 201 is as shown in FIG. The transaction management table 202 is assumed to be empty. Further, the transmission queue 203 is empty, and the transmission state is stored only for the server 100a that is operating normally.

  As illustrated in FIG. 17, when the client 500a transmits a packet including the transaction start SQL (BEGIN) addressed to 172.17.1.1, the reception query processing unit 204 of the mediation apparatus 200 receives the packet (step S301). The reception query processing unit 204 detects that a transaction has started, and registers the IP address and transaction number of the client 500a in the transaction management table 202 (step S302). FIG. 21 shows the transaction management table 202 at this time. The reception query processing unit 204 refers to the server management table 201 and sets the transmission state to “untransmitted” for the normally operating server 100a and puts the reception query into the transmission queue 203 (step S303). The query transmission processing unit 205 extracts the query from the transmission queue 203, transfers it to the corresponding server 100a (step S304), and updates the transmission state of the transmission queue 203 to “transmission completed” (step S305). When the legitimacy determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the transaction has started normally from the server 100a (step S306), since only one server 100 is operating normally here, The response transmission processing unit 207 determines that the response packet is valid, and transfers the response packet to the client 500a (step S307). The transmission queue 203 at this time is shown in FIG.

  Next, when the client 500a transmits a packet including SQL (UPDATE) for updating the table test_table to 172.17.1.1, the reception query processing unit 204 of the mediation apparatus 200 receives the packet (step S308). The reception query processing unit 204 refers to the server management table 201, sets the transmission state of the server 100a operating normally to “untransmitted”, and puts the reception query into the transmission queue 203 (step S309). The transmission queue 203 at this time is shown in FIG.

  Here, it is assumed that the server 100b is restarted (step S310). When the operator of the mediation device 200 confirms that the server 100b has been restarted, the operator instructs the mediation device 200 to input a database synchronization request (step S311).

  When there is a database synchronization request, the synchronization processing control unit 208 refers to the server management table 201 and selects the server 100 for synchronization. Here, since only one server 100 is operating normally, the server 100a is selected. Then, the entry whose transmission state is “untransmitted” for the server 100a in the transmission queue 203 is updated to “pending” (step S312). In addition, after confirming that there is no query being executed in the synchronization server 100a, the synchronization processing control unit 208 adds the operation state of the new server 100b to the server management table 201 with “sync” (step S313). ), A column for the server 100b is added to the transmission status column of the transmission queue 203 (step S314). Here, all the transmission states of the server 100b are set to “hold”. The server management table 201 and the transmission queue 203 at this time are shown in FIGS. Note that the synchronization processing control unit 208 handles the processes in steps S312 to S314 as one process and performs exclusive control. That is, during the processing of steps S312 to S314, the server management table 201 and the transmission queue 203 accessed in each step are sent from other functional blocks (for example, the reception query processing unit 204 and the query transmission processing unit 205). Interrupt access.

  Next, the synchronization processing control unit 208 starts creating a snapshot of the database 101a of the server 100a (step S315). The snapshot is stored in the snapshot storage unit 209. Since PostgreSQL is used as the database 101 in this embodiment, pg_dump is used as a snapshot creation tool.

  As described above, with the snapshot creation tool used in this embodiment, even if a query is executed during snapshot creation, the snapshot is not affected. Therefore, the synchronization processing control unit 208 updates the transmission state of each query in the transmission queue 203 for the synchronization server 100a from “hold” to “hold release” (step S316). The transmission queue 203 at this time is shown in FIG. As a result, the transmission of the query from the transmission queue 203 by the query transmission processing unit 205 is resumed. Specifically, the query transmission processing unit 205 extracts the UPDATE query from the transmission queue 203 and transmits it to the synchronization server 100a (step S317), and updates the transmission state to “transmission completed” (step S318). When the validity determination unit 206 receives from the server 100a a response packet notifying that the query has been normally processed (step S319), the validity determination unit 206 determines that the response packet is valid because only one server 100 is operating normally. The response transmission processing unit 207 transfers the response packet to the client 500a (step S320). The transmission queue 203 at this time is shown in FIG. In addition, since the snapshot creation is started, the query received from the client 500 is put in the transmission queue 203 as “unsent” for the synchronization server 100a and “hold” for the new server 100b.

  Here, it is assumed that the snapshot creation processing has been completed (step S321). When the snapshot creation processing is completed, the synchronization processing control unit 208 starts restoration processing of the database 101b of the new server 100b using the snapshot (step S322). Since PostgreSQL is used as the database 101 in this embodiment, psql is used as a restoration tool from a snapshot.

  As described above, the query received from the client 500 after starting the snapshot creation is put in the transmission queue 203 as “unsent” for the synchronization server 100a and “hold” for the new server 100b. In the example of FIG. 18, upon receipt of the INSERT query from the client 500a (step S323), the received query processing unit 204 is “unsent” for the synchronization server 100a and “hold” for the new server 100b. Is put into the transmission queue 203 (step S324). The transmission queue 203 at this time is shown in FIG. Then, the query transmission processing unit 205 extracts a query whose transmission state is “untransmitted” and transfers the query to the corresponding synchronization server 100a (step S325), and updates the transmission state to “transmission completed”. (Step S326). When the validity determination unit 206 receives from the server 100a a response packet notifying that the query has been normally processed (step S327), the validity determination unit 206 determines that the response packet is valid because only one server 100 is operating normally. The response transmission processing unit 207 transfers the response packet to the client 500a (step S328).

  Here, it is assumed that the restoration process of the database 101b of the new server 100b has been completed (step S329). When the restoration from the snapshot of the database 101b of the new server 100b is completed, the synchronization processing control unit 208 sets the transmission state of the new server 100b to “transmission query 203” as difference information. All queries that are “pending” are updated to the transmission state “pending release” (step S330). The transmission queue 203 at this time is shown in FIG. As a result, transmission of a query as difference information from the transmission queue 203 by the query transmission processing unit 205 is started. Specifically, the query transmission processing unit 205 extracts the BEGIN query from the transmission queue 203 and transmits it to the new server 100b (step S331), and updates the transmission state to “transmission completed” (step S332). The validity determination unit 206 receives from the new server 100b a response packet notifying that the query has been processed normally (step S333). Here, since the response is a query processing response as difference information, the response is not transferred to the client 500.

  The received query processing unit 204 transmits the query received from the client 500 after the start of the difference information transfer with the transmission state “unsent” for the synchronization server 100a and the transmission state “unhold” for the new server 100b. Put it in the queue 203. In the example of FIG. 19, when a COMMIT query is received from the client 500a (step S334), the reception query processing unit 204 sets the transmission state for the synchronization server 100a to “unsent” and the transmission state for the new server 100b. The “hold release” is entered into the transmission queue 203 (step S335). The transmission queue 203 at this time is shown in FIG.

  Thereafter, the query transmission processing unit 205 transmits the query whose transmission status is “untransmitted” and “hold release” to the corresponding server 100 and updates the transmission status to “transmission complete”. For the response to the query whose transmission state is “unsent”, the validity determination unit 206 determines the validity, and the response transmission processing unit 207 sends one of the valid responses to the client 500. return. On the other hand, the response to the query whose transmission state is “hold release” is not transferred to the client 500.

  In the example of FIG. 19, the query transmission processing unit 205 extracts a COMMIT query whose transmission state is “untransmitted” and transfers it to the corresponding synchronization server 100a (step S336), and the transmission state is “transmission complete”. (Step S337). When the validity determination unit 206 receives a response packet notifying that the query has been processed normally from the server 100a (step S338), the validity determination unit 206 determines that the response packet is valid because only one server 100 is operating normally. The response transmission processing unit 207 transfers the response packet to the client 500a (step S339). Further, since the transaction is terminated by the processing of the COMMIT query, the response transmission processing unit 207 deletes the registration of the transaction from the transaction management table 202 (step S340).

  In the example of FIG. 19, the query transmission processing unit 205 sequentially transfers the UPDATE query, the INSERT query, and the COMMIT query whose transmission status is “hold release” as difference information to the new server 100b, and sets the transmission status. The process of updating to “transmission completed” is repeated (steps S341 to S349). When the transmission of the difference information is completed, that is, when there is no query in the transmission queue 203 whose transmission state is “pending release”, the operating state of the server management table 201 for the server 100b is set to “ updated to "active" (step S350). The server management table 201 at this time is shown in FIG. The process in step S350 corresponds to the processes in steps S144 and S242 described above.

  As described above in detail, according to the multiplexed database system according to the present embodiment, even if a plurality of transactions are processed in parallel, there is a possibility that inconsistencies may occur between the databases 101, specifically, When there is no response of the servers 100 due to different query processing orders in each server 100 or inconsistencies in response results between the servers 100, synchronization processing between the databases 101 is executed. Thereby, the synchronization state of each database 101 can be maintained. Even in such a state, only one correct response is returned to the client 500 as a processing result, so that the normal operation of the entire system can be maintained.

  The synchronization process itself is not limited to the server 100 originally incorporated in the system but disconnected from the system due to a failure or the like, but may be a new server 100 for increasing the number of servers in the system. Applicable.

  In the synchronization process, data stored in the transmission queue 203 as difference information in the mediation apparatus 200 starts to accumulate after a synchronization request (system incorporation request) is received. There is no increase in data for conversion. Thereby, the storage capacity of the intermediary device 200 can be saved, and the occurrence of a failure due to the overflow of the storage capacity can be prevented. Further, the server 100 can be arbitrarily disconnected.

  As described above, in the multiplexed database system according to the present embodiment, the server can be arbitrarily incorporated and disconnected, so that a flexible system design can be performed according to requests such as usage and budget.

  In the present embodiment, a case has been described in which processing requests from the clients 500a and 500b are processed by the multiplexed database system. However, processing requests from the database match checking device 600 may be processed in the same manner. This is because the database match checking device 600 is one of the client computers when viewed from the multiplexed database system. Incidentally, as described above, the database match checking device 600 transmits a reference query for database match checking to the mediation device 200 periodically or as necessary. Thereby, even if data inconsistency occurs between the databases 101 for some reason, the inconsistency between the databases 101 is detected by the query, and the synchronization processing is executed. Thereby, the synchronization between the databases 101 can be more reliably achieved.

(Second Embodiment)
A multiplexed database system according to a second embodiment of the present invention will be described with reference to the drawings. This embodiment is different from the first embodiment described above in that the virtual server 800 includes three servers 100 and that the SQL is used as a snapshot creation / restoration root. The point is to use things. More specifically, in the present embodiment and the first embodiment, the synchronization processing when incorporating the server 100 into the system (step S143 in FIG. 14 and step S241 in FIG. 16 in the first embodiment). ) Are different, and other operations are the same. Hereinafter, this synchronization processing will be described in detail.

  In the first embodiment, the synchronization processing control unit 208 uses pg_dump as a snapshot creation tool, which does not affect the snapshot even if a query is executed during the creation of the snapshot. On the other hand, in the present embodiment, the synchronization processing control unit 208 acquires a snapshot by issuing a general query such as SELECT to the database 101, and issues an INSERT query or the like from the snapshot. The database 101 is restored. By adopting such a method, a general-purpose system independent of the type of the database 101 can be constructed.

  By the way, in such a general-purpose snapshot creation and database restoration method, it becomes a problem whether or not an update query processed after the start of snapshot creation is reflected in the snapshot. For this reason, in the system configuration as in the first embodiment, it is necessary to stop query processing while creating a snapshot. This causes a problem that service provision to the client 500 is stopped. Therefore, in the present embodiment, service continuation for the client 500 and snapshot creation are performed by different servers 100 so that service provision to the client 500 is continued. Hereinafter, the operation of the system according to the present embodiment will be described in detail.

  Here, a case where one server 100c among the three servers 100a to 100c is detached from the system and then the server 100c is re-installed in the system will be described with reference to FIGS.

  FIG. 37 shows the server management table 201 in the initial state. The transaction management table 202 is assumed to be empty. The transmission queue 203 is empty and has a structure as shown in FIG.

  As illustrated in FIG. 32, when the client 500a transmits a packet including the transaction start SQL (BEGIN) addressed to 172.17.1.1, the reception query processing unit 204 of the mediation apparatus 200 receives the packet (step S401). The reception query processing unit 204 detects that a transaction has started, and registers the IP address and transaction number of the client 500a in the transaction management table 202 (step S402). The reception query processing unit 204 refers to the server management table 201 and sets the transmission state to “untransmitted” for the servers 100a and 100b that are operating normally, and puts the reception query into the transmission queue 203 (step S403). The query transmission processing unit 205 retrieves the query from the transmission queue 203, transfers it to the corresponding servers 100a and 100b (steps S404 and S405), and updates the transmission state of the transmission queue 203 to “transmission complete” (step S406). ). When the legitimacy determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the transaction has started normally from the servers 100a and 100b (steps S407 and S408), the legitimacy of the response packet from each of the servers 100a and 100b. Determine sex. Then, the response transmission processing unit 207 transfers one of the valid response packets to the client 500a (Step S409). The transmission queue 203 at this time is shown in FIG.

  Next, when the client 500a transmits a packet including SQL (UPDATE) for updating the table test_table to 172.17.1.1, the reception query processing unit 204 of the mediation apparatus 200 receives the packet (step S410). The reception query processing unit 204 refers to the server management table 201, sets the transmission state of the servers 100a and 100b that are operating normally to “untransmitted”, and puts the reception query into the transmission queue 203 (step S411). The transmission queue 203 at this time is shown in FIG.

  Here, it is assumed that the server 100c is restarted (step S412). When the operator of the mediation device 200 confirms that the server 100c has been restarted, the operator instructs the mediation device 200 to input a database synchronization request (step S413).

  When there is a database synchronization request, the synchronization processing control unit 208 refers to the server management table 201 and selects one server 100 for synchronization. Here, since there are two servers 100 operating normally, either one of the servers is selected according to a predetermined rule. In the present embodiment, it is assumed that the server 100b is selected as the synchronization server. The synchronization processing control unit 208 updates the operation state for the server 100b in the server management table 201 to “sync” (step S414), and the transmission state for the server 100b in the transmission queue 203 is “not transmitted”. The entry is updated to “pending” (step S415). In addition, the synchronization processing control unit 208 confirms that the processing of the query being executed in the synchronization server 100b is completed, and then adds the operation status of the requesting server 100c to the server management table 201 with “sync”. At the same time (step S416), a column for the server 100c is added to the transmission status column of the transmission queue 203 (step S417). Here, all the transmission states of the server 100c are set to “hold”. The server management table 201 and the transmission queue 203 at this time are shown in FIGS. Note that the synchronization processing control unit 208 handles the processes in steps S414 to S417 as one process and performs exclusive control. That is, during the processing of steps S414 to S417, the server management table 201 and the transmission queue 203 accessed in each step are sent from other functional blocks (for example, the reception query processing unit 204 and the query transmission processing unit 205). Interrupt access.

  Next, the synchronization processing control unit 208 starts creating a snapshot of the database 101b of the server 100b (step S418). The snapshot is stored in the snapshot storage unit 209. In this embodiment, as described above, the data of each table in the database 101b is acquired using the SELECT query.

  When the synchronization processing control unit 208 finishes the exclusive processing of steps S413 to S416, the query transmission processing unit 205 retrieves a query whose transmission state is “untransmitted” from the transmission queue 203 as shown in FIG. (Step S419), and the transmission state of the transmission queue 203 is updated to “transmission completed” (step S420). When the reception query processing unit 204 of the mediation device 200 receives a response packet notifying that the UPDATE has been processed normally from the server 100a (step S421), since only one server 100 is operating normally, the response query processing unit 204 The response transmission processing unit 207 determines that the response packet is valid, and transfers the response packet to the client 500a (step S422).

  When the client 500b transmits a packet including the transaction start SQL (BEGIN) addressed to 172.17.1.1, the reception query processing unit 204 of the mediation apparatus 200 receives the packet (step S423). The reception query processing unit 204 detects that a transaction has started, and registers the IP address and transaction number of the client 500b in the transaction management table 202 (step S424). The reception query processing unit 204 refers to the server management table 201 and sets the transmission state to “unsent” for the server 100a that is operating normally, and sets the transmission state to “hold” for the servers 100b and 100c that are performing the synchronization processing. The reception query is put in the transmission queue 203 (step S425). The query transmission processing unit 205 retrieves the query from the transmission queue 203, transfers it to the server 100a whose transmission state is “untransmitted” (step S426), and sets the transmission state for the server 100a in the transmission queue 203 to “transmission complete”. (Step S427). When the legitimacy determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the transaction has started normally from the server 100a (step S428), since only one server 100 is operating normally here, The response transmission processing unit 207 determines that the response packet is valid, and transfers the response packet to the client 500b (step S429). The transmission queue 203 at this time is shown in FIG.

  Here, it is assumed that the snapshot creation processing has been completed (step S430). When the snapshot creation processing is completed, the synchronization processing control unit 208 starts restoration processing of the database 101c of the new server 100c using the snapshot (step S431). In this embodiment, the database 101 is restored from the snapshot by issuing an INSERT query or the like to the new server 100c.

  When the snapshot creation processing is completed, the synchronization processing control unit 208 updates the server 100b in which the transmission state of the transmission queue 203 is “pending” to “hold release” (step S432). . The transmission queue 203 at this time is shown in FIG. Thereafter, the query received from each client 500 is transmitted with the transmission state “unsent” for the server 100a, the transmission state “unhold” for the server 100b, and the transmission state “hold” for the server 100c. Put in the queue 203. As a result, the query transmission processing unit 205 transmits the queries whose transmission status is “hold release” to the server 100b in order from the oldest as difference information.

  Specifically, the query transmission processing unit 205 extracts the UPDATE query from the transmission queue 203 and transfers it to the server 100b (step S433), and updates the transmission state of the transmission queue 203 to “transmission completed” (step S434). . The validity determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the update has been processed normally from the server 100b (step S435). Here, since the response is a query processing response as difference information, the response is not transferred to the client 500.

  Here, when the client 500b transmits an INSERT query to the mediation device 200 (step S436), as described above, the reception query processing unit 204 of the mediation device 200 sets the transmission status to “unsent” for the server 100a. For 100b, the transmission state is “hold release”, and for the server 100c, the transmission state is “hold” and the query is put into the transmission queue (step S437). The transmission queue 203 at this time is shown in FIG. The query transmission processing unit 205 retrieves the query from the transmission queue 203 and transfers the query to the server 100a whose transmission state is “untransmitted” (step S438), and sets the transmission state of the transmission queue 203 for the server 100a to “ Update to “transmission completed” (step S439). When the validity determining unit 206 receives from the server 100a a packet notifying that the INSERT has been processed normally (step S440), the response determining unit 206 determines that the response packet is valid because only one server 100 is operating normally. In response, the response transmission processing unit 207 transfers the response packet to the client 500b (step S441).

  As shown in FIG. 45, at this time, there are two queries, the BEGIN query and the INSERT query, whose transmission status is “pending release” in the transmission queue 203. The mediation apparatus 200 processes the two queries in the same manner as in steps S433 to S435 described above (steps S442 to S447).

  As described above, the transfer of all the difference information to the server 100b is completed (that is, the transmission of all “hold release” queries from the transmission queue 203), and the query processing as the difference information is processed normally. As a result, the synchronization of the database 101a of the server 100a and the database 101b of the server 100b is completed. Therefore, the response transmission processing unit 207 of the mediation apparatus 200 updates the operating state of the server management table 201 for the server 100b to “active” in order to incorporate the server 100b into the system (step S448). Note that the timing of incorporation into the system may be during execution of a query in the normally operating server 100a, or the transaction may be ongoing.

  Thereafter, the query from the client 500 is placed in the transmission queue 203 with the transmission state “untransmitted” for the server 100a and the server 100b and the transmission state “held” for the server 100c. Specifically, as illustrated in FIG. 34, when the client 500a transmits a packet including the transaction confirmation SQL (COMMIT) addressed to 172.17.1.1, the reception query processing unit 204 of the mediation apparatus 200 receives the packet ( Step S449). The reception query processing unit 204 refers to the server management table 201 and sets the transmission state to “unsent” for the servers 100a and 100b that are operating normally, and sets the transmission state to “hold” for the server 100c that is performing the synchronization process. The reception query is put in the transmission queue 203 (step S450). The transmission queue 203 at this time is shown in FIG. The query transmission processing unit 205 extracts the query from the transmission queue 203, transfers it to the corresponding servers 100a and 100b (steps S451 and S452), and updates the transmission state of the transmission queue 203 to “transmission completed” (step S453). ). When the legitimacy determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the transaction has been successfully committed from the servers 100a and 100b (steps S454 and S455), the legitimacy of the response packet from each of the servers 100a and 100b. Determine sex. Then, the response transmission processing unit 207 transfers one valid response packet to the client 500a (step S456). Further, since the COMMIT has been completed normally, it can be seen that the transaction has ended, so the response transmission processing unit 207 deletes the registration of this transaction from the transaction management table 202 (step S457).

  Here, it is assumed that the restoration process of the database 101c of the new server 100c has been completed (step S458). When the restoration from the snapshot of the database 101c of the new server 100c is completed, the synchronization processing control unit 208 sends the query held in the transmission queue 203 as difference information for the new server 100c in the transmission queue 203. The one whose transmission status is “hold” is updated to “hold release” (step S459). The transmission queue 203 at this time is shown in FIG. Thereafter, the query received from each client 500 is placed in the transmission queue 203 with the transmission state “untransmitted” for the server 100a and the server 100b and the transmission state “unhold” for the server 100c. As a result, the query transmission processing unit 205 transmits, to the server 100c, in order from the oldest as the difference information, the queries whose transmission status is “hold release”.

  Specifically, the query transmission processing unit 205 extracts the BEGIN query from the transmission queue 203 and transfers it to the server 100c (step S460), and updates the transmission state of the transmission queue 203 to “transmission completed” (step S461). . The validity determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the transaction has been started normally from the server 100c (step S462). Here, since the response is a query processing response as difference information, the response is not transferred to the client 500.

  When the UPDATE query is received from the client 500b during the transfer of the difference information to the server 100c (step S463), the reception query processing unit 204 sets the transmission status to “unsent” for the servers 100a and 100b, and the transmission status for the server 100c. Is put into the transmission queue 203 with “hold release” (step S464). The transmission queue 203 at this time is shown in FIG. The query transmission processing unit 205 retrieves the query from the transmission queue 203, transfers it to the servers 100a and 100b whose transmission status is “untransmitted” (steps S465 and S466), and sets the transmission queue 203 for each of the servers 100a and 100b. The transmission state is updated to “transmission complete” (step S467). When the validity determining unit 206 receives a packet notifying that the UPDATE has been processed normally from each of the servers 100a and 100b (steps S468 and S469), the validity determining unit 206 determines the validity of each response and determines one of the valid responses. Is returned to the client 500b (step S470).

  When the transfer of all the difference information is completed (that is, the transmission of all the “hold release” queries from the transmission queue 203 is completed) and the query processing as the difference information is normally processed, the database of the server 100a Since the synchronization of the database 101c between the server 101c and the server 100c is completed, the operating state of the server management table 201 for the server 100c is updated to “active” in order to incorporate the server 100c into the system. It should be noted that the timing of incorporation into the system may be during execution of a query in the normally operating server 100, or the transaction may be ongoing.

  In the example of FIG. 48, first, processing similar to that in steps S460 to S462 described above is performed for the UPDATE query with the transaction ID No. 5 to the INSERT query with the transaction ID No. 6. The processing of the COMMIT query with the transaction ID No. 5 and the UPDATE query with the transaction ID No. 6 in the example of FIG. 48 will be described in detail below.

  The query transmission processing unit 205 retrieves the COMMIT query from the transmission queue 203 and transfers it to the server 100c (step S490), and updates the transmission state of the transmission queue 203 to “transmission completed” (step S491). The validity determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the transaction has been confirmed from the server 100c (step S492). Here, since the response is a query processing response as difference information, the response is not transferred to the client 500.

  At this time, the transaction with transaction ID 5 has been processed in all servers 100, and the transmission status of each query belonging to transaction ID 5 in the transmission queue 203 is “transmission complete” for all servers 100a, 100b, 100c. Therefore, the response transmission processing unit 207 deletes the query entry belonging to the transaction from the transmission queue 203 (step S493). The transmission queue 203 at this time is shown in FIG.

  Next, as shown in FIG. 36, the query transmission processing unit 205 extracts the UPDATE query from the transmission queue 203 and transfers it to the server 100c (step S494), and updates the transmission state of the transmission queue 203 to “transmission completed”. (Step S495). The validity determination unit 206 of the mediation apparatus 200 receives a response packet notifying that UPDATE has been processed normally from the server 100c (step S496). Here, since the response is a query processing response as difference information, the response is not transferred to the client 500.

  At this point, since there is no query in the transmission queue 203 whose transmission state is “hold release”, the response transmission processing unit 207 sets the active state of the server management table 201 for the server 100c to “active” in order to incorporate the server 100c into the system. (Step S497). Note that the processing in step S497 corresponds to the processing in steps S144 and S242 described above.

  As described above, in this embodiment, as a snapshot creation method, a method in which query processing cannot be performed during creation of the snapshot is employed. However, snapshot creation and a query from a client are employed. By processing these processes with separate servers, the synchronization process can be performed while maintaining the provision of services to the clients. Other operations and effects are the same as those in the first embodiment.

  In the present embodiment, difference information is transferred to the synchronization server 100b for creating a snapshot and the server 100c that is re-installed in the system at independent timings. The same difference information may be transferred to both servers 100b and 100c after the database recovery is completed.

  In the present embodiment, transfer of difference information from the mediation apparatus 200 to the server 100c is started after the database recovery is completed in the server 100c that is re-installed in the system. However, the difference information is temporarily stored in the server 100c. If there is a function, the transfer of difference information may be started without waiting for the completion of database recovery. Thereby, since the transfer rate of the difference information from the mediation apparatus 200 to the server 100 can be suppressed, an increase in traffic due to the difference information transfer can be prevented.

  As mentioned above, although embodiment of this invention was explained in full detail, the said embodiment is an illustration and this invention is not limited to this. The scope of the invention is set forth in the appended claims, and all modifications that come within the meaning of the claims are intended to be embraced by the invention. Note that the following modifications can be applied to the above-described embodiments in appropriate combinations.

  For example, in addition to the configuration of the above embodiment, the mediation apparatus 200 may determine the validity of the processing result of the query processed by the new server 100 or the like as difference information. Specifically, the intermediary device 200 stores a query processing result in the normally operating server 100 in the intermediary device 200. When the query is processed as difference information by the new server 100 or the like, the processing result of the new server 100 or the like is compared with the processing result of the server 100 that is operating normally. If they do not match, it is preferable to retry the synchronization process immediately or at an appropriate timing.

  Further, in the above embodiment, when a query whose transmission state is “hold release” is taken out from the transmission queue 203 and transferred to the server 100 as difference information, and a query is received from the client 500 during the transfer, Processing for setting the transmission state of the server 100 to “hold release” and putting it in the transmission queue 203 is performed. Then, after all the queries whose transmission status is “hold release” are processed in the server 100, the server 100 is incorporated into the system. In such processing, if the frequency of receiving queries from the client 500 is high, it may be necessary to incorporate the server 100 into the system. Therefore, for example, when the number of queries stored in the transmission queue 203 as “reserved release” falls below a predetermined number, the received query processing unit 204 temporarily stops the input of queries to the transmission queue 203 under predetermined conditions. You may make it give priority to the transfer process of difference information.

  In the above embodiment, all queries received from the client 500 are stored in the transmission queue 203, and the query stored in the transmission queue 203 is transferred to the server 100 as difference information during the synchronization process. However, a reference query that does not update the database 101, such as a SELECT query, may not be transferred to the server 100 as difference information. Thereby, the processing time of a synchronization process can be shortened.

  Further, only an update query that updates the database 101 such as an UPDATE query may be transferred, and a reference query or a transaction control query (BEGIN, ROLLBACK, etc.) may not be transferred. When the update query is transferred to the server 100 as difference information, the server 100 is made to process the query in the AutoCommit mode. As a result, the synchronization process can be further shortened and the storage capacity can be saved. However, in this case, it is necessary to ensure that the order in which queries are transferred to the server 100 matches the order processed by the server 100 that is operating normally. In order to realize this, it is only necessary to grasp the actual processing order of each query in the normal operating server 100 from the processing response from the normal operating server 100 to each update query, and transfer each query according to the order. .

  In the above-described embodiment, the mediation apparatus 200 starts creating a snapshot even when a transaction is ongoing in the server 100. However, when there is no ongoing transaction, a snapshot creation instruction is transmitted. You may make it do. As a result, the database 101 cannot create a snapshot while the transaction is ongoing, or the snapshot can be started even if the transaction is ongoing, but the query related to the transaction is reflected in the snapshot. It is possible to use an uncertain whether or not.

  Further, in the above embodiment, the timing for deleting each query from the transmission queue 203 during the synchronization process is the time when the transaction to which the query belongs is completed in all the servers 100. This method has the advantage of being easy to implement because it is the same as the query deletion timing during normal operation. On the other hand, during the synchronization process, if the query of the transmission queue 203 is processed as difference information in the server 100, it may be deleted as needed. Further, it may be deleted in a lump after the synchronization processing is completed.

  In the above embodiment, the query buffering function and the synchronization information storage function for synchronization processing are integrated in the transmission queue 203. However, a storage unit may be provided for each function. . In this case, when the number of servers 100 is three, the difference information storage unit can be shared between the server 100 to be incorporated into the system and the synchronization processing server 100. This is advantageous in that it can be saved.

  In the above embodiment, after the operator confirms that the server 100 has been restarted, the database synchronization request is input using a predetermined input device (not shown) of the intermediary device 200. The synchronization request may be input from the computer via the network. In addition, the intermediary apparatus 100 or another computer may be provided with server monitoring means for issuing a database synchronization request to the intermediary apparatus 200 when the operating status of the server 100 is monitored and the restart of the server 100 is detected.

  Further, in addition to the above-described embodiment, each server 100 may be provided with a failure detection unit that detects a failure of the database 101 or the database control unit 102. This failure detection means detects a failure by periodically monitoring the operations of the database 101 and the database control unit 102, and notifies the mediation device 200 of the occurrence of the failure when a failure is detected. As a result, the mediation apparatus 200 can more reliably and efficiently detect the occurrence of a failure in each server 100 or network.

  Moreover, if each server responds the same according to a request | requirement, it is not necessary to be the same implementation. That is, the version, specification, programming language, compiler type, compiler option, hardware or software, and the like may be different. As the server, free software such as PostgreSQL, commercially available software such as Oracle, or proprietary software may be used. Moreover, they may be mixed. For example, the server 100a may be PostgreSQL and the server 100b may be Oracle.

  In the above-described embodiment, the server is realized by software on a personal computer, but may be implemented by hardware.

  In the above embodiment, only one mediation device 200 is included in the virtual server 800. However, by providing a plurality of mediation devices 200 to provide redundancy, a configuration with higher availability can be achieved. . As a technique for multiplexing the mediation device, for example, what is described in Japanese Patent Application Laid-Open No. 2003-345679 by the applicant of the present application may be used.

  In the above embodiment, the client 500 and the server 100 belong to different networks 300 and 400, respectively, and the mediation apparatus 200 mediates both the networks 300 and 400. The configuration is unquestioned. For example, the client 500, the server 100, and the mediation apparatus 200 may be configured to belong to one network.

  Further, in each of the above embodiments, the database match checking device 600 is connected to the outside of the multiplexed database system, that is, the network 400. However, the database match checking device 600 is connected to the network 300 inside the multiplexed database system. You may do it.

Configuration diagram of a multiplexed database system according to the first embodiment Functional block diagram of an intermediary device according to the first embodiment The figure which shows an example of the server management table which concerns on 1st Embodiment The figure which shows an example of the transaction management table which concerns on 1st Embodiment The figure which shows an example of the transmission queue which concerns on 1st Embodiment. Sequence chart explaining the operation of the multiplexed database system when each server is operating normally Example of server management table in the operation of FIG. Example of transaction management table in the operation of FIG. Sequence chart explaining operation of multiplexed database system when server fails Example of transaction management table in operation of FIG. An example of the server management table in the operation of FIG. An example of a transmission queue in the operation of FIG. Sequence chart explaining the operation of the multiplexed database system when queries are executed in different orders by the server Sequence chart explaining the operation of the multiplexed database system when queries are executed in different orders by the server Sequence chart explaining the operation of the multiplexed database system when queries are executed in different orders by the server Sequence chart explaining the operation of the multiplexed database system when queries are executed in different orders by the server Sequence chart for explaining synchronization processing in the multiplexed database system according to the first embodiment Sequence chart for explaining synchronization processing in the multiplexed database system according to the first embodiment Sequence chart for explaining synchronization processing in the multiplexed database system according to the first embodiment An example of the server management table in the operations of FIGS. An example of a transaction management table in the operations of FIGS. An example of a transmission queue in the operations of FIGS. An example of a transmission queue in the operations of FIGS. An example of the server management table in the operations of FIGS. An example of a transmission queue in the operations of FIGS. An example of a transmission queue in the operations of FIGS. An example of a transmission queue in the operations of FIGS. An example of a transmission queue in the operations of FIGS. An example of a transmission queue in the operations of FIGS. An example of a transmission queue in the operations of FIGS. An example of the server management table in the operations of FIGS. Sequence chart for explaining synchronization processing in the multiplexed database system according to the second embodiment Sequence chart for explaining synchronization processing in the multiplexed database system according to the second embodiment Sequence chart for explaining synchronization processing in the multiplexed database system according to the second embodiment Sequence chart for explaining synchronization processing in the multiplexed database system according to the second embodiment Sequence chart for explaining synchronization processing in the multiplexed database system according to the second embodiment An example of the server management table in the operations of FIGS. 32 to 36 An example of the data structure of the transmission queue in the operations of FIGS. An example of a transmission queue in the operation of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 An example of the server management table in the operations of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 An example of a transmission queue in the operation of FIGS. 32 to 36 Configuration diagram of conventional database synchronization system An example of a database table An example of a transaction whose processing order is an issue An example of a transaction whose processing order is an issue

Explanation of symbols

  DESCRIPTION OF SYMBOLS 100 ... Server, 101 ... Database, 102 ... Database control part, 200 ... Mediation apparatus, 201 ... Server management table, 202 ... Transaction management table, 203 ... Transmission queue, 204 ... Reception query processing part, 205 ... Query transmission processing part, 206 ... Validity determination unit, 207 ... Response transmission processing unit, 208 ... Synchronization processing control unit, 300, 400 ... Network, 500 ... Client, 600 ... Database match checking device.

Claims (8)

In a multiplexed database system comprising a plurality of database servers and an intermediary device that relays processing requests from client computers to each database server and returns one of the valid responses from each database server as a processing result to the client computer A method of synchronizing each database server,
The mediation apparatus includes a difference information storage unit that stores a processing request from a client computer as difference information, and a snapshot storage unit that stores a snapshot of a database.
(A) (i) When it is detected that there is no response to the processing request from the database server, the non-responsive database server is disconnected from the system, or (ii) a processing result inconsistency between the database servers is detected, and the processing result When one of the responses is detected, one response is selected and the selected response is returned to the client computer, and the database server that returns a response other than the selected response is disconnected from the system.
(B) starting a process of acquiring a snapshot of the database from a normally operating database server and storing it in the snapshot storage unit;
(C) sequentially storing processing requests received from the client computer as difference information in the difference information storage unit;
(D) When the acquisition of the snapshot is completed, the database of the database server separated from the system is restored using the snapshot stored in the snapshot storage unit,
(E) When restoration of the database from the snapshot is completed in the database server separated from the system, the processing requests stored in the difference information storage unit are sequentially sent to the database server,
(F) A synchronization method in a multiplexed database system, wherein the processing is stored in a database separated from the system for processing requests stored in the difference information storage unit, and the database server is incorporated into the system. The synchronization method in the multiplexed database system according to claim 1, wherein the intermediary device sequentially stores processing requests not reflected in the snapshot as difference information in the difference information storage unit in the step (c). 3. The multiplexing according to claim 2, wherein the intermediary device stores, in step (c), a processing request related to a transaction that has not been committed in a server that is operating normally at the time of the installation request, retroactively from the time of the installation request. A synchronization method in a database system. 2. The synchronization method in a multiplexed database system according to claim 1, wherein in step (b), the intermediary device starts acquiring a snapshot when a transaction is not processed in a normally operating server. . When there are two or more database servers in normal operation, the mediation device selects one database server as a synchronization database server, acquires a snapshot from the synchronization database server, and creates a snapshot. 2. The synchronization method in a multiplexed database system according to claim 1, wherein the processing request received from the client is relayed to another normally operating database server. In a multiplexed database system comprising a plurality of database servers and an intermediary device that relays processing requests from client computers to each database server and returns one of the valid responses from each database server as a processing result to the client computer ,
The intermediary device
A difference information storage unit for storing a processing request from the client computer as difference information;
A snapshot storage unit for storing database snapshots;
(A) (i) When it is detected that there is no response to the processing request from the database server, the non-responsive database server is disconnected from the system, or (ii) a processing result inconsistency between the database servers is detected, and the processing result If a contradiction is detected, one response is selected from the responses, the selected response is returned to the client computer, and the database server that returned a response other than the selected response is disconnected from the system, and (b) Processing for acquiring a database snapshot from the database server and storing it in the snapshot storage unit is started. (C) Processing requests received from the client computers are sequentially stored as difference information in the difference information storage unit, and (d) snap When the acquisition of the shot is completed, the snapshot storage unit The database of the database server separated from the system is restored using the stored snapshot, and (e) when the restoration of the database from the snapshot is completed in the database server separated from the system, it is stored in the difference information storage unit. And (f) control means for incorporating the database server into the system when processing is completed in the database separated from the system for the processing requests stored in the difference information storage unit. A multiplexed database system characterized by comprising. In a multiplexed database system comprising a plurality of database servers and an intermediary device that relays processing requests from client computers to each database server and returns one of the valid responses from each database server to the client computer as a processing result An intermediary device,
A difference information storage unit for storing a processing request from the client computer as difference information;
A snapshot storage unit for storing database snapshots;
(A) (i) When it is detected that there is no response to the processing request from the database server, the non-responsive database server is disconnected from the system, or (ii) a processing result inconsistency between the database servers is detected, and the processing result If a contradiction is detected, one response is selected from the responses, the selected response is returned to the client computer, and the database server that returned a response other than the selected response is disconnected from the system, and (b) Processing for acquiring a database snapshot from the database server and storing it in the snapshot storage unit is started. (C) Processing requests received from the client computers are sequentially stored as difference information in the difference information storage unit, and (d) snap When the acquisition of the shot is completed, the snapshot storage unit The database of the database server separated from the system is restored using the stored snapshot, and (e) when the restoration of the database from the snapshot is completed in the database server separated from the system, it is stored in the difference information storage unit. And (f) control means for incorporating the database server into the system when processing is completed in the database separated from the system for the processing requests stored in the difference information storage unit. An intermediary device characterized by comprising. In a multiplexed database system comprising a plurality of database servers and an intermediary device that relays processing requests from client computers to each database server and returns one of the valid responses from each database server to the client computer as a processing result A program for realizing an intermediary device,
Computer
A difference information storage unit for storing a processing request from the client computer as difference information;
A snapshot storage unit for storing database snapshots;
(A) (i) When it is detected that there is no response to the processing request from the database server, the non-responsive database server is disconnected from the system, or (ii) a processing result inconsistency between the database servers is detected, and the processing result If a contradiction is detected, one response is selected from the responses, the selected response is returned to the client computer, and the database server that returned a response other than the selected response is disconnected from the system, and (b) Processing for acquiring a database snapshot from the database server and storing it in the snapshot storage unit is started. (C) Processing requests received from the client computers are sequentially stored as difference information in the difference information storage unit, and (d) snap When the acquisition of the shot is completed, the snapshot storage unit The database of the database server separated from the system is restored using the stored snapshot. (E) When the restoration of the database from the snapshot is completed in the database server separated from the system, it is stored in the difference information storage unit. (F) function as control means for incorporating the database server into the system when processing is completed in the database separated from the system for the processing request stored in the difference information storage unit. An intermediary program characterized by

Images