This topic describes the precautions and limits when you synchronize data from MySQL databases, such as self-managed MySQL databases and ApsaraDB RDS for MySQL instances. To ensure that your data synchronization task runs as expected, you must read the precautions and limits before you configure the task.

Scenarios of synchronizing data from a MySQL database

Take note of precautions and limits in the following data synchronization scenarios:
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 types of destination databases:
  • ApsaraDB RDS for MySQL instance or self-managed MySQL database
  • PolarDB for MySQL cluster
  • AnalyticDB for MySQL cluster
  • AnalyticDB for PostgreSQL instance
  • Elasticsearch cluster
  • ApsaraDB for ClickHouse cluster
  • Tablestore instance
  • PolarDB-X 2.0 instance
  • Oracle database
  • PostgreSQL database

Synchronize data between MySQL databases

The following table describes the precautions and limits when you synchronize data between MySQL databases, such as self-managed MySQL databases and ApsaraDB RDS for MySQL instances.
  • One-way data synchronization between MySQL databases
    Category Description
    Limits on the source database
    • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
      • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
        Notice
        • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
        • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

      • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

    Other limits
    • To ensure compatibility, the version of the destination database must be the same as or later than that of the source database. If the version of the destination database is earlier than that of the source database, database compatibility issues may occur.
    • 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 increase the loads on the database servers.
    • 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.
    • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

      If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

    • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
    Precautions
    If the source database is a self-managed MySQL database, take note of the following items:
    • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
    • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
      Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.
  • Two-way data synchronization between MySQL databases
    Category Description
    Limits on the source and destination databases
    • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
      • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
        Notice
        • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
        • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

      • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

    Other limits
    • To ensure compatibility, the version of the destination database must be the same as or later than that of the source database. If the version of the destination database is earlier than that of the source database, database compatibility issues may occur.
    • When DTS runs a two-way data synchronization task, DTS creates a database named dts in the destination database to prevent circular synchronization. When the task is running, do not modify the dts database.
    • If the source or destination database of a two-way data synchronization task resides in a region outside the Chinese mainland, data can be synchronized only within this region. Cross-region two-way synchronization is not supported. For example, if the source instance resides in the Japan (Tokyo) region, data can be synchronized only within the Japan (Tokyo) region and cannot be synchronized to the Germany (Frankfurt) region.
    • 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 increase the loads on the database servers.
    • 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.
    • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

      If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

    • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
    • By default, 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 destination database.
    • For a table that is synchronized in both the forward and reverse synchronization and both the full data and incremental data of the table are synchronized in the forward synchronization, DTS synchronizes only the incremental data of the table in the reverse synchronization.
    Special cases
    If the source database is a self-managed MySQL database, take note of the following items:
    • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
    • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
      Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to a PolarDB for MySQL cluster

  • One-way data synchronization from a MySQL database to a PolarDB for MySQL cluster
    Category Description
    Limits on the source database
    • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
      • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
        Notice
        • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
        • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

      • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

    Other limits
    • To ensure compatibility, the version of the destination database must be the same as or later than that of the source database. If the version of the destination database is earlier than that of the source database, database compatibility issues may occur.
    • 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 increase the loads on the database servers.
    • 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.
    • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

      If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

    • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
    Special cases
    If the source database is a self-managed MySQL database, take note of the following items:
    • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
    • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
      Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.
  • Two-way data synchronization from a MySQL database to a PolarDB for MySQL cluster
    Category Description
    Limits on the source and destination databases
    • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
      • For the MySQL database:
        The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
        Notice
        • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
        • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.
      • For the PolarDB for MySQL cluster:

        The binary logging feature must be enabled. The loose_polar_log_bin parameter must be set to on. 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 data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

    Other limits
    • To ensure compatibility, the version of the destination database must be the same as or later than that of the source database. If the version of the destination database is earlier than that of the source database, database compatibility issues may occur.
    • When DTS runs a two-way data synchronization task, DTS creates a database named dts in the destination database to prevent circular synchronization. When the task is running, do not modify the dts database.
    • If the source or destination database of a two-way data synchronization task resides in a region outside the Chinese mainland, data can be synchronized only within this region. Cross-region two-way synchronization is not supported. For example, if the source instance resides in the Japan (Tokyo) region, data can be synchronized only within the Japan (Tokyo) region and cannot be synchronized to the Germany (Frankfurt) region.
    • 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 increase the loads on the database servers.
    • 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.
    • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

      If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

    • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
    • By default, 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 destination database.
    • For a table that is synchronized in both the forward and reverse synchronization and both the full data and incremental data of the table are synchronized in the forward synchronization, DTS synchronizes only the incremental data of the table in the reverse synchronization.
    Special cases
    If the source database is a self-managed MySQL database, take note of the following items:
    • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
    • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
      Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to an AnalyticDB for MySQL cluster

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

  • During data synchronization, do not perform DDL operations to modify the primary key or add comments such as ALTER TABLE table_name COMMENT='Table comments'; because the operations cannot take effect.
Other limits
  • Prefix indexes cannot be synchronized. If the source database contains prefix indexes, data may fail to be synchronized.
  • Due to the limits of AnalyticDB for MySQL, if the disk space usage of the nodes in an AnalyticDB for MySQL cluster reaches 80%, the task is delayed and error messages are returned. We recommend that you estimate the required disk space based on the objects that you want to synchronize. You must ensure that the destination cluster has sufficient storage space.
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • If you use only DTS to write data to the destination database in the AnalyticDB for MySQL cluster, you can use DMS to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.
  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to an AnalyticDB for PostgreSQL instance

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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 SLA of DTS does not ensure service reliability and performance. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

  • During data synchronization, do not perform DDL operations to modify the primary key or add comments such as ALTER TABLE table_name COMMENT='Table comments'; because the operations cannot take effect.
Other limits
  • Requirements for the objects to be synchronized:
    • Only tables can be selected as the objects to be synchronized.
    • DTS does not synchronize the following data types: BIT, VARBIT, GEOMETRY, ARRAY, UUID, TSQUERY, TSVECTOR, and TXID_SNAPSHOT.
    • Prefix indexes cannot be synchronized. If the source database contains prefix indexes, data may fail to be synchronized.
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to a DataHub project

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a schema and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After the schema is synchronized, 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 SLA of DTS does not ensure service reliability and performance. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • Initial full data synchronization is not supported. DTS does not synchronize the historical data of required objects from the source ApsaraDB RDS for MySQL instance to the destination DataHub instance.
  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to an Elasticsearch cluster

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • To add columns to a table that you want to synchronize, you must perform the following steps: Modify the mappings of the table in the Elasticsearch cluster, perform DDL operations in the source MySQL database, and then pause and start the data synchronization task.
  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to a MaxCompute project

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • MaxCompute does not support PRIMARY KEY constraints. If network errors occur, DTS may synchronize duplicate data records to the MaxCompute project.
  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to an ApsaraDB for ClickHouse cluster

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
  • The names of the databases, tables, and columns to be synchronized must comply with the naming conventions of ApsaraDB for ClickHouse. For more information, see the "Object naming conventions" section of the Limits topic.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to a Tablestore instance

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
  • The names of the tables and columns to be synchronized must comply with the naming conventions of the Tablestore instance.
    • The name of a table or an index can contain letters, digits, and underscores (_). The name must start with a letter or underscore (_).
    • The name of a table or an index must be 1 to 255 characters in length.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to a Message Queue for Apache Kafka instance or a self-managed Kafka cluster

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to a PolarDB-X 2.0 instance

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a full data and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After 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. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • Schema synchronization is not supported in this scenario. Before you configure a data synchronization task, you must create databases and tables in the destination instance.
  • Requirements for the objects to be synchronized:
    • DTS does not synchronize the following data types: BIT, VARBIT, GEOMETRY, ARRAY, UUID, TSQUERY, TSVECTOR, and TXID_SNAPSHOT.
    • Prefix indexes cannot be synchronized. If the source database contains prefix indexes, data may fail to be synchronized.
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to an Oracle database

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a schema and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After the schema is synchronized, 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 SLA of DTS does not ensure service reliability and performance. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • The attribute of at most one column can be changed.
  • The basic data types cannot be changed.
  • If the self-managed Oracle database is an Oracle RAC database, you can only use a single virtual IP address (VIP) rather than a Single Client Access Name (SCAN) IP address when you configure the data synchronization task. After you specify the VIP, node failover of the Oracle RAC database is not supported.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.

Synchronize data from a MySQL database to a PostgreSQL database

Category Description
Limits on the source database
  • The tables to be synchronized 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 be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, 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 must be met:
    • The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, 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.
      Notice
      • If the source database is a self-managed MySQL database, you must enable binary logging and set binlog_format to row and binlog_row_image to full.
      • If the self-managed MySQL database is deployed in a dual-primary cluster, you must set log_slave_updates to ON. This ensures that DTS can obtain all binary logs. For more information, see Create an account for a user-created MySQL database and configure binary logging.

    • For an incremental data synchronization task, the binary logs of the source database are retained for at least 24 hours. For a schema and incremental data synchronization task, the binary logs of the source database are retained for at least seven days. After the schema is synchronized, 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 SLA of DTS does not ensure service reliability and performance. For more information about binary log files and log backup files of an ApsaraDB RDS for MySQL instance, see View and delete the binary log files of an ApsaraDB RDS for MySQL instance.

Other limits
  • Requirements for the objects to be synchronized:
    • Only tables can be selected as the objects to be synchronized.
    • DTS does not synchronize the following data types: BIT, VARBIT, GEOMETRY, ARRAY, UUID, TSQUERY, TSVECTOR, and TXID_SNAPSHOT.
    • Prefix indexes cannot be synchronized. If the source database contains prefix indexes, data may fail to be synchronized.
  • 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 increase the loads on the database servers.
  • 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.
  • If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized.

    If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Perform lock-free DDL operations.

  • 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, we recommend that you do not use DMS to perform online DDL operations. Otherwise, data loss may occur in the destination database.
Special cases
If the source database is a self-managed MySQL database, take note of the following items:
  • If you perform a primary/secondary switchover on the source database when the data synchronization task is running, the task fails.
  • DTS calculates synchronization latency based on the timestamp of the latest synchronized data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for a long time, the synchronization latency may be inaccurate. If the latency of the synchronization task is too high, you can perform a DML operation on the source database to update the latency.
    Note If you select an entire database as the object to be synchronized, you can create a heartbeat table. The heartbeat table is updated or receives data every second.