16.6. Administración de MySQL Cluster

MySQL 5.0

previous page next page

16.6. Administración de MySQL Cluster

Administar un MySQL Cluster implica un número de tareas, la primera de ellas es configurar y arrancar el MySQL Cluster. Esto se cubre en Sección 16.4, “Configuración de MySQL Cluster” y Sección 16.5, “Gestión de procesos en MySQL Cluster”.

Las siguientes secciones cubren la administración de un MySQL Cluster en ejecución.

Esencialmente hay dos métodos de administrar activamente un MySQL Cluster en ejecución. El primero de ellos es mediante el uso de comandos entrados en el cliente de administración donde puede chequearse el estado del cluster, cambiar los niveles de log, arrancar y parar copias de seguridad y parar y arrancar nodos. El segundo método implica estudiar el contenido del log del cluster _cluster.log en el directorio del servidor de adminisración . (Recuerde que representa el identificador único del nodo cuya actividad se está logueando.) El log del cluster contiene reportes de eventos generados por ndbd. Es posible también enviar entradas del log del cluster a un log de sistema Unix.

16.6.1. Comandos del cliente de administración

Además del fichero de configuración central, un cluster puede ser controlado mediante una interfaz de línea de comandos disponible a través del cliente de administración ndb_mgm. Esta es la interfaz administrativa primaria para un cluster en ejecución.

El cliente de administración tiene los siguientes comandos básicos. En la lista que sigue, dentoa un ID de nodo de base de datos o la palabra clave , que indica que el comando debe aplicarse a todos los nodos de datos en el cluster.

  • Muestra información de todos los comandos disponibles.

  • Muestra informaicón del estado del cluster.

  • START

    Arranca el nodo de datos identificado por (o todos los nodos de datos).

  • STOP

    Para el nodo de datos identificado por (o todos los nodos de datos).

  • RESTART [-N] [-I]

    Reinicia el nodo de datos identificado por (o todos los nodos de datos).

  • STATUS

    Muestra información de estado para el nodo de datos identificado por (o todos los nodos de datos).

  • Entra en modo de usuario único, donde sólo el servidor MySQL identificado por el ID del nodo tiene permiso para acceder a la base de datos.

  • Abandona el modo de usuario único permitiendo a todos los nodos SQL (esto es, todos los procesos mysqld en ejecución) para acceder a la base de datos.

  • Termina el cliente de administración.

  • Para todos los nodos del cluster, excepto los nodos SQL, y sale.

Los comandos para los logs de eventos se dan en la siguiente sección; los comandos para creación de copias de seguridad y restaurar de una copia de seguridad se proporcionan en una sección separada de estos temas.

16.6.2. Informes de eventos generados por MySQL Cluster

En esta sección dicutimos los tipos de logs de eventos proporcionados por MySQL Cluster, y los tipos de eventos que se loguean.

MySQL Cluster proporciona dos tipos de log de evento. Son cluster log, que incluye eventos generados por todos los nodos del cluster, y node logs, que son locales en cada nodo de datos.

La salida generada por el logueo de eventos del cluster puede tener varias destinaciones incluyendo un fichero, la consola del servidor de administración o . La salida generada por el logueo de eventos de un nodo se escribe en la ventana de consola de datos del nodo.

Ambos tipos de logueo de eventos pueden configurarse para loguear distintos subconjuntos de eventos.

Nota: El log del cluster es el log recomendado para la mayoría de usos, ya que proporciona información de logueo para un cluster entero en un único fichero . Los logs de nodos están pensados para ser usados sólo durante desarrollo de aplicaciones, o para depurar código de aplicación.

Cada evento reportable puede distinguirse según tres criterios distintos:

  • Categoría: Puede tener uno de los siguientes valores: , , , , , , , o .

  • Prioridad: Representada por un número de 1 a 15 incluidos, donde 1 indica “más importante” y 15 “menos importante”.

  • Nivel de severidad: Puede ser uno de los siguientes valores: , , , , , o .

El log de cluster y el log de nodo pueden filtrarse con estas propiedades.

16.6.2.1. Registrar comandos de control

Los siguientes comandos de administación están relacionados con el log de cluster:

  • Activa el log del cluster.

  • Desactiva el log del cluster

  • Información acerca de la configuración del log del cluster.

  • CLUSTERLOG =

    Loguea eventos de con prioridad menor o igual a en el log del cluster.

  • Cambia a loguear eventos del cluster de la especificada.

La siguiente tabla describe la configuración por defecto ( para todos los nodos de datos ) del umbral de categoría del log del cluster. Si un evento tiene una prioridad con un valor menor o igual al umbral de prioridad, se reporta en el log del cluster.

Tenga en cuenta que los eventos se reportan por nodo de datos, y que el umbral puede configurarse con distintos valores en nodos diferentes

Categoría Umbral por defecto (todos los nodos de datos)
7
7
7
7
7
7
15
7

Los umbrales se usan para filtrar eventos dentro de cada categoría. Por ejemplo, un evento con una prioridad de 3 no se loguea a no ser que el umbral para se cambie a 3 o menos. Sólo los eventos con prioridad de 3 o menor se envían si el umbral es 3.

Los niveles de seguridad de los eventos se muestran a continuación. (Nota: Se corresponde a niveles Unix, excepto para y , que no se usan o mapean.)

1 Condición que debe corregirse inmediatamente, tal como una base de datos de sistema corrupta
2 Condiciones críticas, tales como errores de dispositivos o recursos insuficientes
3 Condiciones que deben corregirse, tales como errores de configuración
4 Condiciones que no son errores, pero que pueden requerir tratamiento especial
5 Mensajes de información
6 Mensajes de depuración usados para desarrollo

Los niveles de severidad de eventos pueden activarse o desactivarse. Si un invel de severidad se activa, todos los eventos con una prioridad menor o igual que los umbrales de categoría se loguan. Si el nivel de severidad se deactiva no se loguan los eventos pertenecientes a ese nivel.

16.6.2.2. Registro de eventos

Un reporte de evento se reporta en el log de eventos con el siguiente formato: > [] -- . Por ejemplo: 

09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed

Todos los eventos reportables se discuten en esta sección, ordenados por categoría y nivel de severidad dentro de cada categoría.

Eventos

Hay eventos asociados con conexiones entre nodos del cluster.

Evento Prioridad Nivel de severidad Descripción
nodos DB conectados 8 INFO nodos de datos conectados
nodos DB desconectados 8 INFO nodos de datos desconectados
comunicación cerrada 8 INFO conexión con nodo SQL o de datos node cerrada
Comunicación abierta 8 INFO conexión con nodo SQL o de datos node abierta

Eventos

Los mensajes de log que se muestran se asocian con checkpoints.

(Nota: GCP = Global Checkpoint, LCP = Local Checkpoint.)

Evento Prioridad Nivel de severidad Descripción
LCP parado en el cálculo de mantenimiento de GCI 0 ALERT LCP parado
Fragmento de checkpoint local completo 11 INFO LCP en un fragmento se ha completado
Checkpoint global completo 10 INFO GCP finalizado
Checkpoint global arrancado 9 INFO Arranque de GCP: REDO log escrito en disco
Checkpoint local completado 8 INFO LCP completado normalmente
Checkpoint local arrancado 7 INFO Arranque de LCP: datos escritos en disco
Reporte del log de undo bloqueado 7 INFO Logueo de UNDO bloqueado; buffer cerca de desbordarse

Eventos

Los siguientes eventos se generan en respuesta al arranque de un nodo o del cluster y de su éxito o fallida. También proporciona información relacionada con el progreso del proceso de arranque, incluyendo información acerca de las actividades de logueo.

Evento Prioridad Nivel de severidad Descripción
Señal de arranque interna recibida STTORRY 15 INFO Bloques recibidos tras completar el reinicio
Registros Undo rejecutados 15 INFO  
Arrancado nuevo log REDO 10 INFO GCI guarda , los GCI restaurables más nuevos
Nuevo log arrancado 10 INFO Parte de log, arranca MB , para MB
El nodo se ha rehusado para incluir en el cluster 8 INFO El nodo no puede incluirse en el cluster debido a fallos de configuración, inabilidad de establecer comunicación, u otros problemas
DB nodos vecinos 8 INFO Muestra nodos de datos vecino
DB nodo arranca fase completada 4 INFO Un inicio de fase de nodo se ha completado
El nodo se ha incluido con éxito en el cluster 3 INFO Muestra el nodo, nodo de administración, e ID dinámico
Fases de arranque de nodo DB iniciadas 1 INFO Nodos de cluster NDB arrancando
Todas las fases de arranque del nodo DB completadas 1 INFO Nodos NDB Cluster arrancados
Parada de nodo DB iniciada 1 INFO Parada de nodos de datos comenzada
Parada de nodo DB abortada 1 INFO Incapaz de cerrar el nodo de datos normalmente

Eventos

Los siguientes eventos se generan al reiniciar un nodo y están relacionados con el éxito o fracaso del proceso de reinicio del nodo.

Evento Prioridad Nivel de severidad Descripción
Fase de fallo de nodo completa 8 ALERT Rerporta la finalización de las fases de fallo de nodo
El nodo ha fallado, el estado del nodo era 8 ALERT Reporta que el nodo ha fallado
Reporta el resultado del árbitro 2 ALERT Hay 8 resultados distintos posibles de arbitraciones:

  • Chequeo de arbitración fallido - quedan menos de 1/2 de los nodos.

  • Chequeo de arbitración exitoso - mayoría de nodos del grupo.

  • Chequeo de arbitración fallido - falta un grupo de nodos.

  • Partición de red - arbitración necesaria

  • Arbitración exitosa - respuesta afirmativa del nodo

  • Arbitración fallida - respuesta negativa del nodo

  • Partición de red - no hay árbitro disponible

  • Partición de red - no hay árbitro configurado

Completada la copia de fragmento 10 INFO  
Completada la copia de información de directorio 8 INFO  
Completada la copia de información de distribución 8 INFO  
Iniciada la copia de fragmentos 8 INFO  
Completada la copia de todos los fragmentos 8 INFO  
Control de GCP iniciado 7 INFO  
Control de GCP completado 7 INFO  
Control de LCP iniciado 7 INFO  
Control de LCP completado (estado = ) 7 INFO  
Reporta si se encuentra un árbitro o no 6 INFO Hay 7 salidas distintas al buscar un árbitro:

  • El servidor de administración reinicia el flujo árbitro [estado=]

  • Prepara nodo árbitro [ticket=]

  • Recibe nodo árbitro [ticket=]

  • Nodo árbitro iniciado [ticket=]

  • Nodo árbitro perdido - proceso fallido [estado=]

  • Lost arbitrator node - process exit [state=]

  • Nodo árbitro perido <error msg> [estado=]

Eventos

Los siguientes eventos son de naturaleza estadística. Proporcionan información tal como números de transacción y otras operaciones, cantidad de datos enviados o recibidos por nodos individuales, y uso de memoria.

Evento Prioridad Nivel de severidad Descripción
Reporta estadísticas de planificación de trabajos 9 INFO Estadísticas de planificación de trabajos internos
Número de bytes enviados 9 INFO Número de bytes enviados al nodo
Recibidos # bytes 9 INFO Número de bytes recibidos del nodo
Reporte de estadísticas de transacción 8 INFO Número de: transacciones, commits, lecturas, lecturas simples, escrituras, operaciones concurrentes, información de atributos, y abortos
Operaciones de reporte 8 INFO Número de operaciones
Creación de tabla de reportes 7 INFO  
Uso de memoria 5 INFO Uso de datos e índices (80%, 90% y 100%)

Eventos

Estos eventos están relacionados con errores y advertencias del cluster; la presencia de uno o más de ellos indica generalmente que un fallo importante ha ocurrido.

Evento Prioridad Severidad Descripción
Muerte debida a un heartbeat fallido 8 ALERT Nodo declarado “dead” debido a un heartbeat fallido
Errores de transporte 2 ERROR  
Advertencias de transporte 8 WARNING  
Heartbeats perdidos 8 WARNING Nodo ha perdido el heartbeat #
Eventos de advertencia generales 2 WARNING  

Eventos

Estos eventos proporcionan información general sobre el estado del cluster y actividades asociadas con el mantenimiento del mismo, tales como logueo y transmisión de heartbeat .

Evento Prioridad Severidad Descripción
Heartbeat enviado 12 INFO Heartbeat enviado a nodo
Bytes de log creado 11 INFO Parte de log, fichero de log, MB
Eventos de información general 2 INFO  

16.6.3. Modo de usuario único

El modo de usuario único permite al administrador de la base de datos restringir el acceso al sistema de base de datos a un único servidor MySQL (nodo SQL): Al entrar en el modo de usuario único todas las conexiones a todos los otros servidores MySQL se cierran y todas las transacciones en ejecución se abortan. No se permiten nuevas transacciones.

Una vez que el cluster ha entrado en modo de usuario único, sólo el nodo SQL designado tiene acceso a la base de datos. Puede usar el comando all status para ver si el cluster ha entrado en este modo.

Ejemplo: 

NDB> ENTER SINGLE USER MODE 5

Tras la ejecución de este comando y que el cluster entre en modo de usuario único, el nodo SQL cuyo ID de nodo es pasa a ser el único usuario permitido del cluster.

El nodo especificado en el comando superior debe ser un nodo MySQL Server ; Un intento de especificar cualquier otro tipo de nodo se rehusará.

Nota: Cuando se invoca el comando anteior, todas las transacciones en ejecución en el nodo designado se abortan, la conexión se cierra y el servidor debe reiniciarse.

El comando EXIT SINGLE USER MODE cambia el estado de los nodos del datos del cluster de modo de usuario único a modo normal. Los servidores MySQL esperando conexiones (esto es, a que el cluster pase a estar preparado y disponible), pueden conectarse: El servidor MySQL denotado como el nodo de usuario único SQL continúa ejecutándose (si todavía está conectado) durante y tras el cambio de estado.

Ejemplo: 

NDB> EXIT SINGLE USER MODE

La forma recomendada de tratar un fallo de nodo al ejecutar el modo de usuario único es una de las siguientes:

    1. Terminar todas las transacciones de modo de usuario único.

    2. Ejecutar el comando EXIT SINGLE USER MODE

    3. Reiniciar los nodos de datos del cluster

or

  • Reinicia los nodos de base de datos antes de entrar en modo de usuario único.

16.6.4. Copias de seguridad On-line para MySQL Cluster

Esta sección describe cómo crear una copia de seguridad y cómo restaurar la base de datos de una copia de seguridad posteriormente.

16.6.4.1. Conceptos de copias de seguridad de nodos

Una copia de seguridad es una fotografía de la base de datos en un momento dado. La copia de seguridad tiene tres partes principales:

  • Metadatos: nombres y definiciones de todas las tablas de la base de datos.

  • Registros de tabla: los datos guardados realmente en las tablas de la base de datos cuando se hizo la copia de seguridad

  • Log de transacción: un registro secuencial diciendo cómo y cuándo se han almacenado los datos en la base de datos.

Cada uno de ellos se guarda en todos los nodos participantes en la copia de seguridad. Durante la copia de seguridad cada nodo guarda estas tres partes en tres ficheros en disco:

  • ..ctl

    Un fichero de control con información de control y metadatos. Cada nodo guarda las mismas definiciones de tabla (para todas las tablas en el cluster) en su propia versión de este fichero.

  • -0..data

    Un fichero de datos conteniendo los registros de tabla, que se guardan en fragmentos; esto es, distintos nodos guardan distintos fragmentos durante la copia de seguridad. El fichero guardado por cada nodo comienza con una cabecera que explica a qué tabla pertenencen los registros. A continuación de la lista de registros, hay un pie que contiene un checksum de los registros.

  • ..log

    Un fichero de log con registros de transacciones finalizadas. Sólo las transacciones de tablas guardadas en la copia de seguridad se guardan en el log. Los nodos involucrados en la copia de seguridad guardan distintos registros, ya que distintos nodos guardan distintos fragmentos de base de datos.

En la tabla anterior es el identificador de la copia de seguridad y es el identificador único para el nodo que crea el fichero.

16.6.4.2. Usar el servidor de administración para crear una copia de seguridad

Antes de iniciar una copia de seguridad, asegúrese que el cluster está debidamente configurado para ello. (consulte Sección 16.6.4.4, “Configuración para copias de seguridad de un nodo”.)

Para crear una copia de seguridad usando el servidor de administración implica los siguientes pasos:

  1. Arrancar el servidor de administración (ndb_mgm).

  2. Ejecutar el comando .

  3. El servidor de administración responderá con el mensaje “”. Esto significa que el servidor de administración ha enviado la petición al cluster, pero no ha recibido respuesta aun.

  4. El servidor de administración responderá “ started”, donde es el identificador único para esta copia de seguridad. (Este ID se guardará en el log del cluster, si no ha sido configurado de otro modo.) Esto significa sólo que el cluster ha recibido y procesado la petición de copia de seguridad. Esto no significa que se haya completado.

  5. El servidor de administración envía la señal que la copia ha finalizado con el mensaje “ completed”.

Es posible iniciar la copia de seguridad de la shell del sistema usando 

shell> ndb_mgm -e "START BACKUP"

Para abortar una copia en marcha:

  1. Arranque el servidor de administración.

  2. Ejecute el comando ''. El número es el identificador de la copia que se incluyó en la respuesta del servidor de administración cuando se inició la copia (en el mensaje ' started"').

  3. El servidor de administración reconocerá la petición de aborto con “ ordered”; tenga en cuenta que no se ha recibido todavía respuesta a esta petición.

  4. Una vez que la copia de seguridad se ha abortado, el servidor de administración reportará “ has been aborted for reason ”. Esto significa que el cluster ha terminado la copia y que todos los ficheros relacionados con la misma se han eliminado del sistema de ficheros del cluster.

Es posible abortar una copia de seguridad en curso desde el shell de sistema usando este comando: 

shell> ndb_mgm -e "ABORT BACKUP "

Nota: Si no hay una copia con ID en ejecución cuando se aborta, el servidor de administración no hace ninguna respuesta explícita. Sin embargo, el hecho que se envió un comando de aborto incorrecto se indica en el log del cluster.

16.6.4.3. Cómo restablecer una copia de seguridad de un nodo

El programa de restauración del cluster se implementa como utilidad de línea de comandos separada ndb_restore, que lee los ficheros creados por la copia de seguridad e inserta la información almacenada en la base de datos. El programa de restauración debe ejecutarse una vez para cada conjunto de ficheros de la copia, esto es, tantas veces como nodos había cuando se creo la copia.

La primera vez que ejecute el programa de restauración, necesita restaurar los metadatos; en otras palabras, debe recrear las tablas de la base de datos. (Tenga en cuenta que el cluster debe tener una base de datos vacía cuando empieza a restaurar una copia de seguridad.) El program de restauración actúa como una API contra el cluster y por lo tanto necesita una conexión libre para conectar al cluster. Esto puede verificarse con el comando ndb_mgm SHOW (o desde una shell de sistema usando ndb_mgm -e SHOW). La opción puede usarse para localizar el nodo MGM (consulte Sección 16.4.4.2, “El de MySQL Cluster” para información acerca de connectstrings). Los ficheros de la copia de seguridad deben estar presentes en el directorio dado como argumento al programa de restauración.

Es posible restaurar una copia de seguridad a una base de datos con una configuración distinta a la que tenía en el momento de su creación. Por ejemplo, suponga que una copia de seguridad con ID ,se creó en un cluster con dos nodos de base de datos con los IDs de nodo y , se restaura en un cluster con cuatro nodos. Entonces ndb_restore debe ejecutarse dos veces — una por cada nodo de base de datos en el cluster donde se hizo la copia de seguridad.

Nota: Para una restauración rápida, los datos pueden restaurarse en paralelo, dado que haya una cantidad de conexiones de cluster disponibles. Sin embargo, los ficheros de datos deben siempre aplicarse antes que los logs.

16.6.4.4. Configuración para copias de seguridad de un nodo

Hay cuatro parámetros de configuración esenciales para una copia de seguridad:

  • Cantidad de memoria usada para buffer de los datos antes de escribir en disco.

  • Cantidad de memoria usada para buffer de registros de lob antes de escribir en disco.

  • Memoria total reservada en un nodo de base de datos para copia de seguridad. Debe ser la suma de memoria reservada para el buffer de datos y el de log.

  • Tamaño de los blocks escritos en disco. Esto se aplica tanto para el buffer de datos como para el de log.

Puede encontrar información más detallada sobre estos parámetros en Sección 16.4, “Configuración de MySQL Cluster”.

16.6.4.5. Resolver problemas con copias de seguridad

Si se retorna un código de error al hacer una petición de copia de seguridad la causa más probable es memoria insuficiente o espacio de disco insuficiente. Debe chequear que hay suficiente memoria reservada para la copia de seguridad. También que hay espacio suficiente en la partición del disco duro.

En MySQL 5.0, no soporta lecturas repetibles, que puede causar problemas en el proceso de restauración. Mientras que el proceso de copia de seguridad es“hot”, restaurar un MySQL Cluster desde una copia de seguridad no es un proceso 100% “hot” . Esto se debe a que, por la duración del proceso de restauración, las transacciones en ejecución obtienen lecturas no repetibles de los datos restaurados. Esto significa que el estado de los datos es incosistente mientras que la restauración está en marcha.

previous page start next page