プライマリMongoDB Ops Managerが失われた場合は、セカンダリMongoDB Ops Managerからバッキング データベースを復元し、新しいプライマリMongoDB Ops Managerを起動します。アップグレードの失敗、データの誤った削除、インフラストラクチャの障害などのイベントの後にこの手順を使用します。プライマリMongoDB Ops Managerが再起動すると、通常の操作が再開される前にエージェント構成を調整するために、自動的に復元モードに入ります。このパターンの概要については、「セカンダリ インスタンスを使用した MongoDB Ops Manager のバックアップと復元」を参照してください。このパスワードなしを構成するには、「 セカンダリOps Managerを使用してOps Managerをバックアップする」を参照してください。
Considerations
順序を復元
バッキング データベースの復元とプライマリ MongoDB Ops Manager の起動の順序は重要です。
警告
プライマリ MongoDB Ops Manager を起動する前に、バッキング データベースを復元します。プライマリ MongoDB Ops Manager のバッキング データベースを復元する前にプライマリ MongoDB Ops Manager を起動すると、プライマリ MongoDB Ops Manager は不整合な状態を書き込み、古い配置と新しい配置の間で分裂ブレイン シナリオを作成する可能性があります。
セカンダリの MongoDB Ops Manager もスナップショットメタデータストアと oplog メタデータストアをバックアップする場合は、プライマリの MongoDB Ops Manager を起動する前に、3 つのバッキング データベースを同じ時点に復元するか、メタデータストアをアプリケーションデータベースよりもわずかに時間を遅らせて復元します。メタデータストアをアプリケーションデータベースよりも早い時点に復元すると、プライマリの MongoDB Ops Manager は影響を受けた復元ジョブを HTTP 409 （「スナップショット ブロックが見つかりません」）で拒否します。
リカバリ点
ポイントインタイム復元では、災害発生時ではなく、選択した時点にアプリケーションデータベースを復元します。災害発生前にバックアップで oplog slice にキャプチャされなかった操作は復元できない可能性があります。災害に可能な限り近い復元ポイントを選択します。このポイントインタイム復元ウィンドウでは、災害に可能な限り近い復元ポイントを選択します。
プライマリ MongoDB Ops Manager が再起動すると、調整によって MongoDB エージェントから配置オートメーション構成が復元されます。その他の最近のアプリケーションデータベースの変更には、選択した復元ポイントが反映されます。
バージョンの互換性
プライマリとセカンダリの MongoDB Ops Manager のバージョンは互換性を維持する必要があります。
警告
スナップショットの取得元となったオリジナルのプライマリ MongoDB Ops Manager と同じバージョンまたはそれ以降のバージョンを実行するプライマリ MongoDB Ops Manager にアプリケーションデータベースを復元します。置き換えるバイナリがアプリケーションデータベースの記録されたバージョンより古い場合、MongoDB Ops Manager は「ダウングレードは許可されません」エラーで起動を拒否します。
前提条件
復元モードは、MongoDB Ops Manager 8.0.24 以降でデフォルトで有効になっています。無効にした場合は、復元する前にプライマリ MongoDB Ops Manager で再度有効にします。手順については、「MongoDB Ops Manager をバックアップするためのセカンダリ MongoDB Ops Manager の構成」を参照してください。
セカンダリ MongoDB Ops Manager に、バッキング データベースのスナップショットと連続的なポイントインタイムリカバリー ウィンドウが完了していることを確認します。
オリジナルのプライマリ MongoDB Ops Manager インストールからの
gen.keyファイルを含め、必要なホストごとの状態がリカバリのために保持されていることを確認します。
ホストごとの状態を維持する
フルプライマリ MongoDB Ops Manager のリカバリには、アプリケーションデータベース以外のものが必要です。セカンダリ MongoDB Ops Manager がバックアップするアプリケーションデータベースに加えて、各ホストで次の状態を保持します。
Item | ロケーション | 説明 |
|---|---|---|
暗号化のキー |
| アプリケーションデータベースのコンテンツを暗号化します。オリジナルインストールに使用されたキーと一致する必要があります。一致しない場合、プライマリMongoDB Ops Managerはスタートアップ時に復元されたアプリケーションデータベースを複号化できません。 |
MongoDB Ops Manager の構成 |
| データベース URI、ブロックストア構成、ライセンス キー、および TLS 証明書を保存する。これがない場合、プライマリ MongoDB Ops Manager を手動で再構成する必要があります。 |
エージェントの構成 |
|
|
重要
gen.key ファイルが見つからないか、復元されたアプリケーションデータベースと一致しない場合、プライマリ MongoDB Ops Manager は、gen.key がこの MongoDB Ops Manager インストールで既に使用されているキーと一致しないというエラーでスタートアップの事前チェックに失敗します。アプリケーションデータベースデータとともに、障害復旧バックアップに gen.key を保存してください。
プライマリ MongoDB Ops Manager を復元します。
バッキング データベースを復元する
セカンダリ MongoDB Ops Manager で、選択した時点にプライマリ MongoDB Ops Manager のアプリケーションデータベースを復元します。
Continuous Backup をクリックし、アプリケーションデータベースレプリカセットを選択します。
メニューをクリックし、Restore をクリックします。
Point in Time を選択し、実行する日付と時刻を入力します。
Choose Cluster to Restore to をクリックし、アプリケーションデータベースのレプリカセットホストを選択してから、Restore をクリックします。
セカンダリの Ops Manager の MongoDB Agent は、アプリケーションデータベースプロセスを停止し、データを復元されたスナップショットで置き換え、oplog を対象時間まで再生し、プロセスを再起動します。
警告
セカンダリ MongoDB Ops Manager もスナップショットと oplog メタデータ ストアをバックアップする場合は、プライマリ MongoDB Ops Manager を起動する前に、メタデータ ストアをアプリケーションデータベースと同じ時点またはそれより少し遅い時点に復元します。メタデータ ストアを早い時点に復元すると、プライマリ MongoDB Ops Manager は影響を受けた復元ジョブを HTTP 409 (「スナップショット ブロックが見つかりません」)で拒否します。
アプリケーションデータベースのみを復元すると、セカンダリ MongoDB Ops Manager はメタデータストアを変更しません。これは通常操作には安全ですが、プライマリ MongoDB Ops Manager が復元ポイントから現在までの間に取ったバックアップ スナップショットは使用できない可能性があります。
プライマリ MongoDB Ops Manager を起動します
プライマリ MongoDB Ops Manager を起動します。プライマリ MongoDB Ops Manager は、復元されたアプリケーションデータベースに接続し、復元された状態を読み取り、復旧を開始します。詳細については、「MongoDB Ops Manager アプリケーションの起動と停止」を参照してください。
復元モードと突合
アプリケーションデータベースを復元し、プライマリ MongoDB Ops Manager を起動すると、プライマリ MongoDB Ops Manager は各 MongoDB Agent の構成バージョンを復元された構成バージョンと比較します。エージェントが新しいバージョンを報告すると、プライマリ MongoDB Ops Manager はそのプロジェクトの復元モードに入り、構成を自動的に調整します。
プライマリ Ops Manager は、プロジェクトを分離します。復元モード バナーが表示され、エージェントポーリングに変更されていない応答が返され、調整が完了するまでユーザー インターフェイスとAPIからの配置変更がブロックされます。
プライマリ MongoDB Ops Manager は各エージェントから構成バージョンを収集し、最新の構成を持つエージェントを選択し、その構成を正規構成としてアプリケーションデータベースに書き込みます。
プライマリ Ops Manager はプロジェクトの復元モードを終了し、通常操作を再開します。バックアップは自動的に再開されます。
この調整により、分裂ブレーンシナリオが防止されます。これにより、すべてのエージェントは、新しい構成を受け取る前に単一の正規構成に合流します。
アプリケーションデータベースを以前の時点にロールバックすると、復元された構成には復元後に行った配置変更が含まれなくなります。突合がない場合、エージェントは古い構成を受け取り、構成が参照しなくなったプロセスを停止します。影響は配置の変更によって異なります。
配置の変更 | 調整のないリスク |
|---|---|
新しいレプリカセット ノード | データは他のノードに存在するため、データが失われることはありません。 |
移行されたチャンクを含む新しいシャード | 移行されたチャンクは新しいシャードにのみ存在します。これを停止すると、そのデータにアクセスできなくなり、データの損失につながります。 |
新しいプロセスバージョン | プロセスはロールバックされたバイナリバージョンで実行できないため、操作上のズレが発生します。 |
新しいインデックス | MongoDB Ops Manager がインデックスを再構築するまで、インデックスクエリは劣化します。 |
照合により、これらの結果が防止されます。プライマリの MongoDB Ops Manager は、すべてのエージェントを最新の構成に統合し、復元モードを終了する前にオンデマンドスナップショットをキューに入れることで、一貫性のあるバックアップポイントを提供します。
復元された Ops Manager を検証する
復元されたプライマリ MongoDB Ops Manager が健全であることを確認します。
MongoDB エージェントが再接続し、健康な状態でレポートされることを確認します。
マネージド配置のオートメーション、バックアップ、モニタリングが再開されることを確認します。
プライマリの MongoDB Ops Manager が復元モードを終了したことを確認します。復元モードの状態を確認するには、
Project Read Onlyロールを持つユーザーとして、次のエンドポイントにGETリクエストを送信します。応答には、プロジェクトの現在の状態、trigger の理由、タイムスタンプが表示されます。GET /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
停止した調整からの復旧
プライマリ Ops Manager が復元モードの状態で再起動すると、次の MongoDB Agent ポールで再度調整がトリガーされます。再起動の場合は、アクションを実行する必要はありません。
エージェントにアクセスできないため、調整が完了しない場合があります。その場合は、 ロールを持つユーザーとして、次の API Project Ownerエンドポイントのいずれかを使用します。
調整を再試行するには、次のエンドポイントに
POSTリクエストを送信します。再試行により調整失敗カウンターがリセットされ、レストレーション モードを終了せずに調整が再実行されます。POST /api/public/v1.0/groups/{PROJECT-ID}/restorationMode/retry プライマリMongoDB Ops Managerに復元モードを終了して復元された構成を受け入れるよう強制するには、次のエンドポイントに
DELETEリクエストを送信します。DELETE /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
警告
プライマリ MongoDB Ops Manager に復元モードを強制終了させると、後のエージェント構成を調整せずに復元された構成を受け入れます。調整が完了できない場合にのみ、このエンドポイントとなる接続されたデバイスを使用します。強制終了後、プライマリ MongoDB Ops Manager はプロジェクト内のすべてのエージェントに復元された構成を提供します。また、すべてのエージェントがそれに合致するまで、復元モードに再び入りません。
復元された MongoDB Ops Manager へ切り替える
このパターンは、プライマリ MongoDB Ops Manager をインプレースで復元します。セカンダリ MongoDB Ops Manager をプライマリ MongoDB Ops Manager の代わりに昇格させることはありません。
復元したプライマリ MongoDB Ops Manager を検証した後、カットオーバーを実行します。
URL to Access Ops Manager設定とすべての DNS レコードを更新して、復元されたプライマリ MongoDB Ops Manager を指すようにします。MongoDB エージェントが復元されたプライマリ Ops Manager に接続することを確認します。エージェントの構成にある
mmsGroupIdとmmsApiKeyが復元されたプロジェクトレコードと一致する場合、エージェントは再登録せずに再接続します。
操作ガイダンス
次のプラクティスを使用して、このパターンを長期にわたって運用および検証します。
バックアップとリストアのパスをテストする
テストされていない復元は、運用上のリスクです。このバックアップと復元パスを定期的にテストします。次のランブックは、任意のガイダンスではなく、必須のプラクティスとして扱ってください。
予定に従ってテストの復元を実行します。バッキング データベースをサンドボック MongoDB Ops Manager に復元し、起動して調和することを確認します。
スナップショットが予定どおりに表示され、ポイントインタイムリカバリ ウィンドウが継続していることを確認します。
バックアップと復元のエラーについて、プライマリ MongoDB Ops Manager とセカンダリ MongoDB Ops Manager のログを確認します。
セカンダリ MongoDB Ops Manager をモニターします
セカンダリ Ops Manager と、それがバックアップするバッキング データベースをモニターします。
Ops Managerのバックアップ アラートを使用して、バッキング データベースの見逃したスナップショットまたは失敗したスナップショットを監視します。
点インタイムリカバリーウィンドウが継続していて、前進し続けることを確認します。
セカンダリ MongoDB Ops Manager のアプリケーションデータベースとバックアップデーモンの状態をモニターします。
障害シナリオ
次の表は、一般的な障害シナリオでこのパターンがどのように動作するかを説明します。
Scenario | 影響 | リカバリ |
|---|---|---|
セカンダリの MongoDB Ops Manager が一時的に利用できません | 新しいバックアップと復元は一時停止します。プライマリ MongoDB Ops Manager とすべてのマネージド エージェントは引き続き実行されます。 | セカンダリ MongoDB Ops Manager を復元します。バックアップエージェントは自動的に再開します。 |
復元後にセカンダリ MongoDB Ops Manager が失敗します | なし。アプリケーションデータベースを復元すると、プライマリ MongoDB Ops Manager は復元モードに入り、セカンダリ MongoDB Ops Manager なしで調整します。 | アクションは必要ありません。 |
両方の MongoDB Ops Manager インスタンスの損失 | プライマリの MongoDB Ops Manager アプリケーションデータベースのポイントインタイムリカバリーが失われます。 | セカンダリ MongoDB Ops Manager を再構築してアプリケーションデータベースを再インポートするか、プライマリ MongoDB Ops Manager を再構築してクラスターを手動で再インポートします。 |
パフォーマンス、ストレージ、コストの考慮事項
専用のセカンダリ MongoDB Ops Manager を実行する場合は、次の点を考慮してください。
セカンダリ MongoDB Ops Manager のサイズをプロダクションのプライマリ MongoDB Ops Manager よりも大幅に小さくします。バックアップと復元のためにプライマリ MongoDB Ops Manager のバッキング データベースのみを管理し、MongoDB クラスターは管理しません。
スナップショットの予定と保持ポリシーに基づいて、バッキング データベースのスナップショット ストレージのキャパシティを計画します。
専用のセカンダリ MongoDB Ops Manager を実行する余計なインフラストラクチャと運用コストを考慮してください。