PostgreSQL Patroni Cluster

Patroni, PostgreSQL cluster’larında lider seçimini, rol değişimini ve otomatik failover’ı yöneten bir HA aracıdır. Veriyi PostgreSQL streaming replication taşır; Patroni hangi node’un primary olarak çalışabileceğini koordine eder. Proje belgesi bu sorumlulukları ve desteklenen bileşenleri açıklar.

Patroni kurmak, uygulamanın kesintiyi fark etmeyeceği veya her arızada sıfır veri kaybı olacağı anlamına gelmez. PostgreSQL, dağıtık koordinasyon katmanı, bağlantı yönlendirmesi ve yedekleme birlikte tasarlanmalıdır.

PostgreSQL cluster bileşenleri

DCS (Distributed Configuration Store), cluster’ın liderlik ve ortak yapılandırma bilgisini tutan koordinasyon katmanıdır; uygulama tablolarını saklamaz. Quorum, karar için gereken çoğunluğu; fencing, eski primary’nin yazmaya devam etmesini engelleyen önlemleri ifade eder.

DCS üyeleri, PostgreSQL node’ları ve proxy’ler aynı hata alanına yığılmamalıdır. Üç VM’in tek fiziksel sunucuda bulunması, o sunucu kaybedildiğinde üç bağımsız kopya sağlamaz.

Senkron mu asenkron replikasyon mu?

Patroni replikasyon modları seçimde erişilebilirlik, gecikme ve veri kaybı hedeflerinin birlikte ele alınmasını gerektirir.

• Asenkron mod: Primary, standby onayını beklemeden ilerleyebilir. Failover’da aktarılmamış işlem kaybı mümkündür. maximum_lag_on_failover bir seçim sınırıdır; tek başına sıfır kayıp garantisi değildir.
• Senkron mod (synchronous_mode): Patroni, başarılı commit almış işlemleri içerdiğinden emin olmadığı standby’ı otomatik promote etmez. Ancak strict mod kapalıysa uygun standby kalmadığında primary tek başına yazma kabul etmeye devam edebilir; bu yazmaların başka node’da kopyası garanti değildir.
• Strict senkron mod (synchronous_mode_strict): Uygun senkron standby olmadığında Patroni senkron replikasyonu devreden çıkarmaz; gerekli onayı bekleyen commit’ler bloklanır. Transaction seviyesinde synchronous_commit ayarının değiştirilmesi ve manuel failover bu korumanın kapsamını etkileyebilir.

DCS quorum’u ile PostgreSQL senkron yazma onayı farklı mekanizmalardır. Etcd çoğunluğunun mevcut olması, her işlem için yeterli veri kopyası bulunduğunu göstermez.

Failover ve split-brain kontrolü

Arıza planı yalnız yeni primary’nin seçilmesini değil, eski primary’nin yazma kabul etmeyi bırakmasını da kapsar. Watchdog desteği, belirli arıza durumlarında ek koruma için değerlendirilebilir. DCS kaybı, ağ bölünmesi ve PostgreSQL’in kapanamaması ayrı senaryolarla sınanır.

Proxy kontrolü yalnız TCP portunun açık olmasına dayanmamalıdır; node’un rolü ve trafik almaya uygunluğu doğrulanır. Uygulamada timeout ve yeniden deneme politikası bulunmalıdır. Sonucu belirsiz kalan bir transaction’ın körlemesine tekrarı aynı iş işlemini iki kez oluşturabilir.

Çok veri merkezli kurulum

Resmi çok veri merkezi rehberi, DCS yerleşimi ile senkron/asenkron modelleri ayrı ele alır. İki veri merkezli yapıda ikinci merkez için bağımsız bir standby cluster ve kontrollü promote yaklaşımı değerlendirilebilir. Karşı tarafın gerçekten kapalı olduğu doğrulanmadan iki merkezi de primary yapmak veri ayrışmasına yol açar.

Coğrafi mesafe arttıkça senkron commit gecikmesi ve bağlantı kesintilerinin etkisi ölçülmelidir. “Çok bölgeli” olmak tek başına daha yüksek erişilebilirlik kanıtı değildir.

Kurulum ve bakım kabul listesi

1. Normal işletim: Primary/replica rolleri, WAL akışı, DCS üyeliği ve erişim yetkileri doğrulanır.
2. Planlı switchover: Uygulamanın yeni primary’ye bağlanması ve devam eden işlerin sonucu kontrol edilir.
3. Arıza: Primary, DCS üyesi, proxy ve ağ bağlantısı kayıpları ayrı denenir; RTO uygulama açısından ölçülür.
4. Eski primary’nin dönüşü: pg_rewind önkoşulları veya yeniden kurulum yöntemi belirlenir. Ayrışmış verinin üzerine işlem yapmadan inceleme ihtiyacı değerlendirilir.
5. Geri yükleme: Bağımsız yedekten izole ortamda kurtarma denenir. HA testinin başarılı olması bu testin yerine geçmez.

İlgili hizmetlerimiz

Sıkça sorulan sorular