🗂️ Topic & Partition Detayları

Topic & Partition Detayları: Topic Yapılandırması Kafka CLI — topic oluştur ve yönet --describe Çıktısında Leader/Replica/ISR Nasıl Okunur?

Topic Yapılandırması

Kafka CLI — topic oluştur ve yönet

--describe Çıktısında Leader/Replica/ISR Nasıl Okunur?

--create --partitions 3…

`--create --partitions 3 --replication-factor 3` çalıştırıldığında Kafka her partition için 1 leader + 2 follower broker seçer — bu seçim rastgele değil, cluster'a eşit dağıtılır.

--describe çıktısındaki "Partition…

`--describe` çıktısındaki "Partition: 0 Leader: 1" satırı, o partition'a yazılan HER mesajın broker 1 üzerinden geçtiğini gösterir — diğer brokerlar sadece kopyalar.

"Replicas: 1,2,3" o partition'ın hangi broker'larda KOPYALANDIĞINI, "Isr: 1,2,3" ise bu kopyaların hangilerinin GÜNCEL (in-sync) olduğunu gösterir — ikisi aynı olmayabilir.

Bir broker geride kalırsa ISR listesinden…

Bir broker geride kalırsa ISR listesinden düşer — bu durumda `min.insync.replicas` eşiği artık daha az broker tarafından karşılanıyor demektir ve durum izlenmelidir.

Replication — Fault Tolerance

Kafka'daki replication, event stream'leri için bir RAID dizisi gibi çalışır: her partition'ın bir leader broker'ı (yazmaları kabul eden ve okumaları sunan) ve sürekli her byte'ı yansıtan N-1 follower broker'ı vardır — leader makine bozulursa, follower'lardan biri saniyeler içinde mesaj kaybı olmadan leader seçilir. Devam etmeden önce üzerinde durulması gereken soru: cluster zaten replication-factor=2 ile hayatta kalıyorsa neden her production rehberi 3'te ısrar ediyor? Çünkü replication-factor=2 ile tek bir broker arızası sizi tek bir kopya ile bırakır ve fazlalık kalmaz — sonraki arıza veri kaybını tetikler. Kafka, özellikle rolling restart'larda ve donanım arızalarında bile veri kaybını imkânsız kılmak için tasarlanmıştır. Java açısından, replication yazma yansıtmalı bir `ReentrantReadWriteLock` gibidir: `acks=all` ile tüm `min.insync.replicas`'lar alındığını onaylayana kadar yazma kabul edilmez, bu size bir veritabanı transaction'ının `COMMIT`'iyle aynı dayanıklılık garantisini sağlar. QA için operasyonel etki doğrudandır: staging ortamınız tek broker'lı Kafka (replication-factor=1) çalıştırıyorken production replication-factor=3 çalıştırıyorsa, performans testleri ve güvenilirlik kontrolleri tamamen farklı bir sistemi ölçüyor demektir — bu, neredeyse her zaman replication uyumsuzluğuna kadar takip edilen klasik "staging'de çalıştı, production'da başarısız oldu" kök nedenidir.

🎬 acks=all Yeterli mi? min.insync.replicas Tuzağı

Producer, acks=all ve min.insync.replicas=2 ile bir ödeme event'i gönderiyor — en güvenli ayar kombinasyonu gibi görünüyor.