Comment gérer les énormes longueurs de lignes créées par mysqldump ?

Question

J'utilise mysqldump dans une tâche cron pour sauvegarder une base de données de plus de 2 millions de lignes.

Il crée un fichier texte qui peut être utilisé pour restaurer l'enregistrement de données à partir de la ligne de commande.

J'ai pensé qu'il serait utile d'éditer le dump avant une restauration en tant que rapide pour modifier les valeurs et les noms de tables ou de colonnes - du moins jusqu'à ce que j'en sache plus et que je sois sûr de pouvoir le faire avec ALTER et UPDATE.

L'édition de gros fichiers texte ne me dérange pas, mais j'ai été surpris de constater que dans une 250 mégaoctets de ma base de données, il n'y avait qu'environ 300 lignes . Chaque ligne comportait quelque chose comme 800 000 caractères.

Existe-t-il un autre moyen de générer des vidages avec un meilleur contrôle de la longueur des lignes ?

Ou devrais-je post-traiter le dump avec des outils comme sed ou Perl ?

Answer 1

Par défaut, mysqldump ne génère qu'un seul INSERT commande par table Le résultat est une (très longue) ligne de données insérées pour chaque table qui a été vidée. Ceci est essentiellement dû au fait que les insertions "par lots" sont beaucoup plus rapides que si elles généraient un fichier INSERT pour chaque enregistrement de chaque table.

Donc, ce n'est pas que mysqldump a créé des lignes arbitrairement longues, et vous pouvez simplement imposer une autre longueur de coupure. Les lignes sont longues pour une raison.

Si c'est vraiment important d'obtenir le INSERT est réparti sur plusieurs lignes, vous pouvez l'indiquer avec :

mysqldump --extended-insert=FALSE --complete-insert=TRUE ...

Notez cependant que la restauration des tables prendra plus de temps dans ce format.

Answer 2

Je parcourais le code source de MySQL à la recherche d'une solution à ce problème aujourd'hui. La longueur maximale des lignes est imposée par la variable opt_net_buffer_length qui est censée correspondre à la taille du tampon du serveur MySQL. Elle est comiquement grande.

Mais de toute façon, c'est une option, alors faites ça :

mysqldump --net_buffer_length=5000 ...

La valeur minimale est de 4096.

Answer 3

Je suis tombé sur une réponse sur les forums MySQL, qui montre de manière concluante que l'ajout de ' \n après chaque groupe INSERT n'est pas possible en utilisant mysqldump seul, sans modifier la source :

Le format étendu ne peut pas être analysé correctement à 100 % sur la base de la virgule. ou des parenthèses, il faudrait compter les champs. La meilleure solution est de corriger mysqldump à faire un saut de ligne sur la sortie.

Changement très mineur : À la ligne 3506, vous pouvez voir où la virgule de fin de ligne est sortie :
fputc(',',md_result_file); /* Always row break */

Il suffit d'insérer cette ligne immédiatement après la ligne 3506 :
fputc('\n',md_result_file); /* Lon Binder says wrap that line! */

recompilation et terminé.

@see http://forums.mysql.com/read.php?28,420002,426110#msg-426110

Merci Lon B !

(J'ai inclus le contenu du forum MySQL, au cas où le forum disparaîtrait).

Answer 4

L'utilisation d'une regex pour diviser les lignes n'est pas suffisante, vous avez besoin d'un analyseur syntaxique qui comprendra correctement les guillemets et les caractères d'échappement.

J'ai juste écrit un parseur puisque je n'en ai pas trouvé : http://blog.lavoie.sl/2014/06/split-mysqldump-extended-inserts.html

Answer 5

Post-traiter le fichier de vidage avec python . Vous serez peut-être plus heureux que perl ou sed.

Si vous êtes sous Linux, vous l'avez déjà installé. Si vous êtes sous Windows, le programme d'installation est facile à utiliser.

Mais avant cela, apprenez à utiliser SQL UPDATE et SQL ALTER. Vous serez plus heureux en faisant les choses de la bonne manière.