(57)【要約】【課題】コミットログファイルを一元管理し、不要になったコミットログを削除する契機を判定して削除するログファイル管理装置を提供する。【解決手段】クライアント装置１からレコードデータの更新要求を受け付ける要求受付部２と、コミットログを生成するコミットログ生成部３と、コミットログ記憶部８へ永続化し、レコード集合毎に、所定のタイミングのレコードデータをレコードデータ記憶部６からチェックポイントとして取得して永続化した時点を比較し、最も古くチェックポイントが永続化された時点以前のコミットログを不要となったコミットログとして削除を指示する更新実行部４と、チェックポイントを取得して永続化してチェックポイント記憶部９に記憶するチェックポイント取得部６と、不要となったコミットログを削除するコミットログ制御部５とを備える。【選択図】図１
2010277473.tif 000002
【特許請求の範囲】
【請求項１】
レコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成し、管理するログファイル管理装置であって、
前記共有ファイルを記憶するコミットログ記憶部と、
クライアント装置から前記レコードデータの更新要求を受け付ける要求受付部と、
前記更新要求に基づいて前記コミットログを生成し、このコミットログを前記共有ファイルへ永続化するコミットログ生成部と、
レコードデータ記憶部に記憶されるレコードデータを、任意のタイミングでチェックポイントとして取得して永続化し、各レコード集合毎に、チェックポイントが取得された時点を比較し、最も古いチェックポイントが取得された以前の前記コミットログを不要なコミットログとして削除を指示する更新実行部と、
前記任意のタイミングのレコードデータを前記レコードデータ記憶部からチェックポイントとして取得して永続化してチェックポイント記憶部に記憶するチェックポイント取得部と、
前記更新実行部からの指示に基づき、前記共有ファイルに蓄積されたコミットログから、前記チェックポイント取得時以前のコミットログを削除するコミットログ制御部とを備える
ことを特徴とするログファイル管理装置。
【請求項２】
前記コミットログ生成部は、前記コミットログを生成した順に、前記共有ファイルに蓄積し、その共有ファイルが複数からなる場合、
前記コミットログ制御部は、前記コミットログを削除するとき、前記共有ファイルのうち、当該共有ファイルの最新のコミットログが前記最も古いチェックポイントの取得時点よりも古い共有ファイルを、ファイル単位で削除する
ことを特徴とする請求項１に記載のログファイル管理装置。
【請求項３】
ノード間で共有するレコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成し、管理するログファイル管理システムであって、
クライアント装置から前記レコードデータの更新要求を受け付けて当該レコードデータの更新処理を行うマスタのログファイル管理装置と、当該マスタのログファイル管理装置の当該レコードデータの更新に対応して、当該同一のレコードデータを複製し更新するレプリカのログファイル管理装置とを備え、
前記ログファイル管理装置はそれぞれ、
前記共有ファイルを記憶するコミットログ記憶部と、
クライアント装置から前記レコードデータの更新要求を受け付ける要求受付部と、
前記更新要求に基づいて前記コミットログを生成し、このコミットログを前記共有ファイルへ永続化するコミットログ生成部と、
前記各レコード集合に対する前記共有ファイルに蓄積されたコミットログが所定の範囲にあるか否かを判定し、当該コミットログが所定の範囲を超えたときは、当該所定の範囲を超えたコミットログを不要なコミットログとして削除を指示する更新実行部と、
前記レコードデータを前記レコードデータ記憶部からチェックポイントとして取得してチェックポイント記憶部に記憶するチェックポイント取得部と、
前記更新実行部からの指示に基づき、前記共有ファイルに蓄積されたコミットログから不要なコミットログを削除するコミットログ制御部と、
他のログファイル管理装置との間で通信を行う通信制御部とを備え、
自身のログファイル管理装置が前記マスタのログファイル管理装置であるとき、前記ログファイル管理装置は、さらに、
前記レプリカのログファイル管理装置それぞれへ、当該マスタのログファイル管理装置におけるレコードデータの更新に対応して、当該同一のレコードデータを複製し、更新するよう要求するレプリケーション要求を送信し、当該レプリカのログファイル管理装置それぞれから、前記レプリケーション要求に基づくレコードデータ更新に関するコミットログの永続化が完了した旨の応答を受信するレプリケーション制御部を備え、
前記所定の範囲を示す値として、前記マスタ及び前記レプリカのログファイル管理装置は同一の値を用いる
ことを特徴とするログファイル管理システム。
【請求項４】
ノード間で共有するレコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成し、管理するログファイル管理システムであって、
クライアント装置から前記レコードデータの更新要求を受け付けて当該レコードデータの更新処理を行うマスタのログファイル管理装置と、当該マスタのログファイル管理装置の当該レコードデータの更新に対応して、当該同一のレコードデータを複製し更新するレプリカのログファイル管理装置とを備え、
前記ログファイル管理装置は、
前記共有ファイルを記憶するコミットログ記憶部と、
前記クライアント装置から前記レコードデータの更新要求を受け付ける要求受付部と、
前記更新要求に基づいて前記コミットログを生成し、このコミットログを前記共有ファイルへ永続化するコミットログ生成部と、
前記各レコード集合に対する前記共有ファイルに蓄積されたコミットログのうち不要なコミットログの削除を指示する更新実行部と、
前記レコードデータを前記レコードデータ記憶部からチェックポイントとして取得してチェックポイント記憶部に記憶するチェックポイント取得部と、
前記更新実行部からの指示に基づき、前記共有ファイルに蓄積されたコミットログから、前記最も古いチェックポイント取得時以前のコミットログを削除するコミットログ制御部と、
他のログファイル管理装置との間で通信を行う通信制御部とを備え、
自身のログファイル管理装置が前記マスタのログファイル管理装置であるとき、前記ログファイル管理装置は、さらに、
前記レプリカのログファイル管理装置それぞれへ、当該マスタのログファイル管理装置におけるレコードデータの更新に対応して、当該同一のレコードデータを複製し、更新するよう要求するレプリケーション要求を送信し、当該レプリカのログファイル管理装置それぞれから、前記レプリケーション要求に基づくレコードデータ更新に関するコミットログの永続化が完了した旨の応答を受信するレプリケーション制御部を備え、
前記マスタのログファイル管理装置の更新実行部は、
前記レプリカのログファイル管理装置が有するコミットログのうち、最も古いコミットログを選定し、当該コミットログ以前に生成されたコミットログを不要なコミットログとして削除する旨を前記レプリカのログファイル管理装置ヘ通知すると共に自身のファイルログ管理装置が有する当該コミットログを削除し、
前記レプリカのログファイル管理装置の更新実行部は、前記通知に基づいて前記コミットログを削除する
ことを特徴とするログファイル管理システム。
【請求項５】
請求項３に記載のログファイル管理システムに用いられる前記ログファイル管理装置。
【請求項６】
請求項４に記載のログファイル管理システムに用いられる前記ログファイル管理装置。
【請求項７】
レコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成し、管理するログファイル管理装置に用いるログファイル管理方法であって、
前記ログファイル管理装置は、
クライアント装置から前記レコードデータの更新要求を要求受付部により受け付けるステップと、
前記更新要求に基づいて前記コミットログを生成し、当該コミットログを前記共有ファイルを有するコミットログ記憶部へ永続化するステップと、
レコードデータ記憶部に記憶されるレコードデータを、任意のタイミングでチェックポイントとして取得して永続化し、チェックポイント記憶部に記憶するステップと、
各レコード集合毎に、前記チェックポイントが取得された時点を比較し、最も古いチェックポイントが取得された時点以前の前記コミットログを不要なコミットログとして削除するステップとを備える
ことを特徴とするログファイル管理方法。
【請求項８】
ノード間で共有するレコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成して管理し、クライアント装置から前記レコードデータの更新要求を受け付けて当該レコードデータの更新処理を行うマスタのログファイル管理装置と、当該マスタのログファイル管理装置の当該レコードデータの更新に対応して、当該同一のレコードデータを複製し更新するレプリカのログファイル管理装置とを備えるログファイル管理システムのログファイル管理装置に用いるログファイル管理方法であって、
前記ログファイル管理装置は、
前記クライアント装置から前記レコードデータの更新要求を受け付けるステップと、
前記更新要求に基づいて前記コミットログを生成し、このコミットログを前記共有ファイルへ永続化するステップと、
前記各レコード集合に対する前記共有ファイルに蓄積されたコミットログが所定の範囲にあるか否かを判定するステップと、
前記コミットログが所定の範囲を超えたときは、当該所定の範囲を超えたコミットログを不要なコミットログとして削除するステップと、
前記レコードデータを前記レコードデータ記憶部からチェックポイントとして取得してチェックポイント記憶部に記憶するステップと、
自身のログファイル管理装置が前記マスタのログファイル管理装置であるとき、前記ログファイル管理装置は、さらに、
前記レプリカのログファイル管理装置それぞれへ、当該マスタのログファイル管理装置におけるレコードデータの更新に対応して、当該同一のレコードデータを複製し、更新するよう要求するレプリケーション要求を送信し、当該レプリカのログファイル管理装置それぞれから、前記レプリケーション要求に基づくレコードデータ更新に関するコミットログの永続化が完了した旨の応答を受信するステップとを備え、
前記所定の範囲を示す値として、前記マスタ及び前記レプリカのログファイル管理装置は同一の値を用いる
ことを特徴とするログファイル管理方法。
【請求項９】
ノード間で共有するレコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成して管理し、クライアント装置から前記レコードデータの更新要求を受け付けて当該レコードデータの更新処理を行うマスタのログファイル管理装置と、当該マスタのログファイル管理装置の当該レコードデータの更新に対応して、当該同一のレコードデータを複製し更新するレプリカのログファイル管理装置とを備えるログファイル管理システムのログファイル管理装置に用いるログファイル管理方法であって、
前記ログファイル管理装置は、
クライアント装置から前記レコードデータの更新要求を受け付けるステップと、
前記更新要求に基づいて前記コミットログを生成し、このコミットログを前記共有ファイルへ永続化するステップと、
前記各レコード集合に対する前記共有ファイルに蓄積されたコミットログのうち不要なコミットログを削除するステップと、
前記レコードデータを前記レコードデータ記憶部からチェックポイントとして取得してチェックポイント記憶部に記憶するステップと、
前記レプリカのログファイル管理装置それぞれへ、当該マスタのログファイル管理装置におけるレコードデータの更新に対応して、当該同一のレコードデータを複製し、更新するよう要求するレプリケーション要求を送信し、当該レプリカのログファイル管理装置それぞれから、前記レプリケーション要求に基づくレコードデータ更新に関するコミットログの永続化が完了した旨の応答を受信するステップと、
自身のログファイル管理装置が前記マスタのログファイル管理装置であるとき、前記ログファイル管理装置は、さらに、
前記レプリカのログファイル管理装置が有するコミットログのうち、最も古いコミットログを選定し、当該コミットログ以前に生成されたコミットログを不要なコミットログとして削除する旨を前記レプリカのログファイル管理装置ヘ通知すると共に自身のファイルログ管理装置が有する当該コミットログを削除するステップと、
前記レプリカのログファイル管理装置のコミットログ制御部は、前記通知に基づいて前記コミットログを削除するステップとを備える
ことを特徴とするログファイル管理方法。
【請求項１０】
請求項７乃至９のいずれか１項に記載のログファイル管理方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、レコードデータの更新作業に基づいて、レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成し、不要となったコミットログを削除する契機を同期する技術に関する。
【背景技術】
【０００２】
従来、分散システムにおけるデータベースの管理では、同一スキーマのレコードデータが集まったレコード集合毎に、更新するレコードデータの前回の更新からの差分情報である、更新差分情報に識別情報を付与したもの（以下、「コミットログ」という）をファイルしたコミットログファイルが準備されていた。しかし、この方式では、クライアント装置から複数のレコード集合への更新が発生すると、レコード集合毎にコミットログファイルを備えるため、コミットログファイルへのアクセスに伴うＩ／Ｏ（Input/Output）の回数が増加してネットワークの負荷が増大し、データベース更新のレスポンス等が悪化するという問題点があった。
【０００３】
上記問題点に対して、同一スキーマのレコードデータが集まったレコード集合毎に、コミットログファイルを準備するのではなく、複数のレコード集合で、１つのコミットログファイルを共有して書き込みを実施する方式が提案されている。この方式では、１度に複数のレコード集合への更新が発生した場合、それらの更新すべき情報をまとめて一括して更新することが可能となり、データベース更新のレスポンス等の向上が望める。ところが、コミットログは更新ごとに生成されるため、これを放置しておくと膨大になる。
【０００４】
そこで、ある所定時間が経過したコミットログを削除する方式がある。この方式では、所定期間毎にレコード集合のスナップショットを取得し、その取得した期間より過去の期間を所定期間として、コミットログを削除する。これにより、取得したスナップショットと残ったコミットログファイルでレコード集合の復元が可能になる。
【０００５】
また、ある所定量のコミットログが蓄積した時点で、その所定量を超えた古いコミットログを削除する方式もある。所定量のコミットログが蓄積した時点でスナップショットを取得し、その取得した時点より過去のコミットログを削除することにより、このスナップショットと残ったコミットログファイルでレコード集合の復元が可能になる（例えば、非特許文献１参照）。
【０００６】
また、複製元のデータベースを有するマスタ記憶装置のレコードデータと全く同じ内容をレプリケーションにより複製したデータベースを有する複製先のレプリカ記憶装置を複数配置した構成においても、上記のようにある所定期間が経過した時点又はある所定量が蓄積した時点をマスタ記憶装置とレプリカ記憶装置との間で通知することにより、コミットログの削除が可能になる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「連載  ORACLE MASTER Silver DBA  ポイント解説  第３回  制御ファイルとREDOログ・ファイルの管理」,小野寺智子,ＩＴ自分戦略研究所,［online］, 2004年8月27日,［2009年4月16日検索］,インターネット, ＜URL:http://jibun.atmarkit.co.jp/Iskill01/rensai/omsdb03/omsdb01.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記のように複数のレコード集合体のコミットログを１ファイルにまとめた場合には、各レコード集合からスナップショットを取得するタイミングが必ずしも同一ではないので、所定時間経過後又はコミットログが所定量に蓄積したことを契機としてまうと、本来必要なコミットログまで削除してしまうおそれがある。よって、どのコミットログから過去のものを削除していいかを判定する必要がある。
【０００９】
また、上記のようなコミットログの構成において、複製元のマスタ記憶装置１台に対して複製先のレプリカ記憶装置が複数あるような構成をとる場合、レプリカ記憶装置はマスタ記憶装置の有するレコードデータの更新と同期をとるように動作するが、通信状況や負荷状況によっては、レプリカ記憶装置におけるレコードデータの更新の同期が遅れる場合がある。レプリカ記憶装置の同期に遅れが発生した場合は、マスタ記憶装置はコミットログを削除する過程でレプリカ記憶装置の更新状況を勘案する必要がある。同様に、レプリカ記憶装置でも不要なコミットログの削除を実施したいが、レプリカ記憶装置はマスタ記憶装置が故障し、動作できなくなった場合にマスタ記憶装置に成り代わるものであるので、マスタ記憶装置や自身以外のレプリカ記憶装置の更新状況を勘案したコミットログ削除を実施する必要がある。
【００１０】
上記問題点に鑑み、本発明は、レコードデータの更新で生成されるコミットログをファイルして一元管理し、不要になったコミットログを削除する契機を判定して削除するログファイル管理装置、システム、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
前記課題を解決するために、本発明は、レコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成し、管理するログファイル管理装置であって、前記共有ファイルを記憶するコミットログ記憶部と、クライアント装置から前記レコードデータの更新要求を受け付ける要求受付部と、前記更新要求に基づいて前記コミットログを生成し、このコミットログを前記共有ファイルへ永続化するコミットログ生成部と、レコードデータ記憶部に記憶されるレコードデータを、任意のタイミングでチェックポイントとして取得して永続化し、各レコード集合毎に、チェックポイントが取得された時点を比較し、最も古いチェックポイントが取得された以前の前記コミットログを不要なコミットログとして削除する更新実行部と、前記所定のタイミングのレコードデータを前記レコードデータ記憶部からチェックポイントとして取得して永続化してチェックポイント記憶部に記憶するチェックポイント取得部と、前記更新実行部からの指示に基づき、前記共有ファイルに蓄積されたコミットログから、前記チェックポイント取得時以前のコミットログを削除するコミットログ制御部とを備えることを特徴とする。
【００１２】
本発明によれば、レコードデータの更新要求で生成されるコミットログを共有のコミットログファイルに永続化し、任意のタイミングでチェックポイントを取得したときは、各レコード集合に対して、チェックポイントが取得された時点を比較し、最も古いチェックポイントが取得された時点以前のコミットログを不要なコミットログとして削除しているので、迅速に適切な削除ポイントを特定して削除することができる。
【００１３】
また、本発明は、ノード間で共有するレコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成し、管理するログファイル管理システムであって、クライアント装置から前記レコードデータの更新要求を受け付けて当該レコードデータの更新処理を行うマスタのログファイル管理装置と、当該マスタのログファイル管理装置の当該レコードデータの更新に対応して、当該同一のレコードデータを複製し更新するレプリカのログファイル管理装置とを備え、前記ログファイル管理装置はそれぞれ、前記共有ファイルを記憶するコミットログ記憶部と、クライアント装置から前記レコードデータの更新要求を受け付ける要求受付部と、前記更新要求に基づいて前記コミットログを生成し、このコミットログを前記共有ファイルへ永続化するコミットログ生成部と、前記各レコード集合に対する前記共有ファイルに蓄積されたコミットログが所定の範囲にあるか否かを判定し、当該コミットログが所定の範囲を超えたときは、当該所定の範囲を超えたコミットログを不要なコミットログとして削除を指示する更新実行部と、前記レコードデータを前記レコードデータ記憶部からチェックポイントとして取得してチェックポイント記憶部に記憶するチェックポイント取得部と、前記更新実行部からの指示に基づき、前記共有ファイルに蓄積されたコミットログから不要なコミットログを削除するコミットログ制御部と、他のログファイル管理装置との間で通信を行う通信制御部とを備え、自身のログファイル管理装置が前記マスタのログファイル管理装置であるとき、前記ログファイル管理装置は、さらに、前記レプリカのログファイル管理装置それぞれへ、当該マスタのログファイル管理装置におけるレコードデータの更新に対応して、当該同一のレコードデータを複製し、更新するよう要求するレプリケーション要求を送信し、当該レプリカのログファイル管理装置それぞれから、前記レプリケーション要求に基づくレコードデータ更新に関するコミットログの永続化が完了した旨の応答を受信するレプリケーション制御部を備え、前記所定の範囲を示す値として、前記マスタ及び前記レプリカのログファイル管理装置は同一の値を用いることを特徴とする。
【００１４】
本発明によれば、マスタのログファイル管理装置（以下、「マスタ」という）は、最新のコミットログからどこまでを削除可能か、レプリカのログファイル管理装置（以下、「レプリカ」という）と同じ範囲を用いることにより、マスタとレプリカが事前に設定した範囲外のコミットログは各自で独立に削除してよい構成を備えているため、レプリカに問い合わせることなくそれ以前のコミットログを削除することが可能となる。よって、マスタと各レプリカとの間で削除に関する問い合わせのための通信がなくなるため、ネットワークの負荷を下げることが可能になる。
【００１５】
また、本発明は、ノード間で共有するレコードデータの集合であるレコード集合に対して、前記レコードデータの更新作業に基づいて、前記レコードデータそれぞれの更新内容を示すコミットログを生成して蓄積した共有ファイルを作成し、管理するログファイル管理システムであって、クライアント装置から前記レコードデータの更新要求を受け付けて当該レコードデータの更新処理を行うマスタのログファイル管理装置と、当該マスタのログファイル管理装置の当該レコードデータの更新に対応して、当該同一のレコードデータを複製し更新するレプリカのログファイル管理装置とを備え、前記ログファイル管理装置は、前記共有ファイルを記憶するコミットログ記憶部と、前記クライアント装置から前記レコードデータの更新要求を受け付ける要求受付部と、前記更新要求に基づいて前記コミットログを生成し、このコミットログを前記共有ファイルへ永続化するコミットログ生成部と、前記各レコード集合に対する前記共有ファイルに蓄積されたコミットログのうち不要なコミットログの削除を指示する更新実行部と、前記レコードデータを前記レコードデータ記憶部からチェックポイントとして取得してチェックポイント記憶部に記憶するチェックポイント取得部と、前記更新実行部からの指示に基づき、前記共有ファイルに蓄積されたコミットログから、前記最も古いチェックポイント取得時以前のコミットログを削除するコミットログ制御部と、他のログファイル管理装置との間で通信を行う通信制御部とを備え、自身のログファイル管理装置が前記マスタのログファイル管理装置であるとき、前記ログファイル管理装置は、さらに、前記レプリカのログファイル管理装置それぞれへ、当該マスタのログファイル管理装置におけるレコードデータの更新に対応して、当該同一のレコードデータを複製し、更新するよう要求するレプリケーション要求を送信し、当該レプリカのログファイル管理装置それぞれから、前記レプリケーション要求に基づくレコードデータ更新に関するコミットログの永続化が完了した旨の応答を受信するレプリケーション制御部を備え、前記マスタのログファイル管理装置の更新実行部は、前記レプリカのログファイル管理装置が有するコミットログのうち、最も古いコミットログを選定し、当該コミットログ以前に生成されたコミットログを不要なコミットログとして削除する旨を前記レプリカのログファイル管理装置ヘ通知すると共に自身のファイルログ管理装置が有する当該コミットログを削除し、前記レプリカのログファイル管理装置の更新実行部は、前記通知に基づいて前記コミットログを削除することを特徴とする。
【００１６】
本発明によれば、マスタが自身及びレプリカが有するコミットログの適用状況を管理し、マスタからレプリカヘ適用状況を通知するので、マスタと各レプリカとの間で適用状況に関する問い合わせをする必要がなくなり、ネットワークの負荷を下げることが可能になる。
【発明の効果】
【００１７】
本発明によれば、ログファイル管理装置は、コミットログを削除する削除ポイントを適切に特定して迅速に削除することが可能になる。
また、ログファイル管理システムは、他のノードに依存することなく、コミットログを削除して、ネットワークの負荷を低減することが可能になる。
【図面の簡単な説明】
【００１８】
【図１】第１の実施の形態に係るログファイル管理装置の構成図である。
【図２】レコード集合とチェックポイントの関係を示す図である。
【図３】第１の実施の形態に係るログファイル管理装置の処理の流れを示すフローチャートである。
【図４】削除してよいコミットログの判定方法を説明する図である。
【図５】コミットログＩＤを基準にコミットログを削除する方法を説明する図である。
【図６】時刻を基準にコミットログを削除する方法を示す図である。
【図７】コミットログファイルをスワップさせる方法を説明する図である。
【図８】第２の実施の形態におけるコミットログファイルの削除判定のリストを示す図である。
【図９】第３の実施の形態におけるクライアント装置とログファイル管理装置との関係を示す図である。
【図１０】第４の実施の形態に係るログファイル管理システムの構成図である。
【図１１】第４の実施の形態に係るログファイル管理システムにおける処理の流れを示すフローチャートである。
【図１２】レプリカからマスタへの再送要求を説明する図である。
【図１３】第４の実施の形態に係るログファイル管理システムの構成図である。
【図１４】第５の実施の形態におけるコミットログの適用を示す図である、
【図１５】第５の実施の形態に係るログファイル管理システムにおける処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１９】
以下に、本発明の実施の形態について図面を参照しながら詳細に説明する。
【００２０】
（第１の実施の形態）
図１は、第１の実施の形態に係るログファイル管理装置の構成図である。ログファイル管理装置１００は、図１に示すように、クライアント装置１からレコードデータの更新要求を受け付ける要求受付部２と、更新要求に応じてコミットログを生成するコミットログ生成部３と、不要となったコミットログの削除するタイミング判定して削除を指示する更新実行部４と、不要になったコミットログの削除を実施するコミットログ制御部５と、所定のタイミングにおけるレコードデータをチェックポイントとして取得する（以下、「チェックポイント取得」という）チェックポイント取得部６と、レコード集合毎にレコードデータを記憶するレコードデータ記憶部７と、コミットログを記憶するコミットログ記憶部８と、チェックポイントをファイルとして（以下、「チェックポイントファイル」という）記憶するチェックポイント記憶部９とから構成される。以下、各構成部について詳細に説明する。
【００２１】
要求受付部２は、クライアント装置１からレコードデータの更新要求を受け付ける。ここで、クライアント装置１から受け付ける要求にはレコードデータの更新及び参照があるが、本発明の実施の形態ではレコードデータの更新を処理として扱うことにする。更新の対象レコードデータはレコード集合毎に記憶される。レコード集合とは、データベースを例にとった場合、テーブルを示す。
【００２２】
コミットログ生成部３は、更新要求に基づいて、更新すべきレコードデータの前回の更新からの差分情報である更新差分情報に一意のＩＤ（Identification）を付与したコミットログを生成する。
【００２３】
更新実行部４は、コミットログ制御部５にコミットログをコミットログ記憶部７に永続化（記憶）するよう指示する。さらに、任意のタイミングでチェックポイント取得をチェックポイント取得部６へ指示し、各レコード集合毎に、チェックポイントが取得された時点を比較し、最も古くチェックポイントが取得された時点以前のコミットログを不要となったコミットログと判定して、このコミットログの削除をコミットログ制御部５へ指示する。さらに、削除したコミットログに対応するレコードデータの更新をレコードデータ記憶部７のレコードデータに対し実行する。
【００２４】
コミットログ制御部５は、更新実行部４の指示に基づいて、コミットログをコミットログ記憶部８に永続化し、不要になったコミットログを削除する。
チェックポイント取得部６は、更新実行部４からの指示でチェックポイントの取得を実施し、チェックポイント記憶部９に記憶する。
【００２５】
更新実行部４、コミットログ制御部５及びチェックポイント取得部６は、ログファイル管理装置１００に備えるＣＰＵ（Central Processing Unit）によるプログラム処理や専用回路により実現される。さらに、上記レコードデータ記憶部７、コミットログ記憶部８、チェックポイント記憶部９、及び、ログファイル管理装置１００の機能を実現するためのプログラムを格納する記憶部（不図示）は、ＲＡＭ(Random Access Memory)、ＲＯＭ(Read Only Memory)、ＨＤＤ(Hard Disk Drive)、フラッシュメモリ等の記憶媒体から構成される。
【００２６】
ここで、チェックポイント取得のタイミングを任意のタイミングとしているが、この任意のタイミングとは、コミットログが生成された回数を量として所定の閾値を超えたとき、永続化されたコミットログの量が上記コミットログ記憶部８において所定の容量を超えたとき、前回チェックポイント取得から所定時間を経過したとき、レコードデータ記憶部７に記憶されているレコードデータの量が所定の容量を超えたとき、又は、任意に設定したタイミングをいう。
【００２７】
図２は、レコードデータ記憶部７のレコード集合とチェックポイント記憶部９のチェックポイントの関係を示す図である。図２では、１つのレコード集合に対して１チェックポイントファイルを対応付けているが、複数のチェックポイントファイルを有する構造でもよい。複数有する場合は、スキーマ情報に応じてレコード集合の部分ごとに複数ファイルを有する場合と、異なるタイミングで取得したチェックポイントファイルを複数個保持（複数世代保持）する場合との両方が考えられる。
【００２８】
次に、ログファイル管理装置１００における処理の流れを図３に示すフローチャートで説明する（適宜図１参照）。まず、更新要求部２はクライアント装置１からレコードデータの更新要求を受け付る（Ｓ１）。次に、この更新要求に基づいて、コミットログ生成部３はコミットログを生成し、更新実行部４はこのコミットログの永続化をコミットログ制御部５へ指示してコミットログ記憶部７に永続化する（Ｓ２）。次に、更新実行部４は、所定のタイミングでチェックポイント取得をチェックポイン取得部６に指示して、各レコード集合に対して、チェックポイントを取得する（Ｓ３）。
【００２９】
次に、更新実行部４は、各レコード集合毎に、チェックポイント取得時を比較し、最も古いチェックポイント取得時を決定する（Ｓ４）。次に、更新実行部４は、最も古いチェクポイント取得時以前のコミットログの削除をコミットログ制御部５へ指示して削除する（Ｓ５）。次に、更新実行部４は、削除したコミットログに対応するレコードデータの更新をレコードデータ記憶部７のレコードデータに対して実行する（Ｓ６）。ここで、Ｓ６の処理については、削除するタイミングと同期して実行してもよいし、非同期に実行してもよい。以上により、不要となったコミットログの削除が終了する。
【００３０】
ここで、コミットログは、データベースを復旧させるリカバリ時には、永続化された順序に応じて、順次レコードデータ記憶部７へ適用していく。このため、コミットログは、永続化された順序を示すシーケンシャルな番号、及び／又は、生成された時刻を永続化情報として、更新情報（レコードデータ及びレコード集合のアドレス）と共に有している。ここでは、シーケンシャルな番号のことをコミットログIDという。
【００３１】
次に、削除してよいコミットログの判定方法について具体的に説明する。図４は、削除してよいコミットログの判定方法を説明する図である。図４に示すように、更新実行部４が、ｔ１、ｔ２、ｔ３、ｔ４のタイミングで各レコード集合のチェックポイントファイルを取得したとする。レコード集合Aは、ｔ１のタイミングでチェックポイントファイル（ＣＰＡ）を取得し、その時点でのコミットログIDは、「２５」である。レコード集合Bは、ｔ４のタイミングでチェックポイントファイル（ＣＰＢ）を取得し、その時点でのコミットログIDは、「６９」である。レコード集合Cは、ｔ３のタイミングでチェックポイントファイル（ＣＰＣ）を取得し、その時点でのコミットログIDは、「５２」である。レコード集合Dは、ｔ４のタイミングでチェックポイントファイル（ＣＰＤ）を取得し、その時点でのコミットログIDは、「３３」である。ここで、時刻については、ｔ０＜ｔ１＜ｔ２＜ｔ３＜ｔ４＜現在の順序であり、コミットログIDは大きいほど新しいものとする。
【００３２】
例えば、現時点でコミットログを削除すると考えた場合、各レコード集合で削除できるのは、レコード集合Aは コミットログID ＝２５（もしくは時刻ｔ１）以前であり、レコード集合BはコミットログID＝６９（もしくは時刻ｔ４）以前であり、レコード集合Cは、コミットログID ＝５２（もしくは時刻ｔ３）以前であり、レコード集合Dは、コミットログID＝３３（もしくは時刻ｔ２）以前となり、最も古いレコード集合は、レコード集合Aであるため、コミットログID＝２５（もしくは時刻ｔ１）以前のコミットログは削除してよいという判定になる。もし、コミットログID＝３３以前を削除してしまうと、レコード集合Aについては、現在状態に復元できなくなる。
【００３３】
上記判定をより簡易に行う方法について説明する。図５は、コミットログIDを基準にコミットログの削除を説明する図である。図５では、コミットログＩＤをキーとした単方向リスト構造でレコード集合の情報を管理しており、リストの先頭が、最も古いデータを表している。
【００３４】
まず、初期起動時は、コミットログが全く永続化されていない状態なので、各レコード集合のコミットログID＝０として、任意の順番でリストを作る（この場合、リストへ作られた順番は問題とならないので、何でもよい）。次に、レコード集合Aでチェックポイント取得が行われると、任意の順番で作っていたレコード集合Aの要素をリストから削除し、リストの末尾（時系列的に最新の方）にコミットログID＝２５でレコード集合Aを追加する。時系列順に、レコード集合D、レコード集合C、レコード集合Bと任意の順番のレコードを削除し、末尾から追加を繰り返していく。このリスト構造を作っていれば、任意のタイミングでコミットログ削除を実施したい場合は、このリストの先頭を参照し、そのレコード集合が示すコミットログID以前のコミットログを削除すればよい。
【００３５】
上記では、初期起動時に全レコード集合の要素を追加していたが、各レコード集合が初めてチェックポイントを取得するタイミングで要素を追加する方法も考えられる。この場合、コミットログ削除の判定を実施するときは、リストの要素数を確認し、レコード集合の数と一致していた場合にのみコミットログ削除を実施するようにする。図５に示した例の場合レコード集合Ｃを基点にそれ以前のデータを削除してしまと、レコード集合Ａを復元するのに必要なデータのうちコミットログＩＤ＝２６〜５１が、レコード集合Ｃを復元するのに必要なデータのうちコミットログＩＤ＝３４〜５１がそれぞれ失われてしまいレコード集合Ａとレコード集合Ｃの復元が行えなくなる。
【００３６】
また、削除の判定には、時刻を利用することもできる。この場合も、基本的にはコミットログIDを利用する場合と同じだが、判定要素が時刻に変わる。図６は、時刻を基準にコミットログを削除する方法を示す図である。図６に示す例では、削除できる基点となる時刻が決まったら、その基点の時刻よりも前のコミットログをすべて削除する。コミットログファイルはファイルの先頭から順に時系列に追記されていく前提として、コミットログが1ファイルに書かれている場合は、先頭からその基点の時刻までを削除する。
【００３７】
第１の実施の形態によれば、レコードデータの更新要求で生成されるコミットログに対して、時系列的にシーケンシャルな識別情報を対応付けて共有のコミットログファイルに永続化し、任意のタイミングでチェックポイントを取得したときは、各レコード集合に対して、チェックポイントが永続化された時点を比較し、最も古くチェックポイントが永続化された時点以前のコミットログを不要なコミットログとして削除しているので、迅速に適切な削除ポイントを特定して削除することができる。
【００３８】
（第２の実施の形態）
第２の実施の形態では、コミットログ記憶部７において、論理的にコミットログファイルが複数ファイルから構成される例について説明する。コミットログファイルが複数ファイルにまたがっている場合は、コミットログを複数のコミットログファイルに順次書き込むスワップ処理を実施しており、削除するタイミングを示す基点以前のコミットログしか含まれていないファイルは削除し、基点が含まれているファイルは、先頭からその基点の位置までを削除する。基本的な考え方は、第１の実施の形態と同様であるが、コミットログ削除をファイル単位で削除するような場合を想定している。
【００３９】
図７は、コミットログファイルをスワップさせる方法を説明する図である。図７では、コミットログファイルが３つ用意されており、コミットログIDが０〜２０まではコミットログファイル１に、コミットログIDが２１〜７８まではコミットログファイル２に、コミットログIDが７８以降のものはコミットログファイル３にそれぞれファイルされている。
【００４０】
初期起動時にコミットログファイル１が生成され、ｔ１のタイミングでコミットログをファイルするファイルがコミットログファイル２へスワップし、ｔ６のタイミングでコミットログファイル３へスワップしているものとする。
【００４１】
図８は、第２の実施の形態におけるコミットログファイルの削除判定のリストを示す図である。図８（ａ）は、時刻を基準にコミットログを削除する場合を示し、図８（ｂ）は、コミットログＩＤを基準にコミットログを削除する場合を示している。
【００４２】
例えば、図７に示す現在時刻にコミットログ削除を実施した場合、第１実施の形態と同様に判定を実施すると、コミットログID＝２５以前、即ち、時刻ｔ２以前のコミットログを削除できるという判定ができる。第１の実施の形態と異なる点は、各コミットログファイルをファイル単位でサーチし、そのファイルに含まれるコミットログの範囲を確認する点である。コミットログ記憶部７にコミットログファイル管理情報を作成しておき、この管理情報を参照してコミットログファイルに含まれるコミットログの範囲を確認してもよい。コミットログ管理情報は、コミットログファイルとこのファイルに含まれるコミットログ（ＩＤ）の範囲の対応付けている情報である。
【００４３】
コミットログファイル１は、コミットログＩＤ０〜２０（時刻ｔ０〜ｔ１）のコミットログＩＤを含んでおり、今回削除してもよいと判定される。よって、ここでは、コミットログファイル１のみを削除するという処理になる。そして、コミットログファイル２について検討すると、コミットログＩＤ２５以降のコミットログが含まれているため、コミットログファイル２はそのまま残すことも可能である。
【００４４】
第２の実施の形態によれば、コミットログファイル単位でのコミットログの削除が可能になり、コミットログファイルが１つで構成される場合におけるファイルの一部を削除するよりも高速にコミットログの削除が実施できる。
【００４５】
（第３の実施の形態）
図９は、第３の実施の形態におけるクライアント装置１とログファイル管理装置１００との関係を示す図である。第３の実施の形態では、1つのレコード集合のデータが複数のログファイル管理装置１００に分散している例について説明する。例えば、一つのテーブル（レコード集合）を、物理的には都道府県別に分割して配置保存している様な場合を想定している。クライアント装置１からは、テーブルが個々に分割保存されていることは意識されず、一つのテーブルとして見えている。即ち、それぞれのログファイル管理装置１００で異なるデータを保持していることになる。また、それぞれ異なるログファイル管理装置１００に物理的に分散していると考えられるため、コミットログ記憶部７はそれぞれのログファイル管理装置１００に一つずつ配置されている。
【００４６】
上記の場合でも、コミットログの削除条件は、各々のログファイル管理装置１００が互いに依存しあうことなく、各々のログファイル管理装置１００毎にリカバリが可能であれば良いので、上述した第１及び第２実施の形態と同様の判定を各ログファイル管理装置１００で実施すればよい。
【００４７】
第３の実施の形態によれば、分散してログファイル管理装置１００を設置でき、他のログファイル管理装置１００に依存することなく、高速にコミットログの削除が可能になる。
【００４８】
（第４の実施の形態）
図１０は、第４の実施の形態に係るログファイル管理システムの構成図である。
図１０に示すように、ログファイル管理システム２００は、クライアント装置１からレコードデータの更新要求を受け付けてレコードデータの更新処理を行うマスタのログファイル管理装置（以下、「マスタ４０」という）と、マスタのログファイル管理装置のレコードデータの更新に対応して、同一のレコードデータを複製し更新するレプリカのログファイル管理装置（以下、「レプリカ５０」という）とを備える。
【００４９】
マスタ４０，レプリカ５０はそれぞれ、クライアント装置１からレコードデータの更新要求を受け付ける要求受付部２と、更新要求に応じてコミットログを生成するコミットログ生成部３と、不要となったコミットログの削除するタイミング判定して削除を指示する更新実行部１４と、不要になったコミットログの削除を実施するコミットログ制御部１５と、コミットログの量が所定の範囲（以下、「ウインドウ幅」という）に達した時点のチェックポイント取得を実施するチェックポイント取得部６と、レコード集合毎にレコードデータを記憶するレコードデータ記憶部７と、コミットログを記憶するコミットログ記憶部８と、チェックポイントファイルを記憶するチェックポイント記憶部９と、レプリケーション要求の制御をするレプリケーション制御部１６と、他のログファイル管理装置との間で通信を行う通信制御部１７とを備える。
【００５０】
以下、第１の実施の形態と同様の機能を有する構成を示す部位については、同様の符号を付し、その説明の重複を省略する。
【００５１】
マスタ４０は、さらに、各レプリカ５０へ、マスタ４０におけるレコードデータの更新に対応して、同一のレコードデータを複製し、更新するよう要求するレプリケーション要求を送信し、各レプリカ５０から、レプリケーション要求に基づくレコードデータ更新に関するコミットログの永続化が完了した旨の応答を受信するレプリケーション制御部１６を備える。
【００５２】
ここで、チェックポイント取得のタイミングをコミットログの量が所定のウインドウ幅に達したときとしているが、これは、コミットログが生成された回数を量として所定のウインドウ幅を超えたとき、永続化されたコミットログの量が上記コミットログ記憶部８において所定の容量を超えたとき、前回チェックポイント取得から所定時間を経過したとき、又は、レコードデータ記憶部７に記憶されているレコードデータの量が所定の容量を超えたときをいう。また、チェックポイントの取得を任意のタイミングで実施することも可能である。
【００５３】
マスタ４０の更新実行部１４は、コミットログの量が所定のウインドウ幅にあるか否かの判定を行うとき、コミットログの量のウインドウ幅として、各レプリカ５０で用いられるコミットログの量のウインドウ幅と同じ値を用いる。さらに、マスタ４０の更新実行部１４は、レプリケーション要求に対して、各レプリカ５０から、レコードデータに関するコミットログの永続化が完了した旨の通知を、レプリカ５０の合計台数のうち、過半数のレプリカから受信した場合に、レコードデータに関するコミットログを永続化されたコミットログとみなし、永続化されたとみなされたコミットログの量が所定のウインドウ幅にあるか否かを判定する。
【００５４】
第４の実施の形態におけるレコード集合とチェックポイントの関係は第１の実施の形態におけるものと同様であるのでここでは説明を省略する。
【００５５】
次に、ログファイル管理システム２００における処理の流れを図１１に示すフローチャートで説明する（適宜図１０参照）。まず、マスタ４０の更新要求部２はクライアント装置１からレコードデータの更新要求を受け付ける（Ｓ１１）。次に、この更新要求に基づいて、コミットログ生成部３はコミットログを生成し、更新実行部１４はコミットログの永続化をコミットログ制御部１５へ指示してコミットログ記憶部７に永続化する（Ｓ１２）。
【００５６】
次に、マスタ４０のレプリケーション制御部１６は、各レプリカ５０ヘレプリケーション要求を送信する（Ｓ１３）。各レプリカ５０から、レコードデータに関するコミットログの永続化が完了した旨の通知を、レプリカ５０の合計台数のうち、過半数のレプリカから受信した場合（Ｓ１４のＹｅｓ）、マスタ４０の更新実行部１３は、レコードデータのコミットログが永続化したものとみなして、このコミットログをカウントする（Ｓ１６）。一方、過半数のレプリカから上記通知を受信できなかった場合は（Ｓ１４のＮｏ）、マスタ４０の更新実行部１３エラーと判断する（Ｓ１５）。
【００５７】
次に、マスタ４０の更新実行部１４は、自身のコミットログ記憶部８のコミットログの量が所定のウインドウ幅に達しているか否かを判定する（Ｓ１７）。所定のウインドウ幅に達した場合は（Ｓ１７のＹｅｓ）、チェックポイント取得部６はチェックポイント取得を実施する（Ｓ１７のＹｅｓ）。一方、所定のウインドウ幅に達していない場合は（Ｓ１７のＮｏ）、レコードデータをレコードデータ記憶部へ更新する（Ｓ２０）。次に、マスタの更新実行部１４は、所定のウインドウ幅の範囲外にあるコミットログの削除をコミットログ制御部１５に指示して削除する（Ｓ１９）。次に、更新実行部１４は、削除したコミットログに対応するレコードデータをレコードデータ記憶部７へ更新する（Ｓ２０）。Ｓ２０の処理については、削除と同期して実行してもよいし、非同期に実行してもよい。以上により、不要となったコミットログの削除が終了する。
【００５８】
第４の実施の形態のマスタ４０及びレプリカ５０からなる構成では、マスタ４０はクライアント装置１から更新要求を受けて、レプリカ５０へレプリケーション要求（以下、「複製依頼」という）を送信する（上記Ｓ１３）。レプリカ５０側では、複製依頼を受けてレプリカ５０で生成したコミットログをコミットログ記憶部８へ永続化する。ここで、レプリカ５０もマスタ４０と同様の装置構成であったとして、レコードデータ記憶部７へレコードデータの更新を反映するか否かは問わない。この理由は、リアルタイムでレコードデータ記憶部７へ更新を反映してもよいし、マスタ４０が故障等によりダウンし、レプリカ５０が新たなマスタ４０なったタイミングで新マスタ４０のコミットログからレコードデータ記憶部７への更新を行ってもよいからである。即ち、レプリカ５０側でマスタ４０側と同一のコミットログがコミットログ記憶部８へ永続化されていればよい。
【００５９】
但し、レプリカ５０でのレコードデータ記憶部７への更新順序、即ち、コミットログの永続化の順序は、マスタ４０と同一である必要がある。これは、更新データの適用順序が入れ替わると不整合が起こる場合があるからである。例えば、コミットログＩＤが１のときにレコード集合Ａを新規挿入し、コミットログＩＤが２のときにレコード集合Ａのレコードデータを変更したとする。レプリカ５０でこの順序が入れ替わると、レコード集合Ａのレコードデータ変更から適用するが、まだレコード集合Ａが存在していないため、エラーとなってしまうのである。
【００６０】
そこで、マスタ４０が複製依頼をする度にコミットログに単調増加する連番を付し、レプリカ５０ではこの連番を元に、上記の様に順序の入れ替えが起きていないか否かの判定を行う。ここで、この連番をそのままコミットログＩＤとして利用してもよいし、連番とコミットログＩＤは別体系でも構わない。
【００６１】
レプリカ５０では、最後に永続化したコミットログの連番を連番記憶部（不図示）に記憶しておき、どこまでコミットログ記憶部８に永続化したかを保持しておく。複製依頼を受けると、その連番と連番記憶部にある連番とを比較し、歯抜けが無いかを判定する。例えば、連番記憶部に連番の「３」が記憶されている場合、次には４番の複製依頼がマスタ４０からくると期待するが、実際に来た番号が５番以降であった場合は、歯抜けであると判定される。この場合は、通信障害などにより、４番が到着できなかった可能性があるため、レプリカ５０は複製依頼の再送を要求し、４番の到着を待ってから４番及び５番の複製処理（コミットログ記憶部８への更新）を実施する。ここで、複数の連番が歯抜けだと分かった時は、その分の再送要求を出す。再送要求は一ずつ出してもよいし、まとめて出してもよい。一方、マスタ４０は、レプリカ５０からの再送要求がいつ来るか分からないため、コミットログを削除するタイミングを決めることができない。
【００６２】
そこで、マスタ４０は、保持しておくコミットログの量のウインドウ幅として、各レプリカ５０で用いられるコミットログの量のウインドウ幅と同じ値を用い、レプリカ５０側からそのウインドウ幅の範囲外のコミットログの再送を要求された場合は、既に無いので、初期状態から立ち上がる様にレプリカ５０側へ応答する。このような応答を受けたレプリカ５０は、初期状態からの立ち上げ要求を受けて、マスタ４０の有するチェックポイントとコミットログをマスタ４０から再送してもらい、これを用いてマスタ４０と同一の状態へのリカバリを実施する。
【００６３】
以上のような状態では、最新のコミットログからマスタ４０が定めたウインドウ幅（Windowサイズ）は、例えば、所定期間分（例えば、過去１時間分）、又は所定個数（例えば、最新から１００個分）を残して、それ以前のコミットログは削除してよいと判定する。また、複製依頼の再送要求と併せて削除判定を実施することも可能である。
【００６４】
図１２は、レプリカ５０からマスタ４０への再送要求を説明する図である。図１２（ａ）に示すように、マスタでは保持するコミットログの量をWindowサイズとして決めている。この場合は、マスタはコミットログ１〜１０を保持しているが、Windowサイズは「５」であるので、コミットログ１〜５は削除してよいコミットログとなる。図１２（ｂ）では、レプリカ１は、コミットログ１〜７を保持しているが、最新化するためにコミットログ８〜１０をマスタ４０から再送してもらう。図１２（ｃ）では、コミットログ４〜９の再送を要求したいが、Windowサイズを上回るため再送できない。よって、リカバリするため初期状態から立ち上げるリカバリールートに入ることになる。即ち、レプリカ５０は、マスタ４０からチェックポイントファイルとコミットログ５〜９とを再送してもらう。
【００６５】
第４の実施の形態によれば、マスタ４０は、最新のコミットログからどこまでを削除可能か、レプリカ５０と同じウインドウ幅を用いることにより、マスタ４０とレプリカ５０が事前に設定したウインドウ幅の範囲外のコミットログは各自で独立に削除してよい構成を備えているため、レプリカ５０に問い合わせることなくそれ以前のコミットログを削除することが可能となる。よって、マスタ４０と各レプリカ５０との間で削除に関する問い合わせのための通信がなくなるため、ネットワークの負荷を下げることが可能になる。
【００６６】
（第５の実施の形態）
第５の実施の形態では、第４の実施の形態に記載したように、マスタ及びレプリカが自立的に削除実施する方式ではなく、マスタ側で削除可能範囲を判断し、各レプリカに通知する方式である。
【００６７】
図１３は、第５の実施の形態に係るログファイル管理システムの構成図である。第４の実施の形態と同様の機能を有する構成を示す部位については、同様の符号を付し、その説明の重複を省略する。
マスタ６０の更新実行部２４が各レプリカ７０にレプリケーション要求を送信した後、各レプリカ７０はマスタ６０に対してレプリカ完了という応答（ＡＣＫ）を送信する。マスタ６０の更新実行部２４は、この応答に基づいて、マスタ６０自身及び各レプリカ７０がどのコミットログＩＤまで永続化が完了したかを示すコミットログ適用状況表を作成して保持しておき、各レプリカ７０からＡＣＫを受信したときは、このコミットログ適用状況表を更新する。
【００６８】
図１４は、第５の実施の形態におけるコミットログの適用を示す図である。図１４は、レプリカ４とマスタとの間で、コミットログＩＤ＝９以降のレプリケーション要求発生時に通信途絶が発生しており、レプリカ４ではコミットログＩＤ＝８の適用までしか完了しておらず、その後、図14に示すコミットログＩＤ＝１０のレプリケーション終了後、レプリカ4とマスタとの間での通信途絶が解消している場合を示している。図１４に示すように、コミットログＩＤ＝１０のレプリケーション要求の送信に対し、レプリカ７０（ここでは、レプリカ１〜３とする）は、マスタに対してＡＣＫを送信するが、レプリカ４は、コミットログＩＤ＝８までしか永続化が完了していないためＡＣＫを送信することができない。マスタの更新実行部２４は、レプリカ１〜３からＡＣＫを受信することにより、ＡＣＫに基づいてコミットログ適用状況表を更新し、レプリカ毎の最新のコミットログＩＤの適用状況を把握しておくことができ、各レプリカに対して削除可能なコミットログＩＤを通知することができる。また、マスタがコミットログＩＤ＝１１の複製依頼をしてきたときは、レプリカ４はマスタに対して、コミットログＩＤ＝９、１０の再送要求を送信する。
【００６９】
コミットログの削除は、マスタ６０側の任意のタイミングで実行できる。例えば、マスタ６０内でチェックポイント取得がなされたタイミング、所定時間、コミットログの更新量が所定、又は、ユーザの決めた任意のタイミングで、コミットログの削除を実施する。この場合、マスタ６０の更新実行部２４は、保持するコミットログ適用状況表を参照し、各レプリカ７０が有するコミットログＩＤの中で一番古い（小さい）コミットログID（もしくは時刻）を選定し、それ以前のコミットログを削除してよいと判定する。判定後、マスタ６０は各レプリカ７０にそのコミットログＩＤを通知し、レプリカ７０はその通知を基にコミットログＩＤの削除を実施する。
【００７０】
次に、ログファイル管理システム３００における処理の流れを図１５に示すフローチャートで説明する。まず、更新要求部２はクライアント装置１からレコードデータの更新要求を受け付ける（Ｓ３１）。次に、この更新要求に基づいて、コミットログ生成部３はコミットログを生成し、更新実行部２４はコミットログ記憶部７にコミットログの永続化をコミットログ制御部１５へ指示して永続化させる（Ｓ３２）。
【００７１】
次に、レプリケーション制御部１６は、各レプリカ７０ヘレプリケーション要求を送信する。マスタ６０の更新実行部２４は、各レプリカ７０から、レコードデータに関するコミットログの永続化が完了した旨の通知を受信する（Ｓ３３）。この通知には、マスタ６０がどのコミットログに対する通知かわかるように、コミットログＩＤ、コミットログそのもの、又は、マスタ６０がコミットログを出力した時刻が含まれているものとする。マスタ６０の更新実行部２４は、この通知に基づいて、コミットログ適用状況表を作成又は更新する（Ｓ３４）。マスタ６０の更新処理実行部２４は、各レプリカ７０が有するコミットログのうち最も古く生成されたコミットログを選定する（Ｓ３５）。チェックポイント取得部６は、この最も古く生成されたコミットログに対応するチェックポイントを取得する（Ｓ３６）。マスタ６０の更新実行部２４は、最も古く生成されたコミットログ以前のコミットログを削除すると共にレプリカ７０ヘ通知し、レプリカ７０は該当するコミットログを削除する（Ｓ３７）。以上により、不要となったコミットログの削除が終了する。
【００７２】
第５の実施の形態によれば、マスタ６０が自身及びレプリカ７０が有するコミットログの適用状況を管理し、マスタ６０からレプリカ７０ヘ適用状況を通知するので、マスタ６０と各レプリカ７０との間で適用状況に関する問い合わせをする必要がなくなり、ネットワークの負荷を下げることが可能になる。
【符号の説明】
【００７３】
１  クライアント装置
２  要求受付部
３  コミットログ生成部
４  更新実行部
５  コミットログ制御部
６  チェックポイント取得部
７  レコードデータ記憶部
８  コミットログ記憶部
９  チェックポイント記憶部
１４  更新実行部
１５  コミットログ制御部
１６  レプリケーション制御部
１７  通信制御部
２４  更新実行部
４０  マスタ
５０  レプリカ
６０  マスタ
７０  レプリカ
１００  ログファイル管理装置
２００  ログファイル管理システム
３００  ログファイル管理システム
【図１】
2010277473.tif 000003
【図２】
2010277473.tif 000004
【図３】
2010277473.tif 000005
【図４】
2010277473.tif 000006
【図５】
2010277473.tif 000007
【図６】
2010277473.tif 000008
【図７】
2010277473.tif 000009
【図８】
2010277473.tif 000010
【図９】
2010277473.tif 000011
【図１０】
2010277473.tif 000012
【図１１】
2010277473.tif 000013
【図１２】
2010277473.tif 000014
【図１３】
2010277473.tif 000015
【図１４】
2010277473.tif 000016
【図１５】
2010277473.tif 000017