Skip to main content

> raft_log_sıkıştırma_(compaction),_bellek_anlık_görüntüleri_ve_durum_makinesi_kurtarma

Raft Log Sıkıştırma (Compaction), Bellek Anlık Görüntüleri ve Durum Makinesi Kurtarma

Sınırsız büyüyen bir Raft commit log'u neden kaçınılmaz olarak disk tükenmesine ve yavaş node toparlanmasına yol açar; anlık görüntü (snapshot) tabanlı log sıkıştırma durum makinesi güvenliğini nasıl sağlar?

Staff/Principal (L6+)

ÖZET VE TEKNİK CEVAP

Raft mutabakat kümelerinde (etcd, Consul, CockroachDB) her yazma işlemi değişmez bir write-ahead log'a eklenir. Milyonlarca işlem yapan bir sistemde sınırsız log diski tüketir ve çöken bir node'un yeniden ayağa kalkmasını imkansız derecede yavaşlatır (milyonlarca eski işlemi baştan oynatması gerekir). Raft log sıkıştırma (compaction), durum makinesinin belirli aralıklarla anlık görüntüsünü (snapshot) alarak, o indeksten önceki tüm log satırlarını diskten siler. Çok geride kalan bir node geri bağlandığında, lider tüm geçmişi oynatmak yerine `InstallSnapshot` RPC'si ile tek parça kompakt anlık görüntüyü gönderir; böylece bellek ve disk kullanımı sınırlandırılırken sistemin ayağa kalkış hızı dakikalardan saniyelere iner.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Raft Log Sıkıştırma 4 aşamalı bir mekanizmayla çalışır: (1) Anlık Görüntü Tetikleme: Log belirlenen eşiği (ör. 100.000 işlem veya 500MB) aştığında node durum makinesini diske kompakt ikili dosya olarak yazar. (2) Üstveri Kaydı: Anlık görüntü `last_included_index` ve `last_included_term` değerleriyle küme üyelik ayarlarını saklar. (3) Log Kırpma: `last_included_index`'e kadar olan tüm eski log satırları diskten silinir. (4) Yakalama Protokolü: Geride kalan bir follower'ın talep ettiği indeks liderin logunda kalmamışsa, lider parça parça `InstallSnapshot` RPC'leri göndererek follower'ın durum makinesini doğrudan en güncel hale getirir.

2. Doğru Kullanım Senaryosu

Dağıtık anahtar-değer depoları (etcd, ZooKeeper, Consul), dağıtık SQL motorları (CockroachDB, TiKV) ve küme mutabakat motorları.

3. Prodüksiyon Arıza Modları

Anlık görüntü alımını ana Raft thread'i üzerinde senkron çalıştırmak ve CPU kilitlenmesi sonucu heartbeat paketleri gecikince istem dışı sahte lider seçimlerinin tetiklenmesi; devasa gigabaytlık snapshot gönderiminin ağ bant genişliğini boğup küme kalp atışlarını düşürmesi.

4. Teşhis ve Telemetri Sinyalleri

Veri seti büyümemesine rağmen disk kullanımının sürekli artması; yeni bir node'un kümeye katılması 10 dakikayı aşması; sıkıştırma döngülerinde `etcd_server_slow_apply_total` metriklerinin fırlaması.

5. Önleme ve Mimari Bariyerler

Copy-on-Write (CoW) arka plan snapshot mekanizmaları kullanın; `InstallSnapshot` ağ bant genişliğine hız sınırı (rate limit) koyun; snapshot sonrasında gerideki follower'ların tam dosya indirmeden logla yetişebilmesi için geriye dönük 5.000 satırlık bir güvenlik tampon logu tutun.

6. Mimari Ödünleşimler (Trade-offs)

Log sıkıştırma snapshot diske yazılırken periyodik disk I/O yükü getirir; ancak disk tüketimini işlem geçmişi yerine veri setinin gerçek boyutuyla sınırlar ve node kurtarma hızını 100 kat artırır.

Vaka İncelemesi (TinyCTO Örneği)

Büyük bir Kubernetes kümesinde log sıkıştırması kapalı unutulduğu için 5 node'lu etcd kümesi disk dolması nedeniyle çöktü. WAL logu 6 ayda 45 milyon işleme ulaşmıştı. Her 10.000 revizyonda bir otomatik sıkıştırma ve defragmentation devreye alındığında, disk kullanımı 120GB'tan 1.8GB'a düştü; çöken bir node 45 dakika boyunca geçmişi replay etmek yerine 4 saniyede snapshot ile senkron oldu.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Canlı bir kümede Raft log sıkıştırması (compaction) hiç yapılmazsa ne olur?

Write-ahead log diski doldurana kadar sonsuza dek büyür ve çöken bir node'u ayağa kaldırmak 1. günden beri yapılan tüm işlemleri baştan oynatmayı gerektirir.
Q2

Raft lideri, logu çok geride kalmış bir follower'a durumu nasıl aktarır?

Bireysel log satırları yerine en güncel sıkıştırılmış durum makinesi anlık görüntüsünü içeren `InstallSnapshot` RPC'si göndererek.

Raft Log Sıkıştırma (Compaction), Bellek Anlık Görüntüleri ve Durum Makinesi Kurtarma — Sıkça Sorulan Sorular

Raft snapshot yapısındaki `last_included_index` ve `last_included_term` nedir?

Snapshot'ın logdaki tam yerini ve term numarasını belirterek log eşleme özelliğinin kesintisiz devam etmesini sağlayan üstveri değerleridir.

Raft snapshot'ları neden asenkron (arka planda) üretilmelidir?

Diske senkron veri yazmak ana Raft döngüsünü kilitler, kalp atışı (heartbeat) paketlerinin düşmesine ve sahte lider seçimlerine yol açar.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Unbounded Raft logs cause disk exhaustion and multi-hour recovery replay times.
  • ▸Snapshot-based log compaction discards historical entries prior to `last_included_index`.
  • ▸`InstallSnapshot` RPC catches up severely lagged followers in seconds.
  • ▸Always take snapshots asynchronously via Copy-on-Write to avoid blocking cluster heartbeats.

Yaygın Yanılgılar

  • ✗Yanılgı: Compacting the log destroys fault tolerance (Gerçek: The snapshot preserves complete current state).
  • ✗Yanılgı: Snapshotting should occur after every single write (Gerçek: Frequent snapshots cause extreme disk write amplification; batch at 10k-100k entries).

Karar Kılavuzu & Önceliklendirme

Configure automated compaction triggers based on both log entry count and WAL file size. Implement bandwidth throttling on `InstallSnapshot` streaming to protect heartbeat traffic.

Doğrulanmış Kaynaklar & Referanslar