RootForum Community

Hat das schon mal einer ausprobiert?

http://dev.mysql.com/doc/mysql/en/NDBCluster.html

Noch nicht probiert, aber du solltest, wenn du es versuchen willst, unbedingt darauf achten, dass du überall min mysql 4.1.8 einsetzt, da von 4.1.7 auf 4.1.8 ETLICHE ndb Bugs behoben wurden.

4.1.8a

Ich will dieses Feature in den nächsten Tagen mal testen. Folgendes Szenario soll abgedeckt werden:

Kunde will Java Applikation betreiben und sich gegen Server-Ausfall absichern.

Auf Server1 und Server2 läuft MySQL Cluster. Auf Server1 läuft Tomcat mit der Applikation. Auf Server2 (in einem anderen Rechenzentrum) ist Tomcat ebenfalls installiert, aber nicht gestartet.

Sollte Server1 abrauchen, startet Kunde seine Applikation auf Server2 und kann nach ein paar Minuten mit aktuellen Daten auf einer anderen URL weiterarbeiten. Kunde informiert seine User per email, dass ab sofort nur noch der Server2 zu nutzen ist.

Was haltet ihr von diesem Konzept? Was kann man besser machen?

(Mir ist natürlich klar, dass eine echte Hochverfügbarkeitslösung noch geclusterte Application Server, Load Balancer usw. haben sollte. Es geht mir um die Frage, wie die bestmögliche Lösung aussehen könnte, wenn man nur zwei rootserver zur Verfügung hat).

Kunde wird per E-Mail informiert? Automatische Umstellungen sind da i.A. wesentlich kundenfreundlicher, oder habe ich das jetzt was falsch verstanden?

Man sollte natürlich alles soweit wie möglich automatisieren und narrensicher machen.

Die Java Applikation ist als Server Applikation nicht darauf eingerichtet, dass eine zweite Applikation auf die gleiche DB zugreift. Man darf also nur eine Applikation zur Zeit nutzen.

Problem: Server1 läuft fehlerfrei, aber ein Router des RZ funktioniert für 3 Stunden nicht. Server2 wird aktiviert, Server1 kann aber nicht abgeschaltet werden, da er netzwerktechnisch nicht erreichbar ist.

Nach 3 Stunden sind nun wieder beide Server im Netz, die Hälfte der User hat den Ausfall evtl. nicht mitgekriegt und arbeitet auf Server1, die andere auf Server2.

Oder man muss in die DB reinschreiben, welcher Server der aktive ist.

Ã?ber RZ Grenzen hinweg wird das nicht (oder nur sehr schlecht) gehen, da die Daten direkt beim Update in der DB im Cluster verteilt werden.

Man muss also mit schlechter Performance rechnen, wenn die beiden MySQL Server in verschiedenen RZ stehen?

Ja, aber auch im gleichen RZ ist das nicht mit einer localen DB zu vergleichen.

Was für Queries verarbeitest Du denn, um damit eine 100Mbit-Leitung auszulasten?

:?:

Also wenn ich den einen Server in Hamburg und den anderen in München stehen habe, dann habe ich da schon ein merkliches Zeitfenster, das benötigt wird, um das Update auf dem einen Server auf dem anderen bekanntzumachen.

Ein einfaches Insert zB. wird auf dem einen Server durchgeführt und erst dann erfolgreich bestätigt, wenn auch auf dem 2. Server die Ã?nderung durchgeführt worden ist.

Bei einer Latency von 15ms und normalerweise 100 Abfragen pro Sekunde sieht man schon recht deutlich, dass eine Abfrage im Cluster min. 15ms (eher aber viel mehr) braucht und somit nur noch 66 Abfragen im Cluster möglich sind.

Hat also nicht wirklich etwas mit dem Volumen der Abfragen zu tun...

ja ausprobiert mit beiden version 4.1.7 weil 4.1.8 nochcniht da war udn jeztt mit der neuen verison

bis zu einer bestimmten grösse gut geeignet aber so wie es aussieht ist das was ich realisierne wolle wohl zu viel(tabellen anzahl) für den mysql cluster

woodworker wrote:bis zu einer bestimmten grösse gut geeignet aber so wie es aussieht ist das was ich realisierne wolle wohl zu viel(tabellen anzahl) für den mysql cluster

In welcher Hinsicht und wie stellst du das fest?

IMHO braucht man ja nur ein Cluster, wenn man EXTREM VIEL will, da es ansonsten auch ein einfacher mysql-Server schafft. (so bis 500 Querys/s sollte jeder gute mysql-Server locker schaffen)

Ich bin auch gerade dabei (nebenberuflich) mich in die NDB Technik von Mysql einzuarbeiten. Gerade die Technik die ganzen DBs komplett im Speicher zu halten bereitet mir etwas Sorgen, weswegen ich bei einem produktiven Einsatz noch davon absehe. Ich teste es zur Zeit auf einer kleinen Maschine (P3 mit 1024 RAM) mit 3 VServer Sessions. Je VServer hat 1 NBD Node und 1 API Node. Auf dem 3. VServer ist ndb_mgm.

Es werden übrigens nur Tabellen "geclustert". Dies bedeutet, daß man auf allen API Nodes die DB erstellen muss, erst dann funzt das clustern innerhalb der DB.

Was ich demnächst testen werde, ist die Mysql eigene DB in NDB umzuwandeln.

Ich habe mal folgendes Szenario simuliert:

DBs auf allen APIs anlegen, auf einem API Node eine Tabelle mit MyISAM erzeugen, dann auf anderem Node eine NDB-Tabelle mit denselben Namen. Irgendwie kam es zu keiner Fehlermeldung. Die Tabelle wurde nicht gesynct.

Man müsste dann das Erzeugen von MyISAM Tabellen global unterbinden. Geht das ?

Standardmäßig NDB als Engine habe ich schon in my.cnf eingestellt.

Für mich persönlich müssen noch viele Tests gemacht werden, da es einfach noch zu neu ist. Was passiert, wenn DB grösser als RAM pro Server ? Darf dann nur Mysql oder können auch weitere Dienste wie Apache laufen ? All solche Fragen meine ich.

Ich hoffe wir können hier unsere Erfahrungen weiter austauschen.

Gruß

PS: Ich verwende die dotdeb Version 4.1.8 auf Woody

Müsste, bei einem Wechsel des Servers, nicht auch der DNS-Eintrag für die Domain geändert werden? Falls ja, wie schnell glaubt ihr geht das???

DNS zu ändern würde ich da nicht empfehlen, da dies zu lange dauert. Was man allerhöchstens mit Heartbeat machen kann: Ein extra Interface/IP nehmen und dann heartbeat regeln lassen, wer diese IP hat und diese dann für myql Queries nehmen.

Aber jetzt bei Mysql Cluster ist das anders, da du jede API Node zum Connecten verwenden kannst. Ideal wäre ein Hardware-Loadbalancer, der dann die die SQL Queries auf alle erreichbaren Nodes verteilt :-D

Ciao

willi wrote:Müsste, bei einem Wechsel des Servers, nicht auch der DNS-Eintrag für die Domain geändert werden? Falls ja, wie schnell glaubt ihr geht das???

Naja . geht doch schnell - wenn mans "richtig" macht. Einfach alle Server in ein internes Netz, welches einen eigenen DNS nutzt. Wenn Du auf diesem DNS die Domain änderst, ist die Ã?nderung im internen Netz sofort verfügbar.

Naja . geht doch schnell - wenn mans "richtig" macht. Einfach alle Server in ein internes Netz, welches einen eigenen DNS nutzt. Wenn Du auf diesem DNS die Domain änderst, ist die Ã?nderung im internen Netz sofort verfügbar.

So wie ich es verstanden habe will er aber die Server in verschiedenen RZ abgleichen, dann wird es wohl länger dauern, oder verstehe ich das falsch?

willi wrote:

Naja . geht doch schnell - wenn mans "richtig" macht. Einfach alle Server in ein internes Netz, welches einen eigenen DNS nutzt. Wenn Du auf diesem DNS die Domain änderst, ist die Ã?nderung im internen Netz sofort verfügbar.

So wie ich es verstanden habe will er aber die Server in verschiedenen RZ abgleichen, dann wird es wohl länger dauern, oder verstehe ich das falsch?

Das ist eigentlich völlig egal, solange er einstellt, dass die Webserver oder sonstige Server die auf die DB zugreifen nur seinen DNS nutzen und so Sachen wie DNS Cache deaktiviert.

Dies funktioniert natürlich nicht bei einem externen Zugriff, bei dem nicht gewährleistet ist, dass der eigene DNS (auf dem die Ã?nderung vorgenommen wird) verwendet wird und somit die Ã?nderung an der Domain sofort aufgelöst wird.