Skip navigation links
MySQL 5.1 Referenzhandbuch :: 16 MySQL Cluster :: 16.5 Prozessverwaltung in MySQL Cluster :: 16.5.2 ndbd, der Speicher-Engine-Node-Prozess
16.5.3 ndb_mgmd, der Management-Server-Prozess »
Section Navigation      [Toggle]

16.5.2. ndbd, der Speicher-Engine-Node-Prozess

ndbd ist der Prozess, der alle Tabellendaten behandelt, die mit der Speicher-Engine NDB Cluster gespeichert sind. Dieser Prozess kann einen Speicherknoten auch in die Lage versetzen, verteilte Transaktionen, Knoten-Recovery, Checkpointing auf der Festplatte, Online-Sicherung und ähnliche Aufgaben zu erfüllen.

In einem MySQL Cluster kümmern sich mehrere ndbd-Prozesse gemeinsam um die Behandlung der Daten. Diese Prozesse können auf demselben Computer/Host oder auf verschiedenen Computern ausgeführt werden. Die Beziehungen zwischen Datenknoten und Cluster-Hosts ist komplett konfigurierbar.

ndbd generiert einige Logdateien, die in einem im DataDir-Abschnitt der Konfigurationsdatei config.ini genannten Verzeichnis abgelegt werden. Diese Logdateien sind unten aufgeführt. Beachten Sie, dass node_id der eindeutige Bezeichner des Knotens ist. So ist beispielsweise ndb_2_error.log das Fehlerlog, das der Speicherknoten mit der Knoten-ID 2 generiert.

  • ndb_node_id_error.log ist eine Datei mit Aufzeichnungen aller Crashes, die dem angegebenen ndbd-Prozess begegnet sind. Jeder Datensatz in dieser Datei enthält einen kurzen Fehler-String und eine Referenz auf eine Trace-Datei für den betreffenden Crash. Ein typischer Eintrag könnte folgendermaßen aussehen: 

    Date/Time: Saturday 30 July 2004 - 00:20:01
Type of error: error
Message: Internal program error (failed ndbrequire)
Fault ID: 2341
Problem data: DbtupFixAlloc.cpp
Object of reference: DBTUP (Line: 173)
ProgramName: NDB Kernel
ProcessID: 14909
TraceFile: ndb_2_trace.log.2
***EOM***

    Hinweis: Sie müssen immer daran denken, dass der letzte Eintrag in der Fehlerlogdatei nicht unbedingt der neueste ist (das wäre sogar höchst unwahrscheinlich). Eintragungen im Fehlerlog sind nicht chronologisch, sondern spiegeln die Reihenfolge der Trace-Dateien wider, wie sie in der Datei ndb_node_id_trace.log.next (siehe unten) festgelegt ist. Daher werden Fehlerlogeinträge zyklisch und nicht sequenziell überschrieben.

  • ndb_node_id_trace.log.trace_id ist eine Trace-Datei, die genau beschreibt, was unmittelbar vor Eintreten des Fehlers geschah. Diese Information ist nützlich für die Analysen des MySQL Cluster-Entwicklungsteams.

    Sie können konfigurieren, wie viele von diesen Trace-Dateien erzeugt werden, ehe die alten überschrieben werden. trace_id ist eine Zahl, die mit jeder sukzessiven Trace-Datei um eins erhöht wird.

  • Die Datei ndb_node_id_trace.log.next behält im Auge, welche Trace-Datei-Nummer als Nächste zugewiesen wird.

  • Die Datei ndb_node_id_out.log enthält die Datenausgabe des ndbd-Prozesses. Diese Datei wird nur angelegt, wenn ndbd als Daemon gestartet wird.

  • Die Datei ndb_node_id.pid enthält die Prozess-ID des ndbd-Prozesses, wenn dieser als Daemon gestartet wird. Sie fungiert auch als Sperrdatei, damit keine Knoten mit demselben Bezeichner gestartet werden.

  • Die Datei ndb_node_id_signal.log ist nur in Debugversionen von ndbd vorhanden, wo es möglich ist, alle ein- und ausgehenden sowie internen Nachrichten mit ihren Daten im ndbd-Prozess nachzuvollziehen.

Bitte verwenden Sie kein mit NFS gemountetes Verzeichnis, da dies in manchen Umgebungen Probleme verursachen kann, wobei die Sperre auf der .pid-Datei auch nach dem Ende des Prozesses in Kraft bleibt.

Um ndbd starten zu können, ist es unter Umständen notwendig, den Hostnamen des Management-Servers und den Port anzugeben, auf dem er lauscht. Optional können Sie auch die ID des Knotens angeben, den der Prozess benutzen soll. 

shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"

Mehr zu diesem Thema finden Sie unter Abschnitt 16.4.4.2, „MySQL Cluster: connectstring“. Abschnitt 16.5.5, „Befehlsoptionen für MySQL Cluster-Prozesse“, beschreibt weitere Optionen für ndbd.

Wenn der ndbd-Prozess startet, werden in Wirklichkeit zwei Prozesse initiiert: Der erste heißt „Engelprozess“ und hat nur die Aufgabe, zu entdecken, wenn die Ausführung des Prozesses beendet ist, und dann den ndbd-Prozess neu zu starten, wenn er so konfiguriert ist. Wenn Sie also versuchen, ndbd mit dem Unix-Befehl kill anzuhalten, müssen Sie beide Prozesse anhalten, und zwar den Engelprozess als ersten. Einen ndbd-Prozess stoppen Sie am besten, indem Sie den Management-Client benutzen, um den Prozess von dort aus anzuhalten.

Der Ausführungsprozess verwendet nur einen einzigen Thread für das Lesen, Schreiben und Scannen der Daten sowie alle anderen Aktivitäten. Dieser Thread ist asynchron implementiert, damit er Tausende von nebenläufigen Aktivitäten leicht bewältigen kann. Zusätzlich überwacht ein Wachhund-Thread diesen Ausführungs-Thread, um sicherzustellen, dass dieser nicht in einer Endlosschleife stecken bleibt. Ein Pool von Threads kümmert sich um die Dateiein- und -ausgaben, wobei jeder Thread für eine geöffnete Datei zuständig ist. Auch die Transporter im ndbd-Prozess können für ihre Transporterverbindungen Threads nutzen. In einem System, das viele Operationen - darunter auch Updates - ausführt, kann der ndbd-Prozess bis zu 2 CPUs mit Beschlag belegen, wenn ihm dies erlaubt ist. Auf einem Mehrprozessorcomputer ist es empfehlenswert, mehrere ndbd-Prozesse für die verschiedenen Knotengruppen zu verwenden.

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.