(57)【要約】【課題】複数のトランザクションを並行処理しても各データベース間で矛盾の生じることがない多重化データベースシステムにおける同期化方法を提供する。【解決手段】仲介装置２００は、各サーバ１００間における処理結果の矛盾又はサーバ１００の無応答を検出し、処理結果の矛盾を検出したら各応答の中から１つの応答を選定するとともに、選定した応答以外の応答を返したサーバ１００をシステムから切り離し、サーバ１００の無応答を検出したら該無応答のサーバ１００をシステムから切り離し、システムから切り離されたサーバ１００とシステムに組み込まれている正常稼働中のサーバ１００との同期化処理を行い、同期化処理が完了したらシステムから切り離されたサーバ１００を再びシステムに組み込む。【選択図】  図１
2007183728.tif 000002
【特許請求の範囲】
【請求項１】
複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおいて、各データベースサーバを同期化する方法であって、
仲介装置は、クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部と、データベースのスナップショットを記憶するスナップショット記憶部とを備え、
（ａ）（ｉ）データベースサーバから処理要求に対する応答がない事を検出すると該無応答のデータベースサーバをシステムから切り離し、又は、（ｉｉ）各データベースサーバ間における処理結果の矛盾を検出し、処理結果の矛盾を検出したら各応答の中から１つの応答を選定するとともに当該選定した応答をクライアントコンピュータに返し、選定した応答以外の応答を返したデータベースサーバをシステムから切り離し、
（ｂ）正常稼働中のデータベースサーバからデータベースのスナップショットを取得してスナップショット記憶部に記憶する処理を開始し、
（ｃ）クライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、
（ｄ）スナップショットの取得を完了するとスナップショット記憶部に記憶したスナップショットを用いてシステムから切り離されたデータベースサーバのデータベースを復元させ、
（ｅ）システムから切り離されたデータベースサーバにおいて前記スナップショットからのデータベースの復元が完了すると、差分情報記憶部に記憶されている処理要求を該データベースサーバに順次送出し、
（ｆ）差分情報記憶部に記憶されている処理要求についてシステムから切り離されたデータベースにおいて処理が終了すると該データベースサーバをシステムに組み込む
ことを特徴とする多重化データベースシステムにおける同期化方法。
【請求項２】
仲介装置は、前記ステップ（ｃ）において、スナップショットに反映されない処理要求を差分情報として差分情報記憶部に順次記憶する
ことを特徴とする請求項１記載の多重化データベースシステムにおける同期化方法。
【請求項３】
仲介装置は、前記ステップ（ｃ）において、組み込み要求時に正常稼働中のサーバにおいてコミットされていないトランザクションに係る処理要求を組み込み要求時から遡って記憶する
ことを特徴とする請求項２記載の多重化データベースシステムにおける同期化方法。
【請求項４】
仲介装置は、前記ステップ（ｂ）において、正常稼働中のサーバにおいてトランザクションが処理されていないときにスナップショットの取得を開始する
ことを特徴とする請求項１記載の多重化データベースシステムにおける同期化方法。
【請求項５】
仲介装置は、正常稼働中のデータベースサーバが２台以上ある場合には、１台のデータベースサーバを同期化用データベースサーバとして選定し、該同期化用データベースサーバからスナップショットを取得し、スナップショット作成中にクライアントから受信した処理要求は他の正常稼働中のデータベースサーバに中継する
ことを特徴とする請求項１記載の多重化データベースシステムにおける同期化方法。
【請求項６】
複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおいて、
仲介装置は、
クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部と、
データベースのスナップショットを記憶するスナップショット記憶部と、
（ａ）（ｉ）データベースサーバから処理要求に対する応答がない事を検出すると該無応答のデータベースサーバをシステムから切り離し、又は、（ｉｉ）各データベースサーバ間における処理結果の矛盾を検出し、処理結果の矛盾を検出したら各応答の中から１つの応答を選定するとともに当該選定した応答をクライアントコンピュータに返し、選定した応答以外の応答を返したデータベースサーバをシステムから切り離し、（ｂ）正常稼働中のデータベースサーバからデータベースのスナップショットを取得してスナップショット記憶部に記憶する処理を開始し、（ｃ）クライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、（ｄ）スナップショットの取得を完了するとスナップショット記憶部に記憶したスナップショットを用いてシステムから切り離されたデータベースサーバのデータベースを復元させ、（ｅ）システムから切り離されたデータベースサーバにおいて前記スナップショットからのデータベースの復元が完了すると、差分情報記憶部に記憶されている処理要求を該データベースサーバに順次送出し、（ｆ）差分情報記憶部に記憶されている処理要求についてシステムから切り離されたデータベースにおいて処理が終了すると該データベースサーバをシステムに組み込む制御手段とを備えた
ことを特徴とする多重化データベースシステム。
【請求項７】
複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおける仲介装置であって、
クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部と、
データベースのスナップショットを記憶するスナップショット記憶部と、
（ａ）（ｉ）データベースサーバから処理要求に対する応答がない事を検出すると該無応答のデータベースサーバをシステムから切り離し、又は、（ｉｉ）各データベースサーバ間における処理結果の矛盾を検出し、処理結果の矛盾を検出したら各応答の中から１つの応答を選定するとともに当該選定した応答をクライアントコンピュータに返し、選定した応答以外の応答を返したデータベースサーバをシステムから切り離し、（ｂ）正常稼働中のデータベースサーバからデータベースのスナップショットを取得してスナップショット記憶部に記憶する処理を開始し、（ｃ）クライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、（ｄ）スナップショットの取得を完了するとスナップショット記憶部に記憶したスナップショットを用いてシステムから切り離されたデータベースサーバのデータベースを復元させ、（ｅ）システムから切り離されたデータベースサーバにおいて前記スナップショットからのデータベースの復元が完了すると、差分情報記憶部に記憶されている処理要求を該データベースサーバに順次送出し、（ｆ）差分情報記憶部に記憶されている処理要求についてシステムから切り離されたデータベースにおいて処理が終了すると該データベースサーバをシステムに組み込む制御手段とを備えた
ことを特徴とする仲介装置。
【請求項８】
複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおける仲介装置を実現するプログラムであって、
コンピュータを、
クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部と、
データベースのスナップショットを記憶するスナップショット記憶部と、
（ａ）（ｉ）データベースサーバから処理要求に対する応答がない事を検出すると該無応答のデータベースサーバをシステムから切り離し、又は、（ｉｉ）各データベースサーバ間における処理結果の矛盾を検出し、処理結果の矛盾を検出したら各応答の中から１つの応答を選定するとともに当該選定した応答をクライアントコンピュータに返し、選定した応答以外の応答を返したデータベースサーバをシステムから切り離し、（ｂ）正常稼働中のデータベースサーバからデータベースのスナップショットを取得してスナップショット記憶部に記憶する処理を開始し、（ｃ）クライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、（ｄ）スナップショットの取得を完了するとスナップショット記憶部に記憶したスナップショットを用いてシステムから切り離されたデータベースサーバのデータベースを復元させ、（ｅ）システムから切り離されたデータベースサーバにおいて前記スナップショットからのデータベースの復元が完了すると、差分情報記憶部に記憶されている処理要求を該データベースサーバに順次送出し、（ｆ）差分情報記憶部に記憶されている処理要求についてシステムから切り離されたデータベースにおいて処理が終了すると該データベースサーバをシステムに組み込む制御手段として機能させる
ことを特徴とする仲介プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のデータベースマネージメントシステム（ＤＢＭＳ）を並列動作させた多重化データベースシステムに関し、特に各データベース間の同期技術に関する。
【背景技術】
【０００２】
従来の多重化データベースシステムは、例えば特許文献１に記載されたものが知られている。このシステムでは、図５０に示すように、それぞれデータベースを備えた２つの計算機１０１０と計算機１０２０が通信回線により接続されている。各計算機１０１０と１０２０とは、いわゆる二相コミット制御によりデータベース間の同期が図られている。
【０００３】
計算機１０１０は、各種の業務処理を実行する応用プログラム１０１１と、データベース１０１４の検索及び更新の制御を行うとともにトランザクションモニタ１０１３を介して他の計算機１０２０のデータベース１０２４における更新処理との同期を取るデータベース管理システム１０１２と、いわゆる二相コミット制御によってデータベース１０１４と１０２４の更新処理の同期をとるトランザクションモニタ１０１３とから構成される。計算機１０２０についても計算機１０１０と同様に、応用プログラム１０２１と、データベース管理システム１０２２と、トランザクションモニタ１０２３とから構成されている。
【０００４】
本システムにおいて、計算機１０１０のデータベース１０１４と計算機１０２０のデータベース１０２４で同じデータを保持し、更新があった場合でも両方のデータベース１０１４と１０２４に同じ更新が反映される処理手順について説明する。
【０００５】
応用プログラム１０１１は、あるトランザクション内でデータベース１０１４と１０２４を同一クエリで更新する。データベース１０１４は、データベース管理システム１０１２が更新し、データベース１０２４はデータベース管理システム１０２２が更新する。
【０００６】
そして、応用プログラム１０１１は、トランザクションの最後に今までの更新を確定する「ＣＯＭＭＩＴ要求」又は今までの更新を取り消す「ＲＯＬＬＢＡＣＫ要求」を発行する。「ＣＯＭＭＩＴ要求」又は「ＲＯＬＬＢＡＣＫ要求」は、トランザクションモニタ１０１３によってデータベース管理システム１０１２と、トランザクションモニタ１０２３を経由してデータベース管理システム１０２２へ送られる。
【０００７】
例えば、トランザクションモニタ１０１３が「ＣＯＭＭＩＴ要求」を転送した場合、データベース管理システム１０１２と１０２２は、ＣＯＭＭＩＴ実行の可否をトランザクションモニタ１０１３へ返答する。この際、データベース管理システム１０１２と１０２２は実際にはＣＯＭＭＩＴを実行せず、実行の可否のみを答えるのみである。
【０００８】
トランザクションモニタ１０１３及び１０２３は、データベース管理システム１０１２及び１０２２の双方から「ＣＯＭＭＩＴ可」の応答を受け取ると、それぞれデータベース管理システム１０１２及び１０２２に「ＣＯＭＭＩＴ実行」を送信する。「ＣＯＭＭＩＴ実行」を受け取ったデータベース管理システム１０１１２と１０２２は、実際にＣＯＭＭＩＴを実行する。
【０００９】
一方、例えばトランザクションモニタ１０１３が、データベース管理システム１０１２又は１０２２の一方から「ＣＯＭＭＩＴ不可」の応答を受け取った場合、他方の応答が「ＣＯＭＭＩＴ可」であったとしても、データベース管理システム１０１２と１０２２に対して「ＲＯＬＬＢＡＣＫ実行」を送信し、トランザクションをキャンセルする。「ＲＯＬＬＢＡＣＫ実行」を受け取ったデータベース管理システム１０１２と１０２２は、実際にＲＯＬＬＢＡＣＫを実行する。
【００１０】
以上のようにして、どちらか一方のデータベースだけ更新が反映されることを防ぎ、両方のデータベースに対して常に同一の更新が行われるようにすることで、データベース間の同期を保つ。
【特許文献１】特開平６−１６１８６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、上述の従来技術は、複数のデータベースにおける一トランザクションのデータベースの同期を図る方法であって、複数のトランザクション間でのデータベースの同期を制御することはできない。つまり、複数のトランザクションが並行に実行されている状態で、且つ、それらのトランザクションが同一のテーブルの同一行にほぼ同時にアクセスした場合には、データベースの同期が崩れたり、クライアントへ返す返答が一意に決まらないなどの問題が生じる。この問題点について以下に具体的に例示する。
【００１２】
図５１に示すｔｅｓｔ＿ｔａｂｌｅという名前のテーブルを考える。この時、図５２に示すトランザクションＴ１及びＴ２がほぼ同時に実行される場合を考える。トランザクションＴ１はｉｄ＝１０１の行を更新し、トランザクションＴ２はｉｄ＝１０１の行とｉｄ＝１０２の行を更新する。どちらのトランザクションのＵＰＤＡＴＥが先に実行されるかによって、ｉｄ＝１０１の値は異なってしまう。
【００１３】
２つのトランザクション中のＵＰＤＡＴＥが実行される順序は以下の２通りが考えられる。
【００１４】
（１）Ｔ１のＵＰＤＡＴＥの後にＴ２のＵＰＤＡＴＥ
（２）Ｔ２のＵＰＤＡＴＥの後にＴ１のＵＰＤＡＴＥ
（１）の場合、２つのトランザクション実行後にはＴ２のＵＰＤＡＴＥの結果が残り、ｄｅｐａｒｔｍｅｎｔ＝２となる。一方（２）の場合、２つのトランザクション実行後にはＴ１のＵＰＤＡＴＥの結果が残り、ｄｅｐａｒｔｍｅｎｔ＝１となる。すなわち、（１）と（２）では最終的なテーブルｔｅｓｔ＿ｔａｂｌｅのデータが異なる。
【００１５】
つまり、複数のデータベースの初期状態が同じで、且つ、同じトランザクションを実行したとしても、あるＤＢＭＳでは（１）の順で実行し、別のＤＢＭＳは（２）の順で実行した場合、２つのデータベースは同期状態（同じデータを保持している状態）が崩れてしまう問題が発生する。
【００１６】
また、別の例として、図５３に示すトランザクションＴ３及びＴ４がほぼ同時に実行される場合を考える。トランザクションＴ４のＳＥＬＥＣＴがトランザクションＴ３のＣＯＭＭＩＴの前に実行されるか又は後に実行されるかで、トランザクションＴ４のＳＥＬＥＣＴで得られる値は異なってしまう。
【００１７】
トランザクションＴ４のＳＥＬＥＣＴとトランザクションＴ３のＣＯＭＭＩＴが実行される順序は以下の２通りが考えられる。
【００１８】
（３）Ｔ４のＳＥＬＥＣＴの後にＴ３のＣＯＭＭＩＴ
（４）Ｔ３のＣＯＭＭＩＴの後にＴ４のＳＥＬＥＣＴ
（３）の場合、トランザクションＴ４のＳＥＬＥＣＴ実行後には、トランザクションＴ３のＵＰＤＡＴＥが反映されていない古い値ｄｅｐａｒｔｍｅｎｔ＝３が得られる。一方（４）の場合、トランザクションＴ４のＳＥＬＥＣＴ実行後には、トランザクションＴ３のＵＰＤＡＴＥが反映された値ｄｅｐａｒｔｍｅｎｔ＝１が得られる。
【００１９】
つまり、複数のデータベースの初期状態が同じで、且つ、同じトランザクションを実行したとしても、あるＤＢＭＳは（３）の順で実行し、別のＤＢＭＳは（４）の順で実行した場合、得られる値が異なってしまう。
【００２０】
本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、複数のトランザクションを並行処理しても各データベース間で矛盾の生じることがない多重化データベースシステムにおける同期化方法を提供することにある。
【課題を解決するための手段】
【００２１】
本願発明は、複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおける各データベースの同期化処理に関するものである。
【００２２】
ところで、各データベースサーバにおいて複数のトランザクションが並行して処理され、しかも各データベースサーバでトランザクション内での処理要求が互いに異なる順番で処理されると、仲介装置側からは、（１）あるデータベースサーバからの応答はあるが他のデータベースサーバからの応答はない、又は、（２）あるデータベースサーバからの応答と他のデータベースサーバからの応答とが矛盾している（異なっている）、と認識される場合がある。
【００２３】
そこで、本願発明では、仲介装置は、（Ａ）（ｉ）データベースサーバから処理要求に対する応答がない事を検出すると該無応答のデータベースサーバをシステムから切り離し、又は、（ｉｉ）各データベースサーバ間における処理結果の矛盾を検出し、処理結果の矛盾を検出したら各応答の中から１つの応答を選定するとともに当該選定した応答をクライアントコンピュータに返し、選定した応答以外の応答を返したデータベースサーバをシステムから切り離し、（Ｂ）システムから切り離されたデータベースサーバとシステムに組み込まれている正常稼働中のデータベースサーバとの同期化処理を行い、（Ｃ）同期化処理が完了したらシステムから切り離されたデータベースサーバを再びシステムに組み込む。
【００２４】
これにより、あるデータベースサーバからの応答はあるが他のデータベースからの応答がない場合には、当該応答のないデータベースサーバがシステムから切り離される。または、あるデータベースサーバからの応答と他のデータベースサーバからの応答とが矛盾している場合には、各応答の中から１つの応答が選定され、選定された応答以外の応答を返したデータベースサーバがシステムから切り離される。すなわち、各データベースサーバ間で処理要求の処理順序が異なり各データベースサーバ間で非同期になった（各データベースサーバ間で同一であるはずのデータが同一でなくなった）可能性を検出すると、あるデータベースサーバを基準として該データベースサーバと非同期になった可能性のあるデータベースサーバがシステムから切り離される。そして、正常稼働中のデータベースサーバとシステムから切り離されたデータベースサーバとの同期化処理が行われ、同期化処理が完了するとシステムから切り離されたデータベースサーバが再びシステムに組み込まれる。これにより、各データベースサーバの同期化が図られる。
【００２５】
上記同期化処理においては、仲介装置にクライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部と、データベースのスナップショットを記憶するスナップショット記憶部とを設け、データベースサーバがシステムから切り離されている間にクライアントコンピュータから受信した処理要求を差分情報として記憶する。また、仲介装置は、正常稼働中のデータベースサーバからスナップショットを取得してスナップショット記憶部に記憶する。そして、仲介装置は、該該スナップショットを用いて、システムから切り離されたデータベースサーバのデータベースを復元する。その後に、仲介装置は、前記差分情報記憶部に記憶されてた差分情報を当該データベースサーバに順次送信する。データベースサーバは、仲介装置から差分情報として処理要求を処理することで正常稼働中のサーバとの同期化が図れる。
【００２６】
なお、ここでシステムへのデータベースサーバの組み込みとは、多重化データベースシステムを構成するデータベースサーバとして機能するよう仲介装置が当該データベースサーバを取り扱うようにすることを意味する。また、システムからのデータベースサーバからの切り離しとは、多重化データベースシステムを構成するデータベースサーバとして機能しないよう仲介装置が当該データベースサーバを取り扱うようにすることを意味する。したがって、システムに組み込まれているデータベースサーバにはクライアントコンピュータからの処理要求が仲介装置を介して届くが、システムから切り離されたデータベースサーバにはクライアントコンピュータからの処理要求が届かない状態となる。なお、データベースサーバがシステムに組み込まれていること又は切り離されていることと、データベースサーバが仲介装置と通信可能又は不能であることとは無関係である点に留意されたい。つまり、データベースサーバと仲介装置が通信可能な状態にある場合であっても、データベースサーバがシステムに組み込まれていない場合もあり得る。
【発明の効果】
【００２７】
以上説明したように本発明によれば、複数のトランザクションを並行処理することにより各データベースサーバ間で矛盾が生じても、各データベースサーバの同期化が図られるので当該矛盾を解消できる。また、各データベースサーバの同期を維持するための制御処理は、専ら仲介装置でのみ実施するので、データベースそのものは従来の既存のものを無改造で利用できる。さらに、各データベースサーバでは同期を保つために全てのデータベースで同じ順序で更新されることを保証する処理、つまり、更新クエリの順序制御やスケジューリング、それらを実現するためのサーバ間通信、順序制御が失敗した場合のロールバックなどの処理を行う必要がないので、当該処理に伴う処理負荷の増加を防止できる。
【発明を実施するための最良の形態】
【００２８】
（第１の実施の形態）
本発明の第１の実施の形態に係る多重化データベースシステムについて図面を参照して説明する。図１は本実施の形態に係る多重化データベースシステムの全体構成を説明するブロック図である。
【００２９】
この多重化データベースシステムは、図１に示すように、複数のデータベースサーバ（以下「サーバ」と言う）１００と仲介装置２００とをネットワーク３００で接続したものであり、ネットワーク４００を介して１以上のクライアントコンピュータ（以下「クライアント」と言う）５００及びデータベース一致検査装置６００からアクセスされるものである。本実施の形態では、図１に示すように、２台のサーバ１００ａ及び１００ｂを有しており、２台のクライアント５００ａ及び５００ｂからアクセスされる。以降の説明において各サーバ１００を他のサーバ１００と区別する場合には添え字「ａ」「ｂ」を付加するものとする。クライアント５００についても同様である。なお、図１の例では、サーバ１００とクライアント５００はそれぞれ別々のネットワーク３００，４００に接続されているが、同じネットワークに接続されていてもよい。
【００３０】
図１に示すように、仲介装置２００は、ネットワーク４００側にＩＰアドレス172.17.1.1を持っており、これをデータベースサーバのＩＰアドレスとして公開している。クライアント５００やデータベース一致検査装置６００はデータベースにアクセスしたいときはＩＰアドレス172.17.1.1へクエリを送信し、ＩＰアドレス172.17.1.1の仲介装置２００からそのクエリに対する応答パケットを受信する。これは、クライアント５００等にとっては、ＩＰアドレス172.17.1.1を持ったデータベースサーバとパケットを送受信していることと同じである。このＩＰアドレス172.17.1.1を持った仮想的なデータベースサーバを仮想サーバ８００と呼ぶ。この仮想サーバ８００の目的は、サーバ１００が冗長化されていることを隠蔽するためである。つまり、サーバ１００ａとサーバ１００ｂ両方が稼働していようとサーバ１００ｂがダウンしてサーバ１００ａのみが稼働していようとサーバ１００ａとサーバ１００ｂの他に新たなサーバが追加されようとクライアントには影響は無く、動作を変更する必要がない。
【００３１】
サーバ１００は、データを保存・管理するデータベース１０１を備えている。また、サーバ１００は、仲介装置２００等の外部からの指示に応じて再起動を行う。このサーバ１００の再起動によりデータベース１０１が起動する。
【００３２】
データベース１０１は、ＳＱＬ（Structured Query Language）を解して処理を行うＲＤＢＭＳ（Relational Database Management System）である。このようなデータベース１０１としては種々のものがあり、例えばＴｈｅ  ＰｏｓｔｇｒｅＳＱＬ  Ｇｌｏｂａｌ  Ｄｅｖｅｌｏｐｍｅｎｔ  ＧｒｏｕｐによるＰｏｓｔｇｒｅＳＱＬ（http://www.postgres.org/）や、Ｏｒａｃｌｅ社によるＯｒａｃｌｅ（登録商標）（http://www.oracle.com/）などが挙げられる。本実施の形態ではデータベース１０１としてＰｏｓｔｇｒｅＳＱＬを用いるものとする。
【００３３】
また、データベース１０１は、ネットワークを介して他の端末から、スナップショットの作成、及び、スナップショットからのデータベースの復元する機能を有しているものとする。この機能は、通常、データベース１０１のメンテナンスに係る機能として提供されている。例えば、ＰｏｓｔｇｒｅＳＱＬでは、ｐｇ＿ｄｕｍｐ及びｐｓｑｌというツールが用意されており、これらのツールを用いることにより他の端末からスナップショットの取得及びスナップショットからの復元を実施できる。ここで、スナップショットとはデータベース全体の複製データやデータベースを復元するために必要なデータを意味する。一般的に、スナップショット作成開始時にコミットされていないデータがスナップショットに含まれるか否かや、スナップショット作成中にクエリの処理が可能か否かなどはデータベース１０１の仕様によって異なる。本実施の形態では、スナップショット作成開始時にコミットされているデータのみがスナップショットに反映される、つまり、スナップショット作成開始後にコミットされたクエリの内容はスナップショットに反映されない、という事を前提とする。
【００３４】
仲介装置２００は、図２に示すように、本システム内のサーバ１００を管理するサーバ管理表２０１と、トランザクションを管理するトランザクション管理表２０２と、サーバ１００に送信するクエリを一時保存する送信キュー２０３と、クライアント５００から受信したクエリを送信キュー２０３に投入する受信クエリ処理部２０４と、送信キュー２０３からクエリを取り出してサーバ１００に送信するクエリ送信処理部２０５と、クエリ送信処理部２０５で送信したクエリに対する各サーバ１００からの応答の正当性を判定する正当性判定部２０６と、正当性判定部２０６で正当と判定された応答を要求元のクライアント５００等に送信する応答送信処理部２０７と、各サーバ１００間の同期化処理を制御する同期化処理制御部２０８と、同期化処理時にサーバ１００から取得したデータベース１０１のスナップショットを一時記憶するスナップショット記憶部２０９とを備えている。
【００３５】
サーバ管理表２０１は、サーバが正常稼働中でクエリの処理が可能であるか（ａｃｔｉｖｅ）、同期化処理中であるか（ｓｙｎｃ）という状態情報を保存している。また、サーバ１００がシステムから切り離された場合には、当該サーバ１００についてのエントリはサーバ管理表２０１から削除される。図３にサーバ管理表の一例を示す。サーバ管理表２０１は、図３に示すように、サーバ１００を識別するためのサーバＩＤと、サーバの稼働状態から構成されている。図３の例では、サーバ１００ａとサーバ１００ｂとが登録されており、稼働状態は共に正常稼働を示すａｃｔｉｖｅである。また、本実施形態では、サーバＩＤとしてサーバ１００に付されたＩＰアドレスを用いた。
【００３６】
トランザクション管理表２０２は、現在実行中の又は実行開始を保留されているトランザクションの有無を記憶する。図４にトランザクション管理表２０２の一例を示す。図４に示すように、トランザクション管理表２０２は、クライアントを一意に識別するクライアントＩＤとトランザクションを一意に識別するトランザクションＩＤから構成される。これらのペアは、受信クエリ処理部２０４がトランザクション開始時にトランザクション管理表２０２に登録し、応答送信処理部２０７がトランザクション終了時にトランザクション管理表２０２から削除する。クライアントＩＤは、例えばクライアント５００等のＩＰアドレスやポート番号である。トランザクションＩＤは新しいトランザクションが発生する毎に受信クエリ処理部２０４が新たに割り振る。
【００３７】
送信キュー２０３は、クライアント５００等から受信したクエリをサーバ１００に送信する際の送信バッファとしての機能を有するとともに、同期化処理時にクライアント５００から受信したクエリを差分情報として記憶蓄積する機能とを有するものである。
【００３８】
送信キュー２０３のデータ構造について図５を参照して説明する。送信キュー２０３は、クライアント５００から受信したクエリの内容と、そのクエリの属するトランザクションＩＤと、各サーバ１００への送信状態とを記憶する。トランザクションＩＤは、トランザクション管理表２０２から取得される。各サーバ１００への送信状態は、システムに属する各サーバ１００毎に記憶される。
【００３９】
送信キュー２０３の各サーバ１００への送信状態は、「未送信」，「送信完了」，「保留」，「保留解除」の４つの値を取りうる。「未送信」は、特に保留することなく当該サーバ１００に送信予定であるが未だ送信されていない状態である。「送信完了」は、当該サーバ１００への送信が完了した状態である。「保留」は、サーバ１００のシステムへの組み込み処理中に、当該サーバ１００へ転送されることなく保留されている状態である。「保留解除」は、「保留」状態が解除されたが未送信の状態である。送信キュー２０３の各エントリは、全てのサーバ１００についての送信状態が「送信完了」になり、且つ、当該クエリの属するトランザクションが終了すると送信キュー２０３から削除される。
【００４０】
受信クエリ処理部２０４は、クライアント５００からのクエリをネットワーク４００経由で受信すると、当該クエリを解析して新規トランザクションの開始を検出した場合にはトランザクション管理表２０２に該トランザクションを登録するとともに、サーバ管理表２０１を参照して受信クエリを送信キュー２０３に投入する。
【００４１】
受信クエリ処理部２０４が新規トランザクションの開始を検出する方法は、ＤＢＭＳの種類によって異なる。例えば前述のＰｏｓｔｇｒｅＳＱＬの場合は、トランザクションの開始はクライアント５００等が「ＢＥＧＩＮ」というＳＱＬを送信した時であり、トランザクションの終了はクライアント５００等が「ＣＯＭＭＩＴ」「ＲＯＬＬＢＡＣＫ」というＳＱＬを送信した時である。また、Ｏｒａｃｌｅの場合は、トランザクションの開始はクライアント５００等が有効なＳＱＬを送信したときであり（明示的なトランザクションの開始を宣言するＳＱＬは無い）、トランザクションの終了はクライアント５００等が「ＣＯＭＭＩＴ」「ＲＯＬＬＢＡＣＫ」というＳＱＬを送信した時である。また、サーバ１００がＡＵＴＯ  ＣＯＭＭＩＴモードで動作する場合には、クライアント５００等から受信したＳＱＬ文はそれぞれ１つの独立したトランザクションに属していると解釈できるので、クライアント５００等からＳＱＬを受信する毎に、該ＳＱＬ実行前にトランザクションが開始されるとともにＳＱＬ実行後に当該トランザクションが終了したこととして扱うことができる。
【００４２】
受信クエリ処理部２０４が受信クエリを送信キュー２０３に投入する際には以下のようにして各サーバ１００についての送信状態を設定する。サーバ管理表２０１のサーバ稼働状態が「ａｃｔｉｖｅ」である場合には、当該サーバ１００については送信状態を「未送信」とする。また、サーバ管理表２０１のサーバ稼働状態が「ｓｙｎｃ」の場合であって、当該サーバ１００に対するクエリの転送処理が未だ始まっていない場合には、当該サーバ１００については送信状態を「保留」とする。すなわち、本実施の形態では、受信クエリを「保留」として送信キュー２０３に記憶することにより、差分情報の蓄積を図っている。また、サーバ管理表２０１のサーバ稼働状態が「ｓｙｎｃ」の場合であって、当該サーバ１００に対するクエリの転送処理が始まっている場合には、当該サーバ１００については送信状態を「保留解除」とする。
【００４３】
クエリ送信処理部２０５は、送信キュー２０３を監視して、該送信キュー２０３に送信状態が「未送信」又は「保留解除」となっているクエリを古いものから順に取り出し、対象となるサーバ１００に対して送信するとともに、送信キュー２０３の送信状態を「送信完了」に更新する。
【００４４】
正当性判定部２０６は、クエリ送信処理部２０５で各サーバ１００に送信したクエリに対する応答を受信して当該応答の正当性を判定する。この正当性判定は、一台以上のサーバ１００間でのクエリ処理の正当性を判定するものである。具体的には、サーバ１００が３台以上ある場合には多数決で決める方法や、受信した応答を所定のルールに基づいて判断する方法がある。例えば、クライアント５００からの「参照」要求に対して「更新成功」という応答が返ってきた場合、正常であればそのような応答はあり得ないので（参照成功など参照に関する応答のはず）、この応答は正しくないと判断する。また、当該応答に係るパケット中にデータ長フィールドがある場合、このデータ長フィールドの値と実際に受信したパケット長を比較し、異なる場合は正しくないと判断する。また、複数のサーバ１００の中からＭａｓｔｅｒサーバを予め１台決めておき、このサーバ１００からの応答を常に正しいと判断する。また、上記複数の方法を併用する方法もある。例えば、３台で多数決を行った結果、応答の中身が全てバラバラであり、多数派の応答を決められない場合はＭａｓｔｅｒサーバの応答を正しいと判断する。正常稼働しているサーバ１００が１つだけの場合は、そのサーバ１００からの応答を正常と判断する。なお、正常稼働しているサーバ１００の台数はサーバ管理表２０１を参照することにより認識できる。正当性判定部２０６は、正当性判定の結果、正当でない応答を返したサーバ１００を検出すると、サーバ管理表２０１及び送信キュー２０３から当該サーバ１００についてのエントリを削除するとともに、該サーバ１００に対して再起動指示を送出する。これにより、当該サーバ１００にはクエリが送信されなくなるので、該サーバ１００はシステムから切り離されたことになる。また、当該サーバ１００は再起動指示に応じて再起動処理を行う。
【００４５】
応答送信処理部２０７は、正当性判定部２０６において正当と判断された応答であって、該応答の送信元サーバ１００の稼働状態が「ａｃｔｉｖｅ」の場合、当該応答の１つを処理要求元のクライアント５００等に返す。また、応答送信処理部２０７は、サーバ１００から受信した応答がトランザクションの終了に係るものであるかを検出し、トランザクションの終了に係るものである場合には、当該トランザクションについてのエントリをトランザクション管理表２０２から削除する。また、応答送信処理部２０７は、終了したトランザクションに属するクエリであり且つ全てのサーバ１００の送信状態が「送信完了」となったものを送信キュー２０３から削除する。また、応答送信処理部２０７は、「保留解除」のクエリが送信キュー２０３からなくなった場合には、「保留解除」となっていたサーバ１００について、サーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新する。これにより、当該サーバ１００はシステムに組み込まれる。なお、システムへの組み込みのタイミングは、正常稼働中のサーバ１００においてクエリの実行中であっても構わず、またトランザクションが継続中であっても構わない点に留意されたい。
【００４６】
同期化処理制御部２０８は、システム外のサーバ１００（ここでは便宜上「新規サーバ１００」と呼ぶ）をシステムに組み込む際に、該新規サーバ１００とシステム内で正常稼働中のサーバとの同期化処理を制御する。ここで、新規サーバ１００としては、システムに新たに追加するもの、一旦システムから切り離され再びシステムに組み込むものの双方が含まれる。
【００４７】
同期化処理制御部２０８は、データベース同期化要求（システムの組み込み要求）の入力を検出すると、（１）当該新規サーバ１００について稼働状態を「ｓｙｎｃ」にしてサーバ管理表２０１に追加する、（２）送信キュー２０３の送信状態の欄に当該新規サーバ１００についての列を追加する、（３）正常稼働中のサーバ１００の中から同期化処理用のサーバを１台を選定して当該サーバ１００について送信キュー２０３の送信状態が「未送信」となっているものは「保留」に更新する、（４）同期化処理用のサーバ１００において実行中クエリの処理が完了するまで待機し、同期化処理用のサーバ１００において実行中クエリの処理が完了したら該サーバ１００のスナップショットを取得してスナップショット記憶部２０９に保存する処理を開始する、という処理を行う。なお、本実施の形態では、データベース同期化要求は、オペレータが新規サーバ１００の再起動完了を確認した後に所定の入力装置（図示省略）するものとする。
【００４８】
また、同期化処理制御部２０８は、データの整合性を維持するために、前記（１）から（４）のスナップショット作成開始までの処理は１つの処理として取り扱い、排他制御を行う。つまり、同期化処理制御部２０８は、前記（１）から（４）のスナップショット作成開始までの処理を行っている間は、各処理でアクセスするサーバ管理表２０１及び送信キュー２０３に対して、他の機能ブロック（例えば受信クエリ処理部２０４など）からのアクセスを中断させる。
【００４９】
前記（２）において同期化処理制御部２０８は、送信キュー２０３にクエリが残っている場合には、そのクエリについての新規サーバ１００の送信状態は全て「保留」とする。前述したように、送信キュー２０３のエントリは、トランザクションが終了した際に削除される。したがって、送信キュー２０３に残っているクエリは、トランザクションが終了していないクエリであり、前記（４）で作成されるスナップショットには反映されないものである。前記（２）の処理では、このクエリについての送信状態を「保留」とすることで該クエリを差分情報として保持する。
【００５０】
また、同期化処理制御部２０８は、（５）スナップショットの作成が完了したら、当該スナップショットから新規サーバ１００のデータベース１０１を復元させる、（６）データベース１０１の復元が完了すると送信キュー２０３に記憶されている新規サーバ１００の欄の全てのクエリについて送信状態を「保留」から「保留解除」に変更する。これにより、クエリ送信処理部２０５が新規サーバ１００に対して差分情報としてクエリの送信を開始する。「保留解除」になっていたクエリの処理が全て終了すると、応答送信処理部２０７が、当該新規サーバ１００について、サーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新することにより、新規サーバ１００はシステムに組み込まれる。
【００５１】
クライアント５００は、多重化データベースシステムに対して更新クエリ（データベースを更新するリクエスト）や参照クエリ（データベースの内容を参照するリクエスト）などを発行するものである。
【００５２】
データベース一致検査装置６００は、クライアント５００と同様に多重化データベースシステムのクライアントとして動作するものであり、各サーバ１００のデータベース１０１が互いに一致しているか否かを確認するためのクエリを発行する。このクエリは、参照系のものであり、例えば所定のテーブルｔｅｓｔ＿ｔａｂｌｅに対する「ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  ｔｅｓｔ＿ｔａｂｌｅ」などである。データベース一致検査装置６００は、定期的に又はオペレータ等の指示に応じて当該検査用クエリの発行を行う。
【００５３】
次に、本実施の形態に係る多重化データベースシステムの動作について図面を参照して説明する。まず、サーバ１００ａと１００ｂが正常に動作している場合の動作を図６から図８を参照して説明する。
【００５４】
初期状態では、データベース１０１ａと１０１ｂは完全に同一であり、サーバ管理表２０１は図７のようになっているものとする。また、トランザクション管理表２０２と送信キュー２０３は空であるとする。各サーバ１００ａ，１００ｂには、テーブルｔｅｓｔ＿ｔａｂｌｅが存在しているとする。
【００５５】
クライアント５００ａが172.17.1.1宛にトランザクション開始ＳＱＬを含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ１）。受信クエリ処理部２０４は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ａのＩＰアドレスとトランザクション番号を登録する（ステップＳ２）。図８にこのときのトランザクション管理表２０２を示す。そして、このパケットに係るクエリを、サーバ管理表２０１を参照して正常稼働しているサーバ１００（ここではサーバ１００ａ及び１００ｂ）について送信状態を「未送信」にして送信キュー２０３に入れる。
【００５６】
クエリ送信処理部２０５は、送信キュー２０３から送信状態が「未送信」のクエリを取り出し、対応するサーバ１００に該パケットを送信する。ここでは、サーバ１００ａと１００ｂが正常稼働しているので、サーバ１００ａとサーバ１００ｂへ該パケットを転送する（それぞれステップＳ３とＳ４）。そして、各サーバ１００への送信が完了したので各サーバ１００について送信キュー２０３の送信状態を「送信完了」に更新する。正当性判定部２０６は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａから受信するが（ステップＳ５）、この時点では、未だ全ての応答パケットが揃っているわけではないので（この場合、サーバ１００ｂからの応答パケットが来ていない）、正当性判定部２０６は何もせずにサーバ１００ｂからの応答パケットを待つ。そして、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ６）、これで全ての応答パケットが揃ったので、正当性判定部２０６はそれらの応答パケットを互いに比較することでサーバ１００に障害が発生しているか否かをチェックする（ステップＳ７）。この場合、２つの応答パケットは共にトランザクションが正常に開始されたことを示すパケットであるため、障害は無いと判断する。そして、応答送信処理部２０７は正当な応答パケットの１つをクライアント５００ａに返す（ステップＳ８）。
【００５７】
次に、クライアント５００ａは、テーブルｔｅｓｔ＿ｔａｂｌｅを更新するＳＱＬ（ＵＰＤＡＴＥ）を含んだパケットを172.17.1.1へ送信する（ステップＳ９）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働しているサーバ１００について送信状態を「未送信」にして送信キュー２０３に入れる。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、各サーバ１００へパケットを転送し（それぞれステップＳ１０とＳ１１）、送信キュー２０３の送信状態を「送信完了」に更新する。サーバ１００ａは正常にＵＰＤＡＴＥ成功したことを通知する応答パケットを仲介装置２００に送信し、仲介装置２００の正当性判定部２０６がこの応答パケットを受信する（ステップＳ１２）。この時点では全ての応答パケットが全て揃っているわけではないので、正当性判定部２０６は何もせず待機する。そして、正常にＵＰＤＡＴＥ成功したことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ１３）、これで応答パケットが全て揃ったので、正当性判定部２０６はそれら応答パケットを互いに比較することでサーバ１００に障害が発生しているか否かをチェックする（ステップＳ１４）。この場合、２つの応答パケットは共にＵＰＤＡＴＥ成功したことを示すパケットであるため、障害は無いと判断する。そして、応答送信処理部２０７は、正当な応答パケットの１つをクライアント５００ａへ転送する（ステップＳ１５）。
【００５８】
次に、クライアント５００ａは、テーブルｔｅｓｔ＿ｔａｂｌｅへの更新を確定する（実際にデータベースを更新する）ＳＱＬ（ＣＯＭＭＩＴ）を含んだパケットを172.17.1.1へ送信する（ステップＳ１６）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働しているサーバ１００について送信状態を「未送信」にして送信キュー２０３に入れる。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し各サーバ１００へパケットを転送し（それぞれステップＳ１７とＳ１８）、送信キュー２０３の送信状態を「送信完了」に更新する。サーバ１００ａは正常にＣＯＭＭＩＴ成功したことを通知するパケットを仲介装置２００に送信し、仲介装置２００の正当性判定部２０６がこの応答パケットを受信する（ステップＳ１９）。この時点では全ての応答パケットが全て揃っているわけではないので、正当性判定部２０６は何もせず待機する。そして、正常にＣＯＭＭＩＴ成功したことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ２０）、これで応答パケットが全て揃ったので、正当性判定部２０６はそれら応答パケットを互いに比較することでサーバ１００に障害が発生しているか否かをチェックする（ステップＳ２１）。この場合、２つの応答パケットは共にＣＯＭＭＩＴ成功したことを示すパケットであるため、障害は無いと判断する。応答送信処理部２０７は、正当な応答パケットの１つをクライアント５００ａへ転送する（ステップＳ２２）。また、ＣＯＭＭＩＴが正常に完了したことから、トランザクションが終了したことが分かるので、応答送信処理部２０７はトランザクション管理表２０２からこのトランザクションの登録を削除するとともに（ステップＳ２３）、全てのサーバ１００について送信状態が「送信完了」となっているクエリ（ここでは、「ＢＥＧＩＮ」，「ＵＰＤＡＴＥ」，「ＣＯＭＭＩＴ」の３つのクエリ）を送信キュー２０３から削除する（ステップＳ２３）。このときのトランザクション管理表２０２及び送信キュー２０３は再び初期状態（すなわち空）になる。
【００５９】
次に、サーバ１００ｂが故障などで障害になった場合の動作を図９から図１１を参照して説明する。初期状態では、データベース１０１ａと１０１ｂは完全に同一であり、サーバ管理表２０１は前述した図７のようになっているとする。また、トランザクション管理表２０２と送信キュー２０３は空であるとする。
【００６０】
クライアント５００ａが172.17.1.1宛にトランザクション開始ＳＱＬ（ＢＥＧＩＮ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ３０）。受信クエリ処理部２０４は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ａのＩＰアドレスとトランザクション番号を登録する（ステップＳ３１）。図１０にこのときのトランザクション管理表２０２を示す。そして、このパケットに係るクエリを、サーバ管理表２０１を参照して正常稼働しているサーバ１００について送信状態を「未送信」にして送信キュー２０３に入れる。
【００６１】
クエリ送信処理部２０５は、送信キュー２０３から送信状態が「未送信」のクエリを取り出し、対応する各サーバ１００に該パケットを転送する（それぞれステップＳ３２とＳ３３）。次いで、送信キュー２０３の送信状態を「送信完了」に更新する。仲介装置２００の正当性判定部２０６は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａから受信するが（ステップＳ３４）、この時点では、未だ全ての応答パケットが揃っているわけではないので（この場合、サーバ１００ｂからの応答パケットが来ていない）、何もせずにサーバ１００ｂからの応答パケットを待つ。そして、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ３５）、これで全ての応答パケットが揃ったので、正当性判定部２０６はそれら応答パケットを互いに比較することでサーバ１００に障害が発生しているか否かをチェックする（ステップＳ３６）。この場合、２つの応答パケットは共にトランザクションが正常に開始されたことを示すパケットであるため、障害は無いと判断する。そして、応答送信処理部２０７は、正当な応答パケットの１つをクライアント５００ａへ転送する（ステップＳ３７）。
【００６２】
ここで、サーバ１００ｂは、ステップＳ３５で応答パケットを返した後、故障などの障害が発生してダウンしたものとする（ステップＳ３８）。
【００６３】
次に、クライアント５００ａは、テーブルｔｅｓｔ＿ｔａｂｌｅを更新するＳＱＬ（ＵＰＤＡＴＥ）を含んだパケットを172.17.1.1へ送信する（ステップＳ３９）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働しているサーバ１００について送信状態を「未送信」にして送信キュー２０３に入れる。この時点では、仲介装置２００はサーバ１００ｂのダウンを知らないので、サーバ１００ｂが正常稼働しているという情報がサーバ管理表２０１に格納されたままである。したがって、受信クエリ処理部２０４は、サーバ１００ａの欄だけでなくサーバ１００ｂの欄についても送信状態を「未送信」にして送信キュー２０３に受信クエリを格納する。クエリ送信処理部２０５は、送信キュー２０３から送信状態が「未送信」のクエリを取り出して各サーバ１００ａ及び１００ｂにパケットを転送する（それぞれステップＳ４０とＳ４１）。次いで、クエリ送信処理部２０５は、送信キュー２０３の送信状態を「送信完了」に更新する。サーバ１００ａは正常にＵＰＤＡＴＥ成功したことを通知する応答パケットを仲介装置２００に送信し、仲介装置２００の正当性判定部２０６がこの応答パケットを受信する（ステップＳ４２）。この時点では応答パケットが全て揃っているわけではないので、正当性判定部２０６は何もせず待機する。しかし、サーバ１００ｂはダウンしているのでサーバ１００ｂからの応答パケットはいつまで経っても正当性判定部２０６には届かない。これにより正当性判定部２０６はタイムアウトし、サーバ１００ｂのダウンを検知する。そして、正当性判定部２０６はサーバ管理表２０１からサーバ１００ｂのエントリを削除する（ステップＳ４３）。このときのサーバ管理表２０１を図１１に示す。また、サーバ１００ｂについての送信状態の欄を送信キュー２０３から削除する。このときの送信キュー２０３を図１２に示す。次に、応答送信処理部２０７は応答パケットをクライアント５００ａへ転送する（ステップＳ４４）。ここでは、クライアント５００ａにとって、サーバ１００ｂが障害になったかどうかは認識せず、今までと同様に仮想サーバ８００からサービスを受けることができることに注目すべきである。
【００６４】
次に、クライアント５００ａは、テーブルｔｅｓｔ＿ｔａｂｌｅへの更新を確定するＳＱＬ（ＣＯＭＭＩＴ）を含んだパケットを172.17.1.1へ送信する（ステップＳ４５）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働しているサーバ１００について送信状態を「未送信」にして送信キュー２０３に入れる。ここでは、サーバ１００ａについてのみ送信状態が「未送信」で送信キュー２０３にクエリが記憶される。そして、クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、対応するサーバ、この場合、サーバ１００ａのみへ該パケットを転送する（ステップＳ４６）。次いで、送信キュー２０３の送信状態を「送信完了」に更新する。サーバ１００ａは正常にＣＯＭＭＩＴ成功したことを通知する応答パケットを送信し、仲介装置２００の正当性判定部２０６がこの応答パケットを受信する（ステップＳ４７）。ここでは、正常稼働中のサーバ１００が１台のみなので正当性判定部２０６は当該応答パケットを正当と判断し、応答送信処理部２０７は該応答パケットをクライアント５００ａへ転送する（ステップＳ４８）。また、ＣＯＭＭＩＴが正常に完了したことから、トランザクションが終了したことが分かるので、応答送信処理部２０７はトランザクション管理表２０２からこのトランザクションの登録を削除するとともに（ステップＳ４９）、全てのサーバ１００について送信状態が「送信完了」となっているクエリ（ここでは、「ＢＥＧＩＮ」，「ＵＰＤＡＴＥ」，「ＣＯＭＭＩＴ」の３つのクエリ）を送信キュー２０３から削除する（ステップＳ５０）。このときのトランザクション管理表２０２及び送信キュー２０３は再び初期状態（すなわち空）になる。
【００６５】
次に、並行処理される複数のトランザクションについて、各サーバ１００における処理順序が異なった場合について図１３及び図１４のシーケンスチャートを参照して説明する。
【００６６】
ここでは、２台の正常稼働中のサーバ１００ａ及び１００ｂが各クライアント５００からのクエリを処理するものとする。初期状態では、データベース１０１ａと１０１ｂは完全に同一であり、サーバ管理表２０１は図７のようになっているものとする。また、トランザクション管理表２０２と送信キュー２０３は空であるとする。各サーバ１００ａ，１００ｂには、テーブルｔｅｓｔ＿ｔａｂｌｅが存在しているとする。そして、図５１のテーブルｔｅｓｔ＿ｔａｂｌｅに対して、図５２のトランザクションＴ１をクライアント５００ａが発行し、同図のトランザクションＴ２をクライアント５００ｂが発行したものとする。前述したように、この２つのトランザクションＴ１，Ｔ２の処理後におけるデータベース１０１のデータは、各トランザクションの処理順序によって異なった内容になることに注意されたい。
【００６７】
なお、ここではクエリの処理順序に伴うデータベースの不整合とその解決方法の大まかな流れについて説明するため、サーバ管理表２０１の更新動作、送信キュー２０３に対するクエリの入出力、トランザクション管理表２０２の更新動作など、仲介装置２００の各部についての詳細な動作については省略する。
【００６８】
図１３に示すように、クライアント５００ａがトランザクションＴ１を開始するクエリ（ＢＥＧＩＮ）を仲介装置２００に送信し（ステップＳ１０１）、一方、クライアント５００ｂがトランザクションＴ２を開始するクエリ（ＢＥＧＩＮ）を仲介装置２００に送信する（ステップＳ１０２）。仲介装置２００は、各クエリをそれぞれ正常稼働中のサーバ１００ａ及び１００ｂに転送する（ステップＳ１０３〜Ｓ１０６）。そして、各サーバ１００ａ及び１００ｂからのそれぞれ応答（ステップＳ１０７〜Ｓ１１０）について正当性をチェックし（図示省略）、正当な応答の１つをそれぞれの要求元のクライアント５００ａ又は５００ｂに転送する（ステップＳ１１１〜Ｓ１１２）。
【００６９】
仲介装置２００からＢＥＧＩＮに対する応答を受信したクライアント５００ａ及び５００ｂは、それぞれのトランザクションに属する次のクエリを仲介装置２００に送信する。本実施例では、クライアント５００ａはトランザクションＴ１のＵＰＤＡＴＥクエリを仲介装置２００に送信し（ステップＳ１１３）、クライアント５００ｂはトランザクションＴ２のＵＰＤＡＴＥクエリを仲介装置２００に送信する（ステップＳ１１４）。クライアント５００ａ及び５００ｂからクエリを受信した仲介装置２００は、当該クエリをそれぞれ正常稼働中のサーバ１００ａ及び１００ｂに転送する（ステップＳ１１５〜Ｓ１１８）。
【００７０】
サーバ１００ａではトランザクションＴ１のＵＰＤＡＴＥクエリがトランザクションＴ２のＵＰＤＡＴＥクエリより先に処理されたとする。トランザクションＴ１のＵＰＤＡＴＥクエリを処理したサーバ１００ａは、処理結果を仲介装置２００に送信する（ステップＳ１１９）。このとき、トランザクションＴ１のＵＰＤＡＴＥクエリによるｔｅｓｔ＿ｔａｂｌｅの当該更新対象行は、トランザクションＴ１がＣＯＭＭＩＴされるまでロックされる。トランザクションＴ２のＵＰＤＡＴＥクエリは上記ロックされている行が更新対象となっているので、当該クエリの処理はロックが解除されるまで保留される（ステップＳ１２０）。
【００７１】
一方、サーバ１００ｂではトランザクションＴ２のＵＰＤＡＴＥクエリがトランザクションＴ１のＵＰＤＡＴＥクエリより先に処理されたとする。トランザクションＴ２のＵＰＤＡＴＥクエリを処理したサーバ１００ｂは、処理結果を仲介装置２００に送信する（ステップＳ１２１）。このとき、トランザクションＴ２のＵＰＤＡＴＥクエリによるｔｅｓｔ＿ｔａｂｌｅの当該更新対象行は、トランザクションＴ２がＣＯＭＭＩＴされるまでロックされる。トランザクションＴ１のＵＰＤＡＴＥクエリは上記ロックされている行が更新対象となっているので、当該クエリの処理はロックが解除されるまで保留される（ステップＳ１２２）。
【００７２】
ここで、サーバ１００ａからのトランザクションＴ１のＵＰＤＡＴＥクエリに対する応答（ステップＳ１１９）が、サーバ１００ｂからのトランザクションＴ２のＵＰＤＡＴＥクエリに対する応答（ステップＳ１２１）よりも先に仲介装置２００に到達したとする。
【００７３】
仲介装置２００は、トランザクションＴ１のＵＰＤＡＴＥクエリについての応答を一方のサーバ１００ａから受信したが（ステップＳ１１９）、他方のサーバ１００ｂからの応答は受信していないので当該応答を待つ（ステップＳ１２３）。これは、前述したように、仲介装置２００において、各サーバ１００ａ及び１００ｂからの応答を互いに比較して正当性を判断するためである。同様に、仲介装置２００は、トランザクションＴ２のＵＰＤＡＴＥクエリについての応答を一方のサーバ１００ｂから受信したが（ステップＳ１２１）、他方のサーバ１００ａからの応答は受信していないので当該応答を待つ（ステップＳ１２４）。
【００７４】
前述のようにサーバ１００ｂにおいてトランザクションＴ１のＵＰＤＡＴＥクエリの処理はロック解除待ちされているので（ステップＳ１２２）、仲介装置２００における当該クエリに対する応答待ち（ステップＳ１２３）はタイムアウトする（ステップＳ１２５）。これにより、仲介装置２００は、サーバ１００ｂが障害になったと判断し、前記ステップＳ１２４の応答待ちをキャンセルし、当該サーバ１００ｂをシステムから切り離す（ステップＳ１２６）。具体的には、サーバ管理表２０１から当該サーバ１００ｂのエントリを削除するとともに、送信キュー２０３からサーバ１００ｂの送信状態の欄を削除する。そして、仲介装置２００は、図１４に示すように、システムから切り離したサーバ１００ｂに対して再起動指示を送信するとともに（ステップＳ１２７）、応答をクライアント５００ａに返す（ステップＳ１２８）。
【００７５】
サーバ１００ｂは、仲介装置２００からの再起動指示を受信すると、自身の再起動を開始する（ステップＳ１２９）。
【００７６】
トランザクションＴ１のＵＰＤＡＴＥクエリについて応答を受信したクライアント５００ａは、更新を確定するクエリ（ＣＯＭＭＩＴ）を仲介装置２００に送信する（ステップＳ１３０）。仲介装置２００は、クライアント５００ａからクエリを受信すると、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａに当該クエリを転送する（ステップＳ１３１）。
【００７７】
サーバ１００ａでは、トランザクションＴ１のＣＯＭＭＩＴクエリを処理することによりロックが解除されてトランザクションＴ２の処理が再開可能となる（ステップＳ１３２）。これにより、サーバ１００ａはトランザクションＴ１のＣＯＭＭＩＴクエリに対する応答を仲介装置２００に返し（ステップＳ１３３）、仲介装置２００は当該応答をクライアント５００ａに転送する（ステップＳ１３４）。次いで、サーバ１００ａはトランザクションＴ２のＵＰＤＡＴＥクエリに対する応答を仲介装置２００に返し（ステップＳ１３５）、仲介装置２００は当該応答をクライアント５００ｂに転送する（ステップＳ１３６）。
【００７８】
トランザクションＴ２のＵＰＤＡＴＥクエリについて応答を受信したクライアント５００ｂは、更新を確定するクエリ（ＣＯＭＭＩＴ）を仲介装置２００に送信する（ステップＳ１３７）。仲介装置２００は、クライアント５００ｂからクエリを受信すると、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａに当該クエリを転送する（ステップＳ１３８）。サーバ１００ａは当該クエリを処理して応答を仲介装置２００に返し（ステップＳ１３９）、仲介装置２００は当該応答をクライアント５００ｂに転送する（ステップＳ１４０）。
【００７９】
ここで、システムから切り離されたサーバ１００ｂの再起動が完了したものとする（ステップＳ１４１）。仲介装置２００のオペレータは、サーバ１００ｂの再起動完了を確認すると、仲介装置２００に対してデータベース同期化要求を入力指示する（ステップＳ１４２）。仲介装置２００は、正常稼働中のサーバ１００ａのデータベース１０１ａと、サーバ１００ｂのデータベース１０１ｂとを同期化させる処理を行う（ステップＳ１４３）。この同期化処理の詳細については後述する。仲介装置２００は、同期化処理が完了したら当該サーバ１００ｂを再びシステムに組み込む（ステップＳ１４４）。システムへの組込処理の詳細についてはステップＳ１４３の同期化処理の詳細と併せて後述する。
【００８０】
以上の処理により、並行処理される複数のトランザクションについて、各サーバ１００における処理順序が異なった場合であっても、各サーバ１００間でデータベース１０１の同期が保たれる。
【００８１】
次に、並行処理される複数のトランザクションについて、各サーバ１００における処理順序が異なった場合の他の例について図１５及び図１６のシーケンスチャートを参照して説明する。
【００８２】
ここでは、２台の正常稼働中のサーバ１００ａ及び１００ｂが各クライアント５００からのクエリを処理するものとする。初期状態では、データベース１０１ａと１０１ｂは完全に同一であり、サーバ管理表２０１は図７のようになっているものとする。また、トランザクション管理表２０２と送信キュー２０３は空であるとする。各サーバ１００ａ，１００ｂには、テーブルｔｅｓｔ＿ｔａｂｌｅが存在しているとする。そして、図５１のテーブルｔｅｓｔ＿ｔａｂｌｅに対して、図５３のトランザクションＴ３をクライアント５００ａが発行し、同図のトランザクションＴ４をクライアント５００ｂが発行したものとする。前述したように、この２つのトランザクションＴ３，Ｔ４の処理後におけるデータベース１０１のデータは、各トランザクションの処理順序には影響されない。しかしながら、前述したように、トランザクションＴ４におけるＳＥＬＥＣＴの結果は各トランザクションＴ３，Ｔ４の処理順序によって異なった内容になることに注意されたい。
【００８３】
なお、ここではクエリの処理順序に伴うデータベースの不整合とその解決方法の大まかな流れについて説明するため、サーバ管理表２０１の更新動作、送信キュー２０３に対するクエリの入出力、トランザクション管理表２０２の更新動作など、仲介装置２００の各部についての詳細な動作については省略する。
【００８４】
図１５に示すように、クライアント５００ａがトランザクションＴ３を開始するクエリ（ＢＥＧＩＮ）を仲介装置２００に送信すると（ステップＳ２０１）、仲介装置２００は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａ及び１００ｂに転送する（ステップＳ２０２，Ｓ２０３）。仲介装置２００は、各サーバ１００ａ及び１００ｂからの応答を受信すると（ステップＳ２０４，Ｓ２０５）、正当な応答の１つをクライアント５００ａに転送する（ステップＳ２０６）。
【００８５】
次いで、クライアント５００ａはトランザクションＴ３の更新クエリ（ＵＰＤＡＴＥ）を仲介装置２００に送信する（ステップＳ２０７）。一方、クライアント５００ｂはトランザクションＴ４を開始するクエリ（ＢＥＧＩＮ）を仲介装置２００に送信する（ステップＳ２０８）。
【００８６】
仲介装置２００は、トランザクションＴ３のＵＰＤＡＴＥクエリを正常稼働中のサーバ１００ａ及び１００ｂに転送するとともに（ステップＳ２０９，Ｓ２１０）、トランザクションＴ４のＢＥＧＩＮクエリを正常稼働中のサーバ１００ａ及び１００ｂに転送する（ステップＳ２１１，Ｓ２１２）。そして、仲介装置２００は、トランザクションＴ３のＵＰＤＡＴＥクエリに対する応答を各サーバ１００ａ及び１００ｂから受信すると（ステップＳ２１３，Ｓ２１４）、正当な応答の１つをクライアント５００ａに転送する（ステップＳ２１５）。また、トランザクションＴ４のＢＥＧＩＮクエリに対する応答を各サーバ１００ａ及び１００ｂから受信すると（ステップＳ２１６，Ｓ２１７）、正当な応答の１つをクライアント５００ｂに転送する（ステップＳ２１８）。
【００８７】
次いで、クライアント５００ａはトランザクションＴ３を確定するクエリ（ＣＯＭＭＩＴ）を仲介装置２００に送信する（ステップＳ２１９）。一方、クライアント５００ｂはトランザクションＴ４の参照クエリ（ＳＥＬＥＣＴ）を仲介装置２００に送信する（ステップＳ２２０）。
【００８８】
仲介装置２００は、トランザクションＴ３のＣＯＭＭＩＴクエリを正常稼働中のサーバ１００ａ及び１００ｂに転送するとともに（ステップＳ２２１，Ｓ２２２）、トランザクションＴ４のＳＥＬＥＣＴクエリを正常稼働中のサーバ１００ａ及び１００ｂに転送する（ステップＳ２２３，Ｓ２２４）。
【００８９】
ここで、一方のサーバ１００ａでは、トランザクションＴ３のＣＯＭＭＩＴクエリがトランザクションＴ４のＳＥＬＥＣＴクエリより先に処理され（ステップＳ２２５，Ｓ２２６）、他方のサーバ１００ｂでは、トランザクションＴ４のＳＥＬＥＣＴクエリがトランザクションＴ３のＣＯＭＭＩＴクエリより先に処理されたものとする（ステップＳ２２７，Ｓ２２８）。これにより、トランザクションＴ４のＳＥＬＥＣＴクエリの応答は、サーバ１００ａからの応答（ステップＳ２２６）と、サーバ１００ｂからの応答（ステップＳ２２７）とは異なったものとなったとする。
【００９０】
仲介装置２００は、トランザクションＴ４のＳＥＬＥＣＴクエリに対する応答が、各サーバ１００ａ及び１００ｂ間で不一致となっているので、何れかのサーバ１００ａ又は１００ｂを選定し、選定したサーバ１００ａ又は１００ｂからの応答を正当なものとする（ステップＳ２２９）。ここで、サーバ１００の選定方法としては、例えば予めＭａｓｔｅｒサーバを定めておいて、このＭａｓｔｅｒサーバを選定する方法、最初に応答を返したサーバを選定する方法、ラウンドロビンにより選定サーバを順次選定する方法、ランダムに選定する方法、各サーバの処理能力・処理負荷などにより選定する方法などが挙げられる。本実施の形態では、サーバ１００ａをＭａｓｔｅｒサーバとして該サーバ１００ａを正当な応答を返したサーバとして選定する。仲介装置２００は、正当でない応答を返したサーバ１００ｂをシステムから切り離す（ステップＳ２３０）。具体的には、サーバ管理表２０１から当該サーバ１００ｂのエントリを削除するとともに、送信キュー２０３からサーバ１００ｂの送信状態の欄を削除する。そして、図１６に示すように、当該サーバ１００ｂに対して再起動指示を送信する（ステップＳ２３１）。
【００９１】
サーバ１００ｂは、仲介装置２００からの再起動指示を受信すると、自身の再起動を開始する（ステップＳ２３２）。
【００９２】
仲介装置２００は、選定したサーバ１００ａから受信した、トランザクションＴ３のＣＯＭＭＩＴクエリに対する応答及びトランザクションＴ４のＳＥＬＥＣＴクエリに対する応答を、それぞれ要求元のクライアント５００ａ，５００ｂに転送する（ステップＳ２３３，Ｓ２３４）。以降、各クライアント５００ａ，５００ｂからのクエリは、正常稼働中のサーバ１００ａで処理する。図１６の例では、クライアント５００ｂがトランザクションＴ４のＣＯＭＭＩＴクエリを仲介装置２００に送信すると（ステップＳ２３５）、仲介装置２００は当該クエリを正常稼働中のサーバ１００ａに転送する（ステップＳ２３６）。そして、仲介装置２００は、当該クエリに対する応答をサーバ１００ａから受信すると（ステップＳ２３７）、この応答を要求元のクライアント５００ｂに返す（ステップＳ２３８）。
【００９３】
ここで、システムから切り離されたサーバ１００ｂの再起動が完了したものとする（ステップＳ２３９）。仲介装置２００のオペレータは、サーバ１００ｂの再起動完了を確認すると、仲介装置２００に対してデータベース同期化要求を入力指示する（ステップＳ２４０）。仲介装置２００は、正常稼働中のサーバ１００ａのデータベース１０１ａと、サーバ１００ｂのデータベース１０１ｂとを同期化させる処理を行う（ステップＳ２４１）。この同期化処理の詳細については後述する。仲介装置２００は、同期化処理が完了したら当該サーバ１００ｂを再びシステムに組み込む（ステップＳ２４２）。システムへの組込処理の詳細についてはステップＳ２４１の同期化処理の詳細と併せて後述する。
【００９４】
以上の処理により、並行処理される複数のトランザクションについて、各サーバ１００における処理順序が異なった場合であっても、クライアント５００には１つの正しい応答のみが処理結果として返される。
【００９５】
なお、この例では、２つのトランザクションＴ３及びＴ４に属するクエリの処理順序が異なっても当該トランザクションＴ３及びＴ４に属する各クエリの中で同一行を更新するクエリは存在しないので、クエリの処理順序が異なることによる各データベース１０１間の不整合は生じない。したがって、この例に限定して考えると、データベース１０１の同期化のための各処理（ステップＳ２３０〜Ｓ２３２，Ｓ２３９〜Ｓ２４２）は不要であるとも考えられる。しかし、本実施の形態では、何らかの原因でデータベース１０１に不整合が潜在していた場合であって、当該不整合について前記ステップＳ２２９を契機に検出した場合にも対処できるように、データベース１０１の同期化のための各処理を実施するようにした。また、この例では、ＳＥＬＥＣＴとＵＰＤＡＴＥの順序不一致による結果不一致について説明したが、他にも、参照系ではＳＥＬＥＣＴ  ＦＯＲ  ＵＰＤＡＴＥ、更新係ではＤＥＬＥＴＥなどの組み合わせで結果不一致が生じる場合がある。本実施の形態では、このような場合であっても図１５及び図１６を参照して説明したシーケンスと同様の処理を行うことによって、データベース１０１の不整合を解消できる。
【００９６】
次に、前記ステップＳ１４３及びＳ２４１における同期化処理の詳細について説明する。本発明における同期化処理では、仲介装置２００が同期化処理開始時において正常稼働しているサーバ１００からデータベース１０１のスナップショットを取得し、このスナップショットを用いて新規サーバ１００のデータベース１０１を復元する。さらに、この処理中に受信したクライアント５００からのクエリを仲介装置２００において差分情報として蓄積する。この差分情報の蓄積は送信キュー２０３を利用する。そして、新規サーバ１００がスナップショットからのデータベース１０１の復元が完了したら仲介装置２００から差分情報を取得して、この差分情報を処理する。
【００９７】
なお、同期化処理の実施は、仲介装置２００からの再起動指示に応じた再起動時に限られない。すなわち、サーバ１００が障害となってシステムから切り離され、その後にシステムに再び組み込む際にも実施される。また、システムを構成するサーバを増設する場合にも実施される。
【００９８】
以下に、サーバ１００ｂをシステムに組み込む場合の同期化動作を図１７から図３１を参照して説明する。このとき注目すべきポイントは、クライアント５００ａ及び５００ｂに対するサービスを続けたままサーバ１００ｂを追加する、つまり、システムダウンさせずにデータベース１０１ａと１０１ｂを同期させることである。
【００９９】
データベース１０１ｂはデータベース１０１ａと同期がとれていない状態、つまり、同一ではない状態である。例えば、データベース１０１ｂは、再起動直前のデータ又は障害発生直前のデータを保持しているかもしれないし、全く新しいサーバの場合には、データを全く持っていない状態かもしれない。本発明では、前者の場合でも古いデータは削除し、データベース１０１ｂはデータを全く保持していないものとしてシステムに組み込む。つまり、古いデータを保持している必要はない。
【０１００】
ここでは、サーバ１００ａのみが正常稼働しているのでサーバ管理表２０１は図２０のようになっているとする。また、トランザクション管理表２０２は空であるとする。さらに、送信キュー２０３は空であり、正常稼働中のサーバ１００ａについてのみ送信状態を記憶する構成となっている。
【０１０１】
図１７に示すように、クライアント５００ａが172.17.1.1宛のトランザクション開始ＳＱＬ（ＢＥＧＩＮ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ３０１）。受信クエリ処理部２０４は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ａのＩＰアドレスとトランザクション番号を登録する（ステップＳ３０２）。図２１にこのときのトランザクション管理表２０２を示す。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａについて送信状態を「未送信」にして受信クエリを送信キュー２０３に入れる（ステップＳ３０３）。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、対応するサーバ１００ａに転送し（ステップＳ３０４）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ３０５）。仲介装置２００の正当性判定部２０６は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ３０６）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７は該応答パケットをクライアント５００ａへ転送する（ステップＳ３０７）。この時の送信キュー２０３を図２２に示す。
【０１０２】
次いで、クライアント５００ａが172.17.1.1宛に、テーブルｔｅｓｔ＿ｔａｂｌｅを更新するＳＱＬ（ＵＰＤＡＴＥ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ３０８）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａについて送信状態を「未送信」にして受信クエリを送信キュー２０３に入れる（ステップＳ３０９）。この時の送信キュー２０３を図２３に示す。
【０１０３】
ここで、サーバ１００ｂが再起動したものとする（ステップＳ３１０）。仲介装置２００のオペレータは、サーバ１００ｂの再起動完了を確認すると、仲介装置２００に対してデータベース同期化要求を入力指示する（ステップＳ３１１）。
【０１０４】
同期化処理制御部２０８は、データベース同期化要求があると、サーバ管理表２０１を参照して同期化用のサーバ１００を選定する。ここでは、正常稼働中のサーバ１００は１台のみなので、サーバ１００ａを選定する。そして、送信キュー２０３のサーバ１００ａについて送信状態が「未送信」となっているエントリを「保留」に更新する（ステップＳ３１２）。また、同期化処理制御部２０８は、同期化用のサーバ１００ａにおいて実行中クエリがないことを確認した後に、新規サーバ１００ｂについて稼働状態を「ｓｙｎｃ」でサーバ管理表２０１に追加するとともに（ステップＳ３１３）、送信キュー２０３の送信状態の欄に当該サーバ１００ｂ用の列を追加する（ステップＳ３１４）。ここで、当該サーバ１００ｂの送信状態は全て「保留」に設定する。この時のサーバ管理表２０１及び送信キュー２０３を図２４，図２５に示す。なお、同期化処理制御部２０８は、上記ステップＳ３１２〜Ｓ３１４の処理は１つの処理として取り扱い、排他制御を行う。つまり、ステップＳ３１２〜Ｓ３１４の処理中には、各ステップでアクセスするサーバ管理表２０１及び送信キュー２０３に対して、他の機能ブロック（例えば受信クエリ処理部２０４やクエリ送信処理部２０５など）からのアクセスを中断させる。
【０１０５】
次いで、同期化処理制御部２０８は、サーバ１００ａのデータベース１０１ａのスナップショットの作成を開始する（ステップＳ３１５）。スナップショットはスナップショット記憶部２０９に保存する。本実施の形態ではデータベース１０１としてＰｏｓｔｇｒｅＳＱＬを利用したので、スナップショットの作成ツールとしてはｐｇ＿ｄｕｍｐを用いた。
【０１０６】
上述したように、本実施の形態で用いるスナップショット作成ツールでは、スナップショット作成中にクエリを実行しても当該スナップショットには影響を与えない。そこで、同期化処理制御部２０８は、同期化用のサーバ１００ａについて送信キュー２０３の各クエリの送信状態を「保留」から「保留解除」に更新する（ステップＳ３１６）。この時の送信キュー２０３を図２６に示す。これにより、クエリ送信処理部２０５による送信キュー２０３からのクエリの送信が再開する。具体的には、クエリ送信処理部２０５は、ＵＰＤＡＴＥクエリを送信キュー２０３から取り出して同期化用サーバ１００ａに送信するとともに（ステップＳ３１７）、送信状態を「送信完了」に更新する（ステップＳ３１８）。正当性判定部２０６は、当該クエリが正常処理されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ３１９）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７が該応答パケットをクライアント５００ａへ転送する（ステップＳ３２０）。この時の送信キュー２０３を図２７に示す。また、スナップショット作成開始以降、クライアント５００から受信したクエリは、同期化用サーバ１００ａについては「未送信」で、新規サーバ１００ｂについては「保留」で送信キュー２０３に投入する。
【０１０７】
ここで、スナップショットの作成処理が完了したものとする（ステップＳ３２１）。同期化処理制御部２０８は、スナップショットの作成処理が完了すると、当該スナップショットを用いて新規サーバ１００ｂのデータベース１０１ｂの復元処理を開始する（ステップＳ３２２）。本実施の形態ではデータベース１０１としてＰｏｓｔｇｒｅＳＱＬを利用したので、スナップショットからの復元ツールとしてはｐｓｑｌを用いた。
【０１０８】
前述したように、スナップショット作成開始以降、クライアント５００から受信したクエリは、同期化用サーバ１００ａについては「未送信」で、新規サーバ１００ｂについては「保留」で送信キュー２０３に投入する。図１８の例では、受信クエリ処理部２０４は、クライアント５００ａからＩＮＳＥＲＴクエリを受信すると（ステップＳ３２３）、同期化用サーバ１００ａについては「未送信」で、新規サーバ１００ｂについては「保留」で当該エリを送信キュー２０３に投入する（ステップＳ３２４）。この時の送信キュー２０３を図２８に示す。そして、クエリ送信処理部２０５は、送信状態が「未送信」となっているクエリを取り出して対応する同期化用サーバ１００ａに転送するとともに（ステップＳ３２５）、送信状態を「送信完了」に更新する（ステップＳ３２６）。正当性判定部２０６は、当該クエリが正常処理されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ３２７）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７が該応答パケットをクライアント５００ａへ転送する（ステップＳ３２８）。
【０１０９】
ここで、新規サーバ１００ｂのデータベース１０１ｂの復元処理が完了したものとする（ステップＳ３２９）。同期化処理制御部２０８は、新規サーバ１００ｂのデータベース１０１ｂのスナップショットからの復元が完了すると、送信キュー２０３に保留となっているクエリを差分情報として送出すべく、新規サーバ１００ｂについて送信状態が「保留」となっているすべてのクエリを、送信状態「保留解除」に更新する（ステップＳ３３０）。この時の送信キュー２０３を図２９に示す。これにより、クエリ送信処理部２０５による送信キュー２０３からの差分情報としてのクエリの送信が開始される。具体的には、クエリ送信処理部２０５は、ＢＥＧＩＮクエリを送信キュー２０３から取り出して新規サーバ１００ｂに送信するとともに（ステップＳ３３１）、送信状態を「送信完了」に更新する（ステップＳ３３２）。正当性判定部２０６は、当該クエリが正常処理されたことを通知する応答パケットを新規サーバ１００ｂから受信する（ステップＳ３３３）。ここで、当該応答は差分情報としてのクエリの処理応答なので、当該応答はクライアント５００へは転送しない。
【０１１０】
受信クエリ処理部２０４は、差分情報転送開始以降クライアント５００から受信したクエリは、同期化用サーバ１００ａについては送信状態を「未送信」で、新規サーバ１００ｂについては送信状態を「保留解除」で送信キュー２０３に投入する。図１９の例では、クライアント５００ａからＣＯＭＭＩＴクエリを受信すると（ステップＳ３３４）、受信クエリ処理部２０４は、同期化用サーバ１００ａについては送信状態を「未送信」で、新規サーバ１００ｂについては送信状態を「保留解除」で送信キュー２０３に投入する（ステップＳ３３５）。この時の送信キュー２０３を図３０に示す。
【０１１１】
以降、クエリ送信処理部２０５は、送信状態が「未送信」及び「保留解除」となっているクエリを対応するサーバ１００に送信するとともに送信状態を「送信完了」に更新する。そして、送信状態が「未送信」であったクエリに対する応答に対しては、正当性判定部２０６が正当性の判定を行うとともに、応答送信処理部２０７が正当な応答の１つをクライアント５００に返す。一方、送信状態が「保留解除」であったクエリに対する応答に対してはクライアント５００への転送は行わない。
【０１１２】
図１９の例では、クエリ送信処理部２０５は、送信状態が「未送信」であるＣＯＭＭＩＴクエリを取り出して対応する同期化用サーバ１００ａに転送するとともに（ステップＳ３３６）、送信状態を「送信完了」に更新する（ステップＳ３３７）。正当性判定部２０６は、当該クエリが正常処理されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ３３８）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７が該応答パケットをクライアント５００ａへ転送する（ステップＳ３３９）。また、このＣＯＭＭＩＴクエリの処理によりトランザクションが終了するので、応答送信処理部２０７は当該トランザクションの登録をトランザクション管理表２０２から削除する（ステップＳ３４０）。
【０１１３】
また、図１９の例では、クエリ送信処理部２０５は、送信状態が「保留解除」となっているＵＰＤＡＴＥクエリ，ＩＮＳＥＲＴクエリ、ＣＯＭＭＩＴクエリを差分情報として順次、新規サーバ１００ｂに転送し、送信状態を「送信完了」に更新する処理を繰り返す（ステップＳ３４１〜Ｓ３４９）。差分情報の送出が完了すると、すなわち送信キュー２０３に送信状態が「保留解除」となっているクエリがなくなると、新規サーバ１００ｂをシステムに組み込むべくサーバ１００ｂについてのサーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新する（ステップＳ３５０）。この時のサーバ管理表２０１を図３１に示す。なお、このステップＳ３５０の処理は、前述のステップＳ１４４，Ｓ２４２の処理に対応するものである。
【０１１４】
以上詳述したように、本実施の形態に係る多重化データベースシステムによれば、複数のトランザクションを並行処理しても、各データベース１０１間で矛盾の生じるおそれがあるような状態、具体的には各サーバ１００においてクエリの処理順序が異なることによるサーバ１００の無応答やサーバ１００間での応答結果の矛盾が生じた状態になると、各データベース１０１間の同期化処理が実行される。これにより、各データベース１０１の同期状態を保つことができる。また、このような状態においても、クライアント５００には１つの正しい応答のみが処理結果として返されるので、システム全体として正常稼働を維持できる。
【０１１５】
なお、上記同期化処理自体は、もともとシステムに組み込まれていたが障害等のためにシステムから切り離されたサーバ１００だけでなく、システム内のサーバ数増大のための新規のサーバ１００であっても適用できる。
【０１１６】
また、上記同期化処理においては、仲介装置２００において差分情報として送信キュー２０３に記憶するデータは、同期化要求（システムの組み込み要求）があった後から蓄積を開始するので、仲介装置２００において同期化用データが増大することがない。これにより、仲介装置２００の記憶容量を節約でき、該記憶容量が溢れることによる障害発生を未然に防止できる。さらに、サーバ１００の切り離しも任意に行うことができる。
【０１１７】
このように、本実施の形態に係る多重化データベースシステムでは、サーバの組み込み及び切り離しを任意に実施できるので、用途や予算などの要求に応じて柔軟なシステム設計を行うことができる。
【０１１８】
なお、本実施形態では、クライアント５００ａ及び５００ｂからの処理要求を多重化データベースシステムで処理する場合について説明したが、データベース一致検査装置６００からの処理要求も同様に処理すればよい。これは、多重化データベースシステムから見るとデータベース一致検査装置６００もクライアントコンピュータの１つだからである。ところで、データベース一致検査装置６００は、前述したように、定期的に又は必要に応じてデータベース一致検査用の参照クエリを仲介装置２００に送信する。これにより、何らかの理由でデータベース１０１間でデータの矛盾が生じた場合であっても、当該クエリによりデータベース１０１間の矛盾が検出され上記同期化処理が実行される。これにより、データベース１０１間の同期をより確実に図ることができる。
【０１１９】
（第２の実施の形態）
本発明の第２の実施の形態に係る多重化データベースシステムについて図面を参照して説明する。本実施の形態が前述の第１の実施の形態と異なる点は、仮想サーバ８００が３台のサーバ１００を備えていること、及び、スナップショットの作成・復元ルーツとしてＳＱＬを用いた汎用的なものを用いる点にある。さらに具体的には、本実施の形態と第１の実施の形態とでは、システムにサーバ１００を組み込む際の同期化処理（第１の実施の形態における図１４のステップＳ１４３及び図１６のステップＳ２４１）の動作が異なり、他の動作については同じである。以下、この同期化処理について詳述する。
【０１２０】
前記第１の実施の形態において同期化処理制御部２０８は、スナップショットの作成ツールとして、スナップショット作成中にクエリを実行しても当該スナップショットには影響を与えないｐｇ＿ｄｕｍｐを用いた。一方、本実施の形態において同期化処理制御部２０８は、データベース１０１に対してＳＥＬＥＣＴなどの一般的なクエリを発行することによりスナップショットを取得し、ＩＮＳＥＲＴクエリ等を発行することによりスナップショットからのデータベース１０１の復元を行う。このような方法を採用することにより、データベース１０１の種類に依存しない汎用的なシステムを構築可能となる。
【０１２１】
ところで、このような汎用的なスナップショットの作成及びデータベースの復元方法では、スナップショット作成開始後に処理された更新クエリがスナップショットに反映するか否かが問題となる。このため、第１の実施の形態のようなシステム構成では、スナップショットの作成中にはクエリの処理を停止する必要がある。そして、これによりクライアント５００へのサービス提供が停止してしまうという問題がある。そこで、本実施の形態では、クライアント５００に対するサービス継続とスナップショット作成とをそれぞれ別のサーバ１００で行うことにより、クライアント５００へのサービス提供を継続するようにしている。以下、本実施の形態に係るシステムの動作について詳述する。
【０１２２】
ここでは、３台のサーバ１００ａ〜１００ｃのうち１台のサーバ１００ｃがシステムから切り離されている状態から、該サーバ１００ｃをシステムに再び組み込む場合について図３２〜図４９を参照して説明する。
【０１２３】
初期状態におけるサーバ管理表２０１を図３７に示す。また、トランザクション管理表２０２は空であるものとする。送信キュー２０３は空であり図３８に示すような構造となっている。
【０１２４】
図３２に示すように、クライアント５００ａが172.17.1.1宛のトランザクション開始ＳＱＬ（ＢＥＧＩＮ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ４０１）。受信クエリ処理部２０４は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ａのＩＰアドレスとトランザクション番号を登録する（ステップＳ４０２）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａ及び１００ｂについて送信状態を「未送信」にして受信クエリを送信キュー２０３に入れる（ステップＳ４０３）。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、対応するサーバ１００ａ及び１００ｂに転送し（ステップＳ４０４，Ｓ４０５）、それぞれ送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４０６）。仲介装置２００の正当性判定部２０６は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａ及び１００ｂから受信すると（ステップＳ４０７，Ｓ４０８）、各サーバ１００ａ及び１００ｂからの応答パケットの正当性を判定する。そして、応答送信処理部２０７は正当な応答パケットの１つをクライアント５００ａへ転送する（ステップＳ４０９）。この時の送信キュー２０３を図３９に示す。
【０１２５】
次いで、クライアント５００ａが172.17.1.1宛に、テーブルｔｅｓｔ＿ｔａｂｌｅを更新するＳＱＬ（ＵＰＤＡＴＥ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ４１０）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａ及び１００ｂについて送信状態を「未送信」にして受信クエリを送信キュー２０３に入れる（ステップＳ４１１）。この時の送信キュー２０３を図４０に示す。
【０１２６】
ここで、サーバ１００ｃが再起動したものとする（ステップＳ４１２）。仲介装置２００のオペレータは、サーバ１００ｃの再起動完了を確認すると、仲介装置２００に対してデータベース同期化要求を入力指示する（ステップＳ４１３）。
【０１２７】
同期化処理制御部２０８は、データベース同期化要求があると、サーバ管理表２０１を参照して同期化用のサーバ１００を１台選定する。ここでは、正常稼働中のサーバ１００は２台なので、何れか一方のサーバを所定の規則に従って選定する。本実施の形態では、サーバ１００ｂを同期化用サーバとして選定したものとする。同期化処理制御部２０８は、サーバ管理表２０１のサーバ１００ｂについての稼働状態を「ｓｙｎｃ」に更新するとともに（ステップＳ４１４）、送信キュー２０３のサーバ１００ｂについて送信状態が「未送信」となっているエントリを「保留」に更新する（ステップＳ４１５）。また、同期化処理制御部２０８は、同期化用のサーバ１００ｂにおいて実行中クエリの処理が完了したことを確認した後に、要求元のサーバ１００ｃについて稼働状態を「ｓｙｎｃ」でサーバ管理表２０１に追加するとともに（ステップＳ４１６）、送信キュー２０３の送信状態の欄に当該サーバ１００ｃ用の列を追加する（ステップＳ４１７）。ここで、当該サーバ１００ｃの送信状態は全て「保留」に設定する。この時のサーバ管理表２０１及び送信キュー２０３を図４１，図４２に示す。なお、同期化処理制御部２０８は、上記ステップＳ４１４〜Ｓ４１７の処理は１つの処理として取り扱い、排他制御を行う。つまり、ステップＳ４１４〜Ｓ４１７の処理中には、各ステップでアクセスするサーバ管理表２０１及び送信キュー２０３に対して、他の機能ブロック（例えば受信クエリ処理部２０４やクエリ送信処理部２０５など）からのアクセスを中断させる。
【０１２８】
次いで、同期化処理制御部２０８は、サーバ１００ｂのデータベース１０１ｂのスナップショットの作成を開始する（ステップＳ４１８）。スナップショットはスナップショット記憶部２０９に保存する。本実施の形態では前述したようにＳＥＬＥＣＴクエリを使ってデータベース１０１ｂの各テーブルのデータ等を取得する。
【０１２９】
同期化処理制御部２０８が上記ステップＳ４１３〜Ｓ４１６の排他処理を終えると、図３３に示すように、クエリ送信処理部２０５は、送信キュー２０３から送信状態が「未送信」のクエリを取り出し、対応するサーバ１００ａに転送するとともに（ステップＳ４１９）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４２０）。仲介装置２００の受信クエリ処理部２０４は、ＵＰＤＡＴＥが正常に処理されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ４２１）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７は該応答パケットのクライアント５００ａへ転送する（ステップＳ４２２）。
【０１３０】
また、クライアント５００ｂが172.17.1.1宛のトランザクション開始ＳＱＬ（ＢＥＧＩＮ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ４２３）。受信クエリ処理部２０４は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ｂのＩＰアドレスとトランザクション番号を登録する（ステップＳ４２４）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａについて送信状態を「未送信」にするとともに、同期化処理中のサーバ１００ｂ及び１００ｃについて送信状態を「保留」にして受信クエリを送信キュー２０３に入れる（ステップＳ４２５）。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、送信状態が「未送信」であるサーバ１００ａに転送し（ステップＳ４２６）、送信キュー２０３のサーバ１００ａについての送信状態を「送信完了」に更新する（ステップＳ４２７）。仲介装置２００の正当性判定部２０６は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ４２８）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７は該応答パケットのクライアント５００ｂへ転送する（ステップＳ４２９）。この時の送信キュー２０３を図４３に示す。
【０１３１】
ここで、スナップショットの作成処理が完了したものとする（ステップＳ４３０）。同期化処理制御部２０８は、スナップショットの作成処理が完了すると、当該スナップショットを用いて新規サーバ１００ｃのデータベース１０１ｃの復元処理を開始する（ステップＳ４３１）。本実施の形態では、ＩＮＳＥＲＴクエリ等を新規サーバ１００ｃに発行することによりスナップショットからのデータベース１０１の復元を図る。
【０１３２】
また、スナップショットの作成処理が完了すると、同期化処理制御部２０８は、該サーバ１００ｂについて送信キュー２０３の送信状態が「保留」となっているものを「保留解除」に更新する（ステップＳ４３２）。この時の送信キュー２０３を図４４に示す。以降、各クライアント５００から受信したクエリは、サーバ１００ａについては送信状態を「未送信」で、サーバ１００ｂについては送信状態を「保留解除」で、サーバ１００ｃについては送信状態を「保留」にして送信キュー２０３に入れる。これにより、クエリ送信処理部２０５は、送信状態が「保留解除」となったクエリを差分情報として古いものから順にサーバ１００ｂに送信する。
【０１３３】
具体的には、クエリ送信処理部２０５は、送信キュー２０３からＵＰＤＡＴＥクエリを取り出してサーバ１００ｂに転送するとともに（ステップＳ４３３）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４３４）。仲介装置２００の正当性判定部２０６は、更新が正常に処理されたことを通知する応答パケットをサーバ１００ｂから受信する（ステップＳ４３５）。ここで、当該応答は差分情報としてのクエリの処理応答なので、当該応答はクライアント５００へは転送しない。
【０１３４】
ここで、クライアント５００ｂがＩＮＳＥＲＴクエリを仲介装置２００に送信すると（ステップＳ４３６）、前述したように、仲介装置２００の受信クエリ処理部２０４は、サーバ１００ａについては送信状態を「未送信」で、サーバ１００ｂについては送信状態を「保留解除」で、サーバ１００ｃについては送信状態を「保留」で当該クエリを送信キューに投入する（ステップＳ４３７）。この時の送信キュー２０３を図４５に示す。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、送信状態が「未送信」であるサーバ１００ａに対して転送するとともに（ステップＳ４３８）、送信キュー２０３のサーバ１００ａについての送信状態を「送信完了」に更新する（ステップＳ４３９）。正当性判定部２０６は、ＩＮＳＥＲＴが正常に処理されたことを通知するパケットをサーバ１００ａから受信すると（ステップＳ４４０）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７は該応答パケットをクライアント５００ｂへ転送する（ステップＳ４４１）。
【０１３５】
図４５に示すように、この時点では送信キュー２０３において送信状態が「保留解除」になったクエリは、ＢＥＧＩＮクエリとＩＮＳＥＲＴクエリの２つである。仲介装置２００は、前述のステップＳ４３３〜Ｓ４３５と同様にして、当該２つのクエリを処理する（ステップＳ４４２〜Ｓ４４７）。
【０１３６】
以上でサーバ１００ｂに対しては、全ての差分情報の転送が終了し（すなわち送信キュー２０３から「保留解除」のクエリを全て送出し終わり）、且つ、差分情報としてのクエリの処理が正常に処理されたことになるので、サーバ１００ａのデータベース１０１ａとサーバ１００ｂのデータベース１０１ｂの同期化が完了したことになる。そこで、仲介装置２００の応答送信処理部２０７は、サーバ１００ｂをシステムに組み込むべくサーバ１００ｂについてのサーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新する（ステップＳ４４８）。なお、システムへの組み込みのタイミングは、正常稼働中のサーバ１００ａにおいてクエリの実行中であっても構わず、またトランザクションが継続中であっても構わない点に留意されたい。
【０１３７】
以降、クライアント５００からのクエリは、サーバ１００ａ及びサーバ１００ｂについては送信状態を「未送信」で、サーバ１００ｃについては送信状態を「保留」にして送信キュー２０３に入れる。具体的には、図３４に示すように、クライアント５００ａが172.17.1.1宛のトランザクション確定ＳＱＬ（ＣＯＭＭＩＴ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ４４９）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａ及び１００ｂについては送信状態を「未送信」に、同期化処理中のサーバ１００ｃについては送信状態を「保留」にして受信クエリを送信キュー２０３に入れる（ステップＳ４５０）。この時の送信キュー２０３を図４６に示す。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、対応するサーバ１００ａ及び１００ｂに転送し（ステップＳ４５１，Ｓ４５２）、それぞれ送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４５３）。仲介装置２００の正当性判定部２０６は、トランザクションが正常にＣＯＭＭＩＴされたことを通知する応答パケットをサーバ１００ａ及び１００ｂから受信すると（ステップＳ４５４，Ｓ４５５）、各サーバ１００ａ及び１００ｂからの応答パケットの正当性を判定する。そして、応答送信処理部２０７は正当な応答パケットの１つをクライアント５００ａへ転送する（ステップＳ４５６）。また、ＣＯＭＭＩＴが正常に完了したことから、トランザクションが終了したことが分かるので、応答送信処理部２０７はトランザクション管理表２０２からこのトランザクションの登録を削除する（ステップＳ４５７）。
【０１３８】
ここで、新規サーバ１００ｃのデータベース１０１ｃの復元処理が完了したものとする（ステップＳ４５８）。同期化処理制御部２０８は、新規サーバ１００ｃのデータベース１０１ｃのスナップショットからの復元が完了すると、送信キュー２０３に保留となっているクエリを差分情報として送出すべく、新規サーバ１００ｃについて送信キュー２０３の送信状態が「保留」となっているものを「保留解除」に更新する（ステップＳ４５９）。この時の送信キュー２０３を図４７に示す。以降、各クライアント５００から受信したクエリは、サーバ１００ａ及びサーバ１００ｂについては送信状態を「未送信」で、サーバ１００ｃについては送信状態を「保留解除」にして送信キュー２０３に入れる。これにより、クエリ送信処理部２０５は、送信状態が「保留解除」となったクエリを差分情報として古いものから順にサーバ１００ｃに送信する。
【０１３９】
具体的には、クエリ送信処理部２０５は、送信キュー２０３からＢＥＧＩＮクエリを取り出してサーバ１００ｃに転送するとともに（ステップＳ４６０）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４６１）。仲介装置２００の正当性判定部２０６は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ｃから受信する（ステップＳ４６２）。ここで、当該応答は差分情報としてのクエリの処理応答なので、当該応答はクライアント５００へは転送しない。
【０１４０】
サーバ１００ｃへの差分情報転送中にクライアント５００ｂからＵＰＤＡＴＥクエリを受信すると（ステップＳ４６３）、受信クエリ処理部２０４は、サーバ１００ａ及び１００ｂについては送信状態を「未送信」で、サーバ１００ｃについては送信状態を「保留解除」で当該クエリーを送信キュー２０３に投入する（ステップＳ４６４）。この時の送信キュー２０３を図４８に示す。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、送信状態が「未送信」であるサーバ１００ａ及び１００ｂに転送し（ステップＳ４６５，Ｓ４６６）、それぞれのサーバ１００ａ及び１００ｂについて送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４６７）。正当性判定部２０６は、各サーバ１００ａ及び１００ｂからＵＰＤＡＴＥが正常に処理されたことを通知するパケットを受信すると（ステップＳ４６８，Ｓ４６９）、各応答の正当性を判定して正当な応答の１つをクライアント５００ｂに返す（ステップＳ４７０）。
【０１４１】
全ての差分情報の転送が終了し（すなわち送信キュー２０３から「保留解除」のクエリを全て送出し終わり）、且つ、差分情報としてのクエリの処理が正常に処理された時点で、サーバ１００ａのデータベース１０１ａとサーバ１００ｃのデータベース１０１ｃの同期化が完了するので、サーバ１００ｃをシステムに組み込むべくサーバ１００ｃについてのサーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新する。なお、システムへの組み込みのタイミングは、正常稼働中のサーバ１００においてクエリの実行中であっても構わず、またトランザクションが継続中であっても構わない点に留意されたい。
【０１４２】
図４８の例では、まず、トランザクションＩＤが５番のＵＰＤＡＴＥクエリからトランザクションＩＤが６番のＩＮＳＥＲＴクエリについて、前述のステップＳ４６０〜Ｓ４６２と同様の処理を行う。以下、図４８の例における、トランザクションＩＤが５番のＣＯＭＭＩＴクエリと、トランザクションＩＤが６番のＵＰＤＡＴＥクエリの処理について詳述する。
【０１４３】
クエリ送信処理部２０５は、送信キュー２０３からＣＯＭＭＩＴクエリを取り出してサーバ１００ｃに転送するとともに（ステップＳ４９０）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４９１）。仲介装置２００の正当性判定部２０６は、トランザクションが確定したことを通知する応答パケットをサーバ１００ｃから受信する（ステップＳ４９２）。ここで、当該応答は差分情報としてのクエリの処理応答なので、当該応答はクライアント５００へは転送しない。
【０１４４】
この時点でトランザクションＩＤ５のトランザクションは全てのサーバ１００において処理が終了し、且つ、送信キュー２０３にはトランザクションＩＤ５に属する各クエリは全てのサーバ１００ａ，１００ｂ，１００ｃについて送信状態が「送信完了」となったので、応答送信処理部２０７は、当該トランザクションに属するクエリのエントリを送信キュー２０３から削除する（ステップＳ４９３）。この時の送信キュー２０３を図４９に示す。
【０１４５】
次いで、図３６に示すように、クエリ送信処理部２０５は、送信キュー２０３からＵＰＤＡＴＥクエリを取り出してサーバ１００ｃに転送するとともに（ステップＳ４９４）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４９５）。仲介装置２００の正当性判定部２０６は、ＵＰＤＡＴＥが正常に処理されたことを通知する応答パケットをサーバ１００ｃから受信する（ステップＳ４９６）。ここで、当該応答は差分情報としてのクエリの処理応答なので、当該応答はクライアント５００へは転送しない。
【０１４６】
この時点で送信キュー２０３には送信状態が「保留解除」のクエリがなくなったので、応答送信処理部２０７は、サーバ１００ｃをシステムに組み込むべくサーバ１００ｃについてのサーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新する（ステップＳ４９７）。なお、このステップＳ４９７の処理は、前述のステップＳ１４４，Ｓ２４２の処理に対応するものである。
【０１４７】
以上のように本実施の形態では、スナップショットの作成方法として、該スナップショットの作成中にはクエリの処理を行うことができない方法を採用しているが、スナップショットの作成とクライアントからのクエリの処理を別々のサーバで処理することにより、クライアントへのサービスの提供を維持しつつ同期化処理を行うことができる。他の作用・効果については第１の実施の形態と同じである。
【０１４８】
なお、本実施の形態では、スナップショットを作成する同期化用のサーバ１００ｂと、システムに再び組み込まれるサーバ１００ｃとに対して、それぞれ独立したタイミングで差分情報を転送していたが、サーバ１００ｃにおいてデータベースの復旧が完了した後に両サーバ１００ｂ，１００ｃに対して同一の差分情報を転送するようにしてもよい。
【０１４９】
また、本実施の形態では、システムに再び組み込まれるサーバ１００ｃにおいてデータベースの復旧が完了した後に仲介装置２００からサーバ１００ｃに差分情報の転送を開始していたが、サーバ１００ｃに差分情報を一時蓄積する機能がある場合にはデータベースの復旧完了を待たずに差分情報の転送を開始しても良い。これにより、仲介装置２００からサーバ１００への差分情報の転送速度を抑えられるので、差分情報転送によるトラフィック増大を防止できる。
【０１５０】
以上、本発明の実施形態について詳述したが、上記実施の形態は例示的なものであり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれるものである。なお、以下の各変形例は適宜組み合わせて上記各実施の形態に適用できる。
【０１５１】
例えば、上記実施の形態の構成に加えて、仲介装置２００が、差分情報として新規サーバ１００等で処理されたクエリの処理結果の正当性を判定するようにしても良い。具体的には、仲介装置２００は、正常稼働中のサーバ１００におけるクエリの処理結果を仲介装置２００において保存しておく。そして、当該クエリを差分情報として新規サーバ１００等で処理された際に、新規サーバ１００等での処理結果と正常稼働中のサーバ１００での処理結果とを比較する。そして、両者が一致しない場合には、同期化処理を直ちに又は適当なタイミングで再試行すると好適である。
【０１５２】
また、上記実施の形態では、送信状態が「保留解除」となっているクエリを送信キュー２０３から取り出して差分情報としてサーバ１００に対して転送し、該転送中にクライアント５００からクエリを受信すると、当該サーバ１００についての送信状態を「保留解除」にして送信キュー２０３に投入する処理を行っている。そして、送信状態が「保留解除」となっているクエリが全てサーバ１００において処理された後に当該サーバ１００をシステムに組み込む処理を行っている。このような処理では、クライアント５００からのクエリ受信頻度が高いとサーバ１００のシステムへの組み込みに時間を要することが考えられる。そこで、例えば送信キュー２０３に送信状態が「保留解除」として記憶されているクエリが所定数以下となったら、受信クエリ処理部２０４が送信キュー２０３へのクエリの投入を一時停止するなど所定条件で差分情報の転送処理を優先させるようにしてもよい。
【０１５３】
また、上記実施の形態では、クライアント５００から受信した全てのクエリを送信キュー２０３に保存しておき、同期化処理時には該送信キュー２０３に保存されているクエリを差分情報としてサーバ１００に転送しているが、ＳＥＬＥＣＴクエリのようにデータベース１０１の更新を行わない参照系クエリについては差分情報としてのサーバ１００への転送を行わないようにしてもよい。これにより、同期化処理の処理時間を短縮化できる。
【０１５４】
さらに、ＵＰＤＡＴＥクエリのようにデータベース１０１の更新を行う更新系クエリのみを転送し、参照系クエリやトランザクション制御クエリ（ＢＥＧＩＮ，ＲＯＬＬＢＡＣＫ等）の転送を行わないようにしてもよい。そして、当該更新系クエリを差分情報としてサーバ１００に転送する際には、サーバ１００においてＡｕｔｏＣｏｍｍｉｔモードで当該クエリを処理させるようにする。これにより、更に同期化処理の短縮化及び記憶容量の節約が可能となる。ただし、この場合にはサーバ１００に対してクエリを転送する順序が、正常稼働中のサーバ１００で処理された順序と一致することを保証する必要がある。これを実現するためには、各更新系クエリに対する正常稼働中サーバ１００からの処理応答から正常稼働中サーバ１００における各クエリの実際の処理順序を把握し、当該順序に従って各クエリを転送すればよい。
【０１５５】
また、上記実施の形態では、サーバ１００においてトランザクションが継続中であっても仲介装置２００がスナップショットの作成を開始していたが、継続中のトランザクションが無くなった時点でスナップショットの作成指示を送信するようにしてもよい。これにより、データベース１０１として、トランザクションの継続中にはスナップショットの作成ができないものや、トランザクションの継続中であってもスナップショットの作成は開始できるが当該スナップショットにトランザクションに係るクエリが反映されるか否かが不確定なものを利用することができる。
【０１５６】
また、上記の実施の形態では、同期化処理中に送信キュー２０３から各クエリを削除するタイミングは、当該クエリが属するトランザクションが全てのサーバ１００において終了した時点としていた。この方法では、通常動作時におけるクエリの削除タイミングと同じなので実装が容易であるという利点がある。一方、同期化処理中には、送信キュー２０３のクエリが差分情報としてサーバ１００において処理されたら随時削除するようにしてもよい。また、同期化処理が完了した後に一括して削除するようにしても良い。
【０１５７】
また、上記の実施の形態では、クエリのバッファリング機能と同期化処理用の差分情報の記憶機能とを送信キュー２０３に統合させていたが、それぞれ機能毎に記憶手段を設けるようにしてもよい。なお、この場合には、サーバ１００が３台構成となっているときには、システムに組み込もうとするサーバ１００と、同期化処理用サーバ１００とで差分情報記憶部を共有できるので、記憶容量を節約できるという点で有利である。
【０１５８】
また、上記実施の形態では、オペレータがサーバ１００の再起動完了を確認した後に、仲介装置２００の所定の入力装置（図示省略）を用いてデータベース同期化要求を入力するようにしていたが、他のコンピュータからネットワークを介して同期化要求を入力するようにしてもよい。また、仲介装置１００又は他のコンピュータに、サーバ１００の稼働状況を監視してサーバ１００の再起動を検出すると仲介装置２００に対してデータベース同期化要求を発出するサーバ監視手段を設けてもよい。
【０１５９】
また、上記の実施の形態に加えて更に、各サーバ１００にデータベース１０１やデータベース制御部１０２の障害を検出する障害検出手段を設けてもよい。この障害検出手段は、データベース１０１やデータベース制御部１０２の動作を定期的に監視することで障害を検出し、障害検出時には仲介装置２００に障害発生を通知する。これにより、仲介装置２００では各サーバ１００やネットワークでの障害発生検出をより確実且つ効率的に行うことができる。
【０１６０】
また、各サーバは要求に応じて同じ応答をするならば同じ実装である必要はない。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラオプション、ハードウェアかソフトウェアか、などが異なっていてもよい。サーバには、ＰｏｓｔｇｒｅＳＱＬなどのフリーソフトウェアやＯｒａｃｌｅなどの市販のソフトウェア、独自開発のソフトウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サーバ１００ａはＰｏｓｔｇｒｅＳＱＬでサーバ１００ｂはＯｒａｃｌｅでも良い。
【０１６１】
また、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが、ハードウェアで実装しても良い。
【０１６２】
また、上記実施の形態では、仮想サーバ８００を構成する仲介装置２００は１台のみであったが、複数台設けて冗長性を持たせることにより、より可用性の高い構成とすることも可能である。仲介装置を多重化させる技術については、例えば本願出願人による特開２００３−３４５６７９号公報に記載されたものなどを用いればよい。
【０１６３】
また、上記実施の形態では、クライアント５００とサーバ１００はそれぞれ別のネットワーク３００，４００に属するようにし、仲介装置２００が両ネットワーク３００，４００を仲介するようなネットワーク構成としたが、本発明ではネットワーク構成は不問である。例えば、１つのネットワークにクライアント５００，サーバ１００，仲介装置２００が属するように構成してもよい。
【０１６４】
さらに、上記各実施の形態では、データベース一致検査装置６００を多重化データベースシステムの外側、すなわちネットワーク４００に接続していたが、多重化データベースシステムの内側のネットワーク３００にデータベース一致検査装置６００を接続するようにしてもよい。
【図面の簡単な説明】
【０１６５】
【図１】第１の実施形態に係る多重化データベースシステムの構成図
【図２】第１の実施形態に係る仲介装置の機能ブロック図
【図３】第１の実施形態に係るサーバ管理表の一例を示す図
【図４】第１の実施形態に係るトランザクション管理表の一例を示す図
【図５】第１の実施形態に係る送信キューの一例を示す図
【図６】各サーバが正常稼働している場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図７】図５の動作におけるサーバ管理表の一例
【図８】図５の動作におけるトランザクション管理表の一例
【図９】サーバが故障した場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１０】図９の動作におけるトランザクション管理表の一例
【図１１】図９の動作におけるサーバ管理表の一例
【図１２】図９の動作における送信キューの一例
【図１３】サーバにより異なる順序でクエリが実行された場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１４】サーバにより異なる順序でクエリが実行された場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１５】サーバにより異なる順序でクエリが実行された場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１６】サーバにより異なる順序でクエリが実行された場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１７】第１の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図１８】第１の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図１９】第１の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図２０】図１７乃至図１９の動作におけるサーバ管理表の一例
【図２１】図１７乃至図１９の動作におけるトランザクション管理表の一例
【図２２】図１７乃至図１９の動作における送信キューの一例
【図２３】図１７乃至図１９の動作における送信キューの一例
【図２４】図１７乃至図１９の動作におけるサーバ管理表の一例
【図２５】図１７乃至図１９の動作における送信キューの一例
【図２６】図１７乃至図１９の動作における送信キューの一例
【図２７】図１７乃至図１９の動作における送信キューの一例
【図２８】図１７乃至図１９の動作における送信キューの一例
【図２９】図１７乃至図１９の動作における送信キューの一例
【図３０】図１７乃至図１９の動作における送信キューの一例
【図３１】図１７乃至図１９の動作におけるサーバ管理表の一例
【図３２】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図３３】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図３４】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図３５】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図３６】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図３７】図３２乃至図３６の動作におけるサーバ管理表の一例
【図３８】図３２乃至図３６の動作における送信キューのデータ構造の一例
【図３９】図３２乃至図３６の動作における送信キューの一例
【図４０】図３２乃至図３６の動作における送信キューの一例
【図４１】図３２乃至図３６の動作におけるサーバ管理表の一例
【図４２】図３２乃至図３６の動作における送信キューの一例
【図４３】図３２乃至図３６の動作における送信キューの一例
【図４４】図３２乃至図３６の動作における送信キューの一例
【図４５】図３２乃至図３６の動作における送信キューの一例
【図４６】図３２乃至図３６の動作における送信キューの一例
【図４７】図３２乃至図３６の動作における送信キューの一例
【図４８】図３２乃至図３６の動作における送信キューの一例
【図４９】図３２乃至図３６の動作における送信キューの一例
【図５０】従来のデータベース同期化システムの構成図
【図５１】データベースのテーブルの一例
【図５２】処理順序が問題となるトランザクションの一例
【図５３】処理順序が問題となるトランザクションの一例
【符号の説明】
【０１６６】
１００…サーバ、１０１…データベース、１０２…データベース制御部、２００…仲介装置、２０１…サーバ管理表、２０２…トランザクション管理表、２０３…送信キュー、２０４…受信クエリ処理部、２０５…クエリ送信処理部、２０６…正当性判定部、２０７…応答送信処理部、２０８…同期化処理制御部、３００，４００…ネットワーク、５００…クライアント、６００…データベース一致検査装置。
【図１】
2007183728.tif 000003
【図２】
2007183728.tif 000004
【図３】
2007183728.tif 000005
【図４】
2007183728.tif 000006
【図５】
2007183728.tif 000007
【図６】
2007183728.tif 000008
【図７】
2007183728.tif 000009
【図８】
2007183728.tif 000010
【図９】
2007183728.tif 000011
【図１０】
2007183728.tif 000012
【図１１】
2007183728.tif 000013
【図１２】
2007183728.tif 000014
【図１３】
2007183728.tif 000015
【図１４】
2007183728.tif 000016
【図１５】
2007183728.tif 000017
【図１６】
2007183728.tif 000018
【図１７】
2007183728.tif 000019
【図１８】
2007183728.tif 000020
【図１９】
2007183728.tif 000021
【図２０】
2007183728.tif 000022
【図２１】
2007183728.tif 000023
【図２２】
2007183728.tif 000024
【図２３】
2007183728.tif 000025
【図２４】
2007183728.tif 000026
【図２５】
2007183728.tif 000027
【図２６】
2007183728.tif 000028
【図２７】
2007183728.tif 000029
【図２８】
2007183728.tif 000030
【図２９】
2007183728.tif 000031
【図３０】
2007183728.tif 000032
【図３１】
2007183728.tif 000033
【図３２】
2007183728.tif 000034
【図３３】
2007183728.tif 000035
【図３４】
2007183728.tif 000036
【図３５】
2007183728.tif 000037
【図３６】
2007183728.tif 000038
【図３７】
2007183728.tif 000039
【図３８】
2007183728.tif 000040
【図３９】
2007183728.tif 000041
【図４０】
2007183728.tif 000042
【図４１】
2007183728.tif 000043
【図４２】
2007183728.tif 000044
【図４３】
2007183728.tif 000045
【図４４】
2007183728.tif 000046
【図４５】
2007183728.tif 000047
【図４６】
2007183728.tif 000048
【図４７】
2007183728.tif 000049
【図４８】
2007183728.tif 000050
【図４９】
2007183728.tif 000051
【図５０】
2007183728.tif 000052
【図５１】
2007183728.tif 000053
【図５２】
2007183728.tif 000054
【図５３】
2007183728.tif 000055