Disaster recovery planning in Kafka - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to set the replication factor for a Kafka topic to ensure data redundancy.

Kafka

kafka-topics --create --topic my-topic --partitions 3 --replication-factor [1] --bootstrap-server localhost:9092

Drag options to blanks, or click blank then click option'

A3

B1

C0

D5

Attempts:

3 left

💡 Hint

Common Mistakes

Setting replication factor to 1 disables redundancy.

Using 0 causes an error.

Setting the replication factor to 3 ensures that each partition has 3 copies across brokers, which helps in disaster recovery.

2fill in blank

medium

Complete the code to enable log compaction for a Kafka topic to help with disaster recovery.

Kafka

kafka-configs --alter --entity-type topics --entity-name my-topic --add-config [1]=compact --bootstrap-server localhost:9092

Drag options to blanks, or click blank then click option'

Amin.insync.replicas

Bcompression.type

Cretention.ms

Dcleanup.policy

Attempts:

3 left

💡 Hint

Common Mistakes

Using retention.ms instead affects log retention time.

Compression.type controls message compression, not compaction.

Setting cleanup.policy to compact enables log compaction, which helps in disaster recovery.

3fill in blank

hard

Fix the error in the command to describe the configuration of a Kafka topic for disaster recovery.

Kafka

kafka-topics --describe --topic [1] --bootstrap-server localhost:9092

Drag options to blanks, or click blank then click option'

Adescribe

Btopic-name

Cmy-topic

Dlocalhost

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'describe' as a topic name.

Using 'localhost' instead of a topic name.

The topic name must be specified correctly to describe its configuration. 'my-topic' is the example topic used.

4fill in blank

hard

Fill both blanks to create a Kafka consumer group with a specific group id and enable auto commit for disaster recovery.

Kafka

kafka-console-consumer --topic my-topic --bootstrap-server localhost:9092 --group [1] --enable-auto-commit [2]

Drag options to blanks, or click blank then click option'

Arecovery-group

Btrue

Cfalse

Ddefault-group

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'false' disables auto commit, risking offset loss.

Using generic group ids may cause conflicts.

Using a specific group id like 'recovery-group' helps track consumer offsets. Enabling auto commit with 'true' allows Kafka to save offsets automatically for recovery.

5fill in blank

hard

Fill all three blanks to configure a Kafka producer with retries, acks, and idempotence for disaster recovery.

Kafka

kafka-console-producer --topic my-topic --bootstrap-server localhost:9092 --producer-property retries=[1] --producer-property acks=[2] --producer-property enable.idempotence=[3]

Drag options to blanks, or click blank then click option'

A0

Ball

Ctrue

D1

Attempts:

3 left

💡 Hint

Common Mistakes

Setting retries to 0 disables retries.

Using acks=1 risks data loss if leader fails.

Disabling idempotence can cause duplicates.

Setting retries to 1 allows retrying failed sends. Setting acks to 'all' waits for all replicas to acknowledge. Enabling idempotence with 'true' prevents duplicate messages, all important for disaster recovery.

Practice

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