FEHLER 2002 (HY000): Verbindung zum lokalen MySQL-Server über Socket '/var/run/mysqld/mysqld.sock' nicht möglich (2)

Ich hatte dieses Problem einmal und löste es, indem ich mysql-server installierte. Stellen Sie also sicher, dass Sie mysql-server installiert haben, nicht mysql-client oder etwas anderes.

Dieser Fehler bedeutet, dass die Datei /var/run/mysqld/mysqld.sock nicht vorhanden ist. Wenn Sie mysql-server nicht installiert haben, ist die Datei nicht vorhanden. Aber wenn der mysql-server bereits installiert ist und ausgeführt wird, müssen Sie die Konfigurationsdateien überprüfen.

Die Konfigurationsdateien sind:

/etc/my.cnf
/etc/mysql/my.cnf
/var/lib/mysql/my.cnf

In /etc/my.cnf kann die Socket-Dateikonfiguration /tmp/mysql.sock sein, und in /etc/mysql/my.cnf kann die Socket-Dateikonfiguration /var/run/mysqld/mysqld.sock sein. Entfernen oder benennen Sie /etc/mysql/my.cnf um, und lassen Sie mysql /etc/my.cnf verwenden, damit das Problem behoben wird.

Versuche dies:

mysql -h 127.0.0.1 -P 3306 -u root -p <database>

Auch (um zu sehen, ob es läuft):

telnet 127.0.0.1 3306 

Wahrscheinlich handelt es sich nur um eine Fehlkonfiguration in der Datei my.cnf in /etc/somewhere (abhängig von Linux-Distribution ).

Ich sehe alle diese Antworten, aber keine bieten die Möglichkeit, das Passwort zurückzusetzen und keine akzeptierte Antwort . Die eigentliche Frage ist, dass er sein Passwort vergessen hat , also muss er zurücksetzen, nicht sehen, ob es läuft oder nicht (installiert oder nicht), wie die meisten dieser Antworten implizieren.

Passwort zurücksetzen

Befolgen Sie diese Schritte (kann hilfreich sein, wenn Sie Ihr Passwort wirklich vergessen haben und es jederzeit versuchen können, auch wenn Sie sich gerade nicht in der Situation befinden):

1. Stop mysql

   Sudo /etc/init.d/mysql stop
   

   Oder für andere Distributionsversionen:

   Sudo /etc/init.d/mysqld stop
   

2. Starten Sie MySQL im abgesicherten Modus

   Sudo mysqld_safe --skip-grant-tables &
   

3. Melden Sie sich mit root bei MySQL an

   mysql -uroot
   

4. Wählen Sie die zu verwendende MySQL-Datenbank aus

   use mysql;
   

5. Setzen Sie das Passwort zurück

   -- MySQL version < 5.7
   update user set password=PASSWORD("mynewpassword") where User='root';
   
   -- MySQL 5.7, mysql.user table "password" field -> "authentication_string"
   
   update user set authentication_string=password('mynewpassword') where user='root';
   

6. Spülen Sie die Privilegien

   flush priveleges;
   

7. Starten Sie den Server neu

   quit
   

8. Stoppen und starten Sie den Server erneut

   Ubuntu und Debian:

   Sudo /etc/init.d/mysql stop
   ...
   Sudo /etc/init.d/mysql start
   

   Auf CentOS, Fedora und RHEL:

   Sudo /etc/init.d/mysqld stop
   ...
   Sudo /etc/init.d/mysqld start
   

9. Melden Sie sich mit einem neuen Passwort an

   mysql -u root -p
   

10. Geben Sie das neue Passwort ein und genießen Sie Ihren Server erneut, als wäre nichts passiert

Dies wurde aus Setzen Sie ein MySQL-Root-Passwort zurück entnommen.

Ich habe die folgenden Schritte ausprobiert:

1. Melden Sie sich als super user an oder verwenden Sie Sudo
2. Öffnen Sie /etc/mysql/my.cnf mit gedit
3. Suchen Sie nach bind-address, und ändern Sie den Wert in die IP-Adresse des Datenbankserver-Hostcomputers. Für mich war es localhost oder 127.0.0.1
4. Speichern und schließen Sie die Datei.
5. Komm zurück zum Terminal und führe Sudo service mysql start aus

Und es hat bei mir funktioniert.

Ich habe dieses Problem behoben, indem ich den folgenden Befehl ausgeführt habe:

mysql.server start

Und wenn Sie auf einem Mac sind und mit brew mysql installiert haben, verwenden Sie einfach:

brew services start mysql

Ich hatte ein ähnliches Problem. mysql würde nicht starten:

Sudo service mysql start
start: Job failed to start

Wenn ich Apparmor deaktiviert habe:

Sudo aa-complain /etc/apparmor.d/*

das Problem ging weg. Das Problem war, dass mysqld versuchte, auf /run/mysqld/mysqld.sock zuzugreifen, aber das apparmor-Profil gab nur /var/run/mysqld/mysqld.sock die Berechtigung (/ var/run ist mit/run verknüpft, also sind dies tatsächlich das Gleiche). Nicht sicher, warum mysqld nicht den var-Pfad verwendet, da dies in allen Konfigurationsdateien festgelegt ist, aber Sie können das Problem beheben, indem Sie Folgendes zu /etc/apparmor.d/usr.sbin.mysqld hinzufügen

/run/mysqld/mysqld.pid rw,
/run/mysqld/mysqld.sock rw,

In meinem Fall war die Festplatte voll und mysqld konnte nicht mehr gestartet werden.

Versuchen Sie, den MySQL-Dienst neu zu starten.

service MySQL neu starten

oder

service MySQL zu stoppen

service MySQL starten

Wenn der Befehl "stop" nicht erkannt wird, ist dies definitiv der Speicherplatz. Sie sollten etwas Platz in der Partition machen, die MySQL zugewiesen hat, oder die Festplatte vergrößern.

Überprüfen Sie den Speicherplatz mit

df -h

Ich habe das gelöst, indem ich den mysql -Prozess beendet habe:

ps -ef | grep mysql
kill [the id]

Und dann habe ich den Server neu gestartet mit:

Sudo /etc/init.d/mysql restart

Aber start funktioniert auch:

Sudo /etc/init.d/mysql start

Dann habe ich mich als admin angemeldet und war fertig.

Nachdem ich meinen Produktionsserver neu starten musste, trat das gleiche Problem auf. Ich verwende Debian 8.1 (Jessie) auf einem DigitalOcean-Tröpfchen.

Folgendes habe ich getan, um mein Problem zu beheben:

1. Überprüfen Sie, ob die Datei /var/run/mysqld/mysqld.sock vorhanden ist. Wenn dies nicht der Fall ist, erstellen Sie es manuell, indem Sie touch /var/run/mysqld/mysqld.sock eingeben (was ich tun musste).

2. Der MySQL-Prozess kann diese Datei also verwenden. Ändern Sie den Besitz der Datei, indem Sie chown mysql /var/run/mysqld/mysqld.sock eingeben.

3. Starten Sie den MySQL-Dienst nach '2' neu, indem Sie service mysql restart oder /etc/init.d/mysql restart eingeben.

Nachdem ich die obigen Schritte ausgeführt hatte, wurde mein Problem behoben. Ich habe dieses Problem selten und es gibt wahrscheinlich einen besseren Weg, also auf jeden Fall konstruktives Feedback geben, wenn es sein muss :).

Irgendwie hat der MySQL-Serverprozess den Socket nicht erstellt, oder der Client sucht am falschen Ort nach dem Socket.

Mein erster Vorschlag wäre zu überprüfen, ob der MySQL-Server läuft. Der zweite Vorschlag könnte sein, ob der MySQL-Server auf einem anderen Host läuft. Wenn ja, fügen Sie Ihrem MySQL-Client im Terminal das Flag -h <hostname> hinzu.

Wenn MySQL tatsächlich und lokal ausgeführt wird, überprüfen Sie Ihre my.cnf -Datei. Es sollte eine Linie wie sein

socket = /var/run/mysqld/mysqld.sock

Überprüfen Sie, ob dies mit dem Socket-Speicherort übereinstimmt, den Sie in Ihrem Beitrag angegeben haben.

Aus Erfahrung würde ich sagen, dass das wahrscheinlichste Szenario ist, dass Ihr MySQL-Server entweder gar nicht oder nicht auf demselben Host ausgeführt wird, auf dem Sie Ihren MySQL-Client vom Terminal aus ausführen.

Ihr MySQL-Server läuft möglicherweise nicht. Stellen Sie sicher, dass es ausgeführt wird, indem Sie mysql.server start in das Terminal eingeben.

Überprüfen Sie den Parameter "bind-adress" in my.cnf.

Andernfalls versuchen Sie es mit dem Befehl:

mysql -h 127.0.0.1 -P 3306 -u root -p

• -h für Host 127.0.0.1, also localhost

• -P (beachten Sie -P als Großbuchstaben) für Port 3306, dh den Standardport für MySQL

Folgendes hat bei mir funktioniert:

ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock
service mysql restart

Dadurch wird eine Verknüpfung erstellt.

Wenn Sie Amazon EC2 verwenden und dieses Problem auf der Instanz haben, müssen Sie nur Folgendes tun:

Sudo yum install mysql-server
Sudo service mysqld restart

In Amazon EC2 ist kein Server installiert (nur der Client ist installiert). In diesem Fall müssen Sie diesen auf Ihrer Instanz installieren und anschließend versuchen

 mysql -u root -p

um zu überprüfen, ob das funktioniert hat.

Ich denke, wann immer Sie den Fehler bekommen

FEHLER 2002 (HY000): Verbindung zum lokalen MySQL-Server über Socket '/var/lib/mysql/mysql.sock' nicht möglich

Ich empfehle zuerst zu überprüfen, ob Ihr mysql -Daemon ausgeführt wird ... Meistens wird er nicht standardmäßig ausgeführt. Sie können es mit /etc/init.d/mysqld status überprüfen.

Wenn es nicht läuft, starte es zuerst:

.../etc/init.d/mysqld start.

Ich wette, es wird 110% funktionieren.

Anstatt localhost zu verwenden:

mysql -u myuser -pmypassword -h localhost mydatabase

Verwenden Sie 127.0.0.1

mysql -u myuser -pmypassword -h 127.0.0.1 mydatabase

(Beachten Sie auch, dass kein Leerzeichen zwischen -p und mypassword steht.)

Genießen :)

Stellen Sie sicher, dass Sie Backups wichtiger Datenbanken haben und versuchen Sie MySQL zu deinstallieren verwandte Sachen:

apt-get remove --purge mysql\*

Dann erneut installieren:

apt-get install mysql-server mysql-client

Das hat bei mir geklappt und die Daten wurden gespeichert.

Wenn PHP MySQL Fehler anzeigt, müssen Sie möglicherweise installieren Sie PHP MySQL erneut:

apt-get install php5-fpm php5-mysql

Wenn Sie XAMPP auf Ihrem Linux-Computer installiert haben, versuchen Sie, Ihre my.cnf -Datei von /opt/lampp/etc/my.cnf nach /etc/my.cnf zu kopieren.

Führen Sie dann den mysql -u root erneut aus ... Sie sollten nun den richtigen Socket haben und in der Lage sein, den MySQL-Client auszuführen.

Ich stelle auch dasselbe Problem gegenüber, es wird auftreten, wenn Ihr mysql server nicht standardmäßig ausgeführt wird, es wird nach einigen Sekunden wieder angehalten, so dass Sie erneut den Befehl ($ Sudo service mysql start) ausführen, den Sie ändern können, wenn Sie wissen.

für diesen Befehl verwenden

$ Sudo service mysql start   

(Benutzerpasswort eingeben, falls erforderlich, da wir Sudo verwenden) und dann ausführen

$ Sudo mysql -u root -p          (put user password if required )

jetzt hast du deine Datenbank

Ich habe dieses Problem auch, aber ich habe gerade getan:

Sudo service mysql restart 

Es hat bei mir funktioniert.

ICH HABE DIE LÖSUNG GEFUNDEN

Vor dem Abfeuern der Befehl: mysql_secure_installation

• Schritt 1: Sudo systemctl stop mariadb
• Schritt 2: Sudo systemctl start mariadb
• Schritt 3: mysql_secure_installation

Dann fragt es nach dem root-Passwort und Sie können einfach drücken Enter und Ihr neues root-Passwort festlegen .

Wenn Ihre Installation neu war, sollten Sie überprüfen, ob es sich bei Ihrer Installation um die Installation SERVER ... als mysql-server-5.5 handelt. Vielleicht haben Sie nur "mysql" installiert. Dies ist nur der Client anstelle des Servers.

ich habe dieses Problem mit einem Neustart von MySQL gelöst

/etc/init.d/mysql stop

und

/etc/init.d/mysql start

das ist es.

In meinem Fall funktionierte es durch Forschung und Entwicklung:

Ich kann mich mit MySQL verbinden

root-debian#mysql -h 127.0.0.1 -u root -p

Aber es funktioniert nicht mit mysql -u root -p.

Ich habe in my.cnf keinen bind-address gefunden. Also habe ich den Parameter socket=/var/lib/mysql/mysqld.sock in my.cnf kommentiert, wodurch ich ein Problem mit der Anmeldung hatte.

Nach dem Neustart des Dienstes ging es gut:

[email protected]:~# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.6.19 MySQL Community Server (GPL)

In meinem Fall wurde der Standardport 3306 von einem anderen Prozess verwendet und wurde daher nicht gestartet. Nachdem ich den anderen Dienst angehalten und Sudo service mysql start ausgeführt habe, hat es gut funktioniert. Übrigens können Sie so etwas wie Sudo lsof -Pn -iTCP:3306 verwenden, um zu sehen, wer möglicherweise den Port verwendet.

In meinem Fall scheint es so, als ob ich den mysql-Prozess nicht wirklich beenden konnte, wenn ich ihn ausführe

Sudo service mysql stop
ps -ef | grep mysql

Der Mysql-Prozess war immer da, es sieht so aus, als ob er die Socket-Datei blockiert und der neue Mysql-Prozess ihn nicht selbst erstellen konnte.

das hat also geholfen

cd /var/run
Sudo cp mysqld/ mysqld.bc -rf
Sudo chown mysql:mysql mysqld.bc/
Sudo service mysql stop
Sudo cp mysqld.bc/ mysqld -rf
Sudo chown mysql:mysql mysqld -R
Sudo /usr/sbin/mysqld --skip-grant-tables --skip-networking &

Jetzt bin ich in der Lage, Datenbank mit einzuloggen

mysql -u root

Dann, um das root-Passwort zu aktualisieren:

UPDATE user SET authentication_string=password('YOURPASSWORDHERE') WHERE user='root';
FLUSH PRIVILEGES;

PS: Ich hatte Probleme beim Aktualisieren des root-Passworts. Es scheint ein Problem mit dem "auth_socket" -Plugin zu geben, daher musste ich einen neuen Benutzer mit allen Rechten erstellen

insert into user set `Host` = "localhost", `User` = "super", `plugin` = "mysql_native_password", `authentication_string` = NULL, `password_expired` = "N", `password_lifetime` = NULL, `account_locked` = "N", `Select_priv` = "Y",
`Insert_priv` = "Y", `Update_priv` = "Y", `Delete_priv` = "Y", `Create_priv` = "Y", `Drop_priv` = "Y", `Reload_priv` = "Y", `Shutdown_priv` = "Y", `Process_priv` = "Y", `File_priv` = "Y",
`Grant_priv` = "Y",  `References_priv` = "Y", `Index_priv` = "Y", `Alter_priv` = "Y", `Show_db_priv` = "Y", `Super_priv` = "Y", `Create_tmp_table_priv` = "Y", `Lock_tables_priv` = "Y",
`Execute_priv` = "Y", `Repl_slave_priv` = "Y",  `Repl_client_priv` = "Y",  `Create_view_priv` = "Y", `Show_view_priv` = "Y", `Create_routine_priv` = "Y", `Alter_routine_priv` = "Y",
`Create_user_priv` = "Y",  `Event_priv` = "Y", `Trigger_priv` = "Y", `Create_tablespace_priv` = "Y";

Dadurch wird der Benutzer "super" ohne Passwort erstellt und Sie können eine Verbindung mit mysql -u super herstellen.

Erfahrungsgemäß müssen Sie zunächst überprüfen, ob der Server ausgeführt wird, und dann versuchen, MySQL zu konfigurieren. Die letzte Lösung ist die Neuinstallation von MySQL.

Auf dem Debian-Server Jessie bestand meine funktionierende Lösung darin, einfach zu tun

service mysql restart
service mysql reload

als root-Benutzer

Es funktioniert jetzt...

Ich habe das Tutorial Installieren von MariaDB 10.1.16 unter Mac OS X mit Homebrew befolgt, um dieses Problem zu beheben.

Vergessen Sie jedoch nicht, die alte Installation von MariaDB zu beenden oder zu deinstallieren.

Öffnen Sie das Terminal und geben Sie Folgendes ein:

Sudo apt-get purge mysql-client-core-5.6

Sudo apt-get autoremove

Sudo apt-get autoclean

Sudo apt-get install mysql-client-core-5.5

Sudo apt-get install mysql-server  

Sowohl der MySQL-Datenbank-Core-Client als auch die MySQL-Server-Pakete haben dieselbe Version 5.5. MySQL Client 5.5 und MySQL Server 5.5 sind die aktuell "besten" Versionen dieser Pakete in Ubuntu 14.04, wie von den Paketbetreuern festgelegt.

Wenn Sie lieber MySQL Client 5.6 und MySQL Server 5.6 installieren möchten, finden Sie die Pakete mysql-client-core-5.6 und mysql-server-5.6 auch im Ubuntu Software Center. Wichtig ist, dass die Versionsnummern von Client und Server in beiden Fällen übereinstimmen.

Das hat bei mir funktioniert.

Ich hatte das gleiche problem Nach langem Suchen habe ich keine Antwort gefunden.

Schließlich überprüfte ich das Verzeichnis /tmp und seine Berechtigungen waren 755. Ich änderte seine Berechtigungen auf 777 und mysqld startete problemlos.

Dasselbe gilt für Ubuntu 14.04 (Trusty Tahr).

Wenn Sie XAMPP installiert haben, ist die Installation von mysql-server nicht die Lösung, da Sie auf ein anderes MySQL zugreifen!

Sie müssen die richtige Steckdose verwenden, um darauf zuzugreifen. Normalerweise ist es das:

/opt/lampp/var/mysql/mysql.sock

Ändern Sie es stattdessen in:

/var/run/mysqld/mysqld.sock

Ich hatte das gleiche Problem. Manchmal passiert dies, wenn Ihr MySQL-Dienst abgelehnt wird.

Also musst du damit anfangen:

Sudo service mysql start

mysqld stop
mysql.server start

Überprüfen Sie, ob Sie die richtigen Rechte haben:

Sudo chmod 755 /var/lib/mysql/mysql

Ich hatte die gleichen Probleme und das hat bei mir funktioniert. Danach konnte ich MySQL starten.

Starten Sie den Server erneut mit

Sudo /usr/local/mysql/support-files/mysql.server start

Wenn ein Fehler auftritt, führen Sie die folgenden Schritte aus

1. mysqld

Sie sehen das folgende Protokoll. Beachten Sie hier den hervorgehobenen Teil des MySQL-Verzeichnisses

mysqld: Das Verzeichnis kann nicht in '/ usr/local/mysql-5.7.14-osx10.11-x86_64/data /' geändert werden (Errcode: 13 - Berechtigung verweigert) 2016 -10-04T14: 09: 19.392581Z 0 [Warnung] TIMESTAMP mit implizitem DEFAULT-Wert ist veraltet. Verwenden Sie die Serveroption --explicit_defaults_for_timestamp (weitere Informationen finden Sie in der Dokumentation). 2016-10-04T14: 09: 19.392847Z 0 [Warnung] Unsichere Konfiguration für --secure-file-priv: Der aktuelle Wert schränkt den Speicherort der generierten Dateien nicht ein. Stellen Sie einen gültigen, nicht leeren Pfad ein. 2016-10-04T14: 09: 19.392921Z 0 [Hinweis] mysqld (mysqld 5.7.14) wird als Prozess 1402 gestartet ... 2016-10-04T14: 09: 19.397569Z 0 [Warnung] Testdatei kann nicht erstellt werden
/usr/local/mysql-5.7.14-osx10.11-x86_64/data/Sudharshan.lower-test
2016-10-04T14: 09: 19.397597Z 0 [Warnung] Die Testdatei /usr/local/mysql-5.7.14-osx10.11-x86_64/data/Sudharshan.lower-test kann nicht erstellt werden
2016-10-04T14: 09: 19.397712Z 0 [FEHLER] konnte den Datenpfad nicht auf /usr/local/mysql-5.7.14-osx10.11-x86_64/data/ setzen
2016-10-04T14: 09: 19.397776Z 0 [FEHLER] Abbruch
2016-10-04T14: 09: 19.397795Z 0 [Hinweis] Binlog-Ende
2016-10-04T14: 09: 19.397925Z 0 [Hinweis] mysqld: Herunterfahren abgeschlossen

2. Sudo chown -R _mysql:_mysql /usr/local/mysql-5.7.14-osx10.11-x86_64

Notieren Sie den MySQL-Ordnerpfad /usr/local im vorherigen Protokoll und in meinem Fall war mysql-5.7.14-osx10.11-x86_64 , und Sie müssen Aktualisieren Sie es basierend auf dem Protokoll, das Sie auf Ihrem Computer erhalten, um Lesezugriff in das MySQL-Verzeichnis

3. Sudo /usr/local/mysql/support-files/mysql.server start

Starten von MySQL
ERFOLG!

Es fehlt die Berechtigung zum Erstellen des Verzeichnisses/var/run/mysqld. Bitte erstellen und erteilen Sie die folgenden Berechtigungen.

• mkdir -p/var/run/mysqld
• chown mysql: mysql/var/run/mysqld

Für mich hat ein Update das Problem gelöst:

Auf Ubuntu:

Sudo apt-get update
Sudo apt-get upgrade

Auf CentOS:

Sudo yum update

Mein Serverspeicher war voll, dies verhinderte das Starten von MySQL. Habe die Idee von hier . Durch Erhöhen der HD und Neustarten wurde das Problem behoben.

Sie können zunächst überprüfen, ob der Dienst ausgeführt wird:

ps ax | grep mysql

Ich habe diese Antwort erhalten:

6104 pts/0    S      0:00 /bin/sh /usr/bin/mysqld_safe
6431 pts/0    Sl     0:01 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --pid-file=/var/run/mysqld/m

Keine Antwort bedeutet, dass der Dienst nicht ausgeführt wird.

service  mysql start

Kopieren Sie einfach Ihre /opt/lampp/etc/my.cnf -Datei nach /etc/mysql/my.cnf.

Und im Terminaltyp:

mysql -u root

Sie erhalten die Eingabeaufforderung mysql>:

mysql> Update mysql.user set Password=PASSWORD('your_password') where user='root';

mysql> FLUSH PRIVILEGES;

Ich kann es nicht erklären, aber in Kubuntu 12.04.2 danach

Sudo apt-get autoremove Linux-Header-3.2.0-37 Linux-Header-3.2.0-37-generic

es fing an zu arbeiten

Installieren Sie den MySQL-Server:

Sudo apt-get install mysql-server
enter password as root

Einloggen:

mysql -u root -p root

Hier wurde -u user name und -p password bei der Installation von MySQL Server angegeben. Es wird so funktionieren, wie es für mich funktioniert hat.

In meinem Fall war das Problem eine Seitenbeschädigung in allen meinen Datenbanken (überprüfen Sie das mysql-Fehlerprotokoll).

Ich habe es mit Forcing InnoDB Recovery gelöst. Der Trick besteht darin, /etc/mysql/my.cnf zu bearbeiten und hinzuzufügen

innodb_force_recovery = 4

knapp unter

[mysqld]

Und dann starten Sie mysql neu. Nachdem Sie überprüft haben, ob alles korrekt funktioniert, entfernen Sie die Linie wieder.

For CentOS Linux release 7.3
The mysql.sock file path is /var/lib/mysql/mysql.sock
Edit /etc/my.cnf file and put below entry
This will solve your problem.

[client]
user=root
password=Passw0rd
port=3306
socket=/var/lib/mysql/mysql.sock
[mysqld]
bind-address=0.0.0.0

Starten Sie danach den Dienst neu

service mysql restart

Diese Antwort bezieht sich auf die Aktualisierung auf MySQL 5.6 auf Computern mit wenig RAM

Ich hatte das gleiche Problem beim Upgrade von MySQL 5.5 auf 5.6 auf meinem Debian 8 (Jessie). MySQL wurde nicht gestartet (der Status war aktiv/beendet) und das einfache Erstellen von service mysql start funktionierte nicht, da ich aus der /var/logs/mysql/error.log -Protokolldatei Folgendes herausgefunden habe:

InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(136019968 bytes) failed; errno 12
Cannot allocate memory for the buffer pool

Der Speicher reichte nicht: Ich hatte nur 256 MB RAM.

In MySQL gibt es eine Einstellung, performance_schema. Standardmäßig ist es in MySQL 5.5 deaktiviert.

https://dev.mysql.com/doc/refman/5.5/de/performance-schema-startup-configuration.html

In MySQL 5.6 ist die Standardeinstellung jedoch aktiviert. Fügen Sie einfach die folgende Zeile in die /etc/mysql/my.cnf -Datei ein und starten Sie sie neu.

performance_schema = off

Warnung: Wenn Sie diese Einstellung deaktivieren, können Leistungsprobleme auftreten. In einer Entwicklungsumgebung ist dies jedoch kein Problem.

Hier ist auch ein Artikel, der hilfreich sein kann, um MySQL so zu konfigurieren, dass nur minimaler Arbeitsspeicher verwendet wird: Konfigurieren von MySQL für die Verwendung von minimalem Arbeitsspeicher.

Wenn Sie Ubuntu verwenden, kann es sich um Privilegien handeln.

Überprüfen Sie Ihre Verzeichnisrechte. Es reicht nicht aus, in der Root-Gruppe zu sein. Verwenden Sie auch ein chmod für Verzeichnisse, die MySQL schreibt (zum Beispiel /var/run/mysqld/ für die Erstellung der mysqld.pid -Datei).

Das war hilfreich für mich.

Überprüfen Sie auch Ihren my.conf (/etc/mysql/my.cnf) und stellen Sie fest, ob die Bindeadresse auf 127.0.0.1 festgelegt ist.

Wenn nicht, kann dies zu diesem Problem führen.

Für mich war es:

Öffne /etc/mysql/my.cnf oder /etc/my.cnf und suche nach 'bind-address'. Es war 127.0.0.1. Ich habe es in localhost konvertiert, daher sollte das Zeilenergebnis 'bind-address = localhost' lauten.

Andernfalls sollten Sie Ihren MySQL-Server mit einer IP-Adresse ausführen, die in der Anweisung bind-address vorhanden war, d. H. mysql -h 127.0.0.1.

Ich hatte gerade dieses Problem und löste es.

Obwohl Sie mysql-server installiert haben, muss der Dämon ausgeführt werden, damit der Client eine Verbindung zu ihm herstellen kann.

Überprüfen Sie zunächst, ob der MySQL-Server ausgeführt wird:

netstat -tap | grep mysql

Sie sollten so etwas sehen:

$ Sudo netstat -tap | grep mysql
tcp        0      0 localhost:mysql         *:*          LISTEN     6639/mysqld     

Wenn der Server nicht ausgeführt wird, starten Sie den Dämon mit dem folgenden Befehl:

/etc/init.d/mysql restart

Dies sollte Ihr Problem lösen, wenn es installiert ist.

Einfache Lösung auf meinem Server: Nach der Migration auf einen neuen Debian 7-Server mit meinen MySQL-Datenbanken lautete die zweite lokale IP-Adresse 127.0.1.1 fehlt in meiner hosts-Datei . Das Hinzufügen dieser löste die Warnungen:

echo -e "\n127.0.1.1       $(hostname)" >> /etc/hosts

Um zu verhindern, dass das Problem auftritt, müssen Sie den Server ordnungsgemäß über die Befehlszeile herunterfahren, anstatt ihn auszuschalten.

shutdown -h now

Dies stoppt die laufenden Dienste, bevor der Computer heruntergefahren wird.

Basierend auf Centos können Sie mysql.sock auch verschieben, wenn Sie auf dieses Problem stoßen:

mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak

service mysqld start

Durch einen Neustart des Dienstes wird ein neuer Eintrag mit dem Namen mqsql.sock erstellt

Sie werden lokal ausgeführt, was bedeutet, dass Ihr Client auf demselben Computer wie Ihr Server ausgeführt wird.

Stellen Sie sicher, dass Ihr Unix-Benutzer tatsächlich /var/run/mysqld/mysqld.sock erreichen/lesen kann:

ls -als /var
ls -als /var/run
ls -als /var/run/mysqld
ls -als /var/run/mysqld/mysqld.sock

Wenn nicht, wenden Sie sich an Ihren Systemadministrator oder an Datenbankadministrator , um ausreichenden Lese-/Ausführungszugriff auf diese Verzeichnisse zu erhalten, oder verschieben Sie die Socket-Datei an einen anderen Ort.

Ich hatte das gleiche Problem. Ich habe das gefunden.

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’

Dies liegt daran, dass Sie den Dämon mysqld nicht ausführen, bevor Sie den MySQL-Client starten. Die Datei /var/lib/mysql/mysql.sock wird beim Ausführen der ersten Instanz von MySQL automatisch erstellt.

Reparieren:

Starten Sie zuerst den MySQL-Daemon und geben Sie dann mysql ein:

/etc/init.d/mysqld start
mysql

Ändern des MySQL-Root-Passworts

Standardmäßig ist das Root-Passwort für die MySQL-Datenbank leer. Es ist aus Sicherheitsgründen eine gute Idee, das MySQL-Root-Passwort durch ein neues zu ersetzen.

mysql> USE mysql;
mysql> UPDATE user SET Password=PASSWORD('newpassword') WHERE user='root';
mysql> FLUSH PRIVILEGES;

Überprüfen Sie dies, indem Sie sich anmelden:

mysql -u root -p
Enter Password: <your new password>

In Ubuntu 18:10 Linode 1GB Ram ist dieser Fehler aufgetreten. Nach der Prüfung von /var/log/mysql/error.log bin ich auf Folgendes gestoßen:

[Anmerkung] InnoDB: innodb_empty_free_list_algorithm wurde aufgrund der geringen Größe des Pufferpools in Legacy geändert. Erhöhen Sie den Pufferpool auf mindestens 20 MB, um das Backoff zu verwenden.

Ich habe mein Linode auf 2 GB aktualisiert und mariadb mit Sudo mysql neu gestartet. Als nächstes wurde mysql_secure_admin ausgeführt, aber das Root-Passwort wurde nicht für den Benutzer festgelegt. Ich bin mir nicht sicher, aber es sieht so aus, als ob die Socke erstellt wurde, aber der Server wurde heruntergefahren, weil in meinem VPS nicht genügend Speicher vorhanden ist.

Sudo touch /var/lib/mysql/.force_upgrade
Sudo rcmysql restart

arbeitete für mich, als ich dieses Problem hatte

Dieser Fehler kann auch auftreten, wenn Sie versuchen, das Verzeichnis zu ändern, in dem die Datenbank gespeichert ist, aber das falsche Verzeichnis in der Konfigurationsdatei eingeben (wie ein Tippfehler auf dem zweiten Laufwerk als D anstelle des genauen D_ ). Anstatt Ihnen mitzuteilen, dass das Tippfehlerverzeichnis nicht existiert, wird Ihnen mitgeteilt, dass Sie keine Zugriffsberechtigung haben (was Sie dazu veranlasst, die Berechtigungen für das Tippfehlerverzeichnis zu ändern, was Sie auch tun können). Wenn Sie diesen Fehler beim Wechseln des Verzeichnisses erhalten, überprüfen Sie die Konfigurationsdatei noch einmal und vergewissern Sie sich, dass Sie keinen Tippfehler haben.

Haben Sie überprüft, ob LAMPP ausgeführt wird?

Sudo bash <path>/lampp start

Für mich ist der Weg

Sudo bash /opt/lampp/lampp start

Ich hatte auch dieses Problem und keine dieser Antworten half mir. Das Problem war anders, aber der Fehler war der vom OP beschriebene.

Ich überprüfe die Protokolle von MySQL in /var/log/mysql und habe Folgendes gesehen:

150309  5:03:19 [ERROR] /usr/sbin/mysqld: unknown variable   'lower_case_tables_names=1'

Ich habe die Datei /etc/mysql/my.cnf geöffnet und diese Zeile # kommentiert. Danach konnte ich mich mit der Datenbank verbinden.

Ehrlich gesagt weiß ich nicht, was das Problem war. Der Linodeserver sollte wegen Wartungsarbeiten neu gestartet werden, und dieser Fehler kam von ungefähr.

Sie sollten den Eigentümer der Gruppe für /var/run/mysqld überprüfen. Wenn es nicht mysql.mysql ist, dann mache:

su root
chown mysql.mysql /var/run/mysqld

Möglicherweise liegt ein Problem mit der Konfigurationsdatei vor. Ich hatte ein ähnliches Problem und konnte im Internet keine Lösung finden. Mir ist aufgefallen, dass ich zwei my.cnf -Dateien hatte, eine in /etc/mysql und die andere in /etc. Folgen Sie den unteren Schritten:

1. Suchen Sie mit my.cnf nach locate my.cnf Dateien auf Ihrem Computer.

2. Wenn zwei Einträge vorhanden sind, d. H. /etc/my.cnf und /etc/mysql/my.cnf, benennen Sie /etc/mysql/my.cnf in etwas anderes um, z. B. /etc/mysql/my.cnf.old

Versuchen Sie erneut, MySQL auszuführen.

In meinem Fall lag es nur daran, dass mysql wegen des fehlenden Ordners /var/log/mysql gestoppt wurde, der in /etc/mysql/my.cnf definiert ist. Nachdem ich es erstellt hatte, konnte ich mysql starten und es lief wie gewohnt.

Ein Upgrade von MySQL hat es für mich behoben. Führen Sie auf RHEL-basierten Servern einfach Folgendes aus:

Sudo yum upgrade mysql-server

Ich habe dieses Problem gelöst, indem ich diese Zeile aus meinem /etc/mysql/my.conf im Abschnitt mysqld entfernt habe ([mysqld]):

default-character-set=utf8

Neustart und es funktioniert gut.

Ich hatte dies auf Ubuntu und wie ich herausgefunden habe, gab es mehr als eine Instanz von mysqld.

Es sah so aus, als ob der vorherige nicht vollständig gestoppt wurde, während der neue bereits gestartet ist. Das Ausführen von '/etc/init.d/mysql stop' hat nicht geholfen, es gab immer 'OK' zurück und eine neue Instanz wurde sofort danach automatisch gestartet:

        $ Sudo /etc/init.d/mysql stop
         * Stopping MySQL database server mysqld        [ OK ] 
        $ pgrep mysql
        28315
        $ Sudo /etc/init.d/mysql stop
         * Stopping MySQL database server mysqld        [ OK ] 
        $ pgrep mysql
        28570
        $ Sudo /etc/init.d/mysql stop
         * Stopping MySQL database server mysqld        [ OK ] 
        $ pgrep mysql
        28763
        ..... etc ...

Glücklicherweise hat der folgende Befehl das Problem behoben:

    $ Sudo service mysql stop
    mysql stop/waiting

    $ ps -ef | grep mysql
    29841 26858  0 10:59 pts/8    00:00:00 grep --color=auto mysql <--- IT's gone ! 

Danach konnte ich mysql erneut starten und feststellen, dass mysql.sock erfolgreich erstellt wurde.

Ein Tipp: Fragen Sie immer MySQL, wo das Problem liegt. In meinem Fall less /var/log/mysql/error.log und siehe dies:

2015-07-28 12:01:48 23224 [ERROR] /usr/sbin/mysqld: unknown variable 'log_slow_queries=/var/log/mysql/mysql-slow.log'
2015-07-28 12:01:48 23224 [ERROR] Aborting

Es beklagt sich, weil ich diese Option in my.cnf nicht kommentiert habe, aber nachdem ich diese Option kommentiert habe, hat sie ohne Probleme begonnen.

Überprüfen Sie in /etc/mysql/my.cnf die letzte Zeile:

!includedir /etc/mysql/conf.d/

Diese Antwort wird wahrscheinlich hier ertrinken, aber vielleicht stößt jemand versehentlich darauf.

In meinem Fall hat SELinux den Benutzer/die Anwendung daran gehindert, eine Verbindung zum MySQL (MariaDB) -Server-Socket herzustellen. Überprüfen Sie auf RHEL /var/log/audit/audit.log, wenn Sie SELinux aktiviert haben.