Zuverlässiger Load Balancer für MySQL Cluster?

worel

Well-Known Member
Hallo!

Suche für mein Testprojekt einen stabilen LoadBalancer für den dahinterliegenden MySQL Cluster.

HAProxy lässt sich dafür leider nur bedingt verwenden, da im Fehlerfall nicht zuverlässig genug der defekte Node "aus der Liste" genommen wird.
Kurz angesehen habe ich mir auch "mysql proxy"... Na ich weiß nicht, irgendwie noch ne alpha geschichte.

Der Loadbalancer selbst wird mittels heartbeat zu einem aktiv/passiv Cluster gemacht. Zumindest ist das beim Web Load Balancer so - dieser arbeitet mit HAProxy.

Gibt es dazu Empfehlungen? Also für einen mysql loadbalancer?
 
Hmmm, wie hast Du denn MySQL geclustert? Per Replikation oder mit der Cluster-DB-Engine? Loadbalancing für ein DB-Backend ist so ne Sache für sich. Wenn es "nur" um Ausfall-Sicherheit geht, dann tut's einfache Replikation - in einem Lastverteilungsszenario wird es deutlich ungemütlicher, aber ich schweife ab...

Was ist denn am MySQL Proxy (http://dev.mysql.com/downloads/mysql-proxy/) "Alpha"? Das Ding wird recht rege entwickelt, läuft weder als Beta noch als RC (und ist damit nach MySQL-Release-Politik stable). Ich würde einfach mal mein Glück damit versuchen...
 
Hm, bisher habe ich mich eher auf die Cluster Engine konzentriert. Also 2 Storage Nodes, 2 API Nodes (bzw. SQL Nodes) und 1 Management Node.
Aber du hast recht, das ist schon eher ein komplexeres Ding, und Typo3 und ähnliches bedarf dann einiger Anpassungsarbeiten, wenn das überhaupt möglich ist damit! (aber das ist klar, und müsste vorab natürlich in die Überlegung und Planung einbezogen werden)

Bezüglich mysql proxy dürfte ich das dann irgendwie falsch mitbekommen haben (naja, sind ja schon bei version 0.6.1, nach einigen Jahren der Entwicklung)

Was ist eigentlich mit ldirectord? Unter Linux bekommt man für diese Aufgabenstellung genau diesen Vorschlag.

Funktioniert ldirector mit FreeBSD (was ich gehört habe kann man es per Paket Heartbeat nachinstallieren) auch so gut? Hat damit jemand Erfahrung?

Aufgrund der Komplexität des MySQL Clusters, tendiere ich jetzt aber auch schon eher zu einem MySQL Replikat. Dahingehend habe ich mich noch nicht so eingelesen, aber dürfte ja auch ein Master-Master Modell geben? (nicht nur Master-Slave) Aber auch hier würde ich dann einen LoadBalaner brauchen :cool:
 
Echte Master-Master Replikation gibt es bei MySQL nicht, aber Du kannst einen Replikationsring bilden, da ein Server gleichzeitig Master und Slave sein kann. Der Vorteil einer solchen Lösung liegt darin, dass Du auch die im Funktionsumfang der Cluster-Engine weit überlegenen MyISAM- und InnoDB-Engines nutzen kannst und nicht den Beschränkungen der Cluster-Engine (Partitionierung etc.) unterworfen bist.

Will jetzt nicht Werbung für ein anderes Forum machen, aber hier hat ein MySQL-Consultant eine ähnliche Frage mal beantwortet: http://www.rootforum.de/forum/viewtopic.php?f=23&t=47079#p293535 Ist IMHO mal ganz lesenswert. Vom selben Autor, allerdings in dessen Blog: http://mysqldump.azundris.com/archives/71-Replication-now-and-then.html

Zu Idirector kann ich nix sagen, meine zwei größeren MySQL-Setups hab ich noch auf Linux laufen, und da auch nur mit einfacher Master-Slave-Replikation.
 
Hm, ich denke für den KMU Hausgebrauch wird eine Master-Slave Replika durchaus reichen. Die Cluster Sache ist doch eher heftig. Auch wenns einfach aufgesetzt ist, aber was dann kommt...

Zum Master-Slave Szenario: Greifen alle Abfragen auf den Master, oder wird das auf die beiden Server aufgeteilt (read, write ...)? Bzw. wenn der Master abraucht, musst du manuell die Applikation auf den Slave hinweisen oder wie machst man das?
 
Wenn die Applikation es hergibt, kannst Du read und write aufteilen. Writes müssen logischerweise immer auf einem Master-Node erfolgen, aber wie gesagt, Du kannst auch einen Replikationsring aufziehen, so dass beide Nodes Writes annehmen können.

Wie Du im Fehlerfalle verfährst, hängt davon ab, ob Du einen Loadbalancer (aka MySQL Proxy o. ä.) einsetzt. Mit einem Proxy wird das ganze für die Applikation transparent, und mit einem Replikationsring aus zwei DB-Servern dahinter bekommst Du sowohl Lastverteilung als auch Fail-Over.

Ohne Proxy musst Du zu anderen Mitteln greifen. Ein einfacher Daemon ist mit Python o. ä. schnell gescriptet, der in einer Schleife in einem Try-Catch-Block permanent versucht, die MySQL-Nodes zu kontaktieren. Im Falle eines Ausfalls kann das Script ja dann die Konfigurationsdatei der Applikation überschreiben/austauschen und ggf. den App-Server SIGHUPen, um alle Verbindungen über den/die verbliebenen Node(s) laufen zu lassen.

Wenn ich richtig gesehen habe, möchtest Du das ganze für eine Typo3-Installation haben. Hast Du denn vor, massiv Module einzusetzen, die selbst wieder in die DB schreiben (Index u. ä.)? Ansonsten dürfte es die Redaktion kaum schaffen, einen Server mit Writes an seine Leistungsgrenze zu bringen. Die Masse werden dann wohl doch eher Reads sein. In so einem Fall würde ich die Writes ganz normal auf den Master laufen lassen und die Reads per MySQL Proxy auf Master und Slave verteilen. Dürfte allerdings ein ganz netter Anpassungsaufwand bei Typo3 selbst sein...
 
Meinst du mit Replikationsring die "Master - Master" Replikation?

Weil das verstehe ich bei dieser Replikationsart noch nicht: kann ich auf beide schreibend/lesend zugreifen oder ist wieder nur einer mein "Hauptserver", und der andere steht als Replikat bereit.
 
Echtes Master-Master kennt MySQL nicht. Als Ersatz kann man mit mehreren (im einfachsten Fall zwei) Servern über Kreuz replizieren (oder eben im Ring). Beispiel:

Server 1 --- repliziert ---> Server 2
Server 2 --- repliziert ---> Server 1

Damit sind beide Server gegenseitig Master und Slave. Das ist in etwa das, was bei MySQL "Master-Master" am nächsten kommt. Wenn Du auf Server 1 schreibst, landen die Writes per Replikation bei Server 2 und umgekehrt => Du kannst also auf beiden Servern schreiben.

Kleiner Haken: Du musst natürlich aufpassen, dass aus dem Relay Log nichts ins Binlog wandert, sonst bekommst Du eine Endlos-Schleife (ich wüsste aber nicht, ob man das überhaupt hinbekommt, selbst wenn man's wollte...)
 
Hieße also, dass man mit dieser Lösung einen für die Applikation weitgehend transparenten 2 Node aktiv-aktiv "Cluster" hat, worauf auf beide gelesen/geschrieben werden kann? (wenn man diesen per loadbalancer oä. anspricht)

Habs gerade auf mysql.org gelesen: der mysql proxy wird schon noch als alpha eingestuft.
 
Diese Master-Master-Replikation arbeitet bei uns seit einiger Zeit fuer "poebelige" Datenbanken wie Bugzilla und Cacti, etc. eigentlich ganz ok.

(Abgesehen davon, das schon 2x nach Systemcrash die Cacti-Datenbank korrumpiert war. Ist MySQL nicht toll? :/)
 
Zurück
Oben