Notes and Constraints

Applicable Version

5.6, 5.7, and 8.x

Required Permissions

Synchronization objects

• DML operations INSERT, UPDATE, and DELETE can be synchronized.
• The DDL operation of adding columns can be synchronized.
• Only MyISAM and InnoDB tables can be synchronized.
• Views, foreign keys, stored procedures, triggers, functions, events, virtual columns, unique constraints, and unique indexes cannot be synchronized.
• Foreign keys that contain reference operations such as CASCADE, SET NULL, and SET DEFAULT cannot be synchronized. These operations will cause the update or deletion of rows in parent tables and affect records in child tables. Also, operations related to child tables are not recorded in Binlogs.

Database

The names of the source databases, tables, and fields cannot contain non-ASCII characters or the following characters: .<'>/\" (You are advised to use common characters to avoid a failure.)

Usage

• General:
  • During real-time synchronization, the IP addresses, ports, accounts, and passwords cannot be changed.
  • The source database cannot be restored.
  • Binlogs must be enabled for the source database and the value of binlog_row_image must be full.
  • It is recommended that MySQL binlogs be retained for more than three days. Binlogs cannot be forcibly cleared.

    When a job is restored after an exception, the recorded binlog location may expire. As a result, the job fails to be restored. It is important to monitor the duration of job exceptions and the binlog retention period.

  • During real-time synchronization, the source MySQL database cannot be upgraded across major versions. Otherwise, data may become inconsistent or the synchronization task may fail (data, table structures, and keywords may cause compatibility changes after the cross-version upgrade). You are advised to create a synchronization task again if the source MySQL database is upgraded across major versions.
  • Views, foreign keys, stored procedures, triggers, functions, events, virtual columns, unique constraints, and unique indexes cannot be synchronized.
  • Synchronizing tables that have no primary keys may cause duplicate data. Exercise caution when performing this operation.
  • If the source database is MySQL 8.0.23 or a later version and the data to be synchronized or migrated contains hidden columns, data in these columns may fail to be obtained and may be lost.
• Full synchronization phase:

  During task startup and full data synchronization, do not perform DDL operations on the source database. Otherwise, the task may fail.

• Incremental synchronization phase:
  • During incremental synchronization, executing non-idempotent DDL statements (for example, ALTER TABLE ddl_test ADD COLUMN c3 timestamp default now();) may cause data inconsistency.
  • During incremental synchronization, the following DDL types can be identified: creating a table, deleting a table, adding a column, deleting a column, renaming a table, renaming a column, modifying the column type, and clearing a table. For details about the DDL types supported by different links, see the notes and constraints of each link.
  • Foreign keys that contain reference operations such as CASCADE, SET NULL, and SET DEFAULT cannot be synchronized. These operations will cause the update or deletion of rows in parent tables and affect records in child tables. Also, operations related to child tables are not recorded in Binlogs.
  • The position cannot be set before DDL operations that involves table structure changes, such as table modification and column addition.
  • After incremental data is synchronized to Hudi MOR tables in MRS clusters earlier than 3.2.0-LTS1.5, CDM or Spark SQL cannot be used to write data. You need to perform compaction before writing data.
  • Database/Table sharding:

    In the database and table sharding scenario, you must stop service operations before renaming columns. Otherwise, data inconsistency may occur.

    In the database and table sharding scenario, you are advised to synchronize only the DDL for adding columns. If you synchronize other DDL operations, the job may fail or data may be inconsistent because the destination table has been modified.

    In the database and table sharding scenario, ensure that the types of columns to be added to each table are the same. Otherwise, the task may fail.

• Extraction from the standby database:

  Before extracting data from the standby database, ensure that a value can be returned after the SHOW MASTER STATUS command is executed on the standby database node. Otherwise, data jobs may be abnormal and data may be lost.

Other

Tables in the destination database can contain more columns than those in the source database. The following failures must be avoided:

Assume that extra columns in the destination database cannot be null and have no default values. If newly inserted data records are synchronized from the source database to the destination database, the extra columns will become null, which does not meet the requirements of the destination database and will cause the task to fail.

Applicable Version

Enterprise Edition 2016, 2017, 2019, and 2022; Standard Edition 2016 SP2 and later, 2017, 2019, and 2022

Required Permissions

sysadmin or view server state permissions, and db_datareader or db_owner permissions of the database to be synchronized

• Enable CDC for a database and a table.
  1. Enable CDC for a database.

     USE YourDatabaseName;
     EXEC sys.sp_cdc_enable_db; 
     -- Check whether CDC is enabled for a database.
     SELECT is_cdc_enabled, name FROM sys.databases WHERE name = 'YourDatabaseName'

  2. Enable CDC for a table.

     EXEC sys.sp_cdc_enable_table
          @source_schema = N'dbo', -- Schema
          @source_name = N'YourTable',-- Table name    
          @role_name = NULL,-- (Optional) CDC access role name    
          @supports_net_changes = 0;
     -- Check whether CDC is enabled for the table.
     SELECT name,is_tracked_by_cdc FROM sys.tables WHERE name = 'YourTable';

• The following permissions for the SQL Server must be granted to the user configured in the data connection:
  • Grant the CONNECT and VIEW DATABASE STATE permissions to the user.

    USE YourDatabaseName;
    GRANT CONNECT, VIEW DATABASE STATE TO [YourUserName];

  • Grant the SELECT permissions on the CDC schema to the user.

    USE YourDatabaseName;
    GRANT SELECT ON SCHEMA::[cdc] TO [YourUserName]; 

  • Grant the SELECT permissions on the table to the user.

    USE YourDatabaseName;
    GRANT SELECT ON OBJECT::[YourSchema].[YourTable] TO [YourUserName];

Synchronization objects

• DML operations INSERT, UPDATE, and DELETE can be synchronized.
• DDL operations cannot be synchronized.
• Only primary key tables can be synchronized.
• Transparent Data Encryption (TDE) encrypted databases in the source instance cannot be synchronized.
• Column encryption is not supported.
• Auto-increment columns cannot be synchronized.
• Table structures, common indexes, constraints (primary key, null, and non-null), and comments cannot be synchronized during automatic table creation.

Database

If Force Protocol Encryption is set to Yes for the source database, Trust Server Certificate also must be set to Yes.

Usage

• General: During real-time synchronization, the IP addresses, ports, accounts, and passwords cannot be changed.
• Full synchronization: During task startup and full data synchronization, do not perform DDL operations on the source database. Otherwise, the task may fail.
• Incremental synchronization phase:
  • DML operations INSERT, UPDATE, and DELETE can be synchronized.
  • DDL operations performed on the source database will not be synchronized to the destination database.
  • The IMAGE, TEXT, and NTEXT big data types cannot be deleted.
  • Tables in a job cannot be modified during synchronization.

Other

• Tables in the source database can contain more or less columns than those in the destination database. However, task failures may occur in the following scenarios:
  • Assume that extra columns in the destination database cannot be null and have no default values. If newly inserted data records are synchronized from the source database to the destination database, the extra columns will become null, which does not meet the requirements of the destination database and will cause the task to fail.
  • Assume that extra columns in the destination database must be fixed at a default value and have a unique constraint. If newly inserted data records are synchronized from the source database to the destination database, the extra columns will contain default values. That does not meet the requirements of the destination database.
• Do not perform primary/standby switchover on the source database. Otherwise, the synchronization task will fail.
• Source Microsoft SQL Server databases using TLS 1.0 or TLS 1.1 cannot be synchronized. To enable synchronization of such databases, you are advised to upgrade the protocol used by the databases to TLS 1.2 or later.

Applicable Version

PostgreSQL 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, and 16

Required Permissions

Synchronization objects

• DML operations INSERT, UPDATE, and DELETE can be synchronized.
• DDL operations cannot be synchronized.
• Only primary key tables can be synchronized.
• Views, foreign keys, stored procedures, triggers, functions, events, virtual columns, unique constraints, and unique indexes cannot be synchronized.
• Unlogged tables, temporary tables, system schemas, and system tables cannot be synchronized.
• Table structures, common indexes, constraints (primary key, null, and non-null), and comments cannot be synchronized during automatic table creation.

Database

• The partition table trigger of the source database cannot be set to disable.
• If incremental synchronization is required, the pg_hba.conf file of the source database contains the following configuration:

  host replication all 0.0.0.0/0 md5

Usage

• General:
  • During real-time synchronization, the IP addresses, ports, accounts, and passwords cannot be changed.
  • The WAL logs of the PostgreSQL database should be retained for more than three days.
  • Source tables must be published in dbz_publiction. Use "select * from pg_publication_tables;" to query the PUBLICATION of all tables and use "ALTER PUBLICATION name ADD TABLE [ ONLY ] table_name [ * ] [, ...]" to add the tables to the publish list.
• Full synchronization phase:

  During task startup and full data synchronization, do not perform DDL operations on the source database. Otherwise, the task may fail.

• Incremental synchronization phase:
  • Do not change the primary key or unique key (if the primary key does not exist) of the source database table. Otherwise, incremental data may be inconsistent or the task may fail.
  • Do not modify the replica identity attribute of tables in the source database. Otherwise, incremental data may be inconsistent or the task may fail.
  • When the number of replication slots of the PostgreSQL data source has reached the upper limit, new jobs cannot be executed. You can increase the upper limit of the number of replication slots by setting max_replication_slots or manually delete replication slots (automatic deletion is not supported). For details about how to delete replication slots, see

Other

• Before starting the job, ensure that no long transaction is started in the source database. If a long transaction is started in the source database, the creation of the logical replication slot will be blocked. As a result, the task fails.
• After the job is started, the active/standby switchover is not allowed for the source database.
• Tables in the destination database can contain more columns than those in the source database. The following failures must be avoided:
  • Assume that extra columns in the destination database cannot be null and have no default values. If newly inserted data records are synchronized from the source database to the destination database, the extra columns will become null, which does not meet the requirements of the destination database and will cause the task to fail.
  • Assume that extra columns in the destination database must be fixed at a default value and have a unique constraint. If newly inserted data records are synchronized from the source database to the destination database, the extra columns will contain default values. That does not meet the requirements of the destination database.

Applicable Version

10, 11, 12, and 19

Required Permissions

The account must have the permissions to archive logs, query tables, and parse logs of the Oracle database. For details about how to grant the permissions, see .

Synchronization objects

• The following DML operations can be synchronized: INSERT, UPDATE, and DELETE.
• The DDL operation of adding columns can be synchronized.
• Only primary key tables can be synchronized.
• Views, foreign keys, stored procedures, triggers, functions, events, virtual columns, unique constraints, unique indexes, foreign key indexes, and check constraints cannot be synchronized.
• Table structures, common indexes, constraints (primary key, null, and non-null), and comments cannot be synchronized during automatic table creation.

Database

The names of the source databases, tables, and fields cannot contain periods (.), hyphens (-), or non-ASCII characters. You are advised to use common characters to avoid a failure.

Usage

• Driver package installation:
• General:
  • During real-time synchronization, the IP addresses, ports, accounts, and passwords cannot be changed.
  • It is recommended that Oracle archive logs be retained for more than three days. Otherwise, the task may fail because logs cannot be obtained. In some special cases, data may be inconsistent or lost.
  • resetlogs operations cannot be performed on the source Oracle database. Otherwise, data cannot be synchronized, and the job cannot be recovered.
  • The username (schema name) of the source Oracle database cannot be changed, neither by modifying the USER$ dictionary table in versions earlier than 11.2.0.2 nor by running the ALTER USER username RENAME TO new_username command in 11.2.0.2 and later versions.
  • If the source is an Oracle database, CLOB, NCLOB, and BLOB data cannot be migrated.
  • Oracle RAC clusters cannot be the source.
  • If the source is an Oracle database, it can connect to the standby Oracle database of a single instance but cannot connect to a standby database in an RAC cluster. Only archive logs can be read from the standby database, and standby logs cannot be read from the standby database. When connecting to the standby database, you are advised to configure scheduled archiving to reduce the data synchronization latency.
  • It is recommended that the network bandwidth be greater than 100 Mbit/s.
• Full synchronization phase:

  During task startup and full data synchronization, do not perform DDL operations on the source database. Otherwise, the task may fail.

• Incremental synchronization phase:
  • DML operations INSERT, UPDATE, and DELETE can be synchronized.
  • The DDL operation of adding columns can be synchronized.
  • Mixed partitioned tables are not supported. When data in the external partition of a mixed partitioned table changes, no DML log is generated. As a result, the change information cannot be obtained during incremental data synchronization, which may cause data inconsistency.
  • The table name and column name can contain a maximum of 30 characters. Oracle LogMiner is used to read Oracle logs. The table name and column name can contain a maximum of 30 characters. For details, see Using LogMiner to Analyze Redo Log Files.
  • During incremental startup, select a time point. Ensure that the Oracle database is in the same time zone as the host where the database is located to ensure the accuracy of the incremental time point.
  • Distributed transactions (XA transactions) and PARALLEL DML on Oracle cannot be incrementally synchronized.
  • During incremental synchronization, Oracle extended characters are not supported. The standard character set cannot parse Oracle customized extended characters.
  • During incremental synchronization, triggers cannot be synchronized or migrated. You must disable the triggers on the destination Oracle database.
  • Data with foreign key constraints cannot be incrementally synchronized or migrated.
  • Data imported to the source database using Oracle Data Pump cannot be incrementally synchronized or migrated.

Other

• Tables in the destination database can contain more columns than those in the source database. The following failures must be avoided:
  • If extra columns in the destination database are not null and have no default values, when newly inserted data records are synchronized from the source database to the destination database, the extra columns will become null, which does not meet the requirements of the destination database.
  • Assume that extra columns in the destination database must be fixed at a default value and have a unique constraint. If newly inserted data records are synchronized from the source database to the destination database, the extra columns will contain default values. That does not meet the requirements of the destination database.
• During incremental synchronization from the PDB database, all PDBs must be enabled due to restrictions of Oracle LogMiner.
• For a full and incremental job or an incremental job that migrates data from an Oracle database, if you want to synchronize tables in the PDB database, you need to enter the username and password of the CDB database in the Oracle connection. This is because Oracle logs are stored in the CDB database and Oracle LogMiner can run only in the CDB database.
• To delete a table using DDL, run the drop table test_table_name purage command.

  Deleting a table in the Oracle database is a high-risk operation by default. When the drop table test_table_name command is executed, the Oracle database converts the command to rename table test_table_name asxxxxx. That is, the table is renamed as a table to be processed in the Oracle temporary tablespace. The original table is not deleted, and DataArts Migration ignores the syntax by default. The data deletion statement drop table test_table_name purage of the Oracle database completely deletes the table. DataArts Migration automatically identifies and delivers the deleted table to the downstream.

• Tables with no primary keys are not supported.
• Data control language (DCL) operations are not supported.
• Consecutive RENAME TABLE operations cannot be synchronized or migrated. Otherwise, the task may fail.
• Global temporary tables cannot be synchronized or migrated (the task is running properly).
• Tables that contain default value functions cannot be synchronized or migrated. Otherwise, data will be inconsistent.
• Tables with default values that contain expressions cannot be synchronized or migrated.
• Foreign tables cannot be synchronized or migrated.
• Compute columns and encrypted columns cannot be synchronized or migrated.
• Virtual private databases (VPDs) cannot be synchronized or migrated.
• Jobs created by dbms_scheduler and dbms_job cannot be synchronized or migrated.
• Schema name changes cannot be synchronized or migrated.
• Nested tables cannot be synchronized or migrated. Otherwise, an error will occur.
• Materialized views cannot be synchronized or migrated.
• DDL operations with attribute names that contain keywords or special characters cannot be synchronized or migrated.
• ROWID change operations (such as split partition, table move, table shrink, and move partition key) are not supported. Otherwise, data inconsistency or task failures may occur.
• The Secure Sockets Layer (SSL) encryption transmission mode is not supported.
• The Oracle Label Security mode is not supported.

Applicable Version

Kernel engine versions: 505.1.0, 505.1.0.SPC0100, and 505.2.0

Required Permissions

1. The REPLICATION permission or the permissions inherited from the built-in role gs_role_replication, the CONNECT permission of databases, USAGE permission of schemas, and SELECT permission of tables and sequences
2. Remote connection permission

   To add the remote connection permission, perform the following steps:

   • Centralized: Add host all <user> 0.0.0.0/0 sha256 and host replication <user> 0.0.0.0/0 sha256 to the gs_hba.conf configuration file of the source database.
   • Distributed: Add host all <user> 0.0.0.0/0 sha256 to the gs_hba.conf configuration file of the CN node of the source database. Add host all <user> 0.0.0.0/0 sha256 and host replication <user> 0.0.0.0/0 sha256 to the gs_hba.conf configuration file of the DN node of the source database.
   • Run select pg_reload_conf(); in the source database as the system administrator, or restart the DB instance to apply the changes.
3. Ensure that the corresponding connection ports are enabled in the security group and firewall policies.

   Security group and firewall policies: Common and replication connection ports are enabled for database connections.

   Centralized: The replication connection port number is the common connection port number plus 1.

   Distributed: The replication connection port number is the CN/DN connection port number plus 1. You can run the select * from pgxc_node statement in the source database to obtain the DN connection port.

Synchronization objects

• DML operations INSERT, UPDATE, and DELETE can be synchronized.
• DDL operations cannot be synchronized.
• Only primary key tables can be synchronized.
• Views, foreign keys, stored procedures, triggers, functions, events, virtual columns, unique constraints, and unique indexes cannot be synchronized.
• Unlogged tables, temporary tables, system schemas, and system tables cannot be synchronized.
• Table structures, common indexes, constraints (primary key, null, and non-null), and comments cannot be synchronized during automatic table creation.

Database

• Source database parameter requirements:
  • The password_encryption_type parameter is set to 1. Change the password to make it take effect.
  • The wal_level parameter is set to logical.
  • The value of parameter max_replication_slots must be greater than the number of used replication slots. You can determine the value based on the number of real-time jobs to be created.
• The names of the databases, schemas, and tables to be synchronized cannot contain /<.>\\'`|\?!, and the column names cannot be any fields forbidden in the destination database. You are advised to use common characters to avoid task failures.
• The partition table trigger of the source database cannot be set to disable.

Usage

• General:
  • During real-time synchronization, the IP addresses, ports, accounts, and passwords cannot be changed.
  • The WAL logs of the GaussDB database should be retained for more than three days.
• Full synchronization phase:

  During task startup and full data synchronization, do not perform DDL operations on the source database. Otherwise, the task may fail.

• Incremental synchronization phase:
  • Do not change the primary key or unique key (if the primary key does not exist) of the source database table. Otherwise, incremental data may be inconsistent or the task may fail.
  • Do not modify the replica identity attribute of tables in the source database. Otherwise, incremental data may be inconsistent or the task may fail.
  • When the number of replication slots of the GaussDB data source has reached the upper limit, new jobs cannot be executed. You can increase the upper limit of the number of replication slots by setting max_replication_slots or manually delete replication slots (automatic deletion is not supported). For details about how to delete replication slots, see

Other

• Before starting the job, ensure that no long transaction is started in the source database. If a long transaction is started in the source database, the creation of the logical replication slot will be blocked. As a result, the task fails.
• After the job is started, the active/standby switchover is not allowed for the source database.

Applicable Version

• MRS cluster (3.2.0-LTS.x and 3.5.x)
• Hudi (0.11.0)

Required Permissions

The MRS user must have read and write permissions for the Hadoop and Hive components. You are advised to assign the roles and user groups shown in the following figure to the MRS user.

Figure 1 Minimal permissions for MRS Hudi

For details, see .

Database

The names of the Hudi databases, tables, and fields can only contain digits, letters, and underscores (_). Field names must start with a letter or an underscore (). You are advised to use common characters in names.

Usage

• General:
  • During real-time synchronization, the MRS accounts and passwords cannot be changed.
  • During real-time synchronization, if the MRS Hadoop component or role is stopped or restarted, the Hadoop component may be unavailable for a short period of time. As a result, the real-time synchronization task is abnormal.
  • Ensure that the Hudi parameters are supported by Flink on Hudi. Otherwise, the task may fail.

    Some Spark on Hudi parameters are not applicable in the Flink on Hudi scenario or the parameter names are inconsistent.

  • After incremental data is synchronized to Hudi MOR tables in MRS clusters earlier than 3.2.0-LTS1.5 through a real-time synchronization task (Flink), CDM or Spark SQL cannot be used to write data. You need to perform compaction before writing data.
• Create a table.
  • Do not update the partition fields of a Hudi table. Otherwise, there will be data with the same primary key in different partitions in the soft deletion scenario. Choose columns with stable field values as Hudi partition fields.
  • Real-time synchronization tasks only support Hudi tables with three audit fields: cdc_last_update_date (timestamp), logical_is_deleted (Boolean), and _hoodie_event_time (string). You need to add the three audit fields when creating a table. Otherwise, the task will be abnormal.
  • If a field name contains uppercase letters during manual creation of a Hudi table, ensure that the name and case of the field are the same as those of the corresponding field in the source table. Otherwise, the job will be abnormal or the data will be null after migration.

    When a real-time synchronization job automatically creates a Hudi table, the field names of the table are lowercase letters.

• Job stability:
  • The memory overhead of a Hudi table with BLOOM indexes is high, and the job is unstable. You are advised to use BUCKET indexes to create a table.
  • Real-time compaction consumes a large amount of memory, and the job is unstable. Therefore, you are advised to use offline compaction.
• Changelog tables:

  If changelogs are enabled for Hudi and data is lost, downstream Flink jobs must be restarted after data is patched using a Spark or Flink job. Otherwise, changelogs may be lost and Flink status may be abnormal.

  Currently, data cannot be patched at the operation level (-U, +U, +I, and -D data) for Hudi changelog tables. Instead, data patching can only ensure data consistency during Spark query, but cannot ensure the consistency of data read by Flink streams.

• DDL synchronization:
  • DDL operations (for example, ALTER TABLE ddl_test ADD COLUMN c2 AFTER/FIRST c1;) for adding columns to a specified position are not supported. The AFTER/FIRST attribute will be deleted, which may cause column sequence inconsistency.
  • Executing non-idempotent DDL statements (for example, ALTER TABLE ddl_test ADD COLUMN c3 timestamp default now();) may cause data inconsistency.
  • The following DDL operations can be identified: creating a table, deleting a table, adding a column, deleting a column, renaming a table, renaming a column, modifying a column type, and clearing a table. Only column adding operations can be synchronized to the destination Hudi database. You can set the processing policy for the other DDL operations to Ignore or Error.
    • In the database and table sharding scenario, ensure that the types of columns to be added to each table are the same. Otherwise, the task may fail.
    • If the column type is changed, a column is deleted, or a column is renamed at the source, you must stop the real-time synchronization task in a timely manner and use Spark SQL to update the DDL of the Hudi table. Otherwise, the job will fail or data inconsistency will occur.
    • The column name can contain no more than 256 characters. Otherwise, the task fails.

Applicable Version

8.1.3, 8.2.0, or a later version, except GaussDB(DWS) 3.0

Required Permissions

Table permissions: The account must have the INSERT, SELECT, UPDATE, DELETE, CONNECT, and CREATE permissions on the destination table.

Database

The name of an object in the database must contain 1 to 63 characters, start with a letter or underscore (_), and can contain letters, digits, underscores (_), and dollar signs ($).

Usage

• General:
  • During real-time synchronization, the IP addresses, ports, accounts, and passwords cannot be changed.
  • Data cannot be synchronized to GaussDB(DWS) tables that have no primary keys.
  • GaussDB(DWS) column-store tables cannot be concurrently synchronized because there are distributed locks. Concurrent updates may cause locks or deadlocks. You are advised to use GaussDB(DWS) row-store tables or hybrid row- and column-store tables. For details, see the GaussDB(DWS) documentation.
• Full synchronization phase:

  During task startup and full data synchronization, do not perform DDL operations on the source database. Otherwise, the task may fail.

• Incremental synchronization phase:
  • During incremental synchronization, DDL operations (for example, ALTER TABLE ddl_test ADD COLUMN c2 AFTER/FIRST c1;) for adding columns to a specified position are not supported. The AFTER/FIRST attribute will be deleted, which may cause column sequence inconsistency.
  • During incremental synchronization, executing non-idempotent DDL statements (for example, ALTER TABLE ddl_test ADD COLUMN c3 timestamp default now();) may cause data inconsistency.
  • During incremental synchronization, database-level synchronization does not support online DDL operations, and table-level synchronization supports only online DDL operations generated by DMS on some clouds.
  • During incremental synchronization, the following DDL operations can be synchronized: creating tables, deleting tables, adding columns, deleting columns, renaming tables, renaming columns, changing the column type, and clearing tables. You can select the DDL types to be synchronized as needed.
    • In the database and table sharding scenario, you must stop service operations before renaming columns. Otherwise, data inconsistency may occur.
    • In the database and table sharding scenario, you are advised to synchronize only the DDL for adding columns. If you synchronize other DDL operations, the job may fail or data may be inconsistent because the destination table has been modified.
    • In the database and table sharding scenario, ensure that the types of columns to be added to each table are the same. Otherwise, the task may fail.
    • The name of a table or column to be added or modified can contain no more than 63 characters. Otherwise, the job will fail.
    • During incremental migration, when CHANGE COLUMN is executed in the source database to modify a column which is a distribution column in the destination GaussDB(DWS) database, an exception may occur because distribution columns in GaussDB(DWS) databases cannot be modified.

Other

• Tables in the destination database can contain more columns than those in the source database. The following failures must be avoided:
  • Assume that extra columns in the destination database cannot be null and have no default values. If newly inserted data records are synchronized from the source database to the destination database, the extra columns will become null, which does not meet the requirements of the destination database and will cause the task to fail.
  • Assume that extra columns in the destination database must be fixed at a default value and have a unique constraint. If newly inserted data records are synchronized from the source database to the destination database, the extra columns will contain default values. That does not meet the requirements of the destination database.
• During automatic table creation, the length of the char, varchar, nvarchar, enum, and set characters in the source database is automatically increased by byte in the destination GaussDB(DWS) database.
• During full synchronization of timestamp data, the on update current_timestamp syntax in the default value will not be synchronized to the destination GaussDB(DWS) database.
• Only DDL operations (for example, RENAME TABLE A TO B, in which B must be within the synchronization scope) can be performed to rename tables only if the renamed tables are within the synchronization scope.

  You are not advised to perform rename operations in the database and table synchronization scenario. Otherwise, the task may fail or data may be inconsistent.