知財求人 - 知財ポータルサイト「IP Force」
特開2024-14546データ管理システム、データ管理方法及びデータ管理プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024014546
(43)【公開日】2024-02-01
(54)【発明の名称】データ管理システム、データ管理方法及びデータ管理プログラム
(51)【国際特許分類】
G06F 16/178 20190101AFI20240125BHJP
G06F 11/20 20060101ALI20240125BHJP
【ＦＩ】
G06F16/178
G06F11/20 664
【審査請求】未請求
【請求項の数】7
【出願形態】ＯＬ
(21)【出願番号】P 2022117451
(22)【出願日】2022-07-22
(71)【出願人】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】古賀 啓太郎
(72)【発明者】
【氏名】三浦 浩一
(72)【発明者】
【氏名】廣瀬 厚人
(72)【発明者】
【氏名】山田 俊昭
【テーマコード（参考）】
5B034
【Ｆターム（参考）】
5B034CC02
5B034DD06
(57)【要約】
【課題】システムの信頼性を向上させるデータ管理システム、データ管理方法及びデータ管理プログラムを提供する。
【解決手段】ＡＰＩ処理部１０５は、クライアントアプリケーション３００から複数の処理命令を含む一括処理依頼を受信して、一括処理依頼に含まれる各処理命令を順次実行すする。一時格納処理部１０６は、ＡＰＩ処理部１０５によるそれぞれの処理命令の実行が完了する毎に、各処理命令による処理済データを一時格納領域１０２に格納する。同期処理部１０７は、一時格納領域１０２に格納された処理済データが別クライアントアプリケーションにより参照された場合、一時格納領域１０２の参照状態に基づいて所定の処理済データをスタンバイノード２０へ送信し、ＡＰＩ処理部１０５による一括処理依頼に含まれる全ての処理命令の実行が完了すると、未送信の処理済データをスタンバイノード２０に送信してデータ同期を行なう。
【選択図】図３
【解決手段】ＡＰＩ処理部１０５は、クライアントアプリケーション３００から複数の処理命令を含む一括処理依頼を受信して、一括処理依頼に含まれる各処理命令を順次実行すする。一時格納処理部１０６は、ＡＰＩ処理部１０５によるそれぞれの処理命令の実行が完了する毎に、各処理命令による処理済データを一時格納領域１０２に格納する。同期処理部１０７は、一時格納領域１０２に格納された処理済データが別クライアントアプリケーションにより参照された場合、一時格納領域１０２の参照状態に基づいて所定の処理済データをスタンバイノード２０へ送信し、ＡＰＩ処理部１０５による一括処理依頼に含まれる全ての処理命令の実行が完了すると、未送信の処理済データをスタンバイノード２０に送信してデータ同期を行なう。
【選択図】図３
【特許請求の範囲】
【請求項1】
運用系ノード及び待機系ノードを有する冗長化構成のデータ管理システムであって、
前記運用系ノードは、
受信した処理依頼の処理を行い、前記処理依頼が複数の処理命令を含む一括処理依頼の場合、前記一括処理依頼に含まれる各前記処理命令を順次実行する命令処理部と、
前記命令処理部によるそれぞれの前記処理命令の実行が完了する毎に、各前記処理命令による処理済データを一時格納領域に格納する一時格納処理部と、
前記一時格納領域に格納された前記処理済データが別の処理依頼の処理において参照された場合、前記一時格納領域の参照状態に基づいて所定の処理済データを前記待機系ノードへ送信し、前記命令処理部による前記一括処理依頼に含まれる全ての前記処理命令の実行が完了すると、未送信の前記処理済データである未送信処理済データを前記待機系ノードに送信してデータ同期を行なう同期処理部と
を備えることを特徴とするデータ管理システム。
前記運用系ノードは、
受信した処理依頼の処理を行い、前記処理依頼が複数の処理命令を含む一括処理依頼の場合、前記一括処理依頼に含まれる各前記処理命令を順次実行する命令処理部と、
前記命令処理部によるそれぞれの前記処理命令の実行が完了する毎に、各前記処理命令による処理済データを一時格納領域に格納する一時格納処理部と、
前記一時格納領域に格納された前記処理済データが別の処理依頼の処理において参照された場合、前記一時格納領域の参照状態に基づいて所定の処理済データを前記待機系ノードへ送信し、前記命令処理部による前記一括処理依頼に含まれる全ての前記処理命令の実行が完了すると、未送信の前記処理済データである未送信処理済データを前記待機系ノードに送信してデータ同期を行なう同期処理部と
を備えることを特徴とするデータ管理システム。
【請求項2】
前記待機系ノードは、
自装置が前記運用系ノードに切り替わると前記一時格納領域として使用される待機系一時格納領域と、
前記データ同期時に前記処理済データを格納する同期用格納領域と、
前記同期処理部から、前記所定の処理済データを受信すると、前記待機系一時格納領域に格納し、前記命令処理部による前記一括処理依頼に含まれる全ての前記処理命令の実行の完了後に、前記同期処理部から送信された前記未送信処理済データ及び前記待機系一時格納領域に格納された前記処理済データを、前記同期用格納領域に格納する格納処理部と
を備えたことを特徴とする請求項１に記載のデータ管理システム。
自装置が前記運用系ノードに切り替わると前記一時格納領域として使用される待機系一時格納領域と、
前記データ同期時に前記処理済データを格納する同期用格納領域と、
前記同期処理部から、前記所定の処理済データを受信すると、前記待機系一時格納領域に格納し、前記命令処理部による前記一括処理依頼に含まれる全ての前記処理命令の実行の完了後に、前記同期処理部から送信された前記未送信処理済データ及び前記待機系一時格納領域に格納された前記処理済データを、前記同期用格納領域に格納する格納処理部と
を備えたことを特徴とする請求項１に記載のデータ管理システム。
【請求項3】
前記命令処理部は、複数の前記処理命令の実行順序が予め決められた前記一括処理依頼を受信して、前記実行順序にしたがって前記処理命令を順番に実行し、
前記同期処理部は、前記一時格納領域に格納された特定の処理済データが前記別の処理依頼の処理において参照された場合、前記特定の処理済データ及び前記特定の処理済データの前記処理命令よりも前に実行された前記処理命令による前記処理済データを前記待機系ノードへ送信する
ことを特徴とする請求項１に記載のデータ管理システム。
前記同期処理部は、前記一時格納領域に格納された特定の処理済データが前記別の処理依頼の処理において参照された場合、前記特定の処理済データ及び前記特定の処理済データの前記処理命令よりも前に実行された前記処理命令による前記処理済データを前記待機系ノードへ送信する
ことを特徴とする請求項１に記載のデータ管理システム。
【請求項4】
前記同期処理部は、前記別の処理依頼の処理の完了後に、前記別の処理依頼の処理による処理済データとともに前記所定の処理済データを前記待機系ノードへ送信することを特徴とする請求項１に記載のデータ管理システム。
【請求項5】
前記命令処理部は、前記一括処理依頼のうち前記一時格納領域に格納済みの前記処理済データの前記処理命令を除いた他の処理命令を実行することを特徴とする請求項１に記載のデータ管理システム。
【請求項6】
運用系ノード及び待機系ノードを有する冗長化構成を用いたデータ管理方法であって、
前記運用系ノードに、
受信した処理依頼の処理を行わせ、前記処理依頼が複数の処理命令を含む一括処理依頼を受信させて、前記一括処理依頼に含まれる各処理命令を順次実行させ、
それぞれの前記処理命令の実行が完了する毎に、各前記処理命令による処理済データを一時格納領域に格納させ、
前記一時格納領域に格納された前記処理済データが別の処理依頼の処理において参照された場合、前記一時格納領域の参照状態に基づいて所定の処理済データを前記待機系ノードへ送信させ、
前記一括処理依頼に含まれる全ての前記処理命令の実行の完了後、未送信の前記処理済データである未送信処理済データを前記待機系ノードに送信させてデータ同期を行わせる
ことを特徴とするデータ管理方法。
前記運用系ノードに、
受信した処理依頼の処理を行わせ、前記処理依頼が複数の処理命令を含む一括処理依頼を受信させて、前記一括処理依頼に含まれる各処理命令を順次実行させ、
それぞれの前記処理命令の実行が完了する毎に、各前記処理命令による処理済データを一時格納領域に格納させ、
前記一時格納領域に格納された前記処理済データが別の処理依頼の処理において参照された場合、前記一時格納領域の参照状態に基づいて所定の処理済データを前記待機系ノードへ送信させ、
前記一括処理依頼に含まれる全ての前記処理命令の実行の完了後、未送信の前記処理済データである未送信処理済データを前記待機系ノードに送信させてデータ同期を行わせる
ことを特徴とするデータ管理方法。
【請求項7】
運用系コンピュータ及び待機系コンピュータを有する冗長化構成を用いたデータ管理方法であって、
受信した処理依頼の処理を行わせ、前記処理依頼が複数の処理命令を含む一括処理依頼の場合、前記一括処理依頼に含まれる各処理命令を順次実行し、
それぞれの前記処理命令の実行が完了する毎に、各前記処理命令による処理済データを一時格納領域に格納し、
前記一時格納領域に格納された前記処理済データが別の処理依頼において参照された場合、前記一時格納領域の参照状態に基づいて所定の処理済データを前記待機系コンピュータへ送信し、
前記一括処理依頼に含まれる全ての前記処理命令の実行の完了後、未送信の前記処理済データである未送信処理済データを前記待機系コンピュータに送信してデータ同期を行う
処理を前記運用系コンピュータに実行させることを特徴とするデータ管理プログラム。
受信した処理依頼の処理を行わせ、前記処理依頼が複数の処理命令を含む一括処理依頼の場合、前記一括処理依頼に含まれる各処理命令を順次実行し、
それぞれの前記処理命令の実行が完了する毎に、各前記処理命令による処理済データを一時格納領域に格納し、
前記一時格納領域に格納された前記処理済データが別の処理依頼において参照された場合、前記一時格納領域の参照状態に基づいて所定の処理済データを前記待機系コンピュータへ送信し、
前記一括処理依頼に含まれる全ての前記処理命令の実行の完了後、未送信の前記処理済データである未送信処理済データを前記待機系コンピュータに送信してデータ同期を行う
処理を前記運用系コンピュータに実行させることを特徴とするデータ管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データ管理システム、データ管理方法及びデータ管理プログラムに関する。
【背景技術】
【0002】
新型コロナウイルスの感染拡大による巣ごもり需要の高まりなどにより、近年、物販Ｅコマースの市場規模が急拡大している。物販Ｅコマースでは、インターネットの販売サイトを通じて、商品の注文を受け付けられると、倉庫やその倉庫で作業する作業担当者に対して商品発送の指示が出される。作業担当者は、商品発送の指示を受けて、指定された商品のピッキング(商品の取り揃え)及びピッキングした商品の梱包を行ったうえで、出荷伝票を貼り付ける。そして、宅配事業者が、出荷伝票が張り付けられた商品の配送の依頼を受けて、その商品を荷物として送り先へ配達する。
【0003】
宅配事業者の配達手順の一例について説明する。宅配事業者へ引き渡された荷物は、幹線輸送によって複数の宅配事業者の中継拠点を経由し、顧客宅の配達地域のベース店に持ち込まれる。ベース店に送られた荷物は、配達を担当する配達店に納入され、担当エリア毎の車に分けて積まれる。最終的に、宅配ドライバーが、荷物である商品を送り先へ配達する。
【0004】
また、近年、宅配事業者に対して、荷物の状態の管理や顧客への情報提供のために、物流過程における荷物の状態の可視化の需要が高まっている。この要望に応えるために、宅配事業者は、入庫、入庫検品、在庫管理、ピッキング、仕分け、出庫、出庫検品、商品管理、位置追跡及び盗難防止等の配送情報の可視化を促進している。例えば、宅配事業者は、物流の各プロセスで、出荷伝票のバーコードを読み取り、宅配システムの出荷伝票の追跡データを更新することで、様々な配送情報の可視化を実現している。
【0005】
宅配システムは、例えば、受付サーバ及び可視化などの処理を行う処理サーバを含む構成を有する。受付サーバは、荷物の検品データやトラッキングデータを作業員が操作する端末装置から受け付けて、処理サーバに処理を依頼する。処理サーバは、受付サーバからの処理の依頼にしたがって、可視化などの処理を行う。受付サーバは、多数のデータが送られてくるため、効率的にデータを処理サーバへ送信して、迅速に処理サーバに処理を行わせることが求められる。処理サーバは、処理の高速化のためにインメモリデータベースなどが用いられる。さらに、物理Ｅコマースの市場規模の急速拡大に伴い、宅配事業者に配送が依頼される商品も急増したため、宅配システムの処理性能のより一層の高速化が求められている。
【0006】
ここで、例えば宅配システムが停止し直ぐに業務が再開できなければ、宅配事業者は、予定時間通りの配達が困難となる。そこで、宅配システムにおいて処理サーバが故障した場合でも業務を継続可能にするため、処理サーバをクラスタ化してシステムを構成することで、可用性を高めることが行われる。クラスタシステムには、例えば、データを受け付けて実際に処理を行う運用系サーバであるアクティブノード及び待機系サーバであるスタンバイノードが配置されるホットスタンバイと呼ばれる構成を採用することができる。スタンバイノードは複数台配置されてもよく、その中の１台がアクティブノードへと切り替わり、それ以外はスタンバイサーバとして動作を継続する。
【0007】
ここで、ホットスタンバイでデータを保証するクラスタシステムの動作の一例について説明する。アクティブノードとスタンバイノードとは同じデータを保持し、アクティブノードで更新系の処理が確定すると、更新により発生した更新後データと更新前のデータとの差分である更新差分がスタンバイノードに送信されることで、データの同期が行われる。このデータの同期はミラーリングと呼ばれる。ミラーリングを開始するためのデータの更新差分が確定するタイミングには２つの方式がある。１つは、複数処理の結果をコミット実行で更新差分をスタンバイノードに一括反映する「通常コミット」である。また、もう１つは、１つの処理毎に自動で更新差分をスタンバイノードに逐次反映する「オートコミット」とである。
【0008】
オートコミット方式では、アクティブノードが、自己が有するデータ操作領域で操作を行い１つの処理が完了する毎に更新差分をコミットし、コミットの実行を契機としてスタンバイノードへのデータの同期を行なう。アクティブノードは、データ操作領域での操作後に更新差分の情報をスタンバイノードへ送信する。スタンバイノードは、ミラーリングのための一時格納領域であるミラーリングバッファを有する。スタンバイノードは、更新差分をミラーリングバッファに一時的に格納して同期の完了をアクティブノードに通知する。アクティブノードは、同期の完了通知を受けて、更新差分を自己が有するメモリテーブルに反映する。その後、アクティブノードは、クライアントとの間の処理に復帰する。スタンバイノードは、非同期でミラーリングバッファに格納された更新差分を自己が有するメモリテーブルに反映してミラーリングの処理を完了する。
【0009】
さらに、オートコミット方式のミラーリングにおいて、クライアントからアクティブノードのサーバにＡＰＩ（Application Programming Interface）を用いて処理を依頼する場合、複数のＡＰＩをまとめて一括処理として依頼することができる。複数のＡＰＩをまとめることで、クライアントとサーバとの間の通信回数を減らし、処理の高速化を図ることが可能となる。以上のような構成を有するクラスタシステムにおいて、さらにアクティブノードとスタンバイノードとの間の処理を効率化して、さらなる処理の高速化を図ることが考えられる。
【0010】
オートコミットを通知するＡＰＩにはそれぞれにコミット処理が付加される。そのため、オートコミット方式では複数のＡＰＩの一括処理が依頼された場合にも、各オートコミットを通知のそれぞれについてコミット処理が行われる。そこで、オートコミットを通知するＡＰＩ毎に毎回実行されるコミット処理を、最後以外には実行せずに最後に実行させることで、アクティブノードとスタンバイノードとの間のデータ同期回数を削減する方法が考えられる。
【0011】
なお、ＤＢ（Data Base）などについての冗長化の技術として以下のような技術が提案されている。例えば、更新データを累積バッファに格納し、トランザクション終了毎に更新データ反映バッファに更新データを格納し、反映間隔に達すると副系ＤＢに更新データを反映させ、障害発生時には同期点までの累積バッファを破棄する技術が提案されている。また、クエリをトランザクションキューに登録し、クエリがコミットされた場合、未コピークエリを一括して副サイトへ同期コピーし、障害発生時はグレートランザクションを調査して、手動回復を行う技術が提案されている。さらに、処理対象のトランザクションに関するコミット要求を蓄積し、蓄積数が一定の値に達すると一括コミット処理を実行する技術が提案されている。
【先行技術文献】
【特許文献】
【0012】
【特許文献1】特開平２－２９２６４１号公報
【特許文献2】特開２００４－２９５５４０号公報
【特許文献3】特開平７－２７１６４３号公報
【発明の概要】
【発明が解決しようとする課題】
【0013】
しかしながら、あるクライアントアプリケーションからの複数のＡＰＩを含む一括処理依頼の処理中は、処理が完了したＡＰＩについての処理済データが存在する場合でも、別クライアントアプリケーションは更新後の新しい状態のデータの参照が禁止される。そのため、多数のＡＰＩを含む一括処理依頼がなされた場合、別クライアントアプリケーションは、更新済データを用いるには、長時間の待ち時間が発生するおそれがある。このように、従来のクラスタシステムでは、システムの信頼性を向上させることが困難である。
【0014】
開示の技術は、上記に鑑みてなされたものであって、システムの信頼性を向上させるデータ管理システム、データ管理方法及びデータ管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【0015】
本願の開示するデータ管理システム、データ管理方法及びデータ管理プログラムの一つの態様において、データ管理システムは、冗長化された運用系ノード及び待機系ノードを有する。前記運用系ノードは、以下の各部を備える。命令処理部は、クライアントアプリケーションから複数の処理命令を含む一括処理依頼を受信して、前記一括処理依頼に含まれる各前記処理命令を順次実行する。一時格納処理部は、前記命令処理部によるそれぞれの前記処理命令の実行が完了する毎に、各前記処理命令による処理済データを一時格納領域に格納する。同期処理部は、前記一時格納領域に格納された前記処理済データが別クライアントアプリケーションにより参照された場合、前記一時格納領域の参照状態に基づいて所定の処理済データを前記待機系ノードへ送信し、前記命令処理部による前記一括処理依頼に含まれる全ての前記処理命令の実行が完了すると、未送信の前記処理済データである未送信処理済データを前記待機系ノードに送信してデータ同期を行なう。
【発明の効果】
【0016】
１つの側面では、本発明は、システムの信頼性を向上させることができる。
【図面の簡単な説明】
【0017】
【発明を実施するための形態】
【0018】
以下に、本願の開示するデータ管理システム、データ管理方法及びデータ管理プログラムの実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示するデータ管理システム、データ管理方法及びデータ管理プログラムが限定されるものではない。
【実施例0019】
図１は、実施例に係る情報処理システムのシステム構成図である。本実施例に係る情報処理システムは、例えば、運用系のサーバの故障から数秒で業務再開が求められている宅配システムである。情報処理システムは、クラスタシステム１及び端末装置３０を有する。また、情報処理システムは、受付サーバ４０を有してもよい。
【0020】
端末装置３０は、クライアントアプリケーションが動作する。端末装置３０で動作するクライアントアプリケーションは、クラスタシステム１で動作するアクティブノード１０に対して、ＡＰＩを用いて処理依頼を送信して、その処理依頼に対する応答を受信する。ＡＰＩを用いた処理依頼には、複数のＡＰＩの処理がまとめられた一括処理依頼も含まれる。例えば、端末装置３０は、倉庫の担当作業員が使用するコンピュータである。
【0021】
クラスタシステム１は、運用系のサーバであるアクティブノード１０及び待機系のサーバであるスタンバイノード２０を有する。クラスタシステム１は、スタンバイノード２０を複数有してもよい。クラスタシステム１では、オートコミット方式のミラーリングが採用される。このクラスタシステム１が、「データ管理システム」の一例にあたる。
【0022】
具体的には、アクティブノード１０が、端末装置３０から送信されたＡＰＩを用いた処理依頼の処理を実行する。その後、アクティブノード１０は、処理結果を端末装置３０へ送信する。アクティブノード１０は、端末装置３０から送られたＡＰＩの一括処理依頼も処理する。
【0023】
また、アクティブノード１０は、ミラーリングを行い自己が有するデータをスタンバイノード２０に送信して、自己が有するデータとスタンバイノード２０が有するデータとの間のデータの同期をとる。スタンバイノード２０が複数ある場合は、全てのスタンバイノード２０とアクティブノード１０との間でデータの同期がとられる。また、アクティブノード１０に障害が発生するなどしてダウンした場合、スタンバイノード２０が新たなアクティブノード１０に切り替わる。スタンバイノード２０が複数ある場合は、１台のスタンバイノード２０が新たなアクティブノード１０に切り替わり、残りは新たなアクティブノード１０に対するスタンバイノード２０となる。
【0024】
図２は、一括処理依頼の処理を示す図である。一括処理依頼には、例えば、図２に示すように、１番目のデータの書き込み、２番目のデータの書き込み及びデータの書き換えという３つの処理のＡＰＩがまとめて順番に登録された要求リスト１１が含まれる。端末装置３０は、要求リスト１１を含む一括処理依頼をアクティブノード１０へ送信する。図２に示すように、要求リスト１１には各ＡＰＩにインデックスが付されてもよい。もしくは、要求リスト１１は、実行する順番にしたがってＡＰＩが区別可能であり、インデックスを割り当てることが可能であるような構造を有してもよい。
【0025】
アクティブノード１０は、要求リスト１１を含む一括処理依頼を受信する。そして、アクティブノード１０は、第１のデータの書き込み、第２のデータの書き込み及びデータの書き換えの３つの処理のＡＰＩを順次処理する。ここで、アクティブノード１０は、要求リスト１１を含む一括処理依頼を受信した場合、最後のＡＰＩであるデータの書き換えのＡＰＩの処理後に更新差分をコミットして、スタンバイノード２０に対してそれまでの更新差分をまとめてミラーリング１４を実施する。この場合、アクティブノード１０は、第１のデータ書き込みのＡＰＩの処理後及び第２のデータ書き込みのＡＰＩの処理後には更新差分をコミットしない。すなわち、アクティブノード１０は、第１データ書き込みのＡＰＩの処理後のミラーリング１２及び第２のデータ書き込みのＡＰＩの処理後のミラーリング１３は行わない。ただし、本実施例に係るアクティブノード１０は、図２で示したミラーリング以外にも、一括処理依頼の処理中に生成された処理済データが参照されるとその参照に基づいた処理済データをスタンバイノード２０へ送信する。クラスタシステム１におけるデータ同期の詳細は後で説明する。
【0026】
【0027】
例えば、受付サーバ４０は、一括処理依頼などのＡＰＩを用いた処理依頼を端末装置３０から受け付ける。そして、受付サーバ４０は、各処理依頼の処理のタイミングなどを調整して、アクティブノード１０に対して、端末装置３０から受け付けた処理依頼を送信する。その後、受付サーバ４０は、処理依頼に対する処理結果を通知する応答をアクティブノード１０から受信する。そして、受付サーバ４０は、受信した応答を端末装置３０へ送信する。このように、受付サーバ４０でクライアントアプリケーションを動作させることも可能である。
【0028】
【0029】
次に、図３を参照して、クラスタシステム１によるデータ同期の詳細について説明する。以下の説明では、端末装置３０においてクライアントアプリケーション３００が動作する場合で説明する。ただし、受付サーバ４０においてクライアントアプリケーション３００が動作する場合でも、クラスタシステム１は同様の動作を行なう。また、以下の説明では、アクティブノード１０とスタンバイノード２０との機能について説明するが、スタンバイノード２０からアクティブノード１０に切り替わった場合は、新たなアクティブノード１０が切り替え前のアクティブノード１０と同様の機能を有する。
【0030】
端末装置３０は、クライアントアプリケーション３００が動作する。クライアントアプリケーション３００は、一括処理依頼を含む各種処理依頼をアクティブノード１０へ送信する。その後、クライアントアプリケーション３００は、処理依頼に対する応答をアクティブノード１０から受信して、処理を継続する。
【0031】
また、一括処理依頼を送信した場合にアクティブノード１０の切り替えを検知すると、スタンバイノード２０の１つが新たなアクティブノード１０に切り替わる。そして、クライアントアプリケーション３００は、一括処理依頼の再依頼をアクティブノード１０へ送信する。その後、クライアントアプリケーション３００は、処理依頼に対する応答をアクティブノード１０から受信して、処理を継続する。
【0032】
アクティブノード１０は、図３に示すように、データ操作領域１０１、一時格納領域１０２、メモリテーブル１０３、通信部１０４、ＡＰＩ処理部１０５、一時格納処理部１０６及び同期処理部１０７を有する。
【0033】
通信部１０４は、クライアントアプリケーション３００から送信された一括処理依頼などの各種処理依頼を受信する。処理依頼には、後述するような参照依頼を含む処理依頼が含まれてもよい。そして、通信部１０４は、受信した処理依頼をＡＰＩ処理部１０５へ出力する。その後、通信部１０４は、出力した処理依頼の処理結果をＡＰＩ処理部１０５から受信する。そして、通信部１０４は、出力した処理依頼が正常に処理された場合、処理結果を処理依頼に対する応答としてクライアントアプリケーション３００へ送信する。また、通信部１０４は、処理依頼の処理において異常が発生した場合、異常発生通知を応答としてクライアントアプリケーション３００へ送信する。通信部１０４が、クライアントアプリケーション３００へ応答を返すことで、アクティブノード１０は、クライアントアプリケーション３００との間の処理に復帰する。
【0034】
データ操作領域１０１は、ＡＰＩ処理部１０５が処理依頼にしたがってＡＰＩの処理を行う際にデータ操作に用いる領域である。データ操作領域１０１は、ＡＰＩ処理部１０５によるＡＰＩの処理結果として得られる処理済データをコミットログとして格納する。データ操作領域１０１は、クライアントアプリケーション３００から送信された処理依頼に対するスレッド毎に設けられる。各データ操作領域１０１は、あるスレッドついてのデータ操作領域１０１に格納されたデータは、別のスレッドの処理では用いられない。例えば、ＡＰＩ処理部１０５は、あるクライアントアプリケーション３００の処理依頼に対するデータ操作領域１０１に格納された処理済データを、別のクライアントアプリケーション３００からの処理依頼の処理において参照することは禁止される。以下では、異なるスレッド毎の処理として、２つの異なるクライアントアプリケーション３００からの処理依頼を例に説明するが、同じクライアントアプリケーション３００であっても異なる処理依頼であれば異なるスレッド毎の処理となる。
【0035】
図４は、データ操作領域に保存されるログのデータ構造を示す図である。データ操作領域１０１は、図４に示すように、レコード番号、ログ種別及びレコードデータを含むデータ構造１１１を有するコミットログを格納する。レコードデータには、処理済データが格納される。また、ログ種別は、その処理済データが生成され際に行われた処理の種別を表す情報である。例えば、ログ種別において、「Ｕ」は更新処理を表し、「Ｉ」は挿入処理を表し、「Ｄ」は削除処理を表す。また、レコード番号は、各レコードデータに割り当てられた識別情報である。
【0036】
一時格納領域１０２は、複数のＡＰＩを含む一括処理依頼の処理中の更新済データへのアクセスのための長時間待機の解消を目的として設けられる。一時格納領域１０２は、アクティブノード１０における処理済データを格納して蓄積する。これにより、一括処理依頼を行なったクライアントアプリケーション３００以外の別のクライアントアプリケーション３００は、一時格納領域１０２上の処理済データを参照して処理を進めることができる。
【0037】
ただし、単に一時格納領域１０２を追加しただけでは、以下のような問題が発生するおそれがある。ここでは、一括処理依頼を行なったクライアントアプリケーション３００以外の別のクライアントアプリケーション３００を、単に「別のクライアントアプリケーション３００」と呼ぶ。例えば、単に一時格納領域１０２を設けた場合、一括処理依頼の処理中における一部の処理済データはアクティブノード１０に蓄積されており、スタンバイノード２０には送られていない。この状態で、別のクライアントアプリケーション３００が、一時格納領域内１０２に格納された処理済データを参照して処理をコミットすると、コミットのタイミングでは参照された処理済データはスタンバイノード１０には保持されていない。そのため、このコミットのタイミングから一括処理依頼のコミットまでの間に、アクティブノード１０がダウンすると、別のクライアントアプリケーション３００が参照した処理済データが消えてしまう。一方、別のクライアントアプリケーション３００の当該処理済データを用いた処理がアクティブノード１０のダウン前に完了した場合、処理結果はスタンバイノード２０に反映される。すなわち、アクティブノード１０がダウンしても、スタンバイノード２０のメモリテーブル２０３に別のクライアントアプリケーション３００が実行した処理結果が残る。この場合、切り替わり後のアクティブノード１０には、存在しないデータを元にした処理結果がメモリテーブル２０３に残ることになりデータ不整合が発生する。
【0038】
なお、累積バッファ及び更新データ反映バッファを用いてＤＢを冗長化する技術では、予定されたタイミングでデータの反映が行われる。そのため、この技術を用いても一括処理毎に更新差分を反映するクラスタシステム１におけるアクティブノード１０のダウン時のデータ不整合に対処することは困難である。また、トランザクションキューに登録されたクエリをコミット発生時に一括して同期コピーする技術では、クエリを待機系が実行しておりデータの転送は行っていない。そのため、この技術を用いてもアクティブノード１０とスタンバイノード２０で保持するデータの相違による、アクティブノード１０のダウン時のデータ不整合に対処することは困難である。また、コミット要求の蓄積数が一定の値に達すると一括コミット処理を実行する技術では、特定のトランザクションが処理した処理済みデータに対する別のトランザクションによる参照は考慮されていない。そのため、別のクライアントアプリケーション３００に参照されたデータの、アクティブノード１０のダウン時の不整合に対処することは困難である。
【0039】
このように、単に一時格納領域１０２を追加した場合、クラスタシステム１の信頼性を向上するにあたって未だ不十分な部分がある。また、従来の技術を用いてもクラスタシステム１の十分な信頼性を得ることは困難である。そこで、アクティブノード１０のダウン時のデータの不整合の発生を解消するため、本実施例に係るクラスタシステム１は、以下のような構成を有する。
【0040】
一時格納領域１０２は、ＡＰＩ処理部１０５が一括処理依頼を処理する際に、各ＡＰＩの処理完了毎にデータ操作領域１０１に格納されたそのＡＰＩについての処理済データの複製がログとして一時的に格納される。一時格納領域１０２に格納された処理済データは、コミット前に別のクライアントアプリケーション３００の処理において使用可能である。例えば、ＡＰＩ処理部１０５は、あるクライアントアプリケーション３００の処理依頼の処理で生成された処理済データのうち一時格納領域１０２に格納された処理済データを、他のクライアントアプリケーション３００の処理において参照することができる。
【0041】
図５は、一時格納領域に保存されるログのデータ構造を示す図である。一時格納領域１０２は、図５に示すように、一時格納番号、レコード番号、ログ種別、レコードデータ及び送信済フラグを含むデータ構造１１２を有するログを格納する。レコードデータには、処理済データが格納される。レコード番号、ログ種別及びレコードデータは、データ操作領域１０１のデータ構造１１１におけるものと同様である。また、一時格納番号は、一括処理依頼に含まれる要求リスト１１の各ＡＰＩのインデックスに対応する値であり、後述するメモリテーブル１０３のレコードからのポインタが示す先となる。一時格納番号は、ＡＰＩ処理部１０５による特定のＡＰＩの処理結果を含むログが一時格納領域１０２に既に存在するかどうかの判定に用いられる。送信済フラグは、対応するログがスタンバイノード２０に送信済みであるか否かを表す情報である。送信済フラグは、対応するレコードデータが既にスタンバイノード２０に送られた場合はＯＮであり、未だ送られていない場合にはＯＦＦである。
【0042】
メモリテーブル１０３は、要求された処理が完了して最終的な更新差分のコミットが行われた場合に、処理済データが格納される領域である。メモリテーブル１０３に格納された処理済データは、スタンバイノード２０との間で同期が完了したデータである。
【0043】
図６は、メモリテーブルのレコードの構造を示す図である。メモリテーブル１０３は、図６に示すように、レコード番号、レコードデータ及び一時格納領域へのポインタを含むデータ構造１１３を有するレコードを格納する。レコード番号及びレコードデータは、データ操作領域１０１のデータ構造１１１におけるものと同様である。一時格納領域へのポインタは、一時格納領域１０２に同一のレコード番号を有するログが存在する場合、そのログの一時格納番号を示すポインタが格納される。例えば、メモリテーブル１０３に格納された特定のレコードデータが一括処理依頼に基づいて更新された場合について説明する。その場合、更新差分のコミット前の状態では、一時格納領域１０２へのポインタが示す一時格納番号に対応する一時格納領域１０２におけるログに含まれるレコードデータがその特定のレコードデータの更新後のデータである。
【0044】
図３に戻って説明を続ける。ＡＰＩ処理部１０５は、クライアントアプリケーション３００から送信された処理依頼の入力を通信部１０４から受ける。処理依頼が一括処理依頼の場合、ＡＰＩ処理部１０５は、一括処理依頼に含まれるＡＰＩを要求リスト１１で指定された処理順序にしたがって順番に処理する。
【0045】
ここで、切り替わりが発生していない状態のアクティブノード１０の場合と、切り替わり発生後にスタンバイノード２０からアクティブノード１０に切り替わった場合とで分けて、ＡＰＩ処理部１０５の動作を説明する。
【0046】
切り替わりが発生していない状態のアクティブノード１０の場合、ＡＰＩ処理部１０５は、一括処理依頼に含まれるＡＰＩを順番に処理して、各ＡＰＩの処理が完了する毎に、処理済データを含むＡＰＩの処理結果をコミットログの形式でデータ操作領域１０１に格納する。この際、ＡＰＩ処理部１０５は、要求リスト１１において各ＡＰＩにインデックスが付加されていなければ、要求リスト１１により指定された処理順序を基に決められたアルゴリズムでＡＰＩにインデックスを割り当てることができる。その場合、ＡＰＩ処理部１０５は、各ＡＰＩに割り当てた要求リスト１１におけるインデックスを一時格納処理部１０６に通知する。
【0047】
次に、ＡＰＩ処理部１０５は、処理したＡＰＩが一括処理依頼における最後のＡＰＩか否かを判定する。処理したＡＰＩが最後のＡＰＩでなければ、ＡＰＩ処理部１０５は、１つのＡＰＩの処理完了を一時格納処理部１０６に通知する。その後、ＡＰＩ処理部１０５は、次のＡＰＩの処理に移る。
【0048】
これに対して、処理したＡＰＩが最後のＡＰＩであれば、ＡＰＩ処理部１０５は、一括処理依頼の処理完了を同期処理部１０７に通知する。その後、ＡＰＩ処理部１０５は、メモリテーブル１０３への更新差分の反映完了の通知を同期処理部１０７から受ける。そして、ＡＰＩ処理部１０５は、処理結果を通信部１０４へ出力する。
【0049】
ただし、一括処理依頼におけるいずれかのＡＰＩの処理が正常に行えなかった場合、ＡＰＩ処理部１０５は、異常発生通知を通信部１０４へ出力する。この場合、ＡＰＩ処理部１０５は、一括処理依頼の処理を終了する。
【0050】
また、一括処理依頼の処理中にスタンバイノード２０がアクティブノード１０に切り替わった場合、新たなアクティブノード１０は、一括処理依頼の再実行依頼をクライアントアプリケーション３００から受ける。この場合、一括処理依頼に含まれるＡＰＩのうち処理結果がログとして既に一時格納領域１０２に格納されているＡＰＩが存在する場合がある。そこで、スタンバイノード２０がアクティブノード１０に切り替わった場合は、ＡＰＩ処理部１０５は、以下の動作を行なう。
【0051】
ＡＰＩ処理部１０５は、一括処理依頼に含まれるＡＰＩを順番に処理対象とする。そして、ＡＰＩ処理部１０５は、処理対象としたＡＰＩの要求リスト１１におけるインデックスに対応する一時格納番号を有するログが既に一時格納領域１０２に存在するか否かを判定する。処理対象としたＡＰＩのインデックスに対応する一時格納番号を有するログが既に一時格納領域１０２に存在する場合、ＡＰＩ処理部１０５は、そのＡＰＩの処理をスキップして、次のＡＰＩを処理対象として次のＡＰＩの処理に移る。
【0052】
これに対して、処理対象としたＡＰＩのインデックスに対応する一時格納番号を有するログが一時格納領域１０２に存在しない場合、ＡＰＩ処理部１０５は、処理対象としたＡＰＩの処理を実行する。その後、ＡＰＩ処理部１０５は、処理対象としたＡＰＩの処理結果をコミットログの形式でデータ操作領域１０１に格納する。
【0053】
次に、ＡＰＩ処理部１０５は、処理したＡＰＩが一括処理依頼の最後のＡＰＩか否かを判定する。処理したＡＰＩが最後のＡＰＩでなければ、ＡＰＩ処理部１０５は、１つのＡＰＩの処理完了を一時格納処理部１０６に通知する。その後、ＡＰＩ処理部１０５は、次のＡＰＩの処理に移る。
【0054】
これに対して、処理したＡＰＩが最後のＡＰＩであれば、ＡＰＩ処理部１０５は、一括処理依頼の処理完了を同期処理部１０７に通知する。その後、ＡＰＩ処理部１０５は、メモリテーブル１０３への更新差分の反映完了の通知を同期処理部１０７から受ける。そして、ＡＰＩ処理部１０５は、処理結果を通信部１０４へ出力する。ただし、この場合も、いずれかのＡＰＩの処理が正常終了しなければ、ＡＰＩ処理部１０５は、異常発生通知を通信部１０４へ出力する。
【0055】
また、クライアントアプリケーション３００から送信された処理依頼が一括処理依頼でない場合、ＡＰＩ処理部１０５は、その処理依頼で指定されたＡＰＩの処理を実行する。ＡＰＩの処理完了後、クライアントアプリケーション３００は、その処理依頼の処理完了を同期処理部１０７に通知する。その後、ＡＰＩ処理部１０５は、メモリテーブル１０３への更新差分の反映完了の通知を同期処理部１０７から受ける。そして、ＡＰＩ処理部１０５は、処理結果を通信部１０４へ出力する。ただし、この場合も、ＡＰＩの処理が正常終了しなければ、ＡＰＩ処理部１０５は、異常発生通知を通信部１０４へ出力する。
【0056】
ここで、クライアントアプリケーション３００からの処理依頼にデータの参照依頼が含まれている場合、ＡＰＩ処理部１０５は、メモリテーブル１０３の参照依頼で指定されたデータのレコードを参照する。そして、ＡＰＩ処理部１０５は、参照したレコードの一時格納領域へのポインタが初期状態であるか否かを判定する。
【0057】
一時格納領域へのポインタが初期状態であれば、ＡＰＩ処理部１０５は、メモリテーブル１０３のレコードのレコードデータに含まれるデータを参照する。その後、ＡＰＩ処理部１０５は、参照したデータを用いて処理依頼に含まれるＡＰＩの処理を行なう。処理完了後、ＡＰＩ処理部１０５は、処理依頼の処理完了を同期処理部１０７に通知する。この場合、参照されたデータは、実行中の一括処理依頼により生成された処理済データではないため、切り替え発生時のデータの不整合については考慮しなくてもよい。
【0058】
これに対して、一時格納領域へのポインタにポインタが格納されている場合、ＡＰＩ処理部１０５は、ポインタで示された一時格納番号を有する一時格納領域１０２のログを特定する。そして、ＡＰＩ処理部１０５は、特定した一時格納領域１０２のログのレコードデータである処理済データを参照する。
【0059】
次に、ＡＰＩ処理部１０５は、参照した処理済データを含むログの一時格納番号が、自己が記憶する最大送信番号の値より大きいか否かを判定する。ここで、最大送信番号は、一時格納領域１０２に格納されたログであってスタンバイノード２０への送信が完了したログの一時格納番号のうち最大の番号であり、その初期値は一時格納番号の最小値より小さい値である。ＡＰＩ処理部１０５は、参照した処理済データを含むログの一時格納番号が最大送信番号の値より大きい場合、参照した処理済データを含むログの一時格納番号を最大送信番号として記憶して最大送信番号の値を更新する。
【0060】
その後、ＡＰＩ処理部１０５は、参照した処理済データを用いて参照依頼を含む処理依頼に含まれるＡＰＩの処理を行なう。そして、参照依頼を含む処理依頼の処理完了後、ＡＰＩ処理部１０５は、一時格納領域１０２における最大送信番号以下のログの送信指示及び参照依頼を含む処理依頼の処理完了を同期処理部１０７に通知する。その後、ＡＰＩ処理部１０５は、更新差分の反映完了の通知を同期処理部１０７から受ける。そして、ＡＰＩ処理部１０５は、処理結果を通信部１０４へ出力する。ただし、この場合も、ＡＰＩの処理が正常終了しなければ、ＡＰＩ処理部１０５は、異常発生通知を通信部１０４へ出力する。
【0061】
一時格納処理部１０６は、一括処理依頼に含まれる各ＡＰＩの処理が完了する毎に、最後のＡＰＩ以外であれば、１つのＡＰＩの処理完了の通知をＡＰＩ処理部１０５から受ける。次に、一時格納処理部１０６は、通知されたＡＰＩの処理結果が登録されたコミットログをデータ操作領域１０１から取得する。そして、一時格納処理部１０６は、取得したコミットログに、そのＡＰＩの要求リスト１１におけるインデックスに対応する一時格納番号を付加し、且つ、送信済フラグをＯＦＦにして、一時格納領域１０２にログとして登録する。さらに、一時格納処理部１０６は、取得したコミットログをデータ操作領域１０１から削除する。
【0062】
次に、一時格納処理部１０６は、メモリテーブル１０３を参照して、一時格納領域に格納したログに含まれるレコード番号と同様のレコード番号のレコードがメモリテーブル１０３に存在するか否かを判定する。同様のレコード番号のレコードがメモリテーブル１０３に存在する場合、一時格納処理部１０６は、そのレコードの一時格納領域へのポインタに、一時格納領域１０２に格納したログの一時格納番号へのポインタを格納する。
【0063】
ここで、アクティブノード１０のメモリテーブル１０３に格納された一時格納番号へのポインタの情報は、スタンバイノード２０のメモリテーブル２０３に同期されていない。そこで、一時格納処理部１０６は、スタンバイノード２０がアクティブノード１０に切り替わった場合、切り替わりの直後にメモリテーブル１０３から一時格納領域１０２の一時格納番号を示すポインタを張り直す。
【0064】
具体的には、新たなアクティブノード１０の一時格納処理部１０６は、一時格納領域１０２に格納されたログを先頭から順番に参照する。そして、一時格納処理部１０６は、送信フラグがＯＮのログについては、一時格納領域１０２のログのレコード番号を検索キーとして、メモリテーブル１０３からそのレコード番号を有するレコードを検索する。そして、一時格納処理部１０６は、特定したレコードの一時格納領域へのポインタに、検索元の一時格納領域１０２のログの一時格納番号を登録する。一方、送信フラグがＯＦＦのログについては、一時格納処理部１０６は、クライアントアプリケーション３００からの一括処理依頼の再依頼による当該一括処理依頼の再実行時にポインタを登録する。
【0065】
同期処理部１０７は、一括処理依頼に含まれる全てのＡＰＩの処理が完了すると、一括処理依頼の処理完了の通知をＡＰＩ処理部１０５から受ける。次に、同期処理部１０７は、一括処理依頼の最後のＡＰＩの処理のコミットログをデータ操作領域１０１から取得する。また、同期処理部１０７は、一括処理依頼の最後以外のＡＰＩの処理結果のログのうち送信フラグがＯＦＦのログを一時格納領域１０２から取得する。すなわち、同期処理部１０７は、一括処理依頼の処理中に他のクライアントアプリケーション３００からの参照が行われて既にスタンバイノード２０に送られている処理済データのログは取得しない。そして、同期処理部１０７は、一括処理依頼の各ＡＰＩの処理結果のログをまとめたミラーリング用の送信データをスタンバイノード２０へ送信する。この際、同期処理部１０７は、一括処理依頼の更新差分のコミットの通知をスタンバイノード２０へ送信する。
【0066】
図７は、ミラーリング時にアクティブノードからスタンバイノードへ送信されるデータのデータ構造を示す図である。同期処理部１０７は、図７に示すデータ構造１１４を有するミラーリング用の送信データを作成する。ミラーリング用の送信データは、図７に示すように、通信ヘッダの後に、ＡＰＩの処理それぞれのミラーデータが格納される。
【0067】
図８は、ミラーデータのデータ構造を示す図である。各ミラーデータは、図８に示すようにトランザクション番号、レコード番号、ログ種別、レコードデータ及び一時領域フラグが含まれるデータ構造１１５を有する。レコード番号、ログ種別及びレコードデータは、データ操作領域１０１及び一時格納領域１０２におけるレコード番号、ログ種別及びレコードデータが用いられる。また、一時領域フラグは、スタンバイノード２０において一時格納領域２０１又はミラーリングバッファ２０２のいずれに格納するデータかを示す情報である。一時領域フラグは、「ＯＮ」の場合、一時格納領域２０１に格納するデータであることを示す。また、一時領域フラグは、「ＯＦＦ」の場合、ミラーリングバッファ２０３２に格納するデータであることを表す。同期処理部１０７は、一括処理依頼に含まれる全てのＡＰＩの処理の完了後に一括処理依頼の各ＡＰＩの処理結果のログを送信する場合、各ログのミラーデータの一時領域フラグをＯＦＦに設定する。
【0068】
同期処理部１０７は、ミラーリング用の送信データの送信に対する応答受領の通知をスタンバイノード２０から受信する。そして、同期処理部１０７は、一括処理依頼の最後のＡＰＩの処理結果のコミットログ及び一時格納領域１０２に格納されたログの情報をそれぞれ含むレコードをメモリテーブル１０３に格納して更新差分を反映する。さらに、同期処理部１０７は、メモリテーブル１０３における更新差分を反映したレコードの一時格納領域へのポインタを初期化する。その後、同期処理部１０７は、更新差分の反映完了をＡＰＩ処理部１０５に通知する。
【0069】
また、同期処理部１０７は、参照依頼を含む処理依頼の場合、一時格納領域１０２における最大送信番号の値以下の一時格納番号を有するログの送信指示及び当該処理依頼の処理完了の通知をＡＰＩ処理部１０５から受ける。そして、同期処理部１０７は、最大送信番号の値以下の一時格納番号を有するログのうち送信済フラグがＯＦＦのログを一時格納領域１０２から取得する。すなわち、同期処理部１０７は、最大送信番号の値以下の一時格納番号を有するログであっても、既にスタンバイノード２０へ送信済みのログは取得しない。以下、一時格納領域１０２における最大送信番号の値以下の一時格納番号を有するログのうち送信済フラグがＯＦＦのログを、「最大送信番号以下の未送信ログ」と呼ぶ。また、同期処理部１０７は、処理完了の通知を受けた参照依頼を含む処理依頼のコミットログをデータ操作領域１０１から取得する。
【0070】
そして、同期処理部１０７は、最大送信番号以下の未送信ログ及び参照依頼を含む処理依頼のコミットログのそれぞれのミラーデータを作成する。ここで、同期処理部１０７は、最大送信番号以下の未送信ログのミラーデータの場合、一時領域フラグをＯＮに設定する。また、同期処理部１０７は、参照依頼を含む処理依頼のコミットログのミラーデータの場合、一時領域フラグをＯＦＦに設定する。次に、同期処理部１０７は、作成した各ミラーデータを含むミラーリング用の送信データを生成する。そして、同期処理部１０７は、生成したミラーリング用の送信データをスタンバイノード２０へ送信する。
【0071】
その後、同期処理部１０７は、ミラーリング用の送信データの送信に対する応答受領の通知をスタンバイノード２０から受信する。そして、同期処理部１０７は、処理完了の通知を受けた参照依頼を含む処理依頼のコミットログに含まれる情報を登録したレコードをメモリテーブル１０３に格納して更新差分を反映する。また、同期処理部１０７は、一時格納領域１０２における最大送信番号の値以下の未送信ログの送信済フラグをＯＮに設定する。その後、同期処理部１０７は、更新差分の反映完了をＡＰＩ処理部１０５に通知する。
【0072】
次に、スタンバイノード２０について説明する。スタンバイノード２０は、一時格納領域２０１、ミラーリングバッファ２０２、メモリテーブル２０３及び格納処理部２０４を有する。
【0073】
一時格納領域２０１は、アクティブノード１０の一時格納領域１０２に格納されたログのうち、他のクライアントアプリケーション３００からの処理依頼により参照された処理済データを有するログを含むそれ以前に処理されたログを格納する領域である。言い換えれば、一時格納領域２０１は、アクティブノード１０の一時格納領域１０２に格納されたログのうち、最大送信番号の値以下の一時格納番号を有するログを一時的に格納する領域である。一時格納領域２０１に格納されるログも、図５に示したアクティブノード１０の一時格納領域１０２のログと同様のデータ構造１１２を有する。一時格納領域２０１は、スタンバイノード２０がアクティブノード１０に切り替わった場合、アクティブノード１０の一時格納領域１０２の機能を果たす。
【0074】
ミラーリングバッファ２０２は、処理依頼の処理完了後にコミットされた処理済データをミラーリング実行時に格納する領域である。ミラーリングバッファ２０２に格納された処理済データは、非同期でメモリテーブル２０３に映される。
【0075】
メモリテーブル２０３は、アクティブノード１０のメモリテーブル１０３と同期されて、同じレコードデータを保持する領域である。すなわち、メモリテーブル２０３は、コミットされた処理済データを保持する。メモリテーブル２０３に格納されたレコードも、図６に示したアクティブノード１０のメモリテーブル１０３のレコードと同様のデータ構造１１３を有する。メモリテーブル２０３は、スタンバイノード２０がアクティブノード１０に切り替わった場合、アクティブノード１０のメモリテーブル１０３の機能を果たす。
【0076】
格納処理部２０４は、アクティブノード１０による一括処理依頼の処理完了後に、一括処理依頼に含まれる各ＡＰＩの処理結果のミラーデータを含むミラーリング用の送信データを同期処理部１０７から受信する。ただし、このミラーリング用の送信データには、一括処理依頼に含まれる各ＡＰＩの処理結果のうち既に送信された処理結果のミラーデータは含まれない。また、格納処理部２０４は、アクティブノード１０による参照依頼を含む処理依頼の処理完了後に、最大送信番号の値以下の未送信ログ及び当該処理依頼のコミットログ毎のミラーデータをまとめたミラーリング用の送信データを同期処理部１０７から受信する。
【0077】
格納処理部２０４は、受信したミラーリング用の送信データに含まれる各ミラーデータの一時領域フラグを確認する。一時領域フラグがＯＮのミラーデータの場合、格納処理部２０４は、そのミラーデータに含まれる情報をログとして一時格納領域２０１に格納する。これに対して、一時領域フラグがＯＦＦのミラーデータの場合、格納処理部２０４は、そのミラーデータに含まれる情報をレコードとしてミラーリングバッファ２０２に格納する。
【0078】
さらに、格納処理部２０４は、一括処理依頼の更新差分のコミットの通知を受領した場合、一時格納領域２０１のログの情報を含むレコードをミラーリングバッファ２０２に格納して更新差分を反映させる。そして、格納処理部２０４は、一時格納領域２０１のログを削除する。
【0079】
ミラーリング用の送信データに含まれる全てのミラーデータの格納完了後、格納処理部２０４は、アクティブノード１０の同期処理部１０７へ受領応答を送信する。その後、所定のタイミングが到来すると、格納処理部２０４は、ミラーリングバッファ２０２のレコードの情報を全てメモリテーブル２０３に格納して、更新差分を反映させる。
【0080】
図９は、一時格納領域に格納された処理済データの参照が行われた場合の動作の概要を示す図である。次に、図９を参照して、本実施例に係るクラスタシステム１における一時格納領域１０２に格納された処理済データの参照が行われた場合の動作をまとめて説明する。ここでは、クライアントアプリケーション３０１及び３０２の２つが存在する場合で説明する。
【0081】
クライアントアプリケーション３０１は、一括処理依頼をアクティブノード１０へ送信する（ステップＳ１）。一括処理依頼を処理することで、アクティブノード１０は、各ＡＰＩを個別に処理する場合に比べて、スタンバイノード２０への同期回数を減らすことができる。
【0082】
アクティブノード１０のＡＰＩ処理部１０５は、クライアントアプリケーション３０１からの一括処理依頼の処理を開始する。例えば、要求リスト１１に含まれるＡＰＩのうちＡＰＩ［１］～［１０］の処理を行なう場合、ＡＰＩ処理部１０５は、データ操作領域１０１に、ＡＰＩ［１］～［１０］の処理に関するデータを格納する（ステップＳ２）。ここで、ＡＰＩ［１］～［４］の処理が完了すると、一時格納処理部１０６は、ＡＰＩ［１］～［４］の処理結果のログを一時格納領域１０２に格納する（ステップＳ３）。
【0083】
一時格納領域１０２に格納されたＡＰＩ［１］～［４］の処理結果のログは、コミット済み扱いとなり、一括処理依頼を行なったクライアントアプリケーション３０１以外のクライアントアプリケーション３０２も参照可能である。より詳しくは、一時格納領域１０２に格納されたログとメモリテーブル１０３の対応するレコードとを一時格納領域１０２へのポインタを用いて紐付けることで、クライアントアプリケーション３０１は、ポインタを元に一時格納領域１０２上の新しい状態を参照可能となる。このように、一時格納領域１０２に処理済データを蓄積することで、一括処理依頼の処理完了を待たずに、クライアントアプリケーション３０２が処理済データを参照でき、処理の高速化を図ることができる。
【0084】
この時点で、クライアントアプリケーション３０２からＡＰＩ［２］による処理済データの参照依頼を含む処理依頼をアクティブノード１０が受信すると、ＡＰＩ処理部１０５は、参照依頼にしたがってＡＰＩ［２］のログを参照する（ステップＳ４）。
【0085】
ＡＰＩ［２］のログが参照されると、同期処理部１０７は、一時格納番号がＡＰＩ［２］以下でスタンバイノード２０へ未送信のＡＰＩ［１］及び［２］の処理結果を含むミラーデータをまとめたミラーリング用の送信データを生成する。そして、同期処理部１０７は、生成したミラーリング用の送信データをスタンバイノード２０へ送信する（ステップＳ５）。
【0086】
このように、クライアントアプリケーション３０２が一時格納領域１０２上の処理済データを参照した際、アクティブノード１０は、参照された処理済みデータを含むそれ以前の処理結果のログをスタンバイノード２０へ送信する。これにより、クライアントアプリケーション３０２から参照されたデータがスタンバイノード２０にないことによる、アクティブノード１０のダウン時のデータのロストを回避することができる。また、参照された処理済データより前の処理結果もまとめてスタンバイノード２０へ送信して同期させることで、一括処理依頼に含まれるＡＰＩの処理結果の順序を崩さないようにすることができる。
【0087】
また、ミラーリング用の送信データの送信タイミングとしては、アクティブノード１０は、クライアントアプリケーション３０２からの処理依頼による更新差分のコミット時に送信する。この際、アクティブノード１０は、一時格納領域１０２に格納されたログの送信済フラグにより、各ログのデータがスタンバイノード２０へ送信済みか否かを判定する。クライアントアプリケーション３０２からの処理依頼のコミットと同じタイミングで参照された処理済データ以前の処理結果をスタンバイノード２０に送信することで、アクティブノード１０は、送信回数を増やすことなくクラスタシステム１の処理を高速化することができる。
【0088】
スタンバイノード２０では、ＡＰＩ［１］及び［２］の処理結果のログが一時格納領域２０１に格納される（ステップＳ６）。ここで、スタンバイノード２０は、送られてきたミラーデータの一時領域フラグを用いて、一時格納領域２０１又はミラーリングバッファ２０２のいずれに格納するかを判定する。一時格納領域２０１に格納されたＡＰＩの処理結果は、切り替え発生時の一括処理依頼の再実行時にそのまま使用でき、新たなアクティブノード１０は、一時格納領域２０１に格納されたＡＰＩより後のＡＰＩを処理すればよい。
【0089】
図１０は、一括処理依頼の処理実行中にアクティブノードの切り替えが発生した場合の動作の概要を示す図である。次に、図１０を参照して、本実施例に係るクラスタシステム１における一括処理依頼の処理実行中にアクティブノード１０の切り替えが発生した場合の動作をまとめて説明する。
【0090】
図９の状態でアクティブノード１０がダウンして、アクティブノード１０の切り替えが発生する（ステップＳ７）。この場合、切り替わったスタンバイノード２０の一時格納領域２０１は、新たなアクティブノード１０の一時格納領域１０２となる。すなわち、切り替わった直後の状態で、切り替わり後の新たなアクティブノード１０の一時格納領域１０２には、ＡＰＩ［１］及び［２］の処理結果のログが存在する。また、切り替わったスタンバイノード２０のメモリテーブル２０３は、新たなアクティブノード１０のメモリテーブル１０３となる。ただし、切り替わったスタンバイノード２０のミラーリングバッファ２０２は、切り替わり後には使用されない。
【0091】
クライアントアプリケーション３０１は、送信した一括処理依頼の処理が完了していないため、一括処理依頼の再実行を依頼する（ステップＳ８）。
【0092】
新たなアクティブノード１０は、一括処理依頼の再依頼を受けて、先頭のＡＰＩから処理を開始する。この際、アクティブノード１０は、ＡＰＩ［１］及び［２］の処理結果がログとして一時格納領域１０２に既に格納されている。そのため、アクティブノード１０は、ＡＰＩ［１］及び［２］の処理結果のデータ操作領域１０１への格納は行わない。そして、アクティブノード１０は、ＡＰＩ［３］から実際の処理を開始する。
【0093】
このように、スタンバイノード２０の一時格納領域２０１に処理結果を送信しておくことで、切り替え後の新たなアクティブノード１０は、データを突き合わせて処理結果が格納済のＡＰＩの処理をスキップでき、二重処理を避けて一括処理依頼を処理できる。このように、新しいアクティブノード１０で二重処理を避けて一括処理依頼が処理されることで、クライアントアプリケーション３０１は処理状態を気にすることなく、一括処理依頼の再実行を依頼できる。
【0094】
次に、一括処理依頼の処理時のアクティブノード１０の状態の遷移の一例を説明する。図１１は、一括処理依頼の処理時のアクティブノードが有するデータの遷移を示す第１の図である。図１２は、一括処理依頼の処理時のアクティブノードが有するデータの遷移を示す第２の図である。図１１の最初の状態４０１から図１２の最後の状態４０６に向けて時系列で、順番にデータ操作領域１０１、一時格納領域１０２及びメモリテーブル１０３の状態が遷移する。
【0095】
状態４０１は、アクティブノード１０が一括処理依頼を処理する前の状態を表す。この場合、一括処理依頼を処理する前であるため、データ操作領域１０１及び一時格納領域１０２には、何も格納されていない。一方、メモリテーブル１０３には、レコード番号Ｒ００１～Ｒ００４のレコードが格納されている。ただし、メモリテーブル１０３の各レコードの一時格納領域へのポインタは初期状態である。アクティブノード１０は、要求リスト１１を含む一括処理依頼の処理を開始する。要求リスト１１には、ＡＰＩ［１］～［５］の処理命令が含まれる。
【0096】
アクティブノード１０は、一括処理依頼におけるＡＰＩ［１］の処理の完了直前には、状態４０２に遷移する。ＡＰＩ処理部１０５は、ＡＰＩ［１］の処理結果をデータ操作領域１０１にコミットログとして登録する。ＡＰＩ処理部１０５は、ＡＰＩ［１］の処理により、メモリテーブル１０３に格納されたレコード番号Ｒ００１のレコードデータである“ａ１”を“ａ２”に書き換える。
【0097】
そして、ＡＰＩ［１］の処理が完了すると、アクティブノード１０は、状態４０３に遷移する。ここで、図１１及び１２では、要求リスト１１におけるＡＰＩの処理完了を取り消し線で表す。一時格納処理部１０６は、データ操作領域１０１におけるＡＰＩ［１］の処理結果のコミットログの情報を含むログを一時格納領域１０２に格納し、且つ、データ操作領域１０１からそのコミットログを削除する。この際、一時格納処理部１０６は、要求リスト１１におけるＡＰＩ［１］のインデックスに対応する一時格納番号としてＳ００１を割り当て、且つ、送信済みフラグをＯＦＦに設定する。ここでは、一時格納処理部１０６は、要求リストにおけるＡＰＩの括弧内の番号と、一時格納番号の最下位の番号とを対応させる。さらに、一時格納処理部１０６は、メモリテーブル１０３に登録されたレコード番号Ｒ００１のレコードの一時格納領域へのポインタに、一時格納領域１０２におけるレコード番号Ｒ００１のログの一時格納番号であるＳ００１を登録する。
【0098】
次に、アクティブノード１０は、一括処理依頼におけるＡＰＩ［２］の処理が完了すると、図１２の状態４０４に遷移する。ＡＰＩ処理部１０５は、ＡＰＩ［２］の処理することで、メモリテーブル１０３に格納されたレコード番号Ｒ００２のレコードデータである“ｂ１”を“ｂ２”に書き換える。そして、一時格納処理部１０６は、ＡＰＩ［２］の処理結果のレコード番号がＲ００２のログを一時格納領域１０２に格納する。この際、一時格納処理部１０６は、要求リスト１１におけるＡＰＩ［２］のインデックスに対応する一時格納番号としてＳ００２を割り当て、且つ、送信済みフラグをＯＦＦに設定する。さらに、一時格納処理部１０６は、メモリテーブル１０３に登録されたレコード番号Ｒ００２のレコードの一時格納領域へのポインタに、一時格納領域１０２におけるレコード番号Ｒ００２のログの一時格納番号であるＳ００２を登録する。
【0099】
次に、要求リスト１１の最後のＡＰＩ［５］の処理中には、アクティブノード１０は、状態４０５に遷移する。それまでに、ＡＰＩ処理部１０５は、ＡＰＩ［３］の処理により新たにレコードデータとして“ｃ１”を挿入し、さらに、ＡＰＩ［４］の処理によりメモリテーブル１０３に登録されたレコード番号がＲ００３のレコードデータである“ｄ１”を削除する。これにより、一時格納処理部１０６は、状態４０５に示す一時格納番号Ｓ００３及びＳ００４のログを一時格納領域１０２に格納し、且つ、メモリテーブル１０３に格納されたレコード番号がＲ００３の一時格納領域へのポインタを登録する。さらに、ＡＰＩ処理部１０５は、ＡＰＩ［５］の処理結果をデータ操作領域１０１にコミットログとして登録する。ＡＰＩ処理部１０５は、ＡＰＩ［５］の処理により、新たなレコードデータである“ｅ１”を挿入する。
【0100】
そして、一括処理依頼における最後のＡＰＩ［５］の処理が完了すると、アクティブノード１０は、状態４０６に遷移する。同期処理部１０７は、データ操作領域１０１に格納されたＡＰＩ［５］のコミットログ及び一時格納領域１０２に格納されたＡＰＩ［１］～［４］のログについてのそれぞれのミラーデータを含む送信データを生成する。そして、同期処理部１０７は、生成した送信データをスタンバイノード２０へ送信してミラーリングを実行する。その後、同期処理部１０７は、受領応答を受けると、メモリテーブル１０３に、データ操作領域１０１のコミットログ及び一時格納領域１０２のログの情報を含むレコードをメモリテーブル１０３に格納して、更新差分を反映する。さらに、同期処理部１０７は、メモリテーブル１０３の一時格納領域へのポインタを初期化するとともに、データ操作領域１０１のコミットログ及び一時格納領域１０２のログを削除する。
【0101】
次に、一括処理依頼の処理中に別のクライアントアプリケーション３００から処理済データの参照が行われた場合のアクティブノード１０及びスタンバイノード２０の状態の遷移の一例を説明する。図１３は、一括処理依頼の処理中に参照が行われた場合のアクティブノード及びスタンバイノードの状態の遷移の一例を示す図である。ここでは、図１２における状態４０５の場合に、別のクライアントアプリケーション３００からの処理依頼によりＡＰＩ［２］の処理結果である処理済データが参照された場合で説明する。
【0102】
図１２における状態４０５の場合に、別のクライアントアプリケーション３００からの処理依頼によりＡＰＩ［２］の処理結果である処理済データが参照されると、アクティブノード１０は、状態４１１に遷移する。ＡＰＩ処理部１０５は、参照依頼にしたがってメモリテーブル１０３におけるレコード番号がＲ００２のレコードを参照する。そこで、一時格納領域へのポインタとしてＳ００２が登録されていることから、ＡＰＩ処理部１０５は、一時格納領域１０２における一時格納番号がＳ００２のログを参照して、レコードデータとして登録された“ｂ２”を取得する。
【0103】
さらに、ＡＰＩ処理部１０５は、参照されたレコードの一時格納番号が、自己が記憶する最大送信番号の値よりも大きいかを判定する。この場合は、初めての参照であるので、ＡＰＩ処理部１０５は、参照したＡＰＩ［２］の処理結果のログの一時格納番号であるＳ００２を最大送信番号とする。そして、ＡＰＩ処理部１０５は、Ｓ００２以下の一時格納番号を有するログの送信を同期処理部１０７に指示する。ここで、Ｓ００２以下の一時格納番号とは、一時格納番号がＳ００２であるログに格納された処理結果についての処理以前のＡＰＩの処理による処理結果を含むログの一時格納番号である。同期処理部１０７は、Ｓ００２以下の一時格納番号を有し且つ送信済みフラグがＯＦＦであるＡＰＩ［１］及び［２］の処理結果のログをスタンバイノード２０へ送信する。
【0104】
スタンバイノード２０にＡＰＩ［１］及び［２］の処理結果のログが送信されると、アクティブノード１０及びスタンバイノード２０は、状態４１２に遷移する。すなわち、同期処理部１０７は、一時格納領域１０２における一時格納番号がＳ００１及びＳ００２のログの送信済みフラグをＯＮに設定する。さらに、スタンバイノード２０の格納処理部２０４は、ＡＰＩ［１］及び［２］の処理結果のログを一時格納領域２０１に格納する。
【0105】
その後、一括処理依頼の処理が全て完了すると、アクティブノード１０及びスタンバイノード２０は、状態４１３に遷移する。すなわち、同期処理部１０７は、一時格納領域１０２の全てのログの情報を含むレコードをメモリテーブル１０３へ格納して、更新差分を反映させ、一時格納領域１０２の全てのログを削除する。また、同期処理部１０７は、一時格納領域へのポインタを初期化する。また、スタンバイノード２０の格納処理部２０４は、一時格納領域２０１に格納された各ログの情報を含むレコードをミラーリングバッファ２０２へ格納して、更新差分を反映させ、且つ、一時格納領域２０１に格納された全てのログを削除する。
【0106】
図１４は、一括処理依頼を処理中に参照がない場合のクラスタシステムの動作を示すシーケンス図である。次に、図１４を参照して、一括処理依頼を処理中に別のクライアントアプリケーション３００から参照がない場合のクラスタシステム１の動作を説明する。
【0107】
クライアントアプリケーション３００は、アクティブノード１０に一括処理依頼を送信する（ステップＳ１０１）。
【0108】
アクティブノード１０のＡＰＩ処理部１０５は、一括処理依頼を通信部１０４から取得する。そして、ＡＰＩ処理部１０５は、データ操作領域１０１を用いて、一括処理依頼に含まれる各ＡＰＩの処理を順番に行う（ステップＳ１０２）。各ＡＰＩの処理後、ＡＰＩ処理部１０５は、ＡＰＩの処理が正常終了したか否かを判定する（ステップＳ１０３）。
【0109】
ＡＰＩの処理が正常終了しなかった場合（ステップＳ１０３：否定）、ＡＰＩ処理部１０５は、異常発生の通知をクライアントアプリケーション３００へ送信して、クライアントアプリケーション３００との間の処理に復帰する（ステップＳ１０４）。
【0110】
これに対して、ＡＰＩの処理が正常終了した場合（ステップＳ１０３：肯定）、一時格納処理部１０６は、一時格納領域１０２にデータ操作領域１０１のコミットログに含まれるＡＰＩの処理結果の情報をログとして格納する（ステップＳ１０５）。
【0111】
次に、ＡＰＩ処理部１０５は、一括処理依頼に含まれる全てのＡＰＩの処理が完了したか否かを判定する（ステップＳ１０６）。処理していないＡＰＩが残っている場合（ステップＳ１０６：否定）、ＡＰＩ処理部１０５は、ステップＳ１０２へ戻る。
【0112】
これに対して、一括処理依頼に含まれる全てのＡＰＩの処理が完了した場合（ステップＳ１０６：肯定）、同期処理部１０７は、一時格納領域１０２に格納されたログを用いてそれぞれのミラーデータを作成する。この場合、同期処理部１０７は、いずれのミラーデータにおいても一時領域フラグをＯＦＦに設定する。その後、同期処理部１０７は、作成したミラーデータを格納したミラーリング用の送信データをスタンバイノード２０へ送信して、ミラーリングを実行する（ステップＳ１０７）。
【0113】
スタンバイノード２０の格納処理部２０４は、送信データを取得して、一時領域フラグがＯＦＦであることを確認して、全てのミラーデータに含まれるＡＰＩの処理結果の情報をレコードとしてミラーリングバッファ２０２に格納して、更新差分を反映する（ステップＳ１０８）。
【0114】
その後、格納処理部２０４は、ミラーリング用の送信データの受領応答をアクティブノード１０へ送信する（ステップＳ１０９）。
【0115】
アクティブノード１０の同期処理部１０７は、受領応答を受けて、一時格納領域１０２に格納された各ログの情報を含む複数のレコードをメモリテーブル１０３に格納して、更新差分を反映する（ステップＳ１１０）。さらに、同期処理部１０７は、一時格納領域１０２に格納されたログを削除する。
【0116】
その後、ＡＰＩ処理部１０５は、更新差分の反映完了の通知を同期処理部１０７から受けて、正常終了応答をクライアントアプリケーション３００に送信して、クライアントアプリケーション３００との間の処理に復帰する（ステップＳ１１１）。
【0117】
ここで説明したように、ＡＰＩの処理が正常終了しない場合には、アクティブノード１０は、異常発生通知をクライアントアプリケーション３００に通知するが、以下の説明では、異常発生の場合を省略して説明する。
【0118】
図１５は、一括処理依頼で処理中に参照がある場合のクラスタシステムの動作を示すシーケンス図である。次に、図１５を参照して、一括処理依頼を処理中に別のクライアントアプリケーション３００から参照がある場合のクラスタシステム１の動作を説明する。ここでは、クライアントアプリケーション３０１及び３０２が存在し、それぞれからの処理依頼を、アクティブノード１０がスレッド＃１及び＃２として処理する場合で説明する。
【0119】
クライアントアプリケーション３００は、アクティブノード１０に一括処理依頼を送信する（ステップＳ２０１）。
【0120】
アクティブノード１０のＡＰＩ処理部１０５は、一括処理依頼を通信部１０４から取得する。そして、ＡＰＩ処理部１０５は、スレッド＃１において、データ操作領域１０１を用いて括処理依頼に含まれる各ＡＰＩの処理を順番に行う（ステップＳ２０２）。
【0121】
スレッド＃１において１つのＡＰＩの処理が終了すると、一時格納処理部１０６は、一時格納領域１０２にデータ操作領域１０１のコミットログに含まれるＡＰＩの処理結果の情報をログとして格納する（ステップＳ２０３）。
【0122】
次に、ＡＰＩ処理部１０５は、スレッド＃１において、一括処理依頼に含まれる全てのＡＰＩの処理が完了したか否かを判定する（ステップＳ２０４）。処理していないＡＰＩが残っている場合（ステップＳ２０４：否定）、ＡＰＩ処理部１０５は、ステップＳ２０２へ戻る。
【0123】
これに対して、一括処理依頼に含まれる全てのＡＰＩの処理が完了した場合（ステップＳ２０４：肯定）、スレッド＃１における処理はステップＳ２１５へ進む。
【0124】
一方、ＡＰＩ処理部１０５がスレッド＃１において一括処理依頼を処理中に、クライアントアプリケーション３０２が、参照依頼を含む処理依頼をアクティブノード１０に送信する（ステップＳ２０５）。
【0125】
アクティブノード１０のＡＰＩ処理部１０５は、処理依頼を通信部１０４から取得する。そして、ＡＰＩ処理部１０５は、スレッド＃２において、データ操作領域１０１を用いて、処理依頼に含まれるＡＰＩの処理を実行する（ステップＳ２０６）。その処理依頼の中の参照依頼により、ＡＰＩ処理部１０５は、一時格納領域１０２に格納されたＡＰＩの処理結果のログを参照する（ステップＳ２０７）。
【0126】
その後、スレッド＃２における処理依頼の処理が完了すると、ＡＰＩ処理部１０５は、参照したログの一時格納番号が最大送信番号の値よりも大きければ、参照したログの一時格納番号を最大送信番号とする。そして、ＡＰＩ処理部１０５は、最大送信番号の値以下の未送信ログの送信指示及びスレッド＃２における処理依頼の処理完了を同期処理部１０７に通知する。同期処理部１０７は、通知を受けて、更新を含むコミットを実行する（ステップＳ２０８）。すなわち、同期処理部１０７は、一時格納領域１０２に格納された最大送信番号の値以下の未送信ログ及びデータ操作領域１０１に格納されたスレッド＃２における処理依頼のＡＰＩの処理結果のコミットログを取得する。そして、同期処理部１０７は、それぞれのミラーデータを生成する。この際、同期処理部１０７は、一時格納領域１０２に格納された最大送信番号の値以下の未送信ログのミラーデータの一時領域フラグをＯＮにする。また、同期処理部１０７は、スレッド＃２における処理依頼のＡＰＩの処理結果のコミットログのミラーデータの一時領域フラグをＯＦＦにする。そして、同期処理部１０７は、作成したミラーデータを格納したミラーリング用の送信データをスタンバイノード２０へ送信して、ミラーリングを実行する（ステップＳ２０９）。
【0127】
スタンバイノード２０の格納処理部２０４は、ミラーリング用の送信データに含まれるミラーデータのうち一時領域フラグがＯＮのミラーデータに含まれるＡＰＩの処理結果を一時格納領域２０１に格納する。すなわち、格納処理部２０４は、アクティブノード１０の一時格納領域１０２に格納された一括処理に含まれるＡＰＩの処理結果のログのうち参照されたログ以前のログを自装置の一時格納領域２０１に格納して、更新差分を反映する（ステップＳ２１０）。
【0128】
また、格納処理部２０４は、ミラーリング用の送信データに含まれるミラーデータのうち一時領域フラグがＯＦＦのミラーデータに含まれるＡＰＩの処理結果を含むレコードをミラーリングバッファ２０２に格納する。すなわち、格納処理部２０４は、スレッド＃２における処理依頼のＡＰＩの処理結果をミラーリングバッファ２０２に格納して、更新差分を反映する（ステップＳ２１１）。
【0129】
その後、格納処理部２０４は、スレッド＃２に対するミラーリング用の送信データの受領応答をアクティブノード１０へ送信する（ステップＳ２１２）。
【0130】
アクティブノード１０の同期処理部１０７は、スレッド＃２に対する受領応答を受けて、スレッド＃２のデータ操作領域１０１に格納されたコミットログの情報を含むレコードをメモリテーブル１０３に格納して、更新差分を反映する（ステップＳ２１３）。
【0131】
その後、ＡＰＩ処理部１０５は、スレッド＃２における更新差分の反映完了の通知を同期処理部１０７から受ける。そして、ＡＰＩ処理部１０５は、正常終了応答をクライアントアプリケーション３０２に送信して、クライアントアプリケーション３０２との間の処理に復帰する（ステップＳ２１４）。
【0132】
一方、スレッド＃１において、同期処理部１０７は、データ操作領域１０１に存在する最後のＡＰＩの処理結果のコミットログ及び一時格納領域１０２に格納されたログのうち送信済みフラグがＯＦＦのログのそれぞれのミラーデータを作成する。この場合、同期処理部１０７は、全てのミラーデータの一時領域フラグをＯＦＦに設定する。その後、同期処理部１０７は、スレッド＃１において、作成したミラーデータを格納したミラーリング用の送信データをスタンバイノード２０へ送信して、ミラーリングを実行する（ステップＳ２１５）。
【0133】
スタンバイノード２０の格納処理部２０４は、送信データを取得して、全てのミラーデータの一時領域フラグがＯＦＦであることを確認する。そして、格納処理部２０４は、全てのミラーデータに含まれるＡＰＩの処理結果の情報をレコード及び一時格納領域２０１に格納されたログの情報を含むレコードをミラーリングバッファ２０２に格納して、更新差分を反映する（ステップＳ２１６）。
【0134】
その後、格納処理部２０４は、スレッド＃１に対するミラーリング用の送信データの受領応答をアクティブノード１０へ送信する（ステップＳ２１７）。
【0135】
アクティブノード１０の同期処理部１０７は、スレッド＃１に対する受領応答を受ける。そして、同期処理部１０７は、一時格納領域１０２に格納された各ログの情報を含む複数のレコードをメモリテーブル１０３に格納して、更新差分を反映する（ステップＳ２１８）。さらに、同期処理部１０７は、一時格納領域１０２に格納されたログを削除する。
【0136】
その後、ＡＰＩ処理部１０５は、スレッド＃１における更新差分の反映完了の通知を同期処理部１０７から受ける。そして、ＡＰＩ処理部１０５は、正常終了応答をクライアントアプリケーション３０１に送信して、クライアントアプリケーション３０１との間の処理に復帰する（ステップＳ２１９）。
【0137】
図１６は、一括処理依頼で処理中に参照があり且つ切り替えが発生した場合のクラスタシステムの動作を示すシーケンス図である。次に、図１６を参照して、一括処理依頼を処理中に別のクライアントアプリケーション３００から参照があり且つアクティブノード１０の切り替えが発生した場合のクラスタシステム１の動作を説明する。ここでは、クライアントアプリケーション３０１及び３０２が存在し、それぞれからの処理依頼を、アクティブノード１０がスレッド＃１及び＃２として処理する場合で説明する。
【0138】
クライアントアプリケーション３００は、アクティブノード１０に一括処理依頼を送信する（ステップＳ３０１）。
【0139】
アクティブノード１０のＡＰＩ処理部１０５は、一括処理依頼を通信部１０４から取得する。そして、ＡＰＩ処理部１０５は、スレッド＃１において、データ操作領域１０１を用いて括処理依頼に含まれる各ＡＰＩの処理を順番に行う（ステップＳ３０２）。
【0140】
スレッド＃１において１つのＡＰＩの処理が終了すると、一時格納処理部１０６は、一時格納領域１０２にデータ操作領域１０１のコミットログに含まれるＡＰＩの処理結果の情報をログとして格納する（ステップＳ３０３）。
【0141】
次に、ＡＰＩ処理部１０５は、スレッド＃１において、一括処理依頼に含まれる全てのＡＰＩの処理が完了したか否かを判定する（ステップＳ３０４）。処理していないＡＰＩが残っている場合（ステップＳ３０４：否定）、ＡＰＩ処理部１０５は、ステップＳ３０２へ戻る。ここでは一括処理依頼に含まれる全てのＡＰＩの処理が完了する前にアクティブノード１０がダウンするので、一括処理依頼に含まれる全てのＡＰＩの処理が完了する場合への分岐は発生しないので、その分岐方向への処理は進まない。
【0142】
一方、ＡＰＩ処理部１０５がスレッド＃１において一括処理依頼を処理中に、クライアントアプリケーション３０２が、参照依頼を含む処理依頼をアクティブノード１０に送信する（ステップＳ３０５）。
【0143】
アクティブノード１０のＡＰＩ処理部１０５は、処理依頼を通信部１０４から取得する。そして、ＡＰＩ処理部１０５は、スレッド＃２において、データ操作領域１０１を用いて、処理依頼に含まれるＡＰＩの処理を実行する（ステップＳ３０６）。その処理依頼の中の参照依頼により、ＡＰＩ処理部１０５は、一時格納領域１０２に格納されたＡＰＩの処理結果のログを参照する（ステップＳ３０７）。
【0144】
その後、スレッド＃２における処理依頼の処理が完了すると、ＡＰＩ処理部１０５は、参照したログの一時格納番号が最大送信番号の値よりも大きければ、参照したログの一時格納番号を最大送信番号とする。そして、ＡＰＩ処理部１０５は、最大送信番号の値以下の一時格納番号を有するログの送信指示及びスレッド＃２における処理依頼の処理完了を同期処理部１０７に通知する。同期処理部１０７は、通知を受けて、更新を含むコミットを実行する（ステップＳ３０８）。そして、同期処理部１０７は、ミラーリング用の送信データをスタンバイノード２０へ送信して、ミラーリングを実行する（ステップＳ３０９）。
【0145】
スタンバイノード２０の格納処理部２０４は、ミラーリング用の送信データに含まれるミラーデータのうち一時領域フラグがＯＮのミラーデータに含まれるＡＰＩの処理結果を一時格納領域２０１に格納する。すなわち、格納処理部２０４は、アクティブノード１０の一時格納領域１０２に格納された一括処理に含まれるＡＰＩの処理結果のログのうち参照されたログ以前のログを自装置の一時格納領域２０１に格納して、更新差分を反映する（ステップＳ３１０）。
【0146】
また、格納処理部２０４は、ミラーリング用の送信データに含まれるミラーデータのうち一時領域フラグがＯＦＦのミラーデータに含まれるＡＰＩの処理結果を含むレコードをミラーリングバッファ２０２に格納する。すなわち、格納処理部２０４は、スレッド＃２における処理依頼のＡＰＩの処理結果を含むレコードをミラーリングバッファ２０２に格納して、更新差分を反映する（ステップＳ３１１）。
【0147】
その後、格納処理部２０４は、スレッド＃２に対するミラーリング用の送信データの受領応答をアクティブノード１０へ送信する（ステップＳ３１２）。
【0148】
アクティブノード１０の同期処理部１０７は、スレッド＃２に対する受領応答を受ける。そして、同期処理部１０７は、スレッド＃２におけるデータ操作領域１０１に格納されたコミットログに含まれるＡＰＩの処理結果の情報を含むレコードをメモリテーブル１０３に格納して、更新差分を反映する（ステップＳ３１３）。
【0149】
その後、ＡＰＩ処理部１０５は、スレッド＃２における更新差分の反映完了の通知を同期処理部１０７から受ける。そして、ＡＰＩ処理部１０５は、正常終了応答をクライアントアプリケーション３０２に送信して、クライアントアプリケーション３０２との間の処理に復帰する（ステップＳ３１４）。
【0150】
その後、スレッド＃１における一括処理依頼を処理中に、アクティブノード１０がダウンし、アクティブノード１０の切り替えが発生して、スタンバイノード２０が新しいアクティブノード１０となる（ステップＳ３１５）。ただし、図１６では、図示の都合上そのままスタンバイノード２０として表している。以下では、スタンバイノード２０を新しいアクティブノード１０として説明する。
【0151】
新しいアクティブノード１０の一時格納処理部１０６は、切り替わりが発生すると、一時格納領域２０１へのポインタを作成して、メモリテーブル１０３の各レコードの一時格納領域へのポインタに登録する（ステップＳ３１６）。
【0152】
クライアントアプリケーション３０１は、一括処理依頼の再依頼を新しいアクティブノード１０へ送信して、再実行を依頼する（ステップＳ３１７）。
【0153】
新しいアクティブノード１０のＡＰＩ処理部１０５は、一括処理依頼の再依頼を受けて、一括処理依頼に含まれるＡＰＩの処理を順番に開始する。ＡＰＩ処理部１０５は、処理対象のＡＰＩの処理結果のログが一時格納領域１０２に存在するか否かを判定する（ステップＳ３１８）。処理対象のＡＰＩの処理結果のログが一時格納領域１０２に存在する場合（ステップＳ３１８：肯定）、ＡＰＩ処理部１０５は、ステップＳ３２０へ進む。
【0154】
これに対して、処理対象のＡＰＩの処理結果のログが一時格納領域１０２に存在しない場合（ステップＳ３１８：否定）、ＡＰＩ処理部１０５は、処理対象のＡＰＩの処理を実行する（ステップＳ３１９）。この場合、処理対象のＡＰＩが最後のＡＰＩでなければ、一時格納処理部１０６は、ＡＰＩの処理結果をログとして一時格納領域１０２に格納する。
【0155】
その後、ＡＰＩ処理部１０５は、一括処理依頼に含まれる全てのＡＰＩの処理が完了したか否かを判定する（ステップＳ３２０）。未処理のＡＰＩが残っている場合（ステップＳ３２０：否定）、ＡＰＩ処理部１０５は、ステップＳ３１８へ戻る。
【0156】
一方、一括処理依頼に含まれる全てのＡＰＩの処理が完了した場合（ステップＳ３２０：肯定）、同期処理部１０７は、一時格納領域１０２に格納されたログの情報を含むレコードをメモリテーブル１０３に格納して、更新差分を反映する（ステップＳ３２１）。さらに、同期処理部１０７は、一時格納領域１０２に格納されたログを削除する。
【0157】
その後、ＡＰＩ処理部１０５は、スレッド＃１における更新差分の反映完了の通知を同期処理部１０７から受ける。そして、ＡＰＩ処理部１０５は、正常終了応答をクライアントアプリケーション３０１に送信して、クライアントアプリケーション３０１との間の処理に復帰する（ステップＳ３２２）。
【0158】
【0159】
ＡＰＩ処理部１０５は、通信部１０４を介して、クライアントアプリケーション３００から送信された一括処理依頼を受信する（ステップＳ４０１）。
【0160】
次に、ＡＰＩ処理部１０５は、一括処理依頼に含まれるＡＰＩのうち未処理のＡＰＩの先頭のＡＰＩの処理を開始する（ステップＳ４０２）。
【0161】
次に、ＡＰＩ処理部１０５は、処理対象のＡＰＩの要求リストのインデックスに対応する一時格納番号が既に一時格納領域１０２に存在するか否かを判定する（ステップＳ４０３）。処理対象のＡＰＩの要求リストのインデックスに対応する一時格納番号が既に一時格納領域１０２に存在する場合（ステップＳ４０３：肯定）、ＡＰＩ処理部１０５は、ステップＳ４０２へ戻る。
【0162】
これに対して、処理対象のＡＰＩの要求リストのインデックスに対応する一時格納番号が一時格納領域１０２に存在しない場合（ステップＳ４０３：否定）、ＡＰＩ処理部１０５は、データ操作領域１０１を用いてＡＰＩを処理する。そして、ＡＰＩ処理部１０５は、ＡＰＩの処理結果をコミットログとしてデータ操作領域１０１に格納する（ステップＳ４０４）。
【0163】
そして、ＡＰＩ処理部１０５は、処理したＡＰＩが一括処理依頼に含まれるＡＰＩのうちの最後のＡＰＩか否かを判定する（ステップＳ４０５）。最後のＡＰＩでない場合（ステップＳ４０５：否定）、一時格納処理部１０６は、コミットログに含まれるＡＰＩの処理結果の情報をログとして一時格納領域１０２に格納して、データ操作領域１０１からコミットログを削除する（ステップＳ４０６）。
【0164】
さらに、一時格納処理部１０６は、格納した一時格納領域１０２のログへのメモリテーブル１０３のレコードからのポインタを作成してメモリテーブル１０３の一時格納領域へのポインタに登録する（ステップＳ４０７）。その後、ＡＰＩ処理部１０５は、ステップＳ４０２へ戻る。
【0165】
これに対して、処理したＡＰＩが一括処理依頼の最後のＡＰＩの場合（ステップＳ４０５：肯定）、同期処理部１０７は、最後のＡＰＩのコミットログ及び一時格納領域１０２の送信済みフラグがＯＦＦのログをスタンバイノード２０へ送信する。具体的には、同期処理部１０７は、それぞれのミラーデータを生成し、生成したミラーデータを含むミラーリング用の送信データをスタンバイノード２０へ送信する（ステップＳ４０８）。
【0166】
その後、受領応答を受信すると、同期処理部１０７は、最後のＡＰＩのコミットログ及び一時格納領域のログのそれぞれに含まれるＡＰＩの処理結果の情報を含む複数のレコードをメモリテーブル１０３に格納して、更新結果を反映する（ステップＳ４０９）。
【0167】
次に、同期処理部１０７は、メモリテーブル１０３の一時格納領域へのポインタを初期化する（ステップＳ４１０）。
【0168】
その後、ＡＰＩ処理部１０５は、通信部１０４を介して正常終了応答をクライアントアプリケーション３００へ送信する（ステップＳ４１１）。
【0169】
【0170】
ＡＰＩ処理部１０５は、通信部１０４を介してクライアントアプリケーション３００から送信された参照依頼を受信する（ステップＳ５０１）。
【0171】
次に、ＡＰＩ処理部１０５は、参照依頼で指定されたメモリテーブル１０３のレコードを参照する（ステップＳ５０２）。
【0172】
そして、ＡＰＩ処理部１０５は、参照したレコードの一時格納領域へのポインタが初期状態か否かを判定する（ステップＳ５０３）。
【0173】
参照したレコードの一時格納領域へのポインタが初期状態の場合（ステップＳ５０３：肯定）、ＡＰＩ処理部１０５は、メモリテーブル１０３のレコードデータを参照する（ステップＳ５０４）。その後、アクティブノード１０の処理は、ステップＳ５０８へ進む。
【0174】
これに対して、参照したレコードの一時格納領域へのポインタが初期状態でない場合（ステップＳ５０３：否定）、ＡＰＩ処理部１０５は、ポインタで示された一時格納領域１０２のログのレコードデータを参照する（ステップＳ５０５）。
【0175】
次に、ＡＰＩ処理部１０５は、参照したログの一時格納番号が、自己が保持する最大送信番号の値より大きいか否かを判定する（ステップＳ５０６）。一時格納番号が最大送信番号の値以下の場合（ステップＳ５０６：否定）、アクティブノード１０の処理は、ステップＳ５０８へ進む。
【0176】
これに対して、一時格納番号が最大送信番号の値より大きい場合（ステップＳ５０６：肯定）、ＡＰＩ処理部１０５は、最大送信番号の値を参照したログの一時格納番号に更新する（ステップＳ５０７）。
【0177】
その後、同期処理部１０７は、更新を含むコミットを実行する（ステップＳ５０８）。すなわち、一時格納領域１０２のログが参照されていない場合であれば、同期処理部１０７は、データ操作領域１０１に格納されたコミットログをスタンバイノード２０へ送信して、ミラーリングを実行する。また、一時格納領域１０２のログを参照した場合であれば、同期処理部１０７は、一時格納領域１０２に格納された最大送信番号以下の未送信ログ及びデータ操作領域１０１のコミットログをスタンバイノード２０へ送信して、ミラーリングを実行する。
【0178】
その後、ＡＰＩ処理部１０５は、通信部１０４を介して正常応答をクライアントアプリケーション３００へ送信する（ステップＳ５０９）。
【0179】
【0180】
格納処理部２０４は、データをアクティブノード１０から受信する（ステップＳ６０１）。
【0181】
次に、格納処理部２０４は、一時領域フラグがＯＮか否かを判定する（ステップＳ６０２）。
【0182】
一時領域フラグがＯＮの場合（ステップＳ６０２：肯定）、格納処理部２０４は、ＡＰＩの処理結果の情報を含むログを一時格納領域２０１に格納する（ステップＳ６０３）。
【0183】
これに対して、一時領域フラグがＯＦＦの場合（ステップＳ６０２：否定）、格納処理部２０４は、ＡＰＩの処理結果の情報を含むレコードをミラーリングバッファ２０２に格納する（ステップＳ６０４）。
【0184】
その後、格納処理部２０４は、ミラーリング用の送信データの受領応答をアクティブノード１０へ送信する（ステップＳ６０５）。
【0185】
【0186】
クライアントアプリケーション３００は、一括処理依頼をアクティブノード１０へ送信して処理を依頼する（ステップＳ７０１）。
【0187】
その後、クライアントアプリケーション３００は、アクティブノード１０の切り替えを検知したか否かを判定する（ステップＳ７０２）。アクティブノード１０の切り替えを検知しない場合（ステップＳ７０２：否定）、クライアントアプリケーション３００は、ステップＳ７０４へ進む。
【0188】
アクティブノード１０の切り替えを検知した場合（ステップＳ７０２：肯定）、クライアントアプリケーション３００は、一括処理依頼を新たなアクティブノード１０へ再送信して再依頼を行なう（ステップＳ７０３）。
【0189】
その後、クライアントアプリケーション３００は、送信した一括処理に対する応答をアクティブノード１０から受信する（ステップＳ７０４）。そして、クライアントアプリケーション３００は、アクティブノード１０との間の通信に復帰する。
【0190】
以上に説明したように、本実施例に係るクラスタシステムのアクティブノードは、一括処理依頼を処理する場合に、各ＡＰＩの処理完了毎に一時格納領域にログを格納する。これにより、別のクライアントアプリケーションが、一括処理全体の処理完了を待たずに処理済データを用いることができ、クライアントとの間の処理の高速化を図ることができる。また、アクティブノードは、一時格納領域のログが別のクライアントアプリケーションから参照された場合、そのログ及びそのログ以前のログをスタンバイノードに送信する。スタンバイノードは、受信したログを一時格納領域に格納する。これにより、別のクライアントアプリケーションにより参照された処理済データ以前の処理済データを、スタンバイノードが保持することになり、アクティブノードの切り替え後に、データの不整合を回避することができる。また、参照依頼を含む処理依頼のコミットのタイミングで、参照されたログを含む以前のログをスタンバイノードへ送信することで、一括処理依頼に含まれるＡＰＩの処理結果の順序を維持することができる。したがって、システムの信頼性を向上させることが可能となる。
【0191】
さらに、スタンバイノードは、アクティブノードに切り替わった際に、一括処理依頼の再依頼を受けると、すでに一時格納領域に処理結果が格納されたＡＰＩについては処理をスキップして、未処理のＡＰＩの処理を実行する。これにより、一括処理依頼の再実行において、二重処理を回避することができ、一括処理依頼の処理を効率化することができる。また、クライアントアプリケーションは、切り替え前のアクティブノードによる一括処理依頼の処理状態を気にすることなく、再実行を依頼することができる。
【0192】
【0193】
コンピュータ９０は、図２１に示すように、プロセッサ９０１、メモリ９０２、ＨＤＤ（Hard Disk Drive）９０３、画像信号処理部９０４、入力信号処理部９０５、ディスクドライブ９０６及び通信インタフェース９０７を有する。プロセッサ９０１、メモリ９０２、ＨＤＤ（Hard Disk Drive）９０３、画像信号処理部９０４、入力信号処理部９０５、ディスクドライブ９０６及び通信インタフェース９０７のそれぞれは、バスに接続され相互に通信することができる。
【0194】
画像信号処理部９０４は、ディスプレイ９１が接続される。画像信号処理部９０４は、プロセッサ９０１からの指示を受けて、ディスプレイ９１にメッセージや画像を表示させる。利用者は、ディスプレイ９１に表示されたメッセージや画像を確認することができる。
【0195】
入力信号処理部９０５は、キーボードやマウスといった入力デバイス９２が接続される。利用者は、入力デバイス９２を用いて命令を入力することができる。入力信号処理部９０５は、入力デバイス９２から入力された命令をプロセッサ９０１へ転送する。
【0196】
ディスクドライブ９０６は、記憶媒体９３に対してデータの読み書きを行なう装置である。例えば、ディスクドライブ９０６は、記憶媒体９３に格納されたプログラムを読み出してプロセッサ９０１に送信して実行させることができる。
【0197】
通信インタフェース９０７は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等のネットワーク９４に接続される。プロセッサ９０１は、通信インタフェース９０７を介してネットワーク９４に接続される他の装置と通信を行うことができる。例えば、通信インタフェース９０７は、アクティブノード１０と端末装置３０との間の通信やアクティブノード１０とスタンバイノード２０との間の通信に使用される。例えば、通信インタフェース９０７は、図３に例示した、通信部１０４の機能を実現する。
【0198】
ＨＤＤ９０３は、補助記憶装置である。コンピュータ９０がアクティブノード１０の場合、ＨＤＤ９０３は、一時格納領域１０２及びメモリテーブル１０３の機能を実現する。また、ＨＤＤ９０３は、図３に例示したＡＰＩ処理部１０５、一時格納処理部１０６及び同期処理部１０７の機能を実現するためのプログラムを含む各種プログラムを格納する。また、コンピュータ９０がスタンバイノード２０の場合、ＨＤＤ９０３は、一時格納領域２０１、ミラーリングバッファ２０２及びメモリテーブル２０３の機能を実現する。また、ＨＤＤ９０３は、図３に例示した格納処理部２０４の機能を実現するためのプログラムを含む各種プログラムを格納する。また、コンピュータ９０が端末装置３０の場合、ＨＤＤ９０３は、クライアントアプリケーション３００の機能を実現するためのプログラムを含む各種プログラムを格納する。
【0199】
メモリ９０２は、主記憶装置である。メモリ９０２は、例えば、ＤＲＡＭ（Dynamic Random Access Memory）を用いることができる。メモリ９０２は、コンピュータ９０がアクティブノード１０の場合、図３に例示したデータ操作領域１０１の機能を実現する。
【0200】
プロセッサ９０１は、ＨＤＤ９０３から各種プログラムを読み出して、メモリ９０２に展開して実行する。これにより、プロセッサ９０１は、コンピュータ９０がアクティブノード１０の場合、図３に例示したＡＰＩ処理部１０５、一時格納処理部１０６及び同期処理部１０７の機能を実現する。また、プロセッサ９０１は、コンピュータ９０がスタンバイノード２０の場合、格納処理部２０４の機能を実現する。また、プロセッサ９０１は、コンピュータ９０が端末装置３０の場合、クライアントアプリケーション３００の機能を実現する。
【0201】
なお、各部の機能を実現するプログラムは、ＨＤＤ９０３に記憶される場合に限らず、例えば着脱可能な記憶媒体９３に記憶され、ディスクドライブ９０６を介してプロセッサ９０１によって読み出されてもよい。あるいは、各部の機能を実現するプログラムモは、ネットワーク９４を介して接続された他のコンピュータに記憶されてもよい。そして、各部の機能を実現するプログラムは、他のコンピュータから、通信インタフェース９０７を介してプロセッサ９０１によって読み出されてもよい。
【符号の説明】
【0202】
１ クラスタシステム
１０ アクティブノード
２０ スタンバイノード
３０ 端末装置
４０ 受付サーバ
１０１ データ操作領域
１０２ 一時格納領域
１０３ メモリテーブル
１０４ 通信部
１０５ ＡＰＩ処理部
１０６ 一時格納処理部
１０７ 同期処理部
２０１ 一時格納領域
２０２ ミラーリングバッファ
２０３ メモリテーブル
２０４ 格納処理部
３００ クライアントアプリケーション
１０ アクティブノード
２０ スタンバイノード
３０ 端末装置
４０ 受付サーバ
１０１ データ操作領域
１０２ 一時格納領域
１０３ メモリテーブル
１０４ 通信部
１０５ ＡＰＩ処理部
１０６ 一時格納処理部
１０７ 同期処理部
２０１ 一時格納領域
２０２ ミラーリングバッファ
２０３ メモリテーブル
２０４ 格納処理部
３００ クライアントアプリケーション
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】