Replication กับ ISR

ไอเดียในประโยคเดียว

Kafka รอด broker ล่มด้วยการเก็บแต่ละ partition ไว้บนหลาย broker — หนึ่ง leader และหลาย follower — และติดตามว่า copy ไหนตามทันครบใน in-sync replica (ISR) set เพื่อให้ leader ที่ล่มถูกแทนที่ได้โดยไม่เสียข้อมูลที่ ack ไปแล้ว

Leader กับ follower

แต่ละ partition มี replication factor: จำนวน copy ที่ Kafka เก็บ ด้วย replication-factor 3 partition อยู่บน 3 broker หนึ่งตัวเป็น leader — จัดการ read และ write ทั้งหมดของ partition นั้น ที่เหลือเป็น follower ที่ไม่ทำอะไรนอกจาก fetch จาก leader ตลอดเวลาเพื่อให้เหมือนกันเป๊ะ

# 3 copies of every partition, spread across 3 brokers
kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic payments --partitions 6 --replication-factor 3

ถ้า broker ของ leader ล่ม follower ตัวหนึ่งถูกเลื่อนเป็น leader และ partition ยังให้บริการต่อ client ค้นหา leader ใหม่ผ่าน bootstrap server — ไม่เสียข้อมูล แค่สะดุดสั้นๆ

In-sync replica set

ไม่ใช่ทุก follower จะตามทันเสมอ — บางตัวอาจช้าหรือหลุดการเชื่อมต่อชั่วคราว Kafka ติดตาม ISR: เซ็ตของ replica (leader บวก follower) ที่ตามทัน log ของ leader ครบ มีแต่สมาชิก ISR เท่านั้นที่มีสิทธิ์เป็น leader เพราะมีแต่พวกนี้ที่มีข้อมูลที่ ack แล้วครบ

สอง config เปลี่ยน ISR ให้เป็นสัญญาความ durable:

acks=all (ฝั่ง producer) — write ถูก ack ก็ต่อเมื่อ สมาชิก ISR ทุกตัว มีข้อมูลแล้ว
min.insync.replicas (ฝั่ง topic/broker) — ขนาด ISR ขั้นต่ำ ที่ write จะถูกยอมรับ ด้วย min.insync.replicas=2 ถ้า ISR เหลือ 1 write แบบ acks=all จะ ถูกปฏิเสธ แทนที่จะเสี่ยงเหลือ copy เดียว

flowchart TB
  prod["Producer (acks=all)"] --> leader["Leader replica"]
  leader -->|replicate| f1["Follower (อยู่ใน ISR)"]
  leader -->|replicate| f2["Follower (อยู่ใน ISR)"]
  leader -.->|ตามช้า หลุดจาก ISR| f3["Follower (นอก ISR)"]
  isr["write ถูก ack เมื่อ ISR ทุกตัวมีแล้ว min.insync.replicas คุมขนาด ISR"]

leader replicate ไป follower ส่วน ISR คุม write ที่ durable

Durability มาก่อน availability

สูตรความ durable แบบคลาสสิกคือ replication-factor=3, min.insync.replicas=2, acks=all ทน broker ล่มได้ 1 ตัว โดยยังบังคับให้ทุก write ที่ ack แล้วมี 2 copy — คุณไม่พึ่ง disk เดียว

ถ้า ISR เหลือศูนย์และ replica ที่ค้าง ไม่ sync เป็นตัวรอดตัวเดียวล่ะ? การเลือก replica ตัวนั้นขึ้นมาจะทำให้ partition กลับ online แต่ เสีย record ที่ไม่เคยได้รับ default ของ Kafka คือ unclean.leader.election.enable=false ปฏิเสธการแลกนี้ โดยเก็บ partition ไว้ offline จนกว่า replica ที่ in-sync จะกลับมา โดยเลือก durability มาก่อน availability คุณเปลี่ยนให้ availability มาก่อนได้ แต่ต้องเข้าใจความเสี่ยงเรื่องเสียข้อมูล