MySQL MyISAM crasht

[Chromatin]

Moin

Seit knapp 3 Tagen habe ich vermehrt korrupte DB Files unter meinem MySQL Server.
Die Engine ist ausschliesslich MyISAM.

Die Tabellen laufen stundenlang einwandfrei und ploetzlich knallen die ohne ersichtlichen Grund durch.
Und das auch mehrmals hintereinander.

Ich hatte erst auf gemaekel im FS getippt, aber das wurde gecheckt- alles war ok.


sql:/var # uname -pas
Linux sql 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux


sql:/var # mysql --version
mysql Ver 14.12 Distrib 5.0.26, for suse-linux-gnu (x86_64) using readline 5.1

sql:/var # mount
/dev/sda1 on / type reiserfs (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/hda1 on /backup type ext3 (rw,acl,user_xattr)
/dev/sda2 on /database type reiserfs (rw)

(ich hab dieses tolle design nicht verbrochen )

Die Datenbanken liegen unter /database.
Das ganze Zeug haengt an einem U320 (intel?) scsi controller.
Der Controller sagt, alle Platten sind auf go.


Jemand ne Idee?

Upgrade und Enginewechsel kommen nicht in Frage.

 

[bitmuncher]

Einfach mal die Queries loggen und schauen ob evtl. ein bestimmtes Query die Tabellen beschädigt. Und natürlich mal in die Logdatei schauen, ob es da Auffälligkeiten gibt. Vor allem das Error-Logging sollte aktiviert werden, falls noch nicht geschehen. Ansonsten prüfen ob genug RAM/Swap für die Indizes zur Verfügung steht. Sollte eine Replikation aufgebaut sein, auch mal die Error-Meldung aus dem Slave-Status in Betracht ziehen.

 

[Chromatin]

Logs/RAM ist alles OK.
Die Replikationskisten brechen ab und geben die Meldung raus das eine Table auf dem Master gecrasht ist, also in etwa wie auf dem master selbst.

Das Teil laeuft schon jahrelang so vor sich hin. Und vor 3 Tagen hat es dann schleichend angefangen.

Ab und zu hat man sowas, das passiert. Aber so?

*shrugg*

 

[Knoxx]

Hm, da gibts ne Menge Ansatzpunkte...

Greifen andere Anwendungen auf die Tabellen zu? Lässt du mehrere MySQL-Instanzen auf daselbe Data-Directory zugreifen?
Und wie sieht es mit der Auslastung aus? Hat sie zugenommen? Evtl kommt es ja zu den Fehlern aufgrund steigender Queries (was dann wahrscheinlich aber auch auf ein fehlerhaftes DB-Design oder Bugs in der Anwendung schließen lässt.)

Falls mit dem MySQL-Server alles stimmt, nichts verändert wurde und auch die Auslastung nicht zugenommen hat, würde ich auf einen Bug im MySQL-Client oder in der Anwendung vermuten, die auf die Tables zugreift.

 

[Chromatin]

Greifen andere Anwendungen auf die Tabellen zu? Lässt du mehrere MySQL-Instanzen auf daselbe Data-Directory zugreifen? Und wie sieht es mit der Auslastung aus? Hat sie zugenommen? Evtl kommt es ja zu den Fehlern aufgrund steigender Queries (was dann wahrscheinlich aber auch auf ein fehlerhaftes DB-Design oder Bugs in der Anwendung schließen lässt.)

Keine weiteren Anwendungen.
Nur ein MySQL Server.
Auslastung liegt bei Ram/CPU im Durchschnitt etwa bei 60%
DB Design ist mehrere jahre alt, keine Aenderungen, weder an den Tables, noch an den clients.

Es laesst sich ja leider auch nicht reproduzieren, es crashen auch table, die nur gelesen werden.
Absurd.
Ich habe jetzt eine Kiste dazu parallel aufgesetzt und merge das ganze Zeug rueber.

Fuer mich ein klassischer Fall von Ghost in the shell :/