All Products
Search

This Product

    Data Transmission Service:Considerations and limits when migrating from a MySQL source database

    Document Center

    Data Transmission Service:Considerations and limits when migrating from a MySQL source database

    Last Updated:Feb 07, 2026

    If your source database is MySQL—such as a self-managed MySQL database or ApsaraDB RDS for MySQL—you must review these considerations and limits before you configure a data migration task to ensure its successful execution.

    Migration solutions for MySQL sources

    Review the considerations and limits for each migration solution:

    Migrate between MySQL databases

    If your destination database is MySQL—such as ApsaraDB RDS for MySQL or a self-managed MySQL database—review these considerations and limits:

    Type

    Description

    Source database limits

    • Bandwidth requirement: The server hosting the source database must have sufficient outbound bandwidth. Otherwise, migration speed will drop.

    • Each table to migrate must have a primary key or UNIQUE constraint, and the key columns must contain unique values. Otherwise, duplicate records may appear in the destination database.

    • If you select tables as the migration objects and edit them—for example, by mapping column names—a single migration task supports up to 1,000 tables. If you exceed this limit, the task fails with an error when submitted. To fix this, split the tables across multiple tasks or configure a full-database migration task.

    • If you need incremental migration, enable binary logging:

      • Set binlog_format to ROW and binlog_row_image to FULL. Otherwise, the precheck fails and the task cannot start.

        Important

        If your self-managed MySQL source is a dual-master cluster—where each instance acts as both master and slave—enable the log_slave_updates parameter. This ensures DTS can read all binary logs.

      • For RDS for MySQL instances, retain local binary logs for at least three days (seven days recommended). For self-managed MySQL databases, retain local binary logs for at least seven days. If DTS cannot access binary logs, the task fails. In extreme cases, data inconsistency or data loss may occur. Issues caused by binary log retention periods shorter than DTS requires are not covered under the DTS SLA.

        Note

        To set the retention period for local binary logs on an RDS for MySQL instance, see Automatically delete local logs.

    • Operations not allowed on the source database:

      • Do not run DDL operations that change database or table schemas during schema migration or full migration. Otherwise, the migration task fails.

        Note

        During full migration, DTS queries the source database. This creates metadata locks that may block DDL operations on the source database.

      • If you run only full migration, do not write new data to the source instance. Otherwise, source and destination data become inconsistent. To keep data consistent in real time, select schema migration, full migration, and incremental migration.

    • DTS does not migrate data generated by changes that do not write to binary logs. Examples include data restored from physical backups or created by cascade operations.

      Note

      If this occurs, re-run full migration after your business allows it.

    • If your source MySQL database is version 8.0.23 or later and contains invisible hidden columns, DTS cannot read those columns. This may cause data loss.

      Note

      Run ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; to make the hidden column visible. For more information, see Invisible Columns.

    Other limits

    • We recommend using the same MySQL version for source and destination databases to ensure compatibility.

    • If your source database uses temporary-table-mode online DDL operations—including multi-table merge scenarios—or adds function-based indexes to unique key columns, data loss or task failure may occur on the destination database.

    • DTS does not support migrating parsers defined using comment syntax.

    • If a primary key or unique key conflict occurs during migration:

      • If the table schemas are consistent and a record in the destination database has the same primary key value as a record in the source database:

        • During full migration, DTS keeps the record in the destination database. The record from the source database is not migrated.

        • During incremental migration, DTS does not keep the record in the destination database. The record from the source database overwrites the record in the destination database.

      • If the table schemas are inconsistent, only some columns of data may be migrated, or the migration may fail. Proceed with caution.

    • If your destination MySQL database is version 8.0.23 or later and the target column is an invisible hidden column, DTS cannot write data to it. This may cause task failure or data loss.

      Note

      Run ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; to make the hidden column visible. For more information, see Invisible Columns.

    • If you do not use DTS to migrate schemas, verify field compatibility yourself. Otherwise, the task may fail or data may be lost. For example, if the source column type is text and the destination column type is varchar(255), large fields in the source may be truncated.

    • If your data includes four-byte characters—such as rare Chinese characters or emojis—the destination database and table must use the utf8mb4 charset.

      Note

      If you use DTS to migrate schemas, set the instance-level parameter character_set_server to utf8mb4 in the destination database.

    • Before migration, assess the performance of both source and destination databases. Run migration during off-peak business hours. Otherwise, full migration consumes read and write resources on both databases and increases database load.

    • Full migration runs INSERT operations concurrently. This fragments destination tables. After full migration, destination tables require more storage space than source tables.

    • Confirm that DTS migration precision for FLOAT or DOUBLE columns meets your business needs. DTS reads these columns using ROUND(COLUMN,PRECISION). If no precision is defined, DTS uses 38 digits for FLOAT and 308 digits for DOUBLE.

    • DTS tries to recover failed tasks within seven days. Before switching traffic to the destination instance, end or release the task. Or run the revoke command to remove DTS’s write permission on the destination instance account. This prevents automatic recovery from overwriting destination data with source data.

    • If DDL writes fail on the destination database, the DTS task continues running. Check the failed DDL statements in the task logs. For instructions, see View task logs.

    • If you write columns with identical names but different cases into the same table in the destination MySQL database, unexpected results may occur. MySQL column names are case-insensitive.

    • After migration completes—the task status is Status and the status changes to Completed—run analyze table <table_name> to confirm all data is written to the destination table. For example, after a high-availability (HA) switchover in the destination MySQL database, data may remain in memory and never reach disk, causing data loss.

    • If your RDS for MySQL instance has Always-Encrypted enabled, full migration is not supported.

      Note

      RDS for MySQL instances with Transparent Data Encryption (TDE) enabled support schema migration, full migration, and incremental migration.

    • To migrate database accounts from the source, meet the required prerequisites and review related considerations. For more information, see Migrate database accounts.

    • If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.

      Note

      Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.

    Special cases

    • For self-managed MySQL sources:

      • A master–standby switchover on the source database causes the migration task to fail.

      • DTS calculates latency by comparing the timestamp of the last record migrated to the destination database with the current time. If no DML operations run on the source for a long time, latency reporting becomes inaccurate. If latency appears too high, run a DML operation on the source to update the latency value.

        Note

        If you select full-database migration, create a heartbeat table. Update or write to it every second.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

      • If your source is Amazon Aurora MySQL or another clustered MySQL instance, ensure the domain name or IP address configured for the task—and its DNS resolution—always points to a read–write (RW) node. Otherwise, the migration task may fail.

    • For RDS for MySQL sources:

      • If you need incremental migration, RDS for MySQL instances that do not record transaction logs—such as RDS for MySQL 5.6 read-only instances—are not supported as sources.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

    • For RDS for MySQL destinations:

      DTS automatically creates databases in RDS for MySQL. If the database name does not comply with RDS for MySQL naming rules, create the database manually before configuring the migration task. For instructions, see Manage databases.

    Migrate from MySQL to PolarDB for MySQL

    If your destination database is PolarDB for MySQL, review these considerations and limits:

    Type

    Description

    Source database limits

    • Bandwidth requirement: The server hosting the source database must have sufficient outbound bandwidth. Otherwise, migration speed will drop.

    • Each table to migrate must have a primary key or UNIQUE constraint, and the key columns must contain unique values. Otherwise, duplicate records may appear in the destination database.

    • If you select tables as the migration objects and edit them—for example, by mapping column names—a single migration task supports up to 1,000 tables. If you exceed this limit, the task fails with an error when submitted. To fix this, split the tables across multiple tasks or configure a full-database migration task.

    • If you need incremental migration, enable binary logging:

      • Set binlog_format to ROW and binlog_row_image to FULL. Otherwise, the precheck fails and the task cannot start.

        Important

        If your self-managed MySQL source is a dual-master cluster—where each instance acts as both master and slave—enable the log_slave_updates parameter. This ensures DTS can read all binary logs.

      • For RDS for MySQL instances, retain local binary logs for at least three days (seven days recommended). For self-managed MySQL databases, retain local binary logs for at least seven days. If DTS cannot access binary logs, the task fails. In extreme cases, data inconsistency or data loss may occur. Issues caused by binary log retention periods shorter than DTS requires are not covered under the DTS SLA.

        Note

        To set the retention period for local binary logs on an RDS for MySQL instance, see Automatically delete local logs.

    • Operations not allowed on the source database:

      • Do not run DDL operations that change database or table schemas during schema migration or full migration. Otherwise, the migration task fails.

        Note

        During full migration, DTS queries the source database. This creates metadata locks that may block DDL operations on the source database.

      • If you run only full migration, do not write new data to the source instance. Otherwise, source and destination data become inconsistent. To keep data consistent in real time, select schema migration, full migration, and incremental migration.

    • DTS does not migrate data generated by changes that do not write to binary logs. Examples include data restored from physical backups or created by cascade operations.

      Note

      If this occurs, re-run full migration after your business allows it.

    • If your source MySQL database is version 8.0.23 or later and contains invisible hidden columns, DTS cannot read those columns. This may cause data loss.

      Note

      Run ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; to make the hidden column visible. For more information, see Invisible Columns.

    Other limits

    • We recommend using the same MySQL version for source and destination databases to ensure compatibility.

    • If your source database uses temporary-table-mode online DDL operations—including multi-table merge scenarios—or adds function-based indexes to unique key columns, data loss or task failure may occur on the destination database.

    • DTS does not support migrating parsers defined using comment syntax.

    • If a primary key or unique key conflict occurs during migration:

      • If the table schemas are consistent and a record in the destination database has the same primary key value as a record in the source database:

        • During full migration, DTS keeps the record in the destination database. The record from the source database is not migrated.

        • During incremental migration, DTS does not keep the record in the destination database. The record from the source database overwrites the record in the destination database.

      • If the table schemas are inconsistent, only some columns of data may be migrated, or the migration may fail. Proceed with caution.

    • Before migration, assess the performance of both source and destination databases. Run migration during off-peak business hours. Otherwise, full migration consumes read and write resources on both databases and increases database load.

    • Full migration runs INSERT operations concurrently. This fragments destination tables. After full migration, destination tables require more storage space than source tables.

    • If your data includes four-byte characters—such as rare Chinese characters or emojis—the destination database and table must use the utf8mb4 charset.

      Note

      If you use DTS to migrate schemas, set the instance-level parameter character_set_server to utf8mb4 in the destination database.

    • Confirm that DTS migration precision for FLOAT or DOUBLE columns meets your business needs. DTS reads these columns using ROUND(COLUMN,PRECISION). If no precision is defined, DTS uses 38 digits for FLOAT and 308 digits for DOUBLE.

    • DTS tries to recover failed tasks within seven days. Before switching traffic to the destination instance, end or release the task. Or run the revoke command to remove DTS’s write permission on the destination instance account. This prevents automatic recovery from overwriting destination data with source data.

    • DTS does not support converting datetime data to varchar.

    • If DDL writes fail on the destination database, the DTS task continues running. Check the failed DDL statements in the task logs. For instructions, see View task logs.

    • If your RDS for MySQL instance has Always-Encrypted enabled, full migration is not supported.

      Note

      RDS for MySQL instances with Transparent Data Encryption (TDE) enabled support schema migration, full migration, and incremental migration.

    • To migrate database accounts from the source, meet the required prerequisites and review related considerations. For more information, see Migrate database accounts.

    • If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.

      Note

      Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.

    Special cases

    • For self-managed MySQL sources:

      • A master–standby switchover on the source database causes the migration task to fail.

      • DTS calculates latency by comparing the timestamp of the last record migrated to the destination database with the current time. If no DML operations run on the source for a long time, latency reporting becomes inaccurate. If latency appears too high, run a DML operation on the source to update the latency value.

        Note

        If you select full-database migration, create a heartbeat table. Update or write to it every second.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

      • If your source is Amazon Aurora MySQL or another clustered MySQL instance, ensure the domain name or IP address configured for the task—and its DNS resolution—always points to a read–write (RW) node. Otherwise, the migration task may fail.

    • For RDS for MySQL sources:

      • If you need incremental migration, RDS for MySQL instances that do not record transaction logs—such as RDS for MySQL 5.6 read-only instances—are not supported as sources.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

    • When the destination database is PolarDB MySQL Edition:

      • DTS automatically creates a database in PolarDB for MySQL. If the name of the database to be migrated does not meet the naming conventions of PolarDB for MySQL, you must create the database in PolarDB for MySQL before you configure the migration task. For related operations, see Manage databases.

      • You cannot adjust the full migration rate.

    Migrate from MySQL to PolarDB-X 2.0

    Review these considerations and limits:

    Type

    Description

    Source database limits

    • Bandwidth requirement: The server hosting the source database must have sufficient outbound bandwidth. Otherwise, migration speed will drop.

    • Each table to migrate must have a primary key or UNIQUE constraint, and the key columns must contain unique values. Otherwise, duplicate records may appear in the destination database.

    • If you select tables as the migration objects and edit them—for example, by mapping column names—a single migration task supports up to 1,000 tables. If you exceed this limit, the task fails with an error when submitted. To fix this, split the tables across multiple tasks or configure a full-database migration task.

    • If you need incremental migration, enable binary logging:

      • Set binlog_format to ROW and binlog_row_image to FULL. Otherwise, the precheck fails and the task cannot start.

        Important

        If your self-managed MySQL source is a dual-master cluster—where each instance acts as both master and slave—enable the log_slave_updates parameter. This ensures DTS can read all binary logs.

      • For RDS for MySQL instances, retain local binary logs for at least three days (seven days recommended). For self-managed MySQL databases, retain local binary logs for at least seven days. If DTS cannot access binary logs, the task fails. In extreme cases, data inconsistency or data loss may occur. Issues caused by binary log retention periods shorter than DTS requires are not covered under the DTS SLA.

        Note

        To set the retention period for local binary logs on an RDS for MySQL instance, see Automatically delete local logs.

    • Operations not allowed on the source database:

      • Do not run DDL operations that change database or table schemas during full migration. Otherwise, the migration task fails.

        Note

        During full migration, DTS queries the source database. This creates metadata locks that may block DDL operations on the source database.

      • If you run only full migration, do not write new data to the source instance. Otherwise, source and destination data become inconsistent. To keep data consistent in real time, select full migration and incremental migration.

    • DTS does not migrate data generated by changes that do not write to binary logs. Examples include data restored from physical backups or created by cascade operations.

      Note

      If this occurs, re-run full migration after your business allows it.

    • If your source MySQL database is version 8.0.23 or later and contains invisible hidden columns, DTS cannot read those columns. This may cause data loss.

      Note

      Run ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; to make the hidden column visible. For more information, see Invisible Columns.

    Other limits

    • If a primary key or unique key conflict occurs during migration:

      • If the table schemas are consistent and a record in the destination database has the same primary key value as a record in the source database:

        • During full migration, DTS keeps the record in the destination database. The record from the source database is not migrated.

        • During incremental migration, DTS does not keep the record in the destination database. The record from the source database overwrites the record in the destination database.

      • If the table schemas are inconsistent, only some columns of data may be migrated, or the migration may fail. Proceed with caution.

    • If your source database uses temporary-table-mode online DDL operations—including multi-table merge scenarios—or adds function-based indexes to unique key columns, data loss or task failure may occur on the destination database.

    • Before migration, assess the performance of both source and destination databases. Run migration during off-peak business hours. Otherwise, full migration consumes read and write resources on both databases and increases database load.

    • Full migration runs INSERT operations concurrently. This fragments destination tables. After full migration, destination tables require more storage space than source tables.

    • Confirm that DTS migration precision for FLOAT or DOUBLE columns meets your business needs. DTS reads these columns using ROUND(COLUMN,PRECISION). If no precision is defined, DTS uses 38 digits for FLOAT and 308 digits for DOUBLE.

    • DTS tries to recover failed tasks within seven days. Before switching traffic to the destination instance, end or release the task. Or run the revoke command to remove DTS’s write permission on the destination instance account. This prevents automatic recovery from overwriting destination data with source data.

    • If your RDS for MySQL instance has Always-Encrypted enabled, full migration is not supported.

      Note

      RDS for MySQL instances with Transparent Data Encryption (TDE) enabled support schema migration, full migration, and incremental migration.

    • If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.

      Note

      Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.

    Special cases

    • For self-managed MySQL sources:

      • A master–standby switchover on the source database causes the migration task to fail.

      • DTS calculates latency by comparing the timestamp of the last record migrated to the destination database with the current time. If no DML operations run on the source for a long time, latency reporting becomes inaccurate. If latency appears too high, run a DML operation on the source to update the latency value.

        Note

        If you select full-database migration, create a heartbeat table. Update or write to it every second.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

      • If your source is Amazon Aurora MySQL or another clustered MySQL instance, ensure the domain name or IP address configured for the task—and its DNS resolution—always points to a read–write (RW) node. Otherwise, the migration task may fail.

    • For RDS for MySQL sources:

      • If you need incremental migration, RDS for MySQL instances that do not record transaction logs—such as RDS for MySQL 5.6 read-only instances—are not supported as sources.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

    Migrate from MySQL to AnalyticDB for MySQL

    Review these considerations and limits:

    Type

    Description

    Source database limits

    • Bandwidth requirement: The server hosting the source database must have sufficient outbound bandwidth. Otherwise, migration speed will drop.

    • Each table to migrate must have a primary key or UNIQUE constraint, and the key columns must contain unique values. Otherwise, duplicate records may appear in the destination database.

    • If you select tables as the migration objects and edit them—for example, by mapping column names—a single migration task supports up to 1,000 tables. If you exceed this limit, the task fails with an error when submitted. To fix this, split the tables across multiple tasks or configure a full-database migration task.

    • If you need incremental migration, enable binary logging:

      • Set binlog_format to ROW and binlog_row_image to FULL. Otherwise, the precheck fails and the task cannot start.

        Important

        If your self-managed MySQL source is a dual-master cluster—where each instance acts as both master and slave—enable the log_slave_updates parameter. This ensures DTS can read all binary logs.

      • For RDS for MySQL instances, retain local binary logs for at least three days (seven days recommended). For self-managed MySQL databases, retain local binary logs for at least seven days. If DTS cannot access binary logs, the task fails. In extreme cases, data inconsistency or data loss may occur. Issues caused by binary log retention periods shorter than DTS requires are not covered under the DTS SLA.

        Note

        To set the retention period for local binary logs on an RDS for MySQL instance, see Automatically delete local logs.

    • Operations not allowed on the source database:

      • Do not run DDL operations that change database or table schemas during schema migration or full migration. Otherwise, the migration task fails.

        Note

        During full migration, DTS queries the source database. This creates metadata locks that may block DDL operations on the source database.

      • Do not run DDL operations that add comments—such as ALTER TABLE table_name COMMENT='Table comment';. Otherwise, the migration task fails.

      • If you run only full migration, do not write new data to the source instance. Otherwise, source and destination data become inconsistent. To keep data consistent in real time, select schema migration, full migration, and incremental migration.

    • DTS does not migrate data generated by changes that do not write to binary logs. Examples include data restored from physical backups or created by cascade operations.

      Note

      If this occurs, re-run full migration after your business allows it.

    • If your source MySQL database is version 8.0.23 or later and contains invisible hidden columns, DTS cannot read those columns. This may cause data loss.

      Note

      Run ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; to make the hidden column visible. For more information, see Invisible Columns.

    Other limits

    • Prefix indexes are not supported. If your source database contains prefix indexes, migration may fail.

    • DTS does not support migrating INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, or FK objects.

    • If your source database uses temporary-table-mode online DDL operations—including multi-table merge scenarios—or adds function-based indexes to unique key columns, data loss or task failure may occur on the destination database.

    • If a primary key or unique key conflict occurs during migration:

      • If the table schemas are consistent and a record in the destination database has the same primary key value as a record in the source database:

        • During full migration, DTS keeps the record in the destination database. The record from the source database is not migrated.

        • During incremental migration, DTS does not keep the record in the destination database. The record from the source database overwrites the record in the destination database.

      • If the table schemas are inconsistent, only some columns of data may be migrated, or the migration may fail. Proceed with caution.

    • The destination database must have a custom primary key. Or, in the Configurations for Databases, Tables, and Columns step, set the Primary Key Column. Otherwise, migration may fail.

    • Due to the built-in limits of AnalyticDB for MySQL, if disk space usage on nodes exceeds 80%, DTS tasks become abnormal and experience delays. Estimate the required space in advance based on the objects to be migrated, and ensure the destination cluster has sufficient storage space.

    • If the destination AnalyticDB for MySQL 3.0 cluster is backing up while the DTS task runs, the task fails.

    • Before migration, assess the performance of both source and destination databases. Run migration during off-peak business hours. Otherwise, full migration consumes read and write resources on both databases and increases database load.

    • Full migration runs INSERT operations concurrently. This fragments destination tables. After full migration, destination tables require more storage space than source tables.

    • Confirm that DTS migration precision for FLOAT or DOUBLE columns meets your business needs. DTS reads these columns using ROUND(COLUMN,PRECISION). If no precision is defined, DTS uses 38 digits for FLOAT and 308 digits for DOUBLE.

    • DTS tries to recover failed tasks within seven days. Before switching traffic to the destination instance, end or release the task. Or run the revoke command to remove DTS’s write permission on the destination instance account. This prevents automatic recovery from overwriting destination data with source data.

    • If DDL writes fail on the destination database, the DTS task continues running. Check the failed DDL statements in the task logs. For instructions, see View task logs.

    • If your RDS for MySQL instance has Always-Encrypted enabled, full migration is not supported.

      Note

      RDS for MySQL instances with Transparent Data Encryption (TDE) enabled support schema migration, full migration, and incremental migration.

    • If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.

      Note

      Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.

    Special cases

    • For self-managed MySQL sources:

      • A master–standby switchover on the source database causes the migration task to fail.

      • DTS calculates latency by comparing the timestamp of the last record migrated to the destination database with the current time. If no DML operations run on the source for a long time, latency reporting becomes inaccurate. If latency appears too high, run a DML operation on the source to update the latency value.

        Note

        If you select full-database migration, create a heartbeat table. Update or write to it every second.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

      • If your source is Amazon Aurora MySQL or another clustered MySQL instance, ensure the domain name or IP address configured for the task—and its DNS resolution—always points to a read–write (RW) node. Otherwise, the migration task may fail.

    • For RDS for MySQL sources:

      • If you need incremental migration, RDS for MySQL instances that do not record transaction logs—such as RDS for MySQL 5.6 read-only instances—are not supported as sources.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

    Migrate from MySQL to a self-managed Kafka cluster

    Review these considerations and limits:

    Type

    Description

    Source database limits

    • Bandwidth requirement: The server hosting the source database must have sufficient outbound bandwidth. Otherwise, migration speed will drop.

    • Each table to migrate must have a primary key or UNIQUE constraint, and the key columns must contain unique values. Otherwise, duplicate records may appear in the destination database.

    • If you select tables as the migration objects and edit them—for example, by mapping column names—a single migration task supports up to 1,000 tables. If you exceed this limit, the task fails with an error when submitted. To fix this, split the tables across multiple tasks or configure a full-database migration task.

    • If you need incremental migration, enable binary logging:

      • Set binlog_format to ROW and binlog_row_image to FULL. Otherwise, the precheck fails and the task cannot start.

        Important

        If your self-managed MySQL source is a dual-master cluster—where each instance acts as both master and slave—enable the log_slave_updates parameter. This ensures DTS can read all binary logs.

      • For RDS for MySQL instances, retain local binary logs for at least three days (seven days recommended). For self-managed MySQL databases, retain local binary logs for at least seven days. If DTS cannot access binary logs, the task fails. In extreme cases, data inconsistency or data loss may occur. Issues caused by binary log retention periods shorter than DTS requires are not covered under the DTS SLA.

        Note

        To set the retention period for local binary logs on an RDS for MySQL instance, see Automatically delete local logs.

    • Operations not allowed on the source database:

      • Do not run DDL operations that change database or table schemas during schema migration or full migration. Otherwise, the migration task fails.

        Note

        During full migration, DTS queries the source database. This creates metadata locks that may block DDL operations on the source database.

      • If you run only full migration, do not write new data to the source instance. Otherwise, source and destination data become inconsistent. To keep data consistent in real time, select schema migration, full migration, and incremental migration.

    • DTS does not migrate data generated by changes that do not write to binary logs. Examples include data restored from physical backups or created by cascade operations.

      Note

      If this occurs, re-run full migration after your business allows it.

    • If your source MySQL database is version 8.0.23 or later and contains invisible hidden columns, DTS cannot read those columns. This may cause data loss.

      Note

      Run ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; to make the hidden column visible. For more information, see Invisible Columns.

    Other limits

    • Only data tables are supported as migration objects.

    • DTS does not support migrating INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, or FK objects.

    • Before migration, assess the performance of both source and destination databases. Run migration during off-peak business hours. Otherwise, full migration consumes read and write resources on both databases and increases database load.

    • Full migration runs INSERT operations concurrently. This fragments destination tables. After full migration, destination tables require more storage space than source tables.

    • Confirm that DTS migration precision for FLOAT or DOUBLE columns meets your business needs. DTS reads these columns using ROUND(COLUMN,PRECISION). If no precision is defined, DTS uses 38 digits for FLOAT and 308 digits for DOUBLE.

    • DTS tries to recover failed tasks within seven days. Before switching traffic to the destination instance, end or release the task. Or run the revoke command to remove DTS’s write permission on the destination instance account. This prevents automatic recovery from overwriting destination data with source data.

    • Do not write data to the destination database except through DTS, because this can cause data inconsistency between the source and destination databases.

    • If your destination Kafka cluster scales out or scales in during migration, restart the DTS task.

    • If your RDS for MySQL instance has Always-Encrypted enabled, full migration is not supported.

      Note

      RDS for MySQL instances with Transparent Data Encryption (TDE) enabled support schema migration, full migration, and incremental migration.

    • If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.

      Note

      Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.

    Special cases

    • For self-managed MySQL sources:

      • A master–standby switchover on the source database causes the migration task to fail.

      • DTS calculates latency by comparing the timestamp of the last record migrated to the destination database with the current time. If no DML operations run on the source for a long time, latency reporting becomes inaccurate. If latency appears too high, run a DML operation on the source to update the latency value.

        Note

        If you select full-database migration, create a heartbeat table. Update or write to it every second.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

      • If your source is Amazon Aurora MySQL or another clustered MySQL instance, ensure the domain name or IP address configured for the task—and its DNS resolution—always points to a read–write (RW) node. Otherwise, the migration task may fail.

    • For RDS for MySQL sources:

      • If you need incremental migration, RDS for MySQL instances that do not record transaction logs—such as RDS for MySQL 5.6 read-only instances—are not supported as sources.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

    Migrate from MySQL to DataHub

    Review these considerations and limits:

    Type

    Description

    Source database limits

    • Bandwidth requirement: The server hosting the source database must have sufficient outbound bandwidth. Otherwise, migration speed will drop.

    • Each table to migrate must have a primary key or UNIQUE constraint, and the key columns must contain unique values. Otherwise, duplicate records may appear in the destination database.

    • If you select tables as the migration objects and edit them—for example, by mapping column names—a single migration task supports up to 1,000 tables. If you exceed this limit, the task fails with an error when submitted. To fix this, split the tables across multiple tasks or configure a full-database migration task.

    • If you need incremental migration, enable binary logging:

      • Set binlog_format to ROW and binlog_row_image to FULL. Otherwise, the precheck fails and the task cannot start.

        Important

        If your self-managed MySQL source is a dual-master cluster—where each instance acts as both master and slave—enable the log_slave_updates parameter. This ensures DTS can read all binary logs.

      • For RDS for MySQL instances, retain local binary logs for at least three days (seven days recommended). For self-managed MySQL databases, retain local binary logs for at least seven days. If DTS cannot access binary logs, the task fails. In extreme cases, data inconsistency or data loss may occur. Issues caused by binary log retention periods shorter than DTS requires are not covered under the DTS SLA.

        Note

        To set the retention period for local binary logs on an RDS for MySQL instance, see Automatically delete local logs.

    • Executing DDL operations that modify the database or table schema during the schema migration phase will cause the data migration task to fail.

    • DTS does not migrate data generated by changes that do not write to binary logs. Examples include data restored from physical backups or created by cascade operations.

      Note

      If this occurs, re-run full migration after your business allows it.

    • If your source MySQL database is version 8.0.23 or later and contains invisible hidden columns, DTS cannot read those columns. This may cause data loss.

      Note

      Run ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; to make the hidden column visible. For more information, see Invisible Columns.

    Other limits

    • Only table-level migration is supported.

    • DTS does not support migrating INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, or FK objects.

    • A single String field in the destination DataHub project supports up to 2 MB.

    • Do not use tools such as pt-online-schema-change to run online DDL operations on migration objects in the source database. Otherwise, migration fails.

    • You can use Data Management (DMS) to run online DDL operations. For instructions, see Online schema changes without locking tables.

      Warning

      If data other than DTS writes to the destination database, do not use DMS to run online DDL operations. Otherwise, destination data may be lost.

    • Confirm that DTS migration precision for FLOAT or DOUBLE columns meets your business needs. DTS reads these columns using ROUND(COLUMN,PRECISION). If no precision is defined, DTS uses 38 digits for FLOAT and 308 digits for DOUBLE.

    • DTS tries to recover failed tasks within seven days. Before switching traffic to the destination instance, end or release the task. Or run the revoke command to remove DTS’s write permission on the destination instance account. This prevents automatic recovery from overwriting destination data with source data.

    • If your RDS for MySQL instance has Always-Encrypted enabled, full migration is not supported.

      Note

      RDS for MySQL instances with Transparent Data Encryption (TDE) enabled support schema migration, full migration, and incremental migration.

    • If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.

      Note

      Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.

    Special cases

    • For self-managed MySQL sources:

      • A master–standby switchover on the source database causes the migration task to fail.

      • DTS calculates latency by comparing the timestamp of the last record migrated to the destination database with the current time. If no DML operations run on the source for a long time, latency reporting becomes inaccurate. If latency appears too high, run a DML operation on the source to update the latency value.

        Note

        If you select full-database migration, create a heartbeat table. Update or write to it every second.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.

      • If your source is Amazon Aurora MySQL or another clustered MySQL instance, ensure the domain name or IP address configured for the task—and its DNS resolution—always points to a read–write (RW) node. Otherwise, the migration task may fail.

    • For RDS for MySQL sources:

      • If you need incremental migration, RDS for MySQL instances that do not record transaction logs—such as RDS for MySQL 5.6 read-only instances—are not supported as sources.

      • DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to advance the binary log offset.