JP5395517B2 - 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム - Google Patents

Description

本発明は、３台以上のデータベース装置によって構成され、１台をマスタ、残りのデータベース装置をスレーブとしてデータベースを保持する分散データベースシステムにおいて、マスタに障害が発生したときの可用性（システムを継続して稼動できること）の確率を高める技術に関する。

分散データベースシステムの可用性の確率を高めるために、分散データベースシステムを構成する複数のデータベース装置に同じデータベースを保持させて、一部のデータベース装置に障害が発生しても、残りのデータベース装置によってサービスを継続させる手法がある。

前記した手法を用いるものとして、例えば、ＰＡＸＯＳ（非特許文献１参照）が知られている。ＰＡＸＯＳを実用に供する場合、ユーザからデータベースの更新や参照のためにアクセスされるデータベース装置を１台決定しておき、それをマスタと呼び、マスタ以外のデータベース装置をスレーブとすることが、一般的に行われている。なお、マスタは、ユーザの処理要求（データベースの更新または参照に係る要求）を受け付けるとともに、その処理要求に対して応答する。また、マスタは、スレーブに最新のデータベースの状態を送信して、スレーブのデータベースをマスタのデータベースと同じ状態に維持する。

ＰＡＸＯＳは、マスタに障害が発生したときに、スレーブの中から新たなマスタを決定するアルゴリズムを備えている。例えば、スレーブがマスタに障害が発生したと判定するケースは、マスタからスレーブに対して一定周期で出力されるハートビートメッセージを、スレーブが受信できなくなったときである。しかし、マスタおよびスレーブが接続されているネットワークにおいてパケットの損失、遅延、転置が発生している場合には、マスタが正常に動作していても、スレーブがハートビートメッセージを受信できないことがあるため、新たなマスタが決定されて、データベースの状態の異なるマスタが２つ存在することになってしまう可能性がある。その結果、データベースの整合性が損なわれることになる。

そこで、ＰＡＸＯＳのアルゴリズムは、２つのマスタが存在しないように調停するため、２つのフェーズで動作する（非特許文献２参照）。第１のフェーズでは、既存のマスタに障害が発生したと判断したスレーブが、次の新たなマスタに選ばれるために、立候補通知Prepare()を他のスレーブに送信する。そして、最も早く立候補通知Prepare()を出したデータベース装置が選ばれて立候補者となる、または、立候補通知Prepare()を出したデータベース装置が複数あった場合には、予め決められた優先順位の高いデータベース装置が選ばれて立候補者となる。次に、第２のフェーズでは、第１のフェーズで選ばれた立候補者が、「自分がマスタである」という提案内容を提案通知Propose()として他のスレーブに送信し、その提案内容について他のスレーブから承認を受けることによって、自分がマスタとなり、自分以外のデータベース装置をスレーブとする関係を確立する。

L. Lamport，"The part-time parliament"，ACM Transactions on Computer System(TOCS)，Vol.16，Issue 2，1998年5月，p.133-169 T. D. Chandra他，"PAXOS made live: an engineering perspective"，PODC’07，Proceedings of the twenty-sixth annual ACM symposium on Principles of distributed computing，2007年6月20日，p.1-16

前記したように、ＰＡＸＯＳのアルゴリズムでは、新しいマスタを決定することができるが、その決定された新しいマスタが、最新のデータベースを備えているとは限らないという問題がある。そして、新しいマスタのデータベースが最新でない場合には、最新のデータベースを持つデータベース装置から最新のデータベースを取得して自身に適用するまでに掛かる期間において、分散データベースシステムの稼動が停止する。そのため、可用性を損なうという問題が発生する。なお、前記した問題は、データベースを含む、データやファイルの版数を管理するデータ管理についても発生する。

そこで、本発明の課題は、前記した問題を解決するために、３台以上のデータ管理装置によって構成され、１台をマスタ、残りの２台以上をスレーブとしてデータを保持する分散データ管理システムにおいて、マスタに障害が発生したときの可用性の確率を高める技術を提供することを目的とする。

前記課題を解決するために、本発明は、３台以上のデータ管理装置がネットワークを介して相互に通信可能に接続され、データ管理装置の中の１台をマスタとし、他のデータ管理装置をスレーブとして、マスタ障害時にスレーブの中から新しいマスタを選択する分散データ管理システムであって、スレーブが、処理部と、当該スレーブの管理するデータを更新するたびに大きくなるデータの更新番号およびその更新番号が大きくなるにしたがって大きくなる更新番号を変数とする提案番号を記憶する記憶部とを備え、スレーブの処理部が、マスタ障害時に、自身の記憶部から自身の更新番号を読出し、その更新番号を変数とする提案番号を含む立候補通知を他のスレーブに送信し、他のスレーブの処理部が、立候補通知を新たに受信したとき、自身の記憶部を探索して、該立候補通知を受信する以前に記憶した提案番号が無い場合には、自身の記憶部から自身の更新番号を読み出して、該更新番号を変数とする自身の提案番号を生成し、該自身の提案番号と新たに受信した立候補通知の提案番号との大小を比較して、新たに受信した立候補通知の提案番号が該自身の提案番号以上のとき、立候補通知の提案番号を含むその立候補通知に対する確認通知を、立候補通知を送信したスレーブに返信し、新たに受信した立候補通知の提案番号を自身の記憶部に記憶し、立候補通知を受信する以前に記憶した提案番号がある場合には、該記憶した提案番号中で最大の提案番号を抽出し、新たに受信した立候補通知の提案番号が最大の提案番号以上であれば、立候補通知の提案番号を含むその立候補通知に対する確認通知を、立候補通知を送出したスレーブに送信し、新たに受信した立候補通知の提案番号を自身の記憶部に記憶し、立候補通知を送信したスレーブが、分散データ管理システムに属するすべてのデータ管理装置中の過半数のスレーブから自身の提案番号を含む確認通知を受信したときに、自身の提案番号を含む自身がマスタになることを示す提案情報をすべてのスレーブに送信し、分散データ管理システムに属するすべてのデータ管理装置中の過半数のスレーブから提案情報に対する確認通知を受信した後、提案情報が確定したことを示す決定通知を他のスレーブに送信し、他のスレーブが、決定通知を受信し、自身の記憶部から、既に記憶されている立候補通知の提案番号を消去することを特徴とする。

また、本発明は、前記分散データ管理システムにおいて用いられるデータ管理装置であって、スレーブの管理するデータを更新するたびに大きくなるデータの更新番号およびその更新番号が大きくなるにしたがって大きくなる更新番号を変数とする提案番号を記憶する記憶手段と、マスタ障害時に、自身の記憶部から自身の更新番号を読出し、その更新番号を変数とする提案番号を含む立候補通知を他のスレーブに送信する手段と、立候補通知を新たに受信したとき、自身の記憶部を探索して、該立候補通知を受信する以前に記憶した提案番号が無い場合には、自身の記憶部から自身の更新番号を読み出して、該更新番号を変数とする自身の提案番号を生成し、該自身の提案番号と新たに受信した立候補通知の提案番号との大小を比較して、新たに受信した立候補通知の提案番号が該自身の提案番号以上のとき、立候補通知の提案番号を含むその立候補通知に対する確認通知を、立候補通知を送信したスレーブに返信し、新たに受信した立候補通知の提案番号を自身の記憶部に記憶し、立候補通知を受信する以前に記憶した提案番号がある場合には、該記憶した提案番号中で最大の提案番号を抽出し、新たに受信した立候補通知の提案番号が最大の提案番号以上であれば、立候補通知の提案番号を含むその立候補通知に対する確認通知を、立候補通知を送信したスレーブに返信し、新たに受信した立候補通知の提案番号を自身の記憶部に記憶する手段と、受信した確認通知に含まれる提案番号ごとに受信した数をカウントする第１のカウント手段と、分散データ管理システムに属するすべてのデータ管理装置の数と第１のカウント手段によってカウントされた提案番号ごとの受信数との比から、確認通知の受信数が過半数を超えたことを判定する第１の判定手段と、第１の判定手段によって、確認通知の受信数が過半数を超えたと判定されたとき、自身の提案番号を含む自身がマスタになることを示す提案情報をすべてのスレーブに送信する手段と、受信した自身の提案番号を含む自身がマスタになることを示す情報に含まれる提案番号ごとに受信した数をカウントする第２のカウント手段と、分散データ管理システムに属するすべてのデータ管理装置の数と第２のカウント手段によってカウントされた提案番号ごとの受信数との比から、いずれかの提案番号の提案情報の受信数が過半数を超えたことを判定する第２の判定手段と、第２の判定手段によって、提案情報の受信数が過半数を超えたと判定されたとき、提案情報が確定したことを示す決定通知を他のスレーブに送信する手段と、決定通知を受信し、自身の記憶部から、既に記憶されている立候補通知の提案番号を消去する手段とを備えることを特徴とする。

また、本発明は、３台以上のデータ管理装置がネットワークを介して相互に通信可能に接続され、データ管理装置の中の１台をマスタとし、他のデータ管理装置をスレーブとして、マスタ障害時にスレーブの中から新しいマスタを選択する分散データ管理システムにおいて用いられるデータ管理方法であって、スレーブが、処理部と、当該スレーブの管理するデータを更新するたびに大きくなるデータの更新番号およびその更新番号が大きくなるにしたがって大きくなる更新番号を変数とする提案番号を記憶する記憶部とを備え、スレーブの処理部が、マスタ障害時に、自身の記憶部から自身の更新番号を読出し、その更新番号を変数とする提案番号を含む立候補通知を他のスレーブに送信し、他のスレーブの処理部が、立候補通知を新たに受信したとき、自身の記憶部を探索して、該立候補通知を受信する以前に記憶した提案番号が無い場合には、自身の記憶部から自身の更新番号を読み出して、該更新番号を変数とする自身の提案番号を生成し、該自身の提案番号と新たに受信した立候補通知の提案番号との大小を比較して、新たに受信した立候補通知の提案番号が該自身の提案番号以上のとき、立候補通知の提案番号を含むその立候補通知に対する確認通知を、立候補通知を送信したスレーブに返信し、新たに受信した立候補通知の提案番号を自身の記憶部に記憶し、立候補通知を受信する以前に記憶した提案番号がある場合には、該記憶した提案番号中で最大の提案番号を抽出し、新たに受信した立候補通知の提案番号が最大の提案番号以上であれば、立候補通知の提案番号を含むその立候補通知に対する確認通知を、立候補通知を送信したスレーブに返信し、新たに受信した立候補通知の提案番号を自身の記憶部に記憶し、立候補通知を送信したスレーブが、分散データ管理システムに属するすべてのデータ管理装置中の過半数のスレーブから自身の提案番号を含む確認通知を受信したときに、自身の提案番号を含む自身がマスタになることを示す提案情報をすべてのスレーブに送信し、分散データ管理システムに属するすべてのデータ管理装置中の過半数のスレーブから提案情報に対する確認通知を受信した後、提案情報が確定したことを示す決定通知を他のスレーブに送信し、他のスレーブが、決定通知を受信し、自身の記憶部から、既に記憶されている立候補通知の提案番号を消去することを特徴とするデータ管理方法。

このような構成によれば、スレーブは、データを更新するたびに大きくなるデータの更新番号およびその更新番号が大きくなるにしたがって大きくなる前記更新番号を変数とする提案番号を記憶している。そして、スレーブは、マスタ障害時に、他のデータ管理装置から受信した立候補通知に含まれる提案番号と、記憶部に記憶してある最大の提案番号（当初記憶されているのは自身の提案番号のみ）とを比較して、立候補通知に含まれる提案番号が記憶部に記憶してある最大の提案番号以上の場合にのみ、立候補通知の提案番号を含む確認通知を、立候補通知を送信したスレーブに返信し、その立候補通知の提案番号を記憶する。すなわち、記憶部には、自分の提案番号以上のものが記憶されることになる。そして、スレーブが、過半数のスレーブから前記自身の提案番号を含む確認通知を受信したときに、自身の提案番号を含む自身がマスタになることを示す提案情報を、立候補通知を送信したスレーブに返信し、さらに、過半数の前記スレーブからいずれかの同じ提案番号を含む提案情報に示されるスレーブが、新しいマスタになる。そのため、より大きな提案番号のスレーブが新しいマスタに選ばれる、すなわち、最新の（提案番号が最も大きいまたは更新番号が最も大きい）データを持つスレーブが新しいマスタに選ばれる確率が高くなるので、マスタに障害が発生したときの可用性の確率を高めることができる。

また、本発明は、分散データ管理システムにおいて、提案番号が、データの更新番号に、新しいマスタに選択される優先順位を示すデータを識別するＩＤをさらに組み合わせたものであり、処理部が、提案番号の大小比較において、提案番号から取り出した更新番号同士を比較し、該更新番号の大きい方を、提案番号が大きいと判定し、更新番号同士が等しい場合には、データを識別するＩＤ同士を比較し、データを識別するＩＤの大きい方を、提案番号が大きいと判定することを特徴とする。

本発明は、データ管理装置において、提案番号が、データの更新番号に、新しいマスタに選択される優先順位を示すデータを識別するＩＤをさらに組み合わせたものであり、提案番号の大小比較において、提案番号から取り出した更新番号同士を比較し、該更新番号の大きい方を、提案番号が大きいと判定し、更新番号同士が等しい場合には、データを識別するＩＤ同士を比較し、データを識別するＩＤの大きい方を、提案番号が大きいと判定する手段を備えることを特徴とする。

本発明は、データ管理方法において、提案番号が、データの更新番号に、新しいマスタに選択される優先順位を示すデータを識別するＩＤをさらに組み合わせたものであり、処理部が、提案番号の大小比較において、提案番号から取り出した更新番号同士を比較し、該更新番号の大きい方を、提案番号が大きいと判定し、更新番号同士が等しい場合には、データを識別するＩＤ同士を比較し、データを識別するＩＤの大きい方を、提案番号が大きいと判定することを特徴とする。

このような構成によれば、提案番号が、データの更新番号と優先順位を示すＩＤとの組み合わせであるので、ユニークな番号となり、データの更新番号が等しい場合であっても、優先順位を示すＩＤの大小によって、新しいマスタの選択を早めることができる。すなわち、新しいマスタが決まるまでの分散データ管理システムの停止時間が短くなるため、マスタに障害が発生したときの可用性の確率を高めることができる。

本発明は、データ管理方法において、他のスレーブの処理部が、立候補通知を新たに受信したとき、自身の記憶部を探索して、自身の更新番号を読出し、該更新番号を変数とする自身の提案番号を生成し、該自身の提案番号と新たに受信した立候補通知の提案番号との大小を比較して、新たに受信した立候補通知の提案番号が該自身の提案番号以下であれば、自身の立候補通知を自身以外のスレーブに送信することを特徴とする。

このような構成によれば、さらに、既に立候補通知を送信したスレーブの提案番号より大きな提案番号を含む立候補通知を分散データ管理ネットワーク内に送出することができるので、最新のデータを保持するデータ管理装置を新しいマスタに決定する確率を高くすることができる。

本発明は、前記データ管理方法を、コンピュータとしてのデータ管理装置に実行させるためのプログラムとした。

このようなプログラムをインストールされたコンピュータは、このプログラムに基づいた機能を実現することができる。

本発明によれば、３台以上のデータ装置によって構成され、１台をマスタ、残りの２台以上をスレーブとしてデータを保持する分散データ管理システムにおいて、マスタに障害が発生したときの可用性を高める技術を提供することができる。

分散データベースシステムの構成を示す図である。 本実施形態におけるデータベース装置の構成および機能を示す図である。 本実施形態における第１のフェーズの処理の流れを示す図である。 本実施形態における第２のフェーズの処理の流れを示す図である。 比較例におけるデータベース装置の構成および機能を示す図である。 比較例における第１のフェーズの処理の流れを示す図である。 比較例における第２のフェーズの処理の流れを示す図である。

次に、本発明を実施するための形態（以降「本実施形態」と称す）について、適宜図面を参照しながら詳細に説明する。なお、本実施形態においては、データベースの場合を例として用いて説明する。

（分散データベースシステム）
本実施形態における分散データベースシステム１は、図１に示すように、３台のデータベース装置１０（１０Ａ，１０Ｂ，１０Ｃ）とクライアント端末２０とが、ネットワーク３０を介して、通信可能に接続されている。なお、図１では、データベース装置１０が３台しか記載されていないが、３台以上であっても構わない。また、クライアント端末２０は、図１では１台しか記載されていないが、２台以上であっても構わない。

データベース装置１０は、クライアント端末２０からデータベースの更新や参照のための処理要求を受け付けて、その処理要求に応答する１台を決定しておき、それをマスタと呼び、マスタ以外のデータベース装置１０をスレーブと呼ぶ。図１では、マスタは、データベース装置１０Ａであり、クライアント端末２０との間で処理要求およびその処理要求に対する応答を送受信する。そして、データベース装置１０Ｂ，１０Ｃが、スレーブとなって、スレーブのデータベースをマスタのデータベースと同じ状態に維持するために、データベース同期のための情報をマスタ（データベース装置１０Ａ）との間で送受信する。スレーブの各データベース装置１０Ｂ，１０Ｃは、マスタに障害が発生したと判断したとき、新しいマスタに選択されるための調停を開始する。

データベース装置１０は、例えば、計算機やＰＣ（Personal Computer）であって、汎用のＯＳ（Operating System）、データベースやファイルシステム等のデータ管理システム、およびローカルストレージ（ローカル記憶部）を備えている。なお、データベース装置１０は、例えば、ローカルストレージを備える携帯電話機であっても構わない。クライアント端末２０は、例えば、ＰＣであって、ユーザからの指示をマスタのデータベース装置１０Ａに送信し、その指示に対する応答を、図示しない出力装置等に出力する。また、ネットワーク３０は、インターネットまたはローカルエリアネットワークであって、そのネットワーク内において、パケットの損失、遅延、転置が発生しても構わない。

≪比較例≫
始めに、本実施形態の比較例として、前記したＰＡＸＯＳのアルゴリズムを適用したマスタの決定処理について、図５〜７を用いて説明する。

（比較例のデータベース装置）
まず、データベース装置１０（１０Ｄ，１０Ｅ，１０Ｆ）の構成および機能について、図５を用いて説明する。図５に示すように、各データベース装置１０Ｄ，１０Ｅ，１０Ｆは、処理部１４、ローカル記憶部１５、およびデータベース１６を備える。処理部１４は、コンピュータのＣＰＵ（Central Processing Unit）とメインメモリとで構成され、ローカル記憶部１５に格納されているアプリケーションプログラムをメインメモリに展開して、各機能を具現化する。そして、処理部１４は、図示しない入力装置を介して、クライアント端末２０（図１参照）からの処理要求を受け付け、その処理要求に対する応答（処理結果）を返信する。ローカル記憶部１５は、各種プログラムや処理部１４の演算結果を記憶する。データベース１６は、例えば、リレーショナルデータベース，ファイルシステム等によって、データを格納している。

処理部１４の機能は、図５に示すように、提案番号発行部１４１、提案部１４２、および調停部１４３を備える。

提案番号発行部１４１は、立候補通知Prepare()を他のデータベース装置１０に出力するときに、提案番号ｎを発行する。提案番号ｎは、予め決められたデータベース装置１０間の優先順位に基づいて計算される、ユニークな番号である。例えば、提案番号ｎ＝データベースＩＤ＋データベース装置の数×提案回数として計算される。ただし、提案回数は、新しいマスタが決定されるまでに立候補通知を出力する回数であって、立候補通知を出力するたびに＋１増加される。つまり、提案番号発行部１４１は、新たなマスタが決定されるまでの間に立候補通知に対して他のスレーブから応答（確認通知）が無い場合、再度立候補通知を出すごとに提案回数を＋１増加した提案番号ｎを発行する。なお、提案番号ｎは、新しいマスタが決定すると、初期値（例えば、０）にリセットされる。

提案部１４２は、立候補通知Prepare()や提案通知Propose()を他のデータベース装置１０に送信し、他のデータベース装置１０から立候補通知や提案通知に対する応答（確認通知PrepareACK()，ProposeACK()）を受信する。調停部１４３は、立候補通知や提案通知を受信し、受信した立候補通知や提案通知をローカル記憶部１５に記憶する。また、調停部１４３は、新たに受信した立候補通知や提案通知に含まれる提案番号ｎと、ローカル記憶部１５に既に記憶されている、新しいマスタが決まるまでの間に受信してローカル記憶部１５に記憶した提案番号ｎ’との大小を比較し、提案番号ｎが提案番号ｎ’以上であれば、確認通知PrepareACK()，ProposeACK()を送信する。

（比較例における第１のフェーズの処理）
第１のフェーズでは、既存のマスタに障害が発生したと判断したスレーブが、次の新たなマスタに選ばれるために、立候補通知Prepare()を他のスレーブに送信する。そして、最も早く立候補通知Prepare()を出したデータベース装置が選ばれて立候補者となる、または、立候補通知Prepare()を出したデータベース装置が複数あった場合には、予め決められた優先順位の高いデータベース装置が選ばれて立候補者となる。
図６は、比較例における第１のフェーズの処理の流れを示す（適宜図５参照）。まず、ステップＳ６０１では、立候補通知を送信するデータベース装置１０Ｄ（以降、データベース装置１０Ｄと称す。）の提案番号発行部１４１は、例えばマスタからのハートビートメッセージを所定時間受信しなかったとき、マスタに障害が発生したと判断し、立候補通知Prepare()を識別する提案番号ｎを発行する。ステップＳ６０２では、提案部１４２は、立候補通知Prepare(n)を、立候補通知を受信するデータベース装置１０Ｅ（１０），１０Ｆ（１０），・（以降、他のデータベース装置１０と称す。）に送信する。なお、データベース装置１０Ｄは、立候補通知Prepare(n)を自分自身に送信しても構わない。

ステップＳ６０３では、他のデータベース装置１０の調停部１４３は、データベース装置１０Ｄから送信された立候補通知Prepare(n)を受信する。ステップＳ６０４では、調停部１４３は、ローカル記憶部１５を探索して、以前受信した立候補通知Prepare(n’)がある（ローカル記憶部１５に記憶されている）か否かを判定する。以前受信した立候補通知Prepare(n’)が無い場合（ステップＳ６０４でＮｏ）、ステップＳ６０５では、調停部１４３は、確認通知PrepareACK(n)を、データベース装置１０Ｄに返信する。その後、ステップＳ６０６では、調停部１４３は、ステップＳ６０３において受信した立候補通知Prepare(n)を自身のローカル記憶部１５に記憶する。

また、以前受信した立候補通知Prepare(n’)がある（ローカル記憶部１５に記憶されている）場合（ステップＳ６０４でＹｅｓ）、ステップＳ６０７では、調停部１４３は、提案番号ｎが以前受信した提案番号ｎ’以上か否かを比較する。そして、提案番号ｎが以前受信した提案番号ｎ’以上の場合（ステップＳ６０７でＹｅｓ）、ステップＳ６０８では、調停部１４３は、提案番号がｎ以下の以前受信した提案通知Propose()の中で、最大の提案番号ｎｍを持つ提案通知Propose(nm,v’)を読出し、確認通知PrepareACK(n,Propose(nm,v’))を、データベース装置１０Ｄに返信する。なお、ｖ’は、提案内容であり、例えば「誰（どのデータベース装置１０）がマスタになる」という情報である。以前受信した提案通知Propose()がない場合は，確認通知PrepareACK(n)をデータベース装置１０Ｄに返信する。前記ステップＳ６０５の確認通知PrepareACK(n)およびステップＳ６０８の確認通知PrepareACK(n,Propose(nm,v’))の返信と合わせて、あるデータベース装置Ｘが過半数以上の他のデータベース装置から確認通知ProposeACK()を受信した状態で，他のデータベース装置Ｙがデータベース装置Ｘの提案番号以上の提案番号を用いるPrepare()を発行した場合も，他のデータベース装置Ｙの提案通知Propose()はデータベース装置Ｘの提案内容と同じになる。したがって、あるデータベース装置Ｘが確認通知ProposeACK()を過半数受信していれば他のデータベース装置はマスタにならないことを保証する。また、ステップＳ６０９では、調停部１４３は、受信した立候補通知Prepare(n)を自身のローカル記憶部１５に記憶する。

また、提案番号ｎが以前受信した提案番号ｎ’以上でない場合（ステップＳ６０７でＮｏ）、他のデータベース装置１０の処理部１４は、処理を終了する。すなわち、他のデータベース装置１０の調停部１４３は、確認通知PrepareACK()を、データベース装置１０Ｄに送信しない。

また、データベース装置１０Ｄは、自分自身に、確認通知PrepareACK()を送信するものとする。

（比較例における第２のフェーズの処理）
第２のフェーズでは、第１のフェーズで選ばれた立候補者が、「自分がマスタである」という提案内容を提案通知Propose()として他のスレーブに送信し、その提案内容について他のスレーブから承認を受けることによって、自分がマスタとなり、自分以外のデータベース装置をスレーブとする関係を確立する。
図７は、比較例における第２のフェーズの処理の流れを示す（適宜図５参照）。まず、ステップＳ７０１では、データベース装置１０Ｄの提案部１４２は、他のデータベース装置１０から送信された確認通知PrepareACK()を受信する。次に、調停部１４３は、所定時間に受信した提案番号ｎの確認通知PrepareACK()の数が分散データベースシステム１全体に存在するデータベース装置１０の数の過半数となったかを集計して、過半数の提案番号ｎの確認通知PrepareACK()を受信したか否かを判定する。そして、過半数の提案番号ｎの確認通知PrepareACK()を受信しなかった場合（ステップＳ７０１でＮｏ）、ステップＳ７０２で、調停部１４３は、立候補が否決されたものと判断し、処理を終了する。なお、ステップＳ７０２の処理の後、新しいマスタが未だ決定していない場合には、データベース装置１０Ｄの処理は、図６に示す処理のステップＳ６０１へ戻って、提案番号ｎを再計算して、ステップＳ６０２以降の処理を継続しても構わない。なお、再計算された提案番号ｎは、前回立候補通知に用いた数値よりは大きな数値にされる。

ステップＳ７０１において、過半数の提案番号ｎの確認通知PrepareACK()を受信した場合（ステップＳ７０１でＹｅｓ）、ステップＳ７０３では、調停部１４３は、確認通知PrepareACK(n,Propose(nm,v’))を受信したか否かを判定する。そして、確認通知PrepareACK(n,Propose(nm,v’))を一つでも受信した場合（ステップＳ７０３でＹｅｓ）、ステップＳ７０４では、調停部１４３は、各他のデータベース装置１０から受信した提案通知Propose(nm,v’)の提案番号ｎｍ同士を比較する。そして、提案部１４２は、その比較結果を受けて、最大の提案番号の提案通知Propose()の提案内容ｖ’を自身の提案内容ｖとして、提案通知Propose(n,v)を、他のデータベース装置１０に送信する。なお、データベース装置１０Ｄは、自分自身に提案通知Propose(n,v)を送信しても構わない。

ステップＳ７０３において確認通知PrepareACK(n,Propose(nm,v’))を受信しなかった場合（ステップＳ７０３でＮｏ）、ステップＳ７０５では、提案部１４２は、自身の提案内容ｖを決定し、提案通知Propose(n,v)を、他のデータベース装置１０に送信する。なお、ステップＳ７０４およびＳ７０５において、データベース装置１０Ｄは、提案通知Propose(n,v)を自分自身に送信しても構わない。ステップＳ７０６では、他のデータベース装置１０の調停部１４３は、提案通知Propose(n,v)を受信した後、ローカル記憶部１５を探索し、提案番号ｎが以前受信した提案番号ｎ’以上か否かを判定する。

そして、提案番号ｎが以前受信した提案番号ｎ’以上の場合（ステップＳ７０６でＹｅｓ）、ステップＳ７０７では、調停部１４３は、確認通知ProposeACK(n)を、データベース装置１０Ｄに返信する。また、調停部１４３は、受信した提案通知Propose(n,v)をローカル記憶部１５に記憶する。なお、提案番号ｎが以前受信した提案番号ｎ’以上でない場合（ステップＳ７０６でＮｏ）、他のデータベース装置１０の処理部１４は、処理を終了する。すなわち、他のデータベース装置１０の調停部１４３は、確認通知ProposeACK()を、データベース装置１０Ｄに送信しない。

ステップＳ７０８では、データベース装置１０Ｄの提案部１４２は、他のデータベース装置１０から送信された確認通知ProposeACK()を受信する。そして、調停部１４３は、所定時間に受信した確認通知ProposeACK(n)の数が分散データベースシステム１全体に存在するデータベース装置１０の数の過半数となったかを集計して、過半数の確認通知ProposeACK(n)を受信したか否かを判定する。そして、過半数の確認通知ProposeACK(n)を受信しなかった場合（ステップＳ７０８でＮｏ）、処理はステップＳ７０２へ進み、データベース装置１０Ｄの調停部１４３は、立候補が否決されたものと判断し、処理を終了する。また、過半数の確認通知ProposeACK(n)を受信した場合（ステップＳ７０８でＹｅｓ）、ステップＳ７０９では、データベース装置１０Ｄの調停部１４３は、提案内容ｖ（データベース装置１０Ｄがマスタになること）が決定されたと判断する。そして、データベース装置１０Ｄの調停部１４３は、提案内容ｖが確定したことを示す決定通知を、他のデータベース装置１０に送信する。

なお、ステップＳ７０７以降のステップＳ７１０では、他のデータベース装置１０の調停部１４３は、受信した提案通知Propose(n)を自身のローカル記憶部１５に記憶する。そして、他のデータベース装置１０の処理部１４は、データベース装置１０Ｄから決定通知を受信した後、ローカル記憶部１５に記憶した立候補通知Prepare()、提案通知Propose()、確認通知PrepareACK()，ProposeACK()を消去して、処理を終了する。

≪本実施形態≫
次に本実施形態におけるマスタの決定処理について、図２〜４を用いて説明する。

（本実施形態のデータベース装置）
次に、データベース装置１０（１０Ａ，１０Ｂ，１０Ｃ）の構成および機能について、図２を用いて説明する。図２に示すように、各データベース装置１０Ａ，１０Ｂ，１０Ｃは、処理部１１、ローカル記憶部１２、およびデータベース１３を備える。処理部１１は、コンピュータのＣＰＵとメインメモリとで構成され、ローカル記憶部１２に格納されているアプリケーションプログラムをメインメモリに展開して、各機能を具現化する。そして、処理部１１は、図示しない入力装置を介して、クライアント端末２０（図１参照）からの処理要求を受け付け、その処理要求に対する応答（処理結果）を返信する。ローカル記憶部１２は、各種プログラムや処理部１１の演算結果を記憶する。データベース１３は、例えば、リレーショナルデータベース，ファイルシステム等によって、データを格納している。

処理部１１は、図２に示すように、ログ管理部１１１、提案番号発行部１１２、提案部１１３、および調停部１１４を備える。

ログ管理部１１１は、データベース１３の最新のログ更新番号を管理し、そのログ更新番号を、データベース１３の状態と関連付けてローカル記憶部１２に記憶する。なお、ログ更新番号は、連続する番号でなくともよく、データベースを更新するたびに大きくなるものとする。また、ログ管理部１１１は、提案番号発行部１１２からの指示によって、ローカル記憶部１２から最新のログ更新番号を読み出し、提案番号発行部１１２へ出力する。

提案番号発行部１１２は、立候補通知Prepare()を他のデータベース装置１０に出力するときに、ローカル記憶部１２に記憶された最新のログ更新番号「Ｌ」と、予めデータベース装置１０ごとにユニークに決められたデータベース装置ＩＤ（Identification）の「Ｉ」とを変数として用いて、提案番号（Ｌ，Ｉ）を発行する。なお、提案番号（Ｌ，Ｉ）は、ログ更新番号「Ｌ」が大きくなるにしたがって大きくなるものとする。提案番号発行部１１２は、新たなマスタが決定されるまでの間に立候補通知に対する応答（確認通知）が無い場合、再度立候補通知を出すごとに、提案番号（Ｌ，Ｉ）の中のＬの値を＋１増加した提案番号を発行する。そして、提案番号（Ｌ，Ｉ）は、新しいマスタが決定すると、初期値（最新のログ管理番号「Ｌ」とデータベース装置ＩＤの「Ｉ」の組）にリセットされる。なお、本実施形態の提案番号（Ｌ，Ｉ）が比較例の提案番号ｎと異なる点は、比較例の提案番号ｎはデータベースのログ更新番号とは無関係であったのに対して、本実施形態の提案番号（Ｌ，Ｉ）中の「Ｌ」が、データベースのログ更新番号であることである。すなわち、提案番号（Ｌ，Ｉ）の大小を比較するときに、ログ更新番号「Ｌ」によって、最新の（ログ更新番号または提案番号が最も大きい）データベースの状態を保持するデータベース装置１０を選びやすくすることができる。ちなみに、本実施形態では、提案番号（Ｌ，Ｉ）の大小比較において、最初に、ログ更新番号同士を比較する。そして、Ｌ＞Ｌ’であれば、提案番号（Ｌ，Ｉ）が提案番号（Ｌ’，Ｉ’）より大きいと判定する。また、Ｌ＝Ｌ’であれば、次に、データベース装置ＩＤ同士を比較する。そして、Ｉ＞Ｉ’であれば、提案番号（Ｌ，Ｉ）が提案番号（Ｌ’，Ｉ’）より大きいと判定する。

提案部１１３は、立候補通知Prepare()や提案通知Propose()を他のデータベース装置１０に送信し、他のデータベース装置１０から立候補通知や提案通知に対する応答（確認通知PrepareACK()，ProposeACK()）を受信する。調停部１１４は、立候補通知や提案通知を受信し、受信した立候補通知や提案通知をローカル記憶部１２に記憶する。また、調停部１１４は、新たに受信した立候補通知や提案通知に含まれる提案番号（Ｌ，Ｉ）と、ローカル記憶部１２に既に記憶されている、新しいマスタが決まるまでの間に受信してローカル記憶部１２に記憶した提案番号（Ｌ’ ’，Ｉ’ ’）との大小を比較し、提案番号（Ｌ，Ｉ）が提案番号（Ｌ’ ’，Ｉ’ ’）以上であれば、確認通知PrepareACK()，ProposeACK()を送信する。

（本実施形態における第１のフェーズの処理）
図３は、本実施形態における第１のフェーズの処理の流れを示す（適宜図２参照）。まず、ステップＳ３０１では、立候補通知を送信するデータベース装置１０Ａ（以降、データベース装置１０Ａと称す。）のログ管理部１１１は、例えば、マスタからのハートビートメッセージを所定時間受信しなかった場合にマスタに障害が発生したと判断する提案番号発行部１１２からのトリガに基づいて、ログ更新番号「Ｌ」をローカル記憶部１２から読出す。また、提案番号発行部１１２は、データベース装置ＩＤ「Ｉ」を取得する。ステップＳ３０２では、提案番号発行部１１２は、ログ更新番号「Ｌ」とデータベース装置ＩＤ「Ｉ」とを変数として、提案番号（Ｌ，Ｉ）を発行する。そして、提案部１１３は、立候補通知Prepare(L,I)を、立候補通知を受信するデータベース装置１０Ｂ（１０），１０Ｃ（１０），・（以降、他のデータベース装置１０と称す。）に送信する。なお、データベース装置１０Ａは、立候補通知Prepare(L,I)を自分自身に送信しても構わない。

ステップＳ３０３では、他のデータベース装置１０の調停部１１４は、データベース装置１０Ａから送信された立候補通知Prepare(L,I)を受信する。ステップＳ３０４では、調停部１１４は、ローカル記憶部１２を探索して、記憶されている立候補通知Prepare()または提案通知Propose()の提案番号を読出して、以前受信した提案番号（Ｌ’’，Ｉ’’）があるか否かを判定する。そして、以前受信した提案番号（Ｌ’’，Ｉ’’）が無い場合（ステップＳ３０４でＮｏ）、ステップＳ３０５では、ログ管理部１１１は、自身のログ更新番号「Ｌ’」およびデータベース装置ＩＤ「Ｉ’」をローカル記憶部１２から取得し、提案番号発行部１１２が提案番号（Ｌ’，Ｉ’）を生成する。

ステップＳ３０６では、調停部１１４は、提案番号（Ｌ，Ｉ）が提案番号（Ｌ’，Ｉ’）以上か否かを判定する。提案番号（Ｌ，Ｉ）が提案番号（Ｌ’，Ｉ’）以上の場合（ステップＳ３０６でＹｅｓ）、ステップＳ３０７では、調停部１１４は、確認通知PrepareACK(L,I)を、データベース装置１０Ａに返信する。その後、ステップＳ３０８では、調停部１１４は、ステップＳ３０３において受信した立候補通知Prepare(L,I)を自身のローカル記憶部１２に記憶する。なお、本実施形態では、ステップＳ３０６を設けたことによって、少なくとも、ログ更新番号「Ｌ」が自身のものより小さいケースを受け付けなくすることができるようになり、ログ更新番号のより大きい（最新の）データベースを保持するデータベース装置１０をマスタに選択する確率を高めることができる。

ここで、ステップＳ３０６における、提案番号（Ｌ，Ｉ）と提案番号（Ｌ’，Ｉ’）との大小比較について説明する。本実施形態では、最初に、ログ更新番号同士を比較する。そして、Ｌ＞Ｌ’であれば、提案番号（Ｌ，Ｉ）が提案番号（Ｌ’，Ｉ’）より大きいと判定する。また、Ｌ＝Ｌ’であれば、次に、データベース装置ＩＤ同士を比較する。そして、Ｉ＞Ｉ’であれば、提案番号（Ｌ，Ｉ）が提案番号（Ｌ’，Ｉ’）より大きいと判定する。

そして、図３に戻って、ステップＳ３０６において、提案番号（Ｌ，Ｉ）が提案番号（Ｌ’，Ｉ’）以上でない場合（ステップＳ３０６でＮｏ）、他のデータベース装置１０の処理部１４は、処理は終了する。すなわち、他のデータベース装置１０の調停部１１４は、確認通知PrepareACK()を、データベース装置１０Ａに送信しない。

また、ステップＳ３０４において、以前受信した提案番号（Ｌ’’，Ｉ’’）がある場合（ステップＳ３０４でＹｅｓ）、ステップＳ３０９では、調停部１１４は、ローカル記憶部１２を探索して、以前受信した立候補通知Prepare()または提案通知Propose()の提案番号（Ｌ’’，Ｉ’’）の中で、最大の提案番号を抽出し、（Ｌｍ，Ｉｍ）とする。次に、ステップＳ３１０では、調停部１１４は、提案番号（Ｌ，Ｉ）が提案番号（Ｌｍ，Ｉｍ）以上か否かを判定する。

提案番号（Ｌ，Ｉ）が提案番号（Ｌｍ，Ｉｍ）以上の場合（ステップＳ３１０でＹｅｓ）、ステップＳ３１１では、調停部１１４は、以前受信した提案通知Propose()の中で、最大の提案番号（Ｌｍ，Ｉｍ）を持つPropose((Lm,Im),v’)をローカル記憶部１２から読出し、確認通知PrepareACK((L,I),Propose((Lm,Im),v’)を、データベース装置１０Ａに返信する。なお、ｖ’は、提案内容であり、例えば「誰（どのデータベース装置１０）がマスタになる」という情報である。以前受信した提案通知Propose(Lm, Im)がない場合は、確認通知PrepareACK(L,I)をデータベース装置１０Ａに返信する。また、ステップＳ３１２では、調停部１１４は、受信した立候補通知Prepare(L,I)を自身のローカル記憶部１２に記憶する。

また、提案番号（Ｌ，Ｉ）が提案番号（Ｌｍ，Ｉｍ）以上でないの場合（ステップＳ３１０でＮｏ）、他のデータベース装置１０の処理部１１は、処理を終了する。すなわち、他のデータベース装置１０の調停部１１４は、確認通知PrepareACK()を、データベース装置１０Ａに送信しない。

また、データベース装置１０Ａは、自分自身に、確認通知PrepareACK()を送信するものとする。

（本実施形態における第２のフェーズの処理）
図４は、本実施形態における第２のフェーズの処理の流れを示す（適宜図２参照）。まず、ステップＳ４０１では、データベース装置１０Ａの提案部１１３は、他のデータベース装置１０から送信された確認通知PrepareACK(L,I)を受信する。次に、調停部１１４は、所定時間に受信した提案番号（Ｌ，Ｉ）の確認通知PrepareACK()の数が分散データベースシステム１全体に存在するデータベース装置１０の数の過半数となったかを集計して、過半数の確認通知PrepareACK(L,I)を受信したか否かを判定する。そして、過半数の確認通知PrepareACK(L,I)を受信しなかった場合（ステップＳ４０１でＮｏ）、ステップＳ４０２では、調停部１１４は、立候補が否決されたものと判断し、処理を終了する。なお、ステップＳ４０２の処理の後、新しいマスタが未だ決定していない場合には、データベース装置１０Ａの処理は、図３に示す処理のステップＳ３０１へ戻って、提案番号（Ｌ，Ｉ）を再計算し、ステップＳ３０２以降の処理を継続しても構わない。なお、再計算された提案番号（Ｌ，Ｉ）は、前回の立候補通知に用いたＬに＋１増加して生成される。

ステップＳ４０１において、過半数の確認通知PrepareACK(L,I)を受信した場合（ステップＳ４０１でＹｅｓ）、ステップＳ４０３では、調停部１１４は、確認通知PrepareACK((L,I),Propose((Lm,Im),v’))を受信したか否かを判定する。そして、確認通知PrepareACK((L,I),Propose((Lm,Im),v’))を一つでも受信した場合（ステップＳ４０３でＹｅｓ）、ステップＳ４０４では、調停部１１４は、各他のデータベース装置１０から受信した提案通知Propose((Lm,Im),v’)の提案番号（Ｌｍ，Ｉｍ）同士を比較する。そして、提案部１１３は、その比較結果を受けて、最大の提案番号の提案通知Propose()の提案内容ｖ’を自身の提案内容ｖとして、提案通知Propose((L,I),v)を、他のデータベース装置１０に送信する。なお、データベース装置１０Ａは、自分自身に提案通知Propose((L,I),v)を送信しても構わない。

ステップＳ４０３において確認通知PrepareACK((L,I),Propose((Lm,Im),v’))を受信しなかった場合（ステップＳ４０３でＮｏ）、ステップＳ４０５では、提案部１１３は、自身の提案内容ｖを決定し、提案通知Propose((L,I),v)を、他のデータベース装置１０に送信する。なお、ステップＳ４０４およびＳ４０５において、データベース装置１０Ａは、提案通知Propose((L,I),v)を、自分自身に送信しても構わない。ステップＳ４０６では、他のデータベース装置１０の調停部１１４は、提案通知Propose((L,I),v)を受信した後、ローカル記憶部１２を探索し、提案番号（Ｌ，Ｉ）が以前受信した提案番号（Ｌ’’，Ｉ’’）以上か否かを判定する。

そして、提案番号（Ｌ，Ｉ）が以前受信した提案番号（Ｌ’’，Ｉ’’）以上の場合（ステップＳ４０６でＹｅｓ）、ステップＳ４０７では、調停部１１４は、確認通知ProposeACK(L,I)を、データベース装置１０に返信する。また、調停部１１４は、受信した提案通知Propose(L,I)を自身のローカル記憶部１２に記憶する。なお、提案番号（Ｌ，Ｉ）が以前受信した提案番号（Ｌ’’，Ｉ’’）以上でない場合（ステップＳ４０６でＮｏ）、他のデータベース装置１０の処理部１１は、処理を終了する。すなわち、他のデータベース装置１０の調停部１１４は、確認通知ProposeACK()を、データベース装置１０Ａに送信しない。

ステップＳ４０８では、データベース装置１０Ａの提案部１１３は、他のデータベース装置１０から送信された確認通知ProposeACK(L,I)を受信する。そして、調停部１１４は、所定時間に受信した確認通知ProposeACK(L,I)の数が分散データベースシステム１全体に存在するデータベース装置１０の数の過半数となったかを集計して、過半数の確認通知ProposeACK(L,I)を受信したか否かを判定する。そして、過半数の確認通知ProposeACK(L,I)を受信しなかった場合（ステップＳ４０８でＮｏ）、処理はステップＳ４０２へ進み、データベース装置１０Ａの調停部１１４は、立候補が否決されたものと判断し、処理を終了する。また、過半数の確認通知ProposeACK(L,I)を受信した場合（ステップＳ４０８でＹｅｓ）、ステップＳ４０９では、データベース装置１０Ａの調停部１１４は、提案内容ｖ（データベース装置１０Ａがマスタになること）が決定されたと判断する。そして、データベース装置１０Ａの調停部１１４は、提案内容ｖが確定したことを示す決定通知を、他のデータベース装置１０に送信する。

なお、ステップＳ４０７以降、ステップＳ４１０では、他のデータベース装置１０の調停部１１４は、受信した提案通知Propose(L,I)を自身のローカル記憶部１２に記憶する。そして、他のデータベース装置１０の処理部１１は、データベース装置１０Ａから決定通知を受信した後、ローカル記憶部１２に記憶した立候補通知Prepare()、提案通知Propose()、確認通知PrepareACK()，ProposeACK()を消去して、処理を終了する。

（具体例）
本実施形態の処理の流れとその効果について、表１に示す具体例を用いて説明する（適宜図３，４参照）。表１に示すように、分散データベースシステム１が、マスタ（データベース装置名Ｎ１）１台、スレーブ（データベース装置名Ｎ２，Ｎ３，Ｎ４，Ｎ５）４台の合計５台のデータベース装置によって構成されているものとする。

第１のフェーズでは、マスタのＮ１に障害が発生して、各スレーブは、Ｎ４，Ｎ２，Ｎ３，Ｎ５の順に立候補通知Prepare()を送信するものとする。スレーブＮ４は、提案番号を（１２２，４）として、立候補通知Prepare(122,4)を他のスレーブＮ２，Ｎ３，Ｎ５に送信する（ステップＳ３０２）。他のスレーブＮ２，Ｎ３，Ｎ５は、Ｎ４から立候補通知Prepare(122,4)を受信する（ステップＳ３０３）。この立候補通知Prepare(122,4)受信時点では、他のスレーブＮ２，Ｎ３，Ｎ５は、それぞれの記憶部に記憶した立候補通知が存在しない（すなわち、以前受信した提案番号がない）ので（ステップＳ３０４）、それぞれの記憶部から自身のログ更新番号「Ｌ」を読出し（ステップＳ３０５）、自身の提案番号（Ｌ，Ｉ）を生成する。そして、他のスレーブＮ２，Ｎ３，Ｎ５は、自身の提案番号（Ｌ，Ｉ）と、受信した立候補通知Prepare(122,4)の提案番号（１２２，４）とを比較する（ステップＳ３０６）。提案番号同士の比較では、スレーブＮ２については、（１２３，２）＞（１２２，４）、スレーブＮ３については、（１２２，３）＜（１２２，４）、スレーブＮ５については、（１２２，５）＞（１２２，４）となる。その結果、スレーブＮ３および自分（Ｎ４）は、確認通知PrepareACK(122,4)を送信する（ステップＳ３０７）。その後、スレーブＮ３およびスレーブＮ４は、確認通知Prepare(122,4)を記憶部に記憶する（ステップＳ３０８）。そして、スレーブＮ４は、スレーブＮ３および自分（Ｎ４）から確認通知PrepareACK(122,4)を受信する（ステップＳ４０１）。すなわち、スレーブＮ４は、５台のデータベース装置のうち、２台からしか確認通知PrepareACK(122,4)を受信できない。したがって、スレーブＮ４は、過半数の確認通知PrepareACK(122,4)を受信できないことになり、立候補否決となる（ステップＳ４０２）。

次に、スレーブＮ２が送信した立候補通知Prepare(123,2)に対しては、それを受信したスレーブＮ３およびスレーブＮ４は、ステップＳ３０８において既に記憶部に記憶した立候補通知Prepare(122,4)が存在するため、記憶されている最大の提案番号である（１２２，４）を抽出し（ステップＳ３０９）、提案番号同士の比較を行う（ステップＳ３１０）。その比較結果は、スレーブ３については、（１２２，４）＜（１２３，２）、スレーブ４については、（１２２，４）＜（１２３，２）となる。また、スレーブ５については、（１２２，５）＜（１２３，２）となる。したがって、スレーブＮ２の送信した立候補通知Prepare(123,2)に対しては、スレーブＮ２，Ｎ３，Ｎ４，Ｎ５は、確認通知PrepareACK(123,2)を送信することになる（ステップＳ３１１）。そして、スレーブＮ２は、スレーブＮ２，Ｎ３，Ｎ４，Ｎ５から確認通知PrepareACK(123,2)を受信する（ステップＳ４０１）。したがって、スレーブＮ２は、第２のフェーズにおいて、提案通知Propose((123,2),「マスタはＮ２である」)を全データベース装置に送信する（ステップＳ４０５）。次に、ステップＳ４０６において提案番号（１２３，２）が以前受信した提案番号（１２３，２）以上であるので、各スレーブＮ２、Ｎ３，Ｎ４，Ｎ５は、確認通知Propose(123,2)を送信する。そして、スレーブＮ２は、過半数のデータベース装置から確認通知ProposeACK(123,2)を受信して（ステップＳ４０８）、提案内容「マスタはＮ２である」に決定する（ステップＳ４０９、Ｓ４１１）。

前記したように、本実施形態では、ステップＳ３０４において、最初に受信した立候補通知の提案番号は必ず自身の提案番号と比較されるため、記憶部に記憶される、以前受信した提案番号は必ず自身の提案番号以上に限られる。したがって、過半数のデータベース装置のログ更新番号が最新のものである場合、必ず（１００％の確率で）、最新のログ更新番号のデータベースを保持するデータベース装置が新しいマスタに選択される。なお、半数以下のデータベース装置しか最新のログ更新番号のデータベースを保持していない場合、データベース装置の台数をＭとすると、最悪の状態で、（Ｍ＋１）／（２×（Ｍ−１））の確率で最新のログ更新番号のデータベースを持つデータベース装置が、新しいマスタになる。すなわち、表１に示すＭ＝５の場合には、最悪でも７５％の確率で最新のログ更新番号のデータベースを保持するデータベース装置が、新しいマスタになる。また、半数以上のデータベース装置のログ更新番号が最新のものである確率を０．５とした場合、新しいマスタが最新のログ更新番号となる確率は、100％×0.5+75％×0.5＝87.5％となる。

≪変形例≫
前記した実施形態では、マスタに障害が発生したと判定してから、初回（１回目）の立候補通知Prepare()を送信した場合について説明をしたが、本変形例では、新しいマスタが決まるまでの間に、再度の立候補通知Prepare()を送信する場合において、最新のログ更新番号のデータベースを保持するデータベース装置１０が新しいマスタに決定される確率を高める方法について、説明する（適宜図１，３参照）。

本実施形態における第１のフェーズにおいて、データベース装置１０Ａが初回（１回目）の立候補通知Prepare()を送信したにもかかわらす、確認通知PrepareACK()を受信できず、その後他のスレーブの立候補通知Prepare()や提案通知Propose()も受信できなかった場合を想定する。この場合、データベース装置１０Ａは、確認通知PrepareACK()を受信できない理由が、（ａ）立候補通知Prepare()がネットワーク３０内でパケット損失によって消滅してしまったのか、（ｂ）提案番号が小さいためなのか、（ｃ）確認通知PrepareACK()がネットワーク３０内でパケット損失によって消滅してしまったのか、（ｄ）新たにマスタに選択されたデータベース装置１０が故障したのか、を知ることができない。それを明確にするために、データベース装置１０Ａは、所定時間待った後、立候補通知Prepare()を再度送信する。このとき、立候補通知Prepare()に用いる提案番号（Ｌ，Ｉ）は、前回の立候補通知Prepare()に用いたＬの値に、立候補通知Prepare()を送信するごとに＋１増加したものを用いる。そして、前回用いたＬに＋１増加した提案番号を用いて、図３のステップＳ３０２以降の処理が実行される。

この立候補通知を再度送信する場合について、表１のケースを用いて説明する。マスタＮ１に障害が発生したと判断したとき、スレーブＮ４，Ｎ２，Ｎ３，Ｎ５の順で第１のフェーズが開始されたものとする。スレーブＮ４の初回（１回目）の立候補通知Prepare()は、提案番号比較の結果、前記したように、過半数の確認通知PrepareACK()を受信することはできない。しかし、スレーブＮ４は、所定時間待った後、２回目の立候補通知Prepare()を送信するまでに、他のスレーブＮ２，Ｎ３，Ｎ５のいずれもが立候補通知Prepare()を送信していなければ、初回の提案番号（１２２，４）を提案番号（１２３，４）として立候補通知Prepare(123,4)を送信するために、最新のログ更新番号でないにもかかわらず、新しいマスタになってしまうという事態が起きる。

そこで、ログ更新番号が最新のデータベースを保持するスレーブが、新しいマスタに選択される確率を高くするために、３つの案について説明する。

第１案は、いずれかのデータベース装置１０が再度の立候補通知Prepare()を送信する前に、すべてのスレーブが初回の立候補通知Prepare()を送信できるように、再度の立候補通知を発行できる時間を設定することである。例えば、マスタからのハートビートメッセージは、ブロードキャストによって全スレーブに送信される。スレーブは、所定時間内にハートビートメッセージを受信しなければ、マスタに障害が発生したと判定し、第１のフェーズを開始する。マスタのハートビート送出装置の負荷状況またはネットワークの輻輳状況によっては、立候補通知Prepare()を送信するタイミングが、スレーブごとに異なって、最も早く送信される立候補通知Prepare()の送信時刻と最後に送信される立候補通知Prepare()の送信時刻との時間差が大きくなる場合がある。５台のデータベース装置１０を用いたシミュレーション実験による結果では、前記時間差を２秒と見積もればほとんどの場合で、再度の立候補通知Prepare()の送信前に、すべてのスレーブが初回の立候補通知Prepare()を送信できることが分かった。

第２案は、受信した立候補通知Prepare()の提案番号（Ｌ，Ｉ）が、自身の提案番号（Ｌ’，Ｉ’）より小さい場合に、自身の立候補通知Prepare()を送信することである。この構成によって、ログ更新番号が小さいスレーブが立候補通知Prepare()を送信しても、そのログ更新番号以上のログ更新番号のスレーブが立候補通知Prepare()を送信するため、より高い確率で、最新のログ更新番号のデータベースを保持するデータベース装置１０が新しいマスタに選択されることになる。なお、前記第１案および第２案では、ネットワーク３０において、パケットの損失、遅延、転置が発生する場合を含む環境において有効な方法である。

第３案では、ネットワーク３０において、パケットの損失、遅延、転置が発生しない環境において用いることが有効な方法について説明する。例えば、表１のケースにおいて、スレーブＮ５，Ｎ４，Ｎ３，Ｎ２の順に第１のフェーズの処理を開始したとする。スレーブＮ５は、提案番号（１２２，５）を含む立候補通知Prepare(122,5)を他のスレーブＮ２，Ｎ３，Ｎ４に送信する。スレーブＮ５は、スレーブＮ３，Ｎ４および自身（Ｎ５）からPrepareACK(122,5)を受信する、すなわち、過半数のPrepareACK()を受信することができる。そして、スレーブＮ５は、最新のログ更新番号のデータベースを保持していなくても、新しいマスタとなってしまうという問題がある。これは、最新のログ更新番号のデータベースを保持するスレーブの台数が半数未満であり、かつ、スレーブＮ５のＩＤが過半数のスレーブのＩＤより高いことに起因している。そこで、マスタからハートビートメッセージを受信してからマスタの故障と判定するまでの判定時間を、優先順位の高いほど（ＩＤの大きいほど）判定時間を長くすることによって、前記問題を解決することができる。

以上、本実施形態および変形例の分散データベースシステム１によれば、図３に示すステップＳ３０４〜Ｓ３０５において、以前に受信した提案番号（Ｌ’’，Ｉ’’）がない（すなわち、初めて立候補通知Prepare(L,I)を受信した）場合、自身のログ更新番号「Ｌ」’およびデータベース装置ＩＤ「Ｉ’」を取得して生成した提案番号（Ｌ’，Ｉ’）を比較基準として備えている。しかし、比較例では、ステップＳ６０４において、以前に受信した提案番号ｎ’がない（すなわち、初めて立候補通知Prepare(n)を受信した）場合、提案番号の大小を比較する基準を備えていない。そのため、本実施形態では、少なくとも、立候補通知Prepare(L,I)を受信したデータベース装置１０は、自身のログ更新番号「Ｌ’」より小さい立候補通知Prepare()に対して、確認通知PrepareACK()を返信することはなく、必ず、自身のログ更新番号「Ｌ」以上のデータベース装置１０をマスタの候補とすることができる。すなわち、新しく選ばれるマスタが、最新のログ更新番号のデータベースを備えている確率を高めることができる。したがって、分散データベースシステム１において、マスタに障害が発生したときの可用性を高めることができる。

なお、本実施形態では、提案番号を（Ｌ，Ｉ）の場合について説明したが、ログ更新番号「Ｌ」だけを用いても、可用性を高める効果をもたらすことが可能である。

また、本実施形態では、データベースの場合について説明したが、版数管理をしているデータやファイルに対しても、適用することが可能である。

また、本実施形態において、データベース装置１０（図２参照）の各部の処理は、データベース装置１０をコンピュータで実現したときに搭載されるプログラムによって実現されてもよい。このプログラムは、通信回線を介して提供することもできるし、ＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体に書き込んで配布することも可能である。

１ 分散データベースシステム（分散データ管理システム）
１０（１０Ａ，１０Ｂ，１０Ｃ） データベース装置（データ管理装置）
１１ 処理部
１２ ローカル記憶部（記憶部）
１３ データベース
３０ ネットワーク
１１１ ログ管理部
１１２ 提案番号発行部
１１３ 提案部
１１４ 調停部

Claims (8)

1. ３台以上のデータ管理装置がネットワークを介して相互に通信可能に接続され、前記データ管理装置の中の１台をマスタとし、他の前記データ管理装置をスレーブとして、マスタ障害時にスレーブの中から新しいマスタを選択する分散データ管理システムであって、
   前記スレーブは、処理部と、当該スレーブの管理するデータを更新するたびに大きくなるデータの更新番号およびその更新番号が大きくなるにしたがって大きくなる前記更新番号を変数とする提案番号を記憶する記憶部とを備え、
   前記スレーブの処理部は、
   マスタ障害時に、自身の記憶部から自身の更新番号を読出し、その更新番号を変数とする提案番号を含む立候補通知を他のスレーブに送信し、
   前記他のスレーブの処理部は、
   前記立候補通知を新たに受信したとき、自身の記憶部を探索して、
   該立候補通知を受信する以前に記憶した提案番号が無い場合には、自身の記憶部から自身の更新番号を読み出して、該更新番号を変数とする自身の提案番号を生成し、該自身の提案番号と新たに受信した前記立候補通知の提案番号との大小を比較して、前記新たに受信した前記立候補通知の提案番号が該自身の提案番号以上のとき、前記立候補通知の提案番号を含むその立候補通知に対する確認通知を、前記立候補通知を送信したスレーブに返信し、前記新たに受信した前記立候補通知の提案番号を自身の記憶部に記憶し、
   前記立候補通知を受信する以前に記憶した提案番号がある場合には、該記憶した提案番号中で最大の提案番号を抽出し、前記新たに受信した前記立候補通知の提案番号が前記最大の提案番号以上であれば、前記立候補通知の提案番号を含むその立候補通知に対する確認通知を、前記立候補通知を送出したスレーブに送信し、前記新たに受信した前記立候補通知の提案番号を自身の記憶部に記憶し、
   前記立候補通知を送信したスレーブは、
   前記分散データ管理システムに属するすべての前記データ管理装置中の過半数の前記スレーブから前記自身の提案番号を含む確認通知を受信したときに、自身の提案番号を含む自身がマスタになることを示す提案情報をすべての前記スレーブに送信し、
   前記分散データ管理システムに属するすべての前記データ管理装置中の過半数の前記スレーブから前記提案情報に対する確認通知を受信した後、前記提案情報が確定したことを示す決定通知を前記他のスレーブに送信し、
   前記他の前記スレーブは、前記決定通知を受信し、自身の記憶部から、既に記憶されている前記立候補通知の提案番号を消去する
   ことを特徴とする分散データ管理システム。
2. 前記提案番号は、前記データの更新番号に、新しいマスタに選択される優先順位を示す前記データを識別するＩＤをさらに組み合わせたものであり、
   前記処理部は、前記提案番号の大小比較において、
   前記提案番号から取り出した更新番号同士を比較し、該更新番号の大きい方を、前記提案番号が大きいと判定し、
   前記更新番号同士が等しい場合には、前記データを識別するＩＤ同士を比較し、前記データを識別するＩＤの大きい方を、前記提案番号が大きいと判定する
   ことを特徴とする請求項１に記載の分散データ管理システム。
3. 請求項１に記載の分散データ管理システムにおいて用いられるデータ管理装置であって、
   前記スレーブの管理するデータを更新するたびに大きくなるデータの更新番号およびその更新番号が大きくなるにしたがって大きくなる前記更新番号を変数とする提案番号を記憶する記憶手段と、
   マスタ障害時に、自身の記憶部から自身の更新番号を読出し、その更新番号を変数とする提案番号を含む立候補通知を他のスレーブに送信する手段と、
   前記立候補通知を新たに受信したとき、自身の記憶部を探索して、該立候補通知を受信する以前に記憶した提案番号が無い場合には、自身の記憶部から自身の更新番号を読み出して、該更新番号を変数とする自身の提案番号を生成し、該自身の提案番号と新たに受信した前記立候補通知の提案番号との大小を比較して、前記新たに受信した前記立候補通知の提案番号が該自身の提案番号以上のとき、前記立候補通知の提案番号を含むその立候補通知に対する確認通知を、前記立候補通知を送信したスレーブに返信し、前記新たに受信した前記立候補通知の提案番号を自身の記憶部に記憶し、前記立候補通知を受信する以前に記憶した提案番号がある場合には、該記憶した提案番号中で最大の提案番号を抽出し、前記新たに受信した前記立候補通知の提案番号が前記最大の提案番号以上であれば、前記立候補通知の提案番号を含むその立候補通知に対する確認通知を、前記立候補通知を送信したスレーブに返信し、前記新たに受信した前記立候補通知の提案番号を自身の記憶部に記憶する手段と、
   受信した確認通知に含まれる提案番号ごとに受信した数をカウントする第１のカウント手段と、
   前記分散データ管理システムに属するすべての前記データ管理装置の数と前記第１のカウント手段によってカウントされた提案番号ごとの受信数との比から、前記確認通知の受信数が過半数を超えたことを判定する第１の判定手段と、
   前記第１の判定手段によって、前記確認通知の受信数が過半数を超えたと判定されたとき、自身の提案番号を含む自身がマスタになることを示す提案情報をすべての前記スレーブに送信する手段と、
   受信した前記自身の提案番号を含む自身がマスタになることを示す情報に含まれる提案番号ごとに受信した数をカウントする第２のカウント手段と、
   前記分散データ管理システムに属するすべての前記データ管理装置の数と前記第２のカウント手段によってカウントされた提案番号ごとの受信数との比から、いずれかの提案番号の前記提案情報の受信数が過半数を超えたことを判定する第２の判定手段と、
   前記第２の判定手段によって、前記提案情報の受信数が過半数を超えたと判定されたとき、前記提案情報が確定したことを示す決定通知を前記他のスレーブに送信する手段と、
   前記決定通知を受信し、自身の記憶部から、既に記憶されている前記立候補通知の提案番号を消去する手段
   とを備えることを特徴とするデータ管理装置。
4. 前記提案番号は、前記データの更新番号に、新しいマスタに選択される優先順位を示す前記データを識別するＩＤをさらに組み合わせたものであり、
   前記提案番号の大小比較において、前記提案番号から取り出した更新番号同士を比較し、該更新番号の大きい方を、前記提案番号が大きいと判定し、前記更新番号同士が等しい場合には、前記データを識別するＩＤ同士を比較し、前記データを識別するＩＤの大きい方を、前記提案番号が大きいと判定する手段
   を備えることを特徴とする請求項３に記載のデータ管理装置。
5. ３台以上のデータ管理装置がネットワークを介して相互に通信可能に接続され、前記データ管理装置の中の１台をマスタとし、他の前記データ管理装置をスレーブとして、マスタ障害時にスレーブの中から新しいマスタを選択する分散データ管理システムにおいて用いられるデータ管理方法であって、
   前記スレーブは、処理部と、当該スレーブの管理するデータを更新するたびに大きくなるデータの更新番号およびその更新番号が大きくなるにしたがって大きくなる前記更新番号を変数とする提案番号を記憶する記憶部とを備え、
   前記スレーブの処理部は、
   マスタ障害時に、自身の記憶部から自身の更新番号を読出し、その更新番号を変数とする提案番号を含む立候補通知を他のスレーブに送信し、
   前記他のスレーブの処理部は、
   前記立候補通知を新たに受信したとき、自身の記憶部を探索して、
   該立候補通知を受信する以前に記憶した提案番号が無い場合には、自身の記憶部から自身の更新番号を読み出して、該更新番号を変数とする自身の提案番号を生成し、該自身の提案番号と新たに受信した前記立候補通知の提案番号との大小を比較して、前記新たに受信した前記立候補通知の提案番号が該自身の提案番号以上のとき、前記立候補通知の提案番号を含むその立候補通知に対する確認通知を、前記立候補通知を送信したスレーブに返信し、前記新たに受信した前記立候補通知の提案番号を自身の記憶部に記憶し、
   前記立候補通知を受信する以前に記憶した提案番号がある場合には、該記憶した提案番号中で最大の提案番号を抽出し、前記新たに受信した前記立候補通知の提案番号が前記最大の提案番号以上であれば、前記立候補通知の提案番号を含むその立候補通知に対する確認通知を、前記立候補通知を送信したスレーブに返信し、前記新たに受信した前記立候補通知の提案番号を自身の記憶部に記憶し、
   前記立候補通知を送信したスレーブは、
   前記分散データ管理システムに属するすべての前記データ管理装置中の過半数の前記スレーブから前記自身の提案番号を含む確認通知を受信したときに、自身の提案番号を含む自身がマスタになることを示す提案情報をすべての前記スレーブに送信し、
   前記分散データ管理システムに属するすべての前記データ管理装置中の過半数の前記スレーブから前記提案情報に対する確認通知を受信した後、前記提案情報が確定したことを示す決定通知を前記他のスレーブに送信し、
   前記他の前記スレーブは、前記決定通知を受信し、自身の記憶部から、既に記憶されている前記立候補通知の提案番号を消去する
   ことを特徴とするデータ管理方法。
6. 前記他のスレーブの処理部は、
   前記立候補通知を新たに受信したとき、
   自身の記憶部を探索して、自身の更新番号を読出し、該更新番号を変数とする自身の提案番号を生成し、該自身の提案番号と新たに受信した前記立候補通知の提案番号との大小を比較して、前記新たに受信した前記立候補通知の提案番号が該自身の提案番号以下であれば、自身の立候補通知を自身以外の前記スレーブに送信する
   ことを特徴とする請求項５に記載のデータ管理方法。
7. 前記提案番号は、前記データの更新番号に、新しいマスタに選択される優先順位を示す前記データを識別するＩＤをさらに組み合わせたものであり、
   前記処理部は、前記提案番号の大小比較において、
   前記提案番号から取り出した更新番号同士を比較し、該更新番号の大きい方を、前記提案番号が大きいと判定し、
   前記更新番号同士が等しい場合には、前記データを識別するＩＤ同士を比較し、前記データを識別するＩＤの大きい方を、前記提案番号が大きいと判定する
   ことを特徴とする請求項５または請求項６に記載のデータ管理方法。
8. 請求項５ないし請求項７のいずれか一項に記載のデータ管理方法を、コンピュータとしてのデータ管理装置に実行させるためのプログラム。

Images