(57)【特許請求の範囲】
【請求項１】
データの原本を所持するマスタとして機能したり、前記データの複製を所持するスレーブとして機能したりする複数のサーバが通信可能に接続されているデータ管理システムであって、
前記サーバの制御部は、
前記サーバが注目データのマスタである場合には、前記注目データの原本への最終的なアクセスがあった時刻である原本最終アクセス時刻を取得してマスタ側原本最終アクセス時刻として記憶部に記憶し、
前記サーバが前記注目データのスレーブである場合には、前記スレーブが所持する前記注目データの複製に紐付けられている原本を所持するマスタから、前記注目データの前記原本最終アクセス時刻を取得してスレーブ側原本最終アクセス時刻として前記記憶部に記憶する、原本最終アクセス時刻取得部と、
前記サーバが前記注目データのマスタである場合には、前記マスタ側原本最終アクセス時刻から、前記注目データに対して設定した所定の原本有効期間が満了する時までの間に、前記注目データの原本へのアクセスが無いときは、前記注目データの原本を原本浮き候補と決定し、
前記サーバが前記注目データのスレーブである場合には、前記スレーブ側原本最終アクセス時刻から、前記注目データに対して設定した所定の複製有効期間が満了する時までの間に、前記注目データの原本へのアクセスが無いときは、前記注目データの複製を複製浮き候補と決定する、浮き候補決定部と、を備える、
ことを特徴とするデータ管理システム。
【請求項２】
前記複製有効期間は、前記原本有効期間よりも長い、
ことを特徴とする請求項１に記載のデータ管理システム。
【請求項３】
前記サーバの制御部は、さらに、
前記データが浮きデータであるか否かを判定可能な手段に対して、前記浮き候補決定部が前記原本浮き候補または前記複製浮き候補であると決定した前記注目データが浮きデータであるか否かを判定するように要求する浮き判定要求部、を備える、
ことを特徴とする請求項１または請求項２に記載のデータ管理システム。
【請求項４】
前記サーバの制御部は、さらに、
前記サーバが前記注目データのスレーブである場合には、前記注目データについて、前記スレーブ側原本最終アクセス時刻が前記マスタ側原本最終アクセス時刻と一致しているか否かを確認する原本最終アクセス時刻確認部、を備える、
ことを特徴とする請求項１から請求項３のいずれか１項に記載のデータ管理システム。
【請求項５】
データの原本を所持するマスタとして機能したり、前記データの複製を所持するスレーブとして機能したりする複数のサーバが通信可能に接続されているデータ管理システムにおける、前記サーバとしてコンピュータを機能させるための浮きチェックプログラムであって、
前記サーバの制御部を、
前記サーバが注目データのマスタである場合には、前記注目データの原本への最終的なアクセスがあった時刻である原本最終アクセス時刻を取得してマスタ側原本最終アクセス時刻として記憶部に記憶し、
前記サーバが前記注目データのスレーブである場合には、前記スレーブが所持する前記注目データの複製に紐付けられている原本を所持するマスタから、前記注目データの前記原本最終アクセス時刻を取得してスレーブ側原本最終アクセス時刻として前記記憶部に記憶する、原本最終アクセス時刻取得部、
前記サーバが前記注目データのマスタである場合には、前記マスタ側原本最終アクセス時刻から、前記注目データに対して設定した所定の原本有効期間が満了する時までの間に、前記注目データの原本へのアクセスが無いときは、前記注目データの原本を原本浮き候補と決定し、
前記サーバが前記注目データのスレーブである場合には、前記スレーブ側原本最終アクセス時刻から、前記注目データに対して設定した所定の複製有効期間が満了する時までの間に、前記注目データの原本へのアクセスが無いときは、前記注目データの複製を複製浮き候補と決定する、浮き候補決定部、
として機能させるための浮きチェックプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタを構成する複数のサーバがマスタスレーブ型のデータ管理を行う技術に関する。
【背景技術】
【０００２】
非特許文献１には、マスタスレーブ方式のレプリケーションによって、１つの本番（原本）データベースと複数の複製データベースをネットワーク上に配置することについて開示されている。
【０００３】
マスタスレーブ型のデータ管理システムは、１つのデータについて、マスタとなるサーバがデータの原本を所持し、冗長度に相当する台数のサーバがスレーブとしてデータの複製をバックアップとして所持する。データは、データ本体およびデータ管理情報（マスタがどのサーバであり、スレーブはどのサーバであるか、などの情報）からなり、原本と複製との間で、データ本体およびデータ管理情報の内容は全く同じである。データの更新および参照をクライアントから受け付けるのはマスタだけである。マスタは、原本に変更が生じた場合、スレーブに複製の更新を都度させる。
【０００４】
データ管理システムの運用が継続されると、新たなサーバの追加や既存のサーバの離脱が行われる。このような追加または離脱があると、データを所持するサーバを切り替える必要があるため、いずれかのサーバが元々所持していたデータを削除する必要が生じる場合がある。また、クライアントがデータ管理システムからのサービスの利用を終了した場合、そのサービスに対応するデータを所持していたサーバは、そのデータを削除する必要がある。
【０００５】
しかし、諸事情によりデータの削除が失敗し、データが浮いてしまう場合がある。ここで、削除が予定されていたが、削除できずにサーバ内に残っているデータを「浮きデータ」と呼ぶ。サーバが浮きデータを所持し続けることは、リソースの無駄使いや、データ探索時の不具合をもたらすので、浮きデータは早急に削除すべきである。
【０００６】
一方、浮きデータを削除するつもりであっても削除するデータを誤ってしまう（別のデータを削除してしまう）場合もある。この場合、原本の削除によるデータの完全消失または複製の削除による冗長度減少を招いてしまう。よって、各サーバが所持するデータが浮きデータであるか否かの確認は精密に行う必要があるが、すべてのデータに対してそのような精密な確認を行うことは管理上の負担が大きすぎる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】藤塚  勤也、「徹底比較！！  PostgreSQL vs MySQL、第４回：レプリケーションの比較」、［online］、2006/5/22、［平成26年3月17日検索］、インターネット<ＵＲＬ: http://thinkit.co.jp/free/article/0603/10/4/>
【発明の概要】
【発明が解決しようとする課題】
【０００８】
このような背景に鑑みて、本発明は、マスタスレーブ型のデータ管理システムにおいて、浮きデータの検出を容易にすることを課題とする。
【課題を解決するための手段】
【０００９】
前記した課題を解決するため、請求項１に記載の発明は、データの原本を所持するマスタとして機能したり、前記データの複製を所持するスレーブとして機能したりする複数のサーバが通信可能に接続されているデータ管理システムであって、前記サーバの制御部は、前記サーバが注目データのマスタである場合には、前記注目データの原本への最終的なアクセスがあった時刻である原本最終アクセス時刻を取得してマスタ側原本最終アクセス時刻として記憶部に記憶し、前記サーバが前記注目データのスレーブである場合には、前記スレーブが所持する前記注目データの複製に紐付けられている原本を所持するマスタから、前記注目データの前記原本最終アクセス時刻を取得してスレーブ側原本最終アクセス時刻として前記記憶部に記憶する、原本最終アクセス時刻取得部と、前記サーバが前記注目データのマスタである場合には、前記マスタ側原本最終アクセス時刻から、前記注目データに対して設定した所定の原本有効期間が満了する時までの間に、前記注目データの原本へのアクセスが無いときは、前記注目データの原本を原本浮き候補と決定し、前記サーバが前記注目データのスレーブである場合には、前記スレーブ側原本最終アクセス時刻から、前記注目データに対して設定した所定の複製有効期間が満了する時までの間に、前記注目データの原本へのアクセスが無いときは、前記注目データの複製を複製浮き候補と決定する、浮き候補決定部と、を備える、ことを特徴とする。
【００１０】
また、請求項５に記載の発明は、データの原本を所持するマスタとして機能したり、前記データの複製を所持するスレーブとして機能したりする複数のサーバが通信可能に接続されているデータ管理システムにおける、前記サーバとしてコンピュータを機能させるための浮きチェックプログラムであって、前記サーバの制御部を、前記サーバが注目データのマスタである場合には、前記注目データの原本への最終的なアクセスがあった時刻である原本最終アクセス時刻を取得してマスタ側原本最終アクセス時刻として記憶部に記憶し、前記サーバが前記注目データのスレーブである場合には、前記スレーブが所持する前記注目データの複製に紐付けられている原本を所持するマスタから、前記注目データの前記原本最終アクセス時刻を取得してスレーブ側原本最終アクセス時刻として前記記憶部に記憶する、原本最終アクセス時刻取得部、前記サーバが前記注目データのマスタである場合には、前記マスタ側原本最終アクセス時刻から、前記注目データに対して設定した所定の原本有効期間が満了する時までの間に、前記注目データの原本へのアクセスが無いときは、前記注目データの原本を原本浮き候補と決定し、前記サーバが前記注目データのスレーブである場合には、前記スレーブ側原本最終アクセス時刻から、前記注目データに対して設定した所定の複製有効期間が満了する時までの間に、前記注目データの原本へのアクセスが無いときは、前記注目データの複製を複製浮き候補と決定する、浮き候補決定部、として機能させるための浮きチェックプログラムである。
【００１１】
請求項１、５に記載の発明によれば、原本へのアクセスに期限を設けた浮きチェックを実現する。この浮きチェックでは、１つのデータの原本および複製に対して原本最終アクセス時刻を共通指標とすることで、原本と複製との間の、原本へのアクセスに関する整合性を保持する。そして、原本最終アクセス時刻を始点とする、原本有効期間内および複製有効期間内の原本へのアクセスの有無を判定し、前記アクセスが無い原本または複製を浮き候補とする。原本へのアクセスがあれば、原本最終アクセス時刻は更新される。浮き候補が浮きデータであるか否かの判定は、外部に要求することもできるし、サーバ自身で行うこともできる。原本および複製が浮きデータであると確定すれば、サーバは、その原本および複製を削除する。
このように、本発明は、浮きデータを検出するためにまず、所定期間内のアクセスの有無の観点から浮きデータである可能性の高い浮き候補を決定することを特徴とする。したがって、マスタスレーブ型のデータ管理システムにおいて、浮きデータの検出を容易にすることができる。
【００１２】
また、請求項２に記載の発明は、請求項１に記載の発明において、前記複製有効期間は、前記原本有効期間よりも長い、ことを特徴とする。
【００１３】
請求項２に記載の発明によれば、複製有効期間を原本有効期間よりも短くしたために複製が原本よりも先に削除されてデータの冗長性が損なわれてしまう、という不都合を回避することができる。
【００１４】
また、請求項３に記載の発明は、請求項１または請求項２に記載の発明において、前記サーバの制御部は、さらに、前記データが浮きデータであるか否かを判定可能な手段に対して、前記浮き候補決定部が前記原本浮き候補または前記複製浮き候補であると決定した前記注目データが浮きデータであるか否かを判定するように要求する浮き判定要求部、を備える、ことを特徴とする。
【００１５】
請求項３に記載の発明によれば、浮きデータであるか否かを判定可能な手段（例えば、保守サーバ、またはサーバ自身が備える機能）を利用することによって、対象のデータの特性、重要度に合わせて浮きデータを間違いなく削除することができる。
【００１６】
また、請求項４に記載の発明は、請求項１または請求項３に記載の発明において、前記サーバの制御部は、さらに、前記サーバが前記注目データのスレーブである場合には、前記注目データについて、前記スレーブ側原本最終アクセス時刻が前記マスタ側原本最終アクセス時刻と一致しているか否かを確認する原本最終アクセス時刻確認部、を備える、ことを特徴とする。
【００１７】
請求項４に記載の発明によれば、スレーブ側原本最終アクセス時刻の更新の遅延または失敗に起因する複製の誤削除を回避することができる。データ管理システム上の不具合により、スレーブがマスタから原本最終アクセス時刻を取得できていない場合がある。この場合、スレーブ側原本最終アクセス時刻の更新が遅延または失敗し、スレーブが記憶しているスレーブ側原本最終アクセス時刻は、更新が繰り返されたマスタ側原本最終アクセス時刻よりも前となってしまい、複製有効期間の満了時が固定してしまう。その結果、本来よりも早いタイミングで複製を複製浮き候補と決定してしまい、複製の誤削除に到る可能性がある。本発明によれば、スレーブ側原本最終アクセス時刻をマスタ側原本最終アクセス時刻に一致させた上で複製の浮きチェックを行うことができるので、前記可能性を排除することができる。
【発明の効果】
【００１８】
本発明によれば、マスタスレーブ型のデータ管理システムにおいて、浮きデータの検出を容易にすることができる。
【図面の簡単な説明】
【００１９】
【図１】本実施形態のデータ管理システムを含む分散処理システムの全体構成図である。
【図２】マスタの動作およびスレーブの動作の説明図である。
【図３】３種類の浮きパターンの説明図である。
【図４】浮きチェックに関する説明図である。
【図５】サーバの機能構成図である。
【図６】データ管理情報のデータ構造図である。
【図７】マスタが実行する原本の浮きチェック（基本）を示すフローチャートである。
【図８】浮きデータである旧原本およびその旧原本に紐づいていない複製の取り扱いに関する説明図である。
【図９】スレーブが実行する複製の浮きチェック（基本）を示すフローチャートである。
【図１０】浮きデータである旧複製およびその旧複製に紐づいていない原本の取り扱いに関する説明図である。
【図１１】マスタが実行する原本の浮きチェック（データごと）を示すフローチャートである。
【図１２】マスタが実行する原本の浮きチェック（全データ共通）を示すフローチャートである。
【図１３】スレーブが実行する複製の浮きチェック（データごと）を示すフローチャートである。
【図１４】スレーブが実行する複製の浮きチェック（全データ共通、定期整合なし）を示すフローチャートである。
【図１５】スレーブが実行する複製の浮きチェック（全データ共通、定期整合あり）を示すフローチャートである。
【発明を実施するための形態】
【００２０】
≪全体構成≫
図１に示すように、本実施形態のデータ管理システム１００は、クラスタを構成する複数のサーバ１を備えており、マスタスレーブ型のデータ管理を行う。分散処理システム１０００は、データ管理システム１００と、ロードバランサ３と、クラスタを構成する振り分け装置４と、を備えており、サーバ１に分散処理をさせることができる。
【００２１】
ロードバランサ３は、各クライアント２からのメッセージを受け付け、前記メッセージを単純なラウンドロビン等により各振り分け装置４に振り分ける。
振り分け装置４は、ロードバランサ３からのメッセージを各サーバ１に振り分ける。どのサーバ１にどのメッセージが振り分けられるかという規則は予め決められている。
サーバ１は、振り分けられたメッセージに対してメッセージ処理を行い、クライアント２に所定のサービスを提供する。
【００２２】
サーバ１、クライアント２、ロードバランサ３、振り分け装置４はそれぞれ、入力部、出力部、制御部および記憶部といったハードウェアを含むコンピュータである。例えば、制御部がＣＰＵ（Central Processing Unit）から構成される場合、その制御部を含むコンピュータによる情報処理は、ＣＰＵによるプログラム実行処理で実現する。また、そのコンピュータが含む記憶部は、ＣＰＵが指令し、そのコンピュータの機能を実現するためのプログラムを記憶する。これによりソフトウェアとハードウェアの協働が実現される。前記プログラムは、記録媒体に記録したり、ネットワークを経由したりすることで提供される。
【００２３】
サーバ１は、メッセージ処理を行う際、そのサーバ１が所持するデータを更新または参照する。データの更新または参照は、データの原本に対して行われる。よって、振り分け装置４は、原本としてデータを所持しているサーバ１（マスタ）に対して、そのデータに対応するメッセージを振り分ける。サーバ１（マスタ）は、原本にアクセスして、原本を更新または参照し、メッセージ処理を行う。図２には、データＸの原本を所持するマスタであるサーバＡがその原本の更新または参照を行う様子が図示されている。
【００２４】
また、原本に変更があった場合、原本を所持するサーバ１からの要求により、複製としてデータを所持しているサーバ１（スレーブ）は、複製を更新し、原本の内容と同一にする。図２には、サーバＡからの要求により、データＸの複製を所持するスレーブであるサーバＢ、サーバＣがその複製の更新を行う様子が図示されている。
【００２５】
≪浮きチェックの概要≫
クライアント２によるサービスの利用終了、マスタからスレーブへの変更、スレーブからマスタへの変更などに応じてデータを削除しようとしても、その削除に失敗して浮きデータが生じる場合がある。浮きデータについては、他のデータを間違えて削除しないように浮きチェックをし、マスタおよびスレーブが所持しているデータが浮きデータであることを決定した上で削除する必要がある。
【００２６】
マスタスレーブ型のデータ管理においては、原本と複製とが浮きデータである可能性がある。よって、図３に示すように、浮きチェックは、想定される以下の３種類の浮きパターンに対して行う必要がある。
浮きパターン（１）：原本も複製も浮きデータ
浮きパターン（２）：原本のみ浮きデータ（複製は削除成功）
浮きパターン（３）：複製のみ浮きデータ（原本は削除成功）
浮きパターン（１）、（２）に対しては、原本の浮きチェックを行う。原本が浮きデータであると決定した場合には、その原本は削除される。浮きパターン（１）については、原本に紐づいた複製も削除される。浮きパターン（３）に対しては、複製の浮きチェックを行う。複製が浮きデータであると決定した場合には、その複製は削除される。
【００２７】
本発明では、メッセージ処理によって注目データの原本への最終的なアクセスがあった時刻である「原本最終アクセス時刻」を、原本および複製の浮きチェックのための共通指標として用いる。原本へのアクセスがなされる度に原本最終アクセス時刻は更新される。
【００２８】
図４に示すように、原本に対して、原本最終アクセス時刻からの所定の有効期間である原本有効期間ＴＯを設定する。また、複製に対して、原本最終アクセス時刻からの所定の有効期間である複製有効期間ＴＲを設定する。
マスタは、原本有効期間ＴＯを経過した原本を浮き候補として検出し、検出した浮き候補を、必要に応じて外部の保守サーバに通知する。保守サーバは、浮き判断を行う手段を備えており、浮き候補が浮きデータであると決定すれば、浮き候補となった原本を削除するなどの指示をマスタに出力する。
一方、スレーブは、複製有効期間ＴＲを経過した複製を浮き候補として検出し、検出した浮き候補を、必要に応じて保守サーバに通知する。保守サーバは、浮き候補が浮きデータであると決定すれば、浮き候補となった複製を削除するなどの指示をスレーブに出力する。なお、スレーブは、複製に対して用いる原本最終アクセス時刻に間違いがない（原本に対して用いる原本最終アクセス時刻と一致している）ことを確認した上で、浮き候補となった複製を保守サーバに通知することができる（詳細は後記）。
【００２９】
保守サーバとは、例えば、オンラインショッピングのサイトを運営する業者が、そのオンラインショッピングの登録ユーザのアカウント情報を記憶して管理するサーバとすることができる。本実施形態のデータ管理システム１００は、例えば、オンラインショッピングのカート（買い物かご）情報を管理することができる。クライアント２のユーザが商品購入の操作をすると、対応するカート情報の原本および複製が作成される。もし、そのカート情報が浮き候補として検出された場合には、保守サーバに問い合わせてユーザの存在を確認することができる。ユーザが存在していれば、保守サーバは、検出した浮き候補は浮きデータではないとし、例えば、マスタおよびスレーブに対して原本最終アクセス時刻を更新し、カート情報を存続するように指示することができる。
【００３０】
≪サーバの機能構成≫
図５に示すように、サーバ１は、原本最終アクセス時刻取得部１１と、浮き候補決定部１２と、浮き判定要求部１３と、原本最終アクセス時刻確認部１４と、を備え、データ２０を原本または複製として所持している。
【００３１】
原本最終アクセス時刻取得部１１は、サーバ１がデータ２０のマスタである場合には、データ２０の原本への最終的なアクセスがあった時刻である原本最終アクセス時刻を取得する。この取得は、クライアント２からのメッセージの受信に基づいてなされる。マスタとして取得した原本最終アクセス時刻を、特に、「マスタ側原本最終アクセス時刻」と呼ぶ場合がある。マスタ側原本最終アクセス時刻は、サーバ１の記憶部に記憶される。
【００３２】
また、原本最終アクセス時刻取得部１１は、サーバ１がデータ２０のスレーブである場合には、スレーブが所持するデータ２０の複製に紐付けられている原本を所持するマスタから、データ２０の原本最終アクセス時刻を取得する。スレーブとして取得した原本最終アクセス時刻を、特に、「スレーブ側原本最終アクセス時刻」と呼ぶ場合がある。スレーブ側原本最終アクセス時刻は、サーバ１の記憶部に記憶される。
【００３３】
浮き候補決定部１２は、サーバ１がデータ２０のマスタである場合には、マスタ側原本最終アクセス時刻から、データ２０に対して設定した所定の原本有効期間が満了する時までの間に、データ２０の原本へのアクセスが無いときは、データ２０の原本を浮き候補と決定する。決定した原本の浮き候補を「原本浮き候補」と呼ぶ場合がある。原本有効期間は、例えば、オペレータからの操作によって、サーバ１の記憶部に記憶されている。
【００３４】
また、浮き候補決定部１２は、サーバ１がデータ２０のスレーブである場合には、スレーブ側原本最終アクセス時刻から、データ２０に対して設定した所定の複製有効期間が満了する時までの間に、データ２０の原本へのアクセスが無いときは、データ２０の複製を浮き候補と決定する。決定した複製の浮き候補を「複製浮き候補」と呼ぶ場合がある。複製有効期間は、例えば、オペレータからの操作によって、サーバ１の記憶部に記憶されている。
【００３５】
なお、データ２０の各々について、複製有効期間が原本有効期間よりも長くなるように設定されている（図４参照）。このような設定により、複製有効期間を原本有効期間よりも短くしたために複製が原本よりも先に削除されてデータの冗長性が損なわれてしまう、という不都合を回避することができる。
【００３６】
浮き判定要求部１３は、外部の保守サーバに対して、原本浮き候補または複製浮き候補であると決定したデータ２０が浮きデータであるか否かを判定するように要求する。
【００３７】
原本最終アクセス時刻確認部１４は、サーバ１がデータ２０のスレーブである場合には、データ２０について、スレーブ側原本最終アクセス時刻がマスタ側原本最終アクセス時刻と一致しているか否か（原本最終アクセス時刻の整合性）を確認する。例えば、スレーブがマスタに対してマスタ側原本最終アクセス時刻を要求することで、マスタからマスタ側原本最終アクセス時刻を取得し、スレーブ自身が記憶しているスレーブ側原本最終アクセス時刻と比較する、という手順をとるとよい。
また、例えば、スレーブがスレーブ側原本最終アクセス時刻をマスタに送信し、送信したスレーブ側原本最終アクセス時刻とマスタ自身が記憶しているマスタ側原本最終アクセス時刻との比較をマスタに要求し、その比較の結果をマスタから取得する、という手順でもよい。
また、例えば、クライアント２からの原本へのアクセスを契機にしてマスタ側原本最終アクセス時刻を更新したマスタがマスタ側原本最終アクセス時刻をスレーブに送信することで、スレーブが、自身で記憶しているスレーブ側原本最終アクセス時刻と、マスタから受信したマスタ側原本最終アクセス時刻とを比較する、という手順でもよい。
【００３８】
データ２０は、データ本体２１およびデータ管理情報２２を有している。データ本体２１はクライアント２に提供するサービスの内容を含むデータである。データ管理情報２２は、データ本体２１のメタデータである。
【００３９】
図６に示すように、データ管理情報２２は、「データ識別子」、「マスタ識別子」、「スレーブ識別子」、「原本最終アクセス時刻」、「原本有効期間」、「複製有効期間」、「浮き候補通知フラグ」、「浮き候補通知先」、「原本最終アクセス時刻整合確認フラグ」、といった項目を有しており、項目ごとにさまざまな値が格納される。
【００４０】
「データ識別子」という項目に対して、データ２０を識別するＩＤ（Identifier）を示す値が格納される。
「マスタ識別子」という項目に対して、データ２０を原本として所持するマスタとして機能するサーバ１を識別する値、例えば、サーバ１のＩＰ（Internet Protocol）アドレスが格納される。
「スレーブ識別子」という項目に対して、データ２０を複製として所持するマスタとして機能するサーバ１を識別する値、例えば、サーバ１のＩＰアドレスが格納される。格納される値は、データ２０の冗長度に相当する個数だけ存在する。
【００４１】
「原本最終アクセス時刻」という項目に対して、データ２０の原本への最終的なアクセスがあった時刻を示す値が格納される。サーバ１がデータ２０のマスタである場合には、前記値は、マスタ側原本最終アクセス時刻である。サーバ１がデータ２０のスレーブである場合には、前記値は、スレーブ側原本最終アクセス時刻である。
「原本有効期間」という項目に対して、データ２０の原本に対して設定した原本有効期間ＴＯを示す値が格納される。原本有効期間ＴＯの始点は、原本最終アクセス時刻である。原本有効期間ＴＯは、例えば、サーバ１の入力部からの入力により設定される。
「複製有効期間」という項目に対して、データ２０の複製に対して設定した複製有効期間ＴＲを示す値が格納される。複製有効期間ＴＲの始点は、原本最終アクセス時刻である。複製有効期間ＴＲは、例えば、サーバ１の入力部からの入力により設定される。
【００４２】
「浮き候補通知フラグ」という項目に対して、浮き候補決定部１２が決定した浮き候補を、浮き候補が浮きデータであるか否かを判定する保守サーバに通知することを示す値（オン）、または通知しないことを示す値（オフ）が格納される。保守サーバは、浮き候補決定部１２が決定した浮き候補の通知先である。また、浮き候補通知フラグがオンである場合には、浮き判定要求部１３による要求がなされ、オフである場合には、浮き判定要求部１３による要求がなされない。
【００４３】
「浮き候補通知先」という項目に対して、浮き候補が浮きデータであるか否かを判定する保守サーバを識別する値、例えば、保守サーバのＩＰアドレスが格納される。
【００４４】
「原本最終アクセス時刻整合確認フラグ」という項目に対して、サーバ１がデータ２０のスレーブである場合に、データ２０について、スレーブ側原本最終アクセス時刻がマスタ側原本最終アクセス時刻と一致していることを確認することを示す値（オン）、または確認しないことを示す値（オフ）が格納される。また、原本最終アクセス時刻整合確認フラグがオンである場合には、原本最終アクセス時刻確認部１４による確認がなされ、オフである場合には、原本最終アクセス時刻確認部１４による確認がなされない。
【００４５】
≪処理≫
本実施形態で実行される浮きチェックの処理について説明する。この処理の主体は、サーバ１の制御部であるが、説明の便宜上、「制御部」という言葉は省略する。
【００４６】
［原本の浮きチェック］
まず、図７を参照して、サーバ１がマスタとして実行する原本の浮きチェックの処理について説明する。この処理は、後記する開始契機を迎えた場合に開始し、ステップＳ１０１に進む。
【００４７】
ステップＳ１０１において、サーバ１は、自身が所持している原本のうち、原本の各々に設定されている原本有効期間を経過した原本があるか否かを判定する。この判定は、原本最終アクセス時刻取得部１１が取得してデータ管理情報２２に書き込まれた原本最終アクセス時刻を始点とする原本有効期間の満了時までに、クライアント２からのアクセスが無かった否か、という判定である。原本有効期間を経過した原本が無い場合には（Ｎｏ）、そのような原本が出現するまでこの判定を継続する。一方、原本有効期間を経過した原本がある場合には（Ｙｅｓ）、その原本の原本有効期間の満了時までにアクセスは無かったことを意味しており、ステップＳ１０２に進む。
【００４８】
ステップＳ１０２において、サーバ１は、浮き候補決定部１２の機能により、原本有効期間を経過した原本を原本浮き候補として決定する。ステップＳ１０２の後、ステップＳ１０３に進む。
【００４９】
ステップＳ１０３において、サーバ１は、原本浮き候補となった原本のデータ管理情報２２を参照して、浮き候補通知フラグがオンであるか否かを判定する。オンである場合には（Ｙｅｓ）、原本浮き候補のことを保守サーバに通知することを意味しており、ステップＳ１０４に進む。一方、オンでない場合には、浮き候補通知フラグがオフであって、原本浮き候補のことを保守サーバに通知せずに、原本浮き候補と決定した原本が浮きデータであるとみなすことを意味しており、ステップＳ１０６に進む。
【００５０】
ステップＳ１０４において、サーバ１は、浮き判定要求部１３の機能により、原本浮き候補となった原本が浮きデータであるか否かという浮き判定を保守サーバに要求する。保守サーバは、浮き判定の判定結果を、浮き判定を要求したサーバ１に通知する。ステップＳ１０４の後、ステップＳ１０５に進む。
【００５１】
ステップＳ１０５において、サーバ１は、保守サーバからの通知が「原本は浮きデータである」という通知であったか否かを判定する。「原本は浮きデータである」という通知であった場合（Ｙｅｓ）、原本浮き候補と決定した原本が浮きデータであることが確定したことを意味しており、ステップＳ１０６に進む。一方、「原本は浮きデータである」という通知でなかった場合（Ｎｏ）、原本は浮きデータでないことが確定したことを意味しており、ステップＳ１０９に進む。
【００５２】
ステップＳ１０６において、サーバ１は、浮きデータであると確定した（またはみなした）原本を削除する。ステップＳ１０６の後、ステップＳ１０７に進む。
【００５３】
ステップＳ１０７において、サーバ１は、削除する原本に紐づく複製がスレーブにあるか否かを判定する。浮きデータである原本に紐づく複製は、たとえ複製有効期間を経過していなくても自動的に浮きデータとなり削除するという趣旨である（浮きパターン（１）に該当）。ここで「紐づく」というのは、図７の処理の対象である原本に係るデータ２０に関して、データ管理情報２２のデータ識別子の値、マスタ識別子の値、スレーブ識別子の値が、原本と複製との間で現時刻においてすべて同じである、という意味である。マスタ識別子の値だけ同じである、ということだけでは不十分である。
【００５４】
ここで、マスタ識別子およびスレーブ識別子を用いず、データ識別子だけを用いて、浮いた原本に対応する複製を削除することについて考察する。本実施形態のデータ管理システム１００の運用を継続するにつれて、１つのデータ２０に関して、スレーブは変更せずマスタのみ変更したという場合がある。このような場合、データ管理情報２２上ではスレーブとなっているサーバ１が、原本と同じデータ識別子を有していてもマスタ識別子が異なる（紐づかない）複製を所持する、という事態が生じる。
【００５５】
もし、変更前のマスタが所持している旧原本が浮いた場合、浮いた旧原本を削除することに伴い、マスタ変更前に旧原本に紐づいていた複製まで削除してしまいかねない。しかし、この複製は、マスタ変更後の新原本の複製であるため、削除してはいけない。複製の誤った削除を回避するために、浮いた原本と複製とが紐づいていることを、データ識別子の値、マスタ識別子の値、スレーブ識別子の値をすべて用いて特定する。
【００５６】
なお、図８には、データ識別子がＸであるデータについて、マスタはサーバＢ（旧マスタ）からサーバＡ（新マスタ）に変更され、スレーブはサーバＣ（新旧スレーブ）のままであること、サーバＡが所持する新原本とサーバＣが所持する複製とが現時点では紐づいていること（網掛け）、サーバＢが所持する旧原本が浮いたため削除する際、マスタ変更前では紐づいていたが現時点では紐づいていない複製を削除してはいけないこと、が示されている。
【００５７】
前記したように、ステップＳ１０７の判定は、削除する原本のデータ管理情報２２のデータ識別子、マスタ識別子、スレーブ識別子を参照して実行される。また、この判定は、例えば、ステップＳ１０２の処理の実行後に実行することができる。紐づく複製がスレーブにある場合（Ｙｅｓ）、ステップＳ１０８に進む。紐づく複製がスレーブにない場合（Ｎｏ）、図７の処理を終了する。
【００５８】
ステップＳ１０８において、サーバ１は、紐づく複製を所持するスレーブに対して、その複製の削除を要求する。スレーブは、この要求に応じて、対象となる複製を削除する。ステップＳ１０８の後、図７の処理を終了する。
【００５９】
ステップＳ１０９において、サーバ１は、浮きデータでないことが確定した原本について、原本の原本最終アクセス時刻を更新する。例えば、この更新は、原本最終アクセス時刻取得部１１の機能によって実現することができる。また、原本の原本最終アクセス時刻を、保守サーバから浮き判定の判定結果（つまり「原本は浮きデータでない」）を通知された時刻に更新することができる。この更新により、図７の処理を再度行ったとき、浮きデータでないと判定された原本を即座に原本浮き候補であると決定してしまうことを回避することができる。
なお、保守サーバが前記更新を指示し、サーバ１がその指示の通りに実行するような形態にすることもできる。また、保守サーバがサーバ１に対してする指示は、原本の原本最終アクセス時刻の更新に限られない。
ステップＳ１０９の後、図７の処理を終了する。
【００６０】
図７の処理によれば、所定期間アクセスが無いことから浮いている可能性が高いと予想される原本を浮き候補として抽出することができ、その浮き候補についてのみ浮きデータであるか否かの判定を行うことができる。このため、サーバ１が所持するすべての原本について、浮きデータであるか否かを判定しなければならない、という負担を回避することができる。
【００６１】
［複製の浮きチェック］
まず、図９を参照して、サーバ１がスレーブとして実行する複製の浮きチェックの処理について説明する。この処理は、後記する開始契機を迎えた場合に開始し、ステップＳ２０１に進む。
【００６２】
ステップＳ２０１において、サーバ１は、自身が所持している複製のうち、複製の各々に設定されている複製有効期間を経過した複製があるか否かを判定する。この判定は、原本最終アクセス時刻取得部１１が取得してデータ管理情報２２に書き込まれた原本最終アクセス時刻を始点とする複製有効期間の満了時までに、この複製に対応し、マスタが所持する原本に対して、クライアント２からのアクセスが無かった否か、という判定である。複製有効期間を経過した複製が無い場合には（Ｎｏ）、そのような複製が出現するまでこの判定を継続する。一方、複製有効期間を経過した複製がある場合には（Ｙｅｓ）、その複製の複製有効期間の満了時までに、対応する原本へのアクセスは無かったことを意味しており、ステップＳ２０２に進む。
【００６３】
ステップＳ２０２において、サーバ１は、複製のデータ管理情報２２を参照して、原本最終アクセス時刻整合確認フラグがオンであるか否かを判定する。オンである場合には、サーバ１が所持している複製のデータ２０について、スレーブ側原本最終アクセス時刻がマスタ側原本最終アクセス時刻と一致していることを確認することを意味しており、ステップＳ２０３に進む。一方、オンでない場合には、前記確認をしない（マスタからスレーブに原本最終アクセス時刻は確実に送信されており、スレーブ側原本最終アクセス時刻がマスタ側原本最終アクセス時刻と一致していると信用する）ことを意味しており、ステップＳ２０６に進む。
【００６４】
ステップＳ２０３において、サーバ１は、複製に紐づく原本がマスタにあるか否かを判定する。ここで「紐づく」というのは、図９の処理の対象である複製に係るデータ２０に関して、データ管理情報２２のデータ識別子の値、マスタ識別子の値、スレーブ識別子の値が、原本と複製との間で現時刻においてすべて同じである、という意味である。マスタ識別子の値だけ同じである、ということだけでは不十分である。
【００６５】
ここで、マスタ識別子およびスレーブ識別子を用いず、データ識別子だけを用いて原本を特定することについて考察する。本実施形態のデータ管理システム１００の運用を継続するにつれて、１つのデータ２０に関して、マスタは変更せずスレーブのみ変更したという場合がある。このような場合、データ管理情報２２上ではマスタとなっているサーバ１が、複製と同じデータ識別子を有していてもスレーブ識別子が異なる（紐づかない）原本を所持する、という事態が生じる。
【００６６】
変更前のスレーブが所持している旧複製は、結果的に浮きデータになるので、たとえこの旧複製の複製有効期間をまだ経過していないとしても削除すべきである。しかし、データ識別子だけを用いて旧複製に対応する原本を特定してしまうと、その原本を所持するマスタは、原本へのアクセスがあったときに、原本最終アクセス時刻を、旧複製を所持するスレーブに送信してしまう。その結果、旧複製のデータ管理情報２２のスレーブ側原本最終アクセス時刻が絶えず最新の時刻に反映され続けてしまい、旧複製の複製有効期間を経過することは無く、浮きデータとして削除する機会を失ってしまう。このようなスレーブ側原本最終アクセス時刻の誤った反映を回避するために、図９の処理の対象である複製と原本とが紐づいていることを、データ識別子の値、マスタ識別子の値、スレーブ識別子の値をすべて用いて特定する。
なお、マスタが、原本のデータ管理情報２２のデータ識別子の値、マスタ識別子の値、スレーブ識別子の値をすべて用いて、原本に紐づいた複製を所持するスレーブを、原本最終アクセス時刻を送信すべきスレーブとして特定するようにしてもよい。
【００６７】
図１０には、データ識別子がＸであるデータについて、スレーブはサーバＢ（旧スレーブ）からサーバＡ（新スレーブ）に変更され、マスタはサーバＣ（新旧マスタ）のままであること、サーバＡが所持する新複製とサーバＣが所持する原本とが現時点では紐づいていること（網掛け）、サーバＢが所持する旧複製に対して、スレーブ変更前では紐づいていたが現時点では紐づいていない原本を所持するサーバＣが原本最終アクセス時刻を反映し続けてしまうこと、が示されている。
【００６８】
前記したように、ステップＳ２０３の判定は、図９の処理の対象である複製のデータ管理情報２２のデータ識別子、マスタ識別子、スレーブ識別子を参照して実行される。紐づく原本がマスタにある場合（Ｙｅｓ）、ステップＳ２０４に進む。紐づく複製がマスタにない場合（Ｎｏ）、例えば、原本から孤立して当然に削除すべき複製であるため、スレーブ側原本最終アクセス時刻がマスタ側原本最終アクセス時刻と一致していることを確認する必要が無いと判断したことを意味しており、ステップＳ２０６に進む。
【００６９】
ステップＳ２０４において、サーバ１は、原本最終アクセス時刻確認部１４の機能により、原本最終アクセス時刻の整合がとれているか否かを判定する。つまり、図９の処理の対象である複製のデータ２０について、スレーブ側原本最終アクセス時刻がマスタ側原本最終アクセス時刻と一致しているか否かを判定する。整合がとれていない場合（Ｎｏ）、サーバ１が記憶しているスレーブ側原本最終アクセス時刻が間違っていることを意味しており、ステップＳ２０５に進む。一方、整合がとれている場合（Ｙｅｓ）、サーバ１が記憶しているスレーブ側原本最終アクセス時刻に間違いは無いことを意味しており、ステップＳ２０６に進む。
【００７０】
ステップＳ２０５において、サーバ１は、複製に対する原本最終アクセス時刻を整合化する。例えば、スレーブであるサーバ１が、原本最終アクセス時刻取得部１１の機能により、マスタに問い合わせてマスタ側原本最終アクセス時刻を取得し、サーバ１が記憶しているスレーブ側原本最終アクセス時刻を、マスタ側原本最終アクセス時刻と一致するように更新する。また、オペレータがサーバ１の入力部からの入力により、スレーブ側原本最終アクセス時刻をマスタ側原本最終アクセス時刻と一致するように更新してもよい。ステップＳ２０５の後、図９の処理を終了する。
【００７１】
ステップＳ２０６において、サーバ１は、浮き候補決定部１２の機能により、複製有効期間を経過した複製を複製浮き候補として決定する。ステップＳ２０６の後、ステップＳ２０７に進む。
【００７２】
ステップＳ２０７において、サーバ１は、複製浮き候補となった複製のデータ管理情報２２を参照して、浮き候補通知フラグがオンであるか否かを判定する。オンである場合には（Ｙｅｓ）、複製浮き候補のことを保守サーバに通知することを意味しており、ステップＳ２０８に進む。一方、オンでない場合には、浮き候補通知フラグがオフであって、複製浮き候補のことを保守サーバに通知せずに、複製浮き候補と決定した複製が浮きデータであるとみなすことを意味しており、ステップＳ２１０に進む。
【００７３】
ステップＳ２０８において、サーバ１は、浮き判定要求部１３の機能により、複製浮き候補となった複製が浮きデータであるか否かという浮き判定を保守サーバに要求する。保守サーバは、浮き判定の判定結果を、浮き判定を要求したサーバ１に通知する。ステップＳ２０８の後、ステップＳ２０９に進む。
【００７４】
ステップＳ２０９において、サーバ１は、保守サーバからの通知が「複製は浮きデータである」という通知であったか否かを判定する。「複製は浮きデータである」という通知であった場合（Ｙｅｓ）、複製浮き候補と決定した複製が浮きデータであることが確定したことを意味しており、ステップＳ２１０に進む。一方、「複製は浮きデータである」という通知でなかった場合（Ｎｏ）、複製は浮きデータでないことが確定したことを意味しており、ステップＳ２１１に進む。
【００７５】
ステップＳ２１０において、サーバ１は、浮きデータであると確定した（またはみなした）複製を削除する。ステップＳ２１０の後、図９の処理を終了する。
【００７６】
ステップＳ２１１において、サーバ１は、浮きデータでないことが確定した複製について、複製の原本最終アクセス時刻を更新する。例えば、この更新は、原本最終アクセス時刻取得部１１の機能によって実現することができる。また、複製の原本最終アクセス時刻を、保守サーバから浮き判定の判定結果（つまり「複製は浮きデータでない」）を通知された時刻に更新することができる。この更新により、図９の処理を再度行ったとき、浮きデータでないと判定された複製を即座に複製浮き候補であると決定してしまうことを回避することができる。
なお、保守サーバが前記更新を指示し、サーバ１がその指示の通りに実行するような形態にすることもできる。また、保守サーバがサーバ１に対してする指示は、複製の原本最終アクセス時刻の更新に限られない。
ステップＳ２１１の後、図９の処理を終了する。
【００７７】
図９の処理によれば、所定期間アクセスが無いことから浮いている可能性が高いと予想される複製を浮き候補として抽出することができ、その浮き候補についてのみ浮きデータであるか否かの判定を行うことができる。このため、サーバ１が所持するすべての複製について、浮きデータであるか否かを判定しなければならない、という負担を回避することができる。
【００７８】
≪実施例≫
本実施形態は、図７を参照して説明した原本の浮きチェック、および図９を参照して説明した複製の浮きチェックを実行するためにさまざまな動作契機を提供することができる。
【００７９】
＜例１＞
例えば、原本の浮きチェックは、原本生成時に、原本ごとに実行することができ、図１１にその処理を示す。なお、原本生成後であっても必要なときにこの処理を実行することは可能である。図１１の処理を開始すると、ステップＳ３０１に進む。
【００８０】
ステップＳ３０１において、マスタであるサーバ１は、原本のデータ管理情報２２を参照して、原本有効期間が設定されているか否かを判定する。原本有効期間が設定されていない場合には（Ｎｏ）、この原本は、本実施形態の処理の対象外であり、図１１の処理を終了する。一方、原本有効期間が設定されている場合には（Ｙｅｓ）、ステップＳ３０２に進む。
【００８１】
ステップＳ３０２において、サーバ１は、周知のタイマを用いることで、設定されている原本有効期間の満了時にタイマを設定する。ステップＳ３０２の後、ステップＳ３０３に進む。
【００８２】
ステップＳ３０３において、サーバ１は、処理対象の原本について、原本有効期間の満了前に、原本へのアクセスがあったか否かを判定する。アクセスが無かった場合（Ｎｏ）、タイマが満了したことを意味しており、ステップＳ１０２に進む。一方、アクセスがあった場合（Ｙｅｓ）、原本が浮きデータではないとみなし、ステップＳ１０９に進む。
【００８３】
図１１に示したステップＳ１０２〜ステップＳ１０９の処理は、図７に示したステップＳ１０２〜ステップＳ１０９の処理と同等であるので説明を省略する。
【００８４】
図１１の処理によれば、生成された原本に対して、原本ごとに浮きチェックを行うことができる。
【００８５】
＜例２＞
他にも、原本の浮きチェックは、すべての原本に対して共通した処理を定期的に実行することができ、図１２にその処理を示す。図１２の処理を開始すると、ステップＳ４０１に進む。
【００８６】
ステップＳ４０１において、マスタであるサーバ１は、記憶しているデータ２０のうち、原本として所持し、原本有効期間が設定されているデータ２０を抽出する。具体的には、サーバ１は、データ管理情報２２のマスタ識別子の値が、自身のサーバ１を識別する値であり、かつ、データ管理情報２２の原本有効期間の値が存在する原本を抽出する。抽出されたデータ２０は、記憶部のルックアップテーブルに一時的に記憶される。
以下、サーバ１は、抽出した原本ごとに、後記するステップＳ４０２およびステップＳ１０２〜ステップＳ１０９の処理からなるループ処理を実行する。このループ処理では、まず、ステップＳ４０２に進む。
【００８７】
ステップＳ４０２において、マスタであるサーバ１は、対象の原本について、現時刻が、原本有効期間を経過したか否かを判定する。原本有効期間を経過した場合（Ｙｅｓ）、ステップＳ１０２に進む。原本有効期間を経過していない場合（Ｎｏ）、対象の原本については、ループ処理を終了し、抽出された他の原本について同じループ処理を繰り返す。
【００８８】
図１２に示したステップＳ１０２〜ステップＳ１０９の処理は、図７に示したステップＳ１０２〜ステップＳ１０９の処理と同等であるので説明を省略する。ただし、ステップＳ１０７でＮｏの場合、ステップＳ１０８の後、ステップＳ１０９の後では、その原本に関するループ処理を終了し、抽出された他の原本について同じループ処理を繰り返す。すべての抽出された原本についてループ処理を終了すると、図１２の処理を終了する。
【００８９】
図１２の処理によれば、原本有効期間が設定された原本に対して、浮きチェックを一括して行うことができる。
【００９０】
＜例３＞
一方、複製の浮きチェックは、複製生成時に、複製ごとに実行することができ、図１３にその処理を示す。なお、複製生成後であっても必要なときにこの処理を実行することは可能である。図１３の処理を開始すると、ステップＳ５０１に進む。
【００９１】
ステップＳ５０１において、スレーブであるサーバ１は、複製のデータ管理情報２２を参照して、複製有効期間が設定されているか否かを判定する。複製有効期間が設定されていない場合には（Ｎｏ）、この複製は、本実施形態の処理の対象外であり、図１３の処理を終了する。一方、複製有効期間が設定されている場合には（Ｙｅｓ）、ステップＳ５０２に進む。
【００９２】
ステップＳ５０２において、サーバ１は、周知のタイマを用いることで、設定されている複製有効期間の満了時にタイマを設定する。ステップＳ５０２の後、ステップＳ５０３に進む。
【００９３】
ステップＳ５０３において、サーバ１は、処理対象の複製について、複製有効期間の満了前に、この複製のデータ管理情報の原本最終アクセス時刻の更新があったか否かを判定する。更新が無かった場合（Ｎｏ）、タイマが満了したことを意味しており、ステップＳ２０２に進む。一方、更新があった場合（Ｙｅｓ）、複製有効期間の満了時が繰り下がることを意味し、ステップＳ５０２に戻る。
【００９４】
図１３に示したステップＳ２０２〜ステップＳ２１１の処理は、図９に示したステップＳ２０２〜ステップＳ２１１の処理と同等であるので説明を省略する。ただし、ステップＳ２０５において、複製に対する原本最終アクセス時刻を整合化した後、複製有効期間の満了時が繰り下がるため、ステップＳ５０２に戻る。
【００９５】
図１３の処理によれば、生成された複製に対して、複製ごとに浮きチェックを行うことができる。
【００９６】
＜例４＞
他にも、複製の浮きチェックは、すべての複製に対して共通した処理を定期的に実行することができ、図１４にその処理を示す。図１４の処理を開始すると、ステップＳ６０１に進む。
【００９７】
ステップＳ６０１において、スレーブであるサーバ１は、記憶しているデータ２０のうち、複製として所持し、複製有効期間が設定されているデータ２０を抽出する。具体的には、サーバ１は、データ管理情報２２のスレーブ識別子の値が、自身のサーバ１を識別する値であり、かつ、データ管理情報２２の複製有効期間の値が存在する複製を抽出する。抽出されたデータ２０は、記憶部のルックアップテーブルに一時的に記憶される。
以下、サーバ１は、抽出した複製ごとに、後記するステップＳ２０２〜ステップＳ２１１の処理からなるループ処理を実行する。
【００９８】
図１４に示したステップＳ２０２〜ステップＳ２１１の処理は、図９に示したステップＳ２０２〜ステップＳ２１１の処理と同等であるので説明を省略する。ただし、ステップＳ２０５の後、ステップＳ２１０の後、ステップＳ２１１の後では、その複製に関するループ処理を終了し、抽出された他の複製について同じループ処理を繰り返す。すべての抽出された複製についてループ処理を終了すると、図１４の処理を終了する。
【００９９】
図１４の処理によれば、複製有効期間が設定された複製に対して、浮きチェックを一括して行うことができる。
【０１００】
＜例５＞
他にも、複製の浮きチェックは、まず、すべての複製に対して、原本と複製との間の原本最終アクセス時刻の整合性をとる処理を定期的に実行し（定期整合）、その後、すべての複製に対して共通した処理を定期的に実行することができ、図１５にその処理を示す。図１５の処理は、定期整合後に開始し、ステップＳ６０１に進む。
【０１０１】
図１５に示したステップＳ６０１の処理は、図１３に示したステップＳ６０１の処理と同等であるので説明を省略する。
以下、サーバ１は、抽出した複製ごとに、後記するステップＳ７０１およびステップＳ２０６〜ステップＳ２１１の処理からなるループ処理を実行する。このループ処理では、まず、ステップＳ７０１に進む。
【０１０２】
ステップＳ７０１において、スレーブであるサーバ１は、対象の複製について、現時刻が、複製有効期間を経過したか否かを判定する。複製有効期間を経過した場合（Ｙｅｓ）、ステップＳ２０６に進む。複製有効期間を経過していない場合（Ｎｏ）、対象の複製については、ループ処理を終了し、抽出された他の複製について同じループ処理を繰り返す。
【０１０３】
図１５に示したステップＳ２０６〜ステップＳ２１１の処理は、図９に示したステップＳ２０６〜ステップＳ２１１の処理と同等であるので説明を省略する。ただし、ステップＳ２０７でＮｏの場合、ステップＳ２１０の後、ステップＳ２１１の後では、その複製に関するループ処理を終了し、抽出された他の複製について同じループ処理を繰り返す。すべての抽出された複製についてループ処理を終了すると、図１５の処理を終了する。
【０１０４】
図１５の処理によれば、最初に、原本と複製との間の原本最終アクセス時刻について整合をとった後、複製有効期間が設定された複製に対して、浮きチェックを一括して行うことができる。
【０１０５】
≪まとめ≫
本実施形態によれば、原本へのアクセスに期限を設けた浮きチェックを実現する。この浮きチェックでは、１つのデータの原本および複製に対して原本最終アクセス時刻を共通指標とすることで、原本と複製との間の、原本へのアクセスに関する整合性を保持する。そして、原本最終アクセス時刻を始点とする、原本有効期間内および複製有効期間内の原本へのアクセスの有無を判定し、前記アクセスが無い原本または複製を浮き候補とする。原本へのアクセスがあれば、原本最終アクセス時刻は更新される。浮き候補が浮きデータであるか否かの判定は、外部に要求することもできるし、サーバ自身で行うこともできる。原本および複製が浮きデータであると確定すれば、サーバ１は、その原本および複製を削除する。
このように、本実施形態は、浮きデータを検出するためにまず、所定期間内のアクセスの有無の観点から浮きデータである可能性の高い浮き候補を決定することを特徴とする。したがって、マスタスレーブ型のデータ管理システムにおいて、浮きデータの検出を容易にすることができる。
【０１０６】
また、複製有効期間は、原本有効期間よりも長いので、複製有効期間を原本有効期間よりも短くしたために複製が原本よりも先に削除されてデータの冗長性が損なわれてしまう、という不都合を回避することができる。
【０１０７】
また、サーバ１が浮き判定要求部１３を備えることで、浮きデータであるか否かを判定可能な保守サーバを利用することによって、対象のデータの特性、重要度に合わせて浮きデータを間違いなく削除することができる。
【０１０８】
また、サーバ１が原本最終アクセス時刻確認部１４を備えることで、スレーブ側原本最終アクセス時刻の更新の遅延または失敗に起因する複製の誤削除を回避することができる。データ管理システム１００上の不具合により、スレーブがマスタから原本最終アクセス時刻を取得できていない場合がある。この場合、スレーブ側原本最終アクセス時刻の更新が遅延または失敗し、スレーブが記憶しているスレーブ側原本最終アクセス時刻は、更新が繰り返されたマスタ側原本最終アクセス時刻よりも前となってしまい、複製有効期間の満了時が固定してしまう。その結果、本来よりも早いタイミングで複製を複製浮き候補と決定してしまい、複製の誤削除に到る可能性がある。本実施形態によれば、スレーブ側原本最終アクセス時刻をマスタ側原本最終アクセス時刻に一致させた上で複製の浮きチェックを行うことができるので、前記可能性を排除することができる。
【０１０９】
≪その他≫
保守サーバが有する、データが浮きデータであるか否かを判定可能な手段を、サーバ１に備え、浮き候補決定部１２が決定した浮き候補に対する浮き判断をサーバ１の内部で行うようにしてもよい。
【０１１０】
また、原本有効期間の大きさおよび複製有効期間の大きさの妥当性を判定する手段を、サーバ１に備えてもよい。この手段は、例えば、クライアント２からの原本へのアクセスの履歴を記録し、アクセス間隔の平均値を算出し、算出した平均値を用いて前記妥当性を判定することができる。妥当でない場合、前記手段は、例えば、原本有効期間および複製有効期間の再設定をオペレータに要求することができる。
【０１１１】
また、図１の構成において、振り分け装置４とサーバ１とを別装置として記載したが、同一サーバ上で別々の機能として動作させる形態も可能である。また、ロードバランサ３を備えず、クライアント２から任意の振り分け装置４にメッセージを送信する形態も可能である。また、振り分け装置４を備えず、サーバ１が、ロードバランサ３から担当外のメッセージを受け取った場合には、担当の別サーバ１にメッセージを渡す形態も可能である。
【０１１２】
また、データ管理システム１００を構成するサーバ１は、物理サーバであってもよいし、仮想化技術を用いて生成した仮想サーバであってもよい。
【０１１３】
また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【０１１４】
１        サーバ
２        クライアント
３        ロードバランサ
４        振り分け装置
１１      原本最終アクセス時刻取得部
１２      浮き候補決定部
１３      浮き判定要求部
１４      原本最終アクセス時刻確認部
２０      データ
２１      データ本体
２２      データ管理情報
１００    データ管理システム
１０００  分散処理システム
【図１】
0005864656.tif 000002
【図２】
0005864656.tif 000003
【図３】
0005864656.tif 000004
【図４】
0005864656.tif 000005
【図５】
0005864656.tif 000006
【図６】
0005864656.tif 000007
【図７】
0005864656.tif 000008
【図８】
0005864656.tif 000009
【図９】
0005864656.tif 000010
【図１０】
0005864656.tif 000011
【図１１】
0005864656.tif 000012
【図１２】
0005864656.tif 000013
【図１３】
0005864656.tif 000014
【図１４】
0005864656.tif 000015
【図１５】
0005864656.tif 000016