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 サービスによってプライマリ シャードのエラーが検出され、スタンバイ ノードにフェールオーバーされ、データ損失がゼロに抑えられます。
クラスター接続文字列は、フェールオーバーに関係なく、常に同じままです。 これにより、サービスは、アプリケーションからの要求を処理する物理シャード内での変更を抽象化できます。
高可用性は、クラスター作成時に有効にできます。 また、高可用性は、既存の Azure Cosmos DB for MongoDB 仮想コア クラスター上でいつでも有効または無効にできます。 Azure Cosmos DB for MongoDB 仮想コア クラスターで高可用性が有効または無効にされるときに、データベースのダウンタイムはありません。
フェールオーバー中の動作
各シャード フェールオーバーは、使用不可の検出、スタンバイ シャードへの切り替え、スタンバイ シャードの再作成の 3 つのフェーズで構成されます。 このサービスは、定期的な正常性チェックを実行して、クラスター内のプライマリ シャードとスタンバイ シャードごとに可用性の継続的な監視を実行します。 正常性チェックが、シャードが応答しなくなり、シャード障害の発生を宣言する必要があることを確実に示すと、スタンバイ シャードへの実際のフェールオーバー (切り替え) が開始されます。
切り替えフェーズ中は、データベースの読み取りと書き込みがスタンバイ シャードにリダイレクトされます。 各プライマリ シャードとスタンバイ シャードと間の同期レプリケーションにより、スタンバイ シャードが持つデータ セットは、常にプライマリと同じになります。 これにより、すべてのフェールオーバーが、データ損失ゼロで実行できます。 スタンバイへの切り替えは、読み取りのダウンタイムなしで行われます。 書き込み処理には、切り替えフェーズ中に内部サービスの再試行が必要になる場合があります。 これらの再試行は、アプリケーション側では、書き込み速度が遅くなる現象として表れることがあります。
シャード のフェールオーバーが完了すると、クラスターは完全に動作可能になります。 元の高可用性構成に戻るための最後の手順は、スタンバイ シャードを再作成することです。 このスタンバイ シャードの再作成は、プライマリ シャードでダウンタイムやパフォーマンスへの影響が発生することなく実行されます。