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.2.5 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 librairie 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:8001/people/proven/pthreads.html). Cela peut être utilisé pour certains systèmes d'exploitation qui n'ont pas les threads POSIX.
Il est aussi possible d'utiliser un autre package de threads au niveau utilisateur nommé FSU Pthreads (Voir la page de FSU 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. Nous avons utilisé
les distributions automake-1.2 et autoconf-2.12.
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 !
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.1 Que faire si MySQL crashe 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 CPU ou si 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 section 4 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.6 Notes spécifiques aux systèmes d'exploitation.
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 librairie 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 crashe 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 crashe 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 à mysql@lists.mysql.com et
demander de l'aide. 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) :
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 dans `/tmp/mysqld.trace'.
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 package DBUG de Fred Fish. See section D.3 Le package DBUG.
Sur la plupart des systèmes, vous pouvez démarrer mysqld à partir de
gdb pour obtenir plus d'informations si mysqld crashe.
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.1 Que faire si MySQL crashe 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 à mysql@lists.mysql.com.
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.
See section 8.2.2 L'interface DBI.
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 4.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 :
mysqld :
nm -n libexec/mysqld > /tmp/mysqld.symNotez 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
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 crashé, 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.7.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.
See section 4 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 'hostname'.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 5.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 4.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
(section 4 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 à
mysql@lists.mysql.com. 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'ai crashé juste
avant, alors quelque chose ne va pas, et une enquête plus approfondie est nécessaire.
See section 4.1.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
reproduisable en effectuant ce qui suit :
mysqladmin shutdown).
myisamchk -s base/*.MYI. Réparez toute
table corrompue avec myisamchk -r base/table.MYI.
mysqld avec --log-bin. See section 4.9.4 Le log binaire.
Si vous voulez trouver une requête qui fait crasher mysqld, vous devez
utiliser --log --log-bin.
serveur mysqld.
mysqld sans --log-bin
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.#.
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.
Pour pouvoir déboguer un client MySQL avec le package de débogage intégré,
vous devez configurer MySQL avec --with-debug ou --with-debug=full.
See section 2.3.3 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.7.1.3 Comment rapporter un bogue ou un problème.
Si votre client crashe au niveau d'un code qui vous parait 'légal', vous devez vérifier que votre fichier `mysql.h' inclu correspond à votre librairie mysql. Une erreur très courante est d'utiliser un vieux fichier `mysql.h' d'une anciene installation avec la nouvelle librairie MySQL.
Le serveur MySQL et la plupart des clients MySQL sont compilés avec le package DBUG écrit, à l'origine, par Fred Fish. Lorsque MySQL est compilé avec le support du débogage, ce package 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 package 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'arguement 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 opur 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.
Actuellement, MySQL ne supporte que le verrouillage de table pour
les tables ISAM/MyISAM et HEAP,
le verrouillage de page pour les tables BDB et le
verrouillage de ligne pour InnoDB.
See section 5.3.1 Comment MySQL verrouille les tables.
Avec les tables MyISAM, vous pouvez mélanger librement les
INSERT et SELECT sans poser de verrous (Versioning).
Depuis la version 3.23.33, vous pouvez analyser l'utilisation des verrous
sur vos tables avec les variables d'environnement Table_locks_waited et
Table_locks_immediate.
Pour décider si vous voulez utiliser un type de table avec verrouillage de ligne, vous devez commencer par étudier ce que votre application fait, et quel est le schéma d'utilisation des sélections et modifications.
Avantages du verrouillage de ligne :
ROLLBACK)
Inconvénients du verrouillage de ligne :
GROUP BY sur la majeure partie des données, ou si vous avez à scanner toute
la table.
Les verrous de tables sont supérieurs aux verrous de page ou de ligne dans les cas suivants :
UPDATE table_name SET column=value WHERE unique_key# DELETE FROM table_name WHERE unique_key=#
SELECT combiné avec INSERT (et quelques UPDATE
et DELETE rares).
GROUP BY sur toute la table, sans aucune écriture.
Autres possibiltés alternatives au verrouillage de ligne ou de page :
Le versionnage (comme celui que nous utilisons pour les insertions
simultanées avec MySQL), où vous pouvez avoir un thread qui écrit
et de nombreux autres qui lisent. Cela signifie que les bases ou tables
supportent différentes vues des données, suivants le moment d'accès aux
données. D'autres noms pour cette techniques sont time travel,
copy on write ou copy on demand.
La copy on demand (copie sur demande) est dans de nombreuses
situations bien meilleure que le verrouillage de page ou de ligne.
Le pire reste l'utilisation de mémoire, qui est bien plus forte qu'avec
les verrous normaux.
Au lieu d'utiliser le verrouillage de ligne, vous pouvez utiliser des verrous au niveau de l'application (comme les get_lock/release_lock de MySQL). Cela ne fonctionne qu'avec les applications bien élevées.
Dans de nombreux cas, vous pouvez faire une estimation éclairée du type de verrouillage qui est le meilleur pour votre application, mais la plus part du temps, il est très difficile de dire si un type de verrouillage est plus adapté que l'autre. Tout dépend de votre application, et des différentes parties qui réclament des verrous.
Voici quelques conseils sur le verrouillage de MySQL :
La plupart des sites web fond de nombreuses lecture, très peu d'effacements, des modifications avec des clés, et des insertions dans des tables spécifiques. La base MySQL est très bien optimisée pour cela.
Les utilisateurs simultanés ne sont pas un problème si ils ne mélangent pas les insertions et les modifications, qui déclenchent l'analyse de nombreuses lignes dans la même table.
Si vous mélangez les insertions et les effacements sur les mêmes tables, alors
utilisez INSERT DELAYED pour améliorer la situation.
Vous pouvez aussi utiliser la commande LOCK TABLES pour accélérer les opérations
(de nombreuses modifications dans le même verrou et bien plus rapide que de le faire
sans le verrou). Répartir les opérations sur plusieurs tables peut aussi aider.
Si vous avez des problèmes avec les verrous de tables de MySQL, vous pourriez
les résoudre en convertissant les tables au format InnoDB
ou BDB .
See section 7.5 Tables InnoDB. See section 7.6 Tables BDB ou BerkeleyDB.
Le chapitre d'optimisation du manuel couvre de nombreux aspects du paramétrage de l'application. See section 5.2.12 Autres conseils d'optimisation.
J'ai essayé d'utiliser le package 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 librairie 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 librairie 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 :
-DHAVE_rts_threads.
thr_alarm.
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
MySQL est très dépendant du package de threads utilisé. Ce qui fait que lors du choix d'une bonne plate-forme pour MySQL, le package des threads est très important.
Il y a au moins trois types de packages de threads :
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 librairies du système. Dans ces cas, le changement de thread ne peut être fait qu'avec la librairie des threads et le noyau n'est pas vraiment ``attentif aux threads''.
Go to the first, previous, next, last section, table of contents.