MirrorMaker 2 Offset Sync and Consumer Group Restoration Interoperability

Question

Restoring a topic replicated by MirrorMaker 2 into a target cluster requires resuming consumer groups at the correct logical position without duplicates or gaps. MirrorMaker 2 periodically writes consumer-group offset mappings to an internal offset-sync topic, translating source log positions into target-cluster offsets. These checkpoints are point-in-time approximations that can drift if replication lag or partition reassignment occurred before the backup boundary, and version-sensitive schema or configuration differences may affect translation fidelity.

Kafka provides no built-in row-count or checksum reconciliation for recovered partitions, so operators must compare end offsets, record timestamps, and payloads manually. Because MirrorMaker 2 does not replicate internal topics, cluster metadata, or access-control lists identically, the restoration boundary itself remains uncertain. The unresolved decision is whether to trust translated checkpointed offsets or reset consumer groups manually, particularly when transaction markers or compacted-topic semantics may not be preserved identically across clusters.

Should operators prefer the translated offsets in the offset-sync topic or manually reset consumer groups to avoid duplicates? How can teams validate that translated positions align with expected partition boundaries without a native reconciliation tool? What verification sequence best confirms recovered data integrity before re-enabling downstream consumers?

Wasi · Answer

Should you trust the translated offsets? When restoring a mirrored topic, the decision hinges on the state of replication at the moment the backup boundary was taken: Low lag & stable metadata – If replication lag was < a few seconds and no partition reassignment or cluster‑metadata change occurred, the offset‑sync topic typically contains accurate positions. In this scenario, you can safely resume consumer groups at the stored offsets. High lag, reassignment, or version mismatch – If the source cluster was lagging, a reassignment happened, or the source and target Kafka versions differ, the translation may drift. Manual resetting to a known safe offset (often to-earliest or a specific offset) is the safer choice to avoid duplicates or gaps. Why manual reset can still be safe Even though resetting can risk duplicate processing, it guarantees that consumers start from a clean, known point. When you reset to the earliest and re‑run the consumer, you will re‑process any messages that may have been missed by the offset‑sync mapping, eliminating the risk of silently dropping data. Verification sequence before re‑enabling downstream consumers Collect source offsets kafka-consumer-groups.sh --bootstrap-server \ --describe --group Collect target offsets kafka-consumer-groups.sh --bootstrap-server \ --describe --group Compare end‑offsets kafka-run-class kafka.tools.GetOffsetShell \ --broker-list \ --topic \ --time -1 Ensure target end offsets are less than or equal to source end offsets. Check timestamps of the last few records kafka-console-consumer.sh --bootstrap-server \ --topic --partition

\ --from-beginning --max-messages 5 Verify that the timestamps match the expected source timestamps. A mismatch indicates drift. Optional checksum on a sample set # Example: compute SHA‑256 of payloads kafka-console-consumer.sh --bootstrap-server \ --topic --partition

\ --from-beginning --max-messages 100 | \ sha256sum If offsets differ, reset consumer group kafka-consumer-groups.sh --bootstrap-server \ --reset-offsets --group --to-earliest \ --execute Re‑run the consumer and confirm no duplicates appear. When to ask for additional information If you are unsure whether the source and target clusters share the same Kafka version or if a partition reassignment occurred after the backup, please provide: Kafka version of both source and target clusters. Any partition reassignment logs around the backup time. Final recommendation Trust the offset‑sync topic only when replication lag was negligible and metadata remained unchanged. Otherwise, reset consumer groups manually and follow the verification steps above to ensure data integrity before re‑enabling downstream consumers.

MirrorMaker 2 Offset Sync and Consumer Group Restoration Interoperability

1 answer

Should you trust the translated offsets?

Why manual reset can still be safe

Verification sequence before re‑enabling downstream consumers

When to ask for additional information

Final recommendation

Your perspective belongs here.

0 question comments