Data Transmission Service:Notes and limits for using PolarDB for MySQL as a source database

Type

Description

Source database limits

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• The tables to be migrated must have a primary key or a UNIQUE constraint, and the fields in the key or constraint must be unique. Otherwise, duplicate data may appear in the destination database.

• If you migrate data at the table level and need to edit the tables, such as mapping column names, a single data migration task can migrate a maximum of 1,000 tables. If you exceed this limit, an error is reported after you submit the task. In this case, split the tables into multiple migration tasks or configure a task to migrate the entire database.

• If you perform incremental migration:

  • You must enable binary logging and set the loose_polar_log_bin parameter to on. Otherwise, the precheck reports an error and the data migration task cannot start. For more information about how to enable binary logging and modify parameters, see Enable binary logging and Modify parameters.

    Note

    Enabling binary logging for a PolarDB for MySQL cluster consumes storage space and incurs storage fees.

  • The binary logs of the PolarDB for MySQL cluster must be retained for at least 3 days. We recommend a retention period of 7 days. Otherwise, DTS may fail to obtain the binary logs, which can cause the task to fail. In extreme cases, this can lead to data inconsistency or data loss. Issues caused by a binary log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

    Note

    For more information about how to set the retention period for binary logs of a PolarDB for MySQL cluster, see Modify the retention period.

• Operational limits for the source database:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

    Note

    During full data migration, DTS queries the source database. This creates a metadata lock, which may block DDL operations on the source database.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency occurs between the source and destination. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

Other limits

• The source and destination PolarDB for MySQL instances should run the same MySQL version to ensure compatibility.

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

• DTS does not support the migration of read-only nodes of the source PolarDB for MySQL instance.

• DTS does not support the migration of OSS external tables from the source PolarDB for MySQL instance.

• DTS does not support the migration of INDEX and PARTITION.

• DTS does not support primary/standby switchover scenarios for the database instance during full data migration. In such a scenario, reconfigure the migration task promptly.

• 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.

• 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 you perform data migration, evaluate the performance of the source and destination databases. We recommend that you perform data migration during off-peak hours. During full data migration, DTS consumes read and write resources on both the source and destination databases, which may increase the database load.

• Full data migration involves concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance after full migration is complete.

• Verify that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns by using ROUND(COLUMN,PRECISION). If the precision is not explicitly defined, DTS uses a default precision of 38 for FLOAT and 308 for DOUBLE.

• DTS attempts to recover failed tasks within seven days. Before you switch your workloads to the destination instance, you must end or release the task. Alternatively, revoke the write permissions of the database account that DTS uses to access the destination instance by using the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically recovered.

• If a DDL statement fails to be written to the destination database, the DTS task continues to run. You need to check the task logs for the failed DDL statement. For more information about how to view task logs, see Query task logs.

• 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.

Other notes

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

Type

Description

Source database limits

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• The tables to be migrated must have a primary key or a UNIQUE constraint, and the fields in the key or constraint must be unique. Otherwise, duplicate data may appear in the destination database.

• If you migrate data at the table level and need to edit the tables, such as mapping column names, a single data migration task can migrate a maximum of 1,000 tables. If you exceed this limit, an error is reported after you submit the task. In this case, split the tables into multiple migration tasks or configure a task to migrate the entire database.

• If you perform incremental migration:

  • You must enable binary logging and set the loose_polar_log_bin parameter to on. Otherwise, the precheck reports an error and the data migration task cannot start. For more information about how to enable binary logging and modify parameters, see Enable binary logging and Modify parameters.

    Note

    Enabling binary logging for a PolarDB for MySQL cluster consumes storage space and incurs storage fees.

  • The binary logs of the PolarDB for MySQL cluster must be retained for at least 3 days. We recommend a retention period of 7 days. Otherwise, DTS may fail to obtain the binary logs, which can cause the task to fail. In extreme cases, this can lead to data inconsistency or data loss. Issues caused by a binary log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

    Note

    For more information about how to set the retention period for binary logs of a PolarDB for MySQL cluster, see Modify the retention period.

• Operational limits for the source database:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

    Note

    During full data migration, DTS queries the source database. This creates a metadata lock, which may block DDL operations on the source database.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency occurs between the source and destination. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

Notes

• DTS does not support the migration of read-only nodes of the source PolarDB for MySQL instance.

• DTS does not support the migration of OSS external tables from the source PolarDB for MySQL instance.

• DTS does not support the migration of INDEX and PARTITION.

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

• DTS does not support primary/standby switchover scenarios for the database instance during full data migration. In such a scenario, reconfigure the migration task promptly.

• 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.

• 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 you perform data migration, evaluate the performance of the source and destination databases. We recommend that you perform data migration during off-peak hours. During full data migration, DTS consumes read and write resources on both the source and destination databases, which may increase the database load.

• Full data migration involves concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance after full migration is complete.

• Verify that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns by using ROUND(COLUMN,PRECISION). If the precision is not explicitly defined, DTS uses a default precision of 38 for FLOAT and 308 for DOUBLE.

• DTS attempts to recover failed tasks within seven days. Before you switch your workloads to the destination instance, you must end or release the task. Alternatively, revoke the write permissions of the database account that DTS uses to access the destination instance by using the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically recovered.

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

• If a DDL statement fails to be written to the destination database, the DTS task continues to run. You need to check the task logs for the failed DDL statement. For more information about how to view task logs, see Query 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 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

If the destination database is an RDS for MySQL instance, DTS automatically creates a database in the instance. If the name of the database to be migrated does not comply with the naming conventions of RDS for MySQL, create the database in the RDS for MySQL instance before you configure the migration task. For more information, see Manage databases.

Type

Description

Source database limits

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• The tables to be migrated must have a primary key or a UNIQUE constraint, and the fields in the key or constraint must be unique. Otherwise, duplicate data may appear in the destination database.

• If you migrate data at the table level and need to edit the tables, such as mapping column names, a single data migration task can migrate a maximum of 1,000 tables. If you exceed this limit, an error is reported after you submit the task. In this case, split the tables into multiple migration tasks or configure a task to migrate the entire database.

• If you perform incremental migration:

  • You must enable binary logging and set the loose_polar_log_bin parameter to on. Otherwise, the precheck reports an error and the data migration task cannot start. For more information about how to enable binary logging and modify parameters, see Enable binary logging and Modify parameters.

    Note

    Enabling binary logging for a PolarDB for MySQL cluster consumes storage space and incurs storage fees.

  • The binary logs of the PolarDB for MySQL cluster must be retained for at least 3 days. We recommend a retention period of 7 days. Otherwise, DTS may fail to obtain the binary logs, which can cause the task to fail. In extreme cases, this can lead to data inconsistency or data loss. Issues caused by a binary log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

    Note

    For more information about how to set the retention period for binary logs of a PolarDB for MySQL cluster, see Modify the retention period.

• Operational limits for the source database:

  • During full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

    Note

    During full data migration, DTS queries the source database. This creates a metadata lock, which may block DDL operations on the source database.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency occurs between the source and destination. To maintain real-time data consistency, select both full data migration and incremental data migration.

  • Incremental migration of DDL operations is not supported. If you need to perform a DDL operation, run it on the destination database first and then on the source database.

Notes

• 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.

• DTS does not support the migration of read-only nodes of the source PolarDB for MySQL instance.

• DTS does not support the migration of OSS external tables from the source PolarDB for MySQL instance.

• DTS does not support primary/standby switchover scenarios for the database instance during full data migration. In such a scenario, reconfigure the migration task promptly.

• Before you perform data migration, evaluate the performance of the source and destination databases. We recommend that you perform data migration during off-peak hours. During full data migration, DTS consumes read and write resources on both the source and destination databases, which may increase the database load.

• Full data migration involves concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance after full migration is complete.

• Verify that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns by using ROUND(COLUMN,PRECISION). If the precision is not explicitly defined, DTS uses a default precision of 38 for FLOAT and 308 for DOUBLE.

• DTS attempts to recover failed tasks within seven days. Before you switch your workloads to the destination instance, you must end or release the task. Alternatively, revoke the write permissions of the database account that DTS uses to access the destination instance by using the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically recovered.

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

• 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.

Type

Description

Source database limits

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• The tables to be migrated must have a primary key or a UNIQUE constraint, and the fields in the key or constraint must be unique. Otherwise, duplicate data may appear in the destination database.

• If you migrate data at the table level and need to edit the tables, such as mapping column names, a single data migration task can migrate a maximum of 1,000 tables. If you exceed this limit, an error is reported after you submit the task. In this case, split the tables into multiple migration tasks or configure a task to migrate the entire database.

• If you perform incremental migration:

  • You must enable binary logging and set the loose_polar_log_bin parameter to on. Otherwise, the precheck reports an error and the data migration task cannot start. For more information about how to enable binary logging and modify parameters, see Enable binary logging and Modify parameters.

    Note

    Enabling binary logging for a PolarDB for MySQL cluster consumes storage space and incurs storage fees.

  • The binary logs of the PolarDB for MySQL cluster must be retained for at least 3 days. We recommend a retention period of 7 days. Otherwise, DTS may fail to obtain the binary logs, which can cause the task to fail. In extreme cases, this can lead to data inconsistency or data loss. Issues caused by a binary log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

    Note

    For more information about how to set the retention period for binary logs of a PolarDB for MySQL cluster, see Modify the retention period.

• Operational limits for the source database:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

    Note

    During full data migration, DTS queries the source database. This creates a metadata lock, which may block DDL operations on the source database.

  • During migration, do not perform DDL operations that modify the primary key or add comments to a table, such as ALTER TABLE table_name COMMENT='table_comment';. Otherwise, the data migration task fails.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency occurs between the source and destination. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

Notes

• DTS does not support the migration of prefix indexes. If the source database has prefix indexes, the data migration may fail.

• 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.

• DTS does not support the migration of read-only nodes of the source PolarDB for MySQL instance.

• DTS does not support the migration of OSS external tables from the source PolarDB for MySQL instance.

• DTS does not support the migration of INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, and FK.

• DTS does not support primary/standby switchover scenarios for the database instance during full data migration. In such a scenario, reconfigure the migration task promptly.

• Due to the limits of AnalyticDB for MySQL, if the disk space usage of any node in the AnalyticDB for MySQL cluster exceeds 80%, the DTS task becomes abnormal and latency occurs. Estimate the required space in advance and ensure that the destination cluster has sufficient storage.

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

• Before you perform data migration, evaluate the performance of the source and destination databases. We recommend that you perform data migration during off-peak hours. During full data migration, DTS consumes read and write resources on both the source and destination databases, which may increase the database load.

• Full data migration involves concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance after full migration is complete.

• Verify that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns by using ROUND(COLUMN,PRECISION). If the precision is not explicitly defined, DTS uses a default precision of 38 for FLOAT and 308 for DOUBLE.

• DTS attempts to recover failed tasks within seven days. Before you switch your workloads to the destination instance, you must end or release the task. Alternatively, revoke the write permissions of the database account that DTS uses to access the destination instance by using the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically recovered.

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

• If a DDL statement fails to be written to the destination database, the DTS task continues to run. You need to check the task logs for the failed DDL statement. For more information about how to view task logs, see Query task logs.

• 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.

Type

Description

Source database limits

• The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected.

• The tables to be migrated must have a primary key or a UNIQUE constraint, and the fields in the key or constraint must be unique. Otherwise, duplicate data may appear in the destination database.

• If you migrate data at the table level and need to edit the tables, such as mapping column names, a single data migration task can migrate a maximum of 1,000 tables. If you exceed this limit, an error is reported after you submit the task. In this case, split the tables into multiple migration tasks or configure a task to migrate the entire database.

• If you perform incremental migration:

  • You must enable binary logging and set the loose_polar_log_bin parameter to on. Otherwise, the precheck reports an error and the data migration task cannot start. For more information about how to enable binary logging and modify parameters, see Enable binary logging and Modify parameters.

    Note

    Enabling binary logging for a PolarDB for MySQL cluster consumes storage space and incurs storage fees.

  • The binary logs of the PolarDB for MySQL cluster must be retained for at least 3 days. We recommend a retention period of 7 days. Otherwise, DTS may fail to obtain the binary logs, which can cause the task to fail. In extreme cases, this can lead to data inconsistency or data loss. Issues caused by a binary log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

    Note

    For more information about how to set the retention period for binary logs of a PolarDB for MySQL cluster, see Modify the retention period.

• Operational limits for the source database:

  • During schema migration and full data migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

    Note

    During full data migration, DTS queries the source database. This creates a metadata lock, which may block DDL operations on the source database.

  • If you perform only full data migration, do not write new data to the source instance. Otherwise, data inconsistency occurs between the source and destination. To maintain real-time data consistency, select schema migration, full data migration, and incremental data migration.

Notes

• DTS does not support the migration of read-only nodes of the source PolarDB for MySQL instance.

• DTS does not support the migration of OSS external tables from the source PolarDB for MySQL instance.

• DTS does not support primary/standby switchover scenarios for the database instance during full data migration. In such a scenario, reconfigure the migration task promptly.

• 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.

• Before you perform data migration, evaluate the performance of the source and destination databases. We recommend that you perform data migration during off-peak hours. During full data migration, DTS consumes read and write resources on both the source and destination databases, which may increase the database load.

• Full data migration involves concurrent INSERT operations, which causes table fragmentation in the destination database. As a result, the table storage space in the destination database is larger than that in the source instance after full migration is complete.

• Verify that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns by using ROUND(COLUMN,PRECISION). If the precision is not explicitly defined, DTS uses a default precision of 38 for FLOAT and 308 for DOUBLE.

• DTS attempts to recover failed tasks within seven days. Before you switch your workloads to the destination instance, you must end or release the task. Alternatively, revoke the write permissions of the database account that DTS uses to access the destination instance by using the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically recovered.

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

• 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

If the self-managed Oracle database uses a Real Application Clusters (RAC) architecture and needs to be connected to an Alibaba Cloud VPC, connect both the SCAN IP address and the virtual IP address (VIP) of each node to the VPC and configure routing. This ensures that the DTS task runs as expected. For more information, see Overview of scenarios for connecting an on-premises data center to Alibaba Cloud and Connect an on-premises data center to DTS through a VPN Gateway.

Type

Description

Source database limits

• The tables to be migrated must have a primary key or a UNIQUE constraint, and the fields in the key or constraint must be unique. Otherwise, duplicate data may appear in the destination database.

• If you migrate data at the table level and need to edit the tables, such as mapping column names, a single data migration task can migrate a maximum of 1,000 tables. If you exceed this limit, an error is reported after you submit the task. In this case, split the tables into multiple migration tasks or configure a task to migrate the entire database.

• If you perform incremental migration:

  • You must enable binary logging and set the loose_polar_log_bin parameter to on. Otherwise, the precheck reports an error and the data migration task cannot start. For more information about how to enable binary logging and modify parameters, see Enable binary logging and Modify parameters.

    Note

    Enabling binary logging for a PolarDB for MySQL cluster consumes storage space and incurs storage fees.

  • The binary logs of the PolarDB for MySQL cluster must be retained for at least 3 days. We recommend a retention period of 7 days. Otherwise, DTS may fail to obtain the binary logs, which can cause the task to fail. In extreme cases, this can lead to data inconsistency or data loss. Issues caused by a binary log retention period shorter than the DTS requirement are not covered by the DTS Service-Level Agreement (SLA).

    Note

    For more information about how to set the retention period for binary logs of a PolarDB for MySQL cluster, see Modify the retention period.

• Operational limits for the source database: During schema migration, do not perform DDL operations that change the database or table schema. Otherwise, the data migration task fails.

Other limits

• Initial full data synchronization is not supported. DTS does not migrate existing data from the source PolarDB for MySQL cluster to the destination DataHub instance.

• Only table-level data migration is supported.

• DTS does not support the migration of read-only nodes of the source PolarDB for MySQL instance.

• DTS does not support the migration of OSS external tables from the source PolarDB for MySQL instance.

• DTS does not support primary/standby switchover scenarios for the database instance during full data migration. In such a scenario, reconfigure the migration task promptly.

• Verify that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns by using ROUND(COLUMN,PRECISION). If the precision is not explicitly defined, DTS uses a default precision of 38 for FLOAT and 308 for DOUBLE.

• DTS attempts to recover failed tasks within seven days. Before you switch your workloads to the destination instance, you must end or release the task. Alternatively, revoke the write permissions of the database account that DTS uses to access the destination instance by using the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically recovered.

• 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.

Other notes

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