Troubleshoot common issues

Available in VPC

You might run into the following problems when using Database Migration Service. Find out causes and possible solutions.

Migration error

Test Connection and migration failed.

Cause

• No Database in source DB.
• Target DB has the same Database name as source DB.
• Permissions required for migration have not been set.
• Settings to apply to source DB have not been applied.
• MyISAM, BLACKHOLE, FEDERATED, and ARCHIVE engines are not supported.
• Character sets of source DB and target DB are different.
• Target DB has been assigned to the cluster in service.

Solution

• Check if there is at least 1 Database in source DB.
• Delete duplicate Database.
• Check if source DB is in GTID mode. For permissions items needed for migration, see minimum permissions required for migration.
• Check following settings are applied to source DB:
  • Activate binary logs and assign server_id value.
  • Check whether the value of log_bin is displayed as ON.
  • For more information on preparations required for source DB replication, see preparations.
• Check if you selected MySQL engine that is not supported. To check whether migration is supported depending on the detailed settings of source DB, see supported databases.
• The supported character sets for migration are utf8, utf8mb4, euckr. If the character set is different, change character set of DB and table character set of source DB and proceed with migration.
• Target DB restarts during migration and is only available for reading data. Make sure not to designate a currently operating cluster as your target DB.

Migration incomplete

All migration steps, including replication, have been completed, but the status is displayed as "migration" in the Cloud DB for MySQL console.

Cause

In migration completed (same as replication completed) stage, DB Service migration is finally available only by clicking [Complete] in the console.

Solution

After checking the status becomes "Migration Completed", click [Complete].

MariaDB migration

Compatibility error messages appear during MariaDB migration.

Cause

Migration is available even when the source DB is MariaDB. However, MariaDB version that reached EOL can cause compatibility-related error messages during migration.

Solution

If the same error occurs continuously, change the target DB to MySQL version 5.7 to proceed with the migration or change the version of the source DB.

Migration error on definer account set in source DB

Definer account that is set in source DB was not automatically created during migration.

Cause

User accounts are not included in the migration target.

Solution

Create an account used in the definer in target DB directly. For more information, see manage DB user.

DB Config settings not migrated

DB Config settings were not migrated.

Cause

Migration for DB Config settings is not supported.

Solution

Set them the same as those for source DB on target DB such as the character set/collation.

Test Connection delay

Test connection takes too much time.

Cause

The process may take a few minutes if there is a large number of source DB schemas. It is a procedure to check authorization and inspect schema for the normal operation of migration.

Solution

No action is required as it is not an error. Make sure not to refresh as the check process will be reset.

"Killed $RESTORECMD" error message

Backup type: "Killed $RESTORECMD" error popup window appears when using mydumper.

Cause

For a large target table, a higher thread limit results in higher memory utilization during the import process. This increases the likelihood of OOM kills or server hangs.

Solution

Try again by lowering Thread limit after deleting migration.

Permission error

• Error occurs when executing GRANT REPLICATION SLAVE ON . TO '계정명'@'허용호스트'; The message **[28000][1045] Access denied for user 'account name'@'allowed host'**appears as well.
• Master command COM_REGISTER_SLAVE failed: Access denied for user 'account name'@'allowed host' (using password: YES) (Errno: 1045) error message appears in replication stage.

Cause

• If there is a problem with permissions of the account you are using, you may get an error.
• If there is no permission for replication, error may occur.

Solution

Check permissions of the account you are using. To run the commands, the account should have a permission for GRANT REPLICATION SLAVE*.* TO '계정명'@'허용호스트' WITH GRANT OPTION ; The permission is for DDL and is only granted to accounts created from the console.

Grant REPLICATION permissions

1. Enter the following commands in source DB to check REPLICATION SLAVE permissions:

   show grants for 'account name'@'allowed host';`
   

2. Grant REPLICATION SLAVE permission to accounts in source DB.

   GRANT REPLICATION SLAVE ON *.* TO 'account name'@'allowed host';`
   

Precautions for migrating some databases

If you proceed with the migration for only some databases, certain cross-database SQL operations may not be replicated or may result in errors during execution.
To prevent data consistency issues or execution errors after migration, review your application logic based on the following information.

Cause

• If cross-database SQL is used, execution errors may occur due to databases that are not included in the migration target.

Solution

• If cross-database SQL is used, make sure to include all related databases in the migration target.

1. Test environment

• Database to migrate: mig-db
• Database to exclude from migration: non-mig-db
• A replication filter example is as follows:

REPLICATE_WILD_IGNORE_TABLE = ('mysql.*', 'non-mig-db.*')

2. Replication behavior criteria
   Replication depends on the type of SQL operation. Refer to the following criteria:

3. Key scenarios

3.1. DML (data manipulation)

3.2. DDL (create/edit/drop table)

3.3. View

3.4. Stored procedure/function/trigger