(57)【特許請求の範囲】
【請求項１】
別個の制御環境を使用して、データベース環境内の複製データベースインスタンスを管理するコンピュータ実装方法であって、
実行可能な命令を用いて構成される１つ以上のコンピュータシステムの制御下で、別個の制御環境の監視構成要素を使用して、データベース環境内の一次インスタンス複製および二次インスタンス複製のそれぞれに対する状態情報を監視することと、
前記監視構成要素が、前記一次インスタンス複製および二次インスタンス複製の中の第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、
前記第１および第２のインスタンス複製が、互いに通信することが可能であるかどうか、ならびに前記第１および第２のインスタンス複製が、共通のデータ世代識別子を有するかどうかを含む、故障情報を判定することと、
前記故障情報に少なくとも部分的に基づき、前記制御環境内で実行されるワークフローを判定することであって、前記ワークフローは、前記監視構成要素が前記第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、前記データベース環境内で実行される１つ以上のタスクを含む、判定することと、
前記制御環境内で前記ワークフローを実行することと、を含む、コンピュータ実装方法。
【請求項２】
前記ワークフローは、前記二次インスタンス複製に、前記監視構成要素が最短期間に前記一次複製と通信することができない場合、前記二次インスタンス複製が前記一次複製と通信することができない場合、ならびに前記第２のインスタンス複製が前記一次複製の最新の既知の状態と共通のデータ世代識別子を有する場合、前記複製データベースインスタンスに対する新しい一次複製となるフェイルオーバー操作を実行させるタスクを含む、請求項１に記載のコンピュータ実装方法。
【請求項３】
前記ワークフローは、前記監視構成要素が最短期間に前記二次複製と通信することができない場合、ならびに前記一次インスタンス複製が前記二次複製と通信することができない場合、前記複製データベースインスタンスに対する新しい二次インスタンス複製を生成する、二次インスタンス複製復旧プロセスを実行させるタスクを含む、請求項１に記載のコンピュータ実装方法。
【請求項４】
前記ワークフローは、前記監視構成要素が最短期間に前記一次複製および前記二次複製のうちどちらともと通信することができない場合、前記一次および二次インスタンス複製が互いに通信することが可能である場合、ならびに前記一次および二次インスタンス複製が共通のデータ世代識別子を有する場合、フェイルオーバーまたは復旧操作を実施することなしに、前記制御環境内のデータストアに情報を記憶するタスクを含む、請求項１に記載のコンピュータ実装方法。
【請求項５】
前記第１および第２のインスタンス複製は、単一のデータゾーン内、別個の地理的な位置における別個のデータゾーン内、複数の地理的な位置にわたる単一のデータゾーン内、または単一の地理的な領域内の複数のデータゾーンにわたってプロビジョニングされる、請求項１に記載のコンピュータ実装方法。
【請求項６】
前記少なくとも１つの監視構成要素は、第３のデータゾーン内または地理的な位置、あるいは第１もしくは第２のデータゾーンまたは地理的な位置のうちの１つに配置される、請求項５に記載のコンピュータ実装方法。
【請求項７】
ユーザは、前記ユーザが現在の一次インスタンス複製と通信することを可能にする別名を提供され、フェイルオーバー操作が、前記二次インスタンス複製を、新しい現在の一次インスタンス複製にさせる場合を含む、請求項１に記載のコンピュータ実装方法。
【請求項８】
前記第１および第２のインスタンス複製のそれぞれは、前記データベース環境内の別個のデータインスタンス上で動作され、各データインスタンスは、１つ以上の専用ブロック記憶ボリュームに付けられる、請求項１に記載のコンピュータ実装方法。
【請求項９】
前記第１のインスタンス複製と第２のインスタンス複製との前記１つ以上の専用ブロック記憶ボリュームの間のデータを、同期的に複製するよう操作可能なブロックレベル複製機構を使用して、前記一次インスタンス複製から前記二次インスタンス複製へデータを同期的に複製することをさらに含む、請求項８に記載のコンピュータ実装方法。
【請求項１０】
別個の制御環境を使用して、データベース環境内の複製データベースインスタンスを管理するためのシステムであって、
プロセッサと、
メモリデバイスであって、前記プロセッサによって実行されると、前記プロセッサに、
別個の制御環境の少なくとも１つの監視構成要素を使用して、データベース環境内の一次インスタンス複製および二次インスタンス複製のそれぞれに対する状態情報を監視させることと、
前記少なくとも１つの監視構成要素が、前記第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、
前記一次インスタンス複製および二次インスタンス複製の中の第１および第２のインスタンス複製が互いに通信することが可能かどうか、ならびに前記第１および第２のインスタンス複製が共通のデータ世代識別子を有するかどうかを含む故障情報を判定することと、
前記故障情報に少なくとも部分的に基づき、前記制御環境内で実行されるワークフローを判定することであって、前記ワークフローは、前記監視構成要素が前記第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、前記データベース環境内で実行される１つ以上のタスクを含む、判定することと、
前記制御環境内で前記ワークフローを実行することと、を行わせる命令を含む、メモリデバイスと、を備える、システム。
【請求項１１】
前記ワークフローは、前記監視構成要素が最短期間に前記一次複製と通信することができない場合、前記二次インスタンス複製が前記一次複製と通信することができない場合、ならびに前記第１および第２のインスタンス複製が、前記一次複製の最新の既知の状態において共通のデータ世代識別子を有する場合、前記複製データベースインスタンスに対する新しい一次複製になるフェイルオーバー操作を前記二次インスタンス複製に実行させるタスクを含む、請求項１０に記載のシステム。
【請求項１２】
前記ワークフローは、前記監視構成要素が最短期間に前記二次複製と通信することができない場合、ならびに前記一次インスタンス複製が前記二次複製と通信することができない場合、前記複製データベースインスタンスに対する新しい二次インスタンス複製を生成する、二次インスタンス複製復旧プロセスを実行させるタスクを含む、請求項１０に記載のシステム。
【請求項１３】
前記ワークフローは、前記監視構成要素が最短期間に前記一次複製および前記二次複製のどちらともと通信することができない場合、前記一次および二次インスタンス複製が互いに通信することが可能である場合、ならびに前記一次および二次インスタンス複製が共通のデータ世代識別子を有する場合、フェイルオーバーまたは復旧操作を実行することなく、前記制御環境内のデータストアに情報を記憶するタスクを含む、請求項１０に記載のシステム。
【請求項１４】
前記第１および第２のインスタンス複製は、単一のデータゾーン内、別個の地理的な位置における別個のデータゾーン内、複数の地理的な位置にわたる単一のデータゾーン内、または単一の地理的な領域内の複数のデータゾーンにわたってプロビジョニングされる、請求項１０に記載のシステム。
【請求項１５】
ユーザは、前記ユーザが現在の一次インスタンス複製と通信することを可能にする別名を提供され、フェイルオーバー操作が、前記二次インスタンス複製を新しい現在の一次インスタンス複製にする場合を含む、請求項１０に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
ますます多くのアプリケーションおよびサービスが、インターネット等のネットワーク上で利用可能になるに従い、ますます多くのコンテンツ、アプリケーション、および／またはサービスプロバイダが、クラウドコンピューティング等の技術に方向転換している。クラウドコンピューティングは、一般的に、それらのサービスをサポートするために使用されるハードウェアおよび／またはソフトウェアが、どんなときでもサービスの必要性に適合するよう、動的に拡張可能であるウェブサービス等のサービスを介して、電子リソースへのアクセスを提供するアプローチである。ユーザまたは顧客は、典型的に、クラウドを介するリソースへのアクセスに対して賃借、賃貸、または別の方法で代金を支払い、したがって、これらのリソースへのアクセスを提供するハードウェアおよび／またはソフトウェアを購入および維持する必要はない。
【０００２】
クラウド内では様々なアプリケーションおよびリソースの態様を調整および管理することができる一方で、これらのアプリケーションおよびリソースが依存するデータ格納場所は、顧客または他のそのようなユーザによる同様の調整が可能ではないか、あるいは容易には管理されない。典型的に、データストレージのプロビジョニングおよび拡大縮小等のタスクを実行することは、単調な手作業であり、顧客は、データベース管理者（ＤＢＡ）が、その設定が有効であるかどうかを判定することができるようにする設定情報および必要条件を伴って、ＤＢＡまたは同様の専門家ユーザを提供しなければならない。さらに、顧客がデータベースインスタンスのためのパラメータを、動的および／または自動的に調整するか、あるいはデータ格納場所の他のそのような態様を管理するための、容易な手段はない。多くの場合において、データインスタンスは、バックアップおよび復旧機構を所定の位置に有するであろうが、これらの機構は、しばしば、単一の位置または領域内にあり、その結果その領域内の故障または停電に敏感に反応する。さらに、データインスタンスが故障した際、新しいインスタンスを生成し、適切なボリュームを新しいインスタンスに付け、そうでなければ故障から復旧するために必要なタスクを実行するためには、典型的に、数分かかる。
【図面の簡単な説明】
【０００３】
本開示に従った様々な実施形態が、図面に関連して説明される。
【０００４】
【図１】様々な実施形態が実装され得る環境を図示する図である。
【図２】様々な実施形態に従って、使用することができる、制御プレーンおよびデータプレーンの別個の例を図示する図である。
【図３】様々な実施形態に従って、使用することができる、複数の監視構成要素を利用する例を図示する図である。
【図４】一実施形態に従って、使用することができる、複数のデータゾーンにわたって、複製されたデータインスタンスを実行するための実装の例を図示する図である。
【図５】一実施形態に従って、一次複製のための状態遷移図の例を図示する図である。
【図６】一実施形態に従って、監視構成要素のための状態遷移図の例を図示する図である。
【図７】一実施形態に従って、使用することができる、フェイルオーバー操作を実行するためのプロセスの例を図示する図である。
【図８】一実施形態に従って、使用することができる、二次複製を復旧するためのプロセスの例を図示する図である。
【図９】一実施形態に従って、使用することができる、イベントプロセッサを管理するためのプロセスの例を図示する図である。
【図１０】一実施形態に従って、使用することができる、故障したイベントプロセッサに起因する再割り当ての例を図示する図である。
【図１１】一実施形態に従って、使用することができる、新しいイベントプロセッサを追加するためのプロセスの例を図示する図である。
【発明を実施するための形態】
【０００５】
本開示の様々な実施形態に従った、システムおよび方法は、前述および電子環境内のデータ記憶の態様を管理するための従来のアプローチの経験がある他の欠陥の、１つ以上を克服することができる。具体的には、様々な実施形態は、別個の制御環境、ならびにユーザがデータ環境の様々な態様を管理するおよび／または変えることを可能にするために使用され得る制御プレーン、またはデータプレーンを提供する。この「セルフサービス」機能性は、ウェブサービスの１セットを通じて提供され得、ユーザおよび制御プレーンが、仮想データベース管理者（ＤＢＡ）としてともに行動することを可能にする。ユーザまたは顧客は、例えば、複数の外部に可視的なアプリケーションプログラミングインターフェース（ＡＰＩ）のうちの１つを介して、制御プレーンへ要求を投入することができる。様々なＡＰＩは、データ環境内の関係データベース等のデータ格納場所に関する、特定の機能を実行するために使用することができる。ＡＰＩのうちの１つに受信された要求は、分析され、データストアもしくはデータ記憶インスタンスの、操作または構成上のパラメータを調整する動作のような、データプレーン内で実行される望ましい動作（１つまたは複数）を決定することができる。ワークフロー構成要素のような構成要素は、その動作のための適切なタスクを決定し、そのタスクを、適切な順序で実行させることができる。関係データベースの態様を調整するような、これらのタスクのうちの少なくとも１つは、典型的に、データ環境内で実行されるであろう。
【０００６】
特定の実施形態に従って、そのようなシステムは、データ環境内の複製されたデータインスタンスのプロビジョニングを提供することができる。プロビジョニングは、１つ以上の別個のデータゾーン、別個の地理的な位置等の中、またはその全域にわたってプロビジョニングされる一次および二次複製の１つ１つを用いて、一次／二次複製アプローチを利用することができる。データベース複製は、別個のデータインスタンス上で動作することができ、その複製にわたって共有されない専用ブロック記憶ボリュームに、それぞれ付けられる。
【０００７】
様々な実施形態において、複製は、サーバ間のブロックデバイスのコンテンツをミラーし、冗長システムの全域で同期的にデータを複製することができる、Ａｕｓｔｒｉａ、ＶｉｅｎｎａのＬｉｎｂｉｔ社からの分散複製型ブロックデバイス（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｒｅｐｌｉｃａｔｅｄ  Ｂｌｏｃｋ  Ｄｅｖｉｃｅ（ＤＲＢＤ（登録商標）））、またはＷａｓｈｉｎｇｔｏｎ、ＳｅａｔｔｌｅのＡｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．により提供されるエラスティックブロックストア（Ｅｌａｓｔｉｃ  Ｂｌｏｃｋ  Ｓｔｏｒｅ（ＥＢＳ））等のブロックレベル複製機構を使用して、実行することができる。各インスタンスは、データインスタンスのための全ての入力および出力（Ｉ／Ｏ）操作を管理するためにインストールされる、ブロックレベル複製機構（ＢＬＲＭ）カーネルモジュールを有するカーネルを、実行することができる。全ての読み込みおよび書き込みは、一次複製において、二次複製とともにその情報を同期的に複製する、ブロックレベル複製機構を用いて実行することができる。
【０００８】
一次および二次複製の両方は、外装のＤＮＳ名を有することができる。顧客は、ＤＮＳ＿一次（ＤＮＳ＿ｐｒｉｍａｒｙ）等のＤＮＳ名を使用して、現在の一次複製に到達することができる。ＤＮＳ＿一次（ＤＮＳ＿ｐｒｉｍａｒｙ）名は、別名を付けるか、あるいは（現在の）一次複製の外部ＤＮＳ名に対して、「ｃｎａｍｅ」を付けることができる。一次複製が故障するか、またはそうでなければ利用できない場合、二次複製は、新しい一次複製になるように昇格させるか、またはフェイルオーバーさせることができ、それによって、ＤＮＳ＿一次（ＤＮＳ＿ｐｒｉｍａｒｙ）のためのｃｎａｍｅは、新しい一次インスタンスのＤＮＳ名を更新することができる。全ての書き込みは、現在の一次複製上のデータベースに送信される。一次インスタンスが書き込みを受信する際、その情報は、二次複製へ同期的に書き込まれる。両方の場所において書き込みが成功すると、その書き込みは、成功したと判断され得る。全ての読み込みはまた、様々な実施形態内の一次複製においてのみ実行される。
【０００９】
データベース複製は、したがって、異なるデータゾーン内で動作するインスタンス複製を使用して、複数のデータインスタンスにわたってサポートされ得る。データベース書き込みは、複数のデータゾーン等を伴う大規模な停電のために全ての複製が利用できない場合を除いて、データが失われることがないように、ブロックレベルにおける同期複製機構を使用して、コミットすることができる。複製は、単一の複製故障が、データベースに対する長時間の停電を引き起こさないため、単一のデータベースインスタンスを使用して成し遂げられ得るよりも高い利用可能性を提供することができる。例えば、データベースの一次複製が停止している場合、様々な実施形態は、フェイルオーバー操作を実行することができ、それによって二次複製は、新しい一次複製を引き継ぐ。複製はまた、多くのインスタンス内の非複製データベースより高い耐久性を提供することができ、データゾーンの故障、データボリューム故障等から保護することができる。
【００１０】
図１は、様々な実施形態に従って態様を実装するための環境１００の例を図示する。明らかなように、ウェブベースの環境は説明の目的のために使用されるが、異なる環境は、様々な実施形態を実装するために必要に応じて使用してもよい。示される環境１００は、試験もしくは開発部分（または側面）および運用部分の両方を含む。運用部分は、適切なネットワーク１０４上の要求、メッセージ、または情報を送信および受信し、デバイスのユーザへ戻すよう情報を伝達するように操作可能なあらゆる適切なデバイスを含むことができる電子クライアントデバイス１０２を含む。そのようなクライアントデバイスの例は、パーソナルコンピュータ、携帯電話、ハンドヘルドメッセ−ジングデバイス、ラップトップコンピュータ、セットトップボックス、パーソナルデータアシスタント、および電子ブックリーダ等を含む。ネットワークは、イントラネット、インターネット、セルラーネットワーク、ローカルエリアネットワークもしくはそのようなその他のネットワーク、またはそれらの組み合わせを含むあらゆる適切なネットワークを含むことができる。そのようなシステムに使用される構成要素は、少なくとも部分的に選択されるネットワークおよび／または環境の種類によって決まり得る。そのようなネットワークを経由して通信するためのプロトコルおよび構成要素は、よく知られており、本明細書に詳細に記載されない。ネットワーク上の通信は、有線のまたは無線の接続、およびそれらの組み合わせによって可能にされ得る。この例において、ネットワークは、その環境が要求を受信し、それに応答してコンテンツを供給するためのウェブサーバ１０６を含むため、インターネットを含むが、その他のネットワークのために同様の目的に対応する代替のデバイスが当業者に明らかであるように使用され得る。
【００１１】
例示的な環境は、少なくとも１つのアプリケーションサーバ１０８およびデータストア１１０を含む。鎖状にされるあるいは別の方法で構成することができ、適切なデータストアからデータを取得すること等のタスクを実行するよう相互に作用することができる、複数のアプリケーションサーバ、層、もしくは他の要素、プロセス、または構成要素が存在することを理解されたい。本明細書に使用される「データストア」という用語は、任意のデバイスまたは記憶、アクセス、およびデータの読み出しが可能であるデバイスの組み合わせを指し、任意の標準、分散型、またはクラスタ化された環境内のデータサーバ、データベース、データ記憶デバイス、ならびにデータ記憶媒体のあらゆる組み合わせおよび数を含んでもよい。アプリケーションサーバは、クライアントデバイスのための１つ以上のアプリケーションの態様を実行する必要に応じて、データストアと統合し、アプリケーションのためのデータアクセスおよびビジネスロジックの大部分を取り扱うためのあらゆる適切なハードウェアおよびソフトウェアを含むことができる。アプリケーションサーバは、データストアと連携してアクセス制御サービスを提供し、ユーザへ転送されるテキスト、グラフィック、オーディオ、および／またはビデオ等のコンテンツを生成することが可能であり、この例におけるＨＴＭＬ、ＸＭＬ、または別の適切な構造化言語の形態のウェブサーバによってユーザへ供給されてもよい。全ての要求および応答の取り扱いならびにクライアントデバイス１０２とアプリケーションサーバ１０８との間のコンテンツの送達は、ウェブサーバによって処理することができる。ウェブおよびアプリケーションサーバは、本明細書に記載される構造化コードが本明細書の他の箇所に記載されるようなあらゆる適切なデバイスまたはホストマシン上で実行され得るため、必要とされず、ただ単に例となる構成要素であることを理解されたい。さらに、環境は、試験自動化フレームワークがユーザまたはアプリケーションが申し込むことができるサービスとして提供され得るそのような手段において設計することができる。試験自動化フレームワークは、本明細書に記載される様々な試験パターンのうちのいずれかの実装として提供され得るが、本明細書に記載されるかまたは推奨されるように、様々な他の実装も同様に使用され得る。
【００１２】
環境はまた、開発者、データ管理者、または試験者等のユーザにシステムにアクセスすることを可能にするユーザデバイス１１８を含む開発および／または試験の側面を含む。ユーザデバイス１１８は、クライアントデバイス１０２に関して、上述されたいずれかの適切なデバイスまたは機械であり得る。環境はまた、アプリケーションサーバ１０８に類似して機能する開発サーバ１２０を含むが、例えば、運用側面上でコードが展開され、実行される前の開発および試験の間、典型的にコードを実行し、外部のユーザへアクセス可能である。いくつかの実施形態において、アプリケーションサーバは、開発サーバとして機能することができ、別個の運用および試験記憶装置は使用されなくてもよい。
【００１３】
データストア１１０は、複数の別個のデータテーブル、データベース、または特定の態様に関連するデータを記憶するための他のデータ記憶機構および媒体を含むことができる。例えば、図示されるデータストアは、運用データ１１２およびユーザ情報１１６を記憶するための機構を含み、運用側面のためのコンテンツを供給するために使用することができる。データストアはまた、試験データ１１４を記憶するための機構を含むよう示され、試験側面のためのユーザ情報とともに使用され得る。それらは、ページ画像情報およびアクセス権情報のための態様のようなデータストア内に記憶されることを必要とする場合がある多くの他の態様であり得、データストア１１０内の適切または追加的な機構として上記に列挙された機構のいずれかの中に記憶され得ることを理解されたい。データストア１１０は、操作可能であり、それとともに関連付けられるロジックを介してアプリケーションサーバ１０８または開発サーバ１２０から命令を受信し、それを取得、更新、またはそうでなければそのことに応答してデータを処理する。一例において、ユーザは、特定の種類の項目の検索要求を投入する場合がある。この場合、データストアは、ユーザの同一性を検証するためのユーザ情報にアクセスしてもよく、その種類の項目についての情報を取得するためのカタログ詳細情報にアクセスすることができる。次いでその情報は、ユーザユーザデバイス１０２上のブラウザを経由して見ることが可能であるウェブページ上に列挙する結果等のユーザへ返却され得る。該当の特定の項目のための情報は、専用ページまたはブラウザのウィンドウ内において見ることができる。
【００１４】
各サーバは、一般管理およびそのサーバの操作のための実行可能なプログラム命令を提供するオペレーティングシステムを典型的に含み、命令を記憶するコンピュータ可読媒体を典型的に含み、サーバのプロセッサによって実行される際、サーバにその意図される機能を実行することを可能にする。サーバのオペレーティングシステムおよび一般的な機能性に適している実装は、既知であるかまたは商業化が可能であり、特に本明細書の開示を踏まえると当業者によって容易に実装される。
【００１５】
一実施形態における環境は、１つ以上のコンピュータネットワークまたは直接接続を使用し、通信リンクを経由して相互接続される複数のコンピュータシステムおよび構成要素を利用する分散型のコンピューティング環境である。しかしながら、そのようなシステムが、図１に図示されるより少ないまたは多い構成要素の数を有するシステムにおいて、同様に良好な操作ができることは、当業者によって明らかになるであろう。したがって、図１のシステム１００の描写は、例示的な性質があり、本開示の範囲に限定されないと理解されたい。
【００１６】
図１に図示されるような環境は、電子マーケット等のプロバイダに有用であり得、複数のホストが、コンテンツを供給すること、ユーザを認証すること、支払いトランザクションを実行すること、または複数のその他のタスクのいずれかを実行すること等のタスクを実行するために使用されてもよい。これらのホストのいくつかは、同一の機能性を提示するよう構成されてもよく、一方で他のサーバは、少なくともいくつかの異なる機能を実行するよう構成されてもよい。その場合、電子環境は、追加的な構成要素および／または以下に詳細に記載される図２の構成２００に図示されるそれらのような他の配置を含んでもよい。
【００１７】
一実施形態に従ってシステムおよび方法は、開発者、顧客、または他の認定ユーザが、関係データベースおよびその他のデータソースを容易かつコスト効率よく取得および構成することを可能にし、ユーザがクラウド内の関係データセットを記憶すること、処理すること、および問い合わせすること等のタスクを実行することができるようにする関係データベースサービス（「ＲＤＳ」）を提供する。この例がインターネット、ウェブサービス、およびインターネットベースの技術に関して説明される一方で、様々な実施形態の態様は、利用可能なあらゆる適切なサービスとともに使用されるか、あるいは電子環境内のネットワーク上で提示され得ると理解されたい。さらに、サービスが本明細書に「関係データベースサービス」として称される一方で、そのようなサービスは、データ格納場所のあらゆる適切な種類または電子環境内のデータ記憶とともに使用され得ると理解されたい。この例におけるＲＤＳは、少なくとも１つのウェブサービスを含み、それはユーザまたは顧客が、展開、アップグレード、パッチ管理、バックアップ、複製、フェイルオーバー、容量管理、拡大縮小、および他のデータ管理のそのような態様の管理上の複雑性を心配することなく、関係データセットを容易に管理することを可能にする。開発者は、したがって、データベース基礎構造を管理することの複雑性を心配することなしに、洗練されたクラウドアプリケーションを開発するよう解放される。
【００１８】
一実施形態におけるＲＤＳは、別個の「制御プレーン」を提供し、それはデータ記憶の態様を管理するために有用な構成要素（例えば、ハードウェアおよびソフトウェア）を含む。一実施形態において、データ管理アプリケーションプログラミングインターフェース（ＡＰＩ）の１セットまたは他のそのようなインターフェースは、ユーザまたは顧客がデータ記憶に関連する特定のタスクを実行するよう、コールをＲＤＳにすることを可能にすることを提供される。ユーザは、依然、データ格納場所と通信するためにダイレクトインターフェースまたはＡＰＩを使用することができるが、しかしながら、データ記憶を管理するか、または同様のタスクを実行する必要がある場合にのみ、制御プレーンのＲＤＳ特定ＡＰＩを使用することもできる。
【００１９】
図２は、ＲＤＳ実装２００の例を図示し、一実施形態に従って使用することができる。この例において、エンドユーザのためのコンピューティングデバイス２０２は、ネットワーク２０６を介して、コールを制御プレーン２０８にできるように示され、データプレーン２１０のデータ格納場所をプロビジョニングする等のタスクを実行する。ユーザまたはアプリケーション２０４は、プロビジョニングされた格納場所に直接的にデータプレーン２１０のインターフェースを介してアクセスすることができる。エンドユーザコンピューティングデバイスおよびアプリケーションが、説明の目的に使用される一方で、任意の適切なユーザ、アプリケーション、サービス、デバイス、構成要素、またはリソースは、様々な実施形態において必要である制御プレーンおよび／またはデータプレーンのインターフェース（１つまたは複数）にアクセスすることができることを理解されたい。さらに、構成要素は制御およびデータ「プレーン」に分けられるが、これは、それぞれの機能性を提供するために使用される、少なくともいくつかのリソース（例えば、ハードウェアおよび／またはソフトウェア）の現実または仮想の分離を指すことができると理解されたい。
【００２０】
この例における制御プレーン２０８は、本質的にハードウェアの仮想層およびソフトウェア構成要素であり、それは、プロビジョニング、拡大縮小、複製等のような制御および管理動作を処理する。この実施形態における制御プレーンは、ウェブサービス層２１２または階層を含み、それらは少なくとも１つのウェブサーバ、例えば、コンピュータ実行可能なソフトウェア、アプリケーションサーバ、または他のそのような構成要素とともに含むことができる。ウェブサービス層はまた、ウェブサービスコールまたは要求をネットワーク２０６内から受信するために、ＡＰＩ２３２（または他のそのようなインターフェース）の１セットを含むこともできる。各ＡＰＩは、関係データベースのインスタンスをプロビジョニングする、拡大縮小する、クローン化する、または休止状態にする等のデータ環境に関連して実行される少なくとも１つの特定の動作の要求を受信するために提供され得る。ＡＰＩのうちの１つに対する要求を受信する上で、ウェブサービス層は、コールに従って動作するか、あるいはそのコールを処理する必要があるステップまたは動作を決定する要求を解析するか、または別の方法で分析することができる。例えば、ウェブサービスコールは、受信されてもよく、データ格納場所を作成する要求を含む。この例において、ウェブサービス層は、作られるデータ格納場所の種類、要求される記憶ボリューム、（もしあるとしたら）要求されるハードウェアの種類、または他のそのような態様を決定する要求を解析することができる。その要求のための情報は、後続の処理のために、ネットワーク管理組織（「Ａｄｍｉｎ」）データストア２２２、または他の適切な記憶場所もしくはジョブ待ち行列へ書き込まれ得る。
【００２１】
一実施形態におけるウェブサービス層は、様々な制御プレーンＡＰＩを提供し、ＡＰＩ仕様書に基づいて適切な応答を返却することができ、顧客対応サーバの拡張可能なセットを含む。ウェブサービス層はまた、少なくとも１つのＡＰＩサービス層を提供することができ、それは一実施形態において、外装の顧客ＡＰＩを処理する処理状態を把握しないかつ複製されたサーバで構成される。ウェブサービス層は、認証情報に基づいて顧客を認証すること、顧客に権限を与えること、ＡＰＩサーバに対する顧客要求を調整すること、ユーザ入力を有効にすること、ならびに要求および応答を整理または無秩序化すること等、ウェブサービスのフロントエンド特徴に関与することができる。ＡＰＩ層はまた、ＡＰＩコールに応答して、データベース構成データをネットワーク管理組織データストアへ／ネットワーク管理組織データストアから読み込むこと、および書き込むことに関与することができる。多くの実施形態において、ウェブサービス層および／またはＡＰＩサービス層は、ただ１つの外部に可視的な構成要素になるか、あるいは制御サービスの顧客に対して可視的、かつ制御サービスの顧客によってアクセス可能であるただ１つの構成要素となるであろう。ウェブサービス層のサーバは、処理状態を把握しなくなり得、当技術分野において知られるように水平方向に拡大縮小することができる。ＡＰＩサーバおよび永続的なデータストアは、地理的な領域内または地理的な位置の近くにある複数のデータセンタにわたって広がることができ、例えば、サーバは、単一のデータセンタ故障に対する回復力に富むようになる。
【００２２】
この実施形態における制御プレーンは、「スイーパ」構成要素２１４として本明細書に称されることを含む。スイーパ構成要素は、制御プレーンの様々な構成要素をポーリングするか、またはそうでなければ未処理の要求に応答して実行される任意のタスクを判定するよう操作可能な、あらゆる適切な構成要素であってもよい。この例において、ウェブサービス層は、ネットワーク管理組織データストア２２２内の「データベース作成」要求のための命令もしくは情報、または類似するジョブ待ち行列を配置してもよく、スイーパは、未処理のジョブのためのネットワーク管理組織データストアを定期的にチェックすることができる。様々な他のアプローチは、ジョブが存在という通知をスイーパへ送信するウェブサービス層のように、当業者に明らかになるよう使用することができる。スイーパ構成要素は、「データベース作成」要求を拾得し、その要求のための情報を使用することによって、要求のための少なくとも１つのワークフローのインスタンスを生成するよう操作可能であるワークフロー構成要素２１６に対し、要求、コール、または他のそのようなコマンドを送信することができる。一実施形態におけるワークフローは、本明細書の他の箇所で説明されるワークフローサービスを使用して、生成および維持される。ワークフローは、一般的にはタスクのシーケンスであり、特定のジョブを行うよう実行されるべきである。ワークフローは、実際の動作ではないが、情報の流れおよび動作の実行を制御する動作の抽象である。ワークフローはまた、実行の間のどの時点においてもプロセスの状態を管理し返却し得る状態機械と考えることができる。一実施形態におけるワークフロー構成要素（または構成要素のシステム）は、格納場所の作成、変更、および削除；復旧およびバックアップ；セキュリティグループの作成、削除、および変更；ユーザ認証情報管理；ならびに鍵ローテーションおよび認証情報管理等のタスクのためのワークフローのホスティングおよび実行を、管理および／または実行するよう操作可能である。そのようなワークフローは、本明細書の他の箇所に説明されるワークフローサービスの上部に実装することができる。ワークフロー構成要素はまた、根本的なワークフローサービスが変化する必要がないため、ＭｙＳＱＬのような異なるデータベースエンジンに使用されるワークフローステップ間の差異を管理することもできる。
【００２３】
この例において、ワークフローは、データベースを作成し、最初の要求から抽出された情報を適用するために、ワークフローテンプレートを使用してインスタンスを生成することができる。例えば、要求が、Ｏｒａｃｌｅ（登録商標）のＲＤＢＭＳまたは他のそのようなインスタンスとは対照的に、ＭｙＳＱＬ（登録商標）の関係データベース管理システム（ＲＤＢＭＳ）のインスタンスのためのものである場合、特定のタスクは、ワークフローに追加され、ＭｙＳＱＬインスタンスに向けられる。ワークフロー構成要素はまた、要求された記憶量、いずれの特定のハードウェア要件、または他のそのようなタスクに関連する特定のタスクを選択することもできる。これらのタスクは、全般的なジョブに有用である実行の順でワークフローに追加することができる。いくつかのタスクは、並行して実行することができるが、前のタスクに依存する他のタスクは、最初に完了される。ワークフロー構成要素またはサービスは、ワークフロー内のこの情報を含むことができ、必要に応じてそのタスクは実行され、その情報は渡され得る。
【００２４】
顧客のための「データベース作成」ワークフローの例は、データストアインスタンスをプロビジョニングすること、オフインスタンス永続記憶装置のボリュームを割り当てること、データストアインスタンスへ永続記憶装置ボリュームを付けること、次いでＤＮＳアドレス、あるいは顧客がデータインスタンスへアクセスするか、または別の方法で接続するために使用することができる他のアドレス、ポート、インターフェース、もしくは識別子を割り当てること、ならびにそれらを付けること等のタスクを含んでもよい。この例において、ユーザは、インスタンスにアクセスするために使用される、ＤＮＳアドレスおよびポートアドレスを提供される。ワークフローはまた、特定のデータ記憶技術（例えば、ＭｙＳＱＬ）に使用される、あらゆるバイナリまたは他の情報をダウンロードおよびインストールするタスクを含むことができる。ワークフロー構成要素は、これらのタスクおよびあらゆる関連するタスク、またはそのようなタスクのその他適切な組み合わせの実行を管理することができ、実際にデータプレーン２１０内のデータストアインスタンスに対応する「データベース作成」要求に応答して、「データベース」の作成を示す要求に対する応答を生成することができ、インスタンスにアクセスするために使用されるＤＮＳアドレスを提供する。次いで、ユーザは、ＤＮＳアドレスおよびポートを直接使用して、アクセスまたは制御プレーン２０８を通過する必要なしに、データストアインスタンスにアクセスすることができる。様々な他のワークフローテンプレートは、ストレージを増やす等のためのさらなるデータストアインスタンスのうちの１つを削除、作成、または修正するような同様のジョブを実行するために使用することができる。いくつかの実施形態において、ワークフロー情報は、ストレージへ書き込まれ、少なくとも１つの別個の実行構成要素（示されない）は、ワークフロー情報に基づいて実行されるタスクを引き出すか、あるいはそうでなければ、タスクにアクセスするか、またはタスクを受信する。例えば、プロビジョニングタスクを実行する専用プロビジョニング構成要素があってもよく、この構成要素は、ワークフロー構成要素によってコールされなくてもよいが、タスク待ち行列を監視することができるか、あるいは明らかであるべき多数の関連する手段のいずれかで、プロビジョニングタスクのための情報を受信することができる。
【００２５】
上述のように、様々な実施形態は、格納場所のプロビジョニング等のプロセスもしくはタスクにおける、現在の状態の要求またはコールを受信することができるワークフローサービスを活用することができ、プロセスの現在の状態を返却することができる。ワークフロー構成要素および／またはワークフローサービスは、各タスクを実行するための実際のコールもしくは要求を作成しないが、それらは、代わりに制御プレーンの構成要素が実行される次のタスクを決定することを可能にするワークフローのための状態および設定情報を管理し、そのタスクに必要なあらゆる情報は、次いでその状態情報を含むデータプレーンに適切なコール（１つまたは複数）を生成し、それによって、データプレーンの構成要素は、タスクを実行するコールを作成することができる。ワークフローおよびタスクは、スループットを上げ、リソースの処理を最大化するために、並行して予定を決めることができる。記載されるように、タスクの実際の実行は、データプレーン内で起こるであろうが、そのタスクは、制御プレーンから由来するであろう。例えば、ワークフロー構成要素は、コールをデータストアにすることができるホストマネージャと通信することができる。したがって、与えられたタスクに対し、コールは、特定のパラメータを渡すワークフローサービスに作成することができ、それによってワークフローサービスは、現在の状態のためのタスクが実行され得るように、ワークフローのためのタスクのシーケンスを生成し、現在の状態を提供する。タスクが実行された（あるいはそうでなければ、決断された、または結論を出された）後、ホストマネージャ等の構成要素は、ワークフロー内の次の状態についての情報を次いで提供することができるサービスへ応答することができ、次のタスクが実行され得るようになる。ワークフローのためのタスクのうちの１つが実行される毎に、そのサービスは、ワークフローが完了されるまで実行する新しいタスクを提供することができる。さらに、複数のスレッドは、異なるワークフローに対して並行して動作することができ、ワークフローの処理を加速させることができる。
【００２６】
この実施形態における制御プレーン２０８はまた、少なくとも１つの監視構成要素２１８を含む。データインスタンスがデータプレーン内に作成される際、そのインスタンスのための情報は、監視データストア２２０等の制御プレーン内のデータストアに書き込むことができる。監視データストアは、別個のデータストアであり得るか、またはネットワーク管理組織（Ａｄｍｉｎ）データストア２２２内のテーブルのはっきりと異なるセット（ｄｉｓｔｉｎｃｔ  ｓｅｔ）等の別のデータストアの一部分、もしくは他の適切な格納場所であり得ることを理解されたい。監視構成要素は、データプレーン２１０内のアクティブインスタンス２３４を判定する監視データストア内の情報にアクセスすることができる。監視構成要素はまた、ウェブサービス層、ワークフロー構成要素、スイーパ構成要素、および様々なホストマネージャ等の制御プレーンおよび／またはデータプレーンの複数の構成要素から、ログおよび／またはイベント情報を収集するような他のタスクを実行することもできる。そのようなイベント情報を使用して、監視構成要素は、顧客対応ＡＰＩを実装する等の目的のために、顧客可視イベントを映すことができる。監視構成要素は、制御プレーンのために全ての動作している収納場所および／またはインスタンスの健康状態を絶えず監視し、これらのインスタンスのいずれかの故障を検出し、適切な復旧プロセス（１つまたは複数）を開始することができる。
【００２７】
データプレーン内の各インスタンス２３４は、データストアへのアクセスを提供するする機械のために、少なくとも１つのデータストア２２６およびホストマネージャ構成要素２２８を含むことができる。一実施形態におけるホストマネージャは、ソフトウェア開発およびデータストア操作等のタスクを管理するようプログラム化された、インスタンスおよび／またはＴｏｍｃａｔもしくはＪａｖａアプリケーションサーバ等のアプリケーションサーバ上で実行し、同様にデータストアおよび／またはそれぞれのインスタンスの状態を監視するアプリケーションまたはソフトウェアエージェントである。一実施形態におけるホストマネージャは、内部システム構成要素からのみ到達され得るポート上で確認し、顧客または他の外部の実体に対し利用可能ではない。いくつかの実施形態において、ホストマネージャは、いかなるコールも制御プレーン層へ伝えることができない。ホストマネージャは、新しい格納場所のためのインスタンスをセットアップする等のタスクを管理および／または実行すること、論理的なボリュームおよびファイルシステムのセットアップを含むこと、データベースバイナリおよびシードをインストールすること、ならびに格納場所を始動するか、または終了することに関与することができる。ホストマネージャは、データストアの健康状態を監視することができ、同様にＩ／Ｏエラーまたはデータ記憶エラー等のエラー状態のためにデータストアを監視し、必要であればデータストアを再始動することができる。ホストマネージャはまた、データストアおよび／またはオペレーティングシステムのためのソフトウェアパッチおよびアップグレード版のインストールを、実行および／または管理する。ホストマネージャはまた、ＣＰＵ、メモリ、およびＩ／Ｏの使用に関係する可能性がある関連メトリクスを収集することもできる。
【００２８】
監視構成要素は、各ホストのステータスを判定するために、特定の要求を送信することによって、あるいはホストマネージャからハートビートを監視することによるように監視されたインスタンス２３４に対し、各ホストマネージャ２２８と定期的に通信することができる。一実施形態において、監視構成要素は、特定のホストおよび／またはインスタンスのステータスを得るため等の各ホストマネージャへコマンドを発行するよう構成されたイベントプロセッサ（または監視サーバ）の１セットを含む。応答が指定回数の再施行の後に受信されない場合、監視構成要素は、問題があると判定することができ、ネットワーク管理組織（Ａｄｍｉｎ）データストア２２２または別のそのようなジョブ待ち行列内へ情報を記憶し、問題を検証し、必要であればそのインスタンスを再プロビジョニングするため等のインスタンスのための動作を実行することができる。スイーパは、この情報にアクセスし、故障から自動的に復旧するように試みるよう、そのインスタンスのための復旧ワークフローを始動することができる。ホストマネージャ２２８は、監視するためのプロキシおよび制御プレーンの他の構成要素として動作することができ、制御プレーン構成要素の代わりとして、そのインスタンスのためのタスクを実行する。しばしば、対応するホスト、インスタンス、またはボリュームがクラッシュすること、再起動すること、再始動すること等のような、インスタンスのうちの１つに関連する問題が起こり、それらは自動的に解決することができない。一実施形態において、ロギング構成要素（示されない）があり、これらおよび他の顧客可視性イベントのログを記録することができる。ロギング構成要素は、インスタンスが一定の期間利用できない場合、顧客がそのイベントに関して情報を得るために適切な「イベント」または類似するＡＰＩをコールすることができるように、ＡＰＩまたは他のそのようなインターフェースを含むことができる。ある場合に、要求は、インスタンスが故障した際、未処理のまま残されてもよい。この実施形態における制御プレーンがデータプレーンから分離されるため、制御プレーンがデータ要求を受信することはなく、したがって、後続の投入の要求を、待ち行列に入れることはできない（ただし、いくつかの実施形態において、この情報は制御プレーンへ転送することができる）。したがって、この実施形態における制御プレーンは、故障に関してユーザへ情報を提供するため、ユーザは、必要に応じてその要求を処理することができる。
【００２９】
記載されるように、インスタンスがプロビジョニングされ、ユーザがＤＮＳアドレスまたは他のアドレスもしくは位置を提供された時点において、そのユーザは、Ｊａｖａデータベース接続性（Ｊａｖａ  Ｄａｔａｂａｓｅ  Ｃｏｎｎｅｃｔｉｖｉｔｙ）（ＪＤＢＣ）または他のそのようなクライアントを使用して、データプレーン２１０へ、ネットワークを介して「直接的に」要求を送信し、インスタンス２３４と直接情報をやり取りするこができる。一実施形態において、データプレーンは、コンピューティングクラウド環境の形態をとるか（または、少なくともそれを含むか、もしくはその一部である）、あるいはデータ記憶および「クラウド」にわたるアクセス、またはハードウェアおよび／またはソフトウェア構成要素の動的なネットワークを提供するウェブサービスおよびリソースの１セットである。ＤＮＳアドレスは、そのような動的なクラウド環境内において有益であり、それは、インスタンスまたは利用可能性の故障として、例えば、ＤＮＳアドレスを使用に適している任意の置換インスタンスへプログラムで再マップすることにより、マスクされ得る。ユーザ２０２またはアプリケーション２０４から受信した要求は、例えば、ネットワークアドレス変換（ＮＡＴ）ルータ２２４、または要求を実際のインスタンス２３４もしくはその要求のＤＮＳに対応するホストへ向けることができる他の適切な構成要素に向けることができる。記載されるように、そのようなアプローチは、ユーザまたはアプリケーションがインスタンスにアクセスするために使用されるＤＮＳまたは他のアドレスを変更することを要求することなしに、インスタンスが動的に移動、更新、複製されること等を可能にさせる。記載されるように、各インスタンス２３４は、ホストマネージャ２２８およびデータストア２２６を含むことができ、永続記憶装置２３０内の少なくとも１つのバックアップインスタンスまたはコピーを有することができる。そのようなアプローチを使用して、インスタンスが制御プレーンを介して構成された時点で、ユーザ、アプリケーション、サービス、または構成要素は、データプレーンに対する要求を直接通じて、制御プレーン２３２にアクセスする必要なしに、インスタンスと情報をやり取りすることができる。例えば、ユーザは、構造化問い合わせ言語（ＳＱＬ）またはインスタンス内のデータに関連する他のそのようなコマンドを、ＤＮＳアドレスを介して、直接発行することができる。ユーザがインスタンスの記憶容量を拡大する等のタスクを実行したい場合、ユーザは、制御プレーンにさえアクセスすればよい。少なくとも一実施形態において、制御プレーン２０８の機能性は、少なくとも１つのサービスとして、プロバイダによって提示することができ、データプレーン２１０のプロバイダに関連してもよく、あるいは関連しなくてもよいが、単にデータプレーン内のデータインスタンスをプロビジョニングし管理するために使用することができるサードパーティーサービスであってもよく、さらに別個のデータプレーン２１０内におけるそれらのインスタンスの利用可能性を監視し、確実にすることができる。
【００３０】
記載されるように、ウェブサービスまたは他のそのようなサービスとして制御プレーンの機能性を提示する１つの利点は、制御プレーンが仮想データベース管理者（ＤＢＡ）として機能し、人間のＤＢＡがデータをプロビジョニングする等のタスクを実行する必要性を回避することである。データをプロビジョニングすることは、現在、単調な手作業であり、ＤＢＡが必要な設定情報を受け取ることを必要とし、構成が有効であるかどうかを判定し、インスタンスを最適化および整調し、相当量の時間および労力をとる他の同様のタスクを実行する。さらに、そのようなアプローチは、エラーとなる多くの機会をもたらし、データが失われる後になるまで発見されない可能性がある。本明細書に記載される制御プレーンまたはサービスを使用して、ユーザまたは顧客は、ハードウェアの種類およびデータベース製品のバージョン等の情報を含むコールを、代わりに投入することができる。次いで、制御プレーンまたはサービスは、データストアまたはデータ記憶インスタンスを作成、削除、修正、拡大、あるいはそうでなければ修正するために必要なタスクを実行する。制御プレーンはまた、ＤＢＡに各エンジンにおける専門家になることを要求することなしに、一貫した方法で複数の異なるデータベースエンジンをサポートすることもできる。プロビジョニングされた時点で、ユーザは、データインスタンス（１つまたは複数）へのネイティブアクセスを有し、既存のアプリケーション（ＭｙＳＱＬアプリケーション等）がＤＮＳアドレスまたは特定のインスタンスのための他の位置情報を単に指すことができる。クエリモデルの制約もしくは変更または他のそのような機能性はないため、ユーザは、ＭｙＳＱＬ、Ｏｒａｃｌｅ、または他のデータベース技術に基づいて作られたアプリケーションを使用し続けることができる。
【００３１】
図３は、一実施形態に従って、単一または複製のどちらか一方で、監視およびＲＤＳインスタンスのオートメーション化された復旧等の目的に使用され得る構成３００の例を図示する。参照番号が、単純かつ明瞭にする目的のために図と図の間で繰り返されるが、これらはただ単に類似する構成要素を表し、様々な実施形態に使用することができ、様々な他の実施形態からの構成要素を必要とするか、あるいはただ単に単一の実施形態の異なる見方を示すものであるように解釈されるべきではないことを理解されたい。さらに、少数または追加的な構成要素は、様々な実施形態において使用され得、規定の図中における構成要素の存在または欠如は、その他に具体的に記載されない限り、構成要素が与えられた実施形態において必要とされるか、あるいは有用ではないと解釈されるべきではない。実施形態と図との間の変形は、本開示を踏まえて当業者に明らかであるべきである。
【００３２】
図に図示されるように、制御プレーンの監視構成要素（またはサービス）２１８は、一連の処理ノード３０２を備えることができ、本明細書にイベントプロセッサと称される。一実施形態において、イベントプロセッサは、データプレーンの態様を監視するよう操作可能である監視サーバのフリートを備える。各イベントプロセッサは、関連付けられたホストマネージャ２２８を介して、特定されるセットまたは範囲のデータストア２２６および／またはデータインスタンス２３４と通信するよう構成することができる。記載されるように、各データストアおよびホストマネージャは、データプレーン２１０のノードもしくは機械またはデータ環境上に存在することができる。イベントプロセッサのそれぞれは、任意の適切な通信技法を使用して、割り当てられたホストマネージャと通信し、「ステータス取得（ｇｅｔＳｔａｔｕｓ）」要求等の安全な（例えば、ＨＴＴＰＳ）要求を使用して各ホストマネージャへピングを打つこと等によって、各ホストから現在のステータスを取得することができる。その要求に応答して、各ホストマネージャは、ホストマネージャ２２８に関連する問題があるか、またはホストマネージャ２２８によって検出されたかどうか等の情報、およびあらゆる関連のあるメトリクス、パラメータ値、または関連すると判定するその診断に関する情報を含む応答を送信することができる。特定の実施形態において、ホストマネージャにより返却される情報の量および種類は、ホストマネージャの状態に基づいて変形することができる。例えば、検出されたエラーがない場合、ホストマネージャは、ログを記憶されるか、またはそうでなければ処理される特定されたメトリクスの標準セットを送信してもよい。問題が検出された場合、例えば、情報の異なるセットは、問題の種類を示す情報、および問題の種類に関連する診断または他の情報等が含まれてもよい。様々なアルゴリズムは、そのような判定をするために、ホストマネージャへ提供することができる。ホストマネージャから情報を受信すると、イベントプロセッサは、必要に応じてその情報を分析し、その情報を監視データストア２２０または他のそのような位置内に記憶することができる。イベントプロセッサはまた、本明細書の他の箇所に説明されるあらゆるログ情報を監視データストア内に記憶することもできる。この例に図示されるように、監視データストア２２０は、単一の論理的なデータストアになり得るが、多くのデータインスタンス３０４にわたって分割することができる。
【００３３】
監視構成要素２１８の一部として複数のイベントプロセッサ３０２を使用することは、多くの利点となることができる。そのような一利点は、データプレーン内の多数のデータインスタンス２３４に対し、単一のイベントプロセッサが、各インスタンスを同時に監視するために十分な容量を有しなくてもよいことである。複数のイベントプロセッサを利用することは、監視動作が複数のイベントプロセッサにわたって分散されることを可能にする。さらに、複数のイベントプロセッサを使用することは、既存のイベントプロセッサに故障または他のそのような問題の場合に、別のイベントプロセッサの動作を引き受けさせることを可能にする。データインスタンスが単一のイベントプロセッサによってのみ管理され、イベントプロセッサを利用できなくするプロセッサに関する問題が存在する場合、データインスタンスは、実行されたいかなる監視も有しない場合があり、したがって停電または他のそのような問題の危険を冒す可能性がある。イベントプロセッサの１セットにわたって監視を広げることにより、各イベントプロセッサによる監視の範囲を動的に更新することを可能にし、制御プレーンは、イベントプロセッサのうちの１つ以上の故障の場合でさえも、データプレーン内の各インスタンスが実質的にいつでも監視されることを確実にすることができる。
【００３４】
一実施形態において、各イベントプロセッサの役割は、どんなときでも監視されるインスタンス（複製を含む）の数をとり、イベントプロセッサの数にわたってインスタンスの数を分配することによって決定される。例えば、データプレーン内で監視される２５，０００個のインスタンスがあり、制御プレーン内で動作している５つのイベントプロセッサがある場合、各イベントプロセッサは、およそ５，０００個のデータインスタンスを監視する役割を与えられ得る。各インスタンスが識別子を与えられる場合、例えば、各イベントプロセッサは、識別子の範囲（第１の５，０００個の識別子、第２の５，０００個の識別子等のような）を与えられ、２５，０００個のインスタンスのそれぞれのためのマッピング情報を管理しなければならないことよりも、むしろ各イベントプロセッサの役割を調整することを容易にすることができる。図中の例は、そのような例におけるイベントプロセッサのそれぞれの役割の範囲を示す。
【００３５】
１分に１回のような適切な間隔において、各イベントプロセッサ３０２は、イベントプロセッサによって監視されている各ホストマネージャ２２８へ要求を送信することができる。一実施形態におけるイベントプロセッサは、制御プレーンのＴｏｍｃａｔコンテナ内で動作しているＪａｖａアプリケーションであり、データプレーン内のデータインスタンスのために、ホストマネージャへ定期的にポーリングを行う。イベントプロセッサは、一実施形態におけるホストマネージャに、ＤＮＳ名およびホストマネージャポートを使用してステータス取得（ｇｅｔＳｔａｔｕｓ（））または類似するコール（例えば、ＳＳＬ上で）を作成することにより、ポーリングを行うことができる。いくつかの実施形態において、監視されているデータインスタンスは、顧客データストア識別子、データストア識別子、およびインスタンス識別子の組み合わせによって、一意的に識別される。そのようなアプローチを使用して、古いおよび新しいインスタンスの状態は、データインスタンスをクラウド内の別のインスタンスへ移動する際に、識別することができる。イベントプロセッサは、データインスタンスの状態を、ホストマネージャからの応答に基づいて、判定することができる。一実施形態におけるデータインスタンスは、少なくとも次の状態例：「ＯＫ」（データインスタンスが適正に動作している）、「隔離された」（データインスタンスが故障の疑わしい状態にある）、または「停止」（データインスタンスが到達不可能でありステータスの要求に応答しない）のうちの１つであり得る。
【００３６】
ほとんどの場合、ホストマネージャは、そのホストマネージャ、関連付けられたインスタンス等が予想通りに動作していることを示す応答を返却し、イベントプロセッサは、監視データストア２２０内の情報を更新することができる。イベントプロセッサは、「ＯＫ」、またはホストマネージャがＨＴＴＰ応答コード「２００」（成功したＨＴＴＰ要求の標準応答コード）等の適切な応答を返却する際の一実施形態における類似する状態にあるデータインスタンスを考慮することができる。応答がホストマネージャから受信されない場合、または応答がタイムアウト応答（ＨＴＴＰコード「５００」、またはいずれの他の「５ｘｘ」エラー応答コード等）である場合、イベントプロセッサは、ステータス取得（ｇｅｔＳｔａｔｕｓ）要求を再送信することができ、データベースインスタンスを「隔離された」または類似する状態に置くことができる。ホストが所定数のステータスピングまたは他のそのような要求にわたって「隔離された」状態にある場合、データインスタンスは、「停止」または類似する状態に宣言され得る。ホストが所定数のステータスピング内で「２００」応答（または類似する）コードとともにオンラインに戻る場合、ホストまたはインスタンスは、「ＯＫ」状態に移動され得る。ホスト状態を「隔離された」から、少なくとも部分的に使用される「停止」または「ＯＫ」へ移動する前の所定回数のチェックは、間欠的なネットワークエラー、一時的に過負荷状態のイベントプロセッサ、一時的に過負荷状態のホストマネージャ、または他のそのような一時的なエラーに起因する誤検出を回避するためのものであり、実際には他の利用できなくなっているデータインスタンスをもたらさず、さもなければ復旧を要求する。一実施形態において、その状態が別のイベントプロセッサによって容易に判定され得るため、「隔離された」状態は、存続されない。
【００３７】
応答が所定回数のステータス要求の後に受信されない場合、または本明細書の他の箇所に記載されるように状態が「停止」または類似する状態へ別の方法で移動される場合、イベントプロセッサは、無反応なホストマネージャに関して疑わしい状態があることを示すネットワーク管理組織（Ａｄｍｉｎ）データストア２２２（または、上述の他のそのようなジョブ待ち行列）へ問題状態に関する情報を入れる。上述のように、制御プレーンのスイーパ２１４構成要素は、情報についてネットワーク管理組織（Ａｄｍｉｎ）データストアを定期的にチェックすることができ、スイーパが疑わしいまたは問題状態の情報を検出する際、適切な復旧ワークフローは、始動され得る。例えば、スイーパは、利用できない状態のデータインスタンスを処理するワークフロー、ホストマネージャによって報告されるエラーを処理するワークフロー、または多数の他のそのような状況のいずれか等の適切なワークフローを生成させるワークフロー構成要素２１６へ情報を渡す。ワークフローマネージャは、適切なワークフローを生成し、状態情報を渡し、本明細書の他の箇所に記載されるように様々な他の態様を取り扱うことができる。
【００３８】
ネットワーク管理組織（Ａｄｍｉｎ）データストア内に復旧情報を記憶する一利点は、そのようなアプローチが監視システムの故障の場合においてさえも復旧を可能にすることである。それは、監視データストアの利用可能性から独立している復旧動作を可能にするよう望まれ得る。それは、この実施形態において、ワークフロー等の生成を含むどのような種類の復旧もアクティブかつ利用可能になるネットワーク管理組織（Ａｄｍｉｎ）データストア（または、他のそのようなジョブ待ち行列）を要求するため、ネットワーク管理組織（Ａｄｍｉｎ）データストアを使用するよう許容可能になり得る。それは、したがって、復旧上の別の依存関係に位置することを避けるよう望まれ得、代わりに可能性の単一の位置付けを有する。
【００３９】
様々な実施形態に従うシステムおよび方法は、顧客がウェブサービス、または類似するそのようなアプローチを利用すること、ならびに作成クラウドコンピューティングまたは類似する環境内の１つ以上の複製データベースインスタンスを作成することを可能にし、その結果として高い耐久性がありかつ高い利用可能なデータソリューションを提示する。様々な実施形態において、顧客が複製データベースインスタンスを作成する際、顧客データは、一次／二次複製モデルを使用して、同期的に複製される。いくつかの実施形態において、複製は、異なるデータゾーン内等の異なる物理位置に配置され得る。各データ「ゾーン」は、１つ以上のデータセンタ、またはデータサーバのグループを指すことができ、例えば、異なる地理的な位置またはその周辺に配置されている異なるゾーンとともに、特定の地理的な領域内に配置される。次いで、ＲＤＳインスタンスは、異なる地理的な位置における別のデータゾーンが、大きな壊滅的なイベントの場合を除いて故障を回避することができるであろうために、データゾーンのうちの１つの故障に耐えることができる。ある場合には、データセンタは、複数のデータゾーンに及ぶことがあるが、与えられたデータセンタ内のデータ複製は、異なるゾーン内にインスタンスを生成され得る。多くの他の変形は、重複ゾーン、複数の地理的な位置におけるゾーン等のように可能である。一次複製が故障するか、またはそうでなければ利用できなくなる場合、ＲＤＳシステムは、二次複製へ迅速かつ自動的にフェイルオーバーすることができ、非常に小さな故障時間または非常に小さなデータ欠損をもたらす。
【００４０】
一実施形態において、顧客は、図２について記載されるような制御プレーンのウェブサービス層における特定されるインターフェースをコールすることにより、複製データベースインスタンスを作成することができる。例えば、顧客は、インスタンスクラス、割り当てられたストレージ、データベースエンジン等のような態様を特定する「ＣｒｅａｔｅＤＢＩｎｓｔａｎｃｅ」ＡＰＩをコールすることができ、同様に顧客は、非複製データインスタンスを作成できる。複製されたインスタンスの作成の際、顧客は、「複製された」または類似するパラメータ等の少なくとも１つの追加的なパラメータを、「真（ｔｒｕｅ）」または作成されたインスタンスが複製されるべきであることを示すその他の適切な値に設定された値とともに、含むことができる。いくつかの実施形態において、値は、初期設定により「偽（ｆａｌｓｅ）」に設定され、顧客によって特定されない限り、非複製インスタンスが作成されるようにする。いくつかの実施形態において、特定の顧客のみが、一定レベルのサービス等の代金を支払う顧客のような複製されたインスタンスを作成する能力を有する。
【００４１】
いくつかの実施形態において、顧客はまた、二次複製が、一次複製よりむしろ異なるデータゾーン内に作成されるかどうかを選択することもできる。顧客はまた、いくつかの実施形態において、インスタンスのための１つ以上の特定のデータゾーン、または順序付けられたリストを選択することを可能にされ得、例えば、その一方で他の実施形態において、顧客が少なくとも一次複製のためのデータゾーンを選択できない場合がある。顧客が２つのデータゾーンを特定し、データゾーンのうちの１つが長時間利用できなくなる場合、例えば、いくつかの実施形態における耐久性必要条件は、第３のデータゾーン等内に生成させる別の複製を引き起こす。これは、複数の顧客のために管理およびデータゾーンリストの順序の更新を要求することができ、いかなる有意義な利益も提示することなく、ユーザ経験を複雑にすることがある。さらに、それはデータゾーンにわたって関連付けられるアプリケーションフリートを広げるアプリケーションにとって容易になることができ、二次複製として同一データゾーンに位置するいくつかのアプリケーションフリートがあり得るようにする。
【００４２】
いくつかの実施形態において、顧客は、複製されたデータインスタンスのための「ディスクライブＤＢインスタンス（ＤｅｓｃｒｉｂｅＤＢＩｎｓｔａｎｃｅ）」または類似するＡＰＩをコールすることができ、それによってＲＤＳは、一次複製の終点ＤＮＳ名および一次複製が現在配置されているデータゾーン等の情報のリストを作ることができる。顧客は、単一のデータゾーンに使用される従来のアプローチを使用して依然ＲＤＳインスタンスと通信することができ、ＲＤＳインスタンスのステータスが「利用可能」になるとすぐに、顧客はデータストアの終点ＤＮＳ名を受信することができるため、例えば、終点ＤＮＳ名を使用してインスタンスへ接続する。複製に故障が発生した場合、ＲＤＳは、データベースを対応する二次複製へフェイルオーバーすることができ、終点ＤＮＳ名は、新しい一次複製対して別名を付けることができる。データベース終点ＤＮＳ名は、多くの実施形態において持続性を留め、複製されたインスタンスの寿命の間、変化しない。
【００４３】
いくつかの実施形態において顧客は、「修正ＤＢインスタンス（ＭｏｄｉｆｙＤＢＩｎｓｔａｎｃｅ）」または類似するＡＰＩを「真（ｔｒｕｅ）」に設定された複製されたパラメータとともにコールすること等によって、非複製インスタンスを複製されたインスタンスへ変質させる能力が提供され得る。これは、データベースを適切な時期において、次の保全ウィンドウの間、またはその要求の直後等で複製されたインスタンスに変換させることができ、ＡＰＩコールパラメータ等に依存してもよい。
【００４４】
様々な実施形態は、サーバ間のブロックデバイスのコンテンツを、ミラーするシェアーナッシングかつ複製されたストレージソリューションを実装するカーネルモジュール等のブロックレベル複製機構を活用する。ＢＬＲＭは、ブロックデバイス（すなわち、ハードディスクまたは論理的なボリューム）の上部で動作する。それは、一次スレーブ複製アーキテクチャを使用し、そこで一次複製は全ての更新を根底にあるブロックデバイスへ向ける。ブロックデバイスへの全ての入力および出力（Ｉ／Ｏ）要求は、自動的かつ同期的に複製されている全ての書き込み操作とともに、ＢＬＲＭカーネルモジュールによって妨害される。ＢＬＲＭは、ピアデバイスの特有の故障検出を提供し、ピアノードが到達不可能である際、適切な復旧ハンドラを起動する。ＢＬＲＭはまた、一時的に利用できないノードを、一次複製におけるデータアクセスを妨げることなく、バックグラウンドでデータの最新バージョンへ、自動的に再同期することもできる。ＢＬＲＭは、複製されたデータの世代を識別する世代識別子（「ＧＩ」）を使用し、それによってＢＬＲＭは、２つのノードが同一の複製ペアのメンバであるかどうか、バックグラウンド再同期（必要であれば）の方向であるかどうか、ならびに部分的なまたは完全な再同期は必要とされるかどうか等の態様を判定することができる。ＢＬＲＭドライバは、切断された予備複製が一次複製に切り替わる際、あるいは一次の役割におけるリソースが二次複製から切断される際、複製ペアの初期化の間等の任意の適切な時期において、新しい世代を始動することができる。ブロックレベル複製機構が説明の目的のために例として本明細書に使用されるが、その他の適切なブロックレベル技術または機構は、様々な実施形態の範囲内で使用することができることを理解されたい。
【００４５】
記載されるように、様々な実施形態におけるＲＤＳデータインスタンスは、１つ以上のシステムまたはプラットフォームに基づいて作られ得る。例えば、インスタンスは、仮想コンピューティング環境に基づいて作られ得、それは様々なオペレーティングシステムとともにインスタンスを立ち上げ、それらのインスタンスを管理するために、顧客がウェブサービスまたは別の適切なアプローチを利用することを可能にする。仮想コンピューティング環境のようなものを提供するウェブサービスの例は、Ａｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．によって提示されるエラスティックコンピュートクラウド（Ｅｌａｓｔｉｃ  Ｃｏｍｐｕｔｅ  Ｃｌｏｕｄ）（ＥＣ２）サービスである。データインスタンスはまた、ブロックレベルストレージ機構に基づいて作られ得、それはインスタンスの寿命とは無関係に存続するオフインスタンスストレージを提供することができる。ブロック記憶機構は、インスタンスに付けられ、インスタンス内にデバイスとして映され得るストレージボリュームを提供することができる。ブロック記憶プラットフォームの例は、同時係属中の２００８年８月８日に出願された「Ｍａｎａｇｉｎｇ  Ａｃｃｅｓｓ  ｏｆ  Ｍｕｌｔｉｐｌｅ  Ｅｘｅｃｕｔｉｎｇ  Ｐｒｏｇｒａｍｓ  ｔｏ  ａ  Ｎｏｎ−Ｌｏｃａｌ  Ｂｌｏｃｋ  Ｄａｔａ  Ｓｔｏｒａｇｅ」と題される米国特許出願第１２／１８８，９４９号に提供され、本明細書に参照として組み込まれる。論理的なボリューム（例えば、ＬＶＭ層）は、ブロック記憶ボリュームおよび顧客データベースがＬＶＭ／ファイルシステム層の上層で動作することができるような適切なファイルシステムの上部に作られ得る。一実施形態における複製データベースに対して、ＢＬＲＭは、ＬＶＭ層の上層で動作することができる。そのような実施形態等におけるＢＬＲＭは、全てのＩ／Ｏ要求を妨害し、それらの要求を、複数のブロック記憶ボリュームにわたって要求を順に分割することができる論理的なボリュームへ送信するであろう。論理的なボリュームの使用は、複数のブロックストレージＥボリュームを処理する能力、ならびにストレージ等を容易に拡大する能力を提供することができる。ＬＶＭの上層にＢＬＲＭを階層化することは、書き込み操作が複製にわたって複製されることも可能にすることができる。
【００４６】
図４は、複製されたＲＤＳインスタンスを提供するために、一次／二次複製モデルを実装するための機構４００の例を図示する。この例において、一次複製４１０および二次複製４１２は、データプレーン４０８またはデータベース環境の異なるデータゾーン（１および２）内に位置する。各複製は、各複製のためのブロック記憶４２０、４２２に対するＩ／Ｏを管理するためのＢＬＲＭ層４１８、４２２として、ここで図示されるブロックストレージ機構の上部に作られる。図２と関連して説明されるものと類似するような、制御プレーン４０６の構成要素は、例えば、必要なセットアップ操作を実行することができるローカルホストマネージャ４１４、４１６に対して、構成コマンドを発行することによって、複製されたＲＤＳインスタンスを作成することができる。図に見られるように、ＢＬＲＭ４１８、４２２等のブロックレベル機構は、全てのＩ／Ｏ要求をブロックデバイスレベルで妨害し、ローカルディスクおよび遠隔ディスク４２０、４２４へ、その要求の情報を書き込むように位置される。この例において、データベース４２６（例えば、ＳＱＬ）は、一次複製４１０でのみ実行され、全てのクライアント４０２は、一次複製４１０上で（適切なネットワーク４０４を経由して）それらのデータベーストランザクションを実行する。データベース４２６は、二次複製４１２上では実行されず、ファイルシステムはまた、データベースが一般的には基礎的なデバイス内の更新を認識しないため、二次複製上でマウントされない可能性もある。
【００４７】
各データベースクライアント４０２は、一次複製４１０のホスト名に別名を付けることができるＲＤＳデータベースのＤＮＳ終了時点の名称を使用して、現在の一次複製を自動的に発見することができる。現在の一次複製を発見するためにＤＮＳを使用することによって、互換性を、例えば生来のＭｙＳＱＬクライアント、ＪＤＢＣ、ＰＨＰ、Ｃ＃、およびＨａｓｋｅｌｌ等の既存のデータベースクライアントに維持することができる。ＤＮＳキャッシングが、クライアントに古い一次複製に接続するよう試みさせる可能性があるが、二次複製内で実行されるデータベースがないため、クライアントは二次複製に接続することによって、データベースに通信することができなくなる。顧客は、次いで、適切なＤＮＳ情報を取得することを、知ることができる。
【００４８】
上述のように、データベース複製は、同一または異なるデータゾーン内で動作している複数の基礎的なデータインスタンスにわたってサポートすることができる。書き込み操作が、同期的なアプローチを使用して行われると、複数のデータゾーンの故障等のために全ての複製が利用できないという極めてまれな事例を除き、データが失われることはない。そのようなアプローチは、単一の複製の故障がデータベースに長時間の停電をもたらさないため、単一のデータベースインスタンスよりも高い利用可能性を提供することができる。例えば、データベースの一次複製が停止している場合、多数の事例において、システムは、二次複製に対してフェイルオーバー操作を実行することができる。さらに、そのようなアプローチは、非複製のデータベースよりも高い耐久性を提供することができ、データゾーンの故障または単一のブロック記憶ボリューム故障等の故障から保護することができる。
【００４９】
前に説明したように、ＲＤＳは、サーバ間のブロックデバイスのコンテンツをミラーとするためにＢＬＲＭ等のブロックレベル機構を利用することができる。一次スレーブ複製アーキテクチャは、ブロックデバイスに対する全ての更新を一次が受け入れ、書き込むことを可能にする。ブロックデバイスに対する全てのＩ／Ｏ要求は、ＢＬＲＭカーネルモジュールによって妨害され、書き込みは同期的に複製されることになる。ＢＬＲＭは、複製されたデータの世代を識別するために、世代識別子（「ＧＩ」）を利用する。ＢＬＲＭは、この機構を使用し、２つのノードが、誤って接続された２つのノードとは対立するものとして、実際に同一の複製ペアのメンバであるかどうかを判定する。ＧＩはまた、必要であれば、バックグラウンドの再同期の方向を判定し、部分的または完全な再同期が必要であるかどうかを判定するために使用することもできる。少なくとも一実施形態において、ＧＩは、汎用一意識別子であり（ＵＵＩＤ）、単調にシーケンス数を増やさない。ＢＬＲＭドライバは、切断された二次複製が新しい一次複製に切り替えられる際、または一次の役割におけるリソースが二次複製から切断される際等の複製ペアの初期化の間に、新しい世代を始動することができる。
【００５０】
複製ペア（例えば、一次複製Ｐおよび二次複製Ｓ）が初期化され、最初に接続される例において、一次複製Ｐは、ＧＩ1等の新しいＧＩを生成することができる。一次複製ＰがＳから切断され、劣化モードに移動する場合、Ｐが同期的な複製なしに全てのＩ／Ｏを実行すると、Ｐは、ＧＩ2等の新しいＧＩを生成することができる。しかしながら、ＰおよびＳがネットワーク分割のために切断される場合においてさえも、Ｓは新しいＧＩを生成することはない。この例において、一次複製Ｐは、そのメタデータ内に新しいＧＩおよび前のＧＩ（それぞれＧＩ2およびＧＩ1）を保つ。前のＧＩを記憶する理由の１つは、二次複製の復旧を最適化するためである。例えば、Ｓが一瞬の間切断される一時的なネットワーク分割が存在する場合がある。その後に、分割が修復し、ＳがＰに再び付けられる際、ＰはＳの現在のＧＩが前のＰのＧＩであることを認識することができ、Ｐが２つのデータ世代間で変更されたこれらのブロックのみを輸送することができる。
【００５１】
一次複製の故障が存在する例において、Ｐが利用できないと検出される場合、Ｓは新しい一次複製に昇格することができる。コマンドが二次複製を新しい一次複製に昇格させるために発行される際、ＢＬＲＭは、新しいＧＩを新しい一次複製（前のＳ）において生成することができる。したがって、Ｐ（もともとの一次複製）がその集団を再度結び付け、Ｓと通信する際、Ｐはデータ世代が変化し、ＰがＳからデータを同期しなければならないことを判定することができる。
【００５２】
記載のように、一次複製Ｐは、全ての書き込みおよび読み込みを受け入れることができ、ＤＮＳ＿一次（ＤＮＳ＿ｐｒｉｍａｒｙ）は、一次インスタンスのＤＮＳ名に別名を付けるか、またはｃｎａｍｅを付けることができる。二次インスタンスＳは、ＤＲＤＢ複製（または類似のブロックレベル複製）プロトコルを介して、全ての更新を一次複製から受信することができる。二次複製内でマウントされるデバイス、または始動されるデータベースはない。フェイルオーバーを可能にする際、利用することができる別の構成要素は、監視構成要素Ｍである。監視構成要素は、一次および／または二次複製の健康状態を監視することができ、故障が起こる際に適切なフェイルオーバー動作を開始することができる。一実施形態における監視構成要素は、定期的に一次および二次複製にピングを打つか、そうでなければそれらと通信する。この通信は、例えば、Ｔ＿ハートビート（Ｔ＿ｈｅａｒｔｂｅａｔ）または類似のパラメータによって特定される秒数等の通常の間隔で起こる、ハートビート通信を含むことができる。監視構成要素がＰおよびＳにピングを打つ場合はいつでも、一実施形態における監視構成要素は、ＨＴＴＰステータス取得）（ｇｅｔＳｔａｔｕｓ（））コマンドを各複製内で動作しているホストマネージャに発行する。ＰおよびＳが、それぞれコールを受信する際、複製は、各複製の現在の状態を判定するために、ＢＬＲＭまたは類似のステータスコールを実行する。例えば、一次複製Ｐは、同期（ＩＮ＿ＳＹＮＣ）、機能停止（ＳＴＡＬＬＥＤ）、劣化（ＤＥＧＲＡＤＥＤ）、停止（ＤＥＡＤ）等のステータスを判定するために、ＢＬＲＭツールコマンドを実行することができる。
【００５３】
ステータスを報告することに加えて、複製のそれぞれは、メモリ内に世代数を記憶することができる監視構成要素へそれぞれのＧＩを報告することもできる。新しい監視構成要素がブートストラップする際はいつでも、新しい構成要素は、複製ペアのリストならびに終了ポイントを、強く一貫したデータストア（つまり、監視データベース）から読み込むことができ、メモリ内にその情報を記憶することができる。各ステータスピングの間、監視構成要素は、その数が同一かどうかを判定することができる。何らかの理由でその数が異なる場合、ＧＩ値はメモリ内で更新することができる。
【００５４】
一次または二次複製は、少なくとも２つの監視状態のうち１つ内にあり得る。図５は、一実施形態に従って一次複製のための状態遷移図５００の例を図示する。複製は、複製が監視構成要素に接続される場合、監視（ＭＯＮＩＴＯＲＥＤ）状態を有することができる。複製は、複製が監視構成要素に接続されない場合、非監視（ＮＯＴ＿ＭＯＮＩＴＯＲＥＤ）または類似の状態にあり得る。一次インスタンスはまた、複数のデータ同期状態のうちの１つでもあり得る。例えば、ＰおよびＳの両方が機能しており、互いに通信することができる場合、Ｐは同期（ＩＮ＿ＳＹＮＣ）状態にあることができ、全ての書き込みは、ＰとＳとの間で同期的に書き込まれる。状態図を見ると、一次複製が同期（ＩＮ＿ＳＹＮＣ）／監視（Ｍｏｎｉｔｏｒｅｄ）状態にある５０４において、一次複製は二次複製と通信することができ、全ての書き込みは継続しており、ＢＬＲＭはハートビートしており、一次は監視されている。一次が監視構成要素から切断されるが依然として二次複製と同期している場合、その状態は、状態５０２へ移行することができる。状態５０２において、一次は、二次複製と通信することができ、どちらの複製も接続され、更新されているが、一次は監視構成要素から切断され、したがって、監視されていない。二次複製はまた、二次複製が健全であり、一次複製と連絡を取り合う接続（ＣＯＮＮＥＣＴＥＤ）状態にあってもよく、二次複製が健全であるが一次複製と連絡を取り合わない場合には切断（ＤＩＳＣＯＮＮＥＣＴＥＤ）状態にあってもよい。したがって、状態５０２および５０４において、二次複製は、接続（ＣＯＮＮＥＣＴＥＤ）状態にある場合があるが、他の状態においては切断（ＤＩＳＣＯＮＮＥＣＴＥＤ）である場合もある。
【００５５】
一次複製は、Ｐが監視されるがＳから切断される、またはＳと連絡を取り合わない場合、機能停止（ＳＴＡＬＬＥＤ）状態または類似の状態５０８を有することができ、全ての書き込みが凍結されるため、いかなるＩ／Ｏ操作も進行することができない。一次複製は、ＰがＳから切断され、非複製モードに切り替えられた場合、劣化（ＤＥＧＲＡＤＥＤ）または類似の状態４０６を有することができる。これは、Ｓが停止しているか、そうでなければ到達不可能な場合に、Ｐが読み込みまたは書き込みに対応し続けることを可能にする。Ｐは、状態５０２または５０８のどちらかから、劣化（ＤＥＧＲＡＤＥＤ）モードに到達することができる。Ｐは、多くの実施形態において、ＲＤＳが典型的に新しい予備複製を作成することになるため、劣化（ＤＥＧＲＡＤＥＤ）モードに長く留まらない場合がある。新しい二次複製がインスタンス生成されると、それは一次複製と完全に同期され、監視構成要素によって監視されており、状態は複製が同期しており（ＩＮ＿ＳＹＮＣ）監視される（Ｍｏｎｉｔｏｒｅｄ）状態５０４へ戻ることができる。
【００５６】
一次複製は、ＰがＳから切断され、非観察（ＮＯＴ＿ＯＢＳＥＲＶＥＤ）状態にあるか、入るかの場合、自滅（ＳＵＩＣＩＤＡＬ）または類似の状態５１０にあることができる。この場合、Ｐの状態は、Ｔ＿フェイルオーバー（Ｔ＿ｆａｉｌｏｖｅｒ）秒間等の期間の後、自滅（ＳＵＩＣＩＤＡＬ）へ変化することができる。この状態５１０は、いくつかの実施形態において、機能停止（ＳＴＡＬＬＥＤ）状態５０８からのみ到達することができ、Ｐが監視構成要素と連絡を取り合わない場合に起こる。この状態において、一次複製は、それ自体をシャットダウンすること、またはデータインスタンスを再動作することによって、「自滅する」。
【００５７】
そのようなプロセスを実行するための監視およびフェイルオーバーアーキテクチャの一部として、各複製データベース（つまり、複製ペア）は、監視構成要素によって監視される。ＲＤＳにおいて、単一の監視構成要素は、複数の複製ペアを監視することができる。さらに、システムは、複数または「フリート」の監視ノードを利用することができる。記載されるように、監視構成要素は、複製ペアを毎Ｔ＿ハートビート（Ｔ＿ｈｅａｒｔｂｅａｔ）秒間等の適切な間隔で継続的にピングを打つことによって、監視データベースの状態を判定することができる。図６は、各監視構成要素Ｍの観点からの複製データベースの状態遷移図６００の例を図示する。一次複製が同期（ＩＮ＿ＳＹＮＣ）状態にあり、二次が接続されている場合、Ｍは、データベースを同期（ＩＮ＿ＳＹＮＣ）または類似の状態６０４にあると見なすことができる。Ｍはまた、監視構成要素が、例えばネットワーク分割のために複製のうちの１つと通信できない場合に、データベースを状態６０４にあると見なすことができるが、複製は接続され同期していることを、他の複製が監視構成要素に示すため、フェイルオーバーイベントを実行する必要が全くない。
【００５８】
Ｍが、何らかの理由のために、もはや一次および二次複製のどちらとも通信することができない場合、監視構成要素が分割されているか、あるいはどちらの複製も同時に利用できないかのどちらかである。どちらの場合においても、Ｍは、データベースの状態を分割（Ｐａｒｔｉｔｉｏｎｅｄ）状態または類似の状態６０２に移動していると見なすことができる。これは、一次および二次複製の両方を非監視（ＮＯＴ＿Ｍｏｎｉｔｏｒｅｄ）状態に置くことができる。監視分割が修復するか、または新しい監視構成要素がデータベースに割り付けられる場合、状態は同期（ＩＮ＿ＳＹＮＣ）状態６０４へ戻ることができる。
【００５９】
Ｍがもはや一次複製と通信することができず、二次複製が一次複製と通信することができない場合、それは切断（Ｄｉｓｃｏｎｎｅｃｔｅｄ）状態にあり、監視構成要素はデータベースをＳ＿オンリー（Ｓ＿ＯＮＬＹ）状態６０６にあると見なすことができる。Ｔ＿フェイルオーバー（Ｔ＿ｆａｉｌｏｖｅｒ）秒間等のある期間内に、監視構成要素が一次複製との通信を再確立することができれば、状態は、同期（ＩＮ＿ＳＹＮＣ）６０４に戻ることができる。監視が、少なくともＴ＿フェイルオーバー（Ｔ＿ｆａｉｌｏｖｅｒ）秒間一次複製と通信することができない場合、監視構成要素は二次複製を新しい一次へ昇格させることができる。二次複製が、現在のＧＩが一次複製の最新の既知のＧＩと同一であると確認し、二次複製が昇格要求を確認すれば、新しい二次がインスタンス生成され、新しい一次と完全に同期され、その時に状態が同期（ＩＮ＿ＳＹＮＣ）６０４へ戻ることができるまで、状態はＰ＿オンリー（Ｐ＿ＯＮＬＹ）状態６０８に移行することができる。
【００６０】
しかしながら、監視構成要素が、二次複製を新しい一次複製に昇格させることを決定するが、二次要求が昇格要求を拒絶する場合、状態は障害（Ｄｉｓａｓｔｅｒ）または類似の状態６１０に移行することができる。二次は、二次複製に対する現在のＧＩが一次複製の最新の既知のものとは異なるために、その要求を拒絶することがある。他の場合において、そうでなければ応答は二次複製から受信されない場合がある。これは、大規模な非可用性が存在する、またはＧＩもしくはメンバシップ情報が破損している等のまれにしか起こらない場合に起こり得る。
【００６１】
状態が同期（ＩＮ＿ＳＹＮＣ）６０４にある別の場合において、監視構成要素は、二次複製と通信する能力を失うことがあり、一次複製もまた、二次複製と通信する能力を失うことがあり、そのため一次複製は機能停止（ＳＴＡＬＬＥＤ）状態になる。この場合、状態監視構成要素は、一次複製が劣化（ＤＥＧＲＡＤＥＤ）状態に移行するよう要求することができ、監視構成要素によって見なされた状態は、Ｐ＿オンリー（Ｐ＿ＯＮＬＹ）または類似の状態６０８に移行することができる。監視構成要素および二次複製と通信することができない一次複製、ならびに劣化（ＤＥＧＲＡＤＥＤ）モードにある一次複製を用いて、新しい二次複製は、インスタンス生成され、一次複製と完全に同期することができ、そこでＭによって見なされた状態が同期（ＩＮ＿ＳＹＮＣ）６０４へ戻ることができる。
【００６２】
状態遷移図によって見られるように、少なくとも１つの実施形態において、監視構成要素によって実装されたフェイルオーバーアルゴリズムは、監視構成要素に、特定の状況の下で少しの間、新しい一次複製になるよう二次複製を昇格させることができる。この例は、単に図６の状態図を通した１つの経路を表すだけであることを理解されたい。図７は、一実施形態に従って使用することができる二次複製に対するフェイルオーバーのプロセス例７００を図示する。この例において、一次および二次複製は、プロビジョニングされ、接続され、同期される７０２。世代識別子（ＧＩ）は、各複製が複製データの現在の世代を識別するように生成される７０４。監視構成要素は、複製に割り付けられ、定期的に複製にピングを打つ７０６。複製ペアに割り付けられている監視構成要素は、その複製ペアのための一定期間後には期限切れとなり得る「リース」を取得することができるか、あるいはそれを伴って提供されてもよい。リースは、典型的に、一次複製のためのホストマネージャから受信され、イベントプロセッサリーススキームが一次複製のクラッシュを切り抜けることができるように、イベントプロセッサ識別子およびリース時間は両方の複製において記憶することができる。このようにして、監視構成要素は定期的に複製から解放され、したがって荷重の分散または分割の目的で他のペアに移動させられるか、そうでなければいくつかの他のそのような理由ために操作されることができる。リース期間の終了時、または終了時近くに、監視構成要素は、リースを延長するよう試みることができ、判定は、本明細書の他の場所に記載されるように、リースを延長しないように成される場合がある。監視構成要素が一次複製との連絡を失う場合７０８、監視構成要素は一定期間再試行するよう試みることができる７１０。監視構成要素が、任意の時点で一次複製との連絡を取り戻す場合、監視プロセスは継続することができる。監視構成要素がＴ＿フェイルオーバー（Ｔ＿ｆａｉｌｏｖｅｒ）秒間等の一定期間に一次複製と連絡を取り合わない場合、判定は、二次複製が一次複製と通信することができるかどうか、または二次複製が切断（ＤＩＳＣＯＮＮＥＣＴＥＤ）状態にあるかどうかに関して行われる７１２。判定は連絡が失われた時点での一次複製の状態が、二次複製と同期（ＩＮ＿ＳＹＮＣ）状態にあるとして知られていたかどうかに関して行われてもよい７１４。判定は、様々な実施形態において、別個に、あるいは実質的に同時に成されてもよい。二次複製が、一次複製と通信することができず、複製が同期されていた（例えば、同一のＧＩ値を有していた）場合、監視構成要素は、二次複製を新しい一次複製に昇格させるコマンドを発行することができる７１６。Ｐの最終状態が判定され得ない場合、フェイルオーバーは起こらない。監視構成要素は、プロセスまたは機械が再起動されたか、あるいは新しい監視構成要素が引き継がれたかの場合、Ｐの状態を知らない可能性がある。その場合、状態は劣化（ＤＥＧＲＡＤＥＤ）として扱われてもよい。
【００６３】
二次複製を新しい一次複製へ昇格させる際、監視構成要素は、一次への昇格（ｐｒｏｍｏｔｅＴｏＰｒｉｍａｒｙ）（古いＧＩ）等のコマンドを二次複製のためのホストマネージャへ発行することができる。この例において、「古いＧＩ」は、一次複製に対するホストマネージャの最新の既知のＧＩである。この要求を受信すると、二次複製は、最後にもう一度、一次複製と通信するよう試みることができる。複製が依然として通信できない場合、二次複製は、その現在のＧＩが（一次複製の）古いＧＩと同じであることを検証する７１８。二次複製はまた、要求を発行する、またはステータス要求を送信する監視構成要素が、その複製の有効な監視構成要素であるか、あるいはその複製の現在の「リース保持者」であるリース情報を検証することもできる。その場合、二次複製は、自身を昇格させることができることを確認し、適切なＢＬＲＭコマンドを発行することによって新しい一次となる７２０。二次複製は、一次への昇格（ｐｒｏｍｏｔｅＴｏＰｒｉｍａｒｙ（））要求に対する応答として新しいＧＩを監視構成要素へ返却する。その後に、新しい（昇格された）一次複製のホストマネージャは、ファイルシステムをマウントし、データベース（例えば、ＭｙＳＱＬ）を始動させる７２２。監視構成要素が無事に二次複製を昇格させ、ＤＮＳ＿一次ｃｎａｍｅは、新しい一次複製によって示され７２４、制御プレーンの監視構成要素または他の構成要素によって実行することができる。その後、インスタンス状態は、二次復旧の必要があるとしてマークすることができる７２６。
【００６４】
しかしながら、二次複製の現在のＧＩが古いＧＩと同一ではない場合、二次複製を新しい一次複製に昇格させるのは安全ではないかもしれない。この場合、昇格プロセスは、中断されてもよく、操作者介入の警報（または別の適切な是正動作）が生じる。操作者がこの問題を解決できない場合、特定の時点への復旧は、データベースを最新のよく知られた時点へ復元することによって実行することができる。
【００６５】
図を見ると、多数の異なる故障事例を判定することができる。例えば、第１の故障事例において、一次および二次複製が動作しており、操作する監視構成要素と通信している。監視構成要素の観点からは、構成要素が、ほとんどのＴ＿監視構成要素（Ｔ＿ｍｏｎｉｔｏｒｉｎｇ  ｃｏｍｐｏｎｅｎｔ）秒間内でのように定期的に、各インスタンスと通信することができる限りは、全てが予想通りに動作している。この場合の一次の状態は、「同期（ＩＮ＿ＳＹＮＣ）／観察（ＯＢＳＥＲＶＥＤ）」である。
【００６６】
監視構成要素と二次複製との間のネットワークリンクが分割されている故障事例においては、しかしながら、一次は二次および監視構成要素と通信することができるかもしれないが、監視構成要素は、二次複製と通信することはできないだろう。一次の観点からは、全ての書き込みは依然として成功しており、そうして一次が依然として同期（ＩＮ＿ＳＹＮＣ）／観察（ＯＢＳＥＲＶＥＤ）状態にあり、二次復旧は全く開始されないようになる。監視構成要素の観点からは、構成要素は二次故障を検出するが、一次が依然として二次と同期されるために、監視構成要素は実行および操作する必要はなく、ただ複製と通信するよう試みることを続けることができる。
【００６７】
その代わりに、ネットワーク分割に応答する等、監視構成要素が一次構成要素と通信することができない場合、二次複製は、一次複製および監視構成要素と通信できるようになるが、一次複製は監視構成要素から到達不可能となるであろう。一次の観点からは、ｎ×Ｔ＿ハートビート（Ｔ＿ｈｅａｒｔｂｅａｔ）秒間の後、一次複製が監視構成要素と連絡を取り合っていないため、一次は非観察（ＮＯＴ＿ＯＢＳＥＲＶＥＤ）状態に移動することになるであろう。いくつかの実施形態において、ｎの値は、２より大きいものに設定されてもよい。一次の状態は、したがって、同期（ＩＮ＿ＳＹＮＣ）／非観察（ＮＯＴ＿ＯＢＳＥＲＶＥＤ）であってもよい。監視構成要素の観点からは、二次複製のみが到達可能であるが、二次複製は、依然として一次複製と連絡を取り合っているため、監視構成要素はいかなるフェイルオーバーも開始しない。
【００６８】
故障事例の一例において、二次複製は、ノード故障またはネットワーク分割等の要因のために、停止していることがある。図８は、少なくとも１つの実施形態に従って、使用することができる二次復旧を実行するためのプロセス８００の例を図示する。この例は、複製が既にプロビジョニングされ、通信しており、同期されている、ならびに、監視構成要素によって監視されていると仮定する８０２。監視構成要素が二次複製との連絡を失う場合８０４、監視構成要素は一定期間再試行するよう試みることができる８０６。監視構成要素が任意の時点で二次複製との連絡を取り戻す場合、プロセスは継続することができる。監視構成要素が、一定期間二次複製と連絡を取り合わない場合、一次複製が二次複製と通信することができるかどうかに関して判定が成される８０８。一次複製が二次複製と通信することができない場合、一次はＴ＿同期（Ｔ＿ｓｙｎｃ）秒間の後、機能停止（ＳＴＡＬＬＥＤ）状態へ入ることができる８１０。機能停止（ＳＴＡＬＬＥＤ）状態に入った後、一次複製は、監視構成要素から連絡をもらうためにｎ×Ｔ＿ハートビート（Ｔ＿ｈｅａｒｔｂｅａｔ）秒間待機することができる。一次複製が、この時間ユニット内に監視構成要素から連絡をもらうと（つまり、一次は監視（ＭＯＮＩＴＯＲＥＤ）状態にある）一次は、劣化（ＤＥＧＲＡＤＥＤ）状態に入り、次のハンドシェイクにおいて監視構成要素に知らせる８１２。監視構成要素の観点から、状態はＰ＿オンリー（Ｐ＿ＯＮＬＹ）に入り、監視構成要素は二次複製が到達不可能であることを発見する。これを判定すると、監視構成要素はデータベースインスタンスの状態を二次復旧が必要（ＮＥＥＤ＿ＳＥＣＯＮＤＡＲＹ＿ＲＥＣＯＶＥＲＹ）等の状態としてマークし、本明細書の他の場所に説明されるような二次複製復旧ワークフローを開始する８１４。
【００６９】
別の故障事例において、全てのホストが機能し、動作していてもよいが、一次複製は監視構成要素および二次複製から分割されていてもよく、それは例えばデータゾーン分割または不良ラックのアップリンクのためであってもよい。したがって、監視構成要素はまた、二次複製と通信することができるが、監視構成要素も二次複製もどちらも一次複製に到達することはできない。一次複製の観点からは、Ｔ＿同期（Ｔ＿ｓｙｎｃ）時間ユニットの後、一次複製は機能停止（ＳＴＡＬＬＥＤ）状態に入る。機能停止（ＳＴＡＬＬＥＤ）状態に入った後、一次複製は、ｎ×Ｔ＿ハートビート（Ｔ＿ｈｅａｒｔｂｅａｔ）秒間、監視構成要素から連絡をもらうために待機する。この場合、一次複製は、監視構成要素から連絡をもらわず、二次複製から切断され、それは自滅（ＳＵＩＣＩＤＡＬ）状態へ移動し、二次複製として戻って来ると、インスタンスを再起動することによって「自滅する」。監視構成要素の観点から、監視構成要素は、Ｓ＿オンリー（Ｓ＿ＯＮＬＹ）の状態に到達し、一次構成要素が到達不可能であることを発見する。監視構成要素は、次のハンドシェイクにおいて、二次複製とチェックし、二次複製が一次複製と通信可能かどうかを判定する。この場合、二次複製は、切断（ＤＩＳＣＯＮＮＥＣＴＥＤ）状態にあることを主張するであろう。監視構成要素は、Ｔ＿フェイルオーバー（Ｔ＿ｆａｉｌｏｖｅｒ）秒間待機し、次いで一次複製が依然として利用できないことを確認する。そうすると、データベースの前の状態が同期（ＩＮ＿ＳＹＮＣ）であり、二次複製の現在のＧＩが一次複製の最新の既知のＧＩと同一である場合に、監視構成要素は二次複製を新しい一次複製として昇進させる。Ｔ＿フェイルオーバーの時間値は、ｎ×Ｔ＿ハートビート（Ｔ＿ｈｅａｒｔｂｅａｔ）＋Ｔ＿バッファ（Ｔ＿ｂｕｆｆｅｒ）に設定されてもよく、ｎは、前の事例においてｎが２より大きく設定された、前に記載されたものと同一のパラメータである。Ｔ＿バッファ（Ｔ＿ｂｕｆｆｅｒ）は、一次複製が「自滅する」ために予想される最悪の場合の時間である。
【００７０】
一次が停止しており、他の問題が全くない類似の事例において、フェイルオーバーもまた存在することがある。この場合は、しかしながら、一次複製が停止しており、自滅（ＳＵＩＣＩＤＡＬ）または他のそのような状態に入らないため、一次はいかなる移行状態も有しない。
【００７１】
別の故障事例において、一次および二次複製は、ネットワークの問題がなく予想通りに機能し、通信しているが、監視構成要素は、停止になるか、そうでなければ利用できなくなる。一次の観点から、全ては依然として同期（ＩＮ＿ＳＹＮＣ）のデータ同期状態にあるが、一次複製は非観察（ＮＯＴ＿ＯＢＳＥＲＶＥＤ）状態にあることを認識する。
【００７２】
説明したように、制御プレーンは、ＲＤＳインスタンスを監視し、必要な際には適切な復旧動作を発行するよう構成された、分散型のイベントプロセッサのセットまたはイベントプロセッシングフリートを含む。各イベントプロセッサは、ハッシュがインスタンス識別子または類似の識別する値に基づいて行われる単純なハッシュベースの分割アルゴリズムを採用すること等によって、ＲＤＳインスタンスの一部分のために作業負荷を監視する一部分を割り付けることができる。複製されたインスタンスを監視するために、イベントプロセッサは監視構成要素として機能することができる。イベントプロセッサはピングを打つか、そうでなければそのインスタンスに関連付けられた全ての複製と通信することによってＲＤＳインスタンスの健康状態を判定することができる。インスタンスが複製されない場合は、イベントプロセッサはそのインスタンスの単一のホストマネージャと通信するだけでよい。
【００７３】
複製されたインスタントがある場合にイベントプロセッシングフリート間でインスタンス監視作業負荷を分割するために、特別な考慮が存在してもよい。いくつかの実施形態において、監視システムは、インスタンスの数が増加するにつれて、実質的に直線的に拡大縮小するべきである。この拡大縮小は、追加のイベントプロセッサ（例えば、ホスト）を追加することによって様々なインスタンスにおいて成し遂げることができる。イベントプロセッサが、そのイベントプロセッサによって監視されているデータベースの各複製から異なるデータゾーン内に位置することが望ましい場合があるため、イベントプロセッサの設置に対して制限が存在する場合もある。イベントプロセッサを異なるデータゾーン内に設置することによって、データセンタの故障は、２つの同時故障が同時に起こり（例えば、監視構成要素および少なくとも１つの複製の故障）、データベースが復旧不可能な状態に達する可能性があることをもたらさない。全ての複製を含め、各データベースインスタンスが継続的に監視されることを確実にするのが望ましい場合もある。これは、様々な実施形態において、データベースインスタンスを分割し、各分割の監視所有者にイベントプロセッサのうちの１つを割り付けることによって成し遂げることができる。イベントプロセッサが何らかの理由で故障する場合、故障したイベントプロセッサによって所有され、監視される部分は、他の利用可能なイベントプロセッサに、均等に再配分されるべきである。
【００７４】
監視システムの直線の拡張性を保証しながらも依然としてイベントプロセッサの設置に対する制限に適合するためには、少なくとも１つの実施形態におけるイベントプロセッシングフリートは、各フリートが存在するデータゾーンに基づいて異なるグループへ分けられる。各グループは、グループ内のイベントプロセッサが、複製が各イベントプロセッサと同一のデータゾーンにないＲＤＳインスタンスと関連付けられるように構成することができる。
【００７５】
例として、４つの各データゾーン（ＤＺ１、ＤＺ２、ＤＺ３、およびＤＺ４）においてインスタンスをカバーしている４つのイベントプロセッサグループ（Ｇ１、Ｇ２、Ｇ３、およびＧ４）が存在してもよい。各複製ペアに対して、監視作業負荷は、複製ペアと同一のデータゾーン内にないグループ間で、分配することができる。この例において、複製ペアがＤＺ２およびＤＺ３内にあるＲＤＳインスタンスの監視作業負荷は、Ｇ１およびＧ４内のイベントプロセッサにわたって分割されてもよい。ＤＺ３およびＤＺ４内の複製ペアに対して、作業負荷は、Ｇ１およびＧ２のグループ間で分割することができる。
【００７６】
既定のデータゾーン内に位置する全ての複製データベースに対して、各イベントプロセッサは、独立してデータゾーンペアをカバーできるイベントプロセッサのリストを算出することができる。その後に、既定のデータゾーンペアに対して、データゾーンペアをカバーしているイベントプロセッサ識別子は、辞書編集の順序でソートすることができる。データベース識別子もまた、ソートされてもよく、ゾーンペアにわたって一様に分割されてもよい。例えば、ゾーンＤＺ２およびＤＺ３内に複製を有するデータベースがあってもよい。これらのデータベースは、グループＧ１およびＧ４内のイベントプロセッサによってともに監視されてもよい。便宜上、このデータゾーンペアにおけるデータベースのデータベース識別子は、（ＤＢｌ、．．．、ＤＢｌ０００）として設定することができ、グループＧｌ（ＥＰｌおよびＥＰ２）内に２つのイベントプロセッサが、グループＧ４（ＥＰ３およびＥＰ４）内に２つのイベントプロセッサが、それぞれあってもよい。この例において、ＥＰ１がブートストラップする際、ＥＰｌは、データゾーンペア（ＤＺ２、ＤＺ３）内には監視されるべきデータベースが１０００個あり、それらをカバーする４つのイベントプロセッサがあることを判定することができる。イベントプロセッサ識別子を辞書編集の順序でソートすることによって、ＥＰ１は、ＥＰ１がＤＢ１からＤＢ２５０をとることができ、ＥＰ２がＤＢ２５１からＤＢ５００をとることができ、ＥＰ３がＤＢ５０１からＤＢ７５０をとることができ、ＥＰ４がＤＢ７５１からＤＢ１０００をとることができることを判定することができる。ＥＰ１は、同一のステップを繰り返し、監視に適格である全ての複製ペアに対して、ＥＰ１が監視を担当しているデータベースを判定することができる。
【００７７】
イベントプロセッサの故障を検出するために、各イベントプロセッサは、ハートビート（ＨＥＡＲＴＢＥＡＴ）メッセージを、毎１０秒等定期的に他の全てのイベントプロセッサに送信する（例えば、ＨＴＴＰ上で）よう構成することができる。イベントプロセッサはまた、イベントプロセッサおよびそれらのステータス（例えば、利用可能（ＡＶＡＩＬＡＢＬＥ）または停止（ＤＥＡＤ））のリストを、各イベントプロセッサの最新のチェックインの時間とともに、維持することができる。第１のイベントプロセッサが、ハートビート＿故障＿時間（ｈｅａｒｔｂｅａｔ＿ｆａｉｌｕｒｅ＿ｔｉｍｅ）よりも長い、典型的には６回のハートビート間隔等のある複数のハートビート間隔である一定期間、別のイベントプロセッサから連絡をもらっていない場合、第１のイベントプロセッサは、無反応なイベントプロセッサを停止（ＤＥＡＤ）であるか、類似状態であると宣言することができ、監視作業負荷を調整することができる。無反応なイベントプロセッサホストが始動または復旧する際、イベントプロセッサはブートストラップ（ＢＯＯＴＳＴＲＡＰ）またはハートビート＿故障＿時間（ｈｅａｒｔｂｅａｔ＿ｆａｉｌｕｒｅ＿ｔｉｍｅ）に類似する一定期間類似モード内で始動し、そのピアのイベントプロセッサからハートビートを受信し、そのハートビートエージェントを始動することができる。この時間の後、イベントプロセッサは、分割に割り付けられたイベントプロセッサの状態に基づき監視作業負荷の現在のスライスを判定する操作可能（ＯＰＥＲＡＴＩＯＮＡＬ）モードへ自身を移動することができる。イベントプロセッサを一定期間ブートストラップモード（ＢＯＯＴＳＴＲＡＰ）に残す１つの理由は、イベントプロセッサを集団的に結び付ける新しいイベントプロセッサおよび残存しているイベントプロセッサがアクティブイベントプロセッサの現在の状態に集合するために十分な時間を有することを確実にするためである。
【００７８】
データゾーンの故障の場合において、故障データゾーン内のイベントプロセッサによって監視されるインスタンスが、残存しているグループによって引き継がれることを確実にすることが望ましい。１つの例において、４つのイベントプロセッサグループ（Ｇｌ、Ｇ２、Ｇ３、およびＧ４）は、それぞれ４つのデータゾーン（ＤＺ１、ＤＺ２、ＤＺ３、およびＤＺ４）内のイベントプロセッサをカバーする。ＤＺ１が停止すると、ＤＺ１内のイベントプロセッサによって監視しているインスタンスは、自動的に他のデータゾーン内のイベントプロセッサによって引き継がれる。
【００７９】
しかしながら、３つのイベントプロセッサグループ（Ｇｌ、Ｇ２、およびＧ３）がデータゾーンペア（ＤＺ２、ＤＺ３）、（ＤＺ３、ＤＺ１）、および（ＤＺ１、ＤＺ２）を監視する状態で、領域内に３つのデータゾーンしかないことも可能である。ＤＺ１が停止するイベントにおいて、Ｇ２およびＧ３は、一次複製を含むデータゾーンの故障に耐えるために、各グループが、二次複製が同一のデータゾーン内にあるインスタンスを監視する方法において再展開される必要がある。様々な実施形態において、「二次−ｄｚ−コロケーション−無視」等のフラグは、データゾーンが３−ＤＺ領域から外れる場合にのみ、オンにすることできる。このフラグがオフになると、グループは、イベントプロセッサが複製ペアと同一のデータゾーン内に存在することができないという制限を伴い、監視作業負荷を分割する。フラグがオンの場合、グループは、この制限を無視することができ、二次複製がそれと同一のデータゾーン内にあるＲＤＳインスタンスを選択するように自身を再整列させることができる。このフラグは、監視データベースまたは制御プレーン内の類似のデータストア内に存続することができる。
【００８０】
特定のＲＤＳインスタンスを監視するイベントプロセッサが１つだけ存在することを確実にすることが望ましい場合もまたある。特定の実施形態において、フェイルオーバーアルゴリズムは、単一の監視構成要素（つまり、イベントプロセッサ）が複製ペアをいつでも監視することを要求する。ネットワーク分割のどちらの側においても２つのイベントプロセッサを、１つのイベントプロセッサがＲＤＳインスタンスをフェイルオーバーしようと試み、もう１つが一次は依然として生きていると仮定し、「分割脳」シナリオへつながる状態で有することが望ましくない場合があるため、この制限は利用することができる。
【００８１】
単一のイベントプロセッサのみがＲＤＳインスタンスを監視していることを確実にするために、イベントプロセッサは、いくつかの実施形態において、ＲＤＳインスタンスの一次複製からリースを入手することを要求されることがある。他の実施形態において、監視構成要素は、リースを管理しデータ環境内の様々な構成要素と相互作用する制御環境の別の構成要素からリースを入手することができる。ＲＤＳインスタンスの一次複製からリースを入手する場合にのみ、イベントプロセッサは既定のＲＤＳインスタンスのためのフェイルオーバーを開始するために適格であり、それもＴ＿リース（Ｔ＿ｌｅａｓｅ）等のリース期間のみに限る。イベントプロセッサは、一実施形態において、データベース複製にピングを打つことによって（例えば、ＨＴＴＰステータスピングを発行することによって）ＲＤＳインスタンス一次複製からリースを入手し、データベース複製のホストマネージャは、通常の応答に加えてリースを配ることができる。いくつかの実施形態において、リースは、複製がＢＬＲＭ一次であり、一次および二次複製が同期している場合、および別のイベントプロセッサに与えられた有効なリースが依然として存在する場合にのみ配られる。一次複製がリースをイベントプロセッサに配る際、一次複製はリース時間およびイベントプロセッサ識別子をそのＢＬＲＭドライブへ書き込むことができる。同期している際のＢＬＲＭディスクへの書き込みによって、一次複製は、本質的に、二次複製にリースを知らせる。したがって、リース時間およびイベントプロセッサ識別子が無事に書き込まれた後（つまり、両方の複製において複製された）にのみ、一次複製は新しいリースをイベントプロセッサに配るであろう。さらに、イベントプロセッサ識別子およびリース時間を両方の複製内に書き込むことによって、イベントプロセッサのリーススキームは、一次複製のクラッシュを切り抜けることができる。ＲＤＳインスタンスの二次複製は、少なくともいくつかの実施形態において、いかなるリースもいかなる時点において配ることはない。二次複製は、要求が、イベントプロセッサの識別子がＢＬＲＭドライブのものと同一の識別子であるイベントプロセッサからの要求である場合にのみ、一次への昇格（ｐｒｏｍｏｔｅＴｏＰｒｉｍａｒｙ（））または類似の要求を受け入れる。
【００８２】
イベントプロセッサが再起動するか、あるいは新しいホストが引き継ぐ際、イベントプロセッサはＲＤＳインスタンスの状態（以前に監視されていなかった）が、一次複製が劣化（ＤＥＧＲＡＤＥＤ）モードにある状態のＰ＿オンリー（Ｐ＿ＯＮＬＹ）であると見なす。イベントプロセッサは、一次および二次複製にピングを打ち、データベースの現在の状態を判定し、必要に応じてその状態を変更する。前に指摘したように、イベントプロセッサは、一次複製が劣化（ＤＥＧＲＡＤＥＤ）状態にあると見なされる場合、いかなるフェイルオーバーも開始しない。「悲観的な」アプローチをとることによって、新しいイベントプロセッサが引き継ぐ際に、ミスがより少なくなるだろう。イベントプロセッサが再起動するか、あるいは新しいイベントプロセッサが引き継ぐ際、イベントプロセッサは既定のホストと関連付けられた両方の複製にピングを打ち、どちらの複製が現在のＢＬＲＭ一次であるかを判定する。この情報が集められると、イベントプロセッサは、ＤＮＳ＿一次ＣＮＡＭＥが現在の一次複製を指していることを確実にするために適切なｐＤＮＳ  ＡＰＩを用いてチェックすることができる。そうでない場合、イベントプロセッサは即座にフェイルオーバーを行うことができる。このシナリオは、イベントプロセッサがフェイルオーバーの最中に止まった場合に起こり得る。ＤＮＳキャッシングおよび他の効果のためにＤＮＳ情報が正しくない可能性があるため、ｐＤＮＳ  ＡＰＩは、ｐＤＮＳ  ＡＰＩが権限のあるデータベースを読み込む時に、ＤＮＳ名を解決することなく問い合わせされることができる。しかしながら、万一一次および二次複製の両方が、それらが正当な一次複製であると考えるようなごくまれなイベントが起こる場合には、操作者または責任のある技術者が、呼び出されることがある。
【００８３】
制御プレーン内の監視データベースは、監視されるべき現在のアクティブデータベースインスタンスのリスト、各インスタンスの種類（例えば、複製された）、およびイベントプロセッサが異なる顧客関連イベントのために集める任意のイベントを記憶することができる。データベースの数が増加するにつれて、いくつかの実施形態において、単一の監視データベースを越えて拡大縮小することが必要になることがある。このために、監視データベース内の全てのテーブルは、分割することができる。監視ＤＢ分割を可能にするために、「ｄｂ分割マップ」がイベントプロセッサとともに採用されてもよい。イベントプロセッサがデータベースインスタンスに関連するイベントを存続させなければいけない場合、イベントプロセッサは、そのイベントのための情報を書き込むために適切なデータベースを判定するために、「ｄｂ分割マップ」を調べることができる。
【００８４】
図９は、バケット内のイベントプロセッサの健康状態を監視し、一実施形態に従ってイベントプロセッサのうちの１つの故障を処理するためのプロセス例９００を図示する。この例において、少なくとも１つの作業負荷分割がデータプレーンのために判定される９０２。少なくともある程度は、データストア、インスタンス、ホストマネージャ、および監視されるべき他のそのような構成要素の数によって、全般的な作業負荷は任意の多数の別個の分割に分割することができる。１セットのイベントプロセッサは、各作業負荷分割に割り付けることができ９０４、セット内の各イベントプロセッサは、割り付けられた分割に対するそれぞれの部分を割り当てられる９０６。適切な間隔で、各イベントプロセッサは「ハートビート」メッセージを（例えば、ＨＴＴＰにわたって）、同一の作業負荷分割をカバーする同一のセットまたはバケット内のイベントプロセッサに送信する９０８。ハートビートは、１０秒毎等の任意の適切な間隔で送信することができる。一実施形態における「ハートビート」は、他のイベントプロセッサにハートビートを送信するイベントプロセッサのステータスの情報を与えるためにバケット内の各イベントプロセッサに送信される、単純なマルチキャストメッセージを指す。イベントプロセッサは、各イベントプロセッサの最新チェックイン時間とともに、イベントプロセッサおよびそれらのステータス（例えば、「利用可能」または「停止」）のリストを維持することができる。ハートビートが、バケット内の各イベントプロセッサから受信されたことを判定すると９１０、そのプロセスは継続することができる。
【００８５】
しかしながら、同一バケット内のイベントプロセッサがハートビートに応答していないと判定する場合は、特定のハートビート故障時間（例えば、６回のハートビート間隔である）と同じかそれより長い期間イベントプロセッサがハートビートを送信することに故障したかどうかについて判定が成される９１２。特定のハートビート故障時間が到達されていない場合、プロセスは継続することができる。ハートビート故障時間が、少なくともイベントプロセッサからのハートビートなしに到達された場合、バケット内の各アクティブイベントプロセッサは、無反応のイベントプロセッサが「停止」または類似の状態にあると宣言し、責任範囲を割り当て、監視作業負荷の部分を引き継ぐことができる９１４。バケット内の全てのアクティブイベントプロセッサが故障したイベントプロセッサからハートビートメッセージを受け取ることに失敗するであろうため、イベントプロセッサは、それぞれ、「欠落」イベントプロセッサの作業を拾得するのに適切な量で割り当てられた作業負荷を拡大することができる。
【００８６】
４つのイベントプロセッサおよび６０，０００個の監視されているインスタンスが存在する場合、図１０の例１０００に図示されるように、各イベントプロセッサは１５，０００個の（辞書編集の順序、または識別子による別の適切な順序等に順序付けられる）のインスタンスを処理する。イベントプロセッサのうちの１つが故障すると、各イベントプロセッサがこれから２０，０００個の（識別子等によって、依然として連続的に順序付けられている）インスタンスを処理できるように、他の３つのイベントプロセッサはそれらの責任の各範囲を再割り当てすることができる。したがって、インスタンスが順序付けスキームを使用して順序付けられているため、イベントプロセッサは監視されるべき順序付けスキームの範囲を調整することができ、マップする必要がなく、そうでなければどの「新しい」インスタンスを監視するかを追跡する。監視されている範囲は、例えば、監視データストア内に記憶することができる。そのようなアプローチはまた、作業負荷がイベントプロセッサにわたって自動的に均等に（実質的に）分散されるため、インスタンスが追加またはリムーブされる状況において有益である。特定のバケット内でのみハートビートすることはまた、広範囲のハートビートよりも効率的で維持し易い。
【００８７】
図１１は、イベントプロセッサがバケットに追加される際、例えば追加のプロセッシング容量を追加した結果か、または故障したイベントプロセッサ復旧の結果であってもよく、再び作業負荷の部分を処理することが可能になる等の、バケットにわたる作業範囲を再割り当てするためのプロセス例１１００を図示する。イベントプロセッサは、再始動または復旧しているイベントプロセッサホスト、あるいは単純にアクティブにされているまたはバケットに追加されているホストによって等、アクティブなることができる１１０２。復旧の場合にイベントプロセッサは既にバケットへ割り付けられている可能性があるが、イベントプロセッサはまた、バケットに追加することができる１１０４。アクティブイベントプロセッサがバケットに追加されると、イベントマネージャは、一定期間（例えば、ハートビート故障時間）「ブートストラップ」モード等のモードに入ることができ、バケット内のピアのイベントプロセッサからハートビートを受信し１１０６、バケット内でアクティブな他のイベントプロセッサについての情報を取得し、例えば、ハートビートを送信するための時間を判定する。イベントプロセッサは、ハートビートエージェントをバケット内の他のイベントプロセッサへハートビートを送信し始めるようにも手配することができる１１０８。この時間の後、ホストは、各イベントプロセッサが作業の範囲を再割り当てし、分割に割り付けられたイベントプロセッサの状態に基づいて、監視作業負荷の現在のスライスを判定することができる「操作可能」モードへ移動することができる１１１０。一定期間イベントプロセッサを「ブートストラップ」モードに残す１つの理由は、イベントプロセッサを集合的に結び付ける（または再度結び付ける）新しいイベントプロセッサおよび残存しているイベントプロセッサが、アクティブイベントプロセッサの現在の状態に集合するために十分な時間を有することを確実にするためである。
【００８８】
一実施形態に従ったアプローチはまた、例えば各イベントプロセッサを容量の５０〜６０％で実行すること等によってイベントプロセッサを過剰分割する。そのようなアプローチは、各バケット内において、性能に著しく否定的な影響を有することなく、少なくとも１つまたは２つのイベントプロセッサが故障することを可能にする。故障したイベントプロセッサは、例えば各ホストが再起動する場合等、いずれは再び利用可能となるであろう。そのイベントプロセッサは、次いでハートビートを再度交換し始めることができ、それによってバケット内の他のイベントプロセッサが、自動的にそのイベントプロセッサを検出することができる。割り当てられた作業は、上述のように自動的に再分散することができ、それによってその作業はバケット内の利用可能なプロセッサのより大きなセットにわたり、比較的均等に分散される。
【００８９】
上述の故障事例に加えて、様々な実施形態に従ってアドレス指定することができる様々な他の故障モードが存在してもよい。例えば、一次複製インスタンスは再起動することができ、一次のためのホストマネージャがオンラインに戻る際、監視構成要素が二次複製に対して未だフェイルオーバーしていない場合、一次複製は二次複製としてオンラインに戻るため、それは、ＢＬＲＭステータスが「一次／二次」から「二次／二次」に変更したことをまず発見することになる。次いで、２つの複製のうちどちらが一次になるべきかを決定することはイベントプロセッサ（例えば、監視構成要素）次第になり、適切な一次への昇格（ｐｒｏｍｏｔｅＴｏＰｒｉｍａｒｙ（））のコールを出すことができる。二次複製インスタンスが再起動する場合、監視構成要素は二次が機能していないことに気付き、復旧のインスタンスをマークすることができる。しかしながら、一方で、二次複製が（再起動後に）オンラインに戻ると、二次復旧ワークフローはこれに気付き、二次複製のホストマネージャが再接続するよう試みることを要求することができる。これは、単純なインスタンス再起動シナリオのための新たな二次複製を作成する犠牲を払うこと避けることができる。非複製インスタンスが再起動すると、ホストマネージャは、インスタンスを昇格させるよう監視構成要素に要求することなく、自動的にそのステータスを二次から一次複製へ変換することができる。これは、非複製インスタンスのためのインスタンス再起動の復旧時間を短縮することができる。
【００９０】
一次複製が故障しオンラインに戻らない場合、監視構成要素は、一次故障を検出し、二次複製を新しい一次へ昇格させることができる。その後、監視構成要素は、ネットワーク管理組織（Ａｄｍｉｎ）データストア内のＲＤＳインスタンス状態を、「未決／劣化＿二次復旧要（ＰＥＮＤＩＮＧ／ＤＥＧＲＡＤＥＤ＿ＮＥＥＤ＿ＳＥＣＯＮＤＡＲＹ＿ＲＥＣＯＶＥＲＹ）」等の状態にあるようにマークすることができる。この状態は、復旧スイーパに適切な復旧ワークフローを始めさせることができる。復旧ワークフローは、両方の複製が生きているかどうかを判定することを試みることができる。古い一次複製が二次複製としてオンラインに戻った場合、例えば監視構成要素が複製を停止とマークするよう再起動に十分な時間がかかった場合、複製が完全に同期されると、ワークフローは古い一次複製を新しい一次複製に接続し、復旧がなされた、例えばデータベース状態ＯＫ等としてマークすることができる。しかしながら、古い一次が全く戻ってきていない場合、ワークフローは古いインスタンスを終了し、複製インスタンスを作成することに関して記載されたのと同一のステップを使用して二次複製を作成することができる。二次複製が故障すると、監視構成要素は故障を検出し、「未決／劣化＿二次復旧要（ＰＥＮＤＩＮＧ／ＤＥＧＲＡＤＥＤ＿ＮＥＥＤ＿ＳＥＣＯＮＤＡＲＹ＿ＲＥＣＯＶＥＲＹ）」または類似状態等を使用することによって、ネットワーク管理組織（Ａｄｍｉｎ）データストア内のインスタンス状態を、復旧ワークフローが作動する状態にあるとして、マークすることができる。データベースが何らかの理由でクラッシュする際、一次複製のホストマネージャは、ナニー（ｎａｎｎｙ）プロセスとして機能し、自動的にデータベースを再始動させることができる。
【００９１】
記載されるように、監視作業負荷の各分割は、１セットのイベントプロセッサによってカバーされてもよい。１セットのイベントプロセッサを用いて作業負荷の単一の分割をカバーすることは、イベントプロセッサのうちの１つが故障するか、または様々な種類の他のそのような問題のいくつかを経験するイベント内の残存しているイベントプロセッサにわたる監視量の再分散を可能にする。一実施形態において、イベントプロセッサの各グループは、バケット内または他のそのような分割内に含まれる。バケット内の各イベントプロセッサは、単一データプレーン内のインスタンスの範囲を処理すること、あるいはそのプレーン内のインスタンスをグループ化することに対して責任がある。故障検出プロセスは、故障が起こる場合、そのバケット内の他のイベントプロセッサは、故障したイベントプロセッサによって処理されていたインスタンスに対する責任を引き継ぐことを確実にするために使用することができる。少なくとも一実施形態における監視データストアは、イベントプロセッサが様々な顧客関連イベントのために集める情報と同様に、バケット内のイベントプロセッサのセットによって監視されるべき現在のアクティブデータインスタンスのリストを保持する。監視インスタンスの数が増加するにつれて、単一の監視データストアを越えて拡大縮小することが必要になる可能性がある。したがって、ｄｂ＿ポーリング＿リスト（ｄｂ＿ｐｏｌｌ＿ｌｉｓｔ）を含み、監視データストア内の各テーブルは分割されてもよい。
【００９２】
一実施形態において、イベントプロセッサは、以下の例の分割テーブルとともに展開される。
分割Ｉｄ                    ハッシュ範囲
Ｐ０                        ０〜１００００
Ｐ１                        １００００〜２００００
この分割構成は、イベントプロセッサホストに対する構成ファイルとして展開することができる。
【００９３】
与えられた作業負荷分割が、責任のあるイベントプロセッサのセットを、持続的なキャッチアップモードに残す著しく多数のイベントを生成する場合（つまり、割り付けられた健康状態のチェックを一定時間内に終わらせることができない）、追加のイベントプロセッサは、データストアを再分割する必要なく、その作業負荷分割に責任のあるセットへ追加することができる。そのような技術を使用して、性能の拡張性は、データの拡張性の問題とは区別することができる。例えば、イベントプロセッサがキャッチアップできない非常に多くのイベントを生成する単一の分割は、単一の分割が単一のデータストアが十分な記憶空間を提供しない非常に多くのイベントを生成する状況とは区別することができる。
【００９４】
イベントプロセッサおよびイベントプロセッサが割り付けられる分割のメンバシップは、イベントプロセッサメンバシップ構成ファイル等の位置に記憶することができる。メンバシップ設定情報は、グループ内（同一の分割またはバケット内等）のイベントプロセッサに展開されてもよく、以下の例の形式を有することができる。
＜ＥＰ識別子＞＜ＥＰホスト名＞＜終了ポイント＿ポート＞＜分割Ｉｄ＞
単一の分割が、複数のイベントプロセッサによってカバーされる際、各イベントプロセッサは、イベントプロセッサ識別子をソートすることによって、例えば、辞書編集またはハッシュベースのソートルーティーン等を使用することによって、バケット範囲を分割し、そのバケット範囲を一様に分ける。各イベントプロセッサは、監視するのに適切な範囲を独立的に判定する。
【００９５】
そのようなシステムにおいて、監視されるべきデータストアおよび／もしくはインスタンスのリストまたはセットが、時間とともに自動的に投入および更新されることを確実にすることもまた、重要であり得る。１つのアプローチは、データベースリストテーブルを作成することであるかもしれず、例えば、それは必要に応じて広まることができるインスタンスのスナップショット複製である。そのようなアプローチは、しかしながら、各適切な構成要素が最も最近のコピーを有することを確実にするのと同様に、維持することが困難である可能性がある。別のアプローチは、イベントプロセッサをデータプレーン構成要素を問い合わせることであってもよく、その後制御プレーン内に局所的に情報を記憶する。そのようなアプローチは、多くのメッセージトラフィックを作成することができ、維持および更新することが困難である可能性がある。一実施形態に従ったアプローチは、代わりに、各イベントプロセッサが「ステータス設定（ｓｅｔＳｔａｔｕｓ）」または類似のＡＰＩ等のインターフェースを映すことを可能にする。「作成」または「削除」のワークフローの一部として、例えば、タスクは、インスタンスを管理する責任があるか、または責任があったイベントプロセッサをコールするよう適切なホストマネージャに命令するワークフローの最後に追加することができる。ホストマネージャは、したがって、ワークフロー（または他のそのような動作）の結果としてステータスの変化がある時はいつでも、イベントプロセッサの「ステータス設定（ｓｅｔＳｔａｔｕｓ）」ＡＰＩを、ホストのステータスを設定するようコールすることができる。イベントプロセッサが「ステータス設定（ｓｅｔＳｔａｔｕｓ）」ＡＰＩを介してコールを受信するたびに、情報は、新しいホストを分割のセットに追加し、ホスト等をリムーブするためにローカルデータストア内に置かれる。ホストのための情報はまた、監視データストアまたは別の適切な永続的な位置へ書き込むことができる。
【００９６】
一実施形態において、現在のアクティブデータインスタンスの権限のあるリストは、ネットワーク管理組織（Ａｄｍｉｎ）データストア内に存在する。監視されるべきデータインスタンスのアクティブなリストは、「ｄｂ＿ポーリング＿リスト」テーブル等のテーブル内の監視データストア内に存在する。監視データストア内のインスタンスのステータスを追加、リムーブ、または更新するために、イベントプロセッサは、データストア識別子、データインスタンスに関連するパラメータ（例えば、インスタンス識別子およびＤＮＳアドレス）、およびインスタンスステータス（例えば、「追加」、「リムーブ」、または「更新」）等のパラメータを受け入れる「ホスト更新」ＡＰＩを映す。イベントプロセッサがこのコールを受信する際、イベントプロセッサはｄｂ＿ポーリング＿リストテーブルへ適切な変更（例えば、エントリーを追加、リムーブ、または更新すること）を加える。例えば、顧客が、データストアｉｄの「ｉｄ１」を用いてデータストアを作成する要求を投入する場合、データストアを作成するためのワークフローは、必要なリソースをプロビジョニングし、データストアを構成すると、ｉｄ１の状態をネットワーク管理組織（Ａｄｍｉｎ）データストア内で「利用可能」としてマークする。作成データベースワークフロータスクの最後のステップとして、ホスト更新（ｕｐｄａｔｅＨｏｓｔ）ＡＰＩは、内部仮想ＩＰを介して到達すること等によって、データストア（およびそのインスタンス）を監視ワークフローに追加するために、イベントプロセッサのうちの１つにおいて起動することができる。監視ステータスの更新をプロビジョニングワークフローの最後の（または少なくとも最後近くの）ステップにすることによって、ＲＤＳデータストアの作成、削除、または修正の利用可能性は、監視データストアの利用可能性から切り離される。
【００９７】
ホストマネージャが、監視されるべきアクティブインスタンスのステータスを設定すると、責任のあるイベントプロセッサは、本明細書の他の場所に記載されるように、定期的にインスタンスのためのホストマネージャにピングを打つことができる。インスタンスが利用できない、例えばホスト機械がクラッシュしているまたは再起動しているため等の場合、イベントプロセッサはインスタンスに対する応答を得ず、ネットワーク管理組織（Ａｄｍｉｎ）データストアへ潜在的な問題の情報を書き込むであろう。スイーパは、その情報を検出し、適切な復旧ワークフローを生じさせ、実行させるであろう。一実施形態において、復旧ワークフローは、まず、データストアまたはデータインスタンスのメトリクスの履歴、例えばインスタンスのＩ／Ｏエラーの履歴の詳細情報等を調べる。ワークフローは、次いで、インスタンスが停止しているかどうか、例えばどこに接続エラーがあるか、あるいは接続に問題はないが増加したＩ／Ｏエラー数がある等を、自動的に判定するよう試み、特定のボリュームサポートインスタンスに潜在的な問題があることを示す。ワークフローのタスクは、問題を自動的に判定および／または分離するよう試みることができ、そこには多数の異なる構成要素に対して起こる多数の異なる問題がある。そのような判定は、そのような問題からの復旧と同様に、どうでもよい問題ではない。
【００９８】
しかしながら、故障から自動的に復旧することが望ましくない可能性のある状況もあり得る。例えば、全体のデータセンタが故障し、何千ものデータストアが利用不可能になることがある。これらのデータストア全てを実質的に同時に復旧しようと試みることは望ましくない場合がある。一実施形態において、スイーパ（または、制御プレーンの別の構成要素）は、エラーの最大数を用いて構成されていてもよく、または特定の種類のワークフローを同時に実行していてもよい。多数のワークフローが特定の数または閾値を上回る場合、例えばメッセージまたは他のそのような通知が送信されるか、そうでなければ操作者またはＤＢＡのために生成されてもよく、そうすることで経験のあるユーザは、その状況を解決するのに最適なアプローチを判定することができる。一実施形態において、スイーパは、いかなる時も多くとも同じ種類の特定された数、例えば既定の種類の１０のワークフロー等を実行するが、例えば２５等の第２の数、または同じ種類のワークフローが要求されるまでは、警報を生成しないであろう。一実施形態に従ったシステムにおいて、ＤＢＡまたは他の認定操作者が監視プロセス（１つまたは複数）の状態を評価することができ、復旧動作を手動で実行することができる、操作可能なサービスダッシュボードを提供する。そのようなインターフェースを使用して、本明細書に記載されるように、ＤＢＡは、特定の復旧動作を実行するためにワークフローを開始するオプションを選択することができる。インターフェースは、制御プレーンがデータプレーンのデータパス内にないとしても、複数の全く異なるデータベースエンジンおよびシステムと動作するように制御プレーンとともに使用され得る。制御プレーンは、例えばエンジンのそれぞれに対して、エラーメッセージおよびログを監視することができる。そのようなアプローチはまた、各データストアを全体として監視することを可能にし、同時にデータストアの複製を監視している。異なる復旧は、したがって、複製の状態等に基づいて実行することができる。
【００９９】
データストアまたはデータインスタンスの非可用性または信頼性の欠如をもたらし得る様々な種類の故障が存在し得ることを認識されたい。例えば、ホストデバイスは、故障または再起動する可能性があるか、あるいはインスタンスを管理するホストマネージャアプリケーションに問題がある場合がある。例えば、コアダンプまたは区分け違反（ＳｅｇＶ）の例外等、データストアに問題がある場合もあり得る。Ｉ／Ｏ操作もしくは通信経路に問題があるか、またはデータストアをホスティイングするインスタンスの故障の場合もまたあり得る。論理ボリュームの故障、ネットワーク停電、またはデータゾーン故障等の様々な他の種類の故障が存在することもまたあり得る。異なるワークフローは、異なる故障の種類を判定し、復旧するよう試みるために使用することができる。一例において、一実施形態におけるホストマネージャは、各データインスタンスに対するゲートウェイであり、このホストマネージャの故障は本質的にそのインスタンス上に制御が全くないことを可能にさせる。メモリが足りなくなっているＴｏｍｃａｔプロセス等の故障をアドレス指定するために、制御プレーンの監視構成要素は、必要があればＴｏｍｃａｔが再始動されることを確実にする。監視システムは、不必要なエラーまたはエラー検出を回避するために、再始動を調節することができる。
【０１００】
さらに、記載されるように、故障のサイズまたは規模等、他の要因も考慮しなければならないため、単に故障を検出し、そこから復旧するだけでは十分ではない。例えば、データストアをホスティングする単一クラウドインスタンス故障の復旧動作は、実質的に全体のデータゾーンの故障をアドレス指定する復旧動作とは異なる場合がある。より大きな問題に対しては、複数の故障は、復旧動作が様々なインスタンスを個別に同時に復旧するよう試みることによって既存の問題を混合させないように、相関され、分析される必要がある場合がある。いくつかの場合においては、同時のプロセスの数が限定される場合だけでなく、全てのデータが失われず、後続の復旧動作に起因して修正される必要が出てくるような復旧動作がとられないように、プロセスの順序付けが制御され得る場合にも、段階的な復旧を実行すること望ましい可能性がある。いくつかの場合において、復旧プロセスを可能な限りローカライズすることが望ましい場合もあり得る。可能な場合には、故障を安全な方法でローカルにアドレス指定することは、少なくともいくつかの実施形態において有益であり得る。例えば、ホストマネージャまたはデータプロセスの故障等の単純な故障に対するローカルの復旧動作は、全般的なＲＤＳシステムのネットワーク管理組織（Ａｄｍｉｎ）スタックによって実行される動作であることが好まれる場合がある。
【０１０１】
データインスタンス、データストア、またはＩ／Ｏプロセスが故障するには様々な理由もあり得、それぞれ異なる復旧動作を要求する可能性がある。例えば、データストアバグは、データストアを故障させるか、または少なくとも著しい数の読み込み／書き込みエラーを生成する。データストアまたはインスタンスはまた、過負荷、不良ブロック、または他のそのような状況のために故障することもある。データストアのクラッシュをもたらす不適切な問い合わせ等のユーザに誘発されたエラーもまた存在し得る。他の場合において、データストアのログボリュームは、埋められるか、または破損されている可能性がある。これらおよび他の種類の故障をアドレス指定するために、データプロセスは、持続的にホストマネージャによって監視され得る。記載されるように、各ホストマネージャは、例えばステータス取得コマンドを実行することによって（例えば、ＭｙＳＱＬに対して、これはｂｉｎ／ｍｙｓｑｌ＿ａｄｍｉｎステータスの形状をとることができる）データストアまたはインスタンスのステータスをチェックするステータス監視構成要素を有することができる。このステータス監視構成要素は、定期的にステータスをチェックし、インスタンスが利用できなくなる場合、インスタンスを再始動させるか、そうでなければアドレス指定することができる。インスタンスが繰り返し利用できなくなるか、他のそのようなエラーを経験する場合、ステータス監視構成要素は、エラーを訂正するよう試みることを止め、情報を制御プレーン内の監視またはネットワーク管理組織データストアへ書き込ませることができる。
【０１０２】
データストアエラーおよびＩ／Ｏクラッシュを検出するために、データストアエラーログおよび／またはカーネルログは、いくつかの実施形態において監視される可能性がある。各ホストマネージャは、これら２つ（または他の）エラーログ内の特定のエラー種に対して持続的にスキャンする別のモジュールを実行し、関連するメトリクスを生成することができる。各エラー種に対して、所定の閾値を設定することができ、それを超えると、分析および可能な復旧のために、エラーは操作者に送信されることになる。
【０１０３】
一実施形態に従った故障検出機構は、適用される多数の制限を有する。例えば、監視構成要素は直線的に拡大縮小するよう構成することができ、それによって、例えばデータインスタンスの数がイベントプロセッサのバケットがポーリングするよう設定されるホストの数を上回る際に、追加の監視構成要素が要望通り単に追加されるようになる。さらに、例えばデータインスタンスを分割し、イベントプロセッサのうちの１つに対する各分割の監視所有者を割り付けることによって、全てのデータインスタンスが持続的に監視されるように確立することができる。記載されるように、イベントプロセッサが何らかの理由で故障する場合、その故障したイベントプロセッサによって所有および監視されていた分割は、同一バケット内のプロセッサ等他の利用可能なイベントプロセッサに、均等に再分散することができる。さらに、データベースインスタンスのリストは、ＲＤＳ顧客がデータストアおよび／またはインスタンスを作成ならびに削除する際にワークフローにタスクを追加することによって最新に保つことができる。
【０１０４】
データストア分割
高い拡張性の分散型システムにおいてよく知られるように、データストア内の分割は、データストアシステムが存在する物理システムの制限へ拡張するのみである。この制限のために、システムが単一のデータ記憶システム内、ならびに多数のデータ記憶システムにわたっての両方において拡大縮小することができるような方法で、システムを構造することが目立って望ましい場合がある。特異的なデータ記憶システムにわたるデータの水平分割は、イベントストレージ上の著しい要望を処理することができる高い拡張性のシステムに貢献することができる。
【０１０５】
一実施形態に従ったシステムは、データベースインスタンスのリスト（ｄｂ＿ポーリング＿リスト）、関連イベント（ｄｂ＿イベントテーブル）、およびセキュリティグループイベントテーブルを含むデータテーブルを分割するための分割鍵として顧客＿ｉｄを利用する。いくつかのイベントは単一のデータストアに制限されず、特定のデータストアに関係することさえない場合があるため、データストア識別子よりも顧客識別子を使用することが有利になることがある。例えば、セキュリティグループ内の変更は、いかなるデータにも直接に適用しないが、顧客可視イベント（つまり、記述イベントＡＰＩ（ＤｅｓｃｒｉｂｅＥｖｅｎｔ  ＡＰＩ）を使用して読み出し可能なもの）として記憶される必要がある場合がある。さらに、単一の顧客のイベントは、いくつかの実施形態においては、イベントデータは１４日間等の限定された期間のみ保持されるため、単一のデータストアの記憶空間を越えて成長することはない。
【０１０６】
水平データストア分割にわたってデータセットを分割することを処理するためには、バケット分割を使用する等、多数の方法がある。バケット分割は、分割されているデータとそのデータが記憶されている分割との間に抽象層を提供する。この抽象層は、分割データの設置を判定するためのハッシュ機構を使用するためのアプリケーションを可能にしながらも、経時的なデータの移行を伴う新しい分割の追加等、分割のより容易な操作可能な管理を可能にさせる。本明細書に記載される、バケット分割システムの実装は、特定の実施形態に特有の構成要素を含むが、全般的な概念は、明らかであるように多数の異なる使用事例に適用できる。
【０１０７】
バケット分割を実装するために、アプリケーションに利用可能であるようなバケットの固定数が決定されてもよい。バケットの数は、アプリケーションの寿命にわたって固定されたままでもよく、十分に大きい数を選択することが、特定の実施形態においては重要になり得る。バケットの数は、全てのバケットにわたって均等に負荷を分散させる能力を反映することができ、少数の物理的な分割に独立して割り付けることができる。同一のバケットに割り付けられた独立したインスタンスが多すぎる場合は、単一の分割内の複数のバケットを効率的に記憶することが問題となり得る。固定数のバケットは、分割されるデータと分割そのものとの中間層として機能することができる。その層化の第１のステップは、データの異なる一片が様々なバケットにマップする方法を見つけ出すことである。上述のように、データの分割鍵は、顧客識別子であってもよい。効率的かつ一貫的なハッシュアルゴリズムは、独立したバケットに直接割り付けることができる値を提供するために使用することができる。顧客識別子が、バケットに割り付けられた値をハッシュする場合はいつでも、その識別子はデータの寿命の間そのバケット内にあり続けることができる。
【０１０８】
この例において、バットは独立した作業負荷分割に割り付けられる。常に分割よりも多いバケットが存在し、そのためマッピングは多数の異なるバケットを独立した分割に割り付けるために使用することができる。割り付け構成を簡潔にするために、バケット数の範囲は、バケットを独立した分割に割り付けるために使用することができる。以下に分割の割り付けがどのようにして動作するかを示すテーブル例を図示する。
【０１０９】
分割１＝｛ｌ〜２５０００｝
分割２＝｛２５００１〜５００００｝
【０１１０】
この例において、バケット番号１から２５，０００は、「分割１」に割り付けられ、一方でバケット番号２５，００１から５０，０００は、「分割２」に割り付けられている。データがシステムに追加される必要があり、顧客識別子のハッシュがワークフローインスタンスをバケット１００にマップする場合はいつでも、例えば、その顧客に関連するあらゆるデータ（データストアおよびセキュリティグループを含む）は物理的に「分割１」内にあるテーブルへ挿入することができる。そのようなアプローチは、顧客のデータベースまたはセキュリティグループに関する任意の情報を読み込むために使用することができ、識別子がバケット１００にハッシュする与えられた顧客に対するイベントの要求は、「分割１」から読み込まれる。
【０１１１】
上記の例は、変化されていない分割へのバケットの初期の割り付けを伴う比較的単純な事例を扱う。しかしながら、時として、他の分割上の負担を軽減するために、新しい分割がシステムに追加される必要があるであろう。上記のこの例を使用して、新しい分割「分割３」を他の２つの分割から負荷を取り去るために追加することができる。
【０１１２】
分割１＝｛ｌ〜１６６６６｝
分割２＝｛３３３３３〜５００００｝
分割３＝｛１６６６７〜３３３３３｝
【０１１３】
見られるように、８３３４個のバケット（番号１６６６７から２５０００）が「分割１」から取り出され、「分割３」に再割り付けされた。さらに、８３３３個の追加バケット（番号２５００１から３３３３３）が、「分割２」から取り出され、「分割３」に再割り付けされた。この再割り付けは、最も多忙な、または最も満杯のバケットに基づいていたかもしれないが、この例においては、分割にわたる比較的均等なバケットの再分散があった。
【０１１４】
バケット割り付けが変化するにつれて、物理的な分割に存在しているデータは、影響を受けることがある。上記の例において、バケット１００は、識別子が１００までハッシュした顧客の情報を記憶するために使用された。この再分割シナリオにおいて、データは、バケット１００が「分割１」上に留まるため、影響を受けない場合がある。バケット１１０００内にデータがあったかもしれないが、しかしながら、再分割以前に書き込まれたいずれのデータも「分割１」内にあるが、再分割以後に書き込まれたあらゆるデータは「分割３」内に存在するだろう。１つの分割内に存在する以前のデータと、別の分割に存在する現在のデータとを用いてこの問題を解消するために、システムは１つより多くの分割がバケットに割り付けられることを可能にする。与えられたバケットは、現在の分割および以前の分割の、少なくとも２つの分割を有することができる。本例において、再分割はバケット１０００１から１５０００が、現在の分割として「分割３」、以前の分割として「分割１」の、割り付けられた２つの分割を有することをもたらす。記載のように、バケット１１０００のあらゆる新しいデータは現在の分割内にあり、一方で再割り付けに先立って書き込まれたあらゆるデータは以前の分割内にある。イベントの問い合わせまたは任意の情報がバケット１１０００にマップする際、そのデータの現在の分割をチェックすることは重要であり、記録がそこにも存在し得るため、以前の分割をチェックすることも同様に重要である。バケット内の複数の分割検索のそのようなサポートは、与えられたバケットの以前の分割内で終了するようなインスタンスのミスの潜在的な犠牲を招く場合がある。あらゆる新たに作成されたイベントが現在の分割に書き込まれているため、しかしながら、ミスの犠牲は、再分割が起こる際に動作しているワークフローインスタンス、または閉ざされたワークフローにのみ負担される。新たに作成された好ましいイベントは、依然として再分割を効率的に行う柔軟性を可能にしながらも、性能を改善することができる。
【０１１５】
上述のように、様々な実施形態は、多種多様な操作環境において実装することができ、その操作環境は、いくつかの場合には、多数のアプリケーションのいずれかを操作するために使用することができる１つ以上のユーザコンピュータ、コンピューティングデバイス、またはプロセッシングデバイスを含むことができる。ユーザまたはクライアントデバイスは、標準のオペレーティングシステムを実行するデスクトップまたはラップトップコンピュータ等の多数の汎用パーソナルコンピュータのいずれかを含むことができ、同様にモバイルソフトウェアを実行するセルラー、無線、およびハンドヘルドのデバイス、多数のネットワークおよびメッセージプロトコルをサポートすることができるものを含むことができる。そのようなシステムはまた、市販のオペレーティングシステムのいずれの種類をも実行する多数のワークステーション、ならびに開発およびデータベース管理等の目的の他の既知のアプリケーションを含むことができる。これらのデバイスはまた、ダミーターミナル、シンクライアント、ゲーム機等の他の電子通信デバイス、およびネットワーク経由で通信することが可能な他のデバイスを含むことができる。
【０１１６】
様々な態様はまた、例えばサービス指向アーキテクチャの一部として等、少なくとも１つのサービスまたはウェブサービスの一部として実装することができる。ウェブサービス等のサービスは、例えば拡張マークアップ言語（ＸＭＬ）形式およびＳＯＡＰ（「簡易オブジェクトアクセスプロトコル（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｌ）」から導き出される）等の適切なプロトコルを使用して交換されたメッセージを使用して等、任意の適切な種類のメッセージングを使用して通信することができる。そのようなサービスによって提供される、または実行されるプロセスは、ウェブサービス記述言語（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）（ＷＳＤＬ）等の任意の適切な言語で書き込むことができる。ＷＳＤＬ等の言語を使用することは、様々なＳＯＡＰの枠組みにおいてクライアント側のコードの自動生成等の機能性を考慮する。
【０１１７】
ほとんどの実施形態は、ＴＣＰ／ＩＰ、ＯＳＩ、ＦＴＰ、ＵＰｎＰ、ＮＦＳ、ＣＩＦＳ、およびＡｐｐｌｅＴａｌｋ等の商用のプロトコルの種類のうち任意のものを使用して通信をサポートすることで当業者に知られている少なくとも１つのネットワークを利用する。ネットワークは、例えば、ローカルエリアネットワーク、広域ネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、ワイヤレスネットワーク、およびそれらの任意の組み合わせであってもよい。
【０１１８】
ウェブサーバを利用する実施形態において、ウェブサーバは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データサーバ、Ｊａｖａサーバ、およびビジネスアプリケーションサーバ等のいずれの種類のサーバまたは中間階層アプリケーションをも実行することができる。サーバ（１つまたは複数）はまた、ユーザデバイスからの要求に応答して、Ｊａｖａ（登録商標）、Ｃ、Ｃ＃もしくはＣ＋＋、またはＰｅｒｌ、Ｐｙｔｈｏｎ、もしくはＴＣＬ等の任意のスクリプト言語、ならびにそれらの組み合わせ等の、任意のプログラム言語で書かれた１つ以上のスクリプトあるいはプログラムとして実装されている可能性のある１つ以上のウェブアプリケーションを実行すること等によって、プログラムまたはスクリプトを実行する能力がある。サーバ（１つまたは複数）はまた、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、およびＩＢＭ（登録商標）からの商用のものを含むが、それらに限定されないデータベースサーバを含んでもよい。
【０１１９】
環境は、上述のように、様々なデータストアならびに他のメモリおよび記憶媒体を含むことができる。これらは、コンピュータの１つ以上に対してローカルな記憶媒体上（および／または、その中にある）、あるいはネットワークにわたるコンピュータのいくつかまたは全てから離れた記憶媒体上等の、様々な場所に存在することができる。実施形態の特定のセットにおいて、情報は、当業者によく知られているストレージエリアネットワーク（「ＳＡＮ」）内に存在することがある。同様に、コンピュータ、サーバ、または他のネットワークデバイスに属する機能を実行するためのいずれかの必要なファイルは、適宜、ローカルおよび／または遠隔に記憶されてもよい。システムがコンピュータ化されたデバイスを含む場合、そのようなデバイスそれぞれは、バスを経由して電気的に接続されたハードウェア要素を含むことができ、その要素は、例えば、少なくとも１つの中央処理装置（ＣＰＵ）、少なくとも１つの入力デバイス（例えば、マウス、キーボード、コントローラ、タッチスクリーン、またはキーパッド）、および少なくとも１つの出力デバイス（例えば、ディスプレイデバイス、プリンタ、またはスピーカ）を含む。そのようなシステムはまた、ディスクドライブ、光学記憶デバイス、ランダムアクセスメモリ（「ＲＡＭ」）または読み取り専用メモリ（「ＲＯＭ」）等のソリッドステート記憶デバイス、ならびにリムーバブル媒体デバイス、メモリカード、フラッシュカード等の１つ以上の記憶デバイスを、含むことができる。
【０１２０】
そのようなデバイスはまた、コンピュータ可読の記憶媒体リーダ、通信デバイス（例えば、モデム、ネットワークカード（無線または有線）、赤外線通信デバイス等）、および上記のようなワーキングメモリを含むことができる。コンピュータ可読の記憶媒体リーダは、遠隔の、ローカルの、固定の、および／または取り外し可能な記憶デバイスを代表するコンピュータ可読の記憶媒体、ならびに一時的および／またはより恒久的に、コンピュータ可読情報を含み、記憶し、伝送し、読み出す記憶媒体と接続することができるか、またはそれらを受信するように構成することができる。システムおよび様々なデバイスはまた、典型的に、クライアントアプリケーションまたはウェブブラウザ等のオペレーティングシステムおよびアプリケーションプログラムを含む、多数のソフトウェアアプリケーション、モジュール、サービス、または少なくとも１つのワーキングメモリデバイス内に位置する他の要素を含むであろう。代替の実施形態は上記からの多数の変形を有することを認識されたい。例えば、カスタマイズされたハードウェアも使用することができる、および／または特定の要素が、ハードウェア、ソフトウェア（アプレット等のポータブルソフトウェアを含む）、または両方において実装されることもある。さらに、ネットワーク入力／出力デバイス等の他のコンピューティングデバイスへの接続が採用される場合もある。
【０１２１】
コード、またはコード部分を含むための記憶媒体およびコンピュータ可読媒体は、当技術分野で既知または使用される任意の適切な媒体を含むことができ、その媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、もしくは他のデータ等の情報の記憶および伝送のための任意の方法または技術で実装された揮発性および不揮発性媒体、取り外し可能および取り外し不可能な媒体などの記憶媒体および通信媒体であるがこれらに限定されず、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）もしくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、システムデバイスによってアクセスされ得る任意の他の媒体を含む。本開示および本明細書に提供される技術に基づいて、当業者は、様々な実施形態を実装するための他の手段および／または方法を認識するであろう。
【０１２２】
本明細書および図面は、したがって、限定的な意味ではなく、むしろ実例的な意味として捉えられるべきである。しかしながら、請求項に記載の本発明のより広い精神と範囲を逸脱しない範囲で、そこに様々な修正および変更が成されることは明白であろう。
【０１２３】
第１項。
制御環境から関係データベースインスタンスのための複製されたインスタンスの復旧を管理するコンピュータ実装方法であって、
実行可能な命令を用いて構成される１つ以上のコンピュータシステムの制御下で、
別個の制御環境の監視構成要素を使用して、データベース環境内の一次インスタンス複製および二次インスタンス複製と定期的に通信することであって、少なくとも１つの監視構成要素によって受信された各応答は、第１および第２のインスタンス複製のうちのそれぞれ１つのためのステータス情報およびデータ世代情報を含み、一次インスタンス複製のデータ更新は、単一のデータ世代のために二次インスタンス複製に同期的に複製される、通信することと、
第１および第２のインスタンス複製のうちの１つと通信することができない少なくとも１つの監視構成要素に応答して、第１および第２のインスタンス複製が互いに通信することが可能であるかどうか、ならびに第１および第２のインスタンス複製が共通のデータ世代情報を有するかどうかを判定することと、
監視構成要素が最短期間に一次複製と通信することができない場合、二次インスタンス複製が一次複製と通信することができない場合、ならびに第２のインスタンス複製が一次複製の最新の既知の状態と同一のデータ世代情報を有する場合、二次インスタンス複製に関係データベースインスタンスのための新しい一次複製になるフェイルオーバー操作を実行させることと、
監視構成要素が最短期間に二次複製と通信することができない場合、ならびに一次インスタンス複製が二次複製と通信することができない場合、関係データベースインスタンスのための新しい二次インスタンス複製を生成する、二次インスタンス複製復旧プロセスを実行させることと、
監視構成要素が最短期間に一次複製および二次複製のどちらともと通信することができない場合、一次および二次インスタンス複製が互いに通信することが可能である場合、ならびに一次および二次インスタンス複製が同一のデータ世代情報を有する場合、フェイルオーバーまたは復旧操作が、一次および二次インスタンス複製のために実行されないことと、を含む、コンピュータ実装方法。
【０１２４】
第２項。
監視構成要素が最短期間に一次複製と通信することができない場合、二次インスタンス複製が一次複製と通信することができない場合、ならびに第２のインスタンス複製が一次複製の最新の既知の状態と異なるデータ世代情報を有する場合、一次インスタンス複製のために特定の時点への復旧操作を実行させることをさらに含む、第１項に記載のコンピュータ実装方法。
【０１２５】
第３項。
監視構成要素が最短期間に一次複製と通信することができない場合、ならびに二次インスタンス複製が一次複製と通信することができない場合、一次インスタンス複製を終了させることをさらに含む、第１項に記載のコンピュータ実装方法。
【０１２６】
第４項。
ユーザは、ユーザに現在の一次インスタンス複製と通信することを可能にする別名を提供され、フェイルオーバー操作が、二次インスタンス複製を、新しい現在の一次インスタンス複製にさせる場合を含む、第１項に記載のコンピュータ実装方法。
【０１２７】
第５項。
別個の制御環境を使用して、データベース環境内の複製データベースインスタンスを管理するコンピュータ実装方法であって、
実行可能な命令を用いて構成される１つ以上のコンピュータシステムの制御下で、
別個の制御環境の監視構成要素を使用して、データベース環境内の一次インスタンス複製および二次インスタンス複製のそれぞれに対する状態情報を監視することと、
監視構成要素が、第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、
第１および第２のインスタンス複製が、互いに通信することが可能であるかどうか、ならびに第１および第２のインスタンス複製が、共通のデータ世代識別子を有するかどうかを含む、故障情報を判定することと、
故障情報に少なくとも部分的に基づき、制御環境内で実行されるワークフローを決定することであって、ワークフローは、監視構成要素が第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、データベース環境内で実行される１つ以上のタスクを含む、判定することと、
制御環境内でワークフローを実行することと、を含む、コンピュータ実装方法。
【０１２８】
第６項。
ワークフローは、二次インスタンス複製に、監視構成要素が最短期間に一次複製と通信することができない場合、二次インスタンス複製が一次複製と通信することができない場合、ならびに第２のインスタンス複製が一次複製の最新の既知の状態と共通のデータ世代識別子を有する場合、二次インスタンス複製に関係データベースインスタンスに対する新しい一次複製となるフェイルオーバー操作を実行させるタスクを含む、第５項に記載のコンピュータ実装方法。
【０１２９】
第７項。
フェイルオーバー操作を実行することは、ファイルシステムをマウントすることと、新しい一次複製のためのデータベースを始動することと、をさらに含む、第６項に記載のコンピュータ実装方法。
【０１３０】
第８項。
ワークフローは、監視構成要素が最短期間に二次複製と通信することができない場合、ならびに一次インスタンス複製が二次複製と通信することができない場合、関係データベースインスタンスに対する新しい二次インスタンス複製を生成する、二次インスタンス複製復旧プロセスを実行させるタスクを含む、第５項に記載のコンピュータ実装方法。
【０１３１】
第９項。
ワークフローは、監視構成要素が最短期間に一次複製および二次複製のうちどちらともと通信することができない場合、一次および二次インスタンス複製が互いに通信することが可能である場合、ならびに一次および二次インスタンス複製が共通のデータ世代識別子を有する場合、フェイルオーバーまたは復旧操作を実行することなしに、制御環境内のデータストアに情報を記憶するタスクを含む、第５項に記載のコンピュータ実装方法。
【０１３２】
第１０項。
第１および第２のインスタンス複製は、単一のデータゾーン内、別個の地理的な位置における別個のデータゾーン内、複数の地理的な位置にわたる単一のデータゾーン内、または単一の地理的な領域内の複数のデータゾーンにわたってプロビジョニングされる、第５項に記載のコンピュータ実装方法。
【０１３３】
第１１項。
少なくとも１つの監視構成要素は、第３のデータゾーン内または地理的な位置、あるいは第１もしくは第２のデータゾーンまたは地理的な位置のうちの１つに配置される、第１０項に記載のコンピュータ実装方法。
【０１３４】
第１２項。
ユーザは、ユーザが現在の一次インスタンス複製と通信することを可能にする別名を提供され、フェイルオーバー操作が、二次インスタンス複製を、新しい現在の一次インスタンス複製にさせる場合を含む、第５項に記載のコンピュータ実装方法。
【０１３５】
第１３項。
制御環境内の第１および第２のインスタンス複製のための状態情報およびデータ世代識別子を制御環境に記憶することをさらに含む、第５項に記載のコンピュータ実装方法。
【０１３６】
第１４項。
第１および第２のインスタンス複製のそれぞれは、データベース環境内の別個のデータインスタンス上で動作され、各データインスタンスは、１つ以上の専用ブロック記憶ボリュームに付けられる、第５項に記載のコンピュータ実装方法。
【０１３７】
第１５項。
第１のインスタンス複製と第２のインスタンス複製との１つ以上の専用ブロック記憶ボリュームの間のデータを、同期的に複製するよう操作可能なブロックレベル複製機構を使用して、一次インスタンス複製から二次インスタンス複製へデータを同期的に複製することをさらに含む、第１４項に記載のコンピュータ実装方法。
【０１３８】
第１６項。
一次インスタンス複製は、顧客のための関係データベースを実行している、第５項に記載のコンピュータ実装方法。
【０１３９】
第１７項。
別個の制御環境を使用して、データベース環境内の複製データベースインスタンスを管理するためのシステムであって、
プロセッサと、
メモリデバイスであって、プロセッサによって実行されると、プロセッサに、
別個の制御環境の少なくとも１つの監視構成要素を使用して、データベース環境内の一次インスタンス複製および二次インスタンス複製のそれぞれに対する状態情報を監視させることと、
少なくとも１つの監視構成要素が、第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、
第１および第２のインスタンス複製が互いに通信することが可能かどうか、ならびに第１および第２のインスタンス複製が共通のデータ世代識別子を有するかどうかを含む故障情報を判定することと、
故障情報に少なくとも部分的に基づき、制御環境内で実行されるワークフローを判定することであって、ワークフローは、監視構成要素が第１および第２のインスタンス複製のうち１つと通信することができないことに応答して、データベース環境内で実行される１つ以上のタスクを含む、判定することと、
制御環境内でワークフローを実行することと、を行わせる命令を含む、メモリデバイスと、を備える、システム。
【０１４０】
第１８項。
ワークフローは、二次インスタンス複製にフェイルオーバー操作を実行させるタスクを含み、監視構成要素が最短期間に一次複製と通信することができない場合、二次インスタンス複製が一次複製と通信することができない場合、ならびに第１および第２のインスタンス複製が、一次複製の最新の既知の状態で共通のデータ世代識別子を有する場合、関係データベースインスタンスに対する新しい一次複製になる、第１７項に記載のシステム。
【０１４１】
第１９項。
ワークフローは、監視構成要素が最短期間に二次複製と通信することができない場合、ならびに一次インスタンス複製が二次複製と通信することができない場合、関係データベースインスタンスに対する新しい二次インスタンス複製を生成する、二次インスタンス複製復旧プロセスを実行させるタスクを含む、第１７項に記載のシステム。
【０１４２】
第２０項。
ワークフローは、監視構成要素が最短期間に一次複製および二次複製のどちらともと通信することができない場合、一次および二次インスタンス複製が互いに通信することが可能である場合、ならびに一次および二次インスタンス複製が共通データ世代識別子を有する場合、フェイルオーバーまたは復旧操作を実行することなしに、制御環境内のデータストアに情報を記憶するタスクを含む、第１７項に記載のシステム。
【０１４３】
第２１項。
第１および第２のインスタンス複製は、単一のデータゾーン内、別個の地理的な位置における別個のデータゾーン内、複数の地理的な位置にわたる単一のデータゾーン内、または複数のデータゾーンにわたる単一の地理的な領域内にプロビジョニングされる、第１７項に記載のシステム。
【０１４４】
第２２項。
ユーザは、ユーザが現在の一次インスタンス複製と通信することを可能にする別名を提供され、フェイルオーバー操作が、二次インスタンス複製を新しい現在の一次インスタンス複製にする場合を含む、第１７項に記載のシステム。
【０１４５】
第２３項。
別個の制御環境を使用して、データベース環境内複製データベースインスタンスを管理する命令を記憶するコンピュータ可読記憶媒体であって、プロセッサによって実行されると、プロセッサに、
別個の制御環境の少なくとも１つの監視構成要素を使用して、データベース環境内の一次インスタンス複製および二次インスタンス複製のそれぞれのための状態情報を監視させることと、
少なくとも１つの監視構成要素が、第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、
第１および第２のインスタンス複製が互いに通信することが可能であるかどうか、ならびに第１および第２のインスタンス複製が共通のデータ世代識別子を有するかどうかを含む、故障情報を判定することと、
故障情報に少なくとも部分的に基づき、制御環境内で実行されるワークフローを判定することであって、そのワークフローは、監視構成要素が第１および第２のインスタンス複製のうちの１つと通信することができないことに応答して、データベース環境内で実行される１つ以上のタスクを含むワークフローを判定することと、
制御環境内でワークフローを実行することと、を行わせる命令を含む、コンピュータ可読記憶媒体。
【０１４６】
第２４項。
ワークフローは、二次インスタンス複製にフェイルオーバー操作を実行させるタスクを含み、監視構成要素が最短期間に一次複製と通信することができない場合、二次インスタンス複製が一次複製と通信することができない場合、ならびに第１および第２のインスタンス複製が、次複製の最新の既知の状態において共通のデータ世代識別子を有する場合、関係データベースインスタンスに対する新しい一次複製になる、第２３項に記載のコンピュータ可読記憶媒体。
【０１４７】
第２５項。
ワークフローは、監視構成要素が最短期間に二次複製と通信することができない場合、ならびに一次インスタンス複製が二次複製と通信することができない場合、関係データベースインスタンスに対する新しい二次インスタンス複製を生成する、二次インスタンス複製復旧プロセスを実行させるタスクを含む、第２３項に記載のコンピュータ可読記憶媒体。
【０１４８】
第２６項。
ワークフローは、監視構成要素が最短期間に一次複製および二次複製のどちらともと通信することができない場合、一次および二次インスタンス複製が互いに通信することが可能である場合、ならびに一次および二次インスタンス複製が共通のデータ世代識別子を有する場合、フェイルオーバーまたは復旧操作を実行することなく、制御環境内のデータストアに情報を記憶するタスクを含む、第２３項に記載のコンピュータ可読記憶媒体。
【０１４９】
第２７項。
第１および第２のインスタンス複製は、単一のデータゾーン内、別個の地理的な位置における別個のデータゾーン内、複数の地理的な位置にわたる単一のデータゾーン内、または単一の地理的な領域内の複数のデータゾーンにわたってプロビジョニングされる、第２３項に記載のコンピュータ可読記憶媒体。
【図１】
0005529972.tif 000002
【図２】
0005529972.tif 000003
【図３】
0005529972.tif 000004
【図４】
0005529972.tif 000005
【図５】
0005529972.tif 000006
【図６】
0005529972.tif 000007
【図７】
0005529972.tif 000008
【図８】
0005529972.tif 000009
【図９】
0005529972.tif 000010
【図１０】
0005529972.tif 000011
【図１１】
0005529972.tif 000012