PostgreSQL High Availability: Patroni, Pgpool ve Failover 2026

Postgres high availability, 2026 yılında çoğu üretim sistemi için artık opsiyon değil temel gereksinim. Stack Overflow Developer Survey 2024 verilerine göre PostgreSQL, %49 kullanım oranıyla en çok tercih edilen veritabanı; bu yoğunlukta tek node ile devam etmek, ortalama 60 dakikalık bir kesinti senaryosunda SaaS şirketleri için yaklaşık 100.000–300.000 USD arasında gelir kaybına yol açabiliyor. Bu yazı, üretim ortamında doğrulanmış üç temel mimariyi karşılaştırıyor: Patroni + etcd + HAProxy, Pgpool-II tabanlı sanal IP yönetimi ve PostgreSQL 17 native logical failover. Hedef; RPO sıfıra, RTO 30 saniyenin altına indiren bir topoloji kurmak, split-brain riskini minimize etmek ve replikasyon lag’ini 100 ms eşiğinde tutmak. Aşağıdaki bölümlerde her bileşenin rolünü, ölçülmüş failover sürelerini, lisans/operasyon maliyetini ve hangi senaryoda hangi yaklaşımın seçilmesi gerektiğini gerçek rakamlarla açıklıyorum.

1. Postgres HA neden 2026’da farklı: rakamlar ve trendler

PostgreSQL 17, Eylül 2024’te yayınlandı ve logical replication tarafında failover slot desteği gibi HA için belirleyici özellikler getirdi. DB-Engines Mayıs 2026 sıralamasında PostgreSQL, ilk üç motor arasındaki konumunu korurken Crunchy Data, EDB ve AWS RDS gibi yönetilen sağlayıcılar üzerindeki yük yıllık yaklaşık %25 artış gösteriyor. Yüksek erişilebilirlik artık sadece finans veya telekom sektörünün konusu değil; B2B SaaS şirketlerinin SLA taahhütleri 99.95% (yıllık ~4 saat 22 dakika kesinti) eşiğini geçemeyecek hale geldi. Bu da pratikte tek-AZ tek-node mimarinin terk edilmesi anlamına geliyor.

Bu yazının kapsamı, self-managed Postgres üzerinde otomatik failover sağlayan cluster yönetim katmanları. AWS RDS Multi-AZ veya Google Cloud SQL High Availability gibi yönetilen seçenekler maliyet/kontrol dengesinde ayrı bir tartışma olduğu için ana akışta sadece karşılaştırma tablosunda referans verilecek.

SLA seviyesi	Yıllık kesinti	Aylık kesinti	Tipik mimari
99.9%	8s 45dk	43dk 49s	Tek primary + manual failover
99.95%	4s 22dk	21dk 54s	Streaming replica + Patroni
99.99%	52dk	4dk 22s	Patroni + etcd 3-node + HAProxy
99.999%	5dk 15s	26s	Multi-region + sync replica + DNS GSLB

Pratik gözlem: 99.99% seviyesi, hesaplanmış maliyet/performans optimumudur. 99.999% taahhüdü Postgres tarafında uygulama mimarisi (multi-master conflict resolution veya saga pattern) gerektirir; bu yazının kapsamı dışında.

2. Replikasyon temelleri: streaming, logical ve synchronous farkları

Postgres HA’nın altyapısı replikasyondur ve yanlış mod seçimi en sık görülen başlangıç hatasıdır. Üç temel seçenek şunlardır:

• Physical streaming replication: WAL akışını byte-byte taşır. Replikalar primary’nin tam kopyasıdır; failover’da DNS/proxy yönlendirmesi yeterlidir. Avantaj: Düşük overhead, blok-seviyesi tutarlılık. Dezavantaj: Postgres ana sürümleri arasında çalışmaz, kısmi tablo replikasyonu yapamaz.
• Logical replication (pub/sub): WAL’ı satır seviyesinde dekode eder. Avantaj: Cross-version upgrade ve seçici replikasyon. Dezavantaj: Sequence ve DDL replikasyonu PostgreSQL 17’ye kadar eksikti; failover sonrası slot rebuild gerekiyordu.
• Synchronous replication: Primary, replica’nın WAL’ı disk’e yazdığını teyit etmeden commit dönmez. Avantaj: RPO=0. Dezavantaj: Replica yavaşlığı veya kesintisi primary’yi de yavaşlatır; en az 2 sync standby önerilir.
• Quorum-based sync: synchronous_standby_names = 'ANY 1 (replica_a, replica_b)' ile en az bir replica’nın onayı yeterli sayılır. Ne zaman seç: Banka, ödeme, sipariş yönetimi gibi RPO=0 zorunlu olan workload’lar.

Replikasyon modu	RPO	Yazma latency etkisi	Cross-version	Tipik kullanım
Async streaming	1–5 sn	~0 ms	Hayır	Read replica, analytics
Sync (remote_write)	0 (memory)	+1–3 ms	Hayır	OLTP, finans
Sync (remote_apply)	0 (durable)	+5–15 ms	Hayır	Read-after-write garantisi
Logical (failover slots)	~1 sn	+2–4 ms	Evet	Major upgrade, multi-tenant

Önerilen başlangıç noktası: 1 sync + 1 async replica + WAL archive. Bu kombinasyon RPO=0 hedefini bozmadan sync replica kesintisinde dahi primary’yi açık tutar. Postgres’in dahili yapı taşlarını derinlemesine kullanmak için PostgreSQL performans optimizasyonu rehberindeki indeks ve vacuum stratejileri HA mimarisiyle paralel düşünülmelidir.

3. Patroni: dağıtık konsensüs ile otomatik failover

Patroni, Zalando tarafından 2015’te açık kaynaklandırılan ve 2026 itibarıyla GitHub’da yaklaşık 7.500+ star toplayan Python tabanlı bir cluster yöneticisidir. Çekirdek tasarım kararı, cluster state’i Postgres dışında dağıtık bir konsensüs deposunda (DCS) tutmaktır: etcd, Consul veya ZooKeeper. Bu sayede split-brain önleme net bir matematiksel temele oturur: leader lease süresi içinde DCS’e ulaşamayan node, kendini demote eder.

Tipik 3 node’lu Patroni cluster’ı şu bileşenlerden oluşur:

• 3 Postgres node (her birinde bir Patroni agent prosesi)
• 3 node’lu etcd cluster (Postgres node’larıyla aynı veya ayrı host’larda; üretimde ayrı önerilir)
• HAProxy veya pgBouncer + consul-template trafiği primary’ye yönlendirmek için
• WAL archive hedefi (S3, MinIO veya NFS) point-in-time recovery için

Failover senaryosu şöyle işler: Primary node, varsayılan 30 saniyelik TTL (ttl: 30) içinde etcd leader key’ini yenilemezse, Patroni en güncel LSN’e sahip standby’ı yeni primary olarak promote eder. Production ortamında yapılan ölçümler:

TTL ayarı	Loop wait	Retry timeout	Ortalama failover süresi	False-positive riski
30 sn (default)	10 sn	10 sn	22–28 sn	Düşük
20 sn	5 sn	10 sn	14–18 sn	Orta
15 sn	3 sn	5 sn	8–12 sn	Yüksek (network jitter)
10 sn	2 sn	3 sn	5–8 sn	Çok yüksek

30 saniyenin altına inerken etcd cluster’ının network round-trip time’ı 1 ms’in altında, disk fsync gecikmesi 5 ms’in altında tutulmalı. Aksi halde Patroni gereksiz failover (false promotion) tetikler ve uygulama tarafında sık disconnect yaşanır. Patroni’nin REST API’si (/master, /replica, /health) HAProxy httpchk ile entegre edilir; HAProxy 200 OK dönen node’u primary kabul eder. Bu mimari, Zalando’nun 2024 tarihli operasyon raporlarına göre 1.000+ Postgres cluster’da %99.99 erişilebilirlik üretiyor.

Patroni konfigürasyonunda en sık atlanan iki parametre maximum_lag_on_failover ve master_start_timeout‘tur. Birincisi, RPO toleransını byte cinsinden tanımlar (1 MB iyi başlangıç); ikincisi ise crash sonrası recovery’de standby’ın promote edilmesini ne kadar bekleyeceğini belirler. Resmi rehberlik için Patroni dokümantasyonu başvuru kaynağıdır.

4. Pgpool-II ile connection pooling + load balancing yaklaşımı

Pgpool-II, SRA OSS tarafından geliştirilen ve 2003’ten beri aktif sürdürülen bir middleware’dir. 2026 itibarıyla 4.5.x sürümünde olan Pgpool, üç işlevi tek proses altında birleştirir: connection pooling, statement-level load balancing ve watchdog tabanlı otomatik failover. Patroni’den farkı, ayrı bir DCS gerektirmemesi; bunun yerine Pgpool node’ları kendi aralarında lifecheck protokolüyle koordine olur ve bir sanal IP (VIP) üzerinden trafiği primary’ye yönlendirir.

Pgpool’un öne çıktığı senaryolar:

• Read-heavy workload: SELECT sorgularını otomatik olarak replica’lara dağıtır. Avantaj: Uygulamada read/write split kod değişikliği gerekmiyor. Dezavantaj: Transaction sınırlarını anlamak için query parser overhead’i.
• Connection pooling: Postgres’in process-per-connection modelinde 5.000+ uygulama bağlantısını 200 backend session’a indirir. Genel olarak PgBouncer transaction pooling daha hızlıdır, ancak Pgpool tek node’da pooling + LB + failover birleştirir.
• Watchdog VIP: Pgpool node’u down olursa VIP otomatik olarak diğer node’a geçer. Failover süresi tipik olarak 4–8 saniye, Patroni’den daha hızlıdır ancak Pgpool yedeği gerektirir.
• Ne zaman seç: Connection pooling + load balancing + failover’ı tek katmanda istiyor ve uygulama kodunu değiştirmek istemiyorsanız.

Özellik	Patroni + HAProxy	Pgpool-II watchdog	PgBouncer + repmgr
Failover süresi	15–30 sn	4–8 sn	20–40 sn
DCS gereksinimi	Evet (etcd/Consul)	Hayır	Opsiyonel
Connection pooling	Harici (PgBouncer)	Dahili	Evet (transaction)
Load balancing	Manuel (HAProxy)	Otomatik (SELECT)	Yok
Split-brain koruması	Çok güçlü (quorum)	Orta (watchdog)	Manuel müdahale
Operasyon karmaşıklığı	Yüksek	Orta	Düşük

Pgpool’un dikkat edilmesi gereken yanı, query parser’ın bazı pgpool versiyonlarında prepared statement’larla beklenmedik şekilde çakışmasıdır. Üretime almadan önce mutlaka pgbench -c 200 -j 4 -T 600 ile baseline alın ve karşılaştırın. Stream işleme tarafında bu pooling katmanını ek olarak değerlendirmek için stream processing içerikleri de referans olabilir; özellikle Flink CDC kaynaklarınız Postgres ise.

5. PostgreSQL 17 native logical failover ve repmgr ekosistemi

PostgreSQL 17, Eylül 2024’te yayınlandığında HA topluluğunun en çok beklediği özellik failover slot desteği oldu. Bu özellik öncesi logical replication subscriber’ları primary failover’ında manuel olarak yeniden bağlanır ve büyük ölçüde slot rebuild gerekirdi. PG17 ile failover = true parametresi sayesinde replication slot bilgisi standby’lara senkronize edilir; promote edilen yeni primary üzerinden subscriber’lar kaldıkları yerden devam eder.

repmgr, EDB (EnterpriseDB) tarafından sürdürülen klasik HA yöneticisidir ve Patroni’ye göre daha basit, daha az “akıllı” bir alternatiftir. Tek bir repmgr.conf dosyası ve repmgrd daemon’u yeterlidir; DCS gerekmez. Failover kararını cluster’daki repmgr node’ları arasında basit bir “witness” mantığıyla verir. Avantajı operasyonel sadelik; dezavantajı network partition senaryolarında Patroni kadar güçlü split-brain garantisi vermemesi.

• Patroni: Karmaşık ama bulletproof, Kubernetes-native, geniş topluluk. Ne zaman seç: 5+ cluster, multi-AZ, %99.99+ SLA.
• repmgr: Sade, ihtimal düşük cluster’da pragmatik. Ne zaman seç: Tek site, 1–3 cluster, küçük ekip.
• pg_auto_failover: Citus/Microsoft tarafından üretilmiş, monitor node + worker node modeli. Avantaj: Tek komutla setup. Dezavantaj: Monitor SPOF olmasın diye ayrı HA gerekir.
• Stolon: Sorintlab kaynaklı, Patroni alternatifi. 2024 sonrası geliştirme yavaşladı; yeni projeler için önerilmez.

6. Failover topolojisi tasarımı: quorum, witness ve fencing

HA cluster tasarımının üç temel matematiksel kuralı vardır. Birincisi: konsensüs için tek sayıda node gerekir. İki node’lu cluster split-brain’e doğal olarak yatkındır çünkü her iki node birbirini ölmüş varsayar. İkincisi: çoğunluk kuralı (quorum) cluster boyutunun yarısından fazlasıdır. 3 node’da 2, 5 node’da 3 node’un ayakta olması yeterli. Üçüncüsü: WAN üzerinden senkron replikasyon round-trip + fsync süresine bağımlıdır; 1.000 km mesafe pratik olarak +10–20 ms commit latency demektir.

Topoloji	Node sayısı	Fault tolerance	Tipik failover süresi	Bulut maliyeti (aylık, EU-region)
Single primary + 1 replica	2	0 (manuel)	5–30 dk	~$220
Patroni 3-node single-AZ	3	1	15–25 sn	~$420
Patroni 3-node multi-AZ	3	1 AZ	20–35 sn	~$520
Patroni 5-node multi-AZ + witness	5	2	15–25 sn	~$780
Multi-region async DR	3+2	1 region	2–5 dk (DNS)	~$1.150

Fencing (STONITH—”Shoot The Other Node In The Head”) başarısız primary’nin kalkıp tekrar yazma yapmasını engellemenin yoludur. Bulut ortamında IAM tabanlı API ile EC2/Compute instance’ı stop edilebilir; on-premise ortamda IPMI fencing tercih edilir. Patroni’nin callbacks mekanizması bu komutları failover sırasında otomatik tetikler. Fencing eksikliği, üretimde gördüğüm en pahalı veri kaybı senaryolarının ortak paydasıdır.

Cloud provider tarafında AWS dokümantasyonu Multi-AZ topolojiler için detaylı kılavuz sunar; AWS RDS Multi-AZ dokümantasyonu üzerinden bulut tarafındaki failover SLA’larını incelemek karşılaştırma için faydalıdır.

7. Backup, PITR ve WAL arşivleme: HA’nın görünmeyen yarısı

Replikasyon, mantıksal hatalara karşı koruma sağlamaz. DELETE FROM orders; komutu primary’de çalıştırılırsa replikalara da anında yayılır. Bu nedenle HA mimarisi backup ve point-in-time recovery (PITR) ile birlikte tasarlanmalıdır. Üç olgun seçenek: pgBackRest, Barman ve WAL-G.

• pgBackRest: Crunchy Data tarafından bakım yapılır, paralel sıkıştırma, delta restore, S3 native. Avantaj: 1 TB restore <30 dk (paralel), checksum doğrulama. Dezavantaj: Konfigürasyon dosyası karmaşık.
• Barman: 2ndQuadrant/EDB kökenli, RPO 0 sıfır-veri-kaybı modu (backup_method = postgres). Avantaj: Streaming replica üzerinden hot backup. Dezavantaj: Tek node’lu Barman host’u SPOF.
• WAL-G: Citus Data kökenli, Go ile yazılmış, multi-cloud (S3, GCS, Azure Blob). Avantaj: Düşük overhead, encrypted backup. Dezavantaj: Toplulukta Barman/pgBackRest kadar yaygın değil.

PITR için pratik hedef RPO < 5 dakikadır. Bunu sağlamak için WAL segment'leri her 60 saniyede bir S3'e arşivlenmeli (archive_timeout = 60) ve aynı bucket’a günlük base backup alınmalıdır. Restore testini ayda en az bir kez otomatize edin; doğrulanmamış backup, “var sanılan ama olmayan” backup’tır. Veri kalitesi süreçleriyle backup doğrulama testlerini birleştiren ekipler, “silent corruption” hatalarını üretime ulaşmadan yakalar.

8. Connection pooling, proxy katmanı ve uygulama tarafı entegrasyon

Postgres’in process-per-connection modeli, 200’ü aşan eşzamanlı bağlantıda memory ve context-switch maliyetini hızla artırır. Bir HA mimarisi, pooling katmanı olmadan kâğıt üzerinde mükemmel olsa bile uygulama davranışında dalgalanma yaratır. Üç ana seçenek:

Pooler	Mod	Maks connection (tipik)	Pool latency overhead	HA entegrasyonu
PgBouncer	Transaction	10.000+	~0.2 ms	Harici (HAProxy/keepalived)
Pgpool-II	Session + LB	3.000–5.000	~1–2 ms	Dahili watchdog
Odyssey	Transaction multi-thread	20.000+	~0.3 ms	Harici
Supabase Supavisor	Transaction (Elixir)	1.000.000 (claimed)	~0.5 ms	Harici

Uygulama tarafında dikkat: transaction pooler kullanırken prepared statement, advisory lock ve session-scoped GUC’lar (örn. SET timezone) beklenmedik davranır. Tipik çözüm, uygulama framework’ünde “no prepared statements” konfigürasyonu açmak veya PgBouncer 1.21+’in named prepared statement desteğini kullanmaktır.

HAProxy ile Patroni entegrasyonu için minimal sağlık kontrolü şu olur: option httpchk OPTIONS /master HTTP/1.1. HAProxy, 200 OK dönen tek node’a write trafiğini, replica endpoint’ine read trafiğini yönlendirir. Bu basit pattern, üretimde milyarlarca sorgu altında test edilmiş ve p99 latency overhead’i 1 ms’in altındadır.

9. Monitoring, observability ve chaos testing

HA cluster’ın sessizce bozulmaması için sürekli observability şarttır. Üretim kalitesi bir Postgres HA setup’ı en az şu 8 metriği saniye seviyesinde toplar:

1. Replication lag (byte ve saniye): pg_stat_replication.write_lag, flush_lag, replay_lag. Alarm eşiği: > 100 MB veya > 30 sn.
2. WAL üretim hızı: pg_current_wal_lsn() üzerinden dakikalık delta. Anormal artış disk doluluğu riski.
3. Connection sayısı ve uzun-süren transaction: pg_stat_activity üzerinden state = 'idle in transaction' > 60 sn alarm.
4. Patroni state ve etcd health: Patroni REST API /health, etcd /health.
5. Lock waits ve deadlock: pg_locks üzerinden bekleyen lock sayısı.
6. Cache hit ratio: pg_stat_database.blks_hit / (blks_hit + blks_read) > 0.99 hedef.
7. Checkpoint sıklığı: pg_stat_bgwriter.checkpoints_timed / checkpoints_req oranı > 0.9 ideal.
8. Disk IOPS ve fsync latency: 5 ms’in üzerine çıkarsa sync replication problemli.

Prometheus + postgres_exporter + Grafana stack’i de-facto standart. Patroni’nin kendi exporter’ı da etcd state’ini metric olarak yayınlar. Üretime almadan önce mutlaka chaos testing yapın: kill -9 primary, iptables DROP ile network partition simülasyonu, tc qdisc ile artificial latency. Cluster’ın bu senaryolarda gerçek davranışı yazılı runbook’tan farklı olabilir. Bu tür mühendislik denetimlerini bağımsız bir gözle yaptırmak için Ömer Önal’ın veritabanı mimarisi danışmanlığı kapsamında yürütülen HA-readiness değerlendirmesi, çoğu ekibin gözden kaçırdığı fencing, replication lag eşik ve restore test eksiklerini çıkarır.

10. Karar çerçevesi: hangi mimari hangi senaryo için?

İdeal mimari, SLA hedefi, ekip büyüklüğü ve veri hacmiyle birlikte belirlenir. Aşağıdaki matris pratik karar verme için kullanılabilir:

Senaryo	SLA	Veri hacmi	Önerilen mimari	Aylık operasyon yükü
Startup MVP	99.9%	< 100 GB	Yönetilen Postgres (RDS, Cloud SQL)	~2 saat
Orta ölçek SaaS	99.95%	100 GB – 1 TB	Patroni 3-node single-AZ + pgBackRest	~10 saat
B2B enterprise	99.99%	1–10 TB	Patroni 3-node multi-AZ + sync replica + WAL-G	~25 saat
Finansal/Sigorta	99.99%+	10 TB+	Patroni 5-node multi-region + quorum sync + DR site	~60 saat
Read-heavy analytics	99.9%	Değişken	Pgpool-II + 3–5 read replica	~15 saat

Postgres HA’yı, daha geniş veri mimarisi içinde değerlendirmek gerekir; özellikle OLTP veritabanının arkasındaki analytics katmanı ayrı bir yatak olarak ele alınmalıdır. BigQuery vs Snowflake ya da data lakehouse içerikleri bu ayrımı netleştirir; Postgres’i tek başına analytics motoru olarak konumlandırmak 1 TB üzeri workload’larda dezavantaj yaratır.

Ek olarak topluluk benchmark referansları için PostgreSQL resmi HA dokümantasyonu, vendor karşılaştırması için Percona Database Performance blog ve cluster orchestration patterns için Crunchy Postgres Operator GitHub başvuru kaynaklarıdır. Stack Overflow Developer Survey 2024 sonuçlarının tamamına ise Stack Overflow 2024 Technology Survey sayfasından erişilebilir.

Sıkça Sorulan Sorular (SSS)

Sonuç

Postgres yüksek erişilebilirlik mimarisi, 2026 itibarıyla artık “advanced topic” olmaktan çıkıp her ciddi üretim sisteminin temel taşı haline geldi. Patroni + etcd + HAProxy kombinasyonu, açık kaynak ekosistemde en olgun ve en geniş topluluğu olan referans mimaridir; %99.99 SLA hedefini 20–30 saniyelik failover’la güvenle karşılar. Pgpool-II ise read-heavy workload ve uygulama-şeffaf load balancing senaryolarında değerini kanıtlar. PostgreSQL 17’nin failover slot desteği logical replication tabanlı senaryoları artık üretim sınıfı yapar; major version upgrade ve multi-tenant ayrıştırma için somut bir adım atılmıştır.

Karar çerçevesi nettir: SLA hedefini önce belirleyin, ardından veri hacmi ve ekip kapasitesini değerlendirin; bu üç değişken topolojiyi büyük ölçüde tek bir yolda buluşturur. Replication, backup, monitoring ve chaos testing dört saç ayaktır; biri eksik kalan HA mimarisi gerçek bir kriz anında çatırdar. Mevcut Postgres mimarinizin failover süresini, RPO ölçümünü ve restore test düzenliliğini gözden geçirmek için iletişim sayfası üzerinden HA-readiness assessment talep edebilir, kendi cluster’ınız için somut bir yol haritası alabilirsiniz.

Veri mimarisinin daha geniş resmi içinde Postgres HA bir başlangıç noktasıdır; akışkan veri (CDC, event streaming) ve modern analytics platformlarıyla birleştiğinde sistemin tamamı dayanıklı hale gelir. Spark ve Kafka tabanlı pipeline’lar ile entegre çalışan bir Postgres katmanı, hem operasyonel hem analitik yükü dengeli taşır.