pgactive - Postgres için aktif-aktif çoğaltma eklentisi

• AWS tarafından geliştirilip yayımlanan, PostgreSQL için bir aktif-aktif çoğaltma eklentisi
• Birden fazla PostgreSQL örneğinde veriye yazma ve veri güncelleme gerektiğinde, yalnızca belirli bir örneğin değişiklik kabul ettiği mevcut aktif-standby modeli yerine, birden fazla örnekte eşzamanlı değişiklik ve çoğaltmanın mümkün olduğu bir yapı kurulabilir
• Birden fazla bölgede yüksek erişilebilir veritabanı mimarisi, yazma gecikmesini en aza indirme, uygulamanın blue/green güncellemeleri, çift yönlü veri migrasyonu gibi senaryolar için uygundur
• Mantıksal çoğaltma kullanarak çakışma tespiti, yazma çakışmalarını çözme, hedef veritabanı biçimi dönüşümü gibi özellikleri destekler

Aktif-aktif çoğaltma kavramı

• Çoğaltma (Replication), veritabanları arasındaki değişiklikleri senkronize etme teknolojisidir
• PostgreSQL'in mevcut aktif-standby yapısında yalnızca bir örnek değişiklik kabul eder ve diğerleri salt okunurdur; bu nedenle tek bir yer tek veri kaynağı rolünü üstlenir
• pgactive, aktif-aktif çoğaltma topolojisi sunarak birden fazla örnekte aynı anda veri yazılmasına izin verir
• Bu yaklaşım, birden fazla yazma noktasına ihtiyaç duyulan ortamlar için uygundur; örneğin çok bölgeli dağıtımlar veya çift yönlü migrasyonlar
• Aktif-aktif modelde çakışmalar, gecikme ve bazı özellik kısıtları için ayrıca yönetim gerekir

Temel teknoloji: mantıksal çoğaltma

• Mantıksal çoğaltma (Logical Replication), veriyi harici sistemlerin yorumlayabileceği bir biçimde iletir
• Mantıksal çoğaltma sayesinde hedef veritabanında çakışma tespiti, yazma çakışmalarının çözümü, sorgu dönüşümü gibi çeşitli ek işlevler uygulanabilir
• PostgreSQL, 2017'de yayınlanan sürüm 10 ile temel mantıksal çoğaltmayı tanıttı, ancak aktif-aktif çoğaltma için ek özellikler gereklidir
• PostgreSQL'in tasarım özellikleri sayesinde bu işlevler eklenti (extension) biçiminde geliştirilebilir ve uygulanabilir
• PostgreSQL geliştirici topluluğu da ilgili işlevleri kademeli olarak ana projeye eklemektedir

[GN⁺]

Hacker News görüşleri

• 2nd Quadrant ve EDB ekibindeki kişilerden duyduklarıma dayanarak BDR, pglogical, pgactive ve Postgres Distributed (PGD) tarihçesini özetleyeyim
  İlk çıkan ve hâlâ açık kaynak olan şey BDR1'di (bağlantı); pgactive de bunun üzerine kurulu
  BDR2, BDR1'in kapalı kaynak olarak yeniden yazılmış hâliydi ve sonunda rafa kaldırıldı
  pglogical v1 ve v2 (ikisi de açık kaynak, bağlantı) yayımlandı; bunlardan v1 büyük ölçüde değiştirilerek Postgres 10'a dahil edildi
  Postgres 10'daki mantıksal çoğaltma deneyimine dayanarak 2nd Quadrant pglogical v2 geliştirmeye başladı; pgEdge de buradan çıktı
  Daha sonra 2nd Quadrant, kapalı kaynak sürümler olan pglogical v3 ve BDR v3'ü yaptı; bunlar birleştirilerek BDR v4 oldu
  Ardından BDR ürününün adı Postgres Distributed (PGD, bağlantı) olarak değiştirildi
  2ndQuadrant, EDB tarafından satın alındıktan sonra EDB PGD v6'yı çıkardı
  • PostgresPro'nun da ayrı bir multi-master çoğaltma sistemi var doküman bağlantısı
  • PGDv6'nın hâlâ kapalı kaynak olup olmadığı soruluyor
• Bu sistem, Postgres'in Logical replication özelliğini kullanarak bir instance'taki değişiklikleri diğer instance'lara aktarıyor
  Çakışma olursa zaman damgasına göre en son yazılan değer nihai olarak uygulanıyor
  Çakışma kayıtları pgactive_conflict_history adlı özel bir tabloda tutulduğu için geçmişi incelemek ve elle çözümlemek mümkün
  Ayrıntılar ve dokümantasyon için buraya bakılabilir
  • Bunun multi-master replication sayılıp sayılmadığı merak ediliyor
    Eğer bu özellik resmî olarak Postgres'e kabul edilebilirse ilginç olabilir
  • Kullanıcı açısından, kendi yazmasının anında onaylanıp onaylanmadığını mı yoksa sonradan yakınsayan bir model mi olduğunu bilmek önemli
• Son zamanlarda Bloomberg'in veritabanını (comdb2) bizzat kullanmış biri olup olmadığı soruluyor
• Konuyla bağlantılı ama biraz farklı olarak, "yerelde yazılabilir (read replica tabanlı) replication" yapmanın bir yolu olup olmadığı soruluyor
  Örneğin production ya da staging verisini okuyan ama sadece yerelde değiştirilebilen ve sonuçları tekrar upstream'e yansımayan ikincil bir veritabanı isteniyor
  Şu anda çoğu durumda periyodik script'lerle (cron vb.) veri dökümü ya da sorgu alınıp snapshot oluşturuluyor, bu S3'e kaydediliyor, sonra yerelde indirilip geri yükleniyor
  Bu yöntem çoğunlukla işe yarıyor ama bazen indeks oluşturma çok uzun sürebiliyor
  • Bu arada, kişisel veriler gibi hassas bilgiler nedeniyle verinin bu şekilde doğrudan staging veya dev ortamlarına gitmesi riskli
    Hukuki ve etik boyutu büyük olduğundan çoğu şirkette bu yöntem önerilmiyor
  • Postgres'in logical replication özelliği filtrelerle birlikte kullanılırsa tek yönlü çoğaltma yapılabilir; replication slot bırakıldıktan sonra yerelde serbestçe değişiklik yapılabilir
    Böylece primary'yi etkilemeden yalnızca yerel tablolar değiştirilebilir
  • "Temiz" durumdaki bir yerel veritabanını yedek olarak tutup gerektiğinde bunu kopyalayarak geliştirme veritabanı olarak kullanırsanız, indeks oluşturma olmadan kopyalama çok hızlı olur
    createdb --template komutu öneriliyor
  • Yerel yazmalar ile uzak güncellemeler çakışırsa bunun nasıl ele alınacağı soruluyor
    Her duruma uyan genel geçer bir merge stratejisi akla gelmiyor
  • Bildiğim kadarıyla, Postgres logical replication kurulumunda bu zaten standart davranış
    Replica'da yazmayı engellemez; sadece bunun sonucu başka yerlere yayılmaz
• "Conflict resolution" teriminin, özünde "zaten commit edilmiş ve kabul edilmiş veriyi atarak dayanıklılığı bozmak" anlamına geldiğini hep akılda tutmak gerekir
  En iyi yaklaşım, tüm active instance'lar genelinde yazılacak veri alanlarının çakışmayacağı şekilde mimari tasarlamaktır
  Böyle durumlarda pgactive gibi araçlar işe yarayabilir
  Ya da en baştan dağıtık bir veritabanı (Yugabyte vb.) kullanmak daha doğru olabilir
  • Resmî doküman da çakışmadan kaçınmak için master'lar arasında schema bölünmesini ve "her master'ın her schema için tek writer olması" yaklaşımını öneriyor
    Tüm master'lar tüm schema'ları okuyabiliyor ama yazma tarafında herkes sadece kendi alanından sorumlu oluyor
    Schema yerine partition gibi yapılarla da sorumluluk dağıtılıp dağıtılamayacağı soruluyor
• AWS'nin bunu neden yaptığı düşündürücü
  Kendi ürünlerinde bunu doğrudan nerede kullandıkları akla gelmiyor
  RDS block replication, Aurora ise kendine özgü SAN replication kullanıyor
  Belki DMS tarafında kullanmayı hedefliyor olabilirler diye tahmin ediliyor
  • Muhtemelen yakın zamanda çıkan Aurora DSQL ile ilgilidir
  • Aslında büyük bir faydası pek görülmüyor
    Güçlü ACID ilişkisel veritabanlarında neden özellikle buna ihtiyaç duyulsun, sorgulanıyor
  • Bildiğim kadarıyla Aurora'nın SAN replication'ı cross-region replication için kullanılmıyor
  • İlgili depo README'sinde de "başlıca kullanım amacı Multi-Region yüksek erişilebilirlikli veritabanı kümesi kurmak" deniyor
  • Aslında bunun RDS Postgres'te 2 yıl kadar önce sunulmaya başlandığı söyleniyor (ilgili bağlantı)
    Ancak 1 ay önce topluluğa açık kaynak olarak resmî şekilde yayımlandığı haberleri çıkmıştı (resmî haber)
• repmgr ve patroni ile neredeyse tamamen kesintisiz biçimde birden çok cluster çalıştırdım; bu eklentiyi gerçekten ancak en son çare olarak kurmak isterim
  Geceleri rahat uyumak istiyorsam mümkün olduğunca uzak durmak isterim
• Tesadüfen yakın zamanda "otomatik failover, node recovery ve point-in-time recovery" yapabilen yüksek erişilebilirlikli bir Postgres cluster'ını kolayca kurmanın yollarını arıyordum
  patroni+etcd+haproxy kombinasyonu çok öneriliyor; gerçekten kullanmış kişilerin bu kadar heyecanla önermesinin bir nedeni vardır herhâlde
  Yine de docker compose ile verilen örnek dosyalara bakınca biraz göz korkutucu geliyor
  pgpool ise her postgres'in önüne koyulan bir katman gibi göründüğünden daha basit duruyor
  Gerçek üretim ortamında Postgres seven insanların önerileri ya da deneyimleri merak ediliyor
  Hedef, docker compose tabanlı olarak olabildiğince kolay şekilde yüksek erişilebilirlik, (en azından) veri kaybını en aza indirme ve point-in-time recovery destekli bir cluster kurmak
  • Acaba Barman gibi bir araç mı arıyorsunuz diye soruluyor
  • cloudnativepg kullandığını ve bununla gerekli özelliklerin çoğunun doğrudan çalıştığını söyleyen var
• pgactive ve ilgili örnekler hakkında başka kaynaklar paylaşılmış
  <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
  Hacker News gönderisi (Ekim 2023 tarihli, 1 yorum)
• Bunun asenkron çalıştığı anlaşılıyor ve transaction isolation açısından ciddi sorunlar olabilir gibi görünüyor
  • Sonuçta bunun bir trade-off olduğu görüşü var
    Yani herkesin kendi durumuna göre artı ve eksileri kabul etmesi gerekiyor