JP5213108B2 - データ複製方法及びデータ複製システム - Google Patents

Description

本発明は、障害許容性を有する計算機システムに関し、特に、計算機間でデータを複製することで、処理内容の整合性を保証する技術に関する。

障害許容性（または冗長性）を求められるアプリケーションシステムでは、複数のサーバによってデータ処理を行う実行系サーバと、実行系サーバに障害が発生した場合にデータ処理を引き継ぐ待機系サーバによるクラスタ構成によって信頼性を確保することができる。データベース（ＤＢ）のように、ディスクにデータを蓄積するアプリケーションでは、実行系サーバ及び待機系サーバからアクセス可能な共有ディスクによってデータを引継ぎ、待機系サーバによって処理を継続する。従って、ディスクへデータを同期的に書き込むＩ／Ｏ処理が必要となり、Ｉ／Ｏ処理性能によってシステム性能が決定される。

近年、広範的に利用されるアプリケーションシステムでは、上記のＩ／Ｏ性能によって決定されるシステム性能以上のシステム性能が必要となる場合が増えている。こうした要求に対して、メモリ上にのみデータを保持し、ディスク装置への同期的なＩ／Ｏ処理を無くすことで、システム性能を向上させるインメモリアプリケーションシステムが登場している。

このようなインメモリアプリケーションシステムでは、そのままではメモリ上に保持したデータを待機系サーバと共有することはできないため、例えば、インメモリＤＢのように、メモリ上に保持されるデータを障害によって喪失することが許されない障害許容性が必要なアプリケーションでは、実行系サーバから待機系サーバに対して通信することで、実行系サーバのデータの複製を待機系サーバのメモリ上に保持させることでデータを冗長化する必要がある。

さらに、障害許容性を考慮すると、こうしたインメモリアプリケーションシステムでは、実行系／待機系サーバからなる２台構成では１台のサーバ障害が発生した場合に、データは１台のサーバ上に残るのみとなる。残った１台の計算機にサーバ障害が発生すると、データ喪失が生じるため、揮発性記憶媒体であるメモリ上のデータを、ディスクなどの不揮発性記憶媒体にデータを保存する必要が生じる。しかしながら、サーバが１台になった後に前述の保存を実施している最中に障害が発生した場合には、保存していないデータが喪失することになる。従って、高い障害許容性を必要とする場合、２台以上の待機系サーバに対して、データ複製を同時に行う必要があり、このような場合、マルチキャストによる通信を利用して、複数台の待機系サーバへの通信が行われる。

ここで、複数台の待機系サーバに対してデータ複製を行う通信方法として、２フェーズコミット法と呼ばれる方法が知られる。２フェーズコミット法では、実行系サーバから待機系サーバへのデータの複製に際して、複製するデータを送信するための通信を行う準備フェーズと、実行系サーバが、全待機系サーバでデータが受信されたことを確認した場合に前記送信したデータを確定するための通信を行うコミットフェーズとからなる。コミットフェーズが成功した場合に送信元である実行系と待機系でデータが確定した状態での整合性が保証され、実行系サーバで行われた業務処理が終了となる。

このため、この２フェーズコミット法では、実行系が持つデータを全待機系と同期し、実行系サーバで業務処理を完了するためには２度のマルチキャスト通信が必要であり、待機系台数が多ければ多いほど、全待機系サーバから各フェーズの応答を受信するまでの時間が増大するため、オーバヘッドが大きくなるという問題がある。

このような問題に対して、特許文献１では、実行系サーバでのデータ更新を、定期的に待機系サーバにマルチキャスト通信（ハートビート通信）により通知し、待機系サーバが受信時にデータ更新のために実行系サーバにデータを要求することでデータ複製を行う１フェーズコミット法による同期方法Ａを用いることで、通信回数を削減し、データの冗長化を実現する技術が開示されている。加えて、特許文献１では、ハートビート通信で更新されたデータの準備フェーズと、準備フェーズが終わったデータのコミットを一括して送信することによって、前記２フェーズコミット法のマルチキャスト通信をハートビートで置換した同期方法Ｂも記載され、データ更新回数よりも通信回数を削減して、データの冗長化を実現する技術が開示されている。また加えて、上記同期方法Ａ、Ｂで実行系サーバとの同期が失敗した待機系サーバが存在する場合でも、実行系サーバは処理を確定することを可能とし、前記同期に失敗した待機系サーバが実行系サーバに同期できなかったデータの再送を要求することで再同期する技術も合わせて開示されている。
米国特許出願公開第２００３／００１８７３２号明細書

上記特許文献１に記載される技術は、インメモリアプリケーションシステムに適用する場合に以下のような問題がある。まず、前記同期に失敗した待機系サーバからの要求に応じて、データの再送を行うためには、実行系サーバで行ったデータ更新内容を記憶しておき、任意の時点のデータを再生成する必要がある点である。これは、更新内容の記憶のためにメモリを消費することになり、システムで保持できるデータ量を制約することになる。加えて、実行系サーバに障害が発生した場合、メモリ上に保持しているデータが失われるため、待機系サーバでも同様に更新内容の記憶が必要であり、メモリ消費が生じる。

次に、ハートビートによってデータの複製を行うため、実行系サーバで行ったデータ更新内容が待機系サーバに複製されるまでに遅延が生じる。すなわち、実行系サーバで業務処理が確定するまでに遅延が生じることになる。従って、高速な処理を実現するために利用されるインメモリアプリケーションシステムでオーバヘッドを生じるという問題がある。このように、上記特許文献１で開示されるデータ複製技術による通信回数の削減効果は、インメモリアプリケーションシステムでは好適でないという問題がある。

本発明は、以上に示す課題を解決することを鑑みたものであり、クラスタ構成を有するインメモリアプリケーションシステムで、実行系サーバの処理結果を通信によって待機系サーバへ複製を行う場合において、必要とされる通信回数を削減しつつ、信頼の高いデータ複製方法を提供することを目的とする。

本発明は、プロセッサとメモリを備えてアプリケーションを実行する第１の計算機と、プロセッサとメモリを備えて実行系の前記第１の計算機を引き継ぎ可能な第２の計算機と、を備え、前記第１の計算機が第１の処理要求を含む第１の電文を受信し、複数の第２の計算機で前記第１の電文を複製するデータ複製方法であって、第３の計算機が前記第１の電文を、前記第１の計算機と前記複数の第２の計算機に送信し、前記第２の計算機が、前記第１の電文の受信完了通知を前記第１の計算機に送信し、前記第１の計算機が、全ての第２の計算機からの前記受信完了通知を待ち合わせて、前記第１の計算機が、前記複数の第２の計算機からの受信完了通知を受信し、前記第１の計算機が、複数の第２の計算機からの受信完了通知を受信した後に、前記第３の計算機に前記第１の電文の受信完了通知を送信し、前記第１の計算機が、複数の第２の計算機からの受信完了通知を受信した後に、前記第１の処理要求を第１の計算機で実行可能なように有効に設定し、前記第１の計算機が、複数の第２の計算機からの受信完了通知を受信した後に、前記第２の計算機に前記第１の電文が有効であることを通知する。

また、前記第１の計算機または第２の計算機が、メモリ上でのみ前記アプリケーションの処理を実行する。

したがって、本発明は、待機系となる全ての第２の計算機に、第３の計算機が電文をマルチキャストで送信し、第２の計算機（待機系サーバ）が第１の計算機（実行系サーバ）に受信完了を通知することで、第１の計算機の電文の受信処理を完了し、第１の計算機と第２の計算機で電文の複製が完了する。これにより、通信量を削減しつつ、信頼性の高いデータ複製を実現することができる。

以下、本発明の実施の形態を添付図面に基づいて説明する。
＜第１の実施の形態＞
本発明に関する図と説明は、本発明を鮮明に理解するのに適当な要素を示すために簡略化されており、発明を実施するのに支障ない範囲で既知の要素等は省略していることを理解されたい。本技術中で従来技術の中には、本発明を実装するために他の要素が望ましく、かつ／または、必要とされると思われるものが幾つかある。しかし、技術中のこれらの要素は既知であり、本発明の理解を容易にするものではないので、ここでは説明しない。

また、以下の説明では、各プログラムは実行系（または現用系）のモジュール番号で説明している場合もあるが、それらの説明は、待機系の対応したプログラムの説明も兼ねる場合もある。さらに、以降の図に示す符号において、他の図中の数字と同様の番号を用いているものがあるが、それらについては特に説明がない場合、他の図の説明と同様である。

図１〜図６及び図１９は本発明における第１の実施形態について表している。

図１は、第１の実施形態のクラスタ構成を有するインメモリアプリケーションシステムのハードウェア構成を表すブロック図である。

第１の実施形態の実行系サーバ１０は、通信インターフェース１１と、ＣＰＵ（プロセッサ）１２と、メモリ１３と、Ｉ／Ｏインターフェース１４と、前記Ｉ／Ｏインターフェース１４を経由して接続可能なローカル接続されたストレージ装置１５を備える。

ＣＰＵ１２は、メモリ１３に格納されたプログラムを実行することによって、各種処理を実行する。メモリ１４及びストレージ装置１５は、ＣＰＵ１２によって実行されるプログラムおよび処理に必要なデータを格納することができる。通信インターフェース１１は、ネットワーク７０を介して、他の計算機（例えば、クライアントや、待機系サーバ）と通信する。なお、ＣＰＵ１２は複数のコアを備え、複数の処理を並列的に実行可能であってもよい。

待機系サーバ１及び待機系サーバ２も上記実行系サーバと同様に構成される。

図２は、図１に示した物理計算機におけるインメモリアプリケーションシステムのソフトウェアを主体とした機能ブロック図である。これらのソフトウェアは、メモリ１３に読み込まれてＣＰＵ１２により実行され、使用するデータを予めメモリ１３に読み込んでおくインメモリアプリケーションシステムを構成する。

インメモリアプリケーションシステムに処理要求を送信するクライアントサーバ８０では、インメモリアプリケーションシステムに対して処理要求を行う入力電文を送信する電文制御部８１０を有する。また、前記電文制御部８１０は、前記入力電文がインメモリアプリケーションシステムに受信完了されたかの応答を受信する機能や、前記入力電文の処理結果を受信する機能を有する。さらに、前記電文制御部８１０は、マルチキャスト通信を用いて複数の計算機、例えば、実行系サーバ１０と全待機系サーバ２０、３０に電文を同報する機能も有する。

実行系サーバ１０では、前記クライアントサーバ８０の電文制御部８１０によって送信された入力電文を受信する機能と、待機系からの入力電文受信完了通知を受信する機能を有する電文制御部１１０を備える。さらに、前記電文制御部１１０は、受信した前記入力電文を格納する受信電文格納バッファ１１１を有する。さらに、前記電文制御部１１０は、クライアントサーバ８０や待機系サーバ２０、３０に対して電文を送信する機能を有し、送信される前記電文を格納する送信電文格納バッファ１１２を有する。また加えて、前記電文制御部１１０は、前記電文制御部８１０と同様にマルチキャスト通信を用いて電文を同報する機能を有する。さらに、電文制御部１１０は、後述のクラスタ制御部１２０と連携することで、クラスタ構成をとる任意の実行系サーバと待機系サーバを識別する機能も有する。これにより、前記電文制御部１１０は全待機系サーバ２０、３０への電文送信をする場合には、マルチキャスト通信で行う機能も有する。さらに、前記電文制御部１１０は、受信電文格納バッファ１１１に格納された入力電文に対して待機系サーバ２０、３０の同期状態を認識する同期状態制御部１１９を含む。さらに、前記同期状態制御部１１９は、前記同期状態の認識結果を契機に、前記電文制御部１１０を介して、前記同期状態を格納バッファ１１１、１１２に合わせて格納する機能を有する。なお、電文制御部１１０は、受信した電文に含まれる処理要求を実行するソフトウェアモジュールを備えていても良い。

また、実行系サーバ１０は、どの物理計算機が実行系サーバや待機系サーバであるかを管理するクラスタ制御部１２０を有する。ここで、他の計算機が実行系サーバであるか待機系サーバであるかを管理するために、前記クラスタ制御部１２０は、クラスタ構成をなす他の計算機と相互通信を行う機能を有することもある。また加えて、前記クラスタ制御部１２０は、他サーバの障害を検出する機能を有する。

一方、待機系サーバ２０、３０では、実行系サーバ１０と同様の構成のソフトウェアが実行される。なお、待機系サーバ３０は、待機系サーバ２０と同一のソフトウェア構成であるので、以下待機系サーバ２０について説明する。待機系サーバ２０では、前記クライアントサーバ８０からマルチキャスト送信された電文を受信する電文制御部２１０を有する。さらに、クライアントサーバ８０や他のサーバから受信した前記入力電文を格納する受信電文格納バッファ２１１を有する。さらに、前記電文制御部２１０は、前記入力電文の受信後に、実行系サーバ１０に対して前記入力電文の受信完了を送信する機能を有する。さらに、前記電文制御部２１０は、クライアントサーバ８０や他の待機系サーバ３０に対して電文を送信する機能を有し、送信される前記電文を格納する送信電文格納バッファ２１２を有する。また、待機系サーバ２０の前記電文制御部２１０は、実行系サーバ１０と同様に、同期状態制御部２１９を含む。ここで、クラスタを構成する他の計算機に対して通信を行う場合には、マルチキャスト通信で行う機能も前記電文制御部２１０は有する。また、待機系サーバ２０は、どの物理計算機が実行系サーバ１０と待機系サーバ２０、３０かを管理するクラスタ制御部２２０を有する。ここで、他の計算機が実行系サーバであるか待機系サーバ２０、３０であるかを管理するために、前記クラスタ制御部２２０は、クラスタ構成をなす他の計算機と相互通信を行う機能を有することもある。また加えて、前記クラスタ制御部２２０は、他サーバの障害を検出する機能を有する。さらに待機系サーバ２０、３０の前記クラスタ制御部２２０は、実行系サーバ１０に障害が発生した場合には、稼動中の待機系サーバ２０、３０のうち、１台の待機系サーバ２０、３０を実行系サーバとして動作するように系切り替えを行う機能を有する。

図３は、第１の実施形態におけるインメモリアプリケーションシステムのソフトウェアが、外部（クライアントサーバ８０）から送信された入力電文を複製する処理を表すシーケンス図である。なお、以降の実施形態でも同様のシーケンス図を用いて説明をするが、これらのシーケンス図は入力電文Ａの複製処理の理解を容易にすることを目的とし、電文Ａの複製処理以外の処理は簡略化されていることを理解されたい。

図３において、クライアントサーバ８０の電文制御部８１０が入力電文Ａを実行系サーバ１０と待機系サーバ２０、３０に送信する（Ｓ１）。実行系サーバ１０と待機系サーバ２０、３０では、電文Ａを受信電文格納バッファ１１１、２１１に格納する。電文Ａの格納は、同期状態制御部１１９、２１９を介して実行され、待機系サーバ２０、３０では、自系の電文Ａの同期状態を同期済として格納する（Ｓ２）。

続いて、待機系サーバ２０、３０は、電文格納後、同期済応答を実行系サーバへと送信する（Ｓ３）。実行系サーバでは、各待機系サーバ２０、３０からの同期済応答を受信すると、同期状態制御部１１９を介して、送信元の待機系サーバ２０、３０の同期状態を同期済へと変更する処理（Ｓ４）を繰り返す。

これにより、全待機系サーバ２０、３０が同期済となるまで待ち合わせる（Ｓ５）。全待機系サーバ２０、３０が同期済となると、電文Ａの受信完了をクライアントサーバ８０へ通知する（Ｓ６）。その後、実行系サーバ１０は、全待機系サーバ２０、３０に対して電文Ａが実行系サーバ１０で実行可能であることを通知する確定済通知を全待機系サーバ２０、３０に通知する（Ｓ７）。

待機系サーバ２０、３０は、この確定済通知を受け、すでに格納していた電文Ａに対して全ての待機系サーバ２０、３０の同期状態を同期済へと変更することで、電文Ａの確定を行う（Ｓ８）。その後、待機系サーバ２０、３０は、電文Ａの確定済応答を実行系サーバへと応答する（Ｓ９）。実行系サーバ１０は、同期済応答と同様に、各待機系サーバ２０、３０からの確定済応答を受信すると、待機系サーバ２０、３０の同期状態を確定済に変更して（Ｓ１０）、全待機系サーバ２０、３０からの確定済応答を待ち合わせ（Ｓ１１）、全応答を受信することで、入力電文Ａの複製が完了する。

図４は、図３に示した入力電文の複製処理の例を示すフローチャートである。なお、以下の説明では、待機系サーバ２０、３０の動作を１台の計算機で示しているが、他の待機系サーバの処理も同様である。

まず、インメモリアプリケーションシステムに対して入力電文の送信元、例えば、クライアントサーバ８０の電文制御部８１０が入力電文として、電文Ａをマルチキャスト送信で、実行系サーバ１０と全待機系サーバ２０、３０に送信する(Ｓ８０１、Ｔ１０１)。図５ａは、前記電文Ａの一例を示すものであり、例えば、電文を一意に示す電文ＩＤ３０１と、インメモリアプリケーションシステムに要求する処理をあらわす電文内容３０２とを有する。ここで、電文は、上記情報の他、送信元を表す識別情報を含んでもよいし、さらには、送信元から電文の再送を行う仕組みを持つ場合には、その再送回数を表す情報を含んでも良い。

実行系サーバ１０と待機系サーバ２０、３０はそれぞれ前記電文Ａを受信し（Ｓ１０１、Ｓ２０１）、前記電文Ａを受信電文格納バッファ１１１、２１１に格納する（Ｓ１０２、Ｓ２０２）。

図６は、前記受信電文格納バッファ１１１の一例を示すものであり、例えば、前記電文Ａに含まれる情報（前記電文ＩＤ３０１と前記電文内容３０２）に加えて、待機系サーバ２０、３０における電文Ａの状態を示す同期状態３４１を有する。前記同期状態３４１は、待機系サーバ２０、３０毎に、前記電文Ａを待機系が受信する前の未同期状態、受信した後の同期状態、さらには、全待機系サーバ２０、３０が受信したことを待機系サーバ２０、３０が認識したかどうかを表す確定済状態に関する情報を含む。例えば、前記処理Ｓ１０２において実行系サーバが電文Ａを格納した場合には、全待機系サーバ２０、３０が前記電文Ａを受信したかどうかを未確認であるため、全ての待機系サーバの同期状態３４１は未同期状態となる。

一方、前記処理Ｓ２０２において待機系サーバ２０、３０が電文Ａを受信電文格納バッファ２１１に格納した場合には、自待機系サーバ２０、３０の同期状態３４１は同期済となるが、その他の待機系サーバの同期状態は未同期状態となる。

次に、実行系サーバ１０は処理Ｓ１０２の後、電文Ａの受信完了を送信元（クライアントサーバ８０）に通知するための受信完了応答を生成し、前記送信電文格納バッファ１１２に格納する（Ｓ１０３）。

待機系サーバ２０、３０は、処理Ｓ２０２の後、電文Ａの受信完了を実行系サーバ１０に通知するための同期済応答を生成し、前記送信電文格納バッファ２１２に格納する（Ｓ２０３）。

図５ｂは、前記同期済応答の一例であり、受信した電文ＩＤ（同期済電文ＩＤ）３１２と、送信元である待機系サーバ２０、３０を一意に示す送信元識別子３１１を有する。また、図５ｃは、前記受信完了応答の一例であり、例えば、受信した電文ＩＤを含む。ここで、前記受信完了応答は、クライアントサーバ８０は実行系サーバがどの計算機なのかを認識するために、図５ｂと同様に送信元となる実行系サーバを一意に識別するための情報を含んでもよい。

処理Ｓ２０３の後、待機系サーバ２０、３０は、格納した前記同期済応答を実行系サーバ１０に通知する（Ｓ２０４、Ｔ１０２）。一方、実行系サーバ１０は、処理Ｓ１０３の後、全待機系サーバ２０、３０から前記同期済応答が来るのを待つ（Ｓ１０４）。例えば、処理Ｓ１０４は、前記同期済応答を受信した場合に、図６に示した前記受信電文格納バッファ１１１に保持される電文のうち、前記応答に含まれる前記同期済電文ＩＤ３０１の電文について、前記送信元識別子に対応する待機系サーバ２０、３０の同期状態３４１を同期済と変更し、全待機系の同期状態３４１が同期済となっているかを確認することで実行されてもよい。

全待機系サーバからの同期済応答を受信すると、実行系サーバ１０では、電文Ａについて全待機系サーバ２０、３０で同期済が確定できる。すなわち、待機系サーバ２０、３０において電文Ａが複製されことが確定できる（Ｓ１０５）。処理Ｓ１０５が行われた後、例えば、前記同期済が確定した電文Ａは、実行系サーバ１０で電文内容に応じて実際に実行されてもよいし、また、さらに電文内容の一部ないし全てを別の計算機に送信してもよい。処理Ｓ１０５に続いて、前記処理Ｓ１０３で格納した電文Ａの電文受信完了応答を送信元に対して送信する（Ｓ１０６、Ｔ１０３）。送信元（クライアントサーバ８０）では前記受信完了応答Ｔ１０３を受信し（Ｓ８０２）、電文Ａの送信処理を完了する。

実行系サーバ１０では、引き続き、待機系に対して前記電文Ａが全待機系で同期したことを通知する電文確定通知を生成し、前記送信電文格納バッファ１１２に格納した後に、全待機系サーバ２０、３０に対してマルチキャスト送信し（Ｓ１０７、Ｔ１０４）、全待機系サーバ２０、３０から前記電文確定通知Ｔ１０４に対する応答である電文確定済応答を待つ（Ｓ１０８）。ここで、前記電文確定通知Ｔ１０４は、例えば、前記電文Ｔ１０２と同様に、実行系サーバ１０で確定した確定済電文ＩＤを含む（例えば、図５ｄ参照）。

待機系サーバ２０、３０は、前記処理Ｓ２０４の後、前記電文確定通知Ｔ１０４を受信すると（Ｓ２０５）、電文Ａを確定する（Ｓ２０６）。例えば、処理Ｓ２０６は、前記電文確定通知Ｔ１０４を受信した場合に、前記受信電文格納バッファ２１１に保持される電文のうち、前記電文確定通知Ｔ１０４に含まれる前記同期済電文ＩＤの全待機系サーバ２０、３０の同期状態３４１を同期済と変更することで実行される。これにより、待機系サーバ２０、３０は確定した前記電文Ａが自系を含む全待機系サーバ２０、３０に複製されたことを確定できる。さらに、前述のように、実行系サーバ１０が前記電文Ａを確定後に実行する処理が開始されることを認識することもできる。

従って、待機系サーバ２０、３０は確定された電文Ａを認識することで、実行系サーバ１０の障害による系切り替えが生じた場合に、系切り替え先となる待機系サーバ２０、３０は、前記電文Ａが実行系サーバ１０で処理中であり、回復対象とする電文であることを認識することが可能である。

待機系サーバ２０、３０は、処理Ｓ２０６に引き続き、自系で電文確定済応答を生成し、前記送信電文格納バッファ２１２に格納した後（Ｓ２０７）、前記電文確定済応答を実行系サーバ１０へ通知し（Ｓ２０８、Ｔ１０５）、待機系サーバ２０、３０での電文受信処理は完了する。ここで、前記電文Ｔ１０５は、例えば、前記電文Ｔ１０２やＴ１０３と同様に、待機系サーバ２０、３０で確定した電文ＩＤを含み、さらには送信元を一意に示す情報を含んでも良い。

一方、実行系サーバ１０は、処理Ｓ１０７の後、全待機系サーバ２０、３０から前記確定済応答Ｔ１０５が来るのを待つ（Ｓ１０８）。例えば、処理Ｓ１０８は、前記確定済応答Ｔ１０５を受信した場合に、前記受信電文格納バッファ１１１に保持される電文のうち、前記応答に含まれる前記確定済電文ＩＤの電文について、前記送信元識別子に対応する待機系サーバ２０、３０の同期状態を確定済と変更し、全待機系サーバ２０、３０の同期状態が確定済となっているかを確認することで実行されてもよい。前記処理Ｓ１０８で全待機系サーバ２０、３０からの確定済応答を受信することで、待機系サーバ２０、３０での入力電文の確定済みを確認することができ（Ｓ１０９）、実行系サーバ１０での電文受信処理は完了する。

以上により、実行系サーバ１０の障害時に待機系サーバ２０、３０では複製された電文Ａによって業務が引き継がれることが保証される。ここで、上記では、実行系サーバ１０及び全待機系サーバ２０、３０に対する送信をクライアントサーバ８０がマルチキャスト通信する例を示したが、このマルチキャスト通信は、クライアントサーバ８０はユニキャスト通信した電文を、クライアントサーバ８０と実行系／待機系サーバ２０、３０間のネットワーク上にあるルータ（図示省略）がマルチキャストすることで実現されてもよい。加えて、マルチキャスト通信は、複数のマルチキャスト通信を組み合わせることで実現してもよいし、さらには一部ないしは全体のマルチキャスト通信をユニキャスト通信に置換してもよい。このようにすることで、待機系が１台となった場合や、異なるネットワークに待機系が分散しているような場合であっても、入力電文の複製を行うことができる。

また、前記処理Ｓ１０３を実行するタイミングは、前記処理Ｓ１０２の後で前記電文Ｔ１０３を送信する処理Ｓ１０６の前であれば、異なるタイミングであってもよい。

さらに、第１の実施形態を実現するための別のシステム構成として、例えば、図７に示すように、クライアントサーバ８０とインメモリアプリケーションシステムとの間に中継サーバ５０が存在するようなシステム構成であっても良い。

図７は、前記図４において、クライアントサーバ８０の動作として説明した動作を中継サーバ５０が実施するシステム構成を示したブロック図である。図７では、例えば、クライアントサーバ８０は、前記中継サーバ５０に対してのみ入力電文を送信し、前記中継サーバ５０では、前記入力電文を電文制御部５１０が受信電文格納バッファ５１１に格納し、さらに、送信電文格納バッファ５１２に前記入力電文を格納して、実行系サーバ１０と全待機系サーバ２０、３０にマルチキャスト通信することで実現してもよい。

また、前記処理Ｓ８０２を実行した後に、クライアントサーバ８０に対して処理Ｓ８０２で受信した受信完了応答を転送することでクライアントサーバ８０への受信完了応答を通知することができる。

加えて、本実施形態では電文確定通知Ｔ１０４を電文毎に実行する場合について示したが、通信回数をさらに削減するために、一定量の電文毎に実行したり、一定間隔で通知したりすることで、複数の電文確定通知を一括して送信する方法を用いてもよい。

以上、図１〜図７に示した一連の処理を行うことで、クライアントサーバ８０からインメモリアプリケーションシステムへの入力電文のデータ複製を、マルチキャスト通信と全待機系サーバ２０、３０からの受信完了応答を組み合わせることで、実現することができる。これにより、入力電文を受けた実行系サーバ１０が全待機系サーバ２０、３０にマルチキャスト通信で転送する場合に比べて、少ない通信回数で、待機系サーバ２０、３０への入力電文の複製を実現することができる。

＜第２の実施の形態＞
図８、図９ａ〜図９ｃ及び図１０は、本発明における第２の実施形態について表しており、第１の実施形態の一部を変更して実施することで実現される。

図１０は、第２の実施形態におけるインメモリアプリケーションシステムのソフトウェアが、外部から送信された入力電文を複製する処理を表すシーケンス図であり、図３に示した第１の実施形態におけるシーケンスの一部を変更したものである。

図１０において、クライアントサーバ８０から入力電文Ａを送信してから、クライアントサーバ８０が電文Ａの受信完了応答を受信するまでのシーケンス（Ｓ１〜Ｓ６）は、図３と同様である。

クライアントサーバ８０は、電文Ａの受信完了応答を受信した後（Ｓ６）、電文Ａが実行系サーバ１０と待機系サーバ２０、３０で同期済であることを認識する（Ｓ２１）。この後に、新たな入力電文Ｂを実行系サーバ１０と待機系サーバ２０、３０に送信する場合に、クライアントサーバ８０は電文Ａの確定通知を電文Ｂと一緒に送信する（Ｓ２２）。待機系サーバ２０、３０では、電文Ｂと電文Ａ確定通知を受信すると、すでに格納していた電文Ａに対して全ての待機系サーバ２０、３０の同期状態を同期済へと変更することで、電文Ａの確定を行う（Ｓ２３）。その後、入力電文Ｂの同期済応答と合わせて、電文Ａ確定済応答を実行系サーバ１０へと応答する（Ｓ２４）。

実行系サーバ１０は、同期済応答と同様に、各待機系サーバ２０、３０からの電文Ａ確定済応答を受信すると、待機系サーバ２０、３０の同期状態を確定済に変更して（Ｓ２５）、全待機系サーバ２０、３０からの確定済応答を待ち合わせる（Ｓ２６）。

実行系サーバ１０が全応答を受信した後、入力電文Ｂの受信完了応答と合わせて、電文Ａ確定済応答をクライアントサーバ８０に応答する（Ｓ２７）。以上により、入力電文Ａの複製が完了し、電文Ｂの受信完了応答が確定する。

図８は、図１０に示した入力電文の複製処理の例を示すフローチャートである。

入力電文の送信元であるクライアントサーバ８０では、電文制御部８１０は過去に受信完了応答を受けた同期済電文のうち、インメモリアプリケーションシステムに対して確定を未通知な電文Ｂがあるかを参照し（Ｓ８０３）、入力電文である電文Ａの送信時に、前記処理Ｔ１０４と同様の前記電文Ｂの確定通知をあわせて、通知する（Ｓ８０４、Ｔ１０６）。また、その後、前記処理Ｓ８０２と同様にして、前記電文Ｔ１０６の応答となる受信完了応答を受信する。前記処理Ｓ８０２により、入力電文である電文Ａの同期済を確認し（Ｓ８０５）、さらに前記電文Ｔ１０６において送信した前記電文Ｂが待機系サーバ２０、３０で確定されたことを確認する（Ｓ８０６）。

図９ａは、前記電文Ｔ１０６の一例を示すものであり、前記図５ａに加えて、前記未通知の同期済電文Ｂを識別可能な確定済電文ＩＤ３０３を有する。

ここで、前記処理Ｓ８０３からＳ８０６は、クライアントサーバ８０の前記電文制御部８１０に同期状態制御部を設け、この同期状態制御部によって受信応答を受けた電文ＩＤをテーブル等でメモリやディスク装置などに記憶することで実現してもよい。例えば、メモリで行う一例として、送信した入力電文を格納するバッファを設け、受信電文格納バッファと同様に送信した入力電文の同期状態を前記同期状態制御部で変更する方法がある。また、クライアントサーバ８０が入力電文の送信を前の入力電文の受信完了応答受信後に行う場合は、入力電文ＩＤから直前に送信され、同期済となった入力電文の電文ＩＤが一意に定まるような電文ＩＤを利用することで、受信応答を受けた電文ＩＤを管理せずに実現してもよい。また、この場合、図９ａに示した前記電文Ｔ１０６における確定済電文ＩＤを送信しなくてもよい。

一方、インメモリアプリケーションシステムでは、図８で示すように、まず、前記電文Ａについては、第１の実施形態と同様に、実行系サーバ１０は処理Ｓ１０１〜Ｓ１０６を、待機系サーバ２０、３０は処理Ｓ２０１〜Ｓ２０４を実行し、電文Ｔ１０２が実行系サーバ１０と待機系サーバ２０、３０間で通信される。加えて、前記電文Ｂに関して、待機系サーバ２０、３０では前記処理Ｓ２０３の後、前記電文Ｔ１０６から電文Ｂの同期済みであることを確認し、前記第１実施形態の図４に示した処理Ｓ２０６と同様にして、電文Ｂの確定を行い（Ｓ２０９）、前記処理Ｓ２０４と同様にして、実行系サーバ１０に電文Ａの同期済応答Ｔ１０２を送信する。

一方、実行系サーバ１０では、前記処理Ｓ１０６と同様に、電文Ａの受信完了応答をクライアントサーバ８０に通知する。ここで、待機系サーバ２０、３０の処理Ｓ２０９は、前記電文Ｔ１０２を通知する前記処理Ｓ２０４の後で実施されてもよい。この場合、前記電文Ｔ１０２は、前記電文Ｂの確定済前であるため、前記電文Ｂの確定済応答を含まなくなる。しかし、待機系サーバ２０、３０が、前記処理ＳＳ２０９によって前記電文Ｂを確定した以降に異なる入力電文に関する電文Ｔ１０２を送信する場合に、電文Ｂの確定済応答を行えばよい。例えば、前記通知Ｔ１０１に対する前記通知１０６と同様に、前記電文Ｔ１０２に新たに確定済電文Ｂの電文ＩＤを付与する別の電文形式Ｔ１０２´（図９ｂ）を送信することで実現される。さらに、実行系サーバ１０の前記処理Ｔ１０３も、図９ｂと同様に、前記電文Ｔ１０３に新たに確定済電文Ｂの電文ＩＤを付与する別の電文形式Ｔ１０３´（図９ｃ）を送信することで実現される。加えて、クライアントサーバ８０は、前記処理Ｓ８０６で、前記電文Ｔ１０３´が通知された電文Ｂの確定済の確認処理を行う。

以上に示したように、待機系サーバ２０、３０で実施される入力電文の同期済応答処理Ｓ２０４を、他の電文の確定処理を行う前に実施することが可能であり、この場合、クライアントサーバ８０に入力電文の受信完了応答Ｔ１０３を早く応答することが可能となる。

ここで、クライアントサーバ８０から送信される入力電文は、インメモリアプリケーションシステムに対して、何の処理要求も行わないような電文内容を有する電文であってもよい。例えば、次の入力電文が送信されなかった場合に、前記電文Ｔ１０３で通知された同期済電文をインメモリアプリケーションシステムに通知するために、処理要求を含まないような前記入力電文を送信してもよい。さらに、実行系サーバ１０と待機系サーバ２０、３０では、入力電文の処理内容が存在しない場合には、入力電文の格納処理を省略することもある。また、処理要求を含まないような前記入力電文をクライアントサーバ８０が送信するタイミングは、任意のタイミングでよい。例えば、次の入力電文が一定時間送信されなかった場合であったり、一定間隔で送信する場合であったり、前記の組合せであってもよい。

さらに、第２の実施形態も前記第１の実施形態の図７に示したように、クライアントサーバ８０とインメモリアプリケーションシステムとの間に中継サーバ５０が存在するようなシステム構成でも実現可能である。例えば、第１の実施形態と同様に、クライアントサーバ８０から中継サーバ５０には入力電文が送信され、中継サーバ５０が前記図８に示した送信元電文送信処理を実施し、前記入力電文の受信完了通知をクライアントサーバ８０に転送することで実現しても良い。また、クライアントサーバ８０が前記図８に示した送信元電文送信処理を行い、中継サーバ５０はクライアントサーバ８０とインアプリケーションシステム間の通信を転送することで実現しても良い。この場合、前記電文Ｔ１０６は、クライアントサーバ８０から中継サーバ５０へはユニキャスト通信で送信され、中継サーバが実行系サーバ１０と待機系サーバ２０、３０にマルチキャスト通信を行うことで実現しても良い。

以上、図８〜図１０に示した一連の処理を行うことで、クライアントサーバ８０からインメモリアプリケーションシステムへの入力電文のデータ複製を、クライアントサーバ８０からのマルチキャスト通信に対する処理だけで実現することができる。これにより、第１の実施形態と同様に、入力電文を受けた実行系サーバ１０が全待機系サーバ２０、３０にマルチキャスト通信で転送する場合に比べて、通信回数を削減して、待機系サーバ２０、３０への入力電文の複製を実現することができる。さらに、入力電文の通信と同じ通信の仕組みを用いることが出来るため、実行系サーバ１０が全待機系サーバ２０、３０にマルチキャスト通信するための機能を不要とすることができる。

＜第３の実施の形態＞
図１１から図１４は、本発明における第３の実施形態について表しており、第１の実施形態の一部を変更して実施することで実現される。

図１１は、第３の実施形態におけるインメモリアプリケーションシステムのソフトウェアを主体とした機能ブロック図で、前記第１の実施形態の図２の一部を変更したものである。図１１の各サーバは、前記第１実施形態の図２における各サーバの有する機能に加えて、以下に示す機能を有する。

実行系サーバ１０は、電文制御部１１０によって待機系サーバ２０、３０に複製が存在する入力電文の処理要求を実行する電文処理部１３０を有する。前記電文処理部１３０は、前記入力電文の処理要求を実施するために、必要となるデータ格納領域１３１を有する。処理要求は、例えば、前記データ格納領域１３１の参照処理や更新処理を含む。前記処理要求が更新処理である場合には、前記電文処理部１３０は、前記データ格納領域１３１を更新する機能に加えて、前記更新処理に関する情報を、前記電文制御部１１０を介して、同期電文として待機系サーバ２０、３０に送信する機能を有する。前記電文制御部１１０は、前記同期電文を格納する同期電文送信バッファ１１３を有する。さらに、同期状態制御部１１９は、前記同期電文送信バッファ１１３に格納される同期電文に対して待機系サーバ２０、３０の同期状態を認識し、前記同期状態を格納する機能を備える。

一方、待機系サーバ２０、３０も、実行系サーバ１０と同様に、電文処理部２３０及びデータ格納領域２３１、さらに、同期電文送信バッファ２１３を有する。待機系サーバ２０、３０の電文制御部２１０は、実行系サーバ１０の前記電文制御部１１０から送信された同期電文を前記同期電文送信バッファ２１３に格納する機能を有する。さらに、前記電文処理部２３０は、前記同期電文送信バッファ２１３に格納された同期電文を元に、実行系サーバ１０が実施した前記処理結果を前記データ格納領域２３１に反映する機能も有する。

図１２は、第３の実施形態におけるインメモリアプリケーションシステムのソフトウェアが、外部から送信された入力電文を複製する処理を表すシーケンス図であり、図３に示した第１の実施形態におけるシーケンスの一部を変更したものである。

図１２において、クライアントサーバ８０が入力電文Ａを送信してから、クライアントサーバ８０が電文Ａの受信完了応答を受信するまでのシーケンス（Ｓ１〜Ｓ６）は、前記第１実施形態の図３と同様である。

その後、実行系サーバ１０は、すでに待機系サーバ２０、３０と同期済となっており、処理可能な入力電文Ｘを電文処理部１３０で実行し（Ｓ３１）、その処理結果を同期電文Ｘ２として待機系サーバ２０、３０に送信することで、処理結果の同期を行う（Ｓ３２）。実行系サーバ１０は、Ｓ３２において、この同期電文Ｘ２の送信前に、全待機系サーバ２０、３０で同期済状態にある電文である電文Ａを確認し、同期電文Ｘ２に合わせて、電文Ａ確定通知を一緒に送信する。

待機系サーバ２０、３０では、電文Ａ確定通知を受信すると、すでに格納していた電文Ａに対して全ての待機系サーバ２０、３０の同期状態を同期済へと変更することで、電文Ａの確定を行う（Ｓ３３）。その後、同期電文Ｘ２の受信完了応答と合わせて、電文Ａ確定済応答を実行系サーバ１０へと応答する（Ｓ３４）。

実行系サーバ１０は、同期済応答と同様に、各待機系サーバ２０、３０からの確定済応答を受信すると、待機系サーバ２０、３０の同期状態３４１を確定済に変更して（Ｓ３５）、全待機系サーバ２０、３０からの確定済応答を待ち合わせる（Ｓ３６）。実行系サーバ１０が全応答を受信した後、入力電文Ｂの受信完了応答と合わせて、電文Ａ確定済応答をクライアントサーバ８０に応答する。以上により、入力電文Ａの複製が完了する。

図１３、図１４は、図１２に示した入力電文の複製処理の例を示すフローチャートである。まず、図１３は、入力電文の複製処理において、外部から送信された入力電文を待機系サーバ２０、３０で同期したことを確定するまでの処理の例を示すフローチャートで、前記第１の実施形態の図４の一部を変更したものである。図１３において、待機系サーバ２０、３０は、入力電文を受信すると、第１の実施形態の図４と同様に、前記処理Ｓ２０１から前記処理Ｓ２０４までを実施する。一方、実行系サーバ１０は、第１の実施形態と同様に、前記処理Ｓ１０１から前記処理Ｓ１０６までを実施する。

図１４は、入力電文の複製処理において、処理要求を実行系サーバ１０が処理し、前記処理結果を待機系サーバ２０、３０に複製する際に、待機系サーバ２０、３０で入力電文を確定する処理の例を示すフローチャートである。

図１４で、実行系サーバ１０の電文処理部１３０は、前記処理Ｓ１０６で実行可能となった入力電文を取り出す（Ｓ１２１）。例えば、ここでは、前記図１３で受信した入力電文Ａと異なる電文Ｃが取り出されたとして、以下に説明を行う。

実行系サーバ１０は、取り出した電文Ｃの処理要求に基づいて処理を実行する（Ｓ１２２）。次に、前記処理Ｓ１２２の電文Ｃにおける実行結果を待機系サーバ２０、３０のデータ格納領域に反映するための同期電文Ｃ２を生成し、前記同期電文送信バッファ１１３に格納した（Ｓ１２３）後、前記実行結果を前記データ格納領域１３１に反映する（Ｓ１２４）。

そして、前記図８に示した処理Ｓ８０３と同様に、待機系サーバ２０、３０で確定前である同期済電文Ｄが存在するかどうかを確認する（Ｓ１２５）。ここで、同期済電文Ｄは、前記図１３で処理される入力電文以外に、詳細は後述するが、待機系サーバ２０、３０に送信した同期電文そのものを含んでもよく、また、対象となる電文が複数ある場合には全対象電文を対象としてもよい。続いて、電文Ｃの処理結果を入力電文の送信元に応答するための実行結果電文Ｃ４を生成し、前記送信電文格納バッファに格納する（Ｓ１２６）。そして、前記同期電文Ｃ２を、前記処理Ｓ１２６で生成した前記電文Ｃ４と、前記処理Ｓ１２５で確認した電文Ｄの情報とともに、全待機系サーバ２０、３０にマルチキャスト通信で送信する（Ｓ１２７、Ｔ１３１）。

図１５ｂは、前記処理Ｓ１２６で生成された実行結果電文Ｃ４（電文Ｔ１３２）の一例を表すものであり、例えば、結果電文を一意に表す電文ＩＤ１３２１と、処理結果を示す電文内容１３２２を含む。さらに、前記電文ＩＤ１３２１は、処理した入力電文の電文ＩＤ１３０１と共通する番号をつけた例を示しており、これにより、どの入力電文を処理した結果かを合わせて通知することができる。ここで、入力電文の電文ＩＤを送信してもよい。

次に、図１５ａは、前記処理Ｓ１２７で送信される電文Ｔ１３１の一例を表すものであり、例えば、同期電文を一意に示す電文ＩＤ１３０１と、処理結果によってデータ格納領域が更新される情報を表す電文処理結果内容１３０４からなる同期電文Ｃ２を含む。加えて、前記電文Ｃ４と、前記処理Ｓ１２５で抽出した確定前の同期済電文の電文ＩＤ１３０３とを含む。

また、図１６ａは、前記処理Ｓ１２７で前記電文Ｔ１３１が送信される時点の同期電文送信バッファ１１３の一例を示すものであり、例えば、前記電文Ｔ１３１に加えて、前記図６と同様に、待機系サーバ２０、３０で同期電文の受信状態を示す同期状態１１３１を含む。次に、図１６ｂは、前記送信電文格納バッファ１１２の一例を示すものであり、結果電文内容に前記電文Ｃ４が格納された場合を示している。

一方、図１４において、待機系サーバ２０、３０は、前記図１３の処理Ｓ２０１〜Ｓ２０４と同様に、前記電文Ｔ１３１を受信し（Ｓ２２１）、前記電文Ｔ１３１を前記同期電文送信バッファ２１３に格納した（Ｓ２２２）後、前記処理Ｓ２２２で格納した同期電文Ｃ２に対する受信完了応答を生成し（Ｓ２２３）、前記処理Ｓ１３１と同様に、確定前であった同期済電文Ｄが確定したことを確認する（Ｓ２２４）。続いて、前記通知Ｔ１０２´と同様に、待機系サーバ２０、３０で確定した電文Ｄの確定済通知と合わせて、実行系サーバ１０に通知を行う（Ｓ２２５、Ｔ１０２´）。実行系サーバ１０は、前記処理Ｓ１０４〜Ｓ１０６と同様にして、前記応答を受信し（Ｓ１２８）、前記同期電文Ｃ２の確定済を確認し（Ｓ１２９）、前記電文Ｃ４を送信元に通知する（Ｓ１３０）。

さらに、前記電文Ｔ１３１で通知した確定前の同期済電文Ｄが確定したことを確認する（Ｓ１３１）。ここで、前記処理Ｓ１３１において、確定した電文Ｄが同期電文である場合には、同期電文を削除する処理を含んでもよい。

一方、待機系サーバ２０、３０は、前記処理Ｓ２２４で確定した電文のうち、確定した前記同期済電文Ｄより、以前に確定した同期済の入力電文Ｅに対する同期電文Ｅ２が存在する場合には、前記同期電文Ｅ２を読み込む（Ｓ２２６）。そして、前記同期電文Ｅ２を生成するために実行された入力電文Ｅを前記受信電文格納バッファ２１１から削除した（Ｓ２２７）後、同期電文Ｅ２の電文処理結果内容を前記データ格納領域２３１に反映し、同期電文Ｅ２を同期電文送信バッファから削除する（Ｓ２２８）。前記処理Ｓ２２８によって、待機系サーバ２０、３０のデータ格納領域２３１は、電文Ｅを実行された時点における実行系のデータ格納領域１３１の複製状態となる。

なお、本実施形態において、前記処理Ｓ１２３を実行するタイミングは、前記電文Ｔ１３１を送信する前であれば、異なるタイミングであってもよい。

また、本実施形態では、確定前の同期済電文Ｄが直前に同期済となった入力電文Ａと異なり、待機系サーバ２０、３０で反映される同期電文Ｅ２が直前に受信した同期電文Ｘ２と異なる例で説明したが、電文Ｄと電文Ａが同一であったり、電文Ｅ２と電文Ｘ２が同一であったりしてもよいし、さらには同期電文Ｘ２を生成した電文Ｘが電文Ｄと同一であってもよい。この場合、電文Ｔ１３１、１０２´に含まれる確定済電文ＩＤが、同期電文ＩＤから一意に算出可能な電文ＩＤとなるため、送信を省略することができ、通信量をさらに削減することが可能である。

以上、図１１から図１６ｂに示した一連の処理を行うことで、クライアントサーバ８０からインメモリアプリケーションシステムへの入力電文のデータ複製を、送信元からのマルチキャスト通信と、入力電文の実行結果を同期するために必要となるマルチキャスト通信を組み合わせることで実現することができる。これにより、第１の実施形態と同様に、入力電文を受けた実行系サーバ１０が全待機系サーバ２０、３０にマルチキャスト通信で転送する場合に比べて、通信回数を削減して、待機系サーバ２０、３０への入力電文の複製を実現することができる。

＜第４の実施の形態＞
図１７から図２２は、本発明における第４の実施形態について表しており、第３の実施形態にさらに追加して実施することで実現される。また、図１７から図２２は、実行系サーバ１０に障害が発生した場合に、系切り替えによって待機系サーバ２０、３０のうちの一台が実行系サーバ１０の処理を引き継ぐまでの回復処理を示している。ここで、第３の実施形態において、マルチキャスト通信によって入力電文ならびに同期電文が各待機系サーバ２０、３０に送信されるため、待機系サーバ２０、３０間の電文の同期状態が一致しない場合が存在することがある。従って、本第４実施形態で示す回復処理では、このような待機系サーバ２０、３０間の同期状態の不一致を解消する整合性回復処理を含む。

まず、図１７は、待機系サーバ２０、３０で行われる全体の処理の一例を示すフローチャートである。この例では、実行系サーバ１０を待機系サーバ２０（待機系１）で引き継ぐ例を示す。なお、複数の待機系サーバ２０、３０で実行系サーバ１０の障害発生を監視し、障害発生時に処理を引き継ぐ待機系サーバ２０、３０の何れかを決定する手法は、公知または周知の技術を用いればよいので、ここでは詳述しない。

実行系サーバ１０で障害が発生すると、各待機系サーバ２０、３０はクラスタ制御部２２０で前記障害を検出し（Ｓ２５１、Ｓ３５１）、自身の各バッファに格納される電文を確認した後（Ｓ２５２、Ｓ３５２）、相互に通信を行い（Ｔ１５１、Ｔ１５２）、他の待機系サーバ２０、３０で格納される電文の同期状態を受信する（Ｓ２５３、Ｓ２５４、Ｓ３５３、Ｓ３５４）。

続いて、実行系サーバ１０の系切り替え先となる待機系サーバ２０（以降、系切り替え先サーバ）は、他の待機系サーバ３０（以降、非系切り替え先サーバ）と通信することで、全ての待機系での電文状態を同期させる電文同期状態の整合性回復処理を実行する（Ｓ２５５、Ｓ３５５、Ｔ１５３）。前記整合性回復処理は図１８以降で詳細を示すが、前記一連の処理によって、系切り替え先サーバと非系切り替え先サーバ間で回復が必要な電文は、各バッファにおける電文の同期状態が、全系に電文が存在する場合には確定済み状態となり、系切り替え先サーバでは同期電文がデータ格納領域に反映された状態となる。従って、系切り替え先サーバは実行系サーバ１０として、動作を継続することができる。

図１８は、前記整合性回復処理の一例を示し、電文の同期状態に応じて、回復方法を選択して、各回復方法を実行する例を示すフローチャートである。図１８では、系切り替え先サーバで実行する例を示す。

まず、系切り替え先サーバは、前記図１７の処理Ｓ２５４で受信した他系（非系切り替え先サーバ）の電文の同期状態と自系の電文の同期状態を参照し、ある電文に対する状態を確認し（Ｓ２７１）、次に、電文のうち、整合性回復処理を実施していない未処理の電文があるかを判断する（Ｓ２７２）。全ての電文の整合性回復処理が完了している場合や、回復する対象となる電文がいずれの系にも格納されていない場合は、整合性が保証されるため、整合性回復処理を終了する。一方で、格納された電文がある場合には、Ｓ２７３以降の処理が行われる。

まず、いずれかひとつのサーバが未受信かどうかを判断し（Ｓ２７３）、いずれのサーバも未受信で無い場合には、受信済の電文の整合性処理Ｒ３が呼び出される。ここで未受信状態は、ある系に格納されている電文が他系において受信されていない状態を指す。例えば、前記電文Ｔ１０１のようにマルチキャスト通信された電文が通信障害などにより、あるサーバに届いていないような場合である。ここで、ある系でのみ確定済であるような電文が存在する場合は、その電文が未受信状態であるサーバは存在しない。確定済である電文は他系では少なくとも同期済以降の状態であることが前記第３の実施形態において保証されているため、他系に受信済みであり、未受信ではないためである。これは、各待機系サーバ２０、３０が電文を確定済とする前記図１４の処理Ｓ２２４や、確定済電文を消去する前記処理Ｓ２２７やＳ２２８で電文ＩＤを記録することで実現することが可能である。

一方、前記処理Ｓ２７３で、ある系で未受信である電文が存在した場合には、その電文を全系で受信済となるように補完するべきかどうかを判断し（Ｓ２７４）、補完を実施する整合性回復処理Ｒ２または補完を実施しない整合性回復処理Ｒ３を呼び出す。

ここで、前記処理Ｓ２７４において、補完するべきか否かの決定は、図２２に示すようなユーザによって設定される電文補完要否設定に基づいて実施されてもよい。図２２の例では、格納されている電文の種別の情報３１４毎にユーザが補完の要否を設定した情報３１５を用いて判断される。ここで、前記情報３１４は、電文種別として電文識別子で指定される例を示したが、各電文の処理内容を細かく指定する情報を含んでも良い。さらに、前記電文補完要否設定は、電文を送信したクライアントサーバ８０毎に補完すべきかどうかを定める情報３１６を含んでいる。このように電文やクライアントサーバ８０毎に補完の有無を設定することで、例えば、重要な処理要求だけの回復を行い、全ての電文を回復する場合に比べて、回復時間を削減することができる。さらに、図２２の電文補完要否設定の例ででは、電文種別毎に、あるいは更に情報３１６で指定するクライアントサーバ毎に、ある系で受信してからの経過時間範囲を設定してその時間範囲内では補完し、その時間範囲を越えると補完しないとの判断するための時間範囲情報３１７も指定可能である。このような時間範囲の設定を用いることで、例えば、入力電文を送信したクライアントサーバ８０が送信した入力電文に対する応答を受信しなかったため、エラーと認識している場合に、誤って入力電文を補完してしまい、エラー電文が受信済みとなってしまうような不整合が生じることを防ぐことができる。また、別の一例として、例えば、前記クライアントサーバ８０が入力電文を再送するような場合には、再送される入力電文を受けるより先に入力電文を補完しておくことができるため、高速に再送に対する受信応答を返すことができる。さらに、図２２の電文補完要否設定の例では補完すべき電文の上限数も情報３１８により指定可能である。つまり前記情報３１８で指定した数以上の電文は補完しないと判断する設定ができる。あるいは、補完すべき未受信の系の上限数を定めておき、前記補完先サーバ上限数以上の電文は補完しないといった方法によって、判断しても良い。これらの上限数を定めることで、整合性回復処理に要する時間を削減することができる。

図１９は、前記図１８のＳ２７４で未受信電文の補完を行わない場合の整合性回復処理Ｒ１の一例を示すフローチャートである。本処理では、対象となる電文の補完を行わず、未受信状態で整合性を取る処理を行う。

系切り替え先サーバは、まず該当する対象電文の削除を行う（Ｓ２７５）。ここで自系に対象電文が無い場合は、処理Ｓ２７５をスキップする。続いて、前記対象電文を未受信状態にする（すなわち、対象電文を削除する）ように状態変更通知を全系にマルチキャスト通信で行う（Ｓ２７６、Ｔ１５４）。前記電文Ｔ１５４は、例えば、対象電文のＩＤと、状態変更を含む。非系切り替え先サーバは、前記電文Ｔ１５５を受信すると（Ｓ３７１）、対象電文の状態変更（電文の削除）を行い（Ｓ３７２）、状態変更完了応答を系切り替え先サーバに応答する（Ｓ３７３、Ｔ１５５）。系切り替え先サーバは前記電文Ｔ１５５を全系から受信する（Ｓ２７７）。以上により、対象電文を未受信状態で整合性回復することが完了し、次の電文を処理するために前記図１８の処理Ｓ２７２を呼び出す（Ｒ４）。

図２０は、前記図１８のＳ２７４で未受信電文の補完を行う場合の整合性回復処理Ｒ２の一例を示すフローチャートである。本処理では、対象となる電文の補完を行い、同期済状態で整合性を取る処理を行う。

系切り替え先サーバは、まず該当する対象電文を自系が格納しているか判断する（Ｓ２７８）。ここで、自系に対象電文を保持していない場合には、対象電文を保持する非系切り替え先サーバに対象電文を送信するように要求する（Ｓ２７９、Ｔ１５６）。一方、処理Ｓ３７４で対象電文の送信要求を受けた非系切り替え先サーバは、格納された対象電文を系切り替え先サーバへ送信する（Ｓ３７５、Ｔ１５７）。系切り替え先サーバは前記電文Ｔ１５７を受信する（Ｓ２８０）と、対応する電文の格納バッファに対象電文を格納し、自系の状態を受信済みに変更する（Ｓ２８１）。以上により、自系に対象電文が格納された状態となるため、電文を保持しない非系切り替え先サーバへの電文転送処理（処理Ｓ２８２以降）を実行する。

系切り替え先サーバは、電文を保持していない非系切り替え先サーバに対して、対象となっている格納電文を転送する（Ｓ２８２、Ｔ１５８）。一方、処理Ｓ３７６で前記電文Ｔ１５９を受信した非系切り替え先サーバは、送信された前記対象電文を、自系の同期状態を受信済状態として、対応する格納バッファに格納し（Ｓ３７７）、転送された電文の受信完了を応答する（Ｓ３７８、Ｔ１５９）。

系切り替え先サーバは、前記電文Ｔ１５８を受信すると、送信元となる系の同期状態を同期済に変更し、前記処理Ｓ２８２で電文を転送した全系からの応答を待つ（Ｓ２８３）。なお、上記では、電文を保持しない非系切り替え先サーバが存在する場合で説明したが、非系切り替え先サーバが全て電文を保持する場合には、処理Ｓ２８２以降の電文転送処理はスキップされる。以上により、対象電文が全系で保持された同期済状態で整合性回復することが完了するため、受信済の電文の整合性処理Ｒ３を実行する。

ここで、前記電文Ｔ１５６の送信先は、対象電文を保持する非系切り替え先サーバから任意のサーバを選択してもよいし、もっとも通信が速いと想定されるサーバを選択してもよい。後者の場合は、転送量を削減することや回復時間を削減することができる。あるいは、全ての非系切り替え先サーバの系にマルチキャスト通信し、受信した非系切り替え先サーバが電文を格納していない場合は、対象電文の転送を行わないような方法で実現してもよい。この場合、実際に最も早く通信してきた非系切り替え先サーバからデータを受信するため、通信状態に変動が生じ、通信の速さを想定しにくい場合でも、整合性回復処理に要する時間を短縮して系切り替えからの回復時間を削減することができる。さらに、前記電文Ｔ１５８の送信先は、全ての非系切り替え先サーバとしてマルチキャスト通信し、対象電文を格納済みである非系切り替え先サーバは対象電文の格納を行わないような方法で実現してもよい。この場合。電文の有無に関わらず、正常動作時に他の待機系サーバに同期電文を送信する通信と同じ仕組みを用いることが出来るため、整合性回復処理に特化した通信機能を不要とすることができる。

図２１は、前記図１８のＳ２７３で電文の未受信がない場合に行われる受信済電文の整合性回復処理Ｒ３の一例を示すフローチャートである。本処理で対象となる電文の同期状態は、各系において同期済か確定済のいずれかの状態であり、本処理では、同期済状態の電文を確定済状態で整合性を取る処理を行う。

まず、系切り替え先サーバは、対象電文が同期電文か（第３の実施形態での記載方法を用いてＸ２とする）否かを判断する（Ｓ２８４）。

同期電文Ｘ２である場合には、系切り替え先サーバが、自系で同期済状態であるか否かを判断する（Ｓ２８５）。同期済状態である場合には、系切り替え先サーバでは、実行系サーバ１０になる（引き継ぐ）前に、同期電文を反映させる必要があるため、以降の処理を実施する。まず、前記図１４の処理Ｓ２２６、Ｓ２２７と同様に、同期電文Ｘ２を読込み、対応する入力電文Ｘを削除した後、前記同期電文Ｘ２から実行結果応答Ｘ４を取り出し、送信電文格納バッファ２１２に格納する（Ｓ２８６）。続いて、前記処理Ｓ２２８、Ｓ１２９と同様に、電文Ｘの実行結果の反映と同期電文Ｘ２の確定を行い、前記処理Ｓ１３０と同様に、前記処理Ｓ２８６で格納した実行結果応答Ｘ４を送信する。

以上により、系切り替え先サーバでは、実行系サーバ１０を引き継ぐ際に、同期電文の同期状態が確定済状態となる場合に、本来実行系サーバ１０で実施される処理に相当する処理が実現される。

以下、確定済状態を非系切り替え先サーバに通知し、電文の整合性を取るための処理（Ｓ２８７以降）が行われる。

ここで、送信元（クライアントサーバ８０）へ実行結果電文Ｘ４を送信する例を示したが、例えば、障害発生前に実行系サーバ１０が図１４における処理Ｓ１３０で電文の実行結果を送信済みであるかどうかを、入力電文のクライアントサーバ８０に対して確認することで、送信が不要であるような場合には、系切り替え先サーバが実行結果電文Ｘ４に関する前記処理Ｓ２８６、Ｓ１３０をスキップするような方法を用いても良い。これにより、入力電文のクライアントサーバ８０が受信済みの実行結果を重複送信するのを削減し、通信量の削減を図ることができる。

一方、前記処理Ｓ２８５で自系の同期状態が同期済でない場合は、確定済状態であるため、前記一連の同期電文の反映処理が完了していることになり、同様に処理Ｓ２８７以降が実施される。さらに、前記処理Ｓ２８４で対象電文が同期電文でなかった場合は、入力電文であるため、一連の前記反映処理は不要であり、さらに入力電文を確定済状態となることができるため、同様に処理Ｓ２８７以降が実施される。

まず、処理Ｓ２８７で、前記処理Ｓ２７６と同様に、系切り替え先サーバは、前記対象電文を確定済状態に変更するように状態変更通知を全系（非系切り替え先サーバ）にマルチキャスト通信で通知する。その後、非系切り替え先サーバが前記処理Ｓ１７１〜Ｓ１７３と同様に、状態変更を反映し、状態変更完了応答Ｔ１５５を返信する（Ｓ３７１〜Ｓ３７３）。系切り替え先サーバは、前記状態変更完了応答を受信すると、系の同期状態を確定済に変更し、全系の同期状態が確定済になるのを待つ（Ｓ２８８）。これにより、対象電文が全系で確定済となったことが確認される（Ｓ２８９）。処理Ｓ２８９では、対象電文が同期電文である場合には、前記処理Ｓ１２９と同様、同期電文を削除する処理を含んでも良い。

以上により、対象となった受信済電文が系切り替え先サーバではデータ更新した状態となり、他の非系切り替え先サーバでは確定済状態となる。これは、実行系サーバ１０が前記処理Ｓ１３１まで、待機系サーバ２０、３０が前記処理Ｓ２２５までを実施した正常動作時の電文同期状態と同様の状態であり、整合性が保証された状態である。従って、系切り替えが完了した場合に、非系切り替えサーバの確定済同期電文の実行結果の反映処理Ｓ２２８が実行されるため、整合性が回復された状態となる。処理Ｓ２８９が完了した後、次の電文に対する整合性回復処理するために前記図１８の処理Ｓ２７２を呼び出す（Ｒ４）。

なお、上述のように非系切り替え先サーバにおける回復処理では、前記処理Ｓ２２５での同期電文の確定済処理までを示したが、処理Ｓ２２６以降における確定済同期電文の反映処理を実施しても良い。この場合、整合性回復処理の完了時にデータ格納領域の内容も整合性が保証することができる。

ここで、第４の実施形態は、第３の実施形態の変形として、入力電文と同期電文の双方を有する場合において説明したが、第１の実施形態のように入力電文のみがある場合に適用しても良く、同期電文に関する一連の処理をスキップすればよい。

以上、図１７から図２１に示した第４の実施形態によれば、インメモリアプリケーションシステムにおいて、上記クライアントサーバ８０による入力電文送信から実行系サーバ１０による転送開始までの間に障害が発生した場合には、入力電文が喪失するのに対して、全待機系サーバ２０、３０に入力電文が複製されているため、入力電文を喪失すること無く補完して、処理を継続する事のできる高信頼なシステムを提供することができる。さらに加えて、同期電文も、同様に補完することで、全待機系に対する複製が完了する前に障害が発生した場合であっても、その処理結果が少なくとも１台の待機系に存在する場合には、電文の処理を再実行することなく、処理を継続する事のできる高信頼なシステムを提供することができる。すなわち、通信回数を削減する本発明によるデータ複製方法を用いて通信回数を削減した場合でも、高信頼なシステムを提供することが可能となる。

なお、本発明における各実施形態では、実行系サーバ１０から待機系サーバ２０、３０に対してデータを複製する手段として、マルチキャスト通信を用いた場合について示したが、送信先サーバにデータの複製を実現する手段であれば、異なる手段を用いても構わない。例えば、ハードウェア機構によってＤＭＡ転送や共有メモリを実現することで、複製する手段であったりしてもよい。

以上のように、本発明は、クラスタ構成を取るインメモリアプリケーションシステムに適用することが可能である。特に、通信回数を削減することができるため、通信頻度の高いシステムに適用すると好適である。

本発明の第１の実施形態におけるシステム構成を示すブロック図である。 本発明の第１の実施形態におけるソフトウェア構成を示すブロック図である。 本発明の第１の実施形態における入力電文を複製する処理の一例を示すシーケンス図である。 本発明の第１の実施形態における入力電文を複製する処理の一例を示すフローチャートで、クライアントサーバと実行系サーバ及び待機系サーバの処理の関連を示す。 本発明の第１の実施形態における電文の一例を示す説明図である。 本発明の第１の実施形態における同期応答の一例を示す説明図である。 本発明の第１の実施形態における受信完了応答の一例を示す説明図である。 本発明の第１の実施形態における電文確定通知の一例を示す説明図である。 本発明の第１の実施形態における受信電文格納バッファの一例を示す説明図である。 本発明の第１の実施形態におけるシステム構成の他の例を示すブロック図である。 本発明の第２の実施形態における入力電文を複製する処理の一例を示すフローチャートで、クライアントサーバと実行系サーバ及び待機系サーバの処理の関連を示す。 本発明の第２の実施形態における電文の一例を示す説明図である。 本発明の第２の実施形態における電文の他の例を示す説明図である。 本発明の第２の実施形態における電文のさらに他の例を示す説明図である。 本発明の第２の実施形態における入力電文を複製する処理の一例を示すシーケンス図である。 本発明の第３の実施形態におけるシステム構成の一例を示すブロック図である。 本発明の第３の実施形態における入力電文を複製する処理の一例を示すシーケンス図である。 本発明の第３の実施形態における入力電文を複製する処理の一例を示すフローチャートで、クライアントサーバと実行系サーバ及び待機系サーバの処理の関連を示す。 本発明の第３の実施形態における入力電文を複製処理において待機系サーバで入力電文を確定する処理の一例を示すフローチャートで、クライアントサーバと実行系サーバ及び待機系サーバの処理の関連を示す。 本発明の第３の実施形態における電文の一例を示す説明図である。 本発明の第３の実施形態における実行結果電文の一例を示す説明図である。 本発明の第３の実施形態における同期電文送信バッファの一例を示す説明図である。 本発明の第３の実施形態における送信電文格納バッファの一例を示す説明図である。 本発明の第４の実施形態における整合性回復処理の一例を示すフローチャートで、待機系サーバ内の全体の処理を示す。 本発明の第４の実施形態における整合性回復処理の一例を示し、系切り替え先サーバで行われる処理のフローチャートで、電文の同期状態に応じて回復方法を決定する整合性回復処理の一例を示す。 本発明の第４の実施形態における未受信電文の補完を行わない場合の整合性回復処理の一例を示すフローチャートである。 本発明の第４の実施形態における未受信電文の補完を行う場合の整合性回復処理の一例を示すフローチャートである。 本発明の第４の実施形態における受信済電文の整合性回復処理の一例を表すフローチャートである。 本発明の第４の実施形態におけるユーザが指定可能な電文補完要否設定の一例を示す表である。

符号の説明

１０ 実行系サーバ
２０、３０ 待機系サーバ
５０ 中継サーバ
８０ クライアントサーバ
１１０、２１０、５１０、８１０ 電文制御部
１１９、２１９、５１９ 同期状態制御部
１１１、２１１、５１１ 受信電文格納バッファ
１１２、２１２、５１２ 送信電文格納バッファ
１２０、２２０ クラスタ制御部
１３０、２３０ 電文処理部
１３１、２３１ データ格納領域

Claims (20)

1. プロセッサとメモリを備えてアプリケーションを実行する第１の計算機と、
   プロセッサとメモリを備えて実行系の前記第１の計算機を引き継ぎ可能な第２の計算機と、を備え、前記第１の計算機が第１の処理要求を含む第１の電文を受信し、複数の第２の計算機で前記第１の電文を複製するデータ複製方法であって、
   第３の計算機が前記第１の電文を、前記第１の計算機と前記複数の第２の計算機に送信するステップと、
   前記第２の計算機が、前記第１の電文の受信完了通知を前記第１の計算機に送信するステップと、
   前記第１の計算機が、全ての第２の計算機からの前記受信完了通知を待ち合わせるステップと、
   前記第１の計算機が、前記複数の第２の計算機からの受信完了通知を受信するステップと、を含み、
   前記複数の第２の計算機からの受信完了通知を受信するステップは、
   前記第１の計算機が、複数の第２の計算機からの受信完了通知を受信した後に、前記第３の計算機に前記第１の電文の受信完了通知を送信するステップと、
   前記第１の計算機が、複数の第２の計算機からの受信完了通知を受信した後に、前記第１の処理要求を第１の計算機で実行可能なように有効とするステップと、
   前記第１の計算機が、複数の第２の計算機からの受信完了通知を受信した後に、前記第２の計算機に前記第１の電文が有効であることを通知するステップと、
   を含むことを特徴としたデータ複製方法。
2. 請求項１に記載のデータ複製方法であって、
   前記第１の電文の受信完了通知を通知された前記第３の計算機が、第２の処理要求を含む第２の電文を前記第１の計算機と前記第２の計算機に送信するステップをさらに含み、
   前記第１の電文が有効であることを示す通知を、第１の計算機が前記第２の計算機に通知するステップは、
   前記第３の計算機から受信した第２の処理要求を含む第２の電文と、前記第１の電文が有効であることを示す通知とを一緒に送信することを特徴とするデータ複製方法。
3. 請求項１に記載のデータ複製方法であって、
   前記第２の計算機が、前記第１の計算機に障害が発生したことを検知するステップと、
   前記第２の計算機が、前記第１の計算機に障害が発生したときに、当該第１の計算機を引き継ぐステップと、をさらに含み、
   前記第１の計算機に障害が発生したときに、前記第１の計算機を引き継ぐステップは、
   前記複数の第２の計算機のうちのひとつを前記第１の計算機を引き継ぐ系切り替え先計算機とし、当該系切り替え先計算機が、他の前記第２の計算機に電文の受信状態を問い合わせるステップと、
   前記系切り替え先計算機が、前記問合せの結果得られた電文の受信状態と、当該系切り替え先計算機が有する電文の受信状態とを照合するステップと、
   前記照合の結果、前記系切り替え先計算機と前記他の第２の計算機との間に電文の受信状態に不整合状態が存在する場合に、当該系切り替え先計算機が全ての第２の計算機の受信状態を同一の受信状態に設定するステップと、を含み、
   前記全ての第２の計算機の受信状態を同一とした後に、前記系切り替え先計算機が障害の発生した第１の計算機の処理を引き継ぐことを特徴とするデータ複製方法。
4. 請求項３に記載のデータ複製方法であって、
   前記系切り替え先計算機が全ての第２の計算機の受信状態を同一の受信状態に設定するステップは、
   前記不整合状態である電文の受信状態が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であることを判定する第１の判定ステップと、
   前記判定の結果が前記電文を受信する前の受信状態であれば、前記系切り替え先計算機が前記第２の計算機に当該電文の削除を指令する第１の整合性保証ステップと、
   前記不整合状態である電文の受信状態が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であり、かつ、前記第２の計算機の少なくとも１つが前記電文を受信済みであることを判定する第２の判定ステップと、
   前記判定の結果が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であり、かつ、前記第２の計算機の少なくとも１つが前記電文を受信済みの場合に、前記電文を前記受信済みの前記第２の計算機から全ての第２の計算機に前記電文を複製する第２の整合性保証ステップと、
   前記電文毎に前記第１の整合性保証ステップと第２の整合性保証ステップのいずれか一方を選択するステップと、を含むことを特徴とするデータ複製方法。
5. 請求項４に記載のデータ複製方法であって、
   前記第１の整合性保証ステップと第２の整合性保証ステップを選択するステップは、
   前記電文の処理内容と、前記電文を送信した第３の計算機の識別子と、前記電文が送信された時間と、前記電文の再送タイミングのうちの少なくとも一つを判断基準として、当該判断基準を満たすときに前記第１の整合性保証ステップを選択し、当該判断基準を満たさないときに前記第２の整合性保証ステップを選択することを特徴とするデータ複製方法。
6. 請求項５に記載のデータ複製方法であって、前記判断基準は前記第１の計算機または第２の計算機のユーザにより設定されることを特徴とするデータ複製方法。
7. 請求項１に記載のデータ複製方法であって、
   前記第１の処理要求が有効であることを第１の計算機が前記第２の計算機に通知するステップは、
   前記第１の計算機が、第２の計算機に第３の電文を送信する際に、前記第３の電文と前記有効であることの通知とを一緒に通知することを特徴としたデータ複製方法。
8. 請求項７に記載のデータ複製方法であって、
   前記第１の計算機が、第３の処理要求を含む電文を実行することでメモリ上のデータを更新し、前記更新結果を前記第２の計算機に通知を送信するステップを、さらに含み、
   前記第３の電文が、前記更新結果の通知であることを特徴とするデータ複製方法。
9. 請求項８に記載のデータ複製方法であって、
   前記第２の計算機が、前記第１の計算機に障害が発生したことを検知するステップと、
   前記第２の計算機が、前記第１の計算機に障害が発生したときに、当該第１の計算機を引き継ぐステップと、をさらに含み、
   前記第１の計算機に障害が発生したときに、前記第１の計算機を引き継ぐステップは、
   前記複数の第２の計算機のうちのひとつを前記第１の計算機を引き継ぐ系切り替え先計算機とし、当該系切り替え先計算機が、他の前記第２の計算機に電文の受信状態を問い合わせるステップと、
   前記系切り替え先計算機が、前記問合せの結果得られた電文の受信状態と、当該系切り替え先計算機が有する電文の受信状態とを照合するステップと、
   前記照合の結果、前記系切り替え先計算機と前記他の第２の計算機との間に電文の受信状態に不整合状態が存在する場合に、当該系切り替え先計算機が全ての第２の計算機の受信状態を同一の受信状態に設定するステップと、を含み、
   前記全ての第２の計算機の受信状態を同一とした後に、前記系切り替え先計算機が障害の発生した第１の計算機の処理を引き継ぐことを特徴とするデータ複製方法。
10. 請求項９に記載のデータ複製方法であって、
    前記系切り替え先計算機が全ての第２の計算機の受信状態を同一の受信状態に設定するステップは、
    前記不整合状態である電文の受信状態が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であることを判定する第１の判定ステップと、
    前記判定の結果が前記電文を受信する前の受信状態であれば、前記系切り替え先計算機が前記第２の計算機に当該電文の削除を指令する第１の整合性保証ステップと、
    前記不整合状態である電文の受信状態が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であり、かつ、前記第２の計算機の少なくとも１つが前記電文を受信済みであることを判定する第２の判定ステップと、
    前記判定の結果が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であり、かつ、前記第２の計算機の少なくとも１つが前記電文を受信済みの場合に、前記電文を前記受信済みの前記第２の計算機から全ての第２の計算機に前記電文を複製する第２の整合性保証ステップと、
    前記電文毎に前記第１の整合性保証ステップと第２の整合性保証ステップのいずれか一方を選択するステップと、を含むことを特徴とするデータ複製方法。
11. 請求項１０に記載のデータ複製方法であって、
    前記第１の整合性保証ステップと第２の整合性保証ステップを選択するステップは、
    前記電文の処理内容と、前記電文を送信した第３の計算機の識別子と、前記電文が送信された時間と、前記電文の再送タイミングのうちの少なくとも一つを判断基準として、当該判断基準を満たすときに前記第１の整合性保証ステップを選択し、当該判断基準を満たさないときに前記第２の整合性保証ステップを選択することを特徴とするデータ複製方法。
12. 請求項１に記載のデータ複製方法であって、
    前記第１の計算機または第２の計算機が、メモリ上でのみ前記アプリケーションの処理を実行することを特徴とするデータ複製方法。
13. プロセッサとメモリを備えてアプリケーションを実行する第１の計算機と、
    プロセッサとメモリを備えて実行系の前記第１の計算機を引き継ぎ可能な第２の計算機と
    第３の計算機から送信される第１の処理要求を含む第１の電文を前記第１の計算機と複数の第２の計算機で複製するデータ複製システムであって、
    前記第３の計算機は、前記第１の電文を、前記第１の計算機と前記複数の第２の計算機に送信する第３の制御部を有し、
    前記第２の計算機は、前記第１の電文の受信完了通知を前記第１の計算機に送信する第２の制御部を有し、
    前記第１の計算機は、全ての第２の計算機からの前記受信完了通知を待ち合わせる第１の制御部を有し、
    前記第１の制御部は、
    前記複数の第２の計算機からの受信完了通知を受信した後に、前記第３の計算機に前記第１の電文の受信完了通知を第１の通信部と、
    前記複数の第２の計算機からの受信完了通知を受信した後に、前記第１の処理要求を第１の計算機で実行可能なように有効とする確定部と、
    前記複数の第２の計算機からの受信完了通知を受信した後に、前記第２の計算機に前記第１の電文が有効であることを通知する第２の通信部と、
    を有することを特徴とするデータ複製システム。
14. 請求項１３に記載のデータ複製システムであって、
    前記第３の計算機の前記第３の制御部は、
    前記第１の電文の受信完了通知を受信した後に、第２の処理要求を含む第２の電文を前記第１の計算機と第２の計算機に送信し、
    前記第２の通信部は、
    前記第３の計算機から受信した第２の処理要求を含む第２の電文と、前記第１の電文が有効であることを示す通知とを一緒に送信することを特徴とするデータ複製システム。
15. 請求項１３に記載のデータ複製システムであって、
    前記第２の通信部は、
    前記第１の計算機が第２の計算機に第３の電文を送信する際に、前記第３の電文と前記第１の電文が有効であることを示す通知とを、一緒に送信することを特徴とするデータ複製システム。
16. 請求項１５に記載のデータ複製システムであって、
    前記第１の計算機は、第３の処理要求を含む電文を実行することでメモリ上のデータを更新し、前記更新結果を第２の計算機に送信する第３の通信部を有し、
    前記第３の電文が、前記更新結果の通知であることを特徴とするデータ複製システム。
17. 請求項１３に記載のデータ複製システムであって、
    前記第２の計算機は、
    前記第１の計算機に障害が発生したことを検知する障害検知部と、
    前記障害検知部が前記第１の計算機の障害を検知したときに、当該第１の計算機を引き継ぐクラスタ制御部と、をさらに有し、
    前記クラスタ制御部は、
    前記複数の第２の計算機のうちのひとつを前記第１の計算機を引き継ぐ系切り替え先計算機とし、当該系切り替え先計算機が、他の前記第２の計算機に前記電文の受信状態を問い合わせ、
    前記系切り替え先計算機が、前記問合せの結果得られた電文の受信状態と、当該系切り替え先計算機が有する電文の受信状態とを照合し、
    前記照合の結果、前記系切り替え先計算機と前記他の第２の計算機との間に電文の受信状態に不整合状態が存在する場合に、当該系切り替え先計算機が全ての第２の計算機の受信状態を同一の受信状態に設定する整合性保証部、を有し、
    前記全ての第２の計算機の受信状態を同一とした後に、前記系切り替え先計算機が障害の発生した第１の計算機の処理を引き継ぐことを特徴とするデータ複製システム。
18. 請求項１７に記載のデータ複製システムであって、
    前記整合性保証部は、
    前記不整合状態である電文の受信状態が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であることを判定する第１の判定部と、
    前記判定の結果が前記電文を受信する前の受信状態であれば、前記系切り替え先計算機が前記第２の計算機に当該電文の削除を指令する第１の整合性保証部と、
    前記不整合状態である電文の受信状態が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であり、かつ、前記第２の計算機の少なくとも１つが前記電文を受信済みであることを判定する第２の判定部と、
    前記判定の結果が、前記第２の計算機のうちの少なくとも１つが前記電文を受信する前の受信状態であり、かつ、前記第２の計算機の少なくとも１つが前記電文を受信済みの場合に、前記電文を前記受信済みの前記第２の計算機から全ての第２の計算機に前記電文を複製する第２の整合性保証部と、
    前記電文毎に前記第１の整合性保証部と第２の整合性保証部のいずれか一方を選択する選択部と、
    を有することを特徴とするデータ複製システム。
19. 前記請求項１８に記載のデータ複製システムであって、
    前記選択部は、
    前記電文の処理内容と、前記電文を送信した第３の計算機の識別子と、前記電文が送信された時間と、前記電文の再送タイミングのうちの少なくとも一つを基準として、当該基準を満たすときに前記第１の整合性保証部を選択し、当該基準を満たさないときに前記第２の整合性保証部を選択することを特徴とするデータ複製システム。
20. 請求項１３に記載のデータ複製システムであって、
    前記第１の計算機または第２の計算機が、メモリ上でのみ前記アプリケーションの処理を実行することを特徴とするデータ複製システム。

Images