mysql schmiert mit Signal 11 mehrere Male pro Tag ab

[betrazivis]

Hallo,
Vor ca. 2 Wochen habe ich auf eine ca. 1 GB große Tabelle mehrere FULLTEXT Indizes gelegt. Die Datenbank wurde dadurch sehr groß und nach einem "Disk Full" Unfall auf der Partition, auf der meine Datenbanken liegen ist mysql abgeschmiert. Er hat daraufhin alle InnoDB-Tabellen geschossen, weil er entsprechenden Logfiles nicht mehr schreiben konnte. Ein Binlog-Recovery brachte nichts, doch habe ich einen alten Dump einspielen können. Nach Löschung der ib_logfile* und ibdata habe ich den Server neu gestartet und alle Daten waren dort wo sie sein sollten.

Leider macht der Server seit dem das lästige Sperenzchen ca. 2-4 Mal pro Tag abzustürzen. Von einem Absturz merkt man zu 70% nichts, weil der Server direkt danach wieder hochfährt. Bei allen anderen Gelegenheiten schießt er leider die große Table mit der FULLTEXT Indizes, die sich zum Glück auch wieder reparieren lässt. Der Server ist dann aber down.

Hier mal der Log, wiederholt so jeden Tag zu unterschiedlichen Zeiten.

Code: Select all

Number of processes running now: 0
080401 02:53:34  mysqld restarted
080401  2:53:34  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
080401  2:53:34  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 443010263.
InnoDB: Doing recovery: scanned up to log sequence number 0 443010263
080401  2:53:34  InnoDB: Flushing modified pages from the buffer pool...
080401  2:53:34  InnoDB: Started; log sequence number 0 443010263
/usr/sbin/mysqld: ready for connections.
Version: '4.1.10a'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  SUSE MySQL RPM
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=33554432
read_buffer_size=520192
max_used_connections=24
max_connections=100
threads_connected=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 230051 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

System:
Linux 2.6.16.27-061216a x86_64 (SuSE 9.2)
mySQL 4.1.10a

Vielen Dank

[braindead]

Code: Select all

Signal 11: SIGSEGV - Segmentation Fault (Ein Programm versucht auf einen unzulässigen Speicherbereich zuzugreifen...)

Speicher vom Server gecheckt? Klingt nach einem "Hardwareunfall".

[betrazivis]

Code: Select all

Signal 11: SIGSEGV - Segmentation Fault (Ein Programm versucht auf einen unzulässigen Speicherbereich zuzugreifen...)

Speicher vom Server gecheckt? Klingt nach einem "Hardwareunfall".

Doofe Frage: Wie kann ich auf einem Remotehost per SSH den Speicher checken ohne die Kiste von einem Image -wie bei memtest86- booten oder den Kernel neu kompilieren zu müssen?

[daemotron]

Wie wär's damit: Den Support des Anbieters bitten, das für Dich zu tun?

Ansonsten bieten einige Anbieter auch die Möglichkeit, ein Rettungssystem im Memtest-Modus zu starten. Dafür braucht man dann allerdings i. d. R. KVM-Zugriff (Remote Console, LARA o. ä.)

[betrazivis]

Wie wär's damit: Den Support des Anbieters bitten, das für Dich zu tun?

Ansonsten bieten einige Anbieter auch die Möglichkeit, ein Rettungssystem im Memtest-Modus zu starten. Dafür braucht man dann allerdings i. d. R. KVM-Zugriff (Remote Console, LARA o. ä.)

Ja, in meinem Fall bietet das mein Provider auch an. Werd`s versuchen, danke.

[isotopp]

Vor ca. 2 Wochen habe ich auf eine ca. 1 GB große Tabelle mehrere FULLTEXT Indizes gelegt. Die Datenbank wurde dadurch sehr groß und nach einem "Disk Full" Unfall auf der Partition, auf der meine Datenbanken liegen ist mysql abgeschmiert.

EIn FULLTEXT Index kann nur auf MyISAM-Tabellen angelegt werden.

Wenn Dein Server gecrashed ist, sind mit Sicherheit bei dem Crash die MyISAM-Tabellen beschädigt worden. Ich hoffe sehr, daß Du sie mit REPAIR TABLE hast reparieren lassen, bzw. daß Dein Server mit

myisam_recover = FORCE,BACKUP

läuft. Wenn nein, und Du versuchst in MyISAM-Tabellen zu schreiben die gecrashed sind, bekommst Du alles mögliche inklusive SIg 11.

Eine ib_logfile* und ibdata*-Löschung vorzunehmen wenn noch .frm-Dateien vom Typ InnoDB da sind ist übrigens auch eine Scheißidee. Was sagt

select table_schema, table_name from information_schema.tables where engine = "innodb";

bei Dir.

[betrazivis]

Hallo,
danke für die Anwort, das Problem wächst mir nämlich langsam über den Kopf. :-({|=

Vor ca. 2 Wochen habe ich auf eine ca. 1 GB große Tabelle mehrere FULLTEXT Indizes gelegt. Die Datenbank wurde dadurch sehr groß und nach einem "Disk Full" Unfall auf der Partition, auf der meine Datenbanken liegen ist mysql abgeschmiert.

EIn FULLTEXT Index kann nur auf MyISAM-Tabellen angelegt werden.

Is klar ;)

Wenn Dein Server gecrashed ist, sind mit Sicherheit bei dem Crash die MyISAM-Tabellen beschädigt worden. Ich hoffe sehr, daß Du sie mit REPAIR TABLE hast reparieren lassen, bzw. daß Dein Server mit

Das funktioniert, nur ist in der Zeit, in der ich das nicht merke, die Kiste down, weil dann auf die Haupttabelle kein Zugriff mehr stattfinden kann. ICh hbae das zur Zeit mit einem Script gelöst, das mir eine Mail zukommen lässt, falls der Server down ist und ich den dann brav reparieren kann. ;)

myisam_recover = FORCE,BACKUP

Das war so nicht eingestellt, habe ich jetzt mal nachgetragen.

läuft. Wenn nein, und Du versuchst in MyISAM-Tabellen zu schreiben die gecrashed sind, bekommst Du alles mögliche inklusive SIg 11.

So wie ich das sehe ist das umgekehrt. Der Server schmiert ab und dabei crasht die Tabelle. Ich denke das, weil nicht bei jedem Sig 11 die Tabelle zerstört ist. Vielleicht eine Fehleinschätzung.

Eine ib_logfile* und ibdata*-Löschung vorzunehmen wenn noch .frm-Dateien vom Typ InnoDB da sind ist übrigens auch eine Scheißidee. Was sagt

Das...hab ich auch bemerkt ;)

select table_schema, table_name from information_schema.tables where engine = "innodb";
bei Dir.

Gar nichts, Die INFORMATION_SCHEMA DB habe ich nicht. Ist das schlimm? Sollte ich das nachrüsten?

[daemotron]

mySQL 4.1.10a

[...]

Die INFORMATION_SCHEMA DB habe ich nicht.

AFAIK wurde die auch erst mit MySQL 5 eingeführt.

[isotopp]

select table_schema, table_name from information_schema.tables where engine = "innodb";
bei Dir.

Gar nichts, Die INFORMATION_SCHEMA DB habe ich nicht. Ist das schlimm? Sollte ich das nachrüsten?

INFORMATION_SCHEMA ist neu in MySQL 5.0. Aktuell sind derzei MySQL 5.0 und MySQL 5.1 unterstuetzte Versionen. Die MySQL Users Conference and Expo laeuft gerade in Santa Clara, CA, und wenn alles gelingt sollte dort endlich auch 5.1 als GA released werden.

Wenn Du noch mit einer MySQL 4.x Version arbeitest, verwendet Du ein MySQL ohne Support.

Kris

[betrazivis]

Ich habe jetzt mal mySQL deinstalliert und eine neuer Bugfix Version installiert. Der Server läuft wieder :), allerdings OHNE innoDB-Engine. Weiß zufälligerweise jemand, wie ich die nachrüste, oder was da passiert sein könnte. So allmählich resigniere ich nämlich. Vielleicht sollte ich auf mySQl 5 upgraden, ja. Nur so wirklich traue ich mich das noch nicht.

[bluewind]

Vielleicht sollte ich auf mySQl 5 upgraden, ja. Nur so wirklich traue ich mich das noch nicht.

SUSE 9.2 ist auch nicht gerade das neueste...