Discussion :

[if_zen]

Bonsoir,

Je me permets de vous demander certains éclaircissements concernant une erreur qui est survenue hier sur ma base de données.
Après un crash général (dont la source n'a pas encore été élucidée) des erreurs ont persisté au niveau de mysql, et plus précisément sur une table, ou le fait de faire un simple insert posait problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
1062 : Duplicate key or integrity constraint violation message from server:
 "Duplicate entry 'NULL' for key 4"
insert into BASE.`TABLE` (ID, HEURE1, DATE1, HEURE2, DATE2, ID1, ID2, CHAMP1, CHAMP2, CHAMP3) values
(42, '19:27:00', '2007-12-11', '19:27:00', '2007-12-11', 10, 10, 'val1', 'val2', 'val3')

Des opérations de maintenance diverses (proposées par phpmyadmin) telles que CHECK ou ANALYSE n'ont donné absolument aucun résultat (aucune erreur détectée). J'ai tenté un FLUSH qui doit permettre de mettre à jour le contenu du cache MySQL au niveau des données si j'ai bien compris.

Suite à cette manipulation, les inserts ont refonctionné.

J'ai essayé ensuite de combler les vides puisqu'il manquait environ 300 enregistrement avant que la table ne soit réparée. J'ai donc tenté une requête permettant 300 inserts, une fois via phpmyadmin et une fois via mysqlQueryBrowser. J'ai alors obtenu une erreur du style suivant sur les deux clients :

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 80385 bytes) in /usr/share/phpmyadmin/libraries/sqlparser.lib.php on line 306

Enfin, en cherchant des infos sur le net, je suis simplement tombé dans un forum ou l'explication donnée par le support technique était le suivant (concernant cette même erreur) :

Support response: 2007/09/07 10:35
The database server you were on was having a memory allocation problem. We have restarted the mysql daemon on the server and the problem went away. We don’t expect the problem to return.

Ca me semble assez léger tout ça.

Ce qui me dérange dans l'affaire, c'est que je n'ai pas pu retrouver la moindre trace de log concernant les requetes d'insertions qui ont pu avoir été faites depuis ce crash, je ne sais pas du tout quel est le risque pour que le problème se reproduise, ni son origine.

Si vous avez des idées, des suggestions sur ce qui aurait pu se produire, elles sont les bienvenues.

En parallèle, j'ai pu voir dans /var/log/daemon.log le log suivant :

Dec 11 14:28:14 localhost mysqld[4226]: 071211 14:28:14 [ERROR] Got error 134 when reading table './basename/table2'

... qui ne concerne pas la même table, mais qui a été corrigée via la commande CHECK.

En vous remerciant infiniment pour vos suggestions.

Edit :
Stats mySQL :
Un autre thread a été ouvert contenant les infos de configuration de mysql, ça pourrait aider à trouver une explication ! Encore merci

[if_zen]

bonjour,

Un petit Up et une simplification de l'énoncé.
Il nous arrive assez fréquemment d'avoir une table qui lâche inopinément, jetant des exceptions du type :

Duplicate key or integrity constraint violation message from server: "Duplicate entry 'NULL' for key 4"

La requête est tout à fait correcte (utilisée x fois tous les jours sans poser de pb). Tout insert dans la base est rejeté. Un update ne pose pas de problème.

Afin de palier au problème, il suffit de faire un REPAIR TABLE. La question est : comment éviter cela, à quoi cela peut-il être dû ? Passer en InnoDB serait une solution je pense, mais qui ne m'arrange pas dans l'immédiat.
L'ajout d'un ordre de checksum (cf CHECKSUM doc MySQL) dans les create table (ou via alter table pour la reprise) pourrait corriger le problème ?

En vous remerciant.

[CinePhil]

Le message

"Duplicate entry 'NULL' for key 4"

Signifie que tu as essayé d'entrer une valeur NULL dans une clé primaire, ce qui est rigoureusement interdit.

[if_zen]

Bonjour,

Comme je l'ai dit au-dessus, la requete est correcte. En la repassant après un REPAIR TABLE, tout refonctionne. Je n'ai aucun champ null dans la requete, c'est vraiment mySQL qui craque. En attendant cela arrive quelques fois par an. Maintenant on sait comment réagir, mais au début c'était pas du gâteau.

Merci d'avoir répondu

[Maljuna Kris]

Saluton,

La requête est tout à fait correcte (utilisée x fois tous les jours sans poser de pb). Tout insert dans la base est rejeté. Un update ne pose pas de problème.

Le problème ne provient pas, à l'évidence, de la syntaxe SQL de la requête mais des données transmises à celle-ci.
On peut imaginer que le processus client sous-jacent, qui alimente et soumet cette requête, puisse, de temps à autres, générer un flux de données incohérent, non ?

[if_zen]

Bonjour,

Merci pour ta réponse.
Je ne suis pas certain d'avoir compris le message, mais je précise qu'il ne s'agit pas d'une preparedStatement, mais d'une requête toute bête, comme on peut en voir une dans le 1er post :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
INSERT INTO BASE.`TABLE` (ID, HEURE1, DATE1, HEURE2, DATE2, ID1, ID2, CHAMP1, CHAMP2, CHAMP3) VALUES
(42, '19:27:00', '2007-12-11', '19:27:00', '2007-12-11', 10, 10, 'val1', 'val2', 'val3')

Un CHECK TABLE indique bien que la table est corrompue.

[Maljuna Kris]

Mais cette requête est bien générée et soumise au serveur MySQL par un processus client.
C'est peut-être la fiabilité de ce processus qui est en cause, celui-ci générant de temps en temps une requête avec une valeur NULL pour la colonne ID, par exemple.

[if_zen]

Bonjour,

Même en supposant que cela soit vrai, la clé incriminée est la clé 4. Or, seule ID est une clé unique (une PK), les autres champs IDxxx sont bien indexés mais ne subissent pas la contrainte de l'unicité. Donc, même en supposant que j'envoie un NULL dans la key 4 cela ne devrait pas poser de problème. Je pense que l'erreur vient du fait que la table soit corrompue et non du flux qui est envoyé à mySQL.
Une fois la table corrompue, ce sont tous les INSERT qui sont rejetés et qui me renvoient la même erreur.

[Maljuna Kris]

Non, une PK ne peut être NULL. (cf le post de Cinephil)

[if_zen]

Comme je viens de le dire, KEY 4 n'est pas une PK.