Skip to content
Kafka Mobility Intelligence

Advanced Settings

The Advanced Settings step is shown only for MirrorMaker 2 and Replicator jobs. Cluster Link and Orbit include their advanced settings within the Core Configuration step instead.

These settings provide fine-grained control over replication behavior. They are optional and should be adjusted only when the defaults do not meet your performance, security, or compatibility requirements.

MirrorMaker 2 exposes eight categories of advanced configuration.

Configure Single Message Transforms (SMTs) applied to records as they flow through the MirrorMaker 2 connector. Transforms are a general Kafka Connect feature: you can add any SMT to the chain. One common use case is re-framing Cloudera-native serialized data so Confluent consumers on the destination can read it.

Transforms run as an ordered chain. The suite references transforms by class name only; the SMT jar must be installed on every Connect worker’s plugin path before the job starts (the suite does not deploy the jar). You can reorder transforms and check which transform classes are already installed on the Connect cluster from within the editor.

If your migration plan includes an SMT recommendation (generated when the source is Cloudera-native on a re-framing protocol), the plan pre-fills the Transforms section automatically when you create the job from the plan. You can edit the values before submitting.

SMT configuration fields:

FieldDescription
AliasLogical identifier for this transform (for example, reframe). Used in the connector’s transform chain keys.
Transform class (FQN)Fully qualified Java class name of the SMT implementation. For the Cloudera re-frame SMT, this is the class name from the sample source provided in the plan.
PropertiesKey-value pairs passed to the SMT. For protocol-specific re-framing, include any registry URL, metadata ID, or version ID lookup properties required by the SMT class.

Cloudera serde protocol guidance (applies when the source is Cloudera-native):

Cloudera Serde ProtocolRe-frame behavior
Protocol 0Confluent-compatible framing: no SMT needed.
Protocol 1Re-framing requires a metadata ID and version ID lookup. Include the lookup configuration in the transform properties.
Protocol 2 or 3Pure byte re-framing with no registry lookup.

Prerequisites for the Cloudera re-frame SMT:

  1. Build a jar from the sample SMT Java source available in the plan (or use your own implementation that matches the class name configured here).
  2. Install the jar on every Connect worker’s plugin path before starting the job.
  3. Scope the transform to an explicit Avro-topic allowlist or use a Connect predicate to exclude non-Avro topics and internal topics. A non-Avro value that happens to start with 0x01 must not be re-framed.