Ausfallsicherheit konnte MySQL bislang nur durch einfache Master-Slave-Replikation erreichen. Nun erlangen die ersten Clustersysteme für diese Datenbank Produktreife.

Ob Webplattform, Finanzverwaltung oder Warenwirtschaft – das Herzstück solcher Applikationen ist eine Datenbank. Fällt sie aus, sind ganze Bereiche lahm gelegt. Entsprechend wichtig ist die hochverfügbare Prävention. Auch Open-Source-Produkte, die zunehmend in Produktivumgebungen vordringen, sehen sich mit der Forderung nach Ausfallsicherheit konfrontiert.

Dieser Artikel stellt zwei Clustersysteme für MySQL vor, die über die bisherigen Master-Slave-Replikationen hinausgehen: den MySQL-Cluster[1] und den Cluster für MySQL von EAC[2]. Beide nutzen eine Shared-nothing-Technologie. Das heißt, jeder Node besitzt eine eigene Kopie des Datenbestands, die er mit anderen Knoten synchronisiert.

Cluster zugekauft

So jung, wie es zunächst scheint, ist der MySQL-Cluster nicht. Die Entwicklung geht auf die von Ericsson gegründete Firma Alzato zurück, die im Jahr 2000 an einer Datenbank-Clusterlösung arbeitete. 2003 übernahm MySQL Alzato, um deren Speicherengine NDB (Network Database) in den MySQL-Server zu integrieren. Der fungiert dabei lediglich als Frontend für den NDB-Cluster (Abbildung 1). Dabei bleibt es bei MySQLs dualer Lizenz (kommerzielle Serverlizenz: 500 Euro).

War bisher zwischen MySQL-Servern nur eine asynchrone Replikation möglich, realisiert der Cluster einen synchronen Abgleich. Dabei arbeitet er derzeit als In-RAM-Datenbank. Nur zur permanenten Speicherung beim kontrollierten Abschalten des Systems schreibt er die Informationen auf Festplatte. Daneben loggt er Änderungen am Datenset während des Betriebs auf die Disks, sodass selbst bei einem Totalausfall aller Nodes nicht alle Daten verloren sind.

Der MySQL-Cluster unterscheidet drei Arten von Nodes, wobei einem Node ein Programm und nicht ein Rechner entspricht: MGM-Nodes (Management-Server), Database-Nodes und API-Nodes. Pro Cluster muss mindestens ein MGM-Node vorhanden sein. Dieser wird zum Starten des Clusters benötigt und verwaltet die zentrale Konfiguration für den Verbund. Im Betrieb ist der Management-Server nicht mehr nötig. Erst wenn die Nodes ihre Konfiguration aktualisieren, kontaktieren sie ihn wieder.

Schwachstelle API-Nodes

Auf den Database-Nodes laufen die »ndbd«-Prozesse, die für die Datenhaltung zuständig sind. Diese Knoten sind vollkommen unabhängig von der Schnittstelle nach außen und dienen im Cluster als Backend. Auf den API-Nodes schließlich arbeiten die eigentlichen MySQL-Server, zu denen sich die Applikationen verbinden. Während für die Datenbank-Nodes ein automatisches Failover implementiert ist, muss sich der Administrator um die Sicherheit der API-Nodes selbst kümmern. Wenn ein solcher Knoten ausfällt, bricht aus Sicht der Applikation der komplette Cluster zusammen, da das System die Verbindungen nicht automatisch auf einen anderen API-Node umleitet.

Hardwarefehler abgesichert

Die neue Speicherengine NBD lässt sich neben den bisherigen Tabellenformaten wie MyISAM und InnoDB verwenden. Um eine Tabelle im NDB-Format anzulegen, muss der Anwender nur »ENGINE NDBCLUSTER« angeben, alles Weitere geschieht automatisch. Eine Tabelle in einem Nicht-Cluster-Format landet dagegen auf der Platte jenes API-Node, mit dem er gerade verbunden ist.

Der Admin kann den gesamten Datenbestand des Clusters aufteilen (partitionieren). Ein Datensatz liegt so mehrfach im Cluster, aber nicht jeder Node muss ihn speichern. Gesteuert wird dies über den Parameter »NoOfReplicas«, der angibt, wie oft der Satz vorhanden sein muss. Minimal kann es ein, maximal vier Replikate geben. Bei mehr als zwei Replikaten sind die Daten auf mehrere Rechner verteilbar. Der MySQL-Cluster sichert auf diese Weise auch Hardware-Ausfälle ab.

Abbildung 1: Applikationen, die den Cluster benutzen, kontaktieren MySQL-Server. Die eigentliche Verwaltung der Daten übernehmen die dahinter liegenden DB-Nodes des NDB-Clusters.

Im NDB-Cluster unterscheidet man einerseits Nodes, das sind logische Einheiten, die verschiedene Datenfragmente speichern, und andererseits Node Groups, die aus mehreren Nodes bestehen. Innerhalb einer Node Group kann es auch mehrere Knoten geben, die jeweils die gleichen Datenfragmente vorhalten. Abbildung 2 zeigt beispielhaft die typische Konfiguration eines NDB-Clusters mit vier logischen Nodes, zwei Node Groups und zwei physischen Servern.

Abbildung 2: Eine Beispielkonfiguration des MySQL-Clusters mit vier Nodes in zwei Gruppen.

Doppelt hält besser

Je zwei physische Nodes gehören im Beispiel zu einer logischen Node Group. Es sind zwei Replikate konfiguriert, das heißt, alle Datensätze sind doppelt vorhanden. F1 bis F4 bezeichnen die Fragmente der Datenbereiche. Jeder Node speichert je zwei Fragmente, jedes Fragment ist auf dem zweiten Node der Gruppe noch einmal vorhanden. Durch diese Aufteilung läuft der Cluster auch bei Ausfall eines der Server weiter.

EAC-Cluster für MySQL

Emic Networks wurde im Jahr 2000 gegründet und brachte die erste Version des EAC-Clusters für MySQL im Oktober 2002 auf den Markt. Im Januar folgte der Cluster für Apache, der auf der gleichen Technologie beruht. Der EAC-Cluster für MySQL ist ein kommerzielles Produkt. Die Kosten pro CPU belaufen sich auf etwa 2000 Euro.

Die Software, die für den Betrieb einen gültigen Lizenzschlüssel benötigt, kann man von der Webseite von EAC[1] herunterladen. Interessenten erhalten einen kostenlosen, zeitlich begrenzten Key zum Testen. Die EMIC-Lizenz umfasst ausschließlich die Cluster-Software. Der mitgelieferte modifizierte MySQL-Server ist separat zu lizenzieren.

Der EAC-Cluster besteht aus mehreren Komponenten: einem Kernelmodul, der Replikations- und Load-Balancing-Software und dem modifizierten MySQL-Server. Das Kernelmodul ist für die Paketfilterung für den Load Balancer erforderlich. Wenn der erkennt, dass einer der Datenbankserver überlastet oder nicht mehr ansprechbar ist, richtet er Paketfilter ein, die den Datenverkehr umleiten. Für die Installation des Moduls müssen die entsprechenden Kernelquellen bereitliegen.

Modifiziertes MySQL

Die EAC-Version des MySQL-Servers, die auf allen Nodes installiert sein muss, basiert derzeit auf MySQL 4.0.20, also einer älteren Version. Ein Problem liegt somit auf der Hand: Der Anwender ist davon abhängig, wie schnell EAC die Clusterfunktionen in neue Releases des MySQL-Servers einbaut.

Das Installationspaket liefert EAC ausschließlich im RPM-Format. Besitzer von Debian-Systemen brauchen nur die Pakete zu entpacken und die einzelnen Schritte der Installation manuell durchzuführen. Ob der Hersteller Support auch für diese Prozedur leistet, ist aber fraglich. Außerdem ist EACs MySQL-Version im Vergleich mit dem Standard-MySQL-Server in verschiedener Hinsicht eingeschränkt:

• Sie unterstützt nur »LOAD DATA LOCAL INFILE«.
  Das Kommando »LOAD DATA INFILE« ist nicht
  verwendbar.
• Es lassen sich nur InnoDB und MyISAM als Tabellenformat
  benutzen.
• Die Funktionen »NOW()«,
  »CONNECTION_ID()« und »RAND()«
  funktionieren nur bei lesendem Zugriff.
• »BEGIN«, »COMMIT« und
  »ROLLBACK« sind nicht anwendbar.
• »ANALYZE«, »KILL« und
  »OPTIMIZE« werden nicht unterstützt.

Zwei Netze

Der EAC-Cluster benutzt ein öffentliches Netzwerk für den MySQL-Traffic und ein privates für den Datenaustausch im Cluster und die Administration. Für ihr öffentliches Netzwerk-Interface verwenden alle Nodes die IP- und MAC-Adresse, unter der der gesamte Cluster erreichbar ist. Die dahinter liegende Rechnerstruktur ist für Außenstehende transparent.

Derzeit lassen sich in einem EAC-Cluster bis zu 16 Server vereinen, neue Nodes kann man im laufenden Betrieb integrieren. Dabei synchronisiert die Software den Datenbestand automatisch. Für diese Synchronisation stehen ein Blocking- und ein Nonblocking-Modus zur Verfügung. Der Blocking-Modus sperrt alle Tabellen während der Datenübertragung vollständig, der Nonblocking-Modus dagegen nur die jeweils transferierte Tabelle. Eine (nicht gut dokumentierte) Einschränkung ist jedoch, dass die Nonblocking-Variante erst mit wenigstens drei Servern funktioniert.

Ungewollte Auszeiten

Enthalten die Tabellen große Datenmengen, reagiert der Cluster während der Synchronisation geraume Zeit nicht mehr. Im Test wurden stark frequentierte Tabellen mit mehr als 20 Millionen Datensätzen kopiert, wodurch die zugreifenden Programme mehrere Minuten lang keine Abfrage starten konnten. Erfolgt die Synchronisation im Nonblocking-Modus, verhindert das Abfragen, die mehrere Tabellen einschließen. Das gewährleistet die Datenkonsistenz.

Grafisch bedienbar

Im Gegensatz zum MySQL-Cluster bietet EAC eine grafische Benutzeroberfläche zur Überwachung und Administration (Abbildung 3). Das Tool ist in Java geschrieben und arbeitet flott und stabil. Nach dem Login im Cluster sind dessen Nodes in einer Ring-Ansicht zu sehen. Das Symbol eines Node enthält dabei Zustandsinformationen.

Abbildung 3: Im Unterschied zum MySQL-Cluster bietet das Produkt von EAC dem Anwender eine grafische Oberfläche für viele Administrationsaufgaben.

Jeder Node lässt sich einzeln administrieren, die entsprechenden Kommandos übermittelt ein Mausklick. Dies gilt allerdings nur für Cluster-Kommandos, den lokalen MySQL-Server auf dem Node muss der Admin weiterhin auf einem anderen Weg verwalten. Das Tool bietet auch die Möglichkeit, Statistiken als fortlaufende Graphen anzuzeigen und die Logdateien einzusehen. Dabei stellt es unter anderem die Last, die Antwortzeiten oder den Durchsatz dar. Alle Funktionen der grafischen Oberfläche – außer der Statistik – sind auch über ein Kommandozeilen-Tool erreichbar.

Fazit

Es ist nicht ohne weiteres möglich, eindeutig zu entscheiden, welches der beiden Systeme grundsätzlich besser ist. Positiv ist auf jeden Fall, dass nun das Angebot größer ist.

EAC bietet mit dem Cluster für MySQL bereits eine schlüsselfertige Lösung, auf die man bisherige MySQL-Datenbanken und Applikationen übertragen kann. Der Cluster glänzt außerdem mit einer unkomplizierten Installation auf unterstützten Distributionen. Ist er einmal in Betrieb, erfordert er fast keinen Eingriff des Administrators mehr.

Der Admin eines MySQL-Clusters muss dagegen die Server auf allen eingebundenen Knoten noch einzeln warten. Eine weitere Schwierigkeit ist die Synchronisation, vor allem bei großen und häufig abgefragten Datenbeständen. Durch den Datentransfer kommt es unter Umständen zu längeren Ausfällen, also gerade zu jenem Effekt, den der Betreiber durch Einsatz des Clusters vermeiden will. Das Produkt befindet sich außerdem noch in Entwicklung, besonders die reine Datenhaltung im RAM lässt noch viel Skepsis aufkommen.

Die verfügbare Dokumentation ist zum Teil bereits überholt, daher lohnt es sich, auch die MySQL-Cluster-Mailingliste zu verfolgen. Im MySQL-Manual ist eine erste Konfiguration und Inbetriebnahme des Clusters sehr gut beschrieben. Die Trennung der Server für die Datenhaltung von der Schnittstelle zur Außenwelt ist durchaus sinnvoll, jedoch bilden nun die API-Nodes die eigentliche Schwachstelle des Systems. Die Cluster-Konfiguration über den Management-Node erleichtert die gesamte Verwaltung. Das NDB-Format bringt einige Einschränkungen mit sich. (jcb)