(57)【要約】【課題】ＤＢシステムにおいてデータ要求信号に対する応答の即応性を改善すること。【解決手段】リソース状態通知・通知情報管理機能部１３が、他のＤＢサーバから通知されたリソースの利用状況情報とデータの同期状態情報を管理し、要求信号中継機能部１５は、受信したデータ要求信号がデータの参照要求の場合、自身のＤＢサーバ１がデータ同期中のＳｌａｖｅ状態であれば、他のＤＢサーバのリソースの利用状況情報及びデータの同期状態情報を参照して余剰リソース量の多いデータ同期済みのＤＢサーバへプロキシする。【選択図】図１
2016051256.tif 000002
【特許請求の範囲】
【請求項１】
Ｍａｓｔｅｒ−Ｓｌａｖｅ構成のＤＢシステムにおいて、
前記ＤＢシステムを構成するＤＢサーバは、
他のＤＢサーバから通知されたリソースの利用状況情報とデータの同期状態情報を記憶手段に記憶して管理する第１の管理手段と、
受信したデータ要求信号の要求種別を判定する判定手段と、
前記データ要求信号がデータの参照要求の場合、自身のＤＢサーバがデータ同期中のＳｌａｖｅ状態であれば、前記リソースの利用状況情報及び前記データの同期状態情報を参照して余剰リソース量の多いデータ同期済みのＤＢサーバへ前記データ要求信号を転送し、転送先のＤＢサーバでの処理結果を自身のＤＢサーバを介して要求元へ返信する中継手段と、
を有することを特徴とするＤＢシステム。
【請求項２】
前記中継手段は、
前記余剰リソース量が閾値以上の場合に前記データ要求信号を転送することを特徴とする請求項１に記載のＤＢシステム。
【請求項３】
自身のＤＢサーバがＭａｓｔｅｒであるかＳｌａｖｅであるかのＭａｓｔｅｒ／Ｓｌａｖｅ状態を管理する第２の管理手段と、
自身のＤＢサーバが他のＤＢサーバとの間でデータを同期済みであるか同期済みでないかの同期状態を管理する第３の管理手段と、
自身のＤＢサーバに係るリソースの利用状況を管理する第４の管理手段と、を更に有し、
前記第１の管理手段は、
前記Ｍａｓｔｅｒ／Ｓｌａｖｅ状態と前記同期状態と前記リソースの利用状況とを含むリソース状態情報を他のＤＢサーバへ通知し、他のＤＢサーバから通知されたリソース状態情報を管理することを特徴とする請求項１又は２に記載のＤＢシステム。
【請求項４】
Ｍａｓｔｅｒ−Ｓｌａｖｅ構成のＤＢシステムで行うデータ要求信号のプロキシ方法において、
前記ＤＢシステムを構成するＤＢサーバは、
他のＤＢサーバから通知されたリソースの利用状況情報とデータの同期状態情報を記憶手段に記憶して管理する管理ステップと、
受信したデータ要求信号の要求種別を判定する判定ステップと、
前記データ要求信号がデータの参照要求の場合、自身のＤＢサーバがデータ同期中のＳｌａｖｅ状態であれば、前記リソースの利用状況情報及び前記データの同期状態情報を参照して余剰リソース量の多いデータ同期済みのＤＢサーバへ前記データ要求信号を転送し、転送先のＤＢサーバでの処理結果を自身のＤＢサーバを介して要求元へ返信する中継ステップと、
を有することを特徴とするデータ要求信号のプロキシ方法。
【請求項５】
Ｍａｓｔｅｒ−Ｓｌａｖｅ構成のＤＢシステムで行うデータ要求信号のプロキシ方法において、
前記ＤＢシステムを構成するＤＢサーバは、
受信したデータ要求信号の要求種別を判定する判定ステップと、
他のＤＢサーバに対してリソースの利用状況情報とデータの同期状態情報を通知することを要求し、通知されたリソースの利用状況情報とデータの同期状態情報を記憶手段に記憶して管理する管理ステップと、
前記データ要求信号がデータの参照要求の場合、自身のＤＢサーバがデータ同期中のＳｌａｖｅ状態であれば、前記リソースの利用状況情報及び前記データの同期状態情報を参照して余剰リソース量の多いデータ同期済みのＤＢサーバへ前記データ要求信号を転送し、転送先のＤＢサーバでの処理結果を自身のＤＢサーバを介して要求元へ返信する中継ステップと、
を有することを特徴とするデータ要求信号のプロキシ方法。
【請求項６】
前記中継ステップは、
前記余剰リソース量が閾値以上の場合に前記データ要求信号を転送することを特徴とする請求項４又は５に記載のデータ要求信号のプロキシ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ要求信号をプロキシする技術に関する。
【背景技術】
【０００２】
現在、Ｍａｓｔｅｒ−Ｓｌａｖｅ構成を備えたＤＢシステムが存在する。２つ以上のＤＢサーバを備え、１つのＤＢサーバをＭａｓｔｅｒとし、それ以外のＤＢサーバをＳｌａｖｅとして動作させ、全てのＤＢサーバ間でデータを同期させて運用する。
【０００３】
このＤＢシステムには、高可用性を実現するため、障害の発生したＤＢサーバを自律的に復旧させる機能が具備されている。例えば、ＭａｓｔｅｒのＤＢサーバで障害が検知された場合、Ｍａｓｔｅｒ−Ｓｌａｖｅ交代を行い、新ＭａｓｔｅｒのＤＢサーバではサービスを継続しつつ、旧ＭａｓｔｅｒのＤＢサーバでは、自身のデータを破棄し、最新のデータを他のＤＢサーバから取得することにより、データを同期する。
【０００４】
ここで、データ同期中の場合、同期済みでないＤＢサーバ、すなわち、最新のデータを保持していないＤＢサーバがＤＢシステムに一定期間存在することになる。それゆえ、データの要求信号を受信した場合、同期済みでないＤＢサーバのデータの参照又は更新をさせないことが求められる。
【０００５】
それを実現するため、データ要求信号を受信した場合、自身のＤＢサーバがデータ同期中であれば、「自身のデータは同期中であるため他のＤＢサーバへリダイレクトして下さい」というリダイレクト要求（要求先の変更要求）を要求元へ返信していた。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−２４９２２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、リダイレクト要求を要求元へ返信するため、要求元がリダイレクト機能を具備していない場合は適用できない。そこで、同期済みである他のＤＢサーバへプロキシ（中継）する方法も考えられる。具体的には、受信したデータ要求信号を他のＤＢサーバへ転送し、当該他のＤＢサーバでの処理結果を自身を介して要求元へ返信する。しかし、ＤＢサーバ間ではデータの同期処理が随時実施され、プロキシ時にデータ要求信号が通過するネットワークリソースはデータ同期処理で利用中のネットワークリソースと同一である可能性が高いため、データ要求信号を受信してから要求元へ返信するまでの応答時間に遅延が発生してしまい、即応性が求められる要求の場合は致命的となる。
【０００８】
本発明は、上記事情を鑑みてなされたものであり、データ要求信号に対する応答の即応性を改善することを目的とする。
【課題を解決するための手段】
【０００９】
以上の課題を解決するため、請求項１に記載のＤＢシステムは、Ｍａｓｔｅｒ−Ｓｌａｖｅ構成のＤＢシステムにおいて、前記ＤＢシステムを構成するＤＢサーバは、他のＤＢサーバから通知されたリソースの利用状況情報とデータの同期状態情報を記憶手段に記憶して管理する第１の管理手段と、受信したデータ要求信号の要求種別を判定する判定手段と、前記データ要求信号がデータの参照要求の場合、自身のＤＢサーバがデータ同期中のＳｌａｖｅ状態であれば、前記リソースの利用状況情報及び前記データの同期状態情報を参照して余剰リソース量の多いデータ同期済みのＤＢサーバへ前記データ要求信号を転送し、転送先のＤＢサーバでの処理結果を自身のＤＢサーバを介して要求元へ返信する中継手段と、を有することを要旨とする。
【００１０】
本発明によれば、他のＤＢサーバから通知されたリソースの利用状況情報とデータの同期状態情報を管理し、受信したデータ要求信号がデータの参照要求の場合、自身のＤＢサーバがデータ同期中のＳｌａｖｅ状態であれば、他のＤＢサーバのリソースの利用状況情報及びデータの同期状態情報を参照して余剰リソース量の多いデータ同期済みのＤＢサーバへデータ要求信号をプロキシする（データ要求信号を転送し、転送先のＤＢサーバでの処理結果を自身のＤＢサーバを介して要求元へ返信）ため、データ要求信号に対する応答の即応性を向上できる。
【００１１】
請求項２に記載のＤＢシステムは、請求項１に記載のＤＢシステムにおいて、前記中継手段は、前記余剰リソース量が閾値以上の場合に前記データ要求信号を転送することを要旨とする。
【００１２】
請求項３に記載のＤＢシステムは、請求項１又は２に記載のＤＢシステムにおいて、自身のＤＢサーバがＭａｓｔｅｒであるかＳｌａｖｅであるかのＭａｓｔｅｒ／Ｓｌａｖｅ状態を管理する第２の管理手段と、自身のＤＢサーバが他のＤＢサーバとの間でデータを同期済みであるか同期済みでないかの同期状態を管理する第３の管理手段と、自身のＤＢサーバに係るリソースの利用状況を管理する第４の管理手段と、を更に有し、前記第１の管理手段は、前記Ｍａｓｔｅｒ／Ｓｌａｖｅ状態と前記同期状態と前記リソースの利用状況とを含むリソース状態情報を他のＤＢサーバへ通知し、他のＤＢサーバから通知されたリソース状態情報を管理することを要旨とする。
【００１３】
請求項４に記載のデータ要求信号のプロキシ方法は、Ｍａｓｔｅｒ−Ｓｌａｖｅ構成のＤＢシステムで行うデータ要求信号プロキシ方法において、前記ＤＢシステムを構成するＤＢサーバは、他のＤＢサーバから通知されたリソースの利用状況情報とデータの同期状態情報を記憶手段に記憶して管理する管理ステップと、受信したデータ要求信号の要求種別を判定する判定ステップと、前記データ要求信号がデータの参照要求の場合、自身のＤＢサーバがデータ同期中のＳｌａｖｅ状態であれば、前記リソースの利用状況情報及び前記データの同期状態情報を参照して余剰リソース量の多いデータ同期済みのＤＢサーバへ前記データ要求信号を転送し、転送先のＤＢサーバでの処理結果を自身のＤＢサーバを介して要求元へ返信する中継ステップと、を有することを要旨とする。
【００１４】
請求項５に記載のデータ要求信号のプロキシ方法は、Ｍａｓｔｅｒ−Ｓｌａｖｅ構成のＤＢシステムで行うデータ要求信号プロキシ方法において、前記ＤＢシステムを構成するＤＢサーバは、受信したデータ要求信号の要求種別を判定する判定ステップと、他のＤＢサーバに対してリソースの利用状況情報とデータの同期状態情報を通知することを要求し、通知されたリソースの利用状況情報とデータの同期状態情報を記憶手段に記憶して管理する管理ステップと、前記データ要求信号がデータの参照要求の場合、自身のＤＢサーバがデータ同期中のＳｌａｖｅ状態であれば、前記リソースの利用状況情報及び前記データの同期状態情報を参照して余剰リソース量の多いデータ同期済みのＤＢサーバへ前記データ要求信号を転送し、転送先のＤＢサーバでの処理結果を自身のＤＢサーバを介して要求元へ返信する中継ステップと、を有することを要旨とする。
【００１５】
請求項６に記載のデータ要求信号のプロキシ方法は、請求項４又は５に記載のデータ要求信号プロキシ方法において、前記中継ステップは、前記余剰リソース量が閾値以上の場合に前記データ要求信号を転送することを要旨とする。
【発明の効果】
【００１６】
本発明によれば、データ要求信号に対する応答の即応性を向上できる。
【図面の簡単な説明】
【００１７】
【図１】ＤＢサーバの機能ブロック構成を示す図である。
【図２】Ｍａｓｔｅｒ／Ｓｌａｖｅ状態・同期状態管理機能部の機能を説明するための図である。
【図３】リソース利用状況管理機能部の機能を説明するための図である。
【図４】リソース状態通知・通知情報管理機能部の機能を説明するための図である。
【図５】要求信号種別判定機能部の機能を説明するための図である。
【図６】リソース状態の管理処理フローを示す図である。
【図７】リソース状態の収集イメージを示す図である。
【図８】データ要求信号のプロキシ処理フローを示す図である。
【図９】プロキシ処理の動作イメージを示す図である。
【発明を実施するための形態】
【００１８】
本発明は、同期済みでないＤＢサーバ（正確にはデータ同期中かつＳｌａｖｅ状態のＤＢサーバ）がデータ要求信号を受信した場合、リソースに余裕がある他のＤＢサーバへプロキシすることにより、即応性を向上させるようにする。以下、本発明を実施する一実施の形態について図面を用いて説明する。
【００１９】
図１は、本実施の形態に係るＤＢサーバ１の機能ブロック構成を示す図である。このＤＢサーバ１は、Ｍａｓｔｅｒ／Ｓｌａｖｅ状態・同期状態管理機能部１１と、リソース利用状況管理機能部１２と、リソース状態通知・通知情報管理機能部１３と、要求信号種別判定機能部１４と、要求信号中継機能部１５と、を備えて構成される。これらの各機能部は、ＤＢサーバ１の内部で通信可能に接続されている。以下、各機能部の機能について説明する。
【００２０】
Ｍａｓｔｅｒ／Ｓｌａｖｅ状態・同期状態管理機能部１１は、図２に示すように、自身のＤＢサーバ１が、ＭａｓｔｅｒであるかＳｌａｖｅであるかのＭａｓｔｅｒ／Ｓｌａｖｅ状態と、他のＤＢサーバとの間でデータを同期済みであるか同期済みでないかの同期状態とをデータ記憶部に記憶して管理するように構成されている。Ｍａｓｔｅｒとはデータの原本を保持するＤＢサーバであり、Ｓｌａｖｅとはその複製を保持するＤＢサーバである。
【００２１】
なお、Ｍａｓｔｅｒであるか否かは、前述のＭａｓｔｅｒ−Ｓｌａｖｅ交代等、ＤＢシステムを構成する他のＤＢサーバとの連携処理に基づき設定される。また、同期済みであるか否かは、自身のＤＢサーバ１が他のＤＢサーバの保持するデータと同じデータを保持するに至ったタイミングに基づき判別される。これらは既存技術を用いて実現可能である。
【００２２】
リソース利用状況管理機能部１２は、図３に示すように、自身のＤＢサーバ１のリソースの利用状況を管理するように構成されている。具体的には、ＤＢサーバ１を構成するＣＰＵ、メモリ、ＨＤＤ、ネットワークインタフェース等の使用率や未使用率を管理する。ＤＢサーバ１のＯＳで管理しているシステム情報を利用してもよい。なお、上記のリソースは例であり、プロセス数、プロセスの稼働状況等を用いてもよい。
【００２３】
リソース状態通知・通知情報管理機能部１３は、図４に示すように、他のＤＢサーバとの間で自身のＤＢサーバ１のリソース状態情報を通知し、他のＤＢサーバから通知されたリソース状態情報をデータ記憶部に記憶して管理するように構成されている。リソース状態情報には、Ｍａｓｔｅｒ／Ｓｌａｖｅ状態、同期状態、リソース利用状況の各情報が含まれる。
【００２４】
要求信号種別判定機能部１４は、図５に示すように、受信したデータ要求信号の要求種別を判定するように構成されている。具体的には、データ要求信号に含まれる要求種別（参照要求／更新要求）を参照し、そのデータ要求信号がデータの参照要求であるかデータの更新要求であるかを判定する。
【００２５】
要求信号中継機能部１５は、自身のＤＢサーバ１のＭａｓｔｅｒ／Ｓｌａｖｅ状態、同期状態、リソース利用状況、他のＤＢサーバのリソース状態（Ｍａｓｔｅｒ／Ｓｌａｖｅ状態、同期状態、リソース利用状況）を参照し、同期済み、かつリソースに余裕のある他のＤＢサーバへプロキシするように構成されている。プロキシするとは、データ要求信号を一旦受け付けて他のＤＢサーバへ転送し、当該他のＤＢサーバでの処理結果を自身のＤＢサーバ１を介して要求元へ返信することをいう。
【００２６】
以上、ＤＢサーバ１の機能を説明した。なお、これらの各機能部は主に同期済みでないＤＢサーバが保持するが、ＤＢシステムを構成するいずれのＤＢサーバもデータ同期中のＳｌａｖｅ状態に成り得るため、全てのＤＢサーバに実装される。なお、ＤＢサーバ１は、他のＤＢデータとデータ同期するための機能等、他の機能部を備えているが、そのような既存の機能部についての説明は省略する。
【００２７】
次に、ＤＢサーバ１の動作を説明する。最初に、リソース状態の管理方法を説明する。図６は、リソース状態の管理処理フローを示す図である。
【００２８】
まず、ステップＳ１０１において、Ｍａｓｔｅｒ／Ｓｌａｖｅ状態・同期状態管理機能部１１が、データ記憶部からＤＢサーバ１における現在のＭａｓｔｅｒ／Ｓｌａｖｅ状態と現在の同期状態を収集する。続いて、ステップＳ１０２において、リソース利用状況管理機能部１２が、ＯＳからＤＢサーバ１における現在のリソース利用状況を収集する。それらを収集した結果、ＤＢサーバ１がＳｌａｖｅ状態かつ同期済みであれば、例えば図７に示すようなリソース状態情報が収集される。
【００２９】
次に、ステップＳ１０３において、リソース状態通知・通知情報管理機能部１３が、ステップＳ１０１及びステップＳ１０２で収集した自身のＤＢサーバ１の現在のリソース状態を、ＤＢシステムを構成する他の全てのＤＢサーバへ通知する。その後、他のＤＢサーバから当該他のＤＢサーバのリソース状態が通知された場合、ステップＳ１０４において、リソース状態通知・通知情報管理機能部１３は、通知されたリソース状態を受信して送信元のＤＢサーバのＩＤに関連付けて管理する。
【００３０】
以降、ステップＳ１０１へ戻り、ステップＳ１０１〜ステップＳ１０４を定期的に繰り返し実行する。これにより、ＤＢシステムの各ＤＢサーバは、それぞれ、自身のＤＢサーバの最新のリソース状態と自身以外のＤＢサーバの最新のリソース状態を常に管理可能となる。
【００３１】
続いて、データ要求信号のプロキシ方法を説明する。図８は、データ要求信号のプロキシ処理フローを示す図である。
【００３２】
まず、任意のサーバからデータ要求信号を受信すると、ステップＳ２０１において、要求信号種別判定機能部１４が、そのデータ要求信号に含まれるデータの要求種別から参照要求であるか更新要求であるかを判定する。参照要求の場合はステップＳ２０２へ進み、更新要求の場合はステップＳ２０６へ進む。
【００３３】
次に、ステップＳ２０２において、要求信号中継機能部１５は、Ｍａｓｔｅｒ／Ｓｌａｖｅ状態・同期状態管理機能部１１から自身のＤＢサーバ１の同期状態を取得し、現在データ同期中であるかを判定する。データ同期中の場合はステップＳ２０３へ進み、データ同期済みの場合はステップＳ２０５へ進む。
【００３４】
ステップＳ２０３では、自身のＤＢサーバがデータ同期中であるため、要求信号中継機能部１５は、リソース状態通知・通知情報管理機能部１３から他の全てのＤＢサーバの各リソース状態を参照し、同期済み、かつリソースに余裕があるＤＢサーバへデータ要求信号を転送する。
【００３５】
例えば、同期済みのＤＢサーバが２つある場合、ＣＰＵリソースやネットワークリソースの使用率が低いＤＢサーバへ転送する。その２つのＤＢサーバがＭａｓｔｅｒとＳｌａｖｅであれば、一般的にはＭａｓｔｅｒの方が高使用率のため、ＳｌａｖｅのＤＢサーバへ転送することになる。
【００３６】
そして、データ要求信号を転送した後、指定された参照要求に基づき対象データの複製が転送先のＤＢサーバから送信されると、ステップＳ２０４において、要求信号中継機能部１５は、その対象データの複製を受け取り、要求元のサーバへ返信する。
【００３７】
一方、ステップＳ２０５では、自身のＤＢサーバ１が既にデータ同期済みであるため、要求信号中継機能部１５は、他のＤＢサーバへデータ要求信号を転送することなく、そのデータ要求信号で指定された参照要求に基づき対象データの複製を自身のＤＢサーバ１から取得し、要求元のサーバへ返信する。
【００３８】
また、ステップＳ２０６では、データの要求種別が更新要求であり、データの原本を更新する必要があるため、要求信号中継機能部１５は、他のＤＢサーバのリソース状態に関係なく、データ要求信号をＭａｓｔｅｒのＤＢサーバへ転送する。その後、ＭａｓｔｅｒのＤＢサーバにおいて指定された更新要求に基づき対象データの更新が完了すると、ステップＳ２０７において、その更新完了応答を受け取り、要求元のサーバへ返信する。
【００３９】
以上、ＤＢサーバ１の動作を説明した。ここで、図８で説明したデータ要求信号のプロキシ方法に基づく動作イメージを説明する。図９は、プロキシ処理の動作イメージを示す図である。１つのＭａｓｔｅｒと２つのＳｌａｖｅからなり、一方のＳｌａｖｅのＤＢサーバ１ＳａはＭａｓｔｅｒのＤＢサーバ１Ｍとの間でデータ同期処理を実行中、他方のＳｌａｖｅのＤＢサーバ１Ｓｂはデータ同期済みとする。
【００４０】
まず、要求元サーバ３は、ＤＢシステムの複数のＤＢサーバ１のうちいずれがＭａｓｔｅｒであるかを知らないため、Ｍａｓｔｅｒと想定してデータ要求信号をＳｌａｖｅのＤＢサーバ１Ｓａへ送信する（ステップＳ３０１）。
【００４１】
次に、ＳｌａｖｅのＤＢサーバ１Ｓａは、そのデータ要求信号を一旦受け付けて要求種別を判定し、その判定結果等に基づきプロキシ先を決定する（ステップＳ３０２）。具体的には、図８の処理フローに対応するプロキシ先決定論理情報を保持しておき、その情報に基づきプロキシ先を決定する。つまり、要求元サーバ３からの要求がデータの参照要求である場合、自身のＤＢサーバ１Ｓａはデータ同期中であるため、「同期済みで、かつリソースに余裕のあるＤＢサーバ」をプロキシ先として決定（経路決定）する。具体的には、他の２つのＤＢサーバ１Ｍ，１Ｓｂのリソース状態を参照し、リソース使用率の低いＳｌａｖｅのＤＢサーバ１Ｓｂをプロキシ先に決定する。一方、参照要求であれば、「リソースの状況に関係なくＭａｓｔｅｒ（のＤＢサーバ１Ｍ）」をプロキシ先とする。
【００４２】
その後、ＳｌａｖｅのＤＢサーバ１Ｓａは、決定されたＤＢサーバ１に対してデータ要求信号をプロキシ（転送）し、プロキシ先での処理結果を要求元サーバ３へ返信する（ステップＳ３０３）。具体的には、データの参照要求であればデータ要求信号をＳｌａｖｅのＤＢサーバ１Ｓｂへプロキシし、そのＤＢサーバ１Ｓｂから送信された対象データの複製を要求元サーバ３へ返信する（ステップＳ３０３ａ）。一方、データの更新要求であればデータ要求信号をＭａｓｔｅｒのＤＢサーバ１Ｍへプロキシし、そのＤＢサーバ１Ｍから送信された対象データの更新完了応答を要求元サーバ３へ返信する（ステップＳ３０３ｂ）。
【００４３】
以上より、本実施の形態によれば、同期済みでないＳｌａｖｅのＤＢサーバ１Ｓａがデータの参照要求を受信した場合、ＤＢシステムを構成する他の全てのＤＢサーバ１Ｍ，１Ｓｂのうち、同期済み、かつリソースに余裕のあるＳｌａｖｅのＤＢサーバ１Ｓｂへプロキシするので、データ要求信号に対する応答の即応性を向上でき、データ要求信号を受信してから要求元サーバ３へ返信するまでの応答時間の遅延を極力小さくできる。要求元サーバ３に対してリダイレクト機能を機能上のシステム要件とする必要がなく、ＤＢシステムの利用上の汎用性を向上できる。要求種別がデータの更新要求である場合はリソース利用状況によらずプロキシ先が一意に定まってしまうが、データ要求信号に占める参照要求の割合が大きい場合に本発明の効果が発揮される。
【００４４】
なお、本実施の形態では、各ＤＢサーバの互いのリソース状態を予め定期的に通知しておく例を説明したが、リソース状態の通知処理とデータ要求信号のプロキシ処理を並列に実行してもよい。例えば、ステップＳ３０３の直前、すなわち、ステップＳ３０２でプロキシ先を決定する時に、他のＤＢサーバに対して現在のリソース状態を通知するように要求してもよい。
【００４５】
また、本実施の形態では、プロキシ先を決定する際に２つのＤＢサーバ間でのリソース状態を比較する例を説明したが、閾値を用いて決定してもよい。例えば、ＤＢシステムを構成するＤＢサーバが２つの場合も考えられるため、他方のＤＢサーバの余剰リソース量が閾値以上になるまで待機し、その余剰リソース量が閾値以上になったタイミングでデータ要求信号をプロキシしてもよい。
【００４６】
また、本実施の形態では、要求信号種別判定機能部１４と要求信号中継機能部１５とを各別の機能部で実現する例を説明したが、それら２つの機能部を１つの機能部で実現してもよい。また、Ｍａｓｔｅｒ／Ｓｌａｖｅ状態・同期状態管理機能部１１とリソース利用状況管理機能部１２とリソース状態通知・通知情報管理機能部１３を１つの機能部で実現してもよい。さらに、Ｍａｓｔｅｒ／Ｓｌａｖｅ状態・同期状態管理機能部１１で行う機能をＭａｓｔｅｒ／Ｓｌａｖｅ状態管理機能部と同期状態管理機能部との格別の機能部で実現してもよい。
【００４７】
最後に、本実施の形態で説明したＤＢサーバ１の処理をプログラムとして構築し、コンピュータにインストールして実行させることや、通信ネットワークを介して流通させることも可能である。
【符号の説明】
【００４８】
１…ＤＢサーバ
１１…Ｍａｓｔｅｒ／Ｓｌａｖｅ状態・同期状態管理機能部（第２、第３の管理手段）
１２…リソース利用状況管理機能部（第４の管理手段）
１３…リソース状態通知・通知情報管理機能部（第１の管理手段）
１４…要求信号種別判定機能部（判定手段）
１５…要求信号中継機能部（中継手段）
３…要求元サーバ
Ｓ１０１〜Ｓ１０４、Ｓ２０１〜Ｓ２０７、Ｓ３０１〜Ｓ３０３…ステップ
【図１】
2016051256.tif 000003
【図２】
2016051256.tif 000004
【図３】
2016051256.tif 000005
【図４】
2016051256.tif 000006
【図５】
2016051256.tif 000007
【図６】
2016051256.tif 000008
【図７】
2016051256.tif 000009
【図８】
2016051256.tif 000010
【図９】
2016051256.tif 000011