JP5642817B2 - 差分更新装置、差分更新システム、差分更新方法、差分更新プログラム及び差分更新サーバ - Google Patents

Description

本発明の実施形態は、差分更新装置、差分更新システム、差分更新方法、差分更新プログラム及び差分更新サーバに関する。

システムの性能を向上させるために、サーバ側で管理されるデータのキャッシュをクライアント側で保持する技術が用いられている。例えば、クライアントは、自装置で動作するアプリケーションで利用するファイルをサーバから取得した場合に、取得したファイルをキャッシュデータ（以下、キャッシュと略記）として自装置内のキャッシュメモリに格納する。これにより、クライアントは、サーバから取得済みのファイルを再び利用する場合に、キャッシュメモリから読み込むことで、サーバ−クライアント間の通信量を抑制する。

また、上記の技術では、ファイル自体のキャッシュのみならず、例えば、ファイルやファイルが属するディレクトリの名前、属性、更新日時、サイズ、物理的な格納場所を示す情報等のディレクトリ情報をキャッシュ（ディレクトリキャッシュ）として保持することも行われている。この技術は、例えば、サーバに対して複数のクライアントが接続される分散システム環境下でサーバ−クライアント間の通信量を抑制し、処理速度を向上させるために用いられている。

なお、分散システムでは、サーバ故障やネットワーク分断に耐えられる程度の高い可用性を備えることが求められている。このため、例えば、サーバ故障を自ら検知して他のリソースに故障等のイベント情報を通知するとともに、リソースの自動切替を行う技術が利用されている。また、イベント発生から送信完了までの間にハードウェアリソースに故障が発生すると、イベント情報が欠送し、システムの故障検知、及び切替えに失敗することになる。このため、切り替えが生じた際に欠送発生の可能性を通知し、各クライアント側で、欠送した情報を補完する技術も提案されている。

Mike Burrows,"The Chubby lock service for loosely‐coupled distributed systems",OSDI'06:Seventh Symposium on Operating System Design and Implementation, Seattle, WA,November,2006.［online］、［平成２５年１月２２日検索］、インターネット＜http://research.google.com/archive/chubby‐osdi06.pdf＞ Tushar Chandra et al. "Paxos Made Live‐An Engineering Perspective", PODC’07: Proceedings of the twenty-sixth annual ACM symposium on Principles of distributed computing, Portland, Oregon, USA, August, 2007.

しかしながら、上記の従来技術では、キャッシュの更新に要する通信負荷が大きいという課題があった。例えば、上記のディレクトリキャッシュにおいて、ディレクトリ情報の更新が行われると、各クライアントは、保持していた更新前のディレクトリ情報のキャッシュを一旦削除し、更新後のディレクトリ情報を再受信するので、通信負荷が大きかった。

ここで、サーバにおいて、あるディレクトリ配下に１００００個のファイルが管理され、クライアント側で１００００個のファイル名をキャッシュとして保持している場合を説明する。ここで、サーバ側に１個のファイルが追加されると、サーバは、ディレクトリ配下に１０００１個のファイルを管理することとなる。そして、各クライアントは、１００００個のファイル名を一旦削除し、ファイル追加後の１０００１個のファイル名を再受信する。すなわち、各クライアントは、ファイル追加前から保持していた１００００個のファイル名には変化が無いにもかかわらず、変化が無い１００００個のファイル名を含む１０００１個のファイル名を再受信されることとなるので、通信負荷が大きかった。

また、上記のディレクトリキャッシュが分散システムに適用されていた場合には、再受信する処理を、該当のディレクトリキャッシュを有する全てのクライアントが行うこととなるので、通信負荷が大きかった。なお、上記の課題は、ディレクトリキャッシュが更新される場合に限定されるものではなく、例えば、サーバから取得されたファイルのキャッシュが更新される場合にも同様に挙げられる課題である。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、キャッシュの更新に要する通信負荷を軽減することを目的とする。

実施形態に係る差分更新装置は、キャッシュ記憶部と、接続部と、受信部と、更新部とを備える。キャッシュ記憶部は、クライアントである差分更新装置の有する記憶部であって、複数のサーバのうちの一つのサーバであるマスタサーバに記憶されたデータのキャッシュを記憶する。接続部は、前記クライアントの有する接続部であって、前記マスタサーバに故障が発生し、前記故障したマスタサーバとの通信が途絶えた場合に、更新後のデータと更新前のデータとの間の差分を更新する旨の差分更新通知と、当該差分更新通知の送信を完了したか否かを示す情報であって、前記クライアントに送信された前記差分更新通知に対する応答を前記クライアントから受信したことを示す送信完了情報との同期処理が前記マスタサーバによって行われた前記複数のサーバのうち、当該マスタサーバ以外のレプリカサーバのなかから選択された新たなマスタサーバを問い合わせ、以降の同期処理を行う新たなマスタサーバと通信可能に接続する。受信部は、前記クライアントの有する受信部であって、前記マスタサーバに故障が発生した場合に、前記新たなマスタサーバから前記差分更新通知を受信し、前記マスタサーバに故障が発生していない場合に、該マスタサーバから前記差分更新通知を受信する。更新部は、前記クライアントの有する更新部であって、受信された差分更新通知を用いて、前記キャッシュを更新するとともに、前記マスタサーバ又は前記新たなマスタサーバに、前記差分更新通知に対する応答として信号を送信する。

本願の開示する技術の一つの態様によれば、キャッシュの更新に要する通信負荷を軽減することができるという効果を奏する。

図１は、第１の実施形態に係る死活監視システムの概要を説明するための図である。 図２は、第１の実施形態に係る死活監視システムの構成を示すブロック図である。 図３は、セッション情報一覧を示す図である。 図４は、ノード情報一覧を示す図である。 図５は、イベント一覧を示す図である。 図６は、セッション一覧を示す図である。 図７は、死活監視システムによる新マスタへの切替処理を説明する図である。 図８は、第１の実施形態に係る死活監視システムによる欠送防止処理の流れを説明する図である。 図９は、第１の実施形態に係る死活監視システムによる欠送防止処理の流れを説明する図である。 図１０は、第１の実施形態に係る死活監視システムによる欠送防止処理の流れを説明する図である。 図１１は、第１の実施形態に係る死活監視システムによる欠送防止処理の流れを説明する図である。 図１２は、第１の実施形態に係る死活監視システムによる欠送防止処理の流れを説明する図である。 図１３は、第１の実施形態に係る死活監視システムによる差分更新処理の流れを示すシーケンス図である。 図１４は、第１の実施形態に係るクライアントの定期通信開始処理の処理手順を説明するためのフローチャートである。 図１５は、第１の実施形態に係るクライアントの定期通信受信処理の処理手順を説明するためのフローチャートである。 図１６は、第１の実施形態に係るクライアントのイベント処理の処理手順を説明するためのフローチャートである。 図１７は、第１の実施形態に係るクライアントのディレクトリ情報取得要求発生時の処理手順を説明するためのフローチャートである。 図１８は、第１の実施形態に係るクライアントのノードの追加・削除要求発生時の処理手順を説明するためのフローチャートである。 図１９は、第１の実施形態に係る死活監視装置におけるイベント配信処理の処理手順を説明するためのフローチャートである。 図２０は、第１の実施形態に係る死活監視装置における差分更新処理の処理手順を説明するためのフローチャートである。 図２１は、第１の実施形態に係る死活監視システムの効果を説明するための図である。 図２２は、第２の実施形態に係る死活監視システムによる差分更新処理の流れを示すシーケンス図である。 図２３は、第３の実施形態に係るクライアントのノードの追加・削除要求発生時の処理手順を説明するためのフローチャートである。 図２４は、差分更新プログラムを実行するコンピュータを示す図である。

以下に添付図面を参照して、この発明に係る差分更新装置、差分更新システム、差分更新方法、差分更新プログラム及び差分更新サーバの実施形態を図面に基づいて説明する。なお、以下では、キャッシュデータ（以下、キャッシュと略記）の書き換え前後の差分を更新する差分更新処理を死活監視サービスの一部分として提供する死活監視システムについて説明するが、この実施形態により本発明が限定されるものではない。

［第１の実施形態］
以下、第１の実施形態では、第１の実施形態に係る死活監視システムの概要、死活監視システムの構成、処理の流れを順に説明し、最後に第１の実施形態による効果を説明する。

［死活監視システムの概要］
図１を用いて、第１の実施形態に係る死活監視システムの概要を説明する。図１は、第１の実施形態に係る死活監視システムの概要を説明するための図である。

第１の実施形態に係る死活監視システム１は、死活監視装置１０と、該死活監視装置１０に接続される複数のクライアント２０Ａ，２０Ｂとを有する。死活監視装置１０は、複数のサーバを有し、複数のサーバのうち、一つのサーバの役割をマスタ１０Ａとし、その他のサーバの役割をレプリカ１０Ｂ〜１０Ｅとする。なお、死活監視システム１の構成は図１の例に限定されるものではなく、例えば、死活監視システム１は、任意数のサーバと、任意数のクライアントを有して良い。また、クライアント２０Ａ，２０Ｂの各装置を区別無く総称する場合に、クライアント２０と記載する。

第１の実施形態において、死活監視システム１は、欠送防止処理を実現するとともに、マスタ１０Ａに記憶されたデータについてのディレクトリ情報が更新されると、該ディレクトリ情報のキャッシュデータであるディレクトリキャッシュを記憶するクライアント２０において、ディレクトリキャッシュの差分更新処理を行う。

ここで、イベント情報の欠送が発生することを防止する構成は、死活監視装置１０によって実現される。すなわち、死活監視装置１０は、サーバ故障ならびにネットワーク分断に耐えることができるシステム上でイベント情報を冗長化する。具体的には、死活監視装置１０は、マスタ１０Ａが管理するイベント情報をレプリケーションにより冗長化することで、レプリカ１０Ｂ〜１０Ｅでもマスタ１０Ａが管理するイベント情報を記憶させる。例えば、死活監視装置１０は、既存のＰａｘｏｓアルゴリズムやＱｕｏｒｕｍプロトコルによるレプリケーション技術によって、サーバ故障やネットワーク分断に耐えられる冗長化を行っている。

死活監視装置１０では、イベントが発生すると、マスタ１０Ａが複数のクライアント２０Ａ，２０Ｂに対してイベント情報を配送する。ここで、マスタ１０Ａに故障が発生した場合には、マスタをマスタ１０Ａからレプリカ１０Ｂに切替えて、新しいマスタであるレプリカ１０Ｂが複数のクライアント２０Ａ，２０Ｂと再接続し、送信を完了していないイベント情報を複数のクライアント２０Ａ，２０Ｂに対して送信する。

これにより、クライアント２０側での欠送イベント情報の補完が不要となるため、システム構成を複雑にすることがなくなり、また、マスタ故障時に新マスタからイベント情報を配送可能なため、イベント情報の欠送防止処理が実現される。

このような構成のもと、各クライアント２０は、マスタ１０Ａに記憶されたデータについてのディレクトリ情報が更新されると、該ディレクトリ情報の差分更新処理を行う旨の差分更新通知をマスタ１０Ａから受信し、受信した差分更新通知を用いてディレクトリキャッシュを更新する。

図１には、クライアント２０Ｂによって記憶されるディレクトリキャッシュが更新される場合を例示する。図１の例では、マスタ１０Ａ及びレプリカ１０Ｂ〜１０Ｅは、ディレクトリ名「ディレクトリＡ」のディレクトリ（以下、ディレクトリＡと略記）の配下にファイル名「Ｆｉｌｅ１〜３」のファイルを記憶している。また、クライアント２０Ｂは、ディレクトリＡ配下のファイル名のリストをディレクトリキャッシュとして既に取得し（ディレクトリ監視）、記憶している。すなわち、クライアント２０Ｂは、死活監視装置１０のディレクトリＡを監視する。

ここで、例えば、マスタ１０Ａは、クライアント２０ＡによってディレクトリＡ配下にファイル名「Ｆｉｌｅ４」のファイルが新規に追加されると、追加されたファイル名「Ｆｉｌｅ４」をリストに追加する旨の追加通知（差分更新通知）をクライアント２０Ｂへ送信する。そして、クライアント２０Ｂは、受信した追加通知を用いて、リストにファイル名「Ｆｉｌｅ４」を追加、すなわち、更新前後の差分に相当する情報を更新する（差分更新）。

また、例えば、マスタ１０Ａに故障が発生し、追加通知がクライアント２０へ送信されなかった場合には、未送信の追加通知は欠送防止処理によってクライアント２０Ｂへ送信される。具体的には、マスタがマスタ１０Ａからレプリカ１０Ｂに切替わり、新しいマスタであるレプリカ１０Ｂが、未送信の追加通知をイベント情報としてクライアント２０Ｂに対して送信することにより、差分更新が行われる。

これにより、マスタ１０Ａに故障が発生した場合にも、ディレクトリキャッシュの差分更新処理が実現されるので、ディレクトリキャッシュの更新に要する通信負荷を軽減することが可能となる。

なお、図１の例では、ファイルの追加に伴ってディレクトリキャッシュが更新される場合を説明したが、実施形態はこれに限定されるものではなく、例えば、ディレクトリ情報の更新に伴ってディレクトリキャッシュは更新される。具体的には、ファイルの追加や削除、或いはディレクトリの追加や削除によってディレクトリ情報が更新されることにより、該ディレクトリ情報のキャッシュは更新される。

また、図１の例では、ファイル名がディレクトリキャッシュとしてクライアント２０に記憶され、更新される場合を説明したが、実施形態はこれに限定されるものではない。例えば、クライアント２０は、マスタ１０Ａのディレクトリ配下に属するファイル及びディレクトリの名称、属性、更新日時、サイズ、物理的な格納場所を示す情報等のディレクトリ情報（ディレクトリエントリ）をディレクトリキャッシュとして記憶する。また、以下において、ファイル及びディレクトリを総称する場合に、「ノード」と記載する。

［死活監視システムの構成］
図２を用いて、図１に示した死活監視システム１の構成を説明する。図２は、第１の実施形態に係る死活監視システムの構成を示すブロック図である。図２に示すように、この死活監視システム１は、死活監視装置１０及びクライアント２０を備え、死活監視装置１０のマスタ１０Ａとクライアント２０とが接続されている。以下にこれらの各装置の構成を説明する。

死活監視装置１０は、複数のサーバのうちの一つのサーバであるマスタ１０Ａと、その他のサーバであるレプリカ１０Ｂ〜１０Ｅを有する。また、マスタ１０Ａ及びレプリカ１０Ｂ〜１０Ｅは、それぞれが独立したデータベース３０Ａ〜３０Ｅを保持している。

データベース３０Ａ〜３０Ｅは、例えば、クライアント２０上で動作するアプリケーションによって利用される各種情報を記憶する。具体的には、データベース３０Ａ〜３０Ｅは、所定のディレクトリ配下にアプリケーションによって利用される各種ファイルを記憶する。

また、例えば、データベース３０Ａ〜３０Ｅは、死活監視装置１０上で発生したイベントに関する情報であるイベント情報を記憶する。また、各データベース３０Ａ〜３０Ｅが記憶するイベント情報については、それぞれ同期しているため、同じ内容のイベント情報が記憶されているものとする。

マスタ１０Ａ及びレプリカ１０Ｂ〜１０Ｅは、更新部１１、生成部１２、イベント送信部１３、同期部１４、接続部１５、送信未完了イベント送信部１６及び記憶部１７を有する。なお、各サーバ（マスタ１０Ａ及びレプリカ１０Ｂ〜１０Ｅ）は、マスタとレプリカで役割が異なるが、構成については同様である。以下にこれらの各部の処理を説明する。また、以下の説明では、マスタ１０Ａがマスタの役割であり、マスタ１０Ａに故障が発生した後にレプリカ１０Ｂが新たなマスタとなる場合を例にして説明する。

記憶部１７は、各種処理に必要なデータ及びプログラムを格納する。例えば、マスタ１０Ａの記憶部１７は、セッションを管理するための情報であるセッション情報一覧と、ノードを管理するための情報であるノード情報一覧と、イベント情報を管理するための情報であるイベント一覧とを記憶する。なお、ノード情報一覧及びイベント一覧は、マスタ１０Ａ及びレプリカ１０Ｂ〜１０Ｅがそれぞれ保持するデータベース３０Ａ〜３０Ｅにおいても記憶される情報である。また、上記したデータベース３０Ａ〜３０Ｅは、セッションの一覧であるセッション一覧を記憶する。以下では、セッション情報一覧、ノード情報一覧、イベント一覧及びセッション一覧について、図３〜図６を用いてそれぞれ具体的に説明する。

例えば、マスタ１０Ａの記憶部１７は、図３に例示するように、セッション情報一覧として、セッションを一意に識別する「セッションＩＤ」と、各クライアント２０に関する情報である「クライアント情報」と、各クライアント２０が現在アクセスしているノードのノードＩＤを示す「アクセス中のノードＩＤ」と、クライアント２０に送信するイベント情報のイベントＩＤである「送信するイベントのエントリ」とを対応付けて記憶する。図３の例を挙げて説明すると、記憶部１７は、例えば、セッションＩＤ「１」と、クライアント情報としてＩＰアドレス「１０．０．０．１」と、アクセス中のノードＩＤ「Ｎｉｄ＝１」と、送信するイベントのエントリ「Ｅｉｄ＝１，２，５」とを対応付けて記憶する。つまり、記憶部１７は、セッションＩＤ「１」のセッションで接続されるＩＰアドレス「１０．０．０．１」のクライアント２０が、ノードＩＤ「Ｎｉｄ＝１」のディレクトリキャッシュを保持しており、イベントＩＤ「Ｅｉｄ＝１，２，５」のイベント情報をクライアント２０に送信することを記憶する。

また、例えば、マスタ１０Ａの記憶部１７は、図４に例示するように、ノード情報一覧として、ノードを一意に識別する「ノードＩＤ」と、ノードが属する親のノード（ディレクトリ）のノードＩＤを示す「親ノードＩＤ」と、ノードの種別を示す「ノード種別」と、ノードに現在アクセスしているセッションのセッションＩＤを示す「アクセス中のセッションＩＤ」とを対応付けて記憶する。図４の例を挙げて説明すると、記憶部１７は、例えば、ノードＩＤ「１」と、親ノードＩＤ「Ｐｉｄ＝０」と、ノード種別「ディレクトリ」と、アクセス中のセッションＩＤ「Ｓｉｄ＝１，３」とを対応付けて記憶する。なお、親ノードＩＤには、図４に示した例に限らず、ルートを示す情報が記憶されても良い。

また、例えば、マスタ１０Ａの記憶部１７は、図５に例示するように、イベント一覧として、イベントを一意に識別する「イベントＩＤ」と、イベントの発生元となるノードを示す「イベント発生元のノードＩＤ」と、イベントの種別を示す「イベント種別」と、イベントの発生元となるセッションのセッションＩＤを示す「イベント発生元のセッションＩＤ」とを対応付けて記憶する。図５の例を挙げて説明すると、記憶部１７は、例えば、イベントＩＤ「１」と、イベント発生元のノードＩＤ「Ｎｉｄ＝２」と、イベント種別「ファイル追加」と、イベント発生元のセッションＩＤ「Ｓｉｄ＝２」とを対応付けて記憶する。つまり、記憶部１７は、セッションＩＤ「Ｓｉｄ＝２」のセッションで接続されるクライアント２０からの要求によってノードＩＤ「Ｎｉｄ＝２」のファイルが追加されたことを、イベントＩＤ「１」のイベントとして記憶する。なお、図５の例では、ノードの追加又は削除がイベントとして登録される場合を例示したが、これに限定されるものではなく、例えば、ファイルの内容の更新や、ノードに対するアクセスの無効など、ノードに対して発生した各種イベントが登録されても良い。

また、データベース３０Ａ〜３０Ｅは、図６に例示するように、セッション一覧として、セッションを一意に識別する「セッションＩＤ」と、各クライアント２０に関する情報である「クライアント情報」と、各クライアント２０が現在アクセスしているノードのノードＩＤを示す「アクセス中のノードＩＤ」とを対応付けて記憶する。図６の例を挙げて説明すると、データベース３０Ａ〜３０Ｅは、例えば、セッションＩＤ「１」と、クライアント情報としてＩＰアドレス「１０．０．０．１」と、アクセス中のノードＩＤ「Ｎｉｄ＝１」とを対応付けて記憶する。

ここで、レプリカ１０Ｂ〜１０Ｅのデータベース３０Ｂ〜３０Ｅが記憶するノード情報一覧、イベント一覧及びセッション一覧は、マスタ１０Ａのデータベース３０Ａが記憶するノード情報一覧、イベント一覧及びセッション一覧の複製である。また、上記したように、レプリカ１０Ｂ〜１０Ｅのデータベース３０Ｂ〜３０Ｅは、セッション情報一覧を記憶していない。このため、レプリカ１０Ｂ〜１０Ｅのいずれかがマスタに切り替わった場合には、データベース３０Ｂ〜３０Ｅに記憶されたイベント一覧及びセッション一覧からセッション情報一覧を構築して、該セッション情報一覧を記憶部１７にセットする。

更新部１１は、死活監視装置１０によって管理される各種情報を更新する。具体的には、更新部１１は、データベース３０に記憶された各種情報を更新する旨の要求をクライアント２０から受信する。そして、更新部１１は、受信した要求に応じてデータベース３０に記憶された各種情報を更新する。より具体的には、更新部１１は、ノードの追加又は削除を行う旨の要求であるノードの追加・削除要求を、要求元のアプリケーションが動作するクライアント２０から受信する。

一例としては、マスタ１０Ａの更新部１１は、セッションＩＤ「２」のセッションで接続されるクライアントからノードＩＤ「２」のファイルを追加する旨の追加要求を受信した場合には、ノードＩＤ「２」のファイルをデータベース３０Ａに新規に追加する。また、他の例としては、マスタ１０Ａの更新部１１は、セッションＩＤ「３」のセッションで接続されるクライアントからノードＩＤ「６」のファイルを削除する旨の削除要求を受信した場合には、ノードＩＤ「６」のファイルをデータベース３０Ａから削除する。

生成部１２は、更新部１１によって更新された情報について、更新後の情報と、更新前の情報との差分を更新するための差分更新通知を生成する。具体的には、マスタ１０Ａの生成部１２は、データベース３０に記憶された各種情報が更新されると、差分更新通知を生成する。そして、生成部１２は、生成した差分更新通知をイベント情報としてイベント一覧に登録する。なお、ここで生成部１２によって登録されるイベントＩＤは、例えば、イベント一覧に登録される順にイベントＩＤを１増加させて採番したイベントＩＤが生成部１２によって選択され、登録される。

イベント送信部１３は、自サーバがマスタ１０Ａである場合に、自サーバが保持している記憶部１７がイベント一覧として記憶するイベント情報をクライアント２０に対して送信する。具体的には、イベント送信部１３は、定期的にクライアント２０に対して送信する死活監視情報にイベント情報を付加することで、イベント情報をクライアント２０に対して送信する。ここで、死活監視装置１０とクライアント２０との間で行う死活監視とは、死活監視装置１０及びクライアント２０の両計算機間の接続が保てていることの確認をするためのものである。また、イベント送信部１３は、イベント情報として、イベントを一意に識別する「イベントＩＤ」とイベントの種類を示す「イベントの種類」とを死活監視情報に付加してクライアント２０に送信する。

また、例えば、イベント送信部１３は、差分更新通知をイベント情報として送信する場合には、差分更新通知の通知先となる通知先クライアントの一覧を取得し、取得した通知先クライアントに対して差分更新通知を送信する。

なお、イベント送信部１３は、クライアント２０へ送信するイベント情報の順序を保つために、通信順序を保証する通信路を用いて、クライアント２０にイベント情報を送信する。例えば、イベント送信部１３は、ＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）を用いた通信路でイベント情報をクライアント２０に送信する。ただし、ＵＤＰを用いた通信路を適用する場合には、ＵＤＰ通信に通信順序を保証する機能を追加する必要がある。

同期部１４は、自サーバがマスタ１０Ａである場合に、マスタ１０Ａが保持するデータベース３０Ａが記憶するイベント情報をレプリカ１０Ｂ〜１０Ｅに通知してデータベース３０Ｂ〜３０Ｅに記憶させる。具体的には、同期部１４は、イベントが発生して自サーバが保持するデータベースにイベント情報を登録するたびに、該イベント情報をレプリカ１０Ｂ〜１０Ｅに通知してデータベース３０Ｂ〜３０Ｅに記憶させる。

また、同期部１４は、クライアント２０に対してイベント情報の送信を完了したか否かを示す情報を、レプリカ１０Ｂ〜１０Ｅに通知してレプリカ１０Ｂ〜１０Ｅのデータベース３０Ｂ〜３０Ｅにそれぞれ記憶させる。ここで、同期部１４は、イベント情報の送信を完了したか否かを示す情報として、クライアント２０に送信した最新のイベント情報のイベントＩＤである「最新送信完了イベントＩＤ」をレプリカ１０Ｂ〜１０Ｅに通知してレプリカ１０Ｂ〜１０Ｅのデータベース３０Ｂ〜３０Ｅにそれぞれ記憶させる。

接続部１５は、マスタ１０Ａに故障が発生した場合には、レプリカ１０Ｂ〜１０Ｅのなかから選択された新しいマスタであるレプリカ１０Ｂとクライアント２０とを通信可能に接続する。具体的には、接続部１５は、クライアント２０のクライアントライブラリ２１が送信したマスタの問い合わせを受け付け、かつ、自サーバが新しいマスタであるレプリカ１０Ｂである場合には、クライアント２０と通信可能に接続する。なお、新しいマスタの選択については、例えば、既存のＰａｘｏｓによるマスタの選定機能を利用して行う。

送信未完了イベント送信部１６は、新しいマスタであるレプリカ１０Ｂが保持するデータベース２０Ｂが記憶するイベント情報のうちクライアント２０に対して送信未完了であるイベント情報を、最新送信完了イベントＩＤを用いて特定し、該送信未完了であるイベント情報をクライアント２０に送信する。具体的には、送信未完了イベント送信部１６は、最新送信完了イベントＩＤのイベント情報より新しいイベントＩＤのイベント情報を送信未完了であるイベント情報として特定し、該イベント情報をクライアント２０に送信する。

また、クライアント２０は、クライアントライブラリ２１とアプリケーション２２とを有する。また、クライアントライブラリ２１は、セッション管理部２１ａと、キャッシュ更新部２１ｂと、キャッシュ記憶部２１ｃとを有しており、死活監視のため、定期的にマスタ１０Ａと通信を行う。

セッション管理部２１ａは、マスタ１０Ａから受信した死活監視情報にイベント情報が付加されている場合には、マスタ１０Ａが送信した最新のイベント情報のイベントＩＤである最新送信完了イベントＩＤを用いて、該イベント情報を二重に受信していないか確認する冗送確認処理を行う。なお、上記した最新送信完了イベントＩＤと死活監視装置１０が記憶する最新受信完了イベントＩＤとは、同種の情報であり、クライアント視点では、「最新受信完了イベントＩＤ」とし、死活監視装置視点では、「最新送信完了イベントＩＤ」としている。具体的には、セッション管理部２１ａは、最新受信完了イベントＩＤを保持し、受信したイベント情報のイベントＩＤが最新受信完了イベントＩＤよりも新しいイベント情報であれば、イベント情報をアプリケーション２２に通知する。

また、セッション管理部２１ａは、マスタ１０Ａが故障してフェイルオーバが起こると、接続先を新たなマスタであるレプリカ１０Ｂに変更する。ここで、フェイルオーバ中にクライアント２０が故障等により再接続を行わなかった場合について、図７を用いて説明する。図７は、死活監視システムによる新マスタへの切替処理を説明する図である。図７に例示するように、マスタ１０Ａに故障が発生してフェイルオーバでマスタが交代し、レプリカ１０Ｂが新マスタとなる（図７の（１）参照）。ここで、フェイルオーバ中にクライアント２０Ｂは、故障したため新マスタであるレプリカ１０Ｂと再接続を行わなかったものとし（図７の（２）参照）、クライアント２０Ａは、新マスタであるレプリカ１０Ｂと再接続を行ったものとする（図７の（３）参照）。

この場合には、新マスタであるレプリカ１０Ｂは、一定期間再接続のなかったセッション（この例では、故障したクライアント２０Ｂとのセッション）に関する情報を新マスタであるレプリカ１０Ｂの記憶部１７及びデータベース３０Ｂから削除する。つまり、セッションが切断した場合には、そのクライアントへのイベント情報の送信が不要になるため、セッションに関する情報を記憶部１７及びデータベース３０Ｂから削除する（図７の（４）参照）。

また、セッション管理部２１ａは、受信した死活監視情報に差分更新通知がイベント情報として付加されている場合には、該差分更新通知をキャッシュ更新部２１ｂへ通知する。例えば、セッション管理部２１ａは、受信した死活監視情報にイベントＩＤ「１」の差分更新通知が付加されていれば、差分更新通知をキャッシュ更新部２１ｂへ通知する。

キャッシュ更新部２１ｂは、マスタ１０Ａから通知された差分更新通知を用いて、ディレクトリキャッシュを差分更新する。一例としては、キャッシュ更新部２１ｂは、イベントＩＤ「１」の差分更新通知をセッション管理部２１ａから受け付ける。ここで、イベントＩＤ「１」の差分更新通知は、ノードＩＤ「２」のファイルが追加された旨の差分更新通知である。この結果、キャッシュ更新部２１ｂは、キャッシュ記憶部２１ｃに記憶されたディレクトリキャッシュにノードＩＤ「２」のファイル名を追加する。他の例としては、キャッシュ更新部２１ｂは、イベントＩＤ「４」の差分更新通知をセッション管理部２１ａから受け付ける。ここで、イベントＩＤ「４」の差分更新通知は、ノードＩＤ「６」のファイルが削除された旨の差分更新通知である。この結果、キャッシュ更新部２１ｂは、キャッシュ記憶部２１ｃに記憶されたディレクトリキャッシュからノードＩＤ「６」のファイル名を削除する。

キャッシュ記憶部２１ｃは、マスタ１０Ａによって管理される各種情報のキャッシュを記憶する。具体的には、キャッシュ記憶部２１ｃは、アプリケーション２２によって利用されるためにマスタ１０Ａから取得された各種情報のディレクトリキャッシュを記憶する。

［死活監視システムによる欠送防止処理］
図８〜図１２を用いて、第１の実施形態に係る死活監視システム１によるイベント情報の欠送防止処理の流れを説明する。なお、本実施形態では、ノードの更新によって発生した差分更新通知がイベント情報として各クライアント２０に通知される場合に、差分更新通知の欠送を防止するために行われる欠送防止処理について説明するが、実施形態はこれに限定されるものではない。例えば、イベント情報の欠送防止処理は、各クライアント２０上で動作するアプリケーション２２からの要求によって発生した各種イベントが、各クライアント２０に通知される場合にも実行され得る。

図８〜図１２は、第１の実施形態に係る死活監視システム１による欠送防止処理の流れを示すシーケンス図である。図８には、死活監視システムがイベント情報の欠送を防止するために行う正常時のイベント配送処理の流れを示す。図９〜図１２には、死活監視システムによるフェイルオーバ時のイベント配送処理の流れを示す。また、図９〜図１２は、それぞれフェイルオーバの発生時が異なる。具体的には、図９の例では、イベント発生前にフェイルオーバが発生した場合を示しており、図１０の例では、イベント情報送信前にフェイルオーバが発生した場合を示しており、図１１の例では、応答受信前にフェイルオーバが発生した場合を示しており、図１２の例では、応答受信後にフェイルオーバが発生した場合を示している。

まず、図８を用いて、死活監視システムがイベント情報の欠送を防止するために行う正常時のイベント配送処理の流れを説明する。図８に示すように、マスタ１０Ａは、イベントが発生すると（ステップＳ１０１）、イベント情報を記憶部１７及びデータベース３０Ａに登録し（ステップＳ１０２）、イベント情報の複製をレプリカ１０Ｂ、１０Ｃに通知する（ステップＳ１０３）。レプリカ１０Ｂ、１０Ｃは、イベント情報の複製を受信すると、データベース３０Ｂ、３０Ｃにイベント情報の複製を登録し、登録を行った旨の応答をマスタ１０Ａに送信する（ステップＳ１０４）。

そして、マスタ１０Ａは、定期的に通信している死活監視情報にイベント情報を付加して、クライアント２０のクライアントライブラリ２１にイベント情報を送信する（ステップＳ１０５）。クライアントライブラリ２１は、イベント情報の受信を完了すると、最新送信完了イベントＩＤを用いて、イベント情報を二重に受信していないか確認する冗送確認処理を行う（ステップＳ１０６）。そして、クライアントライブラリ２１は、二重に受信していないイベント情報である場合には、イベント情報をアプリケーション２２に通知する（ステップＳ１０７）。

そして、クライアントライブラリ２１は、最新受信完了イベントＩＤを含むイベント受信完了応答をマスタ１０Ａに送信する（ステップＳ１０８）。続いて、マスタ１０Ａは、イベント受信完了応答を受信すると、イベント情報の送信が完了した旨の登録と最新受信完了イベントＩＤの更新とを行う（ステップＳ１０９）。その後、マスタ１０Ａは、最新受信完了イベントＩＤの複製をレプリカ１０Ｂ、１０Ｃに通知する（ステップＳ１１０）。レプリカ１０Ｂ、１０Ｃは、最新受信完了イベントＩＤの複製を受信すると、データベース３０Ｂ、３０Ｃに最新受信完了イベントＩＤを登録し、登録を行った旨の応答をマスタ１０Ａに送信する（ステップＳ１１１）。そして、マスタ１０Ａは、レプリカ１０Ｂ、１０Ｃからの応答を受信し、イベント情報を受信すべき全クライアント２０から応答が揃った場合に、送信を完了したイベント情報を削除する（ステップＳ１１２）。その後、マスタ１０Ａは、自身のデータベース３０Ａからイベント情報を削除した場合には、レプリカ１０Ｂ、１０Ｃに対してイベント情報の削除を複製させる（ステップＳ１１３）。そして、レプリカ１０Ｂ、１０Ｃは、イベント情報の削除を複製してデータベース３０Ｂ、３０Ｃからイベント情報を削除すると、削除を行った旨の応答をマスタ１０Ａに送信する（ステップＳ１１４）。

続いて、図９を用いて、第１の実施形態に係る死活監視システムによるフェイルオーバ時のイベント配送処理の流れを説明する。図９に示すように、マスタ１０Ａは、イベントが発生すると（ステップＳ２０１）、イベント情報を記憶部１７及びデータベース３０Ａに登録し（ステップＳ２０２）、該イベント情報の複製をレプリカ１０Ｂ、１０Ｃに通知する（ステップＳ２０３）。

そして、マスタ１０Ａに故障が発生し（ステップＳ２０４）、フェイルオーバによりレプリカ１０Ｂを新マスタに切り替える。ここで、マスタ１０Ａが故障しているため、通信ができず、レプリカ１０Ｃからの応答が失敗する（ステップＳ２０５）。また、クライアントライブラリ２１は、マスタ１０Ａとの定期通信が途絶えたことからマスタ１０Ａとの接続切断を検出すると、レプリカのどれかにマスタの問い合わせを行い（ステップＳ２０６）、新マスタであるレプリカ１０Ｂから新しいマスタである旨の返信を受信する（ステップＳ２０８）。そして、クライアントライブラリ２１は、新マスタであるレプリカ１０Ｂとの再接続を要求し（ステップＳ２０９）、新マスタであるレプリカ１０Ｂとのセッションを確立してマスタと再接続する（ステップＳ２１０）。また、新マスタであるレプリカ１０Ｂは、クライアントライブラリ２１との再接続処理と並行して、データベース３０Ｂからイベント情報を読み出し、イベント情報を復元する処理を行う（ステップＳ２０７）。

そして、新マスタであるレプリカ１０Ｂは、イベント情報のうちクライアント２０に対して送信未完了であるイベント情報を、最新受信完了イベントＩＤを用いて特定し、該送信未完了であるイベント情報をクライアント２０に送信する（ステップＳ２１１）。クライアントライブラリ２１は、イベント情報の受信を完了すると、最新送信完了イベントＩＤを用いて、イベント情報を二重に受信していないか確認する冗送確認処理を行う（ステップＳ２１２）。そして、クライアントライブラリ２１は、二重に受信していないイベント情報である場合には、イベント情報をアプリケーション２２に通知する（ステップＳ２１３）。

そして、クライアントライブラリ２１は、最新受信完了イベントＩＤを含むイベント受信完了応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ２１４）。続いて、新マスタであるレプリカ１０Ｂは、イベント受信完了応答を受信すると、イベント情報の送信が完了した旨の登録と最新受信完了イベントＩＤの更新とを行う（ステップＳ２１５）。その後、新マスタであるレプリカ１０Ｂは、最新受信完了イベントＩＤの複製をレプリカ１０Ｃに通知する（ステップＳ２１６）。レプリカ１０Ｃは、最新受信完了イベントＩＤの複製を受信すると、データベース３０Ｃに最新受信完了イベントＩＤを登録し、登録を行った旨の応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ２１７）。そして、新マスタであるレプリカ１０Ｂは、レプリカ１０Ｃからの応答を受信し、イベント情報を受信すべき全クライアント２０から応答が揃った場合に、送信を完了したイベント情報を削除する（ステップＳ２１８）。その後、新マスタであるレプリカ１０Ｂは、自身のデータベース３０Ｂからイベント情報を削除した場合には、レプリカ１０Ｃに対してイベント情報の削除を複製させる（ステップＳ２１９）。そして、レプリカ１０Ｃは、イベント情報の削除を複製してデータベース３０Ｃからイベント情報を削除すると、削除を行った旨の応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ２２０）。

次に、図１０を用いて、第１の実施形態に係る死活監視システムによるフェイルオーバ時のイベント配送処理の流れを説明する。図１０に示すように、マスタ１０Ａは、イベントが発生すると（ステップＳ３０１）、イベント情報を記憶部１７及びデータベース３０Ａに登録し（ステップＳ３０２）、該イベント情報の複製をレプリカ１０Ｂ、１０Ｃに通知する（ステップＳ３０３）。レプリカ１０Ｂ、１０Ｃは、イベント情報の複製を受信すると、データベース３０Ｂ、３０Ｃにイベント情報の複製を登録し、登録を行った旨の応答をマスタ１０Ａに送信する（ステップＳ３０４）。

そして、マスタ１０Ａに故障が発生し（ステップＳ３０５）、イベント情報の送信が失敗すると（ステップＳ３０６）、フェイルオーバによりレプリカ１０Ｂを新マスタであるレプリカ１０Ｂに切り替える。続いて、新マスタであるレプリカ１０Ｂは、データベース３０Ｂからイベント情報を読み出し、イベント情報を復元する処理を行う（ステップＳ３０７）。ここで、クライアントライブラリ２１は、マスタ１０Ａとの定期通信が途絶えたことからマスタ１０Ａとの接続切断を検出すると、レプリカのどれかにマスタの問い合わせを行い（ステップＳ３０８）、新マスタであるレプリカ１０Ｂから新しいマスタである旨の返信を受信する（ステップＳ３０９）。そして、クライアントライブラリ２１は、新マスタであるレプリカ１０Ｂとの再接続を要求し（ステップＳ３１０）、新マスタであるレプリカ１０Ｂとのセッションを確立してマスタと再接続する（ステップＳ３１１）。

そして、新マスタであるレプリカ１０Ｂは、イベント情報のうちクライアント２０に対して送信未完了であるイベント情報を、最新受信完了イベントＩＤを用いて特定し、該送信未完了であるイベント情報をクライアント２０に送信する（ステップＳ３１２）。クライアントライブラリ２１は、イベント情報の受信を完了すると、最新送信完了イベントＩＤを用いて、イベント情報を二重に受信していないか確認する冗送確認処理を行う（ステップＳ３１３）。そして、クライアントライブラリ２１は、二重に受信していないイベント情報である場合には、イベント情報をアプリケーション２２に通知する（ステップＳ３１４）。

そして、クライアントライブラリ２１は、最新受信完了イベントＩＤを含むイベント受信完了応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ３１５）。続いて、新マスタであるレプリカ１０Ｂは、イベント受信完了応答を受信すると、イベント情報の送信が完了した旨の登録と最新受信完了イベントＩＤの更新とを行う（ステップＳ３１６）。その後、新マスタであるレプリカ１０Ｂは、最新受信完了イベントＩＤの複製をレプリカ１０Ｃに通知する（ステップＳ３１７）。レプリカ１０Ｃは、最新受信完了イベントＩＤの複製を受信すると、データベース３０Ｃに最新受信完了イベントＩＤを登録し、登録を行った旨の応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ３１８）。そして、新マスタであるレプリカ１０Ｂは、レプリカ１０Ｃからの応答を受信し、イベント情報を受信すべき全クライアント２０から応答が揃った場合に、送信を完了したイベント情報を削除する（ステップＳ３１９）。その後、新マスタであるレプリカ１０Ｂは、自身のデータベース３０Ｂからイベント情報を削除した場合には、レプリカ１０Ｃに対してイベント情報の削除を複製させる（ステップＳ３２０）。そして、レプリカ１０Ｃは、イベント情報の削除を複製してデータベース３０Ｃからイベント情報を削除すると、削除を行った旨の応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ３２１）。

次に、図１１を用いて、第１の実施形態に係る死活監視システムによるフェイルオーバ時のイベント配送処理の流れを説明する。図１１に示すように、マスタ１０Ａは、イベントが発生すると（ステップＳ４０１）、イベント情報を記憶部１７及びデータベース３０Ａに登録し（ステップＳ４０２）、該イベント情報の複製をレプリカ１０Ｂ、１０Ｃに通知する（ステップＳ４０３）。レプリカ１０Ｂ、１０Ｃは、イベント情報の複製を受信すると、データベース３０Ｂ、３０Ｃにイベント情報の複製を登録し、登録を行った旨の応答をマスタ１０Ａに送信する（ステップＳ４０４）。

そして、マスタ１０Ａは、定期的に通信している死活監視情報にイベント情報を付加して、クライアント２０のクライアントライブラリ２１にイベント情報を送信する（ステップＳ４０５）。クライアントライブラリ２１は、イベント情報の受信を完了すると、最新送信完了イベントＩＤを用いて、イベント情報を二重に受信していないか確認する冗送確認処理を行う（ステップＳ４０６）。そして、クライアントライブラリ２１は、二重に受信していないイベント情報である場合には、イベント情報をアプリケーション２２に通知する（ステップＳ４０７）。

そして、マスタ１０Ａに故障が発生し、フェイルオーバによりレプリカ１０Ｂを新マスタであるレプリカ１０Ｂに切り替える（ステップＳ４０８）。続いて、新マスタであるレプリカ１０Ｂは、データベース３０Ｂからイベント情報を読み出し、イベント情報を復元する処理を行う（ステップＳ４０９）。また、クライアントライブラリ２１は、マスタ１０Ａに故障が発生したため、イベント受信完了応答を旧マスタ１０Ａに送信することに失敗する（ステップＳ４１０）。ここで、クライアントライブラリ２１は、マスタ１０Ａとの定期通信が途絶えたことからマスタ１０Ａとの接続切断を検出すると、レプリカのどれかにマスタの問い合わせを行い（ステップＳ４１１）、新マスタであるレプリカ１０Ｂから新しいマスタである旨の返信を受信する（ステップＳ４１２）。そして、クライアントライブラリ２１は、新マスタであるレプリカ１０Ｂとの再接続を要求し（ステップＳ４１３）、新マスタであるレプリカ１０Ｂとのセッションを確立してマスタと再接続する（ステップＳ４１４）。

続いて、新マスタであるレプリカ１０Ｂは、イベント情報のうちクライアント２０に対して送信未完了であるイベント情報を、最新受信完了イベントＩＤを用いて特定し、該送信未完了であるイベント情報をクライアント２０に送信する（ステップＳ４１５）。そして、クライアントライブラリ２１は、イベント情報の受信を完了すると、最新送信完了イベントＩＤを用いて、イベント情報を二重に受信していないか確認する冗送確認処理を行う（ステップＳ４１６）。ここでは、クライアントライブラリ２１は、受信したイベント情報が、ステップＳ４０５において受信しているイベント情報であるため、イベント情報をアプリケーション２２に通知せずに、最新受信完了イベントＩＤを含むイベント受信完了応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ４１７）。

続いて、新マスタであるレプリカ１０Ｂは、イベント受信完了応答を受信すると、イベント情報の送信が完了した旨の登録と最新受信完了イベントＩＤの更新とを行う（ステップＳ４１８）。その後、新マスタであるレプリカ１０Ｂは、最新受信完了イベントＩＤの複製をレプリカ１０Ｃに通知する（ステップＳ４１９）。レプリカ１０Ｃは、最新受信完了イベントＩＤの複製を受信すると、データベース３０Ｃに最新受信完了イベントＩＤを登録し、登録を行った旨の応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ４２０）。そして、新マスタであるレプリカ１０Ｂは、レプリカ１０Ｃからの応答を受信し、イベント情報を受信すべき全クライアント２０から応答が揃った場合に、送信を完了したイベント情報を削除する（ステップＳ４２１）。その後、新マスタであるレプリカ１０Ｂは、自身のデータベース３０Ｂからイベント情報を削除した場合には、レプリカ１０Ｃに対してイベント情報の削除を複製させる（ステップＳ４２２）。そして、レプリカ１０Ｃは、イベント情報の削除を複製してデータベース３０Ｃからイベント情報を削除すると、削除を行った旨の応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ４２３）。

次に、図１２を用いて、第１の実施形態に係る死活監視システムによるフェイルオーバ時のイベント配送処理の流れを説明する。図１２に示すように、マスタ１０Ａは、イベントが発生すると（ステップＳ５０１）、イベント情報を記憶部１７及びデータベース３０Ａに登録し（ステップＳ５０２）、該イベント情報の複製をレプリカ１０Ｂ、１０Ｃに通知する（ステップＳ５０３）。レプリカ１０Ｂ、１０Ｃは、イベント情報の複製を受信すると、データベース３０Ｂ、３０Ｃにイベント情報の複製を登録し、登録を行った旨の応答をマスタ１０Ａに送信する（ステップＳ５０４）。

そして、マスタ１０Ａは、定期的に通信している死活監視情報にイベント情報を付加して、クライアント２０のクライアントライブラリ２１にイベント情報を送信する（ステップＳ５０５）。クライアントライブラリ２１は、イベント情報の受信を完了すると、最新送信完了イベントＩＤを用いて、イベント情報を二重に受信していないか確認する冗送確認処理を行う（ステップＳ５０６）。そして、クライアントライブラリ２１は、二重に受信していないイベント情報である場合には、イベント情報をアプリケーション２２に通知する（ステップＳ５０７）。

そして、クライアントライブラリ２１は、最新受信完了イベントＩＤを含むイベント受信完了応答をマスタ１０Ａに送信する（ステップＳ５０８）。ここで、マスタ１０Ａに故障が発生し、フェイルオーバによりレプリカ１０Ｂを新マスタであるレプリカ１０Ｂに切り替える（ステップＳ５０９）。続いて、新マスタであるレプリカ１０Ｂは、データベース３０Ｂからイベント情報を読み出し、イベント情報を復元する処理を行う（ステップＳ５１０）。ここで、クライアントライブラリ２１は、マスタ１０Ａとの定期通信が途絶えたことからマスタ１０Ａとの接続切断を検出すると、レプリカのどれかにマスタの問い合わせを行い（ステップＳ５１１）、新マスタであるレプリカ１０Ｂから新しいマスタである旨の返信を受信する（ステップＳ５１２）。そして、クライアントライブラリ２１は、新マスタであるレプリカ１０Ｂとの再接続を要求し（ステップＳ５１３）、新マスタであるレプリカ１０Ｂとのセッションを確立してマスタと再接続する（ステップＳ５１４）。

続いて、新マスタであるレプリカ１０Ｂは、イベント情報のうちクライアント２０に対して送信未完了であるイベント情報を、最新受信完了イベントＩＤを用いて特定し、該送信未完了であるイベント情報をクライアント２０に送信する（ステップＳ５１５）。そして、クライアントライブラリ２１は、イベント情報の受信を完了すると、最新送信完了イベントＩＤを用いて、イベント情報を二重に受信していないか確認する冗送確認処理を行う（ステップＳ５１６）。ここでは、クライアントライブラリ２１は、受信したイベント情報が、ステップＳ５０５において受信しているイベント情報であるため、イベント情報をアプリケーション２２に通知せずに、最新受信完了イベントＩＤを含むイベント受信完了応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ５１７）。

続いて、新マスタであるレプリカ１０Ｂは、イベント受信完了応答を受信すると、イベント情報の送信が完了した旨の登録と最新受信完了イベントＩＤの更新とを行う（ステップＳ５１８）。その後、新マスタであるレプリカ１０Ｂは、最新受信完了イベントＩＤの複製をレプリカ１０Ｃに通知する（ステップＳ５１９）。レプリカ１０Ｃは、最新受信完了イベントＩＤの複製を受信すると、データベース３０Ｃに最新受信完了イベントＩＤを登録し、登録を行った旨の応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ５２０）。そして、新マスタであるレプリカ１０Ｂは、レプリカ１０Ｃからの応答を受信し、イベント情報を受信すべき全クライアント２０から応答が揃った場合に、送信を完了したイベント情報を削除する（ステップＳ５２１）。その後、新マスタであるレプリカ１０Ｂは、自身のデータベース３０Ｂからイベント情報を削除した場合には、レプリカ１０Ｃに対してイベント情報の削除を複製させる（ステップＳ５２２）。そして、レプリカ１０Ｃは、イベント情報の削除を複製してデータベース３０Ｃからイベント情報を削除すると、削除を行った旨の応答を新マスタであるレプリカ１０Ｂに送信する（ステップＳ５２３）。

［死活監視システムによる差分更新処理］
図１３を用いて、第１の実施形態に係る死活監視システム１による差分更新処理の流れを説明する。図１３は、第１の実施形態に係る死活監視システム１による差分更新処理の流れを示すシーケンス図である。図１３には、クライアント２０Ｂがマスタ１０Ａに記憶されたディレクトリ情報「Ｆｉｌｅ１，Ｄｉｒ２」のディレクトリキャッシュを取得し、クライアント２０Ａによるファイル名「Ｆｉｌｅ３」のファイルの追加に応じてディレクトリキャッシュを更新する場合を例示する。

図１３に示すように、クライアント２０Ｂは、アプリケーション２２からディレクトリ情報を取得するためのディレクトリ情報取得要求が発生すると（ステップＳ６０１）、マスタ１０Ａへ該ディレクトリ情報取得要求を送信する（ステップＳ６０２）。クライアント２０Ｂは、送信したディレクトリ情報取得要求に対応するディレクトリ情報のリストをマスタ１０Ａから受信すると（ステップＳ６０３）、該リストをキャッシュ記憶部２１ｃに格納する（ステップＳ６０４）。この結果、クライアント２０Ｂは、ディレクトリ情報「Ｆｉｌｅ１，Ｄｉｒ２」のディレクトリキャッシュを取得する。

これ以降、クライアント２０Ｂは、アプリケーション２２からディレクトリ情報取得要求が発生するごとに（ステップＳ６０５）、取得済みのディレクトリキャッシュを読み込んで（ステップＳ６０６）、これを利用する。

ここで、クライアント２０Ａが新規にファイル名「Ｆｉｌｅ３」のファイルを追加する要求をマスタ１０Ａに対して送信すると（ステップＳ６０７）、マスタ１０Ａは、ファイルを作成する（ステップＳ６０８）。そして、マスタ１０Ａは、ファイル名「Ｆｉｌｅ３」のファイルを作成すると、ファイルの作成完了をクライアント２０Ａへ通知する（ステップＳ６０９）。

マスタ１０Ａは、ファイル名「Ｆｉｌｅ３」のファイルを新規に追加すると、ファイル名「Ｆｉｌｅ３」を追加する旨の差分更新通知をイベントとして発生させる。そして、マスタ１０Ａは、ファイル名「Ｆｉｌｅ３」を追加する旨の差分更新通知を、ディレクトリキャッシュを保持するクライアント２０Ｂに送信する（ステップＳ６１０）。この結果、クライアント２０Ｂは、ディレクトリキャッシュのリストを更新し（ステップＳ６１１）、ファイル名「Ｆｉｌｅ３」のディレクトリ情報をリストに追加する。そして、クライアント２０Ｂは、更新完了通知をマスタ１０Ａへ送信する（ステップＳ６１２）。

これ以降、クライアント２０Ｂは、アプリケーション２２からディレクトリ情報取得要求が発生するごとに（ステップＳ６１３）、更新済みのディレクトリキャッシュを読み込んで（ステップＳ６１４）、これを利用する。

なお、マスタ１０Ａは、ファイルが更新されたことを契機として、差分更新通知をイベントとして発生させた後に、図８のステップＳ１０１以降の処理も実行する。これにより、差分更新通知が欠送されることを防止する。すなわち、差分更新通知が発生した後に、マスタ１０Ａにおいて故障が発生した場合には、図９〜図１２のいずれかの処理によって差分更新通知が通知先クライアント２０へ送信されることとなる。このため、マスタ１０Ａは、差分更新通知を欠送させることなく通知先クライアント２０に送信することができる。

また、図１３では、ノードの追加や削除を行うクライアント２０と、ディレクトリキャッシュを保持するクライアント２０とが異なる場合を例示したが、これらのクライアントが同一の場合にも同様の処理によって差分更新処理が行われる。例えば、図１３において、クライアント２０Ａがディレクトリキャッシュを保持していれば、マスタ１０Ａは、ファイル名「Ｆｉｌｅ３」を追加する旨の差分更新通知を、クライアント２０Ａにも送信する（ステップＳ６１０）。この結果、クライアント２０Ａは、ディレクトリキャッシュのリストを更新し（ステップＳ６１１）、ファイル名「Ｆｉｌｅ３」のディレクトリ情報をリストに追加する。そして、クライアント２０Ａは、更新完了通知をマスタ１０Ａへ送信する（ステップＳ６１２）。

ここで、図１３及び図３〜図５を用いて、ファイルが追加される場合の差分更新処理と、ファイルが削除される場合の差分更新処理とをそれぞれ詳細に説明する。なお、ここでは、図１３に例示のクライアント２０Ａは、マスタ１０ＡとセッションＩＤ「Ｓｉｄ＝２」で接続されており、クライアント２０Ｂは、マスタ１０ＡとセッションＩＤ「Ｓｉｄ＝１」で接続されている。また、マスタ１０Ａは、ノードＩＤ「Ｎｉｄ＝１」のディレクトリ配下に、ノードＩＤ「Ｎｉｄ＝５」のファイル（図１３のファイル名「Ｆｉｌｅ１」）と、ノードＩＤ「Ｎｉｄ＝３」のディレクトリ（図１３のディレクトリ名「Ｄｉｒ２」）とをそれぞれ記憶する。また、クライアント２０Ｂは、ステップＳ６０２の処理において、図４に例示のノードＩＤ「Ｎｉｄ＝１」のディレクトリのディレクトリ情報を取得済みであるものとする。

まず、ファイルが追加される場合の差分更新処理について説明する。ステップＳ６０７において、例えば、クライアント２０Ａは、ノードＩＤ「Ｎｉｄ＝１」のディレクトリ配下にファイル名「Ｆｉｌｅ３」のファイルを追加する要求をマスタ１０Ａに対して送信する。マスタ１０Ａは、ファイル名「Ｆｉｌｅ３」のファイルを追加する要求を受信すると、ファイル名「Ｆｉｌｅ３」のファイルを作成する（ステップＳ６０８）。また、マスタ１０Ａは、ファイル名「Ｆｉｌｅ３」のファイルを作成するとき、作成されるファイルのメタデータとして、図３〜図５に例示の各種一覧の更新を行う。

具体的には、マスタ１０Ａの更新部１１は、ファイル名「Ｆｉｌｅ３」のファイルが作成されると、作成されたファイルを識別するためのノードＩＤを割り当て、ノード情報一覧に登録する。図４に示す例では、更新部１１は、ノードＩＤ「２」、親ノードＩＤ「Ｐｉｄ＝１」、ノード種別「ファイル」及びアクセス中のセッションＩＤ「Ｓｉｄ＝２」が対応付けられたレコードをノード情報一覧に追加する。

また、マスタ１０Ａの生成部１２は、ファイル名「Ｆｉｌｅ３」のファイルが作成されると、ファイルが作成されたことを通知するためのイベント情報（差分更新通知）を生成し、イベント一覧に登録する。図５に示す例では、生成部１２は、イベント発生元のノードＩＤ「Ｎｉｄ＝２」と、イベント種別「ファイル追加」と、イベント発生元のセッションＩＤ「Ｓｉｄ＝２」とを対応付けてイベントＩＤ「１」のイベント情報としてイベント一覧に登録する。

また、マスタ１０Ａのイベント送信部１３は、ファイル名「Ｆｉｌｅ３」のファイルが作成されると、イベントＩＤ「１」の差分更新通知の通知先を特定し、セッション情報一覧に登録する。図３に示す例では、イベント送信部１３は、ノード情報一覧を参照し、ファイル名「Ｆｉｌｅ３」のファイルが作成されるディレクトリのノードＩＤ「Ｎｉｄ＝１」に対応するアクセス中のセッションＩＤ「Ｓｉｄ＝１，３」を特定する。そして、イベント送信部１３は、セッション情報一覧を参照し、特定した各セッションＩＤ「Ｓｉｄ＝１，３」に対応する「送信するイベントのエントリ」に「Ｅｉｄ＝１」をそれぞれ追加する。

このように、マスタ１０Ａは、ファイル名「Ｆｉｌｅ３」のファイルの作成に伴って、作成されたファイルのメタデータを図３〜図５に例示の各種一覧に登録する。その後、イベント送信部１３は、ファイルの作成完了をクライアント２０Ａへ通知する（ステップＳ６０９）。

そして、イベント送信部１３は、各クライアント２０に対して死活監視情報を定期的に送信する際に、セッション情報一覧を参照する。そして、イベント送信部１３は、「送信するイベントのエントリ」にあるイベント情報（差分更新通知）を、該当するセッションＩＤで接続されたクライアント２０に対して送信する。ここで、図３を用いて、セッションＩＤ「１」で接続されたクライアント２０（図１３のクライアント２０Ｂ）に定期的な死活監視情報を送信する場合を説明する。この場合、イベント送信部１３は、図３に例示のセッション情報一覧を参照し、セッションＩＤ「１」に送信するイベントのエントリとして「Ｅｉｄ＝１，２，５」を特定する。そして、イベント送信部１３は、イベントＩＤ「１，２，５」の各イベント情報をイベント一覧から取得する。そして、イベント送信部１３は、取得した各イベント情報を死活監視情報に付加して送信する。この結果、ファイル名「Ｆｉｌｅ３」のファイルが作成されたことを通知するためのイベントＩＤ「１」のイベント情報（差分更新通知）がセッションＩＤ「１」で接続されたクライアント通知される（ステップＳ６１０）。このように、マスタ１０Ａは、ファイルの追加に応じて差分更新処理を実行する。

次に、ファイルが削除される場合の差分更新処理について説明する。ステップＳ６０７に相当する処理として、例えば、クライアント２０Ａは、ノードＩＤ「Ｎｉｄ＝３」のディレクトリ配下にあるノードＩＤ「Ｎｉｄ＝６」のファイルを削除する要求をマスタ１０Ａに対して送信する。マスタ１０Ａは、ノードＩＤ「Ｎｉｄ＝６」のファイルを削除する要求を受信すると、ノードＩＤ「Ｎｉｄ＝６」のファイルを削除する（ステップＳ６０８に相当）。また、マスタ１０Ａは、ノードＩＤ「Ｎｉｄ＝６」のファイルを削除するとき、削除されるファイルのメタデータとして、図３〜図５に例示の各種一覧の更新を行う。

具体的には、マスタ１０Ａの更新部１１は、ノードＩＤ「Ｎｉｄ＝６」のファイルが削除されると、削除されたファイルのノードＩＤに対応するレコードを、ノード情報一覧から削除する。図４に示す例では、更新部１１は、ノードＩＤ「６」、親ノードＩＤ「Ｐｉｄ＝３」、ノード種別「ファイル」及びアクセス中のセッションＩＤ「なし」が対応付けられたレコードをノード情報一覧から削除する。なお、ここでは、説明の便宜上、削除されたファイルにアクセス中のセッションＩＤが無い場合を例示したが、削除されたノードにアクセス中のセッションＩＤがある場合も考えられる。このような場合には、マスタ１０Ａは、セッションＩＤで接続されたクライアント２０に対してアクセスが無効になる旨を通知する処理を別途行っても良い。

また、マスタ１０Ａの生成部１２は、ノードＩＤ「Ｎｉｄ＝６」のファイルが削除されると、ファイルが削除されたことを通知するためのイベント情報（差分更新通知）を生成し、イベント一覧に登録する。図５に示す例では、生成部１２は、イベント発生元のノードＩＤ「Ｎｉｄ＝６」と、イベント種別「ファイル削除」と、イベント発生元のセッションＩＤ「Ｓｉｄ＝３」とを対応付けてイベントＩＤ「４」のイベント情報としてイベント一覧に登録する。

また、マスタ１０Ａのイベント送信部１３は、ノードＩＤ「Ｎｉｄ＝６」のファイルが削除されると、イベントＩＤ「４」の差分更新通知の通知先を特定し、セッション情報一覧に登録する。図３に示す例では、イベント送信部１３は、ノード情報一覧を参照し、ノードＩＤ「Ｎｉｄ＝６」のファイルが属するディレクトリのノードＩＤ「Ｎｉｄ＝３」に対応するアクセス中のセッションＩＤ「Ｓｉｄ＝４」を特定する。そして、イベント送信部１３は、セッション情報一覧を参照し、特定したセッションＩＤ「Ｓｉｄ＝４」に対応する「送信するイベントのエントリ」に「Ｅｉｄ＝４」を追加する。

このように、マスタ１０Ａは、ノードＩＤ「Ｎｉｄ＝６」のファイルの削除に伴って、削除されたファイルのメタデータを図３〜図５に例示の各種一覧に登録する。その後、イベント送信部１３は、ファイルの削除完了をクライアント２０Ａへ通知する（ステップＳ６０９に相当）。

そして、イベント送信部１３は、各クライアント２０に対して死活監視情報を定期的に送信する際に、セッション情報一覧を参照する。そして、イベント送信部１３は、「送信するイベントのエントリ」にあるイベント情報（差分更新通知）を、該当するセッションＩＤで接続されたクライアント２０に対して送信する。ここで、図３を用いて、セッションＩＤ「４」で接続されたクライアント２０に定期的な死活監視情報を送信する場合を説明する。この場合、イベント送信部１３は、図３に例示のセッション情報一覧を参照し、セッションＩＤ「４」に送信するイベントのエントリとして「Ｅｉｄ＝３，４，７」を特定する。そして、イベント送信部１３は、イベントＩＤ「３，４，７」の各イベント情報をイベント一覧から取得する。そして、イベント送信部１３は、取得した各イベント情報を死活監視情報に付加して送信する。この結果、ノードＩＤ「Ｎｉｄ＝６」のファイルが削除されたことを通知するためのイベントＩＤ「４」のイベント情報（差分更新通知）がセッションＩＤ「４」で接続されたクライアント通知される（ステップＳ６１０に相当）。このように、マスタ１０Ａは、ファイルの削除に応じて差分更新処理を実行する。

［クライアントによる処理］
次に、図１４〜図１８を用いて、第１の実施形態に係るクライアント２０による処理を説明する。図１４は、第１の実施形態に係るクライアントの定期通信開始処理の処理手順を説明するためのフローチャートである。図１５は、第１の実施形態に係るクライアントの定期通信受信処理の処理手順を説明するためのフローチャートである。図１６は、第１の実施形態に係るクライアントのイベント処理の処理手順を説明するためのフローチャートである。図１７は、第１の実施形態に係るクライアントのディレクトリ情報取得要求発生時の処理手順を説明するためのフローチャートである。図１８は、第１の実施形態に係るクライアントのノードの追加・削除要求発生時の処理手順を説明するためのフローチャートである。

まず、図１４を用いてクライアントの定期通信開始処理の処理手順を説明する。図１４に示すように、クライアント２０は、全てのサーバ１０Ａ〜１０Ｅへ接続要求を行う（ステップＳ７０１）。そして、クライアント２０は、マスタ１０Ａの接続先を受信すると（ステップＳ７０２）、マスタ１０Ａへ受信完了応答を送信する（ステップＳ７０３）。

続いて、クライアント２０は、死活監視タイマをセットし（ステップＳ７０４）、定期通信受信処理（後に図１３を用いて詳述）を行って（ステップＳ７０５）、処理を終了する。

次に、図１５を用いてクライアントの定期通信受信処理の処理手順を説明する。図１５に示すように、クライアント２０は、死活監視タイムアウト前に受信したか判定する（ステップＳ８０１）。この結果、クライアント２０は、死活監視タイムアウト前に死活監視情報を受信した場合には（ステップＳ８０１肯定）、イベント処理（後に図１６を用いて詳述）を行って（ステップＳ８０２）、マスタ１０Ａへ受信完了応答を送信し（ステップＳ８０３）、死活監視タイマをリセットした後、再度セットして（ステップＳ８０４）、ステップＳ８０１に戻る。

また、ステップＳ８０１において、クライアント２０は、死活監視タイムアウト前に死活監視情報を受信しなかった場合には（ステップＳ８０１否定）、処理を終了する。

次に、図１６を用いてクライアントのイベント処理の処理手順を説明する。図１６に示すように、クライアント２０は、イベント情報を受信したか否か、すなわち、死活監視情報にイベント情報が付加されているか否かを判定する（ステップＳ９０１）。この結果、クライアント２０は、イベント情報を受信していない場合には（ステップＳ９０１否定）、処理を終了する。一方、クライアント２０は、イベント情報を受信した場合には（ステップＳ９０１肯定）、受信したイベント情報が以前に受信していないイベント情報であるか否かを判定する（ステップＳ９０２）。

この結果、クライアント２０は、以前に受信していないイベント情報ではない、すなわち、以前に受信済みのイベント情報である場合には（ステップＳ９０２否定）、処理を終了する。一方、クライアント２０は、以前に受信していないイベント情報である場合には（ステップＳ９０２肯定）、受信したイベントが差分更新通知であるか否かを判定する（ステップＳ９０３）。

この結果、クライアント２０は、差分更新通知である場合には（ステップＳ９０３肯定）、ディレクトリキャッシュを差分更新し（ステップＳ９０４）、ステップＳ９０５の処理へ移行する。一方、クライアント２０は、差分更新通知でない場合には（ステップＳ９０３否定）、ステップＳ９０４の処理を実行することなくステップＳ９０５の処理へ移行する。

続いて、クライアント２０は、受信したイベント情報がアプリケーションに通知するイベント情報であるか否かを判定する（ステップＳ９０５）。この結果、クライアント２０は、アプリケーションに通知するイベント情報である場合には（ステップＳ９０５肯定）、アプリケーション２２にイベント情報を通知して（ステップＳ９０６）、処理を終了する。一方、クライアント２０は、アプリケーションに通知するイベント情報ではない場合には（ステップＳ９０５否定）、ステップＳ９０６の処理を実行することなく処理を終了する。

次に、図１７を用いてクライアントのディレクトリ情報取得要求発生時の処理手順を説明する。図１７に示すように、クライアント２０は、ディレクトリ情報取得要求がアプリケーションから発生すると（ステップＳ１００１肯定）、ディレクトリキャッシュを保持しているか否かを判定する（ステップＳ１００２）。この結果、クライアント２０は、ディレクトリキャッシュを保持している場合には（ステップＳ１００２肯定）、保持しているディレクトリキャッシュを読み込んでアプリケーションへ返却する（ステップＳ１００３）。なお、クライアント２０は、ディレクトリ情報取得要求がアプリケーションから発生するまで（ステップＳ１００１否定）、処理を開始しない。

一方、クライアント２０は、ディレクトリキャッシュを保持していない場合には（ステップＳ１００２否定）、発生したディレクトリ情報取得要求をマスタ１０Ａへ送信する（ステップＳ１００４）。そして、クライアント２０は、送信したディレクトリ情報取得要求に対応するディレクトリ情報をマスタ１０Ａから受信すると（ステップＳ１００５）、該ディレクトリ情報をディレクトリキャッシュとしてキャッシュ記憶部２１ｃに格納する（ステップＳ１００６）。

次に、図１８を用いてクライアントのノードの追加・削除要求発生時の処理手順を説明する。図１８に示すように、クライアント２０は、ノードの追加又は削除を行う旨の追加・削除要求がアプリケーションから発生すると（ステップＳ１１０１肯定）、ノードの追加・削除要求をマスタ１０Ａへ送信する（ステップＳ１１０２）。そして、クライアント２０は、マスタ１０Ａがノードの追加又は削除を行うと、ノードの追加又は削除を行った旨の応答をマスタ１０Ａから受信し（ステップＳ１１０３）、処理を終了する。なお、クライアント２０は、ノードの追加又は削除を行う旨の追加・削除要求がアプリケーションから発生するまで（ステップＳ１１０１否定）、処理を開始しない。

なお、クライアントのノードの追加・削除要求発生時の処理手順は、上記の例に限定されるものではない。例えば、クライアント２０は、ノードの追加を行った際に、追加したノードの親ノードＩＤに対応するノードのディレクトリキャッシュを保持していれば、マスタ１０Ａからの差分更新通知を待つことなく、追加したノードのディレクトリ情報を該ディレクトリキャッシュに追加しても良い。また、クライアント２０は、ノードの削除を行った際に、削除したノードのディレクトリキャッシュを保持していれば、マスタ１０Ａからの差分更新通知を待つことなく、削除したノードのディレクトリ情報を該ディレクトリキャッシュから削除しても良い。

［死活監視装置による処理］
次に、図１９及び図２０を用いて、第１の実施形態に係る死活監視装置による処理を説明する。図１９は、第１の実施形態に係る死活監視装置１０におけるイベント配信処理の処理手順を説明するためのフローチャートである。図２０は、第１の実施形態に係る死活監視装置１０における差分更新処理の処理手順を説明するためのフローチャートである。

まず、図１９を用いて第１の実施形態に係る死活監視装置１０におけるイベント配信処理の処理手順を説明する。図１９に示すように、マスタ１０Ａは、イベントが発生すると、イベント情報を登録し（ステップＳ１２０１）、レプリカ１０Ｂ〜１０Ｅへイベント情報の複製を通知する（ステップＳ１２０２）。そして、マスタ１０Ａは、クライアント２０へイベント情報を送信し（ステップＳ１２０３）、クライアントから最新受信完了イベントＩＤを含むイベント受信完了応答を受信する（ステップＳ１２０４）。そして、マスタ１０Ａは、イベント受信完了応答に含まれる最新受信完了イベントＩＤを登録する（ステップＳ１２０５）。

続いて、マスタ１０Ａは、イベント受信完了応答に含まれる最新受信完了イベントＩＤを複製して、レプリカ１０Ｂ〜１０Ｅへ通知する（ステップＳ１２０６）。その後、マスタ１０Ａは、イベント情報を送信したクライアント全てから応答があったか判定する（ステップＳ１２０７）。この結果、マスタ１０Ａは、イベント情報を送信したクライアント全てから応答がなかった場合（ステップＳ１２０７否定）、処理を終了する。

また、マスタ１０Ａは、イベント情報を送信したクライアント全てから応答があった場合（ステップＳ１２０７肯定）、イベント情報を削除し（ステップＳ１２０８）、レプリカ１０Ｂ〜１０Ｅへイベント情報削除を複製させて（ステップＳ１２０９）、処理を終了する。

次に、図２０を用いて第１の実施形態に係る死活監視装置１０における差分更新処理の処理手順を説明する。図２０に示すように、マスタ１０Ａは、ノードの追加・削除要求をクライアント２０から受信すると（ステップＳ１３０１肯定）、ノードの追加・削除要求に基づいて、データベース３０Ａを更新する（ステップＳ１３０２）。そして、マスタ１０Ａは、ノードの追加・削除要求の送信元のクライアント２０へ追加・削除完了の旨の応答を送信する（ステップＳ１３０３）。

また、マスタ１０Ａは、ノードの追加・削除要求に基づいて、データベース３０Ａを更新すると、更新したノードの差分更新通知を生成し（ステップＳ１３０４）、これをイベント情報としてイベント一覧に登録する。すなわち、マスタ１０Ａは、図１９のステップＳ１２０１及びステップＳ１２０２に示したように、差分更新通知をイベント情報として登録し、登録したイベント情報の複製をレプリカ１０Ｂ〜１０Ｅへ通知する。例えば、マスタ１０Ａは、セッションＩＤ「２」のセッションで接続されるクライアントからノードＩＤ「２」のファイルを追加する旨の追加要求を受信した場合には、イベント発生元のノードＩＤ「Ｎｉｄ＝２」と、イベント種別「ファイル追加」と、イベント発生元のセッションＩＤ「Ｓｉｄ＝２」とを対応付けてイベントＩＤ「１」のイベントとしてイベント一覧に登録する。

そして、マスタ１０Ａは、差分更新通知の通知先となる通知先クライアントの一覧を取得する（ステップＳ１３０５）。例えば、マスタ１０Ａは、ノード情報一覧を参照し、イベント発生元のノードＩＤ「Ｎｉｄ＝２」の親ノードＩＤ「Ｐｉｄ＝１」のノードにアクセス中のセッションＩＤ「Ｓｉｄ＝１，３」を取得する。そして、マスタ１０Ａは、セッション情報一覧を参照し、取得した各セッションＩＤ「Ｓｉｄ＝１，３」に対応する「送信するイベントのエントリ」に「Ｅｉｄ＝１」をそれぞれ追加する。

そして、マスタ１０Ａは、通知先クライアントへ差分更新通知をイベント情報として送信する（ステップＳ１３０６）。すなわち、マスタ１０Ａは、図１９のステップＳ１２０３〜ステップＳ１２０９に示したように、差分更新通知をイベント情報として各クライアントへ送信し、応答を受信する。例えば、マスタ１０Ａは、ＩＰアドレス「１０．０．０．１」及び「１０．０．１．４」の各クライアントに差分更新通知を送信し、送信先の全てのクライアントから応答を受信すると、イベントＩＤ「１」のイベント情報（差分更新通知）を削除する。

[第１の実施形態の効果]
第１の実施形態に係るクライアント２０は、複数のサーバのうちの一つのサーバであるマスタサーバに記憶されたデータのキャッシュを記憶する。クライアント２０は、前記マスタサーバに記憶されたデータが更新された場合に、更新後のデータと更新前のデータとの間の差分を更新する旨の差分更新通知と、当該差分更新通知の送信を完了したか否かを示す送信完了情報との同期処理が前記マスタサーバによって行われた前記複数のサーバのうち、当該マスタサーバ、又は、当該マスタサーバ以外のレプリカサーバのなかから選択された新たなマスタサーバから、前記差分更新通知を受信する。クライアント２０は、受信された差分更新通知を用いて、前記キャッシュを更新する。このため、クライアント２０は、キャッシュの更新に要する通信負荷を軽減することができる。例えば、死活監視装置１０は、ディレクトリキャッシュに対して追加・削除を行うノードのみを差分更新するため、キャッシュの更新に要する通信負荷を軽減することができ、ディレクトリ情報の更新を高速に行うことができる。

ここで、図２１を用いて第１の実施形態に係る死活監視システムの効果を説明する。図２１は、第１の実施形態に係る死活監視システムの効果を説明するための図である。図２１には、死活監視の対象となる３台のクライアント２０Ａ〜２０Ｃ（計算機１〜３）が死活監視装置１０に接続されており、４台目のクライアント２０Ｄ（計算機４）が追加された場合の差分更新処理を例示する。なお、図２１において、クライアント２０Ａ〜２０Ｄ（計算機１〜４）の名称は、それぞれ「ｍ１〜ｍ４」であるものとする。

図２１の左側には、４台目のクライアント２０Ｄが追加される前の死活監視システムの状態を示す。この場合、死活監視装置１０は、５台のサーバで構成され、各クライアント２０Ａ〜２０Ｃと接続されている。このとき、死活監視装置１０は、接続されている各クライアント２０Ａ〜２０Ｃ（計算機１〜３）の名前のファイル名「ｍ１，ｍ２，ｍ３」のファイルをそれぞれ作成し、ディレクトリ名「ｍＤｉｒ」のディレクトリ配下に保持している。また、各クライアント２０Ａ〜２０Ｃは、ディレクトリ名「ｍＤｉｒ」のディレクトリを監視しており、ディレクトリ名「ｍＤｉｒ」のキャッシュとしてファイル名「ｍ１，ｍ２，ｍ３」をそれぞれ保持している。また、死活監視装置１０は、各クライアント２０Ａ〜２０Ｃがディレクトリ名「ｍＤｉｒ」のキャッシュを保持している旨の情報を記憶している。

ここで、４台目のクライアント２０Ｄ（計算機）が死活監視の対象として死活監視装置１０に接続されると、クライアント２０Ｄは、死活監視装置１０のディレクトリ名「ｍＤｉｒ」のディレクトリ配下に自装置を示すファイル名「ｍ４」のファイルを作成する要求を送信し（１．ファイル追加）、これを追加する（２．ファイル追加）。ここで、従来の技術では、各クライアント２０Ａ〜２０Ｃが追加前に保持していたキャッシュを削除してから、追加後のディレクトリ情報であるファイル名「ｍ１，ｍ２，ｍ３，ｍ４」を再受信するので、通信負荷が大きかった。すなわち、各クライアント２０Ａ〜２０Ｃは、ファイル追加の前後で変化のないファイル名「ｍ１，ｍ２，ｍ３」についても再受信していたので、通信負荷が大きかった。

これに対して、第１の実施形態に係る死活監視装置１０は、このファイル名「ｍ４」のファイルの追加を契機として、各クライアント２０が保持するキャッシュにファイル名「ｍ４」を追加する旨の差分更新通知を行う。具体的には、死活監視装置１０は、追加されたファイル名「ｍ４」の親のディレクトリ名「ｍＤｉｒ」のディレクトリ情報を保持するクライアント２０Ａ〜２０Ｃを通知先クライアントとして特定する（３．差分通知準備）。そして、死活監視装置１０は、特定した各クライアント２０Ａ〜２０Ｃに対してファイル名「ｍ４」を追加する旨の差分更新通知を送信する（４．更新情報通知）。このように、第１の実施形態に係る死活監視システムは、各クライアント２０Ａ〜２０Ｃに対してファイル名「ｍ１，ｍ２，ｍ３，ｍ４」を通知するのではなく、新たに追加されたファイル名「ｍ４」のみを通知することができるので、キャッシュの更新に要する通信負荷を軽減することができる。

更に具体例を挙げて説明する。例えば、サーバにおいて、ディレクトリ名「ｍＤｉｒ」のディレクトリ配下に１００００個のファイルが管理されている状況で、サーバ側に１個のファイルが追加された場合を説明する。この場合、従来技術では、１０００１個のファイル名が各クライアント２０に再通知されていた。これに対して、第１の実施形態に係る死活監視装置１０は、追加された１個のファイル名のみを各クライアント２０に通知する。このため、第１の実施形態に係る死活監視装置１０は、キャッシュの更新に要する通信負荷を軽減することができる。

また、従来技術では、例えば、差分更新通知が発生した後に、マスタ１０Ａに故障が発生した場合には、一部のクライアント２０に対して差分更新通知が欠送してしまう恐れがあった。すなわち、従来技術では、キャッシュの維持が担保されなかったため、分散システムに対してキャッシュの差分更新技術を実装することができなかった。これに対して、第１の実施形態に係る死活監視装置１０は、欠送防止処理を行うことによって差分更新通知の欠送を防止しているので、故障が発生しても差分更新通知が欠送することを防止することができる。すなわち、死活監視装置１０は、フェイルオーバの前後でもキャッシュの維持が担保されるため、分散システムに対してキャッシュの差分更新技術を実装することが可能となった。

［第２の実施形態］
上記の第１の実施形態では、ディレクトリキャッシュが差分更新される場合を説明したが、実施形態はこれに限定されるものではない。例えば、実施形態は、マスタ１０Ａから取得されたファイルのキャッシュが差分更新される場合に適用されても良い。そこで、第２の実施形態では、マスタ１０Ａから取得されたファイルのキャッシュが差分更新される場合を説明する。

第２の実施形態に係る死活監視システム１は、図２に示した死活監視システム１と比較して、基本的に同様の機能構成を有し、クライアント２０がディレクトリ情報ではなくファイル等のデータをキャッシュデータとして保持する点が相違する。以下、この相違点について中心的に説明することとする。

図２２を用いて、第２の実施形態に係る死活監視システム１による差分更新処理の流れを説明する。図２２は、第２の実施形態に係る死活監視システム１による差分更新処理の流れを示すシーケンス図である。図２２には、クライアント２０Ｂがマスタ１０Ａに記憶されたファイル名「ＦｉｌｅＡ」のキャッシュを取得した場合を説明する。そして、クライアント２０Ａによるファイル名「ＦｉｌｅＡ」の内容の更新に応じて、キャッシュが差分更新される場合を例示する。

図２２に示すように、クライアント２０Ｂは、アプリケーション２２からファイル名「ＦｉｌｅＡ」のファイルを取得するための取得要求が発生すると（ステップＳ１４０１）、マスタ１０Ａへ「ＦｉｌｅＡ」の取得要求を送信する（ステップＳ１４０２）。クライアント２０Ｂは、送信した取得要求に対応するファイルの内容をマスタ１０Ａから受信すると（ステップＳ１４０３）、ファイルのキャッシュを格納する（ステップＳ１４０４）。この結果、クライアント２０Ｂは、ファイル名「ＦｉｌｅＡ」のファイルのキャッシュを取得する。なお、クライアント２０Ｂが取得したファイル名「ＦｉｌｅＡ」の内容は、例えば、「Ｌｉｎｅ１ ａａａ，Ｌｉｎｅ２ ｂｂｂ」である。

これ以降、クライアント２０Ｂは、アプリケーション２２からファイル名「ＦｉｌｅＡ」のファイルを取得するための取得要求が発生するごとに（ステップＳ１４０５）、取得済みのキャッシュを読み込んで（ステップＳ１４０６）、これを利用する。

ここで、クライアント２０Ａがファイル名「ＦｉｌｅＡ」のファイルを更新する旨の更新要求をマスタ１０Ａに対して送信すると（ステップＳ１４０７）、マスタ１０Ａは、ファイル名「ＦｉｌｅＡ」のファイルを更新する。例えば、マスタ１０Ａは、ファイル名「ＦｉｌｅＡ」のファイル更新要求を受信すると、ファイル名「ＦｉｌｅＡ」のファイルを更新する（ステップＳ１４０８）。例えば、マスタ１０Ａは、ファイル名「ＦｉｌｅＡ」のファイルの内容を「Ｌｉｎｅ１ ａａａ，Ｌｉｎｅ２ ｂｂｂ，Ｌｉｎｅ３ ｃｃｃ」に変更する旨の更新要求であれば、データベース３０Ａに記憶された更新前のファイル名「ＦｉｌｅＡ」のファイルの内容を生成部１２へ通知する。そして、マスタ１０Ａは、更新要求で指定されたファイルの内容を生成部１２へ通知するとともに、データベース３０Ａに記憶されたファイル名「ＦｉｌｅＡ」のファイルを更新要求にしたがって上書きする（更新）。そして、マスタ１０Ａは、ファイル名「ＦｉｌｅＡ」のファイルを更新すると、ファイルの更新完了をクライアント２０Ａへ通知する（ステップＳ１４０９）。

マスタ１０Ａは、ファイル名「ＦｉｌｅＡ」のファイルを更新すると、ファイル名「ＦｉｌｅＡ」のファイルを更新するための差分更新通知を生成する。具体的には、マスタ１０Ａの生成部１２は、更新前のファイル名「ＦｉｌｅＡ」の内容と、更新後のファイル名「ＦｉｌｅＡ」の内容とを比較する。そして、マスタ１０Ａの生成部１２は、更新前のファイル名「ＦｉｌｅＡ」の内容の「Ｌｉｎｅ２ ｂｂｂ」の次に「Ｌｉｎｅ３ ｃｃｃ」を挿入する旨の差分更新通知を生成する。そして、マスタ１０Ａは、生成した差分更新通知を、キャッシュを保持するクライアント２０Ｂに送信する（ステップＳ１４１０）。この結果、クライアント２０Ｂは、キャッシュのファイル名「ＦｉｌｅＡ」の内容を更新し（ステップＳ１４１１）、キャッシュデータ内の「Ｌｉｎｅ２ ｂｂｂ」の次に「Ｌｉｎｅ３ ｃｃｃ」を挿入する。そして、クライアント２０Ｂは、更新完了通知をマスタ１０Ａへ送信する（ステップＳ１４１２）。

これ以降、クライアント２０Ｂは、アプリケーション２２からファイル名「ＦｉｌｅＡ」のファイルを取得するための取得要求が発生するごとに（ステップＳ１４１３）、更新済みのキャッシュを読み込んで（ステップＳ１４１４）、これを利用する。

このように、第２の実施形態によれば、死活監視システム１は、マスタ１０Ａから取得されたファイルのキャッシュを差分更新することもできる。このため、死活監視システムは、キャッシュの更新に要する通信負荷を軽減することが期待される。

［第３の実施形態］
さて、これまで本発明の実施形態について説明したが、本発明は上述した実施形態以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では第３の実施形態として本発明に含まれる他の実施形態を説明する。

例えば、上記の実施形態では、クライアント２０がマスタ１０Ａから受信した差分更新通知に基づいてキャッシュの差分更新を行う場合を説明したが、実施形態はこれに限定されるものではない。例えば、ノードの追加・削除要求を送信したクライアント２０がキャッシュを保持していれば、マスタ１０Ａからの差分更新通知を待つことなくキャッシュの差分更新を行っても良い。

図２３を用いて第３の実施形態に係るクライアント２０のノードの追加・削除要求発生時の処理手順を説明する。図２３は、第３の実施形態に係るクライアントのノードの追加・削除要求発生時の処理手順を説明するためのフローチャートである。

図２３に示すように、クライアント２０は、ノードの追加又は削除を行う旨の追加・削除要求がアプリケーション２２から発生すると（ステップＳ１５０１肯定）、ノードの追加・削除要求をマスタ１０Ａへ送信する（ステップＳ１５０２）。そして、クライアント２０は、マスタ１０Ａがノードの追加又は削除を行うと、ノードの追加又は削除を行った旨の応答をマスタ１０Ａから受信する（ステップＳ１５０３）。なお、クライアント２０は、ノードの追加又は削除を行う旨の追加・削除要求がアプリケーション２２から発生するまで（ステップＳ１１０１否定）、処理を開始しない。

そして、クライアント２０は、追加・削除したノードを含むキャッシュを保持しているか判定する（ステップＳ１５０４）。クライアント２０は、キャッシュを保持している場合には（ステップＳ１５０４肯定）、追加・削除要求に基づいて、保持しているキャッシュに対してノードの追加・削除を行う差分更新を実行し（ステップＳ１５０５）、処理を終了する。なお、クライアント２０は、キャッシュを保持していない場合には（ステップＳ１５０４否定）、処理を終了する。

このように、ノードの追加・削除要求を送信したクライアント２０がキャッシュを保持していれば、クライアント２０は、マスタ１０Ａからの差分更新通知を待つことなくキャッシュの差分更新を行うことができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、イベント送信部１３と送信未完了イベント送信部１６を統合してもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、上記実施形態において説明した死活監視装置１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施例１に係る死活監視装置１０が実行する処理をコンピュータが実行可能な言語で記述した差分更新プログラムを作成することもできる。この場合、コンピュータが差分更新プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる差分更新プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された差分更新プログラムをコンピュータに読み込ませて実行することにより上記第一の実施形態と同様の処理を実現してもよい。以下に、図２に示した死活監視装置１０と同様の機能を実現する差分更新プログラムを実行するコンピュータの一例を説明する。

図２４は、差分更新プログラムを実行するコンピュータ１０００を示す図である。図２４に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図２４に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図２４に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図２４に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。

ここで、図２４に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の差分更新プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各手順を実行する。

なお、差分更新プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、差分更新プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１ 死活監視システム
１０ 死活監視装置
１０Ａ マスタ
１０Ｂ〜１０Ｅ レプリカ
１１ 更新部
１２ 生成部
１３ イベント送信部
１４ 同期部
１５ 接続部
１６ 送信未完了イベント送信部
１７ 記憶部
２０ クライアント
２１ クライアントライブラリ
２１ａ セッション管理部
２１ｂ キャッシュ更新部
２１ｃ キャッシュ記憶部
２２ アプリケーション

Claims (7)

1. クライアントである差分更新装置の有する記憶部であって、複数のサーバのうちの一つのサーバであるマスタサーバに記憶されたデータのキャッシュを記憶するキャッシュ記憶部と、
   前記クライアントの有する接続部であって、前記マスタサーバに故障が発生し、前記故障したマスタサーバとの通信が途絶えた場合に、更新後のデータと更新前のデータとの間の差分を更新する旨の差分更新通知と、当該差分更新通知の送信を完了したか否かを示す情報であって、前記クライアントに送信された前記差分更新通知に対する応答を前記クライアントから受信したことを示す送信完了情報との同期処理が前記マスタサーバによって行われた前記複数のサーバのうち、当該マスタサーバ以外のレプリカサーバのなかから選択された新たなマスタサーバを問い合わせ、以降の同期処理を行う新たなマスタサーバと通信可能に接続する接続部と、
   前記クライアントの有する受信部であって、前記マスタサーバに故障が発生した場合に、前記新たなマスタサーバから前記差分更新通知を受信し、前記マスタサーバに故障が発生していない場合に、該マスタサーバから前記差分更新通知を受信する受信部と、
   前記クライアントの有する更新部であって、受信された差分更新通知を用いて、前記キャッシュを更新するとともに、前記マスタサーバ又は前記新たなマスタサーバに、前記差分更新通知に対する応答として信号を送信する更新部と
   を備えたことを特徴とする差分更新装置。
2. 前記キャッシュ記憶部は、前記マスタサーバに記憶されたデータについてのディレクトリ情報をキャッシュとして記憶し、
   前記接続部は、前記マスタサーバに故障が発生し、前記故障したマスタサーバとの通信が途絶えた場合に、更新後のディレクトリ情報と更新前のディレクトリ情報との間の差分を更新する旨のディレクトリ用差分更新通知と、当該ディレクトリ用差分更新通知の送信を完了したか否かを示す情報であって、前記クライアントに送信された前記差分更新通知に対する応答を前記クライアントから受信したことを示すディレクトリ用送信完了情報との同期処理が前記マスタサーバによって行われた前記複数のサーバのうち、当該マスタサーバ以外のレプリカサーバのなかから選択された新たなマスタサーバを問い合わせ、以降の同期処理を行う新たなマスタサーバと通信可能に接続し、
   前記受信部は、前記マスタサーバに故障が発生した場合に、前記新たなマスタサーバから前記ディレクトリ用差分更新通知を受信し、前記マスタサーバに故障が発生していない場合に、該マスタサーバから前記ディレクトリ用差分更新通知を受信し、
   前記更新部は、受信されたディレクトリ用差分更新通知を用いて、前記キャッシュを更新するとともに、前記マスタサーバ又は前記新たなマスタサーバに、前記差分更新通知に対する応答として信号を送信することを特徴とする請求項１に記載の差分更新装置。
3. 前記マスタサーバに記憶されたデータを更新する旨の更新要求を当該マスタサーバに対して送信する更新要求送信部を更に備え、
   前記更新部は、前記更新要求送信部によって送信された更新要求に対応するデータのキャッシュが前記記憶部に記憶されていれば、前記更新要求に基づいて、当該キャッシュを更新することを特徴とする請求項１に記載の差分更新装置。
4. 複数のサーバと、クライアントとを備えた差分更新システムであって、
   前記複数のサーバ各々が、
   データを記憶するデータ記憶部と、
   前記データ記憶部に記憶されたデータを更新する旨の要求を受信して、受信した要求に応じて前記データ記憶部に記憶されたデータを更新するデータ更新部と、
   前記データ更新部によって更新された更新後の情報と、更新前の情報との差分を更新するための差分更新通知を生成する生成部と、
   前記データ記憶部に記憶されたデータのキャッシュを保持する前記クライアントへ前記差分更新通知を送信する送信部と、
   複数のサーバのうちの一つのサーバであるマスタサーバが差分更新通知を送信した場合には、前記マスタサーバが記憶する差分更新通知と、前記クライアントに対して前記差分更新通知の送信を完了したか否かを示す情報であって、前記クライアントに送信された前記差分更新通知に対する応答を前記クライアントから受信したことを示す送信完了情報とを、前記複数のサーバのうち前記マスタサーバ以外のサーバであるレプリカサーバに記憶させる同期部と、
   前記マスタサーバに故障が発生し、レプリカサーバであったサーバが新たなマスタサーバとなった場合であって、前記故障したマスタサーバとの通信が途絶えたことによる接続要求を前記クライアントから受信した場合に、前記レプリカサーバのなかから選択された新たなマスタサーバと前記クライアントとを通信可能に接続する接続部と、
   前記新たなマスタサーバとクライアントとが通信可能となった場合には、前記送信完了情報として、前記クライアントに対して送信した最新の差分更新通知を識別する識別情報を用いて、前記新たなマスタサーバが記憶する差分更新通知のうち前記クライアントに対して送信未完了である差分更新通知を特定し、該送信未完了である差分更新通知を前記クライアントに送信する送信未完了通知送信部と、を備え、
   前記クライアントが、
   前記マスタサーバに記憶されたデータのキャッシュを記憶するキャッシュ記憶部と、
   前記マスタサーバに故障が発生し、前記故障したマスタサーバとの通信が途絶えた場合に、前記新たなマスタサーバを問い合わせ、以降の同期処理を行う新たなマスタサーバと通信可能に接続する接続部と、
   前記マスタサーバに故障が発生した場合に、前記新たなマスタサーバから前記差分更新通知を受信し、前記マスタサーバに故障が発生していない場合に、該マスタサーバから前記差分更新通知を受信する受信部と、
   受信された差分更新通知を用いて、前記キャッシュを更新するとともに、前記マスタサーバ又は前記新たなマスタサーバに、前記差分更新通知に対する応答として信号を送信するキャッシュ更新部と
   を備えたことを特徴とする差分更新システム。
5. 差分更新装置で実行される差分更新方法であって、
   複数のサーバのうちの一つのサーバであるマスタサーバに故障が発生し、前記故障したマスタサーバとの通信が途絶えた場合に、更新後のデータと更新前のデータとの間の差分を更新する旨の差分更新通知と、当該差分更新通知の送信を完了したか否かを示す情報であって、クライアントに送信された前記差分更新通知に対する応答を前記クライアントから受信したことを示す送信完了情報との同期処理が前記マスタサーバによって行われた前記複数のサーバのうち、当該マスタサーバ以外のレプリカサーバのなかから選択された新たなマスタサーバを問い合わせ、以降の同期処理を行う新たなマスタサーバと通信可能に接続する接続工程と、
   前記マスタサーバに故障が発生した場合に、前記新たなマスタサーバから前記差分更新通知を受信し、前記マスタサーバに故障が発生していない場合に、該マスタサーバから前記差分更新通知を受信する受信工程と、
   受信された差分更新通知を用いて、前記マスタサーバに記憶されたデータのキャッシュを記憶する記憶部に記憶されたキャッシュを更新するとともに、前記マスタサーバ又は前記新たなマスタサーバに、前記差分更新通知に対する応答として信号を送信する更新工程と
   を含んだことを特徴とする差分更新方法。
6. 複数のサーバのうちの一つのサーバであるマスタサーバに故障が発生し、前記故障したマスタサーバとの通信が途絶えた場合に、更新後のデータと更新前のデータとの間の差分を更新する旨の差分更新通知と、該差分更新通知の送信を完了したか否かを示す情報であって、クライアントに送信された前記差分更新通知に対する応答を前記クライアントから受信したことを示す送信完了情報との同期処理が前記マスタサーバによって行われた前記複数のサーバのうち、当該マスタサーバ以外のレプリカサーバのなかから選択された新たなマスタサーバを問い合わせ、以降の同期処理を行う新たなマスタサーバと通信可能に接続する接続ステップと、
   前記マスタサーバに故障が発生した場合に、前記新たなマスタサーバから前記差分更新通知を受信し、前記マスタサーバに故障が発生していない場合に、該マスタサーバから前記差分更新通知を受信する受信ステップと、
   受信された差分更新通知を用いて、前記マスタサーバに記憶されたデータのキャッシュを記憶する記憶部に記憶されたキャッシュを更新するとともに、前記マスタサーバ又は前記新たなマスタサーバに、前記差分更新通知に対する応答として信号を送信する更新ステップと
   をコンピュータに実行させることを特徴とする差分更新プログラム。
7. データを記憶するデータ記憶部と、
   前記データ記憶部に記憶されたデータを更新する旨の要求を受信して、受信した要求に応じて前記データ記憶部に記憶されたデータを更新するデータ更新部と、
   前記データ更新部によって更新された更新後の情報と、更新前の情報との差分を更新するための差分更新通知を生成する生成部と、
   前記データ記憶部に記憶されたデータのキャッシュを保持するクライアントへ前記差分更新通知を送信する送信部と、
   複数のサーバのうちの一つのサーバであるマスタサーバが差分更新通知を送信した場合には、前記マスタサーバが記憶する差分更新通知と、前記クライアントに対して前記差分更新通知の送信を完了したか否かを示す情報であって、前記クライアントに送信された前記差分更新通知に対する応答を前記クライアントから受信したことを示す送信完了情報とを、複数のサーバのうち前記マスタサーバ以外のサーバであるレプリカサーバに記憶させる同期部と、
   前記マスタサーバに故障が発生し、レプリカサーバであったサーバが新たなマスタサーバとなった場合であって、前記故障したマスタサーバとの通信が途絶えたことによる接続要求を前記クライアントから受信した場合に、前記レプリカサーバのなかから選択された新たなマスタサーバと前記クライアントとを通信可能に接続する接続部と、
   前記新たなマスタサーバとクライアントとが通信可能となった場合には、前記送信完了情報として、前記クライアントに対して送信した最新の差分更新通知を識別する識別情報を用いて、前記新たなマスタサーバが記憶する差分更新通知のうち前記クライアントに対して送信未完了である差分更新通知を特定し、該送信未完了である差分更新通知を前記クライアントに送信する送信未完了通知送信部と
   を備えたことを特徴とする差分更新サーバ。

Images