ubuntuusers.de

hallo, ich habe schon etliche seiten durch und mehrere probleme mit mysql gehabt.. (rechte waren falsch, "in the future" problem, fehlerhafte ib logfile etc...)

manche probleme davon habe ich selbst hervorgerufen, allerdings auch wieder in den griff bekommen (glaube ich zumindest)..

jedenfalls sieht mein aktuelles problem so aus:

bei meinem server mussten die platten ausgetauscht werden, also hab ich mir ein backup von "/var/lib/mysql" gemacht (keine export funktion genutzt) und moechte diese dbs wieder nutzen.

nachdem mysql/ phpmyadmin installiert war, hab ich einfach alle dateien vom alten backup wieder nach "/var/lib/mysql" kopiert, jedoch kann ich aktuell kein mysql starten.

(kopierte daten: verschiedene db ordner, "mysql" ordner, "phpmyadmin" ordner, debian-5.5.flag, iblogfile0, iblogfile1, ibdata1, mysql_upgare_info)

sudo service mysql start
start: Job failed to start

sudo service mysql status
mysql stop/waiting

sudo service mysql stop
stop: Unknown instance: 

in der "/var/log/mysql/error.log" steht folgendes:

140228 17:00:41 [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.
140228 17:00:41 [Note] Plugin 'FEDERATED' is disabled.
140228 17:00:41 InnoDB: The InnoDB memory heap is disabled
140228 17:00:41 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140228 17:00:41 InnoDB: Compressed tables use zlib 1.2.3.4
140228 17:00:41 InnoDB: Initializing buffer pool, size = 128.0M
140228 17:00:41 InnoDB: Completed initialization of buffer pool
140228 17:00:41 InnoDB: highest supported file format is Barracuda.
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
InnoDB: wrong number of columns in SYS_COLUMNS record
140228 17:00:41  InnoDB: Assertion failure in thread 140165570619200 in file dict0load.c line 992
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:00:41 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=16777216
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 = 346700 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f7ad7633719]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f7ad74f8ae3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f7ad6242cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f7ad58ad425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f7ad58b0b8b]
/usr/sbin/mysqld(+0x66a246)[0x7f7ad7744246]
/usr/sbin/mysqld(+0x65bbd5)[0x7f7ad7735bd5]
/usr/sbin/mysqld(+0x60533f)[0x7f7ad76df33f]
/usr/sbin/mysqld(+0x5cedd9)[0x7f7ad76a8dd9]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7f7ad74fb1b1]
/usr/sbin/mysqld(+0x30da31)[0x7f7ad73e7a31]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa94)[0x7f7ad73eb074]
/usr/sbin/mysqld(+0x284d66)[0x7f7ad735ed66]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x624)[0x7f7ad7362624]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f7ad589876d]
/usr/sbin/mysqld(+0x27e665)[0x7f7ad7358665]
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.
140228 17:00: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.
140228 17:00:42 [Note] Plugin 'FEDERATED' is disabled.
140228 17:00:42 InnoDB: The InnoDB memory heap is disabled
140228 17:00:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140228 17:00:42 InnoDB: Compressed tables use zlib 1.2.3.4
140228 17:00:42 InnoDB: Initializing buffer pool, size = 128.0M
140228 17:00:42 InnoDB: Completed initialization of buffer pool
140228 17:00:42 InnoDB: highest supported file format is Barracuda.
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
InnoDB: wrong number of columns in SYS_COLUMNS record
140228 17:00:42  InnoDB: Assertion failure in thread 140394520835904 in file dict0load.c line 992
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:00:42 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=16777216
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 = 346700 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7fb025e24719]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7fb025ce9ae3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fb024a33cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fb02409e425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7fb0240a1b8b]
/usr/sbin/mysqld(+0x66a246)[0x7fb025f35246]
/usr/sbin/mysqld(+0x65bbd5)[0x7fb025f26bd5]
/usr/sbin/mysqld(+0x60533f)[0x7fb025ed033f]
/usr/sbin/mysqld(+0x5cedd9)[0x7fb025e99dd9]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7fb025cec1b1]
/usr/sbin/mysqld(+0x30da31)[0x7fb025bd8a31]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa94)[0x7fb025bdc074]
/usr/sbin/mysqld(+0x284d66)[0x7fb025b4fd66]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x624)[0x7fb025b53624]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fb02408976d]
/usr/sbin/mysqld(+0x27e665)[0x7fb025b49665]
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.
140228 17:00:43 [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.
140228 17:00:43 [Note] Plugin 'FEDERATED' is disabled.
140228 17:00:43 InnoDB: The InnoDB memory heap is disabled
140228 17:00:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140228 17:00:43 InnoDB: Compressed tables use zlib 1.2.3.4
140228 17:00:43 InnoDB: Initializing buffer pool, size = 128.0M
140228 17:00:43 InnoDB: Completed initialization of buffer pool
140228 17:00:43 InnoDB: highest supported file format is Barracuda.
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
InnoDB: wrong number of columns in SYS_COLUMNS record
140228 17:00:43  InnoDB: Assertion failure in thread 139683310950208 in file dict0load.c line 992
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:00:43 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=16777216
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 = 346700 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f0a8e78a719]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f0a8e64fae3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f0a8d399cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f0a8ca04425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f0a8ca07b8b]
/usr/sbin/mysqld(+0x66a246)[0x7f0a8e89b246]
/usr/sbin/mysqld(+0x65bbd5)[0x7f0a8e88cbd5]
/usr/sbin/mysqld(+0x60533f)[0x7f0a8e83633f]
/usr/sbin/mysqld(+0x5cedd9)[0x7f0a8e7ffdd9]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7f0a8e6521b1]
/usr/sbin/mysqld(+0x30da31)[0x7f0a8e53ea31]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa94)[0x7f0a8e542074]
/usr/sbin/mysqld(+0x284d66)[0x7f0a8e4b5d66]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x624)[0x7f0a8e4b9624]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f0a8c9ef76d]
/usr/sbin/mysqld(+0x27e665)[0x7f0a8e4af665]
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.

da ich am rechte system herumgetestet habe, koennte dort etwas falsch sein.

/var/lib/mysql gehoert "mysql:mysql"

auch ein hinzufuegen von:

innodb_force_recovery = 6

in der my.cnf (unter [mysqld]) welche root:root gehoert, brachte nichts. -

nunja, ich hoffe ihr koennt mir helfen, falls noch informationen benoetigt werden einfach fragen..

danke

gibt es denn niemanden der mir helfen kann?

Moin ubuntusub,

benutzte die Maschine, von der das "Backup" stammt, die gleiche MySQL-Version, wie die Maschine, auf der das Backup wiederhergestellt werden soll? Die Zeile

InnoDB: wrong number of columns in SYS_COLUMNS record

(welche ich für den Ursprung des Crashs halte) deutet darauf hin, dass da irgendwas nicht zusammenpasst, oder das die Daten in der betreffenden Tabelle ziemlich komplett korrupt sind…

Ein googeln nach dieser Zeile bringt leider auch keine wirklichen Ergebnisse, was darauf hindeutet, dass das ein sehr seltener Fehler ist. Wahrscheinlich wirst du dich da an einen MySQL-Experten wenden müssen, wobei ich nicht weiß, ob es hier einen solchen gibt.

Gruß

Torben

Hast Du keine mit mysqldump erstellte Sicherung, die Du importieren kannst?

hallo, leider habe ich nur die genannten daten: (verschiedene db ordner, "mysql" ordner, "phpmyadmin" ordner, debian-5.5.flag, iblogfile0, iblogfile1, ibdata1, mysql_upgare_info)

ich kann auch mysql loeschen und neu installieren. das wichtigste ist, das ich irgendwie diese datenbanken wieder zum laufen bekomme.

wie mache ich das am besten?..

Wie sieht es denn mit Hoerberts Frage aus, ob die beiden MySQL-Versionen auch identisch sind?

achso, ja. dazu wollte ich schreiben das ich das nicht genau weis, da ich nurnoch die ordner habe.. die platten wurden formatiert.

steht vielleicht in irgendeiner datei etwas zur version?

Hmm…

Sorry, aber da wirst du vermutlich tatsächlich bei den Experten vorbeischauen müssen. Die haben auch einen (vermutlich nicht so stark frequentierten) deutschsprachigen Bereich, wenn Englisch ein Problem ist.

Per Google lässt sich da nämlich nichts zu rausfinden und alle Rettungs-Versuche setzen einen irgendwie laufenden (oder zumindest humpelnden) MySQL-Server voraus. Also ich bin dann leider raus…

Gruß

Torben

ich habe dort einen thread eroeffnet, danke.