Data Transmission Service:How to resolve slow or stuck full migration tasks

Check the source database

Estimate migration time

Before assuming something is wrong, estimate how long the migration should take:

1. Check the data volume of the objects to be migrated.

2. Run a small batch first — for example, migrate a 10 GB subset — and use that result to project the total migration time.

Check for concurrent tasks

Multiple DTS tasks running simultaneously compete for the same source database resources, which can cause temporary resource shortages. Run tasks in separate time windows to avoid contention.

Verify credentials

Confirm that DTS can connect to the source database using the configured username and password. Test connectivity from a remote host:

mysql -h<IP address or domain name of source database> -P<Port number of source database> -u<Username> -p<Password>

Check whitelist settings

If the source is a self-managed database, confirm that the DTS server CIDR blocks are added to the database's security settings. For instructions, see Whitelist DTS IP ranges for your user-created database.

Check for primary keys

Tables without primary keys or unique indexes can slow down full data migration significantly. DTS may also write duplicate records to the destination database. Check whether large tables have a primary key:

show create table <Database name>.<Table name>;

Check the destination database

Verify credentials

Confirm that DTS can connect to the destination database using the configured username and password. Test connectivity from a remote host:

mysql -h<IP address or domain name of destination database> -P<Port number of destination database> -u<Username> -p<Password>

Check whitelist settings

If the destination is a self-managed database, confirm that the DTS server CIDR blocks are added to the database's security settings. For instructions, see Whitelist DTS IP ranges for your user-created database.

Check read-only status

If the destination database is read-only, DTS cannot write data to it. To query the read-only status of a MySQL database:

show global variables like '%read_only%';

If read_only is returned and super_read_only is ON, the database is in read-only mode. To switch it to read/write:

unlock tables;
set global read_only=0;

read_only=1 or TRUE means read-only; read_only=0 or FALSE means read/write. For details, see the MySQL documentation.

Check available disk space

A full disk on the destination database stops all writes. For an ApsaraDB RDS for MySQL instance, check storage usage in the ApsaraDB RDS console. For details, see Troubleshoot insufficient storage issues on an ApsaraDB RDS for MySQL instance.

Check for performance bottlenecks

For an ApsaraDB RDS for MySQL instance, view CPU utilization, memory usage, and I/O load on the Monitoring and Alerts page in the ApsaraDB RDS console. Also check whether the instance has reached its type limits. For details, see View monitoring information and Instance types for standard primary ApsaraDB RDS for MySQL instances (original x86 architecture).

Check for deadlocks

If a deadlock is present, DTS cannot write data to the destination database. To diagnose and resolve deadlocks on a MySQL destination:

1. Check whether any tables are locked:

   show OPEN TABLES where In_use > 0;

2. Identify locked tables or slow queries:

   SHOW PROCESSLIST;

3. Kill the blocking process:

   KILL [CONNECTION | QUERY] thread_id

Check network connectivity

Use OS commands such as ping and telnet, or a third-party tool, to test network connectivity and latency between DTS and the source or destination database. If bandwidth is the limiting factor, upgrade the network bandwidth.