Category | Description |
Limits on the source database | Bandwidth requirements: The server of the source database must have sufficient egress bandwidth. Otherwise, the data migration speed is affected. The tables to be migrated must have a primary key or a UNIQUE constraint, and all fields must be unique. Otherwise, the destination database may contain duplicate data. If you select tables as the migration objects and need to edit them, such as by mapping table or column names, a single data migration task can migrate up to 1,000 tables. If you try to migrate more than 1,000 tables, a request error occurs after you submit the task. In this case, split the tables into smaller batches and configure multiple tasks, or configure a task to migrate the entire database. Limits on operations in the source database: During schema migration and full data migration, do not perform data definition language (DDL) operations to change the database or table schemas. Otherwise, the data migration task fails. This scenario does not support incremental migration. To ensure data consistency, do not write new data to the source instance during data migration.
|
Other limits | This scenario supports only schema migration and full data migration. It does not support incremental migration. The names of migration objects can contain only letters, digits, and underscores (_). If an object name contains other types of characters, schema migration fails. The destination database must have a custom primary key, or you must configure the Primary Key Column in the Configurations for Databases, Tables, and Columns step. Otherwise, the data migration may fail. Due to the limits of AnalyticDB for MySQL, if the disk space usage of nodes in an AnalyticDB for MySQL cluster exceeds 80%, the write performance to the destination database slows down, which causes delays in the DTS task. If the usage exceeds 90%, data cannot be written to the destination database, and the DTS task becomes abnormal. Estimate the required disk space based on the migration objects in advance. Ensure that the destination cluster has sufficient storage space. If the destination AnalyticDB for MySQL 3.0 cluster is being backed up while the DTS task is running, the task fails. Before you migrate data, evaluate the performance of the source and destination databases. Migrate data during off-peak hours. During full data migration, DTS consumes read and write resources from the source and destination databases. This may increase the load on the database servers. During full data migration, concurrent INSERT operations cause table fragmentation in the destination database. After full data migration is complete, the table storage space in the destination database is larger than that in the source database. DTS attempts to resume failed migration tasks within seven days. Before you switch your business to the destination instance, stop or release the task. You can also run the revoke command to revoke the write permissions from the account that DTS uses to access the destination instance. 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. View the failed DDL statement in the task logs. For more information, see View task logs. If the task fails, DTS technical support will attempt to recover it within 8 hours. During the recovery process, operations such as restarting the task or adjusting its parameters may be performed.
Note When parameters are adjusted, only DTS task parameters are modified. Database parameters remain unchanged.The parameters that may be modified include but are not limited to those described in Modify instance parameters.
|