特許 5901682 高可用性データベース管理システム、およびこれを用いたデータベース管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5901682

(24)【登録日】2016年3月18日

(45)【発行日】2016年4月13日

(54)【発明の名称】高可用性データベース管理システム、およびこれを用いたデータベース管理方法

(51)【国際特許分類】

   G06F 11/20 20060101AFI20160331BHJP

   G06F 12/00 20060101ALI20160331BHJP

【ＦＩ】

   G06F11/20 310E

   G06F12/00 531D

【請求項の数】1

【全頁数】16

(21)【出願番号】特願2014-84462(P2014-84462)

(22)【出願日】2014年4月16日

(62)【分割の表示】特願2012-518485(P2012-518485)の分割

【原出願日】2010年6月21日

(65)【公開番号】特開2014-149862(P2014-149862A)

(43)【公開日】2014年8月21日

【審査請求日】2014年4月16日

(31)【優先権主張番号】10-2009-0060314

(32)【優先日】2009年7月2日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】505205812

【氏名又は名称】ネイバー コーポレーション

【氏名又は名称原語表記】ＮＡＶＥＲ Ｃｏｒｐｏｒａｔｉｏｎ

(74)【代理人】

【識別番号】110000408

【氏名又は名称】特許業務法人高橋・林アンドパートナーズ

(72)【発明者】

【氏名】パク， キ ユン

(72)【発明者】

【氏名】キム， スン キュ

(72)【発明者】

【氏名】イ， ヒュ ユン

【審査官】 田中 幸雄

(56)【参考文献】

【文献】 特開２０００−０５７０３０（ＪＰ，Ａ）

【文献】 特開２００３−２９６２１１（ＪＰ，Ａ）

【文献】 特開２００２−１０８６４０（ＪＰ，Ａ）

【文献】 特開２００５−０１８４６３（ＪＰ，Ａ）

【文献】 特開２００５−２３４７５５（ＪＰ，Ａ）

【文献】 特開２００８−０５９５２９（ＪＰ，Ａ）

【文献】 特開２００７−２６４７７０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／２０

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

複数のブローカーノードおよび複数のサーバノードを含む高可用性データベース管理システムにおけるデータベース管理方法であって、
前記複数のブローカーノードのいずれか１つのブローカーノードが応用サーバからデータベースの変更要求を受信すると、前記変更要求を受信したブローカーノードが前記複数のサーバノードのうち主サーバノードに接続するステップと、
前記ブローカーノードが前記主サーバノードの接続に成功するかどうかを判断するステップと、
前記ブローカーノードが前記主サーバノードの接続に成功すると、前記ブローカーノードが前記データベースの変更要求を前記主サーバノードに処理させるようにするステップと、
前記ブローカーノードが前記主サーバノードの接続に失敗すると、前記ブローカーノードが前記ブローカーノードを副サーバノードのいずれか１つに接続させることによって、前記データベースの変更要求を前記副サーバノードに処理させるようにするステップと、
を含み、
前記データベースの変更要求によるトランザクションログは、前記主サーバノードおよび前記副サーバノードに反映され、
前記ブローカーノードが前記副サーバノードに接続された場合、
前記主サーバノードの障害発生後に前記主サーバノードの障害が復旧されると、前記主サーバノードをスタンバイ状態に設定し、前記副サーバノードが前記副サーバノードによるデータベースの変更要求処理によるトランザクションログを前記主サーバノードのデータベースに送信した後、前記主サーバノードをスタンバイ状態からアクティブ状態に変更することによって前記ブローカーノードを前記主サーバノードに再び接続させるステップをさらに含むことを特徴とするデータベース管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はデータベース管理システムに関し、より詳しくは高可用性データベース管理システムに関する。

【背景技術】

【0002】

データベース管理システム（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ：ＤＢＭＳ、以下「ＤＢＭＳ」と称する）は、膨大な量のデータが格納されているデータベースを管理するためのシステムであって、大量の情報が途切れることなく生成されている今の時代でなくてはならない重要要素として認識され、このようなＤＢＭＳはオンラインサービスを提供するために幅広い分野で様々に用いられている。

【0003】

このようなＤＢＭＳを運用する過程において、ＤＢＭＳ運用者のミスやシステムハードウェアの障害が発生する場合があり、この障害が発生する場合に莫大な損失につながる可能性がある。特に、２４時間持続的に提供されるポータルサービスの場合、上述のようなＤＢＭＳの障害は致命的である。

【0004】

したがって、ＤＢＭＳの障害発生にもかかわらず、ＤＢＭＳを用いるサービスを持続的に提供すること、ＤＢＭＳの障害復旧時にデータの流失を防止すること、すなわち、ＤＢＭＳの障害に対する対策がＤＢＭＳの運用において最も重要なイシューとも言える。

【0005】

このようなＤＢＭＳの障害に対する対策の１つとして、運用データベースを一定の時間周期的に別途の格納装置にバックアップする方式が提案される。この場合、ＤＢＭＳの障害が発生したときバックアップデータベースに基づいて運用データベースを復旧してサービスを再開することができる。しかし、データベースバックアップ方式の場合、一定の時間に周期的にデータベースをバックアップするため、バックアップデータベースを基に運用データベースを復旧するとしても、バックアップの後に生成されたデータは流失されてしまう恐れがあり、データ流失の範囲を減らすためにバックアップ周期を短くする場合にはシステムの負荷が加重してしまう問題がある。

【0006】

その他にも、オリジナルデータベースの非同期的な複製を介して待機（ｓｔａｎｄｂｙ）ＤＢＭＳを構成する方法が提案される。これはオリジナルデータベースの内容を待機ＤＢＭＳに持続的に複製することによって、オリジナルデータベースに障害が発生した場合に待機ＤＢＭＳを用いてサービスを提供する方式である。しかし、非同期式複製方法の場合、複製されたデータベースとオリジナルデータベースとが正確に一致しない場合があることから、ＤＢＭＳの障害が発生したときにデータの流失が発生する可能性があるという問題がある。

【0007】

例えば、オリジナルデータベースに基本キー（Ｐｒｉｍａｒｙ Ｋｅｙ）が１から１００までのデータが順次格納される過程において、基本キーが１から９９まで反映された状態で障害が発生したと仮定する場合、複製データベースにサービス提供は可能であるものの、複製データベースには基本キーが１００であるデータがないことから、基本キーが１００である新しいデータを追加することになるが、これはオリジナルデータベースにある基本キー１００のデータとは異なるものであるため、同一の基本キーを有する２つの異なるデータがオリジナルデータベースと複製データベースとに存在し、結果的にデータの流失が発生する。

【0008】

上述したデータベースのバックアップおよび複製方法の場合、上述した問題の他にも、ＤＢＭＳに障害が発生するとバックアップデータベースを用いて復旧した運用データベースの使用および複製データベースの使用の有無が手動で決定されてしまい、実質的にサービス中断が発生する問題がある。

【0009】

また、上述したデータベースのバックアップおよび複製方法の場合、ＤＢＭＳに障害が発生すると、ＤＢＭＳに接続するアプリケーションが直接データベースの接続メカニズムを変更しなければならないという問題もある。

【発明の概要】

【発明が解決しようとする課題】

【0010】

本発明は上述した問題点を解決するため、ＤＢＭＳの障害が発生しても持続的にサービスを提供することができる高可用性データベース管理システム、およびこれを用いたデータベース管理方法を提供することを技術的な課題とする。

【0011】

また、本発明は、ＤＢＭＳの障害が発生した場合、データを流失させることなく、持続的にサービスを提供することができる高可用性データベース管理システム、およびこれを用いたデータベース管理方法を提供することを他の技術的な課題とする。

【0012】

また、本発明は、主サーバノードと副サーバノードとの間の切り替え（Ｆａｉｌ−Ｏｖｅｒ）および復帰（Ｆａｉｌ−Ｂａｃｋ）が自動で行われることができる高可用性データベース管理システム、およびこれを用いたデータベース管理方法を提供することを更なる技術的な課題とする。

【0013】

また、本発明は、ＤＢＭＳの障害が発生しても、アプリケーションの修正や変更を行うことなく持続的にサービスを提供することができる高可用性データベース管理システム、およびこれを用いたデータベース管理方法を提供することを更なる技術的な課題とする。

【0014】

また、本発明は、ディスク基盤の高可用性データベース管理システム、およびこれを用いたデータベース管理方法を提供することを更なる技術的な課題とする。

【課題を解決するための手段】

【0015】

上述した目的を達成するための本発明の一実施形態に係る高可用性データベース管理システムを用いたデータベース管理方法は、複数のブローカーノードおよび複数のサーバノードを含む高可用性データベース管理システムにおけるデータベース管理方法であって、（ａ）応用サーバからデータベースの変更要求を受信すると、前記複数のブローカーノードのいずれか１つのブローカーノードを前記複数のサーバノードのうち主サーバノードに接続させるステップと、（ｂ）前記ブローカーノードが前記主サーバノードの接続に成功すると、前記データベースの変更要求を前記主サーバノードに処理させるようにし、前記主サーバノードの障害により前記ブローカーノードが前記主サーバノードの接続に失敗すると、前記ブローカーノードを副サーバノードのいずれか１つに接続させることによって、前記データベースの変更要求を前記副サーバノードに処理させるようにするステップと、を含むことを特徴とする。

【0016】

前記（ｂ）ステップにおいて、前記ブローカーノードが前記主サーバノードの接続に失敗すると、前記ブローカーノードを予め決定された順に応じて前記副サーバノードに順次接続させることを特徴とする。

【0017】

また、前記（ｂ）ステップにおいて、前記主サーバノードの障害が検出されると、前記ブローカーノードが接続される副サーバノードをスタンバイ状態からアクティブ状態に変更することによって、前記ブローカーノードが前記副サーバノードに接続可能にすることを特徴とする。

【0018】

一実施形態によると、前記（ｂ）ステップにおいて、前記ブローカーノードが前記副サーバノードに接続された場合、（ｃ）前記主サーバノードの障害復旧が検出されると、前記副サーバノードをアクティブ状態からスタンバイ状態に変更して前記副サーバノードに対する前記ブローカーノードの接続を遮断することによって、前記ブローカーノードを前記主サーバノードに接続させるステップをさらに含むことを特徴とする。

【0019】

また、前記（ｂ）ステップにおいて、前記ブローカーノードが前記副サーバノードに接続された場合、（ｃ）前記主サーバノードの障害発生後に前記主サーバノードの障害が復旧されると、前記主サーバノードをスタンバイ状態に設定し、前記副サーバノードによるデータベースの変更要求処理によるトランザクションログを前記主サーバノードのデータベースに反映した後、前記主サーバノードをスタンバイ状態からアクティブ状態に変更することによって前記ブローカーノードを前記主サーバノードに再び接続させるステップをさらに含むことを特徴とする。

【0020】

他の実施形態によると、前記（ｂ）ステップにおいて、前記データベースの変更要求を前記主サーバノードが処理する場合、前記（ｂ）ステップは、（ｂ１）前記主サーバノードが前記データベースの変更要求に応じて前記主サーバノードのデータベースを変更して前記データベースの変更によるトランザクションログを生成するステップと、（ｂ２）前記主サーバノードのデータベース複製のために前記トランザクションログを前記副サーバノードに送信するステップとを含むことを特徴とする。

【0021】

一方、前記副サーバノードは、前記主サーバノードから前記主サーバノードのトランザクションログが送信されると、前記副サーバノードのデータベースに前記主サーバノードのトランザクションログを反映することによって、前記主サーバノードのデータベースおよび前記副サーバノードのデータベースを同期させることを特徴とする。

【0022】

また、前記（ｂ）ステップにおいて、前記データベースの変更要求を前記副サーバノードが処理する場合、前記（ｂ）ステップは、（ｂ１）前記副サーバノードが前記データベースの変更要求に応じて前記副サーバノードのデータベースを変更して前記データベースの変更によるトランザクションログを生成するステップと、（ｂ２）前記副サーバノードのデータベース複製のために前記トランザクションログを前記主サーバノードまたは他の副サーバノードに送信するステップとを含むことを特徴とする。

【0023】

このとき、前記主サーバノードまたは他の副サーバノードは、前記副サーバノードから前記副サーバノードのトランザクションログが送信されると、前記主サーバノードまたは他の副サーバノードのデータベースに前記副サーバノードのトランザクションログを反映することによって、前記副サーバノードのデータベースと前記主サーバノードまたは他のサーバノードのデータベースとを同期させることを特徴とする。

【0024】

前述した複数のサーバノードはディスク基盤で運用されることを特徴とする。

【0025】

一方、前記（ａ）ステップは、前記ブローカーノードの障害有無を判断するステップをさらに含み、前記（ａ）ステップにおいて、前記ブローカーノードに障害が発生したと判断されると、前記複数のブローカーノードのうち予め決定された順に応じて他のブローカーノードが前記データベースの変更要求を受信することによって、前記他のブローカーノードを前記主サーバノードに接続させることを特徴とする。

【0026】

前述した目的を達成するための本発明の他の実施形態に係る高可用性データベース管理システムは、応用サーバからデータベースの変更要求を受信し、主サーバノードに接続を試みて接続が成功すると前記主サーバノードに前記データベースの変更要求を送信し、前記主サーバノードの障害により前記主サーバノードに対する接続が失敗すると、予め決定された順に応じて１つ以上の副サーバノードに順次接続を試みて接続が成功する副サーバノードに前記データベースの変更要求を送信するブローカーノードと、前記ブローカーノードが接続されると、前記ブローカーノードから送信される前記データベースの変更要求を受信して処理する主サーバノードと、前記主サーバノードの障害により前記ブローカーノードが接続されると、前記ブローカーノードから送信される前記データベースの変更要求を受信して処理する１つ以上の副サーバノードとを含むことを特徴とする。

【発明の効果】

【0027】

本発明によると、ＤＢＭＳの障害が発生しても持続的にサービスを提供することができるため、サービス提供の信頼度を向上させることができる効果がある。

【0028】

また、本発明は、同期式方法を用いてデータベースを複製できるため、ＤＢＭＳの障害が発生した場合、データの流失を防止することができる効果がある。

【0029】

また、本発明は、主サーバノードと副サーバノードとの間の切り替えおよび復帰が自動で行われることによって、活動サーバと待機サーバとの間の切り替えおよび復帰時間を短縮させることができる効果がある。

【0030】

また、本発明は、ＤＢＭＳの障害が発生してもＤＢＭＳの接続を担当するブローカーによってサービス可能なデータベースに対する接続が自動で決定されるため、アプリケーションが修正や変更を行うことなくサービスを提供できる効果がある。

【0031】

また、本発明は、ディスク基盤で運用されるため大容量のデータを容易に処理できる効果がある。

【図面の簡単な説明】

【0032】

【図1】本発明の一実施形態に係る高可用性データベース管理システムが適用されるネットワーク構成図を示す図である。

【図2】本発明の一実施形態に係るサーバノードの概略的な構成を示す図である。

【図3】サーバノードの状態遷移過程を概略的に示す図である。

【図4】サーバノードの切り替えおよび復帰過程を示す図である。

【図5】ＩＤＣ障害の発生時にサーバノードの切り替え過程を示す図である。

【図6】ブローカーノードの切り替えおよび復帰過程を示す図である。

【図7】本発明の一実施形態に係るデータベース管理方法を示すフローチャートである。

【図8】サーバノード間のデータベースの複製過程を示すフローチャートである。

【発明を実施するための形態】

【0033】

以下、添付する図面を参照しながら本発明の実施形態に対して詳細に説明する。

【0034】

図１は、本発明の一実施形態に係る高可用性データベース管理システムが適用される概略的なネットワーク構成図を示す。図１に示す高可用性データベース管理システム１００は、応用サーバ１１０から送信されるデータベースの変更要求を処理するものであり、図示するようにデータベース管理システム１００は、主ブローカーノード１２０ａ及び複数の副ブローカーノード１２０ｂ〜１２０ｍから構成される複数のブローカーノード１２０ａ〜１２０ｍと、主サーバノード１３０ａ及び複数の副サーバノード１３０ｂ〜１３０ｎから構成される複数のサーバノード１３０ａ〜１３０ｎとを含む。

【0035】

まず、複数のブローカーノード１２０ａ〜１２０ｍは、主ブローカーノード１２０ａと複数の副ブローカーノード１２０ｂ〜１２０ｍとから構成される。本実施形態において、ブローカーノード１２０ａ〜１２０ｍを複数個実装する理由は、主ブローカーノード１２０ａに障害が発生した場合、副ブローカーノード１２０ｂ〜１２０ｍが正常にサービスを提供できるようにするためである。

【0036】

具体的に、主ブローカーノード１２０ａは、応用サーバ１１０からデータベースの変更要求を受信し、先に主サーバノード１３０ａに接続を試みて接続が成功すると、主サーバノード１３０ａにデータベースの変更要求を送信する。

【0037】

もし、主サーバノード１３０ａに障害が発生して主サーバノード１３０ａとの接続が失敗すると、主ブローカーノード１２０ａは、主ブローカーノード１２０ａに含まれたサーバ接続リスト上で予め決定された順に応じて副サーバノード１３０ｂ〜１３０ｎに順次接続を試みて、接続が成功した副サーバノードにデータベースの変更要求を送信する。

【0038】

このように本発明は、主サーバノード１３０ａに障害が発生しても主ブローカーノード１２０ａが自動で副サーバノード１３０ｂ〜１３０ｎにデータベースの変更要求を送信し、副サーバノード１３０ｂ〜１３０ｎによってデータベースの変更要求が処理できるようにすることで、応用サーバ１１０を修正または変更することなく持続的にサービスを提供することができる。

【0039】

一方、主ブローカーノード１２０ａに障害が発生すると、副ブローカーノード１２０ｂ〜１２０ｍのうち、予め決定された順に応じていずれか１つの副ブローカーノードが応用サーバ１１０からデータベースの変更要求を受信し、受信されたデータベースの変更要求を主サーバノード１３０ａまたは副サーバノード１３０ｂ〜１３０ｎのいずれか１つに送信する。

【0040】

具体的に、主ブローカーノード１２０ａに障害が発生すると、第１副ブローカーノード１２０ｂが主ブローカーノード１２０ａで処理されていたサーバノードの中継作業を処理し、連続する障害により第１副ブローカーノード１２０ｂに障害が発生すると、第２副ブローカーノード１２０ｃがサーバノードの中継作業を引き受けて処理する。

【0041】

したがって、本発明では全てのブローカーノードが主ブローカーノードの役割を行うと同時に他のブローカーノードのバックアップの役割を行うことができるアクティブ（ａｃｔｉｖｅ）−アクティブ（ａｃｔｉｖｅ）構造であるため、ブローカーノードに重複的に発生し得る障害に備えることができる。

【0042】

次に、複数のサーバノード１３０ａ〜１３０ｎは、上述したように主サーバノード１３０ａと複数の副サーバノード１３０ｂ〜１３０ｍとから構成される。このとき、全てのサーバノードは同一のＩＤＣ（Ｉｎｔｅｒｎｅｔ Ｄａｔａ Ｃｅｎｔｅｒ）内に含まれてもよいが、変形された実施形態においては、一部の副サーバノードは主サーバノード１３０ａとは異なるＩＤＣ内に含まれてもよい。

【0043】

本実施形態において、サーバノードをブローカーノードのように複数個実装する理由は、主サーバノード１３０ａに障害が発生した場合、副サーバノード１３０ｂ〜１３０ｍが正常にサービスを提供できるようにするためである。

【0044】

図１に示すように、主サーバノード１３０ａは、主ブローカーノード１２０ａに接続されると、主ブローカーノード１２０ａから送信されるデータベースの変更要求を受信して処理する機能を行ない、副サーバノード１３０ｂ〜１３０ｎは主サーバノード１３０ａに発生した障害によってブローカーノード１２０ａが主サーバノード１３０ａと接続されない場合、主ブローカーノード１２０ａから送信されるデータベースの変更要求を受信して処理を行う。

【0045】

このとき、複数の副サーバノード１３０ｂ〜１３０ｎのうち、ブローカーノード１２０ａ〜１２０ｍが接続される副サーバノードは、上述したようにブローカーノード１２０ａ〜１２０ｍが保有しているサーバの接続リスト上における順に応じて決定される。

【0046】

以下は、図２を参照して上述したサーバノードの細部構成について具体的に説明する。

【0047】

図２は、サーバノードの細部構成を概略的に示す図である。図示するように、サーバノード１３０は、サーバ１３１、ログ記録部１３２、ログ反映部１３３、トランザクションログ格納部１３４、データベース１３５、障害検出部１３６を備える。以下は説明の便宜のために図２に示すサーバノードは主サーバノードであると仮定して説明する。

【0048】

まず、サーバ１３１は、ブローカーノード１２０ａ〜１２０ｍが主サーバノード１３０ａに接続すると、ブローカーノード１２０ａ〜１２０ｍからデータベースの変更要求を受信し、受信したデータベースの変更要求に応じてデータベース１３５を変更する。

【0049】

また、サーバ１３１は、データベースの変更要求に応じてデータベース１３５を変更すると同時に、データベース１３５の変更によるトランザクションログを生成してトランザクションログ格納部１３４に格納し、生成されたトランザクションデータログを複製して複数の副サーバノード１３０ｂ〜１３０ｎのうち少なくとも１つに送信する。

【0050】

ここで、サーバ１３１が自己のトランザクションログを複製して副サーバノード１３０ｂ〜１３ｎのうち少なくとも１つに送信することは、副サーバノード１３０ｂ〜１３０ｎが主サーバノード１３０ａのトランザクションログを副サーバノード１３０ｂ〜１３０ｎのデータベースに反映することによって主サーバノード１３０ａのデータベースを複製し、これにより主サーバノード１３０ａに障害が発生した場合、副サーバノード１３０ｂ〜１３０ｎが正常にサービスを提供できるようにするためである。

【0051】

ログ記録部１３２は、副サーバノード１３０ｂ〜１３０ｎのデータベースの変更事項を主サーバノード１３０ａのデータベースに反映するため、副サーバノード１３０ｂ〜１３０ｎから副サーバノード１３０ｂ〜１３０ｎのトランザクションログを受信してトランザクションログ格納部１３４に記録する。

【0052】

ログ記録部１３２が副サーバノード１３０ｂ〜１３０ｎのトランザクションログを受信してトランザクションログ格納部１３４に記録する理由は、主サーバノード１３０ａの障害のうち、副サーバノード１３０ｂ〜１３０ｎによって処理されたデータベースの変更要求の事項を主サーバノード１３０ａのデータベースにも同一に反映するためである。

【0053】

ログ反映部１３３は、ログ記録部１３２によって受信された副サーバノード１３０ｂ〜１３０ｎのトランザクションログを分析し、サーバ１３１を介してデータベース１３５に反映することでサーバノードのデータベースを同期化させる。

【0054】

一方、障害検出部１３６は、一定の周期に自己または副サブノードの障害または障害復旧の如何をモニタリングし、その結果をサーバ１３１に送信することによってサーバ１３１が自己の状態を変更するようにする。

【0055】

一実施形態において、障害検出部１３６は、主サーバノード１３０ａに障害が発生すると、障害が発生したことを副サーバノード１３０ｂ〜１３０ｎに送信することで副サーバノード１３０ｂ〜１３０ｎのいずれか１つのサーバノードの状態がスタンバイ状態からアクティブ状態に変更されるようにすることで、サービスを提供しているサーバノードが自動で副サーバノードに切り替えられる（ｆａｉｌ−ｏｖｅｒ）ようにする。

【0056】

また、障害検出部１３６は、主サーバノード１３０ａに発生した障害の復旧が検出されると、これをサーバ１３１およびサービスを担当している副サーバノードに通知する。これによって、主サーバノード１３０ａはスタンバイ状態からアクティブ状態に変更され、サービスを担当している副サーバノードはトゥービースタンバイ（Ｔｏ−ｂｅ−ｓｔａｎｄｂｙ）状態からスタンバイ状態になる。

【0057】

具体的に、主サーバノード１３０ａのサーバ１３１は、障害復旧が通知されると、主サーバノード１３０ａの状態をスタンバイ状態に設定し、主サーバノード１３０ａに障害が発生したときに発生した副サーバノード１３０ｂ〜１３０ｎのデータベース（図示せず）の変更事項に対するトランザクションログがデータベース１３５に反映されると、主サーバノード１３０ａの状態がスタンバイ状態からアクティブ状態に変更されることで、サービスを提供するサーバノードが自動で副サーバノードから主サーバノードに復帰（Ｆａｉｌ−Ｂａｃｋ）される。

【0058】

上述した障害検出部１３６が副サーバノード１３０ｂ〜１３０ｎに含まれる場合、障害検出部１３６は、主サーバノード１３０ａの障害が検出されると、副サーバノード１３０ｂ〜１３０ｎのモードがスタンバイ状態からアクティブ状態に変更されるようにし、主サーバノード１３０ａの障害復旧が検出されると、副サーバノード１３０ｂ〜１３０ｎのモードをアクティブ状態からスタンバイ状態に変更する。

【0059】

上述した障害検出部１３６は、ハートビート（Ｈｅａｒｔｂｅａｔ）プロセスを用いて実現されてもよい。

【0060】

一方、上述したような複数のサーバノード１３０ａ〜１３０ｎは、大容量のデータを処理するためにディスク基盤で運用されてもよい。

【0061】

以下は、図３を参照してサーバノードの状態変更の過程を説明するが、説明の便宜のために副サーバノードは１３０ｂと表記する。

【0062】

サーバノードの状態変更の過程を説明する前に各サーバノードの状態について簡略に説明する。サーバノードの状態は大きく、アイドル（Ｉｄｌｅ）状態、アクティブ状態、スタンバイ状態、トゥービーアクティブ（Ｔｏ−ｂｅ−ａｃｔｉｖｅ）状態、トゥービースタンバイ（Ｔｏ−ｂｅ−ｓｔａｎｄｂｙ）状態、およびデッド（Ｄｅａｄ）状態に区分される。

【0063】

まず、アイドル状態は、サーバノードが実行されていない状態として実際サーバノードにおかれていない状態である。

【0064】

次に、アクティブ状態は、データベースの変更要求、特にデータベースアップデート要求を処理することができる状態である。

【0065】

次に、スタンバイ状態は、アクティブ状態のサーバノードのトランザクションログを複製してスタンバイする状態を意味し、主サーバノード１３０ａは障害が発生して障害が復旧されるとスタンバイ状態に設定され、副サーバノード１３０ｂは最初にスタンバイ状態に設定される。サーバノードがスタンバイ状態である場合、サーバノードはデータベースの選択要求（ｓｅｌｅｃｔ）は処理できるものの、アップデート要求は処理できない。

【0066】

次に、トゥービーアクティブ状態は、スタンバイ状態のサーバノードがアクティブ状態になる以前の状態を意味し、主サーバノード１３０ａの場合、障害復旧の後にスタンバイ状態からアクティブ状態に遷移する過程を経過する状態であり、副サーバノード１３０ｂの場合、主サーバノード１３０ａの障害の発生時にスタンバイ状態からアクティブ状態に遷移する過程を経過する状態である。サーバノードがトゥービーアクティブ状態である場合、ブローカーノード１２０ａ〜１２０ｍの接続は許容されるものの、該当サーバノードがアクティブ状態になるまで全てのデータベースの変更要求はサスペンド（ｓｕｓｐｅｎｄ）される。

【0067】

次に、トゥービースタンバイ状態は、アクティブ状態であるサーバノードがスタンバイ状態になる以前の状態を意味し、主サーバノード１３０ａの障害が復旧されると、副サーバノード１３０ｂがアクティブ状態から再びスタンバイ状態に遷移する過程を経過する状態である。サーバノードがトゥービースタンバイ状態である場合、該当サーバノードで実行されていたトランザクションは続けて実行されるものの、新しいブローカーノード１２０ａ〜１２０ｍの接続は遮断される。

【0068】

最後に、デッド状態は、該当サーバノードに障害が発生したことを意味し、アイドル状態のように実際のサーバノードではない状態である。該当サーバノードがデッド状態である場合、該当サーバノードはスタンバイ状態にのみ遷移される。

【0069】

前述したサーバノードの状態遷移の過程を図３を参照して具体的に説明すると、まず、図３（ａ）に示すように、データベースの変更要求を受信すると、主サーバノード１３０ａは自己の状態をアイドル状態からアクティブ状態に遷移させ、副サーバノード１３０ｂは自己の状態をアイドル状態からスタンバイ状態に遷移させる。このような状態で主サーバノード１３０ａは、データベースの変更要求を処理しながら発生するトランザクションログを副サーバノード１３０ｂに送信することで、副サーバノード１３０ｂが主サーバノード１３０ａのデータベースを複製可能にする。

【0070】

その後、図３（ｂ）に示すように、主サーバノード１３０ａに障害が発生すると、主サーバノード１３０ａはアクティブ状態からデッド状態に遷移し、副サーバノード１３０ｂはスタンバイ状態からトゥービーアクティブ状態に遷移する。このような場合、ブローカーノード１２０ａ〜１２０ｍは、主サーバノード１３０ａにおける接続が遮断されるため、自動で副サーバノード１３０ｂに接続して副サーバノード１３０ｂにデータベースの変更要求を送信するが、副サーバノード１３０ｂがトゥービーアクティブ状態であることから、データベースの変更要求はサスペンドされる。

【0071】

その後、図３（ｃ）に示すように、副サーバノード１３０ｂは、主サーバノード１３０ａの全てのトランザクションログがデータベースに反映されたと判断されると、トゥービーアクティブ状態からアクティブ状態に遷移され、サスペンドされている全てのデータベースの変更要求を処理してもよい。

【0072】

その後、図３（ｄ）に示すように、主サーバノード１３０ａの障害が復旧されると、主サーバノード１３０ａはデッド状態からスタンバイ状態に遷移し、副サーバノード１３０ｂはアクティブ状態からトゥービースタンバイ状態に遷移する。このような場合、副サーバノード１３０ｂにおけるデータベースの変更要求の送信は遮断されるが、副サーバノード１３０ｂで実行していたトランザクションは続けて実行される。

【0073】

その後、図３（ｅ）に示すように、主サーバノード１３０ａは副サーバノード１３０ｂのトランザクションログを主サーバノード１３０ａのデータベースに反映して自己の状態をスタンバイ状態からトゥービーアクティブ状態に遷移させ、副サーバノード１３０ｂは自己の状態をトゥービースタンバイ状態からスタンバイ状態に遷移させる。このような場合、ブローカーノード１２０ａ〜１２０ｍは、主サーバノード１３０ａにデータベースの変更要求を送信するが、主サーバノード１３０ａがトゥービーアクティブ状態であるためデータベースの変更要求はサスペンドされる。

【0074】

最後に、図３（ｆ）に示すように、主サーバノード１３０ａは副サーバノード１３０ｂの全てのトランザクションログが主サーバノード１３０ａに反映されたと判断すると、自己の状態をトゥービーアクティブ状態からアクティブ状態に遷移させることによって、サスペンドされているデータベースの変更要求を処理し、副サーバノード１３０ｂは自己の状態をトゥービースタンバイ状態からスタンバイ状態に遷移させる。

【0075】

以下は、図４を参照して主サーバノードに障害が発生した場合、サーバノードの切り替えおよび復帰過程について例を挙げて説明する。以下は説明の便宜のためにブローカーノードを１２０と表記する。

【0076】

まず、ブローカーノード１２０が第１データベースの変更要求を主サーバノード１３０ａに送信すると、主サーバノード１３０ａは第１データベースの変更要求を処理した後、第１複製ログを生成して第１副サーバノード１３０ｂおよび第２副サーバノード１３０ｃに送信し、ブローカーノード１２０に第１データベースの変更要求の処理成功を通知する。

【0077】

その後、主サーバノード１３０ａに障害が発生した場合、第１副サーバノード１３０ｂは、主サーバノード１３０ａの障害発生を検出し、第１副サーバノード１３０ｂの状態をスタンバイ状態からトゥービーアクティブ状態に変更して、主サーバノード１３０ａの全てのトランザクションログをデータベースに反映する。

【0078】

一方、ブローカーノード１２０は、主サーバノード１３０ａに接続されないため第２データベースの変更要求を第１副サーバノード１３０ｂに送信するが、第１副サーバノード１３０ｂはトゥービーアクティブ状態であるため第２データベースの変更要求はサスペンドされる。

【0079】

その後、第１副サーバノード１３０ｂによって主サーバノード１３０ａの全てのトランザクションログの反映が完了すると、第１副サーバノード１３０ｂは自己の状態をトゥービーアクティブ状態からアクティブ状態に遷移させる。このとき、第１副サーバノード１３０ｂは、サスペンドされている第２データベースの変更要求を処理した後、第２複製ログを生成して第２副サーバノード１３０ｃに送信し、ブローカーノード１２０に第２データベースの変更要求の処理成功を通知する。

【0080】

その後、第１副サーバノード１３０ｂはブローカーノード１２０から第３データベースの変更要求を受信し、第３データベースの変更要求の処理過程中に主サーバノード１３０ａの障害復旧が検出されると、自己の状態をアクティブ状態からトゥービースタンバイ状態に変更する。このとき、第１副サーバノード１３０ｂは、現在の処理中である第３データベースの変更要求を続けて処理することによって第３複製ログを生成するが、ブローカーノードの接続は遮断されるようになる。

【0081】

一方、主サーバノード１３０ａは自己の状態をスタンバイ状態に設定した後、スタンバイ状態をトゥービーアクティブ状態に変更し、第１副サーバノード１３０ｂに接続して障害発生のときに発生した第２複製ログおよび第３複製ログを要求し、第１副サーバノード１３０ｂは第２および第３複製ログを主サーバノード１３０ａに送信してブローカーノード１２０に第３データベースの変更要求の成功を通知する。

【0082】

その後、ブローカーノード１２０は第１副サーバノード１３０ｂへの接続が遮断されたため再び主サーバノード１３０ａに第４データベースの変更要求を送信するが、第１副サーバノード１３０ｂがトゥービーアクティブ状態であるため第４データベースの変更要求はサスペンドされる。

【0083】

その後、主サーバノード１３０ａが第２および第３複製ログをデータベースに反映した後自己の状態をアクティブ状態に変更し、サスペンドされている第４データベースの変更要求を処理することによって第４複製ログを生成し、第１および第２副サーバノード１３０ｂ、１３０ｃに送信する。

【0084】

以下は、図５を参照してＩＤＣ障害が発生したときのサーバノードの切り替え過程について例を挙げて説明する。

【0085】

まず、ブローカーノード１２０が第１データベースの変更要求を主サーバノード１３０ａに送信すると、主サーバノード１３０ａは第１データベースの変更要求を処理した後第１複製ログを生成して第１副サーバノード１３０ｂおよび第２副サーバノード１３０ｃに送信し、ブローカーノード１２０に第１データベースの変更要求の処理成功を通知する。

【0086】

その後、ＩＤＣ障害の発生に応じて同一のＩＤＣに含まれた主サーバノード１３０ａおよび第１副サーバノード１３０ｂの全てに障害が発生した場合、第２副サーバノード１３０ｃはＩＤＣ障害発生を検出して第２副サーバノード１３０ｃの状態をスタンバイ状態からトゥービーアクティブ状態に変更し、主サーバノード１３０ａの全てのトランザクションログをデータベースに反映する。

【0087】

一方、ブローカーノード１２０は、主サーバノード１３０ａおよび第１副サーバノード１３０ｂの全てに対して接続されないため、第２データベースの変更要求を第２副サーバノード１３０ｃに送信するが、第２副サーバノード１３０ｃはトゥービーアクティブ状態であるため第２データベースの変更要求はサスペンドされる。

【0088】

その後、第２副サーバノード１３０ｃによって主サーバノード１３０ａの全てのトランザクションログの反映が完了すると、第２副サーバノード１３０ｃは自己の状態をトゥービーアクティブ状態からアクティブ状態に遷移させる。このとき、第２副サーバノード１３０ｃは、サスペンドされている第２データベースの変更要求を処理してから第２複製ログを生成した後、ブローカーノード１２０に第２データベースの変更要求の処理成功を通知する。

【0089】

以下は、図６を参照してブローカーノードに障害が発生したときのブローカーノードの切り替えおよび復帰過程について例を挙げて説明する。

【0090】

まず、応用サーバ１１０から第１データベースの変更要求が主ブローカーノード１２０ａに受信されると、主ブローカーノード１２０ａは第１データベースの変更要求を主サーバノード１３０ａに送信し、主ブローカーノード１２０ａから第１データベースの変更要求の処理成功が通知されると、これを応用サーバに送信する。

【0091】

その後、主ブローカーノード１２０ａに障害が発生すると、応用サーバ１１０は主ブローカーノード１２０ａに接続できないため、副ブローカーノード１２０ｂに第２データベースの変更要求を送信する。

【0092】

副ブローカーノード１２０ｂは、応用サーバ１１０から送信される第２データベースの変更要求を受信して主サーバノード１３０ａに送信し、主サーバノード１３０ａから第２データベースの変更要求の処理成功が通知されると、これを応用サーバに送信する。

【0093】

その後、応用サーバ１１０は依然として主ブローカーノード１２０ａが障害状態であるため、第３データベースの変更要求を副ブローカーノード１２０ｂに送信し、副ブローカーノード１２０ｂから第３データベースの変更要求の処理成功を通知される。

【0094】

その後、主ブローカーノード１２０ａの障害が復旧されると、応用サーバ１１０は主ブローカーノード１２０ａへの接続が可能であるため、第４データベースの変更要求を主ブローカーノード１２０ａに送信し、これによって第４データベースの変更要求の処理成功を主ブローカーノード１２０ａから通知されるようになる。

【0095】

以下は、図７を参照して本発明に係る高可用性データベース管理システムを用いてデータベースを管理する方法を説明する。

【0096】

まず、応用サーバからデータベースの変更要求が受信される（Ｓ７００）と、主ブローカーノードへの接続が可能であるか否かを判断する（Ｓ７１０）。

【0097】

判断の結果、主ブローカーノードへの接続が可能であれば、主ブローカーノードにデータベースの変更要求を送信し（Ｓ７２０）、主ブローカーノードに接続不可能であれば、予め決定された接続の順に応じて副ブローカーノードへの接続を試みることによって、接続可能な副ブローカーノードにデータベースの変更要求を送信する（Ｓ７３０）。

【0098】

その後、主ブローカーノードまたは副ブローカーノードは主サーバノードに接続可能であるか否かを判断する（Ｓ７４０）。判断の結果、主サーバノードに接続可能であれば、主サーバノードにデータベースの変更要求を送信し（Ｓ７５０）、主サーバノードに接続不可能であれば、予め決定されたサーバノード接続の順に応じて副サーバノードに接続を試みることによって、接続可能な副サーバノードにデータベースの変更要求を送信する（Ｓ７６０）。

【0099】

その後、データベースの変更要求が送信された主サーバノードまたは副サーバノードは、データベースの変更要求を処理することによって各自のデータベースを変更し（Ｓ７７０）、その処理結果を主ブローカーノードまたは副ブローカーノードを経由して応用サーバに送信する（Ｓ７８０）。

【0100】

上述したように、本発明では全てのブローカーノードが主ブローカーノードの役割を行うと同時に他のブローカーノードのバックアップの役割を行うことができるアクティブ（Ａｃｔｉｖｅ）−アクティブ（Ａｃｔｉｖｅ）構造であるため、ブローカーノードで重複的に発生する障害にも備えることができる。

【0101】

また、本発明ではサーバノードを複数実装することによって、主サーバノードに障害が発生してもブローカーノードが自動で副サーバノードに接続されるため、応用サーバを修正または変更することなく持続的なサービスを提供することができる。

【0102】

一方、連続的なサービス提供のためには主サーバノードと副サーバノードとの間にデータベースの複製を行わなければならないが、以下は図８を参照して主サーバノードと副サーバノードとの間のデータベースの複製過程を説明する。

【0103】

まず、主サーバノードがブローカーノードからデータベースの変更要求を受信する（Ｓ８００）。その後、主サーバノードはデータベースの変更要求を処理し（Ｓ８１０）、データベースの変更によるトランザクションログを生成して記録する（Ｓ８２０）。

【0104】

その後、主サーバノードは、自己に接続された副サーバノードが存在するか否かを判断し（Ｓ８３０）、存在する場合、接続された副サーバノードに生成されたトランザクションログを送信する（Ｓ８４０）。

【0105】

その後、主サーバノードはデータベースの変更に対する終了要求が受信されると、データベースの変更完了を通知する（Ｓ８５０）。

【0106】

一方、ステップＳ８４０によって主サーバノードから送信される主サーバノードのトランザクションログを受信した副サーバノードは、受信した主サーバノードのトランザクションログを記録した後（Ｓ８６０）、記録されたトランザクションログを分析する（Ｓ８７０）。その後、副サーバノードは、分析された主サーバノードのトランザクションログを自己のデータベースに反映することで主サーバノードのデータベースの変更事項が副サーバノードのデータベースにも反映されるようにする（Ｓ８８０）。

【0107】

上述したように主サーバノードおよび副サーバノードは互いのトランザクションログを送受信することによってデータベースを複製し、主サーバノードの障害が発生した場合、副サーバノードが自己のデータベースを用いてサービスを連続的に提供する。その後、主サーバノードの障害が復旧されると、主サーバノードが再び副サーバノードのトランザクションログを受信して自己のデータベースに反映することで反映が完了すると、再び主サーバノードがサービスのデータベースを用いてサービスを連続的に提供する。

【0108】

連続的なサービスを提供するために主サーバノードと副サーバノードとの間の切り替えおよび復帰過程で発生する各サーバノードの状態を上述した図３を参照して詳説したため、その具体的な説明は省略する。

【0109】

上記したデータベース管理方法は、多様なコンピュータ手段を介して様々な処理を実行することができるプログラム命令の形態で実現され、コンピュータ読取可能な記録媒体に記録されてもよい。コンピュータ読取可能な媒体は、プログラム命令、データファイル、データ構造などのうちの１つまたはその組み合わせを含んでもよい。媒体に記録されるプログラム命令は、本発明の目的のために特別に設計されて構成されたものでもよく、コンピュータソフトウェア分野の技術を有する当業者にとって公知のものであり、使用可能なものであってもよい。コンピュータ読取可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光記録媒体、光ディスクのような光磁気媒体、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を保存して実行するように特別に構成されたハードウェア装置が含まれてもよい。プログラム命令の例としては、コンパイラによって生成されるような機械語コード（ｍａｃｈｉｎｅ ｃｏｄｅ）だけでなく、インタプリタなどを用いてコンピュータによって実行され得る高級言語コード（ｈｉｇｈｅｒ ｌｅｖｅｌ ｃｏｄｅ）を含む。上述したハードウェア装置は、本発明の動作を行うために１つ以上のソフトウェアのレイヤで動作するように構成されてもよい。

【0110】

上述したように、本発明を限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態から多様な修正及び変形が可能である。

【0111】

したがって、本発明の範囲は、開示された実施形態に限定されるものではなく、特許請求の範囲だけではなく特許請求の範囲と均等なものなどによって定められるものである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】