JP2016091518A

JP2016091518A - データベースシステム

Info

Publication number: JP2016091518A
Application number: JP2014229126A
Authority: JP
Inventors: 貴司水上; Takashi Mizukami
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2014-11-11
Filing date: 2014-11-11
Publication date: 2016-05-23
Anticipated expiration: 2034-11-11
Also published as: JP6413670B2

Abstract

【課題】輻輳状態からの早期、かつ、容易な復帰が可能であるデータベースサーバシステムを提供する。
【解決手段】サーバシステム１００は、処理サーバである、第１及び第２のＳＩＰサーバ１３０、１４０と、処理サーバとネットワークを介して接続された第１及び第２のＤＢサーバ１１０、１２０を備える。処理サーバは、処理情報の各々に優先サーバ情報を付与し、優先サーバ情報に基づいて処理情報及び同期要求をいずれかのＤＢサーバに送信する処理情報送信部を有する。第１及び第２のＤＢサーバは、処理サーバから送信された処理情報を受信して格納する受信格納部と、処理情報を同期要求に従って他のＤＢサーバに送信する送信部と、ＤＢサーバにおいて輻輳が発生しているか否かを判定する輻輳監視部と、を有する。処理サーバは、第１又は第２の輻輳監視部１１３、１２３が輻輳が発生しているとする輻輳判定を検知した場合に、同期要求の送信を停止する。
【選択図】図１

Description

本発明は、データベースシステムに関する。

近年、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｃｏｌ）電話システムが普及してきている。ＩＰ電話システムにおいては、３ＧＰＰＴＳ２３．２２８に示されているように、加入者（ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）端末）に関する情報を保持するデータベース（ＤＢ）サーバ（３ＧＰＰにおいてはＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒと定義されている）と、ＳＩＰの呼処理を行うＳＩＰサーバによって構成されるのが一般的である。

このようなＩＰ電話システムにおいては、ＳＩＰ端末が、自身のコンタクトアドレス (ＳＩＰ−ＵＲＩとＩＰアドレスの対)情報等の情報を、ＲＦＣ３２６１で定義されているＲＥＧＩＳＴＥＲメッセージのＣｏｎｔａｃｔヘッダに設定してＳＩＰサーバへ送信する。当該ＲＥＧＩＳＴＥＲメッセージを受信したＳＩＰサーバは、受信したＲＥＧＩＳＴＥＲメッセージのコンタクトアドレス情報を保持し、当該端末への着信時に、当該保持していたコンタクトアドレス情報に基づいて着信を行う。

ＩＰ電話システムにおいては、ＳＩＰサーバが受信したＲＥＧＩＳＴＥＲメッセージのＣｏｎｔａｃｔヘッダの情報を蓄積するデータベースサーバが置かれる。ＳＩＰサーバに障害が発生した場合、障害の復旧後に、ＳＩＰサーバは、データベースサーバからＣｏｎｔａｃｔヘッダの情報を取得する。それによって、復旧後すぐに（端末からのＲＥＧＩＳＴＥＲ情報の受信を待たずに）ＳＩＰ端末への着信が可能な状態が再構築される。

このようなデータベースを含むシステムの一例として、特許文献１には、情報を受信するマスターデータベースとマスターデータベース情報が複製されるレプリカデータベースを含み、データベースの輻輳時に同期処理を停止するシステムが開示されている。

特開２００８−３０５１５９号公報

特許文献１に開示されているシステム構成においては、輻輳時にマスターデータベースからレプリカデータベースへの書き込み処理は抑止されるが、マスターデータベースのデータ更新量は変わらない。従って、輻輳状態からの復帰に時間がかかる等の問題があった。

本発明は、上記した点に鑑みてなされたものであり、輻輳状態からの早期かつ容易な復帰が可能であるデータベースサーバシステムを提供することを目的とする。

本発明のサーバシステムは、通信処理を行う少なくとも１つの処理サーバと、当該処理サーバとネットワークを介して接続された第１のデータベースサーバと、当該少なくとも１つの処理サーバ及び当該第１のデータベースサーバとネットワークを介して接続された第２のデータベースサーバと、を備えたデータベースシステムであって、当該処理サーバは、当該通信処理に関連する処理情報の各々に送信先のデータベースサーバを指定する優先サーバ情報を付与し、当該優先サーバ情報に基づいて当該処理情報及び当該処理情報に係る同期要求を当該第１のデータベースサーバまたは当該第２のデータベースサーバに送信する処理情報送信部を有し、当該第１のデータベースサーバは、当該処理サーバから送信された当該処理情報を受信して格納する第１の受信格納部と、当該第１の受信格納部に格納された当該処理情報を当該同期要求に従って当該第２のデータベースサーバに送信する第１の送信部と、当該第１のデータベースサーバにおいて輻輳が発生しているか否かを判定する第１の輻輳監視部と、を有し、当該第２のデータベースサーバは、当該処理サーバから送信された当該処理情報を受信して格納する第２の受信格納部と、当該第２の受信格納部に格納された当該処理情報を当該同期要求に従って当該第１のデータベースサーバに送信する第２の送信部と、当該第２のデータベースサーバにおいて輻輳が発生しているか否かを判定する第２の輻輳監視部と、を有し、当該処理サーバは、当該第１の輻輳監視部または当該第２の輻輳監視部が輻輳が発生しているとする輻輳判定していることを検知した場合に、当該同期要求の送信を停止することを特徴とする。

また、本発明のサーバシステムは、ネットワークに接続され当該ネットワークから情報を受信する第１のデータベースサーバと、当該第１のデータベースサーバと当該ネットワークを介して接続され当該ネットワークから情報を受信する第２のデータベースサーバと、を備えたデータベースシステムであって、当該第１のデータベースサーバは、当該ネットワークから受信して更新した情報をその更新時刻とともに格納する第１の受信格納部と、当該第１の受信格納部に格納された情報を当該第２のデータベースサーバに送信する第１の送信部と、当該第１のデータベースサーバにおいて輻輳が発生しているか否かを判定する第１の輻輳監視部と、を有し、当該第２のデータベースサーバは、当該ネットワークから受信して更新した情報をその更新時刻と共に格納する第２の受信格納部と、当該第２の受信格納部に格納された情報を当該第１のデータベースサーバに送信する第２の送信部と、当該第２のデータベースサーバにおいて輻輳が発生しているか否かを判定する第２の輻輳監視部と、を有し、当該第１の送信部及び第２の送信部は、当該第１の輻輳監視部または当該第２の輻輳監視部が輻輳が発生しているとする輻輳判定をしていることを検知した際に当該第１及び第２のデータベースサーバへの当該情報の送信を停止し、当該第１の輻輳監視部または第２の輻輳監視部が輻輳が解消しているとする輻輳解消判定をしていることを検知した際に当該第１及び第２のデータベースへの情報の送信を再開し、当該第１及び第２の受信格納部は、当該第１または第２の輻輳監視部が当該輻輳判定をした時刻及び当該輻輳解消判定をした時刻を保持していることを特徴とする。

本発明の実施例であるサーバシステムを示すブロック図である。ＲＥＧＩＳＴＥＲ情報テーブルの一例を示す図である。同期状態テーブルの一例を示す図である。加入者端末データの一例を示す図である。図１のサーバシステムの動作の一例を示す図である。図１のサーバシステムの動作の一例を示す図である。図１のサーバシステムの動作の一例を示す図である。情報同期管理部の動作の一例を示すフローチャートである。情報同期管理部の動作の一例を示すフローチャートである。情報同期管理部の動作の一例を示すフローチャートである。輻輳監視部の動作の一例を示すフローチャートである。ＲＥＧＩＳＴＥＲ情報送受信部の動作の一例を示すフローチャートである。

以下に、本発明の１つの実施例であるデータベースサーバシステムについて、添付図面を参照しつつ説明する。図１は、本発明の１つの実施例のデータベースサーバシステムを示すブロック図である。なお、以下の説明においては、２つのデータベースサーバからなる冗長構成サーバシステムを例に説明する。

サーバシステム１００は、第１のデータベース（ＤＢ）サーバ１１０、第２のデータベース（ＤＢ）サーバ１２０、処理サーバとしての第１のＳＩＰサーバ１３０及び処理サーバとしての第２のＳＩＰサーバ１４０を含んでいる。第１のＤＢサーバ１１０と第２のＤＢサーバ１２０とは、互いに同様の構成を有しているサーバ装置である。

第１のＤＢサーバ１１０、第２のＤＢサーバ１２０、第１のＳＩＰサーバ１３０及び第２のＳＩＰサーバ１４０は、互いにＩＰネットワークによって接続されている。また、ＳＩＰサーバ１３０、１４０は、それぞれ複数のＩＰ電話端末等のＳＩＰ端末１５０に接続されている。

サーバシステム１００においては、ＳＩＰ端末１５０がＳＩＰサーバ１３０及び１４０へＲＥＧＩＳＴＥＲ情報を送信して更新要求をすると、ＳＩＰサーバがこのＲＥＧＩＳＴＥＲ情報を第１のＤＢサーバ１１０または第２のＤＢサーバ１２０のいずれかに送信する。第１のＤＢサーバ１１０及び第２のＤＢサーバ１２０は、受信したＲＥＧＩＳＴＥＲ情報を自サーバのデータベースに保存する。

そして、通常時にはＳＩＰサーバがＲＥＧＩＳＴＥＲ情報の送信にともなって送信する同期要求に基づいて、他ＤＢサーバのデータベースにも当該ＳＩＰサーバから受信したＲＥＧＩＳＴＥＲ情報を同期して保存する。そして、いずれかのＤＢサーバが輻輳状態に陥った場合には当該同期を停止する。

第１のＤＢサーバ１１０は、受信格納部としてのデータベース（ＤＢ）１１１、輻輳監視部１１３及び送信部としての情報同期管理部１１５を含んでいる。第２のＤＢサーバ１２０は、同様に、情報受信格納部としてのデータベース（ＤＢ）１２１、輻輳監視部１２３及び送信部としての情報同期管理部１２５を含んでいる。

データベース１１１及び１２１は、それぞれ、ＲＥＧＩＳＴＥＲ情報テーブルを含むＲＥＧＩＳＴＥＲ情報データベース（ＤＢ）１１１Ａ及び１２１Ａ及び同期状態テーブル１１１Ｂ、１２１Ｂを有している。ＲＥＧＩＳＴＥＲ情報テーブルは、図２に示すように、パブリックＵＲＩ、Ｃｏｎｔａｃｔ情報、ＳＩＰサーバホスト名及び情報更新日時を含んでいる。

パブリックＵＲＩは、ＳＩＰ端末を識別するためのＳＩＰ−ＵＲＩである。Ｃｏｎｔａｃｔ情報は、ＳＩＰ端末から送信されたＲＥＧＩＳＴＥＲに設定されていたＣｏｎｔａｃｔの情報である。ＳＩＰサーバホスト名は、ＳＩＰ端末を収容するＳＩＰサーバのホスト名である。情報更新日時は、このテーブルを更新した日時である。

また、同期状態テーブルは、図３に示すように、同期状態、及び同期開始日時及び同期停止日時を含んでいる。同期状態は、データベース１１１、１２１間のＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａの同期状態を示し、「同期中」、「同期停止中」及び「復帰処理中」のいずれかの値となる。

「同期中」とは、データベース１１１とデータベース１２１との間でＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａの同期がなされている状態を示す。また、「同期停止中」とは、データベース１１１とデータベース１２１との間のＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａの同期が停止されている状態を示す。また、「復帰処理中」とは、ＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａ間の同期を停止した後に、データベース１１１とデータベース１２１との間でＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａの同期がなされている状態に復帰するための更新処理中であることを示す。

同期開始日時とは、同期状態を「同期中」に変更した最後の日時を示す。また、同期停止日時とは、同期状態を「同期中」から「同期中」以外に変更した最後の日時を示す。なお、同期状態テーブルは、第１のＤＢサーバ１１０と第２のＤＢサーバ１２０との間で常に同期されている。

輻輳監視部１１３及び１２３は、それぞれ自サーバのＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）（図示せず）が輻輳状態か否かを監視する。輻輳監視部１１３及び１２３は、自サーバのＣＰＵが輻輳状態になると、輻輳判定をして自サーバまたは他ＤＢサーバの情報同期管理部１１５、１２５に輻輳通知を送信し、自サーバのＣＰＵの輻輳状態が解消すると、輻輳解消判定をして自サーバまたは他ＤＢサーバの情報同期管理部１１５、１２５に輻輳解除通知を送信する。

また、輻輳監視部１１３、１２３は、それぞれ他のＤＢサーバからの輻輳状態確認を受信すると、それに対して他サーバに自サーバが輻輳状態か否かを通知する。

情報同期管理部１１５、１２５は、ＲＥＧＩＳＴＥＲ情報データベース１１１Ａ及び１２１Ａの同期状態を管理する。情報同期管理部１１５、１２５は、自サーバの輻輳監視部１１３、１２３及び他サーバの輻輳監視部１１３、１２３から同期通知または同期解除通知を受信し、データベース１１１、１２１の同期状態テーブル１１１Ｂ、１２１Ｂを更新する。

また、情報同期管理部１１５、１２５は、自サーバまたは他ＤＢサーバが輻輳状態になり同期が停止し、その後同期が再開される際に、同期停止期間中に各々のデータベースに保存されたＲＥＧＩＳＴＥＲ情報を更新してＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ｂを同期状態に復帰させる。

ＳＩＰサーバ１３０及び１４０は、それぞれ処理情報送信部としてのＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１を有している。ＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１は、ＳＩＰ端末１５０の各々からＲＥＧＩＳＴＥＲ情報及びその更新要求を受信する。ＲＥＧＩＳＴＥＲ情報送受信部は、ＲＥＧＩＳＴＥＲ情報を受信すると、当該ＲＥＧＩＳＴＥＲ情報の各々について図４のような加入者端末データを作成し、これをＲＥＧＩＳＴＥＲ情報の各々に紐付ける。図４に示すように加入端末者データは各々のＳＩＰ端末のＳＩＰ−ＵＲＩ情報、及びＲＥＧＩＳＴＥＲ情報送受信部によって付される優先データベース（ＤＢ）サーバ情報が含まれている。

優先ＤＢサーバ情報とは、当該加入者端末情報が紐付けられたＲＥＧＩＳＴＥＲ情報が送信されるデータベースサーバを示す情報であり、本実施例では第１のＤＢサーバ１１０または第２のＤＢサーバ１２０となる。

ＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１は、受信したＲＥＧＩＳＴＥＲ情報を上記優先ＤＢサーバ情報に基づいて、第１のＤＢサーバまたは第２のＤＢサーバに送信する。また、ＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１は、ＲＥＧＩＳＴＥＲ情報の送信前等の任意のタイミングで送信先のＤＢサーバの同期状態テーブル１１１Ｂ及び１２１Ｂを参照する。

同期状態テーブルが「同期中」の場合には、ＲＥＧＩＳＴＥＲ情報を送信したＤＢサーバに対して、他のＤＢサーバのデータベース１１１、１２１内のＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａにも当該送信したＲＥＧＩＳＴＥＲ情報を同期保存するよう要求する同期要求を送信する。

また、ＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１は、同期状態テーブルが「同期停止中」または「復帰処理中」である場合には、他のデータベースサーバのＲＥＧＩＳＴＥＲ情報ＤＢ１１１Ａ、１２１Ａへ同期要求を送信しない。

以下に、図１、図５及び図６を参照しつつサーバシステム１００の情報更新動作の一例について説明する。以下の説明においては、第１のＳＩＰサーバ１３０のＲＥＧＩＳＴＥＲ情報送受信部１３１が全てのＲＥＧＩＳＴＥＲ情報について優先ＤＢサーバを第１のＤＢサーバ１１０とし、第２のＳＩＰサーバ１４０のＲＥＧＩＳＴＥＲ情報送受信部１４１が全てのＲＥＧＩＳＴＥＲ情報について優先ＤＢサーバを第２のＤＢサーバ１２０とする場合を例に説明する。

図５は、通常時、すなわち第１のＤＢサーバ１１０及び第２のＤＢサーバ１２０のいずれにおいても輻輳が発生していない場合の情報更新動作フローの一例である。図５に示すように、ＳＩＰサーバ１３０及び１４０のＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１は、それぞれ第１のＤＢサーバ１１０及び第２のＤＢサーバ１２０の状態を定期的に確認している。この確認は、第１のＤＢサーバ１１０または第２のＤＢサーバ１２０の同期状態テーブル１１１Ｂ、１２１Ｂを確認することで行われる。

上述のように、通常時であるので、同期状態テーブルの「同期状態」は「同期中」となっており、ＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１は、この確認において、第１のＤＢサーバ１１０及び第２のＤＢサーバ１２０のいずれにおいても輻輳が発生していないと判断する。

その場合、まず、ＳＩＰ端末がＲＥＧＩＳＴＥＲ情報及びその更新要求を第１のＳＩＰサーバ１３０に送信すると第１のＳＩＰサーバ１３０からの情報更新動作が開始され、ステップＳ５１において第１のＳＩＰサーバ１３０のＲＥＧＩＳＴＥＲ情報送受信部１３１がこれを受信する。その後、上述のように優先ＤＢサーバが第１のＤＢサーバ１１０とされているので、ステップＳ５２においてＲＥＧＩＳＴＥＲ情報及び同期要求が、優先ＤＢサーバである第１のＤＢサーバ１１０に送信される。

次にステップＳ５３において、第１のＤＢサーバ１１０がＲＥＧＩＳＴＥＲ情報及び同期要求を受信し、データベース１１１のＲＥＧＩＳＴＥＲ情報ＤＢ１１１Ａを更新する。その後、ステップＳ５４において、第１のＳＩＰサーバ１３０からの同期要求に従って、第１のＤＢサーバ１１０がＲＥＧＩＳＴＥＲ情報を第２のＤＢサーバ１２０に送信する。

次に、ステップＳ５５において、第２のＤＢサーバ１２０がＲＥＧＩＳＴＥＲ情報を受信し、データベース１２１のＲＥＧＩＳＴＥＲ情報テーブル１２１Ａを更新する。その後、ステップＳ５６において、第２のＤＢサーバ１２０がＲＥＧＩＳＴＥＲ情報の同期を完了した旨の同期完了通知を第１のＤＢサーバ１１０に送信する。

次に、ステップＳ５７において、第１のＤＢサーバ１１０が同期完了通知を受信する。その後、ステップＳ５８において、第１のＤＢサーバ１１０が更新完了通知を第１のＳＩＰサーバ１３０に送信する。

次に、ステップＳ５９において、第１のＳＩＰサーバ１３０が、更新完了通知を受信する。その後、ステップＳ５１０において、更新の完了を確認した第１のＳＩＰサーバ１３０は、更新の完了をＳＩＰ端末１５０に通知すべく、ＳＩＰ端末１５０にＲＥＧＩＳＴＥＲ応答(200 OKメッセージ)を送信して、第１のＳＩＰサーバ１３０からの情報更新動作が終了する。

第２のＳＩＰサーバ１４０からの情報更新動作も同様である。まず、ＳＩＰ端末がＲＥＧＩＳＴＥＲ情報及びその更新要求を第２のＳＩＰサーバ１４０に送信すると第２のＳＩＰサーバ１４０からの情報更新動作が開始され、ステップＳ５１１において第２のＳＩＰサーバ１４０のＲＥＧＩＳＴＥＲ情報送受信部１４１がこれを受信する。その後、上述のように優先ＤＢサーバが第２のＤＢサーバ１２０とされているので、ステップＳ５１２においてＲＥＧＩＳＴＥＲ情報及び同期要求が優先ＤＢサーバである第２のＤＢサーバ１２０に送信される。

次にステップＳ５１３において、第２のＤＢサーバ１２０がＲＥＧＩＳＴＥＲ情報及び同期要求を受信し、データベース１２１のＲＥＧＩＳＴＥＲ情報ＤＢ１２１Ａを更新する。その後、ステップＳ５１４において、第２のＳＩＰサーバ１４０からの同期要求に従って、第２のＤＢサーバ１２０がＲＥＧＩＳＴＥＲ情報を第１のＤＢサーバ１１０に送信する。

次に、ステップＳ５１５において、第１のＤＢサーバ１１０がＲＥＧＩＳＴＥＲ情報を受信し、データベース１１１のＲＥＧＩＳＴＥＲ情報ＤＢ１１１Ａを更新する。その後、ステップＳ５１６において、第１のＤＢサーバ１１０がＲＥＧＩＳＴＥＲ情報の同期を完了した旨の同期完了通知を第２のＤＢサーバ１２０に送信する。

次に、ステップＳ５１７において、第２のＤＢサーバ１２０が同期完了通知を受信する。その後、ステップＳ５１８において、第２のＤＢサーバ１２０が更新完了通知を第２のＳＩＰサーバ１４０に送信する。

次に、ステップＳ５１９において、第２のＳＩＰサーバ１４０が、更新完了通知を受信する。その後、ステップＳ５２０において、更新の完了を確認した第２のＳＩＰサーバ１４０は、更新の完了をＳＩＰ端末１５０に通知すべく、ＳＩＰ端末１５０にＲＥＧＩＳＴＥＲ応答(200 OKメッセージ)を送信して、第２のＳＩＰサーバ１４０からの情報更新動作が終了する。

図６は、輻輳時、すなわち第１のＤＢサーバ１１０及び第２のＤＢサーバの少なくともいずれかにおいて輻輳が発生している場合の情報更新動作フローの一例である。この例では、第１のＤＢサーバ１１０で輻輳が発生した場合を例に説明する。図６に示すように、ＳＩＰサーバ１３０及び１４０のＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１は、それぞれ第１のＤＢサーバ１１０及び第２のＤＢサーバ１２０の状態を定期的に確認している。

上述したように、この確認は、第１のＤＢサーバ１１０または第２のＤＢサーバ１２０の同期状態テーブル１１１Ｂ、１２１Ｂを確認することで行われる。

まず、ステップＳ６１において第１のＤＢサーバ１１０の輻輳監視部１１３が輻輳を検出し、輻輳判定を行い、その旨を情報同期管理部１１５に通知する。その後、ステップＳ６２において、情報同期管理部１１５が、同期状態テーブル１１１Ｂの「同期状態」を「同期停止中」に書き換える。なお、この際、上述のように、同期状態テーブルは各データベース間で同期されるので同期状態テーブル１２１Ｂの「同期状態」も「同期停止中」に書き換えられている。

同期状態テーブル１１１Ｂ、１２１Ｂの「同期状態」が「同期停止中」と書き換えられているので、ＲＥＧＩＳＴＥＲ情報送受信部１３１、１４１は、上記ＤＢサーバの状態の確認において、第１のＤＢサーバ１１０及び第２のＤＢサーバ１２０の少なくともいずれかに輻輳が発生していると判断する。

その場合、まず、ＳＩＰ端末がＲＥＧＩＳＴＥＲ情報及びその更新要求を第１のＳＩＰサーバ１３０に送信すると第１のＳＩＰサーバ１３０からの情報更新動作が開始され、ステップＳ６３において第１のＳＩＰサーバ１３０のＲＥＧＩＳＴＥＲ情報送受信部１３１がこれを受信する。その後、ステップＳ６４においてＲＥＧＩＳＴＥＲ情報のみが第１のＤＢサーバ１１０に送信される。すなわち、ＲＥＧＩＳＴＥＲ情報送受信部１３１は、同期状態テーブル１１１Ｂ、１２１Ｂの「同期状態」が「同期停止中」になっている場合には、同期要求を送信しない。

次にステップＳ６５において、第１のＤＢサーバ１１０がＲＥＧＩＳＴＥＲ情報を受信し、データベース１１１のＲＥＧＩＳＴＥＲ情報ＤＢ１１１Ａを更新する。その後、ステップＳ６６において、第１のＤＢサーバ１１０が更新完了通知を第１のＳＩＰサーバ１３０に送信する。

次に、ステップＳ６７において、第１のＳＩＰサーバ１３０が、更新完了通知を受信する。その後、ステップＳ６８において、更新の完了を確認した第１のＳＩＰサーバ１３０は、更新の完了をＳＩＰ端末１５０に通知すべく、ＳＩＰ端末１５０にＲＥＧＩＳＴＥＲ応答(200 OKメッセージ)を送信して、第１のＳＩＰサーバ１３０からの情報更新動作が終了する。

第２のＳＩＰサーバ１４０からの情報更新動作も同様である。まず、ＳＩＰ端末がＲＥＧＩＳＴＥＲ情報及びその更新要求を第２のＳＩＰサーバ１４０に送信すると第２のＳＩＰサーバ１４０からの情報更新動作が開始され、ステップＳ６９において第２のＳＩＰサーバ１４０のＲＥＧＩＳＴＥＲ情報送受信部１４１がこれを受信する。その後、ステップＳ６１０においてＲＥＧＩＳＴＥＲ情報のみが第２のＤＢサーバ１２０に送信される。すなわち、ＲＥＧＩＳＴＥＲ情報送信部１４１は、同期状態テーブル１１１Ｂ、１２１Ｂの「同期状態」が「同期停止中」になっている場合には、同期要求を送信しない。

次にステップＳ６１１において、第２のＤＢサーバ１２０がＲＥＧＩＳＴＥＲ情報を受信し、データベース１２１のＲＥＧＩＳＴＥＲ情報ＤＢ１２１Ａを更新する。その後、ステップＳ６１２において、第２のＤＢサーバ１２０が更新完了通知を第２のＳＩＰサーバ１４０に送信する。

次に、ステップＳ６１３において、第２のＳＩＰサーバ１４０が、更新完了通知を受信する。その後、ステップＳ６１４において、更新の完了を確認した第２のＳＩＰサーバ１４０は、更新の完了をＳＩＰ端末１５０に通知すべく、ＳＩＰ端末１５０にＲＥＧＩＳＴＥＲ応答(200 OKメッセージ)を送信して、第２のＳＩＰサーバ１４０からの情報更新動作が終了する。

上記図５及び図６の説明においては、第１のＳＩＰサーバ１３０の情報更新動作の後に、第２のＳＩＰサーバ１４０の情報更新動作が行われているように説明した。しかし、この動作の順序はＳＩＰサーバ１３０、１４０にＳＩＰ端末がＲＥＧＩＳＴＥＲ情報及びその更新要求を送信するタイミングによって変わるものであり、第２のＳＩＰサーバ１４０の動作が先になることもあるし、第１及び第２のＳＩＰサーバ１３０、１４０の動作が並列して行われることもあり得る。

次に、上記した第１のＤＢサーバにおける輻輳状態が解消した際の同期停止状態からの復帰動作の一例について、図１、図７を参照しつつ説明する。この例においては、輻輳状態が解消した後に第１のＳＩＰサーバ１３０がＤＢサーバの状態を確認する場合について説明する。

まず、輻輳中だった第１のＤＢサーバ１１０において輻輳状態が解消し、ステップＳ７１において輻輳監視部１１３が輻輳状態の解消を検出して輻輳解消判定をする。輻輳状態であった第１のＤＢサーバ１１０において輻輳状態の解消を検出すると、ステップＳ７２において、第１のＤＢサーバ１１０の情報同期管理部１１５が、第２のＤＢサーバ１２０に輻輳状態を確認する。

これは、第２のＤＢサーバ１２０においても、第２のＳＩＰサーバ１４０のＲＥＧＩＳＴＥＲ情報受信時のデータベース更新処理を実施しており、第２のＤＢサーバ１２０が輻輳中の場合は輻輳状態解除処理(データベースの同期)を見送るためである。

第２のＤＢサーバ１２０において輻輳状態が発生しておらず、輻輳監視部１２３が輻輳解消判定をしている場合、ステップＳ７３において、第２のＤＢサーバ１２０から「輻輳なし」を意味するメッセージ応答を受信する。その後、ＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａを第１のＤＢサーバ１１０と第２のＤＢサーバ１２０との間で同期するための処理を開始する。

すなわち、輻輳監視部１１３、１２３のいずれもが輻輳が発生していないとする輻輳解消判定をした際に、ＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａを同期するための処理を開始する。

まず、ステップＳ７４において、第１のＤＢサーバ１１０の同期状態テーブルの「同期状態」が「復帰処理中」に変更される。その後、ステップＳ７５において、第１のＤＢサーバ１１０が第２のＤＢサーバ１２０に同期状態テーブル情報を送信し、両ＤＢサーバにおいて同期状態テーブルが同期される。

ＳＩＰサーバは同期状態テーブルを周期的に参照しており、「同期状態」が「同期停止」以外の値になったことを検出すると、第１及び第２のＤＢサーバ１１０、１２０の両ＤＢサーバの輻輳状態が解消したものと判断する。すなわち、輻輳監視部１１３、１２３のいずれもが輻輳が発生していないとする輻輳解消判定をしたと判断する。

当該両ＤＢサーバの輻輳状態が解消したと判断すると、ＳＩＰサーバはＳＩＰ端末からのＲＥＧＩＳＴＥＲ情報及びその更新要求の受信後の優先ＤＢサーバへのＲＥＧＩＳＴＥＲ情報の送信時における同期要求の送信（図５参照）を再開する。すなわち、当該両ＤＢサーバの輻輳状態が解消したと判断すると、両ＤＢサーバ間におけるＲＥＧＩＳＴＥＲ情報の同期が再開される。

ステップＳ７５におけるテーブルの同期が終了すると、Ｓ７６において、第１のＤＢサーバ１１０は、第２のＤＢサーバ１２０へ向けて輻輳解除通知を送信し、第２のＤＢサーバ１２０がこれを受信する。この輻輳解除通知の送受信が完了すると、Ｓ７７、Ｓ７８において、両ＤＢサーバは、同期停止中に両ＤＢサーバ間で同期されずに一方のＤＢサーバのデータベースのみで更新されていたＲＥＧＩＳＴＥＲ情報を共有する同期処理を行う。すなわち、同期停止中に他ＤＢサーバにのみ蓄積されていた情報を自サーバのデータベースに反映する処理を行う。

第２のＤＢサーバ１２０は、ＲＥＧＩＳＴＥＲ情報の同期が完了すると、ステップＳ７９において、第１のＤＢサーバに向けて輻輳解除通知応答を送信する。

第１のＤＢサーバ１１０は、輻輳解除通知応答を受信するとステップＳ７１０において、自サーバの同期状態テーブルの「同期状態」を「同期中」に書き換える。その後、上記ステップＳ７５と同様に、ステップＳ７１１において、第１のＤＢサーバ１１０が第２のＤＢサーバ１２０に同期状態テーブル情報を送信し、両ＤＢサーバにおいて同期状態テーブルが同期される。

次に、上記システムの動作を実現するための情報同期管理部１１５、１２５の動作ルーチンの一例を図１及び図８乃至１０を参照して説明する。まず、ステップＳ８１において、自サーバの輻輳監視部１１３、１２３からの輻輳通知の有無を確認する。輻輳監視部１１３、１２３から輻輳が通知された場合、Ｓ８２において同期状態テーブルの「同期状態」の値を「同期停止状態」に、「同期停止日時」の値をステップＳ８２が実行された時刻に書き換え、他系ＤＢサーバのデータベースへ同期する。

上述したように、これ以降、情報同期状態テーブルを参照したＳＩＰサーバは同期要求を送信しないので、ＲＥＧＩＳＴＥＲ情報の更新時には優先ＤＢサーバのデータベースのみが更新される。これらが完了すると一定時間ウェイト後にステップＳ８１に戻る。

ステップＳ８１で自サーバの輻輳監視部１１３、１２３から輻輳通知がなかった場合、ステップＳ８３において、自サーバの輻輳監視部１１３、１２３からの輻輳解除通知の受信有無を確認する。輻輳解除通知を受信した場合、ステップＳ８４において、他系ＤＢサーバに輻輳状態を確認する。その後、ステップＳ８５において、他系ＤＢサーバが輻輳状態であるか否かが判定され、輻輳状態であると判定された場合、何もせず一定時間ウェイト後にステップＳ８１に戻る。ステップＳ８５において、他系ＤＢサーバが輻輳状態でないと判定された場合、ステップは図９のＳ９１に進み、ＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａの同期状態への復帰処理が開始される。

ステップＳ８３において、輻輳解除通知を受信していない場合には、ステップＳ８６において、他系ＤＢサーバから輻輳通知を受信したか否かが判定される。他系ＤＢサーバから輻輳解除通知が受信されていないと判定された場合には、一定のウェイト後にステップＳ８１に戻る。他系ＤＢサーバから輻輳解除通知が受信されていると判定された場合には、ステップは図１０のＳ１０１に進み、ＲＥＧＩＳＴＥＲ情報の同期状態への復帰処理が開始される。

ステップＳ８５において、他系ＤＢサーバが輻輳状態でないと判定された場合に開始されるＲＥＧＩＳＴＥＲ情報の同期状態への復帰処理について、図９を参照して以下に説明する。

まず、ステップＳ９１において、自サーバの情報同期状態テーブルの「同期状態」を「復帰処理中」に、「同期開始時刻」をステップＳ９１が実行された時刻に変更し、これを他系ＤＢサーバのデータベースへ同期する。上述したように、これ以降、情報同期状態テーブルを参照したＳＩＰサーバの命令よって、ＲＥＧＩＳＴＥＲ情報の更新時の同期動作が再開され、優先ＤＢサーバ及びそれ以外のＤＢサーバのＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａが更新される。

次に、ステップＳ９２において、他系ＤＢサーバにＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａの同期を促すように輻輳解除通知を送信する。その後、自他両系ＤＢサーバのＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａの同期処理が開始される。まず、ステップＳ９３において、同期状態テーブルの「同期状態」が「同期停止」に書き換えられた後に更新されたＲＥＧＩＳＴＥＲ情報を検索する。

ステップＳ９３の時点で、自他両系ＤＢサーバのＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａにおいて同期されていないＲＥＧＩＳＴＥＲ情報は、ＲＥＧＩＳＴＥＲ情報テーブルの「情報更新日時」が、同期状態テーブルの「同期停止日時」以降で、かつ「同期開始日時」以前である。よって、具体的には、ステップＳ９３において「情報更新日時」が「同期停止時刻」以降でかつ「同期開始時刻」以前のＲＥＧＩＳＴＥＲ情報を自サーバのデータベースから検索する。

その後、ステップＳ９４において、検索の結果として更新された情報が有ったか否かが判定される。ステップＳ９４において、更新された情報が有ったと判定された場合には、ステップＳ９５において、当該更新された情報の「情報更新日時」を同期開始時刻以降の時刻に設定し、ステップＳ９６において当該更新されたＲＥＧＩＳＴＥＲ情報を他系ＤＢサーバに送信して他系ＤＢサーバのＲＥＧＩＳＴＥＲ情報データベースを更新し当該情報を同期する。

「情報更新日時」が同期状態テーブルの「同期停止時刻」以降でかつ「同期開始時刻」以前のＲＥＧＩＳＴＥＲ情報がなくなるまで、ステップＳ９３−Ｓ９６を繰り返す。ステップ９４において、上記「同期停止時刻」以降でかつ「同期開始時刻」以前に更新されたＲＥＧＩＳＴＥＲ情報がなくなったと判定された場合、ステップＳ９７において、他系ＤＢサーバからの輻輳解除通知応答が受信されたか否かを判定する。輻輳解除通知応答がなく輻輳解除通知応答が受信されていないと判定された場合、ステップＳ９８において一定時間ウェイトする。

ステップＳ９７において、他系ＤＢサーバからの輻輳解除通知応答が受信されたと判定された場合には、ステップＳ９９において、情報同期状態テーブルの「同期状態」を「同期中」に書き換えて他系ＤＢサーバのデータベースへ同期し、復帰処理が終了する。

次に、ステップＳ８６において、他系ＤＢサーバから輻輳解除通知が受信されたと判定された場合に開始されるＲＥＧＩＳＴＥＲ情報の同期状態への復帰処理について、図１０を参照して以下に説明する。

ステップＳ８６において、他系ＤＢサーバから輻輳解除通知が受信されたと判定されると、図９を参照して説明したＲＥＧＩＳＴＥＲ情報の同期処理と同様の自他両系ＤＢサーバのＲＥＧＩＳＴＥＲ情報の同期処理が、ステップＳ１０１からＳ１０４において行われる。

まず、ステップＳ１０１において、同期状態テーブルの「同期状態」が「同期停止」に書き換えられた後に更新されたＲＥＧＩＳＴＥＲ情報を検索する。

ステップＳ１０１の時点で、自他両系ＤＢサーバのデータベースにおいて同期されていないＲＥＧＩＳＴＥＲ情報は、ＲＥＧＩＳＴＥＲ情報テーブルの「情報更新日時」が、同期状態テーブルの「同期停止日時」以降で、かつ「同期開始日時」以前のものである。よって、具体的には、ステップＳ１０１において「情報更新日時」が「同期停止時刻」以降でかつ「同期開始時刻」以前のＲＥＧＩＳＴＥＲ情報を自サーバのデータベースから検索する。

その後、ステップＳ１０２において、検索の結果として更新された情報が有ったか否かが判定される。ステップＳ１０２において、更新された情報が有ったと判定された場合には、ステップＳ１０３において、当該更新された情報の「情報更新日時」を同期開始時刻以降の時刻に設定し、ステップＳ１０４において当該更新されたＲＥＧＩＳＴＥＲ情報を他系ＤＢサーバに送信して他系ＤＢサーバのＲＥＧＩＳＴＥＲ情報データベース１１１Ａ、１２１Ａを更新し当該情報を同期する。

「情報更新日時」が同期状態テーブルの「同期停止時刻」以降でかつ「同期開始時刻」以前のＲＥＧＩＳＴＥＲ情報がなくなるまで、ステップＳ１０１−Ｓ１０４を繰り返す。ステップＳ１０２において、上記「同期停止時刻」以降でかつ「同期開始時刻」以前に更新されたＲＥＧＩＳＴＥＲ情報がなくなったと判定された場合、ステップＳ１０５において他系ＤＢサーバに輻輳解除通知応答を送信して、復帰処理が終了する。

以上のような動作で、情報同期管理が行われ得る。

次に、上記システムの動作を実現するための輻輳監視部の動作ルーチンの一例を図１１を参照して説明する。まず、Ｓ１１１において自サーバが輻輳状態であるかを判定する。輻輳状態は、例えば、ＣＰＵ状態を３秒間監視し、ＣＰＵ使用率の平均が７０％を超えた状態と定義する。ステップＳ１１１において、輻輳状態であると判定された場合には、ステップＳ１１２において、自サーバの情報同期管理部１１５、１２５へ、自サーバが輻輳状態であることを通知する輻輳通知を送信する。

輻輳通知の送信が終了すると、ステップＳ１１３において、他系ＤＢサーバからの輻輳状態確認を受信しているか否かを判定する。ステップＳ１１３において、輻輳状態確認を受信していると判定した場合には、ステップＳ１１４において、他系ＤＢサーバに「輻輳中」と応答する。

他系ＤＢサーバへの応答が終了するかまたはステップＳ１１３において輻輳状態確認が受信していないと判定した場合には、ステップＳ１１５において、自サーバの輻輳状態が解消したか否かが判定される。この判定においては、例えば、ＣＰＵの状態を３秒間監視し、ＣＰＵの使用率の平均が３０％を下回った状態をして輻輳状態が解消したと判定する。

ステップＳ１１５において、輻輳状態が解消されたと判定された場合には、ステップＳ１１６において、情報同期管理部１１５、１２５に輻輳解除通知を送信する。ステップＳ１１５において、輻輳状態が解消されていないと判定された場合には、処理はステップＳ１１３に戻る。

ステップＳ１１１において、自サーバが輻輳状態ではないと判定した場合、ステップＳ１１７において、他系ＤＢサーバから輻輳状態確認を受信したか否かが判定される。

ステップＳ１１７において、輻輳状態確認が受信されたと判定した場合、ステップＳ１１８において、他系ＤＢサーバに「輻輳無し」と応答し、ステップＳ１１１に戻る。ステップ１１７において、輻輳状態確認が受信されていないと判定した場合も、処理はステップＳ１１１に戻る。

以上のような動作によって、輻輳監視動作が行われ得る。

次に、上記システムの動作を実現するためのＲＥＧＩＳＴＥＲ情報送受信部の動作ルーチンの一例を図１２を参照して説明する。まず、ステップＳ１２１において、いずれかのＤＢサーバの情報同期状態テーブルを参照する。その後、ステップＳ１２２において、情報同期状態テーブルの「同期状態」が「同期停止中」か否かを判定する。

ステップＳ１２２において、「同期停止中」ではないと判定した場合、ステップＳ１２３においてＳＩＰ端末からＲＥＧＩＳＴＥＲ情報の更新要求が受信されているか否かが判定される。ステップＳ１２３において、ＲＥＧＩＳＴＥＲ情報の更新要求が受信されていると判定した場合、ステップＳ１２４において、優先ＤＢサーバにＲＥＧＩＳＴＥＲ情報及び同期要求を送信し、優先ＤＢサーバ及び他系ＤＢサーバの両系のＤＢサーバのデータベースを更新する。その後、ステップ１２５において、最後に同期状態テーブルを参照してから１秒以上経過したか否かを判定する。

ステップＳ１２３において、ＲＥＧＩＳＴＥＲ情報の更新要求が受信されていないと判定した場合、ステップＳ１２５において、最後に同期状態テーブルを参照してから１秒以上経過したか否かを判定する。ステップＳ１２５において、１秒以上経過していないと判定した場合、Ｓ１２６において一定時間のウェイトをした後ステップＳ１２３に戻る。ステップＳ１２５において、１秒以上経過したと判定した場合、処理はステップＳ１２１に戻る。

ステップＳ１２２において、「同期停止中」と判定した場合、Ｓ１２７において、ＳＩＰ端末からＲＥＧＩＳＴＥＲ情報の更新要求が受信されているか否かが判定される。ステップＳ１２７において、ＲＥＧＩＳＴＥＲ情報の更新要求が受信されていると判定した場合、ステップＳ１２８において、優先ＤＢサーバにＲＥＧＩＳＴＥＲ情報のみを送信し、優先ＤＢサーバのデータベースのみを更新する。その後、ステップＳ１２９において、最後に同期状態テーブルを参照してから１秒以上経過したか否かを判定する。

ステップＳ１２７において、ＲＥＧＩＳＴＥＲ情報の更新要求が受信されていないと判定した場合、ステップＳ１２９において、最後に同期状態テーブルを参照してから１秒以上経過したか否かを判定する。ステップＳ１２９において、１秒以上経過していないと判定した場合、Ｓ１２１０において一定時間のウェイトをした後ステップＳ１２７に戻る。ステップＳ１２９において、１秒以上経過したと判定した場合、処理はステップＳ１２１に戻る。

以上のような動作によって、情報の送受信及び情報更新動作が行われ得る。

このように、本発明のサーバシステム１００によれば、複数のデータベースサーバのいずれにも更新トランザクションがある環境において、データベースサーバが輻輳状態に陥った際に、予め設定された優先データベースサーバのみに対して更新が行われる。すなわち、輻輳状態に陥った際に、データベースサーバ間のＲＥＧＩＳＴＥＲ情報の同期が停止される。

これにより、データベースサーバの各々のデータ通信処理及びデータ更新処理を少なくすることができ、システム内のデータベースサーバの更なる輻輳を回避して、システムを輻輳状態から早期に復帰させることが可能である。

また、本発明のサーバシステム１００によれば、個々のＲＥＧＩＳＴＥＲ情報毎に優先データベースサーバが設定され、輻輳時にどのデータベースサーバにＲＥＧＩＳＴＥＲ情報の各々が保存されるかが決められている。さらに上記輻輳によって同期が停止した時刻及び開示した時刻を含むテーブルがデータベースサーバに記録される。

これにより、上記輻輳状態からの復帰時に、当該同期の停止時刻以後に更新された情報を容易に抽出可能となり、データベースサーバが自律的にデータベースサーバ間で情報が同期された状態に容易に復帰可能である。従って、輻輳状態が解除された際に、外部からの指令を必要とせずにスムーズに輻輳前の状態に同期状態に復帰することが可能である。

上記実施例においては、ＳＩＰサーバは、各々が受信したＲＥＧＩＳＴＥＲ情報に関するＲＥＧＩＳＴＥＲ情報テーブルにおいて、第１のＳＩＰサーバ１３０は第１のＤＢサーバ１１０を優先ＤＢサーバに、第２のＳＩＰサーバ１４０は第２のＤＢサーバ１２０を優先ＤＢサーバに固定的に設定する例について説明した。

しかし、優先ＤＢサーバは、ＳＩＰ端末の各々に対して一意的に決まればよく、ＳＩＰサーバは、自己が受信したＲＥＧＩＳＴＥＲ情報の各々に関するＲＥＧＩＳＴＥＲ情報テーブルにおいて、各々異なった優先ＤＢサーバを設定してもよい。

また、上記実施例においては、いずれかのＤＢサーバが輻輳状態に陥った際に、全ての同期処理を停止する場合を例に説明した。しかし、いずれかのＤＢサーバのみが輻輳状態に陥った際や、システム全体としての輻輳状態が比較的軽度の場合には、ある一方のＤＢサーバから他方のＤＢサーバへの同期処理のみを停止することとしてもよい。

例えば、第１のＤＢサーバ１１０のみが輻輳状態になった際に、ＳＩＰサーバ１３０、１４０の各々が、第２のＤＢサーバ１２０へのＲＥＧＩＳＴＥＲ情報の送信時にのみ同期要求を送信して、第１のＤＢサーバへの同期処理を要求することとしてもよい。すなわち、第１のＤＢサーバ１１０へのＲＥＧＩＳＴＥＲ情報送信時には、同期要求を送信しないこととしてもよい。

また、上記実施例においては、２つのＤＢサーバ１１０、１２０と２つのＳＩＰサーバ１３０、１４０からなるシステムを例に説明したが、ＳＩＰサーバの数は１または３以上であってもよい。その場合でも、ＳＩＰサーバの各々が自己が受信したＲＥＧＩＳＴＥＲ情報の各々に関するＲＥＧＩＳＴＥＲ情報テーブルにおいて、ＳＩＰ端末の各々に対して優先ＤＢサーバを一意的に設定すれば、上記輻輳からの早期復帰及び同期状態の容易かつ早期の回復が可能である。

また、ＤＢサーバは３以上であってもよい。この場合、ＤＢサーバの各々は互いに他のサーバのデータベースの情報を同期する。また、ＤＢサーバの各々は自己の輻輳状態監視しかつ互いの輻輳状態の監視をし、いずれかの輻輳状態になった場合に、同期状態テーブルが書き換えられ、ＳＩＰサーバによる同期処理が停止する。そして、輻輳状態が解消すると、上記説明したように、ＤＢサーバの各々は互いにデータベースの同期を行う。

その場合でも、ＳＩＰサーバの各々が自己が受信したＲＥＧＩＳＴＥＲ情報の各々に関するＲＥＧＩＳＴＥＲ情報テーブルにおいて、ＳＩＰ端末の各々に対して優先ＤＢサーバを一意的に設定すれば、上記輻輳からの早期復帰及び同期状態の容易かつ早期の回復が可能である。

また、上記実施例においては、優先ＤＢサーバはＳＩＰサーバ１３０、１４０が決定するとしたが、ＳＩＰ端末が優先ＤＢサーバ情報を設定するかもしくは予め保有しており、それをＳＩＰサーバに送信することとしてもよい。

また、上記実施例においては、輻輳状態の判定基準として、ＣＰＵの使用率を用いる例について説明したが、判定基準は、データベースサーバの単位時間当たりのトランザクションの数等他の基準を用いてもよい。すなわち、データベースサーバに関する様々なパラメータが輻輳状態の判定に用いられ得る。

上述した実施例における種々の構成は、例示に過ぎず、用途等に応じて、適宜選択することができる。

１００サーバシステム
１１０第１のデータベースサーバ
１１１、１２１データベース
１１１Ａ、１２１ＡＲＥＧＩＳＴＥＲ情報データベース
１１１Ｂ、１２１Ｂ同期状態テーブル
１１３、１２３輻輳監視部
１１５、１２５情報同期管理部
１２０第２のデータベースサーバ
１３０第１のＳＩＰサーバ
１３１、１４１ＲＥＧＩＳＴＥＲ情報送受信部
１４０第２のＳＩＰサーバ
１５０ＳＩＰ端末

Claims

通信処理を行う少なくとも１つの処理サーバと、前記処理サーバとネットワークを介して接続された第１のデータベースサーバと、前記少なくとも１つの処理サーバ及び前記第１のデータベースサーバとネットワークを介して接続された第２のデータベースサーバと、を備えたデータベースシステムであって、
前記処理サーバは、前記通信処理に関連する処理情報の各々に送信先のデータベースサーバを指定する優先サーバ情報を付与し、前記優先サーバ情報に基づいて前記処理情報及び前記処理情報に係る同期要求を前記第１のデータベースサーバまたは前記第２のデータベースサーバに送信する処理情報送信部を有し、
前記第１のデータベースサーバは、前記処理サーバから送信された前記処理情報を受信して格納する第１の受信格納部と、前記第１の受信格納部に格納された前記処理情報を前記同期要求に従って前記第２のデータベースサーバに送信する第１の送信部と、前記第１のデータベースサーバにおいて輻輳が発生しているか否かを判定する第１の輻輳監視部と、を有し、
前記第２のデータベースサーバは、前記処理サーバから送信された前記処理情報を受信して格納する第２の受信格納部と、前記第２の受信格納部に格納された前記処理情報を前記同期要求に従って前記第１のデータベースサーバに送信する第２の送信部と、前記第２のデータベースサーバにおいて輻輳が発生しているか否かを判定する第２の輻輳監視部と、を有し、
前記処理サーバは、前記第１の輻輳監視部または前記第２の輻輳監視部が輻輳が発生しているとする輻輳判定していることを検知した場合に、前記同期要求の送信を停止することを特徴とするデータベースシステム。
前記処理サーバは、前記同期要求の送信の停止後、前記第１の輻輳監視部及び前記第２の輻輳監視部のいずれもが輻輳が発生していないとする輻輳解消判定をしたことを検知した際に、前記同期要求の送信を再開することを特徴とする請求項１に記載のデータベースシステム。
前記第１の送信部は、前記輻輳判定以後かつ前記輻輳解消判定以前に前記第１の受信格納部によって受信され格納された処理情報を前記第２の受信格納部に送信し、前記第２の送信部は、前記輻輳判定以後かつ前記輻輳解消判定以前に前記第２の受信格納部によって受信され格納された処理情報を前記第１の受信格納部に送信することを特徴とする請求項２に記載のデータベースシステム。
前記処理サーバの各々は、それぞれ特定のデータベースサーバを指定する優先サーバ情報を付与することを特徴とする請求項１乃至３のいずれか１に記載のデータベースシステム。
ネットワークに接続され前記ネットワークから情報を受信する第１のデータベースサーバと、前記第１のデータベースサーバと前記ネットワークを介して接続され前記ネットワークから情報を受信する第２のデータベースサーバと、を備えたデータベースシステムであって、
前記第１のデータベースサーバは、前記ネットワークから受信して更新した情報をその更新時刻とともに格納する第１の受信格納部と、前記第１の受信格納部に格納された情報を前記第２のデータベースサーバに送信する第１の送信部と、前記第１のデータベースサーバにおいて輻輳が発生しているか否かを判定する第１の輻輳監視部と、を有し、
前記第２のデータベースサーバは、前記ネットワークから受信して更新した情報をその更新時刻と共に格納する第２の受信格納部と、前記第２の受信格納部に格納された情報を前記第１のデータベースサーバに送信する第２の送信部と、前記第２のデータベースサーバにおいて輻輳が発生しているか否かを判定する第２の輻輳監視部と、を有し、
前記第１の送信部及び第２の送信部は、前記第１の輻輳監視部または前記第２の輻輳監視部が輻輳が発生しているとする輻輳判定をしていることを検知した際に前記第１及び第２のデータベースサーバへの前記情報の送信を停止し、前記第１の輻輳監視部または第２の輻輳監視部が輻輳が解消しているとする輻輳解消判定をしていることを検知した際に前記第１及び第２のデータベースへの情報の送信を再開し、
前記第１及び第２の受信格納部は、前記第１または第２の輻輳監視部が前記輻輳判定をした時刻及び前記輻輳解消判定をした時刻を保持していることを特徴とするデータベースシステム。
前記第１の送信部は、前記更新時刻並びに前記第１または第２の輻輳監視部が前記輻輳判定をした時刻及び前記輻輳解消判定をした時刻に基づいて、前記輻輳判定以後かつ前記輻輳解消判定以前に前記第１の受信格納部によって受信されて更新された情報を前記第２の受信格納部に送信し、前記第２の送信部は、前記更新時刻並びに前記第１または第２の輻輳監視部が前記輻輳判定をした時刻及び前記輻輳解消判定をした時刻に基づいて、前記輻輳判定以後かつ前記輻輳解消判定以前に前記第２の受信格納部によって受信されて更新された情報を前記第１の受信格納部に送信することを特徴とする請求項５に記載のデータベースシステム。