This topic describes the limits on databases that are used for data migration.

Precautions

When you configure or modify a data migration task, the source and destination databases must be running. The source and destination databases cannot be in the process of upgrade, configuration change, network switchover, or cross-zone migration. This ensures that DTS can read database and table information from the source database and connect to the source and destination databases.

Note The source and destination databases include but are not limited to ApsaraDB for RDS databases, user-created databases, and cloud databases from other vendors.

Source database: MySQL

Limits Negative effect of failing to follow the limits
The server where the database resides must have sufficient outbound bandwidth. The reading speed of incremental data and binary log files is decreased. Data migration is delayed.
You cannot perform DDL operations to change the schemas of databases or tables during channel creation. The data migration channel fails to be created.
If you want to perform incremental data migration, you must enable the binary logging feature. The following requirements must be met:
  • The value of the binlog_format parameter is set to row.
  • The value of the binlog_row_image parameter is set to full.

DTS shows error messages during the precheck. DTS cannot start the data migration task.

Binary log files must be retained for at least 24 hours. We recommend that you retain binary log files for more than three days. If you select Incremental Data Migration when you configure a data migration task and binary log files are unavailable, an interrupted channel may fail to be resumed.
The accounts used for data migration must have the following permissions:
  • Schema migration and full data migration: the permission to perform SELECT operations on all the objects to be migrated
  • Incremental data migration: the REPLICATION SLAVE permission, the REPLICATION CLIENT permission, and the permission to perform SELECT operations on all the objects to be migrated

DTS shows error messages during the precheck. DTS cannot start the data migration task.

If the source database is a user-created database, you cannot perform a switchover between the primary and secondary databases during data migration. The performance of the primary database may be impaired. For example, when you configure data migration, you provide the connection information about the secondary database. After the switchover, this secondary database may become the primary database. In this case, the performance of the primary database may be impaired.

Source database: SQL Server

Limits Negative effect of failing to follow the limits
If you want to perform incremental data migration, the backup mode must be set to Full, and the full logical backup must be performed.

DTS shows error messages during the precheck. DTS cannot start the data migration task.

Log files of the source database must be backed up before data migration. These log files must be retained for at least 24 hours. We recommend that you retain log files for more than three days. If you select Incremental Data Migration when you configure a data migration task and log files are unavailable, an interrupted channel may fail to be resumed.
The accounts used for data migration must have the following permissions:
  • Schema migration and full data migration: the permission to perform SELECT operations on all the objects to be migrated
  • Incremental data migration: the sysadmin permission

DTS shows error messages during the precheck. DTS cannot start the data migration task.

A single data migration task can migrate incremental data from only one database. To migrate incremental data from multiple databases, you must create a data migration task for each database. You cannot create a single task in the DTS console to migrate incremental data from multiple databases.
The following data types are not supported: sql_variant, hierarchyid, geometry, cursor, and rowversion.
  • Changes to values of the image, text, ntext, and xml data types are not recorded in logs. DTS can only ensure the values of these data types are consistent between the source and destination databases.
  • If unsupported data types are used in the source database, data fails to be migrated.
  • Heap tables are not supported.
  • Tables that contain non-clustered indexes are not supported.
 Data fails to be migrated.

Source database: Oracle

Limits Negative effect of failing to follow the limits
The server where the database resides must have sufficient outbound bandwidth and CPU resources. The reading speed of incremental data and log files is decreased. Data migration is delayed.
You cannot perform DDL operations to change the schemas of databases or tables during channel creation. The data migration channel fails to be created.
  • Supplemental logging, including SUPPLEMENTAL_LOG_DATA_PK and SUPPLEMENTAL_LOG_DATA_UI, must be enabled.
  • The ARCHIVELOG mode must be enabled. Archived log files must be accessible.
  • If you select Incremental Data Migration when you configure a data migration task, DTS cannot parse all the transaction logs. DTS shows error messages during the precheck. DTS cannot start the data migration task.
  • If you do not select Incremental Data Migration, failing to follow the limits causes no negative effects.
Archived log files must be retained for at least 24 hours. We recommend that you retain archived log files for more than three days. If you select Incremental Data Migration when you configure a data migration task and log files are unavailable, an interrupted channel may fail to be resumed.
The accounts used for data migration must have the following permissions:
  • Schema migration and full data migration: the owner permission on schemas
  • Incremental data migration: the SYSDBA permission

DTS shows error messages during the precheck. DTS cannot start the data migration task.

The following data types are not supported: URI, UDT, BFile, and UROWID. Data fails to be migrated.

Source database: PostgreSQL

Limits Negative effect of failing to follow the limits
If you use the PostgreSQL Community Edition as the source database, you cannot perform a switchover between the primary and secondary databases during data migration. Incremental data may fail to be migrated.
The accounts used for data migration must have the following permissions:
  • Schema migration and full data migration: the usage permission on pg_catalog and the SELECT permission on the objects to be migrated
  • Incremental data migration: the superuser permission

DTS shows error messages during the precheck. DTS cannot start the data migration task.

Source database: Db2

Limits Negative effect of failing to follow the limits
The AIX all-in-one edition is not supported.

DTS shows error messages during the precheck. DTS cannot start the data migration task.

The accounts used for data migration must have the following permissions:
  • Schema migration and full data migration: the CONNECT and SELECT permissions
  • Incremental data migration: the DBADM permission

DTS shows error messages during the precheck. DTS cannot start the data migration task.

Only the following data types are supported:
  • SMALLINT, INTEGER, BITINT, DECIMAL, CHAR, VARCHAR, DECFLOAT, and DOUBLE REAL
  • GRAPHIC, VARGRAPHIC (Data records of the GRAPHIC and VARGRAPHIC types are stored as double-byte strings. The boundary check and validity check are not performed.), and DECFLOAT (The data range is large. Some databases do not support this data type. Only numeric values can be truncated.)
Data fails to be migrated.
If you want to perform incremental data migration, the ARCHIVELOG mode must be enabled and archived log files must be accessible. For more information, see Primary log archive method and Secondary log archive method.

DTS shows error messages during the precheck. DTS cannot start the data migration task.

The primary/secondary switchover logic supports only the SYNC, NEARSYNC, and ASYNC synchronization modes.
Note In the ASYNC mode, if a forced switchover is performed when the primary and secondary databases are not synchronized, data loss may occur on the secondary database. A non-forced switchover is performed after the primary and secondary databases are synchronized.
If SUPERASYNC is used for synchronization, DTS cannot ensure the continuity of the program during switchover.

Source database: Redis

Limits Negative effect of failing to follow the limits
During data migration, you cannot perform the resharding operation. Data in the source and destination databases is inconsistent.
During data migration, you cannot run the FLUSHDB, FLUSHALL, or SWAPDB command. Data in the source and destination databases is inconsistent.
You cannot run large numbers of SCRIPT commands. The latency of incremental data migration increases.
The accounts used for data migration must have the SYNC or PSYNC permission.

DTS shows error messages during the precheck. DTS cannot start the data migration task.

If the delay information is not displayed and the data migration task is not automatically resumed, DTS migrates data again in an RDB manner. DELETE operations that are performed in the source database are not migrated.

Source database: MongoDB

Limits Negative effect of failing to follow the limits
You cannot migrate data from MongoDB databases in a cluster architecture. You must migrate each shard of a sharded cluster instance. N/A
During data migration, you cannot perform the resharding operation. Data in the source and destination databases is inconsistent.
You cannot change the default oplog configuration. The oplog must be written to the oplog.rs collection in the local database.
  • If you select Incremental Data Migration when you configure a data migration task, DTS cannot obtain incremental data logs. DTS shows error messages during the precheck. DTS cannot start the data migration task.
  • If you do not select Incremental Data Migration, failing to follow the limits causes no negative effects.
The accounts used for data migration must have the following permissions:
  • Full data migration: the read permission on the source database
  • Incremental data migration: the read permission on the source database, admin database, and local database

DTS shows error messages during the precheck. DTS cannot start the data migration task.

Transaction information is not retained. When transactions are migrated to the destination database, they are converted into a single record.

Destination database: MySQL

Limits Negative effect of failing to follow the limits
During incremental data migration, only the following DDL operations can be synchronized:
  • ALTER TABLE and ALTER VIEW
  • CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, and CREATE VIEW
  • DROP INDEX and DROP TABLE
  • RENAME TABLE
  • TRUNCATE TABLE
 If you perform unsupported DDL operations on the source database, data fails to be migrated.

Destination database: DRDS

Limits Negative effect of failing to follow the limits
The database in DRDS instance are created based on ApsaraDB RDS for MySQL instances (MySQL 5.x) that you purchased. DTS does not support databases that are created based on ApsaraDB RDS for MySQL instances (MySQL 8.0) or ApsaraDB PolarDB for MySQL clusters. The data migration task cannot be configured.
DDL operations cannot be synchronized. Data fails to be migrated.

Destination database: SQL Server

Limits Negative effect of failing to follow the limits
During incremental data migration, only the following DDL operations can be synchronized:
  • CREATE TABLE (CREATE TABLE operations for creating partition tables or tables that contain functions cannot be synchronized.)
  • ALTER TABLE
    Note ALTER TABLE operations only include ADD COLUMN, DROP COLUMN, and RENAME COLUMN.
  • CREATE INDEX, DROP TABLE, RENAME TABLE, and TRUNCATE TABLE
 Data fails to be migrated.

Destination database: Oracle

Limits Negative effect of failing to follow the limits
During incremental data migration, only the following DDL operations can be synchronized:
  • CREATE TABLE (CREATE TABLE operations for creating partition tables or tables that contain functions cannot be synchronized.)
  • ALTER TABLE
    Note ALTER TABLE operations only include ADD COLUMN, DROP COLUMN, RENAME COLUMN, and ADD INDEX.
  • CREATE INDEX, DROP TABLE, RENAME TABLE, and TRUNCATE TABLE
 Data fails to be migrated.

Destination database: PostgreSQL

Limits Negative effect of failing to follow the limits
DDL operations cannot be synchronized during incremental data migration. Data fails to be migrated.

Destination database: Db2

Limits Negative effect of failing to follow the limits
DDL operations cannot be synchronized during incremental data migration. Data fails to be migrated.

Destination database: Redis

Limits Negative effect of failing to follow the limits
If the Redis database is deployed in the cluster architecture, you cannot run the FLUSHDB, FLUSHALL, or SWAPDB command during data migration. Data in the source and destination databases is inconsistent.
During initial full data migration, the destination Redis database (such as Redis Community Edition and ApsaraDB for Redis Community Edition) cannot contain data. The collection class or data in the source and destination databases is inconsistent.

Destination database: MongoDB

Limits Negative effect of failing to follow the limits
The writing of transactions is not supported. DTS only ensures eventual consistency between the source and destination databases.

Destination database: AnalyticDB for MySQL

Limits Negative effect of failing to follow the limits
A maximum of 1,024 tables can be migrated. Data fails to be migrated.
AnalyticDB for MySQL is incompatible with MySQL in terms of the processing of some invalid values. Data fails to be migrated.
The maximum length of a column is 16 MB by default. Data fails to be migrated.