mongorestore の動作、アクセス、使用方法
警告
データダンプと復元でのフィールドの $ プレフィックスとの競合
MongoDB 5.0以降、ドキュメントフィールド名の前にドル記号（ $ ）を付けることができます。 ただし、コレクションのオプションにおいてドル記号が先頭に付いているフィールド名では、 mongodumpとmongorestoreは機能しません。
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 に設定して、ターゲット データベースのデフォルトのインデックス キーの長さ検証を無効にします。
system.profileコレクションを除外する
mongorestore は、 system.profileコレクション データを復元しません。
FIPS
mongorestore は 、FIPS モードを使用するように構成さ れたmongod /mongos への FIPS 準拠の接続を自動的に作成します。
書込み保証 (write concern)
--writeConcernオプションと--uri接続stringオプションの両方で書込み保証（write concern）を指定した場合、 --writeConcernの値が URI stringで指定された書込み保証（write concern）よりも優先されます。
時系列コレクション
MongoDB 5.0以降では、 mongorestoreを使用して 時系列コレクションを復元できます。 詳細については、「時系列コレクションの復元 」を参照してください。
Atlas の無料層クラスターと共有層クラスターでの の使用mongorestore
無料（M0）層および共有（M2 と M5）層の Atlas クラスターでは、次の制限が適用されます。
adminデータベースではmongorestoreを実行できません。 デフォルトでは、mongorestoreはこのデータベースをスキップします。--dbオプションを使用して宛先データベースをadminに設定すると、プログラムはエラーを返します。mongorestoreプログラムでは、次のオプションは使用できません。
注意
ターゲット クラスターのロールバック
復元プロセス中にクラスターがロールバックした場合は、復元されたデータまたはインポートされたデータをすべて削除し、プロセスを最初からやり直してください。 詳細については、 ロールバックに関するドキュメント を参照してください。
必要なアクセス権
アクセス制御 が有効になっている MongoDB 配置にデータを復元する場合、データに コレクション データを含まずにrestoresystem.profile を オプションなしで実行する 場合 、 ロールはバックアップからデータを復元するために必要な特権を提供します。mongorestore --oplogReplay。
バックアップ データにsystem.profileコレクション データが含まれている場合や--oplogReplayオプションを使用してmongorestoreを実行する場合は、追加の権限が必要です。
system.profile | バックアップ データに 組み込みロール |
--oplogReplay |
|
バックアップ戦略での使用
スタンドアロン/レプリカセット
バックアップおよびリカバリ戦略の一部としてのmongorestoreの使用の概要については、「 MongoDB ツールを使用したバックアップと復元 」を参照してください。
シャーディングされたクラスター
mongodumpとmongorestoreをシャーディングされたクラスターのバックアップ戦略として使用するには、「データベース ダンプを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。
シャーディングされたクラスターではバックアップと復元に次のいずれかの連携的なプロセスも利用できます。これにより、書込みを受け入れながらシャード間のアトミック性が保証されます。