マスターデータベースの更新ログを複製データベースに伝達する通信路の切替時、前記マスターデータベースを有する第1のコンピュータが、切替前後の通信路に同期データを送信し、前記複製データベースを有する第2のコンピュータが、切替前後の通信路から前記同期データを受信するまで、前記同期データに続いて受信する前記更新ログに基づく前記複製データベースの更新処理を保留することを特徴とするデータベースのレプリケーション方法。前記同期データは、同期を取る必要のある複数の通信路を特定する同期対象通信路情報を含み、前記第2のコンピュータは、受信した前記同期データに含まれる前記同期対象通信路情報で特定される複数の通信路で前記同期データを受信したときに、切替前後の全ての通信路から前記同期データを受信したと判断することを特徴とする請求項1に記載のデータベースのレプリケーション方法。前記同期データは、版数を含み、前記第1のコンピュータは、前記通信路の切替毎に、以前の版数と異なる版数を含む同期データを切替前後の通信路に送信し、前記第2のコンピュータは、切替前後の全ての通信路から同じ版数の前記同期データを受信するまで、前記版数の同期データに続いて受信する前記更新ログに基づく前記複製データベースの更新処理を保留することを特徴とする請求項1または2に記載のデータベースのレプリケーション方法。前記通信路は、前記第1のコンピュータに設けられる第1の手段と、前記第2のコンピュータに設けられる第2の手段とから構成され、前記第1の手段は、前記マスターデータベースの更新ログを記憶する第1の記憶手段と、該第1の記憶手段に記憶された更新ログを前記第2の手段に送信する送信手段とを有し、前記第2の手段は、前記送信手段から送信された更新ログを受信する受信手段と、該受信手段で受信された更新ログを記憶する第2の記憶手段とを有することを特徴とする請求項1乃至3の何れかに記載のデータベースのレプリケーション方法。前記通信路の切替は、前記マスターデータベースおよび前記複製データベースの再構成に伴って行われることを特徴とする請求項1乃至4の何れかに記載のデータベースのレプリケーション方法。前記通信路は、前記マスターデータベースと前記複製データベースとの組合せ毎に設けられることを特徴とする請求項5に記載のデータベースのレプリケーション方法。ところで、更新ログを転送する通信路を別の通信路に切替えることがある。しかし、このような通信路の切替えを上述したレプリケーション方法の下で実施すると、複製データベースの更新の順序性を保証することができなくなる。例えば、前述した例において、更新1の更新ログL1を通信路PH1に送出した直後に通信路の切替えを行い、以後、通信路PH1の代わりに通信路PH2を使用したとする。このとき、図18に示すように、更新2の更新ログL2は通信路PH2を流れるため、過度的に、同じデータベースの更新ログL1、L2が複数の通信路PH1、PH2を流れることになる。従って、若し、後から送信された更新ログL2が更新ログL1よりも先にバックアップシステムBSに到着して処理されると、複製データベースRDは、更新2、更新1の順序で更新される。この結果、それらの更新が同一のデータを対象とする場合にはデータに矛盾が生じることになる。本発明の目的は、上述した課題、すなわち、更新ログを転送する通信路を別の通信路に切替えると複製データベースの更新の順序性を保証することができなくなる、という課題を解決するデータベースのレプリケーション方法を提供することにある。本発明の一形態にかかるデータベースのレプリケーション方法は、マスターデータベースの更新ログを複製データベースに伝達する通信路の切替時、前記マスターデータベースを有する第1のコンピュータが、切替前後の通信路に同期データを送信し、前記複製データベースを有する第2のコンピュータが、切替前後の通信路から前記同期データを受信するまで、前記同期データに続いて受信する前記更新ログに基づく前記複製データベースの更新処理を保留するといった構成を採る。本発明は上述した構成を有するため、更新ログを転送する通信路を別の通信路に切替えても複製データベースの更新の順序性を保証することができる。次に本発明の実施の形態について図面を参照して詳細に説明する。第1の実施形態図16を参照すると、本発明の第1の実施形態は、フロントシステムFSと、バックアップシステムBSと、これらを通信可能に接続する通信路PH1、PH2とから構成される。フロントシステムFSは、サーバ装置などの情報処理装置である。フロントシステムFSは、マスターデータベースMDと更新ログ格納手段LWとを有する。バックアップシステムBSは、サーバ装置などの情報処理装置である。バックアップシステムBSは、マスターデータベースMDの複製である複製データベースRDと更新ログ反映手段LRとを有する。マスターデータベースMDとその複製データベースRDは、例えばKVSキーバリューストアあるいはそれ以外の任意の種類のデータベースである。通信路PH1、通信路PH2は、マスターデータベースMDの更新ログをフロントシステムFSからバックアップシステムBSへ転送する機能を有する。通信路PH1および通信路PH2内では、それぞれ更新ログの順序性は保証されている。本実施形態では、通信路をPH1からPH2に切替えることを想定している。通信路PH1、PH2のそれぞれは、例えば、フロントシステムFSに設けられる第1の記憶手段および送信手段と、バックアップシステムBSに設けられる受信手段および第2の記憶手段とから構成される。第1の記憶手段は、マスターデータベースMDの更新ログを記憶する送信バッファとして機能する。送信手段は、第1の記憶手段に記憶された更新ログをLANやWANなどのネットワークを通じて、同じ通信路を構成するバックアップシステムBS側の受信手段に向けて送信する。受信手段は、受信した更新ログを第2の記憶手段に記憶する。第2の記憶手段は受信バッファとして機能する。更新ログ格納手段LWは、マスターデータベースMDの更新時、その更新ログを現在使用している通信路を通じてフロントシステムFSからバックアップシステムBSへ送信する機能を有する。また更新ログ格納手段LWは、通信路の切替え時、切替前の通信路PH1および切替後の通信路PH2に同期データを送信する機能を有する。同期データは、更新ログと明確に識別できる形式であれば、その形式は任意である。更新ログ反映手段LRは、通信路PH1、PH2を通じて受信した更新ログに従って複製データベースRDを更新する機能を有する。また更新ログ反映手段LRは、通信路の切替時、切替前後の通信路PH1、PH2から同期データを受信するまで、同期データに続いて受信する更新ログに基づく複製データベースRDの更新処理を保留する機能を有する。次に本実施形態の動作を説明する。今、フロントシステムFSの更新ログ格納手段LWが、マスターデータベースMDに対して実施された更新1の更新ログL1を通信路PH1に送出した直後に、通信路の切替えが行われたとする。このとき、更新ログ格納手段LWは、図16に示すように、切替前の通信路PH1に同期データDを送信すると共に、切替後の通信路PH2に同期データDを送信する。そして、更新ログ格納手段LWは、更新1より後に実施される更新2の更新ログL2を切替後の通信路PH2へ送信する。バックアップシステムBSの更新ログ反映手段LRは、通信路の切替時、切替前後の通信路から同期データを受信するまで、同期データに続いて受信する更新ログに基づく複製データベースRDの更新処理を保留する。従って、例えば通信路PH1よりも通信路PH2の方が高速であったり、あるいは通信路PH1の受信バッファに多くの更新ログが蓄積されている等の理由で、更新ログ反映手段LRが、更新ログL1より後に送信された通信路PH2の同期データDを先に処理すると、切替前の通信路PH1から未だ同期データDを受信していないので、通信路PH2から受信する更新ログL2の処理を保留する。そして、その後、通信路PH1から受信した更新ログL1に従って複製データベースRDを更新し、次いで通信路PH1から同期データDを受信したことを確認した時点で、上記保留状態を解除し、上記更新ログL2に従って複製データベースRDを更新する。このように本実施形態によれば、更新ログを転送する通信路を別の通信路に切替えても複製データベースの更新の順序性を保証することができる。なお、本実施形態は各種の付加変更が可能である。例えば、上記の実施形態では、更新ログ反映手段LRは、同期を取る対象の通信路が通信路PH1と通信路PH2であることを事前に認識しているものとしたが、同期データDに、同期を取る必要のある通信路PH1、PH2を特定する同期対象通信路情報を持たせるようにしても良い。この場合、更新ログ反映手段LRは、受信した同期データDに含まれる同期対象通信路情報で特定される通信路PH1、PH2で同期データを受信したときに、切替前後の全ての通信路から同期データを受信したと判断する。また、同期データDに、版数を持たせるようにしても良い。この場合、フロントシステムFSの更新ログ格納手段LWは、通信路の切替毎に、以前の版数と異なる版数を含む同期データを切替前後の通信路に送信する。また、バックアップシステムBSの更新ログ反映手段LRは、切替前後の全ての通信路から同じ版数の同期データを受信するまで、その版数の同期データに続いて受信する更新ログに基づく複製データベースRDの更新処理を保留する。さらに、更新ログ反映手段LRは、通信路PH1、PH2毎に設けるようにしても良い。また、通信路を切替える要因は、任意である。例えば、システムのスループットを向上するために、通信路PH1をより高速な通信路PH2に切替えてもよい。あるいは、後述する第2の実施形態で説明するように、データベースの再構成に応じて通信路を切替えてもよい。第2の実施形態[概要]本実施形態は、分散配置されたデータベースの更新ログをフロントシステムからバックアップシステムへ反映させる際、任意の時点でデータベースが動的に再構成された場合に、再構成前後に発生した更新ログの間でバックアップシステムへ更新する順序性を保証する。[本実施形態が解決しようとする課題]データベースを含むシステムにおいて、フロントシステムのデータベースをバックアップシステムへレプリケーションする方式としては、フロントシステムでの処理に大きな影響を与えないために、フロントシステムでの更新内容をバックアップシステムへ転送して同様の内容を非同期的に更新するといった方式が一般的にとられている。本実施形態もそのようなバックアップ処理を前提とする。また、データベースは複数存在し、更新対象のキーごとに更新先データベースが決められるような分散配置データベースを前提とする。さらに、バックアップ処理は、分散されたデータベースごとに処理系列を分けて更新ログの転送更新を行うことで、バックアップ転送反映のスループットの向上を図っている。ここで、処理系列は第1の実施形態における通信路に相当し、1つの処理系列では転送更新の順序性は保証されているものとする。分散配置されたデータベースは、1つのデータベースが高負荷状態になったときの負荷分散を行う等の場合に、動的に再構成される。データベースの再構成は、フロントシステムではフロントシステムのデータベースを元に、バックアップシステムではバックアップシステムのデータベースを元に実施される。バックアップシステムのデータベースを再構成する際に、フロントシステムのデータベースが再構成される前の更新ログが未反映だった場合は、再構成後のバックアップシステムのデータベースにフロントシステムの再構成前の更新ログを反映する。上述のようなシステムにおいて、データベースの動的な再構成が行われた際に、データベースのあるキーに対する更新ログのバックアップへの反映は、データベース再構成の前後で異なる処理系列で行われる可能性があるため、バックアップシステムへの更新の順序性が保証できなくなる問題が発生する。このような問題は、バックアップシステムへの更新ログの自動反映を一旦停止してから、バックアップシステムへ転送された再構成前更新ログ再構成後更新ログを直接確認して手動で反映させることで解決できる。しかし、データベース再構成を実施する毎にバックアップシステムでの手動作業が発生してしまうため、その作業の手間と時間が必要になるという課題がある。本実施形態は上述した課題を解決するために、データベース再構成が行われた際にカウントアップされるような版数を導入し、版数が上がったときに再構成に関わる全ての処理系列に対して同期を行うためのデータをバックアップ処理に挿入してバックアップシステムへ転送する。また、同期データには同期を取る処理系列一覧を格納する。バックアップシステム側では同期データを受け取った際に、残りの同期データが届くまで待ち合わせを行い、全ての同期データを受けとった後に以降の更新ログを反映する処理を再開する。これにより、再構成前後の更新ログの順序性を保証することができ、再構成前後での自動的なバックアップ処理が可能となる。[構成の説明]図1を参照して、本実施形態の全体構成を説明する。全体構成は大きく分けて、フロントシステム100とバックアップシステム200とに分かれている。フロントシステム100のデータベース01-1~4は、それぞれに同じ表が存在し、更新対象のレコードのキーによってどのデータベースに更新するかが決まっている分散配置型データベースである。図1では例として4重で構成された場合を示している。データベース01-1~4には、それぞれにバックアップ転送の処理系列が存在する。例えば、図1のデータベース01-1に対するバックアップ転送の処理系列処理系列1とするは、更新ログ格納表04-1、更新ログ送信機能05-1、更新ログ受信機能06-1、更新ログ格納表07-1、および更新ログ反映機能08-1であり、データベース10-1が反映先のデータベースである。それぞれの処理系列内では更新ログ反映の順序性は保証されている。フロントシステム100のアプリケーション02は複数存在し、各々がデータベースの更新を行う。アプリケーション02は、更新対象のキーによって更新を行うデータベースを選択する。アプリケーション02には更新ログ格納機能03が存在し、データベースを更新した際にその更新ログを対応する更新ログ格納表04-1~4に格納する。更新ログ送信機能05-1~4は、同じ処理系列の更新ログ格納表04-1~4からそれぞれ更新ログを参照し、同じ処理系列の更新ログ受信機能06-1~4に送信する。更新ログ受信機能06-1~4は、同じ処理系列の更新ログ送信機能05-1~4から送信された更新ログを受信し、同じ処理系列の更新ログ格納表07-1~4に更新ログを格納する。更新ログ反映機能08-1~4は、対応する更新ログ格納表07-1~4から更新ログを参照し、更新ログで示されたキーによって更新を行うデータベース10-1~4を選択し、その選択したデータベース10-1~4へ更新ログで示された更新後データを用いて更新を行う。同期情報管理表09は、更新ログ反映機能08-1~4から参照更新され、処理系列間の同期情報を管理する。フロントシステムの版管理機能11は、データベースの再構成が行われる際に版管理表12を更新する。図2に更新ログ格納表04-1~4、07-1~4の例を示す。表の通番は、更新ログが格納された際に採番される番号であり、処理系列内の更新順序を表している。版数は、更新ログが格納された時点での版数を表している。版数は、データベース再構成時にカウントアップされる番号である。処理実行には、更新ログの内容がバックアップシステムのデータベースへ反映させるものであった場合にYES、反映させないものすなわち、同期データであった場合にNOが格納される。同期対象処理系列には、同期をとる必要のある他処理系列を表している。更新ログには、データベース更新時の更新ログが格納される。図3に同期情報管理表09の例を示す。表の処理系列は、そのレコードで管理する処理系列を表している。版数は、取得確認済みの更新ログの版数を表している。同期対象処理系列は、版数更新時の同期対象処理系列を表している。同期対象処理系列がない場合はなしと表す。図4に版管理表12の例を示す。表の版数は現在の版数を表す。処理系列は、そのレコードが管理している処理系列を表している。同期対象処理系列は、データベース再構成前後で同期を取る必要のある他処理系列の一覧を表している。同期済みは、データベース再構成後に発生する同期データがまだ更新ログ格納表に書き込まれていない場合に未を、既に書き込まれている場合に済を表す。[動作の説明]図1を参照してバックアップコピーの動作を説明する。アプリケーション02は、データベース更新時に更新対象レコードのキーから更新先データベースを決定して、データベースを更新する。ここではデータベース01-1に更新を行った場合を例に説明する。アプリケーション02がデータベース01-1へ更新を行うと、更新ログ格納機能03は、版管理表12から現時点の版数を取得し、更新先である処理系列1のレコードの同期済みが済であることを確認してから、更新ログ格納表04-1に、更新対象レコードのキーおよび更新後の値を含む更新ログを格納する。このとき、更新ログ格納機能03は、通番を採番して、その通番と一緒に更新ログの格納を行う。各処理系列の通番は、複数存在するアプリケーション02で共通に管理されている。また版数も一緒に格納する。以下、更新ログ格納表に格納されている更新ログを、その更新ログと一緒に格納されている通番、版数、処理実行、同期対象処理系列とあわせて、単に更新ログと呼ぶことがある。更新ログ送信機能05-1は、更新ログ格納表04-1に格納された更新ログを更新ログ受信機能06-1へ送信する。更新ログ受信機能06-1は、更新ログを受信すると、更新ログ格納表07-1に更新ログを格納する。更新ログ反映機能08-1は、更新ログ格納表07-1から更新ログを取得し、同期データでない場合は、更新ログをデータベース10-1に反映させる。次に、ある時点でデータベースの再構成が行われた場合の動作を説明する。図5はデータベース再構成前後の処理系列の変化を示している。図5ではデータベース再構成の例として、再構成前のデータベース01-1に存在するキー1~10を、データベース01-1とデータベース01-5に分散させるような再構成を示している。以下では図5で示す再構成の例で説明を行う。データベースの再構成が行われた場合、再構成前後の更新ログの順序性について、次のような問題が生じる。再構成前後の更新ログの転送反映順序について、図6に示す。処理系列1と処理系列5は、それぞれが担当している更新ログに対しては順序性を保証して転送反映が行われる。しかし、処理系列1と処理系列5の間の更新ログは順序性に関して独立しているため、再構成前の処理系列1の更新ログよりも再構成後の処理系列5の更新ログが先にバックアップシステムに到達した場合、再構成後の更新ログが再構成前の更新ログより先に反映される可能性がある。このとき、再構成前後の更新ログにおいて同一のキーに対する更新ログが存在した場合、更新順序の逆転が発生するため、順序性が保証されない。このような問題を解決するため、本実施形態ではデータベースの再構成時に以下で示すような処理で順序性の保証を行う。データベースの再構成が実施された際に、版管理機能11は版管理表12の更新を行う。図7に版管理表12の更新の様子を示す図7の→。具体的な更新内容は下記の通りである。版数を、再構成前の版数に1加えた値に変更する図7では5→6再構成に関係する処理系列のレコード図7では処理系列1と5に対して、同期対象処理系列に同期する必要のある処理系列一覧を格納し、同期済みに同期データ書き込み前を表す未を格納する。処理系列が新たに発生した場合図7では処理系列5の場合は、新規処理系列のレコードを作成して更新する。再構成に関係しない処理系列のレコードには、同期対象処理系列をなしにして、同期済みは済のままで更新する。更新ログ格納機能03の処理フローチャートを図10に示す。更新ログ格納機能03は、版管理表12を参照した際、更新対象処理系列のレコードの同期済みが未となっていた場合はS1、S2、更新ログを格納する前に更新ログ格納表に同期データを格納するS5。更新ログ格納機能03が処理系列1に対して更新を行う例で考えると、版管理表12の処理系列が1であるレコードの同期済みが未になっているので、同期データを更新ログ格納表04-1に格納する。同期データには、版管理表12の同期対象処理系列に表された処理系列一覧が格納されている。同期データを格納後に、版管理表12の同期済みを済に更新しS6、本来格納する予定であった更新ログを更新ログ格納表04-1に格納するS7。同期データと再構成前後の更新ログを格納した更新ログ格納表の例を図8に示す。更新ログの格納が完了したら、更新ログ格納機能03は、版管理表12から同期対象処理系列に格納した処理系列本例では処理系列5のレコードの同期済みを参照しS8、未である場合は同様の手順で同期データを更新ログ格納表04-5に格納して処理系列5のレコードの同期済みを済に更新するS9~S11。処理系列5のレコードの同期済みが既に済であった場合既に他のアプリケーションの更新ログ格納機能が同期用データを格納した場合は、S10、S11の処理は行わない。同期対象の処理系列レコードの同期済みがすべて済になったことを確認したら図7のの状態になったら、更新ログ格納処理を終了するS4。他方、更新ログ格納機能03は、版管理表12を参照した際、更新対象処理系列のレコードの同期済みが済となっていた場合はS1、S2、更新ログを更新ログ格納表04-1に格納しS3、更新ログ格納処理を終了するS4。更新ログ格納表04-1および更新ログ格納表04-5に格納された更新ログと同期用データは、前述したバックアップコピーの動作の通りに、バックアップシステムの更新ログ格納表07-1および更新ログ格納表07-5にそれぞれ格納される。更新ログ反映機能の処理フローを図11に示す。更新ログ反映機能08-1と更新ログ反映機能08-5は、それぞれ更新ログ格納表07-1と更新ログ格納表07-5から更新ログを参照する際に、版数に格納されている版数と同期情報管理表09に書かれている版数とを比較しS21、異なっている場合は同期情報管理表09の自処理系列レコードの版数を更新するS22、S25。その際に、更新ログ格納表の同期対象処理系列の内容を同期情報管理表09の自処理系列レコードの同期対象処理系列に格納する。更新された同期情報管理表09の例を図9に示す。更新ログ反映機能は、同期情報管理表09を更新後、次のような同期処理を行う。ここでは、更新ログ反映機能08-1に注目して同期処理の説明を行う。更新ログ反映機能08-1は、同期情報管理表09から、同期対象である処理系列5のレコードの版数を取得し、自処理系列である処理系列1のレコードの版数と比較するS26、S27。比較した結果、版数が異なっていた場合は処理系列5の同期用データが未到達と判断して、処理系列5レコードの版数が更新されるまで待機するS28、S29。その後で、更新ログ反映機能08-5が同期用データを取得して同期情報管理表09の処理系列5レコードの版数を更新した結果、処理系列1と5の版数が同じになったことが確認できたらS28でYES、更新ログ反映機能08-1はそれ以降の更新ログをデータベース10-1へ反映させるS23。このとき、更新ログ反映機能08-5では、同期情報管理表09から処理系列1の版数が自処理系列の版数と同じことを初回比較時に確認できるため、確認後にそれ以降の更新ログをデータベース10-5に反映させる。なお、本例での同期処理を行わない更新ログ反映機能08-2~4については、同期データを受け取らないため、版数が更新された更新ログを受け取ると、同期情報管理表09の自処理系列レコードの版数を更新して、更新ログ反映を行う。再構成前後の更新ログと同期用データの反映順序を図12に示す。処理系列1では、再構成前の更新ログ、同期データ、再構成後の更新ログの順序で転送され、反映される。処理系列5は今回の再構成後に生成された処理系列なので、同期データ、再構成後の更新ログの順序になっている。[効果の説明]フロントシステム100からバックアップシステム200へ更新ログの転送、反映を行う際に、データベースの再構成前の更新ログと再構成後の更新ログとの間に同期データを書き込み、バックアップシステム200の更新ログ反映時に全ての同期データを待ち合わせることで、再構成後の更新ログが再構成前の更新ログを追い抜くといった現象を防ぐことができるので、再構成前後の更新ログ反映の順序性が保証できる。これにより、データベース再構成前後の更新ログの順序を正しくするための手動作業が必要なくなるため、データベース再構成の際の運用の作業とその時間が削減できる。[本実施形態の変形例]上記の実施形態では、データベースの再構成の例として、1つの処理系列で処理しているキーの一部を別の処理系列を追加して分散する場合の説明をしたが、下記の再構成例でも同様の処理で順序性を保証できる。図13に示すように、1つの処理系列で処理しているキーを、別の複数の処理系列に分散する。図14に示すように、複数の処理系列で処理しているキーを1つの処理系列に統合する。図15に示すように、複数の処理系列がそれぞれ処理しているキーを、再分配する。即ち、一般的に複数の処理系列が担当しているキーを複数の処理系列に分散、統合する場合に適応できる。