JP5192226B2 - 待機系計算機の追加方法、計算機及び計算機システム - Google Patents

Description

本発明は、障害許容性を有する計算機システムに関し、特に、計算機システムに待機系の計算機を追加する技術に関する。

データベースシステムでは、複数のサーバによってデータ処理を行う実行系サーバ及び実行系サーバに障害が発生した場合にデータ処理を引き継ぐ待機系サーバによるクラスタ構成によって信頼性を確保することができる。ディスクベースのデータベース（ＤＢ）では、実行系サーバ及び待機系サーバから参照可能な共有ディスクによってデータを引継ぎ、待機系サーバによって処理を継続する。

一方、インメモリＤＢでは、サーバ内のメモリによってデータが保持されるため、サーバ間でストレージ装置を共有してデータを共有することはできない。そこで、待機系サーバは、実行系サーバのデータベースデータの複製をメモリ上に保持することによってデータを冗長化する。

また、サーバに障害が発生し、クラスタから切り離されると、データの冗長度が低下する。冗長度が低下したまま長時間システムの稼動を続けると、更なる障害が発生することによってシステム停止又はデータ損失が発生する可能性がある。したがって、連続運転を要求されるオンラインシステムではデータの冗長度が低下したままの運用を避ける必要がある。そこで、障害が発生したサーバをクラスタに復旧させること、若しくは、新たなサーバをクラスタに追加することによってデータの冗長度を回復させ、システムを継続して安定稼動させることが必要である。

そこで、ペアとなる装置の障害を監視し、相手先の障害を検知すると自動的に新たなペアを決定することによって、迅速に冗長性を回復させる技術が開示されている（特許文献２参照）。

また、実行系サーバと待機系サーバで独立したデータ領域にデータベースデータを保持するクラスタ構成では、待機系サーバを新たに追加する場合、新たに追加される待機系サーバについても保持するデータを実行系サーバのデータと同期させる必要がある。データの同期とは、実行系サーバが保持するデータを待機系サーバが生成可能な状態にすることである。すなわち、実行系サーバが保持するデータと同一のデータを待機系サーバが保持してもよいし、実行系サーバが保持するデータを生成可能な別のデータを保持してもよい。例えば、後者の例として、データベースでは、実行系サーバに保持されるデータの更新ログを待機系が保持していれば、待機系サーバでは当該データを生成可能である。

しかし、実行系サーバが保持するデータベースデータを整合性が確保された状態で新たな待機系サーバに複製するためには、実行系サーバのデータベースに対する更新処理を一時的に停止（静止化）する必要がある。この場合、実行系サーバに対してデータベースの更新処理を要求する業務処理についても、一時的に停止させなければならないという問題がある。

特許文献２に開示された技術では、新たに追加された装置にデータを複製する点については言及されていない。そこで、実行系サーバの動作を妨げることなくデータのバックアップを取得するために、第１及び第２の待機系サーバを用意し、実行系サーバと第１の待機系サーバのデータベースが同期している状態から、第１の待機系サーバの更新を停止し、第１の待機系から第２の待機系にデータを複製する技術が開示されている（特許文献１参照）。
米国特許出願公開第２００６／０２５３７３１号明細書 特開２００５−２５１０５５号公報

特許文献１に開示された技術では、第１の待機系サーバは、更新内容をバッファリングし、第２の待機系サーバにデータの複製が完了してから反映することによって、再び実行系サーバと同期させることができる。しかし、第２の待機系サーバは、複製を作成した後に実行系サーバで更新された内容を反映できないため、第２の待機系サーバは、実行系サーバとデータベースデータを同期できないという問題がある。

本発明の目的は、実行系サーバを停止させず、かつ、新たに追加された待機系サーバに保持されるデータを実行系サーバに保持されるデータと同期させる技術を提供することを目的とする。

本発明の代表的な一形態では、クライアントからの処理要求に応じて業務処理を実行する実行系計算機（実行系サーバ）、及び、前記実行系計算機に格納されたデータの複製を格納する複数の待機系計算機（待機系サーバ）を含み、前記複数の待機系計算機は前記実行系計算機でデータが更新された時に作成され前記実行系計算機から転送される更新情報を受けて、それぞれ自らが格納するデータの複製を更新する計算機システムにおいて、前記計算機システムに前記待機系計算機として新たに計算機を追加する方法であって、前記計算機システムから前記複数の待機系計算機の一つを選択し、前記実行系計算機から前記追加される計算機に前記更新情報の転送を開始し、前記選択された待機系計算機に格納された前記データの複製を前記追加される計算機に転送し、前記追加される計算機は、転送されたデータの複製を格納した後に、それまで滞留していた更新情報のそれぞれが重複反映にならないかを確認した上で前記格納したデータの複製に反映する。

本発明の一形態によれば、実行系計算機の処理を停止させることなく、実行系計算機に同期された状態で待機系計算機として新たに計算機を計算機システムに追加することが可能となる。

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

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

本発明の第１の実施の形態の計算機システムは、実行系サーバ１００、待機系サーバ（２００、３００及び４００）、クライアント１５０、及び、管理サーバ１６０を含む。実行系サーバ１００、待機系サーバ（２００、３００及び４００）、クライアント１５０、及び、管理サーバ１６０は、ネットワーク７によって接続される。ネットワーク７は、ＩＰネットワークであってもよいし、サーバがブレードサーバである場合には内部バスであってもよい。

本発明の第１の実施の形態の計算機システムは、データベース業務を提供する実行系サーバ１００、及び、実行系サーバ１００に障害が発生した場合に、実行系サーバ１００の業務を引き継ぐ１台以上の待機系サーバ（２００、３００及び４００）を含むクラスタ構成となっている。

管理サーバ１６０は、実行系サーバ１００及び待機系サーバ（２００、３００及び４００）を管理する。クライアント１５０は、実行系サーバ１００で稼働しているデータベースを利用する。

実行系サーバ１００は、ＣＰＵ１０１、メモリ１０２、及び、通信インターフェース１０３を備える。待機系サーバ（２００、３００及び４００）についても、実行系サーバ１００と同様の構成である。なお、待機系サーバに含まれるＣＰＵなどの構成要素についても、実行系サーバ１００と同じ符号を用いる。

ＣＰＵ１０１は、各種演算処理を実行する。メモリ１０２は、データベース管理システムなどのプログラムと、各種演算処理で使用されるデータ及びデータベース管理システムによって管理されるデータを格納する。通信インターフェース１０３は、ネットワーク７を介して他の計算機と通信する。

図２は、本発明の第１の実施の形態のクラスタ構成のデータベースシステムのソフトウェアを主体とした機能ブロック図である。

実行系サーバ１００は、待機系として動作する場合に備え、また、待機系サーバ（２００、３００及び４００）は、実行系として動作する場合に備え、実行系サーバ１００及び待機系サーバ（２００、３００及び４００）は同一の構成要素を備える。ここで、実行系サーバが実行系、待機系サーバが待機系として動作する場合に利用しない構成要素については、それぞれ、待機系、実行系として動作を開始する際に生成してもよい。

また、図２では、実行系サーバ１００の構成要素は１００番台、待機系サーバ２００の構成要素は２００番台、待機系サーバ３００の構成要素は３００番台、待機系サーバ４００の構成要素は４００番台の符号を付与する。また、以下の説明では、実行系サーバの各構成要素の機能について説明するが、特に記載の無い場合には、待機系サーバにおける各構成要素も同様の機能を有する。

実行系サーバ１００は、トランザクション制御部１１１、ログ送信バッファ１１２、ログ送信部１１３、ログ受信部１１４、ログ受信バッファ１１５、ログ適用部１１６、データベース送信部１１７、データベース受信部１１８、クラスタ構成管理部１１９、リソース使用量監視部１２０、及び、データベース１２１を備える。トランザクション制御部１１１、ログ送信部１１３、ログ受信部１１４、ログ適用部１１６、データベース送信部１１７、データベース受信部１１８、クラスタ構成管理部１１９、及び、リソース使用量監視部１２０は、プログラムを含み、ＣＰＵ１０１によって実行されることで各処理が実行される。

図２に示すデータベースシステムは、実行系サーバ１００のトランザクション制御部１１１がクライアント１５０からのデータベース操作要求を受け付け、データベース１２１に対する操作を実行し、結果をクライアント１５０に送信する。

実行系サーバ１００は、トランザクション制御部１１１がデータベース１２１を更新した際に、更新内容を表すログをログ送信バッファ１１２に書き込む。ログ送信部１１３は、ログ送信バッファ１１２に書き込まれたログを待機系サーバ（２００、３００及び４００）に送信する。

さらに、クラスタ構成管理部１１９は、実行系サーバ１００及び待機系サーバ（２００、３００及び４００）の状態を管理する。ここで、他系の状態を管理するために、クラスタ構成管理部１１９は、他系の管理部及び管理サーバ１６０と通信する機能を有する。

また、リソース使用量監視部１２０は、実行系サーバのＣＰＵ、メモリ、及び、ネットワーク帯域などのリソースがどの程度使用されているかを監視する。さらに、リソース使用量監視部１２０は、監視されたリソース使用量を他系のリソース使用量監視部１２０及び管理サーバ１６０と通信する機能を有する。なお、リソース使用量監視部１２０は、本発明の第２の実施の形態で利用される。

待機系サーバ２００は、ログ受信部２１４が実行系サーバ１００からログを受信し、受信したログをログ受信バッファ２１５に書き込む。

待機系サーバ２００は、さらに、ログ適用部２１６がログ受信バッファ２１５からログ受信部２１４に書き込まれたログを読み出し、データベース２２１に反映させる。このように、実行系サーバからログが送信されると、待機系サーバ２００に備えられるデータベース２２１を、実行系サーバ１００に備えられるデータベース１２１と同期させることができる。

また、ログ適用部２１６の状態には、ログ適用中状態とログ適用開始待ち状態がある。ログ適用中状態は、ログ受信バッファ２１５に格納されたログをデータベース２２１に順次反映させている状態である。ログ適用開始待ち状態は、ログ受信バッファ２１５にログが格納されたまま待機している状態である。

さらに、待機系サーバ２００は、データベース送信部２１７がデータベース２２１のデータを他の待機系サーバに送信する。また、データベース受信部２１８は、他の待機系サーバからデータを受信し、データベース２２１に格納する。

図３は、本発明の第１の実施の形態の通常動作中にクライアント１５０から送信されたデータベース更新要求によって、データベースが更新される処理を示すシーケンス図である。

クライアント１５０は、実行系サーバ１００のトランザクション制御部１１１にデータベース更新要求を送信する（Ｓ３０１）。

トランザクション制御部１１１は、データベース更新要求を受信すると、要求されたデータベース更新処理をデータベース１２１に対して実行する（Ｓ３０２）。さらに、トランザクション制御部１１１は、データベースの更新内容に対応するログをログ送信バッファ１１２に書き込む（Ｓ３０３）。

ログ送信部１１３は、Ｓ３０３の処理で書き込まれたログをログ送信バッファ１１２から読み出す（Ｓ３０４）。次に、クラスタ構成管理部１１９からログ送信先リストを取得する（Ｓ３０５）。

さらに、ログ送信部１１３は、取得されたログ送信先リストに含まれているすべての待機系サーバのログ受信部２１４にＳ３０４の処理で読み出されたログを送信する（Ｓ３０６）。ログの送信は、データベーストランザクションのコミット時点で当該トランザクションに関連するログを送信してもよいし、複数回のコミットのログをまとめて送信してもよい。

待機系サーバ２００のログ受信部２１４は、実行系サーバ１００のログを受信すると、受信したログをログ受信バッファ２１５に書き込む（Ｓ３０７）。ログ適用部２１６は、通常動作中においてはログ適用中状態であり、ログ受信バッファ２１５からログを読み出して（Ｓ３０８）、読み出されたログをデータベース２２１に反映する（Ｓ３０９）。

以上のＳ３０２からＳ３０９までの処理によって、実行系サーバ１００のデータベース１２１に対して更新された内容が、待機系サーバ２００のデータベース２２１に反映される。このようにして、実行系サーバ１００のデータベース１２１と待機系サーバ２００のデータベース２２１との間で同期が保たれる。

図４Ａ及び図４Ｂは、本発明の第１の実施の形態のデータベース１２１に格納された情報の一例を示す図である。

図４Ａは、業務処理で使用される表の一例である。列１から列ｎはユーザによって定義され、各行の列１から列ｎに対応する部分には、ユーザデータが格納される。各行には、行を一意に識別する行ＩＤが付与される。

図４Ｂは、データベーストランザクションがコミットされる度にインクリメントされるコミット通番を格納する表の一例である。

図５は、本発明の第１の実施の形態のログ情報５５０の一例を示す図である。

ログ情報５５０は、コミット通番５５１、行ＩＤ５５２、操作種別５５３、及び、行データ５５４を含む。

コミット通番５５１は、図４Ｂに示したように、データベーストランザクションがコミットされる度にインクリメントされる番号である。データベーストランザクション内で複数の行が挿入、更新又は削除された場合、同一のデータベーストランザクション内で更新された内容に対しては、同一のコミット通番が割り当てられる。

行ＩＤ５５２は、操作された行を特定する識別子である。操作種別５５３は、操作された行に対して実行された操作の種別である。操作種別５５３は、挿入、更新又は削除のいずれかである。操作種別５５３が挿入である場合には、挿入された行のデータを含む。また、操作種別５５３が更新である場合には、更新後の行データ５５４を含む。

ログ情報５５０は、クライアント１５０からのデータベース更新要求によって、更新の要求の対象となった行の行ＩＤ、操作種別及び行データに基づいて生成される。また、トランザクションに付与されたデータベースのコミット通番をログに付与する。待機系サーバは、ログに含まれる行の行ＩＤ、操作種別及び行データに基づいて、自サーバのデータベースを更新する。

図６は、本発明の第１の実施の形態のクラスタの状態を管理するクラスタ構成テーブル６００の一例を示す図である。

クラスタ構成テーブル６００は、クラスタ構成管理部１１９によって管理される。クラスタ構成テーブル６００は、サーバ名６０１、ＩＰアドレス６０２、及び、状態６０３を含む。

サーバ名６０１は、クラスタに含まれる実行系サーバ及び待機系サーバのサーバ名である。ＩＰアドレス６０２は、サーバ名６０１に対応するサーバのＩＰアドレスである。

状態６０３は、サーバ名６０１に対応するサーバの状態である。サーバの状態には、「実行系」、「待機系」、及び、「追加中」の３種類がある。また、待機系については、追加される待機系サーバにデータベースを複製する複製元となるか否かによって状態をさらに分類してもよい。

図７は、本発明の第１の実施の形態の実行系サーバ１００におけるログ送信部１１３のログ送信処理の手順を示すフローチャートである。

実行系サーバ１００のＣＰＵ１０１は、まず、ログ送信部１１３を実行し、ログ送信バッファ２１２にログが存在するか否かを判定する（Ｓ７０１）。

実行系サーバ１００のＣＰＵ１０１は、ログ送信バッファ２１２にログが存在する場合には（Ｓ７０１の結果が「Ｙｅｓ」）、当該ログをログ送信バッファから読み出す（Ｓ７０２）。

実行系サーバ１００のＣＰＵ１０１は、クラスタ構成管理部１１９からログ送信先リストを取得し（Ｓ７０３）、リストに含まれる待機系サーバにログを送信する（Ｓ７０４）。さらに、送信されたログをログ送信バッファから削除する（Ｓ７０５）。

実行系サーバ１００のＣＰＵ１０１は、ログ送信バッファ２１２にログが存在しなかった場合には（Ｓ７０１の結果が「Ｎｏ」）、ログの存在チェック（Ｓ７０１）を繰り返すことによって、ログがログ送信バッファ２１２に書き込まれるまで待機する。

図８は、本発明の第１の実施の形態の待機系サーバ２００におけるログ適用部２１６のログ適用処理の手順を示すフローチャートである。

待機系サーバ２００のＣＰＵ１０１は、ログ適用部２１６の状態が「ログ適用中状態」であるか否かを判定する（Ｓ８０１）。ログ適用部２１６の状態が「ログ適用中状態」でない場合には（Ｓ８０１の結果が「Ｎｏ」）、「ログ適用中状態」になるまで待機する。

待機系サーバ２００のＣＰＵ１０１は、ログ適用部２１６の状態が「ログ適用中状態」である場合には（Ｓ８０１の結果が「Ｙｅｓ」）、ログ受信バッファ２１５にログが存在するか否かを判定する（Ｓ８０２）。ログが存在しない場合には（Ｓ８０２の結果が「Ｎｏ」）、ログがログ受信バッファ２１５に書き込まれるまで待機する。

待機系サーバ２００のＣＰＵ１０１は、ログ受信バッファ２１５にログが存在した場合には（Ｓ８０２の結果が「Ｙｅｓ」）、当該ログをログ受信バッファ２１５から読み出す（Ｓ８０３）。

さらに、待機系サーバ２００のＣＰＵ１０１は、読み出されたログに含まれるコミット通番が、データベース２２１に格納されているコミット通番（適用済みコミット通番）よりも大きいか否かを判定する（Ｓ８０４）。読み出されたログに含まれるコミット通番が適用済みコミット通番よりも大きい場合には（Ｓ８０４の結果が「Ｙｅｓ」）、当該ログをデータベース２２１に反映する（Ｓ８０５）。さらに、データベース２２１のコミット通番を当該ログのコミット通番で更新する（Ｓ８０６）。

待機系サーバ２００のＣＰＵ１０１は、読み出されたログに含まれるコミット通番が適用済みコミット通番と等しいか小さい場合には（Ｓ８０４の結果が「Ｎｏ」）、同一のログを重複して適用してしまうことを避けるために、当該ログの適用及びコミット通番の更新を実行しない。ログの適用、非適用によらず、読み出したログをログ受信バッファ２１５から削除する（Ｓ８０７）。

図９は、本発明の第１の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。

図９に示すシーケンス図は、実行系サーバ１００及び待機系サーバ２００の２台の計算機が同期している状態に、待機系サーバ４００を新たに追加し、データベースを同期させて待機系サーバとして動作可能になるまでの手順を示している。

はじめに、クラスタ管理者によって管理サーバ１６０から待機系サーバ４００の追加が指示される（Ｓ９０１）。このとき、クラスタ管理者は、データベース送信元となる待機系サーバを指定してもよい。

管理サーバ１６０は、クラスタに追加される待機系サーバ（追加待機系サーバ）４００に、実行系サーバ１００のＩＰアドレスと共に待機系サーバの追加要求を送信する（Ｓ９０２）。

追加待機系サーバ４００のクラスタ構成管理部４１９は、待機系サーバの追加要求を受信すると、実行系サーバ１００のクラスタ構成管理部１１９に対し、クラスタ構成テーブルの転送を要求する（Ｓ９０３）。

実行系サーバ１００のクラスタ構成管理部１１９は、クラスタ構成テーブルの転送要求を受信すると、要求元である追加待機系サーバ４００のクラスタ構成管理部４１９にクラスタ構成テーブルを送信する（Ｓ９０４）。このとき、クラスタ構成テーブルには、待機系サーバ４００が追加される前のクラスタ構成の各サーバのエントリ、つまり、実行系サーバ１００及び待機系サーバ２００のエントリが含まれる。

追加待機系サーバ４００のクラスタ構成管理部４１９は、クラスタ構成テーブルを受信すると、データベース送信元待機系サーバをクラスタ構成テーブルから選択し、決定する（Ｓ９０５）。ここでは、唯一の待機系サーバである待機系サーバ２００がデータベース送信元待機系サーバとして選択される。また、Ｓ９０１の処理において管理者がデータベース送信元待機系サーバを指定した場合には、指定された待機系サーバがデータベース送信元待機系サーバとして選択される。

次に、追加待機系サーバ４００のクラスタ構成管理部４１９は、実行系サーバ１００のクラスタ構成管理部１１９にログ送信先追加要求を送信する（Ｓ９０６）。

実行系サーバ１００のクラスタ構成管理部１１９は、ログ送信先追加要求を受信すると、追加待機系サーバ４００のサーバ名及びＩＰアドレス、さらに、状態を「追加中」としてクラスタ構成テーブルにエントリを追加する（Ｓ９０７）。実行系サーバ１００のクラスタ構成テーブルに追加待機系サーバ４００が追加されると、実行系サーバ１００のデータベース１２１が更新された場合に、待機系サーバ２００に加えて、追加待機系サーバ４００に対してもログが送信される。なお、追加待機系サーバ４００のログ適用部４１６では、送信されたログを適用するデータベースの複製が完了していないため、「ログ適用開始待ち状態」となる。

ここで、実行系サーバ１００のデータベース１２１に対してデータベースの更新が要求された場合に、実行系サーバから待機系サーバに更新データを反映する処理は、図３に示したＳ３０１からＳ３０９までの処理と同じである。ただし、追加待機系サーバ４００では、前述したとおり、ログ適用部４１６が「ログ適用開始待ち状態」であるため、データベースの複製が完了し、ログ適用が開始されるまでの間は、ログ受信部４１４が受信したログはログ受信バッファ４１５に滞留されている。

追加待機系サーバ４００のクラスタ構成管理部４１９は、ログ送信先追加要求（Ｓ９０６）が完了すると、Ｓ９０５の処理で選択された待機系サーバ２００のデータベース送信部２１７にデータベース送信要求を送信する（Ｓ９０８）。

待機系サーバ２００のデータベース送信部２１７は、データベース送信要求を受信すると、ログ適用部２１６に対してログ反映処理の停止を指示する（Ｓ９０９）。ログ適用部２１６は、ログ反映処理の停止指示を受け付けると、ログ適用部２１６の状態を「ログ適用開始待ち状態」に変更する。これ以降、ログ受信部２１４が新たなログを受信した場合であっても、受信したログはログ受信バッファ２１５に滞留される。このようにして、ログ適用部２１６の反映処理が停止し、データベース２２１が静止化状態となる（Ｓ９１０）。

待機系サーバ２００のデータベース送信部２１７は、ログ適用部２１６のログ反映処理が停止すると、データベース２２１のデータを追加待機系サーバ４００のデータベース受信部４１８に送信する（Ｓ９１１）。データベース送信部２１７は、データベース２２１のデータの送信が完了すると、ログ適用部２１６に対してログ反映処理の再開を指示する（Ｓ９１４）。

待機系サーバ２００のログ適用部２１６は、ログ反映処理の再開指示を受け付けると、ログ適用部２１６の状態を「ログ適用中状態」に変更する（Ｓ９１５）。ログ適用部２１６の状態が「ログ適用中状態」になると、図８に示したように、ログ受信バッファ２１５に滞留していたログが、順次、データベース２２１に適用される（Ｓ３０８、Ｓ３０９）。そして、再び実行系サーバ１００のデータベース１２１と待機系サーバ２００のデータベース２２１が同期した状態となる。

追加待機系サーバ４００のデータベース受信部４１８は、待機系サーバ２００のデータベース送信部２１７から受信したデータをデータベース４２１に格納する（Ｓ９１２）。データベースの受信が完了すると、データベース受信部４１８は、クラスタ構成管理部４１９にデータベース受信完了を通知する（Ｓ９１６）。

追加待機系サーバ４００のクラスタ構成管理部４１９は、データベース受信完了通知を受信すると、ログ適用部４１６に対してログ反映処理の開始を指示する（Ｓ９１７）。ログ適用部４１６は、ログ反映処理の開始指示を受け付けると、ログ適用部４１６の状態を「ログ適用開始待ち状態」から「ログ適用中状態」に変更する。ログ適用部２１６の状態が「ログ適用中状態」になると、図８に示したように、ログ受信バッファ４１５に滞留していたログが、順次、データベース４２１に適用され（Ｓ３０８、Ｓ３０９）、追加待機系サーバ４００のデータベース４２１が実行系サーバ１００のデータベース１２１と同期した状態となる。

追加待機系サーバ４００のクラスタ構成管理部４１９は、その後、実行系サーバ１００のクラスタ構成管理部１１９及び待機系サーバ２００のクラスタ構成管理部２１９に、待機系追加完了通知を送信する（Ｓ９１８）。

実行系サーバ１００のクラスタ構成管理部１１９は、待機系追加完了通知を受信すると、Ｓ９０７の処理で追加された追加待機系サーバ４００のエントリの状態を「追加中」から「待機系」に変更する（Ｓ９１９）。待機系サーバ２００のクラスタ構成管理部２１９は、待機系追加完了通知を受信すると、追加待機系サーバ４００のサーバ名及びＩＰアドレス、さらに、状態を「待機系」としてクラスタ構成テーブルにエントリを追加する（Ｓ９２０）。

また、追加待機系サーバ４００のクラスタ構成管理部４１９は、追加待機系サーバ４００のサーバ名及びＩＰアドレス、さらに、状態を「待機系」としてクラスタ構成テーブルにエントリに追加する（Ｓ９２１）。この結果、クラスタ構成テーブルも実行系サーバ１００、待機系サーバ２００、及び、追加待機系サーバ４００の間で一致した状態となる。その後、クラスタ構成管理部４１９は、管理サーバ１６０に待機系サーバの追加完了を通知する（Ｓ９２２）。

管理サーバ１６０は、待機系サーバの追加完了が通知されると（Ｓ９２２）、クラスタ管理者に待機系サーバの追加処理が完了したことを提示する。また、図９には示していないが、データベース受信部４１８がデータベースデータの受信及び格納の進捗状況を、ログ適用部４１６がログ受信バッファ４１５に格納されるログ量を、管理サーバ１６０に報告することによって、クラスタ管理者に待機系サーバの追加処理の進捗状況を提示することができる。

図１０は、本発明の第１の実施の形態の追加待機系サーバ４００におけるクラスタ構成管理部４１９の待機系追加処理の手順を示すフローチャートである。

追加待機系サーバ４００のＣＰＵ１０１は、待機系サーバの追加要求を受信すると、実行系サーバ１００にクラスタ構成テーブルを要求し、当該クラスタ構成テーブルを取得する（Ｓ１００１、図９のＳ９０３及びＳ９０４の処理に対応）。

次に、追加待機系サーバ４００のＣＰＵ１０１は、取得したクラスタ構成テーブルの情報に基づいて、データベースの送信元となる待機系サーバを決定する（Ｓ１００２、図９のＳ９０５の処理に対応）。データベースの送信元となる待機系サーバは、ランダムに選択されてもよいし、最も負荷の低い待機系サーバを選択されてもよい。さらに、実行系サーバ１００のクラスタ構成管理部１１９にログ送信先追加要求を送信する（Ｓ１００３、図９のＳ９０６の処理に対応）。

追加待機系サーバ４００のＣＰＵ１０１は、Ｓ１００２の処理で決定されたデータベース送信元待機系サーバのデータベース送信部２１７にデータベース送信要求を送信する（Ｓ１００４、図９のＳ９０８の処理に対応）。さらに、データベース受信部４１８によってデータベースの受信が完了するまで待機する（Ｓ１００５）。

追加待機系サーバ４００のＣＰＵ１０１は、データベースの受信が完了すると、ログ適用部４１６にログの適用開始を指示する（Ｓ１００６、図９のＳ９１６及びＳ９１７の処理に対応）。

その後、追加待機系サーバ４００のＣＰＵ１０１は、実行系サーバ及びすべての待機系サーバのクラスタ構成管理部に待機系追加完了通知を送信する（Ｓ１００７、図９のＳ９１８の処理に対応）。さらに、クラスタ構成管理部４１９に保持されるクラスタ構成テーブルに、追加待機系サーバ４００のサーバ名及びＩＰアドレス、さらに、状態を「待機系」としてエントリを追加する（Ｓ１００８、図９のＳ９２１の処理に対応）。最後に、管理サーバ１６０に待機系サーバの追加完了を通知する（Ｓ１００９、図９のＳ９２２の処理に対応）。

図１１は、本発明の第１の実施の形態の実行系サーバ１００においてクラスタ構成管理部１１９がログ送信先追加要求を受信した際の処理の手順を示すフローチャートである。

実行系サーバ１００のＣＰＵ１０１は、クラスタ構成管理部１１９がログ送信先追加要求を受信すると、ログ送信先追加要求の送信元のサーバ名及びＩＰアドレス、さらに、状態を「追加中」として、クラスタ構成テーブルに追加する（Ｓ１１０１、図９のＳ９０７の処理に対応）。クラスタ構成テーブルに新たに追加される待機系サーバ４００のエントリを追加することによって、実行系サーバ１００でデータが更新されると、更新内容が待機系サーバ４００にも反映されるようになる。

図１２は、本発明の第１の実施の形態のデータベース送信元として選択された待機系サーバにおけるデータベース送信部２１７の処理の手順を示すフローチャートである。

待機系サーバ２００のＣＰＵ１０１は、データベース送信部２１７によって、データベース送信要求を受信する（Ｓ１２０１、図９のＳ９０８の処理に対応）。さらに、ログ受信バッファ２１５にデータベースに未反映のログが存在するか否かを判定する（Ｓ１２０２）。

待機系サーバ２００のＣＰＵ１０１は、未反映のログが存在する場合には（Ｓ１２０２の結果が「Ｙｅｓ」）、ログ受信バッファ２１５に含まれる最大のコミット通番を取得する（Ｓ１２０３）。さらに、データベース２２１のコミット通番が最大コミット通番と等しくなるまで待機する（Ｓ１２０４）。

次に、待機系サーバ２００のＣＰＵ１０１は、ログ適用部２１６を「ログ適用開始待ち状態」に設定することによって、ログの反映を停止する（Ｓ１２０５、図９のＳ９０９及びＳ９１０の処理に対応）。さらに、データベース送信要求の送信元サーバにデータベース２２１のデータを送信する（Ｓ１２０６、図９のＳ９１１の処理に対応）。データベース２２１のデータの送信が完了すると、ログ適用部２１６を「ログ適用中状態」に設定することによってログの反映を再開させる（Ｓ１２０７、図９のＳ９１３及びＳ９１４の処理に対応）。

図１３は、本発明の第１の実施の形態の実行系サーバ１００及び待機系サーバにおいて、クラスタ構成管理部が待機系追加完了通知を受信した際の処理の手順を示すフローチャートである。

実行系サーバ１００のＣＰＵ１０１は、まず、クラスタ構成テーブルに通知元サーバが既に「追加中」として登録されているか否かを判定する（Ｓ１３０１）。既に登録されている場合には（Ｓ１３０１の結果が「Ｙｅｓ」）、クラスタ構成テーブルに通知元サーバの状態を「追加中」から「待機系」に変更する（Ｓ１３０２）。登録されていない場合には（Ｓ１３０１の結果が「Ｎｏ」）、新たに通知元サーバを「待機系」としてクラスタ構成テーブルに登録する（Ｓ１３０３）。

以上のように、図３から図１３にて説明した処理によって、実行系サーバを停止することなく、新たなサーバを待機系として追加して、データ冗長性を回復することが可能となる。

なお、本発明の第１の実施の形態では、実行系サーバから待機系サーバに転送する更新情報として、ログを用いる方法を示したが、転送するデータは、実行系で更新されたデータを、待機系に反映するために必要な情報であればよい。例えば、更新されたデータそのものを転送してもよい。

さらに、データの転送は一度の送信ですべての処理を実施するのではなく、複数回に分割して送信してもよく、例えば、データが更新されたことのみを通知し、通知された待機系サーバがから更新情報を実行系に問い合わせる方法であってもよい。

また、転送する経路として、ネットワークを用いる場合を一例としたが、複数計算機間で通信可能な方法であれば、異なる転送経路を用いてもよい。例えば、ストレージ装置のボリューム複製機能を用いてもよいし、ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）を用いてもよい。さらに、複数の転送方法を選択可能な場合には、それらを組み合わせてもよい。例えば、待機系サーバからのデータベースの転送と、実行系サーバからの更新ログの転送とを別の転送方法を用いてもよい。

また、さらに別の方法として、事前にデータを定期的にディスクドライブなどの記憶装置に保存するチェックポイントダンプ又はスナップショットが実装されている場合には、当該保存されたデータを転送先となる追加計算機で読み出して、保存されたデータとの差分となるデータを転送元の計算機から転送してもよい。

本発明の第１の実施の形態によれば、待機系サーバからデータベースを複製するため、実行系サーバを停止することなく、新たなサーバを待機系サーバとして追加することが可能となる。

さらに、本発明の第１の実施の形態によれば、データベース送信元の待機系サーバがログ適用中に追加された待機系サーバからデータベース送信要求を受信した場合であっても、データベース送信元の待機系サーバのログ適用を停止し、データベースの複製が完了してから再開することによって、実行系サーバ、データベース送信元の待機系サーバ、及び、追加された待機系サーバに格納されたデータを同期させることが可能となる。

＜第２の実施の形態＞
本発明の第１の実施の形態では、実行系サーバ１００と１台の待機系サーバ２００とが含まれている計算機システムに、待機系サーバ４００を追加する手順について説明した。本発明の第２の実施の形態では、待機系サーバ２００及び待機系サーバ３００の２台の待機系サーバのデータベースが実行系サーバ１００のデータベース１２１と同期している状態で、待機系サーバ４００を新たにクラスタに追加してデータベースを同期させる手順について説明する。

なお、本発明の第２の実施の形態において、本発明の第１の実施の形態と共通する内容については適宜説明を省略する。

本発明の第１の実施の形態では、実行系サーバ１００と同期している待機系サーバが待機系サーバ２００のみであったため、追加待機系サーバ４００のクラスタ構成管理部４１９によるデータベース送信元待機系サーバ決定処理（Ｓ９０５及びＳ１００２）では唯一の待機系サーバである待機系サーバ２００をデータベース送信元待機系サーバとして選択していた。しかし、待機系サーバが複数存在する状況では、いずれの待機系サーバをデータベース送信元待機系サーバとして選択するかを判断する必要がある。

図１４は、本発明の第２の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。

本発明の第２の実施の形態では、実行系サーバ１００、待機系サーバ２００及び待機系サーバ３００の３台の計算機のデータベースが同期している状態に、待機系サーバ４００を新たに追加して同期させる。図１４は、本発明の第１の実施の形態における図９に対応する。図１４におけるＳ３００番台及びＳ９００番台の処理については、図９における処理と同じである。なお、図１４では、待機系サーバ２００の処理と待機系サーバ３００の処理とが同じであるため、待機系サーバ３００の記載を省略している。

追加待機系サーバ４００のクラスタ構成管理部４１９は、クラスタ構成テーブルを実行系サーバ１００から受信すると（Ｓ９０４）、クラスタ構成テーブルに含まれ、状態が「待機系」であるすべての待機系サーバのリソース使用量監視部に対してリソース使用率要求を送信する（Ｓ１４０１）。具体的には、待機系サーバ２００のリソース使用量監視部２２０及び待機系サーバ３００のリソース使用量監視部３２０にリソース使用率要求が送信される。

待機系サーバ２００のリソース使用量監視部２２０は、待機系サーバ２００におけるＣＰＵの使用率、メモリの使用率、ネットワーク帯域の使用率などを監視している。リソース使用率要求を受信すると、ＣＰＵの使用率、メモリの使用率、ネットワーク帯域の使用率を要求元に送信する（Ｓ１４０２）。待機系サーバ３００のリソース使用量監視部３２０についても同様である。

追加待機系サーバ４００のクラスタ構成管理部４１９は、各待機系サーバからリソース使用率を受信すると、待機系サーバのリソース使用率を比較し、最もリソース使用量が少ない待機系サーバをデータベース送信元待機系サーバとして選択する（Ｓ１４０３）。

データベース送信元の待機系サーバを選択した後の処理は、本発明の第１の実施の形態における図９に示した処理と同様である。

図１５は、本発明の第２の実施の形態のデータベース送信元待機系サーバ決定処理において使用されるリソース使用量の比較テーブルの一例を示す図である。

リソース使用量の比較テーブルには、待機系サーバごとのサーバ名、ＣＰＵ使用率、メモリ使用率、ネットワーク使用率が保持される。なお、各待機系サーバが利用可能なＣＰＵ及びネットワークなどのリソースが複数存在するような場合には、リソースごとの使用量を保持してもよい。

図１６は、本発明の第２の実施の形態の追加待機系サーバ４００のクラスタ構成管理部４１９におけるデータベース送信元待機系サーバ決定処理（Ｓ１００２）の手順を示すフローチャートである。

追加待機系サーバ４００のＣＰＵ１０１は、まず、クラスタ構成テーブルに含まれ、状態が「待機系」であるすべての待機系サーバにリソース使用率要求を送信し、リソースの使用率を取得する（Ｓ１６０１）。さらに、取得した各待機系サーバのリソースの使用率に基づいて、図１６に示したリソース使用量の比較テーブルを作成する。

次に、追加待機系サーバ４００のＣＰＵ１０１は、ＣＰＵ使用率、メモリ使用率、ネットワーク帯域使用率をリソース使用量の比較テーブルのサーバ間で比較し、最もリソース使用量が少ない待機系サーバをデータベース送信元待機系サーバとして選択する（Ｓ１６０２）。

リソース使用量の比較は、各待機系サーバから取得した各リソース使用率に基づいて評価値を算出し、最もリソース使用量の少ないサーバを選択する。比較方法の一例としては、以下の評価式によってリソース使用量を比較し、値が最も大きい待機系サーバをデータベース送信元待機系サーバとして選択する。

（１−ＣＰＵ使用率）×（１−メモリ使用率）×（１−ネットワーク帯域使用率）
また、別の比較方法として、単純にＣＰＵ使用率が最も小さい待機系サーバを選択してもよいし、同様にメモリ使用率又はネットワーク帯域使用率が最も小さい待機系サーバを選択してもよい。

本発明の第２の実施の形態では、リソースの例として、ＣＰＵ、メモリ、ネットワークについて述べたが、各サーバで用いられる他のハードウェア要素を用いてもよい。また、本発明の第２の実施の形態において、リソース使用量を表す情報として、使用率を用いて説明したが、直接的又は間接的にリソース使用量を表す指標を利用してもよい。

本発明の第２の実施の形態によれば、第１の実施の形態に示した効果に加えて、最もリソース使用率が小さい待機系サーバからデータベースを追加待機系サーバに転送することによって、新たな待機系サーバを速やかに追加することが可能となる。

＜第３の実施の形態＞
本発明の第３の実施の形態は、本発明の第１の実施の形態と同様に、待機系サーバ２００のデータベース２２１が実行系サーバ１００のデータベース１２１と同期しており、待機系サーバ４００を新たにクラスタに追加してデータベースを同期させる。

本発明の第１の実施の形態では、追加待機系サーバ４００は、実行系サーバ１００からのみログを取得したが、本発明の第３の実施の形態では、待機系サーバ２００からもログを取得する点が相違する。

図１７Ａ及び図１７Ｂは、本発明の第３の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。

本発明の第３の実施の形態では、実行系サーバ１００及び待機系サーバ２００の２台の計算機のデータベースが同期している状態に、待機系サーバ４００を新たに追加して同期させる。図１７Ａ及び図１７Ｂは、本発明の第１の実施の形態における図９に対応する。図１７Ａ及び図１７ＢにおけるＳ３００番台及びＳ９００番台の処理については、図９における処理と同じである。

以下、本発明の第１の実施の形態と相違する処理を中心に説明する。

クラスタ管理者によって管理サーバ１６０が待機系サーバの追加を指示してから（Ｓ９０１）、追加待機系サーバ４００のクラスタ構成管理部４１９がデータベース送信元待機系サーバを決定するまでの処理（Ｓ９０５）は、図９と同じである。

追加待機系サーバのクラスタ構成管理部４１９は、データベース送信元待機系サーバ２００にデータベース送信要求を送信する（Ｓ９０８）。その後、Ｓ９０９からＳ９１３までの処理は、図９と同じである。

データベース送信元待機系サーバ２００のデータベース送信部２１７は、データベースの送信が完了すると（Ｓ９１３）、クラスタ構成管理部２１９にログ送信先の追加を要求する（Ｓ９０６）。クラスタ構成管理部２１９は、追加待機系サーバ４００のサーバ名及びＩＰアドレス、さらに、状態を「追加中」としてクラスタ構成テーブルに追加する（Ｓ９０７）。その後、ログ反映の再開を指示する（Ｓ９１４）。

データベース送信元待機系サーバ２００のログ適用部２１６は、ログ反映の再開を指示されると、ログ反映の再開処理が実行される（Ｓ９１５）。ログ適用部２１６におけるログの反映処理においては、ログをデータベース２２１に反映した後に、当該ログをログ送信バッファ２１２にも書き込む（Ｓ１７０１）。

データベース送信元待機系サーバ２００のログ送信部２１３は、当該ログをログ送信バッファ２１２から読み出すと（Ｓ３０４）、クラスタ構成管理部２１９からログ送信先を取得する（Ｓ１７０２）。このとき、サーバの状態が「追加中」となっているサーバのみをログ送信先として取得する。そして、ログ送信先である追加待機系サーバ４００にログを送信する（Ｓ３０６）。送信されたログを受信した追加待機系サーバ４００におけるＳ３０７からＳ３０９までの処理は、図９と同じである。

待機系サーバ２００において、ログ反映停止Ｓ９１０からログ反映再開Ｓ９１５までの間に、データベースが更新された場合には、待機系サーバ２００で受信したログはログ受信バッファ２１５に保持される。

追加待機系サーバ４００におけるデータベース受信時の処理（Ｓ９１２、Ｓ９１６）は、図９と同じである。追加待機系サーバ４００のクラスタ構成管理部４１９は、データベース受信完了通知を受信すると、ログ適用部４１６にログの適用開始を指示（Ｓ９１７）し、ログの適用が開始（Ｓ１７０４）した後に、ログ送信先追加要求を実行系サーバ１００に送信する（Ｓ９０６）。実行系サーバ１００におけるＳ９０７の処理は、図９と同じの処理である。

したがって、実行系サーバ１００におけるＳ９０７の処理以降にデータベースに対してクライアントから更新が要求されると（Ｓ３０１）、追加待機系サーバ４００に対してもログが送信される（Ｓ３０２〜Ｓ３０７）。

追加待機系サーバ４００のログ適用部４１６は、ログを読み出してデータベースに反映する際に、ログのコミット通番とデータベース４２１のコミット通番を比較することによって、反映済みのログを重複して受信したことを検出することが可能である。ログの重複受信を検出した場合には、クラスタ構成管理部４１９に通知する（Ｓ１７０３）。クラスタ構成管理部４１９は、ログの重複受信を通知されると、実行系サーバ１００のクラスタ構成管理部１１９及び待機系サーバ２００のクラスタ構成管理部２１９に、待機系追加完了通知を送信する（Ｓ９１８）。以降のＳ９１９からＳ９２２までの処理は、図９と同じである。

図１８は、本発明の第３の実施の形態の追加待機系サーバ４００におけるクラスタ構成管理部４１９の待機系追加処理の手順を示すフローチャートである。

追加待機系サーバ４００のＣＰＵ１０１は、待機系サーバの追加要求を受信すると、実行系サーバ１００にクラスタ構成テーブルを要求し、クラスタ構成テーブルを取得する（Ｓ１８０１、図１７ＡのＳ９０３及びＳ９０４の処理に対応）。次に、追加待機系サーバ４００のＣＰＵ１０１は、取得したクラスタ構成テーブルの情報に基づいて、データベースの送信元となる待機系サーバを決定する（Ｓ１８０２、図１７ＡのＳ９０５の処理に対応）。なお、Ｓ１８０１及びＳ１８０２の処理は、図１０のＳ１００１及びＳ１００２の処理と同じである。

追加待機系サーバ４００のＣＰＵ１０１は、Ｓ１８０２の処理で決定されたデータベース送信元待機系サーバのデータベース送信部２１７にデータベース送信要求を送信する（Ｓ１８０３、図１７ＡのＳ９０８の処理に対応）。次に、データベース受信部４１８がデータベースの受信を完了するまで待機する（Ｓ１８０４）。

追加待機系サーバ４００のＣＰＵ１０１は、データベースの受信が完了すると、ログ適用部４１６にログの適用開始を指示する（Ｓ１８０５、図１７ＡのＳ９１７の処理に対応）。次に、実行系サーバ１００のクラスタ構成管理部１１９にログ送信先追加要求を送信する（Ｓ１８０６）。その後、ログ適用部４１６が重複受信を検出するまで待機する（Ｓ１８０７、図１７ＡのＳ１７０３の処理に対応）。

追加待機系サーバ４００のＣＰＵ１０１は、実行系サーバ及びすべての待機系サーバのクラスタ構成管理部に待機系追加完了通知を送信する（Ｓ１８０８、図１７ＢのＳ９１８の処理に対応）。さらに、クラスタ構成管理部４１９に保持されるクラスタ構成テーブルに、追加待機系サーバ４００のサーバ名及びＩＰアドレス、さらに、状態を「待機系」としてエントリを追加する（Ｓ１８０９、図１７ＢのＳ９２１の処理に対応）。最後に、管理サーバ１６０に待機系サーバの追加完了を通知する（Ｓ１８１０、図１７ＢのＳ９２２の処理に対応）。なお、Ｓ１８０８からＳ１８１０までの処理は、図１０のＳ１００７からＳ１００９までの処理と同じである。

以上、本発明の第３の実施の形態によれば、実行系サーバ１００がデータベース更新要求によってデータベース１２１を更新する場合であっても、待機系サーバ２００からデータベース２２１を複製し、さらに、待機系サーバ２００からログを転送して適用することによって、新たに追加される待機系サーバ４００のデータベース４２１を実行系サーバ１００のデータベース１２１と同期させることが可能となる。

また、本発明の第３の実施の形態と本発明の第２の実施の形態に記載される待機系サーバの決定方法を組み合わせることによって、複数の待機系が存在する場合に対しても、本発明の第３の実施の形態を適用可能である。

本発明の第３の実施の形態によれば、本発明の第１の実施の形態と比較して、追加待機系サーバ４００のログ受信バッファ４１５において一時的に保持しなければならないログの量を少なくすることができる。なお、データベース送信元待機系サーバ２００がログを送信しなければならないため、待機系サーバ２００のリソース使用量は増大する。

＜第４の実施の形態＞
本発明の第１の実施の形態ではデータベースデータをネットワーク経由で転送するが、本発明の第４の実施の形態では、ネットワーク帯域に余裕がある場合にはネットワーク経由でデータベースデータを転送するが、ネットワーク帯域に余裕がない場合には、データベース送信元待機系サーバ及び追加待機系サーバで共有されるストレージよってデータベースデータを転送する。

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

以下、図１に示した本発明の第１の実施の形態における計算機システムのハードウェア構成との相違点を中心に説明する。

実行系サーバ１００は、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）４を介してストレージ装置５にアクセスするＩ／Ｏインターフェース（ホストバスアダプタ）１０４を備える。待機系サーバ（２００、３００及び４００）についても、実行系サーバ１００と同様に構成される。

ストレージ装置５は、複数のディスクドライブを備え、実行系サーバ１００及び待機系サーバ（２００、３００及び４００）からアクセス可能な記憶領域として領域（ボリューム）５０１〜５０３が設定される。

図２０は、本発明の第４の実施の形態のデータベース送信元待機系サーバ２００のデータベース送信部２１７の処理手順を示すフローチャートである。

図２０に示す処理は、図１２に示した本発明の第１の実施の形態におけるＳ１２０６の処理の代わりに実行される。

データベース送信元待機系サーバ２００のＣＰＵ１０１は、データベース送信部２１７がデータベース送信要求を受信すると、リソース使用量監視部２２０からネットワーク帯域使用率を取得する（Ｓ２００１）。さらに、取得されたネットワーク帯域使用率があらかじめ設定された閾値（例えば５０％）よりも小さいか否かを判定する（Ｓ２００２）。ネットワーク帯域使用率が閾値よりも小さい場合には（Ｓ２００２の結果が「Ｙｅｓ」）、本発明の第１の実施の形態と同様にネットワークを使用してデータベースデータを送信する（Ｓ２００３）。

データベース送信元待機系サーバ２００のＣＰＵ１０１は、ネットワーク帯域使用率が閾値以上の場合には（Ｓ２００２の結果が「Ｎｏ」）、データベースデータをストレージのボリュームに書き込む（Ｓ２００４）。さらに、書き込まれたボリュームのＩＤを含む書き込み完了通知をデータベース送信要求の送信元にネットワーク経由で送信する（Ｓ２００５）。

なお、図２０では、データベース送信元待機系サーバ２００によってＳ２００２の判定処理が実行される例を説明したが、例えば、追加系計算機がリソース使用量の監視結果に基づいて判断し、データベース送信元待機系サーバ２００に送信方法を通知するようにしてもよい。さらに、本発明の第２の実施の形態で説明したデータベース送信元待機系サーバを選択する処理で、Ｓ２００２の判断処理を実行してもよい。この場合、選択方法の一部としてＳ２００２の処理を実行してもよく、ネットワークによるデータベース転送を優先した待機系サーバの追加が可能である。

図２１は、本発明の第４の実施の形態の追加待機系サーバ４００のデータベース受信部４１８の処理手順を示すフローチャートである。

図２１に示す処理は、本発明の第１の実施の形態におけるＳ９１２及びＳ９１６の処理の代わりに実行される。

追加待機系サーバ４００のＣＰＵ１０１は、データベース送信元待機系サーバ２００のデータベース送信部２１７から、データベースデータでなく、ストレージ装置５のデータ領域を識別する格納ボリュームＩＤを受信したか否かを判定する（Ｓ２１０１）。

追加待機系サーバ４００のＣＰＵ１０１は、格納ボリュームＩＤを受信した場合には（Ｓ２１０１の結果が「Ｙｅｓ」）、データベースデータを指定されたデータ領域であるボリュームから読み出し、データベース４２１に格納する（Ｓ２１０２）。一方、データベースデータを受信した場合には（Ｓ２１０１の結果が「Ｎｏ」）、受信したデータベースデータをデータベース４２１に格納する（Ｓ２１０３、図９のＳ９１２の処理に対応）。いずれの場合であっても、データベースデータの格納が完了すると、クラスタ構成管理部４１９にデータベースの受信完了を通知する（Ｓ２１０４、図９のＳ９１６の処理に対応）。

以上より、本発明の第４の実施の形態では、ネットワーク帯域に余裕がある場合にはネットワーク経由でデータベースデータを転送し、ネットワーク帯域に余裕がない場合にはデータベース送信元待機系サーバと追加待機系サーバで共有されるストレージよってデータベースデータを転送することができる。ここで、本発明の第４の実施の形態では、ネットワーク経由とストレージ経由とを選択する例を示したが、転送経路を変更するようにしてもよい。また、データベースデータの転送だけではなく、更新ログの転送に対して適用してもよい。

本発明の第４の実施の形態によれば、データ転送がログ転送処理又はその他の転送経路を使用する処理に影響を与える可能性がある場合に、当該影響を回避して性能に影響を与えることなく、データベースシステムに新しい待機系を追加することが可能となる。

＜第５の実施の形態＞
本発明の第５の実施の形態は、仮想化機構による仮想化機能及び仮想サーバのリソース使用量制御機能が利用可能な場合に、新たな待機系サーバをデータベースシステムに追加する実施形態である。

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

本発明の第１の実施の形態のハードウェア構成（図１）との相違点は、実行系サーバ１００のメモリ１０２に仮想化機構１０５が格納され、仮想化機構１０５が実行されることによって、仮想サーバ１０７が生成される。

仮想サーバ１０７は、仮想化機構１０５によって、計算機内のメモリ１０２、ＣＰＵ１０１及び通信インターフェース１０３などのリソースが仮想サーバ１０７ごとに分配されることによって、サーバと同等の機能を有することができる。仮想サーバ１０７は、仮想サーバ１０７の内部で、図２に示した実行系サーバ１００の内部で実行される機能ブロック１１１から１２１までの各部が実際の計算機上と同様に動作する。

仮想化機構１０５に含まれるリソース使用量制御部１０６は、設定値に基づいて、仮想サーバ１０７が使用するメモリ１０２、ＣＰＵ１０１及び通信インターフェース１０３などのリソース使用量を制御する機能を有する。なお、設定値は、外部から指定することが可能であり、例えば、管理サーバ１６０など他サーバから、又は、設定対象となる仮想サーバから設定されてもよい。

待機系サーバ２００、３００及び４００についても、実行系サーバ１００と同様に構成される。

図２３は、本発明の第５の実施の形態のリソース使用量制御部１０６に保持されるリソース使用量設定テーブルの一例を示す図である。

リソース使用量制御部１０６は、リソース使用量設定テーブルに基づいて、仮想サーバ１０７が使用可能なリソース量を制御する。リソース使用量設定テーブルは、サーバの仮想化機構１０５によって管理される仮想サーバ１０７の仮想サーバ名、サーバが保持するＣＰＵ１０１、メモリ１０２及び通信インターフェース１０３に対して各仮想サーバが使用可能なＣＰＵ使用率、メモリ使用率及びネットワーク使用率の上限を保持する。いずれの仮想サーバにも割り当てられていないリソースは、未割当て状態のリソースとしてリソース使用量設定テーブルに記録される。各仮想サーバのリソース使用率の上限は、あらかじめシステム管理者によって管理サーバ１６０を介して設定される。なお、各仮想サーバが利用可能なＣＰＵ又はネットワークなどのリソースが複数存在するような場合には、当該リソースのそれぞれに対する上限を保持することもできる。

図２４Ａ及び図２４Ｂは、本発明の第５の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。

本発明の第５の実施の形態では、サーバ仮想化機能及び仮想サーバのリソース使用量制御機能が利用可能な場合に、実行系仮想サーバ１０７及び待機系仮想サーバ２０７の計算機のデータベースが同期している状態に、待機系仮想サーバ４０７を新たに追加して同期させる。図２４Ａ及び図２４Ｂは、本発明の第１の実施の形態における図９に対応する。図２４Ａ及び図２４ＢにおけるＳ３００番台及びＳ９００番台の処理については、図９における処理と同じである。

以下、本発明の第１の実施の形態と相違する処理を中心に説明する。

本発明の第５の実施の形態では、追加待機系仮想サーバ４０７のクラスタ構成管理部４１９は、実行系仮想サーバ１０７にログ送信先の追加を要求する際に（Ｓ９０６）、リソース割当ての変更量を算出する（Ｓ２４０１）。さらに、自サーバのリソース使用量制御部４０６に対してリソース割当ての変更を要求する（Ｓ２４０２）。なお、図２４Ａでは、リソース割当量変更要求Ｓ２４０２を、ログ送信先追加要求Ｓ９０６の後に実施しているが、追加待機系サーバのリソース変更は、ログ書き込みＳ３０７及びログ反映Ｓ３０９を実施するためのリソースを割り当てるためであるため、例えば、Ｓ９０６の処理の前に実行してもよい。また、Ｓ３０７又はＳ３０９の処理を実行する場合に追加待機系サーバのログ受信部４１４又はログ適用部４１６がリソース割当量変更要求Ｓ２４０２を指示する形であってもよい。

リソース使用量制御部４０６は、リソース割当量変更要求Ｓ２４０２を受信すると、追加待機系仮想サーバ４０７のリソース使用量の上限を変更する（Ｓ２４０３）。その後、クラスタ構成管理部４１９は、データベース送信元待機系仮想サーバ２０７にデータベースの送信を要求する（Ｓ９０８）。データベース送信要求を受信した待機系仮想サーバ２０７のデータベース送信部２１７は、ログ適用部２１６にログ反映停止指示（Ｓ９０９）の前に、リソース割当ての変更量を算出し（Ｓ２４０４）、自サーバのリソース使用量制御部２０６に対してリソース割当ての変更を要求する（Ｓ２４０５）。

リソース使用量制御部２０６は、リソース割当量変更要求を受信すると、データベース送信元待機系仮想サーバ２０７のリソース使用量の上限を変更する（Ｓ２４０６）。なお、図２４Ａでは、リソース割当量変更要求Ｓ２４０５は、データベース送信元待機系仮想サーバ２０７から送信されているが、前述したリソース割当量変更要求Ｓ２４０２の場合と同様に、管理サーバ１６０が指示してもよい。さらにその場合には、Ｓ２４０２の処理と同様に、データベース送信要求Ｓ９０８よりも前に実施しても、後に実施してもよい。

その後、データベース送信元待機系仮想サーバ２０７のログ適用部２１６は、データベース送信（Ｓ９１１）の間にログ受信バッファ２１５に格納されたログを、ログ反映再開指示（Ｓ９１４）を受信してから、データベース２２１に順次反映する（Ｓ３０８、Ｓ３０９）。このとき、ログの反映と同時にログ受信バッファ２１５に格納されているログの量を監視する（Ｓ２４０７）。そして、ログの量が一定量以下、例えば、ログ反映停止指示Ｓ９０９を実施した時のログ量、又は、ログが一つも無くなった状態に減少したことを検出した場合には、ログ適用部２１６は、自サーバのリソース使用量制御部２０６に対してリソース割当量を戻すように要求する（Ｓ２４０８）。

ここで、リソース割当量戻し要求Ｓ２４０８は、ログ量の減少検出を管理サーバに通知することによって、リソース割当変更量要求Ｓ２４０５と同様に、管理サーバが行う形であってもよい。リソース使用量制御部２０６は、リソース割当量戻し要求を受信すると、Ｓ２４０６の処理で変更されたデータベース送信元待機系仮想サーバ２０７のリソース使用量の上限を変更前の状態に戻す（Ｓ２４０９）。

追加待機系仮想サーバ４０７についても同様に、ログ適用部４１６は、データベースの受信が完了し（Ｓ９１６）し、ログ反映開始指示（Ｓ９１７）を受信すると、ログ受信バッファ４１５に格納されたログをデータベース４２１に順次反映する（Ｓ３０８、Ｓ３０９）。このとき、ログの反映と同時にログ受信バッファ４１５に格納されているログの量を監視する（Ｓ２４１０）。ログの量が一定量以下に減少したことを検出した場合には、ログ適用部４１６は、自サーバのリソース使用量制御部４０６に対してリソースの割当量を戻すように要求する（Ｓ２４１１）。リソース使用量制御部４０６は、リソース割当量戻し要求を受信すると、Ｓ２４０３の処理で変更された追加待機系仮想サーバ４０７のリソース使用量の上限を変更前の状態に戻す（Ｓ２４１２）。

以上のように、本発明の第５の実施の形態では、データベースデータの転送からデータベースデータ転送処理中にログ受信バッファに滞留したログの反映が完了するまでの期間に、仮想化機構によって、仮想サーバに対するリソース割当量を増やす。したがって、データベースデータの転送及びログの反映を速やかに実行することが可能となり、結果としてデータベースシステムに新たな待機系仮想サーバを追加するために必要な時間を短縮することができる。

図２５は、本発明の第５の実施の形態のリソース割当変更量算出処理（Ｓ２４０１及びＳ２４０４）の手順を示すフローチャートである。

待機系サーバのＣＰＵ１０１は、まず、クラスタ構成テーブルを参照し、クラスタ構成テーブルに含まれる状態が「待機系」となっているサーバ数を算出する。さらに、状態が「待機系」であるサーバ台数が、あらかじめシステム管理者によって設定された複製数閾値よりも大きいか否かを判定する（Ｓ２５０１）。

待機系サーバのＣＰＵ１０１は、状態が「待機系」であるサーバ台数が複製数閾値を超えている場合には（Ｓ２５０１の結果が「ＹＥＳ」）、未割当てリソースのうち一部を追加のリソース割当て変更量とする（Ｓ２５０２）。例えば、未割当てリソースの半分を追加のリソース割当て変更量とする。若しくは、あらかじめシステム管理者によって指定される固定量を追加するリソース割当変更量とする。

待機系サーバのＣＰＵ１０１は、状態が「待機系」であるサーバ台数が複製数閾値を超えていない場合には（Ｓ２５０１の結果が「ＮＯ」）、未割当てリソースすべてを追加のリソース割当て変更量とする（Ｓ２５０３）。

本発明の第５の実施の形態によれば、追加される待機系サーバ及びデータベースの複製を提供する待機系サーバのリソース割当量を大きくすることによって、速やかに待機系仮想サーバの追加を完了させることができる。特に、待機系仮想サーバ数が少なくデータベースデータの冗長度が低い場合には、より多くのリソースを割り当てることによって、速やかにデータベースデータの冗長度を回復させることができる。なお、追加待機系サーバでリソース割当量を変更するための閾値は、システム管理者によって管理サーバに設定された閾値を追加待機系サーバ利用してもよいし、システム管理者によって直接設定されたものであってもよい。

ここで、本発明の第５の実施の形態では、追加される待機系サーバ及びデータベースの複製を提供する待機系サーバのリソース割当量を大きくする例を示したが、データ転送がログ転送処理又はその他の転送経路を使用する処理に影響を与える可能性がある場合には、当該影響を回避することを目的としてリソース割当量を小さくしてもよい。

本発明は、データ更新の性能劣化を防止しつつ待機系を追加することによって、データの冗長性を保証する技術に関するものであり、データの更新頻度が高く、高い信頼性が要求されるデータ処理システムに対して好適である。例えば、証券又は銀行などの金融分野における情報処理システムに好適である。

さらに、本発明は、データを転送する処理を含むため、高速なデータ転送手段を可能とするシステム、特に、内部バスによってサーバ間でデータを転送可能なブレードサーバを用いたシステムに対して好適である。

加えて、実施形態では、データベースシステムを例に待機系計算機を追加する方法について説明したが、本発明はデータベースシステムに限ったものではなく、実行系サーバに格納されたデータと待機系サーバに格納されたデータとを同期させるシステムに適用可能である。

また、実施形態では、複数台の計算機のうち、クライアントからのデータベース更新要求を受け付ける実行系サーバが一台であり、他の計算機は実行系サーバから更新情報の転送を受け付けて反映する待機系サーバである場合について説明したが、複数の実行系サーバが存在する場合に対しても、本発明を適用可能である。例えば、一つの計算機が実行系と待機系の双方の処理部を有することで、複数の計算機間で相互に更新情報を転送し、互いの更新を反映可能である。この場合には、各計算機が実行系と待機系の処理部を個別に有していてもよいし、共通する機能については同一の処理部を利用してもよい。

さらに、複数の計算機から更新情報が転送される待機系サーバは、各更新情報に対する処理部を複数有していてもよいし、共通する機能については同一の処理部を利用してもよい。加えて、この場合、本発明において追加される計算機も、データの同期後にクライアントからのデータベース更新要求を受け付けることによって、実行系サーバとして動作してもよい。

以上のように、複数のサーバにデータの複製を保持することによってデータの冗長性を保証するクラスタ型のデータベースシステムに対して本発明を適用することにより、データベースシステムの可用性を向上させることが可能となる。

本発明の第１の実施の形態の計算機システムのハードウェア構成を示すブロック図である。 本発明の第１の実施の形態のクラスタ構成のデータベースシステムのソフトウェアを主体とした機能ブロック図である。 本発明の第１の実施の形態の通常動作中にクライアントから送信されたデータベース更新要求によって、データベースが更新される処理を示すシーケンス図である。 本発明の第１の実施の形態のデータベースに格納された情報（業務処理で使用される表）の一例を示す図である。 本発明の第１の実施の形態のデータベースに格納された情報（コミット通番）の一例を示す図である。 本発明の第１の実施の形態のログ情報の一例を示す図である。 本発明の第１の実施の形態のクラスタの状態を管理するクラスタ構成テーブルの一例を示す図である。 本発明の第１の実施の形態の実行系サーバにおけるログ送信部のログ送信処理の手順を示すフローチャートである。 本発明の第１の実施の形態の待機系サーバにおけるログ適用部のログ適用処理の手順を示すフローチャートである。 本発明の第１の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。 本発明の第１の実施の形態の追加待機系サーバにおけるクラスタ構成管理部の待機系追加処理の手順を示すフローチャートである。 本発明の第１の実施の形態の実行系サーバにおいてクラスタ構成管理部がログ送信先追加要求を受信した際の処理の手順を示すフローチャートである。 本発明の第１の実施の形態のデータベース送信元として選択された待機系サーバにおけるデータベース送信部の処理の手順を示すフローチャートである。 本発明の第１の実施の形態の実行系サーバ及び待機系サーバにおいて、クラスタ構成管理部が待機系追加完了通知を受信した際の処理の手順を示すフローチャートである。 本発明の第２の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。 本発明の第２の実施の形態のデータベース送信元待機系サーバ決定処理において使用されるリソース使用量の比較テーブルの一例を示す図である。 本発明の第２の実施の形態の追加待機系サーバのクラスタ構成管理部におけるデータベース送信元待機系サーバ決定処理の手順を示すフローチャートである。 本発明の第３の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。 本発明の第３の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。 本発明の第３の実施の形態の追加待機系サーバにおけるクラスタ構成管理部の待機系追加処理の手順を示すフローチャートである。 本発明の第４の実施の形態における計算機システムのハードウェア構成を示すブロック図である。 本発明の第４の実施の形態のデータベース送信元待機系サーバのデータベース送信部の処理手順を示すフローチャートである。 本発明の第４の実施の形態の追加待機系サーバのデータベース受信部の処理手順を示すフローチャートである。 本発明の第５の実施の形態の計算機システムのハードウェア構成を示すブロック図である。 本発明の第５の実施の形態のリソース使用量制御部に保持されるリソース使用量設定テーブルの一例を示す図である。 本発明の第５の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。 本発明の第５の実施の形態の計算機システムに待機系サーバを追加する処理を示すシーケンス図である。 本発明の第５の実施の形態のリソース割当て変更量算出処理の手順を示すフローチャートである。

符号の説明

１００ 実行系サーバ
２００、３００、４００ 待機系サーバ
１６０ 管理サーバ
１１１ トランザクション制御部
１１２ ログ送信バッファ
１１３ ログ送信部
１１９、２１９、４１９ クラスタ構成管理部
１２１、２２１、４２１ データベース
２１４、４１４ ログ受信部
２１５、４１５ ログ受信バッファ
２１６、４１６ ログ適用部
２１７ データベース送信部
４１８ データベース受信部

Claims (12)

1. クライアントからの処理要求に応じて業務処理を実行する実行系計算機、及び、前記実行系計算機に格納されたデータの複製を格納する複数の待機系計算機を含み、前記複数の待機系計算機は前記実行系計算機でデータが更新された時に作成され前記実行系計算機から転送される更新情報を受けて、それぞれ自らが格納するデータの複製を更新する計算機システムにおいて、前記計算機システムに前記待機系計算機として新たに計算機を追加する方法であって、
   前記計算機システムから前記複数の待機系計算機の一つを選択し、
   前記実行系計算機から前記追加される計算機に前記更新情報の転送を開始し、
   前記選択された待機系計算機に格納された前記データの複製を前記追加される計算機に転送し、
   前記追加される計算機は、転送されたデータの複製を格納した後に、それまで滞留していた更新情報のそれぞれが重複反映にならないかを確認した上で前記格納したデータの複製に反映することを特徴とする待機系計算機の追加方法。
2. 前記実行系計算機及び前記待機系計算機には、データベース管理システムが稼動しており、
   前記実行系計算機及び前記待機系計算機に格納されるデータは、前記データベース管理システムによって管理されることを特徴とする請求項１に記載の待機系計算機の追加方法。
3. 前記更新情報は、前記データベース管理システムによって生成される更新ログであることを特徴とする請求項２に記載の待機系計算機の追加方法。
4. 前記方法は、前記選択された待機系計算機が前記追加される計算機に前記データの複製を転送する前に、前記実行系計算機に格納されたデータの更新情報を前記選択された待機系計算機に格納された前記データの複製に反映する処理を一時的に停止することを特徴とする請求項１に記載の待機系計算機の追加方法。
5. 前記方法は、前記選択された待機系計算機が前記追加される計算機に前記データの複製を転送する処理が完了した後、前記実行系計算機に格納されたデータの更新情報を前記選択された待機系計算機に格納された前記データの複製に反映する処理を再開することを特徴とする請求項４に記載の待機系計算機の追加方法。
6. 前記実行系計算機に格納されたデータの複製を転送する待機系計算機は、前記計算機システムに含まれる待機系計算機のリソース使用量に基づいて選択されることを特徴とする請求項１に記載の待機系計算機の追加方法。
7. 前記リソース使用量のリソースは、プロセッサ、メモリ及びネットワークの少なくとも一つが含まれることを特徴とする請求項６に記載の待機系計算機の追加方法。
8. 前記計算機システムは、データを格納するストレージ装置をさらに備え、
   前記待機系計算機の追加方法は、前記選択された待機系計算機のリソース使用量に基づいて、前記追加される計算機に前記データの複製を転送する際に、前記ストレージ装置を経由させるか否かを判定することを特徴とする請求項１に記載の待機系計算機の追加方法。
9. 前記計算機システムは、計算機の物理的なリソースを論理的に分割することによって、論理計算機を提供し、
   前記待機系計算機の追加方法は、前記選択された待機系計算機及び前記追加される計算機の少なくとも一方が前記論理計算機である場合に、当該論理計算機によって使用されるリソース量を変更した後に、前記データの複製を開始することを特徴とする請求項１に記載の待機系計算機の追加方法。
10. クライアントからの処理要求に応じて業務処理を実行する実行系計算機、及び、前記実行系計算機に格納されたデータの複製をそれぞれ格納し、かつ前記実行系計算機でデータが更新された時に作成され前記実行系計算機から転送される更新情報を受けて、それぞれ自らが格納するデータの複製を更新する複数の待機系計算機を含む計算機システムに、前記待機系計算機として新たに追加される計算機であって、
    前記追加される計算機は、
    前記実行系計算機に前記更新情報の転送を要求し、
    前記計算機システムから前記待機系計算機を選択し、
    前記選択された待機系計算機に、前記データの複製の転送を要求し、
    前記選択された待機系計算機から転送された前記データの複製を格納し、
    前記更新情報の転送が開始されてから滞留していた更新情報のそれぞれが重複反映にならないかを確認した上で前記格納したデータの複製に反映することを特徴とする計算機。
11. クライアントからの処理要求に応じて業務処理を実行する実行系計算機、及び、前記実行系計算機に格納されたデータの複製をそれぞれ格納し、かつ前記実行系計算機でデータが更新された時に作成され前記実行系計算機から転送される更新情報を受けて、それぞれ自らが格納するデータの複製を更新する複数の待機系計算機を含む計算機システムであって、
    前記待機系計算機として新たに計算機が追加される場合には、
    前記追加される計算機は、
    前記実行系計算機に前記更新情報の転送を要求し、
    前記計算機システムから前記複数の待機系計算機の一つを選択し、
    前記選択された待機系計算機に、前記データの複製の転送を要求し、
    前記選択された待機系計算機は、前記データの複製を前記追加される計算機に転送し、
    前記実行系計算機は、前記前記追加される計算機に更新情報の転送を開始し、
    前記追加される計算機は、前記転送されたデータの複製の格納が完了した後に、それまで滞留していた前記更新情報のそれぞれが重複反映にならないかを確認した上で前記格納したデータの複製に反映することを特徴とする計算機システム。
12. 前記実行系計算機及び前記待機系計算機には、データベース管理システムが稼動し、
    前記実行系計算機及び前記待機系計算機に格納されるデータは、前記データベース管理システムによって管理され、
    前記更新情報は、前記データベース管理システムによって生成される更新ログであることを特徴とする請求項１１に記載の計算機システム。

Images