次の方法で共有

Azure Cosmos DB for NoSQL の高可用性 (信頼性)

  • [アーティクル]

この記事では、Azure Cosmos DB for NoSQL での高可用性 (信頼性) のサポートについて説明し、可用性ゾーンと、リージョン間のディザスター リカバリーとビジネス継続性について説明します。

可用性ゾーンのサポート

可用性ゾーンとは、各 Azure リージョン内にある、物理的に分離されたデータセンターのグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure の可用性ゾーンの詳細については、「可用性ゾーンとは?」を参照してください。

Azure Cosmos DB は、個々のコンピューティング ノードのすべての詳細を透過的に管理するマルチテナント サービスです。 修正プログラムの適用や計画メンテナンスについて心配する必要はありません。 Azure Cosmos DB では、システムによって実行されるすべての自動メンテナンス操作を通じて、可用性と P99 待機時間に関する SLA が保証されます。

Azure Cosmos DB のオファー:

個々のノード停止の回復性。 Azure Cosmos DB は、4 つのレプリカ クォーラム内のアカウントについて、各 Azure リージョンでデータのレプリカを 3 つ以上保証することにより、レプリカの停止を自動的に軽減します。 この保証により、アプリケーションの変更や構成を必要とせずに、個々のノードの停止に対して 0 の RTO および 0 の RPO を実現します。

ゾーン停止の回復性。 可用性ゾーンを使って Azure Cosmos DB アカウントをデプロイすると、ゾーンが停止しても Azure Cosmos DB で 0 の RTO および 0 の RPO が実現します。 RTO の詳細については、「回復目標」を参照してください。

可用性ゾーンが有効になっている場合、Azure Cosmos DB for NoSQL では、ゾーン冗長構成がサポートされます。

前提条件

  • レプリカは、可用性ゾーンをサポートする Azure リージョンにデプロイする必要があります。 リージョンが可用性ゾーンをサポートしているかどうかを確認するには、サポートされているリージョンの一覧を参照してください。

  • 可用性ゾーンが現在の構成に十分なメリットをもたらすかどうかを、「可用性 ゾーンの使用による影響」で判断します。

可用性 ゾーンの使用による影響

可用性ゾーンが Cosmos DB for NoSQL データベースの高可用性に与える影響は、アカウントの整合性レベルと、可用性ゾーンが有効になっているリージョンによって異なります。 多くの場合、可用性ゾーンは、アカウントが複数リージョンの場合 (厳密な整合性で構成されている場合を除き)、メリットをもたらすことはないか、最小値のメリットのみをもたらします。

現在のアカウント構成で可用性ゾーンを使用した場合の影響を見積もるために、次の表を参照してください。

アカウントの整合性レベル 可用性ゾーンが有効になっているリージョン 可用性 ゾーンの使用による影響
非同期 (有界整合性制約または弱い) 任意の数のセカンダリ読み取りリージョン。 SDK は既に読み取りリージョンが失敗したときに読み取りのシームレスなリダイレクトを提供するため、最小限のメリットをもたらします。
同期 (厳密) 2 つ以上のセカンダリ読み取りリージョン 読み取りリージョンが可用性を失い、書き込みを続行できる場合、システムは動的クォーラムを利用できるため、ある程度のメリットをもたらします。
同期 (厳密) 1 つのセカンダリ読み取りリージョン このシナリオでは読み取りリージョンの損失が書き込みの可用性に影響を与える可能性があるため、より大きなメリットをもたらします。
すべて 書き込みリージョンと任意の数のセカンダリ リージョン ゾーン障害に対する書き込み操作の可用性が向上します。
すべて 単一リージョン 単一リージョンでは、複数リージョンのフェールオーバー機能を利用することはできません。 可用性ゾーンを使用すると、ゾーン障害による全体的な可用性の損失を防ぐことができます。

SLA の機能強化

可用性ゾーンは物理的に分離され、個別の電源、ネットワーク、冷却を提供するため、可用性 SLA (サービス レベル アグリーメント) は、単一リージョン (99.99%) のアカウントよりも高い (99.995%) です。 可用性ゾーンが有効になっているリージョンは 25% の Premium で課金されますが、可用性ゾーンのないリージョンでは Premium は発生しません。 さらに、複数リージョンの書き込みを使用して構成されたアカウントや、自動スケール モードで構成されたコレクションの場合、可用性ゾーンの Premium 価格は免除されます。

Cosmos DB アカウントに追加のリージョンを追加すると、通常、既存の請求額が 100% (乗算ではなく加算) 増加しますが、リージョン間のコストには若干の変動が存在します。 詳しくは、価格に関するページをご覧ください。

AZ の有効化、追加リージョンの追加、またはマルチリージョン書き込みの有効化は、各段階で特定の Cosmos DB アカウントの回復性と可用性を高める階層化アプローチと考えることができます。つまり、可用性は AZ のない単一リージョン構成の場合は 99.99%、AZ のある単一リージョン構成の場合は 99.995%、複数リージョン書き込みオプションが有効になっている複数リージョン構成の場合は 99.999% になります。 各構成の SLA の概要については、次の表を参照してください。

KPI 可用性ゾーンがない単一リージョンの書き込み 可用性ゾーンがある単一リージョンの書き込み 可用性ゾーンがない複数リージョンと単一リージョンの書き込み 可用性ゾーンがある複数リージョンと単一リージョンの書き込み 可用性ゾーンの有無にかかわらず、複数リージョンと複数リージョンの書き込み
書き込み可用性 SLA 99.99% 99.995% 99.99% 99.995% 99.999%
読み取り可用性 SLA 99.99% 99.995% 99.999% 99.999% 99.999%
ゾーンの障害: データ損失 データ損失 データ損失なし データ損失なし データ損失なし データ損失なし
ゾーンの障害: 可用性 可用性の損失 可用性の損失なし 可用性の損失なし 可用性の損失なし 可用性の損失なし
リージョンの障害: データ損失 データ損失 データ損失 整合性レベルによって決まります。 詳細については、「一貫性、可用性、パフォーマンスのトレードオフ」を参照してください。 整合性レベルによって決まります。 詳細については、「一貫性、可用性、パフォーマンスのトレードオフ」を参照してください。 整合性レベルによって決まります。 詳細については、「一貫性、可用性、パフォーマンスのトレードオフ」を参照してください。
リージョンの障害: 可用性 可用性の損失 可用性の損失 読み取りリージョンの障害に関して可用性の損失なし、書き込みリージョンの障害に関しては一時的 読み取りリージョンの障害に関して可用性の損失なし、書き込みリージョンの障害に関しては一時的 読み取り可用性の損失なし、影響を受けるリージョンに関しては一時的な書き込み可用性の損失あり
価格 (1) 該当なし プロビジョニングされた RU/秒 x 1.25 レート プロビジョニングされた RU/秒 x N リージョン プロビジョニングされた RU/秒 x 1.25 レート x N リージョン (2) 複数リージョンの書き込みレート x N リージョン

1 サーバーレス アカウントの RU には、1.25 の係数が乗算されます。

2 1.25 レートは、可用性ゾーンを有効にするリージョンにのみ適用されます。

可用性ゾーンが有効になっているリソースを作成する

可用性ゾーンは、Azure Cosmos DB NoSQL アカウントに新しいリージョンを追加する場合にのみ構成できます。

可用性ゾーンのサポートを有効にするには、次を使用できます。

可用性ゾーン サポートに移行する

Cosmos DB アカウントを可用性ゾーンのサポートに移行する方法については、「Azure Cosmos DB for NoSQL を可用性ゾーンのサポートに移行する」を参照してください。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

"リージョンの停止" とは、すべての可用性ゾーンにわたって、Azure リージョンのすべての Azure Cosmos DB ノードに影響を与える停止を表します。 まれに発生するリージョンの停止時には、Azure Cosmos DB を構成して、持続性と可用性のさまざまな結果をサポートできます。

Durability

通常、Azure Cosmos DB を 1 つのリージョンにデプロイする場合、データ損失は発生しません。 影響を受けるリージョンで Azure Cosmos DB サービスが復旧した後に、データへのアクセスが復元されます。 データ損失は、Azure Cosmos DB リージョンで回復不可能な障害が発生した場合にのみ、発生する可能性があります。

リージョンで致命的なディザスターが発生した結果として起こる可能性がある完全なデータ損失から保護するために、Azure Cosmos DB には 2 つのバックアップ モードがあります。

  • 継続的バックアップでは、100 秒ごとに各リージョンがバックアップされます。 これにより、1 秒の細分性で任意の時点にデータを復元できます。 各リージョンでは、バックアップは、そのリージョンでコミットされたデータに依存します。 リージョンで可用性ゾーンが有効になっている場合、バックアップはゾーン冗長ストレージ アカウントに格納されます。
  • 定期的なバックアップでは、アカウント内のすべてのコンテナーからすべてのパーティションの完全バックアップが作成されます。パーティション間の同期は実行されません。 最小バックアップ間隔は 1 時間です

Azure Cosmos DB アカウントが複数のリージョンにデプロイされている場合、データの持続性は、アカウントで構成する整合性レベルによって異なります。 次の表では、すべての整合性レベルについて、2 つ以上のリージョンにデプロイされている Azure Cosmos DB アカウントの RPO を詳細に示します。

整合性レベル リージョンの停止に対する RPO
セッション、一貫性のあるプレフィックス、最終的 15 分未満
Bounded staleness K および T
Strong 0

K = 項目のバージョン (更新) の数。

T = 前回の更新以降の期間。

複数リージョン アカウントの場合、K と T の最小値は 100,000 回の書き込み操作または 300 秒です。 この値により、有界整合性制約を使用する場合のデータの最小 RPO が定義されます。

整合性レベルの違いの詳細については、「Azure Cosmos DB の整合性レベル」をご覧ください。

サービスマネージド フェールオーバー

リージョンの停止中でもソリューションに継続的なアップタイムが必要な場合は、複数のリージョン間でデータをレプリケートし、必要に応じて使用可能なリージョンに透過的にフェールオーバーするように Azure Cosmos DB を構成できます。

単一リージョン アカウントでは、リージョンの停止後にアクセシビリティが失われる可能性があります。 常にビジネス継続性を確保するには、Azure Cosmos DB アカウントを 1 つの書き込みリージョンと少なくとも 2 つ (読み取り) リージョンで設定し、サービスマネージド フェールオーバーを有効にします。

サービスマネージド フェールオーバーでは、Azure Cosmos DB が複数リージョン アカウントの書き込みリージョンをフェールオーバーし、「持続性」セクションで既に説明したデータ損失のコストでビジネス継続性を維持できます。 リージョン間フェールオーバーは、Azure Cosmos DB クライアントで検出され、処理されます。 アプリケーションの変更は不要です。 複数の読み取りリージョンとサービスマネージド フェールオーバーを有効にする手順については、「Azure portal を使用して Azure Cosmos DB アカウントを管理する」をご覧ください。

重要

複数の読み取りリージョンを含む単一リージョンの書き込み構成を選択した場合は、運用ワークロードに使用される Azure Cosmos DB アカウントを構成して、サービスマネージド フェールオーバーを有効にすることを強くお勧めします。 この構成により、Azure Cosmos DB では、利用可能なリージョンにアカウント データベースをフェールオーバーできるようになります。 この構成がない場合、書き込みリージョンの停止中は、アカウントで書き込みの可用性が失われる恐れがあります。 リージョン接続がないため、手動フェールオーバーは成功しません。

警告

サービス マネージド フェールオーバーが有効になっている場合でも、部分的な停止には Azure Cosmos DB サービス チームの手動介入が必要になる場合があります。 これらのシナリオでは、フェールオーバーが有効になるまでに最大 1 時間 (またはそれ以上) かかる場合があります。 部分的な停止時の書き込みの可用性を向上させるために、サービス マネージド フェールオーバーに加えて可用性ゾーンを有効にすることをお勧めします。

複数の書き込みリージョン

複数のリージョンで書き込みを受け付けるように Azure Cosmos DB を構成できます。 この構成は、地理的に分散したアプリケーションの書き込み待機時間を短縮するために役立ちます。

Azure Cosmos DB アカウントを複数の書き込みリージョン用に構成すると、厳密な整合性はサポートされず、書き込みの競合が発生する場合があります。 これらの競合を解決する方法の詳細については、「複数の書き込みリージョンを使用する場合の競合の種類と解決ポリシー」を参照してください。

重要

同じドキュメント ID を頻繁に更新する (または TTL または削除後に同じドキュメント ID を頻繁に再作成する) と、システムで生成される競合の数が増えるため、レプリケーションのパフォーマンスに影響します。  

競合解決リージョン

Azure Cosmos DB アカウントで複数リージョン書き込みが構成されていると、書き込み競合が発生した場合、リージョンの 1 つがアービターとして機能します。

複数リージョンの書き込むのベスト プラクティス

複数のリージョンに書き込む場合に考慮すべきベスト プラクティスをいくつか紹介します。

ローカル トラフィックをローカルに維持する

複数リージョンの書き込みを使用する場合、アプリケーションはローカル リージョンから発信される読み取りおよび書き込みトラフィックを、厳密にローカル Cosmos DB リージョンに発行する必要があります。 最適なパフォーマンスを得るには、リージョン間の呼び出しを避けてください。

アプリケーションでは、次のアンチパターンを回避して競合を最小限に抑えることが重要です。

  • すべてのリージョンに同じ書き込み操作を送信して、応答時間が速くなる確率を高める

  • 要求ごとに読み取りまたは書き込み操作のターゲット リージョンをランダムに決定する

  • ラウンド ロビン ポリシーを使用して、要求ごとに読み取りまたは書き込み操作のターゲット リージョンを決定します。

レプリケーションのラグへの依存関係を回避する

複数リージョンの書き込みアカウントでは、厳密な整合性を構成できません。 書き込まれるリージョンは、Azure Cosmos DB がデータをグローバルに非同期的にレプリケートしながら、データをローカルにレプリケートした直後に応答します。

めったに起こりませんが、データを geo レプリケートするときに、1 つまたは複数のパーティションでレプリケーションのラグが発生する場合があります。 レプリケーションのラグは、ネットワーク トラフィックのまれな中断や、通常よりも高い競合解決率が原因で発生することがあります。

たとえば、アプリケーションがリージョン A に書き込み、リージョン B から読み取るアーキテクチャでは、2 つのリージョン間のレプリケーションのラグに依存します。 ただし、アプリケーションが同じリージョンに対して読み取りと書き込みを行う場合は、レプリケーションのラグが発生してもパフォーマンスは一定のままになります。

書き込み操作のセッション整合性の使用を評価する

セッション整合性では、セッション トークンは読み取りと書き込みの両方の操作に使用します。

読み取り操作の場合、Azure Cosmos DB によって、指定された (またはより新しい) セッション トークンに対応するデータの受信を保証するサーバーに、キャッシュされたセッション トークンが送信されます。

書き込み操作の場合、指定されたセッション トークンとのラグがサーバーで解消された場合にのみ、Azure Cosmos DB によって、データの保持を保証するデータベースにセッション トークンが送信されます。 単一リージョンの書き込みアカウントでは、書き込みリージョンとセッション トークンの間のラグが解消されていることが常に保証されます。 ただし、複数リージョンの書き込みアカウントでは、書き込み対象のリージョンが別のリージョンに発行された書き込みとのラグを解消できない場合があります。 クライアントがリージョン B からのセッション トークンを使用してリージョン A に書き込む場合、リージョン A は、リージョン B で行われた変更が適用されるまでデータを保持できません。

セッション トークンは読み取り操作にのみ使用し、クライアント インスタンス間でセッション トークンを渡すときの書き込み操作には使用しないことをお勧めします。

同じドキュメントに対する急速な更新を軽減する

解決、または競合がないことを確認するためのサーバーの更新は、同じドキュメントが繰り返し更新されたときにアプリケーションによってトリガーされる書き込みと競合する可能性があります。 同じドキュメントに連続して更新を繰り返す場合、競合解決時の待機時間が長くなります。

同じドキュメントに対する繰り返しの更新でバーストが時々発生することは避けられませんが、安定した状態のトラフィックで長期間にわたって同じドキュメントに対する急速な更新が見られる場合は、代わりに新しいドキュメントが作成されるアーキテクチャを検討してください。

読み取りと書き込みの停止

単一リージョン アカウントのクライアントでは、サービスが復元されるまで、読み取りおよび書き込みの可用性が失われる恐れがあります。

複数リージョンのアカウントでは、次の構成と停止の種類に応じて異なる動作が発生します。

構成 Outage 可用性への影響 持続性への影響 対処
単一の書き込みリージョン リージョンの停止を読み取る すべてのクライアントは、読み取りを他のリージョンに自動的にリダイレクトします。 すべての構成において、読み取りまたは書き込みの可用性が失われることはありません。 例外は、厳密な整合性を持つ 2 つのリージョンの構成であり、サービスが復元されるまで書き込みの可用性が失われます。 または、"サービスマネージド フェールオーバーが有効になっている場合" は、そのリージョンは失敗としてマークされ、フェールオーバーが発生します。 データの損失はありません。 停止状態中は、読み取りトラフィックをサポートするのに十分な要求ユニット (RU) が残りのリージョンにプロビジョニングされていることを確認します。

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整します。
単一の書き込みリージョン 書き込みリージョンの停止 クライアントは、読み取りを他のリージョンにリダイレクトします。

"サービスマネージド フェールオーバーがない" 場合、クライアントで書き込みの可用性が失われます。 書き込みの可用性は、停止が終了すると自動的に復元されます。

"サービスマネージド フェールオーバーが有効になっている" 場合、クライアントでは、選択した新しい書き込みリージョンへのフェールオーバーがサービスによって管理されるまで書き込みの可用性が失われます。		 厳密な整合性レベルを選択していない場合、サービスは一部のデータを残りのアクティブなリージョンにレプリケートしない可能性があります。 このレプリケーションは、選択した整合性レベルによって異なります。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる可能性があります。 停止状態中は、読み取りトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

成功しないからといって、停止時に手動フェールオーバーをトリガー "しない" でください。

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整します。 NoSQL 用 API を使用するアカウントでは、障害が発生したリージョン内のレプリケートされていないデータを競合フィードから復旧することもできます。
複数の書き込みリージョン リージョンの停止 サービスマネージド フェールオーバーを使用した単一書き込みリージョンと同様に、書き込みの可用性が一時的に失われる場合があります。 競合解決リージョンのフェールオーバーは、停止時に多数の競合書き込みが発生すると、書き込みの可用性が失われる原因になる場合もあります。 障害が発生したリージョンで最近更新されたデータは、選択した整合性レベルによっては、残りのアクティブ リージョンでは使用できない場合があります。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる恐れがあります。 停止状態中は、より多くのトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整できます。 可能であれば、Azure Cosmos DB は、失敗したリージョン内のレプリケートされていないデータを自動的に復旧します。 この自動復旧では、NoSQL 用 API を使用するアカウントに対して構成する競合の解決方法が使用されます。 他の API を使用するアカウントの場合、この自動回復では "最後の書き込み優先" が使用されます。

読み取りリージョンの停止に関する追加情報

  • 影響を受けるリージョンは切断され、オフラインとマークされます。 Azure Cosmos DB SDK は、読み取り呼び出しを、優先リージョンの一覧にある次の使用可能なリージョンにリダイレクトします。

  • 優先リージョンの一覧にあるいずれのリージョンも使用可能でない場合、呼び出しは自動的に現在の書き込みリージョンに戻ります。

  • 読み取りリージョンの停止を処理するアプリケーション コードは、変更する必要はありません。 影響を受ける読み取りリージョンはオンラインに戻ると、現在の書き込みリージョンと同期され、完全にラグが解消された後に読み取り要求に再び対応できるようになります。

  • それ以降の読み取りは、アプリケーション コードを変更しなくても、回復したリージョンにリダイレクトされます。 フェールオーバー中も、以前に障害が発生したリージョンの再参加中も、読み取り整合性の保証は引き続き Azure Cosmos DB によって遵守されます。

  • Azure 書き込みリージョンが永久に回復不可能になるという、まれで不運な状況でも、複数リージョンの Azure Cosmos DB アカウントが厳密な整合性で構成されていれば、データ損失は発生しません。 複数リージョンの Azure Cosmos DB アカウントには、「持続性」セクションで前述した持続性の特性があります。

読み取りリージョンの停止に関する追加情報

  • Azure Cosmos DB アカウントで "サービスマネージド フェールオーバー" が構成されている場合、書き込みリージョンの停止時に、Azure Cosmos DB アカウントによってセカンダリ リージョンが新しいプライマリ書き込みリージョンに昇格します。 指定するリージョンの優先順位に従って別のリージョンにフェールオーバーが行われます。

  • 手動フェールオーバーはトリガーしないようにする必要があり、ソースまたは宛先のリージョンが停止していると成功しません。 その理由は、フェールオーバー手順に、リージョン間の接続を必要とする整合性チェックが含まれているためです。

  • 以前に影響を受けたリージョンがオンラインに戻ると、障害発生時にレプリケートされなかった書き込みデータは競合フィードによって使用可能になります。 アプリケーションは競合フィードを読み取り、そのアプリケーション固有のロジックに基づいて競合を解決した後、更新されたデータを必要に応じて Azure Cosmos DB コンテナーに書き戻すことができます。

  • 以前に影響を受けた書き込みリージョンの復旧後、Azure portal に "オンライン" として表示され、読み取りリージョンとして利用できるようになります。 この時点で、[PowerShell、Azure CLI、または Azure portal] を使用して、復旧されたリージョンに書き込みリージョンとして切り替えることができます (/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account)。 書き込みリージョンの切り替えの前後や最中に、"データや可用性が損なわれることはありません"。 アプリケーションの高可用性が維持されます。

警告

書き込みリージョンが停止した場合、Azure Cosmos DB アカウントで "サービスマネージド フェールオーバー" によってセカンダリ リージョンが昇格されて新しいプライマリ書き込みリージョンになり、復旧後に元の書き込みリージョンが自動的に書き込みリージョンとして再び昇格されることはありません。 ユーザーが PowerShell、Azure CLI、または Azure portal を使って、書き込みリージョンとして復旧したリージョンに再び切り替える必要があります (前述のように、安全に実行できるようになったら)。

停止の検出、通知、管理

単一リージョン アカウントの場合、クライアントでは、Azure Cosmos DB リージョンの停止中に読み取りと書き込みの可用性が失われます。 次の表で説明するように、複数リージョン アカウントではさまざまな動作が発生します。

書き込みリージョン サービスマネージド フェールオーバー ウィザードの内容 対処
単一の書き込みリージョン 無効 厳密な整合性が使用されていないときに読み取りリージョンが停止した場合、すべてのクライアントが他のリージョンにリダイレクトされます。 読み取りまたは書き込みの可用性は失われず、データの損失もありません。 厳密な整合性を使用しているときに残っている読み取りリージョンが 2 つより少ない場合、読み取りリージョンの停止が書き込みの可用性に影響を及ぼす可能性があります。

書き込みリージョンが停止した場合、クライアントで書き込みの可用性が失われる可能性があります。 厳密な整合性を選択しなかった場合、一部のデータが残りのアクティブなリージョンにレプリケートされないことがあります。 このレプリケーションは、選択した整合性レベルによって異なります。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる恐れがあります。

停止状態が終わると、Azure Cosmos DB によって書き込みの可用性が復元されます。		 停止状態中は、読み取りトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

成功しないからといって、停止時に手動フェールオーバーをトリガー "しない" でください。

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整します。
単一の書き込みリージョン Enabled 厳密な整合性が使用されていないときに読み取りリージョンが停止した場合、すべてのクライアントが他のリージョンにリダイレクトされます。 読み取りまたは書き込みの可用性は失われず、データの損失もありません。 厳密な整合性を使用しているときに、残っている読み取りリージョンが 2 つより少ない場合、読み取りリージョンの停止が書き込みの可用性に影響を及ぼす可能性があります。

書き込みリージョンが停止した場合、Azure Cosmos DB で設定どおりに新しいリージョンが新しい書き込みリージョンとして選択されるまで、クライアントでは書き込みの可用性が失われます。 厳密な整合性を選択しなかった場合、一部のデータが残りのアクティブなリージョンにレプリケートされないことがあります。 このレプリケーションは、選択した整合性レベルによって異なります。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる恐れがあります。		 停止状態中は、読み取りトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

成功しないからといって、停止時に手動フェールオーバーをトリガー "しない" でください。

停止状態が終了したら、書き込みリージョンを元のリージョンに戻し、必要に応じて、プロビジョニングされている RU を再調整できます。 NoSQL 用 API を使用するアカウントでは、障害が発生したリージョン内のレプリケートされていないデータを競合フィードから復旧することもできます。
複数の書き込みリージョン 該当なし 障害が発生したリージョンの最近の更新データは、残りのアクティブ リージョンで使用可能でない場合があります。 最終的に、一貫性のあるプレフィックス、およびセッションの整合性レベルで保証されている整合性制約は、15 分間未満です。 有界整合性制約では、構成に応じて、K 個の更新、または T 秒未満が保証されます。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる恐れがあります。 停止状態中は、より多くのトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整できます。 可能な場合、Azure Cosmos DB は失敗したリージョン内のレプリケートされていないデータを復旧します。 この復旧では、NoSQL 用 API を使用するアカウントに対して構成した競合の解決方法が使用されます。 他の API を使用するアカウントの場合、この復旧では "最後の書き込み優先" が使用されます。

高可用性のテスト

Azure Cosmos DB アカウントの可用性が高くても、アプリケーションが高可用性を維持するよう正しく設計できていないこともあります。 アプリケーションのテストまたはディザスター リカバリー (DR) 訓練の一部としてアプリケーションのエンド ツー エンドの高可用性をテストするには、アカウントのサービスマネージド フェールオーバーを一時的に無効にします。 PowerShell、Azure CLI、または Azure portal を使用して手動フェールオーバーを呼び出し、アプリケーションを監視します。 テストが完了したら、プライマリ リージョンにフェールバックし、アカウントのサービスマネージド フェールオーバーを復元できます。

重要

ソースまたは宛先リージョンで Azure Cosmos DB が停止している間は手動フェールオーバーを呼び出さないでください。 手動フェールオーバーでは、データの整合性を維持するためにリージョン接続が必要であるため、成功しません。

関連するコンテンツ