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. ) See Section 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/ pour qu'un développeur MySQL y jette un coup d'oeil.

Le fichier de tra¸age est généré avec le paquet DBUG de Fred Fish. See Section 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 capables 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

See Section 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. See Section 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é. See Section 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. See Section 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 see 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 ce qui suit :

Notez qu'avant de démarrer mysqld avec --log vous devez vérifier toutes vos tables avec myisamchk. See Chapitre 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 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 abouties.

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. See Section 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. See Section 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 (see Chapitre 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. See Section 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 :

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.