[RESOLU] Problème sur le site : "MySQL server has gone away"

[fafa08]

J'aurais besoin d'aide s'il vous plait.

J'ai un problème sur le site de vente et j'utilise Prestashop.

Jai pu ajouter mes produits sans problème jusqu'à maintenant.
Quand j'ajoute maintenant un produit, j'enregistre et j'ai une erreur.
Mais le produit apparait bien sur le site de ventes pour le public.

L'erreur (Exemple) :

Array
(
[0] => MySQL server has gone away
[1] => Array
(
[0] => (1,'teinture')
[1] => (1,'manic')
[2] => (1,'panic')
[3] => (1,'tg451002')
[4] => (1,'home')
)
)

END

Si je supprime ce produit, je peux refaire un autre produit mais encore un message d'erreur sur un nouveau produit, affiché par ce même message.
Ce sont des produits déjà créés pourtant ou il n'y avait pas de problème.
Je ne sais pas quoi faire.

Aussi, si le produit contient des déclinaisons, la page de mon administration affiche bien la mise en page (formulaire) comme il faut, mais après validation, rien n'est enregistré. Mais le produit en lui même avec les réf., le prix, la description etc. s'enregistre bien.

En espérant que vous pourrez trouver une solution à mon problème. Je débute encore...

MERCI.

[Yoya]

Bonjour et bienvenue.
Quel est ton hébergeur ainsi que la version utilisée ?

Cdlt,
Pierre.

[fafa08]

Bonjour,

Mon hébergeur est OVH.
J'utilise prestashop (version 1.2.5).

Je n'avais pas précisé désolé.

[fafa08]

Bonjour,

Personne ne pourrait m'aider s'il vous plait ? Je suis vraiment bloquée.
Je peux en attendant ajouter mes produits simples sans déclinaison, ils sont validés avec ce message d'erreur. Mais il m'est toujours impossible de faire des produits à déclinaison. J'en ai énormément à ajouter... Et aussi à modifier.

Si je trouve une solution je vous en ferai part. Mais en attendant, je suis dans le flou.
La seule réponse de ovh étant : "Ce message d'erreur est généralement du au fait que la requete SQL ne fonctionne pas correctement". Donc ca ne m'aide pas beaucoup. Il n'y a pas de problème sur mon serveur...

En attendant une réponse, je remercie par avance les personnes qui pourront m'aider.

[bechir]

Bonjour,
Voici les causes majeurs de cette bug:

Les causes les plus courantes sont:
1. Le serveur a expiré et a fermé la connexion. Par défaut, le serveur ferme la connexion après 8 heures ou 28800 secondes, si rien ne s'était passé. Vous pouvez modifier le délai en définissant la variable wait_timeout lorsque vous démarrez mysqld via le répertoire / etc / my.cnf (sous Linux, recherchez le fichier d'installation de votre serveur sous Windows) ainsi. Cela affecte la plupart des connexions persistantes; connexions ouvertes avec mysql_pconnect () en PHP. Il peut également affecter les connexions regroupées de dire n'importe quelle connexion côté serveur de mise en commun.

2. Une autre raison courante de recevoir le serveur MySQL est parti d'erreur parce que vous avez publié une étroite "sur votre connexion MySQL et a ensuite tenté d'exécuter une requête sur la connexion fermée. Il s'agit d'un problème de logique simple. Êtes-vous partager la connexion entre plusieurs threads?

3. Vous avez un délai d'attente de la connexion TCP / IP sur le côté client. Cela peut se produire si vous avez été en utilisant les commandes: mysql_options (..., MYSQL_OPT_READ_TIMEOUT, ...) ou mysql_options (..., MYSQL_OPT_WRITE_TIMEOUT, ...). Dans ce cas, l'augmentation du délai d'attente, tel que décrit ci-dessus, peut aider à résoudre le problème.

4. Vous avez rencontré un délai d'attente sur le côté serveur et la reconnexion automatique du client est désactivée. S'il vous plaît se référer à l'article lié ci-dessus pour plus de détails et de solution.

5. Vous pouvez aussi obtenir ces erreurs si vous envoyez une requête au serveur qui est incorrecte ou trop grande. Si mysqld reçoit un paquet qui est trop large ou mal ordonné, il suppose que quelque chose s'est mal passé avec le client et ferme la connexion. Si vous avez besoin de grosses requêtes (par exemple, si vous travaillez avec de grandes colonnes BLOB), vous pouvez augmenter la limite de requête en définissant la variable max_allowed_packet du serveur, qui a une valeur par défaut de 1 Mo. Vous pouvez aussi avoir besoin d'augmenter la taille de paquet maximale sur le client. Plus d'informations sur la configuration de la taille des paquets est donnée dans la section B.1.2.9, "Packet too large".

6. Une instruction INSERT ou REPLACE qui insère un grand nombre de lignes peut également provoquer ce genre d'erreurs. Soit un de ces états envoie une demande unique pour le serveur, indépendamment du nombre de lignes à insérer, ainsi, vous pouvez souvent éviter l'erreur en réduisant le nombre de lignes envoyées par INSERT ou REPLACE.

7. Vous bénéficiez également d'une connexion perdue si vous envoyez un paquet de 16 Mo ou plus si votre client est âgé de plus 4.0.8 et votre serveur est 4.0.8 et au-dessus, ou l'inverse.

Peu de causes rares sont:
1. Rarement l'administrateur db peuvent avoir tué le fil conducteur d'une déclaration ou un KILL commande mysqladmin kill.

2. Une application client fonctionnant sur un hôte différent n'a pas les privilèges nécessaires pour se connecter au serveur MySQL à partir de cet hôte.

3. Vous utilisez un client Windows et le serveur a abandonné la connexion (sans doute parce que wait_timeout expiré) avant que la commande a été délivré. Le problème sur Windows, c'est que dans certains cas, MySQL ne reçoit pas une erreur du système d'exploitation lors de l'écriture à la connexion TCP / IP au serveur, mais devient plutôt l'erreur lorsque vous essayez de lire la réponse de la connexion.

4. Avant MySQL 5.0.19, même si le drapeau se reconnecter dans la structure MYSQL est égal à 1, MySQL ne se reconnecte pas automatiquement et ré-émettre la requête en tant qu'elle ne sait pas si le serveur a bien reçu la requête d'origine ou non.

5. Il est également possible de voir cette erreur si les recherches ne hostname (par exemple, si le serveur DNS sur lequel votre serveur ou du réseau repose descend). C'est parce que MySQL est dépendant du système hôte pour la résolution de nom, mais n'a aucun moyen de savoir si elle fonctionne - du point de vue de MySQL, le problème est impossible à distinguer de toute autre réseau de délai d'attente.

6. Vous pouvez également voir le serveur MySQL est parti d'erreur si MySQL est lancé avec l'option-skip-networking.

7. Vous pouvez également rencontrer cette erreur avec les applications que les processus de l'enfant à fourche, qui essaient d'utiliser la même connexion au serveur MySQL. Ceci peut être évité en utilisant une connexion distincte pour chaque processus enfant.

8. Un autre problème de réseau qui peuvent provoquer cette erreur se produit si le port MySQL (par défaut 3306) est bloqué par votre pare-feu, ce qui empêche toute connexion à tous sur le serveur MySQL.

9. Vous avez rencontré un bug où le serveur est mort lors de l'exécution de la requête.

[fafa08]

Bonjour,

J'ai des difficultés à tout comprendre, mais je vais analyser chacun des points, je finirai bien par trouver une solution, un jour. Merci pour toutes les infos.

Bonne journée. Merci.

[fafa08]

Bonjour,
Je n'ai toujours pas solutionné ce problème, je crois qu'il va falloir tout refaire... En espérant que ca ne le refait plus.
Ca me bloque !!! Pas de chance...

[fafa08]

Bonjour,

j'ai résolu mon problème. Suite à des travaux effectués par OVH, j'ai commencé à avoir ce genre de problèmes (je pense que c'est dû à cela car je travaillais sur le site à ce moment là). Après avoir vérifié l'intégrité des tables de prestashop dans phpmyadmin (onglet opérations), je me suis apperçue que trois tables étaient corrompues : ps_product_attribute, ps_product_attribute_combination, ps_product_attribute_image. Un simple "repair table nom_de_la_table" a résolu mon problème sans perte de données apparente.

Je ne m'y reprendrai plus à deux fois, ainsi ai-je installé le module de sauvegarde de Julien Breux.