MySQL 5 Stabilität

Hallo,

ich habe eine Anwendung auf MySQL 4.1.x entwickelt und die soll nun in
den Live-Einsatz auf einem MySQL 5 Cluster (2 x Debian Sarge, MySQL
5.0.26 mit jeweils 4 GB Ram). Die Tabellenstrukturen konnte ich alle
problemlos auf dem Cluster anlegen, in dem ich einfach die Engines der
Tabellen in "ndbcluster" geändert habe. Text-Indizes, oder andere
problematische Indizes oder Typen habe ich nicht.

Dann wollte ich die Daten (250 MB Dump-File) als normale INSERTs von der
Kommandozeile importieren, was den Cluster sichtlich aus dem Takt
gebracht hat.

Ich bekomme ständig Fehlermeldungen wie:

ERROR 1296 (HY000) at line 22: Got error 241 'Invalid schema object
version' from ndbcluster

oder:

ERROR 1297 (HY000) at line 30: Got temporary error 4010 'Node failure
caused abort of transaction' from ndbcluster

und dann stoppt der Import.

Wie gesagt, die Tabellenstrukturen sind bereits angelegt. Woran kann das
liegen? Ich bin jetzt etwas skeptisch, was die Stabilität angeht, weil
ich diese Fehlermeldungen über Google im Bug-Portal von MySQL gefunden
habe.

Kann mich jemand beruhigen und mir ggf. helfen, wie ich die Probleme in
den Griff bekomme?

Gruß,
Oliver

Re: MySQL 5 Stabilität

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: MySQL 5 Stabilität

>> 5.0.26 mit jeweils 4 GB Ram). Die Tabellenstrukturen konnte ich alle
>> problemlos auf dem Cluster anlegen, in dem ich einfach die Engines
>> der
>> Tabellen in "ndbcluster" geändert habe. Text-Indizes, oder andere

>Ich bezweifle erheblich, daß man unter MySQL einfach so die
>Storage-Engines wechseln kann wie ein verdrecktes Handtuch. Die
>Unterschiede sind größer als Text-Index hier und da nicht oder so.

Solange man die Anweisungen in der Doku beachtet, sollte es doch keine
Probleme geben.

>> ERROR 1297 (HY000) at line 30: Got temporary error 4010 'Node failure
>> caused abort of transaction' from ndbcluster
>>
>> und dann stoppt der Import.

>Sei froh, das er nicht einfach weitertut als sei alles in Ordnung.

Die Node stürzt ab und das ist nicht in Ordnung. Es läuft dann nur noch
die zweite.

Re: MySQL 5 Stabilität

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: MySQL 5 Stabilität

"Oliver Benning" wrote:
>
> ich habe eine Anwendung auf MySQL 4.1.x entwickelt und die soll nun in
> den Live-Einsatz auf einem MySQL 5 Cluster (2 x Debian Sarge, MySQL
> 5.0.26 mit jeweils 4 GB Ram).

5.0.26 ist schon recht gut abgehangen. Etwas aktueller dürfte es schon
sein. OK, gibts bei Debian nicht :-/

> Die Tabellenstrukturen konnte ich alle
> problemlos auf dem Cluster anlegen, in dem ich einfach die Engines der
> Tabellen in "ndbcluster" geändert habe. Text-Indizes, oder andere
> problematische Indizes oder Typen habe ich nicht.

Du solltest dir trotzdem mal das Cluster-Kapitel im Handbuch durchlesen
und deine Indizes daraufhin ansehen, ob die Cluster-tauglich sind.

Weiterhin stellt sich die Frage, ob Cluster überhaupt die richtige
Technologie für dein Problem ist. MySQL Cluster ist doch deutlich
verschieden von z.B. Oracle RAC. Wenn es ein 2-Knoten Failsafe System
werden soll, wäre z.B. InnoDB auf DRBD, gemanagt von Heartbeat eine
Lösung.

> Dann wollte ich die Daten (250 MB Dump-File) als normale INSERTs von der
> Kommandozeile importieren, was den Cluster sichtlich aus dem Takt
> gebracht hat.
>
> Ich bekomme ständig Fehlermeldungen wie:
>
> ERROR 1296 (HY000) at line 22: Got error 241 'Invalid schema object
> version' from ndbcluster
>
> ERROR 1297 (HY000) at line 30: Got temporary error 4010 'Node failure
> caused abort of transaction' from ndbcluster
>
> und dann stoppt der Import.

....

> Kann mich jemand beruhigen und mir ggf. helfen, wie ich die Probleme in
> den Griff bekomme?

Wenn du Cluster professionell einsetzen willst, würde ich zu einem
Supportvertrag raten. Ansonsten fällt ein Clusterknoten nicht ohne
Grund aus. Zumindest ins Cluster-Log wirst du schon mal schauen müssen.
Daß es prinzipiell funktioniert, zeigen die Cluster-Kunden von MySQL.


XL

Re: MySQL 5 Stabilität

On 2007-02-19 Axel Schwenke wrote:
> "Oliver Benning" wrote:
> >
> > ich habe eine Anwendung auf MySQL 4.1.x entwickelt und die soll nun in
> > den Live-Einsatz auf einem MySQL 5 Cluster (2 x Debian Sarge, MySQL
> > 5.0.26 mit jeweils 4 GB Ram).
>=20
> 5.0.26 ist schon recht gut abgehangen. Etwas aktueller dürfte es schon
> sein. OK, gibts bei Debian nicht :-/

Debian hat 5.0.30 in backports und 5.0.32 in testing.

tschüss,

-christian-

Re: MySQL 5 Stabilität

Hallo zusammen,

Axel Schwenke schrieb:
> Weiterhin stellt sich die Frage, ob Cluster überhaupt die richtige
> Technologie für dein Problem ist. MySQL Cluster ist doch deutlich
> verschieden von z.B. Oracle RAC. Wenn es ein 2-Knoten Failsafe System
> werden soll, wäre z.B. InnoDB auf DRBD, gemanagt von Heartbeat eine
> Lösung.

MySQL-Cluster ist aber eher für Performance-Verteilung als für
Failsafe-Systeme gedacht. Ausserdem halte ich die
InnoDB-auf-DRBD-Variante für *sehr* fragwürdig. Wie wäre es da mit
MySQL-Replikation mit Heartbeat? Das ist meiner Meinung nach die
deutlich bessere Alternative...

Viele Grüße,
Dennis

Re: MySQL 5 Stabilität

Dennis Birkholz wrote:
> Axel Schwenke schrieb:

>> Weiterhin stellt sich die Frage, ob Cluster überhaupt die richtige
>> Technologie für dein Problem ist. MySQL Cluster ist doch deutlich
>> verschieden von z.B. Oracle RAC. Wenn es ein 2-Knoten Failsafe System
>> werden soll, wäre z.B. InnoDB auf DRBD, gemanagt von Heartbeat eine
>> Lösung.
>
> MySQL-Cluster ist aber eher für Performance-Verteilung als für
> Failsafe-Systeme gedacht.

Ich weiß. Deswegen frage ich ja. Die Anwendungsgebiete für NDB (aka
MySQL Cluster) sind doch eher begrenzt. Und insbesondere ein Setup
mit lediglich 2 Knoten ist eher unsinnig.

> Ausserdem halte ich die
> InnoDB-auf-DRBD-Variante für *sehr* fragwürdig. Wie wäre es da mit
> MySQL-Replikation mit Heartbeat? Das ist meiner Meinung nach die
> deutlich bessere Alternative...

Das sind zwei sehr verschiedene Ansätze. Replikation ist asynchron.
Wenn dir der Master-Knoten abstürzt, sind mit an Sicherheit grenzender
Wahrscheinlichkeit Transaktionen verloren gegangen. Ein DRDB mit
Protocol C, einem journaling FS und InnoDB kann dir *garantieren* daß
keine Transaktion verloren geht.

Die Replikationslösung hat natürlich den Vorteil, daß der Backup-Knoten
für Lesezugriffe genutzt werden kann.

Aber wie gesagt, für eine Aussage, was eine sinnvolle Lösung ist,
braucht man erstmal die Info, welches Problem denn zu lösen ist.


XL