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