Docs Menu
Docs Home
/
MongoDB データベース ツール
/

mongorestore の動作、アクセス、使用方法

項目一覧

  • 動作
  • 必要なアクセス権
  • バックアップ戦略での使用
  • 詳細

警告

データダンプと復元でのフィールドの $ プレフィックスとの競合

MongoDB 5.0以降、ドキュメントフィールド名の前にドル記号( $ )を付けることができます。 ただし、コレクションのオプションにおいてドル記号が先頭に付いているフィールド名では、 mongodumpmongorestoreは機能しません。

MongoDB 拡張 JSON(v 2 )は、type wrapper と、type wrapper と同じ名前を持つフィールドを区別できません。 対応する BSON 表現に$プレフィックス付きキーが含まれる可能性がある場合は、拡張 JSON 形式を使用しないでください。 DBRefsメカニズムは、この一般ルールの例外です。

mongorestoreを使用してmongodumpによって作成されたデータファイルを読み込む場合、ソース配置と宛先配置の MongoDB バージョンは次のいずれかである必要があります。

  • 同一メジャー バージョン。

  • 同一機能互換バージョン。

たとえば、ダンプの作成元が 4.4 を実行中のMongoDB 配置であった場合、復元先となる MongoDB 配置でも、バージョン 4.4 を実行しているか、FCV を 4.4 に設定している必要があります。

機能の互換性バージョンを変更するには、 setFeatureCompatibilityVersionを参照してください。

注意

mongodump から生成された BSON ファイルは、復元元と同じかそれ以降のバージョンを実行中の MongoDB 配置に復元できます。ただし、新しいバージョンの配置へのファイルの復元は、配置のアップグレード方法としては推奨されていません。配置のアップグレード方法については、アップグレードのドキュメントを参照してください。

この保証は、メタデータ、アーカイブ、または oplog リプレイ ファイルには適用されません。復元元と復元先の配置バージョンが異なる状態でこれらのファイルを復元しようとすると、mongorestore プロセスに失敗したり、サイレント障害が発生したり、メタデータが破損したりする可能性があります。

さらに、データファイルをロードするには、 mongorestoreのバージョンが、データファイルの作成に使用したmongodumpのバージョンと同じであることを確認してください。 たとえば、 mongodumpバージョン100.10.0を使用してダンプを作成した場合、それを復元するにはmongorestoreバージョン100.10.0を使用します。

mongorestore では、新しいデータベースを作成することも、既存のデータベースにデータを追加することもできます。 ただし、 mongorestoreは挿入のみを実行し、更新は実行しません。 既存のデータベースとコレクションにドキュメントを復元し、既存のドキュメントの_idフィールドの値が復元するドキュメントと同じ場合、 mongorestoreはそれらのドキュメントを上書きしません

デフォルトでは、 mongorestoreはランダムな順序でドキュメントを挿入できます。 復元プロセス中にドキュメント順序を維持するには、 --maintainInsertionOrderを使用します。

mongorestore は、データを復元した後、 mongodumpによって記録されたインデックスを再作成します。

注意

featureCompatibilityVersion (fCV)が"4.0"またはそれ以前に設定されている MongoDB インストールの場合、既存のドキュメントのインデックス キーが制限を超えると、インデックスの作成がエラーになります。

この問題を回避するには、 ハッシュされたインデックス を使用するか、代わりに計算された値をインデックス化することを検討してください。 データを復元した後にインデックスの問題を解決するには、 mongodインスタンスのfailIndexKeyTooLongパラメータを false に設定して、ターゲット データベースのデフォルトのインデックス キーの長さ検証を無効にします。

mongorestore は、 system.profileコレクション データを復元しません。

mongorestore は 、FIPS モードを使用するように構成さ れたmongod /mongos への FIPS 準拠の接続を自動的に作成します。

--writeConcernオプションと--uri接続stringオプションの両方で書込み保証(write concern)を指定した場合、 --writeConcernの値が URI stringで指定された書込み保証(write concern)よりも優先されます。

MongoDB 5.0以降では、 mongorestoreを使用して 時系列コレクションを復元できます。 詳細については、「時系列コレクションの復元 」を参照してください。

無料(M0)層および共有(M2M5)層の Atlas クラスターでは、次の制限が適用されます。

  • adminデータベースではmongorestoreを実行できません。 デフォルトでは、 mongorestoreはこのデータベースをスキップします。 --dbオプションを使用して宛先データベースをadminに設定すると、プログラムはエラーを返します。

  • mongorestore プログラムでは、次のオプションは使用できません。

アクセス制御 が有効になっている MongoDB 配置にデータを復元する場合、データに コレクション データを含まずにrestoresystem.profile を オプションなしで実行する 場合 、 ロールはバックアップからデータを復元するために必要な特権を提供します。mongorestore --oplogReplay

バックアップ データにsystem.profileコレクション データが含まれている場合や--oplogReplayオプションを使用してmongorestoreを実行する場合は、追加の権限が必要です。

system.profile

バックアップ データにsystem.profileコレクション データが含まれており、ターゲット データベースにsystem.profileコレクションが含まれていない場合、プログラムでは実際にsystem.profileドキュメントを復元していない場合でも、 mongorestoreはコレクションの作成を試みます。 そのため、ユーザーはデータベースの コレクションに対してcreateCollectionconvertToCapped system.profile} アクションと アクションを実行するために追加の特権を必要とします。

組み込みロールdbAdmindbAdminAnyDatabaseには、いずれも追加の特権が付属します。

--oplogReplay

--oplogReplayを使用して実行するには、任意の リソース に持つ anyActionユーザー定義ロールを作成します。

--oplogReplaymongorestoreを実行する必要があるユーザーにのみ付与します

バックアップおよびリカバリ戦略の一部としてのmongorestoreの使用の概要については、「 MongoDB ツールを使用したバックアップと復元 」を参照してください。

mongodumpmongorestoreをシャーディングされたクラスターのバックアップ戦略として使用するには、「データベース ダンプを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。

シャーディングされたクラスターではバックアップと復元に次のいずれかの連携的なプロセスも利用できます。これにより、書込みを受け入れながらシャード間のアトミック性が保証されます。

戻る

互換性とインストール