FAQ: バックアップと復元

バックアップ機能にはどのバージョンの MongoDB が必要か?

バックアップにはどのような MongoDB 権限が必要か?

認証が有効になっている MongoDB インスタンスをバックアップする場合、MongoDB Agent には MongoDB Agent バックアップ機能に記載されている特権が必要です。

MongoDB Ops Managerは、データサイズをどのように測定しますか。

MongoDB Ops Managerは、次の変換を使用してスナップショットのサイズを測定し、 oplogデータの処理量を測定します。

• 1MB = 1024 ²バイト（1 MiB）

• 1 GB = 1024 ³バイト（1 GiB）

• 1 TB = 1024 ⁴バイト（1 TiB）

バックアップはすべてのタイプの配置で機能しますか？

• MongoDB 4.2以降については、「 データベースのバックアップに関する考慮事項 」を参照してください。

• FCV およびそれ以前のデータベースを含むMongoDBでは、バックアップはスタンドアロン配置をサポートしていません。4.0バックアップは、レプリカセットとシャーディングされたクラスターを完全にサポートしています。

バックアップ機能がスタンドアロン配置をサポートしていない理由

MongoDB Ops Managerは、 oplogからデータをコピーして、ポイントインタイムリカバリを備えた継続的なバックアップを提供します。 MongoDB Ops Managerは、 oplogがないため、スタンドアロン ホストのバックアップをサポートしていません。 単一のmongodインスタンスによるバックアップをサポートするには、1 つのメンバーのレプリカセットを実行できます。

バックアップ機能の仕組み

バックアップ機能の詳細については、「バックアップ プロセス 」を参照してください。

バックアップは本番環境のデータベースに影響を与えますか？

バックアップ機能は通常、本番環境の MongoDB 配置への影響を最小限に抑えます。 この影響は、 レプリカセット に新しい セカンダリ を追加する場合と同様にパフォーマンスを発揮します。

デフォルトでは、バックアップエージェントは、影響を制限するために、レプリカセットの セカンダリ ノードに対して最もリソースを集中する操作である 最初の同期 を実行します。 オプションで、バックアップエージェントをレプリカセットのプライマリに対して最初の同期を実行するように構成できますが、これにより最初の同期操作の影響が大きくなります。

バックアップが有効な状態でレプリカセットを維持するにはどうすればよいですか。

レプリカセット内のほとんどの操作は oplog を介して複製され、バックアップ プロセスによってキャプチャされます。 ただし、一部の操作では、複製され ない 変更が行われます。これらの操作では、変更を含めるために MongoDB Ops Managerが 現在のレプリカセットから再同期されて いる 必要 があります。

次の操作は複製されないため、再同期が必要になります。

• データベースの名前を変更または削除するには、データディレクトリ内のデータファイルを削除します。 あるいは、mongosh からの { db.dropDatabase()など、MongoDB が複製する操作を使用してデータベースを削除します

• インスタンスがスタンドアロンとして実行中にデータを変更します。

• ローリング処理によるインデックスビルド。

• compactまたはrepairDatabaseを使用して、大量のスペースを再利用します。

  再同期は、 compactまたは repairDatabase 操作の後に厳密に必要ではありませんが、 MongoDB Ops Managerのデータのコピーがサイズ変更されるため、復元がより迅速になります。

バックアップエージェントはどこで実行すればよいか？

以下のホストでバックアップエージェントを実行します。

• MongoDB インスタンスとは別です。 これにより、システム リソースの競合が回避されます。

• MongoDB インスタンスに接続できます。 エージェントと MongoDB ホスト間の接続のネットワーク設定を確認します。 必要なポートのリストについては、「エージェントのオープン ポート 」を参照してください。

• 少なくとも 2 つの CPU コアと 3 GB の RAM があり、 バックアップエージェントが実行するたびに、バックアップエージェントはホストのパフォーマンスにさらに影響を与えます。

1つのシステム上でバックアップエージェントとモニタリングエージェントを実行できますか。

バックアップエージェントとモニタリングの単一のシステムまたはホスト上での実行を妨げる技術的制限はありません。 ただし、両方のエージェントにはリソース要件があり、1 つのシステムで両方を実行すると、 MongoDB Ops Managerでの配置をサポートするこれらのエージェントの機能に影響する可能性があります。

バックアップエージェントに必要なリソースは、新しい oplog エントリのレートとサイズ（1 時間あたりの oplog の合計 ギガバイト）によって異なります。 モニタリングに必要なリソースは、モニタリング対象のmongod インスタンスの数と インスタンスが提供する データベース mongodの合計数によって異なります。

複数のバックアップエージェントを実行して高可用性を実現できますか

高可用性を実現するために複数のバックアップエージェントを実行できます。 その場合、バックアップエージェントは異なるホストで実行される必要があります。

複数のバックアップエージェントを実行する場合、プロジェクトごとに 1 つのエージェントのみがプライマリエージェントになります。 プライマリエージェントがバックアップを実行します。 残りのエージェントは完全にアイドル状態ですが、ステータスがスタンバイとしてログに記録され、プライマリになるべきかどうかが定期的に MongoDB Ops Manager に確認されます。

バックアップエージェントはデータベースを変更しますか？

バックアップエージェントは、チェックポイントと呼ばれる小さなトークンをソースデータベースの oplog に定期的に書き込みます。 これらのトークンはバックアップのハートビートを提供し、ソース配置には影響しません。 各トークンは 100 バイト未満です。

最初のバックアップ同期はデータベースのパフォーマンスにどのような影響を与えますか。

最初のバックアップ同期の影響は、新しいセカンダリ レプリカセット メンバーを同期する場合と同様です。 バックアップエージェントはそのアクティビティを制限せず、同期を可能な限り迅速に実行しようとします。

MongoDB Ops Managerがコレクションをバックアップしないようにするにはどうすればよいですか。

MongoDB Ops Managerには、バックアップするコレクションまたはデータベースを指定できる名前空間フィルターが用意されています。

バックアップされる名前空間を変更するにはどうすればよいですか?

フィルターを編集するには、「バックアップの設定の編集 」を参照してください。 名前空間フィルターを変更すると、再同期が必要になる場合があります。 その場合、MongoDB Ops Manager が再同期を取り扱います。

MongoDB Ops Managerはどのようにポイントインタイム復元を提供しますか。

復元をtriggerすると、 MongoDB Ops Managerはこのスナップショットへのリンクを作成します。 クリックすると、 MongoDB Ops Managerは Snapshot Store からチャンクを取得し、それらをターゲット ホストにストリーミングします。

次に、そのホスト上で実行されている MongoDB バックアップ復元ユーティリティは、指定された時点に達するまでの oplog エントリをダウンロードし、適用します。

MongoDB Ops Managerが特定のポイントインタイム復元を提供できるかどうかは、スナップショットの保持ポリシーと構成されたポイントインタイムウィンドウによって異なります。

保持ポリシーとポイントインタイム ウィンドウの詳細については、 「 スナップショット スケジュールと保持ポリシーの編集 」を参照してください。

6 時間ごとよりも頻繁にスナップショットを取得できますか

いいえMongoDB Ops Managerは 6 時間以上の頻度のスナップショット スケジュールをサポートしていません。 詳細については、「スナップショット頻度と保持ポリシー 」を参照してください。

独自のスナップショット保持ポリシーを設定できますか。

はい。 バックアップ配置の Edit Snapshot Scheduleメニュー オプションを使用してスケジュールを変更できます。 管理者は、 API の snapshotSchedule リソース を使用して、スナップ ショット頻度と保持ポリシー を変更できます。

復元スナップショットの作成にかかる時間

MongoDB Ops Managerは、すべてのバックアップを圧縮された形式でMongoDB Ops Managerホストからインフラストラクチャに送信します。

さらに、ポイントインタイム復元では、バックアップの要求されたポイントインタイムにロールフォワードするためにホストが受信したスナップショットに適用する必要がある oplog エントリの量によって異なります。

バックアップ機能によってデータ検証は実行されますか？

バックアップは基本的な破損チェックを実行し、いずれかのコンポーネント（例: エージェント）がダウンしたり、機能したりした場合はアラートを提供しますが、明示的なデータ検証は実行しません。 MongoDB Ops Managerは、破損を検出すると、注意側でエラーを発生させ、現在のバックアップを無効にして、アラートを送信します。

スナップショットの復元方法

MongoDB Ops Manager経由で復元をリクエストできます。復元するスナップショットとMongoDB Ops Managerによる復元の配信方法を選択できます。 すべての復元には 2 要素認証が必要です。 SMS が設定されている場合、 MongoDB Ops Managerは SMS 経由で認証コードを送信します。 復元プロセスを開始するには、バックアップ インターフェースに認証コードを入力する必要があります。

スナップショットを復元したときに提供されるもの

MongoDB Ops Managerは、 MongoDBデータファイルの tar.gz アーカイブとして復元を提供します。

復元の詳細については、「 MongoDB デプロイの復元 」を参照してください。

MongoDB Ops Managerはバックアップされたデータをどのようにロールバックしますか。

MongoDB配置でロールバックが発生した場合、 MongoDB Ops Managerはバックアップされたデータもロールバックします。

MongoDB Ops Managerは、追尾カーソルが書込み (write) 操作のタイムスタンプまたはハッシュで不一致を見つけたときにロールバックを検出します。 MongoDB Ops Managerは ロールバックoplog 状態になり、レプリカセットの プライマリ の 内の 3 つのポイントをテストして、履歴内の共通点を見つけます。MongoDB Ops ManagerMongoDBのロールバックは、共通点が必ずしも 最新の 共通点である必要がないという点で セカンダリ ロールバックと異なります。

MongoDB Ops Managerが共通点を見つけると、サービスはその点を超えるoplogエントリとスナップショットを無効にし、共通点の前の最新のスナップショットにロールバックします。 その後、 MongoDB Ops Managerは通常のバックアップ操作を再開します。

MongoDB Ops Manager が共通点を見つけられない場合は、再同期が必要です。

再同期が必要な条件

バックアップエージェントの 追尾カーソルが配置のoplogに追いつけない場合は、バックアップを再同期する必要があります。

このシナリオは、次の場合に発生することがあります。

• アプリケーションが定期的に大量のデータを生成するため、プライマリのoplog window oplogMongoDB Ops Managerは、 が消費するよりも速く に書き込まれる点まで縮小されます。

• バックアップエージェントがプロビジョニングされていないマシンまたは過剰に使用されているマシンで実行され、 oplog のアクティビティに追いつけない場合。

• バックアップエージェントが oplog サイズで許容される以上の期間ダウンした場合。 メンテナンスのためなど、エージェントをダウンさせる場合は、適格に再起動してください。 oplogサイズの詳細については、 oplogMongoDBマニュアルの 「 レプリカセット 」 を参照してください。

• すべてのレプリカセット データを削除し、同じ名前で新しいレプリカセットを配置すると、配置が定期的に切断され、再構築されます。

• ロールバックが発生した場合、 とMongoDB Ops Managerはoplog内で共通の点を見つけられません。

• oplog イベントが、レプリカセットのバックアップに存在しないドキュメントを更新しようとした場合、プライマリとのデータ整合性がないセカンダリからの同期によって発生する可能性があります。

• インデックスを ローリング方式 で作成する場合。