Litestream v0.5.0

 (fly.io)
1 puan yazan GN⁺ 2025-10-04 | 1 yorum | WhatsApp'ta paylaş
  • Litestream v0.5.0, SQLite tabanlı uygulamaların dayanıklılığını büyük ölçüde artıran bir güncelleme
  • Yeni LTX dosya formatını sunarak verimli zaman noktası kurtarma (PITR) ve veri sıkıştırma özelliklerini destekliyor
  • Birden fazla Litestream örneği arasındaki generation kavramını kaldırarak yönetim ve işletimi sadeleştiriyor
  • JetStream desteği ve modern Go SQLite sürücüsüne geçiş gibi değişikliklerle geliştirme ve entegrasyon ortamı daha kullanışlı hale geliyor
  • Gelecekte VFS tabanlı read replica gibi daha güçlü özelliklerin eklenmesi planlanıyor

Genel bakış ve başlıca güncellemeler

  • Litestream, SQLite uygulamaları için bir yedekleme ve kurtarma aracı olup, açık kaynaklıdır ve her yerde çalışabilmesiyle öne çıkar
  • Sunucu arızası kurtarması kolaydır; bu da SQLite tabanlı full-stack uygulamalar kurarken güvenlik sağlar
  • En son sürüm (v0.5.0), hız iyileştirmeleri ve zaman noktası kurtarma (Point-In-Time Recovery, PITR) desteği sunar

LiteFS ve Litestream'in gelişim çizgisi

  • Fly.io'dan Ben Johnson'ın geliştirdiği başlıca SQLite projeleri Litestream ve LiteFS'dir
  • LiteFS, FUSE dosya sistemini kullanarak veritabanı içindeki transaction düzeyinde canlı replikasyonu hedefler
  • Ancak pazardaki talep, işletimi daha basit olan Litestream üzerinde yoğunlaştı; bu yüzden LiteFS'ten elde edilen teknik dersler yeniden Litestream'e uygulandı

LTX dosya formatının kullanıma alınması

  • Mevcut SQLite sayfa düzeyindeki yedekleme yaklaşımının sınırlarını ve verimsizliğini gidermek için LTX (transaction tabanlı format) kullanılmaya başlandı

  • LTX, transaction sırasına göre sayfa aralıklarını yönetme ve yinelenen sayfaları sıkıştırma (compaction) yetenekleri sunar

    • Örnek: Birden fazla LTX dosyası en yeniden en eskiye uygulanabilir; yinelenen sayfalarda yalnızca en güncel sürüm yansıtılarak son veritabanı durumu hızlıca geri yüklenebilir
    • Dosya hiyerarşisi sayesinde LTX dosyaları 30 saniye, 5 dakika ve 1 saatlik aralıklarla birleştirilerek kurtarma için gereken dosya sayısı büyük ölçüde azaltılır

  • Veri kurtarma hızı yalnızca I/O throughput ile sınırlıdır

Generation kavramının kaldırılması

  • Litestream, tipik bir Unix süreci gibi çalışabilir ve çökebilir; çalışma kesildiğinde veri senkronizasyonunda tutarsızlıklar oluşabilir
  • Daha önce birden fazla örnek arasındaki çakışmaları önlemek için generation adlı bir yönetim yaklaşımı kullanılıyordu
  • Ancak LTX'e geçişle birlikte transaction ID tabanlı kurtarma mümkün hale geldiği için, karmaşık generation yönetimine artık gerek kalmadı

Litestream v0.5.0 yükseltmesi

  • Dosya formatı kökten değiştiği için v0.3.x WAL segmentlerinden doğrudan kurtarma mümkün değil
  • Yükseltme basit şekilde yeni sürümü çalıştırma → yeni LTX dosyaları oluşturma akışıyla yapılıyor ve eski WAL dosyaları da aynen korunuyor
  • Yapılandırma dosyası uyumluluğu da korunuyor
  • Başlıca değişiklik: Artık veritabanı başına yalnızca tek bir replication target'a izin veriliyor; bu karar geliştirmeyi kolaylaştırmak ve replikasyon çakışmalarını önlemek için alındı
  • Komutlar eskisiyle aynı, ancak başvuru yöntemi transaction ID (TXID) tabanlı hale geldi

Diğer iyileştirmeler

  • LTX dosya formatı kütüphanesine eklenen sayfa düzeyinde sıkıştırma ve indeksleme, büyük dosyalarda seçici sayfa erişimini ve gelecekteki özellik genişlemelerini mümkün kılıyor
  • Gelecekte belirli bir andaki veriyi sorgulama gibi ek özelliklerin hayata geçirilmesi mümkün hale geliyor
  • CGO bağımlılığı kaldırıldı ve Go SQLite sürücüsü modernc.org/sqlite'a geçirilerek otomatik build ve cross-compilation ortamlarında avantaj sağlandı
  • JetStream destekli replica türü eklendi; ayrıca S3/Google Storage/Azure Blob Storage istemcileri güncellendi ve S3 API'nin yeni sürümü desteklenmeye başlandı

Gelecek planları

  • Read replica ortamları için Litestream VFS özelliği geliştiriliyor
  • Bu özellikle S3'ten yalnızca gerekli sayfalar anında okunarak hızlı replica oluşturma mümkün olacak
  • Bir prototip şimdiden mevcut ve yakında yayımlanması planlanıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-10-04
Hacker News görüşleri

  • Fly.io'da SQLite uygulaması dağıtırken geliştirici deneyimi biraz hayal kırıklığı yarattı; production Rails uygulamasını çalıştırmaya saatlerce uğraştım ama veritabanı başlatma, migration, yazılabilir durum gibi çeşitli sorunlarla karşılaştım. Sorunun kök nedeni kendi yazdığım gem'in eager loading davranışıydı ama üst üste binmiş runner katmanları yüzünden teşhis etmek zordu. DX iyileştirmelerine biraz daha ağırlık vermelerini isterdim ama büyük müşteriler bu tür iş yüklerini kullanmadığı için Fly.io açısından öncelik olmayabilir diye düşünüyorum. Production'da SQLite uygulaması dağıtanların hangi host'u kullandığını merak ediyorum.

    • Geçen yıl Fly'da yeni bir Rails 8 uygulaması kurdum; ana veri deposu olarak PG kullanıyorum ama yardımcı solid stack veritabanıları SQLite kullanıyor. solid queue migration'larıyla ilgili Rails tarafında ufak sorunlar vardı ama bu Fly kaynaklı değildi. Ana PG'yi SQLite'a taşımayı da değerlendiriyorum; şu anda bazı alanlarda SQLite'tan gayet iyi yararlanıyoruz.

    • Ben production ortamında konsol uygulaması için SQLite kullanıyorum. DB, paylaşımlı bir dosya sürücüsünde duruyor.

  • Fly'ın 2 yıllık geliştirme duraksamasının ardından Litestream geliştirmesine yeniden başlamasına çok sevindim. Litestream'i her seferinde kullanıyorum ve çok memnunum. “Günde birkaç penny” reklam söylemine kıyasla gerçek kullanım maliyeti çok daha düşük. Gerçek bir production uygulamasında S3'e Litestream replikasyonu kullandığımda aylık fiili maliyet 2-3 cent ($0.02~$0.03) seviyesindeydi. İlgili deneyim yazısı

  • Litestream'in yakında tüm s3-uyumlu hedefleri destekleyecek olması ilginç. Şu ana kadar SFTP çözümü kullanıyordum çünkü hardcode edilmiş bulut nesne depolama hizmetlerini kullanmak istemiyorum. Geliştiricilere teşekkürler. PR bağlantısı ve rehber bağlantısı

  • Litestream'i yakında denemek istiyorum. Gerçek geri yükleme süresine dair benchmark veya demo olup olmadığını merak ediyorum. Eskiden S3 yedeklerini kendim uygulamıştım; o dönemde Litestream ile 1.000 satırı geri yüklemek 20 dakika sürüyordu. Oldukça optimize edilmemiş görünüyordu. Bugünlerde geri yükleme hızının ne kadar iyileştiğini merak ediyorum.

  • Litestream'in sqlite.org/rsync karşısındaki avantajı nedir diye merak ediyorum.

    • Litestream'in farkı, diğer uçta bir “sunucu” gerekmemesi; yalnızca nesne depolama yeterli. Bu da maliyet açısından daha ucuz olabilir.

    • Litestream ile Point In Time Recovery mümkün. Yalnızca mevcut zamanın bir replikası değil, istenen herhangi bir zaman noktasındaki snapshot'tan geri yükleme yapılabiliyor.

  • LiteFS ve Litestream hakkında ilginç bir nokta: “Piyasa tepkisi her şeyi açıklıyor! Kullanıcılar Litestream'i daha çok tercih ediyor.” Dürüst olmak gerekirse Litestream'i işletmek ve anlamak daha kolay olduğu için yeniden buna odaklanıldı.

    • Bana da mantıklı geliyor. LiteFS için FUSE tabanlı özel bir dosya sistemini çalıştırıp mount etmek gerekiyordu, oysa Litestream'de SQLite DB dosyasını ve ilgili WAL dosyasını işaret eden tek bir Go binary'si yeterli.

  • Litestream Revamped ile ilgili bağlantılar ve Hacker News tartışması paylaşılıyor
    Blog
    HN tartışması

  • Şirket içinde bir uygulamayı dışarıdaki uzak bir filoya dağıtıyoruz ve internet bağlantısı istikrarsız olduğu için düzgün bir veri toplama sistemi kurmak zor. Litestream'in böyle dengesiz ortamlarda yedekleri nasıl ele aldığını ve birden çok yedeğin merkezi bir DB'de birleştirilip sorgulanıp sorgulanamayacağını merak ediyorum.

  • Küçük bir uyarı: Bir keresinde legacy bir iş uygulamasını Azure'a taşırken, uygulamayla birlikte yerel MSSQL sunucusunun çalıştığı bir yapıyla uğraştım; bu biraz Litestream desenine benziyordu. Uygulama yerel erişim (1 ms altı gecikme) varsayımıyla geliştirildiği için her yerde ciddi N+1 query sorunları vardı. Bu da başka bir mimariye geçişi neredeyse imkansız hale getirdi. Eğer bu tür bir hosting kullanıp sonra ölçek sınırına çarpmaktan endişe ediyorsanız, bunu önermem. Yine de tek bir makineyle bile oldukça büyük ölçeklere çıkılabildiği için pratikte büyük sorun olmayabilir.

    • Günümüzde tek bir instance 20 TB'ın üzerinde RAM ve yüzlerce çekirdeği destekleyebildiğinden, bunun gayet rekabetçi bir seçenek olduğunu düşünüyorum. Kullanıcı/tenant başına cell mimarisiyle birleştirildiğinde daha da verimli olabilir.

    • Ben de eskiden uygulama sunucusu ile veritabanının aynı rack'te olduğu bir ürün üzerinde çalışmıştım; benzer şekilde düşük gecikmeli bir yapıydı. Ürün başarılı olup N+1 query sayısı binlere çıktığında, 1 ms bir anda 500 ms ve üstüne dönüşebiliyordu. Her iki ayda bir NewRelic'te yavaş noktaları bulup düzeltme döngüsü yaşanıyordu. Rails uygulaması olduğu için N+1 sorunları kolayca ortaya çıkıyor ama nispeten kolay da düzeltilebiliyordu.

    • Kötü query alışkanlıkları er ya da geç mutlaka sorun çıkarır. Bunu bu yaklaşımın doğrudan bir dezavantajı olarak görmek zor.

    • Aslında sonunda böyle servisler kullandığınızda sadece kodunuzun ne kadar sorunlu olduğu ortaya çıkıyor; bu yüzden bunun büyük bir trade-off olduğunu düşünmüyorum. Sorun serviste değil, koddadır.

    • N+1'in ne olduğu soruluyor.

  • Litestream'i gerçekten seviyorum; kullanımı kolay ve şimdiye kadar hiç çökmedi. systemd unit service olarak kullanmanızı tavsiye ederim. Yalnızca bir yedekleme aracı olarak değil, veritabanı mirroring için de kullanıyorum. Gelecekte gelecek read-replica özelliğini de heyecanla bekliyorum.