MySQL Cluster

MySQL Cluster ist eine Speicher-Engine des freien Datenbanksystems MySQL in der aktuell verfügbaren Version 7.2. Sie ermöglicht die Installation der Datenbank auf einem Computercluster, der 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,9999 %. Das bedeutet eine jährliche Ausfallzeit von weniger als sechs Minuten.

Die NDB-Speicher-Engine (Network-Database-Speicher-Engine) ist eine unabhängige Komponente, die persistente Speicherung von Daten ermöglicht und für die Koordinierung aller Zugriffe auf Datenknoten in einem MySQL-Cluster zuständig ist. Anwendungen können direkt auf die NDB-Speicher-Engine über verschiedene NoSQL-Schnittstellen oder über einen MySQL-Knoten per SQL zugreifen.

NDB Cluster wurde 2003 von MySQL AB mit Erwerb des Unternehmens Alzato (einem Ericsson-Ableger) übernommen. 2008 wurde MySQL AB von Sun Microsystems übernommen. 2010 wiederum wurde Sun von Oracle übernommen.

Einsatzgebiete

MySQL Cluster wird oft als DBMS (Database Management System) im Web-Umfeld eingesetzt, wo es darauf ankommt, viele Lesezugriffe in Kombination mit einer hohen Ausfallsicherheit zu erreichen. Für solche Anforderungen hat MySQL Cluster bei Tests schon bessere Zugriffszeiten bewiesen als Oracle, DB2 und MS SQL.

Architektur

Im MySQL Cluster werden drei Arten von Knoten unterschieden:

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, dass die Datenknoten insgesamt soviel Hauptspeicher haben mussten, 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: Genau ein Ndb-Knoten im Cluster ist der Master. Diese Rolle wird beim Start vom Arbitrator zugeteilt. Der Master hat die primäre Information über den Zustand des Clusters. Ohne Master ist der Cluster arbeitsunfähig. Bei Ausfall kann ein anderer Knoten diese Rolle übernehmen – allerdings nur mit Zustimmung des Arbitrators oder der absoluten Mehrheit der Ndb-Knoten. Falls Teile des Clusters ihre Verbindung verlieren, aber noch arbeitsfähig sind (split brain scenario), entscheidet der Arbitrator (Schiedsrichter), wer Master sein soll. Per Default ist der Manager der Arbitrator; es ist aber möglich, eine Hierarchie zu konfigurieren; dabei wird oft eine ungerade Zahl gewählt, um die Mehrheitsfähigkeit zu erhalten. Als Arbitrator können Management- oder SQL-Knoten dienen.

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. Wenn der Managementknoten zusätzlich Arbitrator (Default) ist, muss er auch verfügbar sein, wenn der Master ausfällt. 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 persistenter Speicherung, mit und ohne den Einsatz von gespeicherten Prozeduren, mit synchroner oder asynchroner Replikation usw.

Der grobe Ablauf einer Benutzeranfrage ist wie folgt:

1. Eine Anfrage wird an einen SQL-Knoten gestellt.
2. Der SQL-Knoten leitet die Anfragen an die Datenknoten weiter.
3. Ein Datenknoten verarbeitet die Anfrage und sendet das Ergebnis an den SQL-Knoten zurück.
4. Der SQL-Knoten übergibt das Ergebnis an das anfragende Objekt.

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 zwei 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.

Sicherheit: Der Datenverkehr innerhalb des Clusters ist nicht kryptographisch abgesichert. Es ist Verantwortung des Betreibers, den Cluster abzuschirmen, z. B. durch Firewallregeln oder ein eigenes Tunnelnetz.

Plattformen

MySQL unterstützt Windows, Unix/Linux. Eine Mac Version steht für die Entwicklung zur Verfügung.