Mise à jour de 5.0.27 à 5.0.37

[xavierB]

Bonjours à tous,

J'ai l'habitude d'installer et de mettre à jour mysql avec les binaires de la rubrique
"Linux non RPM packages" (mysql-standard-5.0.x-linux-i686-glibc23.tar.gz).

Je ne parviens pas à passer à la version 5.0.37. La procédure est la suivante :
- arrêt du serveur (mysql.server stop)
- sauvegardes
- décompression de l'archive
- lancement du serveur (mysql.server start)
Des threads mysql sont bien créés, mais pas mysql.sock ni le fichier pid. Le script mysql.server termine simplement par : "fail"
Le fichier log indique "mysqld started" sans aucune autre information.

J'ai remarqué que le premier thread lancé l'est sous l'utilisateur mysql, alors que les autres le sont sous l'utilisateur root. Avec la version 5.0.27, tous les threads sont mysql.

Quelqu'un a-t-il une idée ?

Merci d'avance
Xavier

[Sivrît]

Le log des erreurs ne donne vraiment rien ? Si le serveur s'arrête sans rien dire c'est un bug (de ne rien dire du moins !).

Est-ce que les fichiers de données ont été conservés entre les deux versions ? Peut-être qu'il s'étouffe avec les fichiers de l'ancienne version.

Sinon il y a la possibilité que l'utilisateur mysql n'ait pas les droits pour créer mysql.sock. Sa position est-elle spécifiée explicitement (des fois que l'emplacement par défaut ait changé) ?

Est-ce que l'ancien mysql.server avait été modifié ? Est-il possible de faire un diff entre ancien et nouveau ?


Dernière idée qui me vient : utiliser "sh -x" pour lancer le script (ce sera pt plus causant que "fail").

Bonne chance.

[xavierB]

Merci Sivrît de ton écoute :-)

Envoyé par Sivrît

Le log des erreurs ne donne vraiment rien ?

La seule ligne inscrite dans ce fichier est "mysqld started", c'est effectivement très léger. Avec les versions passées, j'avais toujours plusieurs messages que le démarrage se soit bien passé ou non.

Envoyé par Sivrît

Si le serveur s'arrête sans rien dire c'est un bug (de ne rien dire du moins !).

C'est mon sentiment. En fait, il ne s'agit pas forcement d'un bug au niveau des sources mysql, mais peut être d'un défaut dans le build. J'ai fait de nombreuses recherches d'où je peux ressortir 2 petites informations :
- à partir de la 5.0.37, les modalités de fabrication du build sont différentes, elles incluent dans un même package ce qui auparavant se trouvait dans 2 packages distincts (standard et debug)
- une intervention sur un forum semble indiquer un cas similaire, d'ou il ressortirait que le problème est au niveau du build. Le seul contournement semble consister à compiler soit même son propre build. Le problème a fait l'objet du rapport #28210 : http://bugs.mysql.com/bug.php?id=28210

Malheureusement j'ai essayé avec la mise à jour 5.0.41 qui conduit exactement au même résultat. J'en conclut qu'il s'agit plus d'un changement dans la méthodologie de compilation des builds, que d'un problème ponctuel de la 5.0.37

Envoyé par Sivrît

Est-ce que les fichiers de données ont été conservés entre les deux versions ? Peut-être qu'il s'étouffe avec les fichiers de l'ancienne version. !).

Oui mêmes fichiers de données. J’avais à ce sujet relu consciencieusement les instructions de mise à jour. Le changement de version mineur ne nécessite habituellement pas d’intervention sur les données. Pour les versions majeures les mises à jour de données se font juste après démarrage du serveur, et avant l’exploitation des bases bien sur. Je suis persuadé que les données n’ont pas à voir avec le problème, je pense que les threads lancés n’ont pas encore été voir les données.

Envoyé par Sivrît

Sinon il y a la possibilité que l'utilisateur mysql n'ait pas les droits pour créer mysql.sock. Sa position est-elle spécifiée explicitement (des fois que l'emplacement par défaut ait changé) ?

Oui c’est bien ce qui vient à l’esprit. J’ai bien vérifié, et j’ai été attentif a ce que les différents répertoires ne changent ni de propriétaire ni de droits durant mes différents tests 5.0.27 -> 5.0.37 -> 5.0.27.
La position de mysql.sock est explicite dans le fichier de configuration (et sans changement entre 5.0.27 et 5.0.37).
En supprimant les fichiers innoDB, j’ai constaté que ceux-ci sont bien créés dans le bon répertoire (position et droits sont donc corrects). Je me suis également livré à un autre test. J’ai ajouté à ma ligne de commande l’option –-debug (le build est supposé maintenant l’accepter). Dans ce cas j’ai une ligne supplémentaire d’erreur dans le log indiquant que l’option n’est pas valide. En revanche les fichiers mysql.sock et mysql.pid sont cette fois bien créés, mais le serveur ne fonctionne pas plus. C’est assez déroutant.

Envoyé par Sivrît

Est-ce que l'ancien mysql.server avait été modifié ? Est-il possible de faire un diff entre ancien et nouveau ?

Je m’étais également posé cette question : oui le script a évolué. Je ne suis pas vraiment capable de comprendre les différences entre les 2 versions. A tout hasard j’ai essayé de lancer le server 5.0.37 avec le script de la 5.0.27, sans nouveauté apparentes (sauf le time out).

Envoyé par Sivrît

Dernière idée qui me vient : utiliser "sh -x" pour lancer le script (ce sera pt plus causant que "fail").

Ah ? je ne connais pas cette commande, je vais me documenter. Merci Sivrît.

Envoyé par Sivrît

Bonne chance.

Pffff, si seulement il s’agissait de chance. :-)

[Sivrît]

Ben là j'en perd un peu mon Latin (pas trop grave je ne le parle pas )

Reste peut-être à s'incruster dans mysql.server ou mysqld_safe afin de logger/afficher les options qui sont réellement passées. Et avec ces options il sera possible d'appeler mysqld_safe à la main pour avoir son retour et éventuellement jouer avec les options.
Je ne sais pas si recommencer avec mysqld directement a un intéret...

Sinon autre possibilité, l'archive en glibc23 est liée dynamiquement. En cas de doute il est possible de télécharger la version liée statiquement. Ne connaissant pas les symptômes en cas de pb de lib je ne sais pas si ça correspond.


Après je vais aller chercher une corde.

[xavierB]

Sans aller chercher une corde, je crois que je vais laisser tomber pour l'instant.

J'utilisais avant le build lié statiquement à glibc23, mais en passant à PHP 5.1.6 il y a quelque temps, ce dernier refusait le redémarrage d'apache. Le problème disparaissait en employant l'archive mysql incorporant la liaison dynamique à glibc23. D'ou ma situation actuelle.

Il y peut-être quelque chose sur ma machine qui n'est pas suffisamment à jour pour les derniers builds. Dans ce cas, il faudrait je fasse moi même la compilation, ou que je reparte sur une installation neuve.

Sinon j'ai essayé "sh -x" comme suggéré par Sivrît, les différences entre le lancement de la 5.0.27 et 5.0.37 ne me donne pas d'indice clair. Il se peut bien que ce sujet sollicite les limites de mes compétences actuelles...

Bref les interdépendances entre composants logiciels sont fortes sous linux, et loin d'être simple à détecter. Du coup les mises à jour a priori banales ne coulent pas de source.