PostgreSQL Replication: Streaming, Logical ve Failover 2026

Postgres replication, modern veri mimarilerinde yüksek erişilebilirlik, okuma ölçeklendirme ve sıfıra yakın veri kaybıyla felaket kurtarma sağlamanın temel mekanizmasıdır. 2026 itibarıyla PostgreSQL 17 sürümü streaming replication için WAL akışında ortalama 1-3 ms latency, logical replication için ise tablo bazlı seçici replikasyon ve sürüm yükseltmesi sırasında kesintisiz cutover imkânı sunuyor. EDB 2025 anketine göre üretim ortamlarındaki Postgres kurulumlarının %78’i en az bir replika çalıştırıyor; bunların %64’ü streaming, %22’si logical, geri kalanı karma yapı kullanıyor.

Bu kılavuz; streaming ve logical replication mimarilerini, synchronous/asynchronous trade-off’larını, Patroni ve repmgr ile failover otomasyonunu, pgBackRest ile PITR entegrasyonunu, replication slot yönetimini ve 2026 itibarıyla üretim ortamında karşılaşılan tipik hata senaryolarını somut rakamlarla ele alıyor. Hedef; tek node Postgres’ten çok node’lu yüksek erişilebilir mimariye geçişte teknik karar çerçevesini netleştirmek.

Postgres Replication Mimarileri: Streaming ve Logical Karşılaştırması

PostgreSQL iki birincil replication modeli sunar. Streaming (fiziksel) replication, primary node’daki Write-Ahead Log (WAL) kayıtlarını byte düzeyinde ikinci node’a aktarır; replica primary’nin bire bir kopyasıdır ve şema değişikliklerinden DDL’e kadar her şey otomatik aktarılır. Logical replication ise WAL kayıtlarını mantıksal değişiklik akışına (INSERT, UPDATE, DELETE) dönüştürür ve publication/subscription modeli üzerinden seçici olarak hedef veritabanına işler.

Streaming replication, replica’nın tam olarak primary ile aynı binary sürüm ve mimaride çalışmasını gerektirir; bu yüzden sürüm yükseltmelerinde kullanılamaz. Logical replication ise farklı major sürümler (örneğin 15’ten 17’ye) arasında çalışabildiği için sıfır kesintili upgrade senaryolarının vazgeçilmezidir. EDB’nin 2025 ortak benchmark raporunda 10 GB veri seti için logical replication başlangıç senkronizasyonu ortalama 14 dakika, streaming için ise base backup süresi olarak ortalama 6 dakika ölçülmüştür.

Özellik	Streaming (Physical)	Logical
Replikasyon birimi	WAL bytes	Row-level değişiklikler
Sürüm uyumu	Aynı major + arch	Farklı major OK (10+)
Seçici tablo replikasyonu	Hayır (tüm cluster)	Evet (publication ile)
DDL replikasyonu	Otomatik	Manuel (PG 17 öncesi)
Replica yazılabilir mi	Hayır (read-only)	Evet (yazma izinli)
Tipik latency	1-5 ms	10-50 ms
WAL overhead	~%0 ek	%8-15 ek (replica identity)
Failover’da uygun	Evet (HA için ideal)	Sınırlı
Cross-platform	Hayır	Evet

Streaming replication’ı yüksek erişilebilirlik, sıcak yedekleme ve okuma ölçeklendirme için seçin. Logical replication’ı ise sıfır kesintili sürüm yükseltmeleri, çoklu veritabanı konsolidasyonu, farklı bölgelere seçici tablo dağıtımı ve veri ambarına CDC (change data capture) akışı için tercih edin. İki modelin birlikte çalıştığı hibrit senaryolar da yaygındır; örneğin streaming ile HA kümesi kurup logical ile Kafka pipeline’ı üzerinden analitik tarafa veri akıtmak tipik bir desendir.

Streaming Replication Kurulumu ve Konfigürasyonu

Streaming replication için primary node’da WAL üretimini ve replikasyon bağlantısını etkinleştirmek gerekir. postgresql.conf dosyasında wal_level = replica (logical da yapacaksa logical), max_wal_senders = 10, wal_keep_size = 2GB ve hot_standby = on ayarları temel başlangıçtır. pg_hba.conf dosyasında ise replikasyon kullanıcısı için host replication replicator /32 scram-sha-256 satırı eklenir.

Replica node’da pg_basebackup -h primary_host -D /var/lib/postgresql/17/main -U replicator -P -R -X stream komutu çalıştırılır. -R flag’i standby.signal dosyasını ve primary_conninfo ayarını otomatik oluşturur. PostgreSQL 17 ile gelen pg_createsubscriber aracı, mevcut bir streaming replica’yı logical subscriber’a dönüştürebilmeyi sağlar ve majör versiyon yükseltme senaryolarında kullanışlıdır.

Parametre	Önerilen Değer (üretim)	Açıklama
wal_level	replica veya logical	WAL detay seviyesi
max_wal_senders	10-20	Eşzamanlı stream sayısı
max_replication_slots	10-20	Aktif slot kapasitesi
wal_keep_size	2-8 GB	Replica yeniden bağlanma buffer’ı
hot_standby	on	Read-only sorgular replica’da
hot_standby_feedback	on	Vacuum çakışmasını önler
max_standby_streaming_delay	30s veya -1	Sorgu iptali eşiği
synchronous_commit	on / remote_apply	Durability seviyesi
archive_mode	on	WAL arşivleme PITR için

Synchronous replication’da primary, en az bir replica WAL’i yazana kadar commit’i bekletir; bu mod zero data loss sağlar ancak primary commit latency’sini %20-40 oranında artırabilir. Bu yüzden çoğu üretim ortamı, finans dışı uygulamalarda asynchronous moda kalır ve synchronous_standby_names‘i sadece kritik tablolar veya specific veritabanları için aktif eder. PostgreSQL resmi dokümantasyonu tüm WAL gönderici ayarlarını detaylı listelemektedir.

Replication Slots ve WAL Retention Yönetimi

Replication slot, replica’nın primary’den henüz teslim almadığı WAL segmentlerinin silinmesini engelleyen bir mekanizmadır. Fiziksel slot streaming için, logical slot ise logical replication için kullanılır. Slot olmadan replica geçici olarak ofline kaldığında primary, wal_keep_size sınırını aştığında WAL’i silebilir; bu durumda replica yeniden bağlandığında “requested WAL segment has already been removed” hatası alır ve base backup ile sıfırdan kurulum gerekir.

Slot kullanmanın bedeli ise disk dolu kalma riskidir. Ofline kalan bir replica veya yanlış konfigüre edilmiş bir logical subscriber, primary’de WAL birikmesine yol açar. 2024’te Crunchy Data müşteri verisine göre üretim outage’larının %12’si terkedilmiş slot kaynaklı disk full sorunlarından kaynaklanıyor. Bu yüzden her slot için izleme zorunludur.

• pg_replication_slots view: active, restart_lsn, confirmed_flush_lsn kolonları izlenmelidir.
• Slot lag metrikleri: pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) ile slot başına biriken WAL byte ölçülür.
• Otomatik temizlik: Prometheus + Alertmanager ile slot lag > 5 GB eşiği aşıldığında uyarı, > 20 GB için otomatik pg_drop_replication_slot opsiyonu.
• Failover slot: PG 17’den itibaren failover attribute’ü ile logical slot’lar standby’a otomatik replike olur, böylece failover sonrası subscriber’lar tekrar bağlanır.

Slot yönetiminde “fail-safe” prensibi: max_slot_wal_keep_size parametresini ayarlayın (örneğin 50 GB). Bu sınır aşıldığında slot invalid olur; replikasyon kopar ama primary disk dolmaz. Veri kaybını önlemenin değil, mevcut bir cluster’ı ayakta tutmanın yolu budur.

Logical Replication: Publication, Subscription ve PG 17 Yenilikleri

Logical replication, PostgreSQL 10’da temel formuyla geldi ve her major sürümde olgunlaştı. Temel mimari iki katmandır: Publisher tarafında CREATE PUBLICATION my_pub FOR TABLE orders, customers komutu ile yayınlanacak tablolar tanımlanır; Subscriber tarafında ise CREATE SUBSCRIPTION my_sub CONNECTION 'host=primary dbname=app user=replicator' PUBLICATION my_pub ile abonelik kurulur.

PostgreSQL 17 (Eylül 2024 yayını), logical replication için kritik üç iyileştirme getirdi:

1. Failover slot desteği: Logical replication slot’ları standby node’a otomatik kopyalanabiliyor, böylece primary çöktüğünde subscriber’lar yeni primary’ye geçişte slot durumlarını koruyor.
2. pg_createsubscriber aracı: Var olan bir physical standby’ı tek komutla logical subscriber’a dönüştürüyor, başlangıç senkronizasyonunu sıfırdan yapma ihtiyacını ortadan kaldırıyor.
3. DDL senkronizasyonu (sınırlı): Belirli tablo değişikliklerinin (yeni sütun ekleme dahil) subscriber’a otomatik yansıması, ancak tam DDL replication hâlâ extension’larla (pglogical, OrioleDB) destekleniyor.

Senaryo	Logical Replication Faydası	Tipik Performans
Sıfır kesintili major upgrade	PG 15 → PG 17 cutover, <1 dk downtime	1 TB veri için ~2-4 saat ön senkron
CDC pipeline’ı (Kafka, Debezium)	Row-level event stream	10K row/sn throughput tipik
Multi-region replikasyon	Seçili tabloları farklı coğrafyaya	50-200 ms cross-region latency
Veri ambarına CDC	Snowflake/BigQuery’ye akış	10-30 sn end-to-end lag
Tenant ayrımı	Tek tenant tablosunu farklı DB’ye	Per-tenant logical slot

Logical replication’ın iki temel kısıtı vardır: large object replikasyonu yok (bytea kullanın), ve sequence değerleri tam replike edilmez (failover’da sequence senkronizasyonu manuel yapılır). Üretim ortamında CDC odaklı senaryolar için Debezium PostgreSQL connector tercih ediliyor; raporlama tarafına akış için ise stream processing katmanı ile birleştiriliyor. Resmi yenilikler için PostgreSQL 17 release notes başvuru kaynağıdır.

Synchronous vs Asynchronous: Durability ve Performans Trade-off’u

Replication topolojisinde en kritik karar synchronous_commit ayarıdır. PostgreSQL beş farklı durability seviyesi sunar; her biri farklı latency ve veri kaybı garantisi sağlar.

synchronous_commit	Garantili Durum	Ekstra Latency	Potansiyel Veri Kaybı
off	Bellekte commit	Sıfır	Son ~200 ms (primary crash)
local	Primary diske flush	~1 ms	Primary kalıcı arıza: tüm replikasız veri
on (default)	Primary fsync + local	~1-3 ms	Primary disk arızası: aynı
remote_write	Replica OS cache’e yazıldı	+1-5 ms (LAN)	Replica OS crash riski
remote_apply	Replica WAL replay etti	+2-8 ms (LAN)	Sıfır (replica reads dahil tutarlı)

Çoğu OLTP uygulaması on ile çalışır ve disk redundancy’ye (RAID, EBS multi-AZ) güvenir. Finansal işlem, kimlik doğrulama veya ödeme akışlarında remote_write minimum, remote_apply ise cross-region read-after-write senaryolarında tercih edilir. AWS Aurora PostgreSQL ve Google Cloud SQL HA tier’leri default olarak synchronous mode kullanır; bu modelde commit latency ortalama 3-7 ms ölçülürken async modda 1-2 ms aralığındadır.

Synchronous replication’da tek standby’ın donması tüm yazma işlemlerini bloklar. Bu yüzden synchronous_standby_names ayarında ANY 1 (replica1, replica2, replica3) formatı kullanılır; üçünden en az biri WAL’i alırsa commit ilerler. Production’da en az 3 sync replica bulundurmak quorum esnekliği için standarttır.

Failover Otomasyonu: Patroni, repmgr ve pg_auto_failover

Manuel failover üretim ortamında kabul edilemez; primary çöktüğünde dakikalar saniye dolarken her saniyenin operasyonel maliyeti vardır. Üç ana açık kaynak çözüm üretimde dominanttır: Patroni, repmgr ve pg_auto_failover.

• Patroni (Zalando):
  • Avantaj: Endüstri standardı, Kubernetes-native operator desteği (CrunchyData, Zalando Postgres Operator), DCS (Consul/etcd/ZooKeeper) ile leader election.
  • Dezavantaj: Kurulum karmaşıklığı, etcd/Consul cluster gereksinimi.
  • Ne zaman seç: Kubernetes ortamı, çok node’lu HA, otomasyon önceliği.
• repmgr (EDB):
  • Avantaj: Bare-metal/VM kurulumda basit, witness node modeli, yıllardır kanıtlanmış.
  • Dezavantaj: Cloud-native değil, manuel network fencing.
  • Ne zaman seç: Geleneksel sunucu, 2-3 node, az operasyon yükü.
• pg_auto_failover (Microsoft/Citus):
  • Avantaj: Tek monitör node, basit konfigürasyon, formal verification (TLA+).
  • Dezavantaj: Monitor SPOF riski, sınırlı topoloji.
  • Ne zaman seç: Küçük cluster, hızlı PoC.

Çözüm	DCS Gereksinimi	Tipik Failover Süresi	K8s Operator	Lisans
Patroni	etcd/Consul/ZK	15-30 sn	Evet	MIT
repmgr	Yok (kendi)	30-60 sn	Sınırlı	GPLv3
pg_auto_failover	Yok (monitor)	10-20 sn	Yok	PostgreSQL
Stolon	etcd/Consul	20-40 sn	Evet	Apache 2.0
EDB EFM	Yok	10-30 sn	Yok	Ticari

Failover otomasyonunda en kritik bileşen split-brain önleme‘dir. Eski primary network izolasyonu kalktığında ikinci primary olarak yazma kabul ederse veri tutarsızlığı doğar. Patroni bunu watchdog (softdog kernel modülü) ve DCS lease modeli ile çözer; eski primary lease’i kaybettiğinde kendini fence eder. Production’da Patroni dokümanı ve GitHub repository referans kaynaklarıdır; Patroni 16.4K GitHub yıldızı ile en aktif Postgres HA projesidir.

PITR, Backup ve pgBackRest Entegrasyonu

Replication tek başına felaket kurtarma değildir. Replikasyon kullanıcı hatalarını da replike eder: yanlış DELETE komutu saniyeler içinde tüm replica’lara yayılır. Bu yüzden Point-In-Time Recovery (PITR) için ayrı bir WAL arşiv ve base backup stratejisi şarttır.

pgBackRest 2026 itibarıyla üretimde en yaygın açık kaynak Postgres backup aracıdır. Paralel backup, incremental/differential modlar, S3/Azure Blob/GCS hedefleri, otomatik retention ve encryption sunar. pgBackRest resmi sitesi kurulum ve konfigürasyon kılavuzu içerir. WAL-G ve Barman alternatifleridir.

• Tam (full) backup: Haftalık, tüm cluster snapshot’ı. 1 TB cluster için pgBackRest ile paralel 8 process: ~45 dk.
• Differential: Son tam backup’tan farkları, 4 saatte bir veya günlük. Tipik boyut: tam backup’ın %5-15’i.
• Incremental: Son backup’tan (full/diff/incr) farkı, saatlik. PostgreSQL 17 native block-level incremental backup ile entegre.
• Continuous WAL archiving: archive_command ile her segment (16 MB) S3’e push. PITR için 1 saniyelik granülariteyi sağlar.
• Retention policy: 35 gün WAL + 4 hafta tam backup tipik finans ortamı; 7 gün + 1 hafta SaaS için yeterli.

Backup’ın değeri ancak restore testiyle kanıtlanır. AWS 2024 reliability raporuna göre düzenli restore testi yapan organizasyonlarda gerçek felaket senaryosunda RTO hedefleme oranı %92, yapmayanlarda %41. Otomatik aylık restore drill’i CI/CD pipeline’ına entegre edilmelidir. Backup mimarisi tasarlanırken PostgreSQL performans optimizasyonu rehberindeki I/O tuning prensipleri de göz önünde bulundurulmalıdır.

Monitoring, Alerting ve Replication Lag Yönetimi

Replication sağlığını sürekli izlemek operasyonel olgunluğun temelidir. Kör çalışan bir cluster, replica gerçekten lag yaparken veya slot patladığında sessizce çöker. Üretim ortamında izlenmesi gereken metrikler:

Metrik	Kaynak	Uyarı Eşiği	Müdahale
Replication lag (saniye)	pg_stat_replication.replay_lag	> 10 sn (OLTP), > 60 sn (analitik)	I/O bottleneck inceleme
Lag (bytes)	pg_wal_lsn_diff	> 1 GB	Replica resource artışı
Slot WAL retain	pg_replication_slots	> 10 GB	Slot temizliği veya yeni replica
Streaming bağlantı durumu	pg_stat_replication.state	≠ streaming > 5 dk	Bağlantı sorun analizi
WAL üretim hızı	pg_stat_wal	> 2x baseline	Application audit, vacuum aktif mi
Failover sayısı (24s)	Patroni logları	> 1	Network/disk root cause
Sync replica eksikliği	pg_stat_replication.sync_state	quorum altı > 30 sn	Sync mode disable kararı

Açık kaynak izleme stack’inde Prometheus + postgres_exporter + Grafana yaygın seçim. postgres_exporter 3K+ GitHub yıldızı ile community standard. PGAnalyze, Datadog APM ve EDB Postgres Enterprise Manager (PEM) ticari alternatifler. Ömer Önal danışmanlık projelerinde Prometheus + Patroni + pgBackRest stack’i ile ortalama 15 saniyelik RTO ve sıfıra yakın RPO hedefini başaran HA kurulumları teslim ediliyor.

Logical replication için ayrıca pg_stat_subscription view’ı subscriber tarafında lag ve apply worker durumunu gösterir. Subscriber’da apply paralelliği PG 16’dan itibaren artırılmıştır; max_parallel_apply_workers_per_subscription = 4 ayarı 4x throughput sağlayabilir.

2026 Trend: Active-Active, Cloud Native ve Multi-Master Çözümler

Single-primary Postgres yıllardır multi-region active-active eksikliğiyle eleştirildi. 2024-2026 döneminde üç önemli gelişme yaşandı:

1. pgEdge Distributed Postgres: BiDirectional Logical Replication (BDR) açık kaynak fork’u, conflict resolution (last-write-wins, CRDT bazlı) ve multi-region active-active replikasyon. 2025’te 1.0 stable.
2. CloudNativePG operator: CNCF Sandbox projesi, Kubernetes üzerinde production-grade Postgres. 3500+ GitHub yıldızı, cloudnative-pg.io.
3. Neon Branching: Storage/compute ayrımı, copy-on-write branching, serverless Postgres. Veri replikasyonu altyapısı seviyesinde yapıldığı için kullanıcı transparan.

Çözüm	Topoloji	Conflict Çözümü	Lisans/Maliyet	Olgunluk
pgEdge	Multi-master	LWW + CRDT	Open + Enterprise	Stable 1.x
EDB BDR (Postgres Distributed)	Multi-master	LWW + Eager	Ticari	Olgun (10+ yıl)
CloudNativePG	Primary + replicas (K8s)	N/A (single primary)	Apache 2.0	Stable
Citus (extension)	Distributed shards	N/A	Open + Azure managed	Olgun
Aurora PostgreSQL Limitless	Distributed (AWS)	N/A	Managed	GA 2024

Active-active mimari her uygulamaya uygun değildir. Eş zamanlı satır güncellemesi olan finansal sistemler conflict resolution semantiğinin uygulama mantığına uygun olduğundan emin olmalı. Data mesh mimarisi gibi domain-owned yaklaşımlarda bölgesel veri sahipliği active-active ihtiyacını azaltabilir; çoğu kuruluş için Patroni + streaming replication + multi-region read replica modeli operasyonel açıdan daha sürdürülebilir.

Sık Sorulan Sorular (SSS)

Sonuç

Postgres replication 2026 itibarıyla, basit master-slave akışından çok daha olgun bir ekosisteme dönüştü: streaming replication HA için endüstri standardı, logical replication CDC ve sıfır kesintili upgrade için vazgeçilmez, Patroni ve CloudNativePG operasyonel otomasyonun temeli, pgBackRest ise PITR’ın güvencesi. Doğru replication mimarisi; iş yükü tipine (OLTP vs analitik), durability gereksinimine (zero data loss vs son birkaç saniye), operasyonel olgunluğa ve coğrafi dağılım ihtiyacına bağlı olarak seçilir.

Karar çerçevesi şudur: tek bölge OLTP için Patroni + streaming + 2 sync replica + pgBackRest; sıfır kesintili yıllık major upgrade için logical replication ile blue-green; çok bölgeli read scaling için cross-region async replica; aktif-aktif yazma için pgEdge veya EDB BDR ancak conflict semantiği uygulamaya uygunsa. Her topolojide monitoring ve restore drill’leri olmazsa olmazdır.

PostgreSQL HA mimarisi tasarımı, mevcut cluster’ın audit’i veya logical replication tabanlı upgrade için iletişim sayfası üzerinden detaylı bir gereksinim görüşmesi planlanabilir; her senaryo iş yükü profiline göre özelleşir ve hazır şablon yerine ölçülü bir tasarım gerektirir.