Stay organized with collections Save and categorize content based on your preferences.
You can migrate your MySQL databases to Cloud SQL by using physical database backup files created with the Percona XtraBackup for MySQL utility. Migrating with physical backup files offers increased data restoration speeds over migrations that use logical backup files. This makes them a great choice for moving big databases that contain multiple terabytes of data.
This migration flow involves the following tasks:
Backing up your source MySQL instance and preparing the physical backup files by using the Percona XtraBackup for MySQL utility.
Uploading your backup files to a Cloud Storage bucket.
Creating and running the migration job in Database Migration Service.
Depending on your scenario, you can create the destination instance on your own, or have Database Migration Service create the destination instance for you as a part of the migration job creation flow. For more information, see the Configure and run the migration job step.
Promoting the migration job after the data is fully migrated.
This guide describes migration scenarios for environments where you can ensure network connectivity between your source and destination database instances.
It is possible to perform a test migration where Database Migration Service doesn't connect to your source instance. Instead, Database Migration Service only reads the backup files you upload to the Cloud Storage bucket and replicates their contents to the Cloud SQL for MySQL destination. A migration flow that doesn't use network connectivity isn't recommended for production migrations, as Database Migration Service can't fully perform data validation.
If you want to try to perform an offline migration job, adjust the procedures in the following way:
When you create the source connection profile, use a sample IP address, port, username and password. For example:
0.0.0.0
1234
test-user
When you create the migration job:
This section lists limitations for the migrations that use Percona XtraBackup physical files:
Migrating to MySQL 5.6 or 8.4 with a physical backup file is not supported. See Known limitations.
Cross-version considerations:
You can't migrate from MySQL 5.7 to MySQL 8.0.
Migration is not supported to earlier database major or minor versions. For example, you can't migrate from MySQL 8.0 to 5.7 or from MySQL 8.0.36 to 8.0.16.
Cross-architecture considerations: Cloud SQL supports ARM architecture. You can only migrate databases between machines of the same architecture type. For example, if your database is hosted on an ARM64 machine, then you must migrate to an ARM64 machine.
The disk size of the destination database must be equal to or greater than the source database size. For more information, see MySQL machine types for your Cloud SQL edition.
You must use Percona XtraBackup to backup up your data to the Cloud Storage bucket. Other backup utilities are not supported.
Database migration from a Percona XtraBackup physical file is only supported for on-premises or self-managed VM MySQL databases. Migration from Amazon Aurora or MySQL on Amazon RDS databases is not supported.
You can only migrate from a full backup. Other backup types, such as incremental or partial backups, are not supported.
Database migration does not include database users or privileges.
You must set the binary log format to ROW
. If you configure the binary log to any other format, such as STATEMENT
or MIXED
, then replication might fail.
Any database with a table larger than 5 TB is not supported.
Cloud Storage limits the size of a file that you can upload to a bucket to 5 TB. If your Percona XtraBackup physical file exceeds 5 TB, then you must split the backup file into smaller files.
Make sure you upload the backup files to a dedicated Cloud Storage folder that doesn't contain any other files.
You must configure the innodb_data_file_path
parameter with only one data file that uses the default data filename ibdata1
. If your database is configured with two data files or has a data file with a different name, then you can't migrate the database using a Percona XtraBackup physical file. For example, a database configured with innodb_data_file_path=ibdata01:50M:autoextend
is not supported for the migration.
The innodb_page_size
parameter on your source instance must be configured with the default value 16384
.
You can't migrate any plugins from your external database.
For homogenous migrations to Cloud SQL, Database Migration Service is offered at no additional charge. However, Cloud SQL and Cloud Storage pricing applies for network charges as well as Cloud SQL and Cloud Storage entities created for migration purposes.
In this document, you use the following billable components of Google Cloud:
To generate a cost estimate based on your projected usage, use the pricing calculator.
New Google Cloud users might be eligible for a
free trial.
Before you beginIn the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Enable the Database Migration Service, Compute Engine, and Cloud SQL Admin APIs.
To get the permissions that you need to perform homogeneous MySQL migrations by using physical backup files, ask your administrator to grant you the following IAM roles on your project:
roles/datamigration.admin
)roles/storage.objectViewer
)roles/cloudsql.editor
)For more information about granting roles, see Manage access to projects, folders, and organizations.
These predefined roles contain the permissions required to perform homogeneous MySQL migrations by using physical backup files. To see the exact permissions that are required, expand the Required permissions section:
Required permissionsThe following permissions are required to perform homogeneous MySQL migrations by using physical backup files:
datamigration.*
resourcemanager.projects.get
resourcemanager.projects.list
cloudsql.instances.create
cloudsql.instances.get
cloudsql.instances.list
compute.machineTypes.list
compute.machineTypes.get
compute.projects.get
storage.buckets.create
storage.buckets.list
You might also be able to get these permissions with custom roles or other predefined roles.
Step 1. Consider your network connectivity requirementsThere are different networking methods you can use to configure connectivity between your source and the Cloud SQL destination instances. Depending on which method you use, there might be additional steps you need to perform during the migration process.
Consider which connectivity method is right for your scenario before you proceed to the next steps, as your choice might impact the settings you need to use. For more information, see Configure connectivity.
Step 2. Prepare your source dataTo prepare your data for migration, perform the following steps:
Before using any of the command data below, make the following replacements:
BACKUP_ADMIN
privilege on the source instance.xtrabackup --backup \ --target-dir=TARGET_DIR \ --user=USERNAME \ --password=PASSWORD
--prepare
command to ensure file consistency. Run the following command:
xtrabackup --prepare --target-dir=TARGET_DIR
Database Migration Service is a fully-regional product, meaning that all entities related to your migration (source and destination connection profiles, migration jobs, destination databases, storage buckets for backup files) must be saved in a single region.
To create a source connection profile, follow these steps:
If the source database is hosted in Google Cloud, or if a reverse SSH tunnel is used to connect the destination database to the source database, then specify the private (internal) IP address for the source database. This address will be accessible by the Cloud SQL destination. For more information, see Configure connectivity using VPC peering.
For other connectivity methods, such as IP allowlist, provide the public IP address.
Optional: If the connection is made over a public network (by using IP allowlists), then we recommend using SSL/TLS encryption for the connection between the source and destination databases.
There are three options for the SSL/TLS configuration that you can select from the Secure your connection section of the page:
Server-only authentication: When the Cloud SQL destination instance connects to the source database, the instance authenticates the source, ensuring that the instance is connecting to the correct host securely. This prevents person-in-the-middle attacks. For server-only authentication, the source doesn't authenticate the instance.
To use server-only authentication, you must provide the x509 PEM-encoded certificate of the certificate authority (CA) that signed the external server's certificate.
For more information about creating certificates and keys for your external server, see Creating SSL and RSA Certificates and Keys using MySQL.Server-client authentication provides the strongest security. However, if you don't want to provide the client certificate and private key when you create the Cloud SQL destination instance, you can still use server-only authentication.
To use server-client authentication, you must provide the following items when you create the destination connection profile:
If you're having trouble uploading the key, then select the Enter manually option, and copy and paste the key into the text area.
This sample uses the optional --no-async
flag so that all operations are performed synchronously. This means that some commands might take a while to complete. You can skip the --no-async
flag to run commands asynchronously. If you do, you need to use the gcloud database-migration operations describe
command to verify if your operation is successful.
Before using any of the command data below, make the following replacements:
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration connection-profiles \ create mysql CONNECTION_PROFILE_ID \ --no-async \ --region=REGION \ --host=HOST_IP_ADDRESS \ --port=PORT_NUMBER \ --username=USERNAME \ --password=PASSWORD \ --display-name=CONNECTION_PROFILE_NAMEWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration connection-profiles ` create mysql CONNECTION_PROFILE_ID ` --no-async ` --region=REGION ` --host=HOST_IP_ADDRESS ` --port=PORT_NUMBER ` --username=USERNAME ` --password=PASSWORD ` --display-name=CONNECTION_PROFILE_NAMEWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration connection-profiles ^ create mysql CONNECTION_PROFILE_ID ^ --no-async ^ --region=REGION ^ --host=HOST_IP_ADDRESS ^ --port=PORT_NUMBER ^ --username=USERNAME ^ --password=PASSWORD ^ --display-name=CONNECTION_PROFILE_NAME
You should receive a response similar to the following:
Waiting for connection profile [CONNECTION_PROFILE_ID] to be created with [OPERATION_ID] Waiting for operation [OPERATION_ID] to complete...done. Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]
When you migrate with Percona XtraBackup, you might want to create the Cloud SQL destination instance on your own, or have Database Migration Service create it for you. For more information, see Migration job creation overview.
Each of these approaches requires you to follow a slightly different set of procedures. Use the drop-down menu to show the procedures relevant for your scenario:
The migration job configuration wizard page opens. This wizard contains multiple panels that walk you through each configuration step.
You can pause the creation of a migration job at any point by clicking SAVE & EXIT. All of the data that you enter up to that point is saved in a draft migration job. You can finish your draft migration job later.
This is a human-readable name for your migration job. This value is displayed in the Google Cloud console.
This is a machine-readable identifier for your migration job. You use this value to work with migration jobs by using Database Migration Service Google Cloud CLI commands or API.
The Destination database engine field is populated automatically and can't be changed.
Database Migration Service is a fully-regional product, meaning all entities related to your migration (source and destination connection profiles, migration jobs, destination databases) must be saved in a single region. Select the region based on the location of the services that need your data, such as Compute Engine instances or App Engine apps, and other services. After you choose the destination region, this selection can't be changed.
Important: If you plan to use the Cloud SQL for MySQL Enterprise Plus edition, make sure your region is supported for that edition. See Cloud SQL for MySQL Enterprise Plus edition region support.Don't include sensitive or personally identifiable information in the identifier. There's no need to include the project ID in the instance name. This is done automatically where appropriate (for example, in the log files).
root
administrator account in the instance.
You can either enter the password manually or click Generate to have Database Migration Service create one for you automatically.
Click Show minor versions to view all minor versions. Learn more about cross-version migration support.
Cloud SQL for MySQL editions come with different sets of features, available machine types, and pricing. Make sure you consult the Cloud SQL documentation to choose the edition that is appropriate for your needs. For more information, see Introduction to Cloud SQL for MySQL editions.
If you are configuring your instance for high availability, select Multiple zones (Highly available). You can select both the primary and the secondary zone. The following conditions apply when the secondary zone is used during instance creation:
To enable private IP connectivity, make sure you meet all the additional networking requirements.
Optionally, under Public IP click the Authorized networks field, and either authorize a network or a proxy to connect to the Cloud SQL instance. Networks are only authorized with the addresses that you provide. See Configure public IP in the Cloud SQL documentation.
You configure the migration job connectivity in a later step. To learn more about available networking methods, see Configure connectivity.
Select the machine type for the Cloud SQL instance.
For more information, see Limitations.
Data cache is an optional feature available for Cloud SQL for MySQL Enterprise Plus edition instances that adds a high-speed local solid state drive to your destination database. This feature can introduce additional costs to your Cloud SQL. For more information on data cache, see Data cache overview in Cloud SQL documentation.
Make sure the instance has enough storage capacity to handle the data from your source database. You can increase this capacity at any time, but you can't decrease it.
(Optional) Configure data encryption options or resource labels for your destination instance.
Expand this section to see the optional steps.Click Show optional configurations, and then:
Specify whether you want to manage the encryption of the data that's migrated from the source to the destination. By default, your data is encrypted with a key that's managed by Google Cloud. If you want to manage your encryption, then you can use a customer-managed encryption key (CMEK). To do so:
If you don't see your key, then click Enter key resource name to provide the resource name of the key that you want to use. Example key resource name: projects/my-project-name/locations/my-location/keyRings/my-keyring/cryptoKeys/my-key
.
If Database Migration Service doesn't have these permissions, then information will appear, specifying that the Database Migration Service service account can't use the CMEK. Click Grant to give Database Migration Service permissions to use the key.
For more information about creating a CMEK, see Using customer-managed encryption keys (CMEK).
Labels help organize your instances. For example, you can organize labels by cost center or environment. Labels are also included in your bill so you can see the distribution of costs across your labels.
From the Connectivity method drop-down menu, select a network connectivity method. This method defines how the newly created Cloud SQL instance will connect to the source database. Current network connectivity methods include IP allowlist, reverse SSH tunnel, and VPC peering.
If you want to use... Then... The IP allowlist network connectivity method, You need to specify the outgoing IP address of your destination instance. If the Cloud SQL instance you created is a high availability instance, include the outgoing IP addresses for both the primary and the secondary instance. The reverse SSH tunnel network connectivity method, You need to select the Compute Engine VM instance that will host the tunnel.After specifying the instance, Google will provide a script that performs the steps to set up the tunnel between the source and destination databases. You'll need to run the script in the Google Cloud CLI.
Run the commands from a machine that has connectivity to both the source database and to Google Cloud.
The VPC peering network connectivity method, You need to select the VPC network where the source database resides. The Cloud SQL instance will be updated to connect to this network.After you select and configure network connectivity, click Configure and continue.
Create the migration jobOn the Test and create migration job, verify the settings for the migration job. At this point, testing the migration job will fail, because the service account associated with the Cloud SQL destination instance doesn't have the necessary permissions.
Perform one of the following actions before testing the job in order to validate job the configuration:
Create the destination connection profile.
When you migrate to a new destination instance with Google Cloud CLI, you create the destination instance and the connection profile in a single action.
Run the following command (click the link to expand):
gcloud database-migration connection-profiles create cloudsql
This sample uses the optional --no-async
flag so that all operations are performed synchronously. This means that some commands might take a while to complete. You can skip the --no-async
flag to run commands asynchronously. If you do, you need to use the gcloud database-migration operations describe
command to verify if your operation is successful.
Before using any of the command data below, make the following replacements:
MYSQL_8_0
, MYSQL_8_0_32
, MYSQL_8_0_36
.
For all possible MySQL versions, see the --database-version flag reference.
You can change your edition by using the --edition
flag with one of the following values:
enterprise-plus
for the Cloud SQL for MySQL Enterprise Plus editionenterprise
for the Cloud SQL for MySQL Enterprise editiondb-n1-standard-1
, db-perf-optimized-N-2
. For a full list of available machine types and their identifiers for use with Google Cloud CLI, see Machine types in Cloud SQL for MySQL documentation.
Instances created with Google Cloud CLI by default use the Cloud SQL for MySQL Enterprise Plus edition that has different machine types available. If you want to use a machine type that is available only in the Cloud SQL for MySQL Enterprise edition, use the optional --edition=enterprise
flag to specify the edition.
By default, new instances you create with Google Cloud CLI use Cloud SQL for MySQL Enterprise Plus edition. If you plan to use Cloud SQL for MySQL Enterprise Plus edition, make sure your region is supported for that edition. See Cloud SQL for MySQL Enterprise Plus edition region support. You can change the edition by using the optional --edition
flag.
By default, new instances you create with Google Cloud CLI have a public IP address assigned, and are configured to use public IP connectivity. You can use other connectivity methods. For more information, see Configure connectivity.
You don't need to use additional flags if you want to use public IP connectivity. If you want to use private IP connectivity with VPC Network Peering or a reverse-SSH tunnel, make sure you meet the following additional network requirements for enabling private IP connectivity and include additional flags in your command.
Include the following additional flags if you want to use private IP connectivity (with VPC Network Peering or with a reverse-SSH tunnel on a Compute Engine VM):
--no-enable-ip-v4
: (Optional) To not assign a public IP address to your destination instance. You can have both a public and a private IP address assigned to your destination instance, but you might not want a public IP address if you use private IP connectivity.--private-network
: To assign a private IP address to your destination instance, specify the name of the Virtual Private Cloud where you want to have a private IP address assigned.Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration connection-profiles \ create mysql CONNECTION_PROFILE_ID \ --no-async \ --region=REGION \ --database-version=DATABASE_VERSION \ --tier=TIER \ --display-name=CONNECTION_PROFILE_NAMEWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration connection-profiles ` create mysql CONNECTION_PROFILE_ID ` --no-async ` --region=REGION ` --database-version=DATABASE_VERSION ` --tier=TIER ` --display-name=CONNECTION_PROFILE_NAMEWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration connection-profiles ^ create mysql CONNECTION_PROFILE_ID ^ --no-async ^ --region=REGION ^ --database-version=DATABASE_VERSION ^ --tier=TIER ^ --display-name=CONNECTION_PROFILE_NAME
You should receive a response similar to the following:
Waiting for connection profile [CONNECTION_PROFILE_ID] to be created with [OPERATION_ID] Waiting for operation [OPERATION_ID] to complete...done. Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]
Depending on what network connectivity you want to use, there might be additional steps you need to follow before you create the migration job.
Create the migration job.
Run the following command (click the link to expand):
gcloud database-migration migration-jobs create
This sample uses the optional --no-async
flag so that all operations are performed synchronously. This means that some commands might take a while to complete. You can skip the --no-async
flag to run commands asynchronously. If you do, you need to use the gcloud database-migration operations describe
command to verify if your operation is successful.
Before using any of the command data below, make the following replacements:
ONE_TIME
or CONTINUOUS
. For more information, see Types of migration.gs://<bucket_name>/<path_to_backup_file_folder>
.If you use private IP connectivity with VPC Network Peering or a reverse-SSH tunnel, add the following flags to your command:
--peer-vpc
flag to specify the name of the network you want to peer with.
--vm-ip
, --vm-port
, --vpc
. You can also use the optional --vm
flag to specify the name of the VM.
For more usage examples, see Google Cloud CLI examples.
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration migration-jobs \ create MIGRATION_JOB_ID \ --no-async \ --region=REGION \ --display-name=MIGRATION_JOB_NAME \ --source=SOURCE_CONNECTION_PROFILE_ID \ --destination=DESTINATION_CONNECTION_PROFILE_ID \ --type=MIGRATION_JOB_TYPE --dump-type=PHYSICAL --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILESWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ` create MIGRATION_JOB_ID ` --no-async ` --region=REGION ` --display-name=MIGRATION_JOB_NAME ` --source=SOURCE_CONNECTION_PROFILE_ID ` --destination=DESTINATION_CONNECTION_PROFILE_ID ` --type=MIGRATION_JOB_TYPE --dump-type=PHYSICAL --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILESWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ^ create MIGRATION_JOB_ID ^ --no-async ^ --region=REGION ^ --display-name=MIGRATION_JOB_NAME ^ --source=SOURCE_CONNECTION_PROFILE_ID ^ --destination=DESTINATION_CONNECTION_PROFILE_ID ^ --type=MIGRATION_JOB_TYPE --dump-type=PHYSICAL --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES
You should receive a response similar to the following:
Waiting for migration job [MIGRATION_JOB_ID] to be created with [OPERATION_ID] Waiting for operation [OPERATION_ID] to complete...done. Created migration job MIGRATION_JOB_ID [OPERATION_ID]
When you create the migration job to a new instance, Database Migration Service also creates the destination Cloud SQL instance for you. Before you can run the migration, you need to assign Cloud Storage permissions for the instance's service account.
To grant the Cloud Storage permissions to the service account associated with your destination instance, follow these steps:
<project-identifier>@gcp-sa-cloud-sql.iam.gserviceaccount.com
. See View instance information in the Cloud SQL documentation.roles/storage.objectViewer
) IAM role to the service account. For information on how to manage access with Identity and Access Management, see Manage access to projects, folders, and organizations in the IAM documentation.Before you run the migration job, you can perform a test operation to check if Database Migration Service can reach all the necessary source and destination entities. With gcloud CLI, you can test migration jobs that are created, but not yet started.
ConsoleIn the Google Cloud console, you can only test draft migration jobs that you create in the migration job creation wizard. If you didn't save your job as a draft, but fully created it in the wizard, you can only perform the test by using Google Cloud CLI.
To test a draft migration job, follow these steps:
The migration job creation wizard opens.
The migration job is now created and ready to be started.
Before using any of the command data below, make the following replacements:
If you don't know the identifier, you can use the gcloud database-migration migration-jobs list
command to list all migration jobs in a given region and view their identifiers.
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration migration-jobs \ verify MIGRATION_JOB_ID \ --region=REGIONWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ` verify MIGRATION_JOB_ID ` --region=REGIONWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ^ verify MIGRATION_JOB_ID ^ --region=REGIONResult
The action is performed in an asynchronous manner. As such, this command returns an Operation entity that represents a long-running operation:
done: false metadata: '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata apiVersion: v1 createTime: '2024-02-20T12:20:24.493106418Z' requestedCancellation: false target: MIGRATION_JOB_ID verb: verify name: OPERATION_ID
To see if your operation is successful, you can query the returned operation object, or check the status of the migration job:
gcloud database-migration migration-jobs describe
command with the MIGRATION_JOB_ID to view the status of the migration job.gcloud database-migration operations describe
command with the OPERATION_ID to see the status of the operation itself.When your migration job is fully created (that is, it isn't saved in a draft state), you can start it at any time to begin migrating data.
To start a migration job, perform the following steps:
ConsoleThe migration job details page opens.
Before using any of the command data below, make the following replacements:
If you don't know the identifier, you can use the gcloud database-migration migration-jobs list
command to list all migration jobs in a given region and view their identifiers.
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration migration-jobs \ start MIGRATION_JOB_ID \ --region=REGIONWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ` start MIGRATION_JOB_ID ` --region=REGIONWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ^ start MIGRATION_JOB_ID ^ --region=REGIONResult
The action is performed in an asynchronous manner. As such, this command returns an Operation entity that represents a long-running operation:
done: false metadata: '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata apiVersion: v1 createTime: '2024-02-20T12:20:24.493106418Z' requestedCancellation: false target: MIGRATION_JOB_ID verb: start name: OPERATION_ID
To see if your operation is successful, you can query the returned operation object, or check the status of the migration job:
gcloud database-migration migration-jobs describe
command with the MIGRATION_JOB_ID to view the status of the migration job.gcloud database-migration operations describe
command with the OPERATION_ID to see the status of the operation itself.To configure your destination Cloud SQL instance, perform the following steps:
Depending on what connectivity method you want to use for your migration, you might need to add a public or a private IP address to your destination instance. For more information on connectivity methods, see Configure connectivity.
<project-identifier>@gcp-sa-cloud-sql.iam.gserviceaccount.com
. See View instance information in the Cloud SQL documentation.roles/storage.objectViewer
) IAM role to the service account. For information on how to manage access with Identity and Access Management, see Manage access to projects, folders, and organizations in the IAM documentation.You don't need to create the destination connection profile. When you create a migration job in the Google Cloud console, you use the destination instance identifier and Database Migration Service manages the connection profile for you.
Proceed to the Create and run migration job section.
gcloudThis sample uses the optional --no-async
flag so that all operations are performed synchronously. This means that some commands might take a while to complete. You can skip the --no-async
flag to run commands asynchronously. If you do, you need to use the gcloud database-migration operations describe
command to verify if your operation is successful.
Before using any of the command data below, make the following replacements:
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration connection-profiles \ create mysql CONNECTION_PROFILE_ID \ --no-async \ --cloudsql-instance=DESTINATION_INSTANCE_ID \ --region=REGION \ --display-name=CONNECTION_PROFILE_NAMEWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration connection-profiles ` create mysql CONNECTION_PROFILE_ID ` --no-async ` --cloudsql-instance=DESTINATION_INSTANCE_ID ` --region=REGION ` --display-name=CONNECTION_PROFILE_NAMEWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration connection-profiles ^ create mysql CONNECTION_PROFILE_ID ^ --no-async ^ --cloudsql-instance=DESTINATION_INSTANCE_ID ^ --region=REGION ^ --display-name=CONNECTION_PROFILE_NAME
You should receive a response similar to the following:
Waiting for connection profile [CONNECTION_PROFILE_ID] to be created with [OPERATION_ID] Waiting for operation [OPERATION_ID] to complete...done. Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]
The migration job configuration wizard page opens. This wizard contains multiple panels that walk you through each configuration step.
You can pause the creation of a migration job at any point by clicking SAVE & EXIT. All of the data that you enter up to that point is saved in a draft migration job. You can finish your draft migration job later.
This is a human-readable name for your migration job. This value is displayed in the Google Cloud console.
This is a machine-readable identifier for your migration job. You use this value to work with migration jobs by using Database Migration Service Google Cloud CLI commands or API.
The Destination database engine field is populated automatically and can't be changed.
Database Migration Service is a fully-regional product, meaning all entities related to your migration (source and destination connection profiles, migration jobs, destination databases) must be saved in a single region. Select the region based on the location of the services that need your data, such as Compute Engine instances or App Engine apps, and other services. After you choose the destination region, this selection can't be changed.
Important: If you plan to use the Cloud SQL for MySQL Enterprise Plus edition, make sure your region is supported for that edition. See Cloud SQL for MySQL Enterprise Plus edition region support.From the Connectivity method drop-down menu, select a network connectivity method. This method defines how the newly created Cloud SQL instance will connect to the source database. Current network connectivity methods include IP allowlist, reverse SSH tunnel, and VPC peering.
If you want to use... Then... The IP allowlist network connectivity method, You need to specify the outgoing IP address of your destination instance. If the Cloud SQL instance you created is a high availability instance, include the outgoing IP addresses for both the primary and the secondary instance. The reverse SSH tunnel network connectivity method, You need to select the Compute Engine VM instance that will host the tunnel.After specifying the instance, Google will provide a script that performs the steps to set up the tunnel between the source and destination databases. You'll need to run the script in the Google Cloud CLI.
Run the commands from a machine that has connectivity to both the source database and to Google Cloud.
The VPC peering network connectivity method, You need to select the VPC network where the source database resides. The Cloud SQL instance will be updated to connect to this network.After you select and configure network connectivity, click Configure and continue.
Test, create, and run the migration jobOn this final step, review the summary of the migration job settings, source, destination, and connectivity method, and then test the validity of the migration job setup. If any issues are encountered, then you can modify the migration job's settings. Not all settings are editable.
If the test fails, then you can address the problem in the appropriate part of the flow, and return to re-test. For information troubleshooting a failing migration job test, see Diagnose issues for MySQL.
Your migration is now in progress. When you start the migration job, Database Migration Service begins the full dump, briefly locking the source database.
To configure and run your migration, perform the following steps:
Create the migration job.
Run the following command (click the link to expand):
gcloud database-migration migration-jobs create
This sample uses the optional --no-async
flag so that all operations are performed synchronously. This means that some commands might take a while to complete. You can skip the --no-async
flag to run commands asynchronously. If you do, you need to use the gcloud database-migration operations describe
command to verify if your operation is successful.
Before using any of the command data below, make the following replacements:
ONE_TIME
or CONTINUOUS
. For more information, see Types of migration.gs://<bucket_name>/<path_to_backup_file_folder>
.If you use private IP connectivity with VPC Network Peering or a reverse-SSH tunnel, add the following flags to your command:
--peer-vpc
flag to specify the name of the network you want to peer with.
--vm-ip
, --vm-port
, --vpc
. You can also use the optional --vm
flag to specify the name of the VM.
For more usage examples, see Google Cloud CLI examples.
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration migration-jobs \ create MIGRATION_JOB_ID \ --no-async \ --region=REGION \ --display-name=MIGRATION_JOB_NAME \ --source=SOURCE_CONNECTION_PROFILE_ID \ --destination=DESTINATION_CONNECTION_PROFILE_ID \ --type=MIGRATION_JOB_TYPE --dump-type=PHYSICAL --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILESWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ` create MIGRATION_JOB_ID ` --no-async ` --region=REGION ` --display-name=MIGRATION_JOB_NAME ` --source=SOURCE_CONNECTION_PROFILE_ID ` --destination=DESTINATION_CONNECTION_PROFILE_ID ` --type=MIGRATION_JOB_TYPE --dump-type=PHYSICAL --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILESWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ^ create MIGRATION_JOB_ID ^ --no-async ^ --region=REGION ^ --display-name=MIGRATION_JOB_NAME ^ --source=SOURCE_CONNECTION_PROFILE_ID ^ --destination=DESTINATION_CONNECTION_PROFILE_ID ^ --type=MIGRATION_JOB_TYPE --dump-type=PHYSICAL --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES
You should receive a response similar to the following:
Waiting for migration job [MIGRATION_JOB_ID] to be created with [OPERATION_ID] Waiting for operation [OPERATION_ID] to complete...done. Created migration job MIGRATION_JOB_ID [OPERATION_ID]
Demote your Cloud SQL destination instance.
Run the following command (click the link to expand):
gcloud database-migration migration-jobs demote-destination
Before using any of the command data below, make the following replacements:
If you don't know the identifier, you can use the gcloud database-migration migration-jobs list
command to list all migration jobs in a given region and view their identifiers.
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration migration-jobs \ demote-destination MIGRATION_JOB_ID \ --region=REGIONWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ` demote-destination MIGRATION_JOB_ID ` --region=REGIONWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ^ demote-destination MIGRATION_JOB_ID ^ --region=REGIONResult
The action is performed in an asynchronous manner. As such, this command returns an Operation entity that represents a long-running operation:
done: false metadata: '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata apiVersion: v1 createTime: '2024-02-20T12:20:24.493106418Z' requestedCancellation: false target: MIGRATION_JOB_ID verb: demote-destination name: OPERATION_ID
To see if your operation is successful, you can query the returned operation object, or check the status of the migration job:
gcloud database-migration migration-jobs describe
command to view the status of the migration job.gcloud database-migration operations describe
with the OPERATION_ID to see the status of the operation itself.(Optional) Perform a migration job test
You can run a check to verify if Database Migration Service can reach all the necessary source and destination entities. Run the following command (click the link to expand):
Before using any of the command data below, make the following replacements:
If you don't know the identifier, you can use the gcloud database-migration migration-jobs list
command to list all migration jobs in a given region and view their identifiers.
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration migration-jobs \ verify MIGRATION_JOB_ID \ --region=REGIONWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ` verify MIGRATION_JOB_ID ` --region=REGIONWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ^ verify MIGRATION_JOB_ID ^ --region=REGIONResult
The action is performed in an asynchronous manner. As such, this command returns an Operation entity that represents a long-running operation:
done: false metadata: '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata apiVersion: v1 createTime: '2024-02-20T12:20:24.493106418Z' requestedCancellation: false target: MIGRATION_JOB_ID verb: verify name: OPERATION_ID
To see if your operation is successful, you can query the returned operation object, or check the status of the migration job:
gcloud database-migration migration-jobs describe
command with the MIGRATION_JOB_ID to view the status of the migration job.gcloud database-migration operations describe
command with the OPERATION_ID to see the status of the operation itself.Start the migration job.
Run the following command (click the link to expand):
Before using any of the command data below, make the following replacements:
If you don't know the identifier, you can use the gcloud database-migration migration-jobs list
command to list all migration jobs in a given region and view their identifiers.
Execute the following command:
Linux, macOS, or Cloud Shell Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.gcloud database-migration migration-jobs \ start MIGRATION_JOB_ID \ --region=REGIONWindows (PowerShell) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ` start MIGRATION_JOB_ID ` --region=REGIONWindows (cmd.exe) Note: Ensure you have initialized the Google Cloud CLI with authentication and a project by running either gcloud init; or gcloud auth login and gcloud config set project.
gcloud database-migration migration-jobs ^ start MIGRATION_JOB_ID ^ --region=REGIONResult
The action is performed in an asynchronous manner. As such, this command returns an Operation entity that represents a long-running operation:
done: false metadata: '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata apiVersion: v1 createTime: '2024-02-20T12:20:24.493106418Z' requestedCancellation: false target: MIGRATION_JOB_ID verb: start name: OPERATION_ID
To see if your operation is successful, you can query the returned operation object, or check the status of the migration job:
gcloud database-migration migration-jobs describe
command with the MIGRATION_JOB_ID to view the status of the migration job.gcloud database-migration operations describe
command with the OPERATION_ID to see the status of the operation itself.When you start the migration job, your destination Cloud SQL instance is put into a read-only mode where it is fully managed by Database Migration Service. You can promote it to a standalone instance when your data is fully migrated.
Note: You can monitor the migration progress, as well as your destination instance health with Database Migration Service observability features. See [Migration job metrics](/database-migration/docs/mysql/migration-job-metrics).
You can stop and delete your migration job at any point if you want to cancel the data migration process. You can manage the migration job in the Google Cloud console or with Google Cloud CLI.
For information on managing migration jobs in the Google Cloud console, see Manage migration jobs.
For information on managing migration jobs with Google Cloud CLI, see gcloud database-migration migration-jobs
reference.
When the migration job completes successfully, finalize the migration job by performing one of the following steps:
For one-time migrations: Migration job status changes to Complete. No further actions required, you can clean up the migration job and connection profile resources.
For continuous migrations: Promote the migration job to switch your application to the new database instance.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-07 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Migrating MySQL to Cloud SQL using Percona XtraBackup provides faster data restoration for large databases by employing a physical backup method."],["The migration process involves backing up the source MySQL instance, uploading files to Cloud Storage, creating a DMS migration job, and promoting the migration to complete the operation."],["Percona XtraBackup is the exclusive supported backup utility, only allowing for full backups, and it must be installed on the source machine for backup, but the version must be compatible with the source MySQL version."],["Database Migration Service is free for these homogenous migrations, but the user will still have to pay for the Cloud Storage and Cloud SQL resources used in the process."],["There are limitations to be considered before beginning, such as the fact that MySQL versions 5.6 and 8.4 are not supported, cross-version migrations are restricted to the same major version, and tables over 5TB are also not supported."]]],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4