MySQL ne répond plus ... [Résolu]

[Ickou]

Salut à tous

MySQL ne répond plus même après un "reboot" du serveur !
Lorsque je tape dans le shell "mysql" j'ai le message suivant :

ERROR 2013 (HY000): Lost connection to MySQL server during query

"/etc/init.d/mysqld restart , stop ou start" renvois "échec" et "mysqld status" renvois "en cours d'exécution"....

Par contre quand je fais un "top" , les processus "mysqld_safe", "syslogd" , "klogd" et "mysqld" apparaissent en haut de la liste.

J'ai ce problème depuis que j'ai demandé la création d'un index à partir phpMyAdmin.....

comment puis je résoudre ce problème

Merci

mysql Ver 14.7 Distrib 4.1.12, for redhat-linux-gnu (i386) using readline 4.3

[Ickou]

Que faire ? MySQL a l'air d'être mort !!!!

Quelqu'un a t il déjà perdu MySQL ???

que feriez vous à ma place ??

[Maximilian]

Salut,

Kille les process qui tournent encore, relance MySQL et donne-nous les dernières lignes du log d'erreurs MySQL (host.err) si ça ne fonctionne pas.

[Ickou]

il se situe où le fichier log de mysql ??

[Ickou]

impossible de faire marcher mysql même après avoir killer les processus

j'ai trouvé le fichier mysqld.log dans /var/log/

voici ce que j'ai trouvé :

Number of processes running now: 0
060509 10:56:19 mysqld restarted
060509 10:56:19 InnoDB: Started; log sequence number 0 43644
060509 10:56:19 [ERROR] /usr/libexec/mysqld: Error writing file '/var/run/mysqld/mysqld.pid' (Errcode: 28)
060509 10:56:19 [ERROR] Can't start server: can't create PID file: No space left on device

[mathieu]

"No space left on device" : ton disque est plein !
tape la commande "df" pour voir l'espace disque

[Ickou]

Bien vu mathieu !

ce matin j'avais déjà fait "df -h" mais apparement j'étais mal réveillé ......

merci

[Ickou]

Dans le répertoire de ma base j'ai un fichier "#sql-9c9_32.MYI" qui fait 30 Go !!

C'est quoi ce fichier ????

je pense que c'est ça qui m'avait remplit le disque.

[Maximilian]

Envoyé par Ickou

J'ai se problème depuis que j'ai demandé la création d'un index à partir phpMyAdmin.....

Il ne faut pas chercher plus loin... Quelle taille fait la table que tu cherchais à indexer ?

[Ickou]

Ma table fait actuellement 48 Go pour 850 millions d'enregistrements.....
La creation d'index est difficile sur cette table car souvent au bout de 2-3 jours MySQL plante .....

Quelle est le meilleur moyen de gérer des grosses tables ???
(en faire plein de petites et les réunir avec MERGE ??)

Ce fichier de 30 GO (#sql-9c9_32.MYI) contient quoi ?(fichier temporaire pour l'index ?) je peux l'éffacer ?

[Maximilian]

Il contient précisément les index de la table.

Tu devrais rajouter de l'espace disque d'une manière ou d'une autre, et reconsidérer ton indexation.
Peux-tu nous donner la structure de la table et ce que tu compte indexer ?

[Ickou]

J'ai effacé plus de 50 Go de fichier commençant par "#sql" et ma base a pas bougé. Je pense que c'était des fichiers temporaires utilisés lors de la création d'index qui a planté (date de création coincidant avec ma création d'index .... )

Ma table possède 5 attributs :
+ data (int) , name1 et name 2 (varchar 40), id1 et id2 (int) et value (decimal(4,3))
+ma clef primaire --> triplet (data, name1 et name2 ) --> seul truc unique de la table
+ J'essais de mettre des index sur id1 et id2 qui sont au 9999/10000 égal à "null" car il y aura des update

Je pense pas que la structure de ma base soit mauvaise car elle marchait bien avec 400 millions de valeurs .... le problème vient de la taille qui fait que grandir.... total final environ 1.3 milliards d'enregistrements .

Je pense que je vais faire des tables de 400 millions car ça marchait bien avant.

Les gens qui font de grosses bases font comment ?

[Maximilian]

Il passent sous Oracle ou SQL Server (pourquoi je dis ça moi )

30 Go d'index ça me paraissait beaucoup mais effectivement quasiment toutes les colonnes sont indexées... il n'y a pas moyen de s'en passer ?

[Ickou]

Quand j'ai fait la première base avec 400 millions de valeurs , sans index l'interrogation était de 20 minutes minimum et après index le résultat était fait en quelque ms .....

Les indexs sont indispensables.

Ma table contient 25 Go de données , 16Go de clef primaire et 8 Go pour l'index sur id1.

Je vais couper cette table en 2 pour être tranquille.

Je te remercie.

@ bientôt

Ickou

[Maximilian]

Je ne parlais bien sûr pas de supprimer tous les index mais si tu as la possiblité de redéfinir la clé primaire, utilise un identifiant numérique auto-incrémenté plutôt que le triplet (data, name1, name2).
Si tu ne fais pas beaucoup de recherches sur data seul, name1 seul ou name2 seul ça permettra d'éviter de les indexer donc gain de place.

Sinon avec MySQL 5.1 (encore en beta) il y a possibilité de partitionner les tables ce qui est très pratique pour de grandes bases. Peut-être à examiner pour le futur...

[Alexandre T]

Envoyé par Maximilian

Il passent sous Oracle ou SQL Server (pourquoi je dis ça moi )

Pour notre logiciel, notre table principale contient une clef primaire sur trois champs en chaîne de caractères... (Varchar(4) ; Varchar(4) ; Varchar(35).

Pour la base d'un grand compte, en Oracle (3 millions de lignes), j'ai mis deux jours à créer l'index...

Sinon, après maintes et maintes remarques, j'ai conseillé à ma direction de nous donner le temps de reformaliser cette base mal construite. En clair je pensais juste à mettre une [auto-censure] de clefs primaires en en entier long... Devant les rejets, et conscients des heures supplémentaires que ces clefs créent dans la société, j'ai pété un cable. Je suis resté un soir, j'ai rajouté ce champ, j'ai remis les index, j'ai recodé le programme et j'ai chargé la base sur MySQL... Aucun problème ls temps de réponses explosent la base en Oracle* !

En conclusion, je rejoins Maximilian, retravaille la structure de ta table avant toute chose.

*N.B. : Attention je compare pas Oracle et MySQL. Je dis juste qu'une table bien construite en MySQL est plus rapide qu'une table pourrie en Oracle

*N.B. : Pour la petite histoire, de mauvaises foi la direction m'a répondu que sur Oracle, il y a trois autres bases de données qui tournent et on a jeté aux oubliettes mon code

[Ickou]

Merci Maximilian car ce que tu m'as dit m'a fait réflechir
Je voudrais savoir si c'est possible de suprimer totalement la clef primaire (triplet --> seul truc unique de la table) ? la clef primaire est obligatoire ? (je veux bien mettre un attribut auto incrementé mais ça me servera à rien ...)
dans ce cas là j'indexerai "data".

Je vais tester desuite avec un attribut autoincrementé.

Une dernière question : C'est mieux de d'abord créer les index puis remplir la base (je remplis avec perl DBI) ou d'abord remplir puis faire les index ??

[Maximilian]

Code :

ALTER TABLE latable DROP PRIMARY KEY

La clé primaire n'est pas obligatoire mais elle permet d'identifier une ligne de manière unique donc quand même très utile

Si tu estimes que la colonne data remplit ce rôle pourquoi pas...

[Alexandre T]

Le must créer la table, les index, mettre les index en veille, insérer les données, réactiver les index.

Sinon, insérer des données dans une table indexée est plus lent que dans une table sans index. Par contre l'insertion des index peut-être longue.

Lequel des deux est plus rapide je ne sais pas. Par contre, je préfère savoir toute mes données rapidement dans la base et ensuite mettre les index, plutôt que de verrouiller longtemps la table et risqué un crash (coupure du service) pendant cette longue insertion.

[Ickou]

merci à tout les deux