CCDAK · Question #156
Drag and Drop Question Match the topic configuration setting with the reason the setting affects topic durability. To answer, move each of the options below to the corresponding answer area. Partial…
The correct answer is Prevents data loss by only considering in-sync replicas when rebalancing.; Sets the standard for the number of partition instances that must keep up with the latest committed message.; Specifies how many redundant copies of partitions that are distributed across the brokers. Kafka Topic Durability Settings - Explanation This question matches three Kafka topic configuration settings (in the answer areas) to the reason each affects durability. The settings implied by the positions are: | Position | Setting | Matched Reason | |---|---|---| | 1 |…
Question
Drag and Drop Question Match the topic configuration setting with the reason the setting affects topic durability. To answer, move each of the options below to the corresponding answer area. Partial credit is given for each correct answer. Answer:
Exhibit
Answer Area
Drag items
Correct arrangement
- Prevents data loss by only considering in-sync replicas when rebalancing.
- Sets the standard for the number of partition instances that must keep up with the latest committed message.
- Specifies how many redundant copies of partitions that are distributed across the brokers.
Explanation
Kafka Topic Durability Settings - Explanation
This question matches three Kafka topic configuration settings (in the answer areas) to the reason each affects durability. The settings implied by the positions are:
| Position | Setting | Matched Reason |
|---|---|---|
| 1 | unclean.leader.election.enable | Prevents data loss by only considering in-sync replicas when rebalancing. |
| 2 | min.insync.replicas | Sets the standard for the number of partition instances that must keep up with the latest committed message. |
| 3 | replication.factor | Specifies how many redundant copies of partitions that are distributed across the brokers. |
Position 1 - unclean.leader.election.enable
When set to false, this setting blocks out-of-sync replicas from being elected as leader. If Kafka allowed a lagging replica to become leader during rebalancing, it could serve stale data or lose committed messages. The phrase "only considering in-sync replicas when rebalancing" is the exact purpose of disabling unclean elections.
Position 2 - min.insync.replicas
This setting defines the minimum number of replicas that must be caught up (in-sync) before a write is acknowledged. "Must keep up with the latest committed message" is precisely what being "in-sync" means - a replica is in the ISR list only if it is not lagging beyond the configured threshold. Producers using acks=all rely on this to guarantee durability.
Position 3 - replication.factor
This is the most straightforward setting - it directly controls how many copies of each partition exist across brokers. More copies = more redundancy = higher durability. "Redundant copies distributed across brokers" is the textbook definition.
Common Mistakes
- Confusing
min.insync.replicaswithreplication.factor: People mix these up because both involve counts. Remember:replication.factorsets how many copies exist;min.insync.replicassets how many must be current before a write succeeds. - Overlooking
unclean.leader.election.enable: This is easy to forget as a durability setting since it sounds like an availability/election topic, but it is critical for preventing data loss during failover. - Thinking
min.insync.replicasalone guarantees durability: It only matters when used withacks=allon the producer side - the topic setting and producer setting must align.
Topics
Community Discussion
No community discussion yet for this question.