RootForum Community

Hallo zusammen,

Ich könnte mal Eure Hilfe bei folgender Überlegung brauchen.

Ich habe für mehrere Applikationen einen MySQL-Server der atm über Heartbeat und Replikation „ausfallsicher" gehalten wird. Jetzt werden aber weitere Applikationen dazu geschaltet und niemand kann genau vorhersagen, wie sich der DB-Server verhalten wird. Aus diesem Grund suche ich nach einem Konzept um die Last auf mehr als einen Server zu verteilen. Aber egal wie ich es auch drehe und wende, ich finden nichts, was sich auch meiner Sicht sinnvoll einsätzen lässt.

1.) Replikation. Ein Master zum schreiben, viele Slaves zum lesen. -> Geht nicht, da wir sonnst die Applikationen darauf anpassen müssten und das nicht bei allen möglich ist, bzw. die Neuentwicklung dafür zu aufwändig erscheint.

2.) Cluster. So wie ich das verstanden habe, werden die Datenbanken im RAM vorgehalten, um die Performance zu bekommen. -> Da wir Datenbanken haben, die größer als der Arbeitsspeicher sind, bzw, noch größere kommen werden, wird das so leider auch nicht funktionieren, denke ich. Ach ja, mir ist bewusst, das dieses Problem bei der 5.1er Version nicht mehr bestehen soll, aber die ist noch Beta.

3.) MySQL-Proxy. Ist Alpha und funktioniert leider noch nicht stabil.

Hätte jemand von Euch noch einen guten Vorschlag? Wie machen das eigentlich so richtig große Anbieter wie sourceforge oder GMX oder 1&1 usw.?

Da gibt’s doch bestimmt was von Ratiopharm.

Viele Dank schon mal an diejenigen, die bis hier gelesen haben ohne einzuschlafen.

Cheers,

Jochen

snowball wrote: 2.) Cluster. So wie ich das verstanden habe, werden die Datenbanken im RAM vorgehalten, um die Performance zu bekommen. -> Da wir Datenbanken haben, die größer als der Arbeitsspeicher sind, bzw, noch größere kommen werden, wird das so leider auch nicht funktionieren, denke ich. Ach ja, mir ist bewusst, das dieses Problem bei der 5.1er Version nicht mehr bestehen soll, aber die ist noch Beta.

die daten werden auf jedem knoten zum teil im ram gehalten. jeder knoten erhält einen teil der gesamtmenge. mit einer ausreichenden anzahl von knoten müsste das schon gehen.

wenn ihr die applikation nicht ändern wollt, ist das wohl die einzigste möglichkeit. ansonsten gibts neben replikation auch noch die möglichkeit, teile der daten auf mehrere server zu verteilen. aber auch hier sind änderungen in den applikationen notwendig.

snowball wrote:1.) Replikation. Ein Master zum schreiben, viele Slaves zum lesen. -> Geht nicht, da wir sonnst die Applikationen darauf anpassen müssten und das nicht bei allen möglich ist, bzw. die Neuentwicklung dafür zu aufwändig erscheint.

Für ein Scaleout ist das die übliche Lösung. Eine Trennung zwischen Reads und Writes in der Anwendung mit zwei Datenbank-Connections ist kaum zu umgehen. Bei Verwendung einer sinnvollen Datenbankabstraktion ist das auch trivial zu machen, siehe den passenden Code im Proxy.

Außerdem will man einen Heartbeat-Mechanismus haben, mit dem an Synchronisationspunkte setzen kann (Schreiben von Transaktion, Folgeschreiben von ip, pid und sequenznummer über Schreibhandle, bei Lesezugriffen für die eigene (ip, pid) auf die Sequenznummer im Lesehandle warten oder über das Schreibhandle lesen).

2.) Cluster. So wie ich das verstanden habe, werden die Datenbanken im RAM vorgehalten, um die Performance zu bekommen. -> Da wir Datenbanken haben, die größer als der Arbeitsspeicher sind, bzw, noch größere kommen werden, wird das so leider auch nicht funktionieren, denke ich.

Es funktioniert sowieso nicht so, wie Du denkst. Erstens mal ist Cluster eine verteilte Datenbank, d.h. es skaliert sich komplett nicht so wie man erwartet. Joins sind sehr viel teurer als bei Vanilla, und es gelten jede Menge statische Partitionierungsregeln.

Zweitens macht Cluster 2pc. Das bedeutet, es macht Waits von 2x(max(rtt)) bei allen Schreibzugriffen, um einen konsistenten State über alle Nodes zu gewährleisten. Will man so nicht unbedingt und immer bei allen Transaktionen haben, sondern lieber auf Anwendungsebene selber kontrollieren können.

mir ist bewusst, das dieses Problem bei der 5.1er Version nicht mehr bestehen soll, aber die ist noch Beta.

Auch 5.1 hält immer noch alle Indices im RAM, nur die Daten nicht.

Hätte jemand von Euch noch einen guten Vorschlag? Wie machen das eigentlich so richtig große Anbieter wie sourceforge oder GMX oder 1&1 usw.?

Die machen sich redundante Master mit DRBD oder SAN, und dann einen Haufen Slaves dahinter, dann passen sie die Anwendung an, mit dem o.a. Heartbeat in einer Tabelle.

Außerdem partitionieren (oder sharden) sie die Load zwischen mehr als einem Master, wenn sie write-heavy sind.

Nur mal so meinen persönlichen Erfahrungssenf der letten Wochen hier mal dazu gebe.

Hatte auch das Problem mit einer erhöhten Auslastung unserer Server und habe mit Cluster und parallel dazu mit Replikation getestet.

Replikation hat bei uns gewonnen. ;)
Letztendlich habe ich mir die Mühe gemacht die Scripte per Ultra-Edit zu suchen, die Schreibzugriffe machen und habe dann getrennt - READ an WRITE den verschiedenen Servern zugewiesen.

Was mich wirklich verblüfft hat ist die Geschwindigkeit in der die Daten auf den Slaves zur Verfügung stehen.

Falls ein Server zum WRITE nicht ausreichen sollte haben wir alles so offen gelassen, das wir bei Bedarf eine Ringkette machen können.

Auch sowas ist in der Doku zu MySQL zu finden, nur sollte man denn einiges beachten, was z.B. auto_increment angeht.

Wobei wir wohl nun erstmal wieder sehr viel Zeit haben bis wir wieder was erweitern müssen, denn wir haben einen Master und zwei Slaves installiert und die langweilen sich jetzt.

Lieben Gruss aus Finnland

Andy alias wichtel