PostgreSQL sunucusunda veri tabloları beklenen hızda büyürken disk kullanımının aniden artması, yalnızca yeni veri yazıldığını göstermez. Bağlantısı kesilen bir replikasyon tüketicisi veya unutulmuş bir replication slot, artık gönderilemeyen WAL dosyalarının tutulmasına neden olabilir. Sonuç, uygulama trafiği normal görünürken üretim sunucusunun depolama sınırına yaklaşmasıdır. Bu yazı failover kurulumunu değil, replication slot kaynaklı WAL birikmesini fark etme, nedenini ayırma ve veri güvenliğini koruyarak müdahale etme sürecini ele alır.

Replication slot neden WAL tutar?

PostgreSQL değişiklikleri WAL kayıtlarına yazar. Fiziksel replikada başka bir PostgreSQL sunucusu bu akışı izler; mantıksal replikasyonda ise abonelik veya değişiklik yakalama uygulaması tüketici olabilir. Replication slot, tüketicinin ihtiyaç duyduğu kayıtların erken kaldırılmasını önlemek için durum bilgisi tutar. Tüketici ilerlemiyorsa koruma mekanizması disk açısından bir riske dönüşebilir. Bu nedenle slot oluşturmak kadar, hangi uygulamaya ait olduğunu ve ne zaman kaldırılacağını bilmek de önemlidir.

Her WAL büyümesi slot sorunu değildir. Yoğun toplu veri aktarımı, başarısız arşivleme, uzun bakım işlemleri veya replikasyon yapılandırması da araştırılmalıdır. İlk teşhis, disk büyümesini tek bir sebebe bağlamak yerine üretim hızı, tüketim ilerlemesi ve arşivleme sağlığını birlikte değerlendirmelidir. Dosya adlarını görünce elle temizlik yapmak, sorunun nedenini saklarken geri dönüş olanaklarını da bozabilir.

Slot envanteri: Kimin tüketicisi, kimin sorumluluğu?

Her slot için sahip ekip, tüketici adresi, fiziksel veya mantıksal tür, beklenen çalışma düzeni ve son doğrulanan ilerleme kaydedilmelidir. Geçici bir veri taşıma işi için açılan slotun işlem sonrasında unutulması yaygın bir operasyon açığıdır. Slot adının tanıdık görünmesi, hâlâ gerekli olduğunu kanıtlamaz; pasif görünmesi de güvenle silinebileceği anlamına gelmez. Planlı bakım sırasında tüketici geçici olarak durmuş olabilir.

• Slotun bağlı olduğu replika, abonelik veya veri aktarım uygulamasını yazın.
• Tüketici için teknik sorumlu ve eskalasyon kişisi belirleyin.
• Planlı duruş süresini ve yeniden başlatma prosedürünü kaydedin.
• Geçici slotlara gözden geçirme tarihi ekleyin; otomatik silme kararı vermeyin.
• Primary değişiminden sonra slotların yeni topolojideki durumunu ayrıca doğrulayın.

Salt okunur sorguyla başlangıç fotoğrafı alın

Aşağıdaki örnek primary üzerinde slotların tuttuğu WAL mesafesini görmeye yardımcı olur. Yetkili izleme hesabıyla çalıştırın; kullanılan PostgreSQL sürümünün görünüm ve fonksiyon desteğini kontrol edin. Sonuç bir disk dolma süresi tahmini değildir. LSN farkı, slotun ihtiyaç duyduğu WAL konumu ile mevcut yazma konumu arasındaki mesafeyi gösterir; toplam disk kullanımını tek başına açıklamaz.

SELECT slot_name, slot_type, active,
       restart_lsn, confirmed_flush_lsn,
       pg_size_pretty(
         pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
       ) AS retained_wal_distance
FROM pg_replication_slots
ORDER BY pg_wal_lsn_diff(
  pg_current_wal_lsn(), restart_lsn
) DESC NULLS LAST;

Tek anlık çıktı yerine aynı sorgunun zaman içindeki değişimini izleyin. active=true bağlantı olduğunu söyler; tüketicinin yeterince hızlı ilerlediğini garanti etmez. Fiziksel slotta confirmed_flush_lsn boş olabilir; mantıksal slotlardaki anlamıyla değerlendirilmemelidir. Slot mesafesini işletim sistemindeki boş alan, WAL üretim hızı ve tüketici loglarıyla eşleştirin. Mantıksal slotların uzun süre tuttuğu işlem ufku ayrıca vacuum ve tablo şişmesi açısından incelenmelidir.

Alarmı yalnız doluluk yüzdesine bağlamayın

Diskin doluluk oranı geç kalmış bir alarm olabilir. Boş kapasite, son dönemdeki WAL üretim eğilimi ve tüketici ilerlemesi birlikte izlenmelidir. Normal iş yükünde günlerce yeterli görünen alan, büyük bir içe aktarma sırasında çok daha hızlı tükenebilir. Alarm eşiklerini evrensel bir yüzde yerine işin yazma yoğunluğuna ve müdahale süresine göre belirleyin.

İki seviyeli uyarı yararlıdır: önce slotun beklenen ilerleme düzeninden sapması, ardından depolamanın tehlikeli hızda azalması. Bildirim, yalnızca “disk doluyor” dememeli; ilgili slotu, tüketiciyi, son ilerleme zamanını ve sorumlu ekibi göstermelidir. Alarmın gerçekten bir insana ulaştığını kontrollü testle doğrulayın. İzleme kaydı bulunmayan bir bakım planı, sessizce büyüyen WAL riskini ortadan kaldırmaz.

Güvenli müdahale sırası nasıl olmalı?

Önce hangi dosya sisteminin büyüdüğünü ve veritabanının yazma yapabildiğini doğrulayın. Ardından tüketicinin ağ, kimlik doğrulama, işlem hatası veya kapasite sorunu nedeniyle durup durmadığını inceleyin. Mümkünse tüketiciyi sağlıklı biçimde yeniden ilerletmek, WAL zincirini koparmaktan daha güvenlidir. Yakın disk riski varsa, desteklenen yöntemle geçici kapasite sağlama ve gereksiz yazma yükünü azaltma seçeneklerini sorumlu ekip değerlendirmelidir.

pg_wal altındaki dosyaları elle silmeyin. Slot silmek de sıradan temizlik değildir: tüketicinin kaldığı yerden devam etme imkânını kaybettirebilir ve yeniden başlangıç kopyası gerektirebilir. Slotun kaldırılması ancak tüketici sahibiyle doğrulama, etkilerin kabulü ve yeniden kurulum planı sonrasında yapılmalıdır. Burada otomatik silme komutu önermememizin nedeni, depolama kazanımı ile veri sürekliliği arasındaki kararın uygulamaya özgü olmasıdır.

WAL sınırı koymak sorunu çözer mi?

Sürüm ve yapılandırmaya bağlı olarak max_slot_wal_keep_size gibi ayarlar slotların tutabileceği WAL için sınır tanımlamaya yardımcı olabilir. Ancak bu bir “bedelsiz güvenlik” seçeneği değildir. Gerekli kayıtlar kaldırıldığında tüketici devam edemeyebilir; replika veya abonelik yeniden hazırlanmak zorunda kalabilir. Ayarın değerlendirilmesi, kapasite koruması ile yeniden senkronizasyon maliyetini birlikte kapsamalıdır.

Benzer şekilde wal_keep_size disk kullanımının genel üst sınırı değildir. Bir ayarı düşürerek tüm WAL birikmesini kontrol altına aldığınızı varsaymayın. Değişiklik önce temsilî test ortamında denenmeli; yeniden başlama, bakım kesintisi ve tüketici geriden gelme senaryoları gözlenmelidir. Kalıcı çözüm, doğru boyutlandırma kadar bozuk tüketicinin kök nedenini gidermektir.

HA, yedekleme ve PITR ayrı kontrollerdir

Sağlıklı replika ve çalışan failover, geçmişteki doğru ana dönebilmeyi kanıtlamaz. PITR için uygun temel yedek, kesintisiz gerekli WAL arşivi ve doğrulanmış geri yükleme süreci gerekir. Slot sağlığını kontrol ederken arşivleme hatalarını ve yedek saklama alanını da ayrı izleyin. Replikasyon slotunu kaldırma kararı, yedek zincirinin de gereksiz olduğu anlamına gelmez.

PostgreSQL Cluster Hosting değerlendirmesinde yalnız node sayısını değil, slot envanterini, izleme sorumluluğunu ve veri kurtarma hedeflerini de konuşun. RPO, RTO, saklama süresi ve WAL arşivleme gereksinimleri ayrıca netleştirilmelidir; PITR veya özel bakım kapsamı standart pakete dâhil varsayılmamalıdır.

Operasyon toplantısına götürülecek kontrol listesi

• Tüm slotlar bir uygulamaya ve sorumlu kişiye bağlı mı?
• İlerleme mesafesi ve gerçek boş disk kapasitesi birlikte izleniyor mu?
• Tüketici durduğunda bildirim ve eskalasyon çalışıyor mu?
• Kapasite sınırının tüketiciye etkisi test edildi mi?
• Slot kaldırılmadan önce yeniden senkronizasyon planı hazırlanıyor mu?
• Yedek, WAL arşivi ve geri yükleme kanıtı ayrı kontrol ediliyor mu?

PostgreSQL kapasite, izleme ve bakım gereksinimlerinizi birlikte değerlendirelim. Mevcut sürümünüzü, replika veya veri aktarım düzeninizi ve disk büyüme gözlemlerinizi paylaşarak teknik kapsam görüşmesini somutlaştırabilirsiniz.