PostgreSQL Streaming Replikasyon ve Patroni ile Yüksek Erişilebilirlik: Üretim Ortamları İçin Dayanıklı Çözümler

4 Eylül 2026 · Gökhan Güngör

PostgreSQL Streaming Replikasyon ve Patroni ile Yüksek Erişilebilirlik: Üretim Ortamları İçin Dayanıklı Çözümler

PostgreSQL tabanlı uygulamaların üretimde kesintisiz çalışabilmesi, doğru replikasyon stratejileri ve otomatik failover mekanizmaları gerektirir. Bu, yalnızca veri kaybını önlemekle kalmaz, aynı zamanda servis sürekliliğini de garanti eder. Streaming replikasyon, PostgreSQL'in sağladığı temel bir yüksek erişilebilirlik (HA) özelliğiyken, Patroni bu replike altyapı üzerinde bir cluster yönetim ve otomatik failover katmanı sunar.

PostgreSQL Streaming Replikasyon Temelleri

PostgreSQL, Write-Ahead Log (WAL) mekanizması aracılığıyla veri bütünlüğünü ve replikasyonu sağlar. Tüm veri değişiklikleri önce WAL dosyalarına yazılır, ardından diskteki veri dosyalarına uygulanır. Streaming replikasyon, bu WAL kayıtlarını birincil (primary) sunucudan ikincil (standby) sunuculara gerçek zamanlı olarak akış yaparak kopyalar.

WAL Akışı ve Replikasyon Modları

Birincil sunucu, WAL kayıtlarını ikincil sunuculara gönderir. İkincil sunucular bu WAL kayıtlarını uygulayarak kendi veri kopyalarını güncel tutar. Replikasyon senkron veya asenkron olabilir:

Asenkron Replikasyon: Birincil sunucu, commit işlemini WAL kaydının ikincil sunucuya ulaştığını beklemeden tamamlar. Düşük gecikme süresi sunar ancak failover durumunda küçük bir veri kaybı (RPO > 0) riski taşır.
Senkron Replikasyon: Birincil sunucu, commit işlemini, ilgili WAL kaydının en az bir ikincil sunucuya ulaşıp diske yazıldığını onaylayana kadar bekleterek tamamlar. Bu, sıfır veri kaybı (RPO = 0) sağlar ancak gecikmeyi artırabilir. Genellikle synchronous_commit = on ve synchronous_standby_names parametreleri ile yapılandırılır.

Birincil (Primary) Sunucu Yapılandırması

Birincil sunucuda streaming replikasyonu etkinleştirmek için postgresql.conf ve pg_hba.conf dosyalarında belirli ayarlamalar yapılır.

# postgresql.conf (Primary)wal_level = replicamax_wal_senders = 10  # Replikasyon bağlantıları için maksimum gönderici sayısıwal_keep_size = 1GB   # Standby'ların ihtiyacı olabilecek WAL dosyalarını saklama boyutu (PostgreSQL 13+)# veya wal_keep_segments = 64 (PostgreSQL 12 ve öncesi, 16MB/segment)archive_mode = on     # WAL arşivlemeyi etkinleştirarchive_command = 'cp %p /mnt/wal_archive/%f' # WAL dosyalarını arşivleme komutu (opsiyonel ama HA için önerilir)# pg_hba.conf (Primary)# Replikasyon kullanıcısı için izin verhost    replication     replicator      192.168.1.0/24  md5

wal_level = replica, replikasyon için gerekli WAL bilgilerini sağlar. max_wal_senders, eşzamanlı kaç replikasyon bağlantısının destekleneceğini belirler. wal_keep_size, ikincil sunucuların yakalaması için ne kadar WAL geçmişinin saklanacağını kontrol eder.

İkincil (Standby) Sunucu Yapılandırması

İkincil sunucu, temel bir yedekten (pg_basebackup ile oluşturulmuş) başlar ve ardından standby.signal dosyası ile veya recovery.conf (PostgreSQL 12 öncesi) ile birincil sunucuya bağlanarak WAL akışını alır.

# postgresql.conf (Standby)primary_conninfo = 'host=192.168.1.10 port=5432 user=replicator password=YOUR_PASSWORD application_name=standby1'hot_standby = on      # Sadece okuma sorgularına izin verrestore_command = 'cp /mnt/wal_archive/%f %p' # Arşivden WAL dosyalarını geri yükleme komutu (opsiyonel, arşivi kullanıyorsanız)

# standby.signal (Boş bir dosya, data dizininde bulunur)# Touch this file to indicate it's a standby server.

primary_conninfo, ikincil sunucunun birincil sunucuya nasıl bağlanacağını tanımlar. hot_standby = on, ikincil sunucunun okuma sorguları için kullanılabilmesini sağlar.

Patroni ile Otomatik Failover ve Cluster Yönetimi

PostgreSQL streaming replikasyon, verilerin kopyalanmasını sağlasa da, birincil sunucu çöktüğünde otomatik olarak yeni bir birincil seçmez veya istemci bağlantılarını yönlendirmez. Bu boşluğu Patroni doldurur. Patroni, yüksek erişilebilirlik, otomatik failover ve cluster yönetimini sağlayan bir Python tabanlı araçtır.

Patroni Mimarisi ve DCS Entegrasyonu

Patroni, bir Dağıtılmış Konsensüs Deposu (DCS) (Etcd, Consul, ZooKeeper gibi) kullanarak cluster durumunu izler, lider seçimi yapar ve failover süreçlerini yönetir. Her PostgreSQL node'unda çalışan bir Patroni ajanı, kendi PostgreSQL instance'ının sağlığını izler, WAL konumunu DCS'e raporlar ve birincil node'un sağlığını kontrol eder.

Lider Seçimi: Patroni, DCS üzerinde bir kiralama mekanizması kullanarak birincil node'u belirler. Birincil node'un kirası sona ererse ve yenileyemezse (çünkü çökmüştür), diğer ikincil node'lar liderlik için yarışır.
Health Check: Patroni, PostgreSQL instance'ının canlılığını, replikasyon durumunu ve WAL gecikmesini sürekli kontrol eder.
Failover/Switchover: Birincil node'da bir sorun algılandığında, Patroni en güncel ikincil node'u yeni birincil olarak yükseltir. Switchover ise planlı bir birincil değişimidir.

Patroni Kurulumu ve Yapılandırması

Her PostgreSQL node'unda Patroni'nin kurulu olması ve ilgili DCS'e erişebilmesi gerekir. Aşağıda tipik bir patroni.yml yapılandırması bulunmaktadır:

# patroni.ymlscope: my_pg_cluster      # Cluster adınamespace: /service/patroni # DCS'de kullanılacak namespace (Etcd, Consul için)restapi:  listen: 0.0.0.0:8008     # Patroni API'sinin dinleyeceği adrespostgresql:  name: pg1               # PostgreSQL instance adı  listen: 0.0.0.0:5432    # PostgreSQL'in dinleyeceği adres  data_dir: /var/lib/postgresql/data # PostgreSQL veri dizini  parameters:    wal_level: replica    hot_standby: on    max_wal_senders: 10    max_replication_slots: 10    archive_mode: on    archive_command: 'cp %p /mnt/wal_archive/%f' # WAL arşivleme komutu  create_replica_method:    - basebackup # Yeni bir standby oluşturmak için pg_basebackup kullan  pg_hba:    - host replication replicator 0.0.0.0/0 md5 # Replikasyon kullanıcısı için izin    - host all all 0.0.0.0/0 md5 # Uygulama kullanıcıları için izin# DCS yapılandırması (Etcd örneği)etcd:  host: 'etcd1:2379,etcd2:2379,etcd3:2379'

Bu yapılandırma, Patroni'nin PostgreSQL instance'ını nasıl yöneteceğini, hangi parametreleri uygulayacağını ve hangi DCS ile etkileşim kuracağını belirtir. Patroni, PostgreSQL'in postgresql.conf dosyasını ve pg_hba.conf kurallarını dinamik olarak güncelleyebilir.

Gerçek Üretim Senaryosu: Yüksek Trafikli E-ticaret Uygulaması

Bir e-ticaret platformunun veritabanı, sipariş işlemleri, ürün katalogları, kullanıcı bilgileri gibi kritik verileri barındırır. Bu sistemin kesintisiz çalışması, doğrudan iş sürekliliğini etkiler. PostgreSQL streaming replikasyon ve Patroni kombinasyonu, bu tür bir senaryo için ideal bir çözümdür.

Senaryo Detayları ve Uygulama

Ele alalım ki, bir e-ticaret platformu için üç PostgreSQL node'lu bir Patroni cluster'ı kurduk: pg-primary, pg-standby-1 ve pg-standby-2. Bu node'lar, farklı erişilebilirlik bölgelerinde (Availability Zones) konumlandırılmış AWS EC2 instance'larında çalışıyor. Patroni, üç node'lu bir Etcd cluster'ı kullanarak durum yönetimini sağlıyor. Uygulama, veritabanına doğrudan birincil node'un IP adresini veya bir Service Discovery (örneğin, DNS kaydı veya load balancer) aracılığıyla bağlanır.

Uygulama katmanı, veritabanı bağlantısı için Patroni'nin sağladığı proxy adresini veya dinamik olarak güncellenen DNS kaydını kullanır. Bu sayede, failover durumunda uygulama tarafında manuel bir müdahale gerekmez.

Failover Akışı

Kritik bir anda, pg-primary sunucusu donanımsal bir arıza veya ağ kesintisi nedeniyle erişilemez hale geldi:

Patroni ajanları, pg-primary'nin Etcd üzerindeki kira süresini yenileyemediğini ve sağlık kontrolünden geçemediğini algılar.
Etcd cluster'ı, pg-primary'nin artık lider olmadığını onaylar.
Patroni ajanları arasında yeni bir lider seçimi başlar. pg-standby-1 ve pg-standby-2, kendi WAL konumlarını Etcd'ye bildirir.
Patroni, en güncel WAL konumuna sahip ikincil node'u (diyelim ki pg-standby-1) yeni birincil olarak seçer.
pg-standby-1, Patroni tarafından birincil moda yükseltilir (promote komutu ile). Bu süreçte varsa replikasyon slotları ve diğer gerekli konfigürasyonlar Patroni tarafından yönetilir.
Yükseltilen pg-standby-1, artık yazma işlemleri için hazırdır. Diğer ikincil node (pg-standby-2) ise otomatik olarak yeni birincil node'a replike olmaya başlar.
Uygulama, DNS kaydının veya Service Discovery'nin güncellenmesiyle yeni birincil node'a yönlendirilir. Uygulamanın connection pool'u, yeni bağlantıları otomatik olarak yeni birincil node'a açar.

Bu failover süreci, senkron replikasyon kullanılıyorsa veri kaybı olmadan (RPO=0) ve dakikalar (hatta saniyeler) içinde (düşük RTO) gerçekleşir. Böylece, e-ticaret platformu müşterileri, birincil veritabanı kesintisini fark etmeden işlemlerine devam edebilirler.

Sonuç

PostgreSQL streaming replikasyonunun temelini oluşturduğu, Patroni ile yönetilen bir yüksek erişilebilirlik cluster'ı, üretim ortamlarında kritik veritabanları için vazgeçilmez bir mimaridir. Bu kombinasyon, manuel müdahale gerektirmeyen otomatik failover ile hem veri bütünlüğünü hem de sürekli servis erişilebilirliğini sağlar. Karmaşık veritabanı ortamlarında operasyonel yükü azaltırken, iş sürekliliği hedeflerine ulaşmak için sağlam bir temel sunar.

← Blog Listesine Dön