11.06.2013

4628

MySQL defekt nach Festplattentausch

Hallo ihr Lieben!

gestern ist unserem Server bei Hetzner eine Platte abgeraucht, neue wurde eingebaut und Spiegelung über Nacht zurückgespielt. Soweit alles gut.
Nun Läuft aber mein MySQL Server nimmer... habe schon alles probiert nur keine Anleitung die ich gefunden habe klappt... ensprechend gehen auch die CMS basierten Webseiten und das Zarafa E-Mail System nimmer...

Ich bitte dringend um Hilfe da wir seit gestern keine Mails mehr empfangen oder versenden...

Vielen Dank!!!!!

10:25:19 UTC - mysqld got signal 11 ;
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 = 346682 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)[0x7f725f2197b9]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f725f0df8f3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f725de2ccb0]
/usr/sbin/mysqld(+0x6a57ee)[0x7f725f3697ee]
/usr/sbin/mysqld(+0x6a1955)[0x7f725f365955]
/usr/sbin/mysqld(+0x6a1a4f)[0x7f725f365a4f]
/usr/sbin/mysqld(+0x67c675)[0x7f725f340675]
/usr/sbin/mysqld(+0x6011d5)[0x7f725f2c51d5]
/usr/sbin/mysqld(+0x5cae89)[0x7f725f28ee89]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7f725f0e1fc1]
/usr/sbin/mysqld(+0x30afc1)[0x7f725efcefc1]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa94)[0x7f725efd25e4]
/usr/sbin/mysqld(+0x284686)[0x7f725ef48686]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x59b)[0x7f725ef4be2b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f725d48376d]
/usr/sbin/mysqld(+0x27e1b5)[0x7f725ef421b5]
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.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 207821

Url: https://administrator.de/contentid/207821

Ausgedruckt am: 22.11.2024 um 20:11 Uhr

17 Kommentare

Neuester Kommentar

Hi mikahaapamaeki,
hast du das in der mysql-Anleitung auch schon probiert ?:

Stop the mysqld server with mysqladmin shutdown, run myisamchk --silent --force */*.MYI from the data directory to check all MyISAM tables, and restart mysqld. This ensures that you are running from a clean state. See Chapter 5, MySQL Server Administration.

Grüße Uwe

Das kam dabei raus ...

root@server ~ # mysqladmin shutdown
mysqladmin: connect to server at 'localhost' failed  
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)'  
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!  
root@server ~ # myisamchk --silent --force */*.MYI 
myisamchk: error: File '*/*.MYI' doesn't exist  
myisamchk: error: File '*/*.MYI' doesn't exist  
root@server ~ #

Gruß,
Mika

EDIT

ggf hilft das ja weiter...

root@server ~ # /etc/init.d/mysql start
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql start

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the start(8) utility, e.g. start mysql
mysql start/running, process 6176
root@server ~ # service mysql status
mysql stop/waiting
root@server ~ # 

/etc/init.d/mysql stop

run myisamchk --silent --force */*.MYI from the data directory

klar wenn du das im home-Verzeichnis machst, kann er nix finden

Das Standard-Datenverzeichnis lautet:
/var/lib/mysql

habe es in /var/lib/mysql geamcht, lief durch, habe dann service mysql start gemacht aber immernoch mysql stop/waiting
Aber mein Zarafa-Server funkt nun auf einmal... leider komme ich aber immernoch nicht rein da mysql nicht läuft...

root@server /var/lib/mysql # myisamchk --silent --force */*.MYI
myisamchk: MyISAM file bmwv/PageStatistics.MYI
myisamchk: error: Found key at page 143360 that points to record outside datafile
myisamchk: Unknown error 126
myisamchk: MyISAM file vhaus@002dohg/PageSearchIndex.MYI
myisamchk: error: Keyblock size at page 32768 is not correct.  Block length: 902  key length: 49

habe es noch mal wiederholt und es kam nichts... zarafa-server und mysql starten immer noch nicht...

kann ich mysql irgendwie neu installieren ohne die Datenbanken zu verlieren?

ich weiß jetzt nicht ob deine Datenbank InnoDB oder ISAM Datenbanken benutzt aber für InnoDB kann man in die mysql Konfigurationsdatei folgenden Eintrag hinzufügen um den Recovery-Modus zu starten:

[mysqld]
innodb_force_recovery = 4

Und danach einen Dump der Tabellen machen.
Siehe dazu folgendes PDF Seite 29

Am einfachsten wäre es ein Backup zurückzuspielen, aber ich denke das hast du wahrscheinlich nicht ...

Zitat von @mikahaapamaeki:

kann ich mysql irgendwie neu installieren ohne die Datenbanken zu verlieren?

Denke dass es nicht an der MySQL-Installation liegt sondern an den Datenbanken die durch den Ausfall der Platte irgendwo beschädigt worden sind.

Backup habe ich bisher nicht gemacht da mir das RAID1 als "ausreichend galt..."

Wenn ich den dump machen will kommt folgender Fehler...

mysqldump: Couldn't execute 'UNLOCK TABLES': Lost connection to MySQL server during query (2013)

hmm die Datenbanken kann man doch sicherlich irgendwie reparieren oder?

Backup habe ich bisher nicht gemacht da mir das RAID1 als "ausreichend galt..."

Das wird dir eine Lehre sein ...RAID ersetzt kein Backup !

probier mal :

mysqlcheck -Aor

oder

mysqlcheck --all-databases -r #repair
mysqlcheck --all-databases -a #analyze
mysqlcheck --all-databases -o #optimize

als root

jetzt geht nichts mehr...

start: Job failed to start

wenn ich versuche mysql zu starten... ich stehe echt kurz davor alles einfach hinzuschmeißen und abzuhauen... was ist denn jetzt schonwieder???

hier noch eine Info, ggf sagt euch das was ?!?

root@server /etc/mysql # dmesg | grep mysql
[   13.673454] type=1400 audit(1370961675.701:11): apparmor="STATUS" operation="profile_load" name="/usr/sbin/mysqld" pid=946 comm="apparmor_parser"  
[   13.843446] init: mysql main process (1027) terminated with status 1
[   13.843464] init: mysql main process ended, respawning
[   14.734502] init: mysql post-start process (1029) terminated with status 1
[   14.759071] init: mysql main process (1287) terminated with status 1
[   14.759086] init: mysql main process ended, respawning
[   15.749974] init: mysql post-start process (1288) terminated with status 1
[   15.789021] init: mysql main process (1330) terminated with status 1
[   15.789055] init: mysql respawning too fast, stopped
[  115.381602] type=1400 audit(1370961777.125:25): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2646 comm="apparmor_parser"  
[  115.419482] init: mysql main process (2650) terminated with status 1
[  115.419514] init: mysql main process ended, respawning
[  116.401268] init: mysql post-start process (2651) terminated with status 1
[  116.409737] type=1400 audit(1370961778.153:26): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2684 comm="apparmor_parser"  
[  116.449316] init: mysql main process (2688) terminated with status 1
[  116.449350] init: mysql main process ended, respawning
[  117.428930] init: mysql post-start process (2689) terminated with status 1
[  117.437369] type=1400 audit(1370961779.181:27): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2722 comm="apparmor_parser"  
[  117.472016] init: mysql main process (2726) terminated with status 1
[  117.472049] init: mysql respawning too fast, stopped
[  386.483461] type=1400 audit(1370962048.385:28): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2779 comm="apparmor_parser"  
[  386.523267] init: mysql main process (2783) terminated with status 1
[  386.523282] init: mysql main process ended, respawning
[  387.502949] init: mysql post-start process (2784) terminated with status 1
[  387.511275] type=1400 audit(1370962049.413:29): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2817 comm="apparmor_parser"  
[  387.550574] init: mysql main process (2821) terminated with status 1
[  387.550608] init: mysql main process ended, respawning
[  388.530955] init: mysql post-start process (2822) terminated with status 1
[  388.539250] type=1400 audit(1370962050.441:30): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2855 comm="apparmor_parser"  
[  388.573423] init: mysql main process (2859) terminated with status 1
[  388.573456] init: mysql respawning too fast, stopped
[  415.137346] type=1400 audit(1370962077.053:31): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2904 comm="apparmor_parser"  
[  415.172988] init: mysql main process (2908) terminated with status 1
[  415.173023] init: mysql main process ended, respawning
[  416.156999] init: mysql post-start process (2909) terminated with status 1
[  416.165521] type=1400 audit(1370962078.085:32): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2942 comm="apparmor_parser"  
[  416.205439] init: mysql main process (2946) terminated with status 1
[  416.205454] init: mysql main process ended, respawning
[  417.185076] init: mysql post-start process (2947) terminated with status 1
[  417.193539] type=1400 audit(1370962079.113:33): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=2980 comm="apparmor_parser"  
[  417.233167] init: mysql main process (2984) terminated with status 1
[  417.233202] init: mysql respawning too fast, stopped
root@server /etc/mysql # 

http://askubuntu.com/questions/127264/cant-start-mysql-mysql-respawning ...

Also um mal zum Abschluss zu kommen... ich hoffe nur ich nerve nicht langsam... Aber vielen Dank schonmal für die Hilfe

Error log habe ich komplett geleert und einmal versucht mysql zu starten das ist alles was da kommt...

130611 18:30:55 [Note] Plugin 'FEDERATED' is disabled.  
130611 18:30:55 InnoDB: The InnoDB memory heap is disabled
130611 18:30:55 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130611 18:30:55 InnoDB: Compressed tables use zlib 1.2.3.4
130611 18:30:55 InnoDB: Initializing buffer pool, size = 3.9G
130611 18:30:55 InnoDB: Completed initialization of buffer pool
130611 18:30:55 InnoDB: highest supported file format is Barracuda.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 220.
InnoDB: You may have to recover from a backup.
130611 18:30:55  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex d4b4c382000000dc000000000000000000000003a8e3ddc40006000000000000000000000000fffffffe00000000000000060000c2d405df0000c2d4007800000000000000022eb20000c2d40000431bfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff$
InnoDB: End of page dump
130611 18:30:55  InnoDB: Page checksum 579790626, prior-to-4.0.14-form checksum 3456036086
InnoDB: stored checksum 3568616322, prior-to-4.0.14-form stored checksum 3456036086
InnoDB: Page lsn 3 2833505732, low 4 bytes of lsn at page end 2833505732
InnoDB: Page number (if stored to page already) 220,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 220.
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
130611 18:30:55  InnoDB: Assertion failure in thread 140574115022656 in file buf0buf.c line 3629
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:30:55 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 = 346682 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
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7fd9f68767b9]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7fd9f673c8f3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fd9f5489cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fd9f4af5425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7fd9f4af8b8b]
/usr/sbin/mysqld(+0x645171)[0x7fd9f6966171]
/usr/sbin/mysqld(+0x6509e8)[0x7fd9f69719e8]
/usr/sbin/mysqld(+0x65138c)[0x7fd9f697238c]
/usr/sbin/mysqld(+0x640c16)[0x7fd9f6961c16]
/usr/sbin/mysqld(+0x6122a6)[0x7fd9f69332a6]
/usr/sbin/mysqld(+0x61305c)[0x7fd9f693405c]
/usr/sbin/mysqld(+0x614a03)[0x7fd9f6935a03]
/usr/sbin/mysqld(+0x6011cc)[0x7fd9f69221cc]
/usr/sbin/mysqld(+0x5cae89)[0x7fd9f68ebe89]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7fd9f673efc1]
/usr/sbin/mysqld(+0x30afc1)[0x7fd9f662bfc1]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa94)[0x7fd9f662f5e4]
/usr/sbin/mysqld(+0x284686)[0x7fd9f65a5686]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x59b)[0x7fd9f65a8e2b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd9f4ae076d]
/usr/sbin/mysqld(+0x27e1b5)[0x7fd9f659f1b5]
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.
130611 18:30:56 [Note] Plugin 'FEDERATED' is disabled.  
130611 18:30:56 InnoDB: The InnoDB memory heap is disabled
130611 18:30:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130611 18:30:56 InnoDB: Compressed tables use zlib 1.2.3.4
130611 18:30:56 InnoDB: Initializing buffer pool, size = 3.9G
130611 18:30:56 InnoDB: Completed initialization of buffer pool
130611 18:30:56 InnoDB: highest supported file format is Barracuda.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 220.
InnoDB: You may have to recover from a backup.
130611 18:30:56  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex d4b4c382000000dc000000000000000000000003a8e3ddc40006000000000000000000000000fffffffe00000000000000060000c2d405df0000c2d4007800000000000000022eb20000c2d40000431bfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff$
InnoDB: End of page dump
130611 18:30:56  InnoDB: Page checksum 579790626, prior-to-4.0.14-form checksum 3456036086
InnoDB: stored checksum 3568616322, prior-to-4.0.14-form stored checksum 3456036086
InnoDB: Page lsn 3 2833505732, low 4 bytes of lsn at page end 2833505732
InnoDB: Page number (if stored to page already) 220,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 220.
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
130611 18:30:56  InnoDB: Assertion failure in thread 140198699333440 in file buf0buf.c line 3629
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: 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:30:56 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 = 346682 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)[0x7f828e0297b9]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f828deef8f3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f828cc3ccb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f828c2a8425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f828c2abb8b]
/usr/sbin/mysqld(+0x645171)[0x7f828e119171]
/usr/sbin/mysqld(+0x6509e8)[0x7f828e1249e8]
/usr/sbin/mysqld(+0x65138c)[0x7f828e12538c]
/usr/sbin/mysqld(+0x640c16)[0x7f828e114c16]
/usr/sbin/mysqld(+0x6122a6)[0x7f828e0e62a6]
/usr/sbin/mysqld(+0x61305c)[0x7f828e0e705c]
/usr/sbin/mysqld(+0x614a03)[0x7f828e0e8a03]
/usr/sbin/mysqld(+0x6011cc)[0x7f828e0d51cc]
/usr/sbin/mysqld(+0x5cae89)[0x7f828e09ee89]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7f828def1fc1]
/usr/sbin/mysqld(+0x30afc1)[0x7f828dddefc1]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa94)[0x7f828dde25e4]
/usr/sbin/mysqld(+0x284686)[0x7f828dd58686]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x59b)[0x7f828dd5be2b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f828c29376d]
/usr/sbin/mysqld(+0x27e1b5)[0x7f828dd521b5]
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.
130611 18:30:57 [Note] Plugin 'FEDERATED' is disabled.  
130611 18:30:57 InnoDB: The InnoDB memory heap is disabled
130611 18:30:57 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130611 18:30:57 InnoDB: Compressed tables use zlib 1.2.3.4
130611 18:30:57 InnoDB: Initializing buffer pool, size = 3.9G
130611 18:30:57 InnoDB: Completed initialization of buffer pool
130611 18:30:57 InnoDB: highest supported file format is Barracuda.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 220.
InnoDB: You may have to recover from a backup.
130611 18:30:57  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex d4b4c382000000dc000000000000000000000003a8e3ddc40006000000000000000000000000fffffffe00000000000000060000c2d405df0000c2d4007800000000000000022eb20000c2d40000431bfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff$
InnoDB: End of page dump
130611 18:30:57  InnoDB: Page checksum 579790626, prior-to-4.0.14-form checksum 3456036086
InnoDB: stored checksum 3568616322, prior-to-4.0.14-form stored checksum 3456036086
130611 18:30:57  InnoDB: Page checksum 579790626, prior-to-4.0.14-form checksum 3456036086
InnoDB: stored checksum 3568616322, prior-to-4.0.14-form stored checksum 3456036086
InnoDB: Page lsn 3 2833505732, low 4 bytes of lsn at page end 2833505732
InnoDB: Page number (if stored to page already) 220,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 220.
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
130611 18:30:57  InnoDB: Assertion failure in thread 139689218172736 in file buf0buf.c line 3629
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:30:57 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 = 346682 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)[0x7f0bee9107b9]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f0bee7d68f3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f0bed523cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f0becb8f425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f0becb92b8b]
/usr/sbin/mysqld(+0x645171)[0x7f0beea00171]
/usr/sbin/mysqld(+0x6509e8)[0x7f0beea0b9e8]
/usr/sbin/mysqld(+0x65138c)[0x7f0beea0c38c]
/usr/sbin/mysqld(+0x640c16)[0x7f0bee9fbc16]
/usr/sbin/mysqld(+0x6122a6)[0x7f0bee9cd2a6]
/usr/sbin/mysqld(+0x61305c)[0x7f0bee9ce05c]
/usr/sbin/mysqld(+0x614a03)[0x7f0bee9cfa03]
/usr/sbin/mysqld(+0x6011cc)[0x7f0bee9bc1cc]
/usr/sbin/mysqld(+0x614a03)[0x7f0bee9cfa03]
/usr/sbin/mysqld(+0x6011cc)[0x7f0bee9bc1cc]
/usr/sbin/mysqld(+0x5cae89)[0x7f0bee985e89]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7f0bee7d8fc1]
/usr/sbin/mysqld(+0x30afc1)[0x7f0bee6c5fc1]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa94)[0x7f0bee6c95e4]
/usr/sbin/mysqld(+0x284686)[0x7f0bee63f686]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x59b)[0x7f0bee642e2b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f0becb7a76d]
/usr/sbin/mysqld(+0x27e1b5)[0x7f0bee6391b5]
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.

es wurde soeben festgestellt, dass der Arbeitsspeicher ebenfalls einen Defekt aufweist. Könnte dies damit zusammenhängen, dass mein MySQL nicht laufen wollte? Also Server ist erstmal 4-5 Stunden down wegen Prüfung und Tausch

Das wäre sogar sehr wahrscheinlich... Wenn der MySQL seinen Programmcode in den RAM schreibt und irgendein Müll wieder rauskommt kann kein Programm mehr funktionieren ("Page fault" ist ein Hinweis darauf dass entweder der RAM, die CPU oder die MySQL-Binaries defekt sind).

Wenn du Pech hast, hat der MySQL-Server jetzt aber vielleicht sogar die Dateien kaputtgeschrieben - ich hoffe, du hast sie dir vor den Reparaturversuchen irgendwohin kopiert?

ich hoffe, dass Du die Conf Dateien meinst. Vermute aber eher Du meinst die Datenbankdateien, die ich leider sichern wollte als mir der Server abgestürzt ist... also nein... freue mich schon auf einen sehr unruhigen Schlaf, Danke aber für die Info, zumindest weiß ich, dass es auch daran gelegen haben kann...

tja... MySQL läuft wieder... und es ist so wie Du es schon gesagt hast... Datenbanken im Ar... habe nur noch die FRM Dateien... kann man da noch was retten?!?

Also die meisten (wichtigen) Tabellen liefen mit MyISAM!!! ich habe also die FRM Daten und die dazugehörige ibdata1 daraus muss man doch was machen können oder`?

Frage Linux Ubuntu

Mehr von mikahaapamaeki

Benötigte Hardware für schnelle VDI Lösungmikahaapamaeki - 32 Kommentare

Öffentliche Domain wie eine lokale Domain behandelnmikahaapamaeki - 5 Kommentare

Mysqldump unvollständigmikahaapamaeki - 8 Kommentare

Netzwerk wird Erneuertmikahaapamaeki - 20 Kommentare

Heiß diskutiert