MySQL: Trennung Master - Slave sinnvoll

theomega
Userprojekt
Userprojekt
Posts: 704
Joined: 2003-01-27 14:36

MySQL: Trennung Master - Slave sinnvoll

Post by theomega »

Hallo Leute,
nehmen wir mal an ich habe eine Webseite die prinzipbedingt sehr SQL-Lastig ist. Nehmen wir weiter an ein einzelner Server (Dual Core, 2GB Ram) reicht stellenweise nichtmehr aus um die Datenbank (Webanwendung läuft auf einem anderen Server) performant zu befragen und upzudaten.

Meine Idee wäre jetzt folgende: Ich besorge einen zweiten Server von ähnliche Leistung. Diesen richte ich als Slave ein, so dass die beiden Server immer synchrone Daten in ihrere Datenbank halten. In meiner Webanwendung öffne ich dann zwei MySQL-Verbindungen, eine zum Schreiben an den master und eine zum Lesen an den Slave. Je nachdem ob ich ein Select ausführe verwende ich die eine oder andere Verbindung.

Ist dieses Vorgehen sinvoll? Ich denke es macht einen Unterschied ob es sich um eine PHP-Anwendung handelt die dann vergleichsweise viel Zeit damit verbringt eine zweite Verbindung aufzubauen oder ob es sich um eine Java-Anwendung mit einem Connectionpool handelt die einfach nur die Verbindungen zugreifen muss.
Was ist mit der Syncrhonität? Wieviele Millisekunden hinken die beiden normalerweise hinterher? "SHOW SLAVE STATUS" gibt ja nur Sekunden aus. Sekunden sind ja sehr viel Zeit, wen die Besucher Daten verändern und sie sehen die auswirkungen nicht sofort gibt es Ärger bzw sie wundern sich.

Wie sieht es aus, unter welchen Bedingungen ist das sinvoll? Funktioniert das eigentlich zuverlässig auch mit InnoDB's und Foreign Keys?

Gruß und Danke schonmal
TO
Top

lord_pinhead
RSAC
Posts: 830
Joined: 2004-04-26 15:57

Re: MySQL: Trennung Master - Slave sinnvoll

Post by lord_pinhead »

Ein Mysql Cluster bietet sich da eher an inkl. Loadbalancer (am einfachsten Round Robin via DNS). Allerdings musst du die Datenbank Engine glaub ich ändern bei den Datenbanken, sonst funzt das ja nicht. So teilst du die Leistung auf 2 Server auf ohne umständlich an deinen Anwendungen rumfummeln zu müssen.
Top

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: MySQL: Trennung Master - Slave sinnvoll

Post by daemotron »

Wenn Du eine etwa gleich große Anzahl an Lese- und Schreibvorgängen hast und die Trennung in der Applikation ohne viel Aufwand hinbekommst, ist die Idee gar nicht so verkehrt. Um einen richtigen Cluster hinzubekommen (Master-Master) müsstest Du Master-Slave über Kreuz aufsetzen, was nicht gerade elegant ist (da sind andere DBMSe schon weiter...)
Top

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: MySQL: Trennung Master - Slave sinnvoll

Post by isotopp »

theomega wrote:Je nachdem ob ich ein Select ausführe verwende ich die eine oder andere Verbindung.
Das ist die übliche Methode. Sie ist sehr sinnvoll und wird so von allen großen Sites eingesetzt. Der MySQL Threadcache fängt den größten Teil des Connection-Overheads ab.
Was ist mit der Syncrhonität? Wieviele Millisekunden hinken die beiden normalerweise hinterher?
Das ist sehr variabel. Was Du brauchst ist eine Heartbeat-Tabelle, in der jeder Client einen Namen und eine Sequenznummer einträgt. Ein Clientname wäre zum Beispiel die Kombination (clientip, portnummer) oder irgendwas anderes, das für jeden Client eindeutig ist. Eine Sequenznummer wäre zum Beispiel der aktuelle Timestamp oder ein Zähler. Der Timestamp hat den Nachteil, daß er nicht beliebig schnell wachsen kann.

Ein Client kann nun auf den Master schreiben und macht am Ende ein Push auf den Heartbeat (schreibt eine neue Sequenznummer unter seinem Namen). Da das Binlog eine Serialisierung der Events des Masters ist und vom Slave in-order abgearbeitet werden muß, kann der Client dann vom Slave lesen und prüfen, ob der Heartbeat schon da ist. Wenn er es ist, sind auch alle Events von VOR dem Heartbeat abgearbeitet. Ansonsten nimmt der Client halt seine Connection zum Master und liest von da. Das bremst den Master runter und gibt den Clients Gelegenheit zum Aufholen.
Wie sieht es aus, unter welchen Bedingungen ist das sinvoll? Funktioniert das eigentlich zuverlässig auch mit InnoDB's und Foreign Keys?
Ja.
Top

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: MySQL: Trennung Master - Slave sinnvoll

Post by isotopp »

Lord_Pinhead wrote:Ein Mysql Cluster bietet sich da eher an inkl. Loadbalancer (am einfachsten Round Robin via DNS). Allerdings musst du die Datenbank Engine glaub ich ändern bei den Datenbanken, sonst funzt das ja nicht. So teilst du die Leistung auf 2 Server auf ohne umständlich an deinen Anwendungen rumfummeln zu müssen.
MySQL Cluster clustert nicht so wie man denkt. Cluster funktioniert, indem Tabellen auf einer Art RAID-10 im RAM der Nodes verteilt werden. Queries gegen den Cluster laufen, wenn sie Joins enthalten, mit einem Haufen Netzwerkkommunikation ab.

Das bedeutet, Dinge die vorher intern im Ram eines Rechners Nanosekunden gedauert haben, dauern nun über das Netzwerk Millisekunden - also von 10E-9 nach 10E-3, im schlimmsten Fall. Das ist eine Million mal LANGSAMER.

Das muß nicht so sein, oder sich global mit dem vollen Faktor auswirken. Aber es ist nicht damit getan, den Tabletype von InnoDB auf NDBCLUSTER umzustellen um nach Cluster zu migrieren.
Top

kase
RSAC
Posts: 1041
Joined: 2002-10-14 22:56

Re: MySQL: Trennung Master - Slave sinnvoll

Post by kase »

isotopp wrote: Das bedeutet, Dinge die vorher intern im Ram eines Rechners Nanosekunden gedauert haben, dauern nun über das Netzwerk Millisekunden - also von 10E-9 nach 10E-3, im schlimmsten Fall. Das ist eine Million mal LANGSAMER.
Zu dieser Aussage habe ich mal eine Frage. Es ist zwar richtig, dass sich der Zugriff aufs Speichermedium im schlimmsten Fall auf 10^6 verlangsamt, aber inwiefern belastet das denn die CPU mehr? Man fängt ja meistens mit Clustering an, wenn die CPU am Ende ist. Wenn aber die CPU auf Daten wartet, dann sollte das ja keine CPU Time kosten (mal abgesehn davon, dass Netzwerk-Reads sicher etwas mehr CPU kosten als Ram-Reads).

Der Overhead bei einer Master-Slave mit Heartbeat kostet ja auch etwas Performance, immerhin hat man nach jeder Write-Transaction einen weiteren Write-Heartbeat und mindestens einen weiteren Read-Heartbeat. (Im schlimmsten Fall verdoppeln sich also die Querys, wenn man nur ein einziges Write-Query mit nachfolgendem Read-Query absetzt)
Top