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

Precautions

When you configure or modify a data synchronization 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 data and binary log files is decreased. Data synchronization is delayed.
You cannot perform DDL operations to change the schemas of databases or tables during channel creation. The data synchronization channel fails to be created.
The binary logging feature must be enabled. 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 synchronization 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 binary log files are unavailable, an interrupted channel may fail to be resumed.
The accounts used for data synchronization must have the REPLICATION SLAVE permission, the REPLICATION CLIENT permission, and the permission to perform SELECT operations on all the objects to be synchronized.

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

If the source database is a user-created database, you cannot perform a switchover between the primary and secondary databases during data synchronization. The performance of the primary database may be impaired. For example, when you configure data synchronization, 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: Redis

Limits Negative effect of failing to follow the limits
During data synchronization, you cannot perform the resharding operation. Data in the source and destination databases is inconsistent.
During data synchronization, 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. Synchronization latency increases.
The accounts used for data synchronization must have the SYNC or PSYNC permission.

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

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

Destination database: MySQL

Limits Negative effect of failing to follow the limits
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 synchronized.

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 synchronization. Data in the source and destination databases is inconsistent.
During initial full data synchronization, 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: AnalyticDB for MySQL

Limits Negative effect of failing to follow the limits
A maximum of 1,024 tables can be synchronized. Data fails to be synchronized.
Only the following DDL operations can be synchronized: CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE, ADD COLUMN, and DROP COLUMN. Data fails to be synchronized.
If the object to be synchronized is not a database, you cannot perform online DDL operations in the source database. Data fails to be synchronized. The system prompts that a temporary table does not exist or already exists.
Each table to be synchronized must contain a primary key. The value of the primary key cannot be NULL. Data fails to be synchronized or the data synchronization task fails to be started.
The data values that are contained in the source database must be supported by AnalyticDB for MySQL. Data fails to be synchronized.
AnalyticDB for MySQL is incompatible with MySQL in terms of the processing of some invalid values. Data fails to be synchronized.
The maximum length of a column is 16 MB by default. Data fails to be synchronized.

Destination database: MaxCompute

Limits Negative effect of failing to follow the limits
Only the following DDL operations can be synchronized: ALTER TABLE and ADD COLUMN. Data fails to be synchronized.