Litestream ermöglicht jetzt schnelle Point-in-Time-Wiederherstellung

• Litestream sichert Full-Stack-Anwendungen auf Basis von SQLite zuverlässig in Objektspeicher und erhält dabei nun seine bislang größte Funktionsänderung
• Durch ein effizienteres LTX-Dateiformat und Compaction wird eine schnelle und effiziente Point-in-Time-Wiederherstellung möglich
• Mit einem neuen Ansatz auf Basis von Conditional Write werden Leader-Singleton- und Read-Replica-Funktionen einfacher umgesetzt
• Bald wird eine VFS-basierte Read-Replica-Schicht bereitstehen, die sich in verschiedensten Umgebungen leicht skalieren lässt
• Dank der deutlich verbesserten Architektur können viele Datenbanken gleichzeitig synchronisiert werden, was die Skalierbarkeit erhöht

---

Einführung in Litestream und warum es wichtig ist

• Litestream ist ein Open-Source-Tool, das verschiedene Full-Stack-Anwendungen auf Basis von SQLite sicher in Objektspeicher sichert
• Es löst das Problem, dass Daten aufgrund der eingebetteten Natur von SQLite an einen einzelnen Server gebunden sind, und erleichtert die Datenwiederherstellung auch bei Serverausfällen

Die Entwicklung von Litestream

• Litestream erschien 2020, um die Nutzung von SQLite einfacher zu machen
• Litestream läuft als separater Prozess neben der SQLite-Anwendung und ersetzt den WAL-Checkpointing-Prozess, indem es Datenänderungen in Echtzeit in Objektspeicher wie S3 streamt
• Selbst wenn ein Server verloren geht, kann die Datenbank effizient aus dem Objektspeicher auf den neuesten Stand wiederhergestellt werden
• Später wurde zusätzlich das Projekt LiteFS entwickelt, das auch Read Replicas und grundlegendes Failover für die Primärinstanz unterstützt und damit SQLite in moderneren Deployment-Strukturen ähnlich wie Postgres nutzbar macht
• Sowohl LiteFS als auch Litestream haben ihre Vorteile, Litestream ist jedoch weiter verbreitet, weil Deployment und Nutzung einfacher sind

Effiziente Point-in-Time-Wiederherstellung

• Das frühere Design von Litestream protokollierte fortlaufend alle Änderungen und übertrug sie nach S3, was bei häufigen Datenänderungen bei der Wiederherstellung ineffizient war
• LiteFS führte einen transaktionsbewussten Ansatz ein und verwendet das LTX-Dateiformat, das Bereiche geänderter Seiten sortiert aufzeichnet
• Mehrere LTX-Dateien lassen sich leicht zusammenführen (Compaction), sodass nur die neuesten Versionen erhalten bleiben, was Geschwindigkeit und Effizienz der Datenwiederherstellung deutlich verbessert
• Diese Struktur ähnelt einem LSM-Tree
• Auch das neue Litestream übernimmt LTX-Dateien und Compaction und ermöglicht damit eine präzise Point-in-Time-Wiederherstellung ohne viel redundante Speicherung

CASAAS: Compare-and-Swap as a Service

• Litestream muss funktionieren, ohne dass SQLite-Anwendungen das Backup-System kennen, doch wenn Prozesse etwa durch Ausfälle beendet werden, können Datenänderungen verloren gehen
• Um dieses Problem zu lösen, wurde das Konzept der Generation eingeführt, das jede Backup-Sitzung und ihren Log-Stream eindeutig identifiziert
• LiteFS garantierte mit Consul einen einzelnen Leader, Litestream setzt jedoch wegen der unerwünschten externen Abhängigkeit stattdessen auf die Conditional-Write-Funktion von Objektspeichern wie S3, um einen einzelnen Replikationspfad (Singleton) einfach umzusetzen
• Dadurch ist auch in Umgebungen mit ephemeren Knoten ein stabiler und eindeutiger Betrieb möglich

Leichtgewichtige Read-Replica-Funktion

• LiteFS nutzt für Transaktionsbewusstsein ein FUSE-Dateisystem, was jedoch Komplexität und Einführungsaufwand mit sich bringt
• Um das zu entschärfen, wurde mit LiteVFS ein Erweiterungsmodul für das SQLite Virtual Filesystem (VFS) entworfen, das auch ohne FUSE in verschiedensten Umgebungen funktionieren kann
• Künftig soll auch Litestream dieselbe VFS-basierte Schicht erhalten und eine Read-Replica-Ebene bereitstellen, die Seiten direkt aus Objektspeichern wie S3 lädt und zwischenspeichert
• Sie wird zwar nicht so schnell sein wie lokales SQLite, dürfte aber durch Caching- und Prefetching-Strategien in vielen Anwendungsfällen zufriedenstellende Leistung bieten

Open Source und praktische Nutzbarkeit

• Litestream ist vollständig Open Source, nicht an Fly.io gebunden und überall einsetzbar
• Es wurde die Fähigkeit ergänzt, große Mengen von Datenbanken in einem einzigen Prozess zu synchronisieren, sodass auch Hunderte bis Tausende Datenbanken effizient gesichert oder repliziert werden können

Gemeinsames weiteres Wachstum mit SQLite

• SQLite ist eine robuste Datenbank, die auch im Wandel der Branche kontinuierlich neue Einsatzmöglichkeiten hervorbringt
• Auch in Bereichen wie LLM-basierte Code-Generierungsagenten wird die weiterentwickelte Point-in-Time-Wiederherstellung von Litestream zu einer wichtigen Grundlage, da dort Echtzeit-Rollbacks und Verzweigungen an Bedeutung gewinnen
• Diese verbesserte Architektur wird künftig auch zu erweiterten Funktionen wie Rollback, Forks und der Unterstützung automatisierter Agenten beitragen
• Das neue Litestream ist dem bisherigen Design überlegen und stärkt sowohl Skalierbarkeit als auch Benutzerfreundlichkeit

[xguru]

Litestream – ein Tool für Streaming-Replikation von SQLite
Ich setze serverseitig ganz auf SQLite

[GN⁺]

Hacker-News-Kommentare

• Jemand berichtet von seiner Erfahrung bei der Suche nach dem Ort des Code-Repositorys. Vor zwei Jahren habe es mit litestream und litefs noch Unannehmlichkeiten gegeben, diesmal wirke es aber so, als seien die meisten Probleme gelöst. Man könne litestream jetzt problemlos auf Datenbanken anwenden und müsse sich weniger Sorgen um Probleme mit mehreren Writern machen. Außerdem freue man sich auf die Vorteile der Read-Replica-FUSE-Schicht. Im zugehörigen Pull Request werde das Lease-Übernahmeverfahren vorgestellt: Falls bereits ein Lease existiert, versucht ein neuer Prozess es im Abstand von 1 Sekunde erneut, was schnelle Rolling Restarts unterstützt. Das wirke wie ein pragmatischer Ansatz.

• Es wirke so, als ob im neuen Litestream alles umgesetzt worden sei, was man sich gewünscht habe; die Stimmung sei erwartungsvoll und begeistert.

• Positive Sicht auf einen sehr cleveren Ansatz, der Deployments vereinfacht. In einer Situation, in der Backups für Tausende von SQLite-DBs nötig waren, habe man bisher mit fanotify und der Backup-API von SQLite einen Behelf gebaut. Falls Wildcard-Replikation viele Dateien unterstützt, würde man gern zu Litestream wechseln.

• Seit der Umstellung auf LTX sei nun auch die Replikation von /data/*.db möglich, selbst wenn in einem Verzeichnis Hunderte oder Tausende von Datenbanken liegen. Genau das sei zuvor ein entscheidendes Hindernis gewesen. Nun eröffne sich die positive Perspektive, in Multi-Tenant-Umgebungen für jede Nutzerin und jeden Nutzer Datenbanken mit gewünschter Point-in-Time-Recovery sowie Daten-Download und Migration anbieten zu können.

• Mit einem Dank an ben wird praktische Nutzungserfahrung geteilt: Seit über einem Jahr werde litestream in Produktion für einen write-heavy internen Use Case genutzt (komprimiert etwa 12 GB), und die monatlichen Kosten lägen nur bei einem sehr kleinen Betrag (bei Azure nur ein paar hundert Won). Man freue sich darauf, die neuen Änderungen anzuwenden.

• Der Wunsch, dass die SQLite-basierte Developer Experience bei Fly noch etwas ausgereifter wird. Als aktueller Schwachpunkt werden fehlende eigene UI und CLI genannt, wodurch das Einrichten der initialen Datenbank auf einer Fly Machine mehr Arbeit als gedacht sei. fly console arbeite nicht sauber mit SQLite zusammen und laufe auf einer separaten Machine, sodass kein Zugriff auf das Volume mit den Daten möglich sei. Am Ende müsse man mit fly ssh console —pty direkt auf die betreffende Machine gehen, was umständlich sei. SQLite-basierte Web-Apps seien meist klein, daher müsse man viele davon betreiben, um damit Umsatz zu machen.

  • Frage nach der persönlichen Entscheidung in Richtung Rails 8 und SQLite, insbesondere ob man das in letzter Zeit mehr als Postgres bevorzuge.

• Jemand hatte sich gerade erst mit Litestream beschäftigt und ist dann passend auf diesen Beitrag gestoßen. Auf einem VPS werde Sqlite genutzt und die Einführung von Litestream erwogen. Es wird gefragt, ob sich die Datenbank auf einen bestimmten Zeitpunkt zurücksetzen lässt, während der Litestream-Prozess läuft. Wegen des Auto-Checkpointing, das bei einem Prozessausfall das WAL verarbeitet, stellt sich die Frage nach einem nicht wiederherstellbaren Zeitfenster — etwa wenn der Prozess wegen eines Ausfalls von 2:00 bis 3:00 stoppt, eine Wiederherstellung auf 1:55 oder 3:05 aber möglich ist, die Informationen für 2:00 bis 3:00 jedoch verloren wären.

  • Erklärung: Litestream speichert WAL-Segmente in bestimmten Zeitintervallen und sendet WAL-Änderungen standardmäßig jede Sekunde, sodass innerhalb der konfigurierten Aufbewahrungsdauer eine Point-in-Time-Recovery auf Sekundenbasis möglich ist.

  • Frage zur Behandlung von DST (Sommerzeit): Wie verhält sich das System in Europa am 30. März, wenn die Uhr von 2:00 auf 3:00 springt?

• Jemand berichtet von einer früheren Erfahrung mit einer auf DynamoDB basierenden SQLite-VFS namens DonutDB. Als S3 Unterstützung für CAS (Content Addressable Storage) hinzugefügt habe, habe man DonutDB als S3-Version neu auflegen wollen. Nun freue man sich, dass lightstream dies unterstützt und man es nicht selbst entwickeln muss. Die Vorfreude auf das neue Tool ist groß.

  • Auf die Erwähnung, dass S3 CAS (Content Addressable Storage) hinzugefügt habe, wird um offizielle Unterlagen oder einen Referenzlink gebeten; außerdem möchte man bestätigen, ob mit CAS wirklich das Gemeinte gemeint ist.

• Bei App-Deployments habe man früher eine neue Serverinstanz gestartet, nach bestandenen Health Checks den Traffic umgeschaltet und dann den alten Server beendet. Dabei seien während des Umschaltens Datenbankänderungen verloren gegangen. Es wird gefragt, ob dieses Problem durch die aktuellen Änderungen gelöst sei.

  • Die Ansicht, dass man den Server nicht als kurzlebige Web-Server-Instanz, sondern aus Sicht einer Produktionsdatenbank betrachten sollte. Beim Deployment einer Python/SQLite-Web-App werde nicht die ganze Machine ersetzt, sondern nur Pakete aktualisiert und der systemd-Service neu gestartet. Um Downtime zu verringern, könne man den Übergang mit SO_REUSEPORT o. Ä. gestalten. Dabei könnten alter und neuer Prozess zwar gleichzeitig auf die Datenbank zugreifen, aber wenn Schemaänderungen enthalten sind, sei eine gewisse Downtime unvermeidlich. Das könne bei anderen Datenbanken genauso sein.

  • Die Position, dass sich das Problem nicht einfach lösen lässt. Es könne weiterhin nur ein Writer das Lease halten. Auch wenn der neue Service startet, bekommt er das Lease erst, wenn der vorherige Writer beendet ist. Es gebe zwar Werkzeuge für den Writer-Wechsel, aber wartende Requests oder eine kurze Downtime seien kaum zu vermeiden.

• Frage, wie man mit litestream für zahlreiche nutzerbezogene Datenbanken Replikation einrichten kann — also für den in der Dokumentation beschriebenen typischen Use Case —, wenn zur Laufzeit neue Datenbanken dynamisch hinzugefügt werden sollen. Es wird berichtet, dass die Konfigurationsdatei derzeit statisch sei und keine Live-API gefunden wurde.

  • Einschätzung, dass dieses Problem letztlich gelöst werden dürfte. Die neue Logik zur Erkennung von SQLite-Datenbanken sei zwar knifflig, aber nicht unmöglich. Bis dahin könne man es immerhin leicht als Bibliothek verwenden.