Manuel de référence MySQL 5.0

Si vous avez un problème spécifique, vous pouvez toujours essayer de déboguer MySQL. Pour ce faire, vous devez configurer MySQL avec l'option --with-debug ou --with-debug=full. Vous pouvez vérifier si MySQL est déjà compilé avec le support du débogage en faisant ceci : mysqld --help. Si l'attribut --debug est listé avec les options, cela veut dire que le support du débogage est activé. Dans ce cas, mysqladmin ver liste aussi la version de mysqld en tant que mysql ... --debug.

Si vous utilisez gcc ou egcs, la ligne de configuration recommandée est :

CC=gcc CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors \
   -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \
   --with-debug --with-extra-charsets=complex

Cela évitera les problèmes avec la bibliothèque libstdc++ et les exceptions C++ (plusieurs compilateurs ont des problèmes avec les exceptions C++ dans le code threadé) et compilera une version MySQL avec le support de tous les jeux de caractères.

Si vous suspectez un dépassement de la mémoire, vous pouvez configurer MySQL avec --with-debug=full, qui installera un vérificateur d'allocation mémoire (SAFEMALLOC). Fonctionner avec SAFEMALLOC est cependant un peu ralentissant, et donc, si vous rencontrez des problèmes de performances, vous devez démarrer mysqld avec l'option --skip-safemalloc. Cela désactivera les vérifications de dépassements de mémoire pour chaque appel à malloc ou free.

Si mysqld ne plante plus lorsque vous le compilez avec --with-debug, vous avez probablement trouvé un bogue du compilateur ou un bogue de temporisation dans MySQL. Dans ce cas, vous pouvez essayer d'ajouter -g aux variables CFLAGS et CXXFLAGS vues plus haut et ne pas utiliser --with-debug. Si mysqld plante maintenant, vous pouvez vous y attacher avec gdb ou utiliser gdb sur le fichier noyau pour trouver ce qui est arrivé.

Lorsque vous configurez MySQL pour le support du débogage, vous activez automatiquement un tas de fonctions de tests supplémentaires qui se chargent de surveiller le bon fonctionnement de mysqld. Si elles trouvent quelque chose d'inattendu (« unexpected »), une entrée sera écrite dans stderr, que safe_mysqld redirige vers le log d'erreurs ! Cela signifie aussi que si vous avez quelques problèmes inattendus avec MySQL et que vous utilisez une distribution des sources, la première chose à faire est de configurer MySQL avec le support du débogage (la seconde, bien sûr, étant d'envoyer un mail sur les listes de diffusion pour demander de l'aide) ! Voir Section 1.4.1.1, « Les listes de diffusion de MySQL »1.4.1.1. Les listes de diffusion de MySQL. Merci d'utiliser le script mysqlbug pour tous les rapport de bogues ou questions concernant la version de MySQL que vous utilisez !

Dans la distribution Windows de MySQL, mysqld.exe est par défaut compilé avec le support des fichiers de traçage.

Si le serveur mysqld ne démarre pas ou que vous pouvez le crasher facilement, vous pouvez essayer de créer un fichier de traçage pour trouver le problème.

Pour ce faire, vous devez avoir un mysqld qui est compilé pour le débogage. Vous pouvez le vérifier en exécutant mysqld -V. Si le numéro de version se termine par -debug, il est compilé avec le support des fichiers de traçage.

Démarrez le serveur mysqld avec un journal de suivi dans /tmp/mysqld.trace (ou C:\mysqld.trace sous Windows) :

shell> mysqld --debug

Sous Windows vous devez aussi utiliser l'option --standalone pour ne pas démarrer mysqld en tant que service.Dans une console DOS entrez :

mysqld --debug --standalone

Après cela, vous pouvez utiliser l'outil en ligne de commande mysql.exe dans une seconde fenêtre pour reproduire le problème. Vous pouvez couper le serveur avec la commande mysqladmin shutdown.

Notez que le fichier de traçage deviendra très gros ! Si vous voulez obtenir un fichier plus petit, utilisez ce qui suit, par exemple :

mysqld --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace

qui n'écrit que les informations les plus intéressantes.

Si vous créez un rapport de bogue, merci de n'envoyer que les lignes du fichier de traçage où le problème se concrétise à la liste de diffusion appropriée ! Si vous n'arrivez pas à trouver le bon endroit dans le fichier, vous pouvez envoyer la totalité du fichier ainsi que le rapport de bogue via FTP à ftp://support.mysql.com/pub/mysql/secret/ [ftp://support.mysql.com/pub/mysql/secret/] pour qu'un développeur MySQL y jette un coup d'œil.

Le fichier de traçage est généré avec le paquet DBUG de Fred Fish. Voir Section D.3, « Le paquet DBUG »D.3. Le paquet DBUG .

Sur la plupart des systèmes, vous pouvez démarrer mysqld à partir de gdb pour obtenir plus d'informations si mysqld plante.

Avec quelques anciennes versions de gdb sous Linux vous devez exécuter run --one-thread si vous voulez être capable de déboguer les threads de mysqld threads. Dans ce cas, vous ne pouvez n'avoir qu'un thread actif à la fois. Nous vous recommandons de mettre à jour gdb à la version 5.1 dès que possible, vu que le débogage des threads fonctionne mieux avec cette version !

Lors de l'utilisation de mysqld sous gdb, vous devez désactiver le traçage de la pile avec -skip-stack-trace, pour pouvoir trouver les erreurs de segmentations avec gdb.

Il est très difficile de déboguer MySQL sous gdb si vous effectuez plusieurs nouvelles connexions tout le temps, vu que gdb ne libère pas la mémoire occupée par les anciens threads. Vous pouvez contourner ce problème en démarrant mysqld avec -O thread_cache_size= 'max_connections +1'. Dans la plupart des cas, le simple fait d'utiliser -O thread_cache_size=5' vous aidera beaucoup !

Si vous voulez obtenir un core dump sur Linux, si mysqld se termine avec un signal SIGSEGV, vous pouvez démarrer mysqld avec l'option --core-file. Ce fichier noyau peut être utilisé pour effectuer des traçages qui peuvent vous aider à trouver pourquoi mysqld s'est terminée :

shell> gdb mysqld core
gdb>   backtrace full
gdb>   exit

Voir Section A.4.2, « Que faire si MySQL plante constamment ? »A.4.2. Que faire si MySQL plante constamment ?.

Si vous utilisez gdb 4.17.x ou plus récent sous Linux, vous devez installer un fichier .gdb, avec les informations suivantes, dans votre répertoire courant :

set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint

Si vous rencontrez des problèmes lors du débogage des threads avec gdb, vous devez obtenir la version 5.x de gdb et essayer cela à la place. La nouvelle version de gdb a une meilleur gestion des threads !

Voilà un exemple de comment déboguer mysqld :

shell> gdb /usr/local/libexec/mysqld
gdb> run
...
backtrace full # A faire lorsque mysqld crashe

Incluez la sortie suivante dans un mail généré avec mysqlbug et envoyez-le sur les listes de diffusion. Voir Section 1.4.1.1, « Les listes de diffusion de MySQL »1.4.1.1. Les listes de diffusion de MySQL.

Si mysqld ne répond plus, vous pouvez utiliser des outils système tel que strace ou /usr/proc/bin/pstack, pour savoir où mysqld s'est bloqué.

strace /tmp/log libexec/mysqld

Si vous utilisez l'interface DBI de Perl, vous pouvez activer le débogage en utilisant la méthode trace ou en définissant la variable d'environnement DBI_TRACE.

Sur quelques systèmes d'exploitation, le log d'erreurs contiendra un fichier de pile mémoire, si mysqld se termine soudainement. Vous pouvez utiliser ceci pour trouver où (et peut-être pourquoi) mysqld s'est terminé. Voir Section 5.9.1, « Le log d'erreurs »5.9.1. Le log d'erreurs. Pour obtenir un traçage de la pile, vous ne devez pas compiler mysqld avec l'option -fomit-frame-pointer de gcc. Voir Section D.1.1, « Compiler MYSQL pour le débogage »D.1.1. Compiler MYSQL pour le débogage.

Si le fichier d'erreurs contient quelque chose qui ressemble à ce qui suit :

mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attemping backtrace. You can use the following information to find out
where mysqld died.  If you Voir no messages after this, something went
terribly wrong
stack range sanity check, ok, backtrace follows
0x40077552
0x81281a0
0x8128f47
0x8127be0
0x8127995
0x8104947
0x80ff28f
0x810131b
0x80ee4bc
0x80c3c91
0x80c6b43
0x80c1fd9
0x80c1686

vous pouvez trouver où s'est terminé mysqld en exécutant :

1. Copiez les nombres précédents dans un fichier, mysqld.stack, par exemple ;

2. Créez un fichier symbolique pour le serveur mysqld :

    

   Sélectionnez

   nm -n libexec/mysqld > /tmp/mysqld.sym

   Notez que beaucoup de distributions binaires MySQL fournissent le fichier précédent, nommé mysqld.sym.gz. Dans ce cas, décompressez-le en faisant :

    

   Sélectionnez

   gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym

3. Exécutez resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack.
   Cela affichera l'endroit où mysqld a planté. Si ce n'est pas le cas, vous devrez créer un rapport de bogue et y inclure le résultat de la commande précédente.
   Notez toutefois que dans la plupart des cas le fait de n'avoir que le traçage de la pile ne nous aidera pas à trouver d'où vient le problème. Pour être capable de trouver le bogue, ou fournir une parade, nous aurons besoin dans la plupart des cas, nous aurons besoin de connaître la requête qui a fait planter mysqld et une batterie de tests pour que nous puissions reproduire le problème ! Voir Section 1.4.1.3, « Comment rapporter un bogue ou un problème »1.4.1.3. Comment rapporter un bogue ou un problème.

Notez qu'avant de démarrer mysqld avec --log vous devez vérifier toutes vos tables avec myisamchk. Voir Chapitre 5, Administration du serveurChapitre 5. Administration du serveur.

Si mysqld se termine ou se bloque, vous devez démarrer mysqld avec --log. Lorsque mysqld se termine à nouveau, vous pouvez examiner la fin de votre fichier de log pour trouver les requêtes qui ont terminé mysqld.

Si vous utilisez --log sans spécifier un nom de fichier, le log est enregistré dans le dossier des bases de données en tant que host_name.log. Dans la plupart des cas, c'est la dernière requête dans le fichier de log qui a terminé mysqld, mais si possible, vérifiez le en redémarrant mysqld et en exécutant à nouveau la requête en question à partir du client en ligne de commande mysql. Si elle fonctionne, vous devez aussi tester les autres requêtes complexes qui n'ont pas abouti.

Vous pouvez aussi utiliser la commande EXPLAIN sur toutes vos requêtes SELECT qui prennent beaucoup de temps à s'exécuter, pour être sûrs que mysqld utilise les index convenablement. Voir Section 7.2.1, « Syntaxe de EXPLAIN (Obtenir des informations sur les SELECT) »7.2.1. Syntaxe de EXPLAIN (Obtenir des informations sur les SELECT).

Vous pouvez trouver les requêtes qui prennent trop de temps à s'exécuter en démarrant mysqld avec --log-slow-queries. Voir Section 5.9.5, « Le log des requêtes lentes »5.9.5. Le log des requêtes lentes.

Si vous trouvez le texte mysqld restarted dans le log d'erreurs (normalement nommé hostname.err) vous avez probablement trouvé une requête qui fait planter mysqld. Si tel est le cas, vous devez vérifier toutes vos tables avec myisamchk (voir Chapitre 5, Administration du serveurChapitre 5. Administration du serveur), et tester les requêtes dans les fichiers de log MySQL pour voir si elles ne fonctionnent toujours pas. Si vous trouvez une requête de ce genre, essayez d'abord de mettre à jour votre version de MySQL en prenant la version la plus récente. Si cela ne vous aide pas et que vous ne pouvez trouver d'aide dans les archives des mails de mysql, vous devez reporter ce bogue sur les listes de diffusion. Des liens vers les archives de mails sont disponibles en ligne à l'adresse suivante : http://lists.mysql.com/.

Si vous avez démarré mysqld avec myisam-recover, MySQL vérifiera et essayera automatiquement de réparer les tables MyISAM, si elles sont marquées comme « not closed properly » ou « crashed ». Si cela arrive, MySQL ajoutera une entrée dans le fichier hostname.err 'Warning: Checking table ...' qui sera suivie de Warning: Repairing table, si la table devait être réparée. Si vous obtenez beaucoup de ces erreurs, sans que mysqld n'ait planté juste avant, alors quelque chose ne va pas et une enquête plus approfondie est nécessaire. Voir Section 4.3.1, « Options de ligne de commande de mysqld »4.3.1. Options de ligne de commande de mysqld.

Ce n'est bien sûr pas de bon augure si mysqld a crashé, mais dans ce cas, il ne faut pas s'attarder sur les messages Checking table... mais plutôt essayer de savoir pourquoi mysqld a crashé.

Si vos tables sont corrompues ou que mysqld échoue toujours avec quelques commandes de mises à jour, vous pouvez tester si le bogue est reproductible en effectuant ce qui suit :

• coupez le démon MySQL (avec mysqladmin shutdown) ;
• créez une copie de vos tables (pour prévoir le cas très improbable ou la réparation tournerait mal) ;
• vérifiez toutes les tables avec myisamchk -s base/*.MYI. Réparez toute table corrompue avec myisamchk -r base/table.MYI ;
• créez une seconde copie des tables ;
• effacez (ou déplacez) tous les vieux fichiers de log du répertoire de données de MySQL si vous avez besoin de plus d'espace ;
• démarrez mysqld avec --log-bin. Voir Section 5.9.4, « Le log binaire »5.9.4. Le log binaire. Si vous voulez trouver une requête qui fait planter mysqld, vous devez utiliser --log -log-bin ;
• lorsque vous obtenez une table corrompue, stoppez le serveur mysqld ;
• restaurez les sauvegardes ;
• redémarrez le serveur mysqld sans --log-bin ;
• réexécutez les commandes avec mysqlbinlog update-log-file | mysql. Le log des mises à jour est sauvegardé dans le dossier des données de MySQL avec le nom hostname-bin.# ;
• si les tables sont à nouveau corrompues ou que vous pouvez faire échouer mysqld avec la commande précédente, vous avez trouvé un bogue reproductible qui devrait être facile à corriger ! Envoyez les tables et le log binaire via FTP à ftp://support.mysql.com/pub/mysql/secret/ [ftp://support.mysql.com/pub/mysql/secret/] et envoyez un mail à <>, ou (si vous êtes client du support) à <> à propos du problème et l'équipe MySQL le corrigera le plus vite possible.

Vous pouvez aussi utiliser le script mysql_find_rows pour n'exécuter que quelques requêtes de mises à jour si vous voulez mieux cerner le problème.