Table des matières
Ce chapitre décrit comment obtenir et installer MySQL :
Déterminez si votre plate-forme est supportée. Notez que tous les systèmes ne supportent pas MySQL de la même fa¸on. MySQL est plus robuste et efficace que sur d'autres. Voyez Section 2.1.1, « Systèmes d'exploitation supportés par MySQL » pour plus de détails.
Choisissez une distribution à installer. Plusieurs versions de MySQL sont disponibles, dans plusieurs formats. Vous pouvez choisir une version preparée avec des exécutables pré-compilés, ou bien une version source. En cas de doute, utilisez la version binaire. Nous fournissons aussi un accès public à notre serveur de développement pour tester le nouveau code. Pour déterminer quelle version et quel type utiliser, voyez Section 2.1.2, « Choisir votre version de MySQL ».
Téléchargez la distribution que vous
souhaitez. Pour une liste de site sur lesquels vous
pouvez télécharger MySQL, voyez
Section 2.1.3, « Comment obtenir MySQL ? ». Vous pouvez vérifier
l'intégrité de votre téléchargement en utilisant les
instructions de Section 2.1.4, « Vérifier l'intégrité des paquets avec MD5 ou
GnuPG ».
Installez la distribution. Pour les distributions binaires, voyez Section 2.3, « Installer MySQL sur d'autres systèmes type Linux ». Pour les distributions source, utilisez Section 2.4, « Installation de MySQL avec une distribution source ». Chaque jeu d'instruction inclut une section spécifique aux plate-formes.
Note : si vous envisagez de changer la version d'une installation existante de MySQL vers une nouvelle version, plutôt que d'installer MySQL pour la première fois, voyez la section Section 2.6, « Changer de version de MySQL » pour des informations sur les mises à jour, et sur les problèmes que vous pourriez rencontrer.
Si vous rencontrez les problèmes d'installation, voyez la section Section 2.8, « Notes spécifiques aux systèmes d'exploitation » pour des informations sur les solutions aux proiblèmes spécifiques des plates-formes.
Pour la procédure post-installation, voyez Section 2.5, « Procédure de post-installation ». Ces procédures s'appliquent aussi bien à la distribution binaire que la distribution source. Cette section décrit aussi comment sécuriser les comptes initiaux MySQL, qui n'ont pas de mot de passe jusqu'à ce que vous leur assigniez un.
Si vous voulez exécuter des scripts de tests MySQL, le support Perl de MySQL doit être disponible. See Section 2.9, « Commentaires sur l'installation de Perl ».
Avant d'installer MySQL, vous devez :
Déterminer si MySQL fonctionne ou pas sur votre plate-forme.
Choisir une distribution.
Télécharger la distribution et vérifier son intégrité.
Cette section contient les informations nécessaires pour réaliser ces étapes. Après cela, vous pouvez utiliser les autres instructions des autres chapitres, pour installer la distribution.
Nous utilisons GNU Autoconf, alors il est
possible de porter MySQL sur tous les systèmes modernes qui
utilisent les threads Posix et un compilateur C++. Pour compiler
uniquement le client, un compilateur C++ est simplement
nécessaire. Nous utilisons et développons le logiciel
nous-mêmes, en commen¸ant par Sun Solaris (Versions 2.5 - 2.7)
et SuSE Linux version 7.x.
Notez que pour de nombreux systèmes d'exploitation, le support natif des threads ne fonctionne qu'avec les dernières versions. MySQL a été compilé avec succès sur les combinaisons système d'exploitation/paquet de threads suivants :
AIX 4.x, 5.x avec les threads natifs. See Section 2.8.5.3, « Notes relatives à IBM-AIX ».
Amiga.
BSDI 2.x avec le paquet MIT-pthreads. See
Section 2.8.4.5, « Notes relatives aux versions 2.x de BSD/OS ».
BSDI 3.0, 3.1 et 4.x avec les threads natifs. See Section 2.8.4.5, « Notes relatives aux versions 2.x de BSD/OS ».
DEC Unix 4.x avec les threads natifs. See
Section 2.8.5.5, « Notes pour Alpha-DEC-UNIX (Tru64) ».
FreeBSD 2.x avec le paquet MIT-pthreads.
See Section 2.8.4.1, « Notes relatives à FreeBSD ».
FreeBSD 3.x et 4.x avec les threads natifs. See Section 2.8.4.1, « Notes relatives à FreeBSD ».
FreeBSD 4.x avec LinuxThreads. See
Section 2.8.4.1, « Notes relatives à FreeBSD ».
HP-UX 10.20 avec les threads DCE ou avec le paquet
MIT-pthreads. See
Section 2.8.5.1, « Notes relatives à la version 10.20 de HP-UX ».
HP-UX 11.x avec les threads natifs See Section 2.8.5.2, « HP-UX Version 11.x Notes ».
Linux 2.0+ avec LinuxThreads 0.7.1+ ou
glibc 2.0.7+. See
Section 2.8.1, « Notes relatives à Linux (toutes versions) ».
Mac OS X. See Section 2.8.2, « Notes relatives à Mac OS X ».
NetBSD 1.3/1.4 Intel et NetBSD 1.3 Alpha (requiert GNU make). See Section 2.8.4.2, « Notes concernant NetBSD ».
Novell NetWare 6.0. See Section 2.2.14, « Installer MySQL sur NetWare ».
OpenBSD > 2.5 avec les threads natifs. OpenBSD < 2.5
avec le paquet MIT-pthreads. See
Section 2.8.4.3, « Notes relatives à OpenBSD 2.5 ».
OS/2 Warp 3, FixPack 29 et OS/2 Warp 4, FixPack 4. See Section 2.8.6, « Notes relatives à OS/2 ».
SCO OpenServer avec un port récent du paquet FSU Pthreads. See Section 2.8.5.8, « Notes sur SCO ».
SCO UnixWare 7.1.x. See Section 2.8.5.9, « Notes sur SCO UnixWare Version 7.1.x ».
SGI Irix 6.x avec les threads natifs. See Section 2.8.5.7, « Notes relatives à SGI Irix ».
Solaris 2.5 et plus récent, avec les threads natifs sur SPARC et x86. See Section 2.8.3, « Notes pour Solaris ».
SunOS 4.x avec le paquet MIT-pthreads.
See Section 2.8.3, « Notes pour Solaris ».
Tru64 Unix
Windows 9x, Me, NT, 2000 et XP. See Section 2.2.1, « Installer MySQL sous Windows ».
Notez que toutes les plates-formes ne sont pas équipées de la même fa¸on pour faire fonctionner MySQL. Les capacités d'une plate-forme pour supporter de fortes charges avec MySQL est déterminé par ceci :
Stabilité générale de la bibliothèque de threads. Une plate-forme qui a une excellente réputation en général, mais une bibliothèque de threads instable, dont le code est utilisé par MySQL, même si le reste est parfait, fera de MySQL une application instable.
La capacité du noyau et/ou de la bibliothèque de threads de profiter des capacités multi-processeurs, symétrique ou pas. En d'autres termes, lorsqu'un processus crée un thread, il doit être possible pour ce thread de s'exécuter sur différents processeurs.
La capacité du noyau et/ou de la bibliothèque de threads
de faire fonctionner de nombreux threads qui posent et
lèvent des verrous mutex en peut de temps, fréquemment,
sans changement de contexte excessif. En d'autres termes, si
l'implémentation de pthread_mutex_lock()
est trop soucieux du temps CPU, cela va ralentir
sérieusement MySQL. Si ce problème n'est pas réglé,
ajouter des processeurs supplémentaires va finalement
ralentir MySQL.
Performance et stabilité générale du système de fichiers.
La capacité du système d'exploitation de gérer de grands fichiers, et de le faire efficacement, si vos tables sont grandes.
Notre niveau d'expertise avec la plate-forme, chez MySQL AB. Si vous connaissons bien une plate-forme, vous pourront introduire des optimisations et des corrections spécifiques à la plate-forme, et activé lors de la compilation. Nous pouvons aussi fournir des conseils judicieux pour configurer votre système optimalement pour MySQL.
Le temps de tests que vous avons consacré à des configurations similaires, en interne.
Le nombre d'utilisateur de MySQL qui font fonctionner MySQL avec succès sur cette plate-forme, avec des configurations similaires. Si ce nombre est grand, les chances de rencontrer un problème spécifique sont faibles.
En se basant sur les critères précédents, les meilleures plates-formes pour MySQL sont x86 avec SuSE Linux 7.1, noyau 2.4, et ReiserFS (ou toute autre distribution Linux similaire) et SPARC avec Solaris 2.7 ou 2.8. FreeBSD vient en troisième, mais nous espérons bien le voir rejoindre le groupe de tête, une fois que la bibliothèque de threads sera améliorée. Nous espérons aussi être bientôt capables d'ajouter les autres plates-formes sur laquelle MySQL compile, et fonctionne correctement, mais pas toujours le bon niveau de stabilité et de performances. Cela réclame des efforts de notre part, en coopération avec les développeurs de ces plates-formes. Si vous êtes intéressés par l'amélioration de ces composants, et que vous êtes en position pour influencer le développement, demandez des instructions détaillées à MySQL en envoyant un email aux listes internes. See Section 1.4.1.1, « Les listes de diffusion de MySQL ».
Notez bien que la comparaison précédente ne signifie pas qu'un système d'exploitation est meilleur que l'autre, en général. Nous avons classé les systèmes en fonction de leur capacité à faire fonctionner un système MySQL, et nous nous limitons à cette comparaison. Avec cela en tête, le résultat de cette comparaison serait différent si nous y ajoutions d'autres problèmes. Et dans certains cas, la seule raison qui fait qu'un OS est meilleur que l'autre est parce que nous y avons consacré plus de temps, pour optimiser et tester. Nous nous bornons à exprimer notre point de vue pour vous aider à décider quelle plate-forme choisir pour votre serveur MySQL.
Lorsque vous vous préparez à installer MySQL, vous devez décider quelle version utiliser. Le développement de MySQL procède par série de versions, et vous pouvez prendre celle qui vous convient le mieux. Après avoir décidé de la version à installer, vous pouvez choisir le format de distribution : elles sont compilées ou au format source.
La première décision à prendre est de savoir si vous voulez utiliser la dernière version de développement ou la dernière version stable :
MySQL 5.0 est la nouvelle version de développement, et les nouvelles fonctionnalités sont activement développées. Jusque récemment, elle n'était disponible qu'en avant-première, sous BitKeeper. Une version alpha a été publiée depuis, pour permettre la diffusion large de la version, à des fins de tests.
MySQL 4.1 est la version de développement, qui propose de nouvelles fonctionnalités majeures. Elle est toujours en version alpha. Les sources et le binaire sont disponibles pour tests et développement.
MySQL 4.0 est la version stable courante, pour la production. Les nouvelles versions publiées sont des corrections de bogues. Aucune nouvelle fonctionnalité ne sera ajoutée, pour ne pas diminuer la stabilité du code.
MySQL 3.23 est l'ancienne version de production. Cette série est retirée, et les nouvelles versions ne feront que corriger les bogues critiques.
Nous ne croyons pas au gel complet d'une version, et cela nous laisse de la place pour les corrections de bogues et les fonctionnalités qui ``doivent être faites.'' ``Un peu gelé'' signifie que nous pourrions ajouter de petites touches, qui ``n'affecterons pas ce qui fonctionne déjà, presque sûrement.'' Naturellement, les corrections de bogues des séries précédentes se propage aux nouvelles versions.
En règle générale, si vous utilisez MySQL pour la première fois ou si vous essayer de le porter vers un système pour lequel il n'existe pas de distribution binaire, nous vous recommandons d'utiliser la dernière version stable (actuellement la version 4.0). Notez que toutes les versions de MySQL sont passées aux bancs de tests MySQL avant chaque sortie (même les versions de développement).
D'autre part, si vous utilisez un vieux système et que vous voulez procéder à une mise à jour, sans pour autant risquer de mettre à jour sans raison, vous devriez mettre à jour vers la dernière version de la même branche que celle que vous êtes en train d'utiliser (dans le cas où un numéro de version supérieur existe). Nous avons essayé de résoudre uniquement les bogues fatals et de produire des correctifs petits et sûrs pour cette version.
Si vous voulez utiliser de nouvelles versions qui ne sont pas présentes dans la version de production, vous pouvez utiliser la version de développement. Notez que les versions de développement ne sont pas aussi stables que les versions de production.
Si vous voulez utiliser les toutes dernières sources, qui contiennent tous les patches courants, et les corrections de bogues, vous pouvez utiliser notre entrepôt BitKeeper. Il n'y a pas de ``versions'' en tant que telle, mais des paquets, sur lesquels le code futur est basé.
La politique de nommage de MySQL utilise des numéros de
version qui consiste en trois nombres suivis d'un suffixe. Par
exemple, une version nommée
mysql-3.21.17-beta doit être interprétée
de la fa¸on suivante :
Le premier nombre (3) décrit le format
de fichier. Toutes les versions 3 ont le même format de
fichier.
Le second nombre (21) correspond au
niveau de version. Normalement, il y a le choix entre deux
d'entre eux. L'un correspond à la version/branche stable
(actuellement 23) et l'autre se
réfère à la branche de développement (actuellement
4.0). Normalement, les deux versions
sont stables, mais la version de développement peut
comporter des lacunes, manquer de documentation sur des
nouvelles fonctionnalités, ou peut ne pas compiler sur
certains systèmes.
Le troisième nombre (17) est le
numéro de version au sein du niveau de version. Celui-ci
est incrémenté à chaque nouvelle publication. En temps
normal, vous souhaiterez utiliser la dernière version du
niveau de version que vous avez choisi.
Pour chaque modification mineure, le dernier nombre de la version est incrémenté. Lorsque les nouvelles fonctionnalités sont majeures, ou que des incompatibilités mineures apparaissent avec les anciennes versions, le deuxième chiffre est incrémenté. Lorsque le format de fichier change, le premier chiffre est incrémenté.
Les noms de versions inclut aussi un suffixe qui indique le niveau de stabilité de la version. Une série progresse avec différents suffixes, qui indique sa stabilité. Les suffixes possibles sont :
alpha indique que la publication
contient de grandes portions de nouveau code qui n'a pas
été testé à 100%. Les bogues connus (d'ordinaire, il
n'y en a aucun) doivent être documentés dans la section
nouveautés. See Annexe C, Historique des changements MySQL. Il existe aussi
de nouvelles commandes et extensions dans la plupart des
versions alpha. Du développement actif qui inclut des
changements majeurs dans le code peut concerner les
versions alpha, mais tout sera testé avant de faire une
publication. Il ne devrait pas y avoir de bogues connus
dans les publications de MySQL.
beta signifie que tout le nouveau code
a été testé. Aucune fonctionnalité majeure qui
pourrait causer corruption du code n'est ajoutée. Il ne
doit pas y avoir un seul bogue connu. Une version alpha
passe en beta quand il n'y a pas eu de
bogue fatal rapporté depuis au moins un mois et que nous
ne prévoyons pas de nouvelle fonctionnalité qui pourrait
corrompre d'anciennes commandes.
gamma est une version bêta qui existe
depuis un certain temps et qui semble fonctionner
correctement. Seulement des changements mineurs sont
effectués. C'est ce que de nombreuses autres compagnies
appellent une publication.
S'il n'y a pas de suffixe, cela signifie que la version fonctionne depuis un certain temps sur différents sites avec aucun rapport de bogue autre que des bogues spécifiques à une plate-forme. Seuls des corrections critiques sont appliquées à la publication. C'est ce que l'on appelle une version stable.
MySQL utilise un schéma de nommage qui est légèrement différent des autres produits. En général, il est plutôt sûr d'utiliser une des versions qui est disponible depuis quelques semaines, sans avoir été remplacée par une nouvelle version de la même série.
Toutes les versions de MySQL passent par nos tests et bancs d'essais standards pour nous assurer qu'elles peuvent être utilisées sans danger. Les séries de tests s'améliorent en permanence car les tests standards sont étendus dans le temps pour traquer tous les bogues précédemment trouvées.
Notez bien que toutes les versions de MySQL ont été testées au moins avec :
Une batterie de tests internes
Le dossier mysql-test contient de
nombreux cas de tests.
Nous utilisons ces tests pour virtuellement tous les systèmes d'exploitation. Voyez Section 27.1.2, « Suite de test de MySQL » pour plus d'informations sur ces fichiers.
Les bancs de tests MySQL
Ils effectuent une série de requêtes communes. C'est aussi un test pour savoir si le dernier processus d'optimisation rend le code plus rapide. See Section 7.1.4, « La suite de tests MySQL ».
Le test crash-me
Il tente de déterminer de quelles fonctionnalités disposent les bases de données et quelles en sont les limites. See Section 7.1.4, « La suite de tests MySQL ».
Un autre test provient du fait que nous avons la version la plus récente de MySQL dans notre propre environnement de production interne, sur au moins une machine. Nous avons plus de 100 Go de données à manipuler.
Après avoir choisi votre version de MySQL, il faut décider
si vous voulez utiliser les versions binaires ou source. Dans
la plupart des cas, vous choisirez une version binaire, si
elle existe pour votre plate-forme. Les distributions binaires
sont disponibles en format natif pour de nombreuses
plates-formes, comme les paquets RPM de
Linux ou les paquets DMG pour Mac OS X. Les
distributions ont aussi disponibles sous formes d'archives Zip
ou tar compressées.
Les raisons de choisir une distribution binaires sont :
Les distributions binaires sont généralement plus faciles à installer que les distributions source.
Pour satisfaire différents niveaux de besoin, nous fournissons deux versions binaires : une version compilée avec des moteurs de stockage non-transactionnels (petits et rapides), et une version compilée avec les extensions les plus importantes, comme les transactions. Les deux versions sont compilées à partir des mêmes sources. Tous les clients natifs MySQL peuvent se connecter aux serveurs MySQL, quelque soit leur version.
La distribution MySQL maximale est suffixée avec
-max et est configurée avec les mêmes
options que mysqld-max. See
Section 5.1.2, « mysqld-max, la version étendue du serveur
mysqld ».
Si vous voulez installer le RPM
MySQL-Max, vous devez commencer par
installer le RPM
MySQL-server.
Dans certaines circonstances, il est préférable d'installer MySQL à partir de la distribution source :
Vous voulez installer MySQL dans un dossier spécial. Les distributions standards sont ``prêtes à exécuter'' depuis n'importe quel dossier, mais vous voudrez peut être avoir plus de libertés pour dispatcher les composants de MySQL.
Vous voulez configurer mysqld avec
certaines extensions qui ne font pas parties des
distributions binaires. Voici les extensions les plus
courantes, que vous souhaiterez utiliser :
--with-innodb (par défaut pour MySQL
4.0 et plus récent)
--with-berkeley-db (disponible pour
quelques plates-formes)
--with-raid
--with-libwrap
--with-named-z-libs (disponible pour
certains binaires)
--with-debug[=full]
Vous devez configurez mysqld sans
certaines fonctionnalités qui font partie de la
configuration standard. Par exemple, les distributions
sont normalement compilées avec le support de tous les
jeux de caractères. Si vous voulez rendre le serveur
MySQL plus compact, vous pouvez recompiler MySQL avec
uniquement les jeux de caractères dont vous avez besoin.
Si vous avez un compilateur spécial, comme
pgcc, ou que vous voulez utiliser des
options particulières de votre compilateur pour optimiser
MySQL pour votre architecture. Les distributions binaires
sont compilées avec les options qui doivent fonctionner
sur une large gamme de processeurs.
Vous voulez utiliser les toutes dernières versions de MySQL, issues du serveur BitKeeper, pour avoir accès à toutes les corrections de bugs archivées. Par exemple, si vous avez découvert un bug, le correctif sera archivé dans le serveur de sources, et vous pourrez y accéder là. Le correctif n'apparaîtra pas avant la prochaine publication de MySQL.
Vous voulez lire et modifier le code C et C++ de MySQL. Pour cela, obtenez une distribution source, car le code source est toujours le code ultime.
Les distributions sources contiennent plus de tests et d'exemples que les distributions binaires.
MySQL évolue rapidement ici, à MySQL AB, et nous voulons le partager avec les autres utilisateurs de MySQL. Nous essayons de faire une nouvelle version à chaque fois que nous avons implanté des fonctionnalités qui seront utiles à d'autres.
Nous essayons aussi d'aider les utilisateurs dont les requêtes sont faciles à programmer. Nous prenons en considération tout ce que nos clients nous demandent, et nous accordons une attention particulière à nos clients qui ont pris une licence e-mail étendue.
Personne n'est obligé de télécharger une nouvelle version. La sections News vous indiquera si la nouvelle version contient une fonctionnalité que vous attendez. See Annexe C, Historique des changements MySQL.
Nous utilisons la politique suivante, lors de la mise à jour de MySQL :
Pour chaque modification mineure, le dernier numéro de la chaîne de version est incrémenté. Lorsqu'il y a des nouvelles fonctionnalités importantes ou des incompatibilité mineures avec la version précédente, nous incrémentons le chiffre du milieu. Lorsque le format de fichier change, le premier numéro est incrémenté.
Des versions tables et testées sont publiées une à deux fois dans l'année, mais si de petits bogues apparaissent, une version qui ne va corriger que ces bogues sera publiée.
Des versions fonctionnelles avec des corrections de bogues pour les vieilles versions sont publiées toutes les 1 à 8 semaines.
Les distributions binaires de certaines plates-formes seront compilées par nos soins pour les versions majeures. D'autres personnes font des versions binaires pour d'autres systèmes, mais probablement moins fréquemment.
Nous rendons généralement public les correctifs, une fois que nous avons découverts de petits bogues. Ils sont postés sur le serveur de versions BitKeeper et seront ajoutés à la prochaine version.
Si il y a un bogue fatal dans une version, nous publierons une nouvelle version aussitôt que possible. Nous apprécions que les autres éditeurs fasse la même chose.
Nous mettons beaucoup d'efforts et de temps à la publication de version sans bugs. A notre connaissance, nous n'avons jamais publié une version de MySQL qui contienne un bug fatal connu et reproductible.
Un bug fatal est un problème qui fait planter MySQL en utilisation normale, fournit des réponses erronées à des requêtes classiques, ou a des problèmes de sécurité.
Nous documentons tous les problèmes ouverts, bugs et tout ce qui dépend des choix de conceptions. See Section 1.5.7, « Erreurs connues, et limitations de MySQL ».
Nous avons pour but de corriger tout ce qui peut être corrigé, sans risquer la stabilité des versions de MySQL. Dans certains cas, cela signifie que nous pouvons corriger une erreur dans la version de développement, mais pas dans la version stable. Naturellement, nous documentons ces problèmes, pour que les utilisateurs soient avertis.
Voici une description de notre processus de publication :
Nous surveillons les bugs sur les listes de support utilisateur, les listes externes et la base de données de bugs sur le site http://bugs.mysql.com/.
Tous les bugs rapportés pour les versions en production entrent dans la base de données des bugs.
Lorsque nous corrigeons un bug, nous essayons de réaliser un cas de test, que nous incluons dans notre système de tests, pour nous assurer que le bugs ne reviendra jamais (environ 90% des bugs ont des cas de tests).
Nous créons aussi des cas de tests pour toutes les nouvelles fonctionnalités que nous voulons ajouter à MySQL.
Avant de commencer à compiler une nouvelle version de MySQL, nous nous assurons que tous les bugs reproductibles pour les versions anciennes (3.23.x, 4.0.x, etc...) sont corrigés. Si le bug ne peut être corrigé (pour des raisons de choix de conception), nous le documentons dans le manuel. See Section 1.5.7, « Erreurs connues, et limitations de MySQL ».
Nous compilons MySQL sur toutes les plates-formes pour lesquelles nous distribuons des paquets binaires (plus de 15 plates-formes à ce jour), et nous exécutons notre suite de tests et notre suite de performances sur chacune d'entre elles.
Nous ne publions pas un paquet binaire sur une plate-forme pour laquelle la suite de test ou de performances échoue. Si c'est une erreur générale, nous la corrigeons, et nous recommen¸ons les tests sur toutes les plates-formes, à partir de zéro.
Si nous recevons, durant le temps de compilation et de tests qui peut prendre deux à trois jours, un rapport de bugs concernant un bug fatal (par exemple, un bogue qui crée un coredump), nous le corrigeons, et nous recommen¸ons le processus de tests.
Après avoir publié les paquets binaires sur
http://www.mysql.com/, nous envoyons une annonce par email
aux listes de diffusion. See
Section 1.4.1.1, « Les listes de diffusion de MySQL ». Le message d'annonce
contient une liste de toutes les changements de la
version, et de tous les bugs connus. La section des
problèmes connus, ‘known
problems’, dans les notes de publications
n'a été utilisé que dans quelques versions.
Pour donner rapidement accès aux dernières fonctionnalités de MySQL, nous réalisons une publication de MySQL toutes les 4 à 5 semaines. http://downloads.mysql.com/snapshots.php.
Si, après une publication, nous recevons des rapports de
bugs qui prouvent qu'il y a, malgré tout, un bug critique
dans une version spécifique à une plate-forme, nous le
corrigeons rapidement, et nous annon¸ons une version
'a' pour la plate-forme. Grâce à
notre large communauté d'utilisateurs, les problèmes
sont trouvés rapidement.
Nos résultats de bonne publication sont excellents. Dans
les dernières 150 versions, nous avons dû reprendre la
compilation moins de 10 fois (dans trois des cas, le bug
était dû à glibc sur l'une de nos
machines de tests, qu'il a été difficile de trouver.
MySQL AB, propose un jeu de distributions binaires de MySQL qui sont compilés sur nos machines, ou les machines auxquelles nos clients nous ont gracieusement donné accès.
En plus des versions binaires adaptées à chaque plate-forme,
(See Section 2.2, « Installation standard rapide de MySQL ».), nous
proposons aussi des distributions binaires au format
.tar.gz.
Pour les distributions Windows, voyez Section 2.2.1, « Installer MySQL sous Windows ».
Ces distributions sont générées avec le script
Build-tools/Do-compile qui compile le code
source, et crée l'archive tar.gz en
utilisant le script
scripts/make_binary_distribution.
Ces archives sont configurés et compilées avec les options
suivantes. Cette information peut aussi être obtenue en
lisant les variables COMP_ENV_INFO et
CONFIGURE_LINE dans le script
bin/mysqlbug, disponible dans toutes les
distributions binaires tar.
Les programmes suivants ont été compilés par les équipes de MySQL AB :
Linux 2.4.xx x86 avec gcc 2.95.3 :
CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc
CXXFLAGS="-O2 -mcpu=pentiumpro -felide-constructors"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler --disable-shared
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
Linux 2.4.xx Intel Itanium 2 avec ecc
(Intel C++ Itanium Compiler 7.0) :
CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline"
CXX=ecc CXXFLAGS="-O2 -tpp2 -ip -nolib_inline" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client
--enable-local-infile
Linux 2.4.xx Intel Itanium avec ecc
(Intel C++ Itanium Compiler 7.0) :
CC=ecc CFLAGS=-tpp1 CXX=ecc CXXFLAGS=-tpp1
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile
Linux 2.4.xx alpha avec ccc (Compaq C
V6.2-505 / Compaq C++ V6.3-006) :
CC=ccc CFLAGS="-fast -arch generic" CXX=cxx
CXXFLAGS="-fast -arch generic -noexceptions -nortti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-mysqld-ldflags=-non_shared
--with-client-ldflags=-non_shared
--disable-shared
Linux 2.x.xx ppc avec gcc 2.95.4 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
Linux 2.4.xx s390 avec gcc 2.95.3 :
CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2
-felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared --with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
Linux 2.4.xx x86_64 (AMD64) avec gcc
3.2.1 :
CXX=gcc ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
Sun Solaris 8 x86 avec gcc 3.2.3 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
Sun Solaris 8 SPARC avec gcc 3.2 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-z-libs=no --with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 8 SPARC 64-bit avec gcc
3.2 :
CC=gcc CFLAGS="-O3 -m64 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -m64 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-z-libs=no --with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 9 SPARC avec gcc 2.95.3 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--with-named-curses-libs=-lcurses
--disable-shared
Sun Solaris 9 SPARC avec cc-5.0 (Sun
Forte 5.0) :
CC=cc-5.0 CXX=CC ASFLAGS="-xarch=v9" CFLAGS="-Xa
-xstrconst -mt -D_FORTEC_ -xarch=v9" CXXFLAGS="-noex -mt
-D_FORTEC_ -xarch=v9" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=no
--enable-thread-safe-client --disable-shared
IBM AIX 4.3.2 ppc avec gcc 3.2.3 :
CFLAGS="-O2 -mcpu=powerpc -Wa,-many " CXX=gcc
CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --disable-shared
IBM AIX 4.3.3 ppc avec xlC_r (IBM
Visual Age C/C++ 6.0) :
CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2
-qmaxmem=8192" CXX=xlC_r CXXFLAGS ="-ma -O2 -qstrict
-qoptimize=2 -qmaxmem=8192" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared --with-innodb
IBM AIX 5.1.0 ppc avec gcc 3.3 :
CFLAGS="-O2 -mcpu=powerpc -Wa,-many" CXX=gcc
CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--with-server-suffix="-pro" --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared
IBM AIX 5.2.0 ppc avec xlC_r (IBM
Visual Age C/C++ 6.0) :
CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2
-qmaxmem=8192" CXX=xlC_r CXXFLAGS="-ma -O2 -qstrict
-qoptimize=2 -qmaxmem=8192" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared --with-embedded-server
--with-innodb
HP-UX 10.20 pa-risc1.1 avec gcc 3.1 :
CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC"
CXX=gcc CXXFLAGS="-DHPUX -I/opt/dce /include
-felide-constructors -fno-exceptions -fno-rtti -O3 -fPIC"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-pthread
--with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC
--disable-shared
HP-UX 11.00 pa-risc avec aCC (HP ANSI
C++ B3910B A.03.50) :
CC=cc CXX=aCC CFLAGS=+DAportable
CXXFLAGS=+DAportable ./configure --prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
HP-UX 11.11 pa-risc2.0 64bit avec aCC
(HP ANSI C++ B3910B A.03.33) :
CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
HP-UX 11.11 pa-risc2.0 32bit avec aCC
(HP ANSI C++ B3910B A.03.33) :
CC=cc CXX=aCC CFLAGS="+DAportable"
CXXFLAGS="+DAportable" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
HP-UX 11.22 ia64 64bit avec aCC (HP
aC++/ANSI C B3910B A.05.50) :
CC=cc CXX=aCC CFLAGS="+DD64 +DSitanium2"
CXXFLAGS="+DD64 +DSitanium2" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-embedded-server --with-innodb
Apple Mac OS X 10.2 powerpc avec gcc
3.1 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
FreeBSD 4.7 i386 avec gcc 2.95.4 :
CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--enable-assembler --with-named-z-libs=not-used
--disable-shared
FreeBSD 4.7 i386 avec LinuxThreads et
gcc 2.95.4 :
CFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98
-D_REENTRANT -D_THREAD_SAFE
-I/usr/local/include/pthread/linuxthreads"
CXXFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98
-D_REENTRANT -D_THREAD_SAFE
-I/usr/local/include/pthread/linuxthreads" ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--enable-thread-safe-client --enable-local-infile
--enable-assembler
--with-named-thread-libs="-DHAVE_GLIBC2_STYLE_GETHOSTBYNAME_R
-D_THREAD_SAFE -I /usr/local/include/pthread/linuxthreads
-L/usr/local/lib -llthread -llgcc_r" --disable-shared
--with-embedded-server --with-innodb
QNX Neutrino 6.2.1 i386 avec gcc
2.95.3qnx-nto 20010315 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
Les paquets binaires suivants sont compilés sur des systèmes que des tiers prêtent gracieusement à MySQL AB. Notez que ces paquets sont fournis gracieusement. Comme MySQL AB n'a pas le contrôle complet sur ces systèmes, nous ne pouvons proposer qu'un support limité.
SCO Unix 3.2v5.0.6 i386 avec gcc
2.95.3 :
CFLAGS="-O3 -mpentium" LDFLAGS=-static CXX=gcc
CXXFLAGS="-O3 -mpentium -felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared
SCO OpenUnix 8.0.0 i386 avec CC 3.2 :
CC=cc CFLAGS="-O" CXX=CC ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared
Compaq Tru64 OSF/1 V5.1 732 alpha avec
cc/cxx (Compaq C V6.3-029i / DIGITAL
C++ V6.1-027) :
CC="cc -pthread" CFLAGS="-O4 -ansi_alias
-ansi_args -fast -inline speed -speculate all" CXX="cxx
-pthread" CXXFLAGS="-O4 -ansi_alias -fast -inline speed
-speculate all -noexceptions -nortti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-prefix=/usr/local/mysql
--with-named-thread-libs="-lpthread -lmach -lexc -lc"
--disable-shared
--with-mysqld-ldflags=-all-static
SGI Irix 6.5 IP32 avec gcc 3.0.1 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--disable-shared
FreeBSD/sparc64 5.0 avec gcc 3.2.1 :
CFLAGS=-DHAVE_BROKEN_REALPATH ./configure
--prefix=/usr/local/mysql
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --disable-shared
--with-innodb
Les options suivantes de compilations ont été utilisées pour les paquets binaires de MySQL, qui étaient fournis auparavant. Ces paquets ne sont plus mis à jours, mais les options de compilation sont conservées ici pour mémoire.
Linux 2.2.xx SPARC avec egcs 1.1.2 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer"
CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --enable-assembler
--disable-shared
Linux 2.2.x avec x686 avec gcc
2.95.2 :
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3
-mpentiumpro -felide-constructors -fno-exceptions
-fno-rtti" ./configure --prefix=/usr/local/mysql
--enable-assembler --with-mysqld-ldflags=-all-static
--disable-shared --with-extra-charsets=complex
SunOS 4.1.4 2 sun4c avec gcc 2.7.2.1 :
CC=gcc CXX=gcc CXXFLAGS="-O3
-felide-constructors" ./configure
--prefix=/usr/local/mysql --disable-shared
--with-extra-charsets=complex --enable-assembler
SunOS 5.5.1 (et plus récents) sun4u avec
egcs 1.0.3a or 2.90.27 or
gcc 2.95.2 et plus récents :
CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3
-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex --enable-assembler
SunOS 5.6 i86pc avec gcc 2.8.1 :
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex
BSDI BSD/OS 3.1 i386 avec gcc
2.7.2.1 :
CC=gcc CXX=gcc CXXFLAGS=-O ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
BSDI BSD/OS 2.1 i386 avec gcc 2.7.2 :
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
AIX 2 4 avec gcc 2.7.2.2 :
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
Si vous avez des options plus optimales pour l'une des configurations précédemment listées, vous pouvez toujours nous en faire part sur la liste de distribution des développeurs. See Section 1.4.1.1, « Les listes de diffusion de MySQL ».
Les distributions RPM antérieures à la
version 3.22 de MySQL sont fournies par nos utilisateurs. A
partir de la version 3.22, les RPM sont
générés par nous chez MySQL AB.
Si vous voulez compiler une version de débogage de MySQL,
vous devez ajouter --with-debug ou
--with-debug=full aux lignes de
configurations précédentes et effacer les options
-fomit-frame-pointer.
Visitez le site de MySQL (http://www.mysql.com/) pour des informations à propos de la version courante et les instructions de téléchargement.
Notre miroir principal est situé sur http://mirrors.sunsite.dk/mysql/.
Pour une liste complète et à jour des miroirs web/téléchargement de MySQL, voyez http://www.mysql.com/downloads/mirrors.html. Vous trouverez là des informations à propos des futurs miroirs et de quoi nous informer de la non-validité de l'un d'entre eux.
Une fois que vous avez téléchargé le paquet MySQL qui vous convient, et avant de l'installer, vous devriez vous assurer qu'il est intact, et n'a pas été altéré.
MySQL AB propose deux moyens de vérifier l'intégrité :
Signatures MD5
Signatures chiffrées avec GnuPG,
GNU Privacy Guard
Pour les paquets RPM, le mécanisme de
vérification d'intégrité intégré.
Les sections suivantes décrivent comment utiliser ces méthodes.
Dans le cas où vous vous apercevez que la somme de contrôle
MD5 checksum ou la signature
GPG ne correspond pas, essayez de
télécharger à nouveau le même paquet, éventuellement depuis
un autre miroir. Si vous échouez plusieurs fois à vérifier
l'intégrité du paquet, faites nous part de votre problème, en
incluant le nom complet du paquet désiré, et les sites de
téléchargement que vous avez utilisé. Envoyez nous un
courriel à l'adresse <webmaster@mysql.com> ou
<build@mysql.com>.
Une fois que vous avez téléchargé le paquet, vous devez vérifier si la somme de contrôle MD5 correspond à celle qui est disponibles sur le site de MySQL. Chaque paquet a une somme de contrôle individuelle, que vous pouvez obtenir avec la commande suivante :
shell> md5sum <paquet>
Exemple :
shell> md5sum mysql-standard-4.0.17-pc-linux-i686.tar.gz
60f5fe969d61c8f82e4f7f62657e1f06
mysql-standard-4.0.17-pc-linux-i686.tar.gz
Ainsi, vous devez vérifier si la somme de contrôle résultante correspond à celle qui est imprimée sur la page de téléchargement, en dessous du paquet téléchargé.
Notez que tous les systèmes d'exploitation ne supportent pas
la commande md5sum : sur certains, elle
s'appelle simplement md5, sur d'autre, elle
n'est pas du tout disponible. Sur Linux, elle a fait partie
des utilitaires texte GNU (GNU Text
Utilities), qui sont disponibles pour toute une
gamme de plates-formes. Vous pouvez télécharger le code
source sur le site
http://www.gnu.org/software/textutils/.
Si vous avez installé OpenSSL, vous pouvez
utiliser la commande openssl md5
<paquet> à la place. Une implémentation
DOS/Windows de la commande md5 est
disponible sur le site
http://www.fourmilab.ch/md5/.
Une méthode plus sûre pour vérifier l'intégrité d'un
paquet est d'utiliser la signatureGnuPG.
C'est une méthode plus sûre que le MD5, mais elle requiert
un peu plus de travail.
Depuis MySQL 4.0.10 (Février 2003), MySQL AB utilise
GNU Privacy Guard
(GnuPG), une alternative Open
Source du très connu Pretty Good
Privacy (PGP) par Phil
Zimmermann. Voir
http://www.gnupg.org/.
La plupart des distributions Linux dispose d'une version de
GnuPG installée par défaut. Pour plus de
détails sur OpenPGP, voir
http://www.openpgp.org/.
Pour vérifier la signature d'un paquet spécifique, vous devez obtenir en premier lieu une copie de la clé publique GPG. Vous pouvez soit la copier/coller directement depuis ce manuel, ou la demander sur le serveur http://www.keyserver.net/.
Key ID:
pub 1024D/5072E1F5 2003-02-03
MySQL Package signing key (www.mysql.com) <build@mysql.com>
Fingerprint: A4A9 4068 76FC BD3C 4567 70C8 8C71 8D3B 5072 E1F5
Public Key (ASCII-armored):
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
mQGiBD4+owwRBAC14GIfUfCyEDSIePvEW3SAFUdJBtoQHH/nJKZyQT7h9bPlUWC3
RODjQReyCITRrdwyrKUGku2FmeVGwn2u2WmDMNABLnpprWPkBdCk96+OmSLN9brZ
fw2vOUgCmYv2hW0hyDHuvYlQA/BThQoADgj8AW6/0Lo7V1W9/8VuHP0gQwCgvzV3
BqOxRznNCRCRxAuAuVztHRcEAJooQK1+iSiunZMYD1WufeXfshc57S/+yeJkegNW
hxwR9pRWVArNYJdDRT+rf2RUe3vpquKNQU/hnEIUHJRQqYHo8gTxvxXNQc7fJYLV
K2HtkrPbP72vwsEKMYhhr0eKCbtLGfls9krjJ6sBgACyP/Vb7hiPwxh6rDZ7ITnE
kYpXBACmWpP8NJTkamEnPCia2ZoOHODANwpUkP43I7jsDmgtobZX9qnrAXw+uNDI
QJEXM6FSbi0LLtZciNlYsafwAPEOMDKpMqAK6IyisNtPvaLd8lH0bPAnWqcyefep
rv0sxxqUEMcM3o7wwgfN83POkDasDbs3pjwPhxvhz6//62zQJ7Q7TXlTUUwgUGFj
a2FnZSBzaWduaW5nIGtleSAod3d3Lm15c3FsLmNvbSkgPGJ1aWxkQG15c3FsLmNv
bT6IXQQTEQIAHQUCPj6jDAUJCWYBgAULBwoDBAMVAwIDFgIBAheAAAoJEIxxjTtQ
cuH1cY4AnilUwTXn8MatQOiG0a/bPxrvK/gCAJ4oinSNZRYTnblChwFaazt7PF3q
zIhMBBMRAgAMBQI+PqPRBYMJZgC7AAoJEElQ4SqycpHyJOEAn1mxHijft00bKXvu
cSo/pECUmppiAJ41M9MRVj5VcdH/KN/KjRtW6tHFPYhMBBMRAgAMBQI+QoIDBYMJ
YiKJAAoJELb1zU3GuiQ/lpEAoIhpp6BozKI8p6eaabzF5MlJH58pAKCu/ROofK8J
Eg2aLos+5zEYrB/LsrkCDQQ+PqMdEAgA7+GJfxbMdY4wslPnjH9rF4N2qfWsEN/l
xaZoJYc3a6M02WCnHl6ahT2/tBK2w1QI4YFteR47gCvtgb6O1JHffOo2HfLmRDRi
Rjd1DTCHqeyX7CHhcghj/dNRlW2Z0l5QFEcmV9U0Vhp3aFfWC4Ujfs3LU+hkAWzE
7zaD5cH9J7yv/6xuZVw411x0h4UqsTcWMu0iM1BzELqX1DY7LwoPEb/O9Rkbf4fm
Le11EzIaCa4PqARXQZc4dhSinMt6K3X4BrRsKTfozBu74F47D8Ilbf5vSYHbuE5p
/1oIDznkg/p8kW+3FxuWrycciqFTcNz215yyX39LXFnlLzKUb/F5GwADBQf+Lwqq
a8CGrRfsOAJxim63CHfty5mUc5rUSnTslGYEIOCR1BeQauyPZbPDsDD9MZ1ZaSaf
anFvwFG6Llx9xkU7tzq+vKLoWkm4u5xf3vn55VjnSd1aQ9eQnUcXiL4cnBGoTbOW
I39EcyzgslzBdC++MPjcQTcA7p6JUVsP6oAB3FQWg54tuUo0Ec8bsM8b3Ev42Lmu
QT5NdKHGwHsXTPtl0klk4bQk4OajHsiy1BMahpT27jWjJlMiJc+IWJ0mghkKHt92
6s/ymfdf5HkdQ1cyvsz5tryVI3Fx78XeSYfQvuuwqp2H139pXGEkg0n6KdUOetdZ
Whe70YGNPw1yjWJT1IhMBBgRAgAMBQI+PqMdBQkJZgGAAAoJEIxxjTtQcuH17p4A
n3r1QpVC9yhnW2cSAjq+kr72GX0eAJ4295kl6NxYEuFApmr1+0uUq/SlsQ==
=YJkx
-----END PGP PUBLIC KEY BLOCK-----
Vous pouvez importer cette clé dans votre trousseau de clés
publiques GPG avec la commande gpg
--import. Par exemple, si vous avez sauvé la clé
dans un fichier appelé mysql_pubkey.asc,
la commande d'importation est :
shell> gpg --import mysql_pubkey.asc
Voyez la documentation GPG pour plus de
détails sur comment travailler avec les clés publiques.
Une fois que vous avez téléchargé et importé la clé
publique, vous pouvez télécharger le paquet MySQL et la
signature qui lui est associée, sur la même page. Le fichier
de signature a pour extension .asc. Par
exemple :
| Fichier de distribution Linux | mysql-standard-4.0.17-pc-linux-i686.tar.gz |
| Fichier de signature | mysql-standard-4.0.17-pc-linux-i686.tar.gz.asc |
Assurez-vous que les deux fichiers sont stockés dans le même dossier, puis exécutez la commande suivante pour vérifier la signature du fichier :
shell> gpg --verify <package>.asc
Exemple :
shell> gpg --verify mysql-standard-4.0.17-pc-linux-i686.tar.gz.asc
gpg: Warning: using insecure memory!
gpg: Signature made Mon 03 Feb 2003 08:50:39 PM MET
using DSA key ID 5072E1F5
gpg: Good signature from
"MySQL Package signing key (www.mysql.com) <build@mysql.com>"
La mention "Good signature" (bonne
signature) indique que le paquet est correct.
Pour les paquets RPM, il n'y a pas de
signature séparée : les paquets RPM
disposent d'une signature GPG intégrée,
et d'une somme de contrôle MD5. Vous
pouvez les vérifier avec la commande suivante :
shell> rpm --checksig package_name.rpm
Exemple :
shell> rpm --checksig MySQL-server-4.0.10-0.i386.rpm
MySQL-server-4.0.10-0.i386.rpm: md5 gpg OK
Note : si vous utilisez
RPM 4.1 et qu'il se plaint que
(GPG) NOT OK (MISSING KEYS: GPG#5072e1f5)
(même si vous l'avez importé dans votre trousseau de clé),
vous devez alors importer la clé dans votre trousseau
RPM d'abord. RPM 4.1
n'utilise pas votre trousseau de clé GPG (ni GPG lui-même),
car il entretient son propre trousseau de clé (car c'est une
application de niveau système, et que le trousseau de clé
est spécifique à chaque utilisateur). Pour importer la clé
publique mysql_pubkey.asc MySQL dans
votre trousseau de clés RPM, utilisez la
commande suivante :
shell> rpm --import mysql_pubkey.asc
Cette section décrit les répertoires par défaut crées en installant les distributions binaires et les distributions de sources.
Sous Windows, le dossier d'installation par défaut est
C:\mysql, qui a la structure suivante :
| Dossier | Contenu du dossier |
bin | Clients et serveur mysqld |
data | Fichiers de log et bases de données |
Docs | Documentation |
examples | Programmes d'exemple et scripts |
include | Fichiers d'inclusion (entêtes) |
lib | Bibliothèques |
scripts | Utilitaires |
share | Fichiers de messages d'erreur |
Les installations créée sur les distributions Linux
RPM placent les fichiers dans les
sous-dossiers suivants :
| Dossier | Contenu du dossier |
/usr/bin | Programmes clients |
/usr/sbin | serveur mysqld |
/var/lib/mysql | Fichiers de log et bases de données |
/usr/share/doc/packages | Documentation |
include | Fichiers d'inclusion (entêtes) |
lib | Bibliothèques |
/usr/share/mysql | Fichiers de messages d'erreurs et jeux de caractères |
sql-bench | Suites de tests |
Sous Unix, une archive tar avec la
distribution binaire s'installe en la désarchivant dans le
dossier d'installation que vous voulez (typiquement le dossier
/usr/local/mysql) et crée les dossiers
suivants au même endroit :
| Dossier | Contenu du dossier |
bin | Clients et serveur mysqld |
data | Fichiers de log et bases de données |
docs | Documentation, historique |
include | Fichiers d'inclusion (entêtes) |
lib | Bibliothèques |
scripts | mysql_install_db |
share/mysql | Fichiers de messages d'erreur |
sql-bench | Suites de tests |
Une distribution source est installée après compilation. Par
défaut, les étapes d'installation installent les fichiers dans
/usr/local, dans les sous-dossiers
suivants :
| Dossier | Contenu du dossier |
bin | Programmes clients et scripts |
include/mysql | Fichiers d'inclusion (entêtes) |
info | Documentation |
lib/mysql | Bibliothèques |
libexec | The serveur mysqld |
share/mysql | Fichiers de messages d'erreur |
sql-bench | Suites de tests |
var | Fichiers de log et bases de données |
Dans le répertoire d'installation, les dispositions d'une installation des sources diffère d'une installation binaire des fa¸ons suivantes :
Le serveur mysqld est installé dans le
répertoire libexec plutôt que dans le
répertoire bin.
Le répertoire des données est var
plutôt que data.
mysql_install_db est installé dans le
répertoire /usr/local/bin plutôt que
dans /usr/local/mysql/scripts.
Le répertoire des fichier d'entête et les répertoires des
bibliothèques sont include/mysql et
lib/mysql au lieu de
include et lib.
Vous pouvez créer votre propre installation binaire à partir
d'une distribution de sources compilées en exécutant le script
scripts/make_binary_distribution.
Cette section couvre l'installation de MySQL sur les plate-formes pour lesquelles nous offrons un système d'installation spécifique. Cela s'appelle aussi une installation binaire. Toutefois, des installation binaires sont disponibles pour de nombreux autres plate-formes. Voyez Section 2.3, « Installer MySQL sur d'autres systèmes type Linux » pour des instructions génériques, qui s'appliqueront aussi à ces plate-formes.
Voyez Section 2.1, « Notes générales à propos de l'installation » pour plus d'informations sur les autres distributions binaires qui sont disponibles, et comment les obtenir.
Le processus d'installation de MySQL sous Windows est le suivant :
Installez la distribution.
Configurez un fichier d'options si nécessaire.
Sélectionnez un serveur à utiliser.
Lancez le serveur.
Assignez des mots de passe aux comptes MySQL initiaux.
MySQL pour Windows est disponible en deux formats :
La distribution binaire, qui contient un programme d'installation, qui se charge de placer tout ce qui est nécessaire.
La distribution source, qui contient tout le code et les fichiers de support pour compiler les exécutables avec VC++ 6.0.
En général, vous devriez utiliser la distribution binaire. Elle est plus facile à installer, et vous n'avez besoin d'aucun autre outil pour faire fonctionner MySQL.
Cette section décrit comment installer MySQL sur Windows en utilisant la distribution binaire. Pour installer une distribution source, voyez Section 2.4.6, « La distribution source Windows ».
Pour utiliser MySQL sur Windows, vous avez besoin de :
Un système d'exploitation 32 bits Windows, tels que 9x,
Me, NT, 2000 ou XP. La famille NT (Windows
NT/2000/XP) vous permet de faire fonctionner
MySQL comme un service. See
Section 2.2.9.1, « Lancer MySQL comme un service Windows ».
Support du protocole TCP/IP.
Une copie de la distribution binaire MySQL pour Windows, qui peut être téléchargé sur http://www.mysql.com/downloads/. See Section 2.1.3, « Comment obtenir MySQL ? ».
Note : les fichiers de la distribution sont fournis dans un format compressé, et nous vous recommandons d'utiliser le client FTP approprié, avec des capacités de reprise sur erreur, pour éviter les corruptions d'archive au cours du téléchargement.
WinZip ou un programme
ZIP pour décompresser l'archive
.zip.
Assez d'espace sur votre disque pour décompresser l'archive, et pour créer les bases selon vos besoins.
Si vous envisagez d'utiliser MySQL via ODBC, vous aurez
aussi besoin du pilote MyODBC. See
Section 25.1.1.1, « Qu'est-ce que ODBC? ».
Si vous avez besoin de table d'une taille supérieure à 4
Go, installez MySQL sur un système de fichier NTFS ou
plus récent. N'oubliez pas d'utiliser les options
MAX_ROWS et
AVG_ROW_LENGTH lorsque vous créez les
tables. See Section 13.2.5, « Syntaxe de CREATE TABLE ».
Depuis MySQL 4.1.5, il y a trois paquets d'installation à choisir avant d'installer MySQL sur Windows. Les paquets sont les suivants :
The Essentials Package :
ce paquet porte un nom du type
mysql-essential-4.1.9-win32.msi et
contient le minimum de fichiers nécessaire pour installer
MySQL sur Windows, y compris l'assistant de configuration.
Ce paquet n'inclut pas de composants optionnels tels que le
serveur embarqué ou la suite de performances.
The Complete Package : ce
paquet porte un nom du type
mysql-4.1.9-win32.zip et contient tous
les fichiers nécessaires pour créer une installation
Windows complète, y compris l'assistant de configuration.
Ce paquet inclut les composants optionnels tels que le
serveur embarqué et la suite de performances.
The Noinstall Archive : ce
paquet porte un nom du type
mysql-noinstall-4.1.9-win32.zip et
contient tous les fichiers du paquet Complete
Package, à l'exception de l'assistant de
configuration. Ce paquet n'inclut pas l'installeur
automatique, et doit être manuellement installé et
configuré.
Le paquet Essentials Package est recommandé
pour la plupart des utilisateurs.
Votre choix de paquet d'installation affecte le processus
d'installation. Si vous choisissez les paquets
Essentials Package ou Complete
Packages, voyez
Section 2.2.3, « Installer MySQL avec l'assistant automatique ». Si vous choisissez
l'installation de MySQL avec le paquet Noinstall
Archive, voyez
Section 2.2.6, « Installer MySQL à partir d'une archive ZIP sans assistant ».
Depuis MySQL 4.1.5, les utilisateurs peuvent utiliser les
nouveaux assistants MySQL Installation Wizard
et MySQL Configuration Wizard pour installer
MySQL sur Windows. MySQL Installation Wizard
et MySQL Configuration Wizard sont con¸us
pour installer et configurer MySQL pour qu'un nouvel utilisateur
puisse immédiatement commencer à utiliser MySQL.
MySQL Installation Wizard et MySQL
Configuration Wizard sont disponibles parmi les
paquets d'installations essentiels et complets : ils sont
recommandés pour la plupart des installations standards de
MySQL. Les exceptions sont les utilisateurs qui ont besoin de
plusieurs instances de serveurs MySQL sur un serveur, et des
utilisateurs experts qui veulent avoir le contrôle de leur
configuration.
Si vous installer une version de MySQL antérieure à la version
4.1.5, suivez les instructions d'installation de MySQL à partir
des paquets Noinstall. See
Section 2.2.6, « Installer MySQL à partir d'une archive ZIP sans assistant ».
L'assistant d'installation MySQL est un nouvel installeur pour le serveur MySQL, qui utilise les dernières technologies de Microsoft Windows. L'assistant d'installation de MySQL, combiné à l'assistant de configuration MySQL, permet à l'utilisateur d'installer et de configurer un serveur MySQL prêt à l'emploi dès son installation.
L'assistant d'installation MySQL est l'installeur standard de toutes les distributions MySQL à partir de la version 4.1.5. Les utilisateurs des anciennes versions doivent faire l'installation manuellement, en éteignant le serveur, suppramant leur installation existante avant d'installer la nouvelle version. Voyez la section Section 2.2.4.7, « Mise à jour de MySQL » pour plus d'informations sur la mise à jour depuis les anciennes versions.
Microsoft a inclut une version améliorée de leur
Microsoft Windows Installer
(MSI) dans les versions récentes de
Windows. L'utilisation de MSI est devenu le
standard de fait pour les applications sur Windows 2000,
Windows XP et Windows Server 2003. L'assistant d'installation
MySQL utilise cette technologie pour améliorer et simplifier
le processus d'installation.
Le Microsoft Windows Installer Engine a
été mise à jour avec la version Windows XP; ceux qui
utilisent un version antérieure de Windows peuvent
se
reporter à cet article de la Microsoft Knowledge Base
pour plus d'informations sur la mise à jour de Windows
Installer Engine.
De plus, Microsoft a introduit le WiX
(Windows Installer XML) récemment. C'est
le premier projet Open Source de Microsoft qui soit
recommandé. Nous sommes passé à WiX car c'est un projet
Open Source, et qu'il nous permet de gérer entièrement le
processus d'installation sur Windows de manière souple, via
des scripts.
L'amélioration de l'assistant d'installation de MySQL dépend du support et des rapports que les utilisateurs comme vous font. Si vous trouvez que l'assistant d'installation MySQL manque de certaines fonctionnalités vitales, ou si vous rencontrez un bogues, utilisez notre notre système de rapport de bogues pour demander une nouvelle fonctionnalité ou une correction de problème.
Les paquets d'installation du serveur MySQL sont disponibles au téléchargement sur le site http://dev.mysql.com/downloads/. Si le paquet que vous téléchargez est une archive Zip, il faudra commencer par décompresser cette archive.
Le processus de lancement de l'assistant dépend du contenu du
paquet d'installation que vous téléchargez. S'il existe un
fichier setup.exe, faites un double-clic
dessus pour le lancer. S'il y a un fichier
.msi, faites un double-clic dessus pour
lancer l'installation.
Il y a trois types d'installations disponibles : le standard
Typical, le complet
Complete et le personnalisé
Custom.
L'installation Typical installe le serveur
MySQL, le client en ligne de commande mysql
et les utilitaires de ligne de commande. Les utilitaires en
ligne de commande incluent mysqldump,
myisamchk et plusieurs autres outils pour
vous aider à gérer le serveur MySQL.
L'installation Complete installe tous les
composants du paquet d'installation. L'installation complète
inclut des composants tels que les bibliothèques embarquées,
les tests de performances, les scripts de support et la
documentation.
L'installation personnalisée Custom vous
donne le contrôle sur les composants que vous voulez
installer, et le chemin de l'installation. Voyez
Section 2.2.4.4, « Le dialogue d'installation personnalisée » pour
plus de détails sur ce type d'installation.
Si vous choisissez les installations
Typical ou Complete et
que vous cliquez sur le bouton Next, vous
irez directement à l'écran de confirmation, et vous
débuterez l'installation. Si vous choisissez l'installation
Custom, le dialogue d'installation
personnalisée se affiché, tel que présenté dans
Section 2.2.4.4, « Le dialogue d'installation personnalisée »
Si vous voulez changer le nom du dossier d'installation ou
installer un composant spécifique, il faut utiliser
l'installation personnalisée Custom.
Tous les composants disponibles sont listés dans un arbre
hiérarchisé à gauche du dialogue d'installation. Les
composants qui ne seront pas installés ont une icône rouge
X, et les composants qui sont déjà
installés ont une icône grisée. Pour installer un nouveau
composant, il faut cliquer sur l'icône du composant, et
choisir une nouvelle option dans la liste déroulante qui
apparaît.
Vous pouvez changer le chemin d'installation par défaut en
cliquant sur le bouton Change... à droite
du chemin d'installation affiché.
Après avoir fait le choix des composants à installer et du
dossier d'installation, cliquez sur le bouton
Next pour passer au dialogue de
confirmation.
Une fois que vous avez choisi un type d'installation et que vous avez choisi tous vos composants à installer, vous passez au dialogue de confirmation. Le type d'installation et les options sont présentés pour que vous puissiez le vérifier.
Pour installer MySQL dès que vous êtes satisfait de vos choix, cliquez sur le bouton 'install'. Pour modifier vos options, cliquez sur le bouton 'Back'. Pour quitter l'assistant d'installation MySQL, cliquez sur le bouton 'Cancel'.
Une fois l'installation terminée, vous pouvez vous enregistrer sur le site Web de MySQL. L'enregistrement vous donne accès aux forums à l'URL forums.mysql.com, ainsi qu'aux rapports de bogues à l'URL bugs.mysql.com et à l'inscription des lettres d'informations. Le dernier écran de l'installeur fournit un résumé de l'opération, et vous donne l'occasion de lancer l'assistant de configuration de MySQL, qui vous servira à créer un fichier de configuration, à installer un service MySQL et à mettre en place les sécurités.
Une fois que vous avez cliqué sur le bouton d'installations,
l'assistant d'installation MySQL commence
le processus d'installation et s'assure que les modifications
apportées à votre système sont celles que vous avez
demandé.
Modifications du registre
L'assistant d'installation MySQL crée une
clé dans le registre de Windows :
HKEY_LOCAL_MACHINE\SOFTWARE\MySQL AB.
L'assistant d'installation MySQL crée une
clée à partir du numéro de version majeur du serveur en
cours d'installation, tel que MySQL Server
4.1. Elle contient deux valeurs, les chaînes
Location et Version. La
chaîne Location contient le chemin
jusqu'au dossier d'installation. Dans une installation par
défaut, elle contient C:\Program Files\MySQL\MySQL
Server 4.1\. La chaîne Version
contient le numéro de version. Par exemple, pour une
installation de MySQL Server 4.1.5, la clé
contient la valeur 4.1.5.
Les clés du registre servent aux outils externes pour
identifier le dossier d'installation, évitant ainsi une
recherche dans l'ensemble du disque dur pour déterminer le
bon dossier. Les clés de registre ne sont pas obligatoires
pour faire fonctionner le serveur, et lorsque vous faites une
installation noinstall, ces clés ne sont
pas créées.
Modification dans le menu de démarrage
L'assistant d'installation MySQL crée une
nouvelle entrée dans le menu de démarrage de Windows, sous
le nom commun de MySQL que vous avez installé. Par exemple,
si vous installez MySQL 4.1,
l'assistant d'installation MySQL crée une
section MySQL Server 4.1.
Les éléments suivants sont créés dans ce menu :
MySQL Command Line Client : c'est un
raccourci vers le client de ligne de commande
mysql et il est configuré pour se
connecter en tant que root. Le
raccourci demande le mot de passe de
root.
MySQL Server Instance Config Wizard :
ceci est un raccourci vers l'assistant de
configuration MySQL. Utilisez ce raccourci pour
configurer un nouveau serveur ou reconfigurer un serveur
en fonctionnement.
Documentation MySQL : ceci est un lien
vers la documentation du serveur MySQL qui est stockée
localement dans le dossier d'installation. Cette option
n'est pas disponible lorsque le serveur est installié
avec le paquet essential.
Modifications dans le système de fichiers
L'assistant d'installation MySQL installe
le serveur MySQL dans le dossier
C:\, où
Program
Files\MySQL\MySQL Server
4.1Program Files est le dossier par
défaut pour les applications sur votre système et
4.1 est la version majeure du
serveur. C'est l'emplacement recommandé pour le serveur
MySQL, qui remplace le dossier précédent de
c:\mysql.
Par défaut, toutes les applications MySQL sont stockées dans
le dossier C:\, où Program
Files\MySQLProgram
Files est le dossier pour les applications sur
votre système Windows. Une installation typique de MySQL sur
une machine ressemble à ceci :
C:\Program Files\MySQL\MySQL Server 4.1 C:\Program Files\MySQL\MySQL Server 5.0 C:\Program Files\MySQL\MySQL Administrator 1.0 C:\Program Files\MySQL\MySQL Query Browser 1.0
Cette approche rend plus simple la gestion et l'entretien des applications MySQL sur un système Windows.
Depuis MySQL 4.1.5, le nouvel assistant d'installation MySQL peut réaliser automatiquement des installations en exploitant des capacités de MSI. Cela signifie que vous n'avez pas à modifier l'ancienne installation manuellement, avant de faire une nouvelle installation. L'installeur se charge d'éteindre automatiquement le serveur et de le supprimer avant d'installer la nouvelle version.
Les mises à jour automatiques sont uniquement disponibles lors de la mise à jour entre deux installations qui ont le même numéro de version majeure et mineure. Par exemple, vous pouvez mettre à jour automatiquement le serveur depuis MySQL 4.1.5 vers MySQL 4.1.6, mais pas de MySQL 4.1 vers MySQL 5.0.
Si vous passez de version MySQL 4.1.4 ou plus ancien à la version 4.1.5 ou plus récent, vous devez commencer par manuellement éteindre le serveur et supprimer l'ancienne installation avant de faire la mise à jour. Assurez-vous de sauver les bases de données avant de faire une telle mise à jour, pour que vous puissiez restaurer les données après la migration. Il est toujours recommandé de faire une sauvegarde des données avant de faire une mise à jour.
assistant de configuration MySQLInnoDBmy.inimy.ini
L'assistant de configuration MySQL vous
aide dans le processus de configuration de votre serveur MySQL
sous Windows. L'assistant de configuration
MySQL crée un fichier my.ini
personnalisé en vous posant différentes questions, et en
enregistrant vos réponses dans un fichier
my.ini modèle.
L'assistant de configuration MySQL est
inclut avec le serveur MySQL depuis MySQL version 4.1.5, mais
il est con¸u pour fonctionner avec les versions 4.1 ou plus
récent. L'assistant de configuration MySQL
est actuellement disponible uniquement pour Windows.
L'assistant de configuration MySQL est,
pour l'essentiel, le résultat des retours que MySQL
AB a re¸u de nombreux utilisateurs depuis quelques
années. Cependant, si vous pensez que ce logiciel manque de
fonctionnalités importantes pour vous, ou si vous rencontrez
un bogue, utilisez notre système
MySQL Bug System
pour demander une nouvelle fonctionnalité ou rapporter un
problème.
L'assistant de configuration MySQL est
simplement lancé lorsque l'assistant d'installation
MySQL se termine. Vous pouvez aussi lancer le
l'assistant de configuration MySQL en
cliquant sur l'élément du programme dans le menu démarrer.
De plus, vous pouvez vous rendre dans le dossier
bin du dossier d'installation de MySQL pour
lancer manuellement le programme
MySQLInstanceConfig.exe.
Si l'assistant de configuration MySQL
détecte un fichier my.ini, vous aurez
l'option de reconfigurer votre serveur ou de supprimer cette
instance du fichier my.ini, stopper et
supprimer le serveur MySQL.
Pour reconfigurer un serveur existant, choisissez l'option
Re-configure Instance et cliquez sur le
bouton de suite. Votre fichier my.ini
actuel sera renommé en
my,
où timestamp.ini.baktimestamp est la date et
l'heure où le fichier my.ini a été
créé. Pour supprimer l'instance actuelle du serveur,
choisissez l'option Remove Instance et
cliquez sur le bouton Next.
Si vous choisissez l'option Remove
Instance, vous passez à une fenêtre de
confirmation. Cliquez sur le bouton d'exécution, et
l'assistant de configuration MySQL va
arrêter et supprimer le serveur MySQL, puis effacer le
fichier my.ini. L'installation du serveur
et le dossier de données data ne sont pas
touchés.
Si vous choisissez l'option Re-configure
Instance, vous passez au dialogue de
Configuration du type où vous pouvez
choisir le type d'installation à configurer.
Lorsque vous lancez l'assistant de configuration
MySQL pour une nouvelle installation ou que vous
choisissez l'option Re-configure Instance
pour une installation existante, vous passez au dialogue
Configuration Type.
Il y a deux types de configuration disponibles :
Detailed Configuration et Standard
Configuration. L'option Standard
Configuration sert aux nouveaux utilisateurs qui
veulent lancer rapidement MySQL sans avoir à prendre beaucoup
de décisions concernant la configuration du serveur. L'option
Detailed Configuration sert pour les
utilisateurs avancés qui veulent avoir le contrôle complet
de leur configuration.
Si vous êtes nouveaux avec MySQL et que vous voulez avoir un
serveur configuré en mode utilisateur seul, la
Standard Configuration devrait vous
convenir. Choisir l'option Standard
Configuration fait que le l'assistant de
configuration MySQL va effectuer toutes les
configurations sauf Service Options et
Security Options.
La Standard Configuration choisit des
options qui peuvent être incompatibles avec les systèmes qui
supportent déjà d'autres installations MySQL. Si vous avez
une installation MySQL sur votre système en plus de celle que
vous voulez configurer, il faut utiliser l'option
Detailed Configuration.
Pour terminer la Standard Configuration,
voyez les sections concernant les options de
service et les option de
sécurité, accessibles à
Section 2.2.5.11, « Le dialogue d'options de service » et
Section 2.2.5.12, « Le dialogue d'options de sécurité ».
Il y a différents types de serveurs disponibles et ce type
affecte les décisions prises par l'assistant de
configuration MySQL en ce qui concerne la mémoire,
le disque et l'utilisation du processeur.
Developer Machine : choisissez cette
option pour installer MySQL pour une utilisation
personnelle. L'assistant suppose qu'il y aura de
nombreuses autres applications qui fonctionneront
simultanément. Le serveur est configuré pour utiliser un
minimum de ressources.
Server Machine : choisissez cette
option pour un serveur, où MySQL fonctionne avec d'autres
applications serveurs, telles qu'un serveur FTP, email et
web. Le serveur est configuré pour utiliser une portion
raisonnable des ressources.
Dedicated MySQL Server Machine :
choisissez ce type pour une machine qui est dédiée à
MySQL. L'assistant suppose alors qu'aucune autre
application ne fonctionne, et que le serveur peut occuper
toutes les ressources disponibles.
Le dialogue Database Usage vous permet
d'indiquer les moteurs de tables que vous voulez utiliser
lorsque vous créez les tables MySQL. Les options que vous
choisissez alors détermines si le moteur InnoDB est
disponible, et quel pourcentage des ressources du serveur sont
disponibles pour ce moteur.
Multifunctional Database : cette
option active simultanément InnoDB et MyISAM et divise
les ressources équitablement entre les deux. Cette option
est recommandée pour les utilisateurs qui utilisent les
deux types de tables régulièrement.
Transactional Database Only : cette
option active les deux moteurs InnoDB et MyISAM mais
consacre plus de ressource InnoDB. Cette option est
recommandée pour les utilisateurs qui emploient
exclusivement InnoDB, et très rarement MyISAM.
Non-Transactional Database Only :
cette option désactive complètement InnoDB et consacre
toutes les ressources du serveur à MyISAM. Cette option
est recommandée pour les utilisateurs qui n'emploient pas
InnoDB.
Certains utilisateurs souhaitent ranger leurs espaces de
tables InnoDB hors du dossier de données
de MySQL. En pla¸ant ces fichiers comme cela, vous pouvez
gagner en performances ou en capacité en choisissant le bon
système de stockage, comme un système RAID, par exemple.
Pour changer le dossier par défaut des espaces de tables
InnoDB, vous devez choisir un autre volume
dans la liste disponible. Pour créer un chemin particulier,
il suffit de cliquer... sur le bouton.
Si vous modifiez la configuration d'un serveur existant, vous
devez cliquer sur le bouton de modification
Modify avant de changer le chemin. Dans la
situation où vous changez manuellement les fichiers d'espace
de table, il faut déplacer les fichiers dans leur nouveau
dossier avant de relancer le serveur.
Il est important de mettre une limite au nombre de connexions
simultanées qu'un serveur MySQL va accepter pour éviter que
le serveur ne consomme tous les processus existants. Le
dialogue Concurrent Connections vous permet
de choisir le nombre maximum d'utilisateurs sur le serveur, et
configure la limite de connexions simultanées. Il est aussi
possible de modifier manuellement cette limite.
Decision Support (DSS)/OLAP :
choisissez cette option si votre serveur ne requiert par
beaucoup de connexions simultanées. Le nombre maximal de
connexions est de 100, avec une moyenne de 20 connexions
simultanées.
Online Transaction Processing (OLTP) :
choisissez cette option si votre serveur requiert de
nombreuses connexions simultanées. Le nombre maximal de
connexions est de 500.
Manual Setting : choisissez cette
option pour spécifier manuellement le nombre maximal de
connexions concurrentes au serveur. Choisissez un nombre
de connexions dans la liste fournie, ou bien tapez
directement le nombre choisi dans cette liste.
Utilisez le dialogue Networking Options
pour activer ou désactiver la pile TCP/IP et pour confirmer
le numéro de port à utiliser pour se connecter à MySQL.
La pile TCP/IP est activée par défaut. Pour désactiver le
réseau TCP/IP, décochez la boîte Enable TCP/IP
Networking.
Le port 3306 est utilisé par éfaut. Pour changer le port utilisé pour se connecter à MySQL, choisissez un port dans la liste fournie, ou tapez un nouveau numéro de port directement dans cette zonne. Si le numéro de port que vous choisissez est déjà utilisé, vous devre confirmer votre choix.
Le serveur MySQL supporte plusieurs jeux de caractères, et il
est possible de configurer un jeu de caractères qui sera
utilisé par défaut à toutes les tables, colonnes et bases
de données, à moins qu'il ne soit spécifié autrement.
Utilisez le dialogue Character Set pour
changer le jeu de caractères par défaut du serveur MySQL.
Standard Character Set : choisissez
cette option si vous voulez utiliser
Latin1 comme jeu de caractères par
défaut. Latin1 sert pour l'anglais et
la plupart des langues occidentales.
Best Support For Multilingualism :
choisissez cette option si vous voulez utiliser
UTF8 comme jeu de caractères par
défaut. UTF8 peut stocker les
caractères de très nombreuses langues dans un même jeu.
Manual Selected Default Character Set /
Collation : choisissez cette option si vous
voulez choisir le jeu de caractères par défaut
manuellement. Choisissez le jeu de caractères souhaité
dans la liste fournie.
Sur les plates-formes Windows NT, le serveur MySQL peut être installé comme un service. Lorsque c'est le cas, le serveur MySQL peut être démarré automatiquement lors du lancement du serveur, et même, redémarré automatiquement par Windows dans le cas d'une panne de service.
L'assistant de configuration MySQL installe le serveur MySQL
comme service par défaut, en utilisant le service appelé
MySQL. Si vous ne voulez pas installer le service, décochez
la boîte à coté de l'option Install As Windows
Service. Vous pouvez changer le nom du service en en
donnant un nouveau dans le champ fourni ou dans le menu
déroulant proposé.
Pour installer le serveur MySQL comme un service, mais sans le
démarrage automatique au démarrage, décochez la boîte à
coté de l'option Launch the MySQL Server
automatically.
Il est recommandé de donner un mot de passe à l'utilisateur
root pour votre serveur, et
l'assistant de configuration MySQL vous
impose de configurer un mot de passe root
par défaut. Si vous ne voulez pas spécifier le mot de passe
root, il faut décocher l'option
Modify Security Settings.
Pour choisir un mot de passe root, tapez le
mot que vous voulez dans les deux champs New root
password et Confirm. Si vous
reconfigurez un serveur existant, il faut aussi indiquer le
mot de passe courant du root dans le champ
Current root password.
Pour éviter les connexions root via le
réseau, cochez l'option Root may only connect from
localhost. Cela améliore la sécurité de votre
compte root.
Pour créer un compte anonyme, cochez l'option Create
An Anonymous Account. La création d'un compte
anonyme peut réduire la sécurité de votre serveur et n'est
pas recommandée.
Le dialogue final de l'assistant de configuration
MySQL est le Confirmation Dialog.
Pour lancer le processus de configuration, cliquez sur le
bouton Execute. Pour retourner à un
dialogue précédent, cliquez sur le bouton
Back. Pour quitter l'assistant de
configuration MySQL, cliquez sur le bouton
Cancel.
Une fois que vous avez cliqué sur le bouton
Execute, l'assistant de
configuration MySQL effecture différentes tâches
et affiche sa progression à l'écran.
L'assistant de configuration MySQL
détermine différentes options de configuration en fonction
de vos choix, en utilisant un gabarit préparé par
MySQL AB. Ce gabarit est appelé
my-template.ini et est situé dans le
dossier d'installation.
L'assistant de configuration MySQL écrit
alors ces options dans le fichier my.ini.
L'emplacement final du fichier my.ini est
affiché à coté de la tâche Write configuration
file.
Si vou choisissez de créer un service pour le serveur MySQL,
l'assistant de configuration MySQL va
créer le service et le démarrer. Si vous reconfigurez un
service existant, l'assistant de configuration
MySQL va redémarrer le service pour qu'il prennent
en compte vos modifications.
Si vous choisissez de configurer un mot de passe
root, l'assistant de configuration
MySQL va se connecter au serveur, configure votre
mot de passe, et appliquer les options de sécurité que vous
lui avez spécifié.
Une fois que l'assistant de configuration
MySQL a terminé, un résumé est affiché. Cliquez
sur le bouton Finish pour terminer avec
l'assistant de configuration MySQL.
Dans les installations MySQL antérieures à la version 4.1.5,
il était de coutume de donner le nom de
my.cnf au fichier de configuration du
serveur, ou bien de le baptiser my.ini et
de placer ce fichier dans c:\my.cnf ou
c:\Windows\my.ini.
Le nouvel assistant de configuration MySQL
place le fichier my.ini dans le dossier
d'installation du serveur MySQL. Cela permet d'associer le
fichier de configuration avec la bonne instance du serveur.
Pour s'assurer que le serveur MySQL sait où trouver le
fichier my.ini, un argument similaire à
celui-ci est passé durant l'installation du service :
--defaults-file=",
où C:\Program
Files\MySQL\MySQL Server 4.1\my.ini"C:\Program Files\MySQL\MySQL Server
4.1 est remplacé par le chemin de
l'installation du serveur MySQL.
L'option --defaults-file indique au serveur
MySQL qu'il doit lire le fichier spécifié pour trouver les
options de configuration.
To modify the my.ini file, open it with a
text editor and make any necessary changes. You can also
modify the server configuration with the
http://www.mysql.com/products/administrator/ utility.
MySQL clients and utilities such as the
mysql command-line client and
mysqldump are not able to locate the
my.ini file located in the server
installation directory. To configure the client and utility
applications, create a new my.ini file in
the c:\Windows directory.
Les utilisateurs qui réalisent leur installation à partir
d'une archive sans assistant (paquet
Noinstall), ou qui installe une version
antérieure à la version 4.1.5, peuvent utiliser les
instructions de cette section pour réaliser leur installation
manuelle de MySQL. Si vous utilisez une version antérieure à
la version 4.1.5 avec une distribution qui dispose d'un
assistant, remplacez l'exécution du programme
Setup par l'extraction de l'archive.
Les instructions d'installation de MySQL à partir de l'archive ZIP sont les suivantes :
Décompressez l'archive dans le dossier d'installation souhaité.
Créez un fichier d'options.
Choisissez un type de serveur MySQL.
Démarrez le serveur MySQL.
Sécurisez les mots de passe des utilisateurs créés par défaut.
Ce processus est décrit dans les sections suivantes.
Pour installer MySQL manuellement, suivez ces instructions :
Si vous mettez à jour votre installation depuis une installation ancienne, voyez la section Section 2.2.11, « Mettre à jour MySQL sous Windows » avant de commencer le processus de mise à jour.
Si vous utilisez un serveur basé sur Windows NT, comme Windows NT, Windows 2000, Windows XP ou Windows Server 2003, assurez-vous que vous êtes connectés avec un utilisateur qui a les droits d'administration.
Choisissez un dossier d'installation. Traditionnellement, le
serveur MySQL est installé dans le dossier
C:\mysql, et le nouvel assistant
d'installation MySQL installe MySQL dans
C:\Program Files\MySQL. Si vous
n'installez pas MySQL dans C:\mysql,
vous devez spécifier le chemin jusqu'au dossier
d'installation durant le démarrage, ou bien dans un fichier
d'options. See Section 2.2.8, « Créer un fichier d'options ».
Extrayez l'archive d'installation dans le dossier d'installation, en utilisant votre outil de Zip préféré. Certains outils vont extraire l'archive dans un dossier du dossier que vous aurez désigné. Si cela arrive, il faudra déplacer le contenu de ce sous-dossier dans le dossier que vous souhaitez.
Si vous avez besoin de spécifier des options lorsque vous exécutez le serveur, vous pouvez les indiquer à la ligne de commande ou les placer dans un fichier d'options. Pour les options qui sont utilisées à chaque démarrage du serveur, il est plus pratique de les ranger dans un fichier d'options. C'est particulièrement vrai dans les situations suivantes :
Le dossier d'installation et le dossier de données sont à
des emplacements différents de leur valeur par défaut
(C:\mysql et
C:\mysql\data).
Vous devez adapter le paramétrage du serveur. Par exemple,
vous utilisez les tables transactionnelles
InnoDB de MySQL 3.23, et vous devez
manuellement ajouter des lignes d'options telles que
décrites dans Section 15.4, « Configuration InnoDB ».
(Depuis MySQL 4.0, InnoDB crée le
fichier de données et de log dans le dossier de données,
par défaut). Avoir un fichier d'options signifie que vous
n'avez plus à configurer InnoDB
explicitement. Vous pouvez toujours le faire si vous le
voulez, mais le fichier d'options est très pratique dans ce
cas.
Lorsque le serveur MySQL démarre sur Windows, il recherche les
options dans deux fichiers : le fichier
my.ini dans le dossier Windows, et le
fichier C:\my.cnf. Le dossier Windows est
typiquement C:\WINDOWS ou
C:\WinNT. Vous pouvez déterminer son
chemin exact en affichant la valeur de la variable
d'environnement WINDIR avec la commande
suivante :
C:\> echo %WINDIR%
MySQL recherche les options en premier dans le fichier
my.ini, puis dans le fichier
my.cnf. Cependant, pour éviter les
confusions, il est mieux de n'utiliser qu'un seul fichier. Si
votre PC utilise un boot loader où le volume
C: n'est pas le disque de démarrage, votre
seule issue est d'utiliser le fichier
my.ini. Quelque soit l'option que vous
utiliser, le fichier d'option est un simple fichier texte.
Vous pouvez aussi utiliser les fichiers d'options d'exemple
inclus dans votre distribution MySQL. Regardez dans le dossier
d'installation et recherchez des fichiers tels que
my-small.cnf,
my-medium.cnf,
my-large.cnf, etc., quie vous pouvez copier
ou renommer, et placer dans le chemin approprié pour avoir un
fichier de configuration de base.
Un fichier d'options peut être créé est modifié par
n'importe quel éditeur de texte, tels que
Notepad. Par exemple, si MySQL est installé
dans le dossier E:\mysql et que le dossier
de donnéest est situé dans
E:\mydata\data, vous pouvez créer un
fichier d'options et configurer la section
[mysqld] pour spécifier les valeurs de
basedir et datadir :
[mysqld] # set basedir to your installation path basedir=E:/mysql # set datadir to the location of your data directory datadir=E:/mydata/data
Notez que les noms de chemin Windows sont spécifiés dans les options avec des slash, et non pas des anti-slash. Si vous utilisez des anti-slash, il faut les doubler :
[mysqld] # set basedir to your installation path basedir=E:\\mysql # set datadir to the location of your data directory datadir=E:\\mydata\\data
Sur Windows, l'installeur MySQL place les données directement
dans le dossier où vous installez MySQL. Si vous voulez
utiliser un dossier de données différent, il faut copier
l'intégralité du dossier data dans le
nouveau chemin. Par défaut, l'installeur place MySQL dans
C:\mysql et le dossier de données dans
C:\mysql\data. Si vous voulez utiliser le
dossier E:\mydata, vous devez faire ceci :
Déplacer le dossier de données depuis
C:\mysql\data vers
E:\mydata.
Utilisez l'option --datadir pour spécifier
le nouveau dossier de données, à chaque fois que vous
lancez le serveur.
Depuis MySQL 3.23.38, la distribution Windows inclut le
serveur MySQL classique et le serveur
MySQL-Max. Voici la description de toutes
les versions livrées :
| Programme | Description |
mysqld | Compilé avec les informations de débogage, la vérification
d'allocation de mémoire, le support des liens
symboliques et les tables InnoDB et
BDB tables. |
mysqld-opt | Optimisé. Depuis la version 4.0, InnoDB est activé.
Avant la version 4.0, ce serveur incluait aucune
tables transactionnelles. |
mysqld-nt | Optimisé pour Windows NT/2000/XP avec support pour les pipes nommés. |
mysqld-max | Optimisé, avec le support des liens symboliques et des tables
InnoDB et BDB. |
mysqld-max-nt | Comme mysqld-max, mais compilé avec le support des
pipes nommés. |
Tous les serveurs précédents sont optimisés pour les processeurs Intel modernes, mais ils fonctionneront sur toutes les architectures Intel de classe i386 et plus récent.
MySQL supporte TCP/IP sur toutes les plates-formes Windows.
Les serveurs mysqld-nt et
mysql-max-nt supportent les pipes nommés
sur NT, 2000 et XP.
Cependant, par défaut, MySQL utilise TCP/IP quelque soit la
plate-forme. Les pipes nommés sont plus lents que TCP/IP.
Les pipes nommés sont sujets aux limitations suivantes :
Depuis MySQL 3.23.50, les pipes nommés sont activés
uniquement si vous lancez le serveur avec l'option
--enable-named-pipe. Il est nécessaire
d'utiliser explicitement cette option, car des
utilisateurs ont rencontré des problèmes lors de
l'extinction du serveur MySQL, avec les pipes nommés.
Les connexions par pipe nommés ne sont permises qu'avec
mysqld-nt et
mysqld-max-nt, et uniquement si le
serveur fonctionne sur une version de Windows qui supporte
les pipes nommés (NT, 2000, XP).
Ces serveurs peuvent fonctionner avec Windows 98 et Me, mais ils requièrent la pile TCP/IP; le pipes nommés seront ignorés.
Sur Windows 95, ces serveurs ne peuvent être utilisés.
Note : La plupart des
exemples dans les prochaines sections, utilisent
mysqld comme nom de serveur. Si vous
choisissez un autre nom de serveur, comme
mysqld-opt, assurez vous de bien faire les
bons remplacements dans les commandes des exemples. Une bonne
raison de choisir un nom de serveur différent est que
mysqld contient le support complet du
débogage, il utilise plus de mémoire et fonctionne plus
lentement que les autres serveurs Windows.
Sur Windows 95, 98 et Me, les clients MySQL utilisent toujours TCP/IP pour se connecter au serveur. Cela permet à toute machine du réseau de se connecter à votre serveur MySQL. A cause de cela, assurez vous que le support TCP/IP est installé avant de lancer MYSQL. Vous pouvez trouver TCP/IP dans votre CD d'installation Windows.
Notez que si vous utilisez une vieille version Windows 95 (par exemple, OSR2), il est probable que vous ayez un vieux paquet Winsock; MySQL requiert Winsock 2! Vous pouvez télécharger un nouveau paquet Winsock sur http://www.microsoft.com/. Windows 98 dispose de la bibliothèque Winsock 2, et il est donc inutile de la mettre à jour.
Sur les systèmes NT, comme Windows NT, 2000 ou XP, les clients ont deux options. Soit utiliser TCP/IP, soit les pipes nommés, si le serveur les supporte.
Pour des informations sur quel serveur choisir, voyez Section 2.2.8.1, « Choisir un serveur MySQL sur Windows ».
Cette section donne un aper¸u général du lancement du serveur MySQL. La section suivante fournit des informations spécifiques pour une version particulière de Windows.
Les exemples de ces sections supposent que MySQL est installé
dans son dossier par défaut : C:\mysql.
Adaptez les noms de chemins si vous avez installé MySQL
ailleurs.
Testez à partir d'une console DOS est la meilleure chose à faire car le serveur affiche des messages qui y apparaissent. Si quelque chose n'est pas bon dans votre configuration, ces messages vous aiderons à identifier et corriger le problème.
Assurez-vous d'être dans le répertoire où se situe le serveur, puis entrez cette commande :
C:\mysql\bin> mysqld --console
Vous devriez voir ce qui suit pendant le démarrage du serveur :
InnoDB: The first specified datafile c:\ibdata\ibdata1 did not exist: InnoDB: a new database to be created! InnoDB: Setting file c:\ibdata\ibdata1 size to 209715200 InnoDB: Database physically writes the file full: wait... InnoDB: Log file c:\iblogs\ib_logfile0 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile0 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile1 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile1 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile2 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile2 size to 31457280 InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: creating foreign key constraint system tables InnoDB: foreign key constraint system tables created 011024 10:58:25 InnoDB: Started
Lorsque le serveur finit sa séquence de démarrage, vous devriez voir une ligne comme celle-ci, qui indique que le serveur est fonctionnel, et attend les connexions :
mysqld: ready for connections Version: '4.0.14-log' socket: '' port: 3306
Le serveur va continuer à écrire dans la console les logs. Vous pouvez ouvrir une autre console pour utiliser un client.
Si vous omettez l'option --console, le
serveur va écrire les logs dans un fichier du dossier de
données (C:\mysql\data par défaut). Le
fichier d'erreurs est celui dont l'extension est
.err.
Les comptes initiaux, qui sont dans les tables de droits de MySQL n'ont pas de mot de passe. Après le démarrage du serveur, vous devriez modifier leurs mots de passe avec les instructions de Section 2.5, « Procédure de post-installation ».
Note : Les comptes sont listés dans les tables de droits MySQL qui n'ont pas de mot de passe initialement. Après avoir démarré le serveur, il est recommandé de les modifié, comme indiqué dans la documentation Section 2.5, « Procédure de post-installation ».
Le serveur MySQL peut être lancé manuellement depuis la ligne de commande. Ceci est valable pour toutes les versions de Windows.
Pour lancer le serveur mysqld depuis la ligne
de commande, vous devez ouvrir une fenêtre de console (une
``fenêtre DOS'') et entrer ces lignes :
C:\> C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld
Le chemin utilisé dans l'exemple précédent dépend de votre installation de MySQL.
Sur les versions non NT de Windows, cette commande lance mysqld en tâche de fond. C'est à dire qu'après le démarrage du serveur, vous devriez retrouver votre invite de commande. Si vous lancez le serveur de cette manière sur Windows NT, 2000, XP ou 2003, le serveur va fonctionner en tâche principale jusqu'à ce que le serveur se termine. A cause de cela, il faudra ouvrir une autre console pour exécuter le client.
Vous pouvez arrêter le serveur MySQL en exécutant cette commande :
C:\> C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqladmin -u root shutdown
Cela appelle l'utilitaire MySQL mysqladmin
qui se connecte au serveur et lui indique de s'arrêter.
L'utilitaire se connecte en tant que root
MySQL, qui est le compte d'administration par défaut dans le
système de droits MySQL. Notez que les utilisateurs MySQL sont
totalement indépendants des utilisateurs Windows.
Si mysqld ne se lance pas, vérifiez le log
d'erreur pour fois si le serveur y a inscrit un message pour
indiquer la nature du problème. Le fichier d'erreur est rangé
dans le dossier C:\mysql\data. C'est le
fichier qui porte le suffixe .err. Vous
pouvez aussi essayer de lancer le serveur avec la commande
mysqld --console; dans ce cas, vous pourrez
lire la totalité des informations d'erreur directement à
l'écran.
La dernière option est de lancer mysqld avec
l'option --standalone --debug. Dans ce cas,
mysqld écrit un fichier de log dans le
fichier C:\mysqld.trace qui contiendra la
raison qui fait que mysqld ne se lance pas.
See Section D.1.2, « Créer un fichier de tra¸age ».
Utilisez mysqld --verbose --help pour
afficher toutes les options que mysqld
comprend (Avant MySQL 4.1, omettez l'option
--verbose.)
Dans la famille NT (Windows NT, 2000 ou XP), la méthode
recommandée pour faire fonctionner MySQL est de l'installer
comme service Windows. Windows lance et arrête le serveur
MySQL lorsque le système d'exploitation se lance ou
s'arrête. Un serveur installé comme un service peut aussi
être contrôlé en ligne de commande, avec la commande
NET, ou avec l'utilitaire graphique
Services.
L'utilitaire Services (le gestionnaire
Windows Service Control Manager) est
disponible dans le panneau d'administration Windows (sous la
section Utilitaires d'administration sous
Windows 2000). Il est conseillé de fermer l'utilitaire
Services lorsque vous faites une
installation ou une suppression à partir de la ligne de
commande : cela évite certaines erreurs étranges.
Pour faire fonctionner MySQL avec TCP/IP sous Windows NT 4, vous devez installer le service pack 3 ou plus récent.
Avant d'installer MySQL comme service Windows, vous devez commencer par arrêter le serveur en marche, avec cette commande :
C:\> C:\mysql\bin\mysqladmin -u root shutdown
Elle appelle l'utilitaire MySQL mysqladmin,
qui se connecte au serveur et l'arrête. La commande se
connecte en tant que root, qui est le
compte d'administration par défaut. Notez que les
utilisateurs du système de droits MySQL sont totalement
indépendant de ceux de Windows.
Ensuite, installez le serveur comme un service :
C:\> mysqld --install
Si vous avez des problèmes d'installation de
mysqld en tant que service en utilisant
simplement le nom du serveur, essayez d'utiliser le chemin
complet :
C:\> C:\mysql\bin\mysqld --install
Depuis MySQL 4.0.2, vous pouvez spécifier un nom de service
personnalisé avec l'option --install. Depuis
MySQL 4.0.3, vous pouvez spécifier en plus l'option
--defaults-file après le nom du service,
pour indiquer où le serveur doit lire les options au
démarrage. Les règles qui détermine le nom du service et le
fichier d'options à utiliser sont les suivantes :
Si vous ne spécifiez pas de nom de service, le serveur
utilise le nom de service par défaut de MySQL et le
serveur lit les options du groupe
[mysqld] dans le fichier d'options
standard.
Si vous spécifiez un nom de service après l'option
--install, le serveur va ignorer le
groupe d'options [mysqld] et lire les
options dans le groupe du même nom que le nom du service.
Le serveur lit ces options dans le fichier d'options
standard.
Si vous spécifiez une option
--defaults-file après le nom du service,
le serveur va ignorer les fichiers d'options standard et
ne lire les options que dans le groupe
[mysqld].
Note : avant MySQL 4.0.17,
un serveur installé comme service Windows avait des
problèmes à se lancer si le chemin ou le nom du service
contenait des espaces. Pour cette raison, évitez d'installer
MySQL dans un dossier tel que C:\Program
Files ou avec un nom qui contient des espaces.
Dans le cas général où vous installez le serveur avec
l'option --install mais sans nom de service,
le serveur est installé sous le nom de MySQL.
Un exemple plus complexe : voyez la commande suivante, qui peut être saisie sur une seule ligne :
C:\> C:\mysql\bin\mysqld --install mysql
--defaults-file=C:\my-opts.cnf
Ici, le nom du service est donné après l'option
--install. Si aucune option
--defaults-file n'est donnée, cette commande
aurait pour effet de faire lire au serveur le groupe
[mysql] dans les fichiers d'options
standard. Cela est une mauvaise idée, car ce groupe d'options
est aussi celui du client mysql. Cependant,
comme l'option --defaults-file est présente,
le serveur lit les options uniquement dans le fichier
indiqué, et uniquement dans le groupe d'options
[mysqld].
Vous pouvez aussi spécifier les options comme
``Start parameters'' dans l'utilitaire
Windows Services avant de lancer le
service.
Une fois que le serveur MySQL est installé, Windows va lancer
automatiquement le service lorsque Windows se lance. Le
service peut aussi être lancé immédiatement depuis
l'utilitaire Services, ou avec la commande
en ligne NET START MySQL. La commande
NET n'est pas sensible à la casse.
Lorsqu'il fonctionne comme un service,
mysqld n'a pas accès à la console
Windows, et aucune message n'apparaîtra la. Si
mysqld ne démarre pas, vérifiez dans le
fichier d'erreurs si le serveur a inscrit des messages qui
indiquent la cause du problème. Le fichier d'erreurs est
situé dans le dossier C:\mysql\data. Il
porte le suffixe .err.
Lorsque mysqld fonctionne comme un service,
il peut être stoppé par l'utilitaire
Services, la commande NET STOP
MySQL, ou la commande mysqladmin
shutdown. Si le service fonctionne lors de
l'extinction de Windows, ce dernier va stopper automatiquement
le serveur.
Depuis MySQL 3.23.44, vous avez le choix d'installer le
serveur comme un service Manuel, si vous ne
voulez pas que le serveur soit lancé automatiquement au
lancement du serveur Windows. Pour cela, utilisez l'option
--install-manual plutôt que
--install :
C:\> C:\mysql\bin\mysqld --install-manual
Pour supprimer un serveur qui a été installé comme service,
commencez par l'arrêter s'il fonctionnait. Puis, utilisez
l'option --remove pour le supprimer :
C:\> C:\mysql\bin\mysqld --remove
Pour les versions MySQL antérieure à la 3.23.49, un
problème avec l'arrêt automatique réside dans le fait que
Windows n'attend que quelques secondes avant l'extinction
complète, et tue les processus si cette limite est
dépassée. C'est la cause de problème potentiels (par
exemple, le moteur InnoDB devra faire une
restauration de base au prochain redémarrage). Depuis MySQL
3.23.49, Windows attend suffisamment longtemps pour que le
serveur s'arrête. Si vous remarquez que ce n'est pas
suffisant pour votre installation, il est plus prudent de ne
pas faire tourner MySQL comme un service. Au lieu de cela,
lancez-le en ligne de commande, et stoppez-le avec
mysqladmin shutdown.
L'augmentation du délai d'attente de Windows fonctionne avec
Windows 2000 et XP. Elle ne fonctionne pas pour Windows NT,
où Windows attend 20s l'extinction d'un service. Vous pouvez
augmenter cette valeur par défaut en ouvrant la base de
registres :
\winnt\system32\regedt32.exe, et en
éditant la valeur de
WaitToKillServiceTimeout à
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control.
Spécifiez une nouvelle valeur plus grande, exprimée en
millisecondes. Par exemple, la valeur de 120000 indique à
Windows NT d'attendre 2 minutes (120 secondes).
Si vous ne voulez pas lancer mysqld comme
un service, vous pouvez le lancer en ligne de commande, comme
vous le faites sur les versions qui ne sont pas Windows NT.
Pour des instructions, voyez
Section 2.2.9, « Démarrer MySQL depuis la ligne de commande Windows ».
Voyez Section 2.2.10.1, « Résolution de problèmes d'installation de MySQL sous Windows » si vous rencontrez des difficultés durant l'installation.
Vous pouvez tester le bon fonctionnement du serveur MySQL en exécutant une des commandes suivantes :
C:\>C:\mysql\bin\mysqlshowC:\>C:\mysql\bin\mysqlshow -u root mysqlC:\>C:\mysql\bin\mysqladmin version status procC:\>C:\mysql\bin\mysql test
Si mysqld est lent à répondre sur les
connexions TCP/IP depuis les clients sur Windows 9x/Me, c'est
qu'il y a vraisemblablement un problème sur vos DNS. Dans ce
cas, lancez mysqld avec l'option
--skip-name-resolve et utilisez uniquement le
serveur localhost et les IP au format
numérique dans la colonne Host des tables de
droits de MySQL.
Vous pouvez forcer un client MySQL à utiliser les connexions de
pipes nommés à la place de TCP/IP en spécifiant l'option
--pipe ou en spécifiant un point
. comme nom d'hôte. Utilisez l'option
--socket pour spécifier le nom du pipe. Depuis
MySQL 4.1, vous pouvez utiliser l'option
--protocol=PIPE.
Il y a deux version des utilitaires de ligne de commande MySQL sous Windows :
| Binary | Description |
| mysql | Compilé nativement sur Windows, avec des capacités limitées d'édition de texte. |
| mysqlc | Compilé avec le compilateur Cygnus GNU et les bibliothèques
associées, qui offre les fonctionnalités d'édition de
readline. mysqlc a
été originellement prévu pour être le principal
outil avec Windows 9x/Me. Il ne supporte pas le nouveau
protocole d'identification de MySQL 4.1, et il n'est pas
supporté à partir de MySQL 4.1. Depuis MySQL 4.1.8, il
n'est plus inclus dans les distributions Windows de
MySQL. |
Pour utiliser mysqlc, vous devez avoir une
copie de la bibliothèque cygwinb19.dll
installée là où mysqlc peut la trouver. Si
votre distribution ne dispose pas de
cygwinb19.dll dans le dossier
bin sous le dossier racine de MySQL,
recherchez-la dans le dossier lib et copiez
la dans le dossier système de Windows
(\Windows\system ou équivalent).
Lorsque vous installez et lancez MySQL pour la première fois, vous pouvez rencontrer des erreurs qui empêchent MySQL de démarrer. Le but de cette section est de vous aider à comprendre et corriger ces erreurs.
Votre première ressource lorsque vous rencontrez un problème
est le log d'erreurs. Le serveur MySQL utilise un log d'erreur
pour enregistrer les informations pertinentes relevant d'une
erreur. Le log d'erreur est situé dans le dossier de
données, spécifié dans votre fichier de configuration
my.ini. Le dossier de données par
défaut est C:\mysql\data. See
Section 5.9.1, « Le log d'erreurs ».
L'autre source d'information sur les erreurs possibles est la console, qui affiche les messages que MySQL envoie. Utilisez la commande NET START mysql depuis la ligne de commande après avoir installé mysqld comme service, pour voir apparaître les messages d'erreur du lancement de MySQL comme service. See Section 2.2.9.1, « Lancer MySQL comme un service Windows ».
Ci-dessous, vous trouverez les exemples des messages d'erreurs les plus courants lors du premier lancement du serveur MySQL :
System error 1067 has occurred. Fatal error: Can't open privilege tables: Table 'mysql.host' doesn't exist
Ce message survient lorsque le serveur ne peut pas trouver la
table de droits mysql ou d'autres fichiers
critiques. Cette erreur survient lorsque la base de mysql ou
le dossier de données est installé dans un autre dossier que
le dossier par défaut : C:\mysql et
C:\mysql\data, respectivement.
Si vous avez installé MySQL dans un autre dossier que
C:\mysql, vous devez vous assurer que le
serveur MySQL le sait grâce à son fichier de configuration,
my.ini. Le fichier
my.ini a besoin d'être situé dans le
dossier Windows, typiquement C:\WinNT ou
C:\WINDOWS. Vous pouvez déterminer sa
localisation exacte à partir de la valeur de la variable
d'environnement WINDIR, grâce à la
commande suivante :
C:\> echo %WINDIR%
Un fichier d'option peut être créé et modifié avec
n'importe quel editeur de texte, tel que
Notepad. Par exemple, si MySQL est
installé dans le dossier E:\mysql et que
les données sont situées dans
D:\MySQLdata, vous pouvez créer un
fichier d'options avec une section [mysqld]
pour spécifier la valeur du dossier de données et ses
paramètres :
[mysqld] # set basedir to your installation path basedir=E:/mysql # set datadir to the location of your data directory datadir=D:/MySQLdata
Notez que les noms de chemins Windows sont spécifiés en utilisant des slashes, plutôt que des anti-slash. Si vous utilisez des anti-slash, vous devez les doubler :
[mysqld] # set basedir to your installation path basedir=C:\\Program Files\\mysql # set datadir to the location of your data directory datadir=D:\\MySQLdata
Lors de la mise à jour de MySQL sous Windows, suivez ces instructions :
Téléchargez la dernière version de MySQL pour Windows.
Cherchez un horaire dans la journée où l'utilisation du serveur est faible, et où une interruption de service est acceptable.
Prévenez les utilisateurs que vous allez interrompre le serveur.
Stoppez le serveur MySQL (par exemple, avec la commande
NET STOP MySQL ou avec l'utilitaire de
Services si vous utilisez MySQL sous
forme de service, ou encore avec mysqladmin
shutdown).
Quittez le programme WinMySQLAdmin, s'il
fonctionnait.
Exécutez les scripts d'installation de la distribution Windows, en cliquant sur le bouton "Install" dans WinZip et en suivant les instructions d'installation.
Note importante : Les premières versions des distributions Windows de MySQL 4.1 n contenaient pas de programme d'installation. Voyez "Windows binary installation" pour les instructions d'installation d'une telle distribution.
Vous pouvez écraser votre précédente installation
(généralement installée dans
C:\mysql), ou l'installer dans un
nouveau dossier, comme C:\mysql4.
Supprimer l'ancienne version est recommandée.
Relancez le serveur (par exemple, avec NET START
MySQL si vous utilisez MySQL comme un service, ou
directement avec la commande mysqld).
Mettez à jour les tables de droits. La procédure est décrite dans la section Section 2.6.7, « Mise à jour des tables de droits ».
Situations possibles :
A system error has occurred. System error 1067 has occurred. The process terminated unexpectedly.
Cette erreur signifie que votre fichier d'options, qui est par
défaut C:\my.cnf, contient une option qui
n'est pas reconnue par MySQL. Vous pouvez vérifier que c'est le
cas en renommant le fichier my.cnf en
my_cnf.old, pour éviter que le serveur
l'utilise. S'il démarre correctement, il vous faut alors
identifier la partie du fichier d'options cause le problème.
Créez un nouveau fichier my.cnf, puis
déplacez progressivement toutes les parties de l'ancien fichier
d'options, en redémarrant le serveur entre deux copies : vous
allez identifier à coup sur le problème.
MySQL pour Windows a prouvé qu'il était très stable. Cette version de MySQL a les mêmes fonctionnalités que la version Unix, a quelques exceptions :
Windows 95 et les threads
Windows 95 perd environs 200 octets de mémoire central
lors de la création de chaque thread. Chaque connexion
MySQL crée un nouveau thread, ce qui fait qu'il n'est pas
recommandé d'exécuter mysqld pour des
durées longues sur Windows 95 si votre serveur gère de
nombreuses connexions. Les autres versions de Windows ne
souffrent pas du même problème.
Nombre limités de ports de connexions
Les systèmes Windows disposent d'environs 4,000 pour les connexions clientes, et après connexion, cela prend de 2 à 4 minutes avant qu'un port soit de nouveau utilisable. Dans des situations où les clients se connectent et se déconnectent à haute vitesse, il est possible que tous les ports soient utilisés, avant que les anciens ports ne redeviennent utilisables. Lorsque cela arrive, le serveur semblera inaccessible, même s'il fonctionne bien. Notez que des ports peuvent aussi être utilisées par d'autres applications, ce qui réduit encore le nombre de ports disponibles pour MySQL.
Lectures concurrentes
MySQL dépends des fonctions pread() et
pwrite() pour être capable de mêler
des INSERT et des
SELECT. Actuellement, nous utilisons
les mutexes pour émuler les fonctions
pread()/pwrite().
Nous allons, à long terme, remplacer ce niveau
d'interface par une interface virtuelle de fa¸on à ce
que nous puissions utiliser l'interface
readfile()/writefile()
de Windows NT/2000/XP pour gagner de la
vitesse. L'implémentation courante limite le nombre de
fichiers ouverts par MySQL à 1024, ce qui signifie que
vous ne pouvez pas utiliser d'aussi nombreux threads
concurrents sur Windows NT/2000/XP que
sur Unix.
Blocking
read
MySQL utilise une lecture bloquée pour chaque connexion. Cela signifie que :
Une connexion ne sera pas déconnectée automatiquement après 8 heures d'inactivité, comme c'est le cas sous Unix.
Si une connexion se bloque, il est impossible de la détruire sans tuer MySQL.
mysqladmin kill ne fonctionne pas
sur une connexion endormie.
mysqladmin shutdown ne peut pas
s'exécuter tant qu'il y a des connexions qui
dorment.
Nous envisageons de corriger ce problème, lorsque les développeurs Windows auront fourni un palliatif.
DROP
DATABASE
Vous ne pouvez pas détruire une base qui est utilisée par un autre thread.
Interrompre MySQL depuis le gestionnaire de tâches
Vous ne pouvez pas tuer MySQL depuis le gestionnaire de
tâche ou avec un utilitaire d'extinction de Windows 95.
Vous devez l'éteindre avec mysqladmin
shutdown.
Noms sensibles à la casse
Les noms de fichiers sont insensibles à la casse sous Windows, ce qui fait que les noms de tables et de bases ne sont pas sensibles à la casse pour MySQL sur Windows. La seule restriction est que les noms de tables et de bases doivent être donnés avec même casse dans le nom (tout en majuscules, ou en minuscules). See Section 9.2.2, « Sensibilité à la casse pour les noms ».
Le caractère
‘\’
Les composants d'un chemin sont séparés par le
caractère ‘\’ sous
Windows, qui est aussi le caractère de protection de
MySQL. Si vous utilisez la commande LOAD DATA
INFILE ou SELECT ... INTO
OUTFILE, vous devez doubler le caractère
‘\’ :
mysql>LOAD DATA INFILE "C:\\tmp\\skr.txt" INTO TABLE skr;mysql>SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;
Alternativement, vous pouvez utiliser les noms de fichiers
au format Unix, avec le caractère
‘/’ :
mysql>LOAD DATA INFILE "C:/tmp/skr.txt" INTO TABLE skr;mysql>SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
Problèmes avec les pipes
Les pipes ne fonctionnent pas de manière fiables depuis
la ligne de commande Windows. Si le pipe re¸oit un
caractère ^Z /
CHAR(24), Windows va croire qu'il
atteint la fin du fichier et arrête le programme.
C'est un problème, notamment lorsque vous essayez d'utiliser le log binaire de cette manière :
mysqlbinlog binary-log-name | mysql --user=root
Si vous rencontrez un problème lors de l'utilisation du
log, et que vous pensez que c'est à cause du caractère
^Z / CHAR(24), vous
pouvez utiliser le palliatif suivant :
mysqlbinlog binary-log-file --result-file=/tmp/bin.sql mysql --user=root --execute "source /tmp/bin.sql"
Cette dernière commande peut aussi être utilisée pour lire fiablement tout fichier SQL qui contient des données binaires.
L'erreur Can't open named
pipe
Si vous utilisez MySQL 3.22 sous NT
avec les derniers clients mysql, vous allez obtenir cette
erreur :
error 2017: can't open named pipe to host: . pipe...
Ceci est dû au fait que les versions modernes de MySQL
utilisent des pipes nommés sous NT,
par défaut. Pour éviter cette erreur, vous devez
utiliser l'option --host=localhost sur
les nouveaux clients, ou bien créer le fichier d'options
C:\my.cnf, qui contiendra les
informations suivantes :
[client] host = localhost
Depuis la version 3.23.50, les pipes nommés sont les
seuls activés si mysqld est démarré
avec --enable-named-pipe.
Erreur Access denied for
user
Si vous rencontrez l'erreur Access denied for
user: 'utilisateur@unknown' to database 'mysql'
lors de l'accès au serveur MySQL sur la même machine,
cela signifie que MySQL ne peut résoudre proprement votre
nom d'hôte.
Pour corriger cela, vous devriez créer un fichier
\windows\hosts dans l'information
suivante :
127.0.0.1 localhost
ALTER
TABLE
Lorsque vous exécutez la commande ALTER
TABLE, la table est verrouillé, empêchant les
autres threads d'y accéder. Cela est lié au fait que
sous Windows, vous ne pouvez pas effacer un fichier qui
est en cours d'utilisation par d'autres threads : à
l'avenir, vous pourrions trouver un moyen de contourner ce
problème.
DROP
TABLE
La commande DROP TABLE sur une table
qui est utilisée dans le cadre d'un
MERGE ne fonctionne pas sous Windows,
car le gestionnaire de MERGE garde la
carte des tables cachée de la couche supérieure de
MySQL. Comme Windows ne vous autorise pas à effacer des
fichiers qui sont ouverts, vous devez d'abord vider de la
mémoire toutes les tables du MERGE
(avec la commande FLUSH TABLES) puis
effacer la table MERGEavant d'effacer
les tables. Nous allons corriger cela lorsque nous
introduirons la notion de VIEWs.
DATA DIRECTORY et
INDEX DIRECTORY
Les directives DATA DIRECTORY et
INDEX DIRECTORY de CREATE
TABLE sont ignorées sous Windows, car Windows
ne supporte pas les liens symboliques.
Voici quelques problèmes connus et pas encore corrigés, si jamais quelqu'un souhaite nous aider sur la version Windows :
Ajouter des icônes pour le démarrage et l'arrêt de MySQL, dans l'installateur.
Il serait vraiment pratique de pouvoir arrêter le
processus mysqld depuis le gestionnaire
de tâches. Pour le moment, il faut passer par
mysqladmin shutdown.
Le port de readline sur Windows pour
pouvoir l'utiliser avec l'outil de ligne de commande
mysql.
Des versions graphiques des clients standards MySQL
(mysql, mysqlshow,
mysqladmin et
mysqldump) seraient bien.
Il serait bien si les fonctions de lecture et d'écriture
sur les sockets de net.c pouvaient
être interrompues. Cela rendrait possible l'arrêt des
threads en court avec mysqladmin kill
sous Windows.
Ajouter des macros pour utiliser les méthodes rapides d'incrément/décrément compatibles avec les threads, fourni par Windows.
Il est recommandé d'installer MySQL sous Linux en utilisant un
fichier RPM. Les RPM de
MySQL sont actuellement compilé sur une Red Hat en version 6.2,
mais devraient fonctionner sur toute autre version de Linux qui
supporte rpm et utilise
glibc. Pour obtenir les paquets
RPM, voyez la section
Section 2.1.3, « Comment obtenir MySQL ? ».
Note : les distributions
RPM de MySQL sont souvent fournies par
d'autres éditeurs. Soyez prévenus qu'elles peuvent contenir
des fonctionnalités différents de celles proposées par
MySQL AB, et les instructions de ce manuel ne
s'appliquent pas forcément. Les instructions de l'éditeur
doivent alors être utilisées.
Si vous avez des problèmes avec un fichier
RPM, si vous obtenez par exemple l'erreur
``Sorry, the host 'xxxx' could not be looked
up'', référez vous à
Section 2.8.1.2, « Notes relatives à Linux pour les distributions binaires ».
Dans la plupart des cas, vous n'aurez besoin que d'installer les
paquets du serveur MySQL et du
client MySQL pour obtenir une installation
MySQL fonctionnelle. Les autres paquets ne sont pas nécessaires
pour une installation standard. Si vous voulez utiliser la
version MySQL Max qui a des fonctionnalités
supplémentaires, vous devez installer le RPM
MySQL-Max. Cependant, il est recommandé de
ne faire cela qu'après avoir installé le
RPM MySQL-server. See
Section 5.1.2, « mysqld-max, la version étendue du serveur
mysqld ».
Si vous obtenez une message d'erreur de dépendance lors de
l'installation des paquets MySQL 4.0 (par exemple,
``error: removing these paquets would break
dependencies: libmysqlclient.so.10 is needed by
...''), vous devriez aussi installer le paquet
MySQL-shared-compat, qui inclut les
bibliothèques partagées pour compatibilité ascendante
(libmysqlclient.so.12 pour MySQL 4.0 et
libmysqlclient.so.10 pour MySQL 3.23).
De nombreuses distributions Linux sont livrés avec MySQL 3.23,
et elle sont dynamiquement liées à d'autres applications pour
économiser de l'espace. Si ces bibliothèques partagées sont
dans un paquet séparé (par exemple,
MySQL-shared), il suffit de laisser le paquet
installé, puis de mettre à jour le serveur et les clients qui
sont statiquement liés à la bibliothèque, et ne dépendent
pas des bibliothèques partagées. Pour les distributions qui
incluent les bibliothèques partagées dans le même paquet que
le serveur MySQL, (par exemple, Red Hat Linux), vous pouvez soit
installer notre RPM
MySQL-shared 3.23, soit utiliser le paquet
MySQL-shared-compat.
Les fichiers RPM dont vous pourriez avoir
besoin sont :
MySQL-server-VERSION.i386.rpm
Le serveur MySQL. Vous en aurez besoin à moins que vous ne
vouliez que vous connectez à un serveur MySQL tournant sur
une autre machine. Notez bien : les fichiers du
RPM de serveur étaient appelés
MySQL-VERSION.i386.rpm avant MySQL
4.0.10. C'est à dire qu'ils n'avaient pas le mot
-server dans leur nom.
MySQL-Max-VERSION.i386.rpm
Le serveur MySQL Max. Ce serveur a des capacités
supplémentaires par rapport au serveur
MySQL-server. Vous devez installer le
RPM MySQL-server
d'abord, parce que le RPM
MySQL-Max dépend de lui.
MySQL-client-VERSION.i386.rpm
Les programmes clients MySQL standards. Vous avez certainement besoin d'installer ce paquet.
MySQL-bench-VERSION.i386.rpm
Tests et bancs d'essai. Nécessite Perl et les modules
RPM msql et mysql.
MySQL-devel-VERSION.i386.rpm
Bibliothèques et fichiers d'inclusions dont vous aurez besoin pour compiler d'autres clients MySQL, tels que les modules Perl.
MySQL-shared-VERSION.i386.rpm
Ce paquet contient les bibliothèques partagées
(libmysqlclient.so*) que certains
langages et applications recherchent pour les charger
dynamiquement, afin d'utiliser MySQL.
MySQL-shared-compat-VERSION.i386.rpm
Ce paquet inclut la bibliothèque partagée pour MySQL 3.23
et MySQL 4.0. Installez ce paquet au lieu de
MySQL-shared, si vous avec des
applications installée qui utilisent dynamiquement MySQL
3.23 mais que vous voulez passez à MySQL 4.0 sans briser
les dépendances. Ce paquet est disponible depuis MySQL
4.0.13.
MySQL-embedded-VERSION.i386.rpm
La bibliothèque intégrée MySQL (depuis MySQL 4.0).
MySQL-VERSION.src.rpm
Celui-ci contient le code source de tous les paquets
précédents. Il peut donc être utilisé pour construire
des fichiers RPM pour d'autres
architectures (par exemple, l'Alpha ou le SPARC).
Pour voir tous les fichiers présents dans un paquet
RPM, lancez :
shell> rpm -qpl MySQL-VERSION.i386.rpm
Pour effectuer une installation standard minimale, lancez :
shell> rpm -i MySQL-VERSION.i386.rpm MySQL-client-VERSION.i386.rpm
Pour installer uniquement le paquet du client MySQL, lancez :
shell> rpm -i MySQL-client-VERSION.i386.rpm
Les RPM fournissent une fonctionnalité qui
permet de vérifier l'authenticité du paquet avant de
l'installer. Si vous voulez en savoir plus sur cette
fonctionnalité, voyez
Section 2.1.4, « Vérifier l'intégrité des paquets avec MD5 ou
GnuPG ».
Le fichier RPM place les données dans
/var/lib/mysql. Le RPM
crée aussi les entrées appropriées dans
/etc/rc.d/ pour lancer le serveur
automatiquement au démarrage. (Cela signifie que, si vous avez
déjà effectué une installation auparavant, vous pouvez avoir
besoin de faire une sauvegarde de vos fichiers de démarrage
précédents si vous les changez, de fa¸on à ne pas les
perdre.) Voyez Section 2.5.2.2, « Lancer et arrêter MySQL automatiquement » pour plus
d'informations sur comment démarrer automatiquement MySQL au
lancement du serveur.
Si vous voulez installer le RPM MySQL sur une
ancienne distribution MySQL, qui ne supporte pas les scripts
d'initialisation de /etc/init.d
(directement ou via un lien symbolique), vous devez créer un
lien symbolique qui pointe sur le dossier où les scripts
d'initialisation sont installés. Par exemple, si ce dossier est
/etc/rc.d/init.d, utilisez une de ces
commandes avant d'installer le RPM, pour
créer /etc/init.d sous forme de lien
symbolique, qui pointe ici :
shell> cd /etc; ln -s rc.d/init.d .
Cependant, toutes les distributions Linux courantes doivent
supporter le nouveau dossier /etc/init.d,
car c'est imposé par la compatibilité LSB (Linux
Standard Base).
Si les fichiers RPM que vous installez
incluent MySQL-server, le démon
mysqld devrait fonctionner après
l'installation. Vous devriez être capable d'utiliser MySQL
immédiatement.
Si quelque chose cloche, vous pouvez trouver plus d'information dans le chapitre d'installation binaire. See Section 2.3, « Installer MySQL sur d'autres systèmes type Linux ».
Note : Les comptes qui sont listés dans les tables de droits MySQL initiales n'ont pas de mot de passe. Après démarrage du serveur, il est recommandé de configurer ces mots de passe, en suivant les instructions de la section Section 2.5, « Procédure de post-installation ».
Depuis MySQL 4.0.11, vous pouvez installer MySQL sur Mac OS X
10.2 ("Jaguar") avec le paquet binaire Mac OS X
PKG au lieu d'utiliser la distribution
binaire compressée. Notez que les anciennes versions de Mac OS
X (i.e. 10.1.x) ne sont pas supportées par ce paquet.
Le paquet est situé dans une image disque
(.dmg), que vous devez monter en
double-cliquant son icône sur le Finder. Le
disque devrait alors se monter, et afficher son contenu.
Pour télécharger MySQL, voyez Section 2.1.3, « Comment obtenir MySQL ? ».
Note : avant de lancer
l'installation, assurez vous qu'il n'y a pas de serveur MySQL en
fonctionnement! Arrêtez tous les serveurs MySQL avant de
continuer, soit en utilisant l'application manager (pour les
serveurs Mac OS X) ou via mysqladmin shutdown
en ligne de commande.
Pour installer le paquet MySQL, double-cliquez sur l'icône. Cela va lancer l'installeur de paquet MacOSX, qui vous guidera durant l'installation.
A cause d'un bug dans l'installeur de paquets MySQL, vous pourriez rencontrer le message d'erreur
You cannot install this software on this disk. (null)
dans le dialogue de sélection du disque de destination. Si
cette erreur survient, cliquez sur le bouton de retour
(Go Back) pour retourner à l'écran
précédent. Puis, cliquez sur le bouton d'avance
(Continue) pour passer à nouveau à la page
de sélection des disques. Nous avons indiqué ce bug à Apple,
qui travaille sur le sujet.
Le paquet Mac OS X de MySQL va s'installer lui-même dans le
dossier /usr/local/mysql-VERSION et va
aussi ajouter un lien symbolique
/usr/local/mysql, qui pointe sur le nouveau
dossier. Si un dossier appelé
/usr/local/mysql existe déjà, il sera
renommé en /usr/local/mysql.bak. De plus,
il va installer les tables de droits MySQL en exécutant le
script mysql_install_db après
l'installation.
Le schéma d'installation est semblable à celui de la
distribution binaire, tous les programmes MySQL sont situés
dans le dossier /usr/local/mysql/bin. Les
sockets MySQL sont installées dans le fichier
/etc/mysql.sock par défaut. See
Section 2.1.5, « Dispositions d'installation ».
L'installation requiert un compte nommé
mysql (qui existe par défaut en Mac OS X
10.2 et plus récent).
Si vous utilisez Mac OS X Server, vous devez avoir déjà une version de MySQL installée :
| Version Mac OS X Server | Version MySQL |
| 10.2-10.2.2 | 3.23.51 |
| 10.2.3-10.2.6 | 3.23.53 |
| 10.3 | 4.0.14 |
| 10.3.2 | 4.0.16 |
Cette section du manuel couvre l'installation du paquet binaire
MySQL pour Mac OS X uniquement. Assurez vous de bien lire l'aide
d'Apple concernant l'installation de MySQL (Lancer le
visualiseur d'aide, sélectionnez la rubrique "Serveur
Mac OS X", et faites une recherche sur "MySQL", puis
lisez l'entrée appelée "Installing MySQL").
Notez bien que la version pre-installée de MySQL sur Mac OS X
Server peut être lancée avec la commande
safe_mysqld au lieu de
mysqld_safe!
Si vous avez utilisé auparavant les paquets MySQL de Marc Liyanage pour Mac OS X, depuis le site de http://www.entropy.ch, vous pouvez simplement suivre le processus de mise à jour, en utilisant les conseils de ses pages.
Si vous faites une mise à jour depuis les versions de Marc, ou depuis une ancienne version de MySQL pour Mac OS X Server, avec le nouveau paquet officiel, vous devrez convertir les tables de droits. See Section 2.6.3, « Passer de la version 3.23 à la version 4.0 ».
Si vous voulez lancer automatiquement MySQL au démarrage du
système, vous devez aussi installer le MySQL Startup
Item. Depuis MySQL 4.0.15, il fait partie du disque
d'installation MySQL pour Mac OS X dans un paquet séparé. Il
suffit de double-cliquer sur l'icône
MySQLStartupItem.pkg et de suivre les
instructions pour l'installer.
Notez que le MySQL Startup Item ne doit être
installé qu'une seule fois. Il n'y a pas besoin de me mettre à
jour avec les versions de MySQL.
Le MySQL Startup Item est installé dans le
dossier /Library/StartupItems/MySQLCOM.
(Avant MySQL 4.1.2, le dossier était
/Library/StartupItems/MySQL, mais cela
créait un conflit avec le MySQL Startup Item
du serveur Mac OS X Server.) Il ajoute la
variable MYSQLCOM=-YES- au fichier de
configuration /etc/hostconfig. Si vous
voulez désactiver le démarrage automatique de MySQL, modifiez
simplement la variable avec MYSQLCOM=-NO-.
Sur Mac OS X Server, l'installation par défaut de MySQL utilise
la variable MYSQL dans
/etc/hostconfig. Le MySQL Startup
Item désactive cette variable en lui donnant la
valeur de MYSQL=-NO-. Cela évite que des
conflit de démarrage surviennent, si la variable
MYSQLCOM est utilisée par MySQL
Startup Item. Cependant, cela n'éteint pas un serveur
MySQL en fonctionnement.
Après cette installation, vous pouvez lancer le serveur MySQL avec ces commandes, exécutées dans terminal. Notez bien que vous devez avoir des droits d'administrateur pour cela!
Si vous avez installé le MySQL Startup
Item :
shell> sudo /Library/StartupItems/MySQL/MySQL start
(Enter your password, if necessary)
(Press Control-D or enter "exit" to exit the shell)
Si vous n'avez pas installé le MySQL Startup
Item :
shell>cd /usr/local/mysqlshell>sudo ./bin/mysqld_safe(Enter your password) (Press CTRL+Z) shell>bg(Press CTRL+D to exit the shell)
Vous devez alors être capable de vous connecter au serveur
MySQL, notamment en exécutant la commande
/usr/local/mysql/bin/mysql.
Note : cette procédure ne configure aucun mot de passe pour les comptes MySQL. Après avoir suivi cette procédure, lisez la section Section 2.5, « Procédure de post-installation », pour les instructions de post-installation et les tests.
Vous pouvez faire cela avec les commandes suivantes :
/usr/local/mysql/bin/mysqladmin -u root password <password> /usr/local/mysql/bin/mysqladmin -u root -h `hostname` password <password>
Vous pouvez aussi ajouter des alias à votre fichier de
ressource Shell, pour accéder à mysql et
mysqladmin depuis la ligne de commande :
alias mysql '/usr/local/mysql/bin/mysql' alias mysqladmin '/usr/local/mysql/bin/mysqladmin'
Alternativement, vous pouvez simplement ajouter
/usr/local/mysql/bin à votre variable
d'environnement PATH, par exemple, en
ajoutant la ligne suivante dans votre fichier
$HOME/.tcshrc :
setenv PATH ${PATH}:/usr/local/mysql/bin
Si aucun fichier .tcshrc n'existe dans
votre dossier d'utilisateur, créez le avec un éditeur texte.
Notez que l'installation d'un nouveau paquet MySQL ne supprimer pas le dossier d'une vieille installation : l'installeur de Mac OS X n'offre pas encore les fonctionnalités nécessaires pour mettre à jour proprement une vieille version.
Après avoir copié les fichiers de bases depuis votre ancien
dossier vers le nouveau, et que vous avez réussi à redémarrer
MySQL avec la nouvelle version, vous devriez pensez à supprimer
les vieilles versions des fichiers, situées dans
/Library/Receipts/mysql-<version>.pkg.
Porter MySQL sur NetWare a été un effort
dirigé par Novell. Les clients Novell seront
heureux de constater que NetWare 6.5 est distribué avec les
exécutables MySQL et une licence de support commercial pour
tous les serveurs qui fonctionnent sur cette version de NetWare.
MySQL pour NetWare est compilé avec une combinaison de
Metrowerks CodeWarrior pour NetWare et de
version spéciales de compilation de GNU
autotools.
Les derniers paquets binaires pour NetWare sont disponibles sur le site http://dev.mysql.com/downloads/. See Section 2.1.3, « Comment obtenir MySQL ? ».
Pour pouvoir héberger un serveur MySQL, un serveur NetWare doit avoir les pré-requis suivants.
NetWare version 6.5, ou NetWare 6.0 avec Support Pack 3 installé (vous pouvez obtenir cela sur http://support.novell.com/filefinder/13659/index.html). Le système doit passer les pré-requis minimum de Novell pour faire tourner cette version de NetWare.
Le sytème doit satisfaire les prérequis minimum de NetWare.
Les données MySQL, ainsi que les logiciels, doivent être installés dans un volume NSS; les volumes traditionnels ne sont pas supportés.
Les fichiers binaires de NetWare sont téléchargeables sur le site http://www.mysql.com/downloads/.
Pour installer MySQL pour NetWare, utilisez la procédure suivante :
Si vous mettez à jour une ancienne installation, stoppez le serveur MySQL. Vous pouvez le faire en console, avec la commande suivante :
SERVER: mysqladmin -u root shutdown
Connectez vous sur le serveur depuis une machine cliente, avec un accès à l'endroit où vous voulez installer MySQL.
Décompressez l'archive binaire zip sur
le serveur. Assurez-vous d'autoriser les chemins utilisés
dans l'archive zip. Il est sécuritaire d'utiliser le
dossier SYS:\.
Si vous mettez à jour une ancienne installation, vous
pouvez copier le dossier de données (par exemple,
SYS:MYSQL\DATA), ainsi que
my.cnf si vous l'avez modifié. Vous
pouvez alors effacer l'ancienne copie de MySQL.
Vous pouvez renommer le dossier avec un nom plus cohérent,
et facile à utiliser. Nous recommandons d'utiliser
SYS:MYSQL; les exemples du manuel
feront références à ce dossier d'installation.
Depuis la console du serveur, ajoutez un chemin de recherche
pour le dossier contenant les NLM MySQL.
Par exemple :
SERVER: SEARCH ADD SYS:MYSQL\BIN
Installez la base de données initiale, si nécessaire, en
exécutant le script mysql_install_db
depuis la console.
Lancez le serveur MySQL en utilisant le script
mysqld_safe depuis la console.
Pour finir l'installation, vous devriez aussi installer les
commandes suivantes dans le fichier
autoexec.ncf. Par exemple, si votre
installation MySQL est dans le dossier
SYS:MYSQL et que vous voulez que MySQL
se lance automatiquement, vous pouvez ajouter ces lignes :
#Starts the MySQL 4.0.x database server SEARCH ADD SYS:MYSQL\BIN MYSQLD_SAFE
Si vous utilisez MySQL sur NetWare 6.0, nous vous
recommandons fortement d'ajouter l'option
--skip-external-locking à la ligne de
commande :
#Starts the MySQL 4.0.x database server SEARCH ADD SYS:MYSQL\BIN MYSQLD_SAFE --skip-external-locking
Il est aussi nécessaire d'utiliser CHECK
TABLE et REPAIR TABLE au lieu
de myisamchk, car
myisamchk utilise un verrouillage
externe. Le verrouillage externe est reconnu pour poser des
problèmes sur NetWare 6.0; ce problème a été supprimé
sur NetWare 6.5.
mysqld_safe sur NetWare fournit un écran
de présence. Lorsque vous déchargez (extinction) le
NLM mysqld_safe,
l'écran ne se ferme pas par défaut. Au lieu de cela, il
demande une action de l'utilisateur :
*<NLM has terminated; Press any key to close the screen>*
Si vous voulez que NetWare ferme automatiquement cet
écrant, utilisez l'option --autoclose de
mysqld_safe. Par exemple :
#Starts the MySQL 4.0.x database server SEARCH ADD SYS:MYSQL\BIN MYSQLD_SAFE --autoclose
Le comportement de mysqld_safe sur NetWare
est décrit plus en détails dans Section 5.1.3, « safe_mysqld, le script père de
mysqld ».
S'il y avait une installation MySQL sur le serveur, assurez-vous
de vérifier les commandes de démarrage de MySQL dans
autoexec.ncf, et éditez ou effacez les
autant que nécessaire.
Note : Les comptes qui sont stockés dans les tables de droits n'ont pas de mot de passe initial. Après avoir lancé le serveur, il est recommandé de leur donner des mots de passe en suivant les instructions de la section Section 2.5, « Procédure de post-installation ».
Cette section couvre l'installation des distributions binaires de
MySQL, qui sont fournies pour différentes plate-formes au format
d'archive tar (les fichiers avec l'extension
.tar.gz). Voyez
Section 2.1.2.5, « Binaires compilés par MySQL AB » pour une liste détaillée.
Pour télécharger une distribution source de MySQL, voyez Section 2.1.3, « Comment obtenir MySQL ? ».
En plus de ces paquets génériques, nous offrons aussi des compilations spécifiques pour certaines plate-formes. Voyez Section 2.2, « Installation standard rapide de MySQL » pour plus d'information sur leur installation.
Vous avez besoin des utilitaires suivants pour installer une
archive tar MySQL :
GNU gunzip pour décompresser la
distribution.
Un utilitaire tar raisonnable pour ouvrir
l'archive. GNU tar est reconnu pour cette
tâche. Certains systèmes d'exploitation disposent d'une
version pré-installée de tar qui posent
des problèmes. Par exemple, Sun tar et Mac
OS X tar ont des soucis avec les noms de
fichiers longs. Dans ce cas, installez GNU
tar. Sur Mac OS X, vous pouvez installer le
logiciel pré-installé gnutar.
Si vous rencontrez des problèmes, utilisez toujours
mysqlbug pour poser des questions
à la liste MySQL. Même si le problème n'est pas un bogue,
mysqlbug rassemble des informations sur le
système qui nous aiderons à résoudre votre problème. Si vous
n'utilisez pas mysqlbug, vous réduisez les
chances de résolution de votre problème. Vous trouverez
mysqlbug dans le dossier
bin après avoir décompressé la
distribution. See Section 1.4.1.3, « Comment rapporter un bogue ou un problème ».
Les commandes de base que vous devez exécuter pour installer MySQL à partir des sources sont :
shell>groupadd mysqlshell>useradd -g mysql mysqlshell>cd /usr/localshell>gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -shell>ln -s full-path-to-mysql-VERSION-OS mysqlshell>cd mysqlshell>scripts/mysql_install_dbshell>chown -R root .shell>chown -R mysql datashell>chgrp -R mysql .shell>bin/mysqld_safe --user=mysql &
Pour les versions de MySQL plus ancienne que la 4.0, remplacez
bin/safe_mysqld par
bin/mysqld_safe dans la commande finale.
Note : cette procédure ne configure aucun mot de passe pour les comptes MySQL. Après avoir suivi cette procédure, lisez la section Section 2.5, « Procédure de post-installation », pour les instructions de post-installation et les tests.
Plus de détails suivent.
Pour installer une distribution binaire, suivez les étapes suivantes, puis reportez vous à Section 2.5, « Procédure de post-installation », pour la configuration post-installation et les tests :
Ajoutez un utilisateur et un groupe avec les droits desquels
mysqld fonctionnera :
shell>groupadd mysqlshell>useradd -g mysql mysql
Ces commandes ajoutent le groupe mysql
group et l'utilisateur mysql. La syntaxe de
useradd et de groupadd
peut varier de fa¸on significative suivant les versions
d'Unix. Elles peuvent aussi s'appeler
adduser et addgroup.
Vous pouvez aussi souhaiter nommer le groupe et l'utilisateur
autrement que mysql.
Choisissez le dossier dans lequel vous voulez décompresser la
distribution, et placez vous-y. Dans l'exemple suivant, nous
allons décompresser la distribution dans le dossier
/usr/local. Les instructions suivantes
supposeront que vous avez les droits pour créer des dossiers
de des fichiers dans /usr/local. Si ce
dossier est protégé, vous aurez besoin des droits de
root pour faire l'installation.
shell> cd /usr/local
Téléchargez la distribution sur l'un des sites listé sur Section 2.1.3, « Comment obtenir MySQL ? ».
Les archives MySQL tar ont des noms de la
forme mysql-VERSION-OS.tar.gz, où
VERSION est le numéro de version (par
exemple, 4.0.17), et OS
indique le système d'exploitation de la distribution (par
exemple, pc-linux-gnu-i586). Pour une
version donnée, les distributions binaires pour toutes les
plate-formes sont compilées sur les mêmes sources MySQL.
Décompressez la distribution dans le répertoire courant :
shell>gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -shell>ln -s full-path-to-mysql-VERSION-OS mysql
La commande tar crée un dossier appelé
mysql-VERSION-OS. La commande
ln crée un lien symbolique dans ce
dossier. Cela vous laisse le moyen de transférer facilement
votre installation dans le dossier
/usr/local/mysql.
Avec GNU tar, il n'est pas nécessaire
d'utiliser séparéement gunzip. Vous
pouvez remplacer la première ligne par celle-ci pour
décompresser et ouvrir l'archive dans le même temps :
shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
Placez-vous dans le répertoire racine de la distribution décompressée :
shell> cd mysql
Vous trouverez plusieurs fichiers et sous dossiers dans le
dossier mysql. Le plus important pour
l'installation sont les dossiers bin et
scripts.
Ce dossier contient les programmes clients et le serveur.
Vous devez ajouter le chemin complet de ce dossier à
votre variable PATH pour que votre
shell trouve MySQL facilement. See
Annexe E, Variables d'environnement.
scripts
Ce dossier contient le script
mysql_install_db, utilisé pour
initialiser la base mysql, qui contient
les tables de droits du serveur.
Si vous n'avez jamais installé MySQL auparavant, vous devez créer les tables de droits :
shell> scripts/mysql_install_db
Notez que pour les versions de MySQL plus anciennes que la
version 3.22.10, mysql_install_db laisse le
serveur fonctionner après avoir créer les tables. Ce n'est
plus vrai : vous devez redémarrer le serveur après avoir
exécuté ce script.
Changez le propriétaire du binaire pour
root et le propriétaire des données pour
l'utilisateur qui va faire tourner mysqld.
En supposant que vous avez installé les données dans le
dossier /usr/local/mysql, la commande
est :
shell>chown -R root .shell>chown -R mysql datashell>chgrp -R mysql .
La première commande change l'attribut
owner du fichier pour
root. La seconde change l'attribut
owner du dossier de données pour
l'utilisateur mysql. La troisième change
l'attribut group pour le groupe
mysql.
Si vous voulez que MySQL démarre automatiquement après le
démarrage de votre serveur, vous pouvez copier le fichier
support-files/mysql.server là où votre
serveur recherche les scripts de démarrage. Plus
d'informations sur
support-files/mysql.server sont disponibles
dans Section 2.5.2.2, « Lancer et arrêter MySQL automatiquement ».
Vous pouvez configurer de nouveaux comptes en utilisant le
script bin/mysql_setpermission si vous
installez les modules Perl DBI et
DBD::mysql. Pour des instructions, voyez
Section 2.9, « Commentaires sur l'installation de Perl ».
Si vous voulez utiliser mysqlaccess et
avoir accès à la distribution MySQL dans un dossier
non-standard, vous devez modifier le chemin où
mysqlaccess va rechercher le client
mysql. Editez le script
bin/mysqlaccess à la ligne 18, environs.
Recherchez une ligne qui ressemble à ceci :
$MYSQL = '/usr/local/bin/mysql'; # path to mysql executable
Changez le dossier pour qu'il prenne la valeur que du chemin
où mysql est situé. Si vous le le faite
pas, vous allez recevoir une erreur Broken
pipe lorsque vous utilisez
mysqlaccess.
Après que tout ait été ouvert et installé, il faut tester votre distribution :
Lancez le serveur MySQL avec les commandes suivantes :
shell> bin/mysqld_safe --user=mysql &
Pour les versions de MySQL plus ancienne que 4.0, remplacez
bin/safe_mysqld par
bin/mysqld_safe dans la commande.
Puis, passez à Section 5.1.3, « safe_mysqld, le script père de
mysqld », et
Section 2.5, « Procédure de post-installation ».
Note : cette procédure ne configure aucun mot de passe pour les comptes MySQL. Après avoir suivi cette procédure, lisez la section Section 2.5, « Procédure de post-installation », pour les instructions de post-installation et les tests.
Avant de procéder à l'installation à partir des sources, vérifiez auparavant que notre distribution binaire pour votre plate-forme ne fonctionne pas. Nous faisons un maximum d'efforts pour nous assurer que nos binaires sont compilés avec les meilleures options possibles.
Les distributions source de MySQL sont fournies sous forme
d'archive tar, dont le nom est sous la forme
mysql-VERSION.tar.gz, où
VERSION est un nombre comme
5.0.6-beta.
Pour télécharger une distribution source de MySQL, voyez Section 2.1.3, « Comment obtenir MySQL ? ».
Vous avez besoin des outils suivants pour compiler et installer MySQL à partir des sources :
GNU gunzip pour décompresser la
distribution.
Un programme tar pour désarchiver la
distribution. GNU tar est connu pour
fonctionner. Le tar de Sun connaît
quelques problèmes.
Un compilateur C++ ANSI fonctionnel. gcc
>= 2.95.2, egcs >= 1.0.2 ou
egcs 2.91.66, SGI C++, et SunPro C++ sont
quelques-uns des compilateurs réputés pour fonctionner.
libg++ n'est pas nécessaire si vous
utilisez gcc. gcc 2.7.x
souffre d'un bogue qui l'empêche de compiler quelques
fichiers C++ correctement écrits, tels que
sql/sql_base.cc. Si vous disposez
seulement de gcc 2.7.x, vous devez mettre
à jour votre gcc afin de compiler MySQL.
gcc 2.8.1 est aussi reconnu pour rencontrer
des problèmes sur certaines plate-formes, il devrait donc
être désactivé si un autre compilateur existe pour la
plate-forme.
gcc >= 2.95.2 est recommandé pour
compiler MySQL dans ses versions 3.23.x.
Un bon programme make. GNU
make est une fois de plus recommandé et
est quelquefois requis. Si vous rencontrez des problèmes,
nous vous recommandons d'essayer GNU make
3.75 ou supérieur.
Si vous utilisez une version récente de gcc,
suffisamment récente pour reconnaître l'option
-fno-exceptions, il est très
important que vous l'utilisiez. Sinon, vous risquez de
compiler un binaire qui crashe aléatoirement. Nous recommandons
donc l'utilisation de -felide-constructors et
-fno-rtti en même temps que
-fno-exceptions. En cas de doute, faites la
chose suivante :
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions \
-fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler \
--with-mysqld-ldflags=-all-static
Sur la plupart des systèmes, il en résultera un binaire rapide et stable.
Si vous rencontrez des problèmes, utilisez toujours
mysqlbug pour poster des questions
sur les listes internes. Même si le problème n'est pas un bogue,
mysqlbug rassemble des informations sur le
système qui aidera les autres à résoudre votre problème. En
n'utilisant pas mysqlbug, vous amoindrissez vos
chances d'obtenir une solution à votre problème ! Vous
trouverez mysqlbug dans le répertoire
scripts après avoir désarchivé la
distribution. See Section 1.4.1.3, « Comment rapporter un bogue ou un problème ».
Les commandes de pages que vous devez exécuter pour installer la distribution source de MySQL sont :
shell>groupadd mysqlshell>useradd -g mysql mysqlshell>gunzip < mysql-VERSION.tar.gz | tar -xvf -shell>cd mysql-VERSIONshell>./configure --prefix=/usr/local/mysqlshell>makeshell>make installshell>cp support-files/my-medium.cnf /etc/my.cnfshell>cd /usr/local/mysqlshell>bin/mysql_install_dbshell>chown -R root .shell>chown -R mysql varshell>chgrp -R mysql .shell>bin/mysqld_safe --user=mysql &
Pour les versions de MySQL 4.0 ou plus récentes, remplacez
bin/safe_mysqld par
bin/mysqld_safe dans la commande finale.
Si vous commencez avec un paquet RPM,
commencez comme ceci :
shell> rpm --rebuild --clean MySQL-VERSION.src.rpm
Cela va compiler un paquet RPM binaire que
vous pouvez installer.
Note : cette procédure ne configure aucun mot de passe pour les comptes MySQL. Après avoir suivi la procédure, passez à la section Section 2.5, « Procédure de post-installation », pour les instructions de post-installation et de tests.
Une description plus détaillée suit.
Ajoutez un utilisateur et un groupe pour
mysqld comme ceci :
shell>groupadd mysqlshell>useradd -g mysql mysql
Ces commandes ajoute le groupe mysql et
l'utilisateur mysql. La syntaxe de
useradd et groupadd
peut différer légèrement suivant votre version d'Unix.
Elles peuvent aussi s'appeler adduser et
addgroup.
Vous pouvez donner un autre nom à l'utilisateur et au
groupe, à la place de mysql. Si vous le
faîtes, adaptez les commandes dans les prochaines
instructions.
Choisissez un dossier dans lequel vous allez décompresser les sources de MySQL. Rendez vous dans ce dossier.
Téléchargez une distribution sur un des sites listés sur Section 2.1.3, « Comment obtenir MySQL ? ».
Décompressez la distribution dans le dossier courant :
shell> gunzip < /path/to/mysql-VERSION.tar.gz | tar xvf -
Cette commande crée un dossier appelé
mysql-VERSION.
Avec GNU tar, il n'est pas besoin de
faire un appel séparé à gunzip. Vous
pouvez utilise cette commande alternative pour décompresser
et extraire la distribution :
shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
Placez vous à la racine de la distribution :
shell> cd mysql-VERSION
Notez qu'actuellement, vous devez configurer et compiler MySQL depuis la racine de la distribution. Vous ne pouvez pas la compiler ailleurs.
Configurer votre version et compilez le tout :
shell>./configure --prefix=/usr/local/mysqlshell>make
Lorsque vous exécutez le code configure,
vous pouvez aussi ajouter des options. Utilisez la commande
./configure --help pour avoir une liste
des options disponibles.
Section 2.4.2, « Options habituelles de configure », présente certaines
options pratiques.
Si configure échoue et que vous allez
envoyer un courriel aux listes MySQL pour demander de
l'aide, ajouter surtout le contenu du fichier
config.log qui vous semblent
pertinentes. Incluez aussi les dernières lignes affichées
par configure. Postez votre rapport de
bug avec le script mysqlbug. See
Section 1.4.1.3, « Comment rapporter un bogue ou un problème ».
Si la compilation échoue, voyez la section Section 2.4.4, « Problèmes de compilation? », pour avoir de l'aide immédiate sur les problèmes les plus courants.
Installez la distribution :
shell> make install
Si vous voulez écrire un fichier d'option, utilisez un des
fichiers présents dans le dossier
support-files comme exemple. Par
exemple,
shell> cp support-files/my-medium.cnf /etc/my.cnf
Il est possible que vous ayez à éxécuter certaines
commandes en tant que root.
Si vous voulez ajouter le support des tables
InnoDB, vous devez éditer le fichier
/etc/my.cnf, supprimer le caractère
# dans les lignes d'options qui
commencent par innodb_..., et donnez à
ces options la valeur que vous souhaitez. Voyez
Section 4.3.2, « Fichier d'options my.cnf » et
Section 15.4, « Configuration InnoDB ».
Déplacez vous dans le dossier d'installation :
shell> cd /usr/local/mysql
Si vous n'avez jamais installé MySQL auparavant, vous devez créer les tables de droits :
shell> bin/mysql_install_db
Si vous utilisez la commande en tant que
root, il est recommandé d'utiliser
l'option --user présentée. La valeurde
l'option doit être le nom de l'utilisateur créé dans les
premières étapes pour faire fonctionner le serveur. Si
vous exécutez la commande après vous être connecté sous
cet utilisateur, vous pouvez omettre l'utilisation de
l'option --user.
Notez que pour les versions de MySQL plus anciennes que la
version 3.22.10, mysql_install_db laisse
le serveur en fonctionnement après avoir créé les tables.
Ce n'est plus vrai. Vous devez démarrer le serveur
vous-même après avoir fait les dernières étapes
d'installation.
Changez le propriétaire des éxécutables pour les donner
à root et le propriétaire des données
por les donner à mysqld. En supposant
que vous êtes dans le dossier d'installation,
/usr/local/mysql, la commande ressemble
à ceci :
shell>chown -R root .shell>chown -R mysql varshell>chgrp -R mysql .
La première commande modifie l'attribut
owner des fichiers pour les donner à
root user. La seconde donner les fichiers
de données à mysql. La troisième
commande change le groupe group pour les
donner au groupe mysql.
Si vous voulez que MySQL se lance automatiquement au
démarrage de votre serveur, vous pouvez copier le fichier
support-files/mysql.server là ou votre
système cherche les fichiers de démarrage. Plus
d'informations sont disponibles dans le script
support-files/mysql.server et dans la
section Section 2.5.2.2, « Lancer et arrêter MySQL automatiquement ».
Vous pouvez créer de nouveaux comptes en utilisant le
script bin/mysql_setpermission si vous
avez installé les modules Perl DBI et
DBD::mysql. Pour les instructions, voyez
Section 2.9, « Commentaires sur l'installation de Perl ».
Après avoir installé tout, il est recommandé d'initialiser et tester votre installation avec cette commande :
shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &
Pour les versions de MySQL plus ancienne que 4.0, remplacez
bin/safe_mysqld par
bin/mysqld_safe dans la commande.
Si la commande échoue immédiatement avec le message
mysqld ended, vous pouvez trouver certaines
informations dans le fichier
mysql-data-directory/'hostname'.err.
Plus d'informations sur mysqld_safe sont
disponibles dans Section 5.1.3, « safe_mysqld, le script père de
mysqld ».
Note : les comptes qui sont listés dans les tables de droits MySQL n'ont pas de mot de passe initial. Après le démarrage du serveur, il est recommandé de configurer les mots de passe en utilisant les instructions de Section 2.5, « Procédure de post-installation ».
Le script configure vous donne un bon moyen
de contrôler la configuration de votre distribution MySQL.
Habituellement, vous faites cela en spécifiant les options dans
la ligne de commande de configure. Vous
pouvez aussi affecter le comportement de
configure en utilisant certaines variables
d'environnement. See Annexe E, Variables d'environnement.
Pour une liste des options supportées par
configure, exécutez cette commande :
shell> ./configure --help
Les options de configure les plus utilisées
sont décrites ici :
Pour ne compiler que les bibliothèques et programmes
clients, et non le serveur, utilisez l'option
--without-server :
shell> ./configure --without-server
Si vous n'avez pas de compilateur C++,
mysql ne compilera pas (c'est le
programme client qui requière C++). Dans ce cas, vous
pouvez supprimer la partie de code dans
configure qui vérifie l'existence d'un
compilateur C++, puis exécuter
./configure avec l'option
--without-server. La compilation essaiera
encore de construire mysql, mais vous
pouvez ignorer les messages d'erreurs concernant
mysql.cc. (Si make
stoppe, essayez make -k pour dire de
continuer même si on rencontre des erreurs.)
Si vous voulez obtenir une bibliothèque MySQL intégrée
(libmysqld.a) vous devez utiliser
l'option --with-embedded-server.
Si vous ne voulez pas que vos fichiers de log et bases de
données soient dans /usr/local/var,
utiliser une commande configure se
rapprochant de l'une des commandes suivantes :
shell>./configure --prefix=/usr/local/mysqlshell>./configure --prefix=/usr/local \--localstatedir=/usr/local/mysql/data
La première change le préfixe de l'installation pour que
tout soit installé dans
/usr/local/mysql au lieu de
/usr/local par défaut. La seconde
commande préserve le préfixe d'installation par défaut
mais change le répertoire par défaut pour les bases de
données (normalement /usr/local/var)
en /usr/local/mysql/data. Après que vous
ayez compilé MySQL, vous pouvez changer ces options dans
les fichiers d'options. See Section 4.3.2, « Fichier d'options my.cnf ».
Si vous utilisez Unix et que vous voulez que la socket de
MySQL soit à un autre endroit que celui par défaut
(normalement /tmp ou
/var/run) utilisez une commande
configure comme celle-ci :
shell>./configure \--with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock
Notez que le fichier donné doit avoir un chemin absolu !
Vous pourrez aussi changer le chemin vers
mysql.sock plus tard en utilisant les
fichiers d'options de MySQL. See
Section A.4.5, « Comment protéger ou changer le fichier socket
/tmp/mysql.sock ».
Si vous voulez compiler des programmes liés statiquement
(par exemple, pour créer une distribution binaire, pour
obtenir plus de vitesse, ou pour résoudre des problèmes
avec quelques distributions RedHat Linux), exécutez
configure de la manière suivante :
shell>./configure --with-client-ldflags=-all-static \--with-mysqld-ldflags=-all-static
Si vous utilisez gcc et n'avez pas
libg++ ou libstdc++
d'installés, vous pouvez dire à
configure d'utiliser
gcc en tant que compilateur C++ :
shell> CC=gcc CXX=gcc ./configure
Quand vous utilisez gcc en tant que
compilateur C++, aucune tentative de liaison avec
libg++ ou libstdc++ ne
sera effectuée. Il peut être bon d'utiliser cette méthode
même si vous avez les bibliothèques citées, car quelques
versions de celles-ci ont causé des problèmes à des
utilisateurs MySQL par le passé.
Voici quelques variables d'environnement à définir selon le compilateur que vous utilisez :
gcc 2.7.2 :
CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors"
egcs 1.0.3a :
CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors \ -fno-exceptions -fno-rtti"
gcc 2.95.2 :
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \ -felide-constructors -fno-exceptions -fno-rtti"
pgcc 2.90.29 ou plus récent :
CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc \ CXXFLAGS="-O3 -mpentiumpro -mstack-align-double \ -felide-constructors -fno-exceptions -fno-rtti"
Dans la plupart des cas, vous pouvez obtenir un binaire MySQL raisonnablement optimal en utilisant les options de la table précédente et en ajoutant les options suivantes aux lignes de configuration :
--prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static
En d'autres termes, la ligne de configuration ressemble à ce qui suit pour les versions récentes de gcc :
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \ -felide-constructors -fno-exceptions -fno-rtti" ./configure \ --prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-static
Les binaires que nous fournissons sur le site de MySQL à http://www.mysql.com/ sont tous compilés avec une optimisation totale et devraient être parfaits pour la plupart des utilisateurs. See Section 2.1.2.5, « Binaires compilés par MySQL AB ». Il y a quelques choses que vous pouvez modifier pour rendre le binaire encore plus rapide, mais cela est réservé aux utilisateurs avancés. See Section 7.5.4, « Influences de la compilation et des liaisons sur la vitesse de MySQL ».
Si la génération échoue et produit des erreurs disant que
votre compilateur ou outil de liaison n'est pas capable de
créer la bibliothèque partagée
libmysqlclient.so.#
(‘#’ étant un numéro de
version), vous pouvez contourner ce problème en donnant
l'option --disable-shared à
configure. Dans ce cas,
configure ne générera pas de
bibliothèque partagée
libmysqlclient.so.#.
Par défaut, MySQL utilise le jeu de caractères ISO-8859-1
(Latin1). Pour changer le jeu par défaut, utilisez l'option
--with-charset :
shell> ./configure --with-charset=CHARSET
CHARSET peut être l'un des
big5, cp1251,
cp1257, czech,
danish, dec8,
dos, euc_kr,
gb2312, gbk,
german1, hebrew,
hp8, hungarian,
koi8_ru, koi8_ukr,
latin1, latin2,
sjis, swe7,
tis620, ujis,
usa7, ou win1251ukr.
See Section 5.8.1, « Le jeu de caractères utilisé pour les données et le stockage ».
Depuis MySQL 4.1.1, la collation par défaut peut aussi
être spécifiée. MySQL utilise la collation
latin1_swedish_ci. Pour le changer,
utilisez l'option --with-collation :
shell> ./configure --with-collation=COLLATION
Pour changer le jeu de caractères et la collation, utilisez
les options --with-charset et
--with-collation. La collation doit être
valide pour le jeu de caractères spécifié. Utilisez la
commande SHOW COLLATION pour déterminer
les collations valides pour un jeu de caractères donné.
Si vous voulez convertir les caractères entre le serveur et
le client, regardez du côté de la commande SET
CHARACTER SET. See Section 13.5.2.8, « Syntaxe de SET ».
Attention : Si vous
changez les jeux de caractères après avoir crée des
tables, vous devrez exécuter myisamchk -r -q
--set-character-set=charset sur chaque table. Vos
index pourraient être stockés de manière incorrecte
sinon. (Cela peut survenir si vous installez MySQL, créez
quelques tables, puis reconfigurez MySQL pour qu'il utilise
un jeu de caractères différent et le réinstallez.)
Avec l'option --with-extra-charsets=LIST
vous pouvez définir les jeux de caractères additionnels à
compiler dans le serveur.
Ici LIST est soit une liste de jeux de
caractères séparés par des espaces, soit
complex pour inclure tous les jeux de
caractères ne pouvant être chargés dynamiquement, ou
encore all pour inclure tous les jeux de
caractères dans les binaires.
Pour configurer MySQL avec le code de débogage, utilisez
l'option --with-debug :
shell> ./configure --with-debug
Cela alloue un vérificateur d'allocation de mémoire qui peut trouver quelques erreurs et qui fournit des informations sur ce qui se produit. See Section D.1, « Déboguer un serveur MySQL ».
Si vos programmes clients utilisent les threads, vous avez
besoin de compiler une version sûre pour les threads de la
bibliothèque du client MySQL avec l'option de configuration
--enable-thread-safe-client. Cela créera
une bibliothèque libmysqlclient_r avec
laquelle vous devez lier vos applications threadées. See
Section 24.2.15, « Comment faire un client MySQL threadé ».
Les options relatives à un système d'exploitation particulier peuvent être trouvées dans la section spécifique aux systèmes de ce manuel. See Section 2.8, « Notes spécifiques aux systèmes d'exploitation ».
Attention : Vous devez lire cette partie seulement si vous voulez nous aider à tester notre nouveau code. Si vous souhaitez seulement faire fonctionner MySQL sur votre système, vous devriez utiliser la distribution d'une version standard (que ce soit une distribution sous forme de sources ou de binaire).
Pour obtenir notre arbre source de développement le plus réent, suivez les instructions suivantes :
Téléchargez BitKeeper à partir de
http://www.bitmover.com/cgi-bin/download.cgi.
Vous aurez besoin de Bitkeeper 2.0 ou
supérieur pour accéder à notre dépôt.
Suivez les instructions pour l'installer.
Après avoir installé BitKeeper,
commencez par vous déplacer dans le répertoire à partir
duquel vous voulez travailler, et lancez l'une des commandes
suivantes pour dupliquer la branche MySQL de votre choix :
Pour dupliquer la branche 3.23, utilisez cette commande :
shell> bk clone bk://work.mysql.com:7000 mysql-3.23
Pour dupliquer la branche 4.0, utilisez cette commande :
shell> bk clone bk://work.mysql.com:7001 mysql-4.0
Pour dupliquer la branche 4.1, utilisez cette commande :
shell> bk clone bk://work.mysql.com:7004 mysql-4.1
Pour dupliquer la branche 5.0, utilisez cette commande :
shell> bk clone bk://mysql.bkbits.net/mysql-5.0 mysql-5.0
Dans l'exemple précédent, les sources seront
respectivement placées dans les dossiers
mysql-3.23/,
mysql-4.0/,
mysql-4.1/ ou
mysql-5.0/, de votre dossier courant.
Si vous êtes derrière un firewall et que vous ne pouvez
utiliser que des connexions HTTP, vous pouvez aussi accéder
à BitKeeper via HTTP.
Si vous devez utiliser un serveur proxy, assignez la
variable d'environnement http_proxy pour
qu'elle pointe sur votre proxy :
shell> export http_proxy="http://your.proxy.server:8080/"
Puis, remplacez le protocole bk:// par
http:// lors de votre export. Par
exemple :
shell> bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1
Le premier téléchargement de l'arbre source peut prendre un certain temps, selon la vitesse de votre connexion. Soyez patients.
Vous aurez besoin de GNU make,
autoconf 2.53 (ou plus récent),
automake 1.5, libtool
1.4 et m4 pour lancer la prochaine série
de commandes. Même si la plupart des systèmes
d'exploitation sont livrés avec leur propre implémentation
de make, les chances sont fortes pour que
la compilation échoue avec des messages d'erreur étranges.
Par conséquent, il est fortement recommandé d'utiliser GNU
make (parfois aussi appelé
gmake).
Heureusement, d'autres systèmes d'exploitation sont livrés avec les utilitaires GNU, ou propose des paquets facilement installables. Dans tous les cas, vous pouvez les télécharger sur ces sites :
Si vous essayez ded configurer MySQL 4.1 ou plus récent,
vous aurez besoin de GNU bison 1.75 ou
plus récent. Les anciennes versions de
bison peuvent indiquer cette erreur :
sql_yacc.yy:#####: fatal error: maximum table size (32767) exceeded
Note : la taille maximale de la table n'est pas dépassée.
L'erreur est causée par un bug dans les versions plus
anciennes de bison.
Les versions de MySQL avant la version 4.1 peuvent aussi se
compiler avec d'autres versions de yacc
(par exemple, BSD yacc 91.7.30). Pour les
versions plus récentes, GNU bison est
une obligation.
Les commandes typiques nécessaires pour compiler MySQL sont
présentées ci-dessous. La première commande
cd change le dossier de travail :
remplacez mysql-4.0 avec le bon nom de
dossier.
shell>cd mysql-4.0shell>bk -r get -Sqshell>aclocal; autoheader; autoconf; automake;shell>./configure # Ajoutez ici vos options favoritesshell>make
Les lignes de commande qui passent dans les dossiers
innobase et
bdb/dist sont utilisées pour
configurer InnoDB et Berkeley DB
(BDB). Vous pouvez omettre ces lignes si
vous n'avez pas besoin du support InnoDB
ou BDB.
Si vous obtenez des erreurs étranges pendant cette étape,
vérifiez bien que vous avez vraiment installé
libtool!
Une collection de nos scripts de configuration les plus
courants de trouve dans le sous-répertoire
BUILD/. Si vous êtes fainéants, vous
pouvez utiliser
BUILD/compile-pentium-debug. Pour
compiler sur une architecture différente, modifiez ce
script en enlevant les drapeaux spécifiques au Pentium.
Quand la compilation est achevée, lancez make
install. Prenez garde sur des machines de
production. Cette commande pourrait écraser votre
installation actuelle. Si vous avez une autre installation
de MySQL, nous vous recommandons de lancer
./configure avec des valeurs des options
prefix, with-tcp-port,
et unix-socket-path différentes de
celles de votre serveur de production.
Torturez votre nouvelle installation et tentez de faire
planter les nouvelles fonctionnalités. Commencez par lancer
make test. See
Section 27.1.2, « Suite de test de MySQL ».
Si vous avez échoué avec l'étape make
et que la distribution ne compile pas, envoyez un rapport
sur le site
http://bugs.mysql.com/.
Si vous avez installé la dernière version des
indispensables outils GNU, et qu'ils échouent dans
l'analyse de vos fichiers de configuration, envoyez aussi un
rapport. D'autre part, si vous exécutez
aclocal et que vous obtenez l'erreur
command not found ou un problème du
même type, n'envoyez pas de rapport. A la place, assurez
vous que les outils nécessaires sont bien installés et que
votre variable PATH est configurée de
telle fa¸on que votre interpréteur de commandes les
trouvent.
Après la première opération bk clone
pour obtenir l'arbre source, vous devez lancer
régulièrement bk pull pour obtenir les
mises à jour.
Vous pouvez examiner l'historique des changements de l'arbre
avec toutes les différences en utilisant bk
sccstool. Si vous apercevez des différences
anormales ou sur lesquelles vous avez des questions,
n'hésitez pas à envoyer un e-mail aux listes internes. See
Section 1.4.1.1, « Les listes de diffusion de MySQL ». De même, si vous pensez
avoir une meilleure méthode pour traiter un problème,
envoyez un e-mail accompagné d'un patch à la même
adresse. bk diffs vous fournira un patch
après que vous ayez fait vos changements aux sources. Si
vous n'avez pas le temps de coder votre idée, envoyez en
juste une description.
BitKeeper dispose d'une aide agréable à
laquelle vous pouvez accéder via bk
helptool.
Veuillez noter que chaque commit (bk ci
ou bk citool) postera un message avec un
aper¸u des changements à notre liste de diffusion interne,
à la fa¸on habituelle des propositions openlogging.org
avec seulement les commentaires des changements.
Généralement, vous n'aurez pas besoin d'utiliser commit
(l'arbre public interdisant les bk push),
mais plutôt d'utiliser la méthode bk
diffs décrite plus haut.
Vous pouvez aussi naviguer dans les fichiers d'historiques, les commentaires et le code source en ligne. Par exemple, pour lire ses informations pour MySQL 4.1, allez à http://mysql.bkbits.net:8080/mysql-4.1.
Le manuel est dans un module séparé, qui peut être obtenu comme ceci :
shell> bk clone bk://mysql.bkbits.net/mysqldoc mysqldoc
Il y a aussi des arbres BitKeeper pour MySQL Control
Center et Connector/ODBC. Ils sont
disponibles comme ceci :
Pour obtenir le MySQL Control Center,
utilisez cette commande :
shell> bk clone http://mysql.bkbits.net/mysqlcc mysqlcc
Pour obtenir le Connector/ODBC, utilisez
cette commande :
shell> bk clone http://mysql.bkbits.net/myodbc3 myodbc3
Tous les programmes MySQL compilent proprement chez nous, sans
aucune alerte sur Solaris avec gcc. Sur
d'autres systèmes, des alertes peuvent apparaître à cause de
différences dans le système d'inclusions. Voyez
Section 2.4.5, « Notes relatives aux MIT-pthreads » pour les alertes qui peuvent
apparaître avec MIT-pthreads. Pour d'autres
problèmes, voyez la liste suivante.
La solution à de nombreux problèmes implique une nouvelle configuration. Si vous avez besoin de refaire une configuration voici quelques conseils généraux :
Si configure est exécuté après une
première exécution, il peut utiliser des informations qui
ont été rassemblées durant une première invocation. Ces
informations sont stockées dans le fichier
config.cache. Lorsque
configure est lancé, il commence par
regarder dans ce fichier, et lire le contenu qui existe, en
supposant que ces données sont toujours correctes. Cette
supposition est invalide si vous faîtes une
reconfiguration.
Chaque fois que vous exécutez configure,
vous devez exécuter à nouveau make pour
recompiler. Toutefois, vous devrez peut être supprimer les
vieux fichiers d'objets qui ont été compilé en utilisant
différentes configurations précédentes.
Pour éviter d'utiliser de vieilles informations de
configuration, ou des vieux fichiers d'objet, vous pouvez
utiliser ces commandes, avant configure :
shell>rm config.cacheshell>make clean
Alternativement, vous pouvez aussi utiliser make
distclean.
La liste suivante décrit certains problèmes lors de la compilation de MySQL, qui surviennent souvent :
Si vous avez des problèmes lors de la compilation de
sql_yacc.cc, comme ceux qui sont
décrits ci-dessous, vous avez probablement été à court
de mémoire ou d'espace de swap :
Internal compiler error: program cc1plus got fatal signal 11 Out of virtual memory Virtual memory exhausted
Le problème est que gcc requiert de
grandes quantité de mémoire pour compiler
sql_yacc.cc avec les options
inline. Essayez d'exécuter
configure avec l'option
--with-low-memory :
shell> ./configure --with-low-memory
Cette option ajoute -fno-inline dans la
ligne de compilation, si vous utilisez
gcc et -O0 si vous
utilisez autre chose. Vous pouvez essayer
--with-low-memory même si il vous reste
suffisamment de mémoire, et que vous ne pensez pas être
limité. Ce problème a été observé sur des systèmes
avec de généreuses configurations, et
--with-low-memory résout ce problème.
Par défaut, configure choisit
c++ comme compilateur, et GNU
c++ pour les liens avec
-lg++. Si vous utilisez
gcc, ce comportement peut poser les
problèmes suivants :
configure: error: installation or configuration problem: C++ compiler cannot create executables.
Vous pourriez aussi observer des problèmes durant la
compilation, avec g++,
libg++ ou libstdc++.
La cause de ces problèmes est que vous avez peut être que
vous n'avez pas g++, ou que vous avez
g++ mais pas libg++,
ou libstdc++. Regardez le fichier de log
config.log. Il va sûrement contenir la
raison exacte du mauvais fonctionnement de votre
compilateur. Pour contourner ce problème, vous pouvez
utiliser gcc comme compilateur C++.
Essayez de modifier la variable d'environnement
CXX avec la valeur "gcc
-O3". Par exemple :
shell> CXX="gcc -O3" ./configure
Cela fonctionne car gcc compile les
sources C++ aussi bien que g++, mais il
n'est pas lié avec libg++ ou
libstdc++ par défaut.
Un autre moyen pour régler ces problèmes, bien sur, est
d'installer g++,
libg++ et libstdc++.
Nous vous recommandons toutefois de ne pas utiliser
libg++ ou libstdc++
avec MySQL car cela ne fera qu'accroître la taille de votre
exécutable binaire, sans vous apporter d'avantages. Par le
passé, certaines versions de ces bibliothèques ont posé
des problèmes étranges aux utilisateurs MySQL.
Utiliser gcc comme compilateur C++ est
aussi nécessaire, si vous voulez compiler MySQL avec le
support de RAID (voyez Section 13.2.5, « Syntaxe de CREATE TABLE » pour
plus d'information sur le type de table RAID), ou utilisez
GNU gcc version 3 plus récent. Si vous
avez des erreurs de compilation comme celles ci-dessous avec
l'option --with-raid, essayez d'utiliser
gcc comme compilateur C++ en définissant
la variable d'environnement CXX
ci-dessus :
gcc -O3 -DDBUG_OFF -rdynamic -o isamchk isamchk.o sort.o libnisam.a ../mysys/libmysys.a ../dbug/libdbug.a ../strings/libmystrings.a -lpthread -lz -lcrypt -lnsl -lm -lpthread ../mysys/libmysys.a(raid.o)(.text+0x79): In function `my_raid_create':: undefined reference to `operator new(unsigned)' ../mysys/libmysys.a(raid.o)(.text+0xdd): In function `my_raid_create':: undefined reference to `operator delete(void*)' ../mysys/libmysys.a(raid.o)(.text+0x129): In function `my_raid_open':: undefined reference to `operator new(unsigned)' ../mysys/libmysys.a(raid.o)(.text+0x189): In function `my_raid_open':: undefined reference to `operator delete(void*)' ../mysys/libmysys.a(raid.o)(.text+0x64b): In function `my_raid_close':: undefined reference to `operator delete(void*)' collect2: ld returned 1 exit status
Si votre compilation échoue avec des erreurs, ou si l'une
des erreurs suivantes apparaît, vous devez changer la
version de make en GNU
make:
making all in mit-pthreads make: Fatal error in reader: Makefile, line 18: Badly formed macro assignment
ou :
make: file `Makefile' line 18: Must be a separator (:
ou :
pthread.h: No such file or directory
Solaris et FreeBSD sont connus pour avoir des problèmes
avec make.
GNU make version 3.75 est reconnu pour
fonctionner.
Si vous voulez définir des options supplémentaires qui
seront utilisées par votre compilateur C ou C++, faites le
en ajoutant ces options aux variables d'environnement
CFLAGS et CXXFLAGS.
Vous pouvez aussi spécifier le nom du compilateur via les
variables CC et CXX.
Par exemple :
shell>CC=gccshell>CFLAGS=-O3shell>CXX=gccshell>CXXFLAGS=-O3shell>export CC CFLAGS CXX CXXFLAGS
Voyez Section 2.1.2.5, « Binaires compilés par MySQL AB », pour avoir une liste des définitions des options disponibles sur divers systèmes.
Si vous obtenez un message d'erreur comme celui-ci, vous
devrez mettre à jour votre version de
gcc :
client/libmysql.c:273: parse error before `__attribute__'
gcc 2.8.1 est connu pour fonctionner,
mais nous recommandons l'utilisation de
gcc 2.95.2 ou egcs
1.0.3a.
Si vous obtenez des erreurs telles que celles qui sont
affichées ci-dessous lors de la compilation de
mysqld, c'est que
configure n'a pas correctement détecter
le dernier argument des fonctions
accept(),
getsockname() ou
getpeername() :
cxx: Error: mysqld.cc, line 645: In this statement, the referenced
type of the pointer value "&length" is "unsigned long", which
is not compatible with "int".
new_sock = accept(sock, (struct sockaddr *)&cAddr, &length);
Pour corriger ce problème, éditez le fichier
config.h (qui est généré par le
fichier configure). Recherchez ces
lignes :
/* Define as the base type of the last arg to accept */ #define SOCKET_SIZE_TYPE XXX
Remplacez XXX par
size_t ou int, suivant
votre système d'exploitation. Notez que vous devrez faire
cette manipulation à chaque fois que vous exécuterez le
script configure car
configure regénére
config.h.
Le fichier sql_yacc.cc est généré à
partir du fichier sql_yacc.yy.
Normalement, le processus de création ne s'occupe pas de
sql_yacc.cc, car MySQL en a déjà une
copie. Cependant, si vous devez le recréer, vous pouvez
rencontrer cette erreur :
"sql_yacc.yy", line xxx fatal: default action causes potential...
Cela indique que votre version de yacc
est inadéquate. Vous devrez probablement réinstaller
bison (la version GNU de
yacc) et l'utiliser à la place.
Sur Debian Linux 3.0, vous devez installer
gawk au lieu du programme par défaut
mawk si vous voulez compiler MySQL 4.1 ou
plus récent avec le support Berkeley DB.
Si vous avez besoin de déboguer mysqld
ou un client MySQL, exécutez le script
configure avec l'option
--with-debug, puis recompilez vos clients
avec la nouvelle bibliothèque. See
Section D.2, « Débogage un client MySQL ».
Si vous rencontrez une erreur de compilation sous Linux (e.g. SuSE Linux 8.1 ou Red Hat Linux 7.3) similaire à celle-ci :
libmysql.c:1329: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type libmysql.c:1329: too few arguments to function `gethostbyname_r' libmysql.c:1329: warning: assignment makes pointer from integer without a cast make[2]: *** [libmysql.lo] Error 1
Par défaut, le script configure tente de
déterminer le nombre correct d'argument en utilisant
g++, le compilateur GNU C++. Ce test
retourne des résultats erroné si g++
n'est pas installé. Il y a deux fa¸ons de contourner le
problème :
Assurez vous que GNU C++ g++ est
installé. Sur certains Linux, le paquet nécessaire est
appelé gpp, et sur d'autres, c'est
gcc-c++.
Utilisez gcc comme compilateur C++ en
mettant donnant à la variable d'environnement
CXX, la valeur de
gcc:
export CXX="gcc"
Notez bien que vous devez lancer
configure après cela.
Cette section décrit quelques informations concernant
l'utilisation des MIT-pthreads.
Notez que sur Linux vous ne devez pas
utiliser les MIT-pthreads mais installer
LinuxThreads ! See Section 2.8.1, « Notes relatives à Linux (toutes versions) ».
Si votre système ne fournit pas un support natif des threads,
vous aurez besoin de construire MySQL en utilisant le paquet des
MIT-pthreads. Cela inclut les anciens
systèmes FreeBSD, SunOS 4.x, Solaris 2.4 et plus ancien, et
quelques autres systèmes. See Section 2.1.1, « Systèmes d'exploitation supportés par MySQL ».
Notez qu'à partir de la version 4.0.2 de MySQL les
MIT-pthreads ne font plus partie de la
distribution des sources ! si vous avez besoin de ce paquet,
vous pouvez l'obtenir sur
http://www.mysql.com/Downloads/Contrib/pthreads-1_60_beta6-mysql.tar.gz
Après l'avoir récupéré, décompressez l'archive dans le
répertoire racine de votre répertoire des sources de MySQL.
Cela créera le répertoire mit-pthreads.
Sur la plupart des systèmes, vous pouvez forcer
l'utilisation des MIT-pthreads en
exécutant configure avec l'option
--with-mit-threads :
shell> ./configure --with-mit-threads
La compilation dans un dossier non-sources n'est pas
supporté lors de l'utilisation des
MIT-pthreads car nous voulons minimiser
les changements de leur code.
La vérification pour l'utilisation des
MIT-pthreads ne survient que durant la
partie du processus de configuration qui s'occupe du code du
serveur. Si vous avez configuré la distribution en
utilisant --without-server pour ne
construire que le client, les clients ne sauront pas si les
MIT-pthreads sont utilisés et
utiliserons les socket Unix pour les connexions par défaut.
Puisque les sockets Unix ne fonctionnent pas avec les
MIT-pthreads sur certaines plate-formes,
cela signifie que vous devrez utiliser -h
ou --host quand vous exécuterez les
programmes clients.
Lorsque MySQL est compilé en utilisant les
MIT-pthreads, le verrouillage système
est désactivé par défaut pour des soucis de performances.
Vous pouvez demander au serveur d'utiliser les verrous
systèmes avec l'option --external-locking.
Cela n'est requis que si vous avez besoin de faire
fonctionner deux serveurs MySQL avec les mêmes données
(non recommandé).
De temps en temps, la commande bind() des
pthreads n'arrive pas à attacher une socket sans afficher
d'erreurs (du mois, sous Solaris). Le résultat est que
toutes les connexions au serveur échouent. Par exemple :
shell> mysqladmin version
mysqladmin: connect to server at '' failed;
error: 'Can't connect to mysql server on localhost (146)'
La solution est de terminer le serveur
mysqld et de le redémarrer. Cela ne nous
est arrivé que quand nous avons forcé le serveur à se
terminer et que nous l'avons redémarré immédiatement
après.
Avec les MIT-pthreads, l'appel système
à sleep() ne peut pas être interrompu
avec SIGINT (break).
On ne s'en rend compte que quand on exécute
mysqladmin --sleep. Vous devez attendre
que l'appel système à sleep() se
termine avant que le processus ne s'arrête.
Lors de la liaison, vous pouvez obtenir des messages d'erreurs comme ceux-ci (du moins sur Solaris); ils peuvent être ignorés :
ld: warning: symbol `_iob' has differing sizes:
(file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
file /usr/lib/libc.so value=0x140);
/my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
ld: warning: symbol `__iob' has differing sizes:
(file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
file /usr/lib/libc.so value=0x140);
/my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
D'autres avertissements peuvent être ignorés :
implicit declaration of function `int strtoll(...)' implicit declaration of function `int strtoul(...)'
Nous n'avons pas réussi à faire fonctionner
readline avec les
MIT-pthreads. (Cela n'est pas
nécessaire, mais peut être utile à quelqu'un.)
Ces instructions décrivent comment compiler MySQL version 4.1, depuis les sources, pour Windows. Les instructions sont fournies pour compiler les versions standards à partir des sources standards, ou depuis la version de développement de BitKeeper.
Note : :es instructions de ce document sont strictement destinées aux utilisateurs qui veulent tester MySQL sur Windows, à partir des toutes dernières sources de BitKeeper. Pour un serveur de production, MySQL vous recommande de ne pas compiler votre serveur vous-même. Normalement, il est mieux d'utiliser une distribution binaire précompilée, et optimisée pour l'utilisation sur Windows par MySQL AB. Les instructions d'installation pour les distributions binaires sont disponibles dans la section Section 2.2.1, « Installer MySQL sous Windows ».
Pour compiler MySQL sur Windows depuis les sources, vous avez besoin des logiciels et ressources suivantes sur votre système :
Le compilateur VC++ 6.0 (mis à jour avec
le service pack 4 ou 5, et paquet
pre-processeur) Le paquet pre-processeur est nécessaire
pour l'assembleur macro. Plus de détails à :
http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/faq.aspx.
Environs 45 Mo d'espace disque.
64 Mo de RAM
Vous aurez besoin de la distribution source MySQL pour Windows. Il y a deux méthodes pour obtenir cette distribution pour MySQL 4.1 et supérieur :
Télécharger une distribution source préparée par MySQL AB pour la version de MySQL que vous voulez. Les distributions sources pre-compilées sont disponibles pour les versions de MySQL publiées, et sont accessibles sur le site de http://www.mysql.com/downloads/.
Vous pouvez préparer votre propre distribution source vous-même, avec la dernière version disponible sur le serveur BitKeeper. Si vous voulez faire cela, vous devez créer la distribution sur un serveur Unix, et transférer l'archive sur votre système Windows. La raison est que certaines étapes de configuration requièrent des outils qui ne fonctionnent que sous Unix. L'approche BitKeeper requiert :
Un système fonctionnant sous Unix, ou un système équivalent, comme Linux.
BitKeeper 3.0 sur ce système. Vous pouvez obtenir BitKeeper sur http://www.bitkeeper.com/.
Si vous utilisez une distribution source Windows vous pouvez passer directement à Section 2.4.6.1, « Compiler MySQL avec VC++ ». Pour compiler depuis les sources BitKeeper, commencez par Section 2.4.6.2, « Compiler MySQL sur Windows à partir des sources de développement ».
Si vous découvrez quelque chose qui ne fonctionne pas comme
prévu, ou si vous avez des suggestions pour améliorer le
processus actuel envoyez un message à la liste de diffusion
dédiée à win32. See
Section 1.4.1.1, « Les listes de diffusion de MySQL ».
Note: Les fichiers du projet
VC++ de MySQL 4.1 et plus récent sont
compatibles avec Microsoft Visual Studio
6.0 et plus récent (7.0/.NET) et sont testés par
l'équipe de MySQL AB avant chaque publication.
Pour compiler MySQL, suivez ces instructions ci-dessous. Notez que les noms de menus sont laissés en anglais, et devront éventuellement être adaptés à votre interface.
Créez un dossier de travail : par exemple,
workdir.
Décompressez la distribution source dans le dossier
ci-dessus, en utilisant WinZip ou un
autre utilitaire Windows qui sache lire les fichiers
.zip.
Lancez le compilateur VC++ 6.0.
Dans le menu File, sélectionnez
Open Workspace.
Ouvrez le fichier mysql.dsw que vous
trouverez dans le dossier de travail.
Dans le menu Build, sélectionnez le
menu Set Active Configuration.
Cliquez dans le dialogue pour sélectionner
mysqld - Win32 Debug, puis cliquez sur
OK.
Pressez F7 pour lancer la compilation
du serveur de débogage, des bibliothèques et des
applications clients.
Compilez la version que vous souhaitez, de la même fa¸on.
Les versions de débogage et les bibliothèques sont
placées dans les dossiers
client_debug et
lib_debug. Les versions finales des
programmes et bibliothèques sont placées dans les
dossiers client_release et
lib_release. Notez que si vous voulez
compiler les versions de débogage et finales, vous pouvez
utiliser l'option ``build all'' dans le
menu Build.
Testez le serveur. Le serveur compilé avec les
instructions suivantes suppose que le dossier de base
MySQL et le dossier de données sont situés dans les
dossiers C:\mysql et
C:\mysql\data, par défaut. Si vous
voulez tester votre serveur, utilisez le chemin de votre
dossier d'installation comme chemin racine. Vous pouvez
faire cela en ligne de commande, avec les options
--basedir et --datadir
ou bien placez les bonnes options dans le fichier
d'options (C:\my.cnf ou
my.ini de votre dossier Windows). Si
vous avez un dossier de données sur votre disque, vous
pouvez spécifier son chemin.
Lancez le serveur depuis le dossier
client_release ou
client_debug, suivant la version que
vous voulez utiliser. Les instructions générales de
lancement sont dans
Section 2.2.1, « Installer MySQL sous Windows ». Vous devrez
adapter les instructions à votre configuration, si vous
avez un dossier de base ou de données différents.
Lorsque le serveur fonctionne en mode indépendant ou
comme un service, suivant votre configuration, essayez de
vous connecter avec le client interactif
mysql, qui est placé dans le dossier
client_release ou
client_debug.
Lorsque vous êtes satisfait du fonctionnement de votre serveur, stoppez le. Puis installez MySQL comme ceci :
Créez un dossier sur votre disque pour installer MySQL.
Par exemple, nous pourrions l'installer dans
C:\mysql. Voici les commandes :
C: mkdir \mysql mkdir \mysql\bin mkdir \mysql\data mkdir \mysql\share mkdir \mysql\scripts
Si vous voulez compiler d'autres clients et les lier à MySQL, il faudra créer d'autres dossiers :
mkdir \mysql\include mkdir \mysql\lib mkdir \mysql\lib\debug mkdir \mysql\lib\opt
Si vous voulez tester les performances de MySQL, créez ce dossier :
mkdir \mysql\sql-bench
Les tests de performances requièrent Perl.
Depuis le dossier workdir, copiez
dans le dossier C:\mysql les fichiers
suivants :
copy client_release\*.exe C:\mysql\bin copy client_debug\mysqld.exe C:\mysql\bin\mysqld-debug.exe xcopy scripts\*.* C:\mysql\scripts /E xcopy share\*.* C:\mysql\share /E
Si vous voulez compiler d'autres clients, et les lier avec MySQL, vous devrez aussi faire ceci :
copy lib_debug\mysqlclient.lib C:\mysql\lib\debug copy lib_debug\libmysql.* C:\mysql\lib\debug copy lib_debug\zlib.* C:\mysql\lib\debug copy lib_release\mysqlclient.lib C:\mysql\lib\opt copy lib_release\libmysql.* C:\mysql\lib\opt copy lib_release\zlib.* C:\mysql\lib\opt copy include\*.h C:\mysql\include copy libmysql\libmysql.def C:\mysql\include
Si vous voulez tester les performances de MySQL, faites aussi ceci :
xcopy sql-bench\*.* C:\mysql\bench /E
Puis lancez votre serveur de la même fa¸on que vous lancez l'exécutable MySQL classique. See Section 2.2.1, « Installer MySQL sous Windows ».
Pour compiler la dernière version Windows à partir de sources disponibles dans le serveur BitKeeper, suivez les instructions suivantes. Notez que ces commandes doivent être exécutés sur un système fonctionnant sous Unix ou Linux. La procédure fonctionne très bien sous Linux, par exemple.
Clonez les source issues de BitKeeper (version 4.1 ou plus récent). Pour plus d'informations sur comment cloner les sources sont disponibles dans la section Section 2.4.3, « Installer à partir de l'arbre source de développement ».
Configurez et compilez la distribution pour obtenir un serveur fonctionnel. Pour cela, vous pouvez lancez la commande suivante à la racine de vos sources :
shell> ./BUILD/compile-pentium-max
Après vous être assurés que le processus est complet et réussi, lancez l'utilitaire suivant depuis la racine de vos sources :
shell> ./scripts/make_win_src_distribution
Ce script crée un paquet source Windows, qui peut être utilisé sur votre système. Vous pouvez passer d'autres options à ce script, suivant vos besoins. Il accepte les options suivantes :
--help
Affiche ce message d'aide.
--debug
Débogage, sans créer le paquet.
--tmp
Spécifie le dossier temporaire.
--suffix
Suffixe pour le nom du paquet.
--dirname
Nom du dossier où copier les fichiers (intermédiaire).
--silent
Ne liste pas tous les fichiers traités.
--tar
Crée le paquet au format tar.gz
plutôt que .zip.
Par défaut, make_win_src_distribution
crée une archive zippée avec le nom
mysql-VERSION-win-src.zip, où
VERSION représente la version de votre
source MySQL.
Copiez ou téléchargez le paquet sur votre machine Windows. Pour le compiler, suivez les instructions de la section Section 2.4.6.1, « Compiler MySQL avec VC++ ».
Dans vos fichiers sources, vous devez inclure
windows.h avant
mysql.h :
#if defined(_WIN32) || defined(_WIN64) #include <windows.h> #endif #include <mysql.h>
my_global.h inclut tous les autres fichiers
nécessaires pour Windows (comme le fichier
windows.h) si vous compilez votre programme
sous Windows.
Vous pouvez soit lier votre code avec la bibliothèque dynamique
libmysql.lib, qui est juste une interface
pour charger libmysql.dll à la demande,
soit lier avec la bibliothèque statique
mysqlclient.lib.
Notez que puisque les bibliothèques
mysqlclient sont compilées en tant que
bibliothèques threadées, vous devez aussi compiler votre code
pour qu'il soit multi-threadé !
Il y a des manipulations importantes à faire après avoir installé MySQL. Par exemple, sous Unix, vous devez créer les tables de droits. Sur toutes les plate-forme, un point de sécurité important est que les comptes initiaux n'ont pas de mot de passe. Vous devez assigner les mots de passe pour éviter un accès indu au serveur MySQL.
Les sections suivantes décrivent les procédures de post installation sur Windows et pour les systèmes Unix. Une autre section, Section 2.5.2.3, « Problèmes de démarrage du serveur MySQL » s'applique aux autres plate-formes : elle décrit ce que vous devez faire si vous avez des problèmes de lancement. La section Section 2.5.3, « Création des premiers droits MySQL » s'applique aussi à toutes les plate-formes. Vous devez suivre les instructions pour vous assurer que vous avez bien protégé vos comptes MySQL en leur assignant un mot de passe.
Lorsque vous êtes prêts à créer d'autres comptes, vous pouvez trouver des informations sur le contrôle d'accès à MySQL et la gestion de comptes dans les sections Section 5.5, « Règles de sécurité et droits d'accès au serveur MySQL » et Section 5.6, « Gestion des comptes utilisateurs de MySQL ».
Sous Windows, la table de droits n'a pas besoin d'être créée.
Les distributions MySQL pour Windows incluent les tables de
droits pré-configurées dans la base mysql,
dans le dossier de données data.
Cependant, vous devez assigner des mots de passe aux comptes.
Avant de donner des mots de passe aux comptes, vérifiez que le serveur fonctionne avec un client. Assurez vous que le serveur fonctionne (see Section 2.2.8.2, « Démarrer le serveur pour la première fois »), puis utilisez les commandes suivantes pour vérifier que vous pouvez lire des données sur le serveur. Lr résultat doit être proche de celui présenté ici :
C:\>C:\mysql\bin\mysqlshow+-----------+ | Databases | +-----------+ | mysql | | test | +-----------+ C:\>C:\mysql\bin\mysqlshow mysqlDatabase: mysql +--------------+ | Tables | +--------------+ | columns_priv | | db | | func | | host | | tables_priv | | user | +--------------+ C:\>C:\mysql\bin\mysql -e "SELECT Host,Db,User FROM db" mysql+------+-------+------+ | host | db | user | +------+-------+------+ | % | test% | | +------+-------+------+
Si vous avez une version fonctionnelle de Windows qui supporte les services, et que vous voulez que MySQL fonctionne automatiquement au lancement de Windows, voyez la section Section 2.2.9.1, « Lancer MySQL comme un service Windows ».
Une fois que vous avez installé MySQL sur Unix, vous devez initialiser les tables de droits, lancer le serveur, et vous assurer que tout fonctionne bien. Vous pouvez aussi configurer le démarrage et l'extinction automatique du serveur, lorsque votre serveur se lance et s'arrête.
Sous Unix, les tables de droits sont configurées avec le
programme mysql_install_db. Pour certaines
méthodes d'installation, ce programme est utilisé
automatiquement :
Si vous installez MySQL sous Linux avec un
RPM, le serveur RPM
exécute mysql_install_db.
Si vous installez MySQL sous Mac OS X en utilisant la
distribution PKG, l'installeur exécute
mysql_install_db.
Sinon, vous devez lancer manuellement
mysql_install_db.
La procédure suivante décrit comment initialiser les tables de droits (si cela n'a pas été fait), puis comment lancer le serveur. Vous trouverez aussi des suggestions de commandes pour tester l'accessibilité du serveur. Pour des informations sur le démarrage et l'extinction automatique du serveur, voyez Section 2.5.2.2, « Lancer et arrêter MySQL automatiquement ».
Une fois que vous avez exécuté la procédure, et que le
serveur fonctionne, vous devez assigner des mots de passe aux
comptes créés par mysql_install_db. Les
instructions pour faire cela
Section 2.5.3, « Création des premiers droits MySQL ».
Dans les exemples ici, le serveur fonctionne avec l'utilisateur
mysql. On suppose donc que ce compte existe.
Créez ce compte, s'il n'existe pas, ou bien utilisez le nom que
vous avez choisi.
Changez de dossier de travail, pour vous mettre à la racine
de l'installation MySQL, représentée ici par
BASEDIR :
shell> cd BASEDIR
BASEDIR vaut probablement
/usr/local/mysql ou
/usr/local. Les étapes suivantes
supposent que vous êtes dans ce dossier.
Si nécessaire, lancez le programme
mysql_install_db pour configurer les
tables de droits initiales, qui déterminent les
utilisateurs qui sont autorisées à se connecter au
serveur. Vous devez faire cela si vous avez installé le
programme avec une distribution qui ne lance pas ce
programme pour vous.
Typiquement, mysql_install_db doit être
utilisé uniquement à la première installation, et vous
pouvez éviter cette étape si vous faites une mise à jour.
Cependant, mysql_install_db n'écrase pas
les tables de droits : vous pouvez l'utiliser, en cas de
doute.
Pour initialiser les tables de droits, utilisez une des
commandes suivantes, en fonction de la localisation de
mysql_install_db dans le dossier
bin scripts :
shell>bin/mysql_install_db --user=mysqlshell>scripts/mysql_install_db --user=mysql
Le script mysql_install_db crée la base
mysql qui contient les tables de droits,
et la base test que vous pouvez utiliser
pour les tests avec MySQL. Ce script va aussi créer
l'utilisateur root et un compte anonyme.
Ces deux comptes sont créés sans mot de passe. Une
description des droits initiaux sont présentés dans la
section Section 2.5.3, « Création des premiers droits MySQL ». Le script
mysqld_safe lance le serveur
mysqld. Avant la version 4.0, utilisez
safe_mysqld au lieu de
mysqld_safe.
Il est important de vous assurer que les dossiers et les
fichiers appartiennent au compte mysql
pour que le serveur puisse lire et écrire dedans. Pour
cela, l'option --user doit être utilisée
comme présenté si vous utilisez
mysql_install_db comme
root. Sinon, il est recommandé
d'exécuter le script lorsque vous êtes connectés en tant
que mysql : dans ce cas, vous pouvez
omettre l'option --user.
mysql_install_db crée de nombreuses
tables dans la base mysql :
user, db,
host, tables_priv,
columns_priv, func, et
même d'autres, en fonction des versions de MySQL.
Si vous ne voulez pas de la base test,
vous pouvez la supprimer avec mysqladmin -u root
drop test au redémarrage du serveur.
Si vous avez des problèmes avec
mysql_install_db, voyez
Section 2.5.2.1, « Problèmes d'exécution de mysql_install_db ».
Il y a d'autres alternatives pour lancer
mysql_install_db tel que fournit par la
distribution MySQL :
Si vous voulez que les droits initiaux soient
différents des valeurs par défaut, vous pouvez
modifier le script mysql_install_db
avant de l'exécuter. Cependant, une technique
préférable est d'utiliser GRANT et
REVOKE pour changer les droits après
avoir configuré les tables de droits. En d'autres
termes, vous pouvez lancer
mysql_install_db, puis utiliser
mysql -u root mysql pour vous
connecter au serveur en tant que root
MySQL, pour émettre les commandes
GRANT et REVOKE.
Si vous voulez installer MySQL sur de nombreuses
machines avec les mêmes droits, vous pouvez mettre les
commandes GRANT et
REVOKE dans un fichier de script, et
exécuter ce script avec mysql après
avoir utilisé mysql_install_db. Par
exemple :
shell>bin/mysql_install_db --user=mysqlshell>bin/mysql -u root < your_script_file
Comme cela, vous pouvez éviter les problèmes de répétition manuelle entre chaque machine.
Il est possible de re-créer entièrement les tables de
droits après les avoir créées. Vous pouvez le faire
si vous apprenez comment utiliser
GRANT et REVOKE et
que vous avez fait tellement de modifications après
mysql_install_db que vous voulez
recommencer à zéro.
Pour re-créer les tables de droits, supprimez les
fichiers .frm,
.MYI et .MYD
dans le dossier contenant les tables
mysql. C'est le dossier appelé
mysql dans le dossier de données,
qui est listé dans le dossier
datadir lorsque vous utilisez la
commande mysqld --help. Puis,
utilisez à nouveau le script
mysql_install_db.
Note : pour les
versions MySQL antérieure à la version 3.22.10, vous
ne devez pas supprimer les fichiers
.frm. Si vous les supprimez
accidentellement, essayez de les retrouver et de les
remettre dans le dossier mysql
depuis votre distribution MySQL, avant d'utiliser
mysql_install_db.
Vous pouvez lancer mysqld
manuellement en utilisant l'option
--skip-grant-tables et en ajoutant les
droits mysql :
shell>bin/mysqld_safe --user=mysql --skip-grant-tables &shell>bin/mysql mysql
Depuis mysql, exécutez manuellement
les commandes SQL contenues dans le script
mysql_install_db. Assurez vous que
vous utilisez mysqladmin
flush-privileges ou mysqladmin
reload après, pour dire au serveur de relire
les tables de droits.
Notez que si vous n'utilisez pas
mysql_install_db, vous devez remplir
les tables manuellement, et en plus, vous devez
commencer par les créer.
Lancez le serveur MySQL :
shell> bin/mysqld_safe --user=mysql &
Pour les versions de MySQL antérieure à 4.0, remplacez
bin/safe_mysqld par
bin/mysqld_safe dans cette commande.
Il est important de vous assurez que le dossier de base de
données et les fichiers de mysql sont
accessibles, pour que le serveur puisse y lire et écrire.
Pour cela, l'option --user peut être
utilisée avec mysql_install_db si vous
l'exécutez en tant que root. Sinon, vous
devez exécuter le script lorsque vous êtes identifié
comme mysql, auquel cas, vous pouvez
omettre l'option --user.
D'autres instructions pour faire fonctionner MySQL en tant qu'utilisateur sans droits sont données dans la section Section A.3.2, « Comment exécuter MySQL comme un utilisateur normal ».
Si vous n'avez pas créé les tables de droits, l'erreur suivante sera inscrite dans le fichier de log d'erreur de votre serveur :
mysqld: Can't find file: 'host.frm'
Si vous avez des problèmes au démarrage du serveur, voyez Section 2.5.2.3, « Problèmes de démarrage du serveur MySQL ».
Utilisez mysqladmin pour vérifier que le
serveur fonctionne. La commande suivante vous permet de
faire un test simple pour vérifier que le serveur est actif
et qu'il répond aux connexions :
shell>bin/mysqladmin versionshell>bin/mysqladmin variables
Le résultat de mysqladmin version varie
légèrement, suivant votre plates-formes et votre version
de MySQL, mais il doit être proche de ceci :
shell> bin/mysqladmin version
mysqladmin Ver 8.40 Distrib 4.0.18, for linux on i586
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license
Server version 4.0.18-log
Protocol version 10
Connection Localhost via Unix socket
TCP port 3306
UNIX socket /tmp/mysql.sock
Uptime: 16 sec
Threads: 1 Questions: 9 Slow queries: 0
Opens: 7 Flush tables: 2 Open tables: 0
Queries per second avg: 0.000
Memory in use: 132K Max memory used: 16773K
Pour voir ce que vous pouvez faire d'autre avec
mysqladmin, utilisez l'option
--help.
Vérifiez que vous pouvez éteindre le serveur :
shell> BINDIR/mysqladmin -u root shutdown
Vérifiez que vous pouvez relancer le serveur. Pour cela,
utilisez mysqld_safe ou
mysqld directement. Par exemple :
shell> BINDIR/mysqld_safe --log &
Si mysqld_safe échoue, essayez de
l'exécuter directement depuis le dossier d'installation
MySQL (si vous n'y êtes pas déjà). Si cela ne fonctionne
toujours pas, voyez Section 2.5.2.3, « Problèmes de démarrage du serveur MySQL ».
Exécutez les tests simples pour vérifier que le serveur fonctionne. Le résultat devrait être proche de celui-ci :
shell>BINDIR/mysqlshow+-----------+ | Databases | +-----------+ | mysql | +-----------+ shell>BINDIR/mysqlshow mysqlDatabase: mysql +--------------+ | Tables | +--------------+ | columns_priv | | db | | func | | host | | tables_priv | | user | +--------------+ shell>BINDIR/mysql -e "SELECT host,db,user FROM db" mysql+------+--------+------+ | host | db | user | +------+--------+------+ | % | test | | | % | test_% | | +------+--------+------+
Il y a aussi une suite de tests dans le dossier
sql-bench (sous le dossier
d'installation MySQL) que vous pouvez utiliser pour comparer
les performances de MySQL sur différentes plates-formes. La
suite de tests utilise le module Perl DBI
pour assurer une interface avec les autres bases de
données. Les modules Perl suivants sont aussi nécessaires
pour exécuter la suite de tests :
DBI DBD::mysql Data::Dumper Data::ShowTable
Ces modules sont disponibles sur la bibliothèque
CPAN
http://www.cpan.org/.
See Section 2.9.1, « Installer Perl sur Unix ».
Le dossier sql-bench/Results contient
des résultats de tests sur différentes plates-formes et
bases. Pour lancer tous les tests, exécutez ces
commandes :
shell>cd sql-benchshell>run-all-tests
Si vous n'avez pas de dossier
sql-bench, vous avez probablement
installé MySQL avec un fichier RPM,
différent du RPM source. Le
RPM source inclut le dossier
sql-bench) Dans ce as, vous devez
d'abord installer la suite de tests avant de l'utiliser.
Depuis MySQL version 3.22, il y a des fichiers de tests
RPM appelé
mysql-bench-VERSION-i386.rpm, qui
contiennent le code et les données.
Si vous avec une distribution source, il y a aussi des tests
dans le sous-dossier tests. Par
exemple, pour lancer
auto_increment.tst, faîtes :
shell> BINDIR/mysql -vvf test < ./tests/auto_increment.tst
Les résultats attendus des tests sont disponibles dans le
fichier ./tests/auto_increment.res.
A ce point, vous devez avoir un serveur fonctionnel. Cependant, les comptes initiaux n'ont pas de mot de passe : il est recommandé de leur assigner des mots de passe en suivant les instructions de la section Section 2.5.3, « Création des premiers droits MySQL ».
Le but du script mysql_install_db est de
générer un nouveau système de droits pour MySQL. Il ne
modifiera aucune autre donnée! Il ne fera rien du tout si
vous avez des tables de droits installées.
Si vous voulez recréer vos tables de droits, vous devez
éteindre le serveur mysqld, s'il
fonctionnait. Puis, renommez le dossier
mysql dans le dossier de données, sauvez
le, et exécutez le script
mysql_install_db. Par exemple :
shell>mv mysql-data-directory/mysql mysql-data-directory/mysql-oldshell>mysql_install_db --user=mysql
Cette section liste les problèmes que vous pourriez
rencontrer lors de l'exécution du script
mysql_install_db :
mysql_install_db
n'installe pas les tables de droits
Vous réalisez que mysql_install_db
n'arrive pas à installer les tables de droits, et se
termine sur ce message :
starting mysqld daemon with databases from XXXXXX mysql daemon ended
Dans ce cas, examinez le fichier de log très
attentivement! Le fichier de log est situé dans le
dossier XXXXXX indiqué dans le
message d'erreur, et il indiquera pourquoi
mysqld n'a pas démarré. Si vous ne
comprenez pas ce qui est arrivé, incluez le log dans
votre message, lors de l'envoi du rapport de bugs avec
mysqlbug! See
Section 1.4.1.3, « Comment rapporter un bogue ou un problème ».
Un démon mysqld
fonctionne déjà
Dans ce cas, vous n'avez probablement pas exécuté
mysql_install_db du tout. Vous avez
exécuté mysql_install_db une fois,
lorsque vous avez installé MySQL pour la première fois.
Installer un second démon
mysqld n'est pas possible lorsque le
premier fonctionne.
Cela arrive lorsque vous avez une installation MySQL pre-existantes, mais que vous voulez installer une autre version ailleurs (par exemple, pour faire des tests ou simplement pour avoir deux installations). Généralement, le problème survient lorsque le second serveur est démarré, et qu'il essaie d'utiliser les mêmes ports et sockets que le premier. Dans ce cas, vous recevez des message d'erreur tels que :
Can't start server: Bind on TCP/IP port: Address already in use Can't start server: Bind on unix socket...
Pour des instructions sur la configuration de serveurs multiples, voyez la section Section 5.10, « Faire fonctionner plusieurs serveurs MySQL sur la même machine ».
You don't have write access
to
/tmp
Si vous n'avez pas les droits d'accès suffisant pour
créer un fichier de socket à l'endroit prévu ou les
permissions pour créer un fichier temporaire dans
/tmp, vous allez avoir une erreur
lors de l'utilisation de
mysql_install_db ou avec
mysqld.
Vous pouvez spécifier une socket différente et un dossier temporaire différent avec les options suivantes :
shell>TMPDIR=/some_tmp_dir/shell>MYSQL_UNIX_PORT=/some_tmp_dir/mysql.sockshell>export TMPDIR MYSQL_UNIX_PORT
some_tmp_dir doit être le chemin
complet d'un dossier dans lequel vous avez les droits en
écriture.
Après cela, vous devriez être capable d'exécuter
mysql_install_db et lancer le serveur
avec ces commandes :
shell>bin/mysql_install_db --user=mysqlshell>bin/mysqld_safe --user=mysql &
Si mysql_install_db est situé dans le
dossier scripts, modifiez la
première commande pour utiliser
scripts/mysql_install_db.
Voyez Section A.4.5, « Comment protéger ou changer le fichier socket
/tmp/mysql.sock ». See
Annexe E, Variables d'environnement.
Généralement, vous démarrez le serveur
mysqld par l'un de ces moyens :
En appelant mysqld directement. Cela
fonctionne sur toutes les plates-formes.
En lan¸ant le serveur MySQL comme un service Windows. Cela fonctionne sur les versions de Windows qui supportent les services : comme Windows NT, 2000 et XP. Le service peut être configuré pour démarrer automatiquement au lancement de Windows, ou manuellement, à la demande. Pour des instructions, reportez vous à Section 2.2.9.1, « Lancer MySQL comme un service Windows ».
En appelant mysqld_safe, qui essaie de
déterminer les options correctes avant de lancer
mysqld. Ce script est utilisé sur les
systèmes Unix BSD. Il est aussi appelé par
mysql.server. See
Section 5.1.3, « safe_mysqld, le script père de
mysqld ».
En appelant mysql.server. Ce script
sert principalement au moment du démarrage et de
l'extinction du système, sur les systèmes qui utilisent
un dossier de processus programmés System V, où il est
généralement enregistré sous le nom de
mysql. Le
scriptmysql.server lance le serveur en
appelant mysqld_safe. See
Section 5.1.4, « Le script de démarrage mysql.server ».
Sur Mac OS X, vous pouvez installer un paquet indépendant
appelé MySQL Startup Item pour activer
le lancement automatique de MySQL au démarrage. Le
Startup Item lance le serveur en
appelant mysql.server. Voir
Section 2.2.13, « Installer MySQL sur Mac OS X » pour plus de
détails.
Les scripts mysql.server et
safe_mysqld et le StartUp
Item de Mac OS X peuvent être
utilisés pour démarrer le serveur automatiquement au moment
du démarrage du serveur. mysql.server peut
aussi servir à arrêter le serveur.
Le script mysql.server peut servir à
démarrer ou arrêter le serveur en l'appelant avec les
arguments start ou
stop :
shell>mysql.server startshell>mysql.server stop
Avant que mysql.server ne démarre le
serveur, il change de dossier pour aller dans le dossier
d'installation et appelle safe_mysqld. Si
vous voulez que le serveur fonctionne sous un nom
d'utilisateur spécifique, ajoutez l'option
user appropriée dans le groupe
[mysqld] du fichier
/etc/my.cnf, tel que présenté
ultérieurement dans cette section (il est possible que vous
ayez besoin d'éditer mysql.server). Vous
pourriez avoir à éditer mysql.server si
vous avez une installation binaire dans une situation non
standard. Modifiez la commande cd avec le
dossier correct, avant qu'il n'exécute
safe_mysqld. Si vous voulez que le serveur
fonctionne avec un utilisateur spécifique, ajouter l'option
user appropriée dans le fichier
/etc/my.cnf, tel que présenté
ultérieurement dans cette section.
mysql.server stop arrête le serveur en lui
envoyant un signal. Vous pouvez éteindre le serveur
manuellement avec la commande mysqladmin
shutdown.
Pour lancer et arrêter automatiquement MYSQL sur votre
serveur, vous devez ajouter les commandes de lancement et
d'arrêt dans les bons endroits de vos fichiers
/etc/rc*.
Notez que si vous utilisez des paquets Linux
RPM
(MySQL-server-VERSION.rpm), le script
mysql.server est installé sous le nom
/etc/init.d/mysql. Vous n'avez pas à
l'installer manuellement. Voyez Section 2.2.12, « Installer MySQL sous Linux »
pour plus d'informations sur les paquets Linux
RPM.
Certaines éditeurs fournissent des paquets
RPM qui installent un script de démarrage
sous un autre nom, comme mysqld.
Si vous installez MySQL depuis une distribution source, ou en
utilisant une distribution binaire qui n'installe pas
automatiquement le script mysql.server,
vous pouvez l'installer manuellement. Le script est disponible
dans le dossier support-files du dossier
d'installation MySQL, ou dans le dossier source de MySQL.
Pour installer mysql.server manuellement,
copiez le dans le dossier /etc/init.d
sous le nom mysql, puis rendez-le
exécutable. Pour cela, placez vous dans le dossier où
mysql.server est stocké, et utilisez ces
commandes :
shell>cp mysql.server /etc/init.d/mysqlshell>chmod +x /etc/init.d/mysql
Les anciens systèmes Red Hat utilisent le dossier
/etc/rc.d/init.d plutôt que
/etc/init.d. Adaptez les commandes
précédentes. Alternativement, créez un lien symbolique
/etc/init.d qui pointe sur
/etc/rc.d/init.d :
shell>cd /etcshell>ln -s rc.d/init.d .
Après installation du script, les commandes doivent être
activées pour fonctionner au lancement du système, sur votre
système d'exploitation. Sous Linux, vous pouvez utiliser
chkconfig :
shell> chkconfig --add mysql
Sur certains systèmes Linux, les commandes suivantes sont
aussi nécessaires pour activer totalement le script
mysql :
shell> chkconfig --level 345 mysql on
Sous FreeBSD, les scripts de démarrage vont généralement
dans le dossier /usr/local/etc/rc.d/. La
page de manuel rc(8) indique que les
scripts de ce dossier ne sont exécutés que si leur nom est
de la forme *.sh. Tout autre fichier de ce
dossier sera alors ignoré. En d'autres termes, vous devez
installer le script mysql.server sous le
nom /usr/local/etc/rc.d/mysql.server.sh
pour activer le démarrage automatique.
Alternativement à la configuration précédente, certains
systèmes d'exploitation utilisent aussi
/etc/rc.local ou
/etc/init.d/boot.local pour lancer des
services supplémentaires au démarrage. Pour lancer MySQL
avec cette méthode, vous pouvez ajouter une commande comme
celle-ci au fichier de démarrage :
/bin/sh -c 'cd /usr/local/mysql; ./bin/mysqld_safe --user=mysql &'
Pour les autres systèmes, consultez la documentation de votre système d'exploitation pour savoir comment installer un script de démarrage.
Vous pouvez aussi ajouter des options à
mysql.server via le fichier global
/etc/my.cnf file. Un fichier
/etc/my.cnf typique peut ressembler à
ceci :
[mysqld] datadir=/usr/local/mysql/var socket=/var/tmp/mysql.sock port=3306 user=mysql [mysql.server] basedir=/usr/local/mysql
Le script mysql.server comprend les options
suivantes : basedir,
datadir et pid-file. Si
spécifiées, elles doivent être
placées dans un fichier d'option, et non pas en ligne de
commande. mysql.server comprend les options
de ligne de commande start et
stop.
La table suivante montre quels groupes d'options chaque scripts de démarrage utilise :
| Script | Groupe d'options |
mysqld | mysqld et server |
mysql.server | mysql.server, mysqld, et
server |
safe_mysqld | mysql.server, mysqld, et
server |
[mysqld-major-version] signifie que des
groupes ayant des noms tels que
[mysqld-4.0],
[mysqld-4.1], et
[mysqld-5.0] seront lus par les serveurs de
versions 4.0.x, 4.1.x, 5.0.x, etc. Cette fonctionnalité a
été ajoutée en MySQL 4.0.14. Elle sert à spécifier des
options qui ne seront lues que par des serveurs dont les
versions sauront les comprendre.
A des fins de compatibilité ascendante,
mysql.server lit aussi le groupe d'options
[mysql_server] et
mysqld_safe lit le groupe d'options
[safe_mysqld]. Cependant, il est
recommandé de modifier vos fichiers de configuration pour
utiliser les groupes [mysql.server] et
[mysqld_safe] à la place.
Si vous avez des problèmes pour lancer le serveur, voici quelques pistes que vous pouvez essayer :
Spécifiez toutes les options spéciales nécessaires aux moteurs de tables que vous utilisez.
Assurez vous que le serveur sait où trouver le dossier de données.
Assurez vous que le serveur peut utiliser le dossier de données. Le propriétaire et les droits du dossier de données et son contenu doivent être accessibles au serveur, en lecture et écriture.
Vérifiez le log d'erreurs pour voir pourquoi le serveur ne démarre pas.
Vérifiez que les interfaces réseau sont accessibles au serveur.
Certains moteurs de stockage ont des options qui contrôlent
leur comportement. Vous devrez créer un fichier d'options
my.cnf et y configurer celles des moteurs
que vous voulez utiliser. Si vous allez utiliser des tables
qui supportent les transactions (InnoDB,
BDB), assurez vous qu'elles sont bien
configurées comme vous le souhaitez.
Si vous utilisez les tables InnoDB,
voyez les options de démarrages spécifiques à
InnoDB. En MySQL version 3.23, vous
devez configurer InnoDB explicitement
ou le serveur ne pourra pas démarrer. Depuis MySQL 4.0,
InnoDB utiliser des valeurs par défaut
pour sa configuration, si vous n'en spécifiez pas. See
Section 15.4, « Configuration InnoDB ».
Si vous utilisez les tables BDB
(Berkeley DB), vous devez vous familiariser avec les
différentes options spécifiques à
BDB. See Section 14.4.3, « Options de démarrage BDB ».
Lorsque le démon mysqld démarre, il
change le dossier de travail par le dossier de données. C'est
là qu'il doit trouver les fichiers de log, et le fichier pid
(ID de processus), ainsi que les dossiers de bases.
Le chemin du dossier de données est codé en dur lorsque la
distribution est compilée. Cependant, si
mysqld cherche le dossier de données
ailleurs que là où il est vraiment, il ne va pas fonctionner
correctement. Vous pouvez lire les chemins par défaut en
invoquant mysqld avec l'option
--verbose ou --help. Avant
MySQL 4.1, omettez --verbose.
Si les valeurs par défaut ne correspondent pas à votre
installation MySQL, vous pouvez les modifier en spécifiant
des options de ligne de commande pour
mysqld et mysqld_safe.
Vous pouvez aussi lister les options dans un fichier
d'options.
Pour spécifier la localisation du dossier de données
explicitement, utilisez l'option --datadir.
Cependant, vous pouvez spécifier à mysqld
le chemin du dossier de base sous lequel MySQL est installé,
et il va rechercher le dossier de données là. Vous pouvez
faire cela avec l'option --basedir.
Pour vérifier l'effet de ces options, appelez
mysqld avec ces options, suivies de
--verbose et --help. Par
exemple, si vous modifiez le chemin pour celui dans lequel
mysqld est installé, alors vous pouvez
utiliser la commande suivante, et vous verrez l'effet sur le
démarrage du serveur avec une installation de base
/usr/local :
shell> ./mysqld --basedir=/usr/local --verbose --help
Vous pouvez spécifier d'autres options comme
--datadir, mais notez que
--verbose et --help doivent
être les dernières options. Avant MySQL 4.1, omettez
l'option --verbose.
Une fois que vous déterminez les configurations que vous
voulez, lancez le serveur avec --verbose et
--help.
Si votre démon mysqld fonctionne déjà,
vous pouvez connaître les chemins de configuration avec la
commande :
shell> mysqladmin variables
ou :
shell> mysqladmin -h host_name variables
host_name est le nom de l'hôte MySQL.
Si vous avez une erreur Errcode 13 (ce qui
signifie Permission denied) lorsque vous
démarrez mysqld, cela signifie que les
droits d'accès au serveur ou son contenu ne sont pas bons.
Dans ce cas, vous devez modifier les droits sur les dossiers
et fichiers que le serveur va utiliser. Vous pouvez aussi
lancer le serveur en tant que root, mais
cela pose des problèmes de sécurité, et il vaut mieux
l'éviter.
Sous Unix, vérifiez l'existence du dossier de données et
vérifiez le nom du propriétaire du dossier de données et de
son contenu. Par exemple, si le dossier est
/usr/local/mysql/var, utilisez cette
commande :
shell> ls -la /usr/local/mysql/var
Si le dossier, ses sous-dossiers ou ses fichiers ne sont pas au nom du compte qui fait tourner le serveur, changez le propriétaire avec cette commande :
shell>chown -R mysql /usr/local/mysql/varshell>chgrp -R mysql /usr/local/mysql/var
Quelque soit la méthode que vous utilisez pour démarrer le
serveur, si elle échoue, vérifiez le fichier de log
d'erreurs pour savoir pourquoi. Les fichiers de log sont
situés dans le dossier de données (typiquement
/usr/local/mysql/data pour une
distribution binaire, /usr/local/var pour
une distribution source, et
\mysql\data\mysql.err sous Windows).
Regardez dans le dossier de données et recherchez des
fichiers de la forme host_name.err et
host_name.log ou
host_name est le nom de votre serveur.
Vérifiez alors les dernières lignes de ce fichier :
shell>tail host_name.errshell>tail host_name.log
Recherchez des lignes comme celles-ci :
000729 14:50:10 bdb: Recovery function for LSN 1 27595 failed 000729 14:50:10 bdb: warning: ./test/t1.db: No such file or directory 000729 14:50:10 Can't init databases
Cela signifie que vous n'avez pas démarré
mysqld avec
--bdb-no-recover et Berkeley DB a trouvé une
erreur dans les fichiers de log lorsqu'il a essayé de
restaurer votre base. Pour pouvoir continuer, vous devez
déplacer le vieux fichier de log Berkeley DB vers un autre
dossier, pour l'examiner plus tard. Les fichiers de logs sont
nommés log.0000000001, et ce nombre
augmente au fil du temps.
Si vous exécutez mysqld avec les tables
BDB et que mysqld fait
des core dumps au démarrage, c'est peut être que vous avez
des problèmes avec le fichier de restauration de
BDB. Dans ce cas, essayez de démarrer
mysqld avec
--bdb-no-recover. Si cela aide, vous devriez
alors retirer tous les fichiers de log
log.* du dossier de données, et
démarrer mysqld à nouveau.
Si vous obtenez l'erreur suivant, cela signifie que d'autres
programmes (ou un autre serveur mysqld)
fonctionne déjà avec le port TCP/IP ou la socket que
mysqld essaie d'utiliser :
Can't start server: Bind on TCP/IP port: Address already in use Can't start server : Bind on unix socket...
Utilisez ps pour vous assurer que vous
n'avez pas d'autre serveur mysqld qui
fonctionne. Si c'est le cas, éteignez le serveur avant de
lancer mysqld à nouveau. Si un autre
serveur fonctionne, et que vous voulez vraiment en avoir
plusieurs, voyez la section
Section 5.10, « Faire fonctionner plusieurs serveurs MySQL sur la même machine ».)
Si vous ne pouvez pas trouver d'autre serveur en
fonctionnement, essayer d'exécuter la commande
telnet votre-nom-d-hote numero-de-port-tcp
puis pressez la touche 'Entrée' plusieurs fois. Si vous
n'obtenez pas de message d'erreur comme telnet:
Unable to connect to remote host: Connection
refused, alors un autre processus utilise le port
TCP/IP de mysqld. Vous devrez alors
rechercher le programme qui utilise ce port, et le
désactiver, ou bien dire à mysqld
d'écouter sur un autre port avec l'option
--port. Dans ce cas, vous devrez aussi
spécifier le numéro de port à tous les clients qui se
connecte au serveur via TCP/IP.
Une autre raison d'inaccessibilité du port est que vous avez un coupe-feu qui fonctionne, et qui bloque ces port. Pour cela, modifiez la configuration du coupe-feu pour libérer l'accès au port.
Si safe_mysqld démarre le serveur, mais
que vous n'arrivez pas à vous y connecter, vous devriez vous
assurer que vous avez une entrée dans le fichier
/etc/hosts qui ressemble à ceci@ :
127.0.0.1 localhost
Ce problème survient uniquement sur les systèmes qui n'ont
pas une bibliothèque de threads fonctionnels, ou pour
lesquels MySQL a été configuré pour utiliser les
MIT-pthreads.
Si vous n'arrivez toujours pas à lancer
mysqld, vous pouvez essayer de générer un
fichier de traces avec l'option --debug. See
Section D.1.2, « Créer un fichier de tra¸age ».
Le processus d'installation de MySQL passe par la création de
la base de données mysql, qui contient les
tables de droits :
La distribution Windows contient des tables de droits pre-initialisées automatiquement.
Sous Unix, les tables de droits sont remplies par le
programme mysql_install_db. Certains
assistants d'installation le font pour vous. Les autres vous
imposent de le faire manuellement. Pour plus de détails,
voyez Section 2.5.2, « Procédures de post-installation sous Unix ».
Le script mysql_install_db démarre le
serveur mysqld et initialise les tables de
droits, avec les paramètres suivants :
Deux comptes MySQL root sont créés en
tant qu'administrateurs ayant tous les droits. Le mot de
passe de l'utilisateur initial root est
vide, ce qui permet à n'importe qui de se connecter en tant
que root sans mot de
passe, pour profiter de tous les droits.
Sous Windows, un compte root permet
de se connecter depuis l'hôte local, et l'autre depuis
n'importe quel hôte.
Sous Unix, les deux comptes root sont
destinés à être utilisés depuis le compte local. Les
connexions doivent être faîtes en spécifiant le nom
d'hôte localhost, ou le véritable
nom d'hôte, ou l'adresse IP.
Deux comptes utilisateur anonyme sont créés, qui peuvent
faire ce qu'ils veulent avec toutes les tables dans la base
de données 'test' ou commen¸ant par
'test_'. Cela signifie qu'un utilisateur
peut se connecter sans mot de passe et être traité comme
un utilisateur anonyme.
Sous Windows, un compte anonyme sert depuis l'hôte
local. Ce compte a tous les droits, comme
root. L'autre sert aux connexions
depuis les hôtes, et a tous les droits pour les bases
test ou commen¸ant par
test.
Sous Unix, les deux comptes anonymes servent depuis
l'hôte local. Les connexions doivent être faîtes en
spécificant le nom d'hôte
localhost, ou le véritable nom
d'hôte, ou l'adresse IP. Ces comptes ont tous les
droits dans les bases test ou dont le
nom commence par test_.
Comme indiqué, aucun des comptes initiaux n'a de mot de passe. Cela signifie que votre installation MySQL n'est pas protégée jusqu'à ce que vous y remédiez :
Si vous voulez éviter que les clients ne se connectent en tant qu'utilisateur anonyme sans mot de passe, vous devez assigner des mots de passe à ces comptes, ou bien les supprimer.
Vous devez assigner des mots de passe aux comptes
root.
Les instructions suivantes décrivent comment configurer les
mots de passe pour les comptes initiaux, en commen¸ant par les
comptes anonymes, puis pour les comptes root.
Remplacez ``nouveau_mot'' dans les exemples
ci-dessous par le nouveau mot de passe que vous voulez utiliser.
Ces instructions montrent aussi comment supprimer les comptes
anonymes.
Vous pouvez différer le changement de mot de passe jusqu'à plus tard, pour pouvoir utiliser cette configuration pour les tests. Cependant, n'oubliez pas de le faire avant de mettre votre serveur en production.
Pour assigner des mots de passe aux comptes anonymes, vous
pouvez utiliser les commandes SET PASSWORD et
UPDATE. Dans les deux cas, assurez-vous de
chiffrer les mots avec la fonction
PASSWORD().
Pour utiliser SET PASSWORD sur Windows,
faîtes :
shell>mysql -u rootmysql>SET PASSWORD FOR ''@'localhost' = PASSWORD('nouveau_mot');mysql>SET PASSWORD FOR ''@'%' = PASSWORD('nouveau_mot');
Pour utiliser SET PASSWORD sur Unix,
faîtes :
shell>mysql -u rootmysql>SET PASSWORD FOR ''@'localhost' = PASSWORD('nouveau_mot');mysql>SET PASSWORD FOR ''@'host_name' = PASSWORD('nouveau_mot');
Dans la seconde commande SET PASSWORD,
remplacez host_name par le nom de l'hôte du
serveur. C'est le nom qui sera spécifié dans la colonne
Host de la ligne du compte
root, et qui n'est pas
localhost. Si vous ne savez pas quel nom
d'hôte c'est, utilisez cette commande avant d'utiliser
SET PASSWORD :
mysql> SELECT Host, User FROM mysql.user;
Recherchez une ligne qui contient root dans
la colonne User et quelque chose d'autre que
localhost dans la colonne
Host. Puis, utilisez la valeur de
Host dans la seconde commande SET
PASSWORD.
L'autre moyen d'assigner des mots de passe à un compte anonyme
est d'utiliser la commande UPDATE pour
modifier la table user directement. Connectez
vous en tant que root et envoyez une commande
UPDATE qui assigne une valeur à la colonne
Password dans les lignes appropriée de la
table user. La procédure est la même sous
Unix et sous Windows. La commande suivante
UPDATE met à jour le mot de passe pour les
deux comptes en même temps :
shell>mysql -u rootmysql>UPDATE mysql.user SET Password = PASSWORD('nouveau_mot')->WHERE User = '';mysql>FLUSH PRIVILEGES;
Après voir fait la mise à jour des mots de passe dans la table
user avec la commande
UPDATE, vous devez demander au serveur de
relire les tables de droits, avec FLUSH
PRIVILEGES. Sinon, les modifications ne seront pas
prises en compte avant le prochain redémarrage du serveur.
Si vous préférez supprimer les comptes anonymes, faîtes ceci :
shell>mysql -u rootmysql>DELETE FROM mysql.user WHERE User = '';mysql>FLUSH PRIVILEGES;
La commande DELETE s'applique à Windows et
Unix. Sous Windows, si vous voulez supprimer uniquement les
comptes anonymes qui ont les mêmes droits que
root, faîtes ceci :
shell>mysql -u rootmysql>DELETE FROM mysql.user WHERE Host='localhost' AND User='';mysql>FLUSH PRIVILEGES;
Ce compte permet un accès anonyme avec les pleins droits : le supprimer améliore la sécurité.
Vous pouvez assigner les mots de passe au compte
root de nombreuses fa¸ons. La discussion
suivante montre trois méthodes :
Utiliser la commande SET PASSWORD
Utiliser la commande en ligne mysqladmin
Utiliser la commande UPDATE
Pour assigner un mot de passe avec la commande SET
PASSWORD, connectez vous en tant que
root et faites deux commandes SET
PASSWORD. Assurez vous de chiffrer le mot de passe
avec PASSWORD().
Pour Windows, faîtes ceci :
shell>mysql -u rootmysql>SET PASSWORD FOR 'root'@'localhost' = PASSWORD('nouveau_mot');mysql>SET PASSWORD FOR 'root'@'%' = PASSWORD('nouveau_mot');
Pour Unix, faîtes ceci :
shell>mysql -u rootmysql>SET PASSWORD FOR 'root'@'localhost' = PASSWORD('nouveau_mot');mysql>SET PASSWORD FOR 'root'@'host_name' = PASSWORD('nouveau_mot');
Dans la seconde commande SET PASSWORD,
remplacez host_name par le nom de l'hôte du
serveur. C'est le même nom que celui qui a été utilisé pour
les comptes anonymes.
Pour assigner un mot de passe à root en
utilisant mysqladmin, exécutez les commandes
suivantes :
shell>mysqladmin -u root password "nouveau_mot"shell>mysqladmin -u root -h host_name password "nouveau_mot"
Ces commandes s'appliquent à Windows et à Unix. Dans la
seconde commande, remplacez host_name par le
nom du serveur hôte. Les guillemets doubles autour du mot de
passe ne sont pas nécessaires, mais vous devez les utiliser si
vous avez des espaces ou d'autres caractères spéciaux.
Si vous utilisez un serveur d'une très
vieille version de MySQL, la commande
mysqladmin va échouer avec un message
d'erreur : parse error near 'SET password'.
La solution à ce problème est de changer la version du serveur
MySQL.
Vous pouvez aussi utiliser UPDATE pour
modifier directement la table user. La
commande UPDATE suivante assigne un mot de
passe aux comptes root en même temps :
shell>mysql -u rootmysql>UPDATE mysql.user SET Password = PASSWORD('nouveau_mot')->WHERE User = 'root';mysql>FLUSH PRIVILEGES;
La commande UPDATE s'applique à Windows et
à Unix.
Après modification des mots de passe, vous devrez les fournir
à chaque connexion au serveur. Par exemple, si vous voulez
utiliser la commande mysqladmin pour
éteindre le serveur, vous devez utiliser une commande de cette
forme :
shell> mysqladmin -u root -p shutdown
Enter password: (enter root password here)
Note : si vous perdez votre
mot de passe root après l'avoir configuré,
la procédure pour le remettre à zéro est présentée dans la
section Section A.4.1, « Comment réinitialiser un mot de passe Root oublié ».
Pour créer de nouveaux comptes, utilisez la commande
GRANT. Pour les instructions, voyez
Section 5.6.2, « Ajouter de nouveaux utilisateurs à MySQL ».
Vous pouvez toujours les fichiers de structures et de données
entre les différentes versions de MySQL. La version de base
actuelle est la version 3. Si vous changez le jeu de caractères
lors de l'utilisation de MySQL (ce qui va aussi affecter le tri),
vous devez exécuter la commande myisamchk -r -q
--set-character-set=charset sur toutes les tables.
Sinon, vos index ne seront pas correctement triés.
Les instructions suivantes sont un pense-bête de tout ce à quoi vous devez penser lors d'une mise à jour :
Lisez la section de mise à jour pour la version que vous voulez utiliser, afin de voir les nouvelles fonctionnalités que vous pourrez utiliser. Par exemple, en passant de MySQL 4.1 en 5.0, lisez l'historique de la version 5.0. See Annexe C, Historique des changements MySQL.
Avant de faire une mise à jour, faîtes une sauvegarde de vos données.
Si vous utilisez MySQL Server sur Windows,
voyez Section 2.2.11, « Mettre à jour MySQL sous Windows ».
Une mise à jour peut impliquer la modification des tables de
droits, dans la base mysql. Certaines
colonnes ou tables peuvent être ajoutées pour supporter de
nouvelles fonctionnalités. Pour tirer partie de ces
fonctionnalités, assurez vous de mettre à jour vos tables.
La procédure de migration est présentée dans
Section 2.6.7, « Mise à jour des tables de droits ».
Si vous utilisez la réplication, voyez la Section 6.6, « Changer de version de réplication » pour savoir comment mettre à jour votre architecture de réplication.
Si vous installez une distribution
MySQL-Max qui inclut le serveur
mysqld-max, puis que vous passez à une
version non-Max de MySQL, mysqld_safe va
tenter d'utiliser l'ancien serveur
mysqld-max. Si vous faites une telle mise
à jour, vous devez supprimer manuellement l'ancien serveur
mysqld-max pour vous assurer que
mysqld_safe utilise le nouveau
mysqld.
Si vous avez peur des nouvelles versions, vous pouvez toujours
renommer votre vieux mysqld avec un nom comme
mysqld-ancienne_version. Si votre nouveau
serveur mysqld se comportement bizarrement,
vous pourrez toujours l'éteindre, et redémarrer avec votre vieux
mysqld!
Lorsque vous faites une évolution de version, vous devriez toujours faire une sauvegarde de vos anciennes données.
Si après un changement de version, vous rencontrez des problèmes
avec les clients recompilés, comme Commands out of
sync ou des core dumps inopinés, vous avez probablement
utiliser un vieux fichier d'entête ou une vieille bibliothèque
lors de la compilation de vos programmes. Dans ce cas, vérifiez
la date de votre fichier mysql.h, et de votre
bibliothèque libmysqlclient.a, pour vous
assurer qu'ils proviennent bien de la nouvelle distribution MySQL.
Si ce n'est pas le cas, recompilez vos programmes!
Si vous avez des problèmes tels que le nouveau serveur
mysqld ne peut plus démarrer, ou que vous ne
pouvez pas vous connecter sans un mot de passe, vérifiez que vous
n'avez pas un vieux fichier my.cnf dans votre
installation! Vous pouvez le vérifier comme ceci :
program-name --print-defaults. Si cette
commande affiche autre chose que le nom du programme, vous avez un
fichier my.cnf actif, qui perturbe vos
opérations.
C'est une bonne idée que de reconstruire et re-installer le
module Msql-Mysql à chaque fois que vous
faites une nouvelle version de MySQL, en particulier si vous
rencontrez des symptômes tels que les DBI qui
font des core dump après votre mise à jour de MySQL.
En général, il faut suivre ces instructions pour passer en version 5.0, depuis la version 4.1 :
Lisez la présentation de la version 5.0, pour savoir quelles évolutions et quelles nouveautés vous pourrez utiliser. See Section C.1, « Changements de la version 5.0.0 (Développement) ».
Si vous utilisez MySQL Server sur
Windows, voyez la section
Section 2.2.11, « Mettre à jour MySQL sous Windows ».
MySQL 5.0 apporte les procédures stockées. Ce support
requiert la table de droits proc dans la
base mysql. Après la mise à jour du
serveur, mettez aussi à jour les tables de droits pour vous
assurer que la table proc existe. La
procédure utilise le script
mysql_fix_privilege_tables et est
décrite dans la section
Section 2.6.7, « Mise à jour des tables de droits ».
Si vous utilisez la réplication, voyez aussi la section Section 6.6, « Changer de version de réplication », pour la mise à jour de votre architecture.
En général, vous devez suivre les instructions suivantes pour passer de MySQL 4.0 à 4.1 :
Vérifiez la liste des modifications de cette section, vous voir si elles ont un impact sur vos applications.
Lisez la liste des nouveautés de la version 4.1 pour identifier les nouvelles fonctionnalités significatives pour vos projets. See Section C.2, « Changements de la version 4.1.x (Alpha) ».
Si vous faites fonctionner MySQL sur Windows, voyez Section 2.2.11, « Mettre à jour MySQL sous Windows ».
Après mise à jour du serveur, mettez à jour les tables de
droits, pour accepter des colonnes
Password plus grande. La procédure
utilise le script
mysql_fix_privilege_tables et est
décrite dans la section
Section 2.6.7, « Mise à jour des tables de droits ». Les implications
du changement de gestion du mot de passe est décrit plus
loin dans cette section. Si vous ne le faîtes pas, MySQL ne
pourra pas utiliser le protocole sécuritaire pour
l'identification.
Si vous utilisez la réplication, voyez la section Section 6.6, « Changer de version de réplication » pour mettre à jour votre installation.
Le moteur de table Berkeley DB table est passé en version
DB 4.1 (depuis la 3.2), et il dispose d'un nouveau format de
log. Si vous devez revenir en version 4.0, vous devrez
utiliser mysqldump pour exporter vos
tables BDB au format texte, et effacer
tout les fichiers log.XXXXXXXXXX avant de
redémarrer le serveur MySQL 4.0 et de réimporter les
données.
Le support des jeux de caractères a été amélioré. si vous avez des tables qui contiennent des données représentées dans un jeu de caractères que MySQL 4.1 supporte directement, vous pouvez convertir ces colonnes vers le bon jeu de caractères avec les instructions du chapitre Section 10.10.2, « Conversion de colonnes version 4.0 en version 4.1 ».
Si vous utilisez un vieux module
DBD-mysql
(Msql-MySQL-modules) vous devez mettre à
jour le module DBD-mysql. Tout ce qui est
plus récent que DBD-mysql 2.xx doit
convenir.
Si vous ne mettez pas à jour, certaines commandes telles
que DBI->do() ne rapporteront pas
correctement les erreurs.
L'option --defaults-file=option-file-name
vous donnera une erreur si le fichier d'options n'existe
pas.
Plusieurs comportements visibles ont changé entre MySQL 4.0 et MySQL 4.1 pour corriger des bogues critiques et rendre MySQL plus compatible avec le standard SQL. Ces changements peuvent affecter votre application.
Certains des comportement 4.1 peuvent être testés en version
4.0 avant de passer à la 4.1. Nous avons ajouté l'option
--new de démarrage de
mysqld pour les versions supérieure à la
4.0.12. See Section 5.2.1, « Options de ligne de commande de mysqld ».
Cette option vous donne le comportement de la version 4.1 pour
les modifications les plus critiques. Vous pouvez aussi activer
ces comportements pour une connexion particulière en utilisant
la commande SET @@new=1, pour désactiver
cette option avec SET @@new=0.
Si vous pensez que certains des changements de la version 4.1
vous affecteront, nous vous recommandons, avant de passer en
version 4.1, de télécharger la dernière version 4.0, et de
l'exécuter avec l'option --new en plus de vos
configuration habituelles :
[mysqld-4.0] new
De cette manière, vous pouvez tester le comportement de la
version 4.1 depuis votre serveur 4.0. Cela vous donnera le temps
de supprimer les anomalies, et de passer sans problème à la
version 4.1, ultérieurement. En faisant cela, vous n'allez pas
rencontrer de bug accidentel lors du changement, que vous
n'aurez pas corrigé grâce à --new.
Voici une liste complète, vous indiquant ce à quoi vous devez faire attention lors du changement de version :
Modification du serveur :
Toutes les colonnes et tables ont désormais un jeu de
caractères, qui apparaît dans le résultat de la commande
SHOW CREATE TABLE et
mysqldump. See Chapitre 10, Jeux de caractères et Unicode.
(MySQL 4.0.6 et plus récent peuvent lire les nouveaux
fichiers de dump, mais pas les plus anciennes versions de
MySQL). Cela ne doit pas affecter les applications qui
n'utilisent qu'un seul jeu de caractères.
Le format de définition de table du fichier
.frm a légèrement changé en version
4.1. Les versions de MySQL 4.0 à partir de la 4.0.11
peuvent lire le nouveau format .frm
directement, mais les versions plus anciennes ne le peuvent
pas. Si vous devez déplacer des tables de la version 4.1
vers une version 4.0.11, passez plutôt par
mysqldump. See
Section 8.8, « mysqldump, sauvegarde des structures de tables et les
données ».
Note importante : si vous
mettez à jour en version InnoDB-4.1.1 ou
plus récent, il sera difficile de revenir à une version
plus ancienne, 4.0 or 4.1.0! Ceci est dû aux versions de
InnoDB qui ne reconnaissent pas les
espaces de table multiples.
Si vous utilisez plusieurs serveurs sur la même machine
Windows, vous devriez utiliser l'option
--shared_memory_base_name avec des valeurs
différentes sur toutes les machines.
L'interface des fonctions UDF
agrégeantes a un peu changé. Vous devez commencer par
déclarer une fonction xxx_clear() pour
chaque fonction agrégeante XXX().
Evolution du client :
mysqldump dispose des options
--opt et --quote-names,
qui sont activées par défaut. Vous pouvez les désactiver
avec --skip-opt et
--skip-quote-names.
Evolution du SQL :
La comparaison de chaînes fonctionne maintenant
conformément au standard SQL : au lieu de supprimer les
espaces de fin de chaîne avant la comparaison, nous
complétons les chaînes courte avec des espaces. Le
problème est que maintenant, 'a' >
'a\t', ce qui n'était pas le cas avant. Si vous
avez des tables avec des colonnes CHAR ou
VARCHAR dont le dernier caractères peut
être de code ASCII(32) ou plus petit,
vous devez utiliser la commande REPAIR
TABLE ou myisamchk.
Lorsque vous utilisez des commandes
DELETE multi-tables, vous devez utiliser
les alias de tables que vous voulez effacer, et non pas le
véritable nom de la table. Par exemple, au lieu de :
DELETE test FROM test AS t1, test2 WHERE ...
faîtes :
DELETE t1 FROM test AS t1, test2 WHERE ...
TIMESTAMP est maintenant retourné comme
une chaîne, au format 'YYYY-MM-DD
HH:MM:SS'. L'option --new peut
être utilisée depuis la version 4.0.12, pour que le
serveur adopte le comportement de la version 4.1 pour ce
point. Si vous voulez recevoir la version entière de la
valeur, comme en version 4.0, il suffit d'ajouter +0 à
chaque colonne TIMESTAMP :
mysql> SELECT ts_col + 0 FROM tbl_name;
La largeur d'affichage des colonnes
TIMESTAMP ne sont plus supportées. Par
exemple, si vous déclarez une colonne de type
TIMESTAMP(10), le nombre
(10) est ignoré.
Ces changements sont nécessaires pour respecter les
standards SQL. Dans une future version, une autre
modification aura lieu, mais restera compatible avec
celle-ci : la taille de la valeur
TIMESTAMP indiquera le nombre de chiffres
voulu pour les fractions de secondes.
Les valeurs binaires, comme 0xFFDF, sont
maintenant supposées être des chaînes et non pas des
nombres. Cela corrige des problèmes avec les jeux de
caractères, où il est plus pratique d'insérer une chaîne
comme une chaîne binaire. Avec cette modification, vous
devez utiliser la fonction CAST() si vous
voulez comparer des valeurs binaires avec les entiers :
mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER);
-> 0
Si vous n'utilisez pas CAST(), une
comparaison lexicale de la chaîne aura lieu :
mysql> SELECT 0xFEFF < 0xFF;
-> 1
Utiliser des chaînes binaires dans un contexte numérique,
ou bien comparer des valeurs avec les opérateurs comme
= devrait fonctionner comme auparavant.
L'option --new peut être utilisée à
partir de la version 4.0.13 pour que le serveur 4.0 se
comporte comme le serveur 4.1.
Les fonctions qui retournent des DATE,
DATETIME, ou TIME sont
désormais traitées lors de leur arrivée sur le client.
Par exemple, en MySQL 4.1, vous obtenez le résultat
suivant :
mysql>SELECT CAST("2001-1-1" as DATETIME);->'2001-01-01 00:00:00'
En MySQL 4.0, le résultat est différent :
mysql>SELECT CAST("2001-1-1" as DATETIME);->'2001-01-01'
Les valeurs DEFAULT ne peuvent plus être
spécifiées pour les colonnes de type
AUTO_INCREMENT. En 4.0, la clause
DEFAULT est ignorée silencieusement. En
4.1, une erreur survient.
LIMIT n'accepte plus les arguments
négatifs. Utilisez 18446744073709551615 au lieu de -1.
SERIALIZE n'est plus une option valide
pour la variable sql_mode. Il faut
utiliser la commande SET TRANSACTION ISOLATION
LEVEL SERIALIZABLE à la place.
SERIALIZE n'est plus valide comme option
de --sql-mode pour
mysqld, non plus. Utilisez
--transaction-isolation=SERIALIZABLE.
Changement de l'interface C :
Certaines fonctions C telles que
mysql_real_query() retournent maintenant
1 en cas d'erreur, et non plus
-1. Vous aurez peut être à changer
certaines anciennes applications comme ceci :
if (mysql_real_query(mysql_object, query, query_length) == -1)
{
printf("Erreur");
}
Modifiez le test de comparaison à 0 :
if (mysql_real_query(mysql_object, query, query_length) != 0)
{
printf("Erreur");
}
Gestion des mots de passe :
Le mécanisme de mot de passe a changé en version 4.1 pour assurer une meilleure sécurité, mais cela pose des problèmes de compatibilité, si vous avez encore des clients qui utilisent les bibliothèques 4.0 ou plus ancien. Il est probable que vous ayez de tels clients, s'ils se connectent depuis des serveurs distants qui n'ont pas encore adopté la version 4.0. La liste suivante présente les stratégies de mise à jour. Elle représentent différents compromis entre la compatibilité et la sécurité.
Ne passez pas en version 4.1. Aucun comportement ne changera, mais vous ne pourrez pas utiliser les nouvelles fonctionnalités du protocole de la version 4.1. MySQL a amélioré le protocole client/serveur de la version 4.1, en ajoutant les commandes préparées et le support des jeux de caractères. See Section 24.2.4, « Fonctions C de commandes préparées ».
Passez en version 4.1, utilisez le script
mysql_fix_privilege_tables pour agrandir
la colonne Password de la table
user pour qu'elle puisse contenir les
nouveaux hashs de mots de passe. Mais lancez le serveur avec
l'option --old-passwords pour que les
clients pre-4.1 puissent continuer d'utiliser leurs anciens
comptes. Finalement, lorsque tous les clients seront passés
en version 4.1, vous pourrez cesser d'utiliser l'option
--old-passwords. Vous pouvez aussi changer
les mots de passe de vos comptes MySQL pour adopter le
nouveau format.
Passez en version 4.1 et utilisez le script
mysql_fix_privilege_tables pour aggrandir
la colonne Password de la table
user. Si vous savez que tous les clients
sont passés en version 4.1, n'utilisez pas l'option
--old-passwords. Au lieu de cela, changez
les mots de passe de tous les comptes, pour qu'ils adoptent
le nouveau format. Une installation 100% 4.1 est la plus
sûre.
D'autres informations sur le nouvel algorithme de protection des
mots de passe et les opérations les concernants sont
disponibles dans la section Section 5.5.9, « Hashage de mots de passe en MySQL 4.1 ».
Section A.2.3, « Erreur Client does not support authentication
protocol ».
En général, ce que vous devez faire pour passer en version 4.0, à partir d'une version 3.23 :
Vérifiez que les changements de la liste ci-dessous n'affectent pas votre application.
Lisez les nouveautés de la version 4.0, pour savoir quelles nouvelles fonctionnalités vous allez découvrir en 4.0. See Section C.3, « Changements de la version 4.0.x (Production) ».
Après mise à jour, exécutez le script
mysql_fix_privilege_tables pour ajouter
de nouveaux droits et fonctionnalités à la table MySQL.
Voyez Section 2.6.7, « Mise à jour des tables de droits ».
Editez les scripts de démarrage MySQL pour les fichiers de configuration pour ne plus utiliser les options abandonnées, listées ci-dessous.
Convertissez vos vieilles tables ISAM en
tables MyISAM avec la commande :
mysql_convert_table_format database. Pour
convertir toutes les tables d'une base de données, utilisez
cette commande :
shell> mysql_convert_table_format database db_name
Notez que cela ne doit être fait que si toutes les tables
de la base sont des tables ISAM ou
MyISAM. Pour éviter de convertir toutes
les tables d'une base au format MyISAM,
vous pouvez explicitement utiliser les noms de vos tables
ISAM après le nom de la base dans la
commande. Vous pouvez aussi utiliser la commande
ALTER TABLE table_name TYPE=MyISAM sur
toutes les tables ISAM.
Les tables individuelles peuvent être mises au format
MyISAM en utilisant la commande
ALTER TABLE suivante, pour chaque
table :
mysql> ALTER TABLE tbl_name TYPE=MyISAM;
Pour connaître le type d'une table, utilisez cette commande :
mysql> SHOW TABLE STATUS LIKE 'tbl_name';
Assurez-vous que vous n'avez pas de client MySQL qui utilise
des bibliothèques partagées (comme les modules Perl
Msql-Mysql). Si vous en avez, vous devriez les recompiler
car les structures utilisées dans
libmysqlclient.so ont changées.
Si vous utilisez MySQL sur Windows, voyez aussi Section 2.2.11, « Mettre à jour MySQL sous Windows ».
Si vous utilisez la réplication, voyez aussi Section 6.6, « Changer de version de réplication » pour plus de détails sur la mise à jour de la réplication.
MySQL 4.0 va fonctionner même si vous ne suivez pas les
instructions ci-dessus, mais il ne sera pas capable de profiter
des nouveaux droits disponibles avec MySQL 4.0 et vous pourriez
rencontrer des problèmes lors de l'évolution vers MySQL 4.1 ou
plus récent. Les fichiers ISAM fonctionne
toujours en MySQL 4.0 mais il est abandonné, et il sera
désactivé en MySQL 5.0.
Les anciens clients doivent fonctionner avec le serveur version 4.0 sans aucun problème.
Même si vous suivez les instructions ci-dessus, vous pourrez
retourner en version MySQL 3.23.52 ou plus récent, si vous
rencontrez des difficultés avec MySQL 4.0. Dans ce cas, vous
devez utiliser la commande mysqldump sur
toutes les tables qui utilisent un index en texte plein, et
restaurer ces tables en 3.23 (car la version 4.0 utilise un
nouveau format pour les index en texte plein).
Voici une liste plus complète de points à contrôler lorsque vous passez à la version 4.0 :
MySQL 4.0 a de très nombreux nouveaux droits dans la table
mysql.user. See
Section 5.5.3, « Droits fournis par MySQL ».
Pour installer ces nouveaux droits, suivez la procédure
dans Section 2.6.7, « Mise à jour des tables de droits ». Jusqu'à ce
que ce script soit exécuté, les utilisateurs auront les
droits de SHOW DATABASES, CREATE
TEMPORARY TABLES, et LOCK
TABLES. Les droits de SUPER et
EXECUTE héritent leur valeur du droit de
PROCESS. REPLICATION
SLAVE et REPLICATION CLIENT
héritent leur valeur de FILE.
Si vous avez un script qui crée automatiquement des
nouveaux utilisateur, vous devez le modifier pour y inclure
les nouveaux droits. Si vous n'utilisez pas la commande
GRANT dans ces scripts, c'est une bonne
idée que de les vérifier.
En version 4.0.2, l'option
--safe-show-database est abandonnée (et ne
fait plus rien du tout). See
Section 5.4.3, « Options de démarrage qui concernent la sécurité ».
Si vous obtenez des interdictions d'accès pour les nouveaux
utilisateurs en version 4.0.2, vous devriez vérifier si
vous avez besoin de nouveaux droits que vous n'utilisiez pas
avant. En particulier, vous aurez besoin du droit de
REPLICATION SLAVE (au lieu de
FILE) pour les nouveaux esclaves.
safe_mysqld a été renommé en
mysqld_safe. Pour assurer la
compatibilité ascendante, les distribution binaires vont
inclure pour quelques temps un lien symbolique de
safe_mysqld vers
mysqld_safe.
Le support InnoDB est désormais inclut
par défaut dans la distribution binaire. Si vous compilez
MySQL depuis les sources, et que vous voulez économiser de
la mémoire, utilisez l'option
--skip-innodb au démarrage du serveur.
Pour compiler MySQL sans le support
InnoDB, utilisez le script
configure avec l'option
--without-innodb.
Les paramètres de démarrage
myisam_max_extra_sort_file_size et
myisam_max_extra_sort_file_size sont
désormais exprimés en octets, et non plus en Mo, comme
cela était le cas jusqu'en version 4.0.3).
mysqld dispose maintenant de l'option
--temp-pool activée par défaut, car cela
donne de meilleures performances sur certains systèmes
d'exploitation, et notamment Linux.
Les options de démarrage mysqld
--skip-locking et
--enable-locking ont été renommées
--skip-external-locking et
--external-locking.
Les systèmes externes de verrouillages des tables
MyISAM/ISAM sont
désormais désactivés par défaut. Vous pouvez les
réactiver avec l'option
--external-locking. Pour la plupart des
utilisateurs, ce n'est jamais nécessaire.
Les options de démarrage suivantes ont été renommées :
| Ancien nom | Nouveau nom. |
myisam_bulk_insert_tree_size | bulk_insert_buffer_size |
query_cache_startup_type | query_cache_type |
record_buffer | read_buffer_size |
record_rnd_buffer | read_rnd_buffer_size |
sort_buffer | sort_buffer_size |
warnings | log-warnings |
err-log | --log-error (for mysqld_safe) |
Les options de démarrage record_buffer,
sort_buffer et
warnings vont encore fonctionner avec
MySQL 4.0 mais elles sont obsolètes.
Changements SQL :
Les variables SQL suivantes ont changé de nom.
| Ancien nom | Nouveau nom. |
SQL_BIG_TABLES | BIG_TABLES |
SQL_LOW_PRIORITY_UPDATES | LOW_PRIORITY_UPDATES |
SQL_MAX_JOIN_SIZE | MAX_JOIN_SIZE |
SQL_QUERY_CACHE_TYPE | QUERY_CACHE_TYPE |
Les anciens noms fonctionneront encore en MySQL 4.0, mais sont obsolètes.
Vous devez utiliser la commande SET GLOBAL
SQL_SLAVE_SKIP_COUNTER=# au lieu de SET
SQL_SLAVE_SKIP_COUNTER=#.
SHOW MASTER STATUS retourne désormais
une liste vide si les logs binaires ne sont pas activés.
SHOW SLAVE STATUS retourne désormais une
liste vide si l'esclave n'est pas initialisé.
SHOW INDEX a 2 colonnes de plus
(Null et Index_type)
qu'il n'avait pas en version 3.23.
Le format de SHOW OPEN TABLE a été
changé.
ORDER BY col_name DESC trie les valeurs
NULL en dernier, depuis MySQL 4.0.11. En
3.23 et dans les premières versions de 4.0, ce n'était pas
toujours cohérent.
CHECK, SIGNED,
LOCALTIME et
LOCALTIMESTAMP sont des mots réservés.
Les colonnes DOUBLE et
FLOAT acceptent désormais l'option
UNSIGNED pour le stockage (auparavant,
UNSIGNED était ignoré pour ces
colonnes).
Le résultat de toutes les opérations sur les bits,
|, &,
<<, >> et
~ est maintenant non signé. Cela peut
poser des problèmes si vous aviez un contexte dans lequel
vous souhaitez un résultat signé. See
Section 12.7, « Fonctions de transtypage ».
Note : lorsque vous
utilisez la soustraction entre des entiers dont l'un est
UNSIGNED, le résultat sera non signé!
En d'autres termes, avant de passer à la version MySQL 4.0,
vous devriez vérifier les situations où votre application
soustrait une valeur d'un entier non signé, et que vous
attendez une valeur négative, ou si vous soustrayez une
valeur non signée d'une colonne. Vous pouvez désactiver ce
comportement en utilisant l'option de démarrage
--sql-mode=NO_UNSIGNED_SUBTRACTION lorsque
vous démarrez mysqld. See
Section 12.7, « Fonctions de transtypage ».
Vous devriez utiliser des entiers pour stocker les valeurs dans les colonnes de type BIGINT (au lieu d'utiliser des chaînes, comme vous le faisiez en MySQL 3.23). Utiliser des chaînes va toujours fonctionner, mais passer des entiers est bien plus efficace.
En version 3.23, INSERT INTO ... SELECT
fonctionne toujours avec l'option IGNORE.
En version 4.0.1, MySQL va s'arrêter (et peut être annuler
la transaction) si vous ne spécifiez pas l'option
IGNORE.
Vous devriez utiliser la commande TRUNCATE
TABLE lorsque vous voulez effacer toutes les
lignes d'une table, et que vous ne souhaitez pas savoir
combien de lignes ont été effacées de la table (car
TRUNCATE TABLE est plus rapide que
DELETE FROM table_name).
Vous allez rencontrer une erreur si vous avez un verrou
actif ou une transaction active, et que vous essayez
d'utiliser les commandes TRUNCATE TABLE
ou DROP DATABASE.
Pour utiliser MATCH ... AGAINST (... IN BOOLEAN
MODE) avec vos table,s vous devez les reconstruire
avec ALTER TABLE table_name TYPE=MyISAM,
même si la table est
déjà au format MyISAM. See
Section 12.6.4, « Paramétrage précis de la recherche en text intégral de MySQL ».
LOCATE() et INSTR()
sont sensibles à la casse, si l'un des arguments est une
chaîne binaire. Sinon, ils sont insensibles à la casse.
STRCMP() utilise désormais le jeu de
caractères courant pour les comparaisons, ce qui signifie
que le comportement par défaut des comparaisons est
désormais insensible à la casse.
HEX(string) retourne désormais les
caractères convertis sous la forme d'une chaîne
hexadécimale. Si vous voulez convertir un nombre en
hexadécimal, vous devez vous assurer d'appeler
HEX() avec un argument numérique.
RAND(seed) retourne un nombre différent
en version 4.0 qu'en version 3.23 : cela est fait pour
différencier plus fortement RAND(seed)
de RAND(seed+1).
Le type par défaut retourné par
IFNULL(A,B) est maintenant le plus
général des deux types A et
B. (L'ordre est
STRING, REAL puis
INTEGER).
Changements de l'interface C :
Les fonctions de l'ancienne API C API
mysql_drop_db,
mysql_create_db et
mysql_connect ne sont plus supportées,
à moins que vous ne compiliez MySQL avec
CFLAGS=-DUSE_OLD_FUNCTIONS. Au lieu de
cela, il sera plus sage de changer vos programmes, pour
qu'il utilisent la nouvelle API 4.0.
Dans la structure MYSQL_FIELD,
length et max_length
ont évolué de unsigned int en
unsigned long. Cela ne va pas causer de
problèmes, hormis le fait qu'ils peuvent générer des
messages d'alerte lorsqu'ils sont utilisé comme argument de
fonctions comme printf().
Les clients multi-threadés doivent utiliser
mysql_thread_init() et
mysql_thread_end(). See
Section 24.2.15, « Comment faire un client MySQL threadé ».
Autres changements :
Si vous voulez recompiler le module Perl DBD::mysql, vous
devez prendre les versions Msql-Mysql-modules 1.2218 ou plus
récente, car les anciennes versions des module DBD
utilisent une fonction drop_db()
abandonnée.
Les clients des versions 3.22 et 3.21 vont fonctionner sans problèmes avec la version 3.23 du serveur.
La liste suivante indique les points à vérifier lors de la migration :
Changement de tables :
MySQL 3.23 supporte les nouvelles tables
MyISAM et l'ancien type
ISAM. Par défaut, toutes les nouvelles
tables sont créées avec MyISAM à moins
que vous ne lanciez mysqld avec l'option
--default-table-type=isam. Vous n'avez pas
à convertir les anciennes tables ISAM
pour les utiliser avec MySQL 3.23. Vous pouvez les convertir
les tables ISAM en
MyISAM avec la commande ALTER
TABLE tbl_name TYPE=MyISAM et le script Perl
mysql_convert_table_format.
Toutes les tables qui utilisent le jeu de caractères
tis620 doivent être corrigées avec
myisamchk -r ou REPAIR
TABLE.
Si vous utilisez le jeu de caractères
allemand pour les tris, vous devez
réparer vos tables avec isamchk -r, car
nous avons fait des modifications dans l'ordre de tri.
Changement au programme client :
Le client MySQL mysql est démarré par
défaut avec l'option option --no-named-commands
(-g). Cette option peut être désactivée avec
--enable-named-commands (-G). Cela peut
causer des problèmes d'incompatibilité dans certains cas
: par exemple, dans les scripts SQL qui utilisent des
commandes nommées sans point virgule! Le format long de la
commande devrait fonctionner correctement.
Si vous voulez que les fichiers d'export de
mysqldump soient compatibles entre les
versions MySQL 3.22 et 3.23, vous ne devez pas utiliser
l'option --opt ou --all de
mysqldump.
Changements SQL :
Si vous exécutez une commande DROP
DATABASE sur un lien symbolique, le lien et la
base originale seront effacés. Cela n'arrivait pas en 3.22
car configure ne détectait pas les
appels à readlink.
OPTIMIZE TABLE ne fonctionne que pour les
tables MyISAM. Pour les autres types de
tables, vous devez utiliser ALTER TABLE
pour optimiser la table. Durant la commande
OPTIMIZE TABLE, la table est
verrouillée.
Les fonctions de date qui travaillent sur des parties de
date (comme MONTH()) vont désormais
retourner 0 pour la date 0000-00-00.
(MySQL 3.22 retournait NULL.)
Le type de retour par défaut de IF()
dépendant maintenant des deux arguments, et plus seulement
du premier.
AUTO_INCREMENT ne fonctionne pas sur les
nombres négatifs. La raison pour cela est que les nombres
négatifs posaient des problèmes d'écrasement entre -1 et
0. AUTO_INCREMENT pour les tables
MyISAM est maintenant géré à un niveau
plus bas, et il est bien plus rapide. Pour les tables
MyISAM, les anciens numéros ne sont plus
réutilisés, même si vous effacez des lignes dans la
table.
CASE, DELAYED,
ELSE, END,
FULLTEXT, INNER,
RIGHT, THEN et
WHEN sont de nouveaux mots réservés.
FLOAT(p) est maintenant un véritable
type de nombre à virgule flottante, avec un nombre défini
de décimales.
Lors de la déclaration de
DECIMAL(length,dec), la taille de
l'argument n'inclut plus une place pour le signe ou le
séparateur décimal.
Une chaîne TIME doit être fournie au
format suivant : [[[DAYS]
[H]H:]MM:]SS[.fraction] ou
[[[[[H]H]H]H]MM]SS[.fraction].
LIKE compare maintenant les chaînes en
appliquant les mêmes règles que =. Si
vous voulez l'ancien comportement, vous pouvez compiler
MySQL avec l'option
CXXFLAGS=-DLIKE_CMP_TOUPPER.
REGEXP est maintenant insensible à la
casse pour les chaînes normales (non binaires).
Quand vous vérifiez/réparez des tables, vous devez
utiliser CHECK TABLE ou
myisamchk pour les tables
MyISAM (.MYI) et
isamchk pour les tables
ISAM (.ISM).
Vérifiez tous vos appels à
DATE_FORMAT() pour vous assurer qu'il y a
un signe pourcentage ‘%’
avant chaque caractère de format (MySQL version 3.22 et
plus récent avait déjà cette syntaxe, mais désormais
‘%’ est obligatoire).
En MySQL version 3.22, le résultat de SELECT
DISTINCT ... était toujours trié. En version
3.23, vous devez spécifier la clause GROUP
BY ou ORDER BY pour obtenir un
résultat trié.
SUM() retourne désormais
NULL, au lieu de 0, si il n'y a pas de
lignes à calculer. Ceci s'accorde avec la norme SQL.
AND ou OR avec les
valeurs NULL vont désormais retourner
NULL au lieu de 0. Cela affecte surtout
les requêtes qui utilisait NOT ou une
expression AND/OR telle que NOT
NULL = NULL.
LPAD() et RPAD() vont
réduire la taille de la chaîne résultante, si elle est
plus grand que l'argument de taille.
Changement de l'interface C :
mysql_fetch_fields_direct est maintenant
une fonction (c'était une macro), qui retourne un pointeur
sur MYSQL_FIELD au lieu de
MYSQL_FIELD.
mysql_num_fields() ne peut plus être
utilisé sur les objets MYSQL* (c'est
maintenant une fonction qui prend
MYSQL_RES* comme argument. Il faut donc
utiliser mysql_field_count() à la
place).
Rien qui n'affecte la compatibilité n'a changé entre les
versions 3.21 et 3.22. Le seul problème courant est que les
nouvelles tables qui sont créées avec le type
DATE vont désormais utiliser le nouveau
format de stockage. Vous ne pourrez pas accéder à ces nouveaux
formats depuis les vieilles versions de
mysqld.
Lors de la mise à jour en MySQL 3.23 depuis une ancienne version, suivez ces conseils :
Après avoir installé MySQL version 3.22, vous devriez
démarrer le nouveau serveur, et exécuter le script
mysql_fix_privilege_tables. Il va ajouter
les nouveaux droits à la commande GRANT.
Si vous oubliez cela, vous obtiendrez des erreurs
Access denied lorsque vous essayez
d'utiliser les commandes ALTER TABLE,
CREATE INDEX ou DROP
INDEX. La procédure pour mettre à jour les
tables de droits est décrite dans
Section 2.6.7, « Mise à jour des tables de droits ».
L'interface C de mysql_real_connect() a
changé. Si vous avez un vieux client qui appelle cette
fonction, vous devez placer un 0 pour le
nouvel argument db (ou réécrire le
client pour qu'il envoie l'élément db,
et accélère les connexions). Vous devez aussi appeler
mysql_init() avant d'appeler
mysql_real_connect()! Ce changement a
été fait pour permettre l'appel de la fonction
mysql_options(), qui sauve les options
dans la structure MYSQL.
La variable key_buffer de
mysqld a changé de nom, et est devenue
key_buffer_size, mais vous pouvez
toujours utiliser l'ancien nom dans vos fichiers de
démarrage.
Si vous avez une version de MySQL plus ancienne que la version 3.20.28 et que vous voulez passer à la version 3.21, vous devez suivre ces étapes :
Vous pouvez démarrer le serveur mysqld
version 3.21 avec le script safe_mysqld
--old-protocol pour l'utiliser avec les clients de la
version 3.20. Dans ce cas, la fonction
mysql_errno() des nouveaux clients ne sera
pas fonctionnelle, et seul CR_UNKNOWN_ERROR
(mais il fonctionne pour les erreurs client), et le serveur
utilisera l'ancienne fonction password()
plutôt que la nouvelle.
Si vous n'utilisez pas l'option
--old-protocol avec mysqld,
vous devez suivre ces instructions :
Tous les clients doivent être recompilés. Si vous utilisez
ODBC, vous devez obtenir le nouveau pilote
MyODBC 2.x.
Le script scripts/add_long_password doit
être utilisé pour convertir le champs
Password de la table
mysql.user en
CHAR(16).
Tous les mots de passe doivent être réassignés dans la
table mysql.user pour utiliser les mots
de 62 bits au lieu de 31 bits.
Le format de table n'a pas changé, ce qui vous évite d'avoir à convertir des tables.
MySQL version 3.20.28 et plus récent peut gérer les nouvelles
tables user sans affecter les clients. Si
vous avez une version plus ancienne que la 3.20.28, les mots de
passe ne seront plus valide, si vous convertissez la table
user. Pour être tranquille, commencez par
faire passer votre version à la 3.20.28 puis passez en version
3.21.
Le nouveau client fonctionne avec le serveur 3.20.x
mysqld, alors si vous rencontrez des
problèmes avec la version 3.21.x, vous pouvez toujours vous
rabattre sur les vieux serveurs 3.20.x sans recompiler les
clients.
Si vous n'utilisez pas l'option --old-protocol
de mysqld, les vieux clients vont émettre
une erreur :
ERROR: Protocol mismatch. Server Version = 10 Client Version = 9
La nouvelle interface Perl
DBI/DBD supporte aussi
l'ancienne interface mysqlperl. Le seul
changement que vous devez faire si vous utilisez
mysqlperl est de changer les arguments de la
fonction connect(). Les nouveaux arguments
sont : host, database,
user, et password (les
arguments user et password
ont été échangés).
Les modifications actuelles affectent les requêtes des anciennes applications :
HAVING doit être spécifié avant la
clause ORDER BY.
Les paramètres de la fonction LOCATE()
ont été échangés.
Il y a de nouveaux mots réservés. Les plus notables sont
DATE, TIME et
TIMESTAMP.
Certaines versions introduisent des modifications dans la
structure des tables de droits (les tables qui sont dans la base
mysql), pour ajouter de nouveaux droits ou
fonctionnalités. Pour vous assurer que vos tables de droits
sont à jour lorsque vous changez de version de MySQL, il est
recommandé de les mettre aussi à jour.
Sous Unix ou ses équivalent, la mise à jour des tables de
droits se fait en exécutant le script
mysql_fix_privilege_tables :
shell> mysql_fix_privilege_tables
Vous devez exécuter ce script lorsque le serveur fonctionne. Le
script tente de se connecter au serveur local avec le compte
root. Si votre compte root
requiert un mot de passe, indiquez-le en ligne de commande.
Depuis MySQL 4.1 et plus récent, spécifiez le mot de passe
comme ceci :
shell> mysql_fix_privilege_tables --password=root_password
Pour les versions antérieures à la version MySQL 4.1, spécifiez le mot de passe comme ceci :
shell> mysql_fix_privilege_tables root_password
L script mysql_fix_privilege_tables effectue
les manipulations nécessaires pour convertir vos tables de
droits au format courant. Vous pouvez apercevoir des alertes
Duplicate column name durant l'exécution du
script : ces alertes peuvent être ignorées sans danger.
Après avoir exécuté le script, arrêtez le serveur, et relancez le.
Sous Windows, il n'existe pas de moyen facile de modifier les
tables de droits jusqu'à MySQL 4.0.15. Depuis la version 4.0.15
on, la distribution MySQL inclut un script SQL
mysql_fix_privilege_tables.sql que vous
pouvez utiliser avec le client mysql. Si
votre installation MySQL est située dans le dossier
C:\mysql, la commande a utiliser ressemble
à celle-ci :
C:\mysql\bin>mysql -u root -p mysqlmysql>SOURCE C:\mysql\scripts\mysql_fix_privilege_tables.sql
Si votre installation est située dans un autre dossier, vous devrez adapter les chemins.
La commande mysql vous demandera le mot de
passe pour le compte root : saisissez-le
lorsqu'il est demandé.
Comme pour la procédure Unix, vous pouvez voir apparaître des
alertes Duplicate column name durant le
traitement de votre base mysql par le script
mysql_fix_privilege_tables.sql : elles
peuvent être ignorées.
Après avoir exécuté le script arrêtez le serveur, et relancez-le.
Si vous utilisez MySQL version 3.23, vous pouvez copier les
fichiers .frm, .MYI et
.MYD entre les différentes architectures
qui supportent le même format de nombre à virgule flottante
(MySQL prend en charge les échanges d'octets). See
Section 14.1, « Le moteur de tables MyISAM ».
Les données MySQL des tables ISAM et les
fichiers d'index (.ISD et
*.ISM, respectivement) sont dépendantes de
l'architecture, et dans certains cas, dépendantes du système
d'exploitation. Si vous voulez déplacer des applications vers
une autre machine qui a une autre architecture, ou un autre
système d'exploitation que votre machine courante, il est
recommandé de ne pas faire une simple copie de base en copiant
les fichiers vers leur nouvelle destination. Utilisez plutôt
mysqldump.
Par défaut, mysqldump va créer un fichier
de requêtes SQL. Vous pouvez alors transférer le fichier sur
une autre machine, et le fournir comme script à un client
mysql.
Essayez la commande mysqldump --help pour
voir quelles options sont disponibles. Si vous envoyez les
données vers une nouvelle version de MySQL, il recommandé
d'utiliser l'option mysqldump --opt pour
obtenir un export compact et plus rapide.
Le plus facile (mais pas le plus rapide) pour déplacer une base de données entre deux machines et d'exécuter les commandes suivantes sur la machine qui héberge la base :
shell>mysqladmin -h 'other hostname' create db_nameshell>mysqldump --opt db_name \| mysql -h 'other hostname' db_name
Si vous voulez copier la base depuis une machine distante sur un réseau lent, vous pouvez utiliser :
shell>mysqladmin create db_nameshell>mysqldump -h 'other hostname' --opt --compress db_name \| mysql db_name
Vous pouvez aussi stocker le résultat dans un fichier, et transférer le fichier sur la machine de destination, puis charger ce fichier dans le serveur. Par exemple, vous pouvez exporter la base vers un fichier source comme ceci :
shell> mysqldump --quick db_name | gzip > db_name.contents.gz
Le fichier créé est compressé. Transférez le fichier contenant le contenu de votre base sur la machine de destination, puis utilisez ces commandes :
shell>mysqladmin create db_nameshell>gunzip < db_name.contents.gz | mysql db_name
Vous pouvez aussi utiliser mysqldump et
mysqlimport pour accomplir cette opération.
Pour les grandes tables, c'est bien plus rapide que d'utiliser
simplement mysqldump. Dans les commandes
suivantes, DUMPDIR représente le chemin
complet du dossier que vous utilisez pour stocker le résultat
de mysqldump.
Premièrement, créez un dossier pour les fichiers d'exportation, puis faites l'export :
shell>mkdir DUMPDIRshell>mysqldump --tab=DUMPDIR db_name
Puis transférez les fichiers du dossier
DUMPDIR dans un dossier correspondant, dans
la machine de destination, puis chargez ces fichiers dans MySQL
comme ceci :
shell>mysqladmin create db_name # Création de la baseshell>cat DUMPDIR/*.sql | mysql db_name # Création des tables dans la baseshell>mysqlimport db_name DUMPDIR/*.txt # Chargement des données dans les tables
N'oubliez pas non plus de copier le contenu de votre base
mysql car c'est là que résident les droits
(user, db,
host). Vous devrez alors exécuter les
commandes en tant que root MySQL sur la
nouvelle machine, jusqu'à ce que vous ayez réinstallé
mysql.
Après l'importation de la base mysql sur la
nouvelle machine, exécutez la commande mysqladmin
flush-privileges pour que le serveur relise les
droits.
Cette section décrit les étapes à suivre pour passer d'une version récente à une version ancienne de MySQL, dans le cas peu probable où vous souhaitez passer à une vieille version qui marchait mieux qu'une version récente.
Si vous changez de version dans une même famille (par exemple, de la version 4.0.20 à 4.0.19) la règle générale est qu'il suffit d'installer les nouveaux exécutables à la place des anciens. Il n'y a pas besoin de toucher aux données. Comme toujours, il est cependant recommandé de faire une sauvegarde.
Les informations suivantes sont à garder comme liste de vérification avant de faire la migration :
Lisez la section de mise à jour pour les versions que vous allez utiliser, et assurez-vous que vous n'aurez pas besoin de fonctionnalités qui ne seront plus disponibles. Section 2.6, « Changer de version de MySQL ».
S'il y a une section de réduction de version pour votre installation, lisez-la.
Vous pouvez toujours copier les fichiers de format et de données entre différentes installation de la même famille, sur la même architecture. La version en production actuellement est la version 4.1.
Si vous passez d'une version de production à une autre plus
ancienne, il est possible que vous rencontriez des
incompatibilités dans les formats de stockage de table. Dans ce
cas, utilisez la commande mysqldump pour
exporter vos tables avant de faire la migration. Après la mise à
jour, importez à nouveau les tables avec la commande
mysql ou mysqlimport. Voyez
Section 2.6.8, « Migrer depuis une autre architecture » pour des exemples.
Le symptôme normal d'incompatibilité entre deux versions de tables est l'impossibilité d'ouvrir la table. Dans ce cas, utilisez la procéduire suivante :
Stoppez le vieux serveur MySQL, celui qui est l'objectif de votre migration.
Redémarrez le nouveau serveur, que vous essayez de quitter.
Exportez les tables qui étaient inaccessibles sur le vieux serveur, en utilisant la commande mysqldump pour créer un fichier d'export.
Stoppez le nouveau serveur et relancez l'ancien.
Rechargez les fichiers exportés dans le vieux serveur. Vos tables devraient être disponibles.
Après être passé de MySQL 5.0 en 4.1, vous risquez de trouver
les lignes suivantes dans le fichier
mysql.err :
Incorrect information in file: './mysql/user.frm'
Dans ce cas, suivez ces instructions :
Lancez MySQL 5.0.4 ou plus récent.
Exécutez la commande
mysql_fix_privilege_tables, qui va
changer la table mysql.user pour qu'elle
ait un format que les deux versions 4.1 et 5.0 peuvent
utiliser.
Arrêtez le serveur MySQL.
Lancez MySQL 4.1.
Si la procédure précédente échoue, alors il faut suivre ces instructions :
Lancez MySQL 5.0.4 ou plus récent.
Exécutez la commande mysqldump --opt --add-drop-table mysql > /tmp/mysql.dump.
Arrêtez le serveur MySQL.
Lancez MySQL 4.1 avec l'option
--skip-grant.
Exécutez la commande mysql mysql < /tmp/mysql.dump.
Exécutez la commande mysqladmin flush-privileges.
Le format des tables de la version 4.1 a changé pour accepter les jeux de caractères. A cause de cela, vous devez utiliser la commande mysqldump pour exporter les données qui ont été créées avec des versions plus récentes de MySQL. Par exemple, si toutes les tables d'une base de données doivent être exportées pour être réinsérées, au format MySQL 4.0, utilisez cette commande :
shell> mysqldump --create-options --compatible=mysql40 db_name > dump_file
Puis, arrêtez le nouveau serveur, relancez l'ancien, et importez les données depuis ce fichier :
shell> mysql db_name < dump_file
Dans le cas particulier où vous utilisez des tables
MyISAM, aucun traitement spécial n'est
nécessaire si toutes les colonnes contiennent des nombres ou
des chaînes de caractères (CHAR,
VARCHAR, TEXT etc) qui ne
contiennent que des caractères latin1. Dans
ce cas, les tables version 4.1 devraient être directement
utilisables en version 4.0.
Si vous utilisez le script
mysql_fix_privilege_tables pour mettre à
jour les tables de droits, vous pouvez utilisez la méthode
précédente pour convertir les tables en version 4.0, ou
appliquez les commandes suivantes aux tables version 4.1 :
ALTER TABLE mysql.user CONVERT TO CHARACTER SET latin1 COLLATE latin1_swedish_ci; ALTER TABLE mysql.db CONVERT TO CHARACTER SET latin1 COLLATE latin1_swedish_ci; ALTER TABLE mysql.host CONVERT TO CHARACTER SET latin1 COLLATE latin1_swedish_ci; ALTER TABLE mysql.tables_priv CONVERT TO CHARACTER SET latin1 COLLATE latin1_swedish_ci; ALTER TABLE mysql.columns_priv CONVERT TO CHARACTER SET latin1 COLLATE latin1_swedish_ci; ALTER TABLE mysql.func CONVERT TO CHARACTER SET latin1 COLLATE latin1_swedish_ci;
Cette section présente les problèmes que nous avons rencontré avec Linux. Les premières sections décrivent les problèmes liés aux opérations générales, les problèmes qui arrivent avec les distributions binaires ou source, puis les problèmes de post-installation. Les autres sections discutent de problèmes qui surviennent sur des plates-formes spécifiques.
Notez que la plupart des problèmes surviennent sur les anciennes versions de Linux. Si vous utilisez une version récente, vous ne les verrez jamais ou presque.
MySQL requiert au moins Linux Version 2.0.
Attention : Nous avons rencontré d'étranges problèmes avec Linux 2.2.14 et MySQL sur des architectures SMP. Nous avons aussi des rapports d'utilisateurs MySQL qui ont rencontré de sérieux problèmes de stabilité avec le noyau 2.2.14. Si vous utilisez ce noyau, il est recommandé de passer en version 2.2.19 (ou plus récente) ou en 2.4. Si vous avez un serveur multi-processeurs, vous devriez considérer sérieusement la migration vers la version 2.4 car elle vous apportera un gain de vitesse significatif. Votre système sera aussi plus stable.
Lorsque vous utilisez les LinuxThreads,
vous verrez un minimum de trois processus
mysqld. Ce sont en fait des threads. Il y a
un thread de gestion LinuxThreads, un
thread pour gérer les connexions et un thread pour gérer les
alertes et signaux.
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 apportera 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 bibliothèques 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ême,
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
bibliothèques 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.
Les notes suivantes concernant glibc ne
s'appliquent que si vous compilez vous-mêmes MySQL. Si vous
utilisez Linux sur une machine x86, dans la plupart des cas,
il est mieux d'utiliser notre bibliothèque. Nous compilons
nos exécutables avec les meilleures versions corrigées de
glibc que nous pouvons trouver, avec les
meilleures options de compilation possible, pour faire que
notre serveur supporte les hautes charges. Pour un utilisateur
typique, même pour une configuration avec de nombreuses
connexions ou des tables dépassant les 2 Go, notre programme
est meilleur choix. Après avoir lu ce texte, si vous doutez
toujours, testez notre compilation pour voir si elle répond
à vos besoins. Si vous pensez qu'elle n'est pas à la
hauteur, alors essayez de compiler par vous-mêmes. Dans ce
cas, nous apprécierons de savoir ce que vous avez fait, pour
pouvoir améliorer notre propre version.
MySQL utilise les LinuxThreads sur Linux.
Si vous utilisez une vieille version de Linux qui n'a pas
glibc2, vous devrez installer
LinuxThreads avant de compiler MySQL. Vous
pouvez obtenir LinuxThreads sur
http://dev.mysql.com/downloads/os-linux.html.
Notez que les versions de glibc avant et
incluant la version 2.1.1 ont un bug critique dans la gestion
de pthread_mutex_timedwait(), qui est
utilisée lorsque vous envoyez des commandes INSERT
DELAYED. Nous vous recommandons de ne pas utiliser
INSERT DELAYED avant de mettre à jour
glibc.
Notez que le noyau Linux et la bibliothèque
LinuxThreads sont limitées par défaut à
1024. Si vous envisagez d'avoir plus de 1000 connexions
simultanées, vous aurez besoin de faire des changement dans
LinuxThreads :
Augmentez PTHREAD_THREADS_MAX dans
sysdeps/unix/sysv/linux/bits/local_lim.h
à 4096 et réduisez STACK_SIZE dans
linuxthreads/internals.h à 256 ko.
Les chemins sont relatifs à la racine de
glibc. (Notez que MysQL ne sera pas
stable autour de 600 à 1000 connexions si
STACK_SIZE vaut les 2 Mo par défaut.
Recompilez LinuxThreads pour avoir un
nouveau libpthread.a, et recompilez
MySQL avec.
La page
http://www.volano.com/linuxnotes.html
contient des informations supplémentaires pour contourner
cette limite de LinuxThreads.
Il y a un autre problème qui limite considérablement les
performances de MySQL, notamment sur des systèmes
multi-processeurs. L'implémentation mutex de
LinuxThreads dans glibc
2.1 est très mauvaise pour les programmes ayant de nombreux
threads qui gardent le mutex pour une courte période de
temps. Cela produit un résultat paradoxal : si vous compilez
MySQL avec un version originale de
LinuxThreads, supprimer des processeurs de
votre architecture va améliorer les performances. Nous avons
fait un correctif de glibc 2.1.3 pour
corriger ce comportement
(http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).
Avec glibc 2.2.2, MySQL 3.23.36 va utiliser
un mutex adaptatif, qui est bien meilleur que la version
corrigée de glibc 2.1.3. Soyez prévenu,
que dans certaines conditions, le code courant du mutex de
glibc 2.2.2 surchauffe, ce qui bride MySQL.
La probabilité de rencontrer cette condition sera réduite en
donnant à mysqld la plus haute priorité.
Nous avons été capable de corriger le problème avec un
correctif, disponible à
http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch.
Il combine la correction avec l'augmentation du nombre limite
de threads et de la taille de pile. Vous devez l'appliquer
dans le dossier linuxthreads avec
patch -p0
</tmp/linuxthreads-2.2.2.patch. Nous espérons
qu'il sera inclut dans une version future de
glibc 2.2. Dans tous les cas, si vous
compilez avec glibc 2.2.2, vous devrez
corriger STACK_SIZE et
PTHREAD_THREADS_MAX. Nous espérons que les
valeurs par défaut seront corrigées et remplacées par des
valeurs plus raisonnables pour les configurations à haut
rendement de MySQL : les manipulations futures pour compiler
MySQL seront alors réduites à ./configure; make;
make install.
Nous recommandons que vous utilisiez ces correctifs pour
compiler une version spéciale statique de
libpthread.a et que vous l'utilisiez pour
compiler MySQL. Nous savons que les correctifs sont
sécuritaires pour MySQL, et améliore significativement les
performances, mais nous ne pouvons pas nous avancer pour les
autres applications. Si vous compilez d'autres applications
qui requièrent les LinuxThreads avec la
version statique corrigée de la bibliothèque, faîtes le à
vos risques et périls.
Si vous rencontrez des problèmes étranges durant l'installation de MySQL, ou si vous voyez les utilitaires se geler, il est très probable que vous ayez un problème de compilateur ou de bibliothèque. Dans ce cas, utiliser notre binaire résoudra vos problèmes.
Si vous compilez vos propres clients MySQL, vous pouvez rencontrer l'erreur suivante durant l'exécution :
ld.so.1: fatal: libmysqlclient.so.#: open failed: No such file or directory
Ce problème peut être évité avec les méthodes suivantes :
Si vous utilisez le compilateur Fujitsu
(fcc/FCC), vous aurez des problèmes pour
compiler MySQL car le fichier d'entête Linux est très
orienté gcc. La ligne de configuration
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
mysql.server est stocké dans le dossier
support-files dans le dossier
d'installation MySQL, ou dans le dossier des sources. Vous
pouvez l'installer dans /etc/init.d/mysql
pour assurer le démarrage et l'extinction automatique de
MySQL. See Section 2.5.2.2, « Lancer et arrêter MySQL automatiquement ».
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 connaître le nombre de gestionnaires de fichiers alloués en faisant :
shell>cat /proc/sys/fs/file-maxshell>cat /proc/sys/fs/dquot-maxshell>cat /proc/sys/fs/super-max
Si vous avez plus de 16 Mo de mémoire, vous devez ajouter
quelque 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
Il est recommandé d'ajouter aussi la ligne suivante dans le
fichier /etc/my.cnf :
[mysqld_safe] open-files-limit=8192
Cela va autoriser le serveur à un maximum de 8192 de connexions et fichiers ouvertes simultanément.
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, va libérer une région réservée,
si vous lui demandez de libérer une adresse déjà utilisée,
détruisant les données de la page, au lieu de retourner une
erreur. Donc, la sécurité de mysqld et
des autres applications qui dépendent d'un comportement
civils du code qui gère les threads. L'utilisateur doit
s'assurer que le nombre de threads fonctionnant simultanément
est suffisamment bas pour éviter d'entrer dans la pile
globale. Avec mysqld, vous devez suivre
cette règle de bon fonctionnement en donnant une valeur
raisonnable à max_connections.
Si vous compilez MySQL vous-mêmes, vous pouvez corriger
LinuxThreads pour améliorer l'utilisation
de la pile. See Section 2.8.1.3, « Notes sur la distribution source de Linux ». Si vous
ne voulez pas corriger 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 128 ko et 256
ko.
Si vous utilisez beaucoup de connexions simultanées, vous pouvez souffrir d'une ``fonctionnalité'' du noyau 2.2, qui tente d'éviter les DOS par fork en pénalisant les processus qui forkent ou qui clonent des fils. Cela fait que MySQL ne se comporte pas bien si vous augmentez le nombre de clients simultanés. Sur les systèmes mono-processeurs, nous avons vu des symptômes sous la forme de ralentissement : il prenait un très long temps pour se connecter (parfois une minute), et il fallait autant de temps pour terminer le processus. Sur les systèmes multi-processeurs, nous avons observé une décroissance graduelle des performances des requêtes chez de nombreux clients. Durant nos recherches pour corriger le problème, nous avons re¸u un patch d'un client qui prétendait avoir résolu le problème pour son site. Ce patch est disponible sur http://www.mysql.com/Downloads/Patches/linux-fork.patch. Nous avons maintenant fait des tests exhaustifs de ce patch en développement et en production. Il a amélioré significativement les performances sans causer de problèmes, et nous l'avons recommandé à nos utilisateurs qui fonctionnent avec des serveurs chargés et un noyau 2.2.
Ce problème a été réglé avec le noyau 2.4 : si vous n'êtes pas satisfait avec les performances courantes de votre système, au lieu de le corriger, passez donc votre noyau 2.2 en 2.4. Sur les systèmes multi-processeurs, la mise à jour vous donnera d'ailleurs un regain de puissance, en plus de corriger le bug.
Nous avons testé MySQL sur des noyaux 2.4 et sur des machines bi-processeurs, et nous avons trouvé que MySQL se comporte beaucoup mieux. Il n'y avait pratiquement pas de ralentissement de requêtes même avec 1000 client, et gain de puissance était de 180% (calculé avec le ratio de vitesse maximale divisé par la vitesse moyenne d'un client). Nous avons observé des résultats similaires sur une machine quadri-processeurs : virtuellement aucun ralentissement alors que le nombre de clients est monté jusqu'à 1000, et le gain de puissance a atteind 300%. En se basant sur ces résultats, pour un serveur haute performances multi-processeurs, nous vous recommandons de passer en noyau 2.4.
Nous avons découvert qu'il est essentiel de faire fonctionner
les processus mysqld avec la priorité
maximal sur le noyau 2.4 pour atteindre les meilleures
performances. Cela peut se faire en ajoutant la commande
renice -20 $$ dans
mysqld_safe. Durant nos tests sur une
machine quadri-processeurs, augmenter la priorité a engendré
60% d'amélioration avec 400 clients.
Nous essayons aussi de rassembler plus d'informations sur
comment MySQL se comporte sur un système 2.4 quadri- ou
octo-processeurs. Si vous avez accès a de telles données,
envoyez nous un email à <benchmarks@mysql.com>
avec les résultats. Nous allons les étudier pour les inclure
dans le manuel.
Si vous voyez un processus mysqld mort avec
ps, c'est que vous avez découvert un bug
dans MySQL ou qu'une des tables est corrompue. See
Section A.4.2, « Que faire si MySQL plante constamment ? ».
Pour obtenir un core dump sur Linux si
mysqld se termine avec un signal
SIGSEGV, vous pouvez lancer
mysqld avec l'option
--core-file. Notez que vous aurez
probablement à augmenter la taille du fichier core en
ajoutant la commande ulimit -c 1000000 à
mysqld_safe ou en lan¸ant
mysqld_safe avec
--core-file-size=1000000. See
Section 5.1.3, « safe_mysqld, le script père de
mysqld ».
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 Red Hat,
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 sont connus pour
fonctionner.
Si vous utilisez gcc 3.0 ou plus récent
pour compiler MySQL, vous devez installer la bibliothèque
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! Pour corriger ce problème, lancez
mysqld avec l'option
--thread-stack=192K. Utilisez la syntaxe
-O thread_stack=192K avant MySQL 4.) La
taille de la pile est maintenant par défaut pour les versions
MySQL 4.0.10 et plus récente, alors vous ne devriez pas
rencontrer de problème.
Si vous utilisez gcc 3.0 et plus récent
pour compiler MySQL, vous devez installer la bibliothèque
libstdc++v3 avant de compiler MySQL; si
vous ne le faites pas, vous aurez des erreurs à propos de
__cxa_pure_virtual qui manque, durant la
résolution des symboles.
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'
Si mysqld provoque toujours un plantage 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éessayez. 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'
Vous pouvez éviter d'utiliser libg++.a
en exécutant configure comme suit :
shell> CXX=gcc ./configure
Si mysqld se plante immédiatement, et que
vous utilisez Red Hat Version 5.0, avec une version de
glibc plus ancienne que 2.0.7-5, il est
recommandé d'installer les patches glibc.
Il y a beaucoup d'informations à ce sujet dans les archives
courriel, disponibles sur
http://lists.mysql.com/.
Sur quelques implémentations, readdir_r()
est cassé. Le symptôme est que SHOW
DATABASES retourne toujours un résultat vide. Cela
peut être corrigé en supprimant
HAVE_READDIR_R de
config.h après avoir configuré et avant
de commencer à compiler.
La version 3.23.12 de MySQL est la première version de MySQL à être testée sur Linux-Alpha. Si vous voulez utiliser MySQL sur Linux-Alpha, vous devez vous assurer d'avoir cette version ou une version plus récente.
Nous avons testé MySQL sur Alpha avec nos tests de performance et notre suite de tests : tout semble fonctionner correctement.
Nous construisons actuellement les paquets binaires de MySQL
sur SuSE Linux 7.0 pour
AXP, kernel 2.4.4-SMP,
Compaq C compiler (V6.2-505) et
Compaq C++ compiler (V6.3-006) sur une
machine Compaq DS20 avec un processeur
Alpha EV6.
Vous pouvez trouver les précédents compilateurs sur
http://www.support.compaq.com/alpha-tools/).
En utilisant ces compilateurs, au lieu de
gcc, nous obtenons environs 9 à 14%
d'améliorations des performances avec MySQL.
Notez que jusqu'aux versions 3.23.52 et 4.0.2 de MySQL nous
avons optimisé l'application pour le processeur courant
seulement (en utilisant l'option de compilation
-fast); cela signifiait que vous ne pouviez
utiliser nos binaires si vous n'aviez pas un processeur Alpha
EV6.
Avec les versions suivantes nous avons ajouté l'option
-arch generic à nos options de
compilation, ce qui assure que le binaire fonctionne sur tout
les processeurs Alpha. Nous compilons aussi statiquement pour
éviter les problèmes de bibliothèques.
CC=ccc CFLAGS="-fast -arch generic" CXX=cxx \ CXXFLAGS="-fast -arch generic -noexceptions -nortti" \ ./configure --prefix=/usr/local/mysql --disable-shared \ --with-extra-charsets=complex --enable-thread-safe-client \ --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared
Si vous voulez utiliser egcs la ligne de
configuration suivante a fonctionné pour nous :
CFLAGS="-O3 -fomit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ --disable-shared
Quelques problèmes connus lors de l'utilisation de MySQL sur Linux-Alpha:
Le débogage d'applications threadées comme MySQL ne
fonctionnera pas avec gdb 4.18. Vous
devez télécharger et utiliser gdb 5.1
à la place !
Si vous essayez de lier statiquement
mysqld en utilisant
gcc, l'image résultante videra son
noyau (core dump) au démarrage. En
d'autres termes, n'utilisez pas
--with-mysqld-ldflags=-all-static avec
gcc.
MySQL devrait fonctionner sur MkLinux avec le dernier paquet
glibc (testé avec glibc
2.0.7).
Pour faire fonctionner MySQL sur Qube2, (Linux Mips), vous
aurez besoin de la bibliothèque glibc la
plus récente (glibc-2.0.7-29C2 est connue
pour marcher). Vous devez aussi utiliser le compilateur
egcs C++ (egcs-1.0.2-9,
gcc 2.95.2 ou plus récent).
Pour pouvoir compiler MySQL sous Linux IA64, nous utilisons
les lignes de compilation suivante : En utilisant
gcc-2.96 :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ "--with-comment=Official MySQL binary" --with-extra-charsets=complex
Sur IA64 les binaires des clients MySQL utilisent des
bibliothèques partagées. Cela signifie que si vous installez
notre distribution binaire à un autre endroit que
/usr/local/mysql vous devez modifier le
fichier /etc/ld.so.conf ou ajouter le
chemin vers le répertoire où vous avez
libmysqlclient.so à la variable
d'environnement LD_LIBRARY_PATH.
See Section A.3.1, « Problèmes lors de la liaison avec la bibliothèque du client MySQL ».
Sous Mac OS X, tar ne sais pas gérer les
noms de fichiers longs. Si vous avez besoin de décompresser la
distribution .tar.gz, utilisez
gnutar.
MySQL devrait fonctionner sans problème avec les versions Mac OS X 10.x (Darwin). Vous n'avez pas besoin du patch pour les pthreads sur cet OS!
Cela s'applique aussi à Mac OS X 10.x Server. La compilation
pour la plate-forme serveur est identique à la compilation
pour pa version client de Mac OS X. Toutefois, notez que MySQL
est pre-installé sur la version Server!
Notre exécutable Mac OS X est compilé sous Darwin 6.3 avec
les options de configure suivantes :
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ --with-extra-charsets=complex --enable-thread-safe-client \ --enable-local-infile --disable-shared
Avant d'essayer de configurer MySQL sur Mac OS X
Server, vous devez d'abord installer le paquet
pthread. Ce n'est plus nécessaire avec les versions récentes
du serveur.
Sous Solaris, vous pouvez rencontrer des problèmes avant même
d'avoir désarchivé la distribution MySQL! Le programme
tar de Solaris ne peut pas manipuler de noms
de fichiers longs, provoquant les messages suivants quand vous
décompressez MySQL :
x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,\ informix,ms-sql,mysql,oracle,solid,sybase, 0 bytes, 0 tape blocks tar: directory checksum error
Dans ce cas, vous devez utiliser GNU tar
(gtar) pour désarchiver la distribution.
Vous pouvez en trouver une copie précompilée pour Solaris sur
http://www.mysql.com/Downloads/.
La gestion native des threads Sun fonctionne uniquement depuis
Solaris 2.5. Pour les versions 2.4 et antérieures, MySQL
utilisera automatiquement les MIT-pthreads.
See Section 2.4.5, « Notes relatives aux MIT-pthreads ».
Vous pouvez rencontrer les erreurs suivantes lors du configure :
checking for restartable system calls... configure: error can not run test programs while cross compiling
Cela signifie que l'installation de votre compilateur est
défectueuse! Dans ce cas, vous devez mettre à jour votre
compilateur en faveur d'une version plus récente. Vous pouvez
aussi résoudre le problème en innérant la ligne suivante dans
le fichier config.cache :
ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}
Si vous utilisez Solaris sur une architecture SPARC, nous
recommandons gcc 2.95.2 comme compilateur.
Vous pouvez le trouver sur
http://gcc.gnu.org/.
Notez que egcs 1.1.1 et
gcc 2.8.1 ne fonctionnent pas correctement
sur SPARC!
La ligne configure recommandée dans le cas
de l'utilisation de gcc 2.95.2 est :
CC=gcc CFLAGS="-O3" \ CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory --enable-assembler
Si vous avez une machine UltraSPARC, vous pouvez gagner 4% de
performances supplémentaires en ajoutant "-mcpu=v8
-Wa,-xarch=v8plusa" à CFLAGS et CXXFLAGS.
Si vous utilisez le compilateur Forte 5.0 (et supérieur) de
Sun, vous pouvez lancer configure de la
fa¸on suivante :
CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt" \ CXX=CC CXXFLAGS="-noex -mt" \ ./configure --prefix=/usr/local/mysql --enable-assembler
Vous pouvez créer un binaire 64 bits avec :
CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt -xarch=v9" \ CXX=CC CXXFLAGS="-noex -mt -xarch=v9" \ ./configure --prefix=/usr/local/mysql --enable-assembler
Lors de bancs de tests MySQL, nous avons gagné 4% en vitesse
sur une UltraSPARC en utilisant Forte 5.0 en mode 32 bits
plutôt que gcc 3.2 avec les marqueurs -mcpu.
Si vous créez un binaire 64 bits, il est de 4% plus lent que le binaire 32 bits,mais en contrepartie vous pouvez gérer davantage de treads et de mémoire.
Si vous rencontrez des problèmes avec
fdatasync ou sched_yield,
vous pouvez les résoudre en ajoutant
LIBS=-lrt à la ligne configure.
Le paragraphe suivant ne s'applique qu'aux compilateurs plus anciens que WorkShop 5.3 :
Vous pouvez avoir à modifier le script
configure et changer la ligne :
#if !defined(__STDC__) || __STDC__ != 1
en :
#if !defined(__STDC__)
Si vous activez __STDC__ avec l'option
-Xc, le compilateur Sun ne peut pas compiler
avec le fichier d'entêtes pthread.h de
Solaris. C'est un bogue de Sun (compilateur ou fichier
d'inclusion défectueux).
Si mysqld génère les messages d'erreur
suivants lorsque vous le lancez, cela est du au fait que vous
avez compilé MySQL avec le compilateur de Sun sans activer
l'option multi-threads (-mt) :
libc internal error: _rmutex_unlock: rmutex not held
Ajoutez -mt à CFLAGS et
CXXFLAGS puis réessayez.
Si vous utilisez la version SFW de gcc (fournie avec Solaris 8),
vous devez ajouter /opt/sfw/lib à la
variable d'environnement LD_LIBRARY_PATH
avant de lancer le configure.
Si vous utilisez le gcc disponible sur
sunfreeware.com, vous pouvez rencontrer de
nombreux problèmes. Vous devriez recompiler gcc et les GNU
binutils sur la machine à partir de laquelle vous les
utiliserez, afin d'éviter tout souci.
Si vous obtenez l'erreur suivante lorsque vous compilez MySQL
avec gcc, cela signifie que votre
gcc n'est pas configuré pour votre version
de Solaris :
shell> gcc -O3 -g -O2 -DDBUG_OFF -o thr_alarm ...
./thr_alarm.c: In function `signal_hand':
./thr_alarm.c:556: too many arguments to function `sigwait'
La meilleure chose à faire dans ce cas est d'obtenir la version
la plus récente de gcc et de compiler avec
votre gcc actuel! Au moins pour Solaris 2.5,
la plupart des versions binaires de gcc ont
d'anciens fichiers d'inclusion inutilisables qui planteront les
programmes qui utilisent les threads (ainsi probablement
d'autres programmes)!
Solaris ne fournit pas de versions statiques de toutes les
bibliothèques système (libpthreads et
libdl), vous ne pouvez donc pas compiler
MySQL avec --static. Si vous tentez de le
faire, vous obtiendrez l'erreur :
ld: fatal: library -ldl: not found undefined reference to `dlopen' cannot find -lrt
Si de nombreux processus essaient de se connecter très
rapidement à mysqld, vous verrez cette
erreur dans le journal MySQL :
Error in accept: Protocol error
Pour éviter cela, vous pouvez lancer le serveur avec l'option
--set-variable back_log=50. Veuillez noter que
--set-variable est déprécié depuis MySQL
4.0, utilisez uniquement --back_log=50.
Si vous liez votre propre client MySQL, vous pouvez avoir l'erreur suivante quand vous le lancez :
ld.so.1: ./my: fatal: libmysqlclient.so.#: open failed: No such file or directory
Le problème peut être évité avec l'une des méthodes suivantes :
Si vous avez des soucis avec configure qui essaie de lier avec
-lz et que vous n'avez pas installé
zlib, vous avez deux solutions :
Si vous voulez utiliser le protocole compressé de communication, vous devrez vous procurer et installer zlib sur ftp.gnu.org.
Configurez avec --with-named-z-libs=no.
Si vous utilisez gcc et rencontrez des problèmes en chargeant
la fonction UDF dans MySQL, essayez d'ajouter
-lgcc à la ligne de liaison de la fonction
UDF.
Si vous voulez que MySQL se lance automatiquement, vous pouvez
copier support-files/mysql.server dans
/etc/init.d et créer un lien symbolique
pointant dessus et s'appelant
/etc/rc3.d/S99mysql.server.
Comme Solaris ne supporte pas les fichiers core pour les
applications setuid(), vous ne pouvez pas
obtenir un fichier core de mysqld si vous
utilisez l'option --user.
Vous pouvez normalement utiliser les binaires Solaris 2.6 sur Solaris 2.7 et 2.8. La plupart des fonctionnalitées de Solaris 2.6 s'appliquent aussi à Solaris 2.7 et 2.8.
Notez que la version 3.23.4 de MySQL et plus doivent être capables de détecter automatiquement les nouvelles versions de Solaris et d'activer les parades pour résoudre les problèmes suivants !
Solaris 2.7 / 2.8 ont quelques bogues dans les fichiers
inclus. Vous verrez peut-être l'erreur suivante en utilisant
gcc :
/usr/include/widec.h:42: warning: `getwc' redefined /usr/include/wchar.h:326: warning: this is the location of the previous definition
Si cela arrive, vous pouvez faire ce qui suit pour résoudre ce problème :
Copiez /usr/include/widec.h vers
.../lib/gcc-lib/os/gcc-version/include et
changez la ligne 41 de :
#if !defined(lint) && !defined(__lint)
en :
#if !defined(lint) && !defined(__lint) && !defined(getwc)
Alternativement, vous pouvez éditer directement le fichier
/usr/include/widec.h. De toutes fa¸ons,
après avoir apporté la correction, vous devez effacer
config.cache et exécuter
configure à nouveau !
Si vous obtenez des erreurs comme celles qui suivent quand
vous exécutez make, c'est parce que
configure n'a pas détecté le fichier
curses.h (probablement à cause de
l'erreur dans /usr/include/widec.h) :
In file included from mysql.cc:50: /usr/include/term.h:1060: syntax error before `,' /usr/include/term.h:1081: syntax error before `;'
La solution est de faire l'une des choses qui suit :
Configurez avec CFLAGS=-DHAVE_CURSES_H
CXXFLAGS=-DHAVE_CURSES_H ./configure.
Editez /usr/include/widec.h comme
indiqué plus haut et ré-exécutez configure.
Effacez la ligne #define HAVE_TERM di
fichier config.h et exécutez
make à nouveau.
Si vous obtenez une erreur disant que votre programme de
liaison ne peut trouver -lz lors de la
liaison du programme de votre client, le problème est
probablement que votre fichier libz.so
est installé dans /usr/local/lib. Vous
pouvez corriger ceci en utilisant l'une des méthodes
suivantes :
Ajoutez /usr/local/lib à
LD_LIBRARY_PATH.
Ajoutez un lien vers libz.so à
partir de /lib.
Si vous utilisez Solaris 8, vous pouvez installer la zlib optionnelle à partir de votre CD Solaris 8.
Configurez MySQL avec l'option
--with-named-z-libs=no.
Sous Solaris 2.8 sur x86, mysqld va crasher
(core dump) si vous l'exécutez 'strip'.
Si vous utilisez gcc ou
egcs sous Solaris x86 et que vous
rencontrez des problèmes avec des coredumps, lorsqu'il y a de
la charge, il est recommandé d'utiliser la commande de
configure suivante :
CC=gcc CFLAGS="-O3 -fomit-frame-pointer -DHAVE_CURSES_H" \ CXX=gcc \ CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors -fno-exceptions \ -fno-rtti -DHAVE_CURSES_H" \ ./configure --prefix=/usr/local/mysql
Cela va éviter les problèmes avec la bibliothèque
libstdc++ et avec les exceptions C++.
Si cela ne vous aide pas, il est recommandé de compiler une
version de débogage, et de l'exécuter avec un fichier de
trace sous gdb. See
Section D.1.3, « Déboguer mysqld sous gdb ».
Cette section fournit des informations pour les différentes variétés de BSD, ainsi que les versions spécifiques de celles-ci.
FreeBSD 4.x est recommandé pour exécuter MySQL vu que le paquet des threads est plus intégré.
La fa¸on la plus facile et la plus conseillée d'installer est d'utiliser les ports du serveur et du client MySQL disponibles sur http://www.freebsd.org/.
Les utiliser vous donnera :
Un MySQL fonctionnant avec toutes les optimisations connues pour votre version active de FreeBSD.
Configuration et construction automatique.
Scripts de démarrage installés dans
/usr/local/etc/rc.d.
La possibilité de voir tous les fichiers installés avec
pkg_info -L.
La possibilité de les effacer tous avec
pkg_delete si vous ne voulez plus de
MySQL sur cette machine.
Il est recommandé d'utiliser les
MIT-pthreads sur FreeBSD 2.x et les threads
natifs sur les versions 3 et plus. Il est possible de faire
fonctionner le tout avec les threads natifs sur les dernières
versions 2.2.x mais vous rencontrerez probablement des
problèmes en coupant mysqld.
Malheureusement, certains appels systèmes sur FreeBSD ne sont
pas encore totalement compatibles avec les threads. Le cas le
plus notable est la fonction
gethostbyname() qui est utilisée par MySQL
pour convertir des noms d'hôtes en adresse IP. Dans certaines
circonstances, le processus mysqld va
soudainement prendre 100% du processeur, et ne plus répondre.
Si vous rencontrez cette situation, essayez de relancer MySQL
avec l'option --skip-name-resolve.
Alternativement, vous pouvez compiler MySQL sur FreeBSD 4.x
avec la bibliothèque LinuxThreads, qui
évite les quelques problèmes que l'implémentation thread
native de FreeBSD a. Pour une bonne comparaison entre
LinuxThreads et les threads natifs, voyez
l'article de Jeremy Zawodny FreeBSD or Linux for
your MySQL Server ? à
http://jeremy.zawodny.com/blog/archives/000697.html.
Un problème connu lors de l'utilisation des
LinuxThreads sur FreeBSD est que
wait_timeout ne fonctionne pas
(probablement un problème de gestion des signaux sous
FreeBSD/LinuxThreads). Cela devrait être
corrigé en FreeBSD 5.0. Le symptôme est que les connexions
persistantes vont rester à bloquées très longtemps sans se
refermer.
Le processus de compilation de MySQL requiert GNU make
(gmake) pour fonctionner. Si vous voulez
compiler MySQL vous devez d'abord installer GNU
make.
La méthode recommandée pour compiler et installer MySQL sur
FreeBSD avec gcc (2.95.2 et plus récent)
est :
CC=gcc CFLAGS="-O2 -fno-strength-reduce" \
CXX=gcc CXXFLAGS="-O2 -fno-rtti -fno-exceptions \
-felide-constructors -fno-strength-reduce" \
./configure --prefix=/usr/local/mysql --enable-assembler
gmake
gmake install
cd /usr/local/mysql
bin/mysql_install_db --user=mysql
bin/mysqld_safe &
Si vous remarquez que configure va utiliser
MIT-pthreads, il faut alors lire les notes
MIT-pthreads. See
Section 2.4.5, « Notes relatives aux MIT-pthreads ».
Si vous avez une erreur durant make install
qui dit qu'il ne peut trouver
/usr/include/pthreads,
configure n'a pas détecté l'absence de
MIT-pthreads. Pour corriger le problème,
supprimez config.cache, puis relancez
configure avec l'option
--with-mit-threads.
Assurez-vous que votre configuration de la résolution des
noms est bonne. Sinon, vous airez peut-être quelques
problèmes lors de la connexion à mysqld.
Assurez-vous que l'entrée localhost dans
le fichier /etc/hosts est correcte
(sinon, vous aurez des problèmes pour vous connecter à la
base de données). Le fichier doit commencer par une ligne
similaire à :
127.0.0.1 localhost localhost.votre.domaine
FreeBSD est aussi connu pour avoir une petite limite de
gestionnaires de fichiers par défaut. See
Section A.2.17, « Fichier non trouvé ». Décommentez la
section ulimit -n dans
safe_mysqld ou enlevez la limite pour
l'utilisateur mysqld dans
/etc/login.conf (et regénèrez le avec
cap_mkdb). Assurez-vous aussi de définir la classe
appropriée pour cet utilisateur dans le fichier des mots de
passe si vous n'utilisez pas celui par défaut. (utilisez :
chpass nom-utilisateur-mysqld). See
Section 5.1.3, « safe_mysqld, le script père de
mysqld ».
Si vous avez beaucoup de mémoire, vous devriez penser à
recompiler le noyau pour permettre à MySQL d'utiliser plus de
512 Mo de RAM. Regardez l'option MAXDSIZ
dans le fichier de configuration de LINT pour plus
d'informations.
Si vous avez des problèmes avec la date courante dans MySQL,
configurer la variable d'environnement TZ
aidera sûrement. See Annexe E, Variables d'environnement.
Pour obtenir un système sécurisé et stable, vous ne devez
utiliser que les noyaux FreeBSD marqués
-RELEASE.
Pour compiler sur NetBSD vous aurez besoin de GNU
make. Sinon, la compilation stoppera
lorsque make essayera d'exécuter
lint sur les fichiers C++.
Dans la version 2.5 de OpenBSD, vous pouvez compiler MySQL avec les threads natifs avec les options suivantes :
CFLAGS=-pthread CXXFLAGS=-pthread ./configure --with-mit-threads=no
Nos utilisateurs nous ont informé que OpenBSD 2.8 comporte un bogue des threads qui pose quelques problèmes avec MySQL. Les développeurs d'OpenBSD ont résolu ce problème, mais depuis le 25 janvier 2001 ce n'est disponible que dans la branche ``-current''. Les symptômes de ce bogue sont : réponses lentes, beaucoup de charge, grande utilisation du CPU, et crashes.
Si vous obtenez une erreur comme Error in accept::
Bad file descriptor ou erreur 9 en essayant d'ouvrir
les tables ou les dossiers, le problème est probablement que
vous n'avez pas alloué assez de descripteurs de fichiers à
MySQL.
Dans ce cas, essayez de démarrer
safe_mysqld en tant que root avec les
options suivantes :
shell> mysqld_safe --user=mysql --open-files-limit=2048 &
Si vous obtenez l'erreur suivante lors de la compilation de
MySQL, votre valeur de ulimit pour la
mémoire virtuelle est trop petite :
item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)': item_func.h:28: virtual memory exhausted make[2]: *** [item_func.o] Error 1
Essayez d'utiliser ulimit -v 80000 et
exécutez make à nouveau. Si cela ne
fonctionne pas et que vous utilisez bash,
essayez de passer à csh ou
sh; quelques utilisateurs de BSDI ont
reporté des problèmes avec bash et
ulimit.
Si vous utilisez gcc, vous aurez peut-être
aussi à utiliser l'option --with-low-memory
de configure pour pouvoir compiler
sql_yacc.cc.
Si vous avez des problèmes avec la date courante dans MySQL,
configurer la variable TZ vous aidera
probablement. See Annexe E, Variables d'environnement.
Mettez à jour à la version 3.1 de BSD/OS. Si cela n'est pas possible, installez le patch BSDIpatch M300-038.
Utilisez la commande suivante lors de la configuration de MySQL :
shell>env CXX=shlicc++ CC=shlicc2 \./configure \--prefix=/usr/local/mysql \--localstatedir=/var/mysql \--without-perl \--with-unix-socket-path=/var/mysql/mysql.sock
Ce qui suit fonctionne aussi :
shell>env CC=gcc CXX=gcc CXXFLAGS=-O3 \./configure \--prefix=/usr/local/mysql \--with-unix-socket-path=/var/mysql/mysql.sock
Vous pouvez changer les répertoires si vous voulez, ou utiliser les valeurs par défaut en ne spécifiant pas de chemins.
Si vous avez des problèmes de performances alors que la
charge est petite, essayez d'utiliser l'option
--skip-thread-priority de
mysqld ! Cela exécutera tous les threads
avec la même priorité; Sur la version 3.1 de BSDI, cela
donne de meilleures performances (en attendant que BSDI
corrige sont gestionnaire de threads).
Si vous obtenez l'erreur virtual memory
exhausted durant la compilation, vous devez essayer
en utilisant ulimit -v 80000 et exécutant
make à nouveau. Si cela ne fonctionne pas
et que vous utilisez bash, essayez de
passer à csh ou sh;
quelques utilisateurs de BSDI ont reporté des problèmes avec
bash et ulimit.
Les versions 4.x de BSDI ont quelques
bogues relatifs aux threads. Si vous voulez utiliser MySQL sur
ce système, vous devez installer tous les patches liés aux
threads. vous devez au moins installer
M400-023.
Sur quelques systèmes avec une version 4.x de
BSDI, vous pouvez rencontrer des problèmes
avec les bibliothèques partagées. Le symptôme est que vous
ne pouvez utiliser aucun programme client, comme par exemple,
mysqladmin. Dans ce cas, vous devez le
reconfigurer pour qu'il n'utilise pas les bibliothèques
partagées avec l'option --disable-shared de
configure.
Quelques utilisateurs ont eu avec BSDI
4.0.1 un problème faisant qu'après un bout de temps, le
binaire mysqld ne peut plus ouvrir de
tables. Cela est du au fait qu'un bogue relatif au système ou
à la bibliothèque fait changer de répertoire à
mysqld sans qu'on ne l'ait demandé !
La solution est soit de mettre à jour vers la version 3.23.34
ou de supprimer la ligne #define
HAVE_REALPATH de config.h après
avoir exécuté configure et avant
d'exécuter make.
Notez que ce qui précède signifie que vous ne pouvez pas
créer de lien symbolique sur un dossier de bases de données
vers un autre dossier de bases de données ou lier une table
symboliquement vers une autre base de données sur
BSDI ! (Créer un lien symbolique vers un
autre disque fonctionne).
Tru64)
Il y a quelques petits problèmes que vous pourrez rencontrer
lors de la compilation de MySQL sur HP-UX. Nous recommandons
l'utilisation de gcc au lieu du compilateur
natif de HP-UX, car gcc produit un meilleur
code !
Nous recommandons l'utilisation de gcc 2.95 sur HP-UX. N'utilisez pas les options de haute optimisation (comme -O6) car cela pourrait ne pas être sûr sur HP-UX.
La ligne de configuration suivante devrait fonctionner avec gcc 2.95 :
CFLAGS="-I/opt/dce/include -fpic" \ CXXFLAGS="-I/opt/dce/include -felide-constructors -fno-exceptions \ -fno-rtti" CXX=gcc ./configure --with-pthread \ --with-named-thread-libs='-ldce' --prefix=/usr/local/mysql --disable-shared
La ligne de configuration suivante devrait fonctionner avec gcc 3.1 :
CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc \ CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors -fno-exceptions \ -fno-rtti -O3 -fPIC" ./configure --prefix=/usr/local/mysql \ --with-extra-charsets=complex --enable-thread-safe-client \ --enable-local-infile --with-pthread \ --with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC --disable-shared
Pour les version 11.x de HP-UX nous recommandons MySQL 3.23.15 ou plus récent.
A cause de quelques bogues critiques dans les bibliothèques standard de HP-UX, vous devez installer les correctifs suivants avant d'essayer de faire fonctionner MySQL sous HP-UX 11.0 :
PHKL_22840 Streams cumulative PHNE_22397 ARPA cumulative
Cela résoudra le problème de l'obtention de
EWOULDBLOCK à partir de
recv() et EBADF à
partir de accept() dans les applications
threadées.
Si vous utilisez gcc 2.95.1 sur un système
HP-UX 11.x non-corrigés, vous obtiendrez l'erreur :
In file included from /usr/include/unistd.h:11,
from ../include/global.h:125,
from mysql_priv.h:15,
from item.cc:19:
/usr/include/sys/unistd.h:184: declaration of C function ...
/usr/include/sys/pthread.h:440: previous declaration ...
In file included from item.h:306,
from mysql_priv.h:158,
from item.cc:19:
Le problème est que HP-UX ne définit pas
pthreads_atfork() avec cohérence. Il
possède des prototypes en conflit dans
/usr/include/sys/unistd.h:184 et
/usr/include/sys/pthread.h:440 (détails
ci-dessous).
Une solution est de copier
/usr/include/sys/unistd.h dans
mysql/include et éditer
unistd.h en le changeant pour qu'il
corresponde à la définition dans
pthread.h. Voici les modifications :
extern int pthread_atfork(void (*prepare)(), void (*parent)(),
void (*child)());
est remplacée par
extern int pthread_atfork(void (*prepare)(void), void (*parent)(void),
void (*child)(void));
Après cela, la ligne de configuration suivante devrait fonctionner :
CFLAGS="-fomit-frame-pointer -O3 -fpic" CXX=gcc \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O3" \ ./configure --prefix=/usr/local/mysql --disable-shared
Si vous utilisez MySQL 4.0.5 avec le compilateur HP-UX, vous pouvez utiliser : (testé avec cc B.11.11.04):
CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure --with-extra-character-set=complex
Vous pouvez ignorer toutes les erreurs de ce type :
aCC: warning 901: unknown option: `-3': use +help for online documentation
Si vous obtenez l'erreur suivante de
configure :
checking for cc option to accept ANSI C... no configure: error: MySQL requires a ANSI C compiler (and a C++ compiler). Try gcc. See the Installation chapter in the Reference Manual.
Vérifiez que le chemin vers le compilateur K&R ne précède pas le chemin vers le compilateur C et C++ HP-UX.
Une autre raison qui pourrait vous empêcher de compiler, et
le fait de n'avoir pas définit l'option
+DD64 ci-dessus.
La détection automatique de xlC est
absente de Autoconf, ce qui fait qu'un commande
configure comme celle qui suit est requise
lors de la compilation de MySQL (Cet exemple utilise le
compilateur IBM) :
export CC="xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 " export CXX="xlC_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192" export CFLAGS="-I /usr/local/include" export LDFLAGS="-L /usr/local/lib" export CPPFLAGS=$CFLAGS export CXXFLAGS=$CFLAGS ./configure --prefix=/usr/local \ --localstatedir=/var/mysql \ --sysconfdir=/etc/mysql \ --sbindir='/usr/local/bin' \ --libexecdir='/usr/local/bin' \ --enable-thread-safe-client \ --enable-large-files
Ce sont les options utilisées pour compiler la distribution de MySQL qui peut être trouvée sur http://www-frec.bull.com/.
Si vous changez le -O3 en
-O2 dans la ligne précédente, vous devez
aussi enlever l'option -qstrict (c'est une
limitation du compilateur IBM C).
Si vous utilisez gcc ou
egcs pour compiler MySQL, vous
devez utiliser l'option
-fno-exceptions, vu que la gestion des
exceptions de gcc/egcs
n'est pas sûre pour les threads ! (Cela est testé avec
egcs 1.1.) Il y a aussi quelques problèmes
connus avec l'assembleur d'IBM, qui peuvent lui faire
générer du mauvais code lors de son utilisation avec gcc.
Nous recommandons la ligne de configure
suivante avec egcs et gcc
2.95 sur AIX :
CC="gcc -pipe -mcpu=power -Wa,-many" \ CXX="gcc -pipe -mcpu=power -Wa,-many" \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory
Le -Wa,-many est nécessaire pour que la
compilation se passe sans problèmes. IBM est au courant de ce
problème mais n'est pas pressé de le corriger à cause de
l'existence du palliatif. Nous ne savons pas si
-fno-exceptions est requise avec
gcc 2.95, mais comme MySQL n'utilise pas
les exceptions et que l'option en question génère un code
plus rapide, nous vous recommandons de toujours utiliser cette
option avec egcs / gcc.
Si vous obtenez un problème avec le code de l'assembleur essayez en changeant l'option -mcpu=xxx pour l'adapter à votre processeur. Le plus souvent, on a besoin de power2, power, ou powerpc, et sinon 604 ou 604e. Je ne suis pas positif mais je pense que l'utilisation de "power" sera sûre la plupart du temps, même sur une machine power2.
Si vous ne savez pas quel est votre processeur, exécutez "uname -m", cela vous renverra une chaîne comme "000514676700", avec un format xxyyyyyymmss où xx et ss sont toujours des zéros, yyyyyy est un identifiant unique du système et mm est l'identifiant du CPU Planar. Une liste de ces valeurs peut être trouvée sur http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/uname.htm. Cela vous donnera un type et un modèle de machine que vous pouvez utiliser pour déterminer quel type de processeur vous avez.
Si vous avez des problèmes avec les signaux (MySQL se termine de manière imprévue lors des montées en charge) vous avez peut-être trouvé un bogue du système avec les threads et les signaux. Dans ce cas, vous pouvez demander à MySQL de ne pas utiliser les signaux en configuration avec :
shell>CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc \CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti \-DDONT_USE_THR_ALARM" \./configure --prefix=/usr/local/mysql --with-debug --with-low-memory
Cela n'affecte pas les performances de MySQL, mais comporte un
effet secondaire faisant en sorte que vous ne pourrez tuer les
clients en état ``sleeping'' sur une connexion avec
mysqladmin kill ou mysqladmin
shutdown. A la place, le client se terminera
lorsqu'il émmetra sa prochaine commande.
Sur quelques versions de AIX, lier avec
libbind.a fait vider son noyau à
getservbyname (core dump). Il s'agit d'un
bogue AIX et doit être remonté à IBM.
Pour AIX 4.2.1 et gcc vous devez apporter les modifications suivantes :
Après la configuration, éditez config.h
et include/my_config.h et changez la
ligne qui comporte
#define HAVE_SNPRINTF 1
en
#undef HAVE_SNPRINTF
Et finalement, dans mysqld.cc vous devez
ajouter un prototype pour initgoups.
#ifdef _AIX41 extern "C" int initgroups(const char *,int); #endif
Si vous avez besoin d'allouer beaucoup de mémoire au
processus mysqld, il ne suffit pas de configurer 'ulimit -d
unlimited'. Vous aurez aussi à configurer dans
mysqld_safe quelque chose comme :
export LDR_CNTRL='MAXDATA=0x80000000'
Vous trouverez plus d'informations sur l'utilisation d'une grande quantité de mémoire sur : http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/lrg_prg_support.htm.
Avec SunOS 4, les MIT-pthreads sont requis
pour compiler MySQL, ce qui signifie que vous aurez besoin de
GNU make.
Quelques systèmes SunOS 4 ont des problèmes avec les
bibliothèques dynamiques et libtool. Vous
pouvez utiliser la ligne suivante de
configure pour éviter ce problème :
shell> ./configure --disable-shared --with-mysqld-ldflags=-all-static
Lors de la compilation de readline, vous
pouvez obtenir des avertissements à propos de définitions
dupliquées. Vous pouvez les ignorer.
Lors de la compilation de mysqld, il y aura
quelques avertissements implicit declaration of
function. Vous pouvez les ignorer.
Si vous utilisez egcs 1.1.2 sur Digital
Unix, vous devez passer à gcc 2.95.2, car
egcs connaît de sérieux bogues sur DEC!
Lorsque vous compilez des programmes threadés sous Digital
Unix, la documentation recommande l'utilisation de l'option
-pthread avec cc et
cxx et les bibliothèques -lmach
-lexc (en plus de -lpthread).
Vous devriez exécuter le script configure
comme ceci :
CC="cc -pthread" CXX="cxx -pthread -O" \ ./configure --with-named-thread-libs="-lpthread -lmach -lexc -lc"
Lorsque vous compilez mysqld, vous pouvez
voir apparaître des alertes comme celles-ci :
mysqld.cc: In function void handle_connections()': mysqld.cc:626: passing long unsigned int *' as argument 3 of accept(int,sockadddr *, int *)'
Vous pouvez les ignorer tranquillement. Elles apparaissent car
configure ne peut détecter que des
erreurs, et pas des alertes.
Si vous démarrez le serveur directement en ligne de commande,
vous pouvez rencontrer des problèmes d'interruption si vous
vous déconnectez. Lorsque vous vous déconnectez, les
processus en cours re¸oivent le signal
SIGHUP. Si c'est le cas, essayez de
démarrer le serveur comme ceci :
shell> nohup mysqld [options] &
nohup fait que la commande suivante va
ignorer les signaux SIGHUP envoyés par le
terminal. Alternativement, vous pouvez démarrer le serveur
avec le script safe_mysqld, qui appelle le
démon mysqld avec l'option
nohup pour vous. See
Section 5.1.3, « safe_mysqld, le script père de
mysqld ».
Si vous avez des problèmes pour compiler
mysys/get_opt.c, vous pouvez simplement
supprimer la ligne #define _NO_PROTO au
début du fichier!
Si vous utilisez le compilateur cc de
Compaq, la ligne de configuration suivante
devrait fonctionner :
CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host" CXX="cxx -pthread" CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host \ -noexceptions -nortti" export CC CFLAGS CXX CXXFLAGS ./configure \ --prefix=/usr/local/mysql \ --with-low-memory \ --enable-large-files \ --enable-shared=yes \ --with-named-thread-libs="-lpthread -lmach -lexc -lc" gnumake
Si vous avez un problème avec libtool,
lorsque vous compilez les bibliothèques partagées, ou
lorsque vous compilez mysql, vous devriez
pouvoir résoudre ce problème avec :
cd mysql /bin/sh ../libtool --mode=link cxx -pthread -O3 -DDBUG_OFF \ -O4 -ansi_alias -ansi_args -fast -inline speed \ -speculate all \ -arch host -DUNDEF_HAVE_GETHOSTBYNAME_R \ -o mysql mysql.o readline.o sql_string.o completion_hash.o \ ../readline/libreadline.a -lcurses \ ../libmysql/.libs/libmysqlclient.so -lm cd .. gnumake gnumake install scripts/mysql_install_db
Si vous avez des problèmes de compilation et que le
CC de DEC et gcc sont
installés, essayez d'utiliser le script
configure comme ceci :
CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Si vous avez des problèmes avec le fichier
c_asm.h, vous pouvez créer un fichier
inerte c_asm.h avec :
touch include/c_asm.h CC=gcc CFLAGS=-I./include \ CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Notez que les problèmes suivants avec le programme
ld peuvent être corrigés en
téléchargeant le dernier kit de patch de DEC (Compaq) à :
http://ftp.support.compaq.com/public/unix/.
Su OSF/1 V4.0D et avec le compilateur DEC C V5.6-071
on Digital Unix V4.0 (Rev. 878) le compilateur
présente un comportement étrange (undefined asm
symbols). /bin/ld apparaît aussi
comme incorrect (problèmes avec des erreurs _exit
undefined survenant lors du link de
mysqld). Sur ce système, nous avons
réussi à compiler MySQL avec le script
configure suivant, après avoir remplacé
/bin/ld par la version de OSF 4.0C:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
Avec le compilateur Digital C++ V6.1-029,
la ligne suivante doit fonctionner :
CC=cc -pthread
CFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all \
-arch host
CXX=cxx -pthread
CXXFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all \
-arch host -noexceptions -nortti
export CC CFLAGS CXX CXXFLAGS
./configure --prefix=/usr/mysql/mysql --with-mysqld-ldflags=-all-static \
--disable-shared --with-named-thread-libs="-lmach -lexc -lc"
Avec certaines versions de OSF/1, la fonction
alloca() est boguée. Corrigez cela en
supprimant la ligne du fichier config.h
qui définit 'HAVE_ALLOCA'.
La fonction alloca() a aussi un prototype
incorrect dans /usr/include/alloca.h.
L'alerte en résultant peut être ignorée.
Le script configure va utiliser
automatiquement les bibliothèques de threads suivantes :
--with-named-thread-libs="-lpthread -lmach -lexc
-lc".
En utilisant gcc, vous pouvez aussi essayer
le script configure avec ceci :
shell> CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ...
Si vous avez des problèmes avec les signaux (MySQL s'arrête inopinément sous forte charge), vous pouvez avoir rencontré un bogue de l'OS avec les threads, et les signaux. Dans ce cas, vous pouvez indiquer à MySQL de ne pas utiliser les signaux avec la configuration suivante :
shell>CFLAGS=-DDONT_USE_THR_ALARM \CXXFLAGS=-DDONT_USE_THR_ALARM \./configure ...
Cela ne modifie pas les performances de MySQL, mais vous ne
pourrez plus terminer les clients qui sont en mode
``sleeping'' sur une connexion avec la commande
mysqladmin kill ou mysqladmin
shutdown. Au lieu de cela, le client sera interrompu
lorsqu'il émettra la prochaine commande.
Avec gcc 2.95.2, vous aurez probablement
les problèmes de compilation suivants :
sql_acl.cc:1456: Internal compiler error in `scan_region', at except.c:2566 Please submit a full bug report.
Pour corriger cela, vous devez aller dans le dossier
sql et faire un ``copier coller'' de la
dernière ligne gcc, tout en rempla¸ant le
code -O3 par le code -O0
ou ajouter le code -O0 immédiatement
après gcc si vous n'avez aucune option
-O sur votre ligne de compilation). Après
cela, vous pouvez retourner au niveau de la racine de MySQL,
et tenter à nouveau un make.
Si vous utilisez la version 6.5.3 d'Irix ou plus récente,
mysqld ne pourra créer de threads que si
vous l'exécutez en tant qu'utilisateur possédant le
privilège CAP_SCHED_MGT (comme
root) ou que vous donnez au serveur
mysqld ce privilège avec la commande
suivante :
shell> chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld
Vous devrez peut-être supprimer quelques définitions dans
config.h après avoir exécuté
configure et avant de compiler.
Sur quelques implémentations d'Irix, la fonction
alloca() ne marche pas. Si le serveur
mysqld se stoppe sur quelques requêtes
SELECT, supprimez les lignes de
config.h qui définissent
HAVE_ALLOC et
HAVE_ALLOCA_H. Si mysqladmin
create ne fonctionne pas, supprimez la ligne qui
définit HAVE_READDIR_R dans
config.h. Vous devrez peut-être
supprimer la ligne de HAVE_TERM_H aussi.
SGI recommande que vous installiez tous les patches de cette page : http://support.sgi.com/surfzone/patches/patchset/6.2_indigo.rps.html
Vous devrez, au moins, installer la dernière version du
noyau, de rld et de
libc.
Vous avez besoin de tous les patches POSIX sur cette page, pour le support des pthreads :
http://support.sgi.com/surfzone/patches/patchset/6.2_posix.rps.html
Si vous obtenez une erreur se rapprochant de la suivante lors
de la compilation de mysql.cc:
"/usr/include/curses.h", line 82: error(1084): invalid combination of type
Tapez ce qui suit dans le répertoire racine de votre source MySQL :
shell>extra/replace bool curses_bool < /usr/include/curses.h \> include/curses.hshell>make
Un problème de planification a aussi été signalé. Si seul un thread est en cours, les choses ralentissent. Evitez cela en démarrant un autre client. Cela pourra accélérer l'exécution de l'autre thread de 2 à 10 fois. Ceci est un problème pas encore très clair avec les threads Irix; vous devrez improviser pour trouver des solutions en attendant que cela soit corrigé.
Si vous compilez avec gcc, vous pouvez
utiliser la commande configure suivante :
CC=gcc CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql --enable-thread-safe-client \ --with-named-thread-libs=-lpthread
Sous Irix 6.5.11 avec les compilateurs natifs Irix C et C++ versions 7.3.1.2, ce qui suit est connu pour fonctionner :
CC=cc CXX=CC CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include \ -L/usr/local/lib' CXXFLAGS='-O3 -n32 -TARG:platform=IP22 \ -I/usr/local/include -L/usr/local/lib' ./configure \ --prefix=/usr/local/mysql --with-innodb --with-berkeley-db \ --with-libwrap=/usr/local \ --with-named-curses-libs=/usr/local/lib/libncurses.a
Le port actuel est testé uniquement sur les systèmes ``sco3.2v5.0.5'', ``sco3.2v5.0.6'' et ``sco3.2v5.0.7''. Il y a aussi eu des progrès sur le port vers ``sco 3.2v4.2''.
Pour le moment, le compilateur recommandé sur OpenServer est
gcc 2.95.2. Avec lui, vous devriez être
capable de compiler MySQL simplement avec :
CC=gcc CXX=gcc ./configure ... (options)
Pour OpenServer 5.0.x, vous avez besoin de
gcc-2.95.2p1 ou plus récent, de
Skunkware.
http://www.sco.com/skunkware/
puis recherchez dans les paquets OpenServer ou par FTP sur
ftp2.caldera.com, dans le dossier
pub/skunkware/osr5/devtools/gcc.
Vous avez besoin de GCC 2.5.x pour ce
produit, et du système de développement. Ils sont
nécessaires sur cette version de Unix SCO. Vous ne pouvez
pas simplement utiliser GCC Dev.
Vous devriez installer le paquet FSU
Pthreads et l'installer. Il peut être trouvé
à l'adresse :
http://moss.csc.ncsu.edu/~mueller/ftp/pub/PART/pthreads.tar.gz.
Vous pouvez aussi obtenir un paquet precompilé sur
http://www.mysql.com/Downloads/SCO/FSU-threads-3.5c.tar.gz.
Les FSU Pthreads peuvent être compilé
sur SCO Unix 4.2 avec TCP/IP. Ou OpenServer 3.0 ou Open
Desktop 3.0 (OS 3.0 ODT 3.0), avec le SCO
Development System, installé avec le bon port
de GCC 2.5.x ODT ou OS 3.0 avec le bon port de GCC 2.5.x
Il y a beaucoup de problèmes si vous n'utilisez pas le
bon port. Le port de ce produit requiert le SCO
Unix Development. Sans cela, il vous manque des
bibliothèques et le linker nécessaire.
Pour compiler FSU Pthreads sur votre
système, faîtes ceci :
Exécutez ./configure dans le
dossier threads/src et
sélectionnez l'option SCO OpenServer. Cette commande
copie Makefile.SCO5 dans le
fichier Makefile.
Exécutez make.
Pour installer le paquet dans le dossier par défaut
/usr/include, identifiez vous
comme root, puis utilisez cd pour
vous placer dans le dossier
thread/src, et faites
make install.
N'oubliez pas d'utiliser GNU make lors
de la compilation de MySQL.
Si vous ne lancez pas mysqld_safe en
tant que root, vous obtiendrez
probablement un maximum de 110 fichiers ouverts par
processus. mysqld vous le dira dans les
logs.
Avec SCO 3.2V5.0.5, il est recommandé d'utiliser
FSU Pthreads version 3.5c ou plus
récent. Il est recommandé d'utiliser
gcc 2.95.2 ou plus récent!
La commande configure devrait
fonctionner :
shell> ./configure --prefix=/usr/local/mysql --disable-shared
Avec SCO 3.2V4.2, il est recommandé d'utiliser
FSU Pthreads version 3.5c ou plus
récent. La commande configure devrait
fonctionner :
shell>CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \./configure \--prefix=/usr/local/mysql \--with-named-thread-libs="-lgthreads -lsocket -lgen -lgthreads" \--with-named-curses-libs="-lcurses"
Vous pourriez rencontrer des problèmes avec certains
fichiers à inclure. Dans ce cas, vous pouvez trouver des
fichiers spécifiques pour SCO à l'adresse
http://www.mysql.com/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz.
Il suffit de décompresser le fichier dans le dossier
include de votre dossier source
MySQL.
Notes de développement SCO :
MySQL doit automatiquement détecter le paquet
FSU Pthreads et l'utiliser pour
compiler mysqld avec
-lgthreads -lsocket -lgthreads.
Les bibliothèques de développement SCO sont re-entrantes
avec les FSU Pthreads. SCO affirme que
ses bibliothèques sont ré-entrantes, donc elles sont
aussi ré-entrantes avec les FSU
Pthreads. FSU Pthreads sur
OpenServer essaie d'utiliser les concepts SCO pour rendre
ses bibliothèques ré-entrantes.
FSU Pthreads (tout au moins, la version
de http://www.mysql.com/) est livré avec GNU
malloc. Si vous rencontrez des
problèmes avec l'utilisation de la mémoire, assurez-vous
que le fichier gmalloc.o est inclus
dans libgthreads.a et
libgthreads.so.
Avec les FSU Pthreads, les appels
système suivants sont compatibles avec les pthreads :
read(), write(),
getmsg(), connect(),
accept(), select()
et wait().
Le patch CSSA-2001-SCO.35.2 (le patch est nommé
erg711905-dscr_remap security patch
(version 2.0.0)) bloque les FSU
Pthreads et rend mysqld
instable. Vous devez le supprimer si vous voulez faire
fonctionner mysqld sur une machine
OpenServer 5.0.6.
SCO fournit des patches pour son système d'exploitation à l'adresse ftp://ftp.sco.com/pub/openserver5 pour OpenServer 5.0.x
SCO fournit des patches de sécurités et la bibliothèque
libsocket.so.2 à l'adresse
ftp://ftp.sco.com/pub/security/OpenServer
et
ftp://ftp.sco.com/pub/security/sse
pour OpenServer 5.0.x
Patch de sécurité avant OSR506. De même, le patch
telnetd de
ftp://stage.caldera.com/pub/security/openserver/
ou
ftp://stage.caldera.com/pub/security/openserver/CSSA-2001-SCO.10/
ainsi que libsocket.so.2 et
libresolv.so.1 ont des instructions
concernant leur installation sur un système pre-OSR506.
C'est probablement une bonne idée que d'installer les patches de sécurité ci-dessus avant de compiler et d'utiliser MySQL.
Sur UnixWare 7.1.0, vous devez utiliser une version de MySQL au moins aussi récente que la 3.22.13 pour avoir les correctifs sur cet OS.
Nous avons réussi à compiler MySQL avec la commande de
configuration suivante configure sur
UnixWare Version 7.1.x:
CC=cc CXX=CC ./configure --prefix=/usr/local/mysql
Si vous voulez utiliser gcc, vous devez
utiliser gcc 2.95.2 ou plus récent.
CC=gcc CXX=g++ ./configure --prefix=/usr/local/mysql
SCO fournit des patchs pour son OS à ftp://ftp.sco.com/pub/unixware7 pour UnixWare 7.1.1 et 7.1.3 et à ftp://ftp.sco.com/pub/openunix8 pour OpenUNIX 8.0.0.
SCO fournit des informations sur les correctifs de sécurité à ftp://ftp.sco.com/pub/security/OpenUNIX pour OpenUNIX et à ftp://ftp.sco.com/pub/security/UnixWare pour UnixWare.
MySQL utilise un certain nombre de fichiers ouverts. A cause de
cela, vous devez ajouter un ligne se rapprochant de la suivante
dans votre fichier CONFIG.SYS :
SET EMXOPT=-c -n -h1024
Si vous ne le faites pas, vous obtiendrez probablement l'erreur :
File 'xxxx' not found (Errcode: 24)
Lors de l'utilisation de MySQL avec OS/2 Warp 3, FixPack 29 ou plus est requis. Avec OS/2 Warp 4, FixPack 4 ou plus est requis. C'est un besoin de la bibliothèque des Pthreads. MySQL doit être installé sur une partition qui supporte les noms de fichiers longs, tel que HPFS, FAT32, etc.
Le script INSTALL.CMD doit être exécuté
à partir du CMD.EXE d'OS/2 et ne
fonctionnera probablement pas avec des substituts tels que
4OS2.EXE.
Le script scripts/mysql-install-db a été
renommé. Il est maintenant nommé
install.cmd et est un script REXX, qui
mettra en place les configurations de sécurité par défaut de
MySQL et créera les icônes WorkPlace Shell pour MySQL.
Le support des module dynamiques est compilé, mais n'est pas assez testé. Les modules dynamiques doivent être compilés en utilisant la bibliothèque pthreads.
gcc -Zdll -Zmt -Zcrtdll=pthrdrtl -I../include -I../regex -I.. \
-o exemple udf_exemple.cc -L../lib -lmysqlclient udf_exemple.def
mv exemple.dll exemple.udf
Note : A cause des limitations
de OS/2, les noms des modules UDF ne doivent
pas dépasser 8 caractères. Les modules sont stockés dans le
répertoire /mysql2/udf; le script
safe-mysqld.cmd placera ce répertoire dans
la variable d'environnement BEGINLIBPATH.
Lors de l'utilisation des modules UDF, les
extensions spécifiées sont ignorées. Elle est supposée être
.udf. Par exemple, sous Unix, le module
partagé peut se nommer exemple.so et vous
chargeriez une de ses fonctions de la fa¸on suivante :
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "exemple.so";
Sous OS/2, me module s'appellera
exemple.udf, mais vous n'aurez pas à
spécifier son extension :
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "exemple";
Nous sommes vraiment intéressés par le port de MySQL sur BeOS, mais malheureusement, nous n'avons personne qui s'y connaisse en BeOS ou qui ait le temps de s'en occuper.
Nous sommes intéressés par quelqu'un qui serait prêt à faire le port, et nous l'aiderions pour toutes les questions techniques qu'il pourrait se poser durant le processus.
Nous avons déjà eu des contacts avec des développeurs BeOS qui ont dit que MySQL était porté à 80% sur BeOS, mais nous n'avons plus entendu parler d'eux depuis.
Le support MySQL par Perl est fournis grâce à l'interface
DBI/DBD. Cette interface
requiert Perl Version 5.6.0 ou plus récent. Elle
fonctionnera pas si vous avez une autre
version plus ancienne de Perl.
Si vous voulez utiliser les transactionsa vec Perl
DBI, vous devez installer
DBD::mysql version 1.2216 ou plus récent. La
version 2.9003 ou plus récent est recommandée.
Notez que si vous utilisez la bibliothèque client MySQL 4.1, vous
devrez utiliser DBD::mysql 2.9003 ou plus
récent.
Depuis la version 3.22.8, le support de Perl n'est plus inclut
dans les distribution de MySQL. Vous pouvez obtenir les modules
requis sur le site
http://search.cpan.org
pour Unix, ou sur le site de ActiveState (fichiers
ppm) pour Windows. La section suivante décrit
comment faire.
Le support de MySQL par Perl doit être installé si vous voulez exécuter les scripts de tests de performances. See Section 7.1.4, « La suite de tests MySQL ».
Le support Perl de MySQL requièrt que vous ayez installé le
support de programmation de clients pour MySQL. Si vous avez
installé MySQL à partir de fichiers RPM,
les programmes clients sont dans le RPM
client, mais le support de la programmation de clients est dans
le RPM des développeurs. Assurez-vous
d'avoir installé le dernier RPM.
Si vous voulez installer le support Perl, les fichiers dont vous avez besoin sont disponible sur la bibliothèque CPAN (Comprehensive Perl Archive Network) à http://search.cpan.org.
Le moyen le plus facile pour installer le module Unix de Perl et
d'utilise le module CPAN. Par exemple :
shell> perl -MCPAN -e shell
cpan> install DBI
cpan> install DBD::mysql
L'installation de DBD::mysql effectue de
nombreux tests. Ces tests requièrent une connexion local au
serveur MySQL, en tant qu'utilisateur anonyme, sans mot de
passe. Si vous avez supprimé l'accès anonyme, ou assigné des
mots de passe, les tests échoueront. Vous pouvez utiliser
force install DBD::mysql pour ignorer ces
tests.
DBI requiert le module
Data::Dumper. Il peut être déjà installé.
Si non, vous devez l'installer avant d'installer
DBI.
Il est aussi possible de télécharger la distribution module
sous la forme d'une archive tar compressée,
et de compiler manuellement les modules. Par exemple, pour
décompresser et construire la distribution
DBI, utilisez cette procédure :
Décompressez la distribution dans le dossier courant :
shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf -
Cette commande crée un dossier appelé
Data-Dumper-VERSION.
Mettez vous dans le répertoire racine de la distribution décompressée :
shell> cd DBI-VERSION
Construisez la distribution et compilez tout :
shell>perl Makefile.PLshell>makeshell>make testshell>make install
La commande make test est importante car elle
vérifie que le module fonctionne. Notez que quand vous
exécutez cette commande durant l'installation de
Msql-Mysql-modules pour tester le code de
l'interface, le serveur MySQL doit être en marche sinon le test
échouera.
Il est bon de reconstruire et réinstaller la distribution
Msql-Mysql-modules à chaque fois que vous
réinstallez une nouvelle version de MySQL, particulièrement si
vous avez des problèmes avec vos scripts DBI
après avoir avoir mis à jour MySQL.
Si vous n'avez pas le droit d'installer des modules Perl dans le dossier système ou que vous voulez installer des modules locaux de Perl, la référence suivante pourra vous aider : http://www.iserver.com/support/contrib/perl5/modules.html
Regardez le paragraphe ``Installing New Modules that Require Locally Installed Modules.''
Pour installer le module DBD MySQL avec
ActiveState Perl sous Windows, vous devez faire ce qui suit :
Obtenez ActiveState Perl à partir de http://www.activestate.com/Products/ActivePerl/ et installez le.
Ouvrez un terminal DOS.
Si requis, définissez la variable HTTP_proxy. Par exemple, vous pouvez faire :
set HTTP_proxy=my.proxy.com:3128
Démarrez le programme PPM :
C:\> c:\perl\bin\ppm.pl
Installez DBI, si ce n'est pas déjà
fait :
ppm> install DBI
Si cela fonctionne, exécutez la commande suivante :
install \ ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd
Ce qui suit devrait fonctionner avec la version 5.6 d'ActiveState Perl.
Si ce qui précède ne veut pas fonctionner, vous devez à la
place installer le pilote MyODBC et vous
connecter au serveur MySQL via ODBC :
use DBI;
$dbh= DBI->connect("DBI:ODBC:$dsn","$utilisateur","$motdepasse") ||
die "Obtenu l'erreur $DBI::errstr lors de la connexion à $dsn\n";
Si Perl vous informe qu'il ne peut trouver le module
../mysql/mysql.so, il se trouve
probablement que Perl n'arrive pas à trouver la bibliothèque
partagée libmysqlclient.so.
Vous pouvez corriger cela en suivant l'une des méthodes suivantes :
Compilez la distribution
Msql-Mysql-modules avec perl
Makefile.PL -static -config au lieu de
perl Makefile.PL.
Copiez libmysqlclient.so dans le
dossier où se situent vos autres bibliothèques partagées
(souvent /usr/lib ou
/lib).
Modifiez l'option -L utilisée pour
compiler DBD::mysql pour refléter le
chemin correct de libmysqlclient.so.
Sous Linux vous pouvez ajouter le chemin vers le dossier
dans lequel se trouve libmysqlclient.so
au fichier /etc/ld.so.conf.
Ajoutez le chemin complet vers le dossier où se situe
libmysqlclient.so à la variable
d'environnement LD_RUN_PATH.
Notez que vous aurez aussi besoin de modifier les options
-L s'il y a d'autres bibliothèques que le
linker ne peut trouver. Par exemple, si le linker ne peut
trouver libc comme il est dans
/lib et que la commande de link spécifie
-L/usr/lib, modifiez l'option
-L en -L/lib ou ajoutez
l'option -L/lib à la commande de link
existante.
Si vous obtenez l'erreur suivante de
DBD-mysql, vous utilisez probablement
gcc (ou un vieux binaire compilé avec
gcc) :
/usr/bin/perl: can't resolve symbol '__moddi3' /usr/bin/perl: can't resolve symbol '__divdi3'
Ajoutez -L/usr/lib/gcc-lib/... -lgcc à la
commande de liaison lorsque la bibliothèque
mysql.so est construite (vérifiez
l'affichage de make concernant
mysql.so quand vous compilez le client
Perl). L'option -L doit spécifier le chemin
vers le dossier où se situe libgcc.a sur
votre système.
Une autre cause du problème peut être que Perl et MySQL ne
sont pas tous deux compilés avec gcc. Dans
ce cas là, vous devrez faire en sorte qu'ils le soient.
Si vous obtenez les erreurs suivantes de la part de
Msql-Mysql-modules quand vous exécutez ces
tests :
t/00base............install_driver(mysql) failed: Can't load '../blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql: ../blib/arch/auto/DBD/mysql/mysql.so: undefined symbol: uncompress at /usr/lib/perl5/5.00503/i586-linux/DynaLoader.pm line 169.
cela signifie que vous avez besoin d'inclure la bibliothèque
dynamique, -lz, dans la ligne de liaison. Cela peut se faire en
changeant ce qui suit dans
lib/DBD/mysql/Install.pm :
$sysliblist .= " -lm";
en
$sysliblist .= " -lm -lz";
Après cela, vous devez exécuter 'make realclean' et reprendre l'installation dès le début.
Si vous voulez installer DBI sur SCO, vous
devez éditer le fichier Makefile de
DBI-xxx et chaque sous-dossier.
Notez que gcc doit être en version 2.95.2 ou
plus récente :
ANCIEN: NOUVEAU: CC = cc CC = gcc CCCDLFLAGS = -KPIC -W1,-Bexport CCCDLFLAGS = -fpic CCDLFLAGS = -wl,-Bexport CCDLFLAGS = LD = ld LD = gcc -G -fpic LDDLFLAGS = -G -L/usr/local/lib LDDLFLAGS = -L/usr/local/lib LDFLAGS = -belf -L/usr/local/lib LDFLAGS = -L/usr/local/lib LD = ld LD = gcc -G -fpic OPTIMISE = -Od OPTIMISE = -O1 OLD: CCCFLAGS = -belf -dy -w0 -U M_XENIX -DPERL_SCO5 -I/usr/local/include NEW: CCFLAGS = -U M_XENIX -DPERL_SCO5 -I/usr/local/include
Ceci est dû au fait que le chargeur dynamique de Perl ne va pas
charger les modules DBI, s'ils sont compilés
avec icc ou cc.
Si vous voulez utiliser le module de Perl sur un système qui ne
supporte pas les liaisons dynamiques (comme Caldera/SCO) vous
pouvez générer une version statique de Perl incluant
DBI et DBD-mysql.
L'approche est de générer une version de Perl avec le code de
DBI lié et de l'installer au dessus de votre
Perl courant. Puis vous utilisez cette version pour en créer à
nouveau une autre qui comporte le code de DBD
lié et d'installer cette version ci.
Sur Caldera (SCO), vous devez définir les variables d'environnement suivantes :
shell> LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
ou :
shell>LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\/usr/progressive/lib:/usr/skunk/libshell>LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\/usr/progressive/lib:/usr/skunk/libshell>MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:\/usr/skunk/man:
D'abord, créez un Perl incluant un DBI lié
statiquement en exécutant des commandes dans le dossier où se
situe votre distribution DBI :
shell>perl Makefile.PL -static -configshell>makeshell>make installshell>make perl
Ensuite, vous devez installer le nouveau Perl. Les affichages de
make perl vous indiqueront les commandes
make exactes que vous aurez besoin
d'exécuter pour faire l'installation. Sur Caldera (SCO), il
s'agit de make -f Makefile.aperl inst_perl
MAP_TARGET=perl.
Puis, utilisé le Perl qui vient d'être créé pour en créer
un nouveau qui inclut un DBD::mysql lié
statiquement en exécutant ces commandes dans le dossier où
votre distribution de Msql-Mysql-modules se
situe :
shell>perl Makefile.PL -static -configshell>makeshell>make installshell>make perl
Finalement, vous devez installer ce nouveau Perl. Une fois de
plus, l'affichage de make perl vous indiquera
la commande à utiliser.