SQL MySQL startet nicht mehr

lordg2009

Lt. Commander
Registriert
Apr. 2009
Beiträge
1.543
Hi, ich habe ein Kali Linux (debian) in Virtual Box laufen.

Da gab es jetzt einen Fehler:
Erst hat er die Festplatte nicht starten können.
Wenn ich die Festplatte hinzufügen wollte, kam immer irgendwas von 'kann UUID nicht registrieren, da schon vorhanden'. Habe die vorhandene Platte dann entfernt und noch mal neu hinzugefügt. Nach dem starten kam ein Fehler, dass das Filesystem nicht intakt ist und ich müsse es mit fsck manuell testen. Die Grafikoberfläche ging gar nicht mehr. Habe das dann gemacht und es lief wieder alles, bis auf den mysqlserver. Da war nix zu machen.

Nach dem Befehl 'service mysql start' kommt folgende Fehlermedlung:
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!

- die logdateien unter /var/log/mysql sind leer
- auch der Ordner /var/log/mysql/ ist leer
- Die Festplatte ist nicht voll, nur eine Partition noch 5GB frei
- jeder hat auf /tmp Schreibrechte
- der Besitzer von /var/run/mysqld ist mysql
- ich habe versucht, den Server als root zu starten

Mehr Hinweise habe ich im Netzt nicht gefunden.

Es wäre kein Din, mysql neu zu installieren, aber ich würde die Datenbank vorher gerne sichern und weiß nicht wie, wenn der Server nicht läuft.
Optimal wäre es natürlich, wenn man es so wieder hinbekommt.

:)
 
Starte das ganze mal nicht als Daemon sondern direkt die Binärdatei (vermutlich /usr/bin) - dann wirst du den Fehler wahrschienlich sehen.
 
Der gute alte Daaron ;)

Ne, der existiert nicht, aber im Internet habe ich gelesen, dass dieser beim Start automatisch generiert werden soll.?
Ergänzung ()

Ich führe gerade ein komplettes update durch.

Vlt. probiere ich dann mal ein
Code:
apt-get --reinstall install mysql-server

Die Tabellen bleiben wohl erhalten
Ergänzung ()

Habs versucht, hat aber nichts gebracht.

Kann ich denn wenigstens die Tabellen irgendwie sichern?
 
Wenn du Angst um deine Tabellen hast, kopier /var/lib/mysql/ an einen sicheren Ort.

Und ja, der Socket wird beim Start des Dienstes gestartet, genauso wie die .pid angelegt wird.

Du kannst außerdem mal in /var/log/daemon.log gucken.
 
Der daemon.log wird regelrecht überflutet von Meldungen. hier sind mal eine ganze Reihe. Die, die er nur am Ende ausgespuckt hat:

Feb 11 17:43:52 KaliVM mysqld: something is definitely wrong and this may fail.
Feb 11 17:43:52 KaliVM mysqld:
Feb 11 17:43:52 KaliVM mysqld: key_buffer_size=16777216
Feb 11 17:43:52 KaliVM mysqld: read_buffer_size=131072
Feb 11 17:43:52 KaliVM mysqld: max_used_connections=0
Feb 11 17:43:52 KaliVM mysqld: max_threads=151
Feb 11 17:43:52 KaliVM mysqld: thread_count=0
Feb 11 17:43:52 KaliVM mysqld: connection_count=0
Feb 11 17:43:52 KaliVM mysqld: It is possible that mysqld could use up to
Feb 11 17:43:52 KaliVM mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346075 K bytes of memory
Feb 11 17:43:52 KaliVM mysqld: Hope that's ok; if not, decrease some variables in the equation.
Feb 11 17:43:52 KaliVM mysqld:
Feb 11 17:43:52 KaliVM mysqld: Thread pointer: 0x0
Feb 11 17:43:52 KaliVM mysqld: Attempting backtrace. You can use the following information to find out
Feb 11 17:43:52 KaliVM mysqld: where mysqld died. If you see no messages after this, something went
Feb 11 17:43:52 KaliVM mysqld: terribly wrong...
Feb 11 17:43:52 KaliVM mysqld: stack_bottom = 0 thread_stack 0x30000
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb72b4743]
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0xb7155984]
Feb 11 17:43:52 KaliVM mysqld: [0xb6e0a400]
Feb 11 17:43:52 KaliVM mysqld: /lib/i386-linux-gnu/i686/cmov/libc.so.6(abort+0x182)[0xb6b06d72]
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(+0x504167)[0xb732d167]
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(+0x504748)[0xb732d748]
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(+0x5cedc9)[0xb73f7dc9]
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(+0x5c481a)[0xb73ed81a]
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(+0x502e19)[0xb732be19]
Feb 11 17:43:52 KaliVM mysqld: 140211 17:43:52 [Note] Event Scheduler: Loaded 0 events
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(+0x4f4e3e)[0xb731de3e]
Feb 11 17:43:52 KaliVM mysqld: 140211 17:43:52 [Note] /usr/sbin/mysqld: ready for connections.
Feb 11 17:43:52 KaliVM mysqld: Version: '5.5.35-0+wheezy1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)
Feb 11 17:43:52 KaliVM mysqld: /usr/sbin/mysqld(+0x4f94c9)[0xb73224c9]
Feb 11 17:43:52 KaliVM mysqld: /lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x5c39)[0xb6dd8c39]
Feb 11 17:43:52 KaliVM mysqld: /lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e)[0xb6bafd4e]
Feb 11 17:43:52 KaliVM mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Feb 11 17:43:52 KaliVM mysqld: information that should help you find out what is causing the crash.
Feb 11 17:43:52 KaliVM mysqld_safe: Number of processes running now: 0
Feb 11 17:43:52 KaliVM mysqld_safe: mysqld restarted
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 [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.
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 [Note] Plugin 'FEDERATED' is disabled.
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 InnoDB: The InnoDB memory heap is disabled
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 InnoDB: Compressed tables use zlib 1.2.7
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 InnoDB: Using Linux native AIO
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 InnoDB: Initializing buffer pool, size = 128.0M
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 InnoDB: Completed initialization of buffer pool
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 InnoDB: highest supported file format is Barracuda.
Feb 11 17:43:53 KaliVM mysqld: 140211 17:43:53 InnoDB: Waiting for the background threads to start
Feb 11 17:43:54 KaliVM mysqld: 140211 17:43:54 InnoDB: 5.5.35 started; log sequence number 2228925
Feb 11 17:43:54 KaliVM mysqld: 140211 17:43:54 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
Feb 11 17:43:54 KaliVM mysqld: 140211 17:43:54 [Note] - '127.0.0.1' resolves to '127.0.0.1';
Feb 11 17:43:54 KaliVM mysqld: 140211 17:43:54 [Note] Server socket created on IP: '127.0.0.1'.
Feb 11 17:43:54 KaliVM mysqld: 140211 17:43:54 InnoDB: Assertion failure in thread 2767981424 in file trx0purge.c line 840
Feb 11 17:43:54 KaliVM mysqld: InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
Feb 11 17:43:54 KaliVM mysqld: InnoDB: We intentionally generate a memory trap.
Feb 11 17:43:54 KaliVM mysqld: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Feb 11 17:43:54 KaliVM mysqld: InnoDB: If you get repeated assertion failures or crashes, even
Feb 11 17:43:54 KaliVM mysqld: InnoDB: immediately after the mysqld startup, there may be
Feb 11 17:43:54 KaliVM mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to
Feb 11 17:43:54 KaliVM mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Feb 11 17:43:54 KaliVM mysqld: InnoDB: about forcing recovery.
Feb 11 17:43:54 KaliVM mysqld: 16:43:54 UTC - mysqld got signal 6 ;
Feb 11 17:43:54 KaliVM mysqld: This could be because you hit a bug. It is also possible that this binary
Feb 11 17:43:54 KaliVM mysqld: or one of the libraries it was linked against is corrupt, improperly built,
Feb 11 17:43:54 KaliVM mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
Feb 11 17:43:54 KaliVM mysqld: We will try our best to scrape up some info that will hopefully help
Feb 11 17:43:54 KaliVM mysqld: diagnose the problem, but since we have already crashed,
Feb 11 17:43:54 KaliVM mysqld: something is definitely wrong and this may fail.
Feb 11 17:43:54 KaliVM mysqld:
Feb 11 17:43:54 KaliVM mysqld: key_buffer_size=16777216
Feb 11 17:43:54 KaliVM mysqld: read_buffer_size=131072
Feb 11 17:43:54 KaliVM mysqld: max_used_connections=0
Feb 11 17:43:54 KaliVM mysqld: max_threads=151
Feb 11 17:43:54 KaliVM mysqld: thread_count=0
Feb 11 17:43:54 KaliVM mysqld: connection_count=0
Feb 11 17:43:54 KaliVM mysqld: It is possible that mysqld could use up to
Feb 11 17:43:54 KaliVM mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346075 K bytes of memory
Feb 11 17:43:54 KaliVM mysqld: Hope that's ok; if not, decrease some variables in the equation.
Feb 11 17:43:54 KaliVM mysqld:
Feb 11 17:43:54 KaliVM mysqld: Thread pointer: 0x0
Feb 11 17:43:54 KaliVM mysqld: Attempting backtrace. You can use the following information to find out
Feb 11 17:43:54 KaliVM mysqld: where mysqld died. If you see no messages after this, something went
Feb 11 17:43:54 KaliVM mysqld: terribly wrong...
Feb 11 17:43:54 KaliVM mysqld: stack_bottom = 0 thread_stack 0x30000
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb72c9743]
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0xb716a984]
Feb 11 17:43:54 KaliVM mysqld: [0xb6e1f400]
Feb 11 17:43:54 KaliVM mysqld: /lib/i386-linux-gnu/i686/cmov/libc.so.6(abort+0x182)[0xb6b1bd72]
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(+0x504167)[0xb7342167]
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(+0x504748)[0xb7342748]
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(+0x5cedc9)[0xb740cdc9]
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(+0x5c481a)[0xb740281a]
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(+0x502e19)[0xb7340e19]
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(+0x4f4e3e)[0xb7332e3e]
Feb 11 17:43:54 KaliVM mysqld: /usr/sbin/mysqld(+0x4f94c9)[0xb73374c9]
Feb 11 17:43:54 KaliVM mysqld: /lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x5c39)[0xb6dedc39]
Feb 11 17:43:54 KaliVM mysqld: /lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e)[0xb6bc4d4e]
Feb 11 17:43:54 KaliVM mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Feb 11 17:43:54 KaliVM mysqld: information that should help you find out what is causing the crash.
Feb 11 17:43:54 KaliVM mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Ergänzung ()

Noch eine Frage:

Habe jetzt alles aus /var/lib/mysql kopiert.

Sollte ich mysql neu installieren, kann ich dann die Tabellen einfach reinkopieren?
Ergänzung ()

Ich denke, es liegt an dieser Festplattengeschichte.

Evtl. habe ich einen snapshot unsachgemäß verworfen, oder es gab beim Laden irgendeinen Fehler. Der mysql-server lief gerade und paar inodes wurden nicht richtig geschrieben. Als ich fsck durchlaufen lassen habe, mussten ein paar Fehler behoben werden. Jetzt wird er wahrscheinlich auf einige Dateien nicht mehr zugreifen können, und ich kann es nicht mehr reparieren.

Da hilft wohl nur komlpett runter und neu installieren, obwohl ich dachte,
apt-get --reinstall install mysql-server, macht genau das
 
Wenn du schon dabei bist, wechsle doch gleich auf MariaDB. Genauso stabil, dafür deutlich schneller und 100% binärkompatibel zu MySQL.


It is possible that mysqld could use up to
Feb 11 17:43:54 KaliVM mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346075 K bytes of memory
Feb 11 17:43:54 KaliVM mysqld: Hope that's ok; if not, decrease some variables in the equation.

Ma geguckt, ob da irgend was schief geht? Sowas hab ich ja noch nie gesehen...
 
Und? Scheiß drauf, du weißt doch sicherlich, wie du Paketquellen hinzufügst. Was für Wikipedia gut genug ist kann für dich nicht schlecht sein.
 
Zurück
Oben