(57)【要約】【課題】  複数のトランザクションを並行処理しても各データベース間で矛盾の生じることがない多重化データベースシステムにおける同期化方法を提供する。【解決手段】  仲介装置２００は、各サーバ１００間における処理結果の矛盾又はサーバ１００の無応答を検出し、処理結果の矛盾を検出したら各応答の中から１つの応答を選定するとともに、選定した応答以外の応答を返したサーバ１００をシステムから切り離し、サーバ１００の無応答を検出したら該無応答のサーバ１００をシステムから切り離し、システムから切り離されたサーバ１００とシステムに組み込まれている正常稼働中のサーバ１００との同期化処理を行い、同期化処理が完了したらシステムから切り離されたサーバ１００を再びシステムに組み込む。【選択図】  図１
2007241325.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宛に、テーブルｔｅｓｔ＿ｔａｂｌｅを更新するＳＱＬ（ＵＰＤＡＴＥ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ４１１）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａ及び１００ｂについて送信状態を「未送信」にして受信クエリを送信キュー２０３に入れる（ステップＳ４１２）。この時の送信キュー２０３を図４７に示す。
【０１４１】
ここで、サーバ１００ｃが再起動したものとする（ステップＳ４１３）。これにより、サーバ１００ｃのデータベース制御部１０２ｃは、データベース同期化要求（システムへの組込要求）を仲介装置２００へ送信する（ステップＳ４１４）。
【０１４２】
データベース同期化要求を受信した同期化処理制御部２０８は、サーバ管理表２０１を参照して同期化用のサーバ１００を１台選定する。ここでは、正常稼働中のサーバ１００は２台なので、何れか一方のサーバを所定の規則に従って選定する。本実施の形態では、サーバ１００ｂを同期化用サーバとして選定したものとする。同期化処理制御部２０８は、サーバ管理表２０１のサーバ１００ｂについての稼働状態を「ｓｙｎｃ」に更新するとともに（ステップＳ４１５）、送信キュー２０３のサーバ１００ｂについて送信状態が「未送信」となっているエントリを「保留」に更新する（ステップＳ４１６）。また、同期化処理制御部２０８は、同期化用のサーバ１００ｂにおいて実行中クエリの処理が完了したことを確認した後に、要求元のサーバ１００ｃについて稼働状態を「ｓｙｎｃ」でサーバ管理表２０１に追加するとともに（ステップＳ４１７）、送信キュー２０３の送信状態の欄に当該サーバ１００ｃ用の列を追加する（ステップＳ４１８）。ここで、当該サーバ１００ｃの送信状態は全て「保留」に設定する。この時のサーバ管理表２０１及び送信キュー２０３を図４８，図４９に示す。なお、同期化処理制御部２０８は、上記ステップＳ４１５〜Ｓ４１８の処理は１つの処理として取り扱い、排他制御を行う。つまり、ステップＳ４１５〜Ｓ４１８の処理中には、各ステップでアクセスするサーバ管理表２０１及び送信キュー２０３に対して、他の機能ブロック（例えば受信クエリ処理部２０４など）からのアクセスを中断させる。
【０１４３】
次いで、同期化処理制御部２０８は、該サーバ１００ｂにスナップショットの作成指示を送出する（ステップＳ４１９）。スナップショット作成指示を受け取ったサーバ１００ｂのデータベース制御部１０２ｂは、データベース１０１ｂのスナップショットを作り出す（ステップＳ４２０）。
【０１４４】
本実施の形態が第１の実施の形態と大きく異なる点は、第１の実施の形態ではスナップショット作成中にはクライアント５００からのクエリを処理できなかったが、本実施の形態では処理可能である点である。すなわち、同期化処理制御部２０８が上記ステップＳ４１５〜Ｓ４１８の排他処理を終えると、図４０に示すように、クエリ送信処理部２０５は、送信キュー２０３から送信状態が「未送信」のクエリを取り出し、対応するサーバ１００ａに転送するとともに（ステップＳ４２１）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４２２）。仲介装置２００の受信クエリ処理部２０４は、ＵＰＤＡＴＥが正常に処理されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ４２３）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７は該応答パケットのクライアント５００ａへ転送するとともに（ステップＳ４２４）、該応答を送信キュー２０３に保存する（ステップＳ４２５）。
【０１４５】
また、クライアント５００ｂが172.17.1.1宛のトランザクション開始ＳＱＬ（ＢＥＧＩＮ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ４２６）。受信クエリ処理部２０４は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ｂのＩＰアドレスとトランザクション番号を登録する（ステップＳ４２７）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａについて送信状態を「未送信」にするとともに、同期化処理中のサーバ１００ｂ及び１００ｃについて送信状態を「保留」にして受信クエリを送信キュー２０３に入れる（ステップＳ４２８）。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、送信状態が「未送信」であるサーバ１００ａに転送し（ステップＳ４２９）、送信キュー２０３のサーバ１００ａについての送信状態を「送信完了」に更新する（ステップＳ４３０）。仲介装置２００の正当性判定部２０６は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ４３１）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７は該応答パケットのクライアント５００ｂへ転送するとともに（ステップＳ４３２）、該応答を送信キュー２０３に保存する（ステップＳ４３３）。この時の送信キュー２０３を図５０に示す。
【０１４６】
ここで、同期化用のサーバ１００ｂがスナップショットの作成を完了したとする（ステップＳ４３４）。サーバ１００ｂのデータベース制御部１０２ｂは、スナップショット作成が完了すると、スナップショット作成完了通知を仲介装置２００へ通知するとともに（ステップＳ４３５）、該スナップショットのサーバ１００ｃへの転送を開始する（ステップＳ４３６）。サーバ１００ｃのデータベース制御部１０２ｃは、サーバ１００ｂから受信したスナップショットからデータベースを復元する（ステップＳ４３７）。
【０１４７】
サーバ１００ｂからスナップショット作成完了通知を受信すると、同期化処理制御部２０８は、該サーバ１００ｂについて送信キュー２０３の送信状態が「保留」となっているものを「保留解除」に更新する（ステップＳ４３８）。この時の送信キュー２０３を図５１に示す。以降、各クライアント５００から受信したクエリは、サーバ１００ａについては送信状態を「未送信」で、サーバ１００ｂについては送信状態を「保留解除」で、サーバ１００ｃについては送信状態を「保留」にして送信キュー２０３に入れる。これにより、クエリ送信処理部２０５は、送信状態が「保留解除」となったクエリを差分情報として古いものから順にサーバ１００ｂに送信する。
【０１４８】
具体的には、クエリ送信処理部２０５は、送信キュー２０３からＵＰＤＡＴＥクエリを取り出してサーバ１００ｂに転送するとともに（ステップＳ４３９）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４４０）。仲介装置２００の正当性判定部２０６は、更新が正常に処理されたことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ４４１）、当該応答と、送信キュー２０３に保存されている応答とを対比する（ステップＳ４４２）。そして、両者が一致しない場合には、一旦、サーバ１００ｂ及び１００ｃについてのエントリをサーバ管理表２０１及び送信キュー２０３から削除した後に、サーバ１００ｂに対して再起動指示を送出する。これにより、第１の実施の形態で前述した手順によりサーバ１００ｂがシステムに組み込まれるので、次いでサーバ１００ｃに対して再起動指示を送出する。これにより、前記ステップＳ４１５以降の処理が再試行される。
【０１４９】
ここで、クライアント５００ｂがＩＮＳＥＲＴクエリを仲介装置２００に送信すると（ステップＳ４４３）、前述したように、仲介装置２００の受信クエリ処理部２０４は、サーバ１００ａについては送信状態を「未送信」で、サーバ１００ｂについては送信状態を「保留解除」で、サーバ１００ｃについては送信状態を「保留」で当該クエリを送信キューに投入する（ステップＳ４４４）。この時の送信キュー２０３を図５２に示す。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、送信状態が「未送信」であるサーバ１００ａに対して転送するとともに（ステップＳ４４５）、送信キュー２０３のサーバ１００ａについての送信状態を「送信完了」に更新する（ステップＳ４４６）。正当性応答部２０６は、ＩＮＳＥＲＴが正常に処理されたことを通知するパケットをサーバ１００ａから受信すると（ステップＳ４４７）、ここでは、正常稼働中のサーバ１００が１台のみなので当該応答パケットを正当と判断し、応答送信処理部２０７は該応答パケットをクライアント５００ｂへ転送するとともに（ステップＳ４４８）、該応答を送信キュー２０３に保存する（ステップＳ４４９）。
【０１５０】
図５２に示すように、この時点では送信キュー２０３において送信状態が「保留解除」になったクエリは、ＢＥＧＩＮクエリとＩＮＳＥＲＴクエリの２つである。仲介装置２００は、前述のステップＳ４３９〜Ｓ４４２と同様にして、当該２つのクエリを処理する（ステップＳ４５０〜Ｓ４５７）。
【０１５１】
以上でサーバ１００ｂに対しては、全ての差分情報の転送が終了し（すなわち送信キュー２０３から「保留解除」のクエリを全て送出し終わり）、且つ、差分情報としてのクエリの処理が正常に処理されたことになるので、サーバ１００ａのデータベース１０１ａとサーバ１００ｂのデータベース１０１ｂの同期化が完了したことになる。そこで、仲介装置２００の応答送信処理部２０７は、サーバ１００ｂをシステムに組み込むべくサーバ１００ｂについてのサーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新する（ステップＳ４５８）。なお、システムへの組み込みのタイミングは、正常稼働中のサーバ１００においてクエリの実行中であっても構わず、またトランザクションが継続中であっても構わない点に留意されたい。
【０１５２】
以降、クライアント５００からのクエリは、サーバ１００ａ及びサーバ１００ｂについては送信状態を「未送信」で、サーバ１００ｃについては送信状態を「保留」にして送信キュー２０３に入れる。具体的には、図４１に示すように、クライアント５００ａが172.17.1.1宛のトランザクション確定ＳＱＬ（ＣＯＭＭＩＴ）を含んだパケットを送信すると、仲介装置２００の受信クエリ処理部２０４はそのパケットを受信する（ステップＳ４５９）。受信クエリ処理部２０４は、サーバ管理表２０１を参照して正常稼働中のサーバ１００ａ及び１００ｂについては送信状態を「未送信」に、同期化処理中のサーバ１００ｃについては送信状態を「保留」にして受信クエリを送信キュー２０３に入れる（ステップＳ４６０）。この時の送信キュー２０３を図５３に示す。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、対応するサーバ１００ａ及び１００ｂに転送し（ステップＳ４６１，Ｓ４６２）、それぞれ送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４６３）。仲介装置２００の正当性判定部２０６は、トランザクションが正常にＣＯＭＭＩＴされたことを通知する応答パケットをサーバ１００ａ及び１００ｂから受信すると（ステップＳ４６４，Ｓ４６５）、各サーバ１００ａ及び１００ｂからの応答パケットの正当性を判定する。そして、応答送信処理部２０７は正当な応答パケットの１つをクライアント５００ａへ転送するとともに（ステップＳ４６６）、該応答を送信キュー２０３に保存する（ステップＳ４６７）。また、ＣＯＭＭＩＴが正常に完了したことから、トランザクションが終了したことが分かるので、応答送信処理部２０７はトランザクション管理表２０２からこのトランザクションの登録を削除する（ステップＳ４６８）。
【０１５３】
ここで、サーバ１００ｃにおいてスナップショットからのデータベース１０１ｃの復元が完了したものとする（ステップＳ４６９）。サーバ１００ｃはデータベース１０１ｃの復元が完了すると差分情報転送要求を仲介装置２００に送信する（ステップＳ４７０）。
【０１５４】
サーバ１００ｃから差分情報転送要求を受信すると、同期化処理制御部２０８は、要求元のサーバ１００ｃについて送信キュー２０３の送信状態が「保留」となっているものを「保留解除」に更新する（ステップＳ４７１）。この時の送信キュー２０３を図５４に示す。以降、各クライアント５００から受信したクエリは、サーバ１００ａ及びサーバ１００ｂについては送信状態を「未送信」で、サーバ１００ｃについては送信状態を「保留解除」にして送信キュー２０３に入れる。これにより、クエリ送信処理部２０５は、送信状態が「保留解除」となったクエリを差分情報として古いものから順にサーバ１００ｃに送信する。
【０１５５】
具体的には、クエリ送信処理部２０５は、送信キュー２０３からＢＥＧＩＮクエリを取り出してサーバ１００ｃに転送するとともに（ステップＳ４７２）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４７３）。仲介装置２００の正当性判定部２０６は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ｃから受信すると（ステップＳ４７４）、当該応答と、送信キュー２０３に保存されている応答とを対比する（ステップＳ４７５）。そして、両者が一致しない場合には、サーバ１００ｃについてのエントリをサーバ管理表２０１及び送信キュー２０３から削除した後に、当該サーバ１００ｃに対して再起動指示を送出する。これにより、ステップＳ４１５以降の処理が再試行される。
【０１５６】
サーバ１００ｃへの差分情報転送中にクライアント５００ｂからＵＰＤＡＴＥクエリを受信すると（ステップＳ４７６）、受信クエリ処理部２０４は、サーバ１００ａ及び１００ｂについては送信状態を「未送信」で、サーバ１００ｃについては送信状態を「保留解除」で当該クエリーを送信キュー２０３に投入する（ステップＳ４７７）。この時の送信キュー２０３を図５５に示す。クエリ送信処理部２０５は、送信キュー２０３から当該クエリを取り出し、送信状態が「未送信」であるサーバ１００ａ及び１００ｂに転送し（ステップＳ４７８，Ｓ４７９）、それぞれのサーバ１００ａ及び１００ｂについて送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４８０）。正当性判定部２０６は、各サーバ１００ａ及び１００ｂからＵＰＤＡＴＥが正常したことを通知するパケットを受信すると（ステップＳ４８１，Ｓ４８２）、各応答の正当性を判定して正当な応答の１つをクライアント５００ｂに返すとともに（ステップＳ４８３）、該応答を送信キュー２０３に保存する（ステップＳ４８４）。
【０１５７】
全ての差分情報の転送が終了し（すなわち送信キュー２０３から「保留解除」のクエリを全て送出し終わり）、且つ、差分情報としてのクエリの処理が正常に処理された時点で、サーバ１００ａのデータベース１０１ａとサーバ１００ｃのデータベース１０１ｃの同期化が完了するので、サーバ１００ｃをシステムに組み込むべくサーバ１００ｃについてのサーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新する。なお、システムへの組み込みのタイミングは、正常稼働中のサーバ１００においてクエリの実行中であっても構わず、またトランザクションが継続中であっても構わない点に留意されたい。
【０１５８】
図５５の例では、まず、トランザクションＩＤが５番のＵＰＤＡＴＥクエリからトランザクションＩＤが６番のＩＮＳＥＲＴクエリについて、前述のステップＳ４７２〜Ｓ４７５と同様の処理を行う。以下、図５５の例における、トランザクションＩＤが５番のＣＯＭＭＩＴクエリと、トランザクションＩＤが６番のＵＰＤＡＴＥクエリの処理について詳述する。
【０１５９】
クエリ送信処理部２０５は、送信キュー２０３からＣＯＭＭＩＴクエリを取り出してサーバ１００ｃに転送するとともに（ステップＳ４９０）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４９１）。仲介装置２００の正当性判定部２０６は、トランザクションが確定したことを通知する応答パケットをサーバ１００ｃから受信すると（ステップＳ４９２）、当該応答と、送信キュー２０３に保存されている応答とを対比する（ステップＳ４９３）。そして、両者が一致しない場合には、サーバ１００ｃについてのエントリをサーバ管理表２０１及び送信キュー２０３から削除した後に、当該サーバ１００ｃに対して再起動指示を送出する。これにより、ステップＳ４１５以降の処理が再試行される。
【０１６０】
この時点でトランザクションＩＤ５のトランザクションは全てのサーバ１００において処理が終了し、且つ、送信キュー２０３にはトランザクションＩＤ５に属する各クエリは全てのサーバ１００ａ，１００ｂ，１００ｃについて送信状態が「送信完了」となったので、応答送信処理部２０７は、当該トランザクションに属するクエリのエントリを送信キュー２０３から削除する（ステップＳ４９４）。この時の送信キュー２０３を図５６に示す。
【０１６１】
次いで、図４３に示すように、クエリ送信処理部２０５は、送信キュー２０３からＵＰＤＡＴＥクエリを取り出してサーバ１００ｃに転送するとともに（ステップＳ４９５）、送信キュー２０３の送信状態を「送信完了」に更新する（ステップＳ４９６）。仲介装置２００の正当性判定部２０６は、ＵＰＤＡＴＥが正常に処理されたことを通知する応答パケットをサーバ１００ｃから受信すると（ステップＳ４９７）、当該応答と、送信キュー２０３に保存されている応答とを対比する（ステップＳ４９８）。そして、両者が一致しない場合には、サーバ１００ｃについてのエントリをサーバ管理表２０１及び送信キュー２０３から削除した後に、当該サーバ１００ｃに対して再起動指示を送出する。これにより、ステップＳ４１５以降の処理が再試行される。
【０１６２】
この時点で送信キュー２０３には送信状態が「保留解除」のクエリがなくなったので、応答送信処理部２０７は、サーバ１００ｃをシステムに組み込むべくサーバ１００ｃについてのサーバ管理表２０１の稼働状態を「ａｃｔｉｖｅ」に更新する（ステップＳ４９９）。なお、このステップＳ４９９の処理は、第１の実施形態で前述したステップＳ１４４，Ｓ２４２の処理に対応するものである。
【０１６３】
以上のように本実施の形態では、第１の実施の形態と比較して、同期化処理において実施されるスナップショットの作成中にもクライアントに対してサービス提供を維持できるという効果を有する。他の作用・効果については第１の実施の形態と同じである。
【０１６４】
なお、本実施の形態では、スナップショットを作成する同期化用のサーバ１００ｂと、システムに再び組み込まれるサーバ１００ｃとに対して、それぞれ独立したタイミングで差分情報を転送していたが、サーバ１００ｃから差分情報転送要求があった際に両サーバ１００ｂ，１００ｃに同一の差分情報を転送するようにしてもよい。
【０１６５】
また、本実施の形態では、同期化処理用サーバ１００ｂにおける差分情報の処理結果が、正常稼働中のサーバ１００ａでの処理結果と一致しない場合には、当該サーバ１００ｂだけでなくサーバ１００ｃに対する処理を中断し、第１の実施の形態の手法を用いて当該サーバ１００ｂのみをシステムに組み込み、その後にサーバ１００ｃをシステムに組み込む処理を再試行していた。一方、この変形例として、サーバ１００ｃに対する処理を継続してサーバ１００ｃをシステムに組み込み、その後にサーバ１００ｂをシステムに組み込むようにしてもよい。この方法では、クライアント５００へのサービス提供を継続できる点、サーバ１００ｃの同期化処理を無駄にやり直す必要がないという点で好適である。
【０１６６】
以上、本発明の実施形態について詳述したが、上記実施の形態は例示的なものであり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれるものである。なお、以下の各変形例は適宜組み合わせて上記各実施の形態に適用できる。
【０１６７】
上記実施の形態では、同期化処理の再試行を行う際には、新規サーバ１００の再起動から再試行していたが、再起動は行わずに、新規サーバ１００から仲介装置２００へのデータベースサーバ同期化要求（第１の実施形態におけるステップＳ３１２，第２の実施の形態におけるステップＳ４１４）から再試行するようにしてもよい。
【０１６８】
また、上記実施の形態では、同期化処理の再試行を行う際にはスナップショットを再度作成し直していたが、再試行前に作成したスナップショットを用いて同期化処理を行ってもよい。これにより、再試行時の同期化処理時間を短縮化できる。なお、この方法を実現するためには、上記実施形態のごとく送信キュー２０３に差分情報として記憶しているクエリを適宜削除するのではなく、同期化が完了するまでに保持しておく必要がある。
【０１６９】
また、上記実施の形態では、送信状態が「保留解除」となっているクエリを送信キュー２０３から取り出して差分情報としてサーバ１００に対して転送し、該転送中にクライアント５００からクエリを受信すると、当該サーバ１００についての送信状態を「保留解除」にして送信キュー２０３に投入する処理を行っている。そして、送信状態が「保留解除」となっているクエリが全てサーバ１００において処理された後に当該サーバ１００をシステムに組み込む処理を行っている。このような処理では、クライアント５００からのクエリ受信頻度が高いとサーバ１００のシステムへの組み込みに時間を要することが考えられる。そこで、例えば送信キュー２０３に送信状態が「保留解除」として記憶されているクエリが所定数以下となったら、受信クエリ処理部２０４が送信キュー２０３へのクエリの投入を一停止するなど所定条件で差分情報の転送処理を優先させるようにしてもよい。
【０１７０】
また、上記実施の形態では、クライアント５００から受信した全てのクエリを送信キュー２０３に保存しておき、同期化処理時には該送信キュー２０３に保存されているクエリを差分情報としてサーバ１００に転送しているが、ＳＥＬＥＣＴクエリのようにデータベース１０１の更新を行わない参照系クエリについては差分情報としてのサーバ１００への転送を行わないようにしてもよい。これにより、同期化処理の処理時間を短縮化できる。
【０１７１】
さらに、ＵＰＤＡＴＥクエリのようにデータベース１０１の更新を行う更新系クエリのみを転送し、参照系クエリやトランザクション制御クエリ（ＢＥＧＩＮ，ＲＯＬＬＢＡＣＫ等）の転送を行わないようにしてもよい。そして、当該更新系クエリを差分情報としてサーバ１００に転送する際には、サーバ１００においてＡｕｔｏＣｏｍｍｉｔモードで当該クエリを処理させるようにする。これにより、更に同期化処理の短縮化及び記憶容量の節約が可能となる。ただし、この場合にはサーバ１００に対してクエリを転送する順序が、正常稼働中のサーバ１００で処理された順序と一致することを保証する必要がある。これを実現するためには、各更新系クエリに対する正常稼働中サーバ１００からの処理応答から正常稼働中サーバ１００における各クエリの実際の処理順序を把握し、当該順序に従って各クエリを転送すればよい。
【０１７２】
また、上記実施の形態では、サーバ１００においてトランザクションが継続中であっても仲介装置２００がサーバ１００に対してスナップショットの作成指示を送信していたが、継続中のトランザクションが無くなった時点でスナップショットの作成指示を送信するようにしてもよい。これにより、データベース１０１として、トランザクションの継続中にはスナップショットの作成ができないものや、トランザクションの継続中であってもスナップショットの作成は開始できるが当該スナップショットにトランザクションに係るクエリが反映されるか否かが不確定なものを利用することができる。また、前述の第１の実施の形態においてはスナップショットの作成中にはクライアント５００へのサービスが停止するので、クライアント５００によってはトランザクション失敗と判断してＲＯＬＬＢＡＣＫクエリを仲介装置２００に送信する場合がある。本変形例では、このような余計なＲＯＬＬＢＡＣＫ処理を未然に防止できる。
【０１７３】
また、上記の実施の形態では、同期化処理中に送信キュー２０３から各クエリを削除するタイミングは、当該クエリが属するトランザクションが全てのサーバ１００において終了した時点としていた。この方法では、通常動作時におけるクエリの削除タイミングと同じなので実装が容易であるという利点がある。一方、同期化処理中には、送信キュー２０３のクエリが差分情報としてサーバ１００において処理されたら随時削除するようにしてもよい。また、同期化処理が完了した後に一括して削除するようにしても良い。
【０１７４】
また、上記の実施の形態では、クエリのバッファリング機能と同期化処理用の差分情報の記憶機能とを送信キュー２０３に統合させていたが、それぞれ機能毎に記憶手段を設けるようにしてもよい。なお、この場合には、サーバ１００が３台構成となっているときには、システムに組み込もうとするサーバ１００と、同期化処理用サーバ１００とで差分情報記憶部を共有できるので、記憶容量を節約できるという点で有利である。
【０１７５】
また、上記の実施の形態に加えて更に、各サーバ１００にデータベース１０１やデータベース制御部１０２の障害を検出する障害検出手段を設けてもよい。この障害検出手段は、データベース１０１やデータベース制御部１０２の動作を定期的に監視することで障害を検出し、障害検出時には仲介装置２００に障害発生を通知する。これにより、仲介装置２００では各サーバ１００やネットワークでの障害発生検出をより確実且つ効率的に行うことができる。
【０１７６】
また、各サーバは要求に応じて同じ応答をするならば同じ実装である必要はない。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラオプション、ハードウェアかソフトウェアか、などが異なっていてもよい。サーバには、ＰｏｓｔｇｒｅＳＱＬなどのフリーソフトウェアやＯｒａｃｌｅなどの市販のソフトウェア、独自開発のソフトウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サーバ１００ａはＰｏｓｔｇｒｅＳＱＬでサーバ１００ｂはＯｒａｃｌｅでも良い。
【０１７７】
ＤＢＭＳとしては、市中品（例えば、ＯｒａｃｌｅやＰｏｓｔｇｒｅＳＱＬ）を使う場合は、データベース制御部１０２は、データベース管理部とデータベースサーバ管理部に機能を分けることによって、市中品を無改造で使うことができる。データベース管理部は、データベース１０１を直接操作するもので、例えばＰｏｓｔｇｒｅＳＱＬの場合はｐｏｓｔｍａｓｔｅｒやｐｏｓｔｇｒｅｓに相当する。データベースサーバ管理部は、仲介装置２００とデータベース管理部の間に介在し、クエリの送受信を中継したりするほかに、他のサーバを同期化する際のデータベース１０１のスナップショットを作成したり、そのスナップショットを他のサーバへ転送したりする処理を行う。また、上記データベースサーバ管理部を仲介装置２００に配置しても良い。このような構成にすることで、冗長化されていない通常使用しているデータベースシステムにおいて、サーバ１００とクライアント５００の間に中間装置２００を配置し、さらにサーバ１００を増設するだけでサーバ１００の冗長化を実現できる。これは既存のデータベースシステムをなるべく変更せず簡単に冗長化したい場合に好適である。
【０１７８】
上記実施の形態では、スナップショットの作成にはＤＢＭＳサーバの種類に依存しない汎用のツール（同期化用サーバからＳＥＬＥＣＴクエリで全てのデータを取り出すツール）を用いることを前提とし、また、新規サーバでのリストアにも汎用のツール（新規サーバへＩＮＳＥＲＴクエリで全てのデータを入れるツール）を用いること前提としていた。これにより、ＤＢＭＳサーバの種類に依存することなく本発明を実施できるだけでなく、異種ＤＢＭＳ間（例えばＰｏｓｔｇｒｅＳＱＬとＯｒａｃｌｅ）でのクエリ翻訳手段を併用することで同一システム内に異種ＤＢＭＳを混在させることができる。異種ＤＢＭＳサーバが混在したシステムとしては、例えば一台のＯｒａｃｌｅと二台のＰｏｓｔｇｒｅＳＱＬを使った三重化システムが挙げられる。このように、高価なライセンスを必要とするサーバと、ライセンスが低廉又は無料のサーバを混在させることで、高価なライセンスを必要とするサーバの冗長化を低コストで実現できる。
【０１７９】
また、上記実施の形態では、汎用のスナップショット作成ツールを用いることを前提としていたため、第１の実施の形態においてはスナップショット作成開始から作成完了までは新しいクエリを実行させていなかった。これは該スナップショット作成ツールでは、スナップショット作成開始以降にＣＯＭＭＩＴされる更新クエリがスナップショットに反映されるか否かが確定しないためである。これにより、データベースサイズが大きい場合には、新しいクエリを実行できない時間が長期化するおそれがある。そこで、スナップショット作成中でもクエリを実行でき、且つ、スナップショット作成開始以降にＣＯＭＭＩＴされる更新クエリはスナップショットに反映されないことが保証されているツールを用いると、スナップショット作成中でもクエリを実行できる。このようなツールは一般的にはＤＢＭＳサーバ固有のツールとして提供されている。例えば、ＰｏｓｔｇｒｅＳＱＬでは、ｐｇ＿ｄｕｍｐやＰｏｓｔｇｒｅＳＱＬ８．０で機能追加されるＰＩＴＲ（Point In Time Recovery）機能が挙げられる。
【０１８０】
スナップショット作成ツールとしてｐｇ＿ｄｕｍｐを用いた場合の動作について上記第１の実施形態の変形例として説明する。この場合、図１７におけるステップＳ３１７が「ｐｇ＿ｄｕｍｐの実行指示」に相当し、ステップＳ３１８がｐｇ＿ｄｕｍｐの開始、ステップＳ３２２がｐｇ＿ｄｕｍｐの完了となる。汎用ツールを用いた上記第１の実施形態ではステップＳ３０９のＵＰＤＡＴＥクエリはスナップショット作成完了まで実行できないが、ｐｇ＿ｄｕｍｐを用いた場合はステップＳ３１８の直後に実行できる。また、ステップＳ３１９のＢＥＧＩＮクエリは、ステップＳ３３８のＵＰＤＡＴＥクエリと同様に、仲介装置２００が受信すると即座にサーバ１００ａへ転送され処理される。このように、ｐｇ＿ｄｕｍｐを用いればスナップショット作成中でもクエリの処理を全く中断する必要はない。
【０１８１】
また、上記実施の形態では、システムへの組み込み要求（新規サーバのデータベース同期化要求）は当該新規サーバ１００のデータベース制御部１０２が仲介装置２００へ送信しているが、さらに保守端末などの他の装置から送信可能にしてもよいし、オペレータが仲介装置２００に直接指示可能としても良い。
【０１８２】
さらに、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが、ハードウェアで実装しても良い。
【０１８３】
また、上記実施の形態では、仮想サーバ８００を構成する仲介装置２００は１台のみであったが、複数台設けて冗長性を持たせることにより、より可用性の高い構成とすることも可能である。仲介装置を多重化させる技術については、例えば本願出願人による特開２００３−３４５６７９号公報に記載されたものなどを用いればよい。
【０１８４】
また、上記実施の形態では、クライアント５００とサーバ１００はそれぞれ別のネットワーク３００，４００に属するようにし、仲介装置２００が両ネットワーク３００，４００を仲介するようなネットワーク構成としたが、本発明ではネットワーク構成は不問である。例えば、１つのネットワークにクライアント５００，サーバ１００，仲介装置２００が属するように構成してもよい。
【０１８５】
さらに、上記各実施の形態では、データベース一致検査装置６００を多重化データベースシステムの外側、すなわちネットワーク４００に接続していたが、多重化データベースシステムの内側のネットワーク３００にデータベース一致検査装置６００を接続するようにしてもよい。
【図面の簡単な説明】
【０１８６】
【図１】第１の実施形態に係る多重化データベースシステムの構成図
【図２】第１の実施形態に係る仲介装置の機能ブロック図
【図３】第１の実施形態に係るサーバ管理表の一例を示す図
【図４】第１の実施形態に係るトランザクション管理表の一例を示す図
【図５】第１の実施形態に係る送信キューの一例を示す図
【図６】各サーバが正常稼働している場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図７】図５の動作におけるサーバ管理表の一例
【図８】図５の動作におけるトランザクション管理表の一例
【図９】サーバが故障した場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１０】図９の動作におけるトランザクション管理表の一例
【図１１】図９の動作におけるサーバ管理表の一例
【図１２】図９の動作における送信キューの一例
【図１３】サーバにより異なる順序でクエリが実行された場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１４】サーバにより異なる順序でクエリが実行された場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１５】サーバにより異なる順序でクエリが実行された場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１６】サーバにより異なる順序でクエリが実行された場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１７】第１の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図１８】第１の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図１９】第１の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図２０】第１の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図２１】図１７乃至図２０の動作におけるサーバ管理表の一例
【図２２】図１７乃至図２０の動作におけるトランザクション管理表の一例
【図２３】図１７乃至図２０の動作における送信キューの一例
【図２４】図１７乃至図２０の動作における送信キューの一例
【図２５】図１７乃至図２０の動作におけるサーバ管理表の一例
【図２６】図１７乃至図２０の動作における送信キューの一例
【図２７】図１７乃至図２０の動作におけるトランザクション管理表の一例
【図２８】図１７乃至図２０の動作における送信キューの一例
【図２９】図１７乃至図２０の動作における送信キューの一例
【図３０】図１７乃至図２０の動作における送信キューの一例
【図３１】図１７乃至図２０の動作におけるサーバ管理表の一例
【図３２】図１７乃至図２０の動作における送信キューの一例
【図３３】図１７乃至図２０の動作における送信キューの一例
【図３４】図１７乃至図２０の動作における送信キューの一例
【図３５】図１７乃至図２０の動作における送信キューの一例
【図３６】図１７乃至図２０の動作における送信キューの一例
【図３７】図１７乃至図２０の動作における送信キューの一例
【図３８】図１７乃至図２０の動作におけるサーバ管理表の一例
【図３９】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図４０】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図４１】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図４２】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図４３】第２の実施形態に係る多重化データベースシステムにおける同期化処理を説明するシーケンスチャート
【図４４】図３９乃至図４３の動作におけるサーバ管理表の一例
【図４５】図３９乃至図４３の動作における送信キューのデータ構造の一例
【図４６】図３９乃至図４３の動作における送信キューの一例
【図４７】図３９乃至図４３の動作における送信キューの一例
【図４８】図３９乃至図４３の動作におけるサーバ管理表の一例
【図４９】図３９乃至図４３の動作における送信キューの一例
【図５０】図３９乃至図４３の動作における送信キューの一例
【図５１】図３９乃至図４３の動作における送信キューの一例
【図５２】図３９乃至図４３の動作における送信キューの一例
【図５３】図３９乃至図４３の動作における送信キューの一例
【図５４】図３９乃至図４３の動作における送信キューの一例
【図５５】図３９乃至図４３の動作における送信キューの一例
【図５６】図３９乃至図４３の動作における送信キューの一例
【図５７】従来のデータベース同期化システムの構成図
【図５８】データベースのテーブルの一例
【図５９】処理順序が問題となるトランザクションの一例
【図６０】処理順序が問題となるトランザクションの一例
【符号の説明】
【０１８７】
１００…サーバ、１０１…データベース、１０２…データベース制御部、２００…仲介装置、２０１…サーバ管理表、２０２…トランザクション管理表、２０３…送信キュー、２０４…受信クエリ処理部、２０５…クエリ送信処理部、２０６…正当性判定部、２０７…応答送信処理部、２０８…同期化処理制御部、３００，４００…ネットワーク、５００…クライアント、６００…データベース一致検査装置。
【図１】
2007241325.tif 000003
【図２】
2007241325.tif 000004
【図３】
2007241325.tif 000005
【図４】
2007241325.tif 000006
【図５】
2007241325.tif 000007
【図６】
2007241325.tif 000008
【図７】
2007241325.tif 000009
【図８】
2007241325.tif 000010
【図９】
2007241325.tif 000011
【図１０】
2007241325.tif 000012
【図１１】
2007241325.tif 000013
【図１２】
2007241325.tif 000014
【図１３】
2007241325.tif 000015
【図１４】
2007241325.tif 000016
【図１５】
2007241325.tif 000017
【図１６】
2007241325.tif 000018
【図１７】
2007241325.tif 000019
【図１８】
2007241325.tif 000020
【図１９】
2007241325.tif 000021
【図２０】
2007241325.tif 000022
【図２１】
2007241325.tif 000023
【図２２】
2007241325.tif 000024
【図２３】
2007241325.tif 000025
【図２４】
2007241325.tif 000026
【図２５】
2007241325.tif 000027
【図２６】
2007241325.tif 000028
【図２７】
2007241325.tif 000029
【図２８】
2007241325.tif 000030
【図２９】
2007241325.tif 000031
【図３０】
2007241325.tif 000032
【図３１】
2007241325.tif 000033
【図３２】
2007241325.tif 000034
【図３３】
2007241325.tif 000035
【図３４】
2007241325.tif 000036
【図３５】
2007241325.tif 000037
【図３６】
2007241325.tif 000038
【図３７】
2007241325.tif 000039
【図３８】
2007241325.tif 000040
【図３９】
2007241325.tif 000041
【図４０】
2007241325.tif 000042
【図４１】
2007241325.tif 000043
【図４２】
2007241325.tif 000044
【図４３】
2007241325.tif 000045
【図４４】
2007241325.tif 000046
【図４５】
2007241325.tif 000047
【図４６】
2007241325.tif 000048
【図４７】
2007241325.tif 000049
【図４８】
2007241325.tif 000050
【図４９】
2007241325.tif 000051
【図５０】
2007241325.tif 000052
【図５１】
2007241325.tif 000053
【図５２】
2007241325.tif 000054
【図５３】
2007241325.tif 000055
【図５４】
2007241325.tif 000056
【図５５】
2007241325.tif 000057
【図５６】
2007241325.tif 000058
【図５７】
2007241325.tif 000059
【図５８】
2007241325.tif 000060
【図５９】
2007241325.tif 000061
【図６０】
2007241325.tif 000062