Create a migration job

The following steps are required for setting up a migration job:

  1. Provide settings for the migration job and performing prerequisite steps.

  2. Define the source connection profile.

  3. Create the destination Cloud SQL instance.

  4. Setup and test connectivity between the source and destination.

  5. Review the migration job settings and create the migration job.

Prerequisite steps and settings

  1. Go to the Database Migration Service jobs page in the Google Cloud Platform Console.

    Go to the Database Migration Service Jobs Page

  2. Click Create Migration Job at the top of the page.

  3. Provide a name for the migration job. Choose a friendly name that will help you identify the migration job. Do not include sensitive or personally identifiable information in the job name.

  4. Provide an ID for the migration job. This must be a unique string, comprised of lower-case letters, digits, and hyphens. There's no need to include the project ID; this is done automatically where appropriate (for example, in the log files).

  5. Select the source database engine.

    The destination database engine is automatically selected and can't be modified since Database Migration Service only supports homogeneous migration jobs at this time.

  6. Select the destination region for your migration. This is where the Cloud SQL instance will be created, and should be selected based on the location of the services that need your data, such as Compute Engine instances and App Engine apps, and other services.

    Once chosen, this selection can't be changed.

  7. Specify the migration job type: One-time (snapshot only) or Continuous (snapshot + ongoing changes).

  8. The required prerequisites will be automatically generated to reflect how the environment will need to be prepared for a successful migration job. It's best to perform them at this step, but they can be performed at any time before the migration job is tested or started for a successful test/start. Then click Continue. The setup can be tested in the last step.

Define the source connection profile

  1. Choose from a list of existing connection profiles, or create one by clicking Create a connection profile at the bottom of the connection profiles dropdown.

  2. If creating a connection profile, perform the same steps as in the Create a connection profile experience.

    The connection profile engine will already be defined based on the selection on the previous page.

  1. Click Continue.

Create the destination Cloud SQL instance

  1. Provide an instance ID for the Cloud SQL instance, or use the generated ID.

    Do not include sensitive or personally identifiable information in the instance name; it is externally visible.

    There is no need to include the project ID in the instance name. This is done automatically where appropriate (for example, in the log files).

  2. Choose the database version for the destination instance from the list of supported Cloud SQL versions for the specified database engine.

  3. The instance will be created in the region that was selected in the prerequisites step. Select a zone within that region, or leave set to "Any" for the Database Migration Service to select one automatically. The zone can be changed at any time.

  4. Select the machine type for the Cloud SQL instance.

  5. Define the disk type and storage size for the Cloud SQL instance.

    For more information and disk type and storage size, see Instance settings (MySQL) or Instance settings (PostgreSQL).

  6. (Optional) Configure the Cloud SQL instance to accept connections from other networks (specific IP addresses or a range of addresses) by adding authorized addresses to the instance. If this information is not readily available at creation time, it can always be changed later in the Cloud SQL instance page.

    For more information on configuring public access to Cloud SQL instance, see Configuring public IP connectivity.

  7. (Optional) Add any necessary database flags.

    For more information about supported database flags, see Configuring database flags (MySQL) or Configuring database flags (PostgreSQL).

  8. (Optional) Specify any labels specific to the Cloud SQL instance.

  9. Click Create & Continue to create the new instance. This may take several minutes to complete.

Set up connectivity

After the source and destination have been established, because they're actually a primary and replica pair behind the scenes, connectivity between them needs to be established.

  1. Choose the networking method to use to establish connectivity between the source and the destination. Based on the selected connectivity method, the UI will display relevant information and instructions required to establish connectivity.

    • Reverse SSH Tunnel

      Follow the steps below to set up a reverse SSH tunnel between the source database and Cloud SQL. Upon providing some parameters, we'll generate a set of gcloud commands that will need to be executed on a machine which has connectivity to both the source database and to Google Cloud.

      1. Select the VPC that will be used to establish connectivity between the source database and the Cloud SQL instance. Typically this is the VPC where the application accessing the new Cloud SQL database will run.

      2. If a Compute Engine VM instance has already been set up in your project, it can be reused.

        1. Choose the Compute Engine VM instance from the list.

        2. Provide a free port for the SSH tunnel to connect to.

      3. If such an instance does not exist, select Create a Compute Engine VM Instance and the generated script will create one for this purpose.

        1. Provide a name for the VM instance.

        2. Select a machine type for the VM.

        3. Select a VPC network for the VM.

      4. Click Copy Script to view the generated script. Run the script in the gcloud command-line tool on a machine that has access to the source database as well as to Google Cloud. The script will perform the following operations:

        • Create a Compute Engine VM instance in the VPC and configure it as a SSH tunnel bastion server (if using an existing instance above, this part of the script will be commented out).

        • Establish a secure SSH connection between the source database and the VPC.

      5. Update the VM IP and SSH port that were generated by the script.

      6. Click Configure & Continue to update the replica instance with the IP of the selected or created VM, configure (or verify) VPC peering between Cloud SQL and the VPC specified above, and to turn off the public IP setting on the instance. Connectivity can be tested on the next page.

    • IP Whitelisting

      IP whitelisting requires the database and/or firewall to be opened to incoming connections from the Cloud SQL instance.

      1. Copy the Cloud SQL instance's public IP displayed in the UI, and use it to configure the network firewall for the source database server to accept connections from this IP address.

        The IP will only come up once the instance has been created, which can take a few minutes.

      2. Return to the migration job creation experience once this is done, and then click Configure & Continue. Connectivity can be texted on the next page.

    • VPC Network Peering

      If the source database is hosted in another VPC in Google Cloud, then the easiest way to connect the source database with the Cloud SQL instance is using VPC Peering.

      1. Select the VPC network where the source database is located.

      2. Click Configure & Continue to setup Private Services Access (VPC peering) between the VPC and Google Cloud SQL.

Test and create the migration job

On this final step, review the summary of the source, destination, and migration job settings, and test the validity of the migration job setup. If any issues are encountered, settings on the previous page can be modified (note: not all settings are editable).

  1. Click Test Migration Job to verify that the source has been configured based on the prerequisites, that the source and destination instance are able to communicate with each other, and that the migration job is valid and the source and destination versions are compatible.

    If the test fails it will indicate which part of the process had an issue, necessary changes can be made, and then re-tested on the same page.

    Navigate to the part of the flow in question to correct the issue, and then retest.

    The migration job can be created even if the test fails, but once the job is started may fail at some point during the run.

  2. Specify whether to Create the migration job without immediately executing it, or Create & Start to create the migration job and start it immediately.

    If the job is not started at create time, it can be started from the migration job page by clicking Start.

    Regardless of when the migration job starts, your organization will be charged for the existence of the destination instance.

  3. The migration job is added to the migration jobs list and can be viewed directly.

Saving an unfinished migration job as a draft

Migration job creation can be stopped and existing progress saved by clicking Save & Exit, then picked back up at a later time. Once clicked, all the data that was populated until that point is saved in a draft migration job, and the migration job appears under the Drafts tab of the migration job list.

To finish creating a migration job, navigate to the drafts tab and click on the job. It will resume the creation flow where it was left off. The job will be a draft until Create or Create & Start are clicked in the last step.