Litestream v0.5.0

 (fly.io)
1 Punkte von GN⁺ 2025-10-04 | 1 Kommentare | Auf WhatsApp teilen
  • Litestream v0.5.0 ist ein Update, das die Widerstandsfähigkeit von SQLite-basierten Anwendungen deutlich verbessert
  • Einführung des neuen LTX-Dateiformats, das effiziente Point-In-Time Recovery (PITR) und Datenkomprimierung unterstützt
  • Das Konzept von Generationen (generation) zwischen mehreren Litestream-Instanzen entfällt, was Verwaltung und Betrieb vereinfacht
  • Mit JetStream-Unterstützung und dem Wechsel zu einem modernen Go-SQLite-Treiber werden Entwicklung und Integration komfortabler
  • Künftig sind noch leistungsfähigere Funktionen wie VFS-basierte Read Replicas geplant

Überblick und wichtigste Updates

  • Litestream ist ein Backup- und Recovery-Tool für SQLite-Anwendungen, Open Source und mit dem Vorteil, praktisch überall lauffähig zu sein
  • Recovery nach Serverausfällen ist einfach, was mehr Sicherheit beim Aufbau kompletter Full-Stack-Anwendungen auf Basis von SQLite bietet
  • Die neueste Version (v0.5.0) bringt Geschwindigkeitsverbesserungen und Unterstützung für Point-In-Time Recovery (PITR)

Die Weiterentwicklung von LiteFS und Litestream

  • Die wichtigsten SQLite-bezogenen Projekte von Ben Johnson bei Fly.io sind Litestream und LiteFS
  • LiteFS zielt mit einem FUSE-Dateisystem auf Live-Replikation auf Ebene der internen Datenbanktransaktionen ab
  • Die Marktnachfrage konzentrierte sich jedoch auf das einfacher zu betreibende Litestream, weshalb technische Erkenntnisse aus LiteFS wieder in Litestream eingeflossen sind

Einführung des LTX-Dateiformats

  • Um die Grenzen und Ineffizienzen des bisherigen SQLite-seitenbasierten Backup-Verfahrens zu beseitigen, wurde LTX (ein transaktionsbasiertes Format) eingeführt

  • LTX bietet Verwaltung von Seitenbereichen entlang der Transaktionsreihenfolge sowie Compaction doppelter Seiten

    • Beispiel: Mehrere LTX-Dateien werden in umgekehrt chronologischer Reihenfolge angewendet; bei doppelten Seiten wird nur die neueste Version übernommen, sodass sich der endgültige Datenbankzustand schnell wiederherstellen lässt
    • Über eine Datei-Hierarchie werden LTX-Dateien in Intervallen von 30 Sekunden, 5 Minuten und 1 Stunde zusammengeführt, wodurch sich die für die Wiederherstellung benötigte Anzahl an Dateien drastisch reduziert

  • Die Geschwindigkeit der Datenwiederherstellung ist nur durch den I/O-Durchsatz begrenzt

Wegfall des Generationen-Konzepts

  • Litestream kann wie ein gewöhnlicher Unix-Prozess laufen und auch abstürzen; bei Betriebsunterbrechungen können Inkonsistenzen bei der Datensynchronisierung entstehen
  • Zuvor wurde zur Vermeidung von Konflikten zwischen mehreren Instanzen ein Verwaltungsansatz mit Generationen (generation) eingeführt,
  • mit dem Wechsel zu LTX ist jedoch Recovery auf Basis von Transaktions-IDs möglich geworden, sodass die komplexe Generationenverwaltung nicht mehr nötig ist

Upgrade auf Litestream v0.5.0

  • Da sich das Dateiformat grundlegend geändert hat, ist eine direkte Wiederherstellung aus WAL-Segmenten von v0.3.x nicht möglich
  • Das Upgrade ist einfach: neue Version starten → neue LTX-Dateien erzeugen; bestehende WAL-Dateien bleiben unverändert erhalten
  • Die Kompatibilität der Konfigurationsdatei bleibt ebenfalls gewahrt
  • Wichtige Änderung: Es ist nun nur noch ein einzelnes Replikationsziel pro Datenbank zulässig; dies wurde zugunsten einfacherer Entwicklung und zur Vermeidung von Replikationskonflikten entschieden
  • Die Befehle bleiben unverändert, aber die Referenzierung erfolgt nun auf Basis von Transaktions-IDs (TXID)

Weitere Verbesserungen

  • Durch seitenweise Komprimierung und das Hinzufügen eines Index in der LTX-Dateiformat-Bibliothek werden selektiver Seitenzugriff in großen Dateien und funktionale Erweiterungen möglich
  • Künftig lassen sich dadurch zusätzliche Funktionen wie Abfragen von Daten zu einem bestimmten Zeitpunkt umsetzen
  • Durch den Wegfall der CGO-Abhängigkeit und den Wechsel des Go-SQLite-Treibers zu modernc.org/sqlite ergeben sich Vorteile für automatische Builds und Cross-Compilation
  • Enthalten sind außerdem Unterstützung für den Replikat-Typ JetStream sowie aktualisierte Clients für S3/Google Storage/Azure Blob Storage und Unterstützung für die neue S3-API-Version

Ausblick

  • Die Entwicklung der Litestream-VFS-Funktion für Read-Replica-(Target-)Umgebungen läuft bereits
  • Damit soll es möglich werden, nur die jeweils benötigten Seiten direkt aus S3 zu lesen und so schnell Replikate zu erzeugen
  • Ein Prototyp existiert bereits und soll bald veröffentlicht werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-04
Hacker-News-Kommentare

  • Beim Deployment von SQLite-Apps auf Fly.io lässt die Developer Experience etwas zu wünschen übrig. Es wurde stundenlang versucht, eine produktive Rails-App zum Laufen zu bringen, dabei traten verschiedene Probleme mit Datenbankinitialisierung, Migrationen und Schreibbarkeit auf. Die Ursache war zwar letztlich das Eager Loading eines selbst erstellten Gems, aber mehrere darüberliegende Runner-Layer machten die Diagnose schwierig. Es wäre wünschenswert, wenn mehr in die DX investiert würde, allerdings ist das für Fly.io vermutlich keine Priorität, weil große Kunden solche Workloads nicht nutzen. Es wird gefragt, welche Hosts andere für SQLite-Apps in Produktion verwenden.

    • Letztes Jahr wurde auf Fly eine neue Rails-8-App eingerichtet. Als primärer Datenspeicher wird zwar PG verwendet, aber die ergänzenden solid-stack-Datenbanken laufen auf SQLite. Es gab einige kleinere Probleme auf Rails-Seite im Zusammenhang mit solid-queue-Migrationen, aber nichts, das an Fly lag. Es wird auch erwogen, die primäre PG-Datenbank auf SQLite umzustellen; derzeit wird SQLite in Teilen bereits gut genutzt.

    • Ich nutze SQLite in Produktion für eine Konsolen-App. Die DB liegt auf einem gemeinsam genutzten Dateilaufwerk.

  • Es ist sehr erfreulich, dass Fly nach zwei Jahren Entwicklungsstillstand die Arbeit an Litestream wieder aufgenommen hat. Litestream wird ständig verwendet und die Zufriedenheit ist sehr hoch. Die tatsächlichen Nutzungskosten liegen weit unter dem Werbespruch „ein paar Pennys pro Tag“: Bei einer echten Produktions-App mit Litestream-Replikation nach S3 lagen die monatlichen Kosten bei nur 2–3 Cent (0,02–0,03 Dollar). Dazu wurde ein Erfahrungsbericht geteilt.

  • Es ist spannend, dass Litestream bald alle S3-kompatiblen Ziele unterstützen soll. Bisher wird eine SFTP-Lösung genutzt, weil keine hartkodierten Cloud-Object-Storage-Dienste verwendet werden sollen. Den Entwicklern wird gedankt, zusammen mit einem PR-Link und einem Guide-Link.

  • Litestream soll bald ausprobiert werden. Gesucht werden Benchmarks oder Demos zur tatsächlichen Wiederherstellungszeit. Früher wurde ein S3-Backup selbst implementiert, und damals dauerte es mit Litestream ganze 20 Minuten, um 1.000 Zeilen wiederherzustellen. Das wirkte ziemlich unoptimiert. Es wird gefragt, wie stark sich die Restore-Geschwindigkeit inzwischen verbessert hat.

  • Es wird gefragt, welche Vorteile Litestream gegenüber sqlite.org/rsync hat.

    • Der Unterschied bei Litestream besteht darin, dass auf der Gegenseite kein „Server“ nötig ist, sondern nur Object Storage. Das kann kostenseitig günstiger sein.

    • Mit Litestream ist Point-in-Time-Recovery möglich. Es gibt also nicht nur Replikate des aktuellen Stands, sondern es kann auf Snapshots beliebiger Zeitpunkte zurückgesetzt werden.

  • Eine interessante Geschichte zu LiteFS und Litestream: „Die Marktreaktion ist die Antwort! Nutzer bevorzugen Litestream.“ Ehrlich gesagt ist Litestream einfacher zu betreiben und leichter zu verstehen, weshalb der Fokus wieder stärker darauf gelegt wurde.

    • Das erscheint auch mir plausibel. LiteFS erforderte das Ausführen und Mounten eines benutzerdefinierten, auf FUSE basierenden Dateisystems, während Litestream nur ein einzelnes Go-Binary braucht, das auf die SQLite-DB-Datei und die zugehörige WAL-Datei zeigt.

  • Es werden Links zu Litestream Revamped und zur Hacker-News-Diskussion geteilt
    Blog
    HN-Diskussion

  • Es werden interne Anwendungen auf entfernte externe Flotten ausgerollt, aber wegen instabiler Internetverbindungen ist es schwierig, ein funktionierendes Datenerfassungssystem aufzubauen. Es wird gefragt, wie Litestream in solch instabilen Umgebungen mit Backups umgeht und ob sich mehrere Backups zu einer zentralen DB zusammenführen und abfragen lassen.

  • Als kleine Warnung: Beim Umzug einer Legacy-Business-App nach Azure musste einmal eine Struktur betreut werden, in der zusammen mit der App ein lokaler MSSQL-Server lief, ähnlich dem Litestream-Muster. Die App war unter der Annahme eines lokalen Zugriffs (unter 1 ms Latenz) entwickelt worden und hatte überall gravierende N+1-Queries. Dadurch wurde ein Wechsel auf eine andere Architektur fast unmöglich. Wenn man Sorge hat, mit einer solchen Hosting-Form an Skalierungsgrenzen zu stoßen, wird sie nicht empfohlen. Andererseits kann man mit nur einer einzelnen Maschine schon sehr große Größenordnungen erreichen, sodass das in der Praxis vielleicht gar kein großes Problem ist.

    • Da einzelne Instanzen heute mehr als 20 TB RAM und Hunderte von Kernen unterstützen, halte ich diese Option für durchaus konkurrenzfähig. In Kombination mit einer Cell-Architektur pro Nutzer oder Tenant kann das noch effizienter sein.

    • Ich habe früher auch an einem Produkt gearbeitet, bei dem App-Server und Datenbank im selben Rack standen, also ebenfalls mit niedriger Latenz. Als das Produkt erfolgreich wurde und sich die N+1-Queries auf Tausende summierten, wurden aus 1 ms schnell mehr als 500 ms. Alle zwei Monate wurde in NewRelic nach langsamen Stellen gesucht und diese wurden behoben. Es war eine Rails-App, daher traten N+1-Probleme leicht auf, ließen sich aber auch relativ einfach korrigieren.

    • Schlechte Query-Praktiken verursachen früher oder später zwangsläufig Probleme. Das ist nicht unbedingt ein Nachteil dieses Ansatzes selbst.

    • Eigentlich ist der Trade-off auch nicht so groß, denn bei solchen Diensten wird letztlich nur sichtbar, wie problematisch der eigene Code ist. Das ist eher ein Code- als ein Serviceproblem.

    • Es wird gefragt, was N+1 ist.

  • Litestream wird sehr geschätzt: Es ist einfach zu verwenden und ist noch nie abgestürzt. Empfohlen wird der Einsatz als systemd-Unit-Service. Es wird nicht nur als Backup-Tool, sondern auch für Datenbank-Mirroring genutzt. Auch auf die kommende Read-Replica-Funktion wird sich gefreut.