Migration fidelity

When you're migrating your schema, data, and metadata from a source database to a destination database, you want to ensure that all of this information is migrated accurately. Database Migration Service provides a high-fidelity way to migrate database objects (including the schema, data, and metadata) from one database to another.

All of the following data, schema, and metadata components are migrated as part of the database migration:

Data

  • All tables and schemas, excluding the following system databases: sys, mysql, performance_schema, and information_schema.

Schema

  • Naming

  • Primary key

  • Data type

  • Ordinal position

  • Default value

  • Nullability

  • Auto-increment attributes

  • Secondary indexes

Metadata

  • Stored procedures

  • Functions

  • Triggers

  • Views

  • Foreign key constraints

Continuous migration

Data manipulation language (DML) and data definition language (DDL) changes to all data, schemas, and metadata listed earlier are updated during continuous migrations.

What isn't migrated

  • To migrate encrypted databases you need to provide the encryption keys to Database Migration Service. 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, Encrypting Amazon RDS resources, and Configure customer-managed encryption keys (CMEK).

  • User accounts and logins aren't migrated.

    MySQL system databases (mysql, performance_schema, information_schema, and sys) aren't migrated. These databases contain information about user accounts, logins, and privileges. User account login information must be managed in the destination Cloud SQL database instance directly.

    Metadata objects (such as stored procedures, functions, views, events, and triggers) that use the DEFINER clause to reference a user account that doesn't exist on the destination instance will fail when invoked on the new Cloud SQL destination. You must either create the corresponding user accounts on the destination instance or update the DEFINER clauses before migrating. For more information, see Verify metadata with a DEFINER clause.

    To add users to the Cloud SQL destination instance, navigate to the instance and add users from the Users tab, or add them from the MySQL client. For more information about creating and managing database users in Cloud SQL for MySQL, see Create and manage users in the Cloud SQL documentation.

  • Non-default flag settings aren't migrated to the Cloud SQL destination instance. Run SHOW VARIABLES on your source database before migrating your schema, data, and metadata to the destination database, and then run it again on the Cloud SQL database. Update flag settings as needed on the Cloud SQL database to replicate the source settings.