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