JP5924117B2 - コンピュータ、データ格納方法、データ格納プログラム及び情報処理システム - Google Patents

Description

本発明は、データベースを管理するコンピュータ、データ格納方法、データ格納プログラム及び情報処理システムに関する。

近年、高可用性を要求される事業分野ではインフラとして分散ストレージシステムが多く採用されている。例えば、クライアント・サーバ型の分散ストレージシステムでは、クライアントは、複数のサーバに対して、データの書き込み、または、サーバが保持するデータを読み込む。一方、サーバ側では、複数のサーバが連携し、故障した場合に備えてデータを冗長化して保持する。例えば、１つのサーバが保持するデータと同じ内容のデータを、他のサーバが保持する。

このようなシステムにおいて、サーバが故障すると、故障したサーバがデータベースに保持するデータの冗長性が低下してしまう。そこで、サーバが故障した場合、故障したサーバが管理していたデータベース内のデータの冗長性を回復する、リカバリ処理が行われる。リカバリ処理では、データの冗長性の低下を抑制するために、当該データを保持しているサーバ（転送元サーバ）は、新たに選択されたサーバ（転送先サーバ）に、当該データのコピーを転送する。これにより、故障したサーバが保持するデータの冗長性を回復することができる。リカバリ処理に関する技術としては、例えばストレージ装置の故障発生時に生じるデータアクセスの停止期間を短縮できるようにする技術等が考えられている。

特開２０１０−９７３８５号公報

しかし、データベースのデータ構造上の原因で、リカバリ処理に時間がかかる場合がある。例えば、データベースのデータ構造は、データの書き込みを効率的に行えるデータ配置を有する書き込み高速型と、データの読み出しを効率的に行えるデータ配置を有する読み出し高速型とに分類される。このうち、読み出し高速型でデータベースを管理するサーバは、書き込み高速型のデータベースへのデータ書き込みに比べて、データの書き込みに時間を要する。そのため、リカバリ時間も長期化する。リカバリ中のサーバは、リカバリが完了しておらずデータベースに保持するスロットは冗長性が低下している。リカバリ中のサーバに新たな故障が発生してしまうと、データロスが発生してしまう。つまり読み出し高速型のデータベースを有するシステムでは、リカバリに時間を要し、データロスが生じる可能性が高くなり、結果的に信頼性の低下を招いてしまうという問題点があった。

１つの側面では、本発明は、データの冗長性を迅速に回復することが可能なコンピュータ、データ格納方法、データ格納プログラム及び情報処理システムを提供することを目的とする。

１態様によれば、故障した第１の装置が保持していたデータと同一内容のデータを第２の装置から受信すると、読み出しがランダムアクセスとなり、書き込みがシーケンシャルアクセスとなるデータ構造の第１のデータベースに、該受信したデータを格納する格納手段と、第１のデータベースに格納されたデータを、書き込みがランダムアクセスとなり、読み出しがシーケンシャルアクセスとなるデータ構造の第２のデータベースにコピーするコピー手段と、を有するコンピュータが提供される。

データの冗長性を迅速に回復することが可能となる。

第１の実施の形態に係るコンピュータを含む情報処理システムの一例を示す図である。 第１の実施の形態に係るデータの書き込み機構の一例を示す模式図である。 第１の実施の形態における冗長データの格納状況の一例を示す図である。 第２の実施の形態に係るサーバシステムの一例を示す図である。 第２の実施の形態に係るＤＢサーバのハードウェアの一例を示すブロック図である。 第２の実施の形態に係るＤＢサーバの機能の一例を示すブロック図である。 第２の実施の形態に係るサーバ状態管理テーブルの一例を示す図である。 第２の実施の形態に係るスロット格納管理テーブルの一例を示す図である。 第２の実施の形態に係るリカバリ中オブジェクト一覧の一例を示す図である。 第２の実施の形態に係るサーバシステムのデータのやりとりの一例を示す図である。 第２の実施の形態に係るＤＢサーバのスロットのコピー実行通知の処理手順の一例を示すフローチャートである。 第２の実施の形態に係るＤＢサーバのリカバリ処理手順の一例を示すフローチャートである。 第２の実施の形態に係るＤＢサーバの書き込み処理手順の一例を示すフローチャートである。 第２の実施の形態に係るＤＢサーバの読み出し処理手順の一例を示すフローチャートである。 第３の実施の形態に係るサーバシステムの一例を示す図である。 第３の実施の形態においてＤＢサーバが正常動作時のＤＢサーバへのＨＤＤ割り当て状況の一例を示す図である。 第３の実施の形態において１台のＤＢサーバが故障したときのサーバシステムの運用状況の一例を示す図である。 第３の実施の形態においてＨＤＤ追加割り当て後のサーバシステムの運用状況の一例を示す図である。

以下、図面を参照して実施の形態について説明する。
［第１の実施の形態］
第１の実施の形態について図１を用いて説明する。

図１は、第１の実施の形態に係るコンピュータを含む情報処理システムの一例を示す図である。
情報処理システム１は、図１に示すように、複数のコンピュータ２〜５が相互に送受信可能にネットワーク６を介して接続されている。

コンピュータ２は、データベース（ＤＢ）２ａ及びＤＢ２ｂを有する。ＤＢ２ａ，２ｂは、記憶手段の一例である。ＤＢ２ａは、読み出しがランダムアクセスとなり、書き込みがシーケンシャルアクセスとなるデータ構造を有している。ＤＢ２ｂは、書き込みがランダムアクセスとなり、読み出しがシーケンシャルアクセスとなるデータ構造を有している。シーケンシャルアクセスは、ランダムアクセスよりも効率的である。そのためＤＢ２ａは、ＤＢ２ｂより効率よくデータの書き込みが可能である。またコンピュータ２は、格納手段２ｃ、コピー手段２ｄ、及びデータ更新手段２ｅを有する。

格納手段２ｃは、故障したコンピュータ３が保持していたデータと同一内容のデータをコンピュータ４から受信すると、ＤＢ２ｂより効率よくデータの書き込みが可能なＤＢ２ａに、該受信したデータを格納する。故障したコンピュータ３が保持していたデータと同一内容のデータとは、例えば冗長性が失われたデータのコピーデータである。

ＤＢ２ｂは、例えば読み出し高速型のデータ構造を有している。またＤＢ２ａは、例えば書き込み高速型のデータ構造を有している。読み出し高速型のデータ構造のＤＢとは、例えば、オブジェクト更新時に更新内容がin-place（決まった場所）に上書きされる構造を持つＤＢである。書き込み高速型のデータ構造のＤＢとは、例えば、オブジェクト更新時に、更新内容がＤＢ末尾に追記される構造（ログ構造）を持つＤＢである。

コピー手段２ｄは、ＤＢ２ａに格納されたデータを、ＤＢ２ｂにコピーする。例えばコピー手段２ｄは、コンピュータ３が保持していたデータのうち、コンピュータ３に代わってコンピュータ２が管理するデータが複数ある場合、該当するすべてのデータがＤＢ２ａに格納された後に、コピーを開始する。

データ更新手段２ｅは、ＤＢ２ａに格納され、かつＤＢ２ｂへのコピーが済んでいないデータの更新要求を受信すると、更新要求に含まれている更新後のデータをＤＢ２ｂに書き込む。またデータ更新手段２ｅは、その更新要求で指定されたＤＢ２ａ内のデータを削除する。

なお、コンピュータ２の格納手段２ｃ及びコピー手段２ｄは、コンピュータ２が備える図示しないＣＰＵ（Central Processing Unit：中央演算処理装置）によってデータ格納プログラムが実行されることにより、その処理機能が実現される。

コンピュータ３，４は、上記コンピュータ２と同様の構成とすることができる。図１の例では、コンピュータ３は、データＤ１を保持するＤＢ３ａを有している。またコンピュータ４は、データＤ２を保持するＤＢ４ａを有している。データＤ２は、データＤ１と同一内容のデータである。すなわち、図１に示したシステムで管理されているデータは、データＤ１，Ｄ２のように冗長化されている。コンピュータ５は、コンピュータ２〜４が有するＤＢに格納されているデータに、ネットワーク６を介してアクセスする。

次に、コンピュータ２が備えるＤＢ２ａ，２ｂの書き込み機構及び読み出し機構について図２を参照して説明する。なお、以下の説明では、コンピュータ５は、複数のコンピュータ２〜４それぞれが管理するデータベースに対して、オブジェクトという単位でのアクセスを行うものとする。オブジェクトは、データの管理単位の一例である。つまりコンピュータ５は、オブジェクトＩＤによって、書き込み・読み込みを行うオブジェクトを指定する。オブジェクトＩＤは、オブジェクト作成時にコンピュータ５によって決定される。

図２は、第１の実施の形態に係るデータの書き込み機構の一例を示す模式図である。図２の上段に、ＤＢ２ａ，２ｂ内のオブジェクトのレイアウトを示している。図２の下段の左に、読み出し高速型のデータ構造でデータが格納されるＤＢ２ｂへの書き込み機構を示している。図２の下段の右に、書き込み高速型のデータ構造でデータが格納されるＤＢ２ａへの書き込み機構を示している。

図２の例では、ＤＢ２ａ，２ｂそれぞれは、例えばディスク上に、オブジェクトＡ，Ｂを、ブロック状に配置して記憶している。オブジェクトＡは、複数のブロックＡ−１，Ａ−２，Ａ−３を有している。各ブロックＡ−１，Ａ−２，Ａ−３には、データが含まれている。同様にオブジェクトＢは、複数のブロックＢ−１，Ｂ−２，Ｂ−３を有している。各ブロックＢ−１，Ｂ−２，Ｂ−３には、データが含まれている。

ここで、オブジェクトＡ内のブロックＡ−１，Ａ−３のデータが更新された場合を想定する。
読み出し高速型のＤＢ２ｂに対して、更新のためにオブジェクトＡを書き込む場合には、コンピュータ２は、ランダムアクセスにより、インデックスの位置情報等に基づいて特定した書き込み箇所に、直接アクセスして書き込む。一方、ＤＢ２ｂからオブジェクトＡを読み出す場合には、シーケンシャルアクセスにより、オブジェクトＡのブロックＡ−１，Ａ−２，Ａ−３を先頭から順番に読み出す。このようにＤＢ２ｂでは、オブジェクトＡの書き込みは、ブロックごとのランダムアクセスとなるが、オブジェクトＡの読み出しは、連続したブロックへのシーケンシャルなアクセスとなる。ＤＢへのアクセスは、ランダムアクセスよりシーケンシャルアクセスの方が効率よく行うことができる。すなわち、ＤＢ２ｂは、読み出し機構の方が書き込み機構よりも効率的である。

なお読み出し高速型のＤＢ２ｂでは、データ（オブジェクト）の更新ではなく、新たなデータ（オブジェクト）の追加の場合、読み出しをシーケンシャルに行えるように、データ（オブジェクト）の再配置が行われる。例えば、データ（オブジェクト）の識別番号順となるように、並べ替えが行われる。そのため新たなデータ（オブジェクト）の追加であっても、読み出し高速型のＤＢ２ｂへの書き込みは、シーケンシャルな書き込みとはならない。

また書き込み高速型のＤＢ２ａに対して、更新のためにオブジェクトＡを書き込む場合には、コンピュータ２は、ディスクの末尾の空き領域に書き込む。一方、ＤＢ２ａからオブジェクトＡを読み出す場合には、コンピュータ２は、ランダムアクセスにより、位置情報等に基づいて特定した書き込み箇所に、直接アクセスして、オブジェクトＡのブロックＡ−１，Ａ−２，Ａ−３を読み出す。このようにＤＢ２ａでは、オブジェクトＡの書き込みは、連続したブロックへのシーケンシャルアクセスとなるが、オブジェクトＡの読み出しは、ブロックごとのランダムアクセスとなる。すなわち、ＤＢ２ａは、書き込み機構の方が読み出し機構よりも効率的である。また、ＤＢ２ａはＤＢ２ｂに比較して書き込みが効率的である。

このような構成を備えるコンピュータ２を含む情報処理システム１におけるデータ格納方法について説明する。
コンピュータ３は、ＤＢ３ａにデータＤ１を保持していると共に、コンピュータ４のＤＢ４ａにも、データＤ１と同一の内容のデータＤ２を予め保持させて、データを冗長化させている。

ここで、コンピュータ３が故障すると、コンピュータ２，４が故障の発生を検知する。例えば、各コンピュータ２〜４は、定期的に他のコンピュータの死活監視を行う。死活監視とは、システム内の他のコンピュータが動作しているかどうかを、定期的に調べる処理である。

コンピュータ４は、故障したコンピュータ３のデータＤ１と同一内容のデータＤ２を保持していることから、当該データＤ２と同一内容のデータをコンピュータ２に送信する。送信されるデータは、データＤ１と同一内容でもある。

コンピュータ２の格納手段２ｃは、コンピュータ４からデータＤ１と同一内容のデータを受信すると、効率よく書き込みが可能なＤＢ２ａに、受信したデータを格納する。コピー手段２ｄは、格納手段２ｃによりＤＢ２ａに格納されたデータを、ＤＢ２ｂにコピーする。

図３は、第１の実施の形態における冗長データの格納状況の一例を示す図である。なお、図３の例では、オブジェクト単位でデータの書き込みを行う場合の例である。コンピュータ４からコンピュータ２に対して、故障したコンピュータ３が有しているオブジェクトと同じ内容のオブジェクト７ａ，７ｂ，７ｃ・・・が転送される。転送されたオブジェクト７ａ，７ｂ，７ｃ・・・は、格納手段２ｃによってＤＢ２ａに書き込まれる。ＤＢ２ａは、書き込み高速型のデータ構造のＤＢである。そのため、ＤＢ２ａへのオブジェクト７ａ，７ｂ，７ｃ・・・の書き込みは、例えばシーケンシャルアクセスによって効率よく実行することができる。コンピュータ４からコンピュータ２へのオブジェクト７ａ，７ｂ，７ｃ・・・の転送が完了した時点で、オブジェクト７ａ，７ｂ，７ｃ・・・の冗長性は回復する。

オブジェクト７ａ，７ｂ，７ｃ・・・のＤＢ２ａへの書き込みが完了すると、コピー手段２ｄにより、オブジェクト７ａ，７ｂ，７ｃ・・・がＤＢ２ｂにコピーされる。ＤＢ２ｂは読み出し高速型のデータ構造であり、例えばランダムアクセスによる書き込みが行われる。そしてオブジェクト７ａ，７ｂ，７ｃ・・・のコピーが完了すると、例えばＤＢ２ａ内のオブジェクト７ａ，７ｂ，７ｃ・・・はすべて消去される。これにより、以後、ＤＢ２ａをリカバリ以外の用途に使用可能となり、資源の有効活用が図れる。

またリカバリ処理中であっても、コンピュータ２は、コンピュータ５からのアクセスを受け付けることができる。例えばオブジェクト７ａ，７ｂ，７ｃ・・・がＤＢ２ａに格納された後、ＤＢ２ｂへのコピー前に、オブジェクト７ａ，７ｂ，７ｃ・・・のいずれかへの読み出しアクセスがコンピュータ５から行われた場合、ＤＢ２ａからオブジェクトが読み出される。またオブジェクト７ａ，７ｂ，７ｃ・・・がＤＢ２ａに格納された後、ＤＢ２ｂへのコピー前に、オブジェクト７ａ，７ｂ，７ｃ・・・のいずれかへの更新の書き込みアクセスがコンピュータ５から行われた場合、ＤＢ２ｂに更新後のオブジェクトが書き込まれる。この場合、ＤＢ２ａに格納されている更新前のオブジェクトは削除され、コピーの対象から除外される。これにより、コピー処理の効率化が図れる。

なおオブジェクト７ａ，７ｂ，７ｃ・・・をＤＢ２ｂにコピーした後に、オブジェクト７ａ，７ｂ，７ｃ・・・のいずれかに書き込みまたは読み出しのアクセスが、コンピュータ５から行われた場合、ＤＢ２ｂに対するアクセスが行われる。

このように情報処理システム１のコンピュータ２は、故障したコンピュータ３が保持していたデータＤ１と同一内容のデータＤ２をコンピュータ４から受信すると、ＤＢ２ｂより効率よく書き込みが可能なＤＢ２ａに、受信したデータを格納するようにした。その後、コンピュータ２は、ＤＢ２ａに格納されたデータをＤＢ２ｂにコピーするようにした。

これにより、故障したコンピュータ３が保持していたデータＤ１と同一内容のデータＤ２を、コンピュータ２のＤＢ２ａへ迅速に格納することができ、データの冗長性を迅速に回復できるようになる。これにより、データロスの発生が抑制され、信頼性の低下が抑制される。

［第２の実施の形態］
次に第２の実施の形態について説明する。第２の実施の形態は、第１の実施の形態のより規模の大きなクライアント・サーバ型の分散ストレージシステムにおいて、サーバ故障時の信頼性の低下を抑制したものである。

なお第２の実施の形態では、データベースを管理する各サーバは、データをオブジェクト単位で管理する。そして複数のサーバは、故障した場合に備えてオブジェクトをグループ化する。以下、オブジェクトのグループを、スロットと呼ぶ。そして複数のサーバ２〜４が連携し、スロットごとに、ミラーリング等の技術でデータの冗長化を行う。

このようなシステムにおいて、１台のサーバが故障すると、故障したサーバのＤＢに保持されたスロット群の冗長性が低下してしまう。スロット群の冗長性の低下を抑制するために、当該スロット群を保持しているサーバ群（転送元サーバ）から新たに選択されたサーバ群（転送先サーバ）に、当該スロット群に関するデータを転送させるリカバリが実行される。

まず、第２の実施の形態に係るサーバシステムについて図４を用いて説明する。
図４は、第２の実施の形態に係るサーバシステムの一例を示す図である。サーバシステム１０は、図４に示すように、複数のＤＢサーバ１００，２００，３００，４００，５００，・・・や、その他のサーバ６００が相互に送受信可能にネットワーク２０を介して接続されている。

ＤＢサーバ１００，２００，３００，４００，５００，・・・は、ＤＢを有し、そのＤＢ内のデータを管理する。ＤＢサーバ１００，２００，３００，４００，５００，・・・は、それぞれ運用データベース（ＤＢ）１１１，２１１，３１１，４１１，５１１を有している。またＤＢサーバ１００，２００，３００，４００，５００，・・・は、それぞれリカバリＤＢ１１２，２１２，３１２，４１２，５１２を有している。運用ＤＢ１１１，２１１，３１１，４１１，５１１は、読み出し高速型のデータ構造でデータが格納される。リカバリＤＢ１１２，２１２，３１２，４１２，５１２は、書き込み高速型のデータ構造でデータが格納される。なお、運用ＤＢ１１１，２１１，３１１，４１１，５１１及びリカバリＤＢ１１２，２１２，３１２，４１２，５１２の詳細については後述する。

このようなＤＢサーバ１００，２００，３００，４００，５００，・・・は、自身が正常に稼働していることを知らせるための信号（例えばハートビート）を、ネットワーク２０を介して定期的に通知し合うことで、互いの稼働状態の監視を行っている。なおＤＢサーバ１００，２００，３００，４００，５００，・・・には、それぞれ識別子が割り振られており、サーバシステム１０内では識別子によって一意に識別される。図４の例では、ＤＢサーバ１００の識別子は「Ａ」、ＤＢサーバ２００の識別子は「Ｂ」、ＤＢサーバ３００の識別子は「Ｃ」、ＤＢサーバ４００の識別子は「Ｄ」、ＤＢサーバ５００の識別子は「Ｅ」である。

サーバ６００は、ネットワーク２０を介して、ＤＢサーバ１００，２００，３００，４００，５００，・・・が管理するＤＢにアクセスする。例えばサーバ６００は、Ｗｅｂサーバである。サーバ６００は、Ｗｅｂサーバとして機能する場合、図示しないネットワークを介して、ユーザが使用する端末装置に接続される。そしてサーバ６００は、端末装置からの要求に応じて、ＤＢサーバ１００，２００，３００，４００，５００，・・・が管理するＤＢにアクセスする。なおＤＢサーバ１００，２００，３００，４００，５００，・・・との関係においては、サーバ６００がクライアントとなる。

なお、図４では、ＤＢサーバとして機能する５台のＤＢサーバ１００，２００，３００，４００，５００，・・・を示しているが、ＤＢサーバとして機能するサーバは、６台以上あってもよい。

次に、このようなサーバシステム１０を構成するＤＢサーバ１００のハードウェアの一例について図５を用いて説明する。
図５は、第２の実施の形態に係るＤＢサーバのハードウェアの一例を示すブロック図である。

ＤＢサーバ１００は、ＣＰＵ１００ａによって装置全体が制御されている。ＣＰＵ１００ａには、バス１００ｊを介してＲＡＭ１００ｂと複数の周辺機器が接続されている。なおＤＢサーバ１００が有するＣＰＵ数は１つに限定されず、複数であってもよい。ＤＢサーバ１００が複数のＣＰＵを有する場合、複数のＣＰＵが連係動作し、装置全体を制御する。

ＲＡＭ１００ｂは、ＤＢサーバ１００の主記憶装置として使用される。ＲＡＭ１００ｂには、ＣＰＵ１００ａに実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１００ｂには、ＣＰＵ１００ａによる処理に必要な各種データが格納される。

バス１００ｊに接続されている周辺機器としては、ＨＤＤ１００ｃ、グラフィック処理装置１００ｄ、入力インタフェース１００ｅ、光学ドライブ装置１００ｆ、機器接続インタフェース１００ｇ、ネットワークインタフェース１００ｈ、及びホストバスアダプタ１００ｉがある。

ＨＤＤ１００ｃは、内蔵したディスクに対して、磁気的にデータの書き込み及び読み出しを行う。ＨＤＤ１００ｃは、ＤＢサーバ１００の補助記憶装置として使用される。ＨＤＤ１００ｃには、ＯＳのプログラム、アプリケーションプログラム、及び各種データが格納される。なお、補助記憶装置としては、フラッシュメモリ等の半導体記憶装置を使用することもできる。

グラフィック処理装置１００ｄには、モニタ２１が接続されている。グラフィック処理装置１００ｄは、ＣＰＵ１００ａからの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置等がある。

入力インタフェース１００ｅには、キーボード２２とマウス２３とが接続されている。入力インタフェース１００ｅは、キーボード２２やマウス２３から送られてくる信号をＣＰＵ１００ａに送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボール等がある。

光学ドライブ装置１００ｆは、レーザ光等を利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等がある。

機器接続インタフェース１００ｇは、ＤＢサーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１００ｇには、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１００ｇとの通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１００ｈは、ネットワーク２０に接続されている。ネットワークインタフェース１００ｈは、ネットワーク２０を介して、他のサーバまたは通信機器との間でデータの送受信を行う。

ホストバスアダプタ１００ｉは、運用ＤＢ１１１またはリカバリＤＢ１１２が構築されたＨＤＤに対して、データアクセスを行うインタフェースである。ホストバスアダプタ１００ｉは、ＣＰＵ１００ａからの指示に従って、運用ＤＢ１１１またはリカバリＤＢ１１２へのオブジェクト単位での書き込みや読み出しを行う。

以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお図５にはＤＢサーバ１００のハードウェア構成を示したが、他のＤＢサーバ２００，３００，４００，５００，・・・，サーバ６００も同様のハードウェアで実現できる。また第１の実施の形態に示したコンピュータ２〜５も、図５に示したＤＢサーバ１００と同様のハードウェアにより実現することができる。

ＤＢサーバ１００は、コンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。ＤＢサーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、ＤＢサーバ１００に実行させるプログラムをＨＤＤ１００ｃに格納しておくことができる。ＣＰＵ１００ａは、ＨＤＤ１００ｃ内のプログラムの少なくとも一部をＲＡＭ１００ｂにロードし、プログラムを実行する。またＤＢサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７等の可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばＣＰＵ１００ａからの制御により、ＨＤＤ１００ｃにインストールされた後、実行可能となる。またＣＰＵ１００ａが、可搬型記録媒体から直接プログラムを読み出して実行することもできる。なおプログラムを記録する記録媒体には、一時的な伝搬信号自体は含まれない。

プログラムを流通させる場合には、例えば、そのプログラムが記録された光ディスク２４、メモリ装置２５、メモリカード２７等の可搬型記録媒体が販売される。また、プログラムをＤＢサーバ１００の記憶装置に格納しておき、ネットワーク２０を介して、サーバからＤＢサーバ１００にそのプログラムを転送することもできる。ＤＢサーバ１００は、ネットワーク２０を介してプログラムを取得する場合、例えば取得したプログラムをＨＤＤ１００ｃに格納する。そしてＤＢサーバ１００のＣＰＵ１００ａがＨＤＤ１００ｃ内のプログラムを実行する。またＤＢサーバ１００は、他のサーバからプログラムの一部が転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

次に、このようなハードウェアを有するＤＢサーバ１００が備える機能を表す機能ブロック図について説明する。
図６は、第２の実施の形態に係るＤＢサーバの機能の一例を示すブロック図である。

ＤＢサーバ１００は、運用ＤＢ１１１及びリカバリＤＢ１１２を備える。
運用ＤＢ１１１は、サーバ６００が使用するデータを格納するデータベースである。運用ＤＢ１１１は、オブジェクト単位のデータを格納する。また、運用ＤＢ１１１は、シーケンシャルに読み出しを行うことができるデータ配列で、データが格納されている。

リカバリＤＢ１１２は、リカバリ処理実行時に使用されるデータベースである。リカバリＤＢ１１２は、運用ＤＢ１１１と同様にオブジェクト単位のデータを格納する。また、リカバリＤＢ１１２は、シーケンシャルに書き込みを行うことができるデータ配列で、データが格納されている。

また、ＤＢサーバ１００は、サーバ状態管理テーブル１１３と、スロット格納管理テーブル１１４、リカバリ中オブジェクト一覧１１５を備える。なお、サーバ状態管理テーブル１１３と、スロット格納管理テーブル１１４、リカバリ中オブジェクト一覧１１５は、例えばＲＡＭ１００ｂまたはＨＤＤ１００ｃに格納されている。

以下、各テーブルについて図７〜図９を用いて説明する。
図７は、第２の実施の形態に係るサーバ状態管理テーブルの一例を示す図である。サーバ状態管理テーブル１１３は、ＤＢサーバ１００以外のＤＢサーバ２００，３００，４００，５００，・・・の稼働状態を表すサーバ状態情報を記録するものである。例えば、サーバ状態管理テーブル１１３には、ＤＢサーバ２００，３００，４００，５００，・・・の識別子に対応付けて、サーバの稼働状態が設定されている。図７の例では、識別子「Ｂ，Ｃ，Ｅ，Ｆ」の各サーバに対しては稼働中を表す「１」が、識別子「Ｄ」のサーバに対しては故障中を表す「０」がそれぞれ記録されている。

このようなサーバ状態管理テーブル１１３は、ＤＢサーバ１００によって、他のサーバから正常に稼働していることを通知する信号を受信するごとに、更新される。またサーバ状態管理テーブル１１３は、ＤＢサーバ１００によって、正常に稼働していることを通知する信号が途絶えたサーバを検出した場合には、そのサーバの稼働状態が、故障中を表す「０」に更新される。

図８は、第２の実施の形態に係るスロット格納管理テーブルの一例を示す図である。スロット格納管理テーブル１１４は、サーバシステム１０内における、各スロットの格納先を表すスロット格納情報を保持する。スロットは、冗長化の単位であり、１つのスロットには複数のオブジェクトが含まれる。例えば、スロットの数は固定されている。図８の例では、スロットの数は６４である。オブジェクトは所定のルールにより、いずれかのスロットに分類される。所定のルールとは、たとえば「オブジェクトＩＤを６４で割った余りの値を、そのオブジェクトが属するスロットの番号とする」等である。

図８の例では、スロット３は、プライマリとしてサーバＢに、バックアップとしてサーバＦにそれぞれ格納されている。また、スロット６２は、プライマリとしてサーバＦに、バックアップとしてサーバＣにそれぞれ格納されている。

ＤＢサーバ１００以外のＤＢサーバ２００，３００，４００，５００，・・・も、図８と同様のスロット格納管理テーブルを有し、スロット格納管理テーブルの内容は、全サーバで共通となる。例えば各ＤＢサーバ１００，２００，３００，４００，５００，・・・は、定期的に（例えば、ハートビートのタイミングで）同期をとり、スロット格納管理テーブルの内容の共通性を維持する。

図９は、第２の実施の形態に係るリカバリ中オブジェクト一覧の一例を示す図である。リカバリ中オブジェクト一覧１１５は、リカバリ処理により、ＤＢサーバ１００のリカバリＤＢ１１２に対して格納されたオブジェクトの識別情報を保持する。例えば、図９に示す場合では、ＤＢサーバ１００では、リカバリＤＢ１１２に対してオブジェクト３，・・・，オブジェクト２４の書き込みを行うことを表している。また、リカバリＤＢ１１２から運用ＤＢ１１１に、リカバリ対象のオブジェクトのコピーが完了すると、ＤＢサーバ１００により、コピーが完了したオブジェクトの識別情報が、リカバリ中オブジェクト一覧１１５から削除される。さらに、リカバリ中のオブジェクトに対するサーバ６００からの書き込み要求により、そのオブジェクトが運用ＤＢ１１１に書き込まれた場合、そのオブジェクトの識別情報が、リカバリ中オブジェクト一覧１１５から削除される。

図６の説明に戻る。ＤＢサーバ１００は、図７〜図９に示したようなテーブル等の情報を用いて、リカバリ処理を実行する。そのためにＤＢサーバ１００は、受信部１２１、サーバ状態監視部１２２、スロット格納先特定部１２３、コピー先決定部１２４、送信部１２５、スロット管理更新部１２６、コピー先判定部１２７、リクエスト処理部１２８、及びＤＢ管理部１２９を有する。

受信部１２１は、他のサーバからデータ等を受信する。受信部１２１が受信する情報には、リカバリ処理により送信されたオブジェクトの書き込み要求が含まれる。また受信部１２１は、サーバ６００からのオブジェクトへの、書き込みまたは読み出しのアクセス要求も受信する。

サーバ状態監視部１２２は、他のＤＢサーバが稼働中なのか、故障中なのかを監視する。例えば、サーバ状態監視部１２２は、他のサーバが稼働中であることを示す信号（ハートビート）を、他のサーバそれぞれから定期的に受信できているか否かを監視する。またサーバ状態監視部１２２は、ＤＢサーバ１００が稼働中であることを示す情報を、他のサーバに対して定期的に送信する。

さらにサーバ状態監視部１２２は、定期的に（例えばハートビートのタイミングで）他のすべてのＤＢサーバに対して、「自分から見て、他のどのサーバが動作中であると確認できていて、どのサーバが動作中であると確認できていないのか」という死活情報を送る。動作中であると確認できているサーバとは、定期的にハートビートを受信できているサーバである。また動作中であると確認できていないサーバとは、所定期間以上ハートビートが途絶しているサーバである。他のサーバのサーバ状態監視部も、同様に死活情報の送信を行う。サーバ状態監視部１２２は、自身の監視による死活情報と、他のサーバから受信した死活情報とを、サーバごとに集計する。そしてサーバ状態監視部１２２は、集計した結果、過半数のサーバによって「動作中であると確認できていない」と判断されたサーバを、故障していると判断する。サーバ状態監視部１２２は、あるサーバが故障していると判断した場合、直ちに、そのサーバが故障していることを、他のすべてのＤＢサーバに通知する。これにより、サーバの故障に関する情報が、すべてのサーバで共有される。

サーバ状態監視部１２２は、サーバ状態管理テーブル１１３における、故障していると判断されたサーバの状態情報を、故障中を示す情報に更新する。またサーバ状態監視部１２２は、故障状態となったサーバからハートビートを受信した場合、サーバ状態管理テーブル１１３における、そのサーバの稼働状態を、稼働中を示す情報に更新する。

スロット格納先特定部１２３は、スロット格納管理テーブル１１４を参照して、サーバ状態監視部１２２の監視により見いだされた故障中のサーバが保持するスロットを判断する。さらにスロット格納先特定部１２３は、故障中のサーバが保持するスロットと同じ内容のスロット（冗長データ）を格納しているサーバを特定する。例えば故障中のサーバが保持するスロットがプライマリであれば、そのスロットのバックアップを保持しているサーバが特定される。また故障中のサーバが保持するスロットがバックアップであれば、そのスロットのプライマリを保持するサーバが特定される。

コピー先決定部１２４は、スロット格納先特定部１２３が特定したサーバがＤＢサーバ１００自身である場合、運用ＤＢ１１１に保持するスロットのコピー先のＤＢサーバを決定する。例えばコピー先決定部１２４は、サーバシステム１０の自身を除くＤＢサーバ１００からランダムに選択されて決定される。そしてコピー先決定部１２４は、決定したコピー先のＤＢサーバが、故障したＤＢサーバのスロットであり、自身の運用ＤＢ１１１に冗長データが格納されているスロットを保持するように、スロット格納情報の更新要求を、スロット管理更新部１２６及び送信部１２５に通知する。

送信部１２５は、コピー先決定部１２４が決定したコピー先のＤＢサーバに、自身の運用ＤＢ１１１が格納する故障したＤＢサーバのスロットを送信する。また送信部１２５は、コピー先決定部１２４から通知されたスロット格納情報の更新要求を他の全ＤＢサーバに対して送信する。

また、スロット管理更新部１２６は、他のＤＢサーバ並びにコピー先決定部１２４それぞれから通知されたスロット格納情報の更新要求に基づき、スロット格納管理テーブル１１４を更新する。

コピー先判定部１２７は、スロット管理更新部１２６によるスロット格納管理テーブル１１４の更新内容を参照して、故障したＤＢサーバのスロットのコピー先として、自身が決定されているか否かを判定する。コピー先判定部１２７は、故障したＤＢサーバのスロットのコピー先として、自身が決定されている場合、リカバリＤＢの作成要求をＤＢ管理部１２９に通知する。

リクエスト処理部１２８は、受信部１２１から、書き込みまたは読み出し要求を取得する。リクエスト処理部１２８は、書き込みまたは読み出し要求が、リカバリ処理によるコピー要求なのか、サーバ６００からの書き込みまたは読み出しのアクセス要求なのかを判断する。例えば、リカバリ時のコピーは、クライアント及び他のサーバから行われる通常の書き込みアクセスとは異なるコマンドで行われる。この場合、リクエスト処理部１２８は、コマンドの種別に応じて格納先のＤＢを選択することができる。そして、リクエスト処理部１２８は、判断結果に応じたオブジェクトの書き込みまたは読み出し実行要求をＤＢ管理部１２９に通知する。

ＤＢ管理部１２９は、運用ＤＢ１１１及びリカバリＤＢ１１２を管理する。ＤＢ管理部１２９は、書き込み高速型のＤＢＭＳ（Database Management System）と、読み出し高速型のＤＢＭＳとを有している。そしてＤＢ管理部１２９は、運用ＤＢ１１１を読み出し高速型のＤＢＭＳで管理し、リカバリＤＢ１１２を書き込み高速型のＤＢＭＳで管理する。例えばＤＢ管理部１２９は、リクエスト処理部１２８からのスロットの書き込みまたは読み出し実行要求に応じて、運用ＤＢ１１１またはリカバリＤＢ１１２にオブジェクトの書き込み、またはオブジェクトの読み出しを行う。またＤＢ管理部１２９は、コピー先判定部１２７からのリカバリＤＢ１１２の作成要求に応じて、未使用のＨＤＤ上にリカバリＤＢ１１２を作成する。このときＤＢ管理部１２９は、リカバリＤＢとして、書き込み高速型のデータ構造のＤＢを構築する。そしてＤＢ管理部１２９は、リカバリ対象のスロットに含まれるオブジェクトを受信すると、そのオブジェクトをリカバリＤＢ１１２に格納する。ＤＢサーバ１００がコピー先となっている全スロットのオブジェクトのリカバリＤＢ１１２への書き込みが完了すると、ＤＢ管理部１２９は、リカバリＤＢ１１２に書き込んだオブジェクトを運用ＤＢ１１１にコピーし、リカバリＤＢ１１２を初期化する。

さらにＤＢ管理部１２９は、リカバリ対象のスロットに属するオブジェクトがリカバリ中か否かを、リカバリ中オブジェクト一覧１１５によって管理する。例えばコピー対象のスロットに含まれるオブジェクトをリカバリＤＢ１１２に格納すると、リカバリ中オブジェクト一覧１１５に、格納したオブジェクトの識別情報を格納する。またＤＢ管理部１２９は、リカバリＤＢ１１２から運用ＤＢ１１１にコピーしたオブジェクトの識別情報を、リカバリ中オブジェクト一覧１１５から削除する。

ＤＢ管理部１２９は、リカバリ中オブジェクト一覧１１５に基づいて、リカバリ対象のスロットに含まれるオブジェクトがリカバリ中か否かを把握する。そしてＤＢ管理部１２９は、サーバ１００からリカバリ中のオブジェクトの読み出し要求があれば、リカバリＤＢ１１２から要求に応じたオブジェクトを読み出す。またＤＢ管理部１１２は、サーバ１００からリカバリ中のオブジェクトの書き込み要求があれば、運用ＤＢ１１１にそのオブジェクトを書き込み、リカバリ中オブジェクト一覧から、そのオブジェクトの識別情報を削除する。

なお、図６に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図６にはＤＢサーバ１００の機能を示したが、他のＤＢサーバ２００，３００，４００，５００，・・・も、ＤＢサーバ１００と同様の機能を有している。またＤＢ管理部１２９は、図１に示した第１の実施の形態における、格納手段２ｃ、コピー手段２ｄ、及びデータ更新手段２ｅの機能を包含する要素の一例である。

このような機能を備えるＤＢサーバ１００を含むサーバシステム１０において、ＤＢサーバに故障が生じた場合のデータのやりとりの一例について図１０を用いて説明する。
図１０は、第２の実施の形態に係るサーバシステムのデータのやりとりの一例を示す図である。

サーバシステム１０は、既述の通り、複数のＤＢサーバが相互に送受信可能にネットワーク２０を介して接続されている。
この際に、例えば、図１０に示すように、ＤＢサーバ１００，２００，３００，４００，５００，・・・のうち、ＤＢサーバ２００が故障した場合を想定する。この場合には、ＤＢサーバ２００に格納されていた複数のスロットそれぞれを保持する他のＤＢサーバ１００，３００，４００，５００，・・・が相互にコピー元、コピー先となり、ＤＢサーバ２００が保持していたスロットに含まれるオブジェクトがコピーされる。このようにして、ＤＢサーバ１００，３００，４００，５００，・・・間では、スロットに含まれるオブジェクトの送受信が行われることにより、ＤＢサーバ２００に格納されていた複数のスロットの冗長化が迅速に回復される。

このようなサーバシステム１０から１つのＤＢサーバ１００がコピー元、コピー先になり行われる処理について説明する。なお、以下では、ＤＢサーバ２００が故障した場合を例に挙げる。

まず、ＤＢサーバ１００がコピー元となり、ＤＢサーバ３００に対してスロットのコピー実行を通知する処理について図１１を用いて説明する。
図１１は、第２の実施の形態に係るＤＢサーバのスロットのコピー実行通知の処理手順の一例を示すフローチャートである。

［ステップＳ１１］ ＤＢサーバ１００において、受信部１２１が他のＤＢサーバから稼働状態を表すサーバ状態情報を受信する。
［ステップＳ１２］ サーバ状態監視部１２２は、受信部１２１が受信したサーバ状態情報に基づき、サーバ状態管理テーブル１１３を更新する。

［ステップＳ１３］ サーバ状態監視部１２２は、更新したサーバ状態管理テーブル１１３を参照して、故障している他のＤＢサーバの有無を判定する。
故障している他のＤＢサーバが存在している場合（例えば、ＤＢサーバ２００）には、ＤＢサーバ１００はステップＳ１４の処理を実行する。存在していない場合には、スロットのコピー実行通知の処理を終了する。

［ステップＳ１４］ スロット格納先特定部１２３は、スロット格納管理テーブル１１４を参照して、サーバ状態監視部１２２の監視により見いだされた故障中のＤＢサーバ２００が保持するスロットを格納しているＤＢサーバ１００を特定する。

特定したＤＢサーバ１００が自身のＤＢサーバ１００である場合には、ＤＢサーバ１００はステップＳ１５の処理を実行する。自身以外の他のＤＢサーバである場合には、スロットのコピー実行通知の処理を終了する。

［ステップＳ１５］ コピー先決定部１２４は、ＤＢサーバ１００の運用ＤＢ１１１に格納されているスロットのコピー先である別のＤＢサーバ（例えば、ＤＢサーバ３００）をランダムに決定する。

［ステップＳ１６］ コピー先決定部１２４は、ステップＳ１５でコピー先として決定したＤＢサーバ３００が、ＤＢサーバ１００が格納する故障したＤＢサーバ２００のスロットを保持するようにスロット格納情報の更新要求をスロット管理更新部１２６及び送信部１２５に通知する。

スロット管理更新部１２６は、コピー先決定部１２４からの更新要求に基づき、スロット格納管理テーブル１１４を更新する。
［ステップＳ１７］ 送信部１２５は、コピー先決定部１２４から通知されたスロット格納情報の更新要求を、自身を除く全ＤＢサーバ３００，４００，５００，・・・に対して送信する。

［ステップＳ１８］ 送信部１２５は、コピー先として決定したＤＢサーバ３００に対して、自身が格納する故障したＤＢサーバ２００のスロットに含まれるオブジェクトと共に、当該スロットのコピー実行通知を送信する。

サーバ状態情報を受信するごとにこのような処理が実行されて、ＤＢサーバ３００には、サーバ状態情報の更新要求、並びに、故障したＤＢサーバ２００に格納されているスロットと共に、当該スロットのコピー実行通知がＤＢサーバ１００から送信される。

図１１に示すようなスロットのコピー実行通知処理が、故障したＤＢサーバ２００に格納されているスロットと同一内容のスロットを保持するすべてのＤＢサーバで実行される。次にスロットのコピー実行通知をＤＢサーバ１００が受信した場合に、ＤＢサーバ１００で実行されるリカバリ処理について図１２を用いて説明する。

図１２は、第２の実施の形態に係るＤＢサーバのリカバリ処理手順の一例を示すフローチャートである。
［ステップＳ２１］ ＤＢサーバ１００の受信部１２１は、他のＤＢサーバ３００，４００，５００，・・・からスロット格納情報の更新要求を受信する。この際、複数のＤＢサーバ４００，５００，・・・からスロット格納情報の更新要求が通知される可能性がある。そこで受信部１２１は、例えば、最初のスロット格納情報の更新要求の受信から一定の時間だけ、他のＤＢサーバからのスロット格納情報の更新要求の受信を待ち、その後、次のステップＳ２２の処理を開始する。

［ステップＳ２２］ スロット管理更新部１２６は、他のＤＢサーバから受信したスロット格納情報に基づき、スロット格納管理テーブル１１４を更新する。
［ステップＳ２３］ コピー先判定部１２７は、更新されたスロット格納管理テーブル１１４を参照して、ＤＢサーバ１００自身がスロットのコピー先として決定されているか否かを判別する。

ＤＢサーバ１００自身がスロットのコピー先として決定されている場合には、ＤＢサーバ１００はステップＳ２４の処理を実行する。ＤＢサーバ１００がコピー先として決定されていない場合には、リカバリ処理を終了する。

［ステップＳ２４］ ＤＢ管理部１２９は、未使用のＨＤＤ中に書き込み速度を速く設定したリカバリＤＢ１１２を割り当てる。
［ステップＳ２５］ ＤＢ管理部１２９は、ＤＢサーバ３００から送信されたスロットのオブジェクトをリカバリＤＢ１１２に書き込む。このときＤＢ管理部１２９は、リカバリ中オブジェクト一覧１１５に、書き込んだオブジェクトの識別情報を登録する。

［ステップＳ２６］ ＤＢ管理部１２９は、リカバリＤＢ１１２に対する、リカバリ対象のスロットのオブジェクトのコピーが完了すると、リカバリＤＢ１１２に格納されたオブジェクトを運用ＤＢ１１１に書き込む。このときＤＢ管理部１２９は、リカバリ中オブジェクト一覧１１５から、書き込んだオブジェクトの識別情報を削除する。

［ステップＳ２７］ ＤＢ管理部１２９は、リカバリ対象のスロットのオブジェクトの運用ＤＢ１１１に対する書き込みが完了すると、リカバリＤＢ１１２を初期化する。例えばＤＢ管理部１２９は、リカバリ中オブジェクト一覧１１５からすべてのオブジェクトの識別情報が削除されたときに、リカバリ対象のスロットのオブジェクトの運用ＤＢ１１１に対する書き込みが完了したと判断する。なお初期化処理では、リカバリＤＢ１１２に書き込まれたすべてのオブジェクトが消去される。

スロット格納情報の更新要求が通知されるごとに、このような処理が実行される。これにより、故障したＤＢサーバ２００が保持していたスロットと同一内容のスロットを、他のＤＢサーバ１００，３００，４００，５００，・・・のリカバリＤＢ１１２，３１２，４１２，５１２，・・・へ迅速に格納することができる。その結果、スロットの冗長性を迅速に回復できるようになる。しかも、リカバリ処理完了後にリカバリＤＢを初期化するため、その後、リカバリＤＢとして使用したＨＤＤを他の用途で使用することもできる。その結果、ＨＤＤ資源の有効活用が可能となる。

次に、ＤＢサーバ１００において、サーバ６００から、リカバリ対象のスロットに含まれるオブジェクトの書き込み要求が通知された場合の処理について図１３を用いて説明する。

図１３は、第２の実施の形態に係るＤＢサーバの書き込み処理手順の一例を示すフローチャートである。
［ステップＳ３１］ ＤＢサーバ１００の受信部１２１は、サーバ６００からＤＢサーバ２００に格納していたものと同じスロットに含まれるオブジェクトの書き込み要求を受信する。

［ステップＳ３２］ リクエスト処理部１２８は、サーバ６００から書き込み要求が通知されたことを判定して、ＤＢ管理部１２９に書き込み対象のオブジェクトがリカバリ中オブジェクト一覧１１５に含まれているか否かの判定要求を通知する。

ＤＢ管理部１２９は、書き込み対象のオブジェクトがリカバリ中オブジェクト一覧１１５に含まれているか否かを判定する。
当該オブジェクトがリカバリ中オブジェクト一覧１１５に含まれている場合には、ＤＢサーバ１００は、ステップＳ３３の処理を実行する。含まれていない場合には、ＤＢサーバ１００は、ステップＳ３５の処理を実行する。

［ステップＳ３３］ ＤＢ管理部１２９は、書き込み対象のオブジェクトを運用ＤＢ１１１に書き込む。
なお、この際、リカバリＤＢ１１２には、書き込み対象のオブジェクトが格納されている。

［ステップＳ３４］ ＤＢ管理部１２９は、運用ＤＢ１１１に対する書き込み対象オブジェクトの書き込みが完了すると、リカバリ中オブジェクト一覧から、書き込みを行ったオブジェクトの識別情報を削除する。またＤＢ管理部１２９は、書き込みを行ったオブジェクトに対応するリカバリＤＢ１１２内のオブジェクトを削除する。その後、書き込み処理が終了する。

［ステップＳ３５］ ＤＢ管理部１２９は、書き込み対象オブジェクトを運用ＤＢ１１１に書き込む。その後、書き込み処理が終了する。
サーバ６００からオブジェクトの書き込み要求が通知されるごとに、このような処理が実行される。

次に、ＤＢサーバ１００において、サーバ６００から、リカバリ対象のスロットに含まれるオブジェクトの読み出し要求が通知された場合の処理について図１４を用いて説明する。

図１４は、第２の実施の形態に係るＤＢサーバの読み出し処理手順の一例を示すフローチャートである。
［ステップＳ４１］ ＤＢサーバ１００の受信部１２１は、サーバ６００からＤＢサーバ２００に格納していたものと同じオブジェクトの読み出し要求を受信する。

［ステップＳ４２］ リクエスト処理部１２８は、サーバ６００から読み出し要求が通知されたことを判定して、ＤＢ管理部１２９に読み出し対象のオブジェクトがリカバリ中オブジェクト一覧１１５に含まれているか否かの判定要求を通知する。

ＤＢ管理部１２９は、読み出し対象のオブジェクトがリカバリ中オブジェクト一覧１１５に含まれているか否かを判定する。
当該オブジェクトがリカバリ中オブジェクト一覧１１５に含まれている場合には、ＤＢサーバ１００は、ステップＳ４３の処理を実行する。含まれていない場合には、ＤＢサーバ１００は、ステップＳ４４の処理を実行する。

［ステップＳ４３］ ＤＢ管理部１２９は、リカバリＤＢ１１２から、読み出し対象のオブジェクトを読み出す。その後、読み出し処理が終了する。
［ステップＳ４４］ ＤＢ管理部１２９は、運用ＤＢ１１１から、読み出し対象のオブジェクトを読み出す。その後、読み出し処理が終了する。

サーバ６００からオブジェクトの読み出し要求が通知されるごとに、上記処理が実行されて、読み出したオブジェクトがサーバ６００に送信される。図１２で説明したように、故障したＤＢサーバ２００が保持していたスロットの他のＤＢサーバのリカバリＤＢへの格納は、迅速に行われる。そのため、上記の読み出し処理時には、リカバリ対象のスロットに含まれるオブジェクトの読み出し要求に対してデータロスが発生せずに、正常にオブジェクトを読み出すことができるようになる。

このように第２の実施の形態では、ＤＢサーバ１００は、故障したＤＢサーバ２００が保持していたスロットと同一内容のスロットを受信すると、運用ＤＢ１１１より効率よく書き込みが可能なリカバリＤＢ１１２に、該受信したスロットを格納する。そしてＤＢサーバ１００は、リカバリＤＢ１１２に格納されたスロットを運用ＤＢ１１１にコピーするようにした。

これにより、故障したＤＢサーバ２００が保持していたスロットを、他のＤＢサーバのリカバリＤＢへの格納を迅速に行うことができ、スロットの冗長性を迅速に回復できるようになる。このためサーバ６００からのオブジェクトの読み出しアクセスに対してデータロスの発生を抑制し、信頼性の低下を抑制することができるようになる。

［第３の実施の形態］
第３の実施の形態では、複数のＨＤＤを別途用意して、リカバリ処理を実行する際に、用意しておいたＨＤＤをサーバに接続するものである。

図１５は、第３の実施の形態に係るサーバシステムの一例を示す図である。図１５に示すサーバシステム７００には、ネットワーク７０１を介して複数のＤＢサーバ７１１〜７１５、サーバ７２０、及び管理サーバ７３０が接続されている。また複数のＤＢサーバ７１１〜７１５と管理サーバ７３０とは、ストレージネットワークスイッチ７０２を介して、複数のＨＤＤ７４１〜７５１に接続されている。ストレージネットワークスイッチ７０２は、例えばＳＡＮ（Storage Area Network）スイッチである。

ＤＢサーバ７１１〜７１５は、第２の実施の形態に示したＤＢサーバ１００と同じ機能を有していると共に、他のＤＢサーバの故障を検出した際に、ＨＤＤ割当要求を管理サーバ７３０に送信する機能を有している。サーバ７２０は、第２の実施の形態に示したサーバ６００と同じ機能を有している。

管理サーバ７３０は、ＤＢサーバ７１１〜７１５へのＨＤＤ７４１〜７５１の割り当てを管理する。管理サーバ７３０からＨＤＤの割り当てを受けたＤＢサーバは、そのＨＤＤをローカルのＨＤＤとして使用できる。例えばＤＢサーバは、割り当てられたＨＤＤを運用ＤＢまたはリカバリＤＢとして使用できる。

このような構成のサーバシステム７００において、すべてのＤＢサーバ７１１〜７１５が正常に動作している間は、運用ＤＢとして用いるＨＤＤが各ＤＢサーバに割り当てられる。

図１６は、第３の実施の形態においてＤＢサーバが正常動作時のＤＢサーバへのＨＤＤ割り当て状況の一例を示す図である。図１６の例では、各ＤＢサーバ７１１〜７１５には、それぞれ１台ずつのＨＤＤ７４１〜７４５が割り当てられている。各ＤＢサーバ７１１〜７１５は、割り当てられたＨＤＤ７４１〜７４５に読み出し高速型のデータ構造のデータベースを構築し、運用ＤＢとして使用する。

ＤＢサーバ７１１〜７１５のいずれにも割り当てられていないＨＤＤ７４６〜７５１は、ＨＤＤプールとして管理される。ＨＤＤプールは未使用のＨＤＤである。管理サーバ７３０は、いずれかのＤＢサーバからＨＤＤ割り当て要求を受信すると、ＨＤＤプールに属するＨＤＤからＨＤＤを選択し、選択したＨＤＤをそのＤＢサーバに割り当てる。

ここで、図１６に示すような状況でサーバシステム７００が運用されているときに、ＤＢサーバ７１１が故障した場合を想定する。
図１７は、第３の実施の形態において１台のＤＢサーバが故障したときのサーバシステムの運用状況の一例を示す図である。ＤＢサーバ７１１が故障すると、第２の実施の形態と同様に、他のＤＢサーバ７１２〜７１５がＤＢサーバ７１１の故障を検知する。このとき第３の実施の形態では、ＤＢサーバ７１１の故障を検知したＤＢサーバ７１２〜７１５それぞれが、管理サーバ７３０にＨＤＤ割り当て要求を送信する。このＨＤＤ割り当て要求に応答し、管理サーバ７３０が、ＤＢサーバ７１２〜７１５に対してＨＤＤの追加割り当てを行う。

図１８は、第３の実施の形態においてＨＤＤ追加割り当て後のサーバシステムの運用状況の一例を示す図である。故障したＤＢサーバ７１１以外のＤＢサーバ７１２〜７１５には、それぞれ１台ずつのＨＤＤ７４６〜７４９が追加で割り当てられている。ＤＢサーバ７１２〜７１５は、それぞれ追加で割り当てられたＨＤＤ７４６〜７４９をリカバリＤＢとして使用する。すなわちＤＢサーバ７１２〜７１５は、ＨＤＤ７４６〜７４９に、書き込み高速型のデータ構造のデータベースを構築する。その後、第２の実施の形態と同様に、リカバリＤＢを用いたリカバリ処理が実行される。すなわち、各ＤＢサーバ７１２〜７１５は、リカバリ対象のスロットに含まれるオブジェクトを受信すると、そのオブジェクトをリカバリＤＢとして使用するＨＤＤ７４６〜７４９に書き込む。リカバリ対象のスロットに含まれるオブジェクトのＤＢサーバ間での受け渡しが完了すると、各ＤＢサーバ７１２〜７１５は、それぞれリカバリＤＢとして使用しているＨＤＤ７４６〜７４９内のオブジェクトを、運用ＤＢとして使用しているＨＤＤ７４２〜７４５にコピーする。

各ＤＢサーバ７１２〜７１５は、リカバリＤＢとして使用しているＨＤＤ７４６〜７４９から運用ＤＢとして使用しているＨＤＤ７４２〜７４５へのオブジェクトのコピーが完了すると、リカバリＤＢとして使用しているＨＤＤ７４６〜７４９を初期化する。そしてＤＢサーバ７１２〜７１５は、リカバリＤＢとして使用しているＨＤＤ７４６〜７４９の返却要求を管理サーバ７３０に送信する。すると、管理サーバ７３０は、ＤＢサーバ７１２〜７１５へのＨＤＤ７４６〜７４９の割り当てを解除し、ＨＤＤ７４６〜７４９をＨＤＤプールに属するものとして管理する。

このように、リカバリＤＢを使用するときだけ、一時的にＨＤＤをＤＢサーバに割り当てることで、ＨＤＤ資源を有効に利用することができる。
［その他の実施の形態］
第１・第２の実施の形態では、ＨＤＤ内にＤＢを構築するものとしているが、ＨＤＤ以外の記憶装置にＤＢを構築してもよい。例えばＳＳＤにＤＢを構築することもできる。またＨＤＤに代えて、ＲＡＩＤ（Redundant Array of Inexpensive Disks）装置を用いることもできる。

なお上記の実施の形態では、ＣＰＵ１００ａがプログラムを実行することによって実現するものとしたが、プログラムで記述された処理の一部を、電子回路に置き換えることが可能である。例えば、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）等の電子回路で実現してもよい。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ 情報処理システム
２，３，４，５ コンピュータ
２ａ，２ｂ，３ａ，４ａ データベース
２ｃ 格納手段
２ｄ コピー手段
２ｅ データ更新手段
６ ネットワーク
Ｄ１，Ｄ２ データ

Claims (7)

1. 故障した第１の装置が保持していたデータと同一内容のデータを第２の装置から受信すると、読み出しがランダムアクセスとなり、書き込みがシーケンシャルアクセスとなるデータ構造の第１のデータベースに、該受信したデータを格納する格納手段と、
   前記第１のデータベースに格納されたデータを、書き込みがランダムアクセスとなり、読み出しがシーケンシャルアクセスとなるデータ構造の第２のデータベースにコピーするコピー手段と、
   を有するコンピュータ。
2. 前記格納手段は、前記第１の装置が保持していたデータのうちの少なくとも１つのデータの識別情報を前記第２の装置から受信し、該受信した識別情報それぞれに対応するデータを受信した場合に、データ受信完了と判断し、
   前記コピー手段は、前記格納手段がデータ受信完了と判断した後、コピーを開始する、
   ことを特徴とする請求項１記載のコンピュータ。
3. 前記格納手段は、前記第１の装置の故障を検知すると、未使用のストレージ装置内に前記第１のデータベースを構築し、前記第１のデータベースに格納したデータの前記第２のデータベースへのコピーが完了すると、前記ストレージ装置内の前記第１のデータベースを消去することを特徴とする請求項１または２記載のコンピュータ。
4. 前記第１のデータベースに格納され、前記第２のデータベースへのコピーが済んでいないデータの更新要求を受信すると、該更新要求に含まれている更新後のデータを前記第２のデータベースに書き込み、該更新要求で指定された前記第１のデータベース内の更新元のデータを削除するデータ更新手段をさらに有することを特徴とする請求項１乃至３のいずれかに記載のコンピュータ。
5. コンピュータが、
   故障した第１の装置が保持していたデータと同一内容のデータを第２の装置から受信すると、読み出しがランダムアクセスとなり、書き込みがシーケンシャルアクセスとなるデータ構造の第１のデータベースに、該受信したデータを格納し、
   前記第１のデータベースに格納されたデータを、書き込みがランダムアクセスとなり、読み出しがシーケンシャルアクセスとなるデータ構造の第２のデータベースにコピーする、
   データ格納方法。
   
6. コンピュータに、
   故障した第１の装置が保持していたデータと同一内容のデータを第２の装置から受信すると、読み出しがランダムアクセスとなり、書き込みがシーケンシャルアクセスとなるデータ構造の第１のデータベースに、該受信したデータを格納し、
   前記第１のデータベースに格納されたデータを、書き込みがランダムアクセスとなり、読み出しがシーケンシャルアクセスとなるデータ構造の第２のデータベースにコピーする、
   処理を実行させるデータ格納プログラム。
7. ネットワークを介して接続されたコンピュータの故障を検知すると、該故障したコンピュータが保持するデータと同一内容のデータを、第１のデータベース内から読み出し、該読み出したデータを、前記ネットワークを介して送信する第１のコンピュータと、
   前記第１のコンピュータが送信したデータを、前記ネットワークを介して受信し、読み出しがランダムアクセスとなり、書き込みがシーケンシャルアクセスとなるデータ構造の第２のデータベースに、該受信したデータを格納し、前記第２のデータベースに格納されたデータを、書き込みがランダムアクセスとなり、読み出しがシーケンシャルアクセスとなるデータ構造の第３のデータベースにコピーする第２のコンピュータと、
   を有する情報処理システム。

Images