16.4. Configuración de MySQL Cluster

MySQL 5.0

previous page next page

16.4. Configuración de MySQL Cluster

Un MySQL server que es parte de un MySQL Cluster difiere sólo en un aspecto de un servidor MySQL normal (no cluster), en que emplea el motor . Este motor también se conoce símplemente como , y las dos formas del nombre son sinónimas.

Para evitar reserva innecesaria de recursos, el servidor se configura por defecto con el motor desactivado. Para activar , necesitará configurar el fichero de configuración del servidor con la opción .

Desde que MySQL server es parte del cluster, necesita datos de configuración que sepa cómo acceder al nodo MGM para obtener datos de configuración del cluster. El comportamiento por defecto es buscar el nodo MGM en . Sin embargo, puede necesitar especificar su localización donde se encuentre, esto puede hacerse en o en la línea de comandos del servidor MySQL. Antes de poderse usar el , al menos un nodo MGM debe ser operacional, así como los nodos de datos deseados.

16.4.1. Generar MySQL Cluster desde el código fuente

, el motor del cluster, está disponible en distribución binaria para Linux, Mac OS X, y Solaris. No está disponible en Windows, pero queremos que lo esté para win32 y otras plataformas en un futuro próximo.

Si elige compilar desde un paquete fuente o desde el MySQL 5.0 BitKeeper tree, asegúrese de usar la opción cuando ejecute configure. Puede usar el script BUILD/compile-pentium-max . Tenga en cuenta que este script incluye OpenSSL,así que debe tener u obtener OpenSSL para compilar con éxito; de otro modo, necesitará modificar compile-pentium-max para excluir este requerimiento. Por supuesto, puede seguir las instrucciones estándar para compilar sus propios binarios, luego realizar los tests usuales y procedimiento de instalación. Consulte Sección 2.8.3, “Instalar desde el árbol de código fuente de desarrollo”.

16.4.2. Instalar el software

En las siguientes secciones, asumimos que conoce el proceso de instalación de MySQL,y cubrimos sólo las diferencias entre configurar MySQL Cluster y configurar MySQL sin clustering. (Consulte Capítulo 2, Instalar MySQL si necesita más información sobre lo último.)

Encontrará la configuración del cluster más sencilla si ya tiene todos los nodos de administración y datos en ejecución; esta es la parte más costosa de tiempo de la configuración. Editar el fichero es sencillo y esta sección cubre sólo las diferencias de configurar MySQL sin clustering.

16.4.3. Rápido montaje de prueba de MySQL Cluster

Para familiarizarse con los conceptos básicos, describimos la configuración más sencilla para un MySQL Cluster. Después, debería poder diseñar su inicialización deseada a partir de la información proporcionada en las otras secciones de este capítulo.

Primero, necesita crear un directorio de configuración tal como , ejecutando el siguiente comando como root del sistema: 

shell> mkdir /var/lib/mysql-cluster

En este directorio, cree un fichero llamado con la siguiente información, substituyendo los valores apropiados por y como sea necesario para su sistema. 

# file "config.ini" - showing minimal setup consisting of 1 data node,
# 1 management server, and 3 MySQL servers.
# The empty default sections are not required, and are shown only for
# the sake of completeness.
# Data nodes must provide a hostname but MySQL Servers are not required
# to do so.
# If you don't know the hostname for your machine, use localhost.
# The DataDir parameter also has a default value, but it is recommended to
# set it explicitly.
# Note: DB, API, and MGM are aliases for NDBD, MYSQLD, and NDB_MGMD
# respectively. DB and API are deprecated and should not be used in new
# installations.
[NDBD DEFAULT]
NoOfReplicas= 1

[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]

[NDB_MGMD]
HostName= myhost.example.com

[NDBD]
HostName= myhost.example.com
DataDir= /var/lib/mysql-cluster

[MYSQLD]
[MYSQLD]
[MYSQLD]

Ahora puede arrancar el servidor de administración: 

shell> cd /var/lib/mysql-cluster
shell> ndb_mgmd

Arranque un nodo DB sencillo usando ndbd. Al arrancar ndbd para un nodod DB dado por primera vez, debe usar la opción : 

shell> ndbd --initial

Para arrancar ndbd de nuevo,normalmente no necesitará usar esta opción: 

shell> ndbd

Esto es porque la opción borra todos los ficheros de datos y log existentes (así como todos los metadatos de tablas) para este nodo de datos y crea nuevos. Una excepción a esta regla es al reiniciar el cluster y restaurar desde una copia de seguridad tras añadir nuevos nodos de datos.

Por defecto, ndbd buscará el servidor de administración en en el puerto 1186.

Nota: Si ha instalado MySQL desde un tarball binario, necesitará especificar la ruta de los servidores ndb_mgmd y ndbd explícitamente. (Normalemnte, se encuentran en .)

Finalmente, vaya al directorio de datos de MySQL (usualmente o ), y asegúrese que el fichero contiene la opción necesaria para permitir el motor NDB : 

[mysqld]
ndbcluster

Ahora puede arrancar el servidor MySQL normalmente: 

shell> mysqld_safe --user=mysql &

Espere un momento para asegurarse que el servidor MySQL está corriendo apropiadamente. Si ve , chequee el fichero del servidor para averiguar qué ha fallado.

Si todo ha ido bien, puede arrancar usando el cluster: 

shell> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.10-Max

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> SHOW ENGINES;
+------------+---------+------------------------------------------------------------+
| Engine     | Support | Comment                                                    |
+------------+---------+------------------------------------------------------------+
...
| NDBCLUSTER | DEFAULT | Clustered, fault-tolerant, memory-based tables             |
| NDB        | YES     | Alias for NDBCLUSTER                                       |
...

mysql> USE test;
Database changed

mysql> CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.09 sec)

mysql> SHOW CREATE TABLE ctest \G
*************************** 1. row ***************************
       Table: ctest
Create Table: CREATE TABLE `ctest` (
  `i` int(11) default NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

Para chequear que sus nodos se han inicializado correctamente, arranque el cliente de administración como se muestra: 

shell> ndb_mgm

Puede usar el comando SHOW desde el cliente de administración para obtener un reporte del estado del cluster: 

NDB> SHOW
Cluster Configuration
---------------------
[ndbd(NDB)]     1 node(s)
id=2    @127.0.0.1  (Version: 3.5.3, Nodegroup: 0, Master)

[ndb_mgmd(MGM)] 1 node(s)
id=1    @127.0.0.1  (Version: 3.5.3)

[mysqld(API)]   3 node(s)
id=3    @127.0.0.1  (Version: 3.5.3)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)

En este punto, ha inicializado correctamente un cluster MySQL. Ya puede almacenar datos en el cluster usando cualquier tabla creada con o su alias .

16.4.4. Fichero de configuración

Configurar MySQL Cluster requiere trabajar con dos ficheros:

  • : Especifica opciones para todos los ejecutables del MySQL Cluster . Este fichero, con el que debe familiarizarse de trabajar anteriormente con MySQL, debe ser accesible por cada ejecutable del cluster.

  • : Este fichero es de sólo lectura por el servidor de administración del MySQL Cluster , que distribuye la información contenida en el mismo a todos los procesos participantes en el cluster. contiene una descripción de cada nodo del cluster. Esto incluye los parámetros de configuración para nodos de datos y parámetros de configuración para conexiones entre todos los nodos del cluster.

Mejoramos la configuración del cluster contínuamente y tratamos de simplicar el proceso. Mientras tratamos de mantener compatibilidad con versiones anteriores, puede ser que a veces hagamos cambios incompatibles. Si encuentra uno de estos cambios no documentados, use nuestra Bugs Database para reportarlo.

16.4.4.1. Ejemplo de configuración para MySQL Cluster

Para soportar MySQL Cluster, necesita actualizar como se muestra en el siguiente ejemplo. Tenga en cuenta que las opciones mostradas aquí no deben confundirse con las de los ficheros . Puede especificar estos parámetros al invocar los ejecutables desde línea de comandos 

# my.cnf
# example additions to my.cnf for MySQL Cluster
# (valid in MySQL 5.0)

# enable ndbcluster storage engine, and provide connectstring for
# management server host (default port is 1186)
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com


# provide connectstring for management server host (default port: 1186)
[ndbd]
connect-string=ndb_mgmd.mysql.com

# provide connectstring for management server host (default port: 1186)
[ndb_mgm]
connect-string=ndb_mgmd.mysql.com

# provide location of cluster configuration file
[ndb_mgmd]
config-file=/etc/config.ini

(Para más información acerca de los connectstrings, consulte Sección 16.4.4.2, “El de MySQL Cluster”.) 

# my.cnf
# example additions to my.cnf for MySQL Cluster
# (will work on all versions)

# enable ndbcluster storage engine, and provide connectstring for management
# server host to the default port 1186
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com:1186

Puede usar una sección separada en el cluster para configuración que deba ser leída y afecte a todos los ejecutables: 

# cluster-specific settings
[mysql_cluster]
ndb-connectstring=ndb_mgmd.mysql.com:1186

Actualmente el fichero de configuración está en formato INI, y se llama por defecto . Lo lee ndb_mgmd al arrancar y puede situarse en cualquier sitio. Su localización y nombre se especifican usando ] en la línea de comandos con ndb_mgmd. Si el fichero de configuración no se especifica, ndb_mgmd trata por defecto de leer el fichero localizado en el directorio de trabajo actual.

Los valores por defecto se definen para la mayoría de parámetros, y pueden especificarse en . Para crear una sección de valores por defecto, añada la palabra al nombre de sección. Por ejemplo, los nodos de datos se configuran usando las secciones . Si todos los nodos de datos usan el mismo tamaño de memoria de datos, y este no es le mismo que el tamaño por defecto, cree una sección que contenga una línea con para especificar el tamaño por defecto de la memoria de datos para todos los nodos de datos.

El formato INI consiste en secciones precedidas por cabeceras de secciones (rodeados por corchetes), segidos por los nombres y valores apropiados de parámetros. Una desviación del formato estándar es que el nombre y valor del parámetro puede separarse por un punto y coma ('') así como el signo de igualdad (''); otra es que las secciones no se identifican únicamente por el nombre. En su lugar, las entradas únicas (tales como dos nodos distintos del mismo tipo) se identifican por un ID único.

Como mínimo, el fichero de configuración debe definir las máquinas y nodos involucrados en el cluster y en qué máquinas están estos nodos. Como ejemplo de un fichero de configuración simple para un cluster con un servidor de administración, dos nodos de datos y dos servidores MySQL se muestra a continuación: 

# file "config.ini" - 2 data nodes and 2 SQL nodes
# This file is placed in the startup directory of ndb_mgmd (the management
# server)
# The first MySQL Server can be started from any host. The second can be started
# only on the host mysqld_5.mysql.com

[NDBD DEFAULT]
NoOfReplicas= 2
DataDir= /var/lib/mysql-cluster

[NDB_MGMD]
Hostname= ndb_mgmd.mysql.com
DataDir= /var/lib/mysql-cluster

[NDBD]
HostName= ndbd_2.mysql.com

[NDBD]
HostName= ndbd_3.mysql.com

[MYSQLD]
[MYSQLD]
HostName= mysqld_5.mysql.com

Hay seis secciones distintas en este fichero de configuración:

  • : Define las máquinas del cluster.

  • : Define los nodos de datos del cluster.

  • : Define los nodos MySQL del cluster.

  • o : Define el nodo de administración del cluster.

  • : Define conexiones TCP/IP entre nodos en el cluster, siendo TCP/IP el protocolo de conexión por defecto.

  • : Define conexiones de memoria compartida entre nodos. Antiguamente, este tipo de conexión estaba disponible sólo en binarios compilados con la opción . En MySQL 5.0-Max, está activado por defecto, pero debe considerarse experimental.

Tenga en cuenta que cada nodo tiene su propia sección en . Por ejemplo, desde que el cluster tiene dos nodos de datos, el fichero de configuración contiene dos secciones definiendo estos nodos.

Puede definir valores para cada sección. En MySQL 5.0, todos los nombres de parámetros no son sensibles a mayúsculas.

16.4.4.2. El de MySQL Cluster

Con excepción del servidor de administración MySQL Cluster (ndb_mgmd), cada nodo de un MySQL Cluster requiere de un connectstring que apunte a la localización del servidor de administración. Se usa para establecer una conexión al servidor de administración así como realizar otras tareas en función del rol del nodo en el cluster. La sintaxis para el connectstring es la siguiente: 

<connectstring> :=
[<nodeid-specification>,]<host-specification>[,<host-specification>]
<nodeid-specification> := nodeid=<id>
<host-specification> := <host>[:<port>]

es un entero mayor que 1 que identifica un nodo en config.ini es un entero que se refiere a un puerto unix regular es una cadena que tiene una dirección de equipo de internet válida 

example 1 (long):    "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
example 2 (short):   "myhost1"

Todos los nodos usan como valor connectstring por defecto si no se especifica otro. Si se omite del connectstring, el puerto por defecto es 1186. Este puerto debe estar siempre disponible en la red, ya que se ha asignado por la IANA para este propósito (consulte http://www.iana.org/assignments/port-numbers para más detalles).

Listando múltiples valores , es posible diseñar varios servidores de administración redundantes. Un nodo del cluster tratará de contactar con administradores sucesivamente en cada equipo en el orden especificado, hasta que se establezca una conexión.

Hay un número de distintos modos de especificar el connectstring:

  • Cada ejecutable tiene su propia opción de línea de comandos que permite especificar el servidor de administración al arrancar. (Consulte la documentación para los respectivos ejecutables.)

  • Es posible en MySQL 5.0 Cluster inicializar el connectstring para todos los nodos en el cluster a la vez poniéndolo en la sección en el fichero del servidor de administración .

  • Para compatibilidad con versiones anteriores, hay dos otras opciones disponibles, usando la misma sintaxis:

    1. Inicialice la variable de entorno para que contenga el connectstring.

    2. Escriba el connectstring para cada ejecutable en un fichero de texto llamado y guarde este fichero en el directorio de arranque del ejecutable.

    Sin embargo, esto está ahora obsoleto y no debería usarse en nuevas instalaciones.

El método recomendado para especificar el connectstring es inicializarlo en la línea de comandos o en el fichero para cada ejecutable.

16.4.4.3. Definir los equipos que forman un cluster MySQL

La sección no tiene otro significado a parte de servir como forma de eliminar la necesidad de definir nombres de equipos para cada nodo en el sistema. Todos los parámetros mencionados aquí son necesarios.

  • Este valor es un entero, usado para referirse la máquina equipo en cualquier punto del fichero de configuración.

  • Este es el nombre de equipo o dirección IP de la máquina.

16.4.4.4. Definición del servidor de administración de MySQL Cluster

La sección (o su alias ) se usa para configurar el comportamiento del servidor de administración. Todos los parámetros de la siguiente lista puede omitirse y, si así es, se asumen sus valores por defecto. Nota: Si ni el parámetro ni están presentes, se asume para ambos el valor por defecto .

  • Cada nodo en el cluster tiene un identificador único, que está representado por un valor entero en el rango de 1 a 63 inclusive. Este ID se usa por todos los mensajes de cluster internos para dirigirse al nodo.

  • Esto se refiere a una de las máquinas definidas en la sección .

  • Este es el número de puerto en que escucha el servidor de administración para peticiones de configuración o comandos de administración.

  • Este parámetro especifica dónde enviar la información de logueo del cluster. Hay tres opciones al respecto: , , y :

    • envía el log a : 

      CONSOLE

    • envía el log a un , siendo los valores posibles uno de , , , , , , , , , , , , , , , , , , , o .

      Nota: No todos los dispositivos son soportadas necesariamente por cada sistema operativo. 

      SYSLOG:facility=syslog

    • envía por un pipe la salida del log del cluster a un fichero normal de la misma máquina. Pueden especificarse los siguientes valores:

      • : Nombre del fichero de log.

      • : Tamaño máximo al que puede crecer el fichero antes de pasar el log a un nuevo fichero. Cuando esto ocurre, el antiguo fichero de log se renombra añadiendo al nombre del fichero, donde es el siguiente número no usado todavía por este nombre.

      • : Número máximo de ficheros de log. 

      FILE:filename=cluster.log,maxsize=1000000,maxfiles=6

      Es posible especificar múltiples destinaciones de logs como se muestra aquí, usando una cadena delimitada por puntos y comas: 

      CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd

      El valor por defecto para el parámetro es _cluster.log,maxsize=1000000,maxfiles=6, donde es el ID del nodo.

  • Este parámetro se usa para definir qué nodos pueden actuar como árbitros. Sólo los nodos MGM y SQL pueden serlo. puede tener uno de los siguientes valores:

    • : El nodo nunca se usará como árbitro.

    • : El nodo tiene alta prioridad, esto es, será preferido como árbitro sobre los nodos con baja prioridad.

    • : Indica que un nodo de baja prioridad será usado como árbitro sólo si un nodo con una prioridad alta no está disponible para este propósito.

    Normalmente, el servidor de administración debe configurarse como árbitro poniendo a 1 (el valor por defecto) y todos los nodos SQL a 0.

  • Un valor entero hace que las respuestas a peticiones de árbitro al servidor de administración se retrasen el número de milisegundos indicado. Por defecto, este valor es 0, normalmente no es necesario cambiarlo.

  • Cambia el directorio donde se guardan los ficheros de salida del servidor de administración. Estos ficheros incluyen ficheros de log del cluster, ficheros de salida de procesos, y los ficheros pid de los demonios. (Para ficheros de log, esto puede sobreescribirse poniendo el parámetro para como se discute préviamente en esta sección.)

16.4.4.5. Definir los nodos de MySQL Cluster

La sección se usa para configurar el comportamiento de los nodos de datos del cluster. Hay varios parámetros que controlan los tamaños de buffer, de pool, timeouts, y así. Los únicos parámetros obligatorios son:

  • O o .

  • El parámetro

Se tienen que definir en la sección .

La mayoría de parámetors de los nodos de datos se inicializan en la sección . Sólo los parámetros marcados como capaces de cambiar valores locales se permiten cambiar en la sección . , y deben definirse en la sección local.

Identificar nodos de datos

El valor (esto es, el identificador del nodo de datos) puede cambiarse en la línea de comandos cuando se arranca el nodo o en el fichero de configuración.

Para cada parámetro es posible usar , , o como sufijo para indicar unidades de 1024, 1024*1024, o 1024*1024*1024. (Por ejemplo, significa 100 * 1024 = 102400.) Los parámetros y valores son sensibles a mayúsculas.

  • Este es el ID del nodo usado como dirección del nodo para todos los mensajes internos del cluster. Este es un entero entre 1 y 63. Cada nodo en el cluster tiene una identidad única.

  • Se refiere a uno de las máquinas (equipos) definidos en la sección .

  • Especificar este parámetro tiene un efecto similar a especificar . Define el nombre de equipo de la máquina en que reside el nodo de almacenamiento. Este parámetro o es necesario para especificar un nombre de equipo distinto a .

  • (OBSOLETO)

    Cada nodo en el cluster usa un puerto para conectarse a otros nodos. Este puerto se usa también para transporte distinto a TCP en la fase de establecimiento de la conexión. Ahora, el puerto por defecto se reserva dinámicamente de forma que se asegura que dos nodos en la misma máquina reciban el mismo número de puerto, no debe ser necesario indicar un valor para este parámetro.

  • Este parámetro global sólo puede cambiarse en la sección , y define el 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.

    Los grupos de nodos se forman implítamente. El primer grupo de nodos se forma por el conjunto de nodos de datos con los IDs de nodo más bajos, el siguiente grupo de nodos se conforma con el conjunto del siguiente conjunto de identidades de nodos más baja, y así. Como ejemplo, asuma que tenemos 4 nodos de datos y que es 2. Los cuatro nodos de datos tienen los IDs 2, 3, 4 y 5. El primer grupo de nodos está formado con los nodos 2 y 3, y el segundo grupo con los nodos 4 y 5. Es importante configurar el cluster de forma que los nodos en el mismo grupo no se guarden en la misma máquina, ya que en esta situación un fallo de hardware haría que fallare el cluster entero.

    Si no hay IDs de nodos el orden de los nodos de datos es el factor determinante para el grupo de nodos. Se haga o no una asignación explícita, puede verse en la salida del comando del cliente administrador .

    No hay valor por defecto para ; el valor máximo posible es 4.

  • Este parámetro especifica el directorio donde los ficheros de traceo, ficheros de log, ficheros pid y logs de errores se guardan.

  • Este parámetro especifica el directorio donde se guardan todos los ficheros para metadatos, logs de REDO, logs de UNDO y ficheros de datos. Por defecto es el directorio especificado por . Nota: Este directorio debe existir antes de inciar el proceso ndbd.

    La jerarquía de directorio recomendada para MySQL Cluster incluye , bajo qué directorio se crea un sistema de ficheros de un nodo. Este subdirectorio contiene el ID del nodo. Por ejemplo, si el ID del nodo es 2, el subdirectorio se llama .

  • Es posible especificar el directorio en que se guardan las copias de seguridad. Por defecto, este directorio es BACKUP. (Consulte secciones anteriores.)

Memoria de datos e índice

y son parámetros especificando el tamaño de los segmentos de memoria usados para almacenar los registros actuales y sus índices. Al inicializar los valores de los mismos, es importante entender cómo se usan y , ya que usualmente necesitan actualizarse para reflejar el uso real del cluster:

  • Este parámetro define la cantidad de espacio disponible para almacenar registros de base de datos. La cantidad entera se guardará en memoria, así que es extremadamente importante que la máquina tenga sufuciente memoria física para guardar este valor.

    La memoria reservada por se usa para almacenar los registros y los índices. Cada registro tiene una longitud fija . (Incluso columnas se almacenan como columnas de longitud fija.) Hay una sobrecarga de 16-byte para cada registro; una cantidad adicional para cada registro se necesita porque se almacena en páginas de 32KB con sobrecarga de 128 byte por página (consulte a continuación). También hay una pequeña cantidad gastada por página debido al hecho que cada registro se almacena en sólo una página. El tamaño de registro máximo actualmente es de 8052 bytes.

    El espacio de memoria definido por se usa para almacenar índices ordenados, que usa acerca de 10 bytes por registor. Cada registro de tabla se representa en el índice ordenado. Un error común entre usuarios es asumir que todos los índices se almacenan en la memoria reservada por , pero no es así: sólo claves primarias e índices hash únicos usan esta memoria; los índices ordenados usan la memoria almacenada por . Sin embargo, crear una clave primar única o índice hash único también crea un índice ordenado en la misma clave, a no ser que especifique en el comando de creación del índice. Esto puede verificarse ejecutando ndb_desc -d en el cliente de administración.

    El espacio de memoria reservado por consiste en 32KB páginas, que se reservan en fragmentos de tabla. Cada tabla se particiona normalmente en el mismo número de fragmentos como hay nodos de datos en el cluster. Por lo tanto, por cada nodo, hay el mismo número de fragmentos así como se especifica en . Una vez que una página se ha reservado, no es posible retornarla al pool de páginas libres, excepto borrando la tabla. Ejecutar el modo de recuperación también comprime la partición ya que todos los registros se insertan en particiones vacías por parte de los otros nodos vivos.

    El espacio de memoria también contiene información UNDO: Para cada actualización, se reserva una copia de los registros no alterados en . También hay una referencia de cada copia en los índices de tablas ordenadas. Los índices hash únicos se modifican sólo cuando las columnas de índice único se actualizan, en tal caso se inserta una nueva entrada en la tabla de índices y la antigua entrada se borra al hacer un commit. Por esta razón, es necesario reservar espacio necesario para tratar la transacción más grande realizada por aplicaciones usando el cluster. En cualquier caso, realizar unas cuantas transacciones muy grandes no tiene ventaja sobre usar muchas pequeñas, por las siguientes razones:

    • Las transacciones grandes no son más rápidas que las pequeñas.

    • Las transacciones grandes incrementan el número de operaciones que se pierden y deben repetirse en caso de fallo de transacción

    • Las transacciones grandes usan más memorias

    El valor por defecto de es 80MB; el mínimo es 1MB. No hay tamaño máximo, pero en realidad el tamaño máximo tiene que adaptarse para que el proceso no empiece ha hacer swapping cuando llega al límite. Este límite se determina por la cantidad de RAM física disponible en la máquina y por la cantidad de memoria que el sistema operativo puede asignar a un proceso. Sistemas operativos 32-bit están normalmente limitados a 2-4GB por proceso; los sistemas opertivos de 64-bit pueden usar más. Para bases de datos grandes, puede ser preferible usar un sistema operativo 64-bit por esta razón. Además, es posible ejecutar más de un proceso ndbd por máquina, y esto puede ser ventajoso en máquinas con múltiples CPUs.

  • 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. Tenga en cuenta que cuando define una clave primaria y un índice único, se crean dos índices, uno de los cuales es un índice hash usado por todos los accesos a tuplas así como tratamiento de bloqueos. También se usa para forzar restricciones únicas.

    El tamaño del índice hash es de 25 bytes por registro, más el tamaño de la clave primaria. Para claves primarias mayores a 32 bytes se añaden otros 8 bytes .

    Considere una tabla definida por 

    CREATE TABLE example
(
  a INT NOT NULL,
  b INT NOT NULL,
  c INT NOT NULL,
  PRIMARY KEY(a),
  UNIQUE(b)
) ENGINE=NDBCLUSTER;

    Hay una sobrecarga de 12 bytes (tener columnas no nulas ahorra 4 bytes de sobrecarga) más 12 bytes de datos por registro. Además tenemos dos índices ordenados en las columnas a y b consumiendo cerca de 10 bytes cada uno por registro. Hay un índice hash de clave primaria en la tabla base con unos 29 bytes por registro. La restricción única se implementa por tablas separadas con b como clave primaria y a como columna. Esta tabla consumirá otros 29 bytes de memoria de índice por registro en la tabla ejemplo así como 12 bytes de sobrecarga, más 8 bytes de datos de registros.

    Así, para un millón de registros, necesitamos 58 MB para memoria de índices para tratar los índices hash para la clave primaria y la restricción única. También necesitamos 64 MB para los registros de la tabla base y la tabla de índice único, más las dos tablas con índice ordenado.

    Puede ver que los índices hash tienen una buena cantidad de espacio de memoria; sin embargo, proporcionan acceso muy rápido a los datos retornados. También se usan en MySQL Cluster para tratar restricciones únicas.

    Actualmente el único algoritmo de partición es hashing y los índices ordenados son locales para cada nodo. Por lo tanto los índices ordenados no pueden usarse para tratar restricciones únicas en caso general.

    Un punto importante para y es que el tamaño de base de datos total es la suma de toda la memoria de datos y toda la memoria de índice para cada grupo de nodos. Cada grupo de nodos se usa para guardar información replicada, así que si hay cuatro nodos con 2 réplicas, habrá dos nodos de grupos. Por lo tanto, la cantidad total de memoria disponible es 2* para cada nodo de datos.

    Se recomienda que y se inicialice con el mismo valor para todos los nodos. Desde que los datos se distribuyen eventualmente sobre todos los nodos en el cluster la cantidad de espacio máxima disponible no es mejor que la del menor nodo del cluster.

    y pueden cambiarse, pero decrementar cualquiera de ellos puede ser arriesgado; al hacerlo puede hacer que un nodo o incluso el cluster entero no sea capaz de reiniciar debido a que hay memoria insuficiente. Incrementar estos valores está bien, pero se recomienda que estas actualizaciones se realicen de la misma manera que una actualización de software, comenzando con una actualización del fichero de configuración, y luego reiniciando el servidor de administración seguido del reinicio de cada nodo de datos.

    Las actualizaciones no incrementan la cantidad de memoria índice usada. Las inserciones tienen efecto inmediatamente; sin embargo, los registros no se borran realmente hasta que la transacción hace un commit.

    El valor por defecto para es 18MB. El mínimo es 1MB.

Parámetros de transacción

Los siguientes tres parámetros que discutimos son importanets porque afectan al número de transacciones paralelas y los tamaños de transacciones que pueden tratarse por el sistema. es el número de transacciones posibles en un nodo; es el número de registros que pueden estar en fase de actualización o bloqueados simultáneamente.

Ambos parámetros (especialmente ) son objetivos probables para que los usuarios especifiquen valores específicos y no usen el valor por defecto. El valor por defecto es para sistemas con transacciones pequeñas, para asegurar que no usan excesiva cantidad de memoria.

  • Para cada transacción activa en el cluster debe haber un registro en uno de los nodos del cluster. La tarea de coordinar transacciones se envía entre los nodos: el número total de registros de transacciones en el cluster es el número de transacciones en cualquier nodo por el número de nodos en el cluster.

    Los registros de transacciones se guardan en servidores MySQL individuales. Normalmente al menos hay un registro de transacción por conexión que usa cualquier tabla en el cluster. Por esta razón, debe asegurarse que hay más registros de transacciones en el cluster que conexiones concurrentes en todos los servidores MySQL del cluster.

    Este parámetro debe inicializarse al mismo valor para todos los nodos del cluster.

    Cambiar este parámetro nunca es seguro y puede causar que un cluster falle. Cuando un nodo falla uno de los nodos (el nodo superviviente más antiguo) levanta el estado de transacción de todas las transacciones que haya en funcionamiento en todos los nodos que han fallado cuando ha ocurrido el fallo. Por lo tanto es importante que este nodo tenga tantos registros de transacción como el nodo que ha fallado.

    El valor por defecto para este parámetro es 4096.

  • Es una buena idea ajustar el valor de este parámetro según el tamaño y número de transacciones. Cuando se realizan transacciones de sólo unas cuantas operaciones y que no involucren muchos registros, no hay necesidad de inicializar este parámetro con un valor muy alto. Cuando realiza transacciones grandes involucrando muchos registros necesita cambiar a un valor mayor este parámetro.

    Los registros se mantienen para cada transacción que actualice los datos del cluster, tanto en el coordinador de la transacción como en los nodos donde se hacen las actualizaciones. Estos registros contienen información de estado necesaria para encontrar registros UNDO para deshacer cambios, bloquear colas y otros propósitos.

    Este parámetro debe inicializarse al número de registros a actualizar simultáneamente en transacciones, dividido por el número de nodos de datos del cluster. Por ejemplo, en un cluster que tenga 4 nodos de datos y del que se espera que trate 1,000,000 de actualizaciones concurrentes usando transacciones debe inicializar este valor a 1000000 / 4 = 250000.

    Leer consultas que hacen bloqueos hace que se creen registros. Se reserva un espacio extra en los nodos individuales para los casos en que la distibución no es perfecta entre los nodos.

    Cuando las consultas usan el índice hash único, hay dos registros de operación usados para registrar la transacción. El primer registro representa la lectura en la tabla índice y el segundo trata la operación en la tabla base.

    El valor por defecto para este parámetro es 32768.

    Este parámetro trata dos valores que se pueden configurar separadamente. El primero de ellos especifica cuántos registros de operación se tienen que situar en el coordinador de la transacción. La segunda parte especifica cuántos registros de operación serán locales en la base de datos.

    Una transacción muy grande realizada en un cluster de 8 nodos requiere tantos registros de operación en el coordinador de transacción como lecturas, actualizaciones y operaciones de borrado involucradas en la transacción. Sin embargo, los registros de operación se envían a los 8 nodos. Por lo tanto, si es necesario configurar el sistema para una transacción muy grande, es buena idea configurar las dos partes por separado. se usará siempre para calcular el número de registros de operación en la porción del coordinador de transacción del nodo.

    Es importante tener una idea de los requerimientos de memoria para registros de operaciones. Actualmente es aproximadamente 1KB por registro.

  • Por defecto, este parámetro se calcula como 1.1 * que encaja en sistemas con muchas transacciones simultáneas, ninguna de ellas demasiado grande. Si hay una necesidad de tratar una transacción muy grande de golpe y hay muchos nodos, es buena idea sobreescribir el valor por defecto especificando explícitamente este parámetro.

Almacenamiento temporal de transacciones

El siguiente conjunto de parámetros se usa para determinar almacenamiento temporal al ejecutar una consulta que es parte de una transacción de Cluster. Todos los registros se liberan al completar la consulta y el cluster espera para un commit o rollback.

Los valores por defecto de estos parámetros son adecuados para la mayoría de situaciones. Sin embargo, los usuarios con necesidad de soportar transacciones que involucren gran cantidad de registros u operaciones pueden necesitar incrementarlos para activar un mejor paralelistmo en el sistema, mientras que los usuarios cuyas aplicaciones necesitan transacciones relativamente pequeñas pueden decrementar los valores para ahorrar memoria.

  • Para consultas usando un índice hash único, el conjunto temporal de registros de operaciones se usa durante la fase de ejecución de una consulta. Este parámetro delimita el tamaño del conjunto de registros. Así este registro sólo se reserva mientras se ejecuta una parte de una consulta, en cuanto ha acabado la ejecución se libera el registro. El estado necesario para tratar abortos y commits se trata mediante los registros operacionales normales donde el tamaño del pool se asigna por el parámetro .

    El valor por defecto de este parámetro es 8192. Sólo en casos raros de paralelismo extremadamente alto usando índices hash únicos debería ser necesario incrementar este valor. Usar un valor menor es posible y puede ahorrar memoria si el DBA está seguro que un cierto grado de paralelismo no es necesario en el cluster.

  • El valor por defecto de es 4000, que es suficiente para la mayoría de situaciones. En algunos casos puede decrementarse si el DBA está seguro que el cluster no necesita un paralelismo alto.

    Se crea un registro cuando se realiza una operación que afecta un índice hash único. Insertar o borrar un registro en una tabla con índices hash únicos o actualizar una columna que es parte de un índice hash único provoca una inserción o borrado en la tabla índice. El registro resultante se usa para representar esta operación de la tabla índice mientras se espera a que la operación original se complete. Esta operación tiene una vida corta pero puede requerir un gran número de registros en su pool para situaciones en que muchas operaciones de escritura paralelas en una tabla base que contenga un conjunto de índices hash únicos.

  • La memoria afectada por este parámetro se usa para tracear operaciones disparadas al actualizar tablas índice y leer índices únicos. Esta memoria se usa para almacenar la información de clave y columna para estas opraciones. Es muy raro que el valor de este parámetro necesite alterarse.

    Las operaciones normales de lectura y escritura usan un búffer similar, cuyo uso es incluso de vida más corta. El parámetro de tiempo de compilación (que se encuentra en ) es 4000*128 bytes (500KB). Un buffer similar para información de claves, (también en ) contiene 4000*16 = 62.5KB de tamaño de búffer. es el módulo que trata la coordinación de transacciones.

Escaneos y búffering

Hay parámtros adicionales en el módulo (en ) que afecta a lecturas y actualizaciones. Incluyen , por defecto 10000*128 bytes (1250KB) y , por defecto 10000*16 bytes (unos 156KB) de tamaño de buffer. Hasta hoy, no ha habido ningún reporte de usuarios ni resultados de nuestros tests que sugieran que deba incrementarse estos límites en tiempo de compilación.

El valor por defecto de es 1MB.

  • Este parámetro se usa para controlar el número de escaneos paralelos que pueden realizarse en el cluster. Cada coordinador de transacción puede tratar el número de escaneos paralelos definidos por este parámetro. Cada consulta de escaneo se realiza escaneando todas las particiones en paralelo. Cada escaneo de partición usa un registro de escaneo en el nodo donde se encuentra la partición, siendo el número de registros el valor de este parámetro por el número de nodos. El clúster debe ser capaz de sostener escaneos concurrentes de todos los nodos en el cluster.

    Los escaneos se realizan en dos casos. El primero cuando no existe un índice hash u ordenado para tratar la consulta, en cuyo caso la consulta se ejecuta realizando un escaneo de la tabla completa. El segundo caso se encuentra cuando no hay índice hash para soportar la consulta pero hay un índice ordenado. Usar el índice ordenado significa ejecutar un escaneo de rango paralelo. Como el orden se mantiene en las particiones locales sólo, es necesario realizar el escaneo de índice en todas las particiones.

    El valor por defecto de es 256. El valor máximo es 500.

    Este parámetro especifica el número de escaneos posibles en el coordinador de transacción. Si el número de registros de escaneos locales no se proporciona, se calcula como el producto de y el número de nodos de datos en el sistema.

  • Especifica el número de registros de escaneo locales si varios escaneos no están paralelizados completamente.

  • Este parámetro se usa para calcular el número de registros bloqueados que necesitan estar ahí para tratar varias operaciones de escaneo concurrentes.

    El valor por defecto es 64; este valor tiene una fuerte conexión con definido en los nodos SQL.

  • Este es un buffer interno usado para pasar mensajes entre nodos individuales y entre nodos. Aunque es muy improbable que este valor deba cambiarse, es configurable. Por defecto es 1MB.

Logueo y establecer Checkpoins

  • Este parámetro especifica el tamaño del fichero de log REDO del nodo. Los ficheros de log REDO se organizan en un anillo. Es muy importante que el fichero primero y último del log (a veces conocidos como "cabeza" y "cola", respectivamente) no se encuentren; cuando se aproximan el uno al otro demasiado, el nodo empieza a abortar todas las transacciones que realizan actualizaciones debido a la falta de espacio para nuevos registros de log.

    Un registro de log REDO no se elimina hasta que se han completado tres checkpoints locales desde la inserción del último registro del log. Establecer checkpoints frecuentemente viene determinado por su propio conjunto de parámetros de configuración discutidos en este capítulo.

    El valor por defecto del parámetro es 8, que significa 8 conjuntos de 4 ficheros de 16MB para un total de 512MB. En otras palabras, el espacio de log REDO debe reservarse en bloques de 64MB. En escenarios que necesitan muchas actualizaciones, el valor de puede necesitar ser tan grande como 300 o incluso mayor para proporcionar suficiente espacio para logs REDO.

    Si se hacen pocos checkpoings y hay tantas escrituras en la base de datos que los ficheros de log se llenan y la cola de logs no puede cortarse sin recuperación jeapo rdising , se abortan todas las transacciones con un código de error interno 410, o . Esta condición prevalecerá hasta que se complete un checkpoint y se mueva la cola de log.

  • Este parámetro especifica el máximo número de ficheros de traceo que se mantienen antes de sobreescribir los antiguos. Los ficheros de traceo se generan cuando, por alguna razón, el nodo cae.

    Por defecto son 25 ficheros de traceo.

Objetos de metadatos

El siguiente conjunto de parámetros definen tamaños de pool para objetos de metadatos. Es necesario definir el máximo número de atributos, tablas, índices y disparadores usados por índices, eventos y replicaciones entre clusters.

  • Define el número de atributos que pueden definirse en el cluster.

    El valor por defecto para este parámetro es 1000, cuyo valor mínimo posible es 32. No hay máximo. Cada atributo consume acerca de 200 bytes de almacenamiento por nodo debido a que todos los metadatos están replicados en los servidores.

  • Se reserva un objeto tabla para cada tabla, índice hash único e índice ordenado. Este parámetro especifica el máximo número de objetos tabla para el cluster en total.

    Para cada atributo que tiene un tipo de datos se usa una tabla extra para almacenar la mayoría de datos . Estas tablas deben tenerse en cuenta al definir el número total de tablas.

    El valor por defecto es 128. El mínimo es 8 y el máximo es 1600. Cada objeto tabla consume aproximadamente 20KB por nodo.

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

    El valor por defecto es 128. Cada objeto consume unos 10KB de datos por nodo.

  • Para cada índice único que no sea clave primaria, se reserva una tabla especial que mapea la clave única con la clave primaria de la tabla indexada. Por defecto hay un índice ordenado que se define para cada índice único. Para evitarlo, debe usar la opción al definir el índice único.

    El valor por defecto es 64. Cada índice consume aproximadamente 15KB por nodo.

  • Los disparadores internos de actualización, inserción y borrado se reservan para cada índice hash único. (Esto significa que se crean 3 disparadores para cada índice hash.) Sin embargo, un índice ordenado necesita sólo un objeto disparador. Las copias de seguridad también usan tres objetos disparadores para cada tabla normal en el cluster.

    Nota: Cuando se soporta replicación entre clusters, esta hará uso de disparadores internos.

    Este parámetro inicializa el número máximo de objetos disparadores en el cluster.

    El valor por defecto es 768.

  • Este parámetro está obsoleto en MySQL 5.0; debe usar y en su lugar.

    Este parámetro se usa sólo en índices hash únicos. Debe haber un registro en este pool para cada índice hash único definido en el cluster.

    El valor por defecto es 128.

Parámetros booleanos

El comportamiento de los nodos de datos se ve afectado por un conjunto de parámetros booleanos. Estos parámetros pueden especificarse como poniéndolos a o , y como poniéndolos a o .

  • Para algunos sistemas operativos, incluyendo Solaris y Linux, es posible bloquear el proceso en memoria y evitar el swapping de disco. Esto puede usarse para ayudar a garantizar las características de tiempo real del cluster.

    Por defecto, esta característica está desactivada.

  • Este parámetro especifica si un proceso NDBD debe salir o reiniciarse automáticamente cuando se encuentra una condición de error.

    Esta característica está activada por defecto.

  • Es posible especificar tablas cluster como diskless, que significa que no se hacen checkpoints en disco y que no se loguean. Estas tablas sólo existen en memoria. Una consecuencia de usar estas tablas es que no se pueden mantener tras una caida. Sin embargo, cuando el modo diskless está operativo se puede ejecutar ndbd en una máquina sin disco.

    Nota: Actualmente, esta característica hace que el cluster entero funcione en modo diskless.

    Actualmente, cuando está característica está activa, las copias de seguridad se realizan pero los datos no se almacenan. En futuras versiones esperamos hacer la copia de seguridad diskless un parámetro separado y configurable.

    Esta característica está activada mediante poner a o . está desactivado por defecto.

  • Esta característica es accesible sólo al compilar la versión de debug cuando es posible insertar errores en la ejecución de bloques de código individuales como parte del testeo.

    Por defecto, esta característica está desactivada.

Controlar timeouts, intervalos y paginación de disco

Hay un número de parámetros que especifican timeouts e intervalos entre varias acciones en nodos de datos del culster. La mayoría de los timeouts se especifican en milisegundos. Cualquier excepción se menciona a continuación.

  • Para evitar que el flujo principal quede en un bucle sin fin en algún punto, un “watchdog” chequea el flujo principal. Este parámetro especifica el número de milisegundos entre chequeos. Si el proceso sigue siendo el mismo tras tres chequeos, lo mata el flujo watchdog.

    Este parámetro puede cambiarse fácilmente para propósitos de experimentación o para adaptar las condiciones locales. Puede especificarse por nodo aunque parece que no hay grandes razones para hacerlo.

    El timeout por defecto es de 4000 milisegundos (4 segundos).

  • Este parámetro especifica lo que esperará el cluster para que arranquen los nodos de almacenamiento cuando se invoca la rutina de inicialización . Este timeout se usa para evitar un arranque parcial del cluster cuando es posible.

    El valor por defecto es de 30000 milisegundos (30 segundos). significa timeout eterno; en otras palabras, el cluster puede arrancar sólo si todos los nodos están disponibles.

  • Si el cluster está preparado para arrancar tras esperar durante milisegundos pero todavía es posible en un estado particionado, el cluster espera hasta que este timeout pasa.

    El timeout por defecto es 60000 milisegundos (60 segundos).

  • Si un nodo de datos no ha completado su secuencia de arranque en el tiempo especificado por este parámetro, el arranque del nodo falla. Poner este parámetro a significa que no se aplica ningún timeout para el nodo de datos.

    El valor por defecto es 60000 milisegundos (60 segundos). Para los nodos de datos con cantidades de datos extremadamente grandes, este parámetro debe incrementarse. Por ejemplo, en el caso de un nodo de almacenamiento que contenga varios gigabytes de datos, un perido de 10-15 minutos (esto es, 600,000 a 1,000,000 milisegundos) puede ser necesario para realizar una reinicialización de nodo.

  • Uno de los métodos primarios de descubrimiento de nodos fallidos es el uso de heartbeats. Este parámetro refleja la frecuencia con que las señales heartbeat se envían y con que frecuencia se espera su recepción. Tras perder tres intervalos heartbeat seguidos, el nodo se declara muerto. Así el máximo tiempo para descubrir un fallo a través del mecanismo heartbeat es cuatro veces el intervalo heartbeat.

    El intervalo de heartbeat por defecto es de 1500 milisegundos (1.5 segundos). Este parámetro no debe cambiarse drásticamente y no debe variar demasiado entre nodos. Si un nodo usa 5000 milisegundos y el nodo observador usa 1000 milisegundos entonces óbviamente se declarará muerto rápidamente. Este parámetro puede cambiarse durande una actualización de software en línea pero sólo en pequeños incrementos.

  • Cada nodo de datos envía señales heartbeat a cada MySQL server (nodo SQL ) para segurar que permanece en contacto. Si un MySQL server falla para enviar un heartbeat a tiempo se declara “muerto”, en cuyo caso todas las transacciones activas se completan y todos los recursos se liberan. El nodo SQL no puede reconectar hasta que todas las actividades iniciadas por la instancia MySQL prévia se ha completado. El criterio de tres heartbeats para esta discriminación es la misma que se describe en .

    El intervalo por defecto es de 1500 milisegundos (1.5 segundos). Este intervalo puede variar entre nodos de datos individuales ya que cada nodo de almacenamiento vigila los servidores MySQL conectados a ellos, independientemente de todos los otros nodos de datos..

  • Este parámetro es una excepción en que no especifica un tiempo para esperar antes de arrancar un nuevo checkpoint local; en lugar de esto, se usa para asegurarse que los checkpoints locales no se realizan en un cluster donde tienen lugar relativamente pocas actualizaciones. En la mayoría de clusters con altos ratios de actualización, es probable que se arranquen checkpoints locales inmediatamente tras que se hayan completado los previos.

    El tamaño de todas las operaciones de escritura ejecutadas desde el arranque de los chekpoints locales prévios. Este parámetro es excepcional ya que se especifica como el logaritmo en base 2 del número de palabras de 4 bytes, así que el valor por defecto 20 significa 4MB (4 * 220) de operaciones de escritura, 21 significaría 8MB, y así hasta un máximo de 31, que son 8GB de operaciones de escritura.

    Todas las operaciones de escritura en el cluster se añaden juntas. Poner a 6 o menos significa que los checkpoints locales se ejecutarán contínuamente sin pausa, independientemente de la carga de trabajo del cluster.

  • Cuando se hace un commit de una transacción, se realiza en memoria principal en todos los nodos en que los datos se replican. Sin embargo, los registros del log de transacción no se vuelcan en disco como parte del commit. El razonamiento de este comportamiento es que tener la transacción con un commit en al menos dos máquinas autónomas debe cumplir estándars razonables para durabilidad.

    También es importante asegurarse que incluso el peor caso — una caída completa del cluster — se trata apropiadamente . Para garantizar que esto ocurre, todas las transacciones que tienen lugar dentro de un intervalo dado se ponen en un checkpoint global, que puede entenderse como un conjunto de transacciones volcadas en disco. En otras palabras, como parte del proceso de commit, una transacción se guarda en el grupo de checkpoint global; posteriormente, este registro de log de grupo se vuelca en disco, y luego se guarda en disco el completo grupo de transacciones en todas las máquinas del cluster.

    Este parámetro define el intervalo entre checkpoints globales. Por defecto son 2000 milisegundos.

  • El tratamiento de time-outs se realiza chequeando un timer en cada transacción una vez por cada intervalo especificado por este parámetro. Por lo tanto, si este parámetro se pone a 1000 milisegundos, cada transacción se chequea para hacer un time out una vez por segundo.

    El valor por defecto para este parámetro es 1000 milisegundos (1 segundo).

  • Si la transacción no está realizando ninguna consulta pero esta esperando más datos de entrada del usuario, este parámetro indica el tiempo máximo que el usuario puede esperar entes de abortar la transacción.

    Por defecto este parámetro es cero (no timeout). Para una base de datos en tiempo real que necesita asegurarse que las transacciones no mantienen bloqueos demasiado tiempo se debe inicializar con un valor mucho más pequeño. La unidad es milisegundos.

  • Cuando un nodo ejecuta una consulta que implique una transacción, el nodo espera para que respondan los otros nodos en el cluster antes de continuar. Puede que haya un fallo al responder por cualquiera de las siguientes razones:

    1. El nodo está “muerto”

    2. La operación ha entrado en una cola de bloqueo

    3. El nodo con la petición de realizar la acción puede estar muy sobrecargado.

    Este parámetro de timeout indica cuánto espera el coordinador de la transacción para la ejecución de la consulta por otro nodo antes de abortar la transacción, y es importante para tratamiento de fallo de nodo y detección de deadlocks. Ponerlo a un valor muy alto puede causar comportamiento no deseables en situaciones que impliquen deadlocks y fallos de nodos.

    El timeout por defecto es 1200 milisegundos (1.2 segundos).

  • Al ejecutar un checkpoint local el algoritmo vuelca todas las páginas de datos a disco. Hacer esto tan rápidamente como sea posible sin ninguna moderación es posible que imponga demasiada carga de procesador, red y disco. Para controlar la velocidad de escritura, este parámetro especifica cuántas paginas se escriben en 100 milisegundos. En este contexto, una “página” se define como 8KB; por lo tanto, este parámetro se especifica en unidades de 80KB por segundo. Por lo tanto, poner a un valor de 20 significa escribir 1.6MB de páginas de datos en disco cada segundo durante checkpoints locales. Este valor incluye escribir registros del log UNDO para páginas de datos; esto es, este parámetro trata la limitación de escrituras de memoria de datos. Los registros del log UNDO para páginas de índice se tratan mediante los parámetros . (Consulte la entrada para para información acerca de páginas de índice.)

    Resumiendo, este parámetro especifique con qué velocidad se realizan los checkpoints locales, y opera en conjunción con , , y .

    El valor por defecto es 40 (3.2MB de páginas de datos por segundo).

  • Este parámetro usa las mismas unidades que y actúa de forma similar, pero limita la velocidad de escritura de páginas índices de memoria índice.

    El valor por defecto de este parámetro es 20 páginas índice de memoria por segundo (1.6MB por segundo).

  • Este parámero parecido a y , sólo lo hace en función de los checkpoints locales ejecutados en el nodo donde se reinicia un nodo. Como parte de todo reinicio de nodo siempre se realiza un checkpoint. Durante el reinicio de un nodo es posible escribir en disco a una velocidad superior que otras veces, ya que se realizan menos actividades en el nodo.

    Este parámetro cubre páginas escritas de memoria de datos.

    El valor por defecto es 40 (3.2MB por segundo).

  • Controla el número de páginas de memoria índice que pueden escribirse en disco durante la fase de checkpoint local del reinicio de un nodo.

    Como con y , los valores para este parámetro se expresan en términos de 8KB páginas escritas en 100 milisegundos (80KB/segundo).

    El valor por defecto es 20 (1.6MB por segundo).

  • Este parámetro especifica el tiempo que esperará el nodo de datos en respuesta al árbitro. Si se excede, se asume que la red se ha partido.

    El valor por defecto es de 1000 milisegundos (1 segundo).

Buffering y Logueo

Varios parámetros de configuración se corresponden a antiguos parámetros en tiempo de compilación que todavía están disponibles. Esto permite al usuario avanzado tener más control sobre los recursos usados por los procesos nodo y para ajustar varios tamaños de buffer según sea necesario.

Estos buffers se usan como front ends para el sistema de ficheros cuando se escriben los registros de log en disco. Si el nodo está ejecutándose en modo diskless, y estos parámetros pueden cambiarse a sus valores mínimos sin penalización debido al hecho que las escrituras en disco se "falsean" por parte la capa de abstracción del sistema de ficheros del motor de almacenamiento NDB.

  • Este buffer se usa durante los checkpoints locales. El motor NDB usa un esquema de recuperación basado en consistencia de checkpoints en conjunción con un log REDO operacional. Para producir un checkpoint consistente con bloquear el sistema entero para escrituras, el logueo de UNDO se hace mientras se realiza el checkpoint local. El logueo UNDO se activa en un fragmento de tabla único cada vez. Esta optimización es posible porque las tablas se almacenan completamente en memoria.

    El buffer UNDO índice se usa para las actualizaciones en el índice de clave hash primaria. Las inserciones y borrados modifican el índice hash; el motor NDB escribe registros en el log UNDO que mapean todos los cambios físicos en una página índice de forma que pueden deshacerse al reiniciar al sistema. También loguea todas las operaciones de inserciones activas para cada fragmento al arranque del checkpoint local.

    Lee y actualiza el conjunto de bits de bloquea y actualiza una cabecera en la entrada del índice hash. Estos cambios los trata el algoritmo de escritura de páginas para asegurar que estas operaciones no necesitan logueo UNDO.

    Este búffer es de 2MB por defecto. El valor mínimo es de 1MB, y para la mayoría de aplicaciones el mínimo es suficiente. Para aplicaciones que realicen un número de inserciones y borrados muy alto junto con transacciones muy grandes y claves primaria grandes, puede ser necesario incrementar el tamaño de este buffer. Si el buffer es muy pequeño, el motor NDB realiza un código de error interno 677 .

  • El buffer de datos UNDO juega el mismo rol que el buffer de indice UNDO, excepto que se usa a con la memoria de datos en lugar de la de índice. Este buffer se usa durante la fase de checkpoint local de un fragmento para inserciones, borrados y actualizaciones.

    Como UNDO las entradas de log tienden a crecer mayores mientras más operaciones se loguean, este buffer también es mayor que su contraparte de memoria índice, con un valor por defecto de 16MB.

    Para algunas aplicaciones esta cantidad de memoria puede ser innecesariamente grande. En tales casos es posible decrementar este tamaño a un mínimo de 1MB.

    Ráramente es necesario incrementar el tamaño de este buffer. Si hay tal necesidad, es una buena idea chequear si el disco puede tratar la carga causada por la actividad de actualización de la base de datos. Una falta de espacio de disco no puede evitarse incrementando el tamaño de este buffer.

    Si este buffer es demasiado pequeño y se congestiona, el motor NDB realiza un código de error interno 891 .

  • Todas las actividades de actualización necesitan loguearse. Este log hace posible rehacer estas actualizaciones cuando el sistema se reinicia. El algoritmo de recuperación NDB usa un checkpoint “fuzzy” de los datos junto con el log UNDO, luego aplica el log REDO para aplicar todos los cambios hasta el punto de restauración.

    Este buffer es de 8MB por defecto. El valor mínimo es 1MB.

    Si este buffer es demasiado pequeño, el motor NDB realiza un código de error 1221 .

Al administrar el cluster, es muy importante ser capaz de controlar el número de mensajes de log enviados por distintos tipos de eventos a . Hay 16 niveles posibles de evento (numerados de 0 a 15). Realizar un reporte de evento para una categoría de evento dada a nivel 15 significa que todos los reportes de evento en esta categoría se envían a ; ponerlo a 0 significa que no habrá reportes de eventos en esta categoría.

Por defecto, sólo el mensaje de arranque se envía , con los valores por defecto de los niveles de reporte pendientes puestos a 0 . La razón para esto es que estos mensajes también se envían al log de administración del cluster.

Un conjunto de niveles análogo puede ponerse para el cliente de administración para determinar qué niveles de evento registrar en el log de cluster.

  • Reportar niveles para eventos generados durante el arranque del proceso.

    El nivel por defecto es 1.

  • El nivel de reporte para eventos generados como parte de un cierre de un nodo.

    El nivel por defecto es 0.

  • El nivel de reporte para eventos estadísticos tales como número de lecturas de clave primaria, número de actualizaciones, número de inserciones, información acerca del uso de búffer, y así.

    El nivel por defecto es 0.

  • Nivel de reporte para eventos generados por los checkpoints locales y globales.

    El nivel por defecto es 0.

  • Nivel de reporte para eventos generados durante reinicio de nodo.

    El nivel por defecto es 0.

  • El nivel de reporte para eventos generados por conexiones entre nodos del cluster.

    El nivel por defecto es 0.

  • Nivel de reporte para eventos generados por errores y advertencias por el cluster global. Estos errores no causan ningún fallo de nodo pero se considera que vale la pena de reportar.

    El nivel por defecto es 0.

  • Nivel de reporte para eventos generados por información acerca del estado general del cluster.

    El nivel por defecto es 0.

Parámetros de copia de seguridad

Los parámetros de esta sección definen buffers de memoria para ejecución de copias de seguridad en línea.

  • Al crear una copia de seguridad, hay dos búffers usados para enviar data a disco. El buffer de copia de seguridad de datos se usa para rellenar con datos registrados al escanear las tablas de un nodo. Una vez que este buffer se ha rellenado al nivel especificado por (vea a continuación), las páginas se envían a disco. Al volcar los datos a disco, el proceso de copia de seguridad puede continuar rellenando este buffer hasta que se queda sin espacio. Cuando ocurre, el proceso de copia de seguridad pausa el escaneo y espera hasta que se completan algunas escrituras en disco y han liberado memoria de forma que pueda continuar el escaneo.

    El valor por defecto de este paráemtro es 2MB.

  • El buffer de log de copia de seguridad tiene un rol similar al jugado por el buffer de copia de seguridad de datos , excepto que se usa para generar un log de todas las escrituras de tabla realizadas durante la ejecución de una copia de seguridad. Los mismos principios se aplican para escribir estas páginas como con el buffer de datos de copia de seguridad, excepto que cuando no hay más espacio en el buffer de log de copia de seguridad, la copia falla. Por esta razón, el tamaño del buffer de log de copia de seguridad debe ser lo bastante grande para tratar la carga causada por las actividades de escritura mientras se realiza la copia de seguridad.

    El valor por defecto de este parámetro debe ser suficiente para la mayoría de aplicaciones. De hecho, es más fácil que un fallo de copia de seguridad sea causado por velocidad de escritura en disco insuficiente que por que el buffer de log esté lleno. Si el subsistema de disco no está configurado para la carga de escritura causada por las aplicaciones, el cluster posiblemente será capaz de realizar las operaciones deseadas.

    Es preferible configurar nodos del cluster de forma que el procesador sea el cuello de botella en lugar que los discos o las conexiones de red.

    El valor por defecto es 2MB.

  • Este parámetro es la suma de y .

    El valor por defecto es 2MB + 2MB = 4MB.

  • Este parámetro especifica el tamaño de los mensajes escritos en disco por los buffers de log y datos de copia de seguridad.

    El valor por defecto es 32KB.

16.4.4.6. Definir los servidores MySQL (nodos sql) en un MySQL Cluster

La sección del fichero define el comportamiento de los servidores MySQL (nodos SQL) usados para acceder a los datos del cluster. Ninguno de los parámetros mostrados es necesario. Si no se proporciona máquina ni nombre de equipo, entonces cualquier equipo puede usar este nodo SQL.

  • Este valor se usa como dirección del nodo por todos los mensajes internos del cluster, y debe ser un entero entre 1 y 63. Cada nodo del cluster debe tener una identidad única dentro del cluster.

  • Se refiere a una de las máquinas definidas en la sección del fichero de configuración.

  • Este parámetro se usa para definir qué nodos pueden actuar como árbitros. Pueden serlo los nodos MGM y SQL. Un valor de 0 significa que el nodo dado nunca se usará como árbitro, un valor de 1 le da al nodo alta prioridad como árbitro, y un valor de 2 le da baja prioridad. Una configuración normal usa el servidor de administración como árbitro, poniendo se a 1 (por defecto) y los nodos SQL a 0.

  • Poner este parámetro con cualquier valor distinto a 0 (valor por defecto) significa que las respuestas al árbitro se retrasan el número indicado de milisegundos. Usualmente no es necesario cambiar este valor.

  • Para consultas traducidas en escaneos completos de tabla o escaneo de rangos de índices, es importante pare un mejor rendimiento tratar registros en batchs de tamaño apropiado. Es posible poner el tamaño adecuado en términos de número de registros () y en términos de bytes (). El tamaño batch real viene limitado por ambos parámetros.

    La velocidad a la que se realizan las consultas puede variar más de un 50$ en función de cómo se ajusta este parámetro. En versiones futuras, el servidor MySQL realizará conjeturas sobre cómo ajustar estos parámetros según el tamaño batch basado en el tipo de consulta.

    Este parámetro se mide en bytes y por defecto es igual a 32KB.

  • Este parámetro se mide en número de registros y por defecto es 64. El tamaño máximo es 992.

  • El tamaño batch es el tamaño de cada batch envíado por cada nodo de datos. La mayoría de escaneos se realizan en paralelo para proteger que el servidor MySQL reciba demasiados datos de demasiados nodos en paralelo; este parámetro ajusta el límite del tamaño total batch en todos los nodos.

    El valor por defecto de este parámetro se ajusta a 256KB. Su tamaño máximo es 16MB.

16.4.4.7. Conexiones TCP/IP de MySQL Cluster

TCP/IP es el mecanismo de transporte por defecto para establecer conexiones en MySQL Cluster. Normalmente no es necesario definir conexiones ya que el cluster automáticamente crea una conexión entre todos los nodos de datos, entre cada nodo de datos y los nodos MySQL server y entre cada nodo y el servidor de administración. (Para una excepción a esta regla consulte Sección 16.4.4.8, “Conexiones TCP/IP de MySQL Cluster usando conexiones directas”.)

Sólo es necesario definir una conexión para sobreescribir los parámetros por defecto de conexión. En tal caso es necesario definir al menos , , y los parámetros a cambiar.

Es posible cambiar los valores por defecto para estos parámetros cambiándolos en la sección .

  • ,

    Para identificar una conexión entre dos nodos es necesario proporcionar los identificadores de nodo para ambos en la sección del fichero de configuración.

  • TCP usa un buffer para almacenar todos los mensajes antes de realizar la llamada de envío del sistema operativo. Cuando este buffer llega a 64KB sus contenidos se envían; también se envían cuando se ha ejecutado una ronda de mensajes. Para tratar situaciones de sobrecarga temporal es posible definir un buffer de envio mayor. El tamaño por defecto del buffer de envío es 256KB.

  • Para poder trazar un diagrama de mensaje distribuído es necesario identificar cada mensaje. Cuando este parámetro es , los IDs de mensaje se transportan por la red. Esta característica está desactivada por defecto.

  • Este parámetro es booleano (/ o /) , y está desactivado por defecto. Cuando está activado, los checksums de todos los mensajes se calculan antes de ponerlos en el buffer de envío. Esta característica se asegura que los mensajes no se corrompan mientras esperan en el buffer de envío, o por el mecanismo de transporte.

  • (OBSOLETO.) Antiguamente especificada el número de puerto a usar para escuchar las conexiones de otros nodos. Este paráemtro no debe usarse más.

  • Especifica el tamaño del buffer usado al recibir datos del socket TCP/IP . No hay necesidad de cambiar el valor por defecto de este parámetro de 64KB, excepto para ahorrar memoria.

16.4.4.8. Conexiones TCP/IP de MySQL Cluster usando conexiones directas

Ajustar el cluster usando conexiones directas entre nodos de datos requiere curzar explícitamente las direcciones IP de los nodos de datos conectados así en la sección del fichero del cluster.

En el siguiente ejemplo, tenemos un cluster con al menos 4 equipos, uno para un servidor de administración, un nodo SQL, y dos nodos de datos. El cluster reside en la subred de una LAN. Además de las conexiones de red usuales, los dos nodos de datos se conectan directamente usando un cable cruzado, y comunican entre ellos directamente usando direcciones IP en el rango IP como se muestra: 

# Management Server
[NDB_MGMD]
Id=1
HostName=172.23.72.20

# SQL Node
[MYSQLD]
Id=2
HostName=172.23.72.21

# Data Nodes
[NDBD]
Id=3
HostName=172.23.72.22

[NDBD]
Id=4
HostName=172.23.72.23

# TCP/IP Connections
[TCP]
NodeId1=3
NodeId2=4
HostName1=1.1.0.1
HostName2=1.1.0.2

El uso de conexiones directas entre nodos de datos puede mejorar la eficiencia global del cluster permitiendo a los nodos de datos cortocircuitar un equipo de Ethernet como un switch, hub o router, disminuyendo la latencia del cluster. Es importante tener en cuenta que para obtener el mayor rendimiento de las conexiones directas con más de 2 nodos de datos, necesitará tener una conexión directa entre cada datos de nodos y cada uno de los nodos de datos en el mismo grupo de nodos.

16.4.4.9. Conexiones de MySQL Cluster que comparten memoria

En MySQL 5.0, MySQL Cluster tata de usar transporte a través de memoria compartida y configurarla automáticamente cuando sea posible, principalmente donde más de un nodo se ejecuta concurrentemente en el mismo equipo del cluser. (En versiones anteriores de MySQL Cluster, los segmentos de memoria compartida se soportan sólo cuando el binario se compila usando .) Cuando se define la memoria compartida explícitamente como método de conexión, es necesario definir como mínimo , y . Todos los otros parámetros tienen valores por defecto que funciona bien en la mayoría de casos.

Nota: El soporte SHM debe considerarse experimental.

  • ,

    Para identificar una conexión entre dos nodos es necesario proporcionar identificadores para cada uno de ellos como y .

  • Cuando se inicializan segmentos de memoria compartido, un ID de nodo se identifica para identificar unívocamente el segmento de memoria compartida para usar para la comunicación. Se expresa como un entero que no tiene valor por defecto.

  • Cada conexión SHM tiene un segmento de memoria compartida dónde los nodos entre mensajes se guardan por parte del que envía y donde lo lee el receptor. El tamaño de este segmento lo define . El valor por defecto es 1MB.

  • Para obtener la traza de la ruta de un mensaje distribuído, es necesario proporcionar un identificador único a cada mensaje. Poner este parámetro a hace que los IDs de mensajes se transporten sobre la red también. Esta característica está desactivada por defecto.

  • Este parámetro es / , y está desactivado por defecto. Cuando se activa, se calculan los checksums para todos los mensajes y se guardan en el buffer de envío.

    Esta característica evita que los mensajes se corrompan mientras esperan en el buffer de envío. También sirve como chequeo para que no se corrompan los datos durante el transporte.

16.4.4.10. Conexiones de transporte SCI en MySQL Cluster

Se soporta el uso de transporte SCI en MySQL Cluster sólo cuando los binarios MySQL-Max se compilan usando . El debe apuntar a un directorio que contiene como mínimo los directorios y con las bibliotecas SISCI y ficheros de cabecera.

Además, SCI necesita hardware especializado.

Es muy recomendable usar SCI Transporters sólo para comunicación entre procesos ndbd . Además, usar SCI Transporters significa que los procesos ndbd nunca duermen. Por esta razón, los SCI Transporters deben usarse sólo en máquinas con al menos 2 CPUs dedicadas para usar con procesos ndbd . Al menos debe haber 1 CPU por proceso ndbd , con al menos 1 CPU en reserva para tratar actividades del sistema operativo.

  • ,

    Para identificar una conexión entre dos nodos es necesario proporcionar identificadores de nodo para cada uno de ellos, como y .

  • Esto identifica el nodo ID SCI en el primer nodo del Cluster (identificado por ).

  • Es posible preparar SCI Transporters para tratar fallos entre dos tarjetas SCI que deban usar redes separadas entre los nodos. Esto identifica el ID del nodo y la segunda tarjeta SCI a usar en el primer nodo.

  • Esto identifica el ID del nodo SCI en el segundo nodo del Cluster (identificado por ).

  • Cuando dos tarjetas SCI para proporcionar tolerancia a fallos, este parámetro identifica la segunda tarjeta SCI a usar en el segundo nodo.

  • Cada SCI transporter tiene un segmento de memoria compartido usado para la comunicación entre los dos nodos. Especificar el segmento de este valor por defecto de 1 MB debería ser suficiente para la mayoría de aplicaciones. Usar un valor menor puede llevar a problemas al realizar muchas inserciones paralelas; si un buffer compartido es demasiado pequeño, puede resultar en una caída del proceso ndbd .

  • Un buffer pequeño en frente del medio SCI almacena mensajes antes de transmitirlos en la red SCI. Por defecto se pone 8kB. Nuestras pruebas muestras que el rendimiento es mejor con 64 kB pero 16kB alcanza un pequeño porcentaje de esto, y hay poca ventaja si se incrementa más allá de 8kB.

  • Para tracear un mensaje distribuído es necesario identificar cada mensaje únicamente. Cuando este parámetro se pone a , los IDs de mensaje se transportan sobre la red. Esta característica se desactiva por defecto.

  • Este parámetro es un valor booleano, y está desactivado por defecto. Cuando está activado, los checksums se calculan para todos los mensajes antes de ponerlos en el buffer de envío. Esta característica evita que los mensajes se corrompan mientras esperan en el buffer de salida durante el transporte.

previous page start next page