Hi Jeroen, Thanks for looking into MM2 for your use-case!
I believe the "active-active" model that MM2 uses is really more of a pair of opposing "active-passive" replication flows, and this extends to the offset sync mechanism too. MM2 doesn't change the state of the source topic or consumer groups to avoid conflicting with existing producers & consumers. The functionality you're proposing could exist, but it has to resolve a couple of complications: 1. If there are additional producers to the downstream topic, downstream consumer offsets include records which don't exist upstream. This is technically already a problem with source->target offset replication, but if you're in a failover scenario it is possible that a new producer has started and the downstream topic has diverged from the source topic significantly. 2. Syncing to a consumer group requires that all consumers in that group be offline. If you were to sync the exact same group in both directions continuously, both groups would need to have all consumers offline. The closest supported solution for you would probably be to do a full round-trip replication (A -> B -> A and B -> A -> B) and write a ForwardingAdminClient plugin which transparently renames the consumer groups. And the best unsupported solution I could think of would be to fork the MirrorClient (which reads from the offset-syncs topic emitted by the plugin) and perform back-translation once during the fail-back with a script, when you know the original consumer group will be offline. Neither of those seem very good to me, so you may need to design your application around this design constraint or handle the "fail-back" state management with some other mechanism. Hope this helps, Greg Harris On Mon, Jan 8, 2024 at 7:10 AM Jeroen Schutrup <jer...@cloudflare.com.invalid> wrote: > > Hi all, > I'm exploring using the MirrorSourceConnector and MirrorCheckpointConnector > on Kafka Connect to setup active/active replication between two Kafka > clusters. Using the DefaultReplicationPolicy replication policy class, > messages originating from the source cluster get replicated as expected to > the cluster-prefixed topic in the target cluster. Consumergroup offsets > from the source to target cluster are replicated likewise. However, once > the consumer group migrates from the source to the target cluster, its > offsets are not replicated from the target back to the source cluster. > For an active/active setup I'd want consumer group offsets for topic > <source-cluster-alias>.<topic-name> in the target cluster to be replicated > back to <topic-name> in the source cluster. This would allow consumers to > failover & failback between clusters with minimal duplicate message > consumption. > > To clarify my setup a bit; I'm running two single-broker Kafka clusters in > Docker (cluster A & B), along with a single Connect instance on which I've > provisioned four source connectors: > - A MirrorSourceConnector replicating topics from cluster A to cluster B > - A MirrorSourceConnector replicating topics from cluster B to cluster A > - A MirrorCheckpointConnector translating & replicating offsets from > cluster A to cluster B > - A MirrorCheckpointConnector translating & replicating offsets from > cluster B to cluster A > > I'm not sure whether this is by design, or maybe I'm missing something. > I've seen a similar question posted to KAFKA-9076 [1] without a resolution. > > Regards, > Jeroen > > [1] > https://issues.apache.org/jira/browse/KAFKA-9076?focusedCommentId=17268908&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17268908
