JP2006338145A - Multiplex database system, synchronization method thereof, intermediation device and intermediation program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a multiplex database system, capable of performing synchronization of a database server with minimized synchronization data and optionally separating or incorporating a database server without making the whole system foiled. <P>SOLUTION: In response to a synchronization request (incorporation request) of a new server 100, the intermediation device 200 acquires a snapshot from a server 100 in normal operation to restore a database 101 of the new server 100. The intermediation device 200 accumulates a query from a client after forming the snapshot as differential information, and transfers the differential information after restoration of the database from the snapshot in the new server 100. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a multiplexed database system in which continuous service provision is required without a service being stopped due to a failure or the like, and more particularly, recovery processing when a failure occurs in a database server constituting the system or a new database server The present invention relates to a data synchronization technique for performing the embedded processing while continuing to provide services.

  As a conventional database synchronization technique, for example, one described in Patent Document 1 is known. In this prior art, a plurality of servers each containing a database are interconnected via a network or the like. As shown in FIG. 46, the embodiment described in Patent Document 1 includes three servers 1010, 1020, and 1030, which are interconnected via a network 1040. Each of the servers 1010, 1020, and 1030 includes a data update control unit 1011, 1021, 1031, a replication control unit 1012, 1022, 1032, databases 1013, 1023, 1033, and difference files 1014, 1024, 1034.

  The data update control unit 1011 of the server 1010 performs database update processing. The replication control unit 1012 performs synchronization processing of the database 1013 using the difference file 1014. The database 1013 collectively manages data. The difference file 1014 stores the difference information of the database 1013. The data update control units 1021, 1031, replication control units 1022, 1032, databases 1023, 1033, and difference files 1024, 1034 of the servers 1020 and 1030 are the data update control unit 1011, replication control unit 1012 and database 1013 described above, respectively. And the same function as the difference file 1014.

  When a data update event occurs in the server 1010, the data update control unit 1011 of the server 1010 updates the content of the own database 1013, and then transmits a data update notification to the server 1020 and the server 1030. The data update control units 1021 and 1031 of the server 1020 and the server 1030 update the contents of the own databases 1023 and 1033. Thereafter, the servers 1020 and 1030 each transmit a data update completion notification to the server 1010. If both the data update completion notifications from the server 1020 and the server 1030 are normal, the server 1010 ends the update process without performing anything. Nothing is written in the difference files 1014, 1024, 1034.

  When a data update event occurs in the server 1010 when the server 1030 is down due to a failure or the like, the server 1020 transmits a data update completion notification to the server 1010, but the server 1030 cannot transmit a data update completion notification to the server 1010. . The server 1010 continues to wait for a data update completion notification from the server 1030, but times out and knows that the update at the server 1030 has not ended normally. The server 1010 stores information on the device that failed to be updated in the difference file 1014 (in this case, the server 1030) and the update content. Thus, the server 1010 ends the update process.

  Even when a data update event occurs in the server 1020, the server 1020 performs the same processing as described above, stores the information of the apparatus that failed to be updated and the update content in the difference file 1024, and ends the update process.

  As described above, until the server 1030 is restored, the server 1010 and the server 1020 continue to store the updated contents in the difference files 1014 and 1024, respectively.

  When the server 1030 recovers from the failure, the replication control unit 1032 of the server 1030 transmits a replication start notification to the server 1010. The replication control unit 1012 of the server 1010 extracts the data stored in the difference file 1014 in the oldest order and transmits a data update notification to the server 1030. After updating the content of its own database 1033, the server 1030 transmits a data update completion notification to the server 1010. Each time the server 1010 receives a data update completion notification, the server 1010 deletes the corresponding data from the difference file 1014.

When the difference file 1014 becomes empty, the data of the difference file 1024 of the server 1020 is transmitted to the server 1030 in the same manner as described above. When the difference file 1024 becomes empty, the synchronization of the server 1030 is completed.
JP 2001-290687 A

  However, in the case of the above-mentioned Patent Document 1, since a server that is operating normally immediately after the occurrence of a failure starts to accumulate data update contents in the difference file, the difference file becomes huge as the time until the failure server recovers becomes longer. End up. As a result, there is a problem that the storage capacity of a normally operating server is crushed and the server becomes a failure, or it takes a long time to complete the synchronization of the server recovered from the failure.

  The synchronization procedure is a method of reflecting the updated contents after the failure occurs in the database at the time of the failure. This means that it is assumed that the server to be synchronized normally maintains the database up to just before the failure occurs. Therefore, there is a problem that it is impossible to synchronize the server when a failure such as a hard disk failure occurs that destroys the database. For the same reason, there is also a problem that a new server that does not hold any data cannot be synchronized, such as when upgrading a server.

  In addition, the synchronization procedure is a method based on the update contents after the failure occurs and the database until the failure occurs. This method cannot be used. That is, there is a problem that a new server cannot be synchronized for the purpose of increasing the number of servers in the entire system. For example, in the example of Patent Document 1, the total number of servers in the system is 3, but the fourth server cannot be synchronized in order to increase this number to 4.

  Another problem is that the number of servers in the entire system cannot be reduced. The reason is that, when one server is disconnected, the difference file is accumulated forever.

  There is also a problem that when a transaction fails, there is no way to cancel the updated contents of the failed transaction.

  In addition, since the update contents are distributed and stored on all servers other than the server that is down due to a failure, there is also a problem that if two or more servers go down, the failed server cannot be synchronized. .

  The present invention has been made in view of the above circumstances, and a first object is to provide a multiplexed database system capable of synchronizing a database server with a small amount of synchronization data. . A second object is to provide a multiplexed database system that can arbitrarily detach or incorporate a database server regardless of the data storage status of the database server without bringing down the entire system.

  In order to achieve the above object, the present invention relays processing requests from a plurality of database servers and 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. In a multiplexed database system including an intermediary device, the intermediary device includes a difference information storage unit that stores processing requests from client computers as difference information, and a snapshot storage unit that stores a snapshot of the database. Then, when there is a request for incorporating a new database server, the intermediary device (a) starts a process of acquiring a database snapshot from a normally operating database server and storing it in the snapshot storage unit, (b) The processing request received from the client computer is sequentially stored as difference information in the difference information storage unit, and (c) when the acquisition of the snapshot is completed, the database of the new database server is restored using the snapshot stored in the snapshot storage unit. (D) When restoration of the database from the snapshot is completed in the new database server, processing requests stored in the difference information storage unit are sequentially sent to the new database server, and (e) stored in the difference information storage unit The new processing request to the new database When the stomach processing is completed incorporate a new database server to the system.

  According to such a system, the intermediary device stores the difference information for synchronization of the new database server in the difference information storage unit, but this difference information is sent to the difference information storage unit in response to an incorporation request from the new database server. Accumulation starts. Therefore, when the database server is separated from the system due to a failure or the like and then incorporated into the system again, a large amount of difference information is not accumulated in the mediation device even if it takes a long time to recover from the failure. As a result, the storage capacity of the mediation device can be saved, and an increase in load or down of the mediation device due to an increase in difference information can be prevented.

  In addition, since the data in the new database server is restored based on the snapshot in the database server in normal operation and the difference information stored in the mediation device, what is the data storage status in the new database at the time of installation? It doesn't matter. Therefore, it is possible to restore a database server that has been disconnected due to a disk failure or to incorporate a new database server (that is, increase the database server). That is, any database server can be incorporated.

  Furthermore, since the snapshot in the database server that is operating normally is stored and held in the intermediary device, the snapshot does not impose the storage capacity of the database server that is operating normally. Therefore, it is possible to prevent a malfunction of the database server during normal operation due to storage capacity compression.

  Furthermore, since the difference information is not stored and the snapshot is not created simply by disconnecting the database server from the system, the database can be arbitrarily disconnected from the system.

  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, the database server can be synchronized with a small amount of synchronization data. Further, the database server can be arbitrarily separated or incorporated regardless of the data storage status of the database server without bringing down the entire system.

(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. It is accessed from a client computer (hereinafter referred to as “client”) 500. 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 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 transmitting / receiving packets 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 affected. There is no need to change the operation.

  The server 100 includes a database 101 that stores and manages data. 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 usually 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 data that is committed at the start of snapshot creation is reflected in the snapshot, and that query processing is possible even during snapshot creation.

  As illustrated in FIG. 2, the mediation apparatus 200 includes a server management table 201 that manages the server 100 in the 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 and the like, 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 is being synchronized (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 processing 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: “not yet transmitted”, “transmission completed”, “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 status 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 transaction start), and the client 500 or the like ends the “COMMIT” transaction. 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 the queries 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, there is no such response 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. Also, one Master server is determined in advance from the plurality of servers 100, and the response from this server 100 is always determined to be correct. There is also a method using a plurality of the above methods in combination. 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 operating normally can be recognized by referring to the server management table 201. When the validity determination unit 206 detects a server 100 that has returned an invalid response as a result of the validity determination, the validity determination unit 206 deletes the entry for the server 100 from the server management table 201 and the transmission queue 203. As a result, the query is not transmitted to the server 100, so that the server 100 is disconnected from the system.

  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. In addition, 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 (hereinafter referred to 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.

  Upon receiving the database synchronization request (system integration request), the synchronization processing control unit 208 (1) sets the operating state of the new server 100 to “sync” and adds it to the server management table 201. (2) Transmission A column for the new server 100 is added to the transmission status column of the queue 203. (3) A server for synchronization processing is selected from the servers 100 operating normally and the transmission queue for the server 100 is selected. If the transmission status of 203 is “unsent”, it is updated to “pending”. (4) The server 100 for synchronization processing waits until processing of the query being executed is completed, When processing of the query being executed in the server 100 is completed, a process of acquiring a snapshot of the server 100 and storing it in the snapshot storage unit 209 is performed. To start, do a process of. The database synchronization request may be input from a console or the like connected to the mediation apparatus 200, or may be input from another apparatus via a network.

  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. That is, the synchronization processing control unit 208 performs the processes from (1) to (4) until the snapshot creation start, with respect to the server management table 201 and the transmission queue 203 accessed in each process. 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.

  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 the response packet notifying that the transaction has started normally is received from the server 100b (step S6), since all the response packets are now prepared, the validity judgment unit 206 compares the response packets with each other. By doing so, 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 device 200, and the validity determination unit 206 of the mediation device 200 receives this 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 completed is received from the server 100b (step S13), since all the response packets are now complete, the validity judgment unit 206 compares the response packets with each other to determine whether 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 of the valid response packets to the client 500a (Step S15).

  Next, the client 500a transmits to 172.17.1.1 a packet including SQL (COMMIT) that confirms 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 both of 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 the transaction start SQL (BEGIN) to 172.17.1.1, the reception query processing unit 204 of the mediation device 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 judgment 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 “not transmitted” 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 been successful, and the validity determining 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). 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 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, database synchronization processing when the new server 100 is incorporated into the system will be described in detail. 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 processing is accumulated as difference information in the mediation apparatus 200. The 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.

  Hereinafter, the synchronization operation when the server 100b is incorporated in 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 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. 13, 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. 17 shows the transaction management table 202 at this time. 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 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 a database synchronization request (request for incorporation into the system) is input from another terminal or the like via the console of the mediation apparatus 200 or the network (step S310).

  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 S311). 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 S312). ), A column for the server 100b is added to the transmission status column of the transmission queue 203 (step S313). 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. The synchronization process control unit 208 handles the processes in steps S311 to S313 as one process and performs exclusive control. That is, during the processing of steps S311 to S313, 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 S314). 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, the snapshot creation tool used in the present embodiment can process a query during snapshot creation. 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 S315). 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 S316), and updates the transmission state to “transmission completed” (step S317). When the validity determination unit 206 receives a response packet notifying that the query has been processed normally from the server 100a (step S318), 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 S319). 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 S320). 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 S321). 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. 14, when the received query processing unit 204 receives an INSERT query from the client 500a (step S322), the synchronization server 100a is “unsent” and the new server 100b is “pending”. Is put into the transmission queue 203 (step S323). 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 “unsent” and transfers it to the corresponding synchronization server 100a (step S324), and updates the transmission state to “transmission completed”. (Step S325). When the validity determination unit 206 receives from the server 100a a response packet notifying that the query has been processed normally (step S326), 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 S327).

  Here, it is assumed that the restoration process of the database 101b of the new server 100b has been completed (step S328). 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 S329). 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 S330), and updates the transmission state to “transmission completed” (step S331). The validity determination unit 206 receives from the new server 100b a response packet notifying that the query has been processed normally (step S332). 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. 15, when a COMMIT query is received from the client 500a (step S333), 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. “Release hold” is put into the transmission queue 203 (step S334). 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. 15, 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 S335), and the transmission state is “transmission complete”. (Step S336). When the validity determination unit 206 receives from the server 100a a response packet notifying that the query has been processed normally (step S337), 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 S338). 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 S339).

  In the example of FIG. 15, the query transmission processing unit 205 sequentially transfers the UPDATE query, the INSERT query, and the COMMIT query whose transmission status is “pending release” as difference information to the new server 100b, and sets the transmission status. The process of updating to “transmission completed” is repeated (steps S340 to S348). 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 “ update to "active" (step S349). FIG. 27 shows the server management table 201 at this time.

  By such a synchronization process, any number of servers can be added theoretically, whether they are servers that were originally incorporated in the system or disconnected from the system due to a failure or the like, or new servers. In other words, there is no limit to the number of servers that can be added.

  In addition, since the data stored in the transmission queue 203 as difference information in the mediation device 200 starts to be accumulated after a synchronization request (system incorporation request) is made, the synchronization data increases in the mediation device 200. There is no. 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 separated.

  Therefore, in the multiplexed database system according to the present embodiment, the server can be arbitrarily installed and disconnected, so that a flexible system design can be performed according to the demands such as usage and budget.

(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. Hereinafter, only differences from the first embodiment will be described in detail.

  In the first embodiment, the synchronization processing control unit 208, as a snapshot creation tool, reflects only data committed at the start of snapshot creation to the snapshot, and can process queries even during snapshot creation. Pg_dump was used. 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 in which one server 100c among the three servers 100a to 100c is detached from the system and then the server 100c is incorporated into the system again will be described with reference to FIGS.

  FIG. 33 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. 28, 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 a database synchronization request (request for incorporation into the system) is input from another terminal or the like via the console of the mediation apparatus 200 or the network (step S412).

  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 a 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 S413), and the transmission state for the server 100b in the transmission queue 203 is “not transmitted”. The entry is updated to “pending” (step S414). 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 S415), a column for the server 100c is added to the transmission status column of the transmission queue 203 (step S416). 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. The synchronization process control unit 208 handles the processes in steps S413 to S416 as one process and performs exclusive control. That is, during the processing of steps S413 to S416, 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 S417). 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 S418), and the transmission state of the transmission queue 203 is updated to “transmission completed” (step S419). When the reception query processing unit 204 of the mediation apparatus 200 receives a response packet notifying that UPDATE has been processed normally from the server 100a (step S420), since only one server 100 is operating normally here, The response packet is determined to be valid, and the response transmission processing unit 207 transfers the response packet to the client 500a (step S421).

  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 S422). 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 S423). 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 S424). 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 S425), and sets the transmission state for the server 100a in the transmission queue 203 to “transmission complete”. (Step S426). 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 S427), since only one server 100 is operating normally here, The response packet is judged to be valid, and the response transmission processing unit 207 transfers the response packet to the client 500b (step S428). The transmission queue 203 at this time is shown in FIG.

  Here, it is assumed that the snapshot creation processing has been completed (step S429). 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 S430). 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 transmission status of the transmission queue 203 for the server 100b to “hold” (step S431). . 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 S432), and updates the transmission state of the transmission queue 203 to “transmission completed” (step S433). . 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 S434). 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 S435), 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 in the transmission queue (step S436). 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 it to the server 100a whose transmission state is “untransmitted” (step S437), and sets the transmission state of the transmission queue 203 for the server 100a to “ Update to “transmission completed” (step S438). When the validity determining unit 206 receives from the server 100a a packet notifying that the INSERT has been processed normally (step S439), the response packet is regarded as 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 S440).

  As shown in FIG. 41, 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 S432 to S434 described above (steps S441 to S446).

  As described above, the transfer of all the difference information to the server 100b is completed (that is, the transmission of all the “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 S447). 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 shown in FIG. 30, when the client 500a transmits a packet including a 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 S448). 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 S449). 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 S450 and S451), and updates the transmission state of the transmission queue 203 to “transmission completed” (step S452). ). When the validity determination unit 206 of the intermediary device 200 receives a response packet notifying that the transaction has been successfully committed from the servers 100a and 100b (steps S453 and S454), the validity of the response packet from each of the servers 100a and 100b is confirmed. Determine sex. Then, the response transmission processing unit 207 transfers one valid response packet to the client 500a (step S455). 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 S456).

  Here, it is assumed that the restoration processing of the database 101c of the new server 100c has been completed (step S457). 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 transmission status “pending” is updated to “pending release” (step S458). 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 “unsent” for the server 100 a and the server 100 b and the transmission state “unhold” for the server 100 c. 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 S459), and updates the transmission state of the transmission queue 203 to “transmission completed” (step S460). . The validity determination unit 206 of the mediation apparatus 200 receives a response packet notifying that the transaction has started normally from the server 100c (step S461). 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 S462), 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. The query is put into the transmission queue 203 by “hold release” (step S463). 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 S464 and S465), and sets the transmission queue 203 for each of the servers 100a and 100b. The transmission state is updated to “transmission completed” (step S466). 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 S467 and S468), 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 S469).

  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. 44, first, the same processing as in steps S459 to S461 described above is performed for the INSERT query with the transaction ID No. 6 from the UPDATE query with the transaction ID No. 5. 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. 44 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. 32, 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).

  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. 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 this embodiment, the difference information is transferred to the synchronization server 100b for creating the 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.

  Further, 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 speed 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 with respect to each update query, and to 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 can start creating a snapshot even while 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 in 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-described 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.

  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. Thereby, the mediation apparatus 200 can more reliably and efficiently detect the occurrence of a failure in each server 100 or the network.

  In addition, if each server responds in response to a request, it does not have to be the same implementation. That is, the version, specifications, programming language, compiler type, compiler options, hardware or software, and the like may be different. For 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.

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 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 the 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. 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. An example of a transmission queue in the operation of FIGS. An example of the server management table in the operations of FIGS. An example of a transmission queue in the operation of FIGS. An example of a transmission queue in the operation of FIGS. An example of a transmission queue in the operation of FIGS. An example of a transmission queue in the operation of FIGS. An example of a transmission queue in the operation of FIGS. An example of a transmission queue in the operation of FIGS. An example of a transmission queue in the operation of FIGS. An example of a transmission queue in the operation of FIGS. Configuration diagram of conventional database synchronization system

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, 209 ... Snapshot storage unit, 300, 400 ... Network, 500 ... Client

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 when a new or disconnected database server (hereinafter referred to as “new database server”) is incorporated into the system,
The intermediary device
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;
When there is a request to install a new database server,
(A) Start processing to acquire a snapshot of the database from the database server that is operating normally and store it in the snapshot storage unit,
(B) The processing request received from the client computer is sequentially stored in the difference information storage unit as difference information,
(C) When the acquisition of the snapshot is completed, the database of the new database server is restored using the snapshot stored in the snapshot storage unit,
(D) When the restoration of the database from the snapshot is completed in the new database server, the processing requests stored in the difference information storage unit are sequentially sent to the new database server,
(E) A synchronization method in a multiplexed database system, wherein a new database server is incorporated into the system when processing for the processing request stored in the difference information storage unit is completed in the new database. 2. The synchronization method in a multiplexed database system according to claim 1, wherein in the step (b), the intermediary device sequentially stores processing requests not reflected in the snapshot as difference information in the difference information storage unit. 3. The multiplexing according to claim 2, wherein the intermediary device stores, in the step (b), a processing request related to a transaction that has not been committed in a server that is operating normally at the time of the incorporation request, retroactively from the time of the incorporation request. A synchronization method in a database system. 2. The synchronization method in a multiplexed database system according to claim 1, wherein, in the step (a), the intermediary device starts acquiring a snapshot when a transaction is not processed in a normally operating server. 3. . 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;
When there is a request to incorporate a new or disconnected database server (hereinafter referred to as “new database server”) into the system, (a) a database snapshot is obtained from the database server that is operating normally. Starts processing to be stored in the snapshot storage unit, (b) sequentially stores processing requests received from the client computer as difference information in the difference information storage unit, and (c) completes acquisition of the snapshot in the snapshot storage unit. The database of the new database server is restored using the stored snapshot, and (d) when restoration of the database from the snapshot is completed in the new database server, the processing request stored in the difference information storage unit is transferred to the new database server To (e Multiplexing database system is characterized in that a control unit incorporating the process in the new database is completed a new database server system for processing requests stored in the difference information storage unit. 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;
When there is a request to incorporate a new or disconnected database server (hereinafter referred to as “new database server”) into the system, (a) a database snapshot is obtained from the database server that is operating normally. Processing to be stored in the snapshot storage unit is started, (b) processing requests received from the client computer are sequentially stored as difference information in the difference information storage unit, and (c) snapshot acquisition is completed when acquisition of the snapshot is completed. The database of the new database server is restored using the stored snapshot, and (d) when the restoration of the database from the snapshot is completed in the new database server, the processing request stored in the difference information storage unit is transferred to the new database server To (e Intermediary device being characterized in that a control unit incorporating a new database server system when the processing request stored in the difference information memory section processed in the new database ends. 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;
When there is a request to incorporate a new or disconnected database server (hereinafter referred to as “new database server”) into the system, (a) a database snapshot is obtained from the database server that is operating normally. Processing to be stored in the snapshot storage unit is started, (b) processing requests received from the client computer are sequentially stored as difference information in the difference information storage unit, and (c) snapshot acquisition is completed when acquisition of the snapshot is completed. The database of the new database server is restored using the stored snapshot, and (d) when restoration of the database from the snapshot is completed in the new database server, the processing request stored in the difference information storage unit is transferred to the new database server To (e Intermediation program, characterized in that the processing request stored in the difference information storage unit process in the new database to function as a control unit incorporating a new database server system upon completion.

Images