MySQL Server a disparu lors de l'importation d'un gros fichier sql

J'ai essayé d'importer un gros fichier sql via phpMyAdmin ... Mais il continuait d'afficher une erreur

«Le serveur MySql est parti»

Que faire?

Comme indiqué ici :

Les deux raisons (et corrections) les plus courantes pour le serveur MySQL ont disparu (erreur 2006):

Le serveur a expiré et a fermé la connexion. Comment réparer:

1. 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.cnfdéfinissez les wait_timeout = 600secondes (vous pouvez modifier / diminuer cette valeur lorsque l'erreur 2006 a disparu), puis sudo /etc/init.d/mysql restart. Je n'ai pas vérifié, mais la valeur par défaut de wait_timeout pourrait être d'environ 28800 secondes (8 heures).

2. Le serveur a supprimé un paquet incorrect ou trop volumineux. Si mysqld obtient un paquet trop volumineux ou incorrect, il suppose que quelque chose s'est mal passé 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.cnfdéfinissez max_allowed_packet = 64M(vous pouvez modifier / diminuer cette valeur lorsque l'erreur 2006 a disparu), puis sudo /etc/init.d/mysql restart.

Éditer:

Notez que les fichiers d'options MySQL n'ont pas leurs commandes déjà disponibles en tant que commentaires (comme dans php.ini par exemple). Donc , vous devez saisir tout changement / tweak dans my.cnfou my.iniet placez - les dans le mysql/datarépertoire ou dans l' une des autres voies, dans le groupe approprié d'options telles que [client], [myslqd], etc. Par exemple:

[mysqld]
wait_timeout = 600
max_allowed_packet = 64M

Redémarrez ensuite le serveur. Pour obtenir leurs valeurs, saisissez le client mysql:

> select @@wait_timeout;
> select @@max_allowed_packet;

Pour moi, cette solution n'a pas fonctionné, j'ai donc exécuté

SET GLOBAL max_allowed_packet=1073741824;

dans mon client SQL.

Si vous ne pouvez pas changer cela avec le service MYSql 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 travaillez sur XAMPP, vous pouvez résoudre le problème de disparition du serveur MySQL avec les modifications suivantes.

ouvrez votre fichier my.ini mon emplacement my.ini est (D: \ xampp \ mysql \ bin \ my.ini)

modifier les valeurs de variable suivantes

max_allowed_packet = 64M
innodb_lock_wait_timeout = 500

Si vous utilisez des valeurs par défaut, vous avez beaucoup de place pour optimiser votre configuration mysql.

La première étape que je recommande est d'augmenter le max_allowed_packet à 128M.

Téléchargez ensuite le script MySQL Tuning Primer et exécutez-le. Il fournira des recommandations à plusieurs facettes de votre configuration pour de meilleures performances.

Regardez également dans l'ajustement de vos valeurs de délai d'expiration à la fois dans MySQL et PHP.

Quelle est la taille (taille du fichier) du fichier que vous importez et pouvez-vous importer le fichier à l'aide du client de ligne de commande mysql au lieu de PHPMyAdmin?

Si vous utilisez MAMP sur OS X, vous devrez modifier la max_allowed_packetvaleur dans le modèle pour MySQL.

1. Vous pouvez le trouver sur: Fichier> Modifier le modèle> MySQL my.cnf

2. Ensuite, recherchez max_allowed_packet, modifiez la valeur et enregistrez.

J'ai résolu mon problème avec ce court fichier /etc/mysql/my.cnf:

[mysqld]
wait_timeout = 600
max_allowed_packet = 100M

L'autre raison pour laquelle cela peut arriver est le manque de mémoire. Vérifiez / var / log / messages et assurez-vous que votre my.cnf n'est pas configuré pour que mysqld alloue plus de mémoire que votre machine.

Votre processus mysqld peut en fait être tué par le noyau puis redémarré par le processus "safe_mysqld" sans que vous vous en rendiez compte.

Utilisez top et regardez l'allocation de mémoire pendant qu'il fonctionne pour voir votre marge.

effectuez une sauvegarde de my.cnf avant de le modifier.

J'ai eu cette erreur et d'autres liées lorsque j'ai importé un fichier SQL de 16 Go. Pour moi, éditer my.ini et définir ce qui suit (basé sur plusieurs articles 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 exécutez sous Windows, accédez au panneau de configuration, aux services et examinez les détails de MySQL et vous verrez où se trouve my.ini. Ensuite, après avoir modifié et enregistré 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 ceux-ci en utilisant cela.

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 le donnez de cette façon.

Si vos données incluent des BLOBdonnées:

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 le --hex-blobdrapeau:

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 binaires entre autres textes.

PhpMyAdmin a également l'option "Dump des colonnes binaires en notation hexadécimale (par exemple," abc "devient 0x616263)" qui fonctionne bien.

Notez qu'il existe un bogue de longue date (en décembre 2015) qui signifie que les GEOMcolonnes ne sont pas converties: Sauvegarder une table avec une colonne GEOMETRY en utilisant mysqldump? donc l'utilisation d'un programme comme PhpMyAdmin semble être la seule solution de contournement (l'option notée ci-dessus convertit correctement les colonnes GEOM).

Si l'échec est long, agrandissez la wait_timeoutvariable.

S'il échoue immédiatement, agrandissez la max_allowed_packetvariable; Si cela ne fonctionne toujours pas, assurez-vous que la commande est valide en SQL. Le mien avait des citations sans faille qui ont tout foiré.

En outre, si possible, envisagez de limiter le nombre d'insertions d'une seule commande SQL à, disons, 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 une erreur similaire .. pour résoudre ce problème, ouvrez simplement mon fichier .ini .. ici, à la ligne no 36, changez la valeur de la taille de paquet maximale autorisée, c'est-à-dire. 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 tuait le service mysqld à chaque fois qu'il prenait trop de mémoire.

J'ai eu une erreur similaire aujourd'hui lors de la duplication de la base de données (le serveur MySQL est parti ...), mais lorsque j'ai essayé de redémarrer le redémarrage de mysql.server, j'ai eu une erreur

ERROR! The server quit without updating PID ...

Voici comment je l'ai résolu: j'ai ouvert Applications / Utilitaires / et j'ai exécuté Activity Monitor

 quit mysqld

a ensuite pu résoudre le problème d'erreur avec

mysql.server restart

Je fais de gros calculs qui impliquent la connexion mysql pour rester longtemps et avec des données lourdes. je faisais face à ce "problème de rejets de Mysql". J'ai donc essayé d'optimiser les requêtes mais cela ne m'a pas aidé alors j'ai augmenté la limite des variables mysql qui est définie sur une valeur inférieure par défaut.

wait_timeout max_allowed_packet

À la limite de ce qui vous convient, ce devrait être n'importe quel nombre * 1024 (octets). vous pouvez vous connecter au terminal en utilisant la commande ' mysql -u username - p ' et pouvez vérifier et modifier ces limites de variables.

Pour l'hébergement partagé GoDaddy

Sur les comptes d'hébergement partagé 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 3100 lignes et 145 cols. En utilisant la commande IMPORT dans phpMyAdmin, j'obtenais l' erreur redoutée du serveur MySQL et aucune autre information.)

J'ai trouvé que Matt Butcher avait la bonne réponse. Comme Matt, j'avais essayé toutes sortes de trucs, de l'exportation de bases de données MySQL en petits morceaux jusqu'à l'écriture de scripts qui divisent les grandes importations en plus petites. Mais voici ce qui a fonctionné:

(1) CPANEL ---> FICHIERS (groupe) ---> SAUVEGARDE

(2a) Sous la rubrique "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 sauvegarde (cette étape est facultative, mais sage)

(3a) Directement à droite de 2b, sous la rubrique "Restaurer une sauvegarde de base de données MySQL"
(3b) Choisissez le fichier d'importation .SQL depuis votre disque local
(3c) Le vrai bonheur sera le vôtre (peu de temps ....) 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 contre quoi l'étape (2) ci-dessus est destinée à se protéger.

Remarques:
a. 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: Article de Matt Butcher 2010

Si l'augmentation max_allowed_packetn'aide pas.

J'obtenais la même erreur que vous lors de l'importation d'un .sqlfichier dans ma base de données via Sequel Pro.

L'erreur a persisté après avoir augmenté le max_allowed_packetto 512M, j'ai donc exécuté l'importation dans la ligne de commande à la place avec:

mysql --verbose -u root -p DatabaseName < MySQL.sql

Il 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 utiles sur StackOverflow:

• Activer le mode binaire lors de la restauration d'une base de données à partir d'un vidage SQL
• ERREUR Mysql: ASCII '\ 0' lors de l'importation du fichier sql sur le serveur linux

Dans mon cas, mon .sqlfichier était un peu corrompu ou quelque chose. Le vidage MySQL que nous obtenons est livré dans deux fichiers zip qui doivent être concaténés ensemble puis décompressés. Je pense que la décompression a été interrompue au départ, laissant le fichier avec quelques caractères et encodages étranges. Obtenir un nouveau vidage MySQL et le décompresser correctement a fonctionné pour moi.

Je voulais juste ajouter ceci ici au cas où d'autres trouveraient que l'augmentation de la max_allowed_packetvariable n'aidait pas.

Aucune des solutions concernant la taille des paquets ou les délais d'attente n'a fait de différence pour moi. J'avais besoin de désactiver ssl

mysql -u -p -hmyhost.com --disable-ssl db < file.sql

https://dev.mysql.com/doc/refman/5.7/en/encrypted-connections.html

J'ai le même problème avec

$image_base64 = base64_encode(file_get_contents($_FILES['file']['tmp_name']) );
$image = 'data:image/jpeg;base64,'.$image_base64;
$query = "insert into images(image) values('".$image."')";
mysqli_query($con,$query);

Dans le fichier \ xampp \ mysql \ bin \ my.ini de phpmyadmin nous obtenons seulement

[mysqldump]
max_allowed_packet=110M

qui est juste pour mysqldump -u root -p dbname. J'ai résolu mon problème en remplaçant le code ci-dessus par

max_allowed_packet=110M
[mysqldump]
max_allowed_packet=110M