Data Transmission Service:Precautions and limits for synchronizing data from a Db2 for LUW database

Category

Description

Limits on the source database

• Bandwidth requirements: The server to which the source database belongs must have sufficient outbound bandwidth. Otherwise, the data synchronization speed is affected.

• The tables to be migrated 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 modify the tables in the destination database, such as renaming tables or columns, you can synchronize up to 5,000 tables in a single data synchronization task. If you run a task to synchronize more than 5,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• The data logging feature must be enabled. Otherwise, error messages are returned during precheck, and the data synchronization task cannot be started.

  Note

  If you perform only incremental data synchronization, the data logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the data logs of the source database must be stored for at least seven days. Otherwise, DTS may fail to obtain the data logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of data logs based on the preceding requirements. Otherwise, the service reliability or performance stated in the Service Level Agreement (SLA) of DTS cannot be guaranteed.

• The change data capture (CDC) feature must be enabled for the tables to be synchronized.

Other limits

• DTS synchronizes incremental data from a Db2 for LUW database to the destination database based on the CDC replication technology of Db2 for LUW. However, the CDC replication technology has its own limits. For more information, see General data restrictions for SQL Replication.

• 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 initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. Therefore, after initial full data synchronization is complete, the size of the used tablespace of the destination database is larger than that of the source database.

• 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. You can use Data Management (DMS) to perform online DDL operations after data synchronization is complete. For more information, see Perform lock-free DDL operations.

Special cases

You must take note of the following items because the source Db2 for LUW database is a self-managed database:

• 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.

Category

Description

Limits on the source database

• Bandwidth requirements: The server to which the source database belongs must have sufficient outbound bandwidth. Otherwise, the data synchronization speed is affected.

• The tables to be migrated 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 modify the tables in the destination database, such as renaming tables or columns, you can synchronize up to 5,000 tables in a single data synchronization task. If you run a task to synchronize more than 5,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• The data logging feature must be enabled. Otherwise, error messages are returned during precheck, and the data synchronization task cannot be started.

  Note

  If you perform only incremental data synchronization, the data logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the data logs of the source database must be stored for at least seven days. Otherwise, DTS may fail to obtain the data logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of data logs based on the preceding requirements. Otherwise, the service reliability or performance stated in the SLA of DTS cannot be guaranteed.

Other limits

• DTS synchronizes incremental data from a Db2 for LUW database to the destination database based on the CDC replication technology of Db2 for LUW. However, the CDC replication technology has its own limits. For more information, see General data restrictions for SQL Replication.

• 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 initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. Therefore, after initial full data synchronization is complete, the size of the used tablespace of the destination database is larger than that of the source database.

• 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. You can use DMS to perform online DDL operations after data synchronization is complete. For more information, see Perform lock-free DDL operations.

• AnalyticDB for MySQL V3.0 has limits on the usage of disk space. If the disk space usage of the nodes in an AnalyticDB for MySQL V3.0 cluster reaches 80%, the DTS task is delayed, and error messages are returned. We recommend that you estimate the required disk space based on the objects to be synchronized. Make sure that the destination cluster has sufficient storage space.

• AnalyticDB for MySQL V3.0 has strictly case-sensitive data.

Special cases

You must take note of the following items because the source Db2 for LUW database is a self-managed database:

• 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.

Category

Description

Limits on the source database

• Bandwidth requirements: The server to which the source database belongs must have sufficient outbound bandwidth. Otherwise, the data synchronization speed is affected.

• The tables to be migrated 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 modify the tables in the destination database, such as renaming tables or columns, you can synchronize up to 5,000 tables in a single data synchronization task. If you run a task to synchronize more than 5,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• The data logging feature must be enabled. Otherwise, error messages are returned during precheck, and the data synchronization task cannot be started.

  Note

  If you perform only incremental data synchronization, the data logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the data logs of the source database must be stored for at least seven days. Otherwise, DTS may fail to obtain the data logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of data logs based on the preceding requirements. Otherwise, the service reliability or performance stated in the SLA of DTS cannot be guaranteed.

Other limits

• DTS synchronizes incremental data from a Db2 for LUW database to the destination database based on the CDC replication technology of Db2 for LUW. However, the CDC replication technology has its own limits. For more information, see General data restrictions for SQL Replication.

• 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 initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. Therefore, after initial full data synchronization is complete, the size of the used tablespace of the destination database is larger than that of the source database.

• 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. You can use Data Management (DMS) to perform online DDL operations after data synchronization is complete. For more information, see Perform lock-free DDL operations.

Special cases

You must take note of the following items because the source Db2 for LUW database is a self-managed database:

• 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.

Category

Description

Limits on the source database

• Bandwidth requirements: The server to which the source database belongs must have sufficient outbound bandwidth. Otherwise, the data synchronization speed is affected.

• The tables to be migrated 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 modify the tables in the destination database, such as renaming tables or columns, you can synchronize up to 5,000 tables in a single data synchronization task. If you run a task to synchronize more than 5,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• The data logging feature must be enabled. Otherwise, error messages are returned during precheck, and the data synchronization task cannot be started.

  Note

  If you perform only incremental data synchronization, the data logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the data logs of the source database must be stored for at least seven days. Otherwise, DTS may fail to obtain the data logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of data logs based on the preceding requirements. Otherwise, the service reliability or performance stated in the SLA of DTS cannot be guaranteed.

Other limits

• DTS synchronizes incremental data from a Db2 for LUW database to the destination database based on the CDC replication technology of Db2 for LUW. However, the CDC replication technology has its own limits. For more information, see General data restrictions for SQL Replication.

• 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 initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. Therefore, after initial full data synchronization is complete, the size of the used tablespace of the destination database is larger than that of the source database.

• 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. You can use DMS to perform online DDL operations after data synchronization is complete. For more information, see Perform lock-free DDL operations.

Special cases

You must take note of the following items because the source Db2 for LUW database is a self-managed database:

• 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.

Category

Description

Limits on the source database

• Bandwidth requirements: The server to which the source database belongs must have sufficient outbound bandwidth. Otherwise, the data synchronization speed is affected.

• The tables to be migrated 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 modify the tables in the destination database, such as renaming tables or columns, you can synchronize up to 5,000 tables in a single data synchronization task. If you run a task to synchronize more than 5,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• The data logging feature must be enabled. Otherwise, error messages are returned during precheck, and the data synchronization task cannot be started.

  Note

  If you perform only incremental data synchronization, the data logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the data logs of the source database must be stored for at least seven days. Otherwise, DTS may fail to obtain the data logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of data logs based on the preceding requirements. Otherwise, the service reliability or performance stated in the SLA of DTS cannot be guaranteed.

Other limits

• DTS synchronizes incremental data from a Db2 for LUW database to the destination database based on the CDC replication technology of Db2 for LUW. However, the CDC replication technology has its own limits. For more information, see General data restrictions for SQL Replication.

• 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 initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. Therefore, after initial full data synchronization is complete, the size of the used tablespace of the destination database is larger than that of the source database.

• 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. You can use DMS to perform online DDL operations after data synchronization is complete. For more information, see Perform lock-free DDL operations.

• If you perform schema synchronization and incremental data synchronization, one or more foreign keys of the source database are not synchronized to the destination database.

Special cases

You must take note of the following items because the source Db2 for LUW database is a self-managed database:

• 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.

Category

Description

Limits on the source database

• Bandwidth requirements: The server to which the source database belongs must have sufficient outbound bandwidth. Otherwise, the data synchronization speed is affected.

• The tables to be migrated 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 modify the tables in the destination database, such as renaming tables or columns, you can synchronize up to 5,000 tables in a single data synchronization task. If you run a task to synchronize more than 5,000 tables, a request error occurs. In this case, we recommend that you configure multiple tasks to synchronize the tables in batches or configure a task to synchronize the entire database.

• The data logging feature must be enabled. Otherwise, error messages are returned during precheck, and the data synchronization task cannot be started.

  Note

  If you perform only incremental data synchronization, the data logs of the source database must be stored for more than 24 hours. If you perform both full data synchronization and incremental data synchronization, the data logs of the source database must be stored for at least seven days. Otherwise, DTS may fail to obtain the data logs and the task may fail. In exceptional circumstances, data inconsistency or loss may occur. After the full data synchronization is complete, you can set the retention period to more than 24 hours. Make sure that you set the retention period of data logs based on the preceding requirements. Otherwise, the service reliability or performance stated in the SLA of DTS cannot be guaranteed.

Other limits

• DTS synchronizes incremental data from a Db2 for LUW database to the destination database based on the CDC replication technology of Db2 for LUW. However, the CDC replication technology has its own limits. For more information, see General data restrictions for SQL Replication.

• 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 initial full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. Therefore, after initial full data synchronization is complete, the size of the used tablespace of the destination database is larger than that of the source database.

• 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. You can use Data Management (DMS) to perform online DDL operations after data synchronization is complete. For more information, see Perform lock-free DDL operations.

Special cases

You must take note of the following items because the source Db2 for LUW database is a self-managed database:

• 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.