Azure Cosmos DB を使用して高可用性を実現する

  • [アーティクル]

適用対象: NoSQL MongoDB Cassandra Gremlin Table

高可用性を備えたソリューションを構築するには、すべてのコンポーネントの信頼性特性を評価する必要があります。 Azure Cosmos DB には、ソリューションの高可用性を実現するのに役立つ機能と構成オプションが用意されています。

この記事では、次の用語を使用しています。

  • 回復時間の目標 (RTO): Azure Cosmos DB に影響を与える停止の開始から完全な可用性への復旧までの時間。
  • 回復ポイントの目標 (RPO): 正しく復元された最後の書き込みから Azure Cosmos DB に影響を与える停止の開始時刻までの時間。

注意

予想される最大 RPO と RTO は、Azure Cosmos DB で発生している停止の種類によって異なります。 たとえば、1 つのノードの停止とリージョン全体の停止では、予想される RTO と RPO は異なります。

この記事では、Azure Cosmos DB の可用性に影響を与えるイベントと 対応する Azure Cosmos DB の構成オプションについて詳しく説明します。

レプリカのメンテナンス

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

レプリカの停止

レプリカの停止とは、Azure リージョンにデプロイされた Azure Cosmos DB クラスター内の個々のノードの停止です。

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

多くの Azure リージョンでは、Azure Cosmos DB クラスターを可用性ゾーンに分散させることができます。 可用性ゾーンが物理的に分離され、個別の電源、ネットワーク、冷却が提供されるため、SLA を向上させることができます。 可用性ゾーンを使って Azure Cosmos DB アカウントをデプロイすると、ゾーンが停止しても Azure Cosmos DB で 0 の RTO および 0 の RPO が実現します。

単一の Azure リージョンにデプロイすると、特に何も入力しなくても、Azure Cosmos DB はノードの停止に対して回復性を持つようになります。 可用性ゾーン間で冗長性を有効にすると、料金は高くなりますが、ゾーンの停止に対する Azure Cosmos DB の回復性が実現されます。

ゾーン冗長は、Azure Cosmos DB アカウントに新しいリージョンを追加するときにのみ構成できます。 既存のリージョンの場合、ゾーン冗長を有効にするには、リージョンを削除してから、ゾーン冗長が有効な状態でゾーンを追加し直します。 単一リージョンのアカウントの場合、このアプローチでは、一時的なフェールオーバー先のリージョンを 1 つ追加し、目的のリージョンを削除してから、ゾーン冗長を有効にして追加する必要があります。

既定では、Azure Cosmos DB アカウントは複数の可用性ゾーンを使用しません。 複数の可用性ゾーン間のデプロイは、次の方法で有効にできます。

Azure Cosmos DB アカウントが N 個の Azure リージョンに分散している場合は、すべてのデータの N x 4 個のコピーが存在します。 Azure Cosmos DB が各リージョンのデータをレプリケートする方法の詳細については、Azure Cosmos DB でのグローバル分散に関するページをご覧ください。 2 つ以上のリージョンで Azure Cosmos DB アカウントを用意すると、アプリケーションの可用性が向上し、関連するリージョン全体で低待機時間を実現できます。

リージョンの停止

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

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 SDK の動作と、それに影響を与える構成を確認します。

  • 書き込みと読み込みの高可用性を確保するために、複数の書き込みリージョンを持つ少なくとも 2 つ (厳密な整合性を使用している場合には 3 つ) のリージョンにまたがるように Azure Cosmos DB アカウントを構成します。 詳しくは、「チュートリアル: NoSQL 用 API を使用して Azure Cosmos DB グローバル分散をセットアップする」をご覧ください。

  • 単一書き込みリージョンで構成されている複数リージョンの Azure Cosmos DB アカウントでは、Azure CLI または Azure portal を使用してサービスマネージド フェールオーバーを有効にします。 サービスマネージド フェールオーバーを有効にすると、リージョンで災害が発生するたびに、ユーザーによる入力なしで Azure Cosmos DB はアカウントをフェールオーバーします。

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

    重要

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

  • グローバルに分散されるデータベース環境内では、リージョン全体にわたる停止が発生した場合の整合性レベルとデータ持続性の間には、直接的な関係があります。 ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間 (つまり RTO) について理解する必要があります。 さらに、破壊的なイベントの発生後、復旧中にアプリケーションが損失を許容できる新しいデータ更新の最大期間 (つまり RPO) についても理解する必要があります。 RTO と RPO の詳細については、「Azure Cosmos DB の整合性レベル」を参照してください。

Azure Cosmos DB のリージョン停止中に予期されること

単一リージョン アカウントの場合、クライアントでは、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 を使用するアカウントの場合、この復旧では "最後の書き込み優先" が使用されます。

次のステップ

次に、次の記事をお読みください。