Page History

...

Integrating with tiered storage would allow mirroring to handle data that has been offloaded to remote storage (e.g., S3, HDFS), enabling full replication of topics with long retention periods without requiring all data to reside in local broker storage. During the PREPARING state, the mirror truncates the local log to the LME. This operation does not support tiered storage on the destination cluster because LME may be moved to remote segments.

When tiered storage is enabled locally for a mirror topic, its partitions transition to FAILED state. This limitation applies only to the destination cluster during PREPARING phase, and will be removed once tiered storage truncation will be fully supported. A detailed design of the metadata synchronization protocol, API schema, and state management will be provided in a follow-up KIP.

...

Active-active topology is not initially supported in Cluster Mirroring, though it could potentially be achieved through topic prefixing and removing the reliance on topic ID for mirroring. This is a candidate for a future improvement KIP. Instead, bidirectional mirroring is supported, but only when mirroring different topics between clusters, allowing records produced to either cluster to be consumed from both. Unlike MirrorMaker 2, Cluster Mirroring does not need special cycle detection or prevention logic because the read-only enforcement inherently blocks the conditions that would create infinite replication loops.

Streams Applications

Stateful Kafka Streams rely on internal topics (changelogs, repartition topics, offset tracking) that are tightly coupled through atomic transactions. A single EOS transaction spans input offset commits, state store mutations written to changelog topics, and intermediate records written to repartition topics. Cluster mirroring replicates topics asynchronously and independently, so it cannot preserve these transactional boundaries. This means internal topics on the destination cluster can end up at inconsistent points in time relative to each other, making state store recovery produce incorrect results. The synchronous mirroring extension would preserve these guarantees. For this reason, mirroring of Kafka Streams internal topics is not  supported.

Synchronous Mirroring

Currently, mirroring is asynchronous. The source cluster acknowledges the producer without waiting for the destination to replicate the data. Synchronous mirroring would guarantee that records are replicated to the destination cluster before the source acknowledges the produce request, providing stronger durability guarantees at the cost of higher latency. This would be useful for workloads where zero data loss across clusters is a strict requirement.

...