Annexe D. Port vers d'autres systèmes
Précédent |  | Suivant

## Annexe D. Port vers d'autres systèmes

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, `<Xavier.Leroy@inria.fr>`.

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 à `<bugs@lists.mysql.com>` ou (si vous êtes client du support) à `<support@mysql.com>` à 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 :

Attribut | Description
d | Active 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.
D | Attendre 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.
f | Limiter 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.
F | Identifie le nom du fichier source pour chaque ligne de débogage ou de tra¸age affichée.
i | Identifie le processus avec son identifiant pour chaque ligne de débogage ou de tra¸age affichée.
g | Active 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.
L | Identifie le numéro de ligne du fichier source pour chaque ligne renvoyée par le tra¸age ou le débogage.
n | Imprime le niveau de profondeur de la fonction en cours d'exécution pour la sortie du tra¸age ou du débogage.
N | Numérote chaque ligne de la sortie du débogage.
o | Redirige le flux de sortie du débogueur vers le fichier spécifié. Par défaut, c'est stderr.
O | Comme `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.
p | Limite 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.
P | Affiche le nom du processus courant pour chaque ligne de sortie de débogage ou de tra¸age.
r | Lors 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.
S | Exé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)
t | Active 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.

Précédent |  | Suivant
Annexe C. Historique des changements MySQL | Sommaire | Annexe E. Variables d'environnement