PostgreSQL Yüksek Erişilebilirlik (HA) Temelleri

Bilişim sektöründe her geçen gün, donanımların güçlendiğine, işletim sistemlerinin evrildiğine ve bulut teknolojilerinin dünyayı nasıl ele geçirdiğine şahit oluyoruz. Ancak bu süreçte değişmeyen, aksine her geçen gün ağırlığı daha da artan tek bir parametre var: Süreklilik. Modern dünyada, bir veritabanının planlı veya plansız bir şekilde çevrimdışı kalması sadece teknik bir aksaklık değil; doğrudan ciro kaybı, prestij sarsılması ve yasal yaptırımlar demektir. PostgreSQL gibi güçlü bir ilişkisel veritabanı yönetim sistemini (RDBMS) kurumsal yapılarda konumlandırırken ilk sormanız gereken soru şudur: Sunucumuz çöktüğünde ne olacak?

Bu makalede, PostgreSQL ekosisteminde Yüksek Erişilebilirlik (High Availability - HA) kavramının temellerini, mimari gereksinimlerini ve bir sistemin gerçekten "ayakta" kalmasını sağlayan temel mekanizmaları ele alacağız.

1. Yüksek Erişilebilirlik (HA) Nedir? (99.99% Ne İfade Eder?)

Yüksek erişilebilirlik, bir sistemin kabul edilebilir bir performans seviyesinde, kesintisiz olarak hizmet vermeye devam edebilme yeteneğidir. BT dünyasında bu durum genellikle "Dokuzlar" (Nines) kuralı ile ölçülür:

Erişilebilirlik Oranı	Yıllık Kabul Edilebilir Kesinti Süresi	Sektörel Karşılığı
99.9% (Üç Dokuz)	8 saat 45 dakika	Standart İş Uygulamaları
99.99% (Dört Dokuz)	52 dakika 35 saniye	E-Ticaret, Finansal Servisler
99.999% (Beş Dokuz)	5 dakika 15 saniye	Telekomünikasyon, Kritik Altyapılar

PostgreSQL dünyasında "Beş Dokuz" seviyesine ulaşmak sadece veritabanı yazılımını değil; network altyapısını, disk mimarisini, bağlantı yönetimini (connection pooling) ve koordinasyon servislerini kapsayan bütüncül bir orkestrasyon gerektirir.

2. HA Mimarisinin İki Temel Taşı: RPO ve RTO

Bir yüksek erişilebilirlik mimarisi tasarlamadan önce, işletmenizin risk toleransını belirleyen iki kritik metriği çok iyi tanımlamalısınız:

• RPO (Recovery Point Objective - Kurtarma Noktası Hedefi): Bir felaket anında ne kadarlık veri kaybını göze alabilirsiniz? Finansal sistemler için bu değer sıfır (RPO=0) olmalıdır.

• RTO (Recovery Time Objective - Kurtarma Süresi Hedefi): Sistem çöktükten sonra, yedek sistemin devreye girip hizmetin tekrar aktif hale gelmesi ne kadar sürmelidir? (Örn: "Maksimum 30 saniye").

  
  

Mimarideki tüm araç seçimleriniz (Senkron/Asenkron replikasyon, otomatik failover araçları) bu iki metriğin sınırlarına göre şekillenir.

3. PostgreSQL HA Mimarisinin Yapı Taşları

PostgreSQL, veri tutarlılığı ve güvenliği konusunda endüstri standardı bir veritabanı olsa da, doğası gereği kendi başına "otomatik failover" (kesintisiz yedek sunucuya geçiş) yeteneğine sahip değildir. Kutudan çıktığı haliyle (out-of-the-box) PostgreSQL, birincil sunucu çöktüğünde trafiği diğerine yönlendirecek veya yeni bir lideri otomatik olarak seçecek mekanizmaları barındırmaz.

Kusursuz, insan müdahalesine ihtiyaç duymayan ve 99.99% (Four Nines) gibi yüksek erişilebilirlik sürelerini hedefleyen bir HA kümesi (cluster) inşa etmek, ancak birbirini tamamlayan dört temel bileşenin orchestrate edilmesiyle mümkündür:

A. Aktif/Pasif Dağıtım ve Replikasyon Mekanizmaları

Bir HA mimarisinin ilk ve en kritik şartı, verinin o anda birden fazla coğrafi konumda veya sunucuda güncel bir kopyasının bulunmasıdır. PostgreSQL dünyasında bu süreç, ana sunucunun (Primary) ürettiği WAL (Write-Ahead Log) kayıtlarının ikincil sunuculara (Standby) aktarılması ve orada yeniden oynatılması (replay) esasına dayanır.

HA topolojilerinde bu akış iki farklı yöntemle kurulabilir:

• Fiziksel (Streaming) Replikasyon: Disk blokları seviyesinde, bayt bayt (byte-by-byte) birebir kopyalama yapar. Sektördeki HA mimarilerinin standart omurgasını oluşturur. Standby sunucuyu, Primary sunucunun tam bir "klon" haline getirir.

  • Avantajı: Performanslıdır, veri kaybı riskini minimize eder ve yönetimi kolaydır.

  • Dezavantajı: Sadece okuma (Read-Only) amaçlı kullanılabilir ve hedef sunucu ile kaynak sunucunun aynı ana PostgreSQL sürümünde olması zorunludur.

    
    

• Mantıksal (Logical) Replikasyon: Değişiklikleri disk blokları yerine tablo veya şema bazında; INSERT, UPDATE, DELETE gibi mantıksal SQL komutları halinde hedef sunucuya aktarır.

  • Kullanım Alanı: Genellikle veri ambarı (DWH) beslemelerinde, farklı PostgreSQL sürümleri arasında veri taşımada veya sadece belirli tabloların replike edilmesi gereken hibrit senaryolarda tercih edilir. HA mimarilerinde doğrudan failover omurgası olarak kullanılması, yönetim zorlukları nedeniyle pek tercih edilmez.

  
  

B. Sağlık Taraması (Health Checking) ve Kalp Atışı (Heartbeat)

Sistemde bir sorun olduğunu anlamanın tek yolu, sürekli ve kararlı bir gözlem mekanizmasıdır. Kümedeki tüm düğümlerin (nodes) durumunu anlık olarak izleyen "Heartbeat" (Kalp Atışı) mekanizmaları kurulmalıdır.

• Milisaniyeler Seviyesinde Tespit: Eğer Primary sunucu donanımsal bir arıza verir, işletim sistemi kilitlenir veya PostgreSQL servisi çökerse; sistemin bunu saniyeler hatta milisaniyeler içinde doğrulaması gerekir.

• Yanıltıcı Sinyallerin Önlenmesi: Anlık bir ağ dalgalanması nedeniyle geçici olarak yanıt vermeyen bir sunucuyu "çökmüş" ilan edip gereksiz yere failover sürecini tetiklememek için, sağlık taramalarının akıllı eşik değerleri (thresholds) ve timeout süreleri ile optimize edilmesi kritik önem taşır.
  

C. Konsensüs (Consensus) ve Dağıtılmış Durum Deposu (DCS)

Yüksek erişilebilirlikli sistemlerin en büyük kabusu Split-Brain (Çift Başlılık) senaryosudur. Ağdaki bir kopukluk nedeniyle Primary ve Standby sunucular birbirleriyle konuşamaz hale geldiğinde, Standby sunucu kendini "Lider" ilan edebilir.

Bu durumda sistemde iki adet yazılabilir (Read-Write) Primary sunucu oluşur ki bu da geri dönülemez veri bozulmalarına (data corruption) yol açar.

Bu kaosu engellemek için mimariye bir Dağıtılmış Konsensüs Sistemi (Distributed Consensus Store - DCS) dahil edilir:

• Ortak Karar Mekanizması: etcd, Consul veya ZooKeeper gibi Raft ya da Paxos algoritmalarını kullanan DCS sistemleri, kümenin o andaki durumunu "tek ve mutlak gerçek" (Single Source of Truth) olarak saklar.

• Liderlik Kilidi (Leader Lock): Primary sunucu, DCS üzerinde dinamik bir kilit (lock) tutar. Bu kilidi belirli aralıklarla (TTL - Time to Live) yenilemek zorundadır. Eğer Primary sunucu çökerse kilit düşer. DCS ve küme yöneticisi (örneğin Patroni), kalan Standby sunucular arasından hangisinin en güncel veriye sahip olduğunu konsensüs algoritmasıyla belirleyerek yeni lideri güvenli bir şekilde seçer.

  
  

D. Akıllı Bağlantı Yönlendirme (Traffic Routing)

Lider değişimi (failover) arka planda başarıyla tamamlansa bile, istemci uygulamaların (application servers) bu değişiklikten anında haberdar olması gerekir. Yeni liderin IP adresini manuel olarak uygulama konfigürasyonuna yazmak kabul edilemez bir kesinti süresine (RTO) yol açar.

Trafiği dinamik olarak yeni Primary sunucuya yönlendirmek için üç popüler yöntem kullanılır:

1. Sanal IP (VIP - Virtual IP) ve Keepalived: Küme içinde koşan bir sanal IP adresi tanımlanır. Bu IP her zaman aktif olan Primary sunucunun üzerinde ayağa kaldırılır. Failover anında sanal IP, yeni Primary sunucuya otomatik olarak atanır (IP takeover). Uygulamalar sadece bu tek sanal IP'ye bağlanır.

2. Yük Dengeleyici ve Proxy Katmanı (HAProxy / PgBouncer): Uygulama ile veritabanı arasına konumlandırılan HAProxy gibi bir proxy katmanı, arkadaki veritabanlarının sağlık durumunu (genellikle Patroni'nin sunduğu REST API üzerinden) sürekli sorgular. Yazma isteklerini sadece 200 OK dönen aktif Primary sunucuya, okuma isteklerini ise Standby sunuculara yönlendirir.

3. Uygulama Seviyesinde Bağlantı Parametreleri (Connection String): PostgreSQL'in resmi kütüphaneleri (libpq, JDBC vb.), bağlantı cümlesinde birden fazla IP adresini ve target_session_attrs=read-write parametresini destekler. Uygulama, listedeki sunucuları sırayla dener ve yazma yetkisine sahip olan ilk sunucuya otomatik olarak bağlanır.

4. Yaygın PostgreSQL HA Çözümleri

Sektörde PostgreSQL için kullanılan en popüler yüksek erişilebilirlik araçlarını ve yaklaşımlarını şu şekilde özetleyebiliriz:

1. Patroni (Sektör Standardı)

Günümüzde modern altyapıların vazgeçilmezi olan Patroni, Python tabanlı bir PostgreSQL orkestrasyon aracıdır. Gücünü dağıtılmış konsensüs depolarından (etcd/Consul) alır.

• Nasıl Çalışır? Her PostgreSQL sunucusunun üzerinde bir Patroni servisi koşar. Bu servisler etcd üzerinde bir "liderlik kilidi" (leader lock) tutmaya çalışır. Kilidi elinde tutan lider olur. Lider çökerse kilit düşer, diğer sunucular kendi aralarında anlaşarak yeni lideri seçer ve trafiği oraya yönlendirir.

  
  

2. pg_auto_failover

Microsoft tarafından geliştirilen, daha küçük ve yönetimi son derece kolay olan bir alternatiftir.

• Nasıl Çalışır? Kümenin dışında bağımsız bir "Monitor" (izleyici) düğümü konumlandırılır. Bu monitör düğümü, Primary ve Standby sunucuların sağlığını izler ve bir sorun anında geçiş sürecini yönetir.

  
  

3. Geleneksel VIP ve Scripting (Önerilmeyen)

Eski sistemlerde sıkça kullanılan, iki sunucu arasına bir Sanal IP (VIP) koyup, sunucu çöktüğünde bir bash script vasıtasıyla IP'yi diğer sunucuya taşıma yöntemidir.

• Neden Önerilmez? Split-brain riskini yönetmek imkansıza yakındır. İki sunucunun da kendini lider sanıp aynı diske veya farklı verilere yazmaya çalışması (data corruption) ile sonuçlanabilir.

  
  

5. Başarılı Bir HA Mimarisi İçin 3 Altın Kural

1. Her Zaman Tek Sayıda Düğüm Kullanın (Quorum): Dağıtılmış sistemlerde karar çoğunlukla alınır. 2 düğümlü bir yapıda network bölündüğünde kimin haklı olduğunu anlamak imkansızdır. Bu yüzden izleme veya konsensüs katmanında (etcd) her zaman en az 3 düğüm kullanın.

   
   

2. Failover Testlerini Canlıya Almadan Önce (Ve Sonra Düzenli Olarak) Yapın: Kağıt üzerinde harika çalışan bir HA sistemi, canlı yük altında disk yazma gecikmeleri yüzünden failover yapamayabilir. Sistemlerin fişini çekerek (chaos engineering) gerçek senaryoları simüle edin.

   
   

3. Yedekleme ile HA'i Birbirine Karıştırmayın: HA, anlık çökmelere karşı sistemin ayakta kalmasını sağlar. Ancak yanlışlıkla çalıştırılan bir DROP TABLE komutu, replikasyon aracılığıyla milisaniyeler içinde Standby sunucuya da yansır. Bu yüzden, ne kadar gelişmiş bir HA mimariniz olursa olsun, Point-in-Time Recovery (PITR) destekleyen güçlü bir yedekleme sisteminiz (pg_backrest vb.) mutlaka olmalıdır.

   
   

Sonuç

PostgreSQL'de yüksek erişilebilirlik kurmak tek bir konfigürasyon parametresiyle çözülecek bir iş değildir. Bu, veritabanı motorundan network topolojisine kadar uzanan disiplinler arası bir mimari çalışmadır. Altyapınızın ihtiyaçlarına göre doğru araçları seçmek ve sistemi proaktif olarak izlemek, verinizin geleceğini garanti altına almanın tek yoludur.