Back to flin
flin

Durcissement de FlinDB pour la production

Comment la session 308 a durci FlinDB pour la production avec des sommes de contrôle CRC-32 du WAL, des points de contrôle automatiques, le verrouillage de fichiers multiplateforme, des fichiers de données par type d'entité, la déduplication de l'historique WAL et la persistance des schémas.

Thales & Claude | March 30, 2026 2 min flin
EN/ FR/ ES
flinflindbhardeningproductiondurability

Il y a un gouffre entre « la base de données fonctionne » et « la base de données est prête pour la production ». La session 308 a comblé ce gouffre. Six fonctionnalités de durcissement, chacune adressant un mode de défaillance spécifique en production.

Sommes de contrôle CRC-32 : détecter la corruption

Chaque entrée WAL est maintenant préfixée avec une somme de contrôle CRC-32 :

CRC:a1b2c3d4\t{"op":"Save","entity_type":"Todo","data":{...}}

Pendant le rejeu du WAL, chaque entrée est vérifiée. Les entrées corrompues sont ignorées avec un avertissement, pas une erreur fatale. La base de données récupère autant de données que possible.

Points de contrôle automatiques : limiter la croissance du WAL

Deux seuils configurables : 1 000 entrées ou 10 Mo (ce qui est atteint en premier déclenche le point de contrôle).

Verrouillage de fichiers : empêcher la corruption concurrente

Un DbLock acquiert un verrou exclusif sur .flindb/lock au démarrage. Si un serveur plante, le système d'exploitation libère automatiquement le verrou.

Fichiers de données par type d'entité

Tous les enregistrements d'un type d'entité sont consolidés dans un seul fichier .flindb :

.flindb/data/
+-- Todo.flindb            # All 847 Todo records
+-- User.flindb            # All 203 User records

Déduplication de l'historique WAL

Les entrées Save du WAL n'incluent plus le tableau d'historique complet. La croissance passe de quadratique à linéaire.

Persistance des schémas

schema.flindb persiste le schéma complet des entités à côté des données, rendant la base de données auto-descriptive.

Principes de conception

Configuration zéro. Chaque fonctionnalité de durcissement a des valeurs par défaut raisonnables.

Rétrocompatibilité. Le code durci lit les anciens formats et migre automatiquement.

Tolérance aux pannes. Les entrées WAL corrompues sont ignorées, pas fatales. La base de données récupère autant de données que possible.


Ceci est la partie 13 de la série « How We Built FlinDB ».

Navigation de la série : - [066] Database Encryption and Configuration - [067] Tree Traversal and Integration Testing - [068] FlinDB Hardening for Production (vous êtes ici) - [069] FlinDB vs SQLite: Why We Built Our Own - [070] Persistence in the Browser

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles