WO2014170952A1 - 計算機システム、計算機システム管理方法及びプログラム - Google Patents

計算機システム、計算機システム管理方法及びプログラム Download PDF

Info

Publication number
WO2014170952A1
WO2014170952A1 PCT/JP2013/061257 JP2013061257W WO2014170952A1 WO 2014170952 A1 WO2014170952 A1 WO 2014170952A1 JP 2013061257 W JP2013061257 W JP 2013061257W WO 2014170952 A1 WO2014170952 A1 WO 2014170952A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
computer
sequence number
control unit
recovery
Prior art date
Application number
PCT/JP2013/061257
Other languages
English (en)
French (fr)
Inventor
敏之 長谷川
展之 山本
Original Assignee
株式会社日立製作所
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
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to EP13882090.7A priority Critical patent/EP2988220B1/en
Priority to US14/426,996 priority patent/US9892183B2/en
Priority to PCT/JP2013/061257 priority patent/WO2014170952A1/ja
Priority to JP2015512218A priority patent/JP5952960B2/ja
Publication of WO2014170952A1 publication Critical patent/WO2014170952A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275—Synchronous replication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/162—Delete operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/219—Managing data history or versioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques

Definitions

  • the present invention relates to a distributed database composed of a plurality of computers.
  • RDBMS Relational DataBase Management System
  • NoSQL Not only SQL
  • KVS Key Value Store
  • a volatile storage medium capable of accessing data at high speed for example, a configuration for storing data in a memory (memory store), a non-volatile recording medium having excellent data storage durability, for example, SSD (Solid State Disk) ) And HDD, etc., various configurations such as a configuration for storing data (disk store) or a configuration in which the above-described configuration is used together.
  • a cluster is configured from a plurality of servers, and the KVS is configured on a memory of a server included in the cluster.
  • Each server constituting the distributed KVS stores data of a predetermined management range (for example, key range). Further, in the distributed KVS, in order to ensure data reliability, each server stores duplicate data of data included in the management range managed by other servers.
  • Each server executes processing as a master server for data included in the management range. That is, in response to a read request including a predetermined key, a server that manages a management range including data corresponding to the key reads data corresponding to the key. Each server operates as a slave server for replicated data in the management range managed by other servers.
  • master data data managed as a master server
  • slave data data managed as a slave server
  • the distributed KVS also ensures fault tolerance.
  • the number of slave servers that is, the number of servers that store the replicated data can be arbitrarily set by the computer system.
  • the number of slave servers for one management range is also referred to as multiplicity.
  • the multiplicity of the distributed KVS is reduced by one. If a server of multiplicity or higher in the distributed KVS is stopped, it becomes impossible to continue the business using the distributed KVS. Therefore, it is necessary to quickly recover the multiplicity of the distributed KVS. In the following description, restoring the multiplicity of the distributed KVS is referred to as “recovery”.
  • start-up processing of a new server is executed as a substitute for the failed server.
  • replication processing is performed to write the data held by the failed server to the new server.
  • a server that holds duplicate data of data held by a server in which a failure has occurred transmits the duplicate data to the new server.
  • the replication source server and the replication destination server must hold the same data. Therefore, when the data held by the replication source server is updated, it is necessary to write the updated data to the replication destination server.
  • Patent Document 1 As described above, the technique described in Patent Document 1 is known for the recovery processing of distributed KVS.
  • Patent Document 1 states that “(1) Take a snapshot of all data in a memory at a certain point of an active copy source computer, transfer it to the copy destination computer, write it to the memory of the copy destination computer, ( 2) Continuously monitoring data updates to the memory of the copy source computer from the execution of (1), repeatedly transferring the difference data regarding the detected update to the copy destination computer and writing to the memory of the copy destination computer (3) When the size of the difference data is equal to or smaller than the size that can be stored in one transmission message, the difference data is finally transferred once and written to the memory of the copy destination computer, and the processing of the copy destination computer is performed. "Resume in synchronization with the computer”.
  • the communication bandwidth usage (communication amount) accompanying the transmission of snapshots may increase, and the communication performance of the entire system may deteriorate.
  • the duplication source computer transmits the difference data to the duplication destination computer, which causes a problem that data that does not need to be transmitted is transmitted. For example, when a snapshot is transmitted, if some data is deleted by the update process, there arises a problem that differential data that does not need to be transmitted is transmitted.
  • An object of the present invention is to reduce the amount of memory used and the amount of communication bandwidth used, and to restore a system constituting a distributed KVS without stopping an application.
  • a typical example of the invention disclosed in the present application is as follows. That is, a computer system in which a plurality of computers are connected via a network, and a business is executed using a database configured from a storage area of each of the plurality of computers, and the data stored in the database is Including the identification information of the data, the value of the data, and a sequence number that is an execution order of events in the database, and each of the plurality of computers applies a distributed arrangement algorithm to the identification information of the data The data is distributed and arranged for each determined management range.
  • Each of the plurality of computers includes a data management unit that manages the arranged data, a data control unit that determines the sequence number of an operation on the arranged data, and a newly added computer with a predetermined management range.
  • the plurality of computers includes a first computer that transmits a recovery request and a second computer that receives the recovery request.
  • the second computer receives a recovery request from the first computer, transitions the state of the second computer to a recovery state, reads one or more data from the database based on the sequence number, A duplication process for transmitting the data as one duplication data to the first computer is executed.
  • the second computer determines the sequence number of the update command, updates predetermined data based on the update command, The update process to be transmitted is executed.
  • At least one of the first computer and the second computer controls the writing order of the first duplicated data and the second duplicated data in the first computer, and the first computer Based on the order of writing, a writing process for writing the first duplicated data and the second duplicated data into a storage area constituting the database is executed.
  • the present invention it is possible to restore a computer system that suppresses memory usage and communication bandwidth usage.
  • the system can be restored without stopping the business (application).
  • FIG. 1 is a sequence diagram for explaining the outline of the present invention.
  • the computer system shown in FIG. 1 includes three servers 100 and one client device 200.
  • the three servers 100 constitute a cluster, and a distributed database is constructed on a storage area of the server 100.
  • the distributed KVS is used as the distributed database.
  • the distributed KVS of this embodiment stores a plurality of data in which keys, values, and sequence numbers are associated with each other.
  • the cluster of the servers 100 configuring the distributed KVS is simply referred to as a cluster.
  • sequence number is a value indicating the execution order of the distributed KVS event.
  • a sequence number is assigned to each event in order from “1”.
  • the distributed KVS event indicates an operation (update process) on data and a configuration change of the computer system.
  • Each server 100 stores data associated with a key, a value, and a sequence number as data management information 300 in a data store 160 (see FIG. 2).
  • the key range represents the range of hash values calculated from each data key. Note that various methods such as the consistent hashing method, the range method, and the list method are used as the distributed arrangement algorithm.
  • Each server 100 operates as a master server that manages data (master data) included in a predetermined key range.
  • Each server 100 holds duplicate data (slave data) of data included in a key range managed by another server 100 and operates as a slave server.
  • FIG. 1 shows the distributed KVS recovery process.
  • the key range managed as a master by the failed server 100 is also referred to as a target key range.
  • Server 100-1 is a master server of the current target key range.
  • the server 100-3 is a server added as a new master server for the target key range.
  • the server 100-1 stores master data of the target key range as shown in the data management information 300-1.
  • the server 100-2 also stores the same slave data.
  • the server 100-3 transmits a recovery request to the server 100-1 (step S101).
  • the server 100-1 transitions to a recovery state.
  • the server 100-1 stores the largest sequence number among the sequence numbers included in the master data as information for specifying the range of data to be transmitted. That is, the server 100-1 stores the latest sequence number. Thereafter, the server 100-1 starts data replication processing.
  • the sequence number that the replication source server 100 stores at the start of the data replication process is also referred to as a replication sequence number.
  • the server 100-1 transmits the duplicate data of the data whose key is “A” to the server 100-3 (step S102).
  • the server 100-3 stores the received duplicate data in the data store 160 (see FIG. 2).
  • the master data held by the server 100-3 is as shown in the data management information 300-2.
  • the server 100-1 When the server 100-1 receives an update command for updating the value of the key “C” to “DDD” from the client device 200 in the recovery state (step S103), the server 100-1 is based on the distributed agreement algorithm. 2 determines the sequence number of the update instruction (step S104). At this time, the data replication process is temporarily stopped.
  • a plurality of servers 100 determine the execution order of operations for the distributed KVS based on the distributed agreement algorithm.
  • the Paxos algorithm is used as the distributed agreement algorithm.
  • the server 100-1 transmits a copy of the update command to the server 100-2 and makes a distribution agreement for the update command.
  • the sequence number of the received update instruction is determined to be “6”.
  • the server 100-2 also executes a similar data update process.
  • the server 100-1 updates the master data in accordance with the update command (step S105). Specifically, the server 100-1 stores “DDD” in the value of the data corresponding to the key “C” and stores “6” in the sequence number. At this time, the master data is as shown in the data management information 300-3. The server 100-2 similarly updates the data based on the distributed state machine event information 500 (see FIG. 5) generated by executing the distributed agreement.
  • the server 100-1 transmits the replicated data of the updated data to the server 100-3 (Step S106).
  • the server 100-3 stores the received duplicate data in the data store 160 (see FIG. 2).
  • the master data held by the server 100-3 is as shown in the data management information 300-4.
  • the server 100-1 resumes the data replication process after the data update process is completed.
  • the server 100-1 transmits the duplicate data of the data whose key is “B” to the server 100-3 (step S107).
  • the server 100-3 stores the received duplicate data in the data store 160 (see FIG. 2).
  • the master data held by the server 100-3 is as shown in the data management information 300-5.
  • the data order of the data management information 300-5 indicates the order of data writing in the server 100-3. Therefore, the server 100-3 holds master data in the same format as the data management information 300-3.
  • the server 100-1 ends the data replication process.
  • the replication source server 100-1 can transmit all data to the replication destination server 100-3 without acquiring a snapshot. Since data with a small data size is transmitted and the latest data is transmitted, the amount of communication bandwidth used in the recovery process can be suppressed. Further, it is not necessary to stop the system in order to maintain data consistency, and there is no need to synchronize between the server 100-1 and the server 100-3.
  • FIG. 2 is a block diagram showing the configuration of the computer system according to the first embodiment of the present invention.
  • the computer system includes a plurality of servers 100 and client devices 200.
  • the servers 100 or the server 100 and the client device 200 are connected to each other via a network 250.
  • the network 250 may have various wired and wireless configurations such as LAN, WAN, and SAN.
  • the present invention may be any network as long as the server 100 and the client device 200 can communicate with each other.
  • the network 250 includes a plurality of network devices (not shown).
  • the network device includes, for example, a switch and a gateway.
  • the server 100 includes a processor 110, a main storage device 120, an auxiliary storage device 130, and a network interface 140, and constitutes a distributed KVS.
  • the server 100 executes various processes according to the request transmitted from the client device 200. Assume that the configuration of each server 100 is the same.
  • the server 100 may include an input device such as a keyboard, a mouse, and a touch panel, and an output device such as a display.
  • an input device such as a keyboard, a mouse, and a touch panel
  • an output device such as a display.
  • the processor 110 executes a program stored in the main storage device 120.
  • the functions of the server 100 can be realized by the processor 110 executing the program.
  • processing is described with the program as the subject, it indicates that the program is being executed by the processor 110.
  • the main storage device 120 stores a program executed by the processor 110 and information necessary for executing the program.
  • the main storage device 120 may be a memory, for example.
  • the main storage device 120 of this embodiment stores a program for realizing the data management unit 151, the distributed state machine control unit 152, and the recovery control unit 153. Further, configuration information 170 and distributed agreement history information 180 are stored on the main storage device 120 as necessary information.
  • a data store 160 that is a database constituting the distributed KVS is stored.
  • the data store 160 of this embodiment stores data that includes a key, a value, and a sequence number.
  • the data store 160 of each server 100 stores master data and slave data.
  • the auxiliary storage device 130 stores various information.
  • the auxiliary storage device 130 may be an HDD or an SSD.
  • a disk store (not shown) for constructing the distributed KVS may be constructed on the auxiliary storage device 130.
  • the network interface 140 is an interface for connecting to other devices via the network 250.
  • the data management unit 151 controls various processes for data managed by the server 100.
  • the data management unit 151 receives a command transmitted from the client device 200, and controls data read processing, write processing, and the like based on the command.
  • the data management unit 151 also executes processing such as data inquiry to other servers 100 and transmission of processing results to the client device 200.
  • the distributed state machine control unit 152 controls the consistency of distributed KVS data in each server 100. Specifically, the distributed state machine control unit 152 determines a sequence number that is an execution order of events input to the distributed KVS by communicating with the distributed state machine control unit 152 of the other server 100.
  • the state machine is a system in which the behavior of the target is expressed using “state” and “event”.
  • the state machine holds the current state inside, and when an event is input from the outside, the state machine changes the state according to a predetermined rule.
  • the distributed state machine is a mechanism for causing one or more state machines existing on a plurality of servers to execute the same behavior in a distributed system (see, for example, Patent Document 2).
  • a distributed agreement algorithm is used to determine the order in which events are input.
  • KVS can handle an operation such as an update command for a key as an event, and data update for the operation as a state transition can be handled as a set of state machines for each key. Therefore, in the distributed KVS, a distributed state machine can be used as a configuration for each server included in the cluster to hold the same data.
  • each server 100 includes one distributed state machine control unit 152.
  • the restoration control unit 153 controls the restoration process.
  • the recovery control unit 153 of the replication destination server 100 transmits a recovery request to the replication source server 100 and stores the data transmitted from the replication source in the data store 160.
  • the recovery control unit 153 of the replication source server 100 transmits data to the replication destination server 100.
  • the restoration control unit 153 holds restoration information 154 used for restoration processing. Details of the recovery information 154 will be described later with reference to FIG.
  • the configuration information 170 stores information indicating a data storage destination. That is, information indicating the master server and slave server of each key range is stored. Details of the configuration information 170 will be described later with reference to FIG.
  • the distributed agreement history information 180 stores information related to the agreement content of the event. Details of the distributed agreement history information will be described later with reference to FIG.
  • the client device 200 includes a processor 210, a main storage device 220, an auxiliary storage device 230, and a network interface 240, and transmits an update command for requesting the server 100 to execute various processes.
  • the processor 210 executes a program stored in the main storage device 220.
  • the functions of the client device 200 can be realized by the processor 210 executing the program.
  • the processing is described with the program as the subject, it indicates that the program is being executed by the processor 210.
  • the main storage device 220 stores a program executed by the processor 210 and information necessary for executing the program.
  • the main storage device 220 may be a memory, for example.
  • main storage device 220 of the present embodiment a program for realizing the application 251 and the configuration information management unit 252 is stored. Further, configuration information 260 is stored on the main storage device 220 as necessary information.
  • the auxiliary storage device 230 stores various information.
  • the auxiliary storage device 130 may be an HDD or an SSD.
  • the network interface 240 is an interface for connecting to other devices via the network 250.
  • the application 251 transmits an update command to the server 100. Further, the application 251 receives the processing result for the access request transmitted from the server 100.
  • the update command is a command for requesting an operation for data, that is, execution of update processing for data.
  • the update process of this embodiment includes data writing, data overwriting, and data deletion.
  • the configuration information management unit 252 manages the configuration information 260 for managing the data storage destination.
  • the configuration information 260 stores information indicating a data storage destination.
  • the configuration information 260 is the same as the configuration information 170.
  • the functions of the server 100 and the client device 200 are implemented using software, but the same functions may be implemented using dedicated hardware.
  • FIG. 3 is an explanatory diagram showing a format of data stored in the data store 160 according to the first embodiment of the present invention.
  • the data store 160 stores data management information 300.
  • the data management information 300 includes a plurality of data composed of keys, values, and sequence numbers.
  • data including a key, a value, and a sequence number is also referred to as key-value type data.
  • the data management information 300 includes Key 301, Value 302, and sequence number 303.
  • Key 301 stores an identifier (key) for identifying data.
  • the Value 302 stores actual data (value).
  • the sequence number 303 stores a value indicating the execution order of the update process (event) for the Key 301.
  • the user who operates the client device 200 can store data in the distributed KVS by designating the Key 301, and can acquire desired data from the distributed KVS by designating the Key 301.
  • Each server 100 manages key-value data for each predetermined Key 301 range (key range). That is, key value type data is distributed and arranged in each server 100 for each key range.
  • the server 100 executes processing as a master server for data in the designated management range 400. As a result, a large amount of data can be processed in parallel and at high speed.
  • the format of data stored in the data store 160 is not limited to that shown in FIG. 3, and may be data in a format in which the hash value, value, and sequence number of a key are associated with each other.
  • FIG. 4 is an explanatory diagram showing an example of the configuration information 170 according to the first embodiment of the present invention.
  • the configuration information 170 stores information related to the key range of data arranged in each server 100. Specifically, the configuration information 170 includes a server ID 401 and a key range 402.
  • the server ID 401 stores an identifier for uniquely identifying the server 100.
  • the server ID 401 stores, for example, an identifier, an IP address, a MAC address, and the like of the server 100.
  • the key range 402 stores a hash value range for specifying the key range.
  • the key range 402 includes a master 403 and a slave 404.
  • the master 403 stores a hash value that identifies the key range of the master data.
  • the slave 404 stores a hash value that specifies the key range of the slave data of each server 100.
  • the multiplicity is 1 distributed KVS.
  • FIG. 5 is an explanatory diagram illustrating an example of the distributed agreement history information 180 according to the first embodiment of this invention.
  • the distributed agreement history information 180 includes a plurality of distributed state machine event information 500.
  • the distributed state machine event information 500 stores information on events in the distributed KVS. Specifically, the distributed state machine event information 500 includes a sequence number 501 and proposal content 502.
  • Sequence number 501 stores a value indicating the execution order of events.
  • the proposal content 502 stores the specific content of the event.
  • the proposal content 502 illustrated in FIG. 5 stores a Put instruction 503 including a Key 504 and a Value 505.
  • FIG. 6 is an explanatory diagram illustrating an example of the recovery information 154 according to the first embodiment of this invention.
  • the restoration information 154 includes a replication sequence number 601, a target key range 602, destination information 603, and a merge sequence number 604.
  • the replication sequence number 601 stores a replication sequence number.
  • the target key range 602 stores a hash value that identifies the target key range.
  • the destination information 603 stores information for specifying the replication destination server 100.
  • the destination information 603 stores, for example, the IP address and port number of the server 100.
  • the merge sequence number 604 stores a sequence number indicating the execution order of events for adding a new server 100 to the cluster.
  • an event for adding a new server 100 to the cluster is also referred to as a member joining event.
  • FIG. 7 is a sequence diagram for explaining the outline of the present invention.
  • FIG. 7 shows processing executed after step S107 of FIG.
  • the server 100-1 transmits all data to be replicated to the server 100-3 (step S107), and then makes a distribution agreement of the member merge event with the server 100-2 (step S108). As a result, the sequence number of the member merge event is determined. In the following description, the sequence number of the member merge event is also referred to as a merge sequence number.
  • the server 100-1 stores the determined joining sequence number in the recovery information 154. Until the member merge event is executed, the server 100-1 performs processing as the master server of the target key range. That is, an update command to which a sequence number smaller than the merge sequence number is assigned is processed by the server 100-1.
  • the server 100-1 and the server 100-2 After the server 100-1 and the server 100-2 have agreed to distribute the member merge event, the server 100-1 and the server 100-2 start executing the member merge event. However, since the sequence number is not “15” at this time, the process waits for a certain period. If the sequence number is smaller than the merging sequence number after a certain period of time, the server 100-1 and the server 100-2 make a NOOP instruction distribution agreement and add the value of the sequence number.
  • the client device 200 transmits an update command for deleting the data of the key “A” to the server 100-1 (step S109). At this time, since the server 100-3 has not been added to the cluster, the update command is transmitted to the server 100-1.
  • the server 100-1 Upon receiving the update command, the server 100-1 makes a distribution agreement with the server 100-2 (step S110). In the example illustrated in FIG. 7, the sequence number of the received update command is determined as “7”.
  • the server 100-1 updates the master data in accordance with the update command (step S111). Specifically, the server 100-1 deletes the data of the key “A”. At this time, the master data is as shown in the data management information 300-6. Note that the server 100-2 similarly updates the data based on the distributed state machine event information 500 generated by executing the distributed agreement.
  • the server 100-1 transmits data instructing data deletion to the server 100-3 (step S112).
  • the server 100-3 deletes the data.
  • the master data held by the server 100-3 is as shown in the data management information 300-7.
  • the server 100-1 executes the processing from step S110 to step S112 until the sequence number reaches “15”.
  • the server 100-1 transmits the restoration completion data including the merge sequence number to the server 100-3 (step S113), and then releases the restoration state.
  • step S114 the server 100-1 and the server 100-2 execute a member joining event.
  • the configuration information 170 is updated so that the server 100-3 becomes a new master server.
  • the server 100-1 adds an entry for the server 100-3 to the configuration information 170, and sets the server 100-3 as a master server.
  • the server 100-2 and the server 100-3 execute the same processing. Further, the server 100-1 transmits the updated configuration information 170 to the server 100-3 and the client device 200.
  • the server 100-3 is added to the cluster, and the server 100-3 processes an update command for data included in the target key range.
  • the client apparatus 200 transmits an update command for adding data having a key “D” and a value “EEE” to the server 100-3 (step S115).
  • the server 100-3 makes a distribution agreement between the server 100-1 and the server 100-2 (step S116), and determines the sequence number of the received update command as “16”.
  • the server 100-3 updates the master data in accordance with the update command (step S117). Specifically, the server 100-3 stores data having a key “D”, a value “EEE”, and a sequence number “16”. Each of the server 100-1 and the server 100-2 similarly updates the data based on the distributed state machine event information 500 transmitted when the distributed agreement is executed. At this time, the master data is as shown in the data management information 300-8.
  • FIG. 8 is a flowchart for explaining the recovery process executed by the replication source server 100 according to the first embodiment of the present invention.
  • the server 100 receives a recovery request from the other server 100 (step S201). Specifically, the recovery control unit 153 receives the recovery request.
  • the recovery request includes a hash value for specifying the target key range and destination information of the copy destination server 100.
  • the server 100 generates recovery information 154 based on the received recovery request (step S202). Specifically, the following processing is executed.
  • the restoration control unit 153 acquires the hash value of the target key range and the destination information included in the restoration request.
  • the recovery control unit 153 outputs a replication sequence number acquisition request to the distributed state machine control unit 152.
  • the acquisition request includes the hash value of the target key range.
  • the distributed state machine control unit 152 searches the distributed state machine event information 500 corresponding to the target key range based on the hash value of the target key range included in the acquisition request. Furthermore, the distributed state machine control unit 152 refers to the sequence number 501 of the searched distributed state machine event information 500 and acquires the largest sequence number. That is, the latest sequence number is acquired.
  • the distributed state machine control unit 152 outputs the acquired sequence number to the recovery control unit 153 as a duplicate sequence number.
  • the restoration control unit 153 generates the restoration information 154 based on the hash value of the key range, the destination information, and the replication sequence number. Thereafter, the recovery control unit 153 transitions to a recovery state.
  • the recovery information 154 does not include the merge sequence number 604.
  • step S202 The above is the description of the processing in step S202.
  • step S203 the server 100 executes data replication processing. Details of the data replication process will be described later with reference to FIG.
  • the server 100 determines the sequence number of the member merging event, that is, the merging sequence number based on the distributed agreement algorithm (step S204). Specifically, the recovery control unit 153 instructs the distributed state machine control unit 152 to distribute the member merging event. Specific processing will be described later with reference to FIG.
  • the server 100 stores the determined merge sequence number in the recovery information 154 (step S205), and ends the process.
  • the replication destination server 100 When the difference between the merge sequence number and the replication sequence number is large, in a system that is not frequently updated, the replication destination server 100 is added to the cluster until an event with the merge sequence number occurs. I can't. In this case, the distributed state machine control unit 152 waits for the occurrence of a member joining event for a certain period after the process of step S205 is executed. If the sequence number after a certain period has elapsed is smaller than the merged sequence number, the distributed state machine control unit 152 performs a NOOP instruction distribution agreement a predetermined number of times.
  • FIG. 9 is a flowchart for explaining data replication processing executed by the replication source server 100 according to the first embodiment of the present invention.
  • the data replication process is executed mainly by the recovery control unit 153.
  • the restoration control unit 153 acquires an exclusive lock of data included in the target key range (step S301). As a result, the data update process for the target key range is not executed. Therefore, it can be avoided that the data replication process and the data update process occur simultaneously.
  • the recovery control unit 153 continues to wait until the exclusive lock is released.
  • the restoration control unit 153 searches for data to be copied from the data included in the target key range (step S302).
  • the recovery control unit 153 refers to the data management information 300 and the recovery information 154 of the data store 160, includes a sequence number older than the replication sequence number from the data included in the target key range, and Search for unsent data. In this embodiment, the recovery control unit 153 searches for data that is greater than the sequence number of the transmitted data and includes a sequence number that is equal to or less than the duplicate sequence number.
  • the restoration control unit 153 determines whether there is data to be replicated based on the search result (step S303). That is, it is determined whether or not all data to be copied has been transmitted.
  • the recovery control unit 153 reads the retrieved data, and transmits the read data to the replication destination server 100 as replication data (step S304). Specifically, the following processing is executed.
  • the restoration control unit 153 selects data to be transmitted from the retrieved data.
  • a selection method a method of selecting data in ascending order of the sequence number or a method of selecting data in the order of registration in the key dictionary can be considered.
  • the number of data to be selected may be one or two or more. In this embodiment, it is assumed that the number of selected data is one.
  • the information regarding the data selection method and the number of pieces of data to be selected may be preset in the recovery control unit 153 or included in the recovery request.
  • the restoration control unit 153 reads the selected data from the data store 160, and transmits the read data to the restoration control unit 153 of the replication destination server 100 as replication data.
  • step S304 The above is the description of the processing in step S304.
  • step S305 the recovery control unit 153 releases the exclusive lock of the target key range (step S305), and returns to step S301.
  • step S303 If it is determined in step S303 that there is no data to be copied, the recovery control unit 153 releases the exclusive lock of the target key range (step S306). Thereafter, the recovery control unit 153 instructs the distributed state machine control unit 152 to execute the distribution agreement of the member merge event (step S307), and ends the process. At this time, the distributed state machine control unit 152 executes the following processing.
  • the distributed state machine control unit 152 Upon receiving the instruction, the distributed state machine control unit 152 communicates with the distributed state machine control unit 152 of the other server 100 in accordance with the distributed agreement algorithm, distributes the processing contents of the member merge event, and sets the merge sequence number. decide.
  • the distributed state machine control unit 152 of each server 100 stores the distributed state machine event information 500 including the proposal content 502 of the member joining event in the distributed agreement history information 180.
  • the proposal content 502 includes information for updating the configuration information 170 and information for calculating the merge sequence number as the process content of the member merge event.
  • Information for updating the configuration information 170 includes information corresponding to the target key range 602 and the destination information 603.
  • the information for calculating the merge sequence number includes a conditional expression.
  • conditional expression is conceivable in which a predetermined value is added to the sequence number 501 given to the distributed state machine event information 500 corresponding to the member merge event, and the calculated value is calculated as the merge sequence number. Further, a conditional expression is conceivable in which the sequence number 501 is multiplied by a predetermined value, and the calculated value is calculated as a merging sequence number. The present invention is not limited to the conditional expression for calculating the merge sequence number.
  • the distributed state machine control unit 152 of each server 100 calculates a merge sequence number based on the proposal content 502 of the member merge event after the distribution agreement of the member merge event is performed. Further, the distributed state machine control unit 152 of each server 100 outputs the calculated merging sequence number to the recovery control unit 153.
  • the recovery control unit 153 holds the input merging sequence number.
  • the distributed state machine control unit 152 of each server 100 is in a waiting state for a certain period.
  • the distributed state machine control unit 152 of each server 100 executes a member joining event that has been in a waiting state.
  • the distributed state machine control unit 152 instructs the data management unit 151 to update the configuration information 170.
  • the instruction includes information corresponding to the target key range 602 and the destination information 603.
  • the data management unit 151 refers to the configuration information 170 and searches for the entry of the replication source server 100.
  • the data management unit 151 updates the hash value so that the target key range 602 is removed from the master 403 of the searched entry. Further, the data management unit 151 updates the hash value so that the target key range 602 is included in the slave 404 of the searched entry.
  • the data management unit 151 adds a new entry to the configuration information 170 and stores the identifier of the replication destination server 100 in the server ID 401 based on the destination information 603. Further, the data management unit 151 stores the hash value of the target key range 602 in the master 403 of the entry. Further, the data management unit 151 stores a predetermined hash value in the slave 404 of the entry.
  • determining the hash value of the slave 404 There are various methods for determining the hash value of the slave 404. For example, a method in which at least one server 100 holds the hash values of the master 403 and the slave 404 of the failed server as history information and determines the hash value of the slave 404 based on the history information can be considered. . Further, a method of determining the hash value of the slave 404 so as to satisfy the multiplicity in the distributed KVS by referring to the slave 404 of the entry of another server 100 can be considered. Note that the present invention is not limited to the method for determining the hash value stored in the slave 404.
  • FIG. 10 is a flowchart illustrating data update processing executed by the replication source server 100 according to the first embodiment of this invention.
  • the data update process is executed mainly by the data management unit 151.
  • the data management unit 151 receives an update command from the client device 200 (step S401).
  • the data management unit 151 determines the sequence number of the update command (step S402). Specifically, the following processing is executed.
  • the data management unit 151 requests the distributed state machine control unit 152 to make a distribution agreement of the update command together with the processing content of the update command.
  • the distributed state machine control unit 152 communicates with the distributed state machine control unit 152 of the other server 100 according to the distributed agreement algorithm, distributes a copy of the update command, and determines the sequence number of the update command.
  • the distributed state machine control unit 152 outputs the determined sequence number to the data management unit 151.
  • the data management unit 151 determines whether or not it is in a recovery state (step S403). Specifically, the following processing is executed.
  • the data management unit 151 transmits an acquisition request for the recovery information 154 to the recovery control unit 153.
  • the recovery control unit 153 When the recovery information 154 exists, the recovery control unit 153 outputs the recovery information 154 to the data management unit 151. When the recovery information 154 does not exist, the recovery control unit 153 outputs an error notification.
  • the data management unit 151 determines that it is in a recovery state. On the other hand, when the error notification is acquired, the data management unit 151 determines that the recovery state is not established.
  • step S408 If it is determined that the state is not the restoration state, the data management unit 151 proceeds to step S408.
  • the data management unit 151 determines whether the data to be processed in the update command is included in the target key range (step S404).
  • the data management unit 151 calculates the hash value of the key included in the update command.
  • the data management unit 151 determines whether or not the calculated key hash value is included in the target key range based on the calculated key hash value and the target key range 602 included in the acquired restoration information 154. judge. When it is determined that the calculated key hash value is included in the target key range, it is determined that the operation target data is included in the target key range.
  • step S408 If it is determined that the update target data is not included in the target key range, the data management unit 151 proceeds to step S408.
  • the data management unit 151 executes the data update process in the recovery state (step S405), and then executes the determination process (step S406).
  • the determination process is a process for determining whether or not the recovery process is completed.
  • the data management unit 151 notifies the processing result to the client device 200 (step S407), and ends the processing.
  • the other server 100 similarly performs the processing from step S403 to step S408. This process is independent of the master server process.
  • step S408 the data management unit 151 executes normal data update processing, and proceeds to step S407.
  • the data management unit 151 acquires an exclusive lock, and stores data in which the key, value, and sequence number are associated with each other in the data management information 300.
  • the normal data update process is a known technique, and thus detailed description thereof is omitted.
  • FIG. 11 is a flowchart for explaining data update processing in the recovery state according to the first embodiment of the present invention.
  • the data update process in the recovery state is executed mainly by the data management unit 151.
  • the data management unit 151 acquires an exclusive lock of data included in the target key range (step S501). As a result, the data replication process for the target key range is not executed. Therefore, it can be avoided that the data replication process and the data update process occur simultaneously.
  • the data management unit 151 continues to wait until the exclusive lock is released.
  • the data management unit 151 updates the data based on the update command (step S502). For example, when the update command is a command corresponding to data overwrite processing, the data management unit 151 searches for data to be updated, and overwrites a predetermined value on the value and sequence number of the searched data. Since the data update method is a known technique, a detailed description thereof is omitted.
  • the data management unit 151 instructs the recovery control unit 153 to transmit replicated data (step S503).
  • the instruction includes updated data.
  • the recovery control unit 153 receives the instruction, the recovery control unit 153 refers to the recovery information 154 and transmits the updated data to the recovery control unit 153 of the replication destination server 100 as replicated data.
  • the data management unit 151 may transmit the updated data as replication data to the recovery control unit 153 of the replication destination server 100. In this case, the data management unit 151 acquires destination information from the recovery control unit 153.
  • the data management unit 151 releases the exclusive lock (step S504) and ends the process. At this time, the data management unit 151 instructs the recovery control unit 153 to execute the determination process.
  • the data management unit 151 may omit the processes in steps S502 and S503.
  • Exclusive locks are acquired in the data replication process and the data update process in the recovery state. This is to control the order of duplicate data transmitted by two processes executed in parallel.
  • the replication source server 100 obtains an exclusive lock and controls the two processes to be executed in series. Thereby, data consistency in the distributed KVS can be maintained.
  • the replication source server 100 may receive the replication data in the order in which data inconsistency occurs due to a communication delay or the like.
  • the replication destination server 100 may receive the replicated data in the order of data deletion and data overwriting due to communication delay. In this case, data inconsistency occurs.
  • the replication source server 100 executes the two processes in series using an exclusive lock in order to avoid the inconsistency of data as described above, so that the replication data transmission order is To control.
  • the execution order of the two processes is controlled using the exclusive lock, but the present invention is not limited to this. Any method may be used as long as two processes such as queuing are executed in series.
  • FIG. 12 is a flowchart illustrating the determination process according to the first embodiment of the present invention.
  • the determination process is executed mainly by the recovery control unit 153.
  • the restoration control unit 153 starts the process when receiving an instruction to execute the determination process from the data management unit 151. First, the recovery control unit 153 determines whether or not the merge sequence number is stored in the recovery information 154 (step S601).
  • the recovery control unit 153 ends the process.
  • the recovery control unit 153 determines whether a member merge event occurs (step S602). Specifically, the following processing is executed.
  • the restoration control unit 153 acquires the merge sequence number 604 from the restoration information 154.
  • the recovery control unit 153 subtracts the sequence number 501 given to the update instruction in the data update process (step S405) executed before the determination process from the merge sequence number 604.
  • the sequence number 501 is assigned to the distributed state machine event information 500 including the proposal content 502 corresponding to the update command executed in the data update process in the recovery state.
  • the restoration control unit 153 determines whether or not the calculated value is “1”. When the calculated value is “1”, the recovery control unit 153 determines that a member joining event occurs.
  • the recovery control unit 153 ends the process.
  • the recovery control unit 153 transmits the recovery completion data to the recovery control unit 153 of the replication destination server 100 (step S603).
  • the recovery completion data includes the merge sequence number.
  • the restoration control unit 153 initializes the restoration information 154 (step S604) and ends the process. Specifically, the recovery control unit 153 deletes all information included in the recovery information 154. As a result, the recovery state is released.
  • FIG. 13 is a flowchart for explaining a recovery process executed by the replication destination server 100 according to the first embodiment of the present invention.
  • the server 100 sets information necessary for the recovery process (step S701), and transmits a recovery request to the server 100 based on the set information (step S702). Specifically, the recovery control unit 153 transmits a recovery request to the server 100 based on information set by the user.
  • information for specifying the replication source server 100 and the replication destination server is set.
  • the user sets the destination information and the target key range of the copy destination server 100.
  • a recovery request is transmitted to the replication source server 100 based on the set destination information.
  • the replication destination server 100 acquires the configuration information 170 from the other servers 100, refers to the acquired configuration information 170, and searches for the master server of the target key range.
  • the replication destination server 100 transmits a recovery request to the server 100 corresponding to the found master server.
  • the server 100 determines whether the received data is duplicated data (step S704). Specifically, the recovery control unit 153 determines whether the received data is duplicate data.
  • the server 100 writes the received data to the data store 160 (step S705), and returns to step S703. Specifically, the received data is written to the data store 160 by the recovery control unit 153. Note that the recovery control unit 153 may request the data management unit 151 to write data to the data store 160.
  • step S704 If it is determined in step S704 that the received data is not replicated data, that is, recovery completion data, the server 100 registers the merge sequence number (step S706) and ends the process. Specifically, the following processing is executed.
  • the recovery control unit 153 acquires the merge sequence number included in the recovery completion data, and outputs a registration request including the acquired merge sequence number to the distributed state machine control unit 152.
  • the distributed state machine control unit 152 temporarily holds the merge sequence number.
  • the distributed state machine control unit 152 may delete the merge sequence number after the member merge event has occurred.
  • the server 100 acquires the updated configuration information 170 from the replication source server 100.
  • the present invention is not limited to the method for acquiring the updated configuration information 170.
  • the following acquisition method can be considered.
  • the copy source server 100 transmits the configuration information 170 updated as one copy data to the copy destination server 100.
  • the replication source server 100 transmits recovery completion data including the updated configuration information 170.
  • the recovery request includes the hash value of the target key range, but it is not always necessary. For example, when all the servers 100 included in the cluster hold the same data, the user does not need to specify the target key range in step S701. In this case, all data stored in the server 100 is the target of the replication process.
  • the data update process and the data replication process are executed in parallel, it is possible to perform recovery while maintaining the consistency of the data of the replication source server and the replication destination server.
  • the memory usage of the replication source server can be reduced.
  • the network traffic can be reduced by transmitting one or a plurality of replicated data. Further, since the updated data is transmitted preferentially, it is not necessary to transmit the same key data a plurality of times. Therefore, it is possible to reduce the network communication amount in the restoration process.
  • step S701 the server 100 that executes the data replication process can also be selected. Specifically, the following processing is executed.
  • the replication destination server 100 Upon receiving the target key range from the user, the replication destination server 100 acquires the configuration information 170 from the server 100 included in the cluster.
  • the replication destination server 100 refers to the configuration information 170 and displays the master server and slave server information of the target key range to the user. The user selects the server 100 that executes the data replication process based on the displayed information.
  • the master server is selected as the server 100 that executes the data replication process, the same process as in the first embodiment is performed.
  • the recovery control unit 153 When the slave server is selected as the server 100 that executes the data replication process, the recovery control unit 153 includes the slave server identification information and the data replication process execution instruction in the recovery request. Further, the recovery control unit 153 transmits the recovery request to the slave server.
  • the slave server executes the processing shown in FIGS.
  • the replication source server 100 controls the reception order of the replicated data of the replication destination server 100 by acquiring an exclusive lock at the start of the data replication process and the data update process. This avoids data inconsistencies as described above.
  • the replication destination server 100 writes the replication data to the data store 160 in consideration of the execution order of the two processes.
  • the server 100 has a buffer for temporarily storing data. Since other configurations are the same as those of the first embodiment, description thereof is omitted. In the second embodiment, the information stored in the data store 160 is different. Other information is the same as in the first embodiment.
  • FIG. 14 is an explanatory diagram showing a format of data stored in the data store 160 according to the first embodiment of the present invention.
  • the data management information 300 of the second embodiment newly includes a deletion flag 304.
  • the deletion flag 304 stores information indicating whether or not the update process indicates data deletion. In the present embodiment, “True” is stored in the case of an update process indicating data deletion, and “False” is stored in an update process other than data deletion.
  • FIG. 15 is a flowchart for explaining data replication processing executed by the replication source server 100 according to the second embodiment of the present invention.
  • step S301 the processes of step S301, step S305, and step S306 are omitted.
  • Other processes are the same as those in the first embodiment.
  • FIG. 16 is a flowchart for explaining data update processing in the recovery state according to the second embodiment of the present invention.
  • step S501 and step S504 are omitted.
  • step S502 and step S503 Processing in the case of an update command that instructs data addition and data overwriting is the same as that in the first embodiment.
  • step S502 when the update command is a command to delete data, the data management unit 151 searches for data to be deleted based on the update command.
  • the data management unit 151 changes the deletion flag 304 of the searched data to “True”.
  • step S503 the data management unit 151 instructs the recovery control unit 153 to transmit the replication data to the replication destination server 100.
  • the transmission includes duplicate data in which the deletion flag 304 is “True”. Thereafter, the data management unit 151 deletes the data whose deletion flag 304 is “True”.
  • the recovery control unit 153 When the recovery control unit 153 receives the instruction, the recovery control unit 153 refers to the recovery information 154 and transmits the replication data to the recovery control unit 153 of the replication destination server 100.
  • FIG. 17 is a flowchart illustrating a recovery process executed by the replication destination server 100 according to the second embodiment of the present invention.
  • step S701 to step S704 is the same processing as in the first embodiment.
  • step S704 If it is determined in step S704 that the received data is duplicated data, the server 100 temporarily stores the received duplicated data in a buffer (step S801). Specifically, the recovery control unit 153 stores the received duplicate data in the buffer.
  • the server 100 determines whether or not to write the data stored in the buffer to the data store 160 (step S802).
  • the recovery control unit 153 when the capacity of data stored in the buffer is equal to or greater than a predetermined threshold, the recovery control unit 153 writes the data in the data store 160. Further, the recovery control unit 153 includes a timer, and writes the data into the data store 160 when a certain time has elapsed.
  • the server 100 returns to step S703.
  • the server 100 If it is determined that the replicated data stored in the buffer is written to the data store 160, the server 100 writes the replicated data stored in the buffer to the data store 160 (step S803), and then returns to step S703. Specifically, the following processing is executed.
  • the restoration control unit 153 refers to the sequence number included in the duplicate data stored in the buffer and selects the duplicate data including the smallest sequence number.
  • the recovery control unit 153 refers to the key of the selected duplicate data, and searches the buffer and data store 160 for duplicate data including the same key as the key.
  • the restoration control unit 153 selects the duplicate data including the largest sequence number from the retrieved duplicate data, and writes the selected duplicate data to the data store 160. Further, the recovery control unit 153 deletes the duplicate data retrieved from the buffer.
  • duplicated data whose deletion flag 304 is “True” is also temporarily stored in the data store 160.
  • the restoration control unit 153 determines whether data is stored in the buffer. When data is not accumulated in the buffer, the recovery control unit 153 ends the process. On the other hand, when data is stored in the buffer, the recovery control unit 153 repeatedly performs the same processing.
  • the processing is executed based on the order of the sequence numbers, but the processing may be executed in the registration order of the key dictionary.
  • step S704 If it is determined in step S704 that the received data is recovery completion data, the server 100 writes the data temporarily stored in the buffer to the data store 160, and then the data store 160 based on the deletion flag 304. The data is deleted from (Step S804). Specifically, the following processing is executed.
  • the recovery control unit 153 writes the data stored in the buffer to the data store 160.
  • the same method as in step S803 is used.
  • the recovery control unit 153 refers to the deletion flag 304 of the data management information 300 and searches for data in which “True” is stored in the deletion flag 304.
  • the recovery control unit 153 deletes the retrieved data from the data management information 300.
  • step S706 Since the process in step S706 is the same as the process in the first embodiment, a description thereof will be omitted.
  • the processing overhead associated with the exclusive lock control can be reduced.
  • the network traffic of the computer system can be reduced. Further, since the replication source server 100 does not need to acquire a snapshot at the time of recovery processing, the amount of memory used can be reduced. Moreover, since the transmission of the data of the same key can be suppressed by preferentially transmitting the updated data, the network traffic can be reduced.
  • data consistency can be maintained by controlling the order of writing the replicated data. Since data is written to the replication destination server 100 without stopping the update process, there is no need to stop the system. Since the replication destination server 100 is added to the cluster based on the merge sequence number, the consistency of the entire system can be maintained and the system configuration can be explicitly changed.
  • the various software illustrated in the present embodiment can be stored in various recording media (for example, non-temporary storage media) such as electromagnetic, electronic, and optical, and through a communication network such as the Internet. It can be downloaded to a computer.
  • recording media for example, non-temporary storage media
  • a communication network such as the Internet. It can be downloaded to a computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　ネットワークを介して複数の計算機が接続され、複数の計算機の各々が有する記憶領域から構成されたデータベースを用いて業務を実行する計算機システムであって、複数の計算機は、復旧要求を送信する第１の計算機、及び復旧要求を受信する第２の計算機を含み、第２の計算機は、復旧要求を受信し、シーケンス番号に基づいてデータベースに格納されるデータを読み出し、読み出されたデータを複製データとして第１の計算機に送信する複製処理と、復旧状態においてデータの更新命令を受信した場合、更新命令のシーケンス番号を決定し、更新命令に基づいて所定のデータを更新し、更新されたデータを複製データとして送信する更新処理と、を実行し、第１の計算機又は第２の計算機の少なくともいずれか一方が、第１の計算機における複製データの書き込み順番を制御し、第１の計算機は、書き込み順番に基づいて、受信した複製データを書き込む書込処理を実行する。

Description

計算機システム、計算機システム管理方法及びプログラム
　本発明は、複数の計算機から構成される分散データベースに関する。
　近年、Ｗｅｂを用いたアプリケーションを実行する計算システムにおいてデータ量が爆発的に増大しており、複数のサーバにデータを分散させることによって、データへのアクセス性能を向上させるシステムが様々知られている。例えば、ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ　ＤａｔａＢａｓｅ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）では、データを所定の範囲毎に分割し、分割されたデータを複数のサーバに配置することによって、システム全体のアクセス性能を向上させる方法が知られている。
　また、キャッシュサーバ等に用いられるシステムとして、ＫＶＳ（Ｋｅｙ　Ｖａｌｕｅ　Ｓｔｏｒｅ）等のＮｏＳＱＬ（Ｎｏｔ　ｏｎｌｙ　ＳＱＬ）データベースが知られている。
　ＫＶＳでは、データに高速にアクセス可能な揮発性の記憶媒体、例えばメモリに、データを格納する構成（メモリストア）、データ格納の永続性に優れる不揮発性の記録媒体、例えば、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｉｓｋ）やＨＤＤ等に、データを格納する構成（ディスクストア）、又は、前述したものを併用する構成等の種々の構成がとられている。
　メモリストア及びディスクストアには、データ（バリュー）と、データの識別子（キー）とがペアとなったレコードが複数格納される。
　インメモリ型分散ＫＶＳでは、複数のサーバからクラスタを構成して、そのクラスタに含まれるサーバのメモリ上に構成されるＫＶＳである。これによって、データアクセスの高速化、及びシステムの可用性が実現される。
　分散ＫＶＳを構成する各サーバは、所定の管理範囲（例えば、キーレンジ）のデータを格納する。また、分散ＫＶＳではデータの信頼性を確保するために、各サーバは他のサーバが管理する管理範囲に含まれるデータの複製データを格納する。
　各サーバは、管理範囲に含まれるデータのマスタサーバとして処理を実行する。すなわち、所定のキーを含む読み出し要求に対して、そのキーに対応するデータが含まれる管理範囲を管理するサーバが、キーに対応するデータを読み出すこととなる。また、各サーバは、他のサーバが管理する管理範囲の複製データのスレーブサーバとして稼働する。
　以下の説明では、マスタサーバとして管理するデータをマスタデータと記載し、スレーブサーバとして管理するデータをスレーブデータとも記載する。
　したがって、分散ＫＶＳでは、一つのサーバに障害が発生した場合であっても、当該サーバのマスタデータの複製データを保持する他のサーバが、新たなマスタサーバとして処理を継続することができる。
　前述したように分散ＫＶＳを構成するサーバには、管理サーバのような特別なサーバが存在しないため単一点障害が存在しない。すなわち、任意のサーバに障害が発生した場合であっても他のサーバが処理を継続できるため、計算機システムが停止することがない。したがって、分散ＫＶＳは耐障害性も確保される。
　なお、スレーブサーバの数、すなわち、複製データの格納先となるサーバの数は、計算機システムによって任意に設定することができる。以下、一つの管理範囲に対するスレーブサーバの数を多重度とも記載する。
　分散ＫＶＳを構成する一つのサーバが停止した場合、分散ＫＶＳの多重度は一つ減少した状態となる。分散ＫＶＳにおける多重度以上のサーバが停止すると、分散ＫＶＳを用いた業務を継続できなくなる。そのため、速やかに分散ＫＶＳの多重度を回復する必要がある。以下の説明では、分散ＫＶＳの多重度を回復させることを「復旧」と記載する。
　分散ＫＶＳの復旧では、以下のような処理が実行される。
　第一に、障害が発生したサーバの代わりとなる新規サーバの起動処理が実行される。
　第二に、障害が発生したサーバが保持するデータを新規サーバに書き込むための複製処理が実行される。具体的には、障害が発生したサーバが保持するデータの複製データを保持するサーバが、新規サーバに当該複製データを送信する。このとき、複製元のサーバ及び複製先のサーバは、同一のデータを保持する必要がある。したがって、複製元のサーバが保持するデータが更新された場合、当該更新されたデータを複製先のサーバに書き込む必要がある。
　第三に、新規サーバをクラスタに追加するための処理が実行される。
　分散ＫＶＳを利用するアプリケーションは、銀行口座及びインターネットショッピング等のオンラインシステム上の商取引を行うものが想定される。そのため、アプリケーションが処理を継続できるように、分散ＫＶＳを停止させることなく復旧する必要がある。
　前述したような、分散ＫＶＳの復旧処理については、特許文献１に記載された技術が知られている。
　特許文献１には、「（１）稼働中のコピー元計算機のある時点でのメモリの全データのスナップショットを取得し、コピー先計算機へ転送し、該コピー先計算機のメモリへと書込み、（２）（１）の実施中から継続的にコピー元計算機のメモリに対するデータ更新を監視し、検出した更新に関する差分データをコピー先計算機へ転送し、コピー先計算機のメモリへと書込むことを繰り返し、（３）差分データのサイズが１つの送信メッセージに格納できるサイズ以下となると、最後に１回差分データの転送、コピー先計算機のメモリへの書込みを行い、コピー先計算機の処理を該コピー元計算機と同期をとって再開する」ことが記載されている。
特開２００９－１９９１９７号公報 米国特許第５２６１０８５号明細書
　しかし、特許文献１に記載の技術では、複製元計算機がスナップショットを取得する必要があり、メモリ使用量が増大する。そのため、分散ＫＶＳに割り当てるメモリが不足し、システム全体の性能が低下する可能性がある。
　また、スナップショットの送信に伴う通信帯域の使用量（通信量）が増大し、システム全体の通信性能が低下する可能性がある。また、スナップショットを取得した後に、データの更新が発生した場合、複製元計算機は複製先計算機に差分データを送信するため、送信する必要のないデータが送信される問題が発生する。例えば、スナップショットの送信時に、更新処理によって一部のデータが削除されている場合、送信する必要のない差分データを送信するという問題が発生する。
　また、複製元計算機と複製先計算機との間で同期を取る場合、ユーザプログラム（アプリケーション）を停止させる必要がある。
　本発明は、メモリ使用量及び通信帯域の使用量を抑え、アプリケーションを停止させることなく分散ＫＶＳを構成するシステムを復旧させることを目的とする。
　本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ネットワークを介して複数の計算機が接続され、前記複数の計算機の各々が有する記憶領域から構成されたデータベースを用いて業務を実行する計算機システムであって、前記データベースに格納されるデータは、前記データの識別情報、前記データの値、及び前記データベースにおけるイベントの実行順番であるシーケンス番号を含み、前記複数の計算機の各々には、前記データの識別情報に対して分散配置アルゴリズムを適用して決定された管理範囲毎に当該データが分散して配置される。前記複数の計算機の各々は、配置されたデータを管理するデータ管理部と、配置されたデータに対する操作の前記シーケンス番号を決定するデータ制御部と、新たに追加された計算機に、所定の管理範囲に含まれるデータの複製データを送信する復旧制御部と、を有する。前記複数の計算機は、復旧要求を送信する第１の計算機、及び前記復旧要求を受信する第２の計算機を含む。前記第２の計算機は、前記第１の計算機から復旧要求を受信し、前記第２の計算機の状態を復旧状態に遷移させ、前記シーケンス番号に基づいて前記データベースからデータを一つ以上読み出し、第１の複製データとして前記第１の計算機に送信する複製処理を実行する。前記第２の計算機は、前記復旧状態において前記データの更新命令を受信した場合、前記更新命令の前記シーケンス番号を決定し、前記更新命令に基づいて所定のデータを更新し、第２の複製データとして送信する更新処理を実行する。前記第１の計算機又は前記第２の計算機の少なくともいずれか一方が、前記第１の計算機における前記第１の複製データ及び前記第２の複製データの書き込み順番を制御し、前記第１の計算機は、前記書き込み順番に基づいて、前記第１の複製データ及び前記第２の複製データを前記データベースを構成する記憶領域に書き込む書込処理を実行する。
　本発明によれば、メモリ使用量及び通信帯域の使用量を抑えた計算機システムの復旧が可能となる。また、業務（アプリケーション）を停止させることなくシステムを復旧することができる。
　前述した以外の課題、構成及び効果は、以下の実施形態の説明によって明らかにされる。
本発明の概要を説明するシーケンス図である。 本発明の実施例１における計算機システムの構成を示すブロック図である。 本発明の実施例１におけるデータストアに格納されるデータの形式を示す説明図である。 本発明の実施例１における構成情報の一例を示す説明図である。 本発明の実施例１における分散合意履歴情報の一例を示す説明図である。 本発明の実施例１における復旧情報の一例を示す説明図である。 本発明の概要を説明するシーケンス図である。 本発明の実施例１における複製元のサーバが実行する復旧処理を説明するフローチャートである。 本発明の実施例１における複製元のサーバが実行するデータ複製処理を説明するフローチャートである。 本発明の実施例１における複製元のサーバが実行する更新処理を説明するフローチャートである。 本発明の実施例１における復旧時のデータ更新処理を説明するフローチャートである。 本発明の実施例１における判定処理を説明するフローチャートである。 本発明の実施例１における複製先のサーバが実行する復旧処理を説明するフローチャートである。 本発明の実施例１におけるデータストアに格納されるデータの形式を示す説明図である。 本発明の実施例２における複製元のサーバが実行するデータ複製処理を説明するフローチャートである。 本発明の実施例２における復旧時のデータ更新処理を説明するフローチャートである。 本発明の実施例２における複製先のサーバが実行する復旧処理を説明するフローチャートである。
　まず、本発明の概要について説明する。
　図１は、本発明の概要を説明するシーケンス図である。
　図１に示す計算機システムは、三つのサーバ１００と、一つのクライアント装置２００から構成される。三つのサーバ１００はクラスタを構成し、当該サーバ１００が有する記憶領域上に分散データベースが構築される。本実施例では、分散データベースとして分散ＫＶＳを用いるものとする。本実施例の分散ＫＶＳには、キー、バリュー、及びシーケンス番号が対応づけられたデータが複数格納される。以下の説明では、分散ＫＶＳを構成するサーバ１００のクラスタを、単にクラスタと記載する。
　ここで、シーケンス番号は、分散ＫＶＳのイベントの実行順番を示す値である。本実施例では、「１」から順に各イベントにシーケンス番号が付与される。分散ＫＶＳのイベントは、データに対する操作（更新処理）、及び計算機システムの構成変更のことを示す。
　また、クラスタに含まれる各サーバ１００には、分散配置アルゴリズムに基づいて決定されたキーレンジ毎にデータが配置される。各サーバ１００は、キー、バリュー、及びシーケンス番号が対応づけられたデータをデータ管理情報３００としてデータストア１６０（図２参照）に格納する。
　ここで、キーレンジは、各データのキーから算出されたハッシュ値の範囲を表す。なお、分散配置アルゴリズムとしては、Ｃｏｎｓｉｓｔｅｎｔ　Ｈａｓｈｉｎｇ法、Ｒａｎｇｅ法及びＬｉｓｔ法等の種々の方法が用いられる。
　各サーバ１００は所定のキーレンジに含まれるデータ（マスタデータ）を管理するマスタサーバとして稼動する。また、各サーバ１００は、他のサーバ１００が管理するキーレンジに含まれるデータの複製データ（スレーブデータ）を保持し、スレーブサーバとして稼動する。
　図１では、分散ＫＶＳの復旧処理を示す。以下の説明では、障害発生したサーバ１００がマスタとして管理するキーレンジを対象キーレンジとも記載する。
　サーバ１００－１は、現在の対象キーレンジのマスタサーバである。サーバ１００－３は、対象キーレンジの新たなマスタサーバとして追加されるサーバである。
　サーバ１００－１は、データ管理情報３００－１に示すような対象キーレンジのマスタデータを格納する。なお、サーバ１００－２にも、同一のスレーブデータが格納される。
　サーバ１００－３は、サーバ１００－１に復旧要求を送信する（ステップＳ１０１）。サーバ１００－１は、当該復旧要求を受信すると、復旧状態に遷移する。
　このとき、サーバ１００－１は、送信対象のデータの範囲を特定する情報として、マスタデータに含まれるシーケンス番号のうち最も大きいシーケンス番号を記憶する。すなわち、サーバ１００－１は、最新のシーケンス番号を記憶する。その後、サーバ１００－１は、データ複製処理を開始する。以下の説明では、複製元のサーバ１００が、データ複製処理の開始時に記憶するシーケンス番号を複製シーケンス番号とも記載する。
　サーバ１００－１は、サーバ１００－３に、キーが「Ａ」のデータの複製データを送信する（ステップＳ１０２）。サーバ１００－３は、受信した複製データをデータストア１６０（図２参照）に格納する。このとき、サーバ１００－３が保持するマスタデータはデータ管理情報３００－２に示すようになる。
　サーバ１００－１は、復旧状態時に、クライアント装置２００からキー「Ｃ」のバリューを「ＤＤＤ」に更新するための更新命令を受信した場合（ステップＳ１０３）、分散合意アルゴリズムに基づいて、サーバ１００－２との間で当該更新命令のシーケンス番号を決定する（ステップＳ１０４）。このとき、データ複製処理は一時的に停止される。
　以下の説明では、複数のサーバ１００が分散合意アルゴリズムに基づいて、分散ＫＶＳに対する操作の実行順番を決定することを分散合意を行うとも記載する。なお、本実施例では、分散合意アルゴリズムとしてＰａｘｏｓアルゴリズムを用いる。
　サーバ１００－１は、サーバ１００－２に更新命令の複製を送信し、当該更新命令について分散合意を行う。図１に示す例では、シーケンス番号が「５」まで決定されているため、受信した更新命令のシーケンス番号は「６」に決定される。これによって、サーバ１００－２も同様のデータ更新処理を実行する。
　サーバ１００－１は、更新命令にしたがって、マスタデータを更新する（ステップＳ１０５）。具体的には、サーバ１００－１は、キー「Ｃ」に対応するデータのバリューに「ＤＤＤ」を格納し、シーケンス番号に「６」を格納する。このとき、マスタデータはデータ管理情報３００－３に示すようになる。なお、サーバ１００-２は、分散合意を実行することによって生成された分散状態マシンイベント情報５００（図５参照）に基づいて、同様にデータを更新する。
　サーバ１００－１は、サーバ１００－３に、更新されたデータの複製データを送信する（ステップＳ１０６）。サーバ１００－３は、受信した複製データをデータストア１６０（図２参照）に格納する。このとき、サーバ１００－３が保持するマスタデータはデータ管理情報３００－４に示すようになる。
　サーバ１００－１は、データの更新処理が完了した後、データ複製処理を再開する。
　サーバ１００－１は、サーバ１００－３に、キーが「Ｂ」のデータの複製データを送信する（ステップＳ１０７）。サーバ１００－３は、受信した複製データをデータストア１６０（図２参照）に格納する。このとき、サーバ１００－３が保持するマスタデータはデータ管理情報３００－５に示すようになる。なお、データ管理情報３００－５のデータの順番は、サーバ１００－３におけるデータの書き込み順を示す。したがって、サーバ１００－３は、データ管理情報３００－３と同一形式のマスタデータを保持する。
　ここで、複製シーケンス番号以下のシーケンス番号を含むデータが全て送信されたため、サーバ１００－１は、データ複製処理を終了する。
　本発明では、複製元のサーバ１００－１がスナップショットを取得することなく、複製先のサーバ１００－３に全てのデータを送信することができる。小さいデータサイズのデータが送信され、また、最新のデータが送信されるため、復旧処理における通信帯域の使用量を抑制できる。また、データの整合性を保つためにシステムを停止させる必要がなく、また、サーバ１００－１とサーバ１００－３との間で同期をとる必要がない。
　したがって、復旧処理時におけるネットワーク負荷を低減し、サービスの継続が可能なシステムの復旧が可能となる。
　図２は、本発明の実施例１における計算機システムの構成を示すブロック図である。
　計算機システムは、複数のサーバ１００、及びクライアント装置２００から構成される。各サーバ１００間又はサーバ１００とクライアント装置２００との間は、ネットワーク２５０を介して互いに接続される。
　ネットワーク２５０は、ＬＡＮ、ＷＡＮ及びＳＡＮ等の有線及び無線の種々の構成が考えられる。本発明は、サーバ１００及びクライアント装置２００が通信できるものであればどのようなネットワークであってもよい。なお、ネットワーク２５０には、複数のネットワーク装置（図示省略）が含まれる。ネットワーク装置は、例えば、スイッチ及びゲートウェイなどが含まれる。
　サーバ１００は、プロセッサ１１０、主記憶装置１２０、補助記憶装置１３０、及びネットワークインタフェース１４０を備え、分散ＫＶＳを構成するサーバである。サーバ１００は、クライアント装置２００から送信される要求にしたがって各種処理を実行する。各サーバ１００の構成は同一であるものとする。
　なお、サーバ１００は、キーボード、マウス、タッチパネル等の入力装置、及び、ディスプレイ等の出力装置を備えていてもよい。
　プロセッサ１１０は、主記憶装置１２０に格納されるプログラムを実行する。プロセッサ１１０がプログラムを実行することによって、サーバ１００が備える機能を実現することができる。以下、プログラムを主語に処理を説明する場合には、プロセッサ１１０によって、プログラムが実行されていることを示す。
　主記憶装置１２０は、プロセッサ１１０が実行するプログラム及び当該プログラムの実行に必要な情報を格納する。主記憶装置１２０は、例えば、メモリ等が考えられる。
　本実施例の主記憶装置１２０上には、データ管理部１５１、分散状態マシン制御部１５２、及び復旧制御部１５３を実現するためのプログラムが格納される。また、主記憶装置１２０上には、必要な情報として、構成情報１７０、及び分散合意履歴情報１８０が格納される。
　さらに、主記憶装置１２０上には、分散ＫＶＳを構成するデータベースであるデータストア１６０が格納される。本実施例のデータストア１６０には、キー、バリュー、及びシーケンス番号を一組としたデータが格納される。なお、各サーバ１００のデータストア１６０には、マスタデータ及びスレーブデータが格納される。
　補助記憶装置１３０は、各種情報を格納する。補助記憶装置１３０は、例えば、ＨＤＤ又はＳＳＤ等が考えられる。なお、補助記憶装置１３０上に分散ＫＶＳを構築するディスクストア（図示省略）が構築されてもよい。
　ネットワークインタフェース１４０は、ネットワーク２５０を介して他の装置と接続するためのインタフェースである。
　ここで、主記憶装置１２０に格納されるプログラム及び情報について説明する。
　データ管理部１５１は、サーバ１００が管理するデータに対する各種処理を制御する。データ管理部１５１は、クライアント装置２００から送信された命令を受け付け、当該命令に基づいて、データの読出処理及び書込処理等を制御する。また、データ管理部１５１は、他のサーバ１００へのデータの問い合わせ、クライアント装置２００への処理結果の送信等の処理も実行する。
　分散状態マシン制御部１５２は、各サーバ１００における分散ＫＶＳのデータの整合性を制御する。具体的には、分散状態マシン制御部１５２は、他のサーバ１００の分散状態マシン制御部１５２と通信することによって、分散ＫＶＳに対して入力されたイベントの実行順番であるシーケンス番号を決定する。
　ここで、状態マシンとは、「状態」及び「イベント」を用いて対象の振る舞いが表現されるシステムである。状態マシンは、内部に現在の状態を保持し、外部からイベントが入力された場合、予め決定されたルールにしたがって状態を遷移させる。
　分散状態マシンは、分散システムにおいて、複数のサーバ上に存在する一つ以上の状態マシンに同一の振る舞いを実行させるための仕組みである（例えば、特許文献２参照）。複数の状態マシンが同一の振る舞いを行うためには、各状態マシンに同一イベントを同一の入力順に入力する必要がある。そこで、イベントを入力する順番を決定するために分散合意アルゴリズムが用いられる。
　ＫＶＳは、キーに対する更新命令等の操作をイベント、当該操作に対するデータの更新を状態の遷移と仮定した場合、キー毎の状態マシンの集合として扱うことができる。したがって、分散ＫＶＳでは、クラスタに含まれる各サーバが同一のデータを保持するための構成として、分散状態マシンを用いることができる。
　ただし、キー毎に状態マシンを運用する場合、状態マシンの数が膨大となるため現実的ではない。例えば、全てのキーのデータ量が４バイトである場合、必要となる状態マシンの数は４０億個になる。
　したがって、一定のキーの集合毎に一つの状態マシンを運用する方が望ましい。すなわち、キーレンジに対して一つの状態マシンを存在するようにすればよい。なお、本実施例では、説明の簡単のために、一つのサーバ１００に一つの状態マシンが存在するものとする。この場合、各サーバ１００には一つの分散状態マシン制御部１５２が含まれる。
　復旧制御部１５３は、復旧処理を制御する。複製先のサーバ１００の復旧制御部１５３は、複製元のサーバ１００に復旧要求を送信し、複製元から送信されたデータをデータストア１６０に格納する。複製元のサーバ１００の復旧制御部１５３は、複製先のサーバ１００にデータを送信する。
　復旧制御部１５３は、復旧処理に用いる復旧情報１５４を保持する。復旧情報１５４の詳細については、図６を用いて後述する。
　構成情報１７０は、データの格納先を示す情報を格納する。すなわち、各キーレンジのマスタサーバ及びスレーブサーバを示す情報が格納される。なお、構成情報１７０の詳細については、図４を用いて後述する。分散合意履歴情報１８０は、イベントの合意内容に関する情報を格納する。分散合意履歴情報の詳細については、図５を用いて後述する。
　次に、クライアント装置２００について説明する。クライアント装置２００は、プロセッサ２１０、主記憶装置２２０、補助記憶装置２３０、及びネットワークインタフェース２４０を備え、サーバ１００に対して各種処理の実行を要求する更新命令を送信する。
　プロセッサ２１０は、主記憶装置２２０に格納されるプログラムを実行する。プロセッサ２１０がプログラムを実行することによって、クライアント装置２００が備える機能を実現することができる。以下、プログラムを主語に処理を説明する場合には、プロセッサ２１０によって、プログラムが実行されていることを示す。
　主記憶装置２２０は、プロセッサ２１０が実行するプログラム及び当該プログラムの実行に必要な情報を格納する。主記憶装置２２０は、例えば、メモリ等が考えられる。
　本実施例の主記憶装置２２０上には、アプリケーション２５１、及び構成情報管理部２５２を実現するためのプログラムが格納される。また、主記憶装置２２０上には、必要な情報として構成情報２６０が格納される。
　補助記憶装置２３０は、各種情報を格納する。補助記憶装置１３０は、例えば、ＨＤＤ又はＳＳＤ等が考えられる。
　ネットワークインタフェース２４０は、ネットワーク２５０を介して他の装置と接続するためのインタフェースである。
　ここで、主記憶装置２２０に格納されるプログラム及び情報について説明する。
　アプリケーション２５１は、サーバ１００に対して更新命令を送信する。また、アプリケーション２５１は、サーバ１００から送信されるアクセス要求に対する処理の結果を受信する。
　更新命令は、データに対する操作、すなわちデータに対する更新処理の実行を要求するための命令である。本実施例の更新処理には、データの書き込み、データの上書き、及びデータの削除が含まれる。
　構成情報管理部２５２は、データの格納先を管理する構成情報２６０を管理する。
　構成情報２６０は、データの格納先を示す情報を格納する。構成情報２６０は、構成情報１７０と同一のものである。
　なお、本実施例では、サーバ１００及びクライアント装置２００が備える機能を、ソフトウェアを用いて実現しているが、専用のハードウェアを用いて同一の機能を実現してもよい。
　図３は、本発明の実施例１におけるデータストア１６０に格納されるデータの形式を示す説明図である。
　本実施形態では、データストア１６０は、データ管理情報３００を格納する。データ管理情報３００には、キー、バリュー、及びシーケンス番号から構成されるデータが複数含まれる。以下、キー、バリュー、及びシーケンス番号から構成されるデータをキーバリュー型データとも記載する。
　データ管理情報３００は、Ｋｅｙ３０１、Ｖａｌｕｅ３０２、及びシーケンス番号３０３を含む。
　Ｋｅｙ３０１は、データを識別するための識別子（キー）を格納する。Ｖａｌｕｅ３０２は、実際のデータ（バリュー）を格納する。シーケンス番号３０３は、Ｋｅｙ３０１に対する更新処理（イベント）の実行順番を示す値を格納する。
　クライアント装置２００を操作するユーザは、Ｋｅｙ３０１を指定して分散ＫＶＳにデータを保存し、また、Ｋｅｙ３０１を指定して分散ＫＶＳから所望のデータを取得することができる。
　各サーバ１００は、所定のＫｅｙ３０１の範囲（キーレンジ）毎にキーバリュー型データを管理する。すなわち、キーレンジ毎にキーバリュー型データが各サーバ１００に分散して配置される。サーバ１００は、指定された管理範囲４００のデータのマスタサーバとして処理を実行することとなる。これによって、大量のデータを並列的かつ高速に処理できる。
　なお、データストア１６０に格納されるデータの形式は、図３に示すものに限定されず、例えば、キーのハッシュ値、バリュー、及びシーケンス番号を対応づけた形式のデータであってもよい。
　図４は、本発明の実施例１における構成情報１７０の一例を示す説明図である。
　構成情報１７０は、各サーバ１００の配置されるデータのキーレンジに関する情報を格納する。具体的には、構成情報１７０は、サーバＩＤ４０１及びキーレンジ４０２を含む。
　サーバＩＤ４０１は、サーバ１００を一意に識別するための識別子を格納する。サーバＩＤ４０１には、例えば、サーバ１００の識別子、ＩＰアドレス、及びＭＡＣアドレス等が格納される。
　キーレンジ４０２は、キーレンジを特定するためのハッシュ値の範囲を格納する。キーレンジ４０２は、マスタ４０３及びスレーブ４０４を含む。マスタ４０３は、マスタデータのキーレンジを特定するハッシュ値を格納する。スレーブ４０４は、各サーバ１００のスレーブデータのキーレンジを特定するハッシュ値を格納する。
　なお、スレーブ４０４のカラムは、多重度の数だけ存在する。図４に示す例では、多重度が１の分散ＫＶＳであることを示す。
　図５は、本発明の実施例１における分散合意履歴情報１８０の一例を示す説明図である。
　分散合意履歴情報１８０は、複数の分散状態マシンイベント情報５００を含む。分散状態マシンイベント情報５００は、分散ＫＶＳにおけるイベントの情報を格納する。具体的には、分散状態マシンイベント情報５００は、シーケンス番号５０１、提案内容５０２を含む。
　シーケンス番号５０１は、イベントの実行順番を示す値を格納する。提案内容５０２は、イベントの具体的な内容を格納する。図５に示す提案内容５０２には、Ｋｅｙ５０４、Ｖａｌｕｅ５０５を含むＰｕｔ命令５０３が格納される。
　本実施例では、キーレンジ毎に分散合意履歴情報１８０が存在するものとする。
　図６は、本発明の実施例１における復旧情報１５４の一例を示す説明図である。
　復旧情報１５４は、複製シーケンス番号６０１、対象キーレンジ６０２、宛先情報６０３、及び合流シーケンス番号６０４を含む。
　複製シーケンス番号６０１は、複製シーケンス番号を格納する。対象キーレンジ６０２は、対象キーレンジを特定するハッシュ値を格納する。宛先情報６０３は、複製先のサーバ１００を特定するための情報を格納する。宛先情報６０３には、例えば、サーバ１００のＩＰアドレス、及びポート番号等が格納される。
　合流シーケンス番号６０４は、クラスタに新たなサーバ１００を追加するためのイベントの実行順番を示すシーケンス番号を格納する。以下の説明では、クラスタに新たなサーバ１００を追加するためのイベントを、メンバ合流イベントとも記載する。
　図７は、本発明の概要を説明するシーケンス図である。図７は、図１のステップＳ１０７の後に実行される処理を示す。
　サーバ１００－１は、サーバ１００－３に、複製対象の全てのデータを送信した後（ステップＳ１０７）、サーバ１００－２との間でメンバ合流イベントの分散合意を行う（ステップＳ１０８）。これによって、メンバ合流イベントのシーケンス番号が決定される。以下の説明では、メンバ合流イベントのシーケンス番号を合流シーケンス番号とも記載する。
　サーバ１００－１は、復旧情報１５４に、決定された合流シーケンス番号を格納する。メンバ合流イベントが実行されるまでは、サーバ１００－１が対象キーレンジのマスタサーバとして処理を行う。すなわち、合流シーケンス番号より小さいシーケンス番号が付与された更新命令は、サーバ１００－１によって処理される。
　図７に示す例では、合流シーケンス番号は「１５」に決定されたものとする。
　サーバ１００－１及びサーバ１００－２は、メンバ合流イベントの分散合意が行われた後、当該メンバ合流イベントの実行を開始する。しかし、この時点では、シーケンス番号が「１５」でないため、一定期間待ち状態となる。一定期間経過した後、シーケンス番号が合流シーケンス番号より小さい場合、サーバ１００－１及びサーバ１００－２は、ＮＯＯＰ命令の分散合意を行って、シーケンス番号の値を加算する。
　クライアント装置２００は、キー「Ａ」のデータを削除するための更新命令をサーバ１００－１に送信する（ステップＳ１０９）。この時点では、サーバ１００－３はクラスタに追加されていないため、更新命令はサーバ１００－１に送信される。
　サーバ１００－１は、更新命令を受信すると、サーバ１００－２との間で分散合意を行う（ステップＳ１１０）。図７に示す例では、受信した更新命令のシーケンス番号は「７」に決定される。
　サーバ１００－１は、更新命令にしたがって、マスタデータを更新する（ステップＳ１１１）。具体的には、サーバ１００－１は、キー「Ａ」のデータを削除する。このとき、マスタデータはデータ管理情報３００－６に示すようになる。なお、サーバ１００－２は、分散合意を実行することによって生成された分散状態マシンイベント情報５００に基づいて、同様にデータを更新する。
　サーバ１００－１は、サーバ１００－３に、データの削除を指示するデータを送信する（ステップＳ１１２）。サーバ１００－３は、データを削除する。このとき、サーバ１００－３が保持するマスタデータはデータ管理情報３００－７に示すようになる。
　サーバ１００－１は、シーケンス番号が「１５」になるまでステップＳ１１０からステップＳ１１２までの処理を実行する。
　所定のイベントのシーケンス番号が「１４」である場合、次にメンバ合流イベントが発生する。ここで、サーバ１００－１は、サーバ１００－３に、合流シーケンス番号を含む復旧完了データを送信し（ステップＳ１１３）、その後、復旧状態を解除する。
　また、サーバ１００－１及びサーバ１００－２は、メンバ合流イベントを実行する（ステップＳ１１４）。
　なお、この時点ではサーバ１００-３が新たなマスタサーバとなるように構成情報１７０が更新されている。具体的には、サーバ１００－１は、構成情報１７０にサーバ１００－３のエントリを追加し、サーバ１００－３をマスタサーバとして設定する。サーバ１００－２及びサーバ１００－３も同様の処理を実行する。さらに、サーバ１００－１は、サーバ１００－３及びクライアント装置２００に更新された構成情報１７０を送信する。
　当該処理によって、クラスタにサーバ１００－３が追加され、また、サーバ１００－３が対象キーレンジに含まれるデータに対する更新命令を処理する。
　その後、クライアント装置２００は、キーが「Ｄ」、バリューが「ＥＥＥ」であるデータを追加するための更新命令をサーバ１００－３に送信する（ステップＳ１１５）。
　サーバ１００－３は、サーバ１００－１及びサーバ１００－２との間で分散合意を行い（ステップＳ１１６）、受信した更新命令のシーケンス番号を「１６」に決定する。
　サーバ１００－３は、更新命令にしたがって、マスタデータを更新する（ステップＳ１１７）。具体的には、サーバ１００－３は、キーが「Ｄ」、バリューが「ＥＥＥ」、シーケンス番号が「１６」であるデータを格納する。サーバ１００－１及びサーバ１００－２は、それぞれ、分散合意の実行時に送信された分散状態マシンイベント情報５００に基づいて、同様にデータを更新する。このとき、マスタデータはデータ管理情報３００－８に示すようになる。
　図８は、本発明の実施例１における複製元のサーバ１００が実行する復旧処理を説明するフローチャートである。
　サーバ１００は、他のサーバ１００から復旧要求を受信する（ステップＳ２０１）。具体的には、復旧制御部１５３が、復旧要求を受信する。復旧要求には、対象キーレンジを特定するためのハッシュ値、及び複製先のサーバ１００の宛先情報が含まれる。
　サーバ１００は、受信した復旧要求に基づいて、復旧情報１５４を生成する（ステップＳ２０２）。具体的には、以下のような処理が実行される。
　復旧制御部１５３は、復旧要求に含まれる対象キーレンジのハッシュ値、及び宛先情報を取得する。復旧制御部１５３は、分散状態マシン制御部１５２に、複製シーケンス番号の取得要求を出力する。なお、取得要求には、対象キーレンジのハッシュ値が含まれる。
　分散状態マシン制御部１５２は、取得要求に含まれる対象キーレンジのハッシュ値に基づいて、対象キーレンジに対応する分散状態マシンイベント情報５００を検索する。さらに、分散状態マシン制御部１５２は、検索された分散状態マシンイベント情報５００のシーケンス番号５０１を参照し、最も大きいシーケンス番号を取得する。すなわち、最新のシーケンス番号が取得される。
　分散状態マシン制御部１５２は、取得されたシーケンス番号を複製シーケンス番号として復旧制御部１５３に出力する。
　復旧制御部１５３は、キーレンジのハッシュ値、宛先情報、及び複製シーケンス番号に基づいて、復旧情報１５４を生成する。その後、復旧制御部１５３は、復旧状態に遷移する。
　なお、この時点では、復旧情報１５４には合流シーケンス番号６０４が含まれていない。
　以上が、ステップＳ２０２の処理の説明である。
　次に、サーバ１００は、データ複製処理を実行する（ステップＳ２０３）。データ複製処理の詳細については、図９を用いて後述する。
　複製対象の全てのデータが送信されたと判定された場合、サーバ１００は、分散合意アルゴリズムに基づいて、メンバ合流イベントのシーケンス番号、すなわち、合流シーケンス番号を決定する（ステップＳ２０４）。具体的には、復旧制御部１５３が、分散状態マシン制御部１５２に、メンバ合流イベントの分散合意を指示する。具体的な処理については、図９を用いて後述する。
　次に、サーバ１００は、決定された合流シーケンス番号を復旧情報１５４に格納し（ステップＳ２０５）、処理を終了する。
　なお、合流シーケンス番号と複製シーケンス番号との間の差が大きい場合、頻繁に更新が行われないシステムでは、合流シーケンス番号が付与されたイベントの発生まで、複製先のサーバ１００をクラスタに追加することができない。この場合、分散状態マシン制御部１５２は、ステップＳ２０５の処理が実行された後、一定期間、メンバ合流イベントの発生を待つ。一定期間経過後のシーケンス番号が合流シーケンス番号より小さい場合、分散状態マシン制御部１５２は、所定の回数、ＮＯＯＰ命令の分散合意を行う。
　図９は、本発明の実施例１における複製元のサーバ１００が実行するデータ複製処理を説明するフローチャートである。データ複製処理は、復旧制御部１５３が主体となって実行される。
　復旧制御部１５３は、対象キーレンジに含まれるデータの排他ロックを取得する（ステップＳ３０１）。これによって、対象キーレンジに対するデータ更新処理が実行されない。そのため、データ複製処理、及びデータ更新処理が同時に発生することを避けることができる。
　なお、データ更新処理によって、対象キーレンジの排他ロックが取得されている場合、復旧制御部１５３は、排他ロックが解放されるまで待ち続ける。
　復旧制御部１５３は、対象キーレンジに含まれるデータの中から複製対象のデータを検索する（ステップＳ３０２）。
　具体的には、復旧制御部１５３は、データストア１６０のデータ管理情報３００、及び復旧情報１５４を参照し、対象キーレンジに含まれるデータの中から、複製シーケンス番号より古いシーケンス番号を含み、かつ、未送信のデータを検索する。本実施例では、復旧制御部１５３は、送信済みのデータのシーケンス番号より大きく、かつ、複製シーケンス番号以下のシーケンス番号を含むデータを検索する。
　復旧制御部１５３は、検索結果に基づいて、複製対象のデータが存在するか否かを判定する（ステップＳ３０３）。すなわち、複製対象の全てのデータを送信したか否かが判定される。
　複製対象のデータが存在すると判定された場合、復旧制御部１５３は、検索されたデータを読み出し、読み出されたデータを複製データとして複製先のサーバ１００に送信する（ステップＳ３０４）。具体的には、以下のような処理が実行される。
　復旧制御部１５３は、検索されたデータの中から送信するデータを選択する。選択方法としては、シーケンス番号が小さい順にデータを選択する方法、又は、キーの辞書の登録順にデータを選択する方法が考えられる。また、選択されるデータの数は、一つ、又は、二つ以上のいずれであってもよい。本実施例では、選択されるデータの数は一つであるものとする。
　なお、データの選択方法、及び選択されるデータの数に関する情報は、復旧制御部１５３に予め設定されていてもよいし、復旧要求に含まれてもよい。
　復旧制御部１５３は、選択されたデータをデータストア１６０から読み出し、複製先のサーバ１００の復旧制御部１５３に読み出されたデータを複製データとして送信する。
　以上がステップＳ３０４の処理の説明である。
　次に、復旧制御部１５３は、対象キーレンジの排他ロックを解放し（ステップＳ３０５）、ステップＳ３０１に戻る。
　ステップＳ３０３において、複製対象のデータが存在しないと判定された場合、復旧制御部１５３は、対象キーレンジの排他ロックを解放する（ステップＳ３０６）。その後、復旧制御部１５３は、分散状態マシン制御部１５２に、メンバ合流イベントの分散合意の実行を指示し（ステップＳ３０７）、処理を終了する。このとき、分散状態マシン制御部１５２は、以下のような処理を実行する。
　分散状態マシン制御部１５２は、当該指示を受け付けると、分散合意アルゴリズムにしたがって、他のサーバ１００の分散状態マシン制御部１５２と通信を行い、メンバ合流イベントの処理内容を配信し、合流シーケンス番号を決定する。
　各サーバ１００の分散状態マシン制御部１５２は、メンバ合流イベントの提案内容５０２を含む分散状態マシンイベント情報５００を分散合意履歴情報１８０に格納する。
　提案内容５０２には、メンバ合流イベントの処理内容として、構成情報１７０を更新するための情報、及び合流シーケンス番号を算出するための情報が含まれる。構成情報１７０を更新するための情報には、対象キーレンジ６０２及び宛先情報６０３に対応する情報が含まれる。また、合流シーケンス番号を算出するための情報には、条件式が含まれる。
　例えば、メンバ合流イベントに対応する分散状態マシンイベント情報５００に付与されるシーケンス番号５０１に所定の値を加算し、算出された値を合流シーケンス番号として算出する条件式が考えられる。また、当該シーケンス番号５０１に所定の値を乗算し、算出された値を合流シーケンス番号として算出する条件式が考えられる。なお、本発明は、合流シーケンス番号を算出する条件式に限定されない。
　各サーバ１００の分散状態マシン制御部１５２は、メンバ合流イベントの分散合意が行われた後、メンバ合流イベントの提案内容５０２に基づいて、合流シーケンス番号を算出する。また、各サーバ１００の分散状態マシン制御部１５２は、復旧制御部１５３に、算出された合流シーケンス番号を出力する。復旧制御部１５３は、入力された合流シーケンス番号を保持する。
　各サーバ１００の分散状態マシン制御部１５２は、一定期間待ち状態となる。各サーバ１００の分散状態マシン制御部１５２は、シーケンス番号が合流シーケンス番号に一致した場合、待ち状態であったメンバ合流イベントを実行する。このとき、分散状態マシン制御部１５２は、データ管理部１５１に、構成情報１７０の更新を指示する。当該指示には、対象キーレンジ６０２及び宛先情報６０３に対応する情報が含まれる。
　データ管理部１５１は、構成情報１７０を参照して、複製元のサーバ１００のエントリを検索する。
　データ管理部１５１は、検索されたエントリのマスタ４０３から対象キーレンジ６０２が除かれるようにハッシュ値を更新する。また、データ管理部１５１は、検索されたエントリのスレーブ４０４に対象キーレンジ６０２が含まれるようにハッシュ値を更新する。
　また、データ管理部１５１は、構成情報１７０に新たなエントリを追加し、宛先情報６０３に基づいて、サーバＩＤ４０１に複製先のサーバ１００の識別子を格納する。また、データ管理部１５１は、当該エントリのマスタ４０３に対象キーレンジ６０２のハッシュ値を格納する。さらに、データ管理部１５１は、当該エントリのスレーブ４０４に所定のハッシュ値を格納する。
　スレーブ４０４のハッシュ値の決定方法は様々考えられる。例えば、少なくとも一つのサーバ１００が、障害が発生したサーバのマスタ４０３、スレーブ４０４のハッシュ値を履歴情報として保持しておき、当該履歴情報に基づいてスレーブ４０４のハッシュ値を決定する方法が考えられる。また、他のサーバ１００のエントリのスレーブ４０４を参照し、分散ＫＶＳにおける多重度を満たすようにスレーブ４０４のハッシュ値を決定する方法が考えられる。なお、本発明は、スレーブ４０４に格納するハッシュ値の決定方法に限定されない。
　以上が、ステップＳ３０７の処理の説明である。
　図１０は、本発明の実施例１における複製元のサーバ１００が実行するデータ更新処理を説明するフローチャートである。データ更新処理は、データ管理部１５１が主体となって実行される。
　データ管理部１５１は、クライアント装置２００から更新命令を受信する（ステップＳ４０１）。
　データ管理部１５１は、更新命令のシーケンス番号を決定する（ステップＳ４０２）。具体的には、以下のような処理が実行される。
　データ管理部１５１は、分散状態マシン制御部１５２に、更新命令の処理内容とともに、当該更新命令の分散合意を行うように依頼する。
　分散状態マシン制御部１５２は、分散合意アルゴリズムにしたがって、他のサーバ１００の分散状態マシン制御部１５２と通信を行い、更新命令の複製を配信し、当該更新命令のシーケンス番号を決定する。分散状態マシン制御部１５２は、データ管理部１５１に、決定されたシーケンス番号を出力する。
　以上が、ステップＳ４０２の処理の説明である。
　次に、データ管理部１５１は、復旧状態であるか否かを判定する（ステップＳ４０３）。具体的には、以下のような処理が実行される。
　データ管理部１５１は、復旧制御部１５３に復旧情報１５４の取得要求を送信する。
　復旧情報１５４が存在する場合、復旧制御部１５３は、当該復旧情報１５４をデータ管理部１５１に出力する。復旧情報１５４が存在しない場合、復旧制御部１５３は、エラー通知を出力する。
　復旧情報１５４を取得した場合、データ管理部１５１は、復旧状態であると判定する。一方、エラー通知を取得した場合、データ管理部１５１は、復旧状態でないと判定する。
　以上が、ステップＳ４０３の処理の説明である。
　復旧状態でないと判定された場合、データ管理部１５１は、ステップＳ４０８に進む。
　復旧状態であると判定された場合、データ管理部１５１は、更新命令における処理対象のデータが対象キーレンジに含まれるか否かを判定する（ステップＳ４０４）。
　具体的には、データ管理部１５１は、更新命令に含まれるキーのハッシュ値を算出する。データ管理部１５１は、算出されたキーのハッシュ値、及び取得された復旧情報１５４に含まれる対象キーレンジ６０２に基づいて、算出されたキーのハッシュ値が対象キーレンジに含まれるか否かを判定する。算出されたキーのハッシュ値が対象キーレンジに含まれていると判定された場合、操作対象のデータが対象キーレンジに含まれると判定する。
　更新対象のデータが対象キーレンジに含まれないと判定された場合、データ管理部１５１は、ステップＳ４０８に進む。
　更新対象のデータが対象キーレンジに含まれると判定された場合、データ管理部１５１は、復旧状態におけるデータ更新処理を実行し（ステップＳ４０５）、その後、判定処理を実行する（ステップＳ４０６）。ここで、判定処理は、復旧処理が完了したか否かを判定するための処理である。
　復旧状態におけるデータ更新処理の詳細については、図１１を用いて後述する。判定処理の詳細については、図１２を用いて後述する。
　データ管理部１５１は、処理結果をクライアント装置２００に通知し（ステップＳ４０７）、処理を終了する。なお、他のサーバ１００（スレーブサーバ）も同様にステップＳ４０３からステップＳ４０８の処理を実行する。当該処理は、マスタサーバの処理とは独立した処理である。
　ステップＳ４０８では、データ管理部１５１は、通常のデータ更新処理を実行し、ステップＳ４０７に進む。
　通常のデータ更新処理では、データを追加する場合、データ管理部１５１は、排他ロックを取得し、データ管理情報３００にキー、バリュー、及びシーケンス番号を対応づけたデータを格納する。なお、通常のデータ更新処理は、公知の技術であるため詳細な説明を省略する。
　図１１は、本発明の実施例１における復旧状態におけるデータ更新処理を説明するフローチャートである。復旧状態におけるデータ更新処理は、データ管理部１５１が主体となって実行される。
　データ管理部１５１は、対象キーレンジに含まれるデータの排他ロックを取得する（ステップＳ５０１）。これによって、対象キーレンジに対するデータ複製処理が実行されない。そのため、データ複製処理、及びデータ更新処理が同時に発生することを避けることができる。
　なお、データ複製処理によって、対象キーレンジの排他ロックが取得されている場合、データ管理部１５１は、排他ロックが解放されるまで待ち続ける。
　データ管理部１５１は、更新命令に基づいて、データを更新する（ステップＳ５０２）。例えば、更新命令がデータの上書き処理に対応する命令である場合、データ管理部１５１は、更新対象のデータを検索し、検索されたデータのバリュー、及びシーケンス番号に所定の値を上書きする。なお、データの更新方法は公知の技術であるため詳細な説明を省略する。
　データ管理部１５１は、復旧制御部１５３に、複製データの送信を指示する（ステップＳ５０３）。当該指示には、更新されたデータが含まれる。復旧制御部１５３は、当該指示を受け付けると、復旧情報１５４を参照し、複製先のサーバ１００の復旧制御部１５３に更新されたデータを複製データとして送信する。
　なお、データ管理部１５１が、複製先のサーバ１００の復旧制御部１５３に、更新されたデータを複製データとして送信してもよい。この場合、データ管理部１５１は、復旧制御部１５３から宛先情報を取得する。
　データ管理部１５１は、排他ロックを解放し（ステップＳ５０４）、処理を終了する。このとき、データ管理部１５１は、復旧制御部１５３に判定処理の実行を指示する。
　なお、更新命令に含まれるコマンドによっては、データが更新されない場合も存在する。この場合、データ管理部１５１は、ステップＳ５０２及びステップＳ５０３の処理を省略してもよい。
　ここで、排他ロック制御について説明する。
　データ複製処理、及び、復旧状態におけるデータ更新処理では、それぞれ、排他ロックが取得される。これは、並列に実行される二つの処理によって送信される複製データの順番を制御するためである。すなわち、複製元のサーバ１００は、排他ロックを取得することによって、二つの処理が直列的に実行されるように制御する。これによって、分散ＫＶＳにおけるデータの整合性を保つことができる。
　一方、排他ロックが取得されない場合、通信の遅延等によって、複製元のサーバ１００が、データの不整合が発生する順番で複製データを受信する可能性がある。例えば、データの上書き、データの削除の順に処理が実行された場合、通信の遅延によって、複製先のサーバ１００がデータの削除、データの上書きの順に複製データを受信する可能性がある。この場合、データの不整合が生じる。
　そのため、実施例１では、複製元のサーバ１００が、前述したようなデータの不整合を回避するために、排他ロックを用いて二つの処理を直列的に実行することによって、複製データの送信順番を制御する。
　なお、本実施例では、排他ロックを用いて二つの処理の実行順番を制御したが、本発明はこれに限定されない。キューイング等、二つの処理を直列的に実行する方法であればどのような方法を用いてもよい。
　図１２は、本発明の実施例１における判定処理を説明するフローチャートである。判定処理は、復旧制御部１５３が主体になって実行される。
　復旧制御部１５３は、データ管理部１５１から判定処理の実行指示を受け付けると処理を開始する。まず、復旧制御部１５３は、復旧情報１５４に合流シーケンス番号が格納されているか否かを判定する（ステップＳ６０１）。
　復旧情報１５４に合流シーケンス番号が格納されていないと判定された場合、復旧制御部１５３は、処理を終了する。
　復旧情報１５４に合流シーケンス番号が格納されていると判定された場合、復旧制御部１５３は、メンバ合流イベントが発生するか否かを判定する（ステップＳ６０２）。具体的には、以下のような処理が実行される。
　復旧制御部１５３は、復旧情報１５４から合流シーケンス番号６０４を取得する。復旧制御部１５３は、合流シーケンス番号６０４から、判定処理の前に実行されたデータ更新処理（ステップＳ４０５）における更新命令に付与されたシーケンス番号５０１を減算する。なお、当該シーケンス番号５０１は、復旧状態におけるデータ更新処理において実行された更新命令に対応する提案内容５０２を含む分散状態マシンイベント情報５００に付与されたものである。
　復旧制御部１５３は、算出された値が「１」であるか否かを判定する。算出された値が「１」である場合、復旧制御部１５３はメンバ合流イベントが発生すると判定する。
　以上が、ステップＳ６０２の処理の説明である。
　メンバ合流イベントが発生しないと判定された場合、復旧制御部１５３は、処理を終了する。
　メンバ合流イベントが発生すると判定された場合、復旧制御部１５３は、複製先のサーバ１００の復旧制御部１５３に復旧完了データを送信する（ステップＳ６０３）。復旧完了データには、合流シーケンス番号が含まれる。
　復旧制御部１５３は、復旧情報１５４を初期化し（ステップＳ６０４）、処理を終了する。具体的には、復旧制御部１５３は、復旧情報１５４に含まれる全ての情報を削除する。これによって、復旧状態が解除される。
　図１３は、本発明の実施例１における複製先のサーバ１００が実行する復旧処理を説明するフローチャートである。
　サーバ１００は、復旧処理に必要な情報を設定し（ステップＳ７０１）、設定された情報に基づいてサーバ１００に復旧要求を送信する（ステップＳ７０２）。具体的には、復旧制御部１５３が、ユーザから設定された情報に基づいて、サーバ１００に復旧要求を送信する。
　本実施例では、複製元のサーバ１００及び複製先のサーバを特定するための情報が設定される。
　例えば、ユーザは複製先のサーバ１００の宛先情報及び対象キーレンジを設定する。この場合、設定された宛先情報に基づいて、複製元のサーバ１００に復旧要求が送信される。
　また、ユーザは対象キーレンジを設定する。この場合、複製先のサーバ１００は、他のサーバ１００から構成情報１７０を取得し、取得された構成情報１７０を参照し、対象キーレンジのマスタサーバを検索する。複製先のサーバ１００は、検索されたマスタサーバに対応するサーバ１００に、復旧要求を送信する。
　サーバ１００は、他のサーバ１００からデータを受信すると（ステップＳ７０３）、受信したデータが複製データであるか否かを判定する（ステップＳ７０４）。具体的には、復旧制御部１５３が、受信したデータが複製データであるか否かを判定する。
　受信したデータが複製データであると判定された場合、サーバ１００は、受信したデータをデータストア１６０に書き込み（ステップＳ７０５）、ステップＳ７０３に戻る。具体的には、復旧制御部１５３がデータストア１６０に受信したデータを書き込む。なお、復旧制御部１５３はデータ管理部１５１にデータストア１６０へのデータの書き込みを依頼してもよい。
　ステップＳ７０４において、受信したデータが複製データでない、すなわち、復旧完了データであると判定された場合、サーバ１００は、合流シーケンス番号を登録し（ステップＳ７０６）、処理を終了する。具体的には、以下のような処理が実行される。
　復旧制御部１５３が、復旧完了データに含まれる合流シーケンス番号を取得し、分散状態マシン制御部１５２に、取得された合流シーケンス番号を含む登録要求を出力する。
　分散状態マシン制御部１５２は、一時的に合流シーケンス番号を保持する。なお、分散状態マシン制御部１５２は、メンバ合流イベントが発生した後、当該合流シーケンス番号を削除してもよい。
　なお、サーバ１００は、複製元のサーバ１００から更新された構成情報１７０を取得する。本発明は、更新された構成情報１７０の取得方法に限定されない、例えば、以下のような取得方法が考えられる。一つの取得方法としては、複製元のサーバ１００が、複製先のサーバ１００に、一つの複製データとして更新された構成情報１７０を送信する。他の取得方法としては、複製元のサーバ１００が、更新された構成情報１７０が含まれる復旧完了データを送信する。
　本実施例では、復旧要求には対象キーレンジのハッシュ値が含まれるが、必ずしも必要ではない。例えば、クラスタに含まれる全てのサーバ１００が同一のデータを保持する場合、ステップＳ７０１において、ユーザは対象キーレンジを指定する必要はない。この場合、サーバ１００に格納される全データが複製処理の対象となる。
　実施例１によれば、データ更新処理及びデータ複製処理が並列に実行されている場合において、複製元のサーバ及び複製先のサーバのデータの整合性を保った復旧が可能となる。
　また、復旧処理においてスナップショットを取得する必要がないため複製元のサーバのメモリ使用量を低減することができる。また、復旧処理では、一つ又は複数の複製データが送信されることによってネットワーク通信量を低減することができる。また、更新されたデータが優先的に送信されるため、同一キーのデータを複数回送信する必要がない。そのため、復旧処理におけるネットワーク通信量を低減することができる。
　また、クライアント装置２００のアプリケーション２５１を停止させることなく復旧することができる。
　（実施例１の変形例）
　ステップＳ７０１では、データ複製処理を実行するサーバ１００を選択することもできる。具体的には、以下のような処理が実行される。
　複製先のサーバ１００は、ユーザから対象キーレンジを受け付けると、クラスタに含まれるサーバ１００から構成情報１７０を取得する。
　複製先のサーバ１００は、構成情報１７０を参照し、対象キーレンジのマスタサーバ及びスレーブサーバの情報をユーザに対して表示する。ユーザは、表示された情報に基づいて、データ複製処理を実行するサーバ１００を選択する。
　マスタサーバがデータ複製処理を実行するサーバ１００として選択された場合、実施例１と同一の処理となる。
　スレーブサーバがデータ複製処理を実行するサーバ１００として選択された場合、復旧制御部１５３は、スレーブサーバの識別情報及びデータ複製処理の実行指示を復旧要求に含める。さらに、復旧制御部１５３は、当該復旧要求をスレーブサーバに送信する。
　スレーブサーバは、図８から図１２に示す処理を実行する。
　これによって、マスタサーバの処理負荷を低減することができる。
　実施例１では、複製元のサーバ１００は、データ複製処理及びデータ更新処理の開始時に排他ロックを取得することによって、複製先のサーバ１００の複製データの受信順番を制御していた。これによって、前述したようなデータの不整合が回避される。
　実施例２では、排他ロック制御を用いる代わりに、複製先のサーバ１００が二つの処理の実行順番を考慮して複製データをデータストア１６０に書き込む。
　以下、実施例１との差異を中心に実施例２について説明する。
　実施例２のシステム構成では、サーバ１００が一時的にデータを蓄積するためのバッファを有する。その他の構成は実施例１と同一であるため説明を省略する。また、実施例２では、データストア１６０に格納される情報が異なる。その他の情報は実施例１と同一である。
　図１４は、本発明の実施例１におけるデータストア１６０に格納されるデータの形式を示す説明図である。
　実施例２のデータ管理情報３００は、新たに削除フラグ３０４を含む。
　削除フラグ３０４は、データの削除を示す更新処理であるか否かを示す情報を格納する。本実施例では、データの削除を示す更新処理の場合「Ｔｒｕｅ」が格納され、データの削除以外の更新処理の場合「Ｆａｌｓｅ」が格納される。
　図１５は、本発明の実施例２における複製元のサーバ１００が実行するデータ複製処理を説明するフローチャートである。
　実施例２では、ステップＳ３０１、ステップＳ３０５及びステップＳ３０６の処理が省略される。その他の処理は実施例１と同一の処理である。
　図１６は、本発明の実施例２における復旧状態におけるデータ更新処理を説明するフローチャートである。
　実施例２では、ステップＳ５０１及びステップＳ５０４の処理が省略される。
　更新命令がデータの削除を指示する命令の場合、ステップＳ５０２及びステップＳ５０３の処理が異なる。データの追加、及びデータの上書きを指示する更新命令の場合の処理は実施例１の処理と同一である。
　ステップＳ５０２では、更新命令がデータの削除を指示する命令であった場合、データ管理部１５１は、更新命令に基づいて、削除対象のデータを検索する。データ管理部１５１は、検索されたデータの削除フラグ３０４を「Ｔｒｕｅ」に変更する。
　ステップＳ５０３では、データ管理部１５１は、復旧制御部１５３に、複製先のサーバ１００への複製データの送信を指示する。当該送信には、削除フラグ３０４が「Ｔｒｕｅ」である複製データが含まれる。その後、データ管理部１５１は、削除フラグ３０４が「Ｔｒｕｅ」のデータを削除する。
　復旧制御部１５３は、当該指示を受け付けると、復旧情報１５４を参照し、複製先のサーバ１００の復旧制御部１５３に複製データを送信する。
　図１７は、本発明の実施例２における複製先のサーバ１００が実行する復旧処理を説明するフローチャートである。
　ステップＳ７０１からステップＳ７０４の処理は、実施例１と同一の処理である。
　ステップＳ７０４において、受信したデータが複製データであると判定された場合、サーバ１００は、受信した複製データをバッファに一時的に蓄積する（ステップＳ８０１）。具体的には、復旧制御部１５３が、バッファに受信した複製データを格納する。
　サーバ１００は、バッファに蓄積されたデータをデータストア１６０に書き込むか否かを判定する（ステップＳ８０２）。
　例えば、バッファに蓄積されたデータの容量が所定のしきい値以上である場合に、復旧制御部１５３は、当該データをデータストア１６０に書き込む。また、復旧制御部１５３は、タイマを備え、一定時間経過した場合に、当該データをデータストア１６０に書き込む。
　バッファに蓄積された複製データをデータストア１６０に書き込まれないと判定された場合、サーバ１００は、ステップＳ７０３に戻る。
　バッファに蓄積された複製データをデータストア１６０に書き込むと判定された場合、サーバ１００は、バッファに蓄積された複製データをデータストア１６０に書き込み（ステップＳ８０３）、その後、ステップＳ７０３に戻る。具体的には、以下のような処理が実行される。
　復旧制御部１５３は、バッファに蓄積された複製データに含まれるシーケンス番号を参照し、最も小さいシーケンス番号を含む複製データを選択する。復旧制御部１５３は、選択された複製データのキーを参照し、バッファ及びデータストア１６０の中から当該キーと同一のキーを含む複製データを検索する。
　復旧制御部１５３は、検索された複製データの中から最も大きいシーケンス番号を含む複製データを選択し、選択された複製データをデータストア１６０に書き込む。また、復旧制御部１５３は、バッファから検索された複製データを削除する。
　なお、削除フラグ３０４が「Ｔｒｕｅ」の複製データも一時的にデータストア１６０に格納される。
　復旧制御部１５３は、バッファにデータが蓄積されているか否かを判定する。バッファにデータが蓄積されていない場合、復旧制御部１５３は処理を終了する。一方、バッファにデータが蓄積されている場合、復旧制御部１５３は、同様の処理を繰り返し実行する。
　なお、前述した処理では、シーケンス番号の順番に基づいて処理が実行されていたが、キーの辞書の登録順に処理が実行されてもよい。
　以上がステップＳ８０３の処理の説明である。
　ステップＳ７０４において、受信したデータが復旧完了データであると判定された場合、サーバ１００は、バッファに一時的に蓄積されたデータをデータストア１６０に書き込み、その後、削除フラグ３０４に基づいてデータストア１６０からデータを削除する（ステップＳ８０４）。具体的には、以下のような処理が実行される。
　まず、復旧制御部１５３は、バッファに蓄積されたデータをデータストア１６０に書き込む。データの書込方法は、ステップＳ８０３と同一の方法を用いる。その後、復旧制御部１５３は、データ管理情報３００の削除フラグ３０４を参照し、削除フラグ３０４に「Ｔｒｕｅ」が格納されるデータを検索する。復旧制御部１５３は、検索されたデータをデータ管理情報３００から削除する。
　以上がステップＳ８０４の処理の説明である。
　ステップＳ７０６の処理は、実施例１の処理と同一であるため説明を省略する。
　実施例２によれば、複製元のサーバ１００は排他ロックを取得する必要がないため、排他ロック制御に伴う処理のオーバーヘッドを削減することができる。
　以上説明したように、本発明によれば、一つ又は所定数の複製データが送信されるため計算機システムのネットワークの通信量を低減することができる。また、複製元のサーバ１００は、復旧処理時にスナップショットを取得する必要がないためメモリの使用量を低減することができる。また、更新されたデータが優先的に送信することによって同一キーのデータの送信を抑制できるため、ネットワークの通信量を低減することができる。
　また、複製データの書き込み順を制御することによって、データの整合性を保つことができる。更新処理を停止することなく、複製先のサーバ１００にデータを書き込むため、システムを停止させる必要がない。合流シーケンス番号に基づいて複製先のサーバ１００がクラスタに追加されるため、システム全体の整合性を保ち、かつ、明示的にシステムの構成を変更することができる。
　なお、本実施例で例示した種々のソフトウェアは、電磁的、電子的及び光学式等の種々の記録媒体（例えば、非一時的な記憶媒体）に格納可能であり、インターネット等の通信網を通じて、コンピュータにダウンロード可能である。
　さらに、本実施例では、ソフトウェアによる制御を用いた例について説明したが、その一部をハードウェアによって実現することも可能である。
　以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更及び同等の構成を含むものである。

Claims (14)

  1. 　ネットワークを介して複数の計算機が接続され、前記複数の計算機の各々が有する記憶領域から構成されたデータベースを用いて業務を実行する計算機システムであって、
    　前記データベースに格納されるデータは、前記データの識別情報、前記データの値、及び前記データベースにおけるイベントの実行順番であるシーケンス番号を含み、
    　前記複数の計算機の各々には、前記データの識別情報に対して分散配置アルゴリズムを適用して決定された管理範囲毎に当該データが分散して配置され、
    　前記複数の計算機の各々は、
    　配置されたデータを管理するデータ管理部と、
    　配置されたデータに対する操作の前記シーケンス番号を決定するデータ制御部と、
    　新たに追加された計算機に、所定の管理範囲に含まれるデータの複製データを送信する復旧制御部と、を有し、
    　前記複数の計算機は、復旧要求を送信する第１の計算機、及び前記復旧要求を受信する第２の計算機を含み、
    　前記第２の計算機は、
    　前記第１の計算機から復旧要求を受信し、前記第２の計算機の状態を復旧状態に遷移させ、前記シーケンス番号に基づいて前記データベースからデータを一つ以上読み出し、第１の複製データとして前記第１の計算機に送信する複製処理と、
    　前記復旧状態において前記データの更新命令を受信した場合、前記更新命令の前記シーケンス番号を決定し、前記更新命令に基づいて所定のデータを更新し、第２の複製データとして送信する更新処理と、を実行し、
    　前記第１の計算機又は前記第２の計算機の少なくともいずれか一方が、前記第１の計算機における前記第１の複製データ及び前記第２の複製データの書き込み順番を制御し、
    　前記第１の計算機は、前記書き込み順番に基づいて、前記第１の複製データ及び前記第２の複製データを前記データベースを構成する記憶領域に書き込む書込処理を実行することを特徴とする計算機システム。
  2. 　請求項１に記載の計算機システムであって、
    　前記複数の計算機の各々は、前記シーケンス番号、及び前記データベースにおけるイベントの内容が対応づけられた履歴情報を保持し、
    　前記復旧要求は、処理対象の前記管理範囲を示す情報を含み、
    　前記複製処理では、
    　前記第２の計算機の復旧制御部が、
    　前記復旧要求を受信した場合、前記履歴情報に基づいて、最新のシーケンス番号を複製シーケンス番号として保持し、
    　前記処理対象の管理範囲の排他ロックを取得し、
    　前記処理対象の管理範囲に含まれるデータの中から、未送信のデータ、かつ、前記複製シーケンス番号より古い前記シーケンス番号を含むデータを一つ以上読み出して、前記第１の複製データとして前記第１の計算機の復旧制御部に送信し、
    　前記取得された排他ロックを解放し、
    　前記更新処理では、
    　前記第２の計算機のデータ管理部が、
    　前記処理対象の管理範囲の前記排他ロックを取得し、
    　前記更新命令に基づいて前記所定のデータを更新し、前記第１の複製データの送信指示を前記第２の計算機の復旧制御部に出力し、
    　前記取得された排他ロックを解放し、
    　前記第２の計算機の復旧制御部が、前記送信指示に基づいて前記第１の複製データを前記第１の計算機の復旧制御部に送信し、
    　前記書込処理では、前記第１の計算機の復旧制御部が、受信した順番にしたがって、前記第１の複製データ及び前記第２の複製データを前記データベースを構成する記憶領域に書き込むことを特徴とする計算機システム。
  3. 　請求項１に記載の計算機システムであって、
    　前記複数の計算機の各々は、
    　前記シーケンス番号、及び前記データベースにおけるイベントの内容が対応づけられた履歴情報を保持し、
    　前記第１の複製データ及び前記第２の複製データを一時的に格納する作業記憶領域を有し、
    　前記復旧要求は、処理対象の前記管理範囲を示す情報を含み、
    　前記複製処理では、
    　前記第２の計算機の復旧制御部が、
    　前記復旧要求を受信した場合、前記履歴情報に基づいて、最新のシーケンス番号を複製シーケンス番号として保持し、
    　前記処理対象の管理範囲に含まれるデータの中から、未送信のデータ、かつ、前記複製シーケンス番号より古い前記シーケンス番号を含むデータを一つ以上読み出して、前記第１の複製データとして前記第１の計算機の復旧制御部に送信し、
    　前記更新処理では、
    　前記第２の計算機のデータ管理部が、前記更新命令に基づいて前記所定のデータを更新し、前記第１の複製データの送信指示を前記第２の計算機の復旧制御部に出力し、
    　前記第２の計算機の復旧制御部が、前記送信指示に基づいて前記第１の複製データを前記第１の計算機の復旧制御部に送信し、
    　前記書込処理では、
    　前記第１の計算機の復旧制御部が、
    　前記受信した第１の複製データ及び前記受信した第２の複製データを前記作業記憶領域に格納し、
    　前記データベース及び前記作業記憶領域の中から、同一の前記データの識別情報を含む、前記第１の複製データ及び前記第２の複製データを検索し、
    　前記検索された第１の複製データに含まれる前記シーケンス番号、及び前記検索された第２の複製データに含まれる前記シーケンス番号を参照して、最新の前記シーケンス番号を含む複製データを選択し、
    　前記選択された複製データを前記データベースを構成する記憶領域に書き込むことを特徴とする計算機システム。
  4. 　請求項３に記載の計算機システムであって、
    　前記データベースに格納されるデータは、さらに、削除対象のデータであるか否かを示す削除フラグを含み、
    　前記更新処理では、前記第２の計算機のデータ管理部が、前記更新命令がデータの削除命令である場合に、前記削除フラグが付与された削除対象のデータを前記第１の複製データとして前記第１の計算機の復旧制御部に送信し、
    　前記書込処理では、前記第１の計算機のデータ管理部が、前記データベースに書き込まれたデータのうち、前記削除フラグが付与されたデータを、前記データベースを構成する記憶領域から削除すること特徴とする計算機システム。
  5. 　請求項２又は請求項３のいずれか一項に記載の計算機システムであって、
    　前記複数の計算機の各々は、前記複数の計算機の各々がマスタとして管理する前記管理範囲、及びスレーブとして管理する前記管理範囲を示す構成情報を保持し、
    　前記複製処理では、
    　前記第２の計算機の復旧制御部が、前記複製シーケンス番号を含む前記第１の複製データが送信された後、前記複数の計算機に前記第１の計算機を追加するための合流イベントの前記シーケンス番号である合流シーケンス番号の決定を前記第２の計算機のデータ制御部に指示し、
    　前記第２の計算機のデータ制御部が、
    　分散合意アルゴリズムに基づいて、前記複数の計算機の各々の前記データ制御部と通信することによって前記合流シーケンス番号を決定し、
    　前記決定された合流シーケンス番号、及び、前記合流イベントの内容が対応づけられた前記履歴情報を保持し、
    　前記決定された合流シーケンス番号を前記第２の計算機の復旧制御部に出力し、
    　前記更新処理では、
    　前記第２の計算機のデータ管理部が、
    　前記第１の複製データが送信された後に、当該第１の複製データに含まれる前記シーケンス番号と、前記合流シーケンス番号とを比較して、前記合流イベントが発生するか否かを判定し、
    　前記合流イベントが発生すると判定された場合、前記第１の計算機の復旧制御部に、前記合流シーケンス番号を送信し、
    　前記合流イベントでは、前記第１の計算機が前記処理対象の管理範囲のマスタとなるように前記構成情報が更新されることを特徴とする計算機システム。
  6. 　請求項５に記載の計算機システムであって、
    　前記第１の計算機は、
    　前記処理対象の管理範囲をマスタとして管理する計算機、又は、前記処理対象の管理範囲をスレーブとして管理する計算機の少なくともいずれか一方の計算機を前記第２の計算機として選択し、
    　前記選択された第２の計算機に前記復旧要求を送信することを特徴とする計算機システム。
  7. 　ネットワークを介して複数の計算機が接続され、前記複数の計算機の各々が有する記憶領域から構成されたデータベースを用いて業務を実行する計算機システムにおける計算機システム管理方法であって、
    　前記複数の計算機の各々は、プロセッサと、前記プロセッサに接続されるメモリと、前記プロセッサと接続され、前記ネットワークを介して他の前記計算機と通信するためのネットワークインタフェースとを有し、
    　前記データベースに格納されるデータは、前記データの識別情報、前記データの値、及び前記データベースにおけるイベントの実行順番であるシーケンス番号を含み、
    　前記複数の計算機の各々には、前記データの識別情報に対して分散配置アルゴリズムを適用することによって決定された管理範囲毎に当該データが分散して配置され、
    　前記複数の計算機の各々は、
    　配置されたデータを管理するデータ管理部と、
    　配置されたデータに対する操作の前記シーケンス番号を決定するデータ制御部と、
    　新たに追加された計算機に、所定の管理範囲に含まれるデータの複製データを送信する復旧制御部と、を有し、
    　前記複数の計算機は、復旧要求を送信する第１の計算機、及び前記復旧要求を受信する第２の計算機を含み、
    　前記方法は、
    　前記第２の計算機が、前記第１の計算機から復旧要求を受信し、前記第２の計算機の状態を復旧状態に遷移させ、前記シーケンス番号に基づいて前記データベースからデータを一つ以上読み出し、第１の複製データとして前記第１の計算機に送信する複製処理を実行するステップと、
    　前記第２の計算機が、前記復旧状態において前記データの更新命令を受信した場合、前記更新命令の前記シーケンス番号を決定し、前記更新命令に基づいて所定のデータを更新し、第２の複製データとして送信する更新処理を実行するステップと、
    　前記第１の計算機又は前記第２の計算機の少なくともいずれか一方が、前記第１の計算機における前記第１の複製データ及び前記第２の複製データの書き込み順番を制御するステップと、
    　前記第１の計算機が、前記書き込み順番に基づいて、前記第１の複製データ及び前記第２の複製データを前記データベースを構成する記憶領域に書き込む書込処理を実行するステップと、を含むことを特徴とする計算機システム管理方法。
  8. 　請求項７に記載の計算機システム管理方法であって、
    　前記複数の計算機の各々は、前記シーケンス番号、及び前記データベースにおけるイベントの内容が対応づけられた履歴情報を保持し、
    　前記復旧要求は、処理対象の前記管理範囲を示す情報を含み、
    　前記複製処理は、
    　前記第２の計算機の復旧制御部が、
    　前記復旧要求を受信した場合、前記履歴情報に基づいて、最新のシーケンス番号を複製シーケンス番号として保持するステップと、
    　前記処理対象の管理範囲の排他ロックを取得するステップと、
    　前記処理対象の管理範囲に含まれるデータの中から、未送信のデータ、かつ、前記複製シーケンス番号より古い前記シーケンス番号を含むデータを一つ以上読み出して、前記第１の複製データとして前記第１の計算機の復旧制御部に送信するステップと、
    　前記取得された排他ロックを解放するステップと、を含み、
    　前記更新処理は、
    　前記第２の計算機のデータ管理部が、
    　前記処理対象の管理範囲の前記排他ロックを取得するステップと、
    　前記更新命令に基づいて前記所定のデータを更新し、前記第１の複製データの送信指示を前記第２の計算機の復旧制御部に出力するステップと、
    　前記取得された排他ロックを解放するステップと、
    　前記第２の計算機の復旧制御部が、前記送信指示に基づいて前記第１の複製データを前記第１の計算機の復旧制御部に送信するステップと、を含み、
    　前記書込処理では、前記第１の計算機の復旧制御部が、受信した順番にしたがって、前記第１の複製データ及び前記第２の複製データを前記データベースを構成する記憶領域に書き込むことを特徴とする計算機システム管理方法。
  9. 　請求項７に記載の計算機システム管理方法であって、
    　前記複数の計算機の各々は、
    　前記シーケンス番号、及び前記データベースにおけるイベントの内容が対応づけられた履歴情報を保持し、
    　前記第１の複製データ及び前記第２の複製データを一時的に格納する作業記憶領域を有し、
    　前記復旧要求は、処理対象の前記管理範囲を示す情報を含み、
    　前記複製処理は、
    　前記第２の計算機の復旧制御部が、
    　前記復旧要求を受信した場合、前記履歴情報に基づいて、最新のシーケンス番号を複製シーケンス番号として保持するステップと、
    　前記処理対象の管理範囲に含まれるデータの中から、未送信のデータ、かつ、前記複製シーケンス番号より古い前記シーケンス番号を含むデータを一つ以上読み出して、前記第１の複製データとして前記第１の計算機の復旧制御部に送信するステップと、を含み、
    　前記更新処理は、
    　前記第２の計算機のデータ管理部が、前記更新命令に基づいて前記所定のデータを更新し、前記第１の複製データの送信指示を前記第２の計算機の復旧制御部に出力するステップと、
    　前記第２の計算機の復旧制御部が、前記送信指示に基づいて前記第１の複製データを前記第１の計算機の復旧制御部に送信するステップと、を含み、
    　前記書込処理は、
    　前記第１の計算機の復旧制御部が、
    　前記受信した第１の複製データ及び前記受信した第２の複製データを前記作業記憶領域に格納するステップと、
    　前記データベース及び前記作業記憶領域の中から、同一の前記データの識別情報を含む、前記第１の複製データ及び前記第２の複製データを検索するステップと、
    　前記検索された第１の複製データに含まれる前記シーケンス番号、及び前記検索された第２の複製データに含まれる前記シーケンス番号を参照して、最新の前記シーケンス番号を含む複製データを選択するステップと、
    　前記選択された複製データを前記データベースを構成する記憶領域に書き込むステップと、を含むことを特徴とする計算機システム管理方法。
  10. 　請求項９に記載の計算機システム管理方法であって、
    　前記データベースに格納されるデータは、さらに、削除対象のデータであるか否かを示す削除フラグを含み、
    　前記更新処理は、前記第２の計算機のデータ管理部が、前記更新命令がデータの削除命令である場合に、前記削除フラグが付与された削除対象のデータを前記第１の複製データとして前記第１の計算機の復旧制御部に送信するステップを含み、
    　前記書込処理は、前記第１の計算機のデータ管理部が、前記データベースに書き込まれたデータのうち、前記削除フラグが付与されたデータを、前記データベースを構成する記憶領域から削除するステップを含むこと特徴とする計算機システム管理方法。
  11. 　請求項８又は請求項９のいずれか一項に記載の計算機システム管理方法であって、
    　前記複数の計算機の各々は、前記複数の計算機の各々がマスタとして管理する前記管理範囲、及びスレーブとして管理する前記管理範囲を示す構成情報を保持し、
    　前記複製処理は、
    　前記第２の計算機の復旧制御部が、前記複製シーケンス番号を含む前記第１の複製データが送信された後、前記複数の計算機に前記第１の計算機を追加するための合流イベントの前記シーケンス番号である合流シーケンス番号の決定を前記第２の計算機のデータ制御部に指示するステップと、
    　前記第２の計算機のデータ制御部が、
    　分散合意アルゴリズムに基づいて、前記複数の計算機の各々の前記データ制御部と通信することによって前記合流シーケンス番号を決定するステップと、
    　前記決定された合流シーケンス番号、及び、前記合流イベントの内容が対応づけられた前記履歴情報を保持するステップと、
    　前記決定された合流シーケンス番号を前記第２の計算機の復旧制御部に出力するステップと、を含み、
    　前記更新処理は、
    　前記第２の計算機のデータ管理部が、
    　前記第１の複製データが送信された後に、当該第１の複製データに含まれる前記シーケンス番号と、前記合流シーケンス番号とを比較して、前記合流イベントが発生するか否かを判定するステップと、
    　前記合流イベントが発生すると判定された場合、前記第１の計算機の復旧制御部に、前記合流シーケンス番号を送信するステップと、を含み、
    　前記合流イベントでは、前記第１の計算機が前記処理対象の管理範囲のマスタとなるように前記構成情報が更新されることを特徴とする計算機システム管理方法。
  12. 　請求項１１に記載の計算機システム管理方法であって、
    　前記方法は、
    　前記第１の計算機が、
    　前記処理対象の管理範囲をマスタとして管理する計算機、又は、前記処理対象の管理範囲をスレーブとして管理する計算機の少なくともいずれか一方の計算機を前記第２の計算機として選択するステップと、
    　前記選択された第２の計算機に前記復旧要求を送信するステップと、を含むことを特徴とする計算機システム管理方法。
  13. 　ネットワークを介して複数の計算機が接続され、前記複数の計算機の各々が有する記憶領域から構成されたデータベースを用いて業務を実行する計算機システムに含まれる前記計算機が実行するプログラムであって、
    　前記複数の計算機の各々は、プロセッサと、前記プロセッサに接続されるメモリと、前記プロセッサと接続され、前記ネットワークを介して他の前記計算機と通信するためのネットワークインタフェースとを有し、
    　前記データベースに格納されるデータは、前記データの識別情報、前記データの値、及び前記データベースにおけるイベントの実行順番であるシーケンス番号を含み、
    　前記複数の計算機の各々には、前記データの識別情報に対して分散配置アルゴリズムを適用することによって決定された管理範囲毎に当該データが分散して配置され、
    　前記複数の計算機の各々は、
    　配置されたデータを管理するデータ管理部と、
    　配置されたデータに対する操作の前記シーケンス番号を決定するデータ制御部と、
    　新たに追加された計算機に、所定の管理範囲に含まれるデータの複製データを送信する復旧制御部と、を有し、
    　前記プログラムは、
    　他の前記計算機から復旧要求を受信し、前記計算機の状態を復旧状態に遷移し、前記シーケンス番号に基づいて前記データベースに格納される前記データを一つ以上読み出し、第１の複製データとして前記他の計算機に送信する複製処理を実行する手順と、
    　前記復旧状態において前記データの更新命令を受信した場合、前記更新命令の前記シーケンス番号を決定し、前記更新命令に基づいて所定のデータを更新し、第２の複製データとして送信する更新処理を実行する手順と、
    　前記他の計算機における前記第１の複製データ及び前記第２の複製データの書き込み順番を制御する手順と、を前記計算機に実行させることを特徴とするプログラム。
  14. 　請求項１３に記載のプログラムであって、
    　前記複数の計算機の各々は、前記シーケンス番号、及び前記データベースにおけるイベントの内容が対応づけられた履歴情報を保持し、
    　前記復旧要求は、処理対象の前記管理範囲を示す情報を含み、
    　前記複製処理は、
    　前記計算機の復旧制御部が、
    　前記復旧要求を受信した場合、前記履歴情報に基づいて、最新のシーケンス番号を複製シーケンス番号として保持する手順と、
    　前記処理対象の管理範囲の排他ロックを取得する手順と、
    　前記処理対象の管理範囲に含まれるデータの中から、未送信のデータ、かつ、前記複製シーケンス番号より古い前記シーケンス番号を含むデータを一つ以上読み出して、前記第１の複製データとして前記他の計算機の復旧制御部に送信する手順と、
    　前記取得された排他ロックを解放する手順と、を含み、
    　前記更新処理は、
    　前記計算機のデータ管理部が、
    　前記処理対象の管理範囲の前記排他ロックを取得する手順と、
    　前記更新命令に基づいて前記所定のデータを更新し、前記第１の複製データの送信指示を前記計算機の復旧制御部に出力する手順と、
    　前記取得された排他ロックを解放する手順と、
    　前記計算機の復旧制御部が、前記送信指示に基づいて前記第１の複製データを前記他の計算機の復旧制御部に送信する手順と、を含むことを特徴とするプログラム。
PCT/JP2013/061257 2013-04-16 2013-04-16 計算機システム、計算機システム管理方法及びプログラム WO2014170952A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP13882090.7A EP2988220B1 (en) 2013-04-16 2013-04-16 Computer system, computer-system management method, and program
US14/426,996 US9892183B2 (en) 2013-04-16 2013-04-16 Computer system, computer system management method, and program
PCT/JP2013/061257 WO2014170952A1 (ja) 2013-04-16 2013-04-16 計算機システム、計算機システム管理方法及びプログラム
JP2015512218A JP5952960B2 (ja) 2013-04-16 2013-04-16 計算機システム、計算機システム管理方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/061257 WO2014170952A1 (ja) 2013-04-16 2013-04-16 計算機システム、計算機システム管理方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2014170952A1 true WO2014170952A1 (ja) 2014-10-23

Family

ID=51730925

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/061257 WO2014170952A1 (ja) 2013-04-16 2013-04-16 計算機システム、計算機システム管理方法及びプログラム

Country Status (4)

Country Link
US (1) US9892183B2 (ja)
EP (1) EP2988220B1 (ja)
JP (1) JP5952960B2 (ja)
WO (1) WO2014170952A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016117322A1 (ja) * 2015-01-22 2016-07-28 日本電気株式会社 処理要求装置、処理装置、データベースシステム、データベース更新方法およびプログラム記録媒体
WO2016143095A1 (ja) * 2015-03-11 2016-09-15 株式会社日立製作所 計算機システム及びトランザクション処理の管理方法
JP2017130705A (ja) * 2016-01-18 2017-07-27 日本電気株式会社 データ管理システム、データ管理方法、及び、データ管理プログラム
CN113822015A (zh) * 2020-06-16 2021-12-21 北京沃东天骏信息技术有限公司 序列号生成方法、装置、电子设备及计算机可读介质
JP2022026178A (ja) * 2020-07-30 2022-02-10 株式会社日立製作所 計算機システム、構成変更制御装置、および構成変更制御方法

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10333724B2 (en) 2013-11-25 2019-06-25 Oracle International Corporation Method and system for low-overhead latency profiling
US9553998B2 (en) 2014-06-09 2017-01-24 Oracle International Corporation Sharing group notification
US20150356117A1 (en) * 2014-06-09 2015-12-10 Oracle International Corporation Eventual consistency to resolve subscriber sharing relationships in a distributed system
US9910740B1 (en) * 2014-06-30 2018-03-06 EMC IP Holding Company LLC Concurrent recovery operation management
US10462218B1 (en) 2015-07-15 2019-10-29 Google Llc System and method for sending proposals within a distributed state machine replication system
US10007695B1 (en) * 2017-05-22 2018-06-26 Dropbox, Inc. Replication lag-constrained deletion of data in a large-scale distributed data storage system
US11275764B2 (en) * 2018-10-11 2022-03-15 EMC IP Holding Company LLC Highly resilient synchronous replication with automatic recovery
JP6972052B2 (ja) * 2019-02-28 2021-11-24 株式会社安川電機 通信システム、通信方法、及びプログラム
US11290390B2 (en) 2019-11-20 2022-03-29 Oracle International Corporation Methods, systems, and computer readable media for lockless communications network resource quota sharing
CN111209304B (zh) * 2019-12-30 2023-04-07 华为云计算技术有限公司 数据处理方法、装置及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5261085A (en) 1989-06-23 1993-11-09 Digital Equipment Corporation Fault-tolerant system and method for implementing a distributed state machine
JP2009199197A (ja) 2008-02-20 2009-09-03 Hitachi Ltd 計算機システム、データ一致化方法およびデータ一致化処理プログラム
WO2012140957A1 (ja) * 2011-04-13 2012-10-18 株式会社日立製作所 情報記憶システム及びそのデータ複製方法
WO2013046352A1 (ja) * 2011-09-28 2013-04-04 株式会社日立製作所 計算機システム、データ管理方法及びデータ管理プログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004259079A (ja) * 2003-02-27 2004-09-16 Hitachi Ltd データ処理システム
US20060235901A1 (en) * 2005-04-18 2006-10-19 Chan Wing M Systems and methods for dynamic burst length transfers
US9235595B2 (en) * 2009-10-02 2016-01-12 Symantec Corporation Storage replication systems and methods
JP5454201B2 (ja) * 2010-02-15 2014-03-26 富士通株式会社 データストア切替装置、データストア切替方法およびデータストア切替プログラム
KR101656384B1 (ko) * 2010-06-10 2016-09-12 삼성전자주식회사 불휘발성 메모리 장치의 데이터 기입 방법
US20120284231A1 (en) * 2011-05-06 2012-11-08 International Business Machines Corporation Distributed, asynchronous and fault-tolerant storage system
US8676951B2 (en) * 2011-07-27 2014-03-18 Hitachi, Ltd. Traffic reduction method for distributed key-value store
JP5733124B2 (ja) * 2011-09-12 2015-06-10 富士通株式会社 データ管理装置、データ管理システム、データ管理方法、及びプログラム
US20140019573A1 (en) * 2012-07-16 2014-01-16 Compellent Technologies Source reference replication in a data storage subsystem

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5261085A (en) 1989-06-23 1993-11-09 Digital Equipment Corporation Fault-tolerant system and method for implementing a distributed state machine
JP2009199197A (ja) 2008-02-20 2009-09-03 Hitachi Ltd 計算機システム、データ一致化方法およびデータ一致化処理プログラム
WO2012140957A1 (ja) * 2011-04-13 2012-10-18 株式会社日立製作所 情報記憶システム及びそのデータ複製方法
WO2013046352A1 (ja) * 2011-09-28 2013-04-04 株式会社日立製作所 計算機システム、データ管理方法及びデータ管理プログラム

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016117322A1 (ja) * 2015-01-22 2016-07-28 日本電気株式会社 処理要求装置、処理装置、データベースシステム、データベース更新方法およびプログラム記録媒体
JPWO2016117322A1 (ja) * 2015-01-22 2017-11-02 日本電気株式会社 処理要求装置、処理装置、データベースシステム、データベース更新方法およびプログラム
WO2016143095A1 (ja) * 2015-03-11 2016-09-15 株式会社日立製作所 計算機システム及びトランザクション処理の管理方法
US10747777B2 (en) 2015-03-11 2020-08-18 Hitachi, Ltd. Computer system and transaction processing management method
JP2017130705A (ja) * 2016-01-18 2017-07-27 日本電気株式会社 データ管理システム、データ管理方法、及び、データ管理プログラム
CN113822015A (zh) * 2020-06-16 2021-12-21 北京沃东天骏信息技术有限公司 序列号生成方法、装置、电子设备及计算机可读介质
JP2022026178A (ja) * 2020-07-30 2022-02-10 株式会社日立製作所 計算機システム、構成変更制御装置、および構成変更制御方法
JP7047027B2 (ja) 2020-07-30 2022-04-04 株式会社日立製作所 計算機システム、構成変更制御装置、および構成変更制御方法

Also Published As

Publication number Publication date
EP2988220A4 (en) 2017-01-11
EP2988220B1 (en) 2020-09-16
JP5952960B2 (ja) 2016-07-13
US20150242481A1 (en) 2015-08-27
JPWO2014170952A1 (ja) 2017-02-16
US9892183B2 (en) 2018-02-13
EP2988220A1 (en) 2016-02-24

Similar Documents

Publication Publication Date Title
JP5952960B2 (ja) 計算機システム、計算機システム管理方法及びプログラム
US10691716B2 (en) Dynamic partitioning techniques for data streams
US9639589B1 (en) Chained replication techniques for large-scale data streams
US9367261B2 (en) Computer system, data management method and data management program
US20170249246A1 (en) Deduplication and garbage collection across logical databases
US11263236B2 (en) Real-time cross-system database replication for hybrid-cloud elastic scaling and high-performance data virtualization
JP6360634B2 (ja) 計算機システム、及び、データ処理方法
JP6835968B2 (ja) スタビングによるコンテンツ記憶の最適化
JP2009157785A (ja) 待機系計算機の追加方法、計算機及び計算機システム
JP5686034B2 (ja) クラスタシステム、同期制御方法、サーバ装置および同期制御プログラム
US9984139B1 (en) Publish session framework for datastore operation records
US20190188309A1 (en) Tracking changes in mirrored databases
CN113010496A (zh) 一种数据迁移方法、装置、设备和存储介质
JP6196389B2 (ja) 分散型ディザスタリカバリファイル同期サーバシステム
WO2013118270A1 (ja) 計算機システム、データ管理方法及びプログラム
JP6007340B2 (ja) 計算機システム、計算機システム管理方法及びプログラム
KR101748913B1 (ko) 분산 저장 환경에서 게이트웨이를 선택하기 위한 클러스터 관리 방법 및 데이터 저장 시스템
US11157454B2 (en) Event-based synchronization in a file sharing environment
US20210248108A1 (en) Asynchronous data synchronization and reconciliation
US11687565B2 (en) Asynchronous data replication in a multiple availability zone cloud platform
US20230409535A1 (en) Techniques for resource utilization in replication pipeline processing
JPWO2012059976A1 (ja) プログラム、ストリームデータ処理方法及びストリームデータ処理計算機
WO2013073022A1 (ja) 計算機システム及び障害検出方法
JP2015165373A (ja) ノードおよびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13882090

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015512218

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14426996

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2013882090

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE