(57)【要約】【課題】プライマリサーバと同期状態にあるサーバへのアクセスを精度良く行なう。【解決手段】端末の接続先となる複数のサーバ２を含むサーバ群において、前記サーバ群に含まれる１又は複数のサーバ２の状態の変化を検知した場合に、前記変化を検知した後の前記サーバ群に含まれるサーバ２から、前記変化を検知した後のプライマリサーバ２Ａに対し同期スタンバイの状態であるサーバ２Ｂを特定し、前記端末に対し、特定した前記サーバ２Ｂへの接続を要求する、処理をコンピュータに実行させる。【選択図】図１４
2019191843.tif 000002
【特許請求の範囲】
【請求項１】
端末が接続を行なうサーバの制御を行なう接続制御プログラムであって、
前記端末の接続先となる複数のサーバを含むサーバ群において、前記サーバ群に含まれる１又は複数のサーバの状態の変化を検知した場合に、前記変化を検知した後の前記サーバ群に含まれるサーバから、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定し、
前記端末に対し、特定した前記サーバへの接続を要求する、
処理をコンピュータに実行させることを特徴とする、接続制御プログラム。
【請求項２】
前記サーバの状態の変化は、フェイルオーバ、フォールバック、及び、サーバの同期状態、の少なくとも一つに関連する変化であることを特徴とする、請求項１に記載の接続制御プログラム。
【請求項３】
前記端末が接続中のサーバの状態の変化を検知した場合に、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定し、
前記端末に対し、特定した前記サーバへの接続を要求する、
処理を前記コンピュータに実行させることを特徴とする、請求項１又は請求項２に記載の接続制御プログラム。
【請求項４】
前記変化を検知した場合に、前記端末に対し、前記サーバ群に含まれるサーバとの接続の切断を要求する、
処理を前記コンピュータに実行させることを特徴とする、請求項１〜３のいずれか１項に記載の接続制御プログラム。
【請求項５】
前記端末が接続中のサーバの状態の変化を検知した場合に、前記サーバ群に含まれるサーバとの切断を要求する、
処理を前記コンピュータに実行させることを特徴とする、請求項１〜４のいずれか１項に記載の接続制御プログラム。
【請求項６】
前記変化は、ログ転送時間の変化に基づいた、プライマリサーバに対して同期スタンバイの状態となるサーバの変化を含むことを特徴とする、請求項１〜５のいずれか１項に記載の接続制御プログラム。
【請求項７】
端末が接続を行なうサーバの制御を行なう接続制御方法であって、
コンピュータのプロセッサが、
前記端末の接続先となる複数のサーバを含むサーバ群において、前記サーバ群に含まれる１又は複数のサーバの状態の変化を検知した場合に、前記変化を検知した後の前記サーバ群に含まれるサーバから、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定し、
前記端末に対し、特定した前記サーバへの接続を要求する、
ことを特徴とする、接続制御方法。
【請求項８】
端末が接続を行なうサーバの制御を行なう接続制御装置であって、
前記端末の接続先となる複数のサーバを含むサーバ群において、前記サーバ群に含まれる１又は複数のサーバの状態の変化を検知した場合に、前記変化を検知した後の前記サーバ群に含まれるサーバから、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定する特定部と、
前記端末に対し、特定した前記サーバへの接続を要求する要求部と、をそなえることを特徴とする、接続制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、接続制御プログラム、接続制御方法、及び接続制御装置に関する。
【背景技術】
【０００２】
複数のノード、例えば複数のＤＢ（Database）サーバにより多重化環境を構成するクラスタシステムでは、クラスタシステムを構成するノード数に見合った可用性向上を実現するために、マルチ同期スタンバイ機能が用いられることがある。
【０００３】
マルチ同期スタンバイ機能は、プライマリサーバ、及び、１以上のスタンバイサーバをそなえるログシッピング方式の多重化環境において、ノードに異常が発生した場合にクラスタ構成を縮退し、プライマリサーバでの業務継続を実現する技術である。マルチ同期スタンバイ機能において採用される手法としては、例えば、フェイルオーバ及びフォールバック等が知られている。
【０００４】
フェイルオーバは、プライマリサーバが故障した場合に、いずれかのスタンバイサーバをプライマリサーバに切り替えて、新プライマリサーバで業務を継続する手法である。フェイルオーバでは、プライマリサーバが故障する都度、アクティブなスタンバイサーバが無くなるまで、スタンバイサーバからプライマリサーバへの切り替えが行なわれる。
【０００５】
なお、スタンバイサーバをプライマリサーバに「切り替える」とは、スタンバイサーバとして動作するノードに対して、プライマリサーバとして動作するように機能を切り替える（制御する）ことを意味してよい。
【０００６】
フォールバックは、スタンバイサーバが故障した場合に、故障したスタンバイサーバを縮退し、残りのスタンバイサーバによってＤＢの冗長化を担保する手法である。
【０００７】
プライマリサーバは、端末からクラスタシステムのＤＢに対する更新業務が行なわれると、更新トランザクションにおいて、プライマリサーバのＤＢを更新するとともに、当該更新をスタンバイサーバのＤＢに反映させるための同期処理を行なう。更新トランザクションは、フェイルオーバ後のデータ保全に向けて、同期処理におけるスタンバイサーバへのログシッピングが保証された時点で完了する。
【０００８】
ログシッピングが保証されたスタンバイサーバ（以下、「同期スタンバイサーバ」と表記する）は、プライマリサーバとの間でデータの同期が保証されるため、例えば、端末による同期データの参照先候補や、フェイルオーバの際のサーバ切替先の候補となる。クラスタシステムの可用性、例えば、フェイルオーバ中の新たな障害（同時障害）等に対する可用性は、同期スタンバイサーバ数の増加に比例して向上する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００４−２０６５６２号公報
【特許文献２】特開２００９−１２２８７３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
同期スタンバイサーバ数が増加すると、同期処理の対象が増加することによりプライマリサーバの処理負荷が増加し、ＤＢの更新性能が低下する場合がある。
【００１１】
ＤＢの更新性能の低下を回避するために、クラスタシステムにおける同期スタンバイサーバ数を制限することも考えられる。例えば、同期スタンバイサーバの待機サーバとして非同期スタンバイサーバが設けられることがある。プライマリサーバは、更新トランザクションにおいて、非同期スタンバイサーバに対するログシッピングの保証を行なわない（データ同期を保証しない）。このため、プライマリサーバと非同期スタンバイサーバとの間の同期処理では、プライマリサーバの処理負荷の増加が抑制される。
【００１２】
非同期スタンバイサーバは、例えば、障害の発生したサーバの復旧中に他のサーバで発生した新たな障害（連続障害）に備えて待機し、可用性を維持するために用いられてよい。
【００１３】
これらのスタンバイサーバの同期モードは、クラスタシステムのデータベース管理システム（ＤＢＭＳ；Database Management System）によって管理される。例えば、ＤＢＭＳは、サーバ障害に応じてフェイルオーバやフォールバックを行なう際に、同期スタンバイ及び非同期スタンバイ間で、サーバの同期モードを切り替えることがある。
【００１４】
ところで、端末からクラスタシステムのＤＢに対して、同期データを参照する参照業務が行なわれる場合、例えば、アプリケーション（ＡＰ；Application）サーバで動作するＡＰは、同期スタンバイサーバに対してアクセスする。
【００１５】
しかしながら、上述のように、サーバの同期モードはＤＢＭＳが管理するため、ＡＰサーバは、ＤＢＭＳによるサーバの同期モードの切り替えに追従できない場合がある。すなわち、端末は、同期データを参照する参照業務において、適切な同期スタンバイサーバにアクセスすることが困難になる場合がある。
【００１６】
１つの側面では、本発明は、プライマリサーバと同期状態にあるサーバへのアクセスを精度良く行なうことを目的とする。
【課題を解決するための手段】
【００１７】
１つの側面では、接続制御プログラムは、端末が接続を行なうサーバの制御を行なってよく、以下の処理をコンピュータに実行させてよい。前記処理は、前記端末の接続先となる複数のサーバを含むサーバ群において、前記サーバ群に含まれる１又は複数のサーバの状態の変化を検知した場合に、前記変化を検知した後の前記サーバ群に含まれるサーバから、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定してよい。また、前記処理は、前記端末に対し、特定した前記サーバへの接続を要求してよい。
【発明の効果】
【００１８】
１つの側面では、プライマリサーバと同期状態にあるサーバへのアクセスを精度良く行なうことができる。
【図面の簡単な説明】
【００１９】
【図１】比較例に係るクラスタシステムの動作例を示す図である。
【図２】比較例に係るクラスタシステムの動作例を示す図である。
【図３】一実施形態に係るクラスタシステムの構成例を示すブロック図である。
【図４】一実施形態に係るクラスタシステムの機能構成例を示すブロック図である。
【図５】一実施形態に係るＤＢサーバの機能構成例を示すブロック図である。
【図６】（ａ）はノード情報の一例を示す図であり、（ｂ）はノードリストの一例を示す図である。
【図７】一実施形態に係るＤＢインスタンスの状態遷移の一例を示す図である。
【図８】性能情報の一例を示す図である。
【図９】集計情報の一例を示す図である。
【図１０】サーバの状態遷移に応じた処理の一例を示す図である。
【図１１】一実施形態に係るＡＰサーバの機能構成例を示すブロック図である。
【図１２】接続候補情報の一例を示す図である。
【図１３】一実施形態に係るＤＢサーバによる同期モード切替処理の動作例を示すフローチャートである。
【図１４】一実施形態に係るクラスタシステムの動作例を示す図である。
【図１５】一実施形態に係るＤＢサーバのクラスタ制御部によるフェイルオーバ処理の動作例を示すフローチャートである。
【図１６】一実施形態に係るＤＢサーバのクラスタ制御部によるフォールバック処理の動作例を示すフローチャートである。
【図１７】一実施形態に係るＤＢサーバのクラスタ制御部によるサーバ起動処理の動作例を示すフローチャートである。
【図１８】一実施形態に係るＤＢサーバの連携制御部による連携処理の動作例を示すフローチャートである。
【図１９】一実施形態に係るＡＰサーバのクラスタ制御部による接続先切替処理の動作例を示すフローチャートである。
【図２０】一実施形態に係るＡＰサーバのクラスタ制御部による接続先振分処理の動作例を示すフローチャートである。
【図２１】一実施形態に係るコンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【００２０】
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。例えば、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。
【００２１】
〔１〕一実施形態
〔１−１〕比較例
はじめに、図１及び図２を参照して、一実施形態の比較例について説明する。図１は、比較例に係るクラスタシステム１００Ａの動作例を示し、図２は比較例に係るクラスタシステム１００Ｂの動作例を示す。
【００２２】
なお、図１に示すクラスタシステム１００Ａは、ノードリスト２０１を用いて同期スタンバイサーバを管理し、図２に示すクラスタシステム１００Ｂは、クォーラム技術を利用して同期スタンバイサーバを管理する。
【００２３】
まず、図１に示すように、クラスタシステム１００Ａにおいて同期スタンバイサーバが切り離される場合の動作例を説明する。
【００２４】
プライマリサーバの一例であるマスタサーバ２００Ａと、スタンバイサーバ２００Ｂ−１〜２００Ｂ−ｎ（ｎ；２以上の整数）とには、それぞれ、ノードリスト２０１が設定・格納される（符号（１）参照）。
【００２５】
なお、以下、スタンバイサーバ２００Ｂ−１〜２００Ｂ−ｎを区別しない場合には、単にスタンバイサーバ２００Ｂと表記し、マスタサーバ２００Ａ及びスタンバイサーバ２００Ｂを区別しない場合には単にサーバ２００と表記する。
【００２６】
ノードリスト２０１は、例えば、ログ転送レイテンシが小さい順にスタンバイサーバ２００Ｂをソートしたリストである。システム管理者は、スタンバイサーバ２００Ｂごとの日々のログ転送レイテンシを分析してノードリスト２０１を作成し、作成したノードリスト２０１を各サーバ２００に設定してよい。マスタサーバ２００ＡのＤＢＭＳは、ノードリスト２０１に基づき、例えばログ転送レイテンシの小さい所定数のスタンバイサーバ２００Ｂを同期スタンバイサーバとして選択する。
【００２７】
図１の例において、端末等による更新業務が発生すると、マスタサーバ２００Ａは更新トランザクションを実行する（符号（２）参照）。マスタサーバ２００Ａは、更新トランザクションにおいて、ＤＢ２０２に対する更新処理を行なうとともに、スタンバイサーバ２００Ｂに対する同期処理を行なう。
【００２８】
例えば、マスタサーバ２００Ａは、同期処理において、更新処理に係る更新結果の情報（例えばＷＡＬ２０３等の更新ログ）を、スタンバイサーバ２００Ｂの各々に対して転送（例えばブロードキャスト）する（符号（３）参照）。
【００２９】
「ＷＡＬ」は、Write Ahead Logging（ログ先行書き込み）の略称であり、ＤＢ２０２への書き込みに先立って書き出されるトランザクションのログである。以下、同期処理がＷＡＬを用いて行なわれるものとして説明する。
【００３０】
各スタンバイサーバ２００Ｂは、マスタサーバ２００ＡからＷＡＬ２０３を受信すると、更新ログの転送が完了したことを示す応答（ログ転送完了応答）をマスタサーバ２００Ａに送信する（符号（４）参照）。なお、各スタンバイサーバ２００Ｂは、受信したＷＡＬ２０３に基づき自身のＤＢ２０２を更新することで、マスタサーバ２００ＡのＤＢ２０２を複製する。
【００３１】
マスタサーバ２００Ａは、ノードリスト２０１に基づき同期スタンバイサーバとして選択した所定数の全てのスタンバイサーバ２００Ｂから応答を受信すると、更新トランザクションを終了する（符号（５）参照）。
【００３２】
マスタサーバ２００Ａ及びスタンバイサーバ２００Ｂは、ＤＢＭＳにより、更新業務が発生する都度、上記符号（２）〜（５）の処理を繰り返す。また、スタンバイサーバ２００Ｂのうちの同期スタンバイサーバでは、更新業務と並行して（非同期に）、端末等から同期データの参照業務が発生することがある（符号（７）参照）。
【００３３】
ここで、マスタサーバ２００Ａとスタンバイサーバ２００Ｂ−１との間の回線故障等が発生した場合、マスタサーバ２００Ａは、ＤＢＭＳにより、フォールバックによりスタンバイサーバ２００Ｂ−１を切り離す（符号（６）参照）。
【００３４】
このようなスタンバイサーバ２００Ｂ−１の切り離しが、符号（２）〜（５）及び（７）のいずれかの処理の実行中に行なわれた場合、上記符号（７）の同期データの参照業務において、切り離しが検知されないことがある。この場合、参照業務では、スタンバイサーバ２００Ｂ−１のＤＢ２０２から、マスタサーバ２００Ａと同期されていない過去データが参照されることになる。
【００３５】
次に、図２に示すように、クラスタシステム１００Ｂにおいて同期スタンバイサーバが切り離される場合の動作例を説明する。
【００３６】
クラスタシステム１００Ｂは、各サーバ２００にノードリスト２０１が設定されるクラスタシステム１００Ａとは異なり、システム管理者により、マスタサーバ２００Ａに対して同期スタンバイ数が設定される（符号（１）参照）。
【００３７】
符号（２）〜（４）の処理は、図１の説明と同様である。符号（５）において、マスタサーバ２００Ａは、ＤＢＭＳにより、設定された同期スタンバイ数以上の応答をスタンバイサーバ２００Ｂから受信すると、更新トランザクションを終了する。換言すれば、クラスタシステム１００Ｂにおいて、同期スタンバイサーバは、更新トランザクションごとに、スタンバイサーバ２００Ｂの中から応答の先着順に決定される。
【００３８】
このように、クラスタシステム１００Ｂでは、更新トランザクションごとに同期スタンバイサーバが入れ替わることになるため、同期データの参照業務が発生した場合に（符号（６）参照）、同期データの参照先の同期スタンバイサーバが不明となる。
【００３９】
以上のように、図１及び図２に示す例では、マスタサーバ２００Ａにおける更新業務の安定稼働を目的に、ＤＢＭＳが主導で同期スタンバイサーバを選択するため、図示しないＡＰサーバを介して実行される参照業務との連携がとれない場合がある。このため、同期スタンバイサーバの状態が変化した場合に、同期データの参照業務から当該変化が検知できずに、過去のデータが参照されてしまうことがある。
【００４０】
そこで、後述する一実施形態では、マスタサーバと同期状態にあるサーバへのアクセスを精度良く行なう手法について説明する。
【００４１】
〔１−２〕クラスタシステムの構成例
図３は、一実施形態の一例としてのクラスタシステム１の構成例を示すブロック図である。クラスタシステム１は、端末が接続を行なうサーバの制御を行なう接続制御装置の一例であり、図１に示すように、例示的に、ノード２Ａと、複数（図３の例ではｎ台）のノード２Ｂ−１〜２Ｂ−ｎと、１以上（図３の例では１台）のノード３と、をそなえる。
【００４２】
以下、ノード２Ｂ−１〜２Ｂ−ｎを区別しない場合には、単にノード２Ｂと表記する。また、ノード２Ａ及びノード２Ｂを区別しない場合には、ノード２、サーバ２、或いは、ＤＢサーバ２と表記する。
【００４３】
複数（図３の例ではｎ＋１台）のノード２の各々は、例えば、ＤＢＭＳ等のソフトウェアがインストールされ、マルチ同期スタンバイ機能を利用可能なＤＢサーバである。クラスタシステム１では、複数のノード２において実行されるＤＢＭＳによって、ＤＢの多重化環境が実現されてよい。
【００４４】
複数のノード２間は、インターコネクト、例えばＬＡＮ（Local Area Network）等のネットワーク１ａにより、相互に通信可能に接続されてよい。
【００４５】
ノード２は、「マスタサーバ」、「同期スタンバイサーバ」、及び「非同期スタンバイサーバ」、のいずれか１つの種別の機能（役割）を可変的に割り当てられ、割り当てられた種別のサーバとして動作してよい。
【００４６】
図３の例では、１台のノード２Ａがマスタサーバとして動作し、ｎ台のノード２Ｂ−１〜２Ｂ−ｎが同期スタンバイサーバ及び非同期スタンバイサーバを含むスタンバイサーバとして動作するものとする。
【００４７】
マスタサーバ２Ａは、ＤＢのマスタデータを管理する運用系ノード（プライマリサーバ）の一例である。マスタサーバ２Ａは、ＤＢの更新業務が発生すると、更新トランザクションを実行する。マスタサーバ２Ａは、更新トランザクションにおいて、マスタサーバ２Ａが有するＤＢの更新処理を行なうとともに、スタンバイサーバ２Ｂに対する同期処理を行なう。
【００４８】
複数のスタンバイサーバ２Ｂは、ＤＢの同期データの参照業務において、端末４の接続先となる同期スタンバイサーバを含むサーバ群の一例である。
【００４９】
スタンバイサーバ２Ｂのうちの同期スタンバイサーバは、運用系ノードの予備である待機系ノード群であって、マスタサーバ２Ａのデータを同期方式でバックアップすることで、マスタサーバ２Ａに対し同期スタンバイの状態となるサーバの一例である。
【００５０】
スタンバイサーバ２Ｂのうちの非同期スタンバイサーバは、待機系ノード群の予備である非同期待機系ノード群であって、マスタサーバ２Ａのデータを非同期でバックアップすることで、マスタサーバ２Ａに対し非同期スタンバイの状態となるサーバの一例である。
【００５１】
なお、スタンバイサーバ２Ｂは、参照業務において、端末４からの参照指示に基づき、ＤＢからユーザデータの少なくとも一部を読み出し、読み出したデータを端末４に応答してよい。
【００５２】
なお、クラスタシステム１の運用設定によっては、マスタサーバ２Ａに対する同期データの参照業務が許容される場合もある。この場合、マスタサーバ２Ａにおいて、スタンバイサーバ２Ｂと同様に参照業務に係る処理が行なわれてもよい。
【００５３】
ＤＢの参照業務は、マスタサーバ２ＡのＤＢとのデータ同期がとれたリアルタイムなデータが期待される「同期データの参照業務」と、マスタサーバ２ＡのＤＢとは非同期でもよい「過去データ等の参照業務」と、を含んでよい。例えば、「同期データの参照業務」は、同期スタンバイサーバ（又はマスタサーバ２Ａ）に対するアクセスにより実行される。また、「過去データ等の参照業務」は、非同期スタンバイサーバ（又は、マスタサーバ２Ａ或いは同期スタンバイサーバ）に対するアクセスにより実行される。
【００５４】
マスタサーバ２Ａ及びスタンバイサーバ２Ｂによる更新処理及び同期処理は、図１又は図２に示すマスタサーバ２００Ａ及びスタンバイサーバ２００Ｂによる処理と同様であってよい。一実施形態においては、マスタサーバ２Ａ及びスタンバイサーバ２Ｂによる更新処理及び同期処理が、図１に示すマスタサーバ２００Ａによる処理と同様に、ノードリスト２１３（図６（ｂ）参照）を参照する手法によって実行されるものとする。
【００５５】
ノード３は、例えばアプリケーション（ＡＰ）サーバである。ノード３は、端末４或いは他の端末に対するクラスタシステム１へのインタフェース（Interface；ＩＦ）を提供してよい。以下の説明において、ノード３を「ＡＰサーバ３」と表記する場合がある。
【００５６】
なお、図３の例では、クラスタシステム１が１台のＡＰサーバ３をそなえるものとして示すが、これに限定されるものではなく、クラスタシステム１は、複数のＡＰサーバ３を冗長化構成、例えばクラスタ構成としてそなえてもよい。
【００５７】
ＡＰサーバ３と複数のＤＢサーバ２の各々との間は、ネットワーク１ｂにより相互に通信可能に接続されてよい。ネットワーク１ｂは、ネットワーク１ａと同一の、又は、異なるインターコネクト（例えばＬＡＮ）等であってよい。
【００５８】
端末４は、クラスタシステム１が提供するＤＢの利用者が使用するコンピュータである。端末４としては、ＰＣ（Personal Computer）、サーバ、スマートホン、或いはタブレット等の情報処理装置が挙げられる。端末４は、例えば、ネットワーク５及びＡＰサーバ３を経由して、ＤＢサーバ２に対してアクセスすることで、ＤＢの更新業務又は参照業務を実行してよい。
【００５９】
ネットワーク５は、例えば、ＬＡＮ或いはＷＡＮ（Wide Area Network）、又はこれらの組み合わせを含む、インターネット及びイントラネットの少なくとも一方であってよい。また、ネットワーク５は、ＶＰＮ（Virtual Private Network）等の仮想ネットワークを含んでもよい。なお、ネットワーク５は、有線ネットワーク及び無線ネットワークの一方又は双方により形成されてよい。
【００６０】
〔１−３〕構成例
次に、クラスタシステム１における機能構成例について説明する。
【００６１】
図４は、クラスタシステム１の機能構成例を示すブロック図である。図４に示すように、クラスタシステム１は、例示的に、複数のノード２におけるＤＢ側クラスタ機能２０と、ＡＰサーバ３におけるＡＰ側クラスタ機能３０と、ＤＢ側クラスタ機能２０とＡＰ側クラスタ機能３０との連携を行なう連携機能６０と、を有してよい。
【００６２】
ＤＢ側クラスタ機能２０は、マスタサーバ２Ａで実行されるクラスタプロセス２０Ａと、各スタンバイサーバ２Ｂで実行されるクラスタプロセス２０Ｂと、を含んでよい。
【００６３】
また、ＡＰ側クラスタ機能３０は、ＡＰサーバ３で実行される１以上のクラスタプロセス３０Ａを含んでよい。なお、クラスタプロセス３０Ａは、端末４から同期データの参照業務を受け付け、当該参照業務を処理して処理結果を含む応答を端末４に送信する。
【００６４】
連携機能６０は、例えば、ノード２又はノード３により実行されるソフトウェアであってもよいし、ノード２及び３に分散して配置され、これらのノード２及び３により実行されるソフトウェアであってもよい。
【００６５】
ＤＢ側クラスタ機能２０、ＡＰ側クラスタ機能３０、及び連携機能６０は、ＤＢＭＳではなく、クラスタの制御や管理等を行なうクラスタソフトウェアにより実現されてよい。例えば、一実施形態に係るクラスタシステム１は、マスタサーバ２Ａにおける更新業務の安定化と、スタンバイサーバ２Ｂにおける同期データの参照業務の安定化とを両立させるために、ＤＢＭＳではなくクラスタ機能によって、以下の処理を行なってよい。
【００６６】
（１）ＤＢ側クラスタ機能２０は、非同期スタンバイから同期スタンバイへの昇格、及び、同期スタンバイから非同期スタンバイ或いは停止状態への降格、の選択基準として、スタンバイサーバ２Ｂのログ転送効率を利用する。
【００６７】
（２）ＤＢ側クラスタ機能２０は、非同期スタンバイから同期スタンバイへの昇格、及び、同期スタンバイから非同期スタンバイ或いは停止状態への降格、の制御及び管理を行なう。
【００６８】
（３）ＡＰ側クラスタ機能３０は、同期データの参照業務をクラスタ機能経由で実施する。
【００６９】
（４）連携機能６０は、上記の（２）及び（３）を連携させる。
【００７０】
ＤＢ側クラスタ機能２０は、上記（１）及び（２）により、フェイルオーバやフォールバックの制御を最適化することで更新業務等の業務継続を実現でき、また、同期スタンバイサーバの適切な選択等による業務安定稼働を実現できる。
【００７１】
連携機能６０は、上記（４）により、例えば、上記（１）及び（２）においてＤＢ側クラスタ機能２０が実行したノード２の状態遷移の結果を、ＡＰ側クラスタ機能３０に通知する。また、連携機能６０は、例えば、ＡＰ側クラスタ機能３０に対して、同期スタンバイの状態遷移に応じてＡＰ再接続の依頼を行なう。
【００７２】
このように、連携機能６０がＤＢ側クラスタ機能２０とＡＰ側クラスタ機能３０とを連携させるため、ＡＰサーバ３は、データ同期がとれたスタンバイサーバ２Ｂに対して同期データの参照業務を確実に実施でき、同期データへのアクセスを保証することができる。
【００７３】
〔１−３−１〕ＤＢサーバの構成例
次に、図５を参照して、一実施形態に係るＤＢサーバ２の機能構成例を説明する。なお、図５に示すノード２は、同期モードの切り替えによって、マスタサーバ、同期スタンバイサーバ、及び非同期スタンバイサーバのいずれとしても動作可能であるため、以下、これらの同期モードの機能を包含した機能構成例を説明する。なお、クラスタの構成や環境、運用等によって、各ノード２がそなえる機能は、これらの同期モードのうちの１つ又は２つを実現するための機能に制限されてもよい。
【００７４】
図５に示すように、ノード２は、例示的に、ＤＢ２１、ＤＢ制御部２２、クラスタ制御部２３、及び、連携制御部２４をそなえてよい。
【００７５】
ＤＢ２１は、クラスタシステム１が提供するデータベースであり、業務データ等のユーザデータ２１１を格納してよい。なお、マスタサーバ２ＡのＤＢ２１が格納するユーザデータ２１１は、マスタデータとして扱われてよく、スタンバイサーバ２Ｂが格納するユーザデータ２１１は、マスタデータの同期バックアップ又は非同期バックアップとして扱われてよい。
【００７６】
また、一実施形態に係るＤＢ２１は、例えば、ノード情報２１２、ノードリスト２１３、性能情報２１４、及び、集計情報２１５を格納してよい。なお、ユーザデータ２１１、ノード情報２１２、ノードリスト２１３、性能情報２１４、及び、集計情報２１５は、１つのＤＢ２１に格納されてもよいし、複数のＤＢ２１（図示省略）に分散して格納されてもよい。
【００７７】
ＤＢ制御部２２は、上述した更新処理及び参照処理等を含む、ＤＢ２１に関する種々の制御を行なうものであり、例えば、ＤＢＭＳの一機能であってよい。
【００７８】
なお、マスタサーバ２ＡのＤＢ制御部２２は、例えば、ＤＢ２１に格納されたノード情報２１２（図６（ａ）参照）を参照することで、複数のスタンバイサーバ２Ｂの各々の同期モードを判定してよい。
【００７９】
図６（ａ）は、ノード情報２１２の一例を示す図である。図６（ａ）に示すように、ノード情報２１２は、例示的に、ノード２を識別するための識別情報、及び、当該ノード２の状態の項目を含んでよい。ノード２の状態は、同期モードに加えて、ノード２が停止した停止状態、例えばフェイルオーバやフォールバック（図６(ａ）に示す「ノード＃３」参照）等により縮退された状態を含んでよい。なお、ノード情報２１２には、「マスタ（プライマリ）」の情報（エントリ）が含まれてもよい。ノード情報２１２におけるノード２の状態は、ノード２の起動、又は、後述するクラスタ制御部２３による、同期モード切替処理、フェイルオーバ処理、フォールバック処理等に応じて更新されてよい。
【００８０】
また、マスタサーバ２Ａは、ノードリスト２１３（図６（ｂ）参照）を管理してもよい。図６（ｂ）は、ノードリスト２１３の一例を示す図である。図６（ｂ）に示すように、ノードリスト２１３は、ノード情報２１２のうち、同期モードが「同期スタンバイ」であるノード２を抽出したリストであってよい。なお、「状態」の項目は省略されてもよい。ノードリスト２１３は、例えば、更新業務において、マスタサーバ２Ａが全ての同期モードから同期処理の応答が返ってきたか否かを判断するために参照されてよい。ノードリスト２１３の内容は、ノード情報２１２の更新と同期して更新されてよい。
【００８１】
マスタサーバ２Ａは、ノード情報２１２又はノードリスト２１３により識別される「同期スタンバイ」の状態である全てのノード２から、同期処理において送信した更新ログに対する応答を受信した場合に、更新トランザクションを終了してよい。
【００８２】
クラスタ制御部２３は、ノード２の同期モードの切り替えに関する種々の制御を行なうものであり、図４に示すＤＢ側クラスタ機能２０の一例である。
【００８３】
図７は、一実施形態に係るＤＢインスタンスの状態遷移（同期モードの切り替え）の一例を示す図である。
【００８４】
図７に示すように、クラスタ制御部２３は、ノード２の障害或いは電源ＯＦＦ制御等に応じて、フェイルオーバ処理又はフォールバック処理を行ない、ノード２の状態を「マスタ」、「同期スタンバイ」又は「非同期スタンバイ」から「停止」に切り替えてよい。
【００８５】
また、クラスタ制御部２３は、ノード２の障害復旧、組み込み、或いは電源ＯＮ制御等に応じて、ノード２の状態を「停止」から「非同期スタンバイ」に切り替えてよい。なお、図７において、「停止」から「マスタ」或いは「同期スタンバイ」への矢印は、「停止」から「非同期スタンバイ」に切り替えられたノード２のその後の状態遷移により、「マスタ」或いは「同期スタンバイ」に状態が切り替わる場合があることを示している。
【００８６】
さらに、クラスタ制御部２３は、「マスタ」の状態であるノード２のフェイルオーバ処理に応じて、「同期スタンバイ」の状態である複数のノード２のうちのいずれか１つのノード２を選択して、「マスタ」の状態に切り替えてよい。「同期スタンバイ」から「マスタ」への昇格では、状態（同期モード）の再構築による更新業務への影響を抑制するために、例えば、ログ転送性能が良好な順に上位の同期スタンバイサーバが優先的に切替対象のノード２として選択されてよい。
【００８７】
なお、上述したフェイルオーバ処理やフォールバック処理に伴う状態遷移により、「同期スタンバイ」の状態であるノード２のノード数が減少することがある。この場合、クラスタ制御部２３は、「同期スタンバイ」の状態であるノード２のノード数の減少に応じて、「非同期スタンバイ」の状態であるノード２のうちのいずれか１つのノード２を選択して、「同期スタンバイ」の状態に切り替えてよい。
【００８８】
「非同期スタンバイ」から「同期スタンバイ」への昇格では、例えば、ログ転送性能が良好な順に上位（例えば最上位）の非同期スタンバイサーバが優先的に切替対象のノード２として選択されてよい。
【００８９】
さらに、クラスタ制御部２３は、「同期スタンバイ」又は「非同期スタンバイ」の状態である待機ノード群の中で、優先順に基づく状態の切り替え（再構築）を実行してよい。なお、「同期スタンバイ」及び「非同期スタンバイ」間の状態の切り替えは、例えば、マスタサーバ２Ａが管理する制御情報の変更により、業務を停止せずに実施可能である。
【００９０】
例えば、クラスタ制御部２３は、所定時間ごとに、ＤＢＭＳが収集する各スタンバイサーバ２Ｂのログ転送性能を取得し、取得したログ転送性能をＤＢ２１の性能情報２１４に格納してよい。
【００９１】
図８に性能情報２１４の一例を示す。性能情報２１４は、例示的に、ノード２の識別情報、ログ転送性能の一例としてのログ転送時間、及び、ノード２の同期モード、の項目を含んでよい。なお、性能情報２１４には、図８に示す情報に加えて、ＤＢＭＳによるログ転送性能の収集時刻を示すタイムスタンプ等、種々の情報が含まれてよい。
【００９２】
なお、ログ転送時間としては、以下の（ｉ）〜（iii）のいずれの時間が用いられてもよい。一実施形態においては、以下の（ii）の時間が用いられるものとする。
【００９３】
（ｉ）“write_lag”
“write_lag”は、マスタサーバ２ＡのＷＡＬに書き込まれた後、スタンバイサーバ２Ｂ（同期スタンバイサーバ）のＷＡＬへの書き込みが完了するまでの時間である。
【００９４】
（ii）“flush_lag”
“flush_lag”は、上記（ｉ）の“write_lag”に加えて、スタンバイサーバ２Ｂ（同期スタンバイサーバ）の不揮発化保証が完了するまでの時間である。
【００９５】
（iii）“replay_lag”
“replay_lag”は、上記（ii）の“flush_lag”に加えて、スタンバイサーバ２Ｂ（同期スタンバイサーバ）のＷＡＬが当該サーバ２ＢのＤＢ２１に反映されるまでの時間である。
【００９６】
クラスタ制御部２３は、性能情報２１４に所定期間分のログ転送性能が蓄積されると、ノード２ごとに、性能情報２１４に蓄積されたログ転送時間の平均値を転送平均時間として算出し、算出した転送平均時間をＤＢ２１の集計情報２１５に格納してよい。所定期間としては、例えば１日等の期間が挙げられる。
【００９７】
図９に集計情報２１５の一例を示す。集計情報２１５は、例示的に、ノード２の識別情報、転送平均時間、及び、ノード２の同期モード、の項目を含んでよい。なお、集計情報２１５には、図９に示す情報に加えて、転送平均時間の算出時刻（タイミング）等を示すタイムスタンプ等、種々の情報が含まれてよい。
【００９８】
クラスタ制御部２３は、集計情報２１５を参照して、「同期スタンバイ」の状態のノード２よりも、転送平均時間が小さい「非同期スタンバイ」の状態のノード２を判定する。
【００９９】
例えば、図９に示すように、「同期スタンバイ」の状態であるノード＃１の転送平均時間は“0.012913”であり、「非同期スタンバイ」の状態であるノード＃２の転送平均時間は“0.003013”である。この場合、ノード＃１よりもノード＃２の方が転送平均時間が小さく、ログ転送性能が良いノード２であるといえる。そこで、クラスタ制御部２３は、ノード＃１の同期モードを「非同期スタンバイ」に変更し、ノード＃２の同期モードを「同期スタンバイ」に変更する制御を行なうとともに、ノード情報２１２及びノードリスト２１３を更新する。
【０１００】
なお、集計情報２１５の算出（更新）及び同期モードの切り替えの処理は、所定期間分のログ転送性能が蓄積された場合に加えて、「同期スタンバイ」の状態であるノード２のログ転送時間が閾値を超えた場合に実行されてもよい。例えば、クラスタ制御部２３は、性能情報２１４の取得後に、「同期スタンバイ」の状態であるノード２のログ転送時間が閾値を超えたか否かを判定し、閾値を超えた場合に、集計情報２１５の算出（更新）及び同期モードの切り替えの処理を実行してよい。
【０１０１】
このように、クラスタ制御部２３によれば、ログ転送性能が良い非同期スタンバイサーバを同期スタンバイサーバと入れ替える（昇格させる）ことにより、同期スタンバイサーバからマスタサーバ２Ａへのログ転送レイテンシを軽減できる。従って、マスタサーバ２Ａにおける処理遅延や処理負荷を低減することができ、マスタサーバ２Ａにおける更新業務の安定稼働を実現することができる。
【０１０２】
なお、性能情報２１４及び集計情報２１５に代えて、クラスタ制御部２３は、例えば、以下のようなノード２の性能に関する統計情報に基づいて、同期モードの切り替えを行なってもよい。統計情報としては、例えば、各ノード２に適用されている最新のＷＡＬ版数、過去の特定の期間における各ノード２のスループット（単位時間当たりの処理量等）、ＣＰＵ（Central Processing Unit）使用率等の種々の情報が挙げられる。
【０１０３】
上述したクラスタ制御部２３による処理は、例えば、マスタサーバ２Ａが正常であれば、マスタサーバ２Ａ（マスタサーバ２Ａが切り替わった場合は切替後のマスタサーバ２Ａ）のクラスタ制御部２３により実行されてよい。
【０１０４】
或いは、マスタサーバ２Ａの更新業務の安定化を図るために、上述したクラスタ制御部２３による処理は、複数のＤＢサーバ２のクラスタ制御部２３により協働して実行されてもよい。協働して上記処理を実行する複数のＤＢサーバ２には、複数のスタンバイサーバ２Ｂ（同期スタンバイサーバ及び／又は非同期スタンバイサーバ）が含まれてよく、マスタサーバ２Ａが含まれてもよい。
【０１０５】
また、上述したクラスタ制御部２３による処理は、マスタサーバ２Ａに障害が発生し、フェイルオーバが完了するまでの間は、例えば、複数のスタンバイサーバ２Ｂのクラスタ制御部２３により協働して実行されてよい。
【０１０６】
なお、一実施形態に係るクラスタシステム１は、同時障害耐久性を確保するために、複数のノード２に障害が発生した場合には、障害が発生したノード２のノード数や障害が発生したノード２の同期モードに基づいて、上述した処理を組み合わせて実施してよい。
【０１０７】
例えば、複数の同期スタンバイサーバに障害が発生した場合には、マスタサーバ２Ａのクラスタ制御部２３は、障害の発生した同期スタンバイサーバの数に相当する（同じ数の）非同期スタンバイサーバの同期モードを同期スタンバイに切り替えてよい。
【０１０８】
なお、「同期スタンバイ」のノード数は、例えば、クラスタシステム１の起動や初期設定等のタイミングで、システム管理者等により設定されてもよい。クラスタ制御部２３は、設定された同期スタンバイのノード数となるように、「同期スタンバイ」の状態であるノード２のノード数を制御してもよい。
【０１０９】
また、マスタサーバ２Ａと、１以上の同期スタンバイサーバとに障害が発生した場合には、以下の（ｉ）及び（ii）の手順により切り替え制御を行なってよい。
【０１１０】
（ｉ）上述のように、複数の同期スタンバイサーバのクラスタ制御部２３が協働して、１つのスタンバイサーバ２Ｂを新たなマスタサーバ２Ａに昇格させる。
【０１１１】
（ii）新たなマスタサーバ２Ａが、障害の発生した１以上の同期スタンバイサーバの数に“１”（上記（ｉ）で減少した同期スタンバイサーバの数）を加算した数に相当する非同期スタンバイサーバの同期モードを同期スタンバイに切り替える。
【０１１２】
連携制御部２４は、クラスタ制御部２３によるノード２の状態遷移（例えば同期モードの切り替え）が行なわれた場合に、更新後のノード情報２１２（又はノードリスト２１３）に基づくＡＰサーバ３への通知を行なう。
【０１１３】
例えば、連携制御部２４は、ノード情報２１２（又はノードリスト２１３）をＡＰサーバ３に送信してもよいし、ノード情報２１２（又はノードリスト２１３）に基づき検出したノード２の状態変化に応じて、ＡＰサーバ３に通知を行なってもよい。以下の説明では、連携制御部２４がノード２の状態変化に応じた通知を行なう場合を例に挙げる。
【０１１４】
なお、状態変化としては、例えば、フェイルオーバ、フォールバック、及び、サーバ２の同期状態、の少なくとも一つに関連する変化が挙げられる。サーバ２の同期状態に関連する変化としては、例えば、ログ転送時間の変化に基づいた、マスタサーバ２Ａに対して同期スタンバイの状態となるサーバ２の変化が挙げられる。
【０１１５】
図１０は、ノード２の状態遷移に応じた処理の一例を示す図である。図１０に示すように、連携制御部２４は、ＡＰサーバ３への通知として、ノード２に対する「コネクション切断」又は「ＡＰ接続候補への追加」を指示してよい。
【０１１６】
「コネクション切断」の指示は、同期データの参照処理を行なうためにＡＰサーバ３が確立する、ＡＰサーバ３とスタンバイサーバ２Ｂ（又はマスタサーバ２Ａ）との間のコネクションを切断するための要求である。
【０１１７】
「ＡＰ接続候補への追加」の指示は、ＡＰによる同期データの参照処理を行なうための接続先の候補にノード２を追加するための要求である。ＡＰ接続候補に追加されたノード２は、ＡＰサーバ３によるコネクションの確立及び同期データの参照処理の候補のノード２となる。
【０１１８】
「コネクション切断」及び「ＡＰ接続候補への追加」の指示が行なわれる場面（図１０参照）と、切断対象又は追加対象のノード２との関係は、以下のとおりである。
【０１１９】
・ノード２のフェイルオーバが発生した場合。
この場合、連携制御部２４は、ＡＰサーバ３に対して、マスタサーバ２Ａに昇格した同期スタンバイサーバの代わりに同期スタンバイに昇格した非同期スタンバイサーバについて、「ＡＰ接続候補への追加」を指示する。
【０１２０】
また、この場合において、マスタサーバ２Ａに対する同期データの参照業務が許容されない場合、連携制御部２４は、ＡＰサーバ３に対して、マスタサーバ２Ａに昇格した同期スタンバイサーバとの間の「コネクション切断」を指示する。
【０１２１】
一方、マスタサーバ２Ａに対する同期データの参照業務が許容される場合、連携制御部２４は、ＡＰサーバ３に対して、障害の発生したマスタサーバ２Ａ（停止状態に遷移したノード２）との間の「コネクション切断」を指示する。
【０１２２】
・同期スタンバイへの状態遷移が発生した場合。
例えば、非同期スタンバイから同期スタンバイにノード２が状態遷移した場合、連携制御部２４は、ＡＰサーバ３に対して、同期スタンバイに状態遷移したノード２について、「ＡＰ接続候補への追加」を指示する。
【０１２３】
・非同期スタンバイへの状態遷移が発生した場合。
例えば、同期スタンバイから非同期スタンバイにノード２が状態遷移した場合、連携制御部２４は、ＡＰサーバ３に対して、非同期スタンバイに状態遷移したノード２との間の「コネクション切断」を指示する。
【０１２４】
・ノード２のフォールバックが発生した場合。
この場合、連携制御部２４は、ＡＰサーバ３に対して、フォールバックしたノード２（停止状態に遷移したノード２）との間の「コネクション切断」を指示する。
【０１２５】
〔１−３−２〕ＡＰサーバの構成例
次に、図１１を参照して、一実施形態に係るＡＰサーバ３の機能構成例を説明する。図１１に示すように、ノード３は、例示的に、メモリ部３１、クラスタ制御部３２、及び、連携制御部３３をそなえてよい。
【０１２６】
連携制御部３３は、連携制御部２４とともに図４に示す連携機能６０の一例であり、ノード２の連携制御部２４から指示を受信し、受信した指示をクラスタ制御部３２に渡す。
【０１２７】
連携制御部３３は、連携制御部２４がノード情報２１２（又はノードリスト２１３）自体をＡＰサーバ３に送信する場合、連携制御部２４から受信したノード情報２１２等に基づいて、連携制御部２４の機能として説明した上述の処理を実行してよい。例えば、連携制御部３３は、ノード２の状態変化を検出し、検出した状態変化に応じて「コネクション切断」又は「ＡＰ接続候補への追加」をクラスタ制御部３２に指示してよい。
【０１２８】
なお、連携制御部２４及び連携制御部３３のうちのいずれか一方は省略されてもよい。例えば、連携制御部２４が省略される場合、ＤＢサーバ２のクラスタ制御部２３は、ノード情報２１２（又はノードリスト２１３）を更新した場合に、当該ノード情報２１２（又はノードリスト２１３）をＡＰサーバ３に送信してよい。また、連携制御部３３が省略される場合、クラスタ制御部３２が連携制御部２４からノード情報２１２（或いはノードリスト２１３）又は指示を受信すればよい。
【０１２９】
以上のように、連携制御部２４及び３３は、スタンバイサーバ２Ｂに含まれる１又は複数のサーバ２の状態の変化を検知した場合に、変化を検知した後のスタンバイサーバ２Ｂに含まれるサーバ２から、同期スタンバイサーバを特定する第１特定部の一例である。
【０１３０】
メモリ部３１は、ＡＰサーバ３がＡＰの制御に用いる種々の情報を記憶する。例えば、一実施形態に係るメモリ部３１は、クラスタ制御部３２及び連携制御部３３の処理に用いられる情報として、接続候補情報３１１を記憶してよい。
【０１３１】
図１２に接続候補情報３１１の一例を示す。接続候補情報３１１は、同期データの参照業務の接続先（参照先）の候補となるノード２を示す情報であり、例示的に、接続候補ノード２の識別情報と、当該ノード２の状態とを含んでよい。接続候補のノード２の状態は、例えば、「同期スタンバイ」が挙げられる。なお、マスタサーバ２Ａが同期データの参照処理の接続先となることが運用設定により許容されている場合には、「マスタ」のノード２（図１２の例では“ノード＃ｘ”）が接続候補情報３１１に設定されてもよい。
【０１３２】
なお、接続候補情報３１１は、非同期データの参照業務の接続先の候補となるノード２（例えば非同期スタンバイサーバ）の識別情報及び状態を含んでもよい。接続候補情報３１１は、ノード情報２１２と同一の情報であってもよく、この場合、ＡＰサーバ３は、ノード２（連携制御部２４）からノード情報２１２を通知され、通知されたノード情報２１２を接続候補情報３１１としてメモリ部３１に格納してもよい。或いは、接続候補情報３１１は、ノードリスト２１３と同様の情報であってもよい。この場合、ＡＰサーバ３は、ノード２（連携制御部２４）からノードリスト２１３を通知され、通知されたノードリスト２１３を接続候補情報３１１としてメモリ部３１に格納してもよい。
【０１３３】
クラスタ制御部３２は、ノード２の同期モードの切り替えに関する種々の制御を行なうものであり、図４に示すＡＰ側クラスタ機能３０の一例である。
【０１３４】
図１１に示すように、クラスタ制御部３２は、例示的に、接続制御部３２１及び振分部３２２をそなえてよい。
【０１３５】
接続制御部３２１は、連携制御部２４からの通知に応じて、接続候補情報３１１及びコネクションの制御を行なってよい。例えば、接続制御部３２１は、連携制御部２４から或るノード２の「接続候補への追加」を指示された場合、接続候補情報３１１に対して、当該ノード２が同期データの参照業務で有効となるように設定してよい。接続候補情報３１１に対するノード２が有効となるような設定は、接続候補情報３１１に当該ノード２のエントリを追加することを含んでもよく、或いは、当該ノード２の状態を同期スタンバイに変更することを含んでもよい。
【０１３６】
なお、接続制御部３２１は、ＡＰ（例えばクラスタプロセス３０Ａ；図４参照）に対して、接続候補に追加したノード２とのコネクションの確立を指示してもよい。ＡＰに対するコネクションの確立の指示は、端末４に通知され、端末４からＡＰに対して、コネクションの確立の実行指示が行なわれてよい。
【０１３７】
以上のように、接続制御部３２１は、サーバ２の状態の変化が検知された場合に、端末４に対し、変化検知後のマスタサーバ２Ａに対し同期スタンバイの状態であるサーバ２への接続を要求する第１要求部の一例である。
【０１３８】
また、接続制御部３２１は、連携制御部２４から、或るノード２の「コネクション切断」を指示された場合、接続候補情報３１１に対して、当該ノード２が同期データの参照業務で無効となるように更新してよい。接続候補情報３１１に対するノード２が無効となるような設定は、接続候補情報３１１から当該ノード２のエントリを削除することを含んでもよく、或いは、当該ノード２の状態を非同期スタンバイや停止状態に変更することを含んでもよい。
【０１３９】
なお、接続制御部３２１は、ＡＰ（例えばクラスタプロセス３０Ａ；図４参照）に対して、ノード２とのコネクション切断を指示してよい。ＡＰに対するコネクション切断の指示は、端末４に通知され、端末４からＡＰに対して、コネクション切断の実行指示が行なわれてよい。なお、コネクションの切断は、端末４（ＡＰ）との接続が確立されている全てのノード２に対して行なわれてよく、その後に、状態変化後の同期スタンバイサーバとの間で接続の再確立が行なわれてもよい。或いは、コネクションの切断は、コネクション切断対象として指定されたノード２に対して行なわれてもよい。
【０１４０】
以上のように、第１要求部の一例としての接続制御部３２１は、サーバ２の状態の変化が検知された場合に、端末４に対し、スタンバイサーバ２Ｂに含まれるサーバ２との接続の切断を要求してよい。
【０１４１】
振分部３２２は、接続候補情報３１１を参照し、端末４から受信したクラスタシステム１に対するアクセス要求（例えば更新業務に係る更新要求や参照業務に係る参照要求）に対して、アクセス対象となるサーバ２を振り分ける。
【０１４２】
一例として、振分部３２２は、ＡＰサーバ３で動作するアプリケーションのクラスタプロセス３０ＡからＡＰの接続先の情報を要求されると、ＡＰサーバ３（端末４）と接続中（コネクション確立済）のサーバ２の状態が変化したか否かを判定してよい。接続中のサーバ２の状態変化（例えば非同期スタンバイ又は停止状態への変化）を検知した場合、振分部３２２は、接続候補情報３１１に登録されている接続先候補のサーバ２を抽出してよい。接続先候補のサーバ２は、例えば、同期データの参照業務の場合は「同期スタンバイ」（及び「マスタ」）のサーバ２である。
【０１４３】
そして、振分部３２２は、抽出したサーバ２のうちのいずれかのサーバ２を特定し、特定したサーバ２の情報をクラスタプロセス３０Ａに通知してよい。なお、複数の同期スタンバイサーバのうちのいずれかのサーバ２を特定する手法としては、既知の種々の手法（例えばロードバランシング）が利用されてよい。
【０１４４】
また、振分部３２２は、ＡＰサーバ３（端末４）と接続中である、状態変化が検知されたサーバ２とのコネクション切断を指示してよい。なお、上述のように、コネクションの切断は、端末４（ＡＰ）との接続が確立されている全てのノード２に対して行なわれてよく、その後に、状態変化後の同期スタンバイサーバとの間で接続の再確立が行なわれてもよい。
【０１４５】
このように、振分部３２２によれば、端末４が同期データの参照業務を行なう際に、端末４と接続中のサーバ２の同期状態に応じた、他のサーバ２とのコネクションの再接続が行なえるため、同期データの参照業務を確実に実施することができる。
【０１４６】
以上のように、振分部３２２は、端末４が接続中のサーバ２の状態の変化を検知した場合に、変化を検知した後のスタンバイサーバ２Ｂに含まれるサーバ２から、同期スタンバイサーバを特定する第２特定部の一例である。また、連携制御部２４及び３３、並びに、振分部３２２は、特定部の一例である。
【０１４７】
また、振分部３２２は、端末４が接続中のサーバ２の状態の変化を検知した場合に、端末４に対し、変化検知後のマスタサーバ２Ａに対し同期スタンバイの状態であるサーバ２への接続を要求する第２要求部の一例である。また、接続制御部３２１及び振分部３２２は、要求部の一例である。第２要求部の一例としての振分部３２２は、端末４が接続中のサーバ２の状態の変化が検知された場合に、端末４に対し、スタンバイサーバ２Ｂに含まれるサーバ２との接続の切断を要求してよい。
【０１４８】
〔１−４〕動作例
次に、図１３〜図２０を参照して、上述の如く構成されたクラスタシステム１の動作例を説明する。
【０１４９】
〔１−４−１〕ＤＢサーバのクラスタ制御部の動作例
まず、図１３〜図１７を参照して、ＤＢサーバ２のクラスタ制御部２３の動作例を説明する。
【０１５０】
・同期モード切替処理
図１３に例示するように、ＤＢサーバ２のクラスタ制御部２３は、ＤＢＭＳにより測定されるスタンバイサーバ２Ｂのログ転送性能を取得し、取得したログ転送性能を性能情報２１４としてＤＢ２１に蓄積する（ステップＳ１）。
【０１５１】
クラスタ制御部２３は、性能情報２１４に一定期間分（例えば１日分）のログ転送性能を蓄積したか否かを判定する（ステップＳ２）。蓄積していない場合（ステップＳ２でＮｏ）、クラスタ制御部２３は、性能情報２１４を参照し、同期スタンバイサーバのログ転送時間が閾値を超えたか否かを判定する（ステップＳ３）。
【０１５２】
同期スタンバイサーバのログ転送時間が閾値を超えていない場合（ステップＳ３でＮｏ）、クラスタ制御部２３は、一定時間（例えば数分〜数時間）待機し、次に蓄積するログ転送性能を選択して（ステップＳ４）、処理がステップＳ１に移行する。
【０１５３】
一方、ステップＳ２において性能情報２１４に一定期間分のログ転送性能を蓄積したと判定した場合（ステップＳ２でＹｅｓ）、処理がステップＳ５に移行する。また、ステップＳ３において同期スタンバイサーバのログ転送時間が閾値を超えたと判定した場合（ステップＳ３でＹｅｓ）、処理がステップＳ５に移行する。
【０１５４】
ステップＳ５において、クラスタ制御部２３は、性能情報２１４からサーバ２ごとにログ転送時間の平均を算出して集計情報２１５を生成又は更新する。
【０１５５】
次いで、クラスタ制御部２３は、集計情報２１５を参照して、同期スタンバイサーバ（Ａ）よりもログ転送時間の平均が短い非同期スタンバイサーバ（Ｂ）が存在するか否かを判定する（ステップＳ６）。このような非同期スタンバイサーバ（Ｂ）が存在しない場合（ステップＳ６でＮｏ）、処理がステップＳ１に移行する。
【０１５６】
一方、このような非同期スタンバイサーバ（Ｂ）が存在する場合（ステップＳ６でＹｅｓ）、クラスタ制御部２３は、サーバ（Ａ）の同期モードとサーバ（Ｂ）の同期モードとを入れ替える（ステップＳ７；図１４の符号（ｉ）参照）。例えば、クラスタ制御部２３は、サーバ（Ａ）の同期モードを非同期スタンバイに設定し、サーバ（Ｂ）の同期モードを同期スタンバイに設定する。なお、クラスタ制御部２３は、設定された同期スタンバイサーバ数と一致するように、サーバ（Ａ）及びサーバ（Ｂ）のそれぞれの台数を決定してもよい。
【０１５７】
そして、クラスタ制御部２３は、変更後のサーバ２の状態に基づき、ノード情報２１２及びノードリスト２１３を更新する（ステップＳ８）。また、クラスタ制御部２３は、更新後のノード情報２１２（又はノードリスト２１３）を連携制御部２４に通知して（ステップＳ９；図１４の符号（ii）参照）、処理がステップＳ１に移行する。
【０１５８】
・フェイルオーバ処理
図１５に例示するように、ＤＢサーバ２（例えば同期スタンバイサーバ）のクラスタ制御部２３は、マスタサーバ２Ａの障害発生を検出する（ステップＳ１１）。
【０１５９】
クラスタ制御部２３は、ノード情報２１２及び集計情報２１５に基づき、マスタへの切替先の同期スタンバイサーバを選択する（ステップＳ１２）。例えば、クラスタ制御部２３は、ノード情報２１２に基づき同期スタンバイサーバを特定し、特定した同期スタンバイサーバの中から、集計情報２１５においてログ転送時間の短い順に上位から所定数分の同期スタンバイサーバを選択してよい。所定数とは、入れ替え対象の台数である。
【０１６０】
また、クラスタ制御部２３は、マスタサーバ２Ａを停止状態に設定し、選択したサーバ２の同期モードをマスタに切り替える（ステップＳ１３）。
【０１６１】
そして、クラスタ制御部２３は、変更後のサーバ２の状態に基づき、ノード情報２１２及びノードリスト２１３を更新し（ステップＳ１４）、ノード情報２１２（又はノードリスト２１３）を連携制御部２４に通知して（ステップＳ１５）、処理が終了する。
【０１６２】
・フォールバック処理
図１６に例示するように、ＤＢサーバ２のクラスタ制御部２３は、スタンバイサーバ２Ｂの障害発生を検出すると（ステップＳ２１）、障害の発生したサーバ２が同期スタンバイサーバか否かを判定する（ステップＳ２２）。
【０１６３】
障害の発生したサーバ２が同期スタンバイサーバの場合（ステップＳ２２でＹｅｓ）、クラスタ制御部２３は、動作する同期スタンバイの数が性能情報２１４の設定値未満か否かを判定する（ステップＳ２３）。動作する同期スタンバイの数が性能情報２１４の設定値未満の場合（ステップＳ２３でＹｅｓ）、クラスタ制御部２３は、同期スタンバイサーバの不足数を算出する（ステップＳ２４）。
【０１６４】
そして、クラスタ制御部２３は、ノード情報２１２及び集計情報２１５に基づき、不足数分の非同期スタンバイサーバを選択する（ステップＳ２５）。例えば、クラスタ制御部２３は、ノード情報２１２に基づき非同期スタンバイサーバを特定し、特定した非同期スタンバイサーバの中から、集計情報２１５においてログ転送時間の短い順に上位から不足数分の非同期スタンバイサーバを選択してよい。
【０１６５】
次いで、クラスタ制御部２３は、選択したサーバ２の同期モードを同期スタンバイに切り替え（ステップＳ２６）、障害の発生した同期スタンバイサーバを停止状態に設定し（ステップＳ２７）、処理がステップＳ２９に移行する。
【０１６６】
なお、ステップＳ２３において、動作する同期スタンバイの数が設定値未満ではないと判定された場合（ステップＳ２３でＮｏ）、非同期スタンバイから同期スタンバイへの切り替えが不要であるため、処理がステップＳ２７に移行する。
【０１６７】
一方、ステップＳ２２において、障害の発生したサーバ２が同期スタンバイサーバではない（例えば非同期スタンバイサーバである）と判定された場合（ステップＳ２２でＮｏ）、処理がステップＳ２８に移行する。ステップＳ２８では、クラスタ制御部２３は、障害の発生した非同期スタンバイサーバを停止状態に設定し、処理がステップＳ２９に移行する。
【０１６８】
ステップＳ２９では、クラスタ制御部２３は、変更後のサーバ２の状態に基づき、ノード情報２１２及びノードリスト２１３を更新する（ステップＳ２９）。そして、クラスタ制御部２３は、ノード情報２１２（又はノードリスト２１３）を連携制御部２４に通知して（ステップＳ３０）、処理が終了する。
【０１６９】
・サーバ起動処理
図１７に例示するように、ＤＢサーバ２のクラスタ制御部２３は、サーバ２の起動を検出すると（ステップＳ３１）、起動したサーバ２の同期モードを非同期スタンバイに設定する（ステップＳ３２）。
【０１７０】
次いで、クラスタ制御部２３は、起動したサーバ２と当該サーバ２の同期モードとをノード情報２１２及びノードリスト２１３に追加する（ステップＳ３３）。また、クラスタ制御部２３は、ノード情報２１２（又はノードリスト２１３）を連携制御部２４に通知して（ステップＳ３４）、処理が終了する。
【０１７１】
〔１−４−２〕連携制御部の動作例
次に、図１４及び図１８を参照して、ＤＢサーバ２の連携制御部２４による連携処理の動作例を説明する。なお、上述のように、連携機能６０は、ＤＢサーバ２側の連携制御部２４と、ＡＰサーバ３側の連携制御部３３とに分散して実装されてもよく、以下の各処理の少なくとも一部は、ＡＰサーバ３の連携制御部３３により実行されてもよい。
【０１７２】
図１８に例示するように、連携制御部２４は、クラスタ制御部２３からノード情報２１２（又はノードリスト２１３）を受け付ける（ステップＳ４１）。なお、連携制御部２４は、受け付けたノード情報２１２（又はノードリスト２１３）をＡＰサーバ３のクラスタ制御部３２に送信してもよく、この場合、以下のステップＳ４２〜Ｓ５０の処理が省略されてもよい。
【０１７３】
次いで、連携制御部２４は、ノード情報２１２に基づいて、状態が変化したサーバを検出する（ステップＳ４２）。
【０１７４】
例えば、連携制御部２４は、検出したサーバ２の状態が非同期スタンバイから同期スタンバイに変化したか否かを判定する（ステップＳ４３）。非同期スタンバイから同期スタンバイに変化していない場合（ステップＳ４３でＮｏ）、処理がステップＳ４５に移行する。一方、非同期スタンバイから同期スタンバイに変化した場合（ステップＳ４３でＹｅｓ）、連携制御部２４は、ＡＰサーバ３に対して、新たな同期スタンバイサーバをＡＰの接続候補に追加するように指示し（ステップＳ４４）、処理がステップＳ４５に移行する。
【０１７５】
ステップＳ４５において、連携制御部２４は、検出したサーバ２の状態が同期スタンバイから非同期スタンバイ又は停止状態に変化したか否かを判定する。同期スタンバイから非同期スタンバイ又は停止状態に変化していない場合（ステップＳ４５でＮｏ）、処理がステップＳ４７に移行する。一方、同期スタンバイから非同期スタンバイ又は停止状態に変化した場合（ステップＳ４５でＹｅｓ）、連携制御部２４は、ＡＰサーバ３に対して、当該サーバ２とのコネクション切断を指示し（ステップＳ４６）、処理がステップＳ４７に移行する。
【０１７６】
ステップＳ４７において、連携制御部２４は、ノード情報２１２に基づいて、マスタサーバ２Ａが変更されたか否か、換言すれば、フェイルオーバが発生したか否かを判定する。フェイルオーバが発生していない場合（ステップＳ４７でＮｏ）、処理が終了する。
【０１７７】
マスタサーバ２Ａが変更された場合（ステップＳ４７でＹｅｓ）、連携制御部２４は、運用設定において、同期データ参照業務の対象にマスタサーバ２Ａが含まれるか否かを判定する（ステップＳ４８）。同期データ参照業務の対象にマスタサーバ２Ａが含まれない場合（ステップＳ４８でＮｏ）、連携制御部２４は、ＡＰサーバ３に対して、新たなマスタサーバ２Ａとのコネクション切断を指示し（ステップＳ４９）、処理が終了する。
【０１７８】
一方、同期データ参照業務の対象にマスタサーバ２Ａが含まれる場合（ステップＳ４８でＹｅｓ）、連携制御部２４は、ＡＰサーバ３に対して、旧マスタサーバ２Ａとのコネクション切断を指示し（ステップＳ５０）、処理が終了する。
【０１７９】
なお、ステップＳ４３の判定に係る、非同期スタンバイから同期スタンバイへの変化は、例えば、フェイルオーバ処理、フォールバック処理、又は、同期モード切替処理によるサーバ２の状態の切り替えによって生じ得る。また、ステップＳ４５の判定に係る、同期スタンバイから非同期スタンバイ又は停止状態への変化は、例えば、フォールバック処理又は同期モード切替処理によるサーバ２の状態の切り替えによって生じ得る。さらに、ステップＳ４７の判定に係る、マスタサーバ２Ａの変更は、フェイルオーバ処理によるサーバ状態の切り替えによって生じ得る。
【０１８０】
また、ステップＳ４４、Ｓ４６、Ｓ４９、及びＳ５０における、連携制御部２４からＡＰサーバ３への通知（指示）は、図１４の符号（iii）に示す、連携機能６０からＡＰサーバ３に対する接続先サーバ２の変更の通知の一例である。
【０１８１】
〔１−４−３〕ＡＰサーバの接続制御部の動作例
次に、図１４及び図１９を参照して、ＡＰサーバ３の接続制御部３２１による接続先切替処理の動作例を説明する。
【０１８２】
図１９に例示するように、ＡＰサーバ３のクラスタ制御部３２は、連携制御部２４からの指示を受け付ける（ステップＳ５１）。
【０１８３】
接続制御部３２１は、受け付けた指示がＡＰの接続候補への追加であるか否かを判定する（ステップＳ５２）。指示がＡＰの接続候補への追加ではない場合（ステップＳ５２でＮｏ）、処理がステップＳ５５に移行する。
【０１８４】
指示がＡＰの接続候補への追加である場合（ステップＳ５２でＹｅｓ）、接続制御部３２１は、指示されたノード２が同期データの参照業務に対して有効となるように接続候補情報３１１を更新する（ステップＳ５３）。そして、接続制御部３２１は、ＡＰに対して、ノード２とのコネクションの確立を指示し（ステップＳ５４）、処理がステップＳ５５に移行する。
【０１８５】
ＡＰ（例えばクラスタプロセス３０Ａ）は、コネクションの確立を指示されると、指示されたノード２について、コネクションを確立する。
【０１８６】
ステップＳ５５において、接続制御部３２１は、受け付けた指示がコネクションの切断であるか否かを判定する。指示がコネクションの切断ではない場合（ステップＳ５５でＮｏ）、処理が終了する。
【０１８７】
指示がコネクションの切断である場合（ステップＳ５５でＹｅｓ）、接続制御部３２１は、ＡＰに対して、ノード２とのコネクションの切断を指示する（ステップＳ５６；図１４の符号（iv）参照）。また、接続制御部３２１は、指示されたノード２が同期データの参照業務に対して無効となるように接続候補情報３１１を更新し（ステップＳ５７）、処理が終了する。
【０１８８】
ＡＰ（例えばクラスタプロセス３０Ａ）は、コネクションの切断を指示されると、コネクションを確立しているノード２とのコネクションを切断する。コネクションの切断は、全てのノード２が対象であってもよく、指示されたノード２が対象であってもよい。
【０１８９】
〔１−４−４〕ＡＰサーバの振分部の動作例
次に、図１４及び図２０を参照して、ＡＰサーバ３の振分部３２２による接続先振分処理の動作例を説明する。
【０１９０】
図２０に例示するように、ＡＰサーバ３のクラスタ制御部３２は、ＡＰサーバ３で動作するアプリケーションのクラスタプロセス３０ＡからＡＰの接続先情報要求を受け付ける（ステップＳ６１）。
【０１９１】
振分部３２２は、接続候補情報３１１を参照し、ＡＰサーバ３と接続中のサーバ２の状態変化を検知したか否かを判定する（ステップＳ６２）。状態変化を検知しない場合（ステップＳ６２でＮｏ）、処理が終了する。この場合、振分部３２２は、例えば、接続先に変化がない旨、又は、ＡＰサーバ３と接続中のサーバ２の情報を応答してもよい。
【０１９２】
状態変化を検知した場合（ステップＳ６２でＹｅｓ）、振分部３２２は、接続候補情報３１１を参照し、接続候補情報３１１から接続候補のサーバ２を抽出する（ステップＳ６３）。例えば、接続先情報要求において同期データの参照業務に係る接続先のサーバ２の情報が要求されている場合、接続候補のサーバ２として、「同期スタンバイ」（及び「マスタ」）の状態であるサーバ２が抽出されてよい。
【０１９３】
振分部３２２は、抽出した接続候補のサーバ２のうちのいずれかのサーバ２を、例えばロードバランシング技術等を用いて特定する（ステップＳ６４）。
【０１９４】
そして、振分部３２２は、ＡＰに対して、特定したサーバ２の情報（例えば識別情報や種々のアドレス等）を応答し、また、接続中のサーバ２とのコネクション切断を指示し（ステップＳ６５；図１４の符号（ｖ）参照）、処理が終了する。
【０１９５】
なお、上述したクラスタ制御部２３、連携制御部２４、及びクラスタ制御部３２のいずれかの処理中、或いは、これらの処理後において、端末４によるＡＰサーバ３を介した更新業務が発生した場合、マスタサーバ２Ａは、以下の処理を行なってよい。
【０１９６】
例えば、マスタサーバ２ＡのＤＢ制御部２２は、更新トランザクションを開始し、ＤＢ２１に対するＷＡＬの書き込み、及び、スタンバイサーバ２Ｂに対するＷＡＬの転送（例えばブロードキャスト）を行なう。また、ＤＢ制御部２２は、スタンバイサーバ２Ｂのうち、ノードリスト２１３に設定された同期スタンバイの状態である全てのノード２から転送応答を受信した場合に、更新トランザクションを終了する。
【０１９７】
〔１−５〕ハードウェア構成例
次に、図２１を参照して、一実施形態に係るノード２及びノード３のハードウェア構成例について説明する。ノード２及びノード３は、互いに同様のハードウェア構成をそなえてよいため、以下、これらの一例としてコンピュータ１０を例に挙げて、コンピュータ１０のハードウェア構成例について説明する。
【０１９８】
図２１に示すように、コンピュータ１０は、例示的に、プロセッサ１０ａ、メモリ１０ｂ、記憶部１０ｃ、ＩＦ（Interface）部１０ｄ、Ｉ／Ｏ（Input / Output）部１０ｅ、及び読取部１０ｆをそなえてよい。
【０１９９】
プロセッサ１０ａは、種々の制御や演算を行なう演算処理装置の一例である。プロセッサ１０ａは、コンピュータ１０内の各ブロックとバス１０ｉで相互に通信可能に接続されてよい。プロセッサ１０ａとしては、例えば、ＣＰＵ、ＭＰＵ、ＧＰＵ、ＡＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ等の集積回路（ＩＣ；Integrated Circuit）が用いられてもよい。なお、ＭＰＵはMicro Processing Unitの略称である。ＧＰＵはGraphics Processing Unitの略称であり、ＡＰＵはAccelerated Processing Unitの略称である。ＤＳＰはDigital Signal Processorの略称であり、ＡＳＩＣはApplication Specific ICの略称であり、ＦＰＧＡはField-Programmable Gate Arrayの略称である。
【０２００】
メモリ１０ｂは、種々のデータやプログラム等の情報を格納するハードウェアの一例である。メモリ１０ｂとしては、例えばＲＡＭ（Random Access Memory）等の揮発性メモリが挙げられる。
【０２０１】
記憶部１０ｃは、種々のデータやプログラム等の情報を格納するハードウェアの一例である。記憶部１０ｃとしては、例えばＨＤＤ（Hard Disk Drive）等の磁気ディスク装置、ＳＳＤ（Solid State Drive）等の半導体ドライブ装置、不揮発性メモリ等の各種記憶装置が挙げられる。不揮発性メモリとしては、例えば、フラッシュメモリ、ＳＣＭ（Storage Class Memory）、ＲＯＭ（Read Only Memory）等が挙げられる。
【０２０２】
なお、図５に示すＤＢサーバ２のＤＢ２１は、例えば、ＤＢサーバ２のメモリ１０ｂ及び記憶部１０ｃの少なくとも一方の記憶領域により実現されてもよい。また、図１１に示すＡＰサーバ３のメモリ部３１は、例えば、ＡＰサーバ３のメモリ１０ｂ及び記憶部１０ｃの少なくとも一方の記憶領域により実現されてもよい。
【０２０３】
また、記憶部１０ｃは、コンピュータ１０の各種機能の全部若しくは一部を実現するプログラム１０ｇを格納してよい。プロセッサ１０ａは、記憶部１０ｃに格納されたプログラム１０ｇをメモリ１０ｂに展開して実行することにより、図５に示すＤＢサーバ２、又は、図１１に示すＡＰサーバ３としての機能を実現できる。
【０２０４】
例えば、ＤＢサーバ２においては、ＤＢサーバ２のプロセッサ１０ａが、記憶部１０ｃに格納されたプログラム（接続制御プログラム）１０ｇをメモリ１０ｂに展開して演算処理を実行することで、同期モードに応じたＤＢサーバ２の機能を実現できる。当該機能は、ＤＢ制御部２２、クラスタ制御部２３、及び連携制御部２４の機能を含んでよい。
【０２０５】
また、ＡＰサーバ３においては、ＡＰサーバ３のプロセッサ１０ａが、記憶部１０ｃに格納されたプログラム（接続制御プログラム）１０ｇをメモリ１０ｂに展開して演算処理を実行することで、ＡＰサーバ３としての機能を実現できる。当該機能は、クラスタ制御部３２（接続制御部３２１及び振分部３２２）、及び連携制御部３３の機能を含んでよい。
【０２０６】
なお、接続制御プログラムの一例であるプログラム１０ｇは、当該プログラム１０ｇにより実現される機能に応じて、図５に示すＤＢサーバ２と、図１１に示すＡＰサーバ３と、に分散して配布され、インストールされてよい。
【０２０７】
ＩＦ部１０ｄは、ネットワーク１ａ、１ｂ、又は５との間の接続及び通信の制御等を行なう通信インタフェースの一例である。例えば、ＩＦ部１０ｄは、ＬＡＮ、或いは、光通信（例えばＦＣ（Fibre Channel；ファイバチャネル））等に準拠したアダプタを含んでよい。
【０２０８】
例えば、ＤＢサーバ２のプログラム１０ｇは、当該通信インタフェース及びネットワーク１ｂ（或いは管理用ネットワーク）を介して、ネットワーク５からコンピュータ１０にダウンロードされ、記憶部１０ｃに格納されてもよい。また、例えば、ＡＰサーバ３のプログラム１０ｇは、当該通信インタフェースを介して、ネットワーク５からコンピュータ１０にダウンロードされ、記憶部１０ｃに格納されてもよい。
【０２０９】
Ｉ／Ｏ部１０ｅは、マウス、キーボード、又は操作ボタン等の入力部、並びに、タッチパネルディスプレイ、ＬＣＤ（Liquid Crystal Display）等のモニタ、プロジェクタ、又はプリンタ等の出力部、の一方又は双方を含んでよい。
【０２１０】
読取部１０ｆは、記録媒体１０ｈに記録されたデータやプログラムの情報を読み出すリーダの一例である。読取部１０ｆは、記録媒体１０ｈを接続可能又は挿入可能な接続端子又は装置を含んでよい。読取部１０ｆとしては、例えば、ＵＳＢ（Universal Serial Bus）等に準拠したアダプタ、記録ディスクへのアクセスを行なうドライブ装置、ＳＤカード等のフラッシュメモリへのアクセスを行なうカードリーダ等が挙げられる。なお、記録媒体１０ｈにはプログラム１０ｇが格納されてもよく、読取部１０ｆが記録媒体１０ｈからプログラム１０ｇを読み出して記憶部１０ｃに格納してもよい。
【０２１１】
記録媒体１０ｈとしては、例示的に、磁気／光ディスクやフラッシュメモリ等の非一時的な記録媒体が挙げられる。磁気／光ディスクとしては、例示的に、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク、ＨＶＤ（Holographic Versatile Disc）等が挙げられる。フラッシュメモリとしては、例示的に、ＵＳＢメモリやＳＤカード等が挙げられる。なお、ＣＤとしては、例示的に、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ等が挙げられる。また、ＤＶＤとしては、例示的に、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。
【０２１２】
上述したコンピュータ１０のハードウェア構成は例示である。従って、コンピュータ１０内でのハードウェアの増減（例えば任意のブロックの追加や削除）、分割、任意の組み合わせでの統合、又は、バスの追加若しくは削除等は適宜行なわれてもよい。
【０２１３】
〔２〕その他
上述した一実施形態に係る技術は、以下のように変形、変更して実施することができる。
【０２１４】
例えば、図５に示すＤＢ制御部２２、クラスタ制御部２３、及び、連携制御部２４の少なくとも１つの機能を併合してもよく、或いは、分割してもよい。また、図１１に示すクラスタ制御部３２、及び、連携制御部３３の少なくとも１つの機能を併合してもよく、或いは、分割してもよい。
【０２１５】
また、図２１に示すコンピュータ１０のプロセッサ１０ａは、シングルプロセッサやシングルコアプロセッサに限定されるものではなく、マルチプロセッサやマルチコアプロセッサであってもよい。
【０２１６】
〔３〕付記
以上の実施形態に関し、さらに以下の付記を開示する。
【０２１７】
（付記１）
端末が接続を行なうサーバの制御を行なう接続制御プログラムであって、
前記端末の接続先となる複数のサーバを含むサーバ群において、前記サーバ群に含まれる１又は複数のサーバの状態の変化を検知した場合に、前記変化を検知した後の前記サーバ群に含まれるサーバから、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定し、
前記端末に対し、特定した前記サーバへの接続を要求する、
処理をコンピュータに実行させることを特徴とする、接続制御プログラム。
【０２１８】
（付記２）
前記サーバの状態の変化は、フェイルオーバ、フォールバック、及び、サーバの同期状態、の少なくとも一つに関連する変化であることを特徴とする、付記１に記載の接続制御プログラム。
【０２１９】
（付記３）
前記端末が接続中のサーバの状態の変化を検知した場合に、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定し、
前記端末に対し、特定した前記サーバへの接続を要求する、
処理を前記コンピュータに実行させることを特徴とする、付記１又は付記２に記載の接続制御プログラム。
【０２２０】
（付記４）
前記変化を検知した場合に、前記端末に対し、前記サーバ群に含まれるサーバとの接続の切断を要求する、
処理を前記コンピュータに実行させることを特徴とする、付記１〜３のいずれか１項に記載の接続制御プログラム。
【０２２１】
（付記５）
前記端末が接続中のサーバの状態の変化を検知した場合に、前記サーバ群に含まれるサーバとの切断を要求する、
処理を前記コンピュータに実行させることを特徴とする、付記１〜４のいずれか１項に記載の接続制御プログラム。
【０２２２】
（付記６）
前記変化は、ログ転送時間の変化に基づいた、プライマリサーバに対して同期スタンバイの状態となるサーバの変化を含むことを特徴とする、付記１〜５のいずれか１項に記載の接続制御プログラム。
【０２２３】
（付記７）
端末が接続を行なうサーバの制御を行なう接続制御方法であって、
コンピュータのプロセッサが、
前記端末の接続先となる複数のサーバを含むサーバ群において、前記サーバ群に含まれる１又は複数のサーバの状態の変化を検知した場合に、前記変化を検知した後の前記サーバ群に含まれるサーバから、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定し、
前記端末に対し、特定した前記サーバへの接続を要求する、
ことを特徴とする、接続制御方法。
【０２２４】
（付記８）
前記サーバの状態の変化は、フェイルオーバ、フォールバック、及び、サーバの同期状態、の少なくとも一つに関連する変化であることを特徴とする、付記７に記載の接続制御方法。
【０２２５】
（付記９）
前記プロセッサが、
前記端末が接続中のサーバの状態の変化を検知した場合に、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定し、
前記端末に対し、特定した前記サーバへの接続を要求する、
ことを特徴とする、付記７又は付記８に記載の接続制御方法。
【０２２６】
（付記１０）
前記プロセッサが、
前記変化を検知した場合に、前記端末に対し、前記サーバ群に含まれるサーバとの接続の切断を要求する、
ことを特徴とする、付記７〜９のいずれか１項に記載の接続制御方法。
【０２２７】
（付記１１）
前記プロセッサが、
前記端末が接続中のサーバの状態の変化を検知した場合に、前記サーバ群に含まれるサーバとの切断を要求する、
ことを特徴とする、付記７〜１０のいずれか１項に記載の接続制御方法。
【０２２８】
（付記１２）
前記変化は、ログ転送時間の変化に基づいた、プライマリサーバに対して同期スタンバイの状態となるサーバの変化を含むことを特徴とする、付記７〜１１のいずれか１項に記載の接続制御方法。
【０２２９】
（付記１３）
端末が接続を行なうサーバの制御を行なう接続制御装置であって、
前記端末の接続先となる複数のサーバを含むサーバ群において、前記サーバ群に含まれる１又は複数のサーバの状態の変化を検知した場合に、前記変化を検知した後の前記サーバ群に含まれるサーバから、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定する特定部と、
前記端末に対し、特定した前記サーバへの接続を要求する要求部と、をそなえることを特徴とする、接続制御装置。
【０２３０】
（付記１４）
前記サーバの状態の変化は、フェイルオーバ、フォールバック、及び、サーバの同期状態、の少なくとも一つに関連する変化であることを特徴とする、付記１３に記載の接続制御装置。
【０２３１】
（付記１５）
前記特定部は、前記端末が接続中のサーバの状態の変化を検知した場合に、前記変化を検知した後のプライマリサーバに対し同期スタンバイの状態であるサーバを特定し、
前記要求部は、前記端末に対し、特定した前記サーバへの接続を要求する
ことを特徴とする、付記１３又は付記１４に記載の接続制御装置。
【０２３２】
（付記１６）
前記要求部は、前記変化を検知した場合に、前記端末に対し、前記サーバ群に含まれるサーバとの接続の切断を要求する、
ことを特徴とする、付記１３〜１５のいずれか１項に記載の接続制御装置。
【０２３３】
（付記１７）
前記要求部は、前記端末が接続中のサーバの状態の変化を検知した場合に、前記サーバ群に含まれるサーバとの切断を要求する、
ことを特徴とする、付記１３〜１６のいずれか１項に記載の接続制御装置。
【０２３４】
（付記１８）
前記変化は、ログ転送時間の変化に基づいた、プライマリサーバに対して同期スタンバイの状態となるサーバの変化を含むことを特徴とする、付記１３〜１７のいずれか１項に記載の接続制御装置。
【符号の説明】
【０２３５】
１    クラスタシステム
１ａ、１ｂ、５    ネットワーク
２、３    ノード
２Ａ    マスタサーバ
２Ｂ    スタンバイサーバ
２０    ＤＢ側クラスタ機能
２０Ａ、２０Ｂ、３０Ａ    クラスタプロセス
２１    ＤＢ
２１１    ユーザデータ
２１２    ノード情報
２１３    ノードリスト
２１４    性能情報
２１５    集計情報
２２    ＤＢ制御部
２３、３２    クラスタ制御部
２４、３３    連携制御部
３０    ＡＰ側クラスタ機能
３１    メモリ部
３１１    接続候補情報
４    端末
６０    連携機能
【図１】
2019191843.tif 000003
【図２】
2019191843.tif 000004
【図３】
2019191843.tif 000005
【図４】
2019191843.tif 000006
【図５】
2019191843.tif 000007
【図６】
2019191843.tif 000008
【図７】
2019191843.tif 000009
【図８】
2019191843.tif 000010
【図９】
2019191843.tif 000011
【図１０】
2019191843.tif 000012
【図１１】
2019191843.tif 000013
【図１２】
2019191843.tif 000014
【図１３】
2019191843.tif 000015
【図１４】
2019191843.tif 000016
【図１５】
2019191843.tif 000017
【図１６】
2019191843.tif 000018
【図１７】
2019191843.tif 000019
【図１８】
2019191843.tif 000020
【図１９】
2019191843.tif 000021
【図２０】
2019191843.tif 000022
【図２１】
2019191843.tif 000023