it-swarm.com.de

Der Start des MySQL-Servers ist fehlgeschlagen

Ich verwende Ubuntu Server. Als ich versuchte, mich bei mysql anzumelden (das lief), bekam ich den folgenden Fehler

ERROR 2002 (HY000): Can't connect to local MySQL server through socket         '/var/run/mysqld/mysqld.sock' (2)

Die Datei mysqld.sock befindet sich jedoch nicht im Ordner /var/run/mysqld. Als ich den Befehl ps aux | grep mysql ausführte, stellte ich fest, dass der MySQL-Server nicht lief.

Ich habe dann versucht, den MySQL-Server mit neu zu starten

service mysql start
service mysql restart
/etc/init.d/mysql start

Der Startvorgang schlug jedoch in allen drei Fällen fehl. /var/log/mysql/mysql.log und /var/log/mysql/mysql.err Dateien sind leer.

Aber /var/log/error.log zeigt folgende Informationen an:

140425 12:49:05 [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.
140425 12:49:05 [Note] Plugin 'FEDERATED' is disabled.
140425 12:49:05 InnoDB: The InnoDB memory heap is disabled
140425 12:49:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140425 12:49:05 InnoDB: Compressed tables use zlib 1.2.8
140425 12:49:05 InnoDB: Using Linux native AIO
140425 12:49:05 InnoDB: Initializing buffer pool, size = 3.0G
140425 12:49:05 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 26214400 bytes!
140425 12:49:05 [ERROR] Plugin 'InnoDB' init function returned error.
140425 12:49:05 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140425 12:49:05 [ERROR] /usr/sbin/mysqld: unknown variable 'record_buffer=64M'
140425 12:49:05 [ERROR] Aborting

140425 12:49:05 [Note] /usr/sbin/mysqld: Shutdown complete
27
ananth

Öffne ein Terminal (Ctrl+Alt+t) und mache folgendes:

Sudo service mysql stop
Sudo rm /var/lib/mysql/ib_logfile0
Sudo rm /var/lib/mysql/ib_logfile1

und kommentiere die Zeile record_buffer=64M in /etc/mysql/my.cnf aus [1]

und starte dann msyql neu mit:

Sudo service mysql restart

(Quelle)

25
jobin

Dies löste mein Problem:

mkdir /var/run/mysqld

touch /var/run/mysqld/mysqld.sock

chown -R mysql /var/run/mysqld

/etc/init.d/mysql restart

9
user520064

Ich habe das Problem folgendermaßen gelöst:

chown -R mysql:mysql /var/lib/mysql
mysql_install_db --user=mysql -ldata=/var/lib/mysql/

In einem anderen Kontext war ich damit konfrontiert, weil der mysql-daemon nicht gestartet werden konnte. Starten Sie den Daemon also mit dem Befehl - mysqld start und versuchen Sie dann, den Dienst zu starten.

7
Sudheesh.M.S

Ich hatte die gleiche Fehlermeldung und die gleiche Leere in den Protokolldateien. In meiner Konfigurationsdatei (my.cnf) hatte ich angegeben, dass ich myisam-Tabellen verwenden möchte, indem ich diese Zeile im Abschnitt [mysqld] hinzufügte:

default-table-type = myisam

Nach dem Upgrade von MySQL scheint es, dass MySQL nicht startet. Ich habe dies geändert zu:

default-storage-engine = myisam

und jetzt funktioniert alles gut.

2

In meinem Fall war es ein Platzproblem. Überprüfen Sie, ob noch genügend Platz vorhanden ist.

von /var/log/mysql/error.log Ich habe einige Hinweise aus zwei Zeilen:

2018-08-04T05:25:29.519139Z 0 [ERROR] InnoDB: Write to file ./ibtmp1failed at offset 3145728, 1048576 bytes should have been written, only 704512 were writt$
2018-08-04T05:25:29.519145Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'

Ich konnte sehen, dass es sich um ein Raumproblem handelt.

[email protected]:/home/user1# df -h
Filesystem                            Size  Used Avail Use% Mounted on
udev                                  477M     0  477M   0% /dev
tmpfs                                 100M   11M   89M  11% /run
/dev/mapper/server1--osticket--vg-root  8.3G  7.9G     0 100% /
tmpfs                                 497M     0  497M   0% /dev/shm
tmpfs                                 5.0M     0  5.0M   0% /run/lock
tmpfs                                 497M     0  497M   0% /sys/fs/cgroup
/dev/vda1                             472M  467M     0 100% /boot
tmpfs                                 100M     0  100M   0% /run/user/1000

Von hier aus konnte ich feststellen, dass auf dem virtuellen Server /dev/mapper/server1--osticket--vg-root 8.3G 7.9G 0 100% / nicht mehr genügend Speicherplatz vorhanden war. Ich überlegte, ob ich das virtuelle Laufwerk migrieren oder vergrößern sollte, beschloss jedoch, zunächst nicht benötigte Dateien zu entfernen.

Also mussten Cache und nicht benötigte Dateien bereinigt werden:

#apt-get clean
#apt-get -f autoremove

Vergessen Sie anschließend nicht, die durch mysql beschädigten Protokolldateien zu entfernen. Sie würden erneut generiert, wenn Sie mysql neu starten

#service mysql stop
#cd /var/lib/mysql
#rm ib_logfile*
#service mysql start

Überprüfen Sie Ihren MySQL-Server-Dienst und es ist wahrscheinlich in Betrieb

[email protected]:/var/lib/mysql# service mysql status
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-08-04 23:07:24 WAT; 7min ago
  Process: 1559 ExecStartPost=/usr/share/mysql/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 1549 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 1558 (mysqld)
    Tasks: 29
   Memory: 280.3M
      CPU: 589ms
   CGroup: /system.slice/mysql.service
           └─1558 /usr/sbin/mysqld

Aug 04 23:07:19 server1-osticket systemd[1]: Starting MySQL Community Server...
Aug 04 23:07:24 server1-osticket systemd[1]: Started MySQL Community Server.
[email protected]:/var/lib/mysql#

Fall abgeschlossen. Ich hoffe, es hilft.

1
sukupandachu

Das Erhöhen des verfügbaren RAM durch Hinzufügen eines neuen Swap-Bereichs kann ebenfalls hilfreich sein. Schritte sind hier

Stellen Sie sicher, dass Sie eine/Swap-Datei erstellen, deren Größe kleiner ist als der von angegebene verfügbare Speicherplatz

df -h

Für mich war die Ausgabe von dfh zum Beispiel:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  1.2G  6.3G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            492M   12K  492M   1% /dev
tmpfs           100M  336K   99M   1% /run

Also habe ich mit 2 G erstellt

Sudo fallocate -l 2G /swapfile

Und dann einfach den Dienst starten

Sudo /etc/init.d/mysql restart

Hoffe das hilft. Alles Gute.

1
Vivek

Meine Lösung:

Prüfen Sie, ob in allen /etc/rc1.d ... /etc/rc5.d das mysql-Skript mit S (Ex S10mysql) und nicht mit K AS K10mysql beginnt.

Erläuterung: K Präfix lädt mit Stop, Art des Kill-Service; und S Präfix beginnt mit Startparameter.

execute in terminal:   
(command        script action  runlevel)
---------------------------------------
Sudo update-rc.d mysql enable  2
Sudo update-rc.d mysql enable  3
Sudo update-rc.d mysql enable  4
Sudo update-rc.d mysql enable  5
1
Sergio Abreu

Der folgende Befehl behebt mein Problem und MySQL könnte danach gestartet werden.

chown -R mysql: /var/lib/mysql
0
Yusef Mohamadi

Entfernen Sie die Datei /var/lib/mysql/.run-mysql_upgrade und es sollte starten

;)

"Mit großer Kraft geht große Verantwortung einher"

0
Adrian Pule

Ich hatte dieses Problem, als ich max_allowed_packet = 0.5M in /etc/mysql/my.cnf eingestellt habe.

Ich habe es gelöst, indem ich max_allowed_packet in 1M geändert habe.

0
ratskin