Litestream v0.5.0

• Litestream v0.5.0 est une mise à jour qui améliore fortement la résilience des applications basées sur SQLite
• Introduction du nouveau format de fichier LTX, avec prise en charge de la restauration à un instant donné (PITR) et de la compression des données
• Suppression de la notion de génération (generation) entre plusieurs instances Litestream, ce qui simplifie l’administration et l’exploitation
• Avec la prise en charge de JetStream et la migration vers un pilote Go SQLite moderne, le développement et l’intégration deviennent plus pratiques
• À l’avenir, des fonctionnalités encore plus puissantes sont prévues, comme des réplicas en lecture basés sur VFS

---

Vue d’ensemble et principales mises à jour

• Litestream est un outil de sauvegarde et de restauration pour les applications SQLite, open source et conçu pour pouvoir s’exécuter partout
• La reprise après panne serveur est simple, ce qui renforce la fiabilité pour construire des applications full stack sur SQLite
• La dernière version (v0.5.0) apporte des gains de performances et la prise en charge de la restauration à un instant donné (Point-In-Time Recovery, PITR)

L’évolution de LiteFS et Litestream

• Les principaux projets liés à SQLite développés par Ben Johnson chez Fly.io sont Litestream et LiteFS
• LiteFS vise une réplication en direct au niveau des transactions internes de la base de données à l’aide d’un système de fichiers FUSE
• Mais la demande du marché s’est davantage concentrée sur Litestream, plus simple à exploiter, ce qui a conduit à réappliquer à Litestream les enseignements techniques tirés de LiteFS

Introduction du format de fichier LTX

• Pour éliminer les limites et l’inefficacité de l’ancienne méthode de sauvegarde SQLite page par page, Litestream introduit LTX (un format basé sur les transactions)

• LTX offre la gestion des plages de pages selon l’ordre des transactions ainsi que la compaction des pages dupliquées

  • Exemple : en appliquant plusieurs fichiers LTX du plus récent au plus ancien, seules les versions les plus récentes des pages dupliquées sont conservées, ce qui permet de restaurer rapidement l’état final de la base de données
  • Grâce à une hiérarchie de fichiers, les fichiers LTX sont fusionnés par tranches de 30 secondes, 5 minutes et 1 heure, ce qui réduit fortement le nombre de fichiers nécessaires à la restauration

• La vitesse de récupération des données n’est limitée que par le débit d’E/S

Suppression de la notion de génération

• Litestream peut s’exécuter et tomber en panne comme un processus Unix classique, et un arrêt en cours de fonctionnement peut provoquer des incohérences de synchronisation des données
• Auparavant, un mécanisme de gestion appelé génération (generation) avait été introduit pour éviter les conflits entre plusieurs instances
• Mais avec le passage à LTX, la restauration basée sur les identifiants de transaction devient possible, ce qui rend la gestion complexe des générations inutile

Mise à niveau vers Litestream v0.5.0

• Le format de fichier ayant changé en profondeur, une restauration directe depuis les segments WAL de la v0.3.x n’est pas possible
• La mise à niveau est simple : exécuter la nouvelle version → générer de nouveaux fichiers LTX, tandis que les anciens fichiers WAL sont conservés tels quels
• La compatibilité du fichier de configuration est également maintenue
• Changement majeur : une seule cible de réplication est désormais autorisée par base de données, un choix fait pour faciliter le développement et éviter les conflits de réplication
• Les commandes restent les mêmes, mais les références reposent désormais sur les identifiants de transaction (TXID)

Autres améliorations

• La compression page par page et l’ajout d’un index dans la bibliothèque du format de fichier LTX permettent un accès sélectif aux pages dans de gros fichiers et ouvrent la voie à des extensions fonctionnelles
• Cela rend possibles à l’avenir des fonctionnalités supplémentaires comme les requêtes de données à un instant précis
• La suppression de la dépendance à CGO et la migration du pilote Go SQLite vers modernc.org/sqlite apportent des avantages pour les builds automatiques et les environnements de cross-compilation
• Sont également inclus la prise en charge du type de réplica JetStream, la mise à jour des clients S3/Google Storage/Azure Blob Storage, ainsi que la prise en charge de la nouvelle version de l’API S3

Feuille de route

• Le développement de la fonctionnalité Litestream VFS pour les environnements de cible en lecture est en cours
• Cette fonctionnalité doit permettre de lire immédiatement depuis S3 uniquement les pages nécessaires afin de créer rapidement un réplica
• Un prototype existe déjà et sa publication approche

[GN⁺]

Avis Hacker News

• L’expérience développeur laisse un peu à désirer lors du déploiement d’apps SQLite sur Fly.io. Quelqu’un a essayé pendant plusieurs heures de faire tourner une app Rails en production, mais s’est heurté à divers problèmes autour de l’initialisation de la base de données, des migrations, de l’état inscriptible, etc. La cause profonde venait du eager loading dans un gem qu’il avait lui-même créé, mais la présence de plusieurs couches de runners par-dessus a rendu le diagnostic difficile. Il aimerait que Fly.io investisse davantage dans l’amélioration de la DX, mais pense que ce n’est probablement pas prioritaire pour eux puisque leurs gros clients n’utilisent pas ce type de workload. Il se demande quels hébergeurs utilisent les personnes qui ont déjà déployé des apps SQLite en production.

  • Quelqu’un a configuré l’an dernier une nouvelle app Rails 8 sur Fly. Le stockage principal des données utilise PG, mais les bases auxiliaires de la solid stack utilisent SQLite. Il y a eu quelques petits soucis côté Rails liés aux migrations de solid queue, mais ce n’était pas un problème de Fly. Il envisage aussi de migrer la base PG principale vers SQLite, et utilise déjà SQLite avec succès dans certains cas.

  • Quelqu’un utilise SQLite en production pour une application console. La base de données se trouve sur un lecteur de fichiers partagé.

• Heureux de voir Fly reprendre le développement de Litestream après deux ans d’interruption. Quelqu’un l’utilise systématiquement et en est très satisfait. Le coût réel à l’usage est bien plus bas que le slogan marketing « quelques centimes par jour ». Dans une app de production réelle avec réplication Litestream vers S3, le coût mensuel effectif n’était que de 2 à 3 centimes de dollar (0,02 à 0,03 $). Partage de ce retour d’expérience connexe.

• Quelqu’un trouve impressionnant que Litestream doive bientôt prendre en charge toutes les destinations compatibles s3. Jusqu’à présent, il utilise une solution SFTP parce qu’il préfère éviter les services de stockage d’objets cloud codés en dur. Il remercie les développeurs et partage un lien vers la PR ainsi qu’un lien vers le guide.

• Quelqu’un aimerait bientôt essayer Litestream et se demande s’il existe des benchmarks ou des démos sur le temps réel de restauration. Par le passé, il avait implémenté lui-même des sauvegardes S3, et à l’époque il fallait 20 minutes à Litestream pour restaurer 1 000 lignes. Cela semblait assez peu optimisé. Il se demande à quel point la vitesse de restauration s’est améliorée aujourd’hui.

• Quelqu’un se demande quels avantages Litestream a par rapport à sqlite.org/rsync.

  • Le point distinctif de Litestream est qu’il n’y a pas besoin d’un « serveur » à l’autre extrémité : un simple stockage d’objets suffit. Cela peut être moins coûteux.

  • Litestream permet la restauration à un instant donné (Point In Time Recovery). On n’a pas seulement une réplique de l’état actuel, on peut restaurer depuis un snapshot de n’importe quel moment.

• À propos de LiteFS et Litestream, quelqu’un partage une remarque intéressante : « La réponse du marché fait foi ! Les utilisateurs préfèrent Litestream. » Honnêtement, Litestream est plus simple à exploiter et plus facile à comprendre, ce qui explique le recentrage sur ce produit.

  • Cela semble logique aussi pour quelqu’un d’autre. LiteFS exigeait d’exécuter et de monter un système de fichiers personnalisé basé sur FUSE, tandis que Litestream se contente d’un unique binaire Go pointant vers le fichier de base SQLite et le fichier WAL associé.

• Partage d’un lien sur Litestream Revamped et du fil de discussion Hacker News associé
  Blog
  Fil HN

• Quelqu’un explique que son équipe déploie des applications internes sur une flotte distante externe, avec une connexion Internet instable, ce qui complique la mise en place correcte d’un système de collecte de données. Il se demande comment Litestream gère les sauvegardes dans ce type d’environnement instable, et s’il est possible de consolider plusieurs sauvegardes dans une base centrale afin de les interroger.

• Petit avertissement : lors d’une migration d’une application métier legacy vers Azure, quelqu’un a dû gérer une architecture où un serveur MSSQL local tournait avec l’application, un peu à la manière du modèle Litestream. L’application avait été développée en supposant un accès local avec une latence inférieure à 1 ms, ce qui avait entraîné de graves problèmes de requêtes N+1 partout. Cela a presque rendu toute transition vers une autre architecture impossible. Si vous craignez d’atteindre une limite de montée en charge avec ce type d’hébergement, cette personne ne le recommande pas. Cela dit, une seule machine peut déjà aller assez loin en capacité, donc en pratique ce n’est peut-être pas un vrai problème.

  • Avec des instances uniques qui prennent désormais en charge plus de 20 To de RAM et plusieurs centaines de cœurs, quelqu’un estime que cette option reste tout à fait compétitive. Combinée à une architecture en cellules par utilisateur/tenant, cela pourrait même être plus efficace.

  • Quelqu’un d’autre a travaillé autrefois sur un produit où le serveur applicatif et la base de données étaient dans le même rack, avec une architecture tout aussi basse latence. Le produit a eu du succès et, à mesure que les requêtes N+1 se sont multipliées par milliers, 1 ms finissait vite par se transformer en plus de 500 ms. Tous les deux mois, il fallait repartir à la chasse aux points lents dans NewRelic. C’était une app Rails, donc les problèmes de N+1 apparaissaient facilement, même s’ils étaient relativement simples à corriger.

  • De mauvaises pratiques de requêtes finissent toujours par poser problème un jour ou l’autre. Il est difficile d’y voir un défaut propre à cette approche.

  • En réalité, quelqu’un estime que le principal effet de ce type de service est simplement de révéler à quel point votre code a des problèmes, ce qui n’est pas un énorme compromis : c’est la faute du code, pas du service.

  • Quelqu’un demande ce que signifie N+1.

• Quelqu’un adore vraiment Litestream : c’est simple à utiliser et cela n’a jamais planté. Il recommande de l’exécuter comme service unit systemd. Il ne s’en sert pas seulement comme outil de sauvegarde, mais aussi pour le mirroring de base de données, et attend avec impatience la future fonctionnalité de read-replica.