pgBackRest artık bakım almıyor

 (github.com/pgbackrest)
3 puan yazan GN⁺ 2 일 전 | 1 yorum | WhatsApp'ta paylaş
  • PostgreSQL için yedekleme ve kurtarma aracı olarak büyük ölçekli ortamlara kadar genişleyecek şekilde tasarlanmıştı, ancak artık bakımı sona erdi
  • bug fix, PR review, issue yanıtları ve yeni özellik geliştirme tamamen durduruldu; düzensiz biçimde sürdürmek yerine net biçimde durdurma yolu seçildi
  • tam, differential, incremental yedekleme ile block-level backup, yarıda kalan işleri sürdürme ve delta restore desteği sayesinde yalnızca değişen kısımlar kaydedilip geri yüklenebiliyor
  • yerel ve uzak ortamları kapsayan bir protocol layer ve multiple repositories sunuyor; TLS·SSH bağlantıları ile S3·Azure·GCS uyumlu object store desteği üzerinden operasyon kapsamını genişletiyordu
  • checksum, WAL segment bekleme, fsync, page checksum doğrulaması gibi bütünlük güvencesi mekanizmaları açısından oldukça kapsamlı bir araçtı; ancak bundan sonra bir fork çıksa bile ayrıca güven inşa etmesi gerekecek

Bakımın sona ermesi ve projenin durumu

  • pgBackRest, PostgreSQL için bir yedekleme ve kurtarma aracı, ancak artık bakım almıyor
  • Proje üzerindeki çalışmalar durduruldu ve bundan sonra bug fix, PR review, issue yanıtları ile yeni özellik geliştirmeye zaman ayrılmayacağı açıklandı
  • Mevcut sponsorluk ve istihdam biçimleri sona erdikten sonra da bakım sürdürülmek istendi, ancak projeyi devam ettirecek kadar iş fırsatı ve sponsorluk sağlanamadı
  • Bakımı düzensiz ya da eksik biçimde sürdürmektense, net biçimde sonlandırmanın daha iyi olduğu düşünülüyor
  • İleride biri bir fork çıkarabilir, ancak bu durumda o çalışma yeni bir proje sayılacak ve yeni bakımcının ayrıca güven kazanması gerekecek

Projenin temel özellikleri

  • Büyük ölçekli PostgreSQL ortamlarına kadar ölçeklenebilen yedekleme ve kurtarma hedefleniyor; mevcut kararlı sürüm v2.58.0
  • Paralel işleme ile lz4, zstd gibi sıkıştırma yöntemleri kullanılarak yedekleme sırasında darboğaz olmaya yatkın sıkıştırma maliyetini azaltacak şekilde tasarlanmış
  • Tam, differential ve incremental yedeklemeyi destekliyor; dosya düzeyinin yanı sıra block-level backup ile yalnızca değişen kısımlar kopyalanıp depolama alanından tasarruf sağlanıyor
  • Yarıda kalan yedeklemeler sürdürülebiliyor ve manifest içindeki checksum ile karşılaştırma yapılarak daha önce kopyalanmış dosyaların bütünlüğü yeniden doğrulanıyor
  • Delta restore sırasında yedekte olmayan dosyalar önce kaldırılıyor, ardından kalan dosyaların checksum değerleri karşılaştırılıyor; eşleşen dosyalar olduğu gibi bırakılırken yalnızca gerekli olanlar geri yükleniyor

Uzak kullanım ve depo tasarımı

  • Kendi protocol layer yapısı sayesinde hem yerel hem de uzak ortamlarda yedekleme, kurtarma ve arşiv işlemleri yapılabiliyor; uzak bağlantılarda TLS/SSH kullanılıyor
  • Aynı protocol layer ile PostgreSQL sorgu arayüzü de sağlanıyor; böylece PostgreSQL'e doğrudan uzaktan bağlanmadan işlem yapılabildiği için güvenlik artırılıyor
  • multiple repositories desteği sayesinde hızlı kurtarma için yerel depo ile uzun süreli saklama ve yedeklilik için uzak depo birlikte kullanılabiliyor
  • Depolar S3, Azure, GCS uyumlu object store üzerinde de tutulabiliyor; bu da kapasiteyi ve saklama süresini ciddi ölçüde artırabiliyor
  • Deponun kendisi şifrelenebiliyor, böylece yedek verisi nerede tutulursa tutulsun korunabiliyor

Bütünlük ve tutarlılık sağlama yöntemleri

  • Yedeğin içindeki tüm dosyalar için checksum hesaplanıyor ve restore ya da verify sırasında yeniden kontrol ediliyor
  • Dosya kopyalama tamamlandıktan sonra, yedeği tutarlı hale getirmek için gerekli tüm WAL segment dosyalarının depoya ulaşması bekleniyor
  • Tüm işlemlerde dosya ve dizin düzeyinde fsync kullanılarak dayanıklılık sağlanıyor
  • PostgreSQL'de page checksum açıksa, tam yedeklemede tüm dosyaların sayfa checksum değerleri doğrulanıyor; differential ve incremental yedeklemelerde ise yalnızca değişen dosyalar kontrol ediliyor
  • Sayfa checksum doğrulaması başarısız olsa bile yedekleme durmuyor; ancak hangi sayfalarda hata olduğu uyarı olarak bırakılıyor, böylece geçerli bir yedek süresi dolmadan önce page-level corruption erken tespit edilebiliyor

WAL işleme ve kurtarma performansı optimizasyonu

  • WAL push/get için özel komutlar sunuluyor; her ikisi de paralel işleme ve asenkron yürütmeyi destekleyerek PostgreSQL yanıt süresini olabildiğince hızlı tutacak şekilde tasarlanmış
  • WAL push, aynı WAL segment birden fazla kez gelirse bunu otomatik olarak tekilleştiriyor; içerik farklıysa hata üretiyor
  • Asenkron WAL push'ta aktarımı başka bir süreç üstleniyor ve WAL segment'leri paralel biçimde sıkıştırılıyor; bu yüzden yazma hacmi çok yüksek veritabanlarında özellikle önemli
  • Asenkron WAL get, sıkıştırması açılmış WAL queue yapısını yerelde tutarak replay öncesinde veriyi anında sağlayabiliyor; bu da yüksek gecikmeli bağlantılarda veya S3 benzeri depolarda özellikle avantajlı
  • Hem WAL push hem de get, veritabanı ile deponun uyumlu olup olmadığını anlamak için PostgreSQL sürümünü ve system identifier değerini karşılaştırıyor; böylece WAL archive konumunun yanlış yapılandırılması olasılığı ciddi ölçüde azalıyor

Operasyonel esneklik ve uyumluluk

  • backup retention ve archive expiration politikaları full, differential ve WAL düzeyinde ayrı ayrı ayarlanabiliyor; böylece istenen zaman aralığı kapsanabiliyor
  • Yedekler PostgreSQL cluster biçiminde olduğu gibi saklanabiliyor; sıkıştırma kapatılıp hard link etkinleştirilirse PostgreSQL cluster bir depo snapshot'ı üzerinde doğrudan da çalıştırılabiliyor
  • Bu yaklaşım, geleneksel restore işleminin uzun sürdüğü terabyte-scale database ortamlarında avantaj sağlıyor
  • tablespace tam olarak destekleniyor; restore sırasında her tablespace farklı bir konuma taşınabiliyor veya tek bir konuma topluca remap edilebiliyor
  • Dosya ve dizin link'leri de destekleniyor; restore sırasında özgün konumu koruma, kısmi ya da tam remap ve normal dosya ya da dizin olarak geri yükleme mümkün
  • PostgreSQL'in 10 sürümü destekleniyor; hâlen desteklenen 5 sürüm ile EOL olmuş en son 5 sürüm dahil edilerek yükseltme için geniş zaman tanınması amaçlanıyor

Referans kaynaklar ve sponsorluk durumu

İlgili okumalar

1 yorum

 
GN⁺ 2 일 전
Hacker News yorumları
  • Yazarın LinkedIn’de paylaştığı yazıya bakılırsa, 13 yıldır pgBackRest için harcadığı zaman ve emek gerçekten çok büyüktü ve artık bakımı durdurma kararı almış
    Şirket desteği de vardı ama gecelerini ve hafta sonlarını da buna vermiş; Crunchy Data satıldıktan sonra da bakımı sürdürürken bu işi devam ettirebileceği bir pozisyon aramış ama işler istediği gibi gitmemiş
    Geçimini sağlayabilmek için daha geniş fırsatlara bakması gerekiyor ve bu durumda bakım, hata düzeltme, PR inceleme ve issue takibi için gereken zamanı artık ayıramayacağı için depoyu arşivleyeceğini söylüyor
  • Kişisel projelerde pgBackRest kullanmış, hatta yerel volume’ler ve bulut depolama için PostgreSQL yedekleme rehberi bile hazırlamış biri olarak bunu çok faydalı buluyordu; işlerin böyle bitmesine üzüldüğünü söylüyor
    Rehber şu adreste: https://github.com/freakynit/postgre-backup-and-restore-guide ve bugüne kadar verdiği tüm zaman ve emek için gerçekten teşekkür ediyor
    • Bugünlerde yapay zeka beklentileri yüzünden geliştiricilerin daha sıkışık teslim tarihleri altında çalıştığını ve zamanlarının daha da azaldığını düşünüyor
      Üstelik token’lara para gömen çok kişi olduğu için hem boşta para hem de zaman azalmış durumda olabiliyor
    • Bu tür projelerin yeterli finansman bulamadığı için yok olup gitmemesini dilediğini, açık kaynağın pratikte yaşadığı zorlukların çok büyük olduğunu söylüyor
  • Burada başarısız olan şeyin açık kaynak modelinin kendisi değil, yazarın artık finansal destek bulamayıp yön değiştirmesi olduğunu ve bunun da gayet makul olduğunu düşünüyor
    Eğer bu, hobi projesini aşarak ticari ortamda gerçek değer üreten ürün düzeyinde bir araçsa, bu boşluğu doldurmak için kâr amaçlı bir şirketin devreye girmesi için kesinlikle bir fırsat vardır
    Ama bunun için kullanıcıların müşteriye dönüşüp gerçekten para ödemesi gerekir; ücretsiz bakım yapan kişilere sürekli hata raporu ve şikayet göndermekle bu iş sürdürülebilir olmaz
    FOSS’un finansal sürdürülebilirliği için yeni çözümler gerektiğini, bağışların tek başına yeterli görünmediğini düşünüyor
    • Hangi ekosistem olursa olsun, gerçekten yaşamasını istiyorsam bizzat destek olmam gerektiğini öğrendiğini söylüyor
      Mahalledeki dükkân da olsa açık kaynak proje de olsa durum aynı
    • Yazarın bunu ücretli bir ürüne dönüştürme ihtimalini değerlendirip değerlendirmediğini merak ediyor
      Ancak katkı yapan herkesin telif hakkı devreye girebileceği için, ACL olup olmadığına ve yargı alanına bağlı olarak hakların düzenlenmesi gerekebilir; gelir paylaşımı gibi konularda da uzlaşı lazım olabilir
  • İnsanların daha çok dikkat etmesi gereken tarafın Crunchy Data satın alımı olduğunu düşünüyor
    Kurumsal destek varken her şey yürüyordu ama şirket satılıp yeni sahip öncelikleri değiştirince 3.8k yıldızlı bir altyapı aracı bir anda kırılgan hale geldi; yani kullanıcılar, kendi yedekleme araçlarının finansmanının başkalarının M&A stratejisine bağlı olduğunun farkında değildi
    Bu yüzden kendisi de yavaş yavaş SQLite ve git ile izlenen dosya tarafına kayıyor
    Çünkü yönetilen Postgres yığınları da sonuçta finansal durumunu bilmediğimiz kişilerin bakımını yaptığı birçok aracın üstüne kurulu
    • Tamamen ortadan kalkmış değil; en azından şu an için yedeklerin durduğu bir durum yok diye düşünüyor
      Yine de finansman yapısının kırılgan olduğu yönündeki büyük resim hâlâ geçerli
    • Ama SQLite da aynı risklerden tamamen muaf değil; neden daha güvenli görüldüğünü merak ediyor
  • Kaynak kod hâlâ duruyor; bu yüzden sadece üzülmek yerine doğrudan fork’layıp sürdürmek ya da birine ücret ödeyip bakımını üstlendirmek de bir seçenek
    Hazır bunu düşünüyorken, kaybetmek istemediğimiz bağımlı projeleri gözden geçirip daha şimdi destek vermeye başlamanın doğru olacağını söylüyor
    • Bunun doğru yaklaşım olduğunu düşünüyor
      Herkes üzgün olduğunu söylüyor ama gerçekten üzgünse önce bağış yapacak kadar üzgün mü diye sormak gerekir
  • Ekosistemi doğru gördüyse pgBackRest, PostgreSQL yedekleme alanındaki en iyi çözümdü
    Özellikle yalnızca yedekleme değil, geri yükleme ve doğrulama konularını da ciddiyetle ele alması çok nadirdi; bunları hafife almanın iş yerinde kendisine ağır patladığı da olmuş
    Ayrıntılar burada: https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
    Bu yüzden bunu oldukça büyük bir kayıp olarak görüyor
  • Bu epey şaşırtıcı; kendisi bunun fiilen önde gelen PG yedekleme/geri yükleme aracı olduğunu düşünüyormuş
    WAL-G ya da Barman ile karşılaştırınca durumun nasıl olduğunu merak ediyor
    https://github.com/wal-g/wal-g
    https://github.com/EnterpriseDB/barman
    • Tam bir karşılaştırma yapamayacağını söylüyor ama Barman’ı uzun süredir kullanıyorlar ve çok memnunlar
      Her gece Barman ile geri yüklenmiş bir nightly DB oluşturup bunu kullanıcı eğitimi ve test için de çalıştırıyorlar; böylece yedeklerin gerçekten bozuk olup olmadığını sürekli doğrulamış oluyorlar ve yıllardır sorun yaşamamışlar
    • Kendisi wal-g bakımcılarından biri ve özellik açısından rahatlıkla karşılaştırılabilir bir seviyede olduğunu düşünüyor
      Birkaç yıllık durgunluğun ardından tekrar managed Postgres tarafına döndüklerini ve wal-g’nin kendi blok karşılaştırmasıyla sunduğu delta backup’ın yanı sıra pg17 incremental backup desteğini de görmek istediğini söylüyor
      Ayrıca daemon mode’u kesinlikle kullanmak gerektiğini ekliyor
      Rakip bir aracın kaybolması üzücü ama bu alanda hâlâ geliştirilecek çok şey var; Postgres overcommit olmayan sistemlerde çalışmak istediğinde de C’nin Golang’a göre avantajları olabiliyor
    • Eskiden WAL-E, şimdi de onun halefi WAL-G’yi memnuniyetle kullanmışlar
      Yaklaşık 9 yıl önce değerlendirme yaparken streaming PITR özellikleri nedeniyle pgBackRest’ten daha cazip gelmiş
    • Bunun önde gelen araç sayılmasını anlıyor ama https://xkcd.com/2347/ gibi bir durumu da hatırlatıyor
  • Kendisi 2TB’lık üretim veritabanında pgBackRest’i memnuniyetle kullanıyormuş ve tam da bu hafta 8TB’lık veritabanına da eklemeyi planlıyormuş
    Şimdi en yakın alternatifin wal-g mi, barman mı, yoksa databasus mu olduğunu merak ediyor
    Kendisiyle ilgili “DBA taklidi yapıyorum” demiş ama aslında bu seçim oldukça önemli
    • 30TB+ ölçekli veritabanlarında Barman kullanmış biri olarak ciddi bir şikâyeti olmadığını söylüyor
      Not olarak da kendisinin DBRE olduğunu ekliyor
    • Çok terabaytlı üretim Postgres yedekliyorsan bunun DBA taklidi değil, işi gerçekten yapıyor olmak anlamına geldiğini söylüyor
    • Yedekleri bulut depolamada tutan bir kurulumsa, hook script’leri eklenmiş Barman en yakın alternatif gibi görünüyor
      İlgili doküman: https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman
      https://github.com/aiven-open/pghoard da iyi görünüyor ama henüz bizzat doğrulamamış
    • Kimsenin standby’ı ZFS ya da başka snapshot alabilen bir dosya sistemi üstünde tutup oradan yedek almayı deneyip denemediğini merak ediyor
    • Kendisi pgBackRest’i daha önce hiç kullanmamış ama tam 2 saat önce bir projeye eklemeye başlamış; README’yi bitirdiğinde çoktan güncellenmişti
  • pgBackRest, PostgreSQL yedekleme teknolojileri arasında en çok yönlü olanlardan biri ve kendi deneyimine göre diğer ürünler bu seviyeye tam ulaşamıyor
    Bu yüzden olanlar daha da üzücü ve bu harika araçla özellik eşdeğerliği yakalamak kolay olmayacak gibi görünüyor
    Mümkünse geri alınabilir bir karar olmasını umuyor; olmazsa PostgreSQL projesinin bunu contrib olarak bünyesine katmasının da iyi olacağını düşünüyor
  • Şimdilik kullanmaya devam edilebilir, yani olduğu gibi kullanılabilir
    Yazara göre de insanlar muhtemelen bunu hemen terk etmek yerine, gerçekten artık çalışmaz hale gelene kadar kullanmaya devam etse daha iyi olur
    • Ve o zamana kadar birilerinin yeni bakımcı olarak ortaya çıkmasını umuyor
      Bunun için fork gerekip gerekmediğini ya da mevcut depoya katkıcı olarak eklenip oradan devralmanın mümkün olup olmadığını bilmediğini söylüyor