Skip navigation links
MySQL 5.1 Referenzhandbuch :: 16 MySQL Cluster :: 16.8 Bekannte Beschränkungen von MySQL Cluster
16.9 MySQL Cluster: Roadmap für die Entwicklung »
Section Navigation      [Toggle]

16.8. Bekannte Beschränkungen von MySQL Cluster

In diesem Abschnitt finden Sie eine Liste bekannter Einschränkungen in den MySQL Cluster-Releases der 5.1.x-Serie im Vergleich zu den Features, die beim Einsatz der Speicher-Engines MyISAM und InnoDB zur Verfügung stehen. Es ist zurzeit nicht geplant, diese Einschränkungen in den nächsten Releases von MySQL 5.1 zu beseitigen, aber wir werden versuchen, in der darauf folgenden Serie von Releases Lösungen für diese Probleme zu finden. Wenn Sie in der MySQL-Bugs-Datenbank http://bugs.mysql.com unter der Kategorie „Cluster“ nachschauen, erfahren Sie, welche bekannten Bugs (soweit sie mit „5.1“ markiert sind) in den nächsten Releases von MySQL 5.1 behoben werden sollen.

Die hier aufgeführte Liste sollte unter den soeben genannten Bedingungen komplett sein. Falls Ihnen irgendwelche Diskrepanzen auffallen, können Sie diese an die MySQL-Bugs-Datenbank melden, wie es unter Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“, beschrieben ist. Wenn wir nicht planen, das Problem in MySQL 5.1 zu beheben, werden wir es mit auf die Liste setzen.

  • Nichtkonforme Syntax (führt zu Fehlern bei der Ausführung vorhandener Anwendungen):

    • Textindizes werden nicht unterstützt.

    • Geometrische Datentypen (WKT und WKB) werden in NDB-Tabellen in MySQL 5.1 unterstützt, aber raumbezogene (spatial) Indizes nicht.

    • Es ist nicht möglich, Partitionen von NDB-Tabellen mit ALTER TABLE ... DROP PARTITION zu löschen. Die anderen Partitionierungserweiterungen für ALTER TABLE, nämlich ADD PARTITION, REORGANIZE PARTITION und COALESCE PARTITION, werden für Cluster-Tabellen unterstützt, aber Kopieren usw. ist nicht optimiert. Siehe auch Abschnitt 17.3.1, „Verwaltung von RANGE- und LIST-Partitionen“, und Abschnitt 13.1.2, „ALTER TABLE“.

      Seit MySQL 5.1.6 werden alle Cluster-Tabellen standardmäßig nach KEY partitioniert, wobei der Primärschlüssel der Tabelle als Partitionierungsschlüssel verwendet wird. Ist für die Tabelle nicht explizit ein Primärschlüssel definiert, wird automatisch von der Speicher-Engine NDB ein „verborgener“ Primärschlüssel erzeugt und benutzt. Mehr zu diesem und verwandten Themen finden Sie unter Abschnitt 17.2.4, „KEY-Partitionierung“.

  • Nichtkonforme Grenzwerte oder Verhalten (kann bei der Ausführung vorhandener Anwendungen zu Fehlern führen):

    • Transaktionsbehandlung:

      • NDB Cluster unterstützt als einzige Ebene der Transaktionsisolation READ COMMITTED.

      • Ein teilweises Zurückrollen von Transaktionen ist nicht möglich. Ein Fehler wegen eines doppelten Schlüssels oder etwas Ähnlichem führt dazu, dass die gesamte Transaktion zurückgerollt wird.

      • Wichtig: Wenn ein SELECT auf einer Cluster-Tabelle eine Spalte des Typs BLOB, TEXT oder VARCHAR enthält, wird die Transaktionsisolationsebene READ COMMITTED in einen Lesevorgang mit Lesesperre umgewandelt. Dies wird getan, um die Konsistenz zu garantieren, da Teile der in solchen Spalten gespeicherten Werte in Wirklichkeit aus einer anderen Tabelle gelesen werden.

    • Es gibt eine Reihe von harten Grenzwerten, die konfigurierbar sind, aber der im Cluster verfügbare Hauptspeicher setzt auf jeden Fall Grenzen. Die vollständige Liste der Konfigurationsparameter finden Sie in Abschnitt 16.4.4, „Konfigurationsdatei“. Die meisten dieser Parameter können online aktualisiert werden. Die erwähnten festen Grenzen sind:

      • Jeweiliger Arbeitsspeicher für Datenbank und Index (DataMemory und IndexMemory).

      • Wie viele Transaktionen höchstens ausgeführt werden können, ist im Konfigurationsparameter MaxNoOfConcurrentOperations festgelegt. Beachten Sie, das Massenladeoperationen, TRUNCATE TABLE, und ALTER TABLE als Sonderfälle mit mehreren Transaktionen abgearbeitet werden und daher nicht dieser Einschränkung unterliegen.

      • Verschiedene Grenzwerte für Tabellen und Indizes. So wird beispielsweise die Höchstzahl der geordneten Indizes pro Tabelle durch MaxNoOfOrderedIndexes festgesetzt.

    • Datenbank-, Tabellen- und Attributnamen dürfen in NDB-Tabellen nicht so lang sein wie bei anderen Tabellen-Handlern. Attributnamen werden auf 31 Zeichen gekappt. Wenn sie dann nicht mehr eindeutig sind, gibt es einen Fehler. Datenbank- und Tabellennamen können insgesamt 122 Zeichen lang sein. (Das bedeutet, dass ein Name einer NDB Cluster-Tabelle maximal 122 Zeichen minus die Länge des Namens der Datenbank haben kann, zu welcher die Tabelle gehört.)

    • Alle Zeilen von Cluster-Tabellen haben eine feste Länge. Wenn also (zum Beispiel) eine Tabelle ein oder mehrere VARCHAR-Felder mit relativ kleinen Werten hat, brauchen diese bei der Speicher-Engine NDB mehr Speicherplatz als bei der Speicher-Engine MyISAM. (Mit anderen Worten, eine VARCHAR-Spalte belegt beispielsweise ebenso viel Speicher wie eine gleich große CHAR-Spalte.)

    • Die Höchstzahl der Tabellen in einer Cluster-Datenbank ist auf 1.792 beschränkt.

    • Die Höchstzahl der Attribute pro Tabelle ist auf 128 beschränkt.

    • Die maximal zulässige Größe einer Zeile ist 8 Kbyte, nicht inbegriffen die in BLOB-Spalten gespeicherten Daten.

    • Die Höchstzahl der Attribute pro Schlüssel beträgt 32.

  • Nicht unterstützte Features (verursachen keinen Fehler, werden aber nicht unterstützt oder verlangt):

    • Das Fremdschlüsselkonstrukt wird, genau wie in MyISAM-Tabellen, ignoriert.

    • Savepoints und Rollbacks zu Savepoints werden, genau wie in MyISAM-Tabellen, ignoriert.

  • Probleme im Zusammenhang mit Leistung und Einschränkungen:

    • Aufgrund des sequenziellen Zugriffs hat die NDB-Speicher-Engine Leistungsprobleme mit Anfragen. Auch ist es aufwändiger als mit MyISAM oder InnoDB, viele Bereichsscans auszuführen.

    • Die Records in range-Statistik wird nicht unterstützt, sodass sich in einigen Fällen ungünstige Anfragenpläne ergeben. Als Workaround empfehlen sich USE INDEX oder FORCE INDEX.

    • Sie können keine mit USING HASH erzeugten eindeutigen Hash-Indizes für den Zugriff auf eine Tabelle verwenden, wenn NULL als Teil des Schlüssels angegeben ist.

    • MySQL Cluster unterstützt keine permanenten Commits auf der Platte. Commits werden repliziert, aber es gibt keine Garantie dafür, dass die Logs beim Committen auf die Platte zurückgeschrieben werden.

  • Fehlende Features:

    • Die einzige Isolationsebene, die unterstützt wird, ist READ COMMITTED. (InnoDB unterstützt READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ und SERIALIZABLE.) Unter Abschnitt 16.6.5.5, „Backup: Troubleshooting“, können Sie nachlesen, wie sich dies auf die Sicherung und Wiederherstellung von Cluster-Datenbanken auswirkt.

    • Es gibt keine dauerhaften Commits auf der Platte. Die Commits werden repliziert, aber es gibt keine Garantie dafür, dass die Logs beim Committen auf die Platte zurückgeschrieben werden.

  • Probleme mit mehreren MySQL Servern (betreffen nicht MyISAM oder InnoDB):

    • ALTER TABLE sperrt nicht vollständig, wenn mehrere MySQL Server betrieben werden (keine verteilte Tabellensperre).

    • MySQL-Replikation funktioniert nicht richtig, wenn Updates auf mehreren MySQL Servern ausgeführt werden. Wenn jedoch das Datenbank-Partitionierungsschema auf Anwendungsebene durchgeführt wird und keine Transaktionen über diese Partitionen hinweg stattfinden, kann die Replikation funktionieren.

    • Das selbstständige Erkennen von Datenbanken wird nicht für mehrere MySQL Server unterstützt, die auf denselben MySQL Cluster zugreifen. Die selbstständige Erkennung von Tabellen wird dagegen in diesen Fälllen unterstützt. Wenn also eine Datenbank namens db_name mit einem einzigen MySQL Server angelegt oder importiert wurde, müssen Sie für jeden weiteren Server, der auf denselben MySQL Cluster zugreift, eine CREATE SCHEMA db_name-Anweisung erteilen. Wenn dies für einen gegebenen MySQL Server erledigt ist, müsste dieser in der Lage sein, die Datenbanktabellen ohne Fehler zu erkennen.

  • Probleme, die ausschließlich MySQL Cluster betreffen (nicht MyISAM oder InnoDB):

    • Alle Cluster-Computer müssen dieselbe Architektur haben. Das bedeutet, dass alle Knoten-Hosts konsistent entweder big-endian oder little-endian sein müssen. Beispielsweise darf es keinen Management-Knoten auf einem Power-PC geben, der einen Datenknoten auf einer x86-Maschine regelt. Diese Einschränkung gilt nicht für Computer, die einfach nur mysql ausführen, oder andere Clients, die vielleicht auf die SQL-Knoten des Clusters zugreifen.

    • Es sind keine Online-Schemaänderungen mit ALTER TABLE oder CREATE INDEX möglich, da NDB Cluster nicht die selbstständige Erkennung solcher Änderungen unterstützt. (Sie können jedoch eine Tabelle importieren oder anlegen, die eine andere Speicher-Engine nutzt, und diese dann mit ALTER TABLE tbl_name ENGINE=NDBCLUSTER in eine NDB-Tabelle umwandeln. In solchen Fällen müssen Sie eine FLUSH TABLES-Anweisung geben, um den Cluster zu zwingen, die Änderung aufzugreifen.)

    • Es ist nicht möglich, Knoten online hinzuzufügen oder zu löschen (der Cluster muss in solchen Fällen neu gestartet werden).

    • Wenn mehrere Management-Server verwendet werden, gelten folgende Regeln:

      • Sie müssen den Knoten in Verbindungs-Strings explizite IDs geben, da die automatische Zuweisung von Knoten-IDs nicht über mehrere Management-Server hinweg funktioniert.

      • Sie müssen genau darauf achten, dass alle Management-Server gleich konfiguriert sind. Der Cluster wird dies nicht extra prüfen.

      • Damit die Management-Knoten voneinander wissen, müssen Sie alle Datenknoten neu starten, nachdem der Cluster eingerichtet ist. (Genaue Erläuterungen finden Sie unter Bug#13070.)

    • Einige Netzwerkschnittstellen für Datenknoten werden nicht unterstützt. Wenn Sie diese verwenden, bekommen Sie Probleme: Wenn ein Datenknoten abstürzt, wartet ein SQL-Knoten auf die Bestätigung, dass der Datenknoten nicht mehr läuft, bekommt aber keine, da eine andere Route zu dem betroffenen Datenknoten weiterhin offen bleibt. Im Endeffekt kann dies den ganzen Cluster unbenutzbar machen.

    • Die Höchstzahl der Datenknoten beträgt 48.

    • Die Gesamtzahl aller Knoten in einem MySQL Cluster beträgt 63. Das umfasst sämtliche MySQL Server (SQL-Knoten), Datenknoten und Management-Server.

    • Die Höchstzahl der Metadatenobjekte in MySQL 5.1 Cluster beträgt 20.320. Diese Obergrenze ist fest eingegeben.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.