Assurez vous que le serveur fonctionne. S'il ne fonctionne pas, vous ne pourrez pas vous y connecter. Par exemple, si vous tentez de vous connecter au serveur, et que vous recevez un message comme celui-ci, c'est peut-être que le serveur ne fonctionne pas :

shell> mysql
ERROR 2003: Can't connect to MySQL server on 'host_name' (111)
shell> mysql
ERROR 2002: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (111)

Il se peut aussi que le serveur fonctionne, mais que vous essayez de vous connecter en utilisant un port TCP/IP, un pipe nommé ou un fichier de socket Unix qui n'est pas celui que le serveur utilise. Pour corriger cela, lorsque vous utilisez un client, spécifiez l'option --port pour indiquer le bon port, et l'option --socket pour indiquer le bon fichier de socket Unix ou le pipe nommé Windows. Pour connaître le port utilisé, et le chemin jusqu'à la socket, vous pouvez utiliser cette commande :

shell> netstat -l | grep mysql

Les tables de droits doivent être correctement configurée pour que le serveur les utilise lors de l'identification. Les installations Windows qui utilisent une distribution binaire ou les installations binaires Unix RPM initialisent automatiquement la base mysql contenant les tables de droits. Pour les autres types d'installation, vous devez initialiser les tables de droits manuellement, avec le script mysql_install_db. Pour plus de détails, voyez Section 2.5.2, « Procédures de post-installation sous Unix ».

Un moyen de déterminer si vous avez besoin d'initialiser les tables de droits est de regarder dans le dossier mysql dans le dossier de données. Le dossier de données s'appelle data ou var et est situé dans le dossier d'installation de MySQL. Assurez vous que vous avez un fichier appelé user.MYD dans le dossier mysql. Si vous ne le trouvez pas, exécutez le script mysql_install_db. Après exécution de ce script, et redémarrage du serveur, testez les premiers droits avec la commande :

shell> mysql -u root test

Le serveur doit vous laisser vous connecter sans erreur.

Après une installation toute fraîche, vous devez vous connecter au serveur et créer les utilisateurs en réglant leurs permissions d'accès :

shell> mysql -u root mysql

Le serveur devrait vous laisser vous connecter car l'utilisateur root de MySQL n'a pas de mot de passe initial. Ceci est aussi une faille de sécurité, et donc, vous devez choisir un mot de passe pour l'utilisateur root en même tant que les autres utilisateurs MySQL. Pour des instructions sur la configuration des mots de passe initiaux, voyez la section Section 2.5.3, « Création des premiers droits MySQL ».

Si vous avez mis à jour une version de MySQL avec une nouvelle versions, avez-vous utilisé le script mysql_fix_privilege_tables? Si ce n'est pas le cas, faîtes-le. La structure des tables de droits change occasionnellement, lorsque de nouvelles fonctionnalités sont ajoutées : après une mise à jour, assurez-vous que vos tables ont la bonne structure. Pour des instructions, voyez Section 2.6.7, « Mise à jour des tables de droits ».

Si un programme client re¸oit l'erreur suivante lorsqu'il essaie de se connecter, cela signifie que le serveur attend un mot de passe dans un nouveau format, alors que le client fournit un ancien format :

shell> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

Pour des informations sur comment traiter ce type de situations, voyez Section 5.5.9, « Hashage de mots de passe en MySQL 4.1 » et Section A.2.3, « Erreur Client does not support authentication protocol ».

Si vous essayez de vous connecter en tant que root et que vous recevez l'erreur suivante, cela signifie que vous n'avez pas d'entrée dans la table user avec une valeur 'root' dans la colonne User et que mysqld ne peut pas résoudre le nom d'hôte du client :

Access denied for user: ''@'unknown' to database mysql

Dans ce cas, vous devez relancer le serveur avec l'option --skip-grant-tables, et éditer votre fichier /etc/hosts ou \windows\hosts pour ajouter une ligne vous votre hôte.

N'oubliez pas que les clients utilisent les paramètres de connexions placés dans les fichiers d'options ou les variables d'environnement. Si un client semble envoyer des paramètres de connexions invalides, lorsque vous n'en spécifiez aucun, vérifiez votre environnement, et les options appropriées. Par exemple, si vous recevez l'erreur Access denied avec un client utilisé sans option, assurez vous que vous n'avez pas spécifié un ancien mot de passe dans vos anciens fichiers d'options.

Vous pouvez supprimer l'utilisation des fichiers d'options d'un client en utilisant l'option --no-defaults. Par exemple :

shell> mysqladmin --no-defaults -u root version

Le fichier d'option que les clients utilisent sont listés dans la section Section 4.3.2, « Fichier d'options my.cnf ». Les variables d'environnement sont listées dans Annexe E, Variables d'environnement.

Si vous obtenez une erreur qui ressemble à celle-ci :

shell> mysqladmin -u root -pxxxx ver
Access denied for user: 'root'@'localhost' (Using password: YES)

Cela signifie que vous utilisez un mot de passe erroné.

Si l'erreur précédente survient lorsque vous n'avez pas spécifié de mot de passe, cela signifie que vous n'avez pas spécifié de mot de passe dans un fichier d'options. Essayez l'option --no-defaults telle décrit ci-dessus.

Pour des informations sur les changements de mot de passe, voyez Section 5.6.5, « Configurer les mots de passe ».

Si vous avez oublié le mot de passe root, vous pouvez redémarrer mysqld avec --skip-grant-tables pour changer le mot de passe. See Section A.4.1, « Comment réinitialiser un mot de passe Root oublié ».

Si vous n'arrivez pas à faire fonctionner votre mot de passe, souvenez-vous que vous devez utiliser la fonction PASSWORD() si vous le changez avec les commandes INSERT, UPDATE, ou SET PASSWORD. L'utilisation de la fonction PASSWORD() n'est pas nécessaire si vous spécifiez le mot de passe en utilisant la commande GRANT ... INDENTIFIED BY ou la commande mysqladmin password. See Section 5.6.5, « Configurer les mots de passe ».

mysql> SET PASSWORD FOR 'abe'@'host_name' = 'eagle';

A la place, utilisez cette commande :

mysql> SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');

La fonction PASSWORD() n'est pas nécessaire si vous spécifiez un mot de passe avec la commande GRANT ou la commande en ligne mysqladmin password, qui utilisent automatiquement PASSWORD() pour chiffrer le mot de passe.

localhost est un synonyme de votre nom d'hôte local, et est aussi l'hôte par défaut auquel le client essaye de se connecter si vous n'en spécifiez pas un explicitement. Toutefois, les connexions à localhost ne fonctionnent pas si vous utilisez une version antérieure à la 3.23.27 qui utilise les MIT-pthreads.

Pour contourner ce problème sur de tels systèmes, vous devez utiliser l'option --host pour nommer l'hôte du serveur explicitement. Cela créera une connexion TCP/IP vers le serveur mysqld. Dans ce cas, vous devez avoir votre vrai nom d'hôte dans les entrées de la table user du serveur hôte. (Cela est vrai même si vous utilisez un programme client sur la même machine que le serveur.)

Si vous obtenez une erreur Access denied lorsque vous essayez de vous connecter à la base de données avec mysql -u nom_utilisateur nom_base, vous pouvez avoir un problème dans la table user. Vérifiez le en vous exécutant mysql -u root mysql et entrant la commande SQL suivante :

mysql> SELECT * FROM user;

Le résultat devrait comprendre une entrée avec les colonnes Host et User correspondante au nom d'hôte de votre ordinateur et votre nom d'utilisateur MySQL.

Le message d'erreur Access denied vous dira en tant que qui vous essayez de vous identifier, l'hôte à partir duquel vous voulez le faire, et si vous utilisez ou pas un mot de passe. Normalement, vous devez avoir une entrée dans la table user qui correspondent au nom d'hôte et nom d'utilisateur donnés dans le message d'erreur. Par exemple, si vous obtenez une erreur qui contient Using password: NO, cela signifie que vous avez essayé de vous connecter sans mot de passe.

Si vous obtenez l'erreur suivante en essayant de vous connecter à partir d'un hôte différent de celui sur lequel est placé le serveur, c'est qu'il n'y a pas d'enregistrement dans la table user qui correspond à cet hôte :

Host ... is not allowed to connect to this MySQL server

Vous pouvez corriger ce problème en configurant un compte avec la combinaison hôte / nom d'utilisateur que vous utilisez lors de la connexion.

Si vous ne connaissez ni l'IP ni le nom d'hôte à partir duquel vous essayez de vous connecter, vous devez créer une entrée avec '%' dans la colonne Host dans la table user et redémarrer mysqld avec l'option --log sur la machine serveur. Après avoir essayé à nouveau de vous connecter à partir de la machine cliente, les informations contenues dans le log de MySQL vous apprendront comment vous vous êtes vraiment connectés. (Remplacez alors l'entrée de la table user contenant '%' avec le nom d'hôte qui apparaît dans le log. Sinon, vous aurez un système non-sécurisé.)

Une autre raison pour cette erreur sous Linux est que vous utilisez une version binaire de MySQL qui est compilée avec une version de glibc différente de celle que vous utilisez. Dans ce cas, vous devez soit mettre à jour votre système d'exploitation et sa bibliothèque glibc, soit télécharger les sources de MySQL et les compiler vous-même. Un RPM de sources est normalement facile à compiler et installer, cela ne devrait donc pas vous poser de gros problèmes.

Si vous obtenez une erreur où le nom d'hôte est absent ou que celui-ci est une adresse IP alors que vous avez bien entré le nom d'hôte :

shell> mysqladmin -u root -pxxxx -h some-hostname ver
Access denied for user: 'root@' (Using password: YES)

Cela signifie que MySQL a rencontré des erreurs lors de la résolution de l'IP du nom d'hôte. Dans ce cas, vous pouvez exécuter mysqladmin flush-hosts pour vider le cache interne des DNS. See Section 7.5.6, « Comment MySQL utilise le DNS ».

Les autres solutions sont :

Si mysql -u root test fonctionne mais que mysql -h votre_hote -u root test provoque une erreur Access denied, il se peut que vous ayez entré de mauvaises informations pour votre nom d'hôte dans la table user. Un problème commun ici est que la valeur Host dans la table user spécifie un nom d'hôte non-qualifié, mais que vos routines système de résolution de noms retournent un nom de domaine pleinement qualifié (ou vice-versa). Par exemple, si vous avez une entrée avec l'hôte 'tcx' dans la table user, mais que vos DNS disent à MySQL que votre nom d'hôte est 'tcx.subnet.se', l'entrée ne fonctionnera pas. Essayez d'ajouter une entrée dans la table user qui contient votre adresse IP en tant que valeur de la colonne Host. (Une alternative est d'ajouter une entrée dans la table user avec une valeur de Host qui contient un caractère spécial, par exemple, 'tcx.%'. Toutefois, l'utilisation des noms d'hôtes se terminant par ‘%’ est non-sécurisé et n'est pas recommandé !)

Si mysql -u utilisateur test fonctionne mais que mysql -u utilisateur autre_base ne fonctionne pas, vous n'avez pas d'entrée pour autre_base listée dans la table db.

Si mysql -u utilisateur nom_base fonctionne à partir du serveur, mais que mysql -h nom_hote -u utilisateur nom_base ne fonctionne pas à partir d'une autre machine, cette machine n'est pas listée dans la table user ou db.

Si vous n'arrivez pas à trouver pourquoi vous obtenez l'erreur Access denied, effacez toutes les entrées de la table user dont la valeur du champ Host contiennent des caractères spéciaux (entrées contenant ‘%’ ou ‘_’). Une erreur commune est d'insérer une nouvelle entrée avec Host='%' et User='un utilisateur', en pensant que cela vous permettra de spécifier localhost pour vous connecter à partir de la même machine. La raison pour laquelle cela ne fonctionnera pas est que les droits par défaut incluent une entrée avec Host='localhost' et User=''. Puisque cette entrée possède une valeur de Host égale à 'localhost', qui est plus spécifique que '%', elle est utilisée de préférence à la nouvelle entrée lors de la connexion à partir de localhost ! La procédure correcte est d'insérer une seconde entrée avec Host='localhost' et User='un_utilisateur', ou de supprimer l'entrée avec Host='localhost' et User=''.

Si vous avez l'erreur suivante, vous avez peut-être un problème avec la table db ou host :

Access to database denied

Si l'entrée sélectionnée dans la table db possède un champ Host vide, assurez-vous qu'il y a au moins une entrée correspondante dans la table host spécifiant les hôtes auxquels l'entrée dans la table db s'applique.

Si vous obtenez l'erreur lors de l'utilisation des commandes SQL SELECT ... INTO OUTFILE ou LOAD DATA INFILE, votre entrée dans la table user ne possède probablement pas les droits de FILE.

Si vous apportez des modifications aux tables de droits directement (en utilisant une requête INSERT ou UPDATE) et que vos changements semblent ignorés, souvenez vous que vous devez exécuter une requête FLUSH PRIVILEGES ou la commande mysqladmin flush-privileges pour demander au serveur de lire à nouveau les tables de droits. Sinon, vos changements ne seront pris en compte qu'au prochain démarrage du serveur. Souvenez-vous qu'après avoir choisi le mot de passe root avec une commande UPDATE, vous n'aurez pas à le spécifier avant de recharger les privilèges, car le serveur ne sait pas que vous l'avez modifié !

Si vos droits changent en milieu de session, c'est peut être qu'un administrateur MySQL a changé les droits. En rechargeant les tables de droits, il a modifié aussi les connexions existantes, comme indiqué dans Section 5.5.7, « Quand les modifications de privilèges prennent-ils effets ? ».

Si vous avez des problèmes d'accès avec un programme Perl, PHP, Python, ou ODBC, essayez de vous connecter au serveur avec mysql -u utilisateur nom_base ou mysql -u utilisateur -pvotre_passe nom_base. Si vous pouvez vous connecter en utilisant le client mysql, c'est que le problème vient de votre programme et non des droits MySQL. (Notez qu'il n'y a pas d'espace entre -p et le mot de passe; vous pouvez aussi utiliser la syntaxe --password=votre_passe pour spécifier le mot de passe. Si vous utilisez l'option -p toute seule, MySQL vous demandera le mot de passe.)

Pour les tests, démarrez le démon mysqld avec l'option --skip-grant-tables. Vous pourrez alors changer les tables de droits MySQL puis utiliser le script mysqlaccess pour vérifier si vos changements ont l'effet désiré. Lorsque vous êtes satisfait de vos modifications, exécutez mysqladmin flush-privileges pour dire au serveur mysqld de commencer à utiliser les nouvelles tables de droits. Recharger les tables de droits écrase l'option --skip-grant-tables. Cela vous permet de dire au serveur de commencer à prendre en considération les droits sans avoir à le couper et le redémarrer.

Si rien ne fonctionne, démarrez le démon mysqld avec l'option de débogage (par exemple, --debug=d,general,query). Cela affichera l'hôte et les informations de l'utilisateur pour chaque tentative de connexion. Les informations à propos de chaque commande exécutée seront aussi affichées. See Section D.1.2, « Créer un fichier de tra¸age ».

Si vous avez d'autres problèmes avec les tables de droits de MySQL et que vous sentez que vous devez envoyer le problème à la liste de diffusion, fournissez toujours le contenu de vos tables de droits. Vous pouvez obtenir les données avec la commande mysqldump mysql. Comme toujours, postez votre problème à l'aide du script mysqlbug. See Section 1.4.1.3, « Comment rapporter un bogue ou un problème ». Dans certains cas, vous aurez besoin de redémarrer mysqld avec --skip-grant-tables pour pouvoir exécuter mysqldump.