Skip to main content

> postgresql_wal_şişmesi:_i̇naktif_replikasyon_yuvası_disk_dolması_ve_max_slot_lsn_koruması

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

Durdurulan bir Debezium CDC işçisi veya ölü replikasyon yuvası (replication slot) PostgreSQL ana sunucusunun diskinin %100 dolup saatler içinde çökmesine neden olur; `max_slot_wal_keep_size` disk krizini nasıl önler?

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: (1) **`max_slot_wal_keep_size = 50GB`** ayarı (diskin dolması yerine yuvayı devre dışı bırakır), (2) Yuva gecikme alarmları ve (3) Ölü yuvaları silen otomatik temizlik botlarıyla çözer.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

PostgreSQL WAL saklaması ve yuva mekanizması checkpoint motoruyla çalışır: (1) Checkpoint Temizliği: Normalde periyodik `CHECKPOINT` eski WAL dosyalarını diskten siler. (2) 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. (3) `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

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

3. Prodüksiyon Arıza Modları

`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

`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

`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)

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

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
Q1

İ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.
Q2

`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