2 Installation de MySQL
2.6 Notes spécifiques aux systèmes d'exploitation
2.6.1 Notes relatives à Linux (toutes versions)
Les notes suivantes relatives à glibc ne s'appliquent que dans la situation où vous construisez MySQL vous−même. Si vous n'utilisez pas Linux sur une machine x86 machine, dans la plupart des cas, il sera mieux pour vous d'utiliser nos binaires. Nous lions nos binaires avec la meilleur version patchée de glibc que nous pouvons fournir et avec les meilleurs options du compilateur, en essayant de les rendre bons pour un serveur qui connait de fortes charges. Et donc, si vous lisez le texte suivant et que vous avez un doute sur ce que vous devez faire, essayez d'abord notre binaire pour voir s'il vous convient, et ne vous souciez de vosz propres constructions qu'après vous être
assurés que notre binaire ne répond pas à vos attentes. Dans ce cas, nous apprécierons une note à propos de cela, pour que nous puissions faire mieux la prochaine fois. Pour les besoins d'un utilisateur de base, pour des configurations avec beaucoup de connexions et/ou des tables
dépassant la limite des 2G, notre binaire est dans la plupart des cas le meilleur choix.MySQL utilise LinuxThreads sur Linux. Si vous utilisez une vielle version de Linux qui ne possède pas glibc2 , vous devz installer LinuxThreads avant d'essayer de compiler MySQL. Vous pouvez obtenir LinuxThreads à l'adresse suivante : http://www.mysql.com/Downloads/Linux/ . Note : Nous avons rencontré quelques problèmes étranges avec Linux 2.2.14 et MySQL sur les systèmes SMP. Si vous avez un système SMP, nous vous recommandons de mettre à jour à Linux 2.4 dès que possible ! Votre système n'en sera que plus rapide et plus stable !
Notez que les versions de glibc inférieure ou égale à la 2.1.1 ont un bogue fatal dans la gestion de pthread_mutex_timedwait , qui est utilisé lors que vous exécutez INSERT DELAYED . Nous vous recommandons de ne pas utiliser INSERT DELAYED avant de mettre à jour glibc.
Si vous planifiez d'avoir plus de 1000 connexions simultanées, vous aurez besoin d'apporter quelques modifications à LinuxThreads, le recompiler, et relier MySQL avec le nouveau
libpthread.a . Augmentez PTHREAD_THREADS_MAX dans
sysdeps/unix/sysv/linux/bits/local_lim.h à 4096 et diminuez STACK_SIZE dans
linuxthreads/internals.h à 256 KB. Les chemins sont relatifs à la racine de glibc . Notez que MySQL ne sera pas stable autour de 600−1000 connexions si STACK_SIZE est à 2 MB (par défaut).
Si MySQL n'arrive pas à ouvrir assez de fichiers, ou à créer assez de connexions, il se peut que vous n'ayez pas configuré Linux pour qu'il gère assez de fichiers.
Dans Linux 2.2 ou plus, vous pouvez connaitre le nombre de gestionnaires de fichiers alloués en faisant :
cat /proc/sys/fs/file−max cat /proc/sys/fs/dquot−max cat /proc/sys/fs/super−max
Si vous avez plus de 16 MB de mémoire, vous devez ajouter qauelque chose comme ce qui suit dans vos scripts d'initialisation ( /etc/init.d/boot.local sur SuSE Linux) :
echo 65536 > /proc/sys/fs/file−max echo 8192 > /proc/sys/fs/dquot−max echo 1024 > /proc/sys/fs/super−max
Vous pouvez aussi exécuter les commandes précédentes à partir de la ligne de commande en tant que root, mais les changements seront perdus au prochain redémarrage de l'ordinateur.
Vous pouvez sinon définir ces paramètres lors du démarrage de la machine en utilisant l'outil
sysctl , qui est utilisé par plusieurs distributions Linux (SuSE l'a aussi ajouté, à partir de SuSE Linux 8.0). Ajoutez simplement les valeurs suivantes dans un fichier nommé /etc/sysctl.conf :
# Increase some values for MySQL fs.file−max = 65536
fs.dquot−max = 8192 fs.super−max = 1024
Vous devez aussi ajouter ce qui suit à /etc/my.cnf :
[safe_mysqld]
open−files−limit=8192
Cela devrait permettre à MySQL de créer jusqu'à 8192 fichiers de conexion.La constante
STACK_SIZE des LinuxThreads contrôle l'espacement des piles de threads dans l'espace
d'adressage. Elle doit être assez grande pour qu'il y ait plusieurs chambres pour la pile de chaque
thread individuel, mais assez petite pour empêcher les piles de certains threads d'agir sur les données globales de mysqld . Malheureusement, l'implémentation Linux de mmap() , comme nous l'avons découvert, will successfully unmap an already mapped region if you ask it to map out an address already in use, zeroing out the data on the entire page, instead of returning an error. So, the safety of mysqld or any other threaded application depends on the "gentleman" behaviour of the code that creates threads. The user must take measures to make sure the number of running threads at any time is sufficiently low for thread stacks to stay away from the global heap. With
mysqld , you should enforce this "gentleman" behaviour by setting a reasonable value for the
max_connections variable.
Si vous construisez MySQL vous−mêmes et ne voulez pas vous amuser à patcher LinuxThreads, vous ne devez pas dépasser 500 pour la valeur de max_connections . Cela devrait même être moins si vous avez un tampon de clefs assez large, de grosses tables heap, ou d'autres choses qui peuvent faire allouer beaucoup de mémoire à mysqld , ou si vous utilisez un noyau 2.2 avec un patch 2G. Si vous utilisez notre binaire ou RPM 3.23.25 ou plus, vous pouvez mettre
max_connections à 1500 sans problèmes, en supposant que vous n'avez ni de grosses tables heap ni grands tampons de clefs. Plus vous réduirez STACK_SIZE dans LinuxThreads plus les threads créés seront sûrs. Nous recommandons une valeur entre 128K et 256K.
Si vous utilisez beaucoup de connexions simultanées vous souffrirez peut−être d'une
"fonctionnalité" du noyau 2.2 qui pénalise un processus lors du fork ou du clonage d'un enfant en essayant de prévenir un attaque du type fork bomb. This will cause MySQL not to scale well as you increase the number of concurrent clients. On single−CPU systems, we have seen this manifested in a very slow thread creation, which means it may take a long time to connect to MySQL (as long as 1 minute), and it may take just as long to shut it down. On multiple−CPU systems, we have observed a gradual drop in query speed as the number of clients increases. In the process of trying to find a solution, we have received a kernel patch from one of our users, who claimed it made a lot of difference for his site. The patch is available at
http://www.mysql.com/Downloads/Patches/linux−fork.patch . We have now done rather extensive testing of this patch on both development and production systems. It has significantly improved
MySQL performance without causing any problems and we now recommend it to our users who are still running high−load servers on 2.2 kernels. This issue has been fixed in the 2.4 kernel, so if you are not satisfied with the current performance of your system, rather than patching your 2.2 kernel, it might be easier to just upgrade to 2.4, which will also give you a nice SMP boost in addition to fixing this fairness bug.
We have tested MySQL on the 2.4 kernel on a 2−CPU machine and found MySQL scales much better−there was virtually no slowdown on queries throughput all the way up to 1000 clients, and the MySQL scaling factor (computed as the ratio of maximum throughput to the throughput with one client) was 180%. We have observed similar results on a 4−CPU system−virtually no slowdown as the number of clients was increased up to 1000, and 300% scaling factor. So for a high−load SMP server we would definitely recommend the 2.4 kernel at this point. We have discovered that it is essential to run mysqld process with the highest possible priority on the 2.4 kernel to achieve maximum performance. This can be done by adding renice −20 $$ command to safe_mysqld
. In our testing on a 4−CPU machine, increasing the priority gave 60% increase in throughput with 400 clients.
Nous essayons aussi actuellement d'obtenir des informations sur le bon fonctionnement de MySQL
sur le noyaux 2.4 sur les systèmes 4−voies and 8−voies. Si vous avez accès à un tel système et que vous avez effectués quelques tests de performances, envoyez−nous un mail à
docs@mysql.com avec les résultats, nous les inclurons dans le manuel.There is another issue that greatly hurts MySQL performance, especially on SMP systems. The implementation of mutex in LinuxThreads in glibc−2.1 is very bad for programs with many threads that only hold the mutex for a short time. On an SMP system, ironic as it is, if you link MySQL against unmodified
LinuxThreads , removing processors from the machine improves MySQL performance in many cases. We have made a patch available for glibc 2.1.3 to correct this behaviour (
http://www.mysql.com/Downloads/Linux/linuxthreads−2.1−patch ).With glibc−2.2.2 MySQL version 3.23.36 will use the adaptive mutex, which is much better than even the patched one in
glibc−2.1.3 . Be warned, however, that under some conditions, the current mutex code in
glibc−2.2.2 overspins, which hurts MySQL performance. The chance of this condition can be reduced by renicing mysqld process to the highest priority. We have also been able to correct the overspin behaviour with a patch, available at
http://www.mysql.com/Downloads/Linux/linuxthreads−2.2.2.patch . It combines the correction of overspin, maximum number of threads, and stack spacing all in one. You will need to apply it in the
linuxthreads directory with patch −p0 </tmp/linuxthreads−2.2.2.patch . We hope it will be included in some form in to the future releases of glibc−2.2 . In any case, if you link against glibc−2.2.2 you still need to correct STACK_SIZE and PTHREAD_THREADS_MAX . We hope that the defaults will be corrected to some more acceptable values for high−load MySQL setup in the future, so that your own build can be reduced to ./configure; make; make install . We recommend that you use the above patches to build a special static version of libpthread.a
and use it only for statically linking against MySQL . We know that the patches are safe for MySQL
and significantly improve its performance, but we cannot say anything about other applications. If you link other applications against the patched version of the library, or build a patched shared version and install it on your system, you are doing it at your own risk with regard to other applications that depend on LinuxThreads .
Si vous rencontrez des problèmes étranges lors de l'installation de MySQL, ou quoi que ce soit qui s'en rapproche, il est fort possible que cela soit un problème de librairie ou de compilateur. Si c'est le cas, l'utilisation de notre binaire les résoudra.
Un problème connu avec la distribution binaire est que avec les anciens systèmes Linux qui utilisent
libc (comme RedHat 4.x ou Slackware), vous obtiendrez quelques erreurs non−fatales de résolutions de noms d'hôtes. Notes relatives à Linux pour les distribution binaires .
Lors de l'utilisation des LinuxThreads vous verrez un minimum de trois processus en cours. Il s'agit en fait de threads, il y'a a un pour le gestionnaire des LinuxThreads, un pour gérer les connexions, et un autre pour gérer les alarmes et les signaux.Notez que le noyau Linux et la librairie
LinuxThread ne peuvent avoir par défaut que 1024 threads. Cela signifie que vous ne pouvez avoir que 1021 connexions à MySQL sur un système non−patché. La page
http://www.volano.com/linuxnotes.html contient des informations pour contourner cette limite.Si vous voyez un processus de démon mysqld mort avec ps , cela signifie le plus souvent que vous avez trouvé un bogue dans MySQL ou que vous avez une table corrompue. Que faire si MySQL crashe constamment .
To get a core dump on Linux if mysqld dies with a SIGSEGV signal, you can start mysqld with the
−−core−file option. Note that you also probably need to raise the core file size by adding
ulimit −c 1000000 to safe_mysqld or starting safe_mysqld with
−−core−file−size=1000000 . safe_mysqld , le script père de mysqld . Si vous liez votre propre client MySQL et que vousobtenez l'erreur suivante :
ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory
lors de son exécution, le problème peut être contourné des façons suivantes :
Liez le client avec les options suivantes (au lieu de −Lpath ) :
−Wl,r/path−libmysqlclient.so .
•
Copiez libmysqclient.so dans /usr/lib .
•
Ajoutez le chemin vers le répertoire où se trouve libmysqlclient.so à la variable d'environnement LD_RUN_PATH avant de mettre en marche votre client.
•
Si vous utilisez le compilateur Fujitsu (fcc / FCC) vous aurez quelques problèmes en compilant MySQL car les fichiers d'entêtes Linux sont très orientés gcc .
La ligne suivante de configure devrait fonctionner avec fcc/FCC :
CC=fcc CFLAGS="−O −K fast −K lib −K omitfp −Kpreex −D_GNU_SOURCE \ −DCONST=const −DNO_STRTOLL_PROTO" CXX=FCC CXXFLAGS="−O −K fast −K lib \ −K omitfp −K preex −−no_exceptions −−no_rtti −D_GNU_SOURCE −DCONST=const \ −Dalloca=__builtin_alloca −DNO_STRTOLL_PROTO \
'−D_EXTERN_INLINE=static __inline'" ./configure −−prefix=/usr/local/mysql \ −−enable−assembler −−with−mysqld−ldflags=−all−static −−disable−shared \ −−with−low−memory
2.6.1.1 Notes relatives à Linux pour les distributions binaires
MySQL requière au moins la version 2.0 de Linux.
Attention : Certains utilisateurs de MySQL nous ont avertis qu'ils ont rencontré de graves
problèmes de stabilité avec MySQL et le noyau 2.2.14 de Linux. Si vous utilisez ce noyau, vous devez mettre à jour à la 2.2.19 (ou plus récent) ou a un noyau 2.4. Si vous utilisez un ordinateur multi−processeurs, vous devriez sérieusement songer à passer au noyau 2.4 qui vous aportera de grandes performances niveau vitesse.
La version binaire est liée avec −static , ce qui signifie que normalement vous n'avez pas besoin de vous soucier des versions des librairies système que vous avez. Vous n'avez pas besoin
d'installer LinuxThreads non plus. Un programme lié avec −static est légèrement plus grand qu'un programme liée dynamiquement mais aussi un peu plus rapide (3−5%). Un problème, toutefois, est que vous ne pouvez utiliser de fonctions définies par l'utilisateur avec un programme lié statiquement. Si vous allez écrire ou utiliser des fonctions UDF (c'est réservé aux développeurs C ou C++), vous devez compiler MySQL vous−mêmes, en utilisant les liaisons dynamiques.
Si vous utilisez un système basé sur libc (au lieu de glibc2 ), vous aurez probablement
quelques problèmes de résolution des noms d'hôtes et des problèmes avec getpwnam() avec les versions binaires. (Cela vient du fait que glibc dépend malheureusement de quelques librairies externes pour résoudre les noms d'hôtes et getpwent() , même quand elle est compilée avec
−static ). Dans ce cas, vous obtiendrez probablement l'erreur suivante quand vous exécuterez
mysql_install_db :
Sorry, the host 'xxxx' could not be looked up
ou l'erreur suivante quand vous essayez de démarrer mysqld avec l'option −−user :
getpwnam: No such file or directory
Vous pouvez résoudre ce problème de la façon suivante :
Obtenez une distribution des sources MySQL (un distribution RPM ou le tar.gz ) et installez la à la place.
•
Exécutez mysql_install_db −−force ; cela n'exécutera pas le test resolveip dans
mysql_install_db . Le mauvais côté est que vous ne pourrez pas utiliser de noms d'hôtes dans les tables de droits; vous devez utiliser les adresses IP à la place (sauf pour
localhost ). Si vous utilisez une vielle version de MySQL qui ne supporte pas −−force , vous devez supprimer le test resolveip dans mysql_install à l'aide d'un éditeur.
•
Démarrez mysqld avec su au lieu d'utiliser −−user .
•
Le binaire Linux−Intel et les RPM de MySQL sont configurés pour la vitesse la plus grande possible. Nous essayons toujours d'utiliser le compilateur le plus rapide disponible.Le support Perl de MySQL requière la version 5.004_03 de Perl ou plus récent.
Sur quelques version de Linux 2.2, vous pouvez obtenir l'erreur Resource temporarily unavailable quand vous faites beaucoup de nouvelles connexions à un serveur mysqld en utilisant TCP/IP.
Le problème est que Linux possède un délai entre votre fermeture de la socket TCP/IP et sa
libération par le système. Vu qu'il y'a un nombre fini de places pour les branchements TCP/IP, vous obtiendrez l'erreur précédente si vous essayez de faire beaucoup de connexions TCP/IP en peu de temps, comme quand vous exécutez le benchmark MySQL test−connect via TCP/IP.
Nous avons envoyé des questions plusieurs fois à propos de ce problème à différentes listes de diffusions Linux mais n'avons jamais réussi à résoudre ce problème proprement.
Le seul 'correctif' connu pour ce problème est d'utiliser des connexions persistantes dans vos clients ou d'utiliser les sockets, si vous utilisez le serveur de bases de données et le client sur la même machine. Nous espérons que le noyau de Linux 2.4 corrigera ce problème bientôt.
2.6.1.2 Notes relatives à Linux x86
MySQL requière la version 5.4.12 de libc ou plus récent. Il est connu pour fonctionner avec libc
5.4.46. La version 2.0.6 de glibc ou plus récente devrait aussi fonctionner. Il y'a eu quelques problèmes avec les RPM de glibc de RedHat, et donc, si vous avez des problèmes, vérifiez s'il existe des mises à jour ! Les RPM de glibc 2.0.7−19 et 2.0.7−29 snot connus pour fonctionner. Si vous utilisez gcc 3.0 ou plus récent pour compiler MySQL, vous devez installer la librairie
libstdc++v3 avant de compiler MySQL; si vous ne le faites pas vous obtiendrez une erreur à propos d'un symbole __cxa_pure_virtual manquant durant la liaison !
Sur quelques vieilles distributions de Linux, configure peut produire une erreur comme celle qui suit :
Syntax error in sched.h. Change _P to __P in the /usr/include/sched.h file. See the Installation chapter in the Reference Manual.
Faites ce que le message d'erreur dit et ajoutez un _ à la macro _P qui n'en a qu'un, puis essayez à nouveau.Vous pouvez obtenir quelques avertissements en compilant; celles qui suivent peuvent être ignorées :
mysqld.cc −o objs−thread/mysqld.o
mysqld.cc: In function `void init_signals()':
mysqld.cc:315: warning: assignment of negative value `−1' to `long unsigned int'
mysqld.cc: In function `void * signal_hand(void *)':
mysqld.cc:346: warning: assignment of negative value `−1' to `long unsigned int'
Sur Debian GNU/Linux, si vous voulez que MySQL démarre automatiquement lors du démarrage de votre système, faites ce qui suit :
shell> cp support−files/mysql.server /etc/init.d/mysql.server shell> /usr/sbin/update−rc.d mysql.server defaults 99
mysql.server peut être trouvé dans le dossier share/mysql dans le dossier d'installation de MySQL ou dans le dossier support−files de l'arborescence des sources de MySQL.
Si mysqld provoque toujours un core dump au démarrage, le problème peut être que vous avez un vieux /lib/libc.a . Renommez le, puis supprimez sql/mysqld et faites à nouveau un make
install puis réassayez. Ce problème a été reporté sur quelques installations de Slackware. Si vous obtenez l'erreur suivante en liant mysqld , cela signifie que votre libg++.a n'est pas installé correctement :
/usr/lib/libc.a(putc.o): In function `_IO_putc': putc.o(.text+0x0): multiple definition of `_IO_putc'