erreur mysqldump 2013

18

J'ai une base de données installée, que je voudrais sauvegarder dans mysql. Le problème mysqldumpéchoue lors de l'exportation de la table 'maia_mail'

# mysqldump -u root -p maia > maia.sql
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `maia_mail` at row: 15

Il fonctionne pendant moins de 30 secondes et obtient une erreur comme ci-dessus.

La taille totale de la base de données est de 1,3 Go, la table maia_mail étant de 1,0 Go

Dans my.cnfj'ai ces ensembles:

[mysqld]
max_allowed_packet      = 1300M
[mysqldump]
max_allowed_packet      = 1300M

Veuillez conseiller ou donner des conseils sur la façon de vider la base de données?

mysql backup mysqldump garfink
la source
170 Go d'espace libre. C'est aussi la même chose si je sauvegarde sur la machine db est
activée
des copies des e-mails afin que les données varchar principalement
garfink
le 1300M était un changement récent, le problème existait quand il était également réglé sur le 16M par défaut. Le serveur a également été redémarré après le passage à 1300M.
garfink
Je reviens au 16M par défaut. le vidage entraîne la même erreur 2013 sur la ligne 15
garfink

Réponses:

13

Je pourrais facilement suggérer de modifier les paramètres InnoDB, ce qui pourrait être un peu lourd juste pour faire fonctionner mysqldump. Vous n'aimez peut-être pas ce que je propose, mais je pense que c'est votre meilleure (seule) option. Ça y est:

SUGGESTION # 1: Désactiver les insertions étendues

Le paramètre par défaut de mysqldump inclurait le regroupement de centaines ou de milliers de lignes dans un seul INSERT. C'est ce qu'on appelle un INSERT étendu. Cela provoque un dépassement au-delà de max_allowed_packet .

J'ai répondu à un message sur Sep 01, 2011(le serveur MySQL a disparu en empêchant l'importation de gros vidages ) où j'ai discuté de la même chose pour importer un grand mysqldump. Je crois que la désactivation de INSERT étendu aiderait également à créer un mysqldump gênant.

mysqldump -u root --skip-extended-insert -p maia > maia.sql

Mauvaise nouvelle: ce que cela fait en créant une commande INSERT pour chaque ligne. Cela augmentera certainement le temps nécessaire pour effectuer le mysqldump. Par conséquent, il augmentera également avec le temps nécessaire pour recharger (probablement par un facteur de 10-100.

J'ai discuté skip-extended-insertavant

SUGGESTION # 2: vidage des données binaires sous forme hexadécimale (FACULTATIF)

Pour rendre les données binaires de mysqldump plus portables, videz ces données en hexadécimal

mysqldump -u root --skip-extended-insert --hex-blob -p maia > maia.sql

Mauvaise nouvelle: cela gonflera un peu plus le mysqldump

ESSAIE !!!

Note latérale: La taille maximale de max_allowed_packet est de 1G

RolandoMySQLDBA
la source
5

J'obtenais également la même erreur en essayant de vider la base de données de 12 Go. J'ai fait les changements suivants pour le faire fonctionner.

  1. paquet max_allowed_packet configuré à 1024M
  2. net_read_timeout configuré à 7200
  3. net_write_timeout configuré à 7200

Remarque: Je sais que les valeurs de délai d'attente sont beaucoup trop élevées (7200 secondes, soit 20 heures). Mais je l'ai fait intentionnellement juste pour exclure toute chance. Je suis en train de trouver une valeur de timeout optimale.

vrai gadha
la source
2
Pour les autres utilisateurs: ceux-ci sont configurés sur le serveur, pas dans le fichier de configuration mysqldump. De plus, 7200 secondes est de 2 heures, pas de 20.
Mark
définissez global net_read_timeout = 120; définir global net_write_timeout = 900; a travaillé pour moi
kasi
2

Incluez simplement les éléments suivants dans votre fichier de configuration my.ini (Windows) ou my.cnf (Linux).

[mysqld]
max_allowed_packet=1024M 

[mysqldump]
max_allowed_packet=1024M 
net_read_timeout=3600 
net_write_timeout=3600
Jesus Uzcanga
la source
2
Les sections devraient être l'inverse.
OrangeDog
1

Assurez-vous d'avoir suffisamment de mémoire pour effectuer un vidage. Veuillez continuer à vérifier la mémoire pendant la sauvegarde, par exemple en utilisant une commande comme celle-ci:

free -mt

Si vous vous épuisez la mémoire pendant le vidage, vous obtiendrez

mysqldump: Erreur 2013: connexion perdue

Ranjeet Ranjan
la source
1

J'ai trouvé:

--max-allowed-packet=1G --net-buffer-length=32704

... le fait fonctionner là où il ne l'était pas (de manière fiable) auparavant, malgré les changements de délai d'expiration de lecture / écriture, les keepalives TCP, etc.

Les max_allowed_packetparamètres seuls ne l'ont pas fait fonctionner, donc peut ne pas être nécessaire s'il net_buffer_lengthest utilisé. - ralph-bolton

Modifier max-allowed-packetet net-buffer-lengthsemble beaucoup mieux que de désactiver les insertions étendues. - kristofer

Voir aussi Quel max_allowed_packet est assez grand et pourquoi dois-je le changer?

user126897
la source