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

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

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

Kapsam

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ı

Kritik Risk
  • ✓

    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

Metrikler
  • ✓

    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

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)

Ödünleşim

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 Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

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