Facebook
Twitter
Google+
Kommentare
6
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

IPC Spring 09 Berlin – MySQL Cluster – Sinoli Minocha

Cluster sind in MySQL seit der Version 5.0 möglich und werden in einer Shared-Nothing-Architektur betrieben. Das bedeutet, dass jeder Knoten mit seiner eigenen Hardware ausgestattet und kein bestimmter Knoten notwendig ist, um eine Verbindung zur Datenbank herzustellen, denn jeder Knoten verfügt über eine Kopie des Datenbankmanagementsystems und somit ist es möglich Aufgaben an andere, weniger ausgelastete Knoten zu übergeben.

Knoten

Ein Cluster besteht aus Management-, Daten- und SQL Knoten. Der Managementknoten handhabt alle anderen Knoten innerhalb des MySQL Cluster und stellt Funktionalitäten wie dem Starten oder Stoppen von Knoten oder dem Mechanismus zur Datensicherung zur Verfügung. Die Datenknoten speichern, wie der Name schon sagt die Daten und es gibt immer so viele Datenknoten wie Kopien vorhanden sind. Ein SQL Knoten ist in einer herkömmlichen Single Server Architektur der MySQL Server. Das ist in einer Cluster Architektur auch der Fall, jedoch benutzt der MySQL Server zum Verarbeiten von SQL Anfragen die NDB Cluster Storage Engine.

NDB Storage Engine

Die Storage Engine ist ein Teil des MySQL Servers, die einen Aufruf über die NDB API auf die Datenknoten absetzt, nachdem eine SQL Anfrage vom Client gesendet wurde. Die Storage Engine verfügt über zwei Speichermethoden, in-memory und disk-based. Disk-based Storage ist seit der Version 5.1 möglich.

Aufruf

Wenn also in einer Cluster Architektur ein Client eine Anfrage sendet, so landet diese bei einem SQL Knoten, dieser wiederum startet einen NDB API Call an einen der Datenknoten, welcher danach die Antwort an einen SQL Knoten sendet und dieser die Antwort an den Client weiterleitet.

bild-13

Anders als bei einer Single Server Architektur wo der Client eine Anfrage an den MySQL Server sendet und direkt von der Datenbank die Antwort erhält.

bild-14

Partitionen & Cluster Replikationen

MySQL Cluster müssen hochverfügbar und skalierbar sein. Das wird durch Partitionen und Cluster Replikationen gewährleistet. Jeder Knoten besteht aus mindestens einer horizontalen und/oder vertikalen Partition und daher gibt es mindestens immer so viele Partitionen wie beteiligte Knoten innerhalb eines Clusters. Haben wir also in unserer Cluster Umgebung zwei Datenknoten, die über zwei Partitionen verfügen, so wird in einem Datenknoten die Partition 1 als primäre und im anderen als sekundäre Replikation geführt und umgekehrt die Partition 2 gegengleich.

bild-15

Knotengruppen

Es ist in einem MySQL Cluster möglich Knotengruppen einzurichten. Man benötigt Knotengruppen, um dem Problem des Split Brain entgegen wirken zu können.

Split Brain bedeutet, dass die Verbindungen zwischen den einzelnen Knoten unterbrochen wurden aber noch mindestens zwei Teile des Clusters funktionieren, jedoch nichts voneinander wissen, da sie sich per Heartbeat nicht mehr erreichen und jeder die volle Verantwortung gegenüber dem Cluster übernimmt. Es treten somit schnell Probleme bei Schreibvorgängen auf, da die geschriebenen Daten bei einem Lesezugriff auf den anderen Knoten nicht mehr gelesen werden können, da sich die Daten auf dem anderen Knoten befinden und umgekehrt. Die Konsistenz der Daten ist somit nicht mehr gegeben und eine Wiederherstellung der Daten fast nicht mehr möglich.

Richtet man nun Knotengruppen ein, ist es möglich, dass im Falle eines unerreichbaren Knoten der Knoten automatisch herunter fährt, da erkannt wird, dass er ein alleiniger Knoten in einer Knotengruppe ist. Diesen Automatismus regelt der Arbitrator Prozess. Werden in einer Single Knotengruppe weniger als 50 Prozent der Datenknoten erkannt, wird der Knoten herunter gefahren. Sind es hingegen exakt 50 Prozent, so wird nach der Sichtbarkeit der Arbitrator Prozesses entschieden. Bei Multiple Knotengruppen prüft der Arbitrator Prozess, ob in jeder Knotengruppe mindestens ein Knoten erreichbar ist und ob der Arbitrator Prozess der Gruppe sichtbar ist.

Transaktionen

Phase 1 – Commit-Request

Wird eine Anfrage an die Datenbank gesendet, so fungiert immer ein Knoten als Transaktionskoordinator, welcher eine Commit Nachricht an den nächstgelegenen Knoten sendet und dieser wieder an den nächsten usw. Nachdem alle Knoten von einem benachbarten eine Commit Message erhalten haben, senden diese jeweils an den nebenliegenden Knoten eine Response Message bis zum letzten, dem Transaktionskoordinator zurück.

Phase 2 – Successful Commit

Nachdem Phase 1 fehlerfrei durchgeführt wurde müssen alle Knoten die Transaktion erfolgreich ausführen, um danach danach die Transaktion endgültig commiten zu können. Das bedeutet, dass jeder Knoten an den benachbarten zuerst eine Nachricht über das erfolgreiche Ausführen der Transaktion sendet, um danach eine Nachricht über das erfolgreiche Commit senden zu können.

Fällt in einem dieser Vorgänge der Transaktionskoordinator aus, so ist laut der Vortragenden die gesamte Transaktion verloren gegangen und nicht wieder auffindbar. Ich musste bei der Vortragenden zweimal nachfragen, ob ich dies richtig verstanden habe, da ich das schlicht und ergreifend einfach nicht glauben konnte, da es sich hierbei, sollte dem wirklich so sein, um einen groben konzeptionellen Fehler der Datenbank handelt. Um diesem Fehler jedoch entgegenzuwirken, könne man laut der Vortragenden ein eigenes UNIX Skript schreiben, das nach Ausfall eines Transaktionskoordinators die Transaktion an einen anderen Knoten übergibt, sprich ein anderer Knoten die Funktion des Transaktionskoordinators übernimmt. Meinem Verständnis nach kann das logisch im Fall von High-Concurrency nicht funktionieren, denn wenn in Phase 2 manche Knoten ein Commit abgesetzt haben, wären zu diesem Zeitpunkt auf diesen Knoten die Daten schon sichtbar. Da hilft ein Rollback auch nicht mehr, da die Daten nicht sichtbar sein dürfen, wenn der Transaktionskoordinator abschmiert, unabhängig dessen in welchem Stadium sich die Transaktion befindet. Auch dann nicht, wenn es sich um Millisekunden handelt bis das Rollback eingeleitet wurde. Die Datenbank könnte schon innerhalb dieser Millisekunden inkonsistent werden, wenn in dieser Zeitspanne z.B. Schreibzugriffe durchgeführt wurden. Gibt es in MySQL kein „stable“ Storage, damit Knoten ihre eigenen Daten persistieren und damit ihr Ausfallen selbst auffangen können? Gefunden habe ich diesbezüglich nämlich nichts. Sollten die Informationen tatsächlich korrekt sein, so zeigt mir dieser Umstand u.a. wieder eindeutig, weshalb ich weiterhin auf PostgreSQL setzen werde.

Über den Autor

Ewi

Als ich die Oberstufe mit 17 abgebrochen habe und als Sekretärin, ähm Office Managerin, zu arbeiten begann, stellte ich sehr schnell fest, dass ich keine Aktenhüllen für irgendwelche hochnäsigen Professoren schlichten möchte und stellte mir die Frage "Was willst du eigentlich mal machen?". Ohne mir lange überlegt zu haben, ob mich die Materie überhaupt interessieren wird, eher vom Gedanken geleitet „irgendeine“ eine Schule abzuschließen und vom damaligen EDV-Boom beeinflusst, habe ich mich für eine der renommiertesten EDV Schulen Österreichs, der HTL Spengergasse Abendschule (ja, tagsüber arbeiten und abends Schule) entschieden, die ich 1999 begonnen und mittlerweile seit einigen Jahren abgeschlossen habe. Ich programmiere also seit Ende 1999 und bin mittlerweile selbstständig (knitwork).
Kommentare

6 Comments

  1. Danke für den Artikel!
    Als ersten Einblick eine gute Zusammenfassung, auch wenn die wenigsten von uns es in der Praxis brauchen werden 😉

    Reply
  2. @Evelyne. super artikel danke schön.

    Hast du einen guten link für PostgreSQL und LoadBalencing/Clustering ?

    Werde wohl in den nächsten monaten in die Verlegenheit kommen neben den FrontendRechnern (Apache/PHP) auch den mysql server zu clustern bzw redundant zu machen. Momentan ist der DB Server mein singlepoint of failure, obwohl der über heartbeat und drbd einen hot-standby hat, aber der hat einfach nicht die leistung.

    Reply
  3. @michael: ich habe mir überlegt die installation und konfiguration einzubinden, aber dann dachte ich mir, dass dies wahrscheinlich die wenigsten interessieren wird. aber falls es doch interesse geben sollte, dann mach ich vielleicht noch einen artikel.

    @ludwigr: bei der hand habe ich keinen link, aber ich frage abends den guru of postgresql hans schönig mal ob er da was empfehlen kann 🙂

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen