Le 5 mars 2019 à 16:16, Sébastien Le Ray sebastien-frsag@orniz.org a écrit :
salut,
Je comprends pas très bien, quelle est la différence entre le snapshot à chaud et une coupure de courant par exemple ? C'est pas censé respecter les propriétés ACID un SGBD ?
De mon point de vue, ça peut être ACID au niveau du service applicatif mais pas forcément consistent au niveau stockage en cas d’incident. Le snapshot au niveau du stockage est intéressant pour de petites bases, que ne sont pas forcément réparties, au niveau FS, serveurs de stockage, etc.
PostgreSQL par exemple te dit que le snapshot c’est ok si ton WAL est activé, car il servira à rejouer les transaction qui n’ont pas forcément été écrites durablement.
Mais si ton WAL est activé, autant streamer ton WAL sur un stockage externe, pour faire de la sauvegarde continue et de la restauration PITR et c’est 100%pévu pour.
Les snapshots, ça présente toujours un risque, sans doute petit, mais si tu y mets tes sauvegardes, c’est dommage.
À+
Le 05/03/2019 à 14:55, David Durieux a écrit :
Ca dépend,
je lock les écritures, fait un snapshot ZFS (très rapide) puis je release le lock d'écriture.
Certes, ça lock pendant quelques secondes, mais ça fonctionne pas si mal que ça.
Après sur le slave ça reste une valeur sûre (il faut bien entendu une supervision de la synchro de tes serveurs de base de données).
Cordialement, David Durieux
On Tue, 5 Mar 2019 14:37:22 +0100 Wallace wallace@morkitu.org wrote:
Le 05/03/2019 à 13:22, HURTEVENT VINCENT a écrit :
+1000, le snapshot d’un volume pour un SGBD(R) me fait toujours un peu peur, mais ça dépend du soft.
Plus que de faire peur c'est clairement connu comme une source de problèmes.
Tu peux le faire que sur un slave sorti de la synchro le temps de faire son snapshot et uniquement dans ce cas ou alors c'est une micro base qui fait très peu de requêtes et la personne qui gère s'en fou si ça plante.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/