"フロントシステムと、バックアップシステムとを備えるレプリケーションシステムであって、前記フロントシステムは、データベースの更新ログの順序性を保証する単位である処理系列毎に更新ログを前記バックアップシステムに転送する手段を備え、前記バックアップシステムは、前記フロントシステムから受信した更新ログを前記更新ログが属するべき処理系列に振り分ける手段を備える、レプリケーションシステム。請求項1に記載のレプリケーションシステムであって、前記フロントシステムの処理系列及び前記バックアップシステムの処理系列は、独立に構成変更可能である、レプリケーションシステム。請求項2に記載のレプリケーションシステムであって、前記フロントシステムの処理系列と前記バックアップシステムの処理系列とが異なる場合でも無停止連続稼動が可能である、レプリケーションシステム。請求項1乃至請求項3のうち何れか1項に記載のレプリケーションシステムであって、前記バックアップシステムは、前記振り分けられた更新ログを複数まとめてコミットする手段を更に備える、レプリケーションシステム。データベースの更新ログの順序性を保証する単位である処理系列毎に転送される更新ログを受信するステップと、前記更新ログを前記更新ログが属するべき処理系列に振り分けるステップと、を備えるレプリケーション方法。請求項5に記載のレプリケーション方法であって、前記振り分けられた更新ログを複数まとめてコミットするステップを更に備える、レプリケーション方法。しかし、上述の従来の方式では、フロントシステムとバックアップシステムとの間の処理系列の構成が完全に一致していない場合には、更新ログを転送できないという問題があった。ここで、処理系列とは、更新ログが転送される経路、及び更新ログの順序性を保証する単位を意味する。そのため、フロントシステムのデータベースとバックアップシステムのデータベースの再構成を行うには、両システムとも停止し、フロントシステムのアプリケーションからの更新要求も停止した状態で、両システムの処理系列の構成変更を行う必要があった。従来は、24時間365日の無停止連続稼動という必要性に乏しかったため、データベースの構成を変更する際は、上述の従来の方式で対応可能であったが、最近は24時間365日の無停止連続稼動という要求が増えてきているため、データベースの構成変更のためにシステムを一時的に完全停止することは好ましくない。そこで、本発明は、フロントシステムの処理系列の構成とバックアップシステムの処理系列の構成とが異なる場合でも無停止連続稼動でレプリケーションすることのできるレプリケーションシステム及びレプリケーション方法を提案することを課題とする。上述の課題を解決するため、本発明に係わるレプリケーションシステムは、フロントシステムと、バックアップシステムとを備え、フロントシステムは、データベースの更新ログの順序性を保証する単位である処理系列毎に更新ログをバックアップシステムに転送する手段を備え、バックアップシステムは、フロントシステムから受信した更新ログをその更新ログが属するべき処理系列に振り分ける手段を備える。本発明に係わるレプリケーション方法は、データベースの更新ログの順序性を保証する単位である処理系列毎に転送される更新ログを受信するステップと、更新ログをその更新ログが属するべき処理系列に振り分けるステップと、を備える。本発明によれば、フロントシステムの処理系列の構成とバックアップシステムの処理系列の構成とが異なる場合でも無停止連続稼動でレプリケーションすることができる。以下、各図を参照しながら本発明の実施形態について説明する。同一の機能ブロックには、同一の符号を付すものとし、重複する説明を省略する。図1は本実施形態に係わるレプリケーションシステム10の構成変更の概要を示す説明図である。レプリケーションシステム10は、フロントシステム20とバックアップシステム30とを備えている。フロントシステム20及びバックアップシステム30には、複数のデータベースが設けられており、更新対象のキー毎に更新先のデータベースが定められている分散配置データベースの運用形態をとる。バックアップ処理は、分散されたデータベース毎に処理系列を分けて更新ログを並列に転送し、データベースの更新を並列に行うことで、スループットの向上を図っている。なお、一つの処理系列では、更新ログの転送及び更新の順序性は保証されているものとする。同図に示す状態は、構成変更の一例として、フロントシステム20の運用を継続したまま、バックアップシステム30のみ先に停止してバックアップシステム30のデータベースの構成変更後にバックアップシステム30の運用を再開した状態を示している。フロントシステム20では、アプリケーションでのデータベース更新処理を継続して受け続け、バックアップシステム30の停止中にバックアップシステム30のデータベースの処理系列の構成変更を行う。その場合、同図に示すように、フロントシステム20は再構成前の状態にある一方、バックアップシステム30は再構成済みのため、両システム間で一時的に処理系列の構成が異なる。フロントシステム20からバックアップシステム30のある処理系列へ転送されてくる更新ログの中には、他の処理系列に属する更新ログが含まれている場合がある。このため、バックアップシステム30の各処理系列は、受信した更新ログの処理系列をチェックし、もし、自身の処理系列とは異なる処理系列に属する更新ログが含まれている場合には、その更新ログを該当する処理系列に振り分ける。バックアップシステム30は、更新ログを振り分けた後、オーバーヘッドを低減するため、複数の更新ログをまとめてコミットする。この方式により、フロントシステム20とバックアップシステム30との間で処理系列の構成が異なる場合でも、更新ログの並列転送及び並列更新が可能となり、無停止連続稼動でのレプリケーションが可能になる。なお、バックアップシステム30の構成変更後、バックアップシステム30をフロントシステムに切り替えて、アプリケーションからのデータベース更新要求を受け付けつつ、フロントシステム20をバックアップシステムに切り替えて、その運用を停止し、そのデータベースの構成を変更することによって、無停止連続稼動での構成変更が可能になる。図2は本実施形態に係わるレプリケーションシステム10の機能ブロック図である。フロントシステム20では、データ更新アプリケーション21がデータベースアクセスプロセス22を経由してデータベース23のユーザ表24を更新する際、更新ログ表25も更新する。すると、送信手段26は、更新ログ表25から更新ログを読み込み、これをバックアップシステム30へ転送する。バックアップシステム30では、受信手段37が更新ログを受信して、更新ログ表35へ書き込む。反映プロセス31は、振分プロセス32を経由して更新ログ表35から更新ログを読み込む。また、反映プロセス31はデータベースアクセスプロセス33を経由してデータベース34のユーザ表36を更新する。これにより、フロントシステム20のユーザ表24とバックアップシステム30のユーザ表36との同期がとれることで、レプリケーションが可能になる。図3は処理系列とその処理系列に属する更新ログの対応関係を示す説明図である。図中、括弧の中の数値はハッシュ値を示す。同図に示す状態は、フロントシステム20の運用を継続したまま、バックアップシステム30のみ先に停止してバックアップシステム30のデータベースの構成変更後にバックアップシステム30の運用を再開した状態を示している。フロントシステム20には、処理系列1のみが存在する一方、バックアップシステム30には、処理系列1,2が存在しており、フロントシステム20の処理系列とバックアップシステム30の処理系列はその構成が一致していない。構成変更前のフロントシステム20の処理系列1のハッシュ値の範囲は1~20であるのに対し、構成変更後のバックアップシステム30の処理系列1のハッシュ値の範囲は1~10であり、処理系列2のハッシュ値の範囲は11~20である。バックアップシステム30の処理系列1のハッシュ値の範囲は1~10であるから、フロントシステム20の処理系列1からバックアップシステム30の処理系列1に転送された更新ログの中で、ハッシュ値が11と15のものは、本来、処理系列2に属するべきものである。図4はバックアップシステム30側で受信した更新ログをユーザ表36に反映する動作を示す説明図である。処理系列1では、更新ログ表35に格納されている更新ログを振分プロセス32が読み込む。振分プロセス32は、更新ログのハッシュ値からその更新ログが属する処理系列を判定し、自身の処理系列とは異なる処理系列に属する更新ログを本来の処理系列に転送する。更新ログを受け取った反映プロセス31は、更新ログを一つずつ取り出し、これをデータベースアクセスプロセス33に渡す。更新ログを受け取ったベースアクセスプロセス33は、更新ログをユーザ表36に反映する。ベースアクセスプロセス33から反映成功の応答を受け取った反映プロセス31は、あるタイミングで複数の更新ログをまとめてコミットする。図5はバックアップシステム30側で受信した更新ログをユーザ表36に反映する動作を記述したフローチャートである。振分プロセス32は、更新ログ表35から複数の更新ログを読み取りステップ501、その中から一つの更新ログを取り出すステップ502。振分プロセス32は、取り出した更新ログが自身の処理系列に属するものではなく、異なる処理系列に属するものであるか否かを判定するステップ503。更新ログが異なる処理系列に属する場合はステップ503;YES、振分プロセス32は、更新ログを本来の処理系列に転送しステップ504、ステップ505に進む。更新ログが自身の処理系列に属する場合にはステップ503;NO、振分プロセス32は、ステップ505に進む。更新ログ表35に更新ログが存在する場合にはステップ505;YES、振分プロセス32は、ステップ502~504の処理を繰り返す。一方、更新ログ表35に更新ログが存在しない場合にはステップ505;NO、反映プロセス31は、振分プロセス32から受け取った更新ログを一つ取り出しステップ506、データベースアクセスプロセスを呼び出してステップ507、更新ログをユーザ表36に反映させるステップ508。反映プロセス31に更新ログが存在する場合にはステップ509;YES、反映プロセス31は、ステップ506~508の処理を繰り返す。一方、反映プロセス31に更新ログが存在しない場合にはステップ509;NO、反映プロセス31は、複数の更新ログをまとめてコミットするステップ510。図6に示すようにバックアップシステム30のデータベースの再構成が終了すると、バックアップシステム30は、フロントシステムとして稼動し、アプリケーションからのデータベース更新要求を受け付ける一方、フロントシステム20は、バックアップシステムとして稼動する。そして、新フロントシステム旧バックアップシステム30から新バックアップシステム旧フロントシステム20へレプリケーションする。図7に示すように、新バックアップシステム旧フロントシステム20のデータベースの構成変更が終了すると、新バックアップシステム旧フロントシステム20を再びフロントシステムとして稼動させる一方、新フロントシステム旧バックアップシステム30を再びバックアップシステムとして稼動させる。そして、フロントシステム20からバックアップシステム30へレプリケーションする。これにより、無停止連続稼動でデータベースの構成変更を行うことができる。本実施形態の一部又は全部は、以下の付記のように記載され得るが、以下には限定されない。付記1フロントシステム20と、バックアップシステム30とを備えるレプリケーションシステム10であって、フロントシステム20は、データベースの更新ログの順序性を保証する単位である処理系列毎に更新ログをバックアップシステム30に転送する手段26を備え、バックアップシステム30は、フロントシステム20から受信した更新ログをその更新ログが属するべき処理系列に振り分ける手段32を備える、レプリケーションシステム10。付記2付記1に記載のレプリケーションシステム10であって、フロントシステム20の処理系列及びバックアップシステム30の処理系列は、独立に構成変更可能である、レプリケーションシステム10。付記3付記2に記載のレプリケーションシステム10であって、フロントシステム20の処理系列とバックアップシステム30の処理系列とが異なる場合でも無停止連続稼動が可能である、レプリケーションシステム10。付記4付記1乃至付記3のうち何れか一つに記載のレプリケーションシステム10であって、バックアップシステム30は、振り分けられた更新ログを複数まとめてコミットする手段31を更に備える、レプリケーションシステム10。付記5データベースの更新ログの順序性を保証する単位である処理系列毎に転送される更新ログを受信するステップと、更新ログをその更新ログが属するべき処理系列に振り分けるステップと、を備えるレプリケーション方法。付記6付記5に記載のレプリケーション方法であって、振り分けられた更新ログを複数まとめてコミットするステップを更に備える、レプリケーション方法。"