JP2015153285A - Redundancy database system, database device, and master changing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent redundancy from being lost.SOLUTION: An each database device includes: a flag storage part 11 which, when it is a master, stores a completion flag storing whether or not submission of a replication request to a slave database device is completed in exchanging masters; transmission means 14 which, when the master is changed to a slave, transmits data of the completion flag to a database device to become a master anew; and means which, when the slave is changed to the master, determines whether or not synchronization is completed by transmitting all data stored to its own device or without transmitting any with respect to a replication start request from the slave database device on the basis of data of the completion flag received from the former master database device.

Description

  The present invention relates to a redundant database system having a plurality of databases, a database apparatus, and a master replacement method for replacing a master in a redundant database system.

  There is a redundant database system in which one of a plurality of database devices (DB devices) is a master and the other is a slave, and the same data is stored between the DB devices. The redundant database system is characterized by high data storage reliability because data is stored in another DB device even if one of the DB devices fails.

  In such a redundant database system, in order to improve the reliability of data storage, a data synchronization method is important, and various methods have been proposed (for example, see Patent Document 1). Patent Document 1 proposes a technique for shortening the time for data synchronization using differential replication when the slave and master DB devices are temporarily disconnected.

  In the redundant database system, data synchronization between the master and the slave is lost. In addition to the case where the slave and the master DB device are disconnected as described in Patent Document 1, the master is changed due to a failure of the master or the like. There is a case to do. When a master change occurs due to a master failure or the like, it may be difficult to ensure that data stored in the old slave DB device is synchronized with data stored in the old master DB device. One of the simplest solutions for synchronizing data between the new master and the old master or between the new master and the slave is to replicate the data of the new master to all slaves.

JP2013-171383A

  As described above, when the master is changed due to the occurrence of a failure or the like, the simplest method for performing data synchronization between the new master and other slaves is a method of replicating all cases to all slaves. However, the data stored in each slave DB device is not completed while all slave replication is performed in each slave DB device, and these data are not replicas. Therefore, the redundancy database system is in a state where redundancy is lost during replication.

  If a failure occurs in the master DB device in a state in which the redundancy is lost in the redundancy database system, there is a risk that data will be completely lost in the redundancy database system. Therefore, it is preferable to shorten the time in which the redundancy is lost as much as possible.

  In view of the above problems, an object of the present invention is to prevent the possibility of loss of redundancy in a redundant data system.

  In order to achieve the above object, a redundant database system according to the present invention stores data synchronously in a plurality of database devices, and any one database device is set as a master, and other database devices are slaves. When each database device is a master, the data update process in the old master database device and the replication request to the slave database device are all completed when the master device is replaced. A flag storage unit that stores a completion flag that identifies whether or not the transmission has been performed, a transmission unit that newly transmits data of the completion flag to the database device that becomes the master when changing from the master to the slave, and a change from the slave to the master The completion flag received from the old master database device. In response to the replication start request from the slave database device, there is provided means for determining whether to transmit all data stored in the own device or to complete the synchronization without transmitting any data. It is characterized by that.

  According to the present invention, unnecessary all-case replication can be prevented after the master is changed in the redundant database system, and the possibility of loss of redundancy can be prevented.

FIG. 1 is a schematic diagram illustrating a redundant database system. FIG. 2 is a sequence diagram for explaining a general replication process in the redundant database system. FIG. 3 is a sequence diagram for explaining a general master change process in the redundant database system. FIG. 4 is a schematic diagram illustrating the redundant database system according to the embodiment. FIG. 5 is a sequence diagram illustrating an example of a master replacement process in the redundant database system according to the embodiment. FIG. 6 is a sequence diagram illustrating another example of the master replacement process in the redundant database system according to the embodiment. FIG. 7 is a sequence diagram illustrating another example of the master replacement process in the redundant database system according to the embodiment.

  The redundant database system, database apparatus, and master replacement method according to each embodiment of the present invention will be described below with reference to the drawings. In the following description, the same components are denoted by the same reference numerals and description thereof is omitted.

  As shown in FIG. 1A, a redundant database system 100 according to the embodiment is a system in which a plurality of database devices (DB devices) 1 to 3 that manage the same data are connected. In this redundant database system 100, one DB device 1 is set as a master, and the other DB devices 2 and 3 are set as slaves. Data stored in each of the DB devices 1 to 3 is synchronized. Specifically, when data is updated in the master first DB device 1, the same data (replica) is stored in the slave second DB device 2 and the third DB device 3 by replication.

  In the redundant database system 100, the master is replaced when the redundant database system 100 is maintained or when a failure occurs in the first DB device 1. Here, the failure is a failure that can transmit / receive a replication request completion notification, which will be described later, and does not affect the change of the master, such as a certain degree of software failure, such as total loss of the first DB device 1 or total disconnection of the network. It is not a malfunction.

  For example, as shown in FIG. 1B, the first DB device 1 is changed from the master to the slave, and the second DB device 2 is changed from the slave to the master. In addition, the second DB device 2 changed to the master requests replication from the other DB devices 1 and 3 which are slaves, and the data is synchronized. As described above, the master replacement method according to the embodiment is a method for replacing the master and the slave in the redundant database system 100.

  Processing in a normal state will be described with reference to the sequence diagram of FIG. In the redundant database system 100, for example, when the master first DB device 1 receives an update request for updating the stored data from the host device 4 (S1), it updates the data according to the received update request. (S2).

  The master first DB device 1 transmits a replication request related to data update to the slave second DB device 2 (S3). The second DB device 2 updates the data according to the replication request (S4). Thereby, in the 2nd DB apparatus 2, the same data (replica) as the 1st DB apparatus 1 is memorized.

  In addition, the second DB device 2 transmits a completion notification of completion of the update to the master first DB device 1 (S5).

  Here, the master DB device transmits a replication request to all the slave DB devices to be connected. Therefore, when the redundant database system 100 has two slave DB devices as shown in FIG. 1, the processing in steps S3 to S5 is performed with the two DB devices of the second DB device 2 and the third DB device 3. Between each.

  When the completion notification is received from all the slave DB devices, the master first DB device 1 transmits the completion notification to the host device 4 (S6).

  Next, an example of a master replacement method executed in a simple redundant database system will be described with reference to the sequence diagram of FIG. For example, when the master first DB device 1 receives an update request for data to be stored from the host device 4 (S11), it updates the data in accordance with the received update request (S12).

  Here, when the first DB device 1 detects the occurrence of a failure, the first DB device 1 starts a master replacement process (S13). Accordingly, the first DB device 1 starts sweeping (S14).

  “Sweeping” does not start the master-slave change until the replication process is completed, when there is a replication process that the old master DB device needs to execute when the master-slave change is executed. This means that a new data update request from the host apparatus 4 is not accepted.

  Further, the first DB device 1 transmits a replication request to the second DB device 2 in order to synchronize data in accordance with the update process executed in step S12 (S15). This replication request includes the contents of the data updated in step S12, and the first DB device 1 synchronizes the data with the second DB device 2. The second DB device 2 updates data according to the replication request (S16).

  The first DB device 1 that was the old master receives an update request from the host device 4 again while the sweeping is continued as described above (S17), and transmits an error notification to the host device 4 (S18).

  When the data update process in response to the replication request is completed, the second DB device 2 transmits a completion notification indicating completion of the update to the first DB device 1 of the old master (S19).

  Thereafter, the first DB device 1 transmits a completion notification indicating that the update has been completed to the host device 4 (S20), and ends the sweep-out process (S21).

  When the sweeping is completed, the first DB device 1 transmits a masterization notification requesting the change from the slave to the master to the second DB device 2 in order to resume the interrupted processing of the master and the slave (S22). . Further, the first DB device 1 ends the master change process (S23), and starts the process as a slave of the own device (S24).

  On the other hand, the second DB device 2 that has received the master notification from the first DB device 1 starts processing as a master (S25).

  The first DB device 1 that has become a slave transmits a replication start request to the second DB device 2 in order to synchronize data with the second DB device 2 that is the master (S26). This replication start request is for requesting transmission of data for replication in order for the first DB device 1 that has become a slave to synchronize with the second DB device 2 that is the master. Further, the second DB device 2 that has received the replication start request does not know the difference between the data stored in the second DB device 2 and the data stored in the first DB device 1. Therefore, the second DB device 2 transmits all case replications to the first DB device 1.

  On the other hand, in the redundant database system 100 according to the embodiment, as will be described later with reference to FIG. 4, in the DB device that has become the master, the flag storage unit 11 has completed data synchronization with the slave DB device. The “completion flag” relating to whether or not it is stored is stored, and it is determined whether or not it is necessary to execute all-replication according to this.

  Specifically, as shown in FIG. 4A, the first DB device 1 includes a data storage unit 10 for storing data managed by the redundant database system 100, and a master and a slave when set to the master. A flag storage unit 11 that stores a “completion flag” related to the completion of synchronization of the DB device, an update unit 12 that updates data in the data storage unit 10 with data received from the host device 4, and a master and slave DB Synchronizing means 13 for executing synchronization of data of the apparatus and updating the completion flag of the flag storage unit 11 as necessary, and when the master to the slave is changed, the flag of the flag storage unit 11 becomes a new master. Transmission means 14 for transmitting to the DB device is provided.

  Similarly to the first DB device 1, the second DB device 2 and the third DB device 3 have a data storage unit 10, a flag storage unit 11, an update unit 12, a synchronization unit 13, and a transmission unit 14, and are set as slaves. When necessary, processing necessary as a slave DB device is executed. When the master DB device is replaced by a master, processing necessary as a master DB device is executed.

  When the master change is started, the master first DB device 1 performs “sweep” of the data update process. That is, after accepting a new data update request from the host DB device, it waits without sending a “master notification” to the new master DB device until the update process being processed is completed. When the “sweep” of the data update process is completed and all the replication requests to the second DB device 2 are successful, as shown in FIG. 4A, the flag storage unit 11 sends the data to the second DB device 2. “Completion flag 2” indicating completion of sweeping is set to “complete”. In addition, if the “sweep” of the data update process is completed and all the replication requests to the third DB device 3 are successful, the flag storage unit 11 displays “completion flag” indicating the completion of the sweep to the third DB device 3. 3 ”is set to“ complete ”.

  In this way, if the “completion flag 2” and “completion flag 3” are “completion”, the data stored in the first DB device 1 that was the old master is the second DB device 2 that was the old slave and Since it can be seen that it is the same as the third DB device 3, replication can be made unnecessary by transmitting “completion flag 2” and “completion flag 3” to the second DB device 2.

  As shown in FIG. 4 (b), the transmission unit 14 of the first DB device 1 that has become a new slave has the “complete flag” that is the “complete flag” and the “complete flag 3” as the new master. 2 DB device 2 transmits. Thereafter, the synchronization means 13 of the first DB device 1 updates “completion flag 2” and “completion flag 3” to “incomplete”.

  The synchronization means 13 of the second DB device 2 that has newly become the master sets “completion flag 1” indicating the completion of replication in the first DB device 1 and “completion flag 3” indicating the completion of replication in the third DB device 3 to the initial stage. Set the setting to “Incomplete”.

  The redundant database system 100 according to the embodiment will be specifically described with reference to the sequence diagram shown in FIG. In the flowchart shown in FIG. 5, the processes in steps S11 to S25 described with reference to FIG. 3 are the same. However, the master first DB device 1 first stores “uncompleted” as an initial value as a “completion flag”.

  If all the data update processing being processed is completed and the sweeping is completed (S21), and all the replication requests to the second DB device 2 have been successful, the “completion flag 2” is set to “completed”. (S31). Thereby, the first DB device 1 and the second DB device 2 can be understood that the data was in a synchronized state at the time of the master change.

  The first DB device 1 that has started processing as a slave of its own device in step S24 reads “complete”, which is data of “completion flag 2” (S32), and becomes a new master together with the read completion flag data. A replication start request for requesting data synchronization is transmitted to the second DB device 2 (S33).

  The second DB device 2 which is the master that has received the replication start request and completion flag data (completion) knows that the first DB device 1 and the second DB device 2 are synchronized, and therefore determines that replication is unnecessary. Therefore, data transmission from the second DB device 2 to the first DB device 1 is not executed.

  Further, when the first DB device 1 transmits the replication start request and the completion flag data, the first DB device 1 updates the “completion flag 2” from “completed” to “incomplete” (S34).

  As described above, in the redundancy database system 100, the master DB device is provided with a completion flag, and the master stores whether or not the replication of the replication to the slave DB device has been completed. Also, the DB device that is the old master that has become a slave due to the change of master sends data of a completion flag indicating completion of data sweeping with the old slave to the DB device that is the new master when sending a replication start request. To do. As a result, the DB device that has become the new master can determine data synchronization with the old master DB device from the data of the completion flag inherited from the old master DB device. Therefore, it is possible to determine whether or not replication is necessary, prevent unnecessary execution of all-case replication, and prevent redundancy from being lost.

[When there are two slaves]
Although FIG. 5 has been described in the case where there is one slave, the processing in the case where there are two slaves will be described using the sequence diagram shown in FIG. In FIG. 6, the first DB device 1 is changed from the master to the slave, the second DB device 2 is changed from the slave to the master, and the third DB device 3 is an example of continuing the slave. In FIG. 6, the process from step S11 to S14 is the same as that in FIGS.

  When the update process is executed in step S12, the first DB device 1 transmits a replication request to each of the second DB device 2 and the third DB device 3 (S15-1 and S15-2).

  The second DB device 2 and the third DB device 3 that have received the replication request update the data in accordance with the replication request (S16-1 and S16-2). In addition, the second DB device 2 and the third DB device 3 that have completed the data update process transmit a completion notification that the update has been completed to the first DB device 1 of the old master (S19-1 and S19-2).

  The first DB device 1 that has received the completion notification from the second DB device 2 and the third DB device 3 transmits a completion notification to the host device 4 (S20), and when the sweeping is completed (S21), synchronization with the second DB device 2 is performed. The “completion flag 2” and “completion flag 3” related to synchronization with the third DB device 3 are updated from “incomplete” to “completed” (S41).

  Moreover, the process of step S22-S25 is also the same as FIG.3 and FIG.5.

  The first DB device 1 that has started the processing as a slave of the own device in step S24 reads the data (completion) of “completion flag 2” and the data (completion) of “completion flag 3” (S42), and newly establishes the master A replication start request for requesting data synchronization is transmitted to the second DB device 2 that has been read together with the read completion flag data (S43).

  Also, the first DB device 1 that has transmitted the completion flag data to the second master device 2 that has become the new master changes the “completion flag 2” and “completion flag 3” from “completed” to “incomplete” (S44). ).

  The second DB device 2 which is the master that has received the replication start request and the data (completion) of the completion flag 2 shows that the first DB device 1 and the second DB device 2 are synchronized. Therefore, the second DB device 2 determines that replication with the first DB device 1 is unnecessary. Therefore, data transmission from the second DB device 2 to the first DB device 1 is not executed.

  In addition, since the second DB device 2 knows from the data of the completion flag 3 that the first DB device 1 and the third DB device 3 are synchronized, the second DB device 2 and the third DB device 3 are also synchronized. I understand. Therefore, the second DB device 2 updates the “completion flag 3” indicating that the data stored in the own device and the data stored in the third DB device 3 are synchronized to “completed” (S45). Thereby, the second DB device 2 can determine that the replication to the third DB device 3 is unnecessary.

  Therefore, even when the second DB device 2 receives a replication request from the third DB device 3 (S46), replication is not executed. Further, when receiving the replication request from the third DB device 3, the second DB device 2 updates the third completion flag from “completed” to “incomplete” (S47).

  In this manner, in the redundancy database system 100, a completion flag is provided in the master DB device, and it is stored whether or not the data sweeping with the slave DB device has been completed. In addition, the DB device that is the old master that has become a slave due to the change of the master transmits the data of the completion flag indicating the completion of the replica flushing to the old slave to the DB device that is the new master when the replication start request is transmitted. . As a result, the DB device that has become the new master can determine data synchronization between the old master DB device and the old slave DB device from the data of the completion flag inherited from the old master DB device. Therefore, it is possible to determine whether or not replication is necessary, prevent unnecessary execution of all-case replication, and prevent redundancy from being lost.

[When a replication start request is received from the second slave first]
FIG. 7 illustrates an example in which the second DB device 2 that has become the new master receives a replication start request first from the second slave that is the third DB device 3 instead of the first DB device 1 of the old master. It is a sequence diagram. In FIG. 7, the processing up to step S25 is the same as that in FIG. 6, and illustration of steps S11 to S21 is omitted.

  As shown in FIG. 7, when the synchronization means 13 of the second DB device 2 that has become the new master receives a replication start request from the third DB device 3 that is the slave (S51), the synchronization means 13 from the first DB device 1 that is the old master It is assumed that the completion flag data is not inherited. In this case, the second DB device 2 does not respond immediately to the replication start request, but waits for a certain period of time until the completion flag data is received from the first DB device 1 of the old master.

  The first DB device 1 reads the data (completion) of the “completion flag 1” and the data (completion) of the “completion flag 2” (S42), and transmits a replication start request including the data of the completion flag to the second DB device 2 ( S52). Further, the first DB device 1 that has transmitted the replication start request updates the “completion flag 2” and “completion flag 3” from “completed” to “incomplete” (S53).

  When the completion flag is received, the second DB apparatus 2 that has received the replication start request and the completion flag data (completion) from the first DB apparatus 1 indicates that the first DB apparatus 1 and the second DB apparatus are synchronized. Recognize. For this reason, the second DB device 2 determines that replication with the first DB device 1 is unnecessary, and no data is transmitted.

  Thereafter, since the “completion flag 3” received from the first DB device 1 (old master) is “completed”, the second DB device 2 does not need to transmit the replication start request received in step S51. Is determined. Therefore, the second DB device 2 does not execute data transmission to the first DB device 1.

  In this way, the DB device that becomes the new master due to the change of the master, when replication is requested from another slave DB device before taking over the data of the completion flag from the DB device of the old master, By deferring the necessity of replication until it is taken over, unnecessary replication can be prevented and redundancy can be prevented from being lost.

  As mentioned above, although this invention was demonstrated in detail using embodiment, this invention is not limited to embodiment described in this specification. The scope of the present invention is determined by the description of the claims and the scope equivalent to the description of the claims.

100 Redundant database system 1-3 Database device (DB device)
10 data storage unit 11 flag storage unit 12 update unit 13 synchronization unit (determination unit)
14 Transmitting means 4 Host device

Claims (5)

A redundant database system in which data is stored synchronously in a plurality of database devices, and any one database device is set as a master and another database device is set as a slave,
Each of the database devices is
A flag storage unit for storing a completion flag for specifying whether or not the data update processing in the database device of the old master and the replication request to the slave database device are all completed when the master is changed,
When changing from the master to the slave, the transmission means for transmitting the data of the completion flag to the database device as a new master,
When changing from the slave to the master, based on the completion flag data received from the old master database device, all data stored in the own device will be sent in response to the replication start request from the slave database device, or A means of determining whether to complete the synchronization without sending a single message,
A redundant database system comprising: The flag storage unit stores completion flags for a plurality of slave database devices,
The synchronization means includes
When changing from a slave to a master, if a replication request is received from another slave database device before receiving the completion flag data from the old master database device, the completion flag data is received from the old master database device. 2. The redundant database system according to claim 1, wherein the database system waits until it is completed. A database device used in a redundant database system in which data is stored synchronously in a plurality of database devices, any one database device is set as a master, and another database device is set as a slave,
A flag storage unit for storing a completion flag for specifying whether or not data synchronization with the slave database device is completed when the data stored in the own device is updated when the master is stored;
When changing from the master to the slave, the transmission means for transmitting the data of the completion flag to the database device as a new master,
When changing from the slave to the master, based on the data of the completion flag received from the database device of the old master, the synchronization means for transmitting the data stored in the own device to the database of the slave whose data is not synchronized,
A database apparatus comprising: A master replacement method executed in a redundant database system in which data is stored synchronously in a plurality of database devices, one of the database devices is set as a master, and the other database device is set as a slave. ,
In the database device, when the master device is the master, when the data stored in the own device is updated, a completion flag for specifying whether or not the synchronization of the data with the slave database device is completed is stored in the flag storage unit; ,
In the database device that changes from the master to the slave, the step of transmitting the data of the completion flag to the database device that becomes a new master;
In the database device to be changed from the slave to the master, based on the data of the completion flag received from the old master database device, the step of transmitting the data stored in the own device to the database of the slave whose data is not synchronized,
A master replacement method characterized by comprising: The flag storage unit stores a completion flag for each of the plurality of slave database devices,
When the database device to be changed from the slave to the master receives a replication request from another slave database device before receiving the completion flag data from the old master database device, the completion flag data from the old master database device is received. 5. The master replacement method according to claim 4, further comprising a step of waiting until the signal is received.

Images