• [COMPUTER]: Definiert die Cluster-Hosts.

• [NDBD]: Definiert die Daten des Clusters nodes.

• [MYSQLD]: Definiert die MySQL Server-Knoten des Clusters server nodes.

• [MGM] or [NDB_MGMD]: Definiert den Management-Server-Knoten des Clusters.

• [TCP]: Definiert die TCP/IP-Verbindungen zwischen den Knoten im Cluster, wobei TCP/IP das Standardverbindungsprotokoll ist.

• [SHM]: Definiert Shared-Memory-Verbindungen zwischen Knoten. Früher stand dieser Verbindungtyp nur in Binaries zur Verfügung, die mit der Option --with-ndb-shm gebaut wurden. In MySQL 5.1-Max ist er nach Voreinstellung eingeschaltet, allerdings befindet sich diese Lösung noch in der Erprobungsphase.

• Jede Executable hat ihre eigene Kommandozeilenoption, um den Management-Server beim Starten anzugeben. (In der Dokumentation finden Sie die jeweilige Executable.)

• Sie können auch die Verbindungs-Strings für alle Knoten des Clusters zugleich einrichten, indem Sie sie in den [mysql_cluster]-Abschnitt der my.cnf-Datei des Management-Servers schreiben.

• Aus Gründen der Abwärtskompatibilität stehen auch zwei weitere Optionen mit gleicher Syntax zur Verfügung:

  1. Sie können die Umgebungsvariable NDB_CONNECTSTRING auf den Verbindungs-String einstellen.

  2. Sie können den Verbindungs-String für jede Executable in eine Textdatei namens Ndb.cfg schreiben und diese Datei in das Startverzeichnis der Executable legen.

  Diese beiden Möglichkeiten sind jedoch inzwischen veraltet und sollten für neuere Installationen nicht mehr verwendet werden.

• Id

  Ein Integer-Wert, der auf einen anderswo in der Konfigurationsdatei angegebenen Hostcomputer verweist.

• HostName

  Der Hostname oder die IP-Adresse des Computers.

• Id

  Jeder Knoten im Cluster hat eine eindeutige Identität, die durch einen Integer-Wert zwischen 1 und 63 (einschließlich) dargestellt wird. Alle Nachrichten im Cluster sprechen den Knoten mit dieser ID an.

• ExecuteOnComputer

  Bezieht sich auf einen der im Abschnitt [COMPUTER] aufgeführten Computer.

• PortNumber

  Die Nummer des Ports, auf welchem der Management-Server auf Konfigurationsanforderungen und Management-Befehle lauscht.

• LogDestination

  Dieser Parameter gibt an, wohin die Logdaten für den Cluster gesandt werden: an CONSOLE, SYSLOG oder FILE:

  • CONSOLE gibt das Log an stdout aus:

    CONSOLE
    

  • SYSLOG sendet das Log an syslog, wobei einer der folgenden Werte verwendet wird: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6 oder local7.

    Hinweis: Nicht jedes Betriebssystem unterstützt alle diese Werte.

    SYSLOG:facility=syslog
    

  • FILE sendet die Ausgabe des Cluster-Logs an eine normale Datei auf demselben Computer. Folgende Werte können angegeben werden:

    • filename: Der Name der Logdatei.

    • maxsize: Die Maximalgröße (in Bytes), auf welche die Datei anwachsen kann, ehe das Log in einer neuen Datei fortgesetzt wird. Wenn dies geschieht, wird die alte Logdatei umbenannt, indem ein .N an ihren Dateinamen angefügt wird, wobei N die nächste laufende Nummer ist, die noch nicht für diesen Dateinamen eingesetzt wurde.

    • maxfiles: Die maximale Anzahl der Logdateien.

    FILE:filename=cluster.log,maxsize=1000000,maxfiles=6
    

    In der folgenden Form können auch mehrere Logdestinationen, jeweils durch Semikola getrennt, angegeben werden:

    CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
    

    Der Parameter FILE hat folgenden Standardwert: FILE:filename=ndb_node_id_cluster.log,maxsize=1000000,maxfiles=6. node_id ist dabei die ID des Knotens.

• ArbitrationRank

  Mit diesem Parameter wird angegeben, welche Knoten als Arbitrator fungieren können. Nur MGM- und SQL-Knoten können Arbitrator sein. Der ArbitrationRank can take ist einer der folgenden Werte:

  • 0: Dieser Knoten wird nie als Arbitrator eingesetzt.

  • 1: Da dieser Knoten eine hohe Priorität hat, wird er eher als Knoten mit niedriger Priorität als Arbitrator eingesetzt.

  • 2: Ein Knoten mit niedriger Priorität, der als Arbitrator nur eingesetzt wird, wenn kein Knoten mit höherer Priorität für diesen Zweck verfügbar ist.

  Normalerweise sollte der Management-Server als Arbitrator konfiguriert werden, indem sein ArbitrationRank auf 1 (den Default) und der Rang aller SQL-Knoten auf 0 gesetzt wird.

• ArbitrationDelay

  Ein Integer-Wert, der angibt, um wie viele Millisekunden die Antworten des Management-Servers auf Arbitration-Requests verzögert werden. Der Standardwert 0 muss normalerweise nicht geändert werden.

• DataDir

  Das Verzeichnis, in dem die Ausgabedateien des Management-Servers gespeichert werden. Dazu gehören die Cluster-Logdateien, die Prozess-Ausgabedateien und die Prozess-ID (PID)-Datei des Daemons. (Für die Logdateien können Sie auch einen anderen Speicherort einstellen, indem Sie, wie weiter oben in diesem Abschnitt beschrieben, den Parameter FILE für die LogDestination einstellen.)

• entweder ExecuteOnComputer oder HostName

• der Parameter NoOfReplicas

• Id

  Diese Knoten-ID ist die Adresse des Knotens für alle internen Nachrichten im Cluster. Sie ist ein Integer zwischen 1 und 63 einschließlich. Jeder Knoten im Cluster muss eine eindeutige Identität haben.

• ExecuteOnComputer

  Bezieht sich auf einen der Computer (Hosts), die im Abschnitt COMPUTER definiert sind.

• HostName

  Die Angabe dieses Parameters wirkt sich ähnlich wie die Angabe von ExecuteOnComputer aus: Er definiert den Hostnamen des Computers, auf dem der Speicherknoten liegen soll. Wenn Sie einen anderen Hostnamen als localhost angeben möchten, müssen Sie entweder diesen Parameter oder ExecuteOnComputer verwenden.

• ServerPort (OBSOLETE)

  Jeder Knoten im Cluster verbindet sich mit anderen Computern über einen Port. Dieser Port wird beim Einrichten der Verbindung auch für Nicht-TCP-Transporter verwendet. Der Standardport wird dynamisch in einer Weise zugewiesen, die gewährleistet, dass keine zwei Knoten auf demselben Computer die gleiche Portnummer bekommen. Daher dürfte es sich normalerweise erübrigen, einen Wert für diesen Parameter zu setzen.

• NoOfReplicas

  Dieser globale Parameter kann nur im Abschnitt [NDBD DEFAULT] eingestellt werden und definiert, wie viele Replikas jeder Tabelle im Cluster gespeichert werden. Außerdem gibt dieser Parameter die Größe der Knotengruppen an. Eine Knotengruppe ist eine Menge von Knoten, die alle dieselben Informationen speichern.

  Knotengruppen werden implizit gebildet. Die erste Knotengruppe besteht aus der Menge der Datenknoten mit den niedrigsten Knoten-IDs, die nächste aus der Menge der Datenknoten mit den zweitniedrigsten IDs und so weiter. Nehmen wir als Beispiel an, wir hätten 4 Datenknoten und die NoOfReplicas wurde auf 2 gesetzt. Die vier Datenknoten haben die IDs 2, 3, 4 und 5. Dann besteht die erste Gruppe aus den Knoten 2 und 3 und die zweite Gruppe aus den Knoten 4 und 5. Es ist wichtig, den Cluster so zu konfigurieren, dass Knoten derselben Gruppe nicht auf demselben Computer liegen, da ein einziger Hardwareabsturz dann den gesamten Cluster zerstören würde.

  Wenn keine Knoten-IDs angegeben werden, entscheidet die Reihenfolge der Datenknoten über ihre Zugehörigkeit zu einer Knotengruppe. Egal ob explizit zugewiesen oder nicht, die SHOW-Ausgabe auf dem Management-Client zeigt die Knotengruppen an.

  NoOfReplicas hat keinen Standardwert, der größtmögliche Wert beträgt 4.

• DataDir

  Dieser Parameter gibt das Verzeichnis für die Trace-Dateien, Logdateien, PID-Dateien und Fehlerlogs an.

• FileSystemPath

  Dieser Parameter gibt an, in welchem Verzeichnis alle Dateien gespeichert werden, die für Metadaten, REDO-Logs, UNDO-Logs und Datendateien angelegt werden. Nach Voreinstellung ist dies das in DataDir angegebene Verzeichnis. Hinweis: Dieses Verzeichnis muss existieren, bevor der ndbd-Prozess gestartet wird.

  Die empfohlene Verzeichnishierarchie für MySQL Cluster beginnt mit dem Verzeichnis /var/lib/mysql-cluster, unter dem dann ein Verzeichnis für das Dateisystem des Knotens angelegt wird. Der Name dieses Unterverzeichnisses enthält die Knoten-ID. Wenn beispielsweise die Knoten-ID die 2 ist, heißt das Unterverzeichnis ndb_2_fs.

• BackupDataDir

  Dieser Parameter sagt, in welches Verzeichnis die Sicherungsdateien gespeichert werden. Wird nichts angegeben, ist ein Verzeichnis namens BACKUP unter dem im Parameter FileSystemPath angegebenen Speicherort das Standardverzeichnis (siehe oben.)

• DataMemory

  Dieser Parameter besagt, wie viel Speicherplatz (in Bytes) für die Speicherung der Datenbankeinträge zur Verfügung stehen muss. Da im Arbeitsspeicher der gesamte hier angegebene Speicherplatz zugewiesen wird, ist es extrem wichtig, dass der physikalische Arbeitsspeicher des Computers groß genug ist, um diesen auch unterbringen zu können.

  Der durch DataMemory zugewiesene Speicher wird sowohl für die Datensätze als auch für ihre Indizes verwendet. Jeder Datensatz hat zurzeit noch eine feste Größe (sogar VARCHAR-Spalten werden als Spalten fester Breite gespeichert). Für jeden Datensatz gibt es einen Overhead von 16 Byte. Zusätzlich wird noch weiterer Platz für jeden Datensatz zugewiesen, da er in einer 32-Kbyte-Seite mit 128 Byte Seiten-Overhead gespeichert wird (siehe unten). Zudem wird für jede Seite ein wenig Platz verschwendet, da jeder Datensatz in ein- und derselben Seite gespeichert werden muss. Die Maximalgröße eines Datensatzes beträgt gegenwärtig 8.052 Byte.

  Der in DataMemory definierte Speicherplatz wird auch zur Unterbringung von Indizes genutzt, die rund 10 Byte pro Datensatz belegen. Jede Tabellenzeile wird im geordneten Index dargestellt. Oft nehmen Anwender fälschlich an, dass alle Indizes in dem Speicher des IndexMemory abgelegt werden, doch dies ist nicht der Fall: Nur Primärschlüssel und eindeutige Hash-Indizes nutzen diesen Speicher, während geordnete Indizes den von DataMemory zugewiesenen Speicher belegen. Wenn Sie jedoch einen Primärschlüssel oder einen eindeutigen Hash-Index anlegen, wird zugleich auf denselben Schlüsseln auch ein geordneter Index erzeugt, sofern Sie nicht in der Indexanweisung USING HASH gesagt haben. Dies können Sie prüfen, indem Sie ndb_desc -d db_name table_name im Management-Client ausführen.

  Der für das DataMemory zugewiesene Speicherplatz besteht aus 32-Kbyte-Seiten, die den Tabellenfragmenten zugeordnet werden. Jede Tabelle wird normalerweise in ebenso viele Fragmente partitioniert, wie der Cluster Datenknoten hat. Also sind für jeden Knoten so viele Fragmente vorhanden, wie in NoOfReplicas eingestellt sind. Gegenwärtig ist es nicht möglich, eine einmal zugewiesene Seite dem Pool der freien Seiten zurückzugeben, außer man löscht die Tabelle. Auch durch eine Knotenwiederherstellung wird die Partition kleiner, da alle Datensätze in leere Partitionen anderer Live-Knoten geschrieben werden.

  Der Speicherplatz im DataMemory enthält auch UNDO-Informationen: Bei jedem Update wird eine Kopie des unveränderten Datensatzes in das DataMemory geschrieben. Außerdem wird jede Kopie in den geordneten Tabellenindizes referenziert. Eindeutige Hash-Indizes werden nur aktualisiert, wenn die eindeutigen Indexspalten sich ändern. In diesem Fall wird ein neuer Eintrag in die Indextabelle eingefügt und der alte beim Committen gelöscht. Aus diesem Grunde ist es auch notwendig, genug Speicherplatz zu reservieren, um selbst die größten Transaktionen von Anwendungen, die diesen Cluster nutzen, noch behandeln zu können. Wenige große Transaktionen auszuführen ist jedenfalls nicht besser, als viele kleine zu verwenden. Dafür gibt es folgende Gründe:

  • Große Transaktionen sind nicht schneller als kleinere.

  • Wenn eine Transaktion scheitert, müssen bei großen Transaktionen mehr Operationen wiederholt werden, weil sie verloren gegangen sind.

  • Große Transaktionen belegen mehr Speicherplatz.

  Der Standardwert für das DataMemory beträgt 80 Mbyte und der Mindestwert 1 Mbyte. Es gibt keinen Höchstwert, aber in der Praxis muss die Maximalgröße natürlich so angepasst werden, dass der Prozess nicht anfängt, auf die Platte zu schreiben, wenn das Limit erreicht wird. Dieses Limit hängt von der Größe des auf dem Computer verfügbaren physikalischen Arbeitsspeichers ab sowie von der Frage, wie viel Speicher das Betriebssystem einem einzelnen Prozess zuweisen kann. 32-Bit-Betriebssysteme sind generell auf 2 bis 4 Gbyte pro Prozess beschränkt, während 64-Bit-Betriebssysteme mehr Speicher verwenden können. Aus diesem Grunde eignen sich 64-Bit-Systeme für große Datenbanken besser. Überdies ist es möglich, mehrere ndbd-Prozesse pro Computer auszuführen. Dies kann bei Maschinen mit mehreren CPUs Vorteile bringen.

• IndexMemory

  Dieser Parameter gibt an, wie viel Speicher für Hash-Indizes in MySQL Cluster benutzt wird. Hash-Indizes werden immer für Primärschlüsselindizes, eindeutige Indizes und Unique-Constraints verwendet. Achtung: Wenn Sie einen Primärschlüssel und einen eindeutigen Index definieren, werden zwei Indizes angelegt, von denen einer ein Hash-Index ist, der für alle Tupel-Zugriffe, für die Sperren und für die Durchsetzung von Unique-Constraints verwendet wird.

  Die Größe des Hash-Indexes beträgt 25 Byte pro Datensatz plus die Größe des Primärschlüssels. Für Primärschlüssel, die mehr als 32 Byte belegen, werden weitere 8 Byte addiert.

  Der Standardwert für IndexMemory beträgt 18 Mbyte, der Mindestwert 1 Mbyte.

• MaxNoOfConcurrentTransactions

  Für jede aktive Transaktion im Cluster muss ein Datensatz in einem der Cluster-Knoten stehen. Die Aufgabe, Transaktionen zu koordinieren, teilen sich die Knoten untereinander auf. Die Gesamtzahl der Transaktionsdatensätze im Cluster ist gleich der Anzahl der Transaktionen in einem gegebenen Knoten mal der Anzahl der Knoten im Cluster.

  Transaktionsdatensätze werden einzelnen MySQL Servern zugewiesen. Normalerweise ist pro Verbindung mindestens ein Transaktionsdatensatz zugewiesen, der eine beliebige Tabelle in dem Cluster benutzen kann. Daher sollten Sie dafür sorgen, dass in einem Cluster mehr Transaktionsdatensätze als nebenläufige Verbindungen zu allen MySQL Servern im Cluster vorhanden sind.

  Dieser Parameter muss für alle Cluster-Knoten auf denselben Wert gesetzt werden.

  Dieser Parameter sollte nie geändert werden, da dadurch ein Cluster abstürzen kann. Wenn ein Knoten abstürzt, erstellt ein anderer Knoten (nämlich der älteste überlebende) den Status aller Transaktionen, die im Augenblick des Crashs in dem abgestürzten Knoten abliefen. Daher ist es wichtig, dass dieser Knoten so viele Transaktionsdatensätze wie der abgestürzte Knoten hat.

  Der Standardwert ist 4096.

• MaxNoOfConcurrentOperations

  Diesen Parameter sollte man immer an die Größe und Anzahl der Transaktionen anpassen. Wenn Ihre Transaktionen immer nur wenige Operationen ausführen und nicht viele Datensätze betreffen, besteht kein Anlass, diesen Parameter auf einen hohen Wert zu setzen. Doch für große Transaktionen mit vielen Datensätzen sollten Sie ihn heraufsetzen.

  Für jede Transaktion, die Cluster-Daten ändert, werden sowohl im Transaktionskoordinator als auch in den Knoten, wo die eigentlichen Änderungen eintreten, Aufzeichnungen gemacht. Diese Einträge enthalten Statusinformationen, die erforderlich sind, um die UNDO-Datensätze für Rollback, Lock Queues und andere Sätze zu erhalten.

  Dieser Parameter sollte auf die Anzahl der in Transaktionen gleichzeitig zu ändernden Datensätze, dividiert durch die Anzahl der Datenknoten im Cluster, gesetzt werden. In einem Cluster, der 4 Datenknoten hat und 1.000.000 nebenläufige Updates bewältigen soll, beträgt dieser Wert 1.000.000 / 4 = 250.000.

  Auch durch Leseanfragen, die Sperren setzen, werden Operationseinträge erzeugt. Für diese wird in den einzelnen Knoten etwas mehr Speicherplatz reserviert, um mit Fällen umgehen zu können, in denen die Verteilung über die Knoten nicht perfekt ist.

  Wenn Abfragen den eindeutigen Hash-Index verwenden, gibt es sogar zwei Operationseinträge pro Transaktionsdatensatz. Der erste stellt den Lesevorgang in der Indextabelle dar und der zweite betrifft die Operation auf der Basistabelle.

  Der Standardwert ist 32768.

  Dieser Parameter steuert in Wirklichkeit zwei separat konfigurierbare Werte. Der erste gibt an, wie viele Operationseinträge mit dem Transaktionskoordinator gesetzt werden, und der zweite, wie viele Operationseinträge lokal in der Datenbank gemacht werden.

  Eine sehr große Transaktion auf einem Cluster mit 8 Knoten erfordert im Transaktionskoordinator so viele Operationseinträge, wie es Lese-, Änderungs- und Einfügungsoperationen in der Transaktion gibt. Dabei werden die Operationseinträge allerdings über alle 8 Knoten verteilt. Also sollten die beiden Teile getrennt konfiguriert werden, wenn das System auf eine einzelne sehr große Transaktion vorbereitet werden soll. Anhand von MaxNoOfConcurrentOperations wird immer berechnet, wie viele Operationseinträge es in dem Teil des Knotens gibt, wo der Transaktionskoordinator sitzt.

  Zudem ist es wichtig, eine ungefähre Vorstellung des Speicherbedarfs für die Operationseinträge zu haben: Diese belegen pro Eintrag ungefähr 1 Kbyte.

• MaxNoOfLocalOperations

  Nach Voreinstellung wird dieser Parameter zu 1,1 × MaxNoOfConcurrentOperations berechnet. Dies eignet sich für Systeme mit vielen simultanen Transaktionen, die jedoch alle nicht sehr umfangreich sind. Wenn Sie immer nur eine einzige, dafür aber sehr große Transaktion und zudem viele Knoten haben, sollten Sie den Standardwert dieses Parameters mit einem geeigneteren überschreiben.

• MaxNoOfConcurrentIndexOperations

  Für Anfragen, die einen eindeutigen Hash-Index verwenden, wird während der Ausführungsphase eine weitere Gruppe von Operationseinträgen erstellt. Dieser Parameter stellt die Größe dieses Pools an Einträgen ein. Also wird dieser Eintrag nur während der Ausführung eines Teils einer Anfrage zugewiesen. Sobald dieser Teil abgeschlossen ist, wird der Eintrag wieder freigegeben. Der Zustand, in dem Transaktionen abgebrochen oder committet werden, wird von den normalen Operationseinträgen behandelt, deren Pool-Größe durch den Parameter MaxNoOfConcurrentOperations eingestellt wird.

  Dieser Parameter hat den Standardwert 8192. Nur in seltenen Fällen, in denen extrem hoher Parallelismus auftritt und eindeutige Hash-Indizes verwendet werden, kann es erforderlich sein, diesen Wert zu erhöhen. Auch ein kleinerer Wert ist möglich und kann Speicherplatz sparen, wenn der DBA sich sicher ist, dass für den Cluster kein besonders hoher Parallelismus erforderlich ist.

• MaxNoOfFiredTriggers

  Der Standardwert von MaxNoOfFiredTriggers ist 4000 und dürfte für die meisten Situationen ausreichen. In manchen Fällen kann er sogar heruntergesetzt werden, wenn der DBA sich sicher ist, dass in dem Cluster kein besonderer Parallelismus auftritt.

  Wenn eine Operation ausgeführt wird, wird ein Datensatz angelegt, der einen eindeutigen Hash-Index beeinflusst. Eine Einfügung oder Löschung eines Eintrags in einer Tabelle mit eindeutigen Hash-Indizes oder eine Aktualisierung einer Spalte, die Teil eines eindeutigen Hash-Indexes ist, löst eine entsprechende Einfügung oder Löschung in der Indextabelle aus. Der resultierende Eintrag wird verwendet, um diese Indextabellenoperation zu repräsentieren, so lange die Originaloperation, die ihn veranlasste, noch nicht abgeschlossen ist. Diese Operation ist zwar kurzlebig, kann aber dennoch viele Einträge in ihrem Pool benötigen, wenn viele parallele Schreiboperationen auf einer Basistabelle stattfinden, die eine Reihe von eindeutigen Hash-Indizes enthält.

• TransactionBufferMemory

  Dieser Parameter betrifft den Speicher zum Nachvollziehen von Operationen, die bei der Aktualisierung von Indextabellen und beim Lesen von eindeutigen Indizes auftreten. In diesem Arbeitsspeicherbereich werden die Schlüssel- und Spalteninformationen für diese Operationen gespeichert. Nur in seltenen Fällen muss dieser Parameter auf einen anderen als seinen Standardwert gesetzt werden.

  Normale Lese- und Schreiboperationen nutzen einen ähnlichen Puffer, der sogar noch kurzfristiger arbeitet. Der zur Übersetzungszeit benutzte Parameter ZATTRBUF_FILESIZE (aus ndb/src/kernel/blocks/Dbtc/Dbtc.hpp) ist auf 4.000 × 128 Byte (500 Kbyte) eingestellt. Ein ähnlicher Puffer für die Schlüsselinformationen, nämlich ZDATABUF_FILESIZE (ebenfalls in Dbtc.hpp), bietet 4.000 × 16 = 62,5 Kbyte Speicherplatz. Dbtc ist das Modul, welches sich um die Transaktionskoordination kümmert.

Das Modul Dblqh hat noch weitere [NDBD]-Parameter (in ndb/src/kernel/blocks/Dblqh/Dblqh.hpp), die sich auf Lese- und Änderungsoperationen auswirken. Hierzu gehören die ZATTRINBUF_FILESIZE, die auf 10.000 × 128 Byte (1250 Kbyte) voreingestellt ist, und ZDATABUF_FILE_SIZE mit dem Standardwert 10.000 * 16 Byte (rund 156 Kbyte) Speicherplatz im Puffer. Bisher haben weder Anwender noch die Ergebnisse unserer umfangreichen Tests je eine Erhöhung dieser Compile-Time-Limits nahe gelegt.

Der Standardwert für TransactionBufferMemory ist 1 Mbyte.

• MaxNoOfConcurrentScans

  Dieser Parameter stellt ein, wie viele parallele Scans im Cluster ausgeführt werden können. Jeder Transaktionskoordinator kann so viele parallele Scans bewältigen, wie dieser Parameter festlegt. Jede Scananfrage wird durch paralleles Scannen aller Partitionen ausgeführt. Jeder Partitionsscan verwendet einen Scandatensatz in dem Knoten, auf dem sich die Partition befindet, wobei die Anzahl der Einträge der Wert dieses Parameters mal die Anzahl der Knoten ist. Der Cluster sollte in der Lage sein, MaxNoOfConcurrentScans nebenläufige Scans auf allen Knoten im Cluster zu bewältigen.

  Scans werden tatsächlich in zwei Fällen ausgeführt: erstens wenn kein Hash-Index oder geordneter Index für die Ausführung der Anfrage vorliegt; in diesem Fall wird die Anfrage mithilfe eines vollständigen Tabellenscans ausgeführt. Zweitens, wenn für die Anfrage zwar kein Hash-Index, aber ein geordneter Index vorhanden ist, denn die Verwendung eines geordneten Indexes erfordert zusätzlich einen parallelen Bereichsscan. Da die Reihenfolge nur auf den lokalen Partitionen beibehalten wird, muss der Indexscan auf allen Partitionen ausgeführt werden.

  Der Standardwert von MaxNoOfConcurrentScans ist 256 und der Höchstwert beträgt 500.

  Dieser Parameter gibt an, wie viele Scans im Transaktionskoordinator möglich sind. Wenn keine Anzahl für lokale Scandatensätze vorgegeben ist, wird sie als MaxNoOfConcurrentScans mal der Anzahl der Datenknoten im System berechnet.

• MaxNoOfLocalScans

  Gibt die Anzahl der lokalen Scandatensätze an, wenn viele Scans nicht vollständig parallelisiert sind.

• BatchSizePerLocalScan

  Dieser Parameter wird genutzt, um zu berechnen, wie viele Sperrdatensätze erforderlich sind, um viele nebenläufige Scanoperationen zu handhaben.

  Der Standardwert beträgt 64; dieser Wert steht in enger Verbindung zur in den SQL-Knoten definierten ScanBatchSize.

• LongMessageBuffer

  Dies ist ein interner Puffer für die Weitergabe von Nachrichten in oder zwischen Knoten. Der Wert muss zwar wahrscheinlich nie geändert werden, ist aber dennoch konfigurierbar. Sein Standardwert beträgt 1 Mbyte.

• NoOfFragmentLogFiles

  Dieser Parameter stellt die Größe der REDO-Logdateien des Knotens ein. REDO-Logdateien sind ringförmig organisiert, wobei es außerordentlich wichtig ist, dass die erste und die letzte Logdatei (auch „Head“ und „Tail“ genannt) nicht aufeinander treffen. Wenn sich diese beiden zu stark annähern, fängt der Knoten an, alle Transaktionen abzubrechen, in denen Updates vorkommen, da kein Platz für neue Logeinträge mehr vorhanden ist.

  Ein REDO-Logeintrag wird erst gelöscht, wenn seit seiner Einfügung drei lokale Checkpoints erreicht wurden. Die Häufigkeit der Checkpoints wird durch eigene Konfigurationsparameter festgelegt, die an anderer Stelle in diesem Kapitel beschrieben werden.

  Der Standardparameterwert beträgt 8, also 8 mal 4 16-Mbyte-Dateien oder insgesamt 512 Mbyte. Mit anderen Worten: Der Speicher für die REDO-Logs muss in Blöcken zu 64 Mbyte zugewiesen werden. In Szenarien, in denen viele Updates erforderlich sind, kann es erforderlich werden, den Wert von NoOfFragmentLogFiles sogar auf 300 oder noch mehr zu setzen, um genügend Platz für die REDO-Logs zu schaffen.

  Wenn das Checkpointing zu langsam läuft und so viele Schreibvorgänge in der Datenbank stattfinden, dass die Logdateien voll laufen und der Logtail nicht abgetrennt werden kann, ohne die Wiederherstellung zu gefährden, können Änderungstransaktionen mit dem internen Fehlercode 410 (Out of log file space temporarily) abgebrochen werden. Dies dauert so lange, bis ein Checkpoint abgeschlossen ist und der Logtail vorrücken kann.

• MaxNoOfSavedMessages

  Dieser Parameter stellt ein, wie viele Trace-Dateien maximal gespeichert werden, ehe die alten überschrieben werden. Trace-Dateien werden angelegt, wenn der Knoten aus irgendeinem Grund abstürzt.

  Der Standardwert sind 25 Trace-Dateien.

• MaxNoOfAttributes

  Gibt an, wie viele Attribute im Cluster definiert werden können.

  Der Standardwert beträgt 1.000 und der kleinstmögliche Wert 32. Einen Höchstwert gibt es nicht. Jedes Attribut belegt rund 200 Byte Speicherplatz pro Knoten, da alle Metadaten vollständig auf den Servern repliziert werden.

  Bei der Einstellung von MaxNoOfAttributes müssen Sie sich schon im Voraus klar machen, wie viele ALTER TABLE-Anweisungen Sie wohl in Zukunft ausführen möchten. Denn wenn Sie ALTER TABLE auf einer Cluster-Tabelle ausführen, werden dreimal so viele Attribute wie in der Originaltabelle verwendet. Wenn eine Tabelle beispielsweise 100 Attribute benötigt und Sie in der Lage sein möchten, diese Tabelle später noch zu ändern, müssen Sie den Wert von MaxNoOfAttributes auf 300 setzen. Wenn wir voraussetzen, dass Sie alle gewünschten Tabellen ohne irgendwelche Probleme anlegen können, sollten Sie MaxNoOfAttributes sicherheitshalber doppelt so viele Attribute hinzufügen, wie die größte Tabelle besitzt. Außerdem sollten Sie nach der Konfiguration des Parameters mit einem echten ALTER TABLE prüfen, ob diese Zahl ausreicht. Wenn die Anweisung scheitert, müssen Sie MaxNoOfAttributes um ein anderes Vielfaches des ursprünglichen Werts erhöhen und erneut testen.

• MaxNoOfTables

  Für jede Tabelle, jeden eindeutigen Hash-Index und jeden geordneten Index wird ein Tabellenobjekt zugewiesen. Dieser Parameter stellt ein, wie viele Tabellenobjekte der Cluster insgesamt maximal haben kann.

  Für jedes Attribut vom Typ BLOB wird eine zusätzliche Tabelle verwendet, um einen Großteil der BLOB-Daten zu speichern. Auch diese Tabellen müssen beim Festlegen der Gesamtzahl der Tabellen berücksichtigt werden.

  Dieser Parameter ist standardmäßig auf 128 eingestellt. Sein Mindestwert beträgt 8 und sein Höchstwert 1600. Jedes Tabellenobjekt belegt rund 20 Kbyte pro Knoten.

• MaxNoOfOrderedIndexes

  Für jeden geordneten Index im Cluster wird ein Objekt zugewiesen, das beschreibt, was hier indiziert wird und in welchen Speichersegmenten. Nach Voreinstellung ist jeder so definierte Index ein geordneter Index. Jeder eindeutige Index und jeder Primärschlüssel besitzt sowohl einen geordneten als auch einen Hash-Index.

  Dieser Parameter hat den Standardwert 128. Jedes Objekt belegt ungefähr 10 Kbyte pro Knoten.

• MaxNoOfUniqueHashIndexes

  Für jeden eindeutigen Index, der kein Primärschlüssel ist, wird eine spezielle Tabelle zugewiesen, die den eindeutigen Schlüssel auf den Primärschlüssel der indizierten Tabelle abbildet. Nach Voreinstellung wird außerdem für jeden eindeutigen Index ein geordneter Index definiert. Wenn Sie dies verhindern möchten, müssen Sie beim Definieren des eindeutigen Indexes die Option USING HASH angeben.

  Der Standardwert ist 64. Jeder Index belegt ungefähr 15 Kbyte pro Knoten.

• MaxNoOfTriggers

  Für jeden eindeutigen Hash-Index werden interne Update-, Insert- und Delete-Trigger zugewiesen. (Das bedeutet, dass für jeden solchen Index drei Trigger erzeugt werden.) Ein geordneter Index erfordert dagegen nur ein einziges Trigger-Objekt. Auch Datensicherungen benötigen drei Trigger-Objekte für jede normale Tabelle im Cluster.

  Hinweis: Wenn Replikation zwischen Clustern unterstützt wird, sind auch dafür interne Trigger erforderlich.

  Dieser Parameter stellt die Höchstzahl der Trigger-Objekte im Cluster ein.

  Der Standardwert ist 768.

• MaxNoOfIndexes

  Dieser Parameter ist in MySQL 5.1 veraltet. Bitte verwenden Sie stattdessen MaxNoOfOrderedIndexes und MaxNoOfUniqueHashIndexes.

  Dieser Parameter wird nur von eindeutigen Hash-Indizes verwendet. Für jeden derartigen Index, der im Cluster definiert ist, muss ein Datensatz in diesem Pool vorhanden sein.

  Der Standardwert dieses Parameters ist 128.

• LockPagesInMainMemory

  Viele Betriebssysteme, darunter auch Solaris und Linux, können einen Prozess im Arbeitsspeicher sperren und dadurch verhindern, dass er auf die Festplatte schreibt. Das kann dabei helfen, die Echtzeitfähigkeiten eines Clusters zu bewahren.

  Dieses Feature ist nach Voreinstellung deaktiviert.

• StopOnError

  Dieser Parameter zeigt an, ob ein ndbd-Prozess anhalten oder automatisch neu starten soll, wenn eine Fehlerbedingung auftritt.

  Dieses Feature ist nach Voreinstellung aktiviert.

• Diskless

  Wenn Tabellen im MySQL Cluster als diskless definiert werden, werden für sie weder Checkpoints auf der Festplatte noch Logeinträge erstellt. Solche Tabellen existieren nur im Hauptspeicher. Infolgedessen überleben weder die Tabellen selbst noch die in ihnen enthaltenen Datensätze einen Absturz. Allerdings können Sie im Diskless-Modus ndbd auch auf einem Computer ohne Festplatte ausführen.

  Wichtig: Dieses Feature lässt den gesamten Cluster im Diskless-Modus laufen.

  Wenn dieses Feature aktiviert ist, werden zwar Datensicherungen ausgeführt, aber keine wirklichen Sicherungsdaten gespeichert.

  Diskless ist nach Voreinstellung deaktiviert.

• RestartOnErrorInsert

  Dieses Feature ist nur beim Bauen der Debugversion zugänglich, wo es möglich ist, zu Testzwecken Fehler in die Ausführung einzelner Codeblöcke einzubauen.

  Dieses Feature ist nach Voreinstellung deaktiviert.

• TimeBetweenWatchDogCheck

  Damit der Haupt-Thread nicht in einer Endlosschleife gefangen bleiben kann, wird er durch einen so genannten „Wachhund“ (engl. Watchdog) überprüft. Dieser Parameter gibt an, wie viele Millisekunden zwischen den Prüfungen verstreichen. Wenn der Prozess nach drei Prüfungen immer noch in demselben Zustand verharrt, wird er vom Watchdog-Thread beendet.

  Dieser Parameter lässt sich leicht ändern, sei es zu experimentellen Zwecken oder um ihn an die lokalen Bedingungen anzupassen. Er kann auch für jeden Knoten separat gesetzt werden, wofür es allerdings keinen vernünftigen Grund gibt.

  Der Standard-Timeout-Wert beträgt 4.000 Millisekunden (4 Sekunden).

• StartPartialTimeout

  Dieser Parameter legt fest, wie lange der Cluster auf das Hochfahren aller Speicherknoten wartet, bevor die Initialisierungsroutine für den Cluster aufgerufen wird. Dieser Timeout-Wert soll nach Möglichkeit verhindern, dass ein Cluster nur teilweise hochgefahren wird.

  Der Standardwert beträgt 30.000 Millisekunden (30 Sekunden). Mit 0 wird der Timeout ausgeschaltet, sodass der Cluster nur starten kann, wenn alle Knoten zur Verfügung stehen.

• StartPartitionedTimeout

  Wenn der Cluster nach dem Abwarten von StartPartialTimeout Millisekunden startbereit ist, sich aber möglicherweise immer noch in einem partitionierten Zustand befindet, wartet er ab, bis auch dieser Timeout verstrichen ist.

  Der Standardwert für diesen Timeout beträgt 60.000 Millisekunden (60 Sekunden).

• StartFailureTimeout

  Wenn ein Datenknoten seine Startsequenz in der durch diesen Parameter gesetzten Zeit nicht abgeschlossen hat, scheitert sein Start. Wenn Sie den Parameter auf 0 setzen, gibt es keinen Timeout für den Datenknoten.

  Der Standardwert beträgt 60.000 Millisekunden (60 Sekunden). Für Datenknoten mit extrem großen Datenmengen sollten Sie diesen Parameter heraufsetzen. Wenn ein Speicherknoten beispielsweise mehrere Gigabytes an Daten enthält, könnten sogar 10 bis 15 Minuten (600.000 bis 1.000.000 Millisekunden) für einen Neustart des Knotens erforderlich sein.

• HeartbeatIntervalDbDb

  Heartbeats (Herzschläge) sind eines der wichtigsten Mittel, um herauszufinden, ob Knoten abgestürzt sind. Dieser Parameter zeigt an, wie oft Heartbeat-Signale gesandt und empfangen werden sollten. Wenn drei aufeinander folgende Heartbeats ausgefallen sind, wird der Knoten für tot erklärt. Also beträgt die maximale Zeitspanne für die Entdeckung eines Scheiterns mit dem Heartbeat-Mechanismus das Vierfache des Heartbeat-Intervalls.

  Das Standardintervall für Heartbeats dauert 1.500 Millisekunden (1,5 Sekunden). Dieser Parameter darf nicht drastisch verändert werden und sollte für alle Knoten ähnlich eingestellt werden. Wenn ein Knoten 5.000-Millisekunden-Intervalle und der beobachtende Knoten 1.000 Millisekunden verwendet, wird der mit den längeren Intervallen natürlich sehr schnell für tot erklärt. Dieser Parameter kann während eines Online-Softwareupgrades geändert werden, allerdings nur in kleinen Inkrementen.

• HeartbeatIntervalDbApi

  Jeder Datenknoten sendet Heartbeat-Signale an jeden MySQL Server (SQL-Knoten), um sich zu vergewissern, dass der Kontakt noch besteht. Wenn ein MySQL Server seinen Heartbeat nicht rechtzeitig absendet, wird er als „tot“ erklärt und alle seine laufenden Transaktionen werden beendet und seine Ressourcen freigegeben. Ein SQL-Knoten kann sich erst wieder verbinden, wenn alle von der vorherigen MySQL-Instanz angestoßenen Aktivitäten abgeschlossen wurden. Es gilt dasselbe Kriterium der drei Heartbeats wie unter HeartbeatIntervalDbDb beschrieben.

  Das Standardintervall beträgt 1.500 Millisekunden (1,5 Sekunden). Dieses Intervall kann zwischen einzelnen Datenknoten variieren, da jeder Speicherknoten die mit ihm verbundenen MySQL Server unabhängig von allen anderen Datenknoten beobachtet.

• TimeBetweenLocalCheckpoints

  Dieser Parameter ist insofern eine Ausnahmeerscheinung, als er nicht eine Wartezeit vor dem Starten eines neuen lokalen Checkpoints angibt, sondern gewährleisten soll, dass keine lokalen Checkpoints in einem Cluster ausgeführt werden, in dem nur relativ wenige Updates auftreten. In den meisten Clustern mit hohen Update-Raten wird ein neuer lokaler Checkpoint normalerweise unmittelbar nach Abschluss des vorherigen gestartet.

  Der Umfang aller seit dem Start des vorherigen lokalen Checkpoints ausgeführten Schreiboperationen wird addiert. Dieser Parameter ist ebenfalls außergewöhnlich, da er als Basis-2-Logarithmus der Anzahl der 4-Byte-Wörter spezifiziert ist. Der Standardwert von 20 bedeutet also Schreiboperationen im Umfang von 4 Mbyte (4 × 2²⁰), 21 würde 8 Mbyte bedeuten, und so weiter bis zum Maximalwert 31, der 8 Gbyte Schreiboperationen entsprechen würde.

  Alle Schreiboperationen im Cluster werden addiert. Wenn TimeBetweenLocalCheckpoints auf 6 oder weniger gesetzt wird, bedeutet dies, dass pausenlos lokale Checkpoints ausgeführt werden, unabhängig von der Arbeitslast des Clusters.

• TimeBetweenGlobalCheckpoints

  Wenn eine Transaktion committet wird, dann im Hauptspeicher in allen Knoten, auf denen die Daten gespiegelt werden. Doch die Transaktionslog-Einträge werden durch den Commit-Befehl nicht auf die Platte zurückgeschrieben. Denn wenn die Transaktion auf mindestens zwei autonomen Hostcomputern sicher committet wurde, müsste dies ausreichen, um die Haltbarkeit der Daten zu gewährleisten.

  Wichtig ist außerdem, dass das System auch im schlimmsten Fall, nämlich dem Absturz eines kompletten Clusters, die Oberhand behält. Um das zu gewährleisten, werden alle Transaktionen, die in einem gegebenen Zeitraum stattfinden, in einen globalen Checkpoint geladen. Diesen kann man sich als eine Menge von committeten und auf die Festplatte geschriebenen Transaktionen vorstellen. Mit anderen Worten: Transaktionen werden im Rahmen des Commit-Prozesses in eine globale Checkpoint-Gruppe gelegt. Später werden die Logeinträge dieser Gruppe auf die Festplatte zurückgeschrieben und die gesamte Transaktionsgruppe auf allen Computern im Cluster sicher auf die Festplatte geschrieben.

  Dieser Parameter legt das Zeitintervall zwischen den globalen Checkpoints fest. Der Standardwert beträgt 2.000 Millisekunden.

• TimeBetweenInactiveTransactionAbortCheck

  Um Timeouts zu behandeln, wird für jede Transaktion einmal pro in diesem Parameter angegebenem Intervall ein Timer nachgeschaut. Wenn also dieser Parameter auf 1.000 Millisekunden gesetzt ist, wird einmal pro Sekunde jede Transaktion auf einen Timeout überprüft.

  Der Standardwert beträgt 1.000 Millisekunden (1 Sekunde).

• TransactionInactiveTimeout

  Dieser Parameter gibt an, wie viel Zeit maximal zwischen zwei Operationen einer Transaktion verstreichen darf, ehe die Transaktion abgebrochen wird.

  Der Standardwert dieses Parameters ist null (kein Timeout). Für eine Echtzeitdatenbank, die gewährleisten muss, dass keine Transaktion irgendwelche Sperren zu lange aufrechterhält, sollte dieser Parameter auf einen sehr kleinen Wert gesetzt werden. Die Maßeinheit sind Millisekunden.

• TransactionDeadlockDetectionTimeout

  Wenn ein Knoten eine Abfrage ausführt, zu der eine Transaktion gehört, wartet er auf Antwort von den anderen Knoten des Clusters, ehe er fortfährt. Bleibt eine Antwort aus, kann das folgende Gründe haben:

  • Der Knoten ist „tot“.

  • Die Operation steckt in einer Warteschlange von Sperranforderungen.

  • Der Knoten, der die Aktion ausführen sollte, könnte heftig überlastet sein.

  Dieser Timeout-Parameter legt fest, wie lange der Transaktionskoordinator darauf wartet, dass ein anderer Knoten die Anfrage ausführt, ehe er die Transaktion abbricht. Er ist wichtig, um den Absturz eines Knotens behandeln oder Deadlocks feststellen zu können. Wenn Sie ihn zu hoch setzen, können Situationen mit gescheiterten Knoten oder Deadlocks unangenehme Konsequenzen haben.

  Der Standardwert für den Timeout beträgt 1.200 Millisekunden (1,2 Sekunden).

• NoOfDiskPagesToDiskAfterRestartTUP

  Wenn ein lokaler Checkpoint ausgeführt wird, schreibt der Algorithmus alle Datenseiten auf die Festplatte zurück. Wenn Sie dies aber einfach ohne irgendwelche Moderation so rasch wie möglich tun, riskieren Sie eine Überlastung von Prozessoren, Netzwerken und Platten. Um die Schreibgeschwindigkeit zu steuern, gibt dieser Parameter an, wie viele Seiten pro 100 Millisekunden geschrieben werden dürfen. In diesem Zusammenhang ist eine „Seite“ als 8 Kbyte definiert. Dieser Parameter wird in Einheiten von 80 Kbyte pro Sekunde angegeben; wenn Sie also NoOfDiskPagesToDiskAfterRestartTUP auf den Wert 20 setzen, werden bei einem lokalen Checkpoint 1,6 Mbyte an Datenseiten pro Sekunde auf die Platte geschrieben. Dieser Wert umfasst auch die Erstellung der UNDO-Logs für die Datenseiten. Folglich setzt dieser Parameter die Obergrenze für Schreibvorgänge aus dem Data Memory. Für die UNDO-Logeinträge für Indexseiten ist der Parameter NoOfDiskPagesToDiskAfterRestartACC da. (Mehr über Indexseiten können Sie im Eintrag IndexMemory nachlesen.)

  Kurz: Dieser Parameter gibt an, wie schnell lokale Checkpoints ausgeführt werden. Er arbeitet zusammen mit NoOfFragmentLogFiles, DataMemory und IndexMemory.

  Der Standardwert ist 40 (3,2 Mbyte Datenseiten pro Sekunde).

• NoOfDiskPagesToDiskAfterRestartACC

  Dieser Parameter verwendet dieselbe Maßeinheit wie NoOfDiskPagesToDiskAfterRestartTUP und verhält sich auch ganz ähnlich, setzt jedoch die Obergrenze für das Schreiben von Indexseiten aus dem Index Memory.

  Der Standardwert dieses Parameters beträgt 20 (1,6 Mbyte Index Memory pro Sekunde).

• NoOfDiskPagesToDiskDuringRestartTUP

  Dieser Parameter funktioniert ähnlich wie NoOfDiskPagesToDiskAfterRestartTUP und NoOfDiskPagesToDiskAfterRestartACC, allerdings im Hinblick auf lokale Checkpoints, die in einem Knoten bei dessen Neustart ausgeführt werden. Ein lokaler Checkpoint wird immer bei jeglichem Neustart eines Knotens ausgeführt. Während eines Knoten-Neustarts können Daten schneller als in anderen Situationen auf die Platte geschrieben werden, da zu diesem Zeitpunkt im Knoten noch weniger andere Aktivitäten stattfinden.

  Dieser Parameter bezieht sich auf die Seiten, die aus dem Data Memory geschrieben werden.

  Der Standardwert beträgt 40 (3,2 Mbyte pro Sekunde).

• NoOfDiskPagesToDiskDuringRestartACC

  Gibt an, wie viele Seiten des Index Memorys während des lokalen Checkpointings beim Neustart eines Knotens auf die Festplatte geschrieben werden können.

  Wie bei NoOfDiskPagesToDiskAfterRestartTUP und NoOfDiskPagesToDiskAfterRestartACC werden auch für diesen Parameter die Werte als 8-Kbyte-Seiten angegeben, die pro 100 Millisekunden geschrieben werden (80 Kbyte/Sekunde).

  Der Standardwert beträgt 20 (1,6 Mbyte pro Sekunde).

• ArbitrationTimeout

  Dieser Parameter legt fest, wie lange Datenknoten darauf warten sollen, dass der Arbitrator auf eine Arbitration-Nachricht antwortet. Wird dieser Wert überschritten, kann man davon ausgehen, dass sich das Netzwerk aufgespalten hat.

  Der Standardwert beträgt 1000 Millisekunden (1 Sekunde).

• UndoIndexBuffer

  Der UNDO-Indexpuffer, dessen Größe mit diesem Parameter eingestellt wird, wird während eines lokalen Checkpoints benutzt. Das Recovery-Schema der Speicher-Engine NDB beruht auf der Konsistenz der Checkpoints und einem funktionierenden REDO-Log. Um einen konsistenten Checkpoint zu erhalten, ohne gleich sämtliche Schreibvorgänge im System zu blockieren, ist während der Erstellung des lokalen Checkpoints das UNDO-Logging eingeschaltet. UNDO-Logging wird immer nur auf einem einzigen Tabellenfragment eingeschaltet. Diese Optimierung ist möglich, da die Tabellen vollständig im Hauptspeicher liegen.

  Der UNDO-Indexpuffer wird für die Änderungen am Primärschlüssel-Hash-Index benutzt. Einfügungen und Löschungen führen zu Umstellungen im Hash-Index. Die Speicher-Engine NDB schreibt UNDO-Logeinträge, die alle physikalischen Änderungen einer Indexseite zuordnen, sodass sie beim Systemstart rückgängig gemacht werden können. Außerdem protokolliert sie zu Beginn eines lokalen Checkpoints alle aktiven Einfügeoperationen für jedes Fragment.

  Lese- und Änderungsoperationen setzen Sperrbits und aktualisieren einen Header im Hash-Indexeintrag. Diese Änderungen behandelt der Page-Writing-Algorithmus so, dass sichergestellt ist, dass diese Operationen kein UNDO-Logging benötigen.

  Dieser Puffer ist nach Voreinstellung auf 2 Mbyte gesetzt. Sein Mindestwert 1 Mbyte dürfte für die meisten Anwendungen ausreichen. Für Anwendungen, die besonders große oder zahlreiche Einfüge- und Löschoperationen in Verbindung mit großen Transaktionen und umfangreichen Primärschlüsseln vornehmen, kann es erforderlich sein, diesen Puffer zu vergrößern. Wenn er zu klein ist, meldet die Speicher-Engine NDB den internen Fehlercode 677 (Index UNDO buffers overloaded).

• UndoDataBuffer

  Dieser Parameter stellt die Größe des UNDO-Datenpuffers ein, der ähnlich wie der UNDO-Indexpuffer funktioniert, aber für das Data Memory statt des Index Memorys verwendet wird. Dieser Puffer wird in der lokalen Checkpoint-Phase eines Fragments für Einfüge-, Lösch- und Änderungsoperationen benötigt.

  Da UNDO-Logeinträge immer größer werden, je mehr Operationen protokolliert werden, ist auch dieser Puffer größer als sein Gegenstück für das Index Memory, nämlich nach Voreinstellung 16 Mbyte.

  Dieser Speicher kann für manche Anwendungen unnötig groß sein. In solchen Fällen können Sie den Wert bis auf das Minimum von 1 Mbyte heruntersetzen.

  Es ist nur selten erforderlich, diesen Puffer zu vergrößern. Wenn es dennoch einmal getan werden muss, so sollten Sie vorher prüfen, ob Ihre Festplatten die Last der Updates in der Datenbank überhaupt bewältigen können. Wenn nicht genügend Platz auf der Festplatte vorhanden ist, können Sie dies auch durch das Vergrößern dieses Puffers nicht ändern.

  Wenn dieser Puffer zu klein ist und verstopft, meldet die Speicher-Engine NDB den internen Fehlercode 891 (Data UNDO buffers overloaded).

• RedoBuffer

  Auch alle Update-Aktivitäten müssen protokolliert werden. Das REDO-Log ermöglicht es, die Updates bei einem späteren Neustart des Systems erneut laufen zu lassen. Der Recovery-Algorithmus von NDB verwendet einen „Fuzzy“-Checkpoint der Daten in Verbindung mit dem UNDO-Log und wendet dann das REDO-Log an, um alle Änderungen bis zum Wiederherstellungspunkt erneut aufzuspielen.

  RedoBuffer stellt die Größe des Puffers ein, in den das REDO-Log geschrieben wird, und hat den Standardwert 8 Mbyte. Sein Mindestwert beträgt 1 Mbyte.

  Ist dieser Puffer zu klein, meldet die Speicher-Engine NDB den Fehlercode 1221 (REDO log buffers overloaded).

• LogLevelStartup

  Die Berichtsebene für Ereignisse, die beim Starten des Prozesses eintreten.

  Die Standardebene ist 1.

• LogLevelShutdown

  Die Berichtsebene für Ereignisse, die beim sanften Herunterfahren eines Knotens gemeldet werden.

  Die Standardebene ist 0.

• LogLevelStatistic

  Die Berichtsebene für statistische Ereignisse wie beispielsweise die Anzahl der Lesevorgänge auf Primärschlüsseln, die Anzahl der Änderungen oder Einfügungen, Informationen über die Pufferausnutzung und so weiter.

  Die Standardebene ist 0.

• LogLevelCheckpoint

  Die Berichtsebene für Ereignisse, die bei lokalen und globalen Checkpoints generiert werden.

  Die Standardebene ist 0.

• LogLevelNodeRestart

  Die Berichtsebene für Ereignisse, die beim Neustart eines Knotens generiert werden.

  Die Standardebene ist 0.

• LogLevelConnection

  Die Berichtsebene für Ereignisse, die von Verbindungen zwischen Cluster-Knoten generiert werden.

  Die Standardebene ist 0.

• LogLevelError

  Die Berichtsebene für Ereignisse, die von Fehlern und Warnungen vom Cluster insgesamt generiert werden. Diese Fehler bringen zwar nicht gleich einen Knoten zum Absturz, sind es aber dennoch wert, gemeldet zu werden.

  Die Standardebene ist 0.

• LogLevelInfo

  Die Berichtsebene für Ereignisse, die zur Information über den Allgemeinzustand des Clusters generiert werden.

  Die Standardebene ist 0.

• BackupDataBufferSize

  Bei der Erstellung einer Datensicherung werden zwei Puffer verwendet, um die Daten auf die Festplatte zu schreiben: Der Puffer für Sicherungsdaten (Backup Data-Puffer) nimmt Daten auf, die beim Scannen der Tabellen eines Knotens aufgezeichnet wurden. Wenn dieser Puffer bis zu dem in BackupWriteSize (siehe unten) angegebenen Stand gefüllt ist, werden die Seiten auf die Festplatte geschrieben. Während Daten auf die Platte zurückgeschrieben werden, kann der Datensicherungsprozess weiter diesen Puffer mit Daten füllen, bis ihm der Platz ausgeht. Wenn dies geschieht, macht der Sicherungsprozess eine Pause mit seinen Scans, bis einige Schreibvorgänge auf der Platte so weit abgeschlossen sind, dass Speicher freigegeben wurde und das Scannen fortgesetzt werden kann.

  Der Standardwert ist 2 Mbyte.

• BackupLogBufferSize

  Der Backup Log-Puffer spielt eine ähnliche Rolle wie der Backup Data-Puffer, wird jedoch verwendet, um ein Log aller während einer Datensicherung ausgeführten Schreibvorgänge auf Tabellen zu generieren. Diese Seiten werden nach demselben Prinzip wie bei der Datensicherung „Datenpuffer“ geschrieben, nur dass hier die Sicherung scheitert, wenn der Platz im Backup Log-Puffer ausgeht. Aus diesem Grund muss der Backup Log-Puffer unbedingt groß genug sein, um die von Schreibaktivitäten während der Datensicherung verursachte Belastung aushalten zu können. Siehe auch Abschnitt 16.6.5.4, „Konfiguration für Cluster-Backup“.

  Der Standardwert dieses Parameters müsste für die meisten Anwendungen ausreichen. Eine Sicherung scheitert eher schon einmal durch zu langsame Schreibvorgänge auf der Platte als durch einen vollen Backup Log-Puffer. Wenn das Festplatten-Teilsystem für die Last der von Anwendungen verursachten Schreibvorgänge unzureichend konfiguriert ist, kann auch der Cluster die gewünschten Operationen nicht ausführen.

  Cluster-Knoten sollten so konfiguriert werden, dass der Engpass eher im Prozessor liegt als in den Festplatten oder Netzwerkverbindungen.

  Der Standardwert ist 2 Mbyte.

• BackupMemory

  Dieser Parameter ist einfach die Summe von BackupDataBufferSize und BackupLogBufferSize.

  Der Standardwert ist 2 Mbyte + 2 Mbyte = 4 Mbyte.

• BackupWriteSize

  Dieser Parameter spezifiziert die Größe der Meldungen, die von den Backup Log- und Backup Data-Puffern auf die Festplatte geschrieben werden.

  Der Standardwert ist 32 Kbyte.

• Id

  Der Wert Id wird verwendet, um den Knoten in allen Cluster-internen Nachrichten zu identifizieren. Es ist ein Integer zwischen 1 und 63 einschließlich, der unter allen Knoten-IDs im Cluster einzigartig sein muss.

• ExecuteOnComputer

  Bezieht sich auf einen der Computer (Hosts), die in einem [COMPUTER]-Abschnitt der Konfigurationsdatei genannt sind.

• ArbitrationRank

  Dieser Parameter gibt an, welche Knoten als Arbitrator fungieren können. Sowohl MGM- als auch SQL-Knoten können Arbitrator sein. Der Wert 0 bedeutet, dass der betreffende Knoten nie Arbitrator sein kann, 1 gibt ihm die höchste Priorität als Arbitrator und 2 verleiht ihm eine niedrige Priorität. In einer normalen Konfiguration wird der Management-Server als Arbitrator eingesetzt, indem sein ArbitrationRank auf 1 (den Default) und die der SQL-Knoten auf 0 gesetzt werden.

• ArbitrationDelay

  Wird dieser Parameter auf irgendeinen anderen Wert als 0 (den Standardwert) gesetzt, so werden die Antworten des Arbitrators auf Arbitration-Requests um diese Anzahl Millisekunden verzögert. Normalerweise ist es nicht nötig, diesen Wert zu ändern.

• BatchByteSize

  Für Anfragen, die in vollständige Tabellenscans oder Indexbereichsscans übersetzt werden, ist es aus Performancegründen wichtig, die Datensätze in Stapeln (Batches) der richtigen Größe abzuholen. Diese richtige Größe kann man sowohl als eine Anzahl von Datensätzen (BatchSize) als auch in Bytes (BatchByteSize) einstellen. Die tatsächliche Batch-Größe wird von beiden Parametern eingeschränkt.

  Je nachdem, wie dieser Parameter eingestellt ist, kann die Geschwindigkeit von Anfragen um 40 Prozent variieren. In künftigen Releases wird MySQL Server anhand des Anfragetyps fundierte Annahmen über die Batch-Größe treffen.

  Dieser Parameter wird in Bytes angegeben und hat den Standardwert 32 Kbyte.

• BatchSize

  Dieser Parameter wird als Anzahl von Datensätzen angegeben und ist standardmäßig auf 64 eingestellt. Seine Maximalgröße beträgt 992.

• MaxScanBatchSize

  Die Batch-Größe ist die Größe jedes Batchs von jedem Datenknoten. Die meisten Scans werden parallel ausgeführt, damit der MySQL Server nicht von vielen Knoten parallel zu viele Daten übermittelt bekommt. Dieser Parameter setzt eine Obergrenze der gesamten Batch-Größe quer über alle Knoten.

  Standardmäßig ist dieser Parameter auf 256 Kbyte eingestellt; seine Maximalgröße beträgt 16 Mbyte.

• NodeId1, NodeId2

  Um eine Verbindung zwischen zwei Knoten zu identifizieren, müssen ihre Knoten-IDs im [TCP]-Abschnitt der Konfigurationsdatei angegeben werden. Dabei handelt es sich um dieselben eindeutigen Id-Werte für einzelne Knoten, wie in Abschnitt 16.4.4.6, „Festlegung von SQL-Nodes in einem MySQL Cluster“, beschrieben.

• SendBufferMemory

  TCP-Transporter speichern alle Nachrichten in einem Puffer, ehe sie den Sendeaufruf an das Betriebssystem starten. Wenn dieser Puffer 64 Kbyte erreicht, wird sein Inhalt übersandt; das Gleiche geschieht, wenn eine Runde Nachrichten ausgeführt worden ist. Um mit vorübergehenden Überlastungen umgehen zu können, ist es auch möglich, einen größeren Send-Puffer zu definieren. Seine Standardgröße beträgt 256 Kbyte.

• SendSignalId

  Um ein Diagramm mit verteilten Nachrichen nachvollziehen zu können, muss jede Nachricht genau identifiziert sein. Wenn dieser Parameter Y ist, werden die Message-IDs über das Netzwerk transportiert. In der Standardeinstellung ist dieses Feature ausgeschaltet.

• Checksum

  Dieser boolesche Parameter ist standardmäßig deaktiviert. (Um ihn zu aktivieren, setzen Sie ihn auf Y oder 1, um ihn zu deaktivieren, auf N oder 0.) Wird er aktiviert, so werden für alle Nachrichten, ehe sie in den Send-Puffer geladen werden, Prüfsummen berechnet. Dadurch wird gewährleistet, dass die Nachrichten nicht durch den Transportmechanismus oder beim Warten im Send-Puffer geschädigt werden.

• PortNumber (OBSOLET)

  Dieser Parameter gab früher einmal die Nummer des Ports an, auf dem das System nach Verbindungen anderer Knoten lauschte. Der Parameter sollte nicht mehr benutzt werden.

• ReceiveBufferMemory

  Gibt die Größe des Puffers zum Empfangen von Daten von dem TCP/IP-Socket an. Es ist kaum jemals erforderlich, den Standardwert von 64 Kbyte zu ändern, es sei denn, um Speicher zu sparen.

• NodeId1, NodeId2

  Um eine Verbindung zwischen zwei Knoten identifizieren zu können, müssen Sie für jeden von ihnen einen Knotenbezeichner verwenden, etwa NodeId1 und NodeId2.

• ShmKey

  Bei der Einrichtung von Shared Memory-Segmenten wird das für die Kommunikation zu verwendende Segment durch eine Knoten-ID (einen Integer) eindeutig identifiziert. Einen Standardwert gibt es nicht.

• ShmSize

  Jede SHM-Verbindung hat ein Shared Memory-Segment, in welchem die Nachrichten zwischen den Knoten vom Absender gespeichert und vom Empfänger gelesen werden. Die Größe dieses Segments wird durch ShmSize festgelegt und beträgt nach Voreinstellung 1 Mbyte.

• SendSignalId

  Um den Pfad einer verteilten Nachricht zurückverfolgen zu können, benötigt jede Nachricht einen eindeutigen Bezeichner. Wird dieser Parameter auf Y gesetzt, werden auch Message-IDs über das Netzwerk transportiert. Nach Voreinstellung ist dieses Feature deaktiviert.

• Checksum

  Dieser boolesche Parameter ist standardmäßig ausgeschaltet (er kann Y oder N sein). Wird er eingeschaltet, werden für alle Nachrichten Prüfsummen berechnet, ehe sie in den Puffer gelegt werden.

  Dieses Feature verhindert, dass Nachrichten beschädigt werden, während sie im Puffer warten. Außerdem wirkt es als Versicherung gegen Datenkorruption auf dem Transportweg.

• NodeId1, NodeId2

  Um eine Verbindung zwischen zwei Knoten genau identifizieren zu können, müssen beide Knoten einen Bezeichner haben, etwa NodeId1 und NodeId2.

• Host1SciId0

  Die SCI-Knoten-ID für den ersten Cluster-Knoten (den mit der Bezeichnung NodeId1).

• Host1SciId1

  Man kann SCI Transporter zur Ausfallsicherung zwischen zwei SCI-Karten einsetzen, die dann allerdings separate Netzwerke zwischen den Knoten verwenden sollten. Dieser Parameter definiert die Knoten-ID und die zweite SCI-Karte für den ersten Knoten.

• Host2SciId0

  Dieser Parameter identifiziert die SCI-Knoten-ID für den zweiten Cluster-Knoten (den mit der Bezeichnung NodeId2).

• Host2SciId1

  Wenn zur Ausfallsicherung zwei SCI-Karten eingesetzt werden, identifiziert dieser Parameter die zweite SCI-Karte für den zweiten Knoten.

• SharedBufferSize

  Jeder SCI Transporter hat ein Shared Memory-Segment für die Kommunikation zwischen den Knoten. Für die meisten Anwendungen müsste es ausreichen, die Größe dieses Segments auf dem Standardwert 1 Mbyte zu belassen. Ein kleinerer Wert kann bei vielen parallelen Einfügeoperationen Probleme verursachen; wenn der Shared Buffer zu klein ist, kann überdies der gesamte ndbd-Prozess abstürzen.

• SendLimit

  Ein kleiner Puffer vor den SCI-Medien speichert Nachrichten, ehe sie über das SCI-Netzwerk verschickt werden. Nach Voreinstellung ist er 8 Kbyte groß. Unsere Benchmarks weisen zwar die beste Performance bei 64 Kbyte aus, aber 16 Kbyte kommen schon bis auf wenige Prozente an diesen Höchstwert heran, und es gibt wenig Anlass, über den Wert von 8 Kbyte hinauszugehen.

• SendSignalId

  Um eine verteilte Nachricht zurückverfolgen zu können, benötigt jede Nachricht einen eindeutigen Bezeichner. Wird dieser Parameter auf Y gesetzt, werden auch Message-IDs über das Netzwerk transportiert. Nach Voreinstellung ist dieses Feature deaktiviert.

• Checksum

  Dieser boolesche Parameter ist standardmäßig deaktiviert. Wird Checksum aktiviert, so werden für alle Nachrichten, ehe sie in den Send-Puffer geladen werden, Prüfsummen berechnet. Dadurch wird gewährleistet, dass die Nachrichten nicht durch den Transportmechanismus oder beim Warten im Send-Puffer geschädigt werden.

• --ndb-connectstring=connect_string

  Wenn die Speicher-Engine NDB Cluster benutzt wird, gibt diese Option an, welcher Management-Server die Daten für die Cluster-Konfiguration verteilt.

• --ndbcluster

  Die Speicher-Engine NDB Cluster ist für die Benutzung von MySQL Cluster erforderlich. Wenn eine mysqld-Binary die Speicher-Engine NDB Cluster unterstützt, ist diese Engine nach Voreinstellung deaktiviert. Mit der Option --ndbcluster wird sie aktiviert und mit --skip-ndbcluster explizit deaktiviert.

• --daemon, -d

  Lässt ndbd als Daemon-Prozess laufen. Dies ist das Standardverhalten. Die Option --nodaemon kann verwendet werden, wenn der Prozess nicht als Daemon laufen soll.

• --initial

  Lässt ndbd einen Initialstart durchführen. Beim Initialstart werden alle Dateien gelöscht, die von früheren ndbd-Instanzen zu Wiederherstellungszwecken angelegt wurden. Außerdem rekonstruiert diese Option die Recovery-Logdateien. Beachten Sie, dass dieser Prozess auf manchen Betriebssystemen viel Zeit braucht.

  Ein --initial-Start soll nur beim allerersten Hochfahren des ndbd-Prozesses ausgeführt werden, da er alle Dateien aus dem Cluster-Dateisystem löscht und alle Recovery-Logdateien wiederherstellt. Von dieser Regel gibt es zwei Ausnahmen:

  • Ein Softwareupgrade, bei dem Dateiinhalte geändert worden sind.

  • Der Neustart eines Knotens mit einer neuen Version von ndbd.

  • Als letztes Mittel, wenn aus irgendeinem Grund der Neustart eines Knotens oder des Systems immer wieder scheitert. In diesem Fall müssen Sie jedoch berücksichtigen, dass der Knoten nun nicht mehr zur Wiederherstellung von Daten taugt, da seine Datendateien zerstört wurden.

  Diese Option wirkt sich auf keine Sicherungsdateien aus, die von dem betroffenen Knoten bereits erzeugt worden sind.

• --nodaemon

  Veranlasst, dass ndbd nicht als Daemon-Prozess startet. Dies ist nützlich, wenn Sie ndbd debuggen und die Ausgabe auf den Bildschirm umleiten möchten.

• --nostart

  Lässt ndbd nicht automatisch starten. Wenn diese Option benutzt wird, verbindet sich ndbd mit dem Management-Server, holt sich von diesem Konfigurationsdaten und initialisiert Kommunikationsobjekte. Die Ausführung wird jedoch erst dann gestartet, wenn der Management-Server es ausdrücklich verlangt, indem er dem Management-Client einen ausdrücklichen Befehl dafür gibt.

• --config-file=file_name, -f file_name,

  Sagt dem Management-Server, welches seine Konfigurationsdatei ist. Diese Option muss gesetzt werden; ihr Standardwert ist config.ini.

  Achtung: Diese Option kann auch als -c file_name angegeben werden, aber diese Abkürzung ist veraltet und soll nicht in neueren Installationen verwendet werden.

• --daemon, -d

  Lässt ndb_mgmd als Daemon-Prozess starten. Dies ist das Standardverhalten.

• --nodaemon

  Lässt ndb_mgmd nicht als Daemon-Prozess starten.

• --try-reconnect=number

  Wenn die Verbindung zum Management-Server abbricht, versucht der Knoten alle 5 Sekunden, sich erneut zu verbinden, bis er damit Erfolg hat. Mit dieser Option können Sie die Anzahl der Verbindungsversuche auf number begrenzen. Danach gibt der Knoten auf und meldet einen Fehler.

• CLUSTERLOG ON

  Schaltet das Cluster-Log ein.

• CLUSTERLOG OFF

  Schaltet das Cluster-Log aus.

• CLUSTERLOG INFO

  Gibt Informationen über die Einstellungen des Cluster-Logs.

• node_id CLUSTERLOG category=threshold

  Protokolliert category-Ereignisse mit einer Priorität kleiner oder gleich threshold im Cluster-Log.

• CLUSTERLOG FILTER severity_level

  Schaltet Cluster-Logging von Ereignissen des angegebenen severity_level ein oder aus.

• Metadaten: die Namen und Definitionen aller Datenbanktabellen

• Tabellendatensätze: die Daten, die in den Datenbanktabellen zum Zeitpunkt der Datensicherung tatsächlich gespeichert waren

• Transaktionslog: ein sequenzieller Logeintrag, der Ihnen sagt, wie und wann Daten in der Datenbank gespeichert wurden

• BACKUP-backup_id.node_id.ctl

  Eine Steuerungsdatei mit Steuerungsinformationen und Metadaten. Jeder Knoten speichert dieselben Tabellendefinitionen (für alle Tabellen im Cluster) in seiner eigenen Version dieser Datei.

• BACKUP-backup_id-0.node_id.data

  Eine Datendatei mit den Tabellendaten, die pro Fragment gespeichert werden. Das bedeutet, dass verschiedene Knoten während der Datensicherung verschiedene Fragmente speichern. Die Datei eines Knotens fängt immer mit einem Header an, auf dem die Tabelle steht, zu welcher die Datensätze gehören. Nach der Liste der Datensätze folgt ein Footer mit einer Prüfsumme für alle Datensätze.

• BACKUP-backup_id.node_id.log

  Eine Logdatei mit Datensätzen von committeten Transaktionen. Nur Transaktionen auf Tabellen, die in der Sicherung gespeichert sind, werden im Log festgehalten. Die gesicherten Knoten speichern unterschiedliche Datensätze, da unterschiedliche Knoten unterschiedliche Datenbankfragmente hosten.

• BackupDataBufferSize

  Gibt an, wie viel Arbeitsspeicher für das Puffern von Daten zur Verfügung steht, ehe diese auf die Platte geschrieben werden.

• BackupLogBufferSize

  Gibt an, wie viel Arbeitsspeicher für das Puffern von Logeinträgen zur Verfügung steht, ehe diese auf die Platte geschrieben werden.

• BackupMemory

  Gibt an, wie viel Arbeitsspeicher in einem Datenbankknoten insgesamt für Datensicherungen reserviert ist. Dieser Wert sollte die Summe des zugewiesenen Speichers für Backup-Datenpuffer plus Backup-Logpuffer sein.

• BackupWriteSize

  Die Blockgröße, in der Daten auf die Platte geschrieben werden. Gilt sowohl für Backup-Datenpuffer als auch für Backup-Logpuffer.