2.4.2 Procédures de post-installation sous Unix
2.4 Procédure de post-installation
2 Installer MySQL
Manuel de Référence MySQL 4.1 : Version Française
. Problèmes d'exécution de mysql_install_db
. Lancer et arrêter MySQL automatiquement
->Problèmes de démarrage du serveur MySQL
|
2.4.2.3 Problèmes de démarrage du serveur MySQL
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.
Configuration
InnoDB
.
-
Si vous utilisez les tables
BDB
(Berkeley DB), vous devez vous familiariser
avec les différentes options spécifiques à
BDB
.
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/var
shell> 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.err
shell> 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 Utiliser plusieurs serveurs 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 :
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
.
Créer des fichiers de traçage .
|