This topic describes the precautions and limits when you synchronize data from a DRDS instance. To ensure that your data synchronization task runs as expected, you must read the precautions and limits before you configure the task.

Notice

For more information about the limits for using PolarDB-X as the source instance, see Limits for using PolarDB-X as the source instance.

For more information about the solutions for using PolarDB-X as the source instance, see Solutions for using DRDS as the source instance.

Scenarios of synchronizing data from a PolarDB-X 1.0 instance

You can click one of the following synchronization scenarios to view its precautions and limits.
Note
By default, Data Transmission Service (DTS) disables FOREIGN KEY constraints for the destination database in a data synchronization task. Therefore, the cascade and delete operations of the source database are not synchronized to the following destination databases:
  • PolarDB-X 1.0
  • MySQL (ApsaraDB RDS for MySQL and self-managed MySQL databases)
  • PolarDB MySQL
  • AnalyticDB for MySQL

Synchronize data between PolarDB-X 1.0 instances

Category Description
Limits on the source database
  • The tables to synchronize must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate data records.
  • If you select tables as the objects to synchronize and you want to edit tables (such as renaming tables or columns), up to 1,000 tables can be synchronized in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you split the tables, configure multiple tasks to synchronize the tables, or configure a task to synchronize the entire database.
  • The following requirements for binary logs of the ApsaraDB RDS for MySQL instances attached to the DRDS instance must be met:
    • The binary logging feature must be enabled. The value of the binlog_row_image parameter must be set to full. Otherwise, error messages are returned during precheck and the data synchronization task cannot be started.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Otherwise, DTS may fail to obtain the binary logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. Make sure that you set the retention period of binary logs in accordance with the preceding requirements. Otherwise, the Service Level Agreement (SLA) of DTS does not ensure service reliability and performance.

  • Limits on operations:
    • If you change the network type of the DRDS instance during data synchronization, you must submit a ticket to update the network connection settings of the data synchronization task.
    • During data synchronization, do not scale the source instance, including the ApsaraDB RDS for MySQL instance attached to the source instance, or change the distribution of physical databases for which a logical database or logical table has been configured in the ApsaraDB RDS for MySQL instance. In addition, do not migrate hot tables, change the shard keys, or perform online DDL operations on the source instance. Otherwise, the data synchronization task fails or data inconsistency occurs.ApsaraDB RDS for MySQL
Other limits
  • The storage type of the DRDS instance must be ApsaraDB RDS for MySQL, including custom instance and purchased instance. PolarDB for MySQL cannot be used as the storage type.
  • Read-only instances at the DRDS compute layer are not supported.
  • DRDS storage resources can be split only by using horizontal splitting. Both databases and tables can be split. Vertical splitting is not supported.
  • When DTS synchronizes from a DRDS instance, data is distributed across the attached ApsaraDB RDS for MySQL instances. DTS runs a subtask for each ApsaraDB RDS for MySQL instance. The running state of the subtask is displayed in Task Topology.
  • Before you synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. During full data synchronization, DTS uses read and write resources of the source and destination databases. This may cause the loads of the database servers to increase.
  • During full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. After full data synchronization is complete, the tablespace of the destination database is larger than that of the source database.
  • We recommend that you do not use gh-ost or pt-online-schema-change to perform DDL operations on objects. Otherwise, data synchronization may fail.
  • During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. If you use tools other than DTS to write data to the destination database, data loss may occur in the destination database when you use Data Management (DMS) to perform online DDL operations.

Synchronize data from a PolarDB-X 1.0 instance to a MySQL databases or a PolarDB for MySQL cluster

Category Description
Limits on the source database
  • The tables to synchronize must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate data records.
  • If you select tables as the objects to synchronize and you want to edit tables (such as renaming tables or columns), up to 1,000 tables can be synchronized in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you split the tables, configure multiple tasks to synchronize the tables, or configure a task to synchronize the entire database.
  • The following requirements for binary logs of the ApsaraDB RDS for MySQL instances attached to the DRDS instance must be met:
    • The binary logging feature must be enabled. The value of the binlog_row_image parameter must be set to full. Otherwise, error messages are returned during precheck and the data synchronization task cannot be started.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Otherwise, DTS may fail to obtain the binary logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. Make sure that you set the retention period of binary logs in accordance with the preceding requirements. Otherwise, the Service Level Agreement (SLA) of DTS does not ensure service reliability and performance.

  • Limits on operations:
    • If you change the network type of the DRDS instance during data synchronization, you must submit a ticket to update the network connection settings of the data synchronization task.
    • During data synchronization, do not scale the source instance, including the ApsaraDB RDS for MySQL instance attached to the source instance, or change the distribution of physical databases for which a logical database or logical table has been configured in the ApsaraDB RDS for MySQL instance. In addition, do not migrate hot tables, change the shard keys, or perform online DDL operations on the source instance. Otherwise, the data synchronization task fails or data inconsistency occurs.ApsaraDB RDS for MySQL
  • The storage type of the DRDS instance must be ApsaraDB RDS for MySQL, including custom instance and purchased instance. PolarDB for MySQL cannot be used as the storage type.
  • DRDS storage resources can be split only by using horizontal splitting. Both databases and tables can be split. Vertical splitting is not supported.
  • Read-only instances at the DRDS compute layer are not supported.
Other limits
  • When DTS synchronizes from a DRDS instance, data is distributed across the attached ApsaraDB RDS for MySQL instances. DTS runs a subtask for each ApsaraDB RDS for MySQL instance. The running state of the subtask is displayed in Task Topology.
  • Before you synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. During full data synchronization, DTS uses read and write resources of the source and destination databases. This may cause the loads of the database servers to increase.
  • During full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. After full data synchronization is complete, the tablespace of the destination database is larger than that of the source database.
  • We recommend that you do not use gh-ost or pt-online-schema-change to perform DDL operations on objects. Otherwise, data synchronization may fail.
  • During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. If you use tools other than DTS to write data to the destination database, data loss may occur in the destination database when you use DMS to perform online DDL operations.

Synchronize data from a PolarDB-X 1.0 instance to an AnalyticDB for MySQL cluster

Category Description
Limits on the source database
  • The tables to synchronize must have PRIMARY KEY or UNIQUE constraints, and all fields must be unique. Otherwise, the destination database may contain duplicate data records.
  • If you select tables as the objects to synchronize and you want to edit tables (such as renaming tables or columns), up to 1,000 tables can be synchronized in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you split the tables, configure multiple tasks to synchronize the tables, or configure a task to synchronize the entire database.
  • The following requirements for binary logs of the ApsaraDB RDS for MySQL instances attached to the DRDS instance must be met:
    • The binary logging feature must be enabled. The value of the binlog_row_image parameter must be set to full. Otherwise, error messages are returned during precheck and the data synchronization task cannot be started.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Otherwise, DTS may fail to obtain the binary logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. Make sure that you set the retention period of binary logs in accordance with the preceding requirements. Otherwise, the Service Level Agreement (SLA) of DTS does not ensure service reliability and performance.

  • Limits on operations:
    • If you change the network type of the DRDS instance during data synchronization, you must submit a ticket to update the network connection settings of the data synchronization task.
    • During data synchronization, do not scale the source instance, including the ApsaraDB RDS for MySQL instance attached to the source instance, or change the distribution of physical databases for which a logical database or logical table has been configured in the ApsaraDB RDS for MySQL instance. In addition, do not migrate hot tables, change the shard keys, or perform online DDL operations on the source instance. Otherwise, the data synchronization task fails or data inconsistency occurs.ApsaraDB RDS for MySQL
  • The storage type of the DRDS instance must be ApsaraDB RDS for MySQL, including custom instance and purchased instance. PolarDB for MySQL cannot be used as the storage type.
  • DRDS storage resources can be split only by using horizontal splitting. Both databases and tables can be split. Vertical splitting is not supported.
  • Read-only instances at the DRDS compute layer are not supported.
Other limits
  • When DTS synchronizes from a DRDS instance, data is distributed across the attached ApsaraDB RDS for MySQL instances. DTS runs a subtask for each ApsaraDB RDS for MySQL instance. The running state of the subtask is displayed in Task Topology.
  • Before you synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. During full data synchronization, DTS uses read and write resources of the source and destination databases. This may cause the loads of the database servers to increase.
  • During full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. After full data synchronization is complete, the tablespace of the destination database is larger than that of the source database.
  • We recommend that you do not use gh-ost or pt-online-schema-change to perform DDL operations on objects. Otherwise, data synchronization may fail.
  • During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. If you use tools other than DTS to write data to the destination database, data loss may occur in the destination database when you use DMS to perform online DDL operations.