WO2018235348A1 - データベースサーバ、データベース管理方法、および記憶媒体 - Google Patents

データベースサーバ、データベース管理方法、および記憶媒体 Download PDF

Info

Publication number
WO2018235348A1
WO2018235348A1 PCT/JP2018/008667 JP2018008667W WO2018235348A1 WO 2018235348 A1 WO2018235348 A1 WO 2018235348A1 JP 2018008667 W JP2018008667 W JP 2018008667W WO 2018235348 A1 WO2018235348 A1 WO 2018235348A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
database server
server
request
state
Prior art date
Application number
PCT/JP2018/008667
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 US16/082,771 priority Critical patent/US11269922B2/en
Publication of WO2018235348A1 publication Critical patent/WO2018235348A1/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/273—Asynchronous replication or reconciliation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2082—Data synchronisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • 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
    • 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
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers

Definitions

  • Embodiments of the present invention relate to a database server, a database management method, and a storage medium.
  • a system for performing data replication takes place between multiple databases.
  • one of the database servers may function as a master and the other database server may function as a slave.
  • the master receives the request from the client, updates its own database, and requests the slave's database server to store a copy of the data (data synchronization).
  • operation patterns for notifying the client that processing based on a request is completed.
  • operation pattern synchronous replication
  • asynchronous replication an operation pattern of performing synchronization at an arbitrary timing after notifying the client.
  • switchover In a conventional database system that performs asynchronous replication, if synchronization is not completed at the start of switchover, the switchover may not be completed until synchronization is complete, and a period may occur in which requests from clients can not be accepted. there were. In addition, it is not this limitation about the switch performed at the time of abnormalities, such as apparatus failure.
  • a system that can receive a write request or a read request, and when executing processing based on a request, acquires necessary update information and then executes processing if the latest data to be a request is not held yet It has been known. However, even in this technology, if the latest data to be requested is not held yet, processing based on the request can not be executed until the necessary update information is acquired, and the client is The response may be delayed.
  • the problem to be solved by the present invention is to provide a database server, a database management method, and a storage medium that can respond to clients more quickly when switchover is performed.
  • the database server of the embodiment is included in a database system.
  • the database system comprises a plurality of database servers.
  • the database server has a database management unit and a synchronization processing unit.
  • the database management unit updates the database according to the request from the client when the own database server is in the first state for receiving the request from the client, and the database management unit is included in the plurality of database servers based on the request.
  • the update data for causing the database server to update the database of the other database server and the management information of the update data for each data management unit are registered in the memory.
  • the synchronization processing unit transmits the update data registered in the memory to the other database.
  • the synchronization processing unit transmits the management information registered in the memory to the other database.
  • the synchronization processing unit transmits update data registered in the memory to the other database.
  • the synchronization processing unit determines the database based on update data received from other database servers included in the plurality of database servers. Update.
  • FIG. 6 is a diagram for explaining the operation of the stage system 1 at the normal time.
  • FIG. 6 is a diagram for explaining the operation of the stage system 1 at the normal time.
  • FIG. 6 is a diagram for explaining the operation of the stage system 1 at the normal time.
  • FIG. 6 is a diagram for explaining the operation of the stage system 1 at the normal time.
  • FIG. 6 is a diagram for explaining the operation of the stage system 1 at the normal time.
  • movement of the stage system 1 at the time of switchover The figure for demonstrating the operation
  • movement of the stage system 1 at the time of switchover. 6 is a flowchart showing an example of the flow of processing executed by the DB management unit 110 and the replication processing unit 130 of the first DB server 100.
  • FIG. 6 is a flowchart showing an example of the flow of processing executed by the DB management unit 210 and the replication processing unit 230 of the second DB server 200.
  • FIG. 1 is a schematic view of a database system 2 provided with three or more DB servers.
  • FIG. 7 is a view showing a scene where switchover is started in the database system 2;
  • FIG. 7 is a diagram showing a scene after a switchover is completed in the database system 2;
  • FIG. 1 is a block diagram of a database system 1 of the embodiment.
  • the database system 1 is a system that manages a database stored in a storage device in response to a request from the client 300.
  • the client 300 is, for example, various computer devices that transmit a request (in other words, a command, a request) to the database system 1 via a network (not shown).
  • the client 300 may be a management computer of a database system higher than the database system 1.
  • the request is transmitted by, for example, a SQL statement.
  • a communication path between the client 300 and the database system 1 is referred to as a client link CL and illustrated.
  • the database system 1 includes, for example, a first DB (database) server 100 and a second DB server 200.
  • One of the first DB server 100 and the second DB server 200 operates as a master DB, and the other operates as a slave DB.
  • the first DB server 100 operates as a master DB
  • the second DB server 200 operates as a slave DB. This relationship can be switched, for example, by outputting an instruction signal to an input unit of the database system 1 (not shown).
  • the master DB receives a request from the client 300, first updates its own DB, returns a response to the client 300, and transmits the same request to the slave DB at arbitrary timing to synchronize the DB. That is, the database system 1 performs asynchronous replication.
  • two DB links DL and replication links RL are prepared as communication paths between the master DB and the slave DB. These communication paths may be physically different communication paths, may be virtual communication paths using one communication line, or may be communication paths using wireless communication. .
  • the first DB server 100 includes, for example, a DB management unit 110, a DB 120, a replication processing unit 130, and an update list module 140.
  • the DB management unit 110 and the replication processing unit 130 are realized, for example, when a processor such as a central processing unit (CPU) executes a program (software). Also, one or both of these may be realized by hardware (circuitry) such as LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), etc. , May be realized by cooperation of software and hardware.
  • LSI Large Scale Integration
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • the DB management unit 110 functions as a window for the client 300 when the first DB server 100 is a master DB.
  • the DB management unit 110 interprets the request from the client 300, and updates the DB 120 or reads data from the DB 120. Update requests include write and delete, but these will be collectively referred to as update requests below.
  • the DB management unit 110 manages the DB 120 in a management unit of predetermined data. Although the management unit of data can be referred to by a table, a block, a page, a record, and other names, in the present embodiment, the management unit of data is described as a table. Also, it is assumed that five tables of A, B, C, D, and E are set in the DB 120 and the DB 220 in a simplified manner. Also, in response to updating the DB 120, the DB management unit 110 updates the update list module 140.
  • the DB 120 is a database stored by, for example, one or more non-volatile storage devices (storage devices) such as a hard disk drive (HDD), a flash memory, and a magnetoresistive memory.
  • storage devices such as a hard disk drive (HDD), a flash memory, and a magnetoresistive memory.
  • the replication processing unit 130 refers to the update list module 140 updated by the DB management unit 110, and replicates the result (or the request itself) of the interpretation of the request from the client 300. It transmits to the replication processing unit 230 of the second DB server 200 via the link RL. At this time, the replication processing unit 130 updates the update list module 140.
  • the replication processing unit 130 updates the DB 120 based on the information received from the replication processing unit 230 of the second DB server 200 via the replication link RL.
  • the update list module 140 is information stored by a memory such as a random access memory (RAM) or a flash memory.
  • the update list module 140 may be stored by the same storage as the DB 120.
  • the update list module 140 includes, for example, a transmission update list 141, a reception update list 142, a transmission update table list 143, and a reception update table list 144.
  • Update data is registered in the transmission update list 141.
  • the update data registered in the transmission update list 141 is data that has been updated in the DB 120 by the DB management unit 110, and is data that has not yet been sent to the second DB server 200.
  • Update data and a flag are registered in the received update list 142.
  • the update data registered in the received update list 142 is data to be updated with respect to the DB 120 from now.
  • the flags will be described later.
  • the transmission update table list 143 a table and the number of updates are registered.
  • the table registered in the transmission update table list 143 is a table for which update data registered in the transmission update list 141 is to be updated.
  • the number of updates in the transmission update table list 143, the reception update table list 144, the transmission update table list 243, and the reception update table list 244 has different meanings between the normal time and the switchover time.
  • the switchover means, for example, exchanging the functions of the master DB and the slave DB based on an instruction from the outside or based on internal logic.
  • this function replacement includes failover performed urgently due to device failure or communication failure. Since switchover is not performed due to the above-mentioned abnormality, when the switchover is completed, it is necessary for the state before the switchover to be taken over from the client 300 as seen from the client 300.
  • a switchover time a period from the start of the switchover process to the completion
  • the other period will be referred to as a normal time.
  • the number of updates in the transmission update table list 143 represents the number of update data registered in the transmission update list 141 in the corresponding table.
  • the number of updates in the transmission update table list 143 is reset by the replication processing unit 130 after being transmitted to the replication processing unit 230 at the start of switchover.
  • the received update table list 144 a table and the number of updates are registered.
  • the table registered in the received update table list 144 is a table in which update data registered in the transmission update list 241 of the second DB server 200 is to be updated.
  • the number of updates in the received update table list 144 represents the number of updated data registered in the received update list 142 in the corresponding table.
  • the number of updates in the received update table list 144 corresponds to the number of times received from the replication processing unit 230 at the start of switchover, and the DB management is performed each time an update request for a non-synchronized table is received from the client 300 Every time it is incremented by the unit 110 and stored in the DB 120, it is decremented by the replication processing unit 130.
  • the second DB server 200 includes, for example, a DB management unit 210, a DB 220, a replication processing unit 230, and an update list module 240.
  • the DB management unit 210 and the replication processing unit 230 are realized, for example, by a processor such as a CPU executing a program (software).
  • a processor such as a CPU executing a program (software).
  • one or both of them may be realized by hardware (circuitry) such as an LSI, an ASIC, or an FPGA, or may be realized by cooperation of software and hardware.
  • the DB management unit 210 functions as a window for the client 300 when the second DB server 100 is a master DB.
  • the DB management unit 210 interprets the request from the client 300, and updates the DB 220 or reads data from the DB 220.
  • the DB management unit 210 manages the DB 220 in the same management unit as the first DB server 100. Also, the DB management unit 210 updates the update list module 240 in response to updating the DB 220.
  • the DB 220 is, for example, a database stored by one or more non-volatile storage devices (storage devices) such as HDD, flash memory, and magnetoresistive memory.
  • storage devices such as HDD, flash memory, and magnetoresistive memory.
  • the replication processing unit 230 refers to the update list module 240 updated by the DB management unit 210, and replicates the result (or the request itself) of the interpretation of the request from the client 300. It transmits to the replication processing unit 130 of the first DB server 100 via the link RL. At this time, the replication processing unit 230 updates the update list module 240. In addition, when the second DB server 200 is a slave DB, the replication processing unit 230 updates the DB 210 based on the information received from the replication processing unit 130 of the first DB server 100 via the replication link RL.
  • the update list module 240 is information stored by a storage device such as, for example, a RAM or a flash memory.
  • the update list module 240 may be stored by the same storage as the DB 220.
  • the update list module 240 includes, for example, a transmission update list 241, a reception update list 242, a transmission update table list 243, and a reception update table list 244.
  • Update data is registered in the transmission update list 241.
  • the update data registered in the transmission update list 241 is data that has been updated in the DB 220 by the DB management unit 210, and is data that has not yet been sent to the first DB server 100.
  • Update data and a flag are registered in the received update list 242.
  • the update data registered in the received update list 242 is data that has been received from the first DB server 100 and has not yet been updated with respect to the DB 220. The flags will be described later.
  • a table and the number of updates are registered in the transmission update table list 243.
  • the table registered in the transmission update table list 243 is a table on which the update data registered in the transmission update list 241 is to be updated.
  • the number of updates in the transmission update table list 243 indicates the number of update data registered in the transmission update list 241 in the corresponding table.
  • the number of updates in the transmission update table list 243 is reset by the replication processing unit 230 after being transmitted to the replication processing unit 230 at the start of switchover.
  • the table registered in the received update table list 244 is a table for which update data registered in the transmission update list 141 of the second DB server 100 is to be updated.
  • the number of updates in the received update table list 244 indicates the number of updated data registered in the received update list 242 in the corresponding table.
  • the number of updates in the received update table list 244 corresponds to the number of times received from the replication processing unit 230 at the start of switchover when a request for updating an unsynchronized table is received from the client 300 Every time it is incremented by the unit 210 and stored in the DB 220, it is decremented by the replication processing unit 230.
  • FIG. 2 shows a situation in which an update request for storing “1” in the table A is made from the client 300.
  • the DB management unit 110 stores data “1” in the table A of the DB 120 and, at the transmission update list 141, data such as “Inset into A values (1)” indicating the content of the request from the client 300 (hereinafter referred to as update Data) is registered, and further, the number of updates of the table A of the transmission update table list 143 is incremented to be 1.
  • FIG. 3 is a view exemplifying a scene in which an update request for storing “2” in the table B is made from the client 300 after the scene illustrated in FIG.
  • the DB management unit 110 stores “2” in the table B of the DB 120 and registers the update data “Inset into B values (2)” in the transmission update list 141, and further, in the table B of the transmission update table list 143. The number of updates is incremented to 1.
  • FIG. 4 relates to the update data “Inset into A values (1)” related to the table A in the transmission update list 141 by the replication processing unit 130 and the table A in the transmission update table list 143 after the scene illustrated in FIG.
  • FIG. 16 is a diagram illustrating a scene in which information is transmitted to the replication processing unit 230 and the reception updating list 242 and the reception updating table list 244 are updated by the replication processing unit 230.
  • the replication processing unit 230 registers update data “Inset into A values (1)” for the table A in the update data of the received update list 242 and increments the number of updates for the table A in the received update table list 244 to 1 Do.
  • the flag of the reception update list 242 is zero, that is, not set.
  • the flags in the received update list 142 and the received update list 242 are used exclusively at switchover.
  • the transmission of the information of the transmission update table list 143 may be omitted.
  • all the information of the transmission update table list 143 may be transmitted collectively.
  • the DB 200 is updated by the replication processing unit 230, and the replication processing unit 130 further updates update data “Inset into B values (2)” regarding the table B in the transmission update list 141. And information on the table B in the transmission update table list 143 is transmitted to the replication processing unit 230.
  • the replication processing unit 230 updates the DB 220 based on the update data “Inset into A values (1)” related to the table A, which has been registered in the received update list 242, and the number of updates of the table A of the received update table list 244 Is decremented to 0.
  • the replication processing unit 230 registers update data “Inset into B values (2)” related to the table B in the update data of the received update list 242 and increments the number of updates of the table B in the received update table list 244 It is assumed to be 1.
  • update data “Inset into B values (2)” related to the table B in the update data of the received update list 242 and increments the number of updates of the table B in the received update table list 244 It is assumed to be 1.
  • data transmission is performed according to the rule that the next update data is transmitted after being notified that storage in the counterpart DB is completed. It will be.
  • FIG. 6 is a view exemplifying a scene in which the DB 200 is updated by the replication processing unit 230 after the scene illustrated in FIG.
  • the replication processing unit 230 updates the DB 220 based on the update data “Inset into A values (2)” related to the table B that has been registered in the received update list 242, and the number of updates of the table B in the received update table list 244 Is decremented to 0.
  • synchronization is completed for all the tables between the DB 120 and the DB 220.
  • the database system 1 repeatedly executes such a series of operations, and continues asynchronous replication.
  • FIG. 7 is a diagram exemplifying a scene in which a switchover request is received.
  • a switchover request (an example of a role change request) may be received from an apparatus (including an input device such as a keyboard or a mouse) other than the client 300, or may be received from the client 300.
  • the switchover request may be received from a higher order database system.
  • update data "Inset into B values (3)” and "Inset into B values (4)" related to the table B are registered in the transmission update list 141. Both of these are reflected in the DB 120, and “4” is stored in the table B based on the request “Inset into B values (4)” received later. Further, 2 is registered in the transmission update table list 143 as the number of updates of the table B.
  • FIG. 8 is a diagram illustrating a scene after the scene illustrated in FIG.
  • the DB management unit 110 sends a switchover notification to the DB management unit 210 via the DB link DL. Thereafter, the DB management unit 210 notifies the client 300 that the DB management unit 210 itself receives a request from the client 300.
  • the DB management unit 110 instructs the replication processing unit 130 to transmit all of the information registered in the transmission update table list 143 to the replication processing unit 230 in response to the switchover.
  • the replication processing unit 130 transmits all of the information registered in the transmission update table list 143 to the replication processing unit 230, and resets (deletes, erases, or invalidates) the information registered in the transmission update table list 143.
  • the replication processing unit 230 registers the information received from the replication processing unit 130 in the received update table list 244.
  • the DB management unit 210 accepts from the client 300 an update request for storing "6" in the table A and an update request for storing "7" in the table B. It is the figure which illustrated the scene. In this case, the DB management unit 210 determines whether the table related to each request is unsynchronized. For example, the DB management unit 210 determines that the number of updates of the table in the received update table list 244 is unsynchronized if it is not zero, and is zero if it is zero.
  • the DB management unit 210 stores it in its own DB 220 and registers the information of the table in the transmission update list 241 and the transmission update table list 243.
  • the DB management unit 210 stores “6” in its own DB 220 for the synchronized table A and registers update data “Insert into A values (6)” in the transmission update list 241, The number of updates of the table A of the transmission update table list 243 is incremented to be 1.
  • the DB management unit 210 transfers the request (or the result of interpreting the request) to the DB management unit 110 via the DB link DL, and Register the result of interpreting the request. At this time, the DB management unit 210 sets the flag 1 to the registered result, and does not update the DB 220 in order to maintain the order of update.
  • the flags in the received update list 142 and the received update list 242 are flags indicating that they are based on the request accepted for the unsynchronized table between the start and the completion of the switchover. is there. In the example of FIG.
  • the DB management unit 210 registers update data “Insert into B values (7)” in the received update list 242 for the unsynchronized table B and sets the flag to 1, and the received update table.
  • the number of updates of the table B in the list 244 is incremented to 3.
  • the DB management unit 110 that has received the request for the unsynchronized table stores “7” in the table B of the DB 120. In this case, since the DB management unit 110 recognizes that the request transfer is being performed during switchover, the DB management unit 110 updates the DB 120 but does not update the transmission update list 141 and the transmission update table list 143.
  • the same distribution is performed when a request other than the update request, for example, a read request is received. That is, if the read request relates to an unsynchronized table, the DB management unit 210 transfers the request (or the result of interpreting the request) to the DB management unit 110 via the DB link DL and the DB management unit 110 The returned result is returned to the client 300, and if it relates to a synchronized table, it is read from the DB 220 and the result is returned to the client 300.
  • the replication processing unit 130 transmits update data “Inset into B values (3)” related to the table B in the transmission update list 141 to the replication processing unit 230, and the replication processing unit It is the figure which illustrated the scene where the reception renewal list 242 was renewed with 230.
  • the replication processing unit 230 registers “Insert into B values (3)” in the reception update list 242 and sets a flag to 0.
  • the DB 220 is updated by the replication processing unit 230, and the replication processing unit 130 further updates update data “Inset into B values (4)” regarding the table B in the transmission update list 141.
  • the information on the table B in the transmission update table list 143 is transmitted to the replication processing unit 230, and the replication processing unit 230 is an example of a scene in which the reception update list 242 and the reception update table list 244 are updated.
  • the replication processing unit 230 stores “3” in the table B of the DB 220, and decrements the number of updates of the table B of the received update table list 244 to be 2.
  • the replication processing unit 230 first stores update data whose flag is zero in the DB 220. This maintains the order of the update process.
  • the replication processing unit 230 registers “Inset into B values (4)” in the reception update list 242.
  • the process of transmitting the information on the transmission update list from the old master side to the new master side shown in FIG. 11 may be sequentially performed from the table for which the read request or update request has been made to the new master side. Further, the process of updating the DB based on the transmission update list from the old master side shown in FIG. 12 may also be sequentially performed from the table for which the read request or update request has been made to the new master side.
  • FIG. 12 is a diagram illustrating a scene in which the DB 220 is updated by the replication processing unit 230 and the received update list 242 and the received update table list 244 are updated after the scene illustrated in FIG.
  • the replication processing unit 230 stores “4” in the table B of the DB 220, and decrements the number of updates of the table B of the received update table list 244 to 1. Also in this case, the replication processing unit 230 first stores update data whose flag is zero in the DB 220.
  • FIG. 13 is a diagram exemplifying a scene in which the DB 220 is updated by the replication processing unit 230 and the reception update list 242 and the reception update table list 244 are updated after the scene illustrated in FIG. 12.
  • the replication processing unit 230 updates the DB 220 based on the update data of which the flag is 1 because there is no update data of which the flag is 0 for the table B.
  • the replication processing unit 230 stores “7” in the table B of the DB 220, and decrements the number of updates of the table B of the received update table list 244 to 0. Note that the processing of this scene may be performed by the DB management unit 210.
  • FIG. 14 is a diagram illustrating a scene in which the synchronization of the table A is completed. This completes the synchronization of unsynchronized data.
  • the completion of synchronization of unsynchronized data is determined, for example, by the DB management unit 210 that has newly become the master DB, and notified to the DB management unit 110 of the old master DB.
  • FIG. 15 is a flowchart showing an example of the flow of processing executed by the DB management unit 110 and the replication processing unit 130 of the first DB server 100. The process of this flowchart is started when the DB management unit 110 receives a switchover request.
  • the DB management unit 110 newly notifies the DB management unit 210 of the DB 200, which is the master DB, of information indicating that a switchover will occur (step S100).
  • the replication processing unit 130 collectively transmits the information registered in the transmission update table list 143 to the replication processing unit 230 (step S102).
  • the DB management unit 110 determines whether an update request has been made via the DB link DL (step S104). When there is an update request via the DB link DL, the DB management unit 110 updates the DB 120 (step S106). Note that the update list module 140 is not updated in step S106.
  • the replication processing unit 130 determines whether update data exists in the transmission update list 141 (step S108). When update data exists in the transmission update list 141, the replication processing unit 130 determines whether the update data can be transmitted via the replication link RL (step S110). If the transmission is not possible, the process returns to step S104. In the case where it is not in the transmittable state, for example, when it is not received from the replication processing unit 230 that the update data transmitted earlier has been notified that the reflection on the DB 220 has been completed, or the replication link RL is used for communication. And so on.
  • the replication processing unit 130 transmits the earliest one of the update data registered timings to the replication processing unit 230 via the replication link RL, and transmits it from the transmission update list 141 The updated data is deleted (step S112).
  • the DB management unit 110 determines whether synchronization of unsynchronized data is completed (step S114). If it is determined that the synchronization of the unsynchronized data is not completed, the process returns to step S104. If it is determined that the synchronization of the unsynchronized data is completed, the processing of this flowchart ends. Note that the DB management unit 110 determines whether synchronization of unsynchronized data is completed based on notification information received from the DB management unit 210 via the DB link DL, for example.
  • FIG. 16 is a flowchart showing an example of the flow of processing executed by the DB management unit 210 and the replication processing unit 230 of the second DB server 200. The process of this flowchart is started when the DB management unit 210 receives a notification of switchover (notice of step S100 in FIG. 15).
  • the DB management unit 210 notifies the client 300 that a switchover will occur (step S200).
  • the replication processing unit 230 collectively receives the information of the transmission update table list 143 of the first DB server 100 from the replication processing unit 130, and registers the information in the reception update table list 244 (step S202).
  • the DB management unit 210 determines whether an update request has been received from the client 300 (step S204). If it is determined that the update request has been received from the client 300, the DB management unit 210 determines whether the target of the update request is an unsynchronized table (step S206). If it is determined that the target of the update request is not an unsynchronized table, the DB management unit 210 updates the DB 220 of itself (the second DB server 200) and registers the updated content in the update list module 240 (step S208).
  • the DB management unit 210 transfers the update request to the DB management unit 110 of the first DB server 100 that is the old master DB via the DB link DL. (Step S210). Then, the DB management unit 210 registers the update request in its own update list module 240 (step S212).
  • the replication processing unit 230 determines whether update data has been received from the replication processing unit 130 of the first DB server 100 that is the old master DB (step S214). When the update data is received from the replication processing unit 130, the replication processing unit 230 registers information such as update data in the update list module 140 (step S216). Next, the replication processing unit 230 determines whether or not the DB 220 can be updated (step S218). If it is determined that the DB 220 can be updated, the replication processing unit 230 updates the DB 220 based on the contents of the update list module 240 (step S220). The case in which the DB can not be updated is, for example, the case where the DB managing unit 210 is in the process of updating the DB 220.
  • the DB management unit 210 determines whether synchronization of unsynchronized data is completed (step S222). If it is determined that the synchronization of unsynchronized data is not completed, the process returns to step S204. On the other hand, when it is determined that the synchronization of the unsynchronized data is completed, the DB management unit 210 sends a completion notification to the DB management unit 110 of the first DB server 100 which is the old master DB (step S224). The DB management unit 210 determines, for example, whether or not all the information in the update list modules 140 and 240 has been reset by communication with the first DB server 100, and it has been confirmed that all the information has been reset. In this case, it is determined that synchronization of unsynchronized data is completed.
  • FIG. 17 is a diagram schematically showing the flow of processing performed at switchover execution in the database system of the comparative example.
  • the unsynchronized data is transferred, the unsynchronized data is stored in the memory of the new master, and furthermore, unsynchronized data Switchover is complete after the data is stored in the new master's DB.
  • the time of the process of storing unsynchronized data in the DB is dominant, and it may take time until the switchover is completed, for example, on the order of several seconds to several tens of seconds.
  • FIG. 18 is a diagram schematically showing the flow of processing performed at switchover execution in the database system 1 of the embodiment.
  • the transmission update table list is first transmitted from the old master to the new master, and the new master holds the received transmission update table list as a reception update table list.
  • the switchover is complete.
  • the update process of the DB is not necessary until the switchover is completed, and for example, the process is expected to be completed on the order of less than 1 [sec].
  • the new master can distribute the request from the client to itself or the old master while referring to the received update table list, and can promptly respond to the request from the client for all the tables of the database system 1 in principle.
  • FIG. 19 is a schematic view of a database system 2 provided with three or more DB servers.
  • the figure shows a database system 2 including a first DB server 100A, a second DB server 200A, and one or more n-th DB servers 400A (n is a natural number of 3 or more).
  • Each DB server includes a DB management unit, a DB, an update list module, and a replication processing unit.
  • FIG. 20 is a diagram showing a scene where switchover is started in the database system 2.
  • the first DB server 100A transmits the transmission update table list to the second DB server 200A.
  • FIG. 21 is a diagram showing a scene after the switchover is completed in the database system 2.
  • the DB management unit 210A transfers a request for the unsynchronized table to the first DB server 100A.
  • the replication processing unit 140A transmits unsynchronized data (updated data) registered in the update list module 130A to the second DB server 200A and the n-th DB server 400A.
  • the replication processing unit 240A also transmits unsynchronized data generated between synchronization completion to the first DB server 100A and the nth DB server 400A after completion of switchover. Thereby, the same switchover as in the case of providing two DB servers is realized.
  • the database when the own database server is in the first state of receiving a request from the client, the database is updated in response to the request from the client, and the plurality of the plurality is updated based on the request.
  • a database management unit for registering, in a memory, update data for causing another database server included in the database server to update the database of the other database server, and management information of the update data for each management unit of data;
  • a synchronization processing unit that transmits the update data registered in the memory to the other database server when the own database server is in the first state, and the own database server responds to the role change instruction.
  • the synchronization process when transitioning from the first state to the second state Transmits the management information registered in the memory to the other database server, and when the own database server is in the second state, the synchronization processing unit updates data registered in the memory When it is transmitted to the other database server and the own database server is in the third state of transitioning from the second state, the synchronization processing unit receives from the other database servers included in the plurality of database servers The database is updated based on the updated data. This allows the client to respond more quickly when performing a switchover.
  • the replication processing unit executes the processing in both the normal time and the switchover time
  • the database system is not activated at normal time, but is activated at switchover time and the replication processing unit is activated.
  • a functional unit that performs the same processing as the above.
  • the replication processing unit is an example of the “synchronization processing unit”
  • the combination of the replication processing unit and its functional units is an example of the “synchronization processing unit”.
  • the state that is the master DB corresponds to the first state
  • the state from switching from the master DB to the slave DB and completion of the switchover corresponds to the second state
  • the state that is the slave DB is the third It corresponds to the state
  • the state until the switchover is completed after switching from the slave DB to the master DB corresponds to the fourth state.

Landscapes

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

Abstract

データベースサーバは、データベース管理部と、同期処理部とを持つ。データベース管理部は、自データベースサーバが、クライアントからの要求を受け付ける第１の状態である場合、前記クライアントからの要求に応じてデータベースを更新し、前記要求に基づき前記複数のデータベースサーバに含まれる他のデータベースサーバに当該他のデータベースサーバのデータベースを更新させるための更新データと、データの管理単位ごとの前記更新データの管理情報とをメモリに登録する。同期処理部は、自データベースサーバが、前記第１の状態である場合、前記メモリに登録された更新データを前記他のデータベースに送信する。

Description

データベースサーバ、データベース管理方法、および記憶媒体
　本発明の実施形態は、データベースサーバ、データベース管理方法、および記憶媒体に関する。
　従来、データのレプリケーションを行うシステムが知られている。レプリケーションは、複数のデータベース間で行われる。複数のデータベースを備えるデータベースシステムでは、いずれかのデータベースサーバがマスターとして機能し、他のデータベースサーバがスレーブとして機能する場合がある。マスターは、クライアントからの要求を受け付け、自身のデータベースを更新すると共に、スレーブのデータベースサーバにデータの複製を保存すること（データの同期）を依頼する。
　ここで、データベースシステムとして、要求に基づく処理が完了したことをクライアントに通知する動作パターンには、主に２通りの動作パターンがある。例えば、スレーブにおいて同期が完了してからクライアントに通知する動作パターン（同期レプリケーション）と、クライアントに通知してから任意のタイミングで同期を行う動作パターン（非同期レプリケーション）とがある。
　そして、マスターとスレーブの関係は、何らかの契機で入れ替わる場合がある。以下、この動作をスイッチオーバーと称する。従来の非同期レプリケーションを行うデータベースシステムでは、スイッチオーバーを開始する時点で同期が完了していない場合、同期が完了するまでスイッチオーバーが完了せず、クライアントからの要求を受け付けられない期間が生じる場合があった。なお、機器故障などの異常時に実行されるスイッチに関してはこの限りでない。
　上記に関連し、第１のサイトと第２のサイトとを備え、第２のサイトが、第１のサイトに代わってまたは第１のサイトの補助としてシステム機能の少なくとも一部を提供するために書き込み要求または読み出し要求を受け付けることができ、要求に基づく処理を実行するとき、要求の対象となる最新のデータを未だ保持していなければ、必要な更新情報を取得してから処理を実行するシステムが知られている。しかしながら、この技術においても、要求の対象となる最新のデータを未だ保持していない場合には、必要な更新情報を取得するまでの間、要求に基づく処理を実行できないことになり、クライアントへの応答が遅延する場合があった。
特開２００６－１１８４８号公報
　本発明が解決しようとする課題は、スイッチオーバー実行時に、より迅速にクライアントに応答することができるデータベースサーバ、データベース管理方法、および記憶媒体を提供することである。
　実施形態のデータベースサーバは、データベースシステムに含まれる。データベースシステムは、複数のデータベースサーバを備える。データベースサーバは、データベース管理部と、同期処理部とを持つ。データベース管理部は、自データベースサーバが、クライアントからの要求を受け付ける第１の状態である場合、前記クライアントからの要求に応じてデータベースを更新し、前記要求に基づき前記複数のデータベースサーバに含まれる他のデータベースサーバに当該他のデータベースサーバのデータベースを更新させるための更新データと、データの管理単位ごとの前記更新データの管理情報とをメモリに登録する。同期処理部は、自データベースサーバが、前記第１の状態である場合、前記メモリに登録された更新データを前記他のデータベースに送信する。自データベースサーバが、役割変更指示に応じて前記第１の状態から第２の状態に遷移するとき、前記同期処理部は、前記メモリに登録された前記管理情報を前記他のデータベースに送信する。自データベースサーバが、前記第２の状態である場合、前記同期処理部は、前記メモリに登録された更新データを前記他のデータベースに送信する。自データベースサーバが、前記第２の状態から遷移する第３の状態である場合、前記同期処理部は、前記複数のデータベースサーバに含まれる他のデータベースサーバから受信した更新データに基づいて前記データベースを更新する。
実施形態のデータベースシステム１の構成図。 通常時におけるステージシステム１の動作を説明するための図。 通常時におけるステージシステム１の動作を説明するための図。 通常時におけるステージシステム１の動作を説明するための図。 通常時におけるステージシステム１の動作を説明するための図。 通常時におけるステージシステム１の動作を説明するための図。 スイッチオーバー時におけるステージシステム１の動作を説明するための図。 スイッチオーバー時におけるステージシステム１の動作を説明するための図。 スイッチオーバー時におけるステージシステム１の動作を説明するための図。 スイッチオーバー時におけるステージシステム１の動作を説明するための図。 スイッチオーバー時におけるステージシステム１の動作を説明するための図。 スイッチオーバー時におけるステージシステム１の動作を説明するための図。 スイッチオーバー時におけるステージシステム１の動作を説明するための図。 スイッチオーバー時におけるステージシステム１の動作を説明するための図。 第１ＤＢサーバ１００のＤＢ管理部１１０およびレプリケーション処理部１３０により実行される処理の流れの一例を示すフローチャート。 第２ＤＢサーバ２００のＤＢ管理部２１０およびレプリケーション処理部２３０により実行される処理の流れの一例を示すフローチャート。 比較例のデータベースシステムにおいてスイッチオーバー実行時に行われる処理の流れを模式的に示す図。 実施形態のデータベースシステム１においてスイッチオーバー実行時に行われる処理の流れを模式的に示す図。 三つ以上のＤＢサーバを備えるデータベースシステム２の概略図。 データベースシステム２においてスイッチオーバーが開始された場面を示す図。 データベースシステム２においてスイッチオーバーが完了した後の場面を示す図。
　以下、実施形態のデータベースサーバ、データベース管理方法、および記憶媒体を、図面を参照して説明する。
　［全体構成］
　図１は、実施形態のデータベースシステム１の構成図である。データベースシステム１は、クライアント３００からの要求に応じて、ストレージ装置に格納したデータベースを管理するシステムである。クライアント３００は、例えば、ネットワーク（不図示）を介してデータベースシステム１に要求（換言するとコマンド、リクエスト）を送信する各種コンピュータ装置である。クライアント３００は、データベースシステム１よりも上位のデータベースシステムの管理コンピュータであってもよい。要求は、例えばＳＱＬ文によって伝達される。実施形態では、クライアント３００とデータベースシステム１との通信経路をクライアントリンクＣＬと称し、図示する。
　データベースシステム１は、例えば、第１ＤＢ（データベース）サーバ１００と、第２ＤＢサーバ２００とを備える。第１ＤＢサーバ１００および第２ＤＢサーバ２００は、一方がマスターＤＢとして動作し、他方がスレーブＤＢとして動作する。図１の例では、第１ＤＢサーバ１００がマスターＤＢとして動作し、第２ＤＢサーバ２００がスレーブＤＢとして動作している。この関係は、例えば、図示しないデータベースシステム１の入力部に対して指示信号を出力することで切り替え可能である。
　マスターＤＢは、クライアント３００からの要求を受け付け、まず自信のＤＢを更新しでクライアント３００に応答を返し、任意のタイミングでスレーブＤＢに同じ要求を送信してＤＢを同期させる。すなわち、データベースシステム１は、非同期レプリケーションを行う。
　マスターＤＢとスレーブＤＢの間の通信経路として、例えば、ＤＢリンクＤＬと、レプリケーションリンクＲＬの二つが用意されている。これらの通信経路は、物理的に異なる通信経路であってもよいし、一つの通信線を用いた仮想的な通信経路であってもよいし、無線通信を用いた通信経路であってもよい。
　［第１ＤＢサーバ］
　第１ＤＢサーバ１００は、例えば、ＤＢ管理部１１０と、ＤＢ１２０と、レプリケーション処理部１３０と、更新リストモジュール１４０とを備える。ＤＢ管理部１１０およびレプリケーション処理部１３０は、例えば、ＣＰＵ（Central Processing Unit）などのプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらのうち一方または双方は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェア（回路部：circuitry）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。
　ＤＢ管理部１１０は、第１ＤＢサーバ１００がマスターＤＢである場合、クライアント３００に対する窓口として機能する。ＤＢ管理部１１０は、クライアント３００からの要求を解釈し、ＤＢ１２０の更新あるいはＤＢ１２０からのデータの読み出しを行う。更新の要求には、書き込みと削除があるが、以下ではこれらをまとめて更新要求と称する。ＤＢ管理部１１０は、所定のデータの管理単位でＤＢ１２０を管理する。データの管理単位は、テーブル、ブロック、ページ、レコードその他の名称で称することができるが、本実施形態ではデータの管理単位をテーブルとして説明する。また、簡易的に、ＤＢ１２０およびＤＢ２２０には、Ａ、Ｂ、Ｃ、Ｄ、Ｅの５つのテーブルが設定されているものとする。また、ＤＢ管理部１１０は、ＤＢ１２０を更新するのに応じて、更新リストモジュール１４０を更新する。
　ＤＢ１２０は、例えば、一以上の、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ、磁気抵抗メモリなどの不揮発性の記憶装置（ストレージ装置）によって記憶されるデータベースである。
　レプリケーション処理部１３０は、第１ＤＢサーバ１００がマスターＤＢである場合、ＤＢ管理部１１０によって更新された更新リストモジュール１４０を参照し、クライアント３００からの要求を解釈した結果（或いは要求そのもの）を、レプリケーションリンクＲＬを介して第２ＤＢサーバ２００のレプリケーション処理部２３０に送信する。この際に、レプリケーション処理部１３０は、更新リストモジュール１４０を更新する。また、レプリケーション処理部１３０は、第１ＤＢサーバ１００がスレーブＤＢである場合、レプリケーションリンクＲＬを介して第２ＤＢサーバ２００のレプリケーション処理部２３０から受信した情報に基づいて、ＤＢ１２０を更新する。
　更新リストモジュール１４０は、例えばＲＡＭ（Random Access Memory）、フラッシュメモリなどのメモリによって記憶される情報である。更新リストモジュール１４０は、ＤＢ１２０と同じ記憶装置によって記憶されてもよい。更新リストモジュール１４０は、例えば、送信更新リスト１４１と、受信更新リスト１４２と、送信更新テーブルリスト１４３と、受信更新テーブルリスト１４４とを備える。
　送信更新リスト１４１には、更新データが登録される。送信更新リスト１４１に登録される更新データは、ＤＢ管理部１１０によりＤＢ１２０に更新がなされたデータであって、未だ第２ＤＢサーバ２００に送信されていないデータである。
　受信更新リスト１４２には、更新データとフラグとが登録される。受信更新リスト１４２に登録される更新データは、これからＤＢ１２０に対して更新処理がなされる対象のデータである。フラグについては後述する。
　送信更新テーブルリスト１４３には、テーブルと更新回数とが登録される。送信更新テーブルリスト１４３に登録されるテーブルは、送信更新リスト１４１に登録されている更新データが更新対象とするテーブルである。
　送信更新テーブルリスト１４３、受信更新テーブルリスト１４４、送信更新テーブルリスト２４３、および受信更新テーブルリスト２４４における更新回数は、通常時とスイッチオーバー時で意味合いが異なる。ここでスイッチオーバーについて説明する。スイッチオーバーとは、例えば、外部からの指示に応じて、或いは内部的なロジックに基づいて、マスターＤＢとスレーブＤＢの機能を入れ替えることをいう。この機能の入れ替えには、スイッチオーバーの他に、機器故障や通信障害などによって緊急的に行うフェールオーバーがある。スイッチオーバーは、上記のような異常に起因して行われるものではないため、スイッチオーバーの完了時には、クライアント３００から見てスイッチオーバー前の状態が引き継がれている必要がある。以下、スイッチオーバーの処理が開始されてから完了するまでの間をスイッチオーバー時と称し、それ以外の期間を通常時と称する。
　通常時の場合、送信更新テーブルリスト１４３における更新回数は、対応するテーブルにおいて、送信更新リスト１４１に登録されている更新データの数を表す。また、スイッチオーバー時の場合、送信更新テーブルリスト１４３における更新回数は、スイッチオーバー開始時にレプリケーション処理部２３０に送信された後、レプリケーション処理部１３０によってリセットされる。
　受信更新テーブルリスト１４４には、テーブルと更新回数とが登録される。受信更新テーブルリスト１４４に登録されるテーブルは、第２ＤＢサーバ２００の送信更新リスト２４１に登録されている更新データが更新対象とするテーブルである。
　通常時の場合、受信更新テーブルリスト１４４における更新回数は、対応するテーブルにおいて、受信更新リスト１４２に登録されている更新データの数を表す。スイッチオーバー時の場合、受信更新テーブルリスト１４４における更新回数は、スイッチオーバー開始時にレプリケーション処理部２３０から受信した回数に対して、未同期のテーブルに関する更新要求がクライアント３００から受信される度にＤＢ管理部１１０によってインクリメントされ、ＤＢ１２０に格納される度にレプリケーション処理部１３０によってデクリメントされる。
　［第２ＤＢサーバ］
　第２ＤＢサーバ２００は、例えば、ＤＢ管理部２１０と、ＤＢ２２０と、レプリケーション処理部２３０と、更新リストモジュール２４０とを備える。ＤＢ管理部２１０およびレプリケーション処理部２３０は、例えば、ＣＰＵなどのプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらのうち一方または双方は、ＬＳＩやＡＳＩＣ、ＦＰＧＡなどのハードウェア（回路部：circuitry）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。
　ＤＢ管理部２１０は、第２ＤＢサーバ１００がマスターＤＢである場合、クライアント３００に対する窓口として機能する。ＤＢ管理部２１０は、クライアント３００からの要求を解釈し、ＤＢ２２０の更新あるいはＤＢ２２０からのデータの読み出しを行う。ＤＢ管理部２１０は、第１ＤＢサーバ１００と同じ管理単位でＤＢ２２０を管理する。また、ＤＢ管理部２１０は、ＤＢ２２０を更新するのに応じて、更新リストモジュール２４０を更新する。
　ＤＢ２２０は、例えば、一以上の、ＨＤＤやフラッシュメモリ、磁気抵抗メモリなどの不揮発性の記憶装置（ストレージ装置）によって記憶されるデータベースである。
　レプリケーション処理部２３０は、第２ＤＢサーバ２００がマスターＤＢである場合、ＤＢ管理部２１０によって更新された更新リストモジュール２４０を参照し、クライアント３００からの要求を解釈した結果（或いは要求そのもの）を、レプリケーションリンクＲＬを介して第１ＤＢサーバ１００のレプリケーション処理部１３０に送信する。この際に、レプリケーション処理部２３０は、更新リストモジュール２４０を更新する。また、レプリケーション処理部２３０は、第２ＤＢサーバ２００がスレーブＤＢである場合、レプリケーションリンクＲＬを介して第１ＤＢサーバ１００のレプリケーション処理部１３０から受信した情報に基づいて、ＤＢ２１０を更新する。
　更新リストモジュール２４０は、例えばＲＡＭ、フラッシュメモリなどの記憶装置によって記憶される情報である。更新リストモジュール２４０は、ＤＢ２２０と同じ記憶装置によって記憶されてもよい。更新リストモジュール２４０は、例えば、送信更新リスト２４１と、受信更新リスト２４２と、送信更新テーブルリスト２４３と、受信更新テーブルリスト２４４とを備える。
　送信更新リスト２４１には、更新データが登録される。送信更新リスト２４１に登録される更新データは、ＤＢ管理部２１０によりＤＢ２２０に更新がなされたデータであって、未だ第１ＤＢサーバ１００に送信されていないデータである。
　受信更新リスト２４２には、更新データとフラグとが登録される。受信更新リスト２４２に登録される更新データは、第１ＤＢサーバ１００から受信し、未だＤＢ２２０に対して更新処理がなされていないデータである。フラグについては後述する。
　送信更新テーブルリスト２４３には、テーブルと更新回数とが登録される。送信更新テーブルリスト２４３に登録されるテーブルは、送信更新リスト２４１に登録されている更新データが更新対象とするテーブルである。
　通常時において、送信更新テーブルリスト２４３における更新回数は、対応するテーブルにおいて、送信更新リスト２４１に登録されている更新データの数を表す。また、スイッチオーバー時の場合、送信更新テーブルリスト２４３における更新回数は、スイッチオーバー開始時にレプリケーション処理部２３０に送信された後、レプリケーション処理部２３０によってリセットされる。
　受信更新テーブルリスト２４４には、テーブルと更新回数とが登録される。受信更新テーブルリスト２４４に登録されるテーブルは、第２ＤＢサーバ１００の送信更新リスト１４１に登録されている更新データが更新対象とするテーブルである。
　通常時において、受信更新テーブルリスト２４４における更新回数は、対応するテーブルにおいて、受信更新リスト２４２に登録されている更新データの数を表す。スイッチオーバー時の場合、受信更新テーブルリスト２４４における更新回数は、スイッチオーバー開始時にレプリケーション処理部２３０から受信した回数に対して、未同期のテーブルに関する更新要求がクライアント３００から受信される度にＤＢ管理部２１０によってインクリメントされ、ＤＢ２２０に格納される度にレプリケーション処理部２３０によってデクリメントされる。
　［処理内容：通常時］
　以下、ステージシステム１における処理の内容について、より詳細に説明する。まず、前述した通常時の処理について説明する。図２～６は、通常時におけるステージシステム１の動作を説明するための図である。
　以下、時系列に場面を例示して説明する。図２は、クライアント３００からテーブルＡに「１」を格納する更新要求がなされた場面を示している。ＤＢ管理部１１０は、ＤＢ１２０のテーブルＡに「１」を格納すると共に、送信更新リスト１４１に、クライアント３００からの要求内容を示す“Inset into A values (1)”のようなデータ（以下、更新データ）を登録し、更に、送信更新テーブルリスト１４３のテーブルＡの更新回数をインクリメントして１とする。
　図３は、図２に例示した場面の後、クライアント３００からテーブルＢに「２」を格納する更新要求がなされた場面を例示した図である。ＤＢ管理部１１０は、ＤＢ１２０のテーブルＢに「２」を格納すると共に、送信更新リスト１４１に更新データ“Inset into B values (2)”を登録し、更に、送信更新テーブルリスト１４３のテーブルＢの更新回数をインクリメントして１とする。
　図４は、図３に例示した場面の後、レプリケーション処理部１３０によって送信更新リスト１４１のうちテーブルＡに関する更新データ“Inset into A values (1)”と、送信更新テーブルリスト１４３のうちテーブルＡに関する情報とがレプリケーション処理部２３０に送信され、レプリケーション処理部２３０によって受信更新リスト２４２および受信更新テーブルリスト２４４が更新された場面を例示した図である。レプリケーション処理部２３０は、テーブルＡに関する更新データ“Inset into A values (1)”を受信更新リスト２４２の更新データに登録すると共に、受信更新テーブルリスト２４４におけるテーブルＡに関する更新回数をインクリメントして１とする。ここで、受信更新リスト２４２のフラグはゼロ、すなわち非設定のままである。受信更新リスト１４２および受信更新リスト２４２のフラグは、専らスイッチオーバー時に使用される。なお、通常時において、送信更新リスト１４１の情報を送信する際に、送信更新テーブルリスト１４３の情報の送信を省略してもよい。また、通常時において、送信される送信更新リスト１４１の情報に対応した部分のみを送信するのではなく、送信更新テーブルリスト１４３の全ての情報を一括して送信してもよい。
　図５は、図４に例示した場面の後、レプリケーション処理部２３０によってＤＢ２００が更新され、更に、レプリケーション処理部１３０によって送信更新リスト１４１のうちテーブルＢに関する更新データ“Inset into B values (2)”と、送信更新テーブルリスト１４３のうちテーブルＢに関する情報とがレプリケーション処理部２３０に送信された場面を例示した図である。レプリケーション処理部２３０は、受信更新リスト２４２に登録されていた、テーブルＡに関する更新データ“Inset into A values (1)”に基づいて、ＤＢ２２０を更新し、受信更新テーブルリスト２４４のテーブルＡの更新回数をデクリメントして０とする。更に、レプリケーション処理部２３０は、テーブルＢに関する更新データ“Inset into B values (2)”を受信更新リスト２４２の更新データに登録すると共に、受信更新テーブルリスト２４４におけるテーブルＢの更新回数をインクリメントして１とする。このように、レプリケーション処理部１３０とレプリケーション処理部２３０との間では、例えば、相手方のＤＢへの格納が完了したことを通知された後に、次の更新データを送信するといった規則でデータ送信が行われる。
　図６は、図５に例示した場面の後、レプリケーション処理部２３０によってＤＢ２００が更新された場面を例示した図である。レプリケーション処理部２３０は、受信更新リスト２４２に登録されていた、テーブルＢに関する更新データ“Inset into A values (2)”に基づいて、ＤＢ２２０を更新し、受信更新テーブルリスト２４４のテーブルＢの更新回数をデクリメントして０とする。これによって、ＤＢ１２０とＤＢ２２０との間で、全てのテーブルについて同期が完了した状態となる。データベースシステム１は、このような一連の動作を繰り返し実行し、非同期レプリケーションを継続する。
　［処理内容：スイッチオーバー時］
　以下、スイッチオーバー時の処理について説明する。図７～１４は、スイッチオーバー時におけるステージシステム１の動作を説明するための図である。
　以下、時系列に場面を例示して説明する。図７は、スイッチオーバー要求を受け付けた場面を例示した図である。スイッチオーバー要求（役割変更要求の一例）は、クライアント３００以外の機器（キーボードやマウスなどの入力デバイスを含む）から受け付けられてもよいし、クライアント３００から受け付けられてもよい。また、スイッチオーバー要求は、より上位のデータベースシステムから受け付けられてもよい。この場面において、送信更新リスト１４１には、テーブルＢに関する更新データ“Inset into B values (3)”および“Inset into B values (4)”が登録されている。ＤＢ１２０には、これらの双方が反映済であり、テーブルＢには、後に受け付けた要求である“Inset into B values (4)”に基づいて「４」が格納されている。また、送信更新テーブルリスト１４３には、テーブルＢの更新回数として２が登録されている。
　図８は、図７に例示した場面の後の場面を例示した図である。ＤＢ管理部１１０は、ＤＢリンクＤＬを介してＤＢ管理部２１０に、スイッチオーバー通知を行う。ＤＢ管理部２１０は、以降、自身がクライアント３００からの要求を受け付ける旨の通知をクライアント３００に対して行う。
　また、ＤＢ管理部１１０は、レプリケーション処理部１３０に対して、スイッチオーバーに伴い、送信更新テーブルリスト１４３に登録された情報の全てをレプリケーション処理部２３０に送信するように指示する。レプリケーション処理部１３０は、送信更新テーブルリスト１４３に登録された情報の全てをレプリケーション処理部２３０に送信すると共に、送信更新テーブルリスト１４３に登録された情報をリセット（削除、消去、あるいは無効化）する。レプリケーション処理部２３０は、レプリケーション処理部１３０から受信した情報を、受信更新テーブルリスト２４４に登録する。
　図９は、図８に例示した場面の後、ＤＢ管理部２１０によって、クライアント３００からテーブルＡに「６」を格納する更新要求と、テーブルＢに「７」を格納する更新要求とが受け付けられた場面を例示した図である。この場合、ＤＢ管理部２１０は、それぞれの要求に係るテーブルが未同期であるか否かを判定する。例えば、ＤＢ管理部２１０は、受信更新テーブルリスト２４４における当該テーブルの更新回数がゼロでなければ未同期であり、ゼロであれば同期済であると判定する。
　ＤＢ管理部２１０は、要求が同期済のテーブルに関するものであれば、自身のＤＢ２２０に格納すると共に送信更新リスト２４１および送信更新テーブルリスト２４３に当該テーブルの情報を登録する。図９の例では、ＤＢ管理部２１０は、同期済のテーブルＡについては自身のＤＢ２２０に「６」を格納すると共に送信更新リスト２４１に更新データ“Insert into A values(6)”を登録し、送信更新テーブルリスト２４３のテーブルＡの更新回数をインクリメントして１とする。
　一方、ＤＢ管理部２１０は、要求が未同期のテーブルに関するものであれば、ＤＢリンクＤＬを介してＤＢ管理部１１０に要求（或いは要求を解釈した結果）を転送すると共に、受信更新リスト２４２に要求を解釈した結果を登録する。この際に、ＤＢ管理部２１０は、登録した結果に対してフラグ１を設定し、且つ、更新の順序性を保つためＤＢ２２０を更新しない。このように、受信更新リスト１４２および受信更新リスト２４２におけるフラグは、スイッチオーバーを開始してから完了するまでの間に、未同期のテーブルについて受け付けられた要求に基づくものであることを示すフラグである。図９の例では、ＤＢ管理部２１０は、未同期のテーブルＢについては、受信更新リスト２４２に更新データ“Insert into B values(7)”を登録してフラグを１に設定し、受信更新テーブルリスト２４４のテーブルＢの更新回数をインクリメントして３とする。
　未同期のテーブルに関する要求を受けたＤＢ管理部１１０は、ＤＢ１２０のテーブルＢに「７」を格納する。この場合、ＤＢ管理部１１０は、スイッチオーバー中の要求転送であることを認識しているため、ＤＢ１２０を更新するが、送信更新リスト１４１および送信更新テーブルリスト１４３の更新は行わない。
　なお、更新要求以外の要求、例えば読み出し要求を受け付けた場合も、同様の振り分けが行われる。すなわち、ＤＢ管理部２１０は、読み出し要求が未同期のテーブルに関するものであれば、ＤＢリンクＤＬを介してＤＢ管理部１１０に要求（或いは要求を解釈した結果）を転送すると共にＤＢ管理部１１０により返信された結果をクライアント３００に返し、同期済のテーブルに関するものであれば、ＤＢ２２０から読み出してクライアント３００に結果を返す。
　図１０は、図９に例示した場面の後、レプリケーション処理部１３０によって送信更新リスト１４１のうちテーブルＢに関する更新データ“Inset into B values (3)”がレプリケーション処理部２３０に送信され、レプリケーション処理部２３０によって受信更新リスト２４２が更新された場面を例示した図である。図示するように、レプリケーション処理部２３０は、受信更新リスト２４２に“Insert into B values(3)”を登録してフラグを０に設定する。
　図１１は、図１０に例示した場面の後、レプリケーション処理部２３０によってＤＢ２２０が更新され、更に、レプリケーション処理部１３０によって送信更新リスト１４１のうちテーブルＢに関する更新データ“Inset into B values (4)”と、送信更新テーブルリスト１４３のうちテーブルＢに関する情報とがレプリケーション処理部２３０に送信され、レプリケーション処理部２３０によって受信更新リスト２４２および受信更新テーブルリスト２４４が更新された場面を例示した図である。図示するように、レプリケーション処理部２３０は、ＤＢ２２０のテーブルＢに「３」を格納し、受信更新テーブルリスト２４４のテーブルＢの更新回数をデクリメントして２とする。ここで、レプリケーション処理部２３０は、フラグがゼロである更新データを先にＤＢ２２０に格納する。これによって、更新処理の順序性が維持される。次いで、レプリケーション処理部２３０は、受信更新リスト２４２に“Inset into B values (4)”を登録する。
　なお、図１１に示した旧マスター側から新マスター側に送信更新リストの情報を送信する処理は、新マスター側に読み出し要求または更新要求がなされたテーブルから順に行われてもよい。また、図１２に示した新マスター側で旧マスター側からの送信更新リストに基づいてＤＢを更新する処理も、新マスター側に読み出し要求または更新要求がなされたテーブルから順に行われてもよい。
　図１２は、図１１に例示した場面の後、レプリケーション処理部２３０によってＤＢ２２０が更新され、受信更新リスト２４２および受信更新テーブルリスト２４４が更新された場面を例示した図である。図示するように、レプリケーション処理部２３０は、ＤＢ２２０のテーブルＢに「４」を格納し、受信更新テーブルリスト２４４のテーブルＢの更新回数をデクリメントして１とする。ここでも、レプリケーション処理部２３０は、フラグがゼロである更新データを先にＤＢ２２０に格納する。
　図１３は、図１２に例示した場面の後、レプリケーション処理部２３０によってＤＢ２２０が更新され、受信更新リスト２４２および受信更新テーブルリスト２４４が更新された場面を例示した図である。図示するように、レプリケーション処理部２３０は、テーブルＢについてフラグがゼロである更新データが無くなったため、フラグが１である更新データに基づいてＤＢ２２０を更新する。レプリケーション処理部２３０は、ＤＢ２２０のテーブルＢに「７」を格納し、受信更新テーブルリスト２４４のテーブルＢの更新回数をデクリメントして０とする。なお、この場面の処理はＤＢ管理部２１０によって行われてもよい。
　スイッチオーバー開始後に送信更新リスト２４１に登録された、スイッチオーバー開始時点では同期済のテーブルＡについての更新データ“Insert into A (6)”は、図１１～図１３で例示した場面の後、あるいはそれらの間の任意のタイミングで、通常時と同じように第１ＤＢサーバ１００に送信され、ＤＢ１２０に反映される。図１４は、テーブルＡの同期が完了した場面を例示した図である。これによって、未同期データの同期が完了する。未同期データの同期の完了は、例えば、新たにマスターＤＢとなった方のＤＢ管理部２１０によって判断され、旧マスターＤＢのＤＢ管理部１１０に通知される。未同期データの同期が完了すると、通常時の処理に戻る。なお、図１３に示すように、スイッチオーバー開始時点で存在していた未同期データの同期が完了したことをもって、未同期データの同期が完了したと判断してもよい。
　［処理フロー］
　以下、スイッチオーバー時におけるデータベースシステム１における処理の流れについて説明する。ここでは、第１ＤＢサーバ１００が旧マスターＤＢであり、第２ＤＢサーバ２００が新マスターＤＢであるものとして説明するが、逆の場合もあり得る。
　図１５は、第１ＤＢサーバ１００のＤＢ管理部１１０およびレプリケーション処理部１３０により実行される処理の流れの一例を示すフローチャートである。本フローチャートの処理は、ＤＢ管理部１１０がスイッチオーバー要求を受け付けたときに開始される。
　まず、ＤＢ管理部１１０が、スイッチオーバーする旨の情報を新しくマスターＤＢとなるＤＢ２００のＤＢ管理部２１０に通知する（ステップＳ１００）。次に、レプリケーション処理部１３０が、送信更新テーブルリスト１４３に登録された情報を一括してレプリケーション処理部２３０に送信する（ステップＳ１０２）。
　次に、ＤＢ管理部１１０が、ＤＢリンクＤＬを介して更新要求があったか否かを判定する（ステップＳ１０４）。ＤＢリンクＤＬを介して更新要求があった場合、ＤＢ管理部１１０が、ＤＢ１２０を更新する（ステップＳ１０６）。なお、ステップＳ１０６において更新リストモジュール１４０の更新は行わない。
　次に、レプリケーション処理部１３０が、送信更新リスト１４１に更新データが存在するか否かを判定する（ステップＳ１０８）。送信更新リスト１４１に更新データが存在する場合、レプリケーション処理部１３０は、レプリケーションリンクＲＬを介して更新データを送信可能な状態であるか否かを判定する（ステップＳ１１０）。送信可能な状態でない場合、ステップＳ１０４に処理が戻される。送信可能な状態でない場合とは、例えば、先に送信した更新データに関してレプリケーション処理部２３０から、ＤＢ２２０への反映を完了した旨の通知を受けていない場合、或いは、レプリケーションリンクＲＬが通信に使用されている最中である場合などである。一方、送信可能な状態である場合、レプリケーション処理部１３０は、レプリケーションリンクＲＬを介して、更新データのうち登録されたタイミングの最も早いものをレプリケーション処理部２３０に送信し、送信更新リスト１４１から送信した更新データを削除する（ステップＳ１１２）。
　そして、ＤＢ管理部１１０は、未同期データの同期が完了したか否かを判定する（ステップＳ１１４）。未同期データの同期が完了していないと判定された場合、ステップＳ１０４に処理が戻され、未同期データの同期が完了したと判定された場合、本フローチャートの処理が終了する。なお、ＤＢ管理部１１０は、例えば、ＤＢリンクＤＬを介してＤＢ管理部２１０から受信される通知情報に基づいて、未同期データの同期が完了したか否かを判定する。
　図１６は、第２ＤＢサーバ２００のＤＢ管理部２１０およびレプリケーション処理部２３０により実行される処理の流れの一例を示すフローチャートである。本フローチャートの処理は、ＤＢ管理部２１０がスイッチオーバー通知（図１５のステップＳ１００の通知）を受けた受け付けたときに開始される。
　まず、ＤＢ管理部２１０は、スイッチオーバーする旨をクライアント３００に通知する（ステップＳ２００）。次に、レプリケーション処理部２３０が、レプリケーション処理部１３０から、第１ＤＢサーバ１００の送信更新テーブルリスト１４３の情報を一括して受信し、受信更新テーブルリスト２４４に登録する（ステップＳ２０２）。
　次に、ＤＢ管理部２１０は、クライアント３００から更新要求を受け付けたか否かを判定する（ステップＳ２０４）。クライアント３００から更新要求を受け付けたと判定した場合、ＤＢ管理部２１０は、更新要求の対象が未同期のテーブルであるか否かを判定する（ステップＳ２０６）。更新要求の対象が未同期のテーブルでないと判定した場合、ＤＢ管理部２１０は、自身（第２ＤＢサーバ２００）のＤＢ２２０を更新し、更新内容を更新リストモジュール２４０に登録する（ステップＳ２０８）。
　一方、更新要求の対象が未同期のテーブルであると判定した場合、ＤＢ管理部２１０は、ＤＢリンクＤＬを介して旧マスターＤＢである第１ＤＢサーバ１００のＤＢ管理部１１０に更新要求を転送する（ステップＳ２１０）。そして、ＤＢ管理部２１０は、更新要求を自身の更新リストモジュール２４０に登録する（ステップＳ２１２）。
　次に、レプリケーション処理部２３０は、旧マスターＤＢである第１ＤＢサーバ１００のレプリケーション処理部１３０から更新データを受信したか否かを判定する（ステップＳ２１４）。レプリケーション処理部１３０から更新データを受信した場合、レプリケーション処理部２３０は、更新リストモジュール１４０に更新データなどの情報を登録する（ステップＳ２１６）。次に、レプリケーション処理部２３０は、ＤＢ２２０を更新可能であるか否かを判定する（ステップＳ２１８）。ＤＢ２２０を更新可能であると判定した場合、レプリケーション処理部２３０は、更新リストモジュール２４０の内容に基づいてＤＢ２２０を更新する（ステップＳ２２０）。ＤＢを更新可能でない場合とは、例えば、ＤＢ管理部２１０によってＤＢ２２０の更新が行われている最中である場合である。
　次に、ＤＢ管理部２１０は、未同期データの同期が完了したか否かを判定する（ステップＳ２２２）。未同期データの同期が完了していないと判定された場合、ステップＳ２０４に処理が戻される。一方、未同期データの同期が完了したと判定された場合、ＤＢ管理部２１０は、旧マスターＤＢである第１ＤＢサーバ１００のＤＢ管理部１１０に完了通知を行う（ステップＳ２２４）。ＤＢ管理部２１０は、例えば、第１ＤＢサーバ１００との通信により更新リストモジュール１４０および２４０の全ての情報がリセットされているか否かを判定し、全ての情報がリセットされていることが確認された場合に、未同期データの同期が完了したと判定する。
　以上説明した処理によれば、スイッチオーバーの実行時に、より迅速にクライアントに応答することができる。
　図１７は、比較例のデータベースシステムにおいてスイッチオーバー実行時に行われる処理の流れを模式的に示す図である。比較例のデータベースシステムでは、スイッチオーバー（図中、ＳＯ）発生時に未同期データが旧マスターにある場合、未同期データを転送し、未同期データを新マスターのメモリに格納し、更に、未同期データを新マスターのＤＢに格納してからスイッチオーバーが完了する。この処理の中で、未同期データをＤＢに格納する処理の時間が支配的であり、例えば、数［ｓｅｃ］～数十［ｓｅｃ］といったオーダーでスイッチオーバー完了までの時間がかかる場合がある。
　図１８は、実施形態のデータベースシステム１においてスイッチオーバー実行時に行われる処理の流れを模式的に示す図である。実施形態のデータベースシステム１では、スイッチオーバーが発生すると、まず送信更新テーブルリストが旧マスターから新マスターに送信され、新マスターは、受信した送信更新テーブルリストを受信更新テーブルリストとして保持する。この時点でスイッチオーバーは完了する。実施形態では、スイッチオーバー完了までの間にＤＢの更新処理は必要でなく、例えば、１［ｓｅｃ］未満のオーダーで処理が完了することが見込まれる。そして、新マスターは、受信更新テーブルリストを参照しながらクライアントからの要求を自身または旧マスターに振り分け、データベースシステム１の原則全てのテーブルについて、クライアントからの要求に迅速に応じることができる。
　［三以上のＤＢサーバを備える場合］
　なお、以上の説明では、データベースシステムは、二つのＤＢサーバを備えるものとして説明したが、データベースシステムは、三つ以上のＤＢサーバを備えてもよい。図１９は、三つ以上のＤＢサーバを備えるデータベースシステム２の概略図である。図では、第１ＤＢサーバ１００Ａと、第２ＤＢサーバ２００Ａと、一以上の第ｎＤＢサーバ４００Ａ（ｎは３以上の自然数）とを備えるデータベースシステム２を示している。それぞれのＤＢサーバは、ＤＢ管理部と、ＤＢと、更新リストモジュールと、レプリケーション処理部とを備える。
　以下、第１ＤＢサーバ１００Ａが旧マスターＤＢであり、第２ＤＢサーバ２００Ａが新マスターＤＢ、第ｎＤＢサーバ４００Ａはスイッチオーバーの前後を通じてスレーブＤＢであるものとする。図２０は、データベースシステム２においてスイッチオーバーが開始された場面を示す図である。第１ＤＢサーバ１００Ａは、スイッチオーバーが開始されたとき、送信更新テーブルリストを第２ＤＢサーバ２００Ａに送信する。図２１は、データベースシステム２においてスイッチオーバーが完了した後の場面を示す図である。図示するように、ＤＢ管理部２１０Ａは、未同期テーブルに対する要求を第１ＤＢサーバ１００Ａに転送する。レプリケーション処理部１４０Ａは、更新リストモジュール１３０Ａに登録された未同期データ（更新データ）を第２ＤＢサーバ２００Ａおよび第ｎＤＢサーバ４００Ａに送信する。また、レプリケーション処理部２４０Ａは、スイッチオーバー完了後、同期完了までの間に発生した未同期データを第１ＤＢサーバ１００Ａおよび第ｎＤＢサーバ４００Ａに送信する。これによって、二つのＤＢサーバを備える場合と同様のスイッチオーバーが実現される。
　以上説明した少なくともひとつの実施形態によれば、自データベースサーバが、クライアントからの要求を受け付ける第１の状態である場合、前記クライアントからの要求に応じてデータベースを更新し、前記要求に基づき前記複数のデータベースサーバに含まれる他のデータベースサーバに当該他のデータベースサーバのデータベースを更新させるための更新データと、データの管理単位ごとの前記更新データの管理情報とをメモリに登録するデータベース管理部と、自データベースサーバが、前記第１の状態である場合、前記メモリに登録された更新データを前記他のデータベースサーバに送信する同期処理部と、を備え、自データベースサーバが、役割変更指示に応じて前記第１の状態から第２の状態に遷移するとき、前記同期処理部は、前記メモリに登録された前記管理情報を前記他のデータベースサーバに送信し、自データベースサーバが、前記第２の状態である場合、前記同期処理部は、前記メモリに登録された更新データを前記他のデータベースサーバに送信し、自データベースサーバが、前記第２の状態から遷移する第３の状態である場合、前記同期処理部は、前記複数のデータベースサーバに含まれる他のデータベースサーバから受信した更新データに基づいて前記データベースを更新する。これによって、スイッチオーバー実行時に、より迅速にクライアントに応答することができる。
　なお、上記実施形態では、レプリケーション処理部が通常時とスイッチオーバー時との双方において処理を実行するものとしたが、データベースシステムは、通常時には起動せず、スイッチオーバー時に起動して上記レプリケーション処理部と同様の処理を行う機能部を備えてもよい。前者の場合、レプリケーション処理部が「同期処理部」の一例であり、後者の場合、レプリケーション処理部と、その機能部とを合わせたものが「同期処理部」の一例である。
　また、マスターＤＢである状態が第１の状態に相当し、マスターＤＢからスレーブＤＢに切り替わってスイッチオーバーが完了するまでの状態が第２の状態に相当し、スレーブＤＢである状態が第３の状態に相当し、スレーブＤＢからマスターＤＢに切り替わってスイッチオーバーが完了するまでの状態が第４の状態に相当する。
　本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

Claims (10)

  1. 　複数のデータベースサーバを備えるデータベースシステムに含まれるデータベースサーバであって、
    　自データベースサーバが、クライアントからの要求を受け付ける第１の状態である場合、前記クライアントからの要求に応じてデータベースを更新し、前記要求に基づき前記複数のデータベースサーバに含まれる他のデータベースサーバに当該他のデータベースサーバのデータベースを更新させるための更新データと、データの管理単位ごとの前記更新データの管理情報とをメモリに登録するデータベース管理部と、
    　自データベースサーバが、前記第１の状態である場合、前記メモリに登録された更新データを前記他のデータベースサーバに送信する同期処理部と、を備え、
    　自データベースサーバが、役割変更指示に応じて前記第１の状態から第２の状態に遷移するとき、前記同期処理部は、前記メモリに登録された前記管理情報を前記他のデータベースサーバに送信し、
    　自データベースサーバが、前記第２の状態である場合、前記同期処理部は、前記メモリに登録された更新データを前記他のデータベースサーバに送信し、
    　自データベースサーバが、前記第２の状態から遷移する第３の状態である場合、前記同期処理部は、前記複数のデータベースサーバに含まれる他のデータベースサーバから受信した更新データに基づいて前記データベースを更新する、
    　データベースサーバ。
  2. 　自データベースサーバが、前記第２の状態である場合、前記データベース管理部は、前記他のデータベースサーバから受信される要求に基づいて前記データベースを更新し、前記更新データと前記管理情報とを更新しない、
    　請求項１記載のデータベースサーバ。
  3. 　自データベースサーバが、前記役割変更指示に応じて前記第３の状態から遷移する第４の状態である場合、前記データベース管理部は、前記他のデータベースサーバから受信した前記管理情報を参照し、前記クライアントからの要求が、前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する要求であるか否かを判定し、前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する要求である場合に、前記他のデータベースサーバに、前記要求に基づく情報を送信する、
    　請求項１または２記載のデータベースサーバ。
  4. 　自データベースサーバが、前記第４の状態である場合、
    　前記データベース管理部は、前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する要求に基づく更新データをメモリに登録し、
    　前記データベース管理部または前記同期処理部は、前記他のデータベースサーバから前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する更新データを受信して自データベースサーバのデータベースを更新した後に、前記メモリに登録した更新データを自データベースサーバのデータベースに反映させる、
    　請求項３記載のデータベースサーバ。
  5. 　複数のデータベースサーバを備えるデータベースシステムに含まれるデータベースサーバであって、
    　自データベースサーバが、クライアントからの要求を受け付けない第３の状態である場合、前記複数のデータベースサーバに含まれる他のデータベースサーバから受信した更新データに基づいてデータベースを更新する同期処理部と、
    　自データベースサーバが、役割変更指示に応じて前記第３の状態から遷移する第４の状態である場合、前記他のデータベースサーバから受信した管理情報を参照し、前記クライアントからの要求が、前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースおいて更新されていない管理単位に関する要求であるか否かを判定し、前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する要求である場合に、前記他のデータベースサーバに、前記要求に基づく情報を送信するデータベース管理部と、
    　を備えるデータベースサーバ。
  6. 　自データベースサーバが、前記第４の状態である場合、
    　前記データベース管理部は、前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する要求に基づく更新データをメモリに登録し、
    　前記データベース管理部または前記同期処理部は、前記他のデータベースサーバから前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する更新データを受信して自データベースサーバのデータベースを更新した後に、前記メモリに登録した更新データを自データベースサーバのデータベースに反映させる、
    　請求項５記載のデータベースサーバ。
  7. 　複数のデータベースサーバを備えるデータベースシステムに含まれるデータベースサーバが、
    　自データベースサーバが、クライアントからの要求を受け付ける第１の状態である場合、
    　　前記クライアントからの要求に応じてデータベースを更新し、
    　　前記要求に基づき前記複数のデータベースサーバに含まれる他のデータベースサーバに当該他のデータベースサーバのデータベースを更新させるための更新データと、データの管理単位ごとの前記更新データの管理情報とをメモリに登録し、
    　　前記メモリに登録された更新データを前記他のデータベースに送信し、
    　自データベースサーバが、役割変更指示に応じて前記第１の状態から第２の状態に遷移するとき、
    　　前記メモリに登録された前記管理情報を前記他のデータベースサーバに送信し、
    　自データベースサーバが、前記第２の状態である場合、
    　　前記メモリに登録された更新データを前記他のデータベースサーバに送信し、
    　自データベースサーバが、前記第２の状態から遷移する第３の状態である場合、
    　　前記複数のデータベースサーバに含まれる他のデータベースサーバサーバから受信した更新データに基づいて前記データベースを更新する、
    　データベース管理方法。
  8. 　複数のデータベースサーバを備えるデータベースシステムに含まれるデータベースサーバが、
    　自データベースサーバが、クライアントからの要求を受け付けない第３の状態である場合、
    　　前記複数のデータベースサーバに含まれる他のデータベースサーバから受信した更新データに基づいてデータベースを更新し、
    　自データベースサーバが、役割変更指示に応じて前記第３の状態から遷移する第４の状態である場合、
    　　前記他のデータベースサーバから受信した管理情報を参照し、前記クライアントからの要求が、前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースおいて更新されていない管理単位に関する要求であるか否かを判定し、
    　　前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する要求である場合に、前記他のデータベースサーバに、前記要求に基づく情報を送信する、
    　データベース管理方法。
  9. 　複数のデータベースサーバを備えるデータベースシステムに含まれるデータベースサーバに、
    　自データベースサーバが、クライアントからの要求を受け付ける第１の状態である場合、
    　　前記クライアントからの要求に応じてデータベースを更新させ、
    　　前記要求に基づき前記複数のデータベースサーバに含まれる他のデータベースサーバに当該他のデータベースサーバのデータベースを更新させるための更新データと、データの管理単位ごとの前記更新データの管理情報とをメモリに登録させ、
    　　前記メモリに登録された更新データを前記他のデータベースに送信させ、
    　自データベースサーバが、役割変更指示に応じて前記第１の状態から第２の状態に遷移するとき、
    　　前記メモリに登録された前記管理情報を前記他のデータベースサーバに送信させ、
    　自データベースサーバが、前記第２の状態である場合、
    　　前記メモリに登録された更新データを前記他のデータベースに送信させ、
    　自データベースサーバが、前記第２の状態から遷移する第３の状態である場合、
    　　前記複数のデータベースサーバに含まれる他のデータベースサーバから受信した更新データに基づいて前記データベースを更新させる、
    　プログラムを記憶した記憶媒体。
  10. 　複数のデータベースサーバを備えるデータベースシステムに含まれるデータベースサーバが、
    　自データベースサーバが、クライアントからの要求を受け付けない第３の状態である場合、
    　　前記複数のデータベースサーバに含まれる他のデータベースサーバから受信した更新データに基づいてデータベースを更新させ、
    　自データベースサーバが、役割変更指示に応じて前記第３の状態から遷移する第４の状態である場合、
    　　前記他のデータベースサーバから受信した管理情報を参照し、前記クライアントからの要求が、前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースおいて更新されていない管理単位に関する要求であるか否かを判定させ、
    　　前記他のデータベースサーバのデータベースにおいて更新され且つ自データベースサーバのデータベースにおいて更新されていない管理単位に関する要求である場合に、前記他のデータベースサーバに、前記要求に基づく情報を送信させる、
    　プログラムを記憶した記憶媒体。
PCT/JP2018/008667 2017-06-20 2018-03-07 データベースサーバ、データベース管理方法、および記憶媒体 WO2018235348A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/082,771 US11269922B2 (en) 2017-06-20 2018-03-07 Database server, database management method, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017-120318 2017-06-20
JP2017120318A JP6553125B2 (ja) 2017-06-20 2017-06-20 データベースサーバ、データベース管理方法、およびプログラム

Publications (1)

Publication Number Publication Date
WO2018235348A1 true WO2018235348A1 (ja) 2018-12-27

Family

ID=64736062

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/008667 WO2018235348A1 (ja) 2017-06-20 2018-03-07 データベースサーバ、データベース管理方法、および記憶媒体

Country Status (3)

Country Link
US (1) US11269922B2 (ja)
JP (1) JP6553125B2 (ja)
WO (1) WO2018235348A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002183088A (ja) * 2000-12-15 2002-06-28 Hitachi Ltd オンラインシステム回復方法及びその実施装置並びにその処理プログラムを記録した記録媒体
JP2015191451A (ja) * 2014-03-28 2015-11-02 富士通株式会社 情報処理装置、制御方法および制御プログラム
JP2017097791A (ja) * 2015-11-27 2017-06-01 株式会社三菱東京Ｕｆｊ銀行 データ処理装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4582297B2 (ja) 2004-06-25 2010-11-17 日本電気株式会社 レプリケーションシステム、装置、方法、およびプログラム
US7475281B2 (en) * 2005-03-10 2009-01-06 International Business Machines Corporation Method for synchronizing replicas of a database
US9239767B2 (en) * 2008-12-22 2016-01-19 Rpx Clearinghouse Llc Selective database replication
US10747776B2 (en) * 2012-12-04 2020-08-18 International Business Machines Corporation Replication control using eventually consistent meta-data
US10282433B1 (en) * 2015-11-17 2019-05-07 Quintiles Ims Incorporated Management of database migration

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002183088A (ja) * 2000-12-15 2002-06-28 Hitachi Ltd オンラインシステム回復方法及びその実施装置並びにその処理プログラムを記録した記録媒体
JP2015191451A (ja) * 2014-03-28 2015-11-02 富士通株式会社 情報処理装置、制御方法および制御プログラム
JP2017097791A (ja) * 2015-11-27 2017-06-01 株式会社三菱東京Ｕｆｊ銀行 データ処理装置

Also Published As

Publication number Publication date
JP6553125B2 (ja) 2019-07-31
JP2019003584A (ja) 2019-01-10
US11269922B2 (en) 2022-03-08
US20200110760A1 (en) 2020-04-09

Similar Documents

Publication Publication Date Title
US11120044B2 (en) System and method for maintaining a master replica for reads and writes in a data store
US11388043B2 (en) System and method for data replication using a single master failover protocol
US10929240B2 (en) System and method for adjusting membership of a data replication group
US9983957B2 (en) Failover mechanism in a distributed computing system
US11893264B1 (en) Methods and systems to interface between a multi-site distributed storage system and an external mediator to efficiently process events related to continuity
US10248704B2 (en) System and method for log conflict detection and resolution in a data store
US9489434B1 (en) System and method for replication log branching avoidance using post-failover rejoin
US8930312B1 (en) System and method for splitting a replicated data partition
JP5952960B2 (ja) 計算機システム、計算機システム管理方法及びプログラム
JP5724735B2 (ja) データベース更新制御装置、データベース管理システムおよびデータベース更新制御プログラム
US9367261B2 (en) Computer system, data management method and data management program
WO2012045245A1 (zh) 一种保持数据一致性的方法及系统
WO2015196692A1 (zh) 一种云计算系统以及云计算系统的处理方法和装置
JP5416490B2 (ja) 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム
KR101696911B1 (ko) 분산 데이터 베이스 장치 및 그 장치에서의 스트림 데이터 처리 방법
JP6553125B2 (ja) データベースサーバ、データベース管理方法、およびプログラム
JP2010244117A (ja) レプリケーションシステム、マスタサーバ、レプリカサーバ、レプリケーション方法、及びプログラム
JP6291977B2 (ja) 分散ファイルシステム、バックアップファイル取得方法、制御装置及び管理装置
JP6404892B2 (ja) データベースシステムおよびデータ処理方法
US10860568B2 (en) External data source linking to queries in memory
JP2007018143A (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: 18820625

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18820625

Country of ref document: EP

Kind code of ref document: A1