PostgreSQL ortamında bir replica bulunması, sistemin primary kaybına hazır olduğu anlamına gelmez. Replikasyon akıyor olabilir; fakat uygulama yeni primary’ye bağlanamıyor, veri kaybı sınırı bilinmiyor veya eski primary tekrar açıldığında split-brain riski oluşuyorsa yüksek erişilebilirlik hedefi tamamlanmış değildir. Failover testi, bu belirsizlikleri kontrollü bir bakım penceresinde ölçülebilir hale getirir.

Replikasyon, failover ve backup aynı şey değildir

Streaming replication, WAL değişikliklerini primary’den replica’ya taşır. Failover, primary hizmet veremediğinde uygun replica’nın yazma kabul eden yeni primary rolüne geçirilmesi ve uygulama trafiğinin ona yönlendirilmesidir. Backup ve PITR ise silinmiş, bozulmuş veya yanlış değiştirilmiş veriyi geçmişteki bir noktaya döndürmek için kullanılır.

Replikasyon mantıksal hatayı da hızlıca kopyalayabilir. Yanlış bir DELETE, uygulama bug’ı veya bozuk veri replica’ya ulaştığında HA katmanı erişilebilirliği korusa bile recoverability sağlamaz. Bu nedenle failover tatbikatı ile backup/PITR restore tatbikatı ayrı planlanmalı ve ayrı başarı kriterlerine sahip olmalıdır.

Testten önce başarı kriterlerini yazın

“Failover çalıştı” ifadesi ölçülebilir değildir. Tatbikat başlamadan önce hedef süreleri ve kabul edilen veri kaybı sınırını tanımlayın. RTO, hizmetin ne kadar sürede yeniden kullanılabilir olacağını; RPO ise kabul edilebilen veri kaybı aralığını ifade eder. Asenkron replikasyonda son işlemlerin replica’ya ulaşmamış olma ihtimali vardır; senkron replikasyon ise gecikme ve kullanılabilirlik üzerinde farklı maliyetler yaratır.

• Primary arızası kaç saniyede algılanmalı?
• Replica promotion ne kadar sürmeli?
• Uygulama yeni yazma noktasına ne kadar sürede bağlanmalı?
• Kaç transaction kaybı kabul edilebilir?
• Eski primary’nin geri dönmesi nasıl engellenecek?
• Tatbikat başarısız olursa geri dönüş kararı kimde?

Replikasyon sağlığını failover öncesi doğrulayın

Test, zaten bozuk olan bir replica üzerinde başlatılmamalıdır. Primary’de replica bağlantılarını, WAL gönderim durumunu ve gecikmeyi; replica’da recovery durumunu, son alınan ve replay edilen WAL konumlarını kontrol edin. Disk doluluğu, archive başarısızlıkları, saat farkı ve network gecikmesi de sonuçları etkiler.

-- Primary üzerinde
SELECT application_name, state, sync_state,
       write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

-- Replica üzerinde
SELECT pg_is_in_recovery(),
       pg_last_wal_receive_lsn(),
       pg_last_wal_replay_lsn(),
       pg_last_xact_replay_timestamp();

Bu sorgular anlık görünüm sağlar. Alarm eşiği, iş yükünün normal davranışına göre belirlenmelidir. Sadece “streaming” durumunu görmek yeterli değildir; replay gecikmesi, WAL arşivi, replication slot büyümesi ve disk kapasitesi birlikte izlenmelidir.

Uygulama bağlantı yolunu haritalayın

Veritabanı rolü değişse bile uygulama eski IP veya hostname’e bağlı kalabilir. Bağlantı havuzu, DNS TTL, load balancer, virtual IP, service discovery ve uygulama retry davranışı failover süresinin gerçek belirleyicileridir. PgBouncer kullanılıyorsa mevcut bağlantıların ne zaman düşeceği ve yeni bağlantıların hangi backend’e gideceği ayrıca test edilmelidir.

Uygulama tarafında yalnızca “bağlantı kurulabiliyor” kontrolü yapmayın. Okuma, yazma, transaction, migration lock ve kritik iş akışlarını kapsayan sentetik test hazırlayın. Retry mekanizması sınırsız olmamalı; aynı isteğin iki kez çalışması veri çoğaltıyorsa idempotency kontrolü gerekir.

Planlı failover tatbikatı nasıl yürütülür?

1. Değişiklik kaydını açın: kapsam, sorumlu, bakım penceresi, iletişim kanalı, rollback eşiği ve beklenen metrikleri yazın.
2. Backup durumunu doğrulayın: son base backup, WAL arşivi ve ayrı restore testinin sonucunu kontrol edin. Failover, yedek yerine geçmez.
3. Kontrollü test verisi oluşturun: tatbikat öncesi benzersiz bir kayıt yazarak promotion sonrasında görünürlüğünü ölçün.
4. Primary erişimini kesin: seçilen senaryoya göre servisi durdurun veya ağ erişimini kontrollü biçimde kapatın. Rastgele güç kesintisiyle başlamayın.
5. Algılama ve promotion süresini ölçün: otomasyon varsa karar loglarını; manuel süreç varsa komut ve onay zamanlarını kaydedin.
6. Trafiği yeni primary’ye yönlendirin: proxy, DNS veya service discovery katmanını doğrulayın; bağlantı havuzlarını gerektiği kadar yenileyin.
7. Uygulama testlerini çalıştırın: login, kritik okuma/yazma, queue tüketimi ve background job davranışını kontrol edin.
8. Eski primary’yi fence edin: iki düğümün aynı anda yazma kabul etmesini engelleyin.

Split-brain ve eski primary riski

En tehlikeli senaryolardan biri, ağ bölünmesi sırasında eski primary’nin yazma kabul etmeye devam etmesidir. Yeni primary promotion edildiğinde iki farklı veri geçmişi oluşabilir. Fencing; eski düğümün ağ, storage veya servis düzeyinde yazma yeteneğini kesin olarak kaldırır. Otomatik failover çözümü kullanılsa bile fencing davranışı belgelenmeli ve tatbikatta doğrulanmalıdır.

Eski primary tekrar açıldığında doğrudan cluster’a eklenmemelidir. Timeline farkı ve veri durumu incelenmeli; uygun olduğunda pg_rewind veya temiz base backup ile replica olarak yeniden kurulmalıdır. Hangi yöntemin kullanılacağı veri ayrışmasına, WAL erişimine ve operasyon politikasına bağlıdır.

Failback’i ayrı bir değişiklik olarak yönetin

Yeni primary hizmet veriyorsa hemen eski topolojiye dönmek zorunlu değildir. Failback yeni bir riskli değişikliktir: replikasyonun yeniden kurulması, bağlantı yönünün değiştirilmesi ve uygulama testlerinin tekrarlanması gerekir. Yoğun olay anında alışkanlık nedeniyle yapılan acele failback, ikinci bir kesinti yaratabilir.

Tatbikat sonunda gerçekleşen algılama, promotion, trafik geçişi ve uygulama toparlanma sürelerini kaydedin. Hedef RTO ile gerçekleşen RTO arasındaki farkı; eksik otomasyon, DNS cache, connection pool veya insan onayı gibi gerçek nedenlere ayırın.

Otomatik failover kararını tek başına araca bırakmayın

Failover yöneticisi, health check veya quorum tabanlı otomasyon karar süresini kısaltabilir; fakat yanlış alarmı doğru karara dönüştürmez. Sadece primary portuna bağlanamamak, gerçekten primary’nin kaybedildiğini göstermeyebilir. Ağ bölünmesi, DNS hatası, proxy sorunu veya monitoring kaybı aynı belirtiyi üretebilir. Otomasyonun hangi sinyalleri kullandığını, kaç başarısız kontrolden sonra promotion yaptığını ve kararsız bağlantıda nasıl davrandığını belgeleyin.

Quorum üyesi kaybı, tek replica ile çalışma, gecikmesi yüksek replica ve dolu WAL diski gibi sınır durumlarını da staging’de test edin. Otomatik sistem, güvenli karar veremediğinde işlemi durdurup operatör onayı istemelidir. Amaç her durumda otomatik promotion yapmak değil; veri bütünlüğünü koruyarak öngörülebilir bir karar üretmektir.

PostgreSQL failover kontrol listesi

• Primary ve replica sürümleri, extension’lar ve yapılandırma uyumlu.
• Replication lag, WAL archive, slot ve disk alarmları aktif.
• RPO/RTO hedefleri ile kabul edilen veri kaybı yazılı.
• Uygulama, pooler ve proxy’nin yeni primary’ye geçiş yöntemi test edilmiş.
• Fencing ve split-brain engelleme mekanizması doğrulanmış.
• Eski primary için rejoin/rewind/rebuild prosedürü mevcut.
• Backup/PITR restore testi failover’dan ayrı ve güncel.
• Olay sahibi, karar yetkisi, iletişim akışı ve rollback eşiği belirli.

PostgreSQL yüksek erişilebilirlik planını netleştirin

PostgreSQL’de yüksek erişilebilirlik; yalnızca iki sunucu kurmak değil, bağlantı yönlendirme, fencing, gözlemleme ve tatbikat disiplinidir. Narweb PostgreSQL Cluster Hosting yaklaşımını inceleyebilir; mevcut topolojinizi, beklenen RPO/RTO’yu ve backup/PITR gereksinimlerinizi paylaşmak için teknik görüşme talep edebilirsiniz. Replikasyon ve failover tasarımının, geri yükleme planından ayrı doğrulanması gerektiğini unutmayın.