MirrorMaker 2 concept in Kafka - Deep Dive

Overview - MirrorMaker 2 concept

What is it?

MirrorMaker 2 is a tool in Apache Kafka that copies data between Kafka clusters. It helps keep data synchronized across different locations or environments. It works by reading messages from one cluster and writing them to another, ensuring data is mirrored. This is useful for backup, disaster recovery, or data migration.

Why it matters

Without MirrorMaker 2, managing data across multiple Kafka clusters would be manual and error-prone. It solves the problem of keeping data consistent and available in different places automatically. This means businesses can avoid data loss, reduce downtime, and support global applications that need data close to users. Without it, data replication would be slow, unreliable, or require complex custom solutions.

Where it fits

Before learning MirrorMaker 2, you should understand basic Kafka concepts like topics, producers, consumers, and clusters. After MirrorMaker 2, you can explore advanced Kafka features like multi-cluster management, Kafka Connect, and disaster recovery strategies.

Mental Model

Core Idea

MirrorMaker 2 acts like a smart courier that continuously copies messages from one Kafka cluster to another to keep them in sync.

Think of it like...

Imagine two offices in different cities that need to have the same files. MirrorMaker 2 is like a courier service that picks up new files from one office and delivers them to the other, making sure both offices always have the latest copies.

┌───────────────┐       ┌───────────────┐
│ Source Kafka  │──────▶│ MirrorMaker 2 │──────▶
│   Cluster     │       │ (Courier Tool)│       │
└───────────────┘       └───────────────┘       
                                │              
                                ▼              
                       ┌───────────────┐       
                       │ Target Kafka  │       
                       │   Cluster     │       
                       └───────────────┘       

Build-Up - 7 Steps

1

Foundation

Basic Kafka Cluster Concepts

Concept: Understanding what a Kafka cluster is and how it stores and streams data.

A Kafka cluster is a group of servers that work together to store and manage streams of messages. Producers send messages to topics in the cluster, and consumers read from these topics. Each cluster is independent and manages its own data.

Result

You know that Kafka clusters hold streams of messages and that producers and consumers interact with these clusters.

Understanding clusters is essential because MirrorMaker 2 moves data between these independent units.

2

Foundation

What is Data Replication in Kafka?

Concept: Introducing the idea of copying data from one place to another to keep it safe or available.

Data replication means making copies of data in different locations. In Kafka, replication inside a cluster keeps data safe if a server fails. But copying data between clusters needs a special tool because clusters are separate.

Result

You understand that replication inside a cluster is different from copying data between clusters.

Knowing this difference helps you see why MirrorMaker 2 is needed for cross-cluster data copying.

3

Intermediate

MirrorMaker 2 Architecture Overview

🤔Before reading on: do you think MirrorMaker 2 runs as a standalone app or integrates with Kafka Connect? Commit to your answer.

Concept: MirrorMaker 2 is built on Kafka Connect, using connectors to move data between clusters.

MirrorMaker 2 uses Kafka Connect framework, which runs connectors that read from source clusters and write to target clusters. It manages offsets, topics, and configurations to keep data consistent. It can run distributed for scalability and fault tolerance.

Result

You see MirrorMaker 2 as a set of connectors managed by Kafka Connect, not just a simple copy tool.

Understanding the Kafka Connect foundation explains MirrorMaker 2's flexibility and reliability.

4

Intermediate

How MirrorMaker 2 Handles Topic and Offset Translation

🤔Before reading on: do you think MirrorMaker 2 copies topic names exactly or can it rename them? Commit to your answer.

Concept: MirrorMaker 2 can rename topics and translate consumer offsets to keep data consistent across clusters.

MirrorMaker 2 supports topic renaming to avoid conflicts and manages consumer offsets so consumers can continue reading seamlessly after failover. It tracks which messages have been copied and ensures no duplicates or gaps happen.

Result

You understand MirrorMaker 2 does more than copy messages; it manages metadata for smooth replication.

Knowing offset and topic translation prevents confusion when working with mirrored clusters.

5

Intermediate

Configuring MirrorMaker 2 for Multi-Cluster Replication

Concept: Learning how to set up MirrorMaker 2 with configuration files to connect source and target clusters.

You create configuration files specifying source and target cluster addresses, topics to replicate, and replication policies. MirrorMaker 2 uses these to start connectors that continuously copy data. You can filter topics and control replication frequency.

Result

You can configure MirrorMaker 2 to replicate exactly the data you want between clusters.

Understanding configuration lets you tailor replication to your needs and avoid unnecessary data transfer.

6

Advanced

Handling Failover and Disaster Recovery with MirrorMaker 2

🤔Before reading on: do you think MirrorMaker 2 automatically switches consumers to the target cluster on failure? Commit to your answer.

Concept: MirrorMaker 2 supports disaster recovery by keeping clusters in sync but requires external steps for failover.

MirrorMaker 2 keeps data mirrored so if one cluster fails, the other has the latest data. However, switching consumers or producers to the backup cluster needs manual or automated orchestration outside MirrorMaker 2. It ensures data is ready but not the full failover process.

Result

You know MirrorMaker 2 is a key part of disaster recovery but not a complete failover solution.

Understanding this boundary helps plan full recovery strategies beyond just data replication.

7

Expert

Internal Offset Sync and Conflict Resolution

🤔Before reading on: do you think MirrorMaker 2 can handle conflicting writes or duplicate messages automatically? Commit to your answer.

Concept: MirrorMaker 2 uses internal offset syncing and conflict resolution to maintain data integrity across clusters.

MirrorMaker 2 tracks offsets from source and target clusters to avoid duplicating messages or losing data. It uses internal topics to store metadata and applies conflict resolution strategies when clusters diverge. This ensures exactly-once semantics as much as possible in asynchronous replication.

Result

You understand the complex internal mechanisms that keep mirrored data consistent and reliable.

Knowing these internals reveals why MirrorMaker 2 is robust and how to troubleshoot replication issues.

Under the Hood

MirrorMaker 2 runs as a Kafka Connect cluster with source and sink connectors. The source connector reads messages from the source Kafka cluster topics, tracking offsets. The sink connector writes these messages to the target cluster, translating topic names and consumer offsets as configured. It uses internal Kafka topics to store replication metadata and offset sync information. This design allows distributed, fault-tolerant replication with monitoring and control.

Why designed this way?

MirrorMaker 2 was built on Kafka Connect to reuse its scalable, pluggable architecture. Earlier MirrorMaker versions were simpler but less reliable and flexible. Using Kafka Connect allows MirrorMaker 2 to handle complex replication scenarios, offset translation, and topic renaming. This design balances performance, reliability, and ease of configuration, addressing limitations of the original MirrorMaker.

┌───────────────┐       ┌─────────────────────┐       ┌───────────────┐
│ Source Kafka  │──────▶│ Kafka Connect with   │──────▶│ Target Kafka  │
│   Cluster     │       │ MirrorMaker 2       │       │   Cluster     │
│ (Topics, Data)│       │ (Source & Sink      │       │ (Topics, Data)│
└───────────────┘       │  Connectors, Offset │       └───────────────┘
                        │  Sync, Metadata)    │
                        └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does MirrorMaker 2 automatically failover clients to the target cluster? Commit yes or no.

Common Belief: MirrorMaker 2 automatically switches consumers and producers to the backup cluster if the source fails.

Reality: MirrorMaker 2 only replicates data; failover of clients must be handled separately by external tools or manual steps.

Why it matters: Assuming automatic failover leads to downtime or data loss during cluster outages because clients keep trying the failed cluster.

Quick: Does MirrorMaker 2 guarantee zero message duplication? Commit yes or no.

Common Belief: MirrorMaker 2 guarantees no duplicate messages in the target cluster.

Reality: While MirrorMaker 2 minimizes duplicates using offset syncing, duplicates can still occur in edge cases due to asynchronous replication.

Why it matters: Expecting perfect deduplication can cause overlooked data inconsistencies and bugs in downstream processing.

Quick: Can MirrorMaker 2 replicate data between different Kafka versions without issues? Commit yes or no.

Common Belief: MirrorMaker 2 works seamlessly between any Kafka cluster versions.

Reality: MirrorMaker 2 requires compatible Kafka versions; major version mismatches can cause replication failures or data corruption.

Why it matters: Ignoring version compatibility risks broken replication and data loss.

Quick: Is MirrorMaker 2 just a simple message copier? Commit yes or no.

Common Belief: MirrorMaker 2 just copies messages from one cluster to another without extra processing.

Reality: MirrorMaker 2 manages offsets, topic renaming, and metadata to ensure consistent and reliable replication, not just copying.

Why it matters: Underestimating its complexity can lead to misconfiguration and unexpected replication behavior.

Expert Zone

1

MirrorMaker 2's internal offset sync topics are critical for exactly-once semantics but can cause lag if not monitored.

2

Topic renaming is powerful but can cause consumer confusion if not coordinated with client applications.

3

Running MirrorMaker 2 in distributed mode improves fault tolerance but requires careful resource planning to avoid bottlenecks.

When NOT to use

MirrorMaker 2 is not suitable for real-time active-active cluster setups requiring synchronous replication. For such use cases, consider Kafka's native cluster linking or external geo-replication tools. Also, for simple one-time migrations, manual export/import may be simpler.

Production Patterns

In production, MirrorMaker 2 is often used for disaster recovery setups, geo-replication to bring data closer to users, and migration between Kafka versions or cloud providers. It is integrated with monitoring tools to track replication lag and failures, and combined with orchestration systems to automate failover.

Connections

Kafka Connect

MirrorMaker 2 is built on top of Kafka Connect framework.

Understanding Kafka Connect's connector model clarifies how MirrorMaker 2 achieves scalable and pluggable replication.

Disaster Recovery Planning

MirrorMaker 2 supports disaster recovery by replicating data across clusters.

Knowing disaster recovery principles helps design effective replication and failover strategies using MirrorMaker 2.

Supply Chain Logistics

Both involve moving goods or data reliably between locations with tracking and error handling.

Recognizing replication as a logistics problem highlights the importance of tracking, ordering, and conflict resolution.

Common Pitfalls

#1 Assuming MirrorMaker 2 handles client failover automatically.

Wrong approach:

Start MirrorMaker 2 and expect consumers to switch clusters without configuration.

Correct approach:

Use external orchestration or client configuration to handle failover alongside MirrorMaker 2 replication.

Root cause:

Misunderstanding MirrorMaker 2's role as data replicator only, not a failover manager.

#2 Not configuring topic renaming when source and target clusters share topic names.

Wrong approach:

"topics": "*" without renaming in MirrorMaker 2 config, causing conflicts.

Correct approach:

"topics": "*", with "topic.rename.format" to avoid name clashes.

Root cause:

Overlooking topic name conflicts leads to data overwrites or replication errors.

#3 Ignoring Kafka version compatibility between clusters.

Wrong approach:

Replicating between Kafka 2.2 and Kafka 3.4 clusters without testing.

Correct approach:

Verify and upgrade Kafka clusters to compatible versions before replication.

Root cause:

Assuming all Kafka versions are interoperable causes replication failures.

Key Takeaways

MirrorMaker 2 is a Kafka Connect-based tool that replicates data between Kafka clusters reliably and flexibly.

It manages not just message copying but also offset syncing and topic renaming to maintain data consistency.

MirrorMaker 2 supports disaster recovery and geo-replication but does not handle automatic client failover.

Proper configuration and monitoring are essential to avoid common pitfalls like topic conflicts and version mismatches.

Understanding MirrorMaker 2's internals and limits helps design robust multi-cluster Kafka architectures.

Practice

1. What is the main purpose of Kafka MirrorMaker 2?

easy

A. To copy data between Kafka clusters for backup and availability

B. To create new Kafka topics automatically

C. To monitor Kafka cluster health

D. To compress Kafka messages for storage

Solution

1. Step 1: Understand MirrorMaker 2 role

   MirrorMaker 2 is designed to replicate data from one Kafka cluster to another to ensure data safety and availability.

2. Step 2: Compare options with MirrorMaker 2 function

   Only To copy data between Kafka clusters for backup and availability describes copying data between clusters, which matches MirrorMaker 2's purpose.

3. Final Answer:

   To copy data between Kafka clusters for backup and availability -> Option A

4. Quick Check:

   MirrorMaker 2 purpose = Data replication [OK]

Hint: MirrorMaker 2 copies data between clusters for safety [OK]

Common Mistakes:

• Confusing MirrorMaker 2 with monitoring tools
• Thinking it creates topics automatically
• Assuming it compresses messages

2. Which configuration is required to specify the source Kafka cluster in MirrorMaker 2?

easy

A. producer.bootstrap.servers

B. replica.bootstrap.servers

C. mirror.bootstrap.servers

D. consumer.bootstrap.servers

Solution

1. Step 1: Identify source cluster connection

   MirrorMaker 2 uses consumer configs to read from the source Kafka cluster.

2. Step 2: Match config key to source cluster

   The correct config key for source cluster is consumer.bootstrap.servers, which tells MirrorMaker 2 where to consume data from.

3. Final Answer:

   consumer.bootstrap.servers -> Option D

4. Quick Check:

   Source cluster = consumer.bootstrap.servers [OK]

Hint: Source cluster uses consumer.bootstrap.servers config [OK]

Common Mistakes:

• Using producer.bootstrap.servers for source cluster
• Confusing config keys with mirror.bootstrap.servers
• Assuming replica.bootstrap.servers is valid

3. Given this MirrorMaker 2 config snippet:

{
  "source.cluster.bootstrap.servers": "source:9092",
  "target.cluster.bootstrap.servers": "target:9092",
  "topics": "topicA,topicB",
  "num.streams": 3
}

How many parallel streams will MirrorMaker 2 use to copy data?

medium

A. 3

B. 2

C. 1

D. 4

Solution

1. Step 1: Locate num.streams setting

   The config sets "num.streams" to 3, which controls how many parallel streams MirrorMaker 2 uses.

2. Step 2: Understand effect of num.streams

   More streams mean more parallelism in copying data, so MirrorMaker 2 will use 3 streams here.

3. Final Answer:

   3 -> Option A

4. Quick Check:

   num.streams = 3 [OK]

Hint: Check num.streams value for parallelism count [OK]

Common Mistakes:

• Assuming default 1 stream if not read carefully
• Confusing topics count with streams count
• Ignoring num.streams config

4. You configured MirrorMaker 2 with:

topics = "topic1,topic2"
num.streams = 0

What is the problem with this configuration?

medium

A. topics must be a single topic, not multiple

B. num.streams cannot be zero; it must be at least 1

C. topics should be configured as a list, not a string

D. num.streams must be an even number

Solution

1. Step 1: Check num.streams value validity

   num.streams controls parallel streams and must be at least 1 to work properly.

2. Step 2: Identify error in config

   Setting num.streams to 0 disables streams, causing MirrorMaker 2 to fail or not copy data.

3. Final Answer:

   num.streams cannot be zero; it must be at least 1 -> Option B

4. Quick Check:

   num.streams ≥ 1 required [OK]

Hint: num.streams must be ≥ 1, zero disables copying [OK]

Common Mistakes:

• Thinking topics must be single only
• Assuming num.streams can be zero
• Believing num.streams must be even

5. You want MirrorMaker 2 to replicate only topics starting with "logs-" from source to target cluster. Which config setting achieves this?

hard

A. "topics": "logs-*"

B. "topics": "logs-"

C. "topics.regex": "logs-.*"

D. "topics.regex": "^logs$"

Solution

1. Step 1: Understand topic filtering in MirrorMaker 2

   MirrorMaker 2 supports filtering topics by regex using the "topics.regex" config.

2. Step 2: Match regex to desired pattern

   To match all topics starting with "logs-", the regex "logs-.*" correctly matches any topic beginning with "logs-".

3. Step 3: Compare options

   "topics": "logs-*" uses "topics" with wildcard which is not supported; "topics": "logs-" matches exact topic name; "topics.regex": "^logs$" matches only "logs" exactly.

4. Final Answer:

   "topics.regex": "logs-.*" -> Option C

5. Quick Check:

   Use topics.regex with proper regex for filtering [OK]

Hint: Use topics.regex with regex pattern to filter topics [OK]

Common Mistakes:

• Using wildcard * in topics instead of regex
• Confusing exact match with regex match
• Using incorrect regex that matches wrong topics