障害復旧を計画することは、組織にとって重要です。次のような要素を含む包括的な障害復旧（DR）プランを作成することを強くお勧めします。
指定された目標復旧時点（RPO）
指定されたリカバリ時間目的 (RTO)
これらの目的との整合性を容易にする自動化プロセス
災害への備えと対応のため、このページの推奨事項を活用してください。
障害復旧に役立つ先を見越した高可用性構成の詳細については、「 Atlas 高可用性に関する 推奨事項 」を参照してください。
Atlas の障害復旧に関する機能
障害復旧をサポートする Atlas の機能については、Atlas アーキテクチャ センターの次のページをご覧ください。
Atlas の障害復旧に関する推奨事項
次の障害復旧に関する推奨事項を参照して、組織用の DR プランを作成します。これらの推奨事項は、災害イベントが発生した場合に取るべき手順に関する情報を提供します。
このセクションのプランは定期的に（できますが、少なくとも四半期ごとに）テストする必要があります。テストは、エンタープライズ データベース管理（EDM）チームが障害発生に対応する準備ができていると同時に、指示を最新に保つのにも役立ちます。
一部の障害復旧テストでは、EDM ユーザーでは実行できないアクションが必要になる場合があります。このような場合は、テストを実行中予定の の少なくとも 1 週間前に、強制停止を実行するためにサポートケースを開きます。
Atlas クラスターを配置できる各クラウドプロバイダーは、停止を軽減するのに役立つデフォルトのデータ冗長性を提供します。
AWS は、AWS リージョン内の少なくとも 3 つのアベイラビリティーゾーンにわたって複数のデバイスにオブジェクトを保存します。
Microsoft Azure は、選択したリージョン内の単一のデータセンター内でデータを 3 回複製するローカル冗長ストレージ（LRS）を使用します。
Google Cloud Platformは、バックアップ リージョンの複数のゾーンにデータを分散します。
障害復旧 を強化するには、Atlas を設定して、スナップショットと oplog のコピーを他のリージョンに自動的に作成するように設定できます。これにより、 プライマリ リージョンが停止時した場合でも、他のリージョンに保存されたスナップショット コピーを使用してクラスターを復元できます。 Atlas は、リージョンの可用性に基づいて最も効率的なオプションを選択し、復元速度を最適化します。また、これらのコピーが存在するリージョンに復元する場合は、コピーされたスナップショットを使用します。さらに、 リージョン停止時により元のスナップショットにアクセスできない場合、Atlas は使用可能な最も近いスナップショット コピーを使用して復元し、ダウンタイムを最小限に抑え、 回復回復力を向上させます。詳しくは、「 でスナップショットを他のリージョンに自動的にコピーするように Atlas を設定する 」を参照してください。
マルチリージョンまたはマルチクラウドのMongoDBクラスターを実行する場合は、データ破損のリスクを軽減するための特定のニーズを考慮してバックアップ戦略を構成していることを確認してください。システム内の潜在的なデータ破損の問題をどのように迅速に特定できるか。この検出時間枠を確立したら、それに応じてバックアップ保持を設定し、破損が発生する前からスナップショットが復元に使用できることを確認します。問題を検出する際の遅延や不正確性を考慮するために、バックアップ保持スケジュールに追加のバッファ（通常は 10-15% あたり）を含めることをお勧めします。このパディングにより、重要な情報を失うことなくクリーンなデータを確実に回復できるようになり、配置の全体的な回復力と信頼性が向上します。
すべての配置パラダイムの推奨事項
このセクションでは、次の障害復旧手順について説明します。
単一ノードの停止時
部分的な リージョン停止時によりレプリカセット内の 1 つのノードが障害が発生した場合でも、 ベストプラクティス に従っていることを前提とすると、配置は引き続き使用可能であるはずです。セカンダリから読み取る場合、セカンダリノードに障害が発生したイベントに、アンダープロビジョニングされたクラスターの負荷が増大するため、パフォーマンスが低下したり、停止したりする可能性があります。
Atlas UI の プライマリ フェイルオーバーのテスト 機能または Atlas 管理APIエンドポイント を使用して、Atlas でプライマリノードの停止時をテストできます。
リージョン停止
マルチリージョンクラスターは、 リージョン停止時が発生したイベントに、自動的に選挙を行い、必要に応じて新しいプライマリノードを識別します。このトポロジーの変更はアプリケーションに自動的に伝達され、必要な修正アクションの実行を可能にします。リージョン停止時 がイベントにアプリケーションのアップタイムを維持するには、アプリケーション自体もマルチリージョントポロジーを使用して配置する必要があります。この要件は、アプリケーションが統合できるサードパーティ サービスを含むように拡張されます。詳しくは、「 マルチリージョン配置パラダイム 」を参照してください。
単一リージョンの停止時またはマルチリージョンの停止時にクラスターの状態が低下する場合は、次の手順に従います。
識別したリージョンにノードを追加してください
停止時の原因による影響を受けやすいリージョン全体で通常の状態に必要な数のノードを追加します。
障害発生時にリージョンやノードを追加してレプリカセットを再構成するには、「地域障害時のレプリカセットの再構成」を参照してください。
Atlas UI の 停止時シミュレーション 機能または 停止時シミュレーションを開始する 管理APIエンドポイントを使用して、Atlas でリージョン停止時をテストできます。
クラウド プロバイダーの障害
マルチクラウドクラスターでは、クラウドプロバイダー全体で選択可能なノードを選択して、高可用性を維持できます。プライマリノードが配置されているプロバイダーが利用できなくなった場合、選択可能なノードをプライマリ ノードに変換して 継続的な操作を確保できます。例、 AWS 、Google Cloud、 Microsoft Azureに選択可能なノードを作成して、1 つのクラウドプロバイダーが停止時場合でも、別のプロバイダーの選挙可能な ノードがクラスターの プライマリノードとして引き継ぐことができます。詳細については、「 マルチクラウド配置パラダイム 」を参照してください。
ほとんどのマルチリージョンAtlas クラスターは、 単一リージョンの停止時から自動的に回復します。詳しくは、「 高可用性 」セクションと「 マルチリージョン配置 」ページを参照してください。リージョン停止によって過半数のノードがダウンした場合、大過半数のノードが正常に機能するために必要なノード数の数を判断する必要があります。
非常に稀なケースとして、クラウドプロバイダー全体が利用不可になった場合、次の手順に従って配置を再度オンラインにします。
新しいクラスターを配置する代替のクラウドプロバイダーを特定する
クラウドプロバイダーと情報のリストについては、「 クラウドプロバイダー 」を参照してください。
複数のクラウドプロバイダーにバックアップを保存する場合、クラウドプロバイダーが停止時と、プライマリクラウドプロバイダーに保存されているバックアップは必ずしも利用できなくなるため、停止時が開始される前にクラスターの利用可能な最新のスナップショットを見つけます。
バックアップ スナップショットの表示方法については、「M10+ バックアップ スナップショットの表示」をご覧ください。
前のステップから新しいクラスターに最新のスナップショットを復元します。
スナップショットを復元する方法については、「 クラスターの復元 」を参照してください。
古いクラスターに接続するアプリケーションを新しく作成されたクラスターに切り替える
新しい接続文字列を見つけるには、「ドライバー経由で接続」を参照してください。多くの場合、新しいクラウド プロバイダーに再デプロイする必要があるため、アプリケーション スタックについてレビューします。
Atlas の停止時
非常に稀なケースですが、Atlas Control Plane と Atlas UI が使用できない場合でも、クラスターは引き続き利用およびアクセス可能です。詳しくは、「プラットフォームの Reliability」をご覧ください。この問題をさらに調査するには、高優先順位のサポートチケットを開きます。
リソースのキャパシティーの問題
計算リソース（ディスク容量、RAM、CPU など）のキャパシティーの問題は、計画が不十分であったり、データベース トラフィックが予期せぬものであった場合に発生する可能性があります。この現象は、災害の結果ではない可能性があります。
計算リソースが最大割り当て量に達し、災害を引き起こした場合は、次の手順を実行します。
リアルタイム パフォーマンス パネル または Atlas メトリクスを使用して、どの計算リソースが最大使用量になっているかを識別する
Atlas UIでリソース使用率を表示するには、「 リアルタイム パフォーマンスのモニタリング 」を参照してください。
Atlas Administration APIを使用してメトリクスを表示するには、「 モニタリングとログ 」を参照してください。
必要なリソースを割り当てます
Atlas はこの変更を順次実行するため、アプリケーションに大きな影響を与えることはありません。
より多くのリソースを割り当てる方法については、「 クラスターの編集 」を参照してください。
リソースの故障
重要
これは、システム全体のダウンタイムを短縮することを目的とした一時的な解決策です。基礎となる問題が解決されたら、新しく作成したクラスターのデータを元のクラスターにマージし、すべてのアプリケーションを元のクラスターに戻し点。
計算リソースが故障し、クラスターが利用不可になった場合、次の手順に従います。
最新のバックアップを新しく作成されたクラスターに復元する
スナップショットを復元する方法については、「 クラスターの復元 」を参照してください。
本番データの削除
人為的なミスやデータベース上に構築されたアプリケーションのバグにより、プロダクション データが誤って削除される可能性があります。クラスター自体が誤って削除された場合、Atlas はボリュームを一時的に保持する可能性があります。
コレクションまたはデータベースの内容が削除された場合は、次の手順に従ってデータを復元します。
データが含まれている場合は、コレクションまたはデータベースの現在の状態のコピーを作成します
mongoexport を使用してコピーを作成できます。
データを復元
削除が過去 72 時間以内に発生し、継続的なバックアップを設定した場合は、ポイント イン タイム（PIT）リストアを使用して、削除が発生する直前の時点にリストアします。
過去 72 時間で削除が発生していない場合は、削除が発生する前の最新のバックアップをクラスターに復元します。
詳しくは、「 クラスターの復元 」を参照してください。
データのコピーを作成した場合は、エクスポートした新しいデータをインポートします。
mongoimport をアップサートモードで使用してデータをインポートし、変更または追加されたデータがコレクションまたはデータベースに適切に反映されていることを確認します。
ドライバーの故障
ドライバーに障害が発生した場合は、次の手順を実行します。
データの破損
重要
これは、システム全体のダウンタイムを短縮することを目的とした一時的な解決策です。基礎となる問題が解決されたら、新しく作成したクラスターのデータを元のクラスターにマージし、すべてのアプリケーションを元のクラスターに戻し点。
基礎データが破損した場合は、次の手順に従います。
最新のバックアップを新しく作成されたクラスターに復元する
スナップショットを復元する方法については、「 クラスターの復元 」を参照してください。