JP5557840B2 - 分散データベースの監視メカニズム - Google Patents

分散データベースの監視メカニズム Download PDF

Info

Publication number
JP5557840B2
JP5557840B2 JP2011529547A JP2011529547A JP5557840B2 JP 5557840 B2 JP5557840 B2 JP 5557840B2 JP 2011529547 A JP2011529547 A JP 2011529547A JP 2011529547 A JP2011529547 A JP 2011529547A JP 5557840 B2 JP5557840 B2 JP 5557840B2
Authority
JP
Japan
Prior art keywords
replica
node
partition
nodes
active
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2011529547A
Other languages
English (en)
Other versions
JP2012504807A5 (ja
JP2012504807A (ja
Inventor
デニス ヘンリクセン,
ヒメネス, ホルヘ ネヴァド
マルティン アリバス, マルタ サン
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン(パブル) filed Critical テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Publication of JP2012504807A publication Critical patent/JP2012504807A/ja
Publication of JP2012504807A5 publication Critical patent/JP2012504807A5/ja
Application granted granted Critical
Publication of JP5557840B2 publication Critical patent/JP5557840B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278Data partitioning, e.g. horizontal or vertical partitioning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275Synchronous replication

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は分散データベースに関し、特に通信ネットワークのための共通データベースとして利用可能な地理的に分散したデータベースに関する。さらに具体的に、本発明は改良された分散データベースシステムだけでなく、このような分散データベースシステムを扱う方法を含む。
本発明は通信ネットワークの分野におけるアプリケーションの多様性について共通集中データベースが有する問題を解決する。通信システムの様々に異なる世代をサポートし、有線システムまたは無線システムである通信ネットワークのほとんどは、従来、加入情報および加入者データだけでなく、通信ネットワーク内または第三者のサービスネットワーク内に存在するが当該通信ネットワークの加入者がアクセス可能である様々なアプリケーションについてのサービスデータを格納するために、1つ以上の共通集中データベースを利用する。
通信ネットワークが成長するにつれて、通信システムの新たな世代が現われ、既存の共通集中データベースは通信ネットワーク内のすべての通信システムのニーズに常に適合できるとは限らず、またはこのニーズに常に適切であるとは限らない。それにも係わらず、通信ネットワークは、ここで利用される任意の特定のデータベースシステムで満たされるべき極めて類似する要件を共有する。
従来の中央管理通信データベースは一般に、少なくとも以下の特徴をサポートする必要がある。回復性および高可用性、一貫性、高性能および低レンテイシ、大容量、拡張性、地理的冗長性、柔軟な配置およびデータモデル、単一アクセス(各地理的位置に1つ)、ならびに単一障害点の不存在。
この点において、従来の中央管理通信データベースについての地理的冗長性は一般に、メインノードに加えて複製されたノードを有するものとして理解されてきた。ここで、メインノードは動作中であり、複製されたノードはメインノードが何らかの理由でダウンした場合に動作を再開するためにスタンバイしている。
近年、純粋な集中データベースは、いくつかある欠点の中で特に、信号転送の観点で極めて高コストである。実際に、一部のデータが他のデータよりも頻繁にアクセスされるように様々なアプリケーションデータがするため、そのリソースの使用は十分にバランスが取られていない。集中データベースが位置する地理的位置に関して、経済的な観点だけでなく負荷および障害のリスクの観点の両方において、信号転送のコストについて選択が極めて重要になりうる。明らかに、データベースクライアントとデータベース自体との間の信号経路が長くなると、ノードがその最終宛先へ信号をさらに送出することができなくなるリスクが大きくなる。同様に、この信号パスが長くなると、通信ネットワークがサポートする負荷が大きくなり、実行時間が長くなる。これとは別に、通信ネットワークは、他のネットワーク事業者に属している様々なアクセスネットワークを通じてしばしば通信される様々な遠くの領域を通じて広がる。このシナリオでは、この信号経路が長くなると、より多くの通信事業者が影響を受け、より多くのコストが引き出されうる。
他方で、他の技術を調査すると、分散データベースは、場合によっては中央データベース管理システムの制御の下で、物理的または論理的に分散された複数のデータベースとしてみなされてもよく、必ずしもすべての記憶装置が共通の処理部に接続される必要はない。よって、分散データベースは同一の物理的位置に位置する複数のコンピュータで構築されてもよいし、相互接続されたコンピュータのネットワーク上に点在してもよい。
一般的に言うと、データベースインスタンスの分散はデータ分散自体の結果である必要はなく、高可用性システムおよび地理的冗長性を得るためのデータレプリケーションのために有益である。特に、従来の集中データベースシステムを、中央管理または分散された共通バックエンドへアクセスする複数の通信データベースフロントエンドで置き換えるいわゆるデータレイヤアーキテクチャ技術は、通信データベースについての上記の要件を満たし、データ分散およびレプリケーションに利用可能な分散データベースの例示の適用性である。
分散データベースの様々なデータベースインスタンスにおけるデータのレプリケーションは、様々なデータベースインスタンスにおいて現存するレプリカを最新に維持するために複雑な管理を必要とする。さらに、通信ネットワークの分野の従来の分散データベースのクライアントは、近くのデータベースインスタンスにおける任意のデータベース関連の動作が常に実行可能であるとは限らない。よって、当該データベース関連の動作に必要な信号経路を常に最短化できるとは限らない。さらに、通信ネットワークの分野における従来の分散データベースのクライアントは、任意のデータベースインスタンスが利用不可能であるデータへのアクセスで問題を経験しうる。
本発明は上述の欠点を少なくとも軽減し、データの少なくとも1つのパーティションのレプリカを格納するようにそれぞれが構成された複数のノードを有する改良された分散データベースシステムと、当該分散データベースシステムを扱う方法とを提供する。
本発明の第1側面では、データの少なくとも1つのパーティションのレプリカを格納するようにそれぞれが構成された複数のノードを有する分散データベースシステムを扱う新たな方法が提供される。
この方法は、格納されるデータをp個のパーティションに分割するステップと、各パーティションをr個のレプリカに複製するステップと、各パーティションについて、前記r個のレプリカを前記複数のノードの中から選択された対応するr個のノードに分配するステップと、相互にアドレスを指定するために使用可能である他のノードの識別子のリストを各ノードに設定するステップと、前記複数のノードの中から2つ以上のノードを起動するステップと、各アクティブノードにおいて、各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とのうちから選択された少なくとも1つのイベントを監視するステップと、前記複数のノードの中のノードの起動又は停止の際に、前記アクティブノードの中のどのノードが各パーティションについての現在のマスタノードであり、当該パーティションについての現在のマスタレプリカを担当するとみなされるかを決定するステップと、前記分散データベースシステム内のデータの読み出し/書き込みを行うことの、ノードにおいて受信された任意のリクエストについて、当該データが属するパーティションと当該パーティションについての現在のマスタレプリカを担当する現在のマスタノードとを決定し、当該リクエストを当該現在のマスタノードへルーティングするステップとを有する。
前記アクティブノードの中のどのノードが各パーティションについての前記マスタノードであり、それ故当該パーティションについての現在のマスタレプリカを担当しているとみなされるかを決定する際に、前記方法は、前記アクティブノードの中の少なくとも1つのノードにおいて、各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とのうちから選択された前記少なくとも1つのイベントに関する情報を各アクティブノードから収集するステップと、各レプリカについての前記収集されたイベントに依存して、前記アクティブノード内の各レプリカの優先順位を決めるための事前に設定されたルールを適用するステップと、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされるステップとを含んでもよい。
本発明は、前記アクティブノードの中のどのノードが各パーティションについてのマスタノードであり前記パーティションについての現在のマスタレプリカを担当するとみなされるかを決定する際に、2つの主な実施形態、すなわち動作モードを提供する。
第1動作モードでは、処理の観点からすべてのノードは似たもの同士のノードであるため、すべてのノードが同じ情報を処理でき、各パーティションについて、現在のマスタレプリカを担当する同じマスタノードを決定することに到りうる。この実施形態のもとでは、前記少なくとも1つのアクティブノードではなく、分散データベースシステム内の各ノードが以下のステップを実行するように構成されてもよい。すなわち、前記アクティブノードの中の少なくとも1つのノードにおいて、各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とのうちから選択された前記少なくとも1つのイベントに関する情報を各アクティブノードから収集するステップと、各レプリカについての前記収集されたイベントに依存して、前記アクティブノード内の各レプリカの優先順位を決めるための事前に設定されたルールを適用するステップと、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされるステップとである。
第2動作モードでは、前記複数のノードの中の任意のノードの起動または停止の際に、前記方法は前記アクティブノードが起動された順序を決定するステップをさらに有してもよい。この場合に、前記アクティブノードが起動された順序を決定するようにすべてのノードが構成され、その結果、最初に起動されたアクティブノードは以下のステップの実行を担当するいわゆるシステムマスタモニタノードであるとみなされる。すなわち、 各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とのうちから選択された前記少なくとも1つのイベントに関する情報を各アクティブノードから収集するステップと、各レプリカについての前記収集されたイベントに依存して、前記アクティブノード内の各レプリカの優先順位を決めるための事前に設定されたルールを適用するステップと、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされるステップと、各パーティションについて選択された前記マスタレプリカと当該マスタレプリカを保持する前記マスタノードとに関して他のアクティブノードへ通知するステップとである。
前記収集されたイベントに依存して、事前に設定されたルールの適用が2つ以上のレプリカについて同一の優先度を生み出す場合に特に有用であるが、各パーティションについて、前記r個のレプリカを対応するr個のノードに分配するこの方法の前記ステップは、他の基準が同一のレプリカ優先度を生み出す場合に適用されるデフォルトレプリカ優先度を各レプリカに設定するステップを含んでもよい。この場合に、前記アクティブノードの中のどのノードが各パーティションについてのマスタノードであり、当該パーティションについての現在のマスタレプリカを担当するとみなされるかを決定する前記ステップは、前記少なくとも1つのアクティブノードにおいて、各パーティションについての所与のデフォルトレプリカ優先度が設定されていることに関する情報を少なくとも1つのアクティブノードから収集するステップと、各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされるステップとを含んでもよい。特に、上記の第1動作モードに従って前記方法が動作する場合に、前記少なくとも1つのノードではなく、前記分散データベースシステム内の各ノードがこれらのステップを実行するように構成されてもよい。
しかしながら、上記第2動作モードに従って前記方法が動作する場合に、最初に起動されたアクティブノードはシステムマスタモニタであるとみなされ、前記アクティブノードの中のどのノードが各パーティションについての現在のマスタノードであり、当該パーティションについての現在のマスタレプリカを担当するとみなされるかを決定するステップは、当該システムマスタモニタノードにおいて、各パーティションについての所与のデフォルトレプリカ優先度が設定されていることに関する情報を少なくとも1つのアクティブノードから収集するステップと、各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされるステップと、各パーティションについて選択された前記マスタレプリカと当該マスタレプリカを保持する前記マスタノードとに関して他のアクティブノードへ通知するステップとを含んでもよい。
一般的に言うと、すべての読み出し/書き込み動作は関連するパーティションについてのマスタレプリカ上で実行される。従って、マスタレプリカの内容と、同一のパーティションについての他のレプリカの内容とは所定の時点において異なりうる。各パーティションについての様々なレプリカの間での一貫性を維持するために、前記方法は、各パーティションについて各アクティブノードにおいて前記現在のマスタレプリカの内容を、当該パーティションについての前記現在のマスタレプリカを担当する前記現在のマスタノードからコピーするステップをさらに有してもよい。コピーするステップが行われる場合に、前記方法は、各アクティブノードにおいてコピーされた各レプリカについて、行われた前記最新の更新と、レプリカ状態と、前記レプリカを担当するローカルリソースの状態と、前記レプリカの接続状態とのうちの少なくとも1つを作成するステップをさらに有してもよい。これは特に、前記マスタレプリカを担当する現在のマスタノードに障害が生じ、ダウンまたは利用不可能になり、もしくは非アクティブノードになる場合に将来の別のマスタレプリカを選択するために有利である。
他方で、本発明の第2側面に従うと、複数のノードを有する分散データベースシステムであって、各ノードはデータの少なくとも1つのパーティションのレプリカを格納するように構成される改良された分散データベースシステムが提供される。この分散データベースシステムにおいて、各ノードは、格納されるデータの少なくとも1つのデータパーティションのレプリカを格納するとともに、相互にアドレスを指定するために使用可能である他のノードの識別子を格納するためのデータ記憶装置と、前記分散データベースシステムの他のノードと通信するとともに、前記分散データベースシステムにおいて読み出し/書き込み動作を要求するクライアントと通信するための入出力部と、各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とのうちから選択された少なくとも1つのイベントを監視するための監視部と、前記データ記憶装置、前記監視部及び前記入出力部と連携して、前記分散データベースシステム内のアクティブノードの中のどのノードが各パーティションについての現在のマスタノードであり、当該パーティションについての現在のマスタレプリカを担当するとみなされるかを決定し、前記分散データベースシステム内のデータの読み出し/書き込みを行うことの、受信された任意のリクエストについて、当該データが属するパーティションと当該パーティションについての現在のマスタレプリカを担当する現在のマスタノードとを決定し、当該リクエストを当該現在のマスタノードへルーティングするための制御部とを含む。
上記方法と整合して、前記分散データベースシステムが第1動作モードに従って動作するか第2動作モードに従って動作するかにかかわらず、各ノードの前記処理部、前記監視部、前記データ記憶装置及び前記入力部は、各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とのうちから選択された少なくとも1つのイベントに関する情報を前記分散データベースシステムの各アクティブノードから収集し、各レプリカについての前記収集されたイベントに依存して、前記アクティブノード内の各レプリカの優先順位を決めるための事前に設定されたルールを適用し、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択し、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされるように構成されてもよい。
特に、前記収集されたイベントに依存して、事前に設定されたルールの適用が2つ以上のレプリカについて同一の優先度を生み出す場合の上記方法に有利に整合して、各ノードの前記データ記憶装置は、他の基準が同一のレプリカ優先度を生み出す場合に適用されるデフォルトレプリカ優先度を示すようにレプリカごとに設定されたインジケータを格納するように構成されてもよい。この場合に、各ノードの前記処理部、前記監視部、前記データ記憶装置及び前記入力部は、パーティションについての所与のデフォルトレプリカ優先度が設定されていることに関する情報を少なくとも1つのアクティブノードから収集し、各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択し、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされるようにさらに構成されてもよい。
また、上記方法に整合して、分散データベースシステムが第2動作モードに従って動作する場合に特に適用可能であるが、各ノードの前記処理部、前記監視部、前記データ記憶装置及び前記入力部は、前記分散データベースシステムの各アクティブノードから、前記アクティブノードが起動された順序を決定するための情報を収集するように構成されてもよい。
この場合に、最初に起動されたアクティブノードはシステムマスタモニタであるとみなされてもよく、前記システムマスタモニタの前記処理部、前記監視部、前記データ記憶装置及び前記入力部は、各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とのうちから選択された少なくとも1つのイベントに関する情報を各アクティブノードから収集し、各レプリカについての前記収集されたイベントに依存して、前記アクティブノード内の各レプリカの優先順位を決めるための事前に設定されたルールを適用し、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択し、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされ、各パーティションについて選択されたマスタレプリカと当該マスタレプリカを保持するマスタノードとに関して他のアクティブノードへ通知するように構成されてもよい。
さらに、上述のデフォルト優先度が第2動作モードの下でのパーティションについてのレプリカの優先順位を決めるために関連する場合に、前記処理部、前記監視部、前記データ記憶装置及び前記入力部は、パーティションについての所与のデフォルトレプリカ優先度が設定されていることに関する情報を少なくとも1つのアクティブノードから収集し、各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択し、このレプリカが前記マスタレプリカであるとみなされ、この特定のノードが前記パーティションについての前記マスタノードであるとみなされ、各パーティションについて選択された前記マスタレプリカと当該マスタレプリカを保持する前記マスタノードとに関して他のアクティブノードへ通知するようにさらに構成されてもよい。
各パーティションについての様々なレプリカの間での一貫性を維持し、それゆえ上記の方法と整合するために、各ノードの前記処理部、前記監視部、前記データ記憶装置及び前記入力部は、各パーティションについて各アクティブノードにおいて前記現在のマスタレプリカの内容を、当該パーティションについての前記現在のマスタレプリカを担当する前記現在のマスタノードからコピーするようにさらに構成される。さらに、現在のマスタレプリカが何らかの理由で非アクティブになる場合にマスタレプリカを担当する別のマスタノードをさらに選択するために、各ノードの前記処理部、前記監視部、前記データ記憶装置及び前記入力部は、各アクティブノードにおいてコピーされた各レプリカについて、行われた前記最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、前記レプリカの接続状態とのうちの少なくとも1つを作成するようにさらに構成されてもよい。
他方で、本発明の第3側面に従って本発明はコンピュータプログラムで実施されてもよい。コンピュータプログラムは入出力部と処理部とを有するコンピュータの内部メモリにロード可能なコンピュータプログラムであって、上記の方法を実行するように構成された実行可能なコードを含む。特に、この実行可能なコードはコンピュータにおいて読み出し可能な記録媒体に記録されてもよい。
本発明の機能、目的および利点は添付の図面と併せて本明細書を読むことによって明らかになるだろう。
格納されるデータをp個のパーティションに分割し、各パーティションをr個のレプリカに複製するために実行される動作シーケンスの簡略図。 各パーティションについて、r個のレプリカを複数のノードの中から選択された対応するr個のノードに分配し、相互にアドレスを指定するために使用可能である他のノードの識別子のリストを各ノードに設定する動作シーケンスの簡略図。 データの少なくとも1つのパーティションのレプリカを格納するように各ノードが構成された複数のノードを有する分散データベースシステムを扱う方法を実行するために、図1Aおよび図1Bに説明された動作と連動して実行される動作シーケンスの簡略図。 本発明の一部の実施形態を説明するために有用なデータを有する分散データベース内の複数のノードの例示の構成の簡略図。 分散データベースに含まれる複数のノードの中のノードの例示の実装を説明する図。 本発明の一部の実施形態を説明するためにクラスタとして構成された有用なデータを有する分散データベース内の複数のノードの中のノードの例示の構成の簡略図。 分散データベース内のデータの読み出し/書き込みを行うことの、ノードにおいて受信された任意のリクエストを、このようなデータが属するパーティションについての現在のマスタレプリカを担当する現在のマスタノードへルーティングするために実行される動作シーケンスの簡略図。 アクティブノードの中のどのノードが、他のノードの調整と各レプリカのついてのマスタノードがどれであるかの決定とを担当するコントローラシステムモニタであるとみなされるかを決定するために本発明の実施形態に従って提供される例示の状態マシンを説明する図。 分散データベースシステム内の複数のノードの起動の際にアクティブノードの中のどのノードがコントローラシステムモニタであるとみなされるかを決定するために、図6に示される状態マシンのサポートのもので実行される例示の動作シーケンスを説明する図。 以前にみなされていたコントローラシステムモニタの非アクティブ化の際にアクティブノードの中のどのノードがコントローラシステムモニタであるとみなされるかを決定するために、図6に示される状態マシンのサポートのもので実行される別の例示の動作シーケンスを説明する図。
データの少なくとも1つのパーティションのレプリカをそれぞれが格納する複数のノードを有する改良された分散データベースシステムと当該分散データベースシステムを扱う方法との現時点で好適な実施形態を以下に説明する。
通信データベースシステムは複数の地理的に分散されたノードを含んでもよく、各ノードは複数のデータ記憶部を含んでもよく、各ノード内の各データ記憶部はデータの部分集合の特定のレプリカ、すなわちパーティションのレプリカを割り振ってもよい。図1Aおよび図1Bに説明されるように、ノード1〜4のデータ記憶部の間でのデータ集合10の例示の分配は本発明に従って提供される複数のステップに従って実行されうる。
図1Aに示されるように、データ集合10はステップS−005の間に複数のパーティション11〜14に分割され、各パーティションはデータ集合10の特定の部分集合を有する。次いで、各パーティションについて、ステップS−010の間に複数のレプリカが生成される。各パーティションについてのレプリカの個数はすべてのパーティションについて同じである必要はない。よって、図1Aに示される例のように、4つのレプリカ111〜114がパーティション11について生成され、3つのレプリカ121〜123とレプリカ141〜143とがパーティション12と14とについてそれぞれ生成され、ただ2つのレプリカ131、132がパーティション13について生成される。
図1Bに示されるように、これらのレプリカは、必要となる地理的な分散を決定する予備的なステップS−015の間にパーティションごとにグループ分けされてもよい。これとは別に、データベースシステムを構成するノードの地理的な分配を決定する際に、各ノードはステップS−017の間にアドレス目的に利用可能な識別子が割り当てられる。図1Bの例示の説明は別個の識別子N−1ID、N−2ID、N−3IDおよびN−4IDを有する4つのノード1〜4で構成される。
次いで、ステップS−020の間に、各パーティションについて生成されたレプリカは、データベースシステムを構成するノードに分配されてもよい。図1Bに説明される例では、第1パーティションの第1レプリカ111はノード1に格納され、第1パーティションの第2レプリカ112はノード2に格納され、第1パーティションの第3レプリカ113はノード3に格納され、第1パーティションの第4レプリカ114はノード4に格納され、第2パーティションの第1レプリカ121はノード3に格納され、第2パーティションの第2レプリカ122はノード1に格納され、第2パーティションの第3レプリカ123はノード2に格納され、第3パーティションの第1レプリカ131はノード4に格納され、第3パーティションの第2レプリカ132はノード1に格納され、第4パーティションの第1レプリカ141はノード3に格納され、第4パーティションの第2レプリカ142はノード4に格納され、第4パーティションの第3レプリカ143はノード2に格納される。よって、各パーティションについてのレプリカを格納するためにすべてのノードが必要であるとは限らず、本発明の側面に従って提供される分散データベースシステムの各ノードにすべてのパーティションがレプリカを有さなければならないというわけではない。
これとは別に、各ノードはまたこのステップの間に、他のノードの識別子を設定されてもよい。よって、ノード1はノード2、3、4を識別する識別子151を格納する。ノード2はノード1、3、4を識別する識別子152を格納する。ノード3はノード1、2、4を識別する識別子153を格納する。ノード4はノード1、2、3を識別する識別子154を格納する。
動作中に、以下に説明される所定のイベントに依存して、所定のノード内の1つの特定のレプリカが最高の優先度を取得してもよく、それ故パーティションについてのマスタレプリカであると決定される一方で、所定のノードは当該パーティションについてのマスタノードとみなされる。しかしながら、イベントが相異なるノード内のパーティションの相異なるレプリカについて同一の優先度を生み出し、その結果、マスタレプリカが決定され得ない状況が存在しうる。2つ以上のレプリカに同一の優先度が与えられる曖昧さを省くために、本発明は他の基準、すなわち上記のイベントの処理結果は同一のレプリカ優先度を生み出す場合に、各レプリカを適用されるデフォルトのレプリカ優先度を設定することを提供する。図2に示されるように、各ノード1〜4はそれぞれ、複数のパーティションについてレプリカ1101、2101、3101、4101と、レプリカごとのデフォルト優先度1102、2102、3102、4102を含む。
分散データベースシステムの各ノードが上述のように構成されると、分散データベースシステムはオペレータが望むようにノードごとにまたは一斉に動作に入ることの準備が整う。
図1Cは本発明の別の側面に従って上記の分散データベースシステムを扱う方法を実行するための後続の動作シーケンスを説明する。すべてのノードが同様に振舞うが、本発明の実施形態に従って以下に説明されるように、各ノードにおける完全な動作シーケンスは相異なるノードが起動される順序に依存してもよい。よって、図1Cの例はノード2がステップS−030の間に最初に起動されるものであり、その後にステップS−035の間にノード3が起動され、次いでステップS−060の間にノード4であり、最後にステップS−070の間にノード1であるシナリオが説明される。
各ノード2、3、4、1の起動の後に、各アクティブノードにおいて当該ノードが起動された開始時刻を決定するそれぞれのステップS−040、S−045、S−080、S−075が続いてもよい。このオプションのステップは、以下に説明される他のノードとの連携と各パーティションについてのマスタレプリカがどれであるかの決定とを担当するシステムマスタモニタとして動作するノードを有するデータベースシステムが動作している場合に、アクティブノードが起動された順序をさらに決定するために有用である。この点において、図2に説明されるように、各ノード1〜4は、開始時刻からノードが稼動している動作時間を示すそれぞれの表示1104、2104、3104、4104を含む。
各ノードについて開始時刻を決定するステップが実行されるかどうかに係わらず、総括的に、各ノード2、3、4、1の起動の後に、各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とから選択される少なくとも1つのイベントを各アクティブノード2、3、4、1において監視するステップS−050、S−055、S−095、S−090のそれぞれが続く。
この目的のために、図2に説明される例のように、各ノード1〜4はそれぞれ、複数のパーティションについて、レプリカ1101、2101、3101、4101とともに、レプリカごとに最新の更新のインジケータ1103、2103、3103、4103を含み、且つ上述のようにレプリカごとのデフォルトの優先度1102、2102、3102、4102を含む。図2に示されるデータの例とは別に、図4に示されるように各ノード1〜4においてレプリカごとに他のデータが格納されてもよい。よって、図4に説明される例のように、ノード2はそれぞれ複数のパーティションについてレプリカ112、123、143とともに、レプリカごとの接続状態のインジケータ312、323、343を含み、且つレプリカ212、223、243ごとに、レプリカがマスタレプリカであるとみなされているか、起動中であるがマスタではないアクティブレプリカであるか、起動していないとみなされうるように設定が行われているスタンバイレプリカであるかを示すレプリカ状態を含む。特に、各ノードはさらに、図示されてはいないが、各レプリカについてのローカルリソースを監督するプロセスがこのようなイベントを監視するステップから分離されうるように、レプリカごとにローカルリソースの状態のインジケータを含めるための、レプリカごとの記憶フィールドをさらに有してもよい。これに替えて、各アクティブノードにおいて選択の少なくとも1つのイベントを監視する上述のステップは、各レプリカについてローカルリソースを監督するステップと各ローカルリソースの状態を決定するステップとを含んでもよい。
なおも図4を参照して、この分散データベースシステムの各ノード1〜4は複数のクラスタで構成されてもよく、各クラスタは、パーティションのレプリカと、レプリカについての接続状態のインジケータと、レプリカについてのレプリカ状態と、レプリカごとの最新の更新のインジケータと、レプリカごとのデフォルト優先度とを含む。よって、図4に説明された例として、ノード2はクラスタ160、170、180を備え、各クラスタはそれぞれレプリカについてのデータおよびインジケータとともに、パーティションのレプリカ112、123、143を含む。
図1Cに説明される動作シーケンスに戻り、イベントを監視するステップが各ノードにおいて実行されると、各ノードはステップS−065、S−085、S−100、S−110のそれぞれの間に、各ノードに知られているすべての他のノードへのいわゆる「アライブ(Alive)」メッセージの送信を開始する。
当業者は理解するかもしれないが、ノード4がノード1よりも前に開始されたにもかかわらず、ノード1における一部の動作はノード4における対応する動作の前に生じる。これは一般的に起こりうる。なぜなら、1つのノードにおけるプロセッサ負荷は別のノードにおける負荷よりも高いかもしれず、結果として前者における性能が低下するからであり、またこれは様々なネットワーク経路を通じる様々な信号遅延に起因しうる。
図1Cに特に例示として説明されるように、ノード2は、ノード1が起動される前に、ステップS−065でいわゆる「アライブ」メッセージを送信した。ノード2はステップS−100の間にノード1からの「アライブ」メッセージを受信するので、ノード2はノード1が当初の「アライブ」メッセージを受信しておらず、ノード1がすべてのノードからの完全な情報を有していないことを認識してもよい。これらの状況では、現在の例示の状況におけるノード2のようなノードはイベントを再び監視するステップS−105と、ノード2に知られているすべてのノードへ「アライブ」メッセージを再び送出するステップS−115とを実行する。さらに、これも図1Cに示されるように、ノード2においてイベントを監視するステップS−105と「アライブ」メッセージを送出するステップS−115との中間のステップS−110の間にノード2においてノード3からの「アライブ」メッセージが受信され、その結果としてノード2から送出された最新の「アライブ」メッセージは、各ノードがすべての他のアクティブノードを認識している最新であるとみなされうる。
これらの「アライブ」メッセージは分散データベースシステムのノード間で交換され、分散データベースシステムのノードの起動または停止の際に、以下に説明されるように、アクティブノードのうちのどのノードが各パーティションについての現在のマスタノードであり、当該パーティションについての現在のマスタレプリカを担当するとみなされるかを決定するために有用である。
上述のように、動作中に決定された所定のイベントが、パーティションについてのマスタレプリカと当該マスタレプリカを担当するマスタノードとを決定する際に考慮に入れられる。各パーティションについてのマスタレプリカがどれであるかを決定するために、以下の情報が考慮に入れられてもよい。すなわち、各パーティションについてどのレプリカが完全な情報、つまり更新レベルを有する直近に更新された内容を有するかと、明らかに稼動中のレプリカだけが適格であるので各パーティションについての各レプリカのレプリカ状態と、各パーティションについての各レプリカの接続状態と、パーティションの各レプリカについて設定されたデフォルト優先度である。さらに、デフォルト優先度は以前の基準の結果を上書きするように構成されてもよく、以前の基準がパーティションのレプリカの2つ以上について同じ結果を生み出す場合にのみ適用可能となるように構成されてもよい。
さらに、動作中に決定されたこれらのイベントに依存して、アクティブノード内の各レプリカの優先順位を決めるために事前に設定されたルールが適用されてもよい。例えば、事前に設定されたルールは、接続状態が更新レベルに優先度を引き継ぐようなものであってもよいし、レプリカ状態のすぐ後でデフォルト優先度が考慮に入れられるものであってもよいし、レプリカの優先順位を決めるためのイベントに関する他の如何なる基準であってもよい。
パーティションについての各レプリカの内容だけでなく、このような内容の更新に関して、所定の時刻に各レプリカがマスタレプリカから更新するような従来のルーチンが提供されてもよい。よって、パーティションについてのすべてではないレプリカが同時に内容を更新し、且つ当該パーティションについてのすべてではないレプリカが同じ速度で更新を進行する。更新中に、分散データベースシステム内の各ノードは、レプリカの内容が完全な情報であるとみなされうるかどうかと、交換が実行された時点とを、他のノードと交換される情報がこの点において考慮するように、どれくらい更新が進行しているかを監視する必要がある。
パーティションについてのマスタレプリカと当該マスタレプリカを担当するマスタノードとの決定に関して上述のイベントを考慮に入れるために、各ノードにおいて監視されたイベントは分散データベースシステム内の他のノードへ通信される。この目的のために、各ノード1〜4は他のノードの仮想IPアドレスを設定されてもよく、または互いに識別してアドレスを指定するために別個のノード識別子151〜154を利用してもよい。各ノード1〜4は定期的に、例えば連続した遅延時間が満了した後に、他のノードへ「アライブ」メッセージを送信してもよい。有利には本発明の実施形態において、「アライブ」メッセージは、TCPで簡単に検出される一方向リンク障害の可能性を回避するために、ある種のハートビートについてUDPを利用する代わりに既知のTCPプロトコルで送信されてもよい。
さらに正確に、各「アライブ」メッセージは受信側ノードに対して送信側ノードを識別するノード識別子N−1ID、N−2ID、N−3ID、N−4IDを含み、パーティションの各レプリカについて、レプリカが属するパーティションの識別子、レプリカ状態、更新レベル、更新時刻、接続状態およびデフォルト優先度のうちの少なくとも1つを含んでもよい。
これに加えて、アクティブノードが起動された順序をさらに決定するために特に有用であるように、任意のノード1〜4から分散データベースシステム内の他のノードへ送信された各「アライブ」メッセージはそれぞれ、送信側ノードが自身の開始時刻からアクティブである動作時間の表示1104、2104、3104、4101を含んでもよい。
本発明は2つの主な実施形態、すなわちアクティブノードのうちのどのノードが各パーティションについてのマスタノードであり、当該パーティションについての現在のマスタレプリカを担当するとみなされるかの決定における動作モードを提供する。
第1動作モードでは、処理の観点からすべてのノードは似たもの同士のノードであるため、各ノードはすべての他のノードから、そこで決定された監視情報を有する「アライブ」メッセージを受信し、その結果、すべてのノードが同じ情報を処理でき、各パーティションについて、現在のマスタレプリカを担当する同じマスタノードを決定することに到りうる。この実施形態のもとでは、分散データベースシステム内の各ノードは以下のステップを実行するように構成されてもよい。すなわち、各レプリカの最新の更新、レプリカ状態、各レプリカを担当するローカルリソースの状態、および各レプリカの接続状態から選択された少なくとも1つのイベントに関する情報を各アクティブノードから収集するステップと、各レプリカについて収集されたイベントに依存して、アクティブノード内の各レプリカの優先順位を決めるための事前に設定されたルールを適用するステップと、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカがマスタレプリカであるとみなされ、この特定のノードが当該パーティションについてのマスタノードであるとみなされるステップとである。
特に有利にはこの第1動作モードの下で如何なる特定のレプリカについてこれらのイベントが最高のレプリカ優先度を結果として生じない場合に、分散データベースシステム内の各ノードはさらに以下のステップを実行するように構成されてもよい。すなわち、パーティションについての所与のデフォルトレプリカ優先度を設定されている情報を少なくとも1つのアクティブノードから収集するステップと、各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカがマスタレプリカであるとみなされ、この特定のノードが当該パーティションについてのマスタノードであるとみなされるステップとである。
第2動作モードでは、アクティブノードが起動された順番を決定するためにすべてのノードが「アライブ」メッセージを処理し、その結果、最初に起動されたアクティブノードは以下のステップの実行を担当するいわゆるシステムマスタモニタノードであるとみなされる。すなわち、各レプリカの最新の更新、レプリカ状態、各レプリカを担当するローカルリソースの状態、および各レプリカの接続状態から選択された少なくとも1つのイベントに関する情報を各アクティブノードから収集するステップと、各レプリカについて収集されたイベントに依存して、アクティブノード内の各レプリカの優先順位を決めるための事前に設定されたルールを適用するステップと、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカがマスタレプリカであるとみなされ、この特定のノードが当該パーティションについてのマスタノードであるとみなされるステップと、各パーティションについて選択されたマスタレプリカと当該マスタレプリカを保持するマスタノードとに関して他のアクティブノードへ通知するステップとである。
特に有利にはこの第2動作モードの下で如何なる特定のレプリカについてこれらのイベントが最高のレプリカ優先度を結果として生じない場合に、分散データベースシステム内のシステムマスタモニタノードはさらに以下のステップを実行するように構成されてもよい。すなわち、パーティションについての所与のデフォルトレプリカ優先度を設定されている情報を少なくとも1つのアクティブノードから収集するステップと、各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、このレプリカがマスタレプリカであるとみなされ、この特定のノードが当該パーティションについてのマスタノードであるとみなされるステップと、各パーティションについて選択されたマスタレプリカと当該マスタレプリカを保持するマスタノードとに関して他のアクティブノードへ通知するステップとである。
上述の方法を実行するために、本発明は総括的にノード1〜4のような複数のノードを有する分散データベースシステムを提供する。各ノードはデータの少なくとも1つのパーティションのレプリカを格納するように構成される。ノード2について図3に説明される例のように、各ノードは格納されるデータの少なくとも1つのデータパーティション112、123、143のレプリカ2101を格納するとともに、相互にアドレスを指定するために用いられる他のノードの識別子152を格納するためのデータ記憶装置15と、分散データベースシステムの他のノード1、3、4と通信するための入出力部30と、各レプリカの最新の更新2103、レプリカ状態212、223、243、各レプリカを担当するローカルリソースの状態、各レプリカの接続状態312、323、343から選択された少なくとも1つのイベントを監視するための監視部60と、データ記憶装置、監視部および入出力部と連動して、分散データベースシステムのアクティブノードのうちのどのノードが各パーティションについての現在のマスタノード2105であり、当該パーティションについての現在のマスタレプリカを担当するとみなされるかを決定するための処理部20とを備える。
さらに、この分散データベースシステムでは、各ノードの処理部20、監視部60、データ記憶装置15および入出力部30は、各レプリカの最新の更新1103、2103、3103、4103、レプリカ状態212、223、243、各レプリカを担当するローカルリソースの状態、および各レプリカの接続状態312、323、343から選択された少なくとも1つのイベントに関する情報を各アクティブノードから収集し、各レプリカについて収集されたイベントに依存して、アクティブノード内の各レプリカの優先順位を決めるための上述の事前に設定されたルールを適用し、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択するステップし、このレプリカがマスタレプリカであるとみなされ、この特定のノードが当該パーティションについてのマスタノードであるとみなされるように構成される。
さらに、特に有利には分散データベースシステムにおいて如何なるレプリカについて以前のイベントが最高のレプリカ優先度を結果として生じない場合に、各ノードの処理部20、監視部60、データ記憶装置15および入出力部30は、パーティションについての所与のデフォルトレプリカ優先度を設定されている情報を少なくとも1つのアクティブノードから収集し、各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択し、このレプリカがマスタレプリカであるとみなされ、この特定のノードが当該パーティションについてのマスタノードであるとみなされるように構成される。
第2動作モードに従って分散データベースシステムを動作するために、各ノードの処理部20、監視部60、データ記憶装置15および入出力部30は、アクティブノードが起動された順序を決定するための情報1104、2104、3104、4104を分散データベースシステムの各アクティブノードから収集するように構成され、その結果、最初に起動されたアクティブノードがシステムマスタモニタであるとみなされる。
特に、ノードが分散データベースシステムのシステムマスタモニタノードであるとみなされる場合に、当該システムマスタモニタの処理部20、監視部60、データ記憶装置15および入出力部30はさらに、各パーティションについて選択されたマスタレプリカと当該マスタレプリカを保持するマスタノードとに関して他のアクティブノードへ通知するように構成されてもよい。
分散データベースシステムを扱う上記の方法は、分散データベーシステムのクライアントがどのように当該システムに格納された情報にアクセスしうるか、特に読み出し動作または書き込み動作のためにアクセスしうるかに関する特定の議論が必要となりうる。
原則として、通信ネットワークのホームロケーションレジスタ、認証センタ、またはホーム加入者サーバのような分散データベースシステムのクライアントは分散データベースシステムの任意のノードから任意のデータへアクセスできる。しかしながら、様々なレプリカ内でデータの一貫性を維持するために、レプリカのうちの1つだけが読み出しおよび/または書き込みのリクエストを受信し、これはマスタレプリカであるだろう。上述のように、マスタレプリカ内のデータは他のレプリカへ時々刻々と更新される。
よって、分散データベースシステムの全内容は、分散データベースシステムを構成する任意のノードからアクセス可能である。この目的ために、各ノードは1つ以上のアクセスゲートウェイ(以下、AG)を含んでもよく、AGはマスタレプリカが位置するノードへデータの読み出し/書き込みを行うリクエストを転送することを担当するエンティティである。データベースプロトコルはアクセスプロトコルと異なりうるため、AGはデータの読み出し/書き込みを行うリクエストをクライアントから受信し、分散データベースシステム内の他のノードへアクセスすることを担当する。性能を最大化するために各ノード内に2つ以上のAGが提供されうるため、2つ以上のAGの間でトラフィックを分配するためにロードバランサ(以下、LB)が提供されてもよい。しかしながら、このようなLBはただ1つのAGを有するノード構成では必要ではない。
図5が説明するように、ノード2はLB109aおよび3つのAG191a〜193aを備えてもよく、第1パーティション11についてのレプリカ112、第2パーティション12についてのレプリカ123、および第4パーティション14についてのレプリカ143を担当してもよく、レプリカ112は第1パーティションについてのマスタレプリカであり、ノード2は第1パーティションについての当該マスタレプリカを担当するマスタノードである。一方で、ノード3はLB190bおよび3つのAG191b〜193bを備えてもよく、第1パーティション11についてのレプリカ113、第2パーティション12についてのレプリカ121、および第4パーティション14についてのレプリカ141を担当してもよく、レプリカ121は第2パーティションについてのマスタレプリカであり、ノード3は第2パーティションについての当該マスタレプリカを担当するマスタノードである。
よって、分散データベースシステムを扱うこの方法は、分散データベースシステム内のデータの読み出し/書き込みを行うためにノードにおいて受信された任意のリクエストについて、当該データが属するパーティションと当該パーティションについての現在のマスタレプリカを担当する現在のマスタノードとを決定するステップと、当該リクエストを当該現在のマスタノードへルーティングするステップとを含む。
図5に説明される例のように、分散データベースシステム内のデータの読み出し/書き込みを行うためのクライアント5からのリクエストはノード2のような任意のノードで受信されうる。図5の例はステップS−150の間にLB190aにおいて受信されたデータの読み出し/書き込みを行うリクエストを説明する。このリクエストはステップS−151の間にAG193aに割り当てられ、AG193aは読み出し/書き込みを行うデータが第2パーティション12に属することを判定し、このAGはまた、当該パーティションを担当する現在のマスタノードがノード3であることを判定する。次いで、AG193aはステップS−152の間にリクエストをノード3へルーティングする。このリクエストは当該ノード3に2つ以上のAGが存在するならばノード3のLB190bにおいて受信されてもよいし、ノード3が1つのAGのみを含むならば唯一のAGにおいて受信されてもよいし、この図5に示される例のように、設定手段によってノード3の特定のAG191bがAG193aに知られているならばこのようなAGにおいて受信されてもよい。リクエストを受信するノード3のAG191bはステップS−152の間にリクエストに従ってデータの読み出し/書き込みを行うために第2パーティション12についてのマスタレプリカ121にアクセスする。
他方で、図5はまた、データが属するパーティションについてのマスタレプリカを保持するマスタノードにおいてリクエストが受信される場合を説明する。この例の場合では、データの読み出し/書き出しを行うリクエストはステップS−160の間にノード2のLB190aにおいて受信される。
このリクエストはステップS−161の間にAG191aに割り当てられてもよく、AG191aは読み出し/書き込みを行うデータが第1パーティション11に属することを判定し、このAGはまた、当該パーティションを担当する現在のマスタノードがこのノード2であることを判定する。次いで、AG191aはステップS−162の間に、リクエストに従ってデータの読み出し/書き込みを行うために、第1パーティション11についてのマスタレプリカ112へアクセスするようにリクエストを内部的にルーティングする。
ノード2のような、分散データベースシステムの任意のノードのLBは、図3に説明されるようなクライアント5との通信専用の入出力部50と、ノードの負荷および性能のバランスをとるために適切なAGを選択するように構成された処理部20のリソースとで構築されてもよい。この入出力部50は、分散データベースシステムの各ノードが備える入出力部30の一体部分であってもよいし、当該入出力部30に含まれる別個のモジュールであってもよい。
ノード2のような、分散データベースシステムの任意のノードのAGは図3に説明されるような他のノード1、3、4との通信専用の入出力部40と、読み出し/書き込みを行うデータが属するパーティションを決定し、当該パーティションについてのマスタレプリカを担当するマスタノードが現在のノードであるかまたは分散データベースシステムの別のノードであるかを判定し、当該パーティションについてのマスタレプリカを担当するマスタノードが現在のノードである場合に当該データへアクセスするためにデータ記憶装置15へアクセスし、それ以外の場合に現在のマスタノードであると判定された別のノードへリクエストをルーティングするように構成された処理部20のリソースとで構築されてもよい。
本発明の実施形態に従うと、監視部60は上述のイベントを監視し蓄積する一意のユニットである、本明細書におけるいわゆるローカルシステムモニタ(以下、LSM)を含んでもよく、またはアクティブLSMとスタンバイLSMとを含み、前者に障害が生じた場合に後者が動作を引き継げるようにしてもよい。以下において、監視部またはLSMへの如何なる言及も、言及されているノード内のアクティブLSMを意味すると解釈される。
特に、本発明が上述の第2動作モードに従って動作する場合に、いわゆるシステムマスタモニタノードの監視部60がコントローラシステムモニタ(以下、CSM)であるとみなされるが、分散データベースシステム内の他のノードの各監視部はなおもLSMとして言及される。よって、CSMは分散データベースシステム内の各ノードのLSMから受信されたイベント情報を考慮に入れ、且つアクティブノード内の各レプリカの優先順位を決めるための事前に設定されたルールを適用することによって、マスタレプリカでどれであるかを決定してもよい。CSMは各パーティションについてのマスタノードが何であるかを他のノード内の各LSMと通信する。
第2動作モードにおいてアクティブノードのうちのどのノードがシステムマスタモニタとみなされるかを決定する際に、図6に説明される例示の状態マシンが適用される。状態間の遷移は他のノードからの「アライブ」メッセージの受信か、タイマの満了かのいずれかに起因する。簡単のために、分散データベースシステム内の他のノードに対してシステムマスタモニタノードを言及するのではなく、以下の議論ではこれらの別個の監視部60、すなわち当該他のノードの各LSMに対するシステムマスタモニタノードのCSMを言及する。
図6に説明される本発明の実施形態では、取りうる状態および遷移は以下でありうる。
‐非アクティブ。これは各LSMが開始した際の状態である。LSMがこの状態にあるならば、ノードはリクエストに応答せず、マスタレプリカのホストになりえない。この状態へ遷移すると、LSMは残りのノードへのアライブメッセージの送信を開始する。
‐アクティブ。アクティブ状態では、各LSMは他のノードに関する情報を有する「アライブ」メッセージをリッスンし、特に存在するならばマスタレプリカを有するCSMからの「アライブ」メッセージをリッスンする。各LSMはまた、自身のノードに関する情報を送信し、自身のノード内で任意のローカルAGへマスタレプリカに関する情報を内部的に分配し、場合によっては「アライブ」メッセージの情報を残りのノードへ転送する。
‐ポテンシャルCSM。所定の設定可能な期間、すなわち本明細書におけるいわゆるDELAY_TIMEの間、LSMがこの状態に留まるならば、このようなLSMはCSMになる。これはまた、DELAY_TIMEが満了する前にシステム内の残りのすべてのノードから「アライブ」メッセージを受信する場合にも生じる。
‐CSM。この状態に到達するノードは分散データベースシステム内のすべてのパーティションについてどのレプリカがマスタレプリカであるかを決定する。
これにもかかわらず、状態、遷移、またはその両方の他の実施形態が同様に予見可能である。
簡単のために任意の状態から非アクティブ状態への遷移が示されていない図6に示される状態間の遷移に関して、任意のLSMは非アクティブ状態から開始し、LSMを有するノードが分散データベースシステム内のすべての他のノードへ「アライブ」メッセージを送信するとすぐに、このLSMはアクティブ状態へ移行する。すなわち、非アクティブ状態からアクティブ状態への遷移ST−1は、非アクティブ状態のLSMを有するノードから分散データベースシステム内のすべての他のノードへ「アライブ」メッセージを送信することである。
2つ以上のサブネットワークがアクティブになることを回避することによってスプリットブレイン状況における一貫性を解決するために提供される本発明のオプションの実施形態に従うと、非アクティブ状態への遷移は、1つ以上のノードに障害が発生し、CSMを含む(n+1)/2個未満の稼動中のノードが存在するか、CSMを含まないn/2+1個未満が存在する場合に発生してもよい。ここで「n」は分散データベースシステム内の全ノード数である。例えば、3つのノードで構成される分散データベースシステムがあり、CSMのホストであるノードが隔離されるならば、そのサブネットワークは1つだけ、すなわち(3+1)/2=2未満のノードを有する。よって、CSMのホストであるこのノードは非アクティブ状態へ移行する。他方のサブネットワークは2つのノードを有し、これは2/2+1=2個以上のノードを有することを意味し、よってこれらはアクティブに留まり、新たなCSMが選択される。このオプションの構成では、各LSMは、設定可能な期間である、本明細書におけるいわゆるINACTIVE_TIMEの後に各LSMが1つ以上のノードから「アライブ」メッセージを受信しないならば、当該1つ以上のノードがダウンしていることを検出する。非アクティブへの遷移により、任意のLSMは自身の実行時間をリセットし、すなわち再び「若く」になる。これは、隔離された以前のCSMが再びCSMになり、使用されるべきでない情報を送信することを防ぐ。
このオプションの実施形態は分散データベースシステムを適切に構成することによって実行されうる。このような実施形態が望まれないならば、適切な設定パラメータがリセットされ、その結果、システムから分離された複数のノードのxxxが、ノードをアクティブ状態へ移行させ、ノード間で分離されている場合であっても2つ以上のサブネットワークで動作させることに無関係になる。
図6に示される状態間の遷移に戻り、上述のオプションの実施形態が動作するように構成されていると仮定すると、アクティブ状態にあるLSMを有する任意のノードは、他のノードから十分な「アライブ」メッセージが得られないならば、すなわちCSMを含む稼働中の(n+1)/2個未満またはCSMを含まないn/2+1個未満であるならば、非アクティブ状態へ移行できる。
そうではなく、他のノードから十分な「アライブ」メッセージが受信され、送信側ノードが後から起動したことを受信された「アライブ」メッセージ内の情報が示し、且つメッセージを送信するノードが残っていない場合に、受信側ノード内のLSMはCSMになる。すなわち、アクティブ状態からCSM状態への遷移ST−2.1は、他のノードからの十分な「アライブ」メッセージの受信であり、分散データベース内にメッセージを送信するノードが残っていないことである。特に2ノードシステムにおいて、メッセージが受信されることなくDELAY_TIMEが経過するかも知れず、同様に当該ノードはCSMになる。しかしながら、他のノードから、当該ノードが後から起動したことを示す「アライブ」メッセージを受信したが、「アライブ」メッセージを受信できると予想されるノードがさらに存在する場合に、遷移ST−2.2が行われ、受信側ノード内のLSMはポテンシャルCSMになる。
以前の遷移について説明したのと同じ理由ために、ポテンシャルCSM状態から、ノードは非アクティブ状態へ戻りうる。そうでなければ、自身のLSMが確定したCSMであることを示す、さらに予想された「アライブ」メッセージがノードから受信された場合、または他のLSMが先に起動したことを示す、さらに予想された「アライブ」メッセージがノードから受信された場合に、図6に説明される遷移ST−3.1が行われ、ポテンシャルCSM状態のLSMは、これらの予想される「アライブ」メッセージのいずれかを受信するノードにおいてアクティブ状態へ移行する。他方で、古いノードを示すさらに予想された「アライブ」メッセージをさらに受信することなくいわゆるDELAY_TIMEが経過した場合、または先に起動したノードが存在しないことを示す「アライブ」メッセージが残りのノードから受信された場合に、図6に説明される遷移ST−3.2が行われ、ポテンシャルCSM状態にあるLSMは、DELAY_TIMEが経過したか、これらの予想された「アライブ」メッセージのいずれかが受信されたノードにおいてCSM状態へ移行する。
上述のように、2種類のタイマが存在する。1つは本明細書におけるいわゆるDELAY_TIMEタイマであり、自身がCSMであると宣言する前に古いLSMに関して通知する、残りのノードの「アライブ」メッセージをLSMが待つ時間である。もう1つは本明細書におけるいわゆるINACTIVE_TIMEタイマであり、ノードがダウンしており利用不可能であることを結論付ける前にこのようなノードからの「アライブ」メッセージをLSMが待つ時間である。
上記の処理が終了すると、CSMとして確定された監視部60を有するノードはマスタレプリカのリストを含む「アライブ」メッセージの送信を開始する。
図6に説明される状態マシンの処理に加えて、図7は、3つの例示のノードの中のどのノードがCSMとして確定された監視部60を有するノードであるかを決定するための分散データベースシステムのノード間での例示の動作シーケンスを示す。上述のように、CSMは最初に起動されたLSMである。これを決定するために、各LSMは起動時に図2に示された例のように動作時間2104、4104を有する「アライブ」メッセージを残りのノードへ送信する。システムの一部であるノードは設定によって知られている。「アライブ」メッセージを送信した後に、LSMは所定の期間であるDELAY_TIMEの間、他のノードから「アライブ」メッセージが受信されるのを待つ。CSMを確立するフェーズは、この時間が経過した場合、または他のノードから十分な「アライブ」メッセージが受信されたならばその前に終了する。このフェーズの間に、この時間までに受信された情報に従ってポテンシャルCSMが割り当てられるかもしれないが、このフェーズが終了するまでそれは確定されないだろう。
よって、図7に説明されるように、ステップS−200の間に起動される最初のノードはノード1である。LSM、すなわちノード1の監視部60が起動するとすぐに、ステップS−205の間に分散データベースシステムの他の2つのノード1、2へ「アライブ」メッセージを送信し、DELAY_TIME秒のタイマを開始する。他のノードはまだ稼動していないので、対応する各LSMはこのような「アライブ」メッセージを受信しない。
次いで、ノード2のLSMはステップS−210の間に稼動を開始し、ステップS−220の間に「アライブ」メッセージをノード1、3へ送信し、DELAY_TIMER秒の自身のタイマを開始する。ノード2のLSMが起動した後ではあるが、ノード2のLSMが「アライブ」メッセージを送信する前に、ノード3のLSMはステップS−215の間に起動し、DELAY_TIMER秒の自身のタイマを開始する。
ノード1がノード2から「アライブ」メッセージを受信する場合に、ノード1はステップS−225の間に自身をポテンシャルCSMとして認定する。なぜなら、ノード1が有する情報を用いて、ノード1は、ノード3からの情報を待つものの、早くに起動したLSMだからである。この段階で、ノード3はステップS−230の間にノード1、2へ「アライブ」メッセージを送信できる。
ノード2がノード3から「アライブ」メッセージを受信する場合に、ノード2はステップS−240の間に自身をポテンシャルCSMとして認定する。なぜなら、ノード2が有する情報を用いて、ノード2のLSMはノード3のLSMよりも早く起動したからである。同様に、ノード3がノード2から「アライブ」メッセージを受信する場合に、ノード3はステップS−245の間にノード2をポテンシャルCSMとして認定する。なぜなら、ノード3が有する情報を用いて、ノード1、2はノード1からの情報を待っており、ノード3にはまだ知られていないが、ノード2のLSMは早くに起動したからである。
ノード1がノード3から「アライブ」メッセージを受信する場合に、ノード1はステップS−235の間に自身を確定したCSMとして認定する。なぜなら、ノード1はシステム内のすべてのノードから「アライブ」メッセージを受信しており、この情報を用いて、ノード1のLSMは早くに起動したものであるからである。よって、ノード1はステップS−250の間に、ノード1が確定したCSMであることを通知する「アライブ」メッセージを他のノードへ送信する。ノード1から最終的に「アライブ」メッセージを受信するノード2、3はステップS−255の間にノード1の監視部がCSMであり、現在の状況において他のノードがこの役割を負わないことを認識し、ステップS−260の間に記録する。
障害の場合にCSMの役割を再割当てできるように、「アライブ」メッセージは各ノードから残りのノードへ定期的に送信される。このように、ノードの追加または削除のような、分散データベースシステムの構成の任意の変化が即座にすべてのノードにおいて知られうる。
よって、本発明の両方の実施形態、すなわち両方の動作モードに従うと、各ノードは、他のノードから受信された情報に基づいて、どのノードがCSMであるとみなされるか、すなわちアクティブノードの中で、より長い動作時間を有するものがどれかを決定してもよい。ノードがCSMになるために、このようなノードは、任意の他のポテンシャルCSMから遠隔の「アライブ」メッセージを受信するための何らかの時間が存在することを保証するために、少なくともDELAY_TIMEを待つことができるだろう。CSM状態に到達したノードは、曖昧さが存在しないことを保証するために残りのノードへ自身の決定を通信してもよい。しかしながら、すべてのノードが第1動作モードに従って振舞う場合にこの通信は必要ない。この通信は信頼性を保証するためにTCPベースであってもよい。再設定時間を低減するために、この振る舞いは、CSMが他のノードへレプリカ構成を通信する際に間接的に実現されてもよい。この点において、レプリカ状態は「アライブ」メッセージに含まれるので、ひとたび選択されると、CSMはどのレプリカ状態の設定が動作に適するかがわかる。実際に、この情報はすべてのノードに知られるかもしれないが、これらは第2動作モードのもとでCSMが確認するのを待ってもよい。
各ノードは、当該ノードが「アライブ」メッセージを受信した、現在のノードを有するリストを、当該メッセージ内で受信されたレプリカ状態とともに管理できるだろう。「アライブ」メッセージが受信されるごとに、送信側ノードがアクティブとして設定されてもよい。パーティションについてのマスタノードはアクティブノードの中だけから選択されてもよい。ノードは、それからメッセージを受信することなく、いわゆるINACTIVE_PERIODという期間が経過している場合に利用可能でないとして設定されてもよい。この時間はメッセージ受信時間の平均時間の2倍または3倍でありえ、これは最初に前述のDELAY_TIMEに設定されうる。ノードはまた、それに送信された「アライブ」メッセージが届かない場合に利用不可能であるとして設定されてもよい。このようにノードの利用可能性は非常に高速に検出される。
一般的に言うと、CSMであるとみなされる監視部60を有するノードは、分散データベースシステム内の他のノードへ、自身のノード識別子、動作時間、各レプリカについてのレプリカ状態、各レプリカについてのマスタノード、状態マシンからのノード状態、(オフラインでさえも)「アライブ」メッセージが受信されているアクティブノードのリスト、現在のマスタレプリカ情報(以下、MRI)、およびMRIを設定するCSMについての(実行時間を含む)更新時間およびノードIDを送出してもよい。
特に、いわゆるMRIメッセージはホストノードを有するレプリカのリストを含みうる。本発明の実施形態では、MRIメッセージはまた、MRIについての確認を受信するために、オフラインのノードへも送信されてもよい。この観点で、オフラインのノードは実CSMノードといわゆるサブCSMノードとの間のリンクであってもよい。後者は、マスタであると信じているがそうではないノード内で稼動しているLSMである。いずれにせよ、上述のように、オフラインのノードのレプリカはマスタとして設定されえない。従って、この問題を回避するために、CSM処理はMRIを送信する前にDELAY_TIMEを待ってもよい。
一般的に言うと、CSM選択メカニズムは、すべての監視プロセスが同期されるようなものである。上述のように、最も古いプロセスがCSMになることがアイデアである。最も古いLSMがどれかを決定する際に、複数の実施形態が予見可能である。第1実施形態では、本発明は動作時間を考慮に入れる。すなわち、各プロセスは、自身のローカル時間を用いて、起動から何秒動作しているかを決定し、この情報を「アライブ」メッセージ内で送信する。この場合に、恐らくはレイテンシが重要な役割を果たすため、以下の欠点が存在するかもしれない。受信側ノードは送信された作業時間を見るだろうが、レイテンシを見ないので、受信側ノードが送信側ノードよりも若いか古いかを正確に判断することは難しいだろう。レイテンシ時間はピングメッセージを介して測定されえ、平均が確立されうるだろう。
第2実施形態では、本発明は起動時刻を考慮に入れる。この実施形態の下で、すべてのプロセスは自身の起動時刻を「アライブ」メッセージ内で送信する。この時刻は各ノードにおけるローカルマシン時刻に関連するだろう。従って、システム内のすべてのマシンを同期する必要があるかもしれない。リナックスシステムおよび一般のオペレーティングシステムはNTPを用いて何年も前にこの問題を解決している。
これらの第1実施形態および第2実施形態の下で、CSM選択処理の間に、図6に説明される例示の状態マシンについての非アクティブ状態にLSMが到達するといつでも、個別の動作時間または起動時刻は、劣化したCSMが回復した際に再びCSM状態に到達することを回避するためにリセットされる必要があるかもしれない。
上述のように、分散データベースシステムの任意のノードの起動または停止の際に、アクティブノードの中で、どのノードが各パーティションについてのマスタレプリカを担当する現在のマスタノードであるかを判定するステップが存在する。このマスタノードがどれであるかを判定する際に、本発明は2つの実施形態を提供する。第1実施形態では、どれがマスタノードであるかを判定するためにすべてのノードは独立して動作する。第2の実施形態では、各パーティションについてどれがマスタノードであるかを決定するためにCSMが決定される。
図8は、例ではノード3である現在みなされているCSMがダウンして、他のノード、すなわちノード1、2に対して利用不可能になる例示の状況を説明する。
図8に示されるように、CSMとして動作するノード3はステップS−300の間に他のノード1、2へ「アライブ」メッセージの最新の集合を送信した。このようなメッセージがそれぞれ受信されると、ノード1、2の両方は、新たな「アライブ」メッセージがノード3から受信されるまでリセットされないいわゆる非活動期間を開始する。ノード3からさらに「アライブ」メッセージを受信することなくノード1、2の両方において非活動期間が満了するため、ノード1、2の両方はそれぞれステップS−320、S−330の間にノード3を利用不可能として記録する。この例示の場合では、ノード2はノード1よりも古く、この情報はノード2に知られている。なぜなら、ノード2はステップS−310の間にノード1から最新の定期的な「アライブ」メッセージを受信しているからである。従って、ノード2はステップS−340の間に、図6に説明される状態マシンに従って、自身をポテンシャルCSM状態へ移行する。次いで、ノード2はステップS−350の間に、自身の定期的な「アライブ」メッセージをノード1とノード3とへ送信するが、後者はこのようなメッセージを受信できない。ノード2から「アライブ」メッセージを受信したノード1は、ノード2が古いことを認識し、ステップS−360の間にノード2が現在のCSMであるという結論にいたる。ノード2においていわゆるDELAY_TIMEが満了した後に、ノード2の監視部60はステップS−370の間にCSMとして確定され、ノード2は現在のシステムマスタモニタである。
さらに、図には示されていないが、ノード3が再び復旧した場合に、ノード3は自身の定期的な「アライブ」メッセージをノード1、2へ送信する。ノード1、2においてこのようなメッセージを受信すると、これらはともに、ノード3を再び利用可能として記録する。上述のように、ノード3はオプションとして自身の動作時間または起動時刻をリセットし、その結果、状況は変化せず、DELAY_TIMEの期間にポテンシャルCSM状態にあった後に、現在のCSMはなおもノード2の監視部であり、これは図6に示される状態マシンに従ってCSM状態へ到達する。
以前に分散データベースシステムに含まれていなかった新たなノードの追加に関して、CSM選択の観点から、状況は、ノードがダウンし再び復旧した状況と非常に類似している。唯一の違いは、障害が発生したノードは設定テーブルに提示されているためCSMに知られているが、全く新たなノードは既存のノードに知られていない点である。この点において、CSMだけでなく他の監視プロセスも、設定されていないノードから受信された「アライブ」メッセージに注意を払わない。従って、新たなノードを導入する重要な側面は、新たなノードの識別子を図1Bに説明されるような既存のノードの対応する設定テーブル151〜154に含めることと、このような新たなノード内にレプリカの構成を含めることとである。これが完了すると、新たなノードの監視部は起動しうる。このように、新たなノードは他の既存のアクティブノードへ「アライブ」メッセージを送信し、他の既存のアクティブノードは新たなノードを認識するだろう。CSMは新たなノード内の新たなレプリカを認識することになるので、これに応じてCSMは必要ならばシステムを再構成する。上記の第1動作モードに従って、すなわちCSMを有さずにシステムが動作する観点で、すべてのノードはそれぞれ、「アライブ」メッセージ内で受信された情報を処理し、各パーティションについてのマスタレプリカを担当するマスタノードがどれであるかに関して同じ結論に到達する。原則として、「アライブ」メッセージはいわゆるMRIメッセージ内に情報を有する。それにもかかわらず、MRIメッセージは「アライブ」メッセージとは別に送信されてもよい。
他方で、稼動中の分散データベースシステムへの新たなパーティションの追加は上述の振る舞いを用いて簡単な作業でありうる。1つのノードにただ1つのレプリカを有する場合よりも高可用性を得るために、それぞれ2つの既存のノードへ追加される少なくとも2つのレプリカ上にパーティションを複製することを考えてもよい。上述のように、任意のノードの構成について、レプリカとは別に、レプリカごとの上述のすべての対応するインジケータが同様に構成されなければならない。よって、第2動作モードでのCSMを有する選択されたシステムマスタモニタノード、または第1動作モードでのすべてのノードは、遅かれ早かれすべてのノードから「アライブ」メッセージを受信する。ここで、新たなレプリカについての情報は当該新たなレプリカのホストとなるノードから受信される。
高可用性を有する分散データベースシステムを効率的に提供するために、監視プロセスも高可用性を有することが期待される。従って、上述のように、2つのLSMであるアクティブLSMとスタンバイLSMとが各ノードで動作してもよい。動作中に、アクティブLSMはすべての受信メッセージ、特に「アライブ」メッセージと、任意のMRIメッセージが受信されるならこのようなMRIメッセージとをスタンバイLSMへ転送する。このようにして、アクティブLSMがクラッシュした場合に、スタンバイLSMが即座に引継ぎ、その結果、単に監視プロセスに障害が発生したからといってノードはダウンすることがない。
本発明の目的のために、監視プロセスは場合によっては処理部20と連動する監視部60によって実行されてもよい。
上記とは別に他の個別の実施形態が予見可能である。例えば、設定データとともに格納される代わりに、すべての動的データが動的に管理され、時々刻々と更新されてもよい。この動的データはMRI情報だけでなく、レプリカおよび通常は「アライブ」メッセージで送信されるノードに関する情報を含む。これは、リクエストに応答するプロセスで用いられるポートとは異なるポートにおけるマルチキャスト技術を用いて容易に実現されうる。
この点において、他のノードから受信されたすべての「アライブ」メッセージだけでなく、設定されたノードへ送信された「アライブ」メッセージは、マルチキャストにより送信されてもよく、特別な処理は必要ない。同様に、ノードの任意のLSMにより受信された、またはシステムマスタモニタのCSMにより送信されたMRIメッセージはマルチキャストにより受信または送信されてもよい。
MRIは2相コミットであるため、以下の特別な検討が必要になる。
‐LSMプロセスであり、MRI_ACKが送信されていないならば、CSMが接続を再開しうるため問題はない(いずれにせよ、ちょうど中間に発生する可能性は非常に低い)。マルチキャストによって何も送信されない。
‐LSMプロセスであり、MRI_ACKが送信されているならば、「確認待機中」を示すフラグを有するMRIをマルチキャストする(MRI_NACKについて、確認されないだろうために何も行われてはならない)。このように、スタンバイプロセスは確認を理解することができてもよい。
‐LSMプロセスであり、MRI_CONFIRMが受信されているならば、「確認済」としてのフラグを有するMRIをマルチキャストする。スタンバイプロセスは直近のものとしてMRIを解釈してもよい。
‐CSMプロセスであり、MRIがどのノードへも送信されていないならば、何もマルチキャストされてはならない(アクティブになるので、スタンバイプロセスは自身の現在のMRIが精密なものに一致しないことを検出してもよく、プロセスを開始してもよい。)
‐CSMプロセスであり、MRIが何れかのノードへ送信されているならば、「確認のペンダント」としてそれをマルチキャストする。スタンバイが制御を得るならば、すべてのLMとの接続を再開してもよく(すでに開いている接続はタイムアウトしてもよく、リモートSMプロセスは最初のMRI表示を無視してもよい)、MRIを再送する。
‐CSMプロセスであり、MRI_CONFIRMが何れかのノードへ送信されているならば、「確認中」というフラグを有するMRIをマルチキャストする。スタンバイが制御を得るならば、再び確認するためにすべてのLSMプロセスとの接続を再開してもよい(すでに確認されたものはこのメッセージを無視してもよい)。
‐CSMプロセスであり、MRI_CONFIRMがすべてのノードへ送信されているならば、「確認済」としてMRIをマルチキャストし、その結果、スタンバイはこれを新たなものとして解釈してもよいが、確認手順を開始しなくてもよい。
上述のように、MRIメッセージは、構文解析のための共通コードを用いるために、末端において「確認」状態についての追加のフラグをマルチキャストするために必要であってもよい。いずれにせよ、すべてのマルチキャストメッセージは、アクティブとスタンバイとの間の競合状態を解決するために、プロセスの重みを表す1バイトを最後の部分に含んでもよいだろう。
このセクションは、アクティブプロセスとスタンバイプロセスとがどのようにそれらの状態を検出しえるか、そしてこれらが何を行うことが想定されるかを説明する。プロセスが起動するときには常に、分散データベースシステム内の任意のマルチメディアメッセージを受信するためにリッスンを開始してもよい。何らかのマルチキャストが受信されると、スタンバイとして設定されてもよいし、受信した状態に従って何れかの内部データを更新してもよい(自身の選択された状態がアライブメッセージから受信されるので、状態マシンを処理しなくてもよい)。プロセスが起動後または以前のマルチキャスト受信パケットの後、DELAY_TIME期間内に何もマルチキャストメッセージを受信しないならば、「アライブ」メッセージまたはMRIメッセージについてリッスン(ポートのオープン)を開始してもよく、処理重み(これはノード内の任意のプロセスについて異なるだろう)とともに(最初の始動時に空であるだろう)自身の現在のMRIを送信してもよい。アクティブプロセスが自身のものよりも大きな重みを有するマルチキャストメッセージと空でないMRIとを受信したならば、以前のポートでのリッスンを停止してもよく、スタンバイへ低下してもよい(これは最初の競合状態を解消してもよく、これは通常動作の間に発生しないと想定される)。空のMRIを比較することの目的は、非常に速く再開される場合に制御を得るために、より大きな重みを有するプロセスを回避することである(いずれにせよ、再起動の後にDELAY_TIMEを待つことができ、それによってこれは、現在のアクティブプロセスが自身の「アライブ」メッセージを送信するのと同時、且つ隣接ノードも自身のマルチキャストされる「アライブ」メッセージを送信するのと同時に、それが起動しない限りこれは発生し得ないだろう)。
以下の表は本発明の実施形態に従う上記の分散データベースシステムのノード間で用いられるプロトコルの取りうる実装を説明する。
Figure 0005557840
本発明は、入出力部だけでなく処理部を有するコンピュータの内部メモリにロード可能なコンピュータプログラムで実施されてもよい。このコンピュータプログラムはこの目的のためにコンピュータで実行される場合に上述の方法のステップを実行するように適応された実行可能なコードを有する。特に、実行可能なノードはコンピュータにおいて読み取り可能な媒体手段に記録されてもよい。
本発明は例示であり非限定的であることが意図される様々な実施形態に関連して上述された。当業者がこれらの実施形態を変形してもよいことが期待される。本発明の範囲は明細書と図面に連動して特許請求の範囲により規定され、特許請求の範囲に含まれるすべての変形が本明細書に含まれることが意図される。

Claims (18)

  1. データの少なくとも1つのパーティションのレプリカを格納するように各ノードが構成された複数のノードを有する分散データベースシステムを扱う方法であって、
    格納されるデータをp個のパーティションに分割するステップ(S−005)と、
    各パーティションをr個のレプリカに複製するステップ(S−010)と、
    各パーティションについて、前記r個のレプリカを前記複数のノードの中から選択された対応するr個のノードに分配するステップ(S−015、S−020)と、
    相互にアドレスを指定するために使用可能である他のノードの識別子のリストを各ノードに設定するステップ(S−017、S−020)と、
    前記複数のノードの中から2つ以上のノードを起動するステップ(S−030、S−035、S−060、S−070)と、
    各アクティブノードにおいて、各レプリカの最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、各レプリカの接続状態とのうちから選択された少なくとも1つのイベントを監視するステップ(S−050、S−055、S−090、S−095)と、
    前記複数のノードの中のノードの起動又は停止の際に、前記アクティブノードの中から選択された少なくとも1つのノードにおいて、前記少なくとも1つのイベントに関する情報を各アクティブノードから収集し、各レプリカについての前記収集されたイベントに依存して前記アクティブノード内の各レプリカの優先順位を決めるためのルールを適用し、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、当該選択されたレプリカが現在のマスタレプリカであり、当該特定のノードが当該パーティションについての現在のマスタノードである、ステップと、
    前記分散データベースシステム内のデータの読み出し/書き込みを行うことの、ノードにおいて受信された(S−150;S−160)任意のリクエストについて、当該データが属するパーティション(11、12)と当該パーティションについての現在のマスタレプリカを担当する現在のマスタノード(2105)とを決定し、当該リクエストを当該現在のマスタノードへルーティングする(S−151、S−152、S−153;S−161)ステップと
    を有することを特徴とする方法。
  2. 各パーティションについて、前記r個のレプリカを対応するr個のノードに分配する前記ステップは、他の基準が同一のレプリカ優先度を生み出す場合に適用されるデフォルトレプリカ優先度を各レプリカに設定するステップを含むことを特徴とする請求項に記載の方法。
  3. 前記アクティブノードの中から選択された少なくとも1つのノードによって、パーティションについての所与のデフォルトレプリカ優先度が設定されていることに関する情報を少なくとも1つのアクティブノードから収集するステップと、
    前記アクティブノードの中から選択された少なくとも1つのノードによって、各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、当該選択されたレプリカが現在のマスタレプリカであ当該特定のノードが当該パーティションについての現在のマスタノードであるステップと
    を含むことを特徴とする請求項に記載の方法。
  4. 前記複数のノードの中のノードの起動又は停止の際に、前記アクティブノードが起動された順序を決定するステップをさらに有することを特徴とする請求項1に記載の方法。
  5. 最初に起動されたアクティブノードは、
    前記少なくとも1つのイベントに関する前記情報を各アクティブノードから収集するステップと、
    各レプリカについての前記収集されたイベントに依存して、前記アクティブノード内の各レプリカの優先順位を決めるための前記ルールを適用するステップと、
    各パーティションについて前記最高のレプリカ優先度を有する前記特定のノード内の前記レプリカを選択するステップであって、当該選択されたレプリカが現在のマスタレプリカであ当該特定のノードが当該パーティションについての現在のマスタノードであるステップと、
    各パーティションについて選択された現在のマスタレプリカと当該マスタレプリカを保持する現在のマスタノードとに関して他のアクティブノードへ通知するステップと
    の実行を担当するシステムマスタモニタであるとみなされることを特徴とする請求項に記載の方法。
  6. 最初に起動されたアクティブノードは、
    パーティションについての所与のデフォルトレプリカ優先度が設定されていることに関する情報を少なくとも1つのアクティブノードから収集するステップと、
    各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択するステップであって、当該選択されたレプリカが現在のマスタレプリカであ当該特定のノードが当該パーティションについての現在のマスタノードであるステップと、
    各パーティションについて選択された現在のマスタレプリカと当該現在のマスタレプリカを保持する現在のマスタノードとに関して他のアクティブノードへ通知するステップと
    の実行を担当するシステムマスタモニタであるとみなされることを特徴とする請求項に記載の方法。
  7. 各パーティションについて各アクティブノードにおいて前記現在のマスタレプリカの内容を、当該パーティションについての前記現在のマスタレプリカ(112、121、132、142)を担当する前記現在のマスタノード(105)からコピーするステップをさらに有することを特徴とする請求項1に記載の方法。
  8. 各アクティブノードにおいてコピーされた各レプリカについて、行われた前記最新の更新と、レプリカ状態と、前記レプリカを担当するローカルリソースの状態と、前記レプリカの接続状態とのうちの少なくとも1つを作成するステップをさらに有することを特徴とする請求項に記載の方法。
  9. 数のノード(1、2、3、4)を有する分散データベースシステムであって、
    格納されるデータは複数のパーティションに分割され、
    各パーティションは、前記複数のノードから選択された対応する数のノードに分散される複数のレプリカに複製され、
    前記複数のノードのうちの少なくとも1つのノードはアクティブであり、
    前記少なくとも1つのノードは、
    なくとも1つのパーティション(112、123、143)のレプリカ(2101)を格納するとともに、相互にアドレスを指定するために使用可能である他のノードの識別子(152)を格納するためのデータ記憶装置(15)と、
    前記分散データベースシステムの他のノード(1、3、4)と通信するとともに、前記分散データベースシステムにおける読み出し/書き込み動作を要求するクライアント(5)と通信するための入出力部(30)と、
    各レプリカの最新の更新(2103)と、レプリカ状態(212、223、243)と、各レプリカを担当するローカルリソースの状態と、各レプリカ(112、123、143)の接続状態(312、323、343)とのうちから選択された少なくとも1つのイベントを監視するための監視部(60)と、
    前記データ記憶装置、前記監視部及び前記入出力部と連携して、前記少なくとも1つのイベントに関する情報を前記分散データベースシステムの各アクティブノードから収集し、各レプリカについての前記収集されたイベントに依存して前記アクティブノード内の各レプリカの優先順位を決めるためのルールを適用し、各パーティションについて最高のレプリカ優先度を有する特定のノード内のレプリカを選択する動作であって、当該選択されたレプリカが現在のマスタレプリカであり、当該特定のノードが当該パーティションについての現在のマスタノードある、動作を実行し、前記分散データベースシステム内のデータの読み出し/書き込みを行うことの、受信された任意のリクエストについて、当該データが属するパーティションと当該パーティションについての現在のマスタレプリカを担当する現在のマスタノードとを決定し、当該リクエストを当該現在のマスタノードへルーティングするための制御部(20)と
    を含むことを特徴とする分散データベースシステム。
  10. 各ノードの前記データ記憶装置(15)は、他の基準が同一のレプリカ優先度を生み出す場合に適用されるデフォルトレプリカ優先度を示すようにレプリカごとに設定されたインジケータ(2102)を格納するように構成されることを特徴とする請求項に記載の分散データベースシステム。
  11. 各ノードの前記処理部(20)、前記監視部(60)、前記データ記憶装置(15)及び前記入力部(30)は、
    パーティションについての所与のデフォルトレプリカ優先度が設定されていることに関する情報を少なくとも1つのアクティブノードから収集し、
    各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択し、当該選択されたレプリカが現在のマスタレプリカであ当該特定のノードが当該パーティションについての現在のマスタノードであ
    うにさらに構成されることを特徴とする請求項10に記載の分散データベースシステム。
  12. 各ノードの前記処理部(20)、前記監視部(60)、前記データ記憶装置(15)及び前記入力部(30)は、前記分散データベースシステムの各アクティブノードから、前記アクティブノードが起動された順序を決定するための情報(1104、2104、3104、4104)を収集するように構成されることを特徴とする請求項に記載の分散データベースシステム。
  13. 最初に起動されたアクティブノードはシステムマスタモニタであるとみなされ、前記システムマスタモニタの前記処理部(20)、前記監視部(60)、前記データ記憶装置(15)及び前記入力部(30)は、
    前記少なくとも1つのイベントに関する前記情報を各アクティブノードから収集し、
    各レプリカについての前記収集されたイベントに依存して、前記アクティブノード内の各レプリカの優先順位を決めるための前記ルールを適用し、
    各パーティションについて前記最高のレプリカ優先度を有する前記特定のノード内の前記レプリカを選択し、当該選択されたレプリカが現在のマスタレプリカであ当該特定のノードが当該パーティションについての現在のマスタノード(2105、4105)であ
    各パーティションについて選択された現在のマスタレプリカと当該マスタレプリカを保持する現在のマスタノードとに関して他のアクティブノードへ通知する
    ように構成されることを特徴とする請求項12に記載の分散データベースシステム。
  14. 最初に起動されたアクティブノードはシステムマスタモニタであるとみなされ、前記システムマスタモニタの前記処理部(20)、前記監視部(60)、前記データ記憶装置(15)及び前記入力部(30)は、
    パーティションについての所与のデフォルトレプリカ優先度が設定されていることに関する情報を少なくとも1つのアクティブノードから収集し、
    各パーティションについて最高のデフォルトレプリカ優先度を有する特定のノード内のレプリカを選択し、当該選択されたレプリカが現在のマスタレプリカであ当該特定のノードが当該パーティションについての現在のマスタノード(2105、4105)であ
    各パーティションについて選択された現在のマスタレプリカと当該マスタレプリカを保持する現在のマスタノードとに関して他のアクティブノードへ通知する
    ようにさらに構成されることを特徴とする請求項12に記載の分散データベースシステム。
  15. 各ノードの前記処理部(20)、前記監視部(60)、前記データ記憶装置(15)及び前記入力部(30)は、各パーティションについて各アクティブノードにおいて前記現在のマスタレプリカの内容を、当該パーティションについての前記現在のマスタレプリカ(112、121、132、142)を担当する前記現在のマスタノード(2105、4105)からコピーするようにさらに構成されることを特徴とする請求項に記載の分散データベースシステム。
  16. 各ノードの前記処理部(20)、前記監視部(60)、前記データ記憶装置(15)及び前記入力部(30)は、各アクティブノードにおいてコピーされた各レプリカについて、行われた前記最新の更新と、レプリカ状態と、各レプリカを担当するローカルリソースの状態と、前記レプリカの接続状態とを作成するようにさらに構成されることを特徴とする請求項15に記載の分散データベースシステム。
  17. 入出力部と処理部とを有するコンピュータの内部メモリにロード可能なコンピュータプログラムであって、前記コンピュータで動作する場合に請求項1乃至の何れか1項に記載の方法を実行するように構成された実行可能なコードを含むことを特徴とするコンピュータプログラム。
  18. コンピュータにおいて読み出し可能であり、請求項17に記載のコンピュータプログラムを含む記録媒体。
JP2011529547A 2008-10-03 2009-09-30 分散データベースの監視メカニズム Active JP5557840B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10240808P 2008-10-03 2008-10-03
US61/102,408 2008-10-03
PCT/EP2009/062714 WO2010037794A2 (en) 2008-10-03 2009-09-30 Monitoring mechanism for a distributed database

Publications (3)

Publication Number Publication Date
JP2012504807A JP2012504807A (ja) 2012-02-23
JP2012504807A5 JP2012504807A5 (ja) 2012-10-18
JP5557840B2 true JP5557840B2 (ja) 2014-07-23

Family

ID=41203944

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011529547A Active JP5557840B2 (ja) 2008-10-03 2009-09-30 分散データベースの監視メカニズム

Country Status (4)

Country Link
US (1) US8375001B2 (ja)
EP (1) EP2350876A2 (ja)
JP (1) JP5557840B2 (ja)
WO (1) WO2010037794A2 (ja)

Families Citing this family (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7675854B2 (en) 2006-02-21 2010-03-09 A10 Networks, Inc. System and method for an adaptive TCP SYN cookie with time validation
US8312507B2 (en) 2006-10-17 2012-11-13 A10 Networks, Inc. System and method to apply network traffic policy to an application session
US8443062B2 (en) * 2008-10-23 2013-05-14 Microsoft Corporation Quorum based transactionally consistent membership management in distributed storage systems
US8332365B2 (en) 2009-03-31 2012-12-11 Amazon Technologies, Inc. Cloning and recovery of data volumes
US8582450B1 (en) * 2009-09-30 2013-11-12 Shoretel, Inc. Status reporting system
US9960967B2 (en) 2009-10-21 2018-05-01 A10 Networks, Inc. Determining an application delivery server based on geo-location information
EP2712149B1 (en) * 2010-04-23 2019-10-30 Compuverde AB Distributed data storage
EP2439908A1 (en) * 2010-09-20 2012-04-11 Thomson Licensing Method of data replication in a distributed data storage system and corresponding device
US9215275B2 (en) 2010-09-30 2015-12-15 A10 Networks, Inc. System and method to balance servers based on server load status
US8326801B2 (en) * 2010-11-17 2012-12-04 Microsoft Corporation Increasing database availability during fault recovery
US9609052B2 (en) 2010-12-02 2017-03-28 A10 Networks, Inc. Distributing application traffic to servers based on dynamic service response time
US8897154B2 (en) 2011-10-24 2014-11-25 A10 Networks, Inc. Combining stateless and stateful server load balancing
US9094364B2 (en) 2011-12-23 2015-07-28 A10 Networks, Inc. Methods to manage services over a service gateway
US10860563B2 (en) 2012-01-06 2020-12-08 Microsoft Technology Licensing, Llc Distributed database with modular blocks and associated log files
US9753999B2 (en) 2012-01-06 2017-09-05 Citus Data Bilgi Islemieri Ticaret A.S. Distributed database with mappings between append-only files and repartitioned files
US20130311421A1 (en) * 2012-01-06 2013-11-21 Citus Data Bilgi Islemleri Ticaret A.S. Logical Representation of Distributed Database Table Updates in an Append-Only Log File
US10706021B2 (en) * 2012-01-17 2020-07-07 Oracle International Corporation System and method for supporting persistence partition discovery in a distributed data grid
US10044582B2 (en) 2012-01-28 2018-08-07 A10 Networks, Inc. Generating secure name records
US8965921B2 (en) * 2012-06-06 2015-02-24 Rackspace Us, Inc. Data management and indexing across a distributed database
US10002141B2 (en) * 2012-09-25 2018-06-19 A10 Networks, Inc. Distributed database in software driven networks
US9843484B2 (en) 2012-09-25 2017-12-12 A10 Networks, Inc. Graceful scaling in software driven networks
KR101692751B1 (ko) 2012-09-25 2017-01-04 에이10 네트워크스, 인코포레이티드 데이터망 부하 분산
US10021174B2 (en) 2012-09-25 2018-07-10 A10 Networks, Inc. Distributing service sessions
US9239741B2 (en) * 2012-10-16 2016-01-19 Futurewei Technologies, Inc. System and method for flexible distributed massively parallel processing (MPP)
US9053166B2 (en) 2012-12-10 2015-06-09 Microsoft Technology Licensing, Llc Dynamically varying the number of database replicas
US9824132B2 (en) * 2013-01-08 2017-11-21 Facebook, Inc. Data recovery in multi-leader distributed systems
US9531846B2 (en) 2013-01-23 2016-12-27 A10 Networks, Inc. Reducing buffer usage for TCP proxy session based on delayed acknowledgement
US9900252B2 (en) 2013-03-08 2018-02-20 A10 Networks, Inc. Application delivery controller and global server load balancer
US9378068B2 (en) 2013-03-13 2016-06-28 International Business Machines Corporation Load balancing for a virtual networking system
US9438670B2 (en) 2013-03-13 2016-09-06 International Business Machines Corporation Data replication for a virtual networking system
US11030055B2 (en) * 2013-03-15 2021-06-08 Amazon Technologies, Inc. Fast crash recovery for distributed database systems
WO2014144837A1 (en) 2013-03-15 2014-09-18 A10 Networks, Inc. Processing data packets using a policy based network path
JP6028641B2 (ja) * 2013-03-21 2016-11-16 富士通株式会社 情報処理システム、情報処理装置の制御プログラム及び情報処理システムの制御方法
US10038693B2 (en) 2013-05-03 2018-07-31 A10 Networks, Inc. Facilitating secure network traffic by an application delivery controller
US9489443B1 (en) * 2013-05-24 2016-11-08 Amazon Technologies, Inc. Scheduling of splits and moves of database partitions
US9548940B2 (en) 2013-06-09 2017-01-17 Apple Inc. Master election among resource managers
US9053167B1 (en) 2013-06-19 2015-06-09 Amazon Technologies, Inc. Storage device selection for database partition replicas
CN104283906B (zh) * 2013-07-02 2018-06-19 华为技术有限公司 分布式存储***、集群节点及其区间管理方法
US9569513B1 (en) 2013-09-10 2017-02-14 Amazon Technologies, Inc. Conditional master election in distributed databases
US9507843B1 (en) * 2013-09-20 2016-11-29 Amazon Technologies, Inc. Efficient replication of distributed storage changes for read-only nodes of a distributed database
US9633051B1 (en) * 2013-09-20 2017-04-25 Amazon Technologies, Inc. Backup of partitioned database tables
US9430545B2 (en) 2013-10-21 2016-08-30 International Business Machines Corporation Mechanism for communication in a distributed database
US9794135B2 (en) 2013-11-11 2017-10-17 Amazon Technologies, Inc. Managed service for acquisition, storage and consumption of large-scale data streams
US10230770B2 (en) 2013-12-02 2019-03-12 A10 Networks, Inc. Network proxy layer for policy-based application proxies
US9639589B1 (en) 2013-12-20 2017-05-02 Amazon Technologies, Inc. Chained replication techniques for large-scale data streams
US9942152B2 (en) 2014-03-25 2018-04-10 A10 Networks, Inc. Forwarding data packets using a service-based forwarding policy
US10372685B2 (en) 2014-03-31 2019-08-06 Amazon Technologies, Inc. Scalable file storage service
US9519510B2 (en) * 2014-03-31 2016-12-13 Amazon Technologies, Inc. Atomic writes for multiple-extent operations
US9942162B2 (en) 2014-03-31 2018-04-10 A10 Networks, Inc. Active application response delay time
US10264071B2 (en) 2014-03-31 2019-04-16 Amazon Technologies, Inc. Session management in distributed storage systems
US9785510B1 (en) 2014-05-09 2017-10-10 Amazon Technologies, Inc. Variable data replication for storage implementing data backup
US9906422B2 (en) 2014-05-16 2018-02-27 A10 Networks, Inc. Distributed system to determine a server's health
US9986061B2 (en) 2014-06-03 2018-05-29 A10 Networks, Inc. Programming a data network device using user defined scripts
US9992229B2 (en) 2014-06-03 2018-06-05 A10 Networks, Inc. Programming a data network device using user defined scripts with licenses
US10129122B2 (en) 2014-06-03 2018-11-13 A10 Networks, Inc. User defined objects for network devices
US9613078B2 (en) 2014-06-26 2017-04-04 Amazon Technologies, Inc. Multi-database log with multi-item transaction support
US9734021B1 (en) 2014-08-18 2017-08-15 Amazon Technologies, Inc. Visualizing restoration operation granularity for a database
CN104615660A (zh) * 2015-01-05 2015-05-13 浪潮(北京)电子信息产业有限公司 一种监控数据库性能的方法和***
US9904722B1 (en) 2015-03-13 2018-02-27 Amazon Technologies, Inc. Log-based distributed transaction management
WO2017004547A1 (en) 2015-07-02 2017-01-05 Google Inc. Distributed storage system with replica location selection
US10581976B2 (en) 2015-08-12 2020-03-03 A10 Networks, Inc. Transmission control of protocol state exchange for dynamic stateful service insertion
US10243791B2 (en) 2015-08-13 2019-03-26 A10 Networks, Inc. Automated adjustment of subscriber policies
US10031935B1 (en) * 2015-08-21 2018-07-24 Amazon Technologies, Inc. Customer-requested partitioning of journal-based storage systems
US10608956B2 (en) * 2015-12-17 2020-03-31 Intel Corporation Adaptive fabric multicast schemes
US10853182B1 (en) 2015-12-21 2020-12-01 Amazon Technologies, Inc. Scalable log-based secondary indexes for non-relational databases
US10567500B1 (en) 2015-12-21 2020-02-18 Amazon Technologies, Inc. Continuous backup of data in a distributed data store
US10423493B1 (en) 2015-12-21 2019-09-24 Amazon Technologies, Inc. Scalable log-based continuous data protection for distributed databases
US10754844B1 (en) 2017-09-27 2020-08-25 Amazon Technologies, Inc. Efficient database snapshot generation
US10990581B1 (en) 2017-09-27 2021-04-27 Amazon Technologies, Inc. Tracking a size of a database change log
US11182372B1 (en) 2017-11-08 2021-11-23 Amazon Technologies, Inc. Tracking database partition change log dependencies
US11042503B1 (en) 2017-11-22 2021-06-22 Amazon Technologies, Inc. Continuous data protection and restoration
US11269731B1 (en) 2017-11-22 2022-03-08 Amazon Technologies, Inc. Continuous data protection
US10922310B2 (en) * 2018-01-31 2021-02-16 Red Hat, Inc. Managing data retrieval in a data grid
US10621049B1 (en) 2018-03-12 2020-04-14 Amazon Technologies, Inc. Consistent backups based on local node clock
US11126505B1 (en) 2018-08-10 2021-09-21 Amazon Technologies, Inc. Past-state backup generator and interface for database systems
CN110928943B (zh) * 2018-08-29 2023-06-20 阿里云计算有限公司 一种分布式数据库及数据写入方法
CN110874382B (zh) * 2018-08-29 2023-07-04 阿里云计算有限公司 一种数据写入方法、装置及其设备
US11042454B1 (en) 2018-11-20 2021-06-22 Amazon Technologies, Inc. Restoration of a data source
CN109933289B (zh) * 2019-03-15 2022-06-10 深圳市网心科技有限公司 一种存储副本部署方法、***及电子设备和存储介质
US11816073B1 (en) * 2020-05-08 2023-11-14 Amazon Technologies, Inc. Asynchronously forwarding database commands
US12007954B1 (en) 2020-05-08 2024-06-11 Amazon Technologies, Inc. Selective forwarding for multi-statement database transactions
KR102382189B1 (ko) * 2020-07-30 2022-04-05 주식회사 엘지유플러스 다중화 액티브 데이터베이스의 리플리케이션 갭 감지 방법 및 장치
WO2022031258A1 (en) 2020-08-03 2022-02-10 Hitachi Vantara Llc Randomization of heartbeat communications among multiple partition groups
US11494356B2 (en) 2020-09-23 2022-11-08 Salesforce.Com, Inc. Key permission distribution

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5440727A (en) * 1991-12-18 1995-08-08 International Business Machines Corporation Asynchronous replica management in shared nothing architectures
US5608903A (en) 1994-12-15 1997-03-04 Novell, Inc. Method and apparatus for moving subtrees in a distributed network directory
US6539381B1 (en) 1999-04-21 2003-03-25 Novell, Inc. System and method for synchronizing database information
US6574750B1 (en) 2000-01-06 2003-06-03 Oracle Corporation Preserving consistency of passively-replicated non-deterministic objects
US20080052327A1 (en) 2006-08-28 2008-02-28 International Business Machines Corporation Secondary Backup Replication Technique for Clusters
US7788233B1 (en) * 2007-07-05 2010-08-31 Amazon Technologies, Inc. Data store replication for entity based partition

Also Published As

Publication number Publication date
WO2010037794A2 (en) 2010-04-08
JP2012504807A (ja) 2012-02-23
EP2350876A2 (en) 2011-08-03
US8375001B2 (en) 2013-02-12
US20110178985A1 (en) 2011-07-21
WO2010037794A3 (en) 2010-06-24

Similar Documents

Publication Publication Date Title
JP5557840B2 (ja) 分散データベースの監視メカニズム
EP2347563B1 (en) Distributed master election
CN109729111B (zh) 用于管理分布式***的方法、设备和计算机程序产品
CN111565229B (zh) 一种基于Redis的通信***分布式方法
CN111615066B (zh) 一种基于广播的分布式微服务注册及调用方法
US6330605B1 (en) Proxy cache cluster
JP5498594B2 (ja) フェデレーションインフラストラクチャ内の一貫性
JP4680919B2 (ja) ネットワークノードクラスタのための冗長なルーティング機能
US9185054B2 (en) System and method for providing zero buffer copying in a middleware machine environment
US20120066394A1 (en) System and method for supporting lazy deserialization of session information in a server cluster
CN104205756A (zh) 并发进程执行
CN105493474A (zh) 用于支持用于同步分布式数据网格中的数据的分区级别日志的***及方法
JP2007524325A (ja) 投票を活用した無停止サービスシステム及びそのシステムにおける情報更新及び提供方法
CN111756780B (zh) 一种同步连接信息的方法和负载均衡***
CN113055461B (zh) 一种基于ZooKeeper的无人集群分布式协同指挥控制方法
EP2616967B1 (en) System including a middleware machine environment
US9015518B1 (en) Method for hierarchical cluster voting in a cluster spreading more than one site
KR20110063083A (ko) 해시를 이용한 게시-구독 네트워크 구성 방법 및 통신 지원 방법
JP2024514467A (ja) 地理的に分散されたハイブリッドクラウドクラスタ
Gäbler et al. Moversight: A group communication protocol for mobile collaborative applications
Gäbler et al. Moversight: a group communication protocol for mobile scenarios
CN112800289A (zh) 元数据查询方法及***
KR101491452B1 (ko) 메시징 채널을 이용한 데이터 복제 방법 및 장치
JP5617628B2 (ja) サーバ所在地追跡装置、方法、およびプログラム
CN114466007A (zh) 一种sdn控制器协议能力统一调度方法及装置

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120830

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120830

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140214

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140526

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140603

R150 Certificate of patent or registration of utility model

Ref document number: 5557840

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250