Known issues and limitations for Data Replication

Some configuration parameters are ignored when replicating to IBM watsonx.data

Applies to: 5.1.0

Fixed in: 5.1.1

Problem: When you replicate data to IBM watsonx.data, Data Replication asset settings, such as replication data file prefix and thresholds that determine when and how Data Replication commits data, do not take effect.

In a PostgreSQL database, columns with a UUID datatype are not supported when replicating data to an IBM watsonx.data target data store

Applies to: 5.1.0

Fixed in: 5.1.1

Problem: In a PostgreSQL database, when you replicate a table with columns containing a UUID datatype to IBM watsonx.data, the replication job will fail to replicate the table.

Workaround: Avoid including any PostgreSQL tables with UUID columns when you replicate data to IBM watsonx.data.

New tables created without the CHANGE DATA CAPTURE flag enabled are not detected when the replication job is in the Running state

Applies to: 4.6.0 and later

Problem: When replication is running and a new table is created without the CHANGE DATA CAPTURE flag, the table is not replicated, even if the flag is later enabled using an ALTER TABLE statement.

Cause: When the replication job is running, changes to new tables are captured only if the CHANGE DATA CAPTURE flag is present in the initial CREATE TABLE statement.

Workaround: Make sure the CHANGE DATA CAPTURE flag is included in the CREATE TABLE statement when you add new tables while replication is running.

You cannot modify the structure of target tables outside of Data Replication

When you run a Data Replication asset that has the Copy business goal, Data Replication owns the maintenance of the target tables. You will not be able to modify the structure of these target tables outside of Data Replication. If Data Replication is in the process of applying a structural change to a table, that table might be temporarily locked for reads.

Parent topic: Service issues