Litestream permet désormais une restauration ponctuelle rapide

 (fly.io)
6 points par GN⁺ 2025-05-22 | 2 commentaires | Partager sur WhatsApp
  • Litestream sauvegarde en toute sécurité des applications full stack basées sur SQLite vers du stockage objet, et bénéficie cette fois de sa plus grande évolution fonctionnelle
  • Grâce à un format de fichier LTX plus efficace et à une technique de compaction plus performante que l’architecture précédente, la restauration ponctuelle devient rapide et efficace
  • Une nouvelle approche reposant sur les conditional writes simplifie l’implémentation d’un singleton lecteur et des fonctionnalités de read replica
  • Une couche de read-replica basée sur VFS sera bientôt disponible, ce qui facilitera l’extension dans divers environnements
  • L’architecture a été largement améliorée pour permettre la synchronisation simultanée de nombreux jeux de données, avec une meilleure scalabilité

Présentation de Litestream et son importance

  • Litestream est un outil open source qui permet de sauvegarder en toute sécurité vers du stockage objet diverses applications full stack reposant sur SQLite
  • Il résout le problème d’une dépendance des données à un seul serveur, liée à la nature embarquée de SQLite, et facilite la récupération des données même en cas de panne du serveur

L’évolution de Litestream

  • Litestream est apparu en 2020 pour rendre SQLite plus simple à exploiter
  • Litestream s’exécute comme un processus séparé de l’application SQLite et remplace le processus de checkpoint WAL pour diffuser en temps réel les changements de données vers un stockage objet comme S3
  • Même si le serveur est perdu, il est possible de restaurer efficacement la base de données à son état le plus récent depuis le stockage objet
  • Par la suite, le projet LiteFS a été développé pour ajouter la prise en charge des read replicas et d’un basculement primaire de base (Primary Failover), permettant d’utiliser SQLite avec une architecture de déploiement moderne comparable à celle de Postgres
  • LiteFS et Litestream ont chacun leurs avantages, mais Litestream est plus largement utilisé car il est plus simple à déployer et à exploiter

Restauration ponctuelle efficace (Point-in-time Restore)

  • L’ancienne conception de Litestream enregistrait continuellement toutes les modifications et les envoyait vers S3, mais cette approche devenait inefficace lors de la restauration si les données changeaient fréquemment
  • LiteFS a introduit une approche sensible aux transactions, avec le format de fichier LTX qui enregistre les plages de pages modifiées après les avoir triées
  • Plusieurs fichiers LTX peuvent être facilement fusionnés (compaction) pour ne conserver que les versions les plus récentes, ce qui améliore fortement la vitesse et l’efficacité de la restauration
  • Cette structure ressemble à un arbre LSM
  • Le nouveau Litestream adopte lui aussi les fichiers LTX et la compaction, ce qui permet une restauration ponctuelle précise sans stocker un grand volume de doublons

CASAAS : Compare-and-Swap as a Service

  • Litestream doit pouvoir fonctionner sans que l’application SQLite ait conscience du système de sauvegarde, mais si le processus s’arrête à cause d’une panne, certaines modifications de données risquent de ne pas être prises en compte
  • Pour résoudre ce problème, le concept de generation a été introduit afin d’identifier de manière unique chaque session de sauvegarde et son flux de journaux associé
  • LiteFS garantissait un lecteur unique à l’aide de Consul, mais comme cela ajoutait une dépendance externe, Litestream met en œuvre un chemin de réplication unique (singleton) de façon simple grâce à la fonctionnalité de conditional write du stockage objet comme S3
  • Cela permet un fonctionnement stable et sans ambiguïté, même dans des environnements de nœuds éphémères

Fonctionnalité légère de read replica

  • LiteFS utilise le système de fichiers FUSE pour être sensible aux transactions, mais cela introduit de la complexité et un coût d’adoption plus élevé
  • Pour alléger cela, le module d’extension LiteVFS, basé sur le SQLite Virtual Filesystem (VFS), a été conçu pour fonctionner dans divers environnements sans FUSE
  • À terme, Litestream adoptera lui aussi cette même couche basée sur VFS afin de fournir une couche de read replica capable de récupérer et de mettre en cache directement des pages depuis un stockage objet comme S3
  • Ce ne sera pas aussi rapide qu’un SQLite local, mais grâce à des stratégies de cache et de prefetching, on peut s’attendre à des performances satisfaisantes dans de nombreux cas d’usage

Open source et utilité pratique

  • Litestream est entièrement open source et peut être utilisé partout, sans dépendre de Fly.io
  • Une fonctionnalité a été ajoutée pour synchroniser un grand nombre de bases de données dans un seul processus, ce qui permet de sauvegarder ou de répliquer efficacement des centaines à des milliers de bases

Une croissance continue aux côtés de SQLite

  • SQLite est une base de données robuste qui continue de créer de nouveaux cas d’usage malgré l’évolution du secteur
  • Même dans des domaines récents comme les agents de génération de code basés sur les LLM, où le rollback et le branching des données en temps réel deviennent importants, les capacités améliorées de restauration ponctuelle de Litestream peuvent constituer une brique essentielle
  • À l’avenir, cette architecture améliorée pourra aussi contribuer à des fonctions étendues comme le rollback, le fork et la prise en charge des agents automatisés
  • Le nouveau Litestream surpasse la conception existante et renforce à la fois la scalabilité et la facilité d’utilisation

À lire aussi

2 commentaires

 
GN⁺ 2025-05-22
Avis Hacker News

  • Partage d’expérience sur la découverte de l’emplacement du dépôt de code : il y a deux ans, l’usage de litestream et litefs présentait des inconvénients, mais cette fois la plupart des problèmes semblent avoir été résolus ; il estime pouvoir désormais appliquer litestream librement à sa base de données et se soucie moins des problèmes liés à plusieurs writers ; il attend beaucoup des avantages de la couche FUSE de read replica ; il présente dans la pull request associée le mode d’acquisition du lease (si un lease existe déjà, un nouveau processus réessaie toutes les secondes, ce qui permet des rolling restarts rapides) ; il trouve l’approche pragmatique

  • Impression que toutes les fonctionnalités qu’il attendait du nouveau Litestream ont été implémentées, avec un sentiment d’attente et d’enthousiasme

  • Regard positif sur une approche très intelligente qui simplifie le déploiement ; dans une situation nécessitant la sauvegarde de milliers de bases SQLite, il avait jusqu’ici bricolé une solution provisoire avec fanotify et la Backup API de SQLite ; il espère passer à Litestream si la wildcard replication peut prendre en charge un grand nombre de fichiers

  • Mise en avant du fait qu’après la transition vers LTX, il devient possible de répliquer /data/*.db même s’il y a des centaines ou des milliers de bases dans un seul répertoire ; c’était auparavant un obstacle bloquant ; perspective positive sur le fait que, dans un environnement multi-tenant, il devient désormais possible d’effectuer une restauration à un instant donné, ainsi que le téléchargement et la migration des données, base par base pour chaque utilisateur

  • Remerciements à ben accompagnés d’un retour d’expérience en production : utilisation de litestream depuis plus d’un an sur un cas interne à forte charge en écriture (environ 12 Go une fois compressé), avec un coût mensuel extrêmement faible (quelques centaines de wons sur Azure), et impatience d’appliquer ces nouveaux changements

  • Souhait que l’expérience développeur SQLite de Fly soit un peu plus polie ; point faible actuel : le manque d’une UI et d’une CLI adaptées, ce qui rend la mise en place de la base initiale sur une Fly Machine plus laborieuse que prévu ; fly console ne s’intègre pas correctement à SQLite, s’exécute sur une machine séparée et ne peut pas accéder au volume contenant les données ; au final, il faut entrer directement dans la machine concernée avec fly ssh console —pty, ce qu’il juge peu pratique ; il souligne aussi que les web apps basées sur SQLite sont le plus souvent de petite taille, donc qu’il faut en exploiter un grand nombre pour en tirer des revenus

    • Question sur son orientation personnelle concernant la combinaison Rails 8 + SQLite : le préfère-t-il désormais à Postgres ?

  • Partage d’une expérience personnelle : il était justement en train d’étudier Litestream lorsqu’il est tombé sur l’article au bon moment ; il utilise Sqlite sur un VPS et envisage d’adopter Litestream ; il demande s’il est possible de restaurer la base à un instant précis pendant que le processus Litestream tourne ; il s’interroge sur une éventuelle fenêtre de non-récupérabilité due au fait que l’auto-checkpointing consomme le WAL lorsque le processus est arrêté (exemple : panne avec arrêt du processus entre 2:00 et 3:00 ; restauration possible à 1:55 ou 3:05, mais disparition des informations de restauration entre 2:00 et 3:00)

    • Explication : Litestream stocke les segments WAL par unités de temps précises et, par défaut, envoie les changements du WAL chaque seconde, ce qui permet une restauration à la seconde près pour n’importe quel instant souhaité dans la période de rétention configurée

    • Question sur la gestion de la DST (heure d’été) : curiosité sur le comportement lors du passage de 2:00 à 3:00 le 30 mars en Europe

  • Partage d’une ancienne expérience de création d’une sqlite vfs appelée DonutDB basée sur dynamodb ; avec l’ajout d’une fonctionnalité CAS (Content Addressable Storage) à S3, il comptait renouveler DonutDB en version compatible S3, mais se réjouit de voir que lightstream le prend désormais en charge, ce qui lui évite de le développer lui-même ; il est impatient d’utiliser ce nouvel outil

    • À propos de la mention de l’ajout de CAS (Content Addressable Storage) à S3, demande de documentation officielle ou de lien de référence ; il veut confirmer que le terme CAS est bien utilisé dans ce sens

  • Souvenir d’un problème lors des déploiements d’application : avec l’ancienne méthode, on lançait une nouvelle instance serveur, on basculait le trafic une fois les health checks validés, puis on arrêtait l’ancien serveur ; pendant cette transition, des pertes de modifications de la base de données pouvaient survenir ; il demande si ce problème est résolu avec ce changement

    • Avis selon lequel il faut considérer le serveur non comme une instance web éphémère mais du point de vue d’une base de données de production ; lors du déploiement d’une web app python/sqlite, il préfère mettre à niveau les packages et redémarrer le service systemd plutôt que remplacer toute la machine ; pour réduire le downtime, on peut réfléchir à une transition avec SO_REUSEPORT, et dans ce cas l’ancien et le nouveau processus peuvent utiliser la base simultanément ; mais s’il y a un changement de schéma, un certain downtime reste inévitable ; selon lui, c’est probablement vrai pour d’autres bases aussi

    • Position selon laquelle le problème ne se résout pas facilement : un seul writer peut toujours détenir le lease ; même si le nouveau service démarre, il ne peut obtenir le lease qu’une fois l’ancien writer arrêté ; des outils sont fournis pour faciliter le remplacement du writer, mais il faut tout de même accepter une mise en attente des requêtes ou un court downtime

  • Question sur la manière d’ajouter dynamiquement de nouvelles bases à l’exécution pour répliquer un très grand nombre de bases par utilisateur avec litestream (cas d’usage représentatif présenté dans la documentation) ; retour d’expérience indiquant que le fichier de configuration est statique et qu’il n’a pas trouvé d’API temps réel

    • Réponse indiquant que ce problème finira probablement par être résolu ; la logique de détection des nouvelles bases SQLite est délicate, mais pas impossible ; d’ici là, il est indiqué que l’outil peut être utilisé facilement sous forme de bibliothèque