mysql läuft nicht - mysqld.sock fehlt

[Yvo]

Hi,

mir ist klar, dass ich hier ein uraltes Thema ausgrabe, aber ich habe genau dieses Problem jetzt auf einem Server mit Jessie.

Die Anwendungen, die eine Datenbank brauchen, werden hier nicht oft angefasst, was nicht heißen soll, dass die Datenbank unwichtig ist, gerade wäre es sehr essentiell, an die Inhalte zu kommen
Ich kann dadurch nur nicht genau eingrenzen, seit wann mysql nicht mehr läuft, gehe aber davon aus, dass das seit dem kürzlichen Reboot so ist (VServer wurde neu gestartet).

Ich durchforste das Internet jetzt schon seit einigen Stunden und komme kein Stück weiter. Das Socket ist und bleibt verschwunden und MySQL lässt sich daher nicht starten.
Gibt es irgendwelche Hinweise für Jessie, was man tun kann? Ich nehme gerne auch einen Workaround ohne Socket, wenn ich nur wüsste wie...

Ich hoffe auf euch!

Liebe Grüße
Yvonne

[Blackbox]

Hallo Yvonne,

darf man fragen, warum du einen Thread von 2004 bzw. 2005 ausgräbst, anstatt ein neues Thema zu öffnen?
Das ist so nicht gedacht.
Vielleicht sollte das neue Posting abgetrennt werden?

Mittlerweile wird in Debian meines Wissen nach mariadb-client und mariadb-server verwendet.
mysql-client und mysql-server sind lediglich bis Debian Stretch (oldstable) im Debian Repository verfügbar.

[novalix]

Die Informationen sind verdammt dünn, um sinnvoll zu helfen.
Was heißt hier "Vserver"? Welche Virtualisierung wird verwendet? Besteht Kontrolle über den Host?

Die Ausgabe von

Code: Alles auswählen

systemctl status mysql

wäre interessant.
Darin findest Du im Falle eines Fehlers auch einen Vorschlag für einen Befehl, der weitere Informationen aus dem journal zieht.
Ansonsten kannst Du auch nach der unit filtern:

Code: Alles auswählen

journalctl -u mysql

Oldoldstable war damals schon alt.

[TRex]

Ich glaskugle mal und behaupte, die Logs (bzw journal) würden schreiben, dass der Socket nicht angelegt werden könne, weil ein Verzeichnis dorthin fehlt (das nach dem Neustart nicht wieder angelegt wurde). Sowas in der Art hatte ich schon ein paar Male mit mysql. Lösung besteht darin, besagtes Verzeichnis wieder anzulegen und herauszufinden, wieso das nicht von alleine passiert (wenn der Pfad in einer ramdisk liegt, muss das ja irgendein Mechanismus sicherstellen).

[novalix]

Soweit orakuliere ich konform mit Dir.
Nur die Ramdisk sehe ich lediglich in einer vollständigen Virtualisierung. Der Terminus "Vserver" kann aber auch Container bedeuten.
Dann ist es wohl eher ein Schluckauf der cgroups o.Ä.

Der Plan sollte zwei Stufen beinhalten:
1. Das Ding wieder zum laufen bringen
2. Herausfinden, warum es bei Neustart nicht einfach funktioniert

Wir haben bislang auch keine Angaben über die bereits verwendeten Maßnahmen der Analyse und der Reparatur.

[Yvo]

Ich hatte leider nicht wie gewohnt Benachrichtigungen bekommen, dass ihr mir geschrieben habt und dachte, mir antwortet keiner

Gelöst ist mein Problem leider immer noch nicht, aber immerhin weiß ich nun, warum meine log-files leer waren, ich habe in /var/log/mysql.err geschaut und es gibt auch noch /var/log/mysql/error.log

Darin steht nun wenigstens ein konkreter Hinweis:

Code: Alles auswählen

191214 14:08:42 [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.
191214 14:08:42 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
191214 14:08:42 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
191214 14:08:42 InnoDB: The InnoDB memory heap is disabled
191214 14:08:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins
191214 14:08:42 InnoDB: Compressed tables use zlib 1.2.8
191214 14:08:42 InnoDB: Using Linux native AIO
191214 14:08:42 InnoDB: Initializing buffer pool, size = 128.0M
191214 14:08:42 InnoDB: Completed initialization of buffer pool
191214 14:08:42 InnoDB: highest supported file format is Barracuda.
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
191214 14:08:42  InnoDB: Waiting for the background threads to start
191214 14:08:43 InnoDB: 5.5.62 started; log sequence number 0
191214 14:08:43 InnoDB: !!! innodb_force_recovery is set to 6 !!!
191214 14:08:43 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
191214 14:08:43 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
191214 14:08:43 [Note] Server socket created on IP: '127.0.0.1'.
191214 14:08:43 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
191214 14:12:34 [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.
191214 14:12:34 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
191214 14:12:34 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
191214 14:12:34 InnoDB: The InnoDB memory heap is disabled
191214 14:12:34 InnoDB: Mutexes and rw_locks use GCC atomic builtins
191214 14:12:34 InnoDB: Compressed tables use zlib 1.2.8
191214 14:12:34 InnoDB: Using Linux native AIO
191214 14:12:34 InnoDB: Initializing buffer pool, size = 128.0M
191214 14:12:34 InnoDB: Completed initialization of buffer pool
191214 14:12:34 InnoDB: highest supported file format is Barracuda.
191214 14:12:34  InnoDB: Waiting for the background threads to start
191214 14:12:35 InnoDB: 5.5.62 started; log sequence number 24205857
191214 14:12:35 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
191214 14:12:35 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
191214 14:12:35 [Note] Server socket created on IP: '127.0.0.1'.
191214 14:12:35 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
(END)

Ja, ich habe innodb_force_recovery stückweise hochgesetzt, nachdem ich gegooglet hatte, hat aber keinerlei Wirkung gezeigt, außer, dass danach was im log stand. Wenn ich jetzt ohne den Parameter einen restart probiere, gibt es keinen neuen Log-Eintrag. Ich habe offen gesagt keine Ahnung, ob ich InnoDB verwende - falls das Standard ist, ja.

Wenn ich nun auf der Kommandozeile mysql_upgrade eingebe, passiert das:

Code: Alles auswählen

Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Error: Failed while fetching Server version! Could be due to unauthorized access.
FATAL ERROR: Upgrade failed

Ich habe es auch schon mit -u und -p probiert. Ich weiß nur nicht so recht, welchen user is angeben muss. mysql-root? root? die probierten PWs sollten die richtigen sein...

Es wird kein Weihnachtsgebäck geben, wenn sich das Problem nicht lösen lässt die Rezepte stehen nämlich in meinem Wiki und damit in der Datenbank
Ich hoffe auf euch

[Yvo]

Wenn mir jemand helfen kann, meine Datenbank und damit mein Wiki wieder zum Laufen zu bringen, backe ich Weihnachtsgebäck nach dem Rezept aus dem Wiki und schicke dem entscheidenden Hinweisgeber ein Päckchen zu

[TRex]

Hat root@localhost denn ein Passwort von dir bekommen? AFAIK ist da normalerweise keins.

Ach ja, und mach, falls keins existiert, ein Backup des data-Verzeichnis. Falls eins existiert, spiel das mal ein. Schau, ob das richtige data-Verzeichnis verwendet wird (der findet ja gefühlt überhaupt nichts, kann sein, dass darum auch der login nicht funktioniert). Poste die my.cnf auf nopaste, schau darin nach datadir und kontrolliere den Inhalt (keine Ahnung, wie groß deine Datenbank ist oder war, Dateidatum, so Dinge). Such die Dateinamen darin an anderen Orten, wenn das nicht den Anschein erweckt, als ob es deine Daten wären (find / -name XXX).

Wenn du kein Backup hast, wäre danach ne gute Zeit, sich darüber Gedanken zu machen.

[Yvo]

Wenn ich bei der Installation nicht dazu aufgefordert wurde, habe ich kein PW vergeben.

Meine my.cnf ist jetzt hier: http://nopaste.debianforum.de/40937

Von /var/lib/mysql habe ich inzwischen eine Kopie erstellt, leider aber erst nachdem das Problem aufgetreten ist
Und ja, wenn es wieder läuft, kümmere ich mich als erstes um ein Backup Bislang habe ich immer nur einen SQL-Dump der Datenbank gemacht, bevor ich irgendetwas größeres angefasst habe, habe einfach nicht damit gerechnet, dass die Datenbank ohne mein Zutun aufhört zu funktionieren. Hinterher ist man immer schlauer...
Immerhin ist der Inhalt des Data-Verzeichnises auf dem Server größer und enthält mehr Dateien als ein komplett jungfreulicher Ordner (ich habe jetzt mal mysql-server auf meinem lokalen Rechner installiert zum Vergleich). In Summe ist die Datenbank aber eher ziemlich klein, im wesentlichen 3 MediaWikis und MediaWiki legt ja hochgeladene Dateien wieder in eigenen Ordnern ab, iirc. Die Inhalte der Wikis sind nicht wahnsinnig umfangreich, aber einiges steht nur darin und dabei geht es nicht nur um Rezepte, sonst würde ich nicht so viel Zeit damit verbringen.

Sollte es nun theoretisch reichen "mysql_upgrade" auf der console einzugeben? Oder müsste dafür mysql laufen und man es in der mysql-console eingeben? Dann hätte ich ein Henne-Ei-Problem.
Oder bin ich damit völlig auf dem Holzweg? Ist nur der einzige Anhaltspunkt, den ich momentan habe.

[Yvo]

Wenn ich wie hier: https://support.plesk.com/hc/en-us/arti ... is-damaged beschrieben die eine Zeile in my.cnf einfüge, kann ich mysql starten, sehe aber überhaupt keine Datenbank darin und bekomme noch immer:

Code: Alles auswählen

root@adler:/# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Error: Failed while fetching Server version! Could be due to unauthorized access.
FATAL ERROR: Upgrade failed

[novalix]

Die Fehlermeldungen in Deinem Link und in Deinem Log unterscheiden sich allerdings deutlich.
In Deinem Log steht, dass die Tabellen "plugin" und "host" nicht gefunden werden, nicht dass sie beschädigt seien und auch nicht, dass mysql_upgrade den Fehler beheben könnte.

Was ergeben denn (als root):

Code: Alles auswählen

ls -l /var/lib/mysql/mysql/host.*
ls -l /var/lib/mysql/mysql/plugin.*

Falls die Tabellen tatsächlich nicht mehr vorhanden sein sollten, wird eine Reparatur kniffelig.
Möglicherweise wäre eine vollständige Neuinstallation des Datenbanksystems, das Neuerstellen der Datenbanken und Einspielen der Backups die einfachere Methode, falls Deine Dumps einigermaßen aktuell sind.

[Yvo]

Das gibt es alles nicht:

Code: Alles auswählen

root@adler:~# ls -al /var/lib/mysql/
insgesamt 53352
drwxr-xr-x  5 mysql mysql     4096 Dez 16 00:45 .
drwxr-xr-x 45 root  root      4096 Dez 15 23:36 ..
-rw-rw----  1 mysql mysql      246 Nov  5 06:16 adler.log
-rw-rw-rw-  1 mysql mysql    16384 Nov 12  2016 ..\bin\te62.dll
-rw-rw-rw-  1 mysql mysql    12288 Nov 12  2016 ..\bin\te82.dll
-rw-rw----  1 mysql mysql      272 Nov  5 06:16 C:wampwwwl.php
-rw-rw-rw-  1 mysql mysql     9372 Nov 12  2016 c:\windows\temp\zzxc.tmp
-rw-r--r--  1 mysql mysql        0 Okt  7 22:16 debian-5.5.flag
-rw-rw----  1 mysql mysql 44040192 Dez 16 00:46 ibdata1
-rw-rw----  1 mysql mysql  5242880 Dez 16 00:46 ib_logfile0
-rw-rw----  1 mysql mysql  5242880 Sep 15  2018 ib_logfile1
-rw-------  1 mysql mysql        6 Okt  7 22:16 mysql_upgrade_info
drwx------  2 mysql mysql     4096 Okt  7 22:16 performance_schema
drwx------  2 mysql mysql     4096 Mär 25  2016 phpmyadmin
drwx------  2 mysql mysql     4096 Okt 25 05:53 PLEASE_READ_ME_VVV
-rw-rw-rw-  1 mysql mysql    16384 Nov 12  2016 \usr\lib\mysql\plugin\\te62.dll
-rw-rw-rw-  1 mysql mysql    12288 Nov 12  2016 \usr\lib\mysql\plugin\\te82.dll

Ich frage mich, was dieses C:\windows... ist. Auf dem Server läuft Linux und auf meinem Desktop-Rechner, von dem ich darauf zugreife, auch. Hat mich ein Windows-User gehackt und aus purer Zerstörungsfreude meine Datenbank gelöscht? Die Datei hat allerdings ein Datum von 2016 und kurz bevor ich dieses Thema hier aufgemacht habe, war mein Wiki noch da.

Die einzig halbwegs gute Nachricht: ich habe überhaupt einen Dump des Wikis ausgegraben bzw. aller drei Wikis, für jedes ein einzelner Dump. Stolze 3,5 Jahre alt, stammen vom letzten Server-Umzug, aber Wiki-Inhalte von 3 Jahren verlieren wäre mir immer noch lieber als Wiki-Inhalte von > 10 Jahren verlieren und ich weiß, dass der größte Teil der Artikel in den ersten Jahren entstanden ist.

Wie seht ihr die aktuelle Situation? Besteht noch eine Chance oder sollte ich mit den Dumps anfangen? Falls Dumps, wie gehe ich jetzt am geschicktesten vor?

Code: Alles auswählen

apt-get remove --purge mysql-server mysql-client mysql-common -y 

und von Null anfangen? Vorher auf dem lokalen Rechner ausprobieren? Brauche ich eine ältere Version von mysql oder kann man die Dumps problemlos in eine neuere Version einspielen?
Ich bin sicher, ich habe mir beim letzten Server-Umzug genau aufgeschrieben, wie ich vorgegangen bin - steht im Wiki

[mig]

Hi

Google mal nach PLEASE_READ_ME_VVV (aus deinen directory listing)

Ich finde da: https://www.bitcoinabuse.com/reports/1r ... chsK221dFc

Wenn dem so ist würde ich den kompletten Server platt machen, und auch dem Rest des, von diesen Server aus, zugänglichen Netzwerkes nur _sehr_ bedingt vertrauen.

Tut mir leid aber töte nicht den Boten.

LG
Michael

Edit: Typo

[Yvo]

Ja, ich habe auch gegooglet und sehe das genauso wie du

Nichts desto trotz, ich will an die Daten aus dem Wiki noch mal ran, zumindest an mein 3 Jahre altes Backup. Es muss nur kurzfristig laufen, dann copy-paste der wichtigsten Artikel in andere Speicher-Medien. Da mein Setup mit mehreren Wikis und trotzdem Installation aus den Debian-Sourcen nicht ganz trivial ist, geht's wahrscheinlich am schnellsten, wenn ich das noch mal auf dem Server wiederbelebe.
D.h. dann wirklich purge mysql, mysql neu installieren, dumps rein, oder? Oder habt ihr andere Tipps?

Danach gebe ich meine Wikis dann auch ganz auf...

Die dumps liegen auf meinem Desktop-Rechner, denen ist also sicher nichts passiert. Und es ist ein VServer bei HostEurope, insofern gibt es kein Netzwerk außenrum, das von diesem Server aus zugänglich ist.

LG
Yvonne

[Yvo]

Siehe auch: viewtopic.php?f=15&t=175830