Apache Kafka MirrorMaker 2 replication guide

How do teams set up Apache Kafka MirrorMaker 2 between two sites?

A second data center, a cloud region or a disaster recovery requirement usually means Kafka topics must be readable and writable at another site when the primary site is unavailable. MirrorMaker 2 runs on Kafka Connect and replicates topics with their configuration, consumer groups with their offsets, and ACLs between clusters, while preserving partitioning. The connector configuration is the easy part. The harder work sits around it: replication is asynchronous, applications and runbooks must switch consumers over, offsets must be translated between clusters, ACLs need an identity mapping across sites, and cross-site bandwidth and latency shape lag. Confirm the exact replication behavior against the Kafka 4.3 geo-replication documentation for the release you run.

Start by choosing the topology, because it shapes every later decision. An active-passive design replicates one way from the primary site to a standby, while an active-active design replicates in both directions and needs rules for topic naming and for preventing replication loops. Most teams run MirrorMaker 2 as a dedicated Kafka Connect cluster in distributed mode, placed where it can reach both clusters, and define each cluster with an alias. Then decide which topics and consumer groups are mirrored using topic and group filters. Mirroring everything is simple to configure, but it also copies internal and test topics to the standby site, so the allowlist should come from a list the application owners have approved. Size the target cluster for the full copy of the mirrored data, not only the current working set.

Consumer failover is where most of the operational work sits. MirrorMaker 2 writes checkpoint and offset sync records so that consumer group offsets can be translated from the source cluster to the target cluster. Applications do not switch themselves. Someone must decide when to stop consumers at the source, fetch translated offsets for each group, and start consumers at the target. Write that sequence as a runbook with named owners, and rehearse it with the consumer groups the business depends on. Confirm in the 4.3 documentation how your client libraries read translated offsets and whether any application needs code changes. Producers need a decision too: they must be pointed at the target cluster through DNS, configuration or a service endpoint, and that switch belongs in the same runbook.

Access control is the second area that tends to break after failover. In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log. A resource without ACLs is restricted to super users unless allow.everyone.if.no.acl.found is set to true. Mirrored ACLs only help if the principal names on the target match the principal names on the source. Check how each site authenticates clients, whether through SASL mechanisms such as SCRAM or OAUTHBEARER or through mutual TLS, and make sure the same identity maps to the same principal at both sites. Test a connection from a non-admin identity against the target cluster before the first failover drill, because a successful connection with an administrator account says little about the permissions the applications will need.

Cross-site bandwidth and latency shape replication lag, and lag sets the data loss exposure during a failure. Replication is asynchronous, so the newest records at the source may not have reached the target when the source fails. Measure lag per topic partition under normal load and again under peak load, and alert on it well before a failover would be needed. Plan link capacity for the peak write rate of the mirrored topics plus the time needed to catch up after an outage, and ask the network team to confirm the sustained throughput of the inter-site path. Set the recovery point expectation from your own lag measurements, then confirm it with the business owners who will accept the data loss.

Which MirrorMaker 2 parts make up the replication path?

A MirrorMaker 2 deployment is a set of clusters, connectors, workers and access settings that work together. Each part below is something your team will configure, monitor and change during upgrades. Confirm connector names and default values against the Kafka release you deploy, because they can change between versions.

Source and target clusters

The source cluster holds the topics your producers write to, and the target cluster receives the copies. Each cluster needs its own bootstrap servers, listeners and security settings, and each replication flow is identified by its source and target aliases. Decide early which cluster accepts client writes and which one serves as the failover site, because that choice sets the direction of every connector.

MirrorSourceConnector copies topics

MirrorSourceConnector copies topics from the source cluster to the target and carries topic configuration across. It preserves partitioning, so records keep their partition assignment on the target side. Check the topic filter and the naming of replicated topics on the target, since a prefixed topic name changes what consumers must subscribe to. Confirm the topic filter defaults in your release before you rely on them.

Checkpoint and heartbeat connectors

MirrorCheckpointConnector translates consumer group offsets for the target cluster and publishes checkpoints, which lets a group resume near its last position after failover. MirrorHeartbeatConnector emits heartbeat records through each flow so you can confirm the link is alive and measure its age. Alert on checkpoint age and heartbeat age separately, because a healthy heartbeat does not show that offsets are being translated.

Kafka Connect workers on target

MirrorMaker 2 runs on Kafka Connect, so its connectors execute in worker processes on the target side. Plan the worker count, memory, task parallelism and the internal topics Connect uses to store its state. Confirm the worker configuration your release expects, and check that workers run on Java 17, which Kafka 4.0 and later require for brokers, Kafka Connect and tools.

ACL synchronization between clusters

MirrorMaker 2 can replicate ACLs from the source cluster to the target, so access rules follow the topics they protect. Decide whether the target should mirror the source exactly or keep its own access model, and review how a copied ACL behaves under the target's authorizer. On KRaft clusters, the StandardAuthorizer stores ACLs in the metadata log and restricts resources without ACLs to super users unless allow.everyone.if.no.acl.found is set, so confirm this on the target before the first sync.

Connector config and plugin packaging

Settings for each replication flow live in a connector configuration covering cluster aliases, topic filters, replication settings and security properties. Keep these files in version control and review each change before it reaches production. The MirrorMaker 2 classes must also be on the Connect plugin path of the target workers, and the jars must match the Kafka version those workers run. Confirm exact property names and defaults for your release.

Which replication topology fits the recovery goal?

This table compares the topology and placement choices a team makes before deploying MirrorMaker 2, along with the operating cost each one adds. Read each row against your recovery goals and against where writers and consumers run. The main takeaway is that one-way active-passive replication with workers on the target side carries the lowest ongoing burden, while active-active, fan-in and the ACL and offset decisions add work that must be tested before an incident.

Decision	When it fits	What it costs to operate
One-way active-passive	A standby site must take over if the primary fails, and only the primary accepts writes.	A tested failover runbook, consumer switchover steps and periodic failover drills to confirm the standby is current.
Bidirectional active-active	Both sites accept writes locally and each must serve its own users during normal operation.	Application-level conflict handling, loop prevention through topic naming, and monitoring of replication in both directions.
Fan-in from several sites	Regional clusters send data to one central cluster for analytics, reporting or consolidated processing.	Each source cluster is another cluster to patch, secure and monitor, and the central cluster grows with every source added.
Workers on the target side	The target network can open outbound connections to source brokers, and the target is the cluster that must stay supplied.	Firewall rules allowing the target workers to reach source listeners, plus source TLS trust and credentials stored on the target.
Workers on the source side	The source network can reach the target, but the target network cannot open connections into the source.	Outbound rules from the source to the target, and a source site outage also halts the replication workers.
Replicate ACLs to the target	The standby must enforce the same access rules as the primary immediately after failover.	The target authorizer must accept replicated ACLs, and any local ACL edits on the target will drift from the primary.
Offset translation or manual consumer reset	Consumers should resume near their last committed position, with translation tested in your own environment before relying on it.	Translation requires a failover test to confirm positions, while a manual reset needs an operator runbook and may reprocess or duplicate records.

What is the build sequence for a working MirrorMaker 2 link?

This sequence takes a MirrorMaker 2 link from version and identity checks to a tested failover of consumers. Each step closes with a check you can run, so the link is confirmed working before any consumer depends on it.

Confirm the Kafka release and Java 17
Choose a release from the supported list on the Kafka downloads page and read the upgrade notes for it. Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, so every host that runs MirrorMaker 2 workers needs Java 17 installed. If either cluster is on an older line, follow the upgrade notes before going further. Check: run the Java version command on each worker host and confirm both clusters and the workers sit on a release line you have signed off in writing.
Create TLS and SASL identities on both clusters
Create a dedicated identity for MirrorMaker 2 on the source and on the target, using TLS certificates, SASL credentials or both, as your security design requires. Kafka's documented SASL mechanisms are GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Keep the MirrorMaker 2 principal separate from application principals so its permissions can be reviewed on their own. Check: from each worker host, make a metadata request to both clusters with the new credentials. A successful response from each side confirms the handshake works.
Define allowlists and deploy connectors
Write the source and target cluster definitions and the replication flow in the MirrorMaker 2 configuration. Set topic and consumer group allowlists to the exact names or patterns you intend to replicate, and exclude internal and sensitive topics. Start the workers in distributed mode, then create the connectors through the Connect REST API. Check: list the connectors and tasks through the REST status endpoint on every worker and confirm each shows a running state, and compare the replicated topic and group names against your approved list.
Confirm topic configuration and data sync
Verify that mirrored topics exist on the target under the names MirrorMaker 2 assigns, with the partition counts and topic configuration you expect. Then produce a small set of test records on the source and watch them arrive on the target. Replication preserves partitioning, so compare records per partition, not only totals. Check: describe the topics on both sides and compare partition counts and key settings, then compare end offsets for the test partitions after the records have arrived.
Confirm offset checkpoints for consumer groups
MirrorMaker 2 translates consumer group offsets through its checkpoint mechanism, so a group can resume on the target at an equivalent position. Use a test consumer group that reads from the source and has committed offsets there. Allow time for checkpoints to be written, then inspect that group's translated offsets on the target. Check: the consumer group description on the target shows offsets that correspond to the source positions for the test group. If they do not line up, stop and investigate before moving on.
Confirm ACL sync and deny-by-default on the target
MirrorMaker 2 can replicate ACLs, so confirm which ACLs arrived on the target and whether they match what the source defines. On the target, check the allow.everyone.if.no.acl.found setting. In KRaft clusters, resources without ACLs are limited to super users unless that setting is true, so it should remain false. Check: produce or read with a principal that has no grant on the target. The request should be refused. Then confirm the mirrored principal can read the replicated topics it is supposed to use.
Set up heartbeat and lag monitoring
Put monitoring in place before anything depends on the link. MirrorMaker 2 publishes heartbeats that show the link is alive and checkpoint data that supports lag measurement. Track replication lag per partition for each mirrored topic, and alert when the lag grows or heartbeats stop arriving. Decide who receives the alerts and what action each one triggers. Check: stop the source-side producer briefly in a test window, confirm the lag and heartbeat signals change as expected, and confirm the alert reaches the on-call channel.
Rehearse consumer failover to the target
Rehearse a planned switch of a test consumer group from the source to the target, using the translated offsets from the earlier checkpoint step. Record the steps your team takes, who makes each decision and how long the switch takes in your environment. Then switch the consumer back, so you test both directions. Check: the test consumer resumes on the target without reprocessing or skipping records beyond what your design allows, and the rehearsal notes list every manual step that needs automation or a runbook entry.

How do you prove the replica is usable and failover works?

A MirrorMaker 2 link is only useful if the target cluster holds data you can read, in the order you expect, and consumers can resume from it. Before any team relies on the replica, run a validation pass against sample topics that covers message counts, partition layout, configuration, ordering and consumer group offsets. Choose topics that represent your real traffic patterns, including one high-volume topic, one with compaction if you use it, and one with a low, steady rate. Record the results in a sign-off document so the people accountable for failover can see what was tested and when.

Start with structure. Compare partition counts and partition leaders' placement between source and target for each sample topic. MirrorMaker 2 replicates topic configuration, but the target name follows the replication policy, so confirm the remote topic name your team will read from and check that settings such as retention, cleanup policy, and replication factor match what you planned for the target. Then compare message counts per partition over a fixed window, accounting for records still in flight. Use the source's end offsets and the target's end offsets as the reference, and treat a persistent gap as a defect to investigate before continuing.

Next, test ordering and delivery with synthetic traffic. Produce numbered test messages with a known key to a single partition on the source, then consume them from the replicated topic on the target and confirm that sequence numbers arrive in the same order within each partition. Ordering is guaranteed per partition only, so do not treat cross-partition order as a requirement. Repeat with a small number of partitions under load to see whether lag changes the observed order. Also verify that the consumer group offsets MirrorMaker 2 checkpoints translate to usable positions on the target, by starting a test consumer group from the translated offsets and confirming it resumes near the last record it processed on the source.

The failover drill moves real consumers to the target. Stop consumers on the source, start them against the target using the translated offsets, and then run a reconciliation: count the records processed before and after the switch, look for duplicates by key and sequence number, and look for gaps. Expect some duplicates, because checkpoints lag the source, and decide in advance how your application handles them, such as idempotent writes or deduplication by key. Record the time each step takes and who made each decision, so the drill becomes the baseline for the production runbook. Confirm with your application owners how they expect to fail back, since the reverse direction needs its own test.

The fail-safe test breaks the link on purpose. Stop the MirrorMaker 2 connectors or sever network access between clusters in a non-production environment, then confirm that your monitoring raises alerts for replication lag, connector state and task failures within the thresholds you set. Check that producers behave as the runbook describes when the target is unreachable, and that consumers on the source keep working. Restore the link and confirm the backlog drains and offsets catch up without data loss. Ask your implementation partner or internal team to document each alert and expected action, and confirm the exact metric names and thresholds with the Apache Kafka 4.3 geo-replication documentation for the version you run.

What makes cross-cluster replication cost more than the connector setup?

This table lists the factors that make MirrorMaker 2 replication take far more effort than starting the connectors, with a way to keep each one down and a note on whether it is paid once or recurs. Use it to scope a quote by counting these items in your own environment before you ask for a fixed-scope price. The main takeaway is that identity mapping, topic scope and consumer failover drive most of the work.

Driver	Why it changes effort or cost	How to keep it down	One-time or recurring
Topics and partitions replicated	Each replicated topic adds configuration, partition mapping, offset translation and monitoring scope. Partition count also raises the load on the replication connectors.	Narrow the topic allowlist to named business topics and exclude internal and scratch topics. Agree the partition plan with owning teams before replication starts.	One-time scoping, recurring as topics are added
Cross-site bandwidth and latency	Replication traffic competes with production traffic on inter-site links. Higher latency increases lag and makes tuning and capacity checks more involved.	Measure link capacity and round-trip time early. Set replication to the topics that need it and confirm the link can absorb peak write volume.	One-time measurement, recurring capacity review
Clusters and replication directions	Each cluster pair and direction adds a MirrorMaker 2 deployment, its own offset and loop-prevention behavior, and a separate lag dashboard. Active-active designs need the most review.	Choose the simplest topology that meets the recovery goal, such as one-directional active-passive, before adding reverse flows.	One-time design, recurring per added direction
Identity and ACL mapping across sites	Principals, service accounts and ACLs must match on both clusters, or consumers fail after switchover. Stored ACLs are cluster-local, so each site needs its own policy.	Agree a single identity model early, such as one OIDC or Kerberos realm for both sites, and define how principals map to ACLs before writing connector configuration.	One-time design, recurring when teams or principals change
Consumer applications needing tested switchover	Each consumer group that must fail over requires offset checks, a runbook, a tested restart on the target cluster and an owner who signs off the result.	Scope failover to critical consumer groups only. Test those groups in a non-production environment and record the observed offset gap.	One-time per application, recurring with each release test
Monitoring and alerting integration	Replication lag, connector health and checkpoint status must reach the existing monitoring stack with thresholds that operations staff understand.	Reuse existing metrics and alert routing. Limit alerts to lag, connector state and checkpoint age, and document who responds to each.	One-time integration, recurring alert tuning and on-call effort
Compliance evidence for the replication path	Assessors look for encryption in transit between sites, access control on replicated data and records of configuration changes. Each control needs evidence collected from the running system.	Define the evidence list before build, including TLS settings, ACL exports and change records. Confirm required controls with your assessor and your compliance owner.	One-time evidence design, recurring evidence collection per review cycle
Number of environments	Development, test, staging and production each need a replication topology, identity setup and test data. Drift between them is a common source of failed switchover tests.	Automate connector and ACL configuration from a single source, and promote changes through environments rather than configuring each one by hand.	Recurring per environment, reduced by automation

How does the setup change across DR, cloud and restricted networks?

Same-region or same-campus disaster recovery usually means two clusters that share a metro area, a campus or a provider region, often on separate failure domains such as different availability zones or buildings. The network path is short and low-latency, so the main concern is failure isolation rather than distance. MirrorMaker 2 still runs as a Kafka Connect workload, but the question is whether a single power, network or identity event can take out both sides at once.

Network path: Confirm that the replication link does not share a switch, route or firewall with the production client path, so a fault on one does not stop both.
Certificates and identity: Usually the same internal certificate authority and identity provider as production. Confirm that the standby cluster can still validate its certificates and principals if the primary identity service is down.
Worker placement: Run Connect workers in the target cluster's failure domain, spread across zones where your platform allows it.
ACLs: Replicate ACLs with the consumer groups and topics, then confirm the replicated rules match on the standby before any failover.
Extra testing: Simulate loss of one zone and of the identity service, then measure how far the replicated offsets lag.

Check whether a shared dependency, such as DNS, secrets storage or the monitoring stack, would fail on both sides at the same time.

How do you secure the replication link and its ACLs?

MirrorMaker 2 moves data, consumer offsets and ACLs across a network boundary, so each link needs its own identity, encryption and authorization decisions. The cards below cover the transport, the replication principals, the target authorizer, ACL replication rights, secrets, the Connect REST API and audit records.

Encrypt every replication listener

MirrorMaker 2 connects to the source and target brokers and runs on Kafka Connect workers, so TLS has to be configured on each listener those components use. Kafka security is optional and clusters can mix secured and unsecured listeners, so confirm that no plaintext listener is reachable across the link. Check certificate chains, hostname verification and certificate rotation for both clusters before go-live.

Dedicated SASL replication principals

Give MirrorMaker 2 its own SASL identities on each cluster rather than reusing an administrator or application account. Supported SASL mechanisms include GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER, so pick the one your identity system can issue and rotate. Grant each principal only the topic, group and cluster operations that its replication role requires, and document that set for review.

Deny by default on the target

With the StandardAuthorizer, ACLs live in the KRaft metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Keep that setting at its default on the target cluster so that replicated topics and groups stay closed until an explicit ACL is written. Confirm the setting in your own configuration, because a change there silently widens access.

Control who can replicate ACLs

MirrorMaker 2 can replicate ACLs as well as topics and offsets, which means a principal allowed to alter ACLs on the source can change access on the target. Decide which principals may write ACLs on each side and whether the replication principal may sync them. Review the ACL sync scope in a test environment so that an unintended grant does not reach production clusters.

Protect connector configuration secrets

MirrorMaker 2 connector configurations contain credentials, keystore passwords and SASL secrets, and those values are stored and displayed through the Connect REST API and the worker configuration. Use externalized secret providers or restricted file permissions, and avoid pasting credentials into connector JSON in version control. Confirm who can read connector definitions and how secrets are rotated without restarting the whole link.

Secure the Connect REST API

The Kafka Connect REST API can create, pause, restart and delete MirrorMaker 2 connectors, so anyone who reaches it can change replication. Restrict the listener to an administrative network, enable TLS and client authentication on it, and limit which accounts may call it. Verify these settings on every worker, since each worker exposes its own endpoint.

Audit changes to replication settings

Record who created, changed or deleted a replication flow, who altered its ACL sync or topic filters, and who used the Connect REST API to do so. Authorization logs on the brokers and Connect worker logs together can show these changes if they are retained and centralized. Ask your team to define the retention period and the review process before the first production replication flow is enabled.

What do you monitor, document and upgrade after go-live?

After go-live, the replication link needs the same operational attention as the clusters it joins. Monitoring should cover replication lag per topic partition, heartbeat freshness, checkpoint progress for consumer group offsets, connector and task failures in the Kafka Connect workers that run MirrorMaker 2, and consumer lag on the target cluster. Each signal answers a different question. Heartbeats show that the link is alive, checkpoints show whether offsets are being translated for consumers that may fail over, and target-side consumer lag shows whether downstream applications keep up with what has arrived. Ask your team which metrics they will export, where they will be stored, and who receives the alerts. Alert thresholds should be set from your own recovery objectives and tested under load. Do not copy numbers from a blog post or a generic template. Connector configuration belongs in version control, not in a running worker's REST API state. Keep the MirrorMaker 2 properties, topic and group filters, replication policy settings, and the Connect worker configuration in a repository with reviews and change history. Rehearsal depends on this: a failover is much harder to reason about when nobody can say which filters were active on the day of an incident. Document the offset mapping approach, including which checkpoint and offset sync topics are used to translate consumer group positions, and document the ACL mapping, including which principals on the source are replicated and which are created or kept on the target. Confirm the ACL behavior of your chosen authorizer on the target, because resources without ACLs are restricted to super users unless the allow.everyone.if.no.acl.found setting is enabled. Write failover and failback runbooks before you need them, then rehearse both. A failover runbook should name who decides to switch traffic, how producers and consumers are redirected, how consumer group offsets are translated and applied, and how the team confirms that the target is serving correct data. The failback runbook is often weaker in practice. It needs a plan for reversing the direction of replication, reconciling records written during the outage, and moving applications back without losing or duplicating messages. Run these exercises against a non-production pair with the same configuration, and record the time and the gaps you found. Plan upgrades for both clusters and for the Kafka Connect workers as a single change. The Kafka time-based release plan says rolling upgrades are supported from each release in the past year, which is the last three releases, to the latest version. Confirm that the MirrorMaker 2 version, the Connect worker version, and the broker versions on both sides fall inside a supported path before you schedule a change. Check the Java runtime requirements for each target release as well, since brokers, Kafka Connect and tools require Java 17 from Kafka 4.0 onward. Test each upgrade against a copy of the replication configuration, and verify replication, checkpoints and offset translation after each step. The supported releases on the Kafka downloads page are the reference for deciding when to move. Confirm the current list before planning, because releases and their end of bugfix support change over time. Ask any partner for a written upgrade and monitoring plan that names the metrics, the owners, the runbook test dates and the version path for both clusters and the Connect workers.

What do buyers ask before hiring help with MirrorMaker 2?

What drives the cost of hiring help with MirrorMaker 2?

Cost follows the written scope: how many clusters and regions are involved, how many topics, consumer groups and ACL principals must be replicated, what network path connects the sites, and how much security, monitoring and failover testing is included. The Apache Kafka software is licensed under Apache-2.0 and carries no license fee from the project, so you pay for people, infrastructure and network transfer. One-time costs include design, build, configuration, testing and the failover rehearsal. Recurring costs include the replication infrastructure, cross-site traffic, monitoring and any ongoing support retainer. Ask for a fixed-scope quote that lists each deliverable, the environments in scope, what your team must supply and what is excluded.

How long does a MirrorMaker 2 project take?

The duration depends on scope, and no single figure applies to every environment. A pair of clusters with a small, well-documented consumer inventory takes far less time than a multi-region topology with many consumer groups, strict ACL rules and firewall change requests. The largest schedule risks usually sit outside Kafka: network paths, identity provisioning and change approvals. Consumer inventory and sign-off from application owners also set the pace, because switchover steps can only be tested once those teams confirm them. Ask for a timeline in the written scope that separates design, build, testing and cutover, and that names which dependencies belong to your team.

What must our team provide before outside help starts?

Plan to provide five things. Environments: source and target clusters, or equivalent test clusters, with agreed sizing and access. Network paths: routes, firewall rules and DNS between sites, approved by your network team. Identities: the credentials MirrorMaker 2 uses on each cluster, and the ACLs that let it read source data and write to the target. Consumer inventory: every consumer group, its owner, its topics and its failover requirements. Sign-off: named approvers for the design, the cutover plan and the failover test results. Missing items usually surface late, so confirm each one in the written scope before the schedule is fixed.

Can an internal team build MirrorMaker 2 without outside help?

Yes, if the team has the skills and time. Kafka is licensed under Apache-2.0, so you can download and run it yourselves. MirrorMaker 2 is built on Kafka Connect, so the team needs working knowledge of Connect, Kafka security and ACLs, and the network between sites. Most of the difficulty sits in testing: verifying topic and offset replication, measuring lag, rehearsing consumer switchover and proving that target ACLs work. Ask whether the team can run that test cycle and document it for the people on call. An outside partner is most useful when the internal team lacks cross-site experience, works to a fixed deadline, or needs an independent test of the failover runbook. DeployOpen implements these systems inside your own infrastructure, so the decision usually comes down to capacity and skill.

Does MirrorMaker 2 switch consumers to the other cluster automatically?

No. MirrorMaker 2 replicates topics, consumer group offsets and ACLs, but it does not move running consumers or producers to the other cluster on its own. Switchover is an application and runbook task. Your teams must define how each application learns the new bootstrap servers, when producers stop writing to the primary, how consumers resume from the replicated offsets, and who makes the call. Replicated offsets help only when consumers restart against the target cluster with the right group settings. Write the switchover and failback steps as a runbook, rehearse them against a test pair of clusters, and record the measured lag at the moment of switch. Confirm offset translation behavior for your release in the Kafka geo-replication documentation before you finalize the runbook.

Is MirrorMaker 2 delivery exactly-once across clusters?

Confirm the delivery semantics in the Kafka documentation for the release you deploy. Do not design around a guarantee you have not read. Replication across clusters is asynchronous, so the target can trail the source, and consumers that resume after switchover may see some records again. Design consumers to tolerate duplicates, make writes idempotent where the business logic allows, and measure lag continuously so the recovery point is known. When you evaluate a partner, ask how the failover drill compared records and offsets between clusters, and how gaps or repeats were identified and handled. The answer should come from test evidence, not from a general statement about the platform.

Which Kafka release should we target for MirrorMaker 2?

Target a release from the supported list on the Kafka downloads page, which currently lists 4.3.1, 4.2.2 and 4.1.2. The project issues bugfix releases only for supported versions, and rolling upgrades are supported from each of the last three releases to the latest. If you run ZooKeeper-based clusters, you must migrate to KRaft before moving to Kafka 4.x, because Kafka 4.0 supports only KRaft mode. The upgrade notes recommend moving KRaft clusters older than 3.3.x to 3.9.x before moving to 4.x. From Kafka 4.0, brokers and Kafka Connect require Java 17, and clients need at least Java 11. MirrorMaker 2 runs on Connect, so check your connectors and client libraries against the chosen release before you fix the version.

How DeployOpen scopes, builds and hands over MirrorMaker 2 replication

DeployOpen plans, builds and documents MirrorMaker 2 replication inside your own data centers, clouds or air-gapped networks. Each engagement starts with a written, fixed scope that names the clusters, topics, consumer groups and ACLs in play, so the replication design can be reviewed before any configuration changes are made.

How we scope

Written scope names source and target clusters, replication direction and the topics and consumer groups to be mirrored.
Scope states how ACLs, topic configuration and consumer offsets will be carried across and what stays out of range.
Failover expectations for consumers and the replication lag metrics you need are agreed in writing before work starts.

How we build

MirrorMaker 2 runs on Kafka Connect, so we confirm the Connect workers, topology and security settings for each cluster pair.
Replication is tested with representative topics, offset translation and consumer failover before it is pointed at production traffic.
Monitoring covers replication lag and connector health, with alert thresholds set against the agreed scope rather than defaults.

How we hand over

Deliverables include the configured topology, connector configuration, ACL mappings and a runbook for failover and fallback.
Test results record which topics, offsets and ACLs were verified across clusters, with the steps used to reproduce them.
Your operators receive walkthroughs covering lag monitoring, connector restarts, and the known limits of the chosen design.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, and the scope of each is agreed in writing.
Upgrades to newer Kafka releases are planned against the project's supported release list and rolling upgrade paths you confirm for your version.
Replication configuration is reviewed when clusters, topics, security settings or client versions change, with findings recorded for your team.

Apache Kafka MirrorMaker 2 cross-cluster replication