(57)【要約】【課題】  少ない同期化用データで復旧後のデータベースサーバの同期化を図るとともに、システム全体をダウンさせることなく、データベースサーバのデータ記憶状況に拘わらずデータベースサーバを任意に切り離し又は組み込むことができる多重化データベースシステムを提供する。【解決手段】  新規のサーバ１００から組み込み要求があると、正常稼働中のサーバ１００がスナップショットを作成し、新規のサーバ１００に転送して該スナップショットからデータベース１０１を復元する。仲介装置２００は、スナップショット作成後からクライアントからのクエリを差分情報として蓄積して、新規のサーバ１００におけるスナップショットからのデータベースの復元後に差分情報を転送する。【選択図】  図１
2007241322.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）などが挙げられる。
【００３１】
データベース制御部１０２は、ネットワーク３００を介して仲介装置２００から送られてくるパケットに基づき動作する。このパケットは、ＳＱＬなどデータベース１０１での処理に係るもの、同期化処理に係るものに大別される。ＳＱＬなどデータベース１０１での処理に係るものについては、データベース制御部１０２は、当該パケットをデータベース１０１に渡し、データベース１０１からの処理結果を仲介装置２００に返す。
【００３２】
一方、同期化処理に係るものは、さらに自身が本システムに組み込まれている場合のものと、障害復旧時などこれからシステムに組み込む場合のものとに別れる。前者については、スナップショットの作成指示がある。データベース制御部１０２は、スナップショット作成指示を仲介装置２００から受信すると、データベース１０１のスナップショットを作成する。そして、スナップショットの作成が完了すると、スナップショット作成完了を仲介装置２００に通知する。そして、作成したスナップショットを、スナップショット作成指示で指示されている転送先の他のサーバ１００に転送する。
【００３３】
他方、障害復旧時などこれからシステムに組み込む場合、データベース制御部１０２は、他のデータベースからスナップショットを受信すると、このスナップショットを用いて自身のデータベース１０１を復元する。データベース１０１の復元が完了すると仲介装置２００に対して差分情報転送要求を送出する。後述するように、差分情報転送要求に応じて仲介装置２００から差分情報が転送されるので、この差分情報を用いてデータベース１０１を復元する。
【００３４】
また、データベース制御部１０２は、本システムに組み込む際には、仲介装置２００に対して組み込み要求を送信する。この組み込み要求は、サーバ１００の起動時や、必要に応じて任意のタイミングで送出する。
【００３５】
仲介装置２００は、本システム内のサーバ１００を管理するサーバ管理表２０１と、トランザクションを管理するトランザクション管理表２０２と、同期化用に差分情報を蓄積する差分情報蓄積部２０３と、サーバ１００に送信するクエリを一時保存する送信キュー２０４と、クライアント５００・サーバ１００間での処理の仲介やサーバ１００の同期化制御などを行うサーバ制御部２１０とを備えている。
【００３６】
サーバ管理表２０１は、サーバが正常稼働中（ａｃｔｉｖｅ）か、障害などで停止している（ｄｏｗｎ）か、という状態を保存している。図２にサーバ管理表の一例を示す。サーバ管理表２０１は、図２に示すように、サーバ１００を識別するためのサーバＩＤと、サーバの稼働状態から構成されている。図２の例では、サーバ１００ａとサーバ１００ｂとが登録されており、稼働状態は共に正常稼働を示すａｃｔｉｖｅである。また、本実施形態では、サーバＩＤとしてサーバ１００に付されたＩＰアドレスを用いた。
【００３７】
トランザクション管理表２０２は、現在実行中の又は実行開始を保留されているトランザクションの有無を記憶する。図３にトランザクション管理表２０２の一例を示す。図３に示すように、トランザクション管理表２０２は、クライアントを一意に識別するクライアントＩＤとトランザクションを一意に識別するトランザクションＩＤから構成される。これらのペアは、トランザクション開始時にトランザクション管理表２０２に登録され、トランザクション終了時にトランザクション管理表２０２から削除される。クライアントＩＤは、例えばクライアント５００のＩＰアドレスやポート番号である。トランザクションＩＤは新しいトランザクションが発生する毎にサーバ制御部２１０が新たに割り振る。
【００３８】
差分情報蓄積部２０３は、サーバ同期化時にクライアント５００から受信する全てのクエリを蓄積する。図４に差分情報蓄積部２０３が蓄積している差分情報の一例を示す。差分情報蓄積部２０３の各データは、図４に示すように、クライアント５００が送信したクエリと、このクエリが所属するトランザクションＩＤとから構成される。トランザクションＩＤはトランザクション管理表２０２から取得する。同期化処理時におけるクライアント５００からの新たなクエリは、この差分情報蓄積部２０３の最後に追加される。つまり、上から古いクエリが蓄積されている。図４の例では、トランザクションＩＤ＝１のＢＥＧＩＮが一番古く、ＣＯＭＭＩＴが一番新しい。
【００３９】
送信キュー２０４は、各クライアント５００から受信したクエリを各サーバ１００に送信するまで一時的に保存するバッファメモリである。図５に送信キュー２０４の一例を示す。送信キュー２０４の各データは、図５に示すように、クライアント５００が送信したクエリと、このクエリが所属するトランザクションＩＤと、サーバ１００に送信したか否かを表す送信情報とから構成される。トランザクションＩＤはトランザクション管理表２０２から取得する。クライアント５００からの新たなクエリは、この送信キュー２０４の最後に追加される。つまり、上から古いクエリが蓄積されている。図５の例では、トランザクションＩＤ＝１のＢＥＧＩＮが一番古く、トランザクションＩＤ＝２のＢＥＧＩＮが一番新しい。この送信キュー２０４の送信状態は、クライアント５００からクエリを受信した際には「未送信」が設定され、正常稼働中の全てのサーバ１００に送信されると「送信完了」が設定される。送信完了となったエントリは、直ちに又は所定期間経過後に送信キュー２０４から削除される。
【００４０】
サーバ制御部２１０は、通常の処理（同期化処理時以外の処理）として、クライアント５００からのパケットをネットワーク４００経由で受信し、サーバ管理表２０１を見て正常稼働している全てのサーバ１００へ該パケットを転送する。ここで、サーバ１００へ転送するパケットは、送信キュー２０４に「未送信」として記憶されているクエリが対象であり、送信キュー２０４に記憶されている古いクエリから順に転送される。そして、サーバ１００からのパケットをネットワーク３００経由で受信し後述するパケットの正当性判断方法により１つ以上の該パケットのうち１つを選出し１つの正しいパケットをネットワーク４００を経由してクライアント５００へ転送する。なお、同期化処理時には、「未送信」のクエリであっても新規トランザクションに属するクエリは送信せず、実行中のトランザクションに属するクエリのみを古い順に正常稼働中のサーバ１００に送信する。
【００４１】
ここで、サーバ制御部２１０は、クライアント５００からの処理要求を解析してトランザクションの開始と終了を検出してトランザクション管理表２０２を更新する。トランザクション開始と終了をサーバ制御部２１０が検出する方法は、ＤＢＭＳの種類によって異なる。例えば前述のＰｏｓｔｇｒｅＳＱＬの場合は、トランザクションの開始はクライアント５００が「ＢＥＧＩＮ」というＳＱＬを送信した時であり、トランザクションの終了はクライアント５００が「ＣＯＭＭＩＴ」「ＲＯＬＬＢＡＣＫ」というＳＱＬを送信した時である。また、Ｏｒａｃｌｅの場合は、トランザクションの開始はクライアント５００が有効なＳＱＬを送信したときであり（明示的なトランザクションの開始を宣言するＳＱＬは無い）、トランザクションの終了はクライアント５００が「ＣＯＭＭＩＴ」「ＲＯＬＬＢＡＣＫ」というＳＱＬを送信した時である。また、ＡＵＴＯ  ＣＯＭＭＩＴモードで動作する場合には、クライアント５００から受信したＳＱＬ文はそれぞれ１つの独立したトランザクションに属していると解釈できるので、クライアント５００からＳＱＬを受信する毎に、該ＳＱＬ実行前にトランザクションが開始されるとともにＳＱＬ実行後に当該トランザクションが終了したこととして扱うことができる。
【００４２】
また、パケットの正当性判断方法は、例えば、多数決で決める方法や、受信したパケットを所定のルールに基づいて判断する方法がある。例えば、クライアント５００からの「参照」要求に対して「更新成功」という応答が返ってきた場合、正常であればそのような応答はあり得ないので（参照成功など参照に関する応答のはず）、この応答パケットは正しくないと判断する。また、パケット中にデータ長フィールドがある場合、このデータ長フィールドの値と実際に受信したパケット長を比較し、異なる場合は正しくないと判断する。また、複数のサーバ１００の中からＭａｓｔｅｒサーバを予め１台決めておき、このサーバ１００からのパケットを常に正しいと判断する。また、上記複数の方法を併用する方法もある。例えば、３台で多数決を行った結果、パケットの中身が全てバラバラであり、多数派のパケットを決められない場合はＭａｓｔｅｒサーバのパケットを正しいと判断する。正常稼働しているサーバが１つだけの場合は、そのサーバからの応答パケットを正常と判断する。
【００４３】
サーバ制御部２１０は、正当ではない応答を送信したサーバ１００は障害と判断し、そのサーバ１００についてはサーバ管理表２０１から登録を削除することによりシステムから切り離す。なお、応答を返してこないサーバ１００も障害と判断する。
【００４４】
さらに、サーバ制御部２１０は、ネットワーク３００を介してサーバ１００からシステムの組み込み要求を受信すると、この新規のサーバ１００と、正常稼働中のサーバ１００とを同期化させる処理を行う。以下にその処理について説明する。
【００４５】
サーバ制御部２１０は、サーバ１００からシステムの組み込み要求を受信すると、正常稼働中のサーバ１００に対してスナップショットの作成指示を送出する。ここで、スナップショットの作成指示を送出するタイミングは、サーバ１００においてトランザクションが実行中でないことが求められる。これはスナップショット作成中にトランザクションがＲＯＬＬＢＡＣＫするとデータの同期化が図れない場合があることを防止するためや、ＣＯＭＭＩＴされていないために更新データがスナップショットに反映されないことを防止するためである。このためサーバ制御部２１０は、処理中のトランザクションが終了するまでスナップショットの作成指示の送出を待つとともに、スナップショット作成完了通知をサーバ１００から受信するまでは新規トランザクションを開始しないようにしている。そして、新規トランザクションに係るＳＱＬについては、スナップショット作成完了通知の受信後に、正常稼働中のサーバ１００で処理するとともに、差分情報蓄積部２０３に蓄積する。差分情報蓄積部２０３に蓄積するクエリは、トランザクション制御ＳＱＬ、参照系ＳＱＬ及び更新系ＳＱＬを含む全てのＳＱＬが対象となる。
【００４６】
サーバ制御部２１０がスナップショットの作成指示を送出すると、当該スナップショットは新規のサーバ１００に転送され、このサーバ１００からサーバ制御部２１０に対して差分情報転送要求が送出される。サーバ制御部２１０は、差分情報転送要求を受信すると、新規のサーバ１００に対して差分情報蓄積部２０３に蓄積されているクエリを古いものから順次送信する。差分情報蓄積部２０３に蓄積されているＳＱＬを全て送出すると、サーバ制御部２１０は、新規サーバ１００をシステムに組み込むべくサーバ管理表２０１を更新する。
【００４７】
ここで、サーバ制御部２１０は、差分情報の送出中にクライアント５００から新たなクエリを受信する場合があるが、この場合は当該クエリを差分情報蓄積部２０３の最後に追加するとともに正常稼働中のサーバ１００へ送信すれば良い。ただし、クライアント５００のクエリ送出頻度が高い場合などには、差分情報の送出終了まで、すなわち同期化終了まで長時間要する場合が考えられる。そこで、差分情報蓄積部２０３における未送信の差分情報が所定件数以下となったら、クライアント５００からのクエリを一時保留して差分情報の送出のみを行い、まず差分情報の送出を完了させる。そして、前述のように新規サーバ１００をシステムに組み込むべくサーバ管理表２０１を更新した後に、保留していたクエリ処理を再開すると好適である。
【００４８】
クライアント５００は、データベースサーバに対して更新クエリ（データベースを更新するリクエスト）や参照クエリ（データベースの内容を参照するリクエスト）などを発行するものである。
【００４９】
次に、本実施の形態に係る多重化データベースシステムの動作について図面を参照して説明する。まず、サーバ１００ａと１００ｂが正常に動作している場合の動作を図６から図８を参照して説明する。
【００５０】
初期状態では、データベース１０１ａと１０１ｂは完全に同一であり、サーバ管理表２０１は図７のようになっているものとする。また、トランザクション管理表２０２と差分情報蓄積部２０３は空であるとする。各サーバ１００ａ，１００ｂには、テーブルtest#tableが存在しているとする。
【００５１】
クライアント５００ａが172.17.1.1宛にトランザクション開始ＳＱＬを含んだパケットを送信すると、仲介装置２００はそのパケットを受信する（ステップＳ１）。サーバ制御部２１０は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ａのＩＰアドレスとトランザクション番号を登録する（ステップＳ２）。図８にこのときのトランザクション管理表２０２を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー２０４に入れる。
【００５２】
サーバ制御部２１０は、送信キュー２０４から当該「未送信」のクエリを取り出し、サーバ管理表２０１を見て正常稼働している全てのサーバ１００に該パケットを送信する。この場合、サーバ１００ａと１００ｂが正常稼働しているので、サーバ制御部２１０はサーバ１００ａとサーバ１００ｂへ該パケットを転送する（それぞれステップＳ３とＳ４）。そして、各サーバ１００への送信が完了したので送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。仲介装置２００は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａから受信するが（ステップＳ５）、この時点では、未だ全ての応答パケットが揃っているわけではないので（この場合、サーバ１００ｂからの応答パケットが来ていない）、サーバ制御部２１０は何もせずにサーバ１００ｂからの応答パケットを待つ。そして、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ６）、これで全ての応答パケットが揃ったので、サーバ制御部２１０はそれらの応答パケットを互いに比較することでサーバ１００に障害が発生しているか否かをチェックする（ステップＳ７）。この場合、２つの応答パケットはともにトランザクションが正常に開始されたことを示すパケットであるため、障害は無いと判断し応答パケットの１つをクライアント５００ａへ転送する（ステップＳ８）。
【００５３】
次に、クライアント５００ａは、テーブルtest#tableを更新するＳＱＬ（ＵＰＤＡＴＥ）を含んだパケットを172.17.1.1へ送信する（ステップＳ９）。サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。そして、送信キュー２０４から当該クエリを取り出し、サーバ管理表２０１を見て正常稼働しているサーバ、この場合、サーバ１００ａと１００ｂへ該パケットを転送する（それぞれステップＳ１０とＳ１１）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。サーバ１００ａは正常にＵＰＤＡＴＥ完了したことを通知する応答パケットを仲介装置２００に送信し、仲介装置２００がこの応答パケットを受信する（ステップＳ１２）。この時点では全ての応答パケットが全て揃っているわけではないので、サーバ制御部２１０は何もせず待機する。そして、正常にＵＰＤＡＴＥ完了したことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ１３）、これで応答パケットが全て揃ったので、サーバ制御部２１０はそれら応答パケットを互いに比較することでサーバ１００に障害が発生しているか否かをチェックする（ステップＳ１４）。この場合、２つの応答パケットはともにＵＰＤＡＴＥ成功したことを示すパケットであるため、障害は無いと判断し応答パケットの１つをクライアント５００ａへ転送する（ステップＳ１５）。
【００５４】
次に、クライアント５００ａは、テーブルtest#tableへの更新を確定する（実際にデータベースを更新する）ＳＱＬ（ＣＯＭＭＩＴ）を含んだパケットを172.17.1.1へ送信する（ステップＳ１６）。サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。そして、送信キュー２０４から当該クエリを取り出し、サーバ管理表２０１を見て正常稼働しているサーバ、この場合、サーバ１００ａとサーバ１００ｂへ該パケットを転送する（それぞれステップＳ１７とＳ１８）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。サーバ１００ａは正常にＣＯＭＭＩＴ完了したことを通知するパケットを仲介装置２００に送信し、仲介装置２００がこの応答パケットを受信する（ステップＳ１９）。この時点では全ての応答パケットが全て揃っているわけではないので、サーバ制御部２１０は何もせず待機する。そして、正常にＣＯＭＭＩＴ完了したことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ２０）、これで応答パケットが全て揃ったので、サーバ制御部２１０はそれら応答パケットを互いに比較することでサーバ１００に障害が発生しているか否かをチェックする（ステップＳ２１）。この場合、２つの応答パケットはともにＣＯＭＭＩＴ成功したことを示すパケットであるため、障害は無いと判断する。ＣＯＭＭＩＴが正常に完了したことから、トランザクションが終了したことが分かるので、サーバ制御部２１０はトランザクション管理表２０２からこのトランザクションの登録を削除する（ステップＳ２２）。このときのトランザクション管理表２０２は再び初期状態（すなわち空）になる。サーバ制御部２１０は応答パケットの１つをクライアント５００ａへ転送する（ステップＳ２３）。
【００５５】
次に、サーバ１００ｂが故障などで障害になった場合の動作を図９から図１１を参照して説明する。初期状態では、データベース１０１ａと１０１ｂは完全に同一であり、サーバ管理表２０１は前述した図７のようになっているとする。また、トランザクション管理表２０２と差分情報蓄積部２０３は空であるとする。
【００５６】
クライアント５００ａが172.17.1.1宛にトランザクション開始ＳＱＬ（ＢＥＧＩＮ）を含んだパケットを送信すると、仲介装置２００はそのパケットを受信する（ステップＳ３０）。サーバ制御部２１０は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ａのＩＰアドレスとトランザクション番号を登録する（ステップＳ３１）。図１０にこのときのトランザクション管理表２０２を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー２０４に入れる。
【００５７】
サーバ制御部２１０は、送信キュー２０４から当該「未送信」のクエリを取り出し、サーバ管理表２０１を見て正常稼働している全てのサーバ１００、この場合、サーバ１００ａと１００ｂへ該パケットを転送する（それぞれステップＳ３２とＳ３３）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。仲介装置２００は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａから受信するが（ステップＳ３４）、この時点では、未だ全ての応答パケットが揃っているわけではないので（この場合、サーバ１００ｂからの応答パケットが来ていない）、サーバ制御部２１０は何もせずにサーバ１００ｂからの応答パケットを待つ。そして、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ｂから受信すると（ステップＳ３５）、これで全ての応答パケットが揃ったので、サーバ制御部２１０はそれら応答パケットを互いに比較することでサーバ１００に障害が発生しているか否かをチェックする（ステップＳ３６）。この場合、２つの応答パケットはともにトランザクションが正常に開始されたことを示すパケットであるため、障害は無いと判断し応答パケットの１つをクライアント５００ａへ転送する（ステップＳ３７）。
【００５８】
ここで、サーバ１００ｂは、ステップＳ３５で応答パケットを返した後、故障などの障害が発生してダウンしたものとする（ステップＳ３８）。
【００５９】
次に、クライアント５００ａは、テーブルtest#tableを更新するＳＱＬ（ＵＰＤＡＴＥ）を含んだパケットを172.17.1.1へ送信する（ステップＳ３９）。サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。そして、送信キュー２０４から当該クエリを取り出し、サーバ管理表２０１を見て正常稼働しているサーバ、この場合、サーバ１００ａと１００ｂへ該パケットを転送する（それぞれステップＳ４０とＳ４１）。この時点では、サーバ制御部２１０はサーバ１００ｂのダウンを知らないので、サーバ１００ｂが正常稼働しているという情報がサーバ管理表２０１に格納されたままである。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。サーバ１００ａは正常にＵＰＤＡＴＥ完了したことを通知する応答パケットを仲介装置２００に送信し、仲介装置２００がこの応答パケットを受信する（ステップＳ４２）。この時点では応答パケットが全て揃っているわけではないので、サーバ制御部２１０は何もせず待機する。しかし、サーバ１００ｂはダウンしているのでサーバ１００ｂからの応答パケットはいつまで経っても仲介装置２００には届かない。これによりサーバ制御部２１０はタイムアウトし、サーバ１００ｂのダウンを検知する。そして、サーバ制御部２１０はサーバ管理表２０１のサーバ１００ｂをａｃｔｉｖｅからｄｏｗｎ（サーバ停止状態）に書き換える（ステップＳ４３）。そのときのサーバ管理表２０１を図１１に示す。サーバ制御部２１０は応答パケットをクライアント５００ａへ転送する（ステップＳ４４）。ここでは、クライアント５００ａにとって、サーバ１００ｂが障害になったかどうかは認識せず、今までと同様に仮想サーバ８００からサービスを受けることができることに注目すべきである。
【００６０】
次に、クライアント５００ａは、テーブルtest#tableへの更新を確定するＳＱＬ（ＣＯＭＭＩＴ）を含んだパケットを172.17.1.1へ送信する（ステップＳ４５）。サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。そして、送信キュー２０４から当該クエリを取り出し、サーバ管理表２０１を見て正常稼働しているサーバ、この場合、サーバ１００ａのみへ該パケットを転送する（ステップＳ４６）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。サーバ１００ａは正常にＣＯＭＭＩＴ完了したことを通知する応答パケットを送信し、仲介装置２００がこの応答パケットを受信する（ステップＳ４７）。ＣＯＭＭＩＴが正常に完了したことから、トランザクションが終了したことが分かるので、サーバ制御部２１０はトランザクション管理表２０２からこのトランザクションの登録を削除する（ステップＳ４８）。このときのトランザクション管理表２０２は再び初期状態（すなわち空）になる。サーバ制御部２１０は応答パケットをクライアント５００ａへ転送する（ステップＳ４９）。
【００６１】
ここで、ステップＳ４６によって、サーバ１００ａのデータベース１０１ａは、クライアント５００ａからのＵＰＤＡＴＥ（ステップＳ３９）が反映されているのに対して、サーバ１００ｂのデータベース１０１ｂにはクライアント５００ａからのＵＰＤＡＴＥ（ステップＳ３９）が反映されていない、つまり、データベース１０１ａとデータベース１０１ｂは非同期状態になったことに注目すべきである。
【００６２】
次に、サーバ１００ｂが障害から復旧しシステムに組み込む（追加する）場合の動作を図１２から図２０を参照して説明する。このとき注目すべきポイントは、クライアント５００ａ及び５００ｂに対するサービスを続けたままサーバ１００ｂを追加する、つまり、システムダウンさせずにデータベース１０１ａと１０１ｂを同期させることである。
【００６３】
データベース１０１ｂはデータベース１０１ａと同期がとれていない状態、つまり、同一ではない状態である。例えば、データベース１０１ｂは、図９のステップＳ３８の障害が起きる直前のデータを保持しているかもしれないし、全く新しいサーバの場合には、データを全く持っていない状態かもしれない。本発明では、前者の場合でも古いデータは削除し、データベース１０１ｂはデータを全く保持していないものとしてシステムに組み込む。つまり、ステップＳ３８以前の古いデータを保持している必要はない。
【００６４】
ここでは、サーバ管理表２０１は図１５のようになっているとする。また、トランザクション管理表２０２と差分情報蓄積部２０３は空であるとする。
【００６５】
図１２に示すように、クライアント５００ａが172.17.1.1宛のトランザクション開始ＳＱＬ（ＢＥＧＩＮ）を含んだパケットを送信すると、仲介装置２００はそのパケットを受信する（ステップＳ６０）。サーバ制御部２１０は、トランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ａのＩＰアドレスとトランザクション番号を登録する（ステップＳ６１）。図１６にこのときのトランザクション管理表２０２を示す。サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。そして、送信キュー２０４から当該クエリを取り出し、サーバ管理表２０１を見て正常稼働しているサーバ、この場合、サーバ１００ａへ該パケットを転送する（ステップＳ６２）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。仲介装置２００は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ１００ａから受信すると（ステップＳ６３）、応答パケットをクライアント５００ａへ転送する（ステップＳ６４）。
【００６６】
ここで、サーバ１００ｂは電源を投入し起動されたものとする。これにより、サーバ１００ｂのデータベース制御部１０２ｂは、データベース同期化要求を仲介装置２００へ送信する（ステップＳ６５）。
【００６７】
データベース同期化要求を受信したサーバ制御部２１０は、トランザクション管理表２０２をチェックし現在実行中のトランザクションが存在するかどうかを確認するとともに、実行中トランザクションの情報を記録しておく（ステップＳ６６）。図１６より、クライアント５００ａ，トランザクション番号３のトランザクションが実行中なので、データベース同期化動作はこのトランザクションの終了を待つと同時に、新しいトランザクション開始要求を受け取った場合は、その要求をサーバ１００ａへ転送することを遅らせる（ステップＳ６７）。つまり、同期化動作は実行中のトランザクションが全くない状態で始める。この新規トランザクションの開始要求についての転送遅延処理は、送信キュー２０４での保留という手段で実現する。
【００６８】
次に、クライアント５００ａは、テーブルtest#tableを更新するＳＱＬ（ＵＰＤＡＴＥ）を含んだパケットを172.17.1.1へ送信する（ステップＳ６８）。サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。このクエリは前記ステップＳ６６で記憶したトランザクション情報から同期化要求時に実行していたトランザクションに属するものと判定できるので、サーバ制御部２１０は、送信キュー２０４から当該クエリを取り出し、サーバ管理表２０１を見て正常稼働しているサーバ、この場合、サーバ１００ａへ該パケットを転送する（ステップＳ６９）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。サーバ１００ａは正常にＵＰＤＡＴＥ完了したことを通知する応答パケットを仲介装置２００に送信し、仲介装置２００がこの応答パケットを受信する（ステップＳ７０）。サーバ制御部２１０は、応答パケットをクライアント５００ａへ転送する（ステップＳ７１）。
【００６９】
次に、クライアント５００ｂが172.17.1.1宛にトランザクション開始ＳＱＬ（ＢＥＧＩＮ）を含んだパケットを送信すると、仲介装置２００はそのパケットを受信する（ステップＳ７２）。サーバ制御部２１０は、このパケットによりトランザクションが開始されたことを検知し、トランザクション管理表２０２にクライアント５００ｂのＩＰアドレスとトランザクション番号を登録する（ステップＳ７３）。図１７にこのときのトランザクション管理表２０２を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー２０４に入れる。しかし、この時点では同期化処理準備のため、新規トランザクション開始クエリは送信キュー２０４に保持したままサーバ１００ａへは転送しない（ステップＳ７４）。
【００７０】
次に、クライアント５００ａは、テーブルtest#tableへの更新を確定するＳＱＬ（ＣＯＭＭＩＴ）を含んだパケットを172.11.1.1へ送信する（ステップＳ７５）。サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。このクエリは前記ステップＳ６６で記憶したトランザクション情報から同期化要求時に実行していたトランザクションに属するものと判定できるので、サーバ制御部２１０は、送信キュー２０４から当該クエリを取り出し、サーバ管理表２０１を見て正常稼働しているサーバ、この場合、サーバ１００ａのみへ該パケットを転送する（ステップＳ７６）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。サーバ１００ａは正常にＣＯＭＭＩＴ完了したことを通知する応答パケットを仲介装置２００に送信し、仲介装置２００がこの応答パケットを受信する（ステップＳ７７）。ＣＯＭＭＩＴが正常に完了したことから、トランザクションが終了したことが分かるので、サーバ制御部２１０はトランザクション管理表２０２からこのトランザクションの登録を削除する（ステップＳ７８）。この時のトランザクション管理表２０２を図１８に示す。サーバ制御部２１０は応答パケットをクライアント５００ａへ転送する（ステップＳ７９）。
【００７１】
ここで、新規サーバ１００ｂからの同期化要求時に実行していたトランザクションが全て無くなったので、サーバ制御部２１０は同期化動作を開始する（ステップＳ８０）。具体的には、図１３に示すように、まず、サーバ制御部２１０は、サーバ１００ａに対して同期化指示（スナップショット作成指示）のパケットを送信する（ステップＳ８１）。なお、前記ステップ８０において、トランザクション管理表２０２に記録されているトランザクションが同期化要求時に実行中であったものか、又は、その後にクライアント５００から受信したものかを判定するには、前記ステップＳ６６で記録しておいた同期要求時のトランザクション情報を参照すればよい。
【００７２】
同期化指示を受け取ったサーバ１００ａのデータベース制御部１０２ａは、データベース１０１ａのスナップショットを作り出す（ステップＳ８２）。ここで、このスナップショットは、同期化指示を受け取った時点でのデータベース全体のバックアップデータやデータベースを復元するための情報であり、同期化指示後の更新は反映されていないことに注目すべきである。
【００７３】
サーバ１００ａのデータベース制御部１０２ａは、スナップショット作成が完了すると（ステップＳ８３）、その旨を仲介装置２００へ通知する（ステップＳ８４）。
【００７４】
データベース制御部１０２ａは作成したスナップショットをサーバ１００ｂへ転送し、サーバ１００ｂのデータベース制御部１０２ｂは、サーバ１００ａから受信したスナップショットからデータベースを復元する（ステップＳ８５）。このスナップショットの転送とデータベースの復元は、データベース１０１ａのサイズが大きければ大きいほど時間がかかるが、クライアントからのデータベースアクセスと並行して実行されるのでクライアントに対するサービスを止めることはない。
【００７５】
スナップショット作成完了通知を受け取った仲介装置２００のサーバ制御部２１０は、クライアント５００へのサービスを再開する。この場合、処理せずに送信キュー２０４に保持していた、クライアント５００ｂからのＢＥＧＩＮを含んだパケットの処理を再開する。すなわち、サーバ制御部２１０は、転送せずに保持していたクライアント５００ｂからのＢＥＧＩＮ  ＳＱＬを含んだパケットを送信キュー２０４から取り出して差分情報蓄積部２０３に保存するとともに（ステップＳ８６）、サーバ１００ａへ転送する（ステップＳ８７）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。
【００７６】
なお、ここではステップＳ８７の処理をステップＳ８５の後に説明したが、ステップＳ８５の動作（スナップショットの転送）はクライアントへのサービスを妨げるものではないので、スナップショットの転送中にステップＳ８７や後述のステップＳ８８が行われてもよい。
【００７７】
サーバ１００ａは、トランザクションが正常に開始されたことを通知する応答パケットを仲介装置２００に送信し、仲介装置２００がこの応答パケットを受信する（ステップＳ８８）。仲介装置２００は、この応答パケットをクライアント５００ｂへ転送する（ステップＳ８９）。
【００７８】
次いで、クライアント５００ｂがテーブルtest#tableの更新ＳＱＬ（ＵＰＤＡＴＥ）のパケットを仲介装置２００に送信すると（ステップＳ９０）、サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。そして、送信キュー２０４から当該クエリを取り出し、当該クエリを差分情報蓄積部２０３に保存するとともに（ステップＳ９１）、正常稼働中のサーバ１００ａに当該パケットを送信する（ステップＳ９２）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。ここで、サーバ１００ａはＵＰＤＡＴＥに失敗し、その旨を通知する応答パケットを仲介装置２００に送信したものとする（ステップＳ９３）。仲介装置２００は、この応答パケットをクライアント５００ｂに送信する（ステップＳ９４）。
【００７９】
ＵＰＤＡＴＥ失敗の応答パケットを受信したクライアント５００ｂは、トランザクションを取り消すＳＱＬ（ＲＯＬＬＢＡＣＫ）のパケットを仲介装置に送信する（ステップＳ９５）。サーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。そして、送信キュー２０４から当該クエリを取り出し、当該ＳＱＬを差分情報蓄積部２０３に保存するとともに（ステップＳ９６）、正常稼働中のサーバ１００ａに当該パケットを送信する（ステップＳ９７）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。そして、サーバ１００ａから正常にトランザクションがＲＯＬＬＢＡＣＫされたことを通知する応答パケットを受信すると（ステップＳ９８）、トランザクション管理表２０２から当該トランザクションの登録を削除するとともに（ステップＳ９９）、この応答パケットをクライアント５００ｂに送信する（ステップＳ１００）。この時点での差分情報蓄積部２０３を図１９に示す。また、トランザクション管理表２０２は空になる。
【００８０】
ここで、サーバ１００ｂにおいてスナップショットからのデータベース１０１ｂの復元が完了したものとする（ステップＳ１０１）。サーバ１００ｂはデータベース１０１ｂの復元が完了すると差分情報転送要求を仲介装置２００に送信する（ステップＳ１０２）。仲介装置２００のサーバ制御部２１０は、差分情報転送要求を受信すると、図１４に示すように、差分情報蓄積部２０３に蓄積されているデータを古いものから順にサーバ１００ｂに転送する処理を開始する（ステップＳ１０３）。
【００８１】
前記ステップＳ１０３で差分情報蓄積部２０３に蓄積されている全てのクエリが転送・処理されることでデータベース１０１ａと１０１ｂは完全に一致した状態（同期状態）になるが、この転送処理中にクライアント５００から新たなクエリを受信する場合がある。例えば、図１４に例示するように、仲介装置２００は、クライアント５００ｂから新規トランザクションを開始するクエリ（ＢＥＧＩＮ）を受信する（ステップＳ１０４）。仲介装置２００は、当該新規トランザクションをトランザクション管理表２０２に登録する（ステップＳ１０５）。そして、当該クエリを送信キュー２０４に入れる。次いで、送信キュー２０４から当該クエリを取り出し、差分情報蓄積部２０３の最後に当該クエリを追加するとともに（ステップＳ１０６）、正常稼働中のサーバ１００ａに送信する（ステップＳ１０７）。そして、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。次いで、サーバ１００ａから応答パケットを受信すると（ステップＳ１０８）、当該応答パケットをクライアント５００ｂに転送する（ステップＳ１０９）。
【００８２】
このように差分情報転送中にクライアント５００から受信したクエリは、正常稼働中のサーバ１００で処理するとともに、差分情報蓄積部２０３に蓄積していく。この処理を継続していくと、やがて差分情報蓄積部２０３に蓄積されているクエリは全て新規サーバ１００ｂに転送され、差分情報蓄積部２０３は空になり、これを契機に差分情報転送処理が終了する（ステップＳ１１０）。これによりデータベース１０１ａと１０１ｂは完全に一致した状態（同期状態）となるので、サーバ制御部２１０は、サーバ管理表２０１にサーバ１００ｂを追加し稼働状態をａｃｔｉｖｅとすることでシステムにサーバ１００ｂを追加する（ステップＳ１１１）。この時のサーバ管理表２０１を図２０に示す。これにより、サーバ１００ｂがシステムに組み込まれた状態となるので、以降の動作は図６を参照して前述したものと同様となる。
【００８３】
この手順を繰り返せば、もともとシステムに組み込まれていたが障害等のためにシステムから切り離されたサーバであっても、新規のサーバであっても、理論的にはいくらでも追加できる。つまり、追加できるサーバ数に制限はない。
【００８４】
以上のように本実施の形態に係る多重化データベースシステムによれば、サーバ１００のデータベース１０１の記憶状況に拘わらず、サーバ１００をシステムに組み込むことができる。すなわち、元々システムに組み込まれていたが障害により切り離されたサーバ（ディスク障害によりデータを失ってしまったものなども含む）であっても、全く新規のサーバであっても同様の手順でシステムに組み込むことができる。
【００８５】
また、仲介装置２００においてデータ同期化用に差分情報蓄積部２０３に記憶する同期化用データは、これから組み込むサーバ１００からの組み込み要求を受信してから蓄積を開始するので、仲介装置２００において同期化用データが増大することがない。これにより、仲介装置２００の記憶容量を節約でき、該記憶容量が溢れることによる障害発生を未然に防止できる。また、サーバ１００の切り離しも任意に行うことができる。
【００８６】
したがって、本実施の形態に係る多重化データベースシステムでは、サーバの組み込み及び切り離しを任意に実施できるので、用途や予算などの要求に応じて柔軟なシステム設計を行うことができる。
【００８７】
本実施の形態の変形例について説明する。上記実施形態では、差分情報転送中にクライアント５００から新たなクエリを受信すると、当該クエリを差分情報蓄積部２０３に追記していた。このような処理では、差分情報の処理に時間がかかる場合や、クライアントからの受信するクエリの受信間隔が短い場合には、差分情報蓄積部２０３のデータが何時までたっても空にならなかったり空になるまで長時間要することになり、結果として新規サーバ１００ｂの組み込み処理完了まで長時間要することが考えられる。そこで、差分情報転送中に差分情報蓄積部２０３のエントリ数が所定数以下となったら、新規クエリの処理を一時保留して専ら差分情報の転送のみを行って差分情報蓄積部２０３を空にしてしまうと良い。以下、このような処理について図２１を参照して説明する。
【００８８】
ここでは、新規のサーバ１００ｂがスナップショットからデータベース１０１ｂの復元処理中であるとする（ステップＳ２００）。そして、サーバ１００ｂにおいてデータベース１０１ｂの復元処理が完了し（ステップＳ２０１）、サーバ１００ｂが仲介装置２００に差分情報転送要求を送信した時点で（ステップＳ２０２）、差分情報蓄積部２０３には所定件数以上の差分情報が蓄積されているものとする。図２１の例では、ステップＳ２０３〜ステップＳ２０７によるＵＰＤＡＴＥのクエリが最新の差分情報として差分情報蓄積部２０３に記憶されているものとする。
【００８９】
図２１に示すように、仲介装置２００のサーバ制御部２１０は、サーバ１００ｂから差分情報転送要求を受信すると、前述したように、差分情報蓄積部２０３に記憶されている各クエリを古いものから順にサーバ１００ｂに転送する処理を開始する（ステップＳ２０８）。
【００９０】
サーバ制御部２１０は、クライアント５００ｂから新たなクエリを受信したとする。図２１の例では、サーバ制御部２１０は、クライアント５００ｂからデータを追加するＳＱＬ（ＩＮＳＥＲＴ）を含むパケットを受信する（ステップＳ２０９）。差分情報転送中に新規クエリを受信したサーバ制御部２１０は、受信したクエリを送信キュー２０４に入れる。そして、送信キュー２０４から当該クエリを取り出し、差分情報蓄積部２０３に蓄積されている未転送のクエリの件数が所定件数より多い場合には、このクエリを差分情報蓄積部２０３の最後に追記するとともに（ステップＳ２１０）、正常稼働中のサーバ１００ａに該パケットを転送する（ステップＳ２１１）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。サーバ制御部２１０は、ＩＮＳＥＲＴが成功したことを示す応答パケットをサーバ１００ａから受信すると（ステップＳ２１２）、この応答パケットをクライアント５００ｂに転送する（ステップＳ２１３）。
【００９１】
ここで、仲介装置２００からサーバ１００ｂへの差分情報の転送は並行して行われており、これにより差分情報蓄積部２０３に記憶されている未転送のクエリが所定数以下となったとする。
【００９２】
サーバ制御部２１０は、クライアント５００ｂからデータを更新するＳＱＬ（ＵＰＤＡＴＥ）を含むパケットを受信すると（ステップＳ２１４）、受信したクエリを送信キュー２０４に入れる。ここでは、差分情報蓄積部２０３に蓄積されている未転送のクエリの件数が所定件数以下となっているので、この新規クエリの処理は保留する（ステップＳ２１５）。すなわち、この新規クエリの差分情報蓄積部２０３への記憶及びサーバ１００ａへの転送は行わない。この保留処理は、差分情報蓄積部２０３に記憶されているクエリを全てサーバ１００ｂに転送し、サーバ１００ｂがシステムへ組み込まれるまで継続する。
【００９３】
差分情報の転送が終了すると（ステップＳ２１６）、差分情報蓄積部２０３に蓄積されている全てのクエリが転送・処理されることでデータベース１０１ａと１０１ｂは完全に一致した状態（同期状態）になる。そこで、サーバ制御部２１０は、サーバ管理表２０１にサーバ１００ｂを追加し稼働状態をａｃｔｉｖｅとすることでシステムにサーバ１００ｂを追加する（ステップＳ２１７）。
【００９４】
ここで、サーバ制御部２１０は、前記ステップＳ２１５で保留していた新規クエリの処理を再開する。この時点では既に同期化が終了しているので、以降の処理は図６を参照して前述したものと同様となる。すなわち、サーバ制御部２１０は、当該クエリを送信キュー２０４から取り出して正常稼働中のサーバ、この場合サーバ１００ａ及び１００ｂに転送する（ステップＳ２１８，Ｓ２１９）。次いで、送信キュー２０４の送信状態を「送信完了」にして当該エントリを削除する。そして、各サーバ１００ａ及び１００ｂから受信した応答パケットを比較して障害発生の有無をチェックし（ステップＳ２２０〜Ｓ２２２）、正常な応答パケットの１つをクライアント５００ｂへ転送する（ステップＳ２２３）。
【００９５】
このような処理により、差分情報の転送中にクライアントから受信したクエリは、未転送の差分情報が所定数より多い場合には差分情報蓄積部２０３への記憶及びサーバ１００ｂへの転送が行われる。一方、未転送の差分情報が所定数以下の場合には新規クエリは保留される。これにより、差分情報の処理に時間がかかる場合やクライアントからの受信するクエリの受信間隔が短い場合であっても、データベースの同期を短時間に行うことができる。なお、閾値となる「所定件数」は、大きく設定すると新規クエリの保留時間が長くなる一方、小さく設定すると同期化処理完了までの時間が長引くことになるというトレードオフの関係にある。したがって、この「所定件数」は各装置の処理負荷やネットワーク速度などシステムの要件に応じて個々に最適な値を設定すればよい。また、本変形例において閾値を０以下に設定すれば、図１２〜図２０を参照して前述した実施例と同様の処理となる。
【００９６】
（第２の実施の形態）
本発明の第２の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第１の実施の形態と異なる点は、仲介装置から新規のサーバに転送する差分情報の内容にある。他の構成・動作等については第１の実施の形態と同様なので、ここでは相違点のみを説明する。
【００９７】
第１の実施の形態では差分情報蓄積部２０３にはクライアント５００から受信した全てのクエリを保存・転送していた。これにより、同期化処理を実施している間に正常稼働中のサーバ１００で処理されたクエリを、新規のサーバ１００においても忠実に再現することができるので、完全な同期化を図ることができる。
【００９８】
ところで、仲介装置から新規のサーバに転送する差分情報は専ら同期処理用にのみ用いられるので、該同期化において不要なクエリは転送する必要がない。具体的には、参照系クエリのＳＱＬ（ＳＥＬＥＣＴ）は不要である。なお、ここでは、ＳＥＬＥＣＴ  ＦＯＲ  ＵＰＤＡＴＥ文は、ＳＥＬＥＣＴ文の一種であるが更新処理に影響を与えるので、ここでは参照系クエリではなく更新系クエリとして取り扱うものとする。
【００９９】
そこで、本実施の形態では、第１の実施の形態と異なり、クライアント５００から受信したクエリのうち、参照系クエリを除いたものを差分情報として新規のサーバ１００に転送する。例えば、クライアント５００から図２２（ａ）に示すようなＳＱＬ文を受信したとすると、新規のサーバ１００には図２２（ｂ）に示すようなＳＱＬ文を転送してやればよい。
【０１００】
このような処理を行うため、本実施の形態に係るサーバ制御部２１０は、第１の実施の形態と同様にクライアント５００からクエリを受信した全てのクエリを差分情報蓄積部２０３に記憶する。そして、差分情報を新規サーバ１００に転送するにあたって、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外を新規サーバ１００に転送する。他の処理については第１の実施の形態と同様である。
【０１０１】
本実施の形態によれば、第１の実施の形態と比較すると、新規サーバ１００は同期化処理時において参照系クエリを処理する必要がないので同期化処理の短縮化を図ることができる。これは、複雑な参照系ＳＱＬや集合関数を含む参照系ＳＱＬなど処理負荷が大きい参照系ＳＱＬをクライアント５００が発行している場合には特に有効である。他の効果については第１の実施の形態と同様である。
【０１０２】
本実施の形態の変形例としては、サーバ制御部２１０が、同期化処理中にクライアント５００からクエリを受信し、このクエリを差分情報として差分情報蓄積部２０３に蓄積するにあたって、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外を差分情報蓄積部２０３に記憶する。そして、差分情報の転送は差分情報蓄積部２０３に記憶されている全てのクエリを対象に行う方法が挙げられる。この変形例は、差分情報蓄積部２０３の記憶容量をさらに節約できるという効果を有する。
【０１０３】
（第３の実施の形態）
本発明の第３の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第１の実施の形態と異なる点は、データベース同期化動作中における差分情報の蓄積処理にある。他の構成・動作等については第１の実施の形態と同様なので、ここでは相違点のみを説明する。
【０１０４】
第１の実施の形態では、サーバ制御部２１０は、クライアント５００から受信した全てのパケットを差分情報蓄積部２０３に保存していた。すなわち、トランザクション制御ＳＱＬ、参照系ＳＱＬ及び更新系ＳＱＬの全てのＳＱＬについて差分情報蓄積部２０３に保存し、サーバ１００には差分情報蓄積部２０３に記憶されている全てのデータを古いものから順に送信していた。
【０１０５】
一方、本実施の形態では、サーバ制御部２１０は、データベース同期化動作中にクライアント５００から受信したパケットのうち、トランザクションの開始ＳＱＬ（ＢＥＧＩＮ）や確定ＳＱＬ（ＣＯＭＭＩＴ）や取消ＳＱＬ（ＲＯＬＬＢＡＣＫ）等のトランザクション制御ＳＱＬ、及び、ＳＥＬＥＣＴなど参照系のＳＱＬについては保存せず、ＵＰＤＡＴＥやＩＮＳＥＲＴなどの更新系のＳＱＬのうち正常稼働中のサーバ１００でＣＯＭＭＩＴされたもののみを差分情報蓄積部２０３に保存する。
【０１０６】
ここで注意すべき点は、差分情報蓄積部２０３には、クライアント５００から受信した順番ではなく、正常稼働中のサーバ１００で処理された順番に更新クエリを蓄積することである。これは、更新対象が重複する更新クエリについては、その処理順序によってデータベース１０１の内容が異なってしまう可能性があるためである。
【０１０７】
このような処理を実現するために、本実施の形態では、図２３に示すような差分情報一時蓄積部２０５を新たに設けた。この差分情報一時蓄積部２０５のデータ構造は、差分情報蓄積部２０３と同様に、クライアントから受信したクエリと該クエリが属するトランザクションのＩＤとからなる。
【０１０８】
サーバ制御部２１０は、同期化処理中にクライアント５００からクエリを受信すると、更新系のもののみを順次、差分情報一時蓄積部２０５に蓄積するとともに、正常稼働中のサーバ１００に転送する。一方、更新係以外のものについては、差分情報一時蓄積部２０５に蓄積することなく正常稼働中のサーバ１００に転送する。
【０１０９】
ここで、サーバ制御部２１０は、正常稼働中のサーバ１００から更新クエリの実行が失敗したことを示す応答パケットを受信すると、当該更新クエリを差分情報一時蓄積部２０５から削除する。また、正常稼働中のサーバ１００からトランザクションのＲＯＬＬＢＡＣＫが正常に完了したことを示す応答パケットを受信すると、サーバ制御部２１０は、当該トランザクションに属する全ての更新クエリを差分情報一時蓄積部２０５から削除する。一方、正常稼働中のサーバ１００からトランザクションのＣＯＭＭＩＴが正常に終了した応答パケットを受信すると、サーバ制御部２１０は、当該トランザクションに属する更新クエリについて差分情報一時蓄積部２０５から差分情報蓄積部２０３に順次移動させる。
【０１１０】
以上のような処理により差分情報蓄積部２０３には、正常稼働中のサーバ１００でＣＯＭＭＩＴされた更新クエリのみが、その処理された順番で蓄積される。したがって、後に新規サーバ１００から差分情報転送要求があったら、差分情報蓄積部２０３に記憶されている差分情報を蓄積されている順番で新規のサーバ１００に転送すればよい。なお、新規のサーバ１００のデータベース１０１は、仲介装置２００からの更新クエリを順次処理するのみなので、この更新クエリはオートコミットモードで処理する。
【０１１１】
このように、本実施の形態によれば、同期化処理には不要の参照系クエリ、ＢＥＧＩＮやＲＯＬＬＢＡＣＫなどのトランザクション制御ＳＱＬを差分情報蓄積部２０３に蓄積することがないので、第１の実施形態と比較すると、差分情報の転送時間及びサーバでの処理時間を短縮化できる。他の効果については第１の実施の形態と同様である。
【０１１２】
なお、本実施形態では、クライアント５００から受信したクエリは、当該クエリの属するトランザクションが正常稼働中のサーバ１００でＣＯＭＭＩＴされた時点で、差分情報一時記憶部２０５から差分情報記憶部２０３へ移動されていたが、その変形例として、当該クエリが正常稼働中のサーバ１００で正常処理された時点で移動するようにしてもよい。この場合には、トランザクションがＲＯＬＬＢＡＣＫしたらら該トランザクションに属する更新クエリを差分情報記憶部２０３から削除すればよい。このような処理は、例えばＰｏｓｔｇｒｅＳＱＬのように、更新順序によって行の順番が変わるＤＢＭＳのデータベースを完全一致させるために有効である。
【０１１３】
（第４の実施の形態）
本発明の第４の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第１の実施の形態と異なる点は、差分情報蓄積部の構造にある。他の構成・動作等については第１の実施の形態と同様なので、ここでは相違点のみを説明する。
【０１１４】
本実施の形態に係る仲介装置２００は、図２５に示すように、第１の実施の形態とは異なり差分情報蓄積部２０３は設けず、送信キュー２０６に第１の実施形態における差分情報蓄積部２０３と送信キュー２０４の機能を統合させている。
【０１１５】
本実施の形態に係る送信キュー２０６のデータ構造について図２５を参照して説明する。送信キュー２０６は、クライアント５００から受信したクエリの内容と、そのクエリの属するトランザクションＩＤと、各サーバ１００への送信状態とを記憶する。トランザクションＩＤは、第１の実施の形態と同様に、トランザクション管理表２０２から取得される。各サーバ１００への送信状態は、システムに属する各サーバ１００毎に記憶される。
【０１１６】
送信キュー２０６の各サーバ１００への送信状態は、「未送信」，「送信完了」，「保留」の３つの値を取りうる。「未送信」は、クライアント５００から受信したクエリが未だ当該サーバ１００に送信されていない状態である。「送信完了」は、当該サーバ１００への送信が完了した状態である。「保留」は、新規サーバ１００のシステムへの組み込み処理中に、当該サーバ１００への転送されることなく保留されている状態である。全てのサーバ１００についての送信状態が「送信完了」になると、当該エントリは送信キュー２０６から削除される。
【０１１７】
次に、サーバ制御部２１０の動作について説明する。サーバ制御部２１０は、クライアント５００からクエリを受信すると、当該クエリがトランザクション開始ＳＱＬ（ＢＥＧＩＮ）の場合は当該トランザクションに対して新たなトランザクションＩＤを振り出してトランザクション管理表２０２に登録する。そして、当該クエリ内容，新規トランザクションＩＤ，各サーバ１００の送信状態を「未送信」で送信キュー２０６に登録する。また、クライアント５００から受信したクエリがトランザクション開始ＳＱＬ（ＢＥＧＩＮ）以外の場合は、当該クエリの属するトランザクションＩＤをトランザクション管理表２０２から取得し、当該クエリ内容，トランザクションＩＤ，各サーバ１００の送信状態を「未送信」で送信キュー２０６に登録する。
【０１１８】
サーバ制御部２１０は、送信キュー２０６に記録されているクエリを、その送信状態が「未送信」となっているサーバ１００に対して送信し、当該サーバ１００についての送信状態を「送信完了」に変更する。全てのサーバ１００について送信状態が「送信完了」になったクエリについては送信キュー２０６から削除する。
【０１１９】
仲介装置２００からクエリを受信した各サーバ１００は、当該クエリの処理を行い、応答パケットを仲介装置２００に返す。仲介装置２００のサーバ制御部２１０は、各サーバ１００から受信した応答パケットを対比して障害発生の有無を確認し、正常な応答パケットの１つをクライアント５００に返す。
【０１２０】
一方、サーバ１００から正当でない応答が仲介装置２００に返ってきたり、応答そのものが返ってこない場合には、当該サーバ１００に障害が発生したものとしてシステムから切り離す。具体的には、サーバ管理表２０１における当該サーバの稼働情報を「ｄｏｗｎ」に変更するとともに、送信キュー２０６の送信状態の欄について当該サーバに関する項目を削除する。図２６は、送信キュー２０６が図２５に示すような状態でサーバ１００ｂがシステムから切り離された場合の送信キュー２０６の一例である。
【０１２１】
次に、新規サーバ１００からシステムへの組み込み要求を受信した場合の動作について説明する。サーバ制御部２１０は、第１の実施の形態と同様に、組み込み要求受信時に実行中のトランザクションが終了するまで、新規トランザクションの開始は保留する。具体的には、クライアント５００から受信したクエリが新規トランザクションに係るものの場合には、送信状態を「保留」として送信キュー２０６に保存する。一方、クライアント５００から受信したクエリが組み込み要求時に実行中のトランザクションに係るものの場合には、送信状態を「未送信」として送信キュー２０６に保存する。図２７は、送信キュー２０６が図２６に示すような状態でクライアント５００から新たにクエリを受信した場合の送信キュー２０６の一例である。図２７の例では、三行目のトランザクションＩＤ＝３のＢＥＧＩＮを除いて上のクエリから順に（古いクエリから順に）、トランザクションＩＤ＝２のＳＥＬＥＣＴ，トランザクションＩＤ＝１のＣＯＭＭＩＴ，トランザクションＩＤ＝２のＣＯＭＭＩＴの順に正常稼働中のサーバ１００ａへ転送され、その送信状態が「未送信」から「送信完了」に変更される。トランザクションＩＤ＝３のＢＥＧＩＮは、新規のサーバ１００ｂからスナップショット作成完了通知を受けた後に転送されることになる。
【０１２２】
そして、組み込み要求受信時に実行中のトランザクションに係るクエリを全て正常稼働中のサーバ１００に送信し終えると、サーバ制御部２１０は、送信キュー２０６に組み込み対象である新規のサーバ１００の項目を追加する。ここで、送信キュー２０６には送信状態が「保留」となっているクエリが記憶されている場合がある。この場合、サーバ制御部２１０は、送信キュー２０６に記憶されているクエリーに対して、新規サーバ１００についての送信状態を「保留」とする。図２８は、図２７の送信キュー２０６に対して新規サーバ１００ｂの登録をした場合を示している。また、サーバ制御部２１０は、組み込み要求受信時に実行中のトランザクションに係るクエリを全て正常稼働中のサーバ１００に送信し終えると、第１の実施の形態と同様に、正常稼働中のサーバ１００に対してスナップショットの作成指示を送出する。
【０１２３】
サーバ制御部２１０は、正常稼働中のサーバ１００からスナップショット作成完了通知を受信すると、正常稼働中のサーバ１００へのクエリの送信を再開する。具体的には、まず送信キュー２０６に記憶されている全てのクエリ（この時点では全てのクエリの送信状態は全てのサーバ１００について「保留」になっている）について、正常稼働中のサーバ１００の送信状態を「未送信」に変更する。そして、サーバ制御部２１０は、送信状態が「未送信」のクエリを当該サーバ１００に順次送信し、送信が完了したら送信状態を「送信完了」に修正する。また、新たにクライアント５００から受信したクエリは、正常稼働中のサーバ１００についての送信状態は「未送信」、新規のサーバ１００についての送信状態は「保留」にして送信キュー２０６に記憶する。図２９は、図２８の送信キュー２０６に対してスナップショット完了通知受信後に新たなクエリを受信した場合を示している。また、図３０のように、正常稼働中のサーバ１００ａに対しては「送信完了」となっても新規のサーバ１００ｂに対しては「送信完了」になっていない（「保留」になっている）ので、送信キュー２０６から当該クエリは削除しない。
【０１２４】
新規のサーバ１００が正常稼働中のサーバ１００から受信したスナップショットを用いてデータベース１０１の復元が完了すると、サーバ制御部２１０は新規のサーバ１００から差分情報転送要求を受信する。サーバ制御部２１０は、送信キュー２０６に記憶されているクエリであって、送信状態が「保留」となっているものを当該「保留」となっていたサーバ１００、すなわち新規のサーバ１００に古いものから順次送信する。送信したクエリについては、送信キュー２０６における当該サーバ１００の送信状態を「送信完了」にし、全てのサーバ１００についての送信状態が「送信完了」になったら当該エントリは削除する。
【０１２５】
サーバ制御部２１０は、送信状態が「保留」となっているクエリが送信キュー２０６に存在しなくなると、サーバ管理表２０１に新規のサーバ１００を「ａｃｔｉｖｅ」として追加することで、当該サーバ１００をシステムに組み込む。以降の動作は各サーバ１００が正常動作している場合のものと同様になる。
【０１２６】
以上のように本実施の形態に係る仲介装置２００では、第１の実施の形態における差分情報蓄積部２０３と送信キュー２０４の機能を、１つの送信キュー２０６に統合しているので、メモリの利用効率や処理効率が向上する。また、送信キュー２０６の各クエリに対して、各サーバ１００への送信状態を記憶するようにしているので、新規サーバ１００を組み込む際には当該サーバ１００の送信状態を追加すればよい。これにより、一度に複数台のサーバ１００をシステムに組み込むことができる。他の作用効果については第１の実施の形態と同様である。
【０１２７】
なお、本実施の形態は、第１の実施の形態の変形例として説明したが、上記第２〜第３の実施の形態において同様の変形を適用できることは言うまでもない。
【０１２８】
（第５の実施の形態）
本発明の第５の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第４の実施の形態と異なる点は、差分情報の蓄積方法にある。他の構成・動作等については第４の実施の形態と同様なので、ここでは相違点のみを説明する。
【０１２９】
上述の第１の〜第４の実施の形態では、仲介装置２００が正常稼働中のサーバ１００にスナップショットの作成指示を送信するタイミングは、正常稼働中のサーバ１００において実行中のトランザクションが無くなったときである。具体的には、新規サーバ１００からの組込要求を受信した時点で実行中のトランザクションについて正常稼働中のサーバ１００で処理を行うのと並行して、組込要求受信時以降にクライアント５００から受信した新規トランザクションの開始要求を保留していた。そして、組込要求を受信した時に実行中のトランザクションが無くなった時点で、スナップショットの作成指示を送信している。これは、ＤＢＭＳによっては、スナップショット作成時にトランザクションが実行中だと、そのトランザクションに属する更新クエリによるデータ更新がスナップショットに反映されるか否かが不確定となる場合を考慮したためである。
【０１３０】
一方、本実施の形態では、サーバ１００として、スナップショット作成時に実行中のトランザクションに属する更新クエリ及びスナップショット作成処理中に受信した更新クエリについては、当該スナップショットには反映しないという動作を行うものを用いる。これにより、本実施の形態に係る仲介装置２００のサーバ制御部２１０は、組込要求受信時に実行中のトランザクションの終了を待つことなく、スナップショット作成指示の送信及び新規トランザクションの開始を行うことができる。なお、仲介装置２００がスナップショット作成完了を待つ必要がないので、サーバ１００のデータベース制御部１０２は、スナップショット作成が完了しても仲介装置２００には完了通知を送信する必要はない。
【０１３１】
このような処理を行うため、本実施の形態に係る仲介装置２００のサーバ制御部２１０は、送信キュー２０６に記憶されている各クエリについて、全てのサーバ１００について送信状態が「送信完了」となり、且つ、当該クエリに属するトランザクションが終了した場合に、当該クエリの登録を削除する。
【０１３２】
以下、新規サーバ１００をシステムに組み込む際の動作について図３１〜図３５を参照して説明する。いま、システムにはサーバ１００ａのみが組み込まれており、これから新たにサーバ１００ｂを組み込むものとする。
【０１３３】
サーバ制御部２１０は、新規サーバ１００ｂから組込要求を受信すると、正常稼働中のサーバ１００ａに対して同期化指示（スナップショット作成指示）を送信する。新規サーバ１００ｂが仲介装置２００に対して組込要求を送信した際の送信キュー２０６の一例を図３１に示す。前述したように、送信キュー２０６に記憶されたクエリは、当該クエリが送信完了しても該クエリの属するトランザクションが完了していないものは削除されずに残っている。同期化指示を受信したサーバ１００ａは、スナップショットの作成を開始する。ここで作成されるスナップショットは、送信キュー２０６に記憶されているクエリは反映されていないものである。また、サーバ制御部２１０は、新規サーバ１００ｂから組込要求を受信すると、送信キュー２０６に記憶されている全てのクエリについて、当該新規サーバ１００ｂの送信状態を「保留」にして追加する。この時の、送信キュー２０６の一例を図３２に示す。
【０１３４】
サーバ制御部２１０は、組込要求受信時以降にクライアント５００からクエリを受信すると、正常稼働中のサーバ１００ａについては送信状態を「未送信」、新規サーバ１００ｂについては送信状態を「保留」にして送信キュー２０６に順次追加する。そして、送信状態が「未送信」となっているクエリについては当該「未送信」のサーバ１００ａに対して順次転送し、送信状態を「送信完了」に変更していく。このとき、図３３に示すように、送信キュー２０６に記憶されているクエリは、正常稼働中のサーバ１００ａについてはトランザクション単位で送信状態が「送信完了」となっているが、新規サーバ１００ｂについては「保留」となっているので、ここではクエリの削除は行わない。
【０１３５】
一方、仲介装置２００からスナップショットの作成指示を受信したサーバ１００ａは、作成したスナップショットを新規のサーバ１００ｂに送信する。新規のサーバ１００ｂのデータベース制御部１０２ｂは、受信したスナップショットからデータベース１０１ｂを復元し、仲介装置２００に差分情報転送要求を送信する。
【０１３６】
差分情報転送要求を受信したサーバ制御部２１０は、送信キュー２０６に記憶されている送信状態が「保留」となっているクエリを差分情報として順次新規サーバ１００ｂに送信し、図３４に示すように、送信状態を「送信完了」に変更する。そして、前述したように、全てのサーバについて送信状態が「送信完了」となり、且つ、当該クエリのトランザクションが完了したら、そのクエリを削除する。以降、送信状態が「保留」のクエリの中の送信中にクライアント５００からクエリを受信すると、図３５に示すように、正常稼働中のサーバ１００ａ及び新規サーバ１００ｂの双方の送信状態を「未送信」で送信キュー２０６へ記憶する。そして、送信状態が「保留」のクエリが無くなった時点でデータベース１００ａとデータベース１００ｂの同期が完了したことになる。
【０１３７】
本実施形態によれば、システムで用いるサーバ１００の機能的要件が限定されるためサーバ選択の幅が狭くなるものの、仲介装置２００での処理が簡略化されるので処理効率の高いものとなる。
【０１３８】
なお、本実施の形態では、サーバ１００として、（１）トランザクション実行中でもスナップショットの作成開始ができ、（２）スナップショット作成中にクエリを処理可能であり且つ当該クエリがスナップショットに反映されないものを用いたが、（１’）トランザクション実行中でもスナップショットの作成開始ができるが、（２’）スナップショット作成中にはクエリを処理できない又はスナップショット作成中にクエリを処理すると当該処理がスナップショットに反映される場合があるようなサーバ１００を用いることもできる。
【０１３９】
ただし、この場合には、新規サーバ１００から組込要求を受信すると直ちに正常稼働中のサーバ１００に対してスナップショット作成指示を送信してよいが、スナップショット作成完了までは正常稼働中のサーバ１００に対するクエリの送信を保留する必要がある。この保留処理の具体的な方法は上記第１の実施の形態と同様であるのでここでは説明は省略する。また、仲介装置２００がスナップショットの作成完了を認識するために、スナップショットの作成が完了したサーバ１００は、スナップショット作成完了を仲介装置２００に通知する必要がある。これにより、本実施の形態よりもサーバ選択の幅が広いものとなる。
【０１４０】
以上、本発明の実施形態について詳述したが、上記実施の形態は例示的なものであり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれるものである。
【０１４１】
例えば、各サーバは要求に応じて同じ応答をするならば同じ実装である必要はない。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラオプション、ハードウェアかソフトウェアか、などが異なっていてもよい。サーバには、ＰｏｓｔｇｒｅＳＱＬなどのフリーソフトウェアやＯｒａｃｌｅなどの市販のソフトウェア、独自開発のソフトウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サーバ１００ａはＰｏｓｔｇｒｅＳＱＬでサーバ１００ｂはＯｒａｃｌｅでも良い。
【０１４２】
ＤＢＭＳとしては、市中品（例えば、ＯｒａｃｌｅやＰｏｓｔｇｒｅＳＱＬ）を使う場合は、データベース制御部１０２は、データベース管理部とデータベースサーバ管理部に機能を分けることによって、市中品を無改造で使うことができる。データベース管理部は、データベース１０１を直接操作するもので、例えばＰｏｓｔｇｒｅＳＱＬの場合はｐｏｓｔｍａｓｔｅｒやｐｏｓｔｇｒｅｓに相当する。データベースサーバ管理部は、仲介装置２００とデータベース管理部の間に介在し、クエリの送受信を中継したりするほかに、他のサーバを同期化する際のデータベース１０１のスナップショットを作成したり、そのスナップショットを他のサーバへ転送したりする処理を行う。
【０１４３】
スナップショットの作成方法は、例えばＤＢＭＳがＰｏｓｔｇｒｅＳＱＬならばｐｇ＿ｄｕｍｐなどのダンプツールやバックアップツールを使って実現する。なお、ｐｇ＿ｄｕｍｐはＰｏｓｔｇｒｅＳＱＬサーバ同士を同期化する場合には有用だが、異種のＤＢＭＳ同士（例えばＰｏｓｔｇｒｅＳＱＬとＯｒａｃｌｅ）を同期化する場合には、ＤＢＭＳ固有のツールは使わずに、正常稼働中のＤＢＭＳサーバからＳＥＬＥＣＴクエリで全てのデータを取りだしＩＮＳＥＲＴクエリでデータを入れる汎用のツールを使えばよい。
【０１４４】
また、上記実施の形態では、システムへの組み込み要求（新規サーバのデータベース同期化要求）は当該新規サーバ１００のデータベース制御部１０２が仲介装置２００へ送信しているが、保守端末などの他の装置から送信してもよいし、オペレータが仲介装置２００に直接指示しても良い。
【０１４５】
さらに、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが、ハードウェアで実装しても良い。
【０１４６】
また、上記実施の形態では、仮想サーバ８００を構成する仲介装置２００は１台のみであったが、複数台設けて冗長性を持たせることにより、より可用性の高い構成とすることも可能である。仲介装置を多重化させる技術については、例えば本願出願人による特開２００３−３４５６７９号公報に記載されたものなどを用いればよい。
【図面の簡単な説明】
【０１４７】
【図１】第１の実施形態に係る多重化データベースシステムの構成図
【図２】第１の実施形態に係るサーバ管理表の一例を示す図
【図３】第１の実施形態に係るトランザクション管理表の一例を示す図
【図４】第１の実施形態に係る差分情報蓄積部の一例を示す図
【図５】第１の実施形態に係る送信キューの一例を示す図
【図６】各サーバが正常稼働している場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図７】図５の動作におけるサーバ管理表の一例
【図８】図５の動作におけるトランザクション管理表の一例
【図９】サーバが故障した場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１０】図８の動作におけるトランザクション管理表の一例
【図１１】図８の動作におけるサーバ管理表の一例
【図１２】新規にサーバを組み込む場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１３】新規にサーバを組み込む場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１４】新規にサーバを組み込む場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図１５】図１１及び図１２の動作におけるサーバ管理表の一例
【図１６】図１１及び図１２の動作におけるトランザクション管理表の一例
【図１７】図１１及び図１２の動作におけるトランザクション管理表の一例
【図１８】図１１及び図１２の動作におけるトランザクション管理表の一例
【図１９】図１１及び図１２の動作における差分情報蓄積部の一例
【図２０】図１１及び図１２の動作におけるサーバ管理表の一例
【図２１】新規にサーバを組み込む場合の多重化データベースシステムの動作を説明するシーケンスチャート
【図２２】第２の実施形態においてクライアントから受信したクエリと差分情報として送出するクエリの関係を説明する図
【図２３】第３の実施形態に係る差分情報蓄積部の一例
【図２４】第４の実施形態に係る仲介装置の構成図
【図２５】第４の実施形態に係る送信キューの一例を示す図
【図２６】第４の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図２７】第４の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図２８】第４の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図２９】第４の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図３０】第４の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図３１】第５の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図３２】第５の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図３３】第５の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図３４】第５の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図３５】第５の実施形態に係る多重化データベースシステムの動作中の送信キューの一例
【図３６】従来のデータベース同期化システムの構成図
【符号の説明】
【０１４８】
１００…サーバ、１０１…データベース、１０２…データベース制御部、２００…仲介装置、２０１…サーバ管理表、２０２…トランザクション管理表、２０３…差分情報蓄積部、２０４，２０６…送信キュー、２０５…差分情報一時蓄積部、２１０…サーバ制御部、３００，４００…ネットワーク、５００…クライアント。
【図１】
2007241322.tif 000003
【図２】
2007241322.tif 000004
【図３】
2007241322.tif 000005
【図４】
2007241322.tif 000006
【図５】
2007241322.tif 000007
【図６】
2007241322.tif 000008
【図７】
2007241322.tif 000009
【図８】
2007241322.tif 000010
【図９】
2007241322.tif 000011
【図１０】
2007241322.tif 000012
【図１１】
2007241322.tif 000013
【図１２】
2007241322.tif 000014
【図１３】
2007241322.tif 000015
【図１４】
2007241322.tif 000016
【図１５】
2007241322.tif 000017
【図１６】
2007241322.tif 000018
【図１７】
2007241322.tif 000019
【図１８】
2007241322.tif 000020
【図１９】
2007241322.tif 000021
【図２０】
2007241322.tif 000022
【図２１】
2007241322.tif 000023
【図２２】
2007241322.tif 000024
【図２３】
2007241322.tif 000025
【図２４】
2007241322.tif 000026
【図２５】
2007241322.tif 000027
【図２６】
2007241322.tif 000028
【図２７】
2007241322.tif 000029
【図２８】
2007241322.tif 000030
【図２９】
2007241322.tif 000031
【図３０】
2007241322.tif 000032
【図３１】
2007241322.tif 000033
【図３２】
2007241322.tif 000034
【図３３】
2007241322.tif 000035
【図３４】
2007241322.tif 000036
【図３５】
2007241322.tif 000037
【図３６】
2007241322.tif 000038