• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

mysql startet nicht mehr

kaiwe

Newbie
Ich habe meinen opesuse 13.2 Server mit init 0 heruntergefahren und nach einigen Stunden wieder gestartet.
Alle Dienste ( ssh, apache, samba ) lassen sich problemlos starten, nur der mysql Dienst bringt untenstehende
Fehlermeldung.

Die verschiedenen Lösungsansätze im Internet ( Rechte setzen usw. ) waren nicht erfolgreich, zumal an der Config
nichts geändert wurde, der Server war einfach nur aus.

Kann mir hier bitte jemand helfen ?

Vielen Dank schon mal !


Code:
DESTASWW02:~ # systemctl status mysql.service
mysql.service - MySQL server
   Loaded: loaded (/usr/lib/systemd/system/mysql.service; disabled)
   Active: activating (start-post) (Result: exit-code) since Sat 2016-07-30 17:15:17 CEST; 19s ago
  Process: 11433 ExecStart=/usr/lib/mysql/mysql-systemd-helper start default (code=exited, status=1/FAILURE)
  Process: 11424 ExecStartPre=/usr/lib/mysql/mysql-systemd-helper upgrade default (code=exited, status=0/SUCCESS)
  Process: 11416 ExecStartPre=/usr/lib/mysql/mysql-systemd-helper install default (code=exited, status=0/SUCCESS)
 Main PID: 11433 (code=exited, status=1/FAILURE);         : 11434 (mysql-systemd-h)
   CGroup: /system.slice/mysql.service
           ââcontrol
             ââ11434 /bin/bash /usr/lib/mysql/mysql-systemd-helper wait default
             ââ11499 sleep 1

Jul 30 17:15:17 DESTASWW02 mysql-systemd-helper[11434]: Waiting for MySQL to start
Jul 30 17:15:17 DESTASWW02 mysql-systemd-helper[11433]: 2016-07-30 17:15:17 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server opti...ore details).
Jul 30 17:15:17 DESTASWW02 mysql-systemd-helper[11433]: 2016-07-30 17:15:17 0 [Note] /usr/sbin/mysqld (mysqld 5.6.30) starting as process 11433 ...
Jul 30 17:15:18 DESTASWW02 systemd[1]: mysql.service: main process exited, code=exited, status=1/FAILURE
Hint: Some lines were ellipsized, use -l to show in full.
 

marce

Guru
was sagt das Log von MySQL selbst? Alternativ mal direkt an der Konsole starten außerhalb von init / systemd - dann sollte er ausspucken, was ihn ärgerrt.
 
OP
K

kaiwe

Newbie
Hallo,

danke für die schnelle Antwort !!!

Ich kann mir nicht erklären, was da kaputt sein sollte, ich habe den Server nur heruntergefahren und dann wieder rauf ...


Im /var/log/mysql/mysqld.log steht folgendes
Code:
InnoDB: End of page dump
2016-07-30 18:25:52 7f33b434e740 InnoDB: uncompressed page, stored checksum in field1 16843009, calculated checksums for field1: crc32 1329801086, innodb 1910826816, none 3735928559, stored checksum in field2 16843009, calculated checksums for field2: crc32 1329801086, innodb 1091675344, none 3735928559, page LSN 16843009 16843009, low 4 bytes of LSN at page end 16843009, page number (if stored to page already) 16843009, space id (if created with >= MySQL-4.1.1 and stored already) 16843009
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 776.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
2016-07-30 18:25:52 7f33b434e740  InnoDB: Assertion failure in thread 139860043425600 in file buf0buf.cc line 4295
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:25:52 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68095 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x7f33b4a83cec]
/usr/sbin/mysqld(handle_fatal_signal+0x481)[0x7f33b481c851]
/lib64/libpthread.so.0(+0xf870)[0x7f33b2e5d870]
/lib64/libc.so.6(gsignal+0x37)[0x7f33b22bc0a7]
/lib64/libc.so.6(abort+0x118)[0x7f33b22bd458]
/usr/sbin/mysqld(+0x8883a8)[0x7f33b4c033a8]
/usr/sbin/mysqld(+0x89bd98)[0x7f33b4c16d98]
/usr/sbin/mysqld(+0x883345)[0x7f33b4bfe345]
/usr/sbin/mysqld(+0x848c32)[0x7f33b4bc3c32]
/usr/sbin/mysqld(+0x83e23f)[0x7f33b4bb923f]
/usr/sbin/mysqld(+0x83ee45)[0x7f33b4bb9e45]
/usr/sbin/mysqld(+0x83fdf7)[0x7f33b4bbadf7]
/usr/sbin/mysqld(+0x8299ae)[0x7f33b4ba49ae]
/usr/sbin/mysqld(+0x767d1c)[0x7f33b4ae2d1c]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x7f33b4760878]
/usr/sbin/mysqld(+0x528531)[0x7f33b48a3531]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x940)[0x7f33b48a99b0]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x8b8)[0x7f33b475a368]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f33b22a8b05]
/usr/sbin/mysqld(+0x3d22ad)[0x7f33b474d2ad]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
 

Sauerland

Ultimate Guru
https://www.opensuse-forum.de/thread/36948-mysql-startet-nicht-mehr/

Bitte einmal lesen:
http://linux-club.de/forum/viewtopic.php?f=86&t=76935
 
OP
K

kaiwe

Newbie
sorry, das wusste ich nicht.

Ich kümmere mich - wie beschrieben - darum, dass es nicht zu Dopplungen oder sonstigen
Effekten kommt.

Vielen Dank für die Info !
 

marce

Guru
im Log stehen ja so ein paar potentielle Möglichkeiten. Frage 1 - hast Du ein Backup? Wenn ja - einspielen. Wenn nein - versuch einen Table-repair. Oder anders herum. Dürfte im Prinzip egal sein...
 
OP
K

kaiwe

Newbie
jetzt wird's peinlich .. Ich habe leiden kein BackUp :-(

Dumme Frage: Wie soll ich ein Table Repair machen, wenn die Datenbank gar nicht startet ?

Ich bin zugegebenermaßen ein ziemlicher Anfänger, was diese Sache angeht.
 

marce

Guru
kaiwe schrieb:
Dumme Frage: Wie soll ich ein Table Repair machen, wenn die Datenbank gar nicht startet ?
Dumme Antwort: Schon mal (1) Google befragt ("mysql repair table") oder - völlig innovativer Gedanke - die (2) Doku gelesen?

(1) führt übrigens meist zu (2)...

Anfänger sein ist übrigens nicht schlimm - jeder hat mal angefangen.
 

Sauerland

Ultimate Guru
Dumme Frage: Wie soll ich ein Table Repair machen, wenn die Datenbank gar nicht startet ?
Und Links im anderen Forum werden auch nicht gelesen?
Wurde schon vor 2 Std. gepostet.........

Geht übrigens in dieselbe Richtung wie marce`s Tips.........

Und drüben ist geschlossen.
 
OP
K

kaiwe

Newbie
Hallo,
ich habe jetzt ausgiebig im GOOGLE gesucht, vieles probiert und bin leider nicht zum Erfolg gekommen.

Alle Lösungsansätze zielen entweder darauf ab, Befehle bei laufenden mysqld abzusetzen, oder sind nicht ausführbar.

Fehlermeldung bei Aufruf von mysqlcheck --repair --all-databases

Code:
mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysql/mysql.sock' (2) when trying to connect

Gibt es da noch eine Möglichkeit oder muss ich komplett neu installieren.


Vielen Dank schon mal !
 

marce

Guru
Auch die Doku zu dem Tool gelesen?

https://dev.mysql.com/doc/refman/5.5/en/mysqlcheck.html

Da ist ein Hinweis drin, was man den tun soll, wenn der MySQL nicht läuft.

Google liefert übrigens auch einen Hinweise, wie man MySQL selbst auffordern kann ,den Job beim Start zu übernehmen - z.b. mit https://www.devside.net/wamp-server/mysql-wont-start-because-of-innodb-table-corruption
 
OP
K

kaiwe

Newbie
Hallo marce,

den Beitrag habe ich eigentlich gelesen, aber scheinbar nicht genau genug ;-)

Danke schon mal !
 

marce

Guru
Ach ja - noch als dezenter Hinweis: Geschrottete Datenbankfiles (Ursache - warum auch immer, da solltest Du auch noch forschen, wie es denn dazu kam) lassen sich nicht unter allen Umständen wieder reparieren - und ein gewisses Maß an Datenverlust ist auch zu erwarten - je nach dem dann evtl. auch eine korrupte Datenbank bezüglich Foreign Keys / Fremdschlüsseln / Constraints / ...

Mit viel Pech lässt sich die DB auch gar nicht reparieren.

So oder so - da die Daten scheinbar wichtig sind, solltest Du Dir eine Backup-Lösung überlegen.
 
OP
K

kaiwe

Newbie
Hallo Marce,

vielen Dank für Deine Antwort.

Mein Problem ist, dass die einzelnen Datenbanken zwar relativ klein sind,
es aber sehr aufwändig wäre, diese Daten wieder einzupflegen.

Zustande gekommen ist die Sache dadurch, dass ich den Server aufgrund
organisatorischer Änderungen mit INIT 0 beendet habe und ca. 3 Std.
später wieder gestartet habe.

Das dürfte normalerweise kein Problem darstellen.

Mit dem BackUp hast Du natürlich mehr als recht ;-(

Besteht die Möglichkeit die Datenbankdateien zu tarballen und in
solchen Fällen dann mysql neu zu installieren und die Daten wieder
in das mysql Verzeichnis zu kopieren ?

Oder stelle ich mir das zu naiv vor.

Um gleich der Frage nach der Möglichkeit eines für ein paar € mietbaren
Managed Servers zu begegnen:

Ich habe MEINE Daten gerne bei MIR ...
 

gehrke

Administrator
Teammitglied
kaiwe schrieb:
Besteht die Möglichkeit die Datenbankdateien zu tarballen und in
solchen Fällen dann mysql neu zu installieren und die Daten wieder
in das mysql Verzeichnis zu kopieren ?
Ich halte es für unwahrscheinlich, dass eine Neu-Installation dieses Problem lösen wird.

Natürlich kannst Du die Dateien auf Dateisystemebene sichern, um beispielsweise einen Snapshot der Datenbank zu erzeugen. Dafür solltest Du aber unbedingt ein paar Restriktionen des RDBMS berücksichtigen, also beispielsweise den mysql-Daemon zuvor stoppen oder mysqldump verwenden. Siehe Dokumentation...

Jetzt wird es dir nicht mehr so viel helfen, höchstens um den Status Quo für Reperaturversuche zu sichern (um zu verhindern, dass noch weitere Schäden entstehen).

kaiwe schrieb:
Ich habe MEINE Daten gerne bei MIR ...
Selbstverständlich. Gerade dann musst Du dich aber auch um die Datensicherung kümmern.
 

bmk

Member
Hallo kaiwe,

vor den innodb-Datenbanken habe ich einen Heidenrespekt, da ich nicht genau weiß, wo genau sich die Daten befinden (myisam-Dateien lassen sich zur Not durch einfaches Kopieren sichern).

Daher nutze ich in den notwendigen Fällen immer die Option
Code:
innodb_file_per_table = ON
Damit hat jede Tabelle einen eigenen Bereich (*.ibd).
Ansonsten liegen alle Datenbanken und Tabellen in einem Paket (vermutlich) in der Datei ibdata1 samt den ib- und aria-Logfiles.

Möglicherweise (aber eher unwahrscheinlich) hat sich etwas in der Datei /etc/my.cnf geändert.
Änderungen in den buffer- und cache-Einstellungen bei mir schon zu heftigen Problemen geführt.

Vielleicht hast du Glück und nur Puffer/Caches sind defekt.

Dann kannst du zunächst versuchen, ein halbwegs "nacktes" mysql zu starten:

- Also zuerst den gesamten mysql-Baum an einen sicheren Ort kopieren.
- Dann im Hauptverzeichnis die aria- und ib-Dateien löschen.

Wenn mysql dann (mit einigen Fehlermeldungen) startet, ist wenigstens das in Ordnung.
Dann vielleicht mal die ibdata1 zurückkopieren und testen, was dann passiert.

Vielleicht hilfts ...
(andernfalls kannst du den gesicherten Baum zurückkopieren, falls es noch eine bessere Lösung geben sollte).

Gruß bmk
 
OP
K

kaiwe

Newbie
Danke für die Infos.

Ich bin jetzt ein gutes Stuck weiter ...

Nachdem ich die ( mächtig große ) Datei ibdata1 gelöscht habe, kann ich den mysqld wieder starten.

Jetzt funktionieren natürlich nur noch die MYISAM Datenbanken.

Die Frage wäre jetzt, ob die Möglichkeit besteht, diese Datei zu reparieren ?

Ich habe natürlich schon versucht, in GOOGLE zu suchen, aber nichts passendes gefunden.

Vielen Dank !
 
OP
K

kaiwe

Newbie
Hallo zusammen,

nachdem ich selbst ewig nicht weitergekommen bin, habe ich das Problem jetzt von einem professionellem
Dienstleister lösen lassen.

Der hat für die Sache eine halbe Stunde gebraucht, jetzt laufen die Datenbanken wieder.

Trotzdem danke für eure Mühen !
 
Oben