Is it possible to specify an existing CloudSQL instance as the destination for the database migration service in GCP?

According the GCP guides, setting up a database migration involves creating a migration job in the console using the wizard [1]. The wizard creates a new CloudSQL instance, but I would like to specify an existing instance such that we can manage the destination instance through version control (e.g. Terraform)

Is it possible to specify an existing CloudSQL instance as the destination for the database migration service in GCP? If so, how?

If not, another solution for version control is to create the migration job (and possibly the destination instance) through a script running gcloud CLI/API commands.

From the API guides for database migration [2], it seems we need to specify a destination connection profile.

destination-connection-profile-id: the destination connection profile ID

This is reflected in the gcloud CLI docs [3]

--destination=DESTINATION
ID of the connection_profile or fully qualified identifier for the connection_profile. To set the connection_profile attribute:
provide the argument --destination on the command line.

Does this mean that in order to create the migration job through the CLI, I will need to manually create a destination CloudSQL instance AND a connection profile for that instance as well? If so, what privileges does the connection user need? Or does the "gcloud database-migration migration-jobs create" command automatically create a destination instance?

Otherwise, open to suggestions as to what the --destination flag could mean.

[1] https://cloud.google.com/database-migration/docs/mysql/create-migration-job

[2] https://cloud.google.com/database-migration/docs/mysql/api-migration-jobs#create_a_continuous_migration_job_with_reverse_ssh_connectivity

[3] https://cloud.google.com/sdk/gcloud/reference/database-migration/migration-jobs/create

You asked the below questions :

• Is it possible to specify an existing CloudSQL instance as the destination for the database migration service in GCP?

• Does the "gcloud database-migration migration-jobs create" command automatically create a destination instance?

• Does this mean that to create the migration job through the CLI, I will need to manually create a destination CloudSQL instance AND a connection profile for that instance as well?

• Answer for the 1st Question : No it is not possible. My take on it is that Database Migration Service will always create a new instance. When using the wizard/Console to perform the migration service, when you click on create a destination it automatically creates a new Cloud SQL destination instance for you. When using the API, you are expected to create the destination profile. See this link where it is mentioned "Create a connection profile for Cloud SQL for MySQL destination ... The Database Migration Service for MySQL uses information in this request to create a new Cloud SQL for MySQL instance."

  I think it would be rather tricky to make the service work reliably if we didn't create a new instance every time. That said, I think the service as it exists now is designed to be able to support more options in the future, so it might happen, but I don't see any evidence that it can be done now.

• Answer for the 2nd Question : No it does not create it. When you run the “gcloud database-migration migration-jobs create” command, you have to have the source and destination connection profiles created and given as parameters to this command as per the documentation.

• Answer for 3rd Question : No. To do this using gcloud (or the API) you need to create the source and destination connection profiles, then the migration job, and the destination instance will be created for you according to the information provided here.

Your concern with how to manage this with terraform is probably valid and perhaps interesting, but terraform is a third party product, and Google doesn't build the APIs with its model in mind. Perhaps you could create an issue with this and someone from that end can look into it.

It is unfortunate that google chose to implement this solution in this way. At first I thought it was more similar to the AWS approach where DMS sets up an intermediary database instance to migrate / manipulate the data before replicating to the target instance / DB engine.

Hoping they evolve this over time, but for now it does not seem like a fully complete product