JP4920248B2

JP4920248B2 - サーバの障害回復方法及びデータベースシステム

Info

Publication number: JP4920248B2
Application number: JP2005348918A
Authority: JP
Inventors: 恒彦馬場; 憲宏原
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2005-12-02
Filing date: 2005-12-02
Publication date: 2012-04-18
Anticipated expiration: 2025-12-02
Also published as: JP2007156679A; US20070130220A1

Description

本発明は無共有型データベース管理システム（ＤＢＭＳ）を構築する障害許容性のあるコンピュータシステムに関し、特にＤＢＭＳ内のコンピュータのプログラム若しくはオペレーティングシステムに障害があった時に、障害の発生したコンピュータを取り除いた構成へと縮退する技術に関する。

無共有型データベース管理システム（以下、ＤＢＭＳ）では、トランザクションを処理するＤＢサーバと処理結果を保存するデータ領域が論理的または物理的に１対１に対応する。また、ＤＢＭＳの性能は、各コンピュータ（ノード）が均一な性能を持つ場合、そのノード上のＤＢサーバが有するデータ領域の量に依存する。そのため、ＤＢＭＳの性能の劣化を抑えるためには各ノードのＤＢサーバが有するデータ領域が同量である必要がある。

ここで、あるノードで障害が発生した場合に、障害が発生したノード（障害ノード）上のＤＢサーバとそのＤＢサーバが利用するデータとを別のノードに引き継ぐ系切り替え手法を無共有ＤＢＭＳに適用する場合を考える。この場合、ＤＢサーバが稼動するノードで障害が発生した場合、障害ノード上のＤＢサーバ（障害ＤＢサーバ）とその障害ＤＢサーバが有するデータ領域とを対とし、稼動中の別のノードに引き継ぎ、引継ぎ先のノード上で回復処理が行なわれる。

この系切り替え手法では、障害ＤＢサーバと同一の構成でＤＢサーバとデータ領域とを一対として別のノードに引き継ぐため、障害発生後のＤＢＭＳの性能を最大限に引き出すためには、他ノードに均等にＤＢサーバを分配することが必要であり、ノード当たりのＤＢサーバ数を事前に設計しておく必要がある。たとえば、ＮノードのＤＢＭＳの場合、１ノード障害に対応するためには、稼動中の（Ｎ−１）台に均等分配されるように、（Ｎ−１）の倍数となるＤＢサーバを１ノード当たりに用意しておく必要がある。

一方で、近年、システムの複雑化・大規模化に伴い、ＤＢＭＳが扱うデータ量も増大しており、ＤＢＭＳはクラスタ構成をとることで、処理能力を高めている。また、クラスタ構成システムを構築するプラットフォームとして、容易にクラスタ構成システムに必要とされるノードを追加可能なブレードサーバが普及している。

しかし、このように構成を容易に変更可能なプラットフォームでは、クラスタを構成するノード数が可変になるため、全てのクラスタ構成に対して、上述のような障害時の系切り替えにおいて、系切り替え後もＤＢＭＳ性能の劣化を抑制可能なＤＢサーバ数やデータ領域を事前に設計することは不可能である。従って、全ノードが正常稼動中はデータ領域の量が均等に割り振られた構成であっても、系切り替え後にノード毎のデータ領域の量が不均等となる場合が生じるという問題がある。

クラスタ構成の無共有型ＤＢＭＳにおいて、上記のようにノード当たりのデータ領域の量が不均等となる上述の課題に対して、ＤＢサーバが有するデータ領域の量を変更することで、ノード当たりのデータ量を均等化する方法があり、その一例として、特許文献１に記載される技術がある。

特許文献１では、無共有ＤＢＭＳにおいて、データ領域を物理的あるいは論理的に複数の領域に分割し、その領域を各ＤＢサーバに割り当てることで、ＤＢサーバの総数やノード当たりのＤＢサーバ数が増減した場合に、ＤＢＭＳ性能の劣化を抑制するように各ＤＢサーバのデータ領域の量を変更することを可能とする技術が記載される。しかし、該技術では、全データ領域のＤＢサーバへの割り当てを変更する技術であり、データ領域の整合性を保証するために、ＤＢＭＳがトランザクション処理を実行していない状態を保証する必要がある。すなわち、該技術による構成変更を適用するためには、業務が完了した状態まで待つ必要がある。
特開２００５−１９６６０２号

上記のようなクラスタ構成をとる無共有型ＤＢＭＳでは、ノード障害の発生による系切り替え後にノード毎のデータ処理量またはスループットが不均等となる場合に対して、ＤＢサーバとデータ領域を別のノードに引き継ぐ系切り替えを行なった後、上記特許文献１の技術を用いた構成変更を行なうことで、ＤＢＭＳの性能の劣化を抑制することが可能なクラスタ構成をとることが可能となる。しかし、この場合、系切り替えと構成変更とにより二度の業務停止が生じるという問題がある。

また、ノード障害が発生した場合に、系切り替えの代わりに、上記特許文献１の技術を用いて構成変更を適用しようとした場合、稼動中のトランザクションが全て終了している必要がある。そのため、障害発生時に縮退運転を実現する場合には、障害ＤＢサーバが実行していた処理と全く関係がないトランザクションの終了を待つ必要があり、縮退を行なうまでに、即座に障害ＤＢサーバを別ノードに引き継ぐ系切り替え手法と比べ、時間を要するという問題点がある。

そこで本発明は、上記問題点に鑑みてなされたもので、障害が生じたノードを除いたクラスタ構成のサーバシステムにおいて、各サーバが均等な負荷を有して、性能の劣化を抑制することが出来るような縮退運転を実現することを目的とする。

本発明は、現用系のサーバと待機系のサーバを有して、データベース処理のトランザクションを分割して実行する複数のサーバと、前記サーバがアクセスするデータ領域とログ領域とを予め設定したストレージ装置と、前記複数のサーバに割り当てるトランザクションを管理する管理サーバと、を備え、前記複数のサーバのうちの何れかに障害が発生したときには、障害のない正常なサーバに前記トランザクションを引き継ぐサーバの障害回復方法であって、前記複数のサーバのうち障害の発生したサーバを特定する手順と、前記障害が発生したサーバが利用していたストレージ装置のデータ領域とログ領域とをそれぞれ特定する手順と、前記障害が発生したサーバで実行されていた処理に関連するトランザクションを実行していた少なくとも２以上の他のサーバの処理を中断する手順と、前記障害が発生したサーバがアクセスする前記データ領域を正常な少なくとも２以上の他のサーバに割り当てる手順と、前記障害が発生したサーバがアクセスする前記ログ領域を、前記障害が発生したサーバのデータ領域が割り当てられた少なくとも２以上のサーバで共有する手順と、前記障害が発生したサーバがアクセスするデータ領域を割り当てられた少なくとも２以上のサーバのそれぞれが、前記共有したログ領域に基づいて処理を中断した時点まで前記データ領域を回復する手順と、を含み、前記障害が発生したサーバがアクセスする前記データ領域を正常な少なくとも２以上の他のサーバに割り当てる手順は、前記サーバの負荷に基づいて縮退と系切り替えの一方を選択する手順と、前記系切り替えを選択した場合には、待機系のサーバで障害の発生した現用系のサーバの処理を引き継ぐ手順と、前記縮退を選択した場合には、前記障害が発生したサーバのデータ領域を引き継ぐサーバの負荷が等しくなるように前記データ領域を正常なサーバに割り当てる手順と、を含む。

したがって、本発明は、複数のサーバの何れかに障害が発生した場合に、そのサーバとデータ領域を対にして別のノードで引き継ぐのではなく、そのサーバのデータ領域を稼動中の他のサーバに割り当て、また、障害が発生したサーバのログを共有させ、割り当て先のサーバで実行中のトランザクションの回復処理を行なうことにより、障害が生じたサーバを除いたクラスタ構成のサーバにおいて、各サーバが均等な負荷を有して、性能の劣化を抑制することが出来るような縮退運転を実現することができる。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は実施形態を示し、本発明を適用する計算機システムのハードウェア構成を示すブロック図である。

図１において、ネットワーク７にはクラスタ構成によりデータベース業務を提供する複数のデータベースノード（以下、ＤＢノード）１００、２００、３００から構成される現用系の計算機群と、これらＤＢノード１００〜３００を管理するデータベース管理システム及びクラスタ管理プログラムを実行する管理ノード（サーバ）４００と、現用系のＤＢノード１００〜３００に障害生じたとき、障害が発生したノード（以下、障害ノード）の業務を引き継ぐ複数のＤＢノード１１００〜１３００から構成される待機系の計算機群と、管理ノード４００を介してＤＢノード１００〜３００からデータベースを利用するクライアントコンピュータ１５０が接続されている。なお、ネットワーク７は、例えば、ＩＰネットワークで構成される。

管理ノード４００は、演算処理を行うＣＰＵ４０１と、プログラムやデータを格納するメモリ４０２と、ネットワーク７を介して他の計算機と通信を行うネットワークインターフェース４０３と、ＳＡＮ（Storage Area Network）４０５を介してストレージ装置４０６にアクセスを行うＩ／Ｏインターフェース（ホストバスアダプタ）４０４を備える。

ＤＢノード１００は、複数の計算機から構成され、本実施形態では３つの計算機で構成した例を示す。ＤＢノード１００は、演算処理を行うＣＰＵ１０１と、データベースの処理を行うプログラムやデータを格納するメモリ１０２と、ネットワーク７を介して他の計算機と通信を行う通信インターフェース１０３と、ＳＡＮ４を介してストレージ装置５にアクセスを行うＩ／Ｏインターフェース（ホストバスアダプタ）１０４を備える。ＤＢノード２００、３００は、ＤＢノード１００と同様に構成される。なお、待機系のＤＢノード１１００〜１３００も上記現用系のＤＢノード１００〜３００と同様である。

ストレージ装置５は複数のディスクドライブを備え、現用系のＤＢノード１００〜３００と管理ノード４と待機系のノード１１００〜１３００からアクセス可能な記憶領域として領域（ボリューム）５１０〜５１２及び６０１〜６０６が設定される。これらのボリュームは、領域５１０〜５１２が各ＤＢノード１００〜３００のデータベースのログを格納するログ領域５００として利用され、領域６０１〜６０６が各ＤＢノード１００〜３００に割り当てられたデータベースを格納するデータ領域６００として利用される。

図２は、クラスタ構成のデータベースシステムに本発明を適用した場合のソフトウェアを主体とした機能ブロック図である。

図２において、データベースシステムは、管理ノード４００で稼働するデータベース管理サーバ４２０が、クライアント１５０からのクエリー（問い合わせ）を受け、データベース処理（トランザクション）を各ＤＢノード１００〜３００で稼働するＤＢサーバ１２０、２２０、３２０に分配し、ＤＢサーバ１２０〜３２０の処理結果をまとめ、クエリーの結果をクライアント１５０に返す。

ＤＢサーバ１２０〜３２０には、ストレージ装置５のデータ領域６００とログ領域５００がそれぞれ割り当てられており、各ＤＢサーバ１２０〜３２０は割り当てられた領域を占有してデータベース処理を行う、所謂無共有型（Shared−nothing）データベース管理システム（ＤＢＭＳ）を構成する。また、管理ノード４００は、各ＤＢノード１００〜３００とクラスタ構成を管理するクラスタプログラム（クラスタ管理部）４１０を実行している。

まず、ＤＢノード１００は、各ＤＢノードの稼動状態を監視するクラスタプログラム１００と、データベース管理サーバ（以下ＤＢ管理サーバ）４２０の配下でトランザクションを処理するＤＢサーバ１２０とを有する。

クラスタプログラム１００は、あるＤＢノードに障害が発生した場合に、そのＤＢノードが有するＤＢサーバを引き継ぐ系切り替え先を定義する系切替定義１１０と、クラスタを構成する他ノードの生死を管理するノード管理表１１２を有する。ここで、系切替定義１１０は、明示的に系切り替え先となるノードを記載しても良いし、系切り替え先となるノードを一意に定める方法が記載されていても良い。また、ノード管理表１１２に管理される他ノードの生死状態は、他ノードのクラスタプログラムと通信することで監視する方法であってもよい。

次に、ＤＢサーバ１２０は、トランザクションを実行するトランザクション実行部１２１と、トランザクションの実行状況（更新履歴）をログに書き込むログ読書部１２２と、前記ログ読書部１２２によって書き込まれトランザクションの実行状態に基づいたデータ更新を行なうログ適用部１２３と、前記ログ適用部１２３がデータを書き込む対象となるデータ領域を記憶しておく領域管理部１２４と、障害が発生した場合に、前記ログ読書部１２２を用いてログを読み出し、前記ログ適用部１２３を用いて、前記領域管理部１２４に記載されたデータ領域上のデータの整合性が保たれるように、データの更新処理を行なう回復処理部１２５を含む。また、ＤＢサーバ１２０は、割り当てられたデータ領域を保持する領域管理表１２６を備える。なお、ＤＢノード２００、３００も同様に管理ノード４００のデータベース管理サーバ４２０の配下で処理を行うＤＢサーバ２２０、３２０と、ＤＢノードを相互に監視するクラスタプログラム２１０、３１０を実行する。各ＤＢノード１００〜３００の構成要素は、図２において、ＤＢノード１００が１００番台で記述し、ＤＢノード２００が２００番台で記述し、ＤＢノード３００は３００番台で記述する。

次に、管理ノード４００は、前記クラスタプログラム１００と同様の構成からなるクラスタプログラム４１０と、ＤＢ管理サーバ４２０からなる。ＤＢ管理サーバ４２０は、前記ＤＢサーバ１２０〜３２０に割り当てられたデータ領域６００との対応付けを行なう領域割当て管理部４３１と、外部から入力されたトランザクションを各ＤＢサーバで実行し、実行結果を外部へと返すトランザクション制御部４３３と、ＤＢノード１００〜３００のいずれかに障害が発生した場合に各ＤＢサーバに対して回復処理を行なうように指示する回復処理管理部４３２と、さらに各ＤＢサーバにどのデータ領域が割り当てられているかを対応づける領域・サーバ対応表４３４と、ＤＢ管理サーバ４２０に対して外部から送られたトランザクションがどのデータ領域に対する要求かを対応づけるトランザクション・領域対応表４３５を有する。

ここで、前記領域割当て管理部４３１は、ＤＢサーバ１２０〜３２０に割り当てられたデータ領域６００との対応付けを領域・サーバ対応表４３４に格納する。次に、前記ＤＢ管理サーバ４２０は、外部から送信されたトランザクションをデータ領域毎の処理単位である小トランザクションに分割する。そして、ＤＢ管理サーバ４２０は、トランザクションをデータ領域に応じて分割した小トランザクションを実行するデータ領域との対応をトランザクション・領域対応表４３５に格納してから、前記サーバ対応表４３４の対応を元に処理対象となるデータ領域を有するＤＢサーバに小トランザクションを投入する。

また、ＤＢ管理サーバ４２０は、投入した小トランザクションの処理結果を各ＤＢサーバ１２０〜３２０から受信し、前記対応表４３５を元に、全ての小トランザクションを受信した後に小トランザクションから構成される元のトランザクションの結果を組み立てて、トランザクションの送信元に対して返し、その後、前記対応表４３５から当該トランザクションのエントリを消去する。

さらに、ストレージ装置５のデータ領域６００は各ＤＢサーバ１００〜３００への割り当て単位となる複数の領域Ａ６０１〜Ｆ６０６から構成される。また、ログ領域５００は、各ＤＢサーバ１２０〜３２０にストレージ装置５に設けたログ領域５１０、５２０、５３０を有する。前記ログ領域５１０〜５１２、５２０〜５２２、５３０〜５３２は、ログ領域を有するＤＢサーバ１００〜３００がデータ領域６００に対して行なったコミットの有無を含めた変更内容と、その変更を生じたトランザクションとが記載されたログ５１１を有する。

図３〜図１５は、本実施形態における各ノードにおけるクラスタプログラム、ＤＢ管理サーバとＤＢサーバの動作を表したフローチャートである。

まず、図３、図４は、ＤＢノード１００〜３００で障害が発生した場合に、ＤＢノード上のＤＢサーバ１２０〜３２０を別ノードで引き継ぐ系切り替え処理と、ＤＢサーバが利用していたデータ領域を別ノード上のＤＢサーバに引き継ぐ縮退（稼働するＤＢサーバ数を低減する）運転処理を選択し、その処理を表したフローチャートである。

図３では、あるノードのクラスタプログラム４００１が他ノードのクラスタプログラム４００１を監視することで他ノードの障害を検知する（通知３００１）。なお、図３、図４のクラスタプログラム４００１は、上記ＤＢノード１００〜３００または管理ノード４００のクラスタプログラム１１０、２１０、３２０、４１０のいずれかを示し、同じく図中クラスタプログラム４００１は、上記クラスタプログラム１１０〜４１０の他のいずれかを示す。以下では、ＤＢノード１００のクラスタプログラム１１０の例について説明する。

前記通知（障害検知）３００１により、前記クラスタプログラム４００１が他ノードの障害を検出し、稼動ノードと障害ノードとをノード管理表１１２に保持する（処理１０１１）。前記処理１０１１の後、クラスタプログラム４００１は系切り替え定義１１１を用いて、障害ノードを含めた各ノード上で動作しているＤＢサーバの数を取得する（処理１０１２）。続いて、クラスタプログラム４００１は、処理１０１３においてＤＢ管理サーバ４２０に領域・サーバ対応表４３４の取得要求（通知３００２）を行ない、前記対応表４３４を取得する（通知３００３）。領域・サーバ対応表４３４は、図１で示すように、データ領域Ａ，Ｂ（６０１，６０２）がＤＢサーバ１２０に割り当てられ、データ領域Ｃ、Ｄ（６０３，６０４）がＤＢサーバ２２０に割り当てられ、データ領域Ｅ，Ｆ（６０５，６０６）がＤＢサーバ３２０に割り当てられていることを示している。

ここで、図４において、前記通知（取得要求）３００２を受けたＤＢ管理サーバ４２０上の領域割当て管理部４３１は、前記領域・サーバ対応表４３４を読み込み（処理１０２１）、その対応表を要求元であるクラスタプログラム４００１に転送する（処理１０２２、通知３００３）。続いて、図３の処理１０１４において、クラスタプログラム４００１は、系切り替えを行なう場合と縮退を行なう場合のコスト計算を行なう。

このコスト計算は、例えば、ＤＢノードの性能（例えば、スループットやトランザクション処理能力など）に着目した場合には、前記処理１０１２で取得したＤＢサーバ数から障害ノード上のＤＢサーバ数が、前記処理１０１１で検出した稼動中のノード数で割り切れるかを計算する方法や、前記処理１０１３で取得した前記対応表４３４を用い、障害ノード上のＤＢサーバが利用していたデータ領域が均等に稼動ノード上のＤＢサーバ数で割り切れるかを計算する方法により、系切り替え後あるいは縮退後の各ＤＢノード当たりのデータ領域量を算出することが可能である。

また、コスト計算は、ＤＢノード１００〜３００上のＤＢサーバ１２０〜３２０の負荷率（例えば、ＣＰＵの負荷率）を求めてもよい。

さらに、ユーザが系切り替えと縮退のどちらを用いるかを明示的にクラスタプログラム４００１に指示する方法や、縮退により業務停止が許容されるＤＢサーバの負荷量（データ領域量やＤＢノード当たりのトランザクション処理量）を指定することで、障害発生時のＤＢサーバの負荷量から縮退するか、系切り替えするかを選択する方法であっても良い。加えて、これらの方法にそれぞれ重みを付け、組み合わせる方法をとっても良い。

前記処理１０１４でコスト計算を行なった結果から、系切り替えを実施した方がよいかどうかを判断し（処理１０１５）、系切り替えを実施すべきであれば、系切り替え処理を実行し（処理１０１６）、そうでなければ、縮退運転を実行する（処理１０１７）。

例えば、障害による停止時間を短くするために高速な障害回復を実現する場合は、縮退運転を選択し、ＤＢノードのハードウェア性能が低い等の理由により、ＤＢサーバを引き継ぐことで生じるＤＢＭＳの処理性能の低下を許容できず、ＤＢＭＳ性能の劣化を抑制する必要性がある場合には、系切替を選択することができる。

あるいは、障害ＤＢノード上のＤＢサーバ数が、前記処理１０１１で検出した稼動中のＤＢノード数で割り切れる場合には縮退を選択し、割り切れない場合には系切り換えを選択する。あるいは、コスト計算の結果、縮退を行った場合の負荷量が予め設定したしきい値を超える場合には、系切り換えを選択し、負荷量がしきい値以内であれば縮退を選択するようにしても良い。

または、上述したコストとして処理負荷（例えば、ＣＰＵの負荷率）を求める場合では、縮退と系切り替えの内、正常なＤＢノード１００〜３００間で処理負荷（例えば、ＣＰＵ負荷率）が等しくなる方（換言すれば、処理負荷の偏りが少ない方）を選択するようにしてもよい。特に、ＤＢノード１００〜３００の処理能力に差がある場合、すなわち、ＤＢノード１００〜３００のハードウェア構成に差異がある場合、ＣＰＵの負荷率の偏りが少なくなるように、縮退または系切替を選択するようにしても良い。

前記処理１０１６、処理１０１７では、それぞれ系切り替え処理と縮退運転処理とをＤＢ管理サーバに通知する（通知３００４）。前記通知３００４（データベース管理サーバ４２０への縮退運転指示）では、障害ＤＢサーバや障害ノードをＤＢ管理サーバに通知してもよい。

図５、図６は、外部（クライアント１５０）からのトランザクションを受信したＤＢ管理サーバ４２０が各ＤＢサーバ１２０〜３２０に処理を実行させ、その処理結果を要求元に対して返信する処理を表したフローチャートである。ここで、トランザクションは依存関係を有するデータ操作要求群を意味する。従って、トランザクションが異なる場合は、操作対象となるデータに依存関係が無く、独立して処理できる。

図５で、ＤＢ管理サーバ４２０上のトランザクション制御部４３３はクライアント１５０からトランザクション（通知（トランザクション要求）３００５）を受信すると（処理１０３１）、前記トランザクション３００５をＤＢ管理サーバ４２０が管理するデータ領域６００の各領域６０１〜６０６毎の処理に対応する小トランザクションに分離する（処理１０３２）。その後、前記トランザクション制御部４３３は、前記処理１０３２によって分離された小トランザクションが対応する各領域と前記トランザクション３００５とを対応させ、トランザクション・領域対応表４３５に登録し（処理１０３３）、領域・サーバ対応表４３４を元に各小トランザクションを対応するＤＢサーバ１２０〜３２０で実行する（処理１０３４、通知（小トランザクション実行要求）３００６）。

図６の小トランザクション完了通知３００７によって各ＤＢサーバ１２０〜３２０で実行された小トランザクションの実行結果は、再び前記トランザクション制御部４３３で受信された後（処理１０４１、通知３００７）、送信元であるクライアント１５０に対して結果を送信する（処理１０４２、通知３００８）。前記処理１０４２により、トランザクション３００５の実行が完了したため、前記トランザクション・領域対応表４３５から前記トランザクション３００５のエントリを消去する。

以上、図５、図６により、クライアント１５０からのトランザクションに対し、ＤＢ管理サーバ４２０はどのデータ領域が、どのＤＢサーバ上で実行されているかを判断するための対応表４３４、４３５とを有し、小トランザクションに分割して各ＤＢサーバ１２０〜３２０に処理を依頼する。各ＤＢサーバ１２０〜３２０は並列的に小トランザクションを実行し、実行結果をＤＢ管理サーバ４２０に返す。ＤＢ管理サーバ４２０は、受信した実行結果を上記対応表４３４，４３５に基づいて組み立てて、クライアント１５０に返信する。

図７〜図１２は、障害が発生したＤＢノードが有するデータ領域を稼動中の別のＤＢノード上のＤＢサーバに割り当て、回復処理を実行した後、割当て先のＤＢサーバが処理を継続することで、障害ノードを縮退させる処理を表したフローチャートである。

図７、図８は、クラスタプログラム４００１からの縮退運転実行の指示を契機に、ＤＢ管理サーバ４２０が障害ＤＢサーバで実行中だった処理に関連するトランザクションを他のノードで実行しているかを判断し、実行中の各ＤＢサーバにその処理の中止を指示し、各ＤＢサーバが中止する処理を表したフローチャートである。なお、以下に述べるトランザクション実行部２００５はＤＢサーバ１２０〜３２０のトランザクション実行部１２１〜３２１を示す。

図７では、ＤＢ管理サーバ４２０の回復処理管理部４３２は、クラスタプログラム４００１から縮退運転を実施するように通知（縮退運転指示）３００４を受信すると（処理１０５１）、前記通知３００４を元に障害ＤＢサーバを検出する（処理１０５２）。ここで、前記処理１０５２では、前記通知３００４が障害ＤＢサーバの情報を含む場合には、この障害情報を利用することで障害ＤＢサーバを検出可能である。

また、前記通知３００４に障害ＤＢサーバの情報を含まない場合には、ＤＢ管理サーバ４２０あるいはクラスタプログラム４００１に問い合わせることで障害ＤＢサーバを検出することが可能である。前記障害検出処理１０５２を実行後、ＤＢ管理サーバ４２０のトランザクション制御部４３３は、トランザクション・領域対応表４３５を参照し、前記処理１０５２で検出された障害ＤＢサーバで実行していた処理に関連するトランザクションを抽出し（処理１０５３）、障害により中断された前記トランザクションから前記処理１０３２で生成された小トランザクションが障害ＤＢサーバ以外で実行中かどうかを判断する（処理１０５４）。

前記処理１０５４で、該当する小トランザクションが前記障害ＤＢサーバ以外で実行されていた場合には、領域・サーバ対応表４３４を用いて、前記小トランザクションを実行中の各ＤＢサーバにトランザクション破棄を通知し（通知３００９）、小トランザクション破棄の完了通知３０１０を受信する（処理１０５５）。

図８では、ＤＢサーバ１２０〜３２０の回復処理部２００４及びトランザクション実行部２００５は前記破棄要求通知３０１０を受信し（処理１０６１）、対象となる小トランザクションの実行を中止する（処理１０６２）。そして、ＤＢサーバ１２０〜３２０は、小トランザクション中止完了通知３０１１をＤＢ管理サーバ４２０に対して送信する（処理１０６３）。一方、図７の前記処理１０５４で該当するＤＢサーバが存在しない場合には、そのまま処理を終了する。なお、回復処理部２００４は、図２のＤＢサーバ１２０〜３２０の回復処理部１２５，２２５，３２５を示す。

以上により、ＤＢ管理サーバ４２０が主体となって、障害ＤＢサーバで実行されていた処理に関連するトランザクションの全処理を中断することが可能となり、以降に説明する回復処理を行なうことが出来る。

図９、図１０は、障害ＤＢサーバのデータ領域を他ノードで稼動中のＤＢサーバに割り当てる処理を表したフローチャートである。

図９では、ＤＢ管理サーバ４２０の回復処理管理部４３２は、領域・サーバ対応表４３４とトランザクション・領域対応表４３５を参照することで、障害ＤＢサーバのデータ領域を抽出する（処理１０７１）。そして、回復処理管理部４３２で抽出したデータ領域を稼動中のＤＢサーバ１２０〜３２０に割り当てるように前記対応表４３４を更新する（処理１０７２）。そして、ＤＢ管理サーバ４２０は、各ＤＢサーバに前記対応表４３４で更新したデータ領域の割り当てを実行するように通知する（通知（領域割当通知）３０１１）。ＤＢ管理サーバ４２０は、割り当てを指示したＤＢサーバ１２０〜３２０からのデータ領域のマウントが終了したことを示す完了通知３０１２を受信する（処理１０７３）。前記通知３０１２は、前記対応表４３４をそのまま送信しても良い。

以上により、ＤＢ管理サーバ４２０は、障害ＤＢサーバに割り当てられていたデータ領域を、正常に稼働しているＤＢサーバ１２０〜３２０に配分する。

図１０では、各ＤＢサーバ１２０〜３２０の領域管理部１２４〜３２４における処理を示す。なお、図１０において、領域管理部２００６は、各ＤＢサーバ１２０〜３２０の領域管理部１２４〜３２４を示す。

領域管理部２００６が前記通知（領域割当通知）３０１１を受信し（処理１０８１）、前記領域・サーバ対応表４３４で更新された通りに各ＤＢサーバ１２０〜３２０の領域管理表１２６，２２６，３２６を更新し（処理１０８２）、更新完了後、その完了をＤＢ管理サーバ４２０へ通知する（処理１０８３、通知３０１２）。

以上の図９、図１０の処理を、図７、図８で行なったトランザクションの中止要求に続けて実行することで障害ＤＢサーバが有するデータ領域は、正常に稼動中のＤＢサーバに引き継がれる。

図１１、図１２は、図９、図１０に続いて実行することで、前記破棄完了通知３０１０の小トランザクション中止要求と障害によって中止された小トランザクションによって処理中だったデータ領域の回復を行なう処理を表したフローチャートである。

図１１では、ＤＢ管理サーバ４２０の回復処理管理部４３２が領域・サーバ対応表４３４とトランザクション・領域対応表４３５を元に、障害と前記完了通知３０１０によって中止されたトランザクションを実行していたデータ領域の回復を行なうようにＤＢサーバ１２０〜３２０に破棄（中止）トランザクション回復処理要求を通知し（通知３０１３）、その完了通知３０１４をＤＢサーバ１２０〜３２０から受信する（処理１０９１）。前記処理１０９１が完了した後に、中止したトランザクションを前記トランザクション・領域対応表４３５より消去する。そして、クラスタプログラム４００１に縮退が完了した通知３０１５を送信する（処理１０９２）。

以上により、障害発生により中止したトランザクションで不整合が生じていたデータ領域の回復が完了し、障害ノードが取り除かれたクラスタ構成への変更が完了したため、縮退が完了する。

図１２では、各ＤＢサーバ１２０〜３２０の回復処理部１２５，２２５，３２５における処理を示す。なお、図１２では、各ＤＢサーバ１２０〜３２０のログ読書部１２２，２２２，３２２の総称をログ読書部２００８とする。

各ＤＢサーバ１２０〜３２０の回復処理部２００７が、前記通知３０１３を受信し（処理１１０１）、障害ＤＢサーバが有していたデータ領域を回復するために障害ＤＢサーバが有していたログの共有を行なう（処理１１０２）。続いて、ログ読み書き部２００７が、前記処理１１０２によって共有されたログ領域５００からログを読み込む（処理１１０３）。

前記処理１１０３で読み出したログが、自ＤＢサーバに割り当てられている障害ＤＢサーバが有していたデータ領域を対照としているかを判断する（処理１１０４）。前記処理１１０４で自ＤＢサーバに障害ＤＢサーバのデータ領域が割り当てられている場合にはそのログを自ＤＢサーバのログ領域へ書き出す（処理１１０５）。そして、処理１１０６を実行する。一方、前記処理１１０４で自ＤＢサーバに割り当てられていたデータ領域でない場合には、処理１１０６を実行する。

処理１１０６では、前記処理１１０２で共有したログを全部読み終えたかを判断し（処理１１０６）、全て読み終えてない場合には、前記処理１１０３へ戻り、読み終えた場合には、処理１１０７をログ適用部２００９で、読み込んだログを適用して自ＤＢサーバに割り当てられたデータ領域に障害ＤＢサーバから引き継いだデータを回復する。なお、ログ適用部２００９は、各ＤＢサーバ１２０〜３２０のログ適用部１２３、２２３、３２３を示す。

以上の処理１１０３〜処理１１０６により、障害ＤＢサーバが有したデータ領域を割り当てられたＤＢサーバでは、障害ＤＢサーバが有したログから割り当てられたデータ領域に関するログだけを抜き出し、自サーバのログ領域に書き込みが完了した状態となり、自ＤＢサーバが有するログ領域には、自ＤＢサーバが有するデータ領域に関する全てのログが書き込まれた状態となる。したがって、ノード障害によって中止したトランザクションに関するデータ領域を回復する処理が実行することが出来る（処理１１０７）。前記処理１１０７により、自ＤＢサーバの有するデータ領域の回復が完了した後、各ＤＢサーバ１２０〜３２０の回復処理部１２５，２２５，３２５は、その完了通知３０１４を管理サーバ４２０に通知する（処理１１０８）。

ここで、前記処理１１０２〜処理１１０６は、説明の簡略化のため、全ＤＢサーバで行なう処理としたが、障害ＤＢサーバが有するデータ領域を割り当てられたＤＢサーバでのみ選択的に実行するようにしても良い。同様に、前記処理１１０７も、障害ＤＢサーバが有するデータ領域を割り当てられたＤＢサーバと、前記通知３０１０によって処理を中断したＤＢサーバでのみ選択的に実行するようにしても良い。

以上の図７〜図１２の処理を行なうことで、障害ＤＢサーバが有するデータ領域は、障害によって生じたデータ領域の不整合を回復した状態で稼動中のＤＢサーバに引き継がれ、縮退運転を実現することができる。

ここで、図２では、ＤＢ管理サーバ４２０の領域割当て管理部４３１、回復処理管理部４３２、トランザクション制御部４３３を一つのサーバとし、ＤＢノード１００〜３００とは別のノードに有する構成を持つＤＢＭＳを例にしたが、これらの各部は独立のサーバとし、それぞれ別のノードに配置してもよいし、ＤＢノード１００〜３００と同一のノード上に配置するような構成であってもよい。この場合、別のサーバ、別のノード間で情報を交換する場合は、それぞれ通信を行なうことで第１の実施形態に示した処理を実現することができる。

例えば、本発明の実施形態の一変形例として、図１３に示すように、トランザクション制御部４２２とトランザクション・領域対応表４３５、さらに縮退時にデータ領域の回復処理を実行する回復処理管理部４３２をＤＢ管理サーバ４２０とは独立した別のサーバであるフロントエンドサーバ７２０とし、ＤＢ管理ノード１００〜３００とは別のノードであるフロントエンドノード７００とした構成してもよい。

さらに、前記処理１０１２〜１０１４では、系切り替えと縮退運転の選択指標として、負荷量の計算対象として、無共有型ＤＢＭＳにおけるデータ領域を用いて述べたが、この他クラスタ型アプリケーションのうち、サーバによる系切り替えと、縮退運転とを行なうことができるアプリケーションであっても良く、例えばＷＥＢアプリケーションがある。このようなクラスタ型アプリケーションに適用する場合は、ＤＢＭＳにおける負荷量を決定するデータ領域量ではなく、そのアプリケーションの負荷量を決定するデータの量を用いればよく、例えば、前記ＷＥＢアプリケーションでは、接続されているトランザクション量であれば良い。

以上のように、第１の実施形態によれば、クラスタ構成をとる無共有型ＤＢＭＳ（データベース管理サーバ４２０及び各ＤＢサーバ１２０〜３２０）において、あるノード（ＤＢノードまたはＤＢサーバ）に障害が発生した場合に、ユーザが求める要件に基づき、系切り替えと縮退運転とを選択的に実行することが可能となる。

さらに、縮退運転を実行する場合において、障害ノードのＤＢサーバで実行されていた処理に関連するトランザクションを実行していた他ノードのＤＢサーバの処理を中断し、障害ノードのＤＢサーバが有するデータ領域を他ノードのＤＢサーバに割り当て、障害ＤＢサーバが有していたログ領域を引き継ぎ先となるＤＢサーバで共有する。これにより障害ノードで実行していた処理に関連するトランザクションの回復処理を、障害ＤＢサーバが有していたデータ領域を含む全てのデータ領域で実行することが可能となる。

以上の動作から、第１の実施形態では、無共有型ＤＢＭＳにおいて、ノードの障害が生じた場合に、全ＤＢサーバの処理を停止させることなく、障害ノードを除いたクラスタ構成への縮退を実現することが可能となるため、縮退運転によって生じるＤＢＭＳ性能の劣化を抑制するクラスタ構成を高速に実現する高可用性無共有型ＤＢＭＳを提供することが可能となる。

＜第２実施形態＞
図１４〜図１７は、第２の実施形態を示し、前記第１の実施形態に示したフローチャートを置き換えて新たな処理を表したフローチャートである。本第２実施形態では、第一の実施形態における図７、図９、図１１、図１２の処理を図１４，図１５、図１６、図１７と置き換えたものであり、その他の処理は前記第１の実施形態と同様である。

まず、クラスタプログラムから送られる任意の時点での縮退運転の指示を契機に、縮退対象のＤＢサーバが実行中の処理に関連するトランザクションを中止する。そして、縮退対象のＤＢサーバが有していたデータ領域を他の稼動中のＤＢサーバに割り当てた後、中止したトランザクションによって不整合となったデータ領域の回復処理を行なう。さらに中止したトランザクションを構成変更後のデータ領域の割り当てを元に再実行する。以上の処理により、ノード障害以外の任意の時点において、ＤＢＭＳの縮退を実現することが可能となる。

以下では、図１４〜図１７について、前記第１実施形態から置換した図の処理との処理の相違点を述べる。

まず、図１４は前記第１実施形態の図７を置き換えたもので、前記第１実施形態の図８と共に動作することで、クラスタプログラム４００１や管理コンソール（図示省略）等の外部４００５から任意の時点で縮退運転の指示（通知３００２）を受信し（処理１１１１）、それを契機に縮退処理を行なう。処理１１１２〜１１１５は、前記処理１０５２〜１０５５に対応し、障害ＤＢサーバの代わりに、前記通知３００４で指示された縮退対象となるＤＢサーバを対象とした処理を行なう。

これにより、前記通知３００４によって指示されたＤＢサーバで実行されていた処理に関連するトランザクションを中止することが可能となる。

次に、図１５は図１０の処理と共に、上記図１４と図８の処理に続いて実行される。図１５の処理１１２１〜処理１１２３は、前記第１実施形態の図９に示した処理１０７１〜処理１０７３に対応し、障害ＤＢサーバの代わりに前記通知３００４で指示された縮退対象となるＤＢサーバを対象とした処理を行なう。これにより、前記通知３００２によって指示されたＤＢサーバが有したデータ領域を他ノードで稼動中のＤＢサーバに割り当てることが可能となる。

さらに、図１６と図１７は、それぞれ前記第１実施形態の図１１と図１２に対応する処理で、図１４と図１０の処理に続いて実行される。上記図１６の処理１１３１は図１１の処理１０９１に対応し、図１７の処理１１４１〜１１４８は、図１２の処理１１０１〜処理１１０８に対応し、それぞれ障害ＤＢサーバの代わりに前記通知３００４で指示された縮退対象となるＤＢサーバを対象とした処理を行なう。

これにより、処理１１３１が完了した時点において、ＤＢサーバが縮退し、前記通知３００４によって指示されたＤＢサーバが有したデータ領域は、稼動中のＤＢサーバに割り当てられ、さらに前記処理１１１３で抽出されたトランザクションが実行前の整合性が取れた状態にある。前記処理１１３１の後、処理１１３２〜１１３４は、前記第１実施形態の図５に示した処理１０３２〜１０３４に対応し、クライアントからのトランザクションの代わりに、前記処理１１１５で中止されたトランザクションを用い、図１４と図１０により割り当てが変更された後の全データ領域を対照とした処理を行なう。すなわち、前記処理１１３２〜処理１１３４によって、縮退を行なうために図１４の処理１１１５で中止したトランザクションを縮退構成によって再度実行された状態となり、縮退前の構成において処理中だったトランザクションが縮退後の構成で処理されている状態となる。

以上のように、図１４〜図１７と図８、図１０の処理を行なうことで、任意の時点で、トランザクションの損失無しで、あるＤＢサーバのデータ領域を稼動中のＤＢサーバに引き継ぐ縮退運転を実現することができる。

ここで、第２の実施形態も、前記第１の実施形態と同様に、図２に示す各処理部は、独立のサーバとし、それぞれ別のノードに配置してもよいし、ＤＢノードと同一のノード上に配置するようなしてもよく、前記図１３に示すような構成がある。

さらに、本第２実施形態では、系切り替えと縮退運転の選択指標として、負荷量の計算対象として、無共有型ＤＢＭＳにおけるデータ領域を用いて述べたが、クラスタ型アプリケーションのうち、サーバによる系切り替えと、縮退運転とを行なうことができるアプリケーションであっても良く、例えばＷＥＢアプリケーションがある。このようなクラスタ型アプリケーションに適用する場合は、ＤＢＭＳにおける負荷量を決定するデータ領域量ではなく、そのアプリケーションの負荷量を決定するデータの量を用いればよく、例えば、前記ＷＥＢアプリケーションでは、接続されているトランザクション量であれば良い。

以上のように第２の実施形態では、クラスタ構成をとる無共有型ＤＢＭＳにおいて、あるノードを縮退させる指示に基づき、縮退対象ノードのＤＢサーバで実行されていた処理に関連するトランザクションを実行していた他ノードのＤＢサーバの処理を中断する。そして、縮退対象ノードのＤＢサーバが有するデータ領域を他ノードのＤＢサーバに割り当て、縮退対象ＤＢサーバが有するログ領域を引き継ぎ先となるＤＢサーバで共有することで、縮退対象ノードで実行していた処理に関連するトランザクションの回復処理を、縮退対象ＤＢサーバが有したデータ領域を含む全てのデータ領域で実行することが可能となる。

さらに、回復処理が完了した後、上記で中断したトランザクションを縮退したクラスタ構成のＤＢＭＳで再実行することにより、縮退運転前後でトランザクションの損失を生じることのない縮退技術が実現される。

以上の動作から、第２の実施形態では、無共有型ＤＢＭＳにおいて、任意の時点で全ＤＢサーバの処理を停止させることなく、縮退対象ノードを除いたクラスタ構成への縮退を実現することが可能となるため、縮退運転によって生じるＤＢＭＳ性能の劣化を抑制するクラスタ構成を高速に実現する高可用性の無共有型ＤＢＭＳを提供することが可能となる。

また、上記の第１、第２の実施形態によれば、無共有型ＤＢＭＳと、データ領域を用いた縮退運転について述べたが、クラスタ型アプリケーションのうち、サーバによる系切り替えと、縮退運転とを行なうことができるアプリケーションであっても良く、その場合も縮退運転によって生じるアプリケーションシステムの性能劣化を削減するクラスタ構成を高速に実現することが可能となる。このようなアプリケーションとしては、例えばＷＥＢアプリケーションがある。このようなクラスタ型アプリケーションに適用する場合は、ＤＢＭＳにおける負荷量を決定する単位はデータ領域量ではなく、そのアプリケーションの負荷量を決定するデータの量またはスループットを用いればよく、例えば、前記ＷＥＢアプリケーションでは、接続されているトランザクション量を用いることで、縮退運転によって生じるアプリケーションシステムの性能劣化を抑制するクラスタ構成が高速に実現することが可能となる。

また、サーバによる系切り替えと、縮退運転とを行なうことができるクラスタ型のアプリケーションとしては、上記無共有型ＤＢＭＳの他に、共有型ＤＢＭＳであってもよい。

以上のように、本発明によればサーバによる系切り替えと、縮退運転とを行なうことができるクラスタ型のアプリケーションを運用する計算機システムに適用することができ、特に、クラスタ型のＤＢＭＳに適用することで可用性を向上させることができる。

本発明を適用する計算機システムのブロック図。本発明の第１の実施形態を示し、ソフトウェアを中心とするシステムブロック図。障害発生時にクラスタプログラムで実行される縮退運転のコスト計算と回復方法の判断を行う処理の一例を示すフローチャート。クラスタプログラムが縮退運転のコスト計算を行なうために必要となる情報を、ＤＢＭＳより取得する処理の一例を示すフローチャート。データベース管理サーバで行われる小トランザクションの生成処理の一例を示すフローチャート。データベース管理サーバで行われる小トランザクションの集計処理の一例を示すフローチャート。ＤＢサーバで障害が発生した場合に、障害ＤＢサーバで実行中だった小トランザクション及び関連する小トランザクションの中断処理の一例を示すフローチャート。ＤＢサーバで行われる小トランザクションの中断処理の一例を示すフローチャート。データベース管理サーバで行われる、稼動中のＤＢサーバにデータ領域を割り当てる処理の一例を示すフローチャート。データベース管理サーバの指示に応じてデータ領域を割り当てるＤＢサーバの処理の一例を示すフローチャート。データベース管理サーバで行われるデータ領域の回復処理の一例を示すフローチャート。ＤＢサーバで行われるデータ領域の回復処理の一例を示すフローチャート。図２の変形例を示し、ソフトウェアを中心とするシステムブロック図。第２の実施形態を示し、ＤＢサーバで障害が発生した場合に、障害ＤＢサーバで実行中だった小トランザクション及び関連する小トランザクションの中断処理の一例を示すフローチャート。同じく、第２の実施形態を示し、データベース管理サーバで行われる、稼動中のＤＢサーバにデータ領域を割り当てる処理の一例を示すフローチャート。同じく、第２の実施形態を示し、データベース管理サーバで行われるデータ領域の回復処理の一例を示すフローチャート。同じく、第２の実施形態を示し、ＤＢサーバで行われるデータ領域の回復処理の一例を示すフローチャート。

符号の説明

１００、２００、３００ＤＢノード
１２０、２２０、３２０ＤＢサーバ
１１０、２１０、３１０、４１０クラスタプログラム
４２０データベース管理サーバ
５００ログ領域
６００データ領域
４３１領域割当管理部
４３２回復処理管理部
４３３トランザクション制御部
４３４領域・サーバ対応表
４３５トランザクション・領域対応表

Claims

現用系のサーバと待機系のサーバを有して、データベース処理のトランザクションを分割して実行する複数のサーバと、前記サーバがアクセスするデータ領域とログ領域とを予め設定したストレージ装置と、前記複数のサーバに割り当てるトランザクションを管理する管理サーバと、を備え、前記複数のサーバのうちの何れかに障害が発生したときには、障害のない正常なサーバに前記トランザクションを引き継ぐサーバの障害回復方法であって、
前記複数のサーバのうち障害の発生したサーバを特定する手順と、
前記障害が発生したサーバが利用していたストレージ装置のデータ領域とログ領域とをそれぞれ特定する手順と、
前記障害が発生したサーバで実行されていた処理に関連するトランザクションを実行していた少なくとも２以上の他のサーバの処理を中断する手順と、
前記障害が発生したサーバがアクセスする前記データ領域を正常な少なくとも２以上の他のサーバに割り当てる手順と、
前記障害が発生したサーバがアクセスする前記ログ領域を、前記障害が発生したサーバのデータ領域が割り当てられた少なくとも２以上のサーバで共有する手順と、
前記障害が発生したサーバがアクセスするデータ領域を割り当てられた少なくとも２以上のサーバのそれぞれが、前記共有したログ領域に基づいて処理を中断した時点まで前記データ領域を回復する手順と、
を含み、
前記障害が発生したサーバがアクセスする前記データ領域を正常な少なくとも２以上の他のサーバに割り当てる手順は、
前記サーバの負荷に基づいて縮退と系切り替えの一方を選択する手順と、
前記系切り替えを選択した場合には、待機系のサーバで障害の発生した現用系のサーバの処理を引き継ぐ手順と、
前記縮退を選択した場合には、前記障害が発生したサーバのデータ領域を引き継ぐサーバの負荷が等しくなるように前記データ領域を正常なサーバに割り当てる手順と、
を含むことを特徴とするサーバの障害回復方法。
前記サーバの負荷に基づいて縮退と系切り替えの一方を選択する手順は、
縮退を選択したときのサーバの負荷と、系切り替えを選択したときのサーバの負荷を比較して、サーバの負荷の偏りが少ない方を選択することを特徴とする請求項１に記載のサーバの障害回復方法。
ネットワークを介して接続されて現用系と待機系からなり、データベース処理のトランザクションを分割して実行する複数のデータベースサーバと、
前記データベースサーバがアクセスする複数のデータ領域と、複数のログ領域を予め設定したストレージ装置と、
前記複数のデータベースサーバに割り当てるトランザクションを管理する管理サーバと、
を備え、前記複数のデータベースサーバのうちの何れかに障害が発生したときには、障害のない正常なデータベースサーバに前記トランザクションを引き継ぐデータベースシステムにおいて、
前記管理サーバは、
前記複数のデータ領域及びログ領域にアクセスするデータベースサーバを割り当てる領域割り当て管理部と、
前記複数のデータベースサーバに前記トランザクションを配分するトランザクション制御部と、
前記複数のデータベースサーバのうち障害が発生したデータベースサーバを特定し、縮退または系切り替えの一方を選択するクラスタ管理部と、
前記障害が発生したデータベースサーバがアクセスするデータ領域を回復する回復処理管理部と、を備え、
前記領域割り当て管理部は、
前記障害が発生したデータベースサーバがアクセスしていたストレージ装置のデータ領域とログ領域とをそれぞれ特定し、
前記トランザクション制御部は、
前記障害が発生したデータベースサーバで実行されていた処理に関連するトランザクションを実行していた少なくとも２以上の他のデータベースサーバの処理を中断し、前記障害が発生したデータベースサーバがアクセスしていた前記データ領域を正常な少なくとも２以上の他のデータベースサーバに割り当て、
前記クラスタ管理部は、
前記データベースサーバの負荷に基づいて縮退と系切り替えの一方を選択し、
前記回復処理管理部は、
前記障害が発生したデータベースサーバがアクセスする前記ログ領域を、前記障害が発生したデータベースサーバのデータ領域が割り当てられた少なくとも２以上のデータベースサーバで共有させ、前記障害が発生したデータベースサーバがアクセスするデータ領域を割り当てられた少なくとも２以上のデータベースサーバのそれぞれに、前記共有したログ領域に基づいて処理を中断した時点まで前記データ領域を回復させ、前記クラスタ管理部が前記系切り替えを選択した場合には、待機系のデータベースサーバで障害の発生した現用系のデータベースサーバの処理を引き継ぎ、前記クラスタ管理部が前記縮退を選択した場合には、前記障害が発生したデータベースサーバのデータ領域を引き継ぐサーバの負荷が等しくなるように前記データ領域を正常なデータベースサーバに割り当てることを特徴とするデータベースシステム。
前記クラスタ管理部は、
前記縮退を選択したときのサーバの負荷と、系切り替えを選択したときのサーバの負荷を比較して、サーバの負荷の偏りが少ない方を選択することを特徴とする請求項３に記載のデータベースシステム。