MySQL Cluster
MySQL Cluster ist eine Funktion des Open-Source Datenbanksystems MySQL ab der Version 5.0. Sie ermöglicht die Installation der Datenbank auf einem Computercluster, das in einer Shared Nothing Architecture aufgebaut ist. Das bedeutet, dass jeder Rechner-Knoten seine eigenen Festplatten und Arbeitsspeicher hat. Wenn die einzelnen Rechner-Knoten mit einem genügend großen Arbeitsspeicher ausgestattet sind, dann können alle Daten im Arbeitsspeicher gehalten werden (bis Version 5.0 war das zwingend, ab Version 5.1 gibt es auch plattenresidente Tabellen).
Nach eigenen Angaben bietet die Cluster-Technologie von MySQL eine Verfügbarkeit von 99,999 %. [1] [2] Das bedeutet eine jährliche Ausfallzeit von weniger als 6 Minuten.
Die NDB (Network Database)-Speicher-Engine ist eine unabhängige Komponente, die persistente Speicherung von Daten ermöglicht und für die Koordination aller Zugriffe auf Datenknoten in einem MySQL Cluster zuständig ist. Anwendungen können direkt auf die NDB-Speicher-Engine über die NDB-API oder über einen MySQL-Knoten zugreifen.
NDB Cluster wurde 2003 von MySQL AB mit Erwerb der Firma Alzato (einem Ericsson-Ableger) übernommen. 2008 wurde MySQL AB von Sun Microsystems übernommen.
Einsatzgebiete
MySQL Cluster wird oft als DBMS im Web-Umfeld eingesetzt, wo es darauf ankommt, dass viele Lesezugriffe schnell ausgeführt werden und dass eine hohe Ausfallsicherheit gewährleistet wird.
Bei mehreren Tests hat MySQL Cluster für solche Anforderungen schon bessere Zugriffszeiten bewiesen, als Oracle und DB2.
Architektur
Im MySQL Cluster werden drei Arten von Knoten unterschieden:[3]
- Datenknoten (Ndbd)
- Datenknoten speichern alle zu MySQL Cluster gehörenden Daten. Die Daten werden im Normalfall zwischen den Datenknoten des Clusters repliziert, um sicherzustellen, dass diese bei Ausfall eines oder mehrerer Knoten ununterbrochen verfügbar sind. Datenknoten verwalten außerdem Datenbanktransaktionen. Bei mehr als zwei Datenknoten werden die Knoten in sogenannte Nodegroups (Knotengruppen) unterteilt. Eine Nodegroup muss aus mindestens zwei Datenknoten bestehen. Innerhalb einer Nodegroup werden die Daten repliziert. Beim Einfügen eines neuen Satzes bildet das System einen Hash aus dem Primärschlüssel (die NDB-Engine erzeugt automatisch einen Primärschlüssel, falls keiner definiert ist). Der Wert des Hashs bestimmt, in welcher Nodegroup der Satz abgelegt wird. Dadurch wird eine statistische Gleichverteilung erreicht. Diese Methode der Datenverteilung wird auch als Partitionierung bezeichnet.
- Datenspeicherung: Bis Version-5 wurden alle Daten im Hauptspeicher gehalten und periodisch auf die Platte geschrieben. Grob gesprochen hieß dies, daß die Datenknoten insgesamt soviel Hauptspeicher haben mußten, wie die Größe der Datenbank betrug; das mitgelieferte Skript ndb_size.pl erlaubte es, den voraussichtlichen Speicherbedarf für eine existierende Datenbank abzuschätzen. Ab Version-6 gibt es den Tabellentyp 'storage disk', bei dem Indexfelder im Hauptspeicher und die restlichen Felder auf der Platte gespeichert werden.
- Rollen: Ein Ndb-Knoten im Cluster ist der Master. Diese Rolle wird beim Start vom Manager zugeteilt. Der Master hat die primäre Information über den Zustand des Clusters. Falls Teile des Clusters ihre Verbindung verlieren, aber noch arbeitsfähig sind, entscheidet der Arbitrator (Schiedsrichter), wer Master sein soll. Per Default ist der Manager der Arbitrator; es aber möglich, eine Hierarchie zu konfigurieren.
- Managementknoten
- Ein Managementknoten ist für die Systemkonfiguration, die Knotenverwaltung und die Aufzeichnung der Aktivitäten im Cluster zuständig. Es können ein oder mehrere Managementknoten aus Verfügbarkeitsgründen gleichzeitig eingesetzt werden. Im laufenden Betrieb wird dieser Knoten nur benötigt, wenn sich ein ausgefallener anderer Knoten wieder am Cluster anmelden will. Da Ausfälle nicht vorhersehbar sind, sollte dieser Knoten daher immer laufen.
- SQL-Knoten
- Ein SQL-Knoten entspricht einem MySQL Datenbanksystem, das mit Datenknoten kommunizieren kann. Die SQL-Knoten können einzeln oder über Lastverteilung unter einer Sammel-IP angesprochen werden.
Das MySQL Datenbanksystem erlaubt die Verwendung von Datenbank-Managementsystemen mit verschiedenen Konzepten: mit und ohne Durchführung von Transaktionen, mit und ohne persistente Speicherung, mit und ohne den Einsatz von gespeicherten Prozeduren, mit synchroner oder asynchroner Replikation usw.
Der grobe Ablauf einer Benutzeranfrage ist wie folgt:
- Eine Anfrage wird an einen SQL-Knoten gestellt.
- Der SQL-Knoten leitet die Anfragen an die Datenknoten weiter.
- Ein Datenknoten verarbeitet die Anfrage und sendet das Ergebnis an den SQL-Knoten zurück.
- Der SQL-Knoten übergibt das Ergebnis an Benutzer.
Auf jedem der Knoten des MySQL Clusters ist mindestens ein Prozess gestartet. Bei SQL-Knoten heißt der zuständige Prozess mysqld, bei Datenknoten ndbd und bei Verwaltungsknoten ndb-mgmd. Auf Rechnerknoten mit mehreren Prozessoren können mehrere MySQL Cluster-Prozesse gleichzeitig laufen. Beispielsweise auf einem Datenknoten mit 2 CPUs können zwei ndbd-Prozesse parallel ausgeführt werden. Es ist ebenfalls möglich, Prozesse verschiedener MySQL Cluster-Knotentypen auf einem Rechnerknoten mit mehreren CPUs einzusetzen. Zum Beispiel kann auf einem Rechner ein Prozess des SQL-Knotens (mysqld) und ein Prozess des Datenknotens (ndbd) gestartet sein.
Ports (Voreinstellungen):
- Sql-Knoten 3306
- Manager 1186
- Ndbd-Knoten verwenden keine festen Ports. Die Ports werden vom Manager beim Start des Clusters dynamisch vergeben und an die Server im Cluster propagiert.
Ankündigungen über Weiterentwicklungen
Bei MySQL Cluster der Version 5.0 sind Schreibzugriffe mit einem großen Overhead verbunden.
MySQL AB hat ein Cluster-Konzept angekündigt, bei dem alle Knoten auf die selben Festplatten zugreifen. (Shared Storage) Die Schreib-Zugriffe sollten dadurch schneller werden.
Literatur
- Larissa Janssen: Hochleistungs-Datenbanksysteme: Theorie und Praxis. Books on Demand GmbH, 2008, ISBN 9783833493263
Quellen
- ↑ MySQL AB :: MySQL Cluster
- ↑ Quelle: Computerwoche 45/2006 Seite 24
- ↑ Larissa Janssen: Hochleistungs-Datenbanksysteme: Theorie und Praxis. 2008, S. 188–189.