大規模な `mongodump`、続いて` mongorestore`
かなり大規模な（〜240GB）Mongoデータベースがあり、遅いネットワークを介して新しいサーバーに転送する必要があります。
伝統的に、これらの状況では、mongodumpの後にmongorestoreが続くと、よりもはるかに高速であることがわかりましたdb.cloneCollection()メソッド。しかし、私は今日、すべてのデータ転送を実行してからすべての挿入を実行するため、完全なmongodumpの後にmongorestoreを実行するのは少し無駄であると思いました。
利用可能なデータを新しいデータベースに挿入すると同時に（mongodumpステップ）、古いモンゴ（mongorestoreステップ）からデータを転送したいと思います。
MongoDBでのダンプと挿入のプロセスを並列化する方法を知っている人はいますか？（そして、これは実際に高速でしょうか？）
まず、パイプを使用できます
mongodump -h sourceHost -d yourDatabase … | mongorestore -h targetHost -d yourDatabase …
これにより、読み込まれた各ドキュメントがtargetHostにほぼ瞬時に復元されるため、時間を短縮できます。
ただし、ネットワーク障害などの理由で手順が中止された場合に問題が発生する可能性があるという欠点があります。並列化については、コレクションごとに上記を実行できますが、制限要因はIOである可能性が最も高いため、パフォーマンスが向上することはないと思います。
古いサーバー、新しいサーバー、アービターで構成される一時的な レプリカセット を作成します。最初の同期はかなり高速で、ネットワークの問題が発生した場合でも、同期メカニズムはすべてが正常であることを確認します。最初の同期が完了すると、古いサーバー step down がプライマリになり、新しいサーバーを replSetNameオプション なしで再起動して、再びスタンドアロンにします。これで、新しいサーバーに接続でき、すべてのデータが転送されます。
利点は、これが最小限のダウンタイムで稼働し、出席しないことです。レプリカセットを初期化した後も、アプリケーションは古いサーバーを使用でき、新しいデータも自動的に新しいサーバーに転送されます。したがって、あなたはそれ以外に座る必要はありません。そして、プロセスはタイムゾーンに関係なく、午前3時に終了する可能性が高いことを私たちは皆知っています。 ;）Any time最初の同期が完了した後（数時間または数日後でも）、新しいサーバーをスタンドアロンにして、アプリケーションの接続文字列を新しいサーバーに変更できます。適切に計画されている場合、これは2〜3分程度です。
編集
ただし、この方法には欠点があります。1つのリリースから1つ上のリリースにのみアップグレードできます。したがって、2.4（この記事を書いている時点での考古学）から3.4（Edgeをカット）に移行する場合は、このプロセスを複数回繰り返す必要があります。
- 2.4から2.6へ
- 2.6から3.0へ
- 3.0から3.2へ
- 3.2から3.4へ
受け入れられた答えは、いくつかのパラメーターが不足していたため、私にはうまくいきませんでした：
mongodump --Host source:port --db databasename --gzip --archive | \
mongorestore --drop -vvvvvv -h target:port --db databasename --gzip --archive
--gzipこれは省略可能であり、おそらく省略すべきです。これは、（コマンドを実行しているマシンのバス上の）パイプ内のデータのみを圧縮し、データベースとコマンドを実行しているマシンの間の（有線経由の）データは圧縮しないためです。多分それは単に不必要な計算オーバーヘッドを引き起こすだけです。私が間違っていなければ、MongoDBはとにかく（サーバーとドライバーの間で）ネットワーク経由でデータを圧縮します。
--archiveファイル名を指定しない場合、ファイル名なしでstdoutに書き込み、stdinからそれぞれ読み取ります
--dropは、ターゲットデータベースを完全に置き換えます。