Impossible de se connecter au serveur MySQL local via le socket '/var/mysql/mysql.sock' (38)
J'ai un gros problème en essayant de me connecter à mysql. Quand je cours:
/usr/local/mysql/bin/mysql start
J'ai l'erreur suivante:
Can't connect to local MySQL server through socket '/var/mysql/mysql.sock' (38)
J'ai mysql.sock dans le répertoire /var/mysql.
Dans /etc/my.cnf j'ai:
[client]
port=3306
socket=/var/mysql/mysql.sock
[mysqld]
port=3306
socket=/var/mysql/mysql.sock
key_buffer_size=16M
max_allowed_packet=8M
et dans /etc/php.ini j'ai:
; Default socket name for local MySQL connects. If empty, uses the built-in
; MySQL defaults.
mysql.default_socket = /var/mysql/mysql.sock
J'ai redémarré Apache avec Sudo /opt/local/Apache2/bin/apachectl restart
Mais j'ai toujours l'erreur.
Sinon, je ne sais pas si cela est pertinent, mais quand je fais mysql_config --sockets je reçois
--socket [/tmp/mysql.sock]
Si votre fichier my.cnf (généralement dans le dossier / etc/mysql /) est correctement configuré avec
socket=/var/lib/mysql/mysql.sock
vous pouvez vérifier si mysql fonctionne avec la commande suivante:
mysqladmin -u root -p status
essayez de changer votre permission dans le dossier mysql. Si vous travaillez localement, vous pouvez essayer:
Sudo chmod -R 755 /var/lib/mysql/
cela l'a résolu pour moi
êtes-vous sûr d'avoir installé mysql ainsi que le serveur mysql?.
Par exemple, pour installer le serveur mySql, je vais utiliser yum ou capable d'installer à la fois l'outil de ligne de commande mysql et le serveur:
yum -y install mysql mysql-server (or apt-get install mysql mysql-server)
Activer le service MySQL:
/sbin/chkconfig mysqld on
Démarrez le serveur MySQL:
/sbin/service mysqld start
ensuite, définissez le mot de passe root MySQL:
mysqladmin -u root password 'new-password' (with the quotes)
J'espère que ça aide.
Une solution de contournement rapide qui a fonctionné pour moi: essayez d’utiliser l’adresse IP locale (127.0.0.1) au lieu de "localhost" dans mysql_connect (). Cela "force" php à se connecter via TCP/IP au lieu d’un socket Unix.
J'ai eu l'erreur suivante
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
Essayé de plusieurs manières et finalement résolu par la manière suivante
Sudo gksu gedit /etc/mysql/my.cnf
modifié
#bind-address = 127.0.0.1
à
bind-address = localhost
et redémarré
Sudo /etc/init.d/mysql restart
ça a marché
Assurez-vous que vous utilisez mysqld: /etc/init.d/mysql start
Pour éviter le problème, vous devez exécuter un arrêt en douceur du serveur à partir de la ligne de commande plutôt que de le mettre hors tension.
shutdown -h now
Cela arrêtera les services en cours avant de mettre la machine hors tension.
Basé sur Centos, une méthode supplémentaire pour le récupérer lorsque vous rencontrez ce problème consiste à déplacer mysql.sock:
mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak
service mysqld start
Le redémarrage du service crée une nouvelle entrée appelée mqsql.sock
Comme le montrent les nombreuses réponses fournies ici, de nombreux problèmes peuvent entraîner ce message d'erreur lorsque vous démarrez le service MySQL. Le fait est que MySQL vous dira généralement exactement ce qui ne va pas, si vous vous contentez de regarder dans le fichier journal approprié.
Par exemple, sur Ubuntu, vous devriez vérifier /var/log/syslog. Etant donné que beaucoup d'autres choses peuvent également se connecter à ce fichier, vous voudrez probablement utiliser grep pour regarder les messages mysql et tail pour ne regarder que les plus récents. Tous ensemble, cela pourrait ressembler à:
grep mysql /var/log/syslog | tail -50
N'apportez pas de modifications à votre configuration à l'aveuglette, car quelqu'un d'autre a déclaré "Cela a fonctionné pour mon système". Déterminez ce qui ne va pas avec votre système et vous obtiendrez un meilleur résultat beaucoup plus rapidement.
Une autre solution consiste à éditer /etc/my.cnf et à inclure Host dans la section [client].
[client]
#password = your_password
Host = 127.0.0.1
port = 3306
socket = /var/run/mysql/mysql.sock
Et puis en redémarrant le service mysql.
Cette solution de contournement a été testée dans: Version du serveur: 5.5.25a-log Distribution de la source
J'ai eu cette erreur lorsque j'ai défini le travail cron pour mon fichier. J'ai changé les permissions du fichier en 777 mais cela ne fonctionnait toujours pas pour moi. Enfin j'ai eu la solution. Peut-être que cela sera utile pour les autres.
Essayez avec cette commande:
mysql -h 127.0.0.1 -P 3306 -u racine -p
Rappelez-vous que -h signifie Host et -p signifie port.
Si tout a bien fonctionné et que vous venez tout juste de voir cette erreur, avant de faire autre chose, assurez-vous de ne pas manquer d'espace disque:
df -h
Si le volume sur lequel mysql.sock est créé est utilisé à 100%, MySql ne pourra pas le créer et ce sera la cause de cette erreur. Tout ce que vous avez à faire est de supprimer un élément inutile, comme les anciens fichiers journaux.
Dans mon cas, j'utilisais Centos 5.5. J'ai trouvé que le problème était dû au fait que le service mysql était arrêté. J'ai donc lancé le service mysql avec la commande:
/etc/init.d/mysqld start
Alors .. erreur stupide.
essayez avec -h (hôte) et -P (port):
mysql -h 127.0.0.1 -P 3306 -u root -p
J'ai eu le même problème et il a été causé par une mise à jour des pilotes mysql lorsque le serveur mysql était en cours d'exécution. Je l'ai corrigé en redémarrant à la fois mysql et Apache2:
Sudo service mysql stop
Sudo service mysql start
Sudo service Apache2 stop
Sudo service Apache2 start
Sudo service mysql start
Cela devrait vous servir très bien. Il est possible que vous ayez modifié certaines commandes ayant une incidence sur les configurations mysql.
Il existe de nombreuses solutions à ce problème, mais pour ma situation, je devais simplement corriger DATE sur la machine/serveur (buntu 16.04 Server).
i) Vérifiez la date de votre serveur et corrigez-la.
ii) Exécuter Sudo /etc/init.d/mysql restart
Cela devrait commencer.
J'ai également constaté qu'il s'agissait d'un problème d'autorisations. J'ai comparé les fichiers MySQL à une installation en état de marche (les deux sous Debian 6 squeeze) et je devais apporter les modifications de propriété suivantes (où mydatabase correspond à votre base de données).
Propriété mysql:mysql:
chown mysql:mysql /var/lib/mysql
chown mysql:mysql /var/lib/mysql/ib*
chown mysql:mysql /var/lib/mysql/mydatabase
chown mysql:mysql /var/lib/mysql/mydatabase/*
chown mysql:mysql /var/lib/mysql/mysql/*
Propriété mysql:root:
chown mysql:root /var/lib/mysql/mysql
chown mysql:root /var/run/mysqld
Propriété mysql:adm:
chown mysql:adm /var/log/mysql
chown mysql:adm /var/log/mysql.err
chown mysql:adm /var/log/mysql.log*
J'obtenais l'erreur parce que j'exécutais MAMP et mon fichier .sock se trouvait à un emplacement différent. Je viens d’ajouter un lien symbolique indiquant que l’application devrait être dirigée vers l’endroit où elle se trouvait réellement et que cela a fonctionné à merveille.
Si vous utilisez la version AWS (Amazon Web Services) Micro, il s'agit d'un problème de mémoire. Quand j'ai couru
mysql
du terminal, il dirait
ERROR 2002 (HY000): Can't connect to local MySQL server through socket /var/run/mysqld/mysqld.sock' (111)
J'ai donc essayé ce qui suit et cela échouerait.
service mysqld restart
Après de nombreuses recherches, j'ai découvert qu'il fallait créer un fichier d'échange pour que MySQL dispose de suffisamment de mémoire. Les instructions sont listées: http://www.prowebdev.us/2012/05/Amazon-ec2-linux-micro-swap-space.html .
Ensuite, j'ai pu redémarrer mysqld.
Pour ceux dont la solution n'a pas fonctionné, essayez:
cd /etc/mysql
vérifier si mon.cnf est présent
nano my.cnf
et assurez-vous de n'avoir qu'une seule adresse de liaison, comme suit:
bind-address = 127.0.0.1
Sinon, cela pourrait être le problème, quittez nano et enregistrez le fichier.
et service mysql start
notez que si vous n'avez pas nano (son éditeur de texte), installez-le simplement avec apt-get install nano et appuyez une fois sur Ctrl + X pour quitter, n'oubliez pas de dire Y pour enregistrer et utiliser le même fichier)
J'ai eu ce problème aussi en essayant de démarrer le serveur, donc beaucoup de réponses ici qui disent juste que démarrer le serveur ne fonctionnaient pas. La première chose à faire est d’exécuter ce qui suit pour voir s’il ya des erreurs de configuration:
/usr/sbin/mysqld --verbose --help 1>/dev/null
J'ai eu une erreur qui est apparue:
160816 19:24:33 [Note] /usr/sbin/mysqld (mysqld 5.5.50-0ubuntu0.14.04.1-log) starting as process 9461 ...
160816 19:24:33 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
160816 19:24:33 [Note] Plugin 'FEDERATED' is disabled.
160816 19:24:33 [ERROR] /usr/sbin/mysqld: unknown variable 'innodb-online-alter-log-max-size=4294967296'
160816 19:24:33 [ERROR] Aborting
Un simple grep -HR "innodb-online-alter-log-max-size" /etc/mysql/ m'a montré exactement quel fichier contenait la ligne incriminée, j'ai donc supprimé cette ligne du fichier.
Ensuite, en vérifiant mon fichier /var/log/mysql/error.log que j’avais:
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 671088640 bytes!
160816 22:46:46 [ERROR] Plugin 'InnoDB' init function returned error.
160816 22:46:46 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160816 22:46:46 [ERROR] Unknown/unsupported storage engine: InnoDB
160816 22:46:46 [ERROR] Aborting
Basé sur cette question , la solution acceptée ne fonctionnerait pas car je ne pouvais même pas démarrer le serveur. J'ai donc suivi ce que certains commentaires ont dit et supprimé mon /var/lib/mysql/ib_logfile0 et /var/lib/mysql/ib_logfile1 des dossiers.
Cela a permis au serveur de démarrer et j'ai pu me connecter et exécuter des requêtes, mais en vérifiant mon fichier de journal des erreurs, il s'est rapidement rempli avec plusieurs dizaines de milliers de lignes comme celle-ci:
160816 22:52:15 InnoDB: Error: page 1415 log sequence number 82039318708
InnoDB: is in the future! Current system log sequence number 81640793100.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
Sur une suggestion de ici , pour résoudre ce problème, j’ai fait un mysqldump et une restauration de toutes les bases de données (voir le lien pour plus d’autres solutions).
$ mysqldump -u root -p --allow-keywords --add-drop-database --comments --hex-blob --opt --quote-names --databases db_1 db_2 db_3 db_etc > backup-all-databases.sql
$ mysql -u root -p < backup-all-databases.sql
Tout semble fonctionner comme prévu maintenant.
vous pouvez toujours démarrer le serveur mysql en spécifiant l'emplacement du fichier mysql.sock à l'aide de l'option --socket comme
mysql --socket=/var/mysql/mysql.sock
Cela fonctionnera même si l'emplacement du fichier de socket est spécifié à un emplacement différent dans le fichier my.cnf.
Pour moi, il s’agissait simplement d’un cas de chargement long de MySQL. Il y a plus de 100 000 tables dans l'une de mes bases de données et cela a finalement commencé, mais cela doit évidemment prendre beaucoup de temps dans ce cas.
Cela ne répond pas directement à votre question, mais un sous-ensemble de celle-ci, à savoir l'utilisation de PythonAnywhere. Je n'arrivais pas à trébucher sur cette question lorsque je cherchais un correctif, alors je l'ajoute ici dans l'espoir que cela aidera les autres dans ma situation.
PythonAnywhere a décidé de changer les noms d'hôte de connexion à la base de données afin d'améliorer l'efficacité et la fiabilité, comme détaillé ici :
Le nom d'hôte officiel que vous devez utiliser pour vous connecter à l'instance de base de données MySQL de votre compte est passé de mysql.server à yourusername . Mysql.pythonanywhere-services .com . Cela contourne une partie de notre infrastructure qui a commencé à présenter des problèmes ces dernières semaines et devrait être beaucoup plus efficace et fiable que l'ancienne.
Par conséquent, vous devrez mettre à jour votre nom d’hôte avec la valeur indiquée ci-dessus.
Sudo service mysqld start
Travaillé pour moi, j'utilise Centos
J'ai rencontré ce problème aujourd'hui. Aucune de ces réponses n'a fourni la solution. Je devais faire les commandes suivantes (trouvées ici (https://stackoverflow.com/a/20141146/633107 )) pour que mon service mysql démarre:
Sudo /etc/init.d/mysql stop
cd /var/lib/mysql/
ls ib_logfile*
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak
... etc ...
/etc/init.d/mysql restart
Ceci est en partie indiqué par les erreurs suivantes dans /var/log/mysql/error.log:
140319 11:58:21 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 50331648 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
140319 11:58:21 [ERROR] Plugin 'InnoDB' init function returned error.
140319 11:58:21 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140319 11:58:21 [ERROR] Unknown/unsupported storage engine: InnoDB
140319 11:58:21 [ERROR] Aborting
J'ai également vu l'erreur de disque plein, mais uniquement lors de l'exécution de commandes sans Sudo. Si la vérification des autorisations échoue, le disque est saturé (même si votre partition n’est même pas proche de la saturation).
Je viens d'avoir ce problème. après une journée de vérification, j'ai enfin la réponse à cela. Le fichier mysql.sock est créé au démarrage de MariaDB et est supprimé à la fermeture de MariaDB. Cela n'existera pas si MariaDB n'est pas en cours d'exécution. Peut-être que vous n'avez pas installé MariaDB. VOUS POUVEZ SUIVRE L'INSTRUCTION CI-DESSOUS: https://www.linode.com/docs/databases/mariadb/how-to-install-mariadb-on-centos-7 BEST
C'était assez bien pour moi
Sudo /etc/init.d/mysql restart
CentOS 7, 64 bits. Nouvelle installation.
Dans mon cas, l’erreur était due au fait que je n’avais pas installé le bon serveur MySQL ni le client MySQL.
En utilisant yum, j’ai enlevé mariadb et l’édition mysql-community. J'ai téléchargé les rpm du client et du serveur depuis le site Web officiel de MySQL et ai installé le serveur et le client.
Lors de l'installation du serveur, un message m'a indiqué que le mot de passe du compte racine de MySQL était stocké dans un fichier que je pouvais afficher avec Sudo cat /root/.mysql_secret.
Ainsi, après avoir installé le client et le serveur, j'ai vérifié si MySQL fonctionnait (je pense avoir redémarré avant de le faire) avec la commande Sudo service mysql status et j'ai obtenu le résultat.
MySQL en cours d'exécution (2601) [OK]
Je me suis connecté à MySQL en utilisant le mot de passe du fichier .mysql_secret:mysql -uroot -pdxM01Xfg3DXEPabpf. Notez que dxM01Xfg3DXEPabpf est le mot de passe mentionné dans le fichier .mysql_secret.
puis tapé a entré la commande suivante à l'invite mysql pour changer le mot de passe de root:
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('somePassword');
Tout a bien fonctionné à partir de là.
Ajouter
--protocol=tcp
à la liste des paramètres dans votre connexion a fonctionné pour moi.
Si quelqu'un cherche l'erreur d'initialisation
Impossible de se connecter à la base de données "/var/run/mysql/mysql.sock"
Lorsque vous utilisez civicrm & drupal, apportez simplement les modifications ci-dessous dans
settings.php et civicrm.settings.php
seulement dans les endroits où vous essayez d'établir une connexion à la base de données
localhost to 127.0.0.1 #local installation
J'ai utilisé 127.0.0.1 pour -h à la place de localhost et tout s'est bien passé. Dans d'autres cas, il y avait ce qui avait - l'erreur que ci-dessus.
J'ai eu le même problème sur Freebsd, je l'ai résolu en supprimant le fichier my.cnf. La version de Mysql était 5.6.
Il semble qu’après la mise à niveau à partir de la version 5.5, l’ancien fichier my.cnf subsiste et certains paramètres incompatibles forcent à une erreur. L'ancien my.cnf avait beaucoup de paramètres mais le nouveau un seul
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
Mais si vous le faites, gardez à l’esprit que cela pourrait poser un risque pour la sécurité, car cela, sans autre entrée, pourrait ouvrir votre base de données au reste du monde ;-) Sinon, ajoutez au moins cette ligne.
bind-address = 127.0.1.1
Essayez d'exécuter la commande suivante:
Sudo /etc/init.d/mysql start
J'ai eu cette erreur de socket et cela est dû au fait que MySQL ne fonctionnait pas. Si vous lancez une nouvelle installation, assurez-vous d’installer 1) le paquet système et 2) le programme d’installation du panneau (mysql.prefPane). Le programme d'installation du panneau vous permettra d'accéder à vos préférences système et d'ouvrir MySQL, puis de lancer une instance.
Notez que lors d’une nouvelle installation, j’avais besoin de réinitialiser mon ordinateur pour que les modifications soient correctement appliquées. Après un redémarrage, une nouvelle instance est en cours d’exécution et j’ai pu ouvrir une connexion à localhost sans aucun problème.
À noter également, j’avais apparemment des versions précédentes de MySQL mais j’avais retiré le panneau, ce qui facilite la gestion d’une instance de MySQL pour les utilisateurs de mac.
Un bon lien pour ce processus de réinstallation: http://www.coolestguyplanettech.com/how-to-install-php-mysql-Apache-on-os-x-10-6/
Après une nuit blanche et une demi-soirée avec ceci, voici mes centimes pour l'histoire,
utilisez-vous hhvm?
si c'est le cas, ajoutez la ligne suivante dans /etc/hhvm/server.ini
_hhvm.mysql.socket = /var/run/mysqld/mysqld.sock
_J'ai supprimé le fichier mysql.sock et cela a fonctionné. Mettre les droits dessus n'a pas fonctionné du tout. Ni redémarrer, ou peu importe ...