(57)【要約】【課題】  緊急地震速報データを利用し、地震到達までの数十秒間でトランザクションの流量を制御することで、メインサイトのオンライン性能に影響を与えず、かつメインサイト被災時にもデータ損失の無いディザスタリカバリシステムを提供する。【解決手段】  緊急地震速報データを受信する地震情報受信手段と、トランザクション制御条件を格納した管理サーバ、アプリケーションサーバ上で起動する制御エージェントから構成され、緊急地震データを管理サーバが受信したならば予め設定されたトランザクション制御条件と比較し、条件を満たした場合に、制御エージェントに対して、更新系トランザクションの停止を指示する。これにより、更新系トランザクションは、地震到達の数秒前に停止され、停止前の更新系トランザクションによって発生した更新ログデータはすべて地震到達前にバックアップサイトへの転送が完了する。【選択図】      図１
2009223860.tif 000002
【特許請求の範囲】
【請求項１】
緊急地震速報データを受信する地震情報受信手段と、更新系トランザクションの制御条件を格納した管理サーバと、データベースを更新するアプリケーションサーバ上で起動する制御エージェントとから構成され、
前記管理サーバが、
更新系トランザクションの停止条件を定める震度データ等のトランザクション制御条件を格納した制御条件データベースと、前記地震情報受信手段から緊急地震データを受信したならば、前記制御条件データベースに格納されたトランザクション制御条件と比較し、前記地震情報受信手段から受信した緊急地震データが更新系トランザクションの停止条件を満たしていた場合に、前記制御エージェントに対して、更新系トランザクションの停止を指示する手段を備えることを特徴とするディザスタリカバリシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ディザスタリカバリシステムに関し、特に緊急地震速報データを利用したトランザクョン制御方式を用いた非同期型更新ログ転送方法によるディザスタリカバリシステムに関するものである。
【背景技術】
【０００２】
近年、自然災害発生時にもシステムを停止することなくビジネスを継続し、利益の損失を最小限に抑える事を目的とするDR（Disaster Recovery）や、BCP（Business Continuity Plan）への取り組みが行われている。
これらの実現方法の一つとして、通常業務を行うメインサイトとは別に、数十〜数百Kmの遠隔地にバックアップサイトを構築し、メインサイトが被災などによって業務継続が不可能な場合、速やかにバックアップサイトに切り替えることで業務を継続する方法がある。
これを実現するためには、メインサイト側とバックアップサイト側のデータベースの内容が、常に同じでなければならない。これは、メインサイト側のデータベースの更新ログデータをバックアップサイトへ転送し、バックアップサイト側のデータベースに更新ログを適用することで可能となる。
【０００３】
図５は、メインサイト側のデータベースの更新ログデータをバックアップサイトへ転送し、バックアップサイト側のデータベースに更新ログを適用するシステムの概要を示すシステム構成図である。
図５において、メインサイト５０ＭはＷＥＢサーバ５０１、アプリケーションサーバ５０２、ＤＢサーバ５０３で構成され、ＤＢサーバ５０３はアプリケーションサーバ５０２の処理結果を保存する。
また、バックアップサイト５０Ｂは、ＷＥＢサーバ５０４、アプリケーションサーバ５０５、ＤＢサーバ５０６で構成され、メインサイト５０ＭのＤＢサーバ５０３の更新ログを受信し、ＤＢサーバ５０６の格納情報をメインサイト５０ＭのＤＢサーバ５０３の格納情報と同じになるように更新する。もしも、メインサイトが被災によって業務の継続が不可能になった場合には、バックアップサイト５０ＢのＷＥＢサーバ５０４、アプリケーションサーバ５０５が業務を引継ぐ。
このようなシステムの公知技術文献として下記の特許文献１がある。
【０００４】
【特許文献１】特開２００３−２３２０４５  特に日本における自然災害において最も脅威となるのが地震災害である。この地震に関しては、２００７年から気象庁による緊急地震速報が開始されている。これは、震源地付近で検知されたP波の初動データを使って求めた震源情報を瞬時に各所に伝達するもので、緊急地震速報の配信により、遅れてくるS波の到達を事前に知らせることによる警戒効果を狙うものである。震源地のとの距離にもよるが、一般的に速報受信からS波到達までの時間差、数秒〜数十秒を活用するものであり、地震災害のほとんどはこのS波到達以降に集中する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
図５で示したメインサイト５０Ｍからバックアップサイト５０Ｂへの更新ログデータの転送方式には、「非同期方式」と「同期方式」の２つがある。
「非同期方式」では、メインサイト５０Ｍからバックアップサイト５０Ｂへの更新ログ転送の完了を待たずにトランザクションを完了する。そのため、データベースのオンライン性能には、ほとんど影響を与えない。しかし、災害発生のタイミングによっては、バックアップサイト５０Ｂに転送されない更新ログデータが発生するため、データ損失が発生する可能性がある。
これに対し「同期方式」では、データベースに関連するトランザクションの決着を、メインサイト５０Ｍからバックアップサイト５０Ｂへの更新ログ転送が完了するまで待つため、データ損失はゼロである。しかし、レスポンスタイム遅延などといったデータベースのオンライン性能に影響を与える。
このように上記２つの転送方式には、相反する利点と欠点が存在する。
【０００６】
本発明では、上記の問題点を鑑み、緊急地震速報情報を利用し、地震到達までの数十秒間で更新系トランザクションを制御することで、メインサイトのオンライン性能に影響を与えず、かつメインサイト被災時にもデータ損失の無いディザスタリカバリシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明の地震速報データを利用したディザスタリカバリシステムは、緊急地震速報データを受信する地震情報受信手段と、更新系トランザクションの制御条件を格納した管理サーバと、データベースを更新するアプリケーションサーバ上で起動する制御エージェントとから構成され、
前記管理サーバが、
更新系トランザクションの停止条件を定める震度データ等のトランザクション制御条件を格納した制御条件データベースと、前記地震情報受信手段から緊急地震データを受信したならば、前記制御条件データベースに格納されたトランザクション制御条件と比較し、前記地震情報受信手段から受信した緊急地震データが更新系トランザクションの停止条件を満たしていた場合に、前記制御エージェントに対して、更新系トランザクションの停止を指示する手段を備えることを特徴とする。
【発明の効果】
【０００８】
本発明によれば、通常時は、メインサイトからバックアップサイトへの更新ログデータの転送に、非同期方式を用いることで、メインサイトのオンライン性能に影響を与えず、かつメインサイト被災時にはデータ損失の無い、ディザスタリカバリシステムを実現することが可能になる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態を図面を参照して詳細に説明する。
図１は、本発明の一実施形態を示すシステム構成図である。
この実施形態の地震速報データを利用したディザスタリカバリシステムでは、通常時に業務を行うメインサイト１０Ｍと、メインサイト１０Ｍが被災によって業務継続が不可能な場合に業務を代行するバックアップサイト１０Ｂから構成される。
メインサイト１０Ｍは、インターネット１１に接続された第１ＷＥＢサーバ１０８、地震情報受信機１０１と、ファイアウォール（ＦＷ）１１２に接続された第１アプリケーションサーバ１０９と、第１ＤＢサーバ１１１と管理サーバ１００から構成される。
ファイアウォール１１２の内側に存在する管理サーバ１００は、外部からの不正アクセスや攻撃を受けることはない。
【００１０】
管理サーバ１００は、地震情報受信機１０１から地震データを受信し、地震情報ＤＢ１０６に格納する受信部１０２と、トランザクション制御の実行条件を格納する制御条件ＤＢ１０７と制御条件ＤＢ１０７に新規条件を設定、または変更、削除、確認を行う設定部１０５と、実際に地震が発生した場合に地震情報と制御条件ＤＢ１０７の内容を比較判定する判定部１０３と、判定した結果、トランザクション制御を実行する場合に、第１アプリケーションサーバ１０９上で起動している制御エージェント１１０に対して、実行命令を出す実行部１０４から構成される。
【００１１】
バックアップサイト１０Ｂは、インターネット１１に接続された第２ＷＥＢサーバ１１３と、ファイアウォール（ＦＷ）１１４に接続された第２アプリケーションサーバ１１５、第２ＤＢサーバ１１６から構成される。
第１ＤＢサーバ１１１と第２ＤＢサーバ１１６は、ルータ１１７を介して接続されており、通常時は、第１ＤＢサーバ１１１の更新処理に伴い発生したＤＢ更新ログデータは第２ＤＢサーバ１１６へ転送され、適用される。
【００１２】
図２は、管理サーバ１００の地震情報ＤＢ１０６に格納されている地震データの一例を示す図である。
図２に示すように、地震データは、受信日２０１、受信時刻２０２、予測震度２０３、予測到達時刻２０４の各データから構成されている。本データは、地震発生時に専用回線を介して配信される緊急地震速報を地震情報受信機１０１が受信し、即座に管理サーバ１００に送信されるものである。
管理サーバ１００では受信部１０２がデータを受信し、地震情報ＤＢ１０６にデータを格納する。
【００１３】
図３は、管理サーバ１００の制御条件ＤＢ１０７に格納されている制御条件の一例を示す図である。図に示すように、制御条件のデータは、登録日３０１、開始日３０２、開始時刻３０３、終了日３０４、終了時刻３０５、震度３０６、制御開始余裕値３０７の各データから構成されている。
本データは、管理サーバ１００の設定部１０５で予めユーザが設定する必要がある。
登録日３０１は、ユーザが登録を実行した日付を示す。
開始日３０２、開始時刻３０３は、登録された制御条件の有効開始日と時刻を、終了日３０４と終了時刻３０５は、制御条件の有効終了日と時刻を示す。
震度３０６は、緊急地震速報の予測震度がこの値以上の場合にトランザクション制御を実行する。制御開始余裕値は、秒数が定義される。この値は、トランザクション制御を実施する場合に、地震到達時刻の何秒前に制御を開始するかを示す。
例えば、業務特性で、ある時間帯にトランザクションが集中するような場合、制御開始余裕値を大きめに設定することで、トランザクション制御開始から地震予測到達時刻までの時間を長くすることができ、その間に未決着トランザクションが決着し、ＤＢ更新ログが確実にバックアップサイト側の第２ＤＢサーバに転送される。
【００１４】
図４は、管理サーバ１００の判定部１０３の処理を示すフローチャートである。
管理サーバ１００の受信部１０２が地震情報受信機１０１から地震速報データを受信すると、判定部１０３の処理が開始される。
まず、ステップ４０１では現在の日付、時刻、受信した予測震度をそれぞれ変数にセットする。
ステップ４０２では、ステップ４０１でセットした３変数をキーとして制御条件ＤＢ１０７から条件を満たすレコードを検索する。
ステップ４０３では、ステップ４０２の結果をレコードの有無で条件判定する。レコードが存在しなければ終了し（ステップ４０５）、レコードが存在する場合は、ステップ４０４に移る。
ステップ４０４では、地震到達時刻から該当レコードに設定されている余裕値を減算し、制御開始時刻を決定する。
ステップ４０６では、制御開始時刻と現在時刻を比較する。制御開始時刻を過ぎている場合は、ステップ４０８に移り、直ちにトランザクション制御（実行部）を開始する。
制御開始時刻を過ぎていない場合は、ステップ４０７に移る。
ステップ４０７では、制御開始時刻になるまで待機し、開始時刻になったならば、ステップ４０８に移り、トランザクション制御を開始する。
【００１５】
管理サーバ１００の実行部１０４は、判定部１０３の処理フローで条件を満たし場合に呼び出され、第１アプリケーションサーバ１０９上で起動している制御エージェント１１０に実行命令を出す。
制御エージェント１１０には予め、トランザクションを発行するアプリケーションに応じた制御スクリプトが組み込まれており、これが実行されることで、更新系トランザクションのみを停止する。結果として、地震到達までにすべての更新ログデータがバックアップサイト１０Ｂへ転送され、第２ＤＢサーバ１１６に反映される。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施の形態を示すシステム構成図である。
【図２】地震情報データベースの格納情報の例を示す図である。
【図３】制御条件データベースの格納情報の例を示す図である。
【図４】管理サーバの判定部の処理を示すフローチャートである。
【図５】従来のディザスタリカバリシステムの概要を示す図である。
【符号の説明】
【００１７】
１０Ｍ    メインサイト
１０Ｂ    バックアップサイト
１００    管理サーバ
１０１    地震情報受信機
１０３    判定部
１０４    実行部
１０５    設定部
１０６    地震情報ＤＢ
１０７    制御条件ＤＢ
１１０    エージェント
【図１】
2009223860.tif 000003
【図２】
2009223860.tif 000004
【図３】
2009223860.tif 000005
【図４】
2009223860.tif 000006
【図５】
2009223860.tif 000007