16.5. Gestión de procesos en MySQL Cluster

MySQL 5.0

previous page next page

16.5. Gestión de procesos en MySQL Cluster

Entender cómo administrar MySQL Cluster requiere un conocimiento de cuatro procesos esenciales. En las siguientes secciones de este capítulo, cubrimos los roles jugados por estos procesos en un cluster, cómo usarlos, y qué opciones de arranque están disponibles para cada uno de ellos.

16.5.1. El uso del proceso del servidor MySQL para MySQL Cluster

mysqld es el proceso de MySQL server tradicional. mysqld debe compilarse con soporte para el motor NDB Cluster , como lo está en los binarios precompilados disponibles en mysql.com.

Si el binario mysqld se ha compilado de esta forma, el motor NDB Cluster todavía está desactivado por defecto. Tiene dos opciones para activar el motor NDB Cluster :

Use como opción de arranque para mysqld

  • Inserte una línea con en la sección en el fichero .

Una forma sencilla de verificar que su servidor está ejecutando el motor es ejecutar el comando en MySQL Monitor (mysql). Debe ver el valor en el registro ; si ve en este registro (o si no se muestra este registro en la salida), no está ejecutando la versión -activada de mysqld. Si ve en este registro, entonces su servidor es capaz de usar el motor , pero debe activarse mediante algunos de los métodos ya descritos.

Para leer los datos de configuración del cluster, el MySQL server necesita como mínimo 3 informaciones:

  • El ID del nodo del servidor MySQL.

  • El nombre de equipo o dirección IP para el servidor de administración (nodo MGM).

  • El puerto en el que puede conectarse al servidor de administración.

Los ID de nodo pueden registrarse dinámicamente en MySQL 5.0, así que no es estrictamente necesario especificarlo explícitamente.

El parámetro de mysqld se usa para especificar el connectstring en la línea de comandos al arrancar mysqld o en . El connectstring contiene el nombre de equipo o direcciones IP así como el puerto donde puede encontrarse el servidor de administración.

En el siguiente ejemplo, es el equipo en que reside el servidor de administración, y el servidor de administracion escucha los mensajes del cluster en el puerto 1186: 

shell> mysqld --ndb-connectstring=ndb_mgmd.mysql.com:1186

Consulte Sección 16.4.4.2, “El de MySQL Cluster” para más información sobre los connectstrings.

Dada esta información el servidor MySQL será un participante activo del cluster. (En ocasiones nos referimos a un proceso mysqld que se ejecute de este modo como nodo SQL.) Será consciente de todos los nodos de datos del cluster así como de su estado, y establecerá conexiones con todos los nodos de datos. En este caso, es capaz de usar cualquier nodo de datos como un coordinador de transacción y para acceder nodos de datos para leer y actualizar.

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 en el fichero de configuración. Estos ficheros de log se listan a continuación. Tenga en cuenta que representa el identificador único del nodo. Por ejemplo, es el log de error generado por el nodo de almacenamiento cuyo ID de nodo es 2.

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

  • _trace.log. 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. es un número que se incrementa para cada fichero de traceo sucesivo.

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

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

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

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

16.5.3. El proceso del servidor de administración ndb_mgmd

El sevidor de administración es el proceso que lee el fichero de configuración del cluster y distribuye esta información a todos los nodos en el cluster que la piden. También mantiene un log de las actividades del cluster. Los clientes de administración pueden conectar al servidor de administración y chequear el estado del cluster.

No es estrictamente necesario especificar un connectstring al arrancar un servidor de administración. Sin embargo, si está usando más de un servidor de administración, debe proporcionarse un connectstring y cada nodo en el cluster debe especificar su ID de nodo explícitamente.

Los siguientes ficheros se crean o usan por ndb_mgmd en su directorio de arranque. En MySQL 5.0 Cluster, los ficheros de log y PID se guardan en el como se especifica en el fichero de configuración. En la lista a continuación, es el único identificador de nodo.

  • es el fichero de configuración para el cluster como un todo. Este fichero se crea por el usuario y lo lee el servidor de administración. La configuración de este fichero se discute en Sección 16.4, “Configuración de MySQL Cluster”.

  • _cluster.log es el ficheor de log de eventos del cluster. Ejemplos de tales eventos incluyen inicio y finalización de checkpoints, eventos de arranque de nodos, fallos de nodos, y niveles de uso de memoria. Una lista completa de eventos de cluster con descripciones puede encontrarse en Sección 16.6, “Administración de MySQL Cluster”.

    Cuando el tamaño del log del cluster alcanza un millón de bytes el fichero se renombra a _cluster.log., donde es el número de secuencia del fichero de log del cluster . (Por ejemplo: si 1,2, y 3 ya existen, el siguiente fichero de log se llamará con el número .)

  • _out.log es el fichero usado por y cuando se ejecuta el servidor de administración como demonio.

  • .pid es el fichero PID usado cuando se ejecuta el servidor de administración como demonio.

16.5.4. El proceso de cliente de administración ndb_mgm

El proceso de cliente de administración no es necesario que se ejecute en el cluster. Su validez estriba en proporcionar un conjunto de comandos para chequear el estado del cluster, arrancar copias de seguridad, y realizar otras funciones administrativas. El cliente de administración accede al servidor de administración usando la API C que pueden emplear los usuarios avanzados para programación dedicada a procesos de administración que pueden realizar tareas similares a las realizadas por ndb_mgm.

Al arrancar el cliente de administración, es necesario proporcionar el nombre de equipo y puerto del servidor de administración como en el ejemplo posterior. Los valores por defecto en MySQL 5.0 son y . 

shell> ndb_mgm localhost 1186

Más información puede acerca de ndb_mgm puede encontrarse en Sección 16.5.5.4, “Opciones de comando para ndb_mgm” y Sección 16.6.1, “Comandos del cliente de administración”.

16.5.5. Opciones de comando para procesos de MySQL Cluster

Todos los ejecutables de MySQL Cluster (excepto mysqld) tienen las siguientes opciones. Los usuarios de versiones anteriores de MySQL Cluster deben tener en cuenta que algunas de estas opciones han cambiado desde MySQL 4.1 Cluster para hacerlos consistentes entre ellos así como con mysqld. Puede usar la opción para ver un listado de las opciones soportadas.

  • Muestra una pequeña lista con descripciones de las opciones de comandos disponibles.

  • Muestra el número de versión del proceso ndbd. El número de versión es el número de MySQL Cluster. El número de versión es relevante porque no todas las versiones pueden usarse juntas, y al arrancar el proceso MySQL Cluster verifica que las versoines de los binarios usados pueden coexistir en el mismo cluster. Esto es importante al realizar una actualización de software en línea de MySQL Cluster (consulte ).

  • , --connect-string

    Cambia la cadena de conexión del servidor de administración como opción de comando. 

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

  • ]

    Esta opción sólo puede usarse para opciones compiladas con depuración activada. Se usa para permitir la salida de las llamadas de depuración de la misma forma que para el proceso mysqld .

  • ,

    Puede usarse para enviar un comando al ejecutable cluster desde el shell de sistema. Por ejemplo, cualquiera de los siguientes comandos: 

    shell> ndb_mgm -e show

    o 

    shell> ndb_mgm --execute="SHOW"

    es equivalente a 

    NDB> SHOW;

    Esto es análogo a cómo la opción funciona con el cliente de línea de comandos mysql . Consulte Sección 4.3.1, “Usar opciones en la raya de comando”.

16.5.5.1. Opciones de mysqld relacionadas con MySQL Cluster

  • Si el binario incluye soporte para el motor puede evitarse la desactivación por defecto del motor mediante el uso de esta opción. El uso del motor es necesario para MySQL Cluster.

  • Desactiva el motor . Esta opción está activa por defecto para binarios donde se incluye; en otras palabras, el motor se desactiva hasta que se activa via . Esta opción se activa sólo si el servidor se compiló con soporte para el motor .

  • Al usar el motor , es posible mediante esta opción especificar el servidor de almacenamiento que distribuye los datos de configuración del cluster.

16.5.5.2. Opciones de comando para ndbd

Para opciones comunes consulte Sección 16.5.5, “Opciones de comando para procesos de MySQL Cluster”.

  • ,

    Le dice a ndbd que se ejecute como un proceso demonio. En MySQL 5.0, es el comportamiento por defecto.

  • Le dice a ndbd que no arranque como proceso demonio. Es útil cuando ndbd se depura y se quiere que la salida se redirija a la pantalla.

  • Le dice a ndbd que realice un escaneo inicial. Un arranque inicial borra cualquier fichero creado con motivos de recuperación de instancias prévias de ndbd. También recrea ficheros log de recuperación. Tenga en cuenta que en algunos sistemas operativos este proceso puede llevar una cantidad de tiempo substancial.

    Un arranque se usa sólo la primera vez que se arranca el proceso ndbd , y borra todos los ficheros del sistema de ficheros del cluster y recrea todos los ficheros de log REDO. Las excepciones a esta regla son:

    • Cuando se realiza una actualización de software que cambia los contenidos de cualquier fichero.

    • Al reiniciar el nodo con una nueva versión de ndbd.

    • Como medida de última hora cuando por alguna razón el reinicio repetitivo del nodo o sistema fallan. En este caso el nodo no puede seguir usándose para restaurar datos debido a la destrucción de los ficheros de datos.

    Esta opción no afecta ningún fichero de copia de seguridad que se ha creado por el nodo afectado.

  • Le dice a ndbd que no arranque automáticamente. Cuando se usa esta opción, ndbd conecta el servidor de administración , obtiene datos de configuración del mismo, e inicia los objetos de comunicación. Sin embargo, no arranca realmente el motor hasta que se le pida que lo haga explícitamente por parte del servidor de administración. Esto puede realizarse ejecutando el comando apropiado por parte del cliente de administración.

16.5.5.3. Opciones del comando ndb_mgmd

Para algunas opciones comunes consulte Sección 16.5.5, “Opciones de comando para procesos de MySQL Cluster”.

  • , --config-file=, (OBSOLETE):

    Le dice al servidor de administración qué fichero debe usar como fichero de configuración. Esta opción debe especificarse. El fichero por defecto es . Nota: La abreviación es obsoleta en MySQL 5.0 Cluster y no debe usarse en nuevas instalaciones.

  • ,

    Le dice a ndb_mgmd que arranque como demonio. Este es el comportamiento por defecto.

  • Le dice al servidor de administración que no arranque como demonio.

16.5.5.4. Opciones de comando para ndb_mgm

Para algunas opciones comunes consulte Sección 16.5.5, “Opciones de comando para procesos de MySQL Cluster”.

  • [ []]

    Para arrancar el cliente de administración es necesario especificar dónde reside el servidor de administración, que significa especificar el nombre de equipo y puerto. El equipo por defecto es ; el puerto por defecto es 1186.

  • Si la conexión al servidor de administración se rompe, entonces el nodo trata de reconectar al mismo cada 5 segundos hasta que tiene éxito. Usando esta opción, es posible limitar el número de reintentos con antes de abandonar y reportar un error en su lugar.

previous page start next page