What if your data could magically stay updated everywhere without you lifting a finger?
Why Cross-datacenter replication in Kafka? - Purpose & Use Cases
Imagine you have two offices in different cities, each with its own data storage. You try to copy all updates from one office to the other by manually sending files or emails every time something changes.
This manual copying is slow, often misses updates, and can cause confusion if files get lost or overwritten. It's hard to keep both offices perfectly in sync, especially when changes happen fast.
Cross-datacenter replication automatically copies data changes from one data center to another in real time. This keeps all locations up-to-date without manual work, reducing errors and delays.
sendFileToOtherDataCenter(file) waitForConfirmation() repeatForEachChange()
enableReplication(sourceCluster, targetCluster)
// Data flows automatically and continuouslyIt enables seamless, reliable data sharing across locations, so your systems stay consistent and available everywhere.
A global online store uses cross-datacenter replication to keep inventory data synced between servers in New York and Tokyo, ensuring customers see accurate stock no matter where they shop.
Manual data copying is slow and error-prone.
Cross-datacenter replication automates syncing data in real time.
This keeps distributed systems consistent and reliable.
Practice
What is the main purpose of cross-datacenter replication in Kafka?
Solution
Step 1: Understand the concept of cross-datacenter replication
Cross-datacenter replication means copying data from one Kafka cluster to another in a different location.Step 2: Identify the main goal of this replication
The goal is to keep data safe and available even if one cluster fails.Final Answer:
To copy Kafka topics between clusters for data safety and availability -> Option AQuick Check:
Replication = Data safety and availability [OK]
- Confusing replication with compression
- Thinking replication encrypts data
- Assuming replication deletes data
Which of the following is the correct way to specify the source cluster's bootstrap servers in Kafka MirrorMaker configuration?
consumer.bootstrap.servers = ?Solution
Step 1: Identify the role of consumer.bootstrap.servers
This property tells MirrorMaker where to read data from, so it must point to the source Kafka cluster.Step 2: Choose the correct server address for the source cluster
The source cluster's Kafka broker address is usually in the form host:port, like "source.kafka.cluster:9092".Final Answer:
"source.kafka.cluster:9092" -> Option AQuick Check:
consumer.bootstrap.servers = source cluster address [OK]
- Using target cluster address for consumer.bootstrap.servers
- Using ZooKeeper address instead of Kafka broker
- Confusing consumer and producer properties
Given the following MirrorMaker configuration snippet, what will be the value of producer.bootstrap.servers?
consumer.bootstrap.servers=source1.kafka:9092,source2.kafka:9092
producer.bootstrap.servers=target.kafka:9092Solution
Step 1: Read the configuration lines carefully
The snippet shows two properties: consumer.bootstrap.servers and producer.bootstrap.servers with their values.Step 2: Identify the value assigned to producer.bootstrap.servers
It is explicitly set to "target.kafka:9092" in the second line.Final Answer:
"target.kafka:9092" -> Option BQuick Check:
producer.bootstrap.servers = target cluster address [OK]
- Mixing consumer and producer server addresses
- Assuming producer uses source cluster address
- Ignoring explicit configuration values
Identify the error in this MirrorMaker consumer configuration:
consumer.bootstrap.servers=target.kafka:9092
consumer.group.id=mirror-groupSolution
Step 1: Understand the role of consumer.bootstrap.servers
This property must point to the source Kafka cluster to read data for replication.Step 2: Check the given value
It incorrectly points to "target.kafka:9092", which is the destination cluster, not the source.Final Answer:
consumer.bootstrap.servers should point to the source cluster, not target -> Option CQuick Check:
Consumer connects to source cluster [OK]
- Using target cluster address for consumer.bootstrap.servers
- Confusing ZooKeeper port with Kafka broker port
- Assuming group.id is missing when it is present
You want to replicate only topics starting with logs- from the source cluster to the target cluster using MirrorMaker. Which configuration property should you set to filter these topics?
Solution
Step 1: Identify the property to filter topics in MirrorMaker
MirrorMaker uses consumer.topic.whitelist to specify which topics to consume from the source cluster.Step 2: Match the pattern for topics starting with 'logs-'
The pattern "logs-*" matches all topics starting with "logs-".Final Answer:
consumer.topic.whitelist=logs-* -> Option DQuick Check:
Use consumer.topic.whitelist to filter topics [OK]
- Using producer.topic.filter which does not exist
- Confusing mirror.topic.prefix with filtering
- Using consumer.topic.filter instead of whitelist
Ready to prove it?
Pass the test and this pattern moves unknown
