JP5443614B2 - 複製されたデータインスタンスのモニタリング - Google Patents

Description

本発明は、クラウドコンピューティングに関する。

インターネットのようなネットワークで可能になるアプリケーションおよびサービスの数が増えるにつれて、クラウドコンピューティングのような技術に依存するコンテンツ、アプリケーションおよび／またはサービスプロバイダの数が増えている。クラウドコンピューティングは、一般に、Ｗｅｂサービスのようなサービスを介して電子リソースへのアクセスを提供するアプローチであり、それらのサービスを支持するために使用されるハードウェアおよび／またはソフトウェアは、動的に拡張性があり、いかなる時でもサービスのニーズを満たす。ユーザまたは顧客は、通常、クラウドを介したリソースへのアクセスに対し、賃貸、リース、またはそうでなければ支払をし、よってこれらのリソースへのアクセスを提供するハードウェアおよび／またはソフトウェアの購入および保持の必要はない。

種々のアプリケーションおよびリソースのアスペクトがクラウド内で調整および管理されうる一方で、これらのアプリケーションおよびリソースが依存するデータリポジトリは、顧客または他のそのようなユーザによって同様に調整可能にまたは容易に管理されてはいない。通常は、プロビジョニングおよびデータ記憶装置の拡張のようなタスクの実行は、面倒な手動手順であり、この手順で顧客は、構成が有効かどうかデータベース管理者（ＤＢＡ）が判断できるよう、ＤＢＡまたは類似の経験を積んだユーザに構成情報および要件を提供しなければならない。さらに、顧客が動的および／または自動的にデータベースインスタンスのパラメータを調整する、またはデータリポジトリの他のそのようなアスペクトを管理する簡単な方法はない。多くのケースでは、データインスタンスはバックアップおよびリカバリメカニズムが設定されているが、これらのメカニズムは、その領域内の障害または停止に影響されやすいような単一の位置または領域にある。さらに、データインスタンスの障害時、新しいインスタンスを生成すること、新しいインスタンスを適切なボリュームをアタッチすること、および他の障害から復旧するのに必要なタスクを実行するのに、通常数分かかる。

本開示による種々の実施形態を、下記の図を参照して記載する。

種々の実施形態が実施可能な環境を示す図である。 種々の実施形態により使用可能な、制御プレーンおよびデータプレーンの例示的な分離を示す図である。 種々の実施形態により使用可能な、複数のモニタ構成要素を利用する例を示す図である。 １つの実施形態により使用可能な、複数のデータゾーンにわたる複製されたデータインスタンスの実行の実施例を示す図である。 １つの実施形態による、一次レプリカの例示的なステート移行ダイアグラムを示す図である。 １つの実施形態による、モニタ構成要素の例示的なステート移行ダイアグラムを示す図である。 １つの実施形態により使用可能な、フェイルオーバ動作の実行の例示的なプロセスを示す図である。 １つの実施形態により使用可能な、二次レプリカの復旧の例示的なプロセスを示す図である。 １つの実施形態により使用可能な、イベントプロセッサの管理の例示的なプロセス例を示す図である。 １つの実施形態により使用可能な、データベースインスタンスをモニタするリースを取得する例示的なプロセスを示す図である。 １つの実施形態により使用可能な、データベースインスタンスのパーティショニングの例示的なプロセスを示す図である。 １つの実施形態により使用可能な、障害を起こしたイベントプロセッサに起因する再割当ての例を示す図である。 １つの実施形態により使用可能な、新しいイベントプロセッサの追加の例示的なプロセスを示す図である。

本開示の種々の実施形態によるシステムおよび方法は、電子環境内のデータ記憶の面の管理への従来のアプローチにおいて経験する、１つまたは複数の前述および他の欠点を解消し得る。特に、種々の実施形態は、ユーザが、データ環境、またはデータプレーンの種々のアスペクトの管理および／または変更を可能にするために使用可能な、別個のコントロール環境、または制御プレーンを提供する。この「セルフサービス」機能はＷｅｂサービスのセットを介して提供が可能であり、ユーザおよび制御プレーンが仮想データベース管理者（ＤＢＡ）としてともにはたらくことを可能にする。ユーザまたは顧客は、例えば、複数の外部に視認可能なアプリケーションプログラミングインタフェース（ＡＰＩ）のうちの１つを通じて、制御プレーンに要求を提出できる。種々のＡＰＩを、データ環境内でリレーショナルデータベースのようなデータリポジトリに対して特定の機能を実行するのに使用できる。ＡＰＩのうちの１つへ受信された要求は分析され、データストアまたはデータストアインスタンスの運用または構成パラメータを調整する動作のような、データプレーン内で実行される所望のアクションを決定できる。ワークフロー構成要素のような構成要素は、動作のための適切なタスクを決定でき、タスクを適切な順序で実行させる。これらのタスクのうち少なくとも１つは、リレーショナルデータベースのアスペクトを調整するなどのために、データ環境内で通常は実行される。

いくつかの実施形態により、そのようなシステムはデータ環境内の複製されたデータインスタンスのプロビジョニングを提供可能である。プロビジョニングは、一次および二次レプリカのそれぞれが、１つまたは複数の別個のデータゾーン、別個の地理的位置などの中に、またはそれらにわたりプロビジョンされる、一次−二次複製アプローチを利用可能である。データベースレプリカは、別個のデータインスタンスで実行でき、それぞれが、レプリカにわたり共有されていない専用ブロック記憶ボリュームにアタッチされる。

種々の実施形態で、複製は、オーストリアのウィーン、Ｌｉｎｂｉｔからの分散複製型ブロックデバイス（ＤＲＢＤ（登録商標））、またはワシントン州シアトルのＡｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．により提供されるような弾性ブロックストア（ＥＢＳ）のようなブロックレベル複製メカニズムを用いて実行が可能であり、これは冗長システムにわたりサーバと同期複製データの間のブロック装置の内容のミラーを設けることが可能である。それぞれのインスタンスは、データインスタンスの全ての入力および出力（Ｉ／Ｏ）動作を管理するためインストールされた、ブロックレベル複製メカニズム（ＢＬＲＭ）カーネルモジュールを有するカーネルを実行できる。全ての読み出しおよび書き込みは一次レプリカにおいて実行可能で、ブロックレベル複製メカニズムは、二次レプリカと同期的に情報を複製する。

一次および二次レプリカの両方は、外部に向けたＤＮＳ名を持つことができる。顧客は、ＤＮＳ＿ｐｒｉｍａｒｙのようなＤＮＳ名を用いて現在の一次レプリカに到達できる。ＤＮＳ＿ｐｒｉｍａｒｙ名は、（現在の）一次レプリカの外部ＤＮＳ名へエイリアスする、または「ｃｎａｍｅ」することができる。一次レプリカが障害を起こす、またはそうでなければ使用不可能なとき、二次レプリカが新しい一次レプリカになるよう、レベルが上げられ、またはフェイルオーバされることが可能であり、それによってＤＮＳ＿ｐｒｉｍａｒｙのｃｎａｍｅは、新しい一次インスタンスのＤＮＳ名へ更新されることが可能である。全ての書き込みは、現在の一次レプリカのデータベースへ送信される。一次インスタンスが書き込みを受信するとき、情報は二次レプリカに同期的に書き込まれる。両位置で正常に書き込まれると、書き込みは成功とみなすことができる。種々の実施形態において、全ての読み出しも、一次レプリカでのみ実行される。

データベースの複製を、よって、異なるデータゾーンで実行するインスタンスレプリカを用いて、複数のデータインスタンスにわたり維持することができる。データベースの書き込みは、全てのレプリカが複数データゾーンに関与する大規模故障などにより使用不可能である場合を除いて、失われるデータがないよう、ブロックレベルで同期複製メカニズムを用いてコミットできる。単一のレプリカ障害は長期間のデータベースの故障を引き起こさないので、複製は、単一のデータベースインスタンスを使用して達成されうるより高い可用性を提供できる。例えば、データベースの一次レプリカがダウンしている場合、種々の実施形態はフェイルオーバ動作を実行でき、それによって二次レプリカが新しい一次レプリカとして引き継ぐ。複製は、多くのインスタンスで非複製データベースより高い耐久性も提供でき、データゾーン、データボリューム障害などの障害に対して保護する。

図１は、種々の実施形態による態様を実施する環境１００の例を示す。理解されるように、説明の目的でＷｅｂベース環境を使用するが、種々の実施形態を実施するため、適切に、異なる環境を使用してもよい。示される環境１００は、テストまたは開発部分（またはサイド）およびプロダクション部分の両方を有する。プロダクション部分は電子クライアント装置１０２を有し、電子クライアント装置１０２は、適切なネットワーク１０４上の要求、メッセージ、または情報を送受信し、装置のユーザに情報を返送するのに動作可能なあらゆる適切な装置を有することができる。そのようなクライアント装置の例は、パーソナルコンピュータ、携帯電話、ハンドヘルドメッセージ装置、ラップトップコンピュータ、セットトップボックス、パーソナルデータアシスタント、電子ブックリーダなどを含む。ネットワークは、イントラネット、インターネット、セルラーネットワーク、ローカルエリアネットワーク、またはあらゆる他のそのようなネットワーク、またはそれらの組み合わせを含むことができる。そのようなシステムに使用される構成要素は、選択されたネットワークおよび／または環境のタイプに、少なくとも部分において依存し。そのようなネットワークを介して通信するプロトコルおよび構成要素は公知であり、本明細書では詳述しない。ネットワーク上の通信を、有線または無線接続、およびそれらの組み合わせにより可能にできる。この例で、ネットワークは、環境が要求を受信しこれに応えコンテンツを提供するＷｅｂサーバ１０６を有するのでインターネットを有するが、当業者に明らかであろうように、類似の目的を提供できる代替的な装置を他のネットワークに使用可能である。

例示の環境は、少なくとも１つのアプリケーションサーバ１０８およびデータストア１１０を有する。連鎖されまたはそうでなければ構成され得る、適切なデータストアからデータを取得するようなタスクを実行するようやりとりしうる、いくつかのアプリケーションサーバ、層、または他の要素、プロセス、または構成要素があり得ることを理解するべきである。本明細書で使用されるように、「データストア」という用語は、データの格納、アクセス、および検索が可能なあらゆる装置または装置の組み合わせを指し、いかなる標準でも、分散、またはクラスタ環境内のあらゆる組み合わせおよび数の、データサーバ、データベース、データ記憶装置およびデータ記憶媒体を有してもよい。アプリケーションサーバは、クライアント装置の１つまたは複数のアプリケーションのアスペクトの実行に必要とされるように、データストアと統合するあらゆる適切なハードウェアおよびソフトウェアを有することができ、アプリケーションのデータアクセスおよびビジネスロジックの大部分を扱う。アプリケーションサーバはデータストアと協働してアクセスコントロールサービスを提供し、ＨＴＭＬ、ＸＭＬ、または他のこの例で適切に構造化された言語の形態でＷｅｂサーバによりユーザに提供され得る、ユーザに転送されるテキスト、グラフィック、オーディオ、および／またはビデオのようなコンテンツを生成することが可能である。全ての要求および応答、ならびにクライアント装置１０２とアプリケーションサーバ１０８間のコンテンツの伝達は、Ｗｅｂサーバが扱うことができる。本明細書の他の場所で述べたように、本明細書で述べた構造化コードがいかなる適切な装置またはホストマシン上でも実行可能であるので、Ｗｅｂおよびアプリケーションサーバは必要とされず、単に例であることを理解するべきである。さらに、環境は、ユーザまたはアプリケーションが加入できるサービスとしてテスト自動化フレームワークを提供できるような方法で設計できる。テスト自動化フレームワークを、本明細書で述べたあらゆる種々のテストパターンの実施として提供できるが、本明細書で述べまたは示唆するように、種々の他の実施も同様に使用可能である。

環境は、開発者、データ管理者または試験者等のユーザにシステムアクセスを許可するユーザ装置１１８を有する開発および／またはテストサイドも有する。ユーザ装置１１８は、クライアント装置１０２について前述のような、あらゆる適切な装置またはマシンであり得る。環境は、アプリケーションサーバ１０８と同様に機能するが、コードが配置されてプロダクションサイドで実行され、例えば外側のユーザにアクセス可能である前に、開発およびテストの間、通常はコードを実行する開発サーバ１２０も有する。いくつかの実施形態では、アプリケーションサーバは開発サーバとして機能でき、個別のプロダクションおよびテストストレージが使用されない場合がある。

データストア１１０は、特定のアスペクトに関するいくつかの個別のデータテーブル、データベース、または他のデータ記憶メカニズムおよび媒体を有することが可能である。例えば、示されたデータストアは、プロダクションサイドにコンテンツを提供するのに使用可能な、プロダクションデータ１１２およびユーザ情報１１６を格納するメカニズムを有する。データストアは、テストサイドのユーザ情報と使用可能なテストデータ１１４を格納するメカニズムを有するようにも示されている。前述したいずれかのメカニズム内に適切に、または、データストア１１０内に付加されたメカニズム内に格納可能なページイメージ情報およびアクセス権情報のような、データストア内に格納の必要があるかもしれない多くの他のアスペクトがあり得ることを理解するべきである。データストア１１０は、それと関連したロジックを通して、アプリケーションサーバ１０８または開発サーバ１２０から指示を受けとり、それに応答して、データを取得し、更新し、又は他の処理を行うように作動することできる。１つの例で、ユーザが特定のタイプのアイテムのサーチ要求を提出するかもしれない。この場合、データストアはユーザ情報にアクセスしてユーザの識別情報を照合し得、カタログ詳細情報にアクセスしてそのタイプのアイテムについての情報を取得することができる。情報を、それから、ユーザがユーザ装置１０２上のブラウザを介して見られるＷｅｂページの結果リストのように、ユーザに返送できる。対象となる特定のアイテムの情報は、ブラウザの専用ページまたはウィンドウで見ることができる。

それぞれのサーバは、通常は、そのサーバの全般的管理および作動のための実行可能なプログラム命令を提供するオペレーティングシステムを有し、および、通常は、サーバのプロセッサにより実行されるときサーバがその意図された機能を実行するのを可能にする命令を格納するコンピュータ可読な媒体を有する。オペレーティングシステムの適切な実施およびサーバの全般的機能は公知または商業的に入手可能であり、特に本明細書の開示に照らして、当業者には容易に実行される。

１つの実施形態の環境は、分散コンピューティング環境であり、通信リンクを介して相互接続されるいくつかのコンピュータシステムおよび構成要素を利用し、１つまたは複数のコンピュータネットワークまたは直接接続を使用する。しかし、そのようなシステムは、図１で示されるより少ないまたはより多い数の構成要素を有するシステムでも同等に作動可能であることが、当業者に理解される。よって、図１のシステム１００の描写は例示説明の性質を有するものとして受け止めるべきであり、開示の範囲を限定するものではない。

図１で示されるような環境は、電子マーケットプレイスのようなプロバイダには有用であり得、そこでは複数のホストを使用して、コンテンツの提供、ユーザの認証、支払トランザクションの実行、またはあらゆる多数の他のそのようなタスクの実行のようなタスクを実行してもよい。これらのホストのいくつかを同一の機能を提供するよう構成してもよく、一方で他のサーバを、少なくともいくつかの異なる機能を実行するよう構成してもよい。そのような場合では、電子環境は、図２の構成２００に示されるようなさらなる構成要素および／または他の配置を有してもよく、詳細は後述する。

１つの実施形態によるシステムおよび方法は、ユーザがクラウド内のリレーショナルデータセットの格納、処理、および問い合わせのようなタスクを実行できるよう、開発者、顧客、または他の権限を与えられたユーザが、容易におよびコスト効率よくリレーショナルデータベースおよび他のそのようなデータソースを取得および構成することを可能にする、リレーショナルデータベースサービス（「ＲＤＳ」）を提供する。この例がインターネット、Ｗｅｂサービス、およびインターネットベースの技術について述べられているが、種々の実施形態の態様は、電子環境内のネットワーク上で使用可能なまたは提供されるいかなる適切なサービスでも使用可能であることを理解すべきである。さらに、本明細書ではサービスを「リレーショナルデータベースサービス」と呼ぶが、そのようなサービスは電子環境内のいかなる適切なタイプのデータリポジトリまたはデータ記憶装置でも使用可能であることを理解すべきである。この例のＲＤＳは、配備、アップグレード、パッチ管理、バックアップ、複製、フェイルオーバ、容量管理、拡張、およびデータ管理の他のそのような面のデータ管理の複雑性について心配することなく、ユーザまたは顧客が容易にリレーショナルデータセットを管理することを可能にする、少なくとも１つのＷｅｂサービスを含む。開発者は、よって、データベースインフラストラクチャの管理の複雑性について心配することなく、高度なクラウドアプリケーションの開発へ解放される。

１つの実施形態のＲＤＳは、データ記憶の管理面に有用な構成要素（例えばハードウェアおよびソフトウェア）を有する、別個の「制御プレーン」を提供する。１つの実施形態では、ユーザまたは顧客がＲＤＳ内にコールしてデータ記憶に関する特定のタスクの実行を可能にする、データ管理アプリケーションプログラミングインタフェースのセット（ＡＰＩ）または他のそのようなインタフェースが提供される。ユーザはしかし、データリポジトリと通信するのにダイレクトインタフェースまたはＡＰＩをなお使用でき、データ記憶の管理または類似のタスクの実行の必要があるときのみ、制御プレーンのＲＤＳ特異のＡＰＩを使用可能である。

図２は、１つの実施形態により使用可能なＲＤＳ実施例２００を示す。この例で、エンドユーザのための計算装置２０２が示され、これはネットワーク２０６を通して制御プレーン２０８内へコールし、データプレーン２１０のデータリポジトリをプロビジョンするようなタスクを実行することが可能である。ユーザまたはアプリケーション２０４は、データプレーン２１０のインタフェースを通して、直接プロビジョンされたリポジトリにアクセスが可能である。エンドユーザ計算装置およびアプリケーションを説明の目的で使用するが、いかなる適切なユーザ、アプリケーション、サービス、装置、構成要素、またはリソースも、種々の実施形態で適切に制御プレーンおよび／またはデータプレーンのインタフェースにアクセス可能であることを理解するべきである。さらに、構成要素がコントロールおよびデータ「プレーン」内に分離されているが、これは、それぞれの機能を提供するため使用される少なくともいくつかのリソース（例えばハードウェアおよび／またはソフトウェア）の実際または仮想の分離に言及しうることを理解するべきである。

この例の制御プレーン２０８は、基本的に、プロビジョニング、拡張、複製、などのようなコントロールおよび管理アクションを扱うハードウェアおよびソフトウェア構成要素の仮想層である。この実施形態の制御プレーンは、Ｗｅｂサービス層２１２、または段を有し、例えばコンピュータ実行可能なソフトウェア、アプリケーションサーバ、または他のそのような構成要素とともに少なくとも１つのＷｅｂサーバを有することが可能である。Ｗｅｂサービス層も、ネットワーク２０６に渡ってのＷｅｂサービスコールまたは要求を受信するためのＡＰＩ２３２（または他のそのようなインタフェース）のセットを有してもよい。それぞれのＡＰＩを、リレーショナルデータベースのインスタンスをプロビジョン、拡張、クローン、または休止するような、データ環境に関し実行される少なくとも１つの特定のアクションの要求を受信するよう提供することが可能である。ＡＰＩのうちの１つへの要求を受信すると、Ｗｅｂサービス層は要求を解析、またはそうでなければ分析し、コールに従って行うまたはコールを処理するのに必要とされるステップまたはアクションを判断することができる。例えば、データリポジトリを作成する要求を含むＷｅｂサービスコールが受信されるかもしれない。この例で、Ｗｅｂサービス層は要求を解析し、作成するデータリポジトリのタイプ、要求される記憶ボリューム、要求されるハードウェア（もしあれば）のタイプ、または他のそのような態様を判断することが可能である。要求の情報は、その後の処理のため、管理（「Ａｄｍｉｎ」）データストア２２２、または他の適切な格納場所、またはジョブ待ち行列へ書き込むことが可能である。

１つの実施形態のＷｅｂサービス層は、種々の制御プレーンＡＰＩを提供しＡＰＩ仕様に基き適切な応答を返すことが可能な、拡張性がある顧客に向けたサーバのセットを有する。Ｗｅｂサービス層は、１つの実施形態では外部に向けた顧客ＡＰＩを処理するステートレスの複製されたサーバで構成される、少なくとも１つのＡＰＩサービス層も有することができる。Ｗｅｂサービス層は、認証情報に基く顧客認証、顧客の許可、ＡＰＩサーバへの顧客要求のスロットル、ユーザ入力の検証、要求および応答のマーシャリングまたはアンマーシャリングのような、Ｗｅｂサービスフロントエンド機能に関与できる。ＡＰＩ層は、ＡＰＩコールに応え、管理データストアへの／からのデータベース構成データの読み出しおよび書き込みにも関与できる。多くの実施形態で、Ｗｅｂサービス層および／またはＡＰＩサービス層は、唯一の外部に視認可能な構成要素、またはコントロールサービスの顧客が視認可能でアクセス可能な唯一の構成要素となる。Ｗｅｂサービス層のサーバは、当業界で公知のように、ステートレスで水平方向に拡張されうる。ＡＰＩサーバならびに持続的データストアは、例えば、サーバが１つのデータセンタの障害に許容力があるように、地理的地域内または地理的位置近辺の複数のデータセンタにわたって広がることが可能である。

この実施形態の制御プレーンは、本明細書で「スイーパ」と呼ぶ構成要素２１４を有する。スイーパ構成要素は、制御プレーンの種々の構成要素をポーリングし、またはそうでなければ、未処理の要求に応え実行されるあらゆるタスクを判断するのに作動可能なあらゆる適切な構成要素であり得る。この例で、Ｗｅｂサービス層は、ａｄｍｉｎデータストア２２２、または類似のジョブ待ち行列内の「データベース作成」要求の命令または情報を出し、スイーパは未処理のジョブのａｄｍｉｎデータストアを周期的にチェックできる。当業者に明らかであろうように、ジョブが存在するという通知をスイーパへ送信するＷｅｂサービス層のような、種々の他のアプローチの使用が可能である。スイーパ構成要素は「データベース作成「要求をピックアップでき、要求の情報を用いて、要求の少なくとも１つのワークフローをインスタンス化するのに作動可能なワークフロー構成要素２１６へ要求、コール、または他のそのようなコマンドを送信できる。１つの実施形態のワークフローは、本明細書の他の箇所で述べるようなワークフローサービスを用いて生成および保持される。ワークフローは、一般に、特定のジョブを実行するため実行されるべきタスクのシーケンスである。ワークフローは実際のワークではないが、ワークの情報および実行のフローを制御するワークの抽象化である。ワークフローは、実行中のいつでもプロセスのステートを管理し返送することが可能なステートマシンとしても考えられうる。１つの実施形態のワークフロー構成要素（または構成要素のシステム）は、１つの実施形態では、リポジトリ作成、変更、および削除、リカバリおよびバックアップ、セキュリティグループ作成、削除、および変更、ユーザ証明書管理、キーローテーションおよび証明書管理のような、タスクのワークフローのホスティングおよび実行の管理および／または実行に作動可能である。そのようなワークフローは、本明細書の他の箇所で述べるように、ワークフローサービスの上で実行されうる。基本的なワークフローサービスは必ずしも変化しないので、ワークフロー構成要素は、ＭｙＳＱＬのような異なるデータベースエンジンに使用されるワークフローステップ間の違いも管理できる。

この例で、データベースを作成し、元の要求から抽出された情報を問い合わせるため、ワークフローテンプレートを用いてワークフローをインスタンス化することができる。例えば、要求が、Ｏｒａｃｌｅ（登録商標）ＲＤＢＭＳまたは他のそのようなインスタンスではなく、ＭｙＳＱＬ（登録商標）リレーショナルデータベース管理システム（ＲＤＢＭＳ）インスタンスに関する場合、特定のタスクがＭｙＳＱＬインスタンスへ向けられたワークフローに追加される。ワークフロー構成要素は、要求された記憶量に関連する特定のタスク、なんらかの特定のハードウェア要求、または他のそのようなタスクも選択することが可能である。これらのタスクは、ジョブ全体に有益な実行順序でワークフローに追加可能である。いくつかのタスクが平行して実行できる一方で、他のタスクは最初に完了する前のタスクに依存する。ワークフロー構成要素またはサービスはワークフロー内にこの情報を含めることができ、タスクを実行でき、情報が必要に応じ渡される。

顧客の「データベース作成」ワークフロー例は、データストアインスタンスのプロビジョニング、オフインスタンス永続的記憶装置のボリュームの割り当て、データストアインスタンスへ永続的記憶ボリュームをアタッチすること、その後、顧客がアクセスまたはそうでなければデータインスタンスに接続するのに使用できる、ＤＮＳアドレスまたは他のアドレス、ポート、インタフェース、または識別子の割り当ておよび付加のようなタスクを含み得る。この例で、ユーザは、インスタンスへアクセスするのに使用される、ＤＮＳアドレスおよびポートアドレスを提供される。ワークフローは、特定のデータ記憶技術（例えばＭｙＳＱＬ）に使用されるあらゆるバイナリまたは他の情報をダウンロードおよびインストールするタスクも有することができる。ワークフロー構成要素は、これらのおよびあらゆる関連するタスク、またはそのようなタスクのあらゆる他の適切な組み合わせの実行を管理でき、「データベース作成」要求に応え「データベース」の作成を示す要求への、実際にデータプレーン２１０内のデータストアインスタンスに対応し、インスタンスにアクセスするのに使用されるＤＮＳアドレスを提供する、応答を生成できる。ユーザは、それから、制御プレーン２０８にアクセスするまたは通る必要なしに、ＤＮＳアドレスおよびポートを使用して、データストアインスタンスに直接アクセスできる。種々の他のワークフローテンプレートが、記憶装置を増やす用途のような１つまたは複数のデータストアインスタンスの削除、作成、または変更のような類似のジョブを実行するのに使用可能である。いくつかの実施形態では、ワークフロー情報は記憶装置に書き込まれ、少なくとも１つの別個の実行構成要素（図示せず）が、ワークフロー情報に基き実行されるタスクをプルし、またはそうでなければアクセス、または受信する。例えば、プロビジョニングタスクを実行する専用のプロビジョニング構成要素があってもよく、この構成要素はワークフロー構成要素にコールされないかもしれないが、タスク待ち行列をモニタでき、または明らかなように多数の関連した方法のいずれかでプロビジョニングタスクの情報を受信可能である。

述べたように、種々の実施形態は、リポジトリのプロビジョニングのようなプロセスまたはタスクの現在のステートの要求またはコールを受信でき、プロセスの現在のステートを返送できるワークフローサービスの利点を利用することができる。ワークフロー構成要素および／またはワークフローサービスは、それぞれのタスクを実行する実際のコールまたは要求はしないが、代わりに、制御プレーンの構成要素が次に実行されるタスクを判断するのを可能にするワークフローのステートおよび構成情報、およびそのタスクに必要とされるあらゆる情報を管理し、それからそのステート情報を含むデータプレーン内の適切なコールを生成し、それによってデータプレーンの構成要素がコールしてタスクを実行できる。ワークフローおよびタスクは、スループットを増やし処理リソースを最大化するため、平行してスケジューリングできる。述べたように、実際のタスクの実行はデータプレーン内で起こるが、タスクは制御プレーンから始まる。例えば、ワークフロー構成要素は、データストア内にコールできるホストマネジャと通信可能である。よって、所与のタスクについて、あるパラメータを渡すワークフローサービスへのコールができ、それによって、ワークフローサービスはワークフローのタスクのシーケンスを生成し、現ステートのタスクが実行できるよう、現在のステートを提供する。タスクが実行された（またはそうでなければ、解決されまたは終了した）後、ホストマネジャのような構成要素がサービスに応答でき、サービスは、それから、次のタスクが実行できるように、ワークフローの次のステートについての情報を提供する。ワークフローのタスクのうちの１つが実行される毎に、サービスはワークフローが完了するまで実行される新しいタスクを提供できる。さらに、異なるワークフローに複数スレッドを平行して実行して、ワークフローの処理を加速できる。

この実施形態の制御プレーン２０８は、少なくとも１つのモニタリング構成要素２１８も有する。データインスタンスがデータプレーン内で作成されるとき、インスタンスの情報は、モニタリングデータストア２２０のような、制御プレーン内のデータストアへ書き込み可能である。モニタリングデータストアは別個のデータストアであることが可能で、またはＡｄｍｉｎデータストア２２２、または他の適切なリポジトリ内のテーブルの異なるセットのような他のデータストアの部分であることが可能であることを理解するべきである。モニタリング構成要素は、モニタリングデータストア内の情報にアクセスしてデータプレーン２１０内のアクティブインスタンス２３４を判断できる。モニタリング構成要素は、Ｗｅｂサービス層、ワークフロー構成要素、スイーパ構成要素、および種々のホストマネジャのような、制御プレーンおよび／またはデータプレーンの複数の構成要素からのログおよび／またはイベント情報の収集のような、他のタスクも実行できる。そのようなイベント情報を使用して、モニタリング構成要素は、顧客に向けたＡＰＩを実行するような目的で、顧客が視認可能なイベントを表すことができる。モニタリング構成要素は、常に、制御プレーンの全ての実行中のリポジトリおよび／またはインスタンスの正常性をモニタし、これらのいかなるインスタンスの障害も検出し、適切なリカバリプロセスを開始することが可能である。

データプレーン内のそれぞれのインスタンス２３４は、データストアにアクセスを提供するマシンについて、少なくとも１つのデータストア２２６およびホストマネジャ構成要素２２８を有することができる。１つの実施形態のホストマネジャは、インスタンス、および／またはソフトウェア配備およびデータストア作動のようなタスクを管理するためにプログラムされたＴｏｍｃａｔまたはＪａｖａアプリケーションサーバのようなアプリケーションサーバ上で実行する、またデータストアおよび／またはそれぞれのインスタンスのステートをモニタする、アプリケーションまたはソフトウェアエージェントである。１つの実施形態のホストマネジャは、内部のシステム構成要素からのみアクセス可能で、顧客または他の外側エンティティには可能でないポート上でリスニングする。いくつかの実施形態では、ホストマネジャは制御層内へコールを開始できない。ホストマネジャは、論理ボリュームおよびファイルシステムの設定、データベースバイナリおよびシードのインストール、および、リポジトリの開始または終了を含む、新しいリポジトリのインスタンスを設定するようなタスクの管理および／または実行に関与できる。ホストマネジャは、データストアの正常性をモニタし、またＩ／Ｏエラーまたはデータ記憶装置エラーのようなエラー状態のデータストアをモニタし、必要があればデータストアをリスタートすることが可能である。ホストマネジャは、データストアおよび／またはオペレーティングシステムのソフトウェアパッチおよびアップグレードのインストールを行う、および／または管理をする。ホストマネジャは、ＣＰＵ、メモリ、およびＩ／Ｏ使用に関し得るような関連メトリックスも収集できる。

モニタリング構成要素は、特定の要求の送信によって、またはホストマネジャからのハートビートのモニタリングによるなどように、それぞれのホストのステータスを判断するため、モニタされるインスタンス２３４のそれぞれのホストマネジャ２２８と周期的に通信可能である。１つの実施形態では、モニタリング構成要素は、特定のホストおよび／またはインスタンスのステータスを得るためのように、コマンドをそれぞれのマネジャへ発行するよう構成された、イベントプロセッサ（またはモニタリングサーバ）のセットを有する。応答が規定回数のリトライ後に受信されない場合、それからモニタリング構成要素は、問題があると判断でき、問題の検証、および必要があればインスタンスの再プロビジョンのようなインスタンスについてアクションを実行するため、Ａｄｍｉｎデータストア２２２または他のそのようなジョブ待ち行列内に情報を格納できる。スイーパは、この情報にアクセスして、インスタンスのリカバリワークフローを開始し障害の自動的復旧を試みることができる。ホストマネジャ２２８は、制御プレーンのモニタリングのプロキシおよび他の構成要素として働き、制御プレーン構成要素の代理でインスタンスのタスクを実行することができる。時々、対応するホスト、インスタンス、またはボリュームのクラッシュ、リブート、リスタートなどの、自動的に解決できない問題が、インスタンスのうちの１つに起こる。１つの実施形態では、これらのおよび他の顧客の可視イベントのログを取ることが可能な、ロギング構成要素（図示せず）がある。ロギング構成要素は、インスタンスがある期間利用不可な場合に、顧客が適切な「イベント」または類似のＡＰＩをコールしてイベントに関する情報を得られるように、ＡＰＩまたは他のそのようなインタフェースを有することができる。一部の場合、要求は、インスタンスが障害を起こすとき保留のままにしてもよい。この実施形態の制御プレーンはデータプレーンから分離しているので、制御プレーンはデータ要求を受信することは全くなく、よってその後の依頼の要求を待ち行列に入れることができない（が、いくつかの実施形態ではこの情報を制御プレーンに転送できる）。よって、この実施形態の制御プレーンは、障害に関しユーザへ情報を提供し、ユーザは必要に応じて要求を扱うことができる。

述べたように、一度インスタンスがプロビジョンされ、ユーザにＤＮＳアドレスまたは他のアドレスまたは位置が提供されると、ユーザは。インスタンス２３４と直接相互作用するため、Ｊａｖａデータベース接続（ＪＤＢＣ）または他のそのようなクライアントを用いて、ネットワークを通してデータプレーン２１０へ「直接」要求を送信できる。１つの実施形態では、データプレーンは、「クラウド」またはハードウェアおよび／またはソフトウェア構成要素の動的ネットワークにわたるデータ記憶装置およびアクセスを提供する、コンピューティングクラウド環境、またはＷｅｂサービスおよびリソースのセットの形を取る（または少なくとも有する、または部分である）。例えばインスタンスまたは可用性の障害が、使用のためのＤＮＳアドレスを適切な置換インスタンスへプログラムして再マッピングすることにより隠せるので、ＤＮＳアドレスは、そのような動的クラウド環境内で有益である。ユーザ２０２またはアプリケーション２０４に受信された要求は、例えば、要求のＤＮＳに対応する実際のインスタンス２３４またはホストへ要求を向けることができる、ネットワークアドレス変換（ＮＡＴ）ルータ２２４、または他の適切な構成要素へ向けることができる。述べたように、そのようなアプローチは、ユーザまたはアプリケーションがインスタンスのアクセスに使用されるＤＮＳまたは他のアドレスを変更する必要なく、インスタンスの動的な移動、更新、複製などを可能にする。述べたように、それぞれのインスタンス２３４は、ホストマネジャ２２８およびデータストア２２６を含むとができ、永続的記憶装置２３０内に、少なくとも１つのバックアップインスタンスまたはコピーを持つことができる。そのようなアプローチを用いて、一度インスタンスが制御プレーンを通して構成されると、ユーザ、アプリケーション、サービス、または構成要素は、制御プレーン２３２にアクセスする必要なしに、データプレーンへの要求を通じて直接インスタンスとやり取りができる。例えば、ユーザは、インスタンス内のデータに関する構造化された問い合わせ言語（ＳＱＬ）または他のそのようなコマンドを、ＤＮＳアドレスを通して直接発行できる。ユーザがインスタンスの記憶容量を拡張するようなタスクを実行したい場合にのみ、制御プレーンにアクセスしなければならないことになるだろう。少なくとも１つの実施形態で、制御プレーン２０８の機能は、データプレーン２１０のプロバイダに関連してもしなくてもよいプロバイダにより少なくとも１つのサービスとして提供され得るが、単にデータプレーン内のデータインスタンスのプロビジョンおよび管理に使用することができるサードパーティのサービスであってもよく、別個のデータプレーン２１０内のそれらのインスタンスの可用性をモニタし確実にすることもできる。

述べたように、Ｗｅｂサービスまたは他のそのようなサービスとして制御プレーンの機能を提供する１つの利点は、制御プレーンが仮想データベース管理者（ＤＢＡ）として機能し、人間のＤＢＡがデータのプロビジョニングのようなタスクを実行する必要を避けることである。データのプロビジョニングは、現状では、ＤＢＡが必要がある構成情報を受け取り、構成が有効かどうか判断し、インスタンスを最適化および調整し、他のそのようなタスクを実行することを要求する厄介な手動手順であり、かなりの量の時間および努力がかかる。さらに、そのようなアプローチは、データが失われた後まで発見されないかもしれないエラーの機会を多く提供する。本明細書に記載されたような制御プレーンまたはサービスを用いて、ユーザまたは顧客は、代わりに、ハードウェアのタイプおよびデータベース製品のバージョンのような情報を含むコールを提出できる。制御プレーンまたはサービスは、それから、データストアまたはデータ記憶インスタンスを作成、削除、変更、拡張、またはそうでなければ、変更するのに必要なタスクを実行することができる。制御プレーンは、また、ＤＢＡがそれぞれのエンジンの専門家であることを要求することなく、一定の様式でいくつかの異なるデータベースエンジンに対応することができる。一度プロビジョンされると、ユーザはデータインスタンスへのネイティブのアクセスを有し、特定のインスタンスのＤＮＳアドレスまたは他の位置情報へ、（ＭｙＳＱＬアプリケーションのような）既存のアプリケーションを単に示すことができる。ユーザがＭｙＳＱＬ、Ｏｒａｃｌｅ、または他のデータベース技術上で構築したアプリケーションを使用継続できるので、問い合わせモデルの制限または修正または他のそのような機能はない。

図３は、１つの実施形態による、モニタリング、および単一のまたは複製されたＲＤＳインスタンスの自動化されたリカバリのような目的で、使用可能な構成３００の例を示す。単純化および明瞭化の目的で参照番号を図の間で持ち込すが、これらは単に種々の実施形態に使用可能な類似の構成要素を表すことを理解するべきであり、種々の他の実施形態から必要とされる構成要素として、または単一の実施形態の異なる観点を単に示すものとして解釈すべきではない。さらに、種々の実施形態でより少ないまたは付加された構成要素を使用でき、所与の図内の構成要素の存在または欠如は、特に述べていなければ、与えられた実施形態内でその構成要素が必要とされるまたは有益でないと解釈すべきではない。実施形態および図の間の変形は、本開示の観点で、当業者に明らかである。

図に示されるように、制御プレーンのモニタリング構成要素（またはサービス）２１８は、本明細書ではイベントプロセッサと呼ぶ、一連の処理ノード３０２を有することができる。１つの実施形態では、イベントプロセッサは、データプレーンのアスペクトのモニタに作動可能なモニタリングサーバのフリートを有する。それぞれのイベントプロセッサは、関連したホストマネジャ２２８を通じて、データストア２２６および／またはデータインスタンス２３４の特定のセットまたは範囲と通信するよう構成可能である。述べたように、それぞれのデータストアおよびホストマネジャは、データプレーン２１０のノードまたはマシン、またはデータ環境上に存在できる。それぞれのイベントプロセッサは、適切な通信技術を用いて割り当てられたホストマネジャと通信して、「ｇｅｔＳｔａｔｕｓ」要求のようなセキュア（例えばＨＴＴＰＳ）要求を用いたそれぞれのホストマネジャのｐｉｎｇによるなどによって、それぞれのホストから現在のステータスを取得することが可能である。要求に応え、それぞれのホストマネジャは、ホストマネジャ２２８に問題があるかどうか、またはホストマネジャ２２８が問題を検出したかどうかのような情報、ならびに関連すると判断されるあらゆる関連メトリック、パラメータ値、または診断情報を含む応答を送信できる。特定の実施形態で、ホストマネジャが返送する情報の量およびタイプは、ホストマネジャのステートに基き変わりうる。例えば、検出されたエラーがなければ、ホストマネジャは、ログを取る、またはそうでなければ処理する標準セットの特定のメトリックを送信してもよい。問題が検出されれば、例えば、問題のタイプを示す情報、ならびにそのタイプの問題に関連した診断または他の情報のような情報の異なるセットを含んでもよい。そのような判断をするのに、ホストマネジャに種々のアルゴリズムを提供可能である。ホストマネジャから情報を受信すると、イベントプロセッサは必要に応じて情報を分析し、モニタリングデータストア２２０または他のそのような場所内に情報を格納することが可能である。イベントプロセッサは、本明細書の他の箇所で述べるように、モニタリングデータストア内にあらゆるログ情報も格納できる。この例に示されるように、モニタリングデータストア２２０は単一の論理データストアであり得るが、多くのデータインスタンス３０４にわたりパーティションすることができる。

モニタリング構成要素２１８の部分として複数のイベントプロセッサ３０２を使用することは、多くの利点を持つ。そのような利点の１つは、データプレーン内の多数のデータインスタンス２３４に対し、１つのイベントプロセッサがそれぞれのインスタンスを同時にモニタするのに十分な能力を有し得ないことである。複数のイベントプロセッサの利用は、いくつかのイベントプロセッサにわたり分散したモニタリング作業を可能にする。さらに、複数のイベントプロセッサの使用は、既存のイベントプロセッサが、障害または他のそのような問題の際、他のイベントプロセッサの作業を引き取ることを可能にする。データインスタンスが単一のイベントプロセッサによってのみ管理されおり、そのプロセッサに問題が生じ、イベントプロセッサが利用不可となったなら、データインスタンスはモニタリングされず、よって故障または他のそのような問題の危険性があり得ることになるであろう。モニタリングをイベントプロセッサのセットにわたって広げ、それぞれのイベントプロセッサによるモニタリングの範囲を動的に更新することを可能にすることで、制御プレーンは、データプレーン内のそれぞれのインスタンスが、実質的にいつでも、１つまたは複数のイベントプロセッサの障害の場合でさえ、モニタされることを確実にできる。

１つの実施形態では、それぞれのイベントプロセッサの責任は、任意の時点でのモニタされるインスタンス（レプリカを含む）の数をとること、およびその数のイベントプロセッサにわたるインスタンスの数を割り振ることにより判断される。例えば、データプレーン内にモニタされるべき２５，０００のインスタンスがあり、制御プレーン内で実行中の５つのイベントがあれば、そのとき、それぞれのイベントプロセッサに、データインスタンスのおよそ５，０００のモニタリングの責任を与えることができる。それぞれのインスタンスに識別子が与えられていれば、例えば、それからそれぞれのイベントプロセッサに、（第１の５，０００識別子、第２の５，０００識別子、などのような）識別子の範囲を与え、２５，０００インスタンスのそれぞれにマッピング情報を管理する必要とするのではなく、それぞれのイベントプロセッサの責任をより容易に調整することができる。図の例は、そのような例におけるそれぞれのイベントプロセッサの責任の範囲を示す。

１分に一度のような適切な間隔で、それぞれのイベントプロセッサ３０２は、そのイベントプロセッサによりモニタ中のそれぞれのホストマネジャ２２８に要求を送信可能である。１つの実施形態のイベントプロセッサは、データプレーン内のデータインスタンスに対しホストマネジャを定期的にポーリングする、制御プレーンのＴｏｍｃａｔ収納構造内で実行中のＪａｖａアプリケーションである。イベントプロセッサは、ＤＮＳ名およびホストマネジャポートを使用してｇｅｔＳｔａｔｕｓ（）または類似のコール（例えばｏｖｅｒ ＳＳＬ）をすることにより、１つの実施形態のホストマネジャをポーリング可能である。いくつかの実施形態では、モニタ中のデータインスタンスは、顧客データストア識別子、データストア識別子、およびインスタンス識別子の組み合わせにより、一意的に識別される。そのようなアプローチを用いて、データインスタンスをクラウド内の他のインスタンスに移動するとき、古いおよび新しいインスタンスのステートを識別可能である。イベントプロセッサは、ホストマネジャからの応答に基きデータインスタンスのステートを判断できる。１つの実施形態のデータインスタンスは、少なくとも下記のステート例に入ることができる。「ＯＫ」（データインスタンスは適切に実行中）、「ｉｎｃｏｍｍｕｎｉｃａｄｏ」（データインスタンスは障害の疑いのステート）または「ｄｅａｄ」（データインスタンスは到達不可およびステータス要求に応答せず）。

ほとんどの場合、ホストマネジャは、ホストマネジャ、関連するインスタンス、などが予測通り実行中であることを示す応答を返し、イベントプロセッサは、モニタリングデータストア２２０内の情報を更新できる。１つの実施形態で、ホストマネジャがＨＴＴＰ応答コード「２００」（正常なＨＴＴＰ要求の標準応答コード）のような適切な応答を返すとき、イベントプロセッサは、データインスタンスが「ＯＫ」または類似のステートであると考えることができる。応答がホストマネジャから受信されない場合、または応答がタイムアウト応答（ＨＴＴＰコード「５００」、または他のいずれかの「５ｘｘ」エラー応答コード）である場合、イベントプロセッサはｇｅｔＳｔａｔｕｓ要求を再送でき、データベースインスタンスを「ｉｎｃｏｍｍｕｎｉｃａｄｏ」または類似のステートにおくことができる。ホストが予め定められた数のステータスｐｉｎｇまたは他のそのような要求より多く「ｉｎｃｏｍｍｕｎｉｃａｄｏ」ステートにある場合、データインスタンスは「ｄｅａｄ」または類似のステートにあると宣言することができる。ホストが予め定められた数のステータスｐｉｎｇ内に「２００」応答（または類似の）コードでオンラインに戻ってくる場合、ホストまたはインスタンスは「ＯＫ」ステートに移ることができる。ホストステートが「ｉｎｃｏｍｍｕｎｉｃａｄｏ」から「ｄｅａｄ」または「ＯＫ」に移る前に少なくとも部分で使用される予め定められた回数のチェックは、間欠的なネットワークエラー、一時的にオーバーロードされたイベントプロセッサ、一時的にオーバーロードされたホストマネジャ、または他のそのような、実際はデータインスタンス利用不可、他のそうでなければリカバリを要求する結果とならない一時的エラーによる誤った肯定を避けるためである。１つの実施形態では、ステートが他のイベントプロセッサにより容易に判断可能なので、「ｉｎｃｏｍｍｕｎｉｃａｄｏ」のステートは持続されない。

予め定められた数のステータス要求の後応答が受信されない場合、またはステートがそれ以外に 「ｄｅａｄ」または類似のステートに移される場合、本明細書の他の箇所で述べるように、イベントプロセッサは、問題のステートに関する情報をＡｄｍｉｎデータストア２２２（または前述したような他のそのようなジョブ待ち行列）内に投入し、無応答のホストマネジャに関して疑いのステートが存在することを示す。前述のように、制御プレーンのスイーパ２１４構成要素は、情報のため周期的にＡｄｍｉｎデータストアをチェックでき、スイーパが疑いまたは問題のステートに関する情報を検出するとき、適切なリカバリワークフローを開始できる。例えば、スイーパは、情報を、利用不可中のデータインスタンスを扱うワークフロー、ホストマネジャにより報告されたエラーを扱うワークフロー、またはあらゆる多数の他のそのような状況のワークフローのような適切なワークフローの生成を引き起こすワークフロー構成要素２１６に渡すことができる。ワークフローマネジャは、適切なワークフローを生成し、ステート情報を渡し、本明細書の他の箇所で述べるように種々の他のアスペクトを扱うことができる。

リカバリ情報をＡｄｍｉｎデータストア内に格納する１つの利点は、そのようなアプローチがモニタリングシステムの障害の場合でさえ、リカバリを可能にすることである。モニタリングデータストアの可用性から独立してリカバリアクションを可能にすることが、望ましい場合がある。この実施形態では、ワークフローの生成などを含むあらゆるタイプのリカバリが、Ａｄｍｉｎデータストア（または他のそのようなジョブ待ち行列）がアクティブかつ利用可能であることを必要とするので、Ａｄｍｉｎデータストアの使用を受け入れることができる。よって、リカバリに他の依存性をつけることを避け、代わりに利用可能性を単一の場所で有することが望ましくあり得る。

種々の実施形態によるシステムおよび方法は、顧客が、Ｗｅｂサービスまたは類似のそのようなアプローチを利用して、クラウドコンピューティングまたは類似の環境内に、１つまたは複数の複製されたデータベースインスタンスを作成することを可能にし、高度な耐久性があり、高度に可用性のあるデータソリューションを提供する。顧客が種々の実施形態で複製されたデータベースインスタンスを作成するとき、顧客データは、一次−二次複製モデルを用いて同期的に複製される。いくつかの実施形態では、レプリカは異なるデータゾーン内のような異なる物理的位置に配置できる。それぞれのデータ「ゾーン]は、例えば特定の地理的領域内に配置された、異なる地理的位置に、または周辺に配置された異なるゾーンの１つまたは複数のデータセンタ、またはデータサーバのグループを指すことができる。異なる地理的位置にある他のデータゾーンが、大きな壊滅的イベントの場合を除いて障害を避けられ得るので、ＲＤＳインスタンスは、そのとき、データゾーンのうちの１つの障害を許容できる。いくつかのケースで、データセンタは複数のデータゾーンにわたることが可能であるが、与えられたデータセンタ内のデータレプリカは、異なるゾーンでインスタンス化が可能である。重複するゾーン、複数の地理的位置のゾーンなどのような、多くの他の変形が可能である。一次レプリカが障害を起こす、または別様に利用不可になる場合、ＲＤＳシステムは迅速および自動的に二次レプリカへフェイルオーバすることができ、ほとんどダウンタイムまたはデータ非可用性がない結果をもたらす。

１つの実施形態では、図２について述べられたような、制御プレーンのＷｅｂサービス層の特定のインタフェースをコールすることで、顧客は複製されたデータベースインスタンスの作成が可能である。例えば、顧客は、非複製のデータインスタンスを作成する際のように、「ＣｒｅａｔｅＤＢＩｎｓｔａｎｃｅ」ＡＰＩをコールして、インスタンスクラス、割り当てられた記憶装置、データベースエンジン、などのアスペクトを指定できる。複製されたインスタンスを作成するとき、顧客は、「Ｒｅｐｌｉｃａｔｅｄ」または類似のパラメータのような少なくとも１つの付加的なパラメータを、作成されたインスタンスを複製すべきであることを示す「ｔｒｕｅ」または他のいずれかの適切な値に設定した値とともに含めることができる。いくつかの実施形態で、顧客が他に指定した場合を除いて非複製のインスタンスが作成されないように、値はデフォルト設定で「ｆａｌｓｅ」に設定される。いくつかの実施形態では、特定のレベルのサービスのために料金を支払う顧客のような、特定の顧客だけが複製されたインスタンスを作成する能力を持つ。

いくつかの実施形態では、顧客は、二次レプリカを一次レプリカと異なるデータゾーン内に作成するかどうかも選択できる。顧客は、いくつかの実施形態では、例えばインスタンスの１つまたは複数の特定のデータゾーンまたは順序付きリストを選択することも可能であり、一方で他の実施形態では、顧客は少なくとも一次レプリカのデータゾーンを選択することはできない。例えば、顧客が２つのデータゾーンと延長時間内に利用不可となるデータゾーンのうちの１つを指定する場合、いくつかの実施形態で、耐久性の必要が第３のデータゾーン内などで他のレプリカが生成される状態を引き起こす。これは、複数顧客の順番データゾーンリストの管理および更新を必要とする可能性があり、重要な利点を提供することなくユーザの経験を複雑にする可能性がある。さらに、アプリケーションにとっては、二次レプリカと同一のデータゾーン内に位置付けられたいくつかのアプリケーションのフリートがあるよう、データゾーンにわたり関連したアプリケーションのフリートを広げることの方がより容易であり得る。

いくつかの実施形態では、顧客は複製されたデータインスタンスに「ＤｅｓｃｒｉｂｅＤＢＩｎｓｔａｎｃｅ」または類似のＡＰＩをコールでき、それによって、ＲＤＳは、一次レプリカおよび一次レプリカが現在位置付けられたデータゾーンのエンドポイントＤＮＳ名のような情報をリストにできる。例えばＲＤＳインスタンスのステータスが「Ａｖａｉｌａｂｌｅ」で、エンドポイントＤＮＳ名を使用してインスタンスに接続するとすぐに、顧客がデータストアのエンドポイントＤＮＳ名を受信可能であるので、顧客は、なお単一のデータゾーンに使用されるであろう従来のアプローチを用いて、ＲＤＳインスタンスと通信可能である。レプリカ障害の場合、ＲＤＳはデータベースを対応する二次レプリカへフェイルオーバでき、エンドポイントＤＮＳ名を新しい一次レプリカにエイリアスすることができる。データベースエンドポイントＤＮＳ名は、多くの実施形態で一定のままであり、複製されたインスタンスの有効期間の間は変化しない。

いくつかの実施形態では、顧客に、「ＭｏｄｉｆｙＤＢＩｎｓｔａｎｃｅ」または類似のＡＰＩを、Ｒｅｐｌｉｃａｔｅｄパラメータを「ｔｒｕｅ」に設定してコールすることによるなどで、非複製インスタンスを複製されたインスタンスに変換する能力を提供することができる。これは、ＡＰＩコールパラメータに依存し得て、次のメンテナンスウィンドウの間または要求の後直ちになどの適切な時間に、データベースが複製されたインスタンスに変換される状況を起こしうる。

種々の実施形態は、サーバ間のブロック装置の内容をミラーリングする何も共有しない複製された記憶ソリューションを実行するカーネルモジュールのような、ブロックレベル複製メカニズム（ＢＬＲＭ）の利点を活用する。ＢＬＲＭは、ブロック装置（すなわちハードディスクまたは論理ボリューム）の上で動作する。それは、一次レプリカが全ての更新を下層のブロック装置に指示する一次−スレーブ複製アーキテクチャを使用する。ブロック装置への全ての入力および出力（Ｉ／Ｏ）要求は、ＢＬＲＭカーネルモジュールにより傍受され、全ての書き込み動作が自動的および同期的に複製される。ＢＬＲＭは、ピア装置の固有の障害の検出を提供し、ピアノードがアクセス不可能なとき、適切なリカバリハンドラを呼び出す。ＢＬＲＭは、バックグラウンドで、一次レプリカにおけるデータアクセスに干渉することなく、一時的に利用不可のノードを、データの最新バージョンへ自動的に再同期もさせる。ＢＬＲＭは、世代識別子（「ＧＩ」）を使用して複製されたデータの世代を識別し、それによって、ＢＬＲＭは、２つのノードが同一のレプリカペアのメンバかどうか、バックグラウンド再同期（必要があれば）の指示、および部分的または全体の再同期が必要かどうかといったアスペクトを判断できる。ＢＬＲＭドライバは、レプリカペアの初期化の間、切断されたスタンバイレプリカが一次レプリカにスイッチングしているとき、または一次ロールのリソースが二次レプリカから切断されているときのような適切な時にいつでも新しい世代を開始できる。本明細書では、説明の目的で１つの例としてブロックレベルの複製メカニズムを使用するが、あらゆる他の適切なブロックレベルまたはメカニズム技術が種々の実施形態の範囲内で使用可能であることを理解するべきである。

述べたように、種々の実施形態のＲＤＳデータインスタンスは１つまたは複数のシステムまたはプラットフォーム上で構築可能である。例えば、インスタンスは仮想コンピューティング環境上で構築可能であり、仮想コンピューティング環境は、顧客がＷｅｂサービスまたは他の適切なアプローチを利用して、さまざまなオペレーティングシステムでそれらのインスタンスを起動し、管理することを可能にする。そのような仮想コンピューティング環境を提供するＷｅｂサービスの例は、Ａｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．から提供された伸縮自在な計算クラウド（Ｅｌａｓｔｉｃ Ｃｏｍｐｕｔｉｎｇ Ｃｌｏｕｄ、ＥＣ２）サービスである。データインスタンスを、インスタンスの有効期間から独立して持続するオフインスタンス記憶装置を提供可能な、ブロックレベル記憶メカニズム上でも構築できる。ブロック格納メカニズムは、インスタンスにアタッチして、インスタンス内の装置としてエクスポーズ可能な記憶ボリュームを提供できる。ブロック格納プラットフォームの例は、同時係属中の２００８年８月８日出願の米国特許出願第１２／１８８，９４９号、表題「Ｍａｎａｇｉｎｇ Ａｃｃｅｓｓ ｏｆ Ｍｕｌｔｉｐｌｅ Ｅｘｅｃｕｔｉｎｇ Ｐｒｏｇｒａｍｓ ｔｏ Ｎｏｎ−Ｌｏｃａｌ Ｂｌｏｃｋ Ｄａｔａ Ｓｔｏｒａｇｅ「にあり、これは参照により本明細書に組み込まれる。論理ボリューム（例えばＬＶＭ層）は、顧客データベースがＬＶＭ／ファイルシステム層上で実行できるよう、ブロック記憶ボリュームおよび適切なファイルシステムの上に構築可能である。１つの実施形態では複製されたデータベースに対し、ＢＬＲＭはＬＶＭ層の上で実行できる。そのような実施形態のＢＬＲＭは、全てのＩ／Ｏ要求を傍受して、それらの要求を論理ボリュームに送信し、論理ボリュームは、次いで複数のブロック記憶ボリュームにわたり要求を分割することができる。論理ボリュームの使用は、複数のブロック記憶Ｅボリュームを扱う能力ならびに記憶装置を容易に拡張する能力などをもたらすことができる。ＬＶＭの上にＢＬＲＭの層を置くことにより、書き込み動作をレプリカにわたり複製させることを可能することもできる。

図４は、複製されたＲＤＳインスタンスを提供する一次−二次複製モデルを実行するメカニズム４００の例を示す。この例で、一次レプリカ４１０および二次レプリカ４１２は、データプレーン４０８、またはデータベース環境の異なるデータゾーン（１および２）内に位置する。それぞれのレプリカはブロック記憶メカニズムの上に構築され、ここでは、それぞれのレプリカのブロックストア４２０、４２２へのＩ／Ｏ管理をＢＬＲＭ層４１８、４２２として示す。図２に関して述べたものと同様であり得るような制御プレーン４０６の構成要素は、例えば構成コマンドを必要なセットアップ動作を実行できるローカルホストマネジャ４１４、４１６へ発行することにより、複製されたＲＤＳインスタンスを作成することが可能である。図に見られるように、ＢＬＲＭ４１８、４２２のようなブロックレベルメカニズムは、ブロック装置レベルでの全てのＩ／Ｏ要求、およびローカルディスクおよびリモートディスク４２０、４２４への要求に対する書き込み情報を傍受するよう位置する。この例で、データベース４２６（例えばＳＱＬ）は一次レプリカ４１０内でのみ実行され、全てのクライアント４０２はそのデータベーストランザクションを一次レプリカ４１０上（適切なネットワーク４０４を介して）で実行する。データベースは通常下層の装置内の更新を感知しないので、データベース４２６は二次レプリカ４１２上で実行されず、ファイルシステムも二次レプリカ上にマウントされ得ない。

それぞれのデータベースクライアント４０２は、ＲＤＳデータベースＤＮＳエンドポイント名を使用して自動的に現在の一次レプリカを発見し、ＲＤＳデータベースＤＮＳエンドポイント名は一次レプリカ４１０のホスト名へエイリアスすることができる。ＤＮＳを使用して現在の一次レプリカを発見することにより、例えばネイティブのＭｙＳＱＬクライアント、ＪＤＢＣ、ＰＨＰ、Ｃ＃、およびＨａｓｋｅｌｌのような既存のデータベースクライアントとの互換性が維持できる。ＤＮＳキャッシングがクライアントの古い一次レプリカへの接続の試みを引き起こす可能性があるが、二次レプリカ内でデータベースは実行されないので、クライアントは二次レプリカへの接続によりデータベースと対話できない。顧客は、それから適切なＤＮＳ情報を取得することを知ることができる。

述べたように、データベース複製を、同一のまたは異なるデータゾーン内で実行する複数の下層のデータインスタンスにわたり対応することが可能である。一度書き込み動作が同期アプローチを用いてコミットされると、データは、複数のデータゾーンの障害などにより全てのレプリカが利用不可である、非常にまれなケースを除いて失われない。そのようなアプローチは、１つのレプリカ障害が長時間にわたるデータベースの故障を引き起こさないので、単一のデータベースインスタンスより高い可用性を提供できる。例えば、データベースの一次レプリカがダウンしている場合、システムは多くの場合二次レプリカへフェイルオーバ動作を実行できる。さらに、そのようなアプローチは、非複製データベースより高い耐久性を提供でき、データゾーンまたは単一のブロック記憶ボリューム障害などの障害のような障害から保護できる。

前に述べたように、ＲＤＳは、ＢＬＲＭのようなブロックレベルメカニズムの利点を活用して、サーバ間のブロック装置の内容をミラーすることができる。一次−スレーブ複製アーキテクチャは、一次がブロック装置への全ての更新を受け入れ書き込むことを可能にする。ブロック装置への全てのＩ／Ｏ要求は、書き込みが同期複製できるよう、ＢＬＲＭカーネルモジュールにより傍受される。ＢＬＲＭは、複製されたデータの世代を識別するため、世代識別子（「ＧＩ」）を利用する。ＢＬＲＭは、このメカニズムを使用し、２つのノードが、偶発的に接続された２つのノードにではなく、実際に同一のレプリカペアのメンバであるかどうか判断する。ＧＩは、必要があれば、バックグラウンド再同期の指示を判断するため、および部分的または完全再同期が必要かどうかを判断するため使用可能である。少なくとも１つの実施形態で、ＧＩは全範囲で一意的な識別子（Ｕｎｉｖｅｒｓａｌｌｙ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒｓ、ＵＵＩＤ）であり、シーケンス番号を単調に増加しない。ＢＬＲＭドライバは、レプリカペアの初期化の間、切断された二次レプリカが新しい一次レプリカに切り換えられるとき、または一次ロールのリソースが二次レプリカなどから切断されるとき、新しい世代を開始できる。

レプリカペア（例えば一次レプリカＰおよび二次レプリカＳ）が初めて初期化され接続される例で、一次レプリカＰはＧＩ₁のような新しいＧＩを生成可能である。一次レプリカＰがＳから切断されてＰが同期複製なしに全てのＩ／Ｏを実行する劣化モードに移る場合、ＰはＧＩ₂のような新しいＧＩを生成可能である。ＰおよびＳがネットワークパーティションにより切断された場合でも、Ｓは新しいＧＩを生成しない。この例で、一次レプリカＰは、メタデータ内に新しいＧＩおよび前のＧＩ（それぞれＧＩ₂とＧＩ₁）を保存する。前のＧＩを格納する１つの理由は、二次レプリカリカバリの最適化である。例えば、Ｓが瞬間的に切断される原因となる一時的ネットワークパーティションがあり得る。その後、パーティションが回復しＳがＰに再接続されるとき、Ｐが２つのデータ世代間で変更されたそれらのブロックのみを送れるよう、ＰはＳの現在のＧＩをＰの前のＧＩと見ることができる。

一次レプリカの障害がある例では、Ｐが利用不可と検出されるときに、Ｓを新しい一次レプリカへとレベルを上げることができる。二次レプリカを新しい一次レプリカへレベルを上げるためのコマンドが発行されるとき、ＢＬＲＭは新しい一次レプリカ（以前のＳ）で新しいＧＩを生成できる。よって、Ｐ（元の一次レプリカ）がクラスタに再接合しＳと通信するとき、Ｐはデータ世代が変化したことを判断でき、ＰはＳからデータを同期しなければならない。

述べたように、一次レプリカＰは全ての書き込みおよび読み出しを受け入れることが可能で、ＤＮＳ＿ｐｒｉｍａｒｙは一次インスタンスのＤＮＳ名へエイリアスするかｃｎａｍｅすることができる。二次インスタンスＳは、ＤＲＤＢ複製（または類似のブロックレベル複製）プロトコルを通して一次レプリカから全ての更新を受信できる。マウントされた装置、または二次レプリカ内で開始されたデータベースはない。フェイルオーバを可能にするとき、利用可能な他の構成要素は、モニタリング構成要素Ｍである。モニタリング構成要素は、一次および／または二次レプリカの正常性をモニタし、障害が起こるとき適切なフェイルオーバアクションを開始できる。１つの実施形態のモニタリング構成要素は周期的にｐｉｎｇし、またはそうでなければ一次および二次レプリカと通信する。この通信は、例えば、Ｔ＿ｈｅａｒｔｂｅａｔまたは類似のパラメータにより特定される秒数のような一定の間隔をおいて起こるハートビート通信を含むことができる。モニタリング構成要素がＰおよびＳにｐｉｎｇするときはいつでも、１つの実施形態においてモニタリング構成要素は、ＨＴＴＰｇｅｔＳｔａｔｕｓ（）コマンドをそれぞれのレプリカ内で実行中のホストマネジャへ発行する。ＰおよびＳがそれぞれそのコールを受信するとき、レプリカは、それぞれのレプリカの現在のステートを判断するために、ＢＬＲＭまたは類似のステータスコールを実行できる。例えば、一次レプリカＰは、ＩＮ＿ＳＹＮＣ，ＳＴＡＬＬＥＤ，ＤＥＧＲＡＤＥＤ，ＤＥＡＤなどのようなステータスを判断するため、ＢＬＲＭツールコマンドを実行できる。

ステータスの報告に加え、それぞれのレプリカは、それらのそれぞれのＧＩを、メモリ内に世代番号を格納可能なモニタリング構成要素へ報告できる。新しいモニタリング構成要素がブートストラップするときはいつでも、新しい構成要素は、レプリカペアのリストならびにエンドポイントを、強力に一致したデータストア（すなわちモニタリングデータベース）から読み出し、メモリ内に情報を格納することができる。それぞれのステータスｐｉｎｇの間、モニタリング構成要素は数が同一かどうか判断可能である。なんらかの理由で数が異なる場合、ＧＩ値をメモリ内で更新できる。

一次または二次レプリカは少なくとも２つのモニタされたステートのうち１つであり得る。図５は、１つの実施形態による一次レプリカのステート変移ダイアグラム５００の例を示す。レプリカがモニタリング構成要素に接続されているとき、レプリカはＭＯＮＩＴＯＲＥＤステートを有することができる。レプリカがモニタリング構成要素に接続されていないとき、レプリカはＮＯＴ＿ＭＯＮＩＴＯＲＥＤまたは類似のステートであり得る。一次インスタンスは、複数のデータ同期ステートの１つであり得る。例えば、ＰおよびＳの両方が作動中で互いに通信可能なとき、ＰはＩＮ＿ＳＹＮＣステートである可能性があり、そこでは全ての書き込みがＰおよびＳの間で同期的に書き込まれる。ステートダイアグラムを見ると、一次レプリカがＩＮ＿ＳＹＮＣ／Ｍｏｎｉｔｏｒｅｄステートにある５０４で、一次レプリカは二次レプリカと通信可能で、全ての書き込みは成功しており、ＢＬＲＭはハートビートしており、一次はモニタされている。一次がモニタリング構成要素から切断されているがなお二次レプリカと同期している場合、ステートはステート５０２へ変移できる。ステート５０２で、一次は二次レプリカと通信可能で、両方のレプリカが接続されて最新であるが、一次がモニタリング構成要素から切断されており、よってモニタされていない。二次レプリカもＣＯＮＮＥＣＴＥＤステートにあり得、そこでは二次レプリカは正常で一次レプリカとコンタクトがあり、二次レプリカが正常で一次レプリカとコンタクトがないとき、ＤＩＳＣＯＮＮＥＣＴＥＤステートであり得る。よってステータス５０２および５０４で、二次レプリカはＣＯＮＮＥＣＴＥＤであろうが、他のステートではＤＩＳＣＯＮＮＥＣＴＥＤであろう。

Ｐがモニタされているが、Ｓから切断され、またはそうでなければＳとコンタクトがないとき、一次レプリカはＳＴＡＬＬＥＤまたは類似のステート５０８を有することができ、全ての書き込みが凍結されるので、Ｉ／Ｏ動作に進むことができない。ＰがＳから切断され非複製モードに切り換わったとき、一次レプリカはＤＥＧＲＡＤＥＤまたは類似のステート４０６を有することができる。これは、Ｓがダウンまたはそうでなければアクセス不可能なとき、Ｐが読み出しおよび書き込みを提供し続けることを可能にする。Ｐはステート５０２または５０８からＤＥＧＲＡＤＥＤモードに到達し得る。ＲＤＳが通常は新しいスタンバイレプリカを作成するので、Ｐは多くの実施形態で、ＤＥＧＲＡＤＥＤモードに長くはとどまらないかもしれない。一度新しい二次がインスタンス化され、一次レプリカと完全に同期され、モニタリング構成要素にモニタされると、ステートはステート５０４に戻る可能性があり、そこでレプリカはＩＮ＿ＳＹＮＣおよびＭｏｎｉｔｏｒｅｄである。

ＰがＳから切断され、またＮＯＴ＿ＯＢＳＥＲＶＥＤステートにある、またはそうでなければ入るとき、一次レプリカは、ＳＵＩＣＩＤＡＬまたは類似のステート５１０であり得る。この場合、Ｐのステートは、Ｔ＿ｆａｉｌｏｖｅｒ秒のような時間後にＳＵＩＣＩＤＡＬに変更されうる。このステート５１０は、いくつかの実施形態では、ＳＴＡＬＬＥＤステート５０８からのみ到達でき、Ｐがモニタリング構成要素とコンタクトがないときに起こる。このステートで、一次レプリカは、自身をシャットダウン、またはデータインスタンスをリブートすることによって、自身を「ｋｉｌｌ」する。

そのようなプロセスを実施するモニタリングおよびフェイルオーバアーキテクチャの部分として、それぞれの複製されたデータベース（すなわちレプリカペア）が、モニタリング構成要素によりモニタされる。ＲＤＳでは、１つのモニタリング構成要素が複数のレプリカペアをモニタできる。さらに、システムは複数または「フリート」のモニタノードを利用できる。述べたように、モニタリング構成要素は、Ｔ＿ｈｅａｒｔｂｅａｔ秒毎のような適切な間隔でレプリカペアを継続的にｐｉｎｇすることにより、モニタされたデータベースのステートを判断できる。図６は、それぞれのモニタリング構成要素Ｍの観点からの複製されたデータベースのステート変移ダイアグラム６００の例を示す。一次レプリカがＩＮ＿ＳＹＮＣステートにあり、二次が接続されているとき、ＭはＩＮ＿ＳＹＮＣまたは類似のステート６０４にあるものとしてデータベースを見ることができる。例えば、モニタリング構成要素がネットワークパーティションによりレプリカのうちの１つと通信できないとき、Ｍはステート６０４にあるものとしてデータベースを見ることができるが、フェイルオーバイベントを実行する必要がないように、他のレプリカが、モニタリング構成要素にレプリカが接続され同期していることを示す。

なんらかの理由でＭが一次および二次レプリカの両方ともはや通信できない場合、モニタリング構成要素が区分されているか、両方のレプリカが同時に利用不可である。どちらのケースも、ＭはＰａｒｔｉｔｉｏｎｅｄまたは類似のステート６０２に移動中としてデータベースのステートを見ることができる。これは、一次および二次レプリカの両方をＮＯＴ＿Ｍｏｎｉｔｏｒｅｄステートにおく。モニタ区分が回復するときまたは新しいモニタリング構成要素がデータベースに割り当てられるとき、ステートはＩＮ＿ＳＹＮＣステート６０４に戻ることができる。

Ｍが一次レプリカともはや通信できず、二次レプリカがＤｉｓｃｏｎｎｅｃｔｅｄステートにあるように一次レプリカと通信できない場合、モニタリング構成要素はＳ＿ＯＮＬＹステート６０６にあるものとしてデータベースを見ることができる。Ｔ＿ｆａｉｌｏｖｅｒ秒のような時間内に、モニタリング構成要素が一次レプリカとの通信を再確立することが可能である場合、ステートはＩＮ＿ＳＹＮＣ６０４に戻ることができる。モニタが少なくともＴ＿ｆａｉｌｏｖｅｒ秒の間一次レプリカと通信できない場合、モニタリング構成要素は二次レプリカを新しい一次にレベルを上げることを決定できる。二次レプリカが現在のＧＩが一次レプリカの最後に既知のＧＩと同一であることを確認し、二次レプリカがレベル上げの要求を確認する場合、新しい二次がインスタンス化され、完全に新しい一次と同期されるまで、ステートはＰ＿ＯＮＬＹステート６０８に変移でき、同期された段階でステートはＩＮ＿ＳＹＮＣ６０４に戻ることができる。

しかし、モニタリング構成要素が二次レプリカを新しい一次レプリカへレベルに上げることを決定したが、二次レプリカがレベル上げ要求を拒絶する場合、ステートはＤｉｓａｓｔｅｒまたは類似のステート６１０へ変移しうる。二次は、二次レプリカの現在のＧＩが一次レプリカの最後に既知のＧＩと異なるので、要求を拒絶するかもしれない。他の場合では、二次レプリカから応答がそれ以外の理由で受信されないかもしれない。これは、大きな非可用性がある、または、ＧＩまたはメンバーシップ情報が壊れるなど非常に可能性が低いイベントのときに起こりうる。

ステートがＩＮ＿ＳＹＮＣ６０４である他の場合では、モニタリング構成要素は、二次レプリカと通信する能力を失うかもしれず、一次レプリカも、一次レプリカがＳＴＡＬＬＥＤステートにあるように、二次レプリカと通信する能力を失うかもしれない。この場合、ステートモニタリング構成要素は、一次レプリカがＤＥＧＲＡＤＥＤステートに移るよう要求でき、モニタリング構成要素から見るようなステートは、Ｐ＿ＯＮＬＹまたは類似のステート６０８へ変移しうる。モニタリング構成要素および一次レプリカが二次レプリカと通信できず、一次レプリカがＤＥ−ＧＲＡＤＥＤモード中である状態で、新しい二次レプリカをインスタンス化して一次レプリカと完全に同期することが可能で、それによってＭから見るようなステートは、ＩＮ＿ＳＹＮＣ６０４に戻りうる。

ステート変移ダイアグラムに見られるように、少なくとも１つの実施形態のモニタリング構成要素により実施されるフェイルオーバアルゴリズムは、モニタリング構成要素に、特定の状況におけるインスタンスについて、二次レプリカを新しい一次レプリカにレベルを上げることをさせる。理解すべきように、この例は単に図６のステートダイアグラムを通して１つのパスを示すのみである。図７は、１つの実施形態により使用可能な二次レプリカにフェイルオーバする例示的なプロセス７００を示す。この例で、一次および二次レプリカはプロビジョンされ、接続され、および同期される（７０２）。世代識別子（ＧＩ）が、複製されたデータの現在の世代を識別するため、それぞれのレプリカに生成される（７０４）。モニタリング構成要素がレプリカに割り当てられ、周期的にレプリカにｐｉｎｇする（７０６）。レプリカペアに割り当て中のモニタリング構成要素は、そのペアの、しばらくすると無効となる可能性がある「リース」を取得するか、提供されることが可能である。リースは、通常は一次レプリカのホストマネジャから受信され、イベントプロセッサリーススキームが一次レプリカのクラッシュを切り抜けられるよう、イベントプロセッサ識別子およびリース時間を両方のレプリカに格納できる。このように、モニタリング構成要素は、周期的にレプリカから解放されることができ、よってロード配分またはパーティショニングの目的で他のペアへ移るか、またはそうでなければ多数の他のそのような理由のために操作されることが可能である。リース期間の終了またはその間際に、モニタリング構成要素はリースを更新しようと試みることができ、本明細書の他の箇所で述べるように、リースを更新しないなどの判断ができる。モニタリング構成要素が一次レプリカとのコンタクトを失う場合（７０８）、モニタリング構成要素はある一定の期間リトライを試みることができる（７１０）。モニタリング構成要素が一次といつでもコンタクトを取り戻す場合、モニタリングプロセスは継続できる。モニタリング構成要素がＴ＿ｆａｉｌｏｖｅｒ秒のような時間の間一次レプリカとコンタクトがない場合、二次レプリカが一次レプリカと通信可能かどうか（７１２）、または二次レプリカがＤＩＳＣＯＮＮＥＣＴＥＤステートにあるかどうかについて判断がなされる。コンタクトが失われたときの一次レプリカのステートが、二次レプリカにＩＮ＿ＳＹＮＣであると知られているかどうかについての判断も可能である（７１４）。種々の実施形態で、判断は別個に、または実質的に同時にすることができる。二次レプリカが一次レプリカと通信できない場合、およびレプリカが同期されていた（例えば同一のＧＩ値を持った）場合、モニタリング構成要素は二次レプリカを新しい一次レプリカへレベルを上げるコマンドを発行する（７１６）。Ｐの最後のステートが判断できない場合、フェイルオーバは起こらない。プロセスまたはマシンがリブートした場合、または新しいモニタリング構成要素が引き継いだ場合は、モニタリング構成要素はＰのステートを知らないかもしれない。そのような場合では、ステートをＤＥＧＲＡＤＥＤとして扱うことが可能である。

二次レプリカを新しい一次レプリカへレベルを上げるとき、モニタリング構成要素は、二次レプリカのホストマネジャへ、ｐｒｏｍｏｔｅＴｏＰｒｉｍａｒｙ（ｏｌｄＧＩ）のようなコマンドを発行できる。この例で、「ｏｌｄＧＩ」は、一次レプリカのホストマネジャの最後に既知のＧＩである。この要求を受信すると、二次レプリカは一次レプリカと最後にもう一度通信を試みることができる。レプリカが通信不可能の場合、二次レプリカはその現在のＧＩが（一次レプリカの）ｏｌｄＧＩと同一であることを確認する（７１８）。二次レプリカはリース情報も確認可能で、それによって要求を発行またはステータス要求を送信するモニタリング構成要素は、そのレプリカの有効なモニタリング構成要素であるか、レプリカの現在の「リースホルダ」である。その場合、二次レプリカは自身のレベルを上げることが可能であることを確認し、適切なＢＬＲＭコマンドの発行により新しい一次となる（７２０）。二次レプリカは、ｐｒｏｍｏｔｅＴｏＰｒｉｍａｒｙ（）要求への応答として、新しいＧＩをモニタリング構成要素へ返す。その後、新しい（レベルを上げられた）一次レプリカのホストマネジャがファイルシステムをマウントし、データベース（例えばＭｙＳＱＬ）を開始する（７２２）。モニタリング構成要素が正常に二次レプリカのレベルを上げたとき、モニタリング構成要素または制御プレーンの他の構成要素により実行され得るように、ＤＮＳ＿ｐｒｉｍａｒｙ ｃｎａｍｅを、新しい一次レプリカに向けることができる（７２４）。その後、インスタンスステートを、二次リカバリの必要ありとマークを付けることができる（７２６）。

しかし、二次レプリカの現在のＧＩがｏｌｄＧＩと同一でない場合、二次レプリカを新しい一次レプリカになるようレベルを上げることは、安全ではないかもしれない。この場合、レベル上げのプロセスを異常終了させることができ、操作者の介入（または他の適切な修復作業）のため警報が生成される。操作者がこの問題を解決できない場合、データベースを最後の既知のポイントへリストアすることにより、ポイントインタイムリカバリを実行できる。

ダイアグラムを見て、多数の異なる障害の場合を判断できる。例えば、第１の障害の場合は、一次および二次レプリカが実行中であり、モニタリング構成要素との通信中である。モニタリング構成要素の観点からは、構成要素がそれぞれのインスタンスと最大Ｔ＿ｍｏｎｉｔｏｒｉｎｇ ｃｏｍｐｏｎｅｎｔ秒内のように周期的に通信可能である限り、全ては期待通り実行中である。この場合の一次のステートは、「ＩＮ＿ＳＹＮＣ／ＯＢＳＥＲＶＥＤ」であろう。

モニタリング構成要素および二次レプリカの間のネットワークリンクがパーティションされた障害の場合では、しかし、一次は二次およびモニタリング構成要素と通信可能であろうが、モニタリング構成要素は二次レプリカと通信不可能であろう。一次の観点からは、二次リカバリが開始されないよう、一次がなおＩＮ＿ＳＹＮＣ／ＯＢＳＥＲＶＥＤステートにあるように、全ての書き込みはなお成功である。モニタリング構成要素の観点からは、構成要素は二次障害を検出するが、一次はなお二次と同期され、それでモニタリング構成要素は実行および動作の必要がなく、単にレプリカとの通信の試みを続けることができる。

代わりに、ネットワークパーティションに応答する際のように、モニタリング構成要素が一次構成要素と通信不可能な場合、二次レプリカは一次レプリカおよびモニタリング構成要素と通信可能になるが、一次レプリカはモニタリング構成要素からアクセス不可能になる。一次の観点からは、ｎ＊Ｔ＿ｈｅａｒｔｂｅａｔ秒後、一次は、一次レプリカはモニタリング構成要素とコンタクトがなかったので、ＮＯＴ＿ＯＢＳＥＲＶＥＤステートに移る。いくつかの実施形態では、ｎの値はｎ≧２に設定できる。一次のステートは、よってＩＮ＿ＳＹＮＣ／ＮＯＴ＿ＯＢＳＥＲＶＥＤであり得る。モニタリング構成要素の観点からは、二次レプリカのみがアクセス可能であるが、モニタリング構成要素がフェイルオーバを開始しないように、二次レプリカはなお一次レプリカとコンタクトがある。

１つの例示的な障害のケースでは、ノード障害またはネットワークパーティショニングのような要因により、二次レプリカがダウンしているかもしれない。図８は、少なくとも１つの実施形態により使用可能な二次リカバリを実行する、プロセス８００の例を示す。この例は、レプリカがすでにプロビジョンされ、通信中で、同期されており、レプリカはモニタリング構成要素によりモニタされている（８０２）と仮定する。モニタリング構成要素が二次レプリカとのコンタクトを失う場合（８０４）、モニタリング構成要素は、有る一定期間リトライを試みることができる（８０６）。モニタリング構成要素がいつでも二次レプリカとコンタクトを取り戻す場合、プロセスは継続可能である。モニタリング構成要素が二次レプリカと一定の期間コンタクトがない場合、一次レプリカが二次レプリカと通信可能かどうかについて判断がなされる（８０８）。一次レプリカが二次レプリカと通信不可能である場合、一次はＴ＿ｓｙｎｃ秒後にＳＴＡＬＬＥＤステートになることが可能である（８１０）。ＳＴＡＬＬＥＤステートに入った後、一次レプリカはモニタリング構成要素からの通信を受けるため、ｎ＊Ｔ＿ｈｅａｒｔｂｅａｔ秒間待機できる。一次レプリカがこの時間単位（すなわち一次がＭＯＮＩＴＯＲＥＤステートにある）内にモニタリング構成要素から通信を受ける場合、一次はＤＥＧＲＡＤＥＤステートになり、次のハンドシェイクでモニタリング構成要素に通知する（８１２）。モニタリング構成要素の観点からは、ステートはＰ＿ＯＮＬＹになり、そこではモニタリング構成要素は二次レプリカがアクセス不可能であることを知る。これを決定すると、モニタリング構成要素は、ＮＥＥＤ＿ＳＥＣＯＮＤＡＲＹ＿ＲＥＣＯＶＥＲＹのようなステートとしてデータベースインスタンスの状態にマークをつけ、本明細書の他の箇所で述べるような二次レプリカリカバリワークフローを開始する（８１４）。

他の障害のケースでは、全てのホストが起動して実行可能であるが、データゾーンパーティションまたは不良ラックのアップリンクによるかもしれないように、モニタリング構成要素および二次レプリカから一次レプリカがパーティションされることがあり得る。よって、モニタリング構成要素は二次レプリカと通信可能であるが、モニタリング構成要素と二次レプリカのどちらも一次レプリカにアクセス不可能である。一次レプリカの観点からは、Ｔ＿ｓｙｎｃ時間単位の後、一次レプリカはＳＴＡＬＬＥＤステートに入る。ＳＴＡＬＬＥＤステートに入った後、一次レプリカは、ｎ＊Ｔ＿ｈｅａｒｔｂｅａｔ秒間モニタリング構成要素から通信を受けるため待機する。この場合、ＳＵＩＣＩＤＡＬステートに移り二次レプリカとして戻るときそのインスタンスをリブートすることにより自身を「ｋｉｌｌ」するよう、一次レプリカはモニタリング構成要素から通信を受けず、二次レプリカから切断される。モニタリング構成要素の観点からは、モニタリング構成要素はＳ＿ＯＮＬＹのステートに到達し、そこで一次レプリカがアクセス不可能であることを知る。モニタリング構成要素は、次のハンドシェイクに二次レプリカをチェックし、二次レプリカが一次レプリカと通信可能かどうか判断する。この場合、二次レプリカはＤＩＳＣＯＮＮＥＣＴＥＤステートにあることを宣言する。モニタリング構成要素は、Ｔ＿ｆａｉｌｏｖｅｒ秒間待機し、それから一次レプリカがなお利用不可であることを確認する。そうであれば、前のデータベースのステートがＩＮ＿ＳＹＮＣで、二次レプリカの現在のＧＩが一次レプリカの最後の既知のＧＩと同一である場合、モニタリング構成要素は二次レプリカが新しい一次レプリカへレベルを上げるようにさせる。Ｔ＿ｆａｉｌｏｖｅｒの時間値は、ｎ＊Ｔ＿ｈｅａｒｔｂｅａｔ＋Ｔ＿ｂｕｆｆｅｒに設定が可能で、ここでｎは先の場合で前述したものと同一のパラメータであり、ｎ≧２に設定される。Ｔ＿ｂｕｆｆｅｒは、一次レプリカが自身を「ｋｉｌｌ」するのに予想される最悪の場合の時間である。

一次がダウンして他に問題がない類似のケースでは、フェイルオーバもあり得る。この場合、しかし、一次レプリカがダウンして、ＳＵＩＣＩＤＡＬまたは他のそのようなステートにならないので、一次が変移ステートを有さない。

他の障害の場合では、一次および二次レプリカは予想通りネットワークの問題なしに機能および通信できるが、モニタリング構成要素がダウンする可能性があるか、またはそうでなければ、利用不可となる。一次の観点からは、全てがなおＩＮ＿ＳＹＮＣデータ同期ステートにあるが、一次レプリカはＮＯＴ＿ＯＢＳＥＲＶＥＤステートにあることを示す。

述べたように、制御プレーンは、ＲＤＳインスタンスをモニタし、必要があるとき適切なリカバリアクションを発行するよう構成されたイベントプロセッサの分散されたセット、またはイベント処理フリートを有する。図９は、種々の実施形態により使用可能な、モニタリング構成要素をＲＤＳインスタンスに割り振るプロセス９００の例を示す。そのようなプロセスでは、イベントプロセッサ、またはモニタリング構成要素の数（９０２）ならびにモニタされるＲＤＳインスタンスの数（９０４）を決定できる。これらの決定はどちらの順番でも、または平行しても可能で、ロード配分、再パーティショニング、などの目的で周期的に再決定が可能である。複製されたインスタンスを含むインスタンスの判断された数に関するモニタリングワークロードが、それから決定され、適切にパーティションされる（９０６）。いくつかの実施形態では、モニタリング構成要素は、データゾーン、地理的位置、または他のそのようなアスペクトによりグループ分けが可能である（９０８）。それぞれのモニタリング構成要素は、単純なハッシュベースパーティショニングアルゴリズムの採用によるような、ＲＤＳインスタンスのモニタリングワークロードの部分（またはパーティション）に割り当てが可能であり、そこではハッシングがＩｎｓｔａｎｃｅＩｄｅｎｔｉｆｉｅｒまたは類似の識別値に基いてなされる（９１０）。モニタリング構成要素がグループに割り当てられる場合、第１のデータゾーン内のグループを他のデータゾーン内のインスタンスなどをモニタするのに使用することができる。

それぞれのモニタリング構成要素を、そのモニタリング構成要素に割り当てられたそれぞれのインスタンス（複製または非複製）の正常性をモニタするよう構成できる（９１２）。モニタリング構成要素は、そのインスタンスに関連するそれぞれのレプリカにｐｉｎｇするか、またはそうでなければ通信することにより、種々の実施形態のＲＤＳインスタンスの正常性を判断できる。インスタンスが複製されていない場合、モニタリング構成要素はインスタンスの１つのホストマネジャと通信するだけでよい。本明細書で後に述べるように、モニタリング構成要素は「リース」を取得して、一定の期間与えられたインスタンスをモニタすることができる。モニタリング構成要素が障害を起こす場合、本明細書の他の箇所で述べるように、モニタリング構成要素のワークロードを均一にまたはそうでなければ他のモニタリング構成要素に再分散が可能である（９１４）。

複製されたインスタンスがあるとき、イベント処理フリート間のインスタンスモニタリングワークロードのパーティショニングに対して特別な検討事項があり得る。いくつかの実施形態では、モニタリングシステムは、インスタンスの数が増加するにつれて、実質的に直線的に拡張するべきである。この拡張は、さらなるイベントプロセッサ（例えばホスト）を追加することにより種々のインスタンス内で達成することができる。イベントプロセッサがそのイベントプロセッサによりモニタ中のデータベースのそれぞれのレプリカと異なるデータゾーン内に位置することが望ましい可能性があるので、イベントプロセッサの配置上の制約もある可能性がある。異なるデータゾーン内にイベントプロセッサを置くことにより、データセンタの障害は、同時に起こり、データベースを潜在的に回復不能なステートにさせる、２つの同時の障害（例えばモニタリング構成要素およびレプリカのうち少なくとも１つの故障）の結果とならない。全てのレプリカを含むそれぞれのデータベースインスタンスが、継続的にモニタされることを確実にするのも望ましい場合がある。これは、データベースインスタンスのパーティショニング、およびイベントプロセッサのうちの１つへのそれぞれのパーティションのモニタリングオーナシップの割り当てにより種々の実施形態で達成することができる。イベントプロセッサがいくつかの理由で障害を起こす場合、障害を起こしたイベントプロセッサに所有されモニタされるパーティションは、均一に他の可能なイベントプロセッサに再分散すべきである。

モニタリングシステムの直線状拡張性を確実にし、それでもイベントプロセッサの配置上の制約をなお満たすため、少なくとも１つの実施形態のイベント処理フリートは、それぞれのフリートが存在するデータゾーンに基づいて、異なるグループに区分化される。それぞれのグループは、グループ内のイベントプロセッサがそのレプリカがそれぞれのイベントプロセッサと同一のデータゾーン内にないＲＤＳインスタンスと関連付けられるよう、構成可能である。

１つの例として、４つのそれぞれのデータゾーン（ＤＺ１，ＤＺ２，ＤＺ３，およびＤＺ４）内のインスタンスをカバーする４つのイベントプロセッサグループ（Ｇ１，Ｇ２，Ｇ３，およびＧ４）が存在しうる。それぞれのレプリカペアについて、レプリカペアと同一のデータゾーン内にないグループの間で、モニタリングワークロードを割り振ることが可能である。この例で、そのレプリカペアがＤＺ２およびＤＺ３にあるＲＤＳインスタンスのモニタリングワークロードを、Ｇ１およびＧ４内のイベントプロセッサにわたり分割できる。ＤＺ３およびＤＺ４内のレプリカペアについて、ワークロードはグループＧ１およびＧ２間で分割できる。

与えられたデータゾーン内に位置する全ての複製されたデータベースについて、それぞれのイベントプロセッサはデータゾーンペアを独立してカバーするイベントプロセッサのリストを計算可能である。その後、所与のデータゾーンペアについて、データゾーンペアをカバーするイベントプロセッサ識別子を辞書的にソートできる。データベース識別子もソートし、ゾーンペアにわたり均一に分割が可能である。例えば、ゾーンＤＺ２およびＤＺ３内にレプリカがあるデータベースが存在しうる。これらのデータベースは、Ｇ１およびＧ４グループ内で一緒にイベントプロセッサによりモニタが可能である。簡略化のため、このデータゾーンペア内のデータベースのデータベース識別子は、（ＤＢ１，．．．，ＤＢ１０００）として設定でき、グループＧ１内に２つのイベントプロセッサ（ＥＰ１およびＥＰ２）が、グループＧ４内に２つのイベントプロセッサ（ＥＰ３およびＥＰ４）がそれぞれ存在する。この例で、ＥＰ１がブートストラップするとき、ＥＰ１はデータゾーンペア（ＤＺ２，ＤＺ３）内にモニタすべき１０００のデータベース、およびそれらをカバーする４つのイベントプロセッサがあると判断できる。イベントプロセッサ識別子を辞書的にソートすることにより、ＥＰ１はＤＢ１からＤＢ２５０を引き受けることが可能と判断でき、ＥＰ２はＤＢ２５１からＤＢ５００を引き受けることが可能で、ＥＰ３はＤＢ５０１からＤＢ７５０を引き受けることが可能で、ＥＰ４はＤＢ７５１からＤＢ１０００を引き受けることが可能である。ＥＰ１は同一のステップを繰り返し、ＥＰ１がモニタするのに適格な全てのレプリカペアのモニタリングを担当しているデータベースを判断することができる。

イベントプロセッサの障害を検出するため、それぞれのイベントプロセッサを、ＨＥＡＲＴＢＥＡＴメッセージ（例えばＨＴＴＰで）を、全ての他のイベントプロセッサに、１０秒毎のように周期的に送信するよう構成可能である。イベントプロセッサは、イベントプロセッサおよびそれらのステータス（例えばＡＶＡＩＬＡＢＬＥまたはＤＥＡＤ）のリストを、それぞれのイベントプロセッサのチェックイン時間とともに保持可能である。第１のイベントプロセッサが、通常はハートビート間隔の６倍のようなハートビート間隔の何倍かである、ｈｅａｒｔｂｅａｔ＿ｆａｉｌｕｒｅ＿ｔｉｍｅより長い時間他のイベントプロセッサから通信を受けていないとき、第１のイベントプロセッサは無応答のイベントプロセッサがＤＥＡＤまたは類似のステートにあると宣言でき、そのモニタリングワークロードを調整できる。無応答のイベントプロセッサホストが開始または復旧するとき、イベントプロセッサは、自身をｈｅａｒｔｂｅａｔ＿ｆａｉｌｕｒｅ＿ｔｉｍｅと同様の時間の間ＢＯＯＴＳＴＲＡＰまたは類似のモードで開始してそのピアイベントプロセッサからハートビートを受信でき、ハートビートエージェントを開始できる。この時間の後、イベントプロセッサは自身をＯＰＥＲＡＴＩＯＮＡＬモードに移すことができ、そこでは、そのパーティションに割り当てられたイベントプロセッサのステートに基いて、モニタリングワークロードの現在のスライスを判断する。イベントプロセッサを一定の期間ＢＯＯＴＳＴＲＡＰモードにしておく１つの理由は、イベントプロセッサ集団を接合する新しいイベントプロセッサ、および残りのイベントプロセッサが、アクティブなイベントプロセッサの現在のステートに集中する十分な時間を有することを確実にするためである。

データゾーンの障害の場合、障害を起こしたデータゾーン内のイベントプロセッサにより、モニタ中のインスタンスが、残りのグループにより引き継がれることを確実にするのが望ましい。１つの例では、４つのイベントプロセッサグループ（Ｇ１,Ｇ２，Ｇ３,およびＧ４）が、４つのデータゾーン（ＤＺ１，ＤＺ２，ＤＺ３，およびＤＺ４）内のイベントプロセッサをそれぞれカバーする。ＤＺ１が停止する場合、ＤＺ１内のイベントプロセッサによるインスタンスモニタリングを、他のデータゾーン内のイベントプロセッサによって自動的に引き継ぐことができる。

しかし、領域内に３つのデータゾーンと、データゾーンペア（ＤＺ２，ＤＺ３）、（ＤＺ３，ＤＺ１）、および（ＤＺ１，ＤＺ２）をモニタする３つのイベントプロセッサグループ（Ｇ１，Ｇ２，およびＧ３）しかないこともあり得る。ＤＺ１がダウンする場合、一次レプリカを含むデータゾーンの障害に耐性を持つため、それぞれのグループが、二次レプリカが自身と同一のデータゾーン内にあるインスタンスをモニタするような方法で、Ｇ２およびＧ３を再配備する必要がある。種々の実施形態で、データゾーンが３−ＤＺ領域内で故障しているときのみ、「ｓｅｃｏｎｄａｒｙ−ｄｚ−ｃｏｌｏｃａｔｉｏｎ−ｏｖｅｒｒｉｄｅ」のようなフラグをオンにすることができる。このフラグがオフになる場合、グループは、イベントプロセッサがレプリカペアと同一のデータゾーン内に存在できないという制約下で、モニタリングワークロードをパーティションする。フラグがオンであれば、グループは制約を無視して、自身を再配置し、二次レプリカが自身と同一のデータゾーン内にあるＲＤＳインスタンスを選択できる。このフラグは、制御プレーン内のモニタリングデータベースまたは類似のデータストア内で持続可能である。

特定のＲＤＳインスタンスをモニタするイベントプロセッサが１つだけあることを確実にすることも望ましい場合がある。いくつかの実施形態で、フェイルオーバアルゴリズムは、いかなる時でも単一のモニタリング構成要素（すなわちイベントプロセッサ）が、レプリカペアをモニタすることを要求する。ネットワークパーティションのどちらかのサイドが２つのイベントプロセッサを有し、１つのイベントプロセッサ１がＲＤＳインスタンスをフェイルオーバしようとし、他が一次がなお稼働中となり「頭脳分割」シナリオへ導くことは望ましくない可能性があるので、この制約を利用することができる。

１つのイベントプロセッサのみがＲＤＳインスタンスをモニタするのを確実にするため、コントロール環境のイベントプロセッサまたは他のモニタリング構成要素は、いくつかの実施形態でＲＤＳインスタンスの一次レプリカから「リース」を明確に取得することを要求される場合がある。他の実施形態では、モニタリング構成要素は、リースを管理しデータ環境内の種々の構成要素とやりとりするコントロール環境の他の構成要素から、リースを取得できる。例えば、ＲＤＳインスタンスの一次レプリカからリースを取得する場合のみ、イベントプロセッサは所与のＲＤＳインスタンスのフェイルオーバを開始するのに適格であり、またＴ＿ｌｅａｓｅのようなリース期間中のみである。

図１０は、種々の実施形態により使用可能な、そのようなリースを取得するプロセス１０００の例を示す。前述のように、モニタリング構成要素を、複製されたインスタンスのようなインスタンスをモニタするために割り当てが可能である（１００２）。モニタリング構成要素は、インスタンスにｐｉｎｇする、またはそうでなければそれと通信を試みるようにさせることができる（１００４）。インスタンスが複製されたインスタンスであれば、モニタリング構成要素は少なくとも一次レプリカと通信を試みることが可能である。ホストから通信を受信するホストが複製されたインスタンスの一次ホストであれば、ホストは、レプリカが同期し、インスタンスに対し通常は異なるモニタリング構成要素へ有効なリースが存在するかどうか（１００６）判断が可能である。少なくともいくつかの実施形態で全てのこれらの基準を満たさない場合、リースは取得されず（１００８）、制御プレーンおよび／またはデータプレーンの構成要素は、レプリカが利用不可であるような、あらゆる可能性がある問題を解決しようと試みることが可能である（１０１０）。少なくとも１つの実施形態で基準を満たす場合、モニタリング構成要素はレプリカのｐｉｎｇ（例えばＨＴＴＰステータスｐｉｎｇ（）の発行による）に応えて一次レプリカのホストからリース（または「リース」情報）を取得でき（１０１２）、それによってデータベースレプリカのホストマネジャが通常の応答に加えリースを分配する。例えば一次レプリカがリースをイベントプロセッサに分配するとき、一次レプリカはリース時間およびイベントプロセッサ識別子をＢＬＲＭドライブまたは一次の他のブロック記憶装置に書き込み可能である（１０１４）。同期のときＢＬＲＭディスクに書き込むことにより、一次レプリカは、二次レプリカに、モニタリング構成要素識別子（ＩＤ）およびリースの時間または期間を含んだリースを本来の性質としてで通知する（１０１６）。いくつかの実施形態では、一次レプリカは、リース時間およびイベントプロセッサ識別子が正常に書き込まれた（すなわち両方のレプリカ内に複製された）後でのみ新しいリースをイベントプロセッサに分配する。イベントプロセッサ識別子およびリース時間を両方のレプリカ内にリース分配前に書き込むことにより、イベントプロセッサリーススキームは一次レプリカのクラッシュ後に存続することが可能である。ＲＤＳインスタンスの二次レプリカは、少なくともいくつかの実施形態で、いつでもどんなリースも分配しない。二次レプリカは、要求が、識別子がそのＢＬＲＭドライブ内のものと同一のイベントプロセッサからのものである場合のみ、ｐｒｏｍｏｔｅＴｏＰｒｉｍａｒｙ（）または類似の要求を受け入れることができる。

イベントプロセッサがリブートする、または新しいホストが引き継ぐとき、イベントプロセッサは、ＲＤＳインスタンスのステート（前にモニタしていない）が、一次レプリカがＤＥＧＲＡＤＥＤモードであるＰ＿ＯＮＬＹであると仮定する。イベントプロセッサは一次および二次レプリカにｐｉｎｇしてデータベースの現在のステートを判断し、従ってそのステートを変更する。前述のように、一次レプリカがＤＥＧＲＡＤＥＤステートであると仮定される場合、イベントプロセッサはどんなフェイルオーバも開始しない。「悲観的」アプローチを取ることで、新しいイベントプロセッサが引き継ぐとき、誤りがより少なくなる。イベントプロセッサがリブートする、または新しいホストが引き継ぐとき、イベントプロセッサは所与のホストに関連したレプリカの両方にｐｉｎｇし、どのレプリカが現在のＢＬＲＭ一次か判断する。一度この情報が収集されると、イベントプロセッサは適切なｐＤＮＳ ＡＰＩに問い合わせ、ＤＮＳ＿ｐｒｉｍａｒｙ ＣＮＡＭＥが現在の一次レプリカを指すことを確実にすることができる。そうでなければ、イベントプロセッサはただちにフェイルオーバできる。このシナリオは、イベントプロセッサがフェイルオーバの途中で停止した場合に起こりうる。ＤＮＳキャッシングおよび他の影響によりＤＮＳ情報が正しくない可能性があるので、ｐＤＮＳ ＡＰＩが信頼できるデータベースを読み出す故に、ｐＤＮＳ ＡＰＩにＤＮＳ名を解決することなく問い合わることができる。しかし、一次および二次レプリカの両方が、自身が正当な一次レプリカであると考える、ありそうもない場合の際、操作者または責任がある技術者にメッセージを送るなどが可能である。

制御プレーン内のモニタリングデータベースは、モニタされる現在のアクティブなデータベースインスタンス、それぞれのインスタンスのタイプ（例えば複製された）、および異なる顧客に関するイベントについてイベントプロセッサが収集するあらゆるイベントのリストを格納できる。データベースの数が増加するにつれ、いくつかの実施形態では、単一のモニタリングデータベースを越えて拡張する必要がある。この目的を達成するために、モニタリングデータベース内の全てのテーブルをパーティションすることができる。モニタリングデータベースのパーティショニングを可能にするため、イベントプロセッサとともに「ｄｂパーティションマップ」を採用することができる。イベントプロセッサがデータベースインスタンスに関連するイベントで持続しなければならないとき、イベントプロセッサは「ｄｂパーティションマップ」を参照し、イベントの情報を書き込む適切なデータベースを判断することができる。

図１１は、１つの実施形態による、バケットのイベントプロセッサの正常性のモニタリング、およびイベントプロセッサのうちの１つの障害の扱いの例示的なプロセス１１００を示す。この例で、データプレーンについて、少なくとも１つのワークロードパーティションが判断される（１１０２）。モニタされるデータストア、インスタンス、ホストマネジャ、および他のそのような構成要素の数に少なくとも部分的に依存して、全体のワークロードを、任意の数の別個のパーティションにパーティションしてもよい。イベントプロセッサのセットをそれぞれのワークロードパーティションに割り当てることが可能で（１１０４）、セット内のそれぞれのイベントプロセッサは、割り当てられたパーティションの作業のそれぞれの部分に割り当てられる（１１０６）。適切な間隔で、それぞれのイベントプロセッサは、「ハートビート」メッセージ（例えばＨＴＴＰで）を、同一のワークロードパーティションをカバーする同一のセットまたはバケット内のイベントプロセッサへ送信する（１１０８）。ハートビートは、十秒ごとのような任意の適切な間隔で送信することができる。１つの実施形態の「ハートビート」は、他のイベントプロセッサにハートビートを送信中のイベントプロセッサのステータスを通知するため、バケット内のそれぞれのイベントプロセッサに送信される単純なマルチキャストメッセージを指す。イベントプロセッサは、イベントプロセッサおよびそれらのステータス（例えば「ａｖａｉｌａｂｌｅ」または「ｄｅａｄ」）とともにそれぞれのイベントプロセッサの最後のチェックイン時間のリストを保持することが可能である。バケット内のそれぞれのイベントプロセッサからハートビートが受信されたと判断されれば（９１０）、プロセスは継続できる。

しかし、同一のバケット内のイベントプロセッサがハートビートに応答しなかったと判断される場合、規定されたハートビート失敗時間（例えばハートビート間隔の６倍）の時間に等しい間、またはより長くイベントプロセッサがハートビートの送信に失敗したかどうかについて判断がなされる（１１１２）。特定されたハートビート失敗時間に達しなかった場合、プロセスは継続できる。イベントプロセッサからのハートビートなしにハートビート失敗時間に少なくとも達した場合、バケット内のそれぞれのアクティブなイベントプロセッサは、アクティブでないイベントプロセッサが「ｄｅａｄ」、または類似のステートにあると宣言することができ、責任範囲を再割り当てし、モニタリングワークロードの部分を引き継ぐことが可能である（１１１４）。バケット内の全てのアクティブイベントプロセッサが障害を起こしたイベントプロセッサからのハートビートメッセージの受信に失敗すると、イベントプロセッサは、割り当てられたワークロードをそれぞれ適切な量拡張して、「ｍｉｓｓｉｎｇ」のイベントプロセッサの作業を引き取ることができる。

図１２の例１２００に示されるように、モニタ中の４つのイベントプロセッサおよび６０，０００のインスタンスがある場合、それぞれのイベントプロセッサは１５，０００インスタンス（辞書順または識別子など他の適切な順番で順番付け可能）を扱う。イベントプロセッサのうちの１つが障害を起こす場合、それぞれのイベントプロセッサが今度は２０，０００のインスタンス（なお引き続いて識別子などにより順番付けられる）を扱うように、他の３つのイベントプロセッサが、それらの責任の範囲を再割り当てできる。よって、インスタンスは順番付けスキームを用いて順番付けられるので、イベントプロセッサはモニタされる順番付けスキームの範囲を調整可能で、マップを作る、またはそうでなければどの「新しい」インスタンスをモニタするか追跡する必要がない。モニタされる範囲は、例えばモニタリングデータストアに格納できる。ワークロードが（実質的に）均一にイベントプロセッサにわたり自動的に分散可能なので、そのようなアプローチは、インスタンスが追加されるまたは取り除かれる状況でも有益である。特定のバケット内のみのハートビートも、全体のハートビートメカニズムより効率的で保持しやすい可能性がある。

図１３は、付加的な処理能力を追加した結果、または障害を起こしたイベントプロセッサが復旧し、再度ワークロードの部分を扱うことが可能になった結果である可能性のある、イベントプロセッサがバケットに追加されるときの、バケットにわたる作業範囲の再割り当てのプロセス１３００の例を示す。イベントプロセッサは、イベントプロセッサホストのリスタートまたはリカバリ、またはホストが単にアクティブとされまたはバケットに追加されることによるなどして、アクティブになりうる（１３０２）。イベントプロセッサをバケットに追加することも可能である（１３０４）が、リカバリの場合、イベントプロセッサはすでにそのバケットに割り当てられているかもしれない。アクティブなイベントプロセッサがバケットに追加されると、イベントマネジャは、「ｂｏｏｔｓｔｒａｐ」モードのようなモードに（例えばハートビート失敗時間）一定の時間の間入り、バケット内のピアイベントプロセッサから受信して（１３０６）、バケット内でアクティブな他のイベントプロセッサについての情報を取得し、例えばハートビートを送信する時間を判断することができる。イベントプロセッサは、ハートビートエージェントに関与して、バケット内の他のイベントプロセッサへハートビートの送信を開始することもできる（１３０８）。この時間の後、ホストは自身を「ｏｐｅｒａｔｉｏｎａｌ」モードに移すことができ、そこでそれぞれのイベントプロセッサは作業範囲を再割り当てし、そのパーティションに割り当てられたイベントプロセッサのステートに基いてモニタリングワークロードのその現在のスライスを判断できる（１３１０）。イベントプロセッサを一定の期間「ｂｏｏｔｓｔｒａｐ」モードにしておく１つの理由は、イベントプロセッサ集団に接合する（または再接合する）新しいイベントプロセッサ、および残りのイベントプロセッサが、アクティブなイベントプロセッサの現在のステートに集中する十分な時間を有することを確実にするためである。

１つの実施形態によるアプローチは、それぞれのイベントプロセッサを能力の５０〜６０％で実行することによるように、イベントプロセッサをオーバーパーティションもする。そのようなアプローチは、少なくとも１つまたは２つのイベントプロセッサが、性能上で明らかな悪影響を有することなく、それぞれのバケット内で障害を起こすことを可能にする。障害を起こしたイベントプロセッサは、それぞれのホストがリブートする場合のように、最終的に再度可用になる。そのイベントプロセッサは、それから再度ハートビートの交換を開始でき、それによってバケット内の他のイベントプロセッサが、イベントプロセッサの存在を自動的に検出できる。割り当てられた作業は、前述のように、作業がバケット内で可能なイベントプロセッサの大きなセットにわたり比較的均一に分散されるように、自動的に再分散可能である。

前述の障害のケースに加え、種々の実施形態により対処可能な種々の他の障害モードがあり得る。例えば、一次のホストマネジャがオンラインに戻るとき、モニタリング構成要素が二次レプリカをすでにフェイルオーバしていなければ、一次レプリカは二次レプリカとして戻るので、それがＢＬＲＭステータスが「ｐｒｉｍａｒｙ／ｓｅｃｏｎｄａｒｙ」から「ｓｅｃｏｎｄａｒｙ／ｓｅｃｏｎｄａｒｙ」へ変化したのを知るように、一次レプリカインスタンスは、リブートするかもしれない。２つのレプリカの間でどちらが一次であるかを判断し、適切なｐｒｏｍｏｔｅＴｏＰｒｉｍａｒｙ（）コールをするかは、イベントプロセッサ（例えばモニタリング構成要素）次第である可能性がある。二次レプリカインスタンスがリブートすれば、モニタリング構成要素は二次が動作していないことを通知し、リカバリのインスタンスにマークをつけることができる。しかし、その間に、二次レプリカがオンラインに（リブート後）戻る場合、二次リカバリワークフローはこれを認知し、二次レプリカのホストマネジャに再接続を試みることを要求できる。これは、単純なインスタンスリブートシナリオについて新しい二次レプリカを作成する手間を避けることを可能にする。非複製のインスタンスがリブートすれば、ホストマネジャは、モニタリング構成要素にインスタンスのレベルを上げるよう要求することなく、自動的にそのステータスを二次から一次レプリカへ変換できる。これにより、非複製のインスタンスのインスタンスリブートのリカバリ時間を減少させることができる。

一次レプリカが障害を起こしてオンラインに戻らないとき、モニタリング構成要素は一次障害を検出して、二次レプリカを新しい一次にレベルを上げることができる。その後、モニタリング構成要素は、Ａｄｍｉｎデータストア内のＲＤＳインスタンスステートが、「ＰＥＮＤＩＮＧ／ＤＥＧＲＡＤＥＤ＿ＮＥＥＤ＿ＳＥＣＯＮＤＡＲＹ＿ＲＥＣＯＶＥＲＹ」のようなステートであるように、マークをつけることができる。このステートは、リカバリスイーパが適切なリカバリワークフローを開始させるようにさせ得る。リカバリワークフローは、両方のレプリカが動作中であるかどうか判断を試みることができる。モニタリング構成要素がレプリカを停止としてマークをつけるようにリブートが十分な量の時間がかかった場合のように、古い一次レプリカが二次レプリカとしてオンラインに戻ったならば、一度レプリカが完全に同期されると、ワークフローは古い一次レプリカを新しい一次と接続し、ＯＫのデータベースステートのようなリカバリ完了のマークをつけることができる。しかし、古い一次が全く戻らなければ、ワークフローは古いインスタンスを終了して、複製されたインスタンスの作成に関して記載したのと同一のステップを用いて、二次レプリカを派生させることが可能である。二次レプリカが障害を起こす場合、モニタリング構成要素は障害を検出して、Ａｄｍｉｎデータストア内のインスタンスステートが、「ＰＥＮＤＩＮＧ／ＤＥＧＲＡＤＥＤ＿ＮＥＥＤ＿ＳＥＣＯＮＤＡＲＹ＿ＲＥＣＯＶＥＲＹ」または類似のステートの使用によるような、リカバリワークフローのキックインによるステートであるように、マークをつけることができる。データベースがなんらかの理由でクラッシュするとき、一次レプリカのホストマネジャはナニープロセスとしてはたらき、データベースを自動的にリスタートする。

述べたように、モニタリングワークロードのそれぞれのパーティションをイベントプロセッサのセットでカバーすることが可能である。イベントプロセッサのセットでのワークロードの単一のパーティションのカバーは、イベントプロセッサのうちの１つが障害またはさまざまな他のそのような問題を経験する場合、残りのイベントプロセッサにわたるモニタリングの負荷の再分散を可能にする。１つの実施形態では、イベントプロセッサのそれぞれのグループは、バケットまたは他のそのようなパーティション内に含まれる。バケット内のそれぞれのイベントプロセッサは、単一のデータプレーン内のインスタンスの範囲の扱い、またはそのプレーン内のインスタンスのグループ化に関与する。障害検出プロセスは、障害が起こる場合、そのバケット内の他のイベントプロセッサが、障害を起こしたイベントプロセッサにより扱われるインスタンスの責任を引き継ぐことを確実にするために使用可能である。少なくとも１つの実施形態のモニタリングデータストアは、バケット内のイベントプロセッサのセットによりモニタされる現在のアクティブなデータインスタンスのリスト、ならびにイベントプロセッサが種々の顧客に関するイベントについて収集する情報を保持する。モニタされるインスタンスの数が増加するにつれ、単一のモニタリングデータストアを越えて拡張する必要がある可能性がある。よって、モニタリングデータストア内のそれぞれのテーブルを、ｄｂ＿ｐｏｌｌ＿ｌｉｓｔを含んでパーティションすることができる。

１つの実施形態では、イベントプロセッサは以下の例示的な形式のパーティションテーブルで配備される。
パーティション Ｉｄ ハッシュ範囲
Ｐ０ ０−１００００
Ｐ１ １００００−２００００
このパーティション構成は、構成ファイルとしてイベントプロセッサホストに配備することができる。

所与のワークロードパーティションが一定の責任があるイベントプロセッサのセットをキャッチアップモード（すなわち特定の時間内に割り当てられた正常性チェックを終了不可）とさせる多数のイベントを生成する場合、データストアを再パーティションする必要なく、そのワークロードパーティションの責任があるセットにさらなるイベントプロセッサを追加可能である。そのような技術を用いて、実行拡張性はデータ拡張性の問題から区別することができる。例えば、多くのイベントを生成するのでイベントプロセッサがキャッチアップできない１つのパーティションを、多くのイベントを生成するので、１つのデータストアが十分な記憶スペースを提供しない１つのパーティションの状況から区別することができる。

イベントプロセッサが割り当てられるイベントプロセッサおよびパーティションのメンバーシップは、イベントプロセッサメンバーシップ構成ファイルのような場所に格納可能である。メンバーシップ構成情報は、（同一のパーティションまたはバケット内のような）グループ内のイベントプロセッサへ配備することができ、以下の例示的なフォーマットを有することができる。
＜ＥＰ識別子＞ ＜ＥＰホスト名＞ ＜ｅｎｄｐｏｉｎｔ＿ｐｏｒｔ＞ ＜パーティションＩｄ＞
１つのパーティションが複数イベントプロセッサにカバーされるとき、それぞれのイベントプロセッサは、辞書的またはハッシュベースのソートルーチンを用いることによるようなイベントプロセッサ識別子のソート、およびバケット範囲を均一に分けることにより、バケット範囲を分割する。それぞれのイベントプロセッサは、モニタされる適切な範囲を独立して判断することができる。

そのようなシステムで、モニタされるデータストアおよび／またはインスタンスのリストまたはセットが、自動的に投入され、時間とともに更新されることを確実にすることも、重要であり得る。１つのアプローチは、例えば、必要に応じ伝達可能なインスタンスのスナップショットレプリカであるデータベースリストテーブルの作成であろう。しかし、そのようなアプローチは、維持ならびにそれぞれの適切な構成要素が最新のコピーを有することを確実にすることが困難である可能性がある。他のアプローチは、イベントプロセッサにデータプレーン構成要素へ問い合わせをさせ、それから制御プレーン内に情報をローカルに格納することであろう。そのようなアプローチは、多量のメッセージ通信量を生じ、維持および更新が困難である可能性がある。１つの実施形態によるアプローチは、代わりに、それぞれのイベントプロセッサが、「ｓｅｔＳｔａｔｕｓ」または類似のＡＰＩのようなインタフェースを外部に表すことを可能にする。例えば「ｃｒｅａｔｅ」または「ｄｅｌｅｔｅ」ワークフローの部分として、タスクを、適切なホストマネジャにインスタンスの管理を担当しているまたはしていたイベントプロセッサをコールするよう指示するワークフローの最後に追加することができる。ホストマネジャは、よって、ワークフロー（または他のそのようなアクション）の結果としてステータスに変化があるときはいつでも、イベントプロセッサの「ｓｅｔＳｔａｔｕｓ」ＡＰＩをコールし、ホストのステータスを設定することができる。イベントプロセッサが「ｓｅｔＳｔａｔｕｓ」ＡＰＩを通してコールを受信する毎に、そのパーティションのセットへの新しいホストの追加、ホストの削除などのため、情報をローカルデータストア内におくことができる。ホストについての情報も、モニタリングデータストアまたは他の適切な持続する場所に書き込むことができる。

１つの実施形態では、現在のアクティブデータインスタンスの信頼すべきリストが、Ａｄｍｉｎデータストア内に存在する。モニタされるデータインスタンスのアクティブリストが、「ｄｂ＿ｐｏｌｌ＿ｌｉｓｔ」テーブルのようなテーブル内のモニタリングデータストア内に存在する。モニタリングデータストア内のインスタンスのステータスを追加、削除、または更新するため、イベントプロセッサは、データストア識別子、パラメータに関するデータインスタンス（例えばインスタンス識別子およびＤＮＳアドレス）、およびインスタンスステータス（例えば「ａｄｄ」，「ｒｅｍｏｖｅ」、または「ｕｐｄａｔｅ」）のようなパラメータを受け入れる「ｕｐｄａｔｅＨｏｓｔ」ＡＰＩを外部に表す。イベントプロセッサがこのコールを受信するとき、イベントプロセッサは、「ｄｂ＿ｐｏｌｌ＿ｌｉｓｔ」テーブルに適切な変更（例えばエントリを追加、削除、または更新）を加える。例えば、顧客がデータストアｉｄ「ｉｄ１」でデータストアを作成する要求を提出する場合、データストア作成のワークフローは、必要なリソースをプロビジョンしデータストアを構成すると、Ａｄｍｉｎデータストア内で「ａｖａｉｌａｂｌｅ」（可用）としてｉｄ１のステートにマークをつける。データベース生成ワークフロータスクの最終ステップとして、イベントプロセッサのうちの１つで、内部の仮想ＩＰを通しての到達による等でｕｐｄａｔｅＨｏｓｔＡＰＩを起動し、データストア（およびそのインスタンス）をモニタリングワークフローに追加することができる。モニタリングステータスを更新することにより、プロビジョニングワークフロー内の最終（または少なくとも最終に近い）ステップ、ＲＤＳデータストアの生成、削除または修正が、モニタリングデータストアの可用性から切り離される。

一度ホストマネジャがモニタされるアクティブインスタンスのステータスを設定セットすると、責任があるイベントプロセッサは本明細書の他の箇所で述べるように、インスタンスのホストマネジャに周期的にｐｉｎｇ可能である。ホストマシンのクラッシュまたはリブートに起因しうるなどでインスタンスが利用不可の場合、イベントプロセッサはインスタンスの応答を得ず、Ａｄｍｉｎデータストアへ可能性がある問題についての情報を書き込む。スイーパが情報を検出し、適切なリカバリワークフローが生成および実行されるようにさせる。１つの実施形態では、リカバリワークフローはまず、インスタンスのＩ／Ｏエラーのヒストリを詳記する情報のような、データストアまたはデータインスタンスのメトリックのヒストリを調べる。ワークフローは、それから、接続エラーがある場合のように、インスタンスがダウンしているかどうか、またはそれは接続の問題ではないが、インスタンスを支持する特定のボリュームとの可能性がある問題を示すＩ／Ｏエラーの数が増えているかどうか、自動的に判断を試みる。ワークフローのタスクは、多数の異なる構成要素について起こりうる多数の異なる問題がある場合、自動的に問題を判断および／または切り離しを試みることが可能である。そのような判断ならびにそのような問題からの復旧は、ささいな問題ではない。

しかし、自動的に障害から復旧することが望ましくないことがあり得る状況があり得る。例えば、何千ものデータストアが利用不可になるデータストア全体の障害があり得る。全てのこれらのデータストアを実質的に同時に復旧するよう試みるのは、望ましくない場合がある。１つの実施形態では、スイーパ（または制御プレーンの他の構成要素）を、エラー、または特定のタイプのワークフローの同時実行の最大数と共に構成することが可能である。例えば、ワークフローの数が特定された数または閾値を超える場合、メッセージまたは他のそのような通知を送信、またはそうでなければ操作者またはＤＢＡに対し生成することができ、それによって、経験があるユーザが、その状況を解決する最善のアプローチを判断できる。１つの実施形態では、スイーパはいかなる時点でも、１０の同一のタイプの所与のタイプのワークフローのように、最大で特定された数のワークフローを実行するが、２５のような第２の数の同一のタイプのワークフローが要求されるまでアラームを生成しない。１つの実施形態によるシステムは、ＤＢＡまたは他の権限を与えられた操作者がモニタリングプロセスのステートを評価でき、手動でリカバリアクションを実行することができる運用サービスダッシュボードを提供する。そのようなインタフェースを用いて、ＤＢＡは、本明細書で述べたように、特定のリカバリアクションを実行するワークフローをキックオフ可能にするオプションを選択することが可能である。インタフェースは、制御プレーンがデータプレーンのデータパス内にないが、制御プレーンとともに、複数の異なるデータベースエンジンおよびシステムと作業するために使用できる。制御プレーンは、例えばそれぞれのエンジンについてのエラーメッセージおよびログをモニタすることができる。そのようなアプローチは、それぞれのデータストアを全体としてモニタすることも可能にでき、同時にデータストアのあらゆるレプリカをモニタする。異なるリカバリが、レプリカのステートなどに基づいて、それから実行可能である。

データストアまたはデータインスタンスの非可用性または非信頼性といった結果になる可能性がある、さまざまなタイプの障害があり得ることを認識するべきである。例えば、ホスト装置は障害を起こしまたはリブートするかもしれず、またはインスタンスを管理するホストマネジャアプリケーションで問題があるかもしれない。データストアでも、コアダンプまたはセグメンテーション違反（ＳｅｇＶ）例外のような問題があり得る。Ｉ／Ｏ動作または通信パスでも問題があり得、またはデータストアを提供するインスタンスの障害があり得る。論理ボリュームの障害、ネットワーク故障、またはデータゾーンの障害のような種々の他のタイプの障害もあり得る。異なる障害のタイプを判断および復旧する試みのために、異なるワークフローを使用できる。１つの例では、１つの実施形態のホストマネジャは、それぞれのデータインスタンスへのゲートウェイであり、このホストマネジャの障害は、そのインスタンス上に基本的に制御を許さない。Ｔｏｍｃａｔプロセスがメモリ不足となるような障害に対処するため、制御プレーンのモニタリング構成要素は、必要であればＴｏｍｃａｔがリスタートされたことを確実にすることができる。モニタリングシステムは、不必要なエラーまたはエラー検出を避けるため、リスタートを調整できる。

さらに、述べたように、障害のサイズまたはスケールのような他の因子も検討しなければならないので、障害を単に検出および復旧するのでは不十分である。例えば、データストアを提供する単一のクラウドインスタンスの障害のリカバリアクションは、データゾーン全体の障害に対処するリカバリアクションと大幅に異なる可能性がある。より大きい問題について、同時に種々のインスタンスを個別に復旧しようとすることによりリカバリアクションが既存の問題と混ざらないように、複数の障害を関連付けて分析する必要があるかもしれない。一部の場合、データが失われず、その後のリカバリアクションにより後に修正される必要があるリカバリアクションが行われないように、並行プロセスの数を限定するだけでなく、プロセスの順序を制御できる、段階的リカバリの実行が望ましいかもしれない。一部の場合、可能なかぎりリカバリプロセスをローカル化することも望ましい可能性がある。少なくともいくつかの実施形態で、可能なときは安全な方法でローカルに障害に対処することが、有益であり得る。例えば、ホストマネジャまたはデータプロセスの障害のような単純な障害に対するローカルリカバリアクションは、ＲＤＳシステム全体のＡｄｍｉｎスタックにより実行されるアクションが望ましい可能性がある。

データインスタンス、データストア、またはＩ／Ｏプロセスが障害を起こす種々の理由があり得、それぞれが異なるリカバリ動作を必要とするかもしれない。例えば、データストアのバグはデータストアの障害を引き起こす、または少なくともかなりの数の読み出し／書き込みエラーを生む可能性がある。データストアまたはインスタンスは、オーバーロード、不良ブロック、または他のそのような状況によっても障害を起こす可能性がある。データストアをクラッシュする結果となる不適切な問い合わせのような、ユーザが誘発するエラーもあり得る。他の場合、データストアログボリュームがあふれるまたは破損するかもしれない。これらおよび他のタイプの障害に対処するため、データプロセスをホストマネジャから常にモニタできる。述べたように、それぞれのホストマネジャは、ｇｅｔｓｔａｔｕｓコマンド（例えばＭｙＳＱＬに関してこれは／ｂｉｎ／ｍｙｓｑ１＿ａｄｍｉｎステータスの形をとりうる）の実行によるような、データストアまたはインスタンスのステータスをチェックするステータスモニタリング構成要素を有することができる。ステータスモニタリング構成要素は周期的にステータスをチェックでき、インスタンスが利用不可であれば、そのときインスタンスをリスタート、またはそうでなければ、対処することができる。インスタンスが繰り返し利用不可になる場合、または他のそのようなエラーを経験する場合は、ステータスモニタリング構成要素はエラーを修正する試みをやめ、情報の制御プレーン内のモニタリングまたはａｄｍｉｎデータストアへの書き込みをさせることができる。

データストアエラーおよびＩ／Ｏクラッシュを検出するため、いくつかの実施形態では、データストアエラーログおよび／またはカーネルログをモニタすることができる。それぞれのホストマネジャは、これらの２つの（または他の）エラーログ内の特定のエラータイプについて継続的にスキャンし、関連するメトリックを生成する他のモジュールを実行できる。それぞれのエラータイプに対し、予め定義された閾値を設定することができ、それを越えると、分析および可能なリカバリのため、エラーが操作者に送信される。

１つの実施形態による障害検出メカニズムには、多数の制約が適用される。例えば、データインスタンスの数がイベントプロセッサのバケットがポーリングするよう設定されるホストの数を越えるとき、例えば、付加的なモニタリング構成要素を所望に応じて単純に追加できるように、モニタリング構成要素が直線的に拡張するよう構成が可能である。さらに、データインスタンスのパーティショニングおよびイベントプロセッサのうちの１つへのそれぞれのパーティションのモニタリング所有権の割り当てによるように、全てのデータインスタンスが常にモニタされるよう確立することができる。述べたように、イベントプロセッサがいずれかの理由で障害を起こす場合、障害を起こしたイベントプロセッサにより所有されモニタされるパーティションを、同一のバケット内のプロセッサのような他の可能なイベントプロセッサに均一に再分散できる。また、ＲＤＳ顧客がデータストアおよび／またはインスタンスを作成および削除するので、タスクをワークフローに追加することにより、データベースインスタンスのリストを最新に保つことができる。

データストアパーティショニング
高度に拡張性がある分散システム内で公知のように、データストア内のパーティショニングは、データストアシステムが存在する物理的システムの限界までのみ拡張される。この限界により、システムが単一のデータ記憶システム内、ならびに多くのデータ記憶システムにわたる、両方で拡張できるような方法で、予めシステムを構造化することが望ましい可能性がある。異なるデータ記憶システムにわたるデータの水平パーティショニングは、イベント記憶でかなりの要求を扱うことが可能な、高度に拡張性があるシステムに寄与できる。

１つの実施形態によるシステムは、ｃｕｓｔｏｍｅｒ＿ｉｄを、データベースインスタンスのリスト（ｄｂ＿ｐｏｌｌ＿ｌｉｓｔ）、関連するイベント（ｄｂ＿ｅｖｅｎｔｓテーブル）、およびセキュリティグループイベントテーブルを含むデータテーブルを、パーティションするパーティションキーとして利用する。いくつかのイベントは単一のデータストアに制限されず、特定のデータストアに関係しないかもしれないので、データストア識別子よりも顧客識別子を使用することが、好都合であり得る。例えば、セキュリティグループ内の変化は直接どんなデータストアにも適用されないが、顧客が視認可能なイベント（すなわちＤｅｓｃｒｉｂｅＥｖｅｎｔｓ ＡＰＩを用いて取得可能）として格納する必要があるかもしれない。さらに、いくつかの実施形態で、イベントデータは１４日間のような限定された期間の間のみ保持されるので、１つの顧客のイベントが単一のデータストアの記憶スペースを越えて大きくならなり得ない。

バケットパーティショニングの使用によるような、水平データストアパーティションにわたるデータセットのパーティショニングを扱う多数の方法がある。バケットパーティショニングは、パーティションされるデータとデータが格納されるパーティションの間に抽象層を提供する。この抽象層は、新しいパーティションの追加とデータの時間に伴う移動のような、パーティションのより容易な運用面の管理を可能にし、一方で、なおアプリケーションに対しパーティションされたデータの配置を判断するハッシングメカニズムの使用を可能にする。本明細書に記載されたバケットパーティションシステムの実施は、ある実施形態に特定の構成要素を含むが、明らかなように、全体の概念は多くの異なる使用ケースに適用可能である。

バケットパーティショニングの実行のため、アプリケーションが使用できるバケットの一定の数を決定することができる。バケットの数は、アプリケーションの有効期間にわたり一定を保つことができ、そのため、ある実施形態では十分大きい数の選択が重要であり得る。バケットの数は、より小さい数の物理パーティションに個々に割り当て可能な、全てのバケットにわたり負荷を均一に配分する能力に影響し得る。同一のバケットに個々の多すぎるインスタンスが割り当てられている場合、１つのパーティション内に複数のバケットを効率的に格納することが問題になりうる。一定の数のバケットは、パーティションされるデータとパーティション自身の間の中間層としてはたらくことができる。層化の第１のステップは、異なる個々のデータを種々のバケットにマッピングする方法を見つけることである。前述のように、データのパーティションキーは、顧客識別子であり得る。効率的および一貫したハッシュアルゴリズムを使用して個々のバケットに直接割り当て可能な値を提供することができる。顧客識別子がバケットに割り当てられた値をハッシュするときはいつも、その識別子はデータの有効期間中そのバケット内で存続することができる。

この例で、バケットは個々のワークロードパーティションに割り当てられる。常にパーティションより多いバケットがある可能性があり、それで、個々のパーティションに多くの異なるバケットを割り当てるために、マッピングを使用することができる。割り当て構成を簡潔にするため、バケット番号の範囲を使用してバケットを個々のパーティションに割り当てることができる。以下は、どのようにパーティショニング割り当てが機能できるかを示す例示的な表である。

パーティション１＝｛１−２５０００｝
パーティション２＝｛２５００１−５００００｝

この例で、バケット番号１から２５，０００は、「パーティション１」に割り当てられ、一方でバケット番号２５，００１から５０，０００は、「パーティション２」に割り当てられる 例えば、データをシステムに追加する必要があり、顧客識別子のハッシュがワークフローインスタンスをバケット１００にマッピングするときはいつでも、その顧客に関連するいかなるデータ（データストアおよびセキュリティグループを含む）も、物理的に「パーティション１」内に存続するテーブル内に挿入できる そのようなアプローチは、識別子がバケット１００にハッシュする与えられた顧客についてのイベントの要求が「パーティション１」から読み出される、顧客のデータベースまたはセキュリティグループに関するいかなる情報の読み出しにも使用可能である。

前述の例は、パーティションへのバケットの最初の割り当てが変更されない比較的単純な場合を扱う。しかし、ときどき、他のパーティションの負荷を軽減するため、新しいパーティションをシステムに追加する必要がある。上述のこの例を用いて、新しいパーティション「パーティション３」を追加し、他の２つのパーティションの負荷を取り去ることができる。

パーティション１＝｛１−１６６６６｝
パーティション２＝｛３３３３３−５００００｝
パーティション３＝｛１６６６７−３３３３３｝

ここで見られるように、８３３４のバケット（番号１６６６７から２５０００）が、「パーティション１」から取り除かれて、「パーティション３」に再割り当てされている。また、８３３３の付加されたバケット（番号２５００１から３３３３３）が、「パーティション２」から取り除かれて、「パーティション３」に再割り当てされている。この再割り当ては、最も多くアクセスされ、最も満杯であったバケットに基づいて行うことができ得たが、この例では、パーティションにわたる比較的均一なバケットの再分散があった。

バケット割り当てが変化するので、物理パーティション内に存在するデータが影響を受ける可能性がある。前記の例で、バケット１００は、識別子が１００にハッシュされた顧客の情報を格納するために使用された。この再パーティショニングシナリオでは、バケット１００が「パーティション１」に留まるので、データは影響されないだろう しかし、バケット１１０００内にデータがあったかもしれず、再パーティショニング前に書き込まれたデータが「パーティション１」内に存在するが、再パーティショニング後に書き込まれたデータは「パーティション３」内に存在する。前のデータが１つのパーティション内に存在し現在のデータが他のパーティション内に存在する問題を解決するため、システムは２つ以上のパーティションをバケットに割り当てることを可能にできる。所与のバケットは、少なくとも、現在のパーティションおよび前のパーティションの２つのパーティションを有する。この例では、再パーティショニングは、「パーティション３」が現在のパーティションとして、「パーティション１」が前のパーティションとして、割り当てられた２つのパーティションを有するバケット１０００１から１５０００の結果になるだろう。述べたように、バケット１１０００のいかなる新しいデータも現在のパーティションにあり、一方で再パーティショニング前に書き込まれたデータは前のパーティションにある。イベントのクエリまたはいずれかの情報がバケット１１０００へマッピングするとき、そのデータの現在のパーティションのチェック、ならびに、記録が同じように存在する可能性があるので、前のパーティションのチェックが重要になりうる。バケット内の複数のパーティション検索へのそのような対応は、与えられたバケットの前のパーティション内に最終的に存在することとなるインスタンスに対するミスの損失を生じる可能性がある。しかしながら、新しく作成されるイベントは現在のパーティションに書き込み中であるので、ミスの損失は、再パーティショニングが起こるかまたは閉じたワークフローに関するとき、実行中のワークフローインスタンスに対してのみ起こる。好都合な新しく作成されるイベントを優先することは性能を向上し、一方でなお再パーティショニングを効率的にする柔軟性を可能にする。

前述のように、種々の実施形態が多岐にわたる運用環境内で実行可能であり、一部の場合では、１つまたは複数のユーザコンピュータ、計算装置、または、多数のアプリケーションのいずれも作動するため使用可能な処理装置を有することができる。ユーザまたはクライアント装置は、標準オペレーティングシステムを実行する任意の数のデスクトップまたはラップトップコンピュータのような汎用パーソナルコンピュータ、ならびにモバイルソフトウェアを実行し、多数のネットワーキングおよびメッセージングプロトコルを補助可能なセルラー、無線、およびハンドヘルド装置を含むことが可能である。そのようなシステムは、開発およびデータベース管理のような目的のための、さまざまな市販されているオペレーティングシステムおよび他の公知のアプリケーションを実行する多数のワークステーションも含むことが可能である。これらの装置は、ダミー端末、シンクライアント、ゲームシステム、およびネットワークを介して通信可能な他の装置のような、他の電子装置も含むことが可能である。

種々の態様は、サービス指向アーキテクチャの部分であるかもしれないような、少なくとも１つのサービスまたはＷｅｂサービスの部分としても実行可能である。Ｗｅｂサービスのようなサービスは、拡張可能なマークアップ言語（ＸＭＬ）フォーマットの、ＳＯＡＰ（「シンプルオブジェクトアクセスプロトコル」から由来）のような適切なプロトコルを用いて変換されたメッセージの使用によるような、あらゆる適切なタイプのメッセージングを用いて通信可能である。そのようなサービスにより提供されまたは実行されるプロセスは、ウェブサービス記述言語（ＷＳＤＬ）のようなあらゆる適切な言語で記述することができる。ＷＳＤＬのような言語の使用は、種々のＳＯＡＰフレームワーク内のクライアントサイドコードの自動生成のような機能を可能にする。

大半の実施形態は、ＴＣＰ／ＩＰ、ＯＳＩ、ＦＴＰ、ＵＰｎＰ、ＮＦＳ、ＣＩＦＳ、およびＡｐｐｌｅＴａｌｋのような、あらゆるさまざまな市販されているプロトコルを用いて通信を補助する当業者が精通する少なくとも１つのネットワークを使用する。ネットワークは、例えば、ローカルエリアネットワーク、広域ネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、およびそのあらゆる組み合わせであり得る。

Ｗｅｂサーバを利用する実施形態において、Ｗｅｂサーバは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データサーバ、Ｊａｖａサーバ、およびビジネスアプリケーションサーバを含むさまざまなサーバまたは中間層アプリケーションを実行可能である。サーバはまた、ユーザ装置からの要求に応答して、Ｊａｖａ（登録商標）、Ｃ、Ｃ＃またはＣ＋＋のようなあらゆるプログラミング言語、またはＰｅｒｌ、Ｐｙｔｈｏｎ、またはＴＣのようなあらゆる記述言語ならびにそれらの組み合わせで記述された、１つまたは複数のスクリプトまたはプログラムとして実行してもよい１つまたは複数のＷｅｂアプリケーションの実行によるように、プログラムまたはスクリプトを実行可能であり得る。サーバは、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、ｓｙｂａｓｅ（登録商標）、およびＩＢＭ（登録商標）からのデータベースサーバも含んでもよいが、これらに限定されない。

環境は、前述ように、さまざまなデータストアおよび他のメモリおよび記憶媒体を含むことが可能である。これらは、１つまたは複数のコンピュータにローカルな（および／または存在する）、またはネットワークを越えていくつかまたは全てのコンピュータからリモートの記憶媒体のようなさまざまな場所に存在することができる。実施形態の特定のセットにおいて、情報を、当業者が精通するストレージエリアネットワーク（「ＳＡＮ」）内に存在させてもよい。同様に、コンピュータ、サーバ、または他のネットワーク装置に帰する機能を実行するためのあらゆる必要なファイルを、ローカルでおよび／またはリモートで適切に格納してもよい。システムがコンピュータ装置を有する場合、それぞれのそのような装置は、バスを介して接続してもよいハードウェア構成要素を含んでもよく、構成要素は、例えば、少なくとも１つの中央処理ユニット（ＣＰＵ）、少なくとも１つの入力装置（例えばマウス、キーボード、コントローラ、タッチスクリーン、またはキーパッド）、および少なくとも１つの出力装置（例えばディスプレイ装置、プリンタ、またはスピーカ）を含む。そのようなシステムは、ディスクドライブ、光記憶装置、およびランダムアクセスメモリ（「ＲＡＭ」）または読み出し専用メモリ（「ＲＯＭ」）のような固体記憶装置、ならびに着脱可能な媒体装置、メモリカード、フラッシュカードなどのような、１つまたは複数の記憶装置も含んでもよい。

そのような装置は、前述のように、コンピュータ可読な記憶媒体リーダ、通信装置（例えばモデム、ネットワークカード（無線または有線）、赤外線通信装置、など）、および作業メモリも含むことができる。コンピュータ可読な記憶媒体リーダは、リモート、ローカル、固定、および着脱可能な記憶装置を表すコンピュータ可読な記憶媒体、ならびにコンピュータ可読な情報を一時的におよび／またはより永続的に含有、格納、伝達および検索する記憶媒体と接続可能、または受信するよう構成可能である。システムおよび種々の装置は、通常、クライアントアプリケーションまたはＷｅｂブラウザのようなオペレーティングシステムおよびアプリケーションプログラムを含む、多数のソフトウェアアプリケーション、モジュール、サービス、または少なくとも１つのワーキングメモリ装置内に位置する他の構成要素を有する。代替の実施形態は、前述から多数の変形を有してもよいことを理解すべきである。例えば、カスタマイズされたハードウェアも使用してよく、および／または特定の構成要素を、ハードウェア、ソフトウェア（アプレットのような持ち運び可能なソフトウェアを含む）、または両方で実行してもよい。さらに、ネットワーク入／出力装置のような他の計算装置への接続装置を採用してもよい。

コードまたはコードの部分のための記憶媒体およびコンピュータ可読な媒体は、コンピュータ可読な命令、データ構造、プログラムモジュール、または他のデータのような情報のあらゆる記憶および／または伝達方法または技術で実行される揮発性および不揮発性、着脱可能および着脱不可媒体のような、けれどもそれらに限定されない、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、または所望の情報を格納するのに使用可能でシステム装置によりアクセス可能なあらゆる他の媒体を含む記憶媒体および通信媒体を含む、当業界で公知または使用されるあらゆる適切な媒体を含むことが可能である。本明細書で提供される開示および教示に基づき、当業者は種々の実施形態を実行する他の仕方および／または方法を理解するだろう。

明細書および図は、従って、限定的な意味よりむしろ例示とみなされる。しかし、これらへの種々の改良および変更を、請求項に記載したより広い本発明の趣旨および範囲から逸脱することなく、してもよいことは明らかである。

付記項１
実行可能な命令で構成される１つまたは複数のコンピュータシステムの制御下で、
データベース環境内の複数の複製されたデータベースインスタンスのそれぞれを複数のワークロードパーティションのうちの１つに割り当てることと、
コントロール環境内の複数のモニタリング構成要素のうちの１つを前記複数のワークロードパーティションのそれぞれに割り当てることと、
パーティション内の複製されたインスタンスのそれぞれに関して、
割り当てられた前記モニタリング構成要素に、前記複製されたインスタンスの一次インスタンスレプリカのホストマネジャへの通信の送信をさせることと、
前記一次インスタンスレプリカのデータが、前記複製されたインスタンスの
二次インスタンスレプリカと同期されている場合、前記割り当てられたモニタリング構成要素に前記複製されたインスタンスのリースを受けとり、前記リースは、前記割り当てられたモニタリング構成要素が前記複製されたインスタンスをモニタできるリース期間を少なくとも特定することと、
前記割り当てられたモニタリング構成要素への前記リースの前記受けとりに応答して、
前記複製されたインスタンスの少なくともステータスを、前記リース期間中前記割り当てられたモニタリング構成要素を用いてモニタするステップと、を含む、
コンピュータにより実行される、コントロール環境からリレーショナルデータベースインスタンスに関する複製されたインスタンスをモニタする方法。

付記項２
現在の前記リースが前記複製されたインスタンスに関して存在するときのみ、
前記割り当てられたモニタリング構成要素がさらにプロビジョンされ複製された前記インスタンスの前記リースを受けとることができる、
付記項１に記載のコンピュータにより実行される方法。

付記項３
前記割り当てられたモニタリング構成要素の識別子および前記リース期間の情報を、
前記一次インスタンスレプリカのブロック記憶メカニズムに格納することをさらに含み、前記ブロック記憶メカニズムは、前記識別子および前記リース期間の前記情報が前記二次インスタンスレプリカの前記ブロック記憶メカニズムに同期的に格納されるようにする、付記項１に記載のコンピュータにより実行される方法。

付記項４
前記モニタリング構成要素、および、前記一次インスタンスレプリカおよび前記二次インスタンスレプリカのうち少なくとも１つが、異なるデータゾーンまたは異なる地理的位置内に位置する、付記項１に記載のコンピュータにより実行される方法。

付記項５
実行可能な命令で構成される１つまたは複数のコンピュータシステムの制御下で、
コントロール環境内のモニタリング構成要素を、データベース環境内の異なるデータゾーンまたは異なる地理的位置のうち少なくとも１つの中のデータベースインスタンスへ割り当て、前記データベースインスタンスは、少なくとも一次インスタンスレプリカおよび二次インスタンスレプリカを有する複製されたインスタンスであることが可能であり、前記割り当てられたモニタリング構成要素は、前記データベースインスタンスが前記複製されたインスタンスであるとき、前記一次インスタンスレプリカおよび前記二次インスタンスレプリカのうち少なくとも１つと異なる前記データゾーンおよび異なる前記地理的位置のうち少なくとも１つにあることと、
前記モニタリング構成要素が前記データベースインスタンスへ通信を送信する状況を起こし、前記通信は、前記データベースインスタンスが前記複製されたインスタンスである場合、少なくとも前記一次インスタンスレプリカに送信されることと、
前記データベースインスタンスからのリース情報の受信に応答し、リースのリース期間の間、前記モニタリング構成要素を使用する前記データベースインスタンスの少なくともステータスをモニタすることと、を含む、
コンピュータにより実行される、コントロール環境からデータベース環境内のデータベースインスタンスをモニタする方法。

付記項６
前記複製されたインスタンスに関して、前記一次インスタンスレプリカと前記二次インスタンスレプリカの間でデータが同期されるときのみ、前記リース情報が、前記複製されたインスタンスの前記一次インスタンスレプリカから受信される、付記項５に記載のコンピュータにより実行される方法。

付記項７
現在の前記リースがプロビジョンされ複製された前記インスタンスに関して存在するときのみ、前記リース情報が、前記プロビジョンされ複製されたインスタンスの前記一次インスタンスレプリカから受信される、付記項５に記載のコンピュータにより実行される方法。

付記項８
前記コントロール環境が複数の前記モニタリング構成要素を有し、前記データベース環境が複数の前記データベースインスタンスを有し、
複数の前記モニタリング構成要素にわたり実質的に均一にワークロードを分散するため、前記コントロール環境内の複数の前記モニタリング構成要素のそれぞれを、前記データベース環境内の前記データベースインスタンスの部分へ割り当てることをさらに含む、
付記項５に記載のコンピュータにより実行される方法。

付記項９
前記データベース環境内の前記データベースインスタンスのそれぞれを複数のワークロードパーティションの１つへ割り当てることをさらに含み、
前記コントロール環境内の複数の前記モニタリング構成要素のそれぞれの前記データベースインスタンスの部分への前記割り当てが、それぞれの前記モニタリング構成要素の前記複数のワークロードパーティションのうちの１つへの割り当てを含む、
付記項８に記載のコンピュータにより実行される方法。

付記項１０
前記モニタリング構成要素が前記割り当てられたワークロードパーティションをモニタすることが不可能なとき、前記データベースインスタンスの再パーティショニング、および再パーティショニングの後の前記モニタリング構成要素の残りのグループのパーティションへの再割り当てを行うことをさらに含む、付記項９に記載のコンピュータにより実行される方法。

付記項１１
前記モニタリング構成要素が前記割り当てられたワークロードパーティションをモニタすることが不可能なときに判断するため、ハートビートメッセージが前記モニタリング構成要素の間で周期的に送信されるようにさせる、
付記項９に記載のコンピュータにより実行される方法。

付記項１２
割り当てられた前記モニタリング構成要素が前記複製されたインスタンスに対して前記一次インスタンスレプリカが利用不可と判断するとき、前記二次インスタンスレプリカが、前記複製されたインスタンスの新しい前記一次インスタンスレプリカにフェイルオーバするようにさせることをさらに含む、
付記項５に記載のコンピュータにより実行される方法。

付記項１３
前記割り当てられたモニタリング構成要素の識別子およびリース期間の情報を、前記複製されたインスタンスの前記一次インスタンスレプリカのブロック記憶メカニズムに格納することをさらに含み、前記ブロック記憶メカニズムは、前記識別子および前記リース期間の前記情報が前記二次インスタンスレプリカの前記ブロック記憶メカニズムに同期的に格納されるようにさせる、
付記項５に記載のコンピュータにより実行される方法。

付記項１４
前記識別子が無作為の長い識別子である、付記項１３に記載のコンピュータにより実行される方法。

付記項１５
前記複製されたインスタンスの第１および第２のインスタンスレプリカが、単一の前記データゾーン内、別個の前記地理的位置の別個の前記データゾーン内、複数の地理的位置にわたる単一の前記データゾーン内、または単一の地理的地域内の複数の前記データゾーンにわたりプロビジョンされ、
前記モニタリング構成要素が、第３の前記データゾーンまたは前記地理的位置内、または、前記データゾーンまたは前記地理的位置と前記第１および第２のインスタンスレプリカのうちの１つの中に位置する、
付記項５に記載のコンピュータにより実行される方法。

付記項１６
前記複製されたインスタンスの第１および第２のインスタンスレプリカのステート情報およびデータ世代識別子、モニタリング構成要素識別子、およびリース期間情報を、
前記コントロール環境内の前記モニタリング構成要素のメモリ内に格納することをさらに含む、
付記項５に記載のコンピュータにより実行される方法。

付記項１７
プロセッサと、
前記プロセッサにより実行されるとき、前記プロセッサに、
コントロール環境内のモニタリング構成要素を、データベース環境内の異なるデータゾーンまたは異なる地理的位置のうち少なくとも１つの中のデータベースインスタンスへ割り当て、前記データベースインスタンスは、少なくとも一次インスタンスレプリカおよび二次インスタンスレプリカを有する複製されたインスタンスであることが可能であり、前記割り当てられたモニタリング構成要素は、前記データベースインスタンスが前記複製されたインスタンスであるとき、前記一次インスタンスレプリカおよび前記二次インスタンスレプリカのうち少なくとも１つと異なる前記データゾーンおよび異なる前記地理的位置のうち少なくとも１つにある割り当ることと、
前記モニタリング構成要素が前記データベースインスタンスの通信の送信をさせるようにし、前記通信は、前記データベースインスタンスが前記複製されたインスタンスである場合、少なくとも前記一次インスタンスレプリカに送信されることと、
前記データベースインスタンスからのリース情報の受信に応答し、リースのリース期間の間、前記モニタリング構成要素を使用する前記データベースインスタンスの少なくとも１つのステータスをモニタすることをさせる、
命令を有するメモリ装置と、を備える、
コントロール環境からデータベース環境内のデータベースインスタンスをモニタするシステム。

付記項１８
前記複製されたインスタンスに関して、前記一次インスタンスレプリカと前記二次インスタンスレプリカの間でデータが同期され、現在の前記リースがプロビジョンされ複製された前記インスタンスに関して存在するときのみ、前記リース情報が、前記複製されたインスタンスの前記一次インスタンスレプリカから受信される、付記項１７に記載のシステム。

付記項１９
前記コントロール環境が複数の前記モニタリング構成要素を有し、前記データベース環境が複数の前記データベースインスタンスを有し、前記命令が、実行されるとき、さらに前記プロセッサに、
前記複数のモニタリング構成要素にわたり実質的に均一にワークロードを分散するため、
前記コントロール環境内の前記複数のモニタリング構成要素をそれぞれ、前記データベース環境内の前記データベースインスタンスの部分へ割り当てをさせる、
付記項１７に記載のシステム。

付記項２０
前記命令が、実行されるとき、さらに前記プロセッサに、
前記データベース環境内の前記データベースインスタンスのそれぞれを複数のワークロードパーティションの１つへ割り当てさせ、
前記コントロール環境内の前記複数のモニタリング構成要素のそれぞれの前記データベースインスタンスの部分への割り当てが、それぞれの前記モニタリング構成要素を前記複数のワークロードパーティションのうちの１つへ割り当てることを含む、
付記項１９に記載のシステム。

付記項２１
前記命令が、実行されるとき、さらに前記プロセッサに、
前記モニタリング構成要素が前記割り当てられたワークロードパーティションをモニタすることが不可能なとき、前記データベースインスタンスの再パーティションを行い、再パーティショニングの後、前記モニタリング構成要素の残りのグループをパーティションへ再割り当てることをさせる、
付記項２０に記載のシステム。

付記項２２
前記命令が、実行されるとき、さらに前記プロセッサに、
前記割り当てられたモニタリング構成要素の識別子およびリース期間の情報を、前記複製されたインスタンスの前記一次インスタンスレプリカのブロック記憶メカニズムへ格納させ、前記ブロック記憶メカニズムは、前記識別子および前記リース期間の前記情報が前記二次インスタンスレプリカの前記ブロック記憶メカニズムに同期的に格納されるようにする、
付記項１７に記載のシステム。

付記項２３
前記複製されたインスタンスの第１および第２のインスタンスレプリカが、単一の前記データゾーン内、別個の地理的位置の別個の前記データゾーン内、複数の前記地理的位置にわたる単一の前記データゾーン内、または単一の地理的地域内の複数の前記データゾーンにわたりプロビジョンされ、
前記モニタリング構成要素が、第３の前記データゾーンまたは前記地理的位置内、または、第１または第２のうちの１つの前記データゾーンまたは前記地理的位置内に位置する、
付記項１７に記載のシステム。

付記項２４
命令が、プロセッサにより実行されるとき、前記プロセッサに、
コントロール環境内のモニタリング構成要素を、データベース環境内の異なるデータゾーンまたは異なる地理的位置のうち少なくとも１つの中のデータベースインスタンスへ割り当て、前記データベースインスタンスは、少なくとも一次インスタンスレプリカおよび二次インスタンスレプリカを有する複製されたインスタンスであることが可能であり、前記割り当てられたモニタリング構成要素は、前記データベースインスタンスが前記複製されたインスタンスであるとき、前記一次インスタンスレプリカおよび前記二次インスタンスレプリカのうち少なくとも１つと異なる前記データゾーンおよび異なる前記地理的位置のうち少なくとも１つにあるようにさせることと、
前記モニタリング構成要素が前記データベースインスタンスへ通信を送信するようにし、前記通信は、前記データベースインスタンスが前記複製されたインスタンスである場合、少なくとも前記一次インスタンスレプリカに送信されることと、
前記データベースインスタンスからのリース情報の受信に応答し、リースのリース期間の間、前記モニタリング構成要素を使用して前記データベースインスタンスの少なくとも１つのステータスをモニタするようにさせる、
コントロール環境からデータベース環境内のモニタリングデータベースインスタンスに関する命令を格納する、コンピュータ可読な記憶媒体。

付記項２５
前記複製されたインスタンスに関して、前記一次インスタンスレプリカと前記二次インスタンスレプリカの間でデータが同期され、現在の前記リースがプロビジョンされ複製された前記インスタンスに関して存在するときのみ、前記リース情報が、前記複製されたインスタンスの前記一次インスタンスレプリカから受信される、付記項２４に記載のコンピュータ可読な記憶媒体。

付記項２６
前記コントロール環境が複数のモニタリング構成要素を有し、前記データベース環境が複数のデータベースインスタンスを有し、前記命令が、実行されるとき、さらに前記プロセッサに、
前記複数のモニタリング構成要素にわたり実質的に均一にワークロードを分散するため、前記コントロール環境内の前記複数のモニタリング構成要素を、それぞれ、前記データベース環境内の前記データベースインスタンスの部分へ割り当てることをさせる、
付記項２４に記載のコンピュータ可読な記憶媒体。

付記項２７
前記命令が、実行されるとき、さらに前記プロセッサに、
前記データベース環境内の前記データベースインスタンスを、それぞれ、複数のワークロードパーティションのうちの１つへ割り当てることをさせ、
前記コントロール環境内の前記複数のモニタリング構成要素のそれぞれの前記データベースインスタンスの部分への割り当てが、それぞれの前記モニタリング構成要素の前記複数のワークロードパーティションのうちの１つへの割り当てを含む、
付記項２６に記載のコンピュータ可読な記憶媒体。

Claims (15)

1. 実行可能な命令で構成される１つまたは複数のコンピュータシステムの制御下で、
   コントロール環境内のモニタリング構成要素を、データベース環境内の異なるデータゾーンまたは異なる地理的位置のうち少なくとも１つの中のデータベースインスタンスに割り当て、前記データベースインスタンスは、少なくとも一次インスタンスレプリカおよび二次インスタンスレプリカを有する複製されたインスタンスであることが可能であり、割り当てられた前記モニタリング構成要素は、前記データベースインスタンスが複製されたインスタンスであるとき、前記一次インスタンスレプリカおよび前記二次インスタンスレプリカのうち少なくとも１つと異なる前記データゾーンおよび異なる前記地理的位置のうち少なくとも１つにあることと、
   前記モニタリング構成要素が前記データベースインスタンスに通信を送信するようにさせ、前記通信は、前記データベースインスタンスが複製されたインスタンスである場合、
   少なくとも前記一次インスタンスレプリカに送信されることと、
   前記データベースインスタンスからのリース情報の受信に応答し、リースのリース期間の間、前記モニタリング構成要素を使用して前記データベースインスタンスの少なくともステータスをモニタすることと、を含む、
   コンピュータにより実行される、コントロール環境からデータベース環境内のデータベースインスタンスをモニタする方法。
2. 前記複製されたインスタンスに関して、前記一次インスタンスレプリカと前記二次インスタンスレプリカの間でデータが同期されたときのみ、前記リース情報が、前記複製されたインスタンスの前記一次インスタンスレプリカから受信される、請求項１に記載のコンピュータにより実行される方法。
3. 現在の前記リースがプロビジョンされ複製された前記インスタンスに関して存在するときのみ、前記リース情報が、前記プロビジョンされ複製されたインスタンスの前記一次インスタンスレプリカから受信される、請求項１に記載のコンピュータにより実行される方法。
4. 前記コントロール環境が複数の前記モニタリング構成要素を有し、前記データベース環境が複数の前記データベースインスタンスを有し、さらに、
   複数の前記モニタリング構成要素にわたり実質的に均一にワークロードを分散するため、前記コントロール環境内の前記複数のモニタリング構成要素のそれぞれを、前記データベース環境内の前記データベースインスタンスの部分に割り当てることを含む、
   請求項１に記載のコンピュータにより実行される方法。
5. 前記データベース環境内の前記データベースインスタンスのそれぞれを複数のワークロードパーティションのうちの１つに割り当てることをさらに含み、
   前記コントロール環境内の前記複数のモニタリング構成要素のそれぞれを前記データベースインスタンスの部分に割り当てることは、それぞれの前記モニタリング構成要素を複数の前記ワークロードパーティションのうちの１つへの割り当ることを含む、
   請求項４に記載のコンピュータにより実行される方法。
6. 前記モニタリング構成要素が前記割り当てられたワークロードパーティションをモニタすることが不可能なとき、前記データベースインスタンスの再パーティショニング、および再パーティショニングの後、前記モニタリング構成要素の残りのグループのパーティションへの再割り当てを行うことをさらに含む、
   請求項５に記載のコンピュータにより実行される方法。
7. 割り当てられた前記モニタリング構成要素が前記複製されたインスタンスに関して前記一次インスタンスレプリカが利用不可と判断するとき、前記二次インスタンスレプリカが、前記複製されたインスタンスの新しい前記一次インスタンスレプリカにフェイルオーバするようにさせることをさらに含む、
   請求項１に記載のコンピュータにより実行される方法。
8. 前記割り当てられたモニタリング構成要素の識別子および前記リース期間の情報を、前記複製されたインスタンスの前記一次インスタンスレプリカのブロック記憶メカニズムに格納することをさらに含み、前記ブロック記憶メカニズムは、前記識別子および前記リース期間の前記情報が前記二次インスタンスレプリカの前記ブロック記憶メカニズムに同期的に格納されるようにさせる、
   請求項１に記載のコンピュータにより実行される方法。
9. 前記一次インスタンスレプリカおよび前記二次インスタンスレプリカが、単一のデータゾーン内、別個の地理的位置の別個の前記データゾーン内、複数の地理的位置にわたる単一の前記データゾーン内、または単一の地理的地域内の複数の前記データゾーンにわたりプロビジョンされ、
   前記モニタリング構成要素が、第３の前記データゾーンまたは前記地理的位置内、または、前記一次インスタンスレプリカおよび前記二次インスタンスレプリカのうちの１つの前記データゾーンまたは前記地理的位置内に位置する、
   請求項１に記載のコンピュータにより実行される方法。
10. プロセッサと、
    前記プロセッサにより実行されるとき、前記プロセッサに、
    コントロール環境内のモニタリング構成要素を、データベース環境内の異なるデータゾーンまたは異なる地理的位置のうち少なくとも１つの中のデータベースインスタンスへ割り当て、前記データベースインスタンスは、少なくとも一次インスタンスレプリカおよび二次インスタンスレプリカを有する複製されたインスタンスであることが可能であり、前記割り当てられたモニタリング構成要素は、前記データベースインスタンスが前記複製されたインスタンスであるとき、前記一次インスタンスレプリカおよび前記二次インスタンスレプリカのうち少なくとも１つと異なる前記データゾーンおよび異なる前記地理的位置のうち少なくとも１つにあるようにさせることと、
    前記モニタリング構成要素が前記データベースインスタンスへ通信を送信するようにさせ、前記通信は、前記データベースインスタンスが前記複製されたインスタンスである場合、少なくとも前記一次インスタンスレプリカに送信されるようにさせ、
    前記データベースインスタンスからのリース情報の受信に応答し、リースのリース期間の間、前記モニタリング構成要素を使用して、前記データベースインスタンスを少なくとも１つのステータスのモニタすることをさせる、
    命令を有するメモリ装置と、を備える、
    コントロール環境からデータベース環境内のデータベースインスタンスをモニタするシステム。
11. 前記複製されたインスタンスに関して、前記一次インスタンスレプリカと前記二次インスタンスレプリカの間でデータが同期され、現在の前記リースがプロビジョンされ複製された前記インスタンスに関して存在するときのみ、前記リース情報が前記複製されたインスタンスの前記一次インスタンスレプリカから受信される、請求項１０に記載のシステム。
12. 前記コントロール環境が複数の前記モニタリング構成要素を有し、前記データベース環境が複数の前記データベースインスタンスを有し、前記命令が、実行されるとき、さらに前記プロセッサに、
    前記複数のモニタリング構成要素にわたり実質的に均一にワークロードを分散するため、
    前記コントロール環境内の前記複数のモニタリング構成要素を、それぞれ、前記データベース環境内の前記データベースインスタンスの部分へ割り当てることをさせる、
    請求項１０に記載のシステム。
13. 前記命令が、実行されるとき、さらに前記プロセッサに、
    前記データベース環境内の前記データベースインスタンスを、それぞれ、複数のワークロードパーティションのうちの１つへ割り当ることをさせ、
    前記コントロール環境内の前記複数のモニタリング構成要素のそれぞれの前記データベースインスタンスの部分への割り当てが、それぞれの前記モニタリング構成要素の前記複数のワークロードパーティションのうちの１つへの割り当てを含む、
    請求項１２に記載のシステム。
14. 前記命令が、実行されるとき、さらに前記プロセッサに、
    前記割り当てられたモニタリング構成要素の識別子およびリース期間の情報を、前記複製されたインスタンスの前記一次インスタンスレプリカのブロック記憶メカニズムへ格納することをさせ、前記ブロック記憶メカニズムは、前記識別子および前記リース期間の前記情報が前記二次インスタンスレプリカの前記ブロック記憶メカニズムに同期的に格納されるようにさせる、
    請求項１０に記載のシステム。
15. 前記一次インスタンスレプリカおよび前記二次インスタンスレプリカが、単一の前記データゾーン内、別個の前記地理的位置の別個の前記データゾーン内、複数の前記地理的位置にわたる単一の前記データゾーン内、または単一の地理的地域内の複数の前記データゾーンにわたりプロビジョンされ、
    前記モニタリング構成要素が、第３の前記データゾーンまたは前記地理的位置内、または、前記一次インスタンスレプリカおよび前記二次インスタンスレプリカのうちの１つの前記データゾーンまたは前記地理的位置内に位置する、
    請求項１０に記載のシステム。

Images