Import Data into Cluster¶
Data Import Tools¶
You can bring data from existing MongoDB deployments or JSON/CSV files into Atlas using one of the following:
| Tools | Use Case | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Live Migrate a replica set. | To migrate from a MongoDB replica set into an Atlas replica set cluster. Atlas replica set live migration supports the following migration paths:
3.2 End of Life MongoDB Server 3.2 is planned for End of Life on September 2018. Atlas deprecated support for deploying clusters with MongoDB 3.2 in March, 2018. Atlas will automatically upgrade any clusters running MongoDB 3.2
to MongoDB 3.4 in September 2018.
See I have a cluster running MongoDB 3.2. How does the upcoming End of Life affect me? for guidance on how to manage Atlas clusters currently running MongoDB 3.2. See replica set live migration documentation for complete prerequisites and instructions. |
||||||||||||||
| Live Migrate a sharded cluster. | To migrate from a MongoDB sharded cluster to an Atlas sharded cluster. Atlas global clusters are not valid destinations for Live Migration.
See sharded cluster live migration documentation for complete prerequisites and instructions. |
||||||||||||||
| Live Migrate a standalone MongoDB node. | Convert the standalone MongoDB node to a single-node replica set and then use the Live Migration service. | ||||||||||||||
| mongomirror | To migrate from a MongoDB replica set into an Atlas cluster. mongomirror does not require you to shut down your existing replica set or applications.
Important mongomirror does not import
user/role data or copy the See the tutorial Migrate with mongomirror. 3.2 End of Life MongoDB Server 3.2 is planned for End of Life on September 2018. Atlas deprecated support for deploying clusters with MongoDB 3.2 in March, 2018. Atlas will automatically upgrade any clusters running MongoDB 3.2
to MongoDB 3.4 in September 2018.
See I have a cluster running MongoDB 3.2. How does the upcoming End of Life affect me? for guidance on how to manage Atlas clusters currently running MongoDB 3.2. |
||||||||||||||
| mongorestore | To seed an Atlas cluster with a BSON dump backup of an existing MongoDB deployment. Important mongorestore does not restore
See the tutorial Seed with mongorestore. |
||||||||||||||
| mongoimport | To load data from a Important
See the tutorial Load File with mongoimport. |
You can also restore from an Atlas cluster backup data to another Atlas cluster. For information, see Restore a Cluster from a Continuous Backup Snapshot or Point in Time.
Import Strategies for Common Cluster Configurations¶
The following table covers the best import strategy for common cluster configurations.
Note
If have a source cluster with authentication and you wish to use an
import strategy which includes using mongorestore with the --oplogReplay option, you must delete the admin
directory from the dump directory created by mongodump. The admin directory contains database user
information which you cannot add to an Atlas cluster with
mongorestore.
| Cluster Configuration | Import Strategy |
|---|---|
| A replica set. | Use Live Migrate. You must provide the hostname of the primary to the Live Migrate tool. If the cluster is running a MongoDB version earlier than 2.6, you must first upgrade it to at least MongoDB 2.6. You must have access to the primary node’s oplog. If the cluster runs with authentication, you must have credentials that provide read access to the primary and its oplog. See Pre-Migration Validation for the full list of migration requirements. |
| A sharded cluster with multiple shards. | If your application can tolerate a short period of downtime, use Live Migrate. The source cluster must run MongoDB 3.4, or 3.6. If the sharded cluster is not running MongoDB 3.4 or 3.6, you must upgrade it to MongoDB 3.4 or 3.6. If the source cluster enforces authentication, specify a user to Atlas that exists on every shard and the config server replica set. The user must have permission to:
See Pre-Migration Validation for the full list of migration requirements. If near-continuous uptime is a requirement, please contact MongoDB. From the Atlas UI, click Support. Fill out a Support ticket, noting your uptime requirements and cluster configuration in the More details text entry. If some downtime is OK and your sharded cluster does not run a
supported MongoDB version, you may use |
A “single shard” sharded cluster in Compose. This is
the standard configuration for new MongoDB deployments in Compose. |
Use Live Migrate. You must enable the oplog proxy. You must specify the hostname and credentials for the oplog proxy when connecting from Live Migrate. See Pre-Migration Validation for the full list of migration requirements. |
| A standalone MongoDB node. | Convert the standalone MongoDB node to a single-node replica set and then use the Live Migration service. If the standalone is running a MongoDB version earlier than 2.6, you must first upgrade it to at least MongoDB 2.6. If you are running with authentication enabled, you must have credentials that provide read access to the primary and its oplog. If you cannot convert the standalone to a replica set, use
|
| A shared multi-tenant cluster, or a cluster where you have no oplog access. | Use If you are running with authentication enabled, you must have credentials that provide read access to the primary. |
Atlas has built-in support for scaling an M0
Free Tier cluster to an M10+ paid cluster. Alternatively, use
mongodump and mongorestore to copy data from an M0
Free Tier cluster to an M10+ cluster. See Seed with mongorestore.