FAQ: バックアップと復元

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud Manager では、oplog を必要な時間だけ再生することで、24 時間以内の任意の点での復元を構築できます。

レプリカセットとシャーディングされたクラスターを復元する方法については、「 MongoDB 配置の復元 」を参照してください。

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

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

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

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

スナップショット頻度と保持ポリシーをカスタマイズすると、バックアップ コストをより詳細に制御できます。

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

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

米国内では、Cloud Manager は 50 ～ 100 書き込みでスナップショットを送信します。 圧縮係数が 4 倍、転送速度が 50 KB と仮定すると、250 GB のスナップショットの送信に 2.5 時間かかります。

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

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

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

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

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

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

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

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

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

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

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

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

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

再同期が必要な条件

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

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

• アプリケーションが定期的に大量のデータを生成し、プライマリの oplog window を縮小して、Cloud Manager が消費するよりも速く oplog にデータが書き込まれるようにします。

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

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

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

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

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

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