Litestream artık hızlı nokta-zaman kurtarmayı destekliyor

 (fly.io)
6 puan yazan GN⁺ 2025-05-22 | 2 yorum | WhatsApp'ta paylaş
  • Litestream, SQLite tabanlı tam yığın uygulamaları nesne depolamaya güvenle yedekliyor ve bu sürüm şimdiye kadarki en büyük özellik değişikliğini getiriyor
  • Önceki yapıya göre daha verimli LTX dosya formatı ve compaction tekniği uygulanarak hızlı ve verimli nokta-zaman kurtarma mümkün hale geliyor
  • Conditional write kullanan yeni yaklaşımla reader singleton ve read replica özelliklerinin uygulanması basitleştiriliyor
  • Yakında VFS tabanlı read-replica katmanı sunularak farklı ortamlarda kolay ölçeklenebilirlik sağlanacak
  • Büyük ölçüde iyileştirilen mimari sayesinde çok sayıda veritabanı aynı anda senkronize edilebiliyor ve ölçeklenebilirlik artıyor

Litestream'e giriş ve önemi

  • Litestream, açık kaynaklı bir araç olarak SQLite tabanlı çeşitli tam yığın uygulamaları nesne depolamaya güvenle yedekleme işlevi sunuyor
  • SQLite'ın gömülü yapısı nedeniyle verinin tek bir sunucuya bağımlı kalması sorununu çözüyor ve sunucu arızası durumunda veri kurtarmayı kolaylaştırıyor

Litestream'in gelişim süreci

  • SQLite'ı daha kolay kullanabilmek için Litestream 2020'de ortaya çıktı
  • Litestream, SQLite uygulamasından ayrı bir süreç olarak çalışıyor ve WAL checkpointing sürecinin yerini alarak veri değişikliklerini gerçek zamanlı olarak S3 gibi nesne depolamaya stream ediyor
  • Sunucu kaybedilse bile veritabanı nesne depolamadan en güncel duruma verimli şekilde geri yüklenebiliyor
  • Daha sonra LiteFS adlı proje geliştirilerek read replica ve temel failover desteği eklendi; böylece SQLite, Postgres benzeri modern dağıtım mimarilerinde kullanılabilir hale geldi
  • LiteFS ve Litestream'in ikisinin de avantajları var, ancak Litestream dağıtımı ve kullanımı daha kolay olduğu için daha yaygın kullanılıyor

Verimli nokta-zaman kurtarma

  • Önceki Litestream tasarımı tüm değişiklikleri sürekli kaydedip S3'e gönderiyordu, ancak verinin sık değiştiği durumlarda kurtarma açısından verimsiz kalıyordu
  • LiteFS, transaction-aware bir yaklaşım benimsedi ve değişen sayfa aralıklarını sıralayarak kaydeden LTX dosya formatını kullandı
  • Birden fazla LTX dosyası kolayca birleştirilip (compaction) yalnızca en güncel sürüm bırakılabiliyor; bu da veri kurtarma hızını ve verimliliğini büyük ölçüde artırıyor
  • Bu yapı LSM tree'ye benziyor
  • Yeni Litestream da LTX dosyaları ve compaction yaklaşımını benimseyerek çok fazla yinelenen depolama olmadan hassas nokta-zaman kurtarmayı destekliyor

CASAAS: Compare-and-Swap as a Service

  • Litestream, SQLite uygulaması yedekleme sisteminin farkında olmasa bile çalışabilmeli; ancak arıza gibi nedenlerle süreç ölürse veri değişikliklerinin bir kısmı kaçırılabiliyor
  • Bu sorunu çözmek için her yedekleme oturumunu ve ona ait günlük akışını benzersiz şekilde tanımlayan generation kavramı tanıtıldı
  • LiteFS, tek bir reader'ı garanti etmek için Consul kullanıyordu; ancak harici bağımlılık gereksinimi nedeniyle Litestream, S3 gibi nesne depolamanın conditional write özelliği ile tekil çoğaltma yolunu (singleton) daha basit biçimde uyguluyor
  • Böylece ephemeral node ortamlarında da karışıklık olmadan istikrarlı çalışma mümkün oluyor

Hafif read replica özelliği

  • LiteFS, transaction awareness için FUSE dosya sistemini kullanıyor, ancak bu karmaşıklık ve benimseme yükü getiriyor
  • Bunu hafifletmek için LiteVFS adlı SQLite Virtual Filesystem (VFS) genişletme modülü tasarlandı; böylece FUSE olmadan da farklı ortamlarda çalışabiliyor
  • Gelecekte aynı VFS tabanlı katman Litestream'e de uygulanacak ve S3 gibi nesne depolamadan doğrudan sayfa fetch edip cache'leyen bir read-replica katmanı sunulacak
  • Yerel SQLite kadar hızlı olmasa da caching ve prefetching stratejileri sayesinde birçok kullanım senaryosunda tatmin edici performans sunması bekleniyor

Açık kaynak ve kullanım esnekliği

  • Litestream tamamen açık kaynak ve Fly.io'ya bağlı değil; her yerde kullanılabiliyor
  • Çok sayıda veritabanını tek bir süreçten senkronize etme özelliği eklendiği için yüzlerce ila binlerce veritabanı verimli şekilde yedeklenip çoğaltılabiliyor

SQLite ile sürekli birlikte gelişim

  • SQLite, sektördeki değişimlere rağmen sürekli yeni kullanım alanları üreten sağlam bir veritabanı olmaya devam ediyor
  • Son dönemde LLM tabanlı kod üretim ajanları gibi alanlarda da gerçek zamanlı veri rollback'i ve branching önem kazandığından, Litestream'in gelişmiş nokta-zaman kurtarma özelliği önemli bir temel olabilir
  • İleride bu iyileştirilmiş mimari rollback, fork, otomasyon ajanlarına uyum gibi genişletilmiş yeteneklere de katkı sağlayacak
  • Yeni Litestream, önceki tasarıma göre daha üstün bir yapı sunuyor ve hem ölçeklenebilirliği hem kullanılabilirliği güçlendiriyor

İlgili okumalar

2 yorum

 
GN⁺ 2025-05-22
Hacker News yorumu

  • Kod deposunun yerini bulma deneyimini paylaşan bir yorum; 2 yıl önce litestream ve litefs kullanırken rahatsız edici noktalar olduğunu ama bu kez sorunların çoğunun çözülmüş göründüğünü söylüyor. Artık veritabanına litestream’i rahatça uygulayabildiğini ve birden fazla writer sorununa dair kaygısının azaldığını belirtiyor. Read replica FUSE katmanının avantajlarını beklediğini, ilgili pull request’te lease devralma yönteminin tanıtıldığını ekliyor (mevcut bir lease varsa yeni süreç 1 saniye aralıklarla yeniden deneyerek hızlı rolling restart desteği sağlıyor). Bunun pratik bir yaklaşım olduğunu düşünüyor.

  • Yeni Litestream’de uzun zamandır istediğim tüm özelliklerin hayata geçmiş gibi hissettirdiğini, bu yüzden heyecanlandığını söyleyen bir görüş.

  • Çok akıllıca ve dağıtımı basitleştiren bir yaklaşım olarak olumlu bakan bir yorum. Binlerce SQLite DB’sini yedeklemesi gereken bir durumda şimdiye kadar fanotify ve SQLite Backup API ile geçici bir çözüm yazdığını, wildcard replication çok sayıda dosyayı destekliyorsa Litestream’e geçmek istediğini söylüyor.

  • LTX geçişinden sonra tek bir dizinde yüzlerce hatta binlerce veritabanı olsa bile /data/*.db replikasyonunun mümkün hale geldiğini vurguluyor. Bunun daha önce kritik bir engel olduğunu, artık çok kiracılı ortamlarda her kullanıcıya ait veritabanı bazında istenen zamana geri yükleme, veri indirme ve taşımanın mümkün olacağı konusunda olumlu düşündüğünü belirtiyor.

  • Ben’e teşekkür ederek gerçek kullanım deneyimini paylaşıyor: yaklaşık 1 yıldan uzun süredir write-heavy bir iç kullanım senaryosunda (sıkıştırılmış haliyle yaklaşık 12GB) litestream’i production’da kullandığını ve aylık maliyetin son derece düşük olduğunu (Azure’da birkaç yüz won seviyesinde) anlatıyor. Yeni değişiklikleri uygulamayı dört gözle bekliyor.

  • Fly’ın SQLite tabanlı geliştirici deneyiminin biraz daha cilalanmasını istediğini söylüyor. Şu anki eksik yönün, yerleşik UI ve CLI’nın yetersiz olması nedeniyle ilk veritabanını Fly Machine’e kurmanın beklenenden daha çok adım gerektirmesi olduğunu belirtiyor. fly console’un SQLite ile düzgün çalışmadığını ve ayrı bir makinede çalıştığı için verinin bulunduğu volume’a erişemediğini, bu yüzden sonunda doğrudan fly ssh console —pty ile ilgili makineye girmek zorunda kaldığını eleştiriyor. SQLite tabanlı web uygulamalarının çoğunun küçük ölçekli olduğunu, gelir elde etmek için çok sayıda uygulama işletmek gerektiğini de ekliyor.

    • Rails 8 ve SQLite kombinasyonuna kişisel olarak nasıl baktığını soruyor; son dönemde Postgres’ten daha mı çok tercih ettiğini merak ediyor.

  • Litestream’i tam araştırdığı sırada bu yazıya denk geldiğini anlatıyor. VPS üzerinde Sqlite kullandığını ve Litestream kullanmayı düşündüğünü, Litestream süreci çalışırken veritabanını belirli bir ana geri yüklemenin mümkün olup olmadığını soruyor. Auto-checkpointing’in süreç çöktüğünde WAL’ı tüketmesi nedeniyle geri yüklenemeyen bir zaman aralığı oluşup oluşmadığını merak ediyor (örneğin arıza nedeniyle süreç 2:00–3:00 arasında durmuşsa, 1:55’e ya da 3:05’e geri dönmek mümkün olsa da 2:00–3:00 arası için geri yükleme bilgisinin kaybolup kaybolmadığını soruyor).

    • Litestream’in WAL segmentlerini belirli zaman noktalarına göre sakladığı, varsayılan olarak WAL değişikliklerini her saniye gönderdiği ve bu sayede ayarlanan saklama süresi içinde saniye düzeyinde point-in-time recovery yapılabildiği açıklanıyor.

    • DST (yaz saati uygulaması) işleme konusunda soru soruluyor; Avrupa’da 30 Mart’ta saatin 2:00’den 3:00’e atladığı bir durumda bunun nasıl çalıştığı merak ediliyor.

  • Geçmişte DynamoDB tabanlı DonutDB adlı bir sqlite vfs yaptığını anlatıyor. S3’e CAS (Content Addressable Storage) özelliği eklendiğini görünce DonutDB’yi S3 destekli sürümle yenilemeyi düşünmüş, ancak bu kez lightstream bunu desteklediği için kendisinin geliştirmek zorunda kalmayacak olmasına sevindiğini ve yeni aracı kullanmayı sabırsızlıkla beklediğini söylüyor.

    • S3’e CAS (Content Addressable Storage) eklendiği yönündeki ifadeyle ilgili resmi kaynak ya da referans bağlantısı istiyor; CAS anlamının gerçekten bu olup olmadığını doğrulamak istediğini belirtiyor.

  • Uygulama dağıtımında eski yöntemde yeni bir sunucu instance’ı ayağa kaldırıp health check geçince trafiği oraya yönlendirip eski sunucuyu kapattıklarını, ancak bu geçiş sırasında veritabanı değişikliklerinin kaybolması sorunu yaşadıklarını hatırlıyor. Bu değişiklikle sorunun çözülüp çözülmediğini soruyor.

    • Sunucuya tek kullanımlık bir web sunucusu instance’ı olarak değil, production veritabanı olarak bakmak gerektiği görüşü paylaşılıyor. Python/sqlite web uygulaması dağıtırken tüm makineyi değiştirmek yerine yalnızca paketi yükseltip systemd servisini yeniden başlattıklarını, downtime’ı azaltmak için SO_REUSEPORT gibi yöntemlerle geçiş sürecinin düşünülebileceğini söylüyor. Bu sırada eski ve yeni süreç veritabanını aynı anda kullanabilir, ancak DB şeması değişikliği varsa bir miktar downtime’ın kaçınılmaz olduğunu, bunun diğer veritabanları için de benzer olabileceğini düşünüyor.

    • Bunun kolay çözülen bir problem olmadığı söyleniyor; hâlâ lease’i yalnızca tek bir writer’ın alabileceği, yeni servis başlasa bile önceki writer kapanmadan lease’i elde edemeyeceği belirtiliyor. Writer değişimini kolaylaştıracak araçlar sağlansa da istek bekletme ya da kısa bir downtime kaçınılmaz diye açıklanıyor.

  • Litestream ile kullanıcı başına çok sayıda veritabanını çoğaltmak için (dokümanlarda ele alınan tipik use case), çalışma zamanında yeni veritabanlarını dinamik olarak eklemenin bir yolu olup olmadığını soruyor. Mevcut yapılandırma dosyasının statik olduğunu ve gerçek zamanlı bir API bulamadığını söylüyor.

    • Bunun sonunda çözüleceğinin beklendiği, yeni SQLite algılama mantığının zorlayıcı olsa da imkânsız olmadığı belirtiliyor. O zamana kadar da kütüphane biçiminde kolayca kullanılabileceği ifade ediliyor.