WO2005096155A1 - 多重化データベースシステム - Google Patents

多重化データベースシステム Download PDF

Info

Publication number
WO2005096155A1
WO2005096155A1 PCT/JP2005/006483 JP2005006483W WO2005096155A1 WO 2005096155 A1 WO2005096155 A1 WO 2005096155A1 JP 2005006483 W JP2005006483 W JP 2005006483W WO 2005096155 A1 WO2005096155 A1 WO 2005096155A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
database server
server
difference information
processing
Prior art date
Application number
PCT/JP2005/006483
Other languages
English (en)
French (fr)
Inventor
Takeshi Mishima
Original Assignee
Nippon Telegraph And Telephone Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2004109106A external-priority patent/JP2007241322A/ja
Priority claimed from JP2004141174A external-priority patent/JP2007241323A/ja
Priority claimed from JP2004237438A external-priority patent/JP2007241324A/ja
Priority claimed from JP2004369841A external-priority patent/JP2007241325A/ja
Application filed by Nippon Telegraph And Telephone Corporation filed Critical Nippon Telegraph And Telephone Corporation
Publication of WO2005096155A1 publication Critical patent/WO2005096155A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
    • G06F11/1662—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit the resynchronized component or unit being a persistent storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2082—Data synchronisation

Definitions

  • the present invention relates to a multiplexed database system that requires continuous service provision without interruption of service due to a failure or the like, and particularly to recovery processing when a failure occurs in a database server that constitutes the system.
  • the present invention relates to a synchronization technology for performing a process of incorporating a new database server while providing services. Further, the present invention relates to a multiplexed database system in which a plurality of database servers are operated in parallel, and more particularly, to a synchronization technique between the database servers.
  • Patent Document 1 As a conventional database synchronization technology, for example, a technology described in Patent Document 1 is known.
  • a plurality of servers each having a built-in database are interconnected via a network or the like.
  • the embodiment described in Patent Document 1 includes three Sernos 10, 20, and 30, which are interconnected via a network 40.
  • Each of the servers 10, 20, and 30 stores the data update ⁇ U control 21, 31, the replication ⁇
  • the data update control unit 11 of the server 10 performs a database update process.
  • the replication control unit 12 synchronizes the database 13 with the difference file 14.
  • the database 13 manages data collectively.
  • the difference file 14 stores difference information of the database 13.
  • the data update control units 21 and 31, the replication control units 22 and 32, the databases 23 and 33, and the difference files 24 and 34 of the servers 20 and 30 are respectively composed of the data update control unit 11 and the replication control unit 12 described above. It has the same functions as the database 13 and the difference file 14.
  • the data update control unit 11 of the server 10 transmits a data update notification to the server 20 and the server 30 after updating the content of the own database 13. I do.
  • the data update control units 21 and 31 of the server 20 and the server 30 update the contents of the own databases 23 and 33. Thereafter, the servers 20 and 30 each transmit a data update completion notification to the server 10. If both the data update completion notices from the server 20 and the server 30 are normal, the server 10 ends the update processing without performing anything. Nothing is written to the difference files 14, 24, 34.
  • the server 20 sends a data update completion notification to the server 10, but the server 30 sends a data update completion notification to the server 10. Cannot send to.
  • the server 10 keeps waiting for the data update completion notification from the server 30, but times out and learns that the update at the server 30 has not been completed normally.
  • the server 10 saves information (in this case, the server 30) of the device whose update has failed and the update content in the difference file 14. Thus, the server 10 ends the update processing.
  • the server 20 performs the same processing as described above, stores the information of the failed device and the update content in the difference file 24, and ends the update process. .
  • Server 10 replication control The unit 12 sequentially retrieves the data stored in the difference file 14, and transmits a data update notification to the server 30. After updating the contents of its own database 33, the server 30 sends a data update completion notification to the server 10. The server 10 deletes the corresponding data from the difference file 14 each time the data update completion notification is received.
  • the difference file 14 When the difference file 14 becomes empty, the data of the difference file 24 of Sano 20 is transmitted to the server 30 in the same manner as described above. When the difference file 24 is also empty, the synchronization of the server 30 is completed.
  • the synchronization procedure is a method in which the content of the update after the failure is reflected in the database at the time of the failure. This means that it is premised that the server to be synchronized normally holds the database until immediately before the failure occurs. Therefore, there is a problem that it is impossible to synchronize the server when a failure that destroys the database such as a hard disk failure occurs. For the same reason, you may not have any data at all, such as when upgrading a server.
  • V ⁇ New there is a problem that the server can not be synchronized.
  • the synchronization procedure is based on the update contents after the occurrence of the failure and the database immediately before the occurrence of the failure, that is, the method that is based on the point of time when the failure occurs.
  • This method cannot be used for any other purpose.
  • a new server cannot be synchronized in order to increase the number of servers in the entire system.
  • the number of servers in the entire system is three. In order to increase this to four, the fourth server cannot be synchronized.
  • the computer 110 controls an application program 111 for executing various business processes and a search and update of the database 114, and performs update processing in the database 124 of another computer 120 via the transaction monitor 113. And a transaction monitor 113 for synchronizing update processing of the databases 114 and 124 by so-called two-phase commit control.
  • the computer 120 also includes an application program 121, a database management system 122, and a transaction monitor 123.
  • the application program 111 updates the databases 114 and 124 in the same transaction within a certain transaction.
  • Database 114 is updated by database management system 112
  • database 124 is updated by database management system 122.
  • the application program 111 issues a “COMMIT request” for confirming the update so far or a “ROLLBACK request” for canceling the update so far.
  • the “COMMIT request” or “ROLLBACK request” is sent by the transaction monitor 113 to the database management system 112 and to the database management system 122 via the transaction monitor 123.
  • the transaction monitors 113 and 123 When the transaction monitors 113 and 123 receive the response “COMMIT OK” from both the database management systems 112 and 122, they transmit “COMMIT execution” to the database management systems 112 and 122, respectively.
  • the database management systems 1112 and 122 receiving the “COMMIT execution” actually execute the COMMIT.
  • the above-described conventional technique is a method of synchronizing a database of one transaction in a plurality of databases, and cannot control the synchronization of a database between a plurality of transactions.
  • the database synchronization will be lost or the response returned to the client will be unique.
  • This problem is specifically exemplified below.
  • Patent Document 1 Japanese Patent Application Laid-Open No. 2001-290687
  • the present invention has been made in view of the above circumstances, and a first object is to provide a database server after recovery using synchronization data that is small even if a failure occurs in the database server. Another object of the present invention is to provide a multiplexed database system capable of synchronizing data. It is a second object of the present invention to provide a multiplexed database system in which a database server can be arbitrarily separated or incorporated regardless of the data storage state of the database server without bringing down the entire system.
  • a third object of the present invention is to provide a synchronization method in a multiplexed database system in which no inconsistency occurs between databases even when a plurality of transactions are processed in parallel. .
  • the intermediary device stores the difference information for synchronizing the new database server in the difference information storage unit. Storage in the information storage unit is started. Therefore, when the database server is disconnected from the system due to a failure or the like and then re-integrated into the system, even if it takes a long time to recover from the failure, a large amount of difference information is not accumulated in the mediation device. As a result, it is possible to save the storage capacity of the mediation device, and to prevent an increase in the load or downtime of the mediation device due to an increase in difference information.
  • a plurality of database servers and a processing request from a client computer are relayed to each database server, and one of normal responses from each database server is transmitted to the client.
  • the intermediary device includes a difference information storage unit that stores a processing request of a client computer as difference information.
  • the database server that is operating normally starts (2a) creation of a snapshot of the database at the time of receiving the mediation device power snapshot creation instruction, and (2b) transfers the created snapshot to the new database server. (2c) Perform processing in accordance with the processing requests sequentially received as difference information from the mediation device.
  • the new database server (3a) receives the snapshot from the synchronization database server and restores the database using the snapshot. (3b) When the restoration of the database is completed based on the snapshot, the mediation device (3c) Mediation device power Performs processing in accordance with the processing requests sequentially received as difference information.
  • the mediation device stores the difference information for synchronizing the new database server in the difference information storage unit, and this difference information is triggered by the request for incorporating the new database server.
  • the storage in the storage unit is started. Therefore, when the database server is disconnected from the system due to a failure or the like and then re-integrated into the system, a large amount of difference information is not accumulated in the intermediary device even if it takes a long time to recover from the failure. As a result, it is possible to save the storage capacity of the mediation device, and to prevent the load or down of the mediation device due to the increase of the difference information.
  • the process of creating a snapshot and transferring the snapshot to the new database server is performed by a database server (a database server for synchronization) different from the database server that processes the processing request from the client computer. Therefore, an increase in the load on the database server that processes the processing request from the client computer can be prevented. As a result, the service provision to the client can be maintained smoothly even during the synchronization process.
  • a database server a database server for synchronization
  • the present invention relays processing requests from a plurality of database servers and a client computer to each database server, and returns one of proper responses from each database server to the client computer as a processing result. It relates to the synchronization processing of each database in a multiplexed database system with an intermediary device is there.
  • the mediation device is provided with a difference information storage unit that stores the processing request of the client computer power as difference information, and the processing request that also received the client computer power while the database server was disconnected from the system power. Is stored as difference information.
  • a snapshot is created in the database server that is operating normally, and the database server that has been disconnected from the system restores the database from the snapshot. Then, by processing the difference information stored in the difference information storage unit, synchronization of each database server can be achieved.
  • the processing order may differ between the database server that processes the difference information and the database server that is processing the processing request while the difference information is being stored and is operating normally.
  • the database server can be arbitrarily separated or incorporated regardless of the data storage state of the database server without bringing down the entire system.
  • FIG. 1 is a configuration diagram of a multiplexed database system according to a first embodiment.
  • FIG. 3 is a diagram showing an example of a transaction management table according to the first embodiment
  • FIG. 4 is a diagram showing an example of a difference information storage unit according to the first embodiment [5] A diagram showing an example of a transmission queue according to the first embodiment
  • FIG. 11 An example of a server management table in the operation of FIG.
  • FIG. 15 An example of a server management table in the operation of FIG. 11 and FIG.
  • FIG. 27 An example of a transmission queue during operation of the multiplexed database system according to the fourth embodiment
  • FIG. 28 An example of a transmission queue during operation of the multiplexed database system according to the fourth embodiment
  • FIG. 30 An example of a transmission queue during operation of the multiplexed database system according to the fourth embodiment
  • FIG. 31 An example of a transmission queue during operation of the multiplexed database system according to the fifth embodiment
  • FIG. 32 An example of a transmission queue during operation of the multiplexed database system according to the fifth embodiment
  • FIG. 33 An example of a transmission queue during operation of the multiplexed database system according to the fifth embodiment
  • FIG. 35 An example of a transmission queue during operation of the multiplexed database system according to the fifth embodiment
  • FIG. 37 is a configuration diagram of a multiplexed database system according to a sixth embodiment.
  • FIG. 43 An example of a server management table in the operation of FIG. 41
  • FIG. 51 An example of a server management table in the operations of FIGS. 47 and 48
  • FIG. 52 An example of a transaction management table in the operations of FIGS. 47 and 48
  • FIG. 53 An example of a transaction management table in the operations of FIGS. 47 and 48
  • FIG. 54 An example of a transaction management table in the operations in FIGS. 47 and 48
  • FIG. 55 An example of a server management table in the operations of FIGS. 47 and 48
  • FIG. 57 An example of a server management table in the operations of FIGS. 47 and 48
  • FIG. 60 An example of a difference information storage unit according to the eighth embodiment
  • FIG. 61 A configuration diagram of an intermediary device according to a ninth embodiment.
  • FIG. 62 is a diagram showing an example of a transmission queue according to the ninth embodiment.
  • FIG. 65 An example of a transmission queue during operation of the multiplexed database system according to the ninth embodiment
  • FIG. 66 An example of a transmission queue during operation of the multiplexed database system according to the ninth embodiment
  • FIG. 67 An example of a transmission queue during operation of the multiplexed database system according to the ninth embodiment.
  • FIG. 69 An example of a transmission queue during operation of the multiplexed database system according to the tenth embodiment
  • FIG. 70 An example of a transmission queue during operation of the multiplexed database system according to the tenth embodiment
  • FIG. 71 An example of a transmission queue in operation of the multiplexed database system according to the tenth embodiment
  • FIG. 72 An example of a transmission queue during operation of the multiplexed database system according to the tenth embodiment
  • FIG. 75 is a configuration diagram of a multiplexed database system according to a twelfth embodiment.
  • FIG. 78 is a diagram showing an example of a difference information storage unit according to the twelfth embodiment.
  • FIG.81 An example of a server management table in the operation of Fig. 79
  • FIG. 84 An example of a transaction management table in the operation of FIG. 82
  • FIG. 93 An example of a server management table in the operations of FIGS. 90 to 92
  • FIG. 94 An example of a transaction management table in the operations of FIGS. 90 to 92
  • FIG. 95 An example of a transaction management table in the operations of FIGS. 90 to 92
  • FIG. 96 An example of a transaction management table in the operations of FIGS. 90 to 92
  • FIG. 100 An example of a difference information storage unit according to the fourteenth embodiment
  • FIG. 101 is a configuration diagram of an intermediary device according to a fifteenth embodiment.
  • FIG. 102 illustrates an example of a transmission queue according to the fifteenth embodiment.
  • FIG. 103 An example of a transmission queue during synchronization processing of the multiplexed database system according to the fifteenth embodiment.
  • FIG. 104 An example of a transmission queue during synchronization processing of the multiplexed database system according to the fifteenth embodiment
  • FIG. 105 An example of a transmission queue during synchronization processing of the multiplexed database system according to the fourth embodiment.
  • FIG.109 An example of a transmission queue during synchronization processing of the multiplexed database system according to the sixteenth embodiment.
  • FIG. 111 An example of a transmission queue during synchronization processing of the multiplexed database system according to the sixteenth embodiment
  • FIG. 112 An example of a transmission queue during synchronization processing of the multiplexed database system according to the sixteenth embodiment
  • FIG. 113 A configuration diagram of a multiplexed database system according to a seventeenth embodiment.
  • FIG. 114 is a sequence chart for explaining a synchronization process in the multiplexed database system according to the seventeenth embodiment.
  • FIG. 115 is a sequence chart for explaining a synchronization process in the multiplexed database system according to the seventeenth embodiment.
  • FIG. 116 is a sequence chart for explaining the synchronization processing in the multiplexed database system according to the seventeenth embodiment.
  • FIG. 117 An example of a server management table in the operations of FIGS. 114 to 116
  • FIG. 118 An example of a transaction management table in the operations of FIGS. 114 to 116
  • FIG. 119 An example of a transaction management table in the operations of FIGS. 114 to 116
  • FIG. 120 An example of a transaction management table in the operations of FIGS. 114 to 116
  • FIG. 121 An example of a server management table in the operations of FIGS. 114 to 116
  • FIG. 123 An example of a server management table in the operations of FIGS. 114 to 116
  • FIG. 124 is a sequence chart illustrating a synchronization process in the multiplexed database system according to the eighteenth embodiment.
  • FIG. 125 is a sequence chart illustrating a synchronization process in the multiplexed database system according to the eighteenth embodiment.
  • FIG. 126 A configuration diagram of a multiplexed database system according to another example.
  • FIG. 131 A configuration diagram of a multiplexed database system according to a nineteenth embodiment.
  • FIG.137 An example of the server management table in the operation of Fig. 135
  • FIG. 138 An example of a transaction management table in the operation of FIG. 135
  • FIG. 141 An example of a server management table in the operation of FIG. 139
  • Figure 146 A sequence chart illustrating the operation of a multiplexed database system when queries are executed in different orders by a server.
  • FIG. 147 is a sequence chart illustrating a synchronization process in the multiplexed database system according to the nineteenth embodiment.
  • FIG. 148 A sequence chart illustrating a synchronization process in the multiplexed database system according to the nineteenth embodiment.
  • FIG. 150 is a sequence chart illustrating a synchronization process in the multiplexed database system according to the nineteenth embodiment.
  • FIG. 151 An example of a server management table in the operations of FIGS. 208 to 150
  • FIG. 152 An example of a transaction management table in the operations of FIGS. 208 to 150
  • FIG. 154 An example of the transmission queue in the operation of FIGS. 208 to 150
  • FIG. 155 An example of a server management table in the operations of FIGS. 208 to 150
  • FIG. 156 An example of the transmission queue in the operation of FIGS. 208 to 150
  • FIG. 157 An example of a transaction management table in the operations of FIGS. 208 to 150
  • FIG. 158 An example of the transmission queue in the operations of FIGS. 208 to 150
  • FIG. 159 An example of the transmission queue in the operation of FIGS. 208 to 150
  • FIG. 160 An example of the transmission queue in the operation of FIGS. 208 to 150
  • FIG. 161 An example of a server management table in the operations of FIGS. 208 to 150
  • FIG. 162 An example of the transmission queue in the operations of FIGS. 208 to 150
  • FIG. 163 An example of the transmission queue in the operations of FIGS. 208 to 150
  • FIG. 164 An example of the transmission queue in the operation of FIGS. 208 to 150
  • FIG. 165 An example of the transmission queue in the operations of FIGS. 208 to 150
  • FIG. 166 An example of the transmission queue in the operation of FIGS. 208 to 150
  • FIG. 167 An example of the transmission queue in the operation of FIGS. 208 to 150
  • FIG. 168 An example of the server management table in the operation of FIGS. 208 to 150
  • FIG. 169 is a sequence chart illustrating a synchronization process in the multiplexed database system according to the twentieth embodiment.
  • FIG. 170 is a sequence chart for explaining the synchronization processing in the multiplexed database system according to the twentieth embodiment.
  • FIG. 171 is a sequence chart illustrating a synchronization process in the multiplexed database system according to the twentieth embodiment.
  • FIG. 172 is a sequence chart illustrating a synchronization process in the multiplexed database system according to the twentieth embodiment.
  • FIG. 173 is a sequence chart illustrating a synchronization process in the multiplexed database system according to the twentieth embodiment.
  • FIG. 174 An example of a server management table in the operations of FIGS. 169 to 173
  • FIG. 175 An example of the data structure of the transmission queue in the operations of FIGS. 169 to 173
  • FIG. 176 An example of the transmission queue in the operations in FIGS. 169 to 173
  • FIG. 177 An example of the transmission queue in the operation of FIGS. 169 to 173
  • FIG. 178 An example of a server management table in the operations in FIGS. 169 to 173
  • FIG. 179 An example of the transmission queue in the operation of FIGS. 169 to 173
  • FIGS. 169 to 173 [Fig.180] In the operation of Figs. 169 to 173: An example of transmission queue
  • FIG. 187 is a configuration diagram of a multiplexed database system according to another embodiment.
  • FIG. 188 A configuration diagram of a multiplexed database system according to another embodiment.
  • FIG. 189 A sequence chart illustrating synchronization processing of a multiplexed database system according to another embodiment.
  • FIG.190 A sequence chart illustrating synchronization processing of a multiplexed database system according to another embodiment.
  • FIG. 191 A sequence chart illustrating synchronization processing of a multiplexed database system according to another embodiment.
  • FIG. 192 A configuration diagram of a multiplexed database system according to another embodiment.
  • FIG. 1 is a block diagram illustrating the overall configuration of a multiplexed database system according to the present embodiment.
  • this multiplexed database system is configured by connecting a plurality of database servers (hereinafter, referred to as “servers”) 1100 and an intermediary device 1200 via a network 1300, and via a network 1400. And is accessed from one or more client computers (hereinafter referred to as “clients”) 1500.
  • clients client computers
  • FIG. 1 there are two Sanos 1100a and 1100b, which are accessed from two clients 1500a and 1500b.
  • suffixes “a” and “b” are added. The same applies to client 1500.
  • the server 1100 and the client 1500 are connected to the same network connected to different networks 1300 and 1400, respectively.
  • the mediation apparatus 1200 has an IP address 172.17.1.1 on the network 1400 side, and discloses this as the IP address of the database server.
  • the client 1500 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 1200 at the IP address 172.17.1.1. This is the same as sending and receiving packets to the database server having the IP address 172.17.1.1 for the client 1500.
  • the virtual database server having the IP address 172.17.1.1 is called a virtual server 1800.
  • the purpose of the virtual server 1800 is to hide that the server 1100 is redundant.
  • server 1100b goes down and only server 1100a is running! /, And new servers will be added in addition to server 1100a and server 1100b. And there is no effect on the client and there is no need to change the behavior.
  • the server 1100 includes a database 1101 for storing and managing data, and a database 110 And a database control unit 1102 for controlling the first operation.
  • the database 1101 is an RD BMS (Relational Database Management System) that performs processing by interpreting SQL (Structured Query Language).
  • SQL Structured Query Language
  • databases 1111 such as PostgreSQL (http://www.postgres.org/) by The PostgreSQL Global Development Group, and Oracle (registered trademark) (http: // www.oracle.com).
  • the database control unit 1102 operates based on a packet sent from the mediation device 1200 via the network 1300. This packet is roughly classified into one related to processing in the database 1101 such as SQL, and one related to synchronization processing. For those related to processing in the database 1101, such as SQL, the database control unit 1102 passes the packet to the database 1101, and returns the processing result from the database 1101 to the intermediary device 1200.
  • those relating to the synchronization processing are further divided into those in which they are incorporated in the present system and those in which they are incorporated into the system, such as when recovering from a failure.
  • the database control unit 1102 Upon receiving the snapshot creation instruction from the mediation device 1200, the database control unit 1102 creates a snapshot of the database 1101. Then, when the creation of the snapshot is completed, the completion of the snapshot creation is notified to the mediation apparatus 1200. Then, the created snapshot is transferred to another transfer destination server 1100 specified by the snapshot creation instruction.
  • the database control unit 1122 restores its own database 1101 using this snapshot.
  • a difference information transfer request is sent to the mediation device 1200.
  • the database 1101 is restored using this difference information.
  • the database control unit 1102 transmits an incorporation request to the intermediary device 1200 when incorporating it into the present system.
  • This embedded request is sent when the server 1100 is started or at an arbitrary timing as needed.
  • the mediation device 1200 includes a server management table 1201 for managing the server 1100 in the system, a transaction management table 1202 for managing transactions, a difference information storage unit 1203 for storing difference information for synchronization, and a server A transmission queue 1204 for temporarily storing a query to be transmitted to the server 1100, and a server controller 1210 for mediating processing between the client 1500 and the server 1100 and controlling synchronization of the server 1100 are provided.
  • the server management table 1201 stores a state that the server is operating normally (active) or stopped due to a failure or the like (down).
  • Figure 2 shows an example of the server management table.
  • the server management table 1201 includes a server ID for identifying the server 1100 and an operation state of the server.
  • Sano 1100a and Sano 1100b are registered, and both of the operation states are active indicating normal operation.
  • the IP address assigned to the server 1100 is used as the Serno ID.
  • the transaction management table 1202 stores the presence or absence of a transaction that is currently being executed or whose execution is suspended.
  • FIG. 3 shows an example of the transaction management table 1202.
  • the transaction management table 1202 also 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 1202 at the start of the transaction, and are deleted from the transaction management table 1202 at the end of the transaction.
  • the client ID is, for example, the IP address or port number of the client 1500.
  • the transaction ID is newly assigned by the server control unit 1210 every time a new transaction occurs.
  • the difference information storage unit 1203 stores all queries received from the client 1500 at the time of server synchronization.
  • FIG. 4 shows an example of the difference information stored in the difference information storage unit 1203.
  • each data of the difference information storage unit 1203 includes a query transmitted by the client 1500 and a transaction ID to which the query belongs.
  • the transaction ID is obtained from the transaction management table 1202.
  • a new query from the client 1500 at the time of the synchronization processing is added to the end of the difference information storage unit 1203. That is, old queries are accumulated from the top.
  • BE with transaction ID 1
  • the transmission queue 1204 is a buffer memory that temporarily stores a query received from each client 1500 until it is transmitted to each server 1100.
  • FIG. 5 shows an example of the transmission queue 1204.
  • each data in the transmission queue 1204 includes a query transmitted by the client 1500, a transaction ID to which the query belongs, and transmission information indicating whether or not the query has been transmitted to the server 1100. .
  • the transaction ID is obtained from the transaction management table 1222. New queries from client 1500 are added to the end of this send queue 1204. That is, old queries are accumulated from above.
  • the transmission status of the transmission queue 1204 is set to “not transmitted” when a query is received from the client 1500, and is set to “transmission completed” when transmitted to all the normally operating servers 1100.
  • the entry whose transmission has been completed is deleted from the transmission queue 1204 immediately or after a predetermined period has elapsed.
  • the server control unit 1210 receives a packet from the client 1500 via the network 1400 as a normal process (a process other than the synchronization process), and checks the server management table 1201 for all the normally operating packets.
  • the packet is forwarded to the server 1100.
  • the packet to be transferred to the server 1100 is a query stored as “unsent” in the transmission queue 1204, and is transferred in order from the oldest query stored in the transmission queue 1204.
  • a packet from the server 1100 is received via the network 1300, and one or more of the packets is selected by a packet validity determination method described later, and one correct packet is transmitted to the client 1500 via the network 1400. Transfer to At the time of the synchronization processing, even if the query is “unsent”, the query belonging to the new transaction is not sent, and only the query belonging to the running transaction is sent to the normally operating server 1100 in chronological order.
  • the server control unit 1210 analyzes the processing request from the client 1500, detects the start and end of the transaction, and updates the transaction management table 1202.
  • the method by which the server control unit 1210 detects the start and end of a transaction differs depending on the type of DBMS. For example, in the case of PostgreSQL described above, the transaction starts when the client sends the SQL "BEGIN" 1500 and the transaction ends when the client sends SQL. It is when I sent the SQL of 1500 COMMIT and ROLLBACK. In the case of Oracle, the transaction starts at client 1500
  • a method of determining the validity of a packet for example, there is a method of determining by a majority decision or a method of determining a received packet based on a predetermined rule. For example, if a response from the client 1500 to a “reference” request is “update succeeded”, there is no such response if it is normal. ), Judge that this response packet is not correct. If the data length field is present in the packet, 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. In addition, one master server is also determined in advance for the power of multiple servers 1100, and this
  • the server control unit 1210 determines that the server 1100 that has transmitted the invalid response is a failure, and removes the registration of the server 1100 from the server management table 1201 to disconnect the system power.
  • the server 1100 that does not return a response is also determined to be a failure.
  • server control unit 1210 upon receiving a system installation request from server 1100 via network 1300, server control unit 1210 performs a process of synchronizing the new server 1100 and the normally operating server 1100. . The processing will be described below.
  • the server control unit 1210 Upon receiving the request for incorporating the system from the server 1100, the server control unit 1210 sends a snapshot creation instruction to the normally operating server 1100.
  • the timing for sending the snapshot creation instruction is required to be such that the server 1100 is not executing a transaction. This is to prevent the data from being synchronized if the transaction rolls back during snapshot creation, or because the data is updated in the snapshot because it is COMMITed! /, Na! /. What! This is to prevent this.
  • the server control unit 1210 waits for transmission of a snapshot creation instruction until the transaction being processed ends, and does not start a new transaction until a snapshot creation completion notification is received from the server 1100.
  • the SQL relating to the new transaction is processed by the normally operating server 1100 after receiving the snapshot creation completion notification, and is stored in the difference information storage unit 1203.
  • the queries stored in the difference information storage unit 1203 are all SQL including transaction control SQL, reference SQL and update SQL.
  • the server control unit 1210 sends a snapshot creation instruction
  • the snapshot is transferred to a new server 1100, and a difference information transfer request is sent from the server 1100 to the server control unit 1210.
  • the server control unit 1210 receives the difference information transfer request
  • the server control unit 1210 sequentially transmits the queries stored in the difference information storage unit 1203 to the new server 1100, including the oldest query.
  • the server control unit 1210 updates the server management table 1201 so that the new server 1100 can be incorporated into the system.
  • the server control unit 1210 may receive a new query from the client 1500 during the transmission of the difference information.
  • the server control unit 1210 adds the query to the end of the difference information storage unit 1203 and performs normal operation. It may be sent to the running server 1100.
  • the query transmission frequency of the client 1500 is high, it may take a long time until the transmission of the difference information, that is, the synchronization is completed. Therefore, when the number of untransmitted difference information in the difference information storage unit 1203 becomes equal to or smaller than the predetermined number, the query from the client 1500 is temporarily suspended and only the difference information is transmitted, and the transmission of the difference information is completed first. Then, as described above, the server management table 12 After updating 01, it is preferable to resume the suspended query processing.
  • the client 1500 issues an update query (a request for updating the database) and a reference query (a request for referring to the contents of the database) to the database server.
  • each server 1100a, 1100b has a table test —table! /.
  • the mediation apparatus 1200 When transmitting a packet including the transaction start SQL to the client 1500a 172.17.1.1, the mediation apparatus 1200 receives the packet (step S11).
  • the server control unit 1210 detects that the transaction has started, and registers the IP address and the transaction number of the client 1500a in the transaction management table 1202 (step S12).
  • FIG. 8 shows the transaction management table 1202 at this time. Then, the query relating to this packet is put in the transmission queue 1204 in the transmission state “not transmitted”.
  • the server control unit 1210 fetches the “unsent” query from the transmission queue 1204 and transmits the packet to all the normally operating servers 1100 by looking at the server management table 1201. In this case, since the servers 1100a and 100b are operating normally, the server control unit 1210 transfers the packet to the servers 1100a and 1100b (steps S13 and S14, respectively). Then, since the transmission to each server 1100 is completed, the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the mediation apparatus 1200 receives a response packet notifying that the transaction has started normally from the server 1100a (step S15). However, at this point, not all the response packets have been collected.
  • the server control unit 1210 does nothing and waits for a response packet from the server 1100b. Then, upon receiving a response packet from the server 1100b notifying that the transaction has started normally (step S 16) Since all the response packets are prepared, the server control unit 1210 compares the response packets with each other to check whether or not the server 1100 has a failure (step S17). In this case, since the two response packets are both packets indicating that the transaction has started normally, it is determined that there is no failure, and one of the response packets is transferred to the client 1500a (step S18).
  • the client 1500a transmits a packet including SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S19).
  • the server control unit 1210 places the received query in the transmission queue 1204. Then, the query is taken out from the transmission queue 1204, and the server is referred to the server management table 1201, and the packet is transferred to the normally operating server, in this case, the servers 1100a and 100b (steps S110 and S111, respectively).
  • the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the server 110 Oa transmits a response packet notifying that the UPDATE has been completed normally to the mediation device 1200, and the mediation device 1200 receives this response packet (step S112).
  • step S113 when a response packet notifying that the UPDATE has been normally completed is received from the server 1100b (step S113), since all the response packets are completed, the server controller 1210 compares the response packets with each other. Then, it is checked whether the server 1100 has a failure or not (step S114). In this case, since the two response packets are both packets indicating that the UPDATE was successful, it is determined that there is no failure, and one of the response packets is transferred to the client 1500a (step S115).
  • the client 1500a sends a packet containing SQL (COMMIT) to confirm the update to the table test-table (actually update the database) to 172.17.1.1 (step S116).
  • the server control unit 1210 places the received query in the transmission queue 1204. Then, the query is taken out from the transmission queue 1204, and the server is operated normally by looking at the server management table 1201, and in this case, the packet is transferred to the server 1100a and the server 1100b (steps S117 and S118, respectively).
  • the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the server 1100a sends a packet notifying that the COMMIT has been completed normally to the mediation device 1200, and the mediation device 1200 The packet is received (step S119). At this point, since not all response packets are available, the server control unit 1210 waits without doing anything. Then, upon receiving a response packet notifying that the COMMIT has been completed normally from the server 1100b (step S120), the server control unit 1210 compares all the response packets with each other because all the response packets have been prepared. Then, it is checked whether or not the server 1100 has a failure (step S121). In this case, since the two response packets are both packets indicating that the COMMIT was successful, it is determined that there is no failure.
  • the server control unit 1210 deletes the registration of this transaction from the transaction management table 1202 because the completion of the transaction is a factor in the successful completion of the COMMIT (step S122). At this time, the transaction management table 1202 is again in the initial state (ie, empty). The server control unit 1210 transfers one of the response packets to the client 1500a (step S123).
  • mediation apparatus 1200 receives the packet (step S130).
  • the server control unit 1210 detects that the transaction has started, and registers the IP address and the transaction number of the client 1500a in the transaction management table 1202 (Step S131).
  • FIG. 10 shows the transaction management table 1202 at this time. Then, the query relating to this bucket is put in the transmission queue 1204 in the transmission state “not transmitted”.
  • the server control unit 1210 fetches the "unsent" query from the transmission queue 1204, and looks at the server management table 1201 to check all the normally operating servers 1100, in this case, the servers 1100a and 100b.
  • the packet is transferred to (steps S132 and S133, respectively).
  • the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the mediation apparatus 1200 receives a response packet notifying that the transaction has been started normally from the server 1100a (step S134). At this point, all the response packets are still collected. hand! Therefore, in this case (response packet from server 1100b comes! / ⁇ ⁇ !
  • Server control unit 1210 does nothing and waits for a response packet from server 1100b. Then, when the server 1100b also receives a response packet notifying that the transaction has started normally (step S135), the server control unit 1210 exchanges those response packets because all the response packets have been prepared. Then, it is checked whether or not a failure has occurred in the server 1100 (step S136). In this case, since the two response packets are both packets indicating that the transaction has started normally, it is determined that there is no failure, and one of the response packets is transferred to the client 1500a (step S137).
  • step S138 it is assumed that after returning the response packet in step S135, the server 1100b goes down due to a failure such as a failure (step S138).
  • the client 1500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S139).
  • the server control unit 1210 places the received query in the transmission queue 1204. Then, the query is taken out of the transmission queue 1204, and the server is referred to the server management table 1201 to transfer the packet to the normally operating server, in this case, the servers 1100a and 100b (steps S140 and S141, respectively).
  • the server control unit 1210 does not know that the server 1100b has gone down, if the server 1100b operates normally, the information remains stored in the server management table 1201. In,,, the transmission status of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the server 1100a transmits a response packet notifying that the UPDATE has been completed normally to the mediation device 1200, and the mediation device 1200 receives this response packet (step S142).
  • the server control unit 1210 waits without doing anything.
  • the server control unit 1210 since the server 1100b is down, the response packet from the server 1100b does not reach the intermediary device 1200 forever.
  • the server control unit 1210 times out and detects that the server 1100b is down.
  • the server control unit 1210 rewrites the server 1100b in the server management table 1201 from active to down (server stopped state) (step S143).
  • FIG. 11 shows the server management table 1201 at that time.
  • the server control unit 1210 transfers the response packet to the client 1500a (Step S144). In this case, the client 1500a does not know if the server 1100b has failed. It should be noted that services can be received from the virtual server 1800 as before.
  • the client 1500a transmits a packet containing SQL (COMMIT) for confirming the update to the table test-table to 172.17.1.1 (step S145).
  • the server control unit 1210 puts the received query in the transmission queue 1204. Then, the query is extracted from the transmission queue 1204, and the packet is transferred to only the server that is operating normally, in this case, the server 1100a, by referring to the server management table 1201 (step S146).
  • the transmission status of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the server 1100a transmits a response packet notifying that the COMMIT has been completed normally, and the mediation device 1200 receives this response packet (step S147).
  • the server control unit 1210 deletes the registration of this transaction from the transaction management table 1202 because the completion of the transaction is a component of the successful completion of the COMMIT (step S148). At this time, the transaction management table 1202 returns to the initial state (ie, empty). The server control unit 1210 transfers the response packet to the client 1500a (Step S149).
  • the database 1101a of the server 1100a reflects the UPDATE (step S139) from the client 1500a !, whereas the database 110 lb of the server 1 100b has the client 110b. It should be noted that the UPDATE from 1500a (step S139) is not reflected, that is, the database 1101a and the database 1101b are out of synchronization.
  • the database 1101b is out of synchronization with the database 1101a, that is, not in the same state.
  • the database 1101b may retain the data immediately before the failure of step S138 in FIG. 9 may be performed, or may be completely new, and may not have any data in the case of a server. .
  • the old data is deleted, and the 110 lb database retains the data at all and the system is! /, Na! /, Etc. System. That is, there is no need to keep old data before step SI 38.
  • server management table 1201 is as shown in FIG. It is also assumed that the transaction management table 1202 and the difference information storage unit 1203 are empty.
  • mediation apparatus 1200 receives the packet (step S160).
  • the server control unit 1210 detects that the transaction has started, and registers the IP address and the transaction number of the client 1500a in the transaction management table 1202 (Step S161).
  • FIG. 16 shows the transaction management table 1202 at this time.
  • the server control unit 1210 places the received query in the transmission queue 1204. Then, the query is extracted from the transmission queue 1204, and the normally operating server is looked at the server management table 1201, and the packet is transferred to the server 1100a in this case (step S162). Next, the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • mediation apparatus 1200 transfers the response packet to client 1500a (step S164).
  • the server 1100b is powered on and started.
  • the database control unit 1102b of the server 1100b transmits a database synchronization request to the mediation device 1200 (step S165).
  • the server control unit 1210 Upon receiving the database synchronization request, the server control unit 1210 checks the transaction management table 1202 to confirm whether there is a transaction currently being executed, and records information on the transaction being executed. (Step S166). According to Fig. 16, the transaction of client 1500a and transaction number 3 is being executed, so the database synchronization operation waits for the end of this transaction and, when a new transaction start request is received, sends the request to server 1100a. Is delayed (step S167). That is, the synchronization operation starts with no transactions in progress. The transfer delay processing for the request to start a new transaction is realized by means of suspension in the transmission queue 1204 and other means.
  • the client 1500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S168).
  • the server control unit 1210 places the received query in the transmission queue 1204. Since this query can be determined to belong to the transaction executed at the time of the transaction information power synchronization request stored in step S166, the server control unit 1210 extracts the query from the transmission queue 1204 and stores the query in the server management table 1201. In this case, the normally operating Sano transfers the packet to the server 1100a (step S169).
  • the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the server 1100a transmits a response packet notifying that the UPDATE has been completed normally to the mediation device 1200, and the mediation device 1200 receives this response packet (step S170).
  • the server control unit 1210 transfers the response packet to the client 1500a (Step S171).
  • mediation apparatus 1200 receives the packet (step S172).
  • the server control unit 1210 detects that the transaction has been started by this packet, and registers the IP address and the transaction number of the client 1500b in the transaction management table 1202 (step S173).
  • FIG. 17 shows the transaction management table 1202 at this time.
  • the query relating to this packet is put in the transmission queue 1204 in the transmission state “not transmitted”.
  • the new transaction start query is not transferred to the server 1100a while being held in the transmission queue 1204! (Step S174)
  • the client 1500a transmits a packet containing SQL (CO MMIT) for confirming the update to the table test-table to 172.11.1.1 (step S175).
  • the server control unit 1210 puts the received query in the transmission queue 1204. Since this query can be determined from the transaction information stored in step S 166 as belonging to the transaction executed at the time of the synchronization request, the server control unit 1210 extracts the query from the transmission queue 1204 and retrieves the query from the server management table 1201. In this case, the packet is transferred to only the server 1100a (step S176).
  • the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • Server 1100a successfully C A response packet notifying that the OMMIT has been completed is transmitted to the mediation device 1200, and the mediation device 1200 receives this response packet (step S177).
  • the server control unit 1210 deletes the registration of this transaction from the transaction management table 1202 because the COMMIT has been completed normally and the transaction has been completed (Step S178).
  • FIG. 18 shows the transaction management table 1202 at this time.
  • the server control unit 1210 transfers the response packet to the client 1500a (Step S179).
  • step S180 the server control unit 1210 starts the synchronization operation (step S180). Specifically, as shown in FIG. 13, first, the server control unit 1210 transmits a packet of a synchronization instruction (snapshot creation instruction) to the server 1100a (step S181). In step 180, it is necessary to determine whether the transaction recorded in the transaction management table 1202 was being executed at the time of the synchronization request or was subsequently received from the client 1500.
  • the transaction information at the time of the synchronization request recorded in step S166 may be referred to.
  • Step S182 Upon receiving the synchronization instruction, the database control unit 1102a of the server 1100a creates a snapshot of the database 1101a (Step S182). It should be noted here that this snapshot is backup data of the entire database at the time of receiving the synchronization instruction and information for restoring the database, and does not reflect updates after the synchronization instruction. is there.
  • Step S183 and notifies that to the mediation apparatus 1200 (Step S184).
  • the database control unit 1102a transfers the created snapshot to the server 1100b, and the database control unit 1102b of the server 1100b restores the database from the snapshot received from the server 1100a (Step S185).
  • the transfer of the snapshot and the restoration of the database are performed in parallel with the larger the size of the database iioia. This is performed in parallel with the database access from the client, so the service to the client is not stopped.
  • the server control unit 1210 of the mediation device 1200 that has received the snapshot creation completion notification Resumes service to client 1500.
  • the packet containing the BEGIN from the client 1500b is resumed without being processed and retained in the transmission queue 1204! /. That is, the server control unit 1210 takes out the packet containing the BEGIN SQL from the client 1500 b, which has been held without being transferred, from the transmission queue 1204 and stores it in the difference information storage unit 1203 (step S 186). Transfer to 1100a (step S187).
  • the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • step S187 transfer of the snapshot
  • step S185 does not hinder the service to the client.
  • Step S187 and step S188 described below may be performed.
  • the server 1100a transmits a response packet notifying that the transaction has been started normally to the mediation device 1200, and the mediation device 1200 receives this response packet (step S188).
  • the mediation apparatus 1200 transfers this response packet to the client 1500b (Step S189).
  • the server control unit 1210 places the received query in the transmission queue 1204. Then, the query is extracted from the transmission queue 1204, the query is stored in the difference information storage unit 1203 (step S191), and the packet is transmitted to the normally operating server 1100a (step S192). Next, the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the server 1100a has failed in the UPDATE and has transmitted a response packet notifying the fact to the mediation apparatus 1200 (step S193).
  • Mediation apparatus 1200 transmits this response packet to client 1500b (step S194).
  • the client 1500b that has received the UPDATE failure response packet transmits an SQL (ROLLBACK) packet for canceling the transaction to the intermediary device (step S195).
  • the server control unit 1210 places the received query in the transmission queue 1204. Then, the query is extracted from the transmission queue 1204, and the SQL is stored in the difference information storage unit 1203. At the same time (step S196), the packet is transmitted to the normally operating server 11OOa (step S197). Next, the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • step S198 Upon receiving a response packet notifying that the transaction has been successfully rolled back from the server 1100a (step S198), the transaction registration table is deleted from the transaction management table 1202 (step S199), and the response packet is transmitted to the client 1500b. (Step S1100).
  • FIG. 19 shows the difference information storage unit 1203 at this point. Also, the transaction management table 1202 becomes empty.
  • step S1101 the server 1100b transmits a difference information transfer request to the mediation device 1200 (Step S1102).
  • the server control unit 1210 of the mediation device 1200 starts the process of transferring the data stored in the difference information storage unit 1203 to the server 1100b in order from the oldest one, as shown in FIG. (Step S1103).
  • step S 1103 all queries stored in the difference information storage unit 1203 are transferred and processed, so that the databases 1101 a and 101 b are brought into a completely matched state (synchronous state).
  • New queries may be received from client 1500 during processing.
  • the mediation apparatus 1200 receives a query (BEGIN) for starting a new transaction from the client 1500b (Step S1104).
  • Mediation apparatus 1200 registers the new transaction in transaction management table 1202 (step S1105).
  • the query is put in the transmission queue 1204.
  • the query is extracted from the transmission queue 204, added to the end of the difference information storage unit 1203 (step S1106), and transmitted to the normally operating server 1100a (step S1107).
  • the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the response packet is transferred to the client 1500b (step S1109).
  • the query received from the client 1500 during the transfer of the difference information is processed by the server 1100 that is operating normally, and is stored in the difference information storage unit 1203. If this processing is continued, all queries stored in the difference information storage unit 1203 will eventually become new.
  • the difference information is transferred to the server 1100b, and the difference information storage unit 1203 becomes empty.
  • This triggers the difference information transfer process (step SI110).
  • the server control unit 1210 adds the server 1100b to the server management table 1201 and sets the operation state to active, so that the server 110 Ob can be added to the system.
  • FIG. 20 shows the server management table 1201 at this time.
  • the server 1100b is incorporated in the system, and the subsequent operations are the same as those described above with reference to FIG.
  • server 1100 can be incorporated into the system regardless of the storage state of database 1101 of server 1100.
  • the same procedure applies to servers that were originally built into the system but were disconnected due to a failure (including those that lost data due to disk failures), or even completely new servers.
  • the synchronization data stored in the difference information storage unit 1203 for data synchronization in the mediation device 1200 starts to receive power from an installation request from the server 1100 to be installed, and starts accumulating power. Synchronization data does not increase in 1200. As a result, the storage capacity of the intermediary device 1200 can be saved, and occurrence of a failure due to overflow of the storage capacity can be prevented. Further, the server 1100 can be detached arbitrarily.
  • servers can be incorporated and disconnected arbitrarily, so that a flexible system design can be performed according to demands such as usage and budget.
  • the new server 1100b is in the process of restoring the database 1101b from the snapshot (step S1200). Then, when the restoration process of the database 110 lb is completed in the server 1100b (step S1201), and when the Sano 1100b transmits the difference information transfer request to the mediation device 1200 (step S1202), the difference information storage unit 1203 It is assumed that the difference information of a predetermined number or more is stored in. In the example of FIG. 21, it is assumed that the UPDATE query in steps S1203 to S1207 is stored in the difference information storage unit 1203 as the latest difference information.
  • server control unit 1210 of mediation device 1200 when receiving the difference information transfer request from server 1100b, server control unit 1210 of mediation device 1200, as described above, stores each query stored in difference information storage unit 1203 in the old state.
  • the process of transferring the data to the server 1100b in order from the server starts (step S1208).
  • server control unit 1210 has received a new query from client 1500b.
  • the server control unit 1210 receives a packet including an SQL (INSERT) for adding data to the client 1500b (step S1209).
  • the server control unit 1210 receiving the new query during the transfer of the difference information places the received query in the transmission queue 1204. Then, the query is extracted from the transmission queue 1204, and if the number of untransferred queries stored in the difference information storage unit 1203 is larger than a predetermined number, this query is added to the end of the difference information storage unit 1203.
  • the packet is transferred to the normally operating server 1100a (step S1211).
  • the transmission state of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • server control unit 1210 Upon receiving a response packet indicating that the INSERT was successful from server 1100a (step S1212), server control unit 1210 transfers the response packet to client 1500b (step S1213). [0130]
  • the transfer of the difference information to the server 1100b is also performed in parallel with the intermediary device 1200, and as a result, the number of untransferred queries stored in the difference information storage unit 1203 becomes equal to or smaller than a predetermined number. I do.
  • the server control unit 1210 When the server control unit 1210 receives a packet including SQL (UPDATE) for updating the data of the client 1500b (step S1214), the server control unit 1210 places the received query in the transmission queue 1204.
  • the processing of this new query is suspended (step S1215). That is, the new query is not stored in the difference information storage unit 1203 and is not transferred to the server 1100a.
  • This suspension process transfers all the queries stored in the difference information storage unit 1203 to the server 1100b, and continues until the server 1100b is incorporated into the system.
  • step S1216 When the transfer of the difference information is completed (step S1216), all the queries stored in the difference information storage unit 1203 are transferred and processed, so that the databases 1101a and 101b completely match (synchronization state). )become. Therefore, the server control unit 1210 adds the server 1100b to the system by adding the server 1100b to the server management table 1201 and setting the operation state to active (step S1217).
  • the server control unit 1210 resumes the processing of the new query suspended in step S1215.
  • the subsequent processing is the same as that described above with reference to FIG. That is, the server control unit 1210 takes out the query from the transmission queue 1204 and transfers the server that is operating normally, in this case, the servers 1100a and 100b (steps S1218 and S1219).
  • the transmission status of the transmission queue 1204 is set to “transmission completed”, and the entry is deleted.
  • the server 1100a and the server 100b also compare the received response packets to determine whether a failure has occurred (steps SI220 to S1222), and transfer one of the normal response packets to the client 1500b (step S1223).
  • the query received from the client during the transfer of the difference information is stored in the difference information storage unit 1203 and stored in the server 1100b when the untransmitted difference information is larger than the predetermined number.
  • a transfer is performed.
  • the untransferred difference information is less than a predetermined number, New queries are suspended. This makes it possible to synchronize the database in a short period of time when the processing of the difference information takes a long time, even when the reception interval of the query received from the client is short.
  • the “predetermined number” which is a threshold value, has a trade-off relationship in that setting a large value increases the hold time of a new query, while setting a small value lengthens the time to complete synchronization processing.
  • the “predetermined number” may be set to an optimal value individually according to the requirements of the system such as the processing load of each device and the network speed. If the threshold value is set to 0 or less in this modification, the same processing as that of the embodiment described above with reference to FIGS.
  • a multiplex database system according to a second embodiment of the present invention will be described.
  • the difference between the multiplexed database system according to the present embodiment and the first embodiment lies in the contents of the difference information transferred to the new server.
  • Other configurations and operations are the same as those of the first embodiment, and therefore, only the differences will be described here.
  • all the queries received from the client 1500 are stored and transferred to the difference information storage unit 1203.
  • queries processed by the normally operating server 1100 during the synchronization process can be faithfully reproduced on the new server 1100, so that complete synchronization can be achieved. .
  • server control section 1210 performs the first execution. As in the embodiment, all the queries received from the client 1500 are stored in the difference information storage unit 1203. Then, when transferring the difference information to the new server 1100, it is first determined whether or not the query is a reference query, and other than the reference query is transferred to the new server 1100. Other processes are the same as in the first embodiment.
  • the new server 1100 does not need to process the reference query at the time of the synchronization processing, so that the synchronization processing can be shortened. Can be. This is particularly effective when the client 1500 issues a reference SQL having a large processing load such as a complicated reference SQL or a reference SQL including a set function. Other effects are the same as in the first embodiment.
  • the server control unit 1210 receives a query from the client 1500 during the synchronization process, and accumulates the query as difference information in the difference information storage unit 1203, First, it is determined whether the query is a reference query, and information other than the reference query is stored in the difference information storage unit 1203. Then, there is a method of transferring the difference information for all the queries stored in the difference information storage unit 1203. This modification has the effect that the storage capacity of the difference information storage unit 1203 can be further reduced.
  • a multiplex database system according to a third embodiment of the present invention will be described.
  • the difference between the multiplexed database system according to the present embodiment and the first embodiment lies in the process of accumulating difference information during the database synchronization operation.
  • Other configurations and operations are the same as those of the first embodiment, and therefore, only the differences will be described here.
  • server control section 1210 stores all packets received from client 1500 in difference information storage section 1203. That is, the transaction control SQL, the reference SQL, and the update SQL are all stored in the difference information storage unit 1203, and all the data stored in the difference information storage unit 1203 are stored in the server 1100. We sent in order of power.
  • server control unit 1210 includes, among the packets received from client 1500 during the database synchronization operation, transaction start SQL (BEGIN), definitive SQL (COMMIT), and cancel SQL (ROLLBACK ) Etc. transaction control SQ
  • the reference information SQL such as L and SELECT is not stored, but only the update SQL such as UPDATE or INSERT that is COMMITted by the normally operating server 1100 is stored in the difference information storage unit 1203.
  • the difference information accumulating unit 1203 accumulates update queries in the order in which they were processed by the normally operating server 1100 instead of the order in which they were received from the client 1500. This is because the contents of the database 1101 may be different depending on the processing order of an update query whose update target is duplicated.
  • a difference information temporary storage unit 1205 as shown in FIG. 23 is newly provided.
  • the data structure of the difference information temporary storage unit 1205 includes the query received from the client and the ID of the transaction to which the query belongs.
  • the server control unit 1210 When the server control unit 1210 receives a query from the client 1500 during the synchronization process, the server control unit 1210 sequentially stores only the update type one in the difference information temporary storage unit 1205 and transfers it to the normally operating server 1100 I do. On the other hand, those other than the updater are transferred to the normally operating server 1100 without being stored in the difference information temporary storage unit 1205.
  • the server control unit 1210 upon receiving a response packet indicating that the execution of the update query has failed from the normally operating server 1100, deletes the update query from the difference information temporary storage unit 1205. Further, upon receiving a response packet indicating that the RO LLBACK of the transaction has been completed normally from the normally operating server 1100, the server control unit 1210 also stores all update queries belonging to the transaction in the difference information temporary storage unit 1205. delete. On the other hand, when receiving a response packet indicating that the transaction COMMIT has been completed normally from the normally operating server 1100, the server control unit 1210 sends the update information belonging to the transaction the difference information temporary storage unit 1205 to the difference information storage unit 1203. Sequentially.
  • reference queries unnecessary for synchronization processing and transaction control SQL such as BEGIN and ROLLBACK are not stored in the difference information storage unit 1203.
  • the transfer time of the difference information and the processing time at the server can be reduced.
  • Other effects are the same as in the first embodiment.
  • the query received from the client 1500 is transmitted from the difference information temporary storage unit 205 to the difference information storage unit at the time when the transaction to which the query belongs is COMMITed by the server 1100 that is operating normally.
  • the query may be moved at the time when the query is normally processed by the normally operating server 1100.
  • the update query belonging to the transaction may be deleted from the difference information storage unit 203 after the transaction ROLLBACK. This kind of processing is effective to completely match the database of a DBMS whose row order changes according to the update order, such as PostgreSQL.
  • a multiplex database system according to a fourth embodiment of the present invention will be described.
  • the multiplexed database system according to the present embodiment differs from the first embodiment in the structure of the difference information storage unit. Since other configurations and operations are the same as those of the first embodiment, only the differences will be described here.
  • the mediation device 1200 does not include the difference information accumulating unit 1203, and the transmission queue 1206 stores the difference information according to the first embodiment.
  • the functions of the information storage unit 1203 and the transmission queue 1204 are integrated.
  • the transmission queue 1206 stores the content of the query received from the client 1500, the transaction ID to which the query belongs, and the status of transmission to each server 1100.
  • the transaction ID is obtained from the transaction management table 1202 as in the first embodiment.
  • the transmission status to each server 1100 is stored for each server 1100 belonging to the system.
  • the transmission state of the transmission queue 1206 to each server 1100 can take three values: “not transmitted”, “transmission completed”, and “hold”. “Not sent” means that the query received from the client 1500 has not been sent to the server 1100 yet. “Transmission completed” is a state in which transmission to the server 1100 has been completed. “Hold” is a state in which the new server 1100 is held without being transferred to the server 1100 during the process of incorporating the new server 1100 into the system. When the transmission status of all the servers 1100 becomes “transmission completed”, the entry is deleted from the transmission queue 1206.
  • server control unit 1210 When the server control unit 1210 receives a query from the client 1500, if the query is a transaction start SQL (BEGIN), the server control unit 1210 issues a new transaction ID to the transaction and registers it in the transaction management table 1202. Then, the content of the query, the new transaction ID, and the transmission status of each server 1100 are registered in the transmission queue 1206 as “not transmitted”. If the query received from the client 1500 is not a transaction start SQL (BEGIN), the transaction ID to which the query belongs is acquired from the transaction management table 1202, and the query content, transaction ID, and transmission status of each server 1100 are obtained. It is registered in the transmission queue 1206 with "not sent”.
  • BEGIN transaction start SQL
  • the server control unit 1210 transmits the query recorded in the transmission queue 1206 to the server 1100 whose transmission status is “not transmitted”, and sends the query to the server 1100. Change the transmission status of to "Transmission completed”. The queries for which the transmission status is “transmission completed” for all the servers 1100 are deleted from the transmission queue 1206.
  • Each server 1100 that has received the query from the mediation device 1200 processes the query and returns a response packet to the mediation device 1200.
  • the server control unit 1210 of the mediation device 1200 compares the response packets received from each server 1100 to determine whether a failure has occurred, and returns one of the normal response packets to the client 1500.
  • FIG. 26 shows an example of the transmission queue 1206 when the server 1100b is disconnected from the system with the transmission queue 1206 as shown in FIG.
  • the server control unit 1210 suspends the start of a new transaction until the transaction being executed at the time of receiving the embedded request ends. Specifically, when the query received from the client 1500 relates to a new transaction, the transmission status is stored in the transmission queue 1206 as “pending”. On the other hand, if the query received from the client 1500 relates to the transaction being executed at the time of the embedded request, the transmission status is stored in the transmission queue 1206 as “not transmitted”.
  • FIG. 27 is an example of the transmission queue 1206 when the transmission queue 1206 newly receives a query from the client 1500 in the state shown in FIG.
  • the server control unit 1210 stores the new server 1100 to be embedded in the transmission queue 1206. Add items.
  • the transmission queue 1206 may store a query whose transmission status is “pending” and may store a query.
  • the server control unit 1210 sets the transmission state of the new server 1100 to “pending” in response to the query stored in the transmission queue 1206.
  • FIG. 28 shows a case where a new server 1100b is registered in the transmission queue 1206 of FIG.
  • the server control unit 1210 executes the normally operating server similarly to the first embodiment. Sends a snapshot creation instruction to the server 1100.
  • the server control unit 1210 Upon receiving the snapshot creation completion notification from the normally operating server 1100, the server control unit 1210 resumes query transmission to the normally operating server 1100. Specifically, first, for all the queries stored in the transmission queue 1206 (at this time, the transmission status of all the tiers is “pending” for all the servers 1100), the server that is operating normally Change the transmission status of 1100 to "not sent”. Then, the server control unit 1210 sequentially transmits queries whose transmission status is “not transmitted” to the server 1100, and corrects the transmission status to “transmission completed” when the transmission is completed.
  • FIG. 29 shows a case where a new query is received after receiving the snapshot completion notification for the transmission queue 1206 in FIG. Also, as shown in Fig. 30, even if the status is "Transmission completed” for the normally operating server 1100a, the status is "Transmission completed” for the new server 1100b. The query is not deleted from the transmission queue 1206.
  • the server control unit 1210 receives a difference information transfer request from the new server 1100.
  • the server control unit 1210 is the query stored in the transmission queue 1206, and the transmission status is “pending”! /, The thing is put into the “hold”! /,
  • the server is sent to the new server 1100, that is, the new one in order from the old one.
  • the transmission status of the server 1100 in the transmission queue 1206 is set to “transmission completed”, and when the transmission status S of all the servers 1100 becomes “transmission completed”, the entry is deleted.
  • the server control unit 1210 adds the new server 1100 to the server management table 1201 as “active” when the query whose transmission status is “pending” no longer exists in the transmission queue 1206.
  • the server 1100 is incorporated into the system. Subsequent operations are the same as those in the case where each server 1100 operates normally.
  • the functions of the difference information storage unit 1203 and the transmission queue 1204 in the first embodiment are integrated into one transmission queue 1206 As a result, memory use efficiency and processing efficiency are improved. Also, since the transmission status to each server 1100 is stored for each query in the transmission queue 1206, the transmission status of the server 1100 may be added when a new server 1100 is incorporated. This allows a plurality of servers 1100 to be incorporated into the system at one time. Other operational effects are the same as in the first embodiment.
  • a multiplex database system according to a fifth embodiment of the present invention will be described.
  • the difference of the multiplexed database system according to the present embodiment from the fourth embodiment lies in the method of storing difference information.
  • Other configurations and operations are the same as those of the fourth embodiment, and therefore, only the differences will be described here.
  • the timing at which the mediation apparatus 1200 transmits a snapshot creation instruction to the normally operating server 1100 is executed by the normally operating server 1100. This is when there are no more transactions. Specifically, in parallel with processing of the transaction being executed at the time of receiving the embedded request from the new server 1100 on the normally operating server 1100, the client 1500 The request to start a new transaction received from was held. Then, when there are no more transactions being executed when the embedded request is received, a snapshot creation instruction is transmitted. This is because, depending on the DBMS, if a transaction is being executed when a snapshot is created, it is uncertain whether the data update by an update query belonging to the transaction is reflected in the snapshot or not.
  • the server 1100 does not reflect the update query belonging to the transaction being executed at the time of snapshot creation and the update query received during the snapshot creation process in the snapshot.
  • the one that performs is used.
  • the server control unit 1210 of the intermediary device 1200 can transmit a snapshot creation instruction and start a new transaction without waiting for the end of the transaction being executed when receiving the embedded request. it can.
  • the mediation device 1200 Since there is no need to wait for the completion of the snapshot creation, the database control unit 1102 of the server 1100 does not need to send a completion notification to the intermediary device 1200 even when the snapshot creation is completed.
  • server control unit 1210 of mediation apparatus 1200 transmits, for each query stored in transmission queue 1206, the transmission status of all servers 1100 to “ When "Transmission completed" and the transaction belonging to the query ends, the registration of the query is deleted.
  • the server control unit 1210 Upon receiving the installation request from the new server 1100b, the server control unit 1210 transmits a synchronization instruction (snapshot creation instruction) to the normally operating server 1100a.
  • FIG. 31 shows an example of the transmission queue 1206 when the new server 1100b transmits an installation request to the mediation device 1200.
  • the server 1100a starts creating a snapshot. The snapshot created here does not reflect the query stored in the transmission queue 1206.
  • the server control unit 1210 sets the transmission state of the new server 1100b to “pending” for all queries stored in the transmission queue 1206 and adds the query. I do.
  • FIG. 32 shows an example of the transmission queue 1206 at this time.
  • the server control unit 1210 When the server control unit 1210 receives a query from the client 1500 after receiving the embedded request, the transmission status of the normally operating server 1100a is "not transmitted”, and the transmission status of the new server 1100b is “not transmitted”. It is put on hold and sequentially added to the transmission queue 1206. Then, when the transmission state becomes “not transmitted”, the query is sequentially transferred to the “untransmitted” server 1100a, and the transmission state is changed to “transmission completed”. At this time, as shown in FIG. 33, for the query stored in the transmission queue 1206, the transmission status of the normally operating server 1100a is “transmission completed” for each transaction, but the new server As for 1100b! / It is "pending"! /, So here we do not delete the query! /.
  • the server 1100a that has received the snapshot creation instruction from the mediation device 1200 transmits the created snapshot to the new server 1100b.
  • the database control unit 1102b of the new server 1100b restores the database 1101b from the received snapshot, and transmits a difference information transfer request to the mediation device 1200.
  • the server control unit 1210 that has received the difference information transfer request stores the query stored in the transmission queue 1206 and the transmission status becomes “pending”! /, And sends the query to the new server 1100b sequentially as difference information. Transmit, and change the transmission state to “transmission completed” as shown in FIG. Then, as described above, when the transmission status of all servers becomes “transmission completed” and the transaction of the query is completed, the query is deleted. Thereafter, when a query is received from the client 1500 during transmission of a query whose transmission status is “pending”, as shown in FIG. 35, the transmission status of both the normally operating server 1100a and the new server 1100b is changed to “untransmitted”. And store it in the transmission queue 1206. Then, when the query of “transmission status ⁇ pending” disappears, the synchronization of the database 100a and the database 100b is completed.
  • the functional requirements of the server 1100 used in the system are limited, the range of server selection is narrowed, but the processing in the mediation device 1200 is simplified, and the processing efficiency is reduced. High, it will be.
  • server 1100 (1) snapshot creation can be started even during transaction execution, (2) a query can be processed during snapshot creation, and the query can be used as a snapshot. (1 ') The ability to start creating a snapshot while a transaction is running (2') The query cannot be processed during snapshot creation! / ⁇ or the query is processed during snapshot creation Then, it is possible to use the server 1100 in which the processing may be reflected in the snapshot.
  • the snapshot creation instruction may be sent to the normally operating server 1100 as soon as the installation request is received from the new server 1100, but the normal operation is performed until the snapshot creation is completed. It is necessary to suspend the sending of queries to the running server 1100.
  • the specific method of the suspension processing is the same as that of the first embodiment, and the description is omitted here.
  • the mediation device 1200 recognizes that the creation of the snapshot has been completed. In order to perform this, the server 1100 that has completed the creation of the snapshot needs to notify the mediation device 1200 of the completion of the creation of the snapshot. As a result, the range of server selection is wider than in the present embodiment.
  • the servers do not need to have the same implementation if they respond the same in response to a request. That is, versions, specifications, programming languages, types of compilers, compiler options, hardware capabilities, software capabilities, and the like may differ.
  • the server can be free software such as PostgreSQL, commercially available software such as Oracle, or proprietary software. They may be mixed.
  • server 1100a may be PostgreSQL and server 1100b may be Oracle.
  • the database control unit 1102 separates the functions into a database management unit and a database server management unit, so that the middle product is not modified.
  • the database management unit directly operates the database 1101, and corresponds to, for example, postmaster or postgres in the case of PostgreSQL.
  • the database server management unit intervenes between the intermediary device 1200 and the database management unit, relays the transmission and reception of queries, creates a snapshot of the database 1101 when synchronizing other servers, It performs processing to transfer the snapshot to other servers.
  • DBMS is PostgreSQL
  • a snapshot is created using a dump tool such as pg—dump or a backup tool.
  • pg-dump is useful for synchronizing Post greSQL servers.
  • heterogeneous DBMSs for example, PostgreSQL and Oracle
  • normal operation is performed without using DBMS-specific tools. You can use a general-purpose tool to retrieve all data from a DBMS server using a SELECT query and enter data using an INSERT query.
  • the request for incorporation into the system (data of the new server Request for synchronization of the new server 1100, the power transmitted by the database control unit 1102 of the new server 1100 to the mediation device 1200 may be transmitted to another device such as a maintenance terminal, or the operator may directly instruct the mediation device 1200. Good.
  • the server is implemented by software on a personal computer, but may be implemented by hardware.
  • only one intermediary device 1200 constituting virtual server 1800 is provided.
  • a configuration with higher availability can be provided.
  • the technology described in Japanese Patent Application Laid-Open No. 2003-345679 by the present applicant may be used.
  • FIG. 37 is a block diagram illustrating the overall configuration of the multiplexed database system according to the present embodiment.
  • this multiplexed database system is a system in which a plurality of database servers (hereinafter, referred to as "servers") 100 and an intermediary device 2200 are connected via a network 2300. And is accessed from one or more client computers (hereinafter referred to as “clients”) 500.
  • clients client computers
  • FIG. 37 three Sanos 2100a, 2100b, and 2100c are provided, and two clients 2500a and 2500b are accessed.
  • lowercase letters such as “a” and “b” are added. The same applies to client 2500! / ⁇ .
  • Sano 2100 and client 2500 may be connected to the same network connected to separate networks 2300 and 2400, respectively.
  • the mediation device 2200 has an IP address 172.17.1.1 on the network 2400 side, and discloses this as the IP address of the database server.
  • the client 2500 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 2200 at the IP address 172.17.1.1. To do. This is the same as sending and receiving packets to / from the database server having the IP address 172.17.1.1 for the client 2500.
  • the virtual database server having the IP address 172.17.1.1 is called a virtual server 2800.
  • the purpose of this virtual server 2800 is to hide that the server 2100 is redundant. In other words, all Sano 2100a, Sano 2100b, and 2100c operate !! If a new server is added to the client, there is no effect on the client, and there is no need to change the operation.
  • the server 2100 includes a database 2101 that stores and manages data, and a database control unit 2102 that controls the operation of the database 2101.
  • the database 2101 is an RD BMS (Relational Database Management System) that performs processing by interpreting SQL (Structured Query Language).
  • SQL Structured Query Language
  • databases 2111 such as PostgreSQL (http://www.postgres.org/) by The PostgreSQL Global Development Group, and Oracle (registered trademark) (http: // www.oracle.com).
  • the database control unit 2102 operates based on a packet transmitted from the mediation device 2200 via the network 2300. These packets are roughly classified into those related to the processing in the database 2101 such as SQL, and those related to the synchronization processing. For those related to processing in the database 2011, such as SQL, the database control unit 2102 passes the packet to the database 2101 and returns the processing result from the database 2101 to the intermediary device 2200.
  • those related to the synchronization processing are further divided into those that are incorporated in the present system and those that are to be incorporated into the system, such as when a failure is recovered.
  • the database control unit 2102 For the former, there is an instruction to create a snapshot.
  • the database control unit 2102 Upon receiving the snapshot creation instruction from the mediation device 2200, the database control unit 2102 creates a snapshot of the database 2101. Then, the created snapshot is transferred to another destination server 2100 specified by the snapshot creation instruction. Server 2100 is temporarily disconnected from the system after the transfer of the snapshot.
  • server 2100 When the snapshot is transferred, the difference information is eventually received from the mediation device 2200 as described later. This difference information is a processing request received by the mediation device 2200 from the client 2500 while the server 2100 is temporarily disconnected from the system.
  • the database control unit 2102 processes this difference information.
  • the database control unit 2102 restores its own database 2101 using this snapshot.
  • a difference information transfer request is sent to the mediation device 2200.
  • the database 2101 is restored using the difference information.
  • the database control unit 2102 When the database control unit 2102 is installed in the present system, the database control unit 2102 transmits an installation request to the mediation device 2200. This embedded request is sent when the server 2100 is started or at an arbitrary timing as needed.
  • the intermediary device 2200 includes a server management table 2201 for managing the server 2100 in the system, a transaction management table 2202 for managing transactions, a difference information storage unit 2203 for storing difference information for synchronization, and a server.
  • a transmission queue 2204 for temporarily storing a query to be transmitted to the 2100, and a server control unit 2210 for mediating the processing between the client 2500 and the server 2100 and controlling the synchronization of the server 2100 are provided.
  • the server management table 2201 stores the status of whether the server is operating normally (active) or has stopped due to a failure (down), and is in synchronization (sync).
  • Figure 38 shows an example of the server management table.
  • the server management table 2201 also includes a server ID for identifying the server 2100 and the operating status of the server.
  • the server 2100a, the server 2100b, and the server 2100c are registered, and the operation status is active, which indicates normal operation.
  • the IP address assigned to each server 2100 is used as the server ID.
  • the transaction management table 2202 stores the presence or absence of a transaction that is currently being executed or whose execution is suspended.
  • FIG. 39 shows an example of the transaction management table 2202.
  • the transaction management table 2202 contains a query that uniquely identifies the client.
  • a transaction ID is also configured to uniquely identify the client ID and the transaction. These pairs are registered in the transaction management table 2202 at the start of the transaction, and are deleted from the transaction management table 2202 at the end of the transaction.
  • the client ID is, for example, the IP address or port number of the client 2500.
  • the server ID is newly assigned by the server control unit 2210 every time a new transaction occurs.
  • the difference information storage unit 2203 stores all queries received from the client 2500 at the time of server synchronization.
  • FIG. 40 shows an example of the difference information stored in the difference information storage unit 2203.
  • each data of the difference information storage unit 2203 is composed of a query transmitted by the client 2500 and a transaction ID to which the query belongs.
  • the transaction ID is obtained from the transaction management table 2202.
  • a new query from the client 2500 at the time of the synchronization processing is added to the end of the difference information storage unit 2203. In other words, old queries are accumulated.
  • the transmission queue 2204 is a buffer memory that temporarily stores the query received from each client 2500 until it is transmitted to each server 2100.
  • FIG. 41 shows an example of the transmission queue 2204.
  • each data of the transmission queue 2204 includes a query transmitted by the client 2500, a transaction ID to which the query belongs, and transmission information indicating whether or not the query is transmitted to the server 2100.
  • the transaction ID is obtained from the transaction management table 2 202.
  • New queries from client 2500 are added to the end of this send queue 2204. That is, old queries are accumulated from the top.
  • the transmission state of the transmission queue 2204 is set to “not transmitted” when a query is received from the client 2500, and is set to “transmission completed” when transmitted to all the normally operating servers 2100.
  • the entry whose transmission has been completed is deleted from the transmission queue 2204 immediately or after a predetermined period has elapsed.
  • the server control unit 2210 receives a packet from the client 2500 via the network 2400 as a normal process (a process other than the synchronization process), and checks the server management table 2201 for all the normal operations.
  • the packet is forwarded to the server 2100.
  • server 2100 The packet transferred to the transmission queue 2204 is a query stored as “unsent” in the transmission queue 2204, and is transferred in order from the oldest query stored in the transmission queue 2204. Then, a packet from the server 2100 is received via the network 2300, and one or more of the packets is selected by a packet validity determination method described later, and one correct packet is transmitted to the client 2500 via the network 2400. Transfer to During the synchronization process, even if the query is “unsent”, the query belonging to the new transaction is not sent, and only the query belonging to the running transaction is sent to the normally operating server 2100 in chronological order.
  • the server control unit 2210 analyzes the processing request from the client 2500, detects the start and end of the transaction, and updates the transaction management table 2202.
  • the method by which the server control unit 2210 detects the start and end of a transaction differs depending on the type of DBMS.
  • the transaction starts when the client sends the SQL of 2500 S (BEGIN), and the transaction ends when the client sends the SQL of 2500 COMMIT and ROLLBACK.
  • the transaction starts when the client 2500 sends a valid SQL (there is no explicit SQL to declare the start of the transaction), and the client 2500 ends the “COMMIT” This is when the SQL “ROLLBACK” was sent.
  • the SQL statements received from the client 2500 can be interpreted as belonging to one independent transaction. It can be treated as if the transaction started before and the transaction ended after SQL execution.
  • a method of determining the validity of a packet for example, there is a method of determining by a majority decision, or a method of determining a received packet based on a predetermined rule. For example, if a response "Resuccessful" is returned in response to a "reference" request from a client 2500, such a response is not possible if it is normal. ), Judge that this response packet is not correct. If there is a data length field in the packet, the value of this data length field is compared with the actually received packet length. Judge not.
  • the master server of the plurality of servers 2100 is also determined in advance, and the packet from this server 2100 is always determined to be correct.
  • the server control unit 2210 determines that the server 2100 that has transmitted the invalid response is a failure, and also removes the registration of the server 2100 from the server management table 2201, thereby separating the system power.
  • the server 2100 that does not return a response is also determined to be a failure.
  • the server control unit 2210 upon receiving the request for incorporating the system from the server 2100 via the network 2300, performs a process of synchronizing the new server 2100 and the normally operating server 2100. . The processing will be described below.
  • the server control unit 2210 When the server control unit 2210 receives the request to incorporate the system from the server 2100, the server control unit 2210 selects one server 2100 from the plurality of normally operating servers 2100, and instructs the server 2100 to create a snapshot. Send out. Then, the server 2100 that has sent the snapshot creation instruction changes the status of the server management table 2101 to “sync” to disconnect the system power.
  • the server 2100 in which the status of the server management table 2101 is “sync” is referred to as “synchronization server 2100”.
  • the server 2100 whose status is “active” is referred to as “normally operating server 2100”.
  • the timing at which a snapshot creation instruction is sent requires that the server 2100 is not executing a transaction. This is to prevent the data from being out of sync if the transaction rolls back during the creation of the snapshot. What! This is to prevent this. For this reason, the server control unit 2210 waits for transmission of a snapshot creation instruction until the transaction being processed ends, and does not start a new transaction until the snapshot creation instruction is transmitted. Then, for the SQL relating to the new transaction, after sending the snapshot creation instruction, the SQL It is processed by the active server 2100 and stored in the difference information storage unit 2203.
  • the queries stored in the difference information storage unit 2203 are all SQL including transaction control SQL, reference SQL and update SQL.
  • the server control unit 2210 sends a snapshot creation instruction
  • the snapshot is transferred to a new server 2100
  • a difference information transfer request is sent from the server 2100 to the server control unit 2210.
  • the server control unit 2210 sequentially transmits the queries stored in the difference information storage unit 2203 to the new server 2100 and the synchronization server 2100, including the oldest one.
  • the server control unit 2210 updates the server management table 2201 so as to incorporate the new server 2100 and the synchronization server 2100 into the system.
  • the server control unit 2210 may receive a new query from the client 2500 while transmitting the difference information.
  • the server control unit 2210 adds the query to the end of the difference information storage unit 2203 and performs normal operation. What is necessary is just to transmit to the running server 2100.
  • the query frequency of the client 2500 is high, it may take a long time until the transmission of the difference information, that is, the synchronization is completed. Therefore, when the number of untransmitted difference information in the difference information storage unit 2203 becomes equal to or smaller than the predetermined number, the query from the client 2500 is temporarily suspended, and only the difference information is transmitted, and first, the transmission of the difference information is completed. Then, as described above, after updating the server management table 2201 to incorporate the new server 2100 and the synchronization server 2100 into the system, it is preferable to resume the suspended query processing.
  • the client 2500 issues an update query (a request for updating the database) or a reference query (a request for referring to the contents of the database) to the database server 2100.
  • databases 2101a, 2101b, and 2101c are completely identical, Assume that the management table 2201 is as shown in Figure 43. It is also assumed that the transaction management table 2202 and the difference ⁇ green information accumulation ⁇ 2203 are empty. Suppose that each Sano 2100a, 2100b, 2100c has a table test—table! /.
  • the mediation apparatus 2200 receives the packet (step S21).
  • the server control unit 2210 detects that the transaction has started, and registers the IP address and the transaction number of the client 2500a in the transaction management table 2202 (Step S22).
  • FIG. 44 shows the transaction management table 2202 at this time. Then, the query relating to this packet is put in the transmission queue 2204 in the transmission state “not transmitted”.
  • the server control unit 2210 extracts the "unsent" query from the transmission queue 2204, and transmits the packet to all the normally operating servers 2100 by looking at the server management table 2201. In this case, since Sano 2100a, 2100b, and 2100c are operating normally, server control unit 2210 transfers the packet to server 2100a, server 2100b, and 2100c (steps S23 to S25). Then, since the transmission to each server 2100 is completed, the transmission status of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 2200 waits until response packets are received from all the servers 2100 (steps S26 to S28), and when all the response packets are complete, the server 2100 fails by comparing the response packets with each other. It is checked whether or not the power is present (step S29). In this case, since all three response packets indicate that the transaction has started normally, it is determined that there is no failure, and one of the response packets is transferred to the client 2500a (step S210).
  • the client 2500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S211).
  • the server control unit 2210 places the received query in the transmission queue 2204. Then, the query is taken out from the transmission queue 2204, and the server is referred to the server management table 2201 to transfer the packet to the normally operating Sano, in this case, the servers 2100a, 2100b, and 2100c (steps S212 to S214).
  • the transmission status of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 2200 waits until all the servers 2100 have received the response packets (steps S215 to S217), and when all the response packets are available, compares the response packets with each other. No. It is checked whether or not the force has a failure in the 2100 (step S218). In this case, since all three response packets are packets indicating that the UPDATE was successful, it is determined that there is no failure and one of the response packets is transferred to the client 2500a (step S219).
  • the client 2500a transmits a packet containing SQL (COMMIT) confirming the update to the table test-table (actually updating the database) to 172.17.1.1 (step S220).
  • the server control unit 2210 places the received query in the transmission queue 2204. Then, the query is extracted from the transmission queue 2204, and the server refers to the server management table 2201, and transfers the ticket to the normally operating Sano, in this case, Sano 2100a, Sano 2100b, and 100c (steps S221 to S223).
  • the transmission state of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 2200 waits until all the servers 2100 have received the response packets (steps S224 to S226), and when all the response packets are completed, the server 2100 compares the response packets with each other to determine whether a failure has occurred in the server 2100. It is checked whether or not it is (step S227). In this case, since all three response packets are packets indicating that the COM MMIT was successful, it is determined that there is no failure. The server control unit 2210 deletes the registration of this transaction from the transaction management table 2202 because the completion of the transaction is a result of the successful completion of the COMMIT (step S228). At this time, the transaction management table 2202 is again in the initial state (that is, empty). The server control unit 2210 transfers one of the response packets to the client 2500a (Step S229).
  • mediation apparatus 2200 receives the packet (step S230).
  • the server control unit 2210 detects that the transaction has started, and registers the IP address and the transaction number of the client 2500a in the transaction management table 2202 (step S231).
  • FIG. 46 shows the transaction management table 2202 at this time. And this bucket The query relating to the request is put in the transmission queue 2204 in the transmission state “not transmitted”.
  • the server control unit 2210 fetches the "unsent" query from the transmission queue 2204, and refers to the server management table 2201 to check all the normally operating servers 2100, in this case, the servers 2100a and 2100b. And transfer the packet to 2100c (steps S232 to S234).
  • the transmission state of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 2200 waits until response packets are received from all the servers 2100 (steps S235 to S237), and when all the response packets have been collected, a failure occurs in the server 2100 by comparing the response packets with each other. Then, it is checked whether or not the power is low (step S238). In this case, since all three response packets are packets indicating that the transaction has started normally, it is determined that there is no failure, and one of the response packets is transferred to the client 2500a (step S239).
  • step S240 it is assumed that after returning the response packet in step S237, the server 2100c goes down due to a failure such as a failure (step S240).
  • the client 2500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S241).
  • the server control unit 2210 places the received query in the transmission queue 2204. Then, the query is taken out of the transmission queue 2204, and the packet is transferred to the normally operating Sano, in this case, the servers 2100a, 2100b, and 2100c by referring to the server management table 2201 (steps S242 to S244). At this point, the server control unit 2210 does not know that the server 2100c is down, so that when the server 2100c operates normally, the information is still stored in the server management table 2201.
  • the transmission status of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the servers 2100a and 2100b transmit the response packet to the mediation device 2200, and the mediation device 2200 receives this response packet (Steps S245, S246). At this point, not all the response packets are available, so the server control unit 2210 waits for response packets from the remaining server 2100c. However, since the server 2100c is down, the response packet from the server 2100c does not reach the intermediary device 2200 even though it has gone through a long time! As a result, the server control unit 2210 times out and detects that the server 2100c is down.
  • the server control unit 2210 changes the server 2100c in the server management table 2201 from active to down (stop the server). State) (step S247).
  • FIG. 47 shows the server management table 2201 at that time.
  • it is checked whether a failure has occurred in the server 2100 by comparing the response packets from the servers 2100a and 2100b with each other.
  • the server control unit 2210 transfers one of the response packets to the client 2500a (step S248).
  • the client 2500a does not know whether the server 2100c has failed, and can receive services from the virtual server 2800 as before.
  • the client 2500a transmits a packet containing SQL (CO MMIT) for confirming the update to the table test-table to 172.17.1.1 (step S249).
  • the server control unit 2210 places the received query in the transmission queue 2204. Then, the query is taken out from the transmission queue 2204, and the packet is transferred to a server that is operating normally, in this case, the servers 2100a and 2100b by referring to the server management table 2201 (steps S250 and S251). Next, the transmission status of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the intermediary device 2200 waits until response packets are received from the servers 2100a and 2100b that are operating normally (steps S252 and S253), and when all the response packets have been collected, the server compares the response packets with each other. It is checked whether or not the force has a failure in the 2100 (step S254). In this case, since the two response packets are packets indicating that the transaction has started normally, it is determined that there is no failure. The server control unit 2210 deletes the registration of this transaction from the transaction management table 2202 since the completion of the transaction is a component of the successful completion of the COMMIT (step S255). At this time, the transaction management table 2202 is again in the initial state (that is, empty). The server control unit 2210 transfers one of the response packets to the client 2500a (step S256
  • the databases 2101a and 2101b of Sano 2100a and 2100b reflect the UPDATE (step S249) from the client 2500a, whereas the databases 2101c of the server 2100c reflect the UPDATE (step S249). Does not reflect UPDATE from client 2500a (step S249), that is, database 2101a Note that 2101b and database 2101c are out of sync
  • the database 2101c is out of synchronization with the databases 2101a and 2101b, that is, not identical.
  • the database 2101c may retain the data immediately before the failure of step S240 in FIG. 45, and may not have any data in the case of a completely new server. It might be state power.
  • old data is deleted, and the database 2101c is incorporated into the system as if it did not hold any data. That is, it is not necessary to keep old data before step S240.
  • server management table 2201 is as shown in FIG. Further, it is assumed that the transaction management table 2202 and the difference information storage unit 2203 are empty.
  • mediation apparatus 2200 receives the packet (step S260).
  • the server control unit 2210 detects that the transaction has started, and registers the IP address and the transaction number of the client 2500a in the transaction management table 2202 (Step S261).
  • FIG. 52 shows the transaction management table 2202 at this time.
  • the server control unit 2210 places the received query in the transmission queue 2204. Then, the query is extracted from the transmission queue 2204, and the server is operated normally with reference to the server management table 2201, and the packet is transferred to the server, in this case, the servers 2100a and 2101b (steps S262 and S263).
  • the transmission state of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 2200 compares the response packets and checks for a failure (step S 266), and sends one of the valid response packets to the client 2500 a. (Step S267).
  • the database control unit 2102c of the server 2100c transmits a database synchronization request (thread request) to the intermediary device 2200 (step S268).
  • the server control unit 2210 Upon receiving the database synchronization request, the server control unit 2210 checks the transaction management table 2202 to determine whether there is a transaction currently being executed, and records information on the transaction being executed. (Step S269). According to Figure 52, the transaction of client 2500a and transaction number 3 is being executed, so the database synchronization operation waits for the end of this transaction, and when a new transaction start request is received, the request is sent to the server 2100. Delay the transfer (step S270). That is, the synchronization operation starts with no transactions in progress. The transfer delay processing for the request to start a new transaction is realized by means of suspension in the transmission queue 2204 and other means.
  • the client 2500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S271).
  • the server control unit 2210 places the received query in the transmission queue 2204. Since this query can be determined to belong to the transaction executed at the time of the synchronization request by referring to the transaction information stored in step S269, the server control unit 2210 extracts the query from the transmission queue 2204, and The server is operating normally by looking at the management table 2201. In this case, the packet is transferred to the servers 2100a and 100b (steps S272 and S273).
  • the transmission status of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 2200 waits until response packets are received from the servers 2100a and 100b that are operating normally (steps S274 and S275), and when all the response packets are collected, determines whether there is a failure from the packets (step S276). . Then, the server control unit 2210 transfers one of the valid response packets to the client 2500a (Step S277).
  • the mediation apparatus 2200 receives the packet (step S278).
  • the server control unit 2210 detects that the transaction has been started by this packet, and stores the IP address of the client 2500b and the transaction in the transaction management table 2202. The registration number is registered (step S279).
  • FIG. 53 shows the transaction management table 2202 at this time. Then, the query relating to this packet is put in the transmission queue 2204 in the transmission state “not transmitted”. However, at this point, in order to prepare for the synchronization process, the new transaction start query is not transferred to the normally operating servers 2100a and 2100b while being held in the transmission queue 2204 (step S280).
  • the client 2500a transmits a packet including SQL (COMMIT) for confirming the update to the table test-table to 172.11.1.1 (step 3281).
  • the server control unit 2210 places the received query in the transmission queue 2204. Since this query can be determined to belong to the transaction executed at the time of the synchronization request by referring to the transaction information stored in step S269, the server control unit 2210 also extracts the query from the transmission queue 2204, and Referring to the management table 2201, the packet is transferred to the normally operating server, in this case, the servers 2100a and 2100b (steps S282 and S283).
  • the transmission state of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 2200 waits until all the servers 2100a and 2100b that are operating normally receive the response packet (steps S284 and S285), and when all the response packets have been collected, checks whether there is a failure from the packet (step S284). S286). In addition, since the COMMIT has been completed normally, the fact that the transaction has been completed is an important factor, so the server control unit 2210 deletes the registration of this transaction from the transaction management table 2202 (step S287). FIG. 54 shows the transaction management table 2202 at this time. The server control unit 2210 transfers one of the valid response packets to the client 2500a (Step S288).
  • the server control unit 2210 starts the synchronization operation (step S289). Specifically, first, the server control unit 2210 selects one synchronization server 2100 from the normally operating servers 2100a and 210 Ob (step S290). In the present embodiment, it is assumed that the server 2100b has been selected. Then, a synchronization instruction (snapshot creation instruction) is sent to the synchronization server 2100b (step S291). In addition, the status of the server 2100b in the server management table 2201 is changed to “sync” (step S292). Figure 55 shows the server management table 2201 at this time.
  • step S289 the traffic To determine whether the transaction recorded in the transaction management table 2202 was being executed at the time of the synchronization request, or was subsequently received from the client 2500, the transaction recorded in step S269 was used.
  • the transaction information at the time of the synchronization request may be referred to.
  • a snapshot of the database 2101b is created (step S293).
  • this snapshot is the backup data of the entire database and information for restoring the database at the time when the synchronization instruction is received, and the update after the synchronization instruction is reflected. Should.
  • step S294 the database control unit 2102b of the synchronization server 2100b transfers the created snapshot to the new server 2100c.
  • This 'snapshot' transfer and database restoration takes more time as the size of the database 2101b is larger, so the database access from the client is executed on the server 2100a which is operating normally, so the service to the client is stopped. None.
  • the database control unit 2102c of the new server 2100c restores the database from the snapshot received from the synchronization server 2100b (Step S295).
  • the server control unit 2210 of the intermediary device 2200 transmits a synchronization instruction to the server 2100b (the step S291), and changes the state of the server management table 2201 of the server 2100b to “sy nc” (the above-described step S291). Step S292), and immediately resume the processing for the processing request from the client 2500.
  • the server that processes the processing request from the client 2500 is the server 2100a whose status is “active”.
  • the synchronization server 2100b is temporarily disconnected from the system and performs only the synchronization processing. In this case, the packet is retained in the transmission queue 2204 without being processed, and processing of the packet including the BEGIN from the client 2500b is resumed.
  • the server control unit 2210 holds the packet containing the BEGIN SQL from the client 2500b without transferring the packet, and also extracts the transmission queue 2204 from the client 2500b and stores it in the difference information storage unit 2203 (step S295). Transfer to the working server 2100a (step S296). Next, the transmission queue 2204 is transmitted. The communication status is set to "transmission completed" and the entry is deleted.
  • the normally operating server 2100a sends a response packet to the mediation device 2200, and the mediation device 2200 receives this response packet (Step S297).
  • the mediation device 2200 transfers this response packet to the client 2500b (Step S298).
  • the server control unit 2210 places the received query in the transmission queue 2204. Then, the query is taken out from the transmission queue 2204, the query is stored in the difference information storage unit 2203 (step S2100), and the packet is transmitted to the normally operating server 2100a (step S2101). Next, the transmission status of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the server 2100a has failed the UPDATE, and has transmitted a response packet notifying the fact to the mediation device 2200 (step S2102).
  • the mediation device 2200 transmits this response packet to the client 2500b (step S2103).
  • the client 2500b that has received the UPDATE failure response packet transmits an SQL (ROLLBACK) packet for canceling the transaction to the mediation device (step S2104).
  • the server control unit 2210 places the received query in the transmission queue 2204. Then, the query is extracted from the transmission queue 2204, the SQL is stored in the difference information storage unit 2203 (step S2105), and the packet is transmitted to the normally operating server 2100a (step S2106). Next, the transmission state of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • step S2107 Upon receiving a response packet from the server 2100a notifying that the transaction has been successfully rolled back (step S2107), the transaction registration table is deleted from the transaction management table 2202 (step S2108), and the response packet is deleted. The message is transmitted to the client 2500b (step S2109).
  • Fig. 56 shows the difference information storage unit 2203 at this point. Also, the transaction management table 2202 becomes empty.
  • step S2110 the new server 2100c transmits a difference information transfer request to the mediation device 2200 (Step S2111).
  • the server control unit 2210 of the mediation device 2200 receives the difference information transfer request, Then, the process of transferring the data stored in the difference information storage unit 2203 to the new server 21OOc and the synchronization server 2100b in order from the oldest one is started (step S2112).
  • step S2112 all the queries stored in the difference information storage unit 2203 are transferred and processed, so that the database 2101a and the databases 2101b and 2101c completely match (synchronous state). May receive a new query from client 2500 during this transfer process.
  • the mediation apparatus 2200 receives a query (BEGIN) for starting a new transaction from the client 2500b (step S2113).
  • the mediation apparatus 2200 registers the new transaction in the transaction management table 2202 (Step S2114).
  • the query is entered into the transmission queue 2204.
  • the query is extracted from the transmission queue 2204, added to the end of the difference information storage unit 2203 (step S2115), and transmitted to the normally operating server 2100a (step S2116).
  • the transmission state of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the response packet is transferred to the client 2500b (step S2118).
  • the query received from the client 2500 during the transfer of the difference information is processed by the server 2100 that is operating normally, and is stored in the difference information storage unit 2203. If this processing is continued, all the queries stored in the difference information storage unit 2203 will be transferred to the new server 2100c and the synchronization server 2100b, and the difference information storage unit 2203 will be emptied.
  • the difference information transfer processing ends (step S2119).
  • the database 2101a and the databases 2101b and 2101c are completely matched (synchronous state). Therefore, the server control unit 2210 adds the new server 2100c to the server management table 2201, sets the operating state to active, and sets the synchronous state.
  • Server 2100b and 2100c are added to the system by changing the operation state of the activation server 2100b to active (step S2120).
  • FIG. 57 shows the server management table 2201 at this time.
  • the server 2100c is in a state of being incorporated in the system, and the subsequent operations are the same as those described above with reference to FIG.
  • server 2100 can be incorporated into the system regardless of the storage state of database 2101 of server 2100.
  • the same procedure applies to servers that were originally built into the system but were disconnected due to a failure (including those that lost data due to disk failures), or even completely new servers.
  • the synchronization data stored in the difference information storage unit 2203 for data synchronization in the mediation device 2200 receives the incorporation request from the server 2100 to be incorporated, and also starts accumulating power. Synchronization data does not increase in 2200. As a result, the storage capacity of the intermediary device 2200 can be saved, and occurrence of a failure due to overflow of the storage capacity can be prevented. In addition, the server 2100 can be detached arbitrarily.
  • servers can be incorporated and disconnected arbitrarily, so that a flexible system design can be performed according to demands such as applications and budget.
  • the server 2100 for synchronization processing is also selected for the power of the plurality of servers 2100 that are operating normally, and a snapshot is taken using the server 2100 for synchronization processing. Since the creation and transfer are performed, the processing request from the client 2500 can be processed in parallel with the other server 2100 that is operating normally. Therefore, since the embedded processing and the processing related to the processing request from the client are processed by different servers, the load is distributed, and the processing request from the client 2500 can be responded to even during the creation of the snapshot. Provision of smooth services to clients 2500 can be continued.
  • the new server 2100c is in the process of restoring the database 2101c from the snapshot (step S2200). Then, when the restoration process of the database 2101c is completed in the server 2100c (step S2201) and the server 2100c transmits the difference information transfer request to the intermediary device 2200 (step S2202), the difference information storage unit 2203 stores the predetermined information in the difference information storage unit 2203. It is assumed that difference information equal to or more than the number of cases is stored. In the example of FIG. 58, it is assumed that the UPDATE query in steps S2203 to S2207 is stored in the difference information storage unit 2203 as the latest difference information.
  • each of the queries stored in the difference information accumulation unit 2203 is The process of transferring the data to the new server 2100c and the synchronization server 2100b in this order starts (step S2208).
  • server control unit 2210 has received a new query from client 2500b.
  • the server control unit 2210 receives a packet including an SQL (INSERT) for adding data to the client 2500b (step S2209).
  • the server control unit 2210 that has received the new query during the transfer of the difference information places the received query in the transmission queue 2204. Then, the query is extracted from the transmission queue 2204, and if the number of untransferred queries stored in the difference information storage unit 2203 is larger than the predetermined number, this query is added to the end of the difference information storage unit 2203.
  • the packet is transferred to the normally operating server 2100a (step S2211).
  • the transmission status of the transmission queue 2204 is set to “transmission completed”, and the entry is deleted.
  • the server control unit 2210 transfers the response packet to the client 2500b (Step S2213).
  • the transfer of the difference information from the mediation device 2200 to the new server 2100c and the synchronization server 2100b is performed in parallel, so that the untransferred query stored in the difference information storage unit 2203 is It is assumed that the number is equal to or less than a predetermined number.
  • the server control unit 2210 When the server control unit 2210 receives a packet including SQL (UPDATE) for updating the data of the client 2500b (step S2214), the server control unit 2210 places the received query in the transmission queue 2204.
  • the processing of this new query is suspended (step S2215). That is, the new query is not stored in the difference information storage unit 2203 and is not transferred to the normally operating server 2100a.
  • This suspension process transfers all queries stored in the difference information storage unit 2203 to the new server 2100c and the synchronization server 2100b, and continues until both servers 2100b and 2100c are incorporated into the system.
  • step S2216 When the transfer of the difference information is completed (step S2216), all the queries stored in the difference information storage unit 2203 are transferred and processed, so that the databases 2101a and the databases 2 101b and 2101c completely match. State (synchronous state). Therefore, the server control unit 2210 adds the server 2100c to the server management table 2201 and sets the operation state to active, and also sets the server 2100b and 2100c to the system by setting the operation state of the synchronization server 2100b to active.
  • Step S2217 After up (Step S2217).
  • the server control unit 2210 resumes the processing of the new query held in step S2215.
  • the subsequent processing is the same as that described above with reference to FIG. That is, the server control unit 2210 extracts the query from the transmission queue 2204, and transfers the normally operating sano, in this case, the servers 2100a, 2100b, and 2100c (steps S2218, S2219, and S2220).
  • the transmission status of the transmission queue 2204 is set to “transmission completed” and the entry is deleted.
  • the response packets received from the servers 2100a, 2100b, and 2100c are compared to check for a failure (steps S2221 to S2224), and one of the normal response packets is transferred to the client 2500b (step S2225). ).
  • the query received from the client during the transfer of the difference information is stored in the difference information storage unit 2203 when the untransmitted difference information is larger than the predetermined number, and the query is correctly stored.
  • the transfer to the normally operating server 2100a is performed.
  • the new query is suspended.
  • the database synchronization can be performed in a short time.
  • the “predetermined number” which is the threshold value, has a trade-off relationship that if it is set to a large value, the hold time of a new query is prolonged, while if it is set to a small value, the time until the completion of the synchronization process is prolonged. Therefore, the “predetermined number” may be set to an optimal value individually according to the requirements of the system such as the processing load of each device and the network speed. If the threshold value is set to 0 or less in this modification, the same processing as the embodiment described above with reference to FIGS.
  • a multiplex database system according to a seventh embodiment of the present invention will be described.
  • the difference of the multiplexed database system according to the present embodiment from the sixth embodiment lies in the contents of the difference information transferred to the new server and the synchronization server.
  • Other configurations and operations are the same as those of the sixth embodiment, and therefore, only the differences will be described here.
  • all queries received from the client 2500 are stored and transferred to the difference information storage unit 2203.
  • queries processed by the normally operating server 2100 during the synchronization process can be faithfully reproduced by the new server 2100 and the synchronization server 2100, so that Synchronization can be achieved.
  • the difference information transferred to the new server and the synchronization server is exclusively used only for the synchronization processing, so that unnecessary queries in the synchronization need not be transferred.
  • SQL (SELECT) of reference query is not required.
  • the SELECT FOR UPDATE statement is a kind of SELECT statement, but it affects update processing. Therefore, it is assumed here that it is handled as an update query rather than a reference query.
  • server control section 2210 stores all queries received from client 2500 as difference information accumulating section 2203 as in the sixth embodiment. To memorize. Then, when transferring the difference information to the new server 2100 and the synchronization server, it is first determined whether the query is a reference query, and other than the reference query is transferred to the new server 2100 and the synchronization server 2100. The other processing is the same as in the sixth embodiment.
  • the new server 2100 and the synchronization server 2100 do not need to process the reference query at the time of the synchronization processing.
  • the processing can be shortened. This is particularly effective when the client 2500 issues a reference SQL having a large processing load such as a complicated reference SQL or a reference SQL including a set function. Other effects are the same as those of the sixth embodiment.
  • the server control unit 2210 receives a query from the client 2500 during the synchronization processing, and stores the query in the difference information storage unit 2203 as difference information
  • This modification has an effect that the storage capacity of the difference information storage unit 2203 can be further reduced.
  • a multiplexed database system according to an eighth embodiment of the present invention will be described.
  • the difference between the multiplexed database system according to the present embodiment and the sixth embodiment is the difference information accumulation processing during the database synchronization operation.
  • the other configuration and operation are the same as those in the sixth embodiment, and therefore, only the differences will be described here.
  • the server control unit 2210 stores all packets received from the client 2500 in the difference information storage unit 2203. That is, the transaction system Control SQL, reference SQL, and update SQL are all stored in the difference information storage unit 2203, and all data stored in the difference information storage unit 2203 are transmitted to the server 2100 in the order of oldness and power. I was
  • the server control unit 2210 includes, among the packets received from the client 2500 during the database synchronization operation, the transaction start SQL (BEGIN), the confirmed SQL (COMMIT), and the cancel SQL (ROLLBACK ), Etc.Transaction control SQL and reference SQL, such as SELECT, are not stored, and only the update SQL, such as UPDATE or INSERT, that is committed by the normally operating server 2100 is stored as difference information. Store in part 2203.
  • the difference information accumulating unit 2203 accumulates update queries in the order in which they are processed by the normally operating server 2100 rather than in the order received from the client 2500. This is because the contents of the database 2101 may differ depending on the processing order for update queries whose update targets overlap.
  • a difference information temporary storage unit 2205 as shown in FIG. 60 is newly provided.
  • the data structure of the difference information temporary storage unit 2205 includes the query received from the client and the ID of the transaction to which the query belongs.
  • the server control unit 2210 When the server control unit 2210 receives a query from the client 2500 during the synchronization process, the server control unit 2210 sequentially accumulates only those of the update type in the difference information temporary accumulation unit 2205 and transfers the updated information only to the normally operating server 2100. I do. On the other hand, those other than the update system are transferred to the normally operating server 2100 without being stored in the difference information temporary storage unit 2205.
  • the server control unit 2210 upon receiving a response packet indicating that the execution of the update query has failed from the normally operating server 2100, deletes the update query from the difference information temporary storage unit 2205. Also, upon receiving a response packet indicating that the transaction RO LLBACK has been completed normally from the normally operating server 2100, the server control unit 2210 also stores all update queries belonging to the transaction in the difference information temporary storage unit 2205. delete. On the other hand, when receiving a response packet indicating that the COMMIT of the transaction has been completed normally from the normally operating server 2100, the server control unit 2210 returns to the relevant transaction. Update queries belonging to Yeon are sequentially moved from the difference information temporary storage unit 2205 to the difference information storage unit 2203.
  • the difference information stored in the difference information storage unit 2203 may be transferred to the new server 2100 and the synchronization server 2100 in the order of storage. Since the new server 2100 and the database 2101 of the synchronization server 2100 sequentially process update queries from the mediation device 2200, the update queries are processed in the auto-commit mode.
  • reference queries unnecessary for synchronization processing and transaction control SQL such as BEGIN and ROLLBACK are not stored in the difference information storage unit 2203.
  • the transfer time of the difference information and the processing time at the server can be reduced.
  • Other effects are the same as in the sixth embodiment.
  • the query received from the client 2500 is transferred from the difference information temporary storage unit 205 to the difference information storage unit at the time when the transaction to which the query belongs is COMMITed by the server 2100 that is operating normally.
  • the query may be moved at the time when the query is normally processed by the normally operating server 2100.
  • the update query belonging to the transaction may be deleted from the difference information storage unit 203 after the transaction ROLLBACK. This kind of processing is effective to completely match the database of a DBMS whose row order changes according to the update order, such as PostgreSQL.
  • a multiplexed database system according to a ninth embodiment of the present invention will be described.
  • the multiplexed database system according to the present embodiment differs from the sixth embodiment in the structure of the difference information storage unit.
  • Other configurations and operations are the same as those in the sixth embodiment, and therefore, only the differences will be described here.
  • the mediation device 2200 according to the present embodiment differs from the sixth embodiment as shown in FIG. Differently, the difference information storage unit 2203 is not provided, and the functions of the difference information storage unit 2203 and the transmission queue 2204 in the sixth embodiment are integrated in the transmission queue 2206.
  • the data structure of transmission queue 2206 will be described with reference to FIG.
  • the transmission queue 2206 stores the content of the query received from the client 2500, the transaction ID to which the query belongs, and the status of transmission to each server 2100.
  • the transaction ID is obtained from the transaction management table 2202, as in the sixth embodiment.
  • the transmission status to each server 2100 is stored for each server 2100 belonging to the system.
  • the transmission state of the transmission queue 2206 to each server 2100 can take three values: “not transmitted”, “transmission completed”, and “hold”. “Not sent” means that the query received from the client 2500 has not been sent to the server 2100 yet. “Transmission completed” is a state in which transmission to the server 2100 has been completed. “Holding” is a state in which the new server 2100 is held without being transferred to the server 2100 during the process of incorporating the new server 2100 into the system. When the transmission status of all servers 2100 becomes “transmission completed”, the entry is deleted from the transmission queue 2206.
  • the server control unit 2210 receives the query from the client 2500, if the query is a transaction start SQL (BEGIN), it issues a new transaction ID for the transaction and registers it in the transaction management table 2202. Then, the contents of the query, the new transaction ID, and the transmission state of each server 2100 are registered in the transmission queue 2206 as “not transmitted”. If the query received from the client 2500 is not a transaction start SQL (BEGIN), the transaction ID to which the query belongs is obtained from the transaction management table 2202, and the query content, transaction ID, and transmission status of each server 2100 are obtained. It is registered in the transmission queue 2206 with “not transmitted”.
  • BEGIN transaction start SQL
  • the server control unit 2210 transmits the query recorded in the transmission queue 2206 to the server 2100 whose transmission state is “not transmitted”, and transmits the transmission state of the server 2100 to "transmission". Change to "Complete.” For queries for which the transmission status of all the servers 2100 has become “transmission completed", the query is deleted from the transmission queue 2206. [0280] Each server 2100 that has received the query from the mediation device 2200 processes the query, and returns a response packet to the mediation device 2200. The server control unit 2210 of the intermediary device 2200 compares the response packets received from each server 2100 to determine whether a failure has occurred, and returns one of the normal response packets to the client 2500.
  • FIG. 63 is an example of the transmission queue 2206 when the server 2100c is disconnected from the system with the transmission queue 2206 as shown in FIG.
  • the server control unit 2210 suspends the start of a new transaction until the transaction being executed at the time of receiving the embedded request ends. Specifically, when the query received from the client 2500 relates to a new transaction, the transmission status is stored in the transmission queue 2206 as “pending”. On the other hand, if the query received from the client 2500 is related to the transaction being executed at the time of the installation request, the transmission status is stored in the transmission queue 2206 as “not transmitted”. FIG.
  • FIG. 64 is an example of the transmission queue 2206 when the mediation device 2200 receives a synchronization request and then receives a new query from the client 2500 with the transmission queue 2206 as shown in FIG.
  • the query is from the upper query (in order from the oldest query)
  • SELECT with transaction ID 2
  • COMMIT with transaction ID 1
  • the server control unit 2210 When the server control unit 2210 finishes transmitting all queries related to the transaction being executed at the time of receiving the embedded request to the normally operating server 2100, the server control unit 2210 stores the new server 2100 to be embedded in the transmission queue 2206. Add items. Where the send queue 220 In 6, the transmission state may be “pending”, and the query may be stored. In this case, the server control unit 2210 sets the transmission state of the new server 2100 to “pending” in response to the query stored in the transmission queue 2206.
  • FIG. 65 shows a case where a new server 2100c is registered in the transmission queue 2206 of FIG.
  • the server control unit 2210 When the server control unit 2210 finishes transmitting all the queries related to the transaction being executed at the time of receiving the embedded request to the server 2100 that is operating normally, the server control unit 2210 operates similarly to the sixth embodiment.
  • the synchronization server 2100 is selected from the server 2100, and a synchronization instruction (snapshot creation instruction) is transmitted to the synchronization server 2100.
  • the server control unit 2210 When transmitting the synchronization instruction to the synchronization server 2100, the server control unit 2210 changes the operation state of the server management table 2201 for the synchronization server 2100 to "sync". Then, the transmission of the query to the normally operating server 2100 is restarted. Specifically, first, for all queries stored in the transmission queue 2206 (at this point, the transmission status of all queries is “pending” for all servers 2100), the servers 2100 that are operating normally Change the transmission status of the to "not sent”. Then, the server control unit 2210 sequentially transmits a query whose transmission state is “not transmitted” to the server 2100, and corrects the transmission state to “transmission completed” when the transmission is completed.
  • FIG. 66 illustrates a case where a new query is received after transmitting the synchronization instruction to the transmission queue 2206 of FIG. Also, as shown in FIG. 67, even if the transmission is completed for the normally operating server 2100a, the transmission is completed for the new server 2100c and the synchronization server 2100b! / ⁇ ⁇ ⁇ (“Pending”! /, ⁇ ), so the query is not deleted from the transmission queue 2206.
  • the server control unit 2210 receives a difference information transfer request from the new server 2100.
  • the server control unit 2210 is a query stored in the transmission queue 2206, and the transmission state is “pending”! /
  • the transmission status of the server 2100 in the transmission queue 2206 is set to “transmission completed”, and when the transmission status of all the servers 2100 becomes “transmission completed”, the entry is deleted.
  • the server control unit 2210 adds the new server 2100 to the server management table 2201 as “active” when the query whose transmission status is “pending” no longer exists in the transmission queue 2206, and performs synchronization. By changing the operation state of the virtualization server 2100 to “active”, the server 2100 is incorporated into the system. Subsequent operations are the same as those when each server 2100 is operating normally.
  • the functions of the difference information accumulating unit 2203 and the transmission queue 2204 in the sixth embodiment are integrated into one transmission queue 2206. Memory use efficiency and processing efficiency are improved. Also, since the transmission status to each server 2100 is stored for each query in the transmission queue 2206, the transmission status of the server 2100 may be added when a new server 2100 is incorporated. This allows a plurality of servers 2100 to be incorporated into the system at one time. Other operational effects are the same as in the sixth embodiment.
  • a multiplexed database system according to a tenth embodiment of the present invention will be described.
  • the multiplexed database system according to the present embodiment is different from the ninth embodiment in the method of storing difference information.
  • Other configurations and operations are the same as those of the ninth embodiment, and therefore, only the differences will be described here.
  • the timing at which the mediation apparatus 2200 transmits a snapshot creation instruction to the normally operating server 2100 is determined by the server 2100 that is operating normally. This is when there are no more transactions. Specifically, in parallel with processing of the transaction being executed at the time of receiving the embedded request from the new server 2100 on the server 2100 that is operating normally, the client 2500 The request to start a new transaction received from was held. And the integration required At the point in time when there is no transaction being executed when the request is received, a snapshot creation instruction is transmitted to the synchronization server 2100. This is because, depending on the DBMS, if a transaction is being executed at the time of creating a snapshot, the data update power of the update query belonging to the transaction becomes uncertain whether the power reflected in the snapshot is uncertain. is there.
  • the server 2100 does not reflect the update query belonging to the transaction being executed at the time of snapshot creation and the update query received during the snapshot creation process in the snapshot. Use what performs.
  • the server control unit 2210 of the intermediary device 2200 can transmit a snapshot creation instruction and start a new transaction without waiting for the end of the transaction being executed at the time of receiving the embedded request. it can.
  • the server control unit 2210 of the intermediation device 2200 determines that the transmission state of all the queries stored in the transmission queue 2206 for all servers 2100 is “ When "Transmission completed" and the transaction belonging to the query ends, the registration of the query is deleted.
  • the server control unit 2210 Upon receiving the installation request from the new server 2100c, the server control unit 2210 selects the synchronization server 2100 from the normally operating servers 2100. In this embodiment, it is assumed that the server 2100b is selected. The server control unit 2210 transmits a snapshot creation instruction to the synchronization server 2100b.
  • FIG. 68 shows an example of the transmission queue 2206 when the new server 2100c transmits the installation request to the mediation device 2200.
  • the queries stored in the transmission queue 2206 remain without being deleted if the transaction to which the query belongs has not been completed even after the transmission of the query is completed.
  • the synchronization server 2100b that has received the snapshot creation instruction starts the creation of the snapshot.
  • the snapshot created here does not reflect the query stored in the transmission queue 2206.
  • the server control unit 2210 checks whether the new server 2100c When the embedded request is received from the new server 2100c, the transmission status of the new server 2100c is set to “pending” for all queries stored in the transmission queue 2206 and added.
  • FIG. 69 shows an example of the transmission queue 2206 at this time.
  • the server control unit 2210 When the server control unit 2210 receives a query from the client 2500 after receiving the embedded request, the server control unit 2210 changes the transmission status of the normally operating server 2100a to "not yet transmitted", the synchronization server 2100b, and the new server. For 2100c, the transmission state is set to “pending”, and is sequentially added to the transmission queue 2206. Then, the queries whose transmission status is “not transmitted” are sequentially transferred to the “untransmitted” server 2100a, and the transmission status is changed to “transmission completed”. At this time, as shown in FIG. 70, the query stored in the transmission queue 2206 indicates that the transmission status of the normally operating server 2100a is “transmission completed” in transaction units, but the synchronization server The query is not deleted here because 2100b and the new server 2100c are “pending”.
  • the synchronization server 2100b that has received the snapshot creation instruction from the mediation device 2200 transmits the created snapshot to the new server 2100c.
  • the database control unit 2102c of the new server 2100c restores the database 2101c from the received snapshot and transmits a difference information transfer request to the mediation device 2200.
  • the server control unit 2210 Upon receiving the difference information transfer request, the server control unit 2210 uses the query whose transmission status is "pending" stored in the transmission queue 2206 as the difference information, sequentially with the synchronization server 2100b and the new server. 2100c, and changes the transmission state to "transmission completed” as shown in FIG. Then, as described above, when the transmission status of all the servers becomes “transmission completed” and the transaction of the query is completed, the query is deleted. Thereafter, when a query is received from the client 2500 while a query with a transmission status of “pending” is being transmitted, all transmissions of the normally operating server 2100a, synchronization server 2100b, and new server 2100c are sent as shown in Figure 72. The state is stored in the transmission queue 2206 as “not transmitted”. Then, at the point in time when there is no longer a query whose transmission status is “pending”, the synchronization of the databases 2101a, 1010b, and 2101c is completed.
  • the functional requirements of the server 2100 used in the system are limited, the range of server selection is narrowed, but the processing in the mediation device 2200 is simplified. The processing efficiency is high.
  • a multiplexed database system according to an eleventh embodiment of the present invention will be described with reference to the drawings.
  • the multiplexed database system according to the present embodiment is different from the above-described embodiments in the timing of sending difference information to a synchronization server and a new server.
  • the intermediary device upon receiving the difference information transfer request from the new server, the intermediary device simultaneously sends the difference information to both the new server and the synchronization server.
  • the process of transmitting the difference information to the synchronization server and the process of transmitting the difference information to the new server are asynchronously performed in parallel. Therefore, the mediation device according to the present embodiment needs to accumulate difference information for a plurality of servers independently of each other, and thus has the same configuration as the mediation device according to the ninth embodiment. That is, in the transmission queue 2206, difference information is stored for each server.
  • the mediation device 2200 receives a difference information transfer request not only from the new server 2100 but also from the synchronization server 2100. Then, when the difference information transfer request is received, queries in which the transmission status of the requesting server in the transmission queue 2206 is “pending” are sequentially transmitted to the requesting server. Then, when the server that has sent the difference information transfer request becomes “pending” and the transmission of the query is completed, the server management table 2201 for the server is updated and incorporated into the system. The processing of the query from the client 2500 at the time of the embedded processing is the same as that of the ninth embodiment described above.
  • the synchronization server 2100 Upon receiving the synchronization instruction (snapshot creation instruction) from the intermediary device 2200, the synchronization server 2100 starts creating a snapshot. Next, when the creation of the snapshot is completed, a difference information transfer request is transmitted to the mediation device 2200, and the transfer of the snapshot to the new server 2100 is started. Since the difference information is sequentially received from the mediation device 2200 in response to the difference information transfer request, the synchronization server 2100 processes the difference information. Next, the operation when incorporating the new server 2100 into the system will be specifically described with reference to the sequence charts of FIGS. 73 and 74.
  • the new server 2100c transmits a request for installation into the intermediary device 2200, and the intermediary device 2200 selects the server 2100b as a synchronization server, and issues a synchronization instruction to the synchronization server 2100b. Is transmitted (step S2301), and the server 2100b is also disconnected from the system (step S2302). The operation from the reception of the installation request to the system to the transmission of the synchronization instruction is the same as in the ninth embodiment described above.
  • Step S2303 When the synchronization server 2100b receives the synchronization instruction from the mediation device 2200 (Step S2301), it starts creating a snapshot (Step S2303).
  • Step S2304 When the creation of the snapshot is completed (step S2304), a difference information transfer request is transmitted to the mediation device 2200 (step S2305), and the process of transferring the snapshot to the new server 2100c is started. (Step S2306).
  • the mediation device 2200 Upon receiving the difference information transfer request from the synchronization server 2100b, the mediation device 2200 starts sending the difference information to the server 2100b (Step S2307). Specifically, of the queries stored in the transmission queue 2206, those whose transmission status of the synchronization server 2100b is “pending” are transmitted to the synchronization server 2100b in order from the oldest one. . Then, for the query, the transmission status of the synchronization server 2100b in the transmission queue 2206 is updated to “transmission completed”.
  • the mediation device 2200 stores the query as difference information (step S2308). S2309). Specifically, the transmission status of the query is set to “not transmitted” for the normally operating server 2100a, the transmission status is set to “pending” for the synchronization server 2100b and the new server 2100c, and the transmission queue 2206 is set. To accumulate. Next, the mediation device 2200 transfers the data to the server 2100a that is operating normally (step S2310), and updates the transmission status of the server 2100a in the transmission queue 2206 to “transmission completed”. Then, a response packet (step S2311) from the normally operating server 2100a is returned to the requesting client 2500 (step S2312).
  • New server 2100c completes restoration of database 2101c based on the snapshot Then (step S2313), a difference information transfer request is transmitted to mediation apparatus 2200 (step S2314).
  • the mediation apparatus 2200 Upon receiving the difference information transfer request from the new server 2100c (Step S2314), the mediation apparatus 2200 starts sending the difference information to the server 2100c (Step S2315). More specifically, among the queries stored in the transmission queue 2206, the transmission status of the query for the new server 2100c is “pending”, and the queries are transmitted to the new server 2100c in order of oldness and power. Then, the transmission status of the synchronization server 2100b is updated to “transmission completed” for the query.
  • the present embodiment is characterized in that the difference information transfer to the synchronization server 2100b and the difference information transfer to the new server 2100c are performed in parallel and asynchronously with each other.
  • the mediation device 2200 uses the query as difference information. It is memorized (step S2317). Specifically, the transmission status of the query is set to “not transmitted” for the normally operating server 2100a, the transmission status is set to “pending” for the synchronization server 2100b and the new server 2100c, and the transmission queue 2206 To accumulate. Next, the mediation device 2200 transfers the data to the normally operating server 2100a (step S2318), and updates the transmission status of the server 2100a in the transmission queue 2206 to “transmission completed”. Then, a response packet (step S2319) from the normally operating server 2100a is returned to the requesting client 2500 (step S2320).
  • a response packet step S2319
  • the mediation apparatus 2200 completes the transmission of the difference information. Update the server management table 2201 for each of the servers 2100b and 2100c and incorporate them into the system.
  • step S2321 the transmission of the difference information to the synchronization server 2100b ends before the new server 2100c (step S2321), and the mediation device 2200 sends the synchronization information to the synchronization server 2100b.
  • step S2322 change the operating status of the server management table 2201 to active and incorporate it into the system.
  • a query from the client 2500 during the transfer of the difference information to the new server 2100c is processed by the normally operating server 2100a and the server 2100b incorporated in step S2322. Specifically, when a query is received from the client 2500 (step S2323), the transmission status of the servers 2100a and 2100b that are normally operating the query is “not transmitted”, and the transmission status of the new server 2100c is With “pending”, it is stored in the transmission queue 2206 (step S2324).
  • the mediation device 2200 transfers the sanoes 2100a and 2100b that are operating normally (steps S2325 and S2326), and updates the transmission status of the transmission queue 2206 for the servers 2100a and 2100b to “transmission completed”. Then, the validity of the response packets (steps S2327 and S2328) from the normally operating servers 2100a and 2100b is checked (step S2329), and one of the correct responses is returned to the requesting client 2500 (step S2330). ).
  • step S2331 when the query whose transmission status is "pending" for the new server 2100c disappears from the transmission queue 2206, the mediation apparatus 2200 completes the transmission of the difference information (step S2331).
  • the operation information of the server management table 2201 for the new server 2100c is added as “active” and incorporated into the system (step S2332).
  • the timing of the restoration of the synchronization server 2100 into the system is earlier, so that the number of servers incorporated in the system is reduced. It is possible to shorten the period of time that is less than the normal time. Therefore, the fault tolerance of the system is improved.
  • the synchronization server 2100b is incorporated into the system before the new server 2100c.
  • the new server 2100c has higher performance than the synchronization server 2100b.
  • the new server 2100c may be incorporated into the system first.
  • the servers do not need to have the same implementation if they respond the same in response to a request. That is, version, specification, programming language, compiler type, compiler option Chillons, hardware capabilities and software capabilities may differ.
  • the server can be free software such as PostgreSQL, commercially available software such as Oracle, or proprietary software. They may be mixed.
  • server 2100a may be PostgreSQL and servers 2100b and 2100c may be Oracle.
  • the database control unit 2102 separates the functions into a database management unit and a database server management unit, so that the middle product is not modified.
  • the database management unit directly operates the database 2101.
  • PostgreSQL it corresponds to postmaster or postgres.
  • the database server management unit intervenes between the intermediary device 2200 and the database management unit, relays the transmission and reception of queries, creates a snapshot of the database 2101 when synchronizing other servers, It performs processing to transfer the snapshot to other servers.
  • DBMS is PostgreSQL
  • a snapshot creation method is realized by using a dump tool such as pg—dump or a backup tool.
  • pg-dump is useful for synchronizing Post greSQL servers.
  • heterogeneous DBMSs for example, PostgreSQL and Oracle
  • normal operation is performed without using DBMS-specific tools. You can use a general-purpose tool to retrieve all data from a DBMS server using a SELECT query and enter data using an INSERT query.
  • a request for incorporating into the system (a request for synchronizing a database of a new server) is transmitted to the mediation device 2200 by the database control unit 2102 of the new server 2100.
  • the database control unit 2102 of the new server 2100 For example, another device power may be transmitted, or the operator may directly instruct the mediation device 2200.
  • the server is implemented by software on a personal computer, but may be implemented by hardware.
  • FIG. 75 is a block diagram illustrating the overall configuration of the multiplexed database system according to the present embodiment.
  • this multiplexed database system is a system in which a plurality of database servers (hereinafter, referred to as “servers”) 100 and an intermediary device 3200 are connected via a network 3300. And at least one client computer (hereinafter, referred to as “client”) 500 and a database consistency checker 3600.
  • client client computer
  • FIG. 75 there are two servers 3100a and 3100b, and two clients 3500a and 3500b are also accessed.
  • suffixes “a” and “b” are added. The same applies to client 3500.
  • the Sano 3100 and the client 3500 may be connected to the same network connected to different networks 3300 and 400, respectively.
  • the mediation device 3200 has an IP address 172.17.1.1 on the network 3400 side, and discloses this as the IP address of the database server.
  • the client 3500 or the database matching check device 3600 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 mediation device 3200 at the IP address 172.17.1.1. This is the same as transmitting and receiving packets to and from the database server having the IP address 172.17.1.1 for the client 3500.
  • the virtual database server having the IP address 172.17.1.1 is called a virtual server 3800.
  • the purpose of this virtual server 3800 is to hide that the server 3100 is redundant.
  • the server 3100 includes a database 3101 for storing and managing data, and a database control unit 3102 for controlling the operation of the database 3101.
  • the database 3101 is an RD BMS (Relational Database Management System) that performs processing by interpreting SQL (Structured Query Language).
  • SQL Structured Query Language
  • PostgreSQL http://www.postgres.org/
  • the PostgreSQL Global Development Group and Oracle registered trademark
  • the database control unit 3102 operates based on a packet transmitted from the mediation device 3200 via the network 3300. These packets are roughly classified into those related to processing in the database 3101 such as SQL, and those related to synchronization processing. For those related to the processing in the database 3101 such as SQL, the database control unit 3102 passes the packet to the database 3101 and returns the processing result from the database 3101 to the intermediary device 3200.
  • those related to the synchronization process are further divided into those when they are incorporated into the system themselves and those when they are incorporated into the system at the time of startup or failure recovery.
  • a snapshot creation instruction synchronization instruction
  • the database control unit 3102 Upon receiving the snapshot creation instruction from the mediation device 3200, the database control unit 3102 creates a snapshot of the database 3101. Then, when the creation of the snapshot is completed, the completion of the snapshot is notified to the mediation device 3200. Then, the created snapshot is transferred to another transfer destination server 3100 instructed by the snapshot creation instruction.
  • the database control unit 3102 when the database control unit 3102 receives a snapshot from another database when the system is to be incorporated into the system, such as when recovering from a failure, the database control unit 3102 restores its own database 3101 using the snapshot.
  • a difference information transfer request is sent to the mediation device 3200.
  • the database 3101 is restored using this difference information.
  • the database control unit 3102 restarts the database 3101 and the database control unit 3102. This restart processing is only for restarting the processes of the database 3101 and the database control unit 3102. If the database 3101 and the database control unit 3102 are set to start automatically when the server 3100 is started, the entire server 3100 may be restarted. Further, when the database control unit 3102 itself is started (including restart), the database control unit 3102 transmits a database synchronization request (a request for threading to the system) to the intermediary device 3200.
  • a database synchronization request a request for threading to the system
  • the mediation device 3200 includes a server management table 3201 for managing the server 3100 in the present system, a transaction management table 3202 for managing transactions, a difference information storage unit 3203 for storing difference information for synchronization, and a server.
  • a transmission queue 3204 for temporarily storing queries to be transmitted to the 3100, and a server control unit 3210 for mediating processing between the client 3500 and the database consistency check device 3600 and the server 3100 and controlling synchronization of the server 3100.
  • the server management table 3201 stores a state where the server is operating normally (active) or stopped (down) due to a failure or the like.
  • FIG. 76 shows an example of the server management table.
  • the server management table 3201 includes a server ID for identifying the server 3100 and an operating state of the server.
  • the server 3100a and the server 310 Ob are registered, and the operation states are both active indicating normal operation.
  • the IP address assigned to the server 3100 is used as the server ID.
  • the transaction management table 3202 stores the presence or absence of a transaction that is currently being executed or whose execution is suspended.
  • FIG. 77 shows an example of the transaction management table 3202.
  • the transaction management table 3202 also 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 3202 at the start of the transaction, and are deleted from the transaction management table 3202 at the end of the transaction.
  • the client ID is, for example, an IP address or a port number of the client 3500 or the like.
  • the server ID is newly assigned by the server control unit 3210 every time a new transaction occurs.
  • the difference information accumulating unit 3203 accumulates all queries received from the client 3500 and the database consistency check device 3600 at the time of server synchronization.
  • FIG. 78 shows an example of difference information accumulated by the difference information accumulation unit 3203.
  • each data of the difference information storage unit 3203 is transmitted by the client 3500 or the database consistency check device 3600.
  • the transaction ID is obtained from the transaction management table 3202.
  • a new query at the time of the synchronization process is added to the end of the difference information storage unit 3203. In other words, old queries are accumulated from the top.
  • the transmission queue 3204 is a buffer memory that temporarily stores the query received from each client 3500 and the database matching check device 3600 until it is transmitted to each server 3100.
  • FIG. 79 shows an example of the transmission queue 3204.
  • each data of the transmission queue 3204 is composed of a query transmitted by the client 3500 or the like, a transaction ID to which the query belongs, and a transmission state indicating whether or not the data is transmitted to the server 3100.
  • the transaction ID is obtained from the transaction management table 3202.
  • a new query from the client 3500 or the like is added to the end of the transmission queue 3204. In other words, old queries are accumulated from above.
  • FIG. 79 shows an example of the transmission queue 3204.
  • the transmission status of the transmission queue 3204 is set to "not transmitted” when the client 3500 etc. also receives the query, and is set to "transmission completed” when transmitted to all the normally operating servers 3100. .
  • the entry whose transmission is completed is deleted from the transmission queue 3204 immediately or after a predetermined period has elapsed.
  • the server control unit 3210 receives packets from the client 3500 and the database matching check device 3600 via the network 3400 as normal processing (processing other than synchronization processing), and checks the server management table 3201.
  • the packet is forwarded to all servers 3100 that are operating normally.
  • the packet to be transferred to the server 3100 is a query stored as “unsent” in the transmission queue 3204, and is transferred in order from the oldest query stored in the transmission queue 3204.
  • a packet from the server 3100 is received via the network 3300, and one of the one or more packets is selected by a packet validity determination method described later, and one correct packet is requested via the network 3400 as a request source.
  • client 3500 etc.
  • the server control unit 3210 analyzes the processing request of the client 3500 and the like, detects the start and end of the transaction, and updates the transaction management table 3202.
  • the method by which the server control unit 3210 detects the start and end of a transaction differs depending on the type of DBMS. For example, in the case of PostgreSQL described above, the transaction starts when the client 3500 etc. sends the SQL “BEGIN”, and the transaction ends when the client 3500 etc. S ⁇ ] “ROLLBACK”! It is when it was sent.
  • the start of a transaction is when the client 3500 etc. sends a valid SQL (there is no SQL that explicitly declares the start of a transaction), and the end of the transaction is executed by the client 3500 etc. "ROLLBACK"! This is the time when the SQL was sent.
  • the SQL statement that has also received the client 3500 etc. can be interpreted as belonging to one independent transaction. It can be treated as the transaction started before execution and the transaction ended after SQL execution.
  • a method of determining the validity of a packet for example, when there are three or more servers 3100, there is a method of deciding by majority vote, or a method of deciding a received packet based on a predetermined rule. For example, if a response of “update success” is returned in response to a “reference” request from the client 3500, such a response is not possible if it is normal (should be a reference-related response such as successful reference). The response packet is determined to be incorrect. If the data length field is present in the packet, the value of this data length field is compared with the actually received packet length, and if they are different, it is determined to be incorrect.
  • one medium master server of the plurality of servers 3100 is determined in advance, and the packet from this server 3100 is always determined to be correct.
  • the server control unit 3210 determines that the server 3100 that has transmitted an invalid response and the server 3100 that has not returned a response within a predetermined time are failures, and that the server 3100 By deleting the registration from the server management table 3201, the system power is disconnected, and a restart instruction is transmitted to the server 3100.
  • the server control unit 3210 synchronizes the server 3100 with the normally operating server 3100. Is performed. The processing is described below.
  • a server to be incorporated into the system will be referred to as a “new server” for convenience. Incorporation of a new server is performed not only when adding servers in the system, but also when re-installing a server whose system power has been cut off as described above.
  • the server control unit 3210 Upon receiving the database synchronization request from the server 3100, the server control unit 3210 sends a snapshot creation instruction to the normally operating server 3100.
  • the server 3100 is not executing a transaction when sending a snapshot creation instruction. This prevents data from being out of sync if the transaction rolls back during snapshot creation, or updates are reflected in the snapshot due to the COMMIT! /, Na! / What! This is to prevent this. For this reason, the server control unit 3210 waits for transmission of the snapshot creation instruction until the transaction being processed ends, and does not start a new transaction until a snapshot creation completion notification is received from the server 3100. .
  • the SQL relating to the new transaction is processed by the normally operating server 3100 after receiving the snapshot creation completion notification, and is stored in the difference information storage unit 3203.
  • the queries stored in the difference information storage unit 3203 are all SQL including transaction control SQL, reference SQL and update SQL.
  • the server control unit 3210 sends a snapshot creation instruction
  • the snapshot is transferred to a new server 3100, and a difference information transfer request is sent from the server 3100 to the server control unit 3210.
  • the server control unit 3210 sequentially transmits the queries stored in the difference information storage unit 3203 to the new server 3100, including the oldest query.
  • the server control unit 3210 starts the new server 3100 in the system. Update the server management table 3201.
  • the server control unit 3210 has a capability of receiving a new query from the client 3500 or the database matching check device 3600 during transmission of the difference information.
  • the server control unit 3210 stores the query in the difference information storage unit 3203. And send it to the normally operating server 3100.
  • the query transmission frequency of the client 3500 or the like is high, it may take a long time until the transmission of the difference information is completed, that is, the synchronization is completed. Therefore, when the number of untransmitted difference information in the difference information storage unit 3203 becomes equal to or smaller than the predetermined number, the query from the client 3500 or the like is temporarily suspended, and only the difference information is sent, and first, the sending of the difference information is completed. Then, as described above, it is preferable to update the server management table 3201 to incorporate the new server 3100 into the system, and then restart the suspended query processing.
  • the client 3500 issues an update query (a request for updating a database) or a reference query (a request for referring to the contents of a database) to the multiplexed database system.
  • the database consistency check device 3600 operates as a client of the multiplexed database system like the client 3500, and determines whether or not the databases 3101 of each server 3100 match each other. Issue a query to confirm This query is of a reference type, such as "SELECT * FROM test-table" for a given table test-table.
  • the database matching check device 3600 issues the check query periodically or in response to an instruction from an operator or the like.
  • each server 3100a, 3100b has a table test —table! /.
  • Client 3500a sends a packet containing the transaction start SQL to 172.17.1.1 Upon reception, the mediation device 3200 receives the packet (step S31).
  • the server control unit 3210 detects that the transaction has started, and registers the IP address and the transaction number of the client 3500a in the transaction management table 3202 (Step S32).
  • Figure 82 shows the transaction management table 3202 at this time. Then, the query relating to this packet is put in the transmission queue 3204 in the transmission state “not transmitted”.
  • the server control unit 3210 extracts the "unsent" query from the transmission queue 3204, and refers to the server management table 3201, and transmits the packet to all the normally operating servers 3100. In this case, since the servers 3100a and 3100b are operating normally, the server control unit 3210 transfers the packet to the servers 3100a and 3100b (steps S33 and S34, respectively). Then, since the transmission to each server 3100 is completed, the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 3200 receives a response packet notifying that the transaction has started normally from the server 3100a (step S35), but at this point, not all response packets have been collected yet ( In this case, the response packet from the server 3100b has not arrived), and the server control unit 3210 does nothing and waits for the response packet from the server 3100b. Then, upon receiving a response packet notifying that the transaction has started normally from the server 3100b (step S36), the server control unit 3210 compares all the response packets with each other because all the response packets have been prepared. By doing so, it is checked whether or not the server 3100 has a failure (step S37). In this case, since the two response packets both indicate that the transaction has started normally, it is determined that there is no failure, and one of the response packets is transferred to the client 3500a (step S38).
  • the client 3500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S39).
  • the server control unit 3210 places the received query in the transmission queue 3204. Then, the query is taken out from the transmission queue 3204 and the packet is transferred to the normally operating Sano, in this case, the servers 3100a and 3100b by referring to the server management table 3201 (steps S310 and S311 respectively).
  • the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • Server 310 Oa sends a response packet to inform the completion of UPDATE to mediation device 3200 Then, mediation apparatus 3200 receives this response packet (step S312).
  • step S313 upon receiving a response packet notifying that the UPDATE has been completed normally from the server 3100b (step S313), the server control unit 3210 compares the response packets with each other because all the response packets have been prepared. In step S314, it is checked whether a failure has occurred in the server 3100. In this case, since the two response packets are both packets indicating that the UPDATE was successful, it is determined that there is no failure !, and one of the response packets is transferred to the client 3500a (step S315).
  • the client 3500a sends a packet containing SQL (COMMIT) confirming the update to the table test—table (actually updating the database) to 172.17.1.1 (step S316).
  • the server control unit 3210 places the received query in the transmission queue 3204. Then, the query is extracted from the transmission queue 3204, and the server is operated normally by looking at the server management table 3201, and in this case, the packet is transferred to the server 3100a and the server 3100b (steps S317 and S318, respectively). Next, the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the server 3100a transmits a packet notifying that the COMMIT has been completed normally to the mediation device 3200, and the mediation device 3200 receives this response packet (step S319). At this point, since not all response packets have been prepared, the server control unit 3210 waits without doing anything. Then, when a response packet notifying that the COMMIT has been completed normally is received from the server 3100b (step S320), all the response packets are prepared. The server control unit 3210 compares the response packets with each other. It is checked whether a failure has occurred in the server 3100 (step S321). In this case, it is determined that there is no failure because the two response packets both indicate that the COMMIT was successful.
  • the server control unit 3210 deletes the registration of this transaction from the transaction management table 3202 since the COMMIT has been completed normally and the transaction has been completed (Step S322). At this time, the transaction management table 3202 is again in the initial state (ie, empty). Server control unit 3210 transfers one of the response packets to client 3500a (step S323). Next, an operation performed when the server 3100b fails due to a failure or the like will be described with reference to FIGS. In the initial state, it is assumed that the databases 3101a and 101b are completely the same, and the server management table 3201 is as shown in FIG. It is also assumed that the transaction management table 3202 and the difference information storage unit 3203 are empty.
  • the mediation device 3200 receives the packet (step S330).
  • the server control unit 3210 detects that the transaction has started, and registers the IP address and the transaction number of the client 3500a in the transaction management table 3202 (step S331).
  • FIG. 84 shows the transaction management table 3202 at this time. Then, the query relating to this bucket is put in the transmission queue 3204 in the transmission state “not transmitted”.
  • the server control unit 3210 extracts the "unsent" query from the send queue 3204, and looks at the server management table 3201 to check all the normally operating servers 3100, in this case, the servers 3100a and 3100b.
  • the packet is transferred to (steps S332 and S333, respectively).
  • the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 3200 receives a response packet notifying that the transaction has started normally from the server 3100a (step S334), but at this point, not all the response packets have been collected yet. (In this case, there is no response packet from the server 3100b!
  • step S335 There is no response packet), and the server control unit 3210 does nothing and waits for a response packet from the server 3100b. Then, when the server 3100b also receives a response packet notifying that the transaction has been started normally (step S335), the server control unit 3210 compares all the response packets with each other because all the response packets have been prepared. By comparing, it is checked whether the server 3100 has a failure or not (step S336). In this case, since the two response packets are both packets indicating that the transaction has started normally, it is determined that there is no failure, and one of the response packets is transferred to the client 3500a (step S337).
  • step S338 it is assumed that after returning the response packet in step S335, the server 3100b goes down due to a failure such as a failure (step S338).
  • the client 3500a transmits a packet containing SQL (UPDATE) for updating the table test—table to 172.17.1.1 (step S339).
  • the server control unit 3210 Put the sent query in the send queue 3204. Then, the query is taken out from the transmission queue 3204 and the packet is transferred to the normally operating Sano, in this case, the servers 3100a and 3100b by referring to the server management table 3201 (steps S340 and S341, respectively).
  • the server control unit 3210 does not know that the server 3100b has gone down, if the server 3100b operates normally, the information remains stored in the server management table 3201. In,,, the transmission status of the transmission queue 3204 is set to “transmission completed” and the entry is deleted.
  • the server 3100a transmits a response packet notifying that the UPDATE has been completed normally to the mediation device 3200, and the mediation device 3200 receives this response packet (step S342).
  • the server control unit 3210 waits without doing anything.
  • the server control unit 3210 since the server 3100b is down, the response packet from the server 3100b does not reach the mediation device 3200 forever.
  • the server control unit 3210 times out and detects that the server 3100b is down.
  • the server control unit 3210 changes the server 3100b in the server management table 3201 from active to down (server stopped state), thereby disconnecting the server 3100b from the system power (step S343).
  • Figure 85 shows the server management table 3201 at that time.
  • the server control unit 3210 sends a restart instruction to the server 3100b disconnected from the system (Step S344). However, since the server 3100b is down here, the processing for the restart instruction is not performed.
  • the server control unit 3210 transfers the response packet to the client 3500a (step S345).
  • the client 3500a does not recognize whether the server 3100b has failed and can receive services from the virtual server 3800 as before.
  • the client 3500a sends a packet containing SQL (CO MMIT) for confirming the update to the table test—table to 172.17.1.1 (step S346).
  • the server control unit 3210 places the received query in the transmission queue 3204. Then, the query is taken out from the transmission queue 3204, and the packet is transferred only to the server that is operating normally, in this case, the server 3100a, by referring to the server management table 3201 (step S347). Next, the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the server 3100a sends a response packet notifying that the COMMIT has been completed normally, and the This response packet is received (step S348).
  • the server control unit 3210 deletes the registration of this transaction from the transaction management table 3202 because the completion of the transaction is a component of the successful completion of the COMMIT (step S349). At this time, the transaction management table 3202 is again in the initial state (ie, empty). The server control unit 3210 transfers the response packet to the client 3500a (Step S350).
  • step S347 the database 3101a of the server 3100a reflects the UPDATE from the client 3500a (step S339), whereas the database 3101b of the server 3100b reflects the UPDATE from the client 3500a. It should be noted that (Step S339) is not reflected, that is, the database 3101a and the database 3101b are out of synchronization.
  • the client 3500a sends a query (BEG IN) for starting the transaction T1 to the mediation device 3200 (step S3101), while the client 3500b sends a query (BEGIN) for starting the transaction T2. Is transmitted to the mediation device 3200 (step S3102).
  • the server control unit 3210 of the intermediary device 3200 transfers each query to the normally operating servers 3100a and 3100b (steps S3103 to S3106). Then, each response (steps S3107 to S3110) of each of the Sano 3100a and 3100b is checked for validity (not shown), and one of the valid responses is transmitted to the client 3500a or 3500a as the request source. Transfer to 3500b (steps S3111 to S3112).
  • the clients 3500a and 3500b that have received the response to the BEGIN from the mediation device 3200 transmit the next query belonging to each transaction to the mediation device 3200.
  • the client 3500a mediates the UPDATE query of the transaction T1.
  • the client 3500b sends an UP DATE query of the transaction T2 to the mediation device 3200 (step S3114).
  • the server control unit 3210 of the intermediary device 3200 that has received the queries from the clients 3500a and 3500b transfers the queries to the normally operating Sano 3100a and 3100b, respectively (steps S3115 to S3115).
  • server 3100a it is assumed that the UPDATE query of transaction Tl was processed before the UPDATE query of transaction T2.
  • the server 3100a that has processed the UPDATE query of the transaction T1 sends the processing result to the mediation device 3200 (step S3119).
  • the update target row of the test-table by the UPDATE query of the transaction T1 is locked until the transaction T1 is COMMIT.
  • the processing of the query is suspended until the lock is released (step S3120).
  • the UPDATE query of transaction T2 is processed before the UPDATE query of transaction T1 in server 3100b.
  • the server 3100b that has processed the UPDATE query of the transaction T2 transmits the processing result to the mediation device 3200 (Step S3121).
  • the row to be updated in the test-table by the UPDATE query of transaction T2 is locked until transaction T2 is COMMIT.
  • the processing of the query is suspended until the lock is released (step S3122).
  • the server 3100a responds to the UPDATE query of the transaction T1 (step
  • the server control unit 3210 of the mediation device 3200 responds to the UPDATE query of the transaction T1! Although the response from the server 3100a has been received (step S3119), since the response from the other server 3100b has not been received, the server waits for the response (step S3123). This is because, as described above, the server control unit 3210 compares the responses of the servers 3100a and 3100b with each other to determine the validity. Similarly, the server control unit 3210 sends a response to the UPDATE query of the transaction T2 to one of the servers 310. Although received from Ob (step S3121), since a response from the other server 3100a has not been received, the server waits for the response (step S3124).
  • the server control unit 3210 waits for a response to the query (step S3123) (step S3123). S3125). Accordingly, the server control unit 3210 determines that the server 3100b has failed, cancels the response waiting of the step S3124, and further changes the operation state of the server 3100b in the server management table 3201 to down, thereby changing the server 3100b to down. Disconnect 3100b from the system (step S3126). Then, as shown in FIG.
  • the server control unit 3210 sends a restart instruction to the server 3100b from which the system has been disconnected (step S3127), cancels the response waiting from the server 3100b, and cancels the server 3100a. Is returned to the client 3500a (step S3128).
  • step S3129 Upon receiving the restart instruction from the mediation device 3200, the server 3100b starts restarting itself (step S3129).
  • the client 3500a that has received the response to the UPDATE query of the transaction T1! / Transmits a query (COMMIT) for confirming the update to the mediation device 3200 (step S3130).
  • the server control unit 3210 of the intermediary device 3200 transfers the query to the normally operating server 3100a with reference to the server management table 3201 (step S3131).
  • the lock is released by processing the COMMIT query of the transaction T1, and the processing of the transaction T2 can be resumed (step S3132).
  • the server 3100a returns a response to the COMMIT query of the transaction T1 to the mediation device 3200 (step S3133), and the server control unit 3210 of the mediation device 3200 transfers the response to the client 3500a (step S3134).
  • the server 3100a returns a response to the UPDATE query of the transaction T2 to the mediation device 3200 (step S3135), and the server control unit 3210 of the mediation device 3200 transfers the response to the client 3500b (step S3136).
  • Client 3500b received response in response to UPDATE query in transaction T2! / Transmits a query (COMMIT) for confirming the update to the mediation device 3200 (step S3137).
  • the server control unit 3210 of the mediation device 3200 transfers the query to the normally operating server 3100a with reference to the server management table 3201 (step S3138).
  • the server 3100a processes the query and returns a response to the relay device 3200 (step S3139), and the server control unit 3210 of the relay device 3200 transfers the response to the client 3500b (step S3140).
  • step S3141 the restart of the server 3100b from which the system power has been disconnected has been completed.
  • the server 3100b transmits a database synchronization request to the mediation device 3200 (Step S3142).
  • the server control unit 3210 of the mediation device 3200 performs a process of synchronizing the database 3101a of the server 3100a with the database 3101b of the server 3100b in cooperation with the server 3100a that is operating normally (step S3143). The details of this synchronization processing will be described later.
  • the server control unit 3210 changes the operation state of the server 3100b to active in the server management table 3201 to incorporate the server 3100b into the system again (step S3144).
  • the synchronization of the database 3101 is maintained between the servers 3100 even when the processing order of the servers 3100 is different for a plurality of transactions to be processed in parallel.
  • the server control unit 3210 of the mediation device 3200 refers to the server management table 3201 and is operating normally.
  • the servers 3100a and 3100b step S3202, S3203.
  • one of the valid responses is transferred to the client 3500a (step S3206).
  • the client 3500a transmits an update query (UPDATE) of the transaction T3 to the mediation device 3200 (step S3207).
  • the client 3500b transmits a query (BEGIN) for starting the transaction T4 to the mediation device 3200 (step S3208).
  • the server control unit 3210 of the intermediary device 3200 transfers the UPDATE query of the transaction T3 to the normally operating Sano 3100a and 3100b (steps S3209 and S3210), and transmits the BEGIN query of the transaction T4 to the normally operating server. Transfer to 3100a and 3100b (steps S3211, S3212). Then, upon receiving a response to the UPDATE query of the transaction T3 from each of the servers 3100a and 3100b (steps S3213 and S3214), the server control unit 3210 of the mediation device 3200 receives one of the valid responses from the client 3500a. Transfer (step S3215). When receiving a response to the BEGIN query of the transaction T4 from each of the Sano 3100a and 3100b (steps S3216 and S3217), it transfers one legitimate response to the client 3500b (step S 3218).
  • the client 3500a sends a query (COMMIT) for confirming the transaction T3 to the intermediary device 3200 (step S3219).
  • the client 3500b transmits a reference query (SELECT) of the transaction T4 to the mediation device 3200 (step S3220).
  • the server control unit 3210 of the intermediary device 3200 transfers the COMMIT query of the transaction T3 to the normally operating SANOs 3100a and 3100b (steps S3221, S3222), and also transmits the SELECT query of the transaction T4 to the normally operating server. Transfer to 3100a and 3100b (steps S3223, S3224).
  • the COMMIT query of transaction T3 is processed before the SELECT query of transaction T4 (steps S3225, S3226), and on the other server 3100b, the SELECT query of transaction T4 is processed by transaction T3. It is assumed that the processing has been performed before the COMMIT query (steps S3227 and S3228). As a result, it is assumed that the response of the SELECT query of the transaction T4 is different from the response from the server 3100a (step S3226) and the response from the server 3100b (step S3227).
  • the server control unit 3210 of the intermediary device 3200 selects one of the servers 3100a or 3100b because the response to the SELECT query of the transaction T4 does not match between the servers 3100a and 3100b.
  • the response from 3100a is validated (step S3229).
  • a method of selecting the server 3100 for example, a master server is determined in advance, a method of selecting this master server, a method of selecting a server that has returned a response first, and a selection server sequentially by round robin. Selection methods, random selection methods, and selection methods based on the processing capacity and processing load of each server, etc. can be cited.
  • the server 3100a is selected as a master server and the server 3100a is selected as a server that has returned a valid response.
  • the server control unit 3210 changes the operating state of the server management table 3201 to down for the server 3100b that has returned an invalid response, thereby disconnecting the server 3100b from the system power (step S3230). Then, as shown in FIG. 89, a restart instruction is transmitted to the server 3100b (step S3231).
  • step S3232 Upon receiving the restart instruction from the mediation device 3200, the server 3100b starts restarting itself (step S3232).
  • the server control unit 3210 of the intermediary device 3200 transfers the response to the SELECT query of the transaction T4 and the response to the COMMIT query of the transaction T3 received from the selected server 3100a to the requesting clients 3500a and 3500b, respectively. (Steps S3233, S3234). After that, queries of each client 3500a and 3500b are processed by the normally operating server 3100a.
  • the mediation device 3200 transfers the query to the server 3100a that is operating normally (step S3236). Then, upon receiving a response to the query from server 3100a (step S3237), mediation device 3200 returns this response to requesting client 3500b (step S3238).
  • Step S3239 the restart of the server 3100b from which the system power has been disconnected has been completed.
  • the server 3100b transmits data to the mediation device 3200.
  • a database synchronization request is transmitted (step S3240).
  • the server control unit 3210 of the mediation device 3200 performs a process of synchronizing the database 3101a of the server 3100a and the database 3101b of the server 3100b in cooperation with the server 3100a that is operating normally (step S3241). The details of this synchronization processing will be described later.
  • the server control unit 3210 changes the operation state of the server 3100b to active in the server management table 3201 to incorporate the server 3100b into the system again (step S3242).
  • a snapshot of the database 3101 is created on the server 3100 that is operating normally at the start of the synchronization processing, and this snapshot is transferred to the new server 3100 to be synchronized. Then, the new server 3100 restores the database 3101 from the snapshot. Further, the query received from the client 3500 during this processing is accumulated in the intermediary device 3200 as difference information. When the new server 3100 completes the restoration of the database 3101 from the snapshot, the new server 3100 obtains the difference information from the intermediary device 3200 and processes the difference information.
  • the server 3100 when the server 3100 starts up, the server 3100 needs to synchronize the database. Since the request is transmitted to the mediation device 3200, the execution of the synchronization process is not limited to the restart in response to the restart instruction from the mediation device 3200. In other words, the process is also performed when the server 3100 is disconnected from the system as a failure and then re-integrated into the system. It is also implemented when adding servers that make up the system.
  • the database 3101b is out of synchronization with the database 3101a, that is, not in the same state.
  • the database 3101b may retain the data immediately before the restart or the data immediately before the occurrence of the failure, or may not have any data in the case of a completely new U or a server.
  • old data is deleted, and the database 3101b enters the system as if it does not hold any data. That is, there is no need to keep old data.
  • server management table 3201 is as shown in FIG. Further, it is assumed that the transaction management table 3202 and the difference information storage unit 3203 are empty.
  • the mediation device 3200 receives the packet (step S3301).
  • the server control unit 3210 detects that the transaction has started, and registers the IP address and the transaction number of the client 3500a in the transaction management table 3202 (Step S3302).
  • Figure 94 shows the transaction management table 3202 at this time.
  • the server control unit 3210 places the received query in the transmission queue 3204. Then, the query is extracted from the transmission queue 3204, and the packet is transferred to the server that is operating normally, in this case, the server 3100a in the server management table 3201 (step S3303).
  • the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the intermediary device 3200 Upon receiving a response packet notifying that the transaction has started normally from the server 3100a (step S3304), the intermediary device 3200 transfers the response packet to the client 3500a (step S3305). [0394] Here, it is assumed that the server 3100b has restarted (step S306). Thereby, the database control unit 3102b of the server 3100b transmits a database synchronization request to the mediation device 3200 (step S3307).
  • the server control unit 3210 Upon receiving the database synchronization request, the server control unit 3210 checks the transaction management table 3202 to determine whether there is a transaction currently being executed, and records information on the transaction being executed. (Step S3308). According to Figure 94, since the transaction of client 3500a and transaction number 3 is being executed, the database synchronization operation waits for the end of this transaction, and when a new transaction start request is received, the request is sent to the server 3100a. Is delayed (step S3309). That is, the synchronization operation starts with no transactions in progress. The transfer delay processing for the request to start a new transaction is realized by means of suspension in the transmission queue 3204.
  • the client 3500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S3310).
  • the server control unit 3210 places the received query in the transmission queue 3204. Since this query can be determined to belong to the transaction that was being executed at the time of the database synchronization request stored in step S3308, the server control unit 3210 fetches the query from the transmission queue 3204 and retrieves the server management table. After seeing 3201, Sano operating normally, in this case, the packet is transferred to the server 3100a (step S3311). Next, the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • SQL UPDATE
  • the server 3100a transmits a response packet notifying that the UPDATE has been completed normally to the mediation device 3200, and the mediation device 3200 receives this response packet (step S3312).
  • the server control unit 3210 transfers the response packet to the client 3500a (Step S3313).
  • the mediation apparatus 3200 receives the packet (step S3314).
  • the server control unit 3210 detects that the transaction has been started by this packet, and registers the IP address and the transaction number of the client 3500b in the transaction management table 3202 (step S3315).
  • Figure 95 shows the transaction management table 320 at this time. Shows 2. Then, the query relating to this packet is put in the transmission queue 3204 in the transmission state “not transmitted”. However, at this point, in order to prepare for the synchronization process, the new transaction start query is not transferred to the server 3100a while being held in the transmission queue 3204 (step S3316).
  • the client 3500a transmits a packet including SQL (COMMIT) for confirming the update to the table test—table to 172.11.1.1 (step S3317).
  • the server control unit 3210 places the received query in the transmission queue 3204. Since this query can be determined to belong to the transaction executed at the time of the database synchronization request stored in step S3308, the server control unit 3210 fetches the query from the transmission queue 3204, and Referring to Table 3201, the server is operating normally, in this case, the packet is transferred only to the server 3100a (step S3318).
  • the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the server 3100a sends a response packet notifying that the COMMIT has been completed normally to the mediation device 3200, and the mediation device 3200 receives this response packet (step S3319).
  • the server control unit 3210 deletes the registration of this transaction from the transaction management table 3202 because the completion of the transaction is a result of the successful completion of the COMMIT (step S3320).
  • Figure 96 shows the transaction management table 3202 at this time.
  • the server control unit 3210 transfers the response packet to the client 3500a (Step S3321).
  • step S3322 the server control unit 3210 starts the synchronization operation. Specifically, as shown in FIG. 91, first, the server control unit 3210 transmits a packet of a synchronization instruction (snapshot creation instruction) to the normally operating server 3100a (step S3323). . In step S3322, it is necessary to determine whether the transaction recorded in the transaction management table 3202 was being executed at the time of the database synchronization request or was subsequently received from the client 3500. Then, the information recorded in step S3308 may be referred to as the transaction information at the time of the database synchronization request.
  • a synchronization instruction synnapshot creation instruction
  • the database control unit 3102a of the server 3100a Upon receiving the synchronization instruction, the database control unit 3102a of the server 3100a sends the data Create a snapshot of the base 3101a (step S3324).
  • this snapshot is backup data of the entire database at the time when the synchronization instruction is received, and is information for restoring the database, and the update after the synchronization instruction is reflected.
  • Step S3325 the fact is notified to the mediation apparatus 3200 (Step S3326).
  • the database control unit 3102a transfers the created snapshot to the server 3100b, and the database control unit 3102b of the server 3100b restores the database from the snapshot received from the server 3100a (step S3327).
  • the transfer of the snapshot and the restoration of the database are performed in parallel with the access to the database from the client as the size of the database 3101a increases, so that the service to the client is not stopped.
  • the server control unit 3210 of the intermediary device 3200 that has received the snapshot creation completion notification restarts the service to the client 3500.
  • the processing of the packet containing the BEGIN from the client 3500b, which has been held in the transmission queue 3204 without being processed, is restarted. That is, the server control unit 3210 takes out the packet containing the BEGIN SQL from the client 3500 b, which has been held without being forwarded, from the transmission queue 3204 and stores it in the difference information storage unit 3203 (step S3328), and the server 3100a Transfer to (Step S3329).
  • the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • step S3329 transfer of snapshot
  • step S3327 does not hinder the service to the client.
  • step S3329 and step S3330 described below may be performed.
  • the server 3100a transmits a response packet notifying that the transaction has started normally to the mediation device 3200, and the mediation device 3200 receives this response packet (step S3330).
  • the mediation device 3200 transfers this response packet to the client 3500b (step S3331).
  • the server control unit 3210 transmits the received query to the transmission queue 3204. Put in. Then, the query is taken out from the transmission queue 3204, the query is stored in the difference information storage unit 3203 (step S3333), and the packet is transmitted to the normally operating server 3100a (step S3334).
  • the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the server 3100a has failed in the UPDATE and has transmitted a response packet notifying the fact to the mediation device 3200 (step S3335).
  • the mediation device 3200 sends this response packet to the client 3500b (step S3336).
  • the client 3500b that has received the UPDATE failure response packet transmits an SQL (ROLLBACK) packet for canceling the transaction to the mediation device (step S3337).
  • the server control unit 3210 places the received query in the transmission queue 3204. Then, the query is extracted from the transmission queue 3204, the SQL is stored in the difference information storage unit 3203 (step S3338), and the packet is transmitted to the normally operating server 3100a (step S3339). Next, the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • step S3340 upon receiving a response packet from the server 3100a notifying that the transaction has been successfully rolled back (step S3340), the transaction registration table is deleted from the transaction management table 3202 (step S3341), and the response packet is deleted.
  • the message is transmitted to the client 3500b (step S3342).
  • FIG. 97 shows the difference information accumulation unit 3203 at this point. Also, the transaction management table 3202 becomes empty.
  • step S3345 all the queries stored in the difference information storage unit 3203 are transferred and processed, so that the databases 3101a and 101b are completely matched (synchronous state). New queries may be received from client 3500 during this transfer process.
  • the intermediary device 3200 receives a query (BEGIN) for starting a new transaction from the client 3500b (step S3346).
  • the mediation apparatus 3200 registers the new transaction in the transaction management table 3202 (Step S3347). Then, the query is put in the transmission queue 3204.
  • the query is retrieved from the transmission queue 3204, the query is added to the end of the difference information storage unit 3203 (step S3348), and the query is transmitted to the normally operating server 3100a (step S3349). Then, the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted. Next, when a response packet is received from the server 3100a (step S3350), the response packet is transferred to the client 3500b (step S3351).
  • the query received from the client 3500 during the transfer of the difference information is processed by the server 3100 that is operating normally, and is stored in the difference information storage unit 3203. As this processing is continued, all the queries stored in the difference information storage unit 3203 are eventually transferred to the new server 3100b, and the difference information storage unit 3203 becomes empty, which triggers the difference information transfer processing. The process ends (step S3352). As a result, the databases 3101a and 101b are completely matched (synchronous state), and the synchronization processing ends. As described above with reference to FIG. 87 and FIG. 89, the synchronization process is completed. As described above with reference to FIGS. 87 and 89, the operation status of the server management table 3201 for the new server 3100 b is changed to active, so that the system It can be added (step S3144 in FIG. 87, step S3242 in FIG. 89).
  • the processing requests from the force database matching inspection device 3600 described above may be processed in the same manner. Good.
  • the database consistency checker 3600 is also one of the client computers.
  • the database consistency check device 3600 A reference query for database consistency check is transmitted to the mediation device 3200 periodically or as needed.
  • the query detects the inconsistency between the databases 3101 and executes the synchronization processing. Thereby, synchronization between the databases 3101 can be more reliably achieved.
  • the new server 3100b is in the process of restoring the database 3101b from the snapshot (step S3400). Then, when the restoration process of the database 3101b is completed in the server 3100b (step S3401), and when the server 3100b transmits the difference information transfer request to the mediation device 3200 (step S3402), the predetermined information is stored in the difference information storage unit 3203. It is assumed that difference information equal to or more than the number of cases is stored. In the example of FIG. 98, it is assumed that the UPDATE query in steps S3403 to S3407 is stored in the difference information storage unit 3203 as the latest difference information.
  • the server control unit 3210 of the mediation device 3200 receives the difference information transfer request from the server 3100b, as described above, the server control unit 3210 deletes each query stored in the difference information storage unit 3203 from the old one. Start processing to transfer to server 3100b in order from S3408).
  • the server control unit 3210 receives a packet including SQL (INSERT) for adding data to the client 3500b (step S3409).
  • the server control unit 3210 receiving the new query during the transfer of the difference information places the received query in the transmission queue 3204. Then, the query is extracted from the transmission queue 3204, and if the number of untransferred queries stored in the difference information storage unit 3203 is larger than a predetermined number, this query is added to the end of the difference information storage unit 3203.
  • the packet is transferred to the normally operating server 3100a (step S3411).
  • the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the server control unit 3210 transfers the response packet to the client 3500b (step S3413).
  • the transfer of the difference information to the server 3100b is also performed in parallel with the intermediary device 3200, and as a result, the number of untransferred queries stored in the difference information storage unit 3203 becomes equal to or smaller than a predetermined number. I do.
  • the server control unit 3210 When the server control unit 3210 receives a packet including an SQL (UPDATE) for updating data in the client 3500b (step S3414), the server control unit 3210 places the received query in the transmission queue 3204.
  • the processing of this new query is suspended (step S3415). That is, the new query is not stored in the difference information storage unit 3203 and is not transferred to the server 3100a.
  • This suspension process transfers all the queries stored in the difference information storage unit 3203 to the server 3100b, and continues until the server 3100b is incorporated into the system.
  • step S3416 When the transfer of the difference information is completed (step S3416), all the queries stored in the difference information storage unit 3203 are transferred and processed, so that the databases 3101a and 101b completely match (synchronization state). )become. Since the synchronization processing is completed as described above, the server control unit 3210 adds the server 3100b to the system by changing the operation state of the server 3100b in the server management table 3201 to active (step S3417).
  • step S34 Step 17 It corresponds to step S3144 in FIG. 87 and step S3242 in FIG. 89.
  • the server control unit 3210 resumes the processing of the new query suspended in the above step S3415.
  • the subsequent processing is the same as that described above with reference to FIG. That is, the server control unit 3210 takes out the query from the transmission queue 3204 and transfers the normally operating sano, in this case, the servers 3100a and 3100b (steps S3418 and S3419).
  • the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • step S3420 to S3422 the response packets received from each of the servers 3100a and 3100b are compared to determine whether or not a failure has occurred (steps S3420 to S3422), and one of the normal response packets is transferred to the client 3500b (step S3423).
  • the query received from the client during the transfer of the difference information is stored in the difference information storage unit 3203 and stored in the server 3100b when the untransmitted difference information is larger than the predetermined number.
  • a transfer is performed.
  • the new query is suspended. This makes it possible to synchronize the database in a short period of time when the processing of the difference information takes a long time, even when the reception interval of the query received from the client is short.
  • the “predetermined number” which is a threshold value
  • the “predetermined number” has a trade-off relationship in that setting a large value increases the hold time of a new query, while setting a small value lengthens the time to complete synchronization processing. Therefore, the “predetermined number” may be set to an optimal value individually according to the requirements of the system such as the processing load of each device and the network speed. Further, if the threshold value is set to 0 or less in this modification, the same processing as that of the embodiment described above with reference to FIGS.
  • a multiplexed database system according to a thirteenth embodiment of the present invention will be described.
  • the difference of the multiplexed database system according to the present embodiment from the twelfth embodiment lies in the content of the difference information transferred to the new server in the synchronization process.
  • Other configurations and operations are the same as those in the twelfth embodiment, and therefore, only the differences will be described here.
  • the difference information storage unit 3203 receives the information from the client 3500. All queries were saved and forwarded. As a result, queries processed by the normally operating server 3100 during the synchronization process can be faithfully reproduced on the new server 3100, thus achieving perfect synchronization. .
  • server control section 3210 stores all queries received from client 3500 as difference information accumulating section 3203, as in the twelfth embodiment. To memorize. Then, when transferring the difference information to the new server 3100, it is first determined whether or not the query is a reference query, and other than the reference query is transferred to the new server 3100. Other processes are the same as in the twelfth embodiment.
  • the server control unit 3210 receives a query from the client 3500 during the synchronization process, and accumulates the query as difference information in the difference information storage unit 3203, First, it is determined whether the query is a reference query, and information other than the reference query is stored in the difference information storage unit 3203. Then, there is a method of transferring the difference information for all the queries stored in the difference information storage unit 3203. This variant is This has the effect that the storage capacity of the difference information storage unit 3203 can be further reduced.
  • a multiplexed database system according to a fourteenth embodiment of the present invention will be described.
  • the difference between the multiplexed database system according to the present embodiment and the twelfth embodiment is the difference information accumulation processing during the database synchronization operation.
  • Other configurations and operations are the same as those of the twelfth embodiment, and therefore, only the differences will be described here.
  • server control section 3210 stores all packets received from client 3500 in difference information storage section 3203. That is, the transaction control SQL, reference SQL, and update SQL are all stored in the difference information storage unit 3203, and the server 3100 stores all the data stored in the difference information storage unit 3203 as old data. They were sent in order.
  • the server control unit 3210 includes, among the packets received from the client 3500 during the database synchronization operation, the transaction start SQL (BEGIN), the definitive SQL (COMMIT), and the cancel SQL (ROLLBACK ) Etc.Transaction control SQL and reference SQL such as SELECT are not saved, and only difference information of update SQL such as UPDATE and INSERT that is committed by the normally operating server 3100 is stored. Store it in section 3203.
  • the difference information accumulating unit 3203 accumulates update queries in the order in which they are processed by the normally operating server 3100, rather than in the order in which they are received from the client 3500. This is because the contents of the database 3101 may differ depending on the processing order for update queries whose update targets overlap.
  • the server control unit 3210 When the server control unit 3210 receives a query from the client 3500 during the synchronization processing, the server control unit 3210 sequentially accumulates only those of the update type in the difference information temporary accumulation unit 3205, and Transfer to working server 3100. On the other hand, those other than the update section are transferred to the normally operating server 3100 without being stored in the difference information temporary storage unit 3205.
  • the server control unit 3210 when receiving a response packet indicating that the execution of the update query has failed from the normally operating server 3100, deletes the update query from the difference information temporary storage unit 3205. Further, upon receiving a response packet indicating that the transaction RO LLBACK has been completed normally from the normally operating server 3100, the server control unit 3210 also stores all update queries belonging to the transaction in the difference information temporary storage unit 3205. delete. On the other hand, upon receiving a response packet indicating that the transaction COMMIT has been completed normally from the normally operating server 3100, the server control unit 3210 transmits the update information belonging to the transaction to the difference information temporary storage unit 3205 to the difference information storage unit 3203. Sequentially.
  • the query received from the client 3500 is sent from the difference information temporary storage unit 205 to the difference information storage
  • the query may be moved when the server 3100 that is operating normally processes the query normally.
  • the transaction ROLLBACK if the transaction ROLLBACK, The belonging update query may be deleted from the difference information storage unit 203. This kind of processing is effective to completely match the database of a DBMS whose row order changes according to the update order, such as PostgreSQL.
  • a multiplexed database system according to a fifteenth embodiment of the present invention will be described.
  • the multiplexed database system according to the present embodiment is different from the twelfth embodiment in the structure of the difference information storage unit.
  • Other configurations and operations are the same as those in the twelfth embodiment, and therefore, only the differences will be described here.
  • the mediation device 3200 does not include the difference information storage unit 3203, and stores the difference information in the transmission queue 3206 in the first embodiment.
  • the functions of the storage unit 3203 and the transmission queue 3204 are integrated.
  • the data structure of transmission queue 3206 will be described with reference to FIG.
  • the transmission queue 3206 stores the content of the query received from the client 3500, the transaction ID to which the query belongs, and the status of transmission to each server 3100.
  • the transaction ID is obtained from the transaction management table 3202 as in the twelfth embodiment.
  • the transmission status to each server 3100 is stored for each server 3100 belonging to the system.
  • server control unit 3210 receives the query from the client 3500, if the query is a transaction start SQL (BEGIN), it issues a new transaction ID for the transaction and registers it in the transaction management table 3202. And the contents of the query, new transaction ID Then, the transmission status of each server 3100 is registered in the transmission queue 3206 as “not transmitted”. If the query received from the client 3500 is other than the transaction start SQL (BEGIN), the transaction ID to which the query belongs is obtained from the transaction management table 3202, and the contents of the query, the transaction ID, and the transmission status of each server 3100 are obtained. Register in the transmission queue 3206 with "not sent”.
  • BEGIN transaction start SQL
  • the server control unit 3210 transmits the query recorded in the transmission queue 3206 to the server 3100 whose transmission status is “not transmitted”, and "transmits" the transmission status of the server 3100. Change to "Complete.” For queries for which the transmission status is “transmission completed” for all servers 3100, the query is deleted from the transmission queue 3206.
  • Each server 3100 that has received the query from the mediation device 3200 processes the query, and returns a response packet to the mediation device 3200.
  • the server control unit 3210 of the intermediary device 3200 compares the response packets received from each server 3100, checks whether a failure has occurred, and returns one of the normal response packets to the client 3500.
  • FIG. 103 shows an example of the transmission queue 3206 when the transmission queue 3206 is in the state shown in FIG. 102 and the server 3100b is also disconnected from the system.
  • the server control unit 3210 suspends the start of a new transaction until the transaction being executed when the database synchronization request is received ends. Specifically, when the query received from the client 3500 relates to a new transaction, the transmission status is stored in the transmission queue 3206 as “pending”. On the other hand, if the query received from the client 3500 relates to the transaction being executed at the time of the database synchronization request, the transmission status is stored in the transmission queue 3206 as “not transmitted”.
  • Figure 104 shows that transmit queue 3206 is 13 is an example of a transmission queue 3206 when a query is newly received from the client 3500 in the state shown in FIG.
  • the server control unit 3210 transmits the new server to be incorporated into the transmission queue 3206. Add 3100 items.
  • the transmission queue 3206 may store a query whose transmission status is “pending”.
  • the server control unit 3210 sets the transmission state of the new server 3100 to “pending” in response to the query stored in the transmission queue 3206.
  • FIG. 105 shows a case where a new server 3100b is registered in the transmission queue 3206 of FIG.
  • the server control unit 3210 when the server control unit 3210 finishes transmitting all queries related to the transaction being executed at the time of receiving the database synchronization request to the normally operating server 3100, the server control unit 3210 performs the normal operation similarly to the twelfth embodiment. Sends a synchronization instruction (instruction to create a snapshot) to the server 3100.
  • the server control unit 3210 Upon receiving the snapshot creation completion notification from the normally operating server 3100, the server control unit 3210 resumes query transmission to the normally operating server 3100. Specifically, first, for all queries stored in the transmission queue 3206 (at this time, the transmission statuses of all the tiers are “pending” for all the servers 3100), the servers that are operating normally Change the transmission status of the 3100 to "not sent”. Then, the server control unit 3210 sequentially transmits queries whose transmission status is “not transmitted” to the server 3100, and when transmission is completed, changes the transmission status to “transmitted”.
  • Figure 106 shows the transmission key of Figure 105. This shows a case where a new query is received after receiving a snapshot completion notification to the user 3206. Also, as shown in Fig. 107, even though the transmission is completed for the normally operating server 3100a, the transmission is completed for the new server 3100b! / The query is not deleted from the transmission queue 3206.
  • the server control unit 3210 receives a difference information transfer request from the new server 3100.
  • the server control unit 3210 is a query stored in the transmission queue 3206, and the transmission state is “pending”! /
  • the server also sends the old server to the server 3100 that has been “held”, that is, the new server 3100.
  • the transmission status of the server 3100 in the transmission queue 3206 is set to “transmission completed”, and when the transmission status of all the servers 3100 becomes “transmission completed”, the entry is deleted.
  • the server control unit 3210 adds the new server 3100 to the server management table 3201 as "active" when the query whose transmission status is "pending" no longer exists in the transmission queue 3206. Incorporate the server 3100 into the system. The subsequent operation is the same as that in the case where each server 3100 operates normally.
  • the functions of the difference information accumulating unit 3203 and the transmission queue 3204 in the twelfth embodiment are integrated into one transmission queue 3206. Therefore, the use efficiency and processing efficiency of the memory are improved. Further, since the transmission status to each server 3100 is stored for each query in the transmission queue 3206, the transmission status of the server 3100 may be added when a new server 3100 is incorporated. This allows a plurality of servers 3100 to be incorporated into the system at one time. Other effects are the same as in the twelfth embodiment.
  • a multiplexed database system according to a sixteenth embodiment of the present invention will be described.
  • the difference of the multiplexed database system according to the present embodiment from the fifteenth embodiment lies in the method of storing difference information.
  • Other configurations and operations are the same as those of the fifteenth embodiment, and therefore, only the differences will be described here.
  • the timing at which the mediation apparatus 3200 transmits a snapshot creation instruction to the normally operating server 3100 is the timing at which the mediation apparatus 3200 is executing on the normally operating server 3100. This is when there are no more transactions. Specifically, in parallel with processing of the transaction being executed at the time of receiving the database synchronization request from the new server 3100 on the normally operating server 3100, the client The request to start a new transaction received from the 3500 was pending. Then, when there is no transaction being executed when the database synchronization request is received, a snapshot creation instruction is transmitted. This is because, depending on the DBMS, if a transaction is being executed at the time of snapshot creation, the data update power of update queries belonging to that transaction may be uncertain whether the power reflected in the snapshot is uncertain. is there.
  • the server 3100 does not reflect update queries belonging to the transaction being executed at the time of snapshot creation and update queries received during the snapshot creation process in the snapshot. Use what performs. In other words, if a transaction ends and a COMMIT is performed during the creation of a snapshot, the update by the transaction is not reflected in the snapshot.
  • the server control unit 3210 of the intermediary device 3200 transmits a snapshot creation instruction and starts a new transaction without waiting for the end of the transaction being executed when receiving the database synchronization request. Can be.
  • the database control unit 3102 of the server 3100 does not need to transmit a completion notification to the mediation device 3200 even when the snapshot creation is completed, because the mediation device 3200 does not need to wait for the snapshot creation completion.
  • server control unit 32 of mediation apparatus 3200 has 10 deletes the registration of the query stored in the transmission queue 3206 when the transmission status of all the servers 3100 becomes “transmission completed” and the transaction belonging to the query ends. I do.
  • the server control unit 3210 Upon receiving the database synchronization request from the new server 3100b, the server control unit 3210 transmits a synchronization instruction (snapshot creation instruction) to the normally operating server 3100a.
  • FIG. 108 shows an example of the transmission queue 3206 when the new server 3100b transmits a database synchronization request to the mediation device 3200.
  • the queries stored in the transmission queue 3206 remain without being deleted if the transaction to which the query belongs has not been completed even after the transmission of the query is completed.
  • the SANO 3100a Upon receiving the synchronization instruction, the SANO 3100a starts creating a snapshot. The snapshot created here does not reflect the query stored in the transmission queue 3206.
  • the server control unit 3210 sets the transmission status of the new server 3100b to “pending” and adds all the queries stored in the transmission queue 3206. I do.
  • An example of the transmission queue 3206 at this time is shown in FIG.
  • the server control unit 3210 When the server control unit 3210 receives a query from the client 3500 after receiving the database synchronization request, the server control unit 3210 changes the transmission status of the normally operating server 3100a to "not yet transmitted” and the transmission status of the new server 3100b. Set to “Hold” and add to transmission queue 3206 sequentially. Then, the queries whose transmission status is “not transmitted” are sequentially transferred to the “untransmitted” server 3100a, and the transmission status is changed to “transmission completed”. At this time, as shown in FIG. 110, the query stored in the transmission queue 3206 indicates that the transmission status of the normally operating server 3100a is “transmission completed” for each transaction, but the query of the new server 3100b is not completed. Is "pending", so we do not delete the query here.
  • the server 3100a which has received the snapshot creation instruction from the mediation device 3200, Send the created snapshot to the new server 3100b.
  • the database control unit 3102b of the new server 3100b restores the database 3101b from the received snapshot and sends a difference information transfer request to the mediation device 3200.
  • the server control unit 3210 Upon receiving the difference information transfer request, the server control unit 3210 sends the query stored in the transmission queue 3206 to the new server 3100b as the difference information with the transmission status "pending"! Then, the transmission state is changed to “transmission completed” as shown in FIG. Then, as described above, when the transmission status of all servers is “transmission completed” and the transaction of the query is completed, the query is deleted. Thereafter, when a query is received from the client 3500 while a query whose transmission status is “pending” is transmitted, the transmission status of the normally operating server 3100a is “untransmitted” and the transmission of the new server 3100b is performed as shown in FIG. The status is stored in the transmission queue 3206 as “pending”. Then, at the point when the query of “transmission status ⁇ pending” disappears, the synchronization of the database 3101a and the database 3101b is completed.
  • the server 3100 (1) creation of a snapshot can be started even while a transaction is being executed, (2) a query can be processed during creation of a snapshot, and the query becomes a snapshot. (1 ') The ability to start creating a snapshot while a transaction is running (2') The query cannot be processed during snapshot creation! / ⁇ or the query is processed during snapshot creation Then, it is possible to use a server 3100 in which the processing may be reflected in the snapshot.
  • a snapshot creation instruction may be sent to the normally operating server 3100, but the snapshot creation start force is also created.
  • transmission of queries to the normally operating server 3100 must be suspended.
  • queries received from client 3500 during snapshot creation are kept in the transmission queue.
  • No. 3100 needs to notify the mediation device 3200 of the completion of snapshot creation. As a result, the range of server selection is wider than in the present embodiment.
  • a multiplexed database system according to a seventeenth embodiment of the present invention will be described.
  • the difference of the multiplexed database system according to the present embodiment from the twelfth embodiment is that in the twelfth embodiment, processing of a query from a client and creation of a snapshot during synchronization processing are performed by the same server. However, in the present embodiment, the operations are performed on different servers. Therefore, as shown in FIG. 113, three or more Sano 3100s are required. Other configurations and operations are the same as those of the twelfth embodiment, and therefore, only the differences will be described here.
  • the database 3101c is not synchronized with the databases 3101a and 3101b, that is, is not the same.
  • the database 3101c may hold the data just before the restart or the data just before the failure occurred, or may have no data in the case of a completely new server. Absent. In the present invention, even in the former case, old data is deleted, and the database 3101c is incorporated into the system as if it did not hold any data.
  • server management table 3201 is as shown in FIG. Further, it is assumed that the transaction management table 3202 and the difference information storage unit 3203 are empty.
  • the client 3500a starts a transaction addressed to 172.17.1.1 SQL
  • mediation apparatus 3200 receives the packet (step S3500).
  • the server control unit 3210 detects that the transaction has started, and registers the IP address and the transaction number of the client 3500a in the transaction management table 3202 (step S3501).
  • FIG. 118 shows the transaction management table 3202 at this time.
  • the server control unit 3210 places the received query in the transmission queue 3204. Then, the query is taken out from the transmission queue 3204, and the packet is transferred to a normally operating server, in this case, the servers 3100a and 101b by referring to the server management table 3201 (step S3502, S3503). Next, the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 3200 Upon receiving the response packet from each server 3100 (steps S3504 and S3505), the mediation device 3200 compares the response packets and checks for a failure (step S3506), and sends one of the valid response packets to the client. Transfer to 3500a (step S3507).
  • the database control unit 3102c of the server 3100c transmits a database synchronization request (embedding request) to the mediation device 3200 (step S3508).
  • the server control unit 3210 Upon receiving the database synchronization request, the server control unit 3210 checks the transaction management table 3202 to confirm whether there is a transaction currently being executed, and records information on the transaction being executed. (Step S3509). According to Figure 118, since the transaction of client 3500a and transaction number 3 is being executed, the database synchronization operation waits for the end of this transaction, and at the same time receives a new transaction start request, sends the request to the server 3100. Is delayed (step S3510). That is, the synchronization operation starts with no transactions in progress. The transfer delay processing for the request to start a new transaction is realized by means of suspension in the transmission queue 3204.
  • the client 3500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S3511).
  • the server control unit 3210 places the received query in the transmission queue 3204.
  • the query can be determined to belong to the transaction executed at the time of the database synchronization request.
  • the server control unit 3210 extracts the query from the transmission queue 3204, and Looking at the server management table 3201, the normally operating server transfers the packet to the servers 3100a and 3100b in this case (steps S3512 and S3513). 0 Then, sets the transmission status of the transmission queue 3204 to “transmission completed”. To delete the entry.
  • the mediation device 3200 waits until response packets are received from the servers 3100a and 3100b that are operating normally (steps S3514 and S3515), and when all the response packets are completed, determines whether there is a failure from the packets (step S3516). Then, the server control unit 321 0 transfers one of the valid response packets to the client 3500a (step S3517).
  • the mediation device 3200 receives the packet (step S3518).
  • the server control unit 3210 detects that the transaction has been started by this packet, and registers the IP address and the transaction number of the client 3500b in the transaction management table 3202 (step S3519).
  • FIG. 119 shows the transaction management table 3202 at this time.
  • the query relating to this packet is put in the transmission queue 3204 in the transmission state “not transmitted”.
  • the new transaction start query is not transferred to the normally operating servers 3100a and 3100b while being held in the transmission queue 3204! (Step S3520).
  • the client 3500a transmits a packet containing SQL (COMMIT) for confirming the update to the table test-table to 172.11.1.1 (step 33521).
  • the server control unit 3210 places the received query in the transmission queue 3204. This query can be determined to belong to the transaction executed at the time of the database synchronization request by referring to the transaction information stored in step S3509, so the server control unit 3210 extracts the query from the transmission queue 3204 and retrieves the query. Then, the packet is transferred to the server that is operating normally by referring to the server management table 3201, in this case, the servers 3100a and 3100b (steps S3522, S3523).
  • the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the mediation device 3200 waits until response packets are received from all the normally operating servers 3100a and 3100b (steps S3524, S3525), and when all the response packets are complete, checks for a failure from the packets (step S3524, S3525). S3526).
  • the server control unit 3210 deletes the registration of this transaction from the transaction management table 3202 (step S3527).
  • FIG. 120 shows the transaction management table 3202 at this time.
  • the server control unit 3210 transfers one of the valid response packets to the client 3500a (step S3528).
  • Step S3529 the server control unit 3210 executes the server 3 that is operating normally.
  • the server management table 320 is changed to “sync”, and the server 3100b is disconnected from the system (step S3532).
  • the server management table 320 is changed to “sync”, and the server 3100b is disconnected from the system (step S3532).
  • step S3529 to determine whether the transaction recorded in the transaction management table 3202 was being executed at the time of the database synchronization request, or was subsequently received from the client 3500, Refer to the transaction information at the time of the database synchronization request recorded in step S3509.
  • a snapshot of the database 3101b is created (step S3533).
  • this snapshot is the backup data of the entire database and information for restoring the database at the time when the synchronization instruction is received, and the update after the synchronization instruction is reflected. Should.
  • the database control unit 3102b of the synchronization server 3100b transfers the created snapshot to the new server 3100c.
  • the transfer of the snapshot and the restoration of the database take longer when the size of the database 3101b is larger, and it is executed in parallel with the database access from the client, so the service to the client is not stopped. .
  • the database control unit 3102c of the new server 3100c restores the database from the snapshot received from the synchronization server 3100b (Step S3535).
  • the server control unit 3210 of the mediation device 3200 changes the state of the server management table 3201 to "sync" for the server 3100b (step S3532), and restarts the service to the client 3500.
  • the server that processes the processing request from the client 3500 is the server 3100 & whose status is “ & ( ⁇ ). That is, the synchronization server 3100b temporarily stops processing. The system power is also cut off, and only the synchronization processing is performed. Also, here, the packet is retained in the transmission queue 3204 without being processed, and processing of the packet including the BEGIN from the client 3500b is resumed.
  • the server control unit 3210 retains the packet without forwarding it, extracts the packet containing the BEGIN SQL from the client 3500b from the transmission queue 3204, stores it in the difference information storage unit 3203 (step S3535), and Transfer to the normally operating server 3100a (step S3536).
  • the transmission status of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the normally operating server 3100a transmits a response packet to the mediation device 3200, and the mediation device 3200 receives this response packet (step S3537).
  • the mediation device 3200 transfers the response packet to the client 3500b (Step S3538).
  • the server control unit 3210 places the received query in the transmission queue 3204. .
  • the query is extracted from the transmission queue 3204, the query is stored in the difference information storage unit 3203 (step S3540), and the packet is transmitted to the normally operating server 3100a (step S3541).
  • the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the server 3100a has failed in the UPDATE and has transmitted a response packet notifying the fact to the mediation device 3200 (step S3542).
  • the mediation device 3200 sends this response packet to the client 3500b (step S3543).
  • the client 3500b which has received the UPDATE failure response packet, transmits an SQL (ROLLBACK) packet for canceling the transaction to the mediation device (step S3544).
  • the server control unit 3210 places the received query in the transmission queue 3204. Then, the query is extracted from the transmission queue 3204, the SQL is stored in the difference information storage unit 3203 (step S3545), and the packet is transmitted to the normally operating server 3100a (step S3546). Next, the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • step S3547 upon receiving a response packet from the server 3100a notifying that the transaction has been successfully rolled back (step S3547), the transaction registration table is deleted from the transaction management table 3202 (step S3548), and Is transmitted to the client 3500b (step S3549).
  • FIG. 122 shows the difference information accumulation unit 3203 at this point. Also, the transaction management table 3202 will be empty
  • step S3550 it is assumed that the restoration of the database 3101c from the snapshot has been completed on the new server 3100c (step S3550).
  • the new server 3100c transmits a difference information transfer request to the mediation device 3200 (Step S3551).
  • the server control unit 3210 of the mediation device 3200 starts processing to transfer the data stored in the difference information storage unit 3203 to the new server 3100c and the synchronization server 3100b in order from the oldest one. (Step S3552).
  • step S3552 Although all queries stored in the difference information storage unit 3203 are transferred and processed in step S3552, the database 3101a and the databases 3101b and 101c completely match (synchronize).
  • a new query may be received from the client 3500.
  • the mediation device 3200 receives a query (BEGIN) for starting a new transaction from the client 3500b (step S3553).
  • the mediation device 3200 registers the new transaction in the transaction management table 3202 (Step S3554).
  • the query is entered into the transmission queue 3204.
  • the query is extracted from the transmission queue 3204, added to the end of the difference information storage unit 3203 (step S3555), and transmitted to the normally operating server 3100a (step S3556).
  • the transmission state of the transmission queue 3204 is set to “transmission completed”, and the entry is deleted.
  • the response packet is transferred to the client 3500b (step S3558).
  • the query received from the client 3500 during the transfer of the difference information is processed by the normally operating server 3100, and is stored in the difference information storage unit 3203. As this process is continued, all the queries stored in the difference information storage unit 3203 are transferred to the new server 3100c and the synchronization server 3100b, and the difference information storage unit 3203 becomes empty.
  • the difference information transfer processing ends (step S3559). As a result, the database 3101a and the databases 3101b and 101c are completely matched (synchronous state). State). Since the synchronization processing is completed as described above, the operation of the server management table 3201 for the synchronization server 3100b and the new server 3100c is performed as in the twelfth embodiment described above with reference to FIGS.
  • FIG. 123 shows the server management table 3201 at this time.
  • server 3100 for synchronization processing is selected from a plurality of normally operating servers 3100. Since the snapshot is created and transferred using the synchronization processing server 3100, the processing request from the client 3500 can be processed in parallel with this using the other normally operating server 3100. Therefore, since the embedded processing and the processing related to the processing request from the client are processed by different servers, the load is distributed, and the processing request from the client 3500 can be responded to during the snapshot creation. In this way, we can continue to provide smooth services to clients 3500.
  • a multiplexed database system according to an eighteenth embodiment of the present invention will be described with reference to the drawings.
  • the multiplexed database system according to the present embodiment differs from the above-described seventeenth embodiment in the transmission timing of the difference information to the synchronization server and the new server.
  • the intermediary device upon receiving the difference information transfer request from the new server, the intermediary device simultaneously transmits the difference information to both the new server and the synchronization server.
  • the process of sending the difference information to the synchronization server and the process of sending the difference information to the new server are asynchronously performed in parallel.
  • the mediation device according to the present embodiment needs to accumulate difference information for a plurality of servers independently of each other, and thus has the same configuration as the mediation device according to the above-described fifteenth embodiment. . That is, in the transmission queue 3206, The difference information is stored.
  • the mediation device 3200 receives a difference information transfer request not only from the new server 3100 but also from the synchronization server 3100. Then, when the difference information transfer request is received, queries in which the transmission status of the requesting server in the transmission queue 3206 is “pending” are sequentially transmitted to the requesting server, and the transmission request for the server is transmitted. Update the status to "transmission completed”. Then, when the query of the server requesting the difference information transfer is put on hold and the transmission of the query is completed, the server management table 3201 is updated by the server and incorporated into the system. Other processing such as processing of a query from the client 3500 at the time of the difference information transfer processing is the same as in the above-described fifteenth embodiment. For example, it is the same as the fifteenth embodiment in that a query whose transmission status is “transmission completed” for all servers 3100 is deleted from the transmission queue 3206.
  • the synchronization server 3100 Upon receiving the synchronization instruction (snapshot creation instruction) from the intermediary device 3200, the synchronization server 3100 starts creating a snapshot. Next, when the creation of the snapshot is completed, a difference information transfer request is transmitted to the mediation device 3200, and the transfer of the snapshot to the new server 3100 is started. Since the difference information is sequentially received from the mediation device 3200 in response to the difference information transfer request, the synchronization server 3100 processes the difference information.
  • the new server 3100c sends a database synchronization request (a request to incorporate it into the system) to the mediation device 3200, and the mediation device 3200 selects the server 3100b as a synchronization server, and It is assumed that a synchronization instruction is transmitted to the server 3100b (step S3601) and the server 3100b is disconnected from the system (step S3602).
  • the synchronization server 3100b Upon receiving the synchronization instruction from the mediation device 3200 (step S3601), the synchronization server 3100b starts creating a snapshot (step S3603).
  • a difference information transfer request is transmitted to the mediation device 3200 (step S3605), and the snapshot is transferred to the new server 3100.
  • the transfer to c is started (step S3606).
  • the mediation device 3200 Upon receiving the difference information transfer request from the synchronization server 3100b, the mediation device 3200 starts sending difference information to the server 3100b (step S3607). Specifically, of the queries stored in the transmission queue 3206, those whose transmission status for the synchronization server 3100b is “pending” are transmitted to the synchronization server 3100b in order from the oldest one. . Then, the transmission status of the synchronization server 3100b in the transmission queue 3206 for the query is updated to “transmission completed”.
  • the mediation device 3200 When a query (UPDATE in FIG. 124) is received from the client 3500 during transfer of the difference information to the synchronization server 3100b (step S3608), the mediation device 3200 stores the query as difference information (step S3609). ). Specifically, the transmission status of the query is set to “not transmitted” for the normally operating server 3100a, and the transmission status is set to “pending” for the synchronization server 3100b and the new server 3100c. accumulate. Next, the mediation device 3200 transfers the packet including the query to the normally operating server 3100a (step S3610), and sets the transmission status of the transmission queue 3206 to Sano 3100a [kotsu! Update to "Done". Then, a response packet (step S3611) from the normally operating server 3100a is returned to the requesting client 3500 (step S3612).
  • a response packet step S3611
  • Step S3613 When the restoration of the database 3101c is completed based on the snapshot (Step S3613), the new server 3100c transmits a difference information transfer request to the mediation device 3200 (Step S3614).
  • the mediation apparatus 3200 Upon receiving the difference information transfer request from the new server 3100c (Step S3614), the mediation apparatus 3200 starts sending the difference information to the server 3100c (Step S3615). Specifically, among the queries stored in the transmission queue 3206, the transmission status of the new server 3100c whose status is “pending” is transmitted to the new server 3100c in order of oldness and power. Then, the transmission status of the new server 3100c is updated to “transmission completed” for the query.
  • the present embodiment is characterized in that the difference information transfer to the synchronization server 3100b and the difference information transfer to the new server 3100c are performed in parallel and asynchronously with each other.
  • the mediation apparatus 3200 While transferring the difference information to the synchronization server 3100b and the new server 3100c, the client Upon receiving the query (INSERT in FIG. 124) from the client 3500 (step S3616), the mediation apparatus 3200 stores the query as difference information (step S3617). Specifically, the transmission status of the server 3100a that is operating normally is set to “not transmitted”, and the transmission status of the synchronization server 3100b and the new server 3100c is set to “pending”. To accumulate. Next, the mediation device 3200 transfers the data to the normally operating server 3100a (step S3618), and updates the transmission status of the server 3100a in the transmission queue 3206 to “transmission completed”. Then, a response packet (step S3619) from the normally operating server 3100a is returned to the requesting client 3500 (step S3620).
  • the mediation apparatus 3200 completes the transmission of the difference information. Update the server management table 3201 for the servers 3100b and 3100c and incorporate them into the system.
  • step S3621 the sending of the difference information to the synchronization server 3100b ends before the new server 3100c (step S3621), and the mediation device 3200 sends the server information about the synchronization server 3100b to the server.
  • the operation status of the management table 3201 is changed to active and incorporated into the system (step S3622).
  • the query (UPDATE in FIG. 125) from the client 3500 is processed by the normally operating server 3100a and the server 3100b incorporated in the step S3622. . That is, first, when a query is received from the client 3500 (step S3623), the mediation device 3200 stores the query as difference information (step S3624). Specifically, the transmission status of the query is set to “not transmitted” for the servers 3100 a and 3100 b that are operating normally, and the transmission status of the new server 3100 c is stored in the transmission queue 3206 with “pending”.
  • the mediation device 3200 transfers the sanoes 3100a and 3100b that are operating normally (steps S3625 and S3626), and updates the transmission status of the transmission queue 3206 for the servers 3100a and 3100b to “transmission completed”. Then, the validity of the response packets (steps S3627, S3628) from the normally operating servers 3100a and 3100b is checked (step S3629), and one of the correct responses is returned to the requesting client 3500 (step S3630). ). [0503] Next, when the query whose transmission status is "pending" with respect to the new server 3100c disappears from the transmission queue 3206 for the new server 3100c, the transmission of the difference information is completed (step S3631). The operation status of the new server 3100c in the server management table 3201 is added as “active” and incorporated into the system (step S3632).
  • the time for the system of the synchronization server 3100 to be returned to the built-in state is earlier. It is possible to shorten the period in which the number of servers is smaller than usual. Therefore, the fault tolerance of the system is improved.
  • the servers do not need to have the same implementation if they respond the same in response to a request. That is, versions, specifications, programming languages, types of compilers, compiler options, hardware capabilities, software capabilities, and the like may differ.
  • the server can be free software such as PostgreSQL, commercially available software such as Oracle, or proprietary software. They may be mixed.
  • server 3100a may be PostgreSQL and server 3100b may be Oracle.
  • the database control unit 3102 separates the functions into a database management unit and a database server management unit, so that the middle product is not modified.
  • the database management unit directly operates the database 3101.
  • PostgreSQL it is equivalent to postmaster or postgres.
  • the database server management unit intervenes between the intermediary device 3200 and the database management unit, relays the transmission and reception of queries, creates a snapshot of the database 3101 when synchronizing other servers, That snapshot To transfer the data to another server.
  • DBMS is PostgreSQL
  • a snapshot can be created using a dump tool such as pg—dump or a backup tool.
  • pg-dump is useful for synchronizing Post greSQL servers.
  • heterogeneous DBMSs for example, PostgreSQL and Oracle
  • normal operation is performed without using DBMS-specific tools. You can use a general-purpose tool to retrieve all data from a DBMS server using a SELECT query and enter data using an INSERT query.
  • the request for incorporating into the system is transmitted by the database control unit 3102 of the new server 3100 to the mediation device 3200.
  • the power of another device such as a terminal may be transmitted, or the operator may directly instruct the mediation device 3200.
  • the server is realized by software on a personal computer, but may be implemented by hardware.
  • the database matching check device 3600 was connected to the outside of the multiplexed database system, that is, to the network 3400. However, as shown in FIG. It is also possible to connect the database match inspection device 3600 to the network 3300 of this company.
  • FIG. 131 is a block diagram illustrating the overall configuration of the multiplexed database system according to the present embodiment.
  • a plurality of database servers (hereinafter referred to as "servers") 4100 and an intermediary device 4200 are connected by a network 4300, and a network 4400 is connected.
  • client computers (“Clients” Ant ”) 4500 and the database consistency checker 4600.
  • FIG. 131 there are two SANOOs 100a and 4100b, and two clients 4500a and 4500b are also accessed.
  • the subscripts “a” and “b” are added with calories. The same applies to client 4500.
  • the server 4100 and the client 4500 are connected to separate networks 4300 and 4400, respectively, but may be connected to the same network.
  • the mediation device 4200 has an IP address on the network 4400 side.
  • 172.17.1.1 which is published as the IP address of the database server.
  • the client 4500 or the database matching check device 4600 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 4200 at 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 4500 or the like.
  • the virtual database server having the IP address 172.17.1.1 is called a virtual server 4800.
  • the purpose of this virtual server 4800 is to hide that the server 4100 is redundant.
  • the server 4100 includes a database 4101 that stores and manages data, and a database control unit 4102 that controls the operation of the database 4101.
  • the database 4101 is an RD BMS (Relational Database Management System) that performs processing by interpreting SQL (Structured Query Language).
  • SQL Structured Query Language
  • the database control unit 4102 operates based on the packet transmitted from the mediation device 4200 via the network 4300. This packet is stored in database 4101 such as SQL And processing related to the synchronization processing. For those related to processing in the database 4101 such as SQL, the database control unit 4102 passes the packet to the database 4101 and returns the processing result from the database 4101 to the intermediary device 4200.
  • database 4101 such as SQL And processing related to the synchronization processing.
  • the database control unit 4102 passes the packet to the database 4101 and returns the processing result from the database 4101 to the intermediary device 4200.
  • snapshot creation instruction synchronization instruction
  • the database control unit 4102 Upon receiving the snapshot creation instruction from the mediation device 4200, the database control unit 4102 creates a snapshot of the database 4101. Then, when the creation of the snapshot is completed, the completion of snapshot creation is notified to the mediation device 4200. Then, the created snapshot is transferred to another transfer destination server 4100 instructed by the snapshot creation instruction.
  • the snapshot means the copy data of the entire database that has been determined at the time of the creation start (committed! /), And the data necessary for restoring the database. Therefore, it should be noted that the snapshot is COMMITed at the beginning of creation and does not include! /, Na! /, Data! /.
  • the database control unit 4102 restores its own database 4101 using this snapshot.
  • a difference information transfer request is sent to the mediation device 4200.
  • the difference information is the query which is not reflected in the snapshot among the queries received from the client 4500 by the mediation device 4200, and is stored and accumulated in the mediation device 4200.
  • the database control unit 4102 When the database control unit 4102 receives the restart instruction from the mediation device 4200, the database control unit 4102 restarts the database 4101 and the database control unit 4102. In this restart process, only the processes of the database 4101 and the database control unit 4102 may be restarted, and the database 4101 and the database control unit 4102 are set to be automatically started when the server 4100 is started! For example, restarting the entire server 4100, . Further, when the database control unit 4102 is activated (including a restart), the database control unit 4102 transmits a database synchronization request (a request for threading to the system) to the intermediary device 4200.
  • a database synchronization request a request for threading to the system
  • the mediation device 4200 temporarily stores a server management table 4201 for managing the server 4100 in the present system, a transaction management table 4202 for managing the transaction, and a query transmitted to the server 4100.
  • a response transmission processing unit 4207 for transmitting to the original client 4500 and the like and a synchronization processing control unit 4208 for controlling the synchronization processing between the servers 4100 are provided. That.
  • the server management table 4201 indicates whether the server is operating normally and can process queries (acti ve), is synchronizing (sync), or is running normally and can process queries. And the status information indicating whether the synchronization process is in progress (active + sync).
  • the server management table 4201 also includes a server ID for identifying the server 4100 and the operating status of the server.
  • the server 4100a and the server 4100b are registered, and the operation states are both active indicating normal operation.
  • the IP address assigned to the server 4100 is used as the server ID.
  • the transaction management table 4202 stores the presence or absence of a transaction that is currently being executed or whose execution is suspended.
  • FIG. 134 shows an example of the transaction management table 4202.
  • the transaction management table 4202 also 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 4202 by the reception query processing unit 4204 at the start of the transaction, and are transmitted by the response transmission processing unit 4207 at the end of the transaction. Deleted from the management table 4202.
  • the client ID is, for example, an IP address or a port number of the client 4500 or the like.
  • the transaction ID is new, and each time a transaction occurs, the reception query processing unit 4204 newly allocates the transaction ID.
  • the transmission queue 4203 has a function as a transmission buffer when transmitting a query that has also received a client 4500 to the server 4100, and stores and accumulates a query received from the client 4500 as difference information during the synchronization processing. It has a function.
  • the transmission queue 4 203 stores the content of the query received from the client 4500, the transaction ID to which the query belongs, the transmission status to each server 4100, and the status when the query is processed by the normally operating server 4100.
  • the processing result is stored.
  • the transaction ID is obtained from the transaction management table 4202.
  • the transmission status to each server 4100 is stored for each server 4100 belonging to the system.
  • the transmission state of the transmission queue 4203 to each server 4100 can take four values: “not transmitted”, “transmission completed”, “hold”, and “release of hold”. “Not yet transmitted” is a state in which transmission is scheduled to the corresponding laser 100 without any suspension but has not been transmitted yet. “Transmission completed” is a state in which transmission to the server 4100 has been completed. “Pending” is a state where the server 4100 is suspended without being transferred to the server 4100 during the process of incorporating the server 4100 into the system. “Release hold” is a state in which the “hold” state has been released but has not been transmitted. Each entry of the transmission queue 4203 is deleted from the transmission queue 4203 when the transmission status of all the servers 4100 becomes “transmission completed” and the transaction to which the query belongs ends.
  • the received query processing unit 4204 analyzes the query and, when detecting the start of a new transaction, detects a transaction management table.
  • the transaction is registered in 4202, and a reception query is entered in the transmission queue 4203 with reference to the server management table 4201.
  • the method by which the reception query processing unit 4204 detects the start of a new transaction differs depending on the type of DBMS. For example, in the case of PostgreSQL described above, opening a transaction The beginning is when the client 4500 etc. sends the SQL “BEGIN”, and the transaction ends when the client 4500 etc. sends the SQL “COMMIT” “ROLLBACK”. In the case of Oracle, the transaction starts when the client 4500 etc. sends a valid SQL (there is no explicit SQL to declare the start of the transaction), and the client 4500 etc. This is when we sent the SQL "ROLLBACK". Also, when the server 4100 operates in the AUTO COMMIT mode, the SQL statement that also received the client 4500 equality can be interpreted as belonging to one independent transaction. Thus, it can be treated that the transaction is started before the execution of the SQL and the transaction is terminated after the execution of the SQL.
  • the transmission state of each server 4100 is set as follows.
  • the server operation state of the server management table 4201 is “active”, the transmission state of the server 4100 is set to “not transmitted”. If the server operation status in the server management table 4201 is "sync" or “active + syncj" and the query transfer process to the server 4100 has not started yet, the server 4100 is sent. The status is set to “pending”. That is, in the present embodiment, by storing the received query in the transmission queue 4203 as “pending”, difference information is accumulated. If the server operation status in the server management table 4201 is “sync” or “active + sync” and the query transfer process to the server 4100 has started, the transmission status of the server 4100 is changed. To “Release Hold”.
  • the query transmission processing unit 4205 monitors the transmission queue 4203, and extracts the queries that have been transmitted to the transmission queue 4203 from "old" to "unsent", The transmission is performed to the target server 4100, and the transmission status of the transmission queue 4203 is updated to “transmission completed”.
  • the validity determination unit 4206 receives a response to the query transmitted to each server 4100 by the query transmission processing unit 4205, and determines the validity of the response. This validity determination is based on the fact that the operation status of the server 4100 that transmitted the response is “active” or “active + sync”. In this case, one response is selected from one or more responses by a first validity determination method described later. On the other hand, when the operation status of the server 4100 that is the source of the response is “sync”, the validity of the response is determined by a second validity determination method described later.
  • the first validity determination is to determine the validity of query processing between one or more servers 100. Specifically, when there are three or more servers 4100, there is a method of deciding by majority vote and a method of judging received responses based on a predetermined rule. For example, if a response is returned from the client 4500 for a “reference” request that is “update succeeded” t, such a response is not possible if it is normal. ), Judge that this response is incorrect. Also, if the packet related to the response includes a data length field, the value of this data length field is compared with the actually received packet length, and if they are different, it is determined to be incorrect.
  • one Master server is determined in advance from among a plurality of servers 4100, and it is determined that the response from the server 100 is always correct.
  • the validity determination unit 4206 transmits a restart instruction to the server 4100 that has returned an invalid response as a result of the first validity determination, and transmits a restart instruction for the server 4100 from the server management table 4201 and the transmission queue 4203. Delete the entry. As a result, no query is transmitted to the server 4100, and the server 4100 is disconnected from the system.
  • the second validity determination will be described. In the second validity determination, as described later, it is determined whether or not the query transmitted to the server 4100 as the difference information during the synchronization processing has performed the same processing as the other normally operating servers 4100.
  • the response to be determined in the second validity determination is the transmission queue 4203 because the operation status of the server that returned the response was “sync” when the query related to the response was received from the client 4500. smell This is related to a query that has been "held” or "released”. Then, when the query is received from the client 4500, it has already been processed in another server 4100 whose operating state is "active" or "active + sync".
  • a response (processing result) to the query processed by another server 4100 is stored in the transmission queue 4203.
  • the validity determining unit 4206 determines validity by comparing the response received from the server 4100 with the response stored in the transmission queue 4203. If the validity determination unit 4206 determines that the data is not valid as a result of the second validity determination, the validity determination unit 4206 sends a restart instruction to the server 4100 to retry the synchronization process.
  • the response transmission processing unit 4207 is a response that is determined to be valid by the validity determination unit 4206, and the operation status of the transmission source server 4100 of the response is "active" or "active + sync". In this case, one of the responses is returned to the client 4500 or the like that has requested the processing, and the response is stored in the transmission queue 4203 as a transmission result. Also, the response transmission processing unit 4207 detects whether the response received from the server 4100 is related to the end of the transaction, and if it is related to the end of the transaction, the response Is deleted from the transaction management table 4202.
  • the response transmission processing unit 4207 deletes, from the transmission queue 4203, a query belonging to the completed transaction and whose transmission status of all the servers 4100 is “transmission completed”. In addition, when the query of “hold release” disappears from the transmission queue 4203, the response transmission processing unit 4207 changes the operation state of the server management table 4201 to “active” for the server 4100 that has been “hold release”. Update to As a result, the server 4100 is incorporated in the system. It should be noted that the timing of embedding into the system may be during execution of a query on the normally operating server 4100 or during ongoing transactions.
  • the synchronization processing control unit 4208 determines that the new server 4100 and the server that is operating normally in the system. And control the synchronization process.
  • the new server 4100 includes both a server that is newly added to the system and a server that is separated from the system and re-integrated into the system.
  • the synchronization processing control unit 4208 sets (1) the operation status of the new server 4100 to "sync" and the server management table 4201.
  • the server management table 4201 is updated for the selected server 4100, and if the transmission status of the transmission queue 4203 for the server 4100 is "not transmitted", it is updated to "pending”.
  • Synchronization Wait until the processing of the running query is completed at the processing server 100, and then at the synchronization processing server 4100, create a snapshot for the server 4100 when the processing of the running query is completed. Send instructions Is performed.
  • the synchronization processing control unit 4208 handles the above-described processes (1) to (4) as one process and performs exclusion control in order to maintain data consistency.
  • the synchronization processing control unit 4208 performs the processing of the above (1) to (4), and performs other processing on the server management table 4201 and the transmission queue 4203 accessed in each processing during the processing. (For example, the received query processing unit 4204)
  • the synchronization processing control unit 4208 sets the transmission state of the new server 4100 for the query to "pending".
  • the entry in the transmission queue 4203 is deleted when the transaction ends. Therefore, the query remaining in the transmission queue 4203 is a query for which the transaction has not been completed, and corresponds to the snapshot created by the synchronization server 4100 in response to the snapshot creation instruction of (4). Is not reflected.
  • the transmission state of this query is set to “pending” so that the query is held as difference information.
  • the synchronization processing control unit 4208 refers to the server management table 4201 and, when there is one server 4100 whose operating status is "active", operates the server 4100 Change the state to "active + sync". This means that the server 4100 is operated to process the processing request from the client 4500 in the same manner as in the normal case, and is operated for the synchronization processing of the new server 4100.
  • the operation status is "act If there are a plurality of servers 4100 that are “ive”, one server 100 is selected based on a predetermined selection rule, and the operation state of the server 4100 is changed to “sync”. This means that the server 4100 is operated only for the synchronization processing of the new server 4100 without performing the processing for the processing request from the client 4500.
  • the synchronization processing SANO 100 that has received the snapshot creation instruction from the mediation device 4200 starts creating a snapshot, and when the snapshot creation is completed, the mediation device 4200 Send a snapshot creation completion notification.
  • the synchronization processing control unit 4208 executes all the queries in the column of the synchronization processing server 4100 stored in the transmission queue 4203. Change the transmission status from "Hold” to "Release Hold”. As a result, the query transmission processing unit 4205 starts transmitting the query to the synchronization processing server 4100 as difference information.
  • the response transmission processing unit 4207 updates the operation state of the server management table 4201 for the synchronization processing server 4100 to “active”, A server 4100 for synchronization processing is incorporated into the system.
  • the synchronization server 4100 that has completed the creation of the snapshot transfers the snapshot to the new server 4100, and the new server 4100 attempts to restore the database 4101 from the snapshot. Then, when the restoration of the database 4101 is completed, the new server 4100 sends a difference information transfer request to the mediation device 4200.
  • the synchronization processing control unit 4208 changes the transmission status of all the queries in the column of the new server 4100 stored in the transmission queue 4203 from “pending” to the transmission status. Change to "Release Hold". Accordingly, the query transmission processing unit 4205 starts transmitting a query to the new server 4100 as difference information.
  • the response transmission processing unit 4207 updates the operation status of the server management table 4201 to “active” for the new server 4100, A new server 4100 is built into the system.
  • the client 4500 sends an update query (a request to update the database) or a reference query (a request to reference the contents of the database) to the multiplexed database system. Is issued.
  • the database consistency check device 4600 operates as a client of the multiplexed database system similarly to the client 4500, and determines whether the databases 4101 of the servers 4100 match each other. Issue a query to confirm This query is of a reference type, such as "SELECT * FROM test-table" for a given table test-table.
  • the database matching check device 4600 issues the check query periodically or in response to an instruction from an operator or the like.
  • the server management table 4201 is configured as shown in FIG. 137. It is also assumed that the transaction management table 4202 and the transmission queue 4203 are empty. It is assumed that a table test table exists in each of the servers 4100a and 4100b.
  • the reception query processing unit 4204 of the intermediary device 4200 receives the packet (step S41).
  • the reception query processing unit 4204 detects that the transaction has started, and registers the IP address and the transaction number of the client 4500a in the transaction management table 4202 (step S42).
  • FIG. 138 shows the transaction management table 4202 at this time. Then, referring to the server management table 4201, the query relating to this packet is sent to the transmission queue 4203 with the transmission status of the normally operating server 4100 (here, the servers 4100 a and 4100 b) set to “not transmitted”. .
  • the query transmission processing unit 4205 extracts a query whose transmission status is "not transmitted” from the transmission queue 4203, and transmits the packet to the corresponding server 4100.
  • the packet is transferred to the server 100a and the server 4100b (steps S43 and S44, respectively).
  • the transmission status of the transmission queue 4203 for each server 4100 is updated to “transmission completed”.
  • the validity determination unit 4206 includes a response packet notifying that the transaction has started normally. Although the response packet is received from the server 4100a (step S45), at this point all the response packets have not yet been collected!
  • the validity determination unit 4206 waits for a response packet from the server 4100b without doing anything. Then, when a response packet notifying that the transaction has started normally is received from the server 4100b (step S46), since all the response packets have been prepared, the validity determination unit 4206 determines that the response packets are By comparing each other, it is checked whether or not the server 4100 has a failure (step S47). In this case, since the two response packets are both packets indicating that the transaction has started normally, it is determined that there is no failure. Then, the response transmission processing unit 4207 returns one of the valid response packets to the client 4500a, and stores the response in the transmission queue 4203 (step S48).
  • the client 4500a sends a packet containing SQL (UPDATE) for updating the table test—table to 172.17.1.1 (step S49).
  • the reception query processing unit 4204 refers to the server management table 4201 and changes the transmission state of the normally operating server 4100 to “not transmitted” and enters the transmission queue 4203.
  • the query transmission processing unit 4205 extracts the query from the transmission queue 4203, transfers the packet to each server 4100 (steps S410 and S411, respectively), and updates the transmission status of the transmission queue 4203 to “transmission completed”.
  • the server 4100a transmits a response packet notifying that the UPDATE has been successfully completed successfully to the mediation device 4200, and the validity determination unit 4206 of the mediation device 4200 receives this response packet (step S412).
  • the validity determination unit 4206 waits without doing anything. Then, upon receiving from the server 4100b a response packet notifying that the UPDATE succeeded normally (step S413), since all the response buckets have been prepared, the validity determination unit 4206 compares the response packets with each other. Then, it is checked whether a failure has occurred in the server 4100 (step S414). In this case, since the two response packets are both packets indicating that the UPDATE was successful, it is determined that there is no failure. Then, the response transmission processing unit 4207 transfers one of the valid response packets to the client 4500a and stores the response in the transmission queue 4203 (Step S415).
  • the client 4500a transmits a packet containing SQL (COMMIT) that confirms the update to the table test-table (actually updates the database) to 172.17.1.1 (step S416).
  • the reception query processing unit 4204 refers to the server management table 4201 and changes the transmission state of the normally operating server 4100 to “not transmitted” to be put in the transmission queue 4203.
  • the query transmission processing unit 4205 extracts the query from the transmission queue 4203, transfers the packet to each server 4100 (steps S417 and S418, respectively), and updates the transmission state of the transmission queue 4203 to “transmission completed”.
  • the server 4100a transmits a packet notifying that the COMMIT has succeeded normally to the mediation device 4200, and the validity determination unit 4206 of the mediation device 4200 receives this response packet (step S419). At this point, all the response packets are not all prepared! /, So the validity determination unit 4206 waits without doing anything. Then, when a response packet notifying that the COMMIT has been successfully completed is received from the server 4100b (step S420), all the response packets are completed. The validity determination unit 4206 compares the response packets with each other. It is checked whether a failure has occurred in the server 4100 (step S421). In this case, since the two response packets are both packets indicating that the COM MIT was successful, it is determined that there is no failure.
  • the response transmission processing unit 4207 transfers one of the valid response packets to the client 4500a, and stores the response in the transmission queue 4203 (Step S422). Also, since the COMMIT has been completed normally, it is an indicator that the transaction has been completed, so the response transmission processing unit 4207 deletes the registration of this transaction from the transaction management table 4202 (step S423), and Queries whose transmission status is “transmission completed” for the server 4100 (here, three queries of “BEGIN”, “UPDATE”, and “COMMIT”) are deleted from the transmission queue 4203 (step S423). At this time, the transaction management table 4202 and the transmission queue 4203 are again in the initial state (that is, empty).
  • FIGS. 139 to 141 An operation when the server 4100b fails due to a failure or the like will be described with reference to FIGS. 139 to 141.
  • the databases 4101a and 4101b are completely the same, and the server management table 4201 is as shown in FIG. 137 described above. Further, it is assumed that the transaction management table 4202 and the transmission queue 4203 are empty.
  • Client 4500a included transaction start SQL (BEGIN) addressed to 172.17.1.1
  • the reception query processing unit 4204 of the mediation device 4200 receives the packet (step S430).
  • the reception query processing unit 4204 detects that the transaction has started, and registers the IP address and the transaction number of the client 4500a in the transaction management table 4202 (step S431).
  • FIG. 140 shows the transaction management table 4202 at this time. Then, referring to the server management table 4201, the query relating to this packet is placed in the transmission queue 4203 with the transmission status of the normally operating server 4100 set to “not transmitted”.
  • the query transmission processing unit 4205 extracts a query whose transmission status is "not transmitted” from the transmission queue 4203, and transfers the packet to the corresponding server 4100 (steps S432 and S433, respectively). Next, the transmission status of the transmission queue 4203 is updated to “transmission completed”.
  • the legitimacy determination unit 4206 of the intermediary device 4200 receives a response packet notifying that the transaction has started normally from the server 4100a (step S434), but at this point all response packets are still collected. Therefore, because there is no response packet from the server 4100b (in this case, no response packet from the server 4100b), the processing waits for a response packet from the server 4100b without doing anything.
  • step S435 when a response packet notifying that the transaction has started normally is received from the server 4100b (step S435), since all the response packets have been prepared, the validity determination unit 4206 compares the response packets with each other. By comparison, it is checked whether or not the server 4100 has a failure (step S436). In this case, since the two response packets both indicate that the transaction has started normally, it is determined that there is no failure. Then, the response transmission processing unit 4207 transfers one of the valid response packets to the client 4500a, and stores the response in the transmission queue 4203 (step S434).
  • step S435 it is assumed that after returning the response packet in step S435, the server 4100b goes down due to a failure such as a failure (step S438).
  • the client 4500a transmits a packet containing SQL (UPDATE) for updating the table test-table to 172.17.1.1 (step S439).
  • the reception query processing unit 4204 refers to the server management table 4201 and sets the transmission state of the normally operating server 4100 to “not transmitted” to be put in the transmission queue 4203.
  • the mediation device 4200 is Since the user does not know that the server is down, the information that the server 4100b is operating normally remains stored in the server management table 4201. Therefore, the reception query processing unit 4204 stores the reception query in the transmission queue 4203 with the transmission state set to “not transmitted” even in the column of the server 4100b as well as the column of the server 4100a.
  • the query transmission processing unit 4205 extracts a query whose transmission status is “not transmitted” from the transmission queue 4203 and transfers the packet to each of the servers 4100a and 4100b (steps S440 and S441, respectively). Next, the query transmission processing unit 4205 updates the transmission status of the transmission queue 4203 to “transmission completed”.
  • the server 4100a transmits a response packet notifying that the UPDATE has been successfully completed successfully to the mediation device 4200, and the validity determination unit 4206 of the mediation device 4200 receives this response packet (step S442). Since they are not aligned, the validity determination unit 4206 does nothing and waits. However, since Sano 100b is down, the response packet from server 4100b does not reach validity determination section 4206 no matter how long.
  • the validity determination unit 4206 times out and detects that the server 4100b is down. Then, the validity determination unit 4206 deletes the entry of the server 4100b from the server management table 4201 (Step S443).
  • FIG. 141 shows the server management table 4201 at this time. Also, the transmission status column for the server 4100 b is deleted from the transmission queue 4203.
  • FIG. 142 shows the transmission queue 4 203 at this time.
  • the validity determination unit 4206 sends a restart instruction to the server 4100b from which the system power is also disconnected (step S444). However, here, since the server 4 100b is down, the processing for the restart instruction is not performed.
  • the response transmission processing unit 4207 transfers the response packet to the client 4500a and stores the response in the transmission queue 4203 (step S445). It should be noted here that the client 450 Oa does not know whether the server 4100b has failed and can receive the service from the virtual Sano 4800 as before.
  • the client 4500a transmits a packet containing SQL (CO MMIT) for confirming the update to the table test—table to 172.17.1.1 (step S446).
  • the reception query processing unit 4204 refers to the server management table 4201 to operate normally! /, And sets the transmission status to “not transmitted” for the server 4100, and enters the transmission queue 4203.
  • only the server 4100a stores the query in the transmission queue 4203 with the transmission status “not transmitted”.
  • the query transmission processing unit 4205 extracts the query from the transmission queue 4203, and transfers the packet to only the corresponding server, in this case, the server 4100a (step S447).
  • the transmission status of the transmission queue 4203 is updated to “transmission completed”.
  • the server 4100a transmits a response packet notifying that the COMMIT has succeeded normally, and the validity determination unit 4206 of the mediation device 4200 receives this response packet (step S448).
  • the validity determination unit 4206 determines that the response packet is valid, and the response transmission processing unit 4207 forwards the response packet to the client 4500a and sends the response packet to the client 4500a. Is stored in the transmission queue 4203 (step S449).
  • the response transmission processing unit 4207 deletes the registration of this transaction from the transaction management table 4202 (step S450) and For the server 4100, the queries whose transmission status is “transmission completed” (here, three queries of “BEGIN”, “UPDATE”, and “COMMIT”) are deleted from the transmission queue 4203 (step S450). At this time, the transaction management table 4202 and the transmission queue 4203 are again in the initial state (that is, empty).
  • step S447 the database 4101a of the server 4100a reflects the UPDATE from the client 4500a (step S439), whereas the database 4101b of the server 4100b reflects the UPDATE from the client 4500a. It should be noted that (Step S439) is not reflected, that is, the database 4101a and the database 4101b are out of synchronization.
  • the client 4500a sends a query (BE GIN) to start the transaction T1 to the mediation device 4200 (step S4101), while the client 4500b starts a query (BEGIN) to start the transaction T2. Is transmitted to the mediation device 4200 (step S4 102).
  • the mediation device 4200 transfers each query to the normally operating servers 4100a and 410 Ob (steps S4103 to S4106). Then, the validity of each response (steps S4107 to S4110) of each Sano 4100a and 4100b is checked (not shown), and one valid response is transferred to the requesting client 4500a or 4500b. (Steps S4111 to S4112).
  • the clients 4500a and 4500b that have received the response to the BEGIN from the mediation device 4200 transmit the next query belonging to each transaction to the mediation device 4200.
  • the client 4500a transmits the UPDATE query of the transaction T1 to the mediation device 4200 (step S4113)
  • the client 4500b transmits the UPDATE query of the transaction T2 to the mediation device 4200 (step S4114).
  • the intermediary device 4200 that has received the queries from the clients 4500a and 4500b transfers the queries to Sano 4100a and 4100b that are operating normally (steps S4115 to S4118).
  • step S4121 the row to be updated in the test-table by the UPDATE query of transaction T2 is locked until transaction T2 is COMMIT. Since the locked row is to be updated in the UPDATE query of transaction T1, the processing of the query is suspended until the lock is released (step S4122).
  • step S4119 the response to the UPDATE query of transaction T1 from server 4100a (step S4119) has arrived at mediation device 4200 before the response to the UPDATE query of transaction T2 from server 4100b (step S4121).
  • the mediation device 4200 has received a response to the UPDATE query of the transaction T1 from the one server 4100a (step S4119), but has not received a response from the other server 4100b, and therefore waits for the response (step S4123). ). This is because, as described above, the mediation device 4200 compares the responses from the servers 4100a and 4100b with each other to determine the validity. Similarly, the mediation apparatus 4200 receives a response to the U PDATE query of the transaction T2 from the one server 4100b (step S4121), but waits for the response because the response from the other server 4100a has not been received (step S4121). Step S4124).
  • step S4122 since the processing of the UPDATE query of transaction T1 is waiting for the lock release in the server 4100b (step S4122), the response wait (step S4123) for the query in the intermediary device 4200 times out (step S4125). ).
  • the mediation apparatus 4200 determines that the server 4100b has failed, cancels the response waiting in step S4124, and disconnects the server 4100b from the system power (step S4126). Specifically, the entry of the server 4100b is deleted from the server management table 4201, and the transmission status column of the server 4100b is deleted from the transmission queue 4203. Then, as shown in FIG. 144, the mediation device 4200 sends a restart instruction to the server 4100b disconnected from the system (step S4127), and sends a response to the client 4500b. Return to a (step S4128).
  • step S4129 Upon receiving the restart instruction from the mediation device 4200, the server 4100b starts restarting itself (step S4129).
  • the client 4500a that has received the response to the UPDATE query of the transaction T1! / Transmits a query (COMMIT) for confirming the update to the mediation device 4200 (step S4130).
  • the intermediary device 4200 Upon receiving the query from the client 4500a, the intermediary device 4200 refers to the server management table 4201 and transfers the query to the normally operating server 4100a (step S4131).
  • the lock is released by processing the COMMIT query of the transaction T1, and the processing of the transaction T2 can be resumed (step S4132).
  • the server 4100a returns a response to the COMMIT query of the transaction T1 to the mediation device 4200 (step S4133), and the mediation device 4200 transfers the response to the client 4500a (step S4134).
  • the server 4100a returns a response to the UPDATE query of the transaction T2 to the mediation device 4200 (step S4135), and the mediation device 4200 transfers the response to the client 4500b (step S4136).
  • the client 4500b that has received the response to the UPDATE query of transaction T2! / Sends a query (COMMIT) for confirming the update to the mediation device 4200 (step S4137).
  • the mediation device 4200 Upon receiving the query from the client 4500b, the mediation device 4200 refers to the server management table 4201 and transfers the query to the normally operating server 4100a (step S4138).
  • the server 4100a processes the query and returns a response to the mediation device 4200 (step S4139), and the mediation device 4200 transfers the response to the client 4500b (step S4140).
  • step S4141 the server 4100b transmits a database synchronization request to the mediation device 4200 (Step S4142).
  • the mediation device 4200 performs a process of synchronizing the database 4101a of the server 4100a and the database 4101b of the server 410 Ob in cooperation with the server 4100a that is operating normally (step S4143). The details of this synchronization processing will be described later.
  • the mediation device 4200 waits for the synchronization process to be completed.
  • the server 4100b is incorporated into the system again (step S4144). The details of the processing for incorporating into the system will be described later together with the details of the synchronization processing in step S4143.
  • the mediation device 4200 when the client 4500a sends a query (BE GIN) for starting the transaction T3 to the mediation device 4200 (step S4201), the mediation device 4200 operates normally with reference to the server management table 4201. The data is transferred to the servers 4100a and 4100b (steps S4202 and S4203). When the response from each Sano 4100a and 4100b is received (step S4204, S4205), one of the valid responses is transferred to the client 4500a. Is sent (step S4206).
  • the client 4500a transmits an update query (UPDATE) of the transaction T3 to the mediation device 4200 (step S4207).
  • the client 4500b transmits a query (BEGIN) for starting the transaction T4 to the mediation device 4200 (step S4208).
  • the mediation apparatus 4200 transfers the UPDATE query of the transaction T3 to the normally operating servers 4100a and 4100b (steps S4209 and S4210), and then transmits the BEGIN query of the transaction T4 to the normally operating server 4100a. And 4100b (steps S4211, S4212). Then, when receiving a response to the UPDATE query of the transaction T3 from each of the Sano 4100a and 4100b (steps S4213 and S4214), the intermediary device 4200 transfers one of the valid responses to the client 4500a (step S4215). When receiving a response to the transaction T4 BEGIN query from each of the servers 4100a and 4100b (steps S4216 and S4217), the server transmits one of the valid responses to the client 4500b (step S4218).
  • the client 4500a transmits a query (COMMIT) for confirming the transaction T3 to the intermediary device 4200 (step S4219).
  • the client 4500b transmits a reference query (SELECT) of the transaction T4 to the mediation device 4200 (step S4220).
  • the mediation device 4200 transfers the COMMIT query of the transaction T3 to the servers 4100a and 4100b that are operating normally (steps S4221, S4222), and the server 4100a that operates the SELECT query of the transaction T4 is operating normally. And 4100b (steps S4223, S4224).
  • the COMMIT query of transaction T3 is processed before the SELECT query of transaction T4 (steps S4225, S4226), and on the other server 4100b, the SELECT query of transaction T4 is processed by transaction T3. It is assumed that the processing has been performed before the COMMIT query of (steps S4227 and S4228). Accordingly, it is assumed that the response of the SELECT query of transaction T4 is different from the response from server 4100a (step S4226) and the response from Sano 4100b and others (step S4227).
  • the mediation device 4200 has the ability to respond to the SELECT query of transaction T4. Since there is a mismatch between the data 100a and 4100b, either server 4100a or 4100b is selected, and the response from the selected server 4100a or 4100b is justified (step S4229).
  • a method of selecting the server 4100 for example, a master server is determined in advance, a method of selecting this master server, a method of selecting a server that has returned a response first, and a selection server sequentially by round robin There is a method of selecting based on the processing method, the method of selecting at random, the processing capacity of each server, the processing load, and so on.
  • the server 4100a is selected as the master server and the server 4100a is selected as the server that has returned a valid response.
  • the mediation device 4200 also disconnects the system power from the server 4100b that has returned an invalid response (step S4230). Specifically, the entry of the server 4100b is deleted from the server management table 4201, and the transmission status column of the server 4100b is deleted from the transmission queue 4203. Then, as shown in FIG. 146, a restart instruction is transmitted to the server 4100b (step S4231).
  • step S4232 Upon receiving the restart instruction from the mediation device 4200, the server 4100b starts restarting itself (step S4232).
  • the mediation device 4200 forwards the response to the COMMIT query of transaction T3 and the response to the SELECT query of transaction T4 received from the selected server 4100a to the requesting clients 4500a and 4500b, respectively (steps S4233, S423 4) After that, the query of each client 4500a, 4500b is processed by Sano 4100a which is operating normally.
  • the mediation device 4200 transfers the query to the server 4100a that is operating normally (step S4236). Then, when receiving a response to the query from the server 4100a (step S4237), the intermediary device 4200 returns this response to the client 4500b that has requested (step S4238).
  • Step S4239 the restart of the server 4100b from which the system power has been disconnected has been completed.
  • the server 4100b transmits a database synchronization request to the mediation device 4200 (Step S4240).
  • the mediation device 4200 performs a process of synchronizing the database 4101a of the server 4100a and the database 4101b of the server 410 Ob in cooperation with the server 4100a that is operating normally (step S4241). This sync Details of the conversion process will be described later.
  • the mediation apparatus 4200 re-embeds the server 4100b into the system (step S4242). The details of the processing for incorporating into the system will be described later together with the details of the synchronization processing in step S4241.
  • the inconsistency of the database 4101 can be resolved by performing the same processing as the sequence described with reference to FIGS. 145 and 146.
  • a snapshot of the database 4101 is created on the server 4100 that is operating normally at the start of the synchronization processing, and this snapshot is transferred to the new server 4100 to be synchronized. Then, the new server 4100 restores the database 4101 from the snapshot. Further, the query received from the client 4500 during this process is stored as difference information in the mediation device 4200. The accumulation of this difference information uses the transmission queue 4203. When the new server 4100 completes the restoration of the database 4101 from the snapshot, the difference information is transmitted from the mediation device 4200. The information is obtained and the difference information is processed.
  • the server 4100 transmits a database synchronization request to the mediation device 4200. Therefore, the synchronization process is performed in response to a restart instruction from the mediation device 4200. Not limited to reboot. That is, the process is also performed when the server 4100 is disconnected from the system as a failure and then re-integrated into the system. It is also implemented when adding servers that make up the system.
  • the database 4101b is out of synchronization with the database 4101a, that is, not in the same state.
  • the database 4101b may retain the data immediately before the restart or the data immediately before the occurrence of the failure, or may not have any data in the case of a completely new U or a server.
  • old data is deleted, and the database 4101b enters the system as if it does not hold any data. That is, there is no need to keep old data.
  • server management table 4201 is as shown in FIG. 151 because only the server 4100a is operating normally. It is also assumed that the transaction management table 4202 is empty. Further, the transmission queue 4203 is empty, and the transmission state is stored only for the normally operating server 4100a.
  • client 4500a initiates a transaction start SQL addressed to 172.17.1.1.
  • the reception query processing unit 4204 of the intermediary device 4200 receives the packet (step S4301).
  • the reception query processing unit 4204 detects that the transaction has started, and registers the IP address and the transaction number of the client 4500a in the transaction management table 4202 (step S4302).
  • FIG. 152 shows the transaction management table 4202 at this time.
  • the reception query processing unit 4204 refers to the server management table 4201 and sets the transmission status to “not transmitted” for the server 4100a that is operating normally to receive the data.
  • the query is put in the transmission queue 4203 (step S4303).
  • the query transmission processing unit 4205 extracts the query from the transmission queue 4203, transfers the query to the corresponding server 4100a (step S4304), and updates the transmission status of the transmission queue 4203 to “transmission completed” (step S4305).
  • the validity response unit 206 of the mediation device 4200 receives a response packet notifying that the transaction has started normally from the server 4100a (step S4306), here, since there is only one normally operating server 4100, the The response packet is determined to be valid, and the response transmission processing unit 4207 transfers the response packet to the client 4500a (step S4307) and stores the response in the transmission queue 4203 (step S4308).
  • FIG. 153 shows the transmission queue 4203 at this time.
  • the reception query processing unit 4204 of the mediation apparatus 4200 receives the packet (Ste S4309).
  • the reception query processing unit 4204 refers to the server management table 4201 and sets the transmission state of the normally operating server 4100a to “not transmitted” to put the reception query in the transmission queue 4203 (step S4310).
  • FIG. 154 shows the transmission queue 4203 at this time.
  • step S4311 the database control unit 4102b of the server 1002b transmits a database synchronization request (a request for incorporating into the system) to the mediation device 4200 (step S4312).
  • the synchronization processing control unit 4208 Upon receiving the database synchronization request, the synchronization processing control unit 4208 refers to the server management table 4201, and selects a server 4100 for synchronization. Here, since only one server 100 is operating normally, the server 4100a is selected. Then, the operation status of the server 4100a in the server management table 4201 is updated to “active + syncj” (step S4313), and the transmission status of the server 4100a in the transmission queue 4203 becomes “not transmitted”. Is updated to “pending” (step S4314). Also, after confirming that there is no query being executed on the synchronization server 4100a, the synchronization processing control unit 4208 sets the operation status to "sync" for the requesting server 4100b.
  • a column for the server 4100b is added to the transmission status column of the transmission queue 4203 (step S4316).
  • the transmission status of the server 4100b is all Set to "Hold”.
  • FIGS. 155 and 156 show the server management table 4201 and the transmission queue 4203 at this time.
  • the queries received from each client 4500 are put in the transmission queue 4203 with the transmission status of both the servers 4100a and 4100b set to “pending”.
  • the synchronization processing control unit 4208 handles the processing of steps S4313 to S4316 as one processing, and performs the other IJ control. That is, during the processing of steps S4313 to S4316, the server management table 4201 and the transmission queue 4203 accessed in each step are interrupted from accessing from other function blocks (for example, the reception query processing unit 4204). .
  • the synchronization processing control unit 4208 sends a snapshot creation instruction to the server 4100a (step S4317).
  • the database control unit 4102a of the server 4100a Upon receiving the snapshot creation instruction, the database control unit 4102a of the server 4100a creates a snapshot of the database 4101a (step S4318).
  • this snapshot is backup data of the entire database and information for restoring the database that was COMMIT when the snapshot creation instruction was received, and the snapshot is received even if an update query has already been received. It should be noted that at the time of the shot creation instruction, the update will be reflected unless the COM MMIT has been performed yet.
  • the reception query processing unit 4204 upon receiving the query from the client 4500, puts the transmission status of both the servers 4100a and 4100b to "pending" and puts it in the transmission queue 4203.
  • the reception query processing unit 4204 of the intermediary device 4200 receives the packet (step S4319).
  • the reception query processing unit 4204 detects that the transaction has started, and registers the IP address and the transaction number of the client 4500b in the transaction management table 4202 (step S4320).
  • FIG. 157 shows the transaction management table 4202 at this time.
  • the reception query processing unit 4204 sets the transmission state of both the servers 4100a and 4100b to “pending” and places the reception query in the transmission queue 4203 (step S4321).
  • FIG. 158 shows the transmission queue 4203 at this time.
  • Step S4322 the fact is notified to the mediation apparatus 4200 (Step S4323), and the transfer of the snapshot to the server 4100b is started (Step S4324).
  • Server 4 The database control unit 4102b of 100b restores the database from the snapshot received from the server 4100a (Step S4325).
  • the synchronization processing control unit 4208 of the intermediary device 4200 Upon receiving the snapshot completion notification from the server 4100a, the synchronization processing control unit 4208 of the intermediary device 4200 "releases the hold" of the entry in which the transmission status of the server 4100a in the transmission queue 4203 is "pending". (Step S4326).
  • the transmission queue 4203 at this time is shown in FIG.
  • the query received from each client 4500 enters the transmission queue 4203 with the transmission status of the server 4100a set to “hold release” and the transmission status of the server 4100b set to “hold”.
  • the query transmission processing unit 4205 transmits, to the server 4100a, the queries whose transmission status has been changed to “hold release” in order from the oldest one.
  • the query transmission processing unit 4205 transmits the UPDATE query whose transaction ID is 3 shown in FIG. 159 to the server 4100a (step S4327), and updates the transmission state to “transmission completed” (step S4328).
  • the validity determination unit 4206 of the mediation device 4200 receives from the server 4100a a response packet notifying that the UPDATE has been processed normally (step S4329), here, since there is only one normally operating server 4100, the Judge that the response packet is valid.
  • the response transmission processing unit 4207 transfers the response packet to the client 4500a (step S4330), and stores the response in the transmission queue 4203 (step S4331).
  • the transaction ID BEGIN query shown in FIG. 159 is also processed (steps S4332 to S4336).
  • FIG. 160 shows the transmission queue 4203 at this time.
  • the server 4100a all the queries whose transmission status was “hold release” in the transmission queue 4203 have been processed, so the response transmission processing unit 4207 determines whether or not the server 4100a in the server management table 4201 The operation status is updated to “active” (step S4 337).
  • the server 4100a is incorporated into the system.
  • FIG. 161 shows the server management table 4201 at this time. Thereafter, the query received from each client 4500 enters the transmission queue 4203 with the transmission status of the server 4100a set to “not transmitted” and the transmission status of the server 4100b set to “hold”.
  • the reception query processing unit 4204 of the intermediary device 4200 receives the packet (step S4338).
  • the reception query processing unit 4204 refers to the server management table 4201
  • the transmission status of the normally operating server 4100a is set to “not transmitted”, and the transmission status of the server 4100b being synchronized is set to “pending”, and the reception query is sent to the transmission queue 4 203 (step S4339).
  • the transmission queue 4203 at this time is shown in Figure 162.
  • the query transmission processing unit 4205 extracts the query from the transmission queue 4203, transfers the query to the server 4100a whose transmission status is "not transmitted” (step S4340), and transmits the transmission status of the server 410 Oa of the transmission queue 4203 to "transmission". "Completed” (step S4341).
  • the validity determination unit 4206 of the mediation device 4200 determines that the normally operating Since the number is only one, the response packet is determined to be valid. Then, the response transmission processing unit 4207 transfers the response packet to the client 4500b (step S4343), and stores the response in the transmission queue 4203 (step S4344).
  • the mediation device 4200 processes the packet in the same manner as in the above steps S4338 to S344 (steps S4345 to S4351). ).
  • the transmission queue 4203 is as shown in FIG.
  • the response transmission processing unit 4207 deletes the registration of this transaction from the transaction management table 4202 (step S4352).
  • the transaction whose transaction ID is 3 has been completed.Since the query related to the transaction has not been sent to the synchronized server 4100b, the query is not deleted from the send queue 4203. Not performed.
  • step S4353 the server 4100b transmits a difference information transfer request to the mediation device 4200 (Step S4354).
  • the synchronization processing control unit 4208 Upon receiving the difference information transfer request from the server 4100b, the synchronization processing control unit 4208 sets the transmission status of the transmission queue 4203 to "pending" for the requesting server 4100b! The object is updated to “Release Hold” (step S4355). Thereafter, the query received from each client 4500 is set in the transmission queue 4203 with the transmission state of the server 4100a set to “not transmitted” and the transmission state of the server 4100b set to “released”. At this time The transmission queue 4203 is shown in FIG. As a result, the query transmission processing unit 4205 transmits the query whose transmission state has been changed to “hold release” as difference information to the server 4100b in order of age and power.
  • the query transmission processing unit 4205 extracts the BEGIN query from the transmission queue 4203 and transfers it to the server 4100b (step S4356), and updates the transmission state of the transmission queue 4203 to "transmission completed”. (Step S4357).
  • FIG. 165 shows the transmission queue 4203 at this time.
  • the validity determination unit 4206 of the mediation device 4200 receives the response and the response stored in the transmission queue 4203. Is compared (step S4359). If they do not match, the entry for the server 4100b is deleted from the server management table 4201 and the transmission queue 4203, and then a restart instruction is sent to the server 4100b. As a result, the processing from step S4311 is retried.
  • the frequency of the retry of the synchronization process is considered to be low, it may theoretically continue indefinitely. Therefore, it is preferable to store the number of retries in a predetermined storage device and stop the synchronization process when the number of retries becomes equal to or more than the predetermined number. Further, when the synchronization process is stopped, it is preferable to output a message indicating that the synchronization process has been stopped to a predetermined output unit. For example, there is a method of outputting to a log file. Then, it is preferable to try the synchronization process again when the load on the server 4100 or the mediation device 4200 that is operating normally is low.
  • the reception query processing unit 4204 When a query is received from the client 4500 after the transfer of the difference information to the server 4100b has been started and before being incorporated into the system of the server 4100b, the reception query processing unit 4204 The server 4100b enters the query into the transmission queue 4203 in the transmission state “not transmitted” and the server 4100b in the transmission state “released hold”.
  • the client 4500b sends an INSERT query to the intermediary device 4200 (step S4360)
  • ⁇ the reception time process of the mediation device 4200 ⁇ 4204 causes the Sano 4100a to send the message "not sent”.
  • the query is put into the transmission queue 4203 in the transmission state "release of hold” (step S4361).
  • the query transmission processing unit 4205 retrieves the query from the transmission queue 4203 and transmits it to the server 4100a (step S 4362), the transmission status of the server 4100a is updated to “transmission completed” (step S4363).
  • the validity determination unit 4206 of the mediation device 4200 receives a response packet notifying that the INSERT has been processed normally from the server 4100a (step S4364), here, since there is only one normally operating server 4100, the The response packet is determined to be valid.
  • the response transmission processing unit 4207 transfers the response packet to the client 4500b (step S4365) and stores the response in the transmission queue 4203 (step S4366).
  • FIG. 166 shows the transmission queue 4203 at this time.
  • the response transmission processing unit 4207 assigns the query to the transaction. Delete all queries from the transmission queue 4203.
  • the UPDATE with a transaction ID of 3 the BEGIN with a transaction ID of 4
  • the UPDATE with a transaction ID of 4 are sequentially processed according to the above-described procedure.
  • the BEGIN, UPDATE, and COMMIT query with the transaction ID of No. 3 is deleted from the transmission queue 4203.
  • the query transmission processing unit 4205 extracts the INSERT query from the transmission queue 4203 and transfers it to the server 4100b (step S4390), and updates the transmission status of the transmission queue 4203 to "transmission completed”. (Step S4391).
  • the validity determination unit 4206 of the mediation device 4200 compares the response with the response stored in the transmission queue 4203. Yes (step S4393). If they do not match, the entry for the server 410 Ob is deleted from the server management table 4201 and the transmission queue 4203, and then a restart instruction is sent to the server 4100b.
  • step S4311 and subsequent steps The descending process is retried.
  • FIG. 167 shows the transmission queue at this time.
  • step S4394 shows the server management table 4201 at this time.
  • the processing in step S4394 corresponds to the processing in steps S4144 and S4242 described above.
  • the server from which the system power is disconnected restores the database based on the snapshot and the difference information.
  • the processing result of the difference information in the server and the normal processing incorporated in the system are performed. If the processing result on the server does not match, the synchronization processing is retried. As a result, it is possible to prevent the database of each server from being in an asynchronous state due to the difference in the processing order of the processing requests among the servers.
  • the processing requests from the force database match detection device 4600 described above may be processed in the same manner. Good. This is because the database consistency checker 4600 is one of the client computers from the viewpoint of the multiplex database system.
  • the database matching check device 4600 transmits a reference query for database matching checking to the intermediary device 4200 periodically or as needed. Accordingly, even if data inconsistency occurs between the databases 4101 for some reason, the inconsistency between the databases 4101 is detected by the query and the synchronization processing is executed. As a result, synchronization between the databases 4101 can be more reliably achieved.
  • a multiplexed database system will be described with reference to the drawings.
  • This embodiment is different from the nineteenth embodiment in that the virtual server 4800 includes three servers 4100.
  • the configuration and operation of each device are the same as in the nineteenth embodiment.
  • the synchronization processing when the server 4100 is incorporated in the system (step S4143 in FIG. 144 and step S4241 in FIG. 146 in the nineteenth embodiment) ) Is different, and the other operations are the same.
  • this synchronization processing will be described in detail.
  • FIG. 174 shows the server management table 4201 in the initial state. It is also assumed that the transaction management table 4202 is empty. The transmission queue 4203 is empty and has a structure as shown in FIG.
  • client 4500a initiates a transaction to 172.17.1.1
  • the reception query processing unit 4204 of the mediation device 4200 receives the packet (step S4401).
  • the reception query processing unit 4204 detects that the transaction has started, and registers the IP address and the transaction number of the client 4500a in the transaction management table 4202 (step S4402).
  • the reception query processing unit 4204 refers to the server management table 4201 and sets the transmission state of the servers 4100a and 4100b that are operating normally to “not transmitted” to put the reception query in the transmission queue 4203 (step S4403).
  • the query transmission processing unit 4205 extracts the query from the transmission queue 4203, transfers the corresponding queries 4100a and 4100b (steps S4404 and S4405), and updates the transmission status of the transmission queue 4203 to “transmission completed” (step S4404). S4406).
  • the validity determination unit 4206 of the mediation device 4200 receives a response packet notifying that the transaction has started normally from Sano 4100a and 4100b (steps S4407 and S4408), the response from each server 4100a and 4100b Determine the validity of the packet. Then, the response transmission processing unit 4207 forwards one of the valid response packets to the client 4500a. In the meantime (step S4409), the response is stored in the transmission queue 4203 (step S4410).
  • FIG. 176 shows the transmission queue 4203 at this time.
  • the reception query processing unit 4204 of the intermediary device 4200 receives the packet ( Step S4411).
  • the reception query processing unit 4204 refers to the server management table 4201 and sets the transmission status to “not transmitted” for the servers 4100a and 4100b that are operating normally, and places the reception query in the transmission queue 4203 (step S4412).
  • FIG. 177 shows the transmission queue 4203 at this time.
  • step S4413 the database control unit 4102c of the server 1002c transmits a database synchronization request (a request for incorporating into the system) to the intermediary device 4200 (step S4414).
  • the synchronization processing control unit 4208 Upon receiving the database synchronization request, the synchronization processing control unit 4208 refers to the server management table 4201 and selects one server 4100 for synchronization. Here, since there are two normally operating servers 4100, one of the servers is selected according to a predetermined rule. In the present embodiment, it is assumed that the server 4100b has been selected as the synchronization server.
  • the synchronization processing control unit 4208 updates the operation status of the server 4100b in the server management table 4201 to “sync” (step S4415), and the transmission status of the server 4100b in the transmission queue 4203 is “not transmitted”. Update the entry to "pending" (step S4 416).
  • the synchronization processing control unit 4208 sets the operation status of the requesting server 4100c to ⁇ sync '' in the server management table 4201.
  • a column for the server 4100c is added to the transmission status column of the transmission queue 4203 (step S4418).
  • all the transmission states of the server 4100c are set to “pending”.
  • FIGS. 178 and 179 show the server management table 4201 and the transmission queue 4203 at this time. Note that the synchronization processing control unit 4208 handles the processing of steps S4415 to S4418 as one processing and performs exclusive control.
  • step S4415 to S4418 access from other functional blocks (for example, the reception query processing unit 4204, etc.) to the server management table 4201 and the transmission queue 4203 accessed in each step is interrupted.
  • the synchronization processing control unit 4208 sends a snapshot creation instruction to the server 4100b (step S4419).
  • the database control unit 4102b of the server 410 Ob that has received the snapshot creation instruction creates a snapshot of the database 4101b (step S4420).
  • the present embodiment is significantly different from the nineteenth embodiment in that, in the nineteenth embodiment, the query from client 4500 cannot be processed during snapshot creation. It is possible. That is, when the synchronization processing control unit 4208 completes the exclusion processing of the above steps S4415 to S4418, as shown in FIG. 170, the query transmission processing unit 4205 sends a query whose transmission status is “untransmitted” from the transmission queue 4203. It is taken out and transferred to the corresponding server 4100a (step S4421), and the transmission status of the transmission queue 4203 is updated to “transmission completed” (step S4422).
  • the reception query processing unit 4204 of the mediation device 4200 determines that only one server 4100 is operating normally in this case.
  • the response transmission processing unit 4207 determines that the response packet is valid, transfers the response packet to the client 4500a (step S4424), and stores the response in the transmission queue 4203 (step S4425).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

　新規のサーバ１１００から組み込み要求があると、正常稼働中のサーバ１１００がスナップショットを作成し、新規のサーバ１１００に転送して該スナップショットからデータベース１１０１を復元する。仲介装置１２００は、スナップショット作成後からクライアントからのクエリを差分情報として蓄積して、新規のサーバ１１００におけるスナップショットからのデータベースの復元後に差分情報を転送する。  

Description

明 細 書
多重化データベースシステム 技術分野
[0001] 本発明は、障害などによりサービスが停止することなく常時連続したサービス提供 が要求される多重化データベースシステムに関し、特に該システムを構成するデータ ベースサーバに障害が発生した場合の復旧処理や新規のデータベースサーバの組 み込み処理を、サービス提供を継続したまま実施するための同期化技術に関する。 また、本発明は、複数のデータベースサーバを並列動作させた多重化データベース システムに関し、特に各データベースサーバ間の同期技術に関する。
[0002] 本願は、 2004年 4月 1日に出願された特願 2004— 109106号に対し優先権を主 張し、その内容をここに援用する。
本願は、 2004年 5月 11日に出願された特願 2004— 141174号に対し優先権を 主張し、その内容をここに援用する。
本願は、 2004年 8月 17日に出願された特願 2004— 237438号に対し優先権を 主張し、その内容をここに援用する。
本願は、 2004年 12月 21日に出願された特願 2004— 369841号に対し優先権を 主張し、その内容をここに援用する。
背景技術
[0003] 従来のデータベース同期化技術としては、例えば特許文献 1に記載されているもの が知られている。この従来技術では、それぞれデータベースを内蔵する複数のサー バがネットワーク等を介して相互接続されている。図 36に示すように、特許文献 1に 記載されている実施例では、 3個のサーノ 10, 20, 30を含み、それぞれネットワーク 40を介して相互接続されている。各サーバ 10, 20及び 30は、それぞれデータ更新 帘 U御咅 21, 31と、レプリケーシヨン帘||御咅 12, 22, 32と、データベース 13, 23, 33及び差分ファイル 14, 24, 34を含んでいる。 [0004] サーバ 10のデータ更新制御部 11は、データベースの更新処理を行う。レプリケー シヨン制御部 12は、差分ファイル 14によりデータベース 13の同期化処理を行う。デ ータベース 13は、データを一括管理する。差分ファイル 14は、データベース 13の差 分情報を格納する。また、サーバ 20及び 30のデータ更新制御部 21, 31、レプリケー シヨン制御部 22, 32、データベース 23, 33及び差分ファイル 24, 34は、それぞれ上 述したデータ更新制御部 11,レプリケーシヨン制御部 12,データベース 13及び差分 ファイル 14と同様の機能を有する。
[0005] サーバ 10にデータ更新イベントが発生した場合、サーバ 10のデータ更新制御部 1 1は、自データベース 13の内容を更新した後、サーバ 20及びサーバ 30に対してデ ータ更新通知を送信する。サーバ 20及びサーバ 30のデータ更新制御部 21, 31は、 自データベース 23, 33の内容を更新する。その後、サーバ 20及び 30は、それぞれ サーバ 10に対してデータ更新完了通知を送信する。サーバ 10は、サーバ 20及びサ ーバ 30からのデータ更新完了通知がともに正常であれば、何も行わずに更新処理 を終了する。差分ファイル 14, 24, 34には何も書き込まれない。
[0006] サーバ 30が障害などでダウンしている時にサーバ 10にデータ更新イベントが発生 した場合、サーバ 20はデータ更新完了通知をサーバ 10へ送信するが、サーバ 30は データ更新完了通知をサーバ 10へ送信できない。サーバ 10は、サーバ 30からのデ ータ更新完了通知を待ち続けるが、タイムアウトし、サーバ 30での更新が正常に終 了しな力つたことを知る。サーバ 10は、差分ファイル 14に更新が失敗した装置の情 報 (この場合、サーバ 30)と更新内容を保存する。以上で、サーバ 10は更新処理を 終了する。
[0007] サーバ 20にデータ更新イベントが発生した場合も、サーバ 20は上述と同様の処理 を行い、差分ファイル 24に更新が失敗した装置の情報と更新内容を保存し、更新処 理を終了する。
[0008] 以上のようにして、サーバ 30が復旧するまでの間、サーバ 10とサーバ 20は更新内 容をそれぞれ差分ファイル 14, 24へ保存し続ける。
[0009] サーバ 30が障害力も復旧すると、サーバ 30のレプリケーシヨン制御部 32はサーバ
10に対してレプリケーシヨン開始通知を送信する。サーバ 10のレプリケーシヨン制御 部 12は差分ファイル 14に保存されて 、るデータを古 、順に取り出し、サーバ 30へデ ータ更新通知を送信する。サーバ 30は自データベース 33の内容を更新した後、デ ータ更新完了通知をサーバ 10へ送信する。サーバ 10は、データ更新完了通知を受 信するたびに該当するデータを差分ファイル 14から削除する。
[0010] 差分ファイル 14が空になったら、サーノ 20の差分ファイル 24のデータを上記と同 様にしてサーバ 30に送信する。差分ファイル 24も空になったら、サーバ 30の同期化 が完了する。
[0011] し力しながら、上記特許文献 1に記載のものでは、障害発生直後から正常稼働中の サーバがデータ更新内容を差分ファイルに蓄積しはじめるため、障害サーバの復旧 までの時間が長くなると差分ファイルが巨大になってしまう。その結果、正常稼働中 のサーバの記憶容量を食い潰してそのサーバが障害になってしまったり、障害から 復旧したサーバの同期完了までに時間が力かるなどの問題がある。
[0012] また、同期化の手順は障害が発生した時点のデータベースに、障害が発生した後 の更新内容を反映させるという方法である。このことは、同期化するサーバは障害が 発生する直前までのデータベースを正常に保持して 、ることが前提となって 、ること を意味する。したがって、ハードディスクの故障などデータベースが破壊される障害 が発生した場合、このサーバを同期化させることが不可能であるという問題がある。ま た、同じ理由から、サーバをアップグレードする場合など、データを全く保持していな
Vヽ新し 、サーバを同期化することができな 、と 、う問題もある。
[0013] さらに、同期化の手順は障害が発生した後の更新内容と障害が発生する直前まで のデータベースを基に行う方式、つまり、障害発生時点をポイントとした方式であるた め、障害復旧以外の目的にこの方式を使うことができない。すなわち、システム全体 のサーバ台数を増やす目的で、新たなサーバを同期化させることはできないという問 題がある。例えば、特許文献 1の実施例では、システム全体のサーバ台数は 3台であ る力 これを 4台に増やすために 4台目のサーバを同期化させることはできない。
[0014] また、システム全体のサーバ台数を減らすことができないという問題点もある。その 理由は、サーバを 1台切り離すと、永遠に差分ファイルを蓄積するためである。
[0015] さらに、トランザクションが失敗した場合にその失敗したトランザクションの更新内容 を取り消す方法が無 、と 、う問題もある。
[0016] さらに、障害でダウンしたサーバ以外の全てのサーバで、更新内容を分散して保存 しているため、 2台以上のサーバがダウンした場合には障害になったサーバを同期 化できな 、と!/、う問題もある。
[0017] 更に、上述の他の従来技術、及び、問題点についても説明する。従来の多重化デ ータベースシステムは、例えば特許文献 2に記載されたものが知られている。このシ ステムでは、図 127に示すように、それぞれデータベースを備えた 2つの計算機 110 と計算機 120が通信回線により接続されている。各計算機 110と 120とは、いわゆる 二相コミット制御によりデータベース間の同期が図られている。
[0018] 計算機 110は、各種の業務処理を実行する応用プログラム 111と、データベース 1 14の検索及び更新の制御を行うとともにトランザクションモニタ 113を介して他の計 算機 120のデータベース 124における更新処理との同期を取るデータベース管理シ ステム 112と、いわゆる二相コミット制御によってデータベース 114と 124の更新処理 の同期をとるトランザクションモニタ 113とから構成される。計算機 120についても計 算機 110と同様に、応用プログラム 121と、データベース管理システム 122と、トラン ザクシヨンモニタ 123と力も構成されている。
[0019] 本システムにおいて、計算機 110のデータベース 114と計算機 120のデータべ一 ス 124で同じデータを保持し、更新があつた場合でも両方のデータベース 114と 124 に同じ更新が反映される処理手順について説明する。
[0020] 応用プログラム 111は、あるトランザクション内でデータベース 114と 124を同一タエ リで更新する。データベース 114は、データベース管理システム 112が更新し、デー タベース 124はデータベース管理システム 122が更新する。
[0021] そして、応用プログラム 111は、トランザクションの最後に今までの更新を確定する「 COMMIT要求」又は今までの更新を取り消す「ROLLBACK要求」を発行する。「C OMMIT要求」又は「ROLLBACK要求」は、トランザクションモニタ 113によってデ ータベース管理システム 112と、トランザクションモニタ 123を経由してデータベース 管理システム 122へ送られる。
[0022] 例えば、トランザクションモニタ 113が「COMMIT要求」を転送した場合、データべ ース管理システム 112と 122は、 COMMIT実行の可否をトランザクションモニタ 113 へ返答する。この際、データベース管理システム 112と 122は実際には COMMITを 実行せず、実行の可否のみを答えるのみである。
[0023] トランザクションモニタ 113及び 123は、データベース管理システム 112及び 122の 双方から「COMMIT可」の応答を受け取ると、それぞれデータベース管理システム 1 12及び 122に「COMMIT実行」を送信する。「COMMIT実行」を受け取ったデー タベース管理システム 1112と 122は、実際に COMMITを実行する。
[0024] 一方、例えばトランザクションモニタ 113力 データベース管理システム 112又は 12 2の一方から「COMMIT不可」の応答を受け取った場合、他方の応答が「COMMI T可」であったとしても、データベース管理システム 112と122に対して¾01^ 八じ K実行」を送信し、トランザクションをキャンセルする。「ROLLBACK実行」を受け取 つたデータベース管理システム 112と 122は、実際に
ROLLBACKを実行する。
[0025] 以上のようにして、どちらか一方のデータベースだけ更新が反映されることを防ぎ、 両方のデータベースに対して常に同一の更新が行われるようにすることで、データべ ース間の同期を保つ。
[0026] し力しながら、上述の従来技術は、複数のデータベースにおける一トランザクション のデータベースの同期を図る方法であって、複数のトランザクション間でのデータべ ースの同期を制御することはできない。つまり、複数のトランザクションが並行に実行 されている状態で、且つ、それらのトランザクションが同一のテーブルの同一行にほ ぼ同時にアクセスした場合には、データベースの同期が崩れたり、クライアントへ返す 返答が一意に決まらないなどの問題が生じる。この問題点について以下に具体的に 例示する。
[0027] 図 128に示す test— tableという名前のテーブルを考える。この時、図 129に示すト ランザクシヨン T1及び T2がほぼ同時に実行される場合を考える。トランザクション T1 は id= 101の行を更新し、トランザクション T2は id = 101の行と id= 102の行を更新 する。どちらのトランザクションの UPDATEが先に実行されるかによって、 id= 101の 値は異なってしまう。 [0028] 2つのトランザクション中の UPDATEが実行される順序は以下の 2通りが考えられ る。
[0029] (1)T1の UPDATEの後に T2の UPDATE
(2) T2の UPDATEの後に T1の UPDATE
(1)の場合、 2つのトランザクション実行後には T2の UPDATEが残り、 departmen t = 2となる。一方（2)の場合、 2つのトランザクション実行後には T1の UPDATEが残 り、 department = 1となる。すなわち、（1)と（2)では最終的なテーブル test— table のデータが異なる。
[0030] つまり、複数のデータベースの初期状態が同じで、且つ、同じトランザクションを実 行したとしても、ある DBMS (Data Base Management System)では（1)の順 で実行し、別の DBMSは（2)の順で実行した場合、 2つのデータベースは同期状態 (同じデータを保持している状態)が崩れてしまう問題が発生する。
[0031] また、別の例として、図 130に示すトランザクション T3及び T4がほぼ同時に実行さ れる場合を考える。トランザクション T4の SELECTがトランザクション T3の COMMI Tの前に実行されるか又は後に実行されるかで、トランザクション T4の SELECTで得 られる値は異なってしまう。
[0032] トランザクション T4の SELECTとトランザクション T3の COMMITが実行される順序 は以下の 2通りが考えられる。
[0033] (3) T4の SELECTの後に T3の COMMIT
(4) T3の COMMITの後に T4の SELECT
(3)の場合、トランザクション T4の SELECT実行後には、トランザクション T3の UP DATEが反映されていない古い値 department= 3が得られる。一方（4)の場合、ト ランザクシヨン T4の SELECT実行後には、トランザクション T3の UPDATEが反映さ れた値 department = 1が得られる。
[0034] つまり、複数のデータベースの初期状態が同じで、且つ、同じトランザクションを実 行したとしても、ある DBMSは（3)の順で実行し、別の DBMSは（4)の順で実行した 場合、得られる値が異なってしまう。 特許文献 1：特開 2001— 290687号公報
特許文献 2：特開平 6 - 161862号公報
[0035] 本発明は、上記事情に鑑みてなされたものであり、第 1の目的とするところは、デー タベースサーバに障害が発生しても少ない同期化用データで復旧後のデータべ一 スサーバの同期化を図ることができる多重化データベースシステムを提供することに ある。また、第 2の目的とするところは、システム全体をダウンさせることなぐデータべ ースサーバのデータ記憶状況に拘わらずデータベースサーバを任意に切り離し又は 組み込むことができる多重化データベースシステムを提供することにある。
[0036] また、本発明が第 3の目的とするところは、複数のトランザクションを並行処理しても 各データベース間で矛盾の生じることがない多重化データベースシステムにおける 同期化方法を提供することにある。
発明の開示
[0037] 上記目的を達成するために、本願発明では、複数のデータベースサーバと、クライ アントコンピュータ力 の処理要求を各データベースサーバに中継するとともに各デ ータベースサーバからの正常な応答の 1つをクライアントコンピュータに処理結果とし て返す仲介装置とを備えた多重化データベースシステムにおいて、仲介装置は、ク ライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶部を 備える。そして、この仲介装置は、新規の又はこのシステム力も切り離されたデータべ ースサーバ（以後「新規データベースサーバ」と言う）のシステムへの組み込み要求が あると、（la)正常稼働中のデータベースサーバに対してスナップショットの作成を指 示し、（lb)組み込み要求受信時以降にクライアントコンピュータ力 受信する処理要 求を差分情報として差分情報記憶部に順次記憶し、（lc)新規データベースサーバ 力 差分情報転送要求を受信すると差分情報記憶部に記憶されている処理要求を 新規データベースサーバに順次送出し、（Id)差分情報記憶部に記憶されている処 理要求の送出が終了すると差分情報の記憶処理を終了するとともに新規データべ一 スサーバをシステムに組み込む。
[0038] 正常稼働中のデータベースサーバは、（2a)仲介装置力 スナップショット作成指示 を受信するとその時点でのデータベースのスナップショットの作成を開始し、 (2b)作 成したスナップショットを新規データベースサーバに転送する。
[0039] 新規データベースサーバは、（3a)正常稼働中のデータベースサーバからスナップ ショットを受信すると該スナップショットを用いてデータベースを復元し、（3b)スナップ ショットに基づきデータベースの復元が完了すると仲介装置に差分情報要求を送出 し、 (3c)仲介装置力 順次受信した処理要求に応じた処理を行う。
[0040] このようなシステムによれば、仲介装置では新規データベースサーバの同期化用の 差分情報を差分情報記憶部に記憶するが、この差分情報は新規データベースサー バからの組み込み要求を契機として差分情報記憶部への記憶が開始される。したが つて、データベースサーバを故障等によりシステム力 切り離した後に再びシステム に組み込む場合、障害復旧までに長時間要しても、仲介装置に多大な差分情報が 蓄積することがない。これにより、仲介装置の記憶容量を節約できるとともに差分情報 の増大による仲介装置の負荷増大やダウンを防止できる。
[0041] また、正常稼働中のデータベースサーバにおけるスナップショット及び仲介装置で 記憶された差分情報に基づき新規データベースサーバのデータが復元されるので、 組み込み時の新規データベースにおけるデータ蓄積状況はどのようなものであって も構わない。したがって、ディスク故障により切り離されたデータベースサーバの復帰 や、新規のデータベースサーバの組み込み（すなわちデータベースサーバの増強） を実現できる。すなわち、任意のデータベースサーバの組み込みが可能となる。
[0042] さらに、データベースサーバをシステム力 切り離しただけでは差分情報の記憶や スナップショットの作成は行われな 、ので、データベースのシステムからの切り離しを 任意に行うことができる。
[0043] なお、ここでシステムへのデータベースサーバの組み込みとは、多重化データべ一 スシステムを構成するデータベースサーバとして機能するよう仲介装置が当該データ ベースサーバを取り扱うようにすることを意味する。また、システムからのデータベース サーバからの切り離しとは、多重化データベースシステムを構成するデータベースサ ーバとして機能しないよう仲介装置が当該データベースサーバを取り扱うようにするこ とを意味する。したがって、システムに組み込まれているデータベースサーバにはクラ イアントコンピュータからの処理要求が仲介装置を介して届くが、システム力も切り離 されたデータベースサーバにはクライアントコンピュータからの処理要求が届かない 状態となる。なお、データベースサーバがシステムに組み込まれていること又は切り 離されて!/、ることと、データベースサーバが仲介装置と通信可能又は不能であること とは無関係である点に留意されたい。つまり、データベースサーバと仲介装置が通信 可能な状態にある場合であっても、データベースサーバがシステムに組み込まれて いない場合もあり得る。
[0044] また、スナップショットとは、その作成時点で確定して 、る（COMMITされて!/、る）の データベース全体の複製データやデータベースを復元するために必要なデータを意 味する。したがって、スナップショットには、作成時点で COMMITされていないデー タは含まれな 、ことに留意すべきである。
[0045] また、上記目的を達成するために、本願発明では、複数のデータベースサーバと、 クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに 各データベースサーバからの正常な応答の 1つをクライアントコンピュータに処理結 果として返す仲介装置とを備えた多重化データベースシステムにお 、て、仲介装置 は、クライアントコンピュータ力もの処理要求を差分情報として記憶する差分情報記 憶部を備える。そして、この仲介装置は、新規の又はこのシステム力も切り離されたデ ータベースサーバ（以後「新規データベースサーバ」と言う）のシステムへの組み込み 要求があると、（la)正常稼働中のデータベースサーバの中力 選択した 1つのデー タベースサーバ（以下「同期化用データベースサーバ」と言う）に対してスナップショッ トの作成を指示するとともに、この同期化用データベースサーバをシステム力 切り離 し、（lb)組み込み要求受信時以降にクライアントコンピュータから受信する処理要求 を正常稼働中の他のデータベースサーバを用いて処理するとともに、該処理要求を 差分情報として差分情報記憶部に順次記憶し、 (lc)差分情報転送要求を受信する と差分情報記憶部に記憶されている処理要求を同期化用データベースサーバ又は 新規データベースサーバに順次送出し、（Id)差分情報記憶部に記憶されている処 理要求の同期化用データベースサーバ又は新規データベースサーバに対する送出 が終了すると当該送出終了に係る同期化用データベースサーバ又は新規データべ ースサーバをシステムに組み込み、（le)同期化用データベースサーバ及び新規デ ータベースサーバの双方についてシステムへの糸且込が終了すると差分情報の記憶 処理を終了する。
[0046] 正常稼働中のデータベースサーバは、（2a)仲介装置力 スナップショット作成指示 を受信するとその時点でのデータベースのスナップショットの作成を開始し、 (2b)作 成したスナップショットを新規データベースサーバに転送し、 (2c)仲介装置から差分 情報として順次受信した処理要求に応じた処理を行う。
[0047] 新規データベースサーバは、（3a)同期化用データベースサーバからスナップショッ トを受信すると該スナップショットを用いてデータベースを復元し、（3b)スナップショッ トに基づきデータベースの復元が完了すると仲介装置に差分情報転送要求を送出し 、 (3c)仲介装置力 差分情報として順次受信した処理要求に応じた処理を行う。
[0048] このようなシステムによれば、仲介装置では新規データベースサーバの同期化用の 差分情報を差分情報記憶部に記憶するが、この差分情報は新規データベースサー バの組み込み要求を契機として差分情報記憶部への記憶が開始される。したがって 、データベースサーバを故障等によりシステム力も切り離した後に再びシステムに組 み込む場合、障害復旧までに長時間要しても、仲介装置に多大な差分情報が蓄積 することがない。これにより、仲介装置の記憶容量を節約できるとともに差分情報の増 大による仲介装置の負荷増大やダウンを防止できる。
[0049] さらに、同期化処理中は、スナップショットの作成及び新規データベースサーバへ の転送処理を、クライアントコンピュータからの処理要求に対する処理を行うデータべ ースサーバとは異なるデータベースサーバ（同期化用データベースサーバ）が行うの で、クライアントコンピュータからの処理要求を処理するデータベースサーバの負荷 増大を防止できる。これにより、同期化処理中であってもクライアントへのサービス提 供を円滑に維持できる。
[0050] また、本願発明は、複数のデータベースサーバと、クライアントコンピュータからの処 理要求を各データベースサーバに中継するとともに各データベースサーバからの正 当な応答の 1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた 多重化データベースシステムにおける各データベースの同期化処理に関するもので ある。
[0051] ところで、各データベースサーバにおいて複数のトランザクションが並行して処理さ れ、し力も各データベースサーバでトランザクション内での処理要求が互いに異なる 順番で処理されると、仲介装置側からは、（1)あるデータベースサーノくからの応答は あるが他のデータベースサーバからの応答はない、又は、（2)あるデータベースサー ノくからの応答と他のデータベースサーノくからの応答とが矛盾して ヽる（異なって!/ヽる） 、と認識される場合がある。
[0052] そこで、本願発明では、仲介装置は、（a)データベースサーノから処理要求に対す る応答がない事を検出すると該無応答のデータベースサーバをシステム力 切り離し 、 (b)システム力 切り離されたデータベースサーバとシステムに組み込まれて 、る正 常稼働中のデータベースサーバとの同期化処理を行い、 (c)同期化処理が完了した らシステム力 切り離されたデータベースサーバを再びシステムに組み込む。
[0053] これにより、あるデータベースサーバからの応答はあるが他のデータベースからの 応答がない場合には、当該応答のないデータベースサーバがシステム力 切り離さ れる。すなわち、各データベースサーバ間で処理要求の処理順序が異なり各データ ベースサーバ間で非同期になった（各データベースサーバ間で同一であるはずのデ ータが同一でなくなった）可能性を検出すると、あるデータベースサーバを基準として 該データベースサーバと非同期になった可能性のあるデータベースサーバがシステ ムから切り離される。そして、正常稼働中のデータベースサーバとシステム力 切り離 されたデータベースサーバとの同期化処理が行われ、同期化処理が完了するとシス テム力 切り離されたデータベースサーバが再びシステムに組み込まれる。これによ り、各データベースサーバの同期化が図られる。
[0054] また、本願発明では、仲介装置は、（i)各データベースサーバ間における処理結果 の矛盾を検出し、（j)処理結果の矛盾を検出したら各応答の中から 1つの応答を選定 するとともに当該選定した応答をクライアントコンピュータに返し、（k)選定した応答以 外の応答を返したデータベースサーバをシステム力 切り離し、 (1)システム力 切り 離されたデータベースサーバとシステムに組み込まれている正常稼働中のデータべ ースサーバとの同期化処理を行い、 (m)同期化処理が完了したらシステム力も切り 離されたデータベースサーバを再びシステムに組み込む。
[0055] これにより、あるデータベースサーバからの応答と他のデータベースサーバからの 応答とが矛盾している場合には、各応答の中から 1つの応答が選定され、選定された 応答以外の応答を返したデータベースサーバがシステム力 切り離される。すなわち 、各データベースサーバ間で処理要求の処理順序が異なって 、る可能性又は何ら かの原因で各データベースサーバ間で非同期になった（各データベースサーバ間で 同一であるはずのデータが同一でなくなった）可能性を検出すると、あるデータべ一 スサーバを基準として該データベースサーバと非同期になった可能性のあるデータ ベースサーバがシステム力も切り離される。そして、正常稼働中のデータベースサー ノ とシステム力 切り離されたデータベースサーバとの同期化処理が行われ、同期化 処理が完了するとシステム力 切り離されたデータベースサーバが再びシステムに組 み込まれる。これにより、各データベースサーバの同期化が図られる。
[0056] 上記同期化処理においては、仲介装置にクライアントコンピュータ力 の処理要求 を差分情報として記憶する差分情報記憶部を設け、データベースサーバがシステム 力も切り離されている間にクライアントコンピュータ力も受信した処理要求を差分情報 として記憶する。また、正常稼働中のデータベースサーバにおいてスナップショットを 作成し、システム力 切り離されたデータベースサーバは該スナップショットからデー タベースを復元する。その後に、前記差分情報記憶部に記憶されていた差分情報を 処理することで各データベースサーバの同期化が図れる。
[0057] ところで、このような同期化処理においては仲介装置力 送出された差分情報につ いても、前述したような処理順序の問題が生じる恐れが考えられる。すなわち、差分 情報の処理を行うデータベースサーバと、当該差分情報を蓄積中に処理要求を処 理した正常稼働中のデータベースサーバとでは、処理順序が異なる場合が考えられ る。
[0058] そこで、本願発明では、仲介装置は、差分情報として記憶した処理要求について、 正常稼働中のデータベースサーバで処理した当該処理要求に対する処理結果を、 差分情報とともに記憶しておく。そして、差分情報を送出したデータベースサーバか ら当該差分情報の処理に対する処理結果を受信すると、該処理結果と差分情報とと もに記憶した処理結果とを比較し、両者が一致しない場合には同期化処理を再試行 する。このような処理により、データベースサーバの同期化をより確実に実施できる。
[0059] なお、ここでシステムへのデータベースサーバの組み込みとは、多重化データべ一 スシステムを構成するデータベースサーバとして機能するよう仲介装置が当該データ ベースサーバを取り扱うようにすることを意味する。また、システムからのデータベース サーバからの切り離しとは、多重化データベースシステムを構成するデータベースサ ーバとして機能しないよう仲介装置が当該データベースサーバを取り扱うようにするこ とを意味する。したがって、システムに組み込まれているデータベースサーバにはクラ イアントコンピュータからの処理要求が仲介装置を介して届くが、システム力も切り離 されたデータベースサーバにはクライアントコンピュータからの処理要求が届かない 状態となる。なお、データベースサーバがシステムに組み込まれていること又は切り 離されて!/、ることと、データベースサーバが仲介装置と通信可能又は不能であること とは無関係である点に留意されたい。つまり、データベースサーバと仲介装置が通信 可能な状態にある場合であっても、データベースサーバがシステムに組み込まれて いない場合もあり得る。
[0060] 以上説明したように本発明によれば、データベースサーバに障害が発生しても少な い同期化用データで復旧後のデータベースサーバの同期化を図ることができる。ま た、システム全体をダウンさせることなぐデータベースサーバのデータ記憶状況に拘 わらずデータベースサーバを任意に切り離し又は組み込むことができる。
[0061] また、本発明によれば、複数のトランザクションを並行処理することにより各データべ ースサーバ間で矛盾が生じても、各データベースサーバの同期化が図られるので当 該矛盾を解消できる。 図面の簡単な説明
[0062] [図 1]第 1の実施形態に係る多重化データベースシステムの構成図
[図 2]第 1の実施形態に係るサーバ管理表の一例を示す図
[図 3]第 1の実施形態に係るトランザクション管理表の一例を示す図
[図 4]第 1の実施形態に係る差分情報蓄積部の一例を示す図 圆 5]第 1の実施形態に係る送信キューの一例を示す図
[図 6]各サーバが正常稼働している場合の多重化データベースシステムの動作を説 明するシーケンスチャート
圆 7]図 5の動作におけるサーバ管理表の一例
圆 8]図 5の動作におけるトランザクション管理表の一例
[図 9]サーバが故障した場合の多重化データベースシステムの動作を説明するシー ケンスチャート
[図 10]図 8の動作におけるトランザクション管理表の一例
[図 11]図 8の動作におけるサーバ管理表の一例
[図 12]新規にサーバを組み込む場合の多重化データベースシステムの動作を説明 するシーケンスチャート
[図 13]新規にサーバを組み込む場合の多重化データベースシステムの動作を説明 するシーケンスチャート
[図 14]新規にサーバを組み込む場合の多重化データベースシステムの動作を説明 するシーケンスチャート
[図 15]図 11及び図 12の動作におけるサーバ管理表の一例
[図 16]図 11及び図 12の動作におけるトランザクション管理表の一例
[図 17]図 11及び図 12の動作におけるトランザクション管理表の一例
[図 18]図 11及び図 12の動作におけるトランザクション管理表の一例
圆 19]図 11及び図 12の動作における差分情報蓄積部の一例
[図 20]図 11及び図 12の動作におけるサーバ管理表の一例
[図 21]新規にサーバを組み込む場合の多重化データベースシステムの動作を説明 するシーケンスチャート
圆 22]第 2の実施形態においてクライアントから受信したクエリと差分情報として送出 するクエリの関係を説明する図
[図 23]第 3の実施形態に係る差分情報蓄積部の一例
圆 24]第 4の実施形態に係る仲介装置の構成図
[図 25]第 4の実施形態に係る送信キューの一例を示す図 [図 26]第 4の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 27]第 4の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 28]第 4の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 29]第 4の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 30]第 4の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 31]第 5の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 32]第 5の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 33]第 5の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 34]第 5の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 35]第 5の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 36]従来のデータベース同期化システムの構成図
[図 37]第 6の実施形態に係る多重化データベースシステムの構成図
圆 38]第 6の実施形態に係るサーバ管理表の一例を示す図
圆 39]第 6の実施形態に係るトランザクション管理表の一例を示す図
圆 40]第 6の実施形態に係る差分情報蓄積部の一例を示す図
圆 41]第 6の実施形態に係る送信キューの一例を示す図
[図 42]各サーバが正常稼働している場合の多重化データベースシステムの動作を説 明するシーケンスチャート [図 43]図 41の動作におけるサーバ管理表の一例
[図 44]図 41の動作におけるトランザクション管理表の一例
[図 45]サーバが故障した場合の多重化データベースシステムの動作を説明するシー ケンスチャート
[図 46]図 44の動作におけるトランザクション管理表の一例
[図 47]図 44の動作におけるサーバ管理表の一例
[図 48]新規にサーバを組み込む場合の多重化データベースシステムの動作を説明 するシーケンスチャート
[図 49]新規にサーバを組み込む場合の多重化データベースシステムの動作を説明 するシーケンスチャート
[図 50]新規にサーバを組み込む場合の多重化データベースシステムの動作を説明 するシーケンスチャート
[図 51]図 47及び図 48の動作におけるサーバ管理表の一例
[図 52]図 47及び図 48の動作におけるトランザクション管理表の一例
[図 53]図 47及び図 48の動作におけるトランザクション管理表の一例
[図 54]図 47及び図 48の動作におけるトランザクション管理表の一例
[図 55]図 47及び図 48の動作におけるサーバ管理表の一例
圆 56]図 47及び図 48の動作における差分情報蓄積部の一例
[図 57]図 47及び図 48の動作におけるサーバ管理表の一例
[図 58]新規にサーバを組み込む場合の多重化データベースシステムの動作を説明 するシーケンスチャート
圆 59]第 7の実施形態においてクライアントから受信したクエリと差分情報として送出 するクエリの関係を説明する図
[図 60]第 8の実施形態に係る差分情報蓄積部の一例
[図 61]第 9の実施形態に係る仲介装置の構成図
[図 62]第 9の実施形態に係る送信キューの一例を示す図
[図 63]第 9の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例 [図 64]第 9の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 65]第 9の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 66]第 9の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 67]第 9の実施形態に係る多重化データベースシステムの動作中の送信キューの 一例
[図 68]第 10の実施形態に係る多重化データベースシステムの動作中の送信キュー の一例
[図 69]第 10の実施形態に係る多重化データベースシステムの動作中の送信キュー の一例
[図 70]第 10の実施形態に係る多重化データベースシステムの動作中の送信キュー の一例
[図 71]第 10の実施形態に係る多重化データベースシステムの動作中の送信キュー の一例
[図 72]第 10の実施形態に係る多重化データベースシステムの動作中の送信キュー の一例
圆 73]第 11の実施形態に係る多重化データベースシステムの動作を説明するシー ケンスチャート
圆 74]第 11の実施形態に係る多重化データベースシステムの動作を説明するシー ケンスチャート
[図 75]第 12の実施形態に係る多重化データベースシステムの構成図
圆 76]第 12の実施形態に係るサーバ管理表の一例を示す図
圆 77]第 12の実施形態に係るトランザクション管理表の一例を示す図
[図 78]第 12の実施形態に係る差分情報蓄積部の一例を示す図
圆 79]第 12の実施形態に係る送信キューの一例を示す図
[図 80]各サーバが正常稼働している場合の多重化データベースシステムの動作を説 明するシーケンスチャート
[図 81]図 79の動作におけるサーバ管理表の一例
[図 82]図 79の動作におけるトランザクション管理表の一例
[図 83]サーバが故障した場合の多重化データベースシステムの動作を説明するシー ケンスチャート
[図 84]図 82の動作におけるトランザクション管理表の一例
[図 85]図 82の動作におけるサーバ管理表の一例
[図 86]サーバにより異なる順序でクエリが実行された場合の多重化データベースシス テムの動作を説明するシーケンスチャート
[図 87]サーバにより異なる順序でクエリが実行された場合の多重化データベースシス テムの動作を説明するシーケンスチャート
[図 88]サーバにより異なる順序でクエリが実行された場合の多重化データベースシス テムの動作を説明するシーケンスチャート
[図 89]サーバにより異なる順序でクエリが実行された場合の多重化データベースシス テムの動作を説明するシーケンスチャート
[図 90]多重化データベースシステムにおける同期化処理を説明するシーケンスチヤ ート
[図 91]多重化データベースシステムにおける同期化処理を説明するシーケンスチヤ ート
[図 92]多重化データベースシステムにおける同期化処理を説明するシーケンスチヤ ート
[図 93]図 90乃至図 92の動作におけるサーバ管理表の一例
[図 94]図 90乃至図 92の動作におけるトランザクション管理表の一例
[図 95]図 90乃至図 92の動作におけるトランザクション管理表の一例
[図 96]図 90乃至図 92の動作におけるトランザクション管理表の一例
圆 97]図 90乃至図 92の動作における差分情報蓄積部の一例
[図 98]多重化データベースシステムにおける同期化処理を説明するシーケンスチヤ ート 圆 99]第 13の実施形態の同期化処理においてクライアントから受信したクエリと差分 情報として送出するクエリの関係を説明する図
[図 100]第 14の実施形態に係る差分情報蓄積部の一例
[図 101]第 15の実施形態に係る仲介装置の構成図
圆 102]第 15の実施形態に係る送信キューの一例を示す図
[図 103]第 15の実施形態に係る多重化データベースシステムの同期化処理中の送 信キューの一例
[図 104]第 15の実施形態に係る多重化データベースシステムの同期化処理中の送 信キューの一例
[図 105]第 4の実施形態に係る多重化データベースシステムの同期化処理中の送信 キューの一例
[図 106]第 15の実施形態に係る多重化データべースシステムの同期化処理中の送 信キューの一例
[図 107]第 15の実施形態に係る多重化データべースシステムの同期化処理中の送 信キューの一例
[図 108]第 16の実施形態に係る多重化データべースシステムの同期化処理中の送 信キューの一例
[図 109]第 16の実施形態に係る多重化データべースシステムの同期化処理中の送 信キューの一例
[図 110]第 16の実施形態に係る多重化データべースシステムの同期化処理中の送 信キューの一例
[図 111]第 16の実施形態に係る多重化データべースシステムの同期化処理中の送 信キューの一例
[図 112]第 16の実施形態に係る多重化データべースシステムの同期化処理中の送 信キューの一例
[図 113]第 17の実施形態に係る多重化データベースシステムの構成図
[図 114]第 17の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート [図 115]第 17の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 116]第 17の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 117]図 114乃至図 116の動作におけるサーバ管理表の一例
[図 118]図 114乃至図 116の動作におけるトランザクション管理表の一例
[図 119]図 114乃至図 116の動作におけるトランザクション管理表の一例
[図 120]図 114乃至図 116の動作におけるトランザクション管理表の一例
[図 121]図 114乃至図 116の動作におけるサーバ管理表の一例
圆 122]図 114乃至図 116の動作における差分情報蓄積部の一例
[図 123]図 114乃至図 116の動作におけるサーバ管理表の一例
[図 124]第 18の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 125]第 18の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 126]他の例に係る多重化データベースシステムの構成図
[図 127]従来のデータベース同期化システムの構成図
[図 128]データベースのテーブルの一例
[図 129]処理順序が問題となるトランザクションの一例
[図 130]処理順序が問題となるトランザクションの一例
[図 131]第 19の実施形態に係る多重化データベースシステムの構成図
[図 132]第 19の実施形態に係る仲介装置の機能ブロック図
圆 133]第 19の実施形態に係るサーバ管理表の一例を示す図
圆 134]第 19の実施形態に係るトランザクション管理表の一例を示す図
圆 135]第 19の実施形態に係る送信キューの一例を示す図
[図 136]各サーバが正常稼働している場合の多重化データベースシステムの動作を 説明するシーケンスチャート
[図 137]図 135の動作におけるサーバ管理表の一例 [図 138]図 135の動作におけるトランザクション管理表の一例
[図 139]サーバが故障した場合の多重化データベースシステムの動作を説明するシ 一ケンスチャート
[図 140]図 139の動作におけるトランザクション管理表の一例
[図 141]図 139の動作におけるサーバ管理表の一例
[図 142]図 139の動作における送信キューの一例
[図 143]サーバにより異なる順序でクエリが実行された場合の多重化データベースシ ステムの動作を説明するシーケンスチャート
[図 144]サーバにより異なる順序でクエリが実行された場合の多重化データベースシ ステムの動作を説明するシーケンスチャート
[図 145]サーバにより異なる順序でクエリが実行された場合の多重化データベースシ ステムの動作を説明するシーケンスチャート
[図 146]サーバにより異なる順序でクエリが実行された場合の多重化データベースシ ステムの動作を説明するシーケンスチャート
[図 147]第 19の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 148]第 19の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 149]第 19の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 150]第 19の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 151]図 208乃至図 150の動作におけるサーバ管理表の一例
[図 152]図 208乃至図 150の動作におけるトランザクション管理表の一例
[図 153]図 208乃至図 150の動作における送信キューの一例
[図 154]図 208乃至図 150の動作における送信キューの一例
[図 155]図 208乃至図 150の動作におけるサーバ管理表の一例
[図 156]図 208乃至図 150の動作における送信キューの一例 [図 157]図 208乃至図 150の動作におけるトランザクション管理表の一例
[図 158]図 208乃至図 150の動作における送信キューの一例
[図 159]図 208乃至図 150の動作における送信キューの一例
[図 160]図 208乃至図 150の動作における送信キューの一例
[図 161]図 208乃至図 150の動作におけるサーバ管理表の一例
[図 162]図 208乃至図 150の動作における送信キューの一例
[図 163]図 208乃至図 150の動作における送信キューの一例
[図 164]図 208乃至図 150の動作における送信キューの一例
[図 165]図 208乃至図 150の動作における送信キューの一例
[図 166]図 208乃至図 150の動作における送信キューの一例
[図 167]図 208乃至図 150の動作における送信キューの一例
[図 168]図 208乃至図 150の動作におけるサーバ管理表の一例
[図 169]第 20の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 170]第 20の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 171]第 20の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 172]第 20の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 173]第 20の実施形態に係る多重化データベースシステムにおける同期化処理を 説明するシーケンスチャート
[図 174]図 169乃至図 173の動作におけるサーバ管理表の一例
[図 175]図 169乃至図 173の動作における送信キューのデータ構造の一例
[図 176]図 169乃至図 173の動作における送信キューの一例
[図 177]図 169乃至図 173の動作における送信キューの一例
[図 178]図 169乃至図 173の動作におけるサーバ管理表の一例
[図 179]図 169乃至図 173の動作における送信キューの一例 [図 180]図 169乃至図 173の動作に：おける送信キュ -の-一例
[図 181]図 169乃至図 173の動作に ：おける送信キュ -の-一例
[図 182]図 169乃至図 173の動作に ：おける送信キュ -の-一例
[図 183]図 169乃至図 173の動作に ：おける送信キュ -の-一例
[図 184]図 169乃至図 173の動作に ：おける送信キュ -の-一例
[図 185]図 169乃至図 173の動作に ：おける送信キュ -の-一例
[図 186]図 169乃至図 173の動作に ：おける送信キュ —の-一例
[図 187]他の実施の形態における多重化データベースシステムの構成図
[図 188]他の実施の形態における多重化データベースシステムの構成図
[図 189]他の実施の形態における多重化データベースシステムの同期化処理を説明 するシーケンスチャート
[図 190]他の実施の形態における多重化データベースシステムの同期化処理を説明 するシーケンスチャート
[図 191]他の実施の形態における多重化データベースシステムの同期化処理を説明 するシーケンスチャート
[図 192]他の実施の形態における多重化データベースシステムの構成図
符号の説明
1100 サーノ
1101 データべ -ス
1102 データべ -ス制御部
1200 仲介装置
1201 サーバ管理表
1202 トランザクション管理表
1203 差分情報蓄積部
1204 送 1 やユー
1206 送 1 やユー
1205 差分情報- 時蓄積部
1210 サーバ制御部 1300 ネットワーク
1400 ネットワーク
1500 クライアント
1800 仮想サーバ
2100 サーノ
2101 データベース
2102 データベース制御部
2200 仲介装置
2201 サーバ管理表
2202 トランザクション管理表
2203 差分情報蓄積部
2204 送 1 やユー
2206 送 1 やユー
2205 差分情報一時蓄積部
2210 サーバ制御部
2300 ネットワーク
2400 ネットワーク
2500 クライアント
2800 仮想サーバ
2101 サーバ管理表
3100 サーノ
3101 データベース
3102 データベース制御部
3200 仲介装置
3201 サーバ管理表
3202 トランザクション管理表
3203 差分情報蓄積部
3206 送 1 キュー 3204 送信キュー
3205 差分情報一時蓄積部
3210 サーバ制御部
3300 ネットワーク
3400 ネットワーク
3500 クライアント
3600 データベース一致検査装置
3800 仮想サーバ
4100 サーノ
4101 データベース
4102 データベース制御部
4200 仲介装置
4201 サーバ管理表
4202 トランザクション管理表
4203 送 1 やユー
4204 受信クエリ処理部
4205 クエリ送信処理部
4206 正当性判定部
4207 応答送信処理部
4208 同期化処理制御部
4300 ネットワーク
4400 ネットワーク
4500 クライアント
4600 データベース一致検査装置
4800 仮想サーバ 発明を実施するための最良の形態
以下、図面を参照しつつ、本発明の好適な実施例について説明する。ただし、本 発明は以下の各実施例に限定されるものではなぐ例えばこれら実施例の構成要素 同士を適宜組み合わせてもよ 、。
[0065] (第 1の実施の形態）
本発明の第 1の実施の形態に係る多重化データベースシステムについて図面を参 照して説明する。図 1は本実施の形態に係る多重化データベースシステムの全体構 成を説明するブロック図である。
[0066] この多重化データベースシステムは、図 1に示すように、複数のデータベースサー ノ （以下「サーバ」と言う） 1100と仲介装置 1200とをネットワーク 1300で接続したも のであり、ネットワーク 1400を介して 1以上のクライアントコンピュータ（以下「クライア ント」と言う） 1500からアクセスされるものである。本実施の形態では、図 1に示すよう 【こ、 2台のサーノ 1100a及び 1100bを有しており、 2台のクライアント 1500a及び 15 00bからアクセスされる。以降の説明にお 、て各サーバ 1100を他のサーバ 1100と 区別する場合には添え字「a」「b」を付加するものとする。クライアント 1500についても 同様である。なお、図 1の例では、サーバ 1100とクライアント 1500はそれぞれ別々 のネットワーク 1300, 1400に接続されている力 同じネットワークに接続されていて ちょい。
[0067] 図 1に示すように、仲介装置 1200は、ネットワーク 1400側に IPアドレス 172.17.1.1 を持っており、これをデータベースサーバの IPアドレスとして公開している。クライアン ト 1500はデータベースにアクセスしたいときは IPアドレス 172.17.1.1へクエリを送信し 、 IPアドレス 172.17.1.1の仲介装置 1200からそのクエリに対する応答パケットを受信 する。これは、クライアント 1500にとつては、 IPアドレス 172.17.1.1を持ったデータべ ースサーバとパケットを送受信していることと同じである。この IPアドレス 172.17.1.1を 持った仮想的なデータベースサーバを仮想サーバ 1800と呼ぶ。この仮想サーバ 18 00の目的は、サーバ 1100が冗長化されていることを隠蔽するためである。つまり、サ ーバ 1100aとサーバ 1100b両方が稼働していようとサーバ 1100bがダウンしてサー ノ 1100aのみが稼働して!/、ようとサーバ 1100aとサーバ 1100bの他に新たなサーバ が追加されようとクライアントには影響は無ぐ動作を変更する必要がない。
[0068] サーバ 1100は、データを保存'管理するデータベース 1101と、データベース 110 1の動作を制御するデータベース制御部 1102とを備えて 、る。
[0069] データベース 1101は、 SQL (Structured Query Language)を解して処理を行う RD BMS (Relational Database Management System)である。このようなデータベース 11 01としては種々のものがあり、例えば The PostgreSQL Global Development Groupによる PostgreSQL (http://www.postgres.org/)や、 Oracle社による Oracl e (登録商標） (http://www.oracle.com)などが挙げられる。
[0070] データベース制御部 1102は、ネットワーク 1300を介して仲介装置 1200から送ら れてくるパケットに基づき動作する。このパケットは、 SQLなどデータベース 1101で の処理に係るもの、同期化処理に係るものに大別される。 SQLなどデータベース 11 01での処理に係るものについては、データベース制御部 1102は、当該パケットをデ ータベース 1101に渡し、データベース 1101からの処理結果を仲介装置 1200に返 す。
[0071] 一方、同期化処理に係るものは、さらに自身が本システムに組み込まれている場合 のものと、障害復旧時などこれからシステムに組み込む場合のものとに別れる。前者 については、スナップショットの作成指示がある。データベース制御部 1102は、スナ ップショット作成指示を仲介装置 1200から受信すると、データベース 1101のスナツ プショットを作成する。そして、スナップショットの作成が完了すると、スナップショット 作成完了を仲介装置 1200に通知する。そして、作成したスナップショットを、スナツ プショット作成指示で指示されている転送先の他のサーバ 1100に転送する。
[0072] 他方、障害復旧時などこれからシステムに組み込む場合、データベース制御部 11 02は、他のデータベースからスナップショットを受信すると、このスナップショットを用 いて自身のデータベース 1101を復元する。データベース 1101の復元が完了すると 仲介装置 1200に対して差分情報転送要求を送出する。後述するように、差分情報 転送要求に応じて仲介装置 1200から差分情報が転送されるので、この差分情報を 用いてデータベース 1101を復元する。
[0073] また、データベース制御部 1102は、本システムに組み込む際には、仲介装置 120 0に対して組み込み要求を送信する。この組み込み要求は、サーバ 1100の起動時 や、必要に応じて任意のタイミングで送出する。 [0074] 仲介装置 1200は、本システム内のサーバ 1100を管理するサーバ管理表 1201と 、トランザクションを管理するトランザクション管理表 1202と、同期化用に差分情報を 蓄積する差分情報蓄積部 1203と、サーバ 1100に送信するクエリを一時保存する送 信キュー 1204と、クライアント 1500 ·サーバ 1100間での処理の仲介やサーバ 1100 の同期化制御などを行うサーバ制御部 1210とを備えている。
[0075] サーバ管理表 1201は、サーバが正常稼働中（active)か、障害などで停止してい る（down)力 という状態を保存している。図 2にサーバ管理表の一例を示す。サー バ管理表 1201は、図 2に示すように、サーバ 1100を識別するためのサーバ IDと、 サーバの稼働状態から構成されている。図 2の例では、サーノ 1100aとサーノ 1100 bとが登録されており、稼働状態は共に正常稼働を示す activeである。また、本実施 形態では、サーノ IDとしてサーバ 1100に付された IPアドレスを用いた。
[0076] トランザクション管理表 1202は、現在実行中の又は実行開始を保留されているトラ ンザクシヨンの有無を記憶する。図 3にトランザクション管理表 1202の一例を示す。 図 3に示すように、トランザクション管理表 1202は、クライアントを一意に識別するクラ イアント IDとトランザクションを一意に識別するトランザクション ID力も構成される。こ れらのペアは、トランザクション開始時にトランザクション管理表 1202に登録され、トラ ンザクシヨン終了時にトランザクション管理表 1202から削除される。クライアント IDは 、例えばクライアント 1500の IPアドレスやポート番号である。トランザクション IDは新し いトランザクションが発生する毎にサーバ制御部 1210が新たに割り振る。
[0077] 差分情報蓄積部 1203は、サーバ同期化時にクライアント 1500から受信する全て のクエリを蓄積する。図 4に差分情報蓄積部 1203が蓄積している差分情報の一例を 示す。差分情報蓄積部 1203の各データは、図 4に示すように、クライアント 1500が 送信したクエリと、このクエリが所属するトランザクション IDとから構成される。トランザ クシヨン IDはトランザクション管理表 1202から取得する。同期化処理時におけるクラ イアント 1500からの新たなクエリは、この差分情報蓄積部 1203の最後に追加される 。つまり、上から古いクエリが蓄積されている。図 4の例では、トランザクション ID= 1の BE
GINが一番古ぐ COMMITが一番新しい。 [0078] 送信キュー 1204は、各クライアント 1500から受信したクエリを各サーバ 1100に送 信するまで一時的に保存するバッファメモリである。図 5に送信キュー 1204の一例を 示す。送信キュー 1204の各データは、図 5に示すように、クライアント 1500が送信し たクエリと、このクエリが所属するトランザクション IDと、サーバ 1100に送信した力否 かを表す送信情報とから構成される。トランザクション IDはトランザクション管理表 12 02から取得する。クライアント 1500からの新たなクエリは、この送信キュー 1204の最 後に追加される。つまり、上から古いクエリが蓄積されている。図 5の例では、トランザ クシヨン ID= 1の BEGINが一番古ぐトランザクション ID = 2の BEGINが一番新しい 。この送信キュー 1204の送信状態は、クライアント 1500からクエリを受信した際には 「未送信」が設定され、正常稼働中の全てのサーバ 1100に送信されると「送信完了」 が設定される。送信完了となったエントリは、直ちに又は所定期間経過後に送信キュ 一 1204から削除される。
[0079] サーバ制御部 1210は、通常の処理（同期化処理時以外の処理）として、クライアン ト 1500からのパケットをネットワーク 1400経由で受信し、サーバ管理表 1201を見て 正常稼働している全てのサーバ 1100へ該パケットを転送する。ここで、サーバ 1100 へ転送するパケットは、送信キュー 1204に「未送信」として記憶されているクエリが対 象であり、送信キュー 1204に記憶されている古いクエリから順に転送される。そして 、サーバ 1100からのパケットをネットワーク 1300経由で受信し後述するパケットの正 当性判断方法により 1つ以上の該パケットのうち 1つを選出し 1つの正しいパケットを ネットワーク 1400を経由してクライアント 1500へ転送する。なお、同期化処理時には 、「未送信」のクエリであっても新規トランザクションに属するクエリは送信せず、実行 中のトランザクションに属するクエリのみを古い順に正常稼働中のサーバ 1100に送 信する。
[0080] ここで、サーバ制御部 1210は、クライアント 1500からの処理要求を解析してトラン ザクシヨンの開始と終了を検出してトランザクション管理表 1202を更新する。トランザ クシヨン開始と終了をサーバ制御部 1210が検出する方法は、 DBMSの種類によつ て異なる。例えば前述の PostgreSQLの場合は、トランザクションの開始はクライアン ト 1500力 S「BEGIN」という SQLを送信した時であり、トランザクションの終了はクライア ント 1500力 COMMIT」「ROLLBACK」という SQLを送信した時である。また、 Or acleの場合は、トランザクションの開始はクライアント 1500
が有効な SQLを送信したときであり（明示的なトランザクションの開始を宣言する SQ Lは無い）、トランザクションの終了はクライアント 1500が「COMMIT」「ROLLBAC K」と!、う SQLを送信した時である。また、 AUTO COMMITモードで動作する場合 には、クライアント 1500から受信した SQL文はそれぞれ 1つの独立したトランザクショ ンに属していると解釈できるので、クライアント 1500から SQLを受信する毎に、該 SQ L実行前にトランザクションが開始されるとともに SQL実行後に当該トランザクションが 終了したこととして扱うことができる。
[0081] また、パケットの正当性判断方法は、例えば、多数決で決める方法や、受信したパ ケットを所定のルールに基づいて判断する方法がある。例えば、クライアント 1500力 らの「参照」要求に対して「更新成功」 、う応答が返ってきた場合、正常であればそ のような応答はあり得ないので (参照成功など参照に関する応答のはず）、この応答 パケットは正しくないと判断する。また、パケット中にデータ長フィールドがある場合、 このデータ長フィールドの値と実際に受信したパケット長を比較し、異なる場合は正し くないと判断する。また、複数のサーバ 1100の中力も Masterサーバを予め 1台決め ておき、この
サーバ 1100からのパケットを常に正しいと判断する。また、上記複数の方法を併用 する方法もある。例えば、 3台で多数決を行った結果、パケットの中身が全てバラバラ であり、多数派のパケットを決められない場合は Masterサーバのパケットを正しいと 判断する。正常稼働しているサーバが 1つだけの場合は、そのサーノくからの応答パ ケットを正常と判断する。
[0082] サーバ制御部 1210は、正当ではない応答を送信したサーバ 1100は障害と判断し 、そのサーバ 1100についてはサーバ管理表 1201から登録を削除することによりシ ステム力も切り離す。なお、応答を返してこないサーバ 1100も障害と判断する。
[0083] さらに、サーバ制御部 1210は、ネットワーク 1300を介してサーバ 1100からシステ ムの組み込み要求を受信すると、この新規のサーバ 1100と、正常稼働中のサーバ 1 100とを同期化させる処理を行う。以下にその処理にっ 、て説明する。 [0084] サーバ制御部 1210は、サーバ 1100からシステムの組み込み要求を受信すると、 正常稼働中のサーバ 1100に対してスナップショットの作成指示を送出する。ここで、 スナップショットの作成指示を送出するタイミングは、サーバ 1100においてトランザク シヨンが実行中でないことが求められる。これはスナップショット作成中にトランザクシ ヨンが ROLLBACKするとデータの同期化が図れない場合があることを防止するた めや、 COMMITされて!/、な!/、ために更新データがスナップショットに反映されな！、こ とを防止するためである。このためサーバ制御部 1210は、処理中のトランザクション が終了するまでスナップショットの作成指示の送出を待つとともに、スナップショット作 成完了通知をサーバ 1100から受信するまでは新規トランザクションを開始しないよう にしている。そして、新規トランザクションに係る SQLについては、スナップショット作 成完了通知の受信後に、正常稼働中のサーバ 1100で処理するとともに、差分情報 蓄積部 1203に蓄積する。差分情報蓄積部 1203に蓄積するクエリは、トランザクショ ン制御 SQL、参照系 SQL及び更新系 SQLを含む全ての SQLが対象となる。
[0085] サーバ制御部 1210がスナップショットの作成指示を送出すると、当該スナップショ ットは新規のサーバ 1100に転送され、このサーバ 1100からサーバ制御部 1210に 対して差分情報転送要求が送出される。サーバ制御部 1210は、差分情報転送要求 を受信すると、新規のサーバ 1100に対して差分情報蓄積部 1203に蓄積されている クエリを古いもの力も順次送信する。差分情報蓄積部 1203に蓄積されている SQLを 全て送出すると、サーバ制御部 1210は、新規サーバ 1100をシステムに組み込むベ くサーバ管理表 1201を更新する。
[0086] ここで、サーバ制御部 1210は、差分情報の送出中にクライアント 1500から新たな クエリを受信する場合があるが、この場合は当該クエリを差分情報蓄積部 1203の最 後に追加するとともに正常稼働中のサーバ 1100へ送信すれば良い。ただし、クライ アント 1500のクエリ送出頻度が高い場合などには、差分情報の送出終了まで、すな わち同期化終了まで長時間要する場合が考えられる。そこで、差分情報蓄積部 120 3における未送信の差分情報が所定件数以下となったら、クライアント 1500からのク エリを一時保留して差分情報の送出のみを行い、まず差分情報の送出を完了させる 。そして、前述のように新規サーバ 1100をシステムに組み込むべくサーバ管理表 12 01を更新した後に、保留していたクエリ処理を再開すると好適である。
[0087] クライアント 1500は、データベースサーバに対して更新クエリ（データベースを更新 するリクエスト)や参照クエリ（データベースの内容を参照するリクエスト）などを発行す るものである。
[0088] 次に、本実施の形態に係る多重化データベースシステムの動作について図面を参 照して説明する。まず、サーバ 1100aと 1100bが正常に動作している場合の動作を 図 6から図 8を参照して説明する。
[0089] 初期状態では、データベース 1101aと 1101bは完全に同一であり、サーバ管理表 1201は図 7のようになっているものとする。また、トランザクション管理表 1202と差分 情報蓄積部 1203は空であるとする。各サーバ 1100a, 1100bには、テーブル test —tableが存在して!/、るとする。
[0090] クライアント 1500a力 172.17.1.1宛にトランザクション開始 SQLを含んだパケットを送 信すると、仲介装置 1200はそのパケットを受信する (ステップ S 11)。サーバ制御部 1 210は、トランザクションが開始されたことを検知し、トランザクション管理表 1202にク ライアント 1500aの IPアドレスとトランザクション番号を登録する（ステップ S 12)。図 8 にこのときのトランザクション管理表 1202を示す。そして、このパケットに係るクエリを 送信状態「未送信」で送信キュー 1204に入れる。
[0091] サーバ制御部 1210は、送信キュー 1204から当該「未送信」のクエリを取り出し、サ ーバ管理表 1201を見て正常稼働している全てのサーバ 1100に該パケットを送信す る。この場合、サーバ 1100aと 100bが正常稼働しているので、サーバ制御部 1210 はサーバ 1100aとサーバ 1100bへ該パケットを転送する（それぞれステップ S13と S 14)。そして、各サーバ 1100への送信が完了したので送信キュー 1204の送信状態 を「送信完了」にして当該エントリを削除する。仲介装置 1200は、トランザクションが 正常に開始されたことを通知する応答パケットをサーバ 1100aから受信するが (ステ ップ S 15)、この時点では、未だ全ての応答パケットが揃っているわけではないので（ この場合、サーバ 1100bからの応答パケットが来ていない）、サーバ制御部 1210は 何もせずにサーバ 1100bからの応答パケットを待つ。そして、トランザクションが正常 に開始されたことを通知する応答パケットをサーバ 1100bから受信すると (ステップ S 16)、これで全ての応答パケットが揃ったので、サーバ制御部 1210はそれらの応答 パケットを互いに比較することでサーバ 1100に障害が発生している力否かをチェック する (ステップ S17)。この場合、 2つの応答パケットはともにトランザクションが正常に 開始されたことを示すパケットであるため、障害は無いと判断し応答パケットの 1つを クライアント 1500aへ転送する（ステップ S 18)。
[0092] 次に、クライアント 1500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S19)。サーバ制御部 1210は、受 信したクエリを送信キュー 1204に入れる。そして、送信キュー 1204から当該クエリを 取り出し、サーバ管理表 1201を見て正常稼働しているサーノ 、この場合、サーバ 11 00aと 100bへ該パケットを転送する（それぞれステップ S 110と S 111)。次いで、送 信キュー 1204の送信状態を「送信完了」にして当該エントリを削除する。サーバ 110 Oaは正常に UPDATE完了したことを通知する応答パケットを仲介装置 1200に送信 し、仲介装置 1200がこの応答パケットを受信する (ステップ S112)。この時点では全 ての応答パケットが全て揃っているわけではないので、サーバ制御部 1210は何もせ ず待機する。そして、正常に UPDATE完了したことを通知する応答パケットをサー ノ 1100bから受信すると (ステップ S 113)、これで応答パケットが全て揃ったので、サ ーバ制御部 1210はそれら応答パケットを互いに比較することでサーバ 1100に障害 が発生している力否かをチェックする（ステップ S 114)。この場合、 2つの応答パケット はともに UPDATE成功したことを示すパケットであるため、障害は無いと判断し応答 パケットの 1つをクライアント 1500aへ転送する（ステップ S 115)。
[0093] 次に、クライアント 1500aは、テーブル test— tableへの更新を確定する（実際にデ ータベースを更新する） SQL (COMMIT)を含んだパケットを 172.17.1.1へ送信する (ステップ S116)。サーバ制御部 1210は、受信したクエリを送信キュー 1204に入れ る。そして、送信キュー 1204から当該クエリを取り出し、サーバ管理表 1201を見て 正常稼働しているサーノ 、この場合、サーバ 1100aとサーバ 1100bへ該パケットを 転送する（それぞれステップ S 117と S 118)。次いで、送信キュー 1204の送信状態 を「送信完了」にして当該エントリを削除する。サーバ 1100aは正常に COMMIT完 了したことを通知するパケットを仲介装置 1200に送信し、仲介装置 1200がこの応答 パケットを受信する (ステップ S 119)。この時点では全ての応答パケットが全て揃って いるわけではないので、サーバ制御部 1210は何もせず待機する。そして、正常に C OMMIT完了したことを通知する応答パケットをサーバ 1100bから受信すると (ステツ プ S 120)、これで応答パケットが全て揃ったので、サーバ制御部 1210はそれら応答 パケットを互いに比較することでサーバ 1100に障害が発生している力否かをチェック する（ステップ S121)。この場合、 2つの応答パケットはともに COMMIT成功したこと を示すパケットであるため、障害は無いと判断する。 COMMITが正常に完了したこ と力ら、トランザクションが終了したことが分力るので、サーバ制御部 1210はトランザ クシヨン管理表 1202からこのトランザクションの登録を削除する (ステップ S122)。こ のときのトランザクション管理表 1202は再び初期状態 (すなわち空）になる。サーバ 制御部 1210は応答パケットの 1つをクライアント 1500aへ転送する（ステップ S 123)
[0094] 次に、サーバ 1100bが故障などで障害になった場合の動作を図 9から図 11を参照 して説明する。初期状態では、データベース 1101aと 101bは完全に同一であり、サ ーバ管理表 1201は前述した図 7のようになっているとする。また、トランザクション管 理表 1202と差分情報蓄積部 1203は空であるとする。
[0095] クライアント 1500aが 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を含んだ パケットを送信すると、仲介装置 1200はそのパケットを受信する (ステップ S130)。サ ーバ制御部 1210は、トランザクションが開始されたことを検知し、トランザクション管 理表 1202にクライアント 1500aの IPアドレスとトランザクション番号を登録する（ステツ プ S131)。図 10にこのときのトランザクション管理表 1202を示す。そして、このバケツ トに係るクエリを送信状態「未送信」で送信キュー 1204に入れる。
[0096] サーバ制御部 1210は、送信キュー 1204から当該「未送信」のクエリを取り出し、サ ーバ管理表 1201を見て正常稼働している全てのサーバ 1100、この場合、サーバ 1 100aと 100bへ該パケットを転送する（それぞれステップ S132と S133)。次いで、送 信キュー 1204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置 1 200は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ 11 00aから受信するが（ステップ S134)、この時点では、未だ全ての応答パケットが揃つ て！、るわけではな 、ので（この場合、サーバ 1100bからの応答パケットが来て!/ヽな!ヽ )、サーバ制御部 1210は何もせずにサーバ 1100bからの応答パケットを待つ。そし て、トランザクションが正常に開始されたことを通知する応答パケットをサーバ 1100b 力も受信すると (ステップ S135)、これで全ての応答パケットが揃ったので、サーバ制 御部 1210はそれら応答パケットを互 、に比較することでサーバ 1100に障害が発生 しているか否かをチェックする（ステップ S 136)。この場合、 2つの応答パケットはとも にトランザクションが正常に開始されたことを示すパケットであるため、障害は無いと 判断し応答パケットの 1つをクライアント 1500aへ転送する（ステップ S137)。
[0097] ここで、サーバ 1100bは、ステップ S135で応答パケットを返した後、故障などの障 害が発生してダウンしたものとする（ステップ S 138)。
[0098] 次に、クライアント 1500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S139)。サーバ制御部 1210は、受 信したクエリを送信キュー 1204に入れる。そして、送信キュー 1204から当該クエリを 取り出し、サーバ管理表 1201を見て正常稼働しているサーノ 、この場合、サーバ 11 00aと 100bへ該パケットを転送する（それぞれステップ S 140と S 141)。この時点で は、サーバ制御部 1210はサーバ 1100bのダウンを知らないので、サーノ 1100b力 S 正常稼働して 、ると 、う情報がサーバ管理表 1201に格納されたままである。、 、で 、送信キュー 1204の送信状態を「送信完了」にして当該エントリを削除する。サーバ 1100aは正常に UPDATE完了したことを通知する応答パケットを仲介装置 1200に 送信し、仲介装置 1200がこの応答パケットを受信する (ステップ S142)。この時点で は応答パケットが全て揃っているわけではないので、サーバ制御部 1210は何もせず 待機する。し力し、サーバ 1100bはダウンしているのでサーバ 1100bからの応答パ ケットはいつまで経っても仲介装置 1200には届かない。これによりサーバ制御部 12 10はタイムアウトし、サーバ 1100bのダウンを検知する。そして、サーバ制御部 1210 はサーバ管理表 1201のサーバ 1100bを activeから down (サーバ停止状態）に書き 換える（ステップ S143)。そのときのサーバ管理表 1201を図 11に示す。サーバ制御 部 1210は応答パケットをクライアント 1500aへ転送する（ステップ S 144)。ここでは、 クライアント 1500aにとつて、サーバ 1100bが障害になったかどうかは認識せず、今 までと同様に仮想サーバ 1800からサービスを受けることができることに注目すべきで ある。
[0099] 次に、クライアント 1500aは、テーブル test— tableへの更新を確定する SQL (CO MMIT)を含んだパケットを 172.17.1.1へ送信する（ステップ S 145)。サーバ制御部 1 210は、受信したクエリを送信キュー 1204に入れる。そして、送信キュー 1204から 当該クエリを取り出し、サーバ管理表 1201を見て正常稼働しているサーバ、この場 合、サーバ 1100aのみへ該パケットを転送する（ステップ S146)。次いで、送信キュ 一 1204の送信状態を「送信完了」にして当該エントリを削除する。サーバ 1100aは 正常に COMMIT完了したことを通知する応答パケットを送信し、仲介装置 1200が この応答パケットを受信する (ステップ S 147)。 COMMITが正常に完了したことから 、トランザクションが終了したことが分力るので、サーバ制御部 1210はトランザクション 管理表 1202からこのトランザクションの登録を削除する（ステップ S148)。このときの トランザクション管理表 1202は再び初期状態 (すなわち空）になる。サーバ制御部 1 210は応答パケットをクライアント 1500aへ転送する（ステップ S149)。
[0100] ここで、ステップ S146によって、サーバ 1100aのデータベース 1101aは、クライア ント 1500aからの UPDATE (ステップ S 139)が反映されて!、るのに対して、サーバ 1 100bのデータベース 110 lbにはクライアント 1500aからの UPDATE (ステップ S 13 9)が反映されていない、つまり、データベース 1101aとデータベース 1101bは非同 期状態になったことに注目すべきである。
[0101] 次に、サーバ 1100bが障害力も復旧しシステムに組み込む（追加する）場合の動作 を図 12から図 20を参照して説明する。このとき注目すべきポイントは、クライアント 15 00a及び 500bに対するサービスを続けたままサーバ 1100bを追加する、つまり、シ ステムダウンさせずにデータベース 1101aと 1101bを同期させることである。
[0102] データベース 1101bはデータベース 1101aと同期がとれていない状態、つまり、同 一ではない状態である。例えば、データベース 1101bは、図 9のステップ S138の障 害が起きる直前のデータを保持して 、る力もしれな 、し、全く新 、サーバの場合に は、データを全く持っていない状態力もしれない。本発明では、前者の場合でも古い データは削除し、データベース 110 lbはデータを全く保持して!/、な!/、ものとしてシス テムに組み込む。つまり、ステップ SI 38以前の古いデータを保持している必要はな い。
[0103] ここでは、サーバ管理表 1201は図 15のようになっているとする。また、トランザクシ ヨン管理表 1202と差分情報蓄積部 1203は空であるとする。
[0104] 図 12に示すように、クライアント 1500aが 172.17.1.1宛のトランザクション開始 SQL ( BEGIN)を含んだパケットを送信すると、仲介装置 1200はそのパケットを受信する（ ステップ S160)。サーバ制御部 1210は、トランザクションが開始されたことを検知し、 トランザクション管理表 1202にクライアント 1500aの IPアドレスとトランザクション番号 を登録する（ステップ S 161)。図 16にこのときのトランザクション管理表 1202を示す。 サーバ制御部 1210は、受信したクエリを送信キュー 1204に入れる。そして、送信キ ユー 1204から当該クエリを取り出し、サーバ管理表 1201を見て正常稼働しているサ ーノ 、この場合、サーバ 1100aへ該パケットを転送する（ステップ S162)。次いで、送 信キュー 1204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置 1 200は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ 11 00aから受信すると (ステップ S163)、応答パケットをクライアント 1500aへ転送する（ ステップ S 164)。
[0105] ここで、サーバ 1100bは電源を投入し起動されたものとする。これにより、サーバ 11 00bのデータベース制御部 1102bは、データベース同期化要求を仲介装置 1200 へ送信する（ステップ S 165)。
[0106] データベース同期化要求を受信したサーバ制御部 1210は、トランザクション管理 表 1202をチェックし現在実行中のトランザクションが存在するかどうかを確認するとと もに、実行中トランザクションの情報を記録しておく（ステップ S166)。図 16より、クラ イアント 1500a,トランザクション番号 3のトランザクションが実行中なので、データべ ース同期化動作はこのトランザクションの終了を待つと同時に、新しいトランザクション 開始要求を受け取った場合は、その要求をサーバ 1100aへ転送することを遅らせる (ステップ S167)。つまり、同期化動作は実行中のトランザクションが全くない状態で 始める。この新規トランザクションの開始要求についての転送遅延処理は、送信キュ 一 1204での保留と 、う手段で実現する。 [0107] 次に、クライアント 1500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S168)。サーバ制御部 1210は、受 信したクエリを送信キュー 1204に入れる。このクエリは前記ステップ S 166で記憶した トランザクション情報力 同期化要求時に実行していたトランザクションに属するものと 判定できるので、サーバ制御部 1210は、送信キュー 1204から当該クエリを取り出し 、サーバ管理表 1201を見て正常稼働しているサーノ 、この場合、サーバ 1100aへ 該パケットを転送する (ステップ S169)。次いで、送信キュー 1204の送信状態を「送 信完了」にして当該エントリを削除する。サーバ 1100aは正常に UPDATE完了した ことを通知する応答パケットを仲介装置 1200に送信し、仲介装置 1200がこの応答 パケットを受信する (ステップ S170)。サーバ制御部 1210は、応答パケットをクライア ント 1500aへ転送する（ステップ S 171)。
[0108] 次に、クライアント 1500bが 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を 含んだパケットを送信すると、仲介装置 1200はそのパケットを受信する (ステップ S1 72)。サーバ制御部 1210は、このパケットによりトランザクションが開始されたことを検 知し、トランザクション管理表 1202にクライアント 1500bの IPアドレスとトランザクショ ン番号を登録する（ステップ S 173)。図 17にこのときのトランザクション管理表 1202 を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー 1204に 入れる。しかし、この時点では同期化処理準備のため、新規トランザクション開始タエ リは送信キュー 1204に保持したままサーバ 1100aへは転送しな!、（ステップ S 174)
[0109] 次に、クライアント 1500aは、テーブル test— tableへの更新を確定する SQL (CO MMIT)を含んだパケットを 172.11.1.1へ送信する（ステップ S 175)。サーバ制御部 1 210は、受信したクエリを送信キュー 1204に入れる。このクエリは前記ステップ S 166 で記憶したトランザクション情報から同期化要求時に実行していたトランザクションに 属するものと判定できるので、サーバ制御部 1210は、送信キュー 1204から当該タエ リを取り出し、サーバ管理表 1201を見て正常稼働しているサ一ノ^この場合、サー ノ 1100aのみへ該パケットを転送する（ステップ S176)。次いで、送信キュー 1204 の送信状態を「送信完了」にして当該エントリを削除する。サーバ 1100aは正常に C OMMIT完了したことを通知する応答パケットを仲介装置 1200に送信し、仲介装置 1200がこの応答パケットを受信する（ステップ S177)。 COMMITが正常に完了した こと力 、トランザクションが終了したことが分力るので、サーバ制御部 1210はトラン ザクシヨン管理表 1202からこのトランザクションの登録を削除する (ステップ S 178)。 この時のトランザクション管理表 1202を図 18に示す。サーバ制御部 1210は応答パ ケットをクライアント 1500aへ転送する（ステップ S 179)。
[0110] ここで、新規サーバ 1100bからの同期化要求時に実行していたトランザクションが 全て無くなつたので、サーバ制御部 1210は同期化動作を開始する (ステップ S180) 。具体的には、図 13に示すように、まず、サーバ制御部 1210は、サーバ 1100aに対 して同期化指示 (スナップショット作成指示)のパケットを送信する (ステップ S181)。 なお、前記ステップ 180において、トランザクション管理表 1202に記録されているトラ ンザクシヨンが同期化要求時に実行中であったもの力、又は、その後にクライアント 1 500から受信したものかを判定するには、前記ステップ S166で記録しておいた同期 要求時のトランザクション情報を参照すればよい。
[0111] 同期化指示を受け取ったサーバ 1100aのデータベース制御部 1102aは、データ ベース 1101aのスナップショットを作り出す (ステップ S 182)。ここで、このスナップシ ヨットは、同期化指示を受け取った時点でのデータベース全体のバックアップデータ やデータベースを復元するための情報であり、同期化指示後の更新は反映されてい ないことに注目すべきである。
[0112] サーバ 1100aのデータベース制御部 1102aは、スナップショット作成が完了すると
(ステップ S 183)、その旨を仲介装置 1200へ通知する（ステップ S 184)。
[0113] データベース制御部 1102aは作成したスナップショットをサーバ 1100bへ転送し、 サーバ 1100bのデータベース制御部 1102bは、サーバ 1100aから受信したスナツ プショットからデータベースを復元する（ステップ S 185)。このスナップショットの転送 とデータベースの復元は、データベース i ioiaのサイズが大きければ大きいほど時 間が力かる力 クライアントからのデータベースアクセスと並行して実行されるのでクラ イアントに対するサービスを止めることはない。
[0114] スナップショット作成完了通知を受け取った仲介装置 1200のサーバ制御部 1210 は、クライアント 1500へのサービスを再開する。この場合、処理せずに送信キュー 12 04に保持して!/、た、クライアント 1500bからの BEGINを含んだパケットの処理を再開 する。すなわち、サーバ制御部 1210は、転送せずに保持していたクライアント 1500 bからの BEGIN SQLを含んだパケットを送信キュー 1204から取り出して差分情報 蓄積部 1203に保存するとともに (ステップ S 186)、サーバ 1100aへ転送する (ステツ プ S187)。次いで、送信キュー 1204の送信状態を「送信完了」にして当該エントリを 削除する。
[0115] なお、ここではステップ S187の処理をステップ S185の後に説明した力 ステップ S 185の動作 (スナップショットの転送）はクライアントへのサービスを妨げるものではな いので、スナップショットの転送中にステップ S187や後述のステップ S188が行われ てもよい。
[0116] サーバ 1100aは、トランザクションが正常に開始されたことを通知する応答パケット を仲介装置 1200に送信し、仲介装置 1200がこの応答パケットを受信する (ステップ S188)。仲介装置 1200は、この応答パケットをクライアント 1500bへ転送する (ステ ップ S 189)。
[0117] 次いで、クライアント 1500bがテーブル test_tableの更新 SQL (UPDATE)のパ ケットを仲介装置 1200に送信すると (ステップ S190)、サーバ制御部 1210は、受信 したクエリを送信キュー 1204に入れる。そして、送信キュー 1204から当該クエリを取 り出し、当該クエリを差分情報蓄積部 1203に保存するとともに (ステップ S191)、正 常稼働中のサーバ 1100aに当該パケットを送信する (ステップ S192)。次いで、送信 キュー 1204の送信状態を「送信完了」にして当該エントリを削除する。ここで、サーバ 1100aは UPDATEに失敗し、その旨を通知する応答パケットを仲介装置 1200に送 信したものとする (ステップ S 193)。仲介装置 1200は、この応答パケットをクライアン 卜 1500bに送信する（ステップ S 194)。
[0118] UPDATE失敗の応答パケットを受信したクライアント 1500bは、トランザクションを 取り消す SQL (ROLLBACK)のパケットを仲介装置に送信する（ステップ S195)。 サーバ制御部 1210は、受信したクエリを送信キュー 1204に入れる。そして、送信キ ユー 1204から当該クエリを取り出し、当該 SQLを差分情報蓄積部 1203に保存する とともに (ステップ S 196)、正常稼働中のサーバ 11 OOaに当該パケットを送信する（ス テツプ S197)。次いで、送信キュー 1204の送信状態を「送信完了」にして当該ェント リを削除する。そして、サーバ 1100aから正常にトランザクションが ROLLBACKされ たことを通知する応答パケットを受信すると (ステップ S198)、トランザクション管理表 1202から当該トランザクションの登録を削除するとともに (ステップ S199)、この応答 パケットをクライアント 1500bに送信する (ステップ S1100)。この時点での差分情報 蓄積部 1203を図 19に示す。また、トランザクション管理表 1202は空になる。
[0119] ここで、サーバ 1100bにおいてスナップショットからのデータベース 1101bの復元 が完了したものとする（ステップ S1101)。サーバ 1100bはデータベース 1101bの復 元が完了すると差分情報転送要求を仲介装置 1200に送信する (ステップ S1102)。 仲介装置 1200のサーバ制御部 1210は、差分情報転送要求を受信すると、図 14に 示すように、差分情報蓄積部 1203に蓄積されているデータを古いものから順にサー バ 1100bに転送する処理を開始する（ステップ S 1103)。
[0120] 前記ステップ S 1103で差分情報蓄積部 1203に蓄積されて 、る全てのクエリが転 送 ·処理されることでデータベース 1101aと 101bは完全に一致した状態（同期状態） になる力 この転送処理中にクライアント 1500から新たなクエリを受信する場合があ る。例えば、図 14に例示するように、仲介装置 1200は、クライアント 1500bから新規 トランザクションを開始するクエリ（BEGIN)を受信する (ステップ S 1104)。仲介装置 1200は、当該新規トランザクションをトランザクション管理表 1202に登録する (ステツ プ S1105)。そして、当該クエリを送信キュー 1204に入れる。次いで、送信キュー 20 4から当該クエリを取り出し、差分情報蓄積部 1203の最後に当該クエリを追加すると ともに（ステップ S 1106)、正常稼働中のサーバ 1100aに送信する（ステップ S 1107) 。そして、送信キュー 1204の送信状態を「送信完了」にして当該エントリを削除する。 次いで、サーバ 1100aから応答パケットを受信すると (ステップ S1108)、当該応答パ ケッ卜をクライアン卜 1500bに転送する（ステップ S 1109)。
[0121] このように差分情報転送中にクライアント 1500から受信したクエリは、正常稼働中 のサーバ 1100で処理するとともに、差分情報蓄積部 1203に蓄積していく。この処理 を継続していくと、やがて差分情報蓄積部 1203に蓄積されているクエリは全て新規 サーバ 1100bに転送され、差分情報蓄積部 1203は空になり、これを契機に差分情 報転送処理が終了する（ステップ SI 110)。これによりデータベース 1101aと 101bは 完全に一致した状態（同期状態）となるので、サーバ制御部 1210は、サーバ管理表 1201にサーバ 1100bを追加し稼働状態を activeとすることでシステムにサーバ 110 Obを追カロする（ステップ S1111)。この時のサーバ管理表 1201を図 20に示す。これ により、サーバ 1100bがシステムに組み込まれた状態となるので、以降の動作は図 6 を参照して前述したものと同様となる。
[0122] この手順を繰り返せば、もともとシステムに組み込まれていたが障害等のためにシス テム力も切り離されたサーバであっても、新規のサーバであっても、理論的にはいくら でも追加できる。つまり、追加できるサーバ数に制限はない。
[0123] 以上のように本実施の形態に係る多重化データベースシステムによれば、サーバ 1 100のデータベース 1101の記憶状況に拘わらず、サーバ 1100をシステムに組み込 むことができる。すなわち、元々システムに組み込まれていたが障害により切り離され たサーバ（ディスク障害によりデータを失ってしまったものなども含む)であっても、全 く新規のサーバであっても同様の手順でシステムに組み込むことができる。
[0124] また、仲介装置 1200においてデータ同期化用に差分情報蓄積部 1203に記憶す る同期化用データは、これから組み込むサーバ 1100からの組み込み要求を受信し て力も蓄積を開始するので、仲介装置 1200において同期化用データが増大するこ とがない。これにより、仲介装置 1200の記憶容量を節約でき、該記憶容量が溢れる ことによる障害発生を未然に防止できる。また、サーバ 1100の切り離しも任意に行う ことができる。
[0125] したがって、本実施の形態に係る多重化データベースシステムでは、サーバの組み 込み及び切り離しを任意に実施できるので、用途や予算などの要求に応じて柔軟な システム設計を行うことができる。
[0126] 本実施の形態の変形例について説明する。上記実施形態では、差分情報転送中 にクライアント 1500から新たなクエリを受信すると、当該クエリを差分情報蓄積部 120 3に追記していた。このような処理では、差分情報の処理に時間が力かる場合や、ク ライアントからの受信するクエリの受信間隔が短い場合には、差分情報蓄積部 1203 のデータが何時までたっても空にならな力つたり空になるまで長時間要することになり
、結果として新規サーバ 1100bの組み込み処理完了まで長時間要することが考えら れる。そこで、差分情報転送中に差分情報蓄積部 1203のエントリ数が所定数以下と なったら、新規クエリの処理を一時保留して専ら差分情報の転送のみを行って差分 情報蓄積部 1203を空にしてしまうと良い。以下、このような処理について図 21を参 照して説明する。
[0127] ここでは、新規のサーバ 1100bがスナップショットからデータベース 1101bの復元 処理中であるとする（ステップ S1200)。そして、サーバ 1100bにおいてデータべ一 ス 110 lbの復元処理が完了し (ステップ S 1201 )、サーノ 1100bが仲介装置 1200 に差分情報転送要求を送信した時点で (ステップ S 1202)、差分情報蓄積部 1203 には所定件数以上の差分情報が蓄積されているものとする。図 21の例では、ステツ プ S 1203〜ステップ S 1207による UPDATEのクエリが最新の差分情報として差分 情報蓄積部 1203に記憶されて 、るものとする。
[0128] 図 21に示すように、仲介装置 1200のサーバ制御部 1210は、サーバ 1100bから 差分情報転送要求を受信すると、前述したように、差分情報蓄積部 1203に記憶され ている各クエリを古いものから順にサーバ 1100bに転送する処理を開始する (ステツ プ S 1208)。
[0129] サーバ制御部 1210は、クライアント 1500bから新たなクエリを受信したとする。図 2 1の例では、サーバ制御部 1210は、クライアント 1500b力もデータを追加する SQL ( INSERT)を含むパケットを受信する (ステップ S 1209)。差分情報転送中に新規ク エリを受信したサーバ制御部 1210は、受信したクエリを送信キュー 1204に入れる。 そして、送信キュー 1204から当該クエリを取り出し、差分情報蓄積部 1203に蓄積さ れている未転送のクエリの件数が所定件数より多い場合には、このクエリを差分情報 蓄積部 1203の最後に追記するとともに (ステップ S 1210)、正常稼働中のサーバ 11 00aに該パケットを転送する (ステップ S1211)。次いで、送信キュー 1204の送信状 態を「送信完了」にして当該エントリを削除する。サーバ制御部 1210は、 INSERTが 成功したことを示す応答パケットをサーバ 1100aから受信すると (ステップ S 1212)、 この応答パケットをクライアント 1500bに転送する (ステップ S 1213)。 [0130] ここで、仲介装置 1200力もサーバ 1100bへの差分情報の転送は並行して行われ ており、これにより差分情報蓄積部 1203に記憶されている未転送のクエリが所定数 以下となったとする。
[0131] サーバ制御部 1210は、クライアント 1500b力もデータを更新する SQL (UPDATE )を含むパケットを受信すると (ステップ S 1214)、受信したクエリを送信キュー 1204 に入れる。ここでは、差分情報蓄積部 1203に蓄積されている未転送のクエリの件数 が所定件数以下となっているので、この新規クエリの処理は保留する (ステップ S121 5)。すなわち、この新規クエリの差分情報蓄積部 1203への記憶及びサーバ 1100a への転送は行わない。この保留処理は、差分情報蓄積部 1203に記憶されているク エリを全てサーバ 1100bに転送し、サーバ 1100bがシステムへ組み込まれるまで継 続する。
[0132] 差分情報の転送が終了すると (ステップ S1216)、差分情報蓄積部 1203に蓄積さ れている全てのクエリが転送.処理されることでデータベース 1101aと 101bは完全に 一致した状態（同期状態）になる。そこで、サーバ制御部 1210は、サーバ管理表 12 01にサーバ 1100bを追加し稼働状態を activeとすることでシステムにサーバ 1100b を追加する（ステップ S 1217)。
[0133] ここで、サーバ制御部 1210は、前記ステップ S1215で保留していた新規クエリの 処理を再開する。この時点では既に同期化が終了しているので、以降の処理は図 6 を参照して前述したものと同様となる。すなわち、サーバ制御部 1210は、当該クエリ を送信キュー 1204から取り出して正常稼働中のサーバ、この場合サーバ 1100a及 び 100b【こ転送する（ステップ S1218, S1219)。次!ヽで、送信キュー 1204の送信状 態を「送信完了」にして当該エントリを削除する。そして、各サーバ 1100a及び 100b 力も受信した応答パケットを比較して障害発生の有無をチェックし (ステップ SI 220 〜S1222)、正常な応答パケットの 1つをクライアント 1500bへ転送する（ステップ S1 223) o
[0134] このような処理により、差分情報の転送中にクライアントから受信したクエリは、未転 送の差分情報が所定数より多い場合には差分情報蓄積部 1203への記憶及びサー ノ 1100bへの転送が行われる。一方、未転送の差分情報が所定数以下の場合には 新規クエリは保留される。これにより、差分情報の処理に時間が力かる場合ゃクライア ントからの受信するクエリの受信間隔が短い場合であっても、データベースの同期を 短時間に行うことができる。なお、閾値となる「所定件数」は、大きく設定すると新規ク エリの保留時間が長くなる一方、小さく設定すると同期化処理完了までの時間が長 引くことになるというトレードオフの関係にある。したがって、この「所定件数」は各装置 の処理負荷やネットワーク速度などシステムの要件に応じて個々に最適な値を設定 すればよい。また、本変形例において閾値を 0以下に設定すれば、図 12〜図 20を 参照して前述した実施例と同様の処理となる。
[0135] (第 2の実施の形態）
本発明の第 2の実施の形態に係る多重化データベースシステムについて説明する 。本実施の形態に係る多重化データベースシステムが第 1の実施の形態と異なる点 は、仲介装置力 新規のサーバに転送する差分情報の内容にある。他の構成'動作 等については第 1の実施の形態と同様なので、ここでは相違点のみを説明する。
[0136] 第 1の実施の形態では差分情報蓄積部 1203にはクライアント 1500から受信した 全てのクエリを保存.転送していた。これにより、同期化処理を実施している間に正常 稼働中のサーバ 1100で処理されたクエリを、新規のサーバ 1100においても忠実に 再現することができるので、完全な同期化を図ることができる。
[0137] ところで、仲介装置力 新規のサーバに転送する差分情報は専ら同期処理用にの み用いられるので、該同期化において不要なクエリは転送する必要がない。具体的 には、参照系クエリの SQL (SELECT)は不要である。なお、ここでは、 SELECT F OR UPDATE文は、 SELECT文の一種であるが更新処理に影響を与えるので、 ここでは参照系クエリではなく更新系クエリとして取り扱うものとする。
[0138] そこで、本実施の形態では、第 1の実施の形態と異なり、クライアント 1500から受信 したクエリのうち、参照系クエリを除いたものを差分情報として新規のサーバ 1100に 転送する。例えば、クライアント 1500から図 22 (a)に示すような SQL文を受信したと すると、新規のサーバ 1100には図 22 (b)に示すような SQL文を転送してやればよい
[0139] このような処理を行うため、本実施の形態に係るサーバ制御部 1210は、第 1の実 施の形態と同様にクライアント 1500からクエリを受信した全てのクエリを差分情報蓄 積部 1203に記憶する。そして、差分情報を新規サーバ 1100に転送するにあたって 、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外を新規サーバ 110 0に転送する。他の処理については第 1の実施の形態と同様である。
[0140] 本実施の形態によれば、第 1の実施の形態と比較すると、新規サーバ 1100は同期 化処理時において参照系クエリを処理する必要がないので同期化処理の短縮ィ匕を 図ることができる。これは、複雑な参照系 SQLや集合関数を含む参照系 SQLなど処 理負荷が大きい参照系 SQLをクライアント 1500が発行している場合には特に有効 である。他の効果については第 1の実施の形態と同様である。
[0141] 本実施の形態の変形例としては、サーバ制御部 1210が、同期化処理中にクライァ ント 1500からクエリを受信し、このクエリを差分情報として差分情報蓄積部 1203に蓄 積するにあたって、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外 を差分情報蓄積部 1203に記憶する。そして、差分情報の転送は差分情報蓄積部 1 203に記憶されている全てのクエリを対象に行う方法が挙げられる。この変形例は、 差分情報蓄積部 1203の記憶容量をさらに節約できるという効果を有する。
[0142] (第 3の実施の形態）
本発明の第 3の実施の形態に係る多重化データベースシステムについて説明する 。本実施の形態に係る多重化データベースシステムが第 1の実施の形態と異なる点 は、データベース同期化動作中における差分情報の蓄積処理にある。他の構成'動 作等については第 1の実施の形態と同様なので、ここでは相違点のみを説明する。
[0143] 第 1の実施の形態では、サーバ制御部 1210は、クライアント 1500から受信した全 てのパケットを差分情報蓄積部 1203に保存していた。すなわち、トランザクション制 御 SQL、参照系 SQL及び更新系 SQLの全ての SQLについて差分情報蓄積部 120 3に保存し、サーバ 1100には差分情報蓄積部 1203に記憶されて 、る全てのデータ を古 、もの力 順に送信して 、た。
[0144] 一方、本実施の形態では、サーバ制御部 1210は、データベース同期化動作中に クライアント 1500から受信したパケットのうち、トランザクションの開始 SQL (BEGIN) や確定 SQL (COMMIT)や取消 SQL (ROLLBACK)等のトランザクション制御 SQ L、及び、 SELECTなど参照系の SQLについては保存せず、 UPDATEや INSER Tなどの更新系の SQLのうち正常稼働中のサーバ 1100で COMMITされたものの みを差分情報蓄積部 1203に保存する。
[0145] ここで注意すべき点は、差分情報蓄積部 1203には、クライアント 1500から受信し た順番ではなぐ正常稼働中のサーバ 1100で処理された順番に更新クエリを蓄積 することである。これは、更新対象が重複する更新クエリについては、その処理順序 によってデータベース 1101の内容が異なってしまう可能性があるためである。
[0146] このような処理を実現するために、本実施の形態では、図 23に示すような差分情報 一時蓄積部 1205を新たに設けた。この差分情報一時蓄積部 1205のデータ構造は 、差分情報蓄積部 1203と同様に、クライアントから受信したクエリと該クエリが属する トランザクションの IDとからなる。
[0147] サーバ制御部 1210は、同期化処理中にクライアント 1500からクエリを受信すると、 更新系のもののみを順次、差分情報一時蓄積部 1205に蓄積するとともに、正常稼 働中のサーバ 1100に転送する。一方、更新係以外のものについては、差分情報一 時蓄積部 1205に蓄積することなく正常稼働中のサーバ 1100に転送する。
[0148] ここで、サーバ制御部 1210は、正常稼働中のサーバ 1100から更新クエリの実行 が失敗したことを示す応答パケットを受信すると、当該更新クエリを差分情報一時蓄 積部 1205から削除する。また、正常稼働中のサーバ 1100からトランザクションの RO LLBACKが正常に完了したことを示す応答パケットを受信すると、サーバ制御部 12 10は、当該トランザクションに属する全ての更新クエリを差分情報一時蓄積部 1205 力も削除する。一方、正常稼働中のサーバ 1100からトランザクションの COMMITが 正常に終了した応答パケットを受信すると、サーバ制御部 1210は、当該トランザクシ ヨンに属する更新クエリについて差分情報一時蓄積部 1205から差分情報蓄積部 12 03に順次移動させる。
[0149] 以上のような処理により差分情報蓄積部 1203には、正常稼働中のサーバ 1100で COMMITされた更新クエリのみ力 その処理された順番で蓄積される。したがって、 後に新規サーバ 1100から差分情報転送要求があったら、差分情報蓄積部 1203に 記憶されて ヽる差分情報を蓄積されて ヽる順番で新規のサーバ 1100に転送すれば よい。なお、新規のサーバ 1100のデータベース 1101は、仲介装置 1200からの更 新クエリを順次処理するのみなので、この更新クエリはオートコミットモードで処理する
[0150] このように、本実施の形態によれば、同期化処理には不要の参照系クエリ、 BEGI Nや ROLLBACKなどのトランザクション制御 SQLを差分情報蓄積部 1203に蓄積 することがないので、第 1の実施形態と比較すると、差分情報の転送時間及びサーバ での処理時間を短縮ィ匕できる。他の効果については第 1の実施の形態と同様である
[0151] なお、本実施形態では、クライアント 1500から受信したクエリは、当該クエリの属す るトランザクションが正常稼働中のサーバ 1100で COMMITされた時点で、差分情 報一時記憶部 205から差分情報記憶部 203へ移動されて 、たが、その変形例として 、当該クエリが正常稼働中のサーバ 1100で正常処理された時点で移動するようにし てもよい。この場合には、トランザクションが ROLLBACKしたらら該トランザクション に属する更新クエリを差分情報記憶部 203から削除すればよい。このような処理は、 例えば PostgreSQLのように、更新順序によって行の順番が変わる DBMSのデータ ベースを完全一致させるために有効である。
[0152] (第 4の実施の形態）
本発明の第 4の実施の形態に係る多重化データベースシステムについて説明する 。本実施の形態に係る多重化データベースシステムが第 1の実施の形態と異なる点 は、差分情報蓄積部の構造にある。他の構成 ·動作等については第 1の実施の形態 と同様なので、ここでは相違点のみを説明する。
[0153] 本実施の形態に係る仲介装置 1200は、図 24に示すように、第 1の実施の形態とは 異なり差分情報蓄積部 1203は設けず、送信キュー 1206に第 1の実施形態における 差分情報蓄積部 1203と送信キュー 1204の機能を統合させて 、る。
[0154] 本実施の形態に係る送信キュー 1206のデータ構造について図 25を参照して説明 する。送信キュー 1206は、クライアント 1500から受信したクエリの内容と、そのクエリ の属するトランザクション IDと、各サーバ 1100への送信状態とを記憶する。トランザク シヨン IDは、第 1の実施の形態と同様に、トランザクション管理表 1202から取得され る。各サーバ 1100への送信状態は、システムに属する各サーバ 1100毎に記憶され る。
[0155] 送信キュー 1206の各サーバ 1100への送信状態は、「未送信」， 「送信完了」， 「保 留」の 3つの値を取りうる。「未送信」は、クライアント 1500から受信したクエリが未だ当 該サーバ 1100に送信されていない状態である。「送信完了」は、当該サーバ 1100 への送信が完了した状態である。「保留」は、新規サーバ 1100のシステムへの組み 込み処理中に、当該サーバ 1100への転送されることなく保留されて 、る状態である 。全てのサーバ 1100についての送信状態が「送信完了」になると、当該エントリは送 信キュー 1206から削除される。
[0156] 次に、サーバ制御部 1210の動作について説明する。サーバ制御部 1210は、クラ イアント 1500からクエリを受信すると、当該クエリがトランザクション開始 SQL (BEGI N)の場合は当該トランザクションに対して新たなトランザクション IDを振り出してトラン ザクシヨン管理表 1202に登録する。そして、当該クエリ内容，新規トランザクション ID ,各サーバ 1100の送信状態を「未送信」で送信キュー 1206に登録する。また、クラ イアント 1500から受信したクエリがトランザクション開始 SQL (BEGIN)以外の場合 は、当該クエリの属するトランザクション IDをトランザクション管理表 1202から取得し、 当該クエリ内容，トランザクション ID,各サーバ 1100の送信状態を「未送信」で送信 キュー 1206に登録する。
[0157] サーバ制御部 1210は、送信キュー 1206に記録されているクエリを、その送信状態 が「未送信」となって 、るサーバ 1100に対して送信し、当該サーバ 1100につ!/、ての 送信状態を「送信完了」に変更する。全てのサーバ 1100について送信状態が「送信 完了」になったクエリについては送信キュー 1206から削除する。
[0158] 仲介装置 1200からクエリを受信した各サーバ 1100は、当該クエリの処理を行い、 応答パケットを仲介装置 1200に返す。仲介装置 1200のサーバ制御部 1210は、各 サーバ 1100から受信した応答パケットを対比して障害発生の有無を確認し、正常な 応答パケットの 1つをクライアント 1500に返す。
[0159] 一方、サーバ 1100から正当でない応答が仲介装置 1200に返ってきたり、応答そ のものが返ってこない場合には、当該サーバ 1100に障害が発生したものとしてシス テム力も切り離す。具体的には、サーバ管理表 1201における当該サーバの稼働情 報を「down」に変更するとともに、送信キュー 1206の送信状態の欄について当該サ ーバに関する項目を削除する。図 26は、送信キュー 1206が図 25に示すような状態 でサーバ 1100bがシステム力も切り離された場合の送信キュー 1206の一例である。
[0160] 次に、新規サーバ 1100からシステムへの組み込み要求を受信した場合の動作に ついて説明する。サーバ制御部 1210は、第 1の実施の形態と同様に、組み込み要 求受信時に実行中のトランザクションが終了するまで、新規トランザクションの開始は 保留する。具体的には、クライアント 1500から受信したクエリが新規トランザクション に係るものの場合には、送信状態を「保留」として送信キュー 1206に保存する。一方 、クライアント 1500から受信したクエリが組み込み要求時に実行中のトランザクション に係るものの場合には、送信状態を「未送信」として送信キュー 1206に保存する。図 27は、送信キュー 1206が図 26に示すような状態でクライアント 1500から新たにタエ リを受信した場合の送信キュー 1206の一例である。図 27の例では、三行目のトラン ザクシヨン ID = 3の BEGINを除 、て上のクエリから順に（古!/、クエリから順に）、トラン ザクシヨン ID = 2の SELECT,トランザクション ID= 1の COMMIT,トランザクション I D = 2の COMMITの順に正常稼働中のサーバ 1100aへ転送され、その送信状態 が「未送信」から「送信完了」に変更される。トランザクション ID = 3の BEGINは、新規 のサーバ 1100bからスナップショット作成完了通知を受けた後に転送されることにな る。
[0161] そして、組み込み要求受信時に実行中のトランザクションに係るクエリを全て正常稼 働中のサーバ 1100に送信し終えると、サーバ制御部 1210は、送信キュー 1206に 組み込み対象である新規のサーバ 1100の項目を追加する。ここで、送信キュー 120 6には送信状態が「保留」となって 、るクエリが記憶されて 、る場合がある。この場合、 サーバ制御部 1210は、送信キュー 1206に記憶されているクエリーに対して、新規 サーバ 1100についての送信状態を「保留」とする。図 28は、図 27の送信キュー 120 6に対して新規サーバ 1100bの登録をした場合を示している。また、サーバ制御部 1 210は、組み込み要求受信時に実行中のトランザクションに係るクエリを全て正常稼 働中のサーバ 1100に送信し終えると、第 1の実施の形態と同様に、正常稼働中のサ ーバ 1100に対してスナップショットの作成指示を送出する。
[0162] サーバ制御部 1210は、正常稼働中のサーバ 1100からスナップショット作成完了 通知を受信すると、正常稼働中のサーバ 1100へのクエリの送信を再開する。具体的 には、まず送信キュー 1206に記憶されている全てのクエリ（この時点では全てのタエ リの送信状態は全てのサーバ 1100について「保留」になっている）について、正常稼 働中のサーバ 1100の送信状態を「未送信」に変更する。そして、サーバ制御部 121 0は、送信状態が「未送信」のクエリを当該サーバ 1100に順次送信し、送信が完了し たら送信状態を「送信完了」に修正する。また、新たにクライアント 1500から受信した クエリは、正常稼働中のサーバ 1100についての送信状態は「未送信」、新規のサー ノ 1100についての送信状態は「保留」にして送信キュー 1206に記憶する。図 29は 、図 28の送信キュー 1206に対してスナップショット完了通知受信後に新たなクエリを 受信した場合を示している。また、図 30のように、正常稼働中のサーバ 1100aに対し ては「送信完了」となっても新規のサーバ 1100bに対しては「送信完了」になって!/ヽ ない（「保留」になっている）ので、送信キュー 1206から当該クエリは削除しない。
[0163] 新規のサーバ 1100が正常稼働中のサーバ 1100から受信したスナップショットを用 いてデータベース 1101の復元が完了すると、サーバ制御部 1210は新規のサーバ 1 100から差分情報転送要求を受信する。サーバ制御部 1210は、送信キュー 1206 に記憶されて 、るクエリであって、送信状態が「保留」となって！/、るものを当該「保留」 となって!/、たサーバ 1100、すなわち新規のサーバ 1100に古 、ものから順次送信す る。送信したクエリについては、送信キュー 1206における当該サーバ 1100の送信 状態を「送信完了」にし、全てのサーバ 1100についての送信状態力 S「送信完了」に なったら当該エントリは削除する。
[0164] サーバ制御部 1210は、送信状態が「保留」となっているクエリが送信キュー 1206 に存在しなくなると、サーバ管理表 1201に新規のサーバ 1100を「active」として追 加することで、当該サーバ 1100をシステムに組み込む。以降の動作は各サーバ 110 0が正常動作して 、る場合のものと同様になる。
[0165] 以上のように本実施の形態に係る仲介装置 1200では、第 1の実施の形態における 差分情報蓄積部 1203と送信キュー 1204の機能を、 1つの送信キュー 1206に統合 しているので、メモリの利用効率や処理効率が向上する。また、送信キュー 1206の 各クエリに対して、各サーバ 1100への送信状態を記憶するようにしているので、新規 サーバ 1100を組み込む際には当該サーバ 1100の送信状態を追加すればよい。こ れにより、一度に複数台のサーバ 1100をシステムに組み込むことができる。他の作 用効果については第 1の実施の形態と同様である。
[0166] なお、本実施の形態は、第 1の実施の形態の変形例として説明したが、上記第 2〜 第 3の実施の形態において同様の変形を適用できることは言うまでもない。
[0167] (第 5の実施の形態）
本発明の第 5の実施の形態に係る多重化データベースシステムについて説明する 。本実施の形態に係る多重化データベースシステムが第 4の実施の形態と異なる点 は、差分情報の蓄積方法にある。他の構成'動作等については第 4の実施の形態と 同様なので、ここでは相違点のみを説明する。
[0168] 上述の第 1の〜第 4の実施の形態では、仲介装置 1200が正常稼働中のサーバ 11 00にスナップショットの作成指示を送信するタイミングは、正常稼働中のサーバ 110 0において実行中のトランザクションが無くなったときである。具体的には、新規サー ノ 1100からの組込要求を受信した時点で実行中のトランザクションについて正常稼 働中のサーバ 1100で処理を行うのと並行して、組込要求受信時以降にクライアント 1500から受信した新規トランザクションの開始要求を保留していた。そして、組込要 求を受信した時に実行中のトランザクションが無くなった時点で、スナップショットの作 成指示を送信している。これは、 DBMSによっては、スナップショット作成時にトラン ザクシヨンが実行中だと、そのトランザクションに属する更新クエリによるデータ更新が スナップショットに反映されるか否かが不確定となる場合を考慮したためである。
[0169] 一方、本実施の形態では、サーバ 1100として、スナップショット作成時に実行中の トランザクションに属する更新クエリ及びスナップショット作成処理中に受信した更新 クエリについては、当該スナップショットには反映しないという動作を行うものを用いる 。これにより、本実施の形態に係る仲介装置 1200のサーバ制御部 1210は、組込要 求受信時に実行中のトランザクションの終了を待つことなぐスナップショット作成指示 の送信及び新規トランザクションの開始を行うことができる。なお、仲介装置 1200が スナップショット作成完了を待つ必要がないので、サーバ 1100のデータベース制御 部 1102は、スナップショット作成が完了しても仲介装置 1200には完了通知を送信 する必要はない。
[0170] このような処理を行うため、本実施の形態に係る仲介装置 1200のサーバ制御部 12 10は、送信キュー 1206に記憶されている各クエリについて、全てのサーバ 1100に ついて送信状態が「送信完了」となり、且つ、当該クエリに属するトランザクションが終 了した場合に、当該クエリの登録を削除する。
[0171] 以下、新規サーバ 1100をシステムに組み込む際の動作について図 31〜図 35を 参照して説明する。いま、システムにはサーバ 1100aのみが組み込まれており、これ 力 新たにサーバ 1100bを組み込むものとする。
[0172] サーバ制御部 1210は、新規サーバ 1100bから組込要求を受信すると、正常稼働 中のサーバ 1100aに対して同期化指示 (スナップショット作成指示)を送信する。新 規サーバ 1100bが仲介装置 1200に対して組込要求を送信した際の送信キュー 12 06の一例を図 31に示す。前述したように、送信キュー 1206に記憶されたクエリは、 当該クエリが送信完了しても該クエリの属するトランザクションが完了して 、な 、もの は削除されずに残っている。同期化指示を受信したサーバ 1100aは、スナップショッ トの作成を開始する。ここで作成されるスナップショットは、送信キュー 1206に記憶さ れているクエリは反映されていないものである。また、サーバ制御部 1210は、新規サ ーバ 1100bから組込要求を受信すると、送信キュー 1206に記憶されて 、る全てのク エリについて、当該新規サーバ 1100bの送信状態を「保留」にして追加する。この時 の、送信キュー 1206の一例を図 32に示す。
[0173] サーバ制御部 1210は、組込要求受信時以降にクライアント 1500からクエリを受信 すると、正常稼働中のサーバ 1100aについては送信状態を「未送信」、新規サーバ 1 100bについては送信状態を「保留」にして送信キュー 1206に順次追加する。そして 、送信状態が「未送信」となって 、るクエリにつ 、ては当該「未送信」のサーバ 1100a に対して順次転送し、送信状態を「送信完了」に変更していく。このとき、図 33に示す ように、送信キュー 1206に記憶されているクエリは、正常稼働中のサーバ 1100aに ついてはトランザクション単位で送信状態が「送信完了」となっているが、新規サーバ 1100bにつ!/ヽては「保留」となって!/、るので、ここではクエリの削除は行わな!/、。
[0174] 一方、仲介装置 1200からスナップショットの作成指示を受信したサーバ 1100aは、 作成したスナップショットを新規のサーバ 1100bに送信する。新規のサーバ 1100b のデータベース制御部 1102bは、受信したスナップショットからデータベース 1101b を復元し、仲介装置 1200に差分情報転送要求を送信する。
[0175] 差分情報転送要求を受信したサーバ制御部 1210は、送信キュー 1206に記憶さ れて 、る送信状態が「保留」となって!/、るクエリを差分情報として順次新規サーバ 11 00bに送信し、図 34に示すように、送信状態を「送信完了」に変更する。そして、前述 したように、全てのサーバについて送信状態力 ^送信完了」となり、且つ、当該クエリ のトランザクションが完了したら、そのクエリを削除する。以降、送信状態が「保留」の クエリの中の送信中にクライアント 1500からクエリを受信すると、図 35に示すように、 正常稼働中のサーバ 1100a及び新規サーバ 1100bの双方の送信状態を「未送信」 で送信キュー 1206へ記憶する。そして、送信状態力 ^保留」のクエリが無くなった時 点でデータベース 100aとデータベース 100bの同期が完了したことになる。
[0176] 本実施形態によれば、システムで用いるサーバ 1100の機能的要件が限定される ためサーバ選択の幅が狭くなるものの、仲介装置 1200での処理が簡略ィ匕されるの で処理効率の高 、ものとなる。
[0177] なお、本実施の形態では、サーバ 1100として、 (1)トランザクション実行中でもスナ ップショットの作成開始ができ、（2)スナップショット作成中にクエリを処理可能であり 且つ当該クエリがスナップショットに反映されないものを用いた力 (1 ')トランザクショ ン実行中でもスナップショットの作成開始ができる力 （2')スナップショット作成中に はクエリを処理できな!/ヽ又はスナップショット作成中にクエリを処理すると当該処理が スナップショットに反映される場合があるようなサーバ 1100を用いることもできる。
[0178] ただし、この場合には、新規サーバ 1100から組込要求を受信すると直ちに正常稼 働中のサーバ 1100に対してスナップショット作成指示を送信してよいが、スナップシ ヨット作成完了までは正常稼働中のサーバ 1100に対するクエリの送信を保留する必 要がある。この保留処理の具体的な方法は上記第 1の実施の形態と同様であるので ここでは説明は省略する。また、仲介装置 1200がスナップショットの作成完了を認識 するために、スナップショットの作成が完了したサーバ 1100は、スナップショット作成 完了を仲介装置 1200に通知する必要がある。これにより、本実施の形態よりもサー バ選択の幅が広 、ものとなる。
[0179] 以上、本発明の実施形態について詳述したが、上記実施の形態は例示的なもので あり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に 示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれる ものである。
[0180] 例えば、各サーバは要求に応じて同じ応答をするならば同じ実装である必要はな い。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラォプ シヨン、ハードウェア力ソフトウェア力 などが異なっていてもよい。サーバには、 Post greSQLなどのフリーソフトウェアや Oracleなどの市販のソフトウェア、独自開発のソ フトウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サー ノ 1100aは PostgreSQLでサーバ 1100bは Oracleでも良い。
[0181] DBMSとしては、巿中品（例えば、 Oracleや PostgreSQL)を使う場合は、データ ベース制御部 1102は、データベース管理部とデータベースサーバ管理部に機能を 分けることによって、巿中品を無改造で使うことができる。データベース管理部は、デ ータベース 1101を直接操作するもので、例えば PostgreSQLの場合は postmaste rや postgresに相当する。データベースサーバ管理部は、仲介装置 1200とデータ ベース管理部の間に介在し、クエリの送受信を中継したりするほかに、他のサーバを 同期化する際のデータベース 1101のスナップショットを作成したり、そのスナップショ ットを他のサーバへ転送したりする処理を行う。
[0182] スナップショットの作成方法は、例えば DBMSが PostgreSQLならば pg— dumpな どのダンプツールやバックアップツールを使って実現する。なお、 pg— dumpは Post greSQLサーバ同士を同期化する場合には有用だ力 異種の DBMS同士 (例えば PostgreSQLと Oracle)を同期化する場合には、 DBMS固有のツールは使わずに、 正常稼働中の DBMSサーバから SELECTクエリで全てのデータを取りだし INSER Tクエリでデータを入れる汎用のツールを使えばよい。
[0183] また、上記実施の形態では、システムへの組み込み要求 (新規サーバのデータべ ース同期化要求）は当該新規サーバ 1100のデータベース制御部 1102が仲介装置 1200へ送信している力 保守端末などの他の装置力も送信してもよいし、オペレー タが仲介装置 1200に直接指示しても良 、。
[0184] さらに、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが 、ハードウェアで実装しても良い。
[0185] また、上記実施の形態では、仮想サーバ 1800を構成する仲介装置 1200は 1台の みであつたが、複数台設けて冗長性を持たせることにより、より可用性の高い構成と することも可能である。仲介装置を多重化させる技術については、例えば本願出願 人による特開 2003— 345679号公報に記載されたものなどを用いればよい。
[0186] (第 6の実施の形態）
本発明の第 6の実施の形態に係る多重化データベースシステムについて図面を参 照して説明する。図 37は本実施の形態に係る多重化データベースシステムの全体 構成を説明するブロック図である。
[0187] この多重化データベースシステムは、図 37に示すように、複数のデータベースサー バ（以下「サーバ」と言う） 100と仲介装置 2200とをネットワーク 2300で接続したもの であり、ネットワーク 2400を介して 1以上のクライアントコンピュータ（以下「クライアント 」と言う） 500からアクセスされるものである。本実施の形態では、図 37に示すように、 3台のサーノ 2100a, 2100b, 2100cを有しており、 2台のクライアン卜 2500a及び 2 500b力らアクセスされる。以降の説明にお ヽて各サーバ 2100を他のサーバ 2100と 区別する場合には添え字「a」「b」などの英小文字を付加するものとする。クライアント 2500につ!/ヽても同様である。なお、図 37の f列では、サーノ 2100とクライアント 2500 はそれぞれ別々のネットワーク 2300, 2400に接続されている力 同じネットワークに 接続されていてもよい。
[0188] 図 37に示すように、仲介装置 2200は、ネットワーク 2400側に IPアドレス 172.17.1.1 を持っており、これをデータベースサーバの IPアドレスとして公開している。クライアン ト 2500はデータベースにアクセスしたいときは IPアドレス 172.17.1.1へクエリを送信し 、 IPアドレス 172.17.1.1の仲介装置 2200からそのクエリに対する応答パケットを受信 する。これは、クライアント 2500にとつては、 IPアドレス 172.17.1.1を持ったデータべ ースサーバとパケットを送受信していることと同じである。この IPアドレス 172.17.1.1を 持った仮想的なデータベースサーバを仮想サーバ 2800と呼ぶ。この仮想サーバ 28 00の目的は、サーバ 2100が冗長化されていることを隠蔽するためである。つまり、全 てのサーノ 2100a,サーノ 2100b, 2100c力稼働して! /、ようと、サーノ 2100b力ダ ゥンしてサーバ 2100a及び 2100cのみが稼働していようと、サーノ 2100a, 2100b, 2100cの他に新たなサーバが追加されようとクライアントには影響は無く、動作を変 更する必要がない。
[0189] サーバ 2100は、データを保存'管理するデータベース 2101と、データベース 210 1の動作を制御するデータベース制御部 2102とを備えている。
[0190] データベース 2101は、 SQL (Structured Query Language)を解して処理を行う RD BMS (Relational Database Management System)である。このようなデータベース 21 01としては種々のものがあり、例えば The PostgreSQL Global Development Groupによる PostgreSQL (http://www.postgres.org/)や、 Oracle社による Oracl e (登録商標） (http://www.oracle.com)などが挙げられる。
[0191] データベース制御部 2102は、ネットワーク 2300を介して仲介装置 2200から送ら れてくるパケットに基づき動作する。このパケットは、 SQLなどデータベース 2101で の処理に係るもの、同期化処理に係るものに大別される。 SQLなどデータベース 21 01での処理に係るものについては、データベース制御部 2102は、当該パケットをデ ータベース 2101に渡し、データベース 2101からの処理結果を仲介装置 2200に返 す。
[0192] 一方、同期化処理に係るものは、さらに自身が本システムに組み込まれている場合 のものと、障害復旧時などこれからシステムに組み込む場合のものとに別れる。前者 については、スナップショットの作成指示がある。データベース制御部 2102は、スナ ップショット作成指示を仲介装置 2200から受信すると、データベース 2101のスナツ プショットを作成する。そして、作成したスナップショットを、スナップショット作成指示 で指示されている転送先の他のサーバ 2100に転送する。サーバ 2100はスナップシ ヨットの転送の後にシステムから一時的に切り離される。また、サーバ 2100は、スナツ プショットを転送すると、後述するように、やがて仲介装置 2200から差分情報を受信 する。この差分情報は、サーバ 2100が一時的にシステム力も切り離されている間に、 仲介装置 2200がクライアント 2500から受信した処理要求である。データベース制御 部 2102は、この差分情報を処理する。
[0193] 他方、障害復旧時などこれからシステムに組み込む場合、データベース制御部 21 02は、他のデータベースサーバ 2100からスナップショットを受信すると、このスナツ プショットを用いて自身のデータベース 2101を復元する。データベース 2101の復元 が完了すると仲介装置 2200に対して差分情報転送要求を送出する。後述するよう に、差分情報転送要求に応じて仲介装置 2200から差分情報が転送されるので、こ の差分情報を用 、てデータベース 2101を復元する。
[0194] また、データベース制御部 2102は、本システムに組み込む際には、仲介装置 220 0に対して組み込み要求を送信する。この組み込み要求は、サーバ 2100の起動時 や、必要に応じて任意のタイミングで送出する。
[0195] 仲介装置 2200は、本システム内のサーバ 2100を管理するサーバ管理表 2201と 、トランザクションを管理するトランザクション管理表 2202と、同期化用に差分情報を 蓄積する差分情報蓄積部 2203と、サーバ 2100に送信するクエリを一時保存する送 信キュー 2204と、クライアント 2500 ·サーバ 2100間での処理の仲介やサーバ 2100 の同期化制御などを行うサーバ制御部 2210とを備えている。
[0196] サーバ管理表 2201は、サーバが正常稼働中（active)か、障害などで停止してい る（down)力 同期化処理中（sync)かという状態を保存している。図 38にサーバ管 理表の一例を示す。サーバ管理表 2201は、図 38に示すように、サーバ 2100を識 別するためのサーバ IDと、サーバの稼働状態力も構成されている。図 38の例では、 サーバ 2100aとサーバ 2100bとサーバ 2100cが登録されており、稼働状態は共に 正常稼働を示す activeである。また、本実施形態では、サーバ IDとして各サーバ 21 00に付された IPアドレスを用いた。
[0197] トランザクション管理表 2202は、現在実行中の又は実行開始を保留されているトラ ンザクシヨンの有無を記憶する。図 39にトランザクション管理表 2202の一例を示す。 図 39に示すように、トランザクション管理表 2202は、クライアントを一意に識別するク ライアント IDとトランザクションを一意に識別するトランザクション ID力も構成される。こ れらのペアは、トランザクション開始時にトランザクション管理表 2202に登録され、トラ ンザクシヨン終了時にトランザクション管理表 2202から削除される。クライアント IDは 、例えばクライアント 2500の IPアドレスやポート番号である。トランザクション IDは新し いトランザクションが発生する毎にサーバ制御部 2210が新たに割り振る。
[0198] 差分情報蓄積部 2203は、サーバ同期化時にクライアント 2500から受信する全て のクエリを蓄積する。図 40に差分情報蓄積部 2203が蓄積している差分情報の一例 を示す。差分情報蓄積部 2203の各データは、図 40に示すように、クライアント 2500 が送信したクエリと、このクエリが所属するトランザクション IDとから構成される。トラン ザクシヨン IDはトランザクション管理表 2202から取得する。同期化処理時におけるク ライアント 2500からの新たなクエリは、この差分情報蓄積部 2203の最後に追加され る。つまり、上力も古いクエリが蓄積されている。図 40の例では、トランザクション ID = 1の BEGINが一番古ぐ COMMITが一番新しい。
[0199] 送信キュー 2204は、各クライアント 2500から受信したクエリを各サーバ 2100に送 信するまで一時的に保存するバッファメモリである。図 41に送信キュー 2204の一例 を示す。送信キュー 2204の各データは、図 41に示すように、クライアント 2500が送 信したクエリと、このクエリが所属するトランザクション IDと、サーバ 2100に送信したか 否かを表す送信情報とから構成される。トランザクション IDはトランザクション管理表 2 202力ら取得する。クライアント 2500からの新たなクエリは、この送信キュー 2204の 最後に追加される。つまり、上から古いクエリが蓄積されている。図 41の例では、トラ ンザクシヨン ID= 1の BEGINが一番古ぐトランザクション ID = 2の BEGINが一番新 しい。この送信キュー 2204の送信状態は、クライアント 2500からクエリを受信した際 には「未送信」が設定され、正常稼働中の全てのサーバ 2100に送信されると「送信 完了」が設定される。送信完了となったエントリは、直ちに又は所定期間経過後に送 信キュー 2204から削除される。
[0200] サーバ制御部 2210は、通常の処理（同期化処理時以外の処理）として、クライアン ト 2500からのパケットをネットワーク 2400経由で受信し、サーバ管理表 2201を見て 正常稼働している全てのサーバ 2100へ該パケットを転送する。ここで、サーバ 2100 へ転送するパケットは、送信キュー 2204に「未送信」として記憶されているクエリが対 象であり、送信キュー 2204に記憶されている古いクエリから順に転送される。そして 、サーバ 2100からのパケットをネットワーク 2300経由で受信し後述するパケットの正 当性判断方法により 1つ以上の該パケットのうち 1つを選出し 1つの正しいパケットを ネットワーク 2400を経由してクライアント 2500へ転送する。なお、同期化処理時には 、「未送信」のクエリであっても新規トランザクションに属するクエリは送信せず、実行 中のトランザクションに属するクエリのみを古い順に正常稼働中のサーバ 2100に送 信する。
[0201] ここで、サーバ制御部 2210は、クライアント 2500からの処理要求を解析してトラン ザクシヨンの開始と終了を検出してトランザクション管理表 2202を更新する。トランザ クシヨン開始と終了をサーバ制御部 2210が検出する方法は、 DBMSの種類によつ て異なる。例えば前述の PostgreSQLの場合は、トランザクションの開始はクライアン ト 2500力 S「BEGIN」という SQLを送信した時であり、トランザクションの終了はクライア ント 2500力 COMMIT」「ROLLBACK」という SQLを送信した時である。また、 Or acleの場合は、トランザクションの開始はクライアント 2500が有効な SQLを送信した ときであり（明示的なトランザクションの開始を宣言する SQLは無い）、トランザクション の終了はクライアント 2500が「COMMIT」「ROLLBACK」という SQLを送信した時 である。また、 AUTO COMMITモードで動作する場合には、クライアント 2500力 ら受信した SQL文はそれぞれ 1つの独立したトランザクションに属していると解釈でき るので、クライアント 2500から SQLを受信する毎に、該 SQL実行前にトランザクショ ンが開始されるとともに SQL実行後に当該トランザクションが終了したこととして扱うこ とがでさる。
[0202] また、パケットの正当性判断方法は、例えば、多数決で決める方法や、受信したパ ケットを所定のルールに基づいて判断する方法がある。例えば、クライアント 2500力 らの「参照」要求に対して「更新成功」 、う応答が返ってきた場合、正常であればそ のような応答はあり得ないので (参照成功など参照に関する応答のはず）、この応答 パケットは正しくないと判断する。また、パケット中にデータ長フィールドがある場合、 このデータ長フィールドの値と実際に受信したパケット長を比較し、異なる場合は正し くないと判断する。また、複数のサーバ 2100の中力も Masterサーバを予め 1台決め ておき、このサーバ 2100からのパケットを常に正しいと判断する。また、上記複数の 方法を併用する方法もある。例えば、 3台で多数決を行った結果、パケットの中身が 全てバラバラであり、多数派のパケットを決められない場合は Masterサーバのバケツ トを正しいと判断する。正常稼働しているサーバが 1つだけの場合は、そのサーバか らの応答パケットを正常と判断する。
[0203] サーバ制御部 2210は、正当ではない応答を送信したサーバ 2100は障害と判断し 、そのサーバ 2100につ 、てはサーバ管理表 2201から登録を削除することによりシ ステム力も切り離す。なお、応答を返してこないサーバ 2100も障害と判断する。
[0204] さらに、サーバ制御部 2210は、ネットワーク 2300を介してサーバ 2100からシステ ムの組み込み要求を受信すると、この新規のサーバ 2100と、正常稼働中のサーバ 2 100とを同期化させる処理を行う。以下にその処理にっ 、て説明する。
[0205] サーバ制御部 2210は、サーバ 2100からシステムの組み込み要求を受信すると、 正常稼働中の複数のサーバ 2100から 1つのサーバ 2100を選定し、このサーバ 210 0に対してスナップショットの作成指示を送出する。そして、スナップショットの作成指 示を送信したサーバ 2100については、サーバ管理表 2101の状態を「sync」に変更 することによりシステム力も切り離す。なお、以降の説明において、サーバ管理表 210 1の状態が「sync」となっているサーバ 2100を「同期化用サーバ 2100」と呼ぶことと する。また、状態が「active」となっているサーバ 2100を「正常稼働中のサーバ 2100 」と呼ぶこととする。
[0206] スナップショットの作成指示を送出するタイミングは、サーバ 2100においてトランザ クシヨンが実行中でないことが求められる。これはスナップショット作成中にトランザク シヨンが ROLLBACKするとデータの同期化が図れない場合があることを防止するた めや、 COMMITされて!/、な!/、ために更新データがスナップショットに反映されな！、こ とを防止するためである。このためサーバ制御部 2210は、処理中のトランザクション が終了するまでスナップショットの作成指示の送出を待つとともに、スナップショット作 成指示の送出までは新規トランザクションを開始しないようにしている。そして、新規ト ランザクシヨンに係る SQLについては、スナップショット作成指示の送信後に、正常稼 働中のサーバ 2100で処理するとともに、差分情報蓄積部 2203に蓄積する。差分情 報蓄積部 2203に蓄積するクエリは、トランザクション制御 SQL、参照系 SQL及び更 新系 SQLを含む全ての SQLが対象となる。
[0207] サーバ制御部 2210がスナップショットの作成指示を送出すると、当該スナップショ ットは新規のサーバ 2100に転送され、このサーバ 2100からサーバ制御部 2210に 対して差分情報転送要求が送出される。サーバ制御部 2210は、差分情報転送要求 を受信すると、新規のサーバ 2100及び同期化用サーバ 2100に対して、差分情報 蓄積部 2203に蓄積されているクエリを古いもの力も順次送信する。差分情報蓄積部 2203に蓄積されている SQLを全て送出すると、サーバ制御部 2210は、新規サーバ 2100及び同期化用サーバ 2100をシステムに組み込むべくサーバ管理表 2201を 更新する。
[0208] ここで、サーバ制御部 2210は、差分情報の送出中にクライアント 2500から新たな クエリを受信する場合があるが、この場合は当該クエリを差分情報蓄積部 2203の最 後に追加するとともに正常稼働中のサーバ 2100へ送信すれば良い。ただし、クライ アント 2500のクエリ送出頻度が高い場合などには、差分情報の送出終了まで、すな わち同期化終了まで長時間要する場合が考えられる。そこで、差分情報蓄積部 220 3における未送信の差分情報が所定件数以下となったら、クライアント 2500からのク エリを一時保留して差分情報の送出のみを行い、まず差分情報の送出を完了させる 。そして、前述のように新規サーバ 2100及び同期化用サーバ 2100をシステムに組 み込むべくサーバ管理表 2201を更新した後に、保留していたクエリ処理を再開する と好適である。
[0209] クライアント 2500は、データベースサーバ 2100に対して更新クエリ（データベース を更新するリクエスト)や参照クエリ（データベースの内容を参照するリクエスト）などを 発行するものである。
[0210] 次に、本実施の形態に係る多重化データベースシステムの動作について図面を参 照して説明する。まず、サーバ 2100a, 2100b, 2100cが正常に動作している場合 の動作を図 42から図 44を参照して説明する。
[0211] 初期状態では、データベース 2101aと 2101bと 2101cは完全に同一であり、サー バ管理表 2201は図 43のようになっているものとする。また、トランザクション管理表 2 202と差分†青報蓄積咅 2203は空であるとする。各サーノ 2100a, 2100b, 2100c には、テーブル test— tableが存在して!/、るとする。
[0212] クライアント 2500aが 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を含んだ パケットを送信すると、仲介装置 2200はそのパケットを受信する (ステップ S21)。サ ーバ制御部 2210は、トランザクションが開始されたことを検知し、トランザクション管 理表 2202にクライアント 2500aの IPアドレスとトランザクション番号を登録する（ステツ プ S22)。図 44にこのときのトランザクション管理表 2202を示す。そして、このパケット に係るクエリを送信状態「未送信」で送信キュー 2204に入れる。
[0213] サーバ制御部 2210は、送信キュー 2204から当該「未送信」のクエリを取り出し、サ ーバ管理表 2201を見て正常稼働している全てのサーバ 2100に該パケットを送信す る。この場合、サーノ 2100aと 2100bと 2100c力正常稼働しているので、サーバ制 御部 2210はサーバ 2100aとサーバ 2100bと 2100cへ該パケットを転送する（ステツ プ S23〜S25)。そして、各サーバ 2100への送信が完了したので送信キュー 2204 の送信状態を「送信完了」にして当該エントリを削除する。仲介装置 2200は、全ての サーバ 2100から応答パケットを受信 (ステップ S26〜S28)するまで待ち、全ての応 答パケットが揃ったら、各応答パケットを互いに比較することでサーバ 2100に障害が 発生している力否かをチェックする (ステップ S29)。この場合、 3つの応答パケットは 全てトランザクションが正常に開始されたことを示すパケットであるため、障害は無い と判断し応答パケットの 1つをクライアント 2500aへ転送する（ステップ S 210)。
[0214] 次に、クライアント 2500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S211)。サーバ制御部 2210は、受 信したクエリを送信キュー 2204に入れる。そして、送信キュー 2204から当該クエリを 取り出し、サーバ管理表 2201を見て正常稼働しているサーノ 、この場合、サーバ 21 00aと 2100bと 2100cへ該パケットを転送する（ステップ S212〜S214)。次いで、送 信キュー 2204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置 2 200は、全てのサーバ 2100力も応答パケットを受信 (ステップ S215〜S217)するま で待ち、全ての応答パケットが揃ったら、各応答パケットを互いに比較することでサー ノ 2100に障害が発生している力否かをチェックする (ステップ S218)。この場合、 3 つの応答パケットは全て UPDATE成功したことを示すパケットであるため、障害は無 いと判断し応答パケットの 1つをクライアント 2500aへ転送する（ステップ S219)。
[0215] 次に、クライアント 2500aは、テーブル test— tableへの更新を確定する（実際にデ ータベースを更新する） SQL (COMMIT)を含んだパケットを 172.17.1.1へ送信する (ステップ S220)。サーバ制御部 2210は、受信したクエリを送信キュー 2204に入れ る。そして、送信キュー 2204から当該クエリを取り出し、サーバ管理表 2201を見て 正常稼働しているサーノ 、この場合、サーノ 2100aとサーノ 2100bと 100cへ該ノ ケットを転送する (ステップ S221〜S223)。次いで、送信キュー 2204の送信状態を 「送信完了」にして当該エントリを削除する。仲介装置 2200は、全てのサーバ 2100 力も応答パケットを受信 (ステップ S224〜S226)するまで待ち、全ての応答パケット が揃ったら、各応答パケットを互いに比較することでサーバ 2100に障害が発生して いるか否かをチェックする（ステップ S227)。この場合、 3つの応答パケットは全て CO MMIT成功したことを示すパケットであるため、障害は無いと判断する。 COMMIT が正常に完了したことから、トランザクションが終了したことが分力るので、サーバ制御 部 2210はトランザクション管理表 2202からこのトランザクションの登録を削除する（ス テツプ S228)。このときのトランザクション管理表 2202は再び初期状態 (すなわち空） になる。サーバ制御部 2210は応答パケットの 1つをクライアント 2500aへ転送する（ ステップ S229)。
[0216] 次に、サーバ 2100bが故障などで障害になった場合の動作を図 45から図 47を参 照して説明する。初期状態では、データベース 2101a, 2101b, 2101cは完全に同 一であり、サーバ管理表 2201は前述した図 43のようになっているとする。また、トラン ザクシヨン管理表 2202と差分情報蓄積部 2203は空であるとする。
[0217] クライアント 2500aが 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を含んだ パケットを送信すると、仲介装置 2200はそのパケットを受信する (ステップ S230)。サ ーバ制御部 2210は、トランザクションが開始されたことを検知し、トランザクション管 理表 2202にクライアント 2500aの IPアドレスとトランザクション番号を登録する（ステツ プ S231)。図 46にこのときのトランザクション管理表 2202を示す。そして、このバケツ トに係るクエリを送信状態「未送信」で送信キュー 2204に入れる。
[0218] サーバ制御部 2210は、送信キュー 2204から当該「未送信」のクエリを取り出し、サ ーバ管理表 2201を見て正常稼働している全てのサーバ 2100、この場合、サーバ 2 100aと 2100bと 2100cへ該パケットを転送する（ステップ S232〜S234)。次いで、 送信キュー 2204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置 2200は、全てのサーバ 2100から応答パケットを受信（ステップ S235〜S237)する まで待ち、全ての応答パケットが揃ったら、各応答パケットを互いに比較することでサ ーバ 2100に障害が発生して 、る力否かをチェックする (ステップ S238)。この場合、 3つの応答パケットはともにトランザクションが正常に開始されたことを示すパケットで あるため、障害は無いと判断し応答パケットの 1つをクライアント 2500aへ転送する（ ステップ S239)。
[0219] ここで、サーバ 2100cは、ステップ S237で応答パケットを返した後、故障などの障 害が発生してダウンしたものとする（ステップ S240)。
[0220] 次に、クライアント 2500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S241)。サーバ制御部 2210は、受 信したクエリを送信キュー 2204に入れる。そして、送信キュー 2204から当該クエリを 取り出し、サーバ管理表 2201を見て正常稼働しているサーノ 、この場合、サーバ 21 00aと 2100bと 2100cへ該パケットを転送する（ステップ S242〜S244)。この時点で は、サーバ制御部 2210はサーバ 2100cのダウンを知らないので、サーバ 2100cが 正常稼働して 、ると 、う情報がサーバ管理表 2201に格納されたままである。、 、で 、送信キュー 2204の送信状態を「送信完了」にして当該エントリを削除する。サーバ 2100a及び 2100bは応答パケットを仲介装置 2200に送信し、仲介装置 2200がこ の応答パケットを受信する (ステップ S245, S246)。この時点では応答パケットが全 て揃っているわけではないので、サーバ制御部 2210は残りのサーバ 2100cからの 応答パケットを待つ。し力し、サーバ 2100cはダウンしているのでサーバ 2100cから の応答パケットは 、つまで経っても仲介装置 2200には届かな!/、。これによりサーバ 制御部 2210はタイムアウトし、サーバ 2100cのダウンを検知する。そして、サーバ制 御部 2210はサーバ管理表 2201のサーバ 2100cを activeから down (サーバ停止 状態）に書き換える (ステップ S247)。そのときのサーバ管理表 2201を図 47に示す 。また、ここでサーバ 2100a及び 2100bからの応答パケットを互いに比較することで サーバ 2100に障害が発生しているか否かをチェックする。この場合、 2つの応答パ ケットはともに UPDATE成功を示すパケットであるため、障害は無いと判断し、サー バ制御部 2210は応答パケットの 1つをクライアント 2500aへ転送する（ステップ S248 ) oここでは、クライアント 2500aにとつて、サーバ 2100cが障害になったかどうかは認 識せず、今までと同様に仮想サーバ 2800からサービスを受けることができることに注 目すべさである。
[0221] 次に、クライアント 2500aは、テーブル test— tableへの更新を確定する SQL (CO MMIT)を含んだパケットを 172.17.1.1へ送信する（ステップ S249)。サーバ制御部 2 210は、受信したクエリを送信キュー 2204に入れる。そして、送信キュー 2204から 当該クエリを取り出し、サーバ管理表 2201を見て正常稼働しているサーバ、この場 合、サーバ 2100a及び 2100bへ該パケットを転送する（ステップ S250, S251)。次 いで、送信キュー 2204の送信状態を「送信完了」にして当該エントリを削除する。仲 介装置 2200は、正常稼働中の各サーバ 2100a及び 2100bから応答パケットを受信 (ステップ S252, S253)するまで待ち、全ての応答パケットが揃ったら、各応答パケ ットを互いに比較することでサーバ 2100に障害が発生している力否かをチェックする (ステップ S254)。この場合、 2つの応答パケットはトランザクションが正常に開始され たことを示すパケットであるため、障害は無いと判断する。 COMMITが正常に完了 したことから、トランザクションが終了したことが分力るので、サーバ制御部 2210はトラ ンザクシヨン管理表 2202からこのトランザクションの登録を削除する (ステップ S255) 。このときのトランザクション管理表 2202は再び初期状態 (すなわち空）になる。サー バ制御部 2210は応答パケットの 1つをクライアント 2500aへ転送する（ステップ S256
) o
[0222] ここで、ステップ S250及び S51によって、サーノ 2100aと 2100bのデータベース 2 101a及び 2101bは、クライアント 2500aからの UPDATE (ステップ S249)が反映さ れているのに対して、サーバ 2100cのデータベース 2101cにはクライアント 2500aか らの UPDATE (ステップ S249)が反映されていない、つまり、データベース 2101a 及び 2101bとデータベース 2101cとは非同期状態になったことに注目すべきである
[0223] 次に、サーバ 2100cが障害力も復旧しシステムに組み込む（追加する）場合の動作 を図 48から図 56を参照して説明する。このとき注目すべきポイントは、クライアント 25 00a及び 2500bに対するサービスを続けたままサーバ 2100cを追加する、つまり、シ ステムダウンさせずに各データベース 2101a, 2101b, 2101cを同期させることであ る。
[0224] データベース 2101cはデータベース 2101a及び 2101bと同期がとれていない状 態、つまり、同一ではない状態である。例えば、データベース 2101cは、図 45のステ ップ S 240の障害が起きる直前のデータを保持して 、る力もしれな 、し、全く新 ヽサ ーバの場合には、データを全く持っていない状態力もしれない。本発明では、前者の 場合でも古いデータは削除し、データベース 2101cはデータを全く保持していない ものとしてシステムに組み込む。つまり、ステップ S 240以前の古いデータを保持して いる必要はない。
[0225] ここでは、サーバ管理表 2201は図 51のようになっているとする。また、トランザクシ ヨン管理表 2202と差分情報蓄積部 2203は空であるとする。
[0226] 図 48に示すように、クライアント 2500aが 172.17.1.1宛のトランザクション開始 SQL ( BEGIN)を含んだパケットを送信すると、仲介装置 2200はそのパケットを受信する（ ステップ S260)。サーバ制御部 2210は、トランザクションが開始されたことを検知し、 トランザクション管理表 2202にクライアント 2500aの IPアドレスとトランザクション番号 を登録する（ステップ S261)。図 52にこのときのトランザクション管理表 2202を示す。 サーバ制御部 2210は、受信したクエリを送信キュー 2204に入れる。そして、送信キ ユー 2204から当該クエリを取り出し、サーバ管理表 2201を見て正常稼働して 、るサ ーノ 、この場合、サーバ 2100a及び 2101bへ該パケットを転送する（ステップ S262, S263)。次いで、送信キュー 2204の送信状態を「送信完了」にして当該エントリを削 除する。仲介装置 2200は、応答パケットを各サーバ 2100から受信すると (ステップ S 264, S265)、各応答パケットを比較して障害有無をチェックし (ステップ S266)、正 当な応答パケットの 1つをクライアント 2500aへ転送する（ステップ S267)。 [0227] ここで、新規サーバ 2100cは電源を投入し起動されたものとする。これにより、サー ノ 2100cのデータベース制御部 2102cは、データベース同期化要求（糸且込要求）を 仲介装置 2200へ送信する (ステップ S 268)。
[0228] データベース同期化要求を受信したサーバ制御部 2210は、トランザクション管理 表 2202をチェックし現在実行中のトランザクションが存在するかどうかを確認するとと もに、実行中トランザクションの情報を記録しておく（ステップ S269)。図 52より、クラ イアント 2500a,トランザクション番号 3のトランザクションが実行中なので、データべ ース同期化動作はこのトランザクションの終了を待つと同時に、新しいトランザクション 開始要求を受け取った場合は、その要求をサーバ 2100へ転送することを遅らせる（ ステップ S270)。つまり、同期化動作は実行中のトランザクションが全くない状態で始 める。この新規トランザクションの開始要求についての転送遅延処理は、送信キュー 2204での保留と 、う手段で実現する。
[0229] 次に、クライアント 2500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S271)。サーバ制御部 2210は、受 信したクエリを送信キュー 2204に入れる。このクエリは前記ステップ S269で記憶した トランザクション情報を参照することで同期化要求時に実行していたトランザクション に属するものと判定できるので、サーバ制御部 2210は、送信キュー 2204から当該ク エリを取り出し、サーバ管理表 2201を見て正常稼働しているサ一ノ^この場合、サ ーバ 2100a及び 100bへ該パケットを転送する（ステップ S272, S273)。次いで、送 信キュー 2204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置 2 200は、正常稼働中の各サーバ 2100a及び 100bから応答パケットを受信 (ステップ S274, S275)するまで待ち、各応答パケットが揃うと該パケットから障害の有無を判 定する（ステップ S276)。そして、サーバ制御部 2210は、正当な応答パケットの 1つ をクライアント 2500aへ転送する（ステップ S277)。
[0230] 次に、クライアント 2500bが 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を 含んだパケットを送信すると、仲介装置 2200はそのパケットを受信する (ステップ S2 78)。サーバ制御部 2210は、このパケットによりトランザクションが開始されたことを検 知し、トランザクション管理表 2202にクライアント 2500bの IPアドレスとトランザクショ ン番号を登録する（ステップ S279)。図 53にこのときのトランザクション管理表 2202 を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー 2204に 入れる。しかし、この時点では同期化処理準備のため、新規トランザクション開始タエ リは送信キュー 2204に保持したまま、正常稼働中のサーバ 2100a, 2100bへは転 送しな 、（ステップ S 280)。
[0231] 次に、クライアント 2500aは、テーブル test— tableへの更新を確定する SQL (CO MMIT)を含んだパケットを 172.11.1.1へ送信する（ステップ3281)。サーバ制御部 2 210は、受信したクエリを送信キュー 2204に入れる。このクエリは前記ステップ S269 で記憶したトランザクション情報を参照することで同期化要求時に実行していたトラン ザクシヨンに属するものと判定できるので、サーバ制御部 2210は、送信キュー 2204 力も当該クエリを取り出し、サーバ管理表 2201を見て正常稼働しているサーバ、この 場合、サーバ 2100a及び 2100bへ該パケットを転送する（ステップ S282, S283)。 次いで、送信キュー 2204の送信状態を「送信完了」にして当該エントリを削除する。 仲介装置 2200は、正常稼働中の全てのサーバ 2100a及び 2100b力も応答パケット を受信 (ステップ S284, S285)するまで待ち、全ての応答パケットが揃ったら該パケ ットから障害の有無をチェックする（ステップ S286)。また、 COMMITが正常に完了 したことから、トランザクションが終了したことが分力るので、サーバ制御部 2210はトラ ンザクシヨン管理表 2202からこのトランザクションの登録を削除する（ステップ S287) 。この時のトランザクション管理表 2202を図 54に示す。サーバ制御部 2210は正当 な応答パケットの 1つをクライアント 2500aへ転送する（ステップ S288)。
[0232] ここで、新規サーバ 2100cからの同期化要求時に実行していたトランザクションが 全て無くなつたので、サーバ制御部 2210は同期化動作を開始する (ステップ S289) 。具体的には、まず、サーバ制御部 2210は、正常稼働中のサーバ 2100a及び 210 Obの中から同期化用サーバ 2100を 1つ選定する（ステップ S290)。本実施の形態 ではサーバ 2100bを選択したものとする。そして、同期化用サーバ 2100bに対して 同期化指示 (スナップショット作成指示)を送出する (ステップ S291)。また、サーバ管 理表 2201のサーバ 2100bについて状態を「sync」に変更する（ステップ S292)。こ の時のサーバ管理表 2201を図 55に示す。なお、前記ステップ S289において、トラ ンザクシヨン管理表 2202に記録されているトランザクションが同期化要求時に実行中 であったもの力、又は、その後にクライアント 2500から受信したものかを判定するに は、前記ステップ S269で記録してぉ 、た同期要求時のトランザクション情報を参照 すればよい。
[0233] 同期化指示を受け取った同期化用サーバ 2100bのデータベース制御部 2102bは
、データベース 2101bのスナップショットを作り出す (ステップ S293)。ここで、このス ナップショットは、同期化指示を受け取った時点でのデータベース全体のバックアツ プデータやデータベースを復元するための情報であり、同期化指示後の更新は反映 されて 、な 、ことに注目すべきである。
[0234] 同期化用サーバ 2100bのデータベース制御部 2102bは、スナップショット作成が 完了すると (ステップ S294)、作成したスナップショットを新規サーバ 2100cへ転送す る。このスナップショットの作成'転送とデータベースの復元は、データベース 2101b のサイズが大きければ大きいほど時間が力かる力 クライアントからのデータベースァ クセスは正常稼働中のサーバ 2100aで実行されるのでクライアントに対するサービス を止めることはない。
[0235] 新規サーバ 2100cのデータベース制御部 2102cは、同期化用サーバ 2100bから 受信したスナップショットからデータベースを復元する（ステップ S295)。
[0236] 仲介装置 2200のサーバ制御部 2210は、サーバ 2100bに対して同期化指示を送 信し（前記ステップ S291)、サーバ 2100bについてサーバ管理表 2201の状態を「sy nc」に変更すると（前記ステップ S292)、直ちに、クライアント 2500からの処理要求に 対する処理を再開する。ここで、クライアント 2500から処理要求を処理するサーバは 、状態が「active」のサーバ 2100aである。つまり、同期化用サーバ 2100bは、一時 的にシステム力 切り離され専ら同期化処理のみを行うことになる。また、ここでは、処 理せずに送信キュー 2204に保持して!/、た、クライアント 2500bからの BEGINを含ん だパケットの処理を再開する。すなわち、サーバ制御部 2210は、転送せずに保持し て 、たクライアント 2500bからの BEGIN SQLを含んだパケットを送信キュー 2204 力も取り出して差分情報蓄積部 2203に保存するとともに (ステップ S295)、正常稼 働中のサーバ 2100aへ転送する（ステップ S296)。次いで、送信キュー 2204の送 信状態を「送信完了」にして当該エントリを削除する。
[0237] 正常稼働中のサーバ 2100aは、応答パケットを仲介装置 2200に送信し、仲介装 置 2200がこの応答パケットを受信する（ステップ S297)。仲介装置 2200は、この応 答パケットをクライアント 2500bへ転送する（ステップ S298)。
[0238] 次!、で、クライアント 2500bがテーブル test_tableの更新 SQL (UPDATE)のパ ケットを仲介装置 2200に送信すると (ステップ S299)、サーバ制御部 2210は、受信 したクエリを送信キュー 2204に入れる。そして、送信キュー 2204から当該クエリを取 り出し、当該クエリを差分情報蓄積部 2203に保存するとともに (ステップ S2100)、正 常稼働中のサーバ 2100aに当該パケットを送信する (ステップ S2101)。次いで、送 信キュー 2204の送信状態を「送信完了」にして当該エントリを削除する。ここで、サ ーバ 2100aは UPDATEに失敗し、その旨を通知する応答パケットを仲介装置 220 0に送信したものとする (ステップ S2102)。仲介装置 2200は、この応答パケットをク ライアン卜 2500bに送信する（ステップ S2103)。
[0239] UPDATE失敗の応答パケットを受信したクライアント 2500bは、トランザクションを 取り消す SQL (ROLLBACK)のパケットを仲介装置に送信する（ステップ S2104)。 サーバ制御部 2210は、受信したクエリを送信キュー 2204に入れる。そして、送信キ ユー 2204から当該クエリを取り出し、当該 SQLを差分情報蓄積部 2203に保存する とともに (ステップ S2105)、正常稼働中のサーバ 2100aに当該パケットを送信する（ ステップ S2106)。次いで、送信キュー 2204の送信状態を「送信完了」にして当該ェ ントリを削除する。そして、サーバ 2100aから正常にトランザクションが ROLLBACK されたことを通知する応答パケットを受信すると (ステップ S2107)、トランザクション管 理表 2202から当該トランザクションの登録を削除するとともに (ステップ S2108)、こ の応答パケットをクライアント 2500bに送信する（ステップ S2109)。この時点での差 分情報蓄積部 2203を図 56に示す。また、トランザクション管理表 2202は空になる。
[0240] ここで、新規サーバ 2100cにおいてスナップショットからのデータベース 2101cの 復元が完了したものとする（ステップ S2110)。新規サーバ 2100cはデータベース 21 01cの復元が完了すると差分情報転送要求を仲介装置 2200に送信する (ステップ S 2111)。仲介装置 2200のサーバ制御部 2210は、差分情報転送要求を受信すると 、差分情報蓄積部 2203に蓄積されているデータを古いものから順に新規サーバ 21 OOc及び同期化用サーバ 2100bに転送する処理を開始する（ステップ S 2112)。
[0241] 前記ステップ S2112で差分情報蓄積部 2203に蓄積されている全てのクエリが転 送 ·処理されることでデータベース 2101aとデータベース 2101b及び 2101cとは完 全に一致した状態（同期状態）になるが、この転送処理中にクライアント 2500から新 たなクエリを受信する場合がある。例えば、図 50に示すように、仲介装置 2200は、ク ライアント 2500bから新規トランザクションを開始するクエリ（BEGIN)を受信する (ス テツプ S2113)。仲介装置 2200は、当該新規トランザクションをトランザクション管理 表 2202に登録する (ステップ S2114)。そして、当該クエリを送信キュー 2204に入 れる。次いで、送信キュー 2204から当該クエリを取り出し、差分情報蓄積部 2203の 最後に当該クエリを追加するとともに (ステップ S 2115)、正常稼働中のサーバ 2100 aに送信する (ステップ S2116)。そして、送信キュー 2204の送信状態を「送信完了」 にして当該エントリを削除する。次いで、サーバ 2100aから応答パケットを受信すると (ステップ S2117)、当該応答パケットをクライアント 2500bに転送する (ステップ S21 18)。
[0242] このように差分情報転送中にクライアント 2500から受信したクエリは、正常稼働中 のサーバ 2100で処理するとともに、差分情報蓄積部 2203に蓄積していく。この処理 を継続していくと、やがて差分情報蓄積部 2203に蓄積されているクエリは全て新規 サーバ 2100c及び同期化用サーバ 2100bに転送され、差分情報蓄積部 2203は空 になり、これを契機に差分情報転送処理が終了する (ステップ S2119)。これによりデ ータベース 2101aとデータベース 2101b及び 2101cは完全に一致した状態（同期 状態）となるので、サーバ制御部 2210は、サーバ管理表 2201に新規サーバ 2100c を追加し稼働状態を activeとするとともに、同期化用サーバ 2100bの稼働状態を act iveに変更することでシステムにサーバ 2100b及び 2100cを追加する（ステップ S 21 20)。この時のサーバ管理表 2201を図 57に示す。これにより、サーバ 2100cがシス テムに組み込まれた状態となるので、以降の動作は図 42を参照して前述したものと 同様となる。
[0243] この手順を繰り返せば、もともとシステムに組み込まれていたが障害等のためにシス テム力も切り離されたサーバであっても、新規のサーバであっても、理論的にはいくら でも追加できる。つまり、追加できるサーバ数に制限はない。
[0244] 以上のように本実施の形態に係る多重化データベースシステムによれば、サーバ 2 100のデータベース 2101の記憶状況に拘わらず、サーバ 2100をシステムに組み込 むことができる。すなわち、元々システムに組み込まれていたが障害により切り離され たサーバ（ディスク障害によりデータを失ってしまったものなども含む)であっても、全 く新規のサーバであっても同様の手順でシステムに組み込むことができる。
[0245] また、仲介装置 2200においてデータ同期化用に差分情報蓄積部 2203に記憶す る同期化用データは、これから組み込むサーバ 2100からの組み込み要求を受信し て力も蓄積を開始するので、仲介装置 2200において同期化用データが増大するこ とがない。これにより、仲介装置 2200の記憶容量を節約でき、該記憶容量が溢れる ことによる障害発生を未然に防止できる。また、サーバ 2100の切り離しも任意に行う ことができる。
[0246] したがって、本実施の形態に係る多重化データベースシステムでは、サーバの組み 込み及び切り離しを任意に実施できるので、用途や予算などの要求に応じて柔軟な システム設計を行うことができる。
[0247] さらに、サーバ 2100の組込処理の際には、正常稼働中の複数のサーバ 2100の中 力も同期化処理用のサーバ 2100を選定し、この同期化処理用サーバ 2100を用い てスナップショットの作成 ·転送を行っているので、これと並行してクライアント 2500か らの処理要求を正常稼働中の他のサーバ 2100を用いて処理できる。したがって、組 込処理とクライアントからの処理要求に係る処理が異なるサーバで処理されるので負 荷が分散されるとともに、スナップショットの作成中にもクライアント 2500からの処理 要求に応じることができるので、クライアント 2500に対して円滑なサービスの提供を 継続できる。
[0248] 本実施の形態の変形例について説明する。上記実施形態では、差分情報転送中 にクライアント 2500から新たなクエリを受信すると、当該クエリを差分情報蓄積部 220 3に追記していた。このような処理では、差分情報の処理に時間が力かる場合や、ク ライアントからの受信するクエリの受信間隔が短い場合には、差分情報蓄積部 2203 のデータが何時までたっても空にならな力つたり空になるまで長時間要することになり
、結果として新規サーバ 2100cの組み込み処理完了まで長時間要することが考えら れる。そこで、差分情報転送中に差分情報蓄積部 2203のエントリ数が所定数以下と なったら、新規クエリの処理を一時保留して専ら差分情報の転送のみを行って差分 情報蓄積部 2203を空にしてしまうと良い。以下、このような処理について図 58を参 照して説明する。
[0249] ここでは、新規のサーバ 2100cがスナップショットからデータベース 2101cの復元 処理中であるとする（ステップ S2200)。そして、サーバ 2100cにおいてデータべ一 ス 2101cの復元処理が完了し (ステップ S2201)、サーバ 2100cが仲介装置 2200 に差分情報転送要求を送信した時点で (ステップ S2202)、差分情報蓄積部 2203 には所定件数以上の差分情報が蓄積されているものとする。図 58の例では、ステツ プ S2203〜ステップ S2207による UPDATEのクエリが最新の差分情報として差分 情報蓄積部 2203に記憶されているものとする。
[0250] 図 58に示すように、仲介装置 2200のサーバ制御部 2210は、サーバ 2100cから 差分情報転送要求を受信すると、前述したように、差分情報蓄積部 2203に記憶され ている各クエリを古いものから順に新規サーバ 2100c及び同期化用サーバ 2100b に転送する処理を開始する (ステップ S2208)。
[0251] サーバ制御部 2210は、クライアント 2500bから新たなクエリを受信したとする。図 5 8の例では、サーバ制御部 2210は、クライアント 2500b力もデータを追加する SQL ( INSERT)を含むパケットを受信する (ステップ S 2209)。差分情報転送中に新規ク エリを受信したサーバ制御部 2210は、受信したクエリを送信キュー 2204に入れる。 そして、送信キュー 2204から当該クエリを取り出し、差分情報蓄積部 2203に蓄積さ れている未転送のクエリの件数が所定件数より多い場合には、このクエリを差分情報 蓄積部 2203の最後に追記するとともに (ステップ S2210)、正常稼働中のサーバ 21 00aに該パケットを転送する (ステップ S2211)。次いで、送信キュー 2204の送信状 態を「送信完了」にして当該エントリを削除する。サーバ制御部 2210は、 INSERTが 成功したことを示す応答パケットをサーバ 2100aから受信すると (ステップ S2212)、 この応答パケットをクライアント 2500bに転送する (ステップ S 2213)。 [0252] ここで、仲介装置 2200から新規サーバ 2100c及び同期化用 2100bへの差分情報 の転送は並行して行われており、これにより差分情報蓄積部 2203に記憶されている 未転送のクエリが所定数以下となったとする。
[0253] サーバ制御部 2210は、クライアント 2500b力もデータを更新する SQL (UPDATE )を含むパケットを受信すると (ステップ S2214)、受信したクエリを送信キュー 2204 に入れる。ここでは、差分情報蓄積部 2203に蓄積されている未転送のクエリの件数 が所定件数以下となっているので、この新規クエリの処理は保留する (ステップ S221 5)。すなわち、この新規クエリの差分情報蓄積部 2203への記憶及び正常稼働中の サーバ 2100aへの転送は行わない。この保留処理は、差分情報蓄積部 2203に記 憶されているクエリを全て新規サーバ 2100c及び同期化用サーバ 2100bに転送し、 両サーバ 2100b及び 2100cがシステムへ組み込まれるまで継続する。
[0254] 差分情報の転送が終了すると (ステップ S2216)、差分情報蓄積部 2203に蓄積さ れている全てのクエリが転送.処理されることでデータベース 2101aとデータベース 2 101b及び 2101cは完全に一致した状態（同期状態）になる。そこで、サーバ制御部 2210は、サーバ管理表 2201にサーバ 2100cを追加し稼働状態を activeとするとと もに、同期化用サーバ 2100bの稼働状態も activeにすることでシステムにサーバ 21 00b及び 2100cを追カロする（ステップ S2217)。
[0255] ここで、サーバ制御部 2210は、前記ステップ S2215で保留していた新規クエリの 処理を再開する。この時点では既に同期化が終了しているので、以降の処理は図 42 を参照して前述したものと同様となる。すなわち、サーバ制御部 2210は、当該クエリ を送信キュー 2204から取り出して正常稼働中のサーノ 、この場合サーバ 2100a, 2 100b, 2100c【こ転送する（ステップ S2218, S2219, S2220)。次!/ヽで、送信キュ 一 2204の送信状態を「送信完了」にして当該エントリを削除する。そして、各サーバ 2100a, 2100b, 2100cから受信した応答パケットを比較して障害発生の有無をチ エックし (ステップ S2221〜S2224)、正常な応答パケットの 1つをクライアント 2500b へ転送する（ステップ S 2225)。
[0256] このような処理により、差分情報の転送中にクライアントから受信したクエリは、未転 送の差分情報が所定数より多い場合には差分情報蓄積部 2203への記憶並びに正 常稼働中のサーバ 2100aへの転送が行われる。一方、未転送の差分情報が所定数 以下の場合には新規クエリは保留される。これにより、差分情報の処理に時間がかか る場合やクライアントからの受信するクエリの受信間隔が短い場合であっても、データ ベースの同期を短時間に行うことができる。なお、閾値となる「所定件数」は、大きく設 定すると新規クエリの保留時間が長くなる一方、小さく設定すると同期化処理完了ま での時間が長引くことになるというトレードオフの関係にある。したがって、この「所定 件数」は各装置の処理負荷やネットワーク速度などシステムの要件に応じて個々に 最適な値を設定すればよい。また、本変形例において閾値を 0以下に設定すれば、 図 48〜図 57を参照して前述した実施例と同様の処理となる。
[0257] (第 7の実施の形態）
本発明の第 7の実施の形態に係る多重化データベースシステムについて説明する 。本実施の形態に係る多重化データベースシステムが第 6の実施の形態と異なる点 は、仲介装置力 新規のサーバ及び同期化用サーバに転送する差分情報の内容に ある。他の構成'動作等については第 6の実施の形態と同様なので、ここでは相違点 のみを説明する。
[0258] 第 6の実施の形態では差分情報蓄積部 2203にはクライアント 2500から受信した 全てのクエリを保存.転送していた。これにより、同期化処理を実施している間に正常 稼働中のサーバ 2100で処理されたクエリを、新規のサーバ 2100及び同期化用サ ーバ 2100においても忠実に再現することができるので、完全な同期化を図ることが できる。
[0259] ところで、仲介装置力 新規のサーバ及び同期化用サーバに転送する差分情報は 専ら同期処理用にのみ用いられるので、該同期化において不要なクエリは転送する 必要がない。具体的には、参照系クエリの SQL (SELECT)は不要である。なお、こ こでは、 SELECT FOR UPDATE文は、 SELECT文の一種であるが更新処理 に影響を与えるので、ここでは参照系クエリではなく更新系クエリとして取り扱うものと する。
[0260] そこで、本実施の形態では、第 6の実施の形態と異なり、クライアント 2500から受信 したクエリのうち、参照系クエリを除いたものを差分情報として新規のサーバ 2100及 び同期化用サーバ 2100に転送する。例えば、クライアント 2500から図 59 (a)に示す ような SQL文を受信したとすると、新規のサーバ 2100及び同期化用サーバ 2100に は図 59 (b)に示すような SQL文を転送してやればょ 、。
[0261] このような処理を行うため、本実施の形態に係るサーバ制御部 2210は、第 6の実 施の形態と同様にクライアント 2500からクエリを受信した全てのクエリを差分情報蓄 積部 2203に記憶する。そして、差分情報を新規サーバ 2100及び同期化用サーバ に転送するにあたって、まず該クエリが参照系クエリであるかを判別し、参照系クエリ 以外を新規サーバ 2100及び同期化用サーバ 2100に転送する。他の処理につ ヽて は第 6の実施の形態と同様である。
[0262] 本実施の形態によれば、第 6の実施の形態と比較すると、新規サーバ 2100及び同 期化用サーバ 2100は同期化処理時において参照系クエリを処理する必要がないの で同期化処理の短縮ィ匕を図ることができる。これは、複雑な参照系 SQLや集合関数 を含む参照系 SQLなど処理負荷が大きい参照系 SQLをクライアント 2500が発行し ている場合には特に有効である。他の効果については第 6の実施の形態と同様であ る。
[0263] 本実施の形態の変形例としては、サーバ制御部 2210が、同期化処理中にクライァ ント 2500からクエリを受信し、このクエリを差分情報として差分情報蓄積部 2203に蓄 積するにあたって、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外 を差分情報蓄積部 2203に記憶する。そして、差分情報の転送は差分情報蓄積部 2 203に記憶されている全てのクエリを対象に行う方法が挙げられる。この変形例は、 差分情報蓄積部 2203の記憶容量をさらに節約できるという効果を有する。
[0264] (第 8の実施の形態）
本発明の第 8の実施の形態に係る多重化データベースシステムについて説明する 。本実施の形態に係る多重化データベースシステムが第 6の実施の形態と異なる点 は、データベース同期化動作中における差分情報の蓄積処理にある。他の構成'動 作等については第 6の実施の形態と同様なので、ここでは相違点のみを説明する。
[0265] 第 6の実施の形態では、サーバ制御部 2210は、クライアント 2500から受信した全 てのパケットを差分情報蓄積部 2203に保存していた。すなわち、トランザクション制 御 SQL、参照系 SQL及び更新系 SQLの全ての SQLについて差分情報蓄積部 220 3に保存し、サーバ 2100には差分情報蓄積部 2203に記憶されている全てのデータ を古 、もの力 順に送信して 、た。
[0266] 一方、本実施の形態では、サーバ制御部 2210は、データベース同期化動作中に クライアント 2500から受信したパケットのうち、トランザクションの開始 SQL (BEGIN) や確定 SQL (COMMIT)や取消 SQL (ROLLBACK)等のトランザクション制御 SQ L、及び、 SELECTなど参照系の SQLについては保存せず、 UPDATEや INSER Tなどの更新系の SQLのうち正常稼働中のサーバ 2100で COMMITされたものの みを差分情報蓄積部 2203に保存する。
[0267] ここで注意すべき点は、差分情報蓄積部 2203には、クライアント 2500から受信し た順番ではなぐ正常稼働中のサーバ 2100で処理された順番に更新クエリを蓄積 することである。これは、更新対象が重複する更新クエリについては、その処理順序 によってデータベース 2101の内容が異なってしまう可能性があるためである。
[0268] このような処理を実現するために、本実施の形態では、図 60に示すような差分情報 一時蓄積部 2205を新たに設けた。この差分情報一時蓄積部 2205のデータ構造は 、差分情報蓄積部 2203と同様に、クライアントから受信したクエリと該クエリが属する トランザクションの IDとからなる。
[0269] サーバ制御部 2210は、同期化処理中にクライアント 2500からクエリを受信すると、 更新系のもののみを順次、差分情報一時蓄積部 2205に蓄積するとともに、正常稼 働中のサーバ 2100に転送する。一方、更新系以外のものについては、差分情報一 時蓄積部 2205に蓄積することなく正常稼働中のサーバ 2100に転送する。
[0270] ここで、サーバ制御部 2210は、正常稼働中のサーバ 2100から更新クエリの実行 が失敗したことを示す応答パケットを受信すると、当該更新クエリを差分情報一時蓄 積部 2205から削除する。また、正常稼働中のサーバ 2100からトランザクションの RO LLBACKが正常に完了したことを示す応答パケットを受信すると、サーバ制御部 22 10は、当該トランザクションに属する全ての更新クエリを差分情報一時蓄積部 2205 力も削除する。一方、正常稼働中のサーバ 2100からトランザクションの COMMITが 正常に終了した応答パケットを受信すると、サーバ制御部 2210は、当該トランザクシ ヨンに属する更新クエリについて差分情報一時蓄積部 2205から差分情報蓄積部 22 03に順次移動させる。
[0271] 以上のような処理により差分情報蓄積部 2203には、正常稼働中のサーバ 2100で COMMITされた更新クエリのみ力 その処理された順番で蓄積される。したがって、 後に新規サーバ 2100から差分情報転送要求があったら、差分情報蓄積部 2203に 記憶されている差分情報を蓄積されている順番で新規のサーバ 2100及び同期化用 サーバ 2100に転送すればよい。なお、新規のサーバ 2100及び同期化用サーバ 21 00のデータベース 2101は、仲介装置 2200からの更新クエリを順次処理するのみな ので、この更新クエリはオートコミットモードで処理する。
[0272] このように、本実施の形態によれば、同期化処理には不要の参照系クエリ、 BEGI Nや ROLLBACKなどのトランザクション制御 SQLを差分情報蓄積部 2203に蓄積 することがないので、第 6の実施形態と比較すると、差分情報の転送時間及びサーバ での処理時間を短縮ィ匕できる。他の効果については第 6の実施の形態と同様である
[0273] なお、本実施形態では、クライアント 2500から受信したクエリは、当該クエリの属す るトランザクションが正常稼働中のサーバ 2100で COMMITされた時点で、差分情 報一時記憶部 205から差分情報記憶部 203へ移動されて 、たが、その変形例として 、当該クエリが正常稼働中のサーバ 2100で正常処理された時点で移動するようにし てもよい。この場合には、トランザクションが ROLLBACKしたらら該トランザクション に属する更新クエリを差分情報記憶部 203から削除すればよい。このような処理は、 例えば PostgreSQLのように、更新順序によって行の順番が変わる DBMSのデータ ベースを完全一致させるために有効である。
[0274] (第 9の実施の形態）
本発明の第 9の実施の形態に係る多重化データベースシステムについて説明する 。本実施の形態に係る多重化データベースシステムが第 6の実施の形態と異なる点 は、差分情報蓄積部の構造にある。他の構成 ·動作等については第 6の実施の形態 と同様なので、ここでは相違点のみを説明する。
[0275] 本実施の形態に係る仲介装置 2200は、図 61に示すように、第 6の実施の形態とは 異なり差分情報蓄積部 2203は設けず、送信キュー 2206に第 6の実施形態における 差分情報蓄積部 2203と送信キュー 2204の機能を統合させている。
[0276] 本実施の形態に係る送信キュー 2206のデータ構造について図 62を参照して説明 する。送信キュー 2206は、クライアント 2500から受信したクエリの内容と、そのクエリ の属するトランザクション IDと、各サーバ 2100への送信状態とを記憶する。トランザク シヨン IDは、第 6の実施の形態と同様に、トランザクション管理表 2202から取得され る。各サーバ 2100への送信状態は、システムに属する各サーバ 2100毎に記憶され る。
[0277] 送信キュー 2206の各サーバ 2100への送信状態は、「未送信」， 「送信完了」， 「保 留」の 3つの値を取りうる。「未送信」は、クライアント 2500から受信したクエリが未だ当 該サーバ 2100に送信されていない状態である。「送信完了」は、当該サーバ 2100 への送信が完了した状態である。「保留」は、新規サーバ 2100のシステムへの組み 込み処理中に、当該サーバ 2100への転送されることなく保留されている状態である 。全てのサーバ 2100についての送信状態が「送信完了」になると、当該エントリは送 信キュー 2206から削除される。
[0278] 次に、サーバ制御部 2210の動作について説明する。サーバ制御部 2210は、クラ イアント 2500からクエリを受信すると、当該クエリがトランザクション開始 SQL (BEGI N)の場合は当該トランザクションに対して新たなトランザクション IDを振り出してトラン ザクシヨン管理表 2202に登録する。そして、当該クエリ内容，新規トランザクション ID ,各サーバ 2100の送信状態を「未送信」で送信キュー 2206に登録する。また、クラ イアント 2500から受信したクエリがトランザクション開始 SQL (BEGIN)以外の場合 は、当該クエリの属するトランザクション IDをトランザクション管理表 2202から取得し、 当該クエリ内容，トランザクション ID,各サーバ 2100の送信状態を「未送信」で送信 キュー 2206に登録する。
[0279] サーバ制御部 2210は、送信キュー 2206に記録されているクエリを、その送信状態 が「未送信」となっているサーバ 2100に対して送信し、当該サーバ 2100についての 送信状態を「送信完了」に変更する。全てのサーバ 2100について送信状態が「送信 完了」になったクエリにつ 、ては送信キュー 2206から削除する。 [0280] 仲介装置 2200からクエリを受信した各サーバ 2100は、当該クエリの処理を行い、 応答パケットを仲介装置 2200に返す。仲介装置 2200のサーバ制御部 2210は、各 サーバ 2100から受信した応答パケットを対比して障害発生の有無を確認し、正常な 応答パケットの 1つをクライアント 2500に返す。
[0281] 一方、サーバ 2100から正当でない応答が仲介装置 2200に返ってきたり、応答そ のものが返ってこない場合には、当該サーバ 2100に障害が発生したものとしてシス テム力も切り離す。具体的には、サーバ管理表 2201における当該サーバの稼働情 報を「down」に変更するとともに、送信キュー 2206の送信状態の欄について当該サ ーバに関する項目を削除する。図 63は、送信キュー 2206が図 62に示すような状態 でサーバ 2100cがシステム力も切り離された場合の送信キュー 2206の一例である。
[0282] 次に、新規サーバ 2100からシステムへの組み込み要求を受信した場合の動作に ついて説明する。サーバ制御部 2210は、第 6の実施の形態と同様に、組み込み要 求受信時に実行中のトランザクションが終了するまで、新規トランザクションの開始は 保留する。具体的には、クライアント 2500から受信したクエリが新規トランザクション に係るものの場合には、送信状態を「保留」として送信キュー 2206に保存する。一方 、クライアント 2500から受信したクエリが組み込み要求時に実行中のトランザクション に係るものの場合には、送信状態を「未送信」として送信キュー 2206に保存する。図 64は、送信キュー 2206が図 63に示すような状態で、仲介装置 2200が同期化要求 を受信し、その後クライアント 2500から新たにクエリを受信した場合の送信キュー 22 06の一例である。図 64の例では、三行目のトランザクション ID = 3の BEGINを除い て上のクエリから順に（古いクエリから順に）、トランザクション ID = 2の SELECT,トラ ンザクシヨン ID= 1の COMMIT,トランザクション ID = 2の COMMITの順に正常稼 働中のサーバ 2100a及び 2100bへ転送され、その送信状態が「未送信」から「送信 完了」に変更される。トランザクション ID = 3の BEGINは、同期化用サーバ 2100bに 同期化指示 (スナップショット作成指示)を送信した後に転送されることになる。
[0283] そして、組み込み要求受信時に実行中のトランザクションに係るクエリを全て正常稼 働中のサーバ 2100に送信し終えると、サーバ制御部 2210は、送信キュー 2206に 組み込み対象である新規のサーバ 2100の項目を追加する。ここで、送信キュー 220 6には送信状態が「保留」となって 、るクエリが記憶されて 、る場合がある。この場合、 サーバ制御部 2210は、送信キュー 2206に記憶されているクエリーに対して、新規 サーバ 2100についての送信状態を「保留」とする。図 65は、図 64の送信キュー 220 6に対して新規サーバ 2100cの登録をした場合を示している。また、サーバ制御部 2 210は、組み込み要求受信時に実行中のトランザクションに係るクエリを全て正常稼 働中のサーバ 2100に送信し終えると、第 6の実施の形態と同様に、正常稼働中のサ ーバ 2100から同期化用サーバ 2100を選定し、この同期化用サーバ 2100に対して 同期化指示 (スナップショット作成指示)を送出する。
[0284] サーバ制御部 2210は、同期化用サーバ 2100に同期化指示を送信すると、この同 期化用サーバ 2100についてサーバ管理表 2201の稼働状態を「sync」に変更する 。そして、正常稼働中のサーバ 2100へのクエリの送信を再開する。具体的には、ま ず送信キュー 2206に記憶されている全てのクエリ（この時点では全てのクエリの送信 状態は全てのサーバ 2100について「保留」になっている）について、正常稼働中の サーバ 2100の送信状態を「未送信」に変更する。そして、サーバ制御部 2210は、送 信状態が「未送信」のクエリを当該サーバ 2100に順次送信し、送信が完了したら送 信状態を「送信完了」に修正する。また、新たにクライアント 2500から受信したクエリ は、正常稼働中のサーバ 2100についての送信状態は「未送信」、新規のサーバ 21 00及び同期化用サーバ 2100についての送信状態は「保留」にして送信キュー 220 6に記憶する。図 66は、図 65の送信キュー 2206に対して同期化指示送信後に新た なクエリを受信した場合を示している。また、図 67のように、正常稼働中のサーバ 21 00aに対しては「送信完了」となっても新規のサーバ 2100c及び同期化用サーバ 21 00bに対しては「送信完了」になって!/ヽな ヽ（「保留」になって!/、る）ので、送信キュー 2206から当該クエリは削除しない。
[0285] 新規のサーバ 2100が正常稼働中のサーバ 2100から受信したスナップショットを用 いてデータベース 2101の復元が完了すると、サーバ制御部 2210は新規のサーバ 2 100から差分情報転送要求を受信する。サーバ制御部 2210は、送信キュー 2206 に記憶されて 、るクエリであって、送信状態が「保留」となって！/、るものを当該「保留」 となっていたサーバ 2100、すなわち新規のサーバ 2100及び同期化用サーバ 2100 に古いものから順次送信する。送信したクエリについては、送信キュー 2206におけ る当該サーバ 2100の送信状態を「送信完了」にし、全てのサーバ 2100についての 送信状態が「送信完了」になったら当該エントリは削除する。
[0286] サーバ制御部 2210は、送信状態が「保留」となっているクエリが送信キュー 2206 に存在しなくなると、サーバ管理表 2201に新規のサーバ 2100を「active」として追 加するとともに、同期化用サーバ 2100の稼働状態を「active」に変更することで、当 該サーバ 2100をシステムに組み込む。以降の動作は各サーバ 2100が正常動作し ている場合のものと同様になる。
[0287] 以上のように本実施の形態に係る仲介装置 2200では、第 6の実施の形態における 差分情報蓄積部 2203と送信キュー 2204の機能を、 1つの送信キュー 2206に統合 しているので、メモリの利用効率や処理効率が向上する。また、送信キュー 2206の 各クエリに対して、各サーバ 2100への送信状態を記憶するようにしているので、新規 サーバ 2100を組み込む際には当該サーバ 2100の送信状態を追加すればよい。こ れにより、一度に複数台のサーバ 2100をシステムに組み込むことができる。他の作 用効果については第 6の実施の形態と同様である。
[0288] なお、本実施の形態は、第 6の実施の形態の変形例として説明したが、上記第 2〜 第 8の実施の形態において同様の変形を適用できることは言うまでもない。
[0289] (第 10の実施の形態）
本発明の第 10の実施の形態に係る多重化データベースシステムについて説明す る。本実施の形態に係る多重化データベースシステムが第 9の実施の形態と異なる 点は、差分情報の蓄積方法にある。他の構成 ·動作等については第 9の実施の形態 と同様なので、ここでは相違点のみを説明する。
[0290] 上述の第 1の〜第 9の実施の形態では、仲介装置 2200が正常稼働中のサーバ 21 00にスナップショットの作成指示を送信するタイミングは、正常稼働中のサーバ 210 0において実行中のトランザクションが無くなったときである。具体的には、新規サー ノ 2100からの組込要求を受信した時点で実行中のトランザクションについて正常稼 働中のサーバ 2100で処理を行うのと並行して、組込要求受信時以降にクライアント 2500から受信した新規トランザクションの開始要求を保留していた。そして、組込要 求を受信した時に実行中のトランザクションが無くなった時点で、同期化用サーバ 21 00にスナップショットの作成指示を送信している。これは、 DBMSによっては、スナツ プショット作成時にトランザクションが実行中だと、そのトランザクションに属する更新ク エリによるデータ更新力 Sスナップショットに反映される力否かが不確定となる場合を考 慮したためである。
[0291] 一方、本実施の形態では、サーバ 2100として、スナップショット作成時に実行中の トランザクションに属する更新クエリ及びスナップショット作成処理中に受信した更新 クエリについては、当該スナップショットには反映しないという動作を行うものを用いる 。これにより、本実施の形態に係る仲介装置 2200のサーバ制御部 2210は、組込要 求受信時に実行中のトランザクションの終了を待つことなぐスナップショット作成指示 の送信及び新規トランザクションの開始を行うことができる。
[0292] このような処理を行うため、本実施の形態に係る仲介装置 2200のサーバ制御部 22 10は、送信キュー 2206に記憶されている各クエリについて、全てのサーバ 2100に ついて送信状態が「送信完了」となり、且つ、当該クエリに属するトランザクションが終 了した場合に、当該クエリの登録を削除する。
[0293] 以下、新規サーバ 2100をシステムに組み込む際の動作について図 68〜図 72を 参照して説明する。いま、システムにはサーバ 2100a及び 2100bが組み込まれてお り、これ力 新たにサーバ 2100cを組み込むものとする。
[0294] サーバ制御部 2210は、新規サーバ 2100cから組込要求を受信すると、正常稼働 中のサーバ 2100の中から同期化用サーバ 2100を選定する。本実施の形態ではサ ーバ 2100bを選定したとする。サーバ制御部 2210は、同期化用サーバ 2100bに対 してスナップショットの作成指示を送信する。新規サーバ 2100cが仲介装置 2200に 対して組込要求を送信した際の送信キュー 2206の一例を図 68に示す。前述したよ うに、送信キュー 2206に記憶されたクエリは、当該クエリが送信完了しても該クエリの 属するトランザクションが完了していないものは削除されずに残っている。スナップシ ヨット作成指示を受信した同期化用サーバ 2100bは、スナップショットの作成を開始 する。ここで作成されるスナップショットは、送信キュー 2206に記憶されているクエリ は反映されていないものである。また、サーバ制御部 2210は、新規サーバ 2100cか ら組込要求を受信すると、送信キュー 2206に記憶されて 、る全てのクエリにつ 、て、 当該新規サーバ 2100cの送信状態を「保留」にして追加する。この時の、送信キュー 2206の一例を図 69に示す。
[0295] サーバ制御部 2210は、組込要求受信時以降にクライアント 2500からクエリを受信 すると、正常稼働中のサーバ 2100aについては送信状態を「未送信」、同期化用サ ーバ 2100b及び新規サーバ 2100cについては送信状態を「保留」にして送信キュー 2206に順次追加する。そして、送信状態が「未送信」となっているクエリについては 当該「未送信」のサーバ 2100aに対して順次転送し、送信状態を「送信完了」に変更 していく。このとき、図 70に示すように、送信キュー 2206に記憶されているクエリは、 正常稼働中のサーバ 2100aについてはトランザクション単位で送信状態が「送信完 了」となっているが、同期化用サーバ 2100b及び新規サーバ 2100cについては「保 留」となっているので、ここではクエリの削除は行わない。
[0296] 一方、仲介装置 2200からスナップショットの作成指示を受信した同期化用サーバ 2 100bは、作成したスナップショットを新規のサーバ 2100cに送信する。新規のサー バ 2100cのデータベース制御部 2102cは、受信したスナップショットからデータべ一 ス 2101cを復元し、仲介装置 2200に差分情報転送要求を送信する。
[0297] 差分情報転送要求を受信したサーバ制御部 2210は、送信キュー 2206に記憶さ れている送信状態が「保留」となっているクエリを差分情報として順次同期化用サー バ 2100b及び新規サーバ 2100cに送信し、図 71に示すように、送信状態を「送信完 了」に変更する。そして、前述したように、全てのサーバについて送信状態が「送信完 了」となり、且つ、当該クエリのトランザクションが完了したら、そのクエリを削除する。 以降、送信状態が「保留」のクエリの送信中にクライアント 2500からクエリを受信する と、図 72に示すように、正常稼働中のサーバ 2100a,同期化用サーバ 2100b,新規 サーバ 2100cの全ての送信状態を「未送信」で送信キュー 2206へ記憶する。そして 、送信状態が「保留」のクエリが無くなった時点で各データベース 2101a, 1010b, 2 101cの同期が完了したことになる。
[0298] 本実施形態によれば、システムで用いるサーバ 2100の機能的要件が限定される ためサーバ選択の幅が狭くなるものの、仲介装置 2200での処理が簡略ィ匕されるの で処理効率の高 、ものとなる。
[0299] (第 11の実施の形態）
本発明の第 11の実施の形態に係る多重化データベースシステムについて図面を 参照して説明する。本実施の形態に係る多重化データベースシステムが前述の各実 施の形態と異なる点は、同期化用サーバ及び新規サーバへの差分情報の送出タイミ ングにある。
[0300] すなわち、上記各実施の形態では、仲介装置は新規サーバから差分情報転送要 求を受信すると、新規サーバ及び同期化用サーバの双方に同時に差分情報の送出 を行っていた。一方、本実施の形態では、同期化用サーバに対する差分情報の送出 処理と新規サーバに対する差分情報の送出処理とを非同期でそれぞれ並行して実 施する。このため、本実施の形態に係る仲介装置は、複数のサーバに対する差分情 報を互いに独立して蓄積する必要があるので、前述の第 9の実施の形態に係る仲介 装置と同じ構成とした。すなわち、送信キュー 2206において、各サーバ毎に差分情 報を記憶する。
[0301] 仲介装置 2200は、前記各実施の形態とは異なり、新規サーバ 2100からだけでな く同期化用サーバ 2100からも差分情報転送要求を受信する。そして、差分情報転 送要求を受信すると、送信キュー 2206における要求元のサーバについての送信状 態が「保留」となっているクエリを、当該要求元のサーバに順次送出する。そして、差 分情報転送要求元のサーバにっ 、て「保留」となって 、るクエリの送出が完了すると 、当該サーバについてサーバ管理表 2201を更新してシステムに組み込む。組込処 理時におけるクライアント 2500からのクエリの処理などは前述した第 9の実施の形態 と同様である。
[0302] 同期化用サーバ 2100は、仲介装置 2200から同期化指示 (スナップショット作成指 示）を受信すると、スナップショットの作成を開始する。次に、スナップショットの作成が 完了すると、仲介装置 2200に対して差分情報転送要求を送信するとともに、新規サ ーバ 2100に対するスナップショットの転送を開始する。この差分情報転送要求に応 じて仲介装置 2200から差分情報を順次受信するので、同期化用サーバ 2100はこ の差分情報の処理を行う。 [0303] 次に、新規サーバ 2100をシステムに組み込む際の動作について図 73及び図 74 のシーケンスチャートを参照して具体的に説明する。
[0304] 今、新規サーバ 2100cが仲介装置 2200にシステムへの組込要求を送信し、仲介 装置 2200がサーバ 2100bを同期化用サーバとして選定して、該同期化用サーバ 2 100bに同期化指示を送信するとともに (ステップ S2301)、該サーバ 2100bをシステ ムカも切り離したとする（ステップ S2302)。なお、システムへの組込要求の受信から 同期指示の送信までの動作については、前述した第 9の実施の形態と同様である。
[0305] 同期化用サーバ 2100bは、仲介装置 2200から同期化指示を受信すると (ステップ S2301)、スナップショットの作成を開始する（ステップ S2303)。そして、スナップショ ットの作成が完了すると (ステップ S2304)、仲介装置 2200に対して差分情報転送 要求を送信するとともに (ステップ S2305)、当該スナップショットを新規サーバ 2100 cへ転送する処理を開始する（ステップ S 2306)。
[0306] 仲介装置 2200は、同期化用サーバ 2100bから差分情報転送要求を受信すると、 当該サーバ 2100bに対する差分情報の送出を開始する (ステップ S2307)。具体的 には、送信キュー 2206に蓄積されているクエリのうち同期化用サーバ 2100bについ ての送信状態が「保留」となっているものを、古いものから順に同期化用サーバ 2100 bに送信する。そして、当該クエリについて送信キュー 2206における同期化用サー バ 2100bの送信状態を「送信完了」に更新する。
[0307] 同期化用サーバ 2100bへの差分情報転送中に、クライアント 2500からクエリ（図 7 3では UPDATE)を受信すると (ステップ S2308)、仲介装置 2200は当該クエリを差 分情報として記憶する (ステップ S2309)。具体的には、当該クエリを、正常稼働中の サーバ 2100aについては送信状態を「未送信」で、同期化用サーバ 2100b及び新 規サーバ 2100cについては送信状態を「保留」にして、送信キュー 2206に蓄積する 。次に、仲介装置 2200は、正常稼働中のサーバ 2100aに転送し (ステップ S2310) 、送信キュー 2206のサーバ 2100aについての送信状態を「送信完了」に更新する。 そして、正常稼働中のサーバ 2100aからの応答パケット（ステップ S2311)を、要求 元のクライアン卜 2500に返す (ステップ S2312)。
[0308] 新規サーバ 2100cは、スナップショットに基づきデータベース 2101cの復元を完了 すると (ステップ S 2313)、仲介装置 2200に対して差分情報転送要求を送信する (ス テツプ S2314)。
[0309] 仲介装置 2200は、新規サーバ 2100cから差分情報転送要求を受信すると (ステツ プ S2314)、当該サーバ 2100cに対する差分情報の送出を開始する (ステップ S23 15)。具体的には、送信キュー 2206に蓄積されているクエリのうち新規サーバ 2100 cにつ 、ての送信状態が「保留」となって 、るものを、古 、もの力 順に新規サーバ 2 100cに送信し、当該クエリについて同期化用サーバ 2100bの送信状態を「送信完 了」に更新する。本実施の形態は、同期化用サーバ 2100bへの差分情報転送と、新 規サーバ 2100cへの差分情報転送は、互いに並行して非同期で行うことが特徴的 な点である。
[0310] 同期化用サーバ 2100b及び新規サーバ 2100cへの差分情報転送中に、クライア ント 2500からクエリ（図 73では INSERT)を受信すると (ステップ S 2316)、仲介装置 2200は当該クエリを差分情報として記憶する (ステップ S2317)。具体的には、当該 クエリを、正常稼働中のサーバ 2100aについては送信状態を「未送信」で、同期化用 サーバ 2100b及び新規サーバ 2100cについては送信状態を「保留」にして、送信キ ユー 2206に蓄積する。次に、仲介装置 2200は、正常稼働中のサーバ 2100aに転 送し (ステップ S2318)、送信キュー 2206のサーバ 2100aについての送信状態を「 送信完了」に更新する。そして、正常稼働中のサーバ 2100aからの応答パケット (ス テツプ S2319)を、要求元のクライアン卜 2500に返す (ステップ S2320)。
[0311] 仲介装置 2200は、同期化用サーバ 2100b又は新規サーバ 2100cについて送信 状態が「保留」となっているクエリが送信キュー 2206からなくなると、差分情報の送出 が完了したことになるので、当該サーバ 2100b, 2100cについてそれぞれサーバ管 理表 2201を更新してシステムに組み込む。
[0312] 通常は、図 74に示すように、同期化用サーバ 2100bへの差分情報送出は新規サ ーバ 2100cより先に終了し (ステップ S2321)、仲介装置 2200は、同期化用サーバ 2100bにつ!/、てサーバ管理表 2201の稼働状態を activeに変更してシステムに組 み込む（ステップ S2322)。
[0313] 以降、新規サーバ 2100cへの差分情報転送中にクライアント 2500からのクエリ（図 74では UPDATE)は、正常稼働中のサーバ 2100a及び前記ステップ S2322で組 み込まれたサーバ 2100bで処理される。具体的には、当該クライアント 2500からタエ リを受信すると (ステップ S2323)、当該クエリを正常稼働中のサーバ 2100a及び 21 00bについては送信状態を「未送信」で、新規サーバ 2100cについては送信状態を 「保留」で、送信キュー 2206に蓄積する (ステップ S2324)。次に、仲介装置 2200は 、正常稼働中のサーノ 2100a及び 2100b【こ転送し (ステップ S2325, S2326)、送 信キュー 2206のサーバ 2100a及び 2100bについての送信状態を「送信完了」に更 新する。そして、正常稼働中のサーバ 2100a及び 2100bからの応答パケット (ステツ プ S2327, S2328)の正当性をチェックし (ステップ S2329)、正しい応答の 1つを要 求元のクライアン卜 2500に返す (ステップ S2330)。
[0314] 次に、仲介装置 2200は、新規サーバ 2100cについて送信状態が「保留」となって いるクエリが送信キュー 2206からなくなると、差分情報の送出が完了したことになる ので (ステップ S2331)、当該新規サーバ 2100cについてサーバ管理表 2201の稼 働情報を「active」で追加してシステムに組み込む (ステップ S2332)。
[0315] 本実施の形態によれば、上記各実施の形態と比較して、同期化用サーバ 2100の システムの組込復帰の時期が早くなるので、システムに組み込まれて 、るサーバの 数が通常時よりも少なくなつている期間を短縮することができる。したがって、システム の耐故障性が向上する。
[0316] なお、本実施形態では、同期化用サーバ 2100bが新規サーバ 2100cよりも先にシ ステムに組み込まれた例について説明したが、例えば新規サーバ 2100cが同期化 用サーバ 2100bよりも高性能である場合など、状況によっては新規サーバ 2100cの 方が先にシステムに組み込まれる場合も考えられる。
[0317] 以上、本発明の実施形態について詳述したが、上記実施の形態は例示的なもので あり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に 示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれる ものである。
[0318] 例えば、各サーバは要求に応じて同じ応答をするならば同じ実装である必要はな い。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラォプ シヨン、ハードウェア力ソフトウェア力 などが異なっていてもよい。サーバには、 Post greSQLなどのフリーソフトウェアや Oracleなどの市販のソフトウェア、独自開発のソ フトウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サー ノ 2100aは PostgreSQLでサーバ 2100b及び 2100cは Oracleでも良い。
[0319] DBMSとしては、巿中品（例えば、 Oracleや PostgreSQL)を使う場合は、データ ベース制御部 2102は、データベース管理部とデータベースサーバ管理部に機能を 分けることによって、巿中品を無改造で使うことができる。データベース管理部は、デ ータベース 2101を直接操作するもので、例えば PostgreSQLの場合は postmaste rや postgresに相当する。データベースサーバ管理部は、仲介装置 2200とデータ ベース管理部の間に介在し、クエリの送受信を中継したりするほかに、他のサーバを 同期化する際のデータベース 2101のスナップショットを作成したり、そのスナップショ ットを他のサーバへ転送したりする処理を行う。
[0320] スナップショットの作成方法は、例えば DBMSが PostgreSQLならば pg— dumpな どのダンプツールやバックアップツールを使って実現する。なお、 pg— dumpは Post greSQLサーバ同士を同期化する場合には有用だ力 異種の DBMS同士 (例えば PostgreSQLと Oracle)を同期化する場合には、 DBMS固有のツールは使わずに、 正常稼働中の DBMSサーバから SELECTクエリで全てのデータを取りだし INSER Tクエリでデータを入れる汎用のツールを使えばよい。
[0321] また、上記実施の形態では、システムへの組み込み要求 (新規サーバのデータべ ース同期化要求）は当該新規サーバ 2100のデータベース制御部 2102が仲介装置 2200へ送信している力 保守端末などの他の装置力も送信してもよいし、オペレー タが仲介装置 2200に直接指示しても良い。
[0322] さらに、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが 、ハードウェアで実装しても良い。
[0323] また、上記実施の形態では、仮想サーバ 2800を構成する仲介装置 2200は 1台の みであつたが、複数台設けて冗長性を持たせることにより、より可用性の高い構成と することも可能である。仲介装置を多重化させる技術については、例えば本願出願 人による特開 2003— 345679号公報に記載されたものなどを用いればよい。 [0324] (第 12の実施の形態）
本発明の第 12の実施の形態に係る多重化データベースシステムについて図面を 参照して説明する。図 75は本実施の形態に係る多重化データベースシステムの全 体構成を説明するブロック図である。
[0325] この多重化データベースシステムは、図 75に示すように、複数のデータベースサー バ（以下「サーバ」と言う） 100と仲介装置 3200とをネットワーク 3300で接続したもの であり、ネットワーク 3400を介して 1以上のクライアントコンピュータ（以下「クライアント 」と言う） 500及びデータベース一致検査装置 3600からアクセスされるものである。本 実施の形態では、図 75に示すように、 2台のサーバ 3100a及び 3100bを有しており 、 2台のクライアント 3500a及び 3500b力もアクセスされる。以降の説明において各サ ーバ 3100を他のサーバ 3100と区別する場合には添え字「a」「b」を付加するものと する。クライアント 3500についても同様である。なお、図 75の例では、サーノ 3100と クライアント 3500はそれぞれ別々のネットワーク 3300, 400に接続されている力 同 じネットワークに接続されて 、てもよ 、。
[0326] 図 75に示すように、仲介装置 3200は、ネットワーク 3400側に IPアドレス 172.17.1.1 を持っており、これをデータベースサーバの IPアドレスとして公開している。クライアン ト 3500やデータベース一致検査装置 3600はデータベースにアクセスしたいときは I Pアドレス 172.17.1.1へクエリを送信し、 IPアドレス 172.17.1.1の仲介装置 3200からそ のクエリに対する応答パケットを受信する。これは、クライアント 3500等にとっては、 I Pアドレス 172.17.1.1を持ったデータベースサーバとパケットを送受信していることと同 じである。この IPアドレス 172.17.1.1を持った仮想的なデータベースサーバを仮想サ ーノ 3800と呼ぶ。この仮想サーバ 3800の目的は、サーバ 3100が冗長化されてい ることを隠蔽するためである。つまり、サーバ 3100aとサーバ 3100b両方が稼働して いようとサーバ 3100bがダウンしてサーバ 3100aのみが稼働していようとサーバ 310 Oaとサーバ 3100bの他に新たなサーバが追加されようとクライアントには影響は無く 、動作を変更する必要がない。
[0327] サーバ 3100は、データを保存'管理するデータベース 3101と、データベース 310 1の動作を制御するデータベース制御部 3102とを備えている。 [0328] データベース 3101は、 SQL (Structured Query Language)を解して処理を行う RD BMS (Relational Database Management System)である。このようなデータベース 31 01としては種々のものがあり、例えば The PostgreSQL Global Development Groupによる PostgreSQL (http://www.postgres.org/)や、 Oracle社による Oracl e (登録商標） (http://www.oracle.com)などが挙げられる。
[0329] データベース制御部 3102は、ネットワーク 3300を介して仲介装置 3200から送ら れてくるパケットに基づき動作する。このパケットは、 SQLなどデータベース 3101で の処理に係るもの、同期化処理に係るものに大別される。 SQLなどデータベース 31 01での処理に係るものについては、データベース制御部 3102は、当該パケットをデ ータベース 3101に渡し、データベース 3101からの処理結果を仲介装置 3200に返 す。
[0330] 一方、同期化処理に係るものは、さらに、 自身が本システムに組み込まれている場 合のものと、起動時や障害復旧時などこれからシステムに組み込む場合のものとに別 れる。前者については、スナップショットの作成指示（同期化指示）がある。データべ ース制御部 3102は、スナップショット作成指示を仲介装置 3200から受信すると、デ ータベース 3101のスナップショットを作成する。そして、スナップショットの作成が完 了すると、スナップショット作成完了を仲介装置 3200に通知する。そして、作成した スナップショットを、スナップショット作成指示で指示されて 、る転送先の他のサーバ 3 100に転送する。
[0331] 他方、障害復旧時などこれからシステムに組み込む場合、データベース制御部 31 02は、他のデータベースからスナップショットを受信すると、このスナップショットを用 いて自身のデータベース 3101を復元する。データベース 3101の復元が完了すると 仲介装置 3200に対して差分情報転送要求を送出する。後述するように、差分情報 転送要求に応じて仲介装置 3200から差分情報が転送されるので、この差分情報を 用いてデータベース 3101を復元する。
[0332] また、データベース制御部 3102は、仲介装置 3200から再起動指示を受信すると 、データベース 3101及びデータベース制御部 3102の再起動を行う。この再起動処 理は、データベース 3101及びデータベース制御部 3102のプロセスの再起動のみ を行ってもよく、データベース 3101及びデータベース制御部 3102がサーバ 3100の 起動時に自動起動するように設定されて!ヽればサーバ 3100全体の再起動でもよ 、 。さらに、データベース制御部 3102は、自身が起動（再起動を含む）されると、仲介 装置 3200に対してデータベース同期化要求 (システムへの糸且込要求）を送信する。
[0333] 仲介装置 3200は、本システム内のサーバ 3100を管理するサーバ管理表 3201と 、トランザクションを管理するトランザクション管理表 3202と、同期化用に差分情報を 蓄積する差分情報蓄積部 3203と、サーバ 3100に送信するクエリを一時保存する送 信キュー 3204と、クライアント 3500及びデータベース一致検査装置 3600とサーバ 3100と間での処理の仲介やサーバ 3100の同期化制御などを行うサーバ制御部 32 10とを備えている。
[0334] サーバ管理表 3201は、サーバが正常稼働中（active)か、障害などで停止してい る（down)力 という状態を保存している。図 76にサーバ管理表の一例を示す。サー バ管理表 3201は、図 76に示すように、サーバ 3100を識別するためのサーバ IDと、 サーバの稼働状態から構成されている。図 76の例では、サーバ 3100aとサーバ 310 Obとが登録されており、稼働状態は共に正常稼働を示す activeである。また、本実 施形態では、サーバ IDとしてサーバ 3100に付された IPアドレスを用いた。
[0335] トランザクション管理表 3202は、現在実行中の又は実行開始を保留されているトラ ンザクシヨンの有無を記憶する。図 77にトランザクション管理表 3202の一例を示す。 図 77に示すように、トランザクション管理表 3202は、クライアントを一意に識別するク ライアント IDとトランザクションを一意に識別するトランザクション ID力も構成される。こ れらのペアは、トランザクション開始時にトランザクション管理表 3202に登録され、トラ ンザクシヨン終了時にトランザクション管理表 3202から削除される。クライアント IDは 、例えばクライアント 3500等の IPアドレスやポート番号である。トランザクション IDは 新しいトランザクションが発生する毎にサーバ制御部 3210が新たに割り振る。
[0336] 差分情報蓄積部 3203は、サーバ同期化時にクライアント 3500及びデータベース 一致検査装置 3600から受信する全てのクエリを蓄積する。図 78に差分情報蓄積部 3203が蓄積して 、る差分情報の一例を示す。差分情報蓄積部 3203の各データは 、図 78に示すように、クライアント 3500又はデータベース一致検査装置 3600が送 信したクエリと、このクエリが所属するトランザクション IDとから構成される。トランザク シヨン IDはトランザクション管理表 3202から取得する。同期化処理時における新たな クエリは、この差分情報蓄積部 3203の最後に追加される。つまり、上から古いクエリ が蓄積されている。図 78の例では、トランザクション ID= 1の BEGINが一番古ぐ C OMMITが一番新し!/、。
[0337] 送信キュー 3204は、各クライアント 3500及びデータベース一致検査装置 3600か ら受信したクエリを各サーバ 3100に送信するまで一時的に保存するバッファメモリで ある。図 79に送信キュー 3204の一例を示す。送信キュー 3204の各データは、図 79 に示すように、クライアント 3500等が送信したクエリと、このクエリが所属するトランザ クシヨン IDと、サーバ 3100に送信したか否かを表す送信状態とから構成される。トラ ンザクシヨン IDはトランザクション管理表 3202から取得する。クライアント 3500等から の新たなクエリは、この送信キュー 3204の最後に追加される。つまり、上から古いク エリが蓄積されている。図 79の例では、トランザクション ID= 1の BEGINが一番古く 、トランザクション ID = 2の BEGINが一番新しい。この送信キュー 3204の送信状態 は、クライアント 3500等カもクエリを受信した際には「未送信」が設定され、正常稼働 中の全てのサーバ 3100に送信されると「送信完了」が設定される。送信完了となった エントリは、直ちに又は所定期間経過後に送信キュー 3204から削除される。
[0338] サーバ制御部 3210は、通常の処理（同期化処理時以外の処理）として、クライアン ト 3500及びデータベース一致検査装置 3600からのパケットをネットワーク 3400経 由で受信し、サーバ管理表 3201を見て正常稼働している全てのサーバ 3100へ該 パケットを転送する。ここで、サーバ 3100へ転送するパケットは、送信キュー 3204に 「未送信」として記憶されているクエリが対象であり、送信キュー 3204に記憶されてい る古いクエリから順に転送される。そして、サーバ 3100からのパケットをネットワーク 3 300経由で受信し後述するパケットの正当性判断方法により 1つ以上の該パケットの うち 1つを選出し 1つの正しいパケットをネットワーク 3400を経由して要求元のクライ アント 3500等へ転送する。なお、同期化処理時には、「未送信」のクエリであっても 新規トランザクションに属するクエリは送信せず、実行中のトランザクションに属するク エリのみを古い順に正常稼働中のサーバ 3100に送信する。 [0339] ここで、サーバ制御部 3210は、クライアント 3500等力もの処理要求を解析してトラ ンザクシヨンの開始と終了を検出してトランザクション管理表 3202を更新する。トラン ザクシヨン開始と終了をサーバ制御部 3210が検出する方法は、 DBMSの種類によ つて異なる。例えば前述の PostgreSQLの場合は、トランザクションの開始はクライア ント 3500等が「BEGIN」という SQLを送信した時であり、トランザクションの終了はク ライアント 3500等力 S ΓΟΟΜΜΙΤ]「ROLLBACK」と!、う SQLを送信した時である。 また、 Oracleの場合は、トランザクションの開始はクライアント 3500等が有効な SQL を送信したときであり（明示的なトランザクションの開始を宣言する SQLは無い）、トラ ンザクシヨンの終了はクライアント 3500等が「COMMIT」「ROLLBACK」と!、う SQ Lを送信した時である。また、 AUTO COMMITモードで動作する場合には、クライ アント 3500等力も受信した SQL文はそれぞれ 1つの独立したトランザクションに属し ていると解釈できるので、クライアント 3500等から SQLを受信する毎に、該 SQL実行 前にトランザクションが開始されるとともに SQL実行後に当該トランザクションが終了 したこととして扱うことができる。
[0340] また、パケットの正当性判断方法は、例えば、サーバ 3100が 3台以上ある場合には 多数決で決める方法や、受信したパケットを所定のルールに基づ 、て判断する方法 がある。例えば、クライアント 3500からの「参照」要求に対して「更新成功」という応答 が返ってきた場合、正常であればそのような応答はあり得な 、ので (参照成功など参 照に関する応答のはず）、この応答パケットは正しくないと判断する。また、パケット中 にデータ長フィールドがある場合、このデータ長フィールドの値と実際に受信したパ ケット長を比較し、異なる場合は正しくないと判断する。また、複数のサーバ 3100の 中力 Masterサーバを予め 1台決めておき、このサーバ 3100からのパケットを常に 正しいと判断する。また、上記複数の方法を併用する方法もある。例えば、 3台で多 数決を行った結果、パケットの中身が全てバラバラであり、多数派のパケットを決めら れな 、場合は Masterサーバのパケットを正し!/、と判断する。正常稼働して 、るサ一 ノ が 1つだけの場合は、そのサーバからの応答パケットを正常と判断する。
[0341] サーバ制御部 3210は、正当ではない応答を送信したサーバ 3100、及び、所定時 間内に応答を返さないサーバ 3100は障害と判断し、そのサーバ 3100についてサ ーバ管理表 3201から登録を削除することによりシステム力も切り離すとともに、当該 サーバ 3100に対して再起動指示を送信する。
[0342] さらに、サーバ制御部 3210は、ネットワーク 3300を介してサーバ 3100からデータ ベース同期化要求（システムの組み込み要求）を受信すると、このサーバ 3100と、正 常稼働中のサーバ 3100とを同期化させる処理を行う。以下にその処理について説 明する。ここで、以降の説明において、これからシステムに組み込まれるサーバを便 宜上「新規サーバ」と呼ぶ。この新規サーバの組み込みは、システムにおけるサーバ を増設する場合のほか、前述したようにシステム力も切り離されたサーバを再組み込 みする場合などに実施される。
[0343] サーバ制御部 3210は、サーバ 3100からデータベース同期化要求を受信すると、 正常稼働中のサーバ 3100に対してスナップショットの作成指示を送出する。ここで、 スナップショットの作成指示を送出するタイミングは、サーバ 3100においてトランザク シヨンが実行中でないことが求められる。これはスナップショット作成中にトランザクシ ヨンが ROLLBACKするとデータの同期化が図れない場合があることを防止するた めや、 COMMITされて!/、な!/、ために更新データがスナップショットに反映されな！、こ とを防止するためである。このためサーバ制御部 3210は、処理中のトランザクション が終了するまでスナップショットの作成指示の送出を待つとともに、スナップショット作 成完了通知をサーバ 3100から受信するまでは新規トランザクションを開始しないよう にしている。そして、新規トランザクションに係る SQLについては、スナップショット作 成完了通知の受信後に、正常稼働中のサーバ 3100で処理するとともに、差分情報 蓄積部 3203に蓄積する。差分情報蓄積部 3203に蓄積するクエリは、トランザクショ ン制御 SQL、参照系 SQL及び更新系 SQLを含む全ての SQLが対象となる。
[0344] サーバ制御部 3210がスナップショットの作成指示を送出すると、当該スナップショ ットは新規のサーバ 3100に転送され、このサーバ 3100からサーバ制御部 3210に 対して差分情報転送要求が送出される。サーバ制御部 3210は、差分情報転送要求 を受信すると、新規のサーバ 3100に対して差分情報蓄積部 3203に蓄積されている クエリを古いもの力も順次送信する。差分情報蓄積部 3203に蓄積されている SQLを 全て送出すると、サーバ制御部 3210は、新規サーバ 3100をシステムに組み込むベ くサーバ管理表 3201を更新する。
[0345] ここで、サーバ制御部 3210は、差分情報の送出中にクライアント 3500又はデータ ベース一致検査装置 3600から新たなクエリを受信する場合がある力 この場合は当 該クエリを差分情報蓄積部 3203の最後に追加するとともに正常稼働中のサーバ 31 00へ送信すれば良い。ただし、クライアント 3500等のクエリ送出頻度が高い場合な どには、差分情報の送出終了まで、すなわち同期化終了まで長時間要する場合が 考えられる。そこで、差分情報蓄積部 3203における未送信の差分情報が所定件数 以下となったら、クライアント 3500等からのクエリを一時保留して差分情報の送出の みを行い、まず差分情報の送出を完了させる。そして、前述のように新規サーバ 310 0をシステムに組み込むべくサーバ管理表 3201を更新した後に、保留していたクエリ 処理を再開すると好適である。
[0346] クライアント 3500は、多重化データベースシステムに対して更新クエリ（データべ一 スを更新するリクエスト)や参照クエリ（データベースの内容を参照するリクエスト）など を発行するものである。
[0347] データベース一致検査装置 3600は、クライアント 3500と同様に多重化データべ一 スシステムのクライアントとして動作するものであり、各サーバ 3100のデータベース 3 101が互 ヽに一致して 、るか否かを確認するためのクエリを発行する。このクエリは、 参照系のものであり、例えば所定のテーブル test— tableに対する「SELECT * FROM test— table」などである。データベース一致検査装置 3600は、定期的に 又はオペレータ等の指示に応じて当該検査用クエリの発行を行う。
[0348] 次に、本実施の形態に係る多重化データベースシステムの動作について図面を参 照して説明する。まず、サーバ 3100aと 3100bが正常に動作している場合の動作を 図 80から図 82を参照して説明する。
[0349] 初期状態では、データベース 3101aと 101bは完全に同一であり、サーバ管理表 3 201は図 81のようになっているものとする。また、トランザクション管理表 3202と差分 情報蓄積部 3203は空であるとする。各サーバ 3100a, 3100bには、テーブル test —tableが存在して!/、るとする。
[0350] クライアント 3500aが 172.17.1.1宛にトランザクション開始 SQLを含んだパケットを送 信すると、仲介装置 3200はそのパケットを受信する (ステップ S31)。サーバ制御部 3 210は、トランザクションが開始されたことを検知し、トランザクション管理表 3202にク ライアント 3500aの IPアドレスとトランザクション番号を登録する（ステップ S32)。図 8 2にこのときのトランザクション管理表 3202を示す。そして、このパケットに係るクエリ を送信状態「未送信」で送信キュー 3204に入れる。
[0351] サーバ制御部 3210は、送信キュー 3204から当該「未送信」のクエリを取り出し、サ ーバ管理表 3201を見て正常稼働している全てのサーバ 3100に該パケットを送信す る。この場合、サーバ 3100aと 3100bが正常稼働しているので、サーバ制御部 3210 はサーバ 3100aとサーバ 3100bへ該パケットを転送する（それぞれステップ S33と S 34)。そして、各サーバ 3100への送信が完了したので送信キュー 3204の送信状態 を「送信完了」にして当該エントリを削除する。仲介装置 3200は、トランザクションが 正常に開始されたことを通知する応答パケットをサーバ 3100aから受信するが (ステ ップ S35)、この時点では、未だ全ての応答パケットが揃っているわけではないので（ この場合、サーバ 3100bからの応答パケットが来ていない）、サーバ制御部 3210は 何もせずにサーバ 3100bからの応答パケットを待つ。そして、トランザクションが正常 に開始されたことを通知する応答パケットをサーバ 3100bから受信すると (ステップ S 36)、これで全ての応答パケットが揃ったので、サーバ制御部 3210はそれらの応答 パケットを互いに比較することでサーバ 3100に障害が発生している力否かをチェック する (ステップ S37)。この場合、 2つの応答パケットは共にトランザクションが正常に 開始されたことを示すパケットであるため、障害は無いと判断し応答パケットの 1つを クライアント 3500aへ転送する（ステップ S38)。
[0352] 次に、クライアント 3500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S39)。サーバ制御部 3210は、受 信したクエリを送信キュー 3204に入れる。そして、送信キュー 3204から当該クエリを 取り出し、サーバ管理表 3201を見て正常稼働しているサーノ 、この場合、サーバ 31 00aと 3100bへ該パケットを転送する（それぞれステップ S310と S311)。次いで、送 信キュー 3204の送信状態を「送信完了」にして当該エントリを削除する。サーバ 310 Oaは正常に UPDATE完了したことを通知する応答パケットを仲介装置 3200に送信 し、仲介装置 3200がこの応答パケットを受信する (ステップ S312)。この時点では全 ての応答パケットが全て揃っているわけではないので、サーバ制御部 3210は何もせ ず待機する。そして、正常に UPDATE完了したことを通知する応答パケットをサー ノ 3100bから受信すると (ステップ S313)、これで応答パケットが全て揃ったので、サ ーバ制御部 3210はそれら応答パケットを互いに比較することでサーバ 3100に障害 が発生している力否かをチェックする（ステップ S314)。この場合、 2つの応答パケット は共に UPDATE成功したことを示すパケットであるため、障害は無!、と判断し応答 パケットの 1つをクライアント 3500aへ転送する（ステップ S315)。
次に、クライアント 3500aは、テーブル test— tableへの更新を確定する（実際にデ ータベースを更新する） SQL (COMMIT)を含んだパケットを 172.17.1.1へ送信する (ステップ S316)。サーバ制御部 3210は、受信したクエリを送信キュー 3204に入れ る。そして、送信キュー 3204から当該クエリを取り出し、サーバ管理表 3201を見て 正常稼働しているサーノ 、この場合、サーバ 3100aとサーバ 3100bへ該パケットを 転送する（それぞれステップ S317と S318)。次いで、送信キュー 3204の送信状態 を「送信完了」にして当該エントリを削除する。サーバ 3100aは正常に COMMIT完 了したことを通知するパケットを仲介装置 3200に送信し、仲介装置 3200がこの応答 パケットを受信する (ステップ S319)。この時点では全ての応答パケットが全て揃って いるわけではないので、サーバ制御部 3210は何もせず待機する。そして、正常に C OMMIT完了したことを通知する応答パケットをサーバ 3100bから受信すると (ステツ プ S320)、これで応答パケットが全て揃ったので、サーバ制御部 3210はそれら応答 パケットを互いに比較することでサーバ 3100に障害が発生している力否かをチェック する（ステップ S321)。この場合、 2つの応答パケットは共に COMMIT成功したこと を示すパケットであるため、障害は無いと判断する。 COMMITが正常に完了したこ と力 、トランザクションが終了したことが分力るので、サーバ制御部 3210はトランザ クシヨン管理表 3202からこのトランザクションの登録を削除する (ステップ S322)。こ のときのトランザクション管理表 3202は再び初期状態 (すなわち空）になる。サーバ 制御部 3210は応答パケットの 1つをクライアント 3500aへ転送する（ステップ S323) [0354] 次に、サーバ 3100bが故障などで障害になった場合の動作を図 83から図 85を参 照して説明する。初期状態では、データベース 3101aと 101bは完全に同一であり、 サーバ管理表 3201は前述した図 7のようになっているとする。また、トランザクション 管理表 3202と差分情報蓄積部 3203は空であるとする。
[0355] クライアント 3500aが 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を含んだ パケットを送信すると、仲介装置 3200はそのパケットを受信する (ステップ S330)。サ ーバ制御部 3210は、トランザクションが開始されたことを検知し、トランザクション管 理表 3202にクライアント 3500aの IPアドレスとトランザクション番号を登録する（ステツ プ S331)。図 84にこのときのトランザクション管理表 3202を示す。そして、このバケツ トに係るクエリを送信状態「未送信」で送信キュー 3204に入れる。
[0356] サーバ制御部 3210は、送信キュー 3204から当該「未送信」のクエリを取り出し、サ ーバ管理表 3201を見て正常稼働している全てのサーバ 3100、この場合、サーバ 3 100aと 3100bへ該パケットを転送する（それぞれステップ S332と S333)。次いで、 送信キュー 3204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置 3200は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ 3 100aから受信するが (ステップ S334)、この時点では、未だ全ての応答パケットが揃 つて 、るわけではな 、ので（この場合、サーバ 3100bからの応答パケットが来て!/、な い）、サーバ制御部 3210は何もせずにサーバ 3100bからの応答パケットを待つ。そ して、トランザクションが正常に開始されたことを通知する応答パケットをサーバ 3100 b力も受信すると (ステップ S335)、これで全ての応答パケットが揃ったので、サーバ 制御部 3210はそれら応答パケットを互いに比較することでサーバ 3100に障害が発 生している力否かをチェックする (ステップ S336)。この場合、 2つの応答パケットは共 にトランザクションが正常に開始されたことを示すパケットであるため、障害は無いと 判断し応答パケットの 1つをクライアント 3500aへ転送する（ステップ S337)。
[0357] ここで、サーバ 3100bは、ステップ S335で応答パケットを返した後、故障などの障 害が発生してダウンしたものとする（ステップ S338)。
[0358] 次に、クライアント 3500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S339)。サーバ制御部 3210は、受 信したクエリを送信キュー 3204に入れる。そして、送信キュー 3204から当該クエリを 取り出し、サーバ管理表 3201を見て正常稼働しているサーノ 、この場合、サーバ 31 00aと 3100bへ該パケットを転送する（それぞれステップ S340と S341)。この時点で は、サーバ制御部 3210はサーバ 3100bのダウンを知らないので、サーノ 3100b力 S 正常稼働して 、ると 、う情報がサーバ管理表 3201に格納されたままである。、 、で 、送信キュー 3204の送信状態を「送信完了」にして当該エントリを削除する。サーバ 3100aは正常に UPDATE完了したことを通知する応答パケットを仲介装置 3200に 送信し、仲介装置 3200がこの応答パケットを受信する (ステップ S342)。この時点で は応答パケットが全て揃っているわけではないので、サーバ制御部 3210は何もせず 待機する。し力し、サーバ 3100bはダウンしているのでサーバ 3100bからの応答パ ケットはいつまで経っても仲介装置 3200には届かない。これによりサーバ制御部 32 10はタイムアウトし、サーバ 3100bのダウンを検知する。そして、サーバ制御部 3210 はサーバ管理表 3201のサーバ 3100bを activeから down (サーバ停止状態）に書き 換えることにより当該サーバ 3100bをシステム力も切り離す (ステップ S343)。そのと きのサーバ管理表 3201を図 85に示す。次に、サーバ制御部 3210は、システムから 切り離したサーバ 3100bに対して再起動指示を送出する (ステップ S344)。もっとも、 ここではサーバ 3100bはダウンしているので、当該再起動指示に対する処理が行わ れることはない。次に、サーバ制御部 3210は応答パケットをクライアント 3500aへ転 送する（ステップ S345)。ここでは、クライアント 3500aにとつて、サーバ 3100bが障 害になったかどうかは認識せず、今までと同様に仮想サーバ 3800からサービスを受 けることができること〖こ注目すべきである。
次に、クライアント 3500aは、テーブル test— tableへの更新を確定する SQL (CO MMIT)を含んだパケットを 172.17.1.1へ送信する（ステップ S346)。サーバ制御部 3 210は、受信したクエリを送信キュー 3204に入れる。そして、送信キュー 3204から 当該クエリを取り出し、サーバ管理表 3201を見て正常稼働しているサーバ、この場 合、サーバ 3100aのみへ該パケットを転送する（ステップ S347)。次いで、送信キュ 一 3204の送信状態を「送信完了」にして当該エントリを削除する。サーバ 3100aは 正常に COMMIT完了したことを通知する応答パケットを送信し、仲介装置 3200が この応答パケットを受信する (ステップ S348)。 COMMITが正常に完了したことから 、トランザクションが終了したことが分力るので、サーバ制御部 3210はトランザクション 管理表 3202からこのトランザクションの登録を削除する（ステップ S349)。このときの トランザクション管理表 3202は再び初期状態 (すなわち空）になる。サーバ制御部 3 210は応答パケットをクライアント 3500aへ転送する（ステップ S350)。
[0360] ここで、ステップ S347によって、サーバ 3100aのデータベース 3101aは、クライア ント 3500aからの UPDATE (ステップ S339)が反映されているのに対して、サーバ 3 100bのデータベース 3101bにはクライアント 3500aからの UPDATE (ステップ S33 9)が反映されていない、つまり、データベース 3101aとデータベース 3101bは非同 期状態になったことに注目すべきである。
[0361] 次に、並行処理される複数のトランザクションについて、各サーバ 3100における処 理順序が異なった場合について図 86及び図 87のシーケンスチャートを参照して説 明する。ここでは、図 128のテーブル table— testに対して、図 129のトランザクション T1をクライアント 3500aが発行し、同図のトランザクション T2をクライアント 3500bが 発行したものとする。前述したように、この 2つのトランザクション Tl, T2の処理後に おけるデータベース 3101のデータは、各トランザクションの処理順序によって異なつ た内容になることに注意されたい。
[0362] 図 86に示すように、クライアント 3500aがトランザクション T1を開始するクエリ（BEG IN)を仲介装置 3200に送信し (ステップ S3101)、一方、クライアント 3500bがトラン ザクシヨン T2を開始するクエリ（BEGIN)を仲介装置 3200に送信する（ステップ S31 02)。仲介装置 3200のサーバ制御部 3210は、各クエリをそれぞれ正常稼働中のサ ーノ 3100a及び 3100b【こ転送する（ステップ S3103〜S3106)。そして、各サーノ 3100a及び 3100b力らのそれぞれ応答（ステップ S3107〜S3110)につ!/、て正当 性をチェックし（図示省略）、正当な応答の 1つをそれぞれの要求元のクライアント 35 00a又は 3500bに転送する（ステップ S3111〜S3112)。
[0363] 仲介装置 3200から BEGINに対する応答を受信したクライアント 3500a及び 3500 bは、それぞれのトランザクションに属する次のクエリを仲介装置 3200に送信する。 本実施例では、クライアント 3500aはトランザクション T1の UPDATEクエリを仲介装 置 3200に送信し (ステップ S3113)、クライアン卜 3500bはトランザクション T2の UP DATEクエリを仲介装置 3200に送信する（ステップ S3114)。クライアント 3500a及 び 3500bからクエリを受信した仲介装置 3200のサーバ制御部 3210は、当該クエリ をそれぞれ正常稼働中のサーノ 3100a及び 3100bに転送する（ステップ S3115〜
53118)。
[0364] サーバ 3100aではトランザクション Tlの UPDATEクエリがトランザクション T2の U PDATEクエリより先に処理されたとする。トランザクション T1の UPDATEクエリを処 理したサーバ 3100aは、処理結果を仲介装置 3200に送信する（ステップ S3119)。 このとき、トランザクション T1の UPDATEクエリによる test— tableの当該更新対象 行は、トランザクション T1が COMMITされるまでロックされる。一方、トランザクション T2の UPDATEクエリはロックされている行が更新対象となっているので、当該クエリ の処理はロックが解除されるまで保留される（ステップ S3120)。
[0365] 他方、サーバ 3100bではトランザクション T2の UPDATEクエリがトランザクション T 1の UPDATEクエリより先に処理されたとする。トランザクション T2の UPDATEタエ リを処理したサーバ 3100bは、処理結果を仲介装置 3200に送信する (ステップ S31 21)。このとき、トランザクション T2の UPDATEクエリによる test— tableの当該更新 対象行は、トランザクション T2が COMMITされるまでロックされる。一方、トランザク シヨン T1の UPDATEクエリはロックされている行が更新対象となっているので、当該 クエリの処理はロックが解除されるまで保留される (ステップ S 3122)。
[0366] ここで、サーバ 3100aからはトランザクション T1の UPDATEクエリの応答（ステップ
53119)力 サーバ 3100bからはトランザクション T2の UPDATEクエリの応答（ステ ップ S 3121 )よりも先に仲介装置 3200に到達したとする。
[0367] 仲介装置 3200のサーバ制御部 3210は、トランザクション T1の UPDATEクエリに つ！、ての応答を一方のサーバ 3100aから受信したが（ステップ S 3119)、他方のサ ーバ 3100bからの応答は受信していないので当該応答を待つ（ステップ S3123)。こ れは、前述したように、サーバ制御部 3210において、各サーバ 3100a及び 3100b 力もの応答を互いに比較して正当性を判断するためである。同様に、サーバ制御部 3210は、トランザクション T2の UPDATEクエリについての応答を一方のサーバ 310 Obから受信したが（ステップ S3121)、他方のサーバ 3100aからの応答は受信してい ないので当該応答を待つ (ステップ S3124)。
[0368] 前述のようにサーバ 3100bにおいてトランザクション T1の UPDATEクエリの処理 はロック解除待ちされているので (ステップ S3122)、サーバ制御部 3210における当 該クエリに対する応答待ち（ステップ S3123)はタイムアウトする (ステップ S3125)。 これにより、サーバ制御部 3210は、サーバ 3100bが障害になったと判断し、前記ス テツプ S3124の応答待ちをキャンセルし、さらにサーバ管理表 3201におけるサーバ 3100bの稼働状態を downに変更することで当該サーバ 3100bをシステムから切り 離す (ステップ S3126)。そして、サーバ制御部 3210は、図 87に示すように、システ ムカも切り離したサーバ 3100bに対して再起動指示を送信するとともに (ステップ S3 127)、サーバ 3100bからの応答待ちはキャンセルしてサーバ 3100aからの応答をク ライアン卜 3500aに返す (ステップ S3128)。
[0369] サーバ 3100bは、仲介装置 3200からの再起動指示を受信すると、 自身の再起動 を開始する（ステップ S3129)。
[0370] トランザクション T1の UPDATEクエリにつ!/、て応答を受信したクライアント 3500a は、更新を確定するクエリ（COMMIT)を仲介装置 3200に送信する (ステップ S313 0)。仲介装置 3200のサーバ制御部 3210は、クライアント 3500aからクエリを受信す ると、サーバ管理表 3201を参照して正常稼働中のサーバ 3100aに当該クエリを転 送する（ステップ S3131)。
[0371] サーバ 3100aでは、トランザクション T1の COMMITクエリを処理することによりロッ クが解除されてトランザクション T2の処理が再開可能となる（ステップ S3132)。これ により、サーバ 3100aはトランザクション T1の COMMITクエリに対する応答を仲介 装置 3200に返し (ステップ S3133)、仲介装置 3200のサーバ制御部 3210は当該 応答をクライアント 3500aに転送する（ステップ S3134)。次いで、サーバ 3100aはト ランザクシヨン T2の UPDATEクエリに対する応答を仲介装置 3200に返し (ステップ S3135)、仲介装置 3200のサーバ制御部 3210は当該応答をクライアント 3500bに 転送する（ステップ S 3136)。
[0372] トランザクション T2の UPDATEクエリにつ!/、て応答を受信したクライアント 3500b は、更新を確定するクエリ（COMMIT)を仲介装置 3200に送信する (ステップ S313 7)。仲介装置 3200のサーバ制御部 3210は、クライアント 3500bからクエリを受信す ると、サーバ管理表 3201を参照して正常稼働中のサーバ 3100aに当該クエリを転 送する (ステップ S3138)。サーバ 3100aは当該クエリを処理して応答を仲介装置 32 00に返し (ステップ S3139)、仲介装置 3200のサーバ制御部 3210は当該応答をク ライアン卜 3500bに転送する（ステップ S3140)。
[0373] ここで、システム力も切り離されたサーバ 3100bの再起動が完了したものとする（ス テツプ S3141)。サーバ 3100bは、再起動が完了すると仲介装置 3200に対してデ ータベース同期化要求を送信する（ステップ S3142)。仲介装置 3200のサーバ制御 部 3210は、正常稼働中のサーバ 3100aと協働して、サーバ 3100aのデータベース 3101aと、サーバ 3100bのデータベース 3101bとを同期化させる処理を行う（ステツ プ S3143)。この同期化処理の詳細については後述する。サーバ制御部 3210は、 同期化処理が完了したら、サーバ管理表 3201についてサーバ 3100bの稼働状態 を activeに変更することで当該サーバ 3100bを再びシステムに組み込む (ステップ S 3144)。
[0374] 以上の処理により、並行処理される複数のトランザクションについて、各サーバ 310 0における処理順序が異なった場合であっても、各サーバ 3100間でデータベース 3 101の同期が保たれる。
[0375] 次に、図 128のテーブル test— tableに対して、図 130のトランザクション T3をクラ イアント 3500aが発行し、同図のトランザクション T4をクライアント 3500bが発行した 場合について図 88及び図 89のシーケンスチャートを参照して説明する。この 2つのト ランザクシヨン T3, T4の処理後におけるデータベース 3101のデータは、各トランザ クシヨンの処理順序には影響されない。し力しながら、前述したように、トランザクショ ン T4における SELECTの結果は各トランザクション T3, T4の処理順序によって異 なった内容になることに注意されたい。
[0376] クライアント 3500aがトランザクション T3を開始するクエリ（BEGIN)を仲介装置 32 00に送信すると (ステップ S3201)、仲介装置 3200のサーバ制御部 3210は、サー バ管理表 3201を参照して正常稼働中のサーバ 3100a及び 3100bに転送する（ステ ップ S3202, S3203)。サーノ 帘 lj御咅 3210ίま、各サーノ 3100a及び 3100b力らの 応答を受信すると (ステップ S3204, S3205)、正当な応答の 1つをクライアント 3500 aに転送する（ステップ S3206)。
[0377] 次!、で、クライアント 3500aはトランザクション T3の更新クエリ（UPDATE)を仲介 装置 3200に送信する（ステップ S3207)。一方、クライアント 3500bはトランザクショ ン T4を開始するクエリ（BEGIN)を仲介装置 3200に送信する (ステップ S3208)。
[0378] 仲介装置 3200のサーバ制御部 3210は、トランザクション T3の UPDATEクエリを 正常稼働中のサーノ 3100a及び 3100bに転送するとともに（ステップ S3209, S32 10)、トランザクション T4の BEGINクエリを正常稼働中のサーバ 3100a及び 3100b に転送する（ステップ S3211, S3212)。そして、仲介装置 3200のサーバ制御部 32 10は、トランザクション T3の UPDATEクエリに対する応答を各サーバ 3100a及び 3 100b力ら受信すると（ステップ S3213, S3214)、正当な応答の 1つをクライアント 35 00a〖こ転送する（ステップ S3215)。また、トランザクション T4の BEGINクエリに対す る応答を各サーノ 3100a及び 3100b力ら受信すると（ステップ S3216, S3217)、正 当な応答の 1つをクライアント 3500bに転送する（ステップ S 3218)。
[0379] 次!、で、クライアント 3500aはトランザクション T3を確定するクエリ（COMMIT)を仲 介装置 3200に送信する（ステップ S3219)。一方、クライアント 3500bはトランザクシ ヨン T4の参照クエリ（SELECT)を仲介装置 3200に送信する（ステップ S3220)。
[0380] 仲介装置 3200のサーバ制御部 3210は、トランザクション T3の COMMITクエリを 正常稼働中のサーノ 3100a及び 3100bに転送するとともに（ステップ S3221, S32 22)、トランザクション T4の SELECTクエリを正常稼働中のサーバ 3100a及び 3100 bに転送する（ステップ S3223, S3224)。
[0381] ここで、一方のサーバ 3100aでは、トランザクション T3の COMMITクエリがトランザ クシヨン T4の SELECTクエリより先に処理され (ステップ S3225, S3226)、他方の サーバ 3100bでは、トランザクション T4の SELECTクエリがトランザクション T3の CO MMITクエリより先に処理されたものとする（ステップ S3227, S3228)。これにより、 トランザクション T4の SELECTクエリの応答は、サーバ 3100aからの応答（ステップ S 3226)と、サーバ 3100bからの応答 (ステップ S3227)とは異なったものとなったとす る。
[0382] 仲介装置 3200のサーバ制御部 3210は、トランザクション T4の SELECTクエリに 対する応答が、各サーバ 3100a及び 3100b間で不一致となっているので、何れかの サーバ 3100a又は 3100bを選定し、このサーバ 3100aからの応答を正当なものとす る（ステップ S3229)。ここで、サーバ 3100の選定方法としては、例えば予め Master サーバを定めておいて、この Masterサーバを選定する方法、最初に応答を返したサ ーバを選定する方法、ラウンドロビンにより選定サーバを順次選定する方法、ランダム に選定する方法、各サーバの処理能力'処理負荷などにより選定する方法などが挙 げられる。本実施の形態では、サーバ 3100aを Masterサーバとして該サーバ 3100 aを正当な応答を返したサーバとして選定する。サーバ制御部 3210は、正当でない 応答を返したサーバ 3100bについて、サーバ管理表 3201の稼働状態を downに変 更することにより当該サーバ 3100bをシステム力も切り離す (ステップ S3230)。そし て、図 89に示すように、当該サーバ 3100bに対して再起動指示を送信する (ステップ S3231)。
[0383] サーバ 3100bは、仲介装置 3200からの再起動指示を受信すると、 自身の再起動 を開始する（ステップ S3232)。
[0384] 仲介装置 3200のサーバ制御部 3210は、選定したサーバ 3100aから受信した、ト ランザクシヨン T4の SELECTクエリに対する応答及びトランザクション T3の COMMI Tクエリに対する応答を、それぞれ要求元のクライアント 3500a, 3500bに転送する（ ステップ S3233, S3234)。以降、各クライアント 3500a, 3500b力ものクエリは、正 常稼働中のサーバ 3100aで処理する。図 89の例では、クライアント 3500bがトランザ クシヨン T4の COMMITクエリを仲介装置 3200に送信すると（ステップ S3235)、仲 介装置 3200は当該クエリを正常稼働中のサーバ 3100aに転送する (ステップ S323 6)。そして、仲介装置 3200は、当該クエリに対する応答をサーバ 3100aから受信す ると（ステップ S3237)、この応答を要求元のクライアント 3500bに返す (ステップ S32 38)。
[0385] ここで、システム力も切り離されたサーバ 3100bの再起動が完了したものとする（ス テツプ S3239)。サーバ 3100bは、再起動が完了すると仲介装置 3200に対してデ ータベース同期化要求を送信する（ステップ S3240)。仲介装置 3200のサーバ制御 部 3210は、正常稼働中のサーバ 3100aと協働して、サーバ 3100aのデータベース 3101aと、サーバ 3100bのデータベース 3101bとを同期化させる処理を行う（ステツ プ S3241)。この同期化処理の詳細については後述する。サーバ制御部 3210は、 同期化処理が完了したら、サーバ管理表 3201についてサーバ 3100bの稼働状態 を activeに変更することで当該サーバ 3100bを再びシステムに組み込む (ステップ S 3242)。
[0386] 以上の処理により、並行処理される複数のトランザクションについて、各サーバ 310 0における処理順序が異なった場合であっても、クライアント 3500には 1つの正しい 応答のみが処理結果として返される。
[0387] なお、この例では、 2つのトランザクション T3及び T4に属するクエリの処理順序が 異なっても当該トランザクション T3及び T4に属する各クエリの中で同一行を更新する クエリは存在しないので、クエリの処理順序が異なることによる各データベース 3101 間の不整合は生じない。したがって、この例に限定して考えると、データベース 3101 の同期ィ匕のための各処理 (ステップ S3230〜S3232, S3239~S3242)は不要で あるとも考えられる。しかし、本実施の形態では、何らかの原因でデータベース 3101 の不整合が発生し、当該不整合について前記ステップ S3229を契機に検出した場 合にも対処できるように、データベース 3101の同期化のための各処理を実施するよ うにした。
[0388] 次に、前記ステップ S3143及び S3241における同期化処理の詳細について説明 する。本発明における同期化処理では、同期化処理開始時において正常稼働して いるサーバ 3100でデータベース 3101のスナップショットを作成し、このスナップショ ットを同期化対象の新規サーバ 3100に転送する。そして新規サーバ 3100において スナップショットからデータベース 3101の復元を行う。さらに、この処理中に受信した クライアント 3500からのクエリを仲介装置 3200において差分情報として蓄積する。 そして、新規サーバ 3100がスナップショットからのデータベース 3101の復元が完了 したら仲介装置 3200から差分情報を取得して、この差分情報を処理する。
[0389] なお、前述したように、サーバ 3100は自身が起動されるとデータベース同期化要 求を仲介装置 3200に送信するので、同期化処理の実施は、仲介装置 3200からの 再起動指示に応じた再起動時に限られない。すなわち、サーバ 3100が障害となつ てシステムカゝら切り離され、その後にシステムに再び組み込む際にも実施される。ま た、システムを構成するサーバを増設する場合にも実施される。
[0390] 以下に、サーバ 3100bをシステムに組み込む場合の同期化動作を図 90から図 98 を参照して説明する。このとき注目すべきポイントは、クライアント 3500a及び 3500b に対するサービスを続けたままサーバ 3100bを追加する、つまり、システムダウンさせ ずにデータベース 3101aと 101bを同期させることである。
[0391] データベース 3101bはデータベース 3101aと同期がとれていない状態、つまり、同 一ではない状態である。例えば、データベース 3101bは、再起動直前のデータ又は 障害発生直前のデータを保持して 、る力もしれな 、し、全く新 U、サーバの場合には 、データを全く持っていない状態力もしれない。本発明では、前者の場合でも古いデ ータは削除し、データベース 3101bはデータを全く保持していないものとしてシステ ムに糸且み込む。つまり、古いデータを保持している必要はない。
[0392] ここでは、サーバ管理表 3201は図 93のようになっているとする。また、トランザクシ ヨン管理表 3202と差分情報蓄積部 3203は空であるとする。
[0393] 図 90に示すように、クライアント 3500aが 172.17.1.1宛のトランザクション開始 SQL ( BEGIN)を含んだパケットを送信すると、仲介装置 3200はそのパケットを受信する（ ステップ S3301)。サーバ制御部 3210は、トランザクションが開始されたことを検知し 、トランザクション管理表 3202にクライアント 3500aの IPアドレスとトランザクション番 号を登録する（ステップ S3302)。図 94にこのときのトランザクション管理表 3202を示 す。サーバ制御部 3210は、受信したクエリを送信キュー 3204に入れる。そして、送 信キュー 3204から当該クエリを取り出し、サーバ管理表 3201を見て正常稼働してい るサーバ、この場合、サーバ 3100aへ該パケットを転送する（ステップ S3303)。次い で、送信キュー 3204の送信状態を「送信完了」にして当該エントリを削除する。仲介 装置 3200は、トランザクションが正常に開始されたことを通知する応答パケットをサ ーバ 3100aから受信すると（ステップ S3304)、応答パケットをクライアント 3500aへ 転送する（ステップ S3305)。 [0394] ここで、サーバ 3100bが再起動したものとする（ステップ S306)。これにより、サーバ 3100bのデータベース制御部 3102bは、データベース同期化要求を仲介装置 320 0へ送信する（ステップ S3307)。
[0395] データベース同期化要求を受信したサーバ制御部 3210は、トランザクション管理 表 3202をチェックし現在実行中のトランザクションが存在するかどうかを確認するとと もに、実行中トランザクションの情報を記録しておく（ステップ S3308)。図 94より、クラ イアント 3500a,トランザクション番号 3のトランザクションが実行中なので、データべ ース同期化動作はこのトランザクションの終了を待つと同時に、新しいトランザクション 開始要求を受け取った場合は、その要求をサーバ 3100aへ転送することを遅らせる (ステップ S3309)。つまり、同期化動作は実行中のトランザクションが全くない状態で 始める。この新規トランザクションの開始要求についての転送遅延処理は、送信キュ 一 3204での保留という手段で実現する。
[0396] 次に、クライアント 3500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S3310)。サーバ制御部 3210は、 受信したクエリを送信キュー 3204に入れる。このクエリは前記ステップ S3308で記憶 したトランザクション情報力 データベース同期化要求時に実行していたトランザクシ ヨンに属するものと判定できるので、サーバ制御部 3210は、送信キュー 3204から当 該クエリを取り出し、サーバ管理表 3201を見て正常稼働しているサーノ 、この場合、 サーバ 3100aへ該パケットを転送する（ステップ S3311)。次いで、送信キュー 3204 の送信状態を「送信完了」にして当該エントリを削除する。サーバ 3100aは正常に U PDATE完了したことを通知する応答パケットを仲介装置 3200に送信し、仲介装置 3200がこの応答パケットを受信する（ステップ S3312)。サーバ制御部 3210は、応 答パケットをクライアント 3500aへ転送する（ステップ S3313)。
[0397] 次に、クライアント 3500bが 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を 含んだパケットを送信すると、仲介装置 3200はそのパケットを受信する (ステップ S3 314)。サーバ制御部 3210は、このパケットによりトランザクションが開始されたことを 検知し、トランザクション管理表 3202にクライアント 3500bの IPアドレスとトランザクシ ヨン番号を登録する（ステップ S3315)。図 95にこのときのトランザクション管理表 320 2を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー 3204 に入れる。しかし、この時点では同期化処理準備のため、新規トランザクション開始ク エリは送信キュー 3204に保持したままサーバ 3100aへは転送しない（ステップ S331 6)。
[0398] 次に、クライアント 3500aは、テーブル test— tableへの更新を確定する SQL (CO MMIT)を含んだパケットを 172.11.1.1へ送信する（ステップ S 3317)。サーバ制御部 3210は、受信したクエリを送信キュー 3204に入れる。このクエリは前記ステップ S33 08で記憶したトランザクション情報力 データベース同期化要求時に実行していたト ランザクシヨンに属するものと判定できるので、サーバ制御部 3210は、送信キュー 32 04から当該クエリを取り出し、サーバ管理表 3201を見て正常稼働しているサーバ、 この場合、サーバ 3100aのみへ該パケットを転送する（ステップ S3318)。次いで、送 信キュー 3204の送信状態を「送信完了」にして当該エントリを削除する。サーバ 310 0aは正常に COMMIT完了したことを通知する応答パケットを仲介装置 3200に送 信し、仲介装置 3200がこの応答パケットを受信する（ステップ S3319)。 COMMIT が正常に完了したことから、トランザクションが終了したことが分力るので、サーバ制御 部 3210はトランザクション管理表 3202からこのトランザクションの登録を削除する（ス テツプ S3320)。この時のトランザクション管理表 3202を図 96に示す。サーバ制御 部 3210は応答パケットをクライアント 3500aへ転送する（ステップ S 3321)。
[0399] ここで、新規サーバ 3100bからのデータベース同期化要求時に実行していたトラン ザクシヨンが全て無くなつたので、サーバ制御部 3210は同期化動作を開始する (ス テツプ S3322)。具体的には、図 91に示すように、まず、サーバ制御部 3210は、正 常稼働しているサーバ 3100aに対して同期化指示 (スナップショット作成指示)のパ ケットを送信する（ステップ S3323)。なお、前記ステップ S3322において、トランザク シヨン管理表 3202に記録されているトランザクションがデータベース同期化要求時 に実行中であったもの力、又は、その後にクライアント 3500から受信したものかを判 定するには、前記ステップ S 3308で記録してぉ 、たデータベース同期要求時のトラ ンザクシヨン情報を参照すればよ 、。
[0400] 同期化指示を受け取ったサーバ 3100aのデータベース制御部 3102aは、データ ベース 3101aのスナップショットを作り出す (ステップ S3324)。ここで、このスナップ ショットは、同期化指示を受け取った時点でのデータベース全体のバックアップデー タゃデータベースを復元するための情報であり、同期化指示後の更新は反映されて
Vヽな 、ことに注目すべきである。
[0401] サーバ 3100aのデータベース制御部 3102aは、スナップショット作成が完了すると
(ステップ S3325)、その旨を仲介装置 3200へ通知する（ステップ S3326)。
[0402] データベース制御部 3102aは作成したスナップショットをサーバ 3100bへ転送し、 サーバ 3100bのデータベース制御部 3102bは、サーバ 3100aから受信したスナツ プショットからデータベースを復元する（ステップ S3327)。このスナップショットの転送 とデータベースの復元は、データベース 3101aのサイズが大きければ大きいほど時 間が力かる力 クライアントからのデータベースアクセスと並行して実行されるのでクラ イアントに対するサービスを止めることはない。
[0403] スナップショット作成完了通知を受け取った仲介装置 3200のサーバ制御部 3210 は、クライアント 3500へのサービスを再開する。この場合、処理せずに送信キュー 32 04に保持していた、クライアント 3500bからの BEGINを含んだパケットの処理を再開 する。すなわち、サーバ制御部 3210は、転送せずに保持していたクライアント 3500 bからの BEGIN SQLを含んだパケットを送信キュー 3204から取り出して差分情報 蓄積部 3203に保存するとともに (ステップ S3328)、サーバ 3100aへ転送する (ステ ップ S3329)。次いで、送信キュー 3204の送信状態を「送信完了」にして当該ェント リを削除する。
[0404] なお、ここではステップ S3329の処理をステップ S3327の後に説明した力 ステツ プ S3327の動作 (スナップショットの転送）はクライアントへのサービスを妨げるもので はないので、スナップショットの転送中にステップ S3329や後述のステップ S3330が 行われてもよい。
[0405] サーバ 3100aは、トランザクションが正常に開始されたことを通知する応答パケット を仲介装置 3200に送信し、仲介装置 3200がこの応答パケットを受信する (ステップ S3330)。仲介装置 3200は、この応答パケットをクライアント 3500bへ転送する（ステ ップ S3331)。 [0406] 次!、で、クライアント 3500bがテーブル test— tableの更新 SQL (UPDATE)のパ ケットを仲介装置 3200に送信すると (ステップ S3332)、サーバ制御部 3210は、受 信したクエリを送信キュー 3204に入れる。そして、送信キュー 3204から当該クエリを 取り出し、当該クエリを差分情報蓄積部 3203に保存するとともに (ステップ S3333)、 正常稼働中のサーバ 3100aに当該パケットを送信する (ステップ S3334)。次いで、 送信キュー 3204の送信状態を「送信完了」にして当該エントリを削除する。ここで、 サーバ 3100aは UPDATEに失敗し、その旨を通知する応答パケットを仲介装置 32 00に送信したものとする (ステップ S3335)。仲介装置 3200は、この応答パケットをク ライアント 3500bに送信する（ステップ S3336)。
[0407] UPDATE失敗の応答パケットを受信したクライアント 3500bは、トランザクションを 取り消す SQL (ROLLBACK)のパケットを仲介装置に送信する（ステップ S 3337)。 サーバ制御部 3210は、受信したクエリを送信キュー 3204に入れる。そして、送信キ ユー 3204から当該クエリを取り出し、当該 SQLを差分情報蓄積部 3203に保存する とともに (ステップ S3338)、正常稼働中のサーバ 3100aに当該パケットを送信する（ ステップ S3339)。次いで、送信キュー 3204の送信状態を「送信完了」にして当該ェ ントリを削除する。そして、サーバ 3100aから正常にトランザクションが ROLLBACK されたことを通知する応答パケットを受信すると (ステップ S3340)、トランザクション管 理表 3202から当該トランザクションの登録を削除するとともに (ステップ S3341)、こ の応答パケットをクライアント 3500bに送信する（ステップ S3342)。この時点での差 分情報蓄積部 3203を図 97に示す。また、トランザクション管理表 3202は空になる。
[0408] ここで、サーバ 3100bにおいてスナップショットからのデータベース 3101bの復元 が完了したものとする（ステップ S3343)。サーバ 3100bはデータベース 3101bの復 元が完了すると差分情報転送要求を仲介装置 3200に送信する (ステップ S3344)。 仲介装置 3200のサーバ制御部 3210は、差分情報転送要求を受信すると、図 92に 示すように、差分情報蓄積部 3203に蓄積されて 、るデータを古 、ものから順にサー バ 3100bに転送する処理を開始する（ステップ S3345)。
[0409] 前記ステップ S3345で差分情報蓄積部 3203に蓄積されている全てのクエリが転 送 ·処理されることでデータベース 3101aと 101bは完全に一致した状態（同期状態） になる力 この転送処理中にクライアント 3500から新たなクエリを受信する場合があ る。例えば、図 92に例示するように、仲介装置 3200は、クライアント 3500bから新規 トランザクションを開始するクエリ（BEGIN)を受信する (ステップ S3346)。仲介装置 3200は、当該新規トランザクションをトランザクション管理表 3202に登録する (ステツ プ S3347)。そして、当該クエリを送信キュー 3204に入れる。次いで、送信キュー 32 04力 当該クエリを取り出し、差分情報蓄積部 3203の最後に当該クエリを追加する とともに (ステップ S3348)、正常稼働中のサーバ 3100aに送信する（ステップ S334 9)。そして、送信キュー 3204の送信状態を「送信完了」にして当該エントリを削除す る。次いで、サーバ 3100aから応答パケットを受信すると (ステップ S3350)、当該応 答パケットをクライアント 3500bに転送する（ステップ S3351)。
[0410] このように差分情報転送中にクライアント 3500から受信したクエリは、正常稼働中 のサーバ 3100で処理するとともに、差分情報蓄積部 3203に蓄積していく。この処理 を継続していくと、やがて差分情報蓄積部 3203に蓄積されているクエリは全て新規 サーバ 3100bに転送され、差分情報蓄積部 3203は空になり、これを契機に差分情 報転送処理が終了する（ステップ S3352)。これによりデータベース 3101aと 101bは 完全に一致した状態（同期状態)となるので同期化処理を終了する。以上で同期化 処理は完了するので、図 87及び図 89を参照して前述したように、新規サーバ 3100 bについてのサーバ管理表 3201の稼働状態を activeに変更することでシステムに 当該サーバ 3100bを追加することができる（図 87のステップ S3144,図 89のステツ プ S3242)。
[0411] このような同期化処理により、もともとシステムに組み込まれていたが再起動や障害 等のためにシステム力も切り離されたサーバであっても、新規のサーバであっても、 理論的には幾らでも追加できる。つまり、追加できるサーバ数に制限はない。
[0412] なお、上記実施形態では、クライアント 3500a及び 3500bからの処理要求のみ多 重化データベースシステムで処理する場合にっ 、て説明した力 データベース一致 検査装置 3600からの処理要求も同様に処理すればよい。これは、多重化データべ ースシステムから見るとデータベース一致検査装置 3600もクライアントコンピュータ の 1つだからである。ところで、データベース一致検査装置 3600は、前述したように、 定期的に又は必要に応じてデータベース一致検査用の参照クエリを仲介装置 3200 に送信する。これにより、何らかの理由でデータベース 3101間でデータの矛盾が生 じた場合であっても、当該クエリによりデータベース 3101間の矛盾が検出され上記 同期化処理が実行される。これにより、データベース 3101間の同期をより確実に図 ることがでさる。
[0413] 以上のように本実施の多重化データベースシステムによれば、複数のトランザクショ ンを並行処理しても各データベース間で矛盾の生じることがなく同期状態を保つこと ができる。
[0414] 本実施の形態の変形例について説明する。上記実施形態におけるデータベース 同期化処理では、差分情報転送中にクライアント 3500から新たなクエリを受信すると 、当該クエリを差分情報蓄積部 3203に追記していた。このような処理では、差分情 報の処理に時間が力かる場合や、クライアントからの受信するクエリの受信間隔が短 い場合には、差分情報蓄積部 3203のデータが何時までたっても空にならな力つたり 空になるまで長時間要することになり、結果として新規サーバ 3100bの組み込み処 理完了まで長時間要することが考えられる。そこで、差分情報転送中に差分情報蓄 積部 3203のエントリ数が所定数以下となったら、新規クエリの処理を一時保留して専 ら差分情報の転送のみを行って差分情報蓄積部 3203を空にしてしまうと良い。以下 、このような処理について図 98を参照して説明する。
[0415] ここでは、新規のサーバ 3100bがスナップショットからデータベース 3101bの復元 処理中であるとする（ステップ S3400)。そして、サーバ 3100bにおいてデータべ一 ス 3101bの復元処理が完了し (ステップ S3401)、サーバ 3100bが仲介装置 3200 に差分情報転送要求を送信した時点で (ステップ S3402)、差分情報蓄積部 3203 には所定件数以上の差分情報が蓄積されているものとする。図 98の例では、ステツ プ S3403〜ステップ S3407による UPDATEのクエリが最新の差分情報として差分 情報蓄積部 3203に記憶されているものとする。
[0416] 図 98に示すように、仲介装置 3200のサーバ制御部 3210は、サーバ 3100bから 差分情報転送要求を受信すると、前述したように、差分情報蓄積部 3203に記憶され ている各クエリを古いものから順にサーバ 3100bに転送する処理を開始する (ステツ プ S3408)。
[0417] サーバ制御部 3210は、クライアント 3500bから新たなクエリを受信したとする。図 9 8の例では、サーバ制御部 3210は、クライアント 3500b力もデータを追加する SQL ( INSERT)を含むパケットを受信する (ステップ S 3409)。差分情報転送中に新規ク エリを受信したサーバ制御部 3210は、受信したクエリを送信キュー 3204に入れる。 そして、送信キュー 3204から当該クエリを取り出し、差分情報蓄積部 3203に蓄積さ れている未転送のクエリの件数が所定件数より多い場合には、このクエリを差分情報 蓄積部 3203の最後に追記するとともに (ステップ S3410)、正常稼働中のサーバ 31 00aに該パケットを転送する (ステップ S3411)。次いで、送信キュー 3204の送信状 態を「送信完了」にして当該エントリを削除する。サーバ制御部 3210は、 INSERTが 成功したことを示す応答パケットをサーバ 3100aから受信すると (ステップ S3412)、 この応答パケットをクライアント 3500bに転送する（ステップ S3413)。
[0418] ここで、仲介装置 3200力もサーバ 3100bへの差分情報の転送は並行して行われ ており、これにより差分情報蓄積部 3203に記憶されている未転送のクエリが所定数 以下となったとする。
[0419] サーバ制御部 3210は、クライアント 3500b力もデータを更新する SQL (UPDATE )を含むパケットを受信すると (ステップ S3414)、受信したクエリを送信キュー 3204 に入れる。ここでは、差分情報蓄積部 3203に蓄積されている未転送のクエリの件数 が所定件数以下となっているので、この新規クエリの処理は保留する (ステップ S341 5)。すなわち、この新規クエリの差分情報蓄積部 3203への記憶及びサーバ 3100a への転送は行わない。この保留処理は、差分情報蓄積部 3203に記憶されているク エリを全てサーバ 3100bに転送し、サーバ 3100bがシステムへ組み込まれるまで継 続する。
[0420] 差分情報の転送が終了すると (ステップ S3416)、差分情報蓄積部 3203に蓄積さ れている全てのクエリが転送.処理されることでデータベース 3101aと 101bは完全に 一致した状態（同期状態）になる。以上で同期化処理は完了するので、サーバ制御 部 3210は、サーバ管理表 3201のサーバ 3100bの稼働状態を activeに変更するこ とでシステムにサーバ 3100bを追加する（ステップ S3417)。なお、このステップ S34 17の処理 ίま、図 87のステップ S3144及び図 89のステップ S3242にネ目当する。
[0421] 以降、サーバ制御部 3210は、前記ステップ S 3415で保留していた新規クエリの処 理を再開する。この時点では既に同期化が終了しているので、以降の処理は図 80を 参照して前述したものと同様となる。すなわち、サーバ制御部 3210は、当該クエリを 送信キュー 3204から取り出して正常稼働中のサーノ 、この場合サーバ 3100a及び 3100b【こ転送する（ステップ S3418, S3419)。次!ヽで、送信キュー 3204の送信状 態を「送信完了」にして当該エントリを削除する。そして、各サーバ 3100a及び 3100 bから受信した応答パケットを比較して障害発生の有無をチェックし (ステップ S3420 〜S3422)、正常な応答パケットの 1つをクライアント 3500bへ転送する（ステップ S3 423)。
[0422] このような処理により、差分情報の転送中にクライアントから受信したクエリは、未転 送の差分情報が所定数より多い場合には差分情報蓄積部 3203への記憶及びサー ノ 3100bへの転送が行われる。一方、未転送の差分情報が所定数以下の場合には 新規クエリは保留される。これにより、差分情報の処理に時間が力かる場合ゃクライア ントからの受信するクエリの受信間隔が短い場合であっても、データベースの同期を 短時間に行うことができる。なお、閾値となる「所定件数」は、大きく設定すると新規ク エリの保留時間が長くなる一方、小さく設定すると同期化処理完了までの時間が長 引くことになるというトレードオフの関係にある。したがって、この「所定件数」は各装置 の処理負荷やネットワーク速度などシステムの要件に応じて個々に最適な値を設定 すればよい。また、本変形例において閾値を 0以下に設定すれば、図 90〜図 97を 参照して前述した実施例と同様の処理となる。
[0423] (第 13の実施の形態）
本発明の第 13の実施の形態に係る多重化データベースシステムについて説明す る。本実施の形態に係る多重化データベースシステムが第 12の実施の形態と異なる 点は、同期化処理における仲介装置力 新規のサーバに転送する差分情報の内容 にある。他の構成'動作等については第 12の実施の形態と同様なので、ここでは相 違点のみを説明する。
[0424] 第 12の実施の形態では差分情報蓄積部 3203にはクライアント 3500から受信した 全てのクエリを保存.転送していた。これにより、同期化処理を実施している間に正常 稼働中のサーバ 3100で処理されたクエリを、新規のサーバ 3100においても忠実に 再現することができるので、完全な同期化を図ることができる。
[0425] ところで、仲介装置力 新規のサーバに転送する差分情報は専ら同期処理用にの み用いられるので、該同期化において不要なクエリは転送する必要がない。具体的 には、参照系クエリの SQL (SELECT)は不要である。なお、ここでは、 SELECT F OR UPDATE文は、 SELECT文の一種であるが更新処理に影響を与えるので、 ここでは参照系クエリではなく更新系クエリとして取り扱うものとする。
[0426] そこで、本実施の形態では、第 12の実施の形態と異なり、クライアント 3500から受 信したクエリのうち、参照系クエリを除いたものを差分情報として新規のサーバ 3100 に転送する。例えば、クライアント 3500から図 99 (a)に示すような SQL文を受信した とすると、新規のサーバ 3100には図 99 (b)に示すような SQL文を転送してやればよ い。
[0427] このような処理を行うため、本実施の形態に係るサーバ制御部 3210は、第 12の実 施の形態と同様にクライアント 3500からクエリを受信した全てのクエリを差分情報蓄 積部 3203に記憶する。そして、差分情報を新規サーバ 3100に転送するにあたって 、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外を新規サーバ 310 0に転送する。他の処理については第 12の実施の形態と同様である。
[0428] 本実施の形態によれば、第 12の実施の形態と比較すると、新規サーバ 3100は同 期化処理時において参照系クエリを処理する必要がないので同期化処理の短縮ィ匕 を図ることができる。これは、複雑な参照系 SQLや集合関数を含む参照系 SQLなど 処理負荷が大き 、参照系 SQLをクライアント 3500が発行して 、る場合には特に有 効である。他の効果については第 12の実施の形態と同様である。
[0429] 本実施の形態の変形例としては、サーバ制御部 3210が、同期化処理中にクライァ ント 3500からクエリを受信し、このクエリを差分情報として差分情報蓄積部 3203に蓄 積するにあたって、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外 を差分情報蓄積部 3203に記憶する。そして、差分情報の転送は差分情報蓄積部 3 203に記憶されている全てのクエリを対象に行う方法が挙げられる。この変形例は、 差分情報蓄積部 3203の記憶容量をさらに節約できるという効果を有する。
[0430] (第 14の実施の形態）
本発明の第 14の実施の形態に係る多重化データベースシステムについて説明す る。本実施の形態に係る多重化データベースシステムが第 12の実施の形態と異なる 点は、データベース同期化動作中における差分情報の蓄積処理にある。他の構成- 動作等については第 12の実施の形態と同様なので、ここでは相違点のみを説明す る。
[0431] 第 12の実施の形態では、サーバ制御部 3210は、クライアント 3500から受信した全 てのパケットを差分情報蓄積部 3203に保存していた。すなわち、トランザクション制 御 SQL、参照系 SQL及び更新系 SQLの全ての SQLについて差分情報蓄積部 320 3に保存し、サーバ 3100には差分情報蓄積部 3203に記憶されている全てのデータ を古 、もの力 順に送信して 、た。
[0432] 一方、本実施の形態では、サーバ制御部 3210は、データベース同期化動作中に クライアント 3500から受信したパケットのうち、トランザクションの開始 SQL (BEGIN) や確定 SQL (COMMIT)や取消 SQL (ROLLBACK)等のトランザクション制御 SQ L、及び、 SELECTなど参照系の SQLについては保存せず、 UPDATEや INSER Tなどの更新系の SQLのうち正常稼働中のサーバ 3100で COMMITされたものの みを差分情報蓄積部 3203に保存する。
[0433] ここで注意すべき点は、差分情報蓄積部 3203には、クライアント 3500から受信し た順番ではなぐ正常稼働中のサーバ 3100で処理された順番に更新クエリを蓄積 することである。これは、更新対象が重複する更新クエリについては、その処理順序 によってデータベース 3101の内容が異なってしまう可能性があるためである。
[0434] このような処理を実現するために、本実施の形態では、図 100に示すような差分情 報一時蓄積部 3205を新たに設けた。この差分情報一時蓄積部 3205のデータ構造 は、差分情報蓄積部 3203と同様に、クライアントから受信したクエリと該クエリが属す るトランザクションの IDと力 なる。
[0435] サーバ制御部 3210は、同期化処理中にクライアント 3500からクエリを受信すると、 更新系のもののみを順次、差分情報一時蓄積部 3205に蓄積するとともに、正常稼 働中のサーバ 3100に転送する。一方、更新係以外のものについては、差分情報一 時蓄積部 3205に蓄積することなく正常稼働中のサーバ 3100に転送する。
[0436] ここで、サーバ制御部 3210は、正常稼働中のサーバ 3100から更新クエリの実行 が失敗したことを示す応答パケットを受信すると、当該更新クエリを差分情報一時蓄 積部 3205から削除する。また、正常稼働中のサーバ 3100からトランザクションの RO LLBACKが正常に完了したことを示す応答パケットを受信すると、サーバ制御部 32 10は、当該トランザクションに属する全ての更新クエリを差分情報一時蓄積部 3205 力も削除する。一方、正常稼働中のサーバ 3100からトランザクションの COMMITが 正常に終了した応答パケットを受信すると、サーバ制御部 3210は、当該トランザクシ ヨンに属する更新クエリについて差分情報一時蓄積部 3205から差分情報蓄積部 32 03に順次移動させる。
[0437] 以上のような処理により差分情報蓄積部 3203には、正常稼働中のサーバ 3100で COMMITされた更新クエリのみ力 その処理された順番で蓄積される。したがって、 後に新規サーバ 3100から差分情報転送要求があったら、差分情報蓄積部 3203に 記憶されて ヽる差分情報を蓄積されて ヽる順番で新規のサーバ 3100に転送すれば よい。なお、新規のサーバ 3100のデータベース 3101は、仲介装置 3200からの更 新クエリを順次処理するのみなので、この更新クエリはオートコミットモードで処理する
[0438] このように、本実施の形態によれば、同期化処理には不要の参照系クエリ、 BEGI Nや ROLLBACKなどのトランザクション制御 SQLを差分情報蓄積部 3203に蓄積 することがないので、第 1の実施形態と比較すると、差分情報の転送時間及びサーバ での処理時間を短縮ィ匕できる。他の効果については第 12の実施の形態と同様であ る。
[0439] なお、本実施形態では、クライアント 3500から受信したクエリは、当該クエリの属す るトランザクションが正常稼働中のサーバ 3100で COMMITされた時点で、差分情 報一時記憶部 205から差分情報記憶部 203へ移動されて 、たが、その変形例として 、当該クエリが正常稼働中のサーバ 3100で正常処理された時点で移動するようにし てもよい。この場合には、トランザクションが ROLLBACKしたら該トランザクションに 属する更新クエリを差分情報記憶部 203から削除すればよい。このような処理は、例 えば PostgreSQLのように、更新順序によって行の順番が変わる DBMSのデータべ ースを完全一致させるために有効である。
[0440] (第 15の実施の形態）
本発明の第 15の実施の形態に係る多重化データベースシステムについて説明す る。本実施の形態に係る多重化データベースシステムが第 12の実施の形態と異なる 点は、差分情報蓄積部の構造にある。他の構成'動作等については第 12の実施の 形態と同様なので、ここでは相違点のみを説明する。
本実施の形態に係る仲介装置 3200は、図 101に示すように、第 12の実施の形態 とは異なり差分情報蓄積部 3203は設けず、送信キュー 3206に第 1の実施形態にお ける差分情報蓄積部 3203と送信キュー 3204の機能を統合させている。
[0441] 本実施の形態に係る送信キュー 3206のデータ構造について図 102を参照して説 明する。送信キュー 3206は、クライアント 3500から受信したクエリの内容と、そのタエ リの属するトランザクション IDと、各サーバ 3100への送信状態とを記憶する。トランザ クシヨン IDは、第 12の実施の形態と同様に、トランザクション管理表 3202から取得さ れる。各サーバ 3100への送信状態は、システムに属する各サーバ 3100毎に記憶さ れる。
[0442] 送信キュー 3206の各サーバ 3100への送信状態は、「未送信」， 「送信完了」， 「保 留」の 3つの値を取りうる。「未送信」は、クライアント 3500から受信したクエリが未だ当 該サーバ 3100に送信されていない状態である。「送信完了」は、当該サーバ 3100 への送信が完了した状態である。「保留」は、新規サーバ 3100のシステムへの組み 込み処理中に、当該サーバ 3100へ転送されることなく保留されている状態である。 全てのサーバ 3100についての送信状態が「送信完了」になると、当該エントリは送信 キュー 3206から削除される。
[0443] 次に、サーバ制御部 3210の動作について説明する。サーバ制御部 3210は、クラ イアント 3500からクエリを受信すると、当該クエリがトランザクション開始 SQL (BEGI N)の場合は当該トランザクションに対して新たなトランザクション IDを振り出してトラン ザクシヨン管理表 3202に登録する。そして、当該クエリ内容，新規トランザクション ID ,各サーバ 3100の送信状態を「未送信」で送信キュー 3206に登録する。また、クラ イアント 3500から受信したクエリがトランザクション開始 SQL (BEGIN)以外の場合 は、当該クエリの属するトランザクション IDをトランザクション管理表 3202から取得し、 当該クエリ内容，トランザクション ID,各サーバ 3100の送信状態を「未送信」で送信 キュー 3206に登録する。
[0444] サーバ制御部 3210は、送信キュー 3206に記録されているクエリを、その送信状態 が「未送信」となっているサーバ 3100に対して送信し、当該サーバ 3100についての 送信状態を「送信完了」に変更する。全てのサーバ 3100について送信状態が「送信 完了」になったクエリにつ 、ては送信キュー 3206から削除する。
[0445] 仲介装置 3200からクエリを受信した各サーバ 3100は、当該クエリの処理を行い、 応答パケットを仲介装置 3200に返す。仲介装置 3200のサーバ制御部 3210は、各 サーバ 3100から受信した応答パケットを対比して障害発生の有無を確認し、正常な 応答パケットの 1つをクライアント 3500に返す。
[0446] 一方、サーバ 3100から正当でない応答が仲介装置 3200に返ってきたり、応答そ のものが返ってこない場合には、当該サーバ 3100に障害が発生したものとしてシス テム力も切り離す。具体的には、サーバ管理表 3201における当該サーバの稼働状 態を「down」に変更するとともに、送信キュー 3206の送信状態の欄について当該サ ーバに関する項目を削除する。図 103は、送信キュー 3206が図 102に示すような状 態でサーバ 3100bがシステム力も切り離された場合の送信キュー 3206の一例であ る。
[0447] 次に、新規サーバ 3100からデータベース同期化要求（システムへの組み込み要求 )を受信した場合の動作について説明する。サーバ制御部 3210は、第 12の実施の 形態と同様に、データベース同期化要求受信時に実行中のトランザクションが終了 するまで、新規トランザクションの開始は保留する。具体的には、クライアント 3500か ら受信したクエリが新規トランザクションに係るものの場合には、送信状態を「保留」と して送信キュー 3206に保存する。一方、クライアント 3500から受信したクエリがデー タベース同期化要求時に実行中のトランザクションに係るものの場合には、送信状態 を「未送信」として送信キュー 3206に保存する。図 104は、送信キュー 3206が図 10 3に示すような状態でクライアント 3500から新たにクエリを受信した場合の送信キュー 3206の一例である。図 104の例では、三行目のトランザクション ID = 3の BEGINを 除 、て上のクエリから順に（古!/、クエリから順に）、トランザクション ID = 2の SELECT ,トランザクション ID= 1の COMMIT,トランザクション ID = 2の COMMITの順に正 常稼働中のサーバ 3100aへ転送され、その送信状態が「未送信」から「送信完了」に 変更される。トランザクション ID= 3の BEGINは、新規のサーバ 3100bからスナップ ショット作成完了通知を受けた後に転送されることになる。
[0448] そして、データベース同期化要求受信時に実行中のトランザクションに係るクエリを 全て正常稼働中のサーバ 3100に送信し終えると、サーバ制御部 3210は、送信キュ 一 3206に組み込み対象である新規のサーバ 3100の項目を追加する。ここで、送信 キュー 3206には送信状態が「保留」となっているクエリが記憶されている場合がある 。この場合、サーバ制御部 3210は、送信キュー 3206に記憶されているクエリーに対 して、新規サーバ 3100についての送信状態を「保留」とする。図 105は、図 104の送 信キュー 3206に対して新規サーバ 3100bの登録をした場合を示している。また、サ ーバ制御部 3210は、データベース同期化要求受信時に実行中のトランザクションに 係るクエリを全て正常稼働中のサーバ 3100に送信し終えると、第 12の実施の形態と 同様に、正常稼働中のサーバ 3100に対して同期化指示 (スナップショットの作成指 示）を送出する。
[0449] サーバ制御部 3210は、正常稼働中のサーバ 3100からスナップショット作成完了 通知を受信すると、正常稼働中のサーバ 3100へのクエリの送信を再開する。具体的 には、まず送信キュー 3206に記憶されている全てのクエリ（この時点では全てのタエ リの送信状態は全てのサーバ 3100について「保留」になっている）について、正常稼 働中のサーバ 3100の送信状態を「未送信」に変更する。そして、サーバ制御部 321 0は、送信状態が「未送信」のクエリを当該サーバ 3100に順次送信し、送信が完了し たら送信状態を「送
信完了」に修正する。また、新たにクライアント 3500から受信したクエリは、正常稼働 中のサーバ 3100についての送信状態は「未送信」、新規のサーバ 3100についての 送信状態は「保留」にして送信キュー 3206に記憶する。図 106は、図 105の送信キ ユー 3206に対してスナップショット完了通知受信後に新たなクエリを受信した場合を 示している。また、図 107のように、正常稼働中のサーバ 3100aに対しては「送信完 了」となっても新規のサーバ 3100bに対しては「送信完了」になって!/、な ヽ（「保留」 になっている）ので、送信キュー 3206から当該クエリは削除しない。
[0450] 新規のサーバ 3100が正常稼働中のサーバ 3100から受信したスナップショットを用 いてデータベース 3101の復元が完了すると、サーバ制御部 3210は新規のサーバ 3 100から差分情報転送要求を受信する。サーバ制御部 3210は、送信キュー 3206 に記憶されて 、るクエリであって、送信状態が「保留」となって！/、るものを当該「保留」 となっていたサーバ 3100、すなわち新規のサーバ 3100に古いもの力も順次送信す る。送信したクエリについては、送信キュー 3206における当該サーバ 3100の送信 状態を「送信完了」にし、全てのサーバ 3100についての送信状態が「送信完了」に なったら当該エントリは削除する。なお、送信状態が「保留」となっているクエリの送信 中にクライアント 3500からクエリを受信した場合、正常稼働中のサーバについては送 信状態を「未送信」、新規のサーバ 3100については送信状態を「保留」にして、当該 クエリを送信キュー 3206に記憶する。
[0451] サーバ制御部 3210は、送信状態が「保留」となっているクエリが送信キュー 3206 に存在しなくなると、サーバ管理表 3201に新規のサーバ 3100を「active」として追 加することで、当該サーバ 3100をシステムに組み込む。以降の動作は各サーバ 310 0が正常動作して 、る場合のものと同様になる。
[0452] 以上のように本実施の形態に係る仲介装置 3200では、第 12の実施の形態におけ る差分情報蓄積部 3203と送信キュー 3204の機能を、 1つの送信キュー 3206に統 合しているので、メモリの利用効率や処理効率が向上する。また、送信キュー 3206 の各クエリに対して、各サーバ 3100への送信状態を記憶するようにしているので、新 規サーバ 3100を組み込む際には当該サーバ 3100の送信状態を追加すればよい。 これにより、一度に複数台のサーバ 3100をシステムに組み込むことができる。他の作 用効果については第 12の実施の形態と同様である。
[0453] なお、本実施の形態は、第 12の実施の形態の変形例として説明したが、上記第 2 〜第 14の実施の形態において同様の変形を適用できることは言うまでもない。 [0454] (第 16の実施の形態）
本発明の第 16の実施の形態に係る多重化データベースシステムについて説明す る。本実施の形態に係る多重化データベースシステムが第 15の実施の形態と異なる 点は、差分情報の蓄積方法にある。他の構成'動作等については第 15の実施の形 態と同様なので、ここでは相違点のみを説明する。
[0455] 上述の第 1の〜第 15の実施の形態では、仲介装置 3200が正常稼働中のサーバ 3 100にスナップショットの作成指示を送信するタイミングは、正常稼働中のサーバ 31 00において実行中のトランザクションが無くなったときである。具体的には、新規サー ノ 3100からのデータベース同期化要求を受信した時点で実行中のトランザクション について正常稼働中のサーバ 3100で処理を行うのと並行して、データベース同期 化要求受信時以降にクライアント 3500から受信した新規トランザクションの開始要求 を保留していた。そして、データベース同期化要求を受信した時に実行中のトランザ クシヨンが無くなった時点で、スナップショットの作成指示を送信している。これは、 D BMSによっては、スナップショット作成時にトランザクションが実行中だと、そのトラン ザクシヨンに属する更新クエリによるデータ更新力 Sスナップショットに反映される力否 かが不確定となる場合を考慮したためである。
[0456] 一方、本実施の形態では、サーバ 3100として、スナップショット作成時に実行中の トランザクションに属する更新クエリ及びスナップショット作成処理中に受信した更新 クエリについては、当該スナップショットには反映しないという動作を行うものを用いる 。すなわち、もしスナップショット作成中にトランザクションが終了し COMMITされても 、そのトランザクションによる更新はスナップショットに反映されない。これにより、本実 施の形態に係る仲介装置 3200のサーバ制御部 3210は、データベース同期化要求 受信時に実行中のトランザクションの終了を待つことなぐスナップショット作成指示の 送信及び新規トランザクションの開始を行うことができる。なお、仲介装置 3200がス ナップショット作成完了を待つ必要がないので、サーバ 3100のデータベース制御部 3102は、スナップショット作成が完了しても仲介装置 3200には完了通知を送信する 必要はない。
[0457] このような処理を行うため、本実施の形態に係る仲介装置 3200のサーバ制御部 32 10は、送信キュー 3206に記憶されている各クエリについて、全てのサーバ 3100に ついて送信状態が「送信完了」となり、且つ、当該クエリに属するトランザクションが終 了した場合に、当該クエリの登録を削除する。
[0458] 以下、新規サーバ 3100をシステムに組み込む際の動作について図 108〜図 112 を参照して説明する。いま、システムにはサーバ 3100aのみが組み込まれており、こ れカも新たにサーバ 3100bを組み込むものとする。
[0459] サーバ制御部 3210は、新規サーバ 3100bからデータベース同期化要求を受信す ると、正常稼働中のサーバ 3100aに対して同期化指示 (スナップショット作成指示)を 送信する。新規サーバ 3100bが仲介装置 3200に対してデータベース同期化要求 を送信した際の送信キュー 3206の一例を図 108に示す。前述したように、送信キュ 一 3206に記憶されたクエリは、当該クエリが送信完了しても該クエリの属するトランザ クシヨンが完了していないものは削除されずに残っている。同期化指示を受信したサ ーノ 3100aは、スナップショットの作成を開始する。ここで作成されるスナップショット は、送信キュー 3206に記憶されているクエリは反映されていないものである。また、 サーバ制御部 3210は、新規サーバ 3100bからデータベース同期化要求を受信す ると、送信キュー 3206に記憶されている全てのクエリについて、当該新規サーバ 31 00bの送信状態を「保留」にして追加する。この時の、送信キュー 3206の一例を図 1 09に示す。
[0460] サーバ制御部 3210は、データベース同期化要求受信時以降にクライアント 3500 からクエリを受信すると、正常稼働中のサーバ 3100aについては送信状態を「未送 信」、新規サーバ 3100bについては送信状態を「保留」にして送信キュー 3206に順 次追加する。そして、送信状態が「未送信」となっているクエリについては当該「未送 信」のサーバ 3100aに対して順次転送し、送信状態を「送信完了」に変更していく。こ のとき、図 110に示すように、送信キュー 3206に記憶されているクエリは、正常稼働 中のサーバ 3100aについてはトランザクション単位で送信状態が「送信完了」となつ ているが、新規サーバ 3100bについては「保留」となっているので、ここではクエリの 削除は行わない。
[0461] 一方、仲介装置 3200からスナップショットの作成指示を受信したサーバ 3100aは、 作成したスナップショットを新規のサーバ 3100bに送信する。新規のサーバ 3100b のデータベース制御部 3102bは、受信したスナップショットからデータベース 3101b を復元し、仲介装置 3200に差分情報転送要求を送信する。
[0462] 差分情報転送要求を受信したサーバ制御部 3210は、送信キュー 3206に記憶さ れて 、る送信状態が「保留」となって!/、るクエリを差分情報として順次新規サーバ 31 00bに送信し、図 111に示すように、送信状態を「送信完了」に変更する。そして、前 述したように、全てのサーバについて送信状態が「送信完了」となり、且つ、当該タエ リのトランザクションが完了したら、そのクエリを削除する。以降、送信状態が「保留」の クエリの送信中にクライアント 3500からクエリを受信すると、図 112に示すように、正 常稼働中のサーバ 3100aの送信状態を「未送信」，新規サーバ 3100bの送信状態 を「保留」で送信キュー 3206へ記憶する。そして、送信状態力 ^保留」のクエリが無く なった時点でデータベース 3101aとデータベース 3101bの同期が完了したことにな る。
[0463] 本実施形態によれば、システムで用いるサーバ 3100の機能的要件が限定される ためサーバ選択の幅が狭くなるものの、仲介装置 3200での処理が簡略ィ匕されるの で処理効率の高 、ものとなる。
[0464] なお、本実施の形態では、サーバ 3100として、 (1)トランザクション実行中でもスナ ップショットの作成開始ができ、（2)スナップショット作成中にクエリを処理可能であり 且つ当該クエリがスナップショットに反映されないものを用いた力 (1 ')トランザクショ ン実行中でもスナップショットの作成開始ができる力 （2')スナップショット作成中に はクエリを処理できな!/ヽ又はスナップショット作成中にクエリを処理すると当該処理が スナップショットに反映される場合があるようなサーバ 3100を用いることもできる。
[0465] ただし、この場合には、新規サーバ 3100からデータベース同期化要求を受信する と直ちに正常稼働中のサーバ 3100に対してスナップショット作成指示を送信してよ いが、スナップショット作成開始力も作成完了までは正常稼働中のサーバ 3100に対 するクエリの送信を保留する必要がある。つまり、スナップショット作成中にクライアン ト 3500から受信するクエリは送信キューに保持しておく。また、仲介装置 3200がス ナップショットの作成完了を認識するために、スナップショットの作成が完了したサー ノ 3100は、スナップショット作成完了を仲介装置 3200に通知する必要がある。これ により、本実施の形態よりもサーバ選択の幅が広いものとなる。
[0466] (第 17の実施の形態）
本発明の第 17の実施の形態に係る多重化データベースシステムについて説明す る。本実施の形態に係る多重化データベースシステムが第 12の実施の形態と異なる 点は、第 12の実施の形態では同期化処理中におけるクライアントからのクエリの処理 とスナップショットの作成を同一のサーバで行って 、たが、本実施の形態ではそれぞ れ別のサーバで行うところにある。このため、図 113に示すようにサーノ 3100は 3台 以上必要になる。他の構成'動作等については第 12の実施の形態と同様なので、こ こでは相違点のみを説明する。
[0467] 以下に本実施の形態に係る多重化データベースシステムにおけるデータベース同 期化処理時の動作について図 114〜図 122を参照して説明する。
今、データベース 3101cはデータベース 3101a及び 101bと同期がとれていない 状態、つまり、同一ではない状態とする。例えば、データベース 3101cは、再起動直 前のデータ又は障害発生直前のデータを保持して 、る力もしれな 、し、全く新 ヽサ ーバの場合には、データを全く持っていない状態力もしれない。本発明では、前者の 場合でも古いデータは削除し、データベース 3101cはデータを全く保持していない ものとしてシステムに組み込む。
[0468] ここでは、サーバ管理表 3201は図 117のようになっているとする。また、トランザク シヨン管理表 3202と差分情報蓄積部 3203は空であるとする。
[0469] 図 114に示すように、クライアント 3500aが 172.17.1.1宛のトランザクション開始 SQL
(BEGIN)を含んだパケットを送信すると、仲介装置 3200はそのパケットを受信する (ステップ S3500)。サーバ制御部 3210は、トランザクションが開始されたことを検知 し、トランザクション管理表 3202にクライアント 3500aの IPアドレスとトランザクション 番号を登録する（ステップ S3501)。図 118にこのときのトランザクション管理表 3202 を示す。サーバ制御部 3210は、受信したクエリを送信キュー 3204に入れる。そして 、送信キュー 3204から当該クエリを取り出し、サーバ管理表 3201を見て正常稼働し ているサーバ、この場合、サーバ 3100a及び 101bへ該パケットを転送する（ステップ S3502, S3503)。次いで、送信キュー 3204の送信状態を「送信完了」にして当該 エントリを削除する。仲介装置 3200は、応答パケットを各サーバ 3100から受信する と (ステップ S3504, S3505)、各応答パケットを比較して障害有無をチヱックし (ステ ップ S3506)、正当な応答パケットの 1つをクライアント 3500aへ転送する（ステップ S 3507)。
[0470] ここで、新規サーバ 3100cは再起動されたものとする。これにより、サーバ 3100cの データベース制御部 3102cは、データベース同期化要求 (組込要求）を仲介装置 32 00へ送信する（ステップ S3508)。
[0471] データベース同期化要求を受信したサーバ制御部 3210は、トランザクション管理 表 3202をチェックし現在実行中のトランザクションが存在するかどうかを確認するとと もに、実行中トランザクションの情報を記録しておく（ステップ S3509)。図 118より、ク ライアント 3500a,トランザクション番号 3のトランザクションが実行中なので、データべ ース同期化動作はこのトランザクションの終了を待つと同時に、新しいトランザクション 開始要求を受け取った場合は、その要求をサーバ 3100へ転送することを遅らせる（ ステップ S3510)。つまり、同期化動作は実行中のトランザクションが全くない状態で 始める。この新規トランザクションの開始要求についての転送遅延処理は、送信キュ 一 3204での保留という手段で実現する。
[0472] 次に、クライアント 3500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S3511)。サーバ制御部 3210は、 受信したクエリを送信キュー 3204に入れる。このクエリは前記ステップ S3509で記憶 したトランザクション情報を参照することでデータベース同期化要求時に実行してい たトランザクションに属するものと判定できるので、サーバ制御部 3210は、送信キュ 一 3204から当該クエリを取り出し、サーバ管理表 3201を見て正常稼働しているサ ーノ 、この場合、サーバ 3100a及び 3100bへ該パケットを転送する（ステップ S3512 , S3513) 0次いで、送信キュー 3204の送信状態を「送信完了」にして当該エントリ を削除する。仲介装置 3200は、正常稼働中の各サーバ 3100a及び 3100bから応 答パケットを受信 (ステップ S3514, S3515)するまで待ち、各応答パケットが揃うと 該パケットから障害の有無を判定する (ステップ S3516)。そして、サーバ制御部 321 0は、正当な応答パケットの 1つをクライアント 3500aへ転送する（ステップ S3517)。
[0473] 次に、クライアント 3500bが 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を 含んだパケットを送信すると、仲介装置 3200はそのパケットを受信する (ステップ S3 518)。サーバ制御部 3210は、このパケットによりトランザクションが開始されたことを 検知し、トランザクション管理表 3202にクライアント 3500bの IPアドレスとトランザクシ ヨン番号を登録する（ステップ S3519)。図 119にこのときのトランザクション管理表 32 02を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー 3204 に入れる。しかし、この時点では同期化処理準備のため、新規トランザクション開始ク エリは送信キュー 3204に保持したまま、正常稼働中のサーバ 3100a, 3100bへは 転送しな!、（ステップ S3520)。
[0474] 次に、クライアント 3500aは、テーブル test— tableへの更新を確定する SQL (CO MMIT)を含んだパケットを 172.11.1.1へ送信する（ステップ33521)。サーバ制御部 3210は、受信したクエリを送信キュー 3204に入れる。このクエリは前記ステップ S35 09で記憶したトランザクション情報を参照することでデータベース同期化要求時に実 行していたトランザクションに属するものと判定できるので、サーバ制御部 3210は、 送信キュー 3204から当該クエリを取り出し、サーバ管理表 3201を見て正常稼働して いるサーバ、この場合、サーバ 3100a及び 3100bへ該パケットを転送する（ステップ S3522, S3523)。次いで、送信キュー 3204の送信状態を「送信完了」にして当該 エントリを削除する。仲介装置 3200は、正常稼働中の全てのサーバ 3100a及び 31 00bから応答パケットを受信 (ステップ S3524, S3525)するまで待ち、全ての応答パ ケットが揃ったら該パケットから障害の有無をチェックする (ステップ S3526)。また、 C OMMITが正常に完了したことから、トランザクションが終了したことが分力るので、サ ーバ制御部 3210はトランザクション管理表 3202からこのトランザクションの登録を削 除する（ステップ S3527)。この時のトランザクション管理表 3202を図 120に示す。サ ーバ制御部 3210は正当な応答パケットの 1つをクライアント 3500aへ転送する（ステ ップ S3528)。
[0475] ここで、新規サーバ 3100cからのデータベース同期化要求時に実行していたトラン ザクシヨンが全て無くなつたので、サーバ制御部 3210は同期化動作を開始する (ス テツプ S3529)。具体的には、まず、サーバ制御部 3210は、正常稼働中のサーバ 3
100a及び 3100bの中から同期化用サーバ 3100を 1つ選定する（ステップ S3530)
。本実施の形態ではサーバ 3100bを選択したものとする。そして、同期化用サーバ 3
100bに対して同期化指示 (スナップショット作成指示）を送出する (ステップ S3531)
。また、サーバ管理表 3201のサーバ 3100bについて状態を「sync」に変更し、サー ノ 3100bをー且システムから切り離す (ステップ S3532)。ここで、サーバ管理表 320
1の状態「sync」とは、当該サーバ 3100が同期処理中であることを意味する。この時 のサーバ管理表 3201を図 121に示す。なお、前記ステップ S3529において、トラン ザクシヨン管理表 3202に記録されているトランザクションがデータベース同期化要求 時に実行中であったもの力、又は、その後にクライアント 3500から受信したものかを 判定するには、前記ステップ S3509で記録しておいたデータベース同期要求時のト ランザクシヨン情報を参照すればよ 、。
[0476] 同期化指示を受け取った同期化用サーバ 3100bのデータベース制御部 3102bは
、データベース 3101bのスナップショットを作り出す (ステップ S3533)。ここで、このス ナップショットは、同期化指示を受け取った時点でのデータベース全体のバックアツ プデータやデータベースを復元するための情報であり、同期化指示後の更新は反映 されて 、な 、ことに注目すべきである。
[0477] 同期化用サーバ 3100bのデータベース制御部 3102bは、スナップショット作成が 完了すると (ステップ S3534)、作成したスナップショットを新規サーバ 3100cへ転送 する。このスナップショットの転送とデータベースの復元は、データベース 3101bのサ ィズが大きければ大きいほど時間が力かる力 クライアントからのデータベースァクセ スと並行して実行されるのでクライアントに対するサービスを止めることはない。
[0478] 新規サーバ 3100cのデータベース制御部 3102cは、同期化用サーバ 3100bから 受信したスナップショットからデータベースを復元する（ステップ S3535)。
[0479] 仲介装置 3200のサーバ制御部 3210は、サーバ 3100bについてサーバ管理表 3 201の状態を「sync」に変更すると（前記ステップ S3532)、クライアント 3500へのサ 一ビスを再開する。ここで、クライアント 3500から処理要求を処理するサーバは、状 態が「&(^^^」のサーバ3100&でぁる。つまり、同期化用サーバ 3100bは、一時的に システム力も切り離され専ら同期化処理のみを行うことになる。また、ここでは、処理 せずに送信キュー 3204に保持して!/、た、クライアント 3500bからの BEGINを含んだ パケットの処理を再開する。すなわち、サーバ制御部 3210は、転送せずに保持して V、たクライアント 3500bからの BEGIN SQLを含んだパケットを送信キュー 3204か ら取り出して差分情報蓄積部 3203に保存するとともに (ステップ S3535)、正常稼働 中のサーバ 3100aへ転送する（ステップ S3536)。次いで、送信キュー 3204の送信 状態を「送信完了」にして当該エントリを削除する。
[0480] 正常稼働中のサーバ 3100aは、応答パケットを仲介装置 3200に送信し、仲介装 置 3200がこの応答パケットを受信する（ステップ S3537)。仲介装置 3200は、この 応答パケットをクライアント 3500bへ転送する（ステップ S3538)。
[0481] 次!、で、クライアント 3500bがテーブル test_tableの更新 SQL (UPDATE)のパ ケットを仲介装置 3200に送信すると (ステップ S3539)、サーバ制御部 3210は、受 信したクエリを送信キュー 3204に入れる。そして、送信キュー 3204から当該クエリを 取り出し、当該クエリを差分情報蓄積部 3203に保存するとともに (ステップ S3540)、 正常稼働中のサーバ 3100aに当該パケットを送信する (ステップ S3541)。次いで、 送信キュー 3204の送信状態を「送信完了」にして当該エントリを削除する。ここで、 サーバ 3100aは UPDATEに失敗し、その旨を通知する応答パケットを仲介装置 32 00に送信したものとする (ステップ S3542)。仲介装置 3200は、この応答パケットをク ライアン卜 3500bに送信する（ステップ S3543)。
[0482] UPDATE失敗の応答パケットを受信したクライアント 3500bは、トランザクションを 取り消す SQL (ROLLBACK)のパケットを仲介装置に送信する（ステップ S3544)。 サーバ制御部 3210は、受信したクエリを送信キュー 3204に入れる。そして、送信キ ユー 3204から当該クエリを取り出し、当該 SQLを差分情報蓄積部 3203に保存する とともに (ステップ S3545)、正常稼働中のサーバ 3100aに当該パケットを送信する（ ステップ S3546)。次いで、送信キュー 3204の送信状態を「送信完了」にして当該ェ ントリを削除する。そして、サーバ 3100aから正常にトランザクションが ROLLBACK されたことを通知する応答パケットを受信すると (ステップ S3547)、トランザクション管 理表 3202から当該トランザクションの登録を削除するとともに (ステップ S3548)、こ の応答パケットをクライアント 3500bに送信する（ステップ S3549)。この時点での差 分情報蓄積部 3203を図 122に示す。また、トランザクション管理表 3202は空になる
[0483] ここで、新規サーバ 3100cにおいてスナップショットからのデータベース 3101cの 復元が完了したものとする（ステップ S3550)。新規サーバ 3100cはデータベース 31 01 cの復元が完了すると差分情報転送要求を仲介装置 3200に送信する (ステップ S 3551)。仲介装置 3200のサーバ制御部 3210は、差分情報転送要求を受信すると 、差分情報蓄積部 3203に蓄積されているデータを古いものから順に新規サーバ 31 00c及び同期化用サーバ 3100bに転送する処理を開始する（ステップ S3552)。
[0484] 前記ステップ S3552で差分情報蓄積部 3203に蓄積されている全てのクエリが転 送 ·処理されることでデータベース 3101aとデータベース 3101b及び 101cとは完全 に一致した状態（同期状態）になるが、この転送処理中にクライアント 3500から新た なクエリを受信する場合がある。例えば、図 116に示すように、仲介装置 3200は、ク ライアント 3500bから新規トランザクションを開始するクエリ（BEGIN)を受信する (ス テツプ S3553)。仲介装置 3200は、当該新規トランザクションをトランザクション管理 表 3202に登録する (ステップ S3554)。そして、当該クエリを送信キュー 3204に入 れる。次いで、送信キュー 3204から当該クエリを取り出し、差分情報蓄積部 3203の 最後に当該クエリを追加するとともに (ステップ S3555)、正常稼働中のサーバ 3100 aに送信する (ステップ S3556)。そして、送信キュー 3204の送信状態を「送信完了」 にして当該エントリを削除する。次いで、サーバ 3100aから応答パケットを受信すると (ステップ S3557)、当該応答パケットをクライアント 3500bに転送する (ステップ S35 58)。
[0485] このように差分情報転送中にクライアント 3500から受信したクエリは、正常稼働中 のサーバ 3100で処理するとともに、差分情報蓄積部 3203に蓄積していく。この処理 を継続していくと、やがて差分情報蓄積部 3203に蓄積されているクエリは全て新規 サーバ 3100c及び同期化用サーバ 3100bに転送され、差分情報蓄積部 3203は空 になり、これを契機に差分情報転送処理が終了する (ステップ S3559)。これによりデ ータベース 3101aとデータベース 3101b及び 101cは完全に一致した状態（同期状 態）となる。以上で同期化処理は完了するので、図 87及び図 89を参照して前述した 第 12の実施の形態と同様に、同期化用サーバ 3100b及び新規サーバ 3100cにつ いてのサーバ管理表 3201の稼働状態をともに activeに変更することでシステムに当 該サーバ 3100b及び 3100cを追加することができる（図 87のステップ S3144,図 89 のステップ S3242)。なお、この時のサーバ管理表 3201を図 123に示す。
[0486] 以上のように本実施の形態によれば、サーバ 3100のデータベース同期化処理の 際には、正常稼働中の複数のサーバ 3100の中から同期化処理用のサーバ 3100を 選定し、この同期化処理用サーバ 3100を用いてスナップショットの作成 ·転送を行つ ているので、これと並行してクライアント 3500からの処理要求を正常稼働中の他のサ ーバ 3100を用いて処理できる。したがって、組込処理とクライアントからの処理要求 に係る処理が異なるサーバで処理されるので負荷が分散されるとともに、スナップショ ットの作成中にもクライアント 3500からの処理要求に応じることができるので、クライア ント 3500に対して円滑なサービスの提供を継続できる。
[0487] なお、本実施の形態は第 12の実施の形態の変形例として説明したが、本実施の形 態に対して更に上述した第 2〜第 5の実施形態における変形を施しても本発明を実 施できる。
[0488] (第 18の実施の形態）
本発明の第 18の実施の形態に係る多重化データベースシステムについて図面を 参照して説明する。本実施の形態に係る多重化データベースシステムが前述の第 1 7の実施の形態と異なる点は、同期化用サーバ及び新規サーバへの差分情報の送 出タイミングにある。
[0489] すなわち、上記第 17の実施の形態では、仲介装置は新規サーバから差分情報転 送要求を受信すると、新規サーバ及び同期化用サーバの双方に同時に差分情報の 送出を行っていた。一方、本実施の形態では、同期化用サーバに対する差分情報の 送出処理と新規サーバに対する差分情報の送出処理とを非同期でそれぞれ並行し て実施する。このため、本実施の形態に係る仲介装置は、複数のサーバに対する差 分情報を互いに独立して蓄積する必要があるので、前述の第 15の実施の形態に係 る仲介装置と同じ構成とした。すなわち、送信キュー 3206において、各サーバ毎に 差分情報を記憶する。
[0490] 仲介装置 3200は、前記各実施の形態とは異なり、新規サーバ 3100からだけでな く同期化用サーバ 3100からも差分情報転送要求を受信する。そして、差分情報転 送要求を受信すると、送信キュー 3206における要求元のサーバについての送信状 態が「保留」となっているクエリを、当該要求元のサーバに順次送出し、当該サーバ についての送信状態を「送信完了」に更新する。そして、差分情報転送要求元のサ ーバにつ 、て「保留」となって 、るクエリの送出が完了すると、当該サーバにっ 、てサ ーバ管理表 3201を更新してシステムに組み込む。差分情報転送処理時におけるク ライアント 3500からのクエリの処理など他の処理については前述した第 15の実施の 形態と同様である。例えば、全てのサーバ 3100について送信状態が「送信完了」に なったクエリは送信キュー 3206から削除する点などは、第 15の実施の形態と同様で ある。
[0491] 同期化用サーバ 3100は、仲介装置 3200から同期化指示 (スナップショット作成指 示）を受信すると、スナップショットの作成を開始する。次に、スナップショットの作成が 完了すると、仲介装置 3200に対して差分情報転送要求を送信するとともに、新規サ ーバ 3100に対するスナップショットの転送を開始する。この差分情報転送要求に応 じて仲介装置 3200から差分情報を順次受信するので、同期化用サーバ 3100はこ の差分情報の処理を行う。
[0492] 次に、新規サーバ 3100をシステムに組み込む際の動作について図 124及び図 12 5のシーケンスチャートを参照して具体的に説明する。
[0493] 今、新規サーバ 3100cが仲介装置 3200にデータベース同期化要求（システムへ の組込要求）を送信し、仲介装置 3200がサーバ 3100bを同期化用サーバとして選 定して、該同期化用サーバ 3100bに同期化指示を送信するとともに (ステップ S360 1)、該サーバ 3100bをシステムから切り離したとする（ステップ S3602)。
[0494] 同期化用サーバ 3100bは、仲介装置 3200から同期化指示を受信すると (ステップ S3601)、スナップショットの作成を開始する（ステップ S3603)。そして、スナップショ ットの作成が完了すると (ステップ S3604)、仲介装置 3200に対して差分情報転送 要求を送信するとともに (ステップ S3605)、当該スナップショットを新規サーバ 3100 cへ転送する処理を開始する（ステップ S 3606)。
[0495] 仲介装置 3200は、同期化用サーバ 3100bから差分情報転送要求を受信すると、 当該サーバ 3100bに対する差分情報の送出を開始する (ステップ S3607)。具体的 には、送信キュー 3206に蓄積されているクエリのうち同期化用サーバ 3100bについ ての送信状態が「保留」となっているものを、古いものから順に同期化用サーバ 3100 bに送信する。そして、当該クエリについて送信キュー 3206における同期化用サー バ 3100bの送信状態を「送信完了」に更新する。
[0496] 同期化用サーバ 3100bへの差分情報転送中に、クライアント 3500からクエリ（図 1 24では UPDATE)を受信すると (ステップ S3608)、仲介装置 3200は当該クエリを 差分情報として記憶する (ステップ S3609)。具体的には、当該クエリを、正常稼働中 のサーバ 3100aについては送信状態を「未送信」で、同期化用サーバ 3100b及び 新規サーバ 3100cについては送信状態を「保留」にして、送信キュー 3206に蓄積 する。次に、仲介装置 3200は、当該クエリを含んだパケットを正常稼働中のサーバ 3 100a【こ転送し (ステップ S3610)、送信キュー 3206のサーノ 3100a【こつ!/、ての送 信状態を「送信完了」に更新する。そして、正常稼働中のサーバ 3100aからの応答 パケット（ステップ S3611)を、要求元のクライアント 3500に返す (ステップ S3612)。
[0497] 新規サーバ 3100cは、スナップショットに基づきデータベース 3101cの復元を完了 すると (ステップ S3613)、仲介装置 3200に対して差分情報転送要求を送信する (ス テツプ S3614)。
[0498] 仲介装置 3200は、新規サーバ 3100cから差分情報転送要求を受信すると (ステツ プ S3614)、当該サーバ 3100cに対する差分情報の送出を開始する (ステップ S36 15)。具体的には、送信キュー 3206に蓄積されているクエリのうち新規サーバ 3100 cにつ 、ての送信状態が「保留」となって 、るものを、古 、もの力 順に新規サーバ 3 100cに送信し、当該クエリについて新規サーバ 3100cの送信状態を「送信完了」に 更新する。本実施の形態は、同期化用サーバ 3100bへの差分情報転送と、新規サ ーバ 3100cへの差分情報転送は、互いに並行して非同期で行うことが特徴的な点で ある。
[0499] 同期化用サーバ 3100b及び新規サーバ 3100cへの差分情報転送中に、クライア ント 3500からクエリ（図 124では INSERT)を受信すると（ステップ S 3616)、仲介装 置 3200は当該クエリを差分情報として記憶する (ステップ S3617)。具体的には、当 該クエリを、正常稼働中のサーバ 3100aについての送信状態を「未送信」にして、同 期化用サーバ 3100b及び新規サーバ 3100cについて送信状態を「保留」で送信キ ユー 3206に蓄積する。次に、仲介装置 3200は、正常稼働中のサーバ 3100aに転 送し (ステップ S3618)、送信キュー 3206のサーバ 3100aについての送信状態を「 送信完了」に更新する。そして、正常稼働中のサーバ 3100aからの応答パケット (ス テツプ S3619)を、要求元のクライアン卜 3500に返す (ステップ S3620)。
[0500] 仲介装置 3200は、同期化用サーバ 3100b又は新規サーバ 3100cについて送信 状態が「保留」となっているクエリが送信キュー 3206からなくなると、差分情報の送出 が完了したことになるので、当該サーバ 3100b, 3100cについてそれぞれサーバ管 理表 3201を更新してシステムに組み込む。
[0501] 通常は、図 125に示すように、同期化用サーバ 3100bへの差分情報送出は新規 サーバ 3100cより先に終了し (ステップ S3621)、仲介装置 3200は、同期化用サー ノ 3100bについてサーバ管理表 3201の稼働状態を activeに変更してシステムに 組み込む（ステップ S3622)。
[0502] 以降、新規サーバ 3100cへの差分情報転送中にクライアント 3500からのクエリ（図 125では UPDATE)は、正常稼働中のサーバ 3100a及び前記ステップ S3622で組 み込まれたサーバ 3100bで処理される。すなわち、まず、当該クライアント 3500から クエリを受信すると (ステップ S3623)、仲介装置 3200は当該クエリを差分情報として 記憶する (ステップ S3624)。具体的には、当該クエリを、正常稼働中のサーバ 3100 a及び 3100bについて送信状態を「未送信」にして、新規サーバ 3100cについて送 信状態を「保留」で送信キュー 3206に蓄積する。次に、仲介装置 3200は、正常稼 働中のサーノ 3100a及び 3100b【こ転送し (ステップ S3625, S3626)、送信キュー 3206のサーバ 3100a及び 3100bについての送信状態を「送信完了」に更新する。 そして、正常稼働中のサーバ 3100a及び 3100bからの応答パケット（ステップ S362 7, S3628)の正当性をチェックし (ステップ S3629)、正しい応答の 1つを要求元のク ライアン卜 3500に返す (ステップ S3630)。 [0503] 次に、仲介装置 3200は、新規サーバ 3100cについて送信状態が「保留」となって いるクエリが送信キュー 3206からなくなると、差分情報の送出が完了したことになる ので (ステップ S3631)、当該新規サーバ 3100cについてサーバ管理表 3201の稼 働状態を「active」で追加してシステムに組み込む (ステップ S3632)。
[0504] 本実施の形態によれば、上記第 17の実施の形態と比較して、同期化用サーバ 31 00のシステムの組込復帰の時期が早くなるので、システムに組み込まれて!/、るサ一 バの数が通常時よりも少なくなつている期間を短縮することができる。したがって、シ ステムの耐故障性が向上する。
[0505] なお、本実施形態では、同期化用サーバ 3100bが新規サーバ 3100cよりも先にシ ステムに組み込まれた例について説明した力 状況によっては新規サーバ 3100cの 方が先にシステムに組み込まれる場合も考えられる。
[0506] 以上、本発明の実施形態につ!、て詳述したが、上記実施の形態は例示的なもので あり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に 示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれる ものである。
[0507] 例えば、各サーバは要求に応じて同じ応答をするならば同じ実装である必要はな い。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラォプ シヨン、ハードウェア力ソフトウェア力 などが異なっていてもよい。サーバには、 Post greSQLなどのフリーソフトウェアや Oracleなどの市販のソフトウェア、独自開発のソ フトウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サー ノ 3100aは PostgreSQLでサーバ 3100bは Oracleでも良い。
[0508] DBMSとしては、巿中品（例えば、 Oracleや PostgreSQL)を使う場合は、データ ベース制御部 3102は、データベース管理部とデータベースサーバ管理部に機能を 分けることによって、巿中品を無改造で使うことができる。データベース管理部は、デ ータベース 3101を直接操作するもので、例えば PostgreSQLの場合は postmaste rや postgresに相当する。データベースサーバ管理部は、仲介装置 3200とデータ ベース管理部の間に介在し、クエリの送受信を中継したりするほかに、他のサーバを 同期化する際のデータベース 3101のスナップショットを作成したり、そのスナップショ ットを他のサーバへ転送したりする処理を行う。
[0509] スナップショットの作成方法は、例えば DBMSが PostgreSQLならば pg— dumpな どのダンプツールやバックアップツールを使って実現する。なお、 pg— dumpは Post greSQLサーバ同士を同期化する場合には有用だ力 異種の DBMS同士 (例えば PostgreSQLと Oracle)を同期化する場合には、 DBMS固有のツールは使わずに、 正常稼働中の DBMSサーバから SELECTクエリで全てのデータを取りだし INSER Tクエリでデータを入れる汎用のツールを使えばよい。
[0510] また、上記実施の形態では、システムへの組み込み要求 (新規サーバのデータべ ース同期化要求）は当該新規サーバ 3100のデータベース制御部 3102が仲介装置 3200へ送信している力 さらに保守端末などの他の装置力も送信可能にしてもよい し、オペレータが仲介装置 3200に直接指示可能としても良い。
[0511] さらに、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが 、ハードウェアで実装しても良い。
[0512] また、上記実施の形態では、仮想サーバ 3800を構成する仲介装置 3200は 1台の みであつたが、複数台設けて冗長性を持たせることにより、より可用性の高い構成と することも可能である。仲介装置を多重化させる技術については、例えば本願出願 人による特開 2003— 345679号公報に記載されたものなどを用いればよい。
[0513] さらに、上記各実施の形態では、データベース一致検査装置 3600を多重化デー タベースシステムの外側、すなわちネットワーク 3400に接続していたが、図 126に示 すように、多重化データベースシステムの内側のネットワーク 3300にデータベース一 致検査装置 3600を接続するようにしてもょ ヽ。
[0514] (第 19の実施の形態）
本発明の第 19の実施の形態に係る多重化データベースシステムについて図面を 参照して説明する。図 131は本実施の形態に係る多重化データベースシステムの全 体構成を説明するブロック図である。
[0515] この多重化データベースシステムは、図 131に示すように、複数のデータベースサ ーバ（以下「サーバ」と言う） 4100と仲介装置 4200とをネットワーク 4300で接続した ものであり、ネットワーク 4400を介して 1以上のクライアントコンピュータ（以下「クライ アント」と言う） 4500及びデータベース一致検査装置 4600からアクセスされるもので ある。本実施の形態では、図 131に示すように、 2台のサーノ lOOa及び 4100bを 有しており、 2台のクライアント 4500a及び 4500b力もアクセスされる。以降の説明に おいて各サーバ 4100を他のサーバ 4100と区別する場合には添え字「a」「b」を付カロ するものとする。クライアント 4500についても同様である。なお、図 131の例では、サ ーバ 4100とクライアント 4500はそれぞれ別々のネットワーク 4300, 4400に接続さ れて 、るが、同じネットワークに接続されて 、てもよ 、。
[0516] 図 131に示すように、仲介装置 4200は、ネットワーク 4400側に IPアドレス
172.17.1.1を持っており、これをデータベースサーバの IPアドレスとして公開している 。クライアント 4500やデータベース一致検査装置 4600はデータベースにアクセスし たいときは IPアドレス 172.17.1.1へクエリを送信し、 IPアドレス 172.17.1.1の仲介装置 4 200からそのクエリに対する応答パケットを受信する。これは、クライアント 4500等に とっては、 IPアドレス 172.17.1.1を持ったデータベースサーバとパケットを送受信して いることと同じである。この IPアドレス 172.17.1.1を持った仮想的なデータベースサー バを仮想サーバ 4800と呼ぶ。この仮想サーバ 4800の目的は、サーバ 4100が冗長 化されていることを隠蔽するためである。つまり、サーバ 4100aとサーバ 4100b両方 が稼働していようとサーバ 4100bがダウンしてサーバ 4100aのみが稼働していようと サーバ 4100aとサーバ 4100bの他に新たなサーバが追加されようとクライアントには 影響は無ぐ動作を変更する必要がない。
[0517] サーバ 4100は、データを保存'管理するデータベース 4101と、データベース 410 1の動作を制御するデータベース制御部 4102とを備えている。
[0518] データベース 4101は、 SQL (Structured Query Language)を解して処理を行う RD BMS (Relational Database Management System)である。このようなデータベース 41 01としては種々のものがあり、例えば The PostgreSQL Global Development Groupによる PostgreSQL (http://www.postgres.org/)や、 Oracle社による Oracl e (登録商標） (http://www.oracle.com)などが挙げられる。
[0519] データベース制御部 4102は、ネットワーク 4300を介して仲介装置 4200から送ら れてくるパケットに基づき動作する。このパケットは、 SQLなどデータベース 4101で の処理に係るもの、同期化処理に係るものに大別される。 SQLなどデータベース 41 01での処理に係るものについては、データベース制御部 4102は、当該パケットをデ ータベース 4101に渡し、データベース 4101からの処理結果を仲介装置 4200に返 す。
[0520] 一方、同期化処理に係るものは、さらに、自身が本システムに組み込まれている場 合のものと、起動時や障害復旧時などこれからシステムに組み込む場合のものとに別 れる。前者については、スナップショットの作成指示（同期化指示）がある。データべ ース制御部 4102は、スナップショット作成指示を仲介装置 4200から受信すると、デ ータベース 4101のスナップショットを作成する。そして、スナップショットの作成が完 了すると、スナップショット作成完了を仲介装置 4200に通知する。そして、作成した スナップショットを、スナップショット作成指示で指示されて 、る転送先の他のサーバ 4 100に転送する。ここで、スナップショットとは、その作成開始時点で確定している（C OMMITされて!/、る）データベース全体の複製データやデータベースを復元するた めに必要なデータを意味する。したがって、スナップショットには、作成開始時点で C OMMITされて!/、な!/、データは含まれな!/、ことに留意すべきである。
[0521] 他方、障害復旧時などこれからシステムに組み込む場合、データベース制御部 41 02は、他のデータベースからスナップショットを受信すると、このスナップショットを用 いて自身のデータベース 4101を復元する。データベース 4101の復元が完了すると 仲介装置 4200に対して差分情報転送要求を送出する。後述するように、差分情報 転送要求に応じて仲介装置 4200から差分情報が転送されるので、この差分情報を 用いてデータベース 4101を復元する。この差分情報とは、仲介装置 4200がクライア ント 4500から受信したクエリのうち前記スナップショットに反映されていないものであり 、仲介装置 4200にお 、て記憶蓄積したものである。
[0522] また、データベース制御部 4102は、仲介装置 4200から再起動指示を受信すると 、データベース 4101及びデータベース制御部 4102の再起動を行う。この再起動処 理は、データベース 4101及びデータベース制御部 4102のプロセスの再起動のみ を行ってもよく、データベース 4101及びデータベース制御部 4102がサーバ 4100の 起動時に自動起動するように設定されて!ヽればサーバ 4100全体の再起動でもよ 、 。さらに、データベース制御部 4102は、自身が起動（再起動を含む）されると、仲介 装置 4200に対してデータベース同期化要求（システムへの糸且込要求）を送信する。
[0523] 仲介装置 4200は、図 132に示すように、本システム内のサーバ 4100を管理する サーバ管理表 4201と、トランザクションを管理するトランザクション管理表 4202と、サ ーバ 4100に送信するクエリを一時保存する送信キュー 4203と、クライアント 4500及 びデータベース一致検査装置 4600からの受信したクエリを送信キュー 4203に投入 する受信クエリ処理部 4204と、送信キュー 4203からクエリを取り出してサーバ 4100 に送信するクエリ送信処理部 4205と、クエリ送信処理部 4205で送信したクエリに対 する各サーバ 4100からの応答の正当性を判定する正当性判定部 4206と、正当性 判定部 4206で正当と判定された応答を要求元のクライアント 4500等に送信する応 答送信処理部 4207と、各サーバ 4100間の同期化処理を制御する同期化処理制御 部 4208とを備えている。
[0524] サーバ管理表 4201は、サーバが正常稼働中でクエリの処理が可能である力 (acti ve)、同期化処理中であるか（sync)、サーバが正常稼働中でクエリの処理が可能で あり且つ同期化処理中であるか（active + sync)という状態情報を保存している。ま た、サーバ 4100がシステム力も切り離された場合には、当該サーバ 4100について のエントリはサーバ管理表 4201から削除される。図 133にサーバ管理表の一例を示 す。サーバ管理表 4201は、図 133に示すように、サーバ 4100を識別するためのサ ーノ IDと、サーバの稼働状態力も構成されている。図 133の例では、サーバ 4100a とサーバ 4100bとが登録されており、稼働状態は共に正常稼働を示す activeである 。また、本実施形態では、サーバ IDとしてサーバ 4100に付された IPアドレスを用い た。
[0525] トランザクション管理表 4202は、現在実行中の又は実行開始を保留されているトラ ンザクシヨンの有無を記憶する。図 134にトランザクション管理表 4202の一例を示す 。図 134に示すように、トランザクション管理表 4202は、クライアントを一意に識別す るクライアント IDとトランザクションを一意に識別するトランザクション ID力も構成される 。これらのペアは、受信クエリ処理部 4204がトランザクション開始時にトランザクション 管理表 4202に登録し、応答送信処理部 4207がトランザクション終了時にトランザク シヨン管理表 4202から削除する。クライアント IDは、例えばクライアント 4500等の IP アドレスやポート番号である。トランザクション IDは新し 、トランザクションが発生する 毎に受信クエリ処理部 4204が新たに割り振る。
[0526] 送信キュー 4203は、クライアント 4500等力も受信したクエリをサーバ 4100に送信 する際の送信バッファとしての機能を有するとともに、同期化処理時にクライアント 45 00から受信したクエリを差分情報として記憶蓄積する機能とを有するものである。
[0527] 送信キュー 4203のデータ構造について図 135を参照して説明する。送信キュー 4 203は、クライアント 4500から受信したクエリの内容と、そのクエリの属するトランザク シヨン IDと、各サーバ 4100への送信状態と、当該クエリが正常稼働中のサーバ 410 0で処理された場合の当該処理結果を記憶する。トランザクション IDは、トランザクシ ヨン管理表 4202から取得される。各サーバ 4100への送信状態は、システムに属す る各サーバ 4100毎に記憶される。
[0528] 送信キュー 4203の各サーバ 4100への送信状態は、「未送信」， 「送信完了」， 「保 留」， 「保留解除」の 4つの値を取りうる。「未送信」は、特に保留することなく当該サー ノ 100に送信予定であるが未だ送信されていない状態である。「送信完了」は、当 該サーバ 4100への送信が完了した状態である。「保留」は、サーバ 4100のシステム への組み込み処理中に、当該サーバ 4100へ転送されることなく保留されている状態 である。「保留解除」は、「保留」状態が解除されたが未送信の状態である。送信キュ 一 4203の各エントリは、全てのサーバ 4100についての送信状態が「送信完了」にな り、且つ、当該クエリの属するトランザクションが終了すると送信キュー 4203から削除 される。
[0529] 受信クエリ処理部 4204は、クライアント 4500及びデータベース一致検査装置 460 0からのクエリをネットワーク 4400経由で受信すると、当該クエリを解析して新規トラン ザクシヨンの開始を検出した場合にはトランザクション管理表 4202に該トランザクショ ンを登録するとともに、サーバ管理表 4201を参照して受信クエリを送信キュー 4203 に投入する。
[0530] 受信クエリ処理部 4204が新規トランザクションの開始を検出する方法は、 DBMS の種類によって異なる。例えば前述の PostgreSQLの場合は、トランザクションの開 始はクライアント 4500等が「BEGIN」という SQLを送信した時であり、トランザクション の終了はクライアント 4500等が「COMMIT」「ROLLBACK」という SQLを送信した 時である。また、 Oracleの場合は、トランザクションの開始はクライアント 4500等が有 効な SQLを送信したときであり（明示的なトランザクションの開始を宣言する SQLは 無い）、トランザクションの終了はクライアント 4500等が「COMMIT」「ROLLBACK 」という SQLを送信した時である。また、サーバ 4100が AUTO COMMITモードで 動作する場合には、クライアント 4500等力も受信した SQL文はそれぞれ 1つの独立 したトランザクションに属して 、ると解釈できるので、クライアント 4500等力も SQLを 受信する毎に、該 SQL実行前にトランザクションが開始されるとともに SQL実行後に 当該トランザクションが終了したこととして扱うことができる。
[0531] 受信クエリ処理部 4204が受信クエリを送信キュー 4203に投入する際には以下の ようにして各サーバ 4100についての送信状態を設定する。サーバ管理表 4201のサ ーバ稼働状態が「active」である場合には、当該サーバ 4100については送信状態 を「未送信」とする。また、サーバ管理表 4201のサーバ稼働状態が「sync」又は「act ive + syncjの場合であって、当該サーバ 4100に対するクエリの転送処理が未だ始 まっていない場合には、当該サーバ 4100については送信状態を「保留」とする。す なわち、本実施の形態では、受信クエリを「保留」として送信キュー 4203に記憶する ことにより、差分情報の蓄積を図っている。また、サーバ管理表 4201のサーバ稼働 状態が「sync」又は「active + sync」の場合であって、当該サーバ 4100に対するク エリの転送処理が始まっている場合には、当該サーバ 4100については送信状態を「 保留解除」とする。
[0532] クエリ送信処理部 4205は、送信キュー 4203を監視して、該送信キュー 4203に送 信状態が「未送信」又は「保留解除」となって 、るクエリを古 、ものから順に取り出し、 対象となるサーバ 4100に対して送信するとともに、送信キュー 4203の送信状態を「 送信完了」に更新する。
[0533] 正当性判定部 4206は、クエリ送信処理部 4205で各サーバ 4100に送信したクエリ に対する応答を受信して当該応答の正当性を判定する。この正当性の判定は、当該 応答の送信元のサーバ 4100の稼働状態が「active」又は「active + sync」であるも のに係る場合には、後述の第 1の正当性判定方法により 1つ以上の応答から 1つの 応答を選定する。他方、当該応答の送信元のサーバ 4100の稼働状態が「sync」で あるものに係る場合には、後述の第 2の正当性判定方法により当該応答の正当性を 判定する。
[0534] 第 1の正当性判定について説明する。この第 1の正当性判定は、一台以上のサー ノ 100間でのクエリ処理の正当性を判定するものである。具体的には、サーバ 410 0が 3台以上ある場合には多数決で決める方法や、受信した応答を所定のルールに 基づいて判断する方法がある。例えば、クライアント 4500からの「参照」要求に対して 「更新成功」 t 、う応答が返ってきた場合、正常であればそのような応答はあり得な 、 ので (参照成功など参照に関する応答のはず)、この応答は正しくないと判断する。ま た、当該応答に係るパケット中にデータ長フィールドがある場合、このデータ長フィー ルドの値と実際に受信したパケット長を比較し、異なる場合は正しくないと判断する。 また、複数のサーバ 4100の中から Masterサーバを予め 1台決めておき、このサー ノ 100からの応答を常に正しいと判断する。また、上記複数の方法を併用する方法 もある。例えば、 3台で多数決を行った結果、応答の中身が全てバラバラであり、多数 派の応答を決められな 、場合は Masterサーバの応答を正 、と判断する。正常稼 働しているサーバ 4100が 1つだけの場合は、そのサーバ 4100からの応答を正常と 判断する。なお、正常稼働しているサーバ 4100の台数はサーバ管理表 4201を参 照することにより認識できる。正当性判定部 4206は、第 1の正当性判定の結果、正 当でない応答を返したサーバ 4100に対して再起動指示を送信するとともに、サーバ 管理表 4201及び送信キュー 4203から該サーバ 4100についてのエントリを削除す る。これにより、当該サーバ 4100にはクエリが送信されなくなるので、該サーバ 4100 はシステム力 切り離されたことになる。
[0535] 第 2の正当性判定について説明する。第 2の正当性判定は、後述するように、同期 化処理時に差分情報としてサーバ 4100に送信したクエリが、他の正常稼働中のサ ーバ 4100と同じ処理を行ったか否かを判定する。第 2の正当性判定において判定 対象となる応答は、該応答に係るクエリをクライアント 4500から受信した際に、該応 答を返したサーバの稼働状態が「sync」となっていたために送信キュー 4203におい てー且「保留」又は「保留解除」となっていたクエリに係るものである。そして、同クエリ は、クライアント 4500から受信した際に、稼働状態が「active」又は「acrive + sync」 である他のサーバ 4100において既に処理されている。後述するように、他のサーバ 4100で処理された当該クエリに対する応答 (処理結果）は送信キュー 4203に保存さ れている。正当性判定部 4206は、サーバ 4100から受信した応答と、送信キュー 42 03に保存されている応答とを比較することにより正当性を判定する。正当性判定部 4 206は、第 2の正当性判定の結果、正当でないと判定した場合、同期化処理を再試 行するために当該サーバ 4100に対して再起動指示を送出する。
[0536] 応答送信処理部 4207は、正当性判定部 4206にお ヽて正当と判断された応答で あって、該応答の送信元サーバ 4100の稼働状態が「active」又は「active + sync」 の場合、当該応答の 1つを処理要求元のクライアント 4500等に返すとともに、該応答 を送信キュー 4203に送信結果として保存する。また、応答送信処理部 4207は、サ ーバ 4100から受信した応答がトランザクションの終了に係るものであるかを検出し、ト ランザクシヨンの終了に係るものである場合には、当該トランザクションについてのェ ントリをトランザクション管理表 4202から削除する。また、応答送信処理部 4207は、 終了したトランザクションに属するクエリであり且つ全てのサーバ 4100の送信状態が 「送信完了」となったものを送信キュー 4203から削除する。また、応答送信処理部 42 07は、「保留解除」のクエリが送信キュー 4203からなくなった場合には、「保留解除」 となっていたサーバ 4100について、サーバ管理表 4201の稼働状態を「active」に 更新する。これにより、当該サーバ 4100はシステムに組み込まれる。なお、システム への組み込みのタイミングは、正常稼働中のサーバ 4100においてクエリの実行中で あっても構わず、またトランザクションが継続中であっても構わない点に留意されたい
[0537] 同期化処理制御部 4208は、システム外のサーバ 4100 (ここでは便宜上「新規サ ーバ 4100」と呼ぶ）をシステムに組み込む際に、該新規サーバ 4100とシステム内で 正常稼働中のサーバとの同期化処理を制御する。ここで、新規サーバ 4100としては 、システムに新たに追加するもの、ー且システム力 切り離され再びシステムに組み 込むものの双方が含まれる。 [0538] 同期化処理制御部 4208は、新規サーバ 4100からデータベース同期化要求（シス テムの組み込み要求）を受信すると、 (1)当該新規サーバ 4100について稼働状態を 「sync」にしてサーバ管理表 4201に追加する、（2)送信キュー 4203の送信状態の 欄に当該新規サーバ 4100についての列を追加する、（3)正常稼働中のサーバ 410 0の中から同期化処理用のサーバを 1台を選定して該サーバ 4100についてサーバ 管理表 4201を更新するとともに、当該サーバ 4100について送信キュー 4203の送 信状態が「未送信」となっているものは「保留」に更新する、（4)同期化処理用のサー ノ 100において実行中クエリの処理が完了するまで待機し、同期化処理用のサー ノ 4100にお!/、て実行中クエリの処理が完了したら該サーバ 4100に対してスナップ ショット作成指示を送出する、という処理を行う。同期化処理制御部 4208は、データ の整合性を維持するために、前記（1)〜 (4)の処理は 1つの処理として取り扱い、排 他制御を行う。つまり、同期化処理制御部 4208は、前記（1)〜 (4)の処理を行って V、る間は、各処理でアクセスするサーバ管理表 4201及び送信キュー 4203に対して 、他の機能ブロック（例えば受信クエリ処理部 4204など)力ものアクセスを中断させる
[0539] 前記（2)において同期化処理制御部 4208は、送信キュー 4203にクエリが残って いる場合には、そのクエリについての新規サーバ 4100の送信状態は「保留」とする。 前述したように、送信キュー 4203のエントリは、トランザクションが終了した際に削除 される。したがって、送信キュー 4203に残っているクエリは、トランザクションが終了し ていないクエリであり、前記 (4)のスナップショット作成指示に呼応して同期化用のサ ーバ 4100で作成されるスナップショットには反映されないものである。前記（2)の処 理では、このクエリについての送信状態を「保留」とすることで該クエリを差分情報とし て保持する。
[0540] 前記（3)において同期化処理制御部 4208は、サーバ管理表 4201を参照して稼 働状態が「active」であるサーバ 4100が 1台の場合には、当該サーバ 4100につい ての稼働状態を「active + sync」に変更する。これは、当該サーバ 4100を、クライア ント 4500からの処理要求を通常時と同様に処理するよう動作させるとともに、新規サ ーバ 4100の同期化処理用として動作させることを意味する。一方、稼働状態が「act ive」であるサーバ 4100が複数ある場合には、所定の選定規則に基づき一台のサー ノ 100を選定して、当該サーバ 4100についての稼働状態を「sync」に変更する。 これは、当該サーバ 4100を、クライアント 4500からの処理要求に対する処理は行わ ず、専ら新規サーバ 4100の同期化処理用として動作させることを意味する。
[0541] 前述したように、仲介装置 4200からスナップショット作成指示を受信した同期化処 理用のサーノ 100はスナップショットの作成を開始し、スナップショットの作成が完 了すると仲介装置 4200に対してスナップショット作成完了通知を送信する。同期化 処理制御部 4208は、同期化処理用のサーバ 4100からスナップショット作成完了通 知を受信すると、送信キュー 4203に記憶されている同期化処理用サーバ 4100の欄 の全てのクエリにつ ヽて送信状態を「保留」から「保留解除」に変更する。これにより、 クエリ送信処理部 4205が同期化処理用のサーバ 4100に対して差分情報としてタエ リの送信を開始する。「保留解除」になっていたクエリの処理が全て終了すると、応答 送信処理部 4207が、当該同期化処理用サーバ 4100について、サーバ管理表 420 1の稼働状態を「active」に更新することにより、同期化処理用のサーバ 4100はシス テムに^ aみ込まれる。
[0542] また、前述したように、スナップショットの作成を完了した同期化用サーバ 4100は、 新規サーバ 4100に当該スナップショットを転送し、新規サーバ 4100は当該スナップ ショットからデータベース 4101の復元を図る。そして、新規サーバ 4100は、データ ベース 4101の復元が完了すると、仲介装置 4200に差分情報転送要求を送出する 。同期化処理制御部 4208は、新規サーバ 4100から差分情報転送要求を受信する と、送信キュー 4203に記憶されて 、る新規サーバ 4100の欄の全てのクエリにつ ヽ て送信状態を「保留」から「保留解除」に変更する。これにより、クエリ送信処理部 420 5が新規サーバ 4100に対して差分情報としてクエリの送信を開始する。「保留解除」 になっていたクエリの処理が全て終了すると、応答送信処理部 4207が、当該新規サ ーバ 4100について、サーバ管理表 4201の稼働状態を「active」に更新することによ り、新規サーバ 4100はシステムに組み込まれる。
[0543] クライアント 4500は、多重化データベースシステムに対して更新クエリ（データべ一 スを更新するリクエスト)や参照クエリ（データベースの内容を参照するリクエスト）など を発行するものである。
[0544] データベース一致検査装置 4600は、クライアント 4500と同様に多重化データべ一 スシステムのクライアントとして動作するものであり、各サーバ 4100のデータベース 4 101が互 ヽに一致して 、るか否かを確認するためのクエリを発行する。このクエリは、 参照系のものであり、例えば所定のテーブル test— tableに対する「SELECT * FROM test— table」などである。データベース一致検査装置 4600は、定期的に 又はオペレータ等の指示に応じて当該検査用クエリの発行を行う。
[0545] 次に、本実施の形態に係る多重化データベースシステムの動作について図面を参 照して説明する。まず、サーバ 4100aと 4100bが正常に動作している場合の動作を 図 136から図 138を参照して説明する。
[0546] 初期状態では、データベース 4101aと 4101bは完全に同一であり、サーバ管理表 4201は図 137のよう〖こなっているものとする。また、トランザクション管理表 4202と送 信キュー 4203は空であるとする。各サーバ 4100a, 4100bには、テーブル test— ta bleが存在しているとする。
[0547] クライアント 4500aが 172.17.1.1宛にトランザクション開始 SQLを含んだパケットを送 信すると、仲介装置 4200の受信クエリ処理部 4204はそのパケットを受信する (ステ ップ S41)。受信クエリ処理部 4204は、トランザクションが開始されたことを検知し、ト ランザクシヨン管理表 4202にクライアント 4500aの IPアドレスとトランザクション番号を 登録する（ステップ S42)。図 138にこのときのトランザクション管理表 4202を示す。そ して、このパケットに係るクエリを、サーバ管理表 4201を参照して正常稼働している サーバ 4100 (ここではサーバ 4100a及び 4100b)について送信状態を「未送信」に して送信キュー 4203に入れる。
[0548] クエリ送信処理部 4205は、送信キュー 4203から送信状態が「未送信」のクエリを 取り出し、対応するサーバ 4100に該パケットを送信する。ここでは、サーバ 4100aと 4100bが正常稼働しているので、サーノ lOOaとサーバ 4100bへ該パケットを転送 する（それぞれステップ S43と S44)。そして、各サーバ 4100への送信が完了したの で各サーバ 4100について送信キュー 4203の送信状態を「送信完了」に更新する。 正当性判定部 4206は、トランザクションが正常に開始されたことを通知する応答パケ ットをサーバ 4100aから受信するが (ステップ S45)、この時点では、未だ全ての応答 ノ ケットが揃って!/、るわけではな 、ので（この場合、サーバ 4100bからの応答パケット が来ていない）、正当性判定部 4206は何もせずにサーバ 4100bからの応答パケット を待つ。そして、トランザクションが正常に開始されたことを通知する応答パケットをサ ーバ 4100bから受信すると（ステップ S46)、これで全ての応答パケットが揃ったので 、正当性判定部 4206はそれらの応答パケットを互いに比較することでサーバ 4100 に障害が発生している力否かをチェックする (ステップ S47)。この場合、 2つの応答 パケットは共にトランザクションが正常に開始されたことを示すパケットであるため、障 害は無いと判断する。そして、応答送信処理部 4207は正当な応答パケットの 1つを クライアント 4500aに返すとともに、該応答を送信キュー 4203に保存する (ステップ S 48)。
次に、クライアント 4500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S49)。受信クエリ処理部 4204は、 サーバ管理表 4201を参照して正常稼働しているサーバ 4100について送信状態を「 未送信」にして送信キュー 4203に入れる。クエリ送信処理部 4205は、送信キュー 4 203から当該クエリを取り出し、各サーバ 4100へパケットを転送し (それぞれステップ S410と S411)、送信キュー 4203の送信状態を「送信完了」に更新する。サーバ 41 00aは正常に UPDATE成功したことを通知する応答パケットを仲介装置 4200に送 信し、仲介装置 4200の正当性判定部 4206がこの応答パケットを受信する (ステップ S412)。この時点では全ての応答パケットが全て揃っているわけではないので、正当 性判定部 4206は何もせず待機する。そして、正常に UPDATE成功したことを通知 する応答パケットをサーバ 4100bから受信すると (ステップ S413)、これで応答バケツ トが全て揃ったので、正当性判定部 4206はそれら応答パケットを互いに比較するこ とでサーバ 4100に障害が発生しているか否かをチェックする（ステップ S414)。この 場合、 2つの応答パケットは共に UPDATE成功したことを示すパケットであるため、 障害は無いと判断する。そして、応答送信処理部 4207は、正当な応答パケットの 1 つをクライアント 4500aへ転送するとともに、該応答を送信キュー 4203に保存する（ ステップ S415)。 [0550] 次に、クライアント 4500aは、テーブル test— tableへの更新を確定する（実際にデ ータベースを更新する） SQL (COMMIT)を含んだパケットを 172.17.1.1へ送信する (ステップ S416)。受信クエリ処理部 4204は、サーバ管理表 4201を参照して正常 稼働しているサーバ 4100について送信状態を「未送信」にして送信キュー 4203に 入れる。クエリ送信処理部 4205は、送信キュー 4203から当該クエリを取り出し各サ ーバ 4100へパケットを転送し（それぞれステップ S417と S418)、送信キュー 4203 の送信状態を「送信完了」に更新する。サーバ 4100aは正常に COMMIT成功した ことを通知するパケットを仲介装置 4200に送信し、仲介装置 4200の正当性判定部 4206がこの応答パケットを受信する（ステップ S419)。この時点では全ての応答パケ ットが全て揃って!/ヽるわけではな 、ので、正当性判定部 4206は何もせず待機する。 そして、正常に COMMIT成功したことを通知する応答パケットをサーバ 4100bから 受信すると (ステップ S420)、これで応答パケットが全て揃ったので、正当性判定部 4 206はそれら応答パケットを互いに比較することでサーバ 4100に障害が発生して ヽ るか否かをチェックする（ステップ S421)。この場合、 2つの応答パケットは共に COM MIT成功したことを示すパケットであるため、障害は無いと判断する。応答送信処理 部 4207は、正当な応答パケットの 1つをクライアント 4500aへ転送するとともに、該応 答を送信キュー 4203に保存する（ステップ S422)。また、 COMMITが正常に完了 したことから、トランザクションが終了したことが分力るので、応答送信処理部 4207は トランザクション管理表 4202からこのトランザクションの登録を削除するとともに (ステ ップ S423)、全てのサーバ 4100について送信状態が「送信完了」となっているクエリ (ここでは、「BEGIN」， 「UPDATE」， 「COMMIT」の 3つのクエリ）を送信キュー 42 03から削除する（ステップ S423)。このときのトランザクション管理表 4202及び送信 キュー 4203は再び初期状態 (すなわち空）になる。
[0551] 次に、サーバ 4100bが故障などで障害になった場合の動作を図 139から図 141を 参照して説明する。初期状態では、データベース 4101aと 4101bは完全に同一であ り、サーバ管理表 4201は前述した図 137のようになっているとする。また、トランザク シヨン管理表 4202と送信キュー 4203は空であるとする。
[0552] クライアント 4500a力 172.17.1.1宛にトランザクション開始 SQL (BEGIN)を含んだ パケットを送信すると、仲介装置 4200の受信クエリ処理部 4204はそのパケットを受 信する (ステップ S430)。受信クエリ処理部 4204は、トランザクションが開始されたこ とを検知し、トランザクション管理表 4202にクライアント 4500aの IPアドレスとトランザ クシヨン番号を登録する (ステップ S431)。図 140にこのときのトランザクション管理表 4202を示す。そして、このパケットに係るクエリを、サーバ管理表 4201を参照して正 常稼働しているサーバ 4100について送信状態を「未送信」にして送信キュー 4203 に入れる。
[0553] クエリ送信処理部 4205は、送信キュー 4203から送信状態が「未送信」のクエリを 取り出し、対応する各サーバ 4100に該パケットを転送する（それぞれステップ S432 と S433)。次いで、送信キュー 4203の送信状態を「送信完了」に更新する。仲介装 置 4200の正当性判定部 4206は、トランザクションが正常に開始されたことを通知す る応答パケットをサーバ 4100aから受信するが (ステップ S434)、この時点では、未 だ全ての応答パケットが揃って 、るわけではな 、ので（この場合、サーバ 4100bから の応答パケットが来ていない）、何もせずにサーバ 4100bからの応答パケットを待つ 。そして、トランザクションが正常に開始されたことを通知する応答パケットをサーバ 4 100bから受信すると (ステップ S435)、これで全ての応答パケットが揃ったので、正 当性判定部 4206はそれら応答パケットを互いに比較することでサーバ 4100に障害 が発生している力否かをチェックする（ステップ S436)。この場合、 2つの応答パケット は共にトランザクションが正常に開始されたことを示すパケットであるため、障害は無 いと判断する。そして、応答送信処理部 4207は、正当な応答パケットの 1つをクライ アント 4500aへ転送するとともに、該応答を送信キュー 4203に保存する（ステップ S4 37)。
[0554] ここで、サーバ 4100bは、ステップ S435で応答パケットを返した後、故障などの障 害が発生してダウンしたものとする（ステップ S438)。
[0555] 次に、クライアント 4500aは、テーブル test— tableを更新する SQL (UPDATE)を 含んだパケットを 172.17.1.1へ送信する (ステップ S439)。受信クエリ処理部 4204は 、サーバ管理表 4201を参照して正常稼働しているサーバ 4100について送信状態 を「未送信」にして送信キュー 4203に入れる。この時点では、仲介装置 4200はサー ノ lOObのダウンを知らないので、サーバ 4100bが正常稼働しているという情報が サーバ管理表 4201に格納されたままである。したがって、受信クエリ処理部 4204は 、サーバ 4100aの欄だけでなくサーバ 4100bの欄にっ 、ても送信状態を「未送信」 にして送信キュー 4203に受信クエリを格納する。クエリ送信処理部 4205は、送信キ ユー 4203から送信状態が「未送信」のクエリを取り出して各サーバ 4100a及び 4100 bにパケットを転送する（それぞれステップ S440と S441)。次いで、クエリ送信処理部 4205は、送信キュー 4203の送信状態を「送信完了」に更新する。サーバ 4100aは 正常に UPDATE成功したことを通知する応答パケットを仲介装置 4200に送信し、 仲介装置 4200の正当性判定部 4206がこの応答パケットを受信する（ステップ S442 ) oこの時点では応答パケットが全て揃っているわけではないので、正当性判定部 42 06は何もせず待機する。し力し、サーノ lOObはダウンしているのでサーバ 4100b 力 の応答パケットはいつまで経っても正当性判定部 4206には届かない。これによ り正当性判定部 4206はタイムアウトし、サーバ 4100bのダウンを検知する。そして、 正当性判定部 4206はサーバ管理表 4201からサーバ 4100bのエントリを削除する（ ステップ S443)。このときのサーバ管理表 4201を図 141に示す。また、サーバ 4100 bについての送信状態の欄を送信キュー 4203から削除する。このときの送信キュー 4 203を図 142に示す。次に、正当性判定部 4206は、システム力も切り離したサーバ 4100bに対して再起動指示を送出する (ステップ S444)。もっとも、ここではサーバ 4 100bはダウンしているので、当該再起動指示に対する処理が行われることはない。 次に、応答送信処理部 4207は応答パケットをクライアント 4500aへ転送するとともに 、該応答を送信キュー 4203に保存する（ステップ S445)。ここでは、クライアント 450 Oaにとつて、サーバ 4100bが障害になったかどうかは認識せず、今までと同様に仮 想サーノ 4800からサービスを受けることができることに注目すべきである。
次に、クライアント 4500aは、テーブル test— tableへの更新を確定する SQL (CO MMIT)を含んだパケットを 172.17.1.1へ送信する（ステップ S446)。受信クエリ処理 部 4204は、サーバ管理表 4201を参照して正常稼働して!/、るサーバ 4100につ!/、て 送信状態を「未送信」にして送信キュー 4203に入れる。ここでは、サーバ 4100aに っ 、てのみ送信状態が「未送信」で送信キュー 4203にクエリが記憶される。そして、 クエリ送信処理部 4205は、送信キュー 4203から当該クエリを取り出し、対応するサ ーノ 、この場合、サーバ 4100aのみへ該パケットを転送する（ステップ S447)。次い で、送信キュー 4203の送信状態を「送信完了」に更新する。サーバ 4100aは正常に COMMIT成功したことを通知する応答パケットを送信し、仲介装置 4200の正当性 判定部 4206がこの応答パケットを受信する (ステップ S448)。ここでは、正常稼働中 のサーバ 4100が 1台のみなので正当性判定部 4206は当該応答パケットを正当と判 断し、応答送信処理部 4207は該応答パケットをクライアント 4500aへ転送するととも に、該応答を送信キュー 4203に保存する（ステップ S449)。また、 COMMITが正 常に完了したことから、トランザクションが終了したことが分力るので、応答送信処理 部 4207はトランザクション管理表 4202からこのトランザクションの登録を削除するとと もに (ステップ S450)、全てのサーバ 4100につ 、て送信状態が「送信完了」となって いるクエリ（ここでは、「BEGIN」， 「UPDATE」， 「COMMIT」の 3つのクエリ）を送信 キュー 4203から削除する（ステップ S450)。このときのトランザクション管理表 4202 及び送信キュー 4203は再び初期状態 (すなわち空）になる。
[0557] ここで、ステップ S447によって、サーバ 4100aのデータベース 4101aは、クライア ント 4500aからの UPDATE (ステップ S439)が反映されているのに対して、サーバ 4 100bのデータベース 4101bにはクライアント 4500aからの UPDATE (ステップ S43 9)が反映されていない、つまり、データベース 4101aとデータベース 4101bは非同 期状態になったことに注目すべきである。
[0558] 次に、並行処理される複数のトランザクションについて、各サーバ 4100における処 理順序が異なった場合について図 143及び図 144のシーケンスチャートを参照して 説明する。
[0559] ここでは、 2台の正常稼働中のサーバ 4100a及び 4100bが各クライアント 4500か らのクエリを処理するものとする。初期状態では、データベース 4101aと 4101bは完 全に同一であり、サーバ管理表 4201は図 137のようになっているものとする。また、ト ランザクシヨン管理表 4202と送信キュー 4203は空であるとする。各サーバ 4100a, 4100bには、テーブル test— tableが存在しているとする。そして、図 58のテーブル t est tableに対して、図 59のトランザクション T1をクライアント 4500aが発行し、同図 のトランザクション T2をクライアント 4500bが発行したものとする。前述したように、こ の 2つのトランザクション Tl, T2の処理後におけるデータベース 4101のデータは、 各トランザクションの処理順序によって異なった内容になることに注意されたい。
[0560] なお、ここではクエリの処理順序に伴うデータベースの不整合とその解決方法の大 まかな流れについて説明するため、サーバ管理表 4201の更新動作、送信キュー 42 03に対するクエリの入出力、トランザクション管理表 4202の更新動作など、仲介装 置 4200の各部にっ 、ての詳細な動作にっ ヽては省略する。
[0561] 図 143に示すように、クライアント 4500aがトランザクション T1を開始するクエリ（BE GIN)を仲介装置 4200に送信し (ステップ S4101)、一方、クライアント 4500bがトラ ンザクシヨン T2を開始するクエリ（BEGIN)を仲介装置 4200に送信する（ステップ S4 102)。仲介装置 4200は、各クエリをそれぞれ正常稼働中のサーバ 4100a及び 410 Obに転送する（ステップ S4103〜S4106)。そして、各サーノ 4100a及び 4100bカゝ らのそれぞれ応答（ステップ S4107〜S4110)について正当性をチェックし（図示省 略）、正当な応答の 1つをそれぞれの要求元のクライアント 4500a又は 4500bに転送 する（ステップ S4111〜S4112)。
[0562] 仲介装置 4200から BEGINに対する応答を受信したクライアント 4500a及び 4500 bは、それぞれのトランザクションに属する次のクエリを仲介装置 4200に送信する。 本実施例では、クライアント 4500aはトランザクション T1の UPDATEクエリを仲介装 置 4200に送信し (ステップ S4113)、クライアント 4500bはトランザクション T2の UP DATEクエリを仲介装置 4200に送信する（ステップ S4114)。クライアント 4500a及 び 4500bからクエリを受信した仲介装置 4200は、当該クエリをそれぞれ正常稼働中 のサーノ 4100a及び 4100b【こ転送する（ステップ S4115〜S4118)。
[0563] サーバ 4100aではトランザクション Tlの UPDATEクエリがトランザクション T2の U PDATEクエリより先に処理されたとする。トランザクション T1の UPDATEクエリを処 理したサーバ 4100aは、処理結果を仲介装置 4200に送信する（ステップ S4119)。 このとき、トランザクション T1の UPDATEクエリによる test— tableの当該更新対象 行は、トランザクション T1が COMMITされるまでロックされる。トランザクション T2の UPDATEクエリは上記ロックされている行が更新対象となっているので、当該クエリ の処理はロックが解除されるまで保留される（ステップ S4120)。
[0564] 一方、サーバ 4100bではトランザクション T2の UPDATEクエリがトランザクション T 1の UPDATEクエリより先に処理されたとする。トランザクション T2の UPDATEタエ リを処理したサーバ 4100bは、処理結果を仲介装置 4200に送信する（ステップ S41 21)。このとき、トランザクション T2の UPDATEクエリによる test— tableの当該更新 対象行は、トランザクション T2が COMMITされるまでロックされる。トランザクション T 1の UPDATEクエリは上記ロックされている行が更新対象となっているので、当該ク エリの処理はロックが解除されるまで保留される（ステップ S4122)。
[0565] ここで、サーバ 4100aからのトランザクション T1の UPDATEクエリに対する応答（ス テツプ S4119)力 サーバ 4100bからのトランザクション T2の UPDATEクエリに対す る応答 (ステップ S4121)よりも先に仲介装置 4200に到達したとする。
[0566] 仲介装置 4200は、トランザクション T1の UPDATEクエリについての応答を一方の サーバ 4100aから受信したが（ステップ S4119)、他方のサーバ 4100bからの応答 は受信していないので当該応答を待つ (ステップ S4123)。これは、前述したように、 仲介装置 4200において、各サーバ 4100a及び 4100bからの応答を互いに比較し て正当性を判断するためである。同様に、仲介装置 4200は、トランザクション T2の U PDATEクエリについての応答を一方のサーバ 4100bから受信したが（ステップ S41 21)、他方のサーバ 4100aからの応答は受信していないので当該応答を待つ（ステ ップ S4124)。
[0567] 前述のようにサーバ 4100bにおいてトランザクション T1の UPDATEクエリの処理 はロック解除待ちされているので (ステップ S4122)、仲介装置 4200における当該ク エリに対する応答待ち (ステップ S4123)はタイムアウトする (ステップ S4125)。これ により、仲介装置 4200は、サーバ 4100bが障害になったと判断し、前記ステップ S4 124の応答待ちをキャンセルし、当該サーバ 4100bをシステム力も切り離す (ステツ プ S4126)。具体的には、サーバ管理表 4201から当該サーバ 4100bのエントリを削 除するとともに、送信キュー 4203からサーバ 4100bの送信状態の欄を削除する。そ して、仲介装置 4200は、図 144に示すように、システムから切り離したサーバ 4100b に対して再起動指示を送信するとともに (ステップ S4127)、応答をクライアント 4500 aに返す (ステップ S4128)。
[0568] サーバ 4100bは、仲介装置 4200からの再起動指示を受信すると、 自身の再起動 を開始する（ステップ S4129)。
[0569] トランザクション T1の UPDATEクエリにつ!/、て応答を受信したクライアント 4500a は、更新を確定するクエリ（COMMIT)を仲介装置 4200に送信する (ステップ S413 0)。仲介装置 4200は、クライアント 4500aからクエリを受信すると、サーバ管理表 42 01を参照して正常稼働中のサーバ 4100aに当該クエリを転送する (ステップ S4131
) o
[0570] サーバ 4100aでは、トランザクション T1の COMMITクエリを処理することによりロッ クが解除されてトランザクション T2の処理が再開可能となる（ステップ S4132)。これ により、サーバ 4100aはトランザクション T1の COMMITクエリに対する応答を仲介 装置 4200に返し (ステップ S4133)、仲介装置 4200は当該応答をクライアント 4500 aに転送する（ステップ S4134)。次いで、サーバ 4100aはトランザクション T2の UPD ATEクエリに対する応答を仲介装置 4200に返し (ステップ S4135)、仲介装置 420 0は当該応答をクライアント 4500bに転送する (ステップ S4136)。
[0571] トランザクション T2の UPDATEクエリにつ!/、て応答を受信したクライアント 4500b は、更新を確定するクエリ（COMMIT)を仲介装置 4200に送信する (ステップ S413 7)。仲介装置 4200は、クライアント 4500bからクエリを受信すると、サーバ管理表 42 01を参照して正常稼働中のサーバ 4100aに当該クエリを転送する (ステップ S4138 )。サーバ 4100aは当該クエリを処理して応答を仲介装置 4200に返し (ステップ S41 39)、仲介装置 4200は当該応答をクライアント 4500bに転送する (ステップ S4140)
[0572] ここで、システム力も切り離されたサーバ 4100bの再起動が完了したものとする（ス テツプ S4141)。サーバ 4100bは、再起動が完了すると仲介装置 4200に対してデ ータベース同期化要求を送信する（ステップ S4142)。仲介装置 4200は、正常稼働 中のサーバ 4100aと協働して、サーバ 4100aのデータベース 4101aと、サーバ 410 Obのデータベース 4101bとを同期化させる処理を行う（ステップ S4143)。この同期 化処理の詳細については後述する。仲介装置 4200は、同期化処理が完了したら当 該サーバ 4100bを再びシステムに組み込む（ステップ S4144)。システムへの組込処 理の詳細についてはステップ S4143の同期化処理の詳細と併せて後述する。
[0573] 以上の処理により、並行処理される複数のトランザクションについて、各サーバ 410
0における処理順序が異なった場合であっても、各サーバ 4100間でデータベース 4
101の同期が保たれる。
[0574] 次に、並行処理される複数のトランザクションについて、各サーバ 4100における処 理順序が異なった場合の他の例について図 145及び図 146のシーケンスチャートを 参照して説明する。
[0575] ここでは、 2台の正常稼働中のサーバ 4100a及び 4100bが各クライアント 4500か らのクエリを処理するものとする。初期状態では、データベース 4101aと 4101bは完 全に同一であり、サーバ管理表 4201は図 137のようになっているものとする。また、ト ランザクシヨン管理表 4202と送信キュー 4203は空であるとする。各サーバ 4100a, 4100bには、テーブル test— tableが存在しているとする。そして、図 58のテーブル t est— tableに対して、図 60のトランザクション T3をクライアント 4500aが発行し、同図 のトランザクション T4をクライアント 4500bが発行したものとする。前述したように、こ の 2つのトランザクション T3, T4の処理後におけるデータベース 4101のデータは、 各トランザクションの処理順序には影響されない。し力しながら、前述したように、トラ ンザクシヨン T4における SELECTの結果は各トランザクション T3, T4の処理順序に よって異なった内容になることに注意されたい。
[0576] なお、ここではクエリの処理順序に伴うデータベースの不整合とその解決方法の大 まかな流れについて説明するため、サーバ管理表 4201の更新動作、送信キュー 42 03に対するクエリの入出力、トランザクション管理表 4202の更新動作など、仲介装 置 4200の各部にっ 、ての詳細な動作にっ ヽては省略する。
[0577] 図 145に示すように、クライアント 4500aがトランザクション T3を開始するクエリ（BE GIN)を仲介装置 4200に送信すると（ステップ S4201)、仲介装置 4200は、サーバ 管理表 4201を参照して正常稼働中のサーバ 4100a及び 4100bに転送する（ステツ プ S4202, S4203)。 ί中介装置 4200ίま、各サーノ 4100a及び 4100b力らの応答を 受信すると (ステップ S4204, S4205)、正当な応答の 1つをクライアント 4500aに転 送する（ステップ S4206)。
[0578] 次!、で、クライアント 4500aはトランザクション T3の更新クエリ（UPDATE)を仲介 装置 4200に送信する（ステップ S4207)。一方、クライアント 4500bはトランザクショ ン T4を開始するクエリ（BEGIN)を仲介装置 4200に送信する (ステップ S4208)。
[0579] 仲介装置 4200は、トランザクション T3の UPDATEクエリを正常稼働中のサーバ 4 100a及び 4100bに転送するととちに（ステップ S4209, S4210)、卜ランザクシヨン T 4の BEGINクエリを正常稼働中のサーバ 4100a及び 4100bに転送する（ステップ S 4211, S4212)。そして、仲介装置 4200は、トランザクション T3の UPDATEクエリ に対する応答を各サーノ 4100a及び 4100b力ら受信すると (ステップ S4213, S42 14)、正当な応答の 1つをクライアント 4500aに転送する（ステップ S4215)。また、ト ランザクシヨン T4の BEGINクエリに対する応答を各サーバ 4100a及び 4100bから 受信すると (ステップ S4216, S4217)、正当な応答の 1つをクライアント 4500bに転 送する（ステップ S4218)。
[0580] 次!、で、クライアント 4500aはトランザクション T3を確定するクエリ（COMMIT)を仲 介装置 4200に送信する（ステップ S4219)。一方、クライアント 4500bはトランザクシ ヨン T4の参照クエリ（SELECT)を仲介装置 4200に送信する（ステップ S4220)。
[0581] 仲介装置 4200は、トランザクション T3の COMMITクエリを正常稼働中のサーバ 4 100a及び 4100bに転送するととちに（ステップ S4221, S4222) ,卜ランザクシヨン T 4の SELECTクエリを正常稼働中のサーバ 4100a及び 4100bに転送する（ステップ S4223, S4224)。
[0582] ここで、一方のサーバ 4100aでは、トランザクション T3の COMMITクエリがトランザ クシヨン T4の SELECTクエリより先に処理され (ステップ S4225, S4226)、他方の サーバ 4100bでは、トランザクション T4の SELECTクエリがトランザクション T3の CO MMITクエリより先に処理されたものとする（ステップ S4227, S4228)。これにより、 トランザクション T4の SELECTクエリの応答は、サーバ 4100aからの応答（ステップ S 4226)と、サーノ 4100b力らの応答（ステップ S4227)とは異なったものとなったとす る。
[0583] 仲介装置 4200は、トランザクション T4の SELECTクエリに対する応答力 各サー ノ lOOa及び 4100b間で不一致となっているので、何れかのサーバ 4100a又は 41 00bを選定し、選定したサーバ 4100a又は 4100bからの応答を正当なものとする（ス テツプ S4229)。ここで、サーバ 4100の選定方法としては、例えば予め Masterサー バを定めておいて、この Masterサーバを選定する方法、最初に応答を返したサーバ を選定する方法、ラウンドロビンにより選定サーバを順次選定する方法、ランダムに選 定する方法、各サーバの処理能力，処理負荷などにより選定する方法などが挙げら れる。本実施の形態では、サーバ 4100aを Masterサーバとして該サーバ 4100aを 正当な応答を返したサーバとして選定する。仲介装置 4200は、正当でない応答を 返したサーバ 4100bをシステム力も切り離す (ステップ S4230)。具体的には、サー バ管理表 4201から当該サーバ 4100bのエントリを削除するとともに、送信キュー 42 03からサーバ 4100bの送信状態の欄を削除する。そして、図 146に示すように、当 該サーバ 4100bに対して再起動指示を送信する (ステップ S4231)。
[0584] サーバ 4100bは、仲介装置 4200からの再起動指示を受信すると、 自身の再起動 を開始する（ステップ S4232)。
[0585] 仲介装置 4200は、選定したサーバ 4100aから受信した、トランザクション T3の CO MMITクエリに対する応答及びトランザクション T4の SELECTクエリに対する応答を 、それぞれ要求元のクライアン卜 4500a, 4500bに転送する（ステップ S4233, S423 4) o以降、各クライアン卜 4500a, 4500b力らのクエリ ίま、正常稼働中のサーノ 4100 aで処理する。図 146の例では、クライアント 4500bがトランザクション T4の COMMI Tクエリを仲介装置 4200に送信すると (ステップ S4235)、仲介装置 4200は当該ク エリを正常稼働中のサーバ 4100aに転送する (ステップ S4236)。そして、仲介装置 4200は、当該クエリに対する応答をサーバ 4100aから受信すると (ステップ S4237) 、この応答を要求元のクライアント 4500bに返す (ステップ S4238)。
[0586] ここで、システム力も切り離されたサーバ 4100bの再起動が完了したものとする（ス テツプ S4239)。サーバ 4100bは、再起動が完了すると仲介装置 4200に対してデ ータベース同期化要求を送信する（ステップ S4240)。仲介装置 4200は、正常稼働 中のサーバ 4100aと協働して、サーバ 4100aのデータベース 4101aと、サーバ 410 Obのデータベース 4101bとを同期化させる処理を行う（ステップ S4241)。この同期 化処理の詳細については後述する。仲介装置 4200は、同期化処理が完了したら当 該サーバ 4100bを再びシステムに組み込む（ステップ S4242)。システムへの組込処 理の詳細についてはステップ S4241の同期化処理の詳細と併せて後述する。
[0587] 以上の処理により、並行処理される複数のトランザクションについて、各サーバ 410 0における処理順序が異なった場合であっても、クライアント 4500には 1つの正しい 応答のみが処理結果として返される。
[0588] なお、この例では、 2つのトランザクション T3及び T4に属するクエリの処理順序が 異なっても当該トランザクション T3及び T4に属する各クエリの中で同一行を更新する クエリは存在しないので、クエリの処理順序が異なることによる各データベース 4101 間の不整合は生じない。したがって、この例に限定して考えると、データベース 4101 の同期ィ匕のための各処理 (ステップ S4230〜S4232, S4239~S4242)は不要で あるとも考えられる。しかし、本実施の形態では、何らかの原因でデータベース 4101 に不整合が潜在していた場合であって、当該不整合について前記ステップ S4229を 契機に検出した場合にも対処できるように、データベース 4101の同期化のための各 処理を実施するようにした。また、この例では、 SELECTと UPDATEの順序不一致 による結果不一致について説明した力 他にも、参照系では SELECT FOR UP DATE,更新係では DELETEなどの組み合わせで結果不一致が生じる場合がある 。本実施の形態では、このような場合であっても図 145及び図 146を参照して説明し たシーケンスと同様の処理を行うことによって、データベース 4101の不整合を解消で きる。
[0589] 次に、前記ステップ S4143及び S4241における同期化処理の詳細について説明 する。本発明における同期化処理では、同期化処理開始時において正常稼働して いるサーバ 4100でデータベース 4101のスナップショットを作成し、このスナップショ ットを同期化対象の新規サーバ 4100に転送する。そして新規サーバ 4100において スナップショットからデータベース 4101の復元を行う。さらに、この処理中に受信した クライアント 4500からのクエリを仲介装置 4200にお 、て差分情報として蓄積する。こ の差分情報の蓄積は送信キュー 4203を利用する。そして、新規サーバ 4100がスナ ップショットからのデータベース 4101の復元が完了したら仲介装置 4200から差分情 報を取得して、この差分情報を処理する。
[0590] なお、前述したように、サーバ 4100は自身が起動されるとデータベース同期化要 求を仲介装置 4200に送信するので、同期化処理の実施は、仲介装置 4200からの 再起動指示に応じた再起動時に限られない。すなわち、サーバ 4100が障害となつ てシステムカゝら切り離され、その後にシステムに再び組み込む際にも実施される。ま た、システムを構成するサーバを増設する場合にも実施される。
[0591] 以下に、サーバ 4100bをシステムに組み込む場合の同期化動作を図 147から図 1 67を参照して説明する。このとき注目すべきポイントは、スナップショット作成期間中 を除きクライアント 4500a及び 4500bに対するサービスを続けたままサーバ 4100bを 追加する、つまり、システムダウンさせずにデータベース 4101aと 4101bを同期させ ることである。
[0592] データベース 4101bはデータベース 4101aと同期がとれていない状態、つまり、同 一ではない状態である。例えば、データベース 4101bは、再起動直前のデータ又は 障害発生直前のデータを保持して 、る力もしれな 、し、全く新 U、サーバの場合には 、データを全く持っていない状態力もしれない。本発明では、前者の場合でも古いデ ータは削除し、データベース 4101bはデータを全く保持していないものとしてシステ ムに糸且み込む。つまり、古いデータを保持している必要はない。
[0593] ここでは、サーバ 4100aのみが正常稼働しているのでサーバ管理表 4201は図 15 1のようになっているとする。また、トランザクション管理表 4202は空であるとする。さら に、送信キュー 4203は空であり、正常稼働中のサーバ 4100aについてのみ送信状 態を記憶する構成となって 、る。
[0594] 図 147に示すように、クライアント 4500aが 172.17.1.1宛のトランザクション開始 SQL
(BEGIN)を含んだパケットを送信すると、仲介装置 4200の受信クエリ処理部 4204 はそのパケットを受信する (ステップ S4301)。受信クエリ処理部 4204は、トランザク シヨンが開始されたことを検知し、トランザクション管理表 4202にクライアント 4500a の IPアドレスとトランザクション番号を登録する（ステップ S4302)。図 152にこのとき のトランザクション管理表 4202を示す。受信クエリ処理部 4204は、サーバ管理表 42 01を参照して正常稼働中のサーバ 4100aについて送信状態を「未送信」にして受信 クエリを送信キュー 4203に入れる（ステップ S4303)。クエリ送信処理部 4205は、送 信キュー 4203から当該クエリを取り出し、対応するサーバ 4100aに転送し (ステップ S4304)、送信キュー 4203の送信状態を「送信完了」に更新する (ステップ S4305) 。仲介装置 4200の正当性応答部 206は、トランザクションが正常に開始されたことを 通知する応答パケットをサーバ 4100aから受信すると (ステップ S4306)、ここでは、 正常稼働中のサーバ 4100が 1台のみなので当該応答パケットを正当と判断し、応答 送信処理部 4207は該応答パケットをクライアント 4500aへ転送するとともに (ステップ S4307)、該応答を送信キュー 4203に保存する (ステップ S4308)。この時の送信キ ユー 4203を図 153に示す。
[0595] 次いで、クライアント 4500aが 172.17.1.1宛に、テーブル test— tableを更新する S QL (UPDATE)を含んだパケットを送信すると、仲介装置 4200の受信クエリ処理部 4204はそのパケットを受信する（ステップ S4309)。受信クエリ処理部 4204は、サー バ管理表 4201を参照して正常稼働中のサーバ 4100aについて送信状態を「未送 信」にして受信クエリを送信キュー 4203に入れる（ステップ S4310)。この時の送信キ ユー 4203を図 154に示す。
[0596] ここで、サーバ 4100bが再起動したものとする（ステップ S4311)。これにより、サー ノ lOObのデータベース制御部 4102bは、データベース同期化要求（システムへの 組込要求）を仲介装置 4200へ送信する（ステップ S4312)。
[0597] データベース同期化要求を受信した同期化処理制御部 4208は、サーバ管理表 4 201を参照して同期化用のサーバ 4100を選定する。ここでは、正常稼働中のサー ノ 100は 1台のみなので、サーバ 4100aを選定する。そして、サーバ管理表 4201 のサーノ 4100aにつ!/、ての稼働状態を「active + syncjに更新するとともに（ステツ プ S4313)、送信キュー 4203のサーバ 4100aについて送信状態が「未送信」となつ ているエントリを「保留」に更新する (ステップ S4314)。また、同期化処理制御部 420 8は、同期化用のサーバ 4100aにおいて実行中クエリがないことを確認した後に、要 求元のサーバ 4100bにつ!/、て稼働状態を「sync」でサーバ管理表 4201に追加する とともに (ステップ S4315)、送信キュー 4203の送信状態の欄に当該サーバ 4100b 用の列を追加する (ステップ S4316)。ここで、当該サーバ 4100bの送信状態は全て 「保留」に設定する。この時のサーバ管理表 4201及び送信キュー 4203を図 155, 図 156に示す。以降、各クライアント 4500から受信したクエリは、サーバ 4100a及び 4100bの双方について送信状態を「保留」にして送信キュー 4203に入れる。なお、 同期化処理制御部 4208は、上記ステップ S4313〜S4316の処理は 1つの処理とし て取り扱 ヽ、 他帘 IJ御を行う。つまり、ステップ S4313〜S4316の処理中に ίま、各ス テツプでアクセスするサーバ管理表 4201及び送信キュー 4203に対して、他の機能 ブロック (例えば受信クエリ処理部 4204など)からのアクセスを中断させる。
[0598] 次いで、同期化処理制御部 4208は、サーバ 4100aにスナップショットの作成指示 を送出する (ステップ S4317)。
[0599] スナップショット作成指示を受け取ったサーバ 4100aのデータベース制御部 4102 aは、データベース 4101aのスナップショットを作り出す (ステップ S4318)。ここで、こ のスナップショットは、スナップショット作成指示を受け取った時点で COMMITされて いるデータベース全体のバックアップデータ及びデータベースを復元するための情 報であり、既に更新クエリを受信して 、てもスナップショット作成指示時には未だ CO MMITされてなければ当該更新は反映されて ヽな 、ことに注目すべきである。
[0600] 前述したように、クライアント 4500からクエリを受信すると、受信クエリ処理部 4204 は、サーバ 4100a及び 4100bの双方について送信状態を「保留」にして送信キュー 4203に入れる。図 148の例では、クライアント 4500bがトランザクション開始 SQL (B EGIN)を含んだパケットを送信すると、仲介装置 4200の受信クエリ処理部 4204は そのパケットを受信する (ステップ S4319)。受信クエリ処理部 4204は、トランザクショ ンが開始されたことを検知し、トランザクション管理表 4202にクライアント 4500bの IP アドレスとトランザクション番号を登録する（ステップ S4320)。図 157にこのときのトラ ンザクシヨン管理表 4202を示す。受信クエリ処理部 4204は、サーバ 4100a及び 41 00bの双方について送信状態を「保留」にして当該受信クエリを送信キュー 4203に 入れる（ステップ S4321)。この時の送信キュー 4203を図 158に示す。
[0601] サーバ 4100aのデータベース制御部 4102aは、スナップショット作成が完了すると
(ステップ S4322)、その旨を仲介装置 4200へ通知するとともに (ステップ S4323)、 該スナップショットのサーバ 4100bへの転送を開始する（ステップ S4324)。サーバ 4 100bのデータベース制御部 4102bは、サーバ 4100aから受信したスナップショット からデータベースを復元する（ステップ S4325)。
[0602] サーバ 4100aからスナップショット完了通知を受信した仲介装置 4200の同期化処 理制御部 4208は、送信キュー 4203のサーバ 4100aについての送信状態が「保留」 となっているエントリを「保留解除」に更新する (ステップ S4326)。この時の送信キュ 一 4203を図 159に示す。以降、各クライアント 4500から受信したクエリは、サーバ 4 100aについては送信状態を「保留解除」にして、 4100bについては送信状態を「保 留」にして送信キュー 4203に入れる。これにより、クエリ送信処理部 4205は、送信状 態が「保留解除」となったクエリを古いものから順にサーバ 4100aに送信する。ここで は、クエリ送信処理部 4205は、図 159に示すトランザクション IDが 3番の UPDATE クエリをサーバ 4100aに送信し (ステップ S4327)、送信状態を「送信完了」に更新す る（ステップ S4328)。仲介装置 4200の正当性判定部 4206は、 UPDATEが正常 に処理されたことを通知する応答パケットをサーバ 4100aから受信すると (ステップ S 4329)、ここでは正常稼働中のサーバ 4100が 1台のみなので当該応答パケットを正 当と判断する。そして、応答送信処理部 4207は該応答パケットのクライアント 4500a へ転送するとともに (ステップ S4330)、該応答を送信キュー 4203に保存する (ステツ プ S4331)。同様にして図 159に示すトランザクション ID力 番の BEGINクエリも処 理する（ステップ S4332〜S4336)。この時の送信キュー 4203を図 160に示す。ここ で、サーバ 4100aについては、送信キュー 4203において送信状態が「保留解除」で あったクエリが全て処理されたことになるので、応答送信処理部 4207は、サーバ管 理表 4201のサーバ 4100aについての稼働状態を「active」に更新する（ステップ S4 337)。これによりサーバ 4100aはシステムに組み込まれる。この時のサーバ管理表 4 201を図 161に示す。以降、各クライアント 4500から受信したクエリは、サーバ 4100 aについては送信状態を「未送信」にして、サーバ 4100bについては送信状態を「保 留」にして送信キュー 4203に入れる。
[0603] 図 148の例では、クライアント 4500bが 172.17.1.1宛の UPDATEクエリを含んだパ ケットを送信すると、仲介装置 4200の受信クエリ処理部 4204はそのパケットを受信 する（ステップ S4338)。受信クエリ処理部 4204は、サーバ管理表 4201を参照して 正常稼働中のサーバ 4100aについて送信状態を「未送信」にするとともに、同期化 処理中のサーバ 4100bについて送信状態を「保留」にして受信クエリを送信キュー 4 203【こ人れる（ステップ S4339)。この時の送信キュー 4203を図 162【こ示す。クエリ 送信処理部 4205は、送信キュー 4203から当該クエリを取り出し、送信状態が「未送 信」であるサーバ 4100aに転送し (ステップ S4340)、送信キュー 4203のサーバ 410 Oaについての送信状態を「送信完了」に更新する (ステップ S4341)。仲介装置 420 0の正当性判定部 4206は、 UPDATEが正常に処理されたことを通知する応答パケ ットをサーバ 4100aから受信すると (ステップ S4342)、ここでは、正常稼働中のサー ノ 100が 1台のみなので当該応答パケットを正当と判断する。そして、応答送信処 理部 4207は該応答パケットをクライアント 4500bへ転送するとともに (ステップ S434 3)、該応答を送信キュー 4203に保存する (ステップ S4344)。
[0604] クライアント 4500a力 172.17.1.1宛のトランザクション確定 SQL (COMMIT)を含ん だパケットを送信すると、仲介装置 4200は、該パケットを前述のステップ S4338〜3 44と同様に処理する（ステップ S4345〜S4351)。この結果、送信キュー 4203は図 163に示したものとなる。また、 COMMITが正常に完了したことから、トランザクショ ンが終了したことが分力るので、応答送信処理部 4207はトランザクション管理表 420 2からこのトランザクションの登録を削除する（ステップ S4352)。なお、この時点でトラ ンザクシヨン IDが 3番のトランザクションは終了した力 該トランザクションに係るクエリ は同期化中のサーバ 4100bに対しては未だ送信していないので、当該クエリの送信 キュー 4203からの削除は行わない。
[0605] ここで、サーバ 4100bにおいてスナップショットからのデータベース 4101bの復元 が完了したものとする（ステップ S4353)。サーバ 4100bはデータベース 4101bの復 元が完了すると差分情報転送要求を仲介装置 4200に送信する (ステップ S4354)。
[0606] サーバ 4100bから差分情報転送要求を受信すると、同期化処理制御部 4208は、 要求元のサーバ 4100bにつ!/、て送信キュー 4203の送信状態が「保留」となって!/、る ものを「保留解除」に更新する (ステップ S4355)。以降、各クライアント 4500から受 信したクエリーは、サーバ 4100aについては送信状態を「未送信」にして、サーバ 41 00bについては送信状態を「保留解除」にして送信キュー 4203に入れる。この時の 送信キュー 4203を図 164に示す。これにより、クエリ送信処理部 4205は、送信状態 が「保留解除」となったクエリを差分情報として古 、もの力も順にサーバ 4100bに送 信する。
[0607] 具体的には、クエリ送信処理部 4205は、送信キュー 4203から BEGINクエリを取り 出してサーバ 4100bに転送するとともに (ステップ S4356)、送信キュー 4203の送信 状態を「送信完了」に更新する (ステップ S4357)。この時の送信キュー 4203を図 16 5に示す。仲介装置 4200の正当性判定部 4206は、トランザクションが正常に開始さ れたことを通知する応答パケットをサーバ 4100bから受信すると (ステップ S4358)、 当該応答と、送信キュー 4203に保存されている応答とを対比する (ステップ S4359) 。そして、両者が一致しない場合には、サーバ 4100bについてのエントリをサーバ管 理表 4201及び送信キュー 4203から削除した後に、当該サーバ 4100bに対して再 起動指示を送出する。これにより、ステップ S4311以降の処理が再試行される。
[0608] なお、この同期化処理の再試行の発生頻度は低いものと考えられるが理論上は無 限回数継続する可能性がある。そこで、所定の記憶装置に再試行回数を記憶し、再 試行回数が所定回数以上となったら同期化処理を中止すると好適である。さらに、同 期化処理を中止した場合には、所定の出力手段に当該中止した旨を出力すると好 適である。例えば、ログファイルに出力する方法などが挙げられる。そして、正常稼働 中のサーバ 4100や仲介装置 4200の負荷が低いときなどに再び同期化処理を試行 すると好適である。
[0609] 前述したように、サーバ 4100bへの差分情報の転送開始後であってサーバ 4100b のシステムのへ組込前にクライアント 4500からクエリを受信した場合には、受信クエリ 処理部 4204は、サーバ 4100aについては送信状態「未送信」で、サーバ 4100bに っ 、ては送信状態「保留解除」で当該クエリを送信キュー 4203に投入する。図 149 の例では、クライアント 4500bが仲介装置 4200に対して INSERTクエリを送信すると (ステップ S4360)、 ί中介装置 4200の受信タエジ処理咅4204は、サーノ 4100aに っ 、ては送信状態「未送信」で、サーバ 4100bにつ 、ては送信状態「保留解除」で 当該クエリを送信キュー 4203に投入する (ステップ S4361)。クエリ送信処理部 420 5は、当該クエリを送信キュー 4203から取り出してサーバ 4100aに送信し (ステップ S 4362)、サーバ 4100aについての送信状態を「送信完了」に更新する (ステップ S43 63)。仲介装置 4200の正当性判定部 4206は、 INSERTが正常に処理されたことを 通知する応答パケットをサーバ 4100aから受信すると (ステップ S4364)、ここでは正 常稼働中のサーバ 4100が 1台のみなので当該応答パケットを正当と判断する。そし て、応答送信処理部 4207は該応答パケットのクライアント 4500bへ転送するとともに (ステップ S4365)、該応答を送信キュー 4203に保存する（ステップ S4366)。この時 の送信キュー 4203を図 166に示す。
[0610] このような差分情報の転送中において、あるトランザクションに属する各クエリがサ ーバ 4100bで処理され且つその応答が正当であると判定されたら、応答送信処理部 4207は、当該トランザクションに属する全てのクエリを送信キュー 4203から削除する 。図 166の例では、トランザクション IDが 3番の UPDATE,トランザクション ID力 番 の BEGIN、トランザクション IDが 4番の UPDATEが上述した手順により順次処理さ れ、そしてトランザクション IDが 3番の COMMITクエリについて、サーバ 4100bで処 理され且つその応答が正当であると判定された時点で、トランザクション IDが 3番の B EGIN, UPDATE, COMMITクエリが送信キュー 4203から削除される。
[0611] 全ての差分情報の転送が終了し (すなわち送信キュー 4203から「保留解除」のタエ リを全て送出し終わり）、且つ、差分情報としてのクエリの処理が正常に処理された時 点で、サーバ 4100aのデータベース 4101aとサーバ 4100bのデータベース 4101b の同期化が完了するので、サーバ 4100bをシステムに組み込むべくサーバ 4100b についてのサーバ管理表 4201の稼働状態を「active」に更新する。
[0612] 図 150の例では、クエリ送信処理部 4205は、送信キュー 4203から INSERTクエリ を取り出してサーバ 4100bに転送するとともに (ステップ S4390)、送信キュー 4203 の送信状態を「送信完了」に更新する (ステップ S4391)。仲介装置 4200の正当性 判定部 4206は、 INSERTが成功したことを通知する応答パケットをサーバ 4100bか ら受信すると (ステップ S4392)、当該応答と、送信キュー 4203に保存されている応 答とを対比する (ステップ S4393)。そして、両者が一致しない場合には、サーバ 410 Obについてのエントリをサーバ管理表 4201及び送信キュー 4203から削除した後に 、当該サーバ 4100bに対して再起動指示を送出する。これにより、ステップ S4311以 降の処理が再試行される。この時の送信キューを図 167に示す。
[0613] この時点で送信キュー 4203には送信状態が「保留解除」のクエリがなくなつたので 、応答送信処理部 4207は、サーバ 4100bをシステムに組み込むべくサーバ 4100b についてのサーバ管理表 4201の稼働状態を「active」に更新する（ステップ S4394 )。この時のサーバ管理表 4201を図 168に示す。なお、このステップ S4394の処理 は、前述のステップ S4144, S4242の処理に対応するものである。
[0614] このような同期化処理により、もともとシステムに組み込まれていたが再起動や障害 等のためにシステム力も切り離されたサーバであっても、新規のサーバであっても、 理論的には幾らでも追加できる。つまり、追加できるサーバ数に制限はない。
[0615] また、本実施の形態では、システム力も切り離されたサーバはスナップショット及び 差分情報に基づきデータベースの復元を行うが、該サーバにおける差分情報の処理 結果と、システムに組み込まれていた正常なサーバにおける処理結果とがー致しな い場合には、同期化処理が再試行される。これにより、サーバ間において処理要求 の処理順序が異なることにより各サーバのデータベースが非同期状態になることを未 然に防止できる。
[0616] なお、本実施形態では、クライアント 4500a及び 4500bからの処理要求のみ多重 化データベースシステムで処理する場合にっ 、て説明した力 データベース一致検 查装置 4600からの処理要求も同様に処理すればよい。これは、多重化データべ一 スシステムから見るとデータベース一致検査装置 4600もクライアントコンピュータの 1 つだからである。ところで、データベース一致検査装置 4600は、前述したように、定 期的に又は必要に応じてデータベース一致検査用の参照クエリを仲介装置 4200に 送信する。これにより、何らかの理由でデータベース 4101間でデータの矛盾が生じ た場合であっても、当該クエリによりデータベース 4101間の矛盾が検出され上記同 期化処理が実行される。これにより、データベース 4101間の同期をより確実に図るこ とがでさる。
[0617] 以上のように本実施の形態に係る多重化データベースシステムによれば、複数のト ランザクシヨンを並行処理しても各データベース間で矛盾の生じることがなく同期状 態を保つことができる。 [0618] (第 20の実施の形態）
本発明の第 20の実施の形態に係る多重化データベースシステムについて図面を 参照して説明する。本実施の形態が前述の第 19の実施の形態と異なる点は、仮想 サーバ 4800が 3台のサーバ 4100を備えていることにある。各装置の構成'動作等に ついては第 19の実施の形態と同様である。具体的には、本実施の形態と第 19の実 施の形態とでは、システムにサーバ 4100を組み込む際の同期化処理 (第 19の実施 の形態における図 144のステップ S4143及び図 146のステップ S4241)の動作が異 なり、他の動作については同じである。以下、この同期化処理について詳述する。
[0619] ここでは、 3台のサーバ 4100a〜4100cのうち 1台のサーバ 4100cがシステムから 切り離されている状態から、該サーバ 4100cをシステムに再び組み込む場合につい て図 169〜図 186を参照して説明する。
[0620] 初期状態にけるサーバ管理表 4201を図 174に示す。また、トランザクション管理表 4202は空であるものとする。送信キュー 4203は空であり図 175に示すような構造と なっている。
[0621] 図 169に示すように、クライアント 4500aが 172.17.1.1宛のトランザクション開始 SQL
(BEGIN)を含んだパケットを送信すると、仲介装置 4200の受信クエリ処理部 4204 はそのパケットを受信する (ステップ S4401)。受信クエリ処理部 4204は、トランザク シヨンが開始されたことを検知し、トランザクション管理表 4202にクライアント 4500a の IPアドレスとトランザクション番号を登録する (ステップ S4402)。受信クエリ処理部 4204は、サーバ管理表 4201を参照して正常稼働中のサーバ 4100a及び 4100b について送信状態を「未送信」にして受信クエリを送信キュー 4203に入れる (ステツ プ S4403)。クエリ送信処理部 4205は、送信キュー 4203から当該クエリを取り出し、 対応するサーノ 4100a及び 4100b【こ転送し (ステップ S4404, S4405)、それぞれ 送信キュー 4203の送信状態を「送信完了」に更新する (ステップ S4406)。仲介装置 4200の正当性判定部 4206は、トランザクションが正常に開始されたことを通知する 応答ノ ケッ卜をサーノ 4100a及び 4100b力ら受信すると（ステップ S4407, S4408) 、各サーバ 4100a及び 4100bからの応答パケットの正当性を判定する。そして、応 答送信処理部 4207は正当な応答パケットの 1つをクライアント 4500aへ転送するとと もに (ステップ S4409)、該応答を送信キュー 4203に保存する（ステップ S4410)。こ の時の送信キュー 4203を図 176に示す。
[0622] 次いで、クライアント 4500aが 172.17.1.1宛に、テーブル test— tableを更新する S QL (UPDATE)を含んだパケットを送信すると、仲介装置 4200の受信クエリ処理部 4204はそのパケットを受信する（ステップ S4411)。受信クエリ処理部 4204は、サー バ管理表 4201を参照して正常稼働中のサーバ 4100a及び 4100bについて送信状 態を「未送信」にして受信クエリを送信キュー 4203に入れる (ステップ S4412)。この 時の送信キュー 4203を図 177に示す。
[0623] ここで、サーバ 4100cが再起動したものとする（ステップ S4413)。これにより、サー ノ lOOcのデータベース制御部 4102cは、データベース同期化要求（システムへの 組込要求）を仲介装置 4200へ送信する（ステップ S4414)。
[0624] データベース同期化要求を受信した同期化処理制御部 4208は、サーバ管理表 4 201を参照して同期化用のサーバ 4100を 1台選定する。ここでは、正常稼働中のサ ーバ 4100は 2台なので、何れか一方のサーバを所定の規則に従って選定する。本 実施の形態では、サーバ 4100bを同期化用サーバとして選定したものとする。同期 化処理制御部 4208は、サーバ管理表 4201のサーバ 4100bについての稼働状態 を「sync」に更新するとともに（ステップ S4415)、送信キュー 4203のサーバ 4100b について送信状態が「未送信」となっているエントリを「保留」に更新する (ステップ S4 416)。また、同期化処理制御部 4208は、同期化用のサーバ 4100bにおいて実行 中クエリの処理が完了したことを確認した後に、要求元のサーバ 4100cについて稼 働状態を「sync」でサーバ管理表 4201に追加するとともに (ステップ S4417)、送信 キュー 4203の送信状態の欄に当該サーバ 4100c用の列を追加する (ステップ S44 18)。ここで、当該サーバ 4100cの送信状態は全て「保留」に設定する。この時のサ ーバ管理表 4201及び送信キュー 4203を図 178,図 179に示す。なお、同期化処 理制御部 4208は、上記ステップ S4415〜S4418の処理は 1つの処理として取り扱 い、排他制御を行う。つまり、ステップ S4415〜S4418の処理中には、各ステップで アクセスするサーバ管理表 4201及び送信キュー 4203に対して、他の機能ブロック（ 例えば受信クエリ処理部 4204など)からのアクセスを中断させる。 [0625] 次いで、同期化処理制御部 4208は、該サーバ 4100bにスナップショットの作成指 示を送出する（ステップ S4419)。スナップショット作成指示を受け取ったサーバ 410 Obのデータベース制御部 4102bは、データベース 4101bのスナップショットを作り出 す (ステップ S4420)。
[0626] 本実施の形態が第 19の実施の形態と大きく異なる点は、第 19の実施の形態では スナップショット作成中にはクライアント 4500からのクエリを処理できなかった力 本 実施の形態では処理可能である点である。すなわち、同期化処理制御部 4208が上 記ステップ S4415〜S4418の排他処理を終えると、図 170に示すように、クエリ送信 処理部 4205は、送信キュー 4203から送信状態が「未送信」のクエリを取り出し、対 応するサーバ 4100aに転送するとともに (ステップ S4421)、送信キュー 4203の送信 状態を「送信完了」に更新する (ステップ S4422)。仲介装置 4200の受信クエリ処理 部 4204は、 UPDATEが正常に処理されたことを通知する応答パケットをサーバ 41 00aから受信すると (ステップ S4423)、ここでは、正常稼働中のサーバ 4100が 1台 のみなので当該応答パケットを正当と判断し、応答送信処理部 4207は該応答パケ ットのクライアント 4500aへ転送するとともに (ステップ S4424)、該応答を送信キュー 4203に保存する（ステップ S4425)。
[0627] また、クライアント 4500bが 172.17.1.1宛のトランザクション開始 SQL (BEGIN)を含 んだパケットを送信すると、仲介装置 4200の受信クエリ処理部 4204はそのパケット を受信する (ステップ S4426)。受信クエリ処理部 4204は、トランザクションが開始さ れたことを検知し、トランザクション管理表 4202にクライアント 4500bの IPアドレスとト ランザクシヨン番号を登録する（ステップ S4427)。受信クエリ処理部 4204は、サーバ 管理表 4201を参照して正常稼働中のサーバ 4100aについて送信状態を「未送信」 にするとともに、同期化処理中のサーバ 4100b及び 4100cについて送信状態を「保 留」にして受信クエリを送信キュー 4203に入れる (ステップ S4428)。クエリ送信処理 部 4205は、送信キュー 4203から当該クエリを取り出し、送信状態が「未送信」である サーノ 4100a【こ転送し (ステップ S4429)、送信キュー 4203のサーノ 4100a【こつ!ヽ ての送信状態を「送信完了」に更新する (ステップ S4430)。仲介装置 4200の正当 性判定部 4206は、トランザクションが正常に開始されたことを通知する応答パケット をサーバ 4100aから受信すると (ステップ S4431)、ここでは、正常稼働中のサーバ 4 100が 1台のみなので当該応答パケットを正当と判断し、応答送信処理部 4207は該 応答パケットのクライアント 4500bへ転送するとともに (ステップ S4432)、該応答を送 信キュー 4203【こ保存する（ステップ S4433)。この時の送信キュー 4203を図 180【こ 示す。
[0628] ここで、同期化用のサーバ 4100bがスナップショットの作成を完了したとする（ステツ プ S4434)。サーバ 4100bのデータベース制御部 4102bは、スナップショット作成が 完了すると、スナップショット作成完了通知を仲介装置 4200へ通知するとともに (ステ ップ S4435)、該スナップショットのサーバ 4100cへの転送を開始する（ステップ S44 36)。サーバ 4100cのデータベース制御部 4102cは、サーバ 4100bから受信したス ナップショットからデータベースを復元する（ステップ S4437)。
[0629] サーバ 4100bからスナップショット作成完了通知を受信すると、同期化処理制御部 4208は、該サーバ 4100bについて送信キュー 4203の送信状態が「保留」となって いるものを「保留解除」に更新する（ステップ S4438)。この時の送信キュー 4203を図 181〖こ示す。以降、各クライアント 4500から受信したクエリは、サーバ 4100aについ ては送信状態を「未送信」で、サーバ 4100bにつ ヽては送信状態を「保留解除」で、 サーバ 4100cについては送信状態を「保留」にして送信キュー 4203に入れる。これ により、クエリ送信処理部 4205は、送信状態が「保留解除」となったクエリを差分情報 として古いもの力も順にサーバ 4100bに送信する。
[0630] 具体的には、クエリ送信処理部 4205は、送信キュー 4203から UPDATEクエリを 取り出してサーバ 4100bに転送するとともに（ステップ S4439)、送信キュー 4203の 送信状態を「送信完了」に更新する (ステップ S4440)。仲介装置 4200の正当性判 定部 4206は、更新が正常に処理されたことを通知する応答パケットをサーバ 4100b 力も受信すると (ステップ S4441)、当該応答と、送信キュー 4203に保存されている 応答とを対比する (ステップ S4442)。そして、両者が一致しない場合には、ー且、サ ーバ 4100b及び 4100cについてのエントリをサーバ管理表 4201及び送信キュー 4 203から削除した後に、サーバ 4100bに対して再起動指示を送出する。これにより、 第 19の実施の形態で前述した手順によりサーバ 4100bがシステムに組み込まれる ので、次いでサーバ 4100cに対して再起動指示を送出する。これにより、前記ステツ プ S4415以降の処理が再試行される。
[0631] ここで、クライアント 4500bが INSERTクエリを仲介装置 4200に送信すると (ステツ プ S4443)、前述したように、仲介装置 4200の受信クエリ処理部 4204は、サーバ 4 100aについては送信状態を「未送信」で、サーバ 4100bについては送信状態を「保 留解除」で、サーバ 4100cについては送信状態を「保留」で当該クエリを送信キュー に投入する（ステップ S4444)。この時の送信キュー 4203を図 182に示す。クエリ送 信処理部 4205は、送信キュー 4203から当該クエリを取り出し、送信状態が「未送信 」であるサーバ 4100aに対して転送するとともに (ステップ S4445)、送信キュー 420 3のサーバ 4100aについての送信状態を「送信完了」に更新する（ステップ S4446) 。正当性応答部 206は、 INSERTが正常に処理されたことを通知するパケットをサー ノ lOOaから受信すると (ステップ S4447)、ここでは、正常稼働中のサーバ 4100が 1台のみなので当該応答パケットを正当と判断し、応答送信処理部 4207は該応答 パケットをクライアント 4500bへ転送するとともに (ステップ S4448)、該応答を送信キ ユー 4203に保存する（ステップ S4449)。
[0632] 図 182に示すように、この時点では送信キュー 4203において送信状態が「保留解 除」になったクエリは、 BEGINクエリと INSERTクエリの 2つである。仲介装置 4200 は、前述のステップ S4439〜S4442と同様〖こして、当該 2つのクエリを処理する（ス テツプ S4450〜S4457)。
[0633] 以上でサーバ 4100bに対しては、全ての差分情報の転送が終了し (すなわち送信 キュー 4203から「保留解除」のクエリを全て送出し終わり）、且つ、差分情報としての クエリの処理が正常に処理されたことになるので、サーバ 4100aのデータベース 410 laとサーバ 4100bのデータベース 4101bの同期化が完了したことになる。そこで、 仲介装置 4200の応答送信処理部 4207は、サーバ 4100bをシステムに組み込むベ くサーバ 4100bについてのサーバ管理表 4201の稼働状態を「active」に更新する（ ステップ S4458)。なお、システムへの組み込みのタイミングは、正常稼働中のサー ノ 100においてクエリの実行中であっても構わず、またトランザクションが継続中で あっても構わな 、点に留意された 、。 [0634] 以降、クライアント 4500からのクエリは、サーバ 4100a及びサーバ 4100bについて は送信状態を「未送信」で、サーバ 4100cについては送信状態を「保留」にして送信 キュー 4203〖こ入れる。具体的には、図 171〖こ示すよう〖こ、クライアント 4500aが 172.17.1.1宛のトランザクション確定 SQL (COMMIT)を含んだパケットを送信すると 、仲介装置 4200の受信クエリ処理部 4204はそのパケットを受信する（ステップ S44 59)。受信クエリ処理部 4204は、サーバ管理表 4201を参照して正常稼働中のサー ノ lOOa及び 4100bについては送信状態を「未送信」に、同期化処理中のサーバ 4 100cについては送信状態を「保留」にして受信クエリを送信キュー 4203に入れる（ ステップ S4460)。この時の送信キュー 4203を図 183に示す。クエリ送信処理部 42 05は、送信キュー 4203から当該クエリを取り出し、対応するサーバ 4100a及び 410 Obに転送し (ステップ S4461, S4462)、それぞれ送信キュー 4203の送信状態を「 送信完了」に更新する (ステップ S4463)。仲介装置 4200の正当性判定部 4206は 、トランザクションが正常に COMMITされたことを通知する応答パケットをサーバ 41 00a及び 4100b力ら受信すると（ステップ S4464, S4465)、各サーノ 4100a及び 4 100bからの応答パケットの正当性を判定する。そして、応答送信処理部 4207は正 当な応答パケットの 1つをクライアント 4500aへ転送するとともに（ステップ S4466)、 該応答を送信キュー 4203に保存する（ステップ S4467)。また、 COMMITが正常に 完了したことから、トランザクションが終了したことが分力るので、応答送信処理部 42 07はトランザクション管理表 4202からこのトランザクションの登録を削除する（ステツ プ S4468)。
[0635] ここで、サーバ 4100cにおいてスナップショットからのデータベース 4101cの復元 が完了したものとする（ステップ S4469)。サーバ 4100cはデータベース 4101cの復 元が完了すると差分情報転送要求を仲介装置 4200に送信する (ステップ S4470)。
[0636] サーバ 4100cから差分情報転送要求を受信すると、同期化処理制御部 4208は、 要求元のサーバ 4100cにつ!/、て送信キュー 4203の送信状態が「保留」となって!/、る ものを「保留解除」に更新する（ステップ S4471)。この時の送信キュー 4203を図 18 4に示す。以降、各クライアント 4500から受信したクエリは、サーバ 4100a及びサー ノ 100bについては送信状態を「未送信」で、サーバ 4100cについては送信状態を 「保留解除」にして送信キュー 4203に入れる。これにより、クエリ送信処理部 4205は 、送信状態が「保留解除」となったクエリを差分情報として古 、もの力 順にサーバ 4 100cに送信する。
[0637] 具体的には、クエリ送信処理部 4205は、送信キュー 4203から BEGINクエリを取り 出してサーバ 4100cに転送するとともに (ステップ S4472)、送信キュー 4203の送信 状態を「送信完了」に更新する (ステップ S4473)。仲介装置 4200の正当性判定部 4 206は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ 41 00cから受信すると (ステップ S4474)、当該応答と、送信キュー 4203に保存されて いる応答とを対比する (ステップ S4475)。そして、両者が一致しない場合には、サー ノ lOOcについてのエントリをサーバ管理表 4201及び送信キュー 4203から削除し た後に、当該サーバ 4100cに対して再起動指示を送出する。これにより、ステップ S4 415以降の処理が再試行される。
[0638] サーバ 4100cへの差分情報転送中にクライアント 4500bから UPDATEクエリを受 信すると（ステップ S4476)、受信クエリ処理咅4204は、サーノ 4100a及び 4100b につ 、ては送信状態を「未送信」で、サーバ 4100cにつ 、ては送信状態を「保留解 除」で当該クエリーを送信キュー 4203に投入する (ステップ S4477)。この時の送信 キュー 4203を図 185に示す。クエリ送信処理部 4205は、送信キュー 4203から当該 クエリを取り出し、送信状態が「未送信」であるサーバ 4100a及び 4100bに転送し (ス テツプ S4478, S4479)、それぞれのサーノ 4100a及び 4100b【こつ!/、て送信キュ 一 4203の送信状態を「送信完了」に更新する (ステップ S4480)。正当性判定部 42 06は、各サーバ 4100a及び 4100bから UPDATEが正常したことを通知するバケツ トを受信すると (ステップ S4481, S4482)、各応答の正当性を判定して正当な応答 の 1つをクライアント 4500bに返すとともに (ステップ S4483)、該応答を送信キュー 4 203に保存する（ステップ S4484)。
[0639] 全ての差分情報の転送が終了し (すなわち送信キュー 4203から「保留解除」のタエ リを全て送出し終わり）、且つ、差分情報としてのクエリの処理が正常に処理された時 点で、サーバ 4100aのデータベース 4101aとサーバ 4100cのデータベース 4101c の同期化が完了するので、サーバ 4100cをシステムに組み込むべくサーノ lOOc についてのサーバ管理表 4201の稼働状態を「active」に更新する。なお、システム への組み込みのタイミングは、正常稼働中のサーバ 4100においてクエリの実行中で あっても構わず、またトランザクションが継続中であっても構わない点に留意されたい
[0640] 図 185の例では、まず、トランザクション IDが 5番の UPDATEクエリカ トランザクシ ヨン IDが 6番の INSERTクエリについて、前述のステップ S4472〜S4475と同様の 処理を行う。以下、図 185の例における、トランザクション IDが 5番の COMMITクエリ と、トランザクション IDが 6番の UPDATEクエリの処理につ!、て詳述する。
[0641] クエリ送信処理部 4205は、送信キュー 4203力ら COMMITクエリを取り出してサ ーバ 4100cに転送するとともに (ステップ S4490)、送信キュー 4203の送信状態を「 送信完了」に更新する (ステップ S4491)。仲介装置 4200の正当性判定部 4206は 、トランザクションが確定したことを通知する応答パケットをサーバ 4100cから受信す ると (ステップ S4492)、当該応答と、送信キュー 4203に保存されている応答とを対 比する（ステップ S4493)。そして、両者が一致しない場合には、サーノ lOOcにつ いてのエントリをサーバ管理表 4201及び送信キュー 4203から削除した後に、当該 サーバ 4100cに対して再起動指示を送出する。これにより、ステップ S4415以降の 処理が再試行される。
[0642] この時点でトランザクション ID5のトランザクションは全てのサーノ 100において処 理が終了し、且つ、送信キュー 4203にはトランザクション ID5に属する各クエリは全 てのサーバ 4100a, 4100b, 4100cについて送信状態が「送信完了」となったので、 応答送信処理部 4207は、当該トランザクションに属するクエリのエントリを送信キュー 4203力ら肖 IJ除する（ステップ S4494)。この時の送信キュー 4203を図 186に示す。
[0643] 次いで、図 173に示すように、クエリ送信処理部 4205は、送信キュー 4203から UP DATEクエリを取り出してサーバ 4100cに転送するとともに（ステップ S4495)、送信 キュー 4203の送信状態を「送信完了」に更新する (ステップ S4496)。仲介装置 420 0の正当性判定部 4206は、 UPDATEが正常に処理されたことを通知する応答パケ ットをサーバ 4100cから受信すると (ステップ S4497)、当該応答と、送信キュー 420 3に保存されている応答とを対比する (ステップ S4498)。そして、両者が一致しない 場合には、サーバ 4100cについてのエントリをサーバ管理表 4201及び送信キュー 4 203から削除した後に、当該サーバ 4100cに対して再起動指示を送出する。これに より、ステップ S4415以降の処理が再試行される。
[0644] この時点で送信キュー 4203には送信状態が「保留解除」のクエリがなくなつたので 、応答送信処理部 4207は、サーバ 4100cをシステムに組み込むべくサーバ 4100c についてのサーバ管理表 4201の稼働状態を「active」に更新する（ステップ S4499 ) oなお、このステップ S4499の処理は、第 1の実施形態で前述したステップ S4144 , S4242の処理に対応するものである。
[0645] 以上のように本実施の形態では、第 19の実施の形態と比較して、同期化処理にお V、て実施されるスナップショットの作成中にもクライアントに対してサービス提供を維 持できるという効果を有する。他の作用'効果については第 19の実施の形態と同じで ある。
[0646] なお、本実施の形態では、スナップショットを作成する同期化用のサーバ 4100bと 、システムに再び組み込まれるサーバ 4100cとに対して、それぞれ独立したタイミン グで差分情報を転送していたが、サーバ 4100cから差分情報転送要求があった際 に両サーバ 4100b, 4100cに同一の差分情報を転送するようにしてもよい。
[0647] また、本実施の形態では、同期化処理用サーバ 4100bにおける差分情報の処理 結果が、正常稼働中のサーバ 4100aでの処理結果と一致しない場合には、当該サ ーバ 4100bだけでなくサーバ 4100cに対する処理を中断し、第 19の実施の形態の 手法を用いて当該サーバ 4100bのみをシステムに組み込み、その後にサーバ 4100 cをシステムに組み込む処理を再試行していた。一方、この変形例として、サーバ 41 00cに対する処理を継続してサーバ 4100cをシステムに組み込み、その後にサーバ 4100bをシステムに組み込むようにしてもよい。この方法では、クライアント 4500への サービス提供を継続できる点、サーバ 4100cの同期化処理を無駄にやり直す必要が な 、と 、う点で好適である。
[0648] 以上、本発明の実施形態につ!、て詳述したが、上記実施の形態は例示的なもので あり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に 示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれる ものである。なお、以下の各変形例は適宜組み合わせて上記各実施の形態に適用 できる。
[0649] 上記実施の形態では、同期化処理の再試行を行う際には、新規サーバ 4100の再 起動から再試行していたが、再起動は行わずに、新規サーバ 4100から仲介装置 42 00へのデータベースサーバ同期化要求 (第 1の実施形態におけるステップ S4312, 第 20の実施の形態におけるステップ S4414)から再試行するようにしてもよい。
[0650] また、上記実施の形態では、同期化処理の再試行を行う際にはスナップショットを 再度作成し直して ヽたが、再試行前に作成したスナップショットを用いて同期化処理 を行ってもよい。これにより、再試行時の同期化処理時間を短縮化できる。なお、この 方法を実現するためには、上記実施形態のごとく送信キュー 4203に差分情報として 記憶しているクエリを適宜削除するのではなぐ同期化が完了するまでに保持してお く必要がある。
[0651] また、上記実施の形態では、送信状態力 ^保留解除」となっているクエリを送信キュ 一 4203から取り出して差分情報としてサーバ 4100に対して転送し、該転送中にクラ イアント 4500からクエリを受信すると、当該サーバ 4100についての送信状態を「保 留解除」にして送信キュー 4203に投入する処理を行っている。そして、送信状態が「 保留解除」となっているクエリが全てサーバ 4100において処理された後に当該サー ノ 100をシステムに組み込む処理を行っている。このような処理では、クライアント 4 500からのクエリ受信頻度が高いとサーバ 4100のシステムへの組み込みに時間を 要することが考えられる。そこで、例えば送信キュー 4203に送信状態が「保留解除」 として記憶されているクエリが所定数以下となったら、受信クエリ処理部 4204が送信 キュー 4203へのクエリの投入を一停止するなど所定条件で差分情報の転送処理を 優先させるようにしてもよい。
[0652] また、上記実施の形態では、クライアント 4500から受信した全てのクエリを送信キュ 一 4203に保存しておき、同期化処理時には該送信キュー 4203に保存されているク エリを差分情報としてサーバ 4100に転送している力 SELECTクエリのようにデータ ベース 4101の更新を行わない参照系クエリについては差分情報としてのサーバ 41 00への転送を行わないようにしてもよい。これにより、同期化処理の処理時間を短縮 化できる。
[0653] さらに、 UPDATEクエリのようにデータベース 4101の更新を行う更新系クエリのみ を転送し、参照系クエリやトランザクション制御クエリ（BEGIN, ROLLBACK等）の 転送を行わないようにしてもよい。そして、当該更新系クエリを差分情報としてサーバ 4100に転送する際には、サーバ 4100において AutoCommitモードで当該クエリ を処理させるようにする。これにより、更に同期化処理の短縮化及び記憶容量の節約 が可能となる。ただし、この場合にはサーバ 4100に対してクエリを転送する順序が、 正常稼働中のサーバ 4100で処理された順序と一致することを保証する必要がある。 これを実現するためには、各更新系クエリに対する正常稼働中サーバ 4100からの処 理応答力も正常稼働中サーバ 4100における各クエリの実際の処理順序を把握し、 当該順序に従つて各クエリを転送すればよ 、。
[0654] また、上記実施の形態では、サーバ 4100においてトランザクションが継続中であつ ても仲介装置 4200がサーバ 4100に対してスナップショットの作成指示を送信してい た力 継続中のトランザクションが無くなった時点でスナップショットの作成指示を送 信するようにしてもよい。これにより、データベース 4101として、トランザクションの継 続中にはスナップショットの作成ができないものや、トランザクションの継続中であって もスナップショットの作成は開始できるが当該スナップショットにトランザクションに係る クエリが反映されるか否かが不確定なものを利用することができる。また、前述の第 1
9の実施の形態においてはスナップショットの作成中にはクライアント 4500へのサー ビスが停止するので、クライアント 4500によってはトランザクション失敗と判断して RO LLBACKクエリを仲介装置 4200に送信する場合がある。本変形例では、このような 余計な ROLLBACK処理を未然に防止できる。
[0655] また、上記の実施の形態では、同期化処理中に送信キュー 4203から各クエリを削 除するタイミングは、当該クエリが属するトランザクションが全てのサーバ 4100におい て終了した時点としていた。この方法では、通常動作時におけるクエリの削除タイミン グと同じなので実装が容易であるという利点がある。一方、同期化処理中には、送信 キュー 4203のクエリが差分情報としてサーバ 4100において処理されたら随時削除 するようにしてもよい。また、同期化処理が完了した後に一括して削除するようにして も良い。
[0656] また、上記の実施の形態では、クエリのバッファリング機能と同期化処理用の差分 情報の記憶機能とを送信キュー 4203に統合させていたが、それぞれ機能毎に記憶 手段を設けるようにしてもよい。なお、この場合には、サーバ 4100が 3台構成となって いるときには、システムに組み込もうとするサーバ 4100と、同期化処理用サーバ 410 0とで差分情報記憶部を共有できるので、記憶容量を節約できると!、う点で有利であ る。
[0657] また、上記の実施の形態に加えて更に、各サーバ 4100にデータベース 4101ゃデ ータベース制御部 4102の障害を検出する障害検出手段を設けてもよい。この障害 検出手段は、データベース 4101やデータベース制御部 4102の動作を定期的に監 視することで障害を検出し、障害検出時には仲介装置 4200に障害発生を通知する 。これにより、仲介装置 4200では各サーバ 4100やネットワークでの障害発生検出を より確実且つ効率的に行うことができる。
[0658] また、各サーバは要求に応じて同じ応答をするならば同じ実装である必要はない。
すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンノ ィラオプショ ン、ハードウェアかソフトウェア力 などが異なっていてもよい。サーバには、 Postgre SQLなどのフリーソフトウェアや Oracleなどの市販のソフトウェア、独自開発のソフト ウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サーバ 4 100aは PostgreSQLでサーバ 4100bは Oracleでも良い。
[0659] DBMSとしては、巿中品（例えば、 Oracleや PostgreSQL)を使う場合は、データ ベース制御部 4102は、データベース管理部とデータベースサーバ管理部に機能を 分けることによって、巿中品を無改造で使うことができる。データベース管理部は、デ ータベース 4101を直接操作するもので、例えば PostgreSQLの場合は postmaste rや postgresに相当する。データベースサーバ管理部は、仲介装置 4200とデータ ベース管理部の間に介在し、クエリの送受信を中継したりするほかに、他のサーバを 同期化する際のデータベース 4101のスナップショットを作成したり、そのスナップショ ットを他のサーバへ転送したりする処理を行う。また、上記データベースサーバ管理 部を仲介装置 4200に配置しても良い。このような構成にすることで、冗長化されてい な 、通常使用して 、るデータベースシステムにお!/、て、サーバ 4100とクライアント 45 00の間に中間装置 200を配置し、さらにサーバ 4100を増設するだけでサーバ 410 0の冗長化を実現できる。これは既存のデータベースシステムをなるベく変更せず簡 単に冗長化した 、場合に好適である。
[0660] 上記実施の形態では、スナップショットの作成には DBMSサーバの種類に依存し な 、汎用のツール (同期化用サーバから SELECTクエリで全てのデータを取り出す ツール)を用いることを前提とし、また、新規サーバでのリストアにも汎用のツール (新 規サーバへ INSERTクエリで全てのデータを入れるツール）を用いること前提として いた。これにより、 DBMSサーバの種類に依存することなく本発明を実施できるだけ でなぐ異種 DBMS間（例えば PostgreSQLと Oracle)でのクエリ翻訳手段を併用 することで同一システム内に異種 DBMSを混在させることができる。異種 DBMSサ ーバが混在したシステムとしては、例えば一台の Oracleと二台の PostgreSQLを使 つた三重化システムが挙げられる。このように、高価なライセンスを必要とするサーバ と、ライセンスが低廉又は無料のサーバを混在させることで、高価なライセンスを必要 とするサーバの冗長化を低コストで実現できる。
[0661] また、上記実施の形態では、汎用のスナップショット作成ツールを用いることを前提 としていたため、第 19の実施の形態においてはスナップショット作成開始力も作成完 了までは新 、クエリを実行させて 、な力つた。これは該スナップショット作成ツール では、スナップショット作成開始以降に COMMITされる更新クエリがスナップショット に反映されるか否かが確定しないためである。これにより、データベースサイズが大き い場合には、新しいクエリを実行できない時間が長期化するおそれがある。そこで、 スナップショット作成中でもクエリを実行でき、且つ、スナップショット作成開始以降に COMMITされる更新クエリはスナップショットに反映されな 、ことが保証されて 、るッ ールを用いると、スナップショット作成中でもクエリを実行できる。このようなツールは 一般的には DBMSサーバ固有のツールとして提供されている。例えば、 PostgreS QLでは、 pg— dumpや PostgreSQL8. 0で機能追加される PITR(Point In Time Recovery)機能が挙げられる。
[0662] スナップショット作成ツールとして pg— dumpを用いた場合の動作につ!、て上記第 1の実施形態の変形例として説明する。この場合、図 147におけるステップ S4317が 「pg— dumpの実行指示」に相当し、ステップ S4318力 ¾g— dumpの開始、ステップ S4322が pg— dumpの完了となる。汎用ツールを用いた上記第 1の実施形態ではス テツプ S4309の UPDATEクエリはスナップショット作成完了まで実行できな 、が、 pg —dumpを用いた場合はステップ S4318の直後に実行できる。また、ステップ S4319 の BEGINクエリは、ステップ S4338の UPDATEクエリと同様に、仲介装置 4200が 受信すると即座にサーバ 4100aへ転送され処理される。このように、 pg— dumpを用 Vヽればスナップショット作成中でもクエリの処理を全く中断する必要はな 、。
[0663] また、上記実施の形態では、システムへの組み込み要求 (新規サーバのデータべ ース同期化要求）は当該新規サーバ 4100のデータベース制御部 4102が仲介装置 4200へ送信している力 さらに保守端末などの他の装置力も送信可能にしてもよい し、オペレータが仲介装置 4200に直接指示可能としても良い。
[0664] さらに、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが 、ハードウェアで実装しても良い。
[0665] また、上記実施の形態では、仮想サーバ 4800を構成する仲介装置 4200は 1台の みであつたが、複数台設けて冗長性を持たせることにより、より可用性の高い構成と することも可能である。仲介装置を多重化させる技術については、例えば本願出願 人による特開 2003— 345679号公報に記載されたものなどを用いればよい。
[0666] また、上記実施の形態では、クライアント 4500とサーバ 4100はそれぞれ別のネット ワーク 4300, 4400に属するようにし、 ί中介装置 4200力 S両 ッ卜ワーク 4300, 4400 を仲介するようなネットワーク構成とした力 本発明ではネットワーク構成は不問であ る。例えば、 1つのネットワークにクライアント 4500,サーバ 4100,仲介装置 4200が 属するように構成してちょい。
[0667] さらに、上記各実施の形態では、データベース一致検査装置 4600を多重化デー タベースシステムの外側、すなわちネットワーク 4400に接続していた力 多重化デー タベースシステムの内側のネットワーク 4300にデータベース一致検査装置 4600を 接続するようにしてもよ ヽ。
[0668] 上述の第 1〜11の実施の形態は障害で切り離されたサーバまたは新規のサーバを 、サービスを止めずにシステムに追加するものであり、第 12〜20の実施の形態は、 複数の DBMSが並列処理をしている際に同期が崩れてしまったことを検知し、それ を契機に再び同期状態へ戻すものであった。このうち、第 12〜20の実施の形態に お!、ては、同期が崩れたことを仲介装置が各サーバからの応答の有無をチェックし、 タイマ監視などにより無応答と判断することにより検知する方法と、各サーバからの応 答を比較してチェックし、不一致を検出することにより検知する方法がある。
[0669] これらの各実施の形態においては、他にも種々のバリユエーシヨンがある。例えば、 上述の各実施の形態においては、データベース制御部がサーバの代わりに仲介装 置にあっても良い。これは例えば、図 187に示すように、データベース制御部 4102a 及びデータベース制御部 4102bがサーバ 4100a及びサーバ 4100bの代わりに仲 介装置 4200にあっても良い。
[0670] 更にこの場合には、図 188に示すように、データベース制御部 4102a及び bにあつ たデータベース 4101へのデータの送信機能をクエリ送信処理部 4205が備え、デー タベース制御部 4102a及び bにあったデータベース 4101a及び bからの応答受信機 能を正当性判定部 4206が備え、また、データベース制御部 4102a及び bにあった 同期化処理機能を同期化処理制御部 4208が備える構成としても良い。
[0671] この場合、データベース 4101aやデータベース 4101bのスナップショットはネットヮ ークを経由して仲介装置へ送信され、仲介装置 4200の同期化処理制御部 4208が これを受信し、格納する。この処理の流れは、例えば、図 188及び図 189に示すもの である。なお、図 188及び図 189のステップ A〜C以外の処理は上述の処理と大きく 異なるものではない。
[0672] この処理の流れにお!、ては、まず、正常稼動して!/、るサーバ上のデータベース 41 Olaと、新たに追加するサーバである新規サーバ上で稼動するデータベース 4101b とがある場合に、仲介装置 4200の同期化処理制御部 4208は、同期化要求と共に 追加対象の新規サーバの指定を受け付ける（図 188及び図 189のステップ A)。この 受付は、他の端末装置力もネットワークを経由して行っても、ユーザから仲介装置 42 00の受付部に直接受け付けても、あるいは、正当性判定部 4206が異常を検知した 際に正当性判定部 4206が同期化要求を出力しても良い。 [0673] 次に、仲介装置 4200の同期化処理制御部 4208は、ネットワークを経由してサー バ 4100a上のデータベース 4101aをアクセスし、データベース 4101aのスナップショ ットを得る（図 188及び図 189のステップ B)。そして、仲介装置 4200の同期化処理 制御部 4208は、得られたスナップショットを記憶領域に格納する。
[0674] 次に、仲介装置 4200の同期化処理制御部 4208は、記憶領域からスナップショット を読み出し、ネットワークを経由してサーバ 4100bへ読み出したスナップショットを送 信し、データベース 4101bへの格納を要求する（図 188及び図 189のステップ C)。 サーバ 4100bは受信したスナップショットをデータベース 4101bへ格納し、上述の処 理と同様に同期化処理を行う。
[0675] このように、データベース制御部がサーバの代わりに仲介装置にある場合には、サ ーバ側から仲介装置へ差分情報の転送を要求することはなくなるため、図 149のス テツプ 4354などの処理は必要がない。さらに、サーバやクライアントにおいては既存 の DBMSやクライアントプログラムが実行されるのみである。即ち、既存のハードゥエ ァゃソフトウェアの構成に対して大きな変更を行う必要が無ぐシステムに仲介装置を 加えるだけで簡単に上述の各実施の形態が実現できる効果がある。
[0676] また、上述の各実施の形態において、差分情報蓄積部をサーバ側に配置しても良 い。この場合、サーバ 4100a等には差分情報を管理する機能ブロックが必要になる。 この機能ブロックは上述の実施の形態においては、仲介装置にあったものである。
[0677] 図 190は差分情報蓄積部をサーバ側に配置する場合における処理の流れを表し ている。差分情報を管理する機能ブロックは正常時にはクエリを蓄え、同期化処理時 には差分情報を同期化対象のサーバへ転送する。サーバ 4100bからサーバ 4100a への差分情報転送要求（図 190のステップ S 5001 )を契機に差分情報をサーバ 410 Oaからサーバ 4100bへ転送し、全ての差分情報を転送し終わった後、サーバ 4100 aからのシステム追加要求（図 190のステップ S5002)によってサーバ 4100bはシス テムに追カ卩される。
[0678] このように差分情報蓄積部をサーバ側に配置する場合には、仲介装置力 サーバ へ差分情報を転送する必要がなくなる。このため、同期化処理中の仲介装置と、サ ーバとの間の通信処理におけるトラフィックの増加を抑止することができる効果がある [0679] また、上述の各実施の形態においては、スナップショットの転送後であって、更に、 同期処理の対象となるデータベースのスナップショットからの復元の完了を待った後 に差分情報が転送される。このため、同期処理の開始から差分情報の転送までに長 い時間を要し、かつ、多くのクエリが発生する場合などにおいては、差分情報の容量 も大きなものとなることがありえる。このような大きな容量の差分情報の送受信が一度 に発生すると、仲介装置と、サーバとの間の通信処理におけるトラフィックが増大し、 他のクエリに対するレスポンスが遅れるといった問題が発生することがある。このため 、各サーバは、上述の各実施の形態において、差分情報を一時格納するためのバッ ファを記憶領域中に備えても良い。
[0680] 図 191は各サーバが差分情報を一時格納するためのバッファを記憶領域中に備え る場合における同期処理の流れを表している。上述の各実施の形態との差異は、上 述の実施の形態においてはスナップショットからのデータベースの復元を待って差分 情報を送信している力 図 191においては、スナップショットからのデータベースの復 元を待っていないことである。例えば、図 191のステップ S5011の BEGINはスナップ ショットからのデータベースの復元中であっても、ステップ S5015において送信される 。他のステップ S5012の UPDATEも同様に、ステップ S5016において送信されて いる。
[0681] なお、このようにスナップショットからのデータベースの復元を待つことなぐ差分情 報の転送を行う場合であっても、データベースのスナップショットからの復元完了後に 差分情報を適用するという順序自体には変更がない。このため、スナップショットから のデータベースの復元完了までの間、サーバにおいてバッファに差分情報を蓄積す る。
[0682] このように、各サーバが差分情報を一時格納するためのバッファを記憶領域中に備 える場合においては、一度に大量の差分情報が転送されることがなくなるため、仲介 装置と、サーバとの間の通信処理におけるトラフィックの増大が緩やかのものとなり、 他のクエリに対するレスポンスが遅れるといった問題の発生を抑止することができる効 果が得られる。 [0683] また、上述の各実施の形態においては、サーバと、仲介装置とは別々の装置として 動作していたが、仲介装置の機能をサーバにおいて実現しても良い。図 192は仲介 装置の機能をサーバ 1100aにおいて実現した場合の機能ブロック図である。この場 合の動作シーケンスは、サーバ 1100aと、仲介装置の間のネットワークを介した通信 がサーバ 1100a内でやり取りされる以外は上述のものと同様である。
[0684] また、上述の各実施の形態において、仲介装置を複数設けても良い。仲介装置は 上述の各実施の形態においてはフロントエンドサーバ的な機能を備えるため、クライ アントが多数ある場合やクライアントからのクエリの量が多い場合にはクエリの受付を 分散処理できる効果がある。
[0685] また、第 5の実施の形態において、図 35に示す正常稼働中のサーバ 1100a及び 新規サーバ 1100bの双方の送信状態を「未送信」で送信キュー 1206へ記憶する処 理については、「保留」として送信キュー 1206へ記憶しても良い。全ての差分情報が 処理された後に新規サーバ 1100bがシステムに追加されるため、クライアントへの応 答時間の増大を防ぐことができる。
産業上の利用可能性
[0686] 本発明によれば、データベースサーバに障害が発生しても少ない同期化用データ で復旧後のデータベースサーバの同期化を図ることができる。また、システム全体を ダウンさせることなく、データベースサーバのデータ記憶状況に拘わらずデータべ一 スサーバを任意に切り離し又は組み込むことができる。

Claims

請求の範囲
複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データ ベースサーバに中継するとともに各データベースサーバからの正常な応答の 1っをク ライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データべ一 スシステムにおいて、新規の又はこのシステム力も切り離されたデータベースサーノ （ 以後「新規データベースサーバ」と言う）をシステムに組み込む際に各データベース サーバを同期化する方法であって、
前記仲介装置は、
前記クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報 記憶部を備え、
前記新規データベースサーバの組み込み要求があると、
(la)正常稼働中のデータベースサーバに対してスナップショットの作成を指示し、 (lb)組み込み要求受信時以降に前記クライアントコンピュータ力 受信する処理 要求を差分情報として差分情報記憶部に順次記憶し、
(lc)前記新規データベースサーバから差分情報転送要求を受信すると前記差分 情報記憶部に記憶されている処理要求を前記新規データベースサーバに順次送出 し、
(Id)前記差分情報記憶部に記憶されている処理要求の送出が終了すると差分情 報の記憶処理を終了するとともに前記新規データベースサーバをシステムに組み込 み、
正常稼働中のデータベースサーバは、
(2a)前記仲介装置からスナップショット作成指示を受信するとその時点でのデータ ベースのスナップショットの作成を開始し、
(2b)作成したスナップショットを前記新規データベースサーバに転送し、 前記新規データベースサーバは、
(3a)前記正常稼働中のデータベースサーノから前記スナップショットを受信すると 前記スナップショットを用いてデータベースを復元し、
(3b)前記スナップショットに基づきデータベースの復元が完了すると前記仲介装置 に差分情報要求を送出し、
(3c)前記仲介装置力 順次受信した処理要求に応じた処理を行う
ことを特徴とする多重化データベースシステムにおける同期化方法。 前記仲介装置は、
前記ステップ（la)において、（lal)組み込み要求受信時以降にクライアントコンビ ユータから受信する新規トランザクションに係る処理要求の処理開始を、前記正常稼 働中のデータベースサーノ から前記スナップショット作成完了通知を受信するまで保 留し、（la2)組み込み要求受信時点で処理中のトランザクションが全て終了したら前 記正常稼働中のデータベースサーバに対してスナップショットの作成を指示し、 前記ステップ（lb)においては、前記正常稼働中のデータベースサーバからスナツ プショット作成完了通知があると組み込み要求受信時以降にクライアントコンピュータ から受信する新規トランザクションに係る処理要求の処理を再開するとともに、該処理 要求を差分情報として差分情報記憶部に順次記憶し、
前記正常稼働中のデータベースサーバは、
前記ステップ（2a)において、スナップショットの作成が完了すると前記仲介装置に スナップショット作成完了を通知する
ことを特徴とする請求項 1記載の多重化データベースシステムにおける同期化方法
前記仲介装置は、前記ステップ（lb)において、組み込み要求処理受信時に実行 中のトランザクションに係る処理要求も差分情報として前記差分情報蓄積部に記憶 する
ことを特徴とする請求項 1記載の多重化データベースシステムにおける同期化方法
前記仲介装置は、前記ステップ（lb)において、クライアントコンピュータから受信し た全ての処理要求を前記差分情報蓄積部に記憶するとともに、前記ステップ（lc)に おいて、
前記差分情報記憶部に記憶されている全ての処理要求を前記新規データベースに 送出する
ことを特徴とする請求項 1乃至 3何れか 1項記載の多重化データベースシステムに おける同期化方法。
[5] 前記仲介装置は、前記ステップ（lb)において、クライアントコンピュータから受信し た処理要求のうち参照系要求を除いたものを前記差分情報蓄積部に記憶するととも に、前記ステップ（lc)において、前記差分情報記憶部に記憶されている全ての処理 要求を前記新規データベースに送出する
ことを特徴とする請求項 1乃至 3何れか 1項記載の多重化データベースシステムに おける同期化方法。
[6] 前記仲介装置は、前記ステップ（lb)において、クライアントコンピュータから受信し た全ての処理要求を前記差分情報蓄積部に記憶するとともに、前記ステップ（lc)に おいて、
前記差分情報記憶部に記憶されている処理要求のうち参照系要求を除いたものを 前記新規データベースに送出する
ことを特徴とする請求項 1乃至 3何れか 1項記載の多重化データベースシステムに おける同期化方法。
[7] 前記仲介装置は、前記ステップ（lb)において、クライアントコンピュータから受信し た全ての処理要求を前記差分情報蓄積部に記憶するとともに、前記ステップ（lc)に おいて、
前記差分情報記憶部に記憶されている処理要求のうち前記正常稼働中のデータべ ースにおいて正常処理された処理要求のみを前記新規データベースサーバに送出 する
ことを特徴とする請求項 1乃至 3何れか 1項記載の多重化データベースシステムに おける同期化方法, 前記仲介装置は、前記ステップ（lc)において、前記差分情報記憶部に記憶されて いる処理要求のうち、トランザクション制御に係る処理要求及び参照系の処理要求を 含まずに更新系の処理要求のみを前記新規データベースサーバに送出する ことを特徴とする請求項 7記載の多重化データベースシステムにおける同期化方法
[9] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおいて、
前記仲介装置は、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データ ベースサーバ」と言う）の該システムへの組み込み要求があると、正常稼働中のデー タベースサーバに対してスナップショットの作成を指示し、組み込み要求受信時以降 にクライアントコンピュータ力 受信する処理要求を差分情報として前記差分情報記 憶部に順次記憶し、前記新規データベースサーバから差分情報転送要求を受信す ると前記差分情報記憶部に記憶されている処理要求を前記新規データベースサー バに順次送出し、前記差分情報記憶部に記憶されている処理要求の送出が終了す ると差分情報の記憶処理を終了するとともに前記新規データベースサーバをシステ ムに組み込む制御部とを備え、
前記データベースサーバは、
正常稼働中には、前記仲介装置からスナップショット作成指示を受信するとその時 点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを前 記新規データベースサーバに転送するとともに、 システムへの組み込みを行う際には、正常稼働中のデータベースサーバからスナツ プショットを受信すると該スナップショットを用いてデータベースを復元し、スナップシ ヨットに基づき前記データベースの復元が完了すると前記仲介装置に差分情報要求 を送出し、前記仲介装置力 順次受信した処理要求に応じた処理を行う制御部を備 えた
ことを特徴とする多重化データベースシステム。
[10] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた 多重化データベースシステムにおける仲介装置であって、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データ ベースサーバ」と言う）の該システムへの組み込み要求があると、正常稼働中のデー タベースサーバに対してスナップショットの作成を指示し、組み込み要求受信時以降 にクライアントコンピュータ力 受信する処理要求を差分情報として前記差分情報記 憶部に順次記憶し、前記新規データベースサーバから差分情報転送要求を受信す ると前記差分情報記憶部に記憶されている処理要求を前記新規データベースサー バに順次送出し、前記差分情報記憶部に記憶されている処理要求の送出が終了す ると差分情報の記憶処理を終了するとともに前記新規データベースサーバをシステ ムに組み込む制御部とを備えた
ことを特徴とする仲介装置。
[11] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける前記仲介装置を実現するプログラムであ つて、
コンピュータを、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データ ベースサーバ」と言う）の該システムへの組み込み要求があると、正常稼働中のデー タベースサーバに対してスナップショットの作成を指示し、組み込み要求受信時以降 にクライアントコンピュータ力 受信する処理要求を差分情報として前記差分情報記 憶部に順次記憶し、前記新規データベースサーバから差分情報転送要求を受信す ると前記差分情報記憶部に記憶されている処理要求を前記新規データベースサー バに順次送出し、前記差分情報記憶部に記憶されている処理要求の送出が終了す ると差分情報の記憶処理を終了するとともに前記新規データベースサーバをシステ ムに組み込む制御部として機能させる
ことを特徴とする仲介プログラム。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおけるデータベースサーバであって、
正常稼働中には、前記仲介装置からスナップショット作成指示を受信するとその時 点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを、 新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データべ ースサーバ」と言う）に転送するとともに、
システムへの組み込みを行う際には、正常稼働中のデータベースサーバからスナツ プショットを受信すると該スナップショットを用いてデータベースを復元し、該スナップ ショットに基づきデータベースの復元が完了すると前記仲介装置に差分情報要求を 送出し、前記仲介装置力 順次受信した処理要求に応じた処理を行う制御部を備え ことを特徴とするデータベースサーバ。
[13] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおけるデータベースサーバを実現するプロダラ ムであって、
前記ァータベースサーノ を、
正常稼働中には、前記仲介装置からスナップショット作成指示を受信するとその時 点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを、 新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データべ ースサーバ」と言う）に転送するとともに、
システムへの組み込みを行う際には、正常稼働中のデータベースサーバからスナツ プショットを受信すると該スナップショットを用いてデータベースを復元し、該スナップ ショットに基づき前記データベースの復元が完了すると前記仲介装置に差分情報要 求を送出し、前記仲介装置力 順次受信した処理要求に応じた処理を行う制御部と して機能させる
ことを特徴とするプログラム。
[14] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおいて、新規の又はこのシステム力 切り離され たデータベースサーバ（以後「新規データベースサーノ 」と言う）をシステムに組み込 む際に各々の前記データベースサーバを同期化する方法であって、
前記仲介装置は、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部を備え、 新規データベースサーバの組み込み要求があると、
(la)正常稼働中のデータベースサーバの中から選択した 1つのデータベースサー バ（以下「同期化用データベースサーバ」と言う）に対してスナップショットの作成を指 示するとともに、この同期化用データベースサーバをシステム力も切り離し、
(lb)組み込み要求受信時以降にクライアントコンピュータから受信する処理要求を 正常稼働中の他のデータベースサーバを用いて処理するとともに、該処理要求を差 分情報として前記差分情報記憶部に順次記憶し、
(lc)差分情報転送要求を受信すると前記差分情報記憶部に記憶されている処理 要求を前記同期化用データベースサーバ又は前記新規データベースサーバに順次 送出し、
(Id)前記差分情報記憶部に記憶されている処理要求の前記同期化用データべ一 スサーバ又は前記新規データベースサーバに対する送出が終了すると当該送出終 了に係る前記同期化用データベースサーバ又は前記新規データベースサーバをシ ステムに組み込み、
(le)前記同期化用データベースサーバ及び前記新規データベースサーバの双方 についてシステムへの糸且込が終了すると差分情報の記憶処理を終了し、
正常稼働中のデータベースサーバは、
(2a)前記仲介装置からスナップショット作成指示を受信するとその時点でのデータ ベースのスナップショットの作成を開始し、
(2b)作成したスナップショットを前記新規データベースサーバに転送し、
(2c)前記仲介装置力 差分情報として順次受信した処理要求に応じた処理を行 い、
前記新規データベースサーバは、
(3a)前記同期化用データベースサーノからスナップショットを受信すると該スナツ プショットを用いてデータベースを復元し、
(3b)該スナップショットに基づきデータベースの復元が完了すると前記仲介装置に 差分情報転送要求を送出し、
(3c)前記仲介装置力 差分情報として順次受信した処理要求に応じた処理を行う ことを特徴とする多重化データベースシステムにおける同期化方法。
[15] 前記仲介装置は、前記新規データベースサーバから差分情報転送要求を受信す ると、前記新規データベースサーバ及び前記同期化用データベースサーバの双方 に対して同一の差分情報を送出する
ことを特徴とする請求項 14記載の多重化データベースシステムにおける同期化方 法。
[16] 前記正常稼働中のデータベースサーバは、前記ステップ（2b)のスナップショットの 転送が終了すると、前記仲介装置に対して差分情報転送要求を送出し、
前記仲介装置は、差分情報転送要求の要求元の前記新規データベースサーバ又 は前記同期化用データベースサーバのそれぞれに対して互いに非同期で差分情報 を送出する
ことを特徴とする請求項 14記載の多重化データベースシステムにおける同期化方 法。
[17] 前記仲介装置は、
前記ステップ（la)において、組み込み要求受信時以降にクライアントコンピュータ 力 受信する新規トランザクションに係る処理要求の処理開始を、組み込み要求受 信時点で処理中の全てのトランザクションが終了するまで保留し、処理中のトランザク シヨンが全て終了したら、前記同期化用データベースサーバに対するスナップショット 作成指示及びシステムからの切り離し処理を行う
ことを特徴とする請求項 14乃至 16何れ力 1項記載の多重化データベースシステム における同期化方法。
[18] 前記仲介装置は、前記ステップ（lb)にお 、て、組み込み要求処理受信時に実行 中のトランザクションに係る処理要求も差分情報として前記差分情報蓄積部に記憶 する ことを特徴とする請求項 14乃至 16何れ力 1項記載の多重化データベースシステム における同期化方法。
[19] 前記仲介装置は、前記ステップ（lb)において、クライアントコンピュータから受信し た全ての処理要求を前記差分情報蓄積部に記憶するとともに、前記ステップ（lc)に ぉ 、て、前記差分情報記憶部に記憶されて 、る全ての処理要求を前記同期化用デ ータベースサーバ及び前記新規データベースサーバに送出する
ことを特徴とする請求項 14乃至 18何れ力 1項記載の多重化データベースシステム における同期化方法。
[20] 前記仲介装置は、前記ステップ（lb)において、クライアントコンピュータから受信し た処理要求のうち参照系要求を除いたものを前記差分情報蓄積部に記憶するととも に、前記ステップ（lc)において、前記差分情報記憶部に記憶されている全ての処理 要求を前記同期化用データベースサーバ及び前記新規データベースサーバに送出 する
ことを特徴とする請求項 14乃至 18何れ力 1項記載の多重化データベースシステム における同期化方法。
[21] 前記仲介装置は、前記ステップ（lb)において、クライアントコンピュータから受信し た全ての処理要求を前記差分情報蓄積部に記憶するとともに、前記ステップ（lc)に ぉ 、て、前記差分情報記憶部に記憶されて 、る処理要求のうち参照系要求を除 、 たものを前記同期化用データベースサーバ及び前記新規データベースサーバに送 出する
ことを特徴とする請求項 14乃至 18何れ力 1項記載の多重化データベースシステム における同期化方法。
[22] 前記仲介装置は、前記ステップ（lb)において、クライアントコンピュータから受信し た全ての処理要求を前記差分情報蓄積部に記憶するとともに、前記ステップ（lc)に おいて、前記差分情報記憶部に記憶されている処理要求のうち前記正常稼働中の データベースサーバにおいて正常処理された処理要求のみを前記同期化用データ ベースサーバ及び前記新規データベースサーバに送出する
ことを特徴とする請求項 14乃至 18何れ力 1項記載の多重化データベースシステム における同期化方法。
[23] 前記仲介装置は、前記ステップ（lc)において、前記差分情報記憶部に記憶されて いる処理要求のうち、トランザクション制御に係る処理要求及び参照系の処理要求を 含まずに更新系の処理要求のみを前記同期化用データベースサーバ及び前記新 規データベースサーバに送出する ことを特徴とする請求項 22記載の多重化データベースシステムにおける同期化方 法。
[24] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおいて、
前記仲介装置は、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データ ベースサーバ」と言う）の該システムへの組み込み要求があると、正常稼働中のデー タベースサーバの中から選択した 1つのデータベースサーバ（以下「同期化用データ ベースサーバ」と言う）に対してスナップショットの作成を指示するとともに、この同期 化用データベースサーバをシステム力 切り離し、組み込み要求受信時以降にクライ アントコンピュータ力 受信する処理要求を正常稼働中の他のデータベースサーバ を用いて処理するとともに、該処理要求を差分情報として前記差分情報記憶部に順 次記憶し、差分情報転送要求を受信すると前記差分情報記憶部に記憶されている 処理要求を前記同期化用データベースサーバ又は前記新規データベースサーバに 順次送出し、前記差分情報記憶部に記憶されて 、る処理要求の前記同期化用デー タベースサーバ又は前記新規データベースサーバに対する送出が終了すると当該 送出終了に係る前記同期化用データベースサーバ又は前記新規データベースサー バをシステムに組み込み、前記同期化用データベースサーバ及び前記新規データ ベースサーバの双方についてシステムへの糸且込が終了すると差分情報の記憶処理 を終了する制御部を備え、
前記データベースサーバは、
正常稼働中には、前記仲介装置からスナップショット作成指示を受信するとその時 点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを前 記新規データベースサーバに転送し、前記仲介装置から差分情報として順次受信し た処理要求に応じた処理を行うとともに、
システムへの組み込みを行う際には、前記同期化用データベースサーバからスナツ プショットを受信すると該スナップショットを用いてデータベースを復元し、該スナップ ショットに基づきデータベースの復元が完了すると前記仲介装置に差分情報転送要 求を送出し、前記仲介装置力 差分情報として順次受信した処理要求に応じた処理 を行う制御部を備えた
ことを特徴とする多重化データベースシステム。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置であって、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データ ベースサーバ」と言う）の該システムへの組み込み要求があると、正常稼働中のデー タベースサーバの中から選択した 1つのデータベースサーバ（以下「同期化用データ ベースサーバ」と言う）に対してスナップショットの作成を指示するとともに、この同期 化用データベースサーバをシステム力 切り離し、組み込み要求受信時以降にクライ アントコンピュータ力 受信する処理要求を正常稼働中の他のデータベースサーバ を用いて処理するとともに、該処理要求を差分情報として前記差分情報記憶部に順 次記憶し、差分情報転送要求を受信すると前記差分情報記憶部に記憶されている 処理要求を前記同期化用データベースサーバ又は前記新規データベースサーバに 順次送出し、前記差分情報記憶部に記憶されて 、る処理要求の前記同期化用デー タベースサーバ又は前記新規データベースサーバに対する送出が終了すると当該 送出終了に係る前記同期化用データベースサーバ又は前記新規データベースサー バをシステムに組み込み、前記同期化用データベースサーバ及び前記新規データ ベースサーバの双方についてシステムへの糸且込が終了すると差分情報の記憶処理 を終了する制御部とを備えた
ことを特徴とする仲介装置。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置を実現するプログラムであって、 前記仲介装置のコンピュータを、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データ ベースサーバ」と言う）の該システムへの組み込み要求があると、正常稼働中のデー タベースサーバの中から選択した 1つのデータベースサーバ（以下「同期化用データ ベースサーバ」と言う）に対してスナップショットの作成を指示するとともに、この同期 化用データベースサーバをシステム力 切り離し、組み込み要求受信時以降にクライ アントコンピュータ力 受信する処理要求を正常稼働中の他のデータベースサーバ を用いて処理するとともに、該処理要求を差分情報として前記差分情報記憶部に順 次記憶し、差分情報転送要求を受信すると前記差分情報記憶部に記憶されている 処理要求を前記同期化用データベースサーバ又は前記新規データベースサーバに 順次送出し、前記差分情報記憶部に記憶されて 、る処理要求の前記同期化用デー タベースサーバ又は前記新規データベースサーバに対する送出が終了すると当該 送出終了に係る前記同期化用データベースサーバ又は前記新規データベースサー バをシステムに組み込み、前記同期化用データベースサーバ及び前記新規データ ベースサーバの双方についてシステムへの糸且込が終了すると差分情報の記憶処理 を終了する制御部として機能させる
ことを特徴とするプログラム。
[27] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおけるデータベースサーバであって、
正常稼働中には、前記仲介装置からスナップショット作成指示を受信するとその時 点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを、 新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データべ ースサーバ」と言う）に転送し、前記仲介装置から差分情報として順次受信した前記 処理要求に応じた処理を行うとともに、
システムへの組み込みを行う際には、他のデータベースサーバからスナップショット を受信すると該スナップショットを用いてデータベースを復元し、該スナップショットに 基づきデータベースの復元が完了すると前記仲介装置に差分情報転送要求を送出 し、前記仲介装置力 差分情報として順次受信した処理要求に応じた処理を行う制 御部を備えた
ことを特徴とするデータベースサーバ。
[28] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 常な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおけるデータベースサーバを実現するプロダラ ムであって、
前記データベースサーノ を、
正常稼働中には、前記仲介装置からスナップショット作成指示を受信するとその時 点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを、 新規の又はこのシステム力 切り離されたデータベースサーバ（以後「新規データべ ースサーバ」と言う）に転送し、前記仲介装置力 差分情報として順次受信した処理 要求に応じた処理を行うとともに、
システムへの組み込みを行う際には、他のデータベースサーバからスナップショット を受信すると該スナップショットを用いてデータベースを復元し、該スナップショットに 基づきデータベースの復元が完了すると前記仲介装置に差分情報転送要求を送出 し、前記仲介装置力 差分情報として順次受信した処理要求に応じた処理を行う制 御部として機能させる
ことを特徴とするデータベースサーバプログラム。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにお 、て、各データベースサーバを同期化する方 法であって、
前記仲介装置は、
(a)データベースサーバから処理要求に対する応答がな 、事を検出すると該無応 答のデータベースサーバをシステム力 切り離し、
(b)システム力 切り離されたデータベースサーバとシステムに組み込まれて 、る正 常稼働中のデータベースサーバとの同期化処理を行い、
(c)同期化処理が完了したらシステム力 切り離されたデータベースサーバを再び システムに組み込む ことを特徴とする多重化データベースシステムにおける同期化方法。
[30] 前記仲介装置は、
(d)各々の前記データベースサーバ間における処理結果の矛盾を検出し、
(e)処理結果の矛盾を検出したら各応答の中から 1つの応答を選定するとともに当 該選定した応答をクライアントコンピュータに返す
ことを特徴とする請求項 29記載の多重化データベースシステムにおける同期化方 法。
[31] 前記仲介装置は、
(f)選定した応答以外の応答を返したデータベースサーバをシステム力 切り離し、
(g)システム力 切り離されたデータベースサーバとシステムに組み込まれて 、る正 常稼働中のデータベースサーバとの同期化処理を行い、
(h)同期化処理が完了したらシステム力 切り離されたデータベースサーバを再び システムに組み込む
ことを特徴とする請求項 30記載の多重化データベースシステムにおける同期化方 法。
[32] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにお 、て、各データベースサーバを同期化する方 法であって、
仲介装置は、
(i)各々の前記データベースサーバ間における処理結果の矛盾を検出し、
(j)処理結果の矛盾を検出したら各応答の中から 1つの応答を選定するとともに当 該選定した応答をクライアントコンピュータに返し、
(k)選定した応答以外の応答を返したデータベースサーバをシステム力 切り離し (1)システム力 切り離されたデータベースサーバとシステムに組み込まれている正 常稼働中のデータベースサーバとの同期化処理を行い、
(m)同期化処理が完了したらシステム力 切り離されたデータベースサーバを再び システムに組み込む
ことを特徴とする多重化データベースシステムにおける同期化方法。
[33] 前記仲介装置は、データベースサーバのシステム力 の切り離し処理を行うと該デ ータベースサーバに対して再起動指示を送出し、 該データベースサーバは、前記仲介装置からの再起動指示に応じて自身の再起 動を行うとともに再起動後に前記仲介装置に対してシステムへの組込要求を送出し、 前記仲介装置は、該データベースサーバからシステムの組込要求を受信すると該 データベースサーバと正常稼働中のデータベースサーバとの同期化処理を開始す る
ことを特徴とする請求項 29乃至 32何れ力 1項記載の多重化データベースシステム における同期化方法。
[34] 前記仲介装置は、クライアントコンピュータ力もの処理要求を差分情報として記憶す る差分情報記憶部を備え、前記同期化処理において、クライアントコンピュータから の処理要求を差分情報として記憶するとともに、正常稼働中のデータベースサーバ に対してスナップショットの作成を指示し、
スナップショット作成指示を受信したデータベースサーバは、データベースのスナツ プショットを作成してシステム力 切り離されたデータベースサーバに対してスナップ ショットを転送し、
スナップショットを受信したデータベースサーバは、該スナップショットからデータべ ースを復元するとともに前記仲介装置に対して差分情報の転送を要求し、
差分情報転送要求を受信した前記仲介装置は、要求元のデータベースサーバに 対して差分情報記憶部に記憶した処理要求を差分情報として送出する ことを特徴とする請求項 29乃至 33何れ力 1項記載の多重化データベースシステム における同期化方法。
[35] データベースサーバ検査用のクライアントコンピュータが検査用の参照系の処理要 求を前記仲介装置に送出する
ことを特徴とする請求項 29乃至 34何れ力 1項記載の多重化データベースシステム における同期化方法。
[36] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データ ベースサーバに中 ¾するとともに各々の前記データベースサーバからの正当な応答 の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備えた多重 化データベースシステムにお 、て、
前記仲介装置は、
データベースサーバから処理要求に対する応答がない事を検出すると該無応答の データベースサーバをシステム力 切り離し、システム力 切り離されたデータベース サーバとシステムに組み込まれている正常稼働中のデータベースサーバとの同期化 処理を行い、該同期化処理が完了したらシステム力 切り離されたデータベースサー バを再びシステムに組み込む制御部を備えた
ことを特徴とする多重化データベースシステム。
[37] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおいて、
前記仲介装置は、
各々の前記データベースサーバ間における処理結果の矛盾を検出し、処理結果 の矛盾を検出したら各応答の中から 1つの応答を選定するとともに当該選定した応答 を前記クライアントコンピュータに返し、選定した応答以外の応答を返したデータべ一 スサーバをシステム力も切り離し、システム力も切り離されたデータベースサーバとシ ステムに組み込まれている正常稼働中のデータベースサーバとの同期化処理を行い
、該同期化処理が完了したらシステム力 切り離されたデータベースサーバを再びシ ステムに組み込む制御部を備えた
ことを特徴とする多重化データベースシステム。
[38] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置であって、
データベースサーバから処理要求に対する応答がない事を検出すると該無応答の データベースサーバをシステム力 切り離し、システム力 切り離されたデータベース サーバとシステムに組み込まれている正常稼働中のデータベースサーバとの同期化 処理を行い、該同期化処理が完了したらシステム力 切り離されたデータベースサー バを再びシステムに組み込む制御部を備えた
ことを特徴とする仲介装置。
[39] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置であって、
各々の前記データベースサーバ間における処理結果の矛盾を検出し、処理結果 の矛盾を検出したら各応答の中から 1つの応答を選定するとともに当該選定した応答 をクライアントコンピュータに返し、選定した応答以外の応答を返したデータベースサ ーバをシステム力 切り離し、システム力 切り離されたデータベースサーバとシステ ムに組み込まれて 、る正常稼働中のデータベースサーバとの同期化処理を行 、、該 同期化処理が完了したらシステム力 切り離されたデータベースサーバを再びシステ ムに組み込む制御部を備えた ことを特徴とする仲介装置,
[40] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置を実現するプログラムであって、 前記仲介装置のコンピュータを、
データベースサーバから処理要求に対する応答がない事を検出すると該無応答の データベースサーバをシステム力 切り離し、システム力 切り離されたデータベース サーバとシステムに組み込まれている正常稼働中のデータベースサーバとの同期化 処理を行い、該同期化処理が完了したらシステム力 切り離されたデータベースサー バを再びシステムに組み込む制御部として機能させる
ことを特徴とする仲介プログラム。
[41] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置を実現するプログラムであって、 前記仲介装置のコンピュータを、
各々の前記データベースサーバ間における処理結果の矛盾を検出し、処理結果 の矛盾を検出したら各応答の中から 1つの応答を選定するとともに当該選定した応答 をクライアントコンピュータに返し、選定した応答以外の応答を返したデータベースサ ーバをシステム力 切り離し、システム力 切り離されたデータベースサーバとシステ ムに組み込まれて 、る正常稼働中のデータベースサーバとの同期化処理を行 、、該 同期化処理が完了したらシステム力 切り離されたデータベースサーバを再びシステ ムに組み込む制御部として機能させる
ことを特徴とする仲介プログラム。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにお 、て、各データベースサーバを同期化する方 法であって、
前記仲介装置は、クライアントコンピュータ力 の処理要求を差分情報として記憶す る差分情報記憶部を備え、データベースサーバから処理要求に対する応答がない 事を検出すると該無応答のデータベースサーバをシステム力 切り離し、システムか ら切り離されたデータベースサーバとシステムに組み込まれている正常稼働中のデ ータベースサーバとの同期化処理を行い、同期化処理が完了したらシステム力 切り 離されたデータベースサーバを再びシステムに組み込み、
前記同期化処理において、
前記仲介装置は、クライアントコンピュータから処理要求を受信すると当該処理要 求を正常稼働中のデータベースサーバに中継するとともに差分情報として前記差分 情報記憶部に記憶し、データベースサーバから受信した処理結果を前記差分情報と ともに記憶し、正常稼働中のデータベースサーバに対してスナップショットの作成を 指示し、
スナップショット作成指示を受信したデータベースサーバは、データベースのスナツ プショットを作成してシステム力 切り離されたデータベースサーバに対してスナップ ショットを転送し、
スナップショットを受信したデータベースサーバは、該スナップショットからデータべ ースを復元し、
前記仲介装置は、データベースサーバにおけるスナップショットからのデータべ一 スの復元完了を検出すると、該データベースサーバに対して差分情報記憶部に記憶 した処理要求を差分情報として送出し、データベースサーバから受信した差分情報 につ 、ての処理結果と差分情報記憶部に記憶した処理結果とを比較して一致しな!、 場合には同期化処理を再試行する
ことを特徴とする多重化データベースシステムにおける同期化方法。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにお 、て、各データベースサーバを同期化する方 法であって、
前記仲介装置は、クライアントコンピュータ力 の処理要求を差分情報として記憶す る差分情報記憶部を備え、各データベースサーバ間における処理結果の矛盾を検 出し、処理結果の矛盾を検出したら各応答の中から 1つの応答を選定するとともに当 該選定した応答をクライアントコンピュータに返し、選定した応答以外の応答を返した データベースサーバをシステム力 切り離し、システム力 切り離されたデータベース サーバとシステムに組み込まれている正常稼働中のデータベースサーバとの同期化 処理を行い、該同期化処理が完了したらシステム力 切り離されたデータベースサー バを再びシステムに組み込み、
前記同期化処理において、
前記仲介装置は、クライアントコンピュータから処理要求を受信すると当該処理要 求を正常稼働中のデータベースサーバに中継するとともに差分情報として前記差分 情報記憶部に記憶し、データベースサーバから受信した処理結果を前記差分情報と ともに記憶し、正常稼働中のデータベースサーバに対してスナップショットの作成を 指示し、
スナップショット作成指示を受信したデータベースサーバは、データベースのスナツ プショットを作成してシステム力 切り離されたデータベースサーバに対してスナップ ショットを転送し、
スナップショットを受信したデータベースサーバは、該スナップショットからデータべ ースを復元し、
前記仲介装置は、データベースサーバにおけるスナップショットからのデータべ一 スの復元完了を検出すると、該データベースサーバに対して差分情報記憶部に記憶 した処理要求を差分情報として送出し、データベースサーバから受信した差分情報 につ 、ての処理結果と差分情報記憶部に記憶した処理結果とを比較して一致しな!、 場合には同期化処理を再試行する
ことを特徴とする多重化データベースシステムにおける同期化方法。
[44] 前記仲介装置は、前記同期化処理の再試行を所定回数行っても同期化処理が完 了しない場合には該同期化処理を中止する
ことを特徴とする請求項 42又は 43何れか 1項記載の多重化データベースシステム における同期化方法。
[45] 前記仲介装置は、前記同期化処理を中止すると所定の出力手段に中止したことを 出力する
ことを特徴とする請求項 44記載の多重化データベースシステムにおける同期化方 法。
[46] 前記仲介装置は、データベースサーバのシステム力 の切り離し処理を行うと該デ ータベースサーバに対して再起動指示を送出し、
データベースサーバは、前記仲介装置からの再起動指示に応じて自身の再起動を 行うとともに再起動後に前記仲介装置に対してシステムへの組込要求を送出し、 前記仲介装置は、データベースサーバからシステムの組込要求を受信すると該デ ータベースサーバと正常稼働中のデータベースサーバとの同期化処理を開始する ことを特徴とする請求項 42乃至 45何れ力 1項記載の多重化データベースシステム における同期化方法。
[47] スナップショットを受信したデータベースサーバは、スナップショットからデータべ一 スを復元すると仲介装置に対して差分情報の転送を要求し、
前記仲介装置は、データベースサーバからの差分情報転送要求の受信により、該 データベースサーバにおけるスナップショットからのデータベースの復元完了を検出 する ことを特徴とする請求項 42乃至 46何れ力 1項記載の多重化データベースシステム
複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおいて、
前記仲介装置は、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
データベースサーバから処理要求に対する応答がない事を検出すると該無応答の データベースサーバをシステム力 切り離し、システム力 切り離されたデータベース サーバとシステムに組み込まれている正常稼働中のデータベースサーバとの同期化 処理を行い、該同期化処理が完了したらシステム力 切り離されたデータベースサー バを再びシステムに組み込み、
前記同期化処理においては、
クライアントコンピュータ力 処理要求を受信すると当該処理要求を正常稼働中の データベースサーバに中継するとともに差分情報として前記差分情報記憶部に記憶 し、データベースサーバから受信した処理結果を前記差分情報とともに記憶し、正常 稼働中のデータベースサーバに対してスナップショットの作成を指示し、データべ一 スサーバにおけるスナップショットからのデータベースの復元完了を検出すると、該デ ータベースサーバに対して差分情報記憶部に記憶した処理要求を差分情報として 送出し、データベースサーバから受信した差分情報についての処理結果と差分情報 記憶部に記憶した処理結果とを比較して一致しない場合には同期化処理を再試行 する制御部とを備え、
前記データベースサーバは、前記仲介装置からスナップショット作成指示を受信す ると、データベースのスナップショットを作成してシステムから切り離されたデータべ一 スサーバに対してスナップショットを転送するとともに、他のデータベースサーバから スナップショットを受信すると該スナップショットからデータベースを復元する制御部を 備えた
ことを特徴とする多重化データベースシステム。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおいて、
前記仲介装置は、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
各データベースサーバ間における処理結果の矛盾を検出し、処理結果の矛盾を検 出したら各応答の中から 1つの応答を選定するとともに当該選定した応答をクライア ントコンピュータに返し、選定した応答以外の応答を返したデータベースサーバをシ ステム力 切り離し、システム力 切り離されたデータベースサーバとシステムに組み 込まれている正常稼働中のデータベースサーバとの同期化処理を行い、該同期化 処理が完了したらシステム力 切り離されたデータベースサーバを再びシステムに組 み込み、
前記同期化処理においては、
クライアントコンピュータ力 処理要求を受信すると当該処理要求を正常稼働中の データベースサーバに中継するとともに差分情報として前記差分情報記憶部に記憶 し、データベースサーバから受信した処理結果を前記差分情報とともに記憶し、正常 稼働中のデータベースサーバに対してスナップショットの作成を指示し、データべ一 スサーバにおけるスナップショットからのデータベースの復元完了を検出すると、該デ ータベースサーバに対して差分情報記憶部に記憶した処理要求を差分情報として 送出し、データベースサーバから受信した差分情報についての処理結果と差分情報 記憶部に記憶した処理結果とを比較して一致しない場合には同期化処理を再試行 する制御部とを備え、 前記データベースサーバは、仲介装置からスナップショット作成指示を受信すると、 データベースのスナップショットを作成してシステムから切り離されたデータベースサ ーバに対してスナップショットを転送するとともに、他のデータベースサーバ力 スナ ップショットを受信すると該スナップショットからデータベースを復元する制御部を備え た
ことを特徴とする多重化データベースシステム。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置であって、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
データベースサーバから処理要求に対する応答がない事を検出すると該無応答の データベースサーバをシステム力 切り離し、システム力 切り離されたデータベース サーバとシステムに組み込まれている正常稼働中のデータベースサーバとの同期化 処理を行い、該同期化処理が完了したらシステム力 切り離されたデータベースサー バを再びシステムに組み込み、
前記同期化処理においては、
クライアントコンピュータ力 処理要求を受信すると当該処理要求を正常稼働中の データベースサーバに中継するとともに差分情報として前記差分情報記憶部に記憶 し、データベースサーバから受信した処理結果を前記差分情報とともに記憶し、正常 稼働中のデータベースサーバに対してスナップショットの作成を指示し、データべ一 スサーバにおけるスナップショットからのデータベースの復元完了を検出すると、該デ ータベースサーバに対して差分情報記憶部に記憶した処理要求を差分情報として 送出し、データベースサーバから受信した差分情報についての処理結果と差分情報 記憶部に記憶した処理結果とを比較して一致しない場合には同期化処理を再試行 する制御部とを備えた ことを特徴とする仲介装置。
[51] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置であって、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
各々の前記データベースサーバ間における処理結果の矛盾を検出し、処理結果 の矛盾を検出したら各応答の中から 1つの応答を選定するとともに当該選定した応答 をクライアントコンピュータに返し、選定した応答以外の応答を返したデータベースサ ーバをシステム力 切り離し、システム力 切り離されたデータベースサーバとシステ ムに組み込まれて 、る正常稼働中のデータベースサーバとの同期化処理を行 、、該 同期化処理が完了したらシステム力 切り離されたデータベースサーバを再びシステ ムに組み込み、
前記同期化処理においては、
クライアントコンピュータ力 処理要求を受信すると当該処理要求を正常稼働中の データベースサーバに中継するとともに差分情報として前記差分情報記憶部に記憶 し、データベースサーバから受信した処理結果を前記差分情報とともに記憶し、正常 稼働中のデータベースサーバに対してスナップショットの作成を指示し、データべ一 スサーバにおけるスナップショットからのデータベースの復元完了を検出すると、該デ ータベースサーバに対して差分情報記憶部に記憶した処理要求を差分情報として 送出し、データベースサーバから受信した差分情報についての処理結果と差分情報 記憶部に記憶した処理結果とを比較して一致しない場合には同期化処理を再試行 する制御部とを備えた
ことを特徴とする仲介装置。
[52] 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置を実現するプログラムであって、 前記仲介装置のコンピュータを、
クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
データベースサーバから処理要求に対する応答がない事を検出すると該無応答の データベースサーバをシステム力 切り離し、システム力 切り離されたデータベース サーバとシステムに組み込まれている正常稼働中のデータベースサーバとの同期化 処理を行い、該同期化処理が完了したらシステム力 切り離されたデータベースサー バを再びシステムに組み込み、
前記同期化処理においては、
クライアントコンピュータ力 処理要求を受信すると当該処理要求を正常稼働中の データベースサーバに中継するとともに差分情報として前記差分情報記憶部に記憶 し、データベースサーバから受信した処理結果を前記差分情報とともに記憶し、正常 稼働中のデータベースサーバに対してスナップショットの作成を指示し、データべ一 スサーバにおけるスナップショットからのデータベースの復元完了を検出すると、該デ ータベースサーバに対して差分情報記憶部に記憶した処理要求を差分情報として 送出し、データベースサーバから受信した差分情報についての処理結果と差分情報 記憶部に記憶した処理結果とを比較して一致しない場合には同期化処理を再試行 する制御部として機能させる
ことを特徴とする仲介プログラム。 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各々の前 記データベースサーバに中継するとともに各々の前記データベースサーバからの正 当な応答の 1つを前記クライアントコンピュータに処理結果として返す仲介装置とを備 えた多重化データベースシステムにおける仲介装置を実現するプログラムであって、 前記仲介装置のコンピュータを、 クライアントコンピュータ力 の処理要求を差分情報として記憶する差分情報記憶 部と、
各データベースサーバ間における処理結果の矛盾を検出し、処理結果の矛盾を検 出したら各応答の中から 1つの応答を選定するとともに当該選定した応答をクライア ントコンピュータに返し、選定した応答以外の応答を返したデータベースサーバをシ ステム力 切り離し、システム力 切り離されたデータベースサーバとシステムに組み 込まれている正常稼働中のデータベースサーバとの同期化処理を行い、該同期化 処理が完了したらシステム力 切り離されたデータベースサーバを再びシステムに組 み込み、
前記同期化処理においては、
クライアントコンピュータ力 処理要求を受信すると当該処理要求を正常稼働中の データベースサーバに中継するとともに差分情報として前記差分情報記憶部に記憶 し、データベースサーバから受信した処理結果を前記差分情報とともに記憶し、正常 稼働中のデータベースサーバに対してスナップショットの作成を指示し、データべ一 スサーバにおけるスナップショットからのデータベースの復元完了を検出すると、該デ ータベースサーバに対して差分情報記憶部に記憶した処理要求を差分情報として 送出し、データベースサーバから受信した差分情報についての処理結果と差分情報 記憶部に記憶した処理結果とを比較して一致しない場合には同期化処理を再試行 する制御部として機能させる
ことを特徴とする仲介プログラム。 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する仲介装置で あって、
前記クライアントコンピュータが送信した処理要求を差分情報として格納する差分 情報記憶部と、
新規の、又は、前記多重化データベースシステムから切り離されたデータベースサ ーバである第 1のデータベースサーバの該多重化データベースシステムへの組み込 み要求を受け付けたとき、前記複数のデータベースサーバに含まれる正常稼働中の データベースサーバをアクセスして作成したスナップショットを前記第 1のデータべ一 スサーバへ送信し、クライアントコンピュータ力 受信した処理要求を前記差分情報 記憶部に書き込み、前記差分情報記憶部から前記処理要求を読み出して前記第 1 のデータベースサーバへ順次送出し、前記処理要求の送出が完了すると前記第 1の データベースサーバを前記多重化データベースシステムへ組み込む制御部とを具 備することを特徴とする仲介装置。 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する仲介装置で あって、
前記クライアントコンピュータが送信した処理要求を差分情報として格納する差分 情報記憶部と、
新規の、又は、前記多重化データベースシステムから切り離されたデータベースサ ーバである第 1のデータベースサーバの前記多重化データベースシステムへの組み 込み要求を受け付けたとき、前記複数のデータベースサーバに含まれる正常稼働中 のデータベースサーバの中力 選択した第 2のデータベースサーバをアクセスして得 たスナップショットを前記第 1のデータベースサーバへ送信し、前記第 2のデータべ一 スサーバを前記多重化データベースシステム力も切り離し、クライアントコンピュータ からの処理要求を前記複数のデータベースサーバに含まれる正常稼働中のデータ ベースサーバを用いて処理するとともに前記差分情報記憶部に順次書き込み、前記 差分情報記憶部中の前記処理要求を前記第 2のデータベースサーバ、又は、前記 第 1のデータベースサーバへ順次送出し、前記差分情報記憶部中の前記処理要求 の送出が完了したとき、前記第 2のデータベースサーバ、又は、前記第 1のデータべ ースサーバを前記多重化データベースシステムに組み込む制御部とを具備すること を特徴とする仲介装置。 [56] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する仲介装置で あって、
前記クライアントコンピュータが送信した処理要求を差分情報として格納する差分 情報記憶部と、
前記複数のデータベースサーバに含まれ、処理要求に対する応答がないデータべ ースサーバである第 1のデータベースサーバを検知したとき、該第 1のデータベース サーバを前記多重化データベースシステム力 切り離し、前記複数のデータベース サーバに含まれる正常稼働中のデータベースサーバの中から選択した第 2のデータ ベースサーバをアクセスして得たスナップショットを前記第 1のデータベースサーバへ 送信し、クライアントコンピュータ力 の処理要求を前記差分情報記憶部に順次書き 込み、前記差分情報記憶部中の前記処理要求を読み出して前記第 1のデータべ一 スサーバへ順次送出し、前記差分情報記憶部中の前記処理要求の送出が完了した とき、前記第 1のデータベースサーバを該多重化データベースシステムに組み込む 制御部とを具備することを特徴とする仲介装置。
[57] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する仲介装置で あって、
前記クライアントコンピュータが送信した処理要求を差分情報として格納する差分 情報記憶部と、
前記複数のデータベースサーバの間における処理結果の矛盾をチェックし、前記 複数のデータベースサーバに含まれ、処理結果が矛盾するデータベースサーバで ある第 1のデータベースサーバを検知したとき、該第 1のデータベースサーバを前記 多重化データベースシステム力 切り離し、前記複数のデータベースサーバに含ま れる正常稼働中のデータベースサーバの中から選択した第 2のデータベースサーバ をアクセスして得たスナップショットを前記第 1のデータベースサーバへ送信し、クライ アントコンピュータからの処理要求を前記差分情報記憶部に順次書き込み、前記差 分情報記憶部中の前記処理要求を読み出して前記第 1のデータベースサーバへ順 次送出し、前記差分情報記憶部中の前記処理要求の送出が完了したとき、前記第 1 のデータベースサーバを該多重化データベースシステムに組み込む制御部とを具備 することを特徴とする仲介装置。
[58] 多重化データベースシステムにおいて、クライアントコンピュータからの処理要求を 複数のデータベースサーバに中継し、該複数のデータベースサーバからの正当な応 答の 1つを前記クライアントコンピュータに返信する仲介装置であって、
前記クライアントコンピュータが送信した処理要求を差分情報として記憶する差分 情報記憶部と、
前記複数のデータベースサーバ間の矛盾をチェックし、矛盾を検知したとき、矛盾 ありと判定されたデータベースサーバ以外のデータベースサーバへアクセスして作成 したスナップショットを前記矛盾ありと判定されたデータベースサーバに送信して格納 させ、前記クライアントコンピュータ力 受信した処理要求を前記差分情報記憶部へ 書き込み、前記処理要求を前記差分情報記憶部から読み出して前記矛盾ありと判定 されたデータベースサーバへ送信する制御部とを具備することを特徴とする仲介装 置。
[59] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する、前記複数の データベースサーバに含まれる第 1のデータベースサーバであって、
新規の、又は、前記多重化データベースシステムから切り離されたデータベースサ ーバである第 2のデータベースサーバの該多重化データベースシステムへの組み込 み要求を受け付けたとき、前記第 2のデータベースサーバと、前記複数のデータべ一 スサーバに含まれる正常稼働中のデータベースサーバとの同期化処理を行 、、前記 第 2のデータベースサーバを前記多重化データベースシステムへ組み込む制御部を 具備することを特徴とするデータベースサーバ。
[60] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する、前記複数の データベースサーバに含まれる第 1のデータベースサーバであって、
新規の、又は、前記多重化データベースシステムから切り離されたデータベースサ ーバである第 2のデータベースサーバの前記多重化データベースシステムへの組み 込み要求を受け付けたとき、前記複数のデータベースサーバに含まれる正常稼働中 のデータベースサーバの中力 選択した第 3のデータベースサーバを前記多重化デ ータベースシステム力 切り離し、前記第 2のデータベースサーバと、前記第 3のデー タベースサーバとの同期化処理を行い、前記第 3のデータベースサーバ、又は、前 記第 2のデータベースサーバを前記多重化データベースシステムに組み込む制御 部を具備することを特徴とするデータベースサーバ。
[61] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する、前記複数の データベースサーバに含まれる第 1のデータベースサーバであって、
前記複数のデータベースサーバに含まれ、処理要求に対する応答がないデータべ ースサーバである第 2のデータベースサーバを検知したとき、該第 2のデータベース サーバを前記多重化データベースシステム力 切り離し、前記複数のデータベース サーバに含まれる正常稼働中のデータベースサーバの中から選択したデータベース サーバと、前記第 2のデータベースサーバとの同期化処理を行い、前記第 2のデータ ベースサーバを該多重化データベースシステムに組み込む制御部を具備することを 特徴とするデータベースサーバ。 [62] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する、前記複数の データベースサーバに含まれる第 1のデータベースサーバであって、
前記複数のデータベースサーバの間における処理結果の矛盾をチェックし、前記 複数のデータベースサーバに含まれ、処理結果が矛盾するデータベースサーバで ある第 2のデータベースサーバを検知したとき、該第 2のデータベースサーバを前記 多重化データベースシステム力 切り離し、前記複数のデータベースサーバに含ま れる正常稼働中のデータベースサーバの中から選択したデータベースサーバと、前 記第 2のデータベースサーバとの同期化処理を行い、前記第 2のデータベースサー バを該多重化データベースシステムに組み込む制御部を具備することを特徴とする テ ~タべ ~ス廿^ ~ノ 。
[63] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する、前記複数の データベースサーバに含まれる第 1のデータベースサーバであって、
前記クライアントコンピュータが送信した処理要求を差分情報として格納する差分 情報記憶部と、
新規の、又は、前記多重化データベースシステムから切り離されたデータベースサ ーバである第 2のデータベースサーバの該多重化データベースシステムへの組み込 み要求を受け付けたとき、前記複数のデータベースサーバに含まれる正常稼働中の データベースサーバをアクセスして作成したスナップショットを前記第 2のデータべ一 スサーバへ送信し、クライアントコンピュータ力 受信した処理要求を前記差分情報 記憶部に書き込み、前記差分情報記憶部から前記処理要求を読み出して前記第 2 のデータベースサーバへ順次送出し、前記処理要求の送出が完了すると前記第 2の データベースサーバを前記多重化データベースシステムへ組み込む制御部とを具 備することを特徴とするデータベースサーバ。
[64] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する、前記複数の データベースサーバに含まれる第 1のデータベースサーバであって、
前記クライアントコンピュータが送信した処理要求を差分情報として格納する差分 情報記憶部と、
新規の、又は、前記多重化データベースシステムから切り離されたデータベースサ ーバである第 2のデータベースサーバの前記多重化データベースシステムへの組み 込み要求を受け付けたとき、前記複数のデータベースサーバに含まれる正常稼働中 のデータベースサーバの中力 選択した第 3のデータベースサーバをアクセスして得 たスナップショットを前記第 2のデータベースサーバへ送信し、前記第 3のデータべ一 スサーバを前記多重化データベースシステム力も切り離し、クライアントコンピュータ 力 の処理要求を前記複数のデータベースサーバに含まれる正常稼働中のデータ ベースサーバを用いて処理するとともに前記差分情報記憶部に順次書き込み、前記 差分情報記憶部中の前記処理要求を前記第 3のデータベースサーバ、又は、前記 第 2のデータベースサーバへ順次送出し、前記差分情報記憶部中の前記処理要求 の送出が完了したとき、前記第 3のデータベースサーバ、又は、前記第 2のデータべ ースサーバを前記多重化データベースシステムに組み込む制御部とを具備すること を特徴とするデータベースサーバ。
[65] 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する、前記複数の データベースサーバに含まれる第 1のデータベースサーバであって、
前記クライアントコンピュータが送信した処理要求を差分情報として格納する差分 情報記憶部と、 前記複数のデータベースサーバに含まれ、処理要求に対する応答がないデータべ ースサーバである第 2のデータベースサーバを検知したとき、該第 2のデータベース サーバを前記多重化データベースシステム力 切り離し、前記複数のデータベース サーバに含まれる正常稼働中のデータベースサーバの中から選択した第 3のデータ ベースサーバをアクセスして得たスナップショットを前記第 2のデータベースサーバへ 送信し、クライアントコンピュータ力 の処理要求を前記差分情報記憶部に順次書き 込み、前記差分情報記憶部中の前記処理要求を読み出して前記第 2のデータべ一 スサーバへ順次送出し、前記差分情報記憶部中の前記処理要求の送出が完了した とき、前記第 2のデータベースサーバを該多重化データベースシステムに組み込む 制御部とを具備することを特徴とするデータベースサーバ。 多重化データベースシステムにおいて、クライアントコンピュータ力 受信した処理 要求を複数のデータベースサーバに中継し、前記複数のデータベースサーバからの 応答の 1つを正常な応答として前記クライアントコンピュータへ送信する、前記複数の データベースサーバに含まれる第 1のデータベースサーバであって、
前記クライアントコンピュータが送信した処理要求を差分情報として格納する差分 情報記憶部と、
前記複数のデータベースサーバの間における処理結果の矛盾をチェックし、前記 複数のデータベースサーバに含まれ、処理結果が矛盾するデータベースサーバで ある第 2のデータベースサーバを検知したとき、該第 2のデータベースサーバを前記 多重化データベースシステム力 切り離し、前記複数のデータベースサーバに含ま れる正常稼働中のデータベースサーバの中から選択した第 3のデータベースサーバ をアクセスして得たスナップショットを前記第 2のデータベースサーバへ送信し、クライ アントコンピュータからの処理要求を前記差分情報記憶部に順次書き込み、前記差 分情報記憶部中の前記処理要求を読み出して前記第 2のデータベースサーバへ順 次送出し、前記差分情報記憶部中の前記処理要求の送出が完了したとき、前記第 2 のデータベースサーバを該多重化データベースシステムに組み込む制御部とを具備 することを特徴とするデータベースサーバ。 クライアントコンピュータからの処理要求を複数のデータベースサーバに中継し、前 記複数のデータベースサーノくからの応答の 1つを正当な応答として前記クライアント コンピュータに返す多重化データベースシステムにおいて、新規の、又は、前記多重 化データベースシステム力 切り離された第 1のデータベースサーバを同期化する同 期化方法であって、
前記複数のデータベースサーバに含まれる正常稼動中の第 2のデータベースサー バをアクセスしてスナップショットを生成し、
前記スナップショットと、前記スナップショットに反映されて ヽな 、クライアントからの 処理要求とに基づいて前記第 1のデータベースサーバと、前記複数のデータベース サーバに含まれる正常稼動中のデータベースサーバとの同期を取ることを特徴とす る同期化方法。
PCT/JP2005/006483 2004-04-01 2005-04-01 多重化データベースシステム WO2005096155A1 (ja)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
JP2004-109106 2004-04-01
JP2004109106A JP2007241322A (ja) 2004-04-01 2004-04-01 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム
JP2004141174A JP2007241323A (ja) 2004-05-11 2004-05-11 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム
JP2004-141174 2004-05-11
JP2004237438A JP2007241324A (ja) 2004-08-17 2004-08-17 多重化データベースシステム及びその同期化方法、仲介装置、仲介プログラム
JP2004-237438 2004-08-17
JP2004369841A JP2007241325A (ja) 2004-12-21 2004-12-21 多重化データベースシステム及びその同期化方法、仲介装置、仲介プログラム
JP2004-369841 2004-12-21

Publications (1)

Publication Number Publication Date
WO2005096155A1 true WO2005096155A1 (ja) 2005-10-13

Family

ID=35063968

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/006483 WO2005096155A1 (ja) 2004-04-01 2005-04-01 多重化データベースシステム

Country Status (1)

Country Link
WO (1) WO2005096155A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007317028A (ja) * 2006-05-26 2007-12-06 Ns Solutions Corp 情報処理装置、データベース管理システム、情報処理装置の制御方法及びプログラム
JP2009199197A (ja) * 2008-02-20 2009-09-03 Hitachi Ltd 計算機システム、データ一致化方法およびデータ一致化処理プログラム
JP2012208964A (ja) * 2012-08-03 2012-10-25 Hitachi Ltd 計算機システム、データ一致化方法およびデータ一致化処理プログラム
CN112613626A (zh) * 2020-12-28 2021-04-06 南方电网数字电网研究院有限公司 备调系统运行状态的监测方法、装置和计算机设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0689218A (ja) * 1992-09-08 1994-03-29 Hitachi Ltd 多重書きボリュームのバックアップ方式
JPH0962554A (ja) * 1995-08-29 1997-03-07 Nec Corp 静止点セーブ作成方式

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0689218A (ja) * 1992-09-08 1994-03-29 Hitachi Ltd 多重書きボリュームのバックアップ方式
JPH0962554A (ja) * 1995-08-29 1997-03-07 Nec Corp 静止点セーブ作成方式

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MISHIMA K. ET AL.: "Cots Seihin o Riyo shita Koshinraika System PREGMA no Teian to Hyoka.", THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS GIJUTSU KEKYU HOKOKU., vol. 102, no. 262, 15 August 2002 (2002-08-15), pages 13 - 18, XP002998118 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007317028A (ja) * 2006-05-26 2007-12-06 Ns Solutions Corp 情報処理装置、データベース管理システム、情報処理装置の制御方法及びプログラム
JP2009199197A (ja) * 2008-02-20 2009-09-03 Hitachi Ltd 計算機システム、データ一致化方法およびデータ一致化処理プログラム
JP2012208964A (ja) * 2012-08-03 2012-10-25 Hitachi Ltd 計算機システム、データ一致化方法およびデータ一致化処理プログラム
CN112613626A (zh) * 2020-12-28 2021-04-06 南方电网数字电网研究院有限公司 备调系统运行状态的监测方法、装置和计算机设备
CN112613626B (zh) * 2020-12-28 2023-01-20 南方电网数字电网研究院有限公司 备调系统运行状态的监测方法、装置和计算机设备

Similar Documents

Publication Publication Date Title
EP1179770B1 (en) File system
EP1569120B1 (en) Computer system for recovering data based on priority of the data
US6941327B2 (en) Apparatus and method for database synchronization in a duplex system
US20180150476A1 (en) System and Method for Event-Based Synchronization of Remote and Local File Systems
US7802137B2 (en) Journaling system switching to another logical volume to store subsequently received update history
US6823336B1 (en) Data storage system and method for uninterrupted read-only access to a consistent dataset by one host processor concurrent with read-write access by another host processor
US7266644B2 (en) Storage system and file-reference method of remote-site storage system
CN101211290B (zh) 镜像操作方法及镜像操作装置
US7836162B2 (en) Transaction processing system and transaction processing method
EP1507206A2 (en) Storage operation management program and method and storage management computer
CN102326152B (zh) 非同步远程复制系统以及存储控制方法
WO1996042019A1 (en) Real-time data protection system and method
WO2005096155A1 (ja) 多重化データベースシステム
US7167962B2 (en) Remote copy for a storage controller with reduced data size
CA2331467A1 (en) Highly available cluster virtual disk system
JP2006338145A (ja) 多重化データベースシステム及びその同期化方法、仲介装置、仲介プログラム
JP4389772B2 (ja) 計算機システムおよびバックアップ方法
US20070179963A1 (en) Computer system incorporating duplicated database servers
EP3830709B1 (en) Distributed recovery of server information
JP2004272318A (ja) 系切り替えシステムおよびその処理方法並びにその処理プログラム
KR100503899B1 (ko) 데이터베이스 복제시스템 및 그 복제방법
WO2023125412A1 (en) Method and system for synchronous data replication
JPH0895838A (ja) データの二重書込み制御方法
KR100439857B1 (ko) 주기억 데이터베이스의 이중화 처리기의 구성 및 방법그리고 주기억 데이터 베이스 내의 동기화 방법
JP2007241322A (ja) 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP