bei Sequoia gibt es definitiv kein CREATE DATABASE. Hatte da leider falsch geschrieben. Bessere ich aus.

Continuent ist meiner Meinung nach eher schlecht. Wirklichen Vorteil bringt es mir nicht. Wenn ich was hochverfügbares brauche, wie z.B. im Telefoniebereich oder ISP-Bereich, dann nehme ich ein NDB Cluster (wenn ich FULLTEXT brauche bringt mir das natürlich nichts mehr).
Der MySQL Proxy ist dennoch primär dafür da, dass man READ Requests aufsplittet. Die Failover Funktion ist eher sekundär, aber dennoch wichtig.

Die gesamte Thematik rund um MySQL beobachte ich natürlich weiter, mal schaun ob es bei Sequoia Neuerungen gibt. Bin gespannt, allerdings bin ich eher “hoffnungslos”. Das Lizenzgeld ist es allerdings nicht wert (auch wenn das nun nur noch “Support” ist).

> Ein CREATE TABLE ist nicht vorhanden
Falsch; über den uc/connector von Continuent kann man beliebig Tabellen anlegen / modifizieren.

> als etwas schwächere Variante für einen MySQL Proxy an, wenn man viele Lesezugriffe hat.
Falsch; der Vergleich mit MySQL Proxy geht sehr daneben; es geht hauptsaechlich um Hochverfügbarkeit, und in zweiter Linie um Skalierbarkeit. Einer der grossen Vorteile von Continuent ist der Multi-Master Setup, dessen Vorteile weder MySQL Proxy nich die klassischen Master-Slave Setups bieten können.

> lange nicht so weit, um es beispielsweise mit einem Orcale Cluster aufzunehmen.
Diese Aussage solltest Du in spaetestens 6 Monaten einem Review unterziehen.

Was sehr gut funktioniert und was wir nun aufbauen werden ist ein MySQL Read/Write Cluster. Das Read/Write wird über den MySQL Proxy gesplittet. Je nach Anwendung reicht das aus. READs kann man sehr einfach loadbalancen, aber bei den Writes wirds schwierig, aber das ist dann über Methoden wie du es sagst, lösbar.

lg

Meine Lösung war dann, das die User einfach hardgecoded auf die verschiedenen Server umgeleitet wurden. User 1 – 1000 Server1 1000 – 2000 Server2.

Ist vielleicht nicht die elleganteste Lösung aber relative schnell umsetzbar und Hardware ist ja extrem billig geworden.

Kommen neue User -> einfach ein Kästen hinzustellen.

Das richtige Clustern von LAMP Anwendungen ist ein wenig der Heilige Gral der Internet Applications. Digg.com hat lange vergeblich nach jemanden gesucht, der ihre Seite betreut und wenn sie jemanden gefunden haben war der sehr sehr teuer.

Ich habe mir den Text auf der Webseite [1] noch nicht ganz durchgelesen, bin aber ein wenig verwirrt:
“If you are OK to here it is time to test mysql. On either server mysql1 or mysql2 enter the following commands: Note that we have no root password yet.
[CREATE TABLE ...]”
Das lässt mich irgendwie in dem Glauben, dass man die Server trotzdem noch irgendwie selbst verwalten muss, was ich mir aber nicht vorstellen kann.

“In the case that [the management server] is not running, “split-brain” scenario will occure.”
Wenn ich split-brain richtig interpretiere, dann steht hier ja, dass der Management-Server eben die Aufgabe übernimmt, dass die Daten auf beiden Servern gleich gespeichert werden. So habe ich es eigentlich auch erwartet.

Naja, vielleicht weißt du ja etwas zur MySQL-eigenen Lösung. Das würde mich interessieren, inwiefern die da bessere oder schlechtere Lösungen liefert.

Und wie sieht es bei Oracle aus? Die sind doch Führer bei professionellen DB-Systemen. Bieten die da keine gute Umsetzung an?

Und des Interesse wegen noch: Wie würde man das denn besser machen? Wenn auf Server1 jemand einen Eintrag schreibt und gleichzeitig auf Server2 ein anderer Eintrag eingetragen wird, das Clustering-System aber nicht darauf wartet, dass Server2 auch den Eintrag von Server1 erhalten wird, dann hat man ja zwei Eintrage auf der gleichen ID (auto increment).

Sähe also so aus:
“Hallo mein Freund” => Server1 => ID 15
“Dann mal los” => Server2 => ID 15
Synchronisation im Hintergrund
Server1 => “Hallo mein Freund” => Server2 => ID 16
INKONSISTENZ!

Das könnte man nun vielleicht irgendwie bereinigen lassen, aber wenn nun gleichzeitig noch jemand die Seite aufruft, dann kriegt er vielleicht den falschen Eintrag zugesendet.

Ich verstehe ja das Problem: Zum Schreiben kann man gleich einfach EINEN Server hinstellen, wenn es eh immer so lange dauert, wie der langsamste braucht, aber: Wie anders umsetzen?

So, mal ein langer und hoffentlich qualitativ halbwegs akzeptabler Kommentar meinerseits.

Grüße
Stefan

http://dev.mysql.com/tech-resources/articles/mysql-cluster-for-two-servers.html