Pandora: Documentation es: Anexo MySQL Cluster

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

Contents

1 HA en Pandora FMS con MySQL Cluster

1.1 Introducción

MySQL Cluster es una tecnología que permite el agrupamiento de bases de datos en memoria en un entorno de no compartición. La arquitectura de no compartición permite que el sistema funcione con hardware económico, y sin ningún requerimiento especial de hardware o software. Tampoco tienen ningún punto único de fallo porque cada componente tiene su propia memoria y disco.

MySQL Cluster integra el servidor MySQL estándar con un motor de almacenamiento clusterizado en memoria llamado NDB. En nuestra documentación, el término NDB se refiere a la parte de la inicialización específica al motor de almacenamiento, mientras que MySQL Cluster se refiere a la combinación de MySQL y el nuevo motor de almacenamiento. Un MySQL Cluster consiste en un conjunto de máquinas, cada una ejecutando un número de procesos incluyendo servidores MySQL , nodos de datos para NDB Cluster, servidores de administración, y (posiblemente) programas especializados de acceso a datos.

Los datos almacenados en los nodos de datos de MySQL Cluster pueden replicarse: el cluster puede tratar fallos de nodos de datos individuales sin otro impacto a parte de abortar algunas transacciones debido a la pérdida de estado de transacción. Como las aplicaciones transaccionales se suponen que tratan fallos transaccionales, esto no debería ser un problema.

1.1.1 Glosario de términos del cluster usado para Pandora FMS

Nodo de Datos: Este es el tipo de nodo que almacena los datos del cluster. Hay tantos nodos de datos como réplicas, multiplicado por el número de fragmentos. Por ejemplo, con dos réplicas, cada uno teniendo dos fragmentos, necesita cuatro nodos de datos. No es necesario tener más de una réplica. Un nodo de datos se arranca con el comando ndbd (o ndbmtd si se arranca la versión multihilo)

Nodo SQL (o Nodo API): Este es el nodo que accede a los datos del cluster. En el caso de MySQL Cluster, un nodo cliente es un servidor MySQL tradicional que usa el motor NDB Cluster . Un nodo SQL se arranca con el mysqld con la opción ndbcluster añadida al fichero my.cnf.

Manager o MGM: Es el nodo de Administración del cluster. El rol de este tipo de nodo es administrar los otros nodos dentro del MySQL Cluster, tal como proporcionar datos de configuración, iniciar y parar nodos, ejecutar copias de seguridad, y en general las tareas de gestión del cluster. Como este tipo de nodo administra la configuración de otros nodos, un nodo de este tipo debe arrancarse primero, antes de cualquier otro nodo. Un nodo MGM se arranca con el comando ndb_mgmd

1.1.2 Arquitectura del cluster usado con Pandora FMS

La Arquitectura del cluster de ejemplo, constará de dos servidores en los que se ejecutarán los nodos de datos, y los nodos SQL, además en otros dos servidores se instalarán dos nodos de administración del cluster que se encargarán de gestionar el cluster.



Pandora cluster.png



Teniendo en cuenta la arquitectura de la figura el cluster sería formado por las máquinas: PandoraDB1, PandoraDB, PandoraDBhis y Pandora2.

Esta arquitecture supone varias cosas:

  • Existe un balanceador en el frontal (Frontend) que balancea hacia los tres servidores de Pandora FMS utilizando el puerto de tentacle, con un algoritmo tipo RR (RoundRobin). De igual manera se balancea el tráfico de SNMP trap hacia dentro.
  • Existe un balanceador en el backend que balancea hacia los nodos SQL, las peticiones de la consola y de los servidores.

Este balanceador es externo a Pandora, y puede ser tanto hardware como software. Para montar un balanceador por software, existe documentación de Pandora FMS sobre como montar keepalived.

El propósito del clúster para la base de datos es repartir la alta carga que tendrá la base de datos al monitorizar un alto número de máquinas y parámetros de las mismas. Para que el clúster funcione correctamente es muy importante que el balanceador, detallado anteriormente, esté bien diseñado y funcione correctamente.

Las características del clúster para la base de datos serán las siguientes:

  • Funciona trabajando sobre memoria, volcando a disco logs de transacciones.
  • Necesita un gestor para coordinar la recuperación.
  • Necesita discos rápidos y conexión de red rápida.
  • Tiene unos requisitos de memoria muy estrictos.
  • Necesita tener toda la base de datos en memoria para funcionar rápido.

Se puede aumentar la memoria RAM de los equipos que conforman el clúster para obtener un mayor rendimiento. En un principio se proyectó un requerimiento de 16 GiB de RAM para cada uno de los equipos que forman la base de datos.

1.2 Instalación y configuración.

Vamos a suponer una instalación sobre un sistema SUSE. La instalación del cluster de MySQL en SUSE SLES implica la instalación de los rpms con el software de cluster de MySQL, en concreto habrá que instalar los siguientes ficheros:

  • MySQL-Cluster-gpl-client-7.0.6-0.sles10.x86_64.rpm
  • MySQL-Cluster-gpl-extra-7.0.6-0.sles10.x86_64.rpm
  • MySQL-Cluster-gpl-management-7.0.6-0.sles10.x86_64.rpm
  • MySQL-Cluster-gpl-server-7.0.6-0.sles10.x86_64.rpm
  • MySQL-Cluster-gpl-shared-7.0.6-0.sles10.x86_64.rpm
  • MySQL-Cluster-gpl-storage-7.0.6-0.sles10.x86_64.rpm
  • MySQL-Cluster-gpl-test-7.0.6-0.sles10.x86_64.rpm
  • MySQL-Cluster-gpl-tools-7.0.6-0.sles10.x86_64.rpmlibmysqlclient16

1.2.1 Configuración de un Nodo SQL y de Datos

En cada nodo de datos o nodo SQL tendremos que modificar el archivo de configuración /etc/my.cnf, que además de la configuración habitual de MySQL debe contener algunos parámetros extra de configuración del cluster, a continuación se describen dichos parámetros y los valores que se les debe dar (la configuración completa final está al final de este apéndice).

Los parámetros de configuración del cluster en el fichero my.cnf se aplican a dos secciones mysqld y mysql_cluster.

En la seccción mysqld se deben añadir los parámetros siguientes:

  • ndbcluster: indica al motor mysql que debe arrancar el motor NDB para bases de datos en cluster.
  • ndb-connectstring="10.1.1.215:1186;10.1.1.216:1186": contiene el string de conexión a el/los nodo/s de gestión, se trata de una cadena de caracteres con el formato host:puerto,host:puerto.
  • ndb-cluster-connection-pool=10: numero de conexiones en la reserva de conexiones, el fichero config.ini del cluster debe definir también al menos un nodo MySQL (o nodo API) por cada conexión.
  • ndb-force-send=1: fuerza a que los buffers se envíen inmediatamente sin esperar a otros threads.
  • ndb-use-exact-count=0: desactiva el forzado de NDB a contar los registros durante la planificación de consultas SELECT COUNT (*) para agilizar las consultas en general.
  • ndb-autoincrement-prefetch-sz=256: determina la probabilidad de dejar huecos en una columna autoincrementada, con un valor de 1 se minimizan los huecos, mayores valores aceleran las inserciones, pero reducen las posibilidades de que se utilicen numeros consecutiovos en inserciones en lote.

En la sección mysql_cluster se deben añadir los parámetros siguientes:

  • ndb-connectstring="10.1.1.230:1186;10.1.1.220:1186": contiene el string de conexión a el/los nodo/s de gestión, se trata de una cadena de caracteres con el formato host:puerto,host:puerto.

Aqui vemos un extracto del fichero

[mysqld]
# Run NDB storage engine
ndbcluster
# Location of management servers
ndb-connectstring="10.1.1.215:1186;10.1.1.216:1186"   
# Number of connections in the connection pool, the config.ini file of the
# cluster have to define also [API] nodes at least for each connection.
ndb-cluster-connection-pool=10
# Forces sending of buffers to NDB  immediately, without waiting
# for other threads. Defaults to ON. 
ndb-force-send=1
# Forces NDB to use a count of records during SELECT COUNT(*) query planning 
# to speed up this type of query. The default value is ON. For faster queries
# overall, disable this feature by setting the value of ndb_use_exact_count
# to OFF. 
ndb-use-exact-count=0

# Determines the probability of gaps in an autoincremented column. 
# Set it to 1 to minimize this. Setting it to a high value for 
# optimization — makes inserts faster, but decreases the likelihood
# that consecutive autoincrement numbers will be used in a batch
# of inserts. Default value: 32. Minimum value: 1. 
ndb-autoincrement-prefetch-sz=256

# Options for ndbd process:
[mysql_cluster]
# Location of management servers (list of host:port separated by ;)
ndb-connectstring="10.1.1.230:1186;10.1.1.220:1186" 

La versión final de este fichero está en el Apéndice 1

1.2.2 Configuración del Manager

Primero se crea el directorio donde se almacenará la información del cluster (/var/lib/mysql-cluster/) y dentro de dicho directorio se creará el fichero de configuración del cluster (config.ini) del que se incluye a continuación un resumen con los parámetros más relevantes:

# MySQL Cluster Configuration file 
# By Pablo de la Concepción Sanz <[email protected]>
# This file must be present on ALL the management nodes
# in the directory /var/lib/mysql-cluster/

##########################################################
# MANAGEMENT NODES                                       #
# This nodes are the ones running the management console #
##########################################################

# Common configuration for all management nodes:

[ndb_mgmd default]

ArbitrationRank=1
# Directory for management node log files
datadir=/var/lib/mysql-cluster  

[ndb_mgmd]
id=1
# Hostname or IP address of management node
hostname=<hostname_nodo_de_gestion_1>        

[ndb_mgmd]
id=2
# Hostname or IP address of management node
hostname=<hostname_nodo_de_gestion_2> 

.
.
.

Info.png

La versión final de este fichero está al final de este documento

 


El fichero config.ini está dividido en las siguientes secciones:

  • [ndb_mgmd default]: Configuración común a todos los nodos de gestión
  • [ndb_mgmd]: Configuración individual de cada nodo de gestión
  • [ndbd default]: Configuración común de los nodos de datos
  • [ndbd]: Configuración individual de cada nodo de datos
  • [mysqld default]: Configuración común de todos los nodos API o SQL
  • [mysqld]: Configuración individual de cada nodo API o SQL
  • [tcp default]: Configuración de buffers de conexión

1.2.2.1 Parámetros de la configuración común de los nodos de gestión

ArbitrationRank: Este parámetro sirve para definir que nodo hace de árbitro (Los nodos de gestión y los nodos SQL pueden hacer de árbitros, se recomienda que sean los nodos de gestión los que tengan alta prioridad) , puede tomar valores de 0 a 2:

  • 0: El nodo nunca será usado como árbitro
  • 1: El nodo tiene alta prioridad, tendrá prioridad sobre nodos de baja prioridad
  • 2: El nodo tiene baja prioridad, y sólo se utilizará como árbitro si no hay otros nodos de más prioridad disponibles.

Datadir: Directorio donde se almacenan los logs del nodo de gestión.

1.2.2.2 Parámetros de configuración individual de los 2 nodos de gestión

Debe haber una sección [ndb_mgmd] por cada nodo de gestión.

id: Identificador de nodo, debe ser único en todo el fichero de configuración.

Hostname: Nombre del host o dirección IP del nodo de gestión.

1.2.2.3 Parámetros de configuración comunes a los nodos de almacenamiento

NoOfReplicas: redundancia, número de replicas para cada tabla almacenada en el cluster. Este parámetro también especifica el tamaño de los grupos de nodos. Un grupo de nodos es un conjunto de nodos que almacenan todos la misma información. Se recomienda establecer el número de replicas a 2 que permite tener alta disponibilidad.

Datadir: directorio donde se almacenan los ficheros relacionados con el nodo de datos (logs, ficheros de traza, logs de errores, ficherso con el pid).

DataMemory: este parámetro establece el espacio (en Bytes) disponible para almacenar registros de la base de datos, todo el espacio indicado se reserva en memoria, por tanto es extremadamente importante que haya suficiente memoria física para reservar sin necesidad de utiilizar la memoria de intercambio.

IndexMemory: este parámetro controla la cantidad de almacenamiento usado por índices hash en MySQL Cluster. Los índices hash siempre son usados por índices de clave primaria, índices únicos y restricciones únicas.

StringMemory: este parámetro indica cuanta memoria se reserva para cadenas de caracteres (como los nombres de las tablas), un valor entre 0 y 100 se toma como un porcentaje del valor máximo (que varía en función de un buen número de factores) mientras que un valor superior a 100 se interperta como el número de bytes. (25% debería ser más que suficiente).

MaxNoOfConcurrentTransactions: este parámetro indica el número máximo de transacciones en un nodo, debe ser el mismo para todos los nodos de datos, esto se debe a que si un nodo falla el nodo más antiguo de los restantes vuelve a crear todas las transacciones del nodo caido (cambiar el valor de este parámetro supone una parada completa del cluster).

MaxNoOfConcurrentOperations: indica el número máximo de registros que pueden estar en fase de actualización o bloqueados simultaneamente.

MaxNoOfLocalOperations: se recomienda establecer este parámetro con un valor del 110% de MaxNoOfConcurrentOperations.

MaxNoOfConcurrentIndexOperations: este parámetro tiene un valor por defecto de 8192 y sólo en casos de paralelismo extremadamente alto que utilicen indices hash únicos debería ser necesario amuentar su valor. Se puede reducir su valor si el Administrador de la Base de Datos considera que no hay mucho paralelismo y con ello ahorrar algo de memoria.

MaxNoOfFiredTriggers: este parámetro tiene un valor por defecto de 4000 y debería ser suficiente en la mayoría de los casos, en algunas ocasiones incluso se puede reducir su valor si el Administrador de la Base de Datos considera que no hay mucho paralelismo.

TransactionBufferMemory: este almacenamiento temporal de memoria se utiliza durante la actualización de tablas de índices y lectura de indices únicos para almacenar la clave y la columna en estas operaciones y normamente no se debe modificar el valor por defecto de 1M.

MaxNoOfConcurrentScans: este parámetro indica el número máximo de escaneos en paralelo que pude llevar a cabo el cluster, que debe ser capaz de soportar tantos escanos como los marcados por este parámetro en cada nodo.

MaxNoOfLocalScans: Este parámetro indica el número de registros escaneados localmente si varios escaneos no se producen completamente en paralelo. Si no se especifica se calcula como el producto de MaxNoOfConcurrentScans por el número de nodos de datos.

BatchSizePerLocalScan: indica el número de registros bloqueados que se utilizan para tratra operaciones de escaneo concurrentes.

LongMessagesBuffer: este parámetro determina el tamaño de un almacenamiento temporal interno para el intercambio de información entre nodos.

NoOfFragmentLogFiles: este parámetro indica cuantos bloques de redo log se generarán y junto con FragmentLogFileSize permite determinar el tamaño total del redo log.

FragmentLogFileSize: tamaño de los fragmentos de redo log, cuatro de estos fragmentos forman un bloque de redo log y es el tamaño con el que se reserva el espacio de redo log. Un tamaño mayor de los 16M de FragmentLogSize permite un mayor rendimiento cuando hay mucha escritura y muy recomendable aumentar el valor de este parámetro en ese caso.

InitFragmentLogFiles: este parámetro puede tomar dos valores SPARSE o FULL

  • SPARSE: Este es el valor por defecto, los fragmentos de log se crean de forma separada.
  • FULL: Fuerza a que todos los bytes del los fragmentos de log se escriban en disco.

MaxNoOfOpenfiles: este parámetro limita el número de hilos para apertura de ficheros. Cualuquier situación que requiea cambiar este parámetro debería ser reportada como un bug.

InitialNoOfOpenFiles: número de hilos inicial para la apertura de ficheros.

MaxNoOfSavedMessages: número máximo de ficheros de traza que se guardan antes de empezar a sobreescribir los antiguos.

MaxNoOfAttributes: define el número máximo de atributos que se pueden definir en el cluster. Cada atributo consume acerca de 200 bytes de almacenamiento por nodo debido a que todos los metadatos están replicados en los servidores.

MaxNoOfTables: define el numero máximo total de objetos tabla (ttabla, índice hash único e índice ordenado) en el cluster.

MaxNoOfOrderedIndexes: para cada índice ordenado en este cluster, un objeto se reserva que describe lo que se indexa y sus segmentos de almacenamiento. Por defecto cada índice definido así también define un índice ordenado. Cada índice único y clave primaria tiene un índice ordenado e índice hash.

MaxNoOfTriggers: define el número máximo de disparadores en el cluster.

LockPagesOnMainMemory: bloquea los procesos de los nodos de datos en memoria evitando que entren en swap, los posibles valors del parámetro son:

  • 0: Deshabilita el bloqueo (valor por defecto).
  • 1: Realiza el bloqueo después de reservar la memoria del proceso.
  • 2: Realiza el bloque antes de reservar la memoria del proceso.

StopOnError: indica si los procesos de los nodos de datos terminan tras un error o se reinician automáticamente.

Diskless: obliga a todo el cluster a trabajar sin disco, en memoria, en este modo los backups online están deshabilitados, y no se puede inicial parcialmente el cluster.

ODirect: habilitando este parámetro se utilizan escrituras O_DIRECT en local checkpoitns y redo logs, reduciendo la carga de la CPU, se recomienda habilitarlo para sistemas sobre un Linux con un kernel 2.6 o superior.

CompressedBackup: cuando está activado (1) realiza una compresión equivalente a gzip –fast ahorrando hasta un 50% de espacio en los ficheros de backup.

CompressedLCP: cuando está activado (1) realiza una compresión equivalente a gzip –fast ahorrando hasta un 50% de espacio en los ficheros de Checkpoint.

TimeBetweenWatchDogCheck: número de milisegundos del intervalo de checheo del WatchDog (hilo que se encarga de comprobar que el hilo pricipal no se ha quedado bloqueado) si tras 3 chequeos el hilo principal sigue en el mismo estado el wachdog termina el hilo pricipal.

TimeBeweenWatchDogCheckInitial: cumple la misma función que TimeBetweenWachdogCheck, pero este valor se aplica en la fase inicial de arranque del cluster, cuando se está haciendo la reserva de memoria.

StartPartialTimeout: indica cuanto tiempo se espera desde que se inicia el proceso de arranque del cluster hasta que todos los nodos de datos están arriba, este parámetro se ignora si se trata de una inicialización del cluster. Su función es que el cluster no quede arrancado a medias.

StartPartitionedTimeout: si el cluster está listo para arancar tras esperar StartPartialTimeout, pero está en un estado particionado, el cluster espera también a que pase este timeout. Este parámetro se ignora si se trata de una inicialización del cluster.

StartFailureTimeout: si un nodo no ha terminado su fase de arranque cuando termina este timout el arranque falla, un valor de 0 indica que se espera indefinidamente. si el nodo tiene mucha información (varios gigabytes de datos) este parámetro debería aumentarse (el arranque con grandes cantidades de datos puede llegar a tardar 10 o 15 minutos).

HeartbeatIntervalDbDb: indica cada cuanto se envían señales de pulso y cada cuanto se espera recibir señaes de pulso. Si no se reciben señales de pulso desde un nodo durante 3 intervalos consecuivos el nodo se considera caido, asi el tiempo máximo para descubrir un fallo mediante el proceso de envío de pulsos es 4 veces el valor de este parámetro. Este parámetro no debe camibarse demasiado y debería tener el mismo valor para todos los nodos.

HeartbeatIntervalDbApi: cada nodo envía señales de pulso a cada nodo MySQL o API para asegurarse de que se mantiene el contacto. Si un nodo MySQL no puede mandar el pulso a tiempo (siguiendo el criterio de los 3 pulsos explicado en HeartbeatIntervalDbDb) se le considera caido y todas las transacciones en curso se completan y se liberan los recursos. Un nodo no puede reconectar hasta que los recursos de la instancia anterior han sido liberados.

TimeBetweenLocalCheckpoints: sirve para evitar que en un cluster con poca carga se hagan local checkpoints (si hay mucha carga normalmente se empieza uno nuevo nada más terminar el anterior). Es un valor dado como logaritmo en base 2 del tamaño a almacenar en cada checkpoint.

TimeBetweenGlobalCheckpoints: indica cada cuanto tiempo se vuelcan a disco las transacciones.

TimeBetweenEpochs: indica el itntervalo de las épocas de replicación del cluster

TransactionInactiveTimeout: define un timeout para las épocas de sincronización de la replicación del cluster, si un nodo no es capaz de participar en un global checkpoint en el periodo establecido por este parámetro el nodo se apaga.

TransactionDeadlockDetectionTimeout: indica cuanto tiempo espera el coordinador de transacciones a que otro nodo complete una consulta antes de abortar la transacción. Este parámetro es importante para la gestión de deadlocks y de fallo de nodos.

DiskSyncSize: tamaño máximo almacenado antes de volcar los datos a un local checkpoint file.

DiskCheckpointSpeed: velocidad de transferencia en bytes por segundo de datos enviados a disco durante un local checkpoint.

DiskCheckpointSpeedInRestart: velocidad de transferencia en bytes por segundo de datos enviados a disco durante un local checkpoint que forma parte de una operación de Restart.

ArbitrationTimeout: tiempo que espera un nodo un mensage del árbitro, si se supera este tiempo se asume que la red está dividida.

UndoIndexBuffer: se utiliza durante los local checkpoints para registrar las actividades durante la escritura de los local checkpoints.


Template warning.png

No es seguro reducir el valor de este parámetro

 


UndoDataBuffer: tiene la misma función que el anterior excepto que en este caso se refiere a la memoria de datos en lugar de la de índices.


Template warning.png

No es seguro reducir el valor de este parámetro

 


RedoBuffer: registra las actividades de actualización para que puedan volver a ser ejecutadas en caso de que el sistema se reinicie y dejar así el cluster en un estado consistente.

Los niveles de log van de 0 (no se reporta nada al log) a 15 (toda actividad relacionada es reportadda al log).

LogLevelStartup: nivel de registro de actividad durante el proceso de arranque

LogLevelShutdown: nivel de registro de actividad durante el proceso de parada

LogLevelStatistic: nivel de registro de actividad de eventos estadísticos (lecturas de claves primarias, actualizacioes, inserciones, etc...)

LogLevelCheckpoint: nivel de registro de actividad durante checkpoints locales y globales.

LogLevelNodeRestart: nivel de registro de actividad durante el reinicio de un Nodo

LogLevelConnection: nivel de registro de actividad de eventos generados por conexiones entre nodos.

LogLevelError: nivel de registro de actividad de avisos y errores.

LogLevelCongestion: nivel de registro de actividad de congestión del cluster.

LogLevelInfo: nivel de registro de actividad de información general del cluster.

MemReportFrequency: número de segundos entre registos de uso de memoria de los nodos de datos, se registra la memoria de datos y la de índices tanto en porcentaje como en número de páginas de 32KB.

StartupStatusReportFrequency: Indica los reports cuando se inicializan los redologs porque el se ha arrancado un nodo de datos con –initial. El proceso de inicialización de redologs puede ser largo si el tamaño de estos es grande, y este parámetro permite registrar la evolución de esta inicialización.

BackupReportFrequency: indica la frecuencica con la que se registra la evolución del backup en el log durante el proceso de creación de una copia de seguridad.

BackupDataBufferSize: durante el proceso de Backup hay dos buffers que se usan para enviar datos al disco, cuando el buffer se llena hasta el tamaño de BackupWriteSize se empieza a volcar los datos a disco y el proceso de Backup puede continuar llenando este buffer mientras tenga espacio. El tamaño de este parámetro debe ser al menos el de BackupWriteSize + 188 KB

BackupLogBufferSize: registra las escrituras en tablas durante el proceso de Backup si se queda sin espacio en el backup log buffer el backup falla. El tamaño de este parámetro debe ser al menos el de BackupWriteSize + 16 KB

BackupMemory: simplemente la suma de BackupDataBufferSize y BackupLogBufferSize.

BackupWriteSize: tamaño por defecto de los mensajes almacenados en disco por el backup log buffer y el backup data buffer.

BackupMaxWriteSize: tamaño por defecto de los mensajes almacenados en disco por el backup log buffer y el backup data buffer. El tamaño de este parámetro debe ser al menos el de BackupWriteSize.

BackupDataDir: directorio donde se almacenan las copias de seguridad, dentro de este directorio se crea un subdirectorio llamado BACKUPS y dentro de el uno por cada copia de seguridad llamado BACKUP-X (donde X es el número de la copia de seguridad)

LockExecuteThreadToCPU: cadena con los identificadores de las CPUs en las que se ejecutarán los hilos de los nodos de datos (ndbmtd) debe haber tantos identificadores como indique el parámetro MaxNoOfExecutionThreads.

RealTimeScheduler: establecer este parámetro a 1 habilita el planificador en tiempo real de los hilos.

SchedulerExecutionTimer: tiempo en microsegundos de ejecución de los hilos en el planificador antes de ser enviados.

SchedulerSpinTimer: tiempo de ejecución en microsegundos de los hilos antes de dormirse.

MaxNoOfExecutionThreads: número de hilos de ejecución (para 8 o más cores se recomienda establecer este parámetro con un valor de 8)

1.2.2.4 Parámetros de configuración individual para cada nodo de datos

Debe haber una sección [ndbd] por cada nodo de datos.

id: Identificador de nodo, debe ser único en todo el fichero de configuración.

Hostname: Nombre del host o dirección IP del nodo de datos.

1.2.2.5 Parámetros de configuración común a los nodos API o SQL

ArbitrationRank: Este parámetro sirve para definir que nodo hace de árbitro (Los nodos de gestión y los nodos SQL pueden hacer de árbitros, se recomienda que sean los nodos de gestión los que tengan alta prioridad) , puede tomar valores de 0 a 2:

  • 0: El nodo nunca será usado como árbitro
  • 1: El nodo tiene alta prioridad, tendrá prioridad sobre nodos de baja prioridad
  • 2: El nodo tiene baja prioridad, y sólo se utilizará como árbitro si no hay otros nodos de más prioridad disponibles.

En el caso de los nodos API o SQL se romienda establecer el valor de ArbitrationRank a 2 permitiendo que sean los nodos manager (que deberían tener ArbitrationRank a 1) los que tomen el papel de árbitro.

BatchByteSize: Limita el tamaño de bloques de proceso por lotes que se utilizan cuando se hacen escaneos completos de las tablas o escaneos por rangos sobre índices.

BatchSize: Limita el número de bloques de proceso por lotes que se utilizan cuando se hacen escaneos completos de las tablas o escaneos por rangos sobre índices.

MaxScanBatchSize: Limite total para todo el cluster de tamaño de bloques de proceso por lotes que se utilizan cuando se hacen escaneos completos de las tablas o escaneos por rangos sobre índices. Este parámetro evita que se envíen demasiados datos dese muchos nodos en paralelo.

1.2.2.6 Parámetros de configuración individual para cada nodo API o SQL

Debe haber una sección [mysqld] por cada nodo API o SQL, además debería haber secciones [mysqld] extra para permitir conexiones de chequeo o de backup, para ello se recomienda dfinir dichas conexiones extra dandoles identificador de nodo, pero no hostname, de forma que cualquier host pueda conectar mediante las conexiones extra.

id: Identificador de nodo, debe ser único en todo el fichero de configuración.

Hostname: Nombre del host o dirección IP del nodo de datos.


Info.png

En nuestra documentacion y arquitectura de ejemplo, hemos hecho que los nodos API/SQL y el nodo de datos NDB estén fisicamente en el mismo sistema, esto no tiene porqué ser así

 


1.3 Inicio del Cluster

1.3.1 Inicio del Manager

Info.png

Se han configurado los servidores para la parada / arranque automático de los demonios de gestion del cluster. Los procedimientos que aquí se detallan son para hacer las paradas y arranques manuales y para conocer el funcionamiento de los mismos. Se ha desarrollado un script para la parada y arranque y se ha programado en el nivel por defecto de arranque de los sistemas (Nivel 3)

 


Una vez hechos los procedimientos de instalación y configuración del sistema Manager, debemos iniciar el servicio. Para iniciar el nodo de administración, ejecutamos el siguiente comando en la consola: (como root) Nodo de Adminstración 1:

ndb_mgmd  --config-file=/var/lib/mysql-cluster/config.ini --configdir=/var/lib/mysql-cluster

De igual forma mediante el script que se ha desarrollado para tal efecto en

/etc/init.d/cluster_mgmt start

Nodo de Administración 2:

ndb_mgmd -c 10.1.1.221:1186 –-ndb-nodeid=2

De igual forma mediante el script que se ha desarrollado para tal efecto en

/etc/init.d/cluster_mgmt start

Si además se quiere cargar una nueva versión del fichero de confiuración se les debe pasar al arranque de ambos nodos el parámetro –initial

El script de control del servicio (etc/init/cluster_mgmt) se puede utilizar para arrancar el nodo (start) y para pararlo (stop) o reiniciarlo (restart) así como para saber su estado (status).

1.3.2 Inicio de los Nodos de Datos del cluster (SOLO INSTALACIÓN)

Una vez el Manager ha sido lanzado, procedemos a lanzar los nodos con el siguiente comando en la consola (como root):

ndbmtd -–initial

Esto establece la configuración inicial los nodos (que obtienen del manager) y reserva el espacio de redo log. Inicio “normal” de los nodos de datos del cluster

En caso de un renicio de uno de los nodos, por caida o por algún tipo de parada técnica, los nodos se arrancarán usando tan sólo ndbmtd, sin el --initial, ya que dicho parámetro hace que se cargue de cero la configuración y reinicia los ficheros de datos del nodo y los redo log (haciendo necesario restaurar los datos dese un Backup).

ndbmtd

Se podrá usar el script desarrollado para el control del demonio del nodo de almacenamiento del cluster:

/etc/init.d/cluster_node start

Dicho script se puede utilizar para arrancar el nodo (start) y para pararlo (stop) o reiniciarlo (restart) así como para saber su estado (status).


Template warning.png

Por la importancia del proceso de arranque de los nodos de datos del cluster, este proceso NO SE AUTOMATIZA. Es decir, hay que realizarlo manualmente después de un reinicio

 


El proceso de arranque de los nodos es muy delicado (si se hizo una parada desordenada, o el cluster se ha quedado en un estado no sincronizado, habra que consultar los logs y la documentación del fabricante (MySQL) para saber como solucionar el problema antes de arrancar los nodos.

El proceso de arranque de un nodo de datos puede ser un proceso LENTO, y puede tardar de 10 a 20 minutos. Para consultar el estado, dentro del proceso de arranque, utilice el comando “SHOW” dentro de la consola de gestión del cluster de MySQL, tal y como se indica más adelante.

1.3.3 Inicio de los Nodos SQL

Los Nodos SQL se arrancan utilizando el comando:

/etc/init.d/mysql start

y se paran con

/etc/init.d/mysql stop 

como si fuera un servidor mysql normal. Esto hace que se conecten todos los threads definidos en el /etc/my.cnf al cluster completando así el arranque completo del cluster.

1.3.4 Ver el estado del Cluster

Una vez tenemos todos los elementos iniciados, podemos ver si se han conectado al cluster correctamente. Para ello en la consola del Manager escribimos:

ndb_mgm

Y entramos en la interfaz de administración del cluster, una vez en ella escribimos:

show

Y obtendremos algo como esto:

Connected to Management Server at: 10.1.1.221:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=3    @10.1.1.215  (mysql-5.1.34 ndb-7.0.6, Nodegroup: 0, Master)
id=4    @10.1.1.216  (mysql-5.1.34 ndb-7.0.6, Nodegroup: 0)

[ndb_mgmd(MGM)] 2 node(s)
id=1    @10.1.1.221  (mysql-5.1.34 ndb-7.0.6)
id=2    @10.1.1.216  (mysql-5.1.34 ndb-7.0.6)

[mysqld(API)]   29 node(s)
id=11   @10.1.1.215  (mysql-5.1.34 ndb-7.0.6)
id=12   @10.1.1.216  (mysql-5.1.34 ndb-7.0.6)
id=13   @10.1.1.216  (mysql-5.1.34 ndb-7.0.6)
id=14   @10.1.1.216  (mysql-5.1.34 ndb-7.0.6)
id=15   @10.1.1.216  (mysql-5.1.34 ndb-7.0.6)
id=16   @10.1.1.216  (mysql-5.1.34 ndb-7.0.6)
.

Como vemos en esa salida, tenemos los Nodos de gestió, los Nodos de Datos y los Nodos SQL o de API conectados en el cluster, además hay una serie de nodos SQL o de API libres, sin conexiones, que aceptan conexiones desde cualquier host, y que se utilizarán para consultas de estado, creación de backups, etc...

Si acabamos de iniciar los nodos de datos veremos un mensaje como el siguiente:

[ndbd(NDB)] 2 node(s) id=3 @10.1.1.215 (mysql-5.1.34 ndb-7.0.6, starting, Nodegroup: 0, Master) id=4 @10.1.1.216 (mysql-5.1.34 ndb-7.0.6, starting, Nodegroup: 0)

Esto indica que el sistema está todavia inicializando los nodos de datos.

1.3.5 Inicio y parada de nodos desde el Manager.

Es posible la parada e inicio de nodos en el cluster desde el Manager, es decir, sin tener que ir a la consola de cada nodo.

Para parar un nodo usaremos la orden:

<id> stop

Siendo el <id> el número que aparece al hacer un show. Ejemplo:

2 stop

Para iniciar ese nodo que hemos parado usaremos la orden:

<id> start

Siendo el <id> el número que aparece al hacer un show. Ejemplo:

2 start

1.4 Backups del Cluster

Es recomendable hacer una copia de seguridad de los datos y estructuras del cluster. Para ello se han de usar los siguientes pasos:

  1. .Arrancar el servidor de administración (ndb_mgm).
  2. .Ejecutar el comando START BACKUP.
  3. .Obtendremos una salida como la siguiente:
ndb_mgm> START BACKUP
Waiting for completed, this may take several minutes
Node 2: Backup 6 started from node 1
Node 2: Backup 6 started from node 1 completed
StartGCP: 267411 StopGCP: 267414
#Records: 2050 #LogRecords: 0
Data: 32880 bytes Log: 0 bytes

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

ndb_mgm -e "START BACKUP"

Estos backups crearán una serie de ficheros en el directorio: /var/lib/mysql-cluster/BACKUP/BACKUP-X de cada nodo del cluster, donde la X es el número de backup

En dicho directorio se guardan una serie de ficheros con las siguientes extensiones:

  • Data: Datos del cluster
  • .ctl: Metadatos del cluster
  • .log: Ficheros de LOG del cluster.

1.4.1 Restaurado de copias de seguridad.

Cada nodo almacena “una parte” de la BBDD en los backups, de forma que para recomponer el “cuadro completo” hay que hacer un restore de todos los elementos del cluster, en orden y uno por uno.

1.4.1.1 Pasos previos

Para restaurar un backup previamente hay que “reinicializar” los nodos y eliminar su contenido. Esto es, arrancarlos con el parámetro –initial.

ndbmtd –initial

1.4.1.2 Orden del proceso de restauración

Para restaurar un backup, hay que hacerlo primero en el nodo marcado como “master”. La primera restauración creará los metadatos, el resto solo los datos.

1.4.2 Proceso de restauración

La orden para restaurar un backup es la siguiente (tomamos como ejemplo la restauración del backup #5 sobre el node id #3):

En el primer nodo, ejecutamos lo siguiente en la consola de Linux

ndb_restore -b 5 -n 3 -m -r /var/lib/mysql-cluster/BACKUP/BACKUP-5

Y obtendremos la siguiente salida:

Backup Id = 5
Nodeid = 3
backup path = /var/lib/mysql-cluster/BACKUP/BACKUP-5
Ndb version in backup files: Version 5.0.51

En el segundo y sucesivos nodos, será similar pero sin el parámetro “-m”

ndb_restore -b 5 -n 4 -r /var/lib/mysql-cluster/BACKUP/BACKUP-5

Las opciones que se le pasan se detallan a continuación:

  • -b: indica el numero de backup
  • -n: indica el nodo en concreto (que se puede mirar en el manager con un "show")
  • -m: indica que se restauren los meta datos del cluster
  • -r: indica que restauren los datos en el cluster.

Luego hay que poner el path al directorio (hay que poner el path al backup que hayamos puesto en el -b)

1.5 Logs del Cluster

El cluster de MySQL provee dos tipos de logs

1.5.1 El log del cluster

Incluye los eventos generados por cada nodo del cluster. Es el log más recomendable para mirar si algo falla, ya que incluye la información del cluster entero.

Por defecto este log está en el directorio /var/lib/mysql-cluster/ndb_1_cluster.log

Un ejemplo de este tipo de logs es el siguiente:

2009-05-26 11:56:59 [MgmSrvr] INFO     -- Node 5: mysqld --server-id=0
2009-05-26 12:14:32 [MgmSrvr] INFO     -- Mgmt server state: nodeid 6 reserved for ip 10.1.1.220, m_reserved_nodes 0000000000000062.
2009-05-26 12:14:32 [MgmSrvr] INFO     -- Node 6: mysqld --server-id=0
2009-05-26 13:35:47 [MgmSrvr] INFO     -- Mgmt server state: nodeid 6 freed, m_reserved_nodes 0000000000000022.
2009-05-26 13:46:44 [MgmSrvr] INFO     -- Mgmt server state: nodeid 6 reserved for ip 10.1.1.220, m_reserved_nodes 0000000000000062.
2009-05-26 13:46:44 [MgmSrvr] INFO     -- Node 6: mysqld --server-id=0
2009-05-26 13:46:44 [MgmSrvr] INFO     -- Node 2: Node 6 Connected
2009-05-26 13:46:45 [MgmSrvr] INFO     -- Node 3: Node 6 Connected
2009-05-26 13:46:45 [MgmSrvr] INFO     -- Node 3: Node 6: API version 5.0.51
2009-05-26 13:46:45 [MgmSrvr] INFO     -- Node 2: Node 6: API version 5.0.51

La información útil está identificada con las palabras WARNING, ERROR y CRITICAL.

1.5.2 Logs de los Nodos

Cada nodo del cluster tiene sus propios logs, que se dividen a su vez en dos sub-logs. (todos los logs están bajo el directorio /var/lib/mysql-cluster/

1.5.2.1 ndb_X_out.log

El primer log y más general se llama: ndb_X_out.log (siendo X el id del nodo). Este log contiene la información general del cluster y tiene el siguiente aspecto:


2009-09-29 13:15:51 [ndbd] INFO     -- Angel pid: 30514 ndb pid: 30515
NDBMT: MaxNoOfExecutionThreads=8
NDBMT: workers=4 threads=4
2009-09-29 13:15:51 [ndbd] INFO     -- NDB Cluster -- DB node 3
2009-09-29 13:15:51 [ndbd] INFO     -- mysql-5.1.34 ndb-7.0.6 --
2009-09-29 13:15:51 [ndbd] INFO     -- WatchDog timer is set to 40000 ms
2009-09-29 13:15:51 [ndbd] INFO     -- Ndbd_mem_manager::init(1) min: 4266Mb initial: 4286Mb
Adding 4286Mb to ZONE_LO (1,137151)
NDBMT: num_threads=7
thr: 1 tid: 30520 cpu: 1 OK BACKUP(0) DBLQH(0) DBACC(0) DBTUP(0) SUMA(0) DBTUX(0) TSMAN(0) LGMAN(0) PGMAN(0) RESTORE(0) DBINFO(0) PGMAN(5) 
thr: 0 tid: 30519 cpu: 0 OK DBTC(0) DBDIH(0) DBDICT(0) NDBCNTR(0) QMGR(0) NDBFS(0) TRIX(0) DBUTIL(0) 
thr: 2 tid: 30521 cpu: 2 OK PGMAN(1) DBACC(1) DBLQH(1) DBTUP(1) BACKUP(1) DBTUX(1) RESTORE(1) 
thr: 3 tid: 30522 cpu: 3 OK PGMAN(2) DBACC(2) DBLQH(2) DBTUP(2) BACKUP(2) DBTUX(2) RESTORE(2) 
thr: 4 tid: 30523 cpu: 4 OK PGMAN(3) DBACC(3) DBLQH(3) DBTUP(3) BACKUP(3) DBTUX(3) RESTORE(3) 
thr: 6 tid: 30515 cpu: 6 OK CMVMI(0) 
thr: 5 tid: 30524 cpu: 5 OK PGMAN(4) DBACC(4) DBLQH(4) DBTUP(4) BACKUP(4) DBTUX(4) RESTORE(4) 
saving 0x7f6161d38000 at 0x994538 (0)
2009-09-29 13:15:53 [ndbd] INFO     -- Start initiated (mysql-5.1.34 ndb-7.0.6)
saving 0x7f61621e8000 at 0x9ab2d8 (0)
NDBFS/AsyncFile: Allocating 310392 for In/Deflate buffer

1.5.2.2 ndb_X_error.log

El segundo tipo de log es el log de errores del cluster que se llama: ndb_X_error.log (siendo X el id del nodo). En este log tenemos los errores que se producen en el cluster y que nos enlazan a otro log creado a nivel más alto de debug

Aquí vemos la salida de un fichero de log de errores enlazando a otro log de trazas:

Current byte-offset of file-pointer is: 1067                      

Time: Friday 9 October 2009 - 12:57:13
Status: Temporary error, restart node
Message: Node lost connection to other nodes and can not form a unpartitioned cluster, please investigate if there are error(s) on other node(s) (Arbitration error)
Error: 2305
Error data: Arbitrator decided to shutdown this node
Error object: QMGR (Line: 5300) 0x0000000e
Program: ndbmtd
Pid: 30515
Trace: /var/lib/mysql-cluster/ndb_3_trace.log.1 /var/lib/mysql-cluster/ndb_3_trace.log.1_t1 /var/lib/mysql-cluster/ndb_3_
Time: Tuesday 24 November 2009 - 12:01:59
Status: Temporary error, restart node
Message: Node lost connection to other nodes and can not form a unpartitioned cluster, please investigate if there are error(s) on other node(s) (Arbitration error)
Error: 2305
Error data: Arbitrator decided to shutdown this node
Error object: QMGR (Line: 5300) 0x0000000a
Program: /usr/sbin/ndbmtd
Pid: 10348
Trace: /var/lib/mysql-cluster/ndb_3_trace.log.2 /var/lib/mysql-cluster/ndb_3_trace.log.2_t1 /var/lib/mysql-c 

Como vemos nos deja una traza en los siguientes ficheros: /var/lib/mysql-cluster/ndb_3_trace.log.2, /var/lib/mysql-cluster/ndb_3_trace.log.2_t1, ...

Podemos ver un fragmento de uno de estos ficheros y ver su aspecto:

--------------- Signal ----------------
r.bn: 252 "QMGR", r.proc: 3, r.sigId: -411879481 gsn: 164 "CONTINUEB" prio: 0
s.bn: 252 "QMGR", s.proc: 3, s.sigId: -411879485 length: 3 trace: 0 #sec: 0 fragInf: 0
H'00000005 H'00000002 H'00000007
--------------- Signal ----------------
r.bn: 253 "NDBFS", r.proc: 3, r.sigId: -411879482 gsn: 164 "CONTINUEB" prio: 0
s.bn: 253 "NDBFS", s.proc: 3, s.sigId: -411879492 length: 1 trace: 0 #sec: 0 fragInf: 0
Scanning the memory channel every 10ms

Es relativamente fácil monitorizar estos logs con el propio Pandora haciendo búsquedas de las palabras WARNING y CRITICAL.

1.6 Procedimientos generales

Se presentan incialmente los procedimientos individuales de gestión de cada tipo de nodo, y finalmente el procedimiento de inicio y parada del cluster.

1.6.1 Gestión del proceso Manager del cluster

Como root:

Para arrancar el manager del cluster:

/etc/init.d/cluster_mgmt start

Para verificar que está corriendo:

/etc/init.d/cluster_mgmt status

Para parar el proceso del Manager:

/etc/init.d/cluster_mgmt stop

1.6.2 Gestión de los Nodos desde el Manager

Entramos en la shell del Manager del cluster con:

ndb_mgm

Paramos el nodo que queramos con:

2 stop

Siendo el “2” el ID del nodo a parar

Para iniciar un nodo usaremos la orden:

2 start

1.6.3 Gestión de los Nodos de datos con los scripts de arranque

Como root:

Para arrancar un nodo de datos

/etc/init.d/cluster_node start

Para parar un nodo de datos:

/etc/init.d/cluster_node stop

Para inicializar un nodo de datos:


Template warning.png

Esta operación borra los datos del nodo del cluster y recrea los redologs y puede requerir una recuperación desde backup

 


/etc/init.d/ndbmtd initial

1.6.4 Gestión de los nodos SQL con scripts de arranque

Los nodos SQL se gestionan de la misma manera que un servidor MySQL que no esté en cluster, mediante el script de inicio /etc/init.d/mysql

Para arrancar tantos nodos SQL como indique el fichero /etc/my.cnf

/etc/init.d/mysql start

Para parar tantos nodos SQL como indique el fichero /etc/my.cnf

/etc/init.d/mysql stop

Lanzamiento de un Nodo manualmente si se cae. Si un nodo se cae deberemos arrancarlo manualmente desde la linea de comandos siguiendo la siguiente secuencia:

Primero hay que asegurarse que no hay ninguna instancia del Nodo corriendo:

ps -fea | grep -v grep | grep ndbmtd

O bien:

/etc/init.d/cluster_node status

Si el comando muestra algún proceso ndbmtd corriendo, deberíamos mirar los logs para ver por que aun con el proceso corriendo se ha considerdado caido.

Para iniciar el nodo usaremos:

/etc/init.d/cluster_node start

1.6.5 Creación de backups desde la linea de comandos

Este es el método de creación de un backup desde la linea de comandos de forma manual:

ndb_mgm -e "START BACKUP”

Los backups se quedan en:

/var/lib/mysql-cluster/BACKUP

El script de backup diario está en el Apendice1

1.6.6 Restaurado de backups desde la linea de comandos

Una vez dentro del Nodo del que se quiere restaurar el backup:

ndb_restore -b X -n Y -m -r /var/lib/mysql-cluster/BACKUP/BACKUP-X

La “X” debe ser substituida por el número del backup que se desea cambiar y la “Y” por el número del Nodo en el que se está.

1.6.7 Procedimiento de parada total del cluster

Antes de parar el cluster se debería hacer un backup del mismo, siguiendo el procedimiento anteriormente indicado o utlizando el script de backup proporcioando en el Apendice 1.

Una vez se ha completado el backup, también es recomendable parar los servidores de Pandora FMS antes de parar el cluster.

Con todos los preparativos necesarios realizados, el cluster se parará desde el manager con la orden SHUTDOWN. Desde la consola:

ndb_mgm

ndbm_mgm> SHUTDOWN

O bien desde la linea de comandos

ndb_mgm -e SHUTDOWN

Esto parará los nodos de gestión y de datos del cluster, y los nodos SQL (o API) se paran por separado tal y como se ha indicado anteriormente.

1.6.8 Procedimiento de arranque del cluster

El arranque del cluster completo es una operación que debería ser supervisada y durante la cual se debe revisar el log principal del cluster y comprobar que todo ha funcionado correctamente.

Estando todos los nodos parados, se debe arrancar en primer lugar el manager principal (el de pandoradbhis), indicándole el fichero de configuración del cluster.

Utilizando el script de arranque.

/etc/init.d/cluster_mgmt start

O bien desde la linea de comandos.

/usr/sbin/ndb_mgmd –config-file=/var/lib/mysql-cluster/config.ini --configdir=/var/lib/mysql-cluster

A continuación se arranca el manager secundario del cluster (el de pandora2) dándole la cadena de conexión al manager pricipal y su id de nodo.

Utilizando el scritp de arranque.

/etc/init.d/cluster_mgmt start

O bien desde la linea de comandos

/usr/sbin/ndb_mgmd -c pandoradbhis –-ndb-nodeid=2 –configdir=/var/lib/mysql-cluster

En este punto se puede conectar a cualquiera de los dos managers y mostrar el estado con un SHOW, pero es importante indicar que a estas alturas del arranque los nodos manager no se ven entre si ya que se comunican a través de los nodos de datos, y por tanto cada uno mostrará una salida diferente en la que el único nodo conectado del cluster es el propio nodo manager.

Una vez arrancados los 2 nodos manager se procede a arancar los 2 nodos de datos (tanto en pandoradb1 como en pandoradb2) tal y como se ha indicado anteriormente, por ejemplo con el script de arranque:

/etc/init.d/cluster_node start

El proceso de arranque de los nodos de datos es lento y consta de varias fases que se pueden seguir en el log del cluster.

Mientras tanto se arrancan los nodos SQL o API (tanto en pandoradb1 como en pandoradb2) también tal y como se inidicó anteriormente.

/etc/init.d/mysql start

Una vez dadas todas las órdenes de arranque hay que comprobar en el log del cluster que el arranque se completa sin ningún error. Al final se puede ver que todos los servidores están conectados desde el manager con el comando SHOW.

ndb_mgm -e SHOW

Y viendo que todos los nodos arrancados están conectados.

1.7 Apéndice. Ejemplos de ficheros de configuración

1.7.1 /etc/mysql/ndb_mgmd.cnf

Fichero del gestor del Cluster. El gestor secundario obtiene la configuración del primario (que tiene que estar activo cuando el secundario se arranca), pero este fichero debe estar en ambos nodos.

# MySQL Cluster Configuration file
# By Pablo de la Concepcion Sanz <[email protected]>
# This file must be present on ALL the management nodes
# in the directory /var/lib/mysql-cluster/
# For some of the  parameters there is an explanation of the
# possible values that the parameter can take following this
# format:
# ParameterName (MinValue, MaxValue) [DefaultValue]

##########################################################
# MANAGEMENT NODES                                       #
# This nodes are the ones running the management console #
##########################################################
# More info at:
# http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-ndbd-definition.html
# Common configuration for all management nodes:

[ndb_mgmd default]

# This parameter is used to define which nodes can act as arbitrators.
# Only management nodes and SQL nodes can be arbitrators.
# ArbitrationRank can take one of the following values:
#    * 0: The node will never be used as an arbitrator.
#    * 1: The node has high priority; that is, it will be preferred
#         as an arbitrator over low-priority nodes.
#    * 2: Indicates a low-priority node which be used as an arbitrator
#         only if a node with a higher priority is not available
#         for that purpose.
#
# Normally, the management server should be configured as an
# arbitrator by setting its ArbitrationRank to 1 (the default for
# management nodes) and those for all SQL nodes to 0 (the default
# for SQL nodes).
ArbitrationRank=1

# Directory for management node log files
datadir=/var/lib/mysql-cluster

# Using 2 management servers helps guarantee that there is always an
# arbitrator in the event of network partitioning, and so is
# recommended for high availability. Each management server must be
# identified by a HostName. You may for the sake of convenience specify
# a node ID for any management server, although one will be allocated
# for it automatically; if you do so, it must be in the range 1-255
# inclusive and must be unique among all IDs specified for cluster
# nodes.

[ndb_mgmd]

id=1
# Hostname or IP address of management node

hostname=10.1.1.230


[ndb_mgmd]
id=2
# Hostname or IP address of management node
hostname=10.1.1.220


#################
# STORAGE NODES #
#################
# More info at:
# http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-ndbd-definition.html

# Options affecting ndbd processes on all data nodes:
[ndbd default]

# Redundancy (number of replicas):
# Using 2 replicas is recommended to guarantee availability of data;
# using only 1 replica does not provide any redundancy, which means
# that the failure of a single data node causes the entire cluster to
# shut down. We do not recommend using more than 2 replicas, since 2 is
# sufficient to provide high availability, and we do not currently test
# with greater values for this parameter.

NoOfReplicas=2

# Directory for storage node trace files, log files, pid files and error logs.
datadir=/var/lib/mysql-cluster



### Data Memory, Index Memory, and String Memory ###
# This parameter defines the amount of space (in bytes) available for storing
# database records. The entire amount specified by this value is allocated in
# memory, so it is extremely important that the machine has sufficient
# physical memory to accommodate it.
# DataMemory (memory for records and ordered indexes) (recomended 70% of RAM)
# DataMemory antes 22938MB (recomended 70% of RAM)
DataMemory=4096MB

# IndexMemory (memory for Primary key hash index and unique hash index)
# Usually between 1/6 or 1/8 of the DataMemory is enough, but depends on the
# number of unique hash indexes (UNIQUE in table def)
# Also can be calculated as 15% of RAM
# IndexMemory antes 4915MB
IndexMemory= 512MB

# This parameter determines how much memory is allocated for strings
# such as table names
#  * A value between 0 and 100 inclusive is interpreted as a percent of the
#    maximum default value (wich depends on a number of factors)
#  * A value greater than 100 is interpreted as a number of bytes.
StringMemory=25

### Transaction Parameters ###
# MaxNoOfConcurrentTransactions (32,4G) [4096]
# Sets the number of parallel transactions possible in a node
#
# This parameter must be set to the same value for all cluster data nodes.
# This is due to the fact that, when a data node fails, the oldest surviving
# node re-creates the transaction state of all transactions that were ongoing
# in the failed node.
#
# Changing the value of MaxNoOfConcurrentTransactions requires a complete
# shutdown and restart of the cluster.
# MaxNoOfConcurrentTransactions antes 4096
MaxNoOfConcurrentTransactions=8192

# MaxNoOfConcurrentOperations (32,4G) [32k]
# Sets the number of records that can be in update phase or locked
# simultaneously.
MaxNoOfConcurrentOperations=10000000

# MaxNoOfLocalOperations (32,4G)
# Recomentded to set (110% of MaxNoOfConcurrentOperations)
MaxNoOfLocalOperations=11000000

### Transaction Temporary Storage ###
# MaxNoOfConcurrentIndexOperations (0,4G) [8k]
# For queries using a unique hash index, another temporary set of operation
# records is used during a query's execution phase. This parameter sets the
# size of that pool of records. Thus, this record is allocated only while
# executing a part of a query. As soon as this part has been executed, the
# record is released. The state needed to handle aborts and commits is handled
# by the normal operation records, where the pool size is set by the parameter
# MaxNoOfConcurrentOperations.

#
# The default value of this parameter is 8192. Only in rare cases of extremely
# high parallelism using unique hash indexes should it be necessary to increase
# this value. Using a smaller value is possible and can save memory if the DBA
# is certain that a high degree of parallelism is not required for the cluster.
MaxNoOfConcurrentIndexOperations=8192

# MaxNoOfFiredTriggers (0,4G) [4000]
# The default value is sufficient for most situations. In some cases it can
# even be decreased if the DBA feels  certain the need for parallelism in the
# cluster is not high.
MaxNoOfFiredTriggers=4000

# TransactionBufferMemory (1k,4G) [1M]
# The memory affected by this parameter is used for tracking operations fired
# when updating index tables and reading unique indexes. This memory is used to
# store the key and column information for these operations. It is only very
# rarely that the value for this parameter needs to be altered from the default.
TransactionBufferMemory=1M

### Scans and Buffering ###

# MaxNoOfConcurrentScans (2,500) [256]
# This parameter is used to control the number of parallel scans that can be
# performed in the cluster. Each transaction coordinator can handle the number
# of parallel scans defined for this parameter. Each scan query is performed
# by scanning all partitions in parallel. Each partition scan uses a scan
# record in the node where the partition is located, the number of records
# being the value of this parameter times the number of nodes. The cluster
# should be able to sustain MaxNoOfConcurrentScans scans concurrently from all
# nodes in the cluster.
MaxNoOfConcurrentScans=400

# MaxNoOfLocalScans (32,4G)
# Specifies the number of local scan records if many scans are not fully
# parallelized. If the number of local scan records is not provided, it is
# calculated as the product of MaxNoOfConcurrentScans and the number of data
# nodes in the system. The minimum value is 32.
# MaxNoOfLocalScans antes 32
MaxNoOfLocalScans=6400

# BatchSizePerLocalScan (1,992) [64]
# This parameter is used to calculate the number of lock records used to
# handle concurrent scan operations.
#

# The default value is 64; this value has a strong connection to the
# ScanBatchSize defined in the SQL nodes.
BatchSizePerLocalScan=512

# LongMessageBuffer (512k,4G) (4M)
# This is an internal buffer used for passing messages within individual nodes
# and between nodes. Although it is highly unlikely that this would need to be
# changed, it is configurable. In MySQL Cluster NDB 6.4.3 and earlier, the
# default is 1MB; beginning with MySQL Cluster NDB 7.0.4, it is 4MB.
# LongMessageBuffer antes 32M
LongMessageBuffer=4M

### Logging and Checkpointing ###

# Redolog
# Set NoOfFragmentLogFiles to 6xDataMemory [in MB]/(4 *FragmentLogFileSize [in MB]
# The "6xDataMemory" is a good heuristic and is STRONGLY recommended.
# NoOfFragmentLogFiles=135
NoOfFragmentLogFiles=300

# FragmentLogFileSize (3,4G) [16M]
# Size of each redo log fragment, 4 redo log fragment makes up on fragment log
# file. A bigger Fragment log file size thatn the default 16M works better with

# high write load and is strongly recommended!!
# FragmentLogFileSize=256M
FragmentLogFileSize=16M

# By default, fragment log files are created sparsely when performing an
# initial start of a data node â that is, depending on the operating system
# and file system in use, not all bytes are necessarily written to disk.
# Beginning with MySQL Cluster NDB 6.3.19, it is possible to override this
# behavior and force all bytes to be written regardless of the platform
# and file system type being used by mean of this parameter.
# InitFragmentLogFiles takes one of two values:

#  * SPARSE. Fragment log files are created sparsely. This is the default value

#  * FULL. Force all bytes of the fragment log file to be written to disk.

# InitFragmentLogFiles (SPARSE,FULL) [SPARSE]

InitFragmentLogFiles=FULL

# This parameter sets a ceiling on how many internal threads to allocate for
# open files. Any situation requiring a change in this parameter should be
# reported as a bug.
MaxNoOfOpenFiles=80

# This parameter sets the initial number of internal threads to allocate for
# open files.
InitialNoOfOpenFiles=37

# MaxNoOfSavedMessages [25]
# This parameter sets the maximum number of trace files that are kept before
# overwriting old ones. Trace files are generated when, for whatever reason,
# the node crashes.
MaxNoOfSavedMessages=25



### Metadata Objects ###
# MaxNoOfAttributes (32, 4294967039) [1000]
# Defines the number of attributes that can be defined in the cluster.
#MaxNoOfAttributes antes 25000
MaxNoOfAttributes=4096

# MaxNoOfTables  (8, 4G) [128]
# A table object is allocated for each table and for each unique hash
# index in the cluster. This parameter sets the maximum number of table
# objects for the cluster as a whole.
MaxNoOfTables=8192

# MaxNoOfOrderedIndexes (0, 4G) [128]
# Sets the total number of hash indexes that can be in use in the system
# at any one time
#MaxNoOfOrderedIndexes antes 27000
MaxNoOfOrderedIndexes=2048
#MaxNoOfUniqueHashIndexes: Default value 64 Each Index 15 KB per node
#MaxNoOfUniqueHashIndexes antes 2500
MaxNoOfUniqueHashIndexes=1024
# MaxNoOfTriggers (0, 4G) [768]
# This parameter sets the maximum number of trigger objects in the cluster.
#MaxNoOfTriggers antes 770
MaxNoOfTriggers=4096

### Boolean Parameters ###

# Most of this parameters can be set to true (1 or Y) or false (0 or N)

# LockPagesInMainMemory (0,2) [0]
# On Linux and Solaris systems, setting this parameter locks data node
# processes into memory. Doing so prevents them from swapping to disk,
# which can severely degrade cluster performance.
# Possible values:
#       * 0: Disables locking. This is the default value.
#       * 1: Performs the lock after allocating memory for the process.
#       * 2: Performs the lock before memory for the process is allocated.
LockPagesInMainMemory=1
# This parameter specifies whether an ndbd  process should exit or perform
# an automatic restart when an error condition is encountered.
StopOnError=1
# This feature causes the entire  cluster to operate in diskless mode.
# When this feature is enabled, Cluster online backup is disabled. In
# addition, a partial start of the cluster is not possible.
Diskless=0
# Enabling this parameter causes NDBCLUSTER to try using O_DIRECT
# writes for local checkpoints and redo logs; this can reduce load on
# CPUs. We recommend doing so when using MySQL Cluster NDB 6.2.3 or
# newer on systems running Linux kernel 2.6 or later.
ODirect=1
# Setting this parameter to 1 causes backup files to be compressed. The
# compression used is equivalent to gzip --fast, and can save 50% or more
# of the space required on the data node to store uncompressed backup files
CompressedBackup=1
# Setting this parameter to 1 causes local checkpoint files to be compressed.
# The compression used is equivalent to gzip --fast, and can save 50% or
# more of the space required on the data node to store uncompressed
# checkpoint files
CompressedLCP=1

### Controlling Timeouts, Intervals, and Disk Paging ###

# Most of the timeout values are specified in milliseconds. Any exceptions
# to this are mentioned where applicable.
# TimeBetweenWatchDogCheck (70,4G) [6000]
# To prevent the main thread from getting stuck in an endless loop at some
# point, a âwatchdogâ
                     # the number of milliseconds between checks. If the process remains in the
# same state after three checks, the watchdog thread terminates it.
TimeBetweenWatchDogCheck=40000
# TimeBetweenWatchDogCheckInitial (70,4G) [6000]
# This is similar to the TimeBetweenWatchDogCheck parameter, except that
# TimeBetweenWatchDogCheckInitial controls the amount of time that passes
# between execution checks inside a database node in the early start phases
# during which memory is allocated.
TimeBetweenWatchDogCheckInitial=60000
# StartPartialTimeout (0,4G) [30000]
# This parameter specifies how long the Cluster waits for all data nodes to
# come up before the cluster initialization routine is invoked. This timeout
# is used to avoid a partial Cluster startup whenever possible.
#
# This parameter is overridden when performing an initial start or initial
# restart of the cluster.
#
# The default value is 30000 milliseconds (30 seconds). 0 disables the timeout,
# in which case the cluster may start only if all nodes are available.
StartPartialTimeout=30000
# StartPartitionedTimeout (0, 4G) [60000]
# If the cluster is ready to start after waiting for StartPartialTimeout
# milliseconds but is still possibly in a partitioned state, the cluster waits
# until this timeout has also passed. If StartPartitionedTimeout is set to 0,
# the cluster waits indefinitely.
#
# This parameter is overridden when performing an initial start or initial
# restart of the cluster.
StartPartitionedTimeout=60000
# StartFailureTimeout (0, 4G) [0]
# If a data node has not completed its startup sequence within the time
# specified by this parameter, the node startup fails. Setting this
# parameter to 0 (the default value) means that no data node timeout
# is applied.
StartFailureTimeout=1000000
# HeartbeatIntervalDbDb (10,4G)[1500]
# One of the primary methods of discovering failed nodes is by the use of
# heartbeats. This parameter states how often heartbeat signals are sent
# and how often to expect to receive them. After missing three heartbeat
# intervals in a row, the node is declared dead. Thus, the maximum time
# for discovering a failure through the heartbeat mechanism is four times
# the heartbeat interval.
# This parameter must not be changed drastically
HeartbeatIntervalDbDb=2000
# HeartbeatIntervalDbApi (100,4G)[1500]
# Each data node sends heartbeat signals to each MySQL server (SQL node)
# to ensure that it remains in contact. If a MySQL server fails to send
# a heartbeat in time it is declared âdead,â
                                            # transactions are completed and all resources released. The SQL node
# cannot reconnect until all activities initiated by the previous MySQL
# instance have been completed. The three-heartbeat criteria for this
# determination are the same as described for HeartbeatIntervalDbDb.
HeartbeatIntervalDbApi=3000
# TimeBetweenLocalCheckpoints (0,31)[20] Base-2 Logarithm
# This parameter is an exception in that it does not specify a time to
# wait before starting a new local checkpoint; rather, it is used to
# ensure that local checkpoints are not performed in a cluster where
# relatively few updates are taking place. In most clusters with high
# update rates, it is likely that a new local checkpoint is started
# immediately after the previous one has been completed.
#
# The size of all write operations executed since the start of the
# previous local checkpoints is added. This parameter is also exceptional
# in that it is specified as the base-2 logarithm of the number of 4-byte
# words, so that the default value 20 means 4MB (4 Ã 220) of write
# operations, 21 would mean 8MB, and so on up to a maximum value of 31,
# which equates to 8GB of write operations.
# All the write operations in the cluster are added together.
TimeBetweenLocalCheckpoints=20
# TimeBetweenGlobalCheckpoints (10,32000)[2000]
#  When a transaction is committed, it is committed in main memory in all
# nodes on which the data is mirrored. However, transaction log records
# are not flushed to disk as part of the commit. The reasoning behind this
# behavior is that having the transaction safely committed on at least two
# autonomous host machines should meet reasonable standards for durability.
#
# It is also important to ensure that even the worst of cases â a complete
# crash of the cluster â is handled properly. To guarantee that this happens,
# all transactions taking place within a given interval are put into a global
# checkpoint, which can be thought of as a set of committed transactions that
# has been flushed to disk. In other words, as part of the commit process, a
# transaction is placed in a global checkpoint group. Later, this group's log
# records are flushed to disk, and then the entire group of transactions is
# safely committed to disk on all computers in the cluster.
TimeBetweenGlobalCheckpoints=2000
# TimeBetweenEpochs (0,32000)[100]
# This parameter defines the interval between synchronisation epochs for MySQL
# Cluster Replication.
TimeBetweenEpochs=100
# TransactionInactiveTimeout (0,32000)[4000]
# This parameter defines a timeout for synchronisation epochs for MySQL Cluster
# Replication. If a node fails to participate in a global checkpoint within
# the time determined by this parameter, the node is shut down.
TransactionInactiveTimeout=30000

# TransactionDeadlockDetectionTimeout (50,4G)[1200]

# When a node executes a query involving a transaction, the node waits for
# the other nodes in the cluster to respond before continuing. A failure to
# respond can occur for any of the following reasons:
#       * The node is âdeadâ
#       * The node requested to perform the action could be heavily overloaded.
# This timeout parameter states how long the transaction coordinator waits
# for query execution by another node before aborting the transaction, and
# is important for both node failure handling and deadlock detection.
TransactionDeadlockDetectionTimeout=1200
# DiskSyncSize (32k,4G)[4M]
# This is the maximum number of bytes to store before flushing data to a
# local checkpoint file. This is done in order to prevent write buffering,
# which can impede performance significantly. This parameter is NOT
# intended to take the place of TimeBetweenLocalCheckpoints.
DiskSyncSize=4M
# DiskCheckpointSpeed (1M,4G)[10M]
# The amount of data,in bytes per second, that is sent to disk during a
# local checkpoint.
DiskCheckpointSpeed=10M
# DiskCheckpointSpeedInRestart (1M,4G)[100M]
# The amount of data,in bytes per second, that is sent to disk during a
# local checkpoint as part of a restart operation.
DiskCheckpointSpeedInRestart=100M
# ArbitrationTimeout (10,4G)[1000]
# This parameter specifies how long data nodes wait for a response from
# the arbitrator to an arbitration message. If this is exceeded, the
# network is assumed to have split.
ArbitrationTimeout=10

### Buffering and Logging ###

# UndoIndexBuffer (1M,4G)[2M]
# The UNDO index buffer, is used during local checkpoints. The NDB storage
# engine uses a recovery scheme based on checkpoint consistency in
# conjunction with an operational REDO log. To produce a consistent
# checkpoint without blocking the entire system for writes, UNDO logging
# is done while performing the local checkpoint.

# This buffer is 2MB by default. The minimum value is 1MB, which is
# sufficient for most applications. For applications doing extremely
# large or numerous inserts and deletes together with large
# transactions and large primary keys, it may be necessary to
# increase the size of this buffer. If this buffer is too small,
# the NDB storage engine issues internal error code 677 (Index UNDO
# buffers overloaded).
# IMPORTANT: It is not safe to decrease the value of this parameter
# during a rolling restart.
UndoIndexBuffer=2M
# UndoDataBuffer (1M,4G)[16M]
# This parameter sets the size of the UNDO data buffer, which performs
# a function similar to that of the UNDO index buffer, except the UNDO
# data buffer is used with regard to data memory rather than index memory
# If this buffer is too small and gets congested, the NDB storage
# engine issues internal error code 891 (Data UNDO buffers overloaded).
# IMPORTANT: It is not safe to decrease the value of this parameter
# during a rolling restart.

UndoDataBuffer=16M
# RedoBuffer (1M,4G)[32M]
# All update activities also need to be logged. The REDO log makes it
# possible to replay these updates whenever the system is restarted.
# The NDB recovery algorithm uses a âfuzzyâ
                                           # together with the UNDO log, and then applies the REDO log to play
# back all changes up to the restoration point.
# If this buffer is too small, the NDB storage engine issues error
# code 1221 (REDO log buffers overloaded).
# IMPORTANT: It is not safe to decrease the value of this parameter
# during a rolling restart.
RedoBuffer=32M
#

## Logging ##

#
# In managing the cluster, it is very important to be able to control
# the number of log messages sent for various event types to stdout.
# For each event category, there are 16 possible event levels (numbered
# 0 through 15). Setting event reporting for a given event category to
# level 15 means all event reports in that category are sent to stdout;
# setting it to 0 means that there will be no event reports made in
# that category.
# More info at:
# http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-log-events.html
#
# LogLevelStartup (0,15)[1]
# The reporting level for events generated during startup of the process.
LogLevelStartup=15
# LogLevelShutdown (0,15)[0]
# The reporting level for events generated as part of graceful shutdown
# of a node.

LogLevelShutdown=15
# LogLevelStatistic (0,15)[0]
# The reporting level for statistical events such as number of primary
# key reads, number of updates, number of inserts, information relating
# to buffer usage, and so on.
LogLevelStatistic=15
# LogLevelCheckpoint (0,15)[0]
# The reporting level for events generated by local and global checkpoints.
LogLevelCheckpoint=8
# LogLevelNodeRestart (0,15)[0]
# The reporting level for events generated during node restart.
LogLevelNodeRestart=15
# LogLevelConnection (0,15)[0]
# The reporting level for events generated by connections between cluster
# nodes.
LogLevelConnection=0
# LogLevelError (0,15)[0]
# The reporting level for events generated by errors and warnings by the
# cluster as a whole. These errors do not cause any node failure but are
# still considered worth reporting.

LogLevelError=15

# LogLevelCongestion (0,15)[0]
# The reporting level for events generated by congestion. These errors do
# not cause node failure but are still considered worth reporting.
LogLevelCongestion=0
# LogLevelInfo (0,15)[0]
# The reporting level for events generated for information about the general

# state of the cluster.
LogLevelInfo=3
# MemReportFrequency (0,4G)[0]
# This parameter controls how often data node memory usage reports are recorded
# in the cluster log; it is an integer value representing the number of seconds
# between reports.
# Each data node's data memory and index memory usage is logged as both a
# percentage and a number of 32 KB pages of the DataMemory and IndexMemory.
# The minimum value in which case memory reports are logged only when memory
# usage reaches certain percentages (80%, 90%, and 100%)

MemReportFrequency=900
# When a data node is started with the --initial, it initializes the redo log
# file during Start Phase 4. When very large values are set for
# NoOfFragmentLogFiles, FragmentLogFileSize, or both, this initialization can
# take a long time. StartupStatusReportFrequency configuration parameter
# make reports on the progress of this process to be logged periodically.
StartupStatusReportFrequency=30


### Backup Parameters ###

# This section define memory buffers set aside for execution of
# online backups.
# IMPORTANT: When specifying these parameters, the following relationships
# must hold true. Otherwise, the data node will be unable to start:
#       * BackupDataBufferSize >= BackupWriteSize + 188KB
#       * BackupLogBufferSize >= BackupWriteSize + 16KB
#       * BackupMaxWriteSize >= BackupWriteSize
#
# BackupReportFrequency (0,4G)[0]
# This parameter controls how often backup status reports are issued in
# the management client during a backup, as well as how often such reports
# are written to the cluster log. BackupReportFrequency represents the time
# in seconds between backup status reports.
BackupReportFrequency=10

# BackupDataBufferSize (0,4G)[16M]
# In creating a backup, there are two buffers used for sending data to the
# disk. The backup data buffer is used to fill in data recorded by scanning
# a node's tables. Once this buffer has been filled to the level specified
# as BackupWriteSize (see below), the pages are sent to disk. While
# flushing data to disk, the backup process can continue filling this
# buffer until it runs out of space. When this happens, the backup process
# pauses the scan and waits until some disk writes have completed freed up
# memory so that scanning may continue.
BackupDataBufferSize=16M

# BackupLogBufferSize (0,4G)[16M]
# The backup log buffer fulfills a role similar to that played by the backup
# data buffer, except that it is used for generating a log of all table
# writes made during execution of the backup. The same principles apply for
# writing these pages as with the backup data buffer, except that when
# there is no more space in the backup log buffer, the backup fails.
# The default value for this parameter should be sufficient for most
# applications. In fact, it is more likely for a backup failure to be
# caused by insufficient disk write speed than it is for the backup
# log buffer to become full.
# It is preferable to configure cluster nodes in such a manner that the
# processor becomes the bottleneck rather than the disks or the network
# connections.

BackupLogBufferSize=16M

# BackupMemory (0,4G)[32]
# This parameter is simply the sum of BackupDataBufferSize and
# BackupLogBufferSize.
BackupMemory=64M

# BackupWriteSize (2k,4G)[256k]

# This parameter specifies the default size of messages written to disk
# by the backup log and backup data buffers.
BackupWriteSize=256K
# BackupMaxWriteSize (2k,4G)[1M]
# This parameter specifies the maximum size of messages written to disk
# by the backup log and backup data buffers.
BackupMaxWriteSize=1M
# This parameter specifies the directory in which backups are placed
# (The backups are stored in a subdirectory called BACKUPS)
BackupDataDir=/var/lib/mysql-cluster/


### Realtime Performance Parameters ###


# This parameters are used in scheduling and locking of threads to specific
# CPUs on multiprocessor data node hosts.
# NOTE: To make use of these parameters, the data node process must be run as
# system root.
# Setting these parameters allows you to take advantage of real-time scheduling
# of NDBCLUSTER threads (introduced in MySQL Cluster NDB 6.3.4) to get higher
# throughput.

# On systems with multiple CPUs, these parameters can be used to lock
# NDBCLUSTER
# threads to specific CPUs
# LockExecuteThreadToCPU (0,64k)
# When used with ndbd, this parameter (now a string) specifies the ID of the
# CPU assigned to handle the NDBCLUSTER  execution thread. When used with
# ndbmtd, the value of this parameter is a comma-separated list of CPU IDs
# assigned to handle execution threads. Each CPU ID in the list should be
# an integer in the range 0 to 65535 (inclusive)
# The number of IDs specified should match the number of execution threads
# determined by MaxNoOfExecutionThreads
LockExecuteThreadToCPU=0,1,2,3,4,5,6,7
# RealTimeScheduler (0,1)[0]
# Setting this parameter to 1 enables real-time scheduling of NDBCLUSTER
# threads
RealTimeScheduler=1
# SchedulerExecutionTimer (0,110000)[50]
#  This parameter specifies the time in microseconds for threads to be
# executed in the scheduler before being sent. Setting it to 0 minimizes
# the response time; to achieve higher throughput, you can increase the
# value at the expense of longer response times.
# The default is 50 ÎŒsec, which our testing shows to increase throughput
# slightly in high-load cases without materially delaying requests.

SchedulerExecutionTimer=100
# SchedulerSpinTimer (0,500)[0]
# This parameter specifies the time in microseconds for threads to be executed
# in the scheduler before sleeping.
SchedulerSpinTimer=400
#Threads
# MaxNoOfExecutionThreads (2,8)
# For 8 or more cores the recomended value is 8
MaxNoOfExecutionThreads=8

# Options for data node "A":
[ndbd]
id=3
hostname=10.1.1.215         # Hostname or IP address

# Options for data node "B":
[ndbd]
id=4
hostname=10.1.1.216         # Hostname or IP address

#######################################
# SQL NODES (also known as API NODES) #
#######################################

# Common SQL Nodes Parameters

[mysqld default]
# This parameter is used to define which nodes can act as arbitrators.
# Only management nodes and SQL nodes can be arbitrators.
# ArbitrationRank can take one of the following values:
#    * 0: The node will never be used as an arbitrator.
#    * 1: The node has high priority; that is, it will be preferred
#         as an arbitrator over low-priority nodes.
#    * 2: Indicates a low-priority node which be used as an arbitrator
#         only if a node with a higher priority is not available
#         for that purpose.
#
# Normally, the management server should be configured as an
# arbitrator by setting its ArbitrationRank to 1 (the default for
# management nodes) and those for all SQL nodes to 0 (the default
# for SQL nodes).

ArbitrationRank=2



# BatchByteSize (1024,1M) [32k]

# For queries that are translated into full table scans or range scans on

# indexes, it is important for best performance to fetch records in properly
# sized batches. It is possible to set the proper size both in terms of number
# of records (BatchSize) and in terms of bytes (BatchByteSize). The actual
# batch size is limited by both parameters.
# The speed at which queries are performed can vary by more than 40% depending
# upon how this parameter is set
# This parameter is measured in bytes and by default is equal to 32KB.
BatchByteSize=32k
# BatchSize (1,992) [64]
# This parameter is measured in number of records.
BatchSize=512
# MaxScanBatchSize (32k,16M) [256k]
# The batch size is the size of each batch sent from each data node.
# Most scans are performed in parallel to protect the MySQL Server from
# receiving too much data from many nodes in parallel; this parameter sets
# a limit to the total batch size over all nodes.

MaxScanBatchSize=8MB

# SQL node options:
[mysqld]
id=11
# Hostname or IP address
hostname=10.1.1.215
[mysqld]
id=12
# Hostname or IP address
hostname=10.1.1.216

# Extra SQL nodes (also used for backup & checks)
[mysqld]
id=13
[mysqld]
id=14
[mysqld]
id=15
[mysqld]
id=16
[mysqld]
id=17
[mysqld]
id=18


##################
# TCP PARAMETERS #
##################
[tcp default]



# Increasing the sizes of these 2 buffers beyond the default values
# helps prevent bottlenecks due to slow disk I/O.
SendBufferMemory=3M

ReceiveBufferMemory=3M

1.7.2 /etc/mysql/my.cf

Fichero de configuración de los Nodos SQL (que tb son los nodos NDB).


# MySQL SQL node config 
# =====================
# Written by Pablo de la Concepcion, [email protected]
#
# The following options will be passed to all MySQL clients
[client]
#password       = your_password
port            = 3306
socket          = /var/lib/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
datadir = /var/lib/mysql
skip-locking
key_buffer_size = 4000M
table_open_cache = 5100
sort_buffer_size = 64M
net_buffer_length = 512K
read_buffer_size = 128M
read_rnd_buffer_size = 256M
myisam_sort_buffer_size = 64M

query_cache_size = 256M
query_cache_limit = 92M

#slow_query_log = /var/log/mysql/mysql-slow.log
max_connections = 500
table_cache = 9060


# Thread parameters
thread_cache_size = 1024
thread_concurrency = 64
thread_stack = 256k

# Point the following paths to different dedicated disks
#tmpdir         = /tmp/
#log-update     = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

# The safe_mysqld script
[safe_mysqld]
log-error       = /var/log/mysql/mysqld.log
socket          = /var/lib/mysql/mysql.sock

[mysqldump]
socket          = /var/lib/mysql/mysql.sock
quick
max_allowed_packet = 64M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer_size = 10000M
sort_buffer_size = 20M
read_buffer = 10M
write_buffer = 10M

[mysqld_multi]
mysqld     = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin

#log        = /var/log/mysqld_multi.log
# user       = multi_admin
# password   = secret

# If you want to use mysqld_multi uncomment 1 or more mysqld sections
# below or add your own ones.

# WARNING
# --------
# If you uncomment mysqld1 than make absolutely sure, that database mysql,
# configured above, is not started.  This may result in corrupted data!
# [mysqld1]
# port       = 3306
# datadir    = /var/lib/mysql
 pid-file   = /var/lib/mysql/mysqld.pid
# socket     = /var/lib/mysql/mysql.sock
# user       = mysql


# Cluster configuration
#       by Pablo de la Concepcion <[email protected]>


# Options for mysqld process:
[mysqld]

# Run NDB storage engine
ndbcluster

# Location of management servers
ndb-connectstring="10.1.1.215:1186;10.1.1.216:1186"

# Number of connections in the connection pool, the config.ini file of the
# cluster have to define also [API] nodes at least for each connection.
ndb-cluster-connection-pool=3

# Forces sending of buffers to NDB  immediately, without waiting
# for other threads. Defaults to ON.
ndb-force-send=1

# Forces NDB to use a count of records during SELECT COUNT(*) query planning
# to speed up this type of query. The default value is ON. For faster queries
# overall, disable this feature by setting the value of ndb_use_exact_count
# to OFF.
ndb-use-exact-count=0

#  This variable can be used to enable recording in the MySQL error log
# of information specific to the NDB storage engine. It is normally of
# interest only when debugging NDB storage engine code.
# The default value is 0, which means that the only NDB-specific
# information written to the MySQL error log relates to transaction
# handling. If the value is greater than 0 but less than 10, NDB table
# schema and connection events are also logged, as well as whether or
# not conflict resolution is in use, and other NDB errors and information.
# If the value is set to 10 or more, information about NDB internals, such
# as the progress of data distribution among cluster nodes, is also
# written to the MySQL error log.

ndb-extra-logging=00

# Determines the probability of gaps in an autoincremented column.
# Set it to 1 to minimize this. Setting it to a high value for
# optimization â makes inserts faster, but decreases the likelihood
# that consecutive autoincrement numbers will be used in a batch
# of inserts. Default value: 32. Minimum value: 1.

ndb-autoincrement-prefetch-sz=256

engine-condition-pushdown=1

# Options for ndbd process:

[mysql_cluster]
# Location of management servers (list of host:port separated by ;)

ndb-connectstring="10.1.1.230:1186;10.1.1.220:1186"

1.7.3 /etc/cron.daily/backup_cluster

Template warning.png

Trantandose de un cluster el mysqldump no es fiable por que las escrituras son distribuidas y no se puede asegurar la coherencia. Aunque no está recomendado, y es preferible hacer un backup del cluster completo (ver siguiente apartado), se puede tratar de sacar un backup válido si se limitan las escrituras en el cluster (parando los servidores de pandora) y en modo signle user (ver http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-single-user-mode.html )

 


Este script de backup realiza el backup mediante el sistema “seguro” (comando START BACKUP) desde la consola de gestión del cluster.

#!/bin/bash

LOG_TEMPORAL=/tmp/mysql_cluster_backup_script.log

#Directorios de los Backups

DIR_NODO3=/var/lib/mysql-cluster/BACKUPS/Nodo_03
DIR_NODO4=/var/lib/mysql-cluster/BACKUPS/Nodo_04

# Se lanza el backup y se espera a que se complete
/usr/bin/ndb_mgm -e "START BACKUP WAIT COMPLETED" > $LOG_TEMPORAL
echo "Procesando Log $LOG_TEMPORAL"
NUM_BACKUP=`grep Backup $LOG_TEMPORAL | grep completed | awk '{print $4}'`
echo "Procesando backup $NUM_BACKUP"

# Se copian por scp los backups
scp -i /root/.ssh/backup_key_rsa -r [email protected]:/var/lib/mysql-cluster/BACKUP/BACKUP-$NUM_BACKUP/ $DIR_NODO3 >>$LOG_TEMPORAL 2>> /var/lib/mysql-cluster/BACKUPS/logs/backup_$NUM_BACKUP.err

scp -i /root/.ssh/backup_key_rsa -r [email protected]:/var/lib/mysql-cluster/BACKUP/BACKUP-$NUM_BACKUP/ $DIR_NODO4 >>$LOG_TEMPORAL 2>> /var/lib/mysql-cluster/BACKUPS/logs/backup_$NUM_BACKUP.err

#Se almacena el log
mv $LOG_TEMPORAL  /var/lib/mysql-cluster/BACKUPS/logs/backup_$NUM_BACKUP.log

	Para programar este script diariamente debemos poner la siguiente linea en el fichero 	/etc/crontab (Esto hará un backup diario a las 5 de la mañana)

00 5   * * *   root    /tmp/backup_cluster

1.7.4 /etc/init.d/cluster_mgmt

Template warning.png

Este script es ligeramente diferente en la consola de gestion del cluster secundaria (diferentes parametros en DAEMON_PARAMETERS)

 



#!/bin/bash
# Copyright (c) 2005-2009 Artica ST
#
# Author: Sancho Lerena <[email protected]> 2006-2009
#
# /etc/init.d/cluster_mgmt
#
# System startup script for MYSQL Cluster Manager
#
### BEGIN INIT INFO
# Provides:       cluster_mgmt
# Required-Start: $syslog cron
# Should-Start:   $network cron
# Required-Stop:  $syslog
# Should-Stop:    $network
# Default-Start:  2 3 5
# Default-Stop:   0 1 6
# Short-Description: MySQL Cluster Management console startup script
# Description:    See short description
### END INIT INFO

export PROCESS_DAEMON=ndb_mgmd
export PROCESS_PARAMETERS="--config-file=/var/lib/mysql-cluster/config.ini --configdir=/var/lib/mysql-cluster"

# Uses a wait limit before sending a KILL signal, before trying to stop
# Pandora FMS server nicely. Some big systems need some time before close
# all pending tasks / threads.

export MAXWAIT=300

# Check for SUSE status scripts
if [ -f /etc/rc.status ]
then
        . /etc/rc.status
        rc_reset
else
        # Define rc functions for non-suse systems, "void" functions.
        function rc_status () (VOID=1;)
        function rc_exit () (exit;)
        function rc_failed () (VOID=1;)

fi

# This function replace pidof, not working in the same way in different linux distros

function pidof_process () (
        # This sets COLUMNS to XXX chars, because if command is run
        # in a "strech" term, ps aux don't report more than COLUMNS
        # characters and this will not work.
        COLUMNS=400
        PROCESS_PID=`ps aux | grep "$PROCESS_DAEMON $PROCESS_PARAMETERS" | grep -v grep | tail -1 | awk '{ print $2 }'`
        echo $PROCESS_PID
)

# Main script

if [ `which $PROCESS_DAEMON | wc -l` == 0 ]
then
        echo "Server not found, please check setup and read manual"
        rc_status -s
        rc_exit
fi

case "$1" in
        start)
                PROCESS_PID=`pidof_process`
                if [ ! -z "$PROCESS_PID" ]
                then
                        echo "Server is currently running on this machine with PID ($PROCESS_PID). Aborting now..."
                        rc_failed 1
                        rc_exit
                fi

                $PROCESS_DAEMON $PROCESS_PARAMETERS
                sleep 1

                PANDORA_PID=`pidof_process`

                if [ ! -z "$PANDORA_PID" ]
                then
                        echo "Server is now running with PID $PANDORA_PID"
                        rc_status -v
                else
                        echo "Cannot start Server. Aborted."
                        rc_status -s
                fi
        ;;

        stop)
                PANDORA_PID=`pidof_process`
                if [ -z "$PANDORA_PID" ]
                then
                        echo "Server is not running, cannot stop it."
                        rc_failed
                else
                        echo "Stopping Server"
                        kill $PANDORA_PID
                        COUNTER=0

                        while [  $COUNTER -lt $MAXWAIT ]
                        do
                                PANDORA_PID=`pidof_process`
                                if [ -z "$PANDORA_PID" ]
                                then
                                        COUNTER=$MAXWAIT
                                fi
                                COUNTER=`expr $COUNTER + 1`
                                sleep 1
                        done

                        # Send a KILL -9 signal to process, if it's alive after 60secs, we need
                        # to be sure is really dead, and not pretending...
                        if [ ! -z "$PANDORA_PID" ]
                        then
                                kill -9 $PANDORA_PID
                        fi
                        rc_status -v
                fi
        ;;
        status)
                PANDORA_PID=`pidof_process`
                if [ -z "$PANDORA_PID" ]
                then
                        echo "Server is not running."
                        rc_status
                else
                        echo "Server is running with PID $PANDORA_PID."
                        rc_status
                fi
        ;;
  force-reload|restart)
                $0 stop
                $0 start
                ;;
  *)
                echo "Usage: server { start | stop | restart | status }"
                exit 1
esac
rc_exit


1.7.5 /etc/init.d/cluster_node


#!/bin/bash
# Copyright (c) 2005-2009 Artica ST
#
# Author: Sancho Lerena <[email protected]> 2006-2009
#
# /etc/init.d/cluster_node
#
# System startup script for MYSQL Cluster Node storage
#
### BEGIN INIT INFO
# Provides:       cluster_node
# Required-Start: $syslog cron
# Should-Start:   $network cron
# Required-Stop:  $syslog
# Should-Stop:    $network
# Default-Start:  2 3 5
# Default-Stop:   0 1 6
# Short-Description: MySQL Cluster Node startup script
# Description:    See short description
### END INIT INFO

export PROCESS_DAEMON=ndb_ndb
export PROCESS_PARAMETERS="-d"

# Uses a wait limit before sending a KILL signal, before trying to stop
# Pandora FMS server nicely. Some big systems need some time before close
# all pending tasks / threads.

export MAXWAIT=300

# Check for SUSE status scripts
if [ -f /etc/rc.status ]
then
        . /etc/rc.status
        rc_reset
else
        # Define rc functions for non-suse systems, "void" functions.
        function rc_status () (VOID=1;)
        function rc_exit () (exit;)
        function rc_failed () (VOID=1;)

fi

# This function replace pidof, not working in the same way in different linux distros

function pidof_process () (
        # This sets COLUMNS to XXX chars, because if command is run
        # in a "strech" term, ps aux don't report more than COLUMNS
        # characters and this will not work.
        COLUMNS=400
        PROCESS_PID=`ps aux | grep "$PROCESS_DAEMON $PROCESS_PARAMETERS" | grep -v grep | tail -1 | awk '{ print $2 }'`
        echo $PROCESS_PID
)

# Main script

if [ `which $PROCESS_DAEMON | wc -l` == 0 ]
then
        echo "Server not found, please check setup and read manual"
        rc_status -s
        rc_exit
fi

case "$1" in
        start)
                PROCESS_PID=`pidof_process`
                if [ ! -z "$PROCESS_PID" ]
                then
                        echo "Server is currently running on this machine with PID ($PROCESS_PID). Aborting now..."
                        rc_failed 1
                        rc_exit
                fi

                $PROCESS_DAEMON $PROCESS_PARAMETERS
                sleep 1

                PANDORA_PID=`pidof_process`

                if [ ! -z "$PANDORA_PID" ]
                then
                        echo "Server is now running with PID $PANDORA_PID"
                        rc_status -v
                else
                        echo "Cannot start Server. Aborted."
                        rc_status -s
                fi
        ;;

        stop)
                PANDORA_PID=`pidof_process`
                if [ -z "$PANDORA_PID" ]
                then
                        echo "Server is not running, cannot stop it."
                        rc_failed
                else
                        echo "Stopping Server"
                        kill $PANDORA_PID
                        COUNTER=0

                        while [  $COUNTER -lt $MAXWAIT ]
                        do
                                PANDORA_PID=`pidof_process`
                                if [ -z "$PANDORA_PID" ]
                                then
                                        COUNTER=$MAXWAIT
                                fi
                                COUNTER=`expr $COUNTER + 1`
                                sleep 1
                        done

                        # Send a KILL -9 signal to process, if it's alive after 60secs, we need
                        # to be sure is really dead, and not pretending...
                        if [ ! -z "$PANDORA_PID" ]
                        then
                                kill -9 $PANDORA_PID
                        fi
                        rc_status -v
                fi
        ;;
        status)
                PANDORA_PID=`pidof_process`
                if [ -z "$PANDORA_PID" ]
                then
                        echo "Server is not running."
                        rc_status
                else
                        echo "Server is running with PID $PANDORA_PID."
                        rc_status
                fi
        ;;
  force-reload|restart)
                $0 stop
                $0 start
                ;;
  *)
                echo "Usage: server { start | stop | restart | status }"
                exit 1
esac
rc_exit

Volver a Indice de Documentacion Pandora FMS