Le job du FS est de conserver sa cohérence. Dans le cas de ton application qui meurt inopinément, en effet ton appli doit gérer la cohérence à son niveau.
Dans ton cas d'une appli qui écrit un simple fichier, une manière de faire est la suivante:
Créer un fichier temporaire et écrire dedans.
Appeler fsync() sur le fichier temporaire.
Renommer le fichier temporaire vers le fichier final.
Avec cette méthode, tu ne retrouves pas avec un fichier final à moitié écrit, seul le fichier temporaire peut se retrouver dans cet état. Le fichier final est soit la version précédente (avant le renommage) soit la version après le renommage.
C'est beaucoup plus compliqué avec des bases de données. Une bonne partie de la complexité des gestionnaires de base de données vient de là, comment pouvoir repartir correctement après une coupure de courant.
Il y a plusieurs manières d'écrire sur le disque dans MySQL, plus ou moins sûres et moins ou plus performantes, par exemple innodb_flush_log_at_trx_commit
Il y a des commandes SQL pour rendre ça moins douloureux, mais ça doit pouvoir marcher sans.
En théorie si système de snapshot est cohérent, tu dois pouvoir restaurer ta base de données dans un état cohérent avec un snapshot fait sans précaution particulière, mais tu peux perdre quelques transactions si tu utilises innodb_flush_log_at_trx_commit différent de 1. C'est en gros équivalent à une perte de courant sur ton serveur, qui est cas que ton SGBD doit pouvoir redémarrer depuis.
En pratique il y a des cas où ça ne marche pas en fonction des limitations du SGBD. Par exemple avec MySQL avant la version 8, si tu fais un DDL (modification de la définition d'une table) et que MySQL crashe ou que ton serveur crashe, tu as de fortes chances de ne pas pouvoir relancer la base de donnée.
Pour éviter de perdre certaines transaction et éviter de tomber dans les cas d'où le SGBD ne sait pas redémarrer, il faut flusher les tables sur le disque d'abord avec une requête du type:
FLUSH TABLES WITH READ LOCK Si ton système de snapshot n'est pas cohérent (par exemple tu fais un tar ou un rsync), là il faut flusher les tables et mettre un lock en écriture le temps de toute la procédure.
[^] # Re: Bétail vs animal de compagnie (pets vs cattle)
Posté par paulez (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.
Le job du FS est de conserver sa cohérence. Dans le cas de ton application qui meurt inopinément, en effet ton appli doit gérer la cohérence à son niveau.
Dans ton cas d'une appli qui écrit un simple fichier, une manière de faire est la suivante:
Avec cette méthode, tu ne retrouves pas avec un fichier final à moitié écrit, seul le fichier temporaire peut se retrouver dans cet état. Le fichier final est soit la version précédente (avant le renommage) soit la version après le renommage.
C'est beaucoup plus compliqué avec des bases de données. Une bonne partie de la complexité des gestionnaires de base de données vient de là, comment pouvoir repartir correctement après une coupure de courant.
Il y a plusieurs manières d'écrire sur le disque dans MySQL, plus ou moins sûres et moins ou plus performantes, par exemple innodb_flush_log_at_trx_commit
Il y a des commandes SQL pour rendre ça moins douloureux, mais ça doit pouvoir marcher sans.
En théorie si système de snapshot est cohérent, tu dois pouvoir restaurer ta base de données dans un état cohérent avec un snapshot fait sans précaution particulière, mais tu peux perdre quelques transactions si tu utilises innodb_flush_log_at_trx_commit différent de 1. C'est en gros équivalent à une perte de courant sur ton serveur, qui est cas que ton SGBD doit pouvoir redémarrer depuis.
En pratique il y a des cas où ça ne marche pas en fonction des limitations du SGBD. Par exemple avec MySQL avant la version 8, si tu fais un DDL (modification de la définition d'une table) et que MySQL crashe ou que ton serveur crashe, tu as de fortes chances de ne pas pouvoir relancer la base de donnée.
Pour éviter de perdre certaines transaction et éviter de tomber dans les cas d'où le SGBD ne sait pas redémarrer, il faut flusher les tables sur le disque d'abord avec une requête du type:
FLUSH TABLES WITH READ LOCK