JP2013186557A - データベースの非同期レプリケーション方式 - Google Patents

Abstract

【課題】フロント拠点障害時に、残りの拠点で新しくフロント−バックアップ構成を継続する。
【解決手段】フロントシステム障害時に、優先バックアップシステムがフロントシステムへ、代替バックアップシステムが優先バックアップシステムへ切り替わるようなディザスタリカバリを行う。新フロントシステムから新優先バックアップシステムへのバックアップ転送が即時に可能となるように、各バックアップシステムのレプリケーション処理進行を制御する。これにより、フロントシステム障害発生時に、バックアップシステム間で新たなフロント−バックアップ構成をとることが可能となる。
【選択図】図２

Description

本発明は、フロントシステムのデータベースを元にバックアップシステムのデータベースへレプリケーションを行う、データベースの非同期レプリケーション方式に関する。

従来、フロントシステムのデータベースを元にバックアップシステムのデータベースへレプリケーションを行う方法として、フロントシステムのデータベースを更新した際の更新ログをバックアップシステムに非同期に転送し、同様の更新処理をバックアップシステムで実行して追随する方式が存在する。非同期でレプリケーションを行う場合、フロントシステム障害発生時に更新内容の欠落が発生する可能性があるが、同期式と比べてフロントシステムの処理に与える影響が少なく、レプリケーション処理によるフロントシステムの処理のスループット低下を抑えられるという利点がある。

ここで、１つのフロントシステムと複数バックアップシステムという構成で、フロントシステムから直接それぞれのバックアップシステムへ更新ログを転送し、それぞれに対して非同期レプリケーションを行う場合を考える。各バックアップシステムにおけるレプリケーション処理は独立しているため、それぞれのレプリケーション進行状況も独立して進行する。このような構成において、フロントシステム障害発生時に、バックアップシステムの１つが新たにフロントシステムとなり、新フロントシステムから残りのバックアップシステムに対して同様のレプリケーション処理を開始しようとしたとする。

図１は、このような１つのフロントシステムと複数バックアップシステムという構成を示す図である。

このとき、図１で示すように、新フロントシステム１に未到達および未反映であった更新ログが、残りのバックアップシステム２で既にレプリケーション済みであった場合、バックアップデータベースが先行した状態となってしまい、新フロントシステム１とバックアップシステム２とのデータベース間の不整合が生じる。結果、新フロント−バックアップシステム構成でのレプリケーション処理の継続が不可能となる。そのため、このような構成をとる場合は、新フロントシステムとなるバックアップシステム１のレプリケーション進行状況を、他のバックアップシステム２よりも必ず先行させなければならない。

なお、フロントシステムのデータベースを複数のバックアップシステムへレプリケーションし、フロントシステム障害発生時に新フロントシステム−バックアップシステムを構成するための従来の方式として、特許文献１のように、バックアップシステムをもとに別のバックアップシステムへレプリケーションを行うカスケード方式が存在する。しかし、カスケード方式の場合、末端となるバックアップシステムへの更新ログの到達遅延が大きくなる。また、中継するバックアップシステムで通信障害等が発生すると、末端のバックアップシステムへのレプリケーションにも影響があるなどの問題が指摘されている。

特許第３９５８７５７号公報

このように、高可用性を必要とするシステム構成において、フロント拠点−バックアップ拠点の構成に加えて、システムの正常稼動時は別用途でデータベースをレプリケーションし、必要時にバックアップシステムとして稼動するような拠点を加えた３拠点構成でのバックアップ転送を考える必要がある。このとき、フロント拠点障害時に残りの拠点で新しくフロント-バックアップ構成を継続できるような方式を考える必要がある。

本発明の所定の実施形態に係るレプリケーション方式は、分散配置されたデータベースにおいて、フロントシステムのデータベースを複数のバックアップシステムへ非同期にレプリケーションを行う多重レプリケーション方式であり、フロントシステム障害時に、優先バックアップシステムがフロントシステムへ、代替バックアップシステムが優先バックアップシステムへ切り替わるようなディザスタリカバリを行う。新フロントシステムから新優先バックアップシステムへのバックアップ転送が即時に可能となるように、各バックアップシステムのレプリケーション処理進行を制御する。これにより、フロントシステム障害発生時に、バックアップシステム間で新たなフロント−バックアップ構成をとることが可能となる。

好適には、複数存在するバックアップシステムのうち、フロント障害発生時に新フロントシステムになるバックアップシステムでのレプリケーション進行状況を、残りのバックアップシステムへ通知する。残りのバックアップシステムのレプリケーションは、通知されたレプリケーション進行状況までがレプリケーション可能と判断し、通知されたレプリケーション進行状況までレプリケーション処理を実行する。このような仕組みを導入することで、残りのバックアップシステムのレプリケーション進行状況が新フロントシステムとなるバックアップシステムよりも先行することを避けることができ、フロント障害発生時に新フロントシステムから残りのバックアップシステムへのレプリケーションを継続実施することができる。

本発明の所定の実施形態は、高可用性を必要とするようなミッションクリティカル系のシステムにおいて有効であるが、特に、以下の効果を有し得る。

第１に、本発明の所定の実施形態によれば、フロントシステムに存在するマスタデータベースから複数のバックアップシステムのデータベースへ非同期レプリケーションする際に、特定のバックアップシステムのレプリケーション進行状況を他のバックアップシステムのレプリケーション進行状況よりも先行させることが可能となる。

第２に、レプリケーション進行状況が制御できることにより、フロントシステム障害発生時に、特定のバックアップシステムを新フロントシステムとして稼動させ、新フロントシステムのデータベースから残りのバックアップシステムへのレプリケーションを再開することが可能であり、その際に両システムのデータベースのレプリケーション進行状況によるデータ不整合が発生することを避けることが可能である。

特に、この構成は、バックアップシステムごとに新フロントシステムとして稼動できるまでに必要な時間が異なるような場合に有効である。具体的には次のようなシステム構成をとることが可能になる。フロントシステム障害時に新フロントシステムとなる優先度の高いバックアップシステムは、即座にフロントシステムとなれるようにリソース稼動および要員配置を行う。一方、優先度の低いバックアップシステムはフロントシステム正常時には情報共有等の用途でフロントシステムのデータベースを複製し、フロントシステム障害時にのみ優先度の高いバックアップシステム相当のリソース稼動および要員配置を行う。このようなシステム構成の場合、バックアップシステム間に新フロントシステムになるための優先順位があらかじめ決められているため、本実施形態が有効である。

また、ディザスタリカバリの観点で考えると、新フロントシステムとなる優先度の高いバックアップシステムの配置は、フロントシステムから距離の遠い場所が選択される。このとき、優先度の低いバックアップシステムのほうが優先度の高いバックアップシステムよりもフロントシステムからの距離が近い場合、本発明の所定の実施形態のようなレプリケーション進行制御を行わなければ、優先度の低いバックアップシステムのレプリケーション進行状況が先行してしまう可能性が高い。このようなシステムの配置の場合に、本発明の所定の実施形態は有効となる。

また、第３に、レプリケーション進行状況が制御できることにより、レプリケーション進行状況を先行させたバックアップシステムを新フロントシステムとして稼動させた際に、運用の観点で下記の選択を行うことが可能である。すなわち、更新ログ格納表に格納された未反映の更新ログを全てデータベースに反映させてから、アプリケーションを開始させる。または、更新ログ格納表に格納された未反映の更新ログを破棄して、即座にアプリケーションを開始させる。

第４に、更新ログ自体はフロントシステムから各バックアップシステムへ直接転送しているため、フロントシステムが正常稼動時に、仮に新フロントシステムとなるバックアップシステムで障害が発生した場合は、次の操作で新フロントシステムとなるバックアップシステムを切り替えることが可能である。すなわち、切り替え先のバックアップシステムの反映許可通番を、受信済みの最後の更新ログ通番に替える操作を行う。そして、フロントシステムの更新ログ反映許可通番管理表の優先バックアップシステムを切り替え先のバックアップシステムに替える操作を行う。

このように、新フロントシステムとなるバックアップシステムに障害が発生した場合でも、それぞれのシステム内で操作を行うだけで他のバックアップシステムを新フロントシステムとなるバックアップシステムへ切り替えることが可能である。また、カスケード方式のようにデータを中継するバックアップシステムで障害が発生した際に他のバックアップシステムへのレプリケーション処理に影響が出るようなことが無いため、耐障害性が向上する。

従来のフロント−バックアップシステムの概略構成を示す図である。 本発明の一実施形態に係るフロント−バックアップシステムの概略構成を示すブロック図である。 本実施例における更新ログ反映許可通番管理表００６の一例を示す図である。 本実施例における更新ログ反映通番管理表１１０の一例を示す図である。 本実施例において、ある更新ログがバックアップシステム１のデータベース１０１およびバックアップシステム２のデータベース２０１へ反映される過程を示すフローチャートである。 本発明の他の実施形態に係るフロント−バックアップシステムの概略構成を示すブロック図である。

以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。

図２は、本発明の一実施形態に係るフロント−バックアップシステムの概略構成を示すブロック図である。同図に示すように、本実施例においてフロント−バックアップシステムは、フロントシステム０、バックアップシステム１及びバックアップシステム２を備え、各システムはそれぞれデータベース００１、データベース１０１及びデータベース２０１を備える。

フロントシステム０が備えるデータベース００１は、各バックアップシステムのデータベースのレプリケーション元となるデータベースである。バックアップシステム１は、フロントシステム０に障害が発生した場合に、新しいフロントシステムとして稼動するバックアップシステムである。バックアップシステム２は、フロントシステム０に障害が発生した場合にもそのままバックアップシステムとして稼動するバックアップシステムである。

フロントシステム０は、データベース００１を更新するアプリケーション００２を含む。アプリケーション００２は、更新ログ格納手段００３を備えており、更新ログ格納手段００３によって、データベース更新の更新ログを更新ログ格納表００４に格納する。更新ログ格納表００４には、更新ログの発生順番を示す通番とともに、更新ログが格納される。更新ログ送信手段００５は、更新ログ格納表００４によって格納された更新ログ、更新ログの通番及び反映許可通番を、バックアップシステム１上の更新ログ受信手段１０７およびバックアップシステム２上の更新ログ受信手段２０７へ送信する。ここで、反映許可通番とは、各バックアップシステムが反映してもよい更新ログの最後の通番である。また、更新ログ送信手段００５は、更新ログ受信手段１０７，２０７の要求により、更新ログを再送するような機能を有するものとする。

図３は、本実施例における更新ログ反映許可通番管理表００６の一例を示す図である。同図において、反映許可通番００６１は、更新ログ送信手段００５が送信を行う際に参照される反映許可通番である。通知済み反映許可通番００６２は、各バックアップシステムへ既に通知した反映許可通番を表す。優先バックアップシステム００６３は、反映許可通番を決定する際の基準となるバックアップシステムを表す。

図２に戻り、バックアップシステム１の更新ログ受信手段１０７は、更新ログ送信手段００５から受信した更新ログを更新ログ格納表１０８に格納する。また、受信した反映許可通番を、更新ログ反映通番管理表１１０に記録する。更新ログ反映手段１０９は、更新ログ反映通番管理表１１０を参照し、更新ログ格納表１０８から更新すべき更新ログを取得して、データベース１０１に更新ログを反映する。

図４は、本実施例における更新ログ反映通番管理表１１０の一例を示す図である。更新ログ反映通番管理表１１０は、更新ログの通番を管理する。同図において、反映許可通番１１０１は、更新ログ反映手段１０９がデータベース１０１へ反映することができる更新ログの最後の通番を表す。反映済み通番１１０２は、更新ログ反映手段１０９が反映を実施した最後の通番を表す。なお、バックアップシステム２の更新ログ反映通番管理表２１０も、更新ログ反映通番管理表１１０と同様のデータ構造を備え、反映許可通番２１０１と反映済み通番２１０２を含む。

図２に戻り、バックアップシステム２の更新ログ受信手段２０７、更新ログ格納表２０８、更新ログ反映手段２０９及び更新ログ反映通番管理表２１０は、バックアップシステム１でのそれぞれと同じ機能を有する。

次に、図２の実線の矢印で表した更新ログの流れを元に、図５を用いて、本実施例の動作を説明する。図５は、本実施例において、ある更新ログがバックアップシステム１のデータベース１０１およびバックアップシステム２のデータベース２０１へ反映される過程を示すフローチャートである。図５では、更新ログおよびその通番が各表に格納される過程を中心に記述している。破線で囲まれた記述は、フロントシステム０での処理を示している。実線で囲まれた記述は、左側がバックアップシステム１での処理を示しており、右側がバックアップシステム２での処理を示している。

フロントシステム０のアプリケーション００２がデータベース００１を更新すると同時に、更新ログ格納手段００３は、更新ログ格納表００４に更新ログを格納する（Ｓ５０１）。更新ログ格納時には、更新ログ発生順序を示す通番を付与する。

更新ログ送信手段００５は、更新ログ格納表００４の更新ログ追加状況を定期的に監視し、新しく格納された更新ログが存在していた場合は、更新ログおよびその通番を取得する。また、更新ログ送信手段００５は、各バックアップシステムに送信する反映許可通番を決定する。反映許可通番の決定は、次のように行う。

まず、更新ログ反映許可通番管理表００６の優先バックアップシステム００６３に示されるシステムへ送信する場合（図３の実施例ではバックアップシステム１）、更新ログ格納表００４から取得した最後の更新ログの通番を反映許可通番とする。

次に、更新ログ反映許可通番管理表００６の優先バックアップシステム００６３に示されるシステム以外へ送信する場合（本実施例ではバックアップシステム２）、更新ログ反映許可通番管理表００６の反映許可通番００６１の通番を反映許可通番とする。

更新ログ送信手段００５は、取得した更新ログとその通番、および決定した反映許可通番を、バックアップシステム１の更新ログ受信手段１０７およびバックアップシステム２の更新ログ受信手段２０７へそれぞれ送信する（Ｓ５０２，Ｓ５０７）。送信が完了すると、更新ログ反映許可通番管理表００６の通知済み反映許可通番００６２を更新する。

バックアップシステム１の更新ログ受信手段１０７は、更新ログ送信手段００５から受信した更新ログを更新ログ格納表１０８へ格納する。また、更新ログ反映通番管理表１１０の反映許可通番１１０１を、受信した反映許可通番の値で更新する（Ｓ５０３）。なおバックアップシステム１では、反映許可通番１１０１は更新ログ送信手段００５から受信した最後の更新ログの通番と等しくなる。更新ログ反映通番管理表１１０の更新完了後、更新ログ受信手段１０７は更新ログ反映通番管理表１１０の反映済み通番１１０２の値を取得して、その通番を更新ログ送信手段００５に返信する（Ｓ５０５）。

バックアップシステム１の更新ログ反映手段１０９は、更新ログ反映通番管理表１１０を監視し、反映許可通番１１０１の値が反映済み通番１１０２の値より大きくなっていた場合は、更新ログ格納表１０８から反映許可通番１１０１の通番までの更新ログをデータベース１０１に反映する。バックアップシステム１では、反映許可通番１１０１の値が受信した更新ログの最後の通番であるため、受信した全ての更新ログを反映することになる。更新ログ反映後、更新ログ反映通番管理表１１０の反映済み通番１１０２の通番を更新する（Ｓ５０４）。

バックアップシステム２の更新ログ受信手段２０７は、バックアップシステム１の更新ログ受信手段１０７と同様に、更新ログ送信手段００５から受信した更新ログを更新ログ格納表２０８へ格納し（Ｓ５０８）、更新ログ反映通番管理表２１０の反映許可通番２１０１の値を更新して（Ｓ５０９）、反映済み通番２１０２を返信する。バックアップシステム２では、反映許可通番２１０１は、フロントシステム０の更新ログ反映許可通番管理表００６で管理された反映許可通番となる。

バックアップシステム２の更新ログ反映手段２０９は、バックアップシステム１の更新ログ反映手段１０９と同様の手順で更新ログ格納表２０８に格納された更新ログをデータベース２０１に反映する（Ｓ５１０）。

フロントシステム０の更新ログ送信手段００５は、バックアップシステム１の更新ログ受信手段１０７およびバックアップシステム２の更新ログ受信手段２０７からの返信を受け取ると、返信元のシステムが更新ログ反映許可通番管理表００６の優先バックアップシステム００６３であった場合に、受信した反映済み通番で更新ログ反映許可通番管理表００６の反映許可通番００６１を更新する（Ｓ５０６）。

なお、フロントシステム０の更新ログ送信手段００５は、更新ログ格納表００４の更新ログ追加状況を監視して新しく追加された更新ログが存在しなかった場合でも、更新ログ反映許可通番管理表００６を確認し、反映許可通番００６１が通知済み反映許可通番００６２よりも大きかった場合は、反映許可通番のみを各バックアップシステムへ送信する（Ｓ５０２，Ｓ５０７）。更新ログ受信手段１０７および更新ログ受信手段２０７は、反映許可通番のみを受信した場合は、反映許可通番をそれぞれの更新ログ反映通番管理表へ更新する処理のみを実施する。

以上、図５にも示されているとおり、ある更新ログをバックアップシステム２のデータベース２０１に反映する時点で、その更新ログは必ず既にバックアップシステム１のデータベース１０１に反映されていることになる。これにより、データベース１０１のレプリケーション進行状況は、データベース２０１よりも必ず先行した状態にすることが可能となる。

上記の構成においてフロントシステム０で障害が発生し、バックアップシステム１が新フロントシステムとして稼動する際に、必要となる処理について説明する。新フロントシステムとして稼動する際は、フロントシステム０に存在していたアプリケーション００２、更新ログ格納手段００３、更新ログ格納表００４、更新ログ送信手段００５及び更新ログ反映許可通番管理表００６と同等の機能がそれぞれ開始される。この後、更新ログ送信手段によって、反映許可通番として更新ログ反映通番管理表１１０の反映済み通番１１０２を送信する。これにより、バックアップシステム２の更新ログ反映処理を進行させることで、データベース２０１を新フロントシステム稼動直前のデータベース１０１と同じ状態にすることができる。なお、バックアップシステム２の更新ログ格納表２０８に必要な更新ログが格納されていなかった場合、バックアップシステム１の更新ログ格納表１０８から必要な更新ログを再送信することで対処することが可能である。

上記の実施例では、バックアップシステムを新フロントシステムとして稼動させた際に、未反映の更新ログを破棄して、即座にアプリケーションを開始させることが可能である。一方、次に示す実施例においては、未反映の更新ログを全てデータベースに反映させてから、アプリケーションを開始させることが可能である。

更新ログ反映許可通番管理表００６の反映許可通番００６１に、バックアップシステム１の更新ログ受信手段１０７の受信済み通番を使用する。

上記の実施例の場合、バックアップシステム２のデータベース２０１への更新ログ反映処理が、バックアップシステム１のものより先行する可能性がある。しかし、バックアップシステム２のデータベース２０１へ反映させた更新ログは、バックアップシステム１の更新ログ格納表１０８には必ず格納されている。そのため、新フロントシステムとして稼動する際に、更新ログ格納表１０８に格納された更新ログを全てデータベース１０１に反映させることで、データベース１０１のレプリケーション進行状況をデータベース２０１より先行させることが可能となる。上記の実施例の場合では、バックアップシステム２の更新ログ受信手段１０７が、更新ログを更新ログ格納表１０８に格納できた通番を反映許可通番とするため、上記の実施例よりも、バックアップシステム２のデータベース２０１へのレプリケーション処理の遅延を少なくすることができる。

図６は、本発明の他の実施形態に係るフロント−バックアップシステムの概略構成を示すブロック図である。図２に示す実施形態では、フロントシステム０が正常稼動している際のバックアップシステム１とバックアップシステム２間の通信は非活性であるものとしたが、図６に示す実施形態では、正常時にもバックアップシステム間の通信が活性である場合を仮定している。

本実施形態において、バックアップシステム１は、更新ログ反映済み通番送信手段１１１を備え、バックアップシステム２は、更新ログ反映済み通番受信手段２１２を備える。バックアップシステム１の更新ログ反映済み通番送信手段１１１は、更新ログ反映通番管理表１１０から反映済み通番１１０２の値を取得して、バックアップシステム２の更新ログ反映済み通番受信手段２１２に送信する。バックアップシステム２の更新ログ反映済み通番受信手段２１２は、更新ログ反映済み通番送信手段１１１から受け取った通番で更新ログ反映通番管理表２１０の反映許可通番２１０１を更新する。

本実施例の場合、図２に示した実施例と比較して、以下の点の変更を要する。

まず、更新ログ反映許可通番管理表００６は必要ない。次に、フロントシステム０の更新ログ送信手段００５は反映許可通番を送信しない。また、更新ログ受信手段１０７、２０７は更新ログ反映通番管理表１１０、２１０の参照および更新をせず、更新ログ送信手段００５へ反映済み通番を返信しない。さらに、更新ログ反映通番管理表１１０の反映許可通番１１０１の値は、更新ログ反映手段１０９が全ての更新ログを反映してもよいと判断できるような特殊な値（例えば、通番が１から始まるとして、−１といった値など）を格納する。

なお、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限
られない。

（付記１）フロントシステムと、第１及び第２のバックアップシステムとを備え、フロントシステムのデータベースを第１及び第２のバックアップシステムのデータベースへレプリケーションを行うフロント−バックアップシステムであって、第１のバックアップシステムのレプリケーション進行状況を管理する手段と、進行状況を参照して、第２のバックアップシステムのレプリケーションの進行状況を制御する手段と、を備えるフロント−バックアップシステムである。

（付記２）管理する手段は、第１のバックアップシステムのデータベースに更新ログを反映させる第１の更新ログ反映手段と、第１のバックアップシステムのデータベースに反映された反映済み更新ログの通番を管理する管理表と、を備えることを特徴とする付記１記しあのフロント−バックアップシステムである。

（付記３）制御する手段は、管理表に管理されている反映済み更新ログの通番を第２のバックアップシステムに送信する更新ログ送信手段と、 通番に基づいて、第２のバックアップシステムのデータベースに、更新ログを反映させる第２の更新ログ反映手段と、を備えることを特徴とする付記２記載のフロント−バックアップシステムである。

（付記４）フロントシステムに障害が発生したとき、第１のバックアップシステムは、新たなフロントシステムとして機能し、第２のバックアップシステムは、新たな優先バックアップシステムとして機能することを特徴とする付記３記載のフロント−バックアップシステムである。

（付記５）フロントシステムと、第１及び第２のバックアップシステムとを備えるシステムにおいて、フロントシステムのデータベースを第１及び第２のバックアップシステムのデータベースへレプリケーションを行う方法であって、第１のバックアップシステムのレプリケーション進行状況を管理し、進行状況を参照して、第２のバックアップシステムのレプリケーションの進行状況を制御する、方法である。

０ フロントシステム、００１ データベース、００２ アプリケーション、００３ 更新ログ格納手段、００４ 更新ログ格納表、００５ 更新ログ送信手段、００６ 更新ログ反映許可通番管理表、００６１ 反映許可通番、００６２ 通知済み反映許可通番、００６３ 優先バックアップシステム、１ （第１の）バックアップシステム、２ （第２の）バックアップシステム、１０１，２０１ データベース、１０７，２０７ 更新ログ受信手段、１０８，２０８ 更新ログ格納表、１０９，２０９ 更新ログ反映手段、１１０，２１０ 更新ログ反映通番管理表、１１０１，２１０１ 反映許可通番、１１０２，２１０２ 反映済み通番、１１１ 更新ログ反映済み通番送信手段、２１２ 更新ログ反映済み通番受信手段。

Claims (5)

1. フロントシステムと、第１及び第２のバックアップシステムとを備え、前記フロントシステムのデータベースを前記第１及び第２のバックアップシステムのデータベースへレプリケーションを行うフロント−バックアップシステムであって、
   前記第１のバックアップシステムのレプリケーション進行状況を管理する手段と、
   前記進行状況を参照して、前記第２のバックアップシステムのレプリケーションの進行状況を制御する手段と、
   を備えるフロント−バックアップシステム。
2. 前記管理する手段は、
   前記第１のバックアップシステムのデータベースに更新ログを反映させる第１の更新ログ反映手段と、
   前記第１のバックアップシステムのデータベースに反映された反映済み更新ログの通番を管理する管理表と、
   を備えることを特徴とする請求項１記載のフロント−バックアップシステム。
3. 前記制御する手段は、
   前記管理表に管理されている前記反映済み更新ログの通番を前記第２のバックアップシステムに送信する更新ログ送信手段と、
   前記通番に基づいて、前記第２のバックアップシステムのデータベースに、更新ログを反映させる第２の更新ログ反映手段と、
   を備えることを特徴とする請求項２記載のフロント−バックアップシステム。
4. 前記フロントシステムに障害が発生したとき、前記第１のバックアップシステムは、新たなフロントシステムとして機能し、前記第２のバックアップシステムは、新たな優先バックアップシステムとして機能することを特徴とする請求項１〜３のいずれか１項に記載のフロント−バックアップシステム。
5. フロントシステムと、第１及び第２のバックアップシステムとを備えるシステムにおいて、前記フロントシステムのデータベースを前記第１及び第２のバックアップシステムのデータベースへレプリケーションを行う方法であって、
   前記第１のバックアップシステムのレプリケーション進行状況を管理し、
   前記進行状況を参照して、前記第２のバックアップシステムのレプリケーションの進行状況を制御する、方法。

Images