JP2012234333A - クラスタシステム、同期制御方法、サーバ装置および同期制御プログラム - Google Patents

Abstract

【課題】新たにクラスタシステムに組み込んだサーバのデータ同期が完了するまでの時間を短縮することを課題とする。
【解決手段】クラスタシステムは、現用系サーバと組み込みサーバとを有し、クライアントのデータと該データの所在を示す情報とレコードの状況を示す情報とをレコードとして記憶するＤＢを各サーバが有する。現用系サーバは、ＤＢが有するレコードを第１の情報として第１の情報を示す種別の情報と共に組み込みサーバに送信するとともに、レコードの更新が発生した場合には、更新されたレコードを第２の情報として第２の情報を示す種別の情報と共に組み込みサーバに送信する。組み込みサーバは、現用系サーバから第１の情報または第２の情報を受信する。そして、組み込みサーバは、受信した種別の情報と、前記受信した情報によって特定されるＤＢのレコードの状況とに応じて、受信した情報に基づいたレコードをＤＢに生成する。
【選択図】図１

Description

本発明は、クラスタシステム、同期制御方法、サーバ装置および同期制御プログラムに関する。

従来、クライアントなどにサービスを提供するシステムでは、サービスを提供する現用系サーバで故障等が発生した場合に、待機系サーバでサービスを継続的に提供する。このようなシステムの一例としては、現用系サーバと待機系サーバで共有する共有ディスクを用いずに、各サーバでディスクを保持してデータをミラーリングするクラスタシステム（以下、ミラーリングクラスタと表記する）が知られている。

例えば、ミラーリングクラスタでは、待機系サーバが新たな現用系サーバとして起動した場合に、新たな待機系サーバ（以下、組み込みサーバと表記する）をクラスタに組み込む。この場合、新たな現用系サーバが保持するデータと組み込みサーバが保持するデータとを同期する必要がある。

データを同期する手法としては、現用系サーバのデータを外部の記録媒体にバックアップしておき、組み込みサーバにリストアする手法が知られている。また、レプリケーションやデュプリケーション等の手法も知られている。ところが、これらの手法は、データの同期が完了するまでの間、アプリケーションを停止させることになるので、２４時間サービスを停止できないシステムには適用できない。

そして、アプリケーションを停止させることなくデータ同期させる手法としては、データを同期させる同期フェーズと、同期フェーズ中に更新されたデータを更新する更新フェーズとの２フェーズで、データ同期を実行する手法が知られている。

例えば、同期フェーズでは、データが空である組み込みサーバに対して、現用系サーバからデータを送信する。この同期フェーズ実行中に更新されたデータについては、各サーバに適用せずに、現用系サーバまたは組み込みサーバに蓄積させておく。そして、同期フェーズ完了後、更新データを蓄積するサーバが、自サーバに更新データを適用するとともに他のサーバに更新データを送信して、データの同期を完了する。

また、別の手法としては、データベースのデータ構造に依存することなく、実用上オンラインサービスを停止させずにデータベースを移行するデータベースの再編成技術も知られている。このデータベースの再編成技術は、データのコピー中にコピー済のデータに対する物理位置を指定したデータ更新アクセスがあると、現用データベースと切替先データベースとに対してデータ更新処理を行う。そして、データベースの再編成技術は、コピー完了後にオンライン電文の振り分け先を切替先データベースアクセス手段に切り替える。

特開２００９−１９９１９７号公報 特開２００５−３２７０１５号公報 特開２００９−１５７７８５号公報 特開２００５−３１６６２４号公報 特開２００７−４１８８８号公報

しかしながら、従来の技術では、新たにクラスタシステムに組み込んだサーバのデータ同期が完了するまでに時間がかかるという問題がある。

例えば、上述した２フェーズでデータ同期する手法やデータベースの再編成技術を銀行や証券などの大規模システムに適用した場合について説明する。具体的には、管理対象のデータ数が膨大なクラスタシステムや、待機系サーバが複数台存在するような大規模クラスタシステムに組み込みサーバを追加する例で説明する。

２フェーズ手法の場合、管理対象のデータ数が膨大なクラスタシステムでは、現用系サーバから組み込みサーバに全データを送信して同期させるだけでも時間がかかる。さらに、この手法では、管理対象のデータ同期後に、同期中に更新されたデータの同期を続けて実行する。したがって、現用系サーバが管理するデータ数に加えて、データ送信中に更新された件数分のデータを同期することになるので、管理対象のデータ数が膨大なシステムやデータ更新頻度が多いシステムの場合には、同期完了までに時間がかかる。

また、再編成技術の場合、現用系サーバが、各待機系サーバが保持するデータベースおよび組み込みサーバが保持するデータベース各々に対して、同期対象のデータを書き込む。そして、現用系サーバは、各データベースへのデータ書き込みが完了すると、書き込み処理をコミットして、次のデータの書き込みを実行する。つまり、再編成技術の場合、データ１つずつに対して、データの複写状態の確認、データの書き込み、コミットなどを実行することで、データ同期を実行することになる。すなわち、待機系サーバの台数が多い場合には、現用系サーバの処理負荷が高くなる。また、１データずつデータ書き込み処理を実行する、つまり１トランザクションずつコミットした上で各データの同期処理を実行するので、データ書き込み処理に時間がかかる。したがって、これらの場合には、組み込みサーバの同期完了までに時間がかかる。

１つの側面では、新たにクラスタシステムに組み込んだサーバのデータ同期が完了するまでの時間を短縮できるクラスタシステム、同期制御方法、サーバ装置および同期制御プログラムを提供することを目的とする。

第１の案では、クラスタシステムは、第１のサーバ装置と第２のサーバ装置とを有し、クライアントのデータを記憶する記憶部を各サーバ装置が有する。前記第１のサーバ装置は、前記記憶部が有するレコードを第１の情報として第１の情報を示す種別の情報と共に前記第２のサーバ装置に送信するとともに、前記レコードの更新が発生した場合には、更新されたレコードを第２の情報として第２の情報を示す種別の情報と共に前記第２のサーバ装置に送信する送信部を有する。前記第２のサーバ装置は、前記第１のサーバ装置から前記第１の情報または前記第２の情報を受信する受信部を有する。そして、前記第２のサーバ装置は、前記受信部によって受信した種別の情報と、前記受信した情報によって特定される前記記憶部のレコードの状況とに応じて、前記受信した情報のレコードを前記記憶部に生成する生成部を有する。

新たにクラスタシステムに組み込んだサーバのデータ同期が完了するまでの時間を短縮できる。

図１は、実施例１に係るクラスタシステムの全体構成例を示す図である。 図２は、実施例２に係る現用系サーバの構成を示す機能ブロック図である。 図３は、記憶部が有するレコードのデータ構造例を示す図である。 図４は、現用系サーバが送信するログのデータ構造例を示す図である。 図５は、実施例２に係る待機系サーバの構成を示す機能ブロック図である。 図６は、待機系サーバの更新ログおよび同期ログの適用判定基準の例を示す図である。 図７は、実施例２に係る組み込みサーバの構成を示す機能ブロック図である。 図８は、組み込みサーバの更新ログおよび同期ログの適用判定基準の例を示す図である。 図９は、実施例２に係る現用系サーバが実行する更新ログ送信処理の流れを示すフローチャートである。 図１０は、実施例２に係る現用系サーバが実行する同期ログ送信処理の流れを示すフローチャートである。 図１１は、実施例２に係る待機系サーバが実行する処理の流れを示すフローチャートである。 図１２は、実施例２に係る組み込みサーバが実行する処理の流れを示すフローチャートである。 図１３は、同期制御プログラムを実行するコンピュータのハードウェア構成の例を示す図である。

以下に、本願の開示するクラスタシステム、同期制御方法、サーバ装置および同期制御プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

図１は、実施例１に係るクラスタシステムの全体構成例を示す図である。図１に示すように、このシステムは、クライアント装置１、クライアント装置２、クライアント装置３、クラスタシステム５、組み込みサーバ５０がインターネットなどのネットワーク等で通信可能に接続されている。

クライアント装置１、クライアント装置２、クライアント装置３は、エンドユーザが使用するコンピュータ装置であり、クラスタシステム５の現用系サーバ１０に対して、データの書き込みやデータの読み出しを実行する。また、ここでは、各クライアント装置がエンドユーザのコンピュータ装置である例を示したが、これに限定されるものではなく、例えばＷｅｂサーバやアプリケーションサーバなどのサーバ装置であってもよい。

クラスタシステム５は、現用系サーバ１０と、複数の待機系サーバ２０−１から２０−ｎ（ｎ：自然数）とを有し、無停止運転を実現して、各クライアント装置のデータを記憶するシステムである。このクラスタシステム５は、現用系サーバ１０が保持するデータベースと各待機系サーバが保持するデータベースとがミラー化されている。例えば、現用系サーバ１０は、データ更新された場合には、更新データを各待機系サーバに送信し、各待機系サーバは、更新データで自装置のデータベースを更新する。

また、クラスタシステム５では、現用系サーバ１０でハードウェア故障やネットワーク障害等が発生した場合に、自動で待機系サーバに切り替り、クライアント装置へのサービスを継続する。例えば、現用系サーバ１０で障害が発生した場合には、待機系サーバ２０−１が現用系サーバに昇格する。なお、障害の検出、待機系サーバの現用系サーバへの昇格等の手法については、クラスタシステムに利用される一般的なソフトウェア等を用いることができる。

また、本実施例では、クラスタシステム５が有する各サーバは、クライアントのデータを管理するデータベースサーバとして説明するが、これに限定されるものではなく、データベースの同期を実行するＷｅｂサーバやアプリケーションサーバであってもよい。

現用系サーバ１０は、クライアントのデータと該データの所在を示す情報とレコードの状況を示す情報とをレコードとしてＤＢ１０ａを有し、各クライアント装置から各種要求を受信して応答するデータベースサーバである。例えば、現用系サーバ１０は、クライアント装置１からデータ検索要求を受信した場合に、ＤＢ１０ａから該当するデータを検索し、検索結果をクライアント装置１に応答する。また、現用系サーバ１０は、クライアント装置１からデータ更新要求を受信した場合に、ＤＢ１０ａから該当するデータを検索してデータを更新し、更新結果をクライアント装置１に応答する。

この現用系サーバ１０は、送信部１０ｂを有し、クラスタシステム５に新たなサーバである組み込みサーバ５０が組み込まれた場合に、データベースの同期を実行する。具体的には、送信部１０ｂは、ＤＢ１０ａが有するレコードを第１の情報として第１の情報を示す種別の情報と共に組み込みサーバ装置５０に送信するとともに、レコードの更新が発生した場合には、更新されたレコードを第２の情報として第２の情報を示す種別の情報と共に第２の情報を組み込みサーバ装置５０に送信する。

待機系サーバ２０−１から待機系サーバ２０−ｎ各々は、現用系サーバ１０の待機系として動作するデータベースサーバである。この待機系サーバ２０−１から待機系サーバ２０−ｎ各々は、現用系サーバ１０と同期の取れたデータベースを有する。なお、待機系サーバが現用系サーバに昇格する順番等についてはユーザが任意に設定できる。また、このクラスタシステム５の信頼性を向上させるために、２台以上の待機系サーバを有することが好ましい。

組み込みサーバ５０は、クラスタシステム５に新たに組み込まれたサーバであり、ＤＢ５０ａと受信部５０ｂと生成部５０ｃとを有し、クラスタシステム５に組み込まれるとデータベースの同期処理を実行する。

ＤＢ５０ａは、クラスタシステム５への組み込み時には空のデータベースであり、同期処理の実行後に、現用系サーバ１０のデータベース１０ａと同期の取れたデータを記憶する。受信部５０ｂは、現用系サーバ１０から第１の情報または第２の情報を受信する。生成部５０ｃは、受信部５０ｂによって受信した種別の情報と、受信した情報によって特定されるＤＢ５０ａのレコードの状況とに応じて、受信した情報を破棄するまたは受信した情報をＤＢ５０ａに適用する。

このように、現用系サーバ１０は、クラスタシステム５に新たに組み込まれた組み込みサーバ５０とのＤＢ同期に関して、ＤＢの情報である第１の情報とＤＢの更新情報である第２の情報とをシリアライズなしに、並行して送信する。組み込みサーバ５０では、受信したログからＤＢ５０ａへの適用可否を判断して処理する。この結果、新たにシステムに組み込んだ待機系サーバのデータ同期が完了するまでの時間を短縮できる。

次に、図１に示したクラスタシステム５が有する各装置の構成例、各装置が実行する処理の流れ等について説明する。なお、待機系サーバ２０−１から待機系サーバ２０−ｎは、同様の構成を有するので、ここでは待機系サーバ２０として説明する。

［現用系サーバの構成］
図２は、実施例２に係る現用系サーバの構成を示す機能ブロック図である。図２に示すように、現用系サーバ１０は、通信インタフェース部１１と記憶部１２と制御部１３とを有する。なお、現用系サーバ１０が有する処理部は、図２に示したものに限定されるものではなく、例えばディスプレイなどの表示部やキーボードなどの入力部を有していてもよい。

通信インタフェース部１１は、ネットワークインターフェースカードなどの通信モジュールであり、他の装置との間の通信を制御する。例えば、通信インタフェース部１１は、各クライアント装置からデータ検索やデータ更新などの要求を受信して制御部１３に出力し、制御部１３から出力された応答をクライアント装置に送信する。また、通信インタフェース部１１は、同期ログや更新ログを各待機系サーバと組み込みサーバ５０に送信し、各サーバから応答を受信する。

記憶部１２は、クライアントのデータが格納されるデータベースを少なくとも１つ保持する半導体メモリ素子やハードディスクなどの記憶装置である。図３は、記憶部１２が有するデータベースが記憶するレコードのデータ構造例を示す図である。図３に示すように、記憶部１２が有するデータベースは、「レコードＩＤ、管理領域、データ領域」を有するレコードで形成される。この「レコードＩＤ」は、ＤＢ１２内のレコードを一意に特定する識別子であり、例えば位置情報やアドレスなどの情報である。

「管理領域」は、更新適用フラグとレコード情報とを有し、レコードの状態を示す管理情報である。「更新適用フラグ」は、更新ログが適用済みであるか否か、言い換えると、更新ログに基づいてレコード操作が実行されたか否かを示す情報であり、例えば適用済みの場合には「ＯＮ」、未適用の場合には「ＯＦＦ」が格納される。「レコード情報」は、レコードすなわちユーザデータの存在を示す情報であり、例えばユーザデータが存在する場合には「レコード有り」、ユーザデータが存在しない場合には「レコード無し」が格納される。「データ領域」は、ユーザデータが格納されるデータ領域である。

制御部１３は、送信制御部１４とレコード更新部１５とを有し、これらによってデータベースの同期処理を実行するＦＰＧＡ（Field−Programmable Gate Array）などの集積回路やＣＰＵ（Central Processing Unit）などの電子回路である。この制御部１３は、クラスタリングを実現するソフトウェアや、クラスタリングを実現するハードウェアを有する。また、制御部１３は、クライアント装置から受信した各要求に対応した処理を実行する。例えば、制御部１３は、クライアント装置からデータ読み出し要求を受信した場合には、当該読み出し要求に含まれるレコードＩＤやアドレス等を用いて、記憶部１２が保持するデータベースから該当するレコードを取得してクライアント装置に応答する。

送信制御部１４は、排他制御部１４ａと同期ログ送信部１４ｂと更新ログ送信部１４ｃとを有し、これらによってデータベースの同期処理を実行する処理部である。また、送信制御部１４は、ネットワークを介して管理者から同期処理の開始指示を受信した場合や、クラスタシステム５に組み込みサーバ５０が組み込まれたことを検出した場合に、同期処理を開始する。

排他制御部１４ａは、同期処理が開始されたタイミングでレコードの更新や追加が発生した場合に、同期ログの送信と更新処理とを排他させる処理部である。例えば、排他制御部１４ａは、同期ログ送信部１４ｂが同期ログを生成するために記憶部１２のデータベースからレコードを読み出すタイミングで、レコード更新部１５によるレコード更新が発生したとする。この場合には、排他制御部１４ａは、同期ログ送信部１４ｂの処理を一時的に停止させて排他制御を実行する。

その後、排他制御部１４ａは、レコード更新部１５によるレコード更新が終了すると、同期ログ送信部１４ｂの処理を再開させて排他制御を解放する。このとき、排他制御部１４ａは、記憶部１２の同期対象のデータベースを参照し、レコード更新処理終了後のレコード数を計数する。そして、排他制御部１４ａは、計数したレコード数を同期対象のレコード数と特定し、特定したレコード数を同期ログ送信部１４ｂに通知してもよい。

同期ログ送信部１４ｂは、送信制御部１４が同期処理を開始し、排他制御部１４ａが排他を解放した場合に、記憶部１２のデータベースのレコードの情報である同期ログを各待機系サーバと組み込みサーバ５０とに送信する。例えば、同期ログ送信部１４ｂは、同期対象のデータベースの先頭のレコードを読み出す。そして、同期ログ送信部１４ｂは、読み出したレコードに含まれるユーザデータを抽出して同期ログを生成する。その後、同期ログ送信部１４ｂは、生成した同期ログを各待機系サーバと組み込みサーバ５０とにマルチキャストで送信する。

この同期ログ送信部１４ｂは、同期ログを送信した後に、当該同期ログを受信した旨の応答を送信先の各サーバから受信すると、次のレコードを読み出して同期ログを生成し、生成した同期ログを各待機系サーバと組み込みサーバ５０とにマルチキャストで送信する。このように、同期ログ送信部１４ｂは、送信した同期ログに対応する応答を受信するたびに、次のレコードについて同期ログを生成して送信を実行する。なお、同期ログ送信部１４ｂは、同期対象のデータベースの最終レコードまで同期ログの送信を繰り返す、または、排他制御部１４ａから通知されたレコード数に到達するまで同期ログの送信を繰り返す。

更新ログ送信部１４ｃは、記憶部１２のデータベースが更新された場合に、更新されたレコードの情報に基づいて更新ログを生成して、各待機系サーバと組み込みサーバ５０とに送信する。例えば、更新ログ送信部１４ｃは、更新ログ生成部１５ｂによって更新ログが生成された場合に、生成された更新ログを各待機系サーバと組み込みサーバ５０とにマルチキャストで送信する。

ここで、同期ログ送信部１４ｂや更新ログ送信部１４ｃが送信するログの情報について説明する。図４は、現用系サーバが送信するログのデータ構造例を示す図である。図４に示すように、ログは、「ログ管理領域」と「データ領域」とを有する。「ログ管理領域」は、ログの管理情報を示す情報であり、「ログ種別、処理種別、レコードＩＤ」を有する。このうち「ログ種別」は、当該ログが同期ログか更新ログかを示す情報であり、例えば「同期ログ」または「更新ログ」が格納される。「処理種別」は、当該ログによって実行される処理内容を示し、例えば「更新、削除、追加」が格納される。「レコードＩＤ」は、図３と同様、レコードを一意に特定する識別子である。「データ領域」は、図３と同様、ユーザデータが格納される。

例えば、同期ログ送信部１４ｂは、データベースから読み出したレコードＡのデータ領域からユーザデータを読み出す。そして、同期ログ送信部１４ｂは、ログ種別を「同期ログ」、処理種別を「追加」、レコードＩＤを「レコードＡ」とする「ログ管理領域」を生成する。その後、同期ログ送信部１４ｂは、生成した「ログ管理領域」に、読み出したユーザデータを格納した「データ領域」を付加して同期ログを生成する。そして、同期ログ送信部１４ｂは、生成した同期ログを送信する。なお、更新ログの生成については後述する。

図２に戻り、レコード更新部１５は、コミット要求受信部１５ａと更新ログ生成部１５ｂと更新適用部１５ｃとコミット応答部１５ｄとを有し、これらによって記憶部１２のデータベースのレコードを更新し、更新データの同期を実行する処理部である。このレコード更新部１５によって、クラスタシステム５の各サーバのデータベースの同期を取り、ミラーリングを実現できる。

コミット要求受信部１５ａは、クライアント装置のアプリケーションがトランザクションを実行している状態で、トランザクションのコミット要求をクライアント装置から受信する処理部である。例えば、コミット要求受信部１５ａは、レコードの追加、更新、削除などのレコード更新をコミット要求として受信し、受信した情報を更新ログ生成部１５ｂに出力する。

更新ログ生成部１５ｂは、コミット要求受信部１５ａから入力されたコミット要求に基づいて更新ログを生成し、更新ログ送信部１４ｃや更新適用部１５ｃに出力する処理部である。ここで、コミット要求がレコードを追加または更新または削除を示す例を用いて、更新ログの生成について説明する。

例えば、更新ログ生成部１５ｂは、コミット要求に含まれるレコードＩＤ＝レコードＢが記憶部１２のデータベースに存在しない場合やレコードＢに対応するユーザデータがデータベースに存在しないとする。この場合、更新ログ生成部１５ｂは、レコードＢを追加したトランザクションのコミット時にレコードＢに対して、ログ種別を「更新ログ」、処理種別を「追加」、レコードＩＤを「レコードＢ」とする「ログ管理領域」を生成する。その後、更新ログ生成部１５ｂは、生成した「ログ管理領域」に、レコードＢのユーザデータを格納した「データ領域」を付加して更新ログを生成する。

また、更新ログ生成部１５ｂは、コミット要求に含まれるレコードＩＤ＝レコードＣに対応するユーザデータが記憶部１２のデータベースに存在し、コミット要求にユーザデータが含まれているとする。この場合、更新ログ生成部１５ｂは、レコードＣを更新したトランザクションのコミット時にレコードＣに対して、ログ種別を「更新ログ」、処理種別を「更新」、レコードＩＤを「レコードＣ」とする「ログ管理領域」を生成する。その後、更新ログ生成部１５ｂは、生成した「ログ管理領域」に、レコードＣのユーザデータを格納した「データ領域」を付加して更新ログを生成する。

また、更新ログ生成部１５ｂは、コミット要求に含まれるレコードＩＤ＝レコードＤに対応するユーザデータが記憶部１２のデータベースに存在し、コミット要求にユーザデータが含まれていないとする。この場合、更新ログ生成部１５ｂは、レコードＤを削除したトランザクションのコミット時にレコードＤに対して、ログ種別を「更新ログ」、処理種別を「削除」、レコードＩＤを「レコードＤ」とする「ログ管理領域」を生成する。その後、更新ログ生成部１５ｂは、生成した「ログ管理領域」に、空の「データ領域」を付加して更新ログを生成する。

更新適用部１５ｃは、更新ログ送信部１４ｃによって送信された更新ログの受信応答を各サーバから受信した場合に、更新ログ生成部１５ｂが生成した更新ログに基づいてデータベースを操作する処理部である。

例えば、更新適用部１５ｃは、更新ログが「処理種別＝追加、レコードＩＤ＝レコードＢ、ユーザデータ＝ＸＸＸ」である場合には、記憶部１２のデータベースに、データ領域にＸＸＸを格納した新たなレコードＢを生成する。また、更新適用部１５ｃは、更新ログが「処理種別＝更新、レコードＩＤ＝レコードＣ、ユーザデータ＝ＹＹＹ」である場合には、記憶部１２のデータベースのレコードＣのデータ領域をＹＹＹに更新する。また、更新適用部１５ｃは、更新ログが「処理種別＝削除、レコードＩＤ＝レコードＤ、ユーザデータ＝（空白）」である場合には、レコードＤに対応付けられたデータ領域を削除する。

図２に戻り、コミット応答部１５ｄは、各サーバから更新ログが受信されたことを示す応答を受信するとともに、更新適用部１５ｃによるレコード更新が終了した場合に、受信されたコミット要求に対するコミット応答をクライアント装置に送信する。ここで送信されたコミット応答をクライアント装置が受信することで、クライアント装置で実行されたトランザクションが完了する。

［待機系サーバの構成］
図５は、実施例２に係る待機系サーバの構成を示す機能ブロック図である。図５に示すように、待機系サーバ２０は、通信インタフェース部２１と、記憶部２２と、制御部２３とを有する。なお、待機系サーバ２０についても現用系サーバ１０と同様、図２に示した処理部に限定されるものではなく、例えばディスプレイなどの表示部やキーボードなどの入力部を有していてもよい。

通信インタフェース部２１は、ネットワークインターフェースカードなどの通信モジュールであり、他の装置との間の通信を制御する。例えば、通信インタフェース部２１は、現用系サーバ１０から同期ログや更新ログを受信し、受信したことを示す応答を現用系サーバ１０に送信する。

記憶部２２は、現用系サーバの記憶部１２とミラーリングされるデータベースを保持する半導体メモリ素子やハードディスクなどの記憶装置である。なお、記憶部２２が保持するデータベースを形成するレコードのデータ構造例は、図３と同様なので、詳細な説明は省略する。

制御部２３は、受信部２４と格納制御部２５とを有し、これらによってデータベースの同期処理を実行するＦＰＧＡなどの集積回路やＣＰＵなどの電子回路である。この制御部２３は、クラスタリングを実現するソフトウェアや、クラスタリングを実現するハードウェアを有する。また、制御部２３は、当該待機系サーバ２０が現用系サーバに昇格した場合に、図２に示した現用系サーバ１０の制御部１３が実行する各処理部と同様の動作を実行する。

受信部２４は、現用系サーバ１０から同期ログまたは更新ログを受信する処理部である。例えば、受信部２４は、通信インタフェース部２１を介して、現用系サーバ１０がマルチキャストで送信した同期ログまたは更新を受信し、受信した各ログを格納制御部２５に出力する。また、受信部２４は、現用系サーバ１０から更新ログまたは同期ログを受信した場合に、通信インタフェース部２１を介して、現用系サーバ１０に受信したことを示す応答を送信する。なお、更新ログ適用部２５ａや同期ログ適用部２５ｂなどの他の処理部が応答を送信してもよい。

格納制御部２５は、受信部２４によって受信されたログの種別と、受信されたログによって特定されるデータベースのレコードの状況とに応じて、受信したログに基づいたレコードを記憶部２２に生成する処理部である。格納制御部２５は、更新ログ適用部２５ａと同期ログ適用部２５ｂとを有し、これらによって同期処理を実行する。

更新ログ適用部２５ａは、受信された更新ログに基づいて、記憶部２２がデータベースにレコードを生成する処理部である。ここで、更新ログ適用部２５ａが更新ログの適用可否を判定する判定基準の例を説明する。図６は、待機系サーバの更新ログおよび同期ログの適用判定基準の例を示す図である。ここでは、図６に示すうち、更新ログについて説明する。なお、図６の判定基準は、制御部２３が有する内部メモリ等に格納しておき、各適用部が参照するようにしてもよく、プログラム等で実装してもよい。

図６は、受信ログの種別である「更新ログ」に「レコード状態」と「処理種別」とを対応付けている。「レコード状態」は、図３に示したレコードのデータ構造例の管理領域に該当し、「処理種別」は、図４に示したログ管理領域に該当する。図６では、「受信ログ、レコード状態（有無情報、更新適用フラグ）、処理種別（更新、追加、削除）」として「更新ログ、有り、ＯＮ、レコード更新、−、レコード削除」、「更新ログ、有り、ＯＦＦ、レコード更新、−、レコード削除」を対応付けている。また、「受信ログ、レコード状態（有無情報、更新適用フラグ）、処理種別（更新、追加、削除）」として「更新ログ、無し、−、−、レコード追加、−」を対応付けている。なお、ここで示した「−」は、該当するものがないことを示す。

したがって、更新ログ適用部２５ａは、「ログ種別が「更新ログ」、処理種別が「更新」、レコードＩＤが「００１」」である更新ログを受信した場合に、レコードＩＤ＝００１に該当するレコードを記憶部２２から検索する。続いて、更新ログ適用部２５ａは、検索で得られたレコードＩＤ＝００１に該当するレコードの「更新適用フラグ」を参照する。そして、更新ログ適用部２５ａは、「更新適用フラグ」が「ＯＮ」の場合、図６の「受信ログ＝更新ログ、レコード状態（有無情報＝有り、更新適用フラグ＝ＯＮ）、処理種別＝更新」に該当すると判定する。その後、更新ログ適用部２５ａは、受信した更新ログのデータ領域に格納される「ユーザデータ」を、レコードＩＤ＝００１のデータ領域に格納してレコードＩＤ＝００１のレコードを更新する。

同様に、更新ログ適用部２５ａは、「更新適用フラグ」が「ＯＦＦ」の場合も、図６の「受信ログ＝更新ログ、レコード状態（有無情報＝有り、更新適用フラグ＝ＯＦＦ）、処理種別＝更新」に該当すると判定する。その後、更新ログ適用部２５ａは、受信した更新ログのデータ領域に格納される「ユーザデータ」を、レコードＩＤ＝００１のデータ領域に格納してレコードＩＤ＝００１のレコードを更新する。このとき、更新ログ適用部２５ａは、レコードＩＤ＝００１の管理領域の更新適用フラグを「ＯＦＦ」から「ＯＮ」に変更する。

また、更新ログ適用部２５ａは、「ログ種別が「更新ログ」、処理種別が「削除」、レコードＩＤが「００１」」である更新ログを受信した場合に、レコードＩＤ＝００１に該当するレコードを記憶部２２から検索する。続いて、更新ログ適用部２５ａは、検索で得られたレコードＩＤ＝００１に該当するレコードの「有無情報」と「更新適用フラグ」とを参照する。

そして、更新ログ適用部２５ａは、レコードＩＤ＝００１の「有無情報」が「有り」かつ「更新適用フラグ」が「ＯＮ」の場合には、図６の「受信ログ＝更新ログ、レコード状態（有無情報＝有り、更新適用フラグ＝ＯＮ）、処理種別＝削除」に該当すると判定する。その後、更新ログ適用部２５ａは、レコードＩＤ＝００１に対応付けられた「データ領域」を削除する。

同様に、更新ログ適用部２５ａは、レコードＩＤ＝００１の「有無情報」が「有り」かつ「更新適用フラグ」が「ＯＦＦ」の場合、図６の「受信ログ＝更新ログ、レコード状態（有無情報＝有り、更新適用フラグ＝ＯＦＦ）、処理種別＝削除」に該当すると判定する。その後、更新ログ適用部２５ａは、レコードＩＤ＝００１に対応付けられた「データ領域」を削除する。このとき、更新ログ適用部２５ａは、レコードＩＤ＝００１の管理領域の更新適用フラグを「ＯＦＦ」から「ＯＮ」に変更する。なお、更新ログ適用部２５ａは、レコードＩＤ＝００１のレコード自体を削除するようにしてもよい。

また、更新ログ適用部２５ａは、「ログ種別が「更新ログ」、処理種別が「追加」、レコードＩＤが「０１１」」である更新ログを受信したとする。この場合、更新ログ適用部２５ａは、当該更新ログのデータ領域に格納される「ユーザデータ」を抽出する。そして、更新ログ適用部２５ａは、レコードＩＤ＝０１１に対応付けられた「更新適用フラグ」を「ＯＮ」にするとともに「レコード情報」を「有り」に変更する。その後、更新ログ適用部２５ａは、当該レコードＩＤに対応付けられた「データ領域」に、更新ログから抽出した「ユーザデータ」を格納する。このようにして、更新ログ適用部２５ａは、記憶部２２が保持するデータベースに新たなレコードすなわち新たなデータ領域を生成する。

同期ログ適用部２５ｂは、受信された同期ログに基づいて、記憶部２２がデータベースにレコードを生成する処理部である。ここで、図６を用いて、同期ログ適用部２５ｂが同期ログの適用可否を判定する判定基準の例を説明する。図６に示すように、「受信ログ、レコード状態（有無情報、更新適用フラグ）、処理種別（更新、追加、削除）」として「同期ログ、有り、−、受信ログ破棄」、「同期ログ、無し、−、受信ログ破棄」を対応付けている。なお、ここで示した「−」は該当するものがないことを示す。つまり、同期ログ適用部２５ｂは、現用系サーバ１０から同期ログを受信した場合には、レコードの状態に関係なく、記憶部２２への適用を行わずに破棄する。

［組み込みサーバの構成］
図７は、実施例２に係る組み込みサーバの構成を示す機能ブロック図である。図７に示すように、組み込みサーバ５０は、通信インタフェース部５１と、記憶部５２と、制御部５３とを有する。なお、組み込みサーバ５０についても現用系サーバ１０と同様、図２に示した処理部に限定されるものではなく、例えばディスプレイなどの表示部やキーボードなどの入力部を有していてもよい。

通信インタフェース部５１は、ネットワークインターフェースカードなどの通信モジュールであり、他の装置との間の通信を制御する。例えば、通信インタフェース部５１は、現用系サーバ１０から同期ログや更新ログを受信し、受信したことを示す応答を現用系サーバ１０に送信する。

記憶部５２は、半導体メモリ素子やハードディスクなどの記憶装置であり、組み込み時にはデータおよびレコードが存在しない状態である。なお、記憶部２２のデータベースに生成されるレコードのデータ構造例は、図３と同様なので、詳細な説明は省略する。

制御部５３は、受信部５４と生成部５５とを有し、これらによってデータベースの同期処理を実行するＦＰＧＡなどの集積回路やＣＰＵなどの電子回路である。この制御部５３は、クラスタリングを実現するソフトウェアや、クラスタリングを実現するハードウェアを有する。また、制御部５３は、組み込みサーバ５０が現用系サーバに昇格した場合に、図２に示した現用系サーバ１０の制御部１３が実行する各処理部と同様の動作を実行する。また、制御部５３は、組み込みサーバ５０が待機系サーバとなった場合に、図５に示した待機系サーバ２０の制御部２３が実行する各処理部と同様の動作を実行する。

受信部５４は、現用系サーバ１０から同期ログまたは更新ログを受信する処理部である。例えば、受信部５４は、通信インタフェース部５１を介して、現用系サーバ１０がマルチキャストで送信した同期ログまたは更新を受信し、受信した各ログを生成部５５に出力する。また、受信部５４は、現用系サーバ１０から更新ログまたは同期ログを受信した場合に、通信インタフェース部５１を介して、現用系サーバ１０に受信したことを示す応答を送信する。なお、ここで送信される応答は、第１生成部５５ａや判定部５５ｂ等の他の処理部が送信してもよい。

生成部５５は、受信部５４によって受信されたログの種別と、受信されたログによって特定されるデータベースのレコードの状況とに応じて、受信したログに基づいたレコードを記憶部５２に生成する処理部である。生成部５５は、第１生成部５５ａと判定部５５ｂと第２生成部５５ｃとを有し、これらによって上記処理を実行する。

ここで、生成部５５の各処理部が受信ログの適用可否を判定する判定基準の例を説明する。図８は、組み込みサーバの更新ログおよび同期ログの適用判定基準の例を示す図である。なお、図８の判定基準は、制御部２３が有する内部メモリ等に格納しておき、各処理部が参照ようにしてもよく、プログラム等で実装してもよい。

図８は、受信ログの種別である「更新ログ」および「同期ログ」各々に「レコード状態」と「処理種別」とを対応付けている。「レコード状態」は、図３に示したレコードのデータ構造例の管理領域に該当し、「処理種別」は、図４に示したログ管理領域に該当する。図８では、「受信ログ、レコード状態（有無情報、更新適用フラグ）、処理種別（更新、追加、削除）」として「更新ログ、有り、ＯＮ、レコード更新、−、レコード削除」、「更新ログ、有り、ＯＦＦ、レコード更新、−、レコード削除」を対応付けている。また、「受信ログ、レコード状態（有無情報、更新適用フラグ）、処理種別（更新、追加、削除）」として「更新ログ、無し、−、レコード追加、レコード追加、レコード削除」を対応付けている。

同様に、図８では、「受信ログ、レコード状態（有無情報、更新適用フラグ）、処理種別（更新、追加、削除）」として「同期ログ、有り、−、受信ログ破棄」を対応付けている。また、「受信ログ、レコード状態（有無情報、更新適用フラグ）、処理種別（更新、追加、削除）」として「同期ログ、無し、ＯＮ、受信ログ破棄」、「同期ログ、無し、ＯＦＦ、レコード追加」を対応付けている。なお、ここで示した「−」が、該等するものがないことを示す。

第１生成部５５ａは、現用系サーバ１０から更新ログを受信した場合に、受信された更新ログに基づいたレコードを記憶部５２に生成する。例えば、第１生成部５５ａは、「ログ種別が「更新ログ」、処理種別が「更新」、レコードＩＤが「１００」」である更新ログを受信した場合に、レコードＩＤ＝１００に該当するレコードを記憶部５２から検索する。続いて、第１生成部５５ａは、検索で得られたレコードＩＤ＝１００に該当するレコードの「有無情報」を参照する。

そして、第１生成部５５ａは、レコードＩＤ＝１００の「有無情報」が「有り」である場合に、レコードＩＤ＝１００に該当するレコードの「更新適用フラグ」を参照する。第１生成部５５ａは、「更新適用フラグ」が「ＯＮ」の場合、図８の「受信ログ＝更新ログ、レコード状態（有無情報＝有り、更新適用フラグ＝ＯＮ）、処理種別＝更新」に該当すると判定する。その後、第１生成部５５ａは、受信した更新ログのデータ領域に格納される「ユーザデータ」を、レコードＩＤ＝１００のデータ領域に格納してレコードＩＤ＝１００のレコードを更新する。

同様に、第１生成部５５ａは、「更新適用フラグ」が「ＯＦＦ」の場合も、図８の「受信ログ＝更新ログ、レコード状態（有無情報＝有り、更新適用フラグ＝ＯＦＦ）、処理種別＝更新」に該当すると判定する。その後、第１生成部５５ａは、受信した更新ログのデータ領域に格納される「ユーザデータ」を、レコードＩＤ＝１００のデータ領域に格納してレコードＩＤ＝１００のレコードを更新する。このとき、第１生成部５５ａは、レコードＩＤ＝１００の管理領域の更新適用フラグを「ＯＦＦ」から「ＯＮ」に変更する。

一方、第１生成部５５ａは、レコードＩＤ＝１００の「有無情報」が「無し」である場合にも、レコードＩＤ＝１００に該当するレコードの「更新適用フラグ」を参照する。第１生成部５５ａは、「更新適用フラグ」が「ＯＮ」の場合、図８の「受信ログ＝更新ログ、レコード状態（有無情報＝無し、更新適用フラグ＝ＯＮ）、処理種別＝更新」に該当すると判定する。その後、第１生成部５５ａは、受信した更新ログのデータ領域に格納される「ユーザデータ」を、レコードＩＤ＝１００のデータ領域に格納してレコードＩＤ＝１００のレコードを更新する。

同様に、第１生成部５５ａは、「更新適用フラグ」が「ＯＦＦ」の場合も、図８の「受信ログ＝更新ログ、レコード状態（有無情報＝無し、更新適用フラグ＝ＯＦＦ）、処理種別＝更新」に該当すると判定する。その後、第１生成部５５ａは、受信した更新ログのデータ領域に格納される「ユーザデータ」を、レコードＩＤ＝１００のデータ領域に格納してレコードＩＤ＝１００のレコードを更新する。このとき、第１生成部５５ａは、レコードＩＤ＝１００の管理領域の更新適用フラグを「ＯＦＦ」から「ＯＮ」に変更する。

さらに、第１生成部５５ａは、「ログ種別が「更新ログ」、処理種別が「追加」、レコードＩＤが「１０１」」である更新ログを受信した場合に、レコードＩＤ＝１０１に該当するレコードを記憶部５２から検索する。続いて、第１生成部５５ａは、検索で得られたレコードＩＤ＝１０１に該当するレコードの「有無情報」を参照する。

そして、第１生成部５５ａは、レコードＩＤ＝１０１の「有無情報」が「無し」である場合に、レコードＩＤ＝１０１に該当するレコードの「更新適用フラグ」を参照する。第１生成部５５ａは、「更新適用フラグ」が「ＯＦＦ」の場合、図８の「受信ログ＝更新ログ、レコード状態（有無情報＝無し、更新適用フラグ＝ＯＦＦ）、処理種別＝追加」に該当すると判定する。その後、第１生成部５５ａは、当該更新ログのデータ領域に格納される「ユーザデータ」を抽出する。そして、第１生成部５５ａは、レコードＩＤ＝１０１に対応付けられた「更新適用フラグ」を「ＯＮ」にするとともに「レコード情報」を「有り」に変更する。その後、第１生成部５５ａは、当該レコードＩＤに対応付けられた「データ領域」に、更新ログから抽出した「ユーザデータ」を格納する。このようにして、第１生成部５５ａは、記憶部５２が保持するデータベースに新たなレコードを生成する。

一方、第１生成部５５ａは、レコードＩＤ＝１０１の「更新適用フラグ」が「ＯＮ」の場合、図８の「受信ログ＝更新ログ、レコード状態（有無情報＝無し、更新適用フラグ＝ＯＮ）、処理種別＝追加」に該当すると判定する。この場合も、第１生成部５５ａは、上述した手法で新たなレコードを生成する。

また、第１生成部５５ａは、「ログ種別が「更新ログ」、処理種別が「削除」、レコードＩＤが「１０２」」である更新ログを受信した場合に、「有無情報」や「更新適用フラグ」に関係なく、レコードＩＤ＝１０１に対応する「データ領域」を削除する。ただし、第１生成部５５ａは、「更新適用フラグ」が「ＯＦＦ」であった場合には、「データ領域」を削除するとともに「更新適用フラグ」を「ＯＮ」にする。

判定部５５ｂは、現用系サーバ１０から同期ログを受信した場合に、同期ログで特定される記憶部５２のレコード位置に、更新ログに基づいたレコードが生成済みか否かを判定する。第２生成部５５ｃは、生成済みであると判定された場合には同期ログを破棄し、生成済みでないと判定された場合には同期ログに基づいたレコードを記憶部５２に生成する。

例えば、判定部５５ｂは、レコードＩＤが「２００」の「同期ログ」を受信したとする。そして、判定部５５ｂは、レコードＩＤ＝２００に該当するレコードを記憶部５２から検索し、検索されたレコードの「レコード状態」の「レコード情報」が「有り」であったとする。この場合、第２生成部５５ｃは、検索で得られたレコードＩＤ＝２００に該当するレコードの「更新適用フラグ」を参照する。そして、第２生成部５５ｃは、「更新適用フラグ」が「ＯＮ」の場合、図８の「受信ログ＝同期ログ、レコード状態（有無情報＝有り、更新適用フラグ＝ＯＮ）」に該当すると判定する。その結果、第２生成部５５ｃは、受信された同期ログを処理種別に関係なく破棄する。

また、判定部５５ｂは、「更新適用フラグ」が「ＯＦＦ」の場合も同様に、図８の「受信ログ＝同期ログ、レコード状態（有無情報＝有り、更新適用フラグ＝ＯＦＦ）」に該当すると判定する。その結果、第２生成部５５ｃは、受信された同期ログを処理種別に関係なく破棄する。

また、判定部５５ｂは、レコードＩＤ＝２００に該当するレコードを記憶部５２から検索し、検索されたレコードの「レコード状態」の「レコード情報」が「無し」であったとする。つまり、該当レコードのユーザデータが削除されている状態であるとする。この場合、判定部５５ｂは、検索で得られたレコードＩＤ＝２００に該当するレコードの「更新適用フラグ」を参照する。そして、判定部５５ｂは、「更新適用フラグ」が「ＯＮ」の場合、図８の「受信ログ＝同期ログ、レコード状態（有無情報＝無し、更新適用フラグ＝ＯＮ）」に該当すると判定する。その結果、第２生成部５５ｃは、受信された同期ログを処理種別に関係なく破棄する。

また、判定部５５ｂは、「更新適用フラグ」が「ＯＦＦ」の場合には、図８の「受信ログ＝同期ログ、レコード状態（有無情報＝無し、更新適用フラグ＝ＯＦＦ）に該当すると判定する。その結果、第２生成部５５ｃは、受信された同期ログを記憶部５２が保持するデータベースに適用する。すなわち、第２生成部５５ｃは、当該同期ログのデータ領域に格納される「ユーザデータ」を抽出する。そして、第２生成部５５ｃは、レコードＩＤ＝２００に対応付けられた「更新適用フラグ」を「ＯＮ」に変更するとともに、「レコード情報」を「有り」に変更する。そして、第２生成部５５ｃは、レコードＩＤ＝２００に対応付けられた「データ領域」に、同期ログから抽出したユーザデータを格納する。このようにして、第２生成部５５ｃは、記憶部５２が保持するデータベースに、現用系サーバ１０とミラーリングされたレコードを生成する。

［処理の流れ］
次に、図９から図１３を用いて、各サーバが実行する処理の流れを説明する。ここでは、現用系サーバ１０による処理の流れ、待機系サーバ２０による処理の流れ、組み込みサーバ５０による処理の流れを説明する。現用系サーバ１０の更新処理は、レコードの更新が発生した場合には同期処理が実行中であるか否かに関らず随時実行され、同期処理は、ＤＢの同期が開始された場合には更新処理が実行中であるか否かに関らず実行される。つまり、現用系サーバ１０は、更新処理と同期処理とを並列に実行する。

（現用系サーバによる更新ログ送信処理の流れ）
図９は、実施例２に係る現用系サーバが実行する更新ログ送信処理の流れを示すフローチャートである。図９に示すように、更新ログ生成部１５ｂは、コミット要求受信部１５ａがコミット要求を受信した場合に（Ｓ１０１肯定）、当該コミット要求に基づいて更新ログを生成する（Ｓ１０２）。

続いて、レコード更新部１５は、排他制御部１４ａによって共有排他権を獲得して、テーブルの運用単位に排他権を獲得する（Ｓ１０３）。そして、更新ログ送信部１４ｃは、更新ログ生成部１５ｂによって生成された更新ログを各待機系サーバと組み込みサーバ５０の各々にマルチキャストで送信する（Ｓ１０４）。

その後、更新適用部１５ｃは、各サーバから受信したことを示す応答を受信した場合に（Ｓ１０５肯定）、記憶部１２のデータベースに更新ログを適用する（Ｓ１０６）。そして、レコード更新部１５は、排他制御部１４ａによって共有排他権を解放する（Ｓ１０７）。また、排他制御部１４ａは、トランザクション排他を解放する（Ｓ１０８）。その後、コミット応答部１５ｄは、コミット応答をレコードの更新を要求したクライアント装置に送信する（Ｓ１０９）。その後は、Ｓ１０１に戻り、コミット要求が受信されるたびに、上記処理が実行される。

なお、トランザクション排他とは、例えば複数のトランザクションが同一レコードを同時に更新することによる不整合を防止するために、獲得する排他権のことである。トランザクションの開始時にトランザクション排他を獲得し、トランザクションの終了であるコミット処理時に、トランザクション排他は解放される。

（現用系サーバによる同期ログ送信処理の流れ）
図１０は、実施例２に係る現用系サーバが実行する同期ログ送信処理の流れを示すフローチャートである。

図１０に示すように、同期ログ送信部１４ｂは、排他制御部１４ａによって非共有排他権を獲得し（Ｓ２０１）、更新処理が終了するまで、レコードの読み出しを抑止する。続いて、同期ログ送信部１４ｂは、記憶部１２のデータベースを参照して、同期対象となる最終レコードの情報を保持する（Ｓ２０２）。例えば、同期ログ送信部１４ｂは、記憶部１２が有するレコードの最終レコードのレコードＩＤを保持してもよく、レコードの数を計数した結果を保持してもよい。

そして、同期ログ送信部１４ｂは、排他制御部１４ａによって非共有排他権を解放し（Ｓ２０３）、記憶部１２からレコードを読み込み（Ｓ２０４）、読み込んだレコードに基づいて同期ログを生成する（Ｓ２０５）。例えば、同期ログ送信部１４ｂは、記憶部１２が保持するデータベースの先頭のレコードから読み出す。

続いて、同期ログ送信部１４ｂは、生成した同期ログを各待機系サーバと組み込みサーバ５０とにマルチキャストで送信する（Ｓ２０６）。そして、同期ログ送信部１４ｂは、同期対象であり、未送信のレコードが存在する場合には（Ｓ２０７否定）、Ｓ２０４に戻って以降の処理を繰り返す。

そして、同期ログ送信部１４ｂは、同期対象の全レコードについて送信が完了すると（Ｓ２０７肯定）、同期対象の全データベースについて同期ログの送信が完了したかを判定する（Ｓ２０８）。

同期ログが未送信のデータベースが存在する場合には（Ｓ２０８否定）、同期ログ送信部１４ｂは、Ｓ２０１に戻って以降の処理を繰り返す。一方、同期対象の全データベースについて同期ログの送信が完了した場合（Ｓ２０８肯定）、同期ログ送信部１４ｂは、送信した全同期ログについて、受信されたことを示す応答を、送信先の全サーバから受信したか否かを判定する（Ｓ２０９）。

そして、同期ログ送信部１４ｂは、全同期ログに対応した応答を送信先の全サーバから受信した場合に（Ｓ２０９肯定）、同期完了通知を管理者端末に送信したり、表示部に出力したりして、データベースの同期処理を終了する（Ｓ２１０）。

（待機系サーバによる処理の流れ）
図１１は、実施例２に係る待機系サーバが実行する処理の流れを示すフローチャートである。なお、待機系サーバ２０は、現用系サーバ１０からログを受信するたびに、図１１の処理を実行する。

図１１に示すように、受信部２４が現用系サーバ１０からログを受信すると（Ｓ３０１肯定）、格納制御部２５は、受信されたログのログ管理領域を参照して、受信されたログが更新ログか否かを判定する（Ｓ３０２）。

格納制御部２５によって更新ログと判定された場合（Ｓ３０２肯定）、更新ログ適用部２５ａは、更新ログを受信したことを示す応答を現用系サーバ１０に送信する（Ｓ３０３）。その後、更新ログ適用部２５ａは、図６に示した適用判定基準にしたがって、更新ログを記憶部２２が保持するデータベースに適用する（Ｓ３０４）。

一方、格納制御部２５によって更新ログでない判定された場合、すなわち同期ログであると判定された場合（Ｓ３０２否定）、同期ログ適用部２５ｂは、同期ログを受信したことを示す応答を現用系サーバ１０に送信する（Ｓ３０５）。その後、同期ログ適用部２５ｂは、図６に示した適用判定基準にしたがって、同期ログを破棄する（Ｓ３０６）。なお、Ｓ３０４やＳ３０６が実行された後は、Ｓ３０１以降の処理を繰り返す。

（組み込みサーバによる処理の流れ）
図１２は、実施例２に係る組み込みサーバが実行する処理の流れを示すフローチャートである。なお、組み込みサーバ５０は、現用系サーバ１０からログを受信するたびに、図１２の処理を実行する。

図１２に示すように、受信部５４が現用系サーバ１０からログを受信すると（Ｓ４０１肯定）、生成部５５は、受信されたログのログ管理領域を参照して、受信されたログが更新ログか否かを判定する（Ｓ４０２）。

生成部５５によって更新ログと判定された場合（Ｓ４０２肯定）、第１生成部５５ａまたは受信部５４は、更新ログを受信したことを示す応答を現用系サーバ１０に送信する（Ｓ４０３）。その後、第１生成部５５ａは、図８に示した適用判定基準にしたがって、更新ログを記憶部５２が保持するデータベースに適用し（Ｓ４０４）、Ｓ４０１に戻って以降の処理を繰り返す。

一方、生成部５５によって更新ログでない判定された場合、すなわち同期ログであると判定された場合（Ｓ４０２否定）、判定部５５ｂまたは受信部５４は、同期ログを受信したことを示す応答を現用系サーバ１０に送信する（Ｓ４０５）。

その後、判定部５５ｂは、受信された同期ログのログ管理領域のレコードＩＤを参照して、同期ログの適用対象となるレコード位置を特定する（Ｓ４０６）。続いて、判定部５５ｂは、特定したレコードの管理領域のレコード情報を参照してレコードの有無、すなわちデータ領域が存在するか否かを判定する（Ｓ４０７）。そして、判定部５５ｂが、レコードが存在する、すなわちデータ領域が存在すると判定した場合（Ｓ４０７肯定）、第２生成部５５ｃは、受信された同期ログを破棄し（Ｓ４０８）、Ｓ４０１に戻って以降の処理を繰り返す。つまり、この場合には、組み込みサーバ５０は、当該レコード位置に既に更新ログが適用されていると判定し、同期ログを破棄する。

一方、判定部５５ｂは、レコードが存在しない、すなわちデータ領域が存在しないと判定した場合（Ｓ４０７否定）、管理領域の更新適用フラグを参照して、更新ログが適用済みか否かを判定する（Ｓ４０９）。

そして、第２生成部５５ｃは、判定部５５ｂが更新ログ適用済みと判定した場合（Ｓ４０９肯定）、受信された同期ログを破棄し（Ｓ４１０）、Ｓ４０１に戻って以降の処理を繰り返す。一方、第２生成部５５ｃは、判定部５５ｂが更新ログ未適用と判定した場合（Ｓ４０９否定）、受信された同期ログに基づいて記憶部５２が保持するデータベースにレコードを生成し（Ｓ４１１）、Ｓ４０１に戻って以降の処理を繰り返す。

上述したように、実施例２によれば、レコードデータのコピーと更新差分の適用順番の制御を無くして同期処理を実行できるとともに、業務アプリケーションやサーバ自体を停止することなく、異なるサーバ間でのレコードデータの同期を完了することができる。また、同期完了は、レコード数すなわち同期ログの数に依存するので、更新ログに関係なく、同期処理を完了させることができる。また、各サーバに、更新ログを蓄積しておくための領域を設けることもないので、蓄積領域の見積もりを実行することもなく、管理者の負荷を軽減でき、大容量のメモリを用いることもなく、コスト削減にも繋がる。

また、同期処理中であっても、更新ログと同期ログとを並行して処理できるので、動作中のアプリケーションへの影響を小さくすることができる。同期処理開始時に、非共有排他によって更新ログの送信と同期ログの送信を排他制御するので、レコード追加があった場合でも、レコードの送信漏れを抑止できる。よって、現用系にてログ適用制御処理のために、ＣＰＵやメモリ等のＯＳ資源を使用しないため、動作しているアプリケーションへの性能影響を小さくすることができる。

また、現用系サーバ１０は、更新ログを各待機系サーバおよび組み込みサーバ５０に送信するだけでよく、送信先の各サーバに対して、レコードの更新処理を実行しないので、処理負荷を軽減できる。また、現用系サーバ１０は、送信した同期ログの受信応答を各サーバから受信すると、次のレコードについて同期ログの送信処理を開始するので、従来技術に比べて、組み込みサーバ５０へ全同期ログを送信するまでにかかる時間を短縮できる。この結果、従来技術に比べて、同期処理にかかる時間を短縮することができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（同期対象サーバ）
上述した実施例では、第１のサーバ装置を現用系サーバ１０、第２のサーバ装置を組み込みサーバ５０とする例について説明したが、これに限定されるものではない。例えば、現用系サーバ１０と同期が取れている他のサーバを第１のサーバ装置とすることもでき、クラスタシステム５の待機系サーバのうち保守等によりＤＢを再構成した待機系サーバを第２のサーバ装置とすることもできる。

（ログ適用条件）
例えば、図６に示した待機系サーバ２０のログ適用条件や図８に示した組み込みサーバ５０のログ適用条件は任意に変更することができる。例えば、「受信ログ＝同期ログ、有無情報＝無し、更新適用フラグ＝ＯＦＦ」に対して、「受信後に３０秒待機した後、更新ログが適用されていなければ、レコード追加」などの条件を追加することもできる。一例を挙げると、同期ログによって生成したレコードに対して更新ログを適用する場合、同一レコードに対して書き込み処理を２度行うことになるが、上記条件によって、同期ログ受信後３０秒間、同期ログの適用を待機する。その後、３０秒以内に更新ログを受信した場合には、更新ログのみを適用する。このように、同期ログを受信した後、短い間隔で更新ログを受信した場合などに発生する、同一レコードに書き込み処理を削減することができる。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。

図１３は、同期制御プログラムを実行するコンピュータのハードウェア構成の例を示す図である。図１３に示すように、コンピュータ１００は、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、媒体読み取り装置１０６、ＨＤＤ（Hard Disk Drive）１０７、ＲＡＭ（Random Access Memory）１０８を有する。また、図１３に示した各部は、バス１０１で相互に接続される。

入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣ（Network Interface Card）などのインタフェースである。ＨＤＤ１０７は、同期制御プログラム１０７ａとともに、データベース等を記憶する。記録媒体の例としてＨＤＤ１０７を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ、ＣＤ−ＲＯＭ等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記憶媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。

ＣＰＵ１０２は、同期制御プログラム１０７ａを読み出してＲＡＭ１０８に展開することで、図２等で説明した各機能を実行する同期制御プロセス１０８ａを動作させる。すなわち、同期制御プロセス１０８ａは、図２に記載した送信制御部１４が有する各処理部、レコード更新部１５が有する各処理部と同様の機能を実行する。また、同期制御プロセス１０８ａは、図５や図７に示した制御部が有する各処理部と同様の処理を実行させることもできる。このようにコンピュータ１００は、プログラムを読み出して実行することで同期制御方法を実行する情報処理装置として動作する。

例えば、コンピュータ１００は、媒体読み取り装置１０６によって記録媒体から同期制御プログラムを読み出し、読み出された同期制御プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

１、２、３ クライアント装置
５ クラスタシステム
１０ 現用系サーバ
１１ 通信インタフェース部
１２ 記憶部
１３ 制御部
１４ 送信制御部
１４ａ 排他制御部
１４ｂ 同期ログ送信部
１４ｃ 更新ログ送信部
１５ レコード更新部
１５ａ コミット要求受信部
１５ｂ 更新ログ生成部
１５ｃ 更新適用部
１５ｄ コミット応答部
２０ 待機系サーバ
２１ 通信インタフェース部
２２ 記憶部
２３ 制御部
２４ 受信部
２５ 格納制御部
２５ａ 更新ログ適用部
２５ｂ 同期ログ適用部
５０ 組み込みサーバ
５１ 通信インタフェース部
５２ 記憶部
５３ 制御部
５４ 受信部
５５ 生成部
５５ａ 第１生成部
５５ｂ 判定部
５５ｃ 第２生成部

Claims (7)

1. 第１のサーバ装置と第２のサーバ装置とを有し、クライアントのデータと該データの所在を示す情報とレコードの状況を示す情報とをレコードとして記憶する記憶部を各サーバ装置が有するクラスタシステムであって、
   前記第１のサーバ装置は、
   前記記憶部が有するレコードを第１の情報として第１の情報を示す種別の情報と共に前記第２のサーバ装置に送信するとともに、前記レコードの更新が発生した場合には、更新されたレコードを第２の情報として第２の情報を示す種別の情報と共に前記第２のサーバ装置に送信する送信部と、
   前記第２のサーバ装置は、
   前記第１のサーバ装置から前記第１の情報または前記第２の情報を受信する受信部と、
   前記受信部によって受信した種別の情報と、前記受信した情報によって特定される前記記憶部のレコードの状況とに応じて、前記受信した情報のレコードを前記記憶部に生成する生成部と
   を有することを特徴とするクラスタシステム。
2. 前記第２のサーバ装置の生成部は、
   前記第１のサーバ装置から第２の情報を受信した場合に、前記第２の情報のレコードを前記記憶部に生成する第１生成部と、
   前記第１のサーバ装置から第１の情報を受信した場合に、前記第１の情報で特定される前記記憶部のレコード位置に、前記第２の情報のレコードが生成済みか否かを判定する判定部と、
   生成済みであると判定された場合には第１の情報を破棄し、生成済みでないと判定された場合には第１の情報のレコードを前記記憶部に生成する第２生成部とを有することを特徴とする請求項１に記載のクラスタシステム。
3. 前記第１のサーバ装置の送信部は、前記第２のサーバ装置へ送信するレコードを読み出すタイミングで前記レコードの更新が発生した場合に、前記第１の情報を前記記憶部から読み出すことを抑止し、前記レコードの更新が終了した後に前記記憶部から有するレコードの数を送信対象のレコード数と決定して、前記レコードの読み出しを開始することを特徴とする請求項１または２に記載のクラスタシステム。
4. 前記第１のサーバ装置の送信部は、前記クラスタシステムが有する他のサーバ装置と前記第２のサーバ装置との各々に、前記第２の情報または前記第１の情報をマルチキャストで送信することを特徴とする請求項１〜３のいずれか一つに記載のクラスタシステム。
5. 第１のサーバ装置と第２のサーバ装置とを有し、クライアントのデータと該データの所在を示す情報とレコードの状況を示す情報とをレコードとして記憶する記憶部を各サーバ装置が有するクラスタシステムが実行する同期制御方法であって、
   前記第１のサーバ装置が、
   前記記憶部が有するレコードを第１の情報として第１の情報を示す種別の情報と共に前記第２のサーバ装置に送信するとともに、前記レコードの更新が発生した場合には、更新されたレコードを第２の情報として第２の情報を示す種別の情報と共に前記第２のサーバ装置に送信し、
   前記第２のサーバ装置が、
   前記第１のサーバ装置から前記第１の情報または前記第２の情報を受信し、
   受信した種別の情報と、前記受信した情報によって特定される前記記憶部のレコードの状況とに応じて、前記受信した情報のレコードを前記記憶部に生成する、
   ことを特徴とする同期制御方法。
6. クライアントのデータと該データの所在を示す情報とレコードの状況を示す情報とをレコードとして記憶する記憶部を有する記憶元のサーバ装置から、前記記憶部のレコードの情報である第１の情報と第１の情報を示す種別の情報、または、前記レコードの更新が発生した場合に、更新されたレコードの情報である第２の情報と第２の情報を示す種別の情報を受信する受信部と、
   前記受信部によって受信した種別の情報と、受信した情報によって特定される、自装置が有する記憶部のレコードの状況とに応じて、前記受信した情報のレコードを前記記憶部に生成する生成部と
   を有することを特徴とするサーバ装置。
7. コンピュータに、
   クライアントのデータと該データの所在を示す情報とレコードの状況を示す情報とをレコードとして記憶する記憶部を有する記憶元の第１のサーバ装置から、前記記憶部のレコードの情報である第１の情報と第１の情報を示す種別の情報、または、前記レコードの更新が発生した場合に、更新されたレコードの情報である第２の情報と第２の情報を示す種別の情報を受信し、
   受信した種別の情報と、受信した情報によって特定される、前記コンピュータが有する記憶部のレコードの状況とに応じて、前記受信した情報のレコードを前記記憶部に生成する、
   処理を実行させることを特徴とする同期制御プログラム。

Images