This document describes an architecture to migrate from a self-managed MongoDB replica set that contains databases to a fully managed cluster in MongoDB Atlas by using MongoDB's Atlas Live Migration Service.
This document is intended for database architects, database administrators, and database engineers who are interested in a fully hosted MongoDB service, or who are responsible for migrating MongoDB databases in a MongoDB replica set to a MongoDB Atlas cluster.
Architecture
The following diagram shows the migration architecture:
In the diagram, an arrow represents the data migration path from the source MongoDB replica set running on Compute Engine to the target cluster running in MongoDB Atlas on Google Cloud.
The deployment architecture contains the following components:
- Source database: a self-managed MongoDB replica set running on three Compute Engine instances.
- Target database: a fully managed MongoDB Atlas cluster.
- Migration service: an Atlas Live Migration configuration to migrate data from the source to the target.
Although this architecture uses a self-managed MongoDB replica set on Compute Engine instances, you can also deploy a source MongoDB replica set in an on-premises data center or another cloud environment.
Design alternatives
The following sections present potential design alternatives for this architecture.
Sharded MongoDB clusters
The architecture in this document uses a MongoDB replica set as the source. Migrating a sharded MongoDB cluster to MongoDB Atlas isn't included in this architecture. The architectural difference between a MongoDB replica set and a sharded MongoDB cluster is explained in Stack Exchange: Database Administrators.
Atlas mongomirror utility
The architecture in this document uses
Atlas Live Migration,
not the
Atlas mongomirror
utility. The mongomirror utility requires the installation of an agent on the
source MongoDB environment and it operates at a lower level of abstraction.
Integration technology
The migration setup in this architecture is a homogeneous migration with a copy semantics. Data isn't transformed during the migration, and no database consolidation or data resharding occurs. You can implement functionality beyond copy semantics by using integration technology such as Striim.
Design considerations
The following guidelines can help you to develop an architecture that meets your organization's requirements for reliability, cost, and performance.
Reliability
The migration in this architecture is a one-way migration from a source MongoDB replica set to a target MongoDB Atlas cluster. After you complete a cut over from the source MongoDB replica set to the target cluster, the source databases aren't kept up to date with changes to the target cluster. Therefore, if you implement this architecture in a production environment, you can't switch your applications to up-to-date source databases in a fallback. For more information on fallback processes, see Database migration: Concepts and principles (Part 2).
Cost optimization
Deployment of this architecture uses the following billable components of Google Cloud:
To deploy this architecture, you can't use the MongoDB Atlas free tier. The available machine types in the free tier don't support Atlas Live Migration. The minimum required machine type (M10 at the time of this writing) has an hourly service cost in MongoDB Atlas. To generate a price estimate, go to MongoDB Atlas Pricing and review the Google Cloud pricing information. If you implement this migration in production, we recommend that you use the regular hosted version of MongoDB Atlas.
Performance
Atlas Live Migration supports a zero-downtime database migration approach. During the migration from the source MongoDB replica set, your applications can still access the source databases without impact. After the initial load, Atlas Live Migration migrates changes as they occur after the migration starts.
After the initial dataset is migrated, you perform the cut over from the source database to the target cluster. As part of the cutover process, you suspend write access to the source database. You then wait for Atlas Live Migration to capture the remaining changes and apply them to the target database. After the changes are applied, you can execute the cut over in Atlas Live Migration and stop the source database.
After all data is migrated, Atlas Live Migration notifies you on the progress status line in the user interface. At this point, the data migration is complete and the application systems can begin accessing the target cluster as the new system of record.
Deployment
To deploy this architecture, see Deploy Atlas Live Migration to migrate MongoDB to MongoDB Atlas.
What's next
- Check out Google Cloud data migration content.
- For more reference architectures, diagrams, and best practices, explore the Cloud Architecture Center.