Data Replication supports only Audit Apply mode for Kafka targets.

InitialSync is not supported for Kafka targets.

Data Replication does not replicate DDL changes, including TRUNCATE TABLE operations, to Kafka targets.

Data Replication does not support SQL expressions for Kafka targets.

Data Replication does not support the following replication topologies for Kafka targets: bidirectional replication, cascade replication, and replication from one source to multiple targets.

Data Replication sends a single stream of messages that contain change data in commit order to Kafka targets. On the

Runtime Settings

tab >

General

view in the Data Replication Console, the only valid value for the

Applier threads

field is 1.

The Kafka Applier uses the Java-based CDC Publisher component as an intermediary tool to process and format change data from a source database into Avro messages. Data Replication provides the required CDC Publisher library files in the

DataReplication_installation

/lib subdirectory.

Data Replication supports only the following primitive Avro datatypes in Kafka messages:

NULL
BOOLEAN
INT
LONG
BYTES
STRING

Data Replication does not support the use of the FLOAT or DOUBLE primitive Avro datatypes. The Applier converts all source data to characters in Kafka messages. Converting from a source FLOAT or DOUBLE datatype to characters and then to an Avro FLOAT or DOUBLE datatype might decrease data accuracy and precision.

To minimize the risk of duplicated or missing messages on the Kafka target after a network outage occurs, the apply.kafka.kafka_producer_guarantee_delivery runtime parameter is enabled by default. Guaranteed delivery provides the highest level of data integrity but might degrade performance. To disable guaranteed delivery, set the apply.kafka.kafka_producer_guarantee_delivery runtime parameter to 0. With this setting, duplicate messages might occur on the Kafka target after you restart apply processing following an outage. The duplicate messages will have identical values for the OP_CMT_SCN (commit point) and OP_NUM_IN_TX (transaction ID) calculated columns in each message.

For Apache Kafka targets, the Applier saves the sequence of the last change operation successfully sent to the target as a "checkpoint" to a checkpoint file, provided that you use the default guaranteed delivery mode. If you do not use guaranteed delivery, the Applier writes a checkpoint after each Commit operation. The checkpoint file must exist on the system where the Applier, the CDC Publisher, and a Server Manager instance (Main server or subserver) run. You can change the checkpoint file name or directory by editing the apply.kafka.kafka_checkpoint_file_directory and apply.kafka.kafka_checkpoint_file_name runtime parameters. By default, the checkpoint file name matches the configuration name.

All Update operations that the Applier commits to Kafka targets generate UPDATE_EVENT messages in the Kafka topics, including Update operations that affect unmapped source columns or that result in no changes.