Skip navigation links
MySQL 5.0 Reference Manual :: 16 MySQL Cluster :: 16.5 Gestión de procesos en MySQL Cluster :: 16.5.2 ndbd, el proceso del nodo de motor de almacenamiento
16.5.3 El proceso del servidor de administración ndb_mgmd »
Section Navigation      [Toggle]

16.5.2. ndbd, el proceso del nodo de motor de almacenamiento

ndbd es el proceso que se usa para tratar todos los datos en las tablas usando el motor de almacenamiento NDB Cluster. Este proceso fuerza un nodo de almacenamiento a que cumpla el tratamiento de transacciones distribuídas, recuperación de nodos, realización de checkpoints, copia de seguridad en línea, y tareas relacionadas.

En MySQL Cluster, un conjunto de procesos ndbd cooperan para tratar datos. Estos procesos pueden ejecutarse en la misma máquina (equipo) o en máquinas distintas. Las correspondencias entre nodos de datos y máquinas cluster son completamente configurables.

En MySQL 5.0, ndbd genera un conjunto de ficheros de log que se guardan en el directorio especificado por DataDir en el fichero de configuración. Estos ficheros de log se listan a continuación. Tenga en cuenta que <NodeID> representa el identificador único del nodo. Por ejemplo, ndb_2_error.log es el log de error generado por el nodo de almacenamiento cuyo ID de nodo es 2.

  • ndb_<NodeID>_error.log es un fichero que contiene registros de todas las caídas que ha encontrado el proceso referenciado ndbd. Cada registro en este fichero contiene un breve mensaje de error y una referencia a un fichero de traceo para este fallo. Una entrada típica en este fichero puede ser parecida a: 

    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***

  • ndb_<NodeID>_trace.log.<TraceID> es un fichero de traceo que describe exactamente qué ha ocurrido jusnto antes de que ocurra el error. Esta información es útil para su análisis por parte del equipo de desarrollo de MySQL Cluster .

    Es posible configurar el número de estos ficheros de traceo que se crean antes que los ficheros antiguos se sobreescriban. <TraceID> es un número que se incrementa para cada fichero de traceo sucesivo.

  • ndb_<NodeID>_trace.log.next es el fichero que se encarga del siguiente número de traceo para fichero a asignar.

  • ndb_<NodeID>_out.log es un fichero que contiene cualquier salida de datos del proceso ndbd . Este fichero se crea sólo si ndbd se arranca como demonio.

  • ndb_<NodeID>.pid es un fichero que contiene el ID de proceso del proceso ndbd cuando se arranca como demonio. También funciona como fichero de bloqueo para evitar arrancar los nodos con el mismo identificador.

  • ndb_<NodeID>_signal.log es un fichero usado sólo en versiones de depuración de ndbd, donde es posible tracear toda la entrada, salida, y mensajes internos con sus datos en el proceso ndbd .

Se recomiendo no usar un directorio montado mediante NFS porque en algunos entornos puede causar problemas donde el bloqueo del fichero pid sigue en efecto tras la finalización del proceso.

Al reiniciar ndbd puede ser necesario especificar un nombre de equipo del servidor de administración y el puerto en que está escuchando. (Opcionalmente, se puede especificar el ID de nodo que usará el proceso. 

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

Consulte Sección 16.4.4.2, “El connectstring de MySQL Cluster” para más información sobre este tema.

Cuando ndbd arranca, inicia dos procesos. El primero de ellos se llama el proceso “angel process”; su trabajo es descubrir cuándo se completa el proceso de ejecución, y luego reinicia el proceso ndbd si se configura para hacerlo. Por lo tanto, is trata de matar ndbd via comando Unix kill , es necesario matar a ambos procesos. Una forma más adecuada de matar un proceso ndbd es usar el cliente de administración y parar el proceso desde allí.

El proceso en ejecución usa un flujo para lectura, escritura y escaneo de datos, así como otras actividades. Este flujo se implementa asíncronamente para que pueda tratar fácilmente miles de actividades concurrentes. Además, un flujo watch-dog supervisa el flujo de ejecución para asegurarse que no se cuelga en un bucle infinito. Un pool de flujos trata ficheros de entrada/salida, siendo cada flujo capaz de tratar un fichero abierto. Los flujos pueden usarse por las conexiones en el proceso de transporet de ndbd . En un sistema que realice un gran número de operaciones, incluyendo actualizaciones, el proceso ndbd consume hasta 2 CPUs si se permite hacerlo. Para máquinas con varias CPUs se recomienda usar varios procesos ndbd que pertenecen a diferentes grupos de nodos.

Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.