JP2010277467A - Distributed data management system, data management apparatus, data management method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To increase the availability of a system for holding a database with one of three or more database devices as a master and the others as slaves, when the master fails. <P>SOLUTION: When the master fails, the slave database device 10A obtains a database log update number "L" and its own ID "I" from a storage part (S301), and generates a proposal number (L, I) for identifying a notification of candidacy for a new master and sends a candidacy notification Prepare(L, I) to the other slave database devices 10B and 10C (S302). The other slaves each obtain their own database log update number "L'" and their own ID "I'" from their own storage part to generate their own proposal number (L', I'), and if the received (L, I) is not smaller than their own (L', I'), send an acknowledgment notification PrepareACK (L, I). The slave that has the proposal number of a majority of acknowledgment notifications becomes a candidate for a new master. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention is a distributed database system comprising three or more database devices, one database serving as a master and the remaining database devices serving as slaves. The availability when a failure occurs in the master (continuing the system) It relates to a technology for increasing the probability of being able to operate.

  To increase the probability of the availability of a distributed database system, the same database is held in multiple database devices that make up the distributed database system, and even if some database devices fail, services can be provided by the remaining database devices. There is a technique to continue.

  For example, PAXOS (see Non-Patent Document 1) is known as one using the above-described method. When PAXOS is put to practical use, it is common to determine one database device to be accessed by the user for database update or reference, call it the master, and use the database device other than the master as the slave. Has been done. The master accepts a user's processing request (request for updating or referencing the database) and responds to the processing request. In addition, the master transmits the latest database state to the slave and maintains the slave database in the same state as the master database.

  PAXOS has an algorithm for determining a new master from among slaves when a failure occurs in the master. For example, a case where the slave determines that a failure has occurred in the master is when the slave cannot receive a heartbeat message output from the master to the slave at a fixed period. However, if packet loss, delay, or transposition occurs in the network to which the master and slave are connected, the slave may not receive the heartbeat message even if the master is operating normally. There is a possibility that a new master is determined and two masters having different database states exist. As a result, the integrity of the database is impaired.

  Therefore, the PAXOS algorithm operates in two phases because it arbitrates so that there are no two masters (see Non-Patent Document 2). In the first phase, a slave that has determined that a failure has occurred in an existing master is selected as the next new master, so that a candidacy notification Prepare () is transmitted to another slave. If the database device that has issued the candidacy notification Prepare () earliest is selected and becomes a candidate, or if there are multiple database devices that have issued the candidacy notification Prepare (), a predetermined priority order is set. A high database device is selected to become a candidate. Next, in the second phase, the candidate selected in the first phase sends the proposal content “I am the master” to another slave as a proposal notification Propose (), and the other By receiving the approval from the slave, the master becomes the master and establishes a relationship in which the other database device is the slave.

L. Lamport, “The part-time parliament”, ACM Transactions on Computer System (TOCS), Vol. 16, Issue 2, May 1998, p.133-169 T. D. Chandra et al., “PAXOS made live: an engineering perspective”, PODC’07, Proceedings of the twenty-sixth annual ACM symposium on Principles of distributed computing, June 20, 2007, p.1-16

  As described above, in the PAXOS algorithm, a new master can be determined, but there is a problem that the determined new master does not always have the latest database. If the new master database is not up-to-date, the operation of the distributed database system is stopped during the period from the acquisition of the latest database from the database device having the latest database to application to the database. Therefore, the problem of impairing availability occurs. The above-described problem also occurs in data management that manages the version number of data and files including a database.

  Therefore, in order to solve the above-described problem, the object of the present invention is a distributed data management system configured by three or more data management devices and holding data using one as a master and the remaining two or more as slaves. An object of the present invention is to provide a technique for increasing the probability of availability when a failure occurs in a master.

  In order to solve the above-described problems, the present invention is configured such that three or more data management devices are communicably connected to each other via a network, one of the data management devices is a master, and the other data management devices are As a slave, a distributed data management system that selects a new master from slaves in the event of a master failure, where the slave updates the processing unit and the data managed by the slave, and the data update number that increases. A storage unit that stores a proposal number whose variable is an update number that increases as the number increases, and the slave processing unit reads its update number from its own storage unit in the event of a master failure, and the update number When a candidate notification including a proposal number with a variable is sent to another slave and the processing unit of the other slave newly receives a candidate notification If there is no proposal number stored before searching for its own storage unit and receiving the candidacy notification, it reads its own update number from its own storage unit, and uses its update number as a variable A number is generated, and the size of the proposal number of the candidate notification that is newly received is compared with the proposal number of the candidate notification that is newly received. A confirmation notification for the candidacy notification including the proposal number is returned to the slave that sent the candidacy notification, the proposal number of the newly received candidacy notification is stored in its own storage unit, and the proposal stored before receiving the candidacy notification If there is a number, the largest proposal number is extracted from the stored proposal numbers, and if the newly received candidate number proposal number is greater than or equal to the largest proposal number, A confirmation notification for the candidate notification is transmitted to the slave that sent the candidacy notification, the proposal number of the newly received candidacy notification is stored in its own storage unit, and all the slaves that have transmitted the candidacy notification belong to the distributed data management system When a confirmation notification including its own proposal number is received from a majority of the slaves in the data management apparatus, proposal information indicating that the self including the proposal number is a master is transmitted to all slaves, and distributed data After receiving the confirmation notification for the proposal information from the majority of slaves in all the data management devices belonging to the management system, the decision notification indicating that the proposal information is confirmed is sent to the other slaves, and the other slaves are notified of the decision. And the proposal number of the candidacy notification already stored is deleted from its own storage unit.

  The present invention is also a data management apparatus used in the distributed data management system, wherein the data update number increases each time the data managed by the slave is updated, and the update number increases as the update number increases. Means for storing a proposal number having a variable as a variable, and means for reading a candidate's update number from its own storage unit in the event of a master failure and transmitting a candidate notification including a proposal number having the update number as a variable to another slave When the candidate notification is newly received, the storage unit searches its own storage unit, and if there is no proposal number stored before receiving the candidate notification, the update number is read from the storage unit , Generating its own proposal number with the update number as a variable, comparing the size of its own proposal number with the proposal number of the newly received candidacy notification, When the proposal number of the candidacy notification received is equal to or greater than the own proposal number, a confirmation notification for the candidacy notification including the proposal number of the candidacy notification is returned to the slave that sent the candidacy notification, and the newly received candidacy notification If there is a proposal number stored before receiving the candidacy notification, the largest proposal number is extracted from the stored proposal numbers, and the newly received candidate notification is received. If the proposal number is equal to or greater than the maximum proposal number, a confirmation notification for the candidate notification including the proposal number of the candidate notification is returned to the slave that transmitted the candidate notification, and the proposal number of the newly received candidate notification is Means for storing in the storage unit, first counting means for counting the number received for each proposal number included in the received confirmation notification, and belonging to the distributed data management system First determination means for determining that the number of confirmation notifications received exceeds a majority from the ratio of the number of all data management devices and the number of receptions for each proposal number counted by the first counting means; When it is determined by the determination means of 1 that the number of confirmation notifications received exceeds a majority, means for transmitting proposal information indicating that itself including the proposal number is a master to all slaves; Second count means for counting the number received for each proposal number included in the information indicating that the self including the proposal number is the master, the number of all data management devices belonging to the distributed data management system, and the second A second determination for determining that the number of proposal information received for any of the proposal numbers exceeds a majority from a ratio with the number of receptions for each proposal number counted by the counting means Means, and when the second determination means determines that the number of proposal information received exceeds a majority, means for transmitting a decision notification indicating that the proposal information has been confirmed to another slave; and receiving the decision notification And a means for erasing the proposal number of the candidacy notification already stored from its own storage unit.

  In the present invention, three or more data management devices are communicably connected to each other via a network. One of the data management devices is a master and another data management device is a slave. A data management method used in a distributed data management system for selecting a new master from among slaves, the slave updating the processing unit and the data managed by the slave, and the data update number and its update A storage unit that stores a proposal number whose variable is an update number that increases as the number increases, and the slave processing unit reads its update number from its own storage unit in the event of a master failure, and the update number The candidate notification including the proposal number with the variable is sent to the other slaves, and the processing unit of the other slave newly When there is no proposal number stored before the candidate notification is received by searching its own storage unit, the update number is read from the storage unit and the update number is set as a variable. When the proposal number of the newly received candidacy notification is greater than or equal to the own proposal number by comparing the size of the proposal number of the own candidate and the proposal number of the newly received candidate notification Before sending the confirmation notification for the candidacy notification including the proposal number of the candidacy notification to the slave that sent the candidacy notification, storing the newly received proposal number of the candidacy notification in its own storage unit, and receiving the candidacy notification If there is a stored proposal number, the largest proposal number is extracted from the stored proposal numbers, and if the newly received proposal number of the candidacy notification is greater than or equal to the maximum proposal number, the proposal number of the candidacy notification The confirmation notification for the candidacy notification is sent back to the slave that sent the candidacy notification, the proposal number of the newly received candidacy notification is stored in its own storage unit, and the slave that sent the candidacy notification is distributed data management system When a confirmation notification including its own proposal number is received from a majority of the slaves in all data management devices belonging to, the proposal information indicating that itself including its own proposal number becomes the master is transmitted to all slaves. After receiving the confirmation notification for the proposal information from the majority of the slaves in all the data management devices belonging to the distributed data management system, the decision notification indicating that the proposal information is confirmed is sent to the other slaves, and the other slaves Receiving the decision notification, and deleting the already stored proposal number of the candidacy notification from its own storage unit. Data management method.

  According to such a configuration, the slave stores a data update number that increases each time data is updated and a proposal number that uses the update number that increases as the update number increases as a variable. Then, in the event of a master failure, the slave, the proposal number included in the candidacy notification received from the other data management device, and the maximum proposal number stored in the storage unit (only the own proposal number is initially stored) ), The confirmation notification including the proposal number of the candidacy notification is sent to the slave that has transmitted the candidacy notification only when the proposal number included in the candidacy notification is equal to or greater than the maximum proposal number stored in the storage unit. Reply and store the proposal number of the candidacy notification. In other words, the storage unit stores more than its own proposal number. Then, when the slave receives a confirmation notification including the proposal number from a majority of slaves, it returns proposal information indicating that the slave including the proposal number is a master to the slave that has transmitted the candidacy notification. Furthermore, a slave indicated in the proposal information including any one of the same proposal numbers from the majority of the slaves becomes a new master. Therefore, the slave with the larger proposal number is selected as the new master, that is, the slave with the latest data (the highest proposal number or the highest update number) is selected as the new master. The probability of availability when a failure occurs can be increased.

  In the distributed data management system according to the present invention, the proposal number is a combination of the update number of the data and an ID for identifying data indicating the priority selected for the new master. In the size comparison of the numbers, the update numbers extracted from the proposal numbers are compared, and the larger update number is determined to be the larger proposal number. A comparison is made, and the larger ID for identifying the data is determined to have a larger proposal number.

  In the data management apparatus, the proposal number is a combination of the data update number and an ID for identifying data indicating the priority order selected by the new master. The update numbers extracted from the numbers are compared, and the larger update number is determined to be the larger proposal number. If the update numbers are equal, the IDs for identifying the data are compared to identify the data. Means are provided for determining that the proposal number is larger for the larger ID.

  According to the present invention, in the data management method, the proposal number is a combination of the data update number and an ID for identifying data indicating the priority order selected by the new master. In comparison, the update numbers taken out from the proposal number are compared with each other, the larger update number is determined as the proposal number is large, and when the update numbers are equal, the IDs for identifying the data are compared with each other, It is characterized by determining with the larger ID which identifies data that a proposal number is large.

  According to such a configuration, since the proposal number is a combination of the data update number and the ID indicating the priority order, it becomes a unique number and indicates the priority order even when the data update numbers are equal. Selection of a new master can be accelerated by the size of the ID. That is, since the stop time of the distributed data management system until a new master is determined is shortened, the probability of availability when a failure occurs in the master can be increased.

  In the data management method, when a processing unit of another slave newly receives a candidacy notification, it searches its own storage unit, reads its own update number, and uses the update number as a variable If the proposal number of the newly received candidacy notification is equal to or less than the own proposal number, It is characterized in that its own candidacy notification is transmitted to a slave other than itself.

  According to such a configuration, the candidacy notification including the proposal number larger than the proposal number of the slave that has already transmitted the candidacy notification can be sent into the distributed data management network, so that data management that holds the latest data is possible. The probability of determining a device as a new master can be increased.

  The present invention provides a program for causing a data management apparatus as a computer to execute the data management method.

  A computer in which such a program is installed can realize functions based on this program.

  According to the present invention, in a distributed data management system configured with three or more data devices and holding data using one as a master and the remaining two or more as slaves, the availability is improved when a failure occurs in the master. Technology can be provided.

It is a figure which shows the structure of a distributed database system. It is a figure which shows the structure and function of the database apparatus in this embodiment. It is a figure which shows the flow of a process of the 1st phase in this embodiment. It is a figure which shows the flow of a process of the 2nd phase in this embodiment. It is a figure which shows the structure and function of the database apparatus in a comparative example. It is a figure which shows the flow of a process of the 1st phase in a comparative example. It is a figure which shows the flow of a process of the 2nd phase in a comparative example.

  Next, a mode for carrying out the present invention (hereinafter referred to as “the present embodiment”) will be described in detail with reference to the drawings as appropriate. In the present embodiment, the case of a database will be described as an example.

(Distributed database system)
In the distributed database system 1 according to the present embodiment, as shown in FIG. 1, three database devices 10 (10A, 10B, 10C) and a client terminal 20 are connected via a network 30 so that they can communicate with each other. . In FIG. 1, only three database devices 10 are shown, but three or more database devices 10 may be used. Further, although only one client terminal 20 is shown in FIG. 1, two or more client terminals 20 may be used.

  The database device 10 receives a processing request for updating or referring to a database from the client terminal 20, determines one device that responds to the processing request, calls it the master, and refers to the database device 10 other than the master. Called a slave. In FIG. 1, the master is the database apparatus 10 </ b> A, and transmits / receives a processing request and a response to the processing request to / from the client terminal 20. Then, the database devices 10B and 10C become slaves and transmit / receive information for database synchronization to / from the master (database device 10A) in order to maintain the slave database in the same state as the master database. When each of the slave database devices 10B and 10C determines that a failure has occurred in the master, the slave database devices 10B and 10C start arbitration to be selected as a new master.

  The database device 10 is, for example, a computer or a PC (Personal Computer), and includes a general-purpose OS (Operating System), a data management system such as a database or a file system, and a local storage (local storage unit). Note that the database device 10 may be a mobile phone including a local storage, for example. The client terminal 20 is, for example, a PC, transmits an instruction from the user to the master database device 10A, and outputs a response to the instruction to an output device (not shown). The network 30 is the Internet or a local area network, and packet loss, delay, or transposition may occur in the network.

≪Comparative example≫
First, as a comparative example of the present embodiment, a master determination process to which the above-described PAXOS algorithm is applied will be described with reference to FIGS.

(Comparative database device)
First, the configuration and function of the database device 10 (10D, 10E, 10F) will be described with reference to FIG. As shown in FIG. 5, each database device 10 </ b> D, 10 </ b> E, 10 </ b> F includes a processing unit 14, a local storage unit 15, and a database 16. The processing unit 14 includes a CPU (Central Processing Unit) of the computer and a main memory, and develops an application program stored in the local storage unit 15 in the main memory to realize each function. Then, the processing unit 14 receives a processing request from the client terminal 20 (see FIG. 1) via an input device (not shown), and returns a response (processing result) to the processing request. The local storage unit 15 stores various programs and calculation results of the processing unit 14. The database 16 stores data by a relational database, a file system, or the like, for example.

  The function of the processing unit 14 includes a proposal number issuing unit 141, a suggesting unit 142, and an arbitrating unit 143, as shown in FIG.

  The proposal number issuing unit 141 issues a proposal number n when outputting the candidacy notification Prepare () to the other database device 10. The proposal number n is a unique number calculated based on a predetermined priority order among the database devices 10. For example, it is calculated as proposal number n = database ID + number of database devices × number of proposals. However, the number of proposals is the number of times that a candidacy notification is output until a new master is determined, and is incremented by one each time a candidacy notification is output. In other words, the proposal number issuing unit 141 increases the number of proposals by +1 each time the candidacy notification is issued again if there is no response (confirmation notification) from the other slave to the candidacy notification until a new master is determined. Issue the proposal number n. The proposal number n is reset to an initial value (for example, 0) when a new master is determined.

  The proposing unit 142 transmits the candidacy notification Prepare () and the proposal notification Propose () to the other database device 10, and responds to the candidacy notification and the proposal notification from the other database device 10 (confirmation notification PrepareACK (), ProposeACK ()). Receive. The arbitration unit 143 receives the candidacy notification and the proposal notification, and stores the received candidacy notification and the proposal notification in the local storage unit 15. In addition, the arbitration unit 143 receives the proposal number n included in the newly received candidacy notification or proposal notification and the local storage unit 15 until the new master already stored in the local storage unit 15 is determined. Compared with the proposal number n ′ stored in the above, if the proposal number n is greater than or equal to the proposal number n ′, confirmation notifications PrepareACK () and ProposeACK () are transmitted.

(Processing of the first phase in the comparative example)
In the first phase, a slave that has determined that a failure has occurred in an existing master is selected as the next new master, so that a candidacy notification Prepare () is transmitted to another slave. If the database device that has issued the candidacy notification Prepare () earliest is selected and becomes a candidate, or if there are multiple database devices that have issued the candidacy notification Prepare (), a predetermined priority order is set. A high database device is selected to become a candidate.
FIG. 6 shows a flow of processing in the first phase in the comparative example (see FIG. 5 as appropriate). First, in step S601, the proposal number issuing unit 141 of the database device 10D (hereinafter referred to as the database device 10D) that transmits a candidacy notification, for example, does not receive a heartbeat message from the master for a predetermined time. It is determined that a failure has occurred, and a proposal number n for identifying the candidacy notification Prepare () is issued. In step S602, the suggestion unit 142 transmits the candidacy notification Prepare (n) to the database devices 10E (10), 10F (10),... (Hereinafter referred to as other database devices 10) that receive the candidacy notification. . Note that the database device 10D may transmit the candidacy notification Prepare (n) to itself.

  In step S603, the arbitrating unit 143 of the other database device 10 receives the candidacy notification Prepare (n) transmitted from the database device 10D. In step S604, the arbitrating unit 143 searches the local storage unit 15 and determines whether or not there is a previously received candidate notification Prepare (n ′) (stored in the local storage unit 15). When there is no previously received candidate notification Prepare (n ′) (No in Step S604), in Step S605, the arbitrating unit 143 returns a confirmation notification PrepareACK (n) to the database device 10D. Thereafter, in step S606, the arbitrating unit 143 stores the candidacy notification Prepare (n) received in step S603 in its own local storage unit 15.

  If there is a previously received candidate notification Prepare (n ′) (stored in the local storage unit 15) (Yes in step S604), in step S607, the arbitration unit 143 proposes the proposal number n previously received. It is compared whether the number n 'or more. If the proposal number n is greater than or equal to the previously received proposal number n ′ (Yes in step S607), in step S608, the arbitration unit 143 includes the previously received proposal notification Propose () whose proposal number is n or less. The proposal notification Propose (nm, v ′) having the maximum proposal number nm is read, and the confirmation notification PrepareACK (n, Propose (nm, v ′)) is returned to the database device 10D. Note that v ′ is the content of the proposal, for example, “who (which database device 10) becomes the master”. If there is no previously received proposal notification Propose (), a confirmation notification PrepareACK (n) is returned to the database device 10D. Together with the reply of the confirmation notification PrepareACK (n) in step S605 and the confirmation notification PrepareACK (n, Propose (nm, v ')) in step S608, a certain database device X receives confirmation notifications ProposeACK from more than half of the other database devices. Even when other database device Y issues Prepare () using a proposal number equal to or greater than the proposal number of database device X in the state of receiving (), proposal notification Propose () of other database device Y does not It will be the same as the proposal contents. Therefore, if a certain database apparatus X receives a majority of confirmation notifications ProposeACK (), it is guaranteed that no other database apparatus will become the master. Further, in step S609, the arbitrating unit 143 stores the received candidacy notification Prepare (n) in its own local storage unit 15.

  If the proposal number n is not equal to or larger than the previously received proposal number n ′ (No in step S607), the processing unit 14 of the other database device 10 ends the process. That is, the arbitrating unit 143 of the other database device 10 does not transmit the confirmation notification PrepareACK () to the database device 10D.

  Further, the database device 10D transmits a confirmation notification PrepareACK () to itself.

(Processing of second phase in comparative example)
In the second phase, the candidate selected in the first phase sends the proposal content “I am a master” to another slave as a proposal notification Propose (), and the proposal content is sent from another slave. By receiving the approval, the user becomes the master and establishes a relationship in which the database device other than the user is a slave.
FIG. 7 shows a flow of processing in the second phase in the comparative example (see FIG. 5 as appropriate). First, in step S701, the proposal unit 142 of the database device 10D receives the confirmation notification PrepareACK () transmitted from the other database device 10. Next, the arbitrating unit 143 counts whether the number of confirmation notifications PrepareACK () of the proposal number n received at a predetermined time is a majority of the number of database devices 10 existing in the entire distributed database system 1, and determines the majority It is determined whether or not the confirmation notification PrepareACK () of the proposal number n has been received. If the confirmation notification PrepareACK () of the majority proposal number n is not received (No in step S701), the arbitration unit 143 determines that the candidacy has been rejected in step S702, and ends the process. If the new master has not yet been determined after the process of step S702, the process of the database device 10D returns to step S601 of the process shown in FIG. You may continue the process after S602. The recalculated proposal number n is set to a value larger than the value used for the previous candidacy notification.

  When the confirmation notification PrepareACK () of the majority proposal number n is received in step S701 (Yes in step S701), in step S703, the arbitrating unit 143 receives the confirmation notification PrepareACK (n, Propose (nm, v ′)). It is determined whether or not it has been received. If even one confirmation notification PrepareACK (n, Propose (nm, v ′)) is received (Yes in step S703), in step S704, the arbitration unit 143 receives the proposal notification received from each of the other database devices 10. Compare proposal number nm of Propose (nm, v '). Then, the proposal unit 142 receives the comparison result, sets the proposal content v ′ of the proposal notification Propose () of the largest proposal number as its own proposal content v, and proposes the proposal notification Propose (n, v) to another database. Transmit to device 10. The database device 10D may transmit a proposal notification Propose (n, v) to itself.

  When the confirmation notification PrepareACK (n, Propose (nm, v ′)) is not received in step S703 (No in step S703), in step S705, the proposal unit 142 determines its proposal content v and proposes notification. Propose (n, v) is transmitted to the other database device 10. In steps S704 and S705, the database device 10D may transmit a proposal notification Propose (n, v) to itself. In step S706, the arbitration unit 143 of the other database device 10 receives the proposal notification Propose (n, v), and then searches the local storage unit 15 to determine whether the proposal number n is greater than or equal to the previously received proposal number n ′. Determine whether.

  If the proposal number n is greater than or equal to the previously received proposal number n ′ (Yes in step S706), in step S707, the arbitration unit 143 returns a confirmation notification ProposeACK (n) to the database device 10D. Further, the arbitration unit 143 stores the received proposal notification Propose (n, v) in the local storage unit 15. If the proposal number n is not greater than or equal to the previously received proposal number n ′ (No in step S706), the processing unit 14 of the other database device 10 ends the process. That is, the arbitrating unit 143 of the other database device 10 does not transmit the confirmation notification ProposeACK () to the database device 10D.

  In step S708, the proposal unit 142 of the database device 10D receives the confirmation notification ProposeACK () transmitted from the other database device 10. Then, the arbitrating unit 143 counts whether the number of confirmation notifications ProposeACK (n) received at a predetermined time is a majority of the number of database devices 10 existing in the entire distributed database system 1, and determines the majority of confirmation notifications ProposeACK ( Determine whether n) is received. If the majority confirmation notification ProposeACK (n) is not received (No in step S708), the process proceeds to step S702, and the arbitrating unit 143 of the database device 10D determines that the candidacy has been rejected, and the process Exit. When the majority confirmation notification ProposeACK (n) is received (Yes in step S708), in step S709, the arbitration unit 143 of the database device 10D determines the proposal contents v (the database device 10D becomes the master). Judge that Then, the arbitrating unit 143 of the database device 10 </ b> D transmits a determination notification indicating that the proposal content v has been confirmed to the other database device 10.

  In step S710 after step S707, the arbitrating unit 143 of the other database device 10 stores the received proposal notification Propose (n) in its own local storage unit 15. Then, after receiving the determination notification from the database device 10D, the processing unit 14 of the other database device 10 stores the candidacy notification Prepare (), proposal notification Propose (), confirmation notification PrepareACK (), ProposeACK stored in the local storage unit 15. Delete () and end the process.

<< this embodiment >>
Next, master determination processing in the present embodiment will be described with reference to FIGS.

(Database device of this embodiment)
Next, the configuration and function of the database device 10 (10A, 10B, 10C) will be described with reference to FIG. As shown in FIG. 2, each database device 10 </ b> A, 10 </ b> B, 10 </ b> C includes a processing unit 11, a local storage unit 12, and a database 13. The processing unit 11 includes a CPU of a computer and a main memory. The application program stored in the local storage unit 12 is expanded in the main memory to realize each function. And the process part 11 receives the process request from the client terminal 20 (refer FIG. 1) via the input device which is not shown in figure, and returns the response (process result) with respect to the process request. The local storage unit 12 stores various programs and calculation results of the processing unit 11. The database 13 stores data by a relational database, a file system, or the like, for example.

  As illustrated in FIG. 2, the processing unit 11 includes a log management unit 111, a proposal number issuing unit 112, a proposal unit 113, and an arbitration unit 114.

  The log management unit 111 manages the latest log update number of the database 13 and stores the log update number in the local storage unit 12 in association with the state of the database 13. Note that the log update number does not have to be a consecutive number, and increases every time the database is updated. Further, the log management unit 111 reads out the latest log update number from the local storage unit 12 in accordance with an instruction from the proposal number issuing unit 112 and outputs it to the proposal number issuing unit 112.

  When the proposal number issuing unit 112 outputs the candidacy notification Prepare () to the other database device 10, the latest log update number “L” stored in the local storage unit 12 and the database device 10 are uniquely set in advance. A proposal number (L, I) is issued using “I” of the determined database device ID (Identification) as a variable. The proposal number (L, I) is assumed to increase as the log update number “L” increases. If there is no response (confirmation notification) to the candidacy notification until a new master is determined, the proposal number issuing unit 112 will return the L of the proposal numbers (L, I) each time the candidacy notification is issued. A proposal number with a value incremented by +1 is issued. When the new master is determined, the proposal number (L, I) is reset to an initial value (a combination of the latest log management number “L” and the database device ID “I”). The difference between the proposal number (L, I) of the present embodiment and the proposal number n of the comparative example is that the proposal number n of the comparative example has nothing to do with the log update number of the database. “L” in the form proposal number (L, I) is the log update number of the database. That is, when comparing the size of the proposal number (L, I), it is easy to select the database device 10 that holds the latest database state (the log update number or the proposal number is the largest) by the log update number “L”. can do. By the way, in the present embodiment, the log update numbers are first compared with each other in the size comparison of the proposal numbers (L, I). If L> L ′, it is determined that the proposal number (L, I) is larger than the proposal number (L ′, I ′). If L = L ′, the database device IDs are compared with each other. If I> I ′, it is determined that the proposal number (L, I) is larger than the proposal number (L ′, I ′).

  The proposing unit 113 transmits a candidacy notification Prepare () and a proposal notification Propose () to the other database device 10, and responses to the candidacy notification and the proposal notification from other database devices 10 (confirmation notification PrepareACK (), ProposeACK ()). Receive. The arbitration unit 114 receives the candidacy notification and the proposal notification, and stores the received candidacy notification and the proposal notification in the local storage unit 12. In addition, the arbitration unit 114 receives the proposal number (L, I) included in the newly received candidacy notification or proposal notification until the new master already stored in the local storage unit 12 is determined. Compare the proposal number (L ′ ′, I ′ ′) stored in the local storage unit 12 and confirm if the proposal number (L, I) is equal to or greater than the proposal number (L ′ ′, I ′ ′). Notification PrepareACK () and ProposeACK () are sent.

(Processing of the first phase in the present embodiment)
FIG. 3 shows the flow of processing in the first phase in the present embodiment (see FIG. 2 as appropriate). First, in step S301, the log management unit 111 of the database device 10A (hereinafter referred to as the database device 10A) that transmits a candidacy notification, for example, if the heartbeat message from the master is not received for a predetermined time, Based on a trigger from the proposal number issuing unit 112 that determines that a failure has occurred, the log update number “L” is read from the local storage unit 12. Also, the proposal number issuing unit 112 acquires the database device ID “I”. In step S302, the proposal number issuing unit 112 issues a proposal number (L, I) using the log update number “L” and the database device ID “I” as variables. Then, the proposing unit 113 transmits the candidacy notification Prepare (L, I) to the database devices 10B (10), 10C (10),... (Hereinafter referred to as other database devices 10) that receive the candidacy notification. . Note that the database device 10A may transmit the candidacy notification Prepare (L, I) to itself.

  In step S303, the arbitrating unit 114 of the other database device 10 receives the candidacy notification Prepare (L, I) transmitted from the database device 10A. In step S304, the arbitration unit 114 searches the local storage unit 12, reads the stored proposal number of the candidate notification Prepare () or the proposal notification Propose (), and receives the previously received proposal number (L ″, It is determined whether or not there is I ″). If there is no previously received proposal number (L ″, I ″) (No in step S304), in step S305, the log management unit 111 determines its own log update number “L ′” and the database device ID “ I ′ ”is acquired from the local storage unit 12, and the proposal number issuing unit 112 generates a proposal number (L ′, I ′).

  In step S306, the arbitrating unit 114 determines whether the proposal number (L, I) is greater than or equal to the proposal number (L ′, I ′). When the proposal number (L, I) is greater than or equal to the proposal number (L ′, I ′) (Yes in step S306), in step S307, the arbitrating unit 114 sends a confirmation notification PrepareACK (L, I) to the database device 10A. Send back. Thereafter, in step S308, the arbitrating unit 114 stores the candidacy notification Prepare (L, I) received in step S303 in its own local storage unit 12. In this embodiment, by providing step S306, at least a case where the log update number “L” is smaller than its own can be rejected, and the log update number is larger (the latest update number). ) The probability of selecting the database device 10 holding the database as the master can be increased.

  Here, the size comparison between the proposal number (L, I) and the proposal number (L ′, I ′) in step S306 will be described. In this embodiment, first, log update numbers are compared with each other. If L> L ′, it is determined that the proposal number (L, I) is larger than the proposal number (L ′, I ′). If L = L ′, the database device IDs are compared with each other. If I> I ′, it is determined that the proposal number (L, I) is larger than the proposal number (L ′, I ′).

  Returning to FIG. 3, when the proposal number (L, I) is not greater than or equal to the proposal number (L ′, I ′) in step S306 (No in step S306), the processing units 14 of the other database devices 10 The process ends. That is, the arbitrating unit 114 of the other database device 10 does not transmit the confirmation notification PrepareACK () to the database device 10A.

  In step S304, when there is a proposal number (L ″, I ″) received in advance (Yes in step S304), in step S309, the arbitrating unit 114 searches the local storage unit 12 and receives the previous received number. The maximum proposal number is extracted from the proposal numbers (L ″, I ″) of the candidate candidacy notification Prepare () or the proposal notification Propose () and is set as (Lm, Im). Next, in step S310, the arbitrating unit 114 determines whether the proposal number (L, I) is greater than or equal to the proposal number (Lm, Im).

  When the proposal number (L, I) is greater than or equal to the proposal number (Lm, Im) (Yes in step S310), in step S311, the arbitration unit 114 has the largest proposal number in the previously received proposal notification Propose (). Propose ((Lm, Im), v ′) having (Lm, Im) is read from the local storage unit 12 and confirmation notification PrepareACK ((L, I), Propose ((Lm, Im), v ′) is stored in the database. Reply to the device 10A, where v ′ is the content of the proposal, for example, information indicating “who (which database device 10) becomes the master.” When there is no previously received proposal notification Propose (Lm, Im) Returns a confirmation notification PrepareACK (L, I) to the database device 10 A. In step S312, the arbitration unit 114 stores the received candidacy notification Prepare (L, I) in its local storage unit 12.

  If the proposal number (L, I) is not greater than or equal to the proposal number (Lm, Im) (No in step S310), the processing unit 11 of the other database device 10 ends the process. That is, the arbitrating unit 114 of the other database device 10 does not transmit the confirmation notification PrepareACK () to the database device 10A.

  Further, the database device 10A transmits a confirmation notification PrepareACK () to itself.

(Process of the second phase in the present embodiment)
FIG. 4 shows the flow of processing of the second phase in the present embodiment (see FIG. 2 as appropriate). First, in step S401, the proposal unit 113 of the database device 10A receives the confirmation notification PrepareACK (L, I) transmitted from the other database device 10. Next, the arbitrating unit 114 counts whether the number of confirmation notifications PrepareACK () of the proposal numbers (L, I) received at a predetermined time is a majority of the number of database devices 10 existing in the entire distributed database system 1. Thus, it is determined whether or not the majority confirmation notification PrepareACK (L, I) has been received. When the majority confirmation notification PrepareACK (L, I) is not received (No in step S401), in step S402, the arbitrating unit 114 determines that the candidacy has been rejected, and ends the process. If a new master has not yet been determined after the process of step S402, the process of the database device 10A returns to step S301 of the process shown in FIG. 3, and recalculates the proposal number (L, I). However, you may continue the process after step S302. The recalculated proposal number (L, I) is generated by adding +1 to L used in the previous candidacy notification.

  When a majority confirmation notification PrepareACK (L, I) is received in step S401 (Yes in step S401), in step S403, the arbitrating unit 114 confirms the confirmation notification PrepareACK ((L, I), Propose ((Lm, Im ), v ′)) is received. When at least one confirmation notification PrepareACK ((L, I), Propose ((Lm, Im), v ′)) is received (Yes in step S403), in step S404, the arbitrating unit 114 makes each other The proposal numbers (Lm, Im) of the proposal notification Propose ((Lm, Im), v ′) received from the database device 10 are compared. Then, the proposing unit 113 receives the result of the comparison, sets the proposal content v ′ of the proposal notification Propose () with the largest proposal number as its proposal content v, and sets the proposal notification Propose ((L, I), v) To the other database device 10. Note that the database device 10A may transmit a proposal notification Propose ((L, I), v) to itself.

  When the confirmation notification PrepareACK ((L, I), Propose ((Lm, Im), v ′)) is not received in step S403 (No in step S403), in step S405, the proposing unit 113 makes its own proposal. The content v is determined and a proposal notification Propose ((L, I), v) is transmitted to the other database device 10. In steps S404 and S405, the database device 10A may transmit a proposal notification Propose ((L, I), v) to itself. In step S406, the arbitration unit 114 of the other database device 10 receives the proposal notification Propose ((L, I), v), searches the local storage unit 12, and previously receives the proposal number (L, I). It is determined whether or not the proposal number (L ″, I ″) is equal to or higher.

  If the proposal number (L, I) is greater than or equal to the previously received proposal number (L ″, I ″) (Yes in step S406), in step S407, the arbitration unit 114 checks the confirmation notification ProposeACK (L, I ) To the database apparatus 10. Further, the arbitrating unit 114 stores the received proposal notification Propose (L, I) in its local storage unit 12. If the proposal number (L, I) is not greater than or equal to the previously received proposal number (L ″, I ″) (No in step S406), the processing unit 11 of the other database device 10 ends the process. That is, the arbitrating unit 114 of the other database device 10 does not transmit the confirmation notification ProposeACK () to the database device 10A.

  In step S408, the proposal unit 113 of the database device 10A receives the confirmation notification ProposeACK (L, I) transmitted from the other database device 10. Then, the arbitrating unit 114 totals whether the number of confirmation notifications ProposeACK (L, I) received at a predetermined time has become a majority of the number of database devices 10 existing in the entire distributed database system 1, and a confirmation notification of the majority Determine whether ProposeACK (L, I) is received. If the majority confirmation notification ProposeACK (L, I) is not received (No in step S408), the process proceeds to step S402, and the arbitrating unit 114 of the database device 10A determines that the candidacy has been rejected. The process is terminated. Further, when the majority confirmation notification ProposeACK (L, I) is received (Yes in step S408), in step S409, the arbitrating unit 114 of the database device 10A has a proposal v (the database device 10A becomes a master). Judge that it was decided. Then, the arbitrating unit 114 of the database device 10 </ b> A transmits a determination notification indicating that the proposal content v has been confirmed to the other database device 10.

  After step S407, in step S410, the arbitrating unit 114 of the other database device 10 stores the received proposal notification Propose (L, I) in its own local storage unit 12. Then, after receiving the determination notification from the database device 10A, the processing unit 11 of the other database device 10 stores the candidacy notification Prepare (), proposal notification Propose (), confirmation notification PrepareACK (), ProposeACK stored in the local storage unit 12. Delete () and end the process.

(Concrete example)
The flow of processing according to the present embodiment and its effects will be described using specific examples shown in Table 1 (see FIGS. 3 and 4 as appropriate). As shown in Table 1, the distributed database system 1 is composed of a total of five database devices, one master (database device name N1) and four slaves (database device names N2, N3, N4, N5). Shall.

  In the first phase, a failure occurs in N1 of the master, and each slave transmits a candidacy notification Prepare () in the order of N4, N2, N3, and N5. The slave N4 sets the proposal number to (122, 4) and transmits a candidacy notification prepare (122, 4) to the other slaves N2, N3, and N5 (step S302). The other slaves N2, N3, and N5 receive the candidacy notification Prepare (122, 4) from N4 (step S303). At the time of receiving this candidate notification Prepare (122,4), the other slaves N2, N3, and N5 do not have the candidate notification stored in their storage units (that is, there is no previously received proposal number) (step S304). ) Reads its own log update number “L” from each storage unit (step S305), and generates its own proposal number (L, I). Then, the other slaves N2, N3, N5 compare their own proposal numbers (L, I) with the proposal numbers (122, 4) of the received candidate notification prepare (122, 4) (step S306). In comparison between the proposal numbers, for slave N2, (123,2)> (122,4), for slave N3, (122,3) <(122,4), for slave N5, (122,5) )> (122, 4). As a result, the slave N3 and itself (N4) transmit a confirmation notification PrepareACK (122, 4) (step S307). Thereafter, the slave N3 and the slave N4 store the confirmation notification Prepare (122, 4) in the storage unit (step S308). Then, the slave N4 receives the confirmation notification PrepareACK (122, 4) from the slave N3 and itself (N4) (step S401). That is, the slave N4 can receive the confirmation notification PrepareACK (122, 4) from only two of the five database devices. Therefore, the slave N4 cannot receive a majority confirmation notification PrepareACK (122, 4), and the candidate is rejected (step S402).

  Next, for the candidate notification Prepare (123, 2) transmitted by the slave N2, the slave N3 and the slave N4 that have received it receive the candidate notification Prepare (122, 4) already stored in the storage unit in Step S308. Since it exists, (122, 4) which is the maximum stored proposal number is extracted (step S309), and the proposal numbers are compared (step S310). The comparison results are (122,4) <(123,2) for slave 3 and (122,4) <(123,2) for slave 4. For the slave 5, (122, 5) <(123, 2). Therefore, the slaves N2, N3, N4, and N5 transmit the confirmation notification PrepareACK (123, 2) to the candidacy notification Prepare (123, 2) transmitted by the slave N2 (step S311). Then, the slave N2 receives the confirmation notification PrepareACK (123, 2) from the slaves N2, N3, N4, and N5 (step S401). Therefore, in the second phase, the slave N2 transmits a proposal notification Propose ((123,2), “master is N2”) to all the database devices (step S405). Next, since the proposal number (123, 2) is equal to or larger than the previously received proposal number (123, 2) in step S406, each of the slaves N2, N3, N4, and N5 transmits a confirmation notification Propose (123, 2). To do. Then, the slave N2 receives the confirmation notification ProposeACK (123, 2) from the majority of the database devices (step S408), and determines the proposal content “master is N2” (steps S409 and S411).

  As described above, in the present embodiment, since the proposal number of the candidacy notification received first is always compared with its own proposal number in step S304, the previously received proposal number stored in the storage unit is always No more than the proposal number. Therefore, when the log update numbers of the majority of database devices are the latest, the database device that holds the database of the latest log update numbers is always selected as the new master (with a probability of 100%). Note that if only half or less of the database devices hold the database with the latest log update number, assuming that the number of database devices is M, in the worst case, (M + 1) / (2 × (M−1)) The database device having the database with the latest log update number with probability becomes the new master. That is, in the case of M = 5 shown in Table 1, the database device that holds the database of the latest log update number with a probability of 75% at worst becomes a new master. Also, when the probability that the log update number of more than half of the database devices is the latest is 0.5, the probability that the new master will be the latest log update number is 100% × 0.5 + 75% × 0.5 = 87.5 %.

≪Modification≫
In the embodiment described above, the case where the first (first) candidate notification Prepare () is transmitted after it is determined that a failure has occurred in the master has been described. However, in this modification, a new master is determined. In the meantime, a method for increasing the probability that the database device 10 holding the database of the latest log update number is determined to be a new master in the case of sending another candidate notification Prepare () will be described (as appropriate in FIGS. 1 and 3). reference).

  In the first phase in the present embodiment, the database apparatus 10A cannot receive the confirmation notification PrepareACK () after transmitting the first (first) candidate notification Prepare (), and then receives other slave candidate notifications. Assume that Prepare () and proposal notification Propose () could not be received. In this case, the database device 10A cannot receive the confirmation notification PrepareACK () because (a) the candidacy notification Prepare () has disappeared due to packet loss in the network 30, or (b) the proposal number is small. It is impossible to know whether (c) the confirmation notification PrepareACK () has disappeared due to packet loss in the network 30 or (d) whether the database device 10 newly selected as the master has failed. In order to clarify this, the database device 10A waits for a predetermined time, and then transmits the candidacy notification Prepare () again. At this time, the proposal number (L, I) used for the candidacy notification Prepare () uses the value of L used for the previous candidacy notification Prepare () increased by +1 every time the candidacy notification Prepare () is transmitted. . And the process after step S302 of FIG. 3 is performed using the proposal number which increased +1 to L used last time.

  A case where this candidacy notification is transmitted again will be described using the case of Table 1. When it is determined that a failure has occurred in the master N1, it is assumed that the first phase is started in the order of the slaves N4, N2, N3, and N5. As described above, the first (first) candidacy notification Prepare () of the slave N4 cannot receive the majority confirmation notification PrepareACK () as described above. However, after the slave N4 waits for a predetermined time and before any of the other slaves N2, N3, and N5 transmits the candidacy notification Prepare () until the second candidacy notification Prepare () is transmitted, the first time Since the proposal number (122, 4) is set as the proposal number (123, 4) and the candidate notification prepare (123,4) is transmitted, it becomes a new master even though it is not the latest log update number. Happens.

  In order to increase the probability that a slave holding a database with the latest log update number will be selected as a new master, three plans will be described.

  In the first plan, before any of the database devices 10 transmits the candidacy notification Prepare () again, the time when all the slaves can issue the candidacy notification Prepare () for the first time can be issued again. Is to set. For example, a heartbeat message from the master is transmitted to all slaves by broadcast. If the slave does not receive the heartbeat message within a predetermined time, the slave determines that a failure has occurred in the master and starts the first phase. Depending on the load status of the master heartbeat sending device or network congestion, the timing for sending the candidacy notification Prepare () differs for each slave, and the sending time of the candidacy notification Prepare () that is sent earliest and the last There may be a case where the time difference from the transmission time of the candidacy notification Prepare () to be transmitted becomes large. As a result of a simulation experiment using five database devices 10, in most cases, the time difference is estimated to be 2 seconds. Before sending another candidate notification Prepare () again, all the slaves prepare the initial candidate notification Prepare ( ) Can be sent.

  The second proposal is to transmit its own candidacy notification Prepare () when the proposed number (L, I) of the received candidacy notification Prepare () is smaller than its own proposal number (L ', I'). is there. With this configuration, even if a slave with a small log update number sends a candidate notification Prepare (), a slave with a log update number equal to or higher than the log update number sends a candidate notification Prepare (). The database apparatus 10 that holds the database of the log update numbers is selected as the new master. The first and second proposals are effective methods in an environment including cases where packet loss, delay, and transposition occur in the network 30.

  In the third plan, a method that is effective in an environment in which no loss, delay, or transposition of packets occurs in the network 30 will be described. For example, in the case of Table 1, it is assumed that the processing of the first phase is started in the order of slaves N5, N4, N3, and N2. The slave N5 transmits a candidate notification prepare (122, 5) including the proposal number (122, 5) to the other slaves N2, N3, and N4. The slave N5 can receive PrepareACK (122,5) from the slaves N3, N4 and itself (N5), that is, receive a majority of PrepareACK (). Then, there is a problem that the slave N5 becomes a new master even if it does not hold the database of the latest log update numbers. This is because the number of slaves holding the database of the latest log update numbers is less than half, and the ID of the slave N5 is higher than the majority of slave IDs. Therefore, the above problem can be solved by increasing the determination time from the reception of the heartbeat message from the master to the determination of the master failure as the priority is higher (as the ID is larger). it can.

  As described above, according to the distributed database system 1 of the present embodiment and the modification, there is no previously received proposal number (L ″, I ″) in steps S304 to S305 illustrated in FIG. When Prepare (L, I) is received), a proposal number (L ′, I ′) generated by acquiring its own log update number “L” ′ and database device ID “I ′” is provided as a comparison criterion. Yes. However, in the comparative example, if there is no previously received proposal number n ′ (that is, the first candidate notification Prepare (n) is received) in step S604, there is no reference for comparing the size of the proposal number. Therefore, in this embodiment, at least the database device 10 that has received the candidacy notification Prepare (L, I) receives the confirmation notification PrepareACK () for the candidacy notification Prepare () smaller than its log update number “L ′”. The database apparatus 10 having its own log update number “L” or higher can always be set as a master candidate. That is, it is possible to increase the probability that a newly selected master has a database of the latest log update numbers. Therefore, in the distributed database system 1, availability when a failure occurs in the master can be increased.

  In this embodiment, the case where the proposal number is (L, I) has been described. However, even if only the log update number “L” is used, the effect of increasing availability can be brought about.

  In this embodiment, the case of a database has been described. However, the present invention can also be applied to data and files whose version number is managed.

  Moreover, in this embodiment, the process of each part of the database apparatus 10 (refer FIG. 2) may be implement | achieved by the program mounted when the database apparatus 10 is implement | achieved by the computer. This program can be provided via a communication line, or can be distributed by writing in a computer-readable recording medium such as a CD-ROM.

1 Distributed database system (distributed data management system)
10 (10A, 10B, 10C) Database device (data management device)
11 Processing Unit 12 Local Storage Unit (Storage Unit)
13 Database 30 Network 111 Log Management Unit 112 Proposal Number Issuing Unit 113 Proposal Unit 114 Arbitration Unit

Claims (8)

Three or more data management devices are communicably connected to each other via a network. One of the data management devices is used as a master, and the other data management device is used as a slave. A distributed data management system for selecting a new master,
The slave stores a processing unit and a data update number that increases each time the data managed by the slave is updated, and a storage unit that stores a proposal number with the update number increasing as the update number increases. And
The processing unit of the slave is
At the time of a master failure, read out its own update number from its own storage unit, send a candidate notification including a proposal number with the update number as a variable to other slaves,
The processing unit of the other slave is
When the candidate notification is newly received, search its own storage unit,
If there is no proposal number stored before receiving the candidacy notification, it reads its own update number from its own storage unit, generates its own proposal number with the update number as a variable, and Comparing the number of the newly received candidacy notification with the proposed number of the candidacy notification, and including the proposed number of the candidacy notification when the newly received proposal number of the candidacy notification is greater than or equal to its own proposal number A confirmation notification for the candidacy notification is returned to the slave that sent the candidacy notification, and the newly received proposal number of the candidacy notification is stored in its own storage unit,
If there is a proposal number stored before receiving the candidacy notification, the largest proposal number is extracted from the stored proposal numbers, and the newly received proposal number of the candidacy notification is the maximum proposal number. If it is above, the confirmation notification for the candidacy notification including the proposal number of the candidacy notification is transmitted to the slave that sent the candidacy notification, and the newly received proposal number of the candidacy notification is stored in its own storage unit And
The slave that sent the candidacy notification
A proposal indicating that itself including its own proposal number becomes a master when receiving a confirmation notification including its own proposal number from a majority of the slaves in all the data management devices belonging to the distributed data management system Send information to all the slaves,
After receiving a confirmation notification for the proposal information from a majority of the slaves in all the data management devices belonging to the distributed data management system, a decision notification indicating that the proposal information is confirmed is transmitted to the other slaves. ,
The said other said slave receives the said notification of a decision, and deletes the proposal number of the said candidate notification already memorize | stored from its memory | storage part, The distributed data management system characterized by the above-mentioned. The proposal number is a combination of the update number of the data and an ID for identifying the data indicating the priority order selected for the new master,
The processing unit, in the size comparison of the proposal number,
Compare the update numbers extracted from the proposal number, determine the larger update number, the proposal number is large,
The IDs for identifying the data are compared with each other when the update numbers are equal to each other, and a larger ID for identifying the data is determined to have a larger proposal number. Distributed data management system. A data management apparatus used in the distributed data management system according to claim 1,
Storage means for storing an update number of data that increases each time the data managed by the slave is updated, and a proposal number that uses the update number that increases as the update number increases as a variable;
At the time of a master failure, a means for reading out its own update number from its own storage unit and sending a candidate notification including a proposal number with the update number as a variable to other slaves;
When newly receiving the candidacy notification, search for its own storage unit, if there is no suggestion number stored before receiving the candidacy notification, read its own update number from its own storage unit, Generates the proposal number of the candidate using the update number as a variable, compares the proposal number of the proposal with the proposal number of the newly received candidacy notification, and compares the newly received proposal number of the candidacy notification Is returned to the slave that sent the candidacy notification, and the newly received proposal number of the candidacy notification is sent to the slave that sent the candidacy notification If there is a proposal number stored before receiving the candidacy notification, the largest proposal number is extracted from the stored proposal numbers, and the newly received candidate is If the knowledge proposal number is equal to or greater than the maximum proposal number, a confirmation notification for the candidate notification including the proposal number of the candidate notification is returned to the slave that transmitted the candidate notification, and the newly received candidate notification Means for storing the proposal number in its own storage unit;
First counting means for counting the number received for each proposal number included in the received confirmation notification;
From the ratio between the number of all the data management devices belonging to the distributed data management system and the number of receptions for each proposal number counted by the first counting means, the number of confirmation notifications received exceeds a majority. First determining means for determining;
Means for transmitting to each of the slaves proposal information indicating that the first determination means includes itself as a master when it is determined that the number of confirmation notifications received exceeds a majority. ,
Second counting means for counting the number received for each proposal number included in the information indicating that the self including the received proposal number is the master;
From the ratio between the number of all the data management devices belonging to the distributed data management system and the number of receptions for each proposal number counted by the second counting means, the number of receptions of the proposal information of any proposal number is A second determination means for determining that the majority has been exceeded;
Means for transmitting a determination notification indicating that the proposal information has been confirmed to the other slave when the second determination means determines that the number of receptions of the proposal information exceeds a majority;
And a means for receiving the decision notification and erasing the stored proposal number of the candidacy notification from its own storage unit. The proposal number is a combination of the update number of the data and an ID for identifying the data indicating the priority order selected for the new master,
In the comparison of the proposal numbers, the update numbers extracted from the proposal numbers are compared with each other, and the larger update number is determined as the proposal number is large. 4. The data management apparatus according to claim 3, further comprising means for comparing IDs for identifying the data and determining that the larger ID for identifying the data has a larger proposal number. Three or more data management devices are communicably connected to each other via a network. One of the data management devices is used as a master, and the other data management device is used as a slave. A data management method used in a distributed data management system for selecting a new master,
The slave stores a processing unit and a data update number that increases each time the data managed by the slave is updated, and a storage unit that stores a proposal number with the update number increasing as the update number increases. And
The processing unit of the slave is
At the time of a master failure, read out its own update number from its own storage unit, send a candidate notification including a proposal number with the update number as a variable to other slaves,
The processing unit of the other slave is
When the candidate notification is newly received, search its own storage unit,
If there is no proposal number stored before receiving the candidacy notification, it reads its own update number from its own storage unit, generates its own proposal number with the update number as a variable, and Comparing the number of the newly received candidacy notification with the proposed number of the candidacy notification, and including the proposed number of the candidacy notification when the newly received proposal number of the candidacy notification is greater than or equal to its own proposal number A confirmation notification for the candidacy notification is returned to the slave that sent the candidacy notification, and the newly received proposal number of the candidacy notification is stored in its own storage unit,
If there is a proposal number stored before receiving the candidacy notification, the largest proposal number is extracted from the stored proposal numbers, and the newly received proposal number of the candidacy notification is the maximum proposal number. If it is above, the confirmation notification for the candidacy notification including the proposal number of the candidacy notification is returned to the slave that transmitted the candidacy notification, and the newly received proposal number of the candidacy notification is stored in its own storage unit And
The slave that sent the candidacy notification
A proposal indicating that itself including its own proposal number becomes a master when receiving a confirmation notification including its own proposal number from a majority of the slaves in all the data management devices belonging to the distributed data management system Send information to all the slaves,
After receiving a confirmation notification for the proposal information from a majority of the slaves in all the data management devices belonging to the distributed data management system, a decision notification indicating that the proposal information is confirmed is transmitted to the other slaves. ,
The other slave receives the determination notification and deletes the proposal number of the candidacy notification already stored from its own storage unit. The processing unit of the other slave is
When the candidate notification is newly received,
Searches its own storage unit, reads its own update number, generates its own proposal number with the update number as a variable, and determines the size of the own proposal number and the newly received proposal number of the candidacy notification 6. If the proposal number of the newly received candidacy notification is equal to or less than the own proposal number, the candidacy notification of its own is transmitted to the slaves other than itself. Data management method. The proposal number is a combination of the update number of the data and an ID for identifying the data indicating the priority order selected for the new master,
The processing unit, in the size comparison of the proposal number,
Compare the update numbers extracted from the proposal number, determine the larger update number, the proposal number is large,
The IDs for identifying the data are compared with each other when the update numbers are equal to each other, and the larger ID for identifying the data is determined to have the larger proposal number. Item 7. The data management method according to item 6.   A program for causing a data management apparatus as a computer to execute the data management method according to any one of claims 5 to 7.

Images