PostgreSQL kümelerinde Split-Brain (bölünmüş beyin) sendromu nedir ve Patroni bunu nasıl engeller?

Split-Brain, bir ağ kesintisi veya izolasyonu anında birden fazla veritabanı düğümünün kendisini aynı anda Primary (Lider) ilan ederek yazma kabul etmesidir; bu durum veritabanında geri döndürülemez veri tutarsızlıklarına yol açar. Patroni bu sorunu etcd veya Consul gibi bir Dağıtık Yapılandırma Deposu (DCS) üzerindeki Raft konsensüsü ve TTL kilitleri ile tamamen çözer. Yalnızca DCS çoğunluk quorum oylarını alan ve TTL anahtarını düzenli yenileyebilen tek bir düğüm Primary olabilir. Ağdan kopan eski Primary anında kendisini standby moduna çeker veya izole eder.

Patroni ile pg_auto_failover arasındaki temel mimari fark nedir?

Patroni, küme durumunu ve liderlik seçimini etcd/Consul gibi harici bir Raft konsensüs kümesine devreder. Bu sayede 3 veya 5 düğümlü tam hataya dayanıklı bir DCS sağlanır. pg_auto_failover ise üçüncü bir sunucuya kurulan tek bir PostgreSQL uzantılı "Monitor" düğümüne dayanır. Monitor düğümünün tekil hata noktası (SPOF) olması veya ağdan kopması durumunda failover mekanizması etkilenebilir.

Senkron (sync) ve Asenkron (async) replikasyon arasındaki RPO ve gecikme farkı nedir?

Senkron replikasyonda (synchronous_commit = on / remote_apply), bir yazma işlemi en az bir standby düğüm WAL kaydını diske yazana kadar istemciye onay dönmez; bu sayede sunucu çökse dahi sıfır veri kaybı (RPO = 0) garanti edilir, ancak her yazma işlemine veri merkezleri arası ağ RTT süresi eklenir. Asenkron replikasyonda ise commit yerel NVMe SSD fsync ile anında tamamlanır (<1.5ms); ancak Primary düğüm aniden çökerse standby'a henüz iletilmemiş son birkaç milisaniyelik WAL kayıtları kaybolabilir (RPO ~0.05 - 1s).

AWS Aurora Multi-AZ yerine VDS üzerinde Patroni kümesi kurmak ne kadar tasarruf sağlar?

AWS Aurora PostgreSQL Multi-AZ veya Google Cloud SQL HA yapılandırmaları db.r6g.xlarge benzeri orta ölçekli üretim sunucuları, ayrılmış IOPS ve replikasyon veri transferiyle aylık $750 - $1,500 civarında fatura oluşturur. VDS üzerinde 3 adet 8 vCPU / 32GB RAM sunucu ve 3 adet hafif etcd düğümü kurmak toplamda yaklaşık $170/ay maliyet yaratır; bu da kurumlara 3 yılda $20,000 - $45,000 arasında (%80+ net) bütçe tasarrufu kazandırır.

PostgreSQL Patroni vs pg_auto_failover: Yüksek Erişilebilirlik (HA) Hesaplayıcı

VDS sunucularında yüksek erişilebilir, bölünmüş beyin (Split-Brain) korumalı ve sıfır veri kayıplı (RPO=0) PostgreSQL mimarisi planlayın. Patroni, etcd Raft konsensüsü, pg_auto_failover ve CockroachDB için RTO/RPO sürelerini, yazma gecikmesini ve AWS Aurora TCO tasarrufunu simüle edin.

Veritabanı Yüksek Erişilebilirlik (HA)%80 TCO Tasarrufu

PostgreSQL Patroni vs pg_auto_failover: Yüksek Erişilebilirlik ve Split-Brain Hesaplayıcı

VDS sunucularında etcd Raft konsensüsüyle sıfır veri kayıplı (RPO=0) ve bölünmüş beyin (Split-Brain) korumalı PostgreSQL kümesi kurun.

3 Yıllık Net Tasarruf:$24,444/3 yıl

Küme & Veritabanı Parametreleri

Yazma İşlemi (Write TPS):2,500 TPS

200 TPS7.5K TPS15K TPS

Düğüm Sayısı (Nodes):3 Düğüm

3 Düğüm (1 Hata)5 Düğüm (2 Hata)7 Düğüm (3 Hata)

Replikasyon Modu:

Cross-DC Ağ Gecikmesi:3.5 ms RTT

0.5ms (Aynı DC)5ms (Metro DC)25ms (Kıta Arası)

Yönetilen Bulut (Aurora Multi-AZ):$850/ay

VDS Düğüm Maliyeti (8 vCPU / 32GB):$45/ay

etcd Quorum Kümesi (3x Hafif VM):$36/ay ($12x3)

DCS Konsensüs Modeli:etcd v3 Raft

Otomatik Failover (RTO)

14 sn

Patroni + etcd

Veri Kaybı Riski (RPO)

0 sn

Sıfır Kayıp Garantili

Split-Brain Riski

%0.0

Raft Quorum Korumalı

Yazma Gecikmesi

5.4 ms

Commit RTT gecikmesi

Raft Konsensüsü, Çökme Toleransı ve Mimari Karşılaştırması

Patroni + etcdEndüstri Standardı

Failover Süresi (RTO):14 saniye

Veri Kaybı (RPO):0 sn

Split-Brain Koruması:%100 (Raft DCS)

Tolerans Edilen Çökme:1 Düğüm

Lider düğüm etcd üzerindeki anahtarı yenileyemezse (TTL süresi dolunca), etcd liderliği düşürür ve en güncel WAL konumuna sahip standby düğüm yeni lider seçilir.

pg_auto_failoverBasit / Monitörlü

Failover Süresi (RTO):15 saniye

Veri Kaybı (RPO):0 sn (Zorunlu Sync)

Split-Brain Koruması:%99.9 (Monitör SPOF)

DCS İhtiyacı:Gerekmez (PG Monitor)

Kurulumu kolaydır ancak durum makinesi tek bir PostgreSQL monitör düğümüne bağlıdır. Monitör düğümünün ağ izolasyonunda küme kararsız hale gelebilir.

CockroachDBDağıtık SQL

Failover Süresi (RTO):4 saniye

Veri Kaybı (RPO):0 sn

Split-Brain Koruması:%100 (Multi-Raft)

Yazma Gecikmesi:Yüksek (2x RTT)

Tüm düğümler yazabilir ancak her yazma işlemi 2PC ve Raft turu gerektirdiği için gecikme PostgreSQL'e göre 3-4 kat daha yüksektir.

PostgreSQL Yüksek Erişilebilirlik (HA) ve Konsensüs Mimarisi

1. Patroni ve etcd Raft Konsensüs Mekanizması

Geleneksel Pacemaker/Corosync yapılandırmaları, STONITH (Shoot The Other Node In The Head) donanımsal güç yönetimi olmadığında ağ bölünmelerinde her iki sunucunun da kendini lider ilan etmesi (Split-Brain) riski taşır.

Patroni bu problemi modern dağıtık sistemler teorisiyle çözer. Kümenin liderliği, etcd veya Consul üzerindeki bir anahtardır (key). Lider düğüm her `loop_wait` (ör. 10 saniye) periyodunda bu anahtarı günceller. Eğer lider düğüm kilitlenir veya ağdan koparsa, `ttl` süresi (30 sn) dolduğunda etcd anahtarı serbest bırakır. Standby düğümler arasında en güncel LSN (Log Sequence Number) WAL verisine sahip olan düğüm yeni lider olarak seçilir.

2. Senkron Replikasyon ve RPO = 0 Dengesi

Finans, e-ticaret ve kritik sistemlerde tek bir işlemin dahi kaybolmaması (RPO = 0) zorunludur. PostgreSQL `synchronous_commit = on` modu ile bir transaction commit edildiğinde, en az bir standby düğümün WAL kaydını kendi diske yazdığı teyit edilene kadar istemciye başarılı yanıt verilmez.

Patroni'nin `synchronous_mode_strict: true` ayarı, tek bir standby dahi erişilemez olduğunda veri tutarsızlığını önlemek için ana sunucuyu yazmaya kapatır. Bu sayede hiçbir durumda asenkron sapma veya veri kaybı yaşanmaz.

HAProxy ve Uygulama Katmanı Trafik Yönlendirmesi

PostgreSQL kümesinde failover yaşandığında uygulamaların IP adresini manuel değiştirmesi gerekmez. Patroni her düğümde bir REST API (varsayılan 8008 portu) çalıştırır.

GET /primary

Düğüm Lider (Primary) ise HTTP 200 döner; standby ise HTTP 503 döner. Yazma havuzu doğrudan lider düğüme yönlenir.

GET /replica

Düğüm Standby/Replica ise HTTP 200 döner. Okuma (Read-Only) sorguları tüm replikalar arasında dengelenir.

pg_rewind Entegrasyonu

Çöken eski lider geri döndüğünde veritabanını sıfırdan kopyalamak yerine WAL farkını geri sararak (rewind) saniyeler içinde standby olur.