Bonjour. Je ne sais pas ce qui s'est passé?
J'ai voulu utilise mysql41
Le serveur à bloqué
 
Après bien des recherches j'ai fini par désinstaller, renommer la table mysql
puis réinstaller
 
voici le message que j'ai eu avec urpmi
 

 
 
donc si je continue.
 

 
 
Le problème est comment retirer ces entrées?

DELETE from nom-de-ta-table;
 
efface les données de la table concernée

Le probleme est que j'ai 12 bases de donnée et une centaine de tables et que tout marchait bien. Peut-on faire une identification ?

J'ai crée une directory mysql. J'y ai mis seulement la table mysql
J'ai toujours le même problème ......

memaster62 > j'ai retiré toutes les tables.
J'ai supprimé /var/lib/mysql
J'ai désinstallé mysql41
 
J'ai réinstallé
J'ai toujours le problème.  je suis vert

Donnes des infos sur ta conf ça pourrait aider !
Et ton mysql, tu l'installes comment ? C'est un paquetage de ta distrib ?

Personnellement je pense qu'il suffit de lire le message d'erreur pour comprendre ce qui se passe.

Edit: je pensais bien avoir vu un pb lié pas loin, c'est toi qui posait la question pour désinstaller Mysql dans un autre topic!

Si tu es sous Mandriva 2007, tu devrais démarrer mysql par le script approprié plutot que de le lancer "à la gorêt":
/etc/init.d/mysqld start

Oui j'ai un autre fil ouvert pour en principe examiner un problème avec java, mais tout de suite après, j'ai eu ce nouveau problème avec mysql. Ca fait un peu double emploi mais c'est provisoire.
Je reviens à mysql.  
C'est le package installé avec urpmi mysql41 ( version 4 )  
Voici les messages:

 
En root:

 
Je peux ajouter
 
Je n'ai pas d'autre mysqld qui tourne. Voici les fichiers qu'il y a dans /var/lib/mysql/
 
/var/lib/mysql/mysql.sock = 0octet
ib_logfile0 = 5Mo
ib_logfile1 = 0octets
ibdata1 = 10 Mo
 

 
mysqld n'est pas une methode goret mais plutot un mode debug.  
 
Voila ou j'en suis pour l'instant.

A tout hasard. J'ai essayé d'installer bind puisque mysqld en parle .
# rpm -qa | grep bind

Mais ça ne change rien.

 
installer bind ça sert à rien, "binder" c'est se lier à un port. En l'occurence un autre programme l'utilise déjà.. probablement un mysql
 
et mysql il faut le lancer avec les droits de l'utilisateur mysql (ou mysqld_safe en root et il passera le reste en utilisateur mysql tout seul)

Effectivement ça change de message. Mais peut-être pourrais-tu comprendre ce qui ce passe.
 
# mysqld_safe

 
C'est quoi les "pid"

process identification,

Je crois qu'on arrive.
# cd /var/run/mysqld/
 
# ls
#
 
Le fichier n'existe pas.

c'est normal qu'il n'existe pas si mysql server n'est pas lancé.
c'est un fichier temporaire dans lequel le init inscrit le numero d'identification du processus (le pid) de mysqld.
tout ce qui est dans /var/run sers à identifier les processus lancés quelsqu'ils soient.
 
il faut que tu touches un peu au system pour comprendre...

Ca explique pourquoi la derniere experience m'a surpris
J'ai créé un mysqld.pid artificiel.
J'ai tenté de démarré mysqld
Mon fichier à disparu.
 
Donc tout est correct sauf que ça ne démarre pas.  
 
Il y aurait une autre instance mysql déja démarrée mais si je fais un "ctrl+esc" sur kde je ne trouve rien dans tout ce qui est lancé qui ressemble à mysql

c'est possible que tu ai deja un mysql server qui demarre au boot de ta machine.
pour le savoir essaye :
#service mysqld status
ou
#service mysql status
ou
regarde un netstat si le port 3306 est en ecoute via cette commande
#netstat -laputen
qui te donnera toutes les liaisons entre les ports en ecoute et les demons qui s'en servent.

Un truc que je découvre.
 
# service mysqld status

 
# netstat -laputen | grep 3306
#  
Personne sur ce port

le pb peut provenir de mysql.sock (le fichier de verrouillage), il se trouve dans /var/lib/mysql
autrement dit ton nouveau processus de mysqld ne parvient pas à faire ce qu'il veut avec ce fichier,
peut être n'a t'il pas le droit d'ecrire dedans ou quelquechose comme ça. c'est pour ça également
que le systeme croit qu'il y a deja un mysql de demarré sur le systeme, c'est à cause
de ce fichier de sock (p'tain de chaussettes )
 
tu peux essayer d'editer le fichier /etc/my.cnf (deja essaye de comprendre
à quoi sers ce fichier la, il est très bien documenter un peu partout) pour donner un autre nom à ce fichier mysql.sock afin
que ton instance soit complètement nouvelle.

my.cnf me renvoie vers un fichier de logs.
J'ai donc visité le fichier en question
/var/log/mysqld/mysqld.log
 
 

 
J'ai donc vérifié la directory.
# ls -lF /root
total 8
drwx------ 2 root root 4096 oct  9 19:46 drakx/
drwxrwxrwx 2 root root 4096 oct 30 10:35 tmp/
 
Connais-tu l'erreur 13

et on voit clairement que mysqld ne peut pas créer de répertoire tmp dans /root,
ce qui me semble une erreur "normale".
il faut que tu te "debrouilles" pour demander au script de mysqld (via le fichier /etc/my.cnf)
d'aller créer mysql.sock quelquepart où il aura les droits de faire ce qu'il veut.
 
edit : ton mysqld ne demarre pas avec les droits root mais avec les droits d'un utilisateur nommé mysql.
surtout ne donne pas les droits à mysql d'aller ecrire quelquechose dans /root (attention à la faille de secu ).

Se pourrait-il que mysqld ne se serve pas de my.cnf.  ?
Je m'explique.
La directory /root/tmp/  n'existe pas dans my.cnf

bah, c'est possible, il faut regarder le script de demarrage du deamon
dans /etc/rc.d/init.d
mais je dirais normalement, il doit l'utiliser  
 
et effectivement, on se demande bien ce qu'il fait comme acces dans /root/tmp
 
essaye alors d'activer le demarrage de mysqld au boot de linux (dans les options de service)
et regarde à nouveau le mysql.log

c'est énervant lorsque l'on dit à quelqu'un de ne pas lancer mysql directement avec mysqld, et que dans un autre topic il le fait ...
 
tu jeterais un oeil au script de démarrage et tu verrais que pas mal de choses et paramètres sont fournient à mysqld, et que lancer sans ces paramètres ne peut que créer la confusion ...
 
tu essayes d'aller trop vite thierryR et tu fais pleins de bétises ...

le deamon dans /etc/rc.d/init.d  fait bien appel à my.cnf et en aucun cas on ne parle de /root/tmp/
 
voici ce qui se passe au démarrage
 

 
dans /var/lib/mysql/  j'ai ib_logfile0 de 5Mo
et                                    ib_logfile1 de 0 octet

     Ca y est ça marche
 
J'ai viré ibdata1, ib_logfile0 et ib_logfile1
J'ai redémaré et tout fonctionne.
Ce sont 3 fichiers binaire qui sont générés automatiquement.
 
Merci a tous les contributeurs de ce fil.

Tu devrais peut être modifier my.cnf et virer log-bin=mysql-bin
 

Ben.... Je ne le trouve pas dans le fichier

c'est pour mysql 5 alors, c'est vrai que tu utilises mysql4

Bizarre. Suite à la suppression ils se sont recréés !  Je ne sais pas à quoi ils servent si ce n'est faire un beau blocage...

c'est bien mysql4 que tu utilises ?
 
tu éteins correctement mysql avec la commande "service", et tu lances mysql avec al commande "service" ? ou avec /etc/initd.d/mysql ?
 
http://mysql.org/doc/refman/4.1/en/binary-log.html

C'est pas le 4 mais pas le 5  
$ rpm -qa | grep -i mysql

excuse mais tu utilises mysql 4 ...
à part libmysql15, tout le reste concerne mysql 4.1

C'est la 4.1 qui doit être abandonnée officiellement, parait-il.
On a donc un service mysqld  que la 4 n'a pas.
Vu mes nombreux déboires, je ne pense pas me tromper entre les versions.
 
Et pour libmysql15 regarde ....
# urpme libmysql15-5.0.24a-2mdv2007.0