Dans le cadre du passage en production d’une application basée sur Simplicité, nous nous posons des questions concernant la garantie de cohérence d’une sauvegarde d’une instance Simplicité avec des documents stockés sur un filesystem.
J’ai trouvé cet article dans lequel vous recommandez en toute logique de synchroniser le backup de la BDD et du filesystem.
Mais sans mécanisme de type “shadow copy” pour garantir la cohérence, il peut y avoir des transactions pendant les 2 backups (du filesystem et de la BDD), et donc des incohérences entre les 2 types de stockage.
Y a-t-il une procédure pour éviter cela, ou limiter les conséquences de cela pour Simplicité ?
Je sais que généralement, les éditeurs des solutions de Remote Blob Storage préconisent de sauvegarder d’abord la BDD, puis le filesystem. Car ces solutions sont généralement conçues pour ne faire que des ajouts de BLOBs, ou des suppressions avec délai, jamais de modifications. De cette façon, on est sûr d’avoir toutes les données (et au pire, des documents orphelins à purger côté filesystem).
Est-ce que Simplicité fonctionne également de cette façon ?
La meilleure stratégie possible pour garantir à 100% la cohérence entre la base et les docs sur le file system est de suspendre l’instance Simplicité le temps de la sauvegarde, mais s’il y a des accès très fréquents et en 24/7 et que cette sauvegarde dure longtemps ce n’est pas forcément une bonne solution.
Est-ce que vous avez une contrainte forte qui justifie d’utiliser un stockage sur filesystem plutôt qu’un stockage en BLOB dans la base avec lequel cette question de cohérence base-filesystem ne se poserait pas ?
Si vous stockez vos docs sur le filesystem pour de bonnes raisons il n’y a pas de conter indication à gérer du “shadowing/mirroring” de ce file system et de la base de données de manière à faire la sauvegarde de l’ensemble sur ces replicas temporairement suspendus le temps de la sauvegarde. Ce genre de choses ne se met pas en place au niveau de Simplicité mais de l’infrastructure sous-jacente, il n’y rien de spécifique à Simplicité ici (et c’est totalement transparent pour lui). Malheureusement nous n’avons pas les compétences pour vous aider sur la mise en place ce genre de choses.
La raison d’utiliser le stockage sur filesystem est la volumétrie de documents attendue, qui est estimée à 200-300 Go par an. Avec un stockage uniquement en BDD, cela risque de nous amener des problématiques de volumétrie assez rapidement.
Merci pour ce retour. Je sais bien que l’infrastructure sous-jacente n’est pas de votre ressort, pas de souci.
Le but de ma question était de savoir si Simplicité se comportait comme les solutions RBS que je décris dans mon message pour la gestion des fichiers (auquel cas, il suffisait de démarrer le backup du filesystem juste après celui de la BDD sans se poser plus de questions).
OK pour la volumétrie, clairement il faut mettre les fichier sur file system dans ce cas.
Pour le reste ça dépend du métier que vous implémentez => si vous ne faites que créer des documents mais que vous ne les modifiez pas ensuite vous pouvez sauvegarder le filesystem après la base (au pire vous aurez qques fichiers en “trop”)