Le serveur MySQL a disparu lors de l'importation d'un fichier SQL volumineux
J'ai essayé d'importer un fichier SQL volumineux via phpMyAdmin ...
'Le serveur MySql est parti'
Que faire?
Comme indiqué ici :
Les deux raisons les plus courantes (et les correctifs) pour le serveur MySQL ont disparu (erreur 2006) sont:
Le serveur a expiré et a fermé la connexion. Comment réparer:
vérifiez que la variable wait_timeout dans le fichier de configuration my.cnf de votre mysqld est suffisamment grande. Sur Debian:
Sudo nano /etc/mysql/my.cnf, définissezwait_timeout = 600secondes (vous pouvez Modifiez/diminuez cette valeur lorsque l'erreur 2006 a disparu), puisSudo /etc/init.d/mysql restart. Je n'ai pas vérifié, mais la valeur par défaut pour wait_timeout peut durer environ 28800 secondes (8 heures).Le serveur a abandonné un paquet incorrect ou trop volumineux. Si mysqld obtient un paquet trop volumineux ou incorrect, il suppose que quelque chose a a mal tourné avec le client et ferme la connexion. Vous pouvez augmenter la limite maximale de taille de paquet en augmentant la valeur de max_allowed_packet dans le fichier my.cnf. Sur Debian:
Sudo nano /etc/mysql/my.cnf, définissezmax_allowed_packet = 64M(vous pouvez Modifiez/diminuez cette valeur lorsque l'erreur 2006 a disparu), puisSudo /etc/init.d/mysql restart.
Edit:Notez que les commandes des fichiers d'options de MySQL ne sont pas déjà disponibles sous forme de commentaires (comme dans le fichier php.ini par exemple). Vous devez donc saisir tout changement/ajustement dans my.cnf ou my.ini les dans le répertoire mysql/data ou dans l’un des autres chemins, sous le groupe d’options approprié, tel que [client], [myslqd]... etc., par exemple:[mysqld]wait_timeout = 600max_allowed_packet = 64M
Ensuite, redémarrez le serveur. Pour obtenir les valeurs, tapez dans la console:select @@wait_timeout;select @@max_allowed_packet;
Pour moi cette solution n'a pas fonctionné alors j'ai exécuté
SET GLOBAL max_allowed_packet=1073741824;
dans mon client SQL.
Si vous ne pouvez pas changer cela lorsque le service MYSql est en cours d'exécution, vous devez arrêter le service et modifier la variable dans le fichier "my.ini".
Par exemple:
max_allowed_packet=20M
Si vous utilisez des valeurs par défaut, vous disposez de beaucoup d'espace pour optimiser votre configuration mysql.
La première étape que je recommande consiste à augmenter le max_allowed_packet à 128M.
Téléchargez ensuite le script MySQL Tuning Primer et exécutez-le. Il fournira des recommandations sur plusieurs facettes de votre configuration pour de meilleures performances.
Pensez également à ajuster vos valeurs de délai d'attente à la fois en MySQL et en PHP.
Quelle est la taille (taille du fichier) du fichier que vous importez et pouvez-vous importer le fichier en utilisant le client en ligne de commande mysql au lieu de PHPMyAdmin?
Si vous travaillez sur XAMPP, vous pouvez corriger le problème de suppression du serveur MySQL avec les modifications suivantes ..
ouvrez votre fichier my.ini mon.ini est (D:\xampp\mysql\bin\my.ini)
changer les valeurs de variable suivantes
max_allowed_packet = 64M
innodb_lock_wait_timeout = 500
Si vous utilisez MAMP sous OS X, vous devrez modifier la valeur max_allowed_packet dans le modèle pour MySQL.
Vous pouvez le trouver à l’adresse: Fichier> Modifier le modèle> MySQL my.cnf
Ensuite, recherchez simplement
max_allowed_packet, modifiez la valeur etsave.
J'espère que ça aide quelqu'un.
J'ai résolu mon problème avec ce court fichier /etc/mysql/my.cnf:
[mysqld]
wait_timeout = 600
max_allowed_packet = 100M
J'ai eu cette erreur et d'autres apparentés lorsque j'ai importé un fichier SQL de 16 Go. Pour moi, éditez my.ini et définissez les éléments suivants (basés sur plusieurs posts différents) dans la section [mysqld]:
max_allowed_packet = 110M
innodb_buffer_pool_size=511M
innodb_log_file_size=500M
innodb_log_buffer_size = 800M
net_read_timeout = 600
net_write_timeout = 600
Si vous utilisez Windows, accédez au panneau de configuration et aux services, puis consultez les détails de MySQL pour voir où se trouve my.ini. Ensuite, après avoir modifié et sauvegardé my.ini, redémarrez le service mysql (ou redémarrez l'ordinateur).
Si vous utilisez HeidiSQL, vous pouvez également définir tout ou partie de ces éléments.
L'autre raison pour laquelle cela peut arriver est le manque de mémoire. Vérifiez/var/log/messages et assurez-vous que votre fichier my.cnf n’est pas configuré pour permettre à mysqld d’allouer plus de mémoire que ne l’a votre machine.
Votre processus mysqld peut en réalité être tué par le noyau, puis redémarré par le processus "safe_mysqld" sans que vous ne vous en rendiez compte.
Utilisez top et observez l’allocation de mémoire en cours d’exécution pour voir quelle est votre réserve.
faites une copie de sauvegarde de my.cnf avant de la modifier.
Si vos données incluent des données BLOB:
Notez qu’une importation de données à partir de la ligne de commande semble s’étouffer avec les données BLOB, ce qui entraîne l’erreur «Le serveur MySQL est parti».
Pour éviter cela, recréez mysqldump mais avec l'indicateur --hex-blob:
http://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_hex-blob
qui écrira le fichier de données avec des valeurs hexadécimales plutôt que binaire entre autres textes.
PhpMyAdmin a aussi l’option "Vider les colonnes binaires en notation hexadécimale (par exemple," abc "devient 0x616263)", ce qui fonctionne bien.
Notez qu'il existe un bogue de longue date (à compter de décembre 2015) qui signifie que les colonnes GEOM ne sont pas converties: Sauvegarder une table avec une colonne GEOMETRY à l'aide de mysqldump? L’utilisation d’un programme tel que PhpMyAdmin semble donc être la seule solution de contournement (l’option susmentionnée convertit correctement les colonnes GEOM).
Si l'échec est long, agrandissez la variable wait_timeout.
Si cela échoue immédiatement, agrandissez la variable max_allowed_packet; Si cela ne fonctionne toujours pas, assurez-vous que la commande est valide SQL. Le mien avait des citations sans échappatoire qui ont tout bousillé.
En outre, si possible, envisagez de limiter le nombre d'insertions d'une seule commande SQL à, par exemple, 1000. Vous pouvez créer un script qui crée plusieurs instructions à partir d'une seule en réintroduisant la partie INSERT ... toutes les n insertions.
J'ai mis à jour "max_allowed_packet" à 1024M, mais cela ne fonctionnait toujours pas. Il s'avère que mon script de déploiement était en cours d'exécution:
mysql --max_allowed_packet=512M --database=mydb -u root < .\db\db.sql
Assurez-vous de spécifier explicitement un plus grand nombre à partir de la ligne de commande si vous ne le faites pas de cette façon.
j'ai eu une erreur similaire .. pour résoudre ce problème, ouvrez simplement le fichier my.ini ... à la ligne 36, changez la valeur de la taille de paquet maximale autorisée, par exemple. max_allowed_packet = 20M
Assurez-vous que le processus mysqld ne redémarre pas à cause de gestionnaires de services comme systemd.
J'ai eu ce problème dans vagrant avec centos 7. Les réglages de configuration n'ont pas aidé. Il s’est avéré que c’était systemd qui avait tué le service mysqld chaque fois qu’il prenait trop de mémoire.
Je fais des calculs importants qui impliquent la connexion mysql pour rester longtemps et avec des données lourdes. Je faisais face à ce "problème Mysql s'en aller". Donc j’ai essayé d’optimiser les requêtes mais cela ne m’a pas aidé alors j’ai augmenté la limite de variables mysql qui est définie par défaut sur une valeur inférieure.
wait_timeout max_allowed_packet
Dans la mesure du possible, cela devrait correspondre à un nombre quelconque * 1024 (octets). vous pouvez vous connecter au terminal à l'aide de la commande ' mysql -u nom_utilisateur -p ' et vérifier et modifier ces limites variables.
Si augmenter max_allowed_packet n'aide pas.
J'avais la même erreur que vous lorsque vous importez un fichier .sql dans ma base de données via Sequel Pro.
L'erreur persistait après la remontée du max_allowed_packet à 512M. J'ai donc lancé l'importation dans la ligne de commande à la place avec:
mysql --verbose -u root -p DatabaseName < MySQL.sql
Cela a donné l'erreur suivante:
ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled
J'ai trouvé quelques questions StackOverflow utiles:
- Activer le mode binaire lors de la restauration d'une base de données à partir d'un vidage SQL
- Mysql ERROR: ASCII '\ 0' lors de l'importation d'un fichier SQL sur un serveur Linux
Dans mon cas, mon fichier .sql était un peu corrompu ou quelque chose. Le dump MySQL que nous obtenons vient dans deux fichiers Zip qui doivent être concaténés puis décompressés. Je pense que la décompression a été initialement interrompue, laissant au fichier des caractères et des encodages étranges. Obtenir un nouveau dump MySQL et le décompresser correctement a fonctionné pour moi.
Je voulais simplement ajouter ceci ici au cas où d'autres trouveraient que l'augmentation de la variable max_allowed_packet n'aidait pas.
Pour GoDaddy hébergement mutualisé
Sur les comptes d'hébergement partagé de GoDaddy, il est difficile de modifier les fichiers PHP.ini, etc. Cependant, il existe un autre moyen et cela a parfaitement fonctionné pour moi. (Je viens de télécharger avec succès un fichier texte .sql de 3,8 Mo, contenant 3 100 lignes et 145 colonnes. À l'aide de la commande IMPORT de phpMyAdmin, l'erreur se produisait si le serveur MySQL avait disparu et aucune autre information.)
J'ai trouvé que Matt Butcher avait la bonne réponse. Comme Matt, j’avais essayé toutes sortes d’astuces, depuis l’exportation de bases de données MySQL en petits morceaux jusqu’à l’écriture de scripts qui décomposent les importations volumineuses en plus petites. Mais voici ce qui a fonctionné:
(1) CPANEL ---> FICHIERS (groupe) ---> SAUVEGARDE
(2a) Sous "Sauvegardes partielles" ...
(2b) Sous "Télécharger une sauvegarde de base de données MySQL"
(2c) Choisissez votre base de données et téléchargez une copie de sauvegarde (cette étape est facultative mais judicieuse)
(3a) Directement à droite de 2b, sous "Restaurer une sauvegarde de base de données MySQL"
(3b) Choisissez le fichier d'importation .SQL à partir de votre lecteur local
(3c) Le vrai bonheur sera le vôtre (sous peu ....) Le mien a pris environ 5 secondes
J'ai pu utiliser cette méthode pour importer une seule table. Rien d'autre dans ma base de données n'a été affecté - mais c'est ce que l'étape (2) ci-dessus est destinée à protéger.
Remarques:
une. Si vous ne savez pas comment créer un fichier d'importation .SQL, utilisez phpMyAdmin pour exporter une table et modifier cette structure de fichier.
SOURCE: Matt Butcher 2010 Article
J'ai eu une erreur similaire aujourd'hui lors de la duplication de la base de données (le serveur MySQL est parti ...), mais quand j'ai essayé de redémarrer mysql.server, j'ai eu l'erreur
ERROR! The server quit without updating PID ...
Voici comment je l'ai résolu: J'ai ouvert Applications/Utilitaires/et lancé Activity Monitor.
quit mysqld
a ensuite pu résoudre le problème d'erreur avec
mysql.server restart