17.4.2 'ndbd' , le processus de stockage du cluster

'ndbd' est le processus qui gère les données dans les tables basées sur lem oteur NDB Cluster. C'est ce processus qui contient la logique de gestion des transactions distribuées, la restauration des noeuds, la pose des jalons sur le disque, la sauvegarde en ligne, et de nombreuses autres fonctionnalités.

Dans un cluster, il y a un groupe de processus 'ndbd' qui coopèrent pour gérer les données. Ces processus peuvent s'exécuter sur la même machine ou sur des ordinateurs différents, de manière complètement configurable.

Depuis MySQL 4.1.5, cela a été modifié pour que les fichiers soient placés dans un dossier spécifié par DataDir dans le fichier de configuration. 'ndbd' peut maintenant être lancé depuis n'importe où.

• ndb_2_error.log (anciennement error.log en version 4.1.3) est le fichier qui contient les informations sur tous les plantages que 'ndbd' a rencontré, et un message d'erreur court ainsi qu'un référence vers le fichier de trace pour le dernier crash. Une telle ligne peut être :

  Date/Time: Saturday 31 January 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***

• ndb_2_trace.log.1 (anciennement NDB_TraceFile_1.trace en version 4.1.3) est un fichie de trace, décrivant exactement ce qui est arrivé avant l'erreur. Cette information est utile pour l'équipe d'administration du cluster MySQL. Les informations de ce fichier sont décrites dans la section MySQL Cluster Troubleshooting . Le nombre de fichier de trace est configurable, de manière a maîtriser l'écrasement des anciens fichiers par les nouveaux. 1, dans ce contexte, est le numéro du fichier de trace.
• ndb_2_trace.log.next (anciennement NextTraceFileNo.log en version 4.1.3) est le fichier qui garde trace du prochain numéro de fichier de trace.
• ndb_2_out.log est le fichier qui contient les données affichées par le processus 'ndbd' . 2, dans ce contexte, est l'identifiant de noeued. Ce fichier n'existe que si 'ndbd' est lancé en mode démon, ce qui est le défaut en 4.1.5; anciennement node2.out en version 4.1.3)
• ndb_2.pid est le fichier qui contient l'identifiant de processus lorsque ndbd est lancé en mode démon (c'est le comportement par défaut depuis la version 4.1.5 et s'appellait node2.pid en version 4.1.3). Il fonctionne aussi comme un verrou, pour éviter de lancer des noeuds avec le même identifiant.
• ndb_2_signal.log (anciennement Signal.log en version 4.1.3) est le fichier qui ne sert que pour les versions de déguage de 'ndbd' : il est alors possible de suivre les messages entrants, sortants et internes dans le processus 'ndbd' .

De même, lorsque vous lancez le processus 'ndbd' , il peut être nécessaire de spécifier le nom d'hôte du serveur de gestion ainsi que son port. Optionnellement, il faut aussi ajouter le numéro d'identification de noeud. Encore une fois, il y a trois façons de spécifier ces informations. Soit une chaîne de connexion qui doit être stockée dans le fichier Ndb.cfg , et ce fichier doit être stocké dans le dossier de démarrage de 'ndbd' . La seconde option est de configurer la variable d'environnement NDB_CONNECTSTRING avant le démarrage du processus. La troisième option est d'utiliser la ligne de commande et l'option ci-dessous. Voyez les sections précédentes pour connaître le format exact de la chaîne.

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

Le processus d'exécution utilise un thread pour toute ses activités de lecture, écriture et analyse des données, ainsi que pour ses autres activités. Ce thread est conçu pour être asynchrone, et gérer facilement des milliers d'actions simultanées. En plus, il y a un garde-fou qui supervise le thread d'exécution, pour s'assurer que ce dernier ne se bloque pas dans une boucle infinie ou dans un autre problème du même genre. Il y a un pool de thread qui assurent les entrées/sorties. Chaque thread gère un fichier. En plus, d'autres threads peuvent être utilisés pour les activités de transport du processus 'ndbd' . Par conséquent, un processus qui effectue un grand nombre d'activités, verra le processus 'ndbd' utiliser 2 processeurs, s'il en a la possibilité. Sur une machine avec de nombreux processeurs, il est recommandé d'utilsier plusieurs processus 'ndbd' , qui seront configurés pour représente différents groupes de noeuds.