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.

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.

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.

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.