Azure Cosmos DB for MongoDB 仮想コアでの高可用性
適用対象: 
MongoDB 仮想コア
リージョン内高可用性 (HA) は、クラスター内の各シャードのスタンバイ レプリカを維持することでデータベースのダウンタイムを回避する機能です。 何らかの理由でシャードがダウンした場合、Azure Cosmos DB for MongoDB 仮想コアでは、障害が発生したシャードからそのスタンバイに受信接続が切り替えられます。 フェールオーバーが発生した場合、昇格されたシャードは、同期レプリケーションを通じて常に新しいデータを保ちます。
クラスター内のすべてのプライマリ シャードは、シャード間の待機時間を短縮するために、1 つの可用性ゾーン (AZ) にプロビジョニングされます。 スタンバイ シャードは別の可用性ゾーンにプロビジョニングされます。
HA が有効になっていない場合でも、各シャードには独自のローカル冗長ストレージ (LRS) が与えられ、3 つの同期レプリカが Azure Storage サービスによって管理されます。 3 つのレプリカはすべて、クラスターの Azure リージョンに配置されます。 1 つのレプリカ障害が発生した場合、Azure Storage サービスは障害を検出し、障害が発生したレプリカを透過的に再作成します。 LRS ストレージの持続性については、こちらのページのメトリックを参照してください。
HA が有効になっている場合、Azure Cosmos DB for MongoDB 仮想コアによって、クラスター内のプライマリ シャードごとに 1 つのスタンバイ シャードが実行されます。 各プライマリ シャードとスタンバイ シャードのコンピューティングとストレージの構成は同じです。 プライマリとそのスタンバイは、同期レプリケーションを使用します。 この種類のレプリケーションを使用すると、クラスター内のプライマリ シャードとスタンバイ シャードで常に同じデータを保持できます。 簡単に言えば、Microsoft サービスによってプライマリ シャードのエラーが検出され、スタンバイ シャードにフェールオーバーされることで、データ損失がゼロに抑えられます。
クラスター接続文字列は、フェールオーバーに関係なく、常に同じままです。 これにより、サービスは、アプリケーションからの要求を処理する物理シャード内での変更を抽象化できます。
クラスターでリージョン内の高可用性が有効になっている場合、各クラスター シャードの可用性について、99.99% のサービス レベル アグリーメント (SLA) の対象となります。
高可用性は、クラスター作成時に有効にできます。 また、高可用性は、既存の Azure Cosmos DB for MongoDB 仮想コア クラスター上でいつでも有効または無効にできます。 Azure Cosmos DB for MongoDB 仮想コア クラスターで高可用性が有効または無効にされるときに、データベースのダウンタイムはありません。
フェールオーバー中の動作
各シャード フェールオーバーは、使用不可の検出、スタンバイ シャードへの切り替え、スタンバイ シャードの再作成の 3 つのフェーズで構成されます。 このサービスは、定期的な正常性チェックを実行して、クラスター内のプライマリ シャードとスタンバイ シャードごとに可用性の継続的な監視を実行します。 正常性チェックが、シャードが応答しなくなり、シャード障害の発生を宣言する必要があることを確実に示すと、スタンバイ シャードへの実際のフェールオーバー (切り替え) が開始されます。
切り替えフェーズ中は、データベースの読み取りと書き込みがスタンバイ シャードにリダイレクトされます。 各プライマリ シャードとスタンバイ シャードと間の同期レプリケーションにより、スタンバイ シャードが持つデータ セットは、常にプライマリと同じになります。 これにより、すべてのフェールオーバーが、データ損失ゼロで実行できます。 スタンバイへの切り替えは、読み取りのダウンタイムなしで行われます。 書き込み処理には、切り替えフェーズ中に内部サービスの再試行が必要になる場合があります。 これらの再試行は、アプリケーション側では、書き込み速度が遅くなる現象として表れることがあります。
シャード のフェールオーバーが完了すると、クラスターは完全に動作可能になります。 元の高可用性構成に戻るための最後の手順は、スタンバイ シャードを再作成することです。 このスタンバイ シャードの再作成は、プライマリ シャードでダウンタイムやパフォーマンスへの影響が発生することなく実行されます。