Sommaire 27 Historique des changements MySQL
2.4 Procédure de post−installation
2.4.2 Procédures de post−installation sous Un
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 :
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
. Créer des fichiers de traçage .