Database Migration Service provides a lot of flexibility for your homogeneous MySQL migrations to Cloud SQL for MySQL. Depending on your database size, downtime requirements, and networking setup, there are different workflows available to best meet your scenario. Detailed networking and other prerequisites are described in each migration guide.
The following table provides an overview of each migration flow:
| Migration workflow | Best suited for | Description |
|---|---|---|
| Migrate to a new destination instance | Standard migrations where you want Database Migration Service to create and configure the destination Cloud SQL instance for you. | Database Migration Service automatically provisions a new destination Cloud SQL instance using configuration options you select, and migrates your source schemas and data. Covers both continuous and one-time migrations using automatic or manual mysqldump files. |
| Migrate to an existing destination instance | Scenarios where you need to pre-create and customize your destination Cloud SQL instance outside of Database Migration Service (for example, by using Terraform, custom database flags, existing read replicas, or Private Service Connect interfaces). | Migrate data into a standalone Cloud SQL instance that you have already created and configured before setting up the migration job. Covers both continuous and one-time migrations. |
| Migrate by using a Percona XtraBackup physical file | Very large, multi-terabyte self-hosted databases where a logical mysqldump export would be too slow. |
Perform a physical migration by creating physical backup files with the third-party Percona XtraBackup utility and uploading them to a Cloud Storage bucket. |