Discussion :

[willo35]

Bonjour a tous,

J'ai régulèrement a descendre des backup d'une instance de prod vers une instance de test ou de dev.

J'utilise pour le moment des backpus effectué avec mysqldump.
Sur une des bases, cela génère un fichier de 650 Mo et je met presque 4H pour le restaurer.

est ce que la durée du restore vous semble normal ?

Si c'est le cas, est ce qu'il existe d'autre méthodes pour permettre un backup/Restore plus rapide ?

Merci par avance de votre aide. Je peux vous fournir des renseignement complémentaire en cas de besoin.

Willo.

[ShaiLeTroll]

Bonjour,

Je trouve cela un peu lent
J'ai pour ma part intégrer un chargement de Backup capable de lire les Dump de MySQL Administrator ainsi que le BackUp de MyDAC (Devart\CoreLab)
A l'époque on utilisait le Composant CoreLab pour restaurer mais celui-ci chargeait tout en mémoire ... ce qui ne fonctionnait pas avec les Grosses DB
Donc j'ai refait le lecture du Dump manuellement (ce n'est pas dur, j'ai juste géré les ; et les " et \ pour gérer les ; dans une chaine pour isoler les requêtes ...)

Mon programme ne mets deux grosses heures à restaurer 2Go !
le Parsing n'est pas optimiser !

Il faut voir si tu as les options pour désactiver les index durant les INSERT, les index pouvant être calculés qu'une fois tout inséré, cela va nettement plus vite

Je précise que la méthode de sauvegarde, crée un fichier par table, c'est moins lourd à recharger ...

Mais cela fonctionne aussi avec un fichier unique pour la base, j'en ai qui dépasse 1Go, MySQL Administrator doit les restaurer en 35-45 minutes

Tout dépend le type de table, un table avec de grand champ blob est plus rapide a restaurer qu'une table avec bcp de petite ligne

Pour MySQLDump, je ne l'utilise pas, on a eu des soucis sous Windows, il semble qu'il bouffe la mémoire (même soucis qu'avec MyBackup), on peut penser que c'est ton problème !

Sous Linux, MySQLDump doit mettre 30-40 minutes pour un fichier de 650Mo