知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-05-11
(54)【発明の名称】分散データベースにおけるノード障害の検出及び解決
(51)【国際特許分類】
G01R 31/08 20200101AFI20220428BHJP
【ＦＩ】
G01R31/08
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2021545309
(86)(22)【出願日】2020-02-03
(85)【翻訳文提出日】2021-10-01
(86)【国際出願番号】 US2020016449
(87)【国際公開番号】W WO2020160557
(87)【国際公開日】2020-08-06
(31)【優先権主張番号】62/800,009
(32)【優先日】2019-02-01
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】521343220
【氏名又は名称】ヌオディービー インコーポレイテッド
(74)【代理人】
【識別番号】100094569
【弁理士】
【氏名又は名称】田中 伸一郎
(74)【代理人】
【識別番号】100103610
【弁理士】
【氏名又は名称】▲吉▼田 和彦
(74)【代理人】
【識別番号】100109070
【弁理士】
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100086771
【弁理士】
【氏名又は名称】西島 孝喜
(74)【代理人】
【識別番号】100109335
【弁理士】
【氏名又は名称】上杉 浩
(74)【代理人】
【識別番号】100120525
【弁理士】
【氏名又は名称】近藤 直樹
(74)【代理人】
【識別番号】100139712
【弁理士】
【氏名又は名称】那須 威夫
(74)【代理人】
【識別番号】100151987
【弁理士】
【氏名又は名称】谷口 信行
(72)【発明者】
【氏名】ボダガラ スリーナト
(72)【発明者】
【氏名】シャウル ロス
(72)【発明者】
【氏名】スミス ポール ディー
【テーマコード（参考）】
2G033
【Ｆターム（参考）】
2G033AA08
2G033AB01
2G033AC00
2G033AG14
(57)【要約】
本明細書では、分散データベースシステムにおける障害を検出及び解決するための方法及びシステムについて説明する。分散データベースシステム内の第１のノードは、分散データベースシステム内の少なくとも１つの他のノードとの通信の中断を検出し得る。これはネットワーク障害を示している。この障害の検出に応答して、第１のノードは障害解決プロトコルを開始する。これにより、隣接ノード間でのそれぞれの被疑ノードのリストの協調的なブロードキャストが呼び出される。各ノードは、自身の被疑ノードのリストを自身の隣接機の被疑ノードのリストと比較して、どのノードがまだ互いに直接接続されているかを特定する。各ノードは、これらの直接接続されたノードの最大のグループを決定し、自身がそのグループ内にいるか否かを判定する。ノードがそのグループ内にいない場合、ノードはネットワーク障害を解決するために自身を機能停止させる。
【選択図】図１
【選択図】図１
【特許請求の範囲】
【請求項1】
分散データベースにおける障害を解決する方法であって、前記分散データベースは複数のノードを含み、前記複数のノード内の各ノードは前記複数のノード内の他の各ノードに直接接続され、前記方法は、前記障害を検出したことに応答して、前記複数のノード内の第１のノードにおいて、
前記複数のノード内の被疑ノードを識別することであって、前記被疑ノードは、前記障害の結果として前記第１のノードに接続されなくなった前記複数のノード内のノードである、前記識別することと、
第１の被疑ノードのリストを前記複数のノード内の隣接ノードにブロードキャストすることであって、前記第１の被疑ノードのリストは前記被疑ノードを含み、前記隣接ノードは、前記障害後に前記第１のノードに直接接続されたままである前記複数のノード内のノードである、前記ブロードキャストすることと、
前記隣接ノードのうちの少なくとも１つから第２の被疑ノードのリストを受信することと、
前記第１の被疑ノードのリスト及び前記第２の被疑ノードのリストに少なくとも部分的に基づいて、前記複数のノードの接続情報を決定することと、
前記接続情報に基づいて、前記第１のノードが前記分散データベースの勝利全接続コンポーネント内にあるかどうかを判定することであって、前記勝利全接続コンポーネントは、前記複数のノード内の前記ノードの半数超を含み、前記勝利全接続コンポーネントノード内の各ノードは、前記勝利全接続コンポーネントノード内の他の各ノードに直接接続されている、前記判定することと、
前記第１のノードが前記複数のノードの前記勝利全接続コンポーネント内にあると判定したことに応答して、前記第１のノードの動作を継続させることと、
前記第１のノードが前記複数のノードの前記勝利全接続コンポーネント内にないと判定したことに応答して、前記障害を解決するために前記第１のノードを機能停止させることと、
を含む、前記方法。
【請求項2】
前記第１の被疑ノードのリストをブロードキャストすることは、前記第１のノードによって呼び出された前記方法の反復を示すプロトコル反復番号をブロードキャストすることを含む、請求項１に記載の方法。
【請求項3】
前記プロトコル反復番号を、前記第２の被疑ノードのリストと共に受信されたプロトコル反復番号と比較することをさらに含む、請求項２に記載の方法。
【請求項4】
マスターカタログの一部として前記プロトコル反復番号をシリアライズすることであって、前記マスターカタログは、前記複数のノード内の前記ノードのリストを含む、前記シリアライズすることをさらに含む、請求項２に記載の方法。
【請求項5】
前記接続情報を決定することは、前記第１のノードにおいて、前記接続情報に少なくとも部分的に基づいて接続グラフを決定することと、
前記接続グラフから前記勝利全接続コンポーネントを特定することと、
をさらに含む、請求項１に記載の方法。
【請求項6】
前記勝利全接続コンポーネントを特定することは、前記勝利全接続コンポーネントのサイズ及び前記複数のノードのサイズに基づいて、前記勝利全接続コンポーネントを決定すること
を含む、請求項５に記載の方法。
【請求項7】
前記第１のノードが前記勝利全接続コンポーネント内にあるかどうかを判定することは、前記第１のノードにおいて、前記接続情報に基づいて前記勝利全接続コンポーネントを特定することを含む、請求項１に記載の方法。
【請求項8】
前記勝利全接続コンポーネントを特定することは、前記接続情報に基づいて前記分散データベースの第１の全接続コンポーネントを特定することであって、前記第１の全接続コンポーネント内の各ノードは前記第１の全接続コンポーネント内の他の各ノードに直接接続されている、前記特定することと、
前記接続情報に基づいて前記分散データベースの第２の全接続コンポーネントを特定することであって、前記第２の全接続コンポーネントは前記第１の全接続コンポーネントとは異なり、前記第２の全接続コンポーネント内の各ノードは前記第２の全接続コンポーネント内の他の各ノードに直接接続されている、前記特定することと、
前記第１の全接続コンポーネントが、（ｉ）前記第２の全接続コンポーネントよりも多くのノードと、（ｉｉ）前記複数のノード内の前記ノードの半数超と、を含むと判定することと、
前記第１の全接続コンポーネントを前記勝利全接続コンポーネントとして選択することと、
を含む、請求項７に記載の方法。
【請求項9】
前記勝利全接続コンポーネントを特定することは、前記接続情報に基づいて前記分散データベースの第１の全接続コンポーネントを特定することであって、前記第１の全接続コンポーネント内の各ノードは前記第１の全接続コンポーネント内の他の各ノードに直接接続されている、前記特定することと、
前記接続情報に基づいて前記分散データベースの第２の全接続コンポーネントを特定することであって、前記第２の全接続コンポーネントは前記第１の全接続コンポーネントとは異なり、前記第２の全接続コンポーネント内の各ノードは前記第２の全接続コンポーネント内の他の各ノードに直接接続されている、前記特定することと、
前記第１の全接続コンポーネントが、（ｉ）前記第２の全接続コンポーネントと同数のノードと、（ｉｉ）前記複数のノード内の前記ノードの半数超と、を含むと判定することと、
前記第１の全接続コンポーネント及び前記第２の全接続コンポーネント内の前記ノードの一意の識別子に基づいて、前記第１の全接続コンポーネントを前記勝利全接続コンポーネントとして選択することと、
を含む、請求項７に記載の方法。
【請求項10】
前記第２の被疑ノードのリストを前記第１のノードから少なくとも１つの隣接ノードに送信することをさらに含む、請求項１に記載の方法。
【請求項11】
前記第２の被疑ノードのリストに少なくとも部分的に基づいて、前記第１の被疑ノードのリストを更新することと、前記更新された第１の被疑ノードのリストを前記第１のノードから前記隣接ノードにブロードキャストすることと、
をさらに含む、請求項１に記載の方法。
【請求項12】
前記第１のノードは、前記複数のノードのうちの半数未満を被疑ノードとして識別する、請求項１に記載の方法。
【請求項13】
前記複数のノード内の第３のノードにおいて、前記複数のノードの半数超を被疑ノードとして識別することと、前記障害を解決するために前記第３のノードを機能停止させることと、
をさらに含む、請求項１に記載の方法。
【請求項14】
前記障害の検出に応答して前記複数のノードに加入しようとしている第３のノードを機能停止させることをさらに含む、請求項１に記載の方法。
【請求項15】
前記障害は第１の障害であり、前記被疑ノードは第１の被疑ノードであり、前記複数のノード内の第３のノードにおいて、前記分散データベースにおける第２の障害を検出することと、
前記複数のノード内の第２の被疑ノードを識別することであって、前記第２の被疑ノードは、前記第２の障害の結果として前記第３のノードに直接接続されなくなった前記複数のノード内のノードである、前記識別することと、
第３の被疑ノードのリストを前記第１のノードにブロードキャストすることと、
前記第１のノードによって前記方法を再開始することと、
をさらに含む、請求項１に記載の方法。
【請求項16】
分散データベースにおける障害を解決するための方法であって、前記分散データベースは複数のノードを含み、前記複数のノード内の各ノードは前記複数のノード内の他の各ノードに直接接続され、前記方法は、前記複数のノード内の第１のノードにおいて、
前記複数のノード内の第２のノードとの通信の中断を検出することと、
前記中断を検出したことに応答して、前記複数のノード内の隣接ノード間でそれぞれの被疑ノードのリストの協調的なブロードキャストを開始することであって、前記隣接ノードは、前記第１のノードに直接接続されたままである前記複数のノード内のノードであり、前記第１のノードの前記被疑ノードのリストは前記第２のノードを含む、前記開始することと、
前記それぞれの被疑ノードのリストに基づいて接続情報を決定することと、
前記接続情報に少なくとも部分的に基づいて前記障害を解決することと、
を含む、前記方法。
【請求項17】
各隣接ノードにおいて、前記隣接ノードの被疑ノードのリストと、少なくとも１つの他の隣接ノードからの前記被疑ノードのリストとの比較を実行することと、
前記隣接ノードの被疑ノードのリストと、前記少なくとも１つの他の隣接ノードからの前記被疑ノードのリストとの前記比較に少なくとも部分的に基づいて、前記接続情報の少なくとも一部を決定することと、
をさらに含む、請求項１６に記載の方法。
【請求項18】
前記隣接ノードのそれぞれにおいて、前記接続情報に少なくとも部分的に基づいて接続グラフを用意することをさらに含む、請求項１６に記載の方法。
【請求項19】
前記第１のノードは、前記接続グラフに少なくとも部分的に基づいて自身を機能停止させる、請求項１８に記載の方法。
【請求項20】
前記協調的なブロードキャストは、前記障害を検出するために前記第１のノードが呼び出した前記障害解決プロトコルを示すプロトコル反復番号を前記第１のノードによってブロードキャストすることを含む、請求項１８に記載の方法。
【請求項21】
分散データベースにおける障害を解決するための方法であって、前記分散データベースは複数のノードを含み、前記複数のノード内の各ノードは前記複数のノード内の他の各ノードに接続され、前記方法は、前記障害を検出したことに応答して、前記複数のノード内の第１のノードにおいて、
前記第１のノードが前記複数のノード内の前記ノードの少なくとも半数に直接接続されているかどうかを判定することと、
前記第１のノードが前記複数のノード内の前記ノードの半数未満に直接接続されていると判定したことに応答して、前記障害を少なくとも部分的に解決するために前記第１のノードを機能停止させることと、
前記第１のノードが前記複数のノード内の前記ノードの少なくとも半数に直接接続されていると判定したことに応答して、第１の被疑ノードのリストを前記複数のノード内の隣接ノードにブロードキャストすることであって、前記第１の被疑ノードのリストは前記第１のノードに直接接続されていないノードを含み、前記隣接ノードは、前記障害後に前記第１のノードに直接接続されたままのノードである、前記ブロードキャストすることと、
前記隣接ノードのうちの少なくとも１つから第２の被疑ノードのリストを受信することと、
前記第１の被疑ノードのリストが前記第２の被疑ノードのリストと一致するかどうかを判定することと、
前記第１の被疑ノードのリストが前記第２の被疑ノードのリストと一致すると判定したことに応答して、前記障害の少なくとも部分的な解決において前記第１のノードを動作可能に維持することと、
前記第１の被疑ノードのリストが前記第２の被疑ノードのリストと一致しないと判定したことに応答して、前記第１の被疑ノードのリスト及び前記第２の被疑ノードのリストに基づいて第１の更新された被疑ノードのリストを前記隣接ノードにブロードキャストすることと、
前記隣接ノードのうちの少なくとも１つから少なくとも１つの第２の更新された被疑ノードのリストを受信することと、
前記第１の更新された被疑ノードのリスト及び前記第２の更新された被疑ノードのリストに少なくとも部分的に基づいて、前記複数のノードの接続情報を決定することと、
前記接続情報に基づいて前記分散データベースの勝利全接続コンポーネントを決定することであって、前記勝利全接続コンポーネントは前記複数のノード内の前記ノードの半数超を含み、前記勝利全接続コンポーネント内の各ノードは前記勝利全接続コンポーネント内の他の各ノードに直接接続されている、前記決定することと、
前記第１のノードが前記勝利全接続コンポーネント内にあるかどうかを判定することと、
前記第１のノードが前記複数のノードの前記勝利全接続コンポーネント内にあると判定したことに応答して、前記障害を少なくとも部分的に解決するために前記第１のノードの動作を継続させることと、
前記第１のノードが前記複数のノードの前記勝利全接続コンポーネント内にないと判定したことに応答して、前記障害を少なくとも部分的に解決するために前記第１のノードを機能停止させることと、
を含む、前記方法。
【請求項22】
分散データベースシステムであって、複数のノードを備え、前記複数のノード内の各ノードは、対応するプロセッサ及び対応するメモリを含み、前記複数のノード内の他の全てのノードに直接接続され、前記複数のノード内の第１のノードの前記プロセッサは、前記分散データベースシステム内の障害を解決することを、
前記複数のノード内の被疑ノードを識別することであって、前記被疑ノードは、前記分散データベースシステム内の障害の結果として前記第１のノードに接続されなくなった前記複数のノード内のノードである、前記識別することと、
第１の被疑ノードのリストを前記複数のノード内の隣接ノードにブロードキャストすることであって、前記第１の被疑ノードのリストは前記被疑ノードを含み、前記隣接ノードは、前記障害後に前記第１のノードに直接接続されたままである前記複数のノード内のノードである、前記ブロードキャストすることと、
前記隣接ノードのうちの少なくとも１つから第２の被疑ノードのリストを受信することと、
前記第１の被疑ノードのリスト及び前記第２の被疑ノードのリストに少なくとも部分的に基づいて、前記複数のノードの接続情報を決定することと、
前記接続情報に基づいて、前記第１のノードが前記分散データベースの勝利全接続コンポーネント内にあるかどうかを判定することであって、前記勝利全接続コンポーネントは、前記複数のノード内の前記ノードの半数超を含み、前記勝利全接続コンポーネントノード内の各ノードは、前記勝利全接続コンポーネントノード内の他の各ノードに直接接続されている、前記判定することと、
前記第１のノードが前記複数のノードの前記勝利全接続コンポーネント内にあると判定したことに応答して、前記第１のノードの動作を継続させることと、
前記第１のノードが前記複数のノードの前記勝利全接続コンポーネント内にないと判定したことに応答して、前記障害を解決するために前記第１のノードを機能停止させることと、
によって行うように構成される、前記分散データベースシステム。
【請求項23】
前記第１のノードの前記プロセッサは、障害解決反復番号を前記第１の被疑ノードのリストと共にブロードキャストするように構成される、請求項２２に記載の分散データベースシステム。
【請求項24】
前記第１のノードの前記プロセッサは、前記プロトコル反復番号を、前記第２の被疑ノードのリストと共に受信されたプロトコル反復番号と比較するように構成される、請求項２３に記載の分散データベースシステム。
【請求項25】
前記第１のノードの前記プロセッサは、マスターカタログの一部として前記プロトコル反復番号をシリアライズするようにさらに構成され、前記マスターカタログは、前記複数のノード内の前記ノードのリストを含む、請求項２３に記載の分散データベースシステム。
【請求項26】
前記第１のノードの前記プロセッサは、前記接続情報を決定することを、前記接続情報に少なくとも部分的に基づいて接続グラフを決定することと、
前記接続グラフから前記勝利全接続コンポーネントを特定することと、
によって行うように構成される、請求項２２に記載の分散データベースシステム。
【請求項27】
前記勝利全接続コンポーネントを特定することは、前記勝利全接続コンポーネントのサイズ及び前記複数のノードのサイズに基づいて、前記勝利全接続コンポーネントを決定すること
を含む、請求項２６に記載の分散データベースシステム。
【請求項28】
前記第１のノードが前記勝利全接続コンポーネント内にあるかどうかを判定することは、前記接続情報に基づいて前記勝利全接続コンポーネントを特定することを含む、請求項２２に記載の分散データベースシステム。
【請求項29】
前記勝利全接続コンポーネントを特定することは、前記接続情報に基づいて前記分散データベースの第１の全接続コンポーネントを特定することであって、前記第１の全接続コンポーネント内の各ノードは前記第１の全接続コンポーネント内の他の各ノードに直接接続されている、前記特定することと、
前記接続情報に基づいて前記分散データベースの第２の全接続コンポーネントを特定することであって、前記第２の全接続コンポーネントは前記第１の全接続コンポーネントとは異なり、前記第２の全接続コンポーネント内の各ノードは前記第２の全接続コンポーネント内の他の各ノードに直接接続されている、前記特定することと、
前記第１の全接続コンポーネントが、（ｉ）前記第２の全接続コンポーネントよりも多くのノードと、（ｉｉ）前記複数のノード内の前記ノードの半数超と、を含むと判定することと、
前記第１の全接続コンポーネントを前記勝利全接続コンポーネントとして選択することと、
を含む、請求項２８に記載の分散データベースシステム。
【請求項30】
前記勝利全接続コンポーネントを特定することは、前記接続情報に基づいて前記分散データベースの第１の全接続コンポーネントを特定することであって、前記第１の全接続コンポーネント内の各ノードは前記第１の全接続コンポーネント内の他の各ノードに直接接続されている、前記特定することと、
前記接続情報に基づいて前記分散データベースの第２の全接続コンポーネントを特定することであって、前記第２の全接続コンポーネントは前記第１の全接続コンポーネントとは異なり、前記第２の全接続コンポーネント内の各ノードは前記第２の全接続コンポーネント内の他の各ノードに直接接続されている、前記特定することと、
前記第１の全接続コンポーネントが、（ｉ）前記第２の全接続コンポーネントと同数のノードと、（ｉｉ）前記複数のノード内の前記ノードの半数超と、を含むと判定することと、
前記第１の全接続コンポーネント及び前記第２の全接続コンポーネント内の前記ノードの一意の識別子に基づいて、前記第１の全接続コンポーネントを前記勝利全接続コンポーネントとして選択することと、
を含む、請求項２８に記載の分散データベースシステム。
【請求項31】
前記第１のノードの前記プロセッサは、前記分散データベースシステム内の前記障害を解決することを、前記第２の被疑ノードのリストを前記第１のノードから少なくとも１つの隣接ノードに送信することによって行うようにさらに構成される、請求項２２に記載の分散データベースシステム。
【請求項32】
前記第１のノードの前記プロセッサは、前記分散データベースシステム内の前記障害を解決することを、前記第２の被疑ノードのリストに少なくとも部分的に基づいて、前記第１の被疑ノードのリストを更新することと、
前記更新された第１の被疑ノードのリストを前記第１のノードから前記隣接ノードにブロードキャストすることと、
によって行うようにさらに構成される、請求項２２に記載の分散データベースシステム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、２０１９年２月１日に出願された「Ｎｏｄｅ Ｆａｉｌｕｒｅ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒｅｓｏｌｕｔｉｏｎ」と題された米国出願第６２／８００，００９号の、米国特許法第１１９条（ｅ）に基づく優先権の利益を主張し、その開示は全体が引用により本明細書に組み込まれている。
本出願は、２０１９年２月１日に出願された「Ｎｏｄｅ Ｆａｉｌｕｒｅ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒｅｓｏｌｕｔｉｏｎ」と題された米国出願第６２／８００，００９号の、米国特許法第１１９条（ｅ）に基づく優先権の利益を主張し、その開示は全体が引用により本明細書に組み込まれている。
【背景技術】
【0002】
分散データベースにおけるデータ及びメタデータは、相互に通信する複数のノードにわたって記憶される。しかしながら、ノード間で通信の中断が発生することがある。たとえば、分散データベースシステム内のノードは、自身が不整合状態にあることに気付いて、クラッシュまたは機能停止し得る。他の例では、分散データベースシステム内のノード上で動作している仮想マシンまたはプロセスが、クラッシュまたは機能停止し得る。さらに他の例では、分散データベースシステム内の第１のノード及び第２のノードの間の通信リンクに障害が発生し得る。たとえば、分散データベースシステム内の２つ以上のノードを接続するネットワーク（たとえば、ローカルエリアネットワーク、ワイドエリアネットワーク、イーサネットなど）に障害が発生して、ノード間の通信が中断され得る。
【発明の概要】
【0003】
本明細書では、分散データベースシステムについて説明する。分散データベースシステムは、複数のノードを含むことができる。複数のノード内の各ノードは、対応するプロセッサ及び対応するメモリを含むことができる。複数のノード内の各ノードは、複数のノード内の他の全てのノードに接続することができる。複数のノード内の第１のノードのプロセッサは、分散データベースシステム内の障害を解決することを、複数のノード内の被疑ノードを識別することと、第１の被疑ノードのリストを複数のノード内の隣接ノードにブロードキャストすることと、少なくとも１つの他の隣接ノードから第２の被疑ノードのリストを受信することと、接続情報に基づいて、第１のノードが分散データベースの勝利全接続コンポーネント（ｗｉｎｎｉｎｇ ｆｕｌｌｙ ｃｏｎｎｅｃｔｅｄ ｃｏｍｐｏｎｅｎｔ）内にあるかどうかを判定することと、第１のノードが複数のノードの勝利全接続コンポーネント内にあると判定したことに応答して、第１のノードの動作を継続させることと、第１のノードが複数のノードの勝利全接続コンポーネント内にないと判定したことに応答して、障害を解決するために第１のノードを機能停止させることと、によって行うように構成することができる。被疑ノードは、分散データベースシステム内の障害の結果として第１のノードに接続されなくなった複数のノード内のノードとすることができる。第１の被疑ノードのリストは被疑ノードを含むことができる。隣接ノードは、ネットワーク障害後に第１のノードに直接接続されたままである複数のノード内のノードとすることができる。勝利全接続コンポーネントは、複数のノード内のノードの半数超を含むことができ、勝利全接続コンポーネントノード内の各ノードは、勝利全接続コンポーネントノード内の他の各ノードに直接接続されている。
【0004】
本明細書では、分散データベースにおける障害を解決するための方法について説明する。分散データベースは複数のノードを含むことができ、複数のノード内の各ノードは複数のノード内の他の各ノードに直接接続することができる。この方法は、複数のノード内の第１のノードにおいて、複数のノード内の第２のノードとの通信の中断を検出することと、中断を検出したことに応答して、複数のノード内の隣接ノード間でそれぞれの被疑ノードのリストの協調的なブロードキャストを開始することと、それぞれの被疑ノードのリストに基づいて接続情報を決定することと、接続情報に少なくとも部分的に基づいて障害を解決することと、を含むことができる。隣接ノードは、第１のノードに直接接続されたままである複数のノード内のノードとすることができる。第１のノードの被疑ノードのリストは第２のノードを含む。
【0005】
本明細書では、分散データベースにおける障害を解決するための方法について説明する。分散データベースは複数のノードを含むことができ、複数のノード内の各ノードは複数のノード内の他の各ノードに接続することができる。この方法は、障害を検出したことに応答して、複数のノード内の第１のノードにおいて、第１のノードが複数のノード内のノードの少なくとも半数に接続されているかどうかを判定することと、第１のノードが複数のノード内のノードの半数未満に直接接続されていると判定したことに応答して、障害を少なくとも部分的に解決するために第１のノードを機能停止させることと、第１のノードが複数のノード内のノードの少なくとも半数に直接接続されていると判定したことに応答して、第１の被疑ノードのリストを複数のノード内の隣接ノードにブロードキャストすることと、隣接ノードのうちの少なくとも１つから第２の被疑ノードのリストを受信することと、第１の被疑ノードのリストが第２の被疑ノードのリストと一致するかどうかを判定することと、第１の被疑ノードのリストが第２の被疑ノードのリストと一致すると判定したことに応答して、障害の少なくとも部分的な解決において第１のノードを動作可能に維持することと、第１の被疑ノードのリストが第２の被疑ノードのリストと一致しないと判定したことに応答して、第１の被疑ノードのリスト及び第２の被疑ノードのリストに基づいて第１の更新された被疑ノードのリストを隣接ノードにブロードキャストすることと、隣接ノードのうちの少なくとも１つから少なくとも１つの第２の更新された被疑ノードのリストを受信することと、第１の更新された被疑ノードのリスト及び第２の更新された被疑ノードのリストに少なくとも部分的に基づいて、複数のノードの接続情報を決定することと、接続情報に基づいて分散データベースの勝利全接続コンポーネントを決定することと、第１のノードが勝利全接続コンポーネント内にあるかどうかを判定することと、第１のノードが複数のノードの勝利全接続コンポーネント内にあると判定したことに応答して、障害を少なくとも部分的に解決するために第１のノードの動作を継続させることと、第１のノードが複数のノードの勝利全接続コンポーネント内にないと判定したことに応答して、障害を少なくとも部分的に解決するために第１のノードを機能停止させることと、を含むことができる。第１の被疑ノードのリストは第１のノードに直接接続されていないノードを含むことができる。隣接ノードは、障害後に第１のノードに直接接続されたままのノードとすることができる。勝利全接続コンポーネントは複数のノード内のノードの半数超を含み、勝利全接続コンポーネント内の各ノードは勝利全接続コンポーネント内の他の各ノードに直接接続されている。
【0006】
前述の概念及びさらなる概念の全ての組み合わせについて、以下でより詳細に論じ（ただし、そのような概念が相互に矛盾していない場合に限る）、それらは本明細書で開示した本発明の主題の一部である。詳細には、本開示の最後にある特許請求した主題の全ての組み合わせは、本明細書で開示した本発明の主題の一部である。引用により組み込まれているあらゆる開示にも登場し得る、本明細書で使用する用語には、本明細書で開示した特定の概念に最も一致する意味が与えられるものとする。
【0007】
当業者であれば理解するように、図面は主に説明を目的としており、本明細書で説明する本発明の主題の範囲を限定することは意図していない。図面は必ずしも一定の比率ではなく、場合によっては、異なる特徴の理解を容易にするために、本明細書で開示した本発明の主題の種々の態様を図面内で誇張または拡大して示す場合がある。図面では、同様の参照文字は通常、同様の特徴（たとえば、機能的に同様及び／または構造的に同様の要素）を指す。
【図面の簡単な説明】
【0008】
【図1】ネットワーク障害を解決して分散データベース内のノード間の完全な接続を修復する処理を示す図である。
【図2】ネットワーク分断イベントによって分散データベースシステムが全接続されたノードの２つの非連結グループに分割される、分散データベースシステムにおけるネットワーク障害の典型的なケースの一例を示す図である。
【図12】ネットワーク障害を解決する拡張された処理を示すフローチャートである。
【図13】分散データベースシステムにおいてネットワーク分断によって新しいノード及びエントリノードが残りのノードから分離されるときの、分散データベースシステムにおけるメンバーシップ変更を示す図である。
【図15】分散データベースシステムにおいてネットワーク分断によって新しいノード、エントリノード、及び一部のピアが残りのピアから分離されるときの、分散データベースシステムにおけるメンバーシップ変更を示す図である。
【図16】分散データベースシステムにおいてネットワーク分断によってエントリノードが残りのノードから分離されるときの、分散データベースシステムにおけるメンバーシップ変更を示す図である。
【図17】分散データベースシステムにおいてネットワーク分断によって新しいノード、エントリノード、及び一部のピアが残りのノードから分離されるときの、分散データベースシステムにおけるメンバーシップ変更を示す図である。
【図18】分散データベースシステムにおいてネットワーク分断によって新しいノード、エントリノード、及び一部のピアが残りのノードから分離されるときの、分散データベースシステムにおけるメンバーシップ変更の他の図である。
【図19】ノードが障害検出メッセージを交換してネットワーク障害イベントを解決することを示す図である。
【図20】障害検出メッセージを交換しながらノード障害に対処することを示す図である。
【図21】フェイルオーバーを実行しながらノード障害に対処することを示す図である。
【発明を実施するための形態】
【0009】
分散データベースシステムは、分散データベースのデータ及び／またはメタデータのフラグメントを記憶する複数のノードを含む。分散データベースシステム内の全てのノードは、相互に通信できるように相互に直接接続される。しかしながら、分散データベースシステム内の１つまたは複数のノードが、ネットワーク障害が原因で通信の中断を被る場合があり得る。これらの通信の中断は、２つ以上のノード間の通信リンクの障害、あるいは１つまたは複数のノードの障害が原因であり得る。これらの障害は、以下でさらに詳細に説明するように、まだ相互に直接接続されているノードを識別し、直接接続されたノードの最大のグループを特定し、そのグループの一部ではないノードを機能停止させることによって、解決することができる。
【0010】
分散データベースシステム
分散データベースシステムは、２タイプのノード、すなわち、分散データベースへのユーザアクセスを提供するトランザクションエンジン（ＴＥ）ノードと、分散データベース全体のそれぞれのディスクアーカイブを維持するストレージマネージャ（ＳＭ）ノードとを含むことができる。各ストレージマネージャノードは通常、分散データベース全体のコピーを記憶するが、単一のトランザクションエンジンノードは、そのトランザクションエンジンノードでそのときに実行されているトランザクションをサポートするために必要な分散データベースの一部のみを含み得る。
分散データベースシステムは、２タイプのノード、すなわち、分散データベースへのユーザアクセスを提供するトランザクションエンジン（ＴＥ）ノードと、分散データベース全体のそれぞれのディスクアーカイブを維持するストレージマネージャ（ＳＭ）ノードとを含むことができる。各ストレージマネージャノードは通常、分散データベース全体のコピーを記憶するが、単一のトランザクションエンジンノードは、そのトランザクションエンジンノードでそのときに実行されているトランザクションをサポートするために必要な分散データベースの一部のみを含み得る。
【0011】
分散データベースシステム内の各ノードは、独自のプロセッサ、メモリ、及び通信インターフェース（複数可）を有し、データベースシステムネットワークを介して分散データベースシステム内の他の全てのノードと直接通信することができる。任意の２つのノード間の通信は、シリアライズされたメッセージの送信を含むことができる。シリアライズされたメッセージは、伝送制御プロトコル（ＴＣＰ）または他の任意の適切なメッセージングプロトコルに従うことができる。
【0012】
分散データベースシステム内の各ノードは、一意の識別子（たとえば、辞書式ＩＤ）を有し、他の全てのノードのリストを一意の識別子の順に分散データベースシステムに記憶する。各ノードはこのリストを使用して、分散データベースシステム内の全てのトランザクションエンジンノード及びストレージマネージャノードのステータスを追跡する。さらに、各ノードは、全てのデータベーストランザクションと、全てのデータベースレコードの場所（すなわち、どのノードがどのデータフラグメントを記憶しているか）とを追跡し得る。ノードは、このノード及びトランザクション情報をマスターカタログのそれぞれのコピーに記憶し得、マスターカタログは、分散データベースシステムに関するメタデータを含み、データベース内の全てのノードに複製される。新しいノードは、分散データベースシステムに加入する場合に、エントリノードと呼ばれる他のノードからマスターカタログのコピーを受信する。
【0013】
データベーストランザクションとデータベースフラグメントの場所とを追跡することは、分散データベースシステムが、分散データベース内のデータの正確性、完全性、及び整合性を確保するために、一般にＡＣＩＤプロパティとして知られている、不可分性、一貫性、独立性、及び永続性を維持するのに役立つ。
【0014】
ネットワーク障害及び障害検出
分散データベースシステム内の各ノードは、「ハートビート」メッセージを分散データベースシステム内の他の全てのノードに頻繁な間隔で送信する。たとえば、各ノードは毎秒または数秒ごとに他の全てのノードにハートビートメッセージを送信する。（任意選択により、ハートビートメッセージを受信したノードは、ハートビートメッセージを送信したノードに確認応答メッセージを送信することができる。）通信の中断がない場合、分散データベースシステム内の全てのノードは、分散データベースシステム内の他の全てのノードにハートビートメッセージを直接送信し、これらからハートビートを直接受信し続ける。しかしながら、ネットワーク障害によって、そのような通信が中断され得る。通信の中断を検出したノード（たとえば、他のノードから所定の時間内にハートビートメッセージを受信していないもの）は、ネットワーク障害を解決するために障害解決プロトコルを開始する。
分散データベースシステム内の各ノードは、「ハートビート」メッセージを分散データベースシステム内の他の全てのノードに頻繁な間隔で送信する。たとえば、各ノードは毎秒または数秒ごとに他の全てのノードにハートビートメッセージを送信する。（任意選択により、ハートビートメッセージを受信したノードは、ハートビートメッセージを送信したノードに確認応答メッセージを送信することができる。）通信の中断がない場合、分散データベースシステム内の全てのノードは、分散データベースシステム内の他の全てのノードにハートビートメッセージを直接送信し、これらからハートビートを直接受信し続ける。しかしながら、ネットワーク障害によって、そのような通信が中断され得る。通信の中断を検出したノード（たとえば、他のノードから所定の時間内にハートビートメッセージを受信していないもの）は、ネットワーク障害を解決するために障害解決プロトコルを開始する。
【0015】
ネットワーク障害の解決
ここで示す障害解決処理では、分散データベース内のノードは、ネットワーク障害に応じて自身らを再グループ化し、自身らが、辞書式ＩＤの順位が最も先の、多数派のサイズの、最大の全接続されたノードグループの一部でない場合に、自身らを機能停止させる。最大の全接続されたグループが分散データベースシステム内の半数未満のノードを含む場合、全てのノードが自身らを機能停止させ得る。切断または部分接続されたノードを機能停止させることにより、データベースの一部または全部が無効になり得る可能性が低くなる。これらの障害解決処理は、リーダーなしの方法で、進行中のデータベーストランザクションをブロックまたは中止することなく、実行することができる。
ここで示す障害解決処理では、分散データベース内のノードは、ネットワーク障害に応じて自身らを再グループ化し、自身らが、辞書式ＩＤの順位が最も先の、多数派のサイズの、最大の全接続されたノードグループの一部でない場合に、自身らを機能停止させる。最大の全接続されたグループが分散データベースシステム内の半数未満のノードを含む場合、全てのノードが自身らを機能停止させ得る。切断または部分接続されたノードを機能停止させることにより、データベースの一部または全部が無効になり得る可能性が低くなる。これらの障害解決処理は、リーダーなしの方法で、進行中のデータベーストランザクションをブロックまたは中止することなく、実行することができる。
【0016】
図１は、ネットワーク障害を解決する処理１００を示している。分散データベースシステム内の任意のノードが、ネットワーク障害（たとえば、所定の期間内の他のノードからのハートビートメッセージの受信の失敗）を検出したことに応答して、この処理１００を開始することができる。１０２において、第１のノードはネットワーク障害を検出し、「被疑ノード」、すなわち、第１のノードが障害の発生を疑っているノードのリストを作成することによって、障害解決処理１００を開始する。たとえば、第１のノードの被疑リストは、（ａ）第１のノードが所定のタイムアウト間隔（たとえば、ｐｉｎｇＴｉｍｅｏｕｔ秒）内にそれらのノードからハートビートメッセージを受信していないという条件、及び（ｂ）オペレーティングシステムが第１のノード及びその他のノード（複数可）の間の接続（複数可）を閉じたという条件、の一方または両方を満たすノードのリストである。この時点で、第１のノードの被疑リストが分散データベースシステム内の他の全てのノードを含む場合、第１のノードはネットワーク障害を少なくとも部分的に解決するために、自身を機能停止させ得る。
【0017】
１０４において、第１のノード（すなわち、処理１００を開始したノード）は、自身の被疑ノードリストを自身の隣接ノードにブロードキャストし、隣接ノードは、ネットワーク障害後に第１のノードがまだ直接通信することができるノードである。（ネットワーク障害がない場合、分散データベースにおいて、全てのノードは他の全てのノードの隣接機（ｎｅｉｇｈｂｏｒ）である。）隣接ノードはこの被疑リストを受信し、自身らの被疑リストを自身らの隣接機にブロードキャストする。隣接ノードの被疑リストは、ネットワーク障害の性質に応じて、第１のノードの被疑リストと同一であり得、または異なり得る。
【0018】
１０６において、第１のノードは、自身の隣接ノードから被疑リストを受信し、それら及び自身の被疑リストを使用して、接続グラフを構築する。接続グラフは、分散データベースシステム内のどのノードに第１のノードが実際に直接接続されているか（すなわち、どのノードが実際に第１のノードの隣接ノードであるか）を示す。その他のノードも接続グラフを構築する。ネットワーク障害の性質に応じて、これらの接続グラフは、第１のノードの接続グラフと同じであり得、または異なり得る。同様に、各接続グラフは、対応するノードの被疑リストを補うものであり得る。
【0019】
各ノードは、自身の接続グラフを使用して、ネットワーク障害後に相互に直接接続されたままのノードのグループを識別する。直接接続されたノードの各グループを、「全接続コンポーネント」と呼ぶ。全接続コンポーネント内では、各ノードは、ネットワーク障害後も全接続コンポーネント内の他の全てのノードとの通信を継続する。各ノードは、分散データベースシステム内で全接続コンポーネントを特定すると、自身が「勝利全接続コンポーネント」の一部であるかどうかを判定する（１１０）。自身が全接続コンポーネントの一部でない場合、各ノードはネットワーク障害を解決するために自身を機能停止させる（１１２）。自身が勝利全接続コンポーネントの一部である場合、動作を継続する（１１４）。
【0020】
勝利全接続コンポーネントは、データベース内の全てのデータを含むことができるが、必須ではない（たとえば、ストレージマネージャノードを含む必要はない）。この手順は、勝利全接続コンポーネントを形成するノードのタイプを考慮しない。（ただし、場合によっては、この処理は、勝利全接続コンポーネントを決定する場合に、全接続コンポーネント内のノードのタイプに注意を払うように修正することができる。）勝利全接続コンポーネントが分散データベース内の全てのデータを含まない場合、ユーザは適切な動作を確保するために介入し得る。
【0021】
各ノードは、自身が勝利全接続コンポーネントの一部であるかどうかを次のように判定することができる。まず、各ノードは、自身の接続グラフに基づいて、自身が全接続コンポーネントの一部であるかどうかを判定し得る。一部でない場合、自身を機能停止させる。しかしながら、ノードが全接続コンポーネント（または場合によっては２つ以上の全接続コンポーネント）の一部である場合、ノードは自身の接続グラフに基づいて自身の全接続コンポーネント（複数可）のサイズを特定する。（自身の接続グラフと、各ノードが分散データベースシステム内のその他のノードに関して記憶している情報とに基づいて）自身が最大の全接続コンポーネントの一部ではないとノードが判定した場合、ノードは自身を機能停止させる（１１２）。ノードが最大の全接続コンポーネントの一部であって、その全接続コンポーネントが、ネットワーク障害前の分散データベースシステム内のノードの総数の半数超を含む場合、ノードは動作可能なままとなる（１１４）。この全接続コンポーネントを、「勝利全接続コンポーネント」と呼び、その理由は、障害解決処理１００の終了時に、分散データベースシステム内の全ての動作可能なノードを含むためである。
【0022】
同じサイズで、それぞれが分散データベース内のノードの半数超を有し、他の全ての全接続コンポーネントよりも大きい２つ以上の全接続コンポーネントが存在するとノードが判定した場合、勝利全接続コンポーネントを特定するためのタイブレーク処理を実施する。タイブレーク処理は、各全接続コンポーネント内のノードを、ノードの一意の識別子の順にソートすることを含み得る。一意の識別子がソートされると、ノードは一意の識別子の辞書式順序に基づいて、勝利全接続コンポーネントを選ぶ。たとえば、ノードは、共通プレフィックスに続くノードＩＤが最小の全接続コンポーネントを、勝利全接続コンポーネントとして選び得る。
【0023】
他の障害解決処理に対する技術的利点
図１に示す障害解決処理は、分散データベースにおける障害を解決するための他の処理に比べていくつかの相違点及び利点を有する。初めに、ブロッキング処理とは異なり、図１に示す障害解決処理は、ネットワーク障害後に分散データベース内の１つまたは複数のノードを排除して、完全な全接続を修復する。ブロッキングは、分散データベース内のデータに対して行われた更新をロールバックし得るので、望ましくない。他の方法論とは異なり、本明細書に記載の処理は、いかなる種類のブロッキングメカニズムも含まない。
図１に示す障害解決処理は、分散データベースにおける障害を解決するための他の処理に比べていくつかの相違点及び利点を有する。初めに、ブロッキング処理とは異なり、図１に示す障害解決処理は、ネットワーク障害後に分散データベース内の１つまたは複数のノードを排除して、完全な全接続を修復する。ブロッキングは、分散データベース内のデータに対して行われた更新をロールバックし得るので、望ましくない。他の方法論とは異なり、本明細書に記載の処理は、いかなる種類のブロッキングメカニズムも含まない。
【0024】
さらに、図１に示す障害解決処理は、リーダーノードを必要とせず、使用もしない。逆に、分散データベースにおける障害を解決するための他の方法論は、強力なリーダーシップモデルを実装する。基本的に、この方法論はリーダーノードを使用して障害解決の判断を行う。このリーダーベースの方法論とは異なり、本明細書に記載の処理は、障害解決の判断を行うリーダーノードを有さない。代わりに、図１に関して上述したように、任意のノードが障害解決処理を開始することができ、各ノードは、処理の一部として、リーダーノードからの命令なしに、自身を機能停止させるべきか、動作可能なままにすべきかを判定する。
【0025】
ブロッキング及びリーダーベースの障害解決処理とは異なり、本明細書に記載の非ブロッキングのリーダーなしの障害解決処理は、部分接続のネットワーク障害に一貫した方法で対処することができる。部分接続のネットワーク障害では、分散データベースシステム内のネットワーク分断によって、ノードまたはノードのセットが、分散データベースシステム内のノードのサブセットとしか通信しないようになり得る。部分接続のケースに対処するために、他の処理は、ローテーション式リーダーモデルを適用して、リーダー及び情報提供機（ｉｎｆｏｒｍｅｒ）に明示的なメッセージ確認応答を使用させる。場合によっては、通信の中断を被っているノード間でリーダーシップが絶えずシフトして、ネットワーク障害の解決が（場合によっては無期限に）遅れる可能性がある。
【0026】
ネットワーク障害の様々なケース
処理１００は、ネットワーク障害イベントの後に、２つ以上の非連結ノードグループ（すなわち、異なる全接続コンポーネント）の稼働を継続させない。瑣末な解決策（たとえば、全てのノードを機能停止させる）を回避するために、処理１００は、可能な場合には、単一のノードグループが稼働を継続できるようにする。
処理１００は、ネットワーク障害イベントの後に、２つ以上の非連結ノードグループ（すなわち、異なる全接続コンポーネント）の稼働を継続させない。瑣末な解決策（たとえば、全てのノードを機能停止させる）を回避するために、処理１００は、可能な場合には、単一のノードグループが稼働を継続できるようにする。
【0027】
さらに、ユーザが分散データベースシステム内の生き残ったノードの半数以上をシャットダウンすることを選択した場合、処理１００は必ずしも残りのノードを機能停止させなくてもよい。処理１００はまた、リンク障害に加えて、低速リンク（すなわち、接続が低速な２つ以上のノード間の通信経路）に対処することができる。換言すれば、処理１００は、低速リンク及びリンク障害を同じ方法で処理する。
【0028】
【0029】
ケースＡ：図２は、ネットワーク分断イベントによって分散データベースシステム２００が全接続されたノードの２つ以上の非連結グループに分割される典型的な障害のケースを示している。図２の左側に見られるように、分散データベースシステム２００は、３つのトランザクションエンジンノードＴＥ１、ＴＥ２、及びＴＥ３と、２つのストレージマネージャノードＳＭ１及びＳＭ２とを含み、これらは全て相互に接続されている。これらのノードは、それぞれの通信リンク２１２ａ～２１２ｊを介して相互に通信し、ＴＥ１はリンク２１２ａを介してＴＥ２と通信し、ＴＥ２はリンク２１２ｄを介してＴＥ３と通信し、ＴＥ３はリンク２１２ｅを介してＳＭ２と通信し、ＳＭ２はリンク２１２ｆを介してＳＭ１と通信し、ＴＥ２はリンク２１２ｂを介してＳＭ１と通信し、ＴＥ２はリンク２１２ｃを介してＳＭ１と通信し、ＴＥ１はリンク２１２ｈを介してＳＭ２と通信し、ＴＥ３はリンク２１２ｊを介してＳＭ１と通信し、ＴＥ２はリンク２１２ｉを介してＳＭ２と通信する。
【0030】
図２の中央では、ネットワーク分断によって、コーラスが２つの非連結ノードグループ（２つの全接続コンポーネント２０２’及び２０２’’）に分割されている。（コーラスまたはコーラスグループとは、分散データベースシステム内の全てのノードのセットである。）この例では、第１の全接続コンポーネント２０２’は、｛ＴＥ１，ＴＥ２，ＳＭ１｝を含み、第２の全接続コンポーネント２０２’’は、｛ＴＥ３，ＳＭ２｝を含む。次に、処理１００は、第１の全接続コンポーネント２０２’が、第２の全接続コンポーネント２０２”よりも大きく、分散データベース２００内のノードの半数超を含むので、勝利全接続コンポーネント２０４’であると判断する。勝利全接続コンポーネント２０４’内のノード｛ＴＥ１，ＴＥ２，ＳＭ１｝は稼働を継続し、ノードＴＥ３及びＳＭ２は、自身らが勝利全接続コンポーネント２０４’内にないと気づいたことに応答して自身らを機能停止させる。
【0031】
ケースＢ：図３～図８は、部分接続の様々な例を示している。これらの各例では、ネットワーク分断または（双方向）リンク障害（複数可）によって、ノードまたはノードのセットが分散データベースシステム内の他のノードのサブセットのみと通信するようになる。部分接続のケースでは、ノード間の接続は推移性（ｔｒａｎｓｉｔｉｖｅ ｐｒｏｐｅｒｔｙ）を満たさず、すなわち、たとえば、ノードＴＥ１はノードＴＥ２と直接通信することが可能であり得、ノードＴＥ２はノードＳＭ１と直接通信することができるが、ノードＳＭ１はノードＴＥ１と直接通信することができない。
【0032】
例Ｂ１：図３は、３つのノードＴＥ１、ＴＥ２、及びＳＭ１を有する分散データベースシステム３００を示している。図３に見られるように、３つのノードＴＥ１、ＴＥ２、及びＳＭ１は、ＴＥ１がリンク２１２ａを介してＴＥ２と通信し、ＴＥ２がリンク２１２ｂを介してＳＭ１と通信し、ＳＭ１がリンク２１２ｃを介してＴＥ１と通信するコーラスグループを形成する。ＴＥ１及びＴＥ２の間のリンク２１２ａの障害（またはＴＥ１及びＴＥ２が異なるデータセンターにあると仮定すると、ＴＥ１及びＴＥ２のデータセンター間のネットワーク分断）によって、２つの全接続コンポーネント２０２’｛ＳＭ１，ＴＥ１｝及び２０２’’｛ＳＭ１，ＴＥ２｝が、ノードＴＥ１及びＴＥ２の部分接続と共に作成される。全接続コンポーネント２０２’及び２０２’’は同じサイズであり、リンク障害前に稼働していたノード数の半数超を有するので、これらのノードは、上記で論じた辞書式順序付けなどのタイブレーク処理を実施して、勝利全接続コンポーネント２０４’を決定する。図３において、｛ＳＭ１，ＴＥ１｝は、（辞書式順序などのタイブレーク処理によって決定される）勝利全接続コンポーネント２０４’であるので、ＳＭ１及びＴＥ１は稼働を継続し、ＴＥ２は自身を機能停止させる。
【0033】
例Ｂ２：図４は、５つのノードＴＥ１、ＴＥ２、ＴＥ３、ＳＭ１、及びＳＭ２のコーラスグループを有する分散データベースシステム４００を示している。この例では、２つのリンク障害が発生し、１つはＳＭ１及びＳＭ２の間（リンク２１２ｆ）であり、もう１つはＳＭ２及びＴＥ３の間（リンク２１２ｅ）である。これらの障害により、全接続コンポーネント４０２’｛ＴＥ１，ＴＥ２，ＴＥ３，ＳＭ１｝及び４０２’’｛ＴＥ１，ＴＥ２，ＳＭ２｝が生成され、ノードＳＭ２はその他のノードに部分接続されており、その他のノードは互いに直接接続されたままである。第１の全接続コンポーネント４０２’｛ＴＥ１，ＴＥ２，ＴＥ３，ＳＭ１｝は、半数超のノードを含み、他の勝利全接続コンポーネント４０２”よりも大きいので、勝利全接続コンポーネント４０４’である。ノードＳＭ２は機能停止し、その他のノードは稼働を継続する。
【0034】
例Ｂ３：図５は、４つのリンク障害を被っている５つのノードＴＥ１、ＴＥ２、ＴＥ３、ＳＭ１、及びＳＭ２のコーラスグループを有する５ノードの分散データベースシステム５００を示している。この例では、ＴＥ１及びＳＭ１の間（リンク２１２ｃ）、ＴＥ１及びＳＭ２の間（リンク２１２ｈ）、ＴＥ２及びＴＥ３の間（リンク２１２ｇ）、ならびにＴＥ３及びＳＭ１の間（リンク２１２ｊ）で４つのリンク障害が発生している。これらの障害により、いくつかの全接続コンポーネントが生成されるが、１つのみが少なくとも３つのノード｛ＴＥ２，ＳＭ１，ＳＭ２｝を有し、これを右に示す。ノードＴＥ１及びＴＥ３は、分散データベースに部分接続されたままであるが、分散データベース内の他の全てのノードと直接通信することはできない。その結果、ノードＴＥ１及びＴＥ３は機能停止して、｛ＴＥ２，ＳＭ１，ＳＭ２｝が勝利全接続コンポーネント４０４’として残る。
【0035】
図６は、図５の部分接続のケースには、ローテーション式リーダーモデルの方法論を使用して対処できない理由を示している。図６に示すように、５つのノードＴＥ１、ＴＥ２、ＴＥ３、ＳＭ１、及びＳＭ２は、ステップ１（左）でグループを形成する。ステップ１では、これらのノード全てが中断されることなく相互に通信することができる。しかしながら、ステップ２（右）に示すように、ＴＥ１及びＳＭ１の間（リンク２１２ｃ）、ＴＥ１及びＳＭ２の間（リンク２１２ｈ）、ＴＥ２及びＴＥ３の間（リンク２１２ｇ）、ならびにＴＥ３及びＳＭ１の間（リンク２１２ｊ）で通信リンクに障害が発生する。これらの障害によって、ＴＥ１及びＳＭ１の間、ＴＥ１及びＳＭ２の間、ＴＥ２及びＴＥ３の間、ならびにＴＥ３及びＳＭ１の間の直接通信が中断される。
【0036】
ＳＭ１は、ネットワーク障害の直前の現在のリーダーである。リンク障害後にローテーション式リーダーの方法論に基づいて、ＳＭ１はＴＥ２及びＳＭ２からハートビートメッセージを受信するので、自身がリーダーであるという想定を継続する。ＴＥ１及びＳＭ１の間（リンク２１２ｃ）のリンク障害が原因で、ＴＥ１がＳＭ１からハートビートメッセージを受信しないので、ＴＥ１はリーダーシップをＴＥ２にローテーションする。同様に、ＴＥ３及びＳＭ１の間（リンク２１２ｊ）のリンク障害が原因で、ＴＥ３はリーダーシップをＴＥ１にローテーションする。したがって、ＳＭ１、ＴＥ２、ＴＥ１が立て続けに（必ずしもこの順序でない）リーダーシップをとるが、ＴＥ１はＳＭ１にもＳＭ２にも接続されていないので、ＳＭ１がＳＭ２に接続されているか否かさえわからない。このローテーション式リーダーシップでは、障害（複数可）を解決することが困難になる。
【0037】
概念的には、上記のように、リーダーノードが他の全てのノードに接続されていない場合がある（ひいてはリーダーが他の全てのノードの接続情報を知らない場合がある）ので、中央集権的なリーダーベースのソリューションに部分接続のケースに適切に対処させることは困難である。しかしながら、本明細書に記載のリーダーなしの障害解決処理は、これらの部分接続のケースの全てに信頼できる方法で対処するので、リーダーベースの障害解決方法よりも改善される。
【0038】
例Ｂ４：図７は、３つのリンク障害を有する５つのノードのコーラスグループを有する分散データベースシステム７００を示しており、１つのリンク障害はＴＥ１及びＳＭ１の間（リンク２１２ｃ）であり、もう１つはＴＥ２及びＴＥ３の間（リンク２１２ｇ）であり、もう１つはＳＭ１及びＴＥ３の間（リンク２１２ｊ）である。これらの障害により、全接続コンポーネント｛ＴＥ１，ＴＥ２，ＳＭ２｝、｛ＴＥ２，ＳＭ１，ＳＭ２｝、及び｛ＴＥ１，ＳＭ２，ＴＥ３｝が生成され、ノードＴＥ１及びＴＥ２は部分接続される。これらの３つの全接続コンポーネントのそれぞれは、リンク障害前のコーラスグループのノード数の半数超を含む。さらに、これら３つの全接続された多数派グループは同じサイズである。したがって、ノードは、辞書式順序付けなどのタイブレーク処理を実施して、勝利全接続コンポーネント７０４’を特定する。この例では、｛ＴＥ２，ＳＭ１，ＳＭ２｝が、（タイブレーク処理によって決定される）勝利全接続コンポーネント７０４’である。したがって、ノードＴＥ１及びＴＥ３は、ネットワーク障害を解決するために自身らを機能停止させる。
【0039】
例Ｂ５：図８は、５つのノードＴＥ１、ＴＥ２、ＴＥ３、ＳＭ１、及びＳＭ２のコーラスグループを有する分散データベースシステム８００を示している。この例では、ＴＥ１及びＳＭ１の間（リンク２１２ｃ）、ＴＥ１及びＳＭ２の間（リンク２１２ｈ）、ＴＥ２及びＴＥ３の間（リンク２１２ｇ）、ＴＥ２及びＳＭ２の間（リンク２１２ｉ）、ならびにＴＥ３及びＳＭ１の間（リンク２１２ｊ）に５つのリンク障害が発生している。図８からわかるように、これらの障害の後に５つの全接続されたノードグループが存在し、それぞれが２つのノードのサイズである。これは、リンク障害前のコーラスグループ内のノード数の半数超より少ない。したがって、リンク障害後に全接続された多数派グループが存在しないので、全てのノードが自身らを機能停止させる。
【0040】
ケースＣ：図９は、（単方向）リンク障害（複数可）により、ノードまたはノードのセットが、一方向では他のノードのサブセットと通信できるが、他の方向では通信できない、部分接続の特殊なケースを示している。図９に見られるように、分散データベースシステム９００内の３つのノードＴＥ１、ＴＥ２、及びＳＭ１が、コーラスグループを形成する。しかしながら、ＴＥ１及びＴＥ２の間（リンク２１２ａ’’）で単方向リンク障害が発生して、ＴＥ２はＴＥ１にメッセージを送信できるが（リンク２１２ａ’）、ＴＥ１はＴＥ２にメッセージを送信できなくなる（リンク２１２ａ’’）。この単方向リンク障害により（ＴＥ１及びＴＥ２の間の双方向リンク障害と同様に）、全接続コンポーネント９０２’｛ＴＥ１，ＳＭ１｝及び９０２’’｛ＴＥ２，ＳＭ１｝が作成される。全接続コンポーネントの２つのセットは同じサイズであり、リンク障害前に稼働していたノード数の半数超（すなわち、計３つのノードのうち２つ）を含むので、ノードはタイブレーク処理を実施して、勝利全接続コンポーネント９０４’を決定する。この例では、｛ＴＥ１，ＳＭ１｝が、（上記のタイブレーク処理によって決定される）勝利全接続コンポーネント９０４’である。したがって、ノードＴＥ１及びＳＭ１は稼働を継続し、ノードＴＥ２は自身を機能停止させる。
【0041】
ケースＤ：処理１００はまた、メンバーシップ変更中にネットワーク障害が発生したことが原因で、分散データベースシステムが複数の多数派グループに分割しないようにする。メンバーシップ変更とは、新しいノードが分散データベースシステムに加入すること、または分散データベースシステムの既存のノードが分散データベースシステムから離脱することを指す。図１０は、ケースＤの一例を示している。この例では、コーラス１０００は、３つのノードＴＥ１、ＳＭ１及びＳＭ２から始まる。２つのノードＴＥ２及びＴＥ３がコーラス１０００に加入しようとする。それらが加入している最中に、ネットワーク分断が発生して、分散データベースが全接続コンポーネント１００２’｛ＴＥ２，ＴＥ３，ＴＥ１｝及び１００２’’｛ＳＭ１，ＳＭ２｝に分離される。両方のグループが稼働を継続し得、その理由は、グループ｛ＴＥ２，ＴＥ３，ＴＥ１｝のメンバーが、自身らがコーラス｛ＴＥ２，ＴＥ３，ＴＥ１，ＳＭ１，ＳＭ２｝の一部であるために、多数派を形成すると考え、グループ｛ＳＭ１，ＳＭ２｝のメンバーが、自身らがコーラス｛ＴＥ１，ＳＭ１，ＳＭ２｝の一部であるために、同様に多数派を形成すると考えるためである。処理１００は、１つのグループのみが稼働を継続するようにする。換言すれば、処理１００は、｛ＴＥ２，ＴＥ３，ＴＥ１｝及び｛ＳＭ１，ＳＭ２｝の両方が同時に稼働を継続しないようにする。
【0042】
被疑ノードに関する情報の収集及び共有
本明細書で開示する障害解決処理（たとえば、処理１００）は、リーダーなしの処理である。ネットワーク障害イベントに応答して、各ノードは自身の被疑リストを特定し、接続情報（自身のもの、及び任意選択により他のノードのもの）を他のノードと交換したのち、障害解決の判断を行う。この処理は、パーティション内の全てのノードが同じ障害解決の判断（複数可）に至るようにするために、この処理の通信フェーズの終了時に各ノードが自身のパーティション内の他のノードに関する十分な接続情報を有するような方法で、ノードに通信させて接続情報を交換させる。プロトコルの進行中に発生するいずれかの新しいネットワーク障害イベントにより、全てのノードがプロトコルを再開始する。
本明細書で開示する障害解決処理（たとえば、処理１００）は、リーダーなしの処理である。ネットワーク障害イベントに応答して、各ノードは自身の被疑リストを特定し、接続情報（自身のもの、及び任意選択により他のノードのもの）を他のノードと交換したのち、障害解決の判断を行う。この処理は、パーティション内の全てのノードが同じ障害解決の判断（複数可）に至るようにするために、この処理の通信フェーズの終了時に各ノードが自身のパーティション内の他のノードに関する十分な接続情報を有するような方法で、ノードに通信させて接続情報を交換させる。プロトコルの進行中に発生するいずれかの新しいネットワーク障害イベントにより、全てのノードがプロトコルを再開始する。
【0043】
一般に、本発明の障害解決処理は、各ノードが他のノードの被疑リスト／接続に関する情報を収集するフェーズ１と、各ノードがフェーズ１中に収集した情報に基づいて障害解決の判断を行う（たとえば、自身を機能停止させる）フェーズ２との２つのフェーズを含むことができる。
【0044】
フェーズ１中に、各ノードは最大で２ラウンドの協調的なブロードキャストに参加する。被疑リストのこれらの協調的なブロードキャストは、パーティション内のノード間の接続情報／被疑リストの交換を含む。上記のケースＡでは、各ノードは１回の協調的なブロードキャストを実行する。上記のケースＢ及びＣでは、各ノードは２回の協調的なブロードキャストを実行する。ケースＡ、Ｂ、及びＣにおいて全てのノードがグループメンバーシップ変更について合意するには、２ラウンドの協調的なブロードキャストで十分である。
【0045】
この処理を直感的に理解できるようにするために、まず、最適化されていない接続情報交換処理を以下に示し、これは（ｎ－１）ラウンドのブロードキャストを含み、ここでｎはフェーズ１中のコーラス内のノード数である。その後、最適化されたバージョンの接続情報交換処理を以下に示し、この処理では、コーラス内のノード数に関係なく、各ノードが最大で２ラウンドのブロードキャストに参加する。
【0046】
明確さ及び単純さのために、接続情報交換処理の進行中に、新しいネットワーク障害イベントも、加入する新しいノードも、コーラスメンバーノードの障害もないと仮定する。しかしながら、本明細書に記載の接続情報交換処理は、これら全てのイベントにも拡張することができる。これらの仮定及び／または制限は、コア処理の説明後、後のセクションで解除する。
【0047】
最適化されていない被疑ノードリストの配布
まず、コーラスはｎ個の全接続されたノードを含む。ネットワーク障害イベントが発生したとする。各ノードは、ネットワーク障害イベントを解決するために以下のプロトコルを実行する。
まず、コーラスはｎ個の全接続されたノードを含む。ネットワーク障害イベントが発生したとする。各ノードは、ネットワーク障害イベントを解決するために以下のプロトコルを実行する。
【0048】
各ノードは自身の被疑リストを用意する（この被疑リストは空のリストであり得、これが起こり得るのは、ネットワーク障害イベント後にノードが他の全てのノードに全接続されている（または少なくともそう考えている）場合である）。
【0049】
フェーズ１：各ノードは、他のノードの被疑リスト／接続に関する情報を収集するために、（ｎ－１）ラウンドの協調的なブロードキャストを実行する。ラウンド１では、各ノードは自身の被疑リストを自身の隣接ノードに送信し、自身の隣接ノードの被疑リストを受信するまで待機する。ラウンド２からラウンド（ｎ－１）までにおいて、各ノードは、前回のラウンドで受信した他のノードの被疑リストを自身の隣接機に送信し、自身の隣接機からそのような情報を受信するまで待機する。
【0050】
フェーズ２：各ノードはこのとき、自身のパーティション内の他の全てのノードの接続情報を受信している（コーラスはｎ個のノードを含むので、ノードが上記の方法で（ｎ－１）ラウンドのブロードキャストを実行することにより、各ノードが自身のパーティション内の他の全てのノードの接続情報を得るようになる）。各ノードは、自身のパーティションの接続グラフを用意し、接続グラフの最大サイズ（または最大クリーク）の全接続コンポーネントを見つける。そのような全接続コンポーネントが２つ以上ある場合、ノードは、（たとえば、完全コンポーネント内のノードの一意の識別子の辞書式順序に基づいて）タイブレーク処理によって決定された１つの全接続コンポーネントを勝利全接続コンポーネントとして選択する。勝利全接続コンポーネントのサイズが少なくとも（ｎ／２＋１）であり、ノードが勝利全接続コンポーネントのメンバーである場合、ノードは稼働を継続すると決断し（そしてプロトコルを終了し）、そうでなければ、ノードは自身を機能停止させる。
【0051】
以下は、最大で２ラウンドのブロードキャストの後にノードがメンバーシップ変更について合意するようにする最適化である。
【0052】
最適化１：これは、（上記のセクションの）ケースＡでカバーされるシナリオの場合に適用可能な最適化である。これは、ネットワーク障害イベントによってデータベースが全接続されたノードの非連結グループに分割された場合に、グループ／パーティション内の全てのノードの被疑リストが同じになるという観察結果に基づいている。たとえば、図２について考察する。図２では、ノードＴＥ１、ＴＥ２、及びＳＭ１はＴＥ３及びＳＭ２を疑い、ノードＴＥ３及びＳＭ２はＴＥ１、ＴＥ２、及びＳＭ１を疑う。フェーズ１中の第１ラウンドの協調的なブロードキャストの後、ノードの被疑リストが自身の全ての隣接機の被疑リストと一致する場合、ノードは、（ａ）自身が全接続コンポーネントの一部であり、（ｂ）全接続コンポーネントのサイズ（これはコーラスのサイズから自身の被疑リストのサイズを引いたものに等しい）を特定できると推測することができる。したがって、全てのノードは、フェーズ１中の第１ラウンドのブロードキャスト後に、メンバーシップ変更について合意することができる。
【0053】
最適化２：これは、主に上記のケースＢ及びＣに適用可能であり、部分的にケースＡに適用可能である最適化である。最適化されていない処理では、全てのノードが（ｎ－１）ラウンドの協調的なブロードキャストに参加する。これにより、各ノードは、自身のパーティション内の他の全てのノードの接続情報を認識する。しかしながら、最適な障害解決の判断に至るために、各ノードは自身のパーティション内の他の全てのノードの接続情報を知る必要が本当にあるだろうか。ネットワーク障害イベント後にノードをそれらの被疑リストに基づいて２つのカテゴリに分割することについて考察する。カテゴリ（Ｍ）は、ｎ／２個未満の他のノードを疑っているノードを含み、カテゴリ（Ｎ）は、ｎ／２個より多くのノードを疑っているノードを含む。ｎ／２個より多くを疑っているノードは、被疑リストをブロードキャストするのではなく、即刻自身らを機能停止させ得、その理由は、それらが勝利全接続コンポーネントの一部になり得ないためである。
【0054】
たとえば、図１１について考察する。ネットワーク障害イベントの後、ノードＴＥ２、ＳＭ１、及びＳＭ２はカテゴリ（Ｍ）に入り、ノードＴＥ１及びＴＥ３はカテゴリ（Ｎ）に入る。カテゴリ（Ｍ）について考察する。カテゴリ（Ｍ）のノードは、最適な障害解決の判断を行うために、カテゴリ（Ｍ）の他のノードの接続情報について知る必要があるだろうか。必要はある。この理由は、カテゴリ（Ｍ）のノードが、カテゴリ（Ｍ）の他のノードと共に少なくとも（ｎ／２＋１）のサイズの全接続コンポーネントを形成できるためであり、カテゴリ（Ｍ）の他のノードの接続情報について知ることは、（ａ）自身が少なくとも（ｎ／２＋１）のサイズの全接続コンポーネントの一部であるかどうかを判別し、（ｂ）少なくとも（ｎ／２＋１）のサイズの全ての全接続コンポーネントを識別し、（ｃ）自身が勝利全接続コンポーネントの一部であるかどうかを判別するのに役立つ。カテゴリ（Ｍ）のノードは、最適な障害解決の判断を行うために、カテゴリ（Ｎ）のノードの接続情報について知る必要があるだろうか。必要はない。これは、カテゴリ（Ｍ）のノードが、カテゴリ（Ｎ）のノードと共に少なくとも（ｎ／２＋１）のサイズの全接続コンポーネントを形成することはないためであり、その理由は、カテゴリ（Ｎ）のノードが（ｎ／２）個より多くの他のノードを疑っているためである。
【0055】
ここでカテゴリ（Ｎ）について考察する。カテゴリ（Ｎ）のノードは、最適な障害解決の判断を行うために、カテゴリ（Ｍ）及びカテゴリ（Ｎ）のノードの接続情報について知る必要があるだろうか。必要はない。この理由は、カテゴリ（Ｎ）のノードが（ｎ／２）個より多くの他のノードを疑っているために、他の任意のノード（複数可）と共に少なくとも（ｎ／２＋１）のサイズの全接続コンポーネントを形成することはないためである。他の全てのノードの接続情報を用意することは、カテゴリ（Ｎ）のノードが、稼働を継続する他のノードを知るのに役立つが、そのノードが他のノードと共に少なくとも（ｎ／２＋１）のサイズの全接続コンポーネントを形成できないという事実は変わらない。
【0056】
したがって、分散データベースシステム内の全てのノードが最適な障害解決の結果について合意するには、カテゴリ（Ｍ）内の各ノードにカテゴリ（Ｍ）内の他の各ノードの接続情報を認識させるのに十分なラウンドの協調的なブロードキャストで事足りるであろう。したがって、最適化されていない処理への修正として、最適化された処理は、フェーズ１の開始前にカテゴリ（Ｎ）のノードを機能停止させるが、同時にそれらをコーラスのメンバーとして保持することから始まる。換言すれば、カテゴリ（Ｍ）のノードは、フェーズ１が開始する前にカテゴリ（Ｎ）のノードが自身らを機能停止させるが、フェーズ２までカテゴリ（Ｎ）のノードを自身らのノードリスト上に保持する。機能停止されたノード（フェーズ１の開始前に機能停止させることができるカテゴリ（Ｎ）のノード）をフェーズ２までコーラスのメンバーとして保持することによって、正確性が確保され、すなわち、障害解決の結果は、少なくとも（ｎ／２＋１）個のノードを有する全接続されたセットであり、ここでｎはフェーズ１の前に最適化として機能停止されたノードを含む。（カテゴリ（Ｎ）のノード（または任意のタイプのノード）を含めないと、ｎの値（グループサイズ）及び多数派のサイズが変化し得、結果の正確性を証明することがより困難になり得る。）
【0057】
カテゴリ（Ｎ）のノードを機能停止させても、カテゴリ（Ｍ）のノード間の接続には影響せず（すなわち、カテゴリ（Ｎ）のノードの機能停止が原因で、カテゴリ（Ｍ）のノードは切断されない）、その理由は、カテゴリ（Ｍ）の任意の２つのノードが、相互に直接接続されているか、またはカテゴリ（Ｍ）の他のノードを介して接続されているためである。したがって、カテゴリ（Ｎ）ノードを機能停止させても、障害解決の結果の最適性に影響を与えるはずがない。
【0058】
概念的には、最適化によって、基本的にはカテゴリ（Ｍ）のノードが障害解決の結果について合意に達し、カテゴリ（Ｎ）のノードがその結果に従うようになる。この最適化により、フェーズ１を開始した各ノードは、少なくとも（ｎ／２）個の他のノードに接続されているので、接続グラフの直径（すなわち、接続グラフ内の任意の２つのノード間の最大距離）は最大で２である。したがって、フェーズ１を開始した各ノードがフェーズ１を開始した他の各ノードの接続について知るには、２ラウンドのブロードキャストしか必要ない。フェーズ１の各ノードは少なくともｎ／２個の他のノードに接続されているので、接続グラフの直径は最大で２であり、したがって、任意の２つのノードは最大で１つのノードだけ離れている。
【0059】
最適化された被疑ノードリストの配布
ｎ個の全接続されたノードを含むコーラスについて考察する。ネットワーク障害が発生したとする。各ノードは、ネットワーク障害を解決するために以下のプロトコルを実行する。各ノードは自身の被疑リストを用意する（注：この被疑リストは空のリストであり得、これが起こり得るのは、ネットワーク障害イベント後にノードが他の全てのノードに全接続されている（またはそう考えている）場合である）。
ｎ個の全接続されたノードを含むコーラスについて考察する。ネットワーク障害が発生したとする。各ノードは、ネットワーク障害を解決するために以下のプロトコルを実行する。各ノードは自身の被疑リストを用意する（注：この被疑リストは空のリストであり得、これが起こり得るのは、ネットワーク障害イベント後にノードが他の全てのノードに全接続されている（またはそう考えている）場合である）。
【0060】
フェーズ０：各ノードは、自身が（ｎ－１／２）個より多くの他のノードを疑っているかどうかをチェックする。疑っている場合、ノードは自身を機能停止させる。（他のノードは、フェーズ１中に、この機能停止について聞き得る。聞いた場合、それらのノードはプロトコルを再開始し、フェーズ０からやり直す。）
【0061】
フェーズ１のラウンド１：各ノードは、自身の被疑リストを自身の隣接ノードに送信し、自身の隣接ノードの被疑リストを受信するまで待機する。上記のように、ノードの隣接機のうちの１つまたは複数がフェーズ０で機能停止した場合、そのノードは自身の隣接機の被疑リストを待っている間にそれらの機能停止について聞き得る。そのような機能停止（複数可）について聞くと、ノードはプロトコルを再開始し、フェーズ０からやり直す。これにより、他のノードもプロトコルを再開始する。同様に、隣接ノードがプロトコルを再開始する場合、ノードはフェーズ０からやり直す。また、上記のように、このノードは、このステージでどの機能停止されたノードのフェイルオーバーも開始しない（すなわち、勝利全接続コンポーネントを決定する目的で、全てのノードを自身のコーラスに保持する）。これは、フェーズ０の複数のラウンドにも当てはまる。
【0062】
各ノードは、自身の被疑リストが自身の全ての隣接ノードの被疑リストと同じであるかどうかをチェックする。ノードの被疑リストが自身の全ての隣接ノードの被疑リストと一致する場合、これはノードが自身の隣接ノードと全接続されていることを示している。このシナリオは、上記のケースＡ（たとえば、図２）でカバーされる。フェーズ１を開始した各ノードは、少なくとも（ｎ／２）個の他のノードに接続されているので、ノードの隣接機のリストのサイズは少なくとも（ｎ／２）であり得る（ノードはその隣接ノードと共に、少なくとも（ｎ／２＋１）個のノードを含むグループを形成する）。ノードは稼働を継続すると決断し、プロトコルを終了する。
【0063】
ノードの被疑リストが、自身の隣接機のうちの少なくとも１つの被疑リストと一致しない場合、これは、ノードが自身のパーティション内の他の全てのノードと全接続されていないことを示している。このシナリオは、上記のケースＢ及びＣ（たとえば、図３～図９）でカバーされている。そのようなノードは、ラウンド１で受信した情報に基づいて、稼働を継続すべきか否かを判断することができない。したがって、フェーズ１のラウンド２を実施する。
【0064】
フェーズ１のラウンド２：各ノードは、ラウンド１で受信した他のノードの被疑リストを自身の隣接機に送信し、自身の隣接機から自身の隣接機の隣接機のそのような被疑リストを受信するまで待機する。
【0065】
フェーズ２：各ノードはこのとき、自身のパーティション内の他の全てのノードの接続情報を受信している。各ノードは、自身のパーティションの接続グラフを用意し、接続グラフの少なくとも（ｎ／２＋１）個のノードを有する最大の全接続コンポーネント（または少なくとも（ｎ／２＋１）のサイズの最大クリーク）を見つける。２つ以上の全接続コンポーネントが存在する場合（たとえば、図７）、ノードは、障害解決を決定論的にするために、タイブレーク処理（たとえば、辞書式順序）によって決定される１つの全接続コンポーネントを勝利全接続コンポーネントとして選択する。ノードが勝利全接続コンポーネントのメンバーである場合、ノードは稼働を継続すると決断し（そしてプロトコルを終了し）、そうでなければ、ノードは自身を機能停止させる。
【0066】
分散データベースシステムがネットワークイベントを解決している最中に、新しいネットワーク障害イベントが発生した場合、プロトコルはノードに逆戻りさせ、新しいネットワークイベントの影響を考慮して、ノードの接続を再検査させたのち、障害解決の判断を行わせる。
【0067】
新しいネットワーク障害イベントに加えて、分散データベースシステム内のノードがネットワーク障害を解決している間に、ノードの機能停止（たとえば、ノードの手動シャットダウンが原因で発生するもの）も発生し得る。ノードの機能停止に応答して、プロトコルはノードにフェーズ０から再開始させつつ、機能停止されたノードをコーラスのメンバーとしてフェーズ２まで保持する（機能停止されたノードに対してフェイルオーバーを実行しないことにより、残りのノードが機能停止されたノードをそれらのノードリストから削除するのを阻止する）。上記で説明したように、機能停止されたノードをコーラスのメンバーとしてフェーズ２まで保持することによって、正確性が確保され、すなわち、障害解決の結果は、少なくとも（ｎ／２＋１）個のノードを有する全接続されたセットであり、ここでｎは機能停止したノードを含み、したがって、フェーズ２の後で稼働を継続するそのようなセットは１つのみとすることができる。
【0068】
図１２は、ネットワーク障害を解決するための最適化された処理１２００を示すフローチャートである。各ノードは同じ処理に従うので、フローチャートは単一ノードの視点から処理１２００を示している。処理１２００は、ステージの観点から詳細に説明する。
【0069】
ステージ０：初期ステージ。１２０２において、ノードはコーラス内の他の全てのノードに全接続される。ローカルまたはリモートで被疑ノードを検出すると、ノードはステージ１に移動する。
【0070】
ステージ１：１２１０において、ノードは１ｐｉｎｇ（ハートビート）サイクルの間、さらなるｐｉｎｇ（ハートビート）タイムアウトが発生するのを待機し、自身の被疑リストを用意し、受信した被疑リストメッセージを取り込んだのち、ステージ２に入る。
【0071】
ステージ２：１２２０において、ノードは自身が（ｎ－１／２）個より多くの他のノードを疑っているかどうかをチェックする（ここでｎはコーラス内のノード数である）。疑っている場合、１２９９において、ノードは自身を機能停止させる。そうでない場合、ノードは、ステージ１で自身の被疑リストを用意してから、新しい被疑機（ｓｕｓｐｅｃｔ）がいるかどうかをチェックする。また、ノードは、自身の隣接機のいずれかが新しい被疑機を検出したために、プロトコルを再開始したかどうかをチェックする。各ノードは、実行する処理１２００の反復ごとに、ｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒと呼ぶ番号を割り当て得る。各ノードは、送信する被疑リストメッセージにこの番号を設定し、自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを他のノードから受信した被疑リスト内のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒと比較する。ノードは、自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒが隣接機のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒよりも小さいと判定した場合、自身の隣接機が処理を再開始したと判定し、ステージ１に戻る。そうでなければ、ノードはステージ３に入る。（ノードのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒが隣接機のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒよりも大きい場合、そのノードはプロトコルを再開始しており（おそらく新しい被疑機を見つけたため）、これにより隣接機もプロトコルを再開始するはずである。）
【0072】
ステージ３：１２３０において、ノードは自身のラウンド１被疑リストを自身の隣接ノードにブロードキャストする。ノードは、１２３２において、ラウンド１被疑リストメッセージを待機している間に、新しい被疑機を検出し得、あるいは自身の隣接機のうちの１つまたは複数が新しい被疑機を検出したことを聞き得る。その場合、ノードはそれ以上の応答の待機を中止し、ステージ１に戻る。１２３４において、ノードは自身の全ての隣接ノードからラウンド１被疑リストメッセージを受信する。ノードが自身の隣接機のいずれからも適時に（たとえば、所定の期間内に）応答を受信しなかった場合、１２３６において、ノードはそのような隣接機を被疑機としてマークし、ステージ１に戻る。ノードが自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒよりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有するラウンド１被疑リストを受信した場合、１２３８において、ノードはステージ１の最初に戻る。自身の全ての隣接機からラウンド１応答を受信すると、ノードはステージ４に入る。
【0073】
ステージ４：１２４０において、ノードの被疑リストが自身の全ての隣接機の被疑リストと一致する場合、ノードは、自身が自身の隣接ノードと全接続されていると判定する（たとえば、図２の通り）。ステージ３を開始した各ノードは、少なくとも（ｎ／２）個の他のノードに接続されているので、ノードの隣接機のリストのサイズは少なくとも（ｎ／２）であり得る（すなわち、ノード及びその隣接機は、少なくとも（ｎ／２＋１）個のノードを含む全接続コンポーネントまたはグループを形成する）。１２０１において、ノードは、稼働を継続すると決断し、被疑ノードを排除し、処理１２００を終了する。
【0074】
ノードの被疑リストが自身の隣接機のうちの少なくとも１つの被疑リストと一致しない場合、ノードは自身のパーティション内の他の全てのノードと全接続されていない（たとえば、図３～図９の通り）。ノードは、ラウンド１で受信した情報に基づいて、稼働を継続すべきか、機能停止すべきかを判断できないので、ノードはステージ５に入り、ステージ５は１２５０においてラウンド２被疑リストメッセージをブロードキャストすることを含む。
【0075】
ステージ５：１２５０において、ノードは、自身の元の被疑機と自身の隣接ノードの被疑機とを加えたものを含む自身のラウンド２被疑リストを自身の隣接ノードにブロードキャストし、自身の全ての隣接ノードからラウンド２被疑リストメッセージを受信するまで待機する。ノードは、１２３０において自身のラウンド１被疑リストメッセージをブロードキャストした後、いつでもその他のノードからラウンド２被疑リストメッセージを受信し得る。ノードは、これらのラウンド２被疑リストメッセージを蓄積する。１２５２において、新しいネットワーク障害が発生した場合、もしくはノードが他のノードからラウンド１メッセージを受信した場合、またはノードが他のノードの機能停止について聞いた場合、ノードはステージ１に戻る。ステージ１に戻ると、ノードは蓄積したラウンド２被疑リストメッセージを全て破棄する。しかしながら、他のノードが戻り、他のメッセージを送信した場合、そのメッセージは保持される。ノードは、ラウンド１及びラウンド２の被疑リストメッセージ内のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒに基づいて、これら２つのタイプのメッセージを区別する。換言すれば、ｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒに基づくメッセージは、ｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒ及びラウンド番号を含む。
【0076】
１２５４において、ノードは、自身の全ての隣接ノードからラウンド２被疑リストメッセージを受信すると、ステージ６に入る。ノードが自身のラウンド２被疑リストメッセージをブロードキャストした後に、新しいネットワークイベントが発生した場合、またはノードが他のノードの機能停止について聞いた場合、障害解決の判断は最適なものではなくなり得る。可能性のあるケースは少なくとも２つあり、ケース（ａ）では、ノードは新しい被疑ノードまたは機能停止したノードからラウンド２メッセージを既に受信しており、ケース（ｂ）では、ノードは新しい被疑機または機能停止したノードからラウンド２メッセージを受信していない。
【0077】
ケース（ａ）では、ノードはステージ６に進み得、現在のネットワークイベントの障害解決を実行したのち、プロトコルを再開始することにより新しいネットワークイベントに対処するか、または（現在のネットワークイベントを解決せずに）ステージ１に戻って、処理１２００を再開始する（これにより、その後、現在のネットワーク障害及び新しいネットワーク障害の両方が解決される）。ケース（ｂ）では、ノードは新しい被疑機からも機能停止したノードからもラウンド２メッセージを受信しないので、ノードはステージ１に戻る。しかしながら、その他のノードもステージ６を完了する前にステージ１に戻る保証はない（その理由は、それらが新しい被疑機または機能停止したノードからラウンド２メッセージを受信している場合があるためである）。このケースでは、障害解決の結果は準最適であり得る（すなわち、生存セットは、なれたはずのものよりも小さくなるが、生存セットは依然として１つのみである）。しかしながら、このノードがステージ１に移動しても、このノードは既に自身のラウンド２メッセージを送信しているので、他のノードの進行は阻止されない。
【0078】
ステージ６：１２６０において、ノードは自身のパーティションの接続グラフを用意し、接続グラフの少なくとも（ｎ／２＋１）のサイズの最大の全接続コンポーネント（または少なくとも（ｎ／２＋１）のサイズの最大クリーク）を見つける。そのようなコンポーネントが２つ以上ある場合、ノードは、タイブレーク処理によって決定されたそれらの中の１つを勝利全接続コンポーネントとして選択する。ノードが勝利全接続コンポーネントのメンバーである場合、１２０１において、ノードは稼働を継続すると決断し、勝利全接続コンポーネントの一部ではないノードを排除する。そうでない場合、１２９９において、ノードは自身を機能停止させる。
【0079】
プロトコル反復番号
上記で論じたように、分散データベースシステム内の任意のノードは、１つまたは複数の被疑ノードを検出したことに応答して、障害解決プロトコル（たとえば、図１２の処理１２００）を開始することができる。また、障害解決プロトコルの実行中に発生したいずれかの新しいネットワーク障害イベントによって、プロトコルの再開始がトリガーされる。ノードが受信した被疑リストメッセージ（ラウンド１またはラウンド２）が、プロトコルの現在の呼び出しに属しているか、またはプロトコルの再開始による次の呼び出しに属しているか（さらには、プロトコルを再開始したノードの場合、プロトコルの前の呼び出しに属しているか）をノードが検出できるようにするために、ノードは、ｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒと呼ばれる番号を、障害解決プロトコルの各呼び出しに関連付ける。
上記で論じたように、分散データベースシステム内の任意のノードは、１つまたは複数の被疑ノードを検出したことに応答して、障害解決プロトコル（たとえば、図１２の処理１２００）を開始することができる。また、障害解決プロトコルの実行中に発生したいずれかの新しいネットワーク障害イベントによって、プロトコルの再開始がトリガーされる。ノードが受信した被疑リストメッセージ（ラウンド１またはラウンド２）が、プロトコルの現在の呼び出しに属しているか、またはプロトコルの再開始による次の呼び出しに属しているか（さらには、プロトコルを再開始したノードの場合、プロトコルの前の呼び出しに属しているか）をノードが検出できるようにするために、ノードは、ｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒと呼ばれる番号を、障害解決プロトコルの各呼び出しに関連付ける。
【0080】
各ノードは自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを維持し、送信する被疑リストメッセージにこの番号を設定し、各ノードは自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを、受信した被疑リストメッセージ内のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒと比較する。番号が一致する場合、ノードは、受信した被疑リストメッセージがプロトコルの現在の呼び出しに対応していると推測する。受信した被疑リストメッセージ内のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒが自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒより大きい場合、ノードは送信元がプロトコルの再開始を開始した（したがって、プロトコルを再開始する）と推測する。また、受信した被疑リストメッセージ内のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒが自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒよりも小さい場合、ノードは、送信元がまだプロトコルの前回の反復を実行しているために、メッセージを無視すると推測する。
【0081】
各ノードは、以下の方法で自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを維持することができる。
（ａ）ＰｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒは第１のノードにおいて、データベースの初期化中及びデータベースの再開始中にゼロに設定される。
（ｂ）ＰｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒはマスターカタログの一部としてシリアライズされ、分散データベースシステムに加入する新しいノードは、マスターカタログをフェッチするときに、マスターカタログチェアマンから現在のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信する。新しいノードは、分散データベースシステムに加入する場合に、マスターカタログを受信する。現在のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒをマスターカタログに記憶することにより、現在のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒが新しいノードで利用可能になる。
（ｃ）ノードがどのノードも疑っておらず、被疑ノードを検出しており、他のノードからいずれの被疑リストメッセージも受信しておらず、障害解決プロトコルを呼び出している場合、ノードは自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒをインクリメントする。
（ｄ）ノードがどのノードも疑っておらず、被疑ノードを検出しており、他のノードから１つまたは複数の被疑リストメッセージを受信しており、障害解決プロトコルを呼び出している場合、ノードは自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信した被疑リストメッセージ内の最大のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒに設定する。
（ｅ）ノードが被疑ノードを検出しておらず、他のノードから１つまたは複数の被疑リストメッセージを受信しており、障害解決プロトコルを呼び出している場合、ノードは自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを、他のノードから受信した被疑リストメッセージ内の最大のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒに設定する。
（ｆ）ノードが障害解決プロトコルを実行していて、自身のローカルの番号よりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信しておらず、新しいネットワーク障害イベントを検出した場合、ノードは自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒをインクリメントする（そしてプロトコルを再開始する）。
（ｇ）ノードが障害解決プロトコルを実行していて、自身のローカルの番号よりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信しており、新しいネットワーク障害イベントを検出した場合、ノードは自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信した被疑リストメッセージ内の番号に設定する（そしてプロトコルを再開始する）。
（ｈ）ノードが障害解決プロトコルを実行していて、自身のローカルの番号よりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信しており、新しいネットワーク障害イベントを検出しなかった場合、ノードは自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信した被疑リストメッセージ内の番号に設定する（そしてプロトコルを再開始する）。
（ｉ）ノードが障害解決プロトコルを実行していて、自身のローカルの番号よりも小さいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信した場合、ノードはそのメッセージを無視する。
（ａ）ＰｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒは第１のノードにおいて、データベースの初期化中及びデータベースの再開始中にゼロに設定される。
（ｂ）ＰｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒはマスターカタログの一部としてシリアライズされ、分散データベースシステムに加入する新しいノードは、マスターカタログをフェッチするときに、マスターカタログチェアマンから現在のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信する。新しいノードは、分散データベースシステムに加入する場合に、マスターカタログを受信する。現在のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒをマスターカタログに記憶することにより、現在のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒが新しいノードで利用可能になる。
（ｃ）ノードがどのノードも疑っておらず、被疑ノードを検出しており、他のノードからいずれの被疑リストメッセージも受信しておらず、障害解決プロトコルを呼び出している場合、ノードは自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒをインクリメントする。
（ｄ）ノードがどのノードも疑っておらず、被疑ノードを検出しており、他のノードから１つまたは複数の被疑リストメッセージを受信しており、障害解決プロトコルを呼び出している場合、ノードは自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信した被疑リストメッセージ内の最大のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒに設定する。
（ｅ）ノードが被疑ノードを検出しておらず、他のノードから１つまたは複数の被疑リストメッセージを受信しており、障害解決プロトコルを呼び出している場合、ノードは自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを、他のノードから受信した被疑リストメッセージ内の最大のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒに設定する。
（ｆ）ノードが障害解決プロトコルを実行していて、自身のローカルの番号よりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信しておらず、新しいネットワーク障害イベントを検出した場合、ノードは自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒをインクリメントする（そしてプロトコルを再開始する）。
（ｇ）ノードが障害解決プロトコルを実行していて、自身のローカルの番号よりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信しており、新しいネットワーク障害イベントを検出した場合、ノードは自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信した被疑リストメッセージ内の番号に設定する（そしてプロトコルを再開始する）。
（ｈ）ノードが障害解決プロトコルを実行していて、自身のローカルの番号よりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信しており、新しいネットワーク障害イベントを検出しなかった場合、ノードは自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信した被疑リストメッセージ内の番号に設定する（そしてプロトコルを再開始する）。
（ｉ）ノードが障害解決プロトコルを実行していて、自身のローカルの番号よりも小さいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信した場合、ノードはそのメッセージを無視する。
【0082】
これらのポイントは以下のようにまとめることができる。
（Ａ）ＰｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒは第１のノードにおいて、データベースの初期化中及びデータベースの再開始中にゼロに設定される。
（Ｂ）ＰｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒはマスターカタログの一部としてシリアライズされ、データベースに加入する新しいノードは、マスターカタログをフェッチするときに、マスターカタログチェアマンから現在のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信する。
（Ｃ）ノードが障害解決プロトコルを呼び出している場合（被疑ノードを検出したため、及び／または他のノードから被疑リストメッセージを受信したため）、ノードは、自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒよりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信したかどうかをチェックする。受信した場合、ノードは自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを、受信した被疑リストメッセージ（複数可）内の最大のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒに設定し、そうでない場合、自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒをインクリメントする。
（Ａ）ＰｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒは第１のノードにおいて、データベースの初期化中及びデータベースの再開始中にゼロに設定される。
（Ｂ）ＰｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒはマスターカタログの一部としてシリアライズされ、データベースに加入する新しいノードは、マスターカタログをフェッチするときに、マスターカタログチェアマンから現在のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを受信する。
（Ｃ）ノードが障害解決プロトコルを呼び出している場合（被疑ノードを検出したため、及び／または他のノードから被疑リストメッセージを受信したため）、ノードは、自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒよりも大きいｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを有する被疑リストメッセージを受信したかどうかをチェックする。受信した場合、ノードは自身のローカルのｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒを、受信した被疑リストメッセージ（複数可）内の最大のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒに設定し、そうでない場合、自身のｐｒｏｔｏｃｏｌＩｔｅｒａｔｉｏｎＮｕｍｂｅｒをインクリメントする。
【0083】
単方向リンク障害への対処
上記のケースＤ（図１０）のような単方向リンク障害は、それらに双方向リンク障害として対処することによって（すなわち、障害のあるリンクの両側のノードに互いを疑わせることによって）解決することができる。たとえば、分散データベースシステム内のノードＡ及びノードＢの２つのノードについて考察する。ノードＡはノードＢにメッセージを送信できるが、ノードＢはノードＡにメッセージを送信できないと仮定する。ＡはノードＢにｐｉｎｇメッセージを送信できるが、ノードＢから確認応答メッセージを受信しないので、ノードＡはノードＢを疑うようになる。この時点で、ノードＢはまだノードＡを疑っていない。しかしながら、ノードＡはノードＢを疑うようになるので、ノードＢへのｐｉｎｇメッセージの送信をやめる。これによりノードＢはノードＡを疑うようになるので、単方向リンク障害が双方向リンク障害に変換される。
上記のケースＤ（図１０）のような単方向リンク障害は、それらに双方向リンク障害として対処することによって（すなわち、障害のあるリンクの両側のノードに互いを疑わせることによって）解決することができる。たとえば、分散データベースシステム内のノードＡ及びノードＢの２つのノードについて考察する。ノードＡはノードＢにメッセージを送信できるが、ノードＢはノードＡにメッセージを送信できないと仮定する。ＡはノードＢにｐｉｎｇメッセージを送信できるが、ノードＢから確認応答メッセージを受信しないので、ノードＡはノードＢを疑うようになる。この時点で、ノードＢはまだノードＡを疑っていない。しかしながら、ノードＡはノードＢを疑うようになるので、ノードＢへのｐｉｎｇメッセージの送信をやめる。これによりノードＢはノードＡを疑うようになるので、単方向リンク障害が双方向リンク障害に変換される。
【0084】
本明細書に記載の処理では、ノードはＭｓｇＰｉｎｇメッセージ（たとえば、ｐｉｎｇメッセージ）を送信し、特定のノードに対して、そのノードが前のＭｓｇＰｉｎｇメッセージに確認応答した場合にのみ、Ｎｏｄｅ：：ｌａｓｔＰｉｎｇＴｉｍｅを設定する。これにより、単方向リンク障害によって、リンクの両側のノードが互いを疑うことを確実にする。したがって、上記のプロトコルは、単方向リンク障害、または単方向及び双方向リンク障害の混合を解決することができる。
【0085】
コーラスメンバーシップ変更
新しいノード（または新しいノードのセット）がコーラスに加入している最中にネットワーク障害イベントが発生した場合、この処理は、コーラスが複数の多数派グループに分割されないようにする必要がある。図１０では、たとえば、ネットワーク分断によって、コーラスが多数派グループ｛ＳＭ１，ＳＭ２｝と、少数派グループ｛ＴＥ１｝とに分割される。しかしながら、少数派グループ｛ＴＥ１｝は、新しいノード｛ＴＥ２，ＴＥ３｝と共に、多数派グループ｛ＴＥ１，ＴＥ２，ＴＥ３｝を形成し、その結果、２つの「多数派」グループ｛ＴＥ１，ＴＥ２，ＴＥ３｝及び｛ＳＭ１，ＳＭ２｝となる。
新しいノード（または新しいノードのセット）がコーラスに加入している最中にネットワーク障害イベントが発生した場合、この処理は、コーラスが複数の多数派グループに分割されないようにする必要がある。図１０では、たとえば、ネットワーク分断によって、コーラスが多数派グループ｛ＳＭ１，ＳＭ２｝と、少数派グループ｛ＴＥ１｝とに分割される。しかしながら、少数派グループ｛ＴＥ１｝は、新しいノード｛ＴＥ２，ＴＥ３｝と共に、多数派グループ｛ＴＥ１，ＴＥ２，ＴＥ３｝を形成し、その結果、２つの「多数派」グループ｛ＴＥ１，ＴＥ２，ＴＥ３｝及び｛ＳＭ１，ＳＭ２｝となる。
【0086】
新しいノードをコーラスに加入させることに関連する問題を解決する１つの方法は、新しいノード（複数可）がコーラスに加入している最中にネットワーク障害イベントが発生した場合、新しいノード（複数可）を機能停止させることである。これにより、現在のコーラス内の少数派のノードセットが、新しいノード（複数可）と共に多数派グループを形成することが防がれる。図１０では、新しいノードＴＥ２及びＴＥ３（これらはまだコーラスに加入している最中である）を機能停止させることができ、これによりＴＥ１も機能停止して、データベースに単一の多数派グループ｛ＳＭ１，ＳＭ２｝が残る。この処理では、コーラスに同時に加入できるノード数に制限はない。しかしながら、新しいノード（複数可）が機能停止され、現在のコーラス内の一部のノードが新しいノード（複数可）を認識している場合があるので、この処理は（現在のコーラスの奇数または偶数のノード数、コーラスに加入しようとしているノード数、ネットワーク障害時に新しいノード（複数可）を認識しているコーラス内のノード数などに応じて）システムの可用性に影響を与え得る。
【0087】
この処理は、現在のコーラスメンバーに、新しいノードがコーラスに加入することについて合意させるために、分散データベースにおいてデータのフラグメントを要求するための処理（オリジネータが利用可能なフラグメントを送信し、ピアがオリジネータに確認応答を送信し、オリジネータが完全なデータを要求元に送信する）に便乗することもできる。この処理は、ノード加入処理中にノードがコーラスサイズについて一致するために図１２の障害解決処理１２００に対する以下の変更を含む。
【0088】
ノードは、ラウンド１及びラウンド２のブロードキャスト中に、自身らの完全な接続情報（すなわち、自身らの隣接ノードリストならびに自身らの被疑ノードリスト）を交換する。ノードは、ラウンド１／ラウンド２のメッセージを受信したことに応答して、自身らの被疑ノードリスト及び隣接ノードリストを、自身らの隣接機の被疑ノードリスト及び隣接ノードリストと比較する。ノードは、自身が認識していないｎj個のノードについて自身の隣接機が認識していることに気づいた場合、自身のコーラスサイズをｎjだけインクリメントし、処理を再開始する。
【0089】
この処理により、正確性を確保することができ、ネットワーク分断が原因で、新しいノード（複数可）がコーラス内の全てのノードのノードリストに入ることができない場合、その新しいノード（複数可）は障害解決中に自身を機能停止させる。ｎをコーラス内のノード数とし、ｎjを、同時にコーラスに加入しようとしているが、ネットワーク分断が原因でｎ個全てのノードのノードリストに入ることができないノード数とした場合、ｎj個のノード（新しいノード）は、自身らのパーティションに関係なく、処理の実行中に自身らを機能停止させる。したがって、最大でｎ個のノードが、稼働を継続すべきか否かを判断するために、ラウンド１の後で、自身らが多数派パーティション内にいるかどうかをチェックする。各パーティション内のノードがコーラスサイズｓ（ｎ≦ｓ≦ｎ＋ｎj）で動作し、ラウンド１の後、コーラス内に最大でｎ個のノードが存在するので、最大で１つのパーティションが多数派グループを形成することができ、これにより正確性が確保される。
【0090】
しかしながら、パーティション内の全てのノードが、障害解決プロトコルを開始した後に、自身らのノードリストに新しいノード（複数可）を追加したらどうなるだろうか。（なお、ノードは、プロトコルの開始時に、ステージ１中に、自身らの被疑ノードリスト及び隣接ノードリストを用意し、その情報をキャッシュすることに留意されたい）。いずれのノードも、自身らのノードリストに新しいノード（複数可）が追加されたことを検出できない。結果として、新しいノード（複数可）のマスターカタログは完全な状態に遷移し得、新しいノード（複数可）が障害解決処理に参加することになり、その結果、複数の多数派グループがもたらされ得る。
【0091】
たとえば、このシナリオについて考察する。コーラスはノードＡ、Ｂ、及びＣを含み、Ａは分散データベースのフラグメント（たとえば、フラグメント「マスターカタログ」）のチェアマン／リーダーである。新しいノードＤ及びＥが、同時にコーラスに加入しようとする。ノードＡは、Ｄ及びＥの利用可能メッセージをＢ及びＣに送信する。Ｂ及びＣは、Ａからｐｉｎｇメッセージを受信せず、Ａを疑い、プロトコルを開始する。Ｂ及びＣは（まだ）Ａからの利用可能メッセージを適用していないので、コーラスメンバー｛Ａ，Ｂ，Ｃ｝でプロトコルを開始する。その後、Ｂ及びＣは利用可能メッセージを適用し、確認応答メッセージをＡに送信し、その後、ネットワーク分割が発生する。Ｄ及びＥのマスターカタログは完全なものとなるので、Ａ、Ｄ、Ｅはコーラスメンバー｛Ａ，Ｂ，Ｃ，Ｄ，Ｅ｝でプロトコルを開始する。両方のグループ｛Ａ，Ｄ，Ｅ｝及び｛Ｂ，Ｃ｝は、自身らが多数派グループを形成できると考える。
【0092】
次の拡張により、そのような状況を防ぐことができる。利用可能メッセージを適用した後（または、チェアマンノードの場合は、マスターカタログを新しいノードに送信した後）、ノードは障害解決プロトコルを再開始し（１つが進行中の場合）、これにより、そのノードは自身がキャッシュした被疑リスト及び隣接リストを無効化し、より大きなコーラスサイズでそれらを再計算することになる。
【0093】
【0094】
シナリオ（Ａ）：ネットワーク分断が発生して、新しいノード及びエントリノード（マスターカタログのオリジネータ）が残りのノードから分離される。
【0095】
図１３では、ＳＭ３はＴＥ１（マスターカタログのチェアマン）にマスターカタログを要求してＴＥ１から受信し、ＴＥ１がＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅ（たとえば、送信元ノードが分散データベースシステムに加入することを受信側ノードに通知するメッセージ）をＳＭ１及びＳＭ２に送信する前にネットワーク分断が発生する。ＳＭ３を含む全てのノードが、解決プロトコルを開始する。ＳＭ３及びＴＥ１はノードＳＭ１及びＳＭ２を疑い、ＳＭ１及びＳＭ２はＴＥ１を疑う（ＳＭ１及びＳＭ２はＳＭ３については知らない）。ＳＭ３は、まだコーラスに加入している最中であるので（ＴＥ１から完了を受信していないので）機能停止し、ＴＥ１は、コーラス｛ＳＭ１，ＳＭ２，ＳＭ３，ＴＥ１｝内の２つのノードを疑っているので（フェーズ０で）機能停止し、ＳＭ１及びＳＭ２は、コーラス｛ＳＭ１，ＳＭ２，ＴＥ１｝の多数派を形成するので稼働を継続する。
【0096】
シナリオ（Ｂ）：シナリオ（Ａ）の変形例。ネットワーク分断が発生して、新しいノード及びエントリノード（マスターカタログのオリジネータ）が残りのノードから分離される。
【0097】
図１４では、ＳＭ３はＴＥ１（マスターカタログのチェアマン）にマスターカタログを要求してＴＥ１から受信し、ＳＭ１はＴＥ１からＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信し、ＳＭ２がＴＥ１からＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信する前にネットワーク分断が発生する。ＳＭ３及びＴＥ１はＳＭ１及びＳＭ２を疑い、ＳＭ１はＳＭ３及びＴＥ１を疑い、ＳＭ２はＴＥ１を疑う（ＳＭ２はＳＭ３について知らない）。ＳＭ３はまだコーラスに加入している最中である（ＴＥ１から加入の最終確認を受信していない）ので機能停止し、ＴＥ１及びＳＭ１はコーラス｛ＳＭ１，ＳＭ２，ＳＭ３，ＴＥ１｝内の２つのノードを疑っているので（フェーズ０で）機能停止する。ＳＭ２は最初はＴＥ１のみを疑うので（ｎ＝３の場合、これはノード数のｎ／２未満である）、フェーズ０で機能停止せず、フェーズ１のラウンド１のメッセージをＳＭ１に送信するが、ＳＭ１の機能停止について聞いた後、解決プロトコルを再開始したのち、自身を機能停止させる。
【0098】
シナリオ（Ｄ）：ネットワーク分断が発生して、新しいノード、エントリノード、及び一部のピアが残りのピアから分離される。
【0099】
図１５では、ＳＭ３はＴＥ１（マスターカタログのチェアマン）にマスターカタログを要求してＴＥ１から受信し、ＳＭ１はＴＥ１からＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信し、ＳＭ２がＴＥ１からＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信する前に、ネットワーク分断によってＳＭ２が残りのノードから分離される。ＳＭ３は、まだコーラスに加入している最中である（ＴＥ１から完了を受信していない）ので機能停止する。ＳＭ２は、コーラス｛ＳＭ１，ＳＭ２，ＴＥ１｝の少数派パーティション内にいるので機能停止する。ＴＥ１及びＳＭ１はプロトコルを開始し、ＳＭ３から（ラウンド１）応答を受信せず、最終的にＳＭ３を疑ったのち、自身らを機能停止させる。
【0100】
シナリオ（Ｅ）：ネットワーク分断によって、エントリノード（マスターカタログのチェアマン）が残りのノードから分離される。
【0101】
図１６では、ＳＭ３はＴＥ１（マスターカタログのチェアマン）にマスターカタログを要求してＴＥ１から受信し、ＳＭ１及びＳＭ２はＴＥ１からＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信し、ネットワーク分断によって、エントリノードＴＥ１が残りのノードから分断される。ＳＭ３は、まだコーラスに加入している最中であるので、機能停止する。ＴＥ１は、コーラス｛ＳＭ１，ＳＭ２，ＳＭ３，ＴＥ１｝の少数派パーティション内にいるので、機能停止する。ＳＭ１及びＳＭ２は障害解決処理を開始し、ＳＭ３からの応答を受信せず、最終的にＳＭ３を疑ったのち、自身らを機能停止させる。
【0102】
シナリオ（Ｈ）：ネットワーク分断によって、新しいノード、エントリノード、及び一部のピアが残りのノードから分離される。
【0103】
図１７では、ＳＭ４はＴＥ１（マスターカタログのチェアマン）にマスターカタログを要求してＴＥ１から受信し、ＳＭ１及びＳＭ３はＴＥ１からＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信し、ネットワーク分断が発生してＳＭ２が残りのノードから分離される。ＳＭ４はまだコーラスに加入している最中であるので、機能停止する。ＳＭ２は、コーラス｛ＳＭ１，ＳＭ２，ＳＭ３，ＴＥ１｝の少数派パーティション内にいるので、機能停止する。ＴＥ１、ＳＭ１、及びＳＭ３は、コーラス｛ＳＭ１，ＳＭ２，ＳＭ３，ＳＭ４，ＴＥ１｝において多数派グループを形成するので、稼働を継続する。このケースでは、グループ｛ＴＥ１，ＳＭ１，ＳＭ３｝は、元のコーラス｛ＴＥ１，ＳＭ１，ＳＭ２，ＳＭ３｝において多数派であったが、新しいコーラス｛ＴＥ１，ＳＭ１，ＳＭ２，ＳＭ３，ＳＭ４｝においてもまだ多数派である。これにより、ＴＥ１、ＳＭ１、及びＳＭ３は、自身らのノードリストにＳＭ４が追加された後でも、稼働を継続することが可能になる。一般に、この動作は、（ネットワーク障害時に１つのノードがコーラスに加入しようとして）コーラスサイズが偶数のノード数から奇数のノード数に変化するときはいつでも発生する。
【0104】
シナリオ（Ｉ）：ネットワーク分断によって、新しいノード、エントリノード、及び一部のピアが残りのノードから分割される。
【0105】
図１８では、ＳＭ４及びＳＭ５はＴＥ１（マスターカタログのチェアマン）にマスターカタログを要求してＴＥ１から受信し、ＳＭ１及びＳＭ３はＴＥ１からＳＭ４及びＳＭ５の両方のＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信し、ネットワーク分断によってＳＭ２が残りのノードから分離される。ＳＭ４及びＳＭ５は、まだコーラスに加入している最中であるので機能停止し、ＳＭ２はコーラス｛ＳＭ１，ＳＭ２，ＳＭ３，ＴＥ１｝の少数派グループ内にいるので機能停止する。ＴＥ１、ＳＭ１、及びＳＭ３も、コーラス｛ＳＭ１，ＳＭ２，ＳＭ３，ＳＭ４，ＳＭ５，ＴＥ１｝において少数派グループを形成するので機能停止する。シナリオ（Ｈ）で稼働を継続したノードＴＥ１、ＳＭ１、及びＳＭ３はここで機能停止し、その理由は、コーラスに加入しようとしているノードが２つであるために、これらのノードが新しいコーラスで少数派グループになるためである。
【0106】
概念的には、ｎ個のノードを有するコーラスは、最大で（ｎ－（ｎ／２＋１））個のノードがコーラス内の残りのノードから分離されるネットワーク分断（またはコーラス内の最大で（ｎ－（ｎ／２＋１））個のノードの同時障害）を許容し、依然として稼働を継続することができる。単一のノードがコーラスに加入しようとしている場合、ｎが奇数の場合に、コーラスは（ｎ－（ｎ／２＋１）－１）個のノードの分離を許容し、依然として稼働を継続することができる。単一の新しいノードの場合、ｎが偶数の場合に、コーラスは（ｎ－（ｎ／２＋１））個の分離を許容し、依然として稼働を継続することができる。
【0107】
コーラスの障害許容数を、コーラス内の全てのノードが機能停止せずにコーラスが許容できる最大のノード障害数とする。ｎ個のノードを有するコーラスでは、コーラスに加入する新しいノードがない場合、コーラスの障害許容数は（ｎ－（ｎ／２＋１））である（表１の列１）。コーラスに加入しようとしているノードが１つである場合、コーラスの故障（ｆａｕｌｔ）許容数は、ｎが奇数の場合は（ｎ－（ｎ／２＋１））に低下し、ｎが偶数の場合は（ｎ－（ｎ／２＋１））のままである（表１の列２）。コーラスに（同時に）加入しようとしている新しいノードの数が１より大きい場合、コーラスの障害許容数はさらに低下し得る。表１は、コーラス内の様々なノード数（ｎ）と、同時にコーラスに加入しようとしている様々なノード数（ｎj）とについてのコーラスの障害許容数をまとめたものである。以下の表１では、同時にコーラスに加入しようとしているｎj個のノードが存在し、多数派パーティション内の少なくとも１つのノードがｎj個全てのノードのＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信している。
表１
表１
【0108】
シナリオＢ、Ｄ、及びＦ（上記）の障害解決は、ｎ＝３及びｎj＝１のテーブルエントリに取り込まれている。この構成のコーラス障害許容数はゼロであるので、（ノードの少なくとも１つがＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信して）新しいノードが加入している最中に、ネットワーク分断（または任意のノード障害）が発生したことにより、コーラス全体が機能停止する。シナリオＡは表１には取り込まれておらず、その理由は、シナリオＡの多数派グループのいずれのノードもＭｓｇＯｂｊｅｃｔＡｖａｉｌａｂｌｅを受信しなかったためである。シナリオＨは、ｎ＝４及びｎj＝１のエントリに取り込まれている。シナリオＨのコーラス障害許容数は１である。コーラスは少数派パーティションに単一のノードを有するので、コーラスは稼働を継続する。シナリオＩは、ｎ＝４及びｎj＝２のエントリに取り込まれている。この構成のコーラス障害許容数はゼロであるので、ノードが加入している間のネットワーク分断によって、コーラス全体が機能停止する。
【0109】
ノード障害への対処
このセクションでは、分散データベースシステムがネットワーク障害を解決している間の１つまたは複数のノード障害（またはシャットダウン）への対処について論じる。上記で論じたように、ネットワーク障害イベントを解決する処理は、ノードが障害検出メッセージを交換することと、ノードが交換されたメッセージに基づいて稼働を継続すべきか否かを判断することと、稼働を継続すると決断したノードが被疑ノードのフェイルオーバーを実行することと、を含む。この処理は図１９に示している。
このセクションでは、分散データベースシステムがネットワーク障害を解決している間の１つまたは複数のノード障害（またはシャットダウン）への対処について論じる。上記で論じたように、ネットワーク障害イベントを解決する処理は、ノードが障害検出メッセージを交換することと、ノードが交換されたメッセージに基づいて稼働を継続すべきか否かを判断することと、稼働を継続すると決断したノードが被疑ノードのフェイルオーバーを実行することと、を含む。この処理は図１９に示している。
【0110】
図１９では、コーラスはメンバー｛Ａ，Ｂ，Ｃ，Ｄ｝を含む。ネットワーク分断によって｛Ａ，Ｂ，Ｃ｝がＤから分離される。ノードＡ、Ｂ、及びＣはノードＤを疑い、障害検出メッセージを交換し、稼働を継続すると決断し、Ｄのフェイルオーバーを実行する。ノードＤはノードＡ、Ｂ、及びＣを疑い、障害解決プロトコルを開始し、自身を機能停止させる。
【0111】
ｐｉｎｇ（ハートビート）タイムアウトが有効になっている場合、ノード障害によって、障害が発生したノードの隣接機が障害解決プロトコルを開始（または再開始）し、障害が発生したノードを排除することについて合意し、障害が発生したノードをコーラスから排除する。分散データベースシステムがネットワーク障害イベントを解決している最中にノード障害が発生した場合、障害が発生したノードは、障害が発生したノードの隣接機にとって、新しい被疑機となって現れ得る。これにより、隣接機にプロトコルを再開始させることができる。したがって、分断の解決中にノード障害に対処するための特別なメカニズムは存在しない。代わりに、本明細書に記載の処理により、ノード障害に応答して障害解決プロトコルを開始／再開始したノードは、コーラスメンバーシップについて一致することを確実にする。
【0112】
障害検出メッセージの交換中のノード障害への対処
障害検出メッセージを交換している間にノードに障害が発生した場合、そのノードは自身の隣接機の被疑ノードリスト上に存在しなくなる。その結果、隣接ノードは、上記で論じた処理と同様に、コーラスメンバーシップ／コーラスサイズについて意見が一致することになる。ノード障害によって生じた新しい被疑機を検出したことに応答して、隣接機は更新された被疑リストを使用して障害解決処理を再開始する。この更新された被疑リストは、ネットワーク障害によって生じた被疑ノードと、障害が発生したノードとの和集合である。隣接機は、更新された被疑リストに基づいて多数派グループを形成する場合、稼働を継続する。
障害検出メッセージを交換している間にノードに障害が発生した場合、そのノードは自身の隣接機の被疑ノードリスト上に存在しなくなる。その結果、隣接ノードは、上記で論じた処理と同様に、コーラスメンバーシップ／コーラスサイズについて意見が一致することになる。ノード障害によって生じた新しい被疑機を検出したことに応答して、隣接機は更新された被疑リストを使用して障害解決処理を再開始する。この更新された被疑リストは、ネットワーク障害によって生じた被疑ノードと、障害が発生したノードとの和集合である。隣接機は、更新された被疑リストに基づいて多数派グループを形成する場合、稼働を継続する。
【0113】
図２０では、ネットワーク分断によって｛Ａ，Ｂ，Ｃ｝がＤから分離され、ノードがメッセージを交換している間に、ノードＣに障害が発生する。ノードＡ及びＢは、Ｃを疑うと、プロトコルを再開始する。Ａ及びＢは、コーラス｛Ａ，Ｂ，Ｃ，Ｄ｝において多数派グループを形成しないので、機能停止する。
【0114】
フェイルオーバー実行中のノード障害への対処
ノードがフェイルオーバーを実行している間に（機能停止したノードをコーラスメンバーシップリストから削除している間に）ノードに障害が発生した場合、その隣接機は他の被疑ノードのフェイルオーバーを開始または完了している場合がある。その結果、隣接機は、自身らのノードリストから１つまたは複数の被疑ノードを削除している場合があるので、隣接機はプロトコルの開始／再開始時にコーラスメンバーシップ／コーラスサイズが一致しない場合がある。
ノードがフェイルオーバーを実行している間に（機能停止したノードをコーラスメンバーシップリストから削除している間に）ノードに障害が発生した場合、その隣接機は他の被疑ノードのフェイルオーバーを開始または完了している場合がある。その結果、隣接機は、自身らのノードリストから１つまたは複数の被疑ノードを削除している場合があるので、隣接機はプロトコルの開始／再開始時にコーラスメンバーシップ／コーラスサイズが一致しない場合がある。
【0115】
図２１では、コーラスはメンバー｛Ａ，Ｂ，Ｃ，Ｄ｝を含む。ネットワーク分断によって、｛Ａ，Ｂ，Ｃ｝がＤから分離される。ノードＡ、Ｂ、及びＣは、プロトコルを開始し、障害検出メッセージを交換し、稼働を継続すると決断する。ノードＡ、Ｂ、及びＣはノードＤのフェイルオーバーを開始する。ＡがＤのフェイルオーバーを完了した後（及びＤを自身のノードリストから削除した後）、ＢがまだＤのフェイルオーバーを実行している間に、ノードＣに障害が発生する。これにより、ＡはＣを疑い、コーラス｛Ａ，Ｂ，Ｃ｝及び被疑リスト｛Ｃ｝でノード障害処理を開始する。また、それによって、Ｂはコーラス｛Ａ，Ｂ，Ｃ，Ｄ｝及び被疑リスト｛Ｃ，Ｄ｝でノード障害処理を開始する。その結果、Ａ及びＢはコーラスメンバーシップについて一致しない。
【0116】
この場合、次のようにして、ノードはコーラスサイズについて一致するようになる。
【0117】
機能停止していないノードは、ブロードキャストのラウンド１及び２の間に、自身らの完全な接続情報（すなわち、自身らの隣接ノードリストならびに自身らの被疑ノードリスト）を交換する。ノードは、ラウンド１／ラウンド２メッセージを受信した後、自身らの被疑ノードリスト及び隣接ノードリストを自身らの隣接機の被疑ノードリスト及び隣接ノードリストと比較する。ノードは、自身が認識していないｎj個のノードについて自身の隣接機が認識していることに気づいた場合、自身のコーラスサイズをｎjだけインクリメントし、障害解決処理を再開始する。
【0118】
したがって、ｎを多数派パーティション内のノード数とし、ｆを機能停止したノード数とし、ｅをフェイルオーバーが実行されている排除されるノード数とした場合、（ｎ－ｆ）≧（ｓ／２＋１）であれば、パーティション内のノードは稼働を継続することになり、ここで（ｎ≦ｓ≦ｎ＋ｅ）である。
【0119】
しかしながら、ノードが障害解決処理を実行している間に、ノードでフェイルオーバーが完了したらどうなるだろうか。コーラスメンバーの稼働を維持する可能性を高めるために、障害解決処理に次の変更を加えることができる。ノードが排除されるノードのフェイルオーバーを完了した後、障害解決処理を再開始し（１つが進行中の場合）、これにより、この処理はより小さいコーラスサイズで実行される。
【0120】
ノードがより小さいコーラスサイズで再開始した場合に全てのノードがコーラスサイズについて一致するようにするために、この処理は次のようにさらに拡張することができる。ノードはブロードキャストのラウンド１及び２の間に、自身らの完全な接続情報（すなわち、自身らの隣接ノードリストならびに自身らの被疑ノードリスト）を交換する。次に、ノードは、自身らの被疑ノードリスト及び隣接ノードリストを、自身らの隣接機の被疑ノードリスト及び隣接ノードリストと比較する。ノードは、自身が認識していないｎj個のノードについて自身の隣接機が認識していることに気づいた場合、自身のコーラスサイズをｎjだけインクリメントし、処理を再開始する。その後、ノードの隣接機が自身のコーラスリストからｒj個のノードを削除して処理を再開始した場合、ノードは自身のコーラスサイズをｒjだけデクリメントし、処理を再開始する。
【0121】
これにより、ノードはコーラスサイズについて一致するが、疑わしいメンバーシップを有するノードと新しいノードとが機能停止している限り、ノードはコーラスメンバーシップ（またはコーラスサイズ）について一致する必要はない。言い換えると、各ノードは、そのノードのマスターカタログノードリストによって決定されたコーラスメンバーシップに基づいて、障害解決処理を実行することができる。この処理では、メンバーシップが合意されていないノードが、処理の開始前に機能停止されるか、処理中に機能停止される限り、全てのノードが正しい結果に到達することが保証される。
【0122】
これが成り立つ理由を理解するために、ｎ＋ｎjをコーラス内のノード数とする。ｎはマスターカタログが完全であるノード数であり、ｎjは機能停止したノード数と、機能停止することになるノード数（ノード障害のケースのように、これらのノードのマスターカタログは機能停止時に完全である場合があり、完全でない場合もある）、または障害解決プロトコルを開始すると機能停止することになる新しいノードの数（ノード加入のケースのように、これらのノードのマスターカタログは機能停止時に完全にならない）との合計である。
【0123】
ｓを障害解決プロトコルに参加するノードのマスターカタログノードリストのサイズとすると、ｎ≦ｓ≦ｎ＋ｎjである。なお、ｓが障害解決プロトコルに参加する全てのノードで同じではない場合があることに留意されたい。
【0124】
障害解決プロトコルは、各ノードが自身のマスターカタログノードリストサイズに設定されたコーラスサイズを使用してプロトコルを実行する場合、最大で１つのパーティション内のノードが稼働を継続することを保証できるだろうか。保証できるが、その理由は、ｎ≦ｓ≦ｎ＋ｎjであるので、各ノードによって計算される多数派グループサイズは少なくとも（ｎ／２＋１）であるためである。パーティション内の各ノードが多数派グループ内にいる（ｎ／２＋１≦多数派グループサイズ＜（ｎ＋ｎj）／２＋１）と結論付けることができる場合、そのパーティションは少なくとも（ｎ／２＋１）個のノードを有する。プロトコルに参加しているノードはｎ個のみであるので、そのようなパーティションを最大で１つにすることができる。したがって、最大で１つのパーティション内のノードは、障害解決プロトコルを正常に完了し、稼働を継続することができる。
【0125】
パーティション内の全てのノードが、そのパーティションが勝利全接続コンポーネントになるために、自身が多数派全接続コンポーネント内にいると結論付ける必要はない。パーティション内のノードのサブセットは、自身らのマスターカタログノードリストサイズに応じて、自身らが多数派グループ内にいないと結論付け得る。これらのノードは、処理（図１２）のステージ２の間に機能停止して、そのパーティション内の残りのノードが処理を再開始する。しかしながら、残りのノードが処理の再開始時に自身らが多数派グループ内にいると結論付けることができる場合は、その全接続コンポーネントを勝利全接続コンポーネントにするために、それで十分であり得る。
【0126】
追加の性能目標の達成
ユーザがコーラスメンバーノードの半数以上をシャットダウンすることを選択した場合、障害検出をトリガーすることができない。これは、手動でシャットダウンされたノードを被疑ノードとして扱わないように障害解決処理を修正することで実現される。
ユーザがコーラスメンバーノードの半数以上をシャットダウンすることを選択した場合、障害検出をトリガーすることができない。これは、手動でシャットダウンされたノードを被疑ノードとして扱わないように障害解決処理を修正することで実現される。
【0127】
シャットダウン中のノードの識別
管理レイヤからシャットダウン要求を受信すると、ノードは、（たとえば、ノード状態ＮＯＤＥ＿ＳＴＡＴＥ＿ＳＨＵＴＴＩＮＧ＿ＤＯＷＮによって）自身がシャットダウン中であることを示すメッセージノード状態（ＭｓｇＮｏｄｅＳｔａｔｅ）メッセージをブロードキャストする。分散データベースシステム内の管理レイヤは、ユーザが分散データベースとやりとりできるノードのレイヤである。管理レイヤは、分散データベースシステム内のノードを追跡することができ、ユーザと分散データベースシステム内のノードとの間のやりとりを容易にすることができる。たとえば、ユーザがノードをシャットダウンしたい場合、ユーザは管理レイヤにシャットダウンコマンドを出すことができ、次いで管理レイヤは、ユーザが指定したノードにシャットダウンメッセージを送信する。この処理は、少なくとも１つのコーラスメンバーが、シャットダウン中のノードからこのノード状態メッセージを受信することに依存している。
管理レイヤからシャットダウン要求を受信すると、ノードは、（たとえば、ノード状態ＮＯＤＥ＿ＳＴＡＴＥ＿ＳＨＵＴＴＩＮＧ＿ＤＯＷＮによって）自身がシャットダウン中であることを示すメッセージノード状態（ＭｓｇＮｏｄｅＳｔａｔｅ）メッセージをブロードキャストする。分散データベースシステム内の管理レイヤは、ユーザが分散データベースとやりとりできるノードのレイヤである。管理レイヤは、分散データベースシステム内のノードを追跡することができ、ユーザと分散データベースシステム内のノードとの間のやりとりを容易にすることができる。たとえば、ユーザがノードをシャットダウンしたい場合、ユーザは管理レイヤにシャットダウンコマンドを出すことができ、次いで管理レイヤは、ユーザが指定したノードにシャットダウンメッセージを送信する。この処理は、少なくとも１つのコーラスメンバーが、シャットダウン中のノードからこのノード状態メッセージを受信することに依存している。
【0128】
障害解決プロトコルの変更
障害解決プロトコルに以下の変更を加えることができる。
（ａ）処理（図１２）のステージ１の間に、シャットダウン中であることがわかっているノードを被疑ノードとは見なさない。
（ｂ）コーラスメンバーに、シャットダウン中のノードのゴシップをさせる（たとえば、処理のステージ３及び４の間に障害検出メッセージを交換する）。
障害解決プロトコルに以下の変更を加えることができる。
（ａ）処理（図１２）のステージ１の間に、シャットダウン中であることがわかっているノードを被疑ノードとは見なさない。
（ｂ）コーラスメンバーに、シャットダウン中のノードのゴシップをさせる（たとえば、処理のステージ３及び４の間に障害検出メッセージを交換する）。
【0129】
どのようにしてこれらの変更が手動でシャットダウンされているノードを識別したいという要望を満たすことができるかについての一例を以下に示す。ノードＡ、Ｂ、Ｃ、及びＤを有するコーラスについて考察する。ユーザがノードＣ及びＤをほぼ同時にシャットダウンすると仮定する。ノードＡのみがＣからノード状態メッセージを受信し、ノードＢのみがＤからノード状態メッセージを受信すると仮定する。ノードＡは、コーラス｛Ａ，Ｂ，Ｃ，Ｄ｝、被疑リスト｛Ｄ｝、及びシャットダウン中ノードリスト｛Ｃ｝で障害解決処理を開始し、ラウンド１障害検出メッセージをＢに送信する。ノードＢは、コーラス｛Ａ，Ｂ，Ｃ，Ｄ｝、被疑リスト｛Ｃ｝、及びシャットダウン中ノードリスト｛Ｄ｝でプロトコルを開始し、ラウンド１障害検出メッセージをＡに送信する。障害検出メッセージを受信したことに応答して、ノードＡは自身のシャットダウン中ノードリストを｛Ｃ，Ｄ｝に更新し、被疑リストを｛｝に更新し、プロトコルを再開始する。ノードＢも同様にする。ラウンド１の後、ノードＡ及びＢは、コーラスサイズ＝４及び被疑ノードリストサイズ＝０に基づいて、自身らが多数派のパーティション内にいると結論付け、稼働を継続する。
【0130】
しかしながら、ノードがシャットダウンしている間にネットワーク分断またはリンク障害が発生した場合、修正されたプロトコルはどのようにして正しい処理に到達するだろうか。このシナリオを考察する。コーラスはノードＡ、Ｂ、Ｃ、Ｄ、及びＥを含む。ユーザはノードＥをシャットダウンし、ほぼ同時にネットワーク分断によって｛Ａ，Ｂ｝が｛Ｃ，Ｄ｝から分離される。全てのノードがＥからノード状態メッセージを受信すると仮定する。ノードＡはコーラス｛Ａ，Ｂ，Ｃ，Ｄ，Ｅ｝、被疑リスト｛Ｃ，Ｄ｝、及びシャットダウン中ノードリスト｛Ｅ｝でプロトコルを開始し、ラウンド１障害検出メッセージをＢに送信する。ノードＢも、コーラス｛Ａ，Ｂ，Ｃ，Ｄ，Ｅ｝、被疑リスト｛Ｃ，Ｄ｝、及びシャットダウン中ノードリスト｛Ｅ｝でプロトコルを開始し、ラウンド１障害検出メッセージをＡに送信する。障害検出メッセージを受信すると、ノードＡ及びＢは、（コーラスサイズ＝５及び被疑ノードリストサイズ＝２に基づいて）自身らが多数派のパーティションにいると結論付け、稼働を継続する。ノードＣ及びＤも同じロジックで稼働を継続する。次のアプローチにより、このシナリオでプロトコルが正しい処理に到達することを保証することができる。ノード（複数可）がシャットダウンしている間にネットワーク分断（またはリンク障害）が発生した場合、シャットダウン中のノードを被疑ノードとして扱う。
【0131】
要約すると、ユーザがコーラスメンバーノードの半数以上をシャットダウンする場合（ＳＤをこのノードセットとする）、この処理により、以下の条件が成り立つ場合、残りのノード（ＮＳＤをこのノードセットとする）が稼働を継続することになる。
（Ａ）ＮＳＤの少なくとも１つのノードは、ＳＤの各ノードからノード状態変更メッセージを受信する。
（Ｂ）ＮＳＤの各ノードは、ＳＤの少なくとも１つのノードからノード状態メッセージを受信する。（この理由は、ＮＳＤのノードがＳＤのいずれのノードからもノード状態メッセージを受信しない場合、そのノードはＳＤの全てのノードを疑うことになり、他のノードからのシャットダウン中のノードについて知る前に、ステージ２で自身を機能停止させることになるためである。）
（Ｃ）ＮＳＤのノードが障害解決プロトコルを完了し、ＳＤのノードをコーラスから排除するまで、ネットワーク分断もリンク障害も発生しない。
（Ａ）ＮＳＤの少なくとも１つのノードは、ＳＤの各ノードからノード状態変更メッセージを受信する。
（Ｂ）ＮＳＤの各ノードは、ＳＤの少なくとも１つのノードからノード状態メッセージを受信する。（この理由は、ＮＳＤのノードがＳＤのいずれのノードからもノード状態メッセージを受信しない場合、そのノードはＳＤの全てのノードを疑うことになり、他のノードからのシャットダウン中のノードについて知る前に、ステージ２で自身を機能停止させることになるためである。）
（Ｃ）ＮＳＤのノードが障害解決プロトコルを完了し、ＳＤのノードをコーラスから排除するまで、ネットワーク分断もリンク障害も発生しない。
【0132】
結び
様々な本発明の実施形態を本明細書で説明及び図示してきたが、本明細書に記載の機能を実行するための、ならびに／あるいは結果及び／または利点のうちの１つもしくは複数を得るための様々な他の手段及び／または構造を当業者は容易に想像すると思われ、また、そのような変形例及び／または変更例のそれぞれは、本明細書に記載の本発明の実施形態の範囲内にあると考えられる。より一般的には、本明細書に記載の全てのパラメータ、寸法、材料、及び構成は典型的なものであることが意図されており、実際のパラメータ、寸法、材料、及び／または構成は、本発明の教示が使用される１つまたは複数の特定の用途に依存することを当業者は容易に理解するであろう。当業者は、ほんの日常的な実験によって、本明細書に記載した本発明の特定の実施形態に対する多くの均等物を認識または確認することができるであろう。したがって、前述の実施形態は単なる例として示しており、添付の特許請求の範囲及びその均等物の範囲において、本発明の実施形態が、具体的に説明し、特許請求した以外の方法で実施され得ることを理解されたい。本開示の発明の実施形態は、本明細書に記載した各個別の特徴、システム、物品、材料、キット、及び／または方法に向けられている。加えて、２つ以上のそのような特徴、システム、物品、材料、キット、及び／または方法の任意の組み合わせは、そのような特徴、システム、物品、材料、キット、及び／または方法が相互に矛盾していない場合には、本開示の発明の範囲に含まれる。
様々な本発明の実施形態を本明細書で説明及び図示してきたが、本明細書に記載の機能を実行するための、ならびに／あるいは結果及び／または利点のうちの１つもしくは複数を得るための様々な他の手段及び／または構造を当業者は容易に想像すると思われ、また、そのような変形例及び／または変更例のそれぞれは、本明細書に記載の本発明の実施形態の範囲内にあると考えられる。より一般的には、本明細書に記載の全てのパラメータ、寸法、材料、及び構成は典型的なものであることが意図されており、実際のパラメータ、寸法、材料、及び／または構成は、本発明の教示が使用される１つまたは複数の特定の用途に依存することを当業者は容易に理解するであろう。当業者は、ほんの日常的な実験によって、本明細書に記載した本発明の特定の実施形態に対する多くの均等物を認識または確認することができるであろう。したがって、前述の実施形態は単なる例として示しており、添付の特許請求の範囲及びその均等物の範囲において、本発明の実施形態が、具体的に説明し、特許請求した以外の方法で実施され得ることを理解されたい。本開示の発明の実施形態は、本明細書に記載した各個別の特徴、システム、物品、材料、キット、及び／または方法に向けられている。加えて、２つ以上のそのような特徴、システム、物品、材料、キット、及び／または方法の任意の組み合わせは、そのような特徴、システム、物品、材料、キット、及び／または方法が相互に矛盾していない場合には、本開示の発明の範囲に含まれる。
【0133】
また、種々の発明概念は、１つまたは複数の方法として具現化され得、その一例を提供している。方法の一部として実行される行為は、任意の適切な方法で並べられ得る。したがって、図示とは異なる順序で行為が実施される実施態様が構築され得、これには、いくつかの行為を、例示的な実施形態では順次的な行為として示していたとしても、同時に行うことが含まれ得る。
【0134】
本明細書で定義及び使用する全ての定義は、辞書の定義、引用により組み込まれた文献における定義、及び／または定義した用語の通常の意味に優先するものと理解されたい。
【0135】
不定冠詞「ａ」及び「ａｎ」は、本明細書及び特許請求の範囲で使用する場合、明瞭にそうでないという指示がない限り、「少なくとも１つ」を意味するものと理解されたい。
【0136】
「及び／または」という語句は、本明細書及び特許請求の範囲で使用する場合、そのように等位接続された要素の「一方または両方」、すなわち、あるケースでは連言的に存在し、他のケースでは選言的に存在する要素を意味するものと理解されたい。「及び／または」を用いて列記された複数の要素は、同様に、すなわち、そのように等位接続された要素のうちの「１つまたは複数」として解釈されたい。「及び／または」の節によって具体的に特定した要素以外の他の要素が、具体的に特定したそれらの要素に関係しているか関係していないかに関わらず、任意選択で存在してもよい。したがって、非限定的な一例として、「Ａ及び／またはＢ」への言及は、「備える」などのオープンエンドの文言と共に使用する場合、一実施形態ではＡのみ（任意選択でＢ以外の要素を含む）を指し、他の実施形態ではＢのみ（任意選択でＡ以外の要素を含む）を指し、さらに他の実施形態ではＡ及びＢの両方（任意選択で他の要素を含む）などを指すことができる。
【0137】
本明細書及び特許請求の範囲で使用する場合、「または」は、上記で定義した「及び／または」と同じ意味を有するものと理解されたい。たとえば、リスト内の項目を分ける場合、「または」あるいは「及び／または」は包括的であると解釈され、すなわち、いくつかの要素または要素のリスト、及び任意選択で列記されていないさらなる項目のうちの少なくとも１つを含むだけでなく、２つ以上も含むと解釈されるものとする。明瞭にそうでないという指示がある用語、たとえば、「～のうちの１つのみ」もしくは「～のうちのちょうど１つ」、または特許請求の範囲で使用する場合の「～から成る」のみが、いくつかの要素または要素のリストのうちのちょうど１つの要素を含むことを指す。全般的に、「または」という用語は、本明細書で使用する場合、排他性の用語、たとえば、「～のいずれか」、「～のうちの１つ」、「～のうちの１つのみ」、または「～のうちのちょうど１つ」などを伴う場合には、排他的な選択肢（すなわち、「一方または他方であるが両方ではない」）のみを示すと解釈されるものとする。「本質的に～から成る」は、特許請求の範囲で使用する場合には、特許法の分野で用いられる場合のその通常の意味を有するものとする。
【0138】
本明細書及び特許請求の範囲で使用する場合、１つまたは複数の要素のリストに関連する「少なくとも１つ」という語句は、その要素のリスト内の要素のうちの任意の１つまたは複数から選択された少なくとも１つの要素を意味するものと理解されるべきであり、必ずしもその要素のリスト内に具体的に列記されたありとあらゆる要素のうちの少なくとも１つを含む必要はなく、その要素のリスト内の要素のあらゆる組み合わせを除外するものでもない。また、この定義は、「少なくとも１つの」という語句が指す要素のリスト内に具体的に特定した要素以外の要素が、具体的に特定したそれらの要素に関係しているか関係していないかに関わらず、任意選択で存在してもよいということも認める。したがって、非限定的な一例として、「Ａ及びＢのうちの少なくとも１つ」（もしくは同義的に「ＡまたはＢのうちの少なくとも１つ」、または同義的に「Ａ及び／またはＢのうちの少なくとも１つ」）は、一実施形態では、少なくとも１つのＡがあり、任意選択で２つ以上のＡを含み、Ｂは存在しないこと（及び任意選択でＢ以外の要素を含む）、他の実施形態では、少なくとも１つのＢがあり、任意選択で２つ以上のＢを含み、Ａは存在しないこと（及び任意選択でＡ以外の要素を含む）、さらに他の実施形態では、少なくとも１つのＡがあり、任意選択で２つ以上のＡを含み、少なくとも１つのＢがあり、任意選択で２つ以上のＢを含むこと（及び任意選択で他の要素を含む）、などを指す場合がある。
【0139】
特許請求の範囲ならびに上記の明細書では、全ての移行句、たとえば、「備える」、「含む」、「運ぶ」、「有する」、「包含する」、「伴う」、「保持する」、「～から成る」などは、オープンエンドであることを、すなわち、「～を含むがこれらに限定されない」を意味することを理解されたい。「～から成る」及び「本質的に～から成る」という移行句のみが、それぞれクローズド移行句またはセミクローズド移行句であるものとし、これらについては米国特許庁の特許審査便覧、セクション２１１１．０３に記載されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【国際調査報告】