MySQL maakt data stuk

[WildernessChild]

Hopelijk kunnen jullie helpen met dit ernstige probleem.

Het gaat om een dual-Opteron machine (AMD64 dus) met daarop Gentoo Linux. Hierop draait ook een MySQL-server. Deze geeft al sinds enige tijd problemen.

Als ik doe:

code:

$ /etc/init.d/mysql stop
 * Stopping mysqld ...
start-stop-daemon: warning: failed to kill 10565: No such process         [ ok ]
$ cd /var/lib/mysql
$ myisamchk -s */*.MYI
...
myisamchk: MyISAM file Forum/ibf_topics_read.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
MyISAM-table 'Forum/ibf_topics_read.MYI' is usable but should be fixed
...

Op de plaats van de puntjes staan nog veel meer soortgelijke errors, allemaal op tabellen die geschreven zijn sinds de laatste reparatie. Ik vind de No such process ook verdacht. Repareren doe ik met:

code:

myisamchk -r -s -S */*.MYI
/etc/init.d/mysql start

Tot voor kort heeft dit niet tot ernstige problemen geleid... maar nu heb ik gemerkt dat er toch corruptie van de data is ontstaan!

In mysqld.err zie ik:

code:

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=134217728
read_buffer_size=4190208
max_used_connections=7
max_connections=100
threads_connected=5
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 949871 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

/usr/sbin/mysqld: ready for connections.
Version: '4.0.24'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-4.0.24
050729 13:19:34 /usr/sbin/mysqld: Got error 127 from table handler
050729 13:19:34 /usr/sbin/mysqld: Sort aborted
050729 13:19:37 /usr/sbin/mysqld: Got error 127 from table handler
050729 13:19:37 /usr/sbin/mysqld: Sort aborted
050729 13:19:39 /usr/sbin/mysqld: Got error 127 from table handler
050729 13:19:39 /usr/sbin/mysqld: Sort aborted
...

Momenteel ben ik aan het proberen alle dependencies van MySQL te rebuilden. Toch ben ik benieuwd naar jullie ideeen over de mogelijke oorzaken van dit probleem.

[Verwijderd]

Probeer eens een grote programma te compilen of nog beter een nieuwe kernel, alleen compilen dan. Als je dan hele rare errors krijgt te zien, dan denk ik dat je geheugen defect is, wat hier heel erg op lijkt. Maar het kan ook zo zijn de de mysql niet goed is gecompiled. Heb je hem zelf gecompiled?

[WildernessChild]

Ja, het is Gentoo, dus alles wordt zelf gecompiled. Ook vliegt Apache er af en toe uit met een segfault, maar dat gebeurt misschien eens in de maand ofzo.

Ik wil best het geheugen gaan testen; kan dat gewoon met memtest86, ook op een dual Opteron?

[Verwijderd]

Ja je kan het testen met memtest. Die segfault ook met apache geeft aan dat mijn vermoeden juist is. Je geheugen is ergens denk ik stuk. Hoop dat het lukt voor je. Geheugen problemen zijn niet leuk, zeker niet als je bijvoorbeeld 8x 512mb ram ergens in heb zitten (wat ik dus ooit heb gehad). Succes!

[WildernessChild]

Geheugen staat momenteel te testen, maar lijkt in orde te zijn (na 3 tests, 27% in totaal, nog geen errors). Mijn vermoeden gaat nu richting:
1. temperatuur van de CPU's; of
2. softwareprobleem
Ik zal zometeen de temperatuur checken. Maar kan dat uberhaupt dit soort problemen veroorzaken? De kernel zelf bijvoorbeeld is nog nooit van zijn stokje gegaan.

[Verwijderd]

Je kernel hoeft ook niet van zijn stokje te gaan hierdoor. Deze word gewoon geladen door het "goede" geheugen en kan gewoon laden. Het kan inderdaad ook zijn dat 1 van je processors stuk is aan het gaan, maar dat gebeurd echt heel zelden, en heb ik nog maar 1x in mijn leven meegemaakt, maar meestal gaat het gewoon echt stuk, en niet zoals jij nu beschrijft. Ik denk dat het nog steeds je geheugen is, anders compile je een kernel om te kijken of je errors krijgt.

[Elektronicanet]

Check voor de zekerheid je voltages ook eens ?

[WildernessChild]

Ik heb net 4 kernels gecompileerd, met (uiteraard) dezelfde .config, en dat gaf geen errors. Maar:

code:

$ ls -l bzImage.*
-rw-r--r--  1 root root 1959802 Jul 29 15:30 bzImage.1
-rw-r--r--  1 root root 1959802 Jul 29 15:32 bzImage.2
-rw-r--r--  1 root root 1959803 Jul 29 15:35 bzImage.3
-rw-r--r--  1 root root 1959801 Jul 29 15:44 bzImage.4

Bekijk de groottes eens... Ook diff vindt dat ze verschillend zijn. Hoort dit zo?

[ Voor 8% gewijzigd door WildernessChild op 29-07-2005 15:33 ]

[Verwijderd]

Hmmmm,

Dat ze soms in groote verschillen komt door de kernel zelf, maar over het algemeen naar mijn weten zou dit niet veel uit moeten maken. Je kreeg geen foutmeldingen, en je memtest gaf geen fouten aan? Dan kan het ook zijn (ja dit gaat leuk worden) je moederbord zijn, die defect aan het raken is, maar ook dit kan je dus niet testen... dus nu kan je misschien je bios controleren op voltage fouten in je cpu.

[WildernessChild]

Dat soort ernstige dingen zouden toch wel meer fouten moeten opleveren dan subtiele databasecorruptie en een paar segfaults...

Hier vast de uitvoer van sensors:

code:

w83627hf-isa-0290
Adapter: ISA adapter
VCore 1:   +1.54 V  (min =  +1.42 V, max =  +1.57 V)
VCore 2:   +1.52 V  (min =  +1.42 V, max =  +1.57 V)
+3.3V:     +3.34 V  (min =  +3.14 V, max =  +3.47 V)
+5V:       +5.00 V  (min =  +4.76 V, max =  +5.24 V)
+12V:      +4.99 V  (min = +10.82 V, max = +13.19 V)
-12V:      -1.34 V  (min = -13.18 V, max = -10.80 V)
-5V:       -3.94 V  (min =  -5.25 V, max =  -4.75 V)
V5SB:      +5.56 V  (min =  +4.76 V, max =  +5.24 V)
VBat:      +2.61 V  (min =  +2.40 V, max =  +3.60 V)
fan1:        0 RPM  (min = 4326 RPM, div = 2)
fan2:        0 RPM  (min = 3199 RPM, div = 2)
fan3:        0 RPM  (min = 3879 RPM, div = 2)
temp1:       +49 C  (high =   +58 C, hyst =   -49 C)   sensor = thermistor      
temp2:     +45.0 C  (high =   +80 C, hyst =   +75 C)   sensor = thermistor      
temp3:     -48.0 C  (high =   +80 C, hyst =   +75 C)   sensor = thermistor      
vid:      +1.500 V  (VRM Version 2.4)
alarms:   Chassis intrusion detection                      ALARM
beep_enable:
          Sound alarm disabled

Het is trouwens een Tyan Thunder K8W moederbord. Er zijn een aantal waarden hier die dermate veel afwijken, dat ik denk dat het aan de sensors ligt (+12V op 4.99 V bijvoorbeeld). Ik ga nu eens kijken wat de BIOS zegt.

[WildernessChild]

BIOS zegt:

code:

CPU0 Vcore:        schommelt tussen 1.532 en 1.564 V
CPU1 Vcore:        schommelt tussen 1.532 en 1.564 V
CPU0 DIMM Voltage: schommelt tussen 2.612 en 2.661 V
CPU1 DIMM Voltage: schommelt tussen 2.540 en 2.544 V
+5V RUN:           schommelt tussen 5.011 en 5.018 V
+3.3Vin:           schommelt tussen 3.354 en 3.370 V
+3.3VSB:           schommelt tussen 3.246 en 3.250 V
+12Vin:            schommelt tussen 11.169 en 11.185 V

Zijn dit abnormale getallen?

[Verwijderd]

Dit is echt raar. Heb je met de memtest wel volledig laten testen, zo`n test duurde naar mijn weten wel langer als een paar uur, zo`n beetje 10 a 15 uur, afhankelijk van de hoeveelheid gegheugen. Ik zie in jouw configuratie voltage en dergelijke niet echt schikbarende dingen. Toch is er iets met de hardware... heb je ook je harde schijf gecontroleerd en dergelijke.... het is heel lastig om inderdaad een hardware fout te vinden soms.

[TD-er]

Ik werk ook op die machine, dus heb de fouten aan den lijve ondervonden

Maar goed, die +12V (11.3 V) is eigenlijk verdacht laag.
Het zou kunnen dat bijv. de harde schijven mogelijk wat kuren kunnen krijgen.

[Olaf van der Spek]

WildernessChild schreef op vrijdag 29 juli 2005 @ 13:23:
start-stop-daemon: warning: failed to kill 10565: No such process [ ok ]

Op de plaats van de puntjes staan nog veel meer soortgelijke errors, allemaal op tabellen die geschreven zijn sinds de laatste reparatie. Ik vind de No such process ook verdacht. Repareren doe

Heb je gechecked of MySQL wel echt gestopt is? En welke pid het voor de stop had?

[WildernessChild]

Het probleem deed zich eerder ook al voor, en toen kreeg ik deze foutmelding niet.

Maar... bij het inbakken van de temperatuur- en voltagesensors in de kernel heb ik die gelijk maar even geupgrade van 2.6.9 naar 2.6.12... en nu lijkt het probleem over te zijn!

Als dat niet zo is horen jullie vast nog van mij

[Verwijderd]

Tja, kan ook wonderen doen

Wist niet dat je nog oudere kernel draaide

[Wilke]

Verwijderd schreef op vrijdag 29 juli 2005 @ 15:44:
Dat ze soms in groote verschillen komt door de kernel zelf,

Met precies dezelfde configuratie? Ik mag toch hopen dat het proces exact herhaalbaar is en dat je dus elke keer precies hetzelfde bestand krijgt...

Het hoeft niet per se iets met de hardware te zijn overigens, ik hoop niet dat er erg aggressieve CFLAGS zijn ingesteld? Wat staat er in dat deel van /etc/make.conf (wat gaat over de CPU settings, CFLAGS etc.)?

Overigens, MyISAM tables - is het niet handiger om InnoDB tables te gebruiken?

[TD-er]

Wilke schreef op zaterdag 30 juli 2005 @ 12:45:
[...]


Met precies dezelfde configuratie? Ik mag toch hopen dat het proces exact herhaalbaar is en dat je dus elke keer precies hetzelfde bestand krijgt...

Het hoeft niet per se iets met de hardware te zijn overigens, ik hoop niet dat er erg aggressieve CFLAGS zijn ingesteld? Wat staat er in dat deel van /etc/make.conf (wat gaat over de CPU settings, CFLAGS etc.)?

Overigens, MyISAM tables - is het niet handiger om InnoDB tables te gebruiken?

Is dat niet gewoon een date-stamp van het comprimeren die telkens anders is en mogelijk gecomprimeerd wordt?

[Verwijderd]

TD-er schreef op zaterdag 30 juli 2005 @ 13:04:
[...]

Is dat niet gewoon een date-stamp van het comprimeren die telkens anders is en mogelijk gecomprimeerd wordt?

Naar mijn weten is dat het ook!

[Wilke]

Ahh ok, 1 byte verschil zou dan idd nog wel kunnen ja...niet aan gedacht

[WildernessChild]

De kernel-upgrade lijkt inderdaad geholpen te hebben... als ik nu de server stopzet en myisamchk draai zie ik alleen nog maar die "client has not closed table properly" meldingen. Komt dit doordat het Gentoo init-script de server iets te bruut doodmaakt? Of hoort het niet zo?

[DJ Buzzz]

Het hoort iig niet zo. Ik weet zo niet welke CFLAGS je gebruikt, maar ik zou voor wat conservatieve instellingen gaan (-O2 b.v.) en dan nog eens glibc, apache en mysql opnieuw compilen en dan kijken of je er nog steeds last van hebt.