Re: backup

Je te donnes des pistes: - snapshot pas instantané - cache lvm, cache OS, cache hardware - locks pas fait de façon atomique (cf plus haut) - y a des UNDO et REDO chez mysql maintenant ? - ... - snapshot = temps de création du logical volume à l'intérieur du volume group = une seconde - LVM est intégré au noyau et fait un flush du filesystem (y compris le journal ext3) juste avant la création du logical volume => aucun problème de cohérence - cache hardware : rien à voir, car LVM travaille au niveau noyau et opère en mode copy-on-write, c'est-à-dire que tout bloc modifié après la création du snapshot est recopié dans sa version originale avant d'être écrit sur le disque. D'autre part, je te signale que dans le cas d'un SGBD il vaut mieux utiliser du hard qui obéit aux requêtes de synchronisation, donc probablement du SCSI. Sinon ton système n'est plus ACID. - UNDO et REDO : je ne vois pas le rapport, on parle de backups là. Si tu veux restaurer un backup sous MySQL, c'est tout simple, tu arrêtes le serveur, tu remets les fichiers à leur place et hop. c'est quand même d'avoir après la restauration des données coherentes Cohérentes vis-à-vis de quoi. Je te répondrais bien de RTFM, mais répétons encore un coup : - FLUSH TABLES WITH READ LOCK assure la cohérence des données au niveau SGBD. Cela garantit que la représentation des tables sur le filesystem est stable et cohérente (y compris au sens ACID du terme si tu utilises InnoDB (lis la news...)). - la prise du snapshot sous LVM assure de plus la cohérence des données au niveau filesystem. En effet LVM est intégré au noyau et a donc une connaissance totale des blocs flushés ou non. Il installe donc une barrière à un certain moment, flushe tout ce qui n'a pas été flushé et bloque toute modif arrivante, crée le logical volume, puis redonne la main. - par la suite, la permanence du snapshot est assurée par un mécanisme de copy-on-write, toujours grâce au fait que LVM est intégré directement au noyau. - le backup est fait à partir du snapshot, qui est stable et permanent (cf. ci-dessus). Une fois le backup fini, tu détruis le snapshot histoire de ne pas subir la perte (très minime) de performances. Donc la cohérence est garantie (sauf bug bien sûr ;-)) sur toute la chaîne. pourquoi oracle, postgresql ou mysql n'abordent pas (toujours) les snapshots (lvm, netapp...) dans leur doc, et developpe tous des outils plus ou moins compliqués ? Parce que les snapshots ne sont pas une fonctionnalité de base des filesystems (je ne pense pas qu'il y en ait sous Windows, sous linux les distribs n'utilisent pas LVM par défaut, etc.). Et aussi parce qu'une des caractéristiques de beaucoup de bases de données (surtout commerciales) est d'intégrer le plus d'outils pour créer de la valeur ajoutée (tm ;-)) ou faire plaisir à l'utilisateur (tout est out-of-the-box).