PostgreSQL yüksek erişilebilirlik tasarımında yalnız standby oluşturmak yeterli değildir. Replication mode, WAL saklama, failover tetikleme, client yönlendirme, split-brain önleme ve backup/recovery birlikte düşünülmelidir. Senkron replication veri kaybı riskini azaltırken commit latency'yi artırabilir.
PostgreSQL dokümantasyonu synchronous replication ile transaction commit'in bir veya daha fazla standby tarafından doğrulanmasını sağlayabildiğini belirtir. Bu durability seviyesini yükseltir fakat network/standby gecikmesi commit süresine yansıyabilir. Asynchronous replication daha düşük latency sunabilir fakat failover anında son WAL değişikliklerinin kaybı riski vardır.
Uygulama doğrudan primary IP'ye bağlanmak yerine virtual endpoint, HAProxy veya failover-aware service üzerinden yönlendirilebilir. Standby WAL stream'i takip eder ve gerektiğinde promote edilir.
İş yükünün latency toleransı ile veri kaybı toleransı birlikte değerlendirilmelidir.
Promotion, DNS/LB yönlendirme, fencing, client reconnect ve replication slot durumu test edilmelidir.
Komutları uygun yetkili PostgreSQL kullanıcısıyla çalıştırın.
psql -c "SELECT pg_is_in_recovery();"psql -c "SELECT application_name,state,sync_state,write_lag,flush_lag,replay_lag FROM pg_stat_replication;"psql -c "SELECT pg_current_wal_lsn();"pg_isreadyYanlış DELETE, schema hatası veya corruption replica'ya da yayılabilir. Point-in-time recovery için base backup + WAL archive gibi bağımsız recovery planı gerekir.
Tek bir sabit sayı yoktur. En temel primary + standby iki data node olabilir; otomatik quorum/failover katmanı ve witness ihtiyacı kullanılan HA aracına göre ek node gerektirebilir.
Doğru yapılandırmada commit durability'sini artırır ancak tüm sistem failure senaryoları, storage ve client davranışı ayrıca değerlendirilmelidir.
Standby/read replica normalde read-only çalışır; failover/promote sonrası primary rolünü alabilir.
DB boyutu, write rate, kabul edilebilir veri kaybı ve RTO hedefini iletin; async/sync standby ve endpoint mimarisini belirleyelim.