(57)【特許請求の範囲】
【請求項１】
複数のサーバで同期したデータを記憶するデータ多重化システムであり、
各サーバは、
データを記憶するＤＢ（ＤａｔａＢａｓｅ）と、
他のサーバのＤＢについてのＭＶ（Ｍａｔｅｒｉａｌｉｚｅｄ  Ｖｉｅｗ）と、
前記ＭＶのデータに基づき、自身のＤＢのデータを更新するデータ更新部と
を備え、
前記複数のサーバのうち、ユーザにより前記ＤＢのデータが更新される稼働サーバにおける前記データ更新部は、所定のサーバのＤＢについてのＭＶに基づき、自身のＤＢとそのＭＶとの両方にあるデータについて、自身のＤＢが記憶したデータよりもそのＭＶのデータの方が新しい場合に、自身のＤＢが記憶したデータをそのＭＶのデータで更新し、
前記複数のサーバのうち前記稼働サーバ以外の待機サーバにおける前記データ更新部は、前記稼働サーバのＤＢについてのＭＶのデータに合わせて、自身のＤＢのデータを更新する
ことを特徴とするデータ多重化システム。
【請求項２】
前記待機サーバにおける前記データ更新部は、前記稼働サーバのＤＢについてのＭＶに基づき、そのＭＶにのみあるデータについては自身のＤＢに挿入し、自身のＤＢにのみあるデータについては自身のＤＢから削除し、自身のＤＢとそのＭＶとの両方にあるデータについては自身のＤＢのデータをそのＭＶのデータで更新する
ことを特徴とする請求項１に記載のデータ多重化システム。
【請求項３】
前記データ多重化システムは、所定の場合に、待機サーバを稼働サーバに切り替えるとともに、稼働サーバを待機サーバに切り替え、
前記稼働サーバにおける前記データ更新部は、稼働サーバから待機サーバに切り替えられたサーバのＤＢについてのＭＶに基づき、自身のＤＢが記憶したデータを更新する
ことを特徴とする請求項１又は２に記載のデータ多重化システム。
【請求項４】
前記ＭＶは、予め定められたタイミングで、前記ＤＢのデータと同期する
ことを特徴とする請求項１から３までのいずれかに記載のデータ多重化システム。
【請求項５】
複数のサーバで同期したデータを記憶するデータ多重化システムにおけるサーバであり、
データを記憶するＤＢ（ＤａｔａＢａｓｅ）と、
他のサーバのＤＢについてのＭＶ（Ｍａｔｅｒｉａｌｉｚｅｄ  Ｖｉｅｗ）と、
前記ＭＶのデータに基づき、ＤＢのデータを更新するデータ更新部と
を備え、
ユーザにより前記ＤＢのデータが更新される稼働サーバである場合には、前記データ更新部は、前記ＤＢと前記ＭＶとの両方にあるデータについて、前記ＤＢが記憶したデータよりも前記ＭＶのデータの方が新しい場合に、前記ＤＢが記憶したデータを前記ＭＶのデータで更新し、
前記稼働サーバ以外の待機サーバである場合には、前記データ更新部は、前記ＭＶのデータに合わせて、前記ＤＢのデータを更新する
ことを特徴とするデータ多重化システムにおけるサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のサーバで同期したデータを記憶するデータ同期技術に関する。
【背景技術】
【０００２】
２つのサーバで同期したデータを記憶したデータ多重化システムがある。このデータ多重化システムでは、一方のサーバを稼働サーバとし、他方のサーバを待機サーバとする。稼働サーバは、ユーザによりデータ更新が行われる稼働中のサーバであり、待機サーバは、稼働サーバのバックアップとなる待機中のサーバである。
このデータ多重化システムは、稼働サーバに障害が発生した場合、待機サーバを稼働させ稼働サーバに切り替えることにより、速やかに障害から復旧できる。
【０００３】
稼働サーバのデータと同期したデータを待機サーバに記憶させる場合、一般的に、まず、稼働サーバのデータを待機サーバにコピーして、稼働サーバと待機サーバとの間で一旦データを同期させる。そして、その後は、稼働サーバのデータに対して行われた更新を待機サーバのデータに対しても行い、稼働サーバと待機サーバとの間でデータが同期した状態を維持する。
このように稼働サーバのデータと同期したデータを待機サーバに記憶させる場合、稼働サーバのデータを待機サーバにコピーしている間は、稼働サーバのデータの更新を停止する必要がある。この間に、稼働サーバのデータが更新されると、その更新が待機サーバのデータに反映されず、稼働サーバのデータと待機サーバのデータとが同期しなくなる恐れがあるためである。そのため、この間は、システムを停止しなければならない。
【０００４】
例えば、サーバＡが稼働サーバであり、サーバＢが待機サーバであり、サーバＡとサーバＢとで同期したデータを記憶しているとする。このとき、サーバＡに障害が発生し、サーバＢを稼働サーバに切り替えたとする。この場合、サーバＢを稼働サーバに切り替えることにより、速やかに障害から復旧できるため、システムを停止させない、あるいは、停止するとしても停止時間を短くすることができる。
しかし、サーバＢを稼働サーバに切り替えると、待機サーバが存在しない状態となってしまう。そこで、例えば、サーバＡが復旧後、サーバＡを待機サーバとする。サーバＡを待機サーバとするには、まず、サーバＢのデータをサーバＡへコピーして、サーバＢとサーバＡとの間で一旦データを同期させる必要がある。この間、サーバＢへのデータ更新を停止する必要があり、システムを停止しなければならない。
つまり、障害から復旧させる場合には、システムの停止を防ぐことができるが、再びデータを多重化させる場合には、システムを停止しなければならない。
【０００５】
例えば、Ｏｒａｃｌｅ  Ｄａｔａｂａｓｅでは、稼働サーバのデータと同期したデータを待機サーバに記憶させる場合に利用される機能として、マルチマスターレプリケーション機能とデータガード機能とが提供されている。
マルチマスターレプリケーション機能を用いる場合、通常時は、稼働サーバで実行されたトランザクション（挿入、更新、削除）を待機サーバへ転送して、待機サーバでもトランザクションを実行することにより、データの同期が維持される。しかし、障害が発生し、稼働サーバと待機サーバとでデータに差異が発生した場合、稼働サーバでデータをエクスポートし、エクスポートされたデータを待機サーバへインポートすることにより、稼働サーバのデータを待機サーバへコピーして、稼働サーバと待機サーバとのデータを一旦同期させる必要がある。データの整合性を保証するため、稼働サーバでデータをエクスポートしている間、稼働サーバのデータの更新は行えない。
データガード機能を用いる場合、通常時は、稼働サーバで実行されたデータ更新のログを待機サーバへ転送して、待機サーバでログに基づきデータを更新することにより、データの同期が維持される。しかし、障害が発生し、稼働サーバと待機サーバとでデータに差異が発生した場合、稼働サーバのコールドバックアップを待機サーバでリストアすることにより、稼働サーバのデータを待機サーバへコピーして、稼働サーバと待機サーバとのデータを一旦同期させる必要がある。データの整合性を保証するため、待機サーバでコールドバックアップをリストアしている間、稼働サーバのデータの更新は行えない。
【０００６】
特許文献１には、稼働サーバと待機サーバとの間に中間装置を設置することにより、稼働サーバのデータの更新を停止させることなく、稼働サーバのデータと同期したデータを待機サーバに記憶させることについて記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−３３８１４５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
システムによっては、システムを停止させることができない場合や、システムの停止時間をできるだけ短くすることが望ましい場合がある。この場合、上述した一般的な方法により、稼働サーバのデータと同期したデータを待機サーバに記憶させることはできない可能性がある。
特許文献１に記載された方法では、中間装置を用意する必要があり、その分の追加コストがかかる。また、中間装置に障害が発生した場合、データの同期が取れなくなる。
この発明は、コストを抑えつつ、システムが停止させずに、稼働サーバのデータと同期したデータを待機サーバに記憶させることを目的とする。
【課題を解決するための手段】
【０００９】
この発明に係るデータ多重化システムは、
複数のサーバで同期したデータを記憶するデータ多重化システムであり、
各サーバは、
データを記憶するＤＢ（ＤａｔａＢａｓｅ）と、
他のサーバのＤＢについてのＭＶ（Ｍａｔｅｒｉａｌｉｚｅｄ  Ｖｉｅｗ）と、
前記ＭＶのデータに基づき、自身のＤＢのデータを更新するデータ更新部と
を備え、
前記複数のサーバのうち、ユーザにより前記ＤＢのデータが更新される稼働サーバにおける前記データ更新部は、所定のサーバのＤＢについてのＭＶに基づき、自身のＤＢとそのＭＶとの両方にあるデータについて、自身のＤＢが記憶したデータよりもそのＭＶのデータの方が新しい場合に、自身のＤＢが記憶したデータをそのＭＶのデータで更新し、
前記複数のサーバのうち前記稼働サーバ以外の待機サーバにおける前記データ更新部は、前記稼働サーバのＤＢについてのＭＶのデータに合わせて、自身のＤＢのデータを更新する
ことを特徴とする。
【００１０】
前記待機サーバにおける前記データ更新部は、前記稼働サーバのＤＢについてのＭＶに基づき、そのＭＶにのみあるデータについては自身のＤＢに挿入し、自身のＤＢにのみあるデータについては自身のＤＢから削除し、自身のＤＢとそのＭＶとの両方にあるデータについては自身のＤＢのデータをそのＭＶのデータで更新する
ことを特徴とする。
【００１１】
前記データ多重化システムは、所定の場合に、待機サーバを稼働サーバに切り替えるとともに、稼働サーバを待機サーバに切り替え、
前記稼働サーバにおける前記データ更新部は、稼働サーバから待機サーバに切り替えられたサーバのＤＢについてのＭＶに基づき、自身のＤＢが記憶したデータを更新する
ことを特徴とする。
【００１２】
前記ＭＶは、予め定められたタイミングで、前記ＤＢのデータと同期する
ことを特徴とする。
【００１３】
この発明に係るデータ多重化システムにおけるサーバは、
複数のサーバで同期したデータを記憶するデータ多重化システムにおけるサーバであり、
データを記憶するＤＢ（ＤａｔａＢａｓｅ）と、
他のサーバのＤＢについてのＭＶ（Ｍａｔｅｒｉａｌｉｚｅｄ  Ｖｉｅｗ）と、
前記ＭＶのデータに基づき、ＤＢのデータを更新するデータ更新部と
を備え、
ユーザにより前記ＤＢのデータが更新される稼働サーバである場合には、前記データ更新部は、前記ＤＢと前記ＭＶとの両方にあるデータについて、前記ＤＢが記憶したデータよりも前記ＭＶのデータの方が新しい場合に、前記ＤＢが記憶したデータを前記ＭＶのデータで更新し、
前記稼働サーバ以外の待機サーバである場合には、前記データ更新部は、前記ＭＶのデータに合わせて、前記ＤＢのデータを更新する
ことを特徴とする。
【発明の効果】
【００１４】
この発明に係るデータ多重化システムでは、各サーバが他のサーバのＭＶを用いてＤＢのデータを更新することにより、システムを停止させることなく、稼働サーバのデータと同期したデータを待機サーバに記憶させることができる。ＭＶは一般的なデータベースシステムで提供されている機能であり、追加コストがかかることもない。
【図面の簡単な説明】
【００１５】
【図１】実施の形態１に係るデータ多重化システム１００の構成図。
【図２】通常時のデータ多重化システム１００の動作の説明図。
【図３】障害発生時のデータ多重化システム１００の動作の説明図。
【図４】障害復旧後のデータ多重化システム１００の動作の説明図。
【図５】障害復旧後のデータ多重化システム１００の動作の説明図。
【図６】データ更新ロジックを示すフローチャート。
【図７】データ挿入時のデータ推移の例を示す図。
【図８】データ更新時のデータ推移の例を示す図。
【図９】データ削除時のデータ推移の例を示す図。
【図１０】障害発生時のデータ推移の例を示す図。
【図１１】障害復旧後のデータ推移の例を示す図。
【図１２】実施の形態２に係るデータ多重化システム１００の構成図。
【図１３】通常時のデータ多重化システム１００の動作の説明図。
【図１４】障害発生時のデータ多重化システム１００の動作の説明図。
【図１５】障害復旧後のデータ多重化システム１００の動作の説明図。
【図１６】サーバ１０，２０，３０のハードウェア構成の一例を示す図。
【発明を実施するための形態】
【００１６】
実施の形態１．
実施の形態１では、サーバ１０とサーバ２０との２台のサーバで同期したデータを記憶するデータ多重化システム１００について説明する。
【００１７】
図１は、実施の形態１に係るデータ多重化システム１００の構成図である。
データ多重化システム１００は、サーバ１０，２０の２台のサーバを備える。サーバ１０，２０はネットワーク５０を介して接続されている。サーバ１０，２０は、一方が稼働サーバとなり、他方が待機サーバとなる。
【００１８】
サーバ１０は、ＤＢ１１（ＤａｔａＢａｓｅ）と、サーバ２０のＤＢ２１についてのＭＶ１２（Ｍａｔｅｒｉａｌｉｚｅｄ  Ｖｉｅｗ）と、ＭＶ１２のデータに基づき、ＤＢ１１のデータを更新するデータ更新部１３とを備える。
サーバ２０は、ＤＢ２１と、サーバ１０のＤＢ１１についてのＭＶ２２と、ＭＶ２２のデータに基づき、ＤＢ２１のデータを更新するデータ更新部２３とを備える。
【００１９】
ＭＶとは、クエリの結果を実際のテーブルにキャッシュしたものである。つまり、通常のＶｉｅｗは、クエリの結果を表す仮想的なテーブルであり、データの実体を記憶するわけではない。これに対して、ＭＶは、クエリの結果を実際のテーブルにキャッシュしており、データの実体を記憶している。
ＭＶは、クエリで読み出す先のテーブルが更新されると、設定された更新タイミングにその更新が反映される。つまり、ＭＶのデータは、クエリで読み出す先のテーブルのデータと同期した状態となる。
【００２０】
ここでは、ＭＶ１２は、ＤＢ２１の全てのデータを対象として読み出しキャッシュしており、ＭＶ２２は、ＤＢ１１の全てのデータを対象として読み出しキャッシュしているとする。
【００２１】
図２は、通常時のデータ多重化システム１００の動作の説明図である。
図２では、サーバ１０を稼働サーバ、サーバ２０を待機サーバとして動作させている場合を示す。
この場合、サーバ１０のＤＢ１１がユーザにより更新される（１１）。すると、ＤＢ１１の更新がＭＶ２２にも反映される（１２）。ＭＶ２２が更新されると、後述する更新ロジックに従い、データ更新部２３がＭＶ２２の更新をＤＢ２１に反映する（１３）。すると、ＤＢ２１の更新がＭＶ１２にも反映される（１４）。したがって、ＤＢ１１のデータとＤＢ２１のデータとは同期した状態になる。
【００２２】
図３は、障害発生時のデータ多重化システム１００の動作の説明図である。
図３では、サーバ１０で障害が発生し、サーバ２０を待機サーバから稼働サーバに切り替えた場合を示す。サーバ１０とサーバ２０とのデータは同期しているため、単にサーバ２０を稼働サーバとする設定を行うだけで、障害から復旧させることができる。そのため、システムを停止させることなく、あるいは、停止させたとしても、短い停止時間でシステムを復旧させることが可能である。
この場合、サーバ２０のＤＢ２１がユーザにより更新される（２１）。しかし、サーバ１０で障害が発生しているため、ＤＢ２１の更新はＭＶ１２に反映されない。
【００２３】
図４は、障害復旧後のデータ多重化システム１００の動作の説明図である。
図４では、サーバ１０の復旧後、サーバ１０を待機サーバとして動作させる場合を示す。
この場合、ＤＢ２１の更新がＭＶ１２にも反映される（３１）。ＭＶ１２が更新されると、後述する更新ロジックに従い、データ更新部１３がＭＶ１２の更新をＤＢ１１に反映する（３２）。すると、ＤＢ１１の更新がＭＶ２２にも反映される（１３）。したがって、ＤＢ１１のデータとＤＢ２１のデータとは同期した状態になる。
ＭＶ１２を更新する際、ＤＢ２１の更新を停止する必要はない。そのため、サーバ１０を待機サーバとして動作させる場合に、ＤＢ２１の更新を停止する必要はない。したがって、システムを停止することなく、データの多重化をすることが可能である。
【００２４】
しかし、図２における（１１）でＤＢ１１が更新されてから、（１２）でＤＢ１１の更新がＭＶ２２に反映されるまでには、ＭＶ２２の更新タイミングの設定にもよるが、若干のタイムラグがある。そのため、ＤＢ１１のデータとＤＢ２１のデータとには、一時的に若干の差異がある可能性がある。
そのため、ＤＢ１１のデータとＤＢ２１のデータとに差異がある状態で、サーバ１０に障害が発生すると、その差異がある状態でサーバ２０が稼働サーバに切り替えられる。つまり、一部の更新が行われる前の状態でサーバ２０が稼働サーバに切り替えられる。
【００２５】
図５は、障害復旧後のデータ多重化システム１００の動作の説明図である。
図５では、サーバ１０の復旧後、サーバ１０を待機サーバとして動作させる場合を示す。特に、図５では、サーバ１０に障害が発生した際、ＤＢ１１のデータとＤＢ２１のデータとに差異があった場合を示す。
この場合、サーバ１０に障害が発生した時点に存在した、ＤＢ１１のデータとＤＢ２１のデータと間の差異が、ＭＶ２２に反映される（４１）。ＭＶ２２が更新されると、後述する更新ロジックに従い、データ更新部２３がＭＶ２２の更新をＤＢ２１に反映する（４２）。すると、ＤＢ２１の更新がＭＶ１２にも反映される（４３）。ＭＶ１２が更新されると、後述する更新ロジックに従い、データ更新部１３がＭＶ１２の更新をＤＢ１１に反映する（４４）。したがって、ＤＢ１１のデータとＤＢ２１のデータとは同期した状態になる。
【００２６】
図６は、データ更新ロジックを示すフローチャートである。
データ更新ロジックは、サーバ１０，２０に共通のロジックである。つまり、データ更新ロジックは、データ更新部１３がＭＶ１２に基づきＤＢ１１を更新するロジックであり、データ更新部２３がＭＶ２２に基づきＤＢ２１を更新するロジックである。
ここでは、データ更新部１３がＭＶ１２に基づきＤＢ１１を更新する場合を例として説明する。
【００２７】
なお、ＤＢ１１，２１の各テーブルは、テーブル内のレコードを識別可能なＩＤ（主キー）と、更新日時とを含んでいる。更新日時は、データが挿入された場合には、挿入時の日時が設定され、そのデータが更新された場合には、更新時の日時に更新される。各レコードの更新日時は、データベースソフトウェアで用意された関数等により取得することが可能である。
【００２８】
まず、データ更新部１３は、サーバ１０が稼働サーバであるか、待機サーバであるかを判定する（Ｓ１）。
各サーバ１０，２０は、自身が稼働サーバであるか、待機サーバであるか、その他（故障、保守等のために更新停止中）のサーバであるかを示す情報を自身のＤＢ１１，２１に記憶しており、データ更新部１３は、この情報に基づき、サーバ１０が稼働サーバであるか、待機サーバであるかを判定する。
【００２９】
データ更新部１３は、Ｓ１でサーバ１０が稼働サーバであると判定した場合、ＤＢ１１及びＭＶ１２の各データ（レコード）について、ループ１（Ｓ２−Ｓ４）を実行する。つまり、データ更新部１３は、ＤＢ１１とＭＶ１２との両方にあるデータと、ＤＢ１１のみにあるデータと、ＭＶ１２のみにあるデータとの全てについて、ループ１を実行する。なお、ＤＢ１１とＭＶ１２との両方にあるとは、同じＩＤを有するデータがＤＢ１１とＭＶ１２との両方にあるということである。
ループ１では、データ更新部１３は、ＤＢ１１とＭＶ１２との両方にデータがあるか否かを判定する（Ｓ２）。データ更新部１３は、Ｓ２で両方にデータがあると判定した場合、そのデータについて、ＭＶ１２のデータの方がＤＢ１１のデータよりも更新日時が新しいか否かを判定する（Ｓ３）。データ更新部１３は、ＭＶ１２のデータの方がＤＢ１１のデータよりも更新日時が新しい場合、ＭＶ１２のデータでＤＢ１１のデータを更新する（Ｓ４）。
なお、Ｓ２でＤＢ１１又はＭＶ１２にのみデータがある場合、及び、Ｓ３でＭＶ１２のデータとＤＢ１１のデータとの更新日時が同じか、ＭＶ１２のデータの方がＤＢ１１のデータよりも更新日時が古い場合、データ更新部１３はＤＢ１１のデータを更新しない。
【００３０】
データ更新部１３は、Ｓ１でサーバ１０が待機サーバであると判定した場合、ＤＢ１１及びＭＶ１２の各データについて、ループ２（Ｓ５−Ｓ８）を実行する。
ループ２では、データ更新部１３は、ＤＢ１１とＭＶ１２との両方にデータがあるか否かを判定する（Ｓ５）。ＤＢ１１とＭＶ１２との両方にあるとは、上記と同様に、同じＩＤを有するデータがＤＢ１１とＭＶ１２との両方にあるということである。データ更新部１３は、Ｓ５でＭＶ１２にのみデータがある場合、そのデータをＭＶ１２からＤＢ１１へ挿入する（Ｓ６）。データ更新部１３は、Ｓ５でＤＢ１１にのみデータがある場合、そのデータをＤＢ１１から削除する（Ｓ７）。データ更新部１３は、Ｓ５で両方にデータがある場合、ＭＶ１２のデータでＤＢ１１のデータを更新する（Ｓ８）。
【００３１】
図７は、データ挿入時のデータ推移の例を示す図である。
図７では、サーバ１０を稼働サーバ、サーバ２０を待機サーバとして動作させているとする。
図７（ａ）に示すように、ＤＢ１１、ＭＶ１２、ＤＢ２１、ＭＶ２２は、データＡ，Ｂ，Ｃを記憶している。ここで、図７（ｂ）に示すように、ユーザにより、ＤＢ１１にデータＤが挿入される。
すると、図７（ｃ）に示すように、ＤＢ１１の更新がＭＶ２２にも反映される。ＭＶ２２が更新されると、データ更新部２３がＭＶ２２の更新をＤＢ２１に反映する。ここでは、サーバ２０は待機サーバであり、データＤはＭＶ２２にのみあるため、図７（ｄ）に示すように、データＤがＭＶ２２からＤＢ２１へ挿入される。
すると、図７（ｅ）に示すように、ＤＢ２１の更新がＭＶ１２にも反映される。ＭＶ１２が更新されると、データ更新部１３がＭＶ１２の更新をＤＢ１１に反映する。ここでは、サーバ１０は稼働サーバであり、データＤはＤＢ１１とＭＶ１２との両方にあるが、データＤの更新日時はＤＢ１１とＭＶ１２とで同じであるため、ＤＢ１１のデータは更新されない。
【００３２】
図８は、データ更新時のデータ推移の例を示す図である。
図８では、サーバ１０を稼働サーバ、サーバ２０を待機サーバとして動作させているとする。
図８（ａ）に示すように、ＤＢ１１、ＭＶ１２、ＤＢ２１、ＭＶ２２は、データＡ，Ｂ，Ｃ，Ｄを記憶している。ここで、図８（ｂ）に示すように、ユーザにより、ＤＢ１１のデータＡの値がＸからＹに更新される。
すると、図８（ｃ）に示すように、ＤＢ１１の更新がＭＶ２２にも反映される。ＭＶ２２が更新されると、データ更新部２３がＭＶ２２の更新をＤＢ２１に反映する。ここでは、サーバ２０は待機サーバであり、データＡはＤＢ２１とＭＶ２２との両方にあるため、図８（ｄ）に示すように、データＡについてはＭＶ２２のデータでＤＢ２１のデータが更新される。
すると、図８（ｅ）に示すように、ＤＢ２１の更新がＭＶ１２にも反映される。ＭＶ１２が更新されると、データ更新部１３がＭＶ１２の更新をＤＢ１１に反映する。ここでは、サーバ１０は稼働サーバであり、データＡはＤＢ１１とＭＶ１２との両方にあるが、データＡの更新日時はＤＢ１１とＭＶ１２とで同じであるため、ＤＢ１１のデータは更新されない。
【００３３】
図９は、データ削除時のデータ推移の例を示す図である。
図９では、サーバ１０を稼働サーバ、サーバ２０を待機サーバとして動作させているとする。
図９（ａ）に示すように、ＤＢ１１、ＭＶ１２、ＤＢ２１、ＭＶ２２は、データＡ，Ｂ，Ｃ，Ｄを記憶している。ここで、図９（ｂ）に示すように、ユーザにより、ＤＢ１１のデータＢが削除される。
すると、図９（ｃ）に示すように、ＤＢ１１の更新がＭＶ２２にも反映される。ＭＶ２２が更新されると、データ更新部２３がＭＶ２２の更新をＤＢ２１に反映する。ここでは、サーバ２０は待機サーバであり、データＢはＤＢ２１にのみあるため、図９（ｄ）に示すように、データＢがＤＢ２１から削除される。
すると、図９（ｅ）に示すように、ＤＢ２１の更新がＭＶ１２にも反映される。ＭＶ１２が更新されると、データ更新部１３がＭＶ１２の更新をＤＢ１１に反映する。ここでは、サーバ１０は稼働サーバであり、データＢはＤＢ１１とＭＶ１２との両方にないため、ＤＢ１１のデータは更新されない。
【００３４】
図１０は、障害発生時のデータ推移の例を示す図である。
図１０では、サーバ１０を稼働サーバ、サーバ２０を待機サーバとして動作させている場合に、サーバ１０に障害が発生したとする。
図１０（ａ）に示すように、ＤＢ１１、ＭＶ１２、ＤＢ２１、ＭＶ２２は、データＡ，Ｃ，Ｄを記憶している。ここで、図１０（ｂ）に示すように、ユーザにより、ＤＢ１１のデータＡの値がＹからＺに更新され、ＤＢ１１のデータＣの値がＸからＹに更新され、ＤＢ１１のデータＤが削除され、ＤＢ１１にデータＥが挿入される。
すると、本来であれば、ＤＢ１１の更新がＭＶ２２にも反映される。しかし、ここでは、ＤＢ１１の更新がＭＶ２２に反映される前に、サーバ１０に障害が発生したとする。そのため、図１０（ｂ）に示すように、ＭＶ１２、ＤＢ２１、ＭＶ２２は、データＡ，Ｃ，Ｄを記憶している状態で、サーバ２０が稼働サーバに切り替えられる。
ここで、図１０（ｃ）に示すように、ユーザにより、ＤＢ２１のデータＣの値がＸからＺに更新されたとする。サーバ１０で障害が発生しているため、ＤＢ２１の更新はＭＶ１２に反映されない。
【００３５】
図１１は、障害復旧後のデータ推移の例を示す図である。
図１１では、サーバ２０を稼働サーバとして動作させている場合に、サーバ１０が復旧し、サーバ１０を待機サーバとして動作させるとする。
図１１（ａ）に示すように、ＤＢ１１のデータとＤＢ２１のデータとには差異があるとする。ここで、サーバ１０が復旧し、サーバ１０を待機サーバとして動作させる。
すると、図１１（ｂ）に示すように、ＭＶ２２に反映されていないＤＢ１１の更新が、ＭＶ２２に反映される。ＭＶ２２が更新されると、データ更新部２３がＭＶ２２の更新をＤＢ２１に反映する。ここでは、サーバ２０は稼働サーバである。データＡはＤＢ２１とＭＶ２２との両方にあり、データＡはＭＶ２２のデータの方がＤＢ２１のデータよりも更新日時が新しいため、図１１（ｃ）に示すように、ＭＶ２２のデータでＤＢ２１のデータが更新される。データＣはＤＢ２１とＭＶ２２との両方にあるが、データＡはＭＶ２２のデータの方がＤＢ２１のデータよりも更新日時が古いため、図１１（ｃ）に示すように、ＤＢ２１のデータは更新されない。データＤは、ＤＢ２１にのみあるため、図１１（ｃ）に示すように、ＤＢ２１は更新されない。データＥは、ＭＶ２２にのみあるため、図１１（ｃ）に示すように、ＤＢ２１は更新されない。
図１１（ｄ）に示すように、ＭＶ１２に反映されていないＤＢ２１の更新が、ＭＶ１２にも反映される。ＭＶ１２が更新されると、データ更新部１３がＭＶ１２の更新をＤＢ１１に反映する。ここでは、サーバ１０は待機サーバである。データＡ，ＣはＤＢ１１とＭＶ１２との両方にあるため、図１１（ｅ）に示すように、データＡ，ＣについてはＭＶ１２のデータでＤＢ１１のデータが更新される。データＤは、ＭＶ１２のみにあるため、図１１（ｅ）に示すように、ＤＢ１１に挿入される。データＥはＤＢ１１にのみあるため、図１１（ｅ）に示すように、ＤＢ１１から削除される。
【００３６】
以上のように、実施の形態１に係るデータ多重化システム１００は、障害が発生した場合や、障害発生後に再びデータを多重化させる場合に、システムを停止する必要がない。
【００３７】
なお、データ更新部１３，２３は、例えば、ＳＱＬ等のデータベースを操作する言語により構成することが可能である。また、ＭＶは、多くのデータベースソフトで提供されているものである。したがって、実施の形態１に係るデータ多重化システム１００は、機器の追加や、高機能な（高価な）データベースソフトは不要であり、低コストで実現可能である。
【００３８】
また、上述した通り、障害発生時に、ＤＢ１１，２１間でデータに差異が発生する可能性がある。
しかし、システムによっては、直近のデータは必要だが、過去の途中経過は消えてしまっても問題ないものもある。例えば、エレベータの保守要員の派遣要請を受けるコールセンターのシステムにおいて、エレベータ保守要員の位置情報は、直近のデータは必要だが、過去の途中経過は消えてしまっても大きな問題とはならない。保守要員の最新の位置情報があれば、過去の位置情報がなくても、障害に対応させる保守要員を決定するのには十分であるためである。
したがって、実施の形態１に係るデータ多重化システム１００は、十分に有用である。
【００３９】
また、障害発生時に、ＤＢ１１，２１間でデータに差異が発生するのは、ＤＢ１１（あるいはＤＢ２１）が更新されてから、ＭＶ２２（あるいはＭＶ１２）に更新が反映されるまでにタイムラグがあるためである。
しかし、ＭＶ１２，２２の更新タイミングは、ＤＢ１１，２１の更新とほぼ同時に設定することも可能である。したがって、障害発生時に、ＤＢ１１，２１間でデータに差異がほぼ発生しないようにすることも可能である。
但し、ＭＶ１２，２２の更新タイミングの頻度を多くするほど、サーバ１０，２０間のトラフィックが多くなるとともに、サーバ１０，２０へかかる負荷も大きくなる。そのため、ＤＢ１１，２１が備えるテーブルに応じて、ＭＶ１２，２２の更新タイミングを適切に設定することが望ましい。
例えば、失われた場合に回復させることが難しい、顧客から通知された障害発生情報等の業務データは、ＤＢ１１，２１が更新されると、ほぼ同時にＭＶ１２，２２も更新されるように設定して、データが失われないようにする。一方、変更されることが少ない顧客の氏名及び住所や、社員情報等のマスターデータや、失われても影響の小さいデータ等は、更新タイミングを１時間に１度等の少ない頻度に設定する。
【００４０】
また、データ多重化システム１００は、サーバ１０，２０の２台のサーバを備えるとした。サーバ１０，２０の設置場所を、例えば東京と福岡等の離れた場所にしてもよい。これにより、地震等の地域災害が発生した場合でも、いずれかのサーバは使用可能な状態となる。
【００４１】
実施の形態２．
実施の形態１では、データ多重化システム１００は、サーバ１０，２０の２台のサーバを備えるとした。実施の形態２では、データ多重化システム１００が３台以上のサーバを備える場合について説明する。
なお、ここでは、データ多重化システム１００がサーバ１０，２０，３０の３台のサーバを備える場合を例として説明する。しかし、データ多重化システム１００が４台以上のサーバを備える場合も、同様の考え方により実現できる。
【００４２】
図１２は、実施の形態２に係るデータ多重化システム１００の構成図である。
データ多重化システム１００は、サーバ１０，２０，３０の３台のサーバを備える。サーバ１０，２０，３０はネットワーク５０を介して接続されている。サーバ１０，２０，３０は、１台が稼働サーバとなり、残りが待機サーバとなる。
【００４３】
サーバ１０は、ＤＢ１１と、サーバ２０のＤＢ２１についてのＭＶ１２１と、サーバ３０のＤＢ３１についてのＭＶ１２２と、ＭＶ１２１又はＭＶ１２２のデータに基づき、ＤＢ１１のデータを更新するデータ更新部１３とを備える。
サーバ２０は、ＤＢ２１と、サーバ１０のＤＢ１１についてのＭＶ２２１と、サーバ３０のＤＢ３１についてのＭＶ２２２と、ＭＶ２２１又はＭＶ２２２のデータに基づき、ＤＢ２１のデータを更新するデータ更新部２３とを備える。
サーバ３０は、ＤＢ３１と、サーバ１０のＤＢ１１についてのＭＶ３２１と、サーバ２０のＤＢ２１についてのＭＶ３２２と、ＭＶ３２１又はＭＶ３２２のデータに基づき、ＤＢ３１のデータを更新するデータ更新部３３とを備える。
つまり、各サーバは、自身以外の他の全てのサーバのＤＢについてのＭＶを有する。例えば、サーバが３台であれば、各サーバは２つのＭＶを有し、サーバが４台であれば、各サーバは、３つのＭＶを有する。
【００４４】
各サーバの動作は、待機サーバである場合には、稼働サーバのＤＢについてのＭＶに基づき、データ更新部が自身のＤＢの更新を行い、稼働サーバである場合には、自身が稼働サーバになる前に稼働サーバであったサーバであって、一旦停止していたが待機サーバとして起動したサーバのＤＢについてのＭＶに基づき、データ更新部が自身のＤＢの更新を行う点が実施の形態１と異なる。データ更新部が用いるデータ更新ロジックは、実施の形態１と同じであり、サーバ１０，２０，３０に共通のロジックである。
【００４５】
図１３は、通常時のデータ多重化システム１００の動作の説明図である。
図１３では、サーバ１０を稼働サーバ、サーバ２０，３０を待機サーバとして動作させている場合を示す。
この場合、サーバ１０のＤＢ１１がユーザにより更新される（５１）。すると、ＤＢ１１の更新がＭＶ２２１及びＭＶ３２１にも反映される（５２）。ＭＶ２２１が更新されると、更新ロジックに従い、データ更新部２３がＭＶ２２１の更新をＤＢ２１に反映する（５３）。同様に、ＭＶ３２１が更新されると、更新ロジックに従い、データ更新部３３がＭＶ３２１の更新をＤＢ３１に反映する（５４）。すると、ＤＢ２１の更新がＭＶ１２１にも反映され（５５）、ＤＢ３１の更新がＭＶ１２２にも反映される（５６）。なお、ＤＢ２１の更新は、ＭＶ３２２にも反映され、ＤＢ３１の更新は、ＭＶ２２２にも反映される。したがって、ＤＢ１１のデータとＤＢ２１のデータとＤＢ３１のデータとは同期した状態になる。
【００４６】
図１４は、障害発生時のデータ多重化システム１００の動作の説明図である。
図１４では、サーバ１０で障害が発生し、サーバ２０を待機サーバから稼働サーバに切り替えた場合を示す。
この場合、サーバ２０のＤＢ２１がユーザにより更新される（６１）。すると、ＤＢ１１の更新がＭＶ３２２にも反映される（６２）。ＭＶ３２２が更新されると、更新ロジックに従い、データ更新部３３がＭＶ３２２の更新をＤＢ３１に反映する（６３）。すると、ＤＢ３１の更新がＭＶ２２２にも反映される（６４）。したがって、ＤＢ２１のデータとＤＢ３１のデータとは同期した状態になる。
しかし、サーバ１０で障害が発生しているため、ＤＢ２１の更新はＭＶ１２１に反映されず、ＤＢ３１の更新はＭＶ１２２に反映されない。
【００４７】
図１５は、障害復旧後のデータ多重化システム１００の動作の説明図である。
図１５では、サーバ１０の復旧後、サーバ１０を待機サーバとして動作させる場合を示す。
この場合、サーバ１０に障害が発生した時点に存在した、ＤＢ１１のデータとＤＢ２１のデータとの間の差異が、ＭＶ２２１に反映される（７１）。ＭＶ２２１が更新されると、更新ロジックに従い、データ更新部２３がＭＶ２２１の更新をＤＢ２１に反映する（７２）。すると、ＤＢ２１の更新がＭＶ１２１及びＭＶ３２２にも反映される（７３）。ＭＶ１２１が更新されると、更新ロジックに従い、データ更新部１３がＭＶ１２１の更新をＤＢ１１に反映する（７４）。同様に、ＭＶ３２２が更新されると、更新ロジックに従い、データ更新部３３がＭＶ３２２の更新をＤＢ３１に反映する（７５）。
したがって、ＤＢ１１のデータとＤＢ２１のデータとＤＢ３１のデータとは同期した状態になる。
【００４８】
以上のように、実施の形態２に係るデータ多重化システム１００は、実施の形態１に係るデータ多重化システム１００と同様の効果を得つつ、３台以上のサーバにより、データを多重化させることが可能である。
【００４９】
なお、上記説明では、各サーバは、自身が稼働サーバであるか、待機サーバであるか、その他のサーバであるかを示す情報をＤＢに記憶しており、データ更新部は、この情報に基づき、サーバが稼働サーバであるか、待機サーバであるかを判定するとした。
しかし、各サーバは、自身が、いつ稼動サーバ、待機サーバ、その他のサーバになったかを、その日時とともに、過去分も含めてＤＢに記憶してもよい。そして、データ更新部は、全てのサーバについて稼動サーバか待機サーバかその他のサーバかの判定を行ってもよい。稼動サーバが複数ある場合は、日時が新しいサーバが稼動サーバであると判定し、その他は待機サーバであると判定するようにしてもよい。このようにすれば、実際は故障しているにも関わらず情報の更新ができずに稼動サーバと記憶しているような場合にも対応できる。この例は、特に実施の形態２に係るデータ多重化システム１００に有効である。
【００５０】
また、稼動サーバ及び待機サーバでのＭＶの更新は、上述した通り実行される。しかし、稼動サーバであったが停止中のサーバ（稼動サーバでも待機サーバでもないサーバ）におけるＭＶには、他のサーバのＤＢの更新を反映しないことが望ましい。
【００５１】
また、待機サーバでのＭＶからＤＢへのデータ更新のタイミングは、なるべく短い間隔で行い、常にＤＢのデータをできる限り稼動サーバと同じ状態にしておくことが望ましい。
【００５２】
稼動サーバでのＭＶからＤＢへのデータ更新のタイミングは、稼動サーバのＤＢに反映されていない新しいデータを反映することが目的である。そのため、稼働サーバとして動作していたが、故障、保守等の何らかの事情により一旦停止していたサーバが待機サーバとして起動した直後に、稼動サーバにおけるこの待機サーバについてのＭＶが更新され、次に稼働サーバにおいてこのＭＶからＤＢへの更新が行われるように制御される。
その他の場合、稼動サーバでのＭＶからＤＢへのデータ更新は停止していても構わない。又は、稼動サーバでは、正常稼動しているいずれかの待機サーバについてのＭＶからＤＢへデータ更新するようにしてもよい。但し、この場合も稼働サーバではＭＶからＤＢへデータ更新されることはなく、実質的にデータ更新が停止していることと変わりない。
【００５３】
上記のような条件を確保した制御を行うために、例えば、稼働サーバとして動作していたが、故障、保守等の何らかの事情により一旦停止していたサーバを待機サーバとして起動する場合には、全てのサーバで一旦データ更新部によるデータ更新を止める。但し、この際、稼動サーバは、ユーザからのデータ入力をそのまま受け付ける。次に、全てのサーバでＭＶの更新を行う。次に、稼動サーバのデータ更新部が前述の待機サーバとして起動した直後のサーバに対応するＭＶに基づきＤＢの更新を行う。そして、全ての待機サーバにおいて、データ更新部によるＤＢの更新を行う。この後は、所定のタイミングでＭＶへの反映、待機サーバでのデータ更新、稼動サーバでのデータ更新を行う。
【００５４】
図１６は、サーバ１０，２０，３０のハードウェア構成の一例を示す図である。
図１６に示すように、サーバ１０，２０，３０は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３、ＲＡＭ９１４、ＬＣＤ９０１（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）、キーボード９０２（Ｋ／Ｂ）、通信ボード９１５、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置９２０（固定ディスク装置）の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。磁気ディスク装置９２０は、所定の固定ディスクインタフェースを介して接続される。
【００５５】
磁気ディスク装置９２０又はＲＯＭ９１３などには、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
【００５６】
プログラム群９２３には、上記の説明において「ＤＢ１１，２１，３１」、「ＭＶ１２，１２１，１２２，２２，２２１，２２２，３２，３２１，３２２」、「データ更新部１３，２３，３３」等として説明した機能を実行するソフトウェアやプログラムやその他のプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、上記の説明において「ＤＢ１１，２１，３１」、「ＭＶ１２，１２１，１２２，２２，２２１，２２２，３２，３２１，３２２」に格納される情報やデータや信号値や変数値やパラメータが、「ＤＢ１１，２１，３１」、「ＭＶ１２，１２１，１２２，２２，２２１，２２２，３２，３２１，３２２」の各項目として記憶される。「ＤＢ１１，２１，３１」、「ＭＶ１２，１２１，１２２，２２，２２１，２２２，３２，３２１，３２２」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵ９１１の動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵ９１１の動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【００５７】
また、上記の説明におけるフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、その他光ディスク等の記録媒体やＩＣチップに記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体や電波によりオンライン伝送される。
また、上記の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。また、「〜装置」として説明するものは、「〜回路」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組合せ、さらには、ファームウェアとの組合せで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、ＲＯＭ９１３等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、上記で述べた「〜部」としてコンピュータ等を機能させるものである。あるいは、上記で述べた「〜部」の手順や方法をコンピュータ等に実行させるものである。
【符号の説明】
【００５８】
１０，２０，３０  サーバ、１１，２１，３１  ＤＢ、１２，１２１，１２２，２２，２２１，２２２，３２１，３２２  ＭＶ、１３，２３，３３  データ更新部、５０  ネットワーク、１００  データ多重化システム。
【図１】
0005439540.tif 000002
【図２】
0005439540.tif 000003
【図３】
0005439540.tif 000004
【図４】
0005439540.tif 000005
【図５】
0005439540.tif 000006
【図６】
0005439540.tif 000007
【図７】
0005439540.tif 000008
【図８】
0005439540.tif 000009
【図９】
0005439540.tif 000010
【図１０】
0005439540.tif 000011
【図１１】
0005439540.tif 000012
【図１２】
0005439540.tif 000013
【図１３】
0005439540.tif 000014
【図１４】
0005439540.tif 000015
【図１５】
0005439540.tif 000016
【図１６】
0005439540.tif 000017