Hi Fede and friends, Thanks for the KIP. It’s a comprehensive design, easy to read and has clearly taken a lot of work. The principle of integrating mirroring into the brokers makes total sense to me.
The main comment I have is that mirroring like this cannot handle situations in which multiple topic-partitions are logically related, such as transactions, with total fidelity. Each topic-partition is being replicated as a separate entity. The KIP calls this out and describes the behaviour thoroughly. A few initial comments. AS1) Is it true that offsets are always preserved by this KIP? I *think* so but not totally sure that it’s true in all cases. It would certainly be nice. AS2) I think you need to add epoch information to AlterShareGroupOffsetsRequest. It really should already be there in hindsight, but I think this KIP requires it. AS3) The CoordinatorType enum for MIRROR will need to be 3 because 2 is SHARE. I’m sure you’ll parse the keys from the right ;) AS4) The procedure for achieving a failover could be clearer. Let’s say that I am using cluster mirroring to achieve DR replication. My source cluster is utterly lost due to a disaster. What’s the single operation that I perform to switch all of the topics mirrored from the lost source cluster to become the active topics? Similarly for failback. AS5) The only piece that I’m really unsure of is the epoch management. I would have thought that the cluster which currently has the writable topic-partition would be in charge of the leader epoch and it would not be necessary to perform all of the gymnastics described in the section on epoch rewriting. I have read the Rejected Alternatives section too, but I don’t fully grasp why it was necessary to reject it. I wonder if we could store the “polarity” of an epoch, essentially whether the epoch bump was observed by replication from a source cluster, or whether it was bumped by a local leadership change when the topic is locally writable. When a topic-partition switches from read-only to writable, we should definitely bump the epoch, and we could record the fact that it was a local epoch. When connectivity is re-established, you might find that both ends have declared a local epoch N, but someone has to win. Thanks, Andrew > On 14 Feb 2026, at 07:17, Federico Valeri <[email protected]> wrote: > > Hi, we would like to start a discussion thread about KIP-1279: Cluster > Mirroring. > > Cluster Mirroring is a new Kafka feature that enables native, > broker-level topic replication across clusters. Unlike MirrorMaker 2 > (which runs as an external Connect-based tool), Cluster Mirroring is > built into the broker itself, allowing tighter integration with the > controller, coordinator, and partition lifecycle. > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1279%3A+Cluster+Mirroring > > There are a few missing bits, but most of the design is there, so we > think it is the right time to involve the community and get feedback. > Please help validating our approach. > > Thanks > Fede
