Bird
Raised Fist0
Kafkadevops~5 mins

Disaster recovery planning in Kafka - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
Recall & Review
beginner
What is disaster recovery planning in Kafka?
Disaster recovery planning in Kafka means preparing steps and tools to quickly restore Kafka services after failures or disasters, so data and messaging continue working with minimal downtime.
Click to reveal answer
beginner
Why is replication important for Kafka disaster recovery?
Replication copies Kafka data across multiple brokers or clusters. This protects data if one broker or cluster fails, allowing recovery from another copy without data loss.
Click to reveal answer
intermediate
What is a Kafka MirrorMaker and how does it help in disaster recovery?
Kafka MirrorMaker copies data between Kafka clusters. It helps disaster recovery by keeping a backup cluster updated, so if the main cluster fails, the backup can take over.
Click to reveal answer
intermediate
How does Kafka's topic retention policy affect disaster recovery?
Topic retention policy controls how long Kafka keeps messages. Proper retention ensures data needed for recovery is available, preventing data loss during disaster recovery.
Click to reveal answer
beginner
What role do backups play in Kafka disaster recovery?
Backups save Kafka data snapshots outside the cluster. They provide a safety net to restore data if replication or clusters fail, ensuring data can be recovered after disasters.
Click to reveal answer
What is the main purpose of Kafka replication in disaster recovery?
ATo speed up message processing
BTo encrypt data for security
CTo compress messages for storage
DTo copy data across brokers for fault tolerance
Which Kafka tool is commonly used to replicate data between clusters for disaster recovery?
AKafka MirrorMaker
BKafka Streams
CKafka Connect
DKafka Producer
What does Kafka's topic retention policy control?
AHow many consumers can read a topic
BHow long messages are stored
CThe order of messages
DThe encryption level of messages
Why are backups important in Kafka disaster recovery?
AThey provide a data snapshot outside the cluster
BThey speed up message delivery
CThey reduce network traffic
DThey increase message size
In disaster recovery, what is a key benefit of having multiple Kafka clusters?
AIt compresses data automatically
BIt reduces message latency
CIf one cluster fails, another can continue service
DIt encrypts messages end-to-end
Explain how Kafka replication and MirrorMaker work together to support disaster recovery.
Think about local copies vs copies across locations.
You got /4 concepts.
    Describe the role of topic retention and backups in Kafka disaster recovery planning.
    Consider how data is kept safe over time.
    You got /4 concepts.

      Practice

      (1/5)
      1. What is the main purpose of disaster recovery planning in Kafka?
      easy
      A. To keep Kafka data safe and services running after failures
      B. To improve Kafka message throughput
      C. To reduce Kafka cluster size
      D. To speed up Kafka consumer processing

      Solution

      1. Step 1: Understand disaster recovery goal

        Disaster recovery planning focuses on protecting data and maintaining service availability during failures.
      2. Step 2: Match goal to options

        Only To keep Kafka data safe and services running after failures mentions keeping data safe and services running after problems, which matches the goal.
      3. Final Answer:

        To keep Kafka data safe and services running after failures -> Option A
      4. Quick Check:

        Disaster recovery = data safety and uptime [OK]
      Hint: Disaster recovery means data safety and uptime [OK]
      Common Mistakes:
      • Confusing disaster recovery with performance tuning
      • Thinking it reduces cluster size
      • Assuming it speeds up consumers
      2. Which Kafka feature is used to replicate data to a backup cluster for disaster recovery?
      easy
      A. Kafka Connect
      B. Kafka Streams
      C. MirrorMaker
      D. Kafka Producer

      Solution

      1. Step 1: Identify replication tool for backup clusters

        MirrorMaker is designed to copy data between Kafka clusters for backup and disaster recovery.
      2. Step 2: Compare options

        Kafka Connect is for data integration, Kafka Streams for processing, and Producer for sending data, so only MirrorMaker fits replication to backup clusters.
      3. Final Answer:

        MirrorMaker -> Option C
      4. Quick Check:

        Replication to backup = MirrorMaker [OK]
      Hint: MirrorMaker copies data between clusters [OK]
      Common Mistakes:
      • Choosing Kafka Connect which is for integration, not replication
      • Confusing Kafka Streams with replication
      • Thinking Kafka Producer replicates data
      3. Given the following MirrorMaker command, what is its purpose?
      bin/kafka-mirror-maker.sh --consumer.config consumer.properties --producer.config producer.properties --whitelist='topic1,topic2'
      medium
      A. Consume messages from topic1 and topic2 without replication
      B. Delete topic1 and topic2 from the target cluster
      C. Produce messages to topic1 and topic2 only on source cluster
      D. Replicate only topic1 and topic2 from source to target cluster

      Solution

      1. Step 1: Understand MirrorMaker command components

        The command uses consumer and producer configs and a whitelist of topics to replicate.
      2. Step 2: Interpret whitelist usage

        The whitelist='topic1,topic2' means only these topics are replicated from source to target cluster.
      3. Final Answer:

        Replicate only topic1 and topic2 from source to target cluster -> Option D
      4. Quick Check:

        Whitelist limits topics replicated [OK]
      Hint: Whitelist limits topics MirrorMaker replicates [OK]
      Common Mistakes:
      • Thinking it only consumes without replication
      • Assuming it produces only on source cluster
      • Believing it deletes topics
      4. You wrote a MirrorMaker config but replication fails. Which is a likely cause?
      bootstrap.servers=source:9092
      group.id=mirror-group
      whitelist=topicA,topicB

      What is wrong?
      medium
      A. The whitelist should be 'whitelist='topicA,topicB' with quotes
      B. Missing producer bootstrap.servers config for target cluster
      C. group.id should be 'producer-group' instead of 'mirror-group'
      D. bootstrap.servers should point to target cluster, not source

      Solution

      1. Step 1: Check MirrorMaker config requirements

        MirrorMaker needs both consumer (source) and producer (target) bootstrap.servers configs to replicate data.
      2. Step 2: Identify missing config

        The given config only shows source bootstrap.servers; missing producer config causes replication failure.
      3. Final Answer:

        Missing producer bootstrap.servers config for target cluster -> Option B
      4. Quick Check:

        Both consumer and producer configs needed [OK]
      Hint: Both consumer and producer configs are required [OK]
      Common Mistakes:
      • Thinking quotes are mandatory around whitelist
      • Confusing group.id with producer group
      • Setting bootstrap.servers to target cluster only
      5. You want to ensure minimal data loss during a disaster. Which combination is best for Kafka disaster recovery?
      hard
      A. Use topic replication factor 3 and MirrorMaker to backup cluster
      B. Use only MirrorMaker without replication factor increase
      C. Use replication factor 1 and rely on manual backups
      D. Use Kafka Streams to replicate data to backup cluster

      Solution

      1. Step 1: Understand replication factor role

        A replication factor of 3 means data is copied to 3 brokers, reducing data loss risk.
      2. Step 2: Combine with MirrorMaker backup

        MirrorMaker copies data to a separate cluster, adding disaster recovery protection.
      3. Final Answer:

        Use topic replication factor 3 and MirrorMaker to backup cluster -> Option A
      4. Quick Check:

        Replication + MirrorMaker = minimal data loss [OK]
      Hint: Combine replication factor and MirrorMaker for best safety [OK]
      Common Mistakes:
      • Relying only on MirrorMaker without replication
      • Using replication factor 1 which risks data loss
      • Confusing Kafka Streams with replication tool
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard