Category | Description |
Limits on the source database | The tables to be synchronized must have PRIMARY KEY or UNIQUE constraints (tables that have only UNIQUE constraints do not support schema synchronization, so we recommend that you use PRIMARY KEY constraints), and the fields must be unique. Otherwise, the destination database may contain duplicate data. Tables that have secondary indexes cannot be synchronized. If you select tables as the objects to be synchronized and you want to edit the tables, such as mapping table or column names, you can synchronize up to 5,000 tables in a single data synchronization task. If you run a task to synchronize more than 5,000 tables, a request error may occur after you submit the task. In this case, we recommend that you split the tables to be synchronized and configure multiple tasks to synchronize the tables in batches, or configure a task to synchronize the entire database. The following requirements for binary logs of the RDS for MySQL instances attached to the PolarDB-X 1.0 instance must be met: The binary logging feature must be enabled, and the binlog_row_image parameter must be set to full. Otherwise, an error is reported during the precheck, and the data synchronization task cannot be started. For an incremental synchronization task, DTS requires that the binary logs of the source database be retained for at least 24 hours. For a task that performs both full and incremental synchronization, DTS requires that the binary logs of the source database be retained for at least seven days. You can set the retention period of binary logs to more than 24 hours after the initial full data synchronization is complete. Otherwise, DTS may fail to obtain the binary logs and the task may fail. In exceptional circumstances, data may be inconsistent or lost. Issues that are caused because the retention period of binary logs is shorter than the required period are not covered by the DTS Service-Level Agreement (SLA).
Limits on operations to be performed on the source database: If you change the network type of the PolarDB-X 1.0 instance during data synchronization, you must modify the network connectivity information of the synchronization link after the network type is changed. During data synchronization, do not scale the source instance, such as scaling the attached RDS for MySQL instance or changing the distribution of physical databases and tables that correspond to logical databases and tables in the RDS for MySQL instance even if the RDS for MySQL instance is not scaled. In addition, do not migrate hot spot tables, change shard keys, or perform DDL operations. Otherwise, the data synchronization task fails or data inconsistency occurs. During schema synchronization and full data synchronization, do not execute DDL statements to change the schemas of databases or tables. Otherwise, the data synchronization task fails.
The storage class of the PolarDB-X 1.0 instance must be RDS for MySQL, including private custom RDS and separately purchased RDS. PolarDB for MySQL is not supported as the storage class. Storage resources of PolarDB-X 1.0 can be split only using horizontal splitting (sharding). Vertical splitting is not supported. Read-only instances of PolarDB-X 1.0 computing resources are not supported. The version of the source PolarDB-X 1.0 instance must be 5.2 or later.
|
Other limits | Indexes, partitions, views, procedures, functions, triggers, and foreign key constraints (FKs) are not synchronized. Indexes, partitions, views, procedures, functions, triggers, and foreign keys cannot be synchronized. DTS ensures the data consistency of incremental synchronization tasks based on the continuity of XA transactions in the source PolarDB-X 1.0 instance. If the continuity of XA transactions is disrupted, for example, when you modify the synchronization objects or in disaster recovery scenarios for the incremental data collection module, uncommitted XA transactions may be lost. A data synchronization task for a PolarDB-X 1.0 instance is a distributed task. A subtask is created for each attached RDS for MySQL instance. You can view the running status of subtasks in the Task Topology. If the destination AnalyticDB for MySQL V3.0 cluster is being backed up while the DTS task is running, the DTS task fails. Before you synchronize data, you must evaluate the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. Otherwise, initial full data synchronization may consume read and write resources of the source and destination databases and increase database loads. During initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. Therefore, after initial full data synchronization is complete, the tablespace of the destination instance is larger than that of the source instance. Do not use tools such as pt-online-schema-change to perform online DDL operations on the synchronization objects in the source database. Otherwise, the synchronization fails. During data synchronization, do not write data to the destination database using other tools. Otherwise, data inconsistency between the source and destination databases occurs. For example, if you use DMS to perform online DDL operations when data is written to the destination database using other tools, data may be lost in the destination database. 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.
|