Skip navigation links
16.5.3 ndb_mgmd, le serveur de gestion »
Section Navigation      [Toggle]

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

Avant MySQL version 4.1.5, le processus ndbd se lancerait dans un dossier différent. La raison à cela est que ndbd génère son propre jeu de log dans le dossier de démarrage.

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

Ces fichiers de logs sont les suivants (le 2 est l'identifiant de noeud).

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

Il est recommandé de ne pas utiliser de dossier monté en NFS car dans certains environnement, il y a des problèmes de verrouillages sur le fichier de PID, même si le processus s'est arrêté.

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"

Lorsque ndbd se lance, il va lancer en fait 2 processus. Le processus de lancement s'appelle "angel" et sa seule tâche est de surveiller la fin du processus d'exécution, et de relancer le processus ndbd s'il est configuré pour cela. Par conséquent, si vous tentez de terminer ndbd avec la commande kill d'Unix, il sera nécessaire de terminer les deux processus. Une solution plus élégante pour gérer la terminaison des processus ndbd est d'utiliser le client de gestion et d'arrêter les processus depuis ce client.

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.

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.