Known limitations

MySQL | PostgreSQL | PostgreSQL to AlloyDB

Overview

Before you choose to migrate your databases to Cloud SQL, make sure you consider known limitations for this migration scenario.

Known limitations for using a MySQL database as a source include:

Migrating to MySQL 5.6 or MySQL 8.4 with a Percona XtraBackup physical backup file is not supported.
When you migrate across major MySQL versions (for example, from MySQL 8.0 to MySQL 8.4) you need to address possible incompatibilities to ensure a smooth migration without data consistency issues.

When you prepare for a cross-version migration, review the features supported by Cloud SQL for MySQL as well as the release notes for your target major version to determine what incompatibilities you need to address.
Don't perform any data definition language (DDL) changes, such as modifying table definitions, during the full data dump phase. DDL changes performed before the migration job moves to the CDC phase can cause your migration job to fail. For more information, see Diagnose issues: Table definition has changed error.
If the source is Amazon RDS MySQL, Amazon Aurora MySQL, or a source that doesn't grant SUPERUSER privileges, then additional steps are required for successful migration, including a brief write downtime on the source. For more information, see Amazon RDS-specific and Amazon Aurora-specific sections.
Database Migration Service can't migrate data from an Amazon Aurora read replica instance of a MySQL database cluster because binary log files can't be retrieved from the instance. For more information, see Amazon Aurora-specific section.
The MySQL system database isn't migrated as part of the server migration, which means information about user roles isn't included.
You can't select specific database objects (such as databases, tables, or schemas) when you migrate by using Database Migration Service. All tables from all databases and schemas are migrated, excluding the following system schemas: mysql, performance_schema, information_schema and sys. Before you begin the migration, make sure that your source database doesn't contain objects that reference tables in these schemas. Otherwise, your migration can fail with the ERROR 1109 (42S02): Unknown table in <schema name here> message. See Configure your source database and Diagnose issues.
If encrypted databases require customer-managed encryption keys to decrypt the information in the databases, and if Database Migration Service doesn't have access to the keys, then the databases can't be migrated.

Database Migration Service supports migrating data from encrypted Amazon Aurora or Amazon RDS databases because these databases handle decryption transparently in their services. For more information, see Encrypting Amazon Aurora resources and Encrypting Amazon RDS resources.
During migration, the destination Cloud SQL database is in read-only mode, to prevent modification of the database which might break the migration process or data integrity. After the destination is promoted, it becomes writable.
Presently, Database Migration Service isn't compatible with MariaDB.
You must set the binary log format to ROW. Configuring the binary log to any other format, such as STATEMENT or MIXED, might cause the replication to fail. For example, using the LOAD DATA IN FILE statement.

Learn more about this limitation for the STATEMENT or MIXED formats.
If you create a continuous migration job using your own dump file, then don't use the mysqldump utility from MySQL version 5.7.36. For more information, see bug #105761 in the MySQL documentation.
InnoDB is the only supported storage engine for Cloud SQL. Migrating with MyISAM might cause data inconsistency and requires data validation. For help with converting tables from MyISAM to InnoDB, see the MySQL documentation.

Data dump parallelism considerations

Data dump parallelism lets you migrate from MySQL databases using a high-performance dump mechanism, significantly improving the migration speed. When using data dump parallelism, consider the following:

Data dump parallelism is currently available only when migrating to MySQL versions 5.7 or 8.
At the beginning of the data dump, Database Migration Service briefly locks your source database making it temporarily unavailable for writes. The lock duration depends on the number of tables in the source database:

Number of tables Approximate lock time

100 1 second

10K 9 seconds

50K 49 seconds

Number of tables	Approximate lock time
100	1 second
10K	9 seconds
50K	49 seconds

Limitations for migrations to existing destination instances

Your existing destination instance must be empty or contain only system configuration data. Migrating to existing destination instances that contain user data (such as tables) isn't supported.
If you encounter issues due to extra data in your existing destination instance, clear the databases in your destination instance and re-try the migration job. See Clear extra data from your existing destination instance.
You can configure only one migration job per destination instance.
You can only migrate to standalone Cloud SQL instances. Migrating to external server replicas isn't supported.
Migrating data to a Cloud SQL instance that has Private Service Connect enabled isn't supported.
Migrating to a Cloud SQL instance that has a read replica requires that your source instance has global transaction ID (GTID) logging enabled.
For Terraform users: Database Migration Service modifies the backup and recovery settings of your destination instance. This might cause your the destination instance settings to be different from the Terraform configuration you used for provisioning. If you experience this issue, follow the guidance in Diagnose issues.

Quotas

Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted.