min.insync.replicas और उपलब्धता

क्लासिक 3/2/all नुस्खा

acks=all के साथ write तभी सफल होता है जब कम से कम min.insync.replicas replicas (leader समेत) के पास वह हो; कम in-sync हों तो producer को चुपचाप गारंटी कमज़ोर करने की जगह error मिलता है। आम production नुस्खा है replication factor 3, min.insync.replicas=2, acks=all: आप एक broker खो सकते हैं और फिर भी लिख सकते हैं, और स्वीकृत डेटा कम से कम दो brokers पर होता है। दो brokers खोने पर partition writes के लिए अनुपलब्ध हो जाता है (कोई replica in-sync हो तो reads जारी रहती हैं)। यही जानबूझकर किया गया trade-off है: उपलब्धता से ऊपर consistency। unclean.leader.election.enable=false (डिफ़ॉल्ट) रखें ताकि पुराना replica कभी leader न बने और चुपचाप स्वीकृत records न गिराए।

Broker विफलताओं से बचना

Replication, ISR और सही producer settings तय करते हैं कि स्वीकृत डेटा विफलता में बचेगा या नहीं।

Writes कितनी विफलताएँ सह सकते हैं, चलाकर

मैंने यह replication factor 3 और min.insync.replicas=2 के लिए चलाया: 0 या 1 विफल brokers पर writes चलते हैं (True, True) और 2 या 3 विफलताओं पर रुक जाते हैं (False, False)।

def can_write(rf, min_isr, failed):
    return rf - failed >= min_isr

print([can_write(3, 2, f) for f in range(4)])

Output:

[True, True, False, False]

Topic पर सेट करना (उदाहरण)

एक command में टिकाऊ topic बनाएँ।

kafka-topics.sh --bootstrap-server broker1:9092 --create --topic payments \
  --partitions 12 --replication-factor 3 --config min.insync.replicas=2

त्वरित जाँच: Replication factor 3 और min.insync.replicas=2 के साथ writes कितनी broker विफलताएँ सह सकते हैं?

• तीन
• दो
• एक
• कोई नहीं