セカンダリ Ops Manager と呼ばれる 2 つ目の Ops Managerインスタンスを配置して、プライマリ Ops Manager とその バッキング データベースをバックアップできます。プライマリ Ops Manager を紛失した場合、セカンダリ Ops Manager はリカバリ パスとしても機能します。
このパターンは、Ops Manager がアプリケーションデータベースとメタデータストアに保存する運用データを保護します。このガイドを使用して、Ops Manager 自体の障害復旧を設計、構成、操作します。
このガイドは、バックアップと障害復旧を管理する Ops Manager 管理者と、Ops Manager の高可用性と障害復旧トポロジーを設計するチームを対象としています。
セカンダリ Ops Manager バックアップの仕組み
このパターンでは、2 つの MongoDB Ops Manager インスタンスが異なる責任を持っています。
プライマリ Ops Manager は、 MongoDB配置とそのバックアップを通常どおり管理します。
セカンダリ Ops Manager は、プライマリ Ops Manager のバッキング データベースのみを管理およびバックアップします。セカンダリ Ops Manager は、アプリケーションクラスターを管理しません。
MongoDB Agent はプライマリ Ops Manager のアプリケーションデータベースの各ホスト上で実行され、セカンダリ Ops Manager に登録されます。セカンダリ Ops Manager は、これらのバッキング データベースの継続的およびポイントインタイム バックアップを取得します。
プライマリ Ops Manager を紛失した場合は、セカンダリ Ops Manager からそのバッキング データベースを復元し、新しいプライマリ Ops Manager を起動します。プライマリ Ops Manager は復元されたバッキング データベースに再接続し、 MongoDB配置の管理を再開します。
MongoDBエージェントが再起動後に再接続すると、復元されたデータベースよりも新しい 構成バージョン が報告されます。プライマリ Ops Manager は不一致を検出し、 影響を受けるプロジェクトの復元モードに自動的に移行し、復元された構成のすべてのエージェントを変換し、調整が完了するまで配置の変更をブロックします。
アーキテクチャ
次の表では、このパターン内のコンポーネントとその役割について説明しています。
コンポーネント | 責任 |
|---|---|
プライマリ Ops Manager | MongoDB配置とそのバックアップを管理します。独自の運用データをアプリケーションデータベース、 スナップショットメタデータストア 、およびoplogメタデータストアに保存します。 |
セカンダリ Ops Manager | アプリケーションデータベースのスナップショットとoplogスライスのために S 互換のストレージブロックストアに書込むバックアップデーモンを実行します。プライマリ Ops Manager のバッキング データベースを継続的にバックアップします。アプリケーションクラスターを管理しません。3 |
アプリケーションデータベース | プロジェクト構成、オートメーションの状態、バックアップメタデータなど、プライマリ Ops Manager の運用データを保存します。アプリケーションデータベースをバックアップする必要があります。 |
スナップショットとoplogメタデータストア | プライマリ Ops Manager がバックアップする配置のブロック インデックスとoplogインデックスを保存します。これらのストアもバックアップします。 |
MongoDB エージェント | 各バッキングデータベースホストで を実行し、セカンダリ Ops Manager に登録してバックアップと復元を実行します。 |
セカンダリ Ops Manager は、プライマリ Ops Manager のバッキング データベースのバックアップを、プライマリ Ops Manager のバックアップストレージとは別に、独自の S3 互換ストレージブロックストアに保存します。
配置のバリエーション
セカンダリ Ops Manager をプライマリ Ops Manager とは別の障害ドメインに配置して、単一の障害が両方の インスタンスに影響を与えるのを防ぎます。一般的なバリアントには、次のようなものがあります。
異なるリージョン
セカンダリ Ops Manager をプライマリ Ops Manager とは異なるクラウドリージョンに配置します。このバリアントは、リージョンの損失を防ぎます。
異なるデータセンター
プライマリ Ops Manager とは異なるデータセンターに セカンダリ Ops Manager を配置します。このバリアントは、 データセンターの損失を防ぎます。
別のバックアップネットワーク
セカンダリ Ops Manager を、バックアップトラフィック専用の別のネットワークに配置します。このバリアントは、アプリケーションネットワークからバックアップトラフィックを分離します。
重要
セカンダリ Ops Manager を、プライマリ Ops Manager とは別の障害ドメイン（別のラグ、アベイラビリティーゾーン、リージョン、またはネットワーク セグメントなど）に配置します。両方の インスタンスが障害ドメインを共有している場合、1 つの障害でプライマリ Ops Manager とそのリカバリ パスの両方が中断される可能性があります。
サポートされているバージョンと制限
このパターンを使用する前に、次の要件と制限を確認してください。
サポートされているバージョン
MongoDB Ops Manager のプライマリとセカンダリ インスタンスの両方で Ops Manager 8.0.24 以降を実行する必要があります。
セカンダリ Ops Manager は、プライマリ Ops Manager と同じかそれ以降のバージョンを実行する必要があります。プライマリ Ops Manager よりも前のバージョンのセカンダリ Ops Manager を実行しないでください。
警告
スナップショットの取得元となったプライマリ Ops Manager と同じバージョン、またはそれ以降のバージョンを実行するプライマリ Ops Manager に、アプリケーションデータベースを復元します。置き換えバイナリがアプリケーションデータベースの記録バージョンよりも古い場合、Ops は「ダウングレードは許可されていません」エラーを表示し、マネージャーの起動を拒否します。
制限
このパターンは、プライマリ Ops Manager のバッキング データベースをバックアップします。任意のMongoDBクラスターはバックアップされません。プライマリ Ops Manager は、 MongoDB配置のバックアップを引き続き管理します。
スナップショットメタデータストアとoplogメタデータストアのバックアップと調整は手動の手順です。 Ops Manager は、これらのストアの復元点を自動的に選択しません。その結果、復元後にバックアップメタデータの整合性が失われる可能性があり、一部のバックアップは復元できない場合があります。 Ops Manager は、安全でない復元を実行するのではなく、復元する前にスナップショットを検証し、エラーで失敗します。
復元モードは、 Kubernetes Operator が管理する配置など、外部が管理する配置には適用されません。アプリケーションデータベースを復元すると、これらのプロジェクトのエージェントは次回のポーリングで復元された構成を直接受け取り、復元モードになることなく変換されます。これらのプロジェクトではアクションは必要ありません。
スナップショットのデータ ブロックが読み取りにない場合は、スナップショットを復元できなくなる可能性があります。復元する前に、プライマリ Ops Manager はスナップショットのブロックが存在することを確認します。ブロックが欠落している場合、復元はエラーで失敗し、レプリカセットは変更されないままになります。
テストされていない復元は運用上のリスクがあります。バックアップと復元のパスを定期的に検証します。セカンダリ Ops Manager から Ops Manager を復元する の検証ランブを参照してください。
次のステップ
このパターンを設定して操作するには、次のページを参照してください。