This topic describes how to fix the issue if full data migration stops or slows down.

Issue

When DTS is performing full data migration, the migration takes a long time or stops.

Solution

Use the following methods to troubleshoot the issue:

  • Check the source database:
    • Estimate the migration time:
      1. Check the data volume of the objects to be migrated from the source database.
      2. Migrate some tables first to evaluate the total amount of time required to migrate all tables. For example, you can estimate the overall migration time based on the time spent to migrate 10 GB data.
    • Check concurrent tasks: Check whether multiple tasks run at the same time.
      Note Concurrent tasks may result in temporary resource shortage. We recommend that you run tasks in separate time periods.
    • Check whether the username and password of the source database are accurate.

      Check whether you can connect to the source database from a remote host by using the username and password specified when you configure the task. For example, to connect to a MySQL database, run the following command: mysql -h<IP address or domain name of source database> -P<Port number of source database> -u<Username> -p<Password>.

    • Check whether the whitelist settings are valid. If the source database is a self-managed database, you can check whether the CIDR blocks of DTS servers are added to the security settings (for example, IP whitelist) of the database. For more information, see Whitelist DTS IP ranges for your user-created database.
    • Check whether all large tables in the source database contain primary keys or unique indexes. For example, to check whether a large table in a MySQL database contain primary keys or unique indexes, run the following command: show create table <Database name>.<Table name>;.
      Note If the source database contains only common indexes or no indexes, DTS may migrate duplicate data records to the destination database.
  • Check the destination database:
    • Check whether the username and password of the destination database are accurate.

      Check whether you can connect to the destination database from a remote host by using the username and password specified when you configure the task. For example, to connect to a MySQL database, run the following command: mysql -h<IP address or domain name of destination database> -P<Port number of destination database> -u<Username> -p<Password>.

    • Check whether the whitelist settings are valid. If the destination database is a self-managed database, you can check whether the CIDR blocks of DTS servers are added to the security settings (for example, IP whitelist) of the database. For more information, see Whitelist DTS IP ranges for your user-created database.
    • Check whether the destination database instance is read-only.
      For example, to query and modify the status of a MySQL database, run the following commands:
      1. Run the show global variables like '%read_only%'; command. If read_only is returned and super_read_only is ON, the MySQL database is set to read-only.
      2. Run the following command to change the status of the MySQL database from read-only to read/write: 
        unlock tables;
set global read_only=0;
      Note If a MySQL database is in the read-only state, the read_only parameter is set to 1 or TRUE. If the MySQL database is in the read/write state, the read_only parameter is set to 0 or FALSE. For more information, see MySQL documentation.
    • Check whether the destination database has available disk space.

      For example, you can view the storage usage of an ApsaraDB RDS for MySQL instance in the ApsaraDB RDS console. For more information, see Troubleshoot storage issues on an ApsaraDB RDS for MySQL instance.

    • Check whether the performance of the destination database has reached the bottleneck.

      For example, if the destination instance is an ApsaraDB RDS for MySQL instance, you can view the usage details of CPU, memory, and I/O resources on the Monitoring and Alerts page in the ApsaraDB RDS console. You can check whether the limits of the current instance type are reached. For more information, see View the resource, engine, and deployment metrics of an ApsaraDB RDS for MySQL instance and Primary ApsaraDB RDS for MySQL instance types.

    • Check whether the destination database has deadlocks.
      For example, if the destination database is a MySQL database, you can run the following commands to query and delete deadlocks:
      1. Run the following command to check whether the table is locked: show OPEN TABLES whereIn_use > 0;.
      2. Run the following command to query locked tables or slow SQL processes: SHOW PROCESSLIST;.
      3. Run the following command to delete a process: KILL [CONNECTION | QUERY]thread_id.
      Note If the destination database has deadlocks, data cannot be written to the database.
  • Check the network connectivity and whether the network bandwidth is limited. We recommend that you upgrade the network bandwidth if necessary.
    Note You can run OS commands (such as ping and telnet) or use third-party tools to test the network connectivity and network latency.