MySQL ne peut pas se connecter via "localhost", seulement 127.0.0.1
c'est un peu un mystère pour moi. La seule façon de me connecter à MySQL est de l'appeler via "127.0.0.1" ... par exemple, mon script de connexion PHP ne fonctionnera PAS avec localhost
J'utilise Mac OS X Lion, Apache2 intégré, MySQL, PHP, phpMyAdmin
mysqladmin:
count 0
debug-check FALSE
debug-info TRUE
force FALSE
compress FALSE
character-sets-dir (No default value)
default-character-set auto
Host (No default value)
no-beep FALSE
port 0
relative FALSE
socket (No default value)
sleep 0
ssl FALSE
ssl-ca (No default value)
ssl-capath (No default value)
ssl-cert (No default value)
ssl-cipher (No default value)
ssl-key (No default value)
ssl-verify-server-cert FALSE
user (No default value)
verbose FALSE
vertical FALSE
connect-timeout 43200
shutdown-timeout 3600
plugin-dir (No default value)
default-auth (No default value)
MySQL tentera de se connecter à la socket unix si vous lui dites de se connecter à "localhost". Si vous lui dites de se connecter à 127.0.0.1, vous le forcez à se connecter à la prise réseau. Vous avez donc probablement configuré MySQL pour n'écouter que le socket réseau et non le socket du système de fichiers.
Ce qui ne va pas exactement avec votre socket Unix est difficile à dire. Mais je vous recommande de lire cette page sur le guide de référence MySQL. Cela devrait vous aider.
MISE À JOUR: Basé sur la question mise à jour: Le paramètre "socket" devrait être quelque chose comme ceci: "/var/lib/mysql/mysql.sock". Cette page du manuel de référence contient plus d'informations.
Voici le début de mon fichier /etc/my.cnf:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
Votre fichier doit être similaire. Ensuite, votre problème devrait être résolu. N'oubliez pas de redémarrer le serveur MySQL avant de le tester.
Vous pouvez avoir IPv6 activé, son hôte local très possible se résout en hôte local ipv6, qui n'est pas défini dans votre configuration msql.
ive a également eu un problème où j'ai dû ajouter 'localhost' à la place de '127.0.0.1' aux sous-réseaux autorisés pour cet utilisateur, je ne comprends pas pourquoi (j'utilisais ipv4 et c'était il y a un certain temps) mais ça vaut le coup d'essayer.
Pour moi, le php intégré d'OSX est configuré pour utiliser un socket unix différent de mysql de homebrew. Ainsi, il ne peut pas se connecter via localhost qui utilise cette socket.
Je l'ai corrigé avec un hack rapide en associant le chemin de socket configuré de php pour pointer vers celui que mysql utilise réellement.
Sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock
Les commandes de diagnostic suivantes ont été très utiles.
Vérifiez les chemins de socket par défaut utilisés par php et mysql:
php -i | fgrep 'mysql.default_socket'
mysql -e 'show variables where variable_name = "socket"'
Connectez-vous à l'aide d'une prise spécifiée:
php -r 'var_dump(mysql_connect("localhost:/tmp/mysql.sock", "user", "pass"));'
mysql --socket=/tmp/mysql.sock
Déterminez le type de socket que le client mysql utilise pour se connecter:
lsof | egrep '^mysql .*(IPv|unix)'
PHP essaie toujours d'utiliser l'emplacement de socket par défaut. Ce problème peut apparaître si vous avez déplacé le dossier MariaDB/MySQL de /var/lib/mysql vers un autre emplacement. Afin de résoudre le problème, vous devez définir l'emplacement du nouveau socket dans le fichier /etc/php.ini .
mysqli.default_socket =/newDBLocation/mysql/mysql.sock
Attention, selon le pilote que vous utilisez, vous devrez peut-être spécifier le pdo_mysql.default_socket = !
Afin de vérifier votre répertoire actuel, exécutez la commande suivante dans mysql:
select @@datadir;
Pourriez-vous vérifier mysql/conf/my.conf (la structure du répertoire devrait être à peu près la même sous OSx) pour voir si skip-networking n'est pas commenté? Si oui, ajoutez un # devant la ligne et redémarrez le serveur mysql.
J'ai eu un problème similaire il y a quelque temps (bien que ce ne soit pas sous OSx), donc j'ai pensé que cela valait le coup.
J'ai pu recréer vos mêmes symptômes sur ma boîte de test, j'espère que cela vous aidera.
Dans MySQL, les utilisateurs sont définis en deux parties (nom et hôte). Par défaut, MySQL aura 3 utilisateurs root:
mysql> SELECT Host,user,password FROM mysql.user WHERE user='root';
+-----------------------+------+-------------------------------------------+
| Host | user | password |
+-----------------------+------+-------------------------------------------+
| localhost | root | |
| localhost.localdomain | root | |
| 127.0.0.1 | root | *PASSWORD_HASH_GOES_HERE |
+-----------------------+------+-------------------------------------------+
Le champ du mot de passe sera soit vide (pas de mot de passe), soit un hachage sera stocké. Si vous définissez le mot de passe pour un utilisateur spécifique, il ne met pas automatiquement à jour tous, car MySQL les voit comme des utilisateurs différents.
Par exemple:
mysql> set password for 'root'@'127.0.0.1' = password('Password');
mettra à jour le mot de passe pour 'root'@'127.0.0.1', mais non 'root'@'localhost' ou 'root'@'localhost.localdomain'
Jetez un oeil à la skip_name_resolve variable:
mysql> show variables like 'skip_name_resolve';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| skip_name_resolve | ON |
+-------------------+-------+
1 row in set (0.00 sec)
Par défaut skip_name_resolve est OFF, et tentera de résoudre toutes les adresses IP en noms d'hôtes. Par exemple, si vous vous connectez en tant que 'root'@'127.0.0.1', MySQL changera vous connecter en tant que 'root'@'localhost'.
Si c'est ON, MySQL verra et se connectera 'root'@'127.0.0.1' et 'root'@'localhost' en tant qu'utilisateurs séparés. Et ils peuvent ou non avoir des mots de passe différents, selon la façon dont ils ont été définis.
Donc, tout d'abord, je vérifierais les différences de mot de passe: mysql> SELECT Host,user,password FROM mysql.user WHERE user='root';
Si tel est le cas, vous pouvez les corriger ou poursuivre l'enquête.
Ensuite, je vérifierais skip_name_resolve: mysql> show variables like 'skip_name_resolve';
S'il s'agit de ON, je saurais où il est défini (par exemple /etc/my.cnf) et supprimez-le, sauf si vous en avez besoin.
J'espère que ceci vous aidera!
L'hôte local est-il défini dans votre /private/etc/hosts fichier?
Pour les personnes qui utilisent CageFS avec CloudLinux:
J'ai recréé /var/lib/mysql parce que je reconstruisais le serveur MySQL à partir de zéro ...
qui a démonté le chemin de cagefs. Je sais que ce n'est pas lié, mais j'utilisais cPanel et CloudLinux. Je n'ai pas pu vérifier pourquoi la connexion socket ne fonctionne pas, et finalement, j'ai réalisé.
ajouter /var/lib/mysql à /etc/cagefs/cagefs.mp (si déjà là, passez à l'étape suivante) et en cours d'exécution
cagefsctl --remount-all
résolu le problème
Pour moi, changer les autorisations pour qu'elles soient publiquement lisibles sur le répertoire parent de mysql.sock a résolu le problème:
chmod 755 /var/lib/mysql
J'avais ce problème et je ne pouvais pas le comprendre. J'ai tout essayé en vain.
J'ai trouvé que j'avais un .netrc dans/root/qui contenait des informations.
Je l'ai supprimé et le problème a disparu.
Capable de se connecter à mysql en utilisant mysql -uroot -p sans problème maintenant.
Je sais que c'est un vieux post mais j'espère que cela aide quelqu'un.
vous devez le définir dans/etc/hosts privé je pense ... ou simplement utiliser 127.0.0.1 parce que c'est la même chose de toute façon, juste un alias.