障害復旧（DR）は、自動フェイルオーバーが解決しない場合に手動の手順を使用して配置を回復する回復力戦略です。高可用性とは異なり、インフラストラクチャの障害を自動的に自己修復するのに対し、障害復旧ではバックアップから復元するために人間による介入が必要です。
注意
MongoDB Atlas共有責任モデルは、安全で回復力のあるデータ環境を維持するためのMongoDBとそのカスタマーの補完的な役割を定義します。このフレームワークの下、 MongoDB は基礎のプラットフォームのセキュリティと運用上の整合性を管理しますが、カスタマーは特定の配置の構成、管理、データ ポリシーに責任を負います。所有者のセキュリティと運用の優れ性の詳細な内訳については、共有責任モデルを参照してください。
障害復旧を使用する場合
重要
可能な場合は高可用性を優先します。高可用性が不可能な場合にのみ、プライマリ回復力戦略として障害復旧を使用してください。
障害復旧は、次の状況でのプライマリ回復力戦略として適しています。
- 地理的制約
- 十分なアベイラビリティーゾーンを持つ複数のリージョンには配置できません。例、カナダに を配置する必要がある場合は、2 リージョンのみが利用可能であり、自動フェイルオーバークォーラム要件は満たされません。
- コスト最適化
- インフラストラクチャのコストを最小限に抑える必要があります。マルチリージョンまたはマルチクラウドの高可用性配置は、バックアップを使用した単一リージョン配置よりもコスト。
- 手動復元の許容度
- アプリケーションは、手動介入とバックアップ復元に必要な時間を許容できます（RTO は 秒ではなく 分から 時間単位）です。
注意
高可用性を使用している場合でも、データの破損や誤った削除など、自動フェイルオーバーでは処理できないシナリオでは、障害復旧手順のメリットが得られる場合があります。両方のアプローチの組み合わせの詳細については、Atlas Business Container のプランニング のガイダンスを参照してください。
バックアップは障害復旧をサポートする方法
バックアップは、障害復旧 を実行するためのプライマリ ツールです。Atlas は、自動フェイルオーバーが改善しない場合に手動リカバリを可能にする完全管理でカスタマイズ可能なバックアップを提供します。
クラウドバックアップ
クラスターのクラウドバックアップを有効にすると、Atlas はクラウドプロバイダーのネイティブ スナップショット機能を使用して、復元時間がデフォルトで不変の増分バックアップを作成します。
DR をサポートする方法は次のとおりです。
RPO要件を満たすために、スナップショット頻度（時間ごと、毎日、毎週、毎月、年ごと）を設定します。
コンプライアンスとリカバリのニーズに合わせてスナップショットの保持期間を設定します。
データの破損または削除から回復するためにスナップショットを復元します。
使用ケース: スナップショット頻度と等しいデータ損失を許容できる標準的な障害復旧シナリオ。例、1 時間ごとのスナップショットでは最大 1 時間のデータが失われます。
継続的なクラウドバックアップによるポイントインタイムリカバリ
クラウドバックアップに加えて継続的なクラウドバックアップを有効にすると、Atlas はクラウドバックアップ スナップショットとともにoplogデータを保存し、Atlas が設定可能な ポイントインタイム（PIT）復元ウィンドウ内の特定の時点にクラスターを復元できるようにします。
DR をサポートする方法は次のとおりです。
構成可能な PIT 復元ウィンドウ内の任意の時点に復元する。Atlas は、 復元ウィンドウの長さまでoplogデータを保持し、最も近いクラウドバックアップ スナップショットに合わせてoplogエントリを再生して、指定した正確な時点に復元します。
RPO を最短 1 分で実現します。
データの破損または削除が発生する前の瞬間を正確にターゲットにする。
使用ケース: データ損失を最小限に抑える必要がある場合（低 RPO）、または特定のタイムスタンプへの正確な回復が必要な場合。
マルチリージョン スナップショットの分散
スナップショット コピー ポリシーを使用してクラウドバックアップを有効にすると、Atlas を構成して、スナップショットと oplog のコピーを他の地理的条件の追加のクラウドプロバイダーリージョンに自動的に分散できます。
DR をサポートする方法は次のとおりです。
地理的に分散されたバックアップのコンプライアンス要件を満たします。
プライマリ リージョンが完全に障害化された場合でも、バックアップにアクセスし続けることが保証されます。
マルチリージョンクラスターの場合、スナップショット コピー ポリシーで Automatically Sync Copy Regions with Cluster Regions オプションを有効にすると、Atlas はクラスターが配置されているすべてのリージョンにスナップショットを自動的に分散し、リージョンを追加または削除してもスナップショット コピー ポリシーを同期させます。これにより、Atlas は、リージョン停止時後に、より高速な直接ストリーミング復元を使用してクラスター リージョンを復元できるようになります 。
使用ケース: HA 構成を超える、完全なリージョン損失またはプロバイダーの停止時から保護する必要がある場合。
バックアップ戦略 RTO/RPO のトレードオフ
バックアップ戦略は、データの破損、誤って削除、配置の完全な損失など、自動フェイルオーバーでは処理できないデータの整合性の障害から保護します。すべてのバックアップ戦略には、ある程度のデータ損失（RPO > 0）とより長い復元時間（RTO が 分から 時間）を含みます。トレードオフは、失う可能性のあるデータ量とそれぞれのアプローチの運用の複雑さにおいてあります。
バックアップ戦略 | プライマリ ユースケース | 一般的な RTO | RPO | 操作上の考慮事項 | コストに関する考慮事項 |
|---|---|---|---|---|---|
定期的なスナップショット | データの破損、誤って削除、配置の完全な損失。 | 分から 時間。 | > 0（スナップショット間隔まで） | スケジュール/保持を定義します。復元手順を定期的にテストすること。 | ストレージは頻度と保持とともに増加します。復元には コンピュート/ Egress コストが発生します。 |
ポイントインタイム復元による継続的なバックアップ | 「古い」タイムスタンプが既知のデータ破損または削除。 | 分から 時間。 | > 0（ほぼゼロ、ダウンは 秒）。 | ポイント イン タイム（PIT）復元ウィンドウを構成します。障害を監視します。 | スナップショットのみを使用する場合よりもストレージとバックアップのコストが高くなります。 |
マルチリージョン スナップショットの分散 | リージョンまたはプロバイダーの損失は、ローカルバックアップにも影響します。 | 分から 時間（リージョンによっては遅くなる可能性があります）。 | > 0（スナップショット スケジュールに関連付けられている） | クロスリージョン復元の計画とテストを行います。保持ポリシーを管理します。 | 複数のリージョンにおける追加のストレージ。復元時の クロスリージョン Egress。 |
すべての配置パラダイムに共通する推奨事項
以下の推奨事項は、すべての配置パラダイムに適用されます。
このセクションでは、次の障害復旧手順について説明します。
単一ノードの停止時
部分的なリージョン停止でレプリカセット内の 1 つのノードが停止しても、ベストプラクティスに従っていれば、配置は引き続き利用可能です。セカンダリから読み取っている場合、セカンダリ ノードで障害が発生すると、プロビジョニングが不十分なクラスターの負荷が増加するため、パフォーマンスが低下したり、停止したりする可能性があります。
Atlas UI の プライマリ フェイルオーバーのテスト 機能または Atlas 管理APIエンドポイント を使用して、Atlas でプライマリノードの停止時をテストできます。
リージョン停止
リージョン停止時が発生したイベント、マルチリージョンクラスターは自動的に選挙を行い、必要に応じて新しいプライマリノードを識別します。このトポロジーの変更は自動的にアプリケーションに伝達され、必要な 修正アクション を実行できるようになります。リージョン停止時たイベントにアプリケーションのアップタイムを維持するには、アプリケーションもマルチリージョントポロジーを使用して配置する必要があります。この要件は、アプリケーションが統合できるサードパーティ サービスを含むように拡張されます。詳しくは、マルチリージョン配置パラダイム を参照してください。
単一リージョンの停止時またはマルチリージョンの停止時にクラスターの状態が低下する場合は、次の手順に従います。
識別したリージョンにノードを追加してください
停止時の原因による影響を受けやすいリージョン全体で通常の状態に必要な数のノードを追加します。
障害発生時にリージョンやノードを追加してレプリカセットを再構成するには、「地域障害時のレプリカセットの再構成」を参照してください。
Atlas UI の 停止時シミュレーション 機能または 停止時シミュレーションを開始する 管理APIエンドポイントを使用して、Atlas でリージョン停止時をテストできます。
クラウド プロバイダーの障害
マルチクラウドクラスターでは、クラウドプロバイダー全体で選挙可能なノードを選択して、高可用性を維持できます。プライマリノードが配置されているプロバイダーが利用できなくなった場合、Atlas は自動的に新しいプライマリ ノードを選択して 継続的な操作を確保します。例、AWS、Google Cloud、Microsoft Azureに選挙可能な ノードを作成して、1つのクラウドプロバイダーが停止時でも、別のプロバイダーの選挙可能な ノードが自動的にクラスターのプライマリノードを引き継ぐことができます。詳細については、マルチクラウド配置パラダイムを参照してください。
ほとんどのマルチリージョンAtlas クラスターは、 単一リージョンの停止時から自動的に回復します。詳細については、Atlas の高可用性のガイダンス と マルチリージョン配置パラダイム を参照してください。リージョン停止によって過半数のノードがオフラインになった場合、過半数のノードが正常に機能するために必要なノードの数を追加する必要があるかどうかを判断する必要があります。
非常に稀なケースとして、クラウドプロバイダー全体が利用不可になった場合、次の手順に従って配置を再度オンラインにします。
新しいクラスターを配置する代替のクラウドプロバイダーを特定する
クラウドプロバイダーと情報のリストについては、「 クラウドプロバイダー 」を参照してください。
バックアップを複数のクラウドプロバイダーに保存している場合、クラウドプロバイダーの停止によりプライマリクラウドプロバイダーに保存されているバックアップが利用できなくなるため、停止が始まる前に取得されたクラスターの最新のスナップショットを見つけます。
バックアップ スナップショットの表示方法については、「M10+ バックアップ スナップショットの表示」をご覧ください。
前のステップから新しいクラスターに最新のスナップショットを復元します。
スナップショットを復元する方法については、「 クラスターの復元 」を参照してください。
古いクラスターに接続するアプリケーションを新しく作成されたクラスターに切り替える
新しい接続文字列を見つけるには、クライアント ライブラリ経由で接続 を参照してください。アプリケーションスタックを新しいクラウドプロバイダーに再デプロイする必要がある可能性が高いため、アプリケーションスタックを検討します。
Atlas の停止時
非常に稀なケースですが、Atlas Control Plane と Atlas UI が使用できない場合でも、クラスターは引き続き利用およびアクセス可能です。詳しくは、「プラットフォームの Reliability」をご覧ください。この問題をさらに調査するには、高優先順位のサポートチケットを開きます。
リソースのキャパシティーの問題
計算リソース（ディスク容量、RAM、CPU など）のキャパシティーの問題は、計画が不十分であったり、データベース トラフィックが予期せぬものであった場合に発生する可能性があります。この現象は、災害の結果ではない可能性があります。
計算リソースが最大割り当て量に達し、災害を引き起こした場合は、次の手順を実行します。
リアルタイム パフォーマンス パネル または Atlas メトリクスを使用して、どの計算リソースが最大使用量になっているかを識別する
Atlas UIでリソース使用率を表示するには、「 リアルタイム パフォーマンスのモニタリング 」を参照してください。
Atlas Administration APIを使用してメトリクスを表示するには、「 モニタリングとログ 」を参照してください。
必要なリソースを割り当てます
Atlas はこの変更を順次実行するため、アプリケーションに大きな影響を与えることはありません。
より多くのリソースを割り当てる方法については、「 クラスターの編集 」を参照してください。
リソースの故障
重要
これは、システム全体のダウンタイムを短縮することを目的とした一時的な解決策です。基礎となる問題が解決されたら、新しく作成したクラスターのデータを元のクラスターにマージし、すべてのアプリケーションを元のクラスターに戻し点。
計算リソースが故障し、クラスターが利用不可になった場合、次の手順に従います。
優先順位の高いサポートチケット
最新のバックアップを新しく作成されたクラスターに復元する
スナップショットを復元する方法については、「 クラスターの復元 」を参照してください。
本番データの削除
人為的なミスやデータベース上に構築されたアプリケーションのバグにより、プロダクション データが誤って削除される可能性があります。クラスター自体が誤って削除された場合、Atlas はボリュームを一時的に保持する可能性があります。
コレクションまたはデータベースの内容が削除された場合は、次の手順に従ってデータを復元します。
データが含まれている場合は、コレクションまたはデータベースの現在の状態のコピーを作成します
mongoexport を使用してコピーを作成できます。
データを復元
削除が過去 72 時間以内に発生し、継続的なバックアップを設定した場合は、ポイント イン タイム（PIT）リストアを使用して、削除が発生する直前の時点にリストアします。
過去 72 時間で削除が発生していない場合は、削除が発生する前の最新のバックアップをクラスターに復元します。
詳しくは、「 クラスターの復元 」を参照してください。
データのコピーを作成した場合は、エクスポートした新しいデータをインポートします。
mongoimport をアップサートモードで使用してデータをインポートし、変更または追加されたデータがコレクションまたはデータベースに適切に反映されていることを確認します。
ドライバーの故障
ドライバーに障害が発生した場合は、次の手順を実行します。
データの破損
重要
これは、システム全体のダウンタイムを短縮することを目的とした一時的な解決策です。基礎となる問題が解決されたら、新しく作成したクラスターのデータを元のクラスターにマージし、すべてのアプリケーションを元のクラスターに戻し点。
基礎データが破損した場合は、次の手順に従います。
優先順位の高いサポートチケット
最新のバックアップを新しく作成されたクラスターに復元する
スナップショットを復元する方法については、「 クラスターの復元 」を参照してください。