JP2007156916A - データ制御装置、システム、方法、及びプログラム - Google Patents

Abstract

【課題】データの同期維持に関する性能及び信頼性の面でのボトルネックがないデータ制御装置を提供する。
【解決手段】データの同期が維持されるべき複数のデータベースをそれぞれ制御する複数のデータ制御装置の一つに備えられる統合制御部１００は、クライアントから発行された第１アクセス要求について前記複数のデータベース間でのデータの同期制御が必要か否かを判断する要求判断部１１０と、不要と判断された場合、自らのデータベースへ前記第１アクセス要求を発行する単独アクセス部１２０と、必要と判断された場合、他の全てのデータ制御装置を占有し、前記第１アクセス要求を他の全てのデータ制御装置へ転送すると共に自らのデータベースへ発行する連携マスタ部１３０と、他のデータ制御装置から転送された第２アクセス要求を自らのデータベースへ発行する連携サービス部１５０とを備える。
【選択図】図３

Description

データの同期が維持されるべき複数のデータベースをそれぞれ制御する複数のデータ制御装置の一つ、及び前記複数のデータ制御装置から構成されるデータ制御システム等に関し、特にデータの同期を維持するための技術に関する。

従来、分散データベースシステムの構成の一例として２階層構成が広く知られている。２階層構成を採る分散データベースシステムは、典型的には、複数のデータベースをそれぞれ制御する複数のバックエンドサーバと、クライアントからのアクセス要求を前記バックエンドサーバの一つへ転送する一つ以上のフロントエンドサーバと、前記複数のデータベース間でのデータの同期を維持管理するレプリケーションサーバとから構成される。

そのようなデータベースシステムを実現するためのコンピュータソフトウェアの一つにＰＧＣｌｕｓｔｅｒがある（例えば非特許文献１を参照）。

図２４は、ＰＧＣｌｕｓｔｅｒを用いて実現される分散データベースシステム９の機器構成の一例を示すブロック図である。分散データベースシステム９は、フロントエンドサーバ９１、９２、バックエンドサーバ６１、６２、６３、データベース６６、６７、６８、レプリケーションサーバ７１、及びネットワーク８０から構成される。なお、データベース６６、６７、６８は、バックエンドサーバ６１、６２、６３によって制御され、バックエンドサーバ６１、６２、６３にそれぞれ含まれるとしてもよい。

フロントエンドサーバ９１、９２は、二重化されていて、何れか一方が動作し、図示しないクライアントから発行されたアクセス要求を、例えばアクセス負荷の分散を図って、バックエンドサーバ６１、６２、６３の一つへ転送する。

バックエンドサーバ６１、６２、６３は、それぞれ並列に動作し、フロントエンドサーバ９１、９２からアクセス要求を受信すると、そのアクセス要求についてデータベース間でのデータの同期制御が必要か否かを判断する。この判断は、例えば、そのアクセス要求がデータの参照のみに関するものか、データの追加、更新、又は削除に関するものかによって行われる。

そして、不要と判断されると、そのアクセス要求を自らのデータベースのみで実行し、アクセス要求を発行したクライアントへフロントエンドサーバを介して実行結果を返却する。必要と判断されると、そのアクセス要求をレプリケーションサーバ７１へ転送する。

レプリケーションサーバ７１は、アクセス要求を受信すると、そのアクセス要求をバックエンドサーバ６１、６２、６３へ送信する。バックエンドサーバ６１、６２、６３は、レプリケーションサーバ７１からアクセス要求を受信すると、そのアクセス要求を自らのデータベースでそれぞれ実行し、実行結果をレプリケーションサーバ７１へ返却する。レプリケーションサーバ７１は、全てのバックエンドサーバから実行結果を受信すると、アクセス要求を転送したバックエンドサーバへその実行結果を送信する。実行結果を受信したバックエンドサーバは、アクセス要求を発行したクライアントへフロントエンドサーバを介してその実行結果を返却する。

この構成によれば、データの同期（ここでは特に、データ内容の一致を意味する）を維持するために全てのバックエンドサーバで実行されるべきアクセス要求の実行順序が、レプリケーションサーバ７１ただ一箇所で管理される。レプリケーションサーバ７１は、例えば図示しないデータキューを用いて、バックエンドサーバ６１、６２、６３から受信したアクセス要求をそのデータキューに受信順に蓄積すると共に、蓄積順にアクセス要求を取り出して全てのバックエンドサーバへ送信することによって、アクセス要求の実行順序の管理を行う。

その結果、全てのバックエンドサーバにおいて、レプリケーションサーバ７１によって管理される順序でアクセス要求が実行されるので、バックエンドサーバ間に実行順序の違いによる実行結果の不一致が生じることがなく、全てのデータベースでデータの同期が維持される。

このようにして、従来のデータベースシステムは、アクセス負荷の分散とデータの同期の維持とを達成している。
ＰＧＣｌｕｓｔｅｒのＷＥＢページ、http://pgcluster.projects.postgresql.org/jp/

しかしながら、従来のデータベースシステムには、次のような問題がある。
第１に、アクセス要求の実行順序を管理するための負荷が一つのレプリケーションサーバに集中するという問題がある。この問題のため、システム全体の性能に見合う高価で高性能なレプリケーションサーバを導入するか、システム全体の性能をレプリケーションサーバの性能に見合うよう制限することを余儀なくされる。すなわち、システムのスケーラビリティの実現が困難となる。

第２に、レプリケーションサーバが故障した場合、データの同期が失われるという問題がある。この問題を回避すべく、例えば、レプリケーションサーバを二重化するか、レプリケーションサーバの故障中には唯一の代表データベースを更新することが考えられるが、前者の場合、システムがさらに高価にならざるを得ず、また後者の場合、復旧時にその代表データベースの内容を他のデータベースに複写することによってデータの同期を回復するという煩雑な処理が必要になる。

本発明は、上記の問題に鑑みてなされたものであり、データの同期維持に関する性能及び信頼性の面でのボトルネックがなく、またデータの同期を一時的に停止した後、迅速に回復可能なデータ制御装置、及びデータ制御システムを提供することを目的とする。

上記課題を解決するため、本発明のデータ制御装置は、データの同期が維持されるべき複数のデータベースをそれぞれ制御する複数のデータ制御装置の一つであって、クライアントから発行された第１のアクセス要求を受信すると、前記第１のアクセス要求について前記複数のデータベース間でのデータの同期制御が必要か否かを判断する要求判断手段と、不要と判断された場合、自らのデータベースに対して前記第１のアクセス要求を発行する単独アクセス手段と、必要と判断された場合、他の全てのデータ制御装置の占有を試み、前記占有に成功した場合、他の全てのデータ制御装置へ前記第１のアクセス要求を転送すると共に、自らのデータベースに対して前記第１のアクセス要求を発行する連携マスタ手段と、他のデータ制御装置から転送された第２のアクセス要求を受信すると、自らのデータベースに対して前記第２のアクセス要求を発行する連携サービス手段とを備える。

また、前記データ制御装置は、さらに、自らを占有しているデータ制御装置を示す占有受付情報を保持している占有受付レジスタを備え、前記連携マスタ手段は、自データ制御装置を示すように前記占有受付情報を更新した後、他の全てのデータ制御装置へ自データ制御装置を識別する第１の占有要求を送信することによって前記占有を試み、他の全てのデータ制御装置から占有受諾応答が受信された場合に前記占有に成功したと判断し、前記連携サービス手段は、他のデータ制御装置を識別する第２の占有要求を受信したとき、前記占有受付情報がどのデータ制御装置からも占有されていないことを示す場合、前記第２の占有要求によって識別されるデータ制御装置を示すように前記占有受付情報を更新すると共に占有受諾応答を返信し、その他の場合、占有拒否応答を返信してもよい。

この構成によれば、複数のデータベース間でのデータの同期制御が必要となるアクセス要求は、他の全てのデータ制御装置の占有に成功してから初めて実行されるため、そのアクセス要求は全てのデータ制御装置で確実に実行される。また、前記占有受付情報が占有状態を表す間は、新たな占有要求は拒否されるため、複数のアクセス要求がデータ制御装置ごとに異なる順序で実行される事態が避けられる。その結果、データ制御装置間に実行順序の違いによる実行結果の不一致が生じることがなく、全てのデータベースでデータの同期が維持される。

このように、データの同期の維持そのものが分散処理されることで、従来のレプリケーションサーバを省略できる。これにより、データの同期維持に関する性能及び信頼性の面でのボトルネックがシステムから排除され、システムのスケーラビリティの具現化が容易となる。

また、前記データ制御装置によって受信される占有拒否応答は、前記占有拒否応答を送信したデータ制御装置において継続中の占有を識別し、前記占有受付レジスタは、さらに、自データ制御装置を含む全てのデータ制御装置に共通して直前に受け入れられた占有を識別する直前占有情報を保持し、前記連携マスタ手段は、前記第１の占有要求に対して占有拒否応答が受信された場合、前記受信された占有拒否応答によって識別される占有が前記直前占有情報によって識別される占有と同一であれば、前記占有拒否応答を送信したデータ制御装置へ前記第１の占有要求を再送信してもよい。

この構成によれば、自データ制御装置において直前に処理されたアクセスが先方のデータ制御装置においてまだ処理中であるために新たな占有要求が拒否された場合に、直ちに占有失敗とせず占有要求をリトライすることが可能となる。これにより、データ制御装置間での処理タイミングの差異が吸収され、システムのスループットが向上する。

また、前記データ制御装置によって受信される占有拒否応答は、前記占有拒否応答を送信したデータ制御装置を占有しているデータ制御装置を示すと共に、前記複数のデータ制御装置には優先順位が定められており、前記連携マスタ手段は、前記第１の占有要求に対して占有拒否応答が受信された場合、前記受信された占有拒否応答によって示されるデータ制御装置である競合データ制御装置の優先順位と自データ制御装置の優先順位との比較に基づいて、占有の変更先となるべき優先データ制御装置を特定し、自データ制御装置から前記特定された優先データ制御装置への変更を示す第１の占有変更を送信すると共に、前記優先データ制御装置を示すように前記占有受付情報を更新し、前記連携サービス手段は、第２の占有変更を受信すると、前記第２の占有変更によって示される変更前のデータ制御装置と前記占有受付情報によって示されるデータ制御装置とが一致する場合、前記第２の占有変更によって示される変更後のデータ制御装置を示すように前記占有受付情報を更新すると共に、前記変更後のデータ制御装置へ占有受諾応答を送信してもよい。

この構成によれば、競合データ制御装置が存在することを知ったデータ制御装置は、自らの占有を優先順位がより高い競合データ制御装置へと積極的に明け渡すことができるので、競合の解消を、例えば所定時間待ってリトライするといった簡略な方法に比べて、より迅速かつ円滑に行うことができる。

また、前記連携マスタ手段は、前記第１の占有要求に対して他の全てのデータ制御装置から占有許諾応答又は占有拒否応答が受信された後、自データ制御装置及び前記各競合データ制御装置がそれぞれ自分以外のデータ制御装置を占有しているか否かを、受信された占有許諾応答又は占有拒否応答に基づいて判断し、自分以外のデータ制御装置を占有していない状態の前記複数のデータ制御装置を前記優先順位で並べ、さらにその高位に、自分以外のデータ制御装置を占有している状態の前記複数のデータ制御装置を並べて定義される順位に従って、自データ制御装置よりも高位の競合データ制御装置を前記優先データ制御装置として特定してもよい。

この構成によれば、自分以外のデータ制御装置を占有している状態のデータ制御装置の占有変更先としての優先順位を、そうでない状態のデータ制御装置よりも高めることによって、占有に成功する可能性が高いデータ制御装置へ優先的に占有を変更するので、競合の解消をより少ない手間で行うことができる。

また、前記連携マスタ手段は、自らの占有を前記優先データ制御装置へ変更した後、変更前の自らの占有を再度試みてもよい。

この構成によれば、占有変更が行われた場合に、占有に失敗したことを直ちにクライアントへ通知するのではなく、変更前の自らの占有をデータ制御装置自身が再試行することができるので、クライアントの処理を軽減できる。

また、前記連携マスタ手段、及び前記連携サービス手段は、送信されるデータの多寡、再送信か否か、送信されるデータが応答か否かのうちの少なくとも一つに応じて、他のデータ制御装置との通信に用いる通信プロトコルを変更してもよい。

この構成によれば、前記の条件の少なくとも一つに応じて、例えばＴＣＰプロトコルとＵＤＰプロトコルとを切り替えることによって、通信のオーバヘッドと信頼性との良好なトレードオフを図ることができる。

また、前記データ制御装置は、さらに、データ受信の有無を所定時間監視することによって他のデータ制御装置の故障を検出するサーバ状態管理手段を備え、前記連携マスタ手段は、故障と検出されたデータ制御装置を除外して、前記占有の成否を判断してもよい。

この構成によれば、故障したデータ制御装置が自動的にシステムから切り離されるので、一つのデータ制御装置の故障がシステム全体に及ぼす影響が軽減され、サービス無中断の運用が可能となる。

また、前記データ制御装置は、さらに、特定の動作モードにおいて一つ以上のアクセス要求を蓄積し、前記動作モードが解除されるとき、前記アクセス要求を蓄積された順に取り出して自らのデータベースに対して発行する保留制御手段を備え、前記連携サービス手段は、前記動作モードにおいて、前記第２のアクセス要求を自らのデータベースに対して発行する代わりに前記保留制御手段に蓄積してもよい。

この構成によれば、前記データ制御装置は、前記動作モードにおいては、データの同期の維持に関する処理を通常に実行しながら、前記第２のアクセス要求を蓄積するので、一つ以上のアクセス要求をデータの同期維持に必要な実行順序どおりに蓄積することが可能である。

前記動作モードが解除される際には、そのように蓄積された一つ以上のアクセス要求を単に蓄積された順に実行することによって、迅速にデータの同期を回復できる。そして、データの同期回復のために他のデータベースからデータを複写する必要がないため、データベースの規模が大きいほど、データの同期回復の迅速化に大きな効果が得られる。

これにより、例えばデータベースのメンテナンスを行うためにデータの更新を一時的に保留しその後回復するような場合に、極めて高い実用的価値が発揮される。

また、前記データ制御装置は、前記複数のデータ制御装置のみを接続する専用ネットワークへの接続手段を備えてもよい。

この構成によれば、データの同期維持に関する通信トラフィックを前記専用ネットワークに分離できるので、フロントエンドサーバやクライアントとの接続に用いられるネットワークの負荷の軽減に役立つ。

また、本発明は、前述したようなデータ制御装置として実現できるだけでなく、複数のデータベースについてそれぞれ前記データ制御装置を備えるデータ制御システムとして実現することもできる。また、前記データ制御装置が備える特徴的な手段によって実行される処理をステップとするデータ制御方法として実現することも、さらにはコンピュータプログラムとして実現することもできる。

本発明のデータ制御装置によれば、データの同期の維持そのものが分散処理されるので、従来のレプリケーションサーバを省略できる。これにより、システムからデータの同期維持に関する性能及び信頼性の面でのボトルネックとなるレプリケーションサーバが排除され、システムのスケーラビリティの具現化が容易となる。

また、故障したデータ制御装置を自動的にシステムから切り離し、一つのデータ制御装置の故障がシステム全体に及ぼす影響を軽減することも可能となる。

（第１の実施の形態）
本発明の第１の実施の形態におけるデータ制御装置及びデータ制御システムについて、図面を参照しながら詳細に説明する。

（全体構成）
図１は、本発明の第１の実施の形態におけるデータ制御システム１０を含む分散データベースシステムの一例を示す機器構成図である。分散データベースシステム１は、背景技術の項で説明した２階層構成による典型的な分散データベースシステムから、レプリケーションサーバを省いて構成される。図１には、データ制御システム１０と共に、フロントエンドサーバ４１、４２、…、４ｍ、ネットワーク２０、データベース３１、３２、…、３ｎが示される。

データ制御システム１０は、データベース３１、３２、…、３ｎへのアクセスを制御すると共に、データの同期を維持管理するシステムであって、バックエンドサーバ１１、１２、…、１ｎから構成される。ここで、バックエンドサーバ１１、１２、…、１ｎが、請求項に言うデータ制御装置の一例である。

フロントエンドサーバ４１、４２、…、４ｍは、独立して並列に動作し、図示しないクライアントから発行されたアクセス要求をバックエンドサーバ１１、１２、…、１ｎの一つへ、例えば負荷分散を図って、転送するサーバ機能であり、例えばそれぞれ独立したコンピュータシステムを用いて実現される。このアクセス要求は、一例としてＳＱＬ（Structured Query Language）で記述されていてもよい。

バックエンドサーバ１１、１２、…、１ｎは、並列に動作し、フロントエンドサーバ４１、４２、…、４ｍからアクセス要求を受信すると、データの同期が維持されるように連携してデータベース３１、３２、…、３ｎへのアクセス処理を行うサーバ機能であり、例えばそれぞれ独立したコンピュータシステムを用いて実現される。

ここで、バックエンドサーバ１１、１２、…、１ｎには、固有のサーバＩＤと優先順位とが定められていて、バックエンドサーバ１１、１２、…、１ｎは、各バックエンドサーバのサーバＩＤと優先順位とを予め知っているものとする。

データベース３１、３２、…、３ｎは、独立して並列に動作し、アクセス要求に応じてデータを蓄積し、操作し、出力する一般的なデータベース機能であり、例えばそれぞれ独立したコンピュータシステムを用いて実現されるか、バックエンドサーバ１１、１２、…、１ｎと同一のコンピュータシステムを用いて実現される。データベース３１、３２、…、３ｎが、それぞれバックエンドサーバ１１、１２、…、１ｎの一部分として実現される場合も、本発明に含まれる。

バックエンドサーバ１２、…、１ｎはバックエンドサーバ１１と同様であり、またデータベース３２、…、３ｎはデータベース３１と同様である。以下、バックエンドサーバ１１とデータベース３１とについて代表して説明する。

（バックエンドサーバ）
図２は、バックエンドサーバ１１の機能的な構成の一例を示すブロック図である。図２には、バックエンドサーバ１１と共に、データベース３１が示される。

バックエンドサーバ１１は、統合制御部１００、ネットワークアダプタ部２００、フロントエンド通信制御部２１０、バックエンド通信制御部２２０、及びタイマ部４００から構成される。

ネットワークアダプタ部２００は、ネットワーク２０に物理的に接続し、フロントエンド通信制御部２１０は、ネットワークアダプタ部２００を介してフロントエンドサーバ４１、４２、…、４ｍとの通信を実行し、バックエンド通信制御部２２０は、ネットワークアダプタ部２００を介してバックエンドサーバ１２、…、１ｎとの通信を実行する。この通信は、例えば、ＩＰ（Internet Protocol）上のＴＣＰ（Transmission Control Protocol）及びＵＤＰ（User Datagram Protocol）の中から後述する基準で選択される一つを用いて行われるとしてもよい。

タイマ部４００は、所定の時間の経過を統合制御部１００へ通知する。
統合制御部１００は、バックエンドサーバ１１の全体の動作を制御する。統合制御部１００は、例えば、バックエンドサーバ１１を実現するコンピュータシステムが所定のプログラムを実行することによって果たされるソフトウェア機能であるとしてもよい。

（データベース）
データベース３１は、データ記憶部３００、及びデータベース制御部３１０から構成される。データベース３１は、周知の技術を適宜用いて実現されるものとし、本発明はその内容を限定しないが、一例を挙げれば、データ記憶部３００は、例えばハードディスク装置であり、データを物理的に記憶し、データベース制御部３１０は、例えばＳＱＬインタプリタ機能であり、アクセス要求に従ってデータ記憶部３００の内容を操作する。

（統合制御部）
図３は、統合制御部１００の機能的な構成の一例を示すブロック図である。

統合制御部１００は、要求判断部１１０、単独アクセス部１２０、連携マスタ部１３０、占有受付レジスタ１４０、及び連携サービス部１５０から構成される。

要求判断部１１０は、フロントエンドサーバ４１、４２、…、４ｍからフロントエンド通信制御部２１０を介してクライアントによって発行されたアクセス要求を受信すると、そのアクセス要求についてシステム全体でのデータ同期制御が必要か、言い換えれば、データベース３１のみでそのアクセス要求を実行したとすれば他のデータベースとのデータの同期が失われるか否かを判断する。要求判断部１１０は、この判断を、例えば従来と同様に、そのアクセス要求がデータの参照のみに関するものか、データの追加、更新、又は削除に関するものかによって行ってもよい。

そして、システム全体でのデータ同期制御が必要でない（つまり、データベース３１のみでそのアクセス要求を実行してもデータの同期が失われない）と判断された場合、単独アクセス部１２０を並列起動してそのアクセス要求を引き渡す。データ同期制御が必要であると判断された場合、連携マスタ部１３０を並列起動してそのアクセス要求を引き渡す。

単独アクセス部１２０は、要求判断部１１０から引き渡されたアクセス要求をデータベース制御部３１０へ発行する。そして、データベース制御部３１０から実行結果を受け取ると、アクセス要求の発行元であるクライアントへフロントエンド通信制御部２１０を介してその実行結果を返却する。単独アクセス部１２０そのものは、本発明の主要部ではないため、これ以上詳しく説明しない。

連携マスタ部１３０は、まず、要求判断部１１０から引き渡されたアクセス要求について他の全てのバックエンドサーバ１２、…、１ｎの占有を試みる。この占有の詳細については、後述する。連携マスタ部１３０は、占有に成功した場合、そのアクセス要求を他の全てのバックエンドサーバ１２、…、１ｎへバックエンド通信制御部２２０を介して転送すると共に、データベース制御部３１０へ発行する。

バックエンドサーバ１２、…、１ｎにおける連携サービス部は、そのアクセス要求を受信すると、自らのデータベース制御部へそのアクセス要求を発行し、自らのデータベースでの実行を終えると、アクセス応答を返信する。

連携サービス部１５０は、このアクセス要求に応じた処理に代表されるように、他のバックエンドサーバから受信されるデータに応じた処理を行う。連携サービス部１５０は、このアクセス要求に応じた処理の他に、他のバックエンドサーバからの占有要求、占有変更、占有応答、及びアクセス応答に応じた処理を行うが、これらの処理については、それぞれ以下の関連する箇所で説明する。

なお、これらの処理は、データを受信する処理によって、受信されたデータに応じて並列起動されるとしてもよい。

（占有受付情報及び直前占有情報）
占有受付レジスタ１４０は、占有受付情報、及び直前占有情報を保持している。占有受付情報、及び直前占有情報は、バックエンドサーバ１１を占有しているバックエンドサーバと、その占有に関係するアクセス要求とを示し、占有の制御に用いられる。占有受付情報は、バックエンドサーバ１１がどのバックエンドサーバからも占有されていないことを示す空値を取り得るものとする。

図４は、占有受付レジスタ１４０に保持されている占有受付情報、及び直前占有情報の一例を示す図である。占有受付情報は、要求サーバＩＤ１４１、及び要求番号１４２を表し、直前占有情報は、要求サーバＩＤ１４３、及び要求番号１４４を表す。

要求サーバＩＤ１４１はバックエンドサーバ１１を占有しているバックエンドサーバを識別するサーバＩＤであり、要求番号１４２はそのバックエンドサーバにおいて個々のアクセス要求に一意に付与される番号である。

要求サーバＩＤ１４１と要求番号１４２との組み合わせを要求ＩＤと呼ぶ。要求ＩＤは、アクセス要求をデータ制御システム１０の全体で一意に識別する。

占有受付情報は、バックエンドサーバ１１がどのバックエンドサーバからも占有されていないことを、空値（例えばＮＵＬＬ、’ＯＦＦ’など）で表す。

直前占有情報は、占有受付情報によって示される占有要求が全てのバックエンドサーバによって受け入れられたことが分かったとき、その占有受付情報で更新される。これにより、直前占有情報は、バックエンドサーバ１１を含む全てのバックエンドサーバに共通して直前に受け入れられた占有を識別する。

なお、アクセス要求の内容そのもの（例えばＳＱＬで記述されるクエリ）は、要求ＩＤと対応付けて、図示しない記憶領域に記憶されるものとする。

（連携マスタ部と占有一覧情報）
図５は、連携マスタ部１３０の機能的な構成の一例を示すブロック図である。

連携マスタ部１３０は、採番部１３１、占有試行部１３２、占有一覧テーブル１３３、及び要求発行部１３８から構成される。

採番部１３１は、要求判断部１１０からアクセス要求を受け取ると、バックエンドサーバ１１で一意の番号を生成し、受け取ったアクセス要求と生成した番号とを占有試行部１３２へ引き渡す。採番部１３１は、例えばカウンタであり、アクセス要求を受け取るたびにカウンタをインクリメントすることによって、一意の番号を生成してもよい。

占有試行部１３２は、バックエンドサーバ１１を識別するサーバＩＤと採番部１３１から受け取った番号とからなる要求ＩＤで占有受付レジスタ１４０の占有受付情報を更新し、その要求ＩＤを含む占有要求を送信することによって、他の全てのバックエンドサーバ１２、…、１ｎの占有を試みる。

バックエンドサーバ１２、…、１ｎにおける連携サービス部は、占有要求を受信すると、自らの占有受付レジスタに空値が保持されている（つまり、どのバックエンドサーバからも占有されていない）場合、受信された占有要求に含まれる要求ＩＤでその占有受付レジスタの占有受付情報を更新した後、占有応答を返信する。

この占有応答は、対象要求ＩＤ、応答サーバＩＤ、及び受付要求ＩＤを含む（図示省略）。ここで、対象要求ＩＤは対応する占有要求に含まれていた要求ＩＤであり、応答サーバＩＤはその占有応答を送信したバックエンドサーバを識別するサーバＩＤであり、受付要求ＩＤはそのバックエンドサーバの占有受付レジスタに保持されている占有受付情報である。

説明の便宜上、対象要求ＩＤと受付要求ＩＤとが等しい占有応答を占有受諾応答と呼び、対象要求ＩＤと受付要求ＩＤとが異なる占有応答を占有拒否応答と呼ぶ。占有応答に、例えば'OK'、'NG'といった値を含めることによって、占有受諾応答と占有拒否応答との区別を明示してももちろん構わない。

連携サービス部１５０は、バックエンドサーバ１２、…、１ｎから返信される占有応答を受信し、占有一覧テーブル１３３に収集する。

占有一覧テーブル１３３は、受信された占有応答を占有一覧情報として保持する。
図６は、占有一覧テーブル１３３に保持される占有一覧情報の一例を示す図である。占有一覧情報は、占有要求ごと、バックエンドサーバごとに、占有要求に対してバックエンドサーバから返される占有応答について、対象要求ＩＤ１３４、応答サーバＩＤ１３５、及び受付要求ＩＤ１３６を表す。

図６には、ｓ₂及びｓ₃なるサーバＩＤで識別される２つのバックエンドサーバが他の全てのバックエンドサーバである場合に、対象要求ＩＤｉｄ₁に関する占有要求に対して、両方のバックエンドサーバから占有受諾応答が収集された占有成功例が示され、対象要求ＩＤｉｄ₂に関する占有要求について、ｓ₃で識別されるバックエンドサーバから占有拒否応答が収集された占有失敗例が示される。

再び図５を参照して、占有試行部１３２は、所定の時間内に他の全てのバックエンドサーバから占有受諾応答が収集された場合に占有成功と判断する。

要求発行部１３８は、占有成功と判断されると、他の全てのバックエンドサーバ１２、…、１ｎへバックエンド通信制御部２２０を介して対象要求ＩＤで識別されるアクセス要求を転送すると共に、そのアクセス要求をデータベース制御部３１０へ発行する。

バックエンドサーバ１２、…、１ｎにおける連携サービス部は、そのアクセス要求を受信すると、自らのデータベース制御部へそのアクセス要求を発行する。そして、自らのデータベースにおける実行が完了すると、実行結果を示すアクセス応答を返信する。

連携サービス部１５０は、そのアクセス応答を受信し、占有一覧情報の対応レコードに、例えば図示しないフラグ情報を用いて、アクセス応答が返されたことを記録する。

要求発行部１３８は、他の全てのバックエンドサーバ１２、…、１ｎと、データベース制御部３１０とからアクセス応答が返ることでシステム全体でのアクセス完了を知り、クライアントからのアクセス要求を転送したフロントエンドサーバへフロントエンド通信制御部２１０を介してアクセス結果を返却する。

また、占有試行部１３２は、一つ以上の占有拒否応答が収集された場合、次のようにして競合の解消を図る。

まず、収集された占有拒否応答に含まれる受付要求ＩＤが受付占有レジスタ１４０に保持されている直前占有情報と同一である場合（つまり、バックエンドサーバ１１を含む全てのバックエンドサーバによって直前に受け入れられた占有が、その占有拒否応答を返したバックエンドサーバではまだ解除されていない場合）には、そのバックエンドサーバとの真の競合は生じていないと考えて、占有試行部１３２は、その占有拒否応答を送信したバックエンドサーバへ占有要求を再送（つまり、占有をリトライ）して、占有試行を続行する。

次に、他の全てのバックエンドサーバ１２、…、１ｎから占有応答が収集され、その中の一つ以上が占有拒否応答である場合、占有拒否応答に含まれる受付要求ＩＤで識別されるバックエンドサーバ（これを競合サーバと呼ぶ）の優先順位とバックエンドサーバ１１の優先順位との比較に基づいて、自らの占有を変更すべき優先サーバを特定する。

この比較は、バックエンドサーバ１２、…、１ｎ間に定められている優先順位に、さらに各バックエンドサーバが自分以外のバックエンドサーバを占有しているか否かを考慮に入れた順位を用いて行われる。

そのような順位の具体例として、自分以外のバックエンドサーバを占有していない状態のバックエンドサーバ１２、…、１ｎを前記優先順位で並べ、さらにその高位に、自分以外のバックエンドサーバを占有している状態のバックエンドサーバ１２、…、１ｎを前記優先順位で並べて定義される順位を用いることができる。

占有試行部１３２は、この順位に従って、自分以外のバックエンドサーバを占有している状態のバックエンドサーバをそうでないバックエンドサーバよりも優先して、バックエンドサーバ１１よりも高位の競合サーバの中で最高位の競合サーバを前記優先サーバとして特定する。

なお、バックエンドサーバ１１が自分以外のバックエンドサーバを占有しているか否かは、一つ以上の占有許諾応答が収集されるか否かによって判断でき、また、他の各バックエンドサーバ１２、…、１ｎが自分以外のバックエンドサーバを占有しているか否かは、受信された占有拒否応答にその占有拒否応答を返したバックエンドサーバ以外のバックエンドサーバを識別する受付要求ＩＤが含まれるか否かによって判断することができる。

そして、バックエンドサーバ１１から前記特定された優先サーバへの変更を示す占有変更を送信すると共に、優先サーバによる占有を示す占有拒否応答に含まれる受付要求ＩＤで占有受付レジスタ１４０の占有受付情報を更新する。

送信される占有変更は、具体的に、変更前に関して占有受付レジスタ１４０に保持されている要求ＩＤを含み、変更後に関して優先サーバからの占有拒否応答に含まれる受付要求ＩＤを含んでもよい。

バックエンドサーバ１２、…、１ｎにおける連携サービス部は、占有変更を受信すると、受信された占有変更に含まれる変更前に関する要求ＩＤと、自らの占有受付レジスタに保持されている要求受付情報の要求ＩＤとが一致する場合、変更前の正真のバックエンドサーバからの占有変更であると判断して、受信された占有変更に含まれる変更後に関する受付要求ＩＤで自らの占有受付レジスタを更新し、その要求ＩＤで識別されるバックエンドサーバへ占有受諾応答を送信する。

他方、バックエンドサーバ１１よりも高位の競合サーバがない場合には、占有試行部１３２は何もせず、競合サーバにおける占有試行部が前述した処理を行うことによって競合が解消されるのを待つ。

占有試行部１３２は、所定の時間内に占有成功も占有変更もできなかった場合に占有失敗と判断する。

要求発行部１３８は、占有失敗と判断されると、クライアントからのアクセス要求を転送したフロントエンドサーバへフロントエンド通信制御部２１０を介してアクセス失敗を通知する。

（主要部の詳細な動作）
以下、本発明の主要部の詳細な動作についてフローチャートを参照しながら説明する。

図７は、統合制御部１００によって行われる統合制御処理の一例を示すフローチャートである。

統合制御部１００は、クライアントから発行されたアクセス要求を受信すると（Ｓ１０１）、データベース３１のみでそのアクセス要求を実行したとすれば他のデータベースとのデータの同期が維持されるか否か、言い換えれば、システム全体でのデータ同期制御が必要かを要求判断部１１０で判断する。そして、システム全体でのデータ同期制御が必要でないと判断された場合（Ｓ１０２でＮＯ）、単独アクセス部１２０へそのアクセス要求を引き渡し（Ｓ１０３）、必要であると判断された場合（Ｓ１０２でＹＥＳ）、連携マスタ部１３０へそのアクセス要求を引き渡す（Ｓ２００）。

図８は、連携マスタ部１３０によって行われる連携マスタ処理の一例を示すフローチャートである。

連携マスタ部１３０は、要求判断部１１０からアクセス要求を受け取ると、占有受付レジスタ１４０の占有受付情報が空値になるまで（つまり、占有から解かれるまで）待って（Ｓ２１０）、バックエンドサーバ１１を識別するサーバＩＤと採番部１３１で生成された番号とからなる要求ＩＤを、占有受付情報として占有受付レジスタ１４０に登録する（Ｓ２０２）。

そして、占有試行処理を行い（Ｓ３００）、占有に成功した場合には（Ｓ２０３で成功）、他のバックエンドサーバ１２、…、１ｎへそのアクセス要求を転送すると共に（Ｓ２０４）、占有受付レジスタ１４０の直前占有情報を占有受付情報で更新する（Ｓ２０５）。この更新後の直前占有情報は、バックエンドサーバ１１が要求して、全てのバックエンドサーバに共通して受け入れられた占有を識別する。

そして、占有受付情報を空値で更新することにより削除し（Ｓ２０６）、そのアクセス要求をデータベース制御部３１０へ発行してデータベース３１をアクセスする（Ｓ２０７）。

さらに、他のバックエンドサーバ１２、…、１ｎと、データベース制御部３１０とからアクセス応答が返るのを待って（Ｓ２０８）、クライアントからのアクセス要求を転送したフロントエンドサーバへアクセス結果を送信する（Ｓ２０９）。

また、占有に失敗した場合には（Ｓ２０３で失敗）、クライアントからのアクセス要求を転送したフロントエンドサーバへアクセス失敗を送信する（Ｓ２０９）。

また、占有を変更した場合には（Ｓ２０３で変更）、Ｓ２０１へ戻って変更前の自らの占有を再度試みる。

図９は、占有試行部１３２によって行われる占有試行処理の一例を示すフローチャートである。

占有試行部１３２は、占有受付レジスタ１４０に保持されている占有受付情報で示される要求ＩＤを含む占有要求を他の全てのバックエンドサーバ１２、…、１ｎへ送信し（Ｓ３０１）、タイマ部４００をスタートさせる（Ｓ３０２）。この占有要求は、ブロードキャストされてもよく、またそれぞれのバックエンドサーバへ個別に送信されてもよい。

占有試行部１３２は、占有一覧テーブル１３３の占有一覧情報から、前記占有受付情報と一致する対象要求ＩＤを持つ占有応答を参照し（Ｓ３０３）、参照された占有応答の中に、占有受付レジスタ１４０の直前占有情報と同一の受付要求ＩＤを持つ占有拒否応答があれば（Ｓ３０４でＹＥＳ）、その占有拒否応答を送信したバックエンドサーバへ前記占有要求を再送信する（Ｓ３０５）。

占有試行部１３２は、他の全てのバックエンドサーバから占有応答が収集された後（Ｓ３１１でＹＥＳ）、収集された占有応答が全て占有受諾応答なら（Ｓ３１２でＹＥＳ）、占有成功を示して連携マスタ処理へ戻る（Ｓ３１３）。

収集された占有応答の一つ以上が占有拒否応答なら（Ｓ３１２でＮＯ）、占有試行部１３２は、前述したように、バックエンドサーバ間の優先順序にさらに各バックエンドサーバが自分以外のバックエンドサーバを占有しているか否かを考慮に入れた順位を用いて、競合サーバの中から自らの占有を変更すべき優先サーバを特定し（Ｓ３１４でＹＥＳ）、バックエンドサーバ１１から前記特定された優先サーバへの変更を示す占有変更を送信する（Ｓ３２１）。この占有変更は、バックエンドサーバ１１へ占有受諾応答を返信したバックエンドサーバへ個別に送信されてもよく、またブロードキャストされてもよい。

そして、占有受付レジスタ１４０の占有受付情報を更新し（Ｓ３２２）、占有変更を示して連携マスタ処理へ戻る（Ｓ３２３）。

占有試行部１３２は、全てのバックエンドサーバから占有応答が収集されていないか（Ｓ３１１でＮＯ）、特定すべき優先サーバ（つまり、バックエンドサーバ１１よりも上位の競合サーバ）がなければ（Ｓ３１４でＮＯ）、タイマ部４００を参照する。タイムアウトしていれば（Ｓ３１５でＹＥＳ）、占有受付レジスタ１４０の占有受付情報を空値で更新することによって削除し（Ｓ３３１）、占有失敗を示して連携マスタ処理へ戻る（Ｓ３３２）。タイムアウトしていなければ（Ｓ３１５でＮＯ）、Ｓ３０３へ戻って処理を継続する。

図１０は、連携サービス部１５０によって行われる連携サービス処理の一例を示すフローチャートである。

連携サービス部１５０は、他のバックエンドサーバからデータを受信すると（Ｓ４０１）、受信されたデータの種類を判断する。

受信されたデータが占有要求である場合（Ｓ４０２で占有要求）、次の処理を行う。
占有受付レジスタ１４０の占有受付情報が空値であれば（Ｓ４１１でＹＥＳ）、受信された占有要求に含まれる要求ＩＤを占有受付情報として占有受付レジスタ１４０に登録し（Ｓ４１３）、占有受諾応答を返信する（Ｓ４１４）。

また、占有受付情報と受信された占有要求に含まれる要求ＩＤとが同一である、つまり現在受け入れている占有の再要求を受信した場合にも（Ｓ４１２でＹＥＳ）、占有受諾応答を返信する（Ｓ４１４）。

その他の場合には（Ｓ４１２でＮＯ）、占有拒否応答を返信する（Ｓ４１５）。
受信データがアクセス要求である場合（Ｓ４０２でアクセス要求）、次の処理を行う。

受信されたアクセス要求に含まれる要求ＩＤと占有受付レジスタ１４０の占有受付情報の要求ＩＤとが一致するならば（Ｓ４２１でＹＥＳ）、直前占有情報を占有受付情報で更新する（Ｓ４２２）。この更新後の直前占有情報は、バックエンドサーバ１１以外のバックエンドサーバが要求して、バックエンドサーバ１１を含む全てのバックエンドサーバに共通して受け入れられた占有を識別する。

その後、占有受付情報を空値で更新することによって削除し（Ｓ４２３）、受信されたアクセス要求をデータベース制御部３１０へ発行することによってデータベース３１において実行し（Ｓ４３３）、アクセス要求を送信したバックエンドサーバへアクセス応答を返信する（Ｓ４３４）。

受信されたアクセス要求に含まれる要求ＩＤと占有受付レジスタ１４０の占有受付情報の要求ＩＤとが一致しなければ（Ｓ４２１でＮＯ）、何もしない。

受信データが占有応答、又はアクセス応答である場合（Ｓ４０２で占有応答、アクセス応答）、占有要求に対してバックエンドサーバから初めて返される占有応答ならその占有応答を占有一覧テーブル１３３の占有一覧情報へ追加登録する。また、同じ占有要求に対して同じバックエンドサーバから二度目以降に返される占有応答か、アクセス応答なら占有一覧情報の対応するレコードを更新する（Ｓ４４１）。

受信データが占有変更である場合（Ｓ４０２で占有変更）、受信された占有変更に含まれる変更前に関する要求ＩＤと、占有受付レジスタ１４０に保持されている占有受付情報とが一致するなら（Ｓ４５１でＹＥＳ）、受信された占有変更に含まれる要求ＩＤで占有受付レジスタ１４０の占有受付情報を更新し（Ｓ４５２）、その要求ＩＤで識別されるバックエンドサーバへ占有受諾応答を送信する（Ｓ４５３）。

（連携動作の典型例）
以下、連携動作の典型例についてシーケンスチャートを参照しながら説明する。

図１１は、通常のデータ同期動作の一例を示すシーケンスチャートである。図１１に表される矢印はデータフローを表し、それぞれのデータフローには、図７から図１０のフローチャートに示される対応ステップの符号が付される。同一のステップに対応する複数のデータフローは、符号に添えた英字で区別される。

図１１には、どのバックエンドサーバも占有されていない状態において、バックエンドサーバ１１が、システム全体でのデータの同期制御が必要と判断されたアクセス要求を、他のバックエンドサーバ１２〜１ｎを占有して実行する例が示される。

この例では、まず全てのバックエンドサーバの占有受付レジスタに、そのアクセス要求に対応する占有要求に含まれる要求ＩＤが占有受付情報として登録され、次に他の全てのバックエンドサーバ１２、…、１ｎからの占有受諾応答がバックエンドサーバ１１に収集された後、バックエンドサーバ１１からアクセス要求が発せられ、全てのバックエンドサーバが自らのデータベースでそのアクセス要求を実行する。

このように、アクセス要求は全てのバックエンドサーバがバックエンドサーバ１１による占有を受諾してから初めて実行されるため、そのアクセス要求は全てのバックエンドサーバで確実に実行される。また、新たなアクセス要求に対応する占有要求が占有中に発生しても拒否されるため、複数のアクセス要求がバックエンドサーバによって異なる順序で実行される事態が避けられる。

このことはどのバックエンドサーバのどのアクセス要求についても成り立つから、この構成によって全てのデータベース間でのデータの同期が維持される。また、データの同期の維持そのものが分散処理されるので、従来のレプリケーションサーバを省略できる。その結果、システムからデータの同期維持に関する性能及び信頼性の面でのボトルネックが排除され、システムのスケーラビリティの具現化が容易となる。

図１２は、同一のバックエンドサーバからの占有リトライ動作の一例を示すシーケンスチャートである。図１２に表されるそれぞれのデータフローには、図１１と同様の符号が付される。

図１２には、他のバックエンドサーバの一つ（例えばバックエンドサーバ１２）がバックエンドサーバ１１から占有されている状態において、バックエンドサーバ１１が、システム全体でのデータの同期制御が必要と判断されたアクセス要求を、他のバックエンドサーバ１２〜１ｎを占有して実行する例が示される。

この例では、最初バックエンドサーバ１２は、バックエンドサーバ１１において直前に処理されたアクセス要求をまだ処理中であり、バックエンドサーバ１２の占有受付レジスタには、その直前のアクセス要求に対応する占有要求（不図示）に関する要求ＩＤが登録されている。そのため、バックエンドサーバ１１からの新たな占有要求に対して占有拒否応答が返される。なお、直前のアクセス要求に関係するデータフローは点線で示される。

バックエンドサーバ１１は、返された占有拒否応答に含まれる受付要求ＩＤが受付占有レジスタ１４０に保持されている直前占有情報と同一であることによって、自らが直前に受け入れていた占有がバックエンドサーバ１２ではまだ解除されていないことを知り、占有要求を再送することによって、バックエンドサーバ１２の処理終了後に占有に成功する。その後の動作は、図１１と同様である。

このように、占有拒否応答が受信された場合でも、自らが直前に受け入れていた占有に関係する占有拒否である場合には、直ちに占有失敗とするのではなく、占有要求を再送することで、効率的に占有に成功する可能性が高まる。

これにより、バックエンドサーバ間での処理タイミングの差異が吸収され、システムのスループットが向上する。

図１３は、競合バックエンドサーバへの占有変更動作の一例を示すシーケンスチャートである。図１３に表されるそれぞれのデータフローには、図１１と同様の符号が付される。

図１３には、自らよりも優先順位の高い競合サーバとの間で占有要求が競合したことを知ったバックエンドサーバ１１が、自らの占有をその競合サーバに変更する例が示される。

この例では、バックエンドサーバ１１は、受信された占有拒否応答に基づいて優先サーバを特定し、占有受諾応答を返したバックエンドサーバ１２に、バックエンドサーバ１１からその優先サーバへの変更を示す占有変更を送信すると共に、自らの占有受付レジスタの占有受付情報を占有拒否応答に含まれる受付要求ＩＤで更新することによって、占有者をその優先サーバに変更する。

このように、より優先順位の高いバックエンドサーバとの間で占有要求が競合したことを知ったバックエンドサーバは、自らの占有を優先サーバへと積極的に変更するので、競合の解消を、例えば所定時間待ってリトライするといった簡略な方法に比べて、より迅速かつ円滑に行うことができる。

（通信プロトコルの変更）
フロントエンドサーバとバックエンドサーバとの通信、及びバックエンドサーバ同士の通信を、複数の通信プロトコル（例えばＩＰ上のＴＣＰ及びＵＤＰ）の中から所定の基準で選択される一つを用いて行ってもよいことを、先に述べた。

以下では、この選択の基準、及び通信プロトコルを変更する意義について説明する。
図１４は、通信プロトコル選択処理の一例を示すフローチャートである。

この通信プロトコル選択処理は、ＴＣＰ及びＵＤＰの一方を選択する処理であり、フロントエンド通信制御部２１０、及びバックエンド通信制御部２２０によって実行されてもよく、また、統合制御部１００によって実行され、フロントエンド通信制御部２１０、及びバックエンド通信制御部２２０は、統合制御部１００によって選択された通信プロトコルに従って通信を行ってもよい。

この通信プロトコル選択処理による選択の基準は、送信されるデータの量が予め定められたしきい値を超える場合（Ｓ５０１でＹＥＳ）、再送信である場合（Ｓ５０２でＹＥＳ）、及び送信されるデータが応答である場合（Ｓ５０３でＹＥＳ）にＴＣＰを選択し（Ｓ５０５）、その他の場合にＵＤＰを選択する（Ｓ５０４）というものである。

一般に、ＵＤＰによる通信は、ＴＣＰによる通信に比べて、一度に通信できるデータ量に制限がある、通信に要する処理オーバヘッドが小さい、データの到達確認機能がなく通信の信頼性が低いといった特性がある。この特性に鑑みて、上記の選択の基準に従って用いる通信プロトコルを変更することにより、通信のオーバヘッドと信頼性との良好なトレードオフを図ることができる。

（第２の実施の形態）
本発明の第２の実施の形態におけるデータ制御装置について、図面を参照しながら詳細に説明する。第２の実施の形態におけるデータ制御装置も、第１の実施の形態と同様に、バックエンドサーバの例を用いて説明される。

第２の実施の形態におけるバックエンドサーバは、第１の実施の形態で説明したバックエンドサーバ１１、１２、…、１ｎと比べて、分散データベースシステム１（図１を参照）において同様の役割を果たすが、サーバ状態管理機能が追加される点で異なる。このサーバ状態管理機能は、具体的に、第１の実施の形態で説明したバックエンドサーバ（図２を参照）の統合制御部１００に追加される。

以下、第２の実施の形態における統合制御部について詳細に説明する。

（統合制御部）
図１５は、第２の実施の形態における統合制御部１００ａの機能的な構成の一例を示すブロック図である。統合制御部１００ａは、第１の実施の形態における統合制御部１００（図３を参照）と比べて、サーバ状態管理部１６０が追加されると共に、変更された要求判断部１１０ａ、及び連携マスタ部１３０ａを備える。

サーバ状態管理部１６０は、他のバックエンドサーバからのデータ受信の有無を所定時間監視することによって故障状態を検出する部であり、検出結果を保持するサーバ状態テーブル１６１を有する。

サーバ状態管理部１６０は、周期的に交換されるよう定められた監視用データの受信の有無を監視してもよく、また、例えば状態通知要求や占有要求といった所定のデータの送信に応じて受信されるべき応答の有無を監視してもよい。

図１６は、サーバ状態テーブル１６１に保持されているサーバ状態情報の一例を示す図である。サーバ状態情報は、バックエンドサーバごとに、サーバＩＤ１６２、サーバが運用中か故障中かを示すサーバ状態１６３、及び受信の有無を示す受信フラグ１６４を表す。

サーバ状態管理部１６０は、周期的に、又は、例えば占有要求といった所定のデータが送信された後に、サーバ状態管理処理を実行して故障検出を行い、その検出の結果に応じてサーバ状態テーブル１６１のサーバ状態１６３を更新する。このサーバ状態管理処理は、後述するように、自分自身の故障をも検出する。

要求判断部１１０ａは、サーバ状態テーブル１６１を参照して、自バックエンドサーバのサーバ状態が’故障中’と示されている間、フロントエンド通信制御部２１０からのアクセス要求の受け入れを停止する機能を、要求判断部１１０に追加してなる。

連携マスタ部１３０ａは、サーバ状態テーブル１６１を参照して、サーバ状態が故障中と示されているバックエンドサーバを除外して、占有要求の送信、占有の成否判断、及びアクセス要求の送信を行うよう、連携マスタ部１３０を変更してなる。

この変更は、詳細には、図９のフローチャートにおいて、Ｓ３０１をサーバ状態が運用中と示されているバックエンドサーバのみへ占有要求を送信するように変更し、Ｓ３０４をサーバ状態が運用中と示されている全てのバックエンドサーバから占有受諾応答を収集したかを判断するように変更し、また、図８のフローチャートにおいて、Ｓ２０４をサーバ状態が運用中と示されているバックエンドサーバのみへアクセス要求を転送するように変更することによって達成される。

（サーバ状態管理処理）
図１７は、サーバ状態管理部１６０によって行われるサーバ状態管理処理の一例を示すフローチャートである。

サーバ状態管理部１６０は、サーバ状態テーブル１６１の全ての受信フラグ１６４を’ＮＯ’にしてから（Ｓ６０１）、他の全てのバックエンドサーバへ状態通知要求を送信し（Ｓ６０２）、タイマ部４００をスタートさせる（Ｓ６０３）。

状態通知応答が受信されると（Ｓ６０４でＹＥＳ）、受信された状態通知応答を送信したバックエンドサーバに関して、受信フラグ１６４を’ＹＥＳ’に更新し、かつサーバ状態を’運用中’に更新する（Ｓ６０５）。タイムアウトになるまでＳ６０４〜Ｓ６０５の処理を繰り返した後（Ｓ６０６）、サーバ状態１６３が’運用中’と示された全てのバックエンドサーバについて受信フラグ１６４が’ＮＯ’のままであれば（Ｓ６０７でＹＥＳ）、自バックエンドサーバのサーバ状態１６３を’故障中’に更新する（Ｓ６０８）。そうでなければ（Ｓ６０７でＮＯ）、受信フラグ１６４が’ＮＯ’のままのバックエンドサーバについてサーバ状態１６３を’故障中’に更新する（Ｓ６０９）。

この構成によれば、故障したバックエンドサーバが自動的にシステムから切り離されるので、一つのバックエンドサーバの故障がシステム全体に及ぼす影響が軽減され、サービス無中断の運用が可能となる。

なお、ここでは、状態通知要求に応じて状態通知応答が返される例を説明したが、占有要求に応じて返される占有通知を監視してもよく、また、サーバ状態管理部１６０が状態通知応答を自発的かつ周期的に送信することにより、状態通知要求の送信を省略する変形も考えられる。

（第３の実施の形態）
本発明の第３の実施の形態におけるデータ制御装置について、図面を参照しながら詳細に説明する。第３の実施の形態におけるデータ制御装置も、第１及び第２の実施の形態と同様に、バックエンドサーバの例を用いて説明される。

第３の実施の形態におけるバックエンドサーバは、第１の実施の形態で説明した分散データベースシステム１（図１を参照）においてバックエンドサーバ１１、１２、…、１ｎと同様の役割を果たすが、第２の実施の形態で説明したサーバ状態管理機能に加えて、アクセス要求保留機能が追加される点で異なる。このアクセス要求保留機能は、具体的に、第１の実施の形態で説明したバックエンドサーバ（図２を参照）の統合制御部１００に、前述のサーバ状態管理機能と共に追加される。

以下、第３の実施の形態における統合制御部について詳細に説明する。

（統合制御部）
図１８は、第３の実施の形態における統合制御部１００ｂの機能的な構成の一例を示すブロック図である。統合制御部１００ｂは、第２の実施の形態における統合制御部１００ａ（図１５を参照）と比べて、保留制御部１７０が追加されると共に、変更された要求判断部１１０ｂ、連携サービス部１５０ｂ、及びサーバ状態管理部１６０ｂを備える。

保留制御部１７０は、特定の動作モードにおいて一つ以上のアクセス要求を蓄積し、前記動作モードが解除されるとき、前記アクセス要求を蓄積された順に取り出してデータベース制御部３１０へ発行する部であり、アクセス要求を蓄積して蓄積された順に出力する要求保留キュー１７１を有する。

図１９は、要求保留キュー１７１に蓄積されているアクセス要求の一例を示す図である。要求保留キュー１７１は、アクセス要求ごとに、要求ＩＤ１７２、及び要求内容１７３を保持している。

保留制御部１７０は、例えばシステム管理者から図示しないシステムコンソール等を介して、前記特定の動作モードの開始と解除とを指示される。説明の便宜上、前記特定の動作モードを保留モードと呼び、保留モードの開始及び解除の指示を、それぞれ保留指示及び再開指示と呼ぶ。

サーバ状態管理部１６０ｂは、保留制御部１７０からの制御に応じて、自バックエンドサーバのサーバ状態を’保留中’及び’運用中’に更新する機能を、サーバ状態管理部１６０に追加してなる。

要求判断部１１０ｂは、自バックエンドサーバのサーバ状態が’保留中’と示されている間、フロントエンド通信制御部２１０からのアクセス要求の受け入れを制限する（例えば、ダンプコマンド等の参照専用コマンドのみを受け入れる）機能を、要求判断部１１０ａに追加してなる。

連携サービス部１５０ｂは、自バックエンドサーバのサーバ状態が’保留中’と示されている間、他のバックエンドサーバから転送されたアクセス要求を、データベース制御部３１０へ発行する代わりに、保留制御部１７０の要求保留キュー１７１に蓄積するように、連携サービス部１５０を変更してなる。そして、連携サービス部１５０ｂは、この変更点を除いて連携サービス部１５０と同様に動作する。

図２０は、連携サービス部１５０ｂによって行われる連携サービス処理の一例を示すフローチャートである。

連携サービス部１５０ｂは、アクセス要求が受信された場合（Ｓ４０２でアクセス要求）、自バックエンドサーバのサーバ状態が’保留中’であれば（Ｓ４３１でＹＥＳ）、受信されたアクセス要求を要求保留キュー１７１に登録し（Ｓ４３２）、’保留中’でない場合にのみ（Ｓ４３１でＮＯ）、受信されたアクセス要求をデータベース制御部３１０へ発行する（Ｓ４３３）。その他の動作、特に占有に関する動作については、図１０のフローチャートに示される連携サービス部１５０の動作と同一である。

このように、連携サービス部１５０ｂは、保留中にも、占有に関する処理を運用中と変わらずに行うことから、保留中に受信されたアクセス要求は、運用中であれば実行されていた順序、つまりデータの同期維持に必要な順序通りに、要求保留キュー１７１に蓄積される。

図２１は、保留制御部１７０によって行われる保留制御処理の一例を示すフローチャートである。

保留制御部１７０は、保留指示を受け付けると（Ｓ７０１で保留）、自バックエンドサーバについてサーバ状態テーブル１６１のサーバ状態１６３を’保留中’に更新する（Ｓ７０２）。

また、再開指示を受け付けると（Ｓ７０１で再開）、要求保留キュー１７１が空になるまで（Ｓ７０３でＮＯ）、要求保留キュー１７１から先頭のアクセス要求を取り出し（Ｓ７０４）、取り出したアクセス要求をデータベース制御部３１０へ発行する（Ｓ７０５）処理を繰り返す。

そして、要求保留キュー１７１が空になれば（Ｓ７０３でＹＥＳ）、自バックエンドサーバについてサーバ状態テーブル１６１のサーバ状態１６３を’運用中’に更新する（Ｓ７０６）。

この構成によれば、保留モードが解除されるとき、データの同期維持に必要な順序通りに蓄積された一つ以上のアクセス要求を単に蓄積された順に実行することによって、迅速にデータの同期を回復できる。そして、データの同期回復のために他のデータベースからデータを複写する必要がないため、データベースの規模が大きいほど、データの同期回復の迅速化に大きな効果が得られる。

これにより、例えば、データベースのメンテナンスを行うためにデータの更新を一時的に保留しその後回復するような場合に、極めて高い実用的価値が発揮される。

（変形例）
ここまでの実施の形態では、フロントエンドサーバとバックエンドサーバとの通信、及びバックエンドサーバ同士の通信を、一つのネットワークを介して行う例について説明した。しかしながら、バックエンドサーバ同士の通信を、フロントエンドサーバとバックエンドサーバとの通信から分離された専用のネットワークを介して行う変形も考えられる。以下、そのような変形について説明する。

図２２は、本発明の変形例におけるデータ制御システム１０ａを含む分散データベースシステムの一例を示す機器構成図である。分散データベースシステム１ａは、第１の実施の形態で説明した分散データベースシステム１（図１を参照）と比べて、バックエンドサーバ１１ａ、１２ａ、…、１ｎａを接続する専用のネットワーク２１を備える点で異なる。

バックエンドサーバ１１ａ、１２ａ、…、１ｎａは、ネットワーク２０を通してフロントエンドサーバと通信し、ネットワーク２１を通して他のバックエンドサーバと通信する。

図２３は、バックエンドサーバ１１ａの機能的な構成の一例を示すブロック図である。バックエンドサーバ１１ａと共に示されるデータベース３１は、第１の実施の形態と同様である。

バックエンドサーバ１１ａは、バックエンドサーバ１１におけるネットワークアダプタ部２００に代えて、２つのネットワークアダプタ部２０１、２０２を備える。

ネットワークアダプタ部２０１は、ネットワーク２０と物理的に接続し、フロントエンド通信制御部２１０は、ネットワークアダプタ部２０１を介してフロントエンドサーバとの通信を実行する。

ネットワークアダプタ部２０２は、ネットワーク２１と物理的に接続し、バックエンド通信制御部２２０は、ネットワークアダプタ部２０２を介してバックエンドサーバとの通信を実行する。

この構成によれば、バックエンドサーバ同士は、フロントエンドサーバとバックエンドサーバとの間の通信トラフィックに影響されることなく通信を行うことができる。そのため、データ制御システム１０と比べると、例えば占有要求、占有変更、占有応答、アクセス要求といったバックエンドサーバ同士の通信がより安定的に行われることとなり、もって、データ制御システム１０ａはより高い安定性を発揮することができる。

本発明のデータ制御装置は、データの同期が維持されるべき複数のデータベースを制御するデータ制御システムに利用でき、とりわけ、前記複数のデータベース間でのデータの同期を低コストかつ効率的に維持する装置として有用である。

第１の実施の形態におけるデータ制御システムの一例を示す機器構成図である。 バックエンドサーバの機能的な構成の一例を示すブロック図である。 統合制御部の機能的な構成の一例を示すブロック図である。 連携マスタ部の機能的な構成の一例を示すブロック図である。 占有受付レジスタに保持されている占有受付情報、及び直前占有情報の一例を示す図である。 占有一覧テーブルに保持されている占有一覧情報の一例を示す図である。 統合制御処理の一例を示すフローチャートである。 連携マスタ処理の一例を示すフローチャートである。 占有試行処理の一例を示すフローチャートである。 連携サービス処理の一例を示すフローチャートである。 通常のデータ同期動作の一例を示すシーケンスチャートである。 占有リトライ動作の一例を示すシーケンスチャートである。 占有変更動作の一例を示すシーケンスチャートである。 通信プロトコル選択処理の一例を示すフローチャートである。 第２の実施の形態における統合制御部の機能的な構成の一例を示すブロック図である。 サーバ状態テーブルに保持されているサーバ状態情報の一例を示す図である。 サーバ状態管理処理の一例を示すフローチャートである。 第３の実施の形態における統合制御部の機能的な構成の一例を示すブロック図である。 要求保留キューに蓄積されているアクセス要求の一例を示す図である。 保留応答を行う連携サービス処理の一例を示すフローチャートである。 保留制御処理の一例を示すフローチャートである。 変形例におけるデータ制御システムの構成の一例を示す機器構成図である。 変形例におけるバックエンドサーバの機能的な構成の一例を示すブロック図である。 従来のデータ制御システムの構成の一例を示すブロック図である。

符号の説明

１、１ａ、９ 分散データベースシステム
１０、１０ａ データ制御システム
１１、１２、…、１ｎ、１１ａ、１２ａ、…、１ｎａ バックエンドサーバ
２０、２１ ネットワーク
３１、３２、…、３ｎ データベース
４１、４２、…、４ｍ フロントエンドサーバ
６１、６２、６３ バックエンドサーバ
６６、６７、６８ データベース
７１ レプリケーションサーバ
８０ ネットワーク
９１、９２ フロントエンドサーバ
１００、１００ａ、１００ｂ 統合制御部
１１０、１１０ａ、１１０ｂ 要求判断部
１２０ 単独アクセス部
１３０、１３０ａ 連携マスタ部
１３１ 採番部
１３２ 占有試行部
１３３ 占有一覧テーブル
１３４ 対象要求ＩＤ
１３５ 応答サーバＩＤ
１３６ 受付要求ＩＤ
１３８ 要求発行部
１４０ 占有受付レジスタ
１４１、１４３ 要求サーバＩＤ
１４２、１４４ 要求番号
１５０、１５０ｂ 連携サービス部
１６０、１６０ｂ サーバ状態管理部
１６１ サーバ状態テーブル
１６２ サーバＩＤ
１６３ サーバ状態
１６４ 受信フラグ
１７０ 保留制御部
１７１ 要求保留キュー
１７２ 要求ＩＤ
１７３ 要求内容
２００、２０１、２０２ ネットワークアダプタ部
２１０ フロントエンド通信制御部
２２０ バックエンド通信制御部
３００ データ記憶部
３１０ データベース制御部
４００ タイマ部

Claims (14)

1. データの同期が維持されるべき複数のデータベースをそれぞれ制御する複数のデータ制御装置の一つであって、
   クライアントから発行された第１のアクセス要求を受信すると、前記第１のアクセス要求について前記複数のデータベース間でのデータの同期制御が必要か否かを判断する要求判断手段と、
   不要と判断された場合、自らのデータベースに対して前記第１のアクセス要求を発行する単独アクセス手段と、
   必要と判断された場合、他の全てのデータ制御装置の占有を試み、前記占有に成功した場合、他の全てのデータ制御装置へ前記第１のアクセス要求を転送すると共に、自らのデータベースに対して前記第１のアクセス要求を発行する連携マスタ手段と、
   他のデータ制御装置から転送された第２のアクセス要求を受信すると、自らのデータベースに対して前記第２のアクセス要求を発行する連携サービス手段と
   を備えることを特徴とするデータ制御装置。
2. 前記データ制御装置は、さらに、
   自らを占有しているデータ制御装置を示す占有受付情報を保持している占有受付レジスタを備え、
   前記連携マスタ手段は、自データ制御装置を示すように前記占有受付情報を更新した後、他の全てのデータ制御装置へ自データ制御装置を識別する第１の占有要求を送信することによって前記占有を試み、他の全てのデータ制御装置から占有受諾応答が受信された場合に前記占有に成功したと判断し、
   前記連携サービス手段は、他のデータ制御装置を識別する第２の占有要求を受信したとき、前記占有受付情報がどのデータ制御装置からも占有されていないことを示す場合、前記第２の占有要求によって識別されるデータ制御装置を示すように前記占有受付情報を更新すると共に占有受諾応答を返信し、その他の場合、占有拒否応答を返信する
   ことを特徴とする請求項１に記載のデータ制御装置。
3. 前記データ制御装置によって受信される占有拒否応答は、前記占有拒否応答を送信したデータ制御装置において継続中の占有を識別し、
   前記占有受付レジスタは、さらに、自データ制御装置を含む全てのデータ制御装置に共通して直前に受け入れられた占有を識別する直前占有情報を保持し、
   前記連携マスタ手段は、前記第１の占有要求に対して占有拒否応答が受信された場合、前記受信された占有拒否応答によって識別される占有が前記直前占有情報によって識別される占有と同一であれば、前記占有拒否応答を送信したデータ制御装置へ前記第１の占有要求を再送信する
   ことを特徴とする請求項２に記載のデータ制御装置。
4. 前記データ制御装置によって受信される占有拒否応答は、前記占有拒否応答を送信したデータ制御装置を占有しているデータ制御装置を示すと共に、前記複数のデータ制御装置には優先順位が定められており、
   前記連携マスタ手段は、前記第１の占有要求に対して占有拒否応答が受信された場合、前記受信された占有拒否応答によって示されるデータ制御装置である競合データ制御装置の優先順位と自データ制御装置の優先順位との比較に基づいて、占有の変更先となるべき優先データ制御装置を特定し、自データ制御装置から前記特定された優先データ制御装置への変更を示す第１の占有変更を送信すると共に、前記優先データ制御装置を示すように前記占有受付情報を更新し、
   前記連携サービス手段は、第２の占有変更を受信すると、前記第２の占有変更によって示される変更前のデータ制御装置と前記占有受付情報によって示されるデータ制御装置とが一致する場合、前記第２の占有変更によって示される変更後のデータ制御装置を示すように前記占有受付情報を更新すると共に、前記変更後のデータ制御装置へ占有受諾応答を送信する
   ことを特徴とする請求項２に記載のデータ制御装置。
5. 前記連携マスタ手段は、前記第１の占有要求に対して他の全てのデータ制御装置から占有許諾応答又は占有拒否応答が受信された後、
   自データ制御装置及び前記各競合データ制御装置がそれぞれ自分以外のデータ制御装置を占有しているか否かを、受信された占有許諾応答又は占有拒否応答に基づいて判断し、
   自分以外のデータ制御装置を占有していない状態の前記複数のデータ制御装置を前記優先順位で並べ、さらにその高位に、自分以外のデータ制御装置を占有している状態の前記複数のデータ制御装置を前記優先順位で並べて定義される順位に従って、自データ制御装置よりも高位の競合データ制御装置を前記優先データ制御装置として特定する
   ことを特徴とする請求項４に記載のデータ制御装置。
6. 前記連携マスタ手段は、自らの占有を前記優先データ制御装置へ変更した後、変更前の自らの占有を再度試みる
   ことを特徴とする請求項４に記載のデータ制御装置。
7. 前記連携マスタ手段、及び前記連携サービス手段は、送信されるデータの多寡、再送信か否か、送信されるデータが応答か否かのうちの少なくとも一つに応じて、他のデータ制御装置との通信に用いる通信プロトコルを変更する
   ことを特徴とする請求項１に記載のデータ制御装置。
8. 前記データ制御装置は、さらに、
   データ受信の有無を所定時間監視することによって他のデータ制御装置の故障を検出するサーバ状態管理手段を備え、
   前記連携マスタ手段は、故障と検出されたデータ制御装置を除外して、前記占有の成否を判断する
   ことを特徴とする請求項１に記載のデータ制御装置。
9. 前記データ制御装置は、さらに、
   特定の動作モードにおいて一つ以上のアクセス要求を蓄積し、前記動作モードが解除されるとき、前記アクセス要求を蓄積された順に取り出して自らのデータベースに対して発行する保留制御手段を備え、
   前記連携サービス手段は、前記動作モードにおいて、前記第２のアクセス要求を自らのデータベースに対して発行する代わりに前記保留制御手段に蓄積する
   ことを特徴とする請求項１に記載のデータ制御装置。
10. 前記データ制御装置は、前記複数のデータ制御装置のみを接続する専用ネットワークへの接続手段を備える
    ことを特徴とする請求項１に記載のデータ制御装置。
11. データの同期が維持されるべき複数のデータベースを制御するデータ制御システムであって、
    前記複数のデータベースそれぞれに対応して請求項１に記載のデータ制御装置を備える
    ことを特徴とするデータ制御システム。
12. データの同期が維持されるべき複数のデータベースにそれぞれ対応する複数のデータ制御装置の一つにおいて用いられるデータ制御方法であって、
    クライアントから発行された第１のアクセス要求を受信すると、自らのデータベースのみで前記第１のアクセス要求を実行したとすれば他のデータベースとのデータの同期が維持されるか否かを判断する要求判断ステップと、
    肯定判断された場合、自らのデータベースに対して前記第１のアクセス要求を発行する単独アクセスステップと、
    否定判断された場合、他の全てのデータ制御装置の占有を試み、前記占有に成功した場合、他の全てのデータ制御装置へ前記第１のアクセス要求を転送すると共に、自らのデータベースに対して前記第１のアクセス要求を発行する連携マスタステップと、
    他のデータ制御装置から転送された第２のアクセス要求を受信すると、自らのデータベースに対して前記第２のアクセス要求を発行する連携サービスステップと
    を含むことを特徴とするデータ制御方法。
13. データの同期が維持されるべき複数のデータベースにそれぞれ対応する複数のデータ制御装置の一つを動作させるためのコンピュータ実行可能なプログラムであって、
    クライアントから発行された第１のアクセス要求を受信すると、自らのデータベースのみで前記第１のアクセス要求を実行したとすれば他のデータベースとのデータの同期が維持されるか否かを判断する要求判断ステップと、
    肯定判断された場合、自らのデータベースに対して前記第１のアクセス要求を発行する単独アクセスステップと、
    否定判断された場合、他の全てのデータ制御装置の占有を試み、前記占有に成功した場合、他の全てのデータ制御装置へ前記第１のアクセス要求を転送すると共に、自らのデータベースに対して前記第１のアクセス要求を発行する連携マスタステップと、
    他のデータ制御装置から転送された第２のアクセス要求を受信すると、自らのデータベースに対して前記第２のアクセス要求を発行する連携サービスステップと
    をコンピュータに実行させることを特徴とするプログラム。
14. 請求項１３に記載のプログラムを記憶していることを特徴とする、コンピュータ読み取り可能な記録媒体。

Images