PostgreSQL Streaming Replication (WAL) nedir ve nasıl yapılandırılır?

• PostgreSQL'de Streaming Replication, bir veya daha fazla standby sunucuda birincil DB'nin neredeyse gerçek zamanlı kopyalarını tutmanın verimli bir yoludur
• Birincil sunucu, oluşturulan Write-Ahead Log (WAL) kayıtlarını standby sunuculara sürekli olarak göndererek çoğaltma sürecindeki gecikmeyi en aza indirir
• Yüksek erişilebilirlik ve ölçeklenebilirlik artışı için tasarlanmıştır; okuma sorguları standby sunuculara aktarılabilir, böylece birincil sunucunun yükü azaltılabilir
• Hem senkron hem de asenkron modları destekleyerek veri tutarlılığı ile performans arasındaki dengeyi esnek biçimde ayarlamayı mümkün kılar
• Standby sunucunun birincile bağlanıp WAL streaming talep etmesi ve aldığı kayıtları kendi DB kopyasına uygulaması sürecini içerir
• Dosya tabanlı log aktarımına kıyasla daha hızlı failover ve daha düşük veri kaybı riski sunar; bu da onu coğrafi olarak dağıtık ortamlar için ideal hale getirir

Streaming Replication nasıl çalışır?

• Birincil sunucudan standby sunucuya WAL verileri gerçek zamanlı olarak sürekli aktarılır; böylece standby üzerindeki DB, birincille neredeyse aynı durumda tutulur
• Bu sayede çoğaltmalar master failover veya okuma iş yüklerini işlemek için kullanılabilir ve sistemin katlanarak ölçeklenmesi mümkün olur

PostgreSQL yapılandırma dosyaları ve konumları

• PostgreSQL yapılandırma dosyaları, veritabanı sunucusunun ayarlarını ve davranışını yönetmede kritik rol oynar.
  • postgresql.conf: Sunucu ayarlarının çoğunu içeren ana yapılandırma dosyası. İşletim sistemine göre /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) veya /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS) gibi farklı konumlarda bulunabilir
  • pg_hba.conf: İstemci kimlik doğrulamasını kontrol ederek istemcilerin sunucuya nasıl bağlanacağını tanımlar. Genellikle postgresql.conf ile aynı dizinde yer alır
  • pg_ident.conf: Kullanıcı adı eşleme için kullanılır, ancak daha seyrek kullanılır
  • recovery.conf: PostgreSQL 12 öncesi sürümlerde standby sunucu yapılandırması için kullanılıyordu; sonraki sürümlerde içeriği postgresql.conf ve postgresql.auto.conf dosyalarına taşındı
• Tam konum, işletim sistemi, kurulum yöntemi ve PostgreSQL sürümüne göre değişebilir
  • PostgreSQL instance'ı içinden bu dosyaların konumunu bulmak için SHOW config_file; SQL komutu kullanılabilir

WAL (Write Ahead Logs) örnekleri ve yapısı

• WAL, pg_waldump komutuyla görüntülenebilir
• Her satır, DB işlemiyle ilgili bilgi içeren bir WAL kaydını temsil eder
• Her kaydın bileşenleri:
  • rmgr: kaynak yöneticisi (ör. Heap, Btree, Transaction)
  • len: kayıt uzunluğu
  • tx: transaction ID
  • lsn: log sequence number
  • prev: önceki LSN
  • desc: işlem açıklaması
• Görülebilen işlem türleri:
  • INSERT işlemleri (Heap ve Btree)
  • MULTI_INSERT işlemleri (Heap2)
  • COMMIT transaction
  • Dosya işlemleri (CREATE)
  • Full Page Writes (FPW)
• WAL çıktısı transaction akışını, veri değişikliklerini ve sistem etkinliğini ayrıntılı biçimde gösterir; bu nedenle DB davranışını analiz etme, sorun giderme ve point-in-time recovery için faydalıdır

Docker ile nasıl çalışılır

• postgresql.conf içinde Streaming Replication ile ilgili önemli ayarlar:
  • wal_level, max_wal_senders, max_replication_slots, hot_standby vb.
• Docker Compose örneği için gerekenler:
  • init-master.sh: PostgreSQL master'ı çoğaltma için yapılandırır. Çoğaltma kullanıcısı ve slot oluşturur, WAL ile ilgili ayarları günceller
  • init-replica.sh: PostgreSQL replica'yı master'a bağlanıp çoğaltmayı başlatacak şekilde hazırlar. Master hazır olana kadar bekler, ardından base backup alır ve replica'yı yapılandırır
  • start-replica.sh: Docker konteyneri içinde PostgreSQL replica'yı başlatır. init-replica.sh betiğini çalıştırdıktan sonra PostgreSQL'i başlatır
  • docker-compose.yml: Master ve replica servislerini tanımlar; gerekli ortam değişkenlerini, volume'leri, komutları vb. ayarlar
• Betiklere çalıştırma izni verildikten sonra docker-compose up -d komutu çalıştırıldığında master ve replica başlar
• Master'a bağlanarak pg_stat_replication ile çoğaltma durumunu kontrol etmek mümkündür
• Replica'ya bağlanarak pg_is_in_recovery() ile recovery modunda olup olmadığı doğrulanabilir

GN⁺ görüşü

• Streaming Replication, veritabanı altyapısının performansını ve dayanıklılığını önemli ölçüde artırabilir. İster failover senaryolarına hazırlanıyor olun ister okuma yükünü replica'lara dağıtıyor olun, bu yaklaşım DB'nin ölçeklenmesine ve istikrarlı performans sağlamasına yardımcı olabilir
• Tüm yapılandırma sürecini ve çıktıları göstermek önemlidir. Bu, çok sayıdaki hareketli parçaya dair bütüncül bir bakış sunar ve neler olup bittiğini daha iyi anlamayı sağlar
• Streaming Replication'ın nasıl çalıştığını anlamak ve onu doğru şekilde yapılandırmak çok önemlidir. Bu yazının süreci netleştirdiği ve çoğaltmanın nasıl çalıştığına dair içgörü sunduğu umulur
• Benzer işlevlere sahip diğer ürün veya projeler arasında MySQL Replication ve Oracle Data Guard bulunur. Bu çözümler de değişiklikleri master'dan replica'ya aktarma mantığıyla çalışır, ancak uygulama ayrıntıları farklı olabilir
• Streaming Replication kullanılırken ağ bant genişliği ve gecikme dikkate alınmalıdır. Master ile replica arasındaki veri aktarımı ağ kaynaklarını ciddi ölçüde tüketebilir. Replica tarafının ölçeklenebilirliği de önemli bir değerlendirme noktasıdır
• Veri tutarlılığı gereksinimleri de değerlendirilmelidir. Senkron çoğaltma yazma performansını etkileyebilir ancak daha güçlü tutarlılık sağlar. Asenkron çoğaltma daha iyi performans sunar, ancak az da olsa veri kaybı olasılığı vardır

[GN⁺]

Hacker News görüşleri

• Bu yazı harika olsa da, bir full-stack geliştirici olarak veritabanını yönetmeye çalışma açısından bakıldığında pratik uygulama örneklerinin yetersiz olduğunu düşünen bir görüş var

  • Replikanın master'dan ne kadar geride olduğunu nasıl kontrol edebileceğine dair bir soru var
  • Replikayı izleme yöntemi olarak, basit bir cron işiyle durumu kontrol etmeyi öneriyor
  • Daha karmaşık bir konu olarak, ana sunucu çökerse replikaya nasıl geçileceğine dair bir soru var
  • Geçişin otomatik mi yoksa manuel mi yapılması gerektiğine dair bir değerlendirme var
  • Split-brain senaryosundan kaçınmak için iki replika gerekip gerekmediğine dair bir soru işareti var
  • Geçişten sonra özgün duruma nasıl geri dönüleceğine dair bir soru var

• PostgreSQL replikasyonu için en kolay çözümün bir Kubernetes operatörü olduğunu savunuyor

  • Örnek olarak CloudNativePG'den bahsediyor
  • Yalnızca replikasyon değil, failover, kurtarma, izleme, otomatik iyileşme, yedekleme gibi şeylerin de gerektiğini açıklıyor
  • Kubernetes dışında başka ücretsiz/açık kaynak uygulamalar olup olmadığına dair bir soru var

• Kubernetes ve Helm kullanmanın nedenlerinden birinin bu sorunu çözebilmek olduğunu düşünüyor

  • Bitnami PostgreSQL paketiyle, neredeyse hiç ek yapılandırma olmadan her şeyin kurulabildiğini açıklıyor
  • Postgres-ha'nın bir proxy oluşturarak hataları profesyonelce ele aldığını ve böylece kesintisiz failover sağladığını söylüyor

• Kubernetes kullanıcılarına StackGres'i öneriyor

• Son olarak, bu yazının yapay zeka tarafından yazılmış gibi göründüğüne dair şüpheci bir görüş var