Modification de max_allowed_packet et toujours la réception de l'erreur «Packet Too Large»

8

J'utilise mysqldump pour créer un fichier plat à des fins de sauvegarde. J'ai utilisé ce fichier pour recréer la base de données sur un autre serveur. J'ai exécuté le processus d'importation via ssh sur la ligne de commande et j'ai reçu plusieurs Packet too Largeerreurs.

J'ai redémarré mysql avec un max_allowed_packet beaucoup plus grand (c'est-à-dire 1000M) et j'ai toujours reçu l'erreur. J'ai même tenté de définir le max_allowed_packet dans le fichier d'importation, j'ai quand même reçu l'erreur.

Existe-t-il un moyen de s'assurer que max_allowed_packet est défini et / ou d'utiliser mysqldump qui créera un fichier qui ne provoque pas ce problème?

Pour référence:

le fichier mysqldump non compressé fait ~ 2 Go

le type de base de données est INNODB

— Patrick
source

5

La première à laquelle j'ai pensé était ce que max_allowed_packet contrôle réellement. Voici ce que j'ai trouvé:

Selon la page 99 de "Understanding MySQL Internals" (ISBN 0-596-00957-7) , voici les paragraphes 1-3 qui l'expliquent:

Le code de communication réseau MySQL a été écrit en supposant que les requêtes sont toujours raisonnablement courtes, et peuvent donc être envoyées et traitées par le serveur en un seul morceau, qui est appelé un paquet dans la terminologie MySQL. Le serveur alloue la mémoire à un tampon temporaire pour stocker le paquet, et il en demande suffisamment pour l'adapter entièrement. Cette architecture nécessite une précaution pour éviter que le serveur manque de mémoire --- un plafond sur la taille du paquet, ce que cette option accomplit.

Le code d'intérêt par rapport à cette option se trouve dans sql / net_serv.cc . Jetez un œil à my_net_read () , puis suivez l'appel à my_real_read () et portez une attention particulière à net_realloc () .

Cette variable limite également la longueur d'un résultat de nombreux fonctons de chaîne. Voir sql / field.cc et sql / intem_strfunc.cc pour plus de détails.

Étant donné cette définition de max_allowed_packet, j'ai ensuite découvert autre chose à partir de ServerFault: innodb_log_file_size et innodb_log_buffer_size combinés doivent être plus grands que dix fois votre plus grand objet blob si vous en avez beaucoup de gros.

Gardant ces deux choses à l'esprit, j'augmenterais innodb_log_file_size dans /etc/my.cnf à la taille maximale autorisée pour cela, 2047M. Cela nécessite bien sûr les éléments suivants

service mysql stop
rm -f /var/lib/mysql/ib_logfile*
service mysql start

Cela s'adaptera à tous les gros blobs que vous pourriez avoir dans vos données.

— RolandoMySQLDBA
source

Curieux de savoir d'où vient ce 10x - est-ce juste une règle de base ou y a-t-il du code dans MySQL qui dit alloue 10 tampons fixes, vous avez donc besoin de 10 pour vous assurer que l'un d'eux est assez grand?

— Gaius

Ce livre fait-il autorité?

— Pacerier

2

MySQL max_allowed_packetdoit toujours être dans les limites du shell qui l'a lancé - ulimit -amontre- t -il que data seg sizec'est illimité?

— Gaius
source

2

Pour une raison quelconque, max_allowed_packetest ignoré par mysqldump- par conception ? Le complément réel est net_buffer_length. Alors essayez plutôt

mysqldump --net_buffer_length=100k -u root -p databasename > dump.sql

— Leopd
source

C'est très instructif !!! Étant donné que le rapport de bogue traite de l'insertion étendue en conjonction avec ce problème, peut-être que faire --skip-extended-insert peut compenser certains mais générera sûrement un plus grand mysqldump. +1 pour Vous trouvant ce diamant à l'état brut qu'Oracle laissera pour mort !!!

— RolandoMySQLDBA

--skip-extended-insert fonctionne certainement, mais sur ma base de données, la restauration a été ralentie de 100 fois, ce qui la rend inutilisable.

— Leopd

Je suis désolé, mes condoléances. Peut-être que mysqldump crée des fichiers CSV et essaie de les recharger en utilisant LOAD DATA INFILE et en augmentant bulk_insert_buffer_size à 1G ou 2G. Hé, on ne sait jamais !!!

— RolandoMySQLDBA