Restaurer un dump MySQL de plusieurs centaines de milliers de lignes peut s’avĂ©rer “casse gueule” si on ne prend pas un minimum de prĂ©cautions…
Personnellement, j’applique cette mĂ©thode quand j’ai plus de 300k ou 400k lignes Ă importer… Mais ça dĂ©pend aussi si le serveur est suffisamment fiable, la configuration MySQL, si c’est un serveur en prod (trafic, bande passante etc…).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# Si on a des choses à modifier Exemple, changer entry en entries /bin/sed 's/entry/entries/g' db.table.sql > db.table.formated.sql # Ici, on découpe notre fichier sql en partie de 50 000 lignes /usr/bin/split -l 50000 db.table.formated.sql sql_ # cela va générer autant de fichiers qu'il y a de blocs de 50000 lignes # sql_aa, sql_ab, sql_ac... sql_az, sql_ba, sql_bb... # On exécute le premier bloc : /usr/bin/mysql -u USER -pPASSWORD DATABASE < sql_aa 2> sql_aa.log # Un fois exécuté, on contrôle que toutes les données sont présentes avec un #select count(distinct `db`.`table`.`id`) AS `count` from `table` # On passe à sql_ab |
Bien entendu, il est possible d’automatiser le tout avec un log, mais je ne suis pas fan de cette mĂ©thode, disons que j’ai dĂ©jĂ eu de sĂ©rieuses surprises…
Mais voici tout de mĂŞme une piste :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
#!/bin/bash for i in `ls $1` do if [ -d "$i" ] then l $1/$i ; else echo $1/$i fi done exit 0 # Sortir un log sur un mysql /usr/bin/mysql <COMMAND> 2> file.log |