PostgreSQL WAL Şişmesi: İnaktif Replikasyon Yuvası Disk Dolması ve Max Slot LSN Koruması

Principal/Architect (L7+)

⚡ÖZET VE TEKNİK CEVAP

Modern Debezium, Fivetran veya Airbyte gibi Change Data Capture (CDC) araçları PostgreSQL'e Mantıksal Replikasyon Yuvaları (Replication Slots) ile bağlanır. Bir replikasyon yuvası, ilgili tüketici okuduğunu onaylayana kadar (LSN numarası ilerleyene kadar) PostgreSQL'in diskteki hiçbir Write-Ahead Log (WAL) dosyasını silmeyeceğini garanti eder. Bir Debezium konteyneri çökerse veya bir geliştirici tarafından 6 saat boyunca kapalı unutulursa ve veritabanına normal yazma trafiği gelmeye devam ederse, PostgreSQL tek bir WAL dosyasını bile temizleyemez ve pg_wal/ klasöründe biriktirir. Sunucunun disk doluluğu saatler içinde %100'e vurur. Disk %100 dolduğu anda PostgreSQL yeni işlem yazamaz, tüm bağlantıları keser ve Panik Kapanması (Panic Shutdown) ile çöker. Canlı sistemler bu felaketi:

max_slot_wal_keep_size = 50GB ayarı (diskin dolması yerine yuvayı devre dışı bırakır),

Yuva gecikme alarmları ve

Ölü yuvaları silen otomatik temizlik botlarıyla çözer.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

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

Mekanizma

PostgreSQL WAL saklaması ve yuva mekanizması checkpoint motoruyla çalışır:

Checkpoint Temizliği: Normalde periyodik CHECKPOINT eski WAL dosyalarını diskten siler.

Replikasyon Yuvası Vetosu: Temizleyici pg_replication_slots tablosuna bakar. Bir yuvanın restart_lsn değeri geride kalmışsa, o noktadan sonraki hiçbir WAL dosyasının silinmesine izin verilmez.

max_slot_wal_keep_size Devre Kesici: Bu ayar (ör. 50GB) açıksa, biriken WAL boyutu 50GB'ı aştığı anda PostgreSQL geride kalan yuvayı otomatik olarak geçersiz (wal_status = 'lost') ilan eder, diskteki eski WAL'ları temizler ve ana veritabanının çökmesini engeller.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Debezium Kafka CDC hatları, Postgres okuma kopyası replikasyonları, mantıksal replikasyonla beslenen mikroservisler ve analitik ETL aktarımları.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
postgresql.conf dosyasında max_slot_wal_keep_size = -1 (sınırsız) bırakıp unutulan bir test yuvası yüzünden tüm canlı veritabanının diskini doldurmak
✓
yüksek trafikte yuvaları plansız silip replika sunucuların veri tutarlılığını koparmak

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
pg_replication_slots tablosunda bir yuvanın active = false ve lag > 20GB olarak görünmesi
✓
/pg_wal disk doluluk alarmlarının dakikalar içinde yukarı tırmanması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
max_slot_wal_keep_size = 50GB (veya disk boyutunun %25'i) ayarını zorunlu kılın
✓
15 dakikadan uzun süre inaktif kalan yuvalar (active = false) için PagerDuty alarmları kurun
✓
disk %85'e ulaştığında ölü yuvaları otomatik silen temizlik betikleri çalıştırın

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

Ödünleşim

max_slot_wal_keep_size ölü bir tüketici yüzünden veritabanı diskinin dolup çökmesini kesin olarak engeller; ancak geçersiz kılınan CDC yuvasının tüm veritabanını baştan tam tarama (snapshot) ile okumasını gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir sağlık girişimi Snowflake'e veri aktarmak için canlı PostgreSQL veritabanına Debezium CDC bağladı. Cuma gecesi Debezium pod'u bellek yetersizliğinden çöktü. max_slot_wal_keep_size = -1 (sınırsız) olduğu için PostgreSQL hafta sonu boyunca 140 GB WAL dosyasını diskte biriktirdi. Pazar sabahı disk %100 doldu ve PostgreSQL çöktü; hastane portalı 3 saat boyunca kapandı. DBA ekibi max_slot_wal_keep_size = 30GB kuralını getirdi ve inaktif yuva alarmları kurdu. Aylar sonra benzer bir işçi durduğunda PostgreSQL 30 GB sınırında yuvayı güvenle düşürdü ve ana veritabanının kesintisiz ayakta kalmasını sağladı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

İnaktif bir PostgreSQL replikasyon yuvasının (replication slot) en büyük tehlikesi nedir?

PostgreSQL yuva inaktif olduğu sürece üretilen hiçbir WAL dosyasını diskten silmez; bu da diskin %100 dolmasına ve ana veritabanının çökmesine neden olur.

`max_slot_wal_keep_size` PostgreSQL'i disk dolması krizinden nasıl korur?

Replikasyon yuvalarının diskte tutabileceği maksimum WAL boyutuna katı bir tavan koyar; bir yuva bu limiti aşarsa PostgreSQL yuvayı geçersiz kılar ve veritabanını ayakta tutmak için eski WAL dosyalarını siler.

PostgreSQL WAL Şişmesi: İnaktif Replikasyon Yuvası Disk Dolması ve Max Slot LSN Koruması — Sıkça Sorulan Sorular

PostgreSQL'de replikasyon yuvası gecikmesi hangi SQL sorgusuyla denetlenir?

`SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag FROM pg_replication_slots;`

WAL boyutu sınırı yüzünden replikasyon yuvası geçersiz kılınan bir Debezium CDC işçisine ne olur?

İşçi hata alır ve eksik kalan geçmiş WAL dosyaları diskten silindiği için tüm tabloları sıfırdan baştan okumak (full initial snapshot) zorunda kalır.

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

Temel Gerçekler & İlkeler

▸
İnaktif replikasyon yuvaları PostgreSQL'in diskteki WAL dosyalarını silmesini engeller.
▸
Önlem alınmayan WAL birikimi diski %100 doldurarak ölümcül veritabanı çöküşlerine yol açar.
▸
Güvenlik devre kesicisi olarak mutlaka max_slot_wal_keep_size = 30GB-50GB tanımlayın.
▸
active = false durumuna düşen replikasyon yuvaları için yüksek öncelikli alarmlar kurun.

Yaygın Yanılgılar

✗
Yanılgı: Düzenli VACUUM ve CHECKPOINT yuvaların tuttuğu WAL dosyalarını otomatik temizler (Gerçek: Replikasyon yuvaları onaylanana kadar checkpoint temizliğini kesin olarak veto eder).
✗
Yanılgı: AWS RDS veya Aurora gibi bulut veritabanları bu disk dolmasını otomatik engeller (Gerçek: RDS Postgres de izlenmeyen yuvalarda diski doldurup çöker).

Karar Kılavuzu & Önceliklendirme

Disk dolması kaynaklı kesintilere karşı kesin bağışıklık kazanmak için CDC veya replika çalıştıran tüm PostgreSQL veritabanlarında max_slot_wal_keep_size ve yuva izleme alarmlarını yapılandırın.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]PostgreSQL Server Configuration: Replication Slots & WAL Retention Parameters— The PostgreSQL Global Development Group