Je suis rassuré de savoir que mes données seront autant corrompus qu'en cas de crash serveur, ça donne pleinement confiance dans la solution.
Euh... Je ne sais pas si c'est ironique ou pas, mais dans le doute...
Si tu lance un backup sur ta base, il va définir une opération N comme étant la dernière de la sauvegarde. Quand tu fais une nouvelle opération pendant la sauvegarde, il va faire attention à ne pas écraser une opération p avec p < N et le supprimera plus tard (c'est conceptuel l'implémentation n'a probablement rien avoir avec ça). Tu te retrouve avec ta sauvegarde propre qui représente ta base avec les N première opération.
Si tu fais un snapshot du disque, il aura avant que tu ai lancé l'opération écris jusqu'à une opération u et potentiellement, il n'aura que partiellement écris l'opération p+1. Donc tu aura tes données de tes p première opération. L'opération p+1 tu l'aurais eu ou pas si tu avais lancé le backup quelques ms avant ou après donc OSEF.
Et comme tout les softs n'ont jamais de bugs [...]
On parle là de l'une des quelques fonctionnalités de base d'un SGBD, hein ? C'est plus important, plus souvent utilisé et plus testé que certaines formes de jointures. C'est surtout trivial à implémenter. Tu active (si ce n'est pas fait par défaut) le commilog de ta base. C'est un fichier ouvert en append only rollbacké qui décris chaque opération. Je ne sais pas si c'est toujours le cas, mais c'était à une époque utilisé à chaque démarrage du deamon (on démarre, on vérifie la cohérence grâce au commitlog et on repars).
Bref il faut pas croire que c'est une opération de panique grave, c'est juste le fonctionnement normal de ta base.
Si un SGBD ne fait pas ça correctement, il faut le fuir.
[...] et font toujours des mises à jour atomique de soft, on est aussi ok de ce coté la.
J'ai pas compris.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Snapshot comme backups ?
Posté par barmic . En réponse à la dépêche Unixcorn, trois mois plus tard : évolutions, remises en questions et stabilisation. Évalué à 3.
Euh... Je ne sais pas si c'est ironique ou pas, mais dans le doute...
Si tu lance un backup sur ta base, il va définir une opération N comme étant la dernière de la sauvegarde. Quand tu fais une nouvelle opération pendant la sauvegarde, il va faire attention à ne pas écraser une opération p avec p < N et le supprimera plus tard (c'est conceptuel l'implémentation n'a probablement rien avoir avec ça). Tu te retrouve avec ta sauvegarde propre qui représente ta base avec les N première opération.
Si tu fais un snapshot du disque, il aura avant que tu ai lancé l'opération écris jusqu'à une opération u et potentiellement, il n'aura que partiellement écris l'opération p+1. Donc tu aura tes données de tes p première opération. L'opération p+1 tu l'aurais eu ou pas si tu avais lancé le backup quelques ms avant ou après donc OSEF.
On parle là de l'une des quelques fonctionnalités de base d'un SGBD, hein ? C'est plus important, plus souvent utilisé et plus testé que certaines formes de jointures. C'est surtout trivial à implémenter. Tu active (si ce n'est pas fait par défaut) le commilog de ta base. C'est un fichier ouvert en append only rollbacké qui décris chaque opération. Je ne sais pas si c'est toujours le cas, mais c'était à une époque utilisé à chaque démarrage du deamon (on démarre, on vérifie la cohérence grâce au commitlog et on repars).
Bref il faut pas croire que c'est une opération de panique grave, c'est juste le fonctionnement normal de ta base.
Si un SGBD ne fait pas ça correctement, il faut le fuir.
J'ai pas compris.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)