Mysql 4.1.14 zerschiesst immer die gleiche Tabelle

[maku]

Hallo,

ich habe folgendes Problem:

ich habe auf einem Server die Lernplattform ILIAS laufen. Und zwar seit etwa Juli letzten Jahres. Das ging bis gestern auch alles gut.
Seit gestern jedoch erscheint, nachdem man in ILIAS ein Objekt angelegt hat (vornehmlich eine Grafik hochgeladen hat) bspw. folgende Fehlermeldung:

Code: Select all

DB Error: already exists
SQL: INSERT INTO object_data (type,title,description,owner,create_date,last_update,import_id) VALUES ('mob','logo.png','','116',now(),now(),'')

Danach ist immer eine bestimmte Tabelle zerschossen. myisamchk -c sagt bspw. dazu:

Code: Select all

Checking MyISAM file: object_data.MYI
Data records:     917   Deleted blocks:       0
myisamchk: warning: Table is marked as crashed
myisamchk: warning: 1 client is using or hasn't closed the table properly
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
myisamchk: error: Found key at page 8192 that points to record outside datafile
MyISAM-table 'object_data.MYI' is corrupted
Fix it using switch "-r" or "-o" 

ein anschliessendes myisamchk -r oder -o bringt nur bis zum nächsten seitenaufruf in ILIAS einen Erfolg.

Längerfristiger Erfolg stellt sich nur ein, wenn ich mit phpmyadmin die Tabelle repariere. Doch nach (immer unterschiedlich) vielem Anlegen von Objekten in ILIAS, zerschiesst er die Tabelle wieder.

Jemand vom ILIAS Entwicklerteam ist mit mir netterweise alles durchgegangen, musste am Ende aber doch mehr oder weniger passen. Was er aber sagte, war in etwa folgendes:

- scheinbar kann plötzlich der Primärindex in dieser Tabelle nicht mehr auto increment gesetzt werden. Wieso auch immer ...

Die Tabelle ist mit ca. 900 Einträgen nicht sonderlich groß, spezieller code wird dort auch nicht ausgeführt.

Meine config:

apache 1.3.33
php 5.0.4 (wenn überhaupt wichtig)

aber am Wichtigsten:

Mittlerweile Mysql 4.1.14.
Vorher war es 4.1.12 - denn als erstes habe ich ein update versucht :roll:

Habe auch einen dump gemacht und diesen in eine neu erstellte DB eingespielt - Nix gebracht.

Ich steh mehr als auf dem Schlauch ... wie geschrieben, das Ding läuft seit über ´nem Jahr, zu der Zeit kein update kein nix - und peng

Hat vielleicht jemand eine Idee?

Danke,

Mark

[maku]

Hallo,

da mein Problem immer noch besteht, vielleicht mal etwas anders:

Hat zufällig jemand ebenfalls eine Version von myslq-4.1.1x ebenfalls selber kompiliert und hat nun auch irgendwelche sporadisch auftrenden Tabellen-crashes? So in etwa wie in

http://dev.mysql.com/doc/refman/5.0/en/ ... ables.html

oder in

http://dev.mysql.com/downloads/mysql/4.1.html

und zwar im Sinne von:

"Several users have reported random crashes and table corruptions when using MySQL binaries compiled with gcc 2.96 on the x86 Linux platform. We suggest that you use gcc 2.95 or gcc 2.91 to compile your own binaries. It should also be safe to use gcc 3.2."

Wäre dankbar für jeden Hinweis oder Tipp!

Danke,

Mark

[flo]

Das ist doch ein guter Tipp - kompiliere Dein MySQL doch mit nem anderen GCC.

flo.

[maku]

Hmm, ja ...

habe vergessen zu erwähnen, dass ich gcc (GCC) 3.3.3 (SuSE Linux) verwende.

Der steht da halt nicht bei, dachte aber, da 3.2 okay ist, wäre 3.3 auch okay.

Bevor ich da nun einen `downgrade` mache (und aus meiner Erfahrung bringt dies gerade bei dem Compiler viele Nachteile mit sich) frage ich erst mal, ob evtl. jemand halt ähnliche Erfahrungen gesammelt hat.

Vielleicht noch etwas:

Mittlerweile habe ich zwei andere Rechner mit einbezogen. Und zwar habe ich auf die nur den DB-Server verlagert.

Der Ausgangsrechner ist ein Dual-Xeon System ---> ursprünglicher Fehler
Der erste 'Ersatz-DB' Server ist ein Single-Xeon System ---> wieder der ursprüngliche Fehler
Der zweite 'Ersatz-DB' Server ist ein Pentium 4 System ---> erst nach drei Tagen das gleiche Problem, allerdings zuerst mit einer anderen Tabelle - im Anschluss daran direkt wieder das Ursprungsproblem mit ebenfalls der Ursprungstabelle ...

Daher dachte ich zunächst, es wäre ein Xeon spezifisches Problem mit Mysql 4.1.x. Scheinbar lag ich damit falsch ...

Probiere gerade die binaries von mysql aus - und werde auch ein php update auf die 5.0.5 vornehmen.

Bin aber keiner guten Hoffnung

Danke jedenfalls,

Mark

[Joe User]

Warum so kompliziert? Nimm einfach eine andere MySQL-Version (4.1.13)...

[maku]

Nun, das ganze hat begonnen mit MySQL 4.1.12

Und das Witzigste: Ich habe im (ich glaube) Juli das Upgrade darauf gemacht, und am 12. Oktober kam der erste o.g. Fehler. Und seit dem hagelt es nur so davon.

Ich würde am liebsten wieder auf die 4.0.x downgraden, aber man sagte mir, dass nach einem up auf die 4.1 ein down 'nicht' mehr möglich sei, da die Strukturen zu stark abweichen würden.

[Joe User]

Um ein Downgrade von 4.1 auf 4.0 vorzunehmen, gehst Du am Besten so vor:

Code: Select all

mysqlcheck --analyze --check --auto-repair --extend --optimize --all-databases -uroot -p
mysqldump --opt --allow-keywords --delayed-insert --default-character-set=latin1 -c -i -uroot -p $database > /path/to/$database.sql

Die zweite Zeile wiederholst Du für jede DB (ausser "mysql") und ersetzt dabei $database durch den jeweiligen DB-Namen. Nach der Installation von MySQL 4.0 führst Du Folgendes aus und beantwortest alle Fragen, abgesehen vom Root-Passwort, mit ENTER:

Code: Select all

/etc/init.d/mysql start
/usr/bin/mysql_secure_installation

Anschliessend legst Du die DB-User neu an und importierst die Datenbanken:

Code: Select all

mysql -uroot -p < /path/to/$database.sql
mysqlcheck --analyze --check --auto-repair --extend --optimize --all-databases -uroot -p

Fertig.

[maku]

Erst einmal vielen Dank!

So, gesagt, getan. Ich hatte diese Art dump bereits aus einem älteren Beitrag von Dir. Der hatte bereits leider nicht geklappt. Allerdings war dieser nun wesentlich ausführlicher.

Ich habe (der Praktikabilität etc ;) wegen) die mysql Version von der SuSE 9.1, das ist die 4.0.21 genommen. Ist ja erst mal egal.

Auf dem Rechner mit der 4.1er wie Du geschrieben hast, den dump gemacht, rüberkopiert und per root wollte ich ihn einspielen. Leider klam es zu folgender Fehlermeldung (wegen der utf-8 Geschichte):

Code: Select all

ERROR 1064 at line 21: You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near 'DEFAULT CHARSET=latin1' at line 9

[Joe User]

Oops, glatt vergessen, Folgendes müsste ausreichen:

Code: Select all

sed 's/ENGINE=MyISAM/TYPE=MyISAM/g' /path/to/$database.sql
sed 's/ DEFAULT CHARSET=latin1//g' /path/to/$database.sql

[maku]

Nochmal hmmm,

was sed da macht leuchtet mir ja ganz dunkel ein, aber wann genau mach ich das? Ich hab es jetzt auf den existierenden dump gemacht. Wenn ich die beiden Zeilen so ausführe, kommt leider die gleiche Fehlermeldung.

Danke und Gruß,

Mark

[maku]

sed ändert leider nichts an dem dump. musste ich gerade feststellen. aber wie gesagt, mag ja sein, dass ich ihn an der falschen stelle drübergeschickt habe ...

Eine kleine Zeile, nach sed:

Code: Select all

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

[Joe User]

Ich hab es jetzt auf den existierenden dump gemacht.

Richtig.

Wenn ich die beiden Zeilen so ausführe, kommt leider die gleiche Fehlermeldung.

Tippfehler, sorry:

Code: Select all

sed 's/ENGINE=MyISAM/TYPE=MyISAM/g' -i /path/to/$database.sql
sed 's/ DEFAULT CHARSET=latin1//g' -i /path/to/$database.sql

[maku]

Okay, danke ,
jetzt kommt aber schon die nächste Fehlermeldung:

Code: Select all

ERROR 1064 at line 131: You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near 'CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  PRIMARY KEY  (

Eine Idee?

Danke!

Mark

[Joe User]

Ersetze CURRENT_TIMESTAMP mal durch NOW() und versuche es erneut. Fehlermeldung?

[maku]

Oje, ich nullcheck:

Welches CURRENT_TIMESTAMP denn?

Die Zeile im dump sieht so aus

`TIMESTAMP` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,

[Joe User]

Google schlägt unter Anderem folgende Ã?nderung vor:

Code: Select all

`TIMESTAMP` timestamp NOT NULL default 'CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP',

HTH

[maku]

Ja, Deine Hoffnung hat Dich nicht getrübt ;) !

Habe alle geändert und er hat es bis zum nächsten Fehler gemeistert.

Code: Select all

You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near 'DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci' at line

Die Zeile dort lautet:

) TYPE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Was Google da ausspuckt sagt mir gar leider wie immer gar nix ... :oops:

Die DB ist von mir in der MySQL 4.1.12er Variante folgendermaßen angelegt worden:

Code: Select all

mysql> CREATE DATABASE xyz CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Sollte ich das vor einem dump wieder umstellen? Geht so etwas dann überhaupt noch? Oder kann man diese Zeichensatz Einstellungen gar einfach löschen?

Danke,

Mark

[Joe User]

Sollte ich das vor einem dump wieder umstellen?

Falls möglich, ja.

Oder kann man diese Zeichensatz Einstellungen gar einfach löschen?

Hierzu müssen wahrscheinlich die Datensätze erst von utf8 nach latin1 konvertiert werden. IIRC bietet MySQL hierfür eigene Funktionen an, notfalls tut es auch iconv:

Code: Select all

iconv -f UTF-8 -t LATIN1 /path/to/$database.sql > /path/to/$database.latin1.sql
mv /path/to/$database.latin1.sql /path/to/$database.sql

HTH