Was ist „NDB“?

Dies steht für „Network DataBase“.

Was macht es für einen Unterschied, ob ich Cluster oder Replikation nutze?

Bei einer Replikation aktualisiert ein MySQL-Master-Server einen oder mehrere Slaves. Transaktionen werden nacheinander committet und eine langsame Transaktion kann dazu führen, dass der Slave hinter dem Master zurückbleibt. Das bedeutet: Wenn der Master abstürzt, kann es dazu kommen, dass der Slave die letzten paar Transaktionen nicht mitbekommen hat. Wird eine transaktionssichere Engine wie InnoDB benutzt, so wird eine Transaktion auf dem Slave entweder abgeschlossen oder gar nicht angewendet. Bei der Replikation ist jedoch nicht garantiert, dass alle Daten auf dem Master und dem Slave zu jedem Zeitpunkt konsistent sind. In MySQL Cluster hingegen sind immer alle Datenknoten synchron und eine Transaktion, die von irgendeinem Datenknoten committet wird, wird für alle Datenknoten committet. Wenn ein Datenknoten abstürzt, bleiben alle übrigen Datenknoten in einem konsistenten Zustand zurück.

Kurz: Während die MySQL-Replikation standardmäßig asynchron ist, ist MySQL Cluster synchron.

Wir planen, eine (asynchrone) Replikation für Cluster in MySQL 5.1 einzuführen. Dazu gehört auch die Fähigkeit, sowohl zwischen zwei Clustern als auch zwischen einem geclusterten und einem nichtgeclusterten MySQL Server zu replizieren.

Benötige ich ein spezielles Netzwerk für Cluster? (Wie kommunizieren Computer in einem Cluster?)

MySQL Cluster ist für die Benutzung in einer Umgebung mit großer Bandbreite und über TCP/IP verbundene Computer ausgelegt. Die Leistung des Clusters hängt direkt von der Schnelligkeit der Verbindungen zwischen den Cluster-Computern ab. Die Mindestanforderung für die Konnektivität in einem Cluster ist ein typisches 100-Megabit-Ethernet-Netzwerk oder etwas Entsprechendes. Wir empfehlen Ihnen, nach Möglichkeit ein 1-Gigabit-Ethernet einzusetzen.

Das schnellere SCI-Protokoll wird ebenfalls unterstützt, benötigt jedoch eine spezielle Hardware. Weitere Informationen über SCI finden Sie unter Abschnitt 16.7, „Verwendung von Hochgeschwindigkeits-Interconnects mit MySQL Cluster“.

Wie viele Computer sind für einen Cluster erforderlich und warum?

Für einen benutzbaren Cluster sind mindestens drei Computer notwendig. Empfohlen werden jedoch mindestens vier: je einer für den Management- und den SQL-Knoten und zwei, die als Speicherknoten dienen. Zwei Datenknoten sind wegen der Redundanz ratsam und der Management-Knoten muss auf einem eigenen Computer laufen, um auch beim Absturz eines Datenknotens weiterhin die Arbitrator-Funktion aufrechterhalten zu können.

Was tun die verschiedenen Computer in einem Cluster?

Ein MySQL Cluster hat sowohl eine physikalische als auch eine logische Struktur, wobei die Computer die physikalischen Elemente sind. Die logischen oder funktionalen Elemente eines Clusters werden als Knoten bezeichnet und ein Computer, auf dem ein Cluster-Knoten läuft, wird Cluster-Host genannt. Im Idealfall gibt es einen Knoten pro Cluster-Host, allerdings können auf einem einzelnen Host auch mehrere Knoten laufen. Es gibt drei Knotentypen, von denen jeder im Cluster eine bestimmte Rolle spielt:

Mit welchen Betriebssystemen kann ich Cluster benutzen?

MySQL Cluster wird offiziell für Linux, Mac OS X und Solaris unterstützt. Wir arbeiten daran, Cluster auch auf anderen Plattformen zu ermöglichen (einschließlich Windows), und haben uns das Ziel gesetzt, MySQL Cluster irgendwann auf allen Plattformen zu unterstützen, auf denen auch MySQL selbst läuft.

Es könnte möglich sein, Cluster-Prozesse auch auf anderen Betriebssystemen auszuführen. Einige Anwender berichten, Cluster bereits erfolgreich auf FreeBSD betrieben zu haben. Allerdings können Cluster auf anderen als den hier erwähnten drei Betriebssystemen bestenfalls als Alpha-Software gelten. Ihre Zuverlässigkeit in einer Produktionsumgebung kann nicht garantiert werden und wird nicht von MySQL AB unterstützt.

Welche Hardwareanforderungen stellt MySQL Cluster?

Cluster müssten auf jeder Plattform laufen, für die NDB-fähige Binaries zur Verfügung stehen. Natürlich wird die Leistung mit schnelleren CPUs und größerem Arbeitsspeicher besser, und 64-Bit-CPUs sind schneller als 32-Bit-Prozessoren. Die als Datenknoten verwendeten Computer müssen genug Arbeitsspeicher haben, um den Teil der Datenbank zu speichern, der auf diesem Datenknoten liegt (weitere Informationen siehe Wie viel RAM brauche ich?). Die Knoten können über ein normales TCP/IP-Netzwerk mit Standardhardware kommunizieren. Für die SCI-Unterstützung ist spezielle Netzwerkhardware erforderlich.

Wie viel RAM brauche ich? Kann überhaupt Festplattenspeicher benutzt werden?

Zurzeit sind Cluster lediglich arbeitsspeicherresident, sodass alle Tabellendaten (einschließlich Indizes) im Arbeitsspeicher abgelegt werden. Wenn Ihre Daten 1 Gbyte Platz benötigen und Sie sie einmal im Cluster replizieren möchten, benötigen Sie dafür folglich 2 Gbyte Hauptspeicher. Hinzu kommt der Arbeitsspeicher, den das Betriebssystem und irgendwelche sonstigen Anwendungen belegen, die auf den Cluster-Computern laufen.

Die folgende Formel liefert eine grobe Schätzung des für jeden Datenknoten im Cluster benötigten Arbeitsspeicherbedarfs:

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

Um den Speicherbedarf genauer zu berechnen, müssen Sie für jede Tabelle in der Cluster-Datenbank den pro Zeile erforderlichen Speicher ermitteln (Einzelheiten siehe Abschnitt 11.5, „Speicherbedarf von Spaltentypen“) und diesen Wert mit der Zeilenzahl multiplizieren. Außerdem müssen Sie die Spaltenindizes wie folgt mit einkalkulieren:

Sehr wichtig: Bitte denken Sie daran, dass jede MySQL Cluster-Tabelle einen Primärschlüssel haben muss. Die Speicher-Engine NDB legt automatisch einen Primärschlüssel an, wenn nicht bereits einer definiert wurde, und dieser Primärschlüssel wird ohne USING HASH erzeugt.

Es gibt kein einfaches Mittel, um genau festzustellen, wann wie viel Arbeitsspeicher von Cluster-Indizes belegt wird, aber wenn 80 % des verfügbaren DataMemory oder IndexMemory voll sind, wird eine Warnung in das Cluster-Log geschrieben. Weitere Warnungen gibt es, wenn 85 %, 90 % usw. erreicht werden.

Oft erreichen uns Fragen von Anwendern, die berichten, dass der Ladeprozess beim Laden von Daten in eine Cluster-Datenbank vorzeitig mit einer Fehlermeldung wie dieser abbricht:

ERROR 1114: The table 'my_cluster_table' is full

Wenn dies geschieht, haben Sie höchstwahrscheinlich nicht genügend RAM für alle Datentabellen und Indizes einschließlich des von der Speicher-Engine NDB geforderten Primärschlüssels, der automatisch erzeugt wird, wenn er in der Tabellendefinition fehlt.

Außerdem müssen Sie berücksichtigen, dass alle Datenknoten gleich viel RAM haben sollten, da in einem Cluster kein Datenknoten mehr Speicher übrig hat als der an Speicher ärmste Datenknoten des Clusters. Mit anderen Worten: Wenn drei Computer Cluster-Datenknoten hosten und zwei davon 3 Gbyte RAM für Cluster-Daten übrig haben, während dem dritten nur 1 Gbyte verbleibt, können alle drei Datenknoten nur noch 1 Gbyte Speicher für den Cluster verwenden.

Da MySQL Cluster mit TCP/IP arbeitet: Bedeutet dies, dass ich den Cluster im Internet betreiben und einen oder mehrere Knoten remote halten kann?

Es ist mehr als zweifelhaft, dass ein Cluster unter solchen Bedingungen noch eine zuverlässige Leistung bringen könnte, da MySQL Cluster unter der Grundannahme entworfen und implementiert wurde, dass der Cluster eine Hochgeschwindigkeitsverbindung wie in einem LAN mit 100 Mbps oder einem Gigabit-Ethernet (vorzugsweise Letzterem) nutzen kann. Die Leistung mit einer langsameren Verbindung werden wir weder testen noch irgendwie gewährleisten.

Außerdem ist es außerordentlich wichtig, immer daran zu denken, dass die Kommunikation zwischen Knoten in einem MySQL Cluster nicht sicher ist. Die Datenübermittlungen werden weder verschlüsselt noch durch irgendeinen anderen Schutzmechanismus abgesichert. Die sicherste Konfiguration für einen Cluster ist ein privates Netzwerk hinter einer Firewall, ohne direkten Zugriff von außerhalb auf irgendwelche Cluster-Daten oder Management-Knoten. (Für SQL-Knoten sollten Sie dieselben Vorkehrungen treffen wie für jede andere Instanz des MySQL Servers.)

Muss ich für Cluster eine neue Programmiersprache oder Datenbank-Abfragesprache lernen?

Nein. Für die Verwaltung und Konfiguration des Clusters selbst werden zwar einige spezielle Befehle benötigt, aber für die folgenden Operationen sind nur (My)SQL-Standardabfragen und Standardbefehle erforderlich:

Wie kann ich herausfinden, was eine Fehlermeldung oder Warnung bedeutet, wenn ich Cluster benutze?

Dafür gibt es zwei Möglichkeiten:

Ist MySQL Cluster transaktionssicher? Welche Isolationsebenen werden unterstützt?

Ja. Für Tabellen, die mit der Speicher-Engine NDB angelegt wurden, werden Transaktionen unterstützt. In MySQL 5.1 kennen Cluster allerdings als einzige Ebene der Transaktionsisolation READ COMMITTED.

Welche Speicher-Engines unterstützt MySQL Cluster?

Clustering wird in MySQL nur von der Speicher-Engine NDB unterstützt. Um eine Tabelle für Cluster-Knoten tauglich zu machen, muss sie also mit ENGINE=NDB (oder dem Äquivalent ENGINE=NDBCLUSTER) angelegt werden.

(Es ist möglich, Tabellen mit anderen Speicher-Engines wie etwa MyISAM oder InnoDB auf einem MySQL Server anzulegen, der für Clustering verwendet wird, doch diese Nicht-NDB-Tabellen können nicht an dem Cluster beteiligt sein.)

Welche Versionen von MySQL unterstützen Cluster? Muss ich die Quellversionen kompilieren?

Cluster wird in allen MySQL-max-Binaries der Release-Serie 5.1 unterstützt, mit den im folgenden Absatz genannten Ausnahmen. Ob Ihr Server NDB unterstützt, können Sie mit SHOW VARIABLES LIKE 'have_%' oder SHOW ENGINES herausfinden. (Mehr Informationen finden Sie unter Abschnitt 5.3, „mysqld-max, ein erweiterter mysqld-Server“.)

Linux-Benutzer müssen wissen, dass NDB nicht in den Standard-RPMs für MySQL Server enthalten ist. Es gibt auch separate RPM-Packages für die Speicher-Engine NDB und die zugehörigen Management- und anderen Tools. Downloadsites für diese RPMs sind im Abschnitt für NDB RPM-Downloads der MySQL 5.1-Downloadseite angegeben. (Früher musste man die -max-Binaries verwenden, die als .tar.gz-Archive geliefert wurden. Auch dies ist immer noch möglich, aber nicht mehr nötig; heute können Sie den RPM-Manager Ihrer Linux-Distribution nutzen, wenn Sie es möchten.) NDB-Unterstützung bekommen Sie auch, indem Sie die -max-Binaries von der Quelle kompilieren, doch bloß um MySQL Cluster-Unterstützung zu bekommen, ist das nicht erforderlich. Um die neueste Binary, RPM oder Quelldistribution der MySQL 5.1-Serie herunterzuladen, gehen Sie zu http://dev.mysql.com/downloads/mysql/5.1.html.

Würde ich im Katastrophenfall, etwa wenn die ganze Stadt einen Stromausfall hat und zusätzlich meine unterbrechungsfreie Stromversorgung versagt, alle meine Daten verlieren?

Da alle committeten Transaktionen protokolliert werden, ist es zwar möglich, dass einige Daten in einem solchen Katastrophenfall verloren gehen könnten, aber der Verlust dürfte sich in Grenzen halten. Der Datenverlust kann zusätzlich begrenzt werden, indem Sie die Anzahl der Operationen pro Transaktion reduzieren. (Es ist immer schlecht, zu viele Operationen in einer einzigen Transaktion auszuführen.)

Kann man in einem Cluster FULLTEXT-Indizes benutzen?

FULLTEXT-Indizes werden zurzeit weder von NDB noch von irgendeiner anderen Speicher-Engine außer MyISAM unterstützt. Wir arbeiten daran, diese Fähigkeit in einem künftigen Release hinzuzufügen.

Kann ich mehrere Knoten auf einem einzigen Computer laufen lassen?

Das ist möglich, aber nicht ratsam. Einer der Hauptgründe für ein Cluster ist die Redundanz. Um jedoch alle Vorteile der Redundanz zu gewährleisten, sollte jeder Knoten auf einem eigenen Computer laufen. Wenn Sie mehrere Knoten auf einem einzigen Computer betreiben und dieser abstürzt, verlieren Sie alle diese Knoten. Wenn man bedenkt, dass MySQL Cluster auf Standardhardware mit einem billigen (oder sogar kostenlosen) Betriebssystem laufen kann, dann lohnt es sich wohl, ein oder zwei zusätzliche Rechner anzuschaffen, um missionskritische Daten zu sichern. Überdies sind die Anforderungen an einen Cluster-Host, auf dem ein Management-Knoten läuft, minimal: Diese Aufgabe kann schon ein 200-MHz-Pentium bewältigen, wenn er genügend RAM für das Betriebssystem plus einen geringen Overhead für die ndb_mgmd- und ndb_mgm-Prozesse hat.

Kann ich einem Cluster Knoten hinzufügen, ohne ihn neu starten zu müssen?

Zurzeit noch nicht. Allerdings ist ein Neustart alles, was Sie tun müssen, um einem Cluster neue MGM- oder SQL-Knoten hinzuzufügen. Wenn Sie Datenknoten hinzufügen, liegen die Dinge etwas komplizierter; dafür sind folgende Schritte nötig:

In einer künftigen Release-Serie von MySQL Cluster hoffen wir, MySQL Cluster eine „heiße“ Rekonfigurationsfähigkeit implementieren zu können, um die Anforderungen an den Neustart des Clusters nach dem Hinzufügen neuer Knoten zu minimieren (wenn nicht gar zu eliminieren).

Muss ich irgendwelche Einschränkungen berücksichtigen, wenn ich Cluster benutze?

Für NDB-Tabellen gelten in MySQL folgende Einschränkungen:

Weitere Informationen über Beschränkungen in Clustern finden Sie unter Abschnitt 16.8, „Bekannte Beschränkungen von MySQL Cluster“.

Wie importiere ich eine vorhandene MySQL-Datenbank in einen Cluster?

Wie in jede andere Version von MySQL können Sie auch in MySQL Cluster Datenbanken importieren. Außer den im obigen Absatz erwähnten Beschränkungen gibt es nur eine einzige weitere Sonderbedingung: Alle Tabellen, die in den Cluster eingebracht werden sollen, müssen die Speicher-Engine NDB verwenden. Das bedeutet, dass die Tabellen mit ENGINE=NDB oder ENGINE=NDBCLUSTER angelegt werden müssen. Es ist auch möglich, bestehende Tabellen, die andere Speicher-Engines nutzen, mit ALTER TABLE in NDB Cluster zu konvertieren, aber dafür ist ein zusätzlicher Workaround notwendig. Einzelheiten siehe Abschnitt 16.8, „Bekannte Beschränkungen von MySQL Cluster“.

Wie kommunizieren Cluster-Knoten?

Cluster-Knoten können über drei Protokolle miteinander kommunizieren: TCP/IP, SHM (Shared Memory) und SCI (Scalable Coherent Interface). Wo es zur Verfügung steht, wird nach Voreinstellung SHM für Knoten benutzt, die auf demselben Cluster-Host residieren. SCI ist ein sehr schnelles (1 Gigabit pro Sekunde und mehr) und hochverfügbares Protokoll, das beim Aufbau skalierbarer Mehrprozessorsysteme zum Einsatz kommt. Es erfordert spezielle Hardware und Treiber. Unter Abschnitt 16.7, „Verwendung von Hochgeschwindigkeits-Interconnects mit MySQL Cluster“, erfahren Sie mehr über SCI als Transportmechanismus in MySQL Cluster.

Was ist ein „Arbitrator“?

Wenn ein oder mehrere Cluster-Knoten abstürzen, ist es möglich, dass nicht mehr alle Cluster-Knoten einander „sehen“ können. Es kann sogar passieren, dass zwei Knotenmengen durch eine Netzwerkpartitionierung voneinander isoliert werden, die man auch als „Split Brain“-Szenario bezeichnet. Eine solche Situation ist nicht wünschenswert, da jede der beiden Knotenmengen versuchen würde, den gesamten Cluster darzustellen.

Wenn Cluster-Knoten abstürzen, gibt es zwei Möglichkeiten: Wenn mehr als 50 % der verbleibenden Knoten miteinander kommunizieren können, haben wir eine so genannte „Majority Rules“-Situation („die Mehrheit regiert“), und diese Knotenmenge wird dann als der Cluster betrachtet. Der Arbitrator kommt ins Spiel, wenn es einen Gleichstand zwischen den Knoten gibt: In solchen Fällen wird die Knotenmenge, zu welcher der Arbitrator gehört, als der Cluster betrachtet, und die anderen Knoten werden heruntergefahren.

Diese Darstellung ist etwas vereinfachend. Eine genauere Erkärung, die auch Knotengruppen berücksichtigt, folgt:

Wenn alle Knoten in mindestens einer Knotengruppe am Leben sind, entstehen keine Probleme mit Netzwerkpartitionierung, da kein einzelner Teil des Clusters einen funktionsfähigen Cluster bilden kann. Das eigentliche Problem entsteht, wenn in keiner Knotengruppe alle Knoten mehr am Leben sind. In diesem Fall wird eine Netzwerkpartitionierung, das so genannte „Split-Brain“-Szenario, möglich. Dann ist ein Arbitrator (engl. für „Schiedsrichter“) gefordert. Alle Cluster-Knoten betrachten denselben Knoten, normalerweise den Management-Knoten, als Arbitrator. Es ist jedoch möglich, stattdessen einen der MySQL Server im Cluster als Arbitrator zu konfigurieren. Der Arbitrator gestattet, dass die erste Knotenmenge mit ihm Kontakt aufnimmt, und fährt die andere Knotenmenge herunter. Die Wahl des Arbitrators wird durch den Konfigurationsparameter ArbitrationRank für MySQL Server- und Management-Server-Knoten gesteuert. (Einzelheiten siehe Abschnitt 16.4.4.4, „Festlegung des MySQL Cluster-Management-Servers“.) Beachten Sie außerdem, dass der Arbitrator an sich keine großen Anforderungen an den als Arbitrator ausgewählten Host stellt, er muss also nicht besonders schnell sein oder einen besonders großen Arbeitsspeicher haben, um für diese Aufgabe geeignet zu sein.

Welche Datentypen unterstützt MySQL Cluster?

MySQL Cluster unterstützt alle üblichen MySQL-Datentypen, ausgenommen die raumbezogenen, die zur Spatial-Erweiterung von MySQL gehören. (Siehe Kapitel 18, Raumbezogene Erweiterungen in MySQL.) Darüber hinaus gibt es bei NDB-Tabellen einige Abweichungen im Hinblick auf Indizes. Hinweis: MySQL Cluster-Tabellen (also Tabellen, die mit ENGINE=NDBCLUSTER angelegt wurden) haben nur Zeilen mit fester Breite. Das bedeutet beispielsweise, dass ein Datensatz mit einer VARCHAR(255)-Spalte Speicher für 255 Zeichen belegt (wie Zeichensatz und die Kollation der Tabelle es erfordern), unabhängig davon, wie viele Zeichen tatsächlich in der Spalte gespeichert sind. Dieses Problem soll in einer künftigen Release-Serie von MySQL behoben werden.

Mehr zu diesen Fragen lesen Sie unter Abschnitt 16.8, „Bekannte Beschränkungen von MySQL Cluster“.

Wie kann ich MySQL Cluster starten und anhalten?

Jeder Knoten im Cluster muss separat gestartet werden, und zwar in folgender Reihenfolge:

Jeder dieser Befehle muss in der System-Shell des Computers ausgeführt werden, auf dem der betreffende Knoten ausgeführt wird. Ob der Cluster läuft, können Sie prüfen, indem Sie den MGM-Management-Client ndb_mgm auf dem Computer aufrufen, auf dem der MGM-Knoten läuft.

Was passiert mit den Cluster-Daten, wenn der Cluster heruntergefahren wird?

Die Daten, die in den Datenknoten des Clusters im Arbeitsspeicher liegen, werden auf die Platte geschrieben und beim nächsten Start des Clusters wieder in den Arbeitsspeicher geladen.

Um den Cluster herunterzufahren, geben Sie folgenden Befehl in die Shell des MGM-Knoten-Hosts ein:

shell> ndb_mgm -e shutdown

Das beendet geräuschlos ndb_mgm, ndb_mgm und alle ndbd-Prozesse. MySQL Server, die als SQL-Knoten eines Clusters laufen, können mit mysqladmin shutdown angehalten werden.

Weitere Informationen finden Sie unter Abschnitt 16.6.2, „Befehle des Management-Clients“, und Abschnitt 16.3.6, „Sicheres Herunterfahren und Neustarten“.

Ist es nützlich, mehr als einen Management-Knoten im Cluster zu haben?

Das kann als Ausfallsicherung hilfreich sein. Zwar wird der Cluster immer nur von einem MGM-Knoten gesteuert, aber es ist möglich, einen MGM als Primärknoten und andere als Ausfallsicherung zu konfigurieren, für den Fall, dass der Primär-MGM-Knoten abstürzt.

Kann ich in einem Cluster unterschiedliche Hardware und Betriebssysteme mixen?

Ja, aber nur wenn alle Computer und Betriebssysteme dieselbe "Endianness" haben (also entweder alle big-endian oder alle little-endian sind). Es ist auch möglich, auf verschiedenen Knoten verschiedene Releases von MySQL Cluster zu benutzen. Dies können wir jedoch nur im Rahmen einer laufenden Upgrade-Prozedur empfehlen.

Kann ich zwei Datenknoten auf einem einzigen Host betreiben? Oder zwei SQL-Knoten?

Ja, möglich wäre das schon. Wenn Sie mehrere Datenknoten haben, muss jeder Knoten ein anderes Data Directory benutzen. Wenn Sie mehrere SQL-Knoten auf derselben Maschine laufen lassen wollen, muss jede mysqld-Instanz einen anderen TCP/IP-Port benutzen.

Kann ich Hostnamen mit MySQL Cluster benutzen?

Ja, Sie können DNS und DHCP für Cluster-Hosts benutzen. Wenn Ihre Anwendung jedoch eine Verfügbarkeit von 99,999 Prozent benötigt, empfehlen wir feste IP-Adressen. Wenn Sie die Kommunikation zwischen Cluster-Hosts von Diensten wie DNS und DHCP abhängig machen, führen Sie damit zusätzliche Points of Failure ein. Je weniger es davon gibt, desto besser.