Annexe D. Port vers d'autres systèmes

Table des matières

D.1. Déboguer un serveur MySQL
D.1.1. Compiler MYSQL pour le débogage
D.1.2. Créer un fichier de tra¸age
D.1.3. Déboguer mysqld sous gdb
D.1.4. Utilisation d'un tra¸age de pile mémoire
D.1.5. Utilisation des fichiers de log pour trouver d'où viennent les erreurs de mysqld
D.1.6. Faire une batterie de tests lorsque vous faites face à un problème de table corrompue
D.2. Débogage un client MySQL
D.3. Le paquet DBUG
D.4. Commentaires à propos des threads RTS
D.5. Différences entre les différents paquets de threads

Cet appendice vous aidera à porter MySQL vers un autre système d'exploitation. Vérifiez d'abord la liste des systèmes supportés avant toute chose. See Section 2.1.1, « Systèmes d'exploitation supportés par MySQL ». Si vous avez crée un nouveau port de MySQL, merci de nous en avertir pour que nous puissions le lister ici et sur notre site web (http://www.mysql.com/), pour le recommander aux autres utilisateurs.

Note : Si vous créez un nouveau port de MySQL, vous êtes libre de le copier et le distribuer sous la licence GPL, mais cela ne signifie pas que vous êtes détenteur de droits sur MySQL.

Une bibliothèque de threads Posix qui fonctionne est requise pour le serveur. Pour Solaris 2.5 nous utilisons Sun PThreads (le support natif des threads de la version 2.4 et plus ancienne n'est pas assez bonne) et sur Linux nous utilisons LinuxThreads de Xavier Leroy, .

La partie la plus difficile du port vers une nouvelle variante Unix ne bénéficiant pas d'un bon support natif des threads est probablement le port de MIT-pthreads. Voyez mit-pthreads/README et Programming POSIX Threads (http://www.humanfactor.com/pthreads/).

La distribution MySQL inclut une version patchée des Pthreads de Provenzano de MIT (voyez la page web des Pthreads MIT http://www.mit.edu/afs/sipb/project/pthreads/ et une introduction à la programmation sur http://www.mit.edu:8001/people/proven/IAP_2000/). Cela peut être utilisé pour certains systèmes d'exploitation à qui n'ont pas les threads POSIX. See Section 2.4.5, « Notes relatives aux MIT-pthreads ».

Il est aussi possible d'utiliser un autre paquet de threads au niveau utilisateur nommé FSU Pthreads (Voir http://moss.csc.ncsu.edu/~mueller/pthreads/). Cette implémentation est utilisée pour le port vers SCO.

Consultez les programmes thr_lock.c et thr_alarm.c dans le dossier mysys pour quelques tests/exemples de ces problèmes.

Le serveur et le client on besoin d'un compilateur C++ fonctionnel (nous utilisons gcc et avons essayé SPARCworks). Un autre compilateur connu maintenant pour fonctionner est Irix cc.

Pour ne compiler que le client, utilisez ./configure --without-server.

Il n'y a actuellement aucun support pour ne compiler que le serveur, et il n'est pas prévu d'en ajouter un à moins que quelqu'un n'ait une bonne raison de le faire.

Si vous voulez ou avez besoin de changer un fichier Makefile ou le script de configuration vous aurez besoin d'avoir Automake et Autoconf. See Section 2.4.3, « Installer à partir de l'arbre source de développement ».

Toutes les étapes dont vous avez besoin pour reconstruire le tout à partir des fichiers de base.

/bin/rm */.deps/*.P
/bin/rm -f config.cache
aclocal
autoheader
aclocal
automake
autoconf
./configure --with-debug=full --prefix='votre dossier installation'

# les fichiers make générés plus haut ont besoin de GNU make 3.75 ou plus récent.
# (appelé gmake ci-dessous)
gmake clean all install init-db

Si vous rencontrez des problèmes avec un nouveau port, vois devrez faire du débogage de MySQL ! See Section D.1, « Déboguer un serveur MySQL ».

Note : avant de commencer à déboguer mysqld, faites d'abord fonctionner les programmes de tests mysys/thr_alarm et mysys/thr_lock. Cela assurera que votre installation des threads a une chance de fonctionner !

D.1. Déboguer un serveur MySQL

Si vous utilisez des fonctionnalités qui ont été ajoutées il y a peu de temps à MySQL, vous pouvez essayer de démarrer mysqld avec --skip-new (qui désactivera toutes les fonctionnalités nouvelles, qui sont potentiellement non-stables) ou avec --safe-mode qui désactive un tas d'optimisations qui pourraient poser problèmes. See Section A.4.2, « Que faire si MySQL plante constamment ? ».

Si mysqld ne veut pas démarrer, vous devez vérifier que vous n'avez pas de fichiers my.cnf qui interfèrent avec votre configuration ! Vous pouvez vérifier les arguments de votre my.cnf avec mysqld --print-defaults et éviter de les utiliser en démarrant avec mysqld --no-defaults ....

Si mysqld se met à trop consommer de mémoire ou de processu ou s'il se bloque, vous pouvez utiliser mysqladmin processlist status pour trouver si quelqu'un utilise une requête qui prend trop de temps à s'exécuter. C'est un bonne idée d'exécuter mysqladmin -i10 processlist status dans un terminal si vous avez des problèmes de performances ou des problèmes à la connexion de nouveaux clients.

La commande mysqladmin debug écrira des informations à propos des verrous en cours d'utilisation, de la mémoire utilisée et des requêtes dans le fichier de log de MySQL. Cela peut vous aider à résoudre certains problèmes. Cette commande fournit aussi des informations utiles même si vous n'avez pas compilé MySQL pour le débogage !

Si le problème vient du fait que certaines tables sont de plus en plus lentes vous devez essayer de les optimiser en utilisant OPTIMIZE TABLE ou myisamchk. See Chapitre 5, Administration du serveur. Vous devez aussi vérifier les requêtes qui prennent trop de temps avec la commande EXPLAIN.

Vous devriez aussi consulter les sections spécifiques aux systèmes d'exploitations dans ce manuel pour les problèmes pouvant être uniques à votre environnement. See Section 2.8, « Notes spécifiques aux systèmes d'exploitation ».

D.1.1. Compiler MYSQL pour le débogage

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.

D.1.2. Créer un fichier 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  ».

D.1.3. Déboguer mysqld sous gdb

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.

D.1.4. Utilisation d'un tra¸age de pile mémoire

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 :

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

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

    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 :

    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 cela ne vous aide pas à trouver pourquoi mysqld a planté, vous devez créer un rapport de bogue et y inclure le résultat de la commande précédente.

    Notez toutefois que dans la plupart de 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 ! See Section 1.4.1.3, « Comment rapporter un bogue ou un problème ».

D.1.5. Utilisation des fichiers de log pour trouver d'où viennent les erreurs de mysqld

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é.

D.1.6. Faire une batterie de tests lorsque vous faites face à un problème de table corrompue

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) tout 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. See Section 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

  • Re-exécutez les commandes avec mysqlbinlog update-log-file | mysql. Le log des mises à jour est 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/ 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.

D.2. Débogage un client MySQL

Pour pouvoir déboguer un client MySQL avec le paquet de débogage intégré, vous devez configurer MySQL avec --with-debug ou --with-debug=full. See Section 2.4.2, « Options habituelles de configure ».

Avant de mettre en marche un client, vous devez définir la variable d'environnement MYSQL_DEBUG :

shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace
shell> export MYSQL_DEBUG

Cela fait générer au client un fichier de tra¸age dans /tmp/client.trace.

Si vous avez un problème avec votre propre code client, vous devez essayer de vous connecter au serveur et exécuter vos requêtes en utilisant un client qui fonctionne. Faites le en utilisant mysql en mode débogage (en supposant que vous ayez compilé MySQL avec le support du débogage) :

shell> mysql --debug=d:t:O,/tmp/client.trace

Il vous fournira des informations utiles si vous voulez envoyer un rapport de bogue. See Section 1.4.1.3, « Comment rapporter un bogue ou un problème ».

Si votre client se plante au niveau d'un code qui vous parait "valide", vous devez vérifier que votre fichier mysql.h inclus correspond à votre bibliothèque MySQL. Une erreur très courante est d'utiliser un vieux fichier mysql.h d'une ancienne installation avec la nouvelle bibliothèque MySQL.

D.3. Le paquet DBUG

Le serveur MySQL et la plupart des clients MySQL sont compilés avec le paquet DBUG écrit, à l'origine, par Fred Fish. Lorsque MySQL est compilé avec le support du débogage, ce paquet permet d'obtenir des fichiers de tra¸age de ce que le programme débogue. See Section D.1.2, « Créer un fichier de tra¸age ».

Le paquet de débogage est utilisé en invoquant le programme avec l'option --debug="..." ou -#....

La plupart des programmes MySQL ont une chaîne de débogage par défaut qui sera utilisée si vous ne spécifiez aucune option à --debug. Le fichier de tra¸age par défaut est usuellement /tmp/nomprogramme.trace sur Unix et \nomprogramme.trace sur Windows.

La chaîne de caractères de controle du débogage est une séquence de champs séparés par des deux-points (:) comme celle qui suit :

<champ_1>:<champ_2>:...:<champ_N>

Chaque champ consiste d'un caractère attribut suivi d'une liste de modificateurs, commen¸ant optionnellement par une virgule ‘,’, séparés par des virgules :

flag[,modificateur,modificateur,...,modificateur]

Les caractères attributs actuellement reconnus sont :

AttributDescription
dActive les sorties des macros DBUG_<N> pour l'êtat courant. Peut être suivi d'une liste de mots clefs, ce qui sélectionne la sortie seuelemnt pour les macros DBUG contenant ces mots. Une liste de mots clefs vides implique les sorties de toutes les macros.
DAttendre après chaque ligne résultante du débogueur. L'argument est le nombre de dixièmme de secondes à attendre, sujet aux capabilités de la machine. Et donc, -#D,20 est une attente de deux secondes.
fLimiter le débogage et/ou le tra¸age aux fonctions citées. Notez qu'une liste nulle désactivera toutes les fonctions. Les attributs appropriés "d" ou "t" doivent quand même être donnés, cet attribut ne limite que leurs actions si ils sont activés.
FIdentifie le nom du fichier source pour chaque ligne de débogage ou de tra¸age affichée.
iIdentifie le processus avec son identifiant pour chaque ligne de débogage ou de tra¸age affichée.
gActive le profiling. Crée un fichier nommé dbugmon.out contenant des informations qui peuvent être utilisées pour profiler le programme. Peut être suivi d'une liste de mots clefs qui sélectionnent le profiling uniquement pour les fonctions présentes dans ctte liste. Une liste nulle implique que toutes les fonctions sont considérées.
LIdentifie le numéro de ligne du fichier source pour chaque ligne renvoyée par le tra¸age ou le débogage.
nImprime le niveau de profondeur de la fonction en cours d'exécution pour la sortie du tra¸age ou du débogage.
NNumérote chaque ligne de la sortie du débogage.
oRedirige le flux de sortie du débogueur vers le fichier spécifié. Par défaut, c'est stderr.
OComme o mais le fichier est vraiement écrit entre chaque ajout de contenu. Lorsque le besoin en est, le fichier est fermé puis réouvert entre chaque écriture.
pLimite les actions du débogueur aux processus spécifiés. Un processus peut être identifié avec la macro DBUG_PROCESS et correspondre à un processus dans la liste pour que le débogage ait lieu.
PAffiche le nom du processus courant pour chaque ligne de sortie de débogage ou de tra¸age.
rLors du passage à un nouvel état, ne pas hériter le niveau de profondeur de l'état de la fonction précédente. Utile lorsque l'affichage commence à la marge gauche.
SExécute la fonction _sanity(_file_,_line_) sur chaque fonction déboguée jusqu'à ce que la valeur de retour de _sanity() diffère de 0. (La plupart du temps utilisée avec safemalloc pour trouver les pertes de mémoire)
tActive le tra¸age des appels/sorties des fonctions. Peut être suivi d'une liste (ne contenant qu'un seul modificateur) donnant un maximum numérique du tra¸age, au delà duquel aucune sortie ne sera affichée pour les macros de débogage ou de tra¸age. Par défaut, c'est une option de temps de compilation.

Quelques exemples de chaînes de controle de débogage pouvant être utilisée en ligne de commande dans le shell ("-#" est typiquement utilisé pour introduire une chaîne de controle à un programme d'application) sont :

-#d:t
-#d:f,main,subr1:F:L:t,20
-#d,input,output,files:n
-#d:t:i:O,\\mysqld.trace

En MySQL, les balises communes affichées (avec l'option d) sont : enter,exit,error,warning,info et loop.

D.4. Commentaires à propos des threads RTS

J'ai essayé d'utiliser le paquet de threads RTS avec MySQL mais je suis resté bloqué au niveau des problèmes suivants :

Ils utilisent une veille version avec beaucoup d'appels POSIX et il est vraiment difficile de créer une couche d'abstraction pour toutes les fonctions. Je pense qu'il serait plus facile de changer la bibliothèque des threads pour qu'elle suive les nouvelles spécifications POSIX.

Quelques couches d'abstractions sont déjà écrites. Voyez mysys/my_pthread.c pour plus d'informations.

Au minimum, ce qui suit devra être changé :

pthread_get_specific doit utiliser un seul argument. sigwait doit prendre deux arguments. Beaucoup de fonctions (du moins pthread_cond_wait, pthread_cond_timedwait) doivent retourner le code erreur lorsqu'elles en rencontrent. Elle retournent à présent -1 et définissent errno.

Un autre problème est que les threads au niveau utilisateurs utilisent les signaux ALRM et que ceux-ci fait échouer beaucoup de fonctions (read, write, open...). MySQL devrait faire une autre tentative à chaque interruption mais cela n'est pas facile à vérifier.

Le plus gros problème non-résolu est le suivant :

Pour avoir des alertes au niveau des threads, j'ai changé mysys/thr_alarm.c pour avoir une attente entre les alarmes avec pthread_cond_timedwait(), mais cela échoue avec une erreur EINTR. J'ai essayé de déboguer la bibliothèque des threads pour voir d'où cela venait, mais je n'ai pu trouver aucune solution simple.

Si quelqu'un veut utiliser MySQL avec les threads RTS je suggère ce qui suit :

  • Changez les fonctions que MySQL utilise à partir de la bibliothèque des threads en POSIX. Cela ne devrait pas vous prendre beaucoup de temps.

  • Compilez toutes les bibliothèques avec -DHAVE_rts_threads.

  • Compilez thr_alarm.

  • S'il y a de petites différences dans l'implémentation, elles peuvent être corrigées en changeant les fichiers my_pthread.h et my_pthread.c.

  • Exécutez thr_alarm. S'il tourne sans aucun message du type ``warning'', ``error'' ou ``aborted'', vous êtes sur le bon chemin. Voici une bonne exécution se déroulant sur Solaris :

    Main thread: 1
    Thread 0 (5) started
    Thread: 5  Waiting
    process_alarm
    Thread 1 (6) started
    Thread: 6  Waiting
    process_alarm
    process_alarm
    thread_alarm
    Thread: 6  Slept for 1 (1) sec
    Thread: 6  Waiting
    process_alarm
    process_alarm
    thread_alarm
    Thread: 6  Slept for 2 (2) sec
    Thread: 6  Simulation of no alarm needed
    Thread: 6  Slept for 0 (3) sec
    Thread: 6  Waiting
    process_alarm
    process_alarm
    thread_alarm
    Thread: 6  Slept for 4 (4) sec
    Thread: 6  Waiting
    process_alarm
    thread_alarm
    Thread: 5  Slept for 10 (10) sec
    Thread: 5  Waiting
    process_alarm
    process_alarm
    thread_alarm
    Thread: 6  Slept for 5 (5) sec
    Thread: 6  Waiting
    process_alarm
    process_alarm
    
    ...
    thread_alarm
    Thread: 5  Slept for 0 (1) sec
    end
    

D.5. Différences entre les différents paquets de threads

MySQL est très dépendant du paquet de threads utilisé. Ce qui fait que lors du choix d'une bonne plate-forme pour MySQL, le paquet des threads est très important.

Il y a au moins trois types de paquets de threads :

  • Threads utilisateurs dans un processus unique. Le changement de threads est géré avec des alarmes et la bibliothèque des threads gère les fonctions non-utilisables avec les threads par des verrouillages. Les opérations de lectures, d'écritures et de sélections sont usuellement gérées avec une sélection spécifique aux threads qui passe à un autre thread si celui en cours d'exécution attend des données. Si les paquets des threads utilisateurs sont intégrés dans les bibliothèques standards (threads FreeBSD et BSDI) le paquet de thread nécessite moins de ressources que les paquets de thread qui doivent mapper toutes les appels non-sûrs (MIT-pthreads, FSU Pthreads et RTS threads). Avec quelques environnements, (SCO par exemple), tous les appels système sont sûrs pour les threads, ce qui fait que la liaison peut se faire très facilement (Pthreads FSU sur SCO). Mauvais côté : Tous les appels mappés prennent un peu de temps, et il est assez difficile de pouvoir gérer toutes les situations. Il y a aussi souvent des appels système qui ne sont pas gérés par le paquet de threads (comme MIT-pthreads et les sockets). La gestion des threads n'est pas toujours optimale.

  • Threads utilisateurs dans des processus séparés. Les changements de threads sont effectués par le noyau et toutes les données sont partagées entre les threads. Le paquet de thread gère les appels threads standards pour permettre le partage entre les threads. LinuxThreads utilise cette méthode. Mauvais côté : Beaucoup de processus. La création des threads est lente. Si un thread s'interrompt, les autres restent en suspens et vous devez tous les terminer avant de redémarrer. Le changement de thread est d'une certaine fa¸on consommateur de ressources.

  • Threads noyau. Le changement de threads est géré par la bibliothèque de threads ou le noyau est très rapide. Tout est fait en un seul processus, mais sur certains systèmes, ps peut montrer plusieurs threads. Si un thread échoue, tout le processus échoue. La plupart des appels système sont bons pour les threads et ne devraient avoir besoin que d'une petite perte de performances. Solaris, HP-UX, AIX et OSF/1 ont des threads noyau.

Avec quelques systèmes, les threads du noyau sont gérés en intégrant les threads niveau utilisateur dans les bibliothèques du système. Dans ces cas, le changement de thread ne peut être fait qu'avec la bibliothèque de threads et le noyau n'est pas vraiment ``attentif aux threads''.


This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.