PostgreSQL Yüksek Erişilebilirlik Seçenekleri

Merhaba,

Bu yazıda, son dönemde bana en çok sorulan veritabanı başlıklarından birini açmak istiyorum: PostgreSQL’de yüksek erişilebilirliği (high availability) nasıl sağlarız?

Soru basit görünür ama cevabı tek bir araç ya da tek bir ayar değil. PostgreSQL’in bu konuda epeyce seçeneği var; üstelik bir kısmı doğrudan veritabanının içinde gelir, bir kısmı ise dışarıdan eklenen araçlardır. Bu ayrımı en baştan netleştirmek, kafa karışıklığının yarısını çözüyor. Amacım, yazıyı bitirdiğinizde “benim senaryom için hangisi” sorusuna kendi başınıza cevap verebilmeniz.

Hemen söyleyeyim: bu yazıya beni iten kaynak, MSSQLTips’te yayımlanan PostgreSQL High Availability Options yazısı oldu. Buradaki çerçeveyi temel aldım; teknik ayrıntıları ise PostgreSQL’in resmi dokümantasyonuyla tek tek karşılaştırıp Türkçeye, kendi anlatımımla taşıdım.

Önce iki kelime: RTO ve RPO

Yüksek erişilebilirlik konuşmasına girmeden önce iki kavramı oturtmak gerekiyor. Çünkü bütün seçenekler aslında bu iki soruya verdiğiniz cevaba göre şekilleniyor.

• RTO (kurtarma süresi): Sunucu çöktüğünde sistemi yeniden ayağa kaldırmak için tahammül edebileceğiniz süre. “Beş dakika kesinti olabilir” mi diyorsunuz, yoksa “saniyeler içinde dönmeli” mi?
• RPO (veri kaybı toleransı): Bir felaket anında kaybetmeyi göze alabileceğiniz veri miktarı. “Hiç veri kaybedemem” ile “son birkaç saniyenin kaybı sorun değil” arasında büyük bir maliyet farkı vardır.

Bu iki sayı sıfıra ne kadar yaklaşırsa, çözüm de o kadar karmaşık ve pahalı hale gelir. O yüzden “en iyi yüksek erişilebilirlik çözümü hangisi?” sorusunun tek bir doğru cevabı yok; doğru cevap sizin RTO ve RPO hedeflerinizde gizli.

Bu hedefleri sektörün konuştuğu dile de çevirelim. “Sistemim yüzde kaç ayakta olmalı?” sorusunun karşılığı, aslında yılda ne kadar kesintiye razı olduğunuzdur:

Çalışma oranı	Halk arasında	Yıllık toplam kesinti
%99	iki dokuz	~3,65 gün
%99,9	üç dokuz	~8,8 saat
%99,99	dört dokuz	~53 dakika
%99,999	beş dokuz	~5 dakika

Aradaki farkı görüyor musunuz? %99,9’dan %99,99’a çıkmak kulağa küçük bir iyileştirme gibi gelir ama pratikte yıllık kesintiyi neredeyse 9 saatten 53 dakikaya indirmek demektir. Ve bu eşik, çoğu kurumda tam olarak “el ile failover”dan “otomatik failover”a geçilen yerdir. Çünkü bir insanın uyanıp, durumu fark edip, doğru komutu çalıştırması bile o 53 dakikaya zor sığar.

İki büyük aile: çekirdek özellikler ve dış araçlar

PostgreSQL’in yüksek erişilebilirlik dünyasını ikiye ayırarak düşünmenizi öneririm:

• PostgreSQL’in kendi içinde gelen yetenekler: Replikasyon burada. Veriyi bir sunucudan diğerine kopyalama işini PostgreSQL zaten yapıyor. Bunlar yıllardır kararlı (GA) olarak gelen, çekirdek özellikler.
• Üstüne eklenen orkestrasyon araçları: Patroni, repmgr, pgpool-II gibi. Bunlar PostgreSQL’in parçası değil; replikasyonun üstüne “otomatik karar verme” katmanı ekleyen ayrı projeler.

Bu ayrım çok önemli, çünkü tek başına replikasyon size yüksek erişilebilirlik vermez. Replikasyon veriyi kopyalar, evet; ama “birincil sunucu öldü, hadi yedeği devreye al” kararını kimin vereceği apayrı bir mesele. İşte o karar mekanizmasını da birazdan konuşacağız.

1. Akış Tabanlı Replikasyon (Streaming Replication)

En çok kullanılan ve PostgreSQL’in tam kalbinde duran yöntem bu. Mantığı şöyle: PostgreSQL her değişikliği önce bir günlük dosyasına (WAL — write-ahead log) yazar. Akış tabanlı replikasyonda bu WAL kayıtları, dosya tamamen dolmayı beklemeden, birincil (primary) sunucudan yedek (standby) sunucuya canlı bir akış halinde aktarılır.

Sonuç olarak yedek sunucu, birincil sunucunun neredeyse anlık bir kopyasını tutar. Birincil çökerse, elinizde verinin büyük kısmını içeren, hızla yeni birincil yapılabilecek bir yedek hazır bekler.

Burada kritik bir tercih var: senkron mu, asenkron mu?

• Asenkron (varsayılan): Birincil sunucu işlemi tamamlar, yedeğe ulaşmasını beklemez. Hızlıdır, birincil üzerinde yük yaratmaz. Ama birincil tam o anda çökerse, henüz yedeğe geçmemiş son birkaç işlemi kaybedebilirsiniz. Yani RPO sıfır değildir.
• Senkron: PostgreSQL bir işlemi, en az bir senkron yedeğe de yazıldığından emin olmadan “tamamlandı” saymaz. Böylece veri kaybı riski ortadan kalkar (RPO sıfıra iner). Bedeli de var: her işlem yedeğin onayını beklediği için yazma performansı düşer.

Bir de hot standby özelliği var: yedek sunucuyu salt-okunur sorgulara açabilirsiniz. Yani yedek sadece beklemekle kalmaz, raporlama gibi okuma yükünü de üstlenebilir. Akış tabanlı replikasyon PostgreSQL çekirdeğinde uzun yıllardır (9.0 sürümünden, yani 2010’dan beri) kararlı şekilde geliyor; bu yüzden en güvenle yaslanabileceğiniz temel budur.

Soyut kalmasın; işin özü birincil sunucuda aslında şu birkaç satırlık ayardır:

 wal_level = replica # replikasyon icin gerekli WAL detayi max_wal_senders = 10 # ayni anda kac yedek baglanabilir wal_keep_size = 512MB # yedek geri kalirsa WAL'i bir sure sakla hot_standby = on # yedekte salt-okunur sorgulara izin ver 

Yedek sunucu ise birincilin bir kopyasını alıp yedek modunda açılır (PostgreSQL 12 ve sonrası için):

 # Once birincilin tam bir kopyasini al; -R parametresi onemli: pg_basebackup -h birincil-sunucu -U replikator -D /var/lib/postgresql/data -R # -R sayesinde PostgreSQL su iki seyi otomatik halleder: # 1) primary_conninfo ayarini yazar (yedek, birincile nasil baglanacagini bilir) # 2) standby.signal dosyasini olusturur (yedek, yedek modunda acilir) 

Senkron çalışmak isterseniz, birincilde tek bir satır daha eklemeniz yeterli:

 synchronous_standby_names = 'FIRST 1 (yedek1, yedek2)' # Anlami: "Bir islemi, en az 1 yedek onaylamadan tamamlanmis sayma." # Bu satiri silerseniz replikasyon yeniden asenkron (varsayilan) calisir. 

Pratik kural: Çoğu kurumsal kurulumun temelinde akış tabanlı replikasyon vardır. Asıl tartışma “replikasyon olsun mu” değil, “senkron mu asenkron mu” ve “failover’ı kim yönetecek” sorularıdır.

2. Log Gönderimi (WAL Shipping)

Akış tabanlı replikasyonun daha sade akrabası. Burada WAL kayıtları canlı akış yerine, tamamlanmış dosyalar halinde yedeğe gönderilir. Kurması ve anlaması basittir, birincil sunucuya yükü çok azdır.

Karşılığında daha “tanecikli” çalışır: bir WAL dosyası dolup gönderilene kadar yedek geride kalır, dolayısıyla bir kayıp anında akış tabanlı replikasyona göre biraz daha fazla veri açığınız olabilir. Bugün çoğu kurulum doğrudan akış tabanlı replikasyonu tercih etse de, log gönderimi hâlâ basit yedeklilik ve felaket kurtarma senaryolarında işe yarar.

3. Mantıksal Replikasyon (Logical Replication)

Akış tabanlı replikasyon tüm sunucuyu, bir bütün olarak kopyalar. Mantıksal replikasyon ise işi tablo bazına indirir. Yine WAL’den beslenir ama bu sefer ham günlük kayıtlarını değil, “şu tabloda şu satır değişti” gibi mantıksal değişiklikleri bir akışa dönüştürüp aboneye (subscriber) gönderir.

Bunun açtığı kapılar şunlar:

• Seçicilik: Tüm veritabanı yerine yalnızca belirli tabloları kopyalayabilirsiniz.
• Sürümler arası geçiş: Farklı PostgreSQL sürümleri arasında çalışabildiği için büyük yükseltmelerde kesintiyi azaltmak için sıkça kullanılır.
• Çok yönlülük: Çift yönlü ve birden çok birincil içeren topolojiler kurmak mümkün hale gelir.

Bedeli, akış tabanlı replikasyona göre biraz daha fazla yük ve özellikle çok birincilli senaryolarda çatışma (conflict) yönetiminin karmaşıklaşmasıdır. Mantıksal replikasyon, PostgreSQL 10 sürümünden (2017) beri çekirdekte kararlı olarak geliyor; yani bu da deneysel bir özellik değil, üzerine bina kurabileceğiniz olgun bir yetenek.

4. Donanım ve dosya sistemi tarafındaki seçenekler

PostgreSQL’in resmi dokümantasyonu, replikasyonun yanında daha “alt katman” çözümleri de sayar. Bunları kısaca geçeyim, çünkü doğru senaryoda hâlâ kıymetliler:

• Paylaşımlı disk (shared disk failover): Tek bir veri kopyası, birden çok sunucunun eriştiği ortak bir depolama biriminde durur. Senkronizasyon derdi yoktur, devralma hızlıdır ve veri kaybı olmaz. Ama o paylaşımlı disk tek bir kırılma noktasıdır; o giderse her şey gider.
• Dosya sistemi / blok cihaz replikasyonu (ör. DRBD): Dosya sistemindeki her değişiklik, aynı sırayla başka bir sunucuya yansıtılır. Tutarlı bir kopya verir ama genelde Linux’a ve katı yazma sırası gereksinimlerine bağlıdır.

5. Çok birincilli ve tetikleyici tabanlı yaklaşımlar

Daha niş ama bilmekte fayda var:

• Tetikleyici tabanlı replikasyon (ör. Slony-I): Veritabanı tetikleyicileri, değişiklikleri toplu halde yedeklere taşır. Tablo bazında çalışır ve yedek hem sorgu hem yerel değişiklik kabul edebilir. Karşılığında birincil üzerinde tetikleyici yükü ve asenkron yapısı nedeniyle olası veri kaybı vardır.
• Asenkron çok birincilli (ör. Bucardo): Her sunucu bağımsız çalışır, belirli aralıklarla senkronize olup çatışmaları çözer. Yavaş ya da kopuk bağlantılarda (uzak ofisler, sahadaki cihazlar) işe yarar ama çatışma yönetimi karmaşıktır.
• Senkron çok birincilli: Tüm sunucular yazma kabul eder ve değişiklik commit edilmeden önce hepsine iletilir. Veri kaybı olmaz, her sunucu yazabilir; ama yoğun yazmada kilitlenme ve gecikme yaratır ve PostgreSQL bunu çekirdekte doğrudan sunmaz, ortada bir katman ister.

Asıl boşluk: PostgreSQL otomatik failover yapmaz

Şimdi yazının en önemli cümlesine geldik. Yukarıdaki replikasyon yöntemlerinin hepsi veriyi kopyalamayı çözer. Ama hiçbiri tek başına şu soruyu çözmez: “Birincil sunucu çöktüğünü kim fark edecek, yedeği yeni birincil yapma kararını kim verecek ve uygulamaları yeni sunucuya kim yönlendirecek?”

PostgreSQL çekirdeği bu kararı kendiliğinden vermez. El ile müdahale edebilirsiniz ama gece 03.00’te kimsenin uyanık olmadığı bir anda bu, dakikalarca hatta saatlerce kesinti demektir. İşte bu yüzden gerçek yüksek erişilebilirlik için replikasyonun üstüne bir orkestrasyon (cluster yönetimi) katmanı koyarız. Sırada onlar var.

Bunu çok net bir tabloyla anlatayım: Bir ekip, kusursuz bir akış tabanlı replikasyon kurmuştu. Yedek sunucu birincilin anlık kopyasını tutuyordu, her şey kağıt üzerinde mükemmeldi. Sonra bir gece birincil sunucunun diski doldu. Replikasyon vardı ama “yedeği birincil yap” düğmesine basacak bir mekanizma yoktu. Sistem, mükemmel bir yedek sunucu öylece beklerken saatlerce kapalı kaldı; çünkü o düğmeye basacak kişi sabah işe gelene kadar kimse durumdan haberdar olmadı. Verileri sağlamdı ama hizmet yoktu. Yüksek erişilebilirlik tam da burada, replikasyonun bittiği yerde başlıyor.

6. Patroni: en yaygın orkestrasyon çözümü

Patroni, akış tabanlı replikasyon kullanan PostgreSQL kümelerini yöneten açık kaynaklı bir araç. Görevi tek cümleyle: kümenin sağlığını sürekli izlemek ve birincil çöktüğünde otomatik olarak güvenli bir failover (devralma) yürütmek.

Patroni tek başına çalışmaz; etrafında bir ekiple gelir:

• Dağıtık anahtar-değer deposu (etcd, Consul, ZooKeeper ya da Kubernetes): Küme durumunu burada tutar. “Şu an birincil kim?” sorusunun tek ve güvenilir cevabı bu depodadır. Düğümler bu depo üzerinden uzlaşıya (consensus) varır; böylece iki sunucunun aynı anda kendini birincil sanması gibi felaketlerin (split-brain) önüne geçilir.
• HAProxy gibi bir yük dengeleyici: Uygulamaları her zaman o anki birincile yönlendirir. Failover olduğunda uygulamanın IP değiştirmesi gerekmez; HAProxy trafiği sessizce yeni birincile akıtır.

Patroni’nin bir de REST API’si var; kümeyi izlemek ve yönetmek için pratik bir arayüz sunar. Bugün Kubernetes üzerinde ve büyük üretim ortamlarında PostgreSQL yüksek erişilebilirliği denince akla ilk gelen araç genelde Patroni’dir. Ayrıntılar için Patroni’nin resmi dokümantasyonuna bakabilirsiniz.

Split-brain neden bu kadar önemli? Ağ kesintisi yüzünden iki sunucu birbirini kaybedip ikisi de “birincil benim” derse, aynı veriye iki ayrı doğru yazılır ve veriniz onarılması çok zor biçimde bozulur. Patroni’nin dağıtık anahtar-değer deposunu (etcd) kullanmasının asıl sebebi budur: “birincil kim?” sorusunun tek ve tartışmasız bir cevabı olur. Yüksek erişilebilirlik kurarken kaçınmanız gereken bir numaralı tehlike, çökme değil; bu sessiz veri bozulmasıdır.

7. repmgr: daha hafif bir alternatif

repmgr de Patroni gibi akış tabanlı replikasyonu yöneten, failover’ı otomatikleştiren açık kaynaklı bir araç. Temel farkı kurulum felsefesinde: repmgr, küme yapılandırmasını tutmak için ayrı bir etcd/Consul kümesine ihtiyaç duymaz; bunun yerine kendi özel tablolarını PostgreSQL içinde oluşturup küme bilgisini orada saklar.

Bu, mimariyi sadeleştirir: yönetmeniz gereken bir bileşen daha az olur. Karşılığında, Patroni’nin dağıtık uzlaşı altyapısının sunduğu bazı güvencelerden (özellikle çok düğümlü, bulut-yerel ortamlarda) feragat etmiş olursunuz. Daha küçük, daha klasik kurulumlarda repmgr çoğu zaman gayet yeterli ve anlaşılır bir tercihtir. Detaylar repmgr resmi sitesinde.

8. pgpool-II: havuzlama, yük dengeleme ve daha fazlası

pgpool-II biraz daha çok işlevli bir araç. Aynı anda birkaç şeyi birden yapabiliyor:

• Bağlantı havuzlama (connection pooling): Veritabanı bağlantılarını yeniden kullanarak yükü azaltır.
• Yük dengeleme: Okuma sorgularını birden çok yedek arasında dağıtarak okuma performansını artırır.
• Otomatik failover: Birincil çöktüğünde devralmayı yönetebilir.

pgpool-II, özellikle okuma ağırlıklı sistemlerde okuma trafiğini birden çok sunucuya yayma ihtiyacı olduğunda parlar. Ancak kurulumu ve doğru yapılandırması dikkat ister; “kur ve unut” türünden bir araç değildir. Çoğu zaman Patroni ile pgpool-II’yi birlikte de görürsünüz: biri failover’ı, diğeri bağlantı/okuma dağıtımını üstlenir. Ayrıntılar için pgpool-II resmi sitesi.

Küçük ama önemli bir not: sadece bağlantı havuzlama derdiniz varsa, pgpool-II’nin tüm ağırlığını taşımanıza gerek olmayabilir. Bu işe odaklanmış, daha hafif bir araç olan PgBouncer çoğu zaman tek başına yeterlidir. Pratikte yaygın bir desen şudur: failover ve küme yönetimi için Patroni, salt bağlantı havuzlama için PgBouncer. Her aracı en iyi yaptığı tek işte kullanmak, mimariyi hem sade hem sağlam tutar.

Ya bulut? Hazır gelen yüksek erişilebilirlik

Buraya kadar her şeyi kendiniz kurduğunuzu varsaydık. Ama bugün pek çok ekip PostgreSQL’i bir bulut servisinin yönettiği halde kullanıyor; orada yukarıda anlattığımız parçaların çoğu kutudan çıkar çıkmaz hazır geliyor. Ben Microsoft tarafına daha yakın olduğum için en somut örneği oradan vereyim, sonra diğerlerine de değineyim.

• Azure Database for PostgreSQL Flexible Server: “Zone-redundant” yüksek erişilebilirlik seçeneğiyle birincil ve yedek sunucuyu farklı erişilebilirlik bölgelerinde (availability zone) konumlandırır. Bir sorun anında otomatik failover yapar; Microsoft’un belirttiği değerler yaklaşık 60-120 saniyede devralma, sıfır veri kaybı ve %99,99 hizmet seviyesi taahhüdü (SLA). Üstelik bu bir önizleme (preview) değil; genel kullanıma sunulmuş (GA) bir özellik. Ayrıntılar Microsoft Learn dokümantasyonunda.
• Amazon RDS for PostgreSQL (Multi-AZ): Farklı bir bölgede senkron bir yedek tutar ve birincil çökünce otomatik devralır. Mantık aynı; sizin yerinize AWS yönetir.
• Amazon Aurora PostgreSQL: Veriyi depolama katmanında birden çok bölgeye kopyalar; failover’ı ve dayanıklılığı servis üstlenir.

Bulutun cazip tarafı net: etcd, HAProxy, Patroni derdine girmeden, birkaç tıkla “dört dokuz”a yakın bir kuruluma kavuşuyorsunuz. Karşılığında iki şeyden feragat ediyorsunuz: maliyet (yedek sunucu için de tam ücret ödersiniz, yani fatura kabaca ikiye katlanır) ve kontrol (ince ayarların bir kısmı sizin elinizde olmaz). Yani bulut, yüksek erişilebilirliği sihirli biçimde bedavaya getirmez; sadece kurma ve işletme yükünü sizden alıp faturaya yazar. Bu takası bilerek yapmak, çoğu ekip için son derece mantıklı bir tercih.

Hepsini tek tabloda toplayalım

Kafadaki resmi netleştirmek için kabaca bir karşılaştırma:

Yöntem	Ne işe yarar	Otomatik failover?	Tablo bazlı?
Akış tabanlı replikasyon	Çekirdek replikasyon (sync/async)	Hayır (araç gerekir)	Hayır
Log gönderimi	Basit yedeklilik / DR	Hayır	Hayır
Mantıksal replikasyon	Seçici / sürümler arası	Hayır	Evet
Patroni	Küme yönetimi + failover	Evet (etcd ile)	—
repmgr	Küme yönetimi + failover	Evet (kendi tablosuyla)	—
pgpool-II	Havuzlama + yük dengeleme + failover	Evet	—

Peki hangisini seçmeli?

Şimdi başta koyduğumuz RTO/RPO çerçevesine dönelim. Pratikte sıralama genelde şöyle ilerler:

• Önce temeli kurun: Neredeyse her senaryoda altta akış tabanlı replikasyon olur. Buna karar verdikten sonra senkron mu asenkron mu olacağını RPO hedefinize göre belirleyin. “Tek bir işlem bile kaybedemem” diyorsanız senkron; “son birkaç saniye sorun değil, performans önemli” diyorsanız asenkron.
• Failover’ı otomatikleştirin: RTO’nuz dakikalar mertebesindeyse ve gece müdahalesine güvenemiyorsanız, mutlaka bir orkestrasyon aracı koyun. Bulut-yerel, çok düğümlü, “saniyeler içinde dönmeli” diyen kurulumlarda Patroni; daha küçük, klasik kurulumlarda repmgr çoğu zaman doğru başlangıçtır.
• Okuma yükünü dağıtın: Okuma ağırlıklı, çok sayıda eşzamanlı bağlantısı olan sistemlerde pgpool-II ile bağlantı havuzlama ve okuma dağıtımını devreye alın.
• Özel ihtiyaçlar: Seçici kopyalama ya da büyük sürüm yükseltmesinde kesintiyi azaltma gibi durumlarda mantıksal replikasyon çok işinize yarar.
• Yükü hiç almak istemiyorsanız: Tüm bu bileşenleri kendiniz kurup işletmek istemiyorsanız, yönetilen bir bulut servisi (örneğin Azure Database for PostgreSQL Flexible Server) yüksek erişilebilirliği kutudan hazır verir. Maliyet ve kontrol takasını kabul ediyorsanız, en hızlı yol budur.

Dikkat etmeniz gereken altın kural şu: karmaşıklık bedavadır gibi görünür ama değildir. Her eklediğiniz bileşen (etcd, HAProxy, pgpool) ayağa kaldırmanız, izlemeniz ve bir gün arıza verdiğinde tamir etmeniz gereken yeni bir parçadır. İhtiyacınızdan fazla karmaşık bir mimari, çoğu zaman çözdüğü sorundan daha fazlasını yaratır. Önce gerçek RTO/RPO hedefinizi netleştirin, sonra o hedefin gerektirdiği kadar karmaşıklık ekleyin.

En sık yapılan üç hata

Yıllar içinde gördüğüm, neredeyse herkesin aynı yerlerde tökezlediği üç hata var. Mimariyi kurmadan önce bunları bilmek, size çok pahalı dersler kazandırır:

• Failover’ı hiç test etmemek. En yaygın ve en tehlikeli hata. Yedek sunucu kurulur, “var ya işte, gerekirse devreye girer” denir ve devralmanın gerçekten çalıştığı ilk kez felaket günü test edilir. Oysa failover, gerçek bir kesintiden önce, kontrollü bir tatbikatla defalarca denenmesi gereken bir süreçtir. Çalıştığını görmediğiniz bir yedek, yedek değildir.
• “Senkron her zaman daha güvenli” sanmak. Senkron replikasyon veri kaybını sıfırlar ama tek yedeğiniz varsa ve o yedek yavaşlar ya da düşerse, birincil de onay bekleyeceği için yazma işlemleri durabilir. Yani yanlış kurulmuş bir “güvenlik” önlemi, sistemin tamamını kilitleyebilir. Senkron kullanacaksanız en az iki yedek ve doğru bir synchronous_standby_names ayarı şart.
• İzleme ve yedeklemeyi unutmak. Yüksek erişilebilirlik, yedeklemenin yerine geçmez. Replikasyon bir hatayı (yanlış silinen tabloyu) anında yedeğe de kopyalar; yani replikasyon sizi insan hatasından korumaz. Sağlam bir yüksek erişilebilirlik kurulumu; replikasyon, düzenli yedek (WAL arşivleme dahil) ve sürekli izlemeyi birlikte ister.

Yedeğinizi gözle görün: izleme ve tatbikat

Yukarıdaki hataların çoğu tek bir alışkanlıkla çözülür: yedeğinize körlemesine güvenmek yerine onu düzenli olarak gözlemlemek. İşte bunun için ek bir şey kurmadan, doğrudan PostgreSQL’in kendi araçlarıyla çalıştırabileceğiniz birkaç pratik sorgu.

1. Birincilde: yedekler bağlı mı, ne kadar geride? Bu sorgu o an bağlı her yedeği ve replikasyon gecikmesini gösterir. durum alanı “streaming” değilse ya da geri kalan bayt sürekli büyüyorsa, bir sorun var demektir.

 SELECT client_addr AS yedek_adres, state AS durum, sync_state AS senkron_mu, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS geri_kalan_bayt, replay_lag AS gecikme FROM pg_stat_replication; 

2. Yedekte: bu sunucu gerçekten yedek mi ve ne kadar gecikmeli? İlk sorgu yedek modunda olup olmadığını (true ise yedek), ikincisi son uygulanan işlemin üstünden ne kadar zaman geçtiğini söyler.

 -- Bu sunucu yedek modunda mi? SELECT pg_is_in_recovery(); -- true = yedek -- Birincilin ne kadar gerisinde? SELECT now() - pg_last_xact_replay_timestamp() AS replikasyon_gecikmesi; 

Bu sorguları bir izleme paneline ya da basit bir zamanlanmış işe bağlayıp gecikme belli bir eşiği aştığında uyarı üretmek, “yedeğim sessizce koptu da haberim olmadı” felaketinin büyük kısmını ortadan kaldırır.

Bir de failover tatbikatı. Bir numaralı hata failover’ı hiç dememekti; çözümü de o kadar basit: planlı bir bakım penceresinde, bilerek deneyin. Kabaca akış şöyle:

• Yedeğin birincile gerçekten yetiştiğini yukarıdaki sorgularla doğrulayın (gecikme ~0).
• Birincili kontrollü biçimde durdurun (ya da aracınızın “switchover” komutunu verin).
• Yedeğin yeni birincile yükseldiğini ve uygulamanın ona yönlendiğini izleyin. Devralma kaç saniye sürdü? İşte o süre, sizin gerçek RTO’nuzdur; tahmininiz değil.
• Eski birincili yeni yedek olarak kümeye geri katın.
• Çıkan süreyi ve aksaklıkları not edin; bir dahaki sefere neyi hızlandıracağınızı belirleyin.

Bu tatbikatı düzenli yapın. Çünkü ölçmediğiniz bir RTO, hedef değil yalnızca temennidir; ilk kez felaket günü ölçmek istemezsiniz.

Bu yükü tek başınıza taşımak zorunda değilsiniz

Buraya kadar anlattıklarım kulağa derli toplu gelmiş olabilir. Ama gerçek hayatta işin zor tarafı seçeneği bilmek değil; o mimariyi kurmak, sürekli izlemek ve asıl önemlisi, failover gerçekten gerektiği anda kusursuz çalıştığından emin olmaktır. Çoğu ekip yedek sunucuyu kurar ama o yedeğin gerçekten devralabildiğini hiç test etmez; felaket günü de ilk kez orada test edilmiş olur.

İşte tam bu noktada veritabanı tarafını uzman bir ekibe emanet etmek mantıklı hale geliyor. DMC Bilgi Teknolojileri, Yönetilen Veritabanı Hizmeti ile tam olarak bu yükü üstleniyor:

• Yüksek erişilebilirlik mimarisi (replikasyon, failover, izleme) ihtiyacınıza göre kurulur ve düzenli test edilir.
• Sunucuların sağlığı ve performansı sürekli izlenir; sorunlar siz fark etmeden önce yakalanır.
• Yedekleme, güncelleme, güvenlik ve erişim gibi kritik işler uzman veritabanı yöneticileri tarafından yürütülür.
• Siz iş tarafına odaklanırken, verinin altyapısı sağlam ve ayakta kalır.

Bu modelin klasik destek hizmetinden farkını merak ediyorsanız, yönetilen servis ile destek hizmetini karşılaştıran şu yazı iyi bir başlangıç olabilir. İhtiyacınızı konuşmak isterseniz DMC ekibiyle iletişime geçebilirsiniz.

Sıkça Sorulan Sorular

PostgreSQL’de yüksek erişilebilirlik nedir?

Yüksek erişilebilirlik, bir sunucu çökse bile veritabanının hizmet vermeye devam etmesini sağlamaktır. PostgreSQL’de bunun temeli replikasyondur (veriyi başka bir sunucuya kopyalama); üstüne de Patroni gibi araçlarla otomatik devralma (failover) eklenir.

Akış tabanlı (streaming) ve mantıksal (logical) replikasyon arasındaki fark nedir?

Akış tabanlı replikasyon tüm sunucuyu bir bütün olarak, WAL günlüğü üzerinden kopyalar. Mantıksal replikasyon ise değişiklikleri tablo bazında kopyalar; seçici çalışabildiği ve farklı sürümler arasında iş gördüğü için özellikle yükseltmelerde ve kısmi kopyalamada tercih edilir.

PostgreSQL otomatik failover yapar mı?

Çekirdek PostgreSQL tek başına otomatik failover yapmaz; replikasyon yapar ama “birincil öldü, yedeği devreye al” kararını kendiliğinden vermez. Bu kararı otomatikleştirmek için Patroni, repmgr ya da pgpool-II gibi bir orkestrasyon aracı kullanılır.

Patroni mi repmgr mi seçmeliyim?

Bulut-yerel, Kubernetes üzerinde, çok düğümlü ve “saniyeler içinde dönmeli” diyen kurulumlar için genelde Patroni daha güçlüdür (etcd/Consul ile dağıtık uzlaşı kullanır). Daha küçük, klasik kurulumlar için ek bileşen gerektirmeyen repmgr çoğu zaman yeterli ve daha sade bir tercihtir.

Senkron replikasyon her zaman daha mı iyi?

Hayır. Senkron replikasyon veri kaybını sıfırlar (RPO=0) ama her işlem yedeğin onayını beklediği için yazma performansını düşürür. Performans kritikse ve birkaç saniyelik veri kaybını göze alabiliyorsanız asenkron daha doğru olabilir. Karar tamamen RPO hedefinize bağlı.

Yüksek erişilebilirliği bulutta hazır alabilir miyim?

Evet. Azure Database for PostgreSQL Flexible Server’ın zone-redundant seçeneği, Amazon RDS Multi-AZ ve Amazon Aurora gibi yönetilen servisler; replikasyon ve otomatik failover’ı kutudan hazır verir. Bu çözümler kurma ve işletme yükünü üstünüzden alır; karşılığında yedek sunucu için ek ücret ödersiniz ve ince ayarların bir kısmından feragat edersiniz.

Replikasyon gecikmesini (lag) nasıl ölçerim?

Birincil sunucuda pg_stat_replication görünümü her yedeği ve gecikmesini gösterir; pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) ile geri kalan baytı hesaplayabilirsiniz. Yedek sunucuda ise now() - pg_last_xact_replay_timestamp() sorgusu, birincilin ne kadar gerisinde olduğunuzu zaman cinsinden verir. Bu değerleri düzenli izleyip bir eşik aşıldığında uyarı kurmanız önerilir.

Özet

PostgreSQL’de yüksek erişilebilirlik tek bir düğmeye basmak değil; üst üste koyduğunuz katmanların toplamı. Altta veriyi kopyalayan replikasyon (çoğunlukla akış tabanlı), üstte ise o veriyi gerçek bir kesintide işe yarar kılan failover orkestrasyonu (Patroni, repmgr ya da pgpool-II) var.

Doğru tercihi belirleyen şey araçların kendisi değil, sizin RTO ve RPO hedefleriniz. Önce “ne kadar kesintiye ve ne kadar veri kaybına dayanabilirim?” sorusunu net cevaplayın; mimariyi de tam o cevabın gerektirdiği kadar karmaşık kurun. Ne eksik, ne fazla.

PostgreSQL dünyasında son dönemde nelerin değiştiğini, yapay zeka ve performans tarafındaki yeni soluğu merak ediyorsanız, PostgreSQL’in Yeni Çağı: POSETTE 2025 yazıma da göz atabilirsiniz.

Siz PostgreSQL tarafında hangi yüksek erişilebilirlik kurulumunu kullanıyorsunuz, başınızdan ilginç bir failover hikayesi geçti mi? Yorumlarda paylaşırsanız çok merak ederim. Bir sonraki yazıda görüşmek üzere 🙂