Migration evaluation

Category

Check item

Solution

Notes

Event Check

The source RDS instance has events, but DTS does not support event synchronization. You must manually synchronize the events to the destination PolarDB cluster.

Basic Information Verification

Source Instance Running Status

The source ApsaraDB RDS instance must be in the Running state.

Source Instance Read/Write Status

The source ApsaraDB RDS instance must be in the Running state and in Read/Write mode.

Source Instance Account Mode

If Database Proxy (Safe Mode) is enabled for the ApsaraDB RDS for MySQL instance, create a privileged account or switch the network connection mode of the ApsaraDB RDS for MySQL instance to high-performance mode. For more information, see Create an account and [Product changes/Feature changes] The network connection mode of an ApsaraDB RDS instance is upgraded.

Service-linked Role for PolarDB

The service-linked role for PolarDB is created for the account.

For more information about how to create a PolarDB service-linked role, see Precheck whether the service-linked role for PolarDB is created. You can also create a PolarDB service-linked role by calling the API operation.

Migration Task Dependency Verification

DTS Permissions

Your Alibaba Cloud account must have the permissions to access cloud resources over DTS.

For more information, see Authorize DTS to access Alibaba Cloud resources.

Whether Source Instance is Empty

Databases are created in the source ApsaraDB RDS instance. You must create a database in the instance before you can migrate data.

Source Instance Table Engine Verification

The table storage engine for the source RDS instance must be InnoDB or X-Engine.

Source Instance Trigger Verification

If triggers are created for the source ApsaraDB RDS instance, delete the triggers first. Otherwise, the migration process are interrupted.

-- Display all the triggers that exist in the source ApsaraDB RDS instance.
SHOW TRIGGERS;
-- Delete a specific trigger from the source ApsaraDB RDS instance.
DROP TRIGGER  trigger_name;

You can manually create triggers in the destination PolarDB cluster after the migration process is complete.

Verification for Non-primary-key Tables in Source Instance

If the source ApsaraDB RDS instance contains tables without primary keys, duplicate data may occur in the destination PolarDB cluster after data is synchronized.

You can connect to the database on the source ApsaraDB RDS instance by using a privileged account and execute the following SQL statement to query tables without primary keys:

SELECT t1.table_schema, t1.table_name 
FROM information_schema.TABLES t1 LEFT OUTER 
	JOIN information_schema.TABLE_CONSTRAINTS t2 
  ON t1.table_schema = t2.TABLE_SCHEMA AND t1.table_name = t2.TABLE_NAME AND t2.CONSTRAINT_NAME 
  IN ("PRIMARY") 
WHERE t2.table_name IS NULL AND t1.table_type = "BASE TABLE" AND t1.TABLE_SCHEMA NOT IN ("information_schema", "performance_schema", "mysql", "sys") 

You can add primary keys to the tables without primary keys.

If you confirm that duplicate data is acceptable, you can ignore this evaluation result and select Continue when the error message is returned when you Upgrade an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster.

Key Information Verification

Source Instance Root Account Verification

To ensure compatibility between ApsaraDB RDS for MySQL and PolarDB in terms of the system account structure and to prevent the system accounts of the destination PolarDB cluster from being overwritten during migration, make sure that the root and aliyun_root accounts do not exist in the source ApsaraDB RDS instance at the same time. For more information, see Remove redundant system accounts from the source ApsaraDB RDS instance.