Database Migration Service makes it easier for you to migrate your data to Google Cloud. Database Migration Service helps you lift and shift your MySQL, PostgreSQL, and SQL Server workloads into Cloud SQL and AlloyDB for PostgreSQL, and lift and modernize your Oracle workloads into Cloud SQL for PostgreSQL.
Database Migration Service streamlines networking workflow, manages the initial snapshot and ongoing replication, and provides a status of the migration operation.
For businesses that are migrating their workloads to the cloud, there can be considerable friction in moving their on-premises and other cloud-based databases to Google Cloud. This can slow their ability to take advantage of the capabilities that Google Cloud has to offer.
Migration is a process whereby data and metadata is moved from a source database to a destination database. After the migration is completed, the destination database becomes the primary database, dependent applications should read and write to it, and the source database can be shut down.
Continuous (sometimes referred to as ongoing or online) migration is a continuous flow of changes from your source to your destination that follows an initial full dump and load. In the case of a migration, when the time comes to switch to use the destination for reads and writes, finalize the migration. As a result, replication is finalized between the source and the destination, and the destination Cloud SQL instance or AlloyDB cluster is ready to be used as a stand-alone primary instance. Doing the switch when the source and destination are in sync gives you minimal downtime.
Behind the scenes
For homogenous, like-to-like migrations, such as MySQL to Cloud SQL for MySQL, PostgreSQL to Cloud SQL for PostgreSQL or AlloyDB for PostgreSQL, and SQL Server to Cloud SQL for SQL Server, the migration leverages the primary-replica relationships enabled by native tooling for MySQL, PostgreSQL, and SQL Server. This means:
When setting up a migration, a replica instance appears in the Cloud SQL instance or AlloyDB clusters list, attached to the source that was set up.
When performing a promotion, the replica disconnects from the source and is modified to read/write mode. It can then serve as a primary for other replicas, and other options can be changed such as the HA setting (Cloud SQL only).
For heterogeneous migrations where the source and destination are different, such as Oracle to Cloud SQL for PostgreSQL, the migration leverages CDC-based replication.
The migration capabilities of Database Migration Service enable a variety of use cases:
Lift and shift migration to a managed service
As part of an organization's move to Google Cloud, there's an opportunity to move from VM-based self-hosted databases to managed database cloud services. This allows teams to get out of the business of managing infrastructure, and enjoy the high availability, disaster recovery, and performance of running databases on managed services.
Multi-cloud continuous replication
Much like the read replicas across regions, if data exists in another cloud provider, a migration job can be set up which continuously replicates the database into Google Cloud for multi-cloud read-availability. Database Migration Service doesn't support a dual-write scenario, that is writing to and reading from both the source and destination.
There are three main elements that comprise Database Migration Service:
Connection profiles represent connectivity information to the specific source that will be used in a migration job.
Conversion workspaces help you convert your schema and code objects from the source database to a format that's compatible with your destination instance.
Migration jobs represent a source connection profile and destination Cloud SQL instance or AlloyDB cluster pair, along with migration-specific settings.