WO2023148977A1

WO2023148977A1 - ノード装置、クラスタ管理方法、プログラム及びクラスタシステム

Info

Publication number: WO2023148977A1
Application number: PCT/JP2022/004715
Authority: WO
Inventors: 雄大朝井
Original assignee: 株式会社Pfu
Priority date: 2022-02-07
Filing date: 2022-02-07
Publication date: 2023-08-10

Abstract

クラスタを再構成するグループに属さないノードにおいてもデータベースのサービスを提供しつつ、当該クラスタにおけるデータの整合性を図ることを可能とする。　マルチマスタ構成のクラスタを構成する複数のノード装置のうちのノード装置に、当該クラスタが複数のグループに分割された際に、自ノード装置を含む自グループが、当該クラスタを再構成するグループに決定されなかった場合であっても、自ノード装置のデータベースのサービスを提供するサービス提供部と、自グループが当該クラスタを再構成するグループではなく、自ノード装置が当該クラスタに再度参加可能な状態である場合、自ノード装置のデータベースを、当該クラスタを再構成するグループに属する他のノード装置のデータベースに同期させる同期部とを備えた。

Description

ノード装置、クラスタ管理方法、プログラム及びクラスタシステム

　本開示は、クラスタを管理するための技術に関する。

　従来、第一のサーバは通信断絶中に自サーバで更新された差分データを第二のサーバに送信し、第二のサーバは受信した差分データと通信断絶中に自サーバで更新された差分データとをマージして、第一のサーバに送信する送信データと自サーバに反映させる反映データとを作成し、第二のサーバは送信データを第一のサーバに送信し、反映データを自サーバに反映させ、第一のサーバは送信データを自サーバに反映させ、第一のサーバは復旧処理中に自サーバで更新された差分データを第二のサーバに送信し、読み出した差分データが自サーバ反映ずみデータのアップデートを含んでいる場合はアップデート分を自サーバに反映させる方法が提案されている（特許文献１を参照）。

　また、プライマリサイトを含むデータベースシステムにおける方法であって、プライマリデータベースが利用不能であると検出し、プライマリサイトのスタンバイデータベースが利用可能であると決定したとき、フェイルオーバ処理シーケンスを自動的にし、フェイルオーバ処理シーケンスは、スタンバイデータベースを読み取り可能及び書き込み可能として自動的に有効にし、スタンバイデータベースに、他のスタンバイデータベースへのデータの複製を開始するようプライマリサイトにおけるプライマリデータベースのロールを割り当て、フェイルオーバロール移行の後、アプリケーションサーバとスタンバイデータベースとの間の予め確立された接続を使用して、アプリケーションサーバがスタンバイデータベースからデータを読み取り且つスタンバイデータベースにデータを書き込むことを可能にし、スタンバイデータベースがプライマリサイトにおけるプライマリデータベースのロールを引き受けることを結果としてもたらす方法が提案されている（特許文献２を参照）。

特開２００６－１４６２９９号公報特表２０２０－５１１７０８号公報

　マルチマスタ構成のクラスタにおいてノード間を接続するネットワークの一部が遮断される等の障害が発生した場合に、そのまま動作を継続してしまうと、分離された各ノードグループ（サブクラスタ）に対して別々の書き込み（更新）動作が実行されるため、クラスタ内のデータの一貫性（整合性）が失われてしまうおそれがある。

　そのため、従来、マルチマスタ構成のクラスタでは、ネットワーク遮断などの障害が発生し、クラスタが複数のノードグループに分割された場合は、当該複数のノードグループから、当該クラスタを再構成するグループと、当該クラスタを再構成しないグループが決定され、当該クラスタを再構成するグループでは動作継続が可能である一方、当該クラスタを再構成しないグループでは動作継続が不可となる。

　上述した従来の方法では、クラスタ（システム）全体としてデータの一貫性が保たれる一方、クラスタを再構成しないグループに属するノードのデータベースを利用することが困難となる。しかし、利用形態によっては、クラスタを再構成しないグループにおいても、データベースのサービスが提供されることが望ましい場合もある。しかし、クラスタを再構成しないグループにおいてもデータベースのサービスを提供すると、クラスタ内のデータに不整合が生じる等の問題がある。

　本開示は、上記した問題に鑑み、クラスタを再構成するグループに属さないノードにおいてもデータベースのサービスを提供しつつ、当該クラスタにおけるデータの整合性を図ることを課題とする。

　本開示の一例は、マルチマスタ構成のクラスタを構成する複数のノード装置のうちのノード装置であって、前記クラスタが複数のグループに分割された際に、自ノード装置を含む自グループが、前記クラスタを再構成するグループに決定されなかった場合であっても、自ノード装置のデータベースのサービスを提供するサービス提供手段と、前記自グループが前記クラスタを再構成するグループではなく、自ノード装置が前記クラスタに再度参加可能な状態である場合、自ノード装置のデータベースを、前記クラスタを再構成するグループに属する他のノード装置のデータベースに同期させる同期手段と、を備えるノード装置である。

　本開示は、情報処理装置、システム、コンピュータによって実行される方法またはコンピュータに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。

　本開示によれば、クラスタを再構成するグループに属さないノードにおいてもデータベースのサービスを提供しつつ、当該クラスタにおけるデータの整合性を図ることが可能となる。

第一の実施形態に係るマルチマスタ構成のクラスタを備えるクラスタシステムの構成を示す概略図である。第一の実施形態に係るノードの機能構成の概略を示す図である。第一の実施形態に係る管理情報テーブル（平時）の一例を示す図である。第一の実施形態に係るＧｒｉｄクォーラムシステムの一例を示す図である。第一の実施形態に係る有限射影平面クォーラムの一例を示す図である。第一の実施形態に係る管理情報テーブル（拠点間障害発生直後）の一例を示す図である。第一の実施形態に係る管理情報テーブル（ノード障害発生直後）の一例を示す図である。第一の実施形態に係る管理情報テーブル（評価値更新後）の一例を示す図である。第一の実施形態に係る評価値更新処理（平時フロー）の流れの概要を示すフローチャートである。第一の実施形態に係るグループ決定処理（障害発生時フロー）の流れの概要を示すフローチャートである。第一の実施形態に係る同期処理（障害復旧時フロー）の流れの概要を示すフローチャートである。第二の実施形態に係るマルチマスタ構成のクラスタを備えるクラスタシステムの構成を示す概略図である。第二の実施形態に係るノードの機能構成の概略を示す図である。第二の実施形態に係るデータベースの状態（平時）の一例を示す図である。第二の実施形態に係るデータベースの状態（障害発生後）の一例を示す図である。第二の実施形態に係るデータベースの状態（障害復旧時（リストア時））の一例を示す図である。第二の実施形態に係るデータベースの状態（障害復旧時（同期時））の一例を示す図である。第二の実施形態に係るバックアップ処理（平時フロー）の流れの概要を示すフローチャートである。第二の実施形態に係るバックアップ無効化処理（障害発生時フロー）の流れの概要を示すフローチャートである。第二の実施形態に係る同期処理（障害復旧時フロー）の流れの概要を示すフローチャートである。第三の実施形態に係るノードの機能構成の概略を示す図である。

　以下、本開示に係る装置、システム、方法及びプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る装置、システム、方法及びプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

　第一の実施形態、第二の実施形態及び第三の実施形態では、本開示に係る装置、システム、方法及びプログラムを、二拠点に配置されたノード群から構成されたマルチマスタ構成のクラスタにおいて実施した場合の実施の形態について説明する。但し、本開示に係る装置、システム、方法及びプログラムは、マルチマスタ構成のクラスタを再構成及び管理するための技術について広く用いることが可能であり、本開示の適用対象は、実施形態において示した例に限定されない。

　［第一の実施形態］
　第一の実施形態では、障害発生等によりマルチマスタ構成のクラスタが複数のノードグループに分割された場合に、当該クラスタを構成する各ノードにおいて、平時に取得された使用情報を用いることにより、自ノードを含むグループを、当該クラスタを再構成するグループとするかを決定する実施形態について説明する。

　＜システムの構成＞
　図１は、本実施形態に係るマルチマスタ構成のクラスタを備えるクラスタシステムの構成を示す概略図である。本実施形態に係るクラスタシステム９では、マルチマスタ構成のクラスタ３を構成する複数のノード装置（以下、「ノード」と称する）１が、ネットワークを介して互いに通信可能に接続されている。本実施形態に係るクラスタシステム９では、拠点１にノード１ａ（以下、「ノードＡ」と称する）及びノード１ｂ（以下、「ノードＢ」と称する）が配置され、拠点２にノード１ｃ（以下、「ノードＣ」と称する）及びノード１ｄ（以下、「ノードＤ」と称する）が配置されている。

　各ノード１は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１３、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ　Ｅｒａｓａｂｌｅ　ａｎｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）等の記憶装置１４、及びＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）等の通信ユニット１５を備えるコンピュータである。但し、ノード１の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、ノード１は、単一の筐体からなる装置に限定されない。ノード１は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。そのため、例えば、ノード１は、複数の筐体からなるノード装置であり、以下で詳述する機能部と同期対象のデータベースとは、別筐体に備えられていてもよい。

　ノードは、マルチマスタ構成のクラスタ３を構成するコンピューター（情報処理装置）やサーバーであり、本実施形態では、各ノード１は夫々、個別のデータベースを備える（管理する）。即ち、本実施形態に係るクラスタ３は、マルチマスタ構成のデータベースクラスタである。マルチマスタ構成のクラスタでは、当該クラスタを構成する複数のノード夫々のデータベースに対して、データ参照だけでなく更新（書き込み）が可能であり、データベースを更新した結果がノード間で相互に同期されることで、データの一貫性（整合性）が保たれる。そして、マルチマスタ構成のクラスタでは、障害が発生した際に、例えば、障害が発生したノードを切り離す（取り除く）ことで、データベースのサービスを継続することが可能である。なお、本実施形態においてノード間での同期の対象となるデータベースは、例えば、リレーショナルデータベース（関係データベース）であるが、キー・バリュー型データベース等の他の任意のデータベースであってよい。また、各ノードにおいて、データベースは、記憶装置１４に構築（記憶）されてもよいし、その他の記憶装置に構築されてもよい。

　また、本実施形態に係るクラスタシステム９では、ユーザー端末８が接続されており、ノード１は、ユーザー端末８から送信された、データベースに対する読み込み動作や書き込み動作等の処理要求（クエリ）を受け付け実行することが可能である。なお、ユーザー端末８は、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶装置及び通信ユニット等を備えるコンピュータである。但し、ユーザー端末８の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。

　なお、本開示に係るクラスタシステム９は、図１に例示された構成のクラスタシステム９に限定されない。例えば、一拠点のみに複数のノード１が配置されたクラスタシステムや、二拠点以上の拠点に複数ノード１が配置されたクラスタシステムであってもよい。また、各拠点に配置されるノードの数は複数に限定されず、拠点に１ノードのみが配置される構成であってもよい。何れにしても、本実施形態に係るクラスタシステム９（クラスタ３）は、二以上のノードを備える。

　図２は、本実施形態に係るノードの機能構成の概略を示す図である。各ノード１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、ノード１に備えられた各ハードウェアが制御されることで、管理情報記憶部２１、使用情報取得部２２、使用情報送信部２３、評価値算出部２４、状態検知部２５、決定部２６、障害検知部２７、設定部２８、サービス提供部２９、再接続部３０、更新情報送受信部３１、更新データ特定部３２、更新データ送受信部３３及び同期部３４を備える装置として機能する。なお、本実施形態及び後述する他の実施形態では、ノード１の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。また、ノード１が備える各機能部は、単一の筐体からなる装置（１の装置）に実装されるものに限定されず、遠隔に及び／又は分散して（例えば、クラウド上に）実装されてもよい。

　管理情報記憶部２１は、自ノード及び自ノードが属するクラスタに関する管理情報を記憶する。管理情報は、自ノードの使用状況に関する情報と、自ノードと通信可能なノードと自ノードとで構成されるグループ（クラスタ）に関する情報等を含む。以下、「自ノードと通信可能なノードと、自ノードとで構成されるグループ（クラスタ）」を「自グループ（自クラスタ）」と称する。なお、本実施形態では、管理情報は管理情報テーブルに格納され、管理情報（管理情報テーブル）は、記憶装置１４や他の記憶装置等に記憶される。

　図３は、本実施形態に係る管理情報テーブル（平時）の一例を示す図である。図３に示すように、本実施形態に係る管理情報テーブルには、管理情報として、「クラスタノード」、「状態」、「トランザクション数（Ｔｘカウント）」、「評価値」、及び「評価値合計」の情報が格納される。「クラスタノード」の欄には、自グループ（自クラスタ）の構成ノードの情報（例えば、ノード名やノードＩＤ）が格納される。「状態」の欄には、自グループ（自クラスタ）が、クラスタ３として動作するクラスタ（クラスタ３としてデータベースのサービスの提供が可能なクラスタ）であるプライマリクラスタと、クラスタ３として動作しないクラスタであるノンプライマリクラスタの何れであるか（自グループの状態）を示す情報（例えば、「ＰＲＩＭＡＲＹ」又は「ＮＯＮ－ＰＲＩＭＡＲＹ」）が格納される。「Ｔｘカウント」の欄には、自ノードの使用状況を示す情報である使用情報（自ノードのトランザクション数等）が格納される。「評価値」の欄には、後述する重み付け多数決投票に用いられる重み（重要度）である、自ノードの評価値が格納される。「評価値合計」の欄には、プライマリクラスタの構成ノードの評価値の総和が格納される。但し、自グループがノンプライマリクラスタに属した時点で、自ノードが属してない現在のプライマリクラスタの構成ノードの評価値の総和ではなく、自ノードが最後に属していたプライマリクラスタの構成ノードの評価値の総和が、「評価値合計」に保持される。

　図３の例では、障害等が発生しておらず、クラスタ３が分割されていない状態（平時の状態）であり、クラスタ３を構成する各ノードが通信可能な状態であるため、各ノードはプライマリクラスタに属している状態である。そのため、図３に示すように、各ノードが備える管理情報テーブルには、「クラスタノード」の欄に「（ノード）Ａ、Ｂ、Ｃ、Ｄ」が、「状態」の欄に「ＰＲＩＭＡＲＹ」が、「評価値合計」の欄にノードＡ、Ｂ、Ｃ、Ｄの評価値の総和「６３６」が格納されている。なお、「Ｔｘカウント」及び「評価値」については、詳細を後述する。また、図３に示された管理情報は一例であり、管理情報は、図３に示された情報以外の情報を含んでもよい。更に、図３に示された管理情報テーブルは一例であり、管理情報を格納することが可能であれば他の形式であってもよい。また、管理情報を格納する管理情報テーブルは、図３に示すような一つのテーブルに限定されず、複数のテーブルにより構成されてもよい。

　使用情報取得部２２は、所定期間毎に、クラスタ３を構成する各ノード１（自ノードを含む）について、ノードの使用状況（負荷状況）を示す使用情報を取得する。本実施形態では、ノードの使用状況を示す使用情報として、当該ノードに対するアクセスの頻度を示す情報の一例である、当該ノードのトランザクション数（読み込み動作（ｒｅａｄ）及び／又は書き込み動作（ｗｒｉｔｅ）に係るトランザクションの数）を例示する。但し、使用情報取得部２２により取得される使用情報は、ノードの使用状況を示す情報であればトランザクション数に限定されるものではなく、アクセスの頻度を示す情報の他の例であるパケット伝送数の他、ハードウェア負荷指標、ＣＰＵ使用率、又はメモリ使用率等であってもよい。また、取得される使用情報は、一種類の情報に限定されるものではなく、ノードの使用状況を示す複数種類の情報を含んでもよい。例えば、使用情報は、トランザクション数及びパケット伝送数であってよい。

　本実施形態では、所定期間毎に、その時点（使用情報を取得する時刻）近傍における各ノードの使用状況を示す情報が取得される。使用情報を取得する時刻近傍におけるノードの使用状況とは、例えば、使用情報を取得する時点以前一定期間の使用状況であるが、その他、使用情報を取得する時刻における使用状況を示す情報（瞬間値）であってもよい。本実施形態では、使用情報取得部２２は、各ノードについて、所定期間毎に、その時点以前一定期間のノードの使用状況を示す情報を取得する。本実施形態では、各ノードについて、所定期間（例えば、１時間）毎に、その時点以前一定期間（例えば、３時間）のトランザクション数の合計値が算出（取得）される。本実施形態において、所定期間が経過する毎に一定期間のトランザクション数の合計値を算出（取得）する方法を以下で説明する。なお、以下の説明では、所定期間を１時間、一定期間を３時間とし、ノードＡの使用情報取得部２２が、クラスタ３を構成する各ノード（ノードＡ、Ｂ、Ｃ、Ｄ）のトランザクション数を取得する場合について例示する。また、以下に示す例では、所定期間毎に、その時点での、ある時点（始点）からのトランザクション数の累計値（ノード毎の累計値）が、ノード間で送受信されることとする。以下、始点からのノードのトランザクション数の累計値を、単に「累計値」と称する。

　まず、ノードＡの使用情報取得部２２は、予め、少なくとも一定期間（３時間）を超える期間において、所定期間（１時間）毎に、その時点での各ノードについての累計値を取得しておく。例えば、１２時から１時間おきに、３時間分のトランザクション数を取得したい場合、１２時の時点においても、その時点以前３時間分のトランザクション数の合計値を取得可能とするために、９時、１０時、１１時の時点での各ノードの累計値を取得しておく。例えば、ノードＡは、ノードＢの累計値として、９時に「１００」、１０時に「２００」、１１時に「３００」を取得しておく。そして、ノードＡは、１２時にノードＢの累計値「５００」を取得すると、その時点以前３時間分（９時～１２時）のノードＢのトランザクション数を、１２時の累計値「５００」と９時の累計値「１００」との差分である「４００」と算出することが可能である。その後、ノードＡは、１３時にノードＢの累計値「７００」を取得すると、その時点以前３時間分（１０時～１３時）のノードＢのトランザクション数を、１３時の累計値「７００」と１０時の累計値「２００」との差分である「５００」と算出することが可能である。後述する評価値算出部２４では、この算出された一定期間のトランザクション数の合計値に基づき評価値が算出される。

　また、使用情報取得部２２は、自ノードについて、一定期間のトランザクション数の合計値を算出する毎に、当該自ノードの一定期間のトランザクション数の合計値で、管理情報テーブル内の「Ｔｘカウント」の情報を更新する。なお、本実施形態では、一定期間のトランザクション数の合計値に基づき評価値が算出されるが、評価値の算出に用いられる一定期間のトランザクション数は、一定期間の合計値に限定されず、一定期間のトランザクション数の平均値（移動平均値）や中央値（移動中央値）、最大値、最小値、最頻値等の代表値であってもよい。例えば、３時間分のトランザクション数ではなく、３時間のうちの各１時間のトランザクション数の平均値等が評価値の算出に用いられてよい。また、上述の例では、１３時の時点で算出される評価値は、１３時の時点で算出された一定期間のトランザクション数（例えば、上述した合計値「５００」）にのみ基づき算出される以外にも、１３時の時点の一定期間のトランザクション数「５００」に加え、その前に算出（取得）されたトランザクション数（例えば、上述した、１２時の時点の合計値「４００」）に基づき算出されてもよい。また、評価値の算出に用いられる使用情報は、使用情報を取得する時刻における使用状況を示す情報（瞬間値）であってもよい。

　なお、本実施形態では、使用情報取得部２２は、各ノードについての累積値を、対応するノードから取得し、自ノードにおいて各ノード（ノードＡ、Ｂ、Ｃ、Ｄ）の一定期間のトランザクション数を算出することとしたが、各ノードの一定期間のトランザクション数を取得する方法はこの例に限定されない。例えば、各ノードが、所定期間毎に、自身の一定期間のトランザクション数を算出し、算出された結果をノード間で送り合うようにしてもよい。この場合、使用情報取得部２２は、各ノードの一定期間のトランザクション数を、対応するノードから取得する（例えば、ノードＢの一定期間のトランザクション数の合計値をノードＢから取得する）ことが可能である。

　以上の通り、各ノードの使用情報取得部２２が、所定の期間が経過する毎（定期的）に、自ノード及び他ノードの使用情報（アクセス統計情報等）を取得することで、平時において、各ノードの最新の使用情報（使用状態）をノード間で共有することが可能となる。つまり、平時より、各ノードの使用状況を都度ノード間で共有することが可能である。例えば、図１に示されたクラスタ３では、各ノードは、定期的に、クラスタ３を構成する全ノード（ノードＡ、Ｂ、Ｃ、Ｄ）の使用情報を取得することで、クラスタ３の構成ノードの使用状況を把握することが可能である。なお、本実施形態では、所定期間が経過する毎に使用情報が取得される場合について説明するが、平時において各ノードの使用情報が繰り返し取得されればよいため、使用情報が取得されるタイミングは不定期であってよい。

　また、本実施形態では、使用情報取得部２２は、自ノードがプライマリクラスタに属する場合にのみ、使用情報を取得することとする。つまり、使用情報取得部２２は、自ノードがノンプラマリクラスタに属する場合は、使用情報を取得する処理を一時停止する。これより、ノンプライマリクラスタに属しているノードにおいて、各ノードの使用情報が取得され各ノードの評価値が更新されてしまうことで、誤って自ノードをプライマリクラスタに設定してしまう事態を回避することが可能である。

　なお、使用情報取得部２２は、他ノードの使用情報については、当該他ノードの使用情報送信部２３により送信された使用情報を受信することで取得し、自ノードの使用情報については、自ノードの記憶装置１４又はその他の記憶装置等に記憶されている、自ノードの使用状況が逐次更新されるテーブル（図示を省略）等から取得する。使用情報取得部２２は、例えば、ＭｙＳＱＬのｈｏｓｔ＿ｓｕｍｍａｒｙ　ｓｙｓテーブルの統計値を参照することでトランザクション数の情報を取得するようにしてよい。

　使用情報送信部２３は、クラスタ３を構成する他ノードに対して、自ノードの使用状況を示す使用情報を繰り返し送信する。本実施形態では、使用情報送信部２３は、所定期間毎に、自ノードの使用情報（累計値）を送信する。

　評価値算出部２４は、使用情報取得部２２によって取得された使用情報（一定期間のトランザクション数の合計値）に基づき、クラスタ３を構成する各ノード１の評価値（重み）を算出する。従来は、上述の通り、各ノードグループのノード数による多数決投票を行うことでクラスタを再構成する方法や、各ノードの重みを手動で設定することによりクラスタを再構成する方法等が用いられている。これら従来の方法に対し、本実施形態では、平時に、ノードの使用状況に応じて自動的に各ノードに対する重み付けが行われ、障害等が発生すると、重み付けの値である評価値に基づき、クラスタ３を再構成するグループ（新たなプライマリクラスタとなるグループ）が決定される。本実施形態では、評価値算出部２４により算出される評価値（重み）に基づく多数決投票が行われることで、クラスタ３を再構成するグループが決定される。なお、評価値算出部２４は、上述した使用情報取得部２２と同様の理由で、自ノードがプライマリクラスタに属する場合にのみ、評価値の算出を行う。

　評価値算出部２４は、各ノードの評価値（重み）を、対応するノードの使用状況に応じて算出する。つまり、評価値算出部２４は、複数のノード（クラスタ３を構成するノード）の使用情報に夫々対応する、当該複数のノードの評価値を算出する。本実施形態では、使用情報取得部２２によって取得された、複数のノード（クラスタ３を構成するノード）の使用情報に基づき、各ノードの評価値を算出する。具体的には、評価値算出部２４は、当該複数のノードの使用情報の値のうちの最大値が、設定可能な評価値の最大値と一致するよう、当該複数のノードの使用情報の値をスケーリング（調整）する。そして、評価値算出部２４は、当該複数のノードの評価値の夫々を、対応するノードのスケーリングされた結果（以下、「調整値」と称する）に基づき算出する。但し、本実施形態では、スケーリングを行った結果、調整値が１未満となった場合は、当該調整値を１に更新する。

　なお、本実施形態では、複数のノード（クラスタ３を構成するノード）の評価値のうち、任意のノードの評価値が、所定の値未満となるよう、複数のノードの評価値を算出する。ここで、所定の値とは、例えば、複数のノード内の前記任意のノード以外の他のノードの評価値の総和である。これは、クラスタ３を構成する一部のノード（例えば、ノードＡ）が故障（消失）した場合にも、生存している残りのノードからなるグループ（クラスタ）でクラスタを再構成することができる（例えば、過半数の評価値を獲得する）ようにするものである。但し、本実施形態では、プライマリクラスタ（クラスタ３）の構成ノード数が３以上である場合にのみ、任意のノードの評価値が所定の値（他のノードの評価値の総和）未満となるよう調整することとする。本実施形態では、上述したノードの調整値を当該ノードの評価値とするが、複数のノードの調整値の中に、他の調整値と比べて極めて大きい調整値（以下、「極大調整値」と称する）がある場合、この極大調整値に係るノードの評価値を、当該極大調整値より小さい値とする。ここで、本実施形態では、他の調整値と比べて極めて大きい調整値は、他の調整値の総和以上である調整値であるが、その他、当該総和の二倍以上である調整値や所定の値以上である調整値等であってもよい。

　具体的には、極大調整値に係るノードの評価値を、当該調整値以外の他の調整値の総和より小さい値（例えば、総和より１小さい値。但し、総和が２以上の場合）とする。ここで、総和より１小さい値とする場合の条件を「総和が２以上の場合」とするのは、総和が１である場合に総和より１小さい値とすると、極大調整値に係るノードの評価値が０となってしまうことを回避するためである。なお、本実施形態では、極大調整値に係るノードの評価値を他の調整値の総和より１小さい値とする例を示すが、極大調整値に係るノードの重要度を下げたい場合等には、当該ノードの評価値を、他の調整値の総和より２又は３小さい値等にしてもよい。なお、この場合、極大調整値に係るノード以外のノードの評価値は、上記と同様に、算出された調整値とする。また、上述の通り、本実施形態では、プライマリクラスタの構成ノード数が３以上である場合に、上述した調整を行うが、当該調整を行う対象となるクラスタの構成ノード数は任意の数（所定の数）に設定されてよい。

　例えば、使用情報取得部２２により取得された、ノードＡ、Ｂ、Ｃ、Ｄ夫々の一定期間のトランザクション数（合計値）が、「４００」、「３００」、「１００」、「２００」であり、設定可能な評価値の最大値が「２５５」である場合、評価値算出部２４は、最大トランザクション数である「４００」が、評価値の最大値である「２５５」と一致するよう、各ノードのトランザクション数をスケーリングする。これにより、ノードＡ、Ｂ、Ｃ、Ｄの調整値が夫々、「２５５」、「１９１」、「６３」、「１２７」と算出される（図３参照）。これらの調整値には、上述したような極めて大きい調整値は存在しないため、これら各ノードの調整値が夫々、対応するノードの評価値として決定される。つまり、ノードＡ、Ｂ、Ｃ、Ｄの評価値は夫々、「２５５」、「１９１」、「６３」、「１２７」と決定される。評価値算出部２４は、各ノードの評価値を決定（算出）すると、プライマリクラスタを構成するノードの評価値の総和を算出する。図３の例では、プライマリクラスタを構成するノードの評価値の総和が、ノードＡ、Ｂ、Ｃ、Ｄの評価値の総和である「６３６」（＝２５５＋１９１＋６３＋１２７）と算出される。ノード評価値算出部２４は、各ノードの評価値及びプライマリクラスタを構成するノードの評価値の総和を算出すると、算出された自ノードの評価値及び評価値の総和で、管理情報テーブル内の「評価値」及び「評価値合計」の情報を夫々更新する。

　なお、上述の通り、本実施形態では、使用情報取得部２２によって取得された、クラスタ３を構成する複数のノード（全ノード）の使用情報に基づき、各ノードの評価値を算出する例を示すが、この例に限定されるものではなく、各ノードの評価値は、対応するノードの使用情報のみに基づき算出（決定）されてもよい。例えば、単に使用情報の値自体を評価値として採用する場合や、使用情報の値に所定の係数を乗算又は加算した値を評価値とする場合等がこれに該当する。使用情報の値自体を評価値とする場合、使用情報取得部２２により取得された使用情報がそのまま、クラスタ３を再構成するグループを決定する処理に用いられてよい。また、本実施形態では、所定期間毎に、即ち、使用情報取得部２２により各ノードの使用情報（一定期間のトランザクション数の合計値）が取得される度に、各ノードの評価値を算出する例を示すが、クラスタ３を再構成するグループを決定する際に用いられる評価値のみが算出されれば足りる。そのため、例えば、平時には評価値が算出されず、障害発生時に、平時に最後に取得された使用情報に基づく評価値が算出されるようにしてもよい。

　本実施形態では、上述したように、トランザクション数が多いノードほど、即ち、使用されている（アクセス頻度の高い）ノードほどその評価値が高くなるように評価値が算出されるが、評価値の算出方法はこの例に限定されるものではなく、使用されているノードほどその評価値が低くなるよう算出されてもよい。但し、この場合は、評価値の低いグループがクラスタ３を再構成するグループとして決定されることとなる。また、本実施形態では、上述したスケーリングにより評価値を算出することとしたが、評価値はノードの使用状況（使用情報）に応じたものであれば、任意の方法により算出されてよい。

　状態検知部２５は、自ノードが現在プライマリクラスタ（クラスタ３として機能するグループ）及びノンプライマリクラスタ（クラスタ３として機能しないグループ）の何れに属するかを検知する。例えば、状態検知部２５は、上述した管理情報（管理情報テーブルの「状態」の欄）を参照することで、現在の自グループの状態を検知する。また、状態検知部２５は、自グループがプライマリクラスタとノンプライマリクラスタとの間で状態遷移したことを検知する。例えば、状態検知部２５は、設定部２８により自グループの状態が変更されたことにより、状態遷移を検知する。但し、これらの検知方法は一例であり、他の方法により自グループの状態（状態遷移）を検知してもよい。

　決定部２６は、クラスタ３が複数のノードグループに分割されると、クラスタ３が分割される前（平時）に取得された、クラスタ３の構成ノード（複数のノード）の使用情報に夫々対応する、当該複数のノードの評価値を用いることで、自グループを、クラスタ３を再構成するグループ（新たなプラマリクラスタ）とするかを決定する。本実施形態では、平時に最後に取得された使用情報に対応する評価値を用いて決定する。つまり、本実施形態では、平時に最後に更新（算出）された評価値に基づき、決定処理が行われる。但し、上述したように、平時に最後に取得された使用情報及びそれ以前に取得された使用情報に基づく評価値が用いられてもよい。なお、本実施形態では、障害が発生したことによりクラスタ３が複数のグループに分割される場合を例示するが、この例に限定されるものではなく、メンテナンス等により一部のノードの動作を一時停止していること等によりクラスタ３が分割される場合も対象とする。

　平時に取得された各ノードの評価値に基づき、自グループを、クラスタ３を再構成するグループとして決定する方法としては、種々の方法を用いることが可能である。例えば、どの２要素（クォーラム）をとっても共通部分が存在するようなノードの部分集合の集合であるクォーラムシステムを用いる方法を採用することが可能であり、本実施形態では、過半数クォーラム（多数決投票）を用いる。具体的には、クラスタ３が分割された後に自グループを構成するノードの評価値の総和が、クラスタ３が分割される前にクラスタ３（プライマリクラスタ）を構成していたノード（クラスタが分割される前に最後に自ノードが属していたプライマリクラスタの構成ノード）の評価値の総和の半数を超える場合に、当該自グループを、クラスタ３を再構成するグループと決定する。以下、障害が発生した場合に重み付け多数決投票を用いてクラスタ３を再構成するグループを決定する具体例を示す。なお、以下の具体例において、障害が発生した時点での管理情報テーブルを、図３に示された管理情報テーブルとする。但し、管理情報テーブル内の各ノードの「クラスタノード」については、障害が検知された時点で、その時点での情報に更新される。

　＜具体例１：拠点間の障害＞
　本具体例では、平時の状態から、拠点１と拠点２とを結ぶネットワーク経路に障害が発生し、拠点１と拠点２との間のネットワーク通信が不可となった場合を例示する。拠点１と拠点２とを結ぶネットワーク経路の障害が発生すると、クラスタ３は、ノードＡ、Ｂからなるグループ（グループ１）と、ノードＣ、Ｄからなるグループ（グループ２）とに分割される。

　この場合、例えば、ノードＡの決定部２６は、管理情報テーブル（図３）を参照し、障害が発生した後に自グループ（グループ１）に属しているノードの評価値（平時に最後に算出された評価値）の総和と、障害発生直前（平時）にクラスタ３（プライマリクラスタ）を構成していたノードの評価値（平時に最後に算出された評価値）の総和の半数とを比較する。図３の例では、グループ１（ノードＡ、Ｂ）の評価値の総和「４４６」（＝２５５＋１９１）と、平時にクラスタ３を構成していたノード（ノードＡ、Ｂ、Ｃ、Ｄ）の評価値の総和「６３６」の半数「３１８」とを比較する。この場合、グループ１の評価値の総和が、平時におけるクラスタ３の構成ノードの評価値の総和の半数を超えるため、ノードＡの決定部２６は、自グループ（グループ１）を、クラスタ３を再構成するグループと決定する。同様に、ノードＢの決定部２６は、自グループを、クラスタ３を再構成するグループと決定する。

　一方、例えば、ノードＣの決定部２６は、管理情報テーブル（図３）を参照し、障害が発生した後に自グループ（グループ２）に属しているノードの評価値の総和と、障害発生直前にクラスタ３を構成していたノードの評価値の総和の半数とを比較する。図３の例では、グループ２（ノードＣ、Ｄ）の評価値の総和「１９０」（＝６３＋１２７）と、平時にクラスタ３を構成していたノード（ノードＡ、Ｂ、Ｃ、Ｄ）の評価値の総和「６３６」の半数「３１８」とを比較する。この場合、グループ２の評価値の総和が、平時におけるクラスタ３の構成ノードの評価値の総和の半数以下であるため、ノードＣの決定部２６は、自グループ（グループ２）を、クラスタ３を再構成しないグループと決定する。同様に、ノードＤの決定部２６は、自グループを、クラスタ３を再構成しないグループと決定する。

　＜具体例２：ノードＡの障害＞
　本具体例では、平時の状態から、ノードＡのＯＳ等に障害が発生し、ネットワーク上からノードＡが消失した場合を例示する。ノードＡの障害が発生すると、クラスタ３は、ノードＡからなるグループ（グループ３）と、ノードＢ、Ｃ、Ｄからなるグループ（グループ４）とに分割される。グループ３は、稼働が停止したノードのグループであり、グループ４は、稼働が継続しているノードのグループである。このように、分割された複数のグループの中には、稼働が停止しているノードのグループが存在していてもよい。この場合、ノードＡは、例えばＯＳ障害等により活動を一時停止するため、ノードＡにおいて決定部２６による決定処理は実行されない。そのため、グループ３は、クラスタ３を再構成するグループと決定されない。

　一方、例えば、ノードＢの決定部２６は、管理情報テーブル（図３）を参照し、障害が発生した後に自グループ（グループ４）に属しているノードの評価値の総和と、障害発生直前にクラスタ３を構成していたノードの評価値の総和の半数とを比較する。図３の例では、グループ４（ノードＢ、Ｃ、Ｄ）の評価値の総和「３８１」（＝１９１＋６３＋１２７）と、平時にクラスタ３を構成していたノード（ノードＡ、Ｂ、Ｃ、Ｄ）の評価値の総和「６３６」の半数「３１８」とを比較する。この場合、グループ４の評価値の総和が、平時におけるクラスタ３の構成ノードの評価値の総和の半数を超えるため、ノードＢの決定部２６は、自グループ（グループ４）を、クラスタ３を再構成するグループと決定する。同様に、ノードＣ、Ｄ夫々の決定部２６は、自グループを、クラスタ３を再構成するグループと決定する。

　なお、具体例１及び具体例２では、クラスタ３が２つのグループに分割される場合を例示したが、この例に限定されず、クラスタ３が３つ以上のグループに分割される場合にも、上述した決定処理を行うことが可能である。また、本実施形態では、クォーラムシステムとして過半数クォーラム（多数決投票）を用いるが、過半数クォーラム以外に、Ｇｒｉｄクォーラムや有限射影平面クォーラムなどの他のクォーラムシステムが用いられてよい。Ｇｒｉｄクォーラムの場合、ノード数が平方数である前提のもとノードを正方形状に配置して、ある行の全てのノードとそれより下の各行から１ノードずつを含むグループが新たなプライマリクラスタと決定される。有限射影平面クォーラムの場合、ノード数がｑ^２＋ｑ＋１（ｑは素数）である前提のもとノードを有限射影平面上に配置して、同一線上のｑ＋１ノードを含むグループが、新たなプライマリクラスタと決定される。Ｇｒｉｄクォーラム及び有限射影平面クォーラムはいずれも全ノードの重みを同じものとしているが、評価値（重み）の大きいノードを評価値に応じて複数配置することにより、特定のノードの重要度を高めることが可能である。

　図４は、本実施形態に係るＧｒｉｄクォーラムシステムの一例を示す図である。図４には、ノード数２５のＧｒｉｄクォーラムシステムを示す。例えば、ノードＡ、Ｂ、Ｃの評価値（重み）が、その他のノードの４倍、３倍、２倍である場合には、図４に示すように、５×５のマス目に、ノードＡが４つ（４倍）、ノードＢが３つ（３倍）、ノードＣがノード２つ（２倍）配置される。これにより、ノードＡ、Ｂ、Ｃの重要度を高めることが可能である。

　図５は、本実施形態に係る有限射影平面クォーラムの一例を示す図である。図５には、ノード数７の有限射影平面クォーラムシステムを示す。例えば、ノードＡの評価値（重み）が他のノードの３倍である場合には、図５に示すように、ノードＡが有限射影平面上に３つ（３倍）配置される。これにより、ノードＡの重要度を高めることが可能である。

　障害検知部２７は、他ノードとの間で生存確認のための通信を定期的に行うことにより、クラスタシステム９内の障害の発生と障害からの復旧を検知する。障害は、例えば、ＯＳやハードウェアのトラブル、故障等によるノード障害や、ネットワークスイッチやＮＩＣのトラブル、故障等によるネットワーク障害等である。例えば、障害検知部２７は、他ノードとの生存確認のための通信がタイムアウトすることで、当該他ノードに障害が発生したと判断（検知）し、生存確認のための通信が正常に行われるようになったことを検知することで、障害からの復旧を検知する。なお、障害発生及び障害復旧の検知方法については、種々の方法が用いられてよい。例えば、他ノードや障害検知装置等から、障害が発生したことを知らせる通知や障害発生ノードにおいて障害が復旧したことを知らせる通知を受信したこと、障害発生ノードから復旧したことの通知を受信したこと、又は、管理者ユーザーから障害発生及び障害復旧についての入力を受け付けたこと等の方法により、障害発生及び障害復旧が検知されてよい。また、障害検知部２７は、障害が発生又は障害が復旧した際に、自グループに属するノードに変更があるときは、管理情報テーブル内の「クラスタノード」の情報を更新する。

　設定部２８は、決定部２６により自グループがクラスタ３を再構成するグループと決定された場合、自グループの状態をプライマリクラスタに設定（変更）する（データベースに対するＲｅａｄリクエスト及びＷｒｉｔｅリクエストの受付を開始するよう設定（制御）する）ことで、サービス提供部２９に、データベースのサービスを開始（継続）させる。一方、設定部２８は、自グループがクラスタ３を再構成しないグループと決定された場合、自グループの状態をノンプライマリクラスタに設定（変更）する（データベースに対するＲｅａｄリクエスト及びＷｒｉｔｅリクエストを受け付けないよう設定（制御）する）ことで、サービス提供部２９に、データベースのサービスの提供を一時停止する等ノードの活動を停止させる。また、設定部２８は、自ノードがノンプライマリクラスタに属する場合、障害復旧後に、プライマリクラスタのノードのデータベースとの同期が終了すると、自グループの状態をプライマリクラスタに設定する。なお、設定部２８は、自グループの状態がプライマリクラスタとノンプライマリクラスタとの間で遷移（変更）するときは、管理情報テーブル内の「状態」の情報を更新する。但し、この例に限定されず、決定部２６によりプライマリクラスタか否かが決定された際に、決定部２６により管理情報内の「状態」の情報が更新されるようにしてもよい。

　サービス提供部２９は、自グループがプライマリクラスタである場合、自ノードのデータベースのサービスを提供する。例えば、サービス提供部２９は、ユーザー端末８から送信されたデータベースに対する読み込み動作及び書き込み動作等の処理要求（クエリ）を受け付け実行する等の、自ノードのデータベースのサービスを提供する。

　再接続部３０は、自グループがノンプライマリクラスタである場合に、プライマリクラスタに含まれるノードとの接続を再度確立する。例えば、再接続部３０は、プライマリクラスタに含まれるノードに対して接続要求を行うことにより、自ノードと当該プライマリクラスタに含まれるノードとの接続の確立を開始する。

　更新情報送受信部３１は、他のノードに対して、自ノードのデータベースの更新状態を示す情報（更新情報）を送信する。例えば、更新情報送受信部３１は、更新情報として、自ノードのデータベースの最新のトランザクション（書き込み処理に係るトランザクション（ｗｒｉｔｅキャッシュに記憶されたトランザクション））のシーケンス番号を他のノードに送信（通知）する。また、更新情報送受信部３１は、他のノードから、当該他のノードの更新情報を受信する。本実施形態では、ノンプライマリクラスタに属するノードは、障害が復旧すると（クラスタに再度参加可能な状態である場合）、プライマリクラスタに属する所定ノードに対して、自ノードの更新情報を送信する。つまり、更新情報送受信部３１は、自ノードとプライマリクラスタに属するノードとの間の、データベースに対する書き込み処理に係るトランザクションの差分を要求する。

　更新データ特定部３２は、他ノードから受信した当該他ノードの更新情報に基づき、自ノードのデータベースと当該他ノードのデータベースとの差分（更新が必要なデータ）を特定する。例えば、本実施形態では、ノンプライマリクラスタに属するノードのシーケンス番号を受信したプライマリクラスタに属する所定ノードにおいて、両ノードのシーケンス番号を比較することにより、自ノードのデータベースと、当該ノンプライマリクラスタに属するノードのデータベースとの差分を特定する（差分の有無を判定する）。例えば、プライマリクラスタに属する所定ノードの更新データ特定部３２は、他ノードのデータベースが自ノードのデータベースよりも古い（更新されていない）状態である場合、当該他ノードにおいて更新が必要なデータ（更新データ（差分データ））を特定する。

　更新データ送受信部３３は、ノード間で同期を行うために用いられる更新データ（差分データ）を送受信する。例えば、プライマリクラスタに属するノードの更新データ送受信部３３は、ノンプライマリクラスタに属するノードにおいて更新が必要なデータ（更新データ）を当該ノードに対して送信し、当該更新データが、当該ノンプライマリクラスタに属するノードの更新データ送受信部３３により受信される。なお、本実施形態では、更新データを差分データとするが、フルデータであってもよい。

　同期部３４は、自ノードのデータベースを、他ノードのデータベースに同期させる。例えば、本実施形態では、ノンプライマリクラスタに属するノードの同期部３４は、当該ノードの更新データ送受信部３３により受信された更新データを用いて、自ノードのデータベースをプライマリクラスタのノードのデータベースに同期させる。なお、クラスタ３は、データ参照だけではなく更新（書き込み）可能なデータベースであるマスタノードが複数存在する（クラスタの構成ノードが全てマスタノードとして機能する）マルチマスタ構成のクラスタである。そのため、プライマリクラスタに属するノード間では、適宜、データベースの同期が行われる。そのため、同期部３４は、自グループがプライマリクラスタである場合、プライマリクラスタに属する他ノードとデータベースの同期を随時行う。

　なお、本実施形態及び後述する他の実施形態では、ノンプライマリクラスタに属するノードにおいて、プライマリクラスタに含まれるノードとの接続を再度確立し、プライマリクラスタとのデータベースの同期を行った後、自ノードをプライマリクラスタに設定する一連の処理を、クラスタに再度参加する処理と称する。

　図６は、本実施形態に係る管理情報テーブル（拠点間障害発生直後）の一例を示す図である。図６は、上述した具体例１の障害が発生した場合を例示しており、当該障害発生直後に各ノードにおいて自グループを、クラスタ３を再構成するグループとするかが判定され、設定が行われた後の管理情報テーブルを示す。図３及び図６に示すように、障害発生直後（図６）は、平時（図３）に最後に取得されたトランザクション数（Ｔｘカウント）、及び、当該トランザクション数に基づき算出、設定された評価値が管理情報テーブルに保持された状態である。

　具体例１で説明したように、この場合、クラスタ３は、ノードＡ、Ｂからなるグループ１と、ノードＣ、Ｄからなるグループ２に分割される。そのため、図６に示すように、ノードＡ、Ｂにおいては、自グループからノードＣ、Ｄが取り除かれ、「クラスタノード」が「Ａ、Ｂ」に更新され、ノードＣ、Ｄにおいては、自グループからノードＡ、Ｂが取り除かれ、「クラスタノード」が「Ｃ、Ｄ」に更新されている。また具体例１では、グループ１がクラスタ３を再構成するグループとして決定されるため、図６に示すように、ノードＡ、Ｂにおいては、「状態」が「ＰＲＩＭＡＲＹ」に更新（継続）され、ノードＣ、Ｄにおいては、「状態」が「ＮＯＮ－ＰＲＩＭＡＲＹ」に更新されている。更に、グループ１がクラスタ３を再構成するグループと決定されたことで、新たなプライマリクラスタに属するノードＡ、Ｂでは、評価値算出部２４により、プライマリクラスタの構成ノードの評価値の総和が算出され、算出された総和「４４６」で、「評価値合計」の情報が更新されている。なお、ノードＣ、Ｄはノンプライマリクラスタに属すため、「評価値合計」の情報には、自ノードが障害発生前に最後にプライマリクラスタに属していた際の、当該プライマリクラスタの構成ノードの評価値総和「６３６」が保持される。

　なお、障害発生後（クラスタ３が分割された後）も、新たなプライマリクラスタに属するノードでは、平時の処理として、使用情報取得処理及び評価値算出（更新）処理が行われる。ここで、クラスタ３を再構成するグループとして決定されたグループ１には、平時にクラスタ３（プライマリクラスタ）において最大トランザクション数を有していたノードＡが含まれている。そのため、障害発生後に新たなプライマリクラスタにおいて行われた使用情報取得処理により取得されたノードＡ、Ｂのトランザクション数の夫々が、障害発生直前に取得されたノードＡ、Ｂのトランザクション数「４００」、「３００」と同値である場合は、障害発生直前と障害発生後のノードＡ、Ｂ夫々の評価値は、「２５５」、「１９１」で同値となる。

　図７は、本実施形態に係る管理情報テーブル（ノード障害発生直後）の一例を示す図である。図７は、上述した具体例２の障害が発生した場合を例示しており、当該障害発生直後に各ノードにおいて自グループを、クラスタ３を再構成するグループとするかが判定され、設定が行われた後の管理情報テーブルを示す。図３及び図７に示すように、障害発生直後（図７）は、平時（図３）に最後に取得されたトランザクション数（Ｔｘカウント）、及び、当該トランザクション数に基づき算出、設定された評価値が管理情報テーブルに保持された状態である。

　具体例２で説明したように、この場合、クラスタ３は、ノードＡからなるグループ３と、ノードＢ、Ｃ、Ｄからなるグループ４に分割される。そのため、図７に示すように、ノードＢ、Ｃ、Ｄにおいては、自グループからノードＡが取り除かれ、「クラスタノード」が「Ｂ、Ｃ、Ｄ」に更新されている。また具体例２では、グループ４がクラスタ３を再構成するグループとして決定されるため、図７に示すように、ノードＢ、Ｃ、Ｄにおいては、「状態」が「ＰＲＩＭＡＲＹ」に更新（継続）されている。更に、グループ４がクラスタ３を再構成するグループと決定されたことで、新たなプライマリクラスタに属するノードＢ、Ｃ、Ｄでは、評価値算出部２４により、プライマリクラスタの構成ノードの評価値の総和が算出され、算出された総和「３８１」で、「評価値合計」の情報が更新されている。なお、ノードＡは、障害発生により活動を一時停止するため、ノードＡにおいて管理情報テーブルは更新されていない。

　図８は、本実施形態に係る管理情報テーブル（評価値更新後）の一例を示す図である。図８は、上述した具体例２の障害が発生した後、所定期間経過毎に実行される平時の処理において評価値が更新された場合の管理情報テーブルを示す。障害発生後も、プライマリクラスタに属するノードＢ、Ｃ、Ｄでは、平時の処理として、使用情報取得処理及び評価値算出（更新）処理が行われる。障害発生後に取得されたノードＢ、Ｃ、Ｄのトランザクション数が夫々、障害発生直前のノードＢ、Ｃ、Ｄのトランザクション数「３００」、「１００」、「２００」と同値である場合、ノードＢのトランザクション数が最大値となる。そのため、各ノードにおいて、評価値算出部２４により、ノードＢのトランザクション数を設定可能な評価値の最大値（例えば、２５５）と一致するよう、ノードＢ、Ｃ、Ｄのトランザクション数が調整（スケーリング）される。その結果、ノードＢ、Ｃ、Ｄの調整値は夫々、「２５５」、「８５」、「１７０」となるが、ノードＢの調整値がノードＣ、Ｄの調整値の総和と等しくなっている。そのため、ノードＢの評価値は、当該総和より１小さい値である「２５４」と決定され、ノードＣ、Ｄの評価値は夫々、「８５」、「１７０」と決定され、各ノードの管理情報テーブルの「評価値」の情報が更新される。また、各ノードでは、評価値算出部２４により、プライマリクラスタの構成ノードの評価値総和が算出され、算出された評価値総和「５０９」（＝２５４＋８５＋１７０）で管理情報テーブルの「評価値合計」が更新されている。

　＜処理の流れ＞
　次に、本実施形態に係る各ノードによって実行される処理の流れを説明する。なお、以下に説明する処理の具体的な内容及び処理順序は、本開示を実施するための一例である。具体的な処理内容及び処理順序は、本開示の実施の態様に応じて適宜選択されてよい。

　図９は、本実施形態に係る評価値更新処理（平時フロー）の流れの概要を示すフローチャートである。本フローチャートに示された処理は、各ノード１において実行される処理であり、例えば、自ノードがクラスタ３に参加したこと等を契機として開始され、所定期間が経過する毎に繰り返し実行される。なお、平時では、クラスタ３を構成する全ノード（ノードＡ、Ｂ、Ｃ、Ｄ）が互いに通信可能である。そのため、平時においては、管理情報テーブル内の各ノードの「クラスタノード」及び「状態」の欄に夫々、「Ａ、Ｂ、Ｃ、Ｄ」及び「ＰＲＩＭＡＲＹ」が格納されている。

　ステップＳ１０１では、現在自ノードがプラマリクラスタに属するかが判定される。状態検知部２５は、管理情報テーブル等を参照することで、現在自ノードがプライマリクラスタに属するかを判定する。自ノードがプライマリクラスタに属する場合（ステップＳ１０１のＹＥＳ）、処理はステップＳ１０２へ進む。一方、自ノードがプライマリクラスタに属さない場合（ステップＳ１０１のＮＯ）、本フローチャートに示された処理は終了する。

　ステップＳ１０２では、各ノードの使用情報が取得される。使用情報取得部２２は、クラスタ３の構成ノード（自ノードと通信可能な他ノードと自ノード）夫々の使用情報を取得する。本実施形態では、各ノードにおいて、全ノード（ノードＡ、Ｂ、Ｃ、Ｄ）についての一定期間のトランザクション数（合計値）が取得される。また、使用情報取得部２２は、取得された自ノードのトランザクション数（ノードＡは「４００」、ノードＢは「３００」、ノードＣは「１００」、ノードＤは「２００」）で、管理情報テーブルの「Ｔｘカウント」の情報を更新する（図３参照）。その後、処理はステップＳ１０３へ進む。

　ステップＳ１０３では、各ノードの使用情報が調整される。評価値算出部２４は、ステップＳ１０２で取得された各ノードのトランザクション数に対してスケーリングを行うことにより、各ノードについての調整されたトランザクション数（調整値）を算出する。その後、処理はステップＳ１０４へ進む。

　ステップＳ１０４では、他の調整値と比べて極めて大きい調整値が存在するか判定される。評価値算出部２４は、ステップＳ１０３で算出された各ノードの調整値の中に、他の調整値と比べて極めて大きい調整値（極大調整値）が含まれるかを判定する。極大調整値が存在する場合（ステップＳ１０４のＹＥＳ）、処理はステップＳ１０５へ進む。一方、極大調整値が存在しない場合（ステップＳ１０４のＮＯ）、処理はステップＳ１０６へ進む。なお、本実施形態では、プライマリクラスタの構成ノード数が３（所定の数）以上である場合にのみ、ステップＳ１０５の処理を行うため、プライマリクラスタの構成ノード数が３（所定の数）以上でない場合は、極大調整値が存在する場合であっても、ステップＳ１０６へ進む。

　ステップＳ１０５では、該当するノードの調整値が、他ノードの調整値の総和Ｓより小さい値で更新される。評価値算出部２４は、ステップＳ１０４において極大調整値と判定された調整値に係るノードの調整値を、他ノードの調整値の総和Ｓより小さい値（例えば、Ｓより１小さい値）に更新する。その後、処理はステップＳ１０６へ進む。

　ステップＳ１０６では、各ノードの調整値が評価値として決定（更新）される。評価値算出部２４は、ステップＳ１０４において極大調整値でないと判定された調整値に係るノードの評価値を、ステップＳ１０３で算出された調整値と決定する。また、評価値算出部２４は、ステップＳ１０４において極大調整値であると判定された調整値に係るノードの評価値を、ステップＳ１０５で更新された調整値と決定する。但し、プライマリクラスタの構成ノード数が３以上でない場合、極大調整値である調整値に係るノードの評価値は、ステップＳ１０３で算出された調整値と決定する。また、評価値算出部２４は、決定した各ノードの調整値により、プライマリクラスタを構成するノードの評価値の総和を算出する。そして、評価値算出部２４は、決定された自ノードの評価値（ノードＡは「２５５」、ノードＢは「１９１」、ノードＣは「６３」、ノードＤは「１２７」）及びプライマリクラスタの構成ノードの評価値の総和「６３６」で、管理情報テーブルの「評価値」及び「評価値合計」の情報を夫々更新する（図３参照）。その後、本フローチャートに示された処理は終了する。

　なお、本実施形態では、ステップＳ１０１において自ノードがプライマリクラスタに属さない場合には、後述する処理が実行されないようにすることで、プライマリクラスタに属さないノードが誤ってプライマリクラスタに設定されてしまう事態を回避することが可能である。しかし、このような事態を回避する方法は上述した例に限定されるものではない。例えば、自ノードがプライマリクラスタに属さない場合も、自ノードと通信可能なノードの使用情報を取得する一方、取得した使用情報に基づき、評価値を決定、更新することを禁止するようにしてもよい。また、自ノードがプライマリクラスタに属さない場合も、自ノードと通信可能なノードの使用情報を取得し、取得した使用情報に基づき、評価値を決定、更新する一方、図１０に示したグループ決定処理を禁止するようにしてもよい。

　図１０は、本実施形態に係るグループ決定処理（障害発生時フロー）の流れの概要を示すフローチャートである。本フローチャートに示された処理は、各ノード１において実行される処理であり、クラスタシステム９内で障害が発生したことを障害検知部２７により検知されたこと等を契機として実行される。なお、障害発生に限定されず、上述の通り、メンテナンスの通知を受けたこと等を契機として実行されてもよい。

　ステップＳ２０１では、自ノードと通信不能なノードが自グループから取り除かれる。障害検知部２７は、障害を検知すると、自ノードと通信が途絶えたノードを自グループから取り除く。上述した具体例１では、ノードＡ、Ｂ夫々において自グループの構成ノードがノードＡ、Ｂに、ノードＣ、Ｄ夫々において自グループの構成ノードがノードＣ、Ｄとなり、各ノードにおける障害検知部２７は、管理情報テーブルの「クラスタノード」の情報を更新する（図６参照）。その後、処理はステップＳ２０２へ進む。

　ステップＳ２０２では、自グループの評価値の総和が算出される。決定部２６は、ステップＳ２０１で通信不能なノードが排除され、自グループを構成するノードが更新されると、更新された自グループの構成ノードの評価値（障害発生前に最後に算出（更新）された評価値）の総和を算出する。具体例１では、ノードＡ、Ｂでは総和「４４６」が、ノードＣ、Ｄでは総和「１９０」が夫々算出される。その後、処理はステップＳ２０３へ進む。

　ステップＳ２０３では、自グループの評価値の総和が、元のプライマリクラスタの評価値の総和の半数を超えるかが判定される。決定部２６は、ステップＳ２０２で算出された自グループの評価値の総和が、元のプライマリクラスタ（平時のクラスタ３）の構成ノード（ノードＡ、Ｂ、Ｃ、Ｄ）の評価値の総和「６３６」の半数「３１８」を超えるかを判定する。総和の半数を超える場合（ステップＳ２０３のＹＥＳ）、処理はステップＳ２０４へ進む。一方、総和の半数を超えない場合（ステップＳ２０３のＮＯ）、処理はステップＳ２０５へ進む。なお、ステップＳ２０３において、現在自ノードがプライマリクラスタに属するかについて併せて判定するようにしてもよい。この場合、ステップＳ２０３では、両者の条件（プライマリクラスタであること、総和の半数を超えること）を満たすかが判定される。

　ステップＳ２０４では、自グループが、クラスタを再構成するグループと決定される。具体例１の場合、ノードＡ、Ｂ夫々の決定部２６は、自グループを、クラスタ３を再構成するグループに決定する。その後、処理はステップＳ２０６へ進む。

　ステップＳ２０５では、自グループが、クラスタを再構成しないグループと決定される。具体例１の場合、ノードＣ、Ｄ夫々の決定部２６は、自グループを、クラスタ３を再構成しないグループに決定する。その後、処理はステップＳ２０７へ進む。

　ステップＳ２０６では、自グループがプライマリクラスタに設定される。具体例１の場合、ノードＡ、Ｂ夫々の設定部２８は、自グループをプライマリクラスタとして設定し、サービス提供部２９に、データベースのサービスを開始（継続）させる。そして、ノードＡ、Ｂ夫々の評価値算出部２４は、新たなプライマリクラスタの構成ノードの評価値の総和を算出する。これより、ノードＡ、Ｂ夫々において、設定部２８により管理情報テーブル内の「状態」の情報が、評価値算出部２４により「評価値合計」の情報が更新される（図６参照）。その後、本フローチャートに示された処理は終了する。

　ステップＳ２０７では、自グループがノンプライマリクラスタに設定される。具体例１の場合、ノードＣ、Ｄ夫々の設定部２８は、自グループをノンプライマリクラスタとして設定し、サービス提供部２９に、データベースのサービスの提供を停止させる。これより、ノードＣ、Ｄ夫々において、設定部２８により管理情報テーブル内の「状態」の情報が更新される（図６参照）。その後、本フローチャートに示された処理は終了する。

　本実施形態では、図９の平時フローのステップＳ１０１において自ノードがノンプライマリクラスタに属すると判定された場合は、ステップＳ１０１に後続する処理は実行されない。よって、図１０のステップＳ２０５でクラスタ３を再構成しないグループと決定されたグループ（ノードＣ、Ｄ）では、ノンプライマリクラスタに属して以降、再度プライマリクラスタに属するまでは、使用情報取得処理及び評価値算出処理（図９のステップＳ１０２～ステップＳ１０６）は実行されない。ノンプライマリクラスタに属しているにも関わらずノードＣ、Ｄにおいてこれらの処理が実行されてしまうと、ステップＳ１０３においてノードＣ、Ｄの少なくともどちらかの評価値が、設定可能な評価値の最大値に設定されてしまう。そのため、ステップＳ２０３において元のプライマリクラスタ（自ノードが最後に属していたプライマリクラスタ）の総和６３６の半数を超える可能性がある。その場合、ノンプライマリクラスタに属するにもかかわらず、誤ってプライマリクラスタに設定されてしまう事態が発生する。よって、本実施形態では、このような事態を回避するため、ステップＳ１０１において自ノードがノンプライマリクラスタに属するか否かを判定する。

　なお、図１０のステップＳ２０６において新たなプライマリクラスタに設定されたグループ（ノードＡ、Ｂからなるグループ１）内において新たな障害が発生し、当該グループが複数のグループに分割された場合は、図１０に示されたフローを実行することにより、当該複数のグループの中から、新たなプライマリクラスタ（グループ１）を再構成するグループを決定することが可能である。つまり、本実施形態では、図１に示されたクラスタ３が分割された場合の例を示すが、障害発生後に新たなプライマリクラスタとなったグループ１に対しても、クラスタ３と同様に、本実施形態で説明した決定処理を適用することが可能である。

　図１１は、本実施形態に係る同期処理（障害復旧時フロー）の流れの概要を示すフローチャートである。本フローチャートに示された処理は、各ノード１において実行される処理であり、クラスタシステム９内の障害が復旧したことを障害検知部２７により検知されたこと等を契機として実行される。なお、自ノードが再度クラスタに参加可能な状態になれば、本フローチャートに示された処理が実行されてよいため、処理の契機は、障害復旧の検知に限定されない。

　ステップＳ３０１では、自グループが、クラスタ３を再構成しないグループとして決定されたグループであるか、つまり、現在自グループがノンプライマリクラスタであるかが判定される。具体例１の場合、ノードＣ、Ｄからなるグループ２は、クラスタ３を再構成しないグループと決定されているため、ノードＣ、Ｄ夫々において自グループ（グループ２）の状態はノンプライマリクラスタである。状態検知部２５は、管理情報テーブル等を参照することで、現在自グループがノンプライマリクラスタであるかを判定する。自グループがノンプライマリクラスタである場合（ステップＳ３０１のＹＥＳ）、処理はステップＳ３０２へ進み、クラスタ（プライマリクラスタ）に再度参加する処理が実行される。一方、自グループがノンプライマリクラスタでない場合（ステップＳ３０１のＮＯ）、本フローチャートに示された処理は終了する。

　ステップＳ３０２では、自ノードのデータベースがプライマリクラスタのデータベースに同期される。具体例１の場合、ノードＣ、Ｄ夫々において、再接続部３０がプライマリクラスタに属するノードＡ及びノードＢとの接続を再度確立すると、同期部３４は、自ノードのデータベースをプライマリクラスタに属する所定ノード（ノードＡ又はノードＢ）のデータベースに同期させる。具体的には、更新情報送受信部３１により自ノードの最新のシーケンス番号がプライマリクラスタに属する所定ノードに送信され、当該所定ノードの更新データ特定部３２により更新データが特定される。そして、同期部３４は、当該所定ノードの更新データ送受信部３３と自ノードの更新データ送受信部３３との間で送受信された更新データを用いることで、同期を行う。その後、処理はステップＳ３０３へ進む。

　ステップＳ３０３では、自グループがプライマリクラスタに設定される。具体例１の場合、ノードＣ、Ｄ夫々において、設定部２８は、自グループをプライマリクラスタとして設定し、サービス提供部２９にデータベースのサービスを開始させる。これより、ノードＣ、Ｄは夫々、クラスタ３において提供されているデータベースのサービスを行う（クラスタ３として機能する）ノードとして、データベースのサービスを提供する。その後、本フローチャートに示された処理は終了する。

　上述の通り、本実施形態に係るクラスタシステムによれば、障害発生前に取得された、ノードの使用状況を示す情報に基づく評価値（重み）を用いて、自グループを、クラスタを再構成するグループとするかを決定するため、クラスタを再構成するグループを、ノードの使用状況に応じて適切に選択することが可能である。具体的には、平時のノードの使用状況に応じた評価値を設定することで、ネットワーク遮断等の障害が発生した際にも、最近のアクセス頻度が高いノードによって構成されるグループを新たなプライマリクラスタとして動作を継続させることが可能となる。つまり、利用可能なノード数だけでなく、アクセス頻度を同時に考慮することで、適切なグループを、クラスタを再構成するグループとして選択することが可能である。また、本実施形態に係るクラスタシステムによれば、ノードに対する重み設定を、ノードの使用状況に応じて自動的に行うこと（動的な重み付け）が可能である。

　従来のノード数による多数決投票では、ノード数による過半数という判断基準により、クラスタ３の構成ノード数が２である場合、ネットワーク遮断が発生するといずれのグループもノード数が１となり動作継続不可となるため、推奨される最小構成ノード数が３である他、２拠点に同数のノードを配置した場合などにノード数調整のための調停ノード（実際のデータを格納しないダミーノード）を設置するなど、導入先のネットワーク環境に合わせて、システムの構築・運用方法の設計を人が行うことが求められる。例えば、上述した具体例１の障害が発生した場合、従来の方法では、いずれのグループもノード数が２となることから元の総ノード数（４）の半数を超えないために、いずれのグループも動作継続不可となるため、調停ノードの設置等が必要とされる。

　しかし、本実施形態に係るクラスタシステムによれば、上述の通り、利用可能なノード数だけでなく、アクセス頻度等の使用状況を考慮して、クラスタを再構成するグループを決定することが可能であるため、上記のような状況であっても調停ノードを設置することなく、適切なグループを、クラスタを再構成するグループと決定し動作継続させることが可能となる。更に、クラスタを再構成するグループを決定するための一連の処理は、自動的に行うことが可能であるため、システム管理者が介在する必要がなく、複雑なシステムの構築・運用方法の設計を必要としない自律制御デバイスを提供することが可能となる。

　また、本実施形態に係るクラスタシステムによれば、平時にクラスタを構成する各ノードへのアクセス統計情報を収集しノード間で共有することにより、ネットワーク障害等が発生した後、各ノードにおいて速やかに、自グループを、クラスタを再構成するグループとするか否かを決定（判定）することが可能である。例えば、障害が発生した後に、どのグループを優先させるかを決定するための情報をノード間で送受信しなくとも、自グループを、クラスタを再構成するグループとするか否かを決定することが可能である。

　［第二の実施形態］
　次に、第二の実施形態を説明する。第二の実施形態では、上記第一の実施形態で説明した内容と重複する項目については、同一の符号を付して説明を省略するが、第一の実施形態で説明した内容と異なる内容については、以下で説明する。第二の実施形態では、障害等が発生した際に、クラスタ３を再構成しないグループと決定されたグループのノードにおいても、データベースのサービスを提供し、障害が復旧した際には、クラスタに再度参加する実施形態について説明する。

　＜システムの構成＞
　図１２は、本実施形態に係るマルチマスタ構成のクラスタを備えるクラスタシステムの構成を示す概略図である。本実施形態に係るクラスタシステム９では、マルチマスタ構成のクラスタ３を構成する複数のノード１がネットワークを介して互いに通信可能に接続されている。本実施形態に係るクラスタシステム９では、拠点１にノードＡ、Ｂが配置され、拠点２にノードＣが配置されている。なお、本実施形態に係るクラスタシステム９（ノード１、ユーザー端末８）の構成は、上述した第一の実施形態に係るクラスタシステム９の構成と、拠点２におけるノード数が異なること以外は同様であるため、詳細の説明を省略する。

　図１３は、本実施形態に係るノードの機能構成の概略を示す図である。各ノード１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、ノード１に備えられた各ハードウェアが制御されることで、管理情報記憶部２１、状態検知部２５、決定部２６、障害検知部２７、設定部２８、サービス提供部２９、再接続部３０、更新情報送受信部３１、更新データ特定部３２、更新データ送受信部３３、同期部３４、バックアップ部４０、バックアップ制御部４１及びリストア部４２を備える装置として機能する。

　管理情報記憶部２１は、自ノード及び自ノードが属するクラスタに関する管理情報を記憶する。本実施形態では、管理情報として、少なくとも、自グループがプライマリクラスタとノンプライマリクラスタの何れに属するか（自グループの状態）を示す情報を記憶する。そのため、第一の実施形態で示した管理情報テーブルを必ずしも備えなくてよい。また、管理情報記憶部２１は、管理情報として、自ノードのデータベースのバックアップ機能の状態（有効又は無効）を記憶してよい。

　状態検知部２５の詳細は、第一の実施形態で説明した内容と同様である。但し、本実施形態では、状態検知部２５は、管理情報記憶部２１により記憶されている管理情報（自グループの状態）を参照することで、現在の自ノードの状態を検知する。

　決定部２６は、クラスタ３が複数のノードグループに分割されると、少なくとも自グループを、クラスタ３を再構成するグループとするか否かを決定する。なお、クラスタ３を再構成するグループを決定する方法には、第一の実施形態に示された方法や、その他の任意の方法が用いられてよい。また、本実施形態では、各ノードにおいて決定部２６を備えるようにしたが、１つのノードのみが決定部２６を備えることで各グループを、クラスタ３を再構成するグループとするか否かを決定するようにしてもよい。また、クラスタ３を再構成するグループを決定する装置は、クラスタ３を構成するノードに限定されず、クラスタシステム内外に設置された他の情報処理装置であってもよい。

　障害検知部２７の詳細は、第一の実施形態で説明した内容と同様であるため説明を省略する。

　バックアップ部４０は、自ノードのデータベースのバックアップを繰り返し行う。本実施形態では、バックアップ部４０は、定期的（所定期間毎、例えば１日に１回）にバックアップを行う。また、本実施形態では、バックアップ部４０は、フルバックアップを行うが、差分バックアップや増分バックアップを行うようにしてもよい。バックアップ部４０は、バックアップを行うことにより、バックアップデータを取得し、取得されたバックアップデータを記憶装置１４又はその他の記憶装置に記憶する。なお、バックアップ処理は、定期的ではなく、不定期に実行されてもよい。

　図１４は、本実施形態に係るデータベースの状態（平時）の一例を示す図である。図１４に示すように、平時では、プライマリクラスタに属する全ノード（ノードＡ、Ｂ、Ｃ）で同じ内容のテーブルを保持（共有）している。また、各ノードのバックアップ部４０は、所定期間毎にバックアップを行い、その都度、図１４に示したようにデータベースのバックアップデータを取得する。

　バックアップ制御部４１は、バックアップ部４０により行われる自ノードのデータベースに対するバックアップ処理を有効化又は無効化する制御を行う。バックアップ制御部４１は、例えば、障害が発生したことで、自グループがプライマリクラスタからノンプライマリクラスタに状態遷移した場合、自ノードのデータベースのバックアップ処理を無効化する。つまり、バックアップ制御部４１は、バックアップ部４０によるバックアップ処理が行われないよう制御する。また、バックアップ制御部４１は、例えば障害が復旧し、自ノードの同期部３４による同期が終了すると、自ノードのデータベースのバックアップ処理を有効化する。つまり、バックアップ制御部４１は、バックアップ部４０によるバックアップが開始されるよう制御する。

　設定部２８の詳細は、第一の実施形態で説明した内容と同様である。但し、本実施形態では、自グループがクラスタ３を再構成しないグループである場合の処理が、第一の実施形態と異なる。具体的には、設定部２８は、自グループがクラスタ３を再構成しないグループと決定された場合、管理情報に含まれる自グループの状態を「ノンプライマリクラスタ」に更新する一方、サービス提供部２９に、自ノードのデータベースのサービスを開始（継続）させる。つまり、設定部２８は、自グループがクラスタ３を再構成するグループに決定されなかった場合であっても、自ノードのデータベースのサービス提供が可能となるよう、データベースに対するＲｅａｄリクエスト及び／又はＷｒｉｔｅリクエストの受付が拒否されないよう設定する。なおこの設定は、予め行われるようにしてよい。

　サービス提供部２９の詳細は、第一の実施形態で説明した内容と同様である。但し、上述したように、本実施形態では、クラスタ３が複数のノードグループに分割された際に、自グループがクラスタ３を再構成するグループに決定されなかった場合であっても、自ノードのデータベースのサービスを提供する。例えば、サービス提供部２９は、自グループがクラスタ３を構成するグループに決定されなかった場合、クラスタ３とは異なるクラスタ（自グループ）において、自ノードのデータベースのサービス提供を行うことが可能である。なお、クラスタ３を再構成しないグループと決定されたグループの各ノードは、自グループ（自クラスタ）に属する他のノードと同期を行いながらサービスを提供してもよい（自クラスタにおいてはプライマリクラスタである）し、自グループの他のノードと同期を行うことなく、単独でサービスを提供するようにしてもよい。

　なお、自ノードがノンプライマリクラスタに属する場合に提供するサービスは、自ノードのデータベースに対する書き込みリクエスト及び／又は読み込みリクエストに対するサービスである。また、ノンプライマリクラスタに属する場合に書き込みリクエストを許可する場合は、一部の書き込み動作（例えば、利用者のＩＤ情報やアクセストークンの書き込み動作）のみを許可するようにしてもよい。

　図１５は、本実施形態に係るデータベースの状態（障害発生後）の一例を示す図である。図１５では、拠点１と拠点２を結ぶネットワーク経路に障害が発生し、拠点１と拠点２との間のネットワーク通信が不可となった場合を例示する。この場合、拠点１と拠点２の間で障害が発生したことにより、クラスタ３が、ノードＡ、Ｂからなるグループ（グループ５）と、ノードＣからなるグループ（グループ６）に分割される。また、図１５の例では、決定部２６により、グループ５がクラスタ３を再構成するグループとして決定された場合を想定する。クラスタ３がグループ５とグループ６とに分割されると、夫々のグループにおいて、データベースのサービスが提供される。その結果、グループ５とグループ６とで別々の更新処理（書き込み処理）が行われ、図１５に示すように、グループ５とグループ６とでは、データベース中の「Ｂｏｂ」の「Ａｇｅ（年齢）」が「４６」と「４４」とで異なっている。

　リストア部４２は、バックアップデータを用いて自ノードのデータベースのリストアを行う。具体的には、リストア部４２は、自ノードがノンプライマリクラスタに属するノードである場合に、障害が復旧すると（クラスタに再度参加可能な状態である場合）、バックアップが無効化される前に行われたバックアップにより得られたバックアップデータにより、自ノードのデータベースのリストアを行う。本実施形態では、バックアップが無効化される前に最後に行われたバックアップにより得られたバックアップデータを用いるが、状況に応じて、最後に行われたバックアップの１つ前に行われたバックアップにより得られたバックアップデータ等を用いてもよい。

　図１６は、本実施形態に係るデータベースの状態（障害復旧時（リストア時））の一例を示す図である。図１６には、障害が復旧した後、ノンプライマリクラスタに属するノードＣにおいてリストアが行われた後のデータベースの状態が示されている。なお、図１６の例では、バックアップが無効化される前に最後に取得されたバックアップデータを、図１４に示されたバックアップデータとする。ノードＣのリストア部４２は、最後に取得されたバックアップデータ（図１４、図１６）を用いることで、自ノードのデータベースのリストアを行う。その結果、図１６に示すように、ノードＣのデータベース中の「Ｂｏｂ」の「Ａｇｅ（年齢）」が、「４４」から「４５」に更新される。このようにリストアが行われることで、障害発生後（クラスタ３が分割した後）にノードＣで行われた変更内容、つまり、ノードＣが属するグループがノンプリマリクラスタとなっていた間のノードＣ（ノードＣが属するクラスタ）内での変更内容がロールバックされる。

　再接続部３０の詳細は、第一の実施形態で説明した内容と同様であるため説明を省略する。

　更新情報送受信部３１の詳細は、第一の実施形態で説明した内容と同様である。但し、本実施形態では、ノンプライマリクラスタに属するノードの更新情報送受信部３１は、リストアが行われた自ノードのデータベースの更新状態を示す更新情報（最新のトランザクションのシーケンス番号）を、プライマリクラスタに属する所定ノードに送信する。つまり、更新情報送受信部３１は、リストアが完了した自ノードのデータベースと、プライマリクラスタに属するノードのデータベースとの、書き込み処理に係るトランザクションの差分を要求する。

　図１７は、本実施形態に係るデータベースの状態（障害復旧時（同期時））の一例を示す図である。図１７は、ノードＣにおいて、リストアを行った状態からノードＡ及びノードＢ（プライマリクラスタ）の状態との同期処理が行われた場合のデータベースの状態を例示する。ノンプライマリクラスタに属するノードＣは、プライマリクラスタに属する所定ノード（ノードＡ又はノードＢ）に対して、自ノードのデータベースと当該所定ノードのデータベースとの差分データを要求する。例えば、図１７に示すように、ノードＣの更新情報送受信部３１は、自ノードのデータベースの最新のトランザクション（書き込み処理に係るトランザクション）の更新情報（シーケンス番号「４１」）を当該所定ノードに送信することで、差分データを要求する。

　更新データ特定部３２の詳細は、第一の実施形態で説明した内容と同様である。図１７の例では、ノンプライマリクラスタに属するノードＣからの更新情報を受信した、プライマリクラスタに属する所定ノードにおいて、ノードＣと当該所定ノードとの差分、即ち、ノードＣに不足しているデータが特定される。本実施形態では、例えば、ノードＡの更新データ特定部３２は、ノードＣから通知された最新のトランザクションのシーケンス番号と、ノードＡの最新のトランザクションのシーケンス番号とを比較することで、両ノードのデータベースの差分を特定する。

　図１７の例では、ノードＡ又はノードＢにおいて、ノードＣから通知されたノードＣの最新のシーケンス番号「４１」と、ノードＡ及びノードＢの最新のシーケンス番号「４２」とが比較される。そして、ノードＣに送信される差分データ（トランザクション）の範囲が、シーケンス番号「４１」に該当するトランザクションに後続するトランザクション、即ち、シーケンス番号「４２」に該当するトランザクション「ｕｐｄａｔｅ　ｔａｂｌｅ　Ａｇｅ＝４６　ｗｈｅｒｅ　Ｎａｍｅ＝“Ｂｏｂ”」と特定される。

　更新データ送受信部３３の詳細は、第一の実施形態で説明した内容と同様である。図１７の例では、ノードＡ又はノードＢの更新データ送受信部３３により差分データ（更新データ）がノードＣに送信され、ノードＣの更新データ送受信部３３により、当該差分データが受信される。

　同期部３４の詳細は、第一の実施形態で説明した内容と同様である。但し、本実施形態では、リストアが行われた自ノードのデータベースを、プライマリクラスタに属するノードのデータベースに同期させる。図１７の例では、ノードＣの同期部３４は、自ノードの更新データ送受信部３３により受信された差分データを用いて、自ノードのデータベースをプライマリクラスタに属するノードのデータベースに同期させる。具体的には、ノードＣの同期部３４は、受信した、シーケンス番号「４２」に該当するトランザクションを自ノードのデータベースに適用する。その結果、図１７に示すように、データベース中の「Ｂｏｂ」の「Ａｇｅ（年齢）」が、「４５」から「４６」に更新される。つまり、ノードＣがノンプライマリクラスタに属していた間にプライマリクラスタ内で行われた変更による差分が、ノードＣのデータベースに反映される。なお、受信された差分データに複数のトランザクションが含まれる場合は、最後に受信したトランザクションが適用されることで、データベースの同期が完了する。

　このように、本実施形態では、リストアを行った上で差分データを用いて自ノードのデータベースを同期するため、クラスタ３が分割された後にプライマリクラスタ内で行われたデータ変更に係る差分データのみを受信することで、クラスタ３全体のデータの整合性を図ることが可能である。そのため、ノンプライマリクラスタに属するノードが同期を行うめに他ノードから受信するデータの量は、フルデータと比較して少ないため、速やかにプライマリクラスタのノードのデータベースとの同期を行うことが可能となる。但し、同期の方法は上記の例に限定されるものではなく、例えば、障害発生後にプライマリクラスタ内で大幅な変更（更新）があった場合などは、プライマリクラスタに属するノードのデータベースのフルデータを更新データとして受信し、当該更新データにより同期を行うようにしてもよい。

　＜処理の流れ＞
　図１８は、本実施形態に係るバックアップ処理（平時フロー）の流れの概要を示すフローチャートである。本フローチャートに示された処理は、各ノード１において実行される処理であり、例えば、自ノードがクラスタシステム９に参加したこと等を契機として開始され、所定期間が経過する毎に繰り返し実行される。なお、平時では、クラスタ３を構成する全ノード（ノードＡ、Ｂ、Ｃ、Ｃ）が互いに通信可能であり、各ノードがプライマリクラスタの構成ノードとしてサービスを提供している。

　ステップＳ４０１では、現在自ノードにおいて、バックアップ処理が有効であるかが判定される。バックアップ制御部４１は、例えば、管理情報を参照することにより、自ノードのバックアップ機能が有効であるか又は無効であるかを判定する。有効である場合（ステップＳ４０１のＹＥＳ）、処理はステップＳ４０２へ進む。一方、無効である場合（ステップＳ４０１のＮＯ）、自ノードはノンプライマリクラスタに属する状態であるため、バックアップを行わないよう、本フローチャートに示された処理は終了する。

　ステップＳ４０２では、バックアップ処理が行われる。バックアップ部４０は、自ノードのデータベースのバックアップ処理を実行する（図１４参照）。その後、本フローチャートに示された処理は終了する。

　図１９は、本実施形態に係るバックアップ無効化処理（障害発生時フロー）の流れの概要を示すフローチャートである。本フローチャートに示された処理は、各ノード１において実行される処理であり、クラスタシステム９内で障害が発生したことを障害検知部２７により検知されたこと等を契機として実行される。なお、障害発生に限定されず、上述の通り、メンテナンスの通知を受けたこと等を契機として実行されてもよい。

　ステップＳ５０１では、自グループの状態がプライマリクラスタからノンプライマリクラスタに遷移したかが判定される。状態検知部２５は、例えば、自グループが、クラスタ３を再構成しないグループと決定されたことでノンプライマリクラスタに設定されたことを検知することで、自グループが状態遷移したかを判定する。なお、状態検知部２５は、管理情報記憶部２１により記憶される管理情報を参照することで自グループの状態遷移を検知してもよい。ノンプライマリクラスタに遷移したと判定された場合（ステップＳ５０１のＹＥＳ）、処理はステップＳ５０２へ進む。ノンプライマリクラスタに遷移していないと判定された場合（ステップＳ５０２のＮＯ）、本フローチャートに示された処理は終了する。

　ステップＳ５０２では、バックアップ処理が無効化される。バックアップ制御部４１は、自ノードのデータベースのバックアップ機能を無効化する。図１５の例では、ネットワークスプリットによりノンプライマリクラスタに属したノードＣにおいてバックアップ処理が無効化される。これにより、管理情報中のバックアップ機能の状態を示す情報は、「無効」を示す情報となる。なお、本実施形態では、自ノードがクラスタ３を再構成しないグループと決定された場合であっても、サービスの提供を継続するため、ステップＳ５０２においてバックアップ処理が無効化された後も引き続き、自ノードのサービスの提供が継続される。その後、本フローチャートに示された処理は終了する。

　図２０は、本実施形態に係る同期処理（障害復旧時フロー）の流れの概要を示すフローチャートである。本フローチャートに示された処理は、各ノード１において実行される処理であり、クラスタシステム９内の障害が復旧したことを障害検知部２７により検知されたこと等を契機として実行される。なお、自ノードが再度クラスタに参加可能な状態になれば、本フローチャートに示された処理が実行されてよいため、処理の契機は、障害復旧の検知に限定されない。

　ステップＳ６０１では、自グループが、クラスタ３を再構成しないグループとして決定されたグループであるか、つまり、現在自グループがノンプライマリクラスタであるかが判定される。状態検知部２５は、管理情報等を参照することで、現在自グループがノンプライマリクラスタであるかを判定する。自グループがノンプライマリクラスタである場合（ステップＳ６０１のＹＥＳ）、処理はステップＳ６０２へ進み、クラスタ（プライマリクラスタ）に再度参加する処理が実行される。一方、自グループがノンプライマリクラスタである場合（ステップＳ６０１のＮＯ）、本フローチャートに示された処理は終了する。

　ステップＳ６０２では、最後に取得されたバックアップデータを用いたリストアが行われる。図１６の例では、ノンプライマリクラスタに属するノードＣのリストア部４２は、最後に取得されたバックアップデータを用いることで、自ノードのデータベースのリストアを行う。そして、リストアが完了した後、ノードＣの再接続部３０は、ノードＣとプライマリクラスタの各ノードとの接続を確立する。その後、処理はステップＳ６０３へ進む。

　ステップＳ６０３では、自ノードのデータベースがプライマリクラスタのデータベースに同期される。図１７の例では、ノードＣの更新情報送受信部３１により、リストアが完了した時点でのノードＣの最新のシーケンス番号がプライマリクラスタの所定ノードに送信され、当該所定ノードの更新データ特定部３２により差分データが特定される。そして、ノードＣの同期部３４は、当該所定ノードの更新データ送受信部３３とノードＣの更新データ送受信部３３との間で送受信された差分データを用いることで、ノードＣのデータベースをプライマリクラスタのデータベースに同期させる。その後、処理はステップＳ６０４へ進む。

　ステップＳ６０４では、自グループがプライマリクラスタに設定される。図１７の例では、ノードＣの設定部２８は、自グループをプライマリクラスタとして設定し、サービス提供部２９に、データベースのサービスを開始させる。これより、ノードＣは、クラスタ３において提供されているデータベースのサービスを行う（クラスタ３として機能する）ノードとして、データベースのサービスを提供する。その後、処理はステップＳ６０５へ進む。

　ステップＳ６０５では、バックアップ処理が有効化される。図１７の例では、ノードＣのバックアップ制御部４１は、自ノードのデータベースがプライマリクラスタに属していたノードと同等の状態となったことから、自ノードのバックアップ機能を有効化する。これにより、管理情報中のバックアップ機能の状態を示す情報は、「有効」を示す情報となる。その後、本フローチャートに示された処理は終了する。

　なお、本実施形態では、ノンプライマリクラスタに属したノードにおいてもデータベースのサービスを提供する一方、障害復旧時には、当該ノードにおいてロールバックが行われるため、ノンプライマリクラスタに属していた間に当該ノードのデータベースに対して書き込まれた内容は破棄されることとなる。そのため、ノンプライマリクラスタに属したノードは、「データベースに対する書き込み動作を行ったとしても、障害復旧時にその内容が破棄される」旨の通知を、ユーザー端末８に行うようにしてもよい。

　上述の通り、本実施形態に係るクラスタシステムによれば、自グループがクラスタを再構成するグループに決定されなかった場合でもデータベースのサービスを提供し、障害が復旧すると、自ノードのデータベースをプライマリクラスタに属するノードのデータベースに同期させる。そのため、クラスタを再構成するグループに属さないノードにおいてもデータベースのサービスを提供しつつ、クラスタにおけるデータの整合性を図ることが可能となる。具体的には、クラスタを再構成しないグループに属するノードにおいて、データベースのバックアップ及びリストアを適切なタイミングで実施することにより、障害復旧時に当該ノード（ノンプライマリクラスタ）で行われた変更をロールバックし、その後、プライマリクラスタから必要なデータを同期することで、クラスタ全体のデータの整合性を図ることが可能となる。つまり、障害が発生した際に、本来はクラスタ３を再構成しないグループと判定されて動作継続不可となるノードを一旦延命した上で、障害が復旧した際にはクラスタ（プライマリクラスタ）へ再度参加することが可能となる。このように、本実施形態に係るクラスタシステムによれば、クラスタを適切に管理することが可能である。

　また、図１５の例では、従来の多数決機構によりクラスタ３を再構成するグループを決定する場合、拠点１のノード数は２、拠点２のノード数は１となり、拠点１のノード数が元のプライマリクラスタ（クラスタ３）の総ノード数３の半数を超えるため、拠点１の各ノードはプライマリクラスタに属するノードとして動作を継続し、拠点２のノードはノンプライマリクラスタに属するノードであるため動作継続不可となる。しかし、データベースに対して行われるアクセスが概ね読み込み動作（Ｒｅａｄ動作）である場合等は、拠点２のように過半数を獲得できなかったグループのノードについても動作を継続できることが望ましい。対して、本実施形態に係るクラスタシステムによれば、クラスタ３を再構成しないグループと決定されたグループに属するノードにおいても、一時的な（書き込まれた内容は後に破棄される）データベースとして動作を継続させ、障害が復旧した後には速やかにクラスタ（プライマリクラスタ）に参加させることが可能となる。

　また、ノードにおいて、定期的にデータベースのバックアップを取得する場合、クラスタ内で不整合が生じているデータのバックアップを取得してしまうことは不適切であるが、本実施形態によれば、ノンプライマリクラスタに属する間はバックアップ処理を無効化するため、不適切なバックアップデータの取得を回避することが可能である。

　［第三の実施形態］
　次に、第三の実施形態を説明する。第三の実施形態では、上記第一の実施形態及び第二の実施形態で説明した内容と重複する項目については、同一の符号を付して説明を省略する。本実施形態では、第一の実施形態で例示されたクラスタシステムと、第二の実施形態で例示されたクラスタシステムとを組み合わせた実施態様について説明する。具体的には、第一の実施形態で例示された、平時に取得した各ノードの使用情報を用いることで、自グループを、クラスタを再構成するグループとするかを決定する処理が行われ、第二の実施形態で例示された、自グループが前記クラスタを再構成するグループと決定されなかった場合にもデータベースのサービスを提供し、障害が復旧すると、プライマリクラスタとの同期を行う処理が行われる実施態様を説明する。

　本実施形態に係るシステムの構成は、図１を参照して第一の実施形態で説明したシステム構成及び図１２を参照して第二の実施形態で説明したシステム構成の何れの構成であってもよい。なお、システム構成の詳細は、第一の実施形態及び第二の実施形態で説明した詳細と同様であるため、その説明を省略する。以下、本実施形態に係る各ノード１の機能構成について説明する。

　図２１は、本実施形態に係るノードの機能構成の概略を示す図である。ノード１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、ノード１に備えられた各ハードウェアが制御されることで、管理情報記憶部２１、使用情報取得部２２、使用情報送信部２３、評価値算出部２４、状態検知部２５、決定部２６、障害検知部２７、設定部２８、サービス提供部２９、再接続部３０、更新情報送受信部３１、更新データ特定部３２、更新データ送受信部３３、同期部３４、バックアップ部４０、バックアップ制御部４１及びリストア部４２を備える装置として機能する。

　なお、上述した各機能部についての詳細は、第一の実施形態及び第二の実施形態で説明したものと同様であるため、その説明を省略する。例えば、管理情報記憶部２１は、第一の実施形態及び第二の実施形態で示した情報を含む管理情報を記憶する。また、使用情報取得部２２、使用情報送信部２３、評価値算出部２４、状態検知部２５、決定部２６、障害検知部２７及び再接続部３０の詳細は、第一の実施形態で説明したものと同様である。また、設定部２８、サービス提供部２９、更新情報送受信部３１、更新データ特定部３２、更新データ送受信部３３、同期部３４、バックアップ部４０、バックアップ制御部４１及びリストア部４２は、第二の実施形態における説明と同様である。

　次に、本実施形態に係る処理の流れについて説明する。まず、本実施形態では、各ノード１において、平時に、評価値更新処理とバックアップ処理とが行われる。なお、評価値更新処理の流れの概要は、図９を参照して第一の実施形態で説明した評価値更新処理の流れ（ステップＳ１０１～ステップＳ１０６）の概要と同様であるため、処理の説明を省略する。また、バックアップ処理の流れの概要は、図１８を参照して第二の実施形態で説明したバックアップ処理の流れ（ステップＳ４０１～ステップＳ４０２）の概要と同様であるため、処理の説明を省略する。

　そして、本実施形態では、障害発生が検知されると（クラスタ３が複数のグループに分割されると）、まずクラスタを再構成するグループを決定する処理が行われ、その後、バックアップ無効化処理が行われる。つまり、第一の実施形態に示された方法により、自グループを、クラスタ３を再構成するグループとするかが決定される。そして、自グループがクラスタ３を再構成するグループと決定されなかった場合は、第二の実施形態に示された方法により、データベースのサービスを提供（継続）し、障害復旧時には、リストア及び同期が行われる。なお、自グループを、クラスタ３を再構成するグループとするかを決定する処理の流れの概要は、図１０を参照して第一の実施形態で説明した決定処理の流れ（ステップＳ２０１～ステップＳ２０７）の概要と同様であるため、処理の説明を省略する。また、バックアップ無効化処理の流れの概要は、図１９を参照して第二の実施形態で説明したバックアップ無効化処理の流れ（ステップＳ５０１～ステップＳ５０２）の概要と同様であるため、処理の説明を省略する。

　そして、本実施形態では、障害が復旧すると（自ノードが再度クラスタに参加可能な状態であると）、リストア及び同期が行われる。なお、これらの処理の流れの概要は、図２０を参照して第二の実施形態で説明した同期処理の流れ（ステップＳ６０１～ステップＳ６０５）の概要と同様であるため、処理の説明を省略する。

　以上より、平時に取得した各ノードの使用情報を用いることで、自ノードが属するグループを、クラスタを再構成するグループとするかを決定し、自グループが前記クラスタを再構成するグループと決定されなかった場合にもデータベースのサービスを提供しつつ、クラスタ内のデータの整合性を図ることが可能となる。

　　　１（１ａ、１ｂ、１ｃ、１ｄ）　ノード装置（ノード）
　　　３　クラスタ
　　　８　ユーザー端末
　　　９　クラスタシステム

Claims

　マルチマスタ構成のクラスタを構成する複数のノード装置のうちのノード装置であって、
　前記クラスタが複数のグループに分割された際に、自ノード装置を含む自グループが、前記クラスタを再構成するグループに決定されなかった場合であっても、自ノード装置のデータベースのサービスを提供するサービス提供手段と、
　前記自グループが前記クラスタを再構成するグループではなく、自ノード装置が前記クラスタに再度参加可能な状態である場合、自ノード装置のデータベースを、前記クラスタを再構成するグループに属する他のノード装置のデータベースに同期させる同期手段と、
　を備えるノード装置。
　自ノード装置のデータベースのバックアップを繰り返し行うバックアップ手段と、
　前記クラスタが複数のグループに分割された際に、前記自グループが前記クラスタを再構成するグループに決定されなかった場合、前記バックアップを行う処理を無効化するバックアップ制御手段と、を更に備える、
　請求項１に記載のノード装置。
　前記自グループが前記クラスタを再構成するグループでなく、自ノード装置が前記クラスタに再度参加可能な状態である場合、前記無効化の前に行われた前記バックアップにより得られたバックアップデータにより、自ノード装置のデータベースのリストアを行うリストア手段を更に備え、
　前記同期手段は、前記リストアが行われた後に、自ノード装置のデータベースを同期させる、
　請求項２に記載のノード装置。
　前記無効化の前に行われた前記バックアップは、前記無効化の前に最後に行われた前記バックアップである、
　請求項３に記載のノード装置。
　前記クラスタを再構成するグループに属する他のノード装置のデータベースに含まれるデータを受信する更新データ送受信手段を更に備え、
　前記同期手段は、受信された前記データを用いて、自ノード装置のデータベースを同期させる、
　請求項３又は４に記載のノード装置。
　前記クラスタを再構成するグループに属する他のノード装置のデータベースに含まれるデータは、該他のノード装置のデータベースと、前記リストアが行われた自ノード装置のデータベースとの差分データである、
　請求項５に記載のノード装置。
　前記クラスタを再構成するグループに属する他のノード装置のデータベースに含まれるデータは、該他のノード装置のデータベースのフルデータである、
　請求項５に記載のノード装置。
　前記バックアップ制御手段は、前記同期が終了すると、前記バックアップを行う処理を有効化する、
　請求項２～７の何れか一項に記載のノード装置。
　前記バックアップ手段は、所定期間毎に前記バックアップを行う、
　請求項２～８の何れか一項に記載のノード装置。
　前記データベースのサービスは、該データベースに対する書き込みリクエスト及び／又は読み込みリクエストに対するサービスである、
　請求項１～９の何れか一項に記載のノード装置。
　前記自グループは、自ノード装置と通信可能なノード装置と、自ノード装置とで構成されるグループである、
　請求項１～１０の何れか一項に記載のノード装置。
　夫々が前記複数のノード装置夫々についての使用状況を示す、該複数のノード装置の使用情報を繰り返し取得する使用情報取得手段と、
　前記クラスタが複数のグループに分割されると、該クラスタが分割される前に取得された前記複数のノード装置の使用情報に夫々対応する、前記複数のノード装置の評価値を用いることで、自ノード装置を含む自グループを、前記クラスタを再構成するグループとするかを決定する決定手段と、を更に備え、
　前記サービス提供手段は、前記複数のノード装置の評価値を用いることで前記自グループが前記クラスタを再構成するグループに決定されなかった場合であっても、自ノード装置のデータベースのサービスを提供する、
　請求項１～１１の何れか一項に記載のノード装置。
　マルチマスタ構成のクラスタを構成する複数のノード装置のうちのノード装置が、
　前記クラスタが複数のグループに分割された際に、自ノード装置を含む自グループが、前記クラスタを再構成するグループに決定されなかった場合であっても、自ノード装置のデータベースのサービスを提供するステップと、
　前記自グループが前記クラスタを再構成するグループではなく、自ノード装置が前記クラスタに再度参加可能な状態である場合、自ノード装置のデータベースを、前記クラスタを再構成するグループに属する他のノード装置のデータベースに同期させるステップと、を実行する、
　クラスタ管理方法。
　マルチマスタ構成の第一のクラスタを構成する複数のノード装置のうちのノード装置を、
　前記クラスタが複数のグループに分割された際に、自ノード装置を含む自グループが、前記クラスタを再構成するグループに決定されなかった場合であっても、自ノード装置のデータベースのサービスを提供するサービス提供手段と、
　前記自グループが前記クラスタを再構成するグループではなく、自ノード装置が前記クラスタに再度参加可能な状態である場合、自ノード装置のデータベースを、前記クラスタを再構成するグループに属する他のノード装置のデータベースに同期させるとして機能させる、
　プログラム。
　複数のノード装置で構成されるマルチマスタ構成の第一のクラスタを備えるクラスタシステムであって、
　前記複数のノード装置は、夫々、
　前記クラスタが複数のグループに分割された際に、自ノード装置を含む自グループが、前記クラスタを再構成するグループに決定されなかった場合であっても、自ノード装置のデータベースのサービスを提供するサービス提供手段と、
　前記自グループが前記クラスタを再構成するグループではなく、自ノード装置が前記クラスタに再度参加可能な状態である場合、自ノード装置のデータベースを、前記クラスタを再構成するグループに属する他のノード装置のデータベースに同期させる同期手段と、
　を備えるクラスタシステム。