skip to content

What is IdentityReplicationPolicy, and what trade-off do you accept by using it instead of DefaultReplicationPolicy?

level: middleimportance: must knowfreq 60%

answer

  1. no prefix, same name
  2. replication.policy.class = Identity...
  3. active/passive DR only
  4. loses cycle detection
  5. KIP-690, replaces Legacy

basics

~20 s

IdentityReplicationPolicy replicates topics keeping their original name (no source-cluster prefix), so 'orders' stays 'orders' on the destination. The trade-off: you lose automatic cycle detection and risk name collisions, so it's only safe for unidirectional (active/passive) replication.

solid answer

~40 s

IdentityReplicationPolicy is a built-in MM2 ReplicationPolicy that does NOT rename replicated topics — 'orders' on the source stays 'orders' on the destination, unprefixed. You set it via `replication.policy.class=org.apache.kafka.connect.mirror.IdentityReplicationPolicy`. It's commonly chosen for migrations and active/passive DR where consumers should fail over without changing topic names. The cost is that the prefix that DefaultReplicationPolicy relies on for cycle detection is gone, so MM2 can no longer tell a record's origin from the name. That makes it unsafe for active/active or any bidirectional/looping topology — you'd risk infinite replication loops and topic-name collisions when multiple sources feed one destination. It effectively replaces the older deprecated LegacyReplicationPolicy and is the modern way to get 'same-name' replication.

go deeper

for a junior

Know it keeps the original topic name (no us-west. prefix).

for a middle

Set it via replication.policy.class and explain it's for active/passive DR / migrations.

for a senior

Articulate the cycle-detection and collision trade-offs and why it's unsafe for bidirectional topologies.

for a principal

Decide policy per topology, weigh failover ergonomics vs. loop-safety, and know it stems from KIP-690 superseding LegacyReplicationPolicy.

## ReplicationPolicy — the pluggable naming brain MM2 delegates all topic-naming decisions to an implementation of the `ReplicationPolicy` interface (set via `replication.policy.class`). Two are built in: `DefaultReplicationPolicy` (source-prefixed) and `IdentityReplicationPolicy` (no prefix). ## What IdentityReplicationPolicy does It is the identity function on names: a replicated topic keeps its original name. Replicate `orders` from `us-west` to the DR cluster and it lands as `orders`, not `us-west.orders`. Configure it with: ``` replication.policy.class=org.apache.kafka.connect.mirror.IdentityReplicationPolicy ``` ## Why you'd want it - **Seamless failover / migration**: consumers and producers move to the destination cluster without rewriting topic names or subscription patterns. This is the classic active/passive DR shape and the 'lift-and-shift cluster migration' use case. - **Tooling simplicity**: dashboards, schemas, and naming conventions that key off the topic name don't have to special-case prefixes. ## What you give up DefaultReplicationPolicy's source prefix carries information: where the topic came from. IdentityReplicationPolicy throws that away. Consequences: 1. **No cycle detection by name.** MM2's loop-prevention in active/active relies on reading the source prefix. With identity naming, a record replicated A→B looks indistinguishable from a native B topic, so a B→A flow could ship it straight back — an infinite loop. 2. **Collisions.** If two source clusters both have `orders` and both replicate into one destination with identity naming, they'd target the same destination topic and stomp on each other. ## When it is and isn't safe - Safe: strictly unidirectional, single-source-per-topic flows (active/passive DR, one-way migration). - Unsafe: active/active, fan-in from multiple sources of the same topic, or any topology where a topic can loop. There you want DefaultReplicationPolicy (or a custom policy with its own cycle-safe scheme). ## Historical note IdentityReplicationPolicy (introduced via KIP-690) supersedes the older `LegacyReplicationPolicy`/`MirrorMakerConfig` hacks that earlier provided unprefixed names; LegacyReplicationPolicy is deprecated. ## Edge case: internal topics Even with IdentityReplicationPolicy, MM2 still filters internal/system topics (consumer-offsets, MM2 heartbeats/checkpoints, transaction state) so they aren't replicated as ordinary data topics.

  • Why is IdentityReplicationPolicy unsafe for active/active replication?
    Without the source prefix, MM2 can't tell a record's origin from the topic name, so it loses name-based cycle detection — a topic can be replicated back to its origin in an infinite loop, and same-named topics from different sources collide.
  • Which property selects this policy?
    replication.policy.class set to org.apache.kafka.connect.mirror.IdentityReplicationPolicy.

saying these in an interview costs you the question

  • Claiming IdentityReplicationPolicy is fine for active/active (it isn't — no cycle detection)
  • Confusing it with just setting an empty separator (that's not the same and is fragile)
  • Saying it's the default (DefaultReplicationPolicy is the default)

context

resolving links…