JP2009252149A - Database replication method, and database management system, and program - Google Patents

Abstract

To start a slave server database by replication without degrading the processing performance of a master server update transaction.
A master server that receives a database replication request from a slave server starts acquisition of a new generation checkpoint file consisting of a snapshot of the database, and at the same time, updates the history information of the database update transaction. The history information file is also switched to the new generation, and the update transaction history information is sequentially transferred to the communication queue of the slave server 3A each time the update transaction is executed. The slave server 3A duplicates the checkpoint file and the update history information file of the previous generation in the master server 2, and sequentially reflects the history information of the update transaction in the communication queue in the database started from these files. .
[Selection] Figure 1

Description

  The present invention relates to a database replication technique. In particular, in a database management system that can acquire database backup files without stopping execution of database update transactions on the master server, the master server database is replicated to the slave server when the slave server database is started. Related to database replication technology.

  Database replication is to place a replica (replica) of a master server database on a plurality of slave servers on the network. This makes it possible to distribute the load on the master server database to the replica (replica) databases of multiple slave servers, and if the master server fails, the slave server has the replica (replica) database. It becomes possible to change to the master server and continue operation.

  By the way, there is a fuzzy checkpoint method as a method for acquiring a backup file of a database without stopping execution of a transaction for updating the database (see Non-Patent Document 1).

  If a checkpoint file (database snapshot) that is a database backup file is acquired without stopping the update transaction, the checkpoint file is acquired during the execution of the update transaction. Therefore, as illustrated in FIG. 4, there is a possibility that the database acquires the checkpoint file in an inconsistent state during the update transaction processing (a state in which the atomicity of the update transaction is not maintained).

  In the fuzzy checkpoint method, for example, in the case of the master server 5 shown in FIG. 5, the history information of the update transaction that occurred during the acquisition of the checkpoint file is stored in the update history information file in the backup storage unit. The database consistency is guaranteed by correcting and starting the database based on the history information of the update transaction stored in the update history information file when the database is started.

In addition, the database backup method of Patent Document 1 reduces the amount of update transaction history information output by the fuzzy checkpoint method, and secures storage areas for two generations of checkpoint files and update history information files. Thus, backup data can be acquired even if a system failure or a media failure occurs.
D. J. et al. Rosenkranz, “Dynamic database dumping”, in Proc. SIGMOD Int. Conf. Managent Data. ACM, 1978, pp. 3-8 Japanese Patent No. 3514332

  In order to start the database of the slave server 6 by replication in a state where data consistency is ensured, the checkpoint file and the update history information file obtained by the master server 5 are replicated to the slave server 6 by the fuzzy checkpoint method. This is possible by starting the database from the checkpoint file and the update history information file.

  However, since the master server 5 is in operation, update transactions always occur, update transaction history information is generated one after another, and an update history information file that stores update transaction history information is frequently updated. . In this situation, when the replication for starting the database of the slave server 6 is performed by the above method, the slave server 6 refers to the update history information file of the master server 5 for replication. Therefore, as shown in FIG. Update and reference conflicts will occur.

  Due to this conflict, a delay occurs in the process of writing the update transaction history information in the update history information file on the master server 5. This leads to a delay in the update transaction processing of the master server 5 and causes a problem that the update processing performance of the master server 5 deteriorates.

  Therefore, in the database replication method and the database management system for solving the above-described problem, the master server updates the checkpoint file with a generation one older than the generation in operation, triggered by a database replication request from the slave server. A history file is prepared and the slave server replicates these files for reference. As a result, there is no conflict between the update and reference of the same database file between the master server and the slave server.

  That is, in the database replication method for solving the above-described problem, the master server that has received a request for database replication from the slave server starts acquiring a new generation checkpoint file consisting of a snapshot of the database. At the same time when the checkpoint file acquisition starts, the update history information file that stores the history information of the update transaction of the database is also switched to a new generation. Further, the update transaction history information is updated when the checkpoint file acquisition starts. Each time it is executed, it also starts processing to sequentially transfer to the communication queue of the slave server, and after starting the acquisition of the checkpoint file, permission to start replication to the slave server And the slave server replicates the checkpoint file and the update history information file of the previous generation stored in the master server upon receipt of the notification of permission to start replication. A new database is started on the slave server from the file, and update transaction history information stored in the communication queue of the slave server arrives at the communication queue at the database started on the slave server. Reflect sequentially.

  In addition, a database management system for solving the problem includes a master server that can communicate with a plurality of slave servers, and the master server receives a request for database replication from any of the slave servers. Triggered the acquisition of a new generation checkpoint file consisting of a snapshot of the database, and at the same time this checkpoint file acquisition start, the update history information file that stores the history information of the database update transaction is also switched to the new generation, Furthermore, simultaneously with the start of the acquisition of the checkpoint file, a process of sequentially transferring update transaction history information to the communication queue of the slave server each time an update transaction is executed is started. After starting the acquisition of the int file, the slave server is notified of the replication start permission, and the slave server is triggered by the reception of the notification of the replication start permission, and the checkpoint of the one old generation stored in the master server The file and the update history information file are duplicated, a database is newly started on the slave server from these two files, and update transaction history information accumulated in the communication queue of the slave server is also stored on the slave server. Are sequentially reflected in the order of arrival in the communication queue in the database activated in step (b).

  According to the above database replication method and database management system, the contention is prevented and the synchronization of the databases of the master server and the slave server is ensured.

  In the database replication method, when another slave server is replicating the checkpoint file and the update history information file of the one old generation stored in the master server, or the checkpoint file of the new generation When the master server is acquiring, the master server waits for the completion of the replication and acquisition without starting acquisition of the newest generation checkpoint file even if it receives the database replication request notification. It is good to.

  Further, in the database management system, when a slave server other than any one of the slave servers is replicating the checkpoint file and the update history information file of an old generation stored in the master server, Alternatively, when the master server is acquiring the new generation checkpoint file, the master server receives the database replication request notification from any of the slave servers, and the master server checks the latest generation checkpoint file. It is preferable to wait for the completion of the duplication and acquisition without starting the acquisition.

  The conflict does not occur even if there are a plurality of slave servers.

  The functions of the database management system described above can also be realized by a computer and a program, which can be provided by recording the program on a recording medium or via a network. Examples of the program include a program for causing a computer to realize the functions of the master server and the slave server.

  Therefore, according to the above invention, it is possible to start the database of the slave server by replication without degrading the processing performance of the update transaction of the master server.

  FIG. 1 is a schematic configuration diagram of a database management system 1 according to an embodiment of the invention.

  The database management system 1 is configured by connecting one master server 2 and a plurality of slave servers 3 via a network 4. The master server 2 has a database management unit 21 and a backup storage unit 22. The slave server 3A has a database management unit 31A and a backup storage unit 32A. The slave server 3B has a database management unit 31B and a backup storage unit 32B. The number of slave servers connected to the master data of the data management system according to the invention is not limited to the number of slave servers disclosed in FIG.

  The database management units 21, 31A, 31B manage the database entity and output the database backup file to the backup storage units 22, 32A, 32B. Note that the database backup file is a checkpoint file that is a snapshot of the actual database, and an update history in which history information of update transactions since the start of the acquisition of the checkpoint file is written each time an update transaction is executed on the database. Consists of information files.

  The backup storage units 22, 32A, 32B hold the database backup files (checkpoint files, update history information files) output from the database management units 21, 31A, 31 in the storage area for the two most recent generations (2 sets). (For example, refer nonpatent literature 1 etc.). When the checkpoint file is output from the database management unit 21, 31A, 31B (when the backup generation is switched), the checkpoint file of the older generation of the two generations is overwritten. At this time, the update history information file is also switched to the old generation, and the update transaction history information is overwritten from the top of the file. Further, when the database of the slave servers 3A and 3B is activated, the database backup file stored in the backup storage unit 22 of the master server 2 is replicated to the backup storage units 32A and 32B of the slave servers 3A and 3B via the network 4. The slave servers 3A and 3B activate the databases of the database managers 31A and 31B based on the copied database backup file.

  An operation example of the database management system 1 will be described with reference to FIG.

  In the following example, the process flow is when the master server 2 and the slave server 3A are 1: 1. However, when there are two or more slave servers 3 (slave server 3) due to the waiting process of the master server 2 in step S2. 3A, 3B... Can also be replicated.

  In step S <b> 1, the slave server 3 </ b> A whose database is not activated issues a database replication start request notification to the master server 2.

  In step S2, when the master server 2 receives the data replication start request notification, for example, if the master server 2 is acquiring the nth generation checkpoint file, the slave server 3B is the n-1th generation. If the checkpoint file and the update history information file are being copied, or wait until both processes are completed. At this time, it is assumed that the latest generation of the database backup file of the master server 2 when the data replication start request notification is received is the nth generation.

  In step S3, acquisition of the (n + 1) th generation database backup file is started on the master server 2.

  In step S4, the master server 2 starts acquiring the (n + 1) th generation database backup file, and at the same time the update transaction history information storage destination (backup storage unit 32A) is also updated from the nth generation to the (n + 1) th generation update history information file. Change to

  In step S5, the master server 2 starts acquiring the (n + 1) th generation database backup file, and at the same time, starts a process of transferring the history information of the update transaction to the communication queue of the slave server 3A. The history information of update transactions executed thereafter is sequentially transferred to the communication queue of the slave server 3A.

  In step S6, the master server 2 notifies the slave server 3A of permission to start copying the nth generation checkpoint file and the update history information file.

  In step S7, the slave server 3A copies the nth generation checkpoint file and the nth generation update history information file received from the master server 2 to the slave server 3A.

  In step S8, the slave server 3A notifies the master server 2 of the completion of replication after the completion of the replication.

  In step S9, the slave server 3A activates the database using the copied nth generation checkpoint file and nth generation update history information file. At this time, the history information of the update transaction stored in the nth generation update history information file is reflected in the contents of the nth generation checkpoint file, and the database is started in a consistent state.

  In step S10, after the activation of the database is completed, the history information of the update transaction accumulated in the communication queue of the slave server 3A is reflected in the database of the slave server 3A in the order of arrival.

  In step S11, when the communication queue of the slave server 3A becomes empty, the synchronization of the databases of the master server 2 and the slave server 3A is completed. The process of transferring the update transaction history information from the master server 2 to the communication queue of the slave server 3A is continued, and the update transaction history information accumulated in the communication queue of the slave server 3A is reflected in the database of the slave server 3A. By continuing, the synchronization state of the databases of the master server 2 and the slave server 3A will be maintained in the future.

  As described above, in response to a request from the slave server 3A, the master server 2 is the nth generation checkpoint file and the nth generation update history information that is one generation older than the (n + 1) th generation of the latest generation currently in use (in operation). Files are prepared, and the slave server 3A duplicates these files. Therefore, as shown in FIG. 3, since the update and reference of the same file do not compete between the master server 2 and the slave server 3A, the processing performance of the update transaction of the master server 2 does not deteriorate.

  Also, when the master server 2 starts acquiring the (n + 1) th generation checkpoint file, the history information of the update transaction is transferred to the communication queue of the slave server 3A and reflected on the slave server 3A. Thereby, the database of the master server 2 and the database of the slave server 3A can be synchronized.

  Further, when the slave server 3B is replicating the nth generation checkpoint file and the nth generation update history information file received from the master server 2, or when the master server 2 is acquiring the (n + 1) th generation checkpoint file. Even if the master server 2 receives the database replication start request notification from the slave server 3A, the master server 2 does not start acquiring the n + 2 generation checkpoint file and waits for the completion of the replication and acquisition. As a result, even when there are a plurality of slave servers 3 (two or more), it is possible to replicate the database without causing conflict between the update of the same file and the reference.

  The functions of the master server 2 and the slave server 3 described above can also be realized by a computer and a program. The program can be stored in a known recording medium or provided through a network.

1 is a schematic configuration diagram of a database management system according to an embodiment of the invention. The flowchart explaining the operation example of the database management system which concerns on embodiment of invention. Explanatory drawing of the operation example of the database management system which concerns on embodiment of invention. The schematic explanatory drawing of the operation example of the database management system which does not use the fuzzy checkpoint method. Schematic explanatory drawing of the operation example of the database management system which concerns on a prior art.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Database management system 2 ... Master server 3, 3A, 3B ... Slave server 4 ... Network 21, 31A, 31B ... Database management part 22, 32A, 32B ... Backup storage part

Claims (5)

The master server that receives the database replication request from the slave server starts acquisition of a new generation checkpoint file consisting of a snapshot of the database, and updates the database simultaneously with the start of acquisition of the checkpoint file. The update history information file for storing the transaction history information is also switched to a new generation, and the update transaction history information is sequentially transferred to the communication queue of the slave server each time an update transaction is executed at the same time the acquisition of the checkpoint file is started. The process to transfer is also started, and after the start of the checkpoint file acquisition, the slave server is notified of the replication start permission,
The slave server, upon receipt of the notification of permission to start replication, replicates the checkpoint file and the update history information file of the previous generation stored in the master server, and from the two files, A new database is started on the slave server, and update transaction history information accumulated in the communication queue of the slave server is sequentially reflected on the database started on the slave server in the order of arrival in the communication queue. A database replication method characterized by: When the other slave server is replicating the checkpoint file and the update history information file of the previous generation stored in the master server, or the master server is acquiring the checkpoint file of the new generation If it is,
2. The master server according to claim 1, wherein the master server waits for the completion of replication and acquisition without starting acquisition of a checkpoint file of the newest generation even when receiving a request notification of the database replication. Database replication method. A master server that can communicate with multiple slave servers
When the master server receives a request for database replication from any of the slave servers, the master server starts acquiring a new generation checkpoint file consisting of a snapshot of the database in response to the request, and starts acquiring this checkpoint file. At the same time, the update history information file for storing the history information of the update transaction of the database is also switched to a new generation, and the update transaction history information is updated each time an update transaction is executed at the same time as the checkpoint file acquisition starts. Start the process of transferring to the server communication queue, notify the slave server to start replication after starting the checkpoint file acquisition,
The slave server, upon receipt of the notification of permission to start replication, replicates the checkpoint file and the update history information file of the previous generation stored in the master server, and from the two files, A new database is started on the slave server, and update transaction history information accumulated in the communication queue of the slave server is sequentially reflected on the database started on the slave server in the order of arrival in the communication queue. A database management system characterized by When a slave server other than any one of the slave servers is replicating the checkpoint file and the update history information file of the previous generation stored in the master server, or the master server is of the new generation If you are getting a checkpoint file,
The master server waits for the completion of the replication and acquisition without starting acquisition of the newest generation checkpoint file even if the master server receives the database replication request notification from any of the slave servers. The database management system according to claim 3.   A program for causing a computer to realize the functions of the master server and the slave server according to claim 3 or 4.

Images