Skip navigation links
16.4.4.6 Festlegung von SQL-Nodes in einem MySQL Cluster »
Section Navigation      [Toggle]

16.4.4.5. Festlegen von MySQL Cluster-Datenknoten

Im Abschnitt [NDBD] wird das Verhalten der Datenknoten des Clusters konfiguriert. Es gibt eine Vielzahl Parameter für die Größen von Puffern und Pools, für Timeout-Werte und so weiter. Die einzigen obligatorischen Parameter sind:

  • entweder ExecuteOnComputer oder HostName

  • der Parameter NoOfReplicas

Diese obligatorischen Parameter müssen im Abschnitt [NDBD DEFAULT] definiert werden.

Die meisten Parameter für Datenknoten werden im Abschnitt [NDBD DEFAULT] gesetzt. Nur die Parameter, von denen explizit gesagt wird, dass sie lokale Werte einstellen können, dürfen im [NDBD]-Abschnitt geändert werden. HostName, Id und ExecuteOnComputer müssen unbedingt im lokalen [NDBD]-Abschnitt definiert sein.

Datenknoten identifizieren

Der Wert Id (der Datenknoten-Bezeichner) kann entweder auf der Kommandozeile beim Starten des Knotens oder in der Konfigurationsdatei zugewiesen werden.

An jeden Parameter kann als Suffix K, M oder G angehängt werden, um Einheiten von 1.024, 1.024 × 1.024 oder 1.024 × 1.024 × 1.024 anzugeben. (So bedeutet beispielsweise 100K 100 × 1.024 = 102.400.) In Parameternamen und -werten wird zwischen Groß- und Kleinschreibung unterschieden.

  • 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.)

Data Memory und Index Memory

DataMemory und IndexMemory sind [NDBD]-Parameter, in denen die Größe der Speichersegmente festgelegt wird, welche die tatsächlichen Datensätze und ihre Indizes speichern. Für die Einstellung dieser Parameter müssen Sie unbedingt wissen, wie DataMemory und IndexMemory verwendet werden, da diese Werte normalerweise an die tatsächliche Speichernutzung des Clusters angepasst werden müssen:

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

Das folgende Beispiel zeigt, wie Speicher für eine Tabelle zugewiesen wird. Betrachten Sie folgende Tabellendefinition: 

CREATE TABLE example (
  a INT NOT NULL,
  b INT NOT NULL,
  c INT NOT NULL,
  PRIMARY KEY(a),
  UNIQUE(b)
) ENGINE=NDBCLUSTER;

Für jeden Datensatz sind 12 Byte Daten plus 12 Byte Overhead zugewiesen. Wenn keine Spalten dabei sind, die Nullwerte annehmen können, so spart dies 4 Byte Overhead. Außerdem gibt es auf den Spalten a und b zwei geordnete Indizes, die jeweils ungefähr 10 Byte pro Datensatz belegen. Auf der Basistabelle ist ein Primärschlüssel-Hash-Index definiert, der rund 29 Byte pro Datensatz beansprucht. Der Unique-Constraint ist durch eine separate Tabelle implementiert, die b als Primärschlüssel und a als eine Spalte verwendet. Diese andere Tabelle belegt weitere 29 Byte Indexspeicher pro Datensatz in der example-Tabelle zuzüglich 8 Byte für die Datensatzdaten und 12 Byte für den Overhead.

Also benötigen wir für eine Million Datensätze 58 Mbyte für den Indexspeicher, um die Hash-Indizes für den Primärschlüssel und den Unique-Constraint unterbringen zu können. Außerdem benötigen wir 64 Mbyte für die Datensätze der Basistabelle und die Tabelle mit dem eindeutigen Index plus die beiden Tabellen mit dem geordneten Index.

Wie Sie sehen, belegen Hash-Indizes nicht eben wenig Speicherplatz, bieten aber als Ausgleich einen sehr schnellen Datenzugriff. In MySQL Cluster werden sie außerdem für Unique-Constraints verwendet.

Gegenwärtig ist Hashing der einzige Partitionierungsalgorithmus und geordnete Indizes sind lokal für jeden Knoten. Also können geordnete Indizes im Allgemeinen nicht für die Handhabung von Unique-Constraints eingesetzt werden.

Ein wichtiger Punkt sowohl für das IndexMemory als auch für das DataMemory ist der, dass die Gesamtgröße der Datenbank die Summe sämtlicher Daten- und Indexspeicher für jede Knotengruppe ist. Da alle Knotengruppen verwendet werden, um replizierte Informationen zu speichern, kommen bei vier Knoten mit zwei Replikas zwei Knotengruppen zustande. Also stehen jedem Datenknoten insgesamt 2 × DataMemory an Datenspeicher zur Verfügung.

Das DataMemory und das IndexMemory sollten unbedingt für alle Knoten auf denselben Wert eingestellt werden. Da die Daten über alle Knoten im Cluster gleichmäßig verteilt sind, kann für jeden Knoten im Cluster maximal nur so viel Speicher zur Verfügung stehen wie für den kleinsten Knoten im Cluster.

Die Werte für DataMemory und IndexMemory können zwar geändert werden, doch ist es riskant, einen von beiden herunterzusetzen: Wenn Sie dies tun, kann es leicht passieren, dass ein Knoten oder sogar der gesamte MySQL Cluster aus Mangel an Arbeitsspeicher nicht mehr starten kann. Das Heraufsetzen dieser Werte ist zwar schon eher akzeptabel, aber solche Upgrades sollten ebenso wie jeder Softwareupgrade durchgeführt werden: Zuerst wird die Konfigurationdatei geändert, dann der Management-Server neu hochgefahren und zum Schluss werden nacheinander alle Datenknoten gestartet.

Durch Updates wird nicht mehr Indexspeicherplatz belegt. Einfügungen treten sofort in Kraft, aber Löschungen von Zeilen werden erst dann tatsächlich wirksam, wenn die Transaktion committed wird.

Transaktionsparameter

Die nächsten drei [NDBD]-Parameter sind wichtig, weil sie die Anzahl der Paralleltransaktionen und die Größe der Transaktionen festlegen, die das System bewältigen kann. MaxNoOfConcurrentTransactions stellt ein, wie viele parallele Transaktionen in einem Knoten möglich sind. MaxNoOfConcurrentOperations sagt, wie viele Datensätze gleichzeitig geändert oder gesperrt werden können.

Beide Parameter (besonders MaxNoOfConcurrentOperations) werden von den meisten Anwendern an ihre spezifischen Anforderungen angepasst und nicht auf den Standardwerten belassen. Der Standardwert ist auf Systeme ausgelegt, die nur kleine Transaktionen fahren, um zu gewährleisten, dass diese nicht übermäßig Speicher belegen.

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

Temporärer Speicher für Transaktionen

Die nächste Gruppe von [NDBD]-Parametern entscheidet über die temporäre Speicherung, die zur Ausführung einer Anweisung in einer Cluster-Transaktion verwendet wird. Alle Datensätze werden freigegeben, wenn die Anweisung abgeschlossen ist und der Cluster auf den Commit- oder Rollback-Befehl wartet.

Die Standardwerte für diese Parameter sind für die meisten Situationen passend. Wenn Sie jedoch Transaktionen auf sehr vielen Zeilen oder mit sehr vielen Operationen ausführen müssen, müssen Sie diese Werte eventuell heraufsetzen, um eine bessere Parallelverarbeitung im System zu ermöglichen. Sollten Ihre Transaktionen dagegen relativ klein sein, so können Sie durch Reduzieren dieser Werte Speicherplatz sparen.

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

Scans und Datenpuffer

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.

Logging und Checkpointing

Die folgenden [NDBD]-Paramater steuern das Verhalten in Bezug auf Logs und Checkpoints.

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

Metadatenobjekte

Die folgenden [NDBD]-Parameter legen die Größen der Pools für Metadatenobjekte fest, also wie viele Attribute, Tabellen, Indizes und Trigger-Objekte maximal für die Indizes, Ereignisse und Replikation zwischen Clustern zur Verfügung stehen. Beachten Sie, dass diese Werte lediglich „Richtwerte“ für den Cluster sind. Werden sie nicht gesetzt, so treten die unten angegebenen Standardwerte in Kraft.

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

Boolesche Parameter

Das Verhalten der Datenknoten hängt auch von einigen booleschen [NDBD]-Parametern ab. Um diese Parameter auf TRUE einzustellen, setzen Sie sie auf 1 oder Y, und um sie auf FALSE einzustellen, setzen Sie sie auf 0 oder N.

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

Timeouts, Intervalle und Auslagerung von Daten auf die Festplatte

Mehrere [NDBD]-Parameter stehen zur Verfügung, um Timeouts und Intervalle zwischen verschiedenen Aktionen in Cluster-Datenknoten festzulegen. Die Timeout-Werte werden, sofern nicht explizit etwas anderes gesagt wird, in Millisekunden angegeben.

  • 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 × 220), 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).

Buffering und Logging

Es stehen auch mehrere [NDBD]-Konfigurationsparameter zur Verfügung, die den früheren Compile-Time-Parametern entsprechen. Mit ihnen kann der fortgeschrittene Anwender die von Knotenprozessen genutzten Ressourcen besser steuern und diverse Puffergrößen seinen Bedürfnissen anpassen.

Diese Puffer werden als Frontends für das Dateisystem verwendet, wenn Logeinträge auf die Platte geschrieben werden. Wenn der Knoten im Diskless-Modus läuft, können diese Parameter ungestraft auf ihre Mindestwerte gesetzt werden, da die Dateisystem-Abstraktionsschicht der Speicher-Engine NDB das Schreiben auf der Festplatte „vorgaukelt“.

  • 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).

Für das Cluster-Management ist es sehr wichtig, die Anzahl der Logmeldungen steuern zu können, die für verschiedene Ereignistypen an stdout gesandt werden. Für jede Art von Ereignis gibt es 16 mögliche Berichtsebenen (mit den Nummern 0 bis 15). Wird die Berichtsebene für eine gegebene Ereigniskategorie auf 15 gesetzt, so bedeutet dies, dass alle Ereignisberichte dieser Kategorie an stdout geschickt werden; wird es auf 0 gesetzt, so werden in dieser Kategorie keine Ereignisse gemeldet.

Nach Voreinstellung wird nur die Startnachricht an stdout geschickt, während die übrigen Ereignisberichtsebenen auf 0 gesetzt sind. Der Grund: Diese Meldungen werden auch an das Cluster-Log des Management-Servers geschickt.

Dieselben Ebenen können Sie auch für den Management-Client einstellen, um festzulegen, welche Ereignisebenen im Cluster-Log protokolliert werden.

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

Sicherungsparameter

In diesem Abschnitt geht es um [NDBD]-Parameter zur Definition von Speicherpuffern für die Ausführung von Online-Sicherungen.

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

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.