Overview of migration scenarios for a PolarDB for MySQL source
This topic describes the notes and limits for the following migration scenarios:
Migration between PolarDB for MySQL clusters
The following notes and limits apply:
Type | Description |
Source database limits | Bandwidth: The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the migration speed is affected. The tables to be migrated must have primary keys or UNIQUE constraints, and the values in the columns must be unique. Otherwise, data may be duplicated in the destination database. If you migrate tables and need to edit them, 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. For incremental migration: Enable binary logging (Binlog) and set the loose_polar_log_bin parameter to on. Otherwise, an error is reported during the precheck 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 fees. Retain the binary logs of the PolarDB for MySQL cluster for at least 3 days. We recommend that you retain them for 7 days. Otherwise, Data Transmission Service (DTS) may fail because it cannot obtain the binary logs. In extreme cases, this may cause data inconsistency or data loss. Issues caused by a binary log retention period that is shorter than the required period 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.
Source database operation limits: During schema migration and full data migration, do not perform data definition language (DDL) operations to change the schema of the database or tables. Otherwise, the data migration task fails. If you perform only full data migration, do not write new data to the source instance. Otherwise, the data in the source and destination instances will be inconsistent. To ensure real-time data consistency, select schema migration, full data migration, and incremental data migration.
|
Other limits | Keep the MySQL versions of the source and destination PolarDB for MySQL clusters the same to ensure compatibility. DTS does not migrate data where a parser defined by using comments is used. Migration of read-only nodes from the source PolarDB for MySQL cluster is not supported. Migration of OSS external tables from the source PolarDB for MySQL cluster is not supported. Migration of INDEX and PARTITION objects is not supported. DTS does not support primary/secondary failover of the database instance during full migration. If a failover occurs, reconfigure the migration task promptly. If you perform online DDL operations that use temporary tables on the source database, such as merging multiple tables, data may be lost in the destination database or the migration instance may fail. If a primary key or unique key conflict occurs while the migration instance is running: If the source and destination databases have the same schema, and a data record has the same primary key as an existing data record in the destination database, the following scenarios may occur: During full data migration, DTS does not migrate the data record to the destination database. The existing data record in the destination database is retained. During incremental data migration, DTS migrates the data record to the destination database. The existing data record in the destination database is overwritten.
If the source and destination databases have different schemas, only specific columns are migrated or the data migration task fails. Proceed with caution.
If the data to be migrated contains information such as rare characters or emojis that takes up four bytes, the destination databases and tables to receive the data must use UTF8mb4 character set.
Note If you use the schema migration feature of DTS, set the instance parameter character_set_server in the destination database to UTF8mb4 character set. Evaluate the performance of the source and destination databases before data migration. Migrate data during off-peak hours. DTS consumes some read and write resources on the source and destination databases during full data migration, which may increase the database load. Full data migration involves concurrent INSERT operations, which can cause table fragmentation in the destination database. After full migration, the storage space used by the tables in the destination database is larger than that in the source instance. Confirm that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns using ROUND(COLUMN,PRECISION). If you do not specify the precision, the default precision for FLOAT is 38 and for DOUBLE is 308. DTS attempts to resume a failed migration task within seven days. Before you switch your business to the destination instance, end or release the task. You can also revoke the write permissions of the database account that DTS uses to access the destination instance by running the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed. If a DDL statement fails to be written to the destination database, the DTS task continues to run. You can view the failed DDL statement in the task logs. For more information about how to view task logs, see View task logs. If you want to migrate accounts from the source database to the destination database, you need to learn the prerequisites and precautions. For more information, see Migrate database accounts. If a DTS task fails to run, DTS technical support will try to restore the task within 8 hours. During the restoration, the task may be restarted, and the parameters of the task may be modified.
Note Only the parameters of the DTS task may be modified. The parameters of databases are not modified. The parameters that may be modified include but are not limited to the parameters in the "Modify instance parameters" section of the Modify the parameters of a DTS instance topic.
|
Other notes | DTS periodically runs the CREATE DATABASE IF NOT EXISTS `test` command on the source database to advance the binary log offset. |
Migration from PolarDB for MySQL to ApsaraDB RDS for MySQL or a self-managed MySQL database
The following notes and limits apply:
Type | Description |
Source database limits | Bandwidth: The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the migration speed is affected. The tables to be migrated must have primary keys or UNIQUE constraints, and the values in the columns must be unique. Otherwise, data may be duplicated in the destination database. If you migrate tables and need to edit them, 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. For incremental migration: Enable binary logging (Binlog) and set the loose_polar_log_bin parameter to on. Otherwise, an error is reported during the precheck 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 fees. Retain the binary logs of the PolarDB for MySQL cluster for at least 3 days. We recommend that you retain them for 7 days. Otherwise, Data Transmission Service (DTS) may fail because it cannot obtain the binary logs. In extreme cases, this may cause data inconsistency or data loss. Issues caused by a binary log retention period that is shorter than the required period 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.
Source database operation limits: During schema migration and full data migration, do not perform data definition language (DDL) operations to change the schema of the database or tables. Otherwise, the data migration task fails. If you perform only full data migration, do not write new data to the source instance. Otherwise, the data in the source and destination instances will be inconsistent. To ensure real-time data consistency, select schema migration, full data migration, and incremental data migration.
|
Notes | Migration of read-only nodes from the source PolarDB for MySQL cluster is not supported. Migration of OSS external tables from the source PolarDB for MySQL cluster is not supported. Migration of INDEX and PARTITION objects is not supported. DTS does not migrate data where a parser defined by using comments is used. DTS does not support primary/secondary failover of the database instance during full migration. If a failover occurs, reconfigure the migration task promptly. If you perform online DDL operations that use temporary tables on the source database, such as merging multiple tables, data may be lost in the destination database or the migration instance may fail. If a primary key or unique key conflict occurs while the migration instance is running: If the source and destination databases have the same schema, and a data record has the same primary key as an existing data record in the destination database, the following scenarios may occur: During full data migration, DTS does not migrate the data record to the destination database. The existing data record in the destination database is retained. During incremental data migration, DTS migrates the data record to the destination database. The existing data record in the destination database is overwritten.
If the source and destination databases have different schemas, only specific columns are migrated or the data migration task fails. Proceed with caution.
If the data to be migrated contains information such as rare characters or emojis that takes up four bytes, the destination databases and tables to receive the data must use UTF8mb4 character set.
Note If you use the schema migration feature of DTS, set the instance parameter character_set_server in the destination database to UTF8mb4 character set. Evaluate the performance of the source and destination databases before data migration. Migrate data during off-peak hours. DTS consumes some read and write resources on the source and destination databases during full data migration, which may increase the database load. Full data migration involves concurrent INSERT operations, which can cause table fragmentation in the destination database. After full migration, the storage space used by the tables in the destination database is larger than that in the source instance. Confirm that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns using ROUND(COLUMN,PRECISION). If you do not specify the precision, the default precision for FLOAT is 38 and for DOUBLE is 308. DTS attempts to resume a failed migration task within seven days. Before you switch your business to the destination instance, end or release the task. You can also revoke the write permissions of the database account that DTS uses to access the destination instance by running the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed. 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 can view the failed DDL statement in the task logs. For more information about how to view task logs, see View task logs. If you write column names that differ only in capitalization to the same table in the destination MySQL database, the data migration result may not meet your expectations because the column names in MySQL databases are not case-sensitive. After data migration is complete, that is, the Status of the instance changes to Completed, we recommend that you run the analyze table <table name> command to check whether data is written to the destination table. For example, if a high-availability (HA) switchover is triggered in the destination MySQL database, data may be written only to the memory. As a result, data loss occurs. If a DTS task fails to run, DTS technical support will try to restore the task within 8 hours. During the restoration, the task may be restarted, and the parameters of the task may be modified.
Note Only the parameters of the DTS task may be modified. The parameters of databases are not modified. The parameters that may be modified include but are not limited to the parameters in the "Modify instance parameters" section of the Modify the parameters of a DTS instance topic.
|
Special cases | If the destination database is an ApsaraDB RDS for MySQL instance, DTS automatically creates a database in it. If the name of the database to be migrated does not comply with the naming conventions of ApsaraDB RDS for MySQL, create the database in the ApsaraDB RDS for MySQL instance before you configure the migration task. For more information, see Manage databases. |
Migration from PolarDB for MySQL to PolarDB-X 2.0
The following notes and limits apply:
Type | Description |
Source database limits | Bandwidth: The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the migration speed is affected. The tables to be migrated must have primary keys or UNIQUE constraints, and the values in the columns must be unique. Otherwise, data may be duplicated in the destination database. If you migrate tables and need to edit them, 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. For incremental migration: Enable binary logging (Binlog) and set the loose_polar_log_bin parameter to on. Otherwise, an error is reported during the precheck 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 fees. Retain the binary logs of the PolarDB for MySQL cluster for at least 3 days. We recommend that you retain them for 7 days. Otherwise, Data Transmission Service (DTS) may fail because it cannot obtain the binary logs. In extreme cases, this may cause data inconsistency or data loss. Issues caused by a binary log retention period that is shorter than the required period 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.
Source database operation limits: During full data migration, do not perform DDL operations to change the schema of the database or tables. Otherwise, the data migration task fails. If you perform only full data migration, do not write new data to the source instance. Otherwise, the data in the source and destination instances will be inconsistent. To ensure real-time data consistency, select full data migration and incremental data migration. Incremental migration of DDL operations is not supported. Otherwise, the data migration task fails. To perform a DDL operation, manually run it on the destination database first, and then repeat the operation on the source database.
|
Notes | If you perform online DDL operations that use temporary tables on the source database, such as merging multiple tables, data may be lost in the destination database or the migration instance may fail. If a primary key or unique key conflict occurs while the migration instance is running: If the source and destination databases have the same schema, and a data record has the same primary key as an existing data record in the destination database, the following scenarios may occur: During full data migration, DTS does not migrate the data record to the destination database. The existing data record in the destination database is retained. During incremental data migration, DTS migrates the data record to the destination database. The existing data record in the destination database is overwritten.
If the source and destination databases have different schemas, only specific columns are migrated or the data migration task fails. Proceed with caution.
Migration of read-only nodes from the source PolarDB for MySQL cluster is not supported. Migration of OSS external tables from the source PolarDB for MySQL cluster is not supported. DTS does not support primary/secondary failover of the database instance during full migration. If a failover occurs, reconfigure the migration task promptly. Evaluate the performance of the source and destination databases before data migration. Migrate data during off-peak hours. DTS consumes some read and write resources on the source and destination databases during full data migration, which may increase the database load. Full data migration involves concurrent INSERT operations, which can cause table fragmentation in the destination database. After full migration, the storage space used by the tables in the destination database is larger than that in the source instance. Confirm that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns using ROUND(COLUMN,PRECISION). If you do not specify the precision, the default precision for FLOAT is 38 and for DOUBLE is 308. DTS attempts to resume a failed migration task within seven days. Before you switch your business to the destination instance, end or release the task. You can also revoke the write permissions of the database account that DTS uses to access the destination instance by running the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed. DTS periodically runs the CREATE DATABASE IF NOT EXISTS `test` command on the source database to advance the binary log offset. If a DTS task fails to run, DTS technical support will try to restore the task within 8 hours. During the restoration, the task may be restarted, and the parameters of the task may be modified.
Note Only the parameters of the DTS task may be modified. The parameters of databases are not modified. The parameters that may be modified include but are not limited to the parameters in the "Modify instance parameters" section of the Modify the parameters of a DTS instance topic.
|
Migrate from PolarDB for MySQL to AnalyticDB for MySQL
The following notes and limits apply:
Type | Description |
Source database limits | Bandwidth: The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the migration speed is affected. The tables to be migrated must have primary keys or UNIQUE constraints, and the values in the columns must be unique. Otherwise, data may be duplicated in the destination database. If you migrate tables and need to edit them, 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. For incremental migration: Enable binary logging (Binlog) and set the loose_polar_log_bin parameter to on. Otherwise, an error is reported during the precheck 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 fees. Retain the binary logs of the PolarDB for MySQL cluster for at least 3 days. We recommend that you retain them for 7 days. Otherwise, Data Transmission Service (DTS) may fail because it cannot obtain the binary logs. In extreme cases, this may cause data inconsistency or data loss. Issues caused by a binary log retention period that is shorter than the required period 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.
Source database operation limits: During schema migration and full data migration, do not perform data definition language (DDL) operations to change the schema of the database or tables. Otherwise, the data migration task fails. During migration, do not perform DDL operations to modify primary keys or add comments to tables, 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, the data in the source and destination instances will be inconsistent. To ensure real-time data consistency, select schema migration, full data migration, and incremental data migration.
|
Notes | Migration of prefix indexes is not supported. If the source database has prefix indexes, the data migration may fail. If you perform online DDL operations that use temporary tables on the source database, such as merging multiple tables, data may be lost in the destination database or the migration instance may fail. If a primary key or unique key conflict occurs while the migration instance is running: If the source and destination databases have the same schema, and a data record has the same primary key as an existing data record in the destination database, the following scenarios may occur: During full data migration, DTS does not migrate the data record to the destination database. The existing data record in the destination database is retained. During incremental data migration, DTS migrates the data record to the destination database. The existing data record in the destination database is overwritten.
If the source and destination databases have different schemas, only specific columns are migrated or the data migration task fails. Proceed with caution.
You must specify a custom primary key in the destination database or configure Primary Key Column during the Configurations for Databases, Tables, and Columns. Otherwise, data may fail to be migrated. Migration of read-only nodes from the source PolarDB for MySQL cluster is not supported. Migration of OSS external tables from the source PolarDB for MySQL cluster is not supported. Migration of INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, and FK objects is not supported. DTS does not support primary/secondary failover of the database instance during full migration. If a failover occurs, reconfigure the migration task promptly. Due to the limits of AnalyticDB for MySQL, a DTS task becomes abnormal and latency occurs if the disk space usage of a node in an AnalyticDB for MySQL cluster exceeds 80%. Please estimate the required space based on the objects to be migrated in advance to ensure that the target cluster has sufficient storage space. If the destination AnalyticDB for MySQL V3.0 cluster is being backed up while the DTS task is running, the DTS task fails. Evaluate the performance of the source and destination databases before data migration. Migrate data during off-peak hours. DTS consumes some read and write resources on the source and destination databases during full data migration, which may increase the database load. Full data migration involves concurrent INSERT operations, which can cause table fragmentation in the destination database. After full migration, the storage space used by the tables in the destination database is larger than that in the source instance. Confirm that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns using ROUND(COLUMN,PRECISION). If you do not specify the precision, the default precision for FLOAT is 38 and for DOUBLE is 308. DTS attempts to resume a failed migration task within seven days. Before you switch your business to the destination instance, end or release the task. You can also revoke the write permissions of the database account that DTS uses to access the destination instance by running the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed. 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 can view the failed DDL statement in the task logs. For more information about how to view task logs, see View task logs. If a DTS task fails to run, DTS technical support will try to restore the task within 8 hours. During the restoration, the task may be restarted, and the parameters of the task may be modified.
Note Only the parameters of the DTS task may be modified. The parameters of databases are not modified. The parameters that may be modified include but are not limited to the parameters in the "Modify instance parameters" section of the Modify the parameters of a DTS instance topic.
|
Migration from PolarDB for MySQL to a self-managed Oracle database
The following notes and limits apply:
Type | Description |
Source database limits | Bandwidth: The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the migration speed is affected. The tables to be migrated must have primary keys or UNIQUE constraints, and the values in the columns must be unique. Otherwise, data may be duplicated in the destination database. If you migrate tables and need to edit them, 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. For incremental migration: Enable binary logging (Binlog) and set the loose_polar_log_bin parameter to on. Otherwise, an error is reported during the precheck 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 fees. Retain the binary logs of the PolarDB for MySQL cluster for at least 3 days. We recommend that you retain them for 7 days. Otherwise, Data Transmission Service (DTS) may fail because it cannot obtain the binary logs. In extreme cases, this may cause data inconsistency or data loss. Issues caused by a binary log retention period that is shorter than the required period 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.
Source database operation limits: During schema migration and full data migration, do not perform data definition language (DDL) operations to change the schema of the database or tables. Otherwise, the data migration task fails. If you perform only full data migration, do not write new data to the source instance. Otherwise, the data in the source and destination instances will be inconsistent. To ensure real-time data consistency, select schema migration, full data migration, and incremental data migration.
|
Notes | Migration of read-only nodes from the source PolarDB for MySQL cluster is not supported. Migration of OSS external tables from the source PolarDB for MySQL cluster is not supported. DTS does not support primary/secondary failover of the database instance during full migration. If a failover occurs, reconfigure the migration task promptly. If you perform online DDL operations that use temporary tables on the source database, such as merging multiple tables, data may be lost in the destination database or the migration instance may fail. If a primary key or unique key conflict occurs while the migration instance is running: If the source and destination databases have the same schema, and a data record has the same primary key as an existing data record in the destination database, the following scenarios may occur: During full data migration, DTS does not migrate the data record to the destination database. The existing data record in the destination database is retained. During incremental data migration, DTS migrates the data record to the destination database. The existing data record in the destination database is overwritten.
If the source and destination databases have different schemas, only specific columns are migrated or the data migration task fails. Proceed with caution.
Evaluate the performance of the source and destination databases before data migration. Migrate data during off-peak hours. DTS consumes some read and write resources on the source and destination databases during full data migration, which may increase the database load. Full data migration involves concurrent INSERT operations, which can cause table fragmentation in the destination database. After full migration, the storage space used by the tables in the destination database is larger than that in the source instance. Confirm that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns using ROUND(COLUMN,PRECISION). If you do not specify the precision, the default precision for FLOAT is 38 and for DOUBLE is 308. DTS attempts to resume a failed migration task within seven days. Before you switch your business to the destination instance, end or release the task. You can also revoke the write permissions of the database account that DTS uses to access the destination instance by running the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed. DTS periodically runs the CREATE DATABASE IF NOT EXISTS `test` command on the source database to advance the binary log offset. If a DTS task fails to run, DTS technical support will try to restore the task within 8 hours. During the restoration, the task may be restarted, and the parameters of the task may be modified.
Note Only the parameters of the DTS task may be modified. The parameters of databases are not modified. The parameters that may be modified include but are not limited to the parameters in the "Modify instance parameters" section of the Modify the parameters of a DTS instance topic.
|
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, you must connect both the SCAN IP 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 solutions for connecting an on-premises IDC to Alibaba Cloud and Connect an on-premises IDC to DTS through a VPN Gateway.
Important When you configure the source Oracle database information in the DTS console, enter only the SCAN IP of the Oracle RAC in the Database Address or IP Address field. |
Migration from PolarDB for MySQL to DataHub
The following notes and limits apply:
Type | Description |
Source database limits | The tables to be migrated must have primary keys or UNIQUE constraints, and the values in the columns must be unique. Otherwise, data may be duplicated in the destination database. If you migrate tables and need to edit them, 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. For incremental migration: Enable binary logging (Binlog) and set the loose_polar_log_bin parameter to on. Otherwise, an error is reported during the precheck 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 fees. Retain the binary logs of the PolarDB for MySQL cluster for at least 3 days. We recommend that you retain them for 7 days. Otherwise, Data Transmission Service (DTS) may fail because it cannot obtain the binary logs. In extreme cases, this may cause data inconsistency or data loss. Issues caused by a binary log retention period that is shorter than the required period 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.
Source database operation limits: During schema migration, do not perform DDL operations to change the schema of the database or tables. 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. Migration of read-only nodes from the source PolarDB for MySQL cluster is not supported. Migration of OSS external tables from the source PolarDB for MySQL cluster is not supported. DTS does not support primary/secondary failover of the database instance during full migration. If a failover occurs, reconfigure the migration task promptly. Confirm that the migration precision for columns of the FLOAT or DOUBLE data type meets your business requirements. DTS reads the values of these columns using ROUND(COLUMN,PRECISION). If you do not specify the precision, the default precision for FLOAT is 38 and for DOUBLE is 308. DTS attempts to resume a failed migration task within seven days. Before you switch your business to the destination instance, end or release the task. You can also revoke the write permissions of the database account that DTS uses to access the destination instance by running the revoke command. This prevents the source data from overwriting the data in the destination instance if the task is automatically resumed. If a DTS task fails to run, DTS technical support will try to restore the task within 8 hours. During the restoration, the task may be restarted, and the parameters of the task may be modified.
Note Only the parameters of the DTS task may be modified. The parameters of databases are not modified. The parameters that may be modified include but are not limited to the parameters in the "Modify instance parameters" section of the Modify the parameters of a DTS instance topic.
|
Other notes | DTS periodically runs the CREATE DATABASE IF NOT EXISTS `test` command on the source database to advance the binary log offset. |