Navigation

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:

Source Replica Set
MongoDB Version
Destination Atlas Replica Set
MongoDB Version
2.6 3.2, 3.4, 3.6, 4.0
3.0 3.2, 3.4, 3.6, 4.0
3.2 3.2, 3.4, 3.6, 4.0
3.4 3.4, 3.6, 4.0
3.6 3.6, 4.0
4.0 4.0

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. Project Owners can upgrade their MongoDB 3.2 clusters at any time before then.

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.

Source Sharded Cluster
MongoDB Version
Destination Sharded Cluster
MongoDB Version
3.4 3.4
3.6 3.6
4.0 4.0

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.

Source Replica Set
MongoDB Version
Destination Atlas Replica Set
MongoDB Version
2.6 3.2, 3.4, 3.6, 4.0
3.0 3.2, 3.4, 3.6, 4.0
3.2 3.2, 3.4, 3.6, 4.0
3.4 3.4, 3.6, 4.0
3.6 3.6, 4.0
4.0 4.0

Important

mongomirror does not import user/role data or copy the config database.

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. Project Owners can upgrade their MongoDB 3.2 clusters at any time before then.

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 system.profile collection data.

See the tutorial Seed with mongorestore.

mongoimport

To load data from a JSON or a CSV file into an Atlas cluster.

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.

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:

  • Stop or start the sharded cluster balancer.
  • Read all databases and collections on the host.
  • Read the oplog on the host.

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 mongodump and mongorestore. See Seed with mongorestore and Backup Sharded Cluster with Database Dumps.

A “single shardsharded 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 mongodump and mongorestore. See Seed with mongorestore.

A shared multi-tenant cluster, or a cluster where you have no oplog access.

Use mongodump and mongorestore. See Seed with mongorestore.

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.