Datenimport in einen Cluster

Hallo Zusammen,

Zwei Fragen:
A) Gibt es noch eine andere Möglichkeit Tabellen aus einer vorhandenen
DB in einen Cluster zu mirgieren ausser über einen Dump? DIe Datafiles
in das Datenverzeichniss zu kopieren klappt ja sicher nicht.
B) Ist es richtig das die mgmnt node nur die Clusterkonfiguration
vorhält und nicht aktiv dirigiert, und somit auf jeder Datanode auch
eine mgmnt node laufen kann? Warum wird dann in der
Beispielkonfiguration von mysql.com ein zusätzliches System als mgmnt
node eingesetzt?

Besten Dank, Oliver

Re: Datenimport in einen Cluster

"osc" wrote:

> A) Gibt es noch eine andere Möglichkeit Tabellen aus einer vorhandenen
> DB in einen Cluster zu mirgieren ausser über einen Dump? DIe Datafiles
> in das Datenverzeichniss zu kopieren klappt ja sicher nicht.

Ja und Ja.

Der MySQL-Cluster ist ja praktisch die extremste Form, SQL-Engine und
Storage-Engine zu trennen. Datenfiles sind immer spezifisch für eine
bestimmte Storage-Engine. Deswegen kann die Cluster-Engine (aka NDB)
z.B. nix mit MyISAM-Files anfangen.

Allerdings kannst du NDB auch über ein proprietäres Protokoll
ansprechen (am SQL-Server vorbei). Auch auf diesem Weg können also
Daten in ein Cluster migriert werden. Wenn die Daten schon in einem
SQL-Node vorliegen (z.B. als MyISAM-Tabelle), wäre wohl
ALTER TABLE ... ENGINE=NDB
die sinnvollste Lösung.

> B) Ist es richtig das die mgmnt node nur die Clusterkonfiguration
> vorhält und nicht aktiv dirigiert, und somit auf jeder Datanode auch
> eine mgmnt node laufen kann? Warum wird dann in der
> Beispielkonfiguration von mysql.com ein zusätzliches System als mgmnt
> node eingesetzt?

Ja. Weil es ums Prinzip geht? Du kannst auch mehr als eine Datanode
pro physischer Maschine laufen lassen. Oder Mgmt + SQL-Node zusammen.
Oder oder oder. Nodes sind *logische* Einheiten.


XL

Re: Datenimport in einen Cluster

Hallo Axel,
zu A) "ALTER TABLE ... ENGINE=3DNDB " ist klar, nur was mache ich dann?!
In meiner Testumgebung habe ich genau das gemacht, also CLuster zum
Fliegen gebracht, runtergefahren, die ehemals MyISAM nun NDB Datafiles
reinkopiertund wieder gestartet. Folge: Nix. Weder Fehlermeldungen noch
Datenzugriff.

zu B) Hm, wennn es ums Prinizp geht wäre im Sinne der Vermeidung eines
SPOF eine redundanz der Managemnet Node doch sinnvoll. Mein Szenario:
zwei physische Server je als Data Node, ein Application Server mit der
SQL Node, für den es einen coldstandby gibt. Daher würde ich jeweils
eine Managemnet Node auf jeder Data Node favorisieren. SPricht was
dagegen? Setzt Du inzwischen auch auf Cluster oder weiterhin auf die
gute alte Replikation? Beste Grüsse, Oliver

Re: Datenimport in einen Cluster

osc schrieb:
> Hallo Axel,
> zu A) "ALTER TABLE ... ENGINE=NDB " ist klar, nur was mache ich dann?!
> In meiner Testumgebung habe ich genau das gemacht, also CLuster zum
> Fliegen gebracht, runtergefahren, die ehemals MyISAM nun NDB Datafiles
> reinkopiertund wieder gestartet. Folge: Nix. Weder Fehlermeldungen noch
> Datenzugriff.


Wieso fährst du da irgendetwas runter und kopierst irgendwelche Daten
per Hand? Sowas ist aus meiner Sicht nix sinnvolles.

Nach dem Alter Table machst du eigentlich gar nix mehr, weil fertig.

Grüße

Dirk

Re: Datenimport in einen Cluster

osc schrieb:
> zu A) "ALTER TABLE ... ENGINE=3DNDB " ist klar, nur was mache ich dann?=
!
> In meiner Testumgebung habe ich genau das gemacht, also CLuster zum
> Fliegen gebracht, runtergefahren, die ehemals MyISAM nun NDB Datafiles
> reinkopiertund wieder gestartet. Folge: Nix. Weder Fehlermeldungen noch=

> Datenzugriff.

Du hast Axel nicht ganz richtig verstanden.

Er meinte, dass ein _bestehender_ MySQL-Server, welcher bereits Zugriff=20
auf die Datenbank hat in den Cluster integriert wird. Dann reicht es,=20
den Tabellentyp zu ändern.

Das Kopieren den Datafiles wird genau _NULL_ bringen. Egal was du tust,=20
MySQL greift nicht einfach mal eben auf neue Files zu, nur weil die da=20
im richtigen Verzeichnis liegen.

Wenn du eine "externe" Datenbank in deinen Cluster integrieren willst,=20
wirst du wohl um den Import kaum herumkommen.

Lies und beherzige bitte unbedingt:
http://learn.to/quote/

Wir sind _kein_ Webforum.

--=20
HTH,
Fabian

Re: Datenimport in einen Cluster

"osc" wrote:

> zu A) "ALTER TABLE ... ENGINE=NDB " ist klar, nur was mache ich dann?!

Dann bist du fertig :-)

> In meiner Testumgebung habe ich genau das gemacht, also CLuster zum
> Fliegen gebracht, runtergefahren, die ehemals MyISAM nun NDB Datafiles
> reinkopiert und wieder gestartet.

Was meinst du mit "ehemals MyISAM nun NDB Datafiles"?

Wenn du einen Cluster frisch aufsetzt, dann sind die Datanodes erstmal
leer. Die SQL-Nodes enthalten typischerweise die 'mysql' und 'test'
Datenbanken als lokale MyISAM-Tables. Sobald du nun eine Tabelle mit
Engine=NDB anlegst, wird diese auf den Datanodes (verteilt & gespiegelt)
gespeichert.

Allerdings kannst du einen bereits existierenden standalone MySQL-
Server als SQL-Node deines neuen Clusters weiternutzen. Dann bleiben
die alten (= nicht-Cluster) Datenbestände dieses SQL-Nodes erhalten
(sind aber auch nur von diesem SQL-Node zu erreichen und nicht
ausfallsicher). *Diese* Tabellen kannst du nun per ALTER TABLE in den
Cluster migrieren.

> zu B) Hm, wennn es ums Prinizp geht wäre im Sinne der Vermeidung eines
> SPOF eine redundanz der Managemnet Node doch sinnvoll. Mein Szenario:
> zwei physische Server je als Data Node, ein Application Server mit der
> SQL Node, für den es einen coldstandby gibt. Daher würde ich jeweils
> eine Managemnet Node auf jeder Data Node favorisieren.

Die Mgmnt. Node brauchst du immer dann, wenn ein {Data,SQL}-Node deines
Clusters (re)startet. Wenn du nur eine SQL-Node hast, dann reicht es
IMHO die Mgmnt. Node zur SQL-Node zu packen. Beim Failover mußt du dann
halt die Mgmnt-Node vor der SQL-Node starten. Alternativ pack halt zwei
Mgmnt-Nodes zu den Datanodes.

> Setzt Du inzwischen auch auf Cluster oder weiterhin auf die
> gute alte Replikation?

Ich habe noch keinen einzigen Cluster aufgesetzt :-O
Bisher paßten meine Anwendungen nicht dazu. Aber ja, mit Replikation
habe ich schon sehr viel gemacht...


XL

Re: Datenimport in einen Cluster

osc wrote:
> B) Ist es richtig das die mgmnt node nur die Clusterkonfiguration
> vorhält und nicht aktiv dirigiert, und somit auf jeder Datanode auch=

> eine mgmnt node laufen kann? Warum wird dann in der
> Beispielkonfiguration von mysql.com ein zusätzliches System als mgmnt=

> node eingesetzt?

Der Management node ist auch gleichzeitig Arbitrator, d.h. er bestimmt
im Fall eines Network split in zwei gleichgroße Teile welche der beiden=

Hälften weiterarbeiten soll. Sind mehrere Management Nodes vorhanden
so stimmen diese untereinander ab wer der aktive Arbitrator sein soll.
Wenn nun genau die Hälfte der Data Nodes ausfällt und der aktive
Arbitrator auf einem dieser Data Nodes liegt dann fällt der gesamte
Cluster aus. Daher sollten der oder die Management Nodes möglichst
unabhängig von den Data Nodes sein (insbesondere in Sachen Strom).
Management Nodes erkennen zudem wenn in der Konfiguration Mgmt.-
und Data-Nodes auf der gleichen Maschine liegen und meckern das an.

--=20
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com

http://www.mysql.com/support/